スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | --:--:--
Debian 8.0 へのアップグレード (part 2)

Debian 8.0 (Jessie) へのアップグレード後の諸々の処置

Apache2 が起動していない

アップグレード時に ssl.conf の上書きは(いろいろカスタマイズしていたのが理由で)スキップしたので、手作業で書き変えた。(後から思えば上書きして修正する方が楽だったかも)

起動するために書き換えたのは以下のパラメータでした。

  • SSLSessionCache
  • SSLMutex

あと、SSLCertificateChainFile の古い書式を受け付けなくなっていて、openssl x509 で以下のように再生成したところ、正常に読み込まれるようになりました。

# openssl x509 -in ca-cert.pem -out ca-cert-new.pem
# diff ca-cert.pem ca-cert-new.pem
1c1
< -----BEGIN TRUSTED CERTIFICATE-----
---
> -----BEGIN CERTIFICATE-----
23c23
< -----END TRUSTED CERTIFICATE-----
---
> -----END CERTIFICATE-----

Redmine が動作していない

Apache は動作しているが、Redmine が動作していない。見ると redmine の更新がうまくいっていない。

# dpkg -l | grep redmine
rc  redmine                                   1.4.4+dfsg1-2+deb7u1          all          flexible project management web application
ii  redmine-pgsql                             3.0~20140825-5                all          metapackage providing PostgreSQL dependencies for Redmine
# apt-get install redmine
# dpkg -l | grep redmine
ii  redmine                                   3.0~20140825-5                all          flexible project management web application
ii  redmine-pgsql                             3.0~20140825-5                all          metapackage providing PostgreSQL dependencies for Redmine

それでも動かないので、passenger の状態を確認すると、空っぽで Redmine の登録がうまくいっていないように見える。

# passenger-status 
Version : 4.0.53
Date    : 2015-04-27 09:37:53 +0900
Instance: 28134
----------- General information -----------
Max pool size : 6
Processes     : 0
Requests in top-level queue : 0

----------- Application groups -----------

まずは Passenger のログレベルを変える。Passenger の設定ファイル(/etc/apache2/mods-enabled/passenger.conf)の PassengerLogLevel を 2 にする。

Redmine の設定が見当たらなかったので VirtualHost の中に Redmine の設定を記述する。

        <Directory /var/www/redmine>
                RailsEnv production
                RailsBaseURI /redmine
                PassengerResolveSymlinksInDocumentRoot on
                AllowOverride all
                Options -MultiViews
        </Directory>

こんどは Passenger が動作したが、エラーとなっている。

