タグ: CentOS

MySQL5.7をyumでアップデートしようとしたらコケた

2022年1月19日 / 管理人 / 0件のコメント

CentOS7が動いているサーバにMySQL5.7をOracleのレポジトリからyumでrpmを取得する形でインストールしてあったのだが、そのサーバでyum updateをかけたら、yumがエラーで止まった。

The GPG keys listed for the “MySQL 5.7 Community Server” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

…GPGが何やらおかしいとのこと。で、調べてみると、以前よりOracleのレポジトリで使っていたPGPキー、CentOS7だと/etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlに置かれることになる、この鍵は有効期限が2022年2月16日までだったそうで、新しい鍵に切り替えられたらしい。

そんなわけで、古い鍵ではアップデートが出来なくなったようだ。だったら、新しい鍵をインポートしちゃえばいいってことで。

sudo rpm –import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

を実行すれば、今のレポジトリで使われている鍵がインポートされるので、yumのアップデートが普通に実行されるとのこと。

ただまぁ、前から2022年2月までの有効期限だったはずだけど、極めて最近になって発覚して、急遽、GPG鍵が新しいものになったようで…。

参考：
The MySQL GPG key seems to be incorrect
https://bugs.mysql.com/bug.php?id=106188

Changes in MySQL 8.0.28 (2022-01-18, General Availability)
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-packaging

KVMで仮想化したCentOS7の時計について

2016年11月24日 / 管理人 / 0件のコメント

もはや完全にわかってなかった…っていうそれだけのことだけど…。

CentOS6で動いているサーバがあって、そのサーバの上で、KVMで仮想化したCentOS7を動かそうとしていて、無事にインストールできたもののCentOS7の時計がなんか変ってことでウダウダした際のメモ。

とりあえず、結論から書いちゃうと、仮想化されたCentOS7はKVMが提供するkvm-clockを参照するようになっている。んで、kvm-clockがゲストOSに提供する時刻のタイムゾーンは仮想化されたサーバごとに設定で変更することができて、ゲストOSにCentOS6を使っていた時には、JSTで提供するように設定してあって特に問題はなかったんだけど、どうやらCentOS7からはUTCで提供されることが前提になったらしい。

CentOS7の設定を帰ると、kvm-clockがUTCじゃなくて、特定のタイムゾーン(今回はJST)の時刻で提供されることを前提にすることもできるけど、そうするとWarningが出力されてしまい、まぁ、Warningだし、いっかと思いつつ、ちょっと気持ちが悪かった。そういうわけなので、KVMの設定ファイルを書き換えて、UTCでkvm-clockを出すようにすると問題なく動くようになった。

まず、CentOS7で時計回りがどうなってるかは、以下のコマンドで確認する。

# timedatectl status

表示される結果の中で「RTC in local TZ: no」となっていれば、kvm-clockはUTCで提供されるもんだと、CentOS7は思っているようですな。KVM側でkvm-clockを提供する際のタイムゾーンをどうするかは、各ドメインの設定XMLの中でこんな感じで(下記のようにすると、UTCで提供される)

CentOS6時代のまま、KVMの設定ファイルのoffsetがlocaltimeになっていると、JSTで提供されてしまうので、CentOS7の方でJSTをUTCとして扱ってしまうので、まったく違う時間を保持してしまうと。…まぁ、NTPでの同期を設定してあれば、そのうち、修正されるだろうけど、気持ち悪いし、システムの時計がすごい幅で修正されてしまうのでドキドキする。

んで、kvm-clockがUTCじゃなくて、特定のタイムゾーンの時刻で提供されることをCentOS7に教えるには、さきほどのtimedatectlコマンドを使って

# timedatectl set-local-rtc 1

って実行すれば、教えることができるけれど、

This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments.

ってビミョーなWarningが出てくる、と。

密かに想像するに、CentOS7から導入されたsystemdって、デフォルトで時刻をUTCで扱うようなので、kvm-clockをUTCであるものとして動くってのも、その絡みのなんだろうなぁ。システム内部ではUTCで持っておいて、設定に応じて、そのタイムゾーンに合わせた時刻を返すってのが、いろいろと間違いないやり方ではあるような気はするけども…(遠い目)

postfixのログをサマリーするにはpflogsummだけど。

2016年9月7日 / 管理人 / 0件のコメント

