The Road to Genecialist!

私が参加しているプロジェクトでサーバーのログをログ集約サーバーに転送することになりました。

syslogの転送先サーバーはすでに構築されているので、こちらの作業はsyslogを転送する設定を入れるだけですが、勉強のために転送の設定についても調べてみました。

まずはsyslogについて。

syslogはsendmailの一部として開発されましたが、便利だと言うことでUNIX/Linux等のデファクトスタンダードのロギング方式となりました。

syslogが使用するポートは514/udpなのでデータの保証はないが、TCPでの実装版であるrsyslogがあります。使用するには"/etc/services"に"syslog 514/udp"のエントリが必要です(RHEL5ではデフォルトで登録されている)。このエントリが無い場合、ポートを開けることができないのでデーモンは終了します。

ポートがない場合


ポートがある場合


・転送先サーバー設定
"/etc/sysconfig"にある"syslog"ファイルの"SYSLOGD_OPTIONS"を元の"-m 0"から"-m 0 -r"に修正します。また、"/etc/init.d"にも"syslog"ファイルがあるので同じように"SYSLOGD_OPTIONS"を修正します。

-mオプションは後ろの数字の時間(分)ごとにタイムスタンプを記録させます。"-- MARK --"という文字列がログの代わりに記録されます。ここでは"0"なのでこの機能は使わない設定になっています。
-rオプションはネットワークからのメッセージを受信する機能を有効にします。ver1.3以降のデフォルト設定はオフになっており、オプションをつけない限り受信しません。

以上の設定を終えたらsyslogデーモンを再起動します。


・転送元サーバー設定
"syslog.conf"の設定に"@"で始まるIPアドレス/ホスト名を追加します。
(ホスト名の名前解決ができない場合には10回問い合わせをした後、エラーメッセージを出力します。RHEL5ではエラーメッセージの出力が確認できませんでした)。今後の保守性を高めるためにもhostsに記述されているホスト名を使用する方が良いです。

全くすべてのログを転送するのであれば"*.* @hostname"と記述します。今回は通常"/var/log/messages"と"/var/log/secure"に書き込まれるレベルを転送することにしました。

以上の設定を終えたらsyslogデーモンを再起動します。再起動し次第、ログが転送され始めます。


今回設定した際にログ転送先サーバーのファイアウォールのポートを開けるのを忘れていました。
ホストLINUX02でログインしてもログが記録されません。
ログイン




tcpdumpを使って、ログが転送されているのかを確認しました。プロトコルはudpで宛先ポートが514の通信を表示します。


ログ転送先のポートが開いているかを確認。514ポート(下図ではsyslogと表記)自体は開いてリスン状態になっています。


ここまで来たら後はファイアウォールが怪しいです。ファイアウォールでポートをふさいでいないか確認したところ、見事にふさいでおりました。


"system-config-securitylevel"コマンドで"514/udp"ポートを開きます。


注意書きに「"サービス名:プロトコル"で記述せよ」とあったので"syslog:udp"と入力しました。




ファイアウォールのポートを開き、ホストLINUX02でログインしたところ、ログが記録されました。転送先サーバーのログには下記の様にホスト名が表示され、どこのサーバーで出力されたログかがわかるようになっています。転送されたログのホスト名が小文字なのは仕様なのでしょうか？


転送先サーバーでログがどのように振り分けて記録されるのかについても確認しました。

転送先サーバーの設定は認証についてのログを"/var/log/secure"だけでなく"/var/log/messages"にも記録するようにしてありました。


これをデフォルト通り"/var/log/secure"のみに書き込むように変更しました。


すると、最初にログの転送を確認したときには"/var/log/messages"にも記録されていた認証についてのログが"/var/log/secure"のみに記録されるようになりました。


ログの書き分けルールは転送先サーバーの設定に従うと言うことがわかりました。

RHEL5で確認してあります。

「Hyper-Vの構築～その五　仮想マシンのインストール(Red Hat Enterprise Linux 5.4)」でLinux IC (統合コンポーネント)v2.0をインストールしました。

