The Road to Genecialist!

先週22日にWindows 7の発売と同時に公開されたXP Modeを入れてみました。

個人的にXPでなければ動かないアプリケーションを持っているわけではないので、全く必要性は感じられませんが、何となく入れてみました(しまった、お遊びならばVMのWinodws 7に入れるんだった・・・)。

マイクロソフトのサイトWindows XP Mode および Windows Virtual PCからWindows XP ModeとWindows Virtual PCをそれぞれダウンロードし、インストールします。
Windows Virtual PCをインストールしたところでマシンの再起動が必要になります。

再起動後、スタートメニューのWindows Virtual PCにあるWindows XP Modeをクリックすると、5分ほどのセットアップの後にVirtual PCにインストールされたWindows XPが起動します。

このままではアプリケーションだけを実行することはできません。全ユーザー対象のスタートメニュー(C:\Documents and Settings\All Users\スタート メニュー)に呼び出したいアプリケーションのショートカットを作成し、XPにログインし直せばWindows 7から直に呼び出すことができるようになります。

IE6を実行している画面。


ただ、見てわかるとおり、XPの言語バーが出ております。つまりこのIE上ではIMEを使わなければならないわけです。Windows 7ではATOKを使っているのにもかかわらず・・・
ThinkPadのスクロールも効きません・・・

リモートデスクトップのアプリケーション画面だけを使っているような感じです(RemoteAppの使い心地がこんなのかもしれないな)。

ウィルスソフトの設定ではVirtual PCのvhdファイルを対象外とすること、また、Windows XP ModeのXPに別途ウィルスソフトをインストールすることが推奨されています(なぜならXPもネットにつながる設定になっているから)。

こう考えると、個人PCにWindows XP Modeをインストールし、旧来アプリケーションを導入して使用し続けるよりも、部署ごと、島(チーム)ごとに余りPCにXPを入れて使い回す方が便利な気がしてならない。

XP向けアプリケーションをWindows 7向けに改修している開発者にとっては結構便利なツールだと思う。

今日ふと思いました。

/usr/X11R6/lib/X11/app-defaults/XScreenSaverを編集すればスクリーンセーバーの動きを変えられるけれども、GUIで設定変更したときにこのファイルが書き換えられるのか？と。

たとえば、ユーザープロファイルはベースのファイル/etc/skel/.bash_profileがあって、ユーザーの追加をすると新規ユーザーにコピーされる仕組みになっています。その後、各ユーザーが自分のホームディレクトリ下にある.bash_profileをいじれば個人個人の設定となります。

そこで、GUIツールを使用してスクリーンセーバーの設定を変更した後にXScreenSaverを確認してみましたが、全く変更がありませんでした。見間違いとかではなく、ファイル上ではパスワードロック設定がFalseになっていても、GUIのSCREENSAVER設定ツールを開くとTrue(チェックボックスがオン)になっているのです。もちろん設定を変更して保存してもファイルへの更新はありませんでした。

じゃあ、どこに設定を保存しているのか？

探しました。GUIツールで変更してからすぐに下記コマンドを実行して変更されているファイルを洗い出しました。

find / -amin -1

すると、ホームディレクトリ下に.xscreensaverというファイルが追加されていました。GUIツールを使う前までは存在していなかったファイルです。開いてみると、GUIで設定した項目が・・・

XScreenSaverではパスワードロックがFalseになっていても、.xscreensaverでTrueになっていれば有効になるのです。.bash_profileの動きと同じ感じです。ログイン後、ホームディレクトリ下の.xscreensaverを探し、ファイルがあればその設定で動く。なければ大元のXScreenSaverを読み込む。

こうなると、いくらこちらがスクリーンセーバーの設定をしようにも、ユーザーがGUIツールを触ってしまうと動きが変わってしまう。

強引にスクリーンセーバーをアンインストールする前にGUIツールの使用を制限する事を考えた。

このGUIツールは/usr/X11R6/bin/xscreensaver-demoというファイルです。ツールバーのSCREENSAVERのPROPERTYを見てもこのファイルを実行しているだけです。


ですので、実行権限をはずしてしまいます。

-rwxr-xr-x 1 root root 181080 Nov 21 2004 /usr/X11R6/bin/xscreensaver-demo

