頂き物の月末処理をcrontab (vixie-cron) にて妙なことに気づく。下記の処理は28日から31日の間、毎日翌日が1日である事をチェックさせて、該当する場合にコマンドを実行する。28-31のちょっとした工夫がちょっと好み。しかし、
55 23 28-31 * * /usr/bin/test $(date -d '+1 day' '+%_d') -eq 1 && [Command]
とすると
/bin/sh: -c: line 0: unexpected EOF while looking for matching `)' /bin/sh: -c: line 1: syntax error: unexpected end of file
このようなエラーが出てしまう。なんぞ・・・で、正解を書くと
55 23 28-31 * * /usr/bin/test $(date -d '+1 day' '+\%_d') -eq 1 && [Command]
"%"についてはエスケープをしなければならないらしい。Cronにて%を使った何か特殊な書き方があるのだろうか。いや、しかしそれでも''や""で括ったものについては無視をして頂きたいところなのですが・・・何にしても妙なところでエスケープが必要な事に気づき驚く。もしかしてvixie-cronは何か高度な書き方が用意されているのだろうか？ ・・・いや、複雑な事するならシェルスクリプトを定期的に回しますよね。
ひょんなことからProcmailにてメールを振り分けるなど。特定の一覧から愚直にアドレスを遮断できること、ある程度簡単に登録をできること、を目標に速やかに動く。というかレシピをググって使うだけ…なのであったが思わぬ罠が潜んでいたり。
Procmail の紹介とレシピの書き方 よりBLACKLIST=$HOME/.blacklist :0 Wh * ? test -s $BLACKLIST * ? (formail -x From: | fgrep -iqf $BLACKLIST) /dev/null :0 E !hogehoge@example.com
これだけの簡単なお仕事・・・の筈だったが、何故か全ての状況でElse的な条件のの転送が使われてしまう。明らかに真となるようなgrepのオプションや引数を用意しても条件に引っかからない。ところでふと思ったのだけれど作られた言語云々は置いておいて(いずれもCだが) formailも結局は標準入力からのメールのヘッダ抽出つまりはただのテキスト処理であることに気がつく。ので。
BLACKLIST=$HOME/.blacklist :0 Wh * ? test -s $BLACKLIST * ? fgrep -iqf $BLACKLIST /dev/null :0 E !hogehoge@example.com
ですので、私はこうしてみた。はい、条件に引っかかるようになりました。処理速度を考えなければfgrepをgrepにしてもよいかもしれない。というか初めてgrep/egrep/fgrepを意識した気がします。fgrepはやい！
$ cat ~/test.eml | formail -x From: | grep -iqf ~/.blacklist $ echo $? 0
さて、このようなコマンドで試したり、それぞれの結果を確認したりもしたのですが・・・うーん、procmailの中からformailを呼び出す時、もしくは何かが変わるのだろうか。素のログ出力もイマイチ情報少ないですし。あとログといえば.procmailrc、もしくはprocmailに読み込ませるレシピの権限はわりとシビア、オーナーが違っていたり、o+wの状態 (諸事情で書き込み与えてました；) だと動かないしエラーも出さなかったりするので注意。
Linode 最安20GBプランにてゆるゆる生活している私ではありますが、欲を言うとちょっと気兼ね無しに保存をできるストレージもちょっと欲しいところではあります。自前魚拓なり、某巨大掲示板のログを置くなり色々するとあっという間な気もしますので… とりあえずDropboxとDropbox公式Pythonスクリプトで適当な共有はしていますが、これはフォルダ同期だし、無料2GBというのもこの大容量時代どこか心許ない。(実際のところ、50MB くらいしか使っていませんが；)
という大は小を兼ねる理論に基づき、Xen準仮想環境にFuseを入れて後のストレージ拡張を試みる。DavFS辺りでSkydriveの25GB とかを確保できたら最高だろう。で、早速インストールを行おうとするが怒られる。fuse自体カーネル組み込み、もしくはモジュールで運用を行うべきものなので当然。
# emerge sys-fs/fuse (略) Determining the location of the kernel source code Unable to find kernel sources at /usr/src/linux Please make sure that /usr/src/linux points at your running kernel, (or the kernel you wish to build against). Alternatively, set the KERNEL_DIR environment variable to the kernel sources location Unable to calculate Linux Kernel version for build, attempting to use running version Checking for suitable kernel configuration options... >>> Unpacking source... (略) >>> Completed installing fuse-2.8.5 into /var/tmp/portage/sys-fs/fuse-2.8.5/image/ (しかし、何故か成功する。)
さて、Linode環境だと準仮想用のカーネルで動かす(GBPVR に組み込む・・・だったか)のでシステムからカーネル自体が見えないし、fuse用のモジュールも当然組み込まれていない。(運用セキュリティ的な問題だったか・・・今は大丈夫なのかな) 自前で同じバージョンのカーネル(sys-kernel/vanilla-sources)を持ってきてモジュールだけ展開をしてはみたが、modprobeにて現行動いているものとは異なるラベルのモジュールを組み込むのはよく分からんのだ・・
のでテキトウにfuseを再コンパイルしてみる# emerge sys-kernel/vanilla-sources/vanilla-sources-x.x.x.x.ebuild # emerge sys-fs/fuse (略) Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: x.x.x.x Checking for suitable kernel configuration options... >>> Unpacking source... (略) >>> Completed installing fuse-2.8.5 into /var/tmp/portage/sys-fs/fuse-2.8.5/image/
おっおっおっ(^ω^) しかし最近はfuseでZFSまでマウントできるの…カーネルではサポートしていないのに。凄いですねぇ。
・・・だが動かない 何かよい方法はないものか
リレー先指定のtransportの挙動について
Sendmail:# /etc/mail/transport .uso8000k.net smtp:[192.168.1.1]
# /etc/mail/local-host-names test.uso8000k.netPostfix:
# /etc/postfix/transport test.uso8000k.net local: .uso8000k.net smtp:[192.168.1.1] ※要postmap
# /etc/postfix/main.cf mydestination = test.uso8000k.net transport_maps = hash:/etc/postfix/transport両方とも要はtest.uso8000k.netのメールはローカル配送にして*.uso8000k.net宛のメールについては192.168.1.1にリレーしたいという設定。しかしこのTransportの構文が似たMTA同士実は決定的に動作に違いがある。sendmailはローカル用に用意したlocal-host-namesホスト名を見てからtransport配送を振り分ける。postfixはローカル配送優先のmydestinationを用意してもtransport_mapがあるとそちらが優先される。つまりは上に書いたtest.uso8000k.netも*.uso8000k.netに引っかかりリレー配送されてしまう。
Samba 3.x系列で一番簡単な共有を作るだけで問題が発生し苦痛を味わう
・(例) /var/tmp (1777) root:root にpublic共通を作ると失敗
・(例) /var/tmp (0777) nobody:nobody にpublic共有を作ると失敗
・/tmp (1777) にpublic共通を作ると成功
なんぞ・・・原因も分からず2時間悩み未だ解決せず・・・
Redhat Enterprise Linuxについて。あそこまでバイナリパッケージで雁字搦めにして、挙句期間のサブスクリプション代を取るのなら、Windowsでもいいんじゃないですかね・・・と内心思ったり。サブスクリプションでお金を取る事は仕事なのだし問題ないのだけれど、最近ひょんな事から触れてみた感じFedoraやCentOSの無償提供のものとどう違うのかサッパリ分からない。標準だと専用の管理ツールみたいなものも無いときたもので、本当に何が違うのだろうと思いました。Redhatからの保証があるとは言うが、結局どの程度までなのだろうか。ドライバの問題にしてもOSの問題にしても結局は元のカーネルは変わらないし自分で何かするのと大して変わらない。また、問題があったら自分で見るし、殆ど連絡取る前に解決してしまう。逆にこちらで解決の試みをせずに突然ハードウェアの相性込みでサポートしてくれと言われても困るだろう、困られては困るのだが。このような体裁の商用のUnix系の利点やお金を払うだけの対価というものがわからないのが正直なところ。Microsoftの売り方と比べてどこか歪に感じるオープンソースビジネスでした。
IPv6が有効な(標準で有効) Windows Vistaを直接インターネットに繋ぐとISATAP 、6to4 アダプターが勝手に出来てしまう模様。ちなみに私が見た環境ではWindows 7でも発生し、ざっと500個程6to4のアダプタが作成されていました。ちなみにこれは気が付かないと本当 (と書いてマジと読む) に通信周り支障がでます（異常な負荷、WindowsドメインやNAS等NetBIOS使用のサービス）、場合によってはOSが立ち上がらなくなったりもする模様。(Vistaの起動画面のままで起動しません。)
ちなみに問題が起って一番最初はTunnel adapter ローカル エリア接続* 削除方法 を参照しつつ対処を行いましたが、ただでさえVista系OSで遅めの環境にて500ものインターフェイスを消すのは手間が多く心が折れ候。
ということで、何とか自動で全て消せないかと調べていたら本家に症状の説明と対処が詳しく載っていました。公式ツールの"devcon.exe"なるものを使えば、コマンドラインでデバイス情報の操作を行えるとかとか。DevConユーティリティをダウンロード > devcon.exe remove *ISATAP > devcon.exe remove *6to4mp
はい、がっつり消えました。そして処理も軽くなりました。やはり本家の情報は凄い。検索性最悪ですが。あとは修正パッチを当てるか、サービスの[IP Helper] (ipv6用tap/Proxy/Tunnel的な[MSのTCPホールパンチだったか]) を止め、インターフェイスのIPv6を使用しないようにすれば以降増えないとかとか。しかし、このような問題を7も抱えている+パッチがEmail登録型でダウンロードとは・・・(WindowsUpdateには無い？) なんとも。
# Default Chain ip6tables -P INPUT DROP ip6tables -P OUTPUT ACCEPT ip6tables -P FORWARD DROP (略) #----------------------------------------------------------# # Service Filter # #----------------------------------------------------------# ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT ip6tables -A INPUT -p tcp --dport 443 -j ACCEPTサービスを最低限に絞って提供。なお、文法もそのままだし、アドレスの書き方さえ間違えなければiptables/ip6tablesも大して変わらない。ただ、何だかんだでプロトコル変わった故かIP層のフラグメントの状態チェックができなかったり、ICMPのステータスが微妙に変わったりしたのか、微妙にオプションが異なる部分もあったので、注意。やっぱりあとはコアにやってくのはipv6をちゃんと知らなきゃ・・・ですね。とりあえず、v4から毛の生えた程度の運用はできそうだ。
he_tun0 Link encap:IPv6-in-IPv4
inet6 addr: fe80::ade6:93b4/128 Scope:Link
inet6 addr: 2001:470:1f04:1a92::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 MiB) TX bytes:0 (0.0 KiB)
こちらLinodeサポートのIPv6
eth0 Link encap:Ethernet HWaddr f2:3c:91:96:3c:fd
inet addr:173.230.147.180 Bcast:173.230.147.255 Mask:255.255.255.0
inet6 addr: 2600:3c01::f03c:91ff:fe96:3cfd/64 Scope:Global
inet6 addr: fe80::f03c:91ff:fe96:3cfd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 MiB) TX bytes:0 (0 MiB)
Interrupt:0
以下の手順にて有効化。$ w3m -6 [2600:3c01::f03c:91ff:fe96:3cfd] ※ v6アドレスは大括弧で括るとよい Output: It works!ぉー お手軽すぎる。
IPv6 Tunnel Endpoints Server IPv4 Address:72.52.104.74 Server IPv6 Address:2001:470:1f04:1a92::1/64 Client IPv4 Address:173.230.147.180 Client IPv6 Address:2001:470:1f04:1a92::2/64こちらの情報を元にGentooの設定を行う。
emerge --sync USE=ipv6 emerge net-misc/iputils USE=ipv6 emerge sys-apps/iproute2※ping6無いなーと思ったら/etc/make.confにて全面的にipv6切っていた経緯アリ
# cat >> /etc/conf.d/net
modules_he_tun0=("iptunnel")
depend_he_tun0() {
need net.eth0
}
iptunnel_he_tun0="mode sit remote 72.52.104.74 local 173.230.147.180 ttl 255"
config_he_tun0=("2001:470:1f04:1a92::2/64")
routes_he_tun0=("::/0 dev he_tun0")
Linodeドキュメント内"local-IPv4address"は何かと思ったらLinodeに与えられたグローバルのIPv4。IPsecのRemote,Local的な使われ方のlocalっぽい。# cd /etc/init.d/ # ln -s net.lo net.he_tun0 # ./net.he_tun0 start * Bringing up interface he_tun0 * Creating tunnel he_tun0 ... [ ok ] * 2001:470:1f04:1a92::2/64 ... [ ok ] * Adding routes * ::/0 dev he_tun0 ... [ ok ] # rc-update add net.he_tun0 default4. 味わう
# ping6 www.kame.net PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=56 time=122 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=2 ttl=56 time=122 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=3 ttl=56 time=122 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=4 ttl=56 time=129 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=5 ttl=56 time=122 ms ^C --- www.kame.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 122.212/123.787/129.246/2.759 msムヒョー
304 : login:Penguin : : 2011/05/09(月) 13:34:14.64 ID:K4sUKiFG 予告通りにbaselayout-2/OpenRCがstableに来てるぜい 噂によるとetc-updateではマイグレーション時にハマる可能性があって、 dispatch-confを使ったほうが良いらしいよ
$ traceroute www.uso8000k.net traceroute to www.uso8000k.net (173.230.147.180), 64 hops max, 40 byte packets 1 GATE (x.x.x.x) 0.810 ms 0.676 ms 0.800 ms 2 OCN1 (a1.b1.c1.d1) 10.715 ms 4.490 ms 5.139 ms 3 OCN2 (a2.b2.c2.d2) 5.701 ms 6.396 ms 5.851 ms 4 OCN3 (a3.b3.c3.d3) 16.401 ms 16.203 ms 16.007 ms 5 OCN4 (a4.b4.c4.d4) 14.976 ms 14.748 ms 14.630 ms 6 * * * 7 * * * AbortHOP5にて既に止まってしまう状態。おそらくは国内すら出る事はできていなかったと思う。しかし障害当時、海外には普通に接続ができていました。(例:試験としてなぜかyoutube.comが思いつく、特に他意なし)
$ traceroute www.youtube.com traceroute: Warning: www.youtube.com has multiple addresses; using 74.125.235.140 traceroute to youtube-ui.l.google.com (74.125.235.140), 64 hops max, 40 byte packets 1 GATE (x.x.x.x) 0.891 ms 0.791 ms 0.773 ms 2 OCN1 (a1.b1.c1.d1) 4.724 ms 4.491 ms 4.451 ms 3 OCN2 (a2.b2.c2.d2) 5.027 ms 5.124 ms 4.969 ms 4 OCN3 (a3.b3.c3.d3) 17.311 ms 16.075 ms 16.548 ms 5 OCN4 (a4.b4.c4.d4) 14.667 ms 14.561 ms 14.411 ms ＝＝＝www.uso8000k.netアクセス停止した場所より先↓＝＝＝ 6 OCN5 (a6.b6.c6.d6) 21.120 ms 20.873 ms 21.110 ms 7 OCN6 (a7.b7.c7.d7) 20.937 ms 21.470 ms 22.573 ms 8 60.37.27.87 (60.37.27.87) 21.361 ms 21.386 ms 21.892 ms 9 118.23.146.238 (118.23.146.238) 40.293 ms 21.636 ms 21.159 ms 10 61.126.89.38 (61.126.89.38) 22.969 ms 23.018 ms 23.069 ms ＝＝＝10までOCN網、 11からGoogle/Youtube網↓＝＝＝＝＝＝ 11 209.85.241.94 (209.85.241.94) 23.052 ms 23.072 ms 23.044 ms 12 209.85.241.129 (209.85.241.129) 23.493 ms 23.458 ms 23.462 ms 13 74.125.235.140 (74.125.235.140) 24.444 ms 22.555 ms 22.489 ms Finishさて、海外はアクセスは出来るみたいだけど、フレモント州近辺の他のホストはどうなのだろう。しかしよく分からない※。が、障害同時にLinode内VM用コンソール接続の為の console-fremont.linode.com へも接続が出来なかった為、おそらくはフレモントにおいてあるDCと同じもしくは近辺にあるであろうとしてTracerouteを実施。
$ traceroute console-fremont.linode.com traceroute to console-fremont.linode.com (66.220.1.244), 64 hops max, 40 byte packets 1 GATE (x.x.x.x) 1.068 ms 0.991 ms 1.047 ms 2 OCN1 (a1.b1.c1.d1) 4.909 ms 4.776 ms 4.421 ms 3 OCN2 (a2.b2.c2.d2) 5.538 ms 5.153 ms 6.712 ms 4 OCN3 (a3.b3.c3.d3) 17.323 ms 15.830 ms 16.496 ms 5 OCN4 (a4.b4.c4.d4) 14.969 ms 14.765 ms 14.764 ms ＝＝＝www.uso8000k.netアクセス停止した場所より先↓＝＝＝ 6 OCN5 (a5.b5.c5.d5) 20.841 ms 20.998 ms 22.077 ms 7 OCN6 (a6.b6.c6.d6) 21.794 ms 22.732 ms 20.775 ms ＝＝＝現在の海外への共通ルート↑＝＝＝＝＝＝＝＝＝＝＝＝ 8 118.23.168.90 (118.23.168.90) 68.817 ms 21.279 ms 22.150 ms ＝＝＝以下アメリコ国 NTT機器 ↓＝＝＝＝＝＝＝＝＝＝＝＝ 9 ae-11.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.12.197) 30.274 ms 30.114 ms 29.883 ms 10 as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189) 152.276 ms 152.270 ms 133.053 ms ＝＝＝以下アメリコ国↓なぜか安定しない＝＝＝＝＝＝＝＝＝ 11 * * * 12 verio-1.ar5.SEA1.gblx.net (64.208.110.222) 172.453 ms 209.202 ms 201.232 ms 13 * * * 14 * * * 15 * * * Abortといった状態。Twitter等にてとりあえず状況を見回したところ、上流の(he.net)の大規模障害にて下がっているサービスが使用不能だったとか。 今回、何が腑に落ちなかったかというと、国内にてwww.uso8000k.net宛の通信が止まってしまった事。一時的に何か誤った経路情報、もしくは存在しない事になったのだろうか。こういうこともあるんだね。注意しないと。 ----