来週の九州&東京出張の宿がまだ決まらない。
最初候補にいれていた浅草近辺は地下鉄銀座線に乗れるというのがメリットだったけど、実は未乗区間だと思っていた末広町―浅草間は先月東京に行った時に乗っていたことが判明。
なので無理に浅草に泊まる必要も無くなってしまった。
とはいえ今のところ他に候補地が出てこないのも確か、、、
こうなったら副都心線で行ける池袋とかその先辺りでも探して見るか・・・
More from: 仕事
さて、宿を探すか・・・条件は・・・(爆)
今月は東京への出張が入った。
泊まりでの出張なので宿泊先をどうするか検討中。
出張先が渋谷近辺なのでその辺りに泊まるかとも考えたが、渋谷のホテルは高いから出来れば避けたい。
というわけで乗り換えなしで渋谷に行ける沿線沿いを含めて考えている。
渋谷駅には様々な路線が乗り入れているので選択肢はいろいろあって(むしろありすぎて)迷ってしまう。
出来ればそれらの路線の中で乗ったことの無い路線、もしくは乗ったことの無い区間のある路線で選びたいところ(汗)。
けど、あまりに遠くて時間のかかるところも避けたいところなので、副都心線の和光とかはちょっと無理かな。
浅草も銀座線で一本だし、実は末広町と浅草の間は未乗だったので候補地のひとつ。
うーん、悩むなぁ、、、(普通の人はこんなことでは悩まないだろうなぁ)
勘弁してくれ・・・
現場から複数のPCで特定のアプリケーションを起動するとエラーとなって起動できないという連絡が来た。
このアプリケーションはあるドライブ上にあるファイル群を使用するので、各PCではファイルサーバー上の特定のディレクトリをネットワークドライブとして接続して使っている。
なのでこの接続が切れているとエラーとなって起動出来ず、今回出たエラーメッセージもその際に出るものと同じだったので単に接続が切れていると思われた。
Windowsのエクスプローラーで見て貰うと確かに必要なネットワークドライブの接続が切れていて、「ネットワークの場所」の中に見当たらない。
これは時折ある現象なので各PCには接続用のバッチファイルを置いてあり、そのバッチファイルを動作させて接続をして貰ったところ、無事にネットワークドライブに接続できエクスプローラー上にもドライブとして表示されるようになった。
めでたしめでたしということでアプリケーションを起動して貰うと、同じエラーが出てやはり起動しないとのこと。
おかしいな?ということでさらに調べて行き、あーでもないこーでもないといろいろ調べた結果、起動に必要な一部ファイルが削除されていることが判明。
ファイルサーバー内を探しても出てこないので、よその現場にある同じファイルをコピーすることで対処したが、容量が大きい(500MBを超える)のでWAN越しにコピーするのに30分近くかかってしまった。
コピー終了後に現場で再度アプリケーションの起動を試して貰うと今度は無事に起動して、今度こそめでたしめでたしとなった。
ファイルが消えた原因ははっきりしないが、容量が大きい(500MBを超える)ので、現場のユーザーの誰かが(自分たちでは明示的に使わないファイルなので)不要で大きなファイルと思いこんで消してしまった可能性が高い。
実はこの現場では過去にも同じようなことが2回あり、その時はディレクトリ丸ごと消してくれてしまっていたが、今回は特定のファイル一つだけだったので気付くのが遅れた。
前回も前々回もそのファイル群には一切触らないように警告しているんだけど、効き目がないらしい。
今までは現場レベルので話で済ませていたけど、こうなったらトップから罰則付きの警告をして貰わなくては駄目かも(汗)。
一体なにを聞いているのやら・・・
作業依頼をしていた業者さんの担当者から作業についての連絡があった。
日時の調整の連絡だったのだけど、言っていることがなにかおかしい。
不思議に思いながら話をしていると、費用が余分にかかるのでこちらが断った方法で作業をするつもりらしい。
おいおい、その件は営業さんに話を通しておいたんだけどねぇ、と思いつつあらためて一度断っている方法だということを説明すると、調整して再度連絡するとのこと。
作業を依頼したのが先週なのに今日になってようやくよこした連絡がこれかいorz
この分だと次の連絡がいつになるか判らないなぁ、と半分諦めていたら驚くべきことに数分後に連絡があった。
結局こちらが依頼した方法で作業をして貰えるようになり、ようやく日程の調整も付いた。
ここまでくるのに何日かかったことやら、なんか既に作業が終わってしまった感じがするよ(汗)。
またTAが逝ったか・・・
現場の電話の調子が悪いらしくいつも電話工事をお願いしているところに連絡が行ったと業者さんから連絡があった。
それによると
「午前はつながるけど午後は通じなくなる」
ということらしい。
ちょっと不自然な現象なのだが、業者さんがみたところTAが老朽化して不調になっているとのこと。
幸い手元には中古のTAがあるので交換して様子をみることにした。
なんか、ここんとこ電話絡みのトラブルが多いなぁ。
gssftpの設定
何年か前に遠隔地にサーバーを設置したが、その現場にちょっと大きめのデータを送る必要が出来た。
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を再起動すると無事にログインすることが出来た。
まぁ、なんというか・・・
現場のPCから印刷が出ないとの連絡が来た。
実は先日から業務システムの印刷が予期しないプリンタから出てくる現象が発生していたPCだったので、これ幸いとばかりPCの設定を見て貰ったところ予想していた場所にミスがあり、早速直して貰った。
これで解決したと思い印刷を試して貰ったところやっぱり出ないという。
よくよく訊くとWindowsアプリからの印刷が出ないということで、原因はネットワークプリンタとの接続が切れていたためで、こんな場合に備えて各PCに入れてある接続し直すためのバッチファイルを起動して貰ったところ無事に印刷が出来るようになった。
ついでに業務システムからの印刷も試して貰ったところ、「ちゃんと出ましたー」とのことだったので一安心して電話を切ったが、業務システムのサーバーを見ても印刷した形跡が無い・・・
そこでプリンタ側のログを見ると、印刷したのは業務システム画面のハードコピーだということが判明(汗)。
ということで業務システムからの通常の印刷が直ったかどうかは不明。
ま、出なけりゃまた電話が来るだろう。
それにしても業務システムからの印刷をお願いしたのに画面のハードコピーを出されるとは思わなかった・・・
今日は電話かよ・・・
今日は何故か電話のトラブルが多い。
一件目はFAXの送受信が出来ないということで、試しにその番号に電話を掛けてみると話中でつながらない。
TAの再起動で直るかと思ったが、近い現場だったので直接行って試してみたが再起動程度では復旧しなかった。
TAの”ACT”のLEDが点滅しているのが気になったが、再起動しても何故か直らない。
これはTAが壊れたかと思って替わりのTA(中古)を持って行って交換したが、やはり”ACT”のLEDが点滅する。
ここに至って回線の不具合ということで故障受付に連絡して対応して貰ったが、遠隔では対処できることを全て試しても駄目だったのでサービスマンが直接現場に来てくれてチェックしたところ、屋内配線のどこかが断線しかかっている可能性が高いということで新たに配線をし直してくれて解決した。
この対応をしている間に別の現場から電話回線の内一本が時々使えなくなるとの連絡が入った。
こちらもTAが疑わしかったけど、まずは回線の修理受付に連絡して貰うことにした。
午前中はこの対応の合間に急ぎの案件に対応しているだけでつぶれてしまった・・・
なんか忙しいぞ
三連休で東京に行ってきて、今日から仕事に出たら何故か忙しい・・・
というか、急な案件が入ってきてしまったorz
あと一週間はあったはずなのにいきなり明後日とか言うし・・・
急に予定を早めないでよねぇ、、、
今日も大量に編集・・・
昨日大量に設定ファイルを書き換えたところ、今朝になってちょっとした問題が発生していた(汗)。
結局もう一度同じファイルに記述を追加することが必要になったのだが、今度も追加するのはファイルの途中。
昨夜と同じにviで編集するのもなんなので、ちょっとググって出てきた方法を使うことにした。
sedを使う方法なのだが、試しにコマンドラインから実行してみると簡単に出来たので、この方法で実行することにして簡単なスクリプトを書き、それを昨夜と同様にfor文で回して実行。
実行にかかった時間は僅か数秒だったので、昨夜時間を掛けたのはなんだったの?といった感じ(汗)。
実際にスクリプトを書くために調べ始めてからも30分程度で済んだ。
次回からは同じようにsedを使うようにしよう・・・
#sed -e “/^挿入したい場所の直後の行の内容$/i 挿入したい行” ファイル名
で任意の文字列を挿入できるので、この結果をリダイレクトで別ファイルに書き出せばOK。
実際には元のファイルを一度コピーした上で上記のコマンドに渡し、結果を元のファイルに書き出すようにしたので、結局内容は
$cp 元ファイル名 編集用ファイル名
$sed -e “/^挿入したい場所の直後の行の内容$/i 挿入したい行” 編集用ファイル名 > 元ファイル名
となった。
このスクリプトは応用出来るので、今後は楽になる筈・・・
