2023/04/15(土)複数の電源トランスを扱う場合の注意点がよく判らない・・・
2023/04/15 23:37
パワートランジスタが壊れた回路の概略図を描くとこんな感じ ↓

トランジスタの1つ、或いは2つがコレクタ・エミッタ間で短絡故障を起こしました。
電源トランスが複数あり、一次側の0V端子側、2次側の0V端子側を共に合わせて配線しています。
こうすることで、極性が合うはずと思っているんですが、
結果的に、金属ケース筺体を利用して、ダイオードブリッジの中間を共通接地にした形というアホな回路になっていたため、何かしらの循環電流が流れる感じになっていたのかもしれません。
C05 の端子間電圧が 54V になっていたり(ここは 42.5V 以上にはならないはず・・・・)、トランジスタが壊れなかったとしても、意味不明のスパークを筺体で発生させてヒューズが飛ぶ、とか起きる謎の現象もあったので、それは、この狂った配線が原因なのだろうか・・・?
いずれにしても、色々と直観的によろしくないと思うので、下記のように変更を予定しています。

ただ、これでもパワートランジスタ故障の原因が釈然としません。
破壊するとしたら、VEBOが絶対最大定格5Vを越えたくらいしか考えられない感じで、これが発生する条件というのがどうも判りません。。
2023/04/15(土)整流回路の平滑コンデンサは容量が大きければいいというものではないらしい
2023/04/15 6:09
10年近く前に、PC-9801 のBASIC で組んで公開されていた整流回路シミュレーションがあったので、手元のMZ-2500 BASIC-M25 に移植して使っています。最低限機能させるための移植なので、色々変な部分はあるんですが。。orz
引用元の書籍を紹介しようとして、手持ちの書籍を漁ったのですが、何故か見つからない。
ということで、「原作者の方、申し訳ないです・・・」ということで、、、
いずれにしても、MZ-2500だったから移植出来たのです。他の機器だったら、かなり苦しい。
ここから本題なのですが、当初は、こんなふうにしていました ↓

そして、おもむろにこのシミュレーションを動作させてみると・・・

負荷電流1Aという、意図的に悪い動作条件を与えたんですが、こんな感じになりました。
黄色の線は電流を示しますが、正確ではないし、描画がおかしいので、とりあえず無視。
注目すべきは赤っぽい実線。
このあとに5V出力の3端子レギュレータが繋がるのですが、安定動作には7.5V以上の電圧が必要なので、14ms あたりまでは何かしらの不具合が出る可能性がある。
静電容量が大きすぎて、電圧が上がり切りません。
ということで、平滑コンデンサ C01 を下記のようにしてみました ↓

静電容量だけ変えて、他は同じ条件です。

ここまでは、安定化電源装置を動作させるための補助電源部の話で、
本当の本題は、PT2-D3-C05 で構成する、この平滑回路です ↓

22mF(22,000μF)というオーディオアンプの電源に使うような大容量電解コンデンサを当初使っていました。
安定化電源装置の最高出力電圧は24V、最高出力電流は3Aの設計です。
24Vの安定化出力を出すためには、平滑回路の電圧は27Vは欲しい。
これを安定化電源装置の設計最大電流である3Aでシミュレーションさせると・・・

40ms あたりまで、所要の電圧にはならないことが判りました。
試行錯誤で、落ち着いたのがこれ ↓

シミュレーション結果は以下。

ギリギリ大丈夫か? みたいな感じです。今までは経験と勘だけで適当に決めていたところだったが。。orz
Rs というのは、変圧トランスやコンデンサを結線する配線抵抗等ですが、これを正確に決めるのは難しく、代表的な値として0.5Ωと見做すことが多い模様。
恐らく、殆どのケースでは0.5Ωよりも小さく、このシミュレーションで得られる電圧よりは若干高めになると思います。
シミュレーション上の紫の実線の山と赤っぽい実線の山の間隔が広いと、それだけ電力損失が増え、整流ダイオードあたりが発熱しやすくなるのではないかと思われます。
ですが、このことがパワートランジスタの破損に直結するとは思えないです。
2023/04/06(木)Let's encrypt のサーバ証明書をpostfix で使う場合の注意
2023/04/06 16:15
発端は、「こんなメッセージが出るんだが・・・」という一報。

