More from: linux

未だに4800bpsなのか・・・・・・

PC用のGPSレシーバ(I-O DATA 高感度USB接続GPSレシーバー「NAVI CLIP」 UMGPS/MF
)の仕様を見ていると、PCへのデータ転送速度が4800bpsとなっている。
この製品はUSB接続の製品なのだが、昔のRS-232C接続の製品もこの速度だったので、未だに変わっていないようだ。
10年ほど前にDebian GNU LinuxをベースにGPSレシーバとFOMA端末を接続した小型システムを開発したことがあるが、その際GPSレシーバとの通信速度が4800bpsというのがネックになった。
というのは当時でもLinuxのシリアルドライバで設定できるRS-232Cの通信速度は9600bpsが最低で、それ以下の速度に設定することが出来なかったため。
ハードウェアとしては16550A互換のUARTなので、150bpsといった低速の通信速度にも対応しているが、Linuxのシリアルドライバがそれに対応していないために、そのままでは4800bpsでの通信が出来ない。
16550Aの通信速度は2バイトのレジスタの内容で決定されるが、Linuxのドライバはその内の1バイトしか書き換えないらしい(9600bps以上ならそれでも設定可能)ので、プログラムで該当のレジスタ(分周レジスタ)を直接書き換えるようにして4800bpsでの通信を可能にしてGPSレシーバから座標データを読み込めるようにした。
この時はC言語でプログラムを書いていたが、レジスタを直接書き換えるのには「outb」関数を使った覚えがある。
#outb(0x80,レジスタのアドレス)ってな感じで。
つか、こんなプログラムを書かないと使えないデバイスってどうよ?と思ったのは内緒(笑)。

似たようなことを一昨年にも書いていた(汗)
「Windows用ddコマンド」

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

ネットワークの分離

職場のネットワークを分離するのに安いブロードバンドルーターを買ってきて試したが、あっさりと分離できてしまった。
単にルーターの設定で「アドレス変換をしない」「WAN接続はIPアドレスを手動で設定」の2点を設定しただけ。
あとは元のネットワーク上に存在するサーバ類にstatic routeを設定すれば今までどおりにサーバーへのアクセスも可能だし、プリンタへの印刷も問題なく行えた。
サーバーへのstatic route設定は最初に手動で行い、再起動後も設定がされるように設定ファイルにも書いておいた。
linuxでのroute設定は、
/sbin/route add -net 192.168.xxx.0/24(追加したネットワークアドレス) gw 192.168.yyy.zzz(ルーターのIPアドレス)
設定ファイルは
/etc/sysconfig/static-routes
なので、そのファイルに
any net 192.168.xxx.0 netmask 255.255.255.0 gw 192.168.yyy.zzz
の記述を追加すると、起動時に自動でルーティング情報が設定される。
もしもこのファイルが無ければ新しく作ればOK!

ちなみに今回使ったルーターはこれ。
BUFFALO BBR-4MG 有線BroadBandルータ BroadStation エントリーモデル
B0000DJLOE
2千円ちょっとで買えるけど、複雑なルーティングとかをせずに、単にネットワークを分離するくらいならばそこそこ使えると思う。

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

printcapの書き順で変わるのかな?

職場のプリンタを一台ネットワークプリンタに替えた。
今までLinuxサーバのパラレルポートに直結していたプリンタが不調になり、買い換えたプリンタがUSBとLANのポートしか持っていないので、仕方なくネットワークで接続することになった。
で、Linuxサーバ側のprintcapをリモートプリンタ対応に修正(問題なく印刷されているもう一台のプリンタ用の設定をコピーしてきて、リモートホスト名とスプールディレクトリ名を書き換えた)してlpdサービスを再起動したが、印刷がされない(あれ?)。

今まで他所ではこれで良かった筈なんだけど、今回は何故か素直に印刷されない。
lpc status lp
を実行してみるとスプールには溜まっていて、リモートホスト(この場合はプリンタのネットワークインターフェース)にデータを送信しているとなっているが、プリンタ側のjobランプは消灯したままなので、データは送られていない。
lpd restart lp
を実行すると印刷されたので、どうやらプリンタには異常は無さそうだ。
ここで再度印刷をしてみたが、やはりサーバのスプールに溜まるだけで一向にプリンタにデータが送られない。
しかも今回は
lpd restart lp
としても印刷されず、
/etc/rc.d/init.d/lpd restart
を実行してlpdサービスを再起動し、その後に
lpd restart lp
を実行してようやく印刷された。
うーん、何故?

結局のところ他所のサーバのprintcapの中身を参考にして行の順番を一部入れ替え、
/etc/rc.d/init.d/lpd restart
を実行したところ無事に印刷が出た。
数度印刷を繰り返しても素直に印刷されるので、原因はprintcapの記述にあったようだ。
必要な事項は全て記述しておいたのだが、行の並びも大事だったようだ。
でも、もう一台のプリンタは問題なく印刷されるんだよなぁ、、、、、、何故?

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

Linuxでタイムゾーンの変更を行うには