を

-rwxr-xr-- 1 root root 181080 Nov 21 2004 /usr/X11R6/bin/xscreensaver-demo

と変更してしまいます。こうする事により、一般ユーザーは実行不可能となります。


後は、設定する際に各ユーザーのホームディレクトリ下にあるかもしれない.xscreensaverファイルを勝手に消してしまえばミッション終了です。

これでスクリーンセーバー問題は終了で良いかと思います。

本で5種類に分類された金融機関。四つ目はその他の金融機関。その他の金融機関には消費者金融会社やクレジットカード会社が含まれます。銀行とは違い、自己資金で融資やリースを行うため、ノンバンクとも呼ばれます。

最近はバックに銀行がついている消費者金融会社がとても高い認知度を持っています。CMなどを見ると気軽に借りられそうな雰囲気ですが、やっぱりサラ金なんですよね・・・

リース会社もここに分類されます。リースには大きく分けてファイナンス・リース契約とオペレーティング・リース契約の二種類があります。ファイナンス・リースは機器の購入代金を肩代わりしてもらい、毎月使用料金を払う形。オペレーティング・リースは最近自動車会社で設定のある、二年契約で車を買えるというあの形です。

レンタルという言葉もあるが、違う物のようです。
・リースは新品購入して契約者に貸し出すが、レンタルは業者がすでに所有している物を貸し出すので新品とは限らない。
・リースの方がレンタルよりも期間が長く、途中で解約できない。
等の違いがあるそうです。

職場のコピー機は機種が変わると新品が来ますものね。あれはリースだからだったんですね。スキー場で借りる板はコンディションがひどい物が多々見られますが、あれはレンタルだから仕方ないのか・・・

RHEL4からREHL5にバージョンアップを考えているので設定を確認しています。

ログインに三回失敗するとアカウントロックされる設定で少し悩みました。というのは、RHEL4のpamモジュールとRHEL5のモジュールでバージョンが異なり、使い方が変更されているのです。

ログインの失敗回数を数えるにはpam_tally.soモジュールを使用します。

RHEL4では失敗の許容回数を指定する"deny="オプションをaccountで指定していたのですが、RHEL5になってからはauthで指定するように変更になっています（"deny="だけでなく、ほとんどがauthに移動されています）。

また、今まであまり気にしなかった各行の順番でも動作が変わるのです（ここは勉強しないといけないですね。モジュール間で値をやりとりしているのでしょう）。

何気なくpam_tally.soの行をauthの最後に付け加えていたのですが、ここでは何度ログインに失敗しようとも、正しいパスワードを入力すればログインできてしまいます(失敗カウントは増えていきます)。
正しくはpam_unix.soの前に記述する必要があります。

"
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth       required pam_env.so
auth       required pam_tally.so onerr=fail deny=3
auth       sufficient pam_unix.so nullok try_first_pass
auth       requisite pam_succeed_if.so uid >= 500 quiet
auth       required pam_deny.so

account    required pam_unix.so
account    sufficient pam_succeed_if.so uid < 500 quiet
account    required pam_permit.so

password  requisite pam_cracklib.so try_first_pass retry=3
password  sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password  required pam_deny.so

session   optional pam_keyinit.so revoke
session   required pam_limits.so
session   [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session   required pam_unix.so
"

RHEL5で確認

ちなみにRHEL3/4での設定では下記の通りになります。"deby="オプションの行はpam_unix.soの前に記述されていなくても有効になります（こっちではaccountで設定）。

とはいえ、RHEL5ではpam_unix.soの前でしか有効にならなかったし、Securing and Hardening Red Hat Linux Production Systemsというドキュメント内のLocking User Accounts After Too Many Login Failuresセクションで示されている例でもpam_unix.soの前に記述されているのでそのように設定しています。

RHEL3(LDAPが入っているのでちょっと異なる)
"
]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_tally.so deny=2 no_magic_root reset

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so
"

RHEL4
"
]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     required      /lib/security/$ISA/pam_tally.so deny=3 no_magic_root reset
password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type= difok=3 minlen=8 dcredit=-1 lcredit=-1
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=12
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
"

RHEL3/4/5で確認

