特にテーマを定めず気楽に書く日記（主に温泉やパソコン、アニメ、カメラに関することになるかな？） リンクはトップページ、個別記事のどちらでもご自由に。写真等の転載は該当記事へのコメント等でご連絡を頂けるとブログ主が喜びます。＃記事内の商品紹介等にはアフィリエイト広告を含みます。
またまた現場のサーバーにてftpサーバーを動作させる必要が出来た。
まずは明日行く福岡の現場にあるWindowsサーバーでは既にftpサーバーを動作させていると思いこんでいたら、実は動作しておらず接続拒否をされてしまう。
そこでIISマネージャーから設定しようとしたら、IISそのものが動作していない・・・
仕方が無いのでIISも含めてftpサーバーの設定を行った。
もう一か所はLinuxサーバーでパッケージとしてはgssftpなので、/etc/xinetd.d/gssftpファイルを編集して最後の行の
disable = no
を
disable = yes
に書き換えてxinetdを再起動・・・で済む筈が、これだけではユーザー認証で弾かれてしまうので、先月二十日に書いた記事「gssftpの設定」を参考にさらに2行前の
server_args = -l -a
を
server_args = -l
に書き換えてxinetdを再起動。
これで通常通りにログインが可能になった。
←クリックしてくれると嬉しいです。
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コマンドが無くて設定できなかった）。
接続もログインも出来るのにデータの送受信でタイムアウトになる場合はお試しあれ。
←クリックしてくれると嬉しいです。
何年か前に遠隔地にサーバーを設置したが、その現場にちょっと大きめのデータを送る必要が出来た。
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を再起動すると無事にログインすることが出来た。
←クリックしてくれると嬉しいです。
昨日大量に設定ファイルを書き換えたところ、今朝になってちょっとした問題が発生していた（汗）。
結局もう一度同じファイルに記述を追加することが必要になったのだが、今度も追加するのはファイルの途中。
昨夜と同じにviで編集するのもなんなので、ちょっとググって出てきた方法を使うことにした。
sedを使う方法なのだが、試しにコマンドラインから実行してみると簡単に出来たので、この方法で実行することにして簡単なスクリプトを書き、それを昨夜と同様にfor文で回して実行。
実行にかかった時間は僅か数秒だったので、昨夜時間を掛けたのはなんだったの？といった感じ（汗）。
実際にスクリプトを書くために調べ始めてからも30分程度で済んだ。
次回からは同じようにsedを使うようにしよう・・・
#sed -e “/^挿入したい場所の直後の行の内容$/i 挿入したい行” ファイル名
で任意の文字列を挿入できるので、この結果をリダイレクトで別ファイルに書き出せばOK。
実際には元のファイルを一度コピーした上で上記のコマンドに渡し、結果を元のファイルに書き出すようにしたので、結局内容は
$cp 元ファイル名 編集用ファイル名
$sed -e “/^挿入したい場所の直後の行の内容$/i 挿入したい行” 編集用ファイル名 > 元ファイル名
となった。
このスクリプトは応用出来るので、今後は楽になる筈・・・
←クリックしてくれると嬉しいです。
今日の仕事もそろそろ終わりと思っていたところにトラブルの連絡が入った。
急いで対応して当面の対策は済んだが、根本の原因に対しては数百個の設定ファイルの修正が必要になったorz
修正内容は一行だけ記述を追加するということなんだけど、悪いことに殆どのファイルの先頭に追加しなければならないので、単純に
$cat xxx >> 設定ファイル名
とすることが出来ない。
幸い追加する内容は全く同じだし、設定ファイルのファイル名も全く同じ。
ファイルの場所のみ異なるがディレクトリパスも最後のみ以外は同じなので、for文でファイル名を取り込みながらviで修正することにした。
追加する内容とコマンドの一部をクリップボードにコピーしておいて、単純にペーストと3回のキータッチだけで作業できるようにして一気に対象となる全部のファイルを書き換えた。
あー、めんど（爆）
#for i in `ls /ディレクトリ/*/設定ファイル名`;do vi $i;done
としたあとは単純作業の繰り返しだったよ・・・
1%ほど単純な修正で済まないファイルもあったので、目視でチェックしながらの作業の方が完全に自動化するよりも良かったな。
←クリックしてくれると嬉しいです。
Linuxで使用しているFTPサーバーが”vsftpd”の場合、ローカルユーザーがアップロードしたファイルのパーミッションをコントロールする方法。
設定ファイル/etc/vsftpd.confにある次の行でコントロールしているので、そこを適宜書き換える。
local_umask=numeric (Default:022)
デフォルトでは”022”となっているので、そのままだと”644”（rw-r–r–）になる。
これを”000”にすると”666”（全ユーザー書き換え可能）になる。
セキュリティを考えると少なくとも”002”にしておいたほうが良いかな。
←クリックしてくれると嬉しいです。
先日から作っていたファイルフォーマット及び文字コード変換用のスクリプトがようやく形になった（汗）。
元のファイルの中に複数の形式のレコードが混在していたので面倒だったけど、そこはなんとか力技で押さえ込んだ。
てこずったのが特定の文字（全角の長音記号）が元のコード（SJIS）から他のコード（EUC,UTF-8）に変換できなかったこと。
いろいろ調べてみたけど皆さん苦労していらっしゃるようで上手い解決策が見つからなかった。
仕方が無いのでテキストエディターで開いて全角のハイフンに一括変換をかけることで対処した。
元のファイルが三十数個程度だったのでこんな荒業が使えたけど、これがファイル数が三桁だったらやりたくないよなぁ・・・
どうにかして自動で変換できないものか・・・
←クリックしてくれると嬉しいです。
先日仕事でスクリプトを書いた。
簡単なcsvファイルのフォーマット変換用のスクリプトだったんだけど、久々にawkを使ったら構文をすっかり忘れていた（汗）。
基本的な書き方は覚えていたんだけど、ifやらwhileの使い方があやふやだったのでネットで検索。
こういう時はネットはありがたいな。
←クリックしてくれると嬉しいです。
bashの脆弱性に対する対策で先週bash-3.2.22からbash-3.2-33.el5_10.4に上げたばかりなんだけど、今日yumでチェックしたらbash-3.2-33.el5_11.4が出ていたらしいので早速アップデートした。
とはいえ、このバージョンはRHEL5のバージョンが5.11なので出たらしく、CentOS用のel5_10.4との違いは全く無いらしい。
それでも出来るだけ新しくしたほうが気分的に良いからそのままにしておこう（笑）。
3.0-27（EL4）のほうはOracleのサーバを見てもbash-3.0-27.0.3以降はまだ無いみたいだな。
こちらも引き続きチェックをするように心掛けておこうっと。
←クリックしてくれると嬉しいです。
先週の金曜日（9/26）に書いた「bashの脆弱性対策」の被参照数が今日になって増えている。
週末の休みが終って対策に奔走する羽目になったサーバー管理者の方々が多いのだろうか？
まぁ先の記事にはyumが使えない場合の手順も書いたからそのせいかな？
先の記事を書いた後にさらにパッチが公開されているので、ホントは「bashが「CVE-2014-7169」に仮対応」とか「さらにパッチが当っている模様（bash）」のほうが参考になると思うけど（汗）。
←クリックしてくれると嬉しいです。