More from: サーバ

今時AGPとは（汗）

P , by

c No comment

今日の作業で移設したサーバのディスプレイ出力が死んでいた。
駄目元で電源を入れて起ち上げたがやはり画面には何も表示されない。
しかもちゃんと起動していないためかいくら待ってもpingすら通らない。
画面に何も出ないので起動途中のどこで止まっているのかも不明。
たしかこのサーバのビデオカードってAGPだったような・・・
AGPのビデオカードなんて手元にあったかなぁ？何カ月か前に貰ったのが確かAGPだったけど大掃除で捨てちゃったしなぁ、、、
今時買おうとしてもショップの店頭なんかには無いだろうし・・・
と思っていたら部下が3枚ほど掘り出して来てくれてビックリ。
さて、これを組み込んだら動いてくれるかなぁ？

探してみたら今でも販売されているんだなぁ。
玄人志向 ビデオカード GeForce FX5500搭載 AGP 8x接続 GF-FX5500-A256HS
B00I39P62M
IGAGURI 7000-AGP ATI RADEON 7000 SDRAM 64MB AGPビデオカード
B00HAWLG0O
グラフィックカード★ATI 9550 DDR DVI グラフィックカード　256MB 並行輸入品
B00R5F75VU

ATI RADEON 9550 AGPビデオカード IGAGURI 9550-AGP

ATI RADEON 9550 AGPビデオカード IGAGURI 9550-AGP
価格：5,378円（税込、送料別）
←クリックしてくれると嬉しいです。

ファイルサーバにつながらない？

P , by

c No comment

遠隔地のユーザーから別部署経由で「共有フォルダが見えなくなった」との連絡が来た。
すぐにそのフォルダを置いてあるサーバにpingを打つと全く反応が返って来ない（汗）。
中継してくれた別部署の方では荷が重いのでこちらから直接ユーザーに連絡を取って電源の状態等を確認して貰った。
それで判明したのは、
・電源は入っている（電源ランプ点灯、ファンの回転音がする）
・ディスプレイにはなにも表示されていない（信号が来ていない）
・電源SWを押すとすぐに電源が切れる（長押しの必要は無い→OSがハングしているわけでは無い）
ということ。
さて、ここからどう解明していくだけど、とにかくディスプレイに何も表示されないと言うことでこのままではお手上げ状態。
ディスプレイのほうがハングした（たまにある）のかと思って、ディスプレイの電源ケーブルを一度抜いて挿し直して貰ったところ、今度はディスプレイの電源が入らなくなってしまった。
これはもしかしてディスプレイがお亡くなりになった？ということで、他のディスプレイをつないで貰ったところ今度は無事に表示され、BIOSの起動途中でエラーを表示して停まっていた。
内容を読んで貰うと
「Strike F1 Key to continew,F2 key to Setup」
とかいう文が表示されていると言うことだ。
そこでF2キーを押して時刻設定だけを直して貰ってESCキーでSetup画面から抜けると無事にOSの起動画面が出て来て、ほどなくクライアントPCから共有フォルダが見えるようになった。
詳しく訊くと前夜に入居しているビルの電気関係の検査があって数時間の停電が予定されていたとのこと。
一応サーバはUPSから電源を取っているけど、さすがに1時間単位での停電には耐えられないので、UPSのバッテリー切れでサーバが落ちてしまい、複電した時点で再度電源は入ったが何故かBIOSが異常を検知して起動途中で止まっていたらしい。
その異常だけど、ケースが開いたとか外れたとかのメッセージだったらしいけど、誰もケースを開けたりはしないんだけどなぁ、、、？？？
あと壊れたディスプレイの替わりを送らないと・・・（汗）

←クリックしてくれると嬉しいです。

SSDがお亡くなりになってしまった・・・

P , by

c No comment