証明書の更新は正常にできているので、謎の現象です。さらに「証明書の表示(V)...」で表示される内容を送ってもらうと・・・

こんな感じになるらしい。確かにここでは「期限切れ」になっています。
証明書の誤認識であることには間違いないので、クライアント側の設定で何か問題を引き起こしているのではないかと思うのですが、いろいろと不可解なので、一報を頂いた会社へ許可を得て出向いて、原因究明と解消を試みました。
証明書チェーンはあっているが、変にキャッシュしているのかと思い、色々と余計な「オレオレ証明書(最近まで使わせていました)」を削除したが、進展せず。
よく聞くと、最初の送信時だけ出て、電子メール送受信ソフトウェアを終了させない限りは「出ない」とのこと。
また、受信時は一切出ないとのこと。ということは postfix の問題か?
ということで、結局、試行錯誤と考察でひらめいたのが、postfix のhash DB です。
試しに
# postmap -F hash:tls_sni.map(tls_sni.map には、証明書の一覧などが所定フォーマットで記述してある)
# postfix reload
とやったあと、試してみると、当初のメッセージは一切でなくなりました。
ここには、証明書の有効期限までもデータとして保存される作りらしい。
ということで、
2022/12/25 付けの記事 メールサーバの中規模改修と基礎知識(3)~ Dovecot+Pigeonhole,cert-bot
の最終部分に記述した内容は
#!/bin/sh /usr/local/etc/rc.d/apache2 stop /sbin/pfctl -d /usr/local/bin/certbot renew -m user@example.com /sbin/pfctl -e /usr/local/sbin/postmap -F hash:/usr/local/etc/postfix/tls_sni.map /usr/local/sbin/postfix reload /usr/local/sbin/dovecot reload /usr/local/etc/rc.d/apache2 startのようにし、postfix が扱う証明書情報も更新しないと駄目です。
これでこの件は解決。
2023/02/26(日)perl で子プロセスで su を実行させると、親プロセスも道づれで消える
2023/02/26 18:32
《起 動》 ↓ ┌─→《接続要求待ち》 ← LAN・WANからの接続要求 │ ↓ │ 《接続応答》 │ ↓ │ 《子プロセスをfork()》→────┐ │ ↓(親プロセス) │(子プロセス) │ │ ↓ │ │ 《実処理》 │ │ │ | 《子プロセス終了待ち》←──《処理終了》 │ ↓ └←《次の接続を待つ》のような概略構造で、 root 権限で稼働させる代物だが、この構造で、子プロセス内で、perl にて
$status = system (/usr/bin/su username -c "exec comannd ... ") ;
または
$result = `/usr/bin/su username -c "exec comannd ... "`
みたいなことをやらせると、当該処理は実行するものの、実行後、親プロセスまでも終了してしまう。
どちらも更に子プロセスを起こし、 username 権限で実行するというところまでは各所に記載があるため判るが、処理終了時の動作については記載が見当たらず、これ以上の調査に時間を費やせないという現実。
結局、su をやめ、root 権限で動作させ、実行後、このプログラムで生成された必要なファイルを chown するという策で回避。
バグなのかもしれないが、何かやらかしてなるべきしてこうなっているかも知れずで、よく判らないところですね。
2023/01/09(月)dovecot に謎のエラー
2023/01/08 18:21
Jan 8 17:31:43 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF Jan 8 17:31:44 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF Jan 8 17:31:47 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF Jan 8 17:31:47 mx2 syslogd: last message repeated 1 times Jan 8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF Jan 8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 2 pending requests: EOF Jan 8 17:41:42 mx2 dovecot[57447]: auth: Error: auth client 0 disconnected with 1 pending requests: EOF Jan 8 17:41:42 mx2 syslogd: last message repeated 3 times Jan 8 17:51:42 mx2 syslogd: last message repeated 1 times Jan 8 17:51:44 mx2 syslogd: last message repeated 6 timesどうやら、外国のWebサイトにて Apple Mail クライアントの行儀の悪さが原因だという記事を見かけました。
しかしながら、接続元情報が一切出てこない上に、関連付けが出来る他の情報も無いため、断定しきれないですね。
「電子メールの送受信が出来ないという不満が出て来なければ、気にする必要無い」と結論付けていて、それはその通りとも言えますが、原因がハッキリしないエラーメッセージはあまり気分のよいものではないです。
Mac 環境での電子メール設定は、時折問い合わせを受けるものの、問題特定できない内容ばかりで都度悩むのですが、一方で、問い合わせ側の試行錯誤でいつの間にか解決してしまうので、成功事例みたいなものが共有できないんです。
かといって、手本を示すのと、検証の為だけにMac を買うということには絶対にならないので、悩ましいところですね。
2023/01/08(日)whois に障害??
2023/01/08 17:45
mx2-root[97]# whois basekernel.co.jp whois: connect(): Operation timed out mx2-root[98]# whois basekernel.co.jp whois: connect(): Operation timed outメンテナンス情報とか見当たらないし、こういう事態は初めて、、
〔2023/01/08 17:51 追記〕
キャッシュDNS再起動したら復旧。。orz 何だったのだろう??
2023/01/06(金)fml4 → fml8 へのアップデート
2023/01/06 5:00
本家のチュートリアルを見る限り、そんな印象は受けなかったので、本家のチュートリアルを参考に実施しています。
先ずは fml8 を新規インストールします。(2022/12/31(土) fml8 の新規インストール 参照)
fml4 既存MLの fml8 移行の場合は、改めて fml8 で新規ML作成の必要は基本的に無しです。勝手に fml4 環境を上書きされることも無く、fml4 が既存でも問題はありません。
※ https://www.fml.org/software/fml8/ にて、チュートリアル → レシピ一覧 fml4 のMLを fml8 形式のMLへ変換する のリンクを辿っても閲覧出来ない。
チュートリアルページの下の方に
『II. fml のセットアップ~MLの作成』の項目があって、その下の fml4 のMLを fml8 形式のMLへ変換する
https://www.fml.org/software/fml8/Documentation/ja/tutorial/mergeml.fml4to8.html のほうを参照ください。
とはいえ、本家のチュートリアルどおりでは成功しませんので、下記手順を参考にどうぞ:
※ fml4 → fml8 移行に関しては、root ユーザで実施するのが無難です。
# makefml newdomain example.com /var/mail/example.com/~ml ( makefml newdomain バーチャルドメイン名 バーチャルドメインML 格納ディレクトリ )既存の fml4 で運用している、バーチャルドメインにおけるML一式を格納しているディレクトリを指定します。
既存環境に上書きされることはなく、fml8 環境設定ディレクトリに対応付けが設定されるのみです。
尚、これは該当バーチャルドメイン上に複数のMLがあっても、最初の一度だけ実施でよいです。
23/01/06 00:43:01 makefml[1766] warn: /var/mail/example.com/~ml already exist. reuse it.といったメッセージが出ますが、このメッセージは無視して大丈夫です。
次に、
# makefml mergeml ml-name@example.com /var/mail/example.com/~ml/ml-name # cd /var/mail/example.com/~ml/ml-name # chown fmladmin * # chown -R fmladmin varmakefml mergeml にて、既存の fml4 で運用している、バーチャルドメインにおけるメーリングリスト個別ディレクトリを指定します。
makefml mergemlで、fml8 に適応したコンバートが行われます。
ファイル・ディレクトリ所有者が、一部 root になってしまうので、全て fmladmin (fml8 の実行権限ユーザ) に変えます。
postfix の場合、 /etc/mail/aliases /usr/local/etc/postfix/virtualtbl などにML関係の設定をしている場合は、必ず、それらを削除することを忘れないでください。
《※ postfix の設定を変更》 # vi /usr/local/etc/postfix/main.cf 《下記の例のように、alias を追加》 alias_maps = hash:/etc/mail/aliases hash:/var/mail/example.com/~ml/etc/mail/aliases virtual_alias_maps = hash:/usr/local/etc/postfix/virtualtbl/forwardlist hash:/var/mail/example.com/~ml/etc/postfix/virtual
# vi /etc/mail/aliases 《下記を追加》 fmladmin: root 《追加後、下記を実行》 # newaliases上記、makefml mergeml の実行で、雛形ファイルが自動生成されますので、それを流用します。
ただし、そのままでは使えないため、一部変更します:
# cd /var/mail/example.com/~ml/etc/postfix # vi virtual ----- 以下、変更 ----- # example.com is one of $mydestination # CAUTION: DO NOT REMOVE THE FOLLOWING LINE. # example.com example.com ← コメントアウトまたは削除 ### <VIRTUAL test-ml@example.com ML> ### # 以下の5行に、@realmx.example.jp (postfix main.cf で指定の myhostname で示す実ホスト名)を追加 test-ml@example.com test-ml=example.com@realmx.example.jp test-ml-ctl@example.com test-ml-ctl=example.com@realmx.example.jp test-ml-request@example.com test-ml-request=example.com@realmx.example.jp test-ml-admin@example.com test-ml-admin=example.com@realmx.example.jp test-ml-error@example.com test-ml-error=example.com@realmx.example.jp ### </VIRTUAL test-ml@example.com ML> ### ----- 変更はここまで ----- ※ MLごとの個別変更で、題名に通し番号を追加する(makefml mergeml を使用しても、環境によっては引き継がれない設定がある。弊社環境ではこれが発生した) # cd /var/mail/example.com/~ml/text-ml # vi config.cf ----- 以下を、変更または追加(位置的には =cut 行の前) ----- article_header_rewrite_rules += rewrite_article_subject_tag article_subject_tag = [$ml_name:%05d] ----- 変更はここまで ----- ※ この設定で[test-ml:12345] みたいなのがメールタイトルの先頭に自動追加されるようになります。 # postmap hash:virtual # postfix reloadこれで、元通り fml8 での運用が出来るようになりました。
このアップデートは、ML利用者側から見れば、特に利点はありません。
fml4 が運営側にとって、維持困難になってきているので、主な目的はその解消といったところですね。
2023/01/04(水)セカンダリメールサーバの再構築
2023/01/04 6:22
プライマリメールサーバの負荷が高く、応答が遅い時などもセカンダリメールサーバが活用される場面があります。
最近はセカンダリメールサーバを用意していない組織もあるようですが、弊社ではセカンダリメールサーバを備えています。
セカンダリメールサーバは、実は色々な構成があり、プライマリメールサーバのように、電子メールの発信のみを出来るようにしているものもあります。
弊社では、セカンダリメールサーバから電子メールの発信を出来るようにしていませんが、今回はプライマリメールサーバの負荷軽減目的で、明らかなコンピュータウィルスや、確実な spam メールを捨てる仕組みを設けました。