P.S.
複数スペースが入る場合の書き方が難しいです。スペースが複数個あるとNucleusが自動的に一つに集約してくれてしまいます・・・

Linuxのスクリーンセーバーが解除できないで書きましたが、xscreensaverは依存関係が多くてアンインストールするのを断念しました。

どれくらい依存関係があるのかを確認しました。

まずRHEL4
[root@RHEL4-WAS01 ~]# rpm -aq | grep screen
xscreensaver-4.18-5.rhel4.2
[root@RHEL4-WAS01 ~]# rpm -e --test xscreensaver-4.18-5.rhel4.2
error: Failed dependencies:
        xscreensaver is needed by (installed) control-center-2.8.0-12.i386
[root@RHEL4-WAS01 ~]# rpm -e --test xscreensaver-4.18-5.rhel4.2 control-center-2.8.0-12.i386
error: Failed dependencies:
        control-center >= 2.0 is needed by (installed) gnome-volume-manager-1.1.0-5.i386
        control-center is needed by (installed) gnome-session-2.8.0-5.i386
[root@RHEL4-WAS01 ~]# rpm -e --test xscreensaver-4.18-5.rhel4.2 control-center-2.8.0-12.i386 gnome-volume-manager-1.1.0-5.i386 gnome-session-2.8.0-5.i386
[root@RHEL4-WAS01 ~]#

RHEL4からxscreensaverを(きれいに)アンインストールするには
control-center
gnome-volume-manager
gnome-session
の3つを同時にアンインストールする必要があります。

次にRHEL3で確認しました。すると、少し結果が異なりました。
[root@RHEL3 root]# rpm -aq | grep screensaver
xscreensaver-4.10-6
[root@RHEL3 root]# rpm -e --test xscreensaver-4.10-6
error: Failed dependencies:
        xscreensaver is needed by (installed) control-center-2.2.0.1-13
[root@RHEL3 root]# rpm -e --test xscreensaver-4.10-6 control-center-2.2.0.1-13
[root@RHEL3 root]#

RHEL3ではxscreensaverをアンインストールするときにcontrol-centerのみを一緒に消せば良いのです。でも、RHEL3にしろ4にしろ後からアンインストールするとなると面倒くさいので(というよりも、必要な物まで消さなければならないので)、初期導入の時に入れないようにすべきだと思って確認しました。

RHEL3：
今日はインストールCDが手元になかったので確認できませんでした。

RHEL4：
ソフトウェアの選択画面から確認できると思ったのですが、xscreensaverが見あたりませんでした。
textベースでのインストールだと、ソフトウェア選択時にEverythingを選択して詳細を開くとxscreensaverのチェックをはずすことができるのですが、これがどの小分類に入っているのかはわからなかったです(無かった)。本気でインストールを阻止するのであればまず全選択をし、そこから個別に必要不必要を分けていくしかないのかと（そしておそらくRHEL3においても同じかと）・・・

RHEL5：
インストールするソフトウェアを選択する画面で、"Customize now"を選択してNextをクリック。次の画面ではそのままの状態でOptional packagesをクリック。現れたウィンドウ"Packages in GNOME Desktop Environment"のリスト中ちょうど真ん中当たりにgnome-screensaverがあるのでチェックをはずしてCloseをクリック。
これでスクリーンセーバーはインストールされなくなります。

ntp.confの実験でntpの時刻設定間隔のmaxpollを20に設定してからだいぶ経ちます。

設定したのが9月15日。polling 17になったのが18日。もうすぐ一ヶ月が過ぎようとしているが、これ以上あがりそうにありません。
あれからずっとpolling 17ですが、やっぱりずれが数十ミリ秒。一番正確なときは0.6ミリ秒でした。

結局の所、maxpollの最長は17ということなのでしょう。でも、現実的にはもう少し頻繁に時刻同期をするべきなのでしょうね。

RHEL3/4で確認(中)

XDMCP接続でLinuxサーバーに接続してるのですが、スクリーンセーバーが実行された後、パスワード解除が出来ないという問題が発生しました。

パスワードロックがかかりました。


パスワードを入力します。


認証に失敗し、パスワード入力欄に"Sorry!"と表示されます。


