More from: server

今回は２千通弱だった

P , by

c No comment

時々頼まれてサーバ上に残してあるメールを削除しているが、今日は約２ヶ月振りにやることになった。
いつもは先方から依頼されて実行するのだが、今回はこちらから削除が必要かどうかを尋ねたところ、
「是非やって欲しい！」
と言われた。
それだけならいつものように
fetchmail -Fv
で取得済みのメールを削除するのだけれど、今回は
「古いのだけを消して貰えないか？」
と言われてしまった。
ところが-Fvオプションを付けてfetchmailを実行すると、サーバ上にあるメールのほぼ全てを削除してしまうので、それは出来ないと答えた。
まぁそれでも良いとのことだったので早速実行して２千通弱のメールをサーバ上から削除した。
ヘッダー形式がRFCに則っていない数通が取得されずにサーバ上に残ってしまったが、全てSPAMだったのでnPopを使って削除した（先に「ほぼ全て」と書いたのはこのようなメールが残るため）。

後から考えたら.fetchidsファイルを加工してから実行すればサーバ上にメールを残すことが出来るかな？と思ったが、.fetchidsに書かれていないメールは再取得されるだけなので、やはり選択的にメールを削除するのは困難だということに気付いた。

うーん、なんか良い方法は無いかなぁ？

←クリックしてくれると嬉しいです。

サーバを移設したら（汗）

P , by

c No comment

今日はサーバの内の一台を移設する予定をたてていた。
昨日から関係各所には連絡をしておき、さらに作業1時間前にも再度連絡を入れておいた。
と言っても本運用開始前の試験運用中のサーバだったので、連絡する相手もほんの僅か。
設置場所には事前に必要な配線を済ませておき、後は件のサーバーを一旦停止して運び込むだけとなっていた。

予定時刻になったのでサーバを止め、仮の設置場所から本来の設置場所に持ち込み（重かった・・・）、先に配線を済ませておいた電源ケーブルやLANケーブルを接続して電源を投入。
本来はこれだけで作業は終わりの筈だったが、サーバが起動したは良いがネットワークに接続出来ないorz
さんざん調べて判ったことはLANケーブルの挿し間違いで、それに気付くまで30分程度も悩んでしまった（汗）
＃オンボードのLANポートと増設分のLANポートの設定を勘違いしていたのが原因だったといふ・・・・

これでほぼ予定通りにサービスを再開できることになったので、関係各所に連絡を入れて利用を再開して貰った（中には連絡する前に再開したユーザーもいたけど）。

←クリックしてくれると嬉しいです。

アクセス権の問題だった

P , by

c No comment

一個前の記事で書いたRidoc Document Router配信管理ツールで宛先の新規登録が出来なかったのは、ツールのバージョンの問題では無かった。
現場に行かせた部下が思ったより早く帰ってきたので報告を聞くと、サーバーへのログイン時に入力するユーザー名とパスワードが管理者権限のものではなかったのが原因と言うことだった。
管理者権限のあるユーザー（ビルトインユーザー）でログインしたら問題無く宛先新規登録が出来たとのこと。
あー、たいした問題でなくて良かったー、、、、、、、

←クリックしてくれると嬉しいです。

Ridoc Document Routerでサーバーにフォルダの追加が出来ない

P , by

c No comment

WindowsXpのPCにRicoh Ridoc Document Router V4の配信管理ツールをインストールしたが、サーバには接続できるが「宛先新規登録」が出来ない。
左ペインで「全宛先一覧」を右クリックして「宛先新規登録」を選んでもサブメニュー内の項目全て（「ユーザー」、「グループ」等）がグレイアウトしていて選択が出来ない。
数日前まで他のPCから接続して宛先の登録も出来ていたので、サーバー側の問題では無いと思う。
今のところ原因は不明だが、とりあえず配信管理ツールを最新版にアップデートすることにした。
＃サーバーのバージョンとちょっとだけバージョンが違うため。
さてどうなることか？

←クリックしてくれると嬉しいです。

ここにもWindows7非対応のソフトが・・・・・・・

P , by

c No comment

職場で新規に購入したPCの設定をしていて、RicohのRidoc Document routerの配信管理ツールをインストールしようとしたらインストーラーのOS判定に引っ掛かってしまいインストールできない（Windows Server 2008対応の最新版でもダメだったが）。
OSはWindows7Proで、職場で使うソフトの一部が64ビット版では動作しない（もしくは動作保証が無い）ので32ビット版としている。
配信管理ツールは必須のソフトではないが、無いと困ることもあるので一部のPCにはインストールしていて、今回セットアップしているPCには入れる予定だった。
なのでRicohに問い合わせてみるとやはりWindows7には非対応ということだった（Windows7発売時には開発が終わっていたソフトなので今後も対応は期待できないとのこと）。
それじゃどうすれば良いのか？と相談したらWindowsVISTA以前のOSのPCにインストールするか、Ridoc Document routerをインストールしたサーバ（当然ながらWindowsサーバー）にリモートデスクトップ接続して使って欲しいとのこと。

そういえば今年の頭に他の現場に導入した際にクライアントが全てWindows7だったので、サーバーにデスクトップ接続で入って配信管理ツールを使った記憶がある。
今後はWindows7（もしくはそれ以降のWindows）のPCが増えていくので、この方法を使うしかないんだろうなぁ、、、、、