Postfixでメールをホイホイ投げるようなサーバだと、postfixが吐き出すmaillogを見やすくまとめてもらって、たまーに眺められるようにしておくのがいいかなぁと思う。んで、ちょっと調べて見たら、pflogsummというPerlで書かれたスクリプトにmaillogを食わせると、ログのサマリーを作ってくれるらしい。

CentOSのyumレポジトリにもあるらしいのだが、先人達のブログを読むと

# yum -y install postfix-pflogsumm

でインストールできるとのことだが、「postfix-pflogsumm」というパッケージが見当たらない。収録されなくなったか、名前が変わったかのどちらかだろうなぁと思いつつ、yum search postfixを実行してみると、「postfix-perl-scripts」っていうパッケージが見つかった。んで、yum info postfix-perl-scriptsを実行してみると、説明の1行目にこんな記載があった。

This package contains perl scripts pflogsumm and qshape.

qshapeっていう、キューの状態を確認できるPerlスクリプトと同じパッケージにまとめられたような感じだろうか。というわけで、「postfix-perl-scripts」をインストールすると、pflogsummが使えるようになった。

CentOS7のNTPサーバ/クライアント

2015年11月4日 / 管理人 / 0件のコメント

CentOS7から、ntpdに代わって(…という割にはntpdも普通に使えるんだけども)chronyがNTPクライアント/サーバになったらしい。ntpdが普通に使えていたので、chronyの存在しならないままだったけど、ひょんなことからchronyの存在に気付いた…。

というわけで、備忘メモ。

インストールするとき

普通にCentOSをインストールするとchronyもインストールされてそうだけど、最低限のインストールを行うと入ってないこともあるようだ。

sudo yum install chrony

chronydの設定ファイル

CentOS7だと、/etc/chrony.confが設定ファイル。NTPサーバを指定する書き方はntpd.confとよく似ているけど、微妙に違う(そりゃ当然だ)

OS起動時に起動する/起動する

ま、普通にsystemctlに御願いする。

sudo systemctl enable chronyd

sudo systemctl start chronyd

NTPサーバとの同期状況の確認

以下のコマンドで概況を知ることが出来そう。今、同期に使っているサーバとズレを確認するコマンドはこんな感じ。

chronyc tracking

んで、ソースに指定しているNTPサーバとの通信状況を確認するには、こっちのコマンド。

chronyc sources

まぁ、こういうのも慣れなので、今度、CentOS7を使うことがあればntodではなくchronydを使ってみることにしよう。

[amazonjs asin=”4798043591″ locale=”JP” title=”CentOS7で作るネットワークサーバ構築ガイド (Network server construction gu)”]

memcached 1.4.5をCentOS5でRPM作るとコケる件。

2010年5月14日 / 管理人 / 0件のコメント

久しぶりにmemcachedのサイトを見てみたら、新しい1.4.5がリリースされてたので、RPMを作ってサーバにインストールしようとしたら、rpmbuildでコケた。サーバはx86なマシンで、CentOSの5.3が動いてる感じ。

rpmbuildが異常終了した後、画面に出てる文字列を眺めてみる。

(前略)

t/item_size_max……ok

t/line-lengths…….ok

t/lru…………….ok

t/maxconns………..ok

t/multiversioning….ok

t/noreply…………ok

t/stats-detail…….ok

t/stats…………..ok

t/udp…………….ok

t/unixsocket………ok

t/whitespace………skipped

all skipped: Skipping tests probably because you don’t have git.

Failed Test Stat Wstat Total Fail Failed List of Failed

——————————————————————————-

t/binary.t 255 65280 3361 6212 184.83% 240 243-244 251 255 258-3361

2 tests skipped.

Failed 1/39 test scripts, 97.44% okay. 3109/6475 subtests failed, 51.98% okay.

make: *** [test] エラー 255

エラー: /var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)

RPM ビルドエラー:

/var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)

うーむ。さっぱりわからん(汗)

なんとなーく、ビルドの過程は終わっているんだけど、make testが走りきらない感じですかね。

何回やってもラチがあかないので、調べてみたら、この辺とか、この辺に、なんとなく関係がありそうなことが書いてあった。

