朝から取り掛かっていたサーバーの設定はとりあえず完了した。
提供するサービスは多くないが意外と手間取ってしまった。
CUPSの設定画面を他のPCから使えるようにしたり、ポート番号をデフォルト(631)以外にしたりするのに戸惑った。
こんな時はネットが便利だなー、ちょっと検索するだけで情報が集まるのだから。
後はFTPサーバーの設定でアクセスを拒否されるのを直した程度。
今回のサーバーはFTPサービスをxinetd経由で起動するので、「/etc/vsftpd/vsftpd.conf」ファイル中の「Listen=YES」を「Listen=NO」に書き換え、さらにtcp_wrappers経由でアクセス制限をするために「/etc/hosts.deny」「/etc/hosts.allow」の2つのファイルに修正を加えた。
そうそう、「/etc/xinetd.d」ディレクトリに「vsftpd」ファイルを他のサーバーからコピーしてきた。
これが無いとxinetdがvsftpdを起動してくれない。
これで必要なサービスを提供できそうなので、後は現地に設置してくるだけだな。
More from: linux
sambaで接続できないサーバー
部下にファイル&プリンタサーバとして使うLinuxサーバーを一台仕立てさせたが、クライアントPC(Windows Xp or 7)から接続できない。
他の案件がいろいろあって手をつけずにいたがようやく落ち着いてきたので、ちょっと設定を手伝うことにした。
#つーか自分で出来ないからやってくれと頼まれた(苦笑)。
まずサーバを起動してsmbが動作しているかを見てみるとプロセスがいない。
あれ?と思って「/sbin/chkconfig –list | grep smb」で起動設定を見るとランレベル2-5はonになっている。
sambaサービスは起動されているはずなのだが、動いていないのでX上のsmb設定ツールを起動して設定を確認してみると、多少設定に(システム上ではなく運用上の)問題があったので修正してサービスの再起動をしようとしたところ、SElinuxからの警告が出た。
なんてことはない、SElinuxが有効になっていたのでサービスの起動が出来ず、外からのアクセスも制限されていただけだった。
「/usr/sbin/getenforce」でSElinuxの状態を確認すると「Enforcing」と出たので、間違いなくSElinuxが有効になっていた。
とりあえず一時的にSElinuxを無効化するために、「/usr/sbin/setenforce 0」を実行してSElinuxの動作を止め(実際には「permissive(警告は出すがアクセス制限はしないモード)」になるだけで、完全には無効にはなっていない)、クライアントからの接続を試したところ無事に接続できた。
やはりSElinuxが動作していたのが原因だったようなので、動作させないように設定することにして、
「/etc/sysconfig/selinux(/etc/sysconfig/selinux/configへのシンボリックリンク)」という設定ファイルの中の
SELINUX=enforcing
となっている行を修正し、
SELINUX=disabled
に変更し、再起動するとSElinuxは無効化されていて、クライアントからの接続も問題無く可能になっていた。
TCPパケットを送出していないわけではなかった、、、、、、
先日ここに書いた特定のサーバーにTCPパケットを遅れないサーバーにhping2をインストールして調べたところ、TCPパケットの送出は出来ていた。
出来ていたというか、きちんと応答パケットが来ていた。
SYNフラグを立てて80番ポート宛になるようにオプションで指定しても、きちんとACKが返って来ている。
tcpdumpでパケットをキャプチャしてもackフラグが立ったパケットをキャプチャ出来るので、間違いなく相手先サーバーから返事が返って来ている。
とすれば、何故telnet等で80番ポートに接続できないのだろうか?謎は深まるばかりだ・・・・・・
接続できないホスト
特定のホストに接続できない状態なので、接続したい相手ホストまでパケットが到達しているか確認するために、相手側でもtcpdumpでパケットをキャプチャしてもらった。
結果的にパケットが到達していないことが判明。
ってことは送信元ホストからパケットが送出されていない可能性が高まったが、原因として思い当たることが無い・・・・・・
とりあえず別のホストから接続する方向で問題を回避するつもりだけど、何とかして解決できないかなぁ?
特定のホストに接続できない・・・・・・・
職場のサーバーの一台から外部の特定のホストに接続できない。
別のサーバからは問題なく接続できるので、ネットワークの問題では無さそう。
不思議なことにpingは通るし、tracerouteで経路をチェックしても相手にパケットは到達している。
いろいろ試すとTCPのパケットが相手に到達していないらしいところまでは判ったが、なぜ到達しないのかが判らない。
ファイアウォールの設定を見ても問題は無いし、その他通信を制限するようなプロセスは動いていないようだし、、、、
tcpdumpの結果を見ると自分から送信しているパケットは拾えるが、それに対する応答パケットが全く無い状態。
接続できるホストに接続すると要求とそれに対する応答を拾える(当たり前)。
殆どのホストに対しては問題なく接続できるが、どうしてもつながなければならないホスト(一般に公開されているホストなので変なアクセス制限はかけていない)につながらない。
ルーターの設定をチェックしても特定のホストに関しての制限は掛けていない。
、、、、、、うーーーーん、、、、、、何故だろう??????
lpdでプリンタに接続できない
linuxで運用しているサーバにプリンタを追加してlpdサービスを再起動したらネットワークプリンタに接続できなくなってしまった。
印刷にはlpdを使用しているので、/etc/printcapに新しいプリンタの定義を追加して、/etc/rc.d/init.d/lpd restartをして、/usr/sbin/lpc restart プリンタ名を実行したところ、
/usr/sbin/lpc: connect: Connection refused
couldn’t start daemon
となってしまいプリンタに印刷データを送れなくなってしまった。
追加したプリンタだけならまだしも、定義しているプリンタ全てに対して同様のメッセージが出て印刷できない。
このサーバは印刷の為だけに使っているサーバなのでrebootもしてみたが症状に変化は無かった。
何故なのか判らないので悩んでいたら、一部のプリンタから印刷が出始めたと連絡があり、その後順次復旧した。
以前にも同じ現象が他のサーバで発生したことがあり、その時はlpdプロセスが余分に動いていたので止めたところネットワークプリンタに接続できるようになったことを思い出した。
今回も同じだったのではないかと思うが、なにもしないで復旧したので確かなことは判らない。
次回は余分なlpdを止めることから始めてみよう。
LogWatchからのmailが大きすぎるので
サーバで毎日LogWatchの出力がroot宛にmailで届く。
まぁこれはそうなるように設定したからで、そのこと自体には問題は無いのだが、問題はそのmailの大きさ。
そのサーバは多数のユーザが登録されており、それぞれが短い間隔(2~10分程度)でとある処理を行うためにcrontabにその処理を登録している。
そのためcrondのlogが大量に吐き出され、それら全てがLogWatchによってrootに報告されてくるので、mailのサイズが少なくとも数メガバイト、多い日には20メガバイトにもなる。
これでは読み出すにも少々時間がかかるので、crondのlogだけは少なく出来ないかと考えた。
他の処理(sendmail,samba等)のlogは比較的少ないので、今回はcrondのみに絞って調べてみた。
最初はcrondそのものが吐き出すlogをwarningレベル以上のものだけに出来ないかと思ったが、それはやめてLogWatchが吐き出す出力を減らすことにした。
ところが/etc/log.d/logwatch.confを見ても個別のサービス単位でのlog-levelの設定は出来なさそうなので、少々悩んでしまった。
どのサービスのlogを出力するかは個別に選べ、そうするには/etc/log.d/logwatch.conf 内の「Service = All」になっている部分のAllをそれぞれのサービス名に書き換え、それを必要なサービス分書けば良いが、今回はAllのままにした。
というのは、いちいち出力するサービスを記述するのは面倒なうえ、出力漏れがあると少々困ってしまう。
今回はcrondだけのlogを減らしたいので、最終的は出力するscriptを修正してしまった。
修正したscriptは/etc/log.d/scripts/services/cronで、なにも出力させないのなら最初にexit(0)を書いて強制的に処理を終わらせれば良いのだろうが、それでは重大なメッセージがあった場合に見逃してしまうので、圧倒的に多く出力されている”Unmatched Entries”を減らすために、それを出力する行をコメントアウトした。
具体的にはscriptの最後の下記の部分
——————————————–
if ($#OtherList >= 0) {
print “\n**Unmatched Entries**\n”;
print @OtherList;
}
exit(0);
——————————————–
の3行目の”print @OtherList;”の行をコメントアウトした。
これで明日の朝に来るmailのサイズが小さくなることを期待しよう。
samba
職場で昨年暮れに買ったLinuxサーバのセットアップをしている人間から「Windowsからネットワークドライブとして接続できない。」と言われたので、アカウントを作ってもらって少々調べてみた。
/var/log/samba/hoge.logには「’/home/hoge’ does not exist or permission denied when connecting to [hoge] Error was Permission denied」というエラーが出ている。
/etc/samba/smb.confを見てもきちんと定義してあるし、自分のホームディレクトリなので、パーミッションがおかしいとか存在しないということも有り得ない。
WindwosXPのマイネットワークから見るとサーバ名は見えるが、アクセスしようとすると「名前が重複しています。」と言われて接続できない。
確かにhostnameでホスト名を見ると未設定のままなので「localhost.localdomain」となっている。
最初はこれが原因だと考えてとりあえずhostnameコマンドで適当な(他と重複しない)ホスト名を設定して、
#/etc/rc.d/init.d/smb restart
でsambaを再起動。
これで大丈夫と思いサーバにアクセスすると共有名とホームディレクトリが見えるようになったが、どちらもアクセスしようとすると、アクセスする権限が無いと言われてアクセス出来ない。
サーバのログに出ているエラーをキーワードにして探したところ、どうもSELinuxが原因らしいということが判り、/etc/selinux/configファイルを見るとSELinuxが有効になっていた。
SELinuxを無効にするのが簡単だがセキュリティ上不安があるので、SELinuxを有効にしたままsambaを使えるようにするには
#/usr/sbin/setsebool -P samba_enable_home_dirs 1 (homeディレクトリのみ開放)
#/usr/sbin/setsebool -P samba_export_all_rw on (sambaで開放したいディレクトリ全てを開放)
を実行する必要があった(2行目を実行すれば1行目は実行不要)。
“-P”オプションを付けているのは再起動後も設定が有効になるようにするためで、試験的にアクセスを許可する等一時的に設定する場合は”-P”オプションは不要。
これでWindowsPCからsambaでアクセス出来るようになった。
SELinuxに関してはもっと沢山のbool値があり、
#/usr/sbin/getsebool -a
でbool値の名前と現在の状態を調べることが出来るので、おいおい調べていこう。
でもまだまだいろんなことがありそうだなぁ(笑)。
明日から帰省
今年最後の(休日出勤での)仕事も無事終了!
去年はLinuxサーバをshutdownせずに電源ケーブルを抜かれたおかげで、1台はHDDが壊れ、もう一台は電源ユニットが壊れて結局2台のサーバを作り直す羽目になったけど、今年は自分でshutdownして電源を切ったのでその手のトラブルは皆無(ってこれが当たり前)。
まぁWindows2000Serverでどうやってリモートデスクトップ接続を有効にするのかを忘れてしまったけど、その設定は年明けでもいいし。
とりあえず年内の作業は終了!
というわけで明日から帰省できる。まぁ、明日はのんびり行こうっと。
Linuxでプリンタのステータスが正しく表示されない(?)
Linux上で使われている印刷システムは現在CUPSが主流だと思うが、未だにlpdを使っているサーバが少なからずある。
印刷キューの状態は「lpc status ”プリンタ名”」で見ることが出来るが、ちょっと面白い現象に出くわした。
プリンタサーバ側にトラブルがあって複数のキューが溜まってしまったプリンタのステータスを見たら、
queuing is enabled
printing is enabled
21 entries in spool area
no daemon present
と出ていた。まぁこの表示自体には問題が無い(no daemon presentとなっているがプリンタサーバの応答が無いのでdaemonが止まっているため)。
止まっていたプリンタサーバを再起動し、lpc restart ”プリンタ名”で印刷を再開させてから再度ステータスを見ると、相変わらず「no daemon present」となっている。
ところがプリンタサーバ側にはデータが送られていて印刷が始まっている。
他の端末でステータスを見ると「sending to ”プリンタサーバ名”」となっていて正常に印刷データを送っていることになっている。
同じサーバの同じプリンタのステータスを見ているのに違う結果が表示されている。
不思議に思ったがこの違いは一般ユーザーで見ているかスーパーユーザーで見ているかというところにあった。
一般ユーザーで見ると「no daemon present」と表示され、スーパーユーザーで見ると「sending to ”プリンタサーバ名”」と正しく表示される。
/etc/printcapで指定するスプールディレクトリ(一般的には「/var/spool/lpd/”プリンタ名”/」)にあるstatusというファイルの内容もsending to ”プリンタサーバ名”となっていたが、一般ユーザーだときちんと読み取れなかったらしい。
パーミッションも644になっているので何故読み取れなかったは不明。こんなこともあるんだなぁ?
