タイトル : 印刷データ誤出力対処法
種別 : 教職員関連のお知らせ/専任教員へのお知らせ/全専任教員へのお知らせ/
内容 : 自室(研究室)に設置のプリンターに、他研究室で出力した印刷データが出力される不具合が多発しております。
不具合を解消するための手順を添付の資料に記載しましたので、設定をお試しください。
だから、各研究室には家庭用の安いルーターを導入させろ といっているのに。
ネットの逆刺しのトラブルが多いから、ルータを勧めないのだそうな。
研究室の規模が小さいから、安いルータでもセッション数の上限にとどかないだろ。
ま、どっちのトラブルを重視するかで決まるんだろうけどね。ルータ使用方法を教育すればいいのさ。よそのプリンタに印刷されちゃう可能性があるのは、学生の成績とか機密情報もあるんだから、まずいだろうな。
大学教務から手に入れる学生名簿を、こちらの都合で改変する必要がある。毎年、この時期になると、履修者一覧から都合に合う履修学生一覧を作ることになる。
学籍番号、氏名、読み が別々のセルにあるのだかこれを改行して１つのセルに連結したいのだ。顔写真を貼りこむセルの隣のセルなのだ。毎年やるのだが、そのたびに検索しているのだ。じじい だから憶えていられない、というか検索の方法だけ憶えているのだ。だからここに忘備録として書くわけね。しかし、来年の今頃はここに記載したことすら憶えていないのだ。
なんか自分のブロク内を検索するというのも、ちと情けない。
さて、やり方は；
のF2 のセルのようにA2とC2とD２ のセルの文字列をそれぞれ改行して合体したいのね。
問題はMac とWin で改行のキャラクタが CHAR(13) あるいは CHAR(10)と違うのね。
Macintosh では F2 のセルを =A2&CHAR(13)&C2&CHAR(13)&D2
Windows では F3 のセルを =A3&CHAR(10)&C3&CHAR(10)&D3
とすることになる。
だからMac で上の図のように作成するとWinでは
と改行されずWin で改行して合体したF3 のセルはMac で表示すると
と改行されていない。
なんかな、統一してほしいもんだけど。
あ、連結（合体）したセルの書式を「折り返し」表示にすることね。
当然だが、Mac （Win）で改行連結した場合、セルを数値としてコピペすれば Win（Mac）ユーザに渡すことができる。
管理ツール（Webページ）から削除する場合
http://example.com/mailman/rmlist/[mailing list 名]/
とすれば、リストのパスワードを聞いてきて、保存庫も含めて削除できるが、デフォルトでは
リスト管理者としてそれはマズいんじゃない?!
と言われできない。
mike の場合 /usr/local/mailman/Mailman に mm_cfg.py があるから、最後に
OWNERS_CAN_DELETE_THEIR_OWN_LISTS = yes
の１行を書き加えると、管理画面にメーリングリスト削除項目が出現すして
クリックすれば
となって削除できるようになる。
コマンドラインから実施するには
/usr/local/mailman/bin に rmlist があるから
$ ./bin/rmlist -a [mailing list 名]
とすればいい。 -a を漬けることで保存庫も消去される。
WordPress 4.1.1 が利用可能です ! 更新してください。
というわけだが、２台のサーバで何故か更新できない。同じサーバの英語バージョンのWordpressは更新できた。
これまで問題なくできていたわけで、今度の日本語のバージョンだけが自動的にできないのだ。どうしたもんかな。
手動はめんどうだし….
Mac OSX Server はいろいろな設定ファイルがオリジナルから変更されて別のdirectoryにあるんだよね。本来の設定ファイルはそのまま残っているからまた分かりにくいいのさ。
Postfix のmain.cf は、普通は /etc/postfix にあるんだけど、そして現にあるのだけど、これは使われないのだ。
Mountain Lion 10.8.5 の場合 /Library/Server/Mail/Config/postfix にあるmain.cf がアクティブな設定ファイルだ。
GUIで設定した結果は、このmain.cf の最後の方に書かれている。
メールリレーサーバーをFQDNで指定するときは
relayhost = [mail.example.com] と[ ] で囲んでFQDNを記入する。maruko2の情報だ。
ip address で指定するときもつけるのかな？。つけてないけどMXレコードを参照に行ってない。
GUIでの設定だが、Server → メール → ISPを経由して送信メールをリレー → 編集 → 送信メールのリレー の欄で FQDN を [ ] 付きで入力しようとすると、[ ] が入力できない。だからmain.cf の方で書き換えないといけない。面倒だから、そしてリレーを依頼しているサーバのip address は変わらないと思うので（規模が大きくなってきたのでip address を変更すると丸１日くらい使えなくなっちゃう）このままip address で設定しておいてかまわない。
しかしFQDNを使うべきなので main.cf で relayhost = [mail.example.com] と書き換えた。
GUIでの設定画面に[mail.example.com]と [ ] 付きで表示されている。
cf.
Google を使うときは relayhost = [smtp.gmail.com]:587 らしい。ポートを指定するときはコロンをつけて指定だ。
メーリスの遅延で書いたようにメールの遅延がなぜか発生したわけだ。その理由を調べるためあちこちに聞いた結果、どうやら本来の中継サーバではないサーバが中継していたのが理由だ。
メールサーバで中継サーバをFQDN（Fully Qualified Domain Name）で指定していたのだが、なぜかこの中継サーバがバージョンアップを繰り返しているうちにメールをリレーしてくれなくなってしまったのだ。その代わりなぜかDNSのMXレコードを引きにいき、その結果に従って別のサーバに転送してしまったようだ。これを防ぐために中継サーバをip addressで指定することにしたら解決した。この別のサーバは中継を本来の業務としているわけではないのだ。だから本来の仕事をしていたので遅延してしまったようだ。本来の仕事とは受信メールのゲートウエイのようだ。なぜ遅延したのかはわからない。エラーが頻発していたらしい。ともかくメールを中継してくれていたので、いつから中継するようになったのかはもはやわからない。メールが届いているから問題にしなかったわけで。
サーバを更新するとこういうことが発生するんだよね。一部書き換えた設定がもはや使えなくなったりするのさ。
先週からメーリングリストで配信するメールが２０時間とか遅延している。メーリングリストサーバは、投稿メールを受け取り、それなりの時間（数秒）を要しているものの、きちんと配信している。だだし、このサーバが直接インターネットで相手先のサーバに送信しているわけではなく、大学のウイルスフィルターでもある中継サーバを介しているのだ。この中継サーバがメールを受け取ってから１５時間とか後に学外のサーバが受け取っている。
どうやら、「メールゲートウェイ（受信用、以下のアドレス）が、大量のスパムを学外に発信してしまったため、spamcom のブラックリストに掲載、senderbase のスコアが poor に変更されしまった」らしい。
１）学部内サーバから学外のメアドその１へ１５時間
Received: from xxxxx[123.123.123.123]) by yyyy.tsukuba.ac.jp with ESMTP; 07 Feb 2015 09:52:32 +0900
Received: from yyyy.tsukuba.ac.jp by zzzz.ne.jp with ESMTP; 08 Feb 2015 01:24:41 +0900
２）学部内サーバから学外のメアドその２へ ２秒
Received: from xxxxx[123.123.123.123]) by yyyy.tsukuba.ac.jp with ESMTP; 07 Feb 2015 09:52:31 +0900
Received: from yyyy.tsukuba.ac.jp by aaa.ne.jp ; Sat, 7 Feb 2015 09:52:33 +0900 (JST)
３）学部内サーバから 学部内別サーバのメアドへ １秒
Received: from xxxxx[123.123.123.123]) by yyyy.tsukuba.ac.jp with ESMTP; 07 Feb 2015 09:52:31 +0900
Received: from yyyy.tsukuba.ac.jp by bbb.dddd.ac.jp ; Sat, 7 Feb 2015 09:52:31 +0900 (JST)
というわけで、学外のサーバによって異なる。このブラックリストに掲載されちゃったという時期と一致するから関係があるにちがいない。全く届かないというわけではないのが悩ましい。
問い合わせ中だ。
ネットの管理者に聞いたら、使っているハブはループを検知して自動的にブロックするそうだ。ほんとかなな？ちと怪しいと思っているけど。
Facebook は登録すると勝手に探したメールアドレスなどに友達になろうよという招待メールが送付される。
大学の教員やっているから、そして、学生は管理者のメールアドレスを登録しているから、大学のメールアドレスに招待メールがよく来る。どうして、こいつ（学生だ）から招待メールが来るのかは理解できるから問題ない。捨てちゃうだけだからだ。
しかし、プライベートのアカウント（これもいくつもあるんだけど、その一つ）に
が来た。なんてこった。千葉県の高校女子学生だぜ。なぜ彼女のアドレス帳に管理者のメアドがあるんだ？どんなつながりがあるんだろ？管理者にはFacebookの友達が一人もいないからFacebookが哀れに思って勝手に送りつけたんだろうか？
さいたま市のあたりは朝から雪。昨年だったか、雪の日に筑波から岩槻に行くのに通常だったら、１時間半とか、日中だと２時間なんだけど、９時間もかかったというトラウマがあるから、さっさと筑波にもどろうと思っていたわけだ。どうやら午後には雪は止むと天気予報で言っていたが、未来はわからない。
午前中はメールとか再試験の問題作成などの仕事をして、昼食をとって、さらにネットで調べものやメールの出し入れをやっていたら、突如ネット接続がおかしくなった。ハブを見ると上流側のLEDの点滅が激しい。つまりパケットが飛び回っているのだ。あっちの大学にはヘビーユーザーがいないからいつもはこんな高頻度の点滅はない。だれかがループを作った？
調べようにも、こっちの大学とは違い、物理的な配線もハブがどこにあるのかも知らないから、ほかのユーザの状況を聞くしかない。しかしセグメントわけがどうなっているかもわからないから、どこがポイントかわらない。
ネット管理を行っている職員のところに行ったが不在だ。ネットもつながらない、外は雪だ。んじゃ、しょうがね、帰るベェと筑波へ戻る支度をして、うろうろしていたら、ネット管理の職員に出会った。状況を説明していたら、それはその管理職員が操作をしていたからだという。なにやら固定ip addressを割り振った機械がうまく動作しないのだが、ip addressのバッティングがあるらしいので調べていて解決したとのことだ。
へ？なにをどうやって調査したのかしらないが、パケットが飛び回るような調査かよ。
そんで、今回のトラブルについて大元のネットのマネージャに報告したら、なんと管理者（このブログ主）が勝手に固定ip address を設定したからだといってきた。なにいってんだよ。そんなこと管理者がやるわけがないだろうが。くそ。
[ 追記 ]２月３日
どうやら勝手に固定ip address をルータに割り振った奴がいるのかもしれないということになりつつある。ネットに接続できないとクレームを言ったのが管理者だけだったので、管理者を疑ったということらしい。他の利用者は鈍感なのさ。
しかし、この問題のip address にping を飛ばすと20 ms もかかったりする。同じセグメントのまともなPCだと1 ms とかだぞ。なんかおかしい。というわけで今日の午前中ping に応答するので探しだそうと、ネットの管理者と一緒に探しだそうとしたのだが…なんせこの管理者の手元に配線図がない。ハブのところに行ってケーブルのタグをみてもどの部屋なのかわからない。ケーブルのタグと部屋番号の対応表がない。この管理者もこういうトラブルに対応したことがないので、スムーズでない。ということで、こっちも別の業務があったから付き合いきれずに、午後になって再度調べたらping に応答しなくなった。切り離したが電源を落としたのだ。これ以上追跡できない。でおわりだ。
[ さらに追記 ]２月４日
これまでの例では、「ネットにつながらないというクレームを付けた人が原因で接続できない」 だから 「今回もクレームを付けた管理者が何か悪いことしたんだろ」 という結論をだしたんだそうな。
ひでー としか言えないな。