昨夜自宅のPCの一台（MX-130S2）が再起動中に止まっていた。
このPCは基本的に24時間稼働させているのだが、以前から時折勝手に再起動しては止まっていることがあった。
そういう時は起動ドライブの設定が狂っていてOSの入っているSSDでは無いドライブから起動しようとして失敗している状態だったので、昨夜もそうだろうと思って一度電源を切って再度入れ直し、BIOS設定の画面で起動順を入れ替えようとしたところ、マザーがOSの入ったSSD（KingstonのSSDNow V100）を認識していない。
SATAケーブルの抜け等なのかな？と思ってケースを開けてケーブルを確認したが特に外れかけているわけでもないので、再度電源を入れてみたがやはり認識されない。
今度はSATAポートの不良を疑ってケーブルを他のポートに挿してみたが全く同じ状況。
ということはSSDがお亡くなりになったか？ということでSSDを取り外し、外付けUSBケースに入れてUSBポートに接続してみたがやはりドライブとして認識されない。
念のため他のノートPCに接続しても全く認識されない（ケースに他のSSDを入れると認識するのでケースの不具合でも無い）。
これでSSDが逝ってしまったということがほぼ確定・・・
一昨年（2013年）の春に買ってからまだ2年も経っていないのになぁ、、、
手持ちのSSDは新たに手に入ったR61に回す予定（実際にはR500のSSDの中身を予備のSSDにコピーして入れ替え、R61にはR500に入っているSSDを回す予定）なので、余っているのは無い状態。
仕方ないので本体の購入時に入っていたHDDを取りつけてOSをインストールするつもり。
幸い起動ドライブなのでデータは殆ど入っておらず助かったが、OSインストール＆ドライバインストール＆アップデートが面倒だなぁ。

←クリックしてくれると嬉しいです。

ftp接続でのpassive modeの切り方

P , by

c No comment

ftpを使ってのデータのやりとりで、ファイアーウォール等では20番及び21番ポートを開けているにもかかわらず、何故かデータの送受信が出来ないことがある。
最初の接続及びユーザー名を使っての認証までは行えるのに、データを送る（もしくは受け取る）操作（getもしくはput）をしても
ftp: connect: Connection timed out
と出てしまい送受信が出来ない。
こんな時はPassive Modeになっているのではないだろうか？
実際私も職場と現場のサーバー同士でデータの送受信を行おうとして上手くいかなかったことがあり、そういう時は決まってPassive Modeになっていた。
Passive Modeで送受信する時は使われるポートがその時の環境で変化するために、場合によってはファイアーウォール等で閉じてあるポートを使うことになり、当然ながらパケットが通らずにタイムアウトを起こすことになる。
＃Passive Modeの場合はlsコマンド等の結果が返ってくるポートも不定なので同様にタイムアウトを起こしてしまう。
この場合はPassive Modeをオフにすることでftpクライアントはデータ転送に20番ポートのみを使うようになるので、問題無くデータを送受信できるようになる。
Linux標準のftpクライアントでは
ftp>Passive off
としてやることでPassive Modeをオフにすることが出来る。
Windows用のクライアントソフトの場合はソフトにより設定の方法が異なるので、ここでは書かないけど、大抵はPassive Modeをオフにすることが出来る筈（Windows7のコマンドプロンプトで使えるftpクライアントではpassiveコマンドが無くて設定できなかった）。
接続もログインも出来るのにデータの送受信でタイムアウトになる場合はお試しあれ。

←クリックしてくれると嬉しいです。

gssftpの設定

P , by

c 1 comment

何年か前に遠隔地にサーバーを設置したが、その現場にちょっと大きめのデータを送る必要が出来た。
CD-Rに焼いて送ろうかと思っていたが、Linuxサーバーがあるのでftpで送れば良いのでは？と思い試して見た。
手元のPCから直接FTP接続をしてみたが、ルーターでブロックされて駄目（汗）。
仕方がないので一度近くのサーバーにアップして、そこから接続すると相手サーバーにはじかれてやはり駄目。
これは相手側サーバーでftpサービスを動作させていないためで、サービスを動作させてやればOKと思い設定してみた。
相手サーバーにインストールされていたftpパッケージはタイトルにもあるgssftpなので、設定ファイルは”/etc/xinetd.d/gssftp”というファイル。
この中に記述されている
disable = yes
を
disable = no
に書き換えてから
xinetdを再起動（/etc/rc.d/init.d/xinetd restartを実行）。
早速接続してみると、接続は出来るが
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI error major: Unspecified GSS failure. Minor code may provide more information
GSSAPI error minor: No credentials cache found
GSSAPI error: initializing context
GSSAPI authentication failed
334 Using authentication type KERBEROS_V4; ADAT must follow
KERBEROS_V4 accepted as authentication type
Kerberos V4 krb_mk_req failed: You have no tickets cached
Name (localhost:hoge):
530 Must perform authentication before identifying USER.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
というエラーが出てログインできない。
どうもユーザー認証の方法に問題があるようだけど、よく判らないのでググってみると解決方法が見つかった。
設定ファイルにある
server_args = -l -a
の行から”-a”を削除して
server_args = -l
としてxinetdを再起動すると無事にログインすることが出来た。