※ この図は、Postfix やメールサーバの構成をそのまま示した図ではありません。
受信メッセージの流れを中心とすると、上記のように感じかなと考えています。
milter-manager で受信メッセージのコンピュータウィルス検査と spam チェックを行います。
実はこれ、Postfix のオンラインマニュアル等を読んでもどうもよく判らないんです。たぶん、こんな感じかなという想像図。。
「outbound」というのは、プライマリメールサーバなどへ送信する場面を想定しています。
上記セカンダリメールサーバ固有の設定
先ず、spamassassin を milter インタフェースで動作させるために、spamass-milter を導入します。一応、http://savannah.nongnu.org/projects/spamass-milt/ が公式サイトのようで、ダウンロードも出来ますが、永らく更新されておりません。
Ver 0.4.0 をダウンロードしてインストールしましたが、Ver 4.0.0 の spamassassin との組み合わせでも使えるようです。
# tar xvzf spamass-milter-0.4.0.tar.gz # cd spamass-milter-0.4.0 # setenv CPPFLAGS '-I/usr/local/include -I/usr/include' # setenv LDFLAGS '-L/usr/local/lib -L/usr/lib' # ./configure --localstatedir=/var # gmake # gmake installとすると、インストール完了です。
milter 形式だと、サーバ単位での spam 判定になってしまうため、少し緩め閾値で spamassassin の挙動を設定しておきます。
サーバ単位での spamassassin の設定は、/etc/mail/spamassassin/local.cf で設定します:
※ /etc/mail/spamassassin/local.cf の内容(変更部分のみ抜粋): rewrite_header Subject report_safe 0 required_score 17.0経験上、閾値 17.0 では、殆どの spam は通過してしまいます。15.0 未満が妥当ですが、運用しながら、様子見で少しずつ下げていくようにします。
以下、FreeBSD 固有の環境になりますが、下記のスクリプトを /usr/local/etc/rc.d 配下に spamass-milter と言う名前で作成しておきます:
#!/bin/sh # PROVIDE: spamass-milter # REQUIRE: LOGIN # BEFORE: mail # KEYWORD: shutdown # # Add the following lines to /etc/rc.conf to enable spamass-milter: # #spamass_milter_enable="YES" # # See spamass-milter(8) for flags. # . /etc/rc.subr name=spamass_milter rcvar=spamass_milter_enable command=/usr/local/sbin/spamass-milter required_dirs=/usr/local/share/spamassassin start_postcmd=start_postcmd stop_postcmd=stop_postcmd start_postcmd() { sleep 1 /usr/sbin/chown ${spamass_milter_socket_owner}:${spamass_milter_socket_group} ${spamass_milter_socket} /bin/chmod ${spamass_milter_socket_mode} ${spamass_milter_socket} } stop_postcmd() { rm -f ${spamass_milter_socket} } load_rc_config $name : ${spamass_milter_enable="NO"} : ${spamass_milter_socket="/var/run/spamd/spamass.sock"} : ${spamass_milter_flags="-f -p ${spamass_milter_socket} ${spamass_milter_localflags}"} : ${spamass_milter_socket_owner="spamd"} : ${spamass_milter_socket_group="mailuser"} : ${spamass_milter_socket_mode="660"} run_rc_command "$1"※注:このスクリプトは Postfix のみの対応です。sendmail が MTA だと、不具合起こすと思います。
上記スプリプトに実行権を与え、更に /etc/rc.conf へ
spamass_milter_enable="YES"の1行を追加しておきます。
ClamAV と、milter-managerも、インストールしておきます。過去記事を参考にしてください。
milter-manager をインストール後、
# /usr/local/sbin/milter-manager -u milter-manager --show-configとやってみて、
define_milter("clamav-milter") do |milter| # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44 milter.connection_spec = "unix:/var/run/clamav/clmilter.sock" # default milter.description = nil # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37 milter.enabled = true # default milter.fallback_status = "accept" ・ ・ ・ define_milter("spamass-milter") do |milter| # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:44 milter.connection_spec = "unix:/var/run/spamd/spamass.sock" # default milter.description = nil # /usr/local/lib/milter-manager/binding/lib/milter/manager/detector.rb:37 milter.enabled = true # default milter.fallback_status = "accept"といった表示がされるのを必ず確認しておきます。
最後に、Postfix 側の設定で、milter と関連するもののみ抜粋すると、
milter_protocol = 6 milter_default_action = accept milter_mail_macros = {auth_author} {auth_type} {auth_authen} smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock non_smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock transport_maps = hash:/usr/local/etc/postfix/virtualtbl/transport.map header_checks = pcre:/usr/local/etc/postfix/header_checks
※ /usr/local/etc/postfix/virtualtbl/transport.map の内容: example.jp smtp:[primary1.example.net] example.net smtp:[primary2.example.net] ※ /usr/local/etc/postfix/header_checks の内容: /^From:\s*<>/m DISCARD /^X\-Spam\-Flag:\s+YES/m DISCARD /^X\-Virus\-Status:\s+Yes/m DISCARD /^X\-Spam\-Level:/m IGNORE /^X\-Spam\-Checker\-Version:/m IGNORE /^X\-Spam\-Status:\s+No/m IGNORE /^X\-Virus\-Scanned:/m IGNORE /^X\-Virus\-Status:\s+Clean/m IGNOREのような感じ。
# postmap hash:/usr/local/etc/postfix/virtualtbl/transport.mapを忘れずに実施しておきます。
上記の、/usr/local/etc/postfix/header_checks の簡単な説明ですが、
「DISCARD」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「配信しました」と送信元に返答しつつ「メッセージを捨てる」という処理を行い、
「IGNORE」で終わる行は、電子メールヘッダ部分にて、左辺のパターンが出現したら「そのヘッダ行は削除して最終配信先へ送る」という処理を行います。
このファイルに記述された内容は、上から下へ順番に処理しますが、「DISCARD」で記述した行は、「そこで打ち切る」という挙動になるらしいです。
この構成で稼働させているが・・・
どうやら、header_checks の設定が上手く反映できていないみたいなのです。IGNORE で「ヘッダ行削除」の挙動がどうも上手く行っていない模様。
X-Virus.... は上手く行っているが、 X-Spam.... が上手く行かない。。
取り敢えず実害はないのですが、セカンダリメールサーバ経由で受信したメッセージは、
X-Spam... は、受信者から見ると2回出てくることになり、不自然なのでどうにかしたいのです。
バグなのか、設定の問題なのか、、、 困っているところです。