デフォルトでの設定は、アイドル時間が10分あるとスクリーンセーバーが起動し、解除するにはパスワードを入力する必要があります。
スクリーンセーバーの設定については/usr/X11R6/lib/X11/app-defaultsにあるXScreenSaverに記述されています。

スクリーンセーバー起動時間は
*timeout:00:10:00

パスワードロックがかかる設定については
*lock:True

この現象が発生したとき、

messagesには

Oct 13 11:23:31 hostname pam_tally[30076]: Error opening /var/log/faillog for update
Oct 13 11:23:33 hostname pam_tally[30076]: Error opening /var/log/faillog for update
Oct 13 11:23:33 hostname xscreensaver(pam_unix)[30076]: authentication failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=root
Oct 13 11:23:33 hostname xscreensaver[30076]: pam_ldap: error trying to bind as user "uid=root,ou=Users,dc=test-domain,dc=com" (Invalid credentials)

secureには

Oct 13 11:23:35 hostname xscreensaver[30076]: FAILED LOGIN 2 ON DISPLAY "123.456.789.123:0.0", FOR "adminuser"

と書かれますので/var/log/faillog(ログイン失敗回数を記録するファイル)へのアクセスに失敗していると思われます。
secureの"FAILED LOGIN 2 ON"のカウントは失敗するごとに増えていきますが、pam_tallyのカウントとは違うようです。

いろいろ調べてみるとsystem-authのauthに書いているpam_tally.soの中で、"onerr=fail"を消すと動くというので試してみるとパスワード解除が出来るようになりました。
この"onerr=fail"はパスワードファイル等へのアクセスに失敗した場合には認証失敗とする意味ですので、今回の事象ではまさにドンぴしゃり！

ただ、これをはずしておくと通常のログイン時に認証が弱くなってしまいそうなのでつけておきたいオプション。

今回は対処療法的に、スクリーンセーバーの設定でパスワードロックがかからないようにします。前述ファイルの*lockをFalseにすればスクリーンセーバーが起動してもロックはされなくなります。
また、Linux側でスクリーンセーバーがかからないように*timeoutの時間も24:00:00にすることにしました。Linux側ではなく、XDMCPで接続している元のWindowsでスクリーンセーバーとパスワードロックがかかれば良いという話でまとまりましたので。
今回思い切ってスクリーンセーバーをアンインストールしようとも考えたのですが、依存関係が多くてちょっと怖いのでやめました。本番システムだし。


ちなみに、今回の事象については下記に記載がありました。

Securing and Hardening Red Hat Linux Production Systemsというドキュメント内のLocking User Accounts After Too Many Login FailuresセクションのNOTEです。以下引用

Since the /var/log/faillog is owned by root and only root can write to the /var/log/faillog file, xscreensaver and vlock won't work correctly. Each time xscreensaver or vlock is executed as a non-root user, you won't be able to do an unlock since these programs can't write to /var/log/faillog. I don't have a good solution for that. I can only think of setting the SUID bits on these programs.


訳：
/var/log/faillogはroot所有でrootのみが書き込み可能なファイルですので、xscreensaverもしくはvlockは正常に動作しません。xscreensaverもしくはvlockがnon-rootユーザーで実行された場合、ロック解除をすることが出来ません。これらのプログラムが/var/log/faillogを変更することが出来ない為です。これについて解決策はありません。xscreensaverもしくはvlockにSUIDビットを設定すれば良いのではないかと考えています。

今回の事象はRHEL3/4で発生します。

今日は朝方の台風で大混乱の中、赤坂でのカンファレンスに参加してきました。

本当は12,000円だけど、メールマガジンに登録していたりするとただになる不思議なカンファレンスです。

私は開発の人間ではないので最初はあまり行く気はなかったのですが、英語の勉強がてら参加することにしました。

あまり考えずに受講セッションを決めていたので当日になるまでどんなセッションなのか全く知りませんでしたが、終わってみると4つのうち3つがアジャイル開発についてでした。

現場ではがちがちのウォーターフォール型の開発しかしていないので新しい知識を得ることができて良かったです。
これまではどちらかというと「XP？アジャイル？どうせポッと出てきて、そのうち消えるんでしょ」という人たちの一員だったわけですが、意識ががらりと変わりました。もちろん、発表されている事例というのは本当にうまくいったプロジェクト、もしくはうまくいった箇所を紹介しているのであって、失敗例もたくさんあるのだと思います。だから、頭から信じるわけではありませんが、でも、IBMやMicrosoft、その他の大企業の中でもアジャイル開発でうまくいっているという話を聞くと、やっぱり認識を変えられますよ。

