More from: linux

Windowsからftpサーバへの接続メモ

先日から「(Windows標準の)エクスプローラーから簡単にファイルサーバにアクセスしたい。」という要望を実現すべくいろいろ試行錯誤していたのでその時のメモ。

WindowsXP以降のOSには標準でftpクライアントが実装されたので、それを使ってftpサーバに接続してファイルのアップロードやダウンロードが出来るようになった。
エクスプローラーのアドレスバーに「ftp://(サーバのアドレス)/」と入れればanonymous(匿名)ユーザーでのアクセスを許可しているサーバならログイン可能だ。
接続できない場合はanonymousログインを許可していないかサーバ側の設定が間違っていることになる。

今回使用したサーバはvsftpdを利用していたので、以下はvsftpd用の設定メモ。
anonymousユーザーのホームディレクトリ(ftp rootになる)はデフォルトで/var/ftp/なので、これを他のディレクトリにしたければ/etc/passwdファイル中のftpユーザーのエントリを書き換えてvsftpdを再起動すれば良い(kill -HUP 1を実行する必要もあるか)。
ここで気をつけなくてはならないのは、ホームディレクトリに一般ユーザーの書き込み許可があるとvsftpdはログインを許可しないので、エクスプローラーからの接続が出来ない。
Linuxから接続しようとすると、
500 OOPS: vsftpd: refusing to run with writable anonymous root
のエラーメッセージが出て接続が拒否される。
なので、ホームディレクトリのパーミッションは755もしくは775にして置く必要があり、ファイルのアップロードを許可するには書き込み可能なサブディレクトリを作成しておく必要がある。
当初はこのことに気付かず実際にアクセスさせたいディレクトリをホームディレクトリに変更したところログインできなくなって焦った(というか変更は出来ないものかと思った)。

なお、接続時にユーザー名を指定して接続する場合にはその必要は無い。
接続時にユーザー名を指定するにはアドレスバーに「ftp://ユーザー名@サーバーのアドレス」と入力し、パスワード入力を促すダイアログボックスが表示されるので、そこでパスワードを入力すれば(そしてパスワードが正しければ)サーバへ接続できる。
下はパスワード入力のダイアログボックス。

ftp接続時のダイアログボックス

ftp接続時のダイアログボックス。


2回目以降も同じユーザー名とパスワードで接続するなら下の「パスワードを保存する」にチェックを入れておけば入力の手間が省ける。

とりあえずここまでやって目的のサーバーに接続できるようにはなった。
今現在少々悩んでいるのがファイル名の文字コードで、sambaユーザーがアップロードした日本語ファイル名がことごとく文字化けして全く意味不明だということ。
読めないだけならまだしも、フォルダ名が日本語の場合にフォルダの中は見れてもファイルを開こうとするとアクセス出来ないのは困る。
この文字コードを統一したいのだけれど、まだそこまでは調べが付いていないので現在も調査中。
まぁ、sambaとftpを別個に運用することも出来るので、どうしても無理なら諦めることにしよう。

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

忘れていたのでメモ(Linuxのログイン方法の変更)

現場のサーバが不調になり再起動してもネットワークに繋がらなくなったので現場でサーバを起動したところグラフィカルログイン画面でキーボードもマウスも効かなくなっていてログインすら出来なかった。
持ち帰って起動してファイルシステムのチェックを行ったところ無事にログインできるようになったが、グラフィカルログインはなにかと面倒(マウスが無いと操作しにくいし)なのでテキストログインに変更した(Xを使いたければログイン後にXを起動すれば良いだけだし)。
切り替え方法を忘れていたのでここにメモしておく。
直すのは/etc/inittabファイルのみ、修正箇所は「id:5:initdefault:」の”5″を”3″にするだけ。
滅多にやらない作業だからつい忘れてしまうんだよねぇ(汗)。

つーか今後作るサーバは最初からテキストログインにしておくことにしよう。

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

anonymousユーザーのroot dir

WindowsXP等にはftpクライアントが実装されていて、エクスプローラー(IEに非ず)のアドレスバーに「ftp://ftp server/」と入れるとそのサーバにログイン出来る。
ログインユーザーはWindowsのユーザー名ではなく、「anonymous」ユーザーとなるので、通常は限定されたアクセスしか出来ないか、サーバーによってはアクセスを拒否される。
「安全性が確保できるのであれば」というのが前提だけど、anonymousユーザーのftp rootを他のディレクトリに(例えばsambaユーザーが使用するディレクトリに)変更すれば、LAN内のsambaユーザーと外からのftpユーザーが同じファイルを共有することも可能と言うことになる。
#反対にftpユーザーのrootディレクトリをsambaで開放しても同じこと(sambaユーザーとanonymous ftpユーザーが同じファイルにアクセスすること)が可能。
anonymous ftpユーザーのrootディレクトリはftpユーザーのホームディレクトリ(/var/ftp等)なので、これを変更すればエクスプローラー上に見えるディレクトリを変更できる。
ホームディレクトリの変更はX上で管理ツールを使っても出来るし、/etc/passwdファイルを直接編集してからkill -HUP 1で行うことも出来る。
ところがこの方法だとサーバ上のアカウントを聞いてくるので、その時に正しいユーザー名とパスワードの入力が必要になる。
しかもディレクトリ内にあるファイルが一部しか見えず、sambaサーバーのような使い方が出来ない。
ホームディレクトリの変更をしないのであれば、ホームディレクトリ内からsambaで開放しているディレクトリにシンボリックリンクを張ることで同様のことが実現可能に思えるが、実際にはこれは出来ず、やってみてもシンボリックリンクがWindowsのショートカットのような扱いをされてしまい、目的のディレクトリにはアクセス出来なかった。