しかし、2010年7月にLinux Integration Services v2.1がリリースされています。対応しているLinuxゲストOSは下記の6つです。

Linux Distributions (4コア)
SUSE Linux Enterprise Server 10 with Service Pack 3 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3、5.4および5.5 (x86 Editionまたはx64 Edition)

さらに、v2.1ではインストール方法が変更されています。

注意点は下記の二点です。
・v2.1をインストールするには対象Linux OS上の"/usr/src/kernels/2.6.18-155.el5-i686"にカーネルがインストールされている必要があります。

・Software Developmentパッケージがインストールされている必要があります。

それではインストールしていきますが、新規インストールも旧バージョンからのアップグレードも手順は全く同じになります。ここではアップグレードした際のイメージを載せておきます。

まずはCDをマウントし、中身をすべて"/opt"以下の任意のディレクトリにコピーします（MSのドキュメントでは"/opt/linux_ic_v21_rtm2となっています）。


コピーしたらそのディレクトリへ移動し、"make"コマンドを実行します。


"make"が完了したら"make install"でインストールします。




インストールが完了したらLinuxを再起動します。

再起動後にsshで接続した図ですが、前回のログイン時刻と現在時刻が大きくずれています。これは、v2.1で追加されたホストOSとの時刻同期が動いているためです。インストールから1週間で3時間ほどずれています。


サーバーマネージャーで確認をすると、ステータスのところで「ハートビート」が「OK」になっています。Linux ICをインストールする前は「OFF」となっていました。


また、サーバーマネージャーからOSのシャットダウンをすることもできます。






これもv2.1からの新機能です。サポートLinuxゲストOSでも書いてありますが、複数コアのサポート等もv2.1から追加されています。詳細についてはMicrosoftのドキュメントを参照してください。

Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2

「Hyper-Vの構築～その三　仮想マシンのインストール(Windows XP)」、「Hyper-Vの構築～その四　仮想マシンのインストール(Windows 7)」の二回にわたってゲストOSとしてWindows OSをインストールしましたが、今回はLinuxをインストールしてみます。

Linux Integration Services v2.0で対応していたLinuxゲストOSは下記の5つです(現在はv2.1がリリースされています)。

Linux Distributions (1コア)
SUSE Linux Enterprise Server 10 with Service Pack 2 (x86 Editionまたはx64 Edition)
SUSE Linux Enterprise Server 11 (x86 Editionまたはx64 Edition)
Red Hat Enterprise Linux (RHEL) 5.2、5.3および5.4 (x86 Editionまたはx64 Edition)

今回はまずRed Hat Enterprise Linux (RHEL) 5.4をインストールします。

Hyper-VでLinuxを稼働するためにはLinux IC (統合コンポーネント)をOSインストール後に導入する必要がありますので、あらかじめMicrosoftからダウンロードし、展開しておきます。

LinuxのインストールもWindowsと全く同じです。

インストール後にネットワークを確認すると、ネットワークアダプターが認識されていません。


Linux IC (統合コンポーネント)をインストールしますので、メディア -> DVDドライブ -> ディスクの挿入を選んで解凍したLinux IC (統合コンポーネント)のLinuxIC v2.iso(現時点)を指定します。




ディスクを挿入すると、最近のLinuxディストリビューションは自動的にマウントしてくれます。

コマンドラインからCDのマウント場所に移動(cd /media/CDROM)し"./setup.pl drivers"とコマンドを実行するとLinux ICのインストールが開始されます。






Linux ICのインストールが終了してからネットワークを確認すると、"seth0"というアダプターが認識されています。これで外部との通信ができるようになります。


リモートデスクトップでサーバーにログインし、Linuxの仮想マシンに接続してウィンドウをクリックすると、メッセージが表示されてしまいます。要調査です。


ただ、LinuxもWindowsの様にリモートデスクトップで接続することもできますし、teratermなどからSSHで接続することができますのでそれほど問題にはなることはないと思います。

次はv2.1での確認をしたいと思います。

Edge Componentsを使用しているのですが、サービスアドレス(クラスターアドレス)が付加されないという問題が発生しました。