Permission denied @ rb_sysopen - /etc/redmine/default/database.yml (Errno::EACCES)
  /usr/share/redmine/Gemfile:54:in `read'
  /usr/share/redmine/Gemfile:54:in `eval_gemfile'
  /usr/lib/ruby/vendor_ruby/bundler/dsl.rb:32:in `instance_eval'
  /usr/lib/ruby/vendor_ruby/bundler/dsl.rb:32:in `eval_gemfile'
  /usr/lib/ruby/vendor_ruby/bundler/dsl.rb:10:in `evaluate'
  /usr/lib/ruby/vendor_ruby/bundler/definition.rb:25:in `build'
  /usr/lib/ruby/vendor_ruby/bundler.rb:154:in `definition'
  /usr/lib/ruby/vendor_ruby/bundler.rb:117:in `setup'
  /usr/lib/ruby/vendor_ruby/bundler/setup.rb:17:in `'
  /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
  /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:263:in `block in run_load_path_setup_code'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:366:in `running_bundler'
  /usr/lib/ruby/vendor_ruby/phusion_passenger/loader_shared_helpers.rb:261:in `run_load_path_setup_code'
  /usr/share/passenger/helper-scripts/rack-preloader.rb:100:in `preload_app'
  /usr/share/passenger/helper-scripts/rack-preloader.rb:158:in `'
  /usr/share/passenger/helper-scripts/rack-preloader.rb:29:in `'
  /usr/share/passenger/helper-scripts/rack-preloader.rb:28:in `
'

パーミッションを確認すると、以下のように問題なさそうに見える。

# ls -l /etc/redmine/default/database.yml
-rw-r----- 1 root www-data 159 Aug 16  2014 /etc/redmine/default/database.yml
# ls -l /usr/share/redmine/config/environment.rb 
-rw-r--r-- 1 www-data root 586 Jul 11  2014 /usr/share/redmine/config/environment.rb

Passenger の設定に以下を追加してやると動作するようになった。

  PassengerUserSwitching on
  PassengerDefaultUser www-data


スポンサーサイト
Linux | 03:24:02 | トラックバック(0) | コメント(0)
Debian 8.0 へのアップグレード (part 1)

Debian 8.0 (jessie) がリリースされたので、HP MicroServer Gen8 で動作している Debian サーバを更新した。

更新作業

更新作業はリリースノートに書かれている通りで、忘れずにバックアップを取ってから作業開始する。

openvswitch の更新で止まる

アップグレード手順(apt-get dist-upgrade)が以下で止まってしまった。

Setting up openvswitch-switch (2.3.0+git20140819-3) ...
Installing new version of config file /etc/init.d/openvswitch-switch ...
Installing new version of config file /etc/logrotate.d/openvswitch-switch ...
cat: /sys/module/openvswitch_mod/srcversion: No such file or directory
cat: /sys/module/openvswitch_mod/version: No such file or directory

止まったプロセスを調べてみると以下のようなプロセスが止まっていて、ovs-appctl が無応答になっていたためだった。

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0     0 53121 49661  20   0   4316   688 -      S+   pts/4      0:00 /bin/sh /var/lib/dpkg/info/openvswitch-switch.postinst configure 1.4.2+git2012
0     0 53129 53121  20   0   4316   708 -      S+   pts/4      0:00 /bin/sh /usr/sbin/invoke-rc.d openvswitch-switch restart
0     0 53146 53129  20   0   4316   784 -      S+   pts/4      0:00 /bin/sh /etc/init.d/openvswitch-switch restart
0     0 53169 53146  20   0   4448   820 -      S+   pts/4      0:00 /bin/sh /usr/share/openvswitch/scripts/ovs-ctl restart --system-id=random
0     0 53171 53146  20   0   4216   576 -      S+   pts/4      0:00 tee -a /var/log/openvswitch/ovs-ctl.log
1     0 53191 53169  20   0   4448   236 -      S+   pts/4      0:00 /bin/sh /usr/share/openvswitch/scripts/ovs-ctl restart --system-id=random
0     0 53192 53191  20   0  22388  1576 -      S+   pts/4      0:00 ovs-appctl version
0     0 53193 53191  20   0  13208   648 -      S+   pts/4      0:00 sed 1q

停止していたのはスクリプト(/usr/share/openvswitch/scripts/ovs-ctl)の以下の箇所で、原因は突き止めていないが、バージョンの不一致による誤動作だろう。

    292 save_ofports_if_required () {
    293     # Save ofports if we are upgrading from a pre-1.10 branch.
    294     case `ovs-appctl version | sed 1q` in
    295         "ovs-vswitchd (Open vSwitch) 1."[0-9].*)
    296             action "Saving ofport values" ovs_save save-ofports \
    297                 "${script_ofports}"
    298             ;;
    299     esac
    300 }

待てばいつかタイムアウトするのかもしれないが、それほど待つ時間もないので、ovs-appctl のプロセスを kill して先に進んでもらった。

シリアルコンソールが動作しない

シリアルコンソール(iLOのVSP)が動作しなくなっていた。理由は簡単で inittab で指定していた getty 設定が sytemd では動作しないせいだ。以下のように systemd の設定を行うことで VSP 用の getty が起動した。

# ln -sf /lib/systemd/system/serial-getty\@.service /etc/systemd/system/getty.target.wants/getty\@ttyS1.service 
# systemctl start getty\@ttyS1.service

起動後にネットワーク(Open vSwitch)が動作しない

なぜか、起動後にネットワーク(Open vSwitch)が動作しなくなっていた。起動後に service networking restart で再起動させれば動作するようになる。

openvswitch のログ (/var/log/openvswitch/ovs-vswitchd.log) に以下のように気になる警告を発見した。

2015-04-26T14:34:52.948Z|00037|dpif|WARN|system@ovs-system: failed to add eth0 as port: Device or resource busy
2015-04-26T14:34:52.948Z|00038|dpif|WARN|system@ovs-system: failed to add eth1 as port: Device or resource busy
2015-04-26T14:35:39.016Z|00039|dpif|WARN|system@ovs-system: failed to add eth0 as port: Device or resource busy
2015-04-26T14:35:39.016Z|00040|dpif|WARN|system@ovs-system: failed to add eth1 as port: Device or resource busy

busy という事は、Open vSwitch の初期化の前に何か動いていると推測して、ネットワークの設定を見直す。このマシンは元々通常の bonding 構成から Open vSwitch 化していて、旧 bonding の設定が残っていたので、それらをきれいに消してやるとネットワークは起動するようになった。

Open vSwitch の bonding を使うので、bonding モジュールは無効化してあるが、ゴミ設定が残っていると悪さをしてしまうようだ。

しかしまだ、なぜか bonding の経路でパケットが届かないケースがあり、またネットワークの起動で以下のように非常な時間がかかっている。

# systemd-analyze blame | head -3
         43.257s networking.service
          3.328s postgresql@9.1-main.service
          2.850s postgresql@9.4-main.service

ちょっと待て、postgresql が2つ見えるぞ!



続きを読む >>
Linux | 19:31:35 | トラックバック(0) | コメント(0)
ECS LIVA の諸問題解決 (part 2)

ECS LIVA (LIVA-B3-2G-32G) の問題対応の続きで、WiFi がうまく動作しない問題への対応です。

sdhci の問題

どうも https://bugzilla.kernel.org/show_bug.cgi?id=88061 のような問題があるようなので、以下のように systemd に対応を組み込んだ。

Fedora 20 ではこれである程度動作するようになったが、Fedora 21 にアップグレードしたらまた動かなくなったので、再び調査と試行錯誤をすることになった。いずれにせよ brcmfmac 自体は動作しているように見えるが、うまく接続できない。

modprobe の blacklist 設定 (/etc/modprobe.d/brcmdmac.conf を作った) で組み込みを無効化し、

blacklist brcmfmac
blacklist brcmutil

systemd から呼び出されるスクリプトを /usr/lib/systemd/scripts/sdhci-acpi-config.sh に用意した。

#!/bin/sh
echo on > /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control
logger -p local7.info -t "sdhci-acpi-config" "loading brcmfmac modules"
modprobe brcmfmac
logger -p local7.info -t "sdhci-acpi-config" "modprove finished"

以下のような systemd の設定ファイルを /usr/lib/systemd/system/sdhci-acpi-config.service に用意して、wpa_supplicant の前に組み込まれるようにした。

[Unit]
Description=sdhci-acpi config script

[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/scripts/sdhci-acpi-config.sh

[Install]
WantedBy=wpa_supplicant.service

で、systemctl enable sdhci-acpi-config.service で有効化させた。

それでも正常に動作しなかったので、もっと速い段階で制御するために、以下のように modprobe で仕込むように変えてみた。

# blacklist brcmfmac
# blacklist brcmutil
install brcmfmac echo on > /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control; /sbin/modprobe --ignore-install brcmfmac

どっちの方法でも結果は同じっぽい。(最終的に systemd のスクリプトは使うのを止めている)

wpa_supplicant と DHCP の解析

ネットワークの設定を一通り見直し、細かい間違い(と考えられる箇所)は修正したのだが、それらは無関係で、やっぱりうまく動作しない。

解析のために wpa_supplicant の動作を詳細に調べるために設定ファイル(/etc/sysconfig/wpa_supplicant)の OTHER_ARGS にデバッグ出力のオプション -dd とタイムスタンプ出力のオプション -t を追加した。

OTHER_ARGS="-dd -t -P /var/run/wpa_supplicant.pid"

DHCP(dhclient) と wifi のデバイス制御 (iw) のデバッグ出力をさせるためにネットワークインタフェースの設定ファイル(/etc/sysconfig/network-scripts/ifcg-????)に以下を追加

DHCLIENTARGS=-d
IW="iw --debug"

で、ログを調べていったところ、wpa_supplicant がうまく動作しなくなっている様子。wpa_supplicant の設定を変更したり試行錯誤してみたが、どうも動かない。

原因は NetworkManager.service を止めて、旧来の network.service を使ってネットワーク設定をしていたのだが、wpa_supplicant は NetworkManager から dbus 経由で制御するように Fedora 21 では組み込まれていたためと推測。

あまり時間をかけるのがイヤだったので、WiFi の接続には NetworkManager を使うことにした。

固定の ifcfg-p4p1 ではルーティング等の細かい制御をしたかったので NM_CONTROLLED=no を記述して、NetworkManager では無視されるようにした。

で、NetworkManager で wifi の設定だけ行うと、(若干の試行錯誤は必要だったが)動作するようになった。

DHCPの固定IPアドレス割り当てが動作しない (もはや ECS LIVA とは関係ない)

WiFi の接続は出来るようになったが、割り当てられている IP アドレスが想定と違うことに気付いた。この WiFi アクセスポイントでは MAC アドレスにより固定アドレスが割り当ててあったはずなのに変だ。

試しに DHCP Client ID を直接指定したところ、固定 IP アドレスで割り当てられるようになった。デフォルト動作が以前と違う?

パケットをキャプチャして確認したところ、DHCP Client ID を指定しないデフォルト動作は以下のようになっていて、これをうちのWiFiルータは認識できていないようだ。

Option: (61) Client identifier
  Length: 19
  DUID type: link-layer address plus time (1)
  Hardware type: Ethernet (1)
  Time: 481850549
  Link-layer address: 24:0a:64:??:??:??

DHCP Client ID を設定として指定した場合はこうなる

Option: (61) Client identifier
  Length: 7
  Hardware type: Ethernet (0x01)
  Client MAC address: Azurewav_??:??:?? (24:0a:64:??:??:??)

DHCP Client ID を指定した場合、NetworkManager の設定ファイル(/var/lib/NetworkManager/dhclient-wlan0.conf)は以下のように記述されていた。

send dhcp-client-identifier 01:24:0a:64:??:??:??; # added by NetworkManager

NetworkManagerを使うべきか?

まだ答えが出ていない

  • WiFi の接続に失敗する場合、タイムアウトまでブートが滞ってしまうので NetworkManager を使った方が有利だ。
  • Fedora 21 では基本的に WiFi は NetworkManager を使うように初期設定されているように見受けられる。それが無難な方法なんだろう。

宿題

  • wpa_supplicant が動かなかった件の原因までは追いかけていない。
  • WiFi の問題は解決したが、network.service の起動時の初期化がまだ遅く見える。何か別の問題がひそんでいるのかも。


Linux | 09:52:01 | トラックバック(0) | コメント(0)
ECS LIVA の諸問題解決 (part 1)

ECS LIVA のコンソール問題

ECS LIVA (LIVA-B3-2G-32G) を購入して Fedora 20 を入れて遊んでいたのだが、以下のような問題があった。

  • VGAを繋いでいない場合、ブート時に grub で止まってしまう
  • 起動時の WiFi 接続がうまく動作しない

問題をひとまず解決することができたのでメモしておく。

問題解析の前に

問題を解析する前にインストールしていた Fedora 20 を Fedora 21 にアップデートした。原因が判ったときに「それ最新版では直ってるよ!」というのは悲しいし、時間の無駄なので。

Fedora 20 から Fedora 21 へのアップグレード手順は https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum に書かれている通りで作業自体は簡単だ。

# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-21-$(uname -i)
# yum update yum
# yum clean all
# yum --releasever=21 distro-sync --skip-broken --setopt=protected_multilib=false
# yum install system-release-server
# dracut --force --add-drivers "mmc_block sdhci_acpi" /boot/initramfs-`uname -r`.img `uname -r`
# restorecon -R /
# yum autoremove

一般的ではないドライバを入れているので initramfs は再生成しておいた。(後から思えば yum が勝手にやってくれていたかもしれないが)

※ アップデート作業自体は問題なく終わったが、Fedora 20 と Fedora 21 の設定差分に由来する問題で後からWiFiの不可解な動作に苦しむことになった。

VGA を繋いでいない場合に起動できない問題への対応

何度も再起動やVGAを抜き差ししてうんざりしたが、起動できない条件を調査すると grub2 の設定(/etc/default/grub) で GRUB_TERMINAL_OUTPUT に console が含まれている場合にのみ発生することが判明。console を vga_text にしてもダメ。

ということで、苦肉の策として GRUB_TERMINAL_OUTPUT は serial に設定して使うことにした。これならgrub は使えないが問題なく起動する。内部的には serial デバイスは存在するので grub は騙されてくれるようだ。

USB-serial を利用する

ついでにサーバとして使うので VGA の代わりに USB serial を設定することにした。(grub は USB serial に対応していないのでそこでは使えないが・・・)

USB-serialのドライバを起動時に組込むために /etc/dracut.conf の追加ドライバに pl2303 を追加して、initrd を再生成しておく。

add_drivers+="mmc_block sdhci sdhci-pci pl2303"

grub2 の設定(/etc/default/grub) の GRUB_CMDLINE_LINUX に "console=tty console=ttyUSB0,115200n8" を追加すれば、起動時に USB serial が繋がっていれば出力されるようになる。

さらに、USB serial を常時繋いでいたくはないので、以下の systemd 設定で USB serial を差したら getty が起動されるようにした。

ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants getty@ttyUSB0.service

これで使えるようになった!と思ったら、これだと syslog に以下のようなエラーログが延々と出力さてしまう。

Apr 10 06:51:54 flora systemd: getty@ttyUSB0.service has no holdoff time, scheduling restart.
Apr 10 06:51:54 flora systemd: Stopping Getty on ttyUSB0...
Apr 10 06:51:54 flora systemd: Starting Getty on ttyUSB0...
Apr 10 06:51:54 flora systemd: Started Getty on ttyUSB0.

syslogが無用なログで埋め尽くされてしまうのは困るので、USB-serial が刺さっている場合にだけ動作するように改善する。まず、/etc/rc.d/rc.local で起動時に USB-serial が存在しなかった場合は止めるようにした。

if [ ! -e /dev/ttyUSB0 ]; then
  systemctl --no-block stop serial-getty@ttyUSB0
fi

で、udevでUSB-serial が繋がれた場合に getty の制御がスタートするようにした。/etc/udev/rules.d/usb-serial.rules に以下のような記述を行った。udev の処理では長時間ブロックしてはいけないので、systemctl には --no-block オプションを指定して完了を待たないようにする。

ACTION=="add", KERNELS=="ttyUSB*", SUBSYSTEMS=="usb-serial", RUN+="/usr/bin/systemctl --no-block start serial-getty@$kernel"
ACTION=="remove", KERNELS=="ttyUSB*", SUBSYSTEMS=="usb-serial", RUN+="/usr/bin/systemctl --no-block stop serial-getty@$kernel"

宿題

GRUB_TERMINAL_OUTPUT に console が含まれている場合に問題が発生することは切り分けできているが、根本原因が判っていない。時間が取れたら調べてみよう。



Linux | 09:10:48 | トラックバック(0) | コメント(0)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。