昨日、「”grep”で行の完全一致を見つける」という記事を書いた。
その後少々検討した結果、改行コードをWindows（CR+LF）に揃えることで解決した。
実際に改行コードが異なるファイルで検証してみると”-x”オプションを付けると不一致とみなされたが、揃えると（当然だが）一致とみなされたのでWindows上での扱いを考えてCR+LFに統一した。
そもそも改行を何故LFのみにしていたのか思い出せ無いが、とりあえず上手くいったので良しとしよう（汗）。
More from: linux
←クリックしてくれると嬉しいです。
”grep”で行の完全一致を見つける
Linux上でファイル操作をしていて、あるファイルの中から別のファイルにある行と一致する行を取り除きたい。
単純に考えると
#grep -v -f hoge.txt gesho.txt
で出来るんだけど、この場合はhoge.txtのとある行を”含む”行が全て取り除かれてしまう。
例えばgesho.txtの中身が
“This is a pen”
“This is a pencil”
の2行だったとして、hoge.txtに
“This is a pen”
があると2行とも取り除かれてしまう。
そこで、行の完全一致のオプション”-x”を付けて
#grep -v -x -f hoge.txt gesho.txt
とすれば解決・・・の筈だったんだけど、実際には一致する行が無いと判断されてしまった。
理由はhoge.txtとgesho.txtで改行コードが異なっていた為orz。
Windows上で扱う関係でgesho.txtはCR+LFでないと困るが、反対にhoge.txtはLFである必要があって統一できない。
さて、どうするかなぁ？（汗）
grepに渡す時だけ”dos2unix”で改行コードを変換して、終わったら元に戻すのが簡単かな？
←クリックしてくれると嬉しいです。
”Output file suffixes exhausted”が出た。
linux上でファイルを分割するのに”split”コマンドを使っていて、”Output file suffixes exhausted”というエラーが出た。
読んでの通りで出力ファイルの接尾語が使い尽くされたということで、デフォルトの接尾語（aa-zzの676種）では足りなくなった。
これを回避するには”-a”オプションで接尾語の文字数を指定すれば良いということ。
今回の場合はスクリプト内に”-a 3”を追記したので、これまで2文字だった接尾語が”aaa-zzz”の3文字（17,576種）になり、事実上接尾語が足りなくなることは無くなった。
←クリックしてくれると嬉しいです。
Linuxでファイル分割
Linux上でテキストファイルを行単位で分割して加工するスクリプトを作っている。
テキストファイルの分割は”split”コマンドを使えば簡単なんだけど、その際に分割されたファイル名が”指定したベース＋aa~zz”とアルファベットが追加された名前になってしまう。
分割されたファイル単位で処理をするので、ここは数字の方が扱いやすい。
どうにかならないかと思って調べてみたら、”-d”オプションで数字（デフォルトでは二桁）になるらしい。
早速試したところ”そんなオプションは無ぇ！”と怒られてしまったorz。
確かにヘルプを見てもそのオプションは無いので、どうもsplitが古いバージョンのもののようだ（汗）。
新しくするのも面倒だったのでスクリプトのループを変えて対処してしまった。
←クリックしてくれると嬉しいです。
ファイル名の途中に16進数を入れる方法（sh）
Linuxのshスクリプトでファイル名の途中に16進数を連番で入れる方法を探っていてようやく出来たのでメモ。
また、ファイルが存在する間だけ処理をするのでループ化している。
#!/bin/sh
no=0 #通し番号初期化
end=1 #ループ終了条件初期化
while test $end -eq 1
do
ファイル名=（必要なら）ディレクトリ名/固定文字列`printf %X$no`固定文字列
if [ -e $fname ];then
処理
no=$((no+1)) #通し番号インクリメント
else
end=0
fi
done
printf書式内のXはA-Fで表記するため、小文字の場合は%xにする。
さらに桁数固定なら%4Xのように桁数を指定する。
←クリックしてくれると嬉しいです。
巨大なテキストファイル・・・
メールの受信が出来なくなったとの連絡があって調べてみたら、サーバー上のスプールファイルが2GBに達していた。
これではpop3でのログインだけでも時間がかかってしまうので、悩んだ挙句分割することにした。
サーバー上でバックアップをとってからそのバックアップファイルをviで開こうとしたが、しばらく経っても開き切らない（汗）。
そこでPC上で分割してからエディターで開いて加工をしてスプールに戻したが、この作業に数時間を費やしてしまったorz。
問題のアカウントに来るメールを一部別アカウントに振り向けたのでしばらくはこんなことは無いと思う。
←クリックしてくれると嬉しいです。
改行コードか！
Linuxファイルサーバ上のテキストファイルを操作していて特定の文字列を取り除きたかった。
そこで
grep -v -f aaa.txt bbb.txt
を実行したところがaaa.txtに書いてある文字列がbbb.txtに残ってしまう。
エディター上で文字列を見比べてもタイプミスは見当たらない。
おかしいなぁ、と思ってgrepのヘルプを見て思いついたのが改行コード。
ファイルの作成＆編集はWindows10上で行っているので改行コードはCR+LF。
Linuxでは通常LFのみなので試しにaaa.txtの改行コードをLFだけにしてみたらうまくいった（bbb.txtはそのままでもOKだった）。
未だにこんなことで悩まなくてはならないなんて私もまだまだだな（汗）。
←クリックしてくれると嬉しいです。
IBMがレッドハットを買収？
米IBMがLinux ディストリビューターのRedHatを買収すると発表した。
法的な問題がクリアできれば買収は2019年中に完了する見込みとのこと。
RedHatと言うとLinuxの普及に大いに影響を与えた企業で、現在はデスクトップ用のLinux開発はFedoraプロジェクトに移管し本体は企業向けエンタープライズ事業及びクラウド事業を進めている。
IBMとは以前からエンタープライズ事業で協力してきており、今回の買収はIBMがRedHatのもつクラウド事業に目を付けたものと報道されている。
私も何度かRedHatLinuxをPCにインストールしてサーバーとして使ったりしていたが、まさかIBMが買収するとはねぇ、、、
←クリックしてくれると嬉しいです。
NFSがつながらない・・・（解決編）
先日、「nfsがつながらない・・・」という記事を書いた。
その時にはクライアント側のサーバー（ややこしいな）の再起動をすれば解決するのでは無いかと考えていた。
今週に入って再起動の機会がある筈だったので、その時までなんとか我慢して運用かと思っていたところ、土曜の夜にトラブルで再起動の必要なサーバが止まってしまい、図らずも再起動となってしまった。
このことを知ったのは月曜になってからだったんだけど、早速nfsマウントを試してみるとやっぱり接続できないorz。
つまり、nfsサーバを先に停止したことが障害の原因では無かったということになる。
クライアント側に出るエラーは
”ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
と以前と同じものなので、やはりnfsサーバ側との通信が出来ていないことになる。
portmapperでは無いかとの指摘もあったが、nfsサーバ側のrpcinfoの結果を見る限りportmapperは動作している（ディストリビューションの関係で”portmap”ではなく”rpcbind”だったが）。
いろいろ考えた結果、ファイアウォール（iptables）に思い当たり、試しに/etc/rc.d/init.d/iptables stopで止めてみると、クライアント側からのrpcinfoコマンドにnfsサーバ側が応答してくるようになり、さらにnfsマウントも試したところ無事にマウント出来た。
つまり、先週から悩んでいたのはiptablesが原因だったということだ（汗）。
そこで、iptablesの設定で必要なポートを開けようとポート番号を調べてみたところ、現状で使っているポートが以下のようになっていた。
（rpcinfoの出力）
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 60503 mountd
100005 1 tcp 35344 mountd
100005 2 udp 48471 mountd
100005 2 tcp 42678 mountd
100005 3 udp 50205 mountd
100005 3 tcp 41105 mountd
100024 1 udp 56315 status
100024 1 tcp 57525 status
これを見るとmountdとstatusの二つは任意のポートを使っているようだ。
これではiptablesで沢山のポートを開けなくてはならず、セキュリティ的に不安なので使用するポートを固定する方法を調べた。
ポートを固定するにはnfsの設定ファイル（/etc/sysconfig/nfs）でコメントアウトされているポート番号（*_PORT）の項目のコメントアウトを外してnfsを再起動すれば良いとのこと。
早速実行してクライアント側でrpcinfoを実行してみた結果が下。
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 892 mountd
100005 1 tcp 892 mountd
100005 2 udp 892 mountd
100005 2 tcp 892 mountd
100005 3 udp 892 mountd
100005 3 tcp 892 mountd
100024 1 udp 662 status
100024 1 tcp 662 status
mountdが892、statusが662で固定されたので、それらを含む必要なポートをiptablesで開けるように設定したところ、iptablesを動作させてもnfsでのマウントもファイルへのアクセスも可能になった。
※当然ながらportmapperのポート（111）も開けるように設定した。
いやぁ、良かった良かった（汗）。
←クリックしてくれると嬉しいです。
boot時のfsckの回避方法
Linuxサーバの再起動が必要になるのがほぼ確実なんだけど、1200日以上無停止で稼働しているサーバなので、再起動時にfsckが走ることになる。
そうなると起動が終わるまで長時間サービスを停めることになるので出来ればfsckを走らせたくない。
調べてみると起動時のfsckの実行を抑止する方法があった。
一つ目はfstabの6つ目のパラメータを”0″にする方法で、これだとヴォリュームラベル/デヴァイス単位で設定出来る。
二つ目はshutdownコマンドのオプションで”-f”（fastboot）を指定する方法で、このオプションを付けると”/”にfastbootというファイルを作成し、次回のboot時にbootプロセスがfsckをスキップする（ことを期待する）。
今回は全てのディスクのfsckをスキップさせたいので、”shutdown -f -r”を試してみようかな？
問題は短時間とは言え提供中のサービスを止めるのでタイミングをどうするかだなぁ（汗）。
←クリックしてくれると嬉しいです。