職場のサーバの時刻が狂っていたので、タイムサーバーに同期させたところ、分と秒は合ったが時がおかしくなってしまった。
あれぇ?と思ってよく見ると、時刻表示の最後の部分が”JST”ではなく”CST”になっている。
このサーバを構築したのは自分では無いのでインストール時にどのような設定を行ったかは知らないが、タイムゾーンが日本では無く、合衆国中部標準時になっている。
これを日本標準時にするのに下記の手順を実行した(全てスーパーユーザーにて実行)。
#cd /usr/share/zoneinfo/Asia
#cp Tokyo /etc/.
#cd /etc
#mv localtime localtime.org(念のためバックアップを取った)
#cp(or mv) Tokyo localtime
要はタイムゾーン情報を合衆国中部標準時用のファイルから日本標準時用のファイルに入れ替えたということ。
なにも実体のファイルを入れ替えなくても、次のようにしてシンボリックリンクを張っても良いと思う。
#ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
というか、こっちのほうがスマートかも。

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

「時計が進まなくなるサーバ」のその後

昨年12/13に書いた記事「時計が進まなくなるサーバ」で取り上げたThinkCentreを転用したサーバーだが、起動オプションに”noapic acpi=off”を付けて再起動してから三週間が経過しても問題無く動作を続けている。
やはりカーネル内部でのハードウェアタイマ割り込みの処理がうまく行っていなかったようだ。
実は年末前にチェックした時も問題無かったので、そのまま年末年始の休みに入ったというわけ。
年が明けても問題が無いようなので、これでこの問題で手を煩わされることも無いかな?

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

先日止まっていたDNSサーバ

先週末の土曜日にサービスが止まっていたDNSサーバに駄目元でリクエストを出したらきちんと名前解決が出来た。
ということは、12/11はなんらかの理由で一時的にサービスが止まっていたということか?
ま、なんにせよ復活してくれて良かった良かった。
だけど、また止まったら困るので、参照順位は最後にしてあるけどね。

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

時計が進まなくなるサーバ

以前から時々時計が止まってしまい、それにともなっていろんなサービスが止まってしまうサーバがあるが、ここ三日間で三度のリブートをする羽目になった。
流石にこのままでは年末年始の休み期間中が不安なので、再度調べてみた。
稼動させているハードウェアがIBMのThinkCentreだということを思い出し、それでググってみた。
というのも過去にThinkPadにLinuxを入れたところ多少のトラブルがあったことを思い出したから。
そうしたところ、数は少ないながらも似たような事象が報告されているのを発見。
複数のサイトで見つけた対処法はapicの無効化というもの。
なので、/boot/grub/grub.conf内の
kernel /vmlinuz/xxxxxxxxxxxxxxxxxxxx の行の最後に”noapic acpi=off”の記述を追加してみた。
リブートしないと結果は判らないが、流石にサービスに支障がない状態で停めるわけにもいかず、明日の早朝に再起動し、その後経過を見ることにした。
これで解決してくれると助かるけどなぁ・・・・・・・・・・

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

CENT OSのインストールCD

RED HAT系のフリーのOSであるCENT OSは現在5.5が最新らしいけど、インストール用のイメージファイルを見てびっくり。
なんとCD-ROMだと7枚にもなるのね、、、、、、
DVDのイメージだとファイル容量が約3.9GBなので、こっちだと一枚で済むけど、最近購入したサーバだとDVDからのインストールで躓くことが多いので、CD-ROMのインストールメディアを作ることにした。

それにしても7枚かぁ、、、、、、、、、、焼くのが面倒だなぁ(爆)

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

タイムサーバに同期できないサーバがまだあった・・・・・

10/19付けの記事「NTPで時刻同期が出来ないサーバ」で書いたようなサーバがまだあった。
ファイルサーバにしているサーバの時刻が狂っていて、保存したファイルの更新時刻が未来の時刻になっていることに気付き、調べてみると前回と同様にタイムサーバに同期できない状態だった。
原因は前回と同じで自分自身のみしかアクセス出来ないようにしていたので、対処方法も前回と同じにしたところ、無事に同期動作が始まった。
うーん、普段問題なく動いていると監視が疎かになるなぁ、、、、、、

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

delegatedがようやく動いた・・・・・・・

先月半ばに原因不明でハングアップしたサーバを無理やり再起動したが、それ以来delegatedが起動しなくなっていた。
とりあえず動かなくても支障は無かったのだが、今朝になって「○○にftpが繋がらないんだけど」と言われて調べてみると、delegated経由でftp接続していたことが判明した。
それで再度delegatedを動くようにしようとしたが、MD5値が違うというよくあるエラーで起動しない。
これは再コンパイルで解決することが多いのだが、実は前回もこのエラーで起動できずに再コンパイルは実施済み。
それでも起動に失敗するので、ダウンロードしてあった最新版のソースからmakeして実行モジュールを作り直した。
ところがこれでも起動できないので、「もしかして起動方法が間違っているのではなかろうか?」と思い、起動手順を見直してみた。
すると、設定ファイルで指定していると思ったポート番号が実際には設定されておらず、そのため「NO ACTIVE PORT」のエラーも出ていた(爆)。
しかも設定を外部ファイルに記述した場合に引数で渡す方法を間違っていたことが判明(汗)。
起動用スクリプトは環境変数の設定等を行うだけで、あとは渡された引数をそのままdelegatedに渡すだけ($*)だったので、起動時の引数の渡し方を変えたらすんなりと起動してくれた。
要は今まで
delegated.sh(起動用スクリプト名) 設定ファイル名
としていたところを
delegated.sh -Pポート番号 +=設定ファイル名
としただけ。
この設定ファイル名の渡し方が間違っていたために起動してくれなかった訳だ(ポート番号も指定していない)。
久しぶりに触ると忘れてるなぁー、というわけで備忘録代わりにここに書いておこう。

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