妄想の域は出ないけれど、memcachedが依存しているモジュールのバージョンの問題なのかも。具体的には、memcachedの1.4.4まではlibeventの1.1でも動作するけれど、1.4.5からlibeventの1.1ではダメで、1.4あたりを必要とするのではないかと。で、CentOS 5.4以前のRPMレポジトリに入っているlibeventは1.1で、CentOS5.5(現時点でリリースされてるのは、RHEL5.5の方だけ)になったらlibeventが1.4あたりにバージョンアップされる…と。結局、memcached1.4.5をビルドしようと思ったら、CentOS5.5のリリースを待って、アップグレードをかけなきゃいけないってことなのかな。あー。

livedoorのサーバOSはFreeBSDじゃなくてCentOSなのか、そうなのか。

2009年8月17日 / 管理人 / 0件のコメント

WikipediaのFreeBSDのページを見てると、使用例の欄に以下のような記載がある。

ライブドア – ほとんどのサーバOSがFreeBSD

そんなわけで、「そうか、livedoor(のポータル)って、FreeBSDで動いているんだ」と思っていた。で、NetCraftで調べてみると、確かに、しばらく前までFreeBSDだったんだけど、最近はF5なBIG-IPになっていて、きっとBIG-IPの配下でFreeBSDががんばってるんだと思っていた。

しかし、livedoor開発blogの「1000台の子供達 – livedoorを支えるサーバ群 –」ってエントリーを拝見すると、

現在のポータルサーバの主流OSはCentOSです。新規にセットアップされるものの99%が、このOSになります。

…って(汗)ああ、そうなのか、livedoorはCentOSなのか。BIG-IPの配下でがんばってるのは、FreeBSDなサーバではなく、CentOSなIBMサーバ群ってのが真相のようで。きっと、膨大なサーバ群をリプレースしていく過程で、OSもFreeBSDからCentOSに変えていったのかと思うと、さすがlivedoorさんだなぁ…なんて思ったりする今日この頃。

個人的には、CentOSが何かと楽ちんな気がするけれど、FreeBSDの無骨な感じ(特にインストーラーとか)も悪くないし、デフォルトの設定が「堅い」(最初から誰でもsuでrootになれないとか)のはFreeBSDの方だったりするんじゃないかと思ったりする。…と、偉そうなことを書いてる割には、FreeBSDを触って1週間ですが、何か(汗)

ASR-2015SをCentOS5.2で～とりあえず、インストール編～

2009年1月28日 / 管理人 / 0件のコメント

古いサーバにCentOS5.2をインストールすることにした。古いサーバが積んでいるRAIDカードは「ASR-2015S」というヤツで(誤解しているかもしれないが)SCSIを使ったデータのハンドリングはオンボードのSCSIコントローラにやらせるけれど、RAID機能(つまり、2つのHDDにデータを書き込んだり、必要に応じて、RAIDをrebuildしたりといったこと)は「ASR-2015S」が担う…的なややこしいことやってるなぁという印象のRAIDカード。なんか「Zero Channel RAID (ZCR)」ってシロモノらしく、特殊なスロットに収まっているのを見て、なんかイヤな予感がしたんだけども…。

とりあえず、いつも使っているCentOS5.2のネットワークインストール用イメージを書き込んだCD-Rを引っ張り出して、起動してみました。…すると、ディスクのパーティションの設定画面の後で、ディスクがないと言われてしまい、先に進めず。CentOSのインストーラから、RAIDカードを認識できていないような状況だった。

んで、いろいろと調べてみたところ、「ASR-2015S」のRAID Arrayを扱う場合は、「i2o_block」というドライバを使えばいいことがわかった(I2O on Linuxを参照)。で、CentOS5もそのドライバを同梱しているようだった。ということは、デバイスの認識に失敗しているようなので、インストーラを起動するときに自動でデバイスを認識しないようにしてみた。

インストーラの入ったCDからbootして、CentOSのロゴが出ている画面で普段はEnterキーを押すだけだけど、今回は

linux noprobe

と入力して、Enter。ネットワークインストール用イメージなので、まずは、NICのドライバをどうするか聞かれるが、このサーバはIntelのGbEなNICだったはずなので、とりあえずe1000を選択してみたら、すんなり使えるようになった。ネットワーク越しにインストール用イメージが見えるようになったら、追加のデバイスドライバを入れるか聞かれたので、そこで「i2o_block」を選択した。

すると、最初、「HDDがありまへん」と怒られたところで、「ASR-2015S」のRAID Arrayが見えた！その後は普通にインストールして、インストール完了。