最終セッションはアジャイル開発についてのパネルディスカッションだったのですが、日本のソフトウェア産業を元気にしたいという話が出ていました。3Kとか7kとか言われて久しいこの業界ですが、本当は楽しくてやりがいがあるはずだと私も思います。

パネラーの皆さんが「ソフトウェア産業＝人材派遣業という認識を変えたい」という気持ちがあるようなのでしばらく彼らの動きをウォッチしようかと思います。「ソフトウェア産業＝人材派遣業」という構図を知っていたのなら私はこの業界には絶対に入らなかったですから（自分たちで新しい物を作り出しているすばらしい会社がたくさんあるのは知っております）。

最後にアジャイル手法の一つであるスクラムを日本で普及させようとしている人と名刺交換をして、コミュニティに参加させてもらいました（知識全くのゼロなんですけど・・・）。カンファレンスに参加したら一人以上と名刺交換するという目標を久しぶりに達成できました。

Windows Server 2008のバックアップ・リカバリ～その一　バックアップで取得したバックアップファイルを使って、新しくサーバーをリカバリしてみます。

三回目は元のサーバーよりも小さなHDDに戻すパターンです。

新しくVMを作り(HDDは元のサーバーよりも小さい10GB)、バックアップファイルが保管されているHDDを接続します。
Windows Server 2008のインストールDVDを読み込ませ、インストールを開始する。
復元開始までの手順は最初にリカバリした手順（Windows Server 2008のバックアップ・リカバリ～その二　リカバリ～１．同じサイズのHDDに戻すパターン）と全く同じです。

リカバリを開始します。


プロセスが開始してから10秒ほどでリカバリ失敗のメッセージが表示されました。


ずっと作業が進んでいって最後でこのメッセージが出たらどうしようと思っておりましたが、そこまで変な仕様でないことがわかって一安心。
サーバーの設置は何度も経験があるけれども、リカバリってしたことがない（リカバリしなければいけない状況になることがまずないですから）。

もし、バックアップを取得したパーティションを新しいサーバーでは小さくしたいという要件があったら、バックアップ前かリカバリ後にソフト等を使ってサイズ変更をするか、新しくインストールし直すしかないですかね？

現場では業務でWindowsを使っていないけれどもリカバリの手順を勉強することで、現場のサーバーではバックアップデータがどのように保存されているのかが気になり始めた。導入時に一回とったきりだから、リカバリはかなり大変な作業になるに違いない・・・早いうちにバックアップ取得の提案をしなければ、私が大変なことに巻き込まれかねん

Windows Server 2008のバックアップ・リカバリ～その一　バックアップで取得したバックアップファイルを使って、新しくサーバーをリカバリしてみます。

二回目はより大きなHDDに戻すパターンです。

新しくVMを作り(HDDは元のサーバーよりも大きい20GB)、バックアップファイルが保管されているHDDを接続します。
Windows Server 2008のインストールDVDを読み込ませ、インストールを開始する。
復元完了までの手順は前回（Windows Server 2008のバックアップ・リカバリ～その二　リカバリ～１．同じサイズのHDDに戻すパターン）と全く同じです。

とりあえず、リカバリが終わりました。


基本的なところは前回と全く同じです。
HDDですが、20GBのところに15GBをリカバリしたので5GBが余ります。


ただし、ディスクマネージャーからは認識できているのでフォーマットすれば使えるようになります。


フォーマットしました。


15GBのCドライブに5GBのFドライブが作成されました。DドライブはDVDドライブ、Eドライブは今回使用しているバックアップデータを保管しているドライブです。

外部ディスクを買うまではいかないけど、パーティションに余裕を増やしたいときには役立つリカバリ方でしょうか？

Windows Server 2008からはソフトを入れなくてもパーティションの結合などを行えるので、新しいHDDに移してCドライブを増やしたいときに使えるかな？でもそこまでするなら新しく入れ直す方が楽かしら？