←クリックしてくれると嬉しいです。

接続数の上限に達した？

P , by

c No comment

現場のPCがWindowsサーバの共有フォルダを参照しようとすると
「コンピュータの接続数が最大に達しました。これ以上コンピュータを接続できません。」
というようなエラーメッセージが出てアクセスを拒否されることが頻発している。
4台しかPCを置いていない現場で発生しているので、CALの初期購入数である5ユーザーを上回っていることはあり得ない。
またコマンドプロンプトで「net session」を実行しても多くても3セッション程度しか表示され無い。
それでもライセンス管理で見ると到達した最大ユーザー数が”７”となっている。
サーバーを再起動するとこの数値がリセットされてアクセスが可能になるのだけど、頻繁にサーバーをリセットするわけにもいかない。
またイベントビュアーにも「ライセンス数の上限に近付いている」という警告メッセージが出力されている。
クライアントPCが4台しかなく、PC1台につき1ユーザーしか使用していないにも関わらずライセンスが不足するというのはおかしい。
いろいろ調べていくとWindows2000SeverやWindows2003Serverでは「License Logging Service」というのがライセンス数をカウントしているらしく、これに不具合があるらしいことが見えてきた。
MSのサポートサイトでもこのサービスを停止する方法等が出ていたのでとりあえずそれを実行。
さらにアイドル状態のセッションを短時間で切断するために
net config server /autodisconnect:-1
を実行。
これでしばらくは様子見かな？

←クリックしてくれると嬉しいです。

あせったあせった（汗）

P , by

c No comment

部下が現場のサーバに遠隔からリモートデスクトップ接続でログインして作業して、ログアウト時に間違って「シャットダウン」を選んだままOKボタンを押してしまった。
当然サーバは電源が落ちるわけで、そうなると遠隔操作ではどうしようもない（HPのサーバだったら良かったのにと思ってしまった）。
慌てて現地の人に電話して電源SWを押して貰いサービスの中断は僅かで済ませることは出来たけど、報告を受けた時はあせったなぁ。

←クリックしてくれると嬉しいです。

何故今頃？

P , by

c 2 comments

先週の金曜日（9/26）に書いた「bashの脆弱性対策」の被参照数が今日になって増えている。
週末の休みが終って対策に奔走する羽目になったサーバー管理者の方々が多いのだろうか？
まぁ先の記事にはyumが使えない場合の手順も書いたからそのせいかな？

先の記事を書いた後にさらにパッチが公開されているので、ホントは「bashが「CVE-2014-7169」に仮対応」とか「さらにパッチが当っている模様（bash）」のほうが参考になると思うけど（汗）。

←クリックしてくれると嬉しいです。

bashが「CVE-2014-7169」に仮対応

P , by

c 4 comments

「bashの脆弱性対策」で書いたbashの脆弱性に関して、未対応だった残りの脆弱性（CVE-2014-7169で報告）に仮に対応したbash-3.0-27.0.2.el4がリリースされていた。
先の記事同様ソースパッケージ
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4.src.rpm
をダウンロードして
# rpmbuild –rebuild bash-3.0-27.0.2.el4.src.rpm
でrpmパッケージをビルドして
# rpm -Uvh bash-3.0-27.0.2.i386.rpm
で適用完了。
CentOS版のbash-3.2-33.el5_10.4も出ているとのことなので、yumでアップデートが出来るようになる筈。

情報を下さったちょろさんありがとうございます。

←クリックしてくれると嬉しいです。

ちょっと新しくなったVer.は駄目だった（汗）

P , by

c No comment

bashの脆弱性対策を行ったが、bash-3.2-33.el5.1.src.rpmを使ってビルドしようとしたら「とあるヘッダファイルが無い」って言われてコンパイル出来なかった。
bash-3.2-33.el5.1.i386.rpmをそのまま入れようとしたらglibcのVer.が古くて入れられないのでソースから入れ直そうと思ったけど、やっぱり無理だったか（汗）。

←クリックしてくれると嬉しいです。