ちょっと実験をしてみたが、今のところsambaサーバーのようには使える状態には至っていない。

でもこれが実現できたら便利になるなぁ・・・・・・もうちょっと調べてみよう。

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

煙草の箱程度の大きさの超小型PCが発売になるそうだ

小型PCにもいろいろあり、CDジャケット大の大きさのPCについては以前このブログでも書いたことがあるが、今回発売になるのは「Sizka-SuperMicroDX」という製品で予想価格は4万円台半ば。
このPCはさらに小さく、サイズは35mmX74mmX64mm(WxHxD)と煙草の箱(20x85x55)といい勝負。
容積にすると約166ccで厚みがある分煙草の箱(約94cc)の倍近くとなっている。
重さは約300gということなので、流石に煙草よりは重いがPCとしては驚異的な軽さだ。
消費電力も僅か3.5Wとのことなので、1日中起動しておいても電気代は安く済みそうだ。

こんな大きさでもx86互換CPU(Vortex86DX、800MHz動作)を搭載しているので、WindowsOS(ただしXP以前のもの)が動作するそうだが、メモリインターフェースが16bitなので800MHz動作のCPUとしては遅いそうだ。
しかもx86互換とはいえ機能的には486DX同等でMMX以降の拡張命令は非搭載なので、あまり新しいOSやソフトは動作しないかも。
つまりこのPCのCPUは「800MHzで動作する486DX」と言えそうだ。
メモリはDDR2-333を512MB搭載し(増設不可)、グラフィックスはなんとVolari Z9s(VRAM64MB)を搭載している。
#販売代理店(アイティーシー)のサイトにあるPDFファイルにはメモリ容量が512KByteとの表記もあるが、512Mbyteとの表記もあるのでこれは誤りと思われる。
このPCにはOSとして”CPU内部”のフラッシュROM領域にFreeDOSがプリインストールされていて、そこにはBASICやスクリーンエディタ・MASM準拠のアセンブラ等も入っているのでプログラムを作って遊ぶことが出来るとのこと。
またCPUメーカーが作成したX-Linuxも動作するので、添付のUSBフラッシュメモリにはX-Linuxのイメージが格納されていて、直接USBメモリからの起動が可能とのこと。

ストレージ用にオンボードでCFスロット(外部から抜き差し可能)とMicroSDHCスロットが用意されていて(ただし排他使用)、そこにOSをインストールして動作させることも可能だ。

スペック的に通常使用するためのWindowsPCとするには無理があるが、超小型PCマニアには格好のアイテムとも言えそうだ。

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

終わってなかった・・・・・・・・

昨日不調になりHDDをチェック中のサーバで走らせていたfsckは朝になっても完了していなかったorz
I/Oエラーも出ているので最低でもHDDの交換は必要になりそうだ。
つーか今時CPUクロックがMHzで表せるマシンがサーバというのもなんだかなぁ?と。
なので本体ごと交換することになると思われる。
見積りを頼もうと思ったら、販社さんが軒並み休みだという事実に愕然としてしまった。
正月休みは3日までじゃ無いのかよー!(笑)

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

fsckが終わらない・・・・・・・・

不調になったサーバのファイルシステムをチェックしているけど、しばらく経ってもfsckが終わらない・・・・・・
この分だといつまでかかるか判らないから、サーバはそのままfsckを走らせたままにしてそろそろ引き上げるかなぁ?
いくらなんでも明日の朝には終わっているだろう(と思う)。

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

サーバが壊れた(涙)

今日行った現場で搬入したサーバの1台が起動しなくなっていた。
通電すらしない状況なので現場ではどうすることも出来ずお持ち帰りと言うことに・・・・・・・
職場に持って帰ってきて電源ユニットを取り替えてみると電源が入ったので、電源ユニットの故障だった。
ひとまず安心したので本格的に電源ユニットを取り付け、念のためにOS(Linux)を含めてチェックをすることにした。

電源を入れBIOSの設定画面を出すと案の定バックアップ電池が切れていたようで日付等が初期状態になっていた。
日付を初めとして設定を変えている項目の設定をし直して再起動。
無事にOSが起動してくる・・・・・と思いきや自動で走ったfsckがエラーを報告してきて、自動では復旧できないからメンテナンスモードに入って自分でfsckをかけろと言って来た。
仕方が無いのでrootパスワードを入力して手動でfsckをかけたらエラーがたっぷり・・・・・・・・
電源を切る際にどうやって切ったんだ?と思うほど。
仕方が無いのでファイルシステムを復旧しているが結構な量のエラーがあるなぁこりゃ。
しかもI/O errorまで出してくるので、HDDが本格的に駄目になる寸前かも?
数日間寒いところに置いてあったからかもしれないので、しばらくは電源を切らずに放置してみようかな?

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