＃古いバージョン（Version2）のインストーラは動作したが、これだとVersion4のサーバには接続できないので使えない。

←クリックしてくれると嬉しいです。

fetchmail でのサーバ上のメールの削除

P , by

c No comment

4月にもやったけど、今日もメールサーバ上に溜めてあるメールの削除を頼まれた。
1アカウントを複数のPCで使うために普段の受信時にはサーバ上にメールを残すようにしてあるが、大量に溜ると受信時のレスポンスが悪くなってしまうので、ユーザーが我慢できなくなったら削除を依頼してくる。
なにせ前回実施したのが4月の末なので、詳細な手順を忘れている（爆）。
なので、この時の為にと思って当時このブログに手順を書いておいたので、今回はそれを参考にした。
「-Fもしくは–flushオプションだったのね」

今回は約4800通のメールが上記の手順で削除された。

←クリックしてくれると嬉しいです。

awkのメモ

P , by

c No comment

linuxサーバーのmaillogから下記の項目を抜き出す必要が出来た。
・端末のIPアドレス
・ユーザーアカウント
・端末名（名前解決が出来たもののみ）
しかも特定のネットワークからのアクセス分だけという条件付。

で、まずは/var/log/maillog*から特定のネットワークからの分だけを
#grep “ネットワークアドレス(xxx.yyy.zzz)” maillog* > hoge
でhogeというファイルに吐き出した。
次に
#cat hoge | grep pop | awk ‘NF=14{print $12,$13,$7}’ | sort +1 | uniq > hoge2.txt
を実行して結果をhoge2.txtというファイルに書き出した。

#grep “ネットワークアドレス(xxx.yyy.zzz)” maillog* | grep pop | awk ‘NF=14{print $12,$13,$7}’ | sort +1 | uniq > hoge2.txt
のように全部を一度に書いても同じ結果が得られたはず。

awkの中でやっているのは
フィールド数が14ならば（NF=14）12番目と13番目と7番目の項目を書き出す。
ということ。
これで（ほぼ）望みどおりの結果が得られ、数万行にのぼるログファイルから10行少々を切り出すことが出来た。

←クリックしてくれると嬉しいです。

指定したのとは別のプリンタから印刷される

P , by

c No comment

先日仕事で行った先で、
「印刷なんですけど、たまに違うほうのプリンタから出るときがあるんですよ。」
と言われた。
問題の印刷はサーバー上のプログラムから出しているもので、ユーザーが操作するクライアントPC側では出力先のプリンタの指定をすることは出来ない。
しかもサーバ上での設定で違うプリンタを指定しているなら毎回違うほうのプリンタから出るはずなのだが、毎回ではなく”たまに”だということなので単純な設定ミスでは無い。
不思議なこともあるものだと思っていたら、思わぬところに原因があった。
件の印刷は本社のサーバ上で動作するプログラムが出力し、その際に出力先を現場に置いてある別のサーバに定義してあるプリンタを指定している。
この現場のサーバでのプリンタの定義に問題があった。
現場のサーバは古く、印刷システムがlpdなので、プリンタは/etc/printcapで定義している。
この定義の中にはプリンタのエントリが2台分あるのだが、スプールディレクトリの指定（sd=/var/spool/lpd/hogeの部分）が2台とも同じディレクトリになっていた。
仮に1台目をプリンタA、2台目をプリンタBとした場合、プリンタAに対して印刷要求を出した場合もプリンタBに出した場合も実際の印刷データは同じディレクトリに置かれることになる
このためプリンタAに対して印刷要求を出した際に、たまたまプリンタBに対応するデーモンが動作していると、プリンタAに出力する筈のデータもプリンタBに出力してしまい、データをプリンタBに送り終わるとデータを消去することになる。
しかもプリンタは直付けではなくプリンタサーバ経由での接続の為、データの転送はプリンタに直接送るよりも早く終わる。
このため本来印刷する筈のプリンタAではなく、もう一方のプリンタBで印刷されるということが起きてしまっていた。

いやぁ、最初は目的のプリンタにデータを送れない場合に自動で切り替えているのかと思ったが、そんな設定をした覚えはないし、lpdはそんな頭の良いことはしてくれない（爆）。
判明してみれば初歩的な設定のミスだったが、今後は気をつけないとなぁ。

←クリックしてくれると嬉しいです。
←クリックしてくれると嬉しいです。

ちょっとだけつながった（汗）

P , by

c 1 comment

クライアントからの接続が出来なくて困っているWindowsサーバに一部のクライアントから接続が可能になった。
サーバソフトメーカー（Ricoh）のサイトにあった情報を元に、DCOMの設定を見直して「アクセス許可」と「起動とアクティブ化のアクセス許可」の「制限の編集」で「ANONYMOUS LOGON」を追加してローカルからのアクセスやリモートからの起動等全てにチェックを入れたところ、Windows7のクライアントからは接続できるようになった。
ところが設置する部署のクライアントであるWindowsXpからは接続出来ない。
うーん、一歩進んでは立ち止まってるなぁ（汗）。

旗＋Rでdcomcnfgと入力するとコンポーネントサービスを起動できる（メモ）。

←クリックしてくれると嬉しいです。