先日、会社でハラスメント研修があったりして。
セクハラ、パワハラまではなんとか我慢して聞いてたけど、
パタハラ、カラハラあたりから、なんだ、その略語ってってなって、
完全にリャクハラ(略語ハラスメント)。
ちなみにパタハラは「パタにティ・ハラスメント」(育児する男性に対する
いやがらせ）と「カラオケ・ハラスメント」(カラオケが苦手な人を
無理やりカラオケにつれていくとか執拗に誘うとか)だそうだ。
略さなくてもわからないよう。
まずは略すのをやめよう。
タイマーズの「サマータイム・ブルース」で三浦友和さんも叫んでおられる。
なんでも省略するのはニッポンの悪いクセだ。
そして、最近では50歳オーバーの「おっさん」へのバッシング記事も
たくさんあるなか、オレは「ハラハラ」を主張しようと思う。
「ハラスメント・ハラスメント」だ。
なんでもかんでもすぐに「ハラスメントだ！」といっておっさんを
糾弾するような事のことだ。
おっさんが嫌だなあ、と思ったら十分ハラスメントだ。
みんな、ハラハラに気をつけよう。
そのうちハラハラハラって言われるようになるのかしら。
1980年代でも、CPUをシェアして使うという考え方は一般的だった。
汎用機もUNIXも一台も「ホスト」にダム端末と言われていたグリーン
一色のディスプレイをもつ端末がたくさん繋がれており、操作する人は
時々まわってくるCPUの順番で処理を許された。
こんなやつ。
CPUは文字の入力、プログラムの実行、コンパイルなど様々な処理に
対して「時々まわってくるもの」だった。ヒナがたくさんいる親鳥が
一斉に口を開けてピーピー言ってるヒナに順番に餌を与えるように。
オレの最初の端末もSun4-330にRS232cで接続されたtty端末だった。
いまでは/dev/tty0とかは、マルチウインドウの1枚のウインドウに割当
られているが、当時はダム端末の一台に割り当てられていた。
config.sysやautoexec.betを書いていた世代だったので、.cshrcや.loginを
書くことには抵抗がなかった。
当然、.cshrcも.loginもviで編集せざるを得なかったわけである。
だから、カーソルを移動するだけでCPUを使うのは、時間の無駄だった。
スクリーンは10行ほどスクロールすると動きを止め、数秒後にまたスクロール
した(感覚には個人差があります)。
viはそんな時代に開発されているので、いかにすくないキータッチで目的の
編集ができるかを主眼に開発されていると行っても過言ではなかった。
「カーソルを行末へ移動する」「カーソルを最終行へ移動する」などは
「$」と「G」に割当られているし、10行ヤンク(コピー)してペーストも
「10yy」と「p」で実現される。文字列の検索も置換も秀逸だ。
ながながと書いたのは、若い人も是非viを修得して欲しいということ。
サーバー管理でよくあることは、とあるプロセスがメモリを食いつぶして
今にも息絶えそうなサーバーにログインさえできれば、問題のプロセスの
設定ファイルを書き直して、プロセスの再起動をする、というようなことが
できる。設定ファイルをftpで落としてきてローカルのメモ帳で直して再度
アップロードするなんてするなら、ftpdも動いてないといけないし、ポート
も開いてないかもしれない。
以前から採用の面接の時、「エディターはviです」という子は贔屓するように
しているのはナイショだ。
しばらく前に個人で管理しているメールサーバーで発生してたんだけど、今日は会社のメールサーバーでも発生してたので、blogにまとめておく。
Apple社のサービスで使ってるドメイン(me.comとかicloud.com)へのメールが届いてないんだけど、と相談されたら大抵これ、という解決策。
Apple社が自社サービスのメールサーバーの受信フィルタで使っている「proofpoint」というサービスがあって、こいつがある日、急に送信元のIPアドレスに従ってメールをブロックする。その基準はわからない。
ブロックされたらそのIPアドレスのサーバーを使っているドメインからme.comとかicloud.com宛のメールが届かなくなる。
/var/mail/maillog に対応策がログとして残っているので、それを実施。
logの内容はこんな；
Apr 11 06:14:46 smtp_server_name postfix/smtp[ID]: B7E93A****: to=<hogehoge@icloud.com>, relay=mx3.mail.icloud.com[17.172.34.64]:25, delay=2, delays=0.12/0.01/1.3/0.55, dsn=5.7.0, status=bounced (host mx3.mail.icloud.com[17.172.34.64] said: 550 5.7.0 Blocked – see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=IP_ADDRESS (in reply to MAIL FROM command))
(smtp_server_name＝自分のSMTPサーバーの名前、 IP_ADDRESS＝自分のSMTPサーバーのグローバルIPアドレス)
要は「ブロックしたからなんとかしたけりゃここのサイトにおいで」と。
ログにある https://support.proofpoint.com/dnsbl-lookup.cgi?ip= へ行って自分のSMTPサーバーのグローバルIPアドレスを入力し、「ロボットではありません」にチェックを入れて「LOOKUP IP」ボタンを押す。
ブロックされてない場合はこんなだが、
ブロックされてた場合はこんな。
なので、名前とアドレスと(あれば)会社名を入力し、「ブロック解除お願いします」と日本語でもいいので、入力の上、「SUBMIT」ボタンを押す。審査中はこんな画面だけど、1時間前後でブロックが解除され、最初のブロックされてない画面になる。
一度解除されても、またブロックされているケースもあるので、注意が必要。
いくつかのドメインのメールサーバーをAWS上で運用している。
どのドメインもSPFのみならず、DKIMやDMARCにも対応させて
一応なんとか運用している。
しかし、4月の中旬くらいからどうやらdocomo.ne.jpのメールサーバーの
仕様が変わったらしく、Mailmanを使ったMLの配信でbounceが発生する
ようになった。
/var/log/mailman/bouce の例としてはこんな。
date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: bbb@docomo.ne.jp current bounce score: 2.0
date (ID) ml_name: ccc@docomo.ne.jp current bounce score: 2.0
date (ID) processing 3 queued bounces
date (ID) ml_name: aaa@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name: bbb@docomo.ne.jp already scored a bounce for date 23-May-2018
date (ID) ml_name : ccc@docomo.ne.jp already scored a bounce for date 23-May-2018
これ、全部のメールがbounceしているわけではなくて、
i.softbank.jpから発信されて、当該ドメインのメールサーバーで
ML宛に配信されたメールがbounceするのだった。
正確にはaaa,bbb,cccの3人への配信がbnounceしていると書いてあるが、
実は、bbbとcccには実は届いていて、aaaにだけ届いていない。
同じタイミングの/var/log/maillogはこんな。
date server_name postfix/smtp[PID]: ID: to=<ccc@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<bbb@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
date server_name postfix/smtp[PID]: ID: to=<aaa@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.112]:25, delay=0.24, delays=0.09/0.01/0.03/0.11, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.112] said: 550 Unknown user aaa@docomo.ne.jp (in reply to end of DATA command))
maillogではaaaで拒否しているからbbbにもcccにも届いてないよ、って
ログだから、bounceファイルでもbounce処理していることが載っている
のだが、前述の通り実際にはbbbとcccには配信されている。
よって、bbbとcccをaaaの影響から外すために、全てのメールを
個別配信する設定に変更した。Mailmanはデフォルトでは同一
ドメインには、一度のセッションで複数のアドレスへ送っている
ようで、それが今回の問題の原因のようだった。
/etc/mailman/mm_cfg.py の最終行に以下の記述を追記。
VERP_PROBES = Yes
VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
これで管理コンソールの「普通配送」のところに個別配信の
メニューが追加され「いいえ・はい・完全個人別配信」が選択できる。
完全個人別配信とすると、本文に名前を入れるなどのカスタマイズが
できるが、今回はそこまでしないので、「はい」を選択。
結果として、maillog上でもmailman/bounce上でも配信エラーは
aaaだけとなった。
aaaに配信されていないという根本原因は不明なままだが、とりあえず
他のメンバーがバウンス回数が多くて配信停止になるというリスクは
回避できたはずだ。
参考ページ：Mailman日本語情報「サイト管理の手引」
「ＮｏＱＺ」＝No！Ｑ(旧車)Ｚ(増税)「ノーキューズィー」と発音。
2018年4月30日(月・祝)全国分散イベントを企画した。
初度登録から13年18年経った車の自動車税・重量税の割増に反対するイベント。
以前から地味にアピールしてたし、この税制が始まった時から
このblog上で反対する記事は書いてたし、元町プールのネタに続いて
もっともよく読まれている記事の一つであることは確か。
ただ、どうしてもネット上の一部のマニアが騒いでいるだけ、という状態を
脱せなかいと思っていただ、Facebookのこのコミュニティのメンバー数が
2000人を超えたことをきっかけにこの企画を進めることにした。
2018年のお正月に1000人を超え、その後の増え方は加速度的だったこともある。
声高に反対を叫ぶのではなく、この不条理な税制の認知度を向上させるために
一箇所にたくさん集めるのはなく、全国で分散して開催できればと。
「俺たちはただ、旧いクルマが大好きなだけなんだよー」