前任者からの引き継ぎ時に、たまにサービスアドレスが付加されないことがあるから、手動で追加してねと言われていました。アプリケーションサーバーの再起動は頻繁に行っているのですが、Edgeサーバーの再起動はシステムリリース後ほとんど行われていないため、あまり問題にはなっていませんでした。

dscontrolコマンドでEdge Componentsを起動中にgoActiveというスクリプトが実行されます(Edge Componentsのbinディレクトリに作成するファイルです)。このスクリプト内ではipconfigコマンドを実行して、サービスアドレスを新たに追加する様になっています(Windowsではnetshコマンドで)。このipconfigコマンドは/sbinディレクトリに配置されており、通常このディレクトリにパスの通っていない一般ユーザーは実行する事が出来ません。

オペレーターに作業手続きを全て引き継いでいますが、Edge Componentsを起動するシェルではsudoでdscontrolコマンドを実行しています。rootはもちろん/sbinディレクトリにパスが通っているのですが、sudoコマンドではパスが引き継がれない事を知らなかった為にこのような問題が発生しました(どのバージョンからかは定かではありませんが、"-i"オプションをつける事によって、sudoで遷移するユーザーのパスを引き継ぐ事が出来ます)。

sudoコマンドのバージョンが低い為"-i"オプションを使うのではなく、シェルの中に"export PATH=$PATH:/sbin"と書き加える事で解決する事になりました。

Edge Components v6.0.2での事象です。
「Load Balancer 管理ガイド バージョン6.1」の「第５章　クイック・スタート構成 － Dispatcher コンポーネントの構成 － コマンド行による構成」に『AIX、HP-UX、Linux、またはSolaris システムの場合は、dsserver コマンドをroot ユーザーとして実行します。』とあるので、ここで/sbinにもパスを通しておくようにという事を暗に意味していたのかもしれません。

類似事象として、v7.0でもパスが通っていない為にEdge Componentsを起動できない事があります。こちらも/sbinディレクトリへのパスが通っている必要があるもので、Edge Components起動中(dscontrol executor start)にException(java.util.NoSuchElementException)が出力されます。

外部の時刻サーバーと同期し、サーバーの時刻を正確に保つために使用するNTPですが、環境によってはインターネットを通じて外部に接続することができないことがあります。それでも、ネットワークに接続されているサーバー群の時刻は同期がとれている必要がある時もあります。Webサーバー群でログのタイムスタンプをあわせたいときなど。

そんなときは、一台をネットワーク内の時刻サーバーとして扱い、そのサーバーの時刻を他のマシンの基準にさせることができます。次の様な環境で構成してみます。

サーバーA：192.168.0.1
時刻サーバー

サーバーB：192.168.0.2
サーバーC：192.168.0.3
クライアント

まず、クライアントとなるサーバーB/Cの設定を見てみます。

restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
server 192.168.0.1 minpoll 4 maxpoll 10

これらのサーバーの設定については今まで通り、時刻サーバーを見に行く設定にするので特に問題ないと思います。

時刻サーバーとなるサーバーAですが、基本的な設定ファイルの書き方は今まで通りです。一つ違うのは、このサーバーは外部サーバーと同期するのではなく、自分自身と同期するように設定ファイルを記述すると言うことです。

restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
fudge 127.127.1.0 stratum 5

ntp.confを編集したらntpdサービスを再起動します。

しばらく時間をおいてntpqコマンドで確認してみました。

サーバーA

]# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*LOCAL(0)        .LOCL.           5 l   33   64  377    0.000    0.000   0.001

サーバーB/C

# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*192.168.0.1     LOCAL(0)         6 u  535 1024  377    1.334    0.484   0.126

 LOCAL(0)        .LOCL.          10 l   13   64  377    0.000    0.000   0.001

サーバーAではstratumを5と指定したのに、サーバーB/Cでは6と認識されているのがなぜだかわかりませんが、無事にタイムサーバーとして認識され、同期されていることがわかりました。
ローカルネットワーク内での同期なので、時刻差がとても小さいです。

今日ふと思いました。

/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ファイルを勝手に消してしまえばミッション終了です。

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

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で発生します。