KDMでのログインが出来ない
openSUSE12.2がリリースされたので、手元にある12.1のマシンをアップデートしてみた。
更新終わってから再起動したら、どうもうまくログイン出来なくなってしまったので、その時の状況と解消までのメモ。
状況
KDMのログインマネージャから、パスワードを入力してログイン。無事にログイン成功して処理が進んだように見えるが、少しするとまたログイン画面に戻ってきてしまう。
パスワードの入力を誤ったかとも思ったが、意図的に間違ったパスワードを入力するとログイン失敗した旨のメッセージがでてくるので、パスワードに問題があったわけでは無さそう。だがログイン出来ない。
調査
Xの起動に問題があるのか？
ログイン画面からctrl+alt+F1でテキストモードへ移動。
問題の、KDMからログイン出来ないユーザーで入り、startxを実行してみる。
$ startx --------------------------------------------------------------------------- xauth: file /home/warabanshi/.serverauth1234 does not exist Fatal server error: cannot move old log file "/var/log/Xporg.0.log" to "var/log/Xorg.0.log.old" xinit server error --------------------------------------------------------------------------- and drops me back to the prompt. Then I get some info that says: "xinit failed. /usr/bin/Xorg is not set uid" (could this be the problem?) "if so either use a display manager or adjust /etc/permissions.local"
これについては/usr/bin/Xorgの実行権限が足りない模様。
なので、ひとまずrootユーザーでstartxを試してみたら無事にXが起動。続いて、
# chmod 4755 /usr/bin/Xorg
としてスティッキービットを付けてから一般ユーザーでstartxを試してみたら、これも無事に起動。
これで大丈夫かなーと思って、この状態で再起動。KDMからログインを試してみたけど状況は改善されず。KDMからログインするのとCLIからstartxするのは色々扱いが違うんですね･･･。
KDMからとstartxでは何が違うのか？
こちらをちょっと見てみると、どうもstartxはxinitのwrapperのようで。
どうしたものか･･･
さて、ここでKDMからログインしようとしていたユーザーのホームディレクトリを見て、ログイン処理毎に更新されているファイルを探してみると.xsession-errorsなるファイルが。中身には
/etc/X11/xim: Checking whether an input method should be started. sourcing /etc/sysconfig/language to get the value of INPUT_METHOD INPUT_METHOD is not set or empty (no user selected input method). Trying to start a default input method for the locale en_US.UTF-8 ... Checking for a default input method in /etc/X11/xim.d/en/ sourcing /etc/X11/xim.d/en/40-ibus ... /etc/X11/xim.d/en/40-ibus started sucessfully OpenSSL version mismatch. Built against 1000005f, you have 1000103f
との事。最後の行がもう核心に触れている訳ですが、せっかくなのでもうちょっと追いかけてみる。
なんか /etc/X11 辺りで処理してそうなので、ここらで .xsession-errors というファイルを作っている箇所を探してみると
$ grep -r .xsession-errors /etc/X11 /etc/X11/xdm/Xsession:for errfile in "$HOME/.xsession-errors" \
ナイスな反応が。
/etc/X11/xdm/Xsessionをのぞいてみると、exec_login()なんてのが見受けられ、中では
case "${cmd}" in
csh|tcsh)
exec -l -a ${cmd} ${shell} -c 'exec $argv:q' "${@}" ;;
bash*|zsh)
exec -l -a ${cmd} ${shell} --login -c 'exec "${@}"' - "${@}" ;;
dash|pdksh|*pcksh|ksh*)
exec -l -a ${cmd} ${shell} -l -c 'exec "${@}"' - "${@}" ;;
*)
exec -l -a ${cmd} ${shell} -c 'exec "${@}"' - "${@}" ;;
esacなんてことが為されている。自分はbashなので、ここで実行されている命令は
exec -l -a bash /bin/bash --login -c 'exec /etc/X11/xdm/sys.xsession' - /etc/X11/xdm/sys.xsession
となる。
xdmなんてキーワードが出てきた辺り、ログインマネージャに近づいた感じがしますね。
次はこのsys.xsessionをのぞいてみると
if test "$usessh" = yes -a -d "$HOME/.ssh" && sshagent=$(type -p ssh-agent) ; then
とかなんとかで、sshがある場合には専用の処理が入るわけですね。
この先については冗長なので割愛。
ここで出てきたssh。実は先に.xsession-errorsにて
OpenSSL version mismatch. Built against 1000005f, you have 1000103f
なんて事を言われてたわけですが、どうもsshの実装時に想定されていたopensslのbuildを今回openSUSE12.2へ更新した事で新しく入ったopensslが上回ってしまった模様。ちなみにbuild 1000005fはOpenSSL 1.0.0eに該当します。
今回の更新で入ったopensslは1.0.1c。この差によってssh周りが正常に機能せず、それがログイン時の処理にも影響が及ぼしていたわけですね。
解決
一番スマートな解決としてはリポジトリにあるopensshの最新版がその辺のバージョンをちゃんとしてくれることではありますが、悠長に待つのもやってられない。かと言ってパッケージでまとめてあるこの辺を自分でコンパイルしたopensshで上書きしたら、次回の更新時に変な事になりそうで嫌だ。
という訳で、一時的に二つのバージョンを共存させることにしました。
後でパッケージのアップデートが出たら、今回入れたopensshは削除する方向で。
とりあえずはインストール
$ tar zxf openssh-6.0p1.tar.gz $ cd openssh-6.0.1 $ ./configure --prefix=/usr/local/openssh $ make # make install
あとはこのopensshが優先的に使われるようになっていればOKということで
$ vi ~/.bashrc export PATH=/usr/local/openssh/bin:/usr/local/openssh/sbin:$PATH
を追加してやることで、無事起動するようになりましたとさ。