clockコマンド

linuxでシステム時刻とCPU時刻(BIOSの時刻)は別物であり、起動時はCPU時刻を基準としてシステム時刻がセットされる。
#linuxに限らずWindowsOSでも同様。
CPU時刻はPCの内蔵時計の時刻だが、この時計が思いのほか精度が悪い(笑)。
なので一度起動するとしばらく止めることの無いサーバの場合、気付くとかなり狂っていることがある。
linuxには時刻を自動で合わせてくれるntpという仕組みが用意されていて、ディストリビューションによってはデフォルトでインストールされる。
これはタイムサーバと呼ばれる時刻の基準となるサーバとシステム時刻を同期してくれる仕組み。
ただ、ntpで修正されるのはシステム時刻だけで、CPU時刻は修正されない。
そのままではシステム時刻とCPU時刻が大きく乖離してしまい、再起動になかなか時刻の同期がされないことにもなりかねない。
多くのシステムではシャットダウン時にCPU時刻をシステム時刻に合わせるように動作するが、これはシャットダウン時に呼び出されるスクリプト内で実行されている。
それでも不意の電源断等でシャットダウン処理がされない場合はCPU時刻とシステム時刻は同期しない。

任意のタイミングでCPU時刻をシステム時刻に合わせるためには”clock”コマンドを使うことになる。
このコマンドはオプションを何も付けないで実行すると現在のCPU時刻を表示してくれる。
システム時刻をCPU時刻に設定するにはスーパーユーザーで
#clock -w
と”-w”オプションを付けてclockコマンドを実行するだけ。
これでCPU時刻とシステム時刻が”ほぼ”一致する(コマンド実行のオーバヘッドがあるので完全に一致はしない)。
長期間動作させるサーバでは一日に一度程度このコマンドを実行するのが良いと思う(crontabに登録すれば簡単)。

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

またまたntpでタイムサーバと同期できないサーバがあった

以前にもntpでタイムサーバと同期できないサーバが有り、なんとか同期を取れるように出来た。
今回久しぶりに触ることになったサーバも時刻同期が取られておらず、1時間近くも時計が狂っていた。
見るとntpデーモンは動作しているが、/usr/sbin/ntpdcで見るとタイムサーバ(ローカル)と同期が取れていない。
設定ファイル(/etc/ntp.conf)を見てもサーバの指定に特に間違いは無かったが、そのサーバ名が/etc/hostsに書かれておらず名前解決が出来ない状態だった(爆)。
「なーんだ、これが原因かぁ」
と思ってサーバ名とIPアドレスを書き加えてntpdを再起動したが相変わらず同期が取れない。
/usr/sbin/ntpdcで確認するとタイムサーバからの応答が来ないようで、”receive timestamp:”の部分がいつまで経ってもオール”0”のまま。
他のサーバからは問題無く指定したタイムサーバと同期が取れているので、タイムサーバ側の問題とも思えない。
不思議なことにntpdateコマンドでは同期できるので、123番ポートが塞がっているとか、パケットがフィルタリングされているとかでも無い。
/usr/sbin/ntpq -p タイムサーバ名
でもタイムサーバ側が親サーバと同期している状態が見える。
なので、プロトコルやネットワークの問題では無く、件のサーバのntpdの問題のように思われる。
ntp.confで指定するセキュリティがきついのかとも思ったが、/etc/ntp.conf内にはそもそも”restrict”で始まる行が無い(全ての接続を許可している状態)。
駄目元でntpのセキュリティ設定を他のサーバと同様に設定してみたがやはり同期できないorz
うーん、一体どうなっているんだろう?
とりあえず大きな狂いはntpdateで直したからもうしばらく悩んでみるかぁ(爆)

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

またまたsendmailの設定を見直した

2008年11月18日の記事「sendmail」ではsendmailにDNSサーバを参照させない方法を書いた。
たまたま別のサーバのメンテをしていて、root宛のメールが大量に滞留していたので見てみると宛先のサーバ名が引けないで送信できずに残っているものだった。
しかもこのサーバではsendmailを始めとするMTAが動作しておらず、メールを出そうとしても送信queueに溜るだけだったorz

そこで送信先のサーバ名を/etc/hostsファイルに追加して(ローカル環境なのでhostsファイルに書けば十分)、MTAとなるsendmailにDNSサーバを参照させないように
hosts files
の一行だけを書いた
/etc/service.switch
ファイルを準備し、sendmail.cf内の
#O ServiceSwitchFile=/etc/service.switch
の行頭の”#”を削除(コメントアウトを外)して有効化し、sendmailを再起動した。
これで件のサーバが出力するメールは無事に目的のサーバに届くようになった筈だったが、最初は正しく設定したはずが何故かきちんと配送されずに「???」だった。
そこでsendmail.cfを見直すとservice.switchファイルの場所を間違って記述していた。
再度sendmail.cfを修正してsendmailを再起動したところ無事に届くようになった。

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