2023/12/17(日)ドラッグストアや100円ショップで入手できるエッチング液を試す
2023/12/17 19:24
ですが、エッチング液を作る材料をドラッグストアや大手の100円ショップで容易に入手できます。
今回、当方では初めて試すのですが、元情報は既にネット上に複数、かなり出回っています。
なので二番煎じですが、今回は初めてということもあり、要点だけ示す形になります。
きっかけは、地元の電子部品販売店で、サンハヤト社製のエッチング液が買えなくなったからなのです。
解る人には、どこの販売店か判ってしまうと思います。狸小路にある某店です。再度置いてくれることを希望しています。はい。
通信販売で本州の販売店から入手可能ですが、送料がかかる（結果、トータルで割高になる）上に、北海道では、早くても翌々日配達なので、入手の際、使い勝手があまりよろしくない。
代替になるもの（「腐食液」「エジンバラ液」と称するもの）はあるのですが、「店舗で直接入手できるか」から調べるのが、多忙な我が身にはとても手間で時間取れないので、これから紹介する手法に落ち着いたというところです。コメントで販売情報や価格の共有を頂けると嬉しいです。
前置きがまた長くなってしまいましたが、ここから本題になります。
○必要なもの
・クエン酸
・食塩
・オキシドール(500㎖ ものが望ましい)
＝＞ この３つでエッチング液を作ります。
最近、クエン酸・オキシドール・食塩は、ダイソーや Seria といった大手の100円ショップで販売されているようです。
【2024/01/12 追記】
・ジップロックまたは同等品（冷凍用を選ぶこと）
＝＞ これは、１００円ショップあたりでも入手できますね。
・重曹
・アルミホイル
＝＞ 廃液処理で使います。
重曹もダイソーやSeria といった大手の100円ショップで販売されているようです。【2024/01/12 追記】
・重量計
・計量カップ(200㎖ ものでよい)
・耐熱プラスチックトレイ（20cm x 30cm 以上、深さ 5cm 程度が望ましい)
・コーヒーフィルター
・コーヒードリッパー(プラスチック製のもの)
＝＞ 調合や廃液処理に使います。重量計は郵便物の重量を計測する秤などが使えます。ホームセンターなどで販売しています。
計量カップ・耐熱プラスチックトレイ・コーヒードリッパーは、一度でもエッチング処理に使用したら、
有害物質が付着するため、本来の用途には使えません。
なので、専用のものを別途用意するようにしましょう。重量計以外は、１００円ショップで入手できるもので充分です。
○準備
クエン酸 ４：食塩 １ の割合で混合粉末を作ります。
例えば、クエン酸４０ｇ に対し 食塩 １０ｇ という割合です。
どの紹介記事見ても４：１の記載ですが、食塩の割合を少し増やすと、エッチングが早く進むようです。
次に、混合粉末をオキシドールに溶かします。
オキシドールをジップロックに入れ、混合粉末を溶かします。完全に粉末が溶けるまで、攪拌してください。
オキシドールは、エッチング対象のプリント基板が浸かる程度で充分です。
基板サイズが 150mm x 75mm だったら、オキシドールは 150㎖ が適量かと思います。
150㎖ のオキシドールに対し、クエン酸 40g 食塩 10g で上手く行きます。
オキシドールの量に応じて、クエン酸と食塩の量を変えます。但し、４：１の割合は崩さないようにしましょう。
この様子を撮影するのを忘れたので、今回は割愛ということで。。。
液は無色透明のオキシドールの色、そのままです。
○エッチング実施
オキシドール混合液にエッチング対象のプリント版を入れると、途端にエッチング反応が始まります。
オキシドール混合液は、銅イオンが溶けだし、マリンブルーの色に変わっていきます。
湯煎すると反応が早く進みます。湯煎の際、液が35℃を越えないように注意します。
泡が湧いてきますので、揺すりながら泡を落としつつ状況を観察してください。
また、生暖かくなる程度に発熱するので、この点も注意してください。
ちなみに、この工程は従来のサンハヤト社製感光基板でも上手くいきます。
2023/12/08 発売開始の、新しいサンハヤト社製感光基板では、まだ試すことが出来ていません。もし新しい感光基板で、このエッチング手法を試した方が居られたら、コメントで結果共有して頂けると嬉しいです。
塩化第二鉄液によるエッチング同様、パターンの細かい部分から、広い場所にエッチングが進んで行きます。
エッチングは、最初は「本当に進んでいるのか？」という感じですが、終盤は一気に進むようです。
ここで、耐熱プラスチックトレイに水道水を入れておきましょう。水道水はプリント版が全部浸かる程度でよいです。
エッチングが終わったら、液からプリント版を引き上げて、耐熱プラスチックトレイに満たした水道水に浸し、水洗いします。
この途中経過も撮影するのを忘れたので、今回は割愛ということで。。。
物珍しさと、どうなるか判らない状態だったので、メンタル的余裕が無かったのが実際のところ。
エッチング完了後の結果だけは撮影しました。２枚同時で15分程度にて完了しました。
感光基板で露光した際に残るマスク素材を落とした後なので、銅箔が見えています。
結構そこそこな規模の回路なので、最初からぶっつけ本番なのが、かなりのリスクでした。
でも見ての通り、大変上手くいったので、この点は満足です。
○廃液処理
基本的に、この方法で作成したエッチング液は、再利用できないと思ったほうがよいでしょう。
サンハヤト社製エッチング液も、使用後のエッチング液を暫く保存したあとに再度使ってみると、実に使えない状態になっていることが多々あるので、そんなものかと思っています。
このままでは、有毒ということで下水に流せないので、廃液処理を行います。
廃液処理には、マリンブルーになった液に対して、1cm x 3cm 程度の短冊状にカットしたアルミホイルを数枚ずつ投入し、銅イオンを析出するということを行います。
この反応はアルミホイルを一度にたくさん入れると、反応が激しくなって液が熱くなるので、注意しつつ作業を行います。
液がこんな色になって、アルミホイルによる反応が起きなくなったら、この工程は終了です。
また、この工程で水素が発生します。有毒ガスではないですが、換気を良くし、火気を近づけないようにしましょう。
析出した銅の粉末混じりのヘドロのような液になります。まだ、これで作業完了ではありません。
酸性が強すぎて、このままでは下水に流せません。試しに pH試験紙でチェックしてみるとこんな感じです。
重曹を混ぜて中和します。銅粉末はもえないゴミで処分する必要があるため、予めコーヒードリッパーとコーヒーフィルターで、ろ過して分離すると良いでしょう。
下水に流すには pH 5.8 ～ pH 8.6 の範囲である必要があります。100㎖ に対し、重曹20g 程度が適当かと思います。
適当にpH 見ながら少しずつ混ぜたので、適量が良く判っていません。
中和した液は、２倍量以上の水道水と一緒に下水に流します。
次回、作業した際には、もうすこしマトモな手順を書き残したいと考えています。
2023/11/12(日)Python 一部モジュール・ライブラリが更新できない
2023/11/13 1:03
通常、ＯＳバージョンアップの場合、前バージョンまでの動作互換性は保証しているので、必ずしも必要ではないはずなのですが、それでも不可解な挙動が生じる場合があり、それを未然に防ぐために「全てのアプリケーション再構築」という作業を行うことにしているのです。
多くのマトモな方々には信じられないかもしれないですが、この事業を始めたばかりの頃、
『たった１回のアプリケーション障害で、しかもたった１日で一方的なサーバホスティング解消』をされたことがあり、これは純粋にアプリケーションの不具合で、ＯＳアップデートが問題ということでもなく、運用側でどうすることも出来ない不可抗力な原因の事象でした。
当然、「一方的」だったので、説明責任のかけらも果たすことが出来ませんでした。
まぁ、そんなに信用できないなら「最初から易々と近づくな」と言いたいし、何より舐められまくってますね。
そんな態度の「上から目線なクライアント」は、相手にしないことは言うまでもないです。
きっと、他所でも毛嫌いされていることだろうと思われます。
２０年以上やっていますが、この類の不具合は、この件含めて２回。
２回目は説明責任果たせたので、理解してもらえました。過去２０年に限れば安定稼働しています。
前置きが長くなり過ぎたのですが、ここから本題。
FreeBSD12 → FreeBSD13 にＯＳアップデートして、アプリケーション再構築をすると、一部の Python アプリケーションが再構築出来ずに、以下のようなエラーを吐いてしまう。
File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 972, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "/usr/local/lib/python3.9/site-packages/setuptools/__init__.py", line 18, in
from setuptools.dist import Distribution
File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 34, in
from ._importlib import metadata
File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 39, in
disable_importlib_metadata_finder(metadata)
File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 28, in disable_importlib_metadata_finder
to_remove = [
File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in
if isinstance(ob, importlib_metadata.MetadataPathFinder)
AttributeError: module 'importlib_metadata' has no attribute 'MetadataPathFinder'
ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
*** Error code 1
この現象は、時々起きるらしく、外国のメンテナンス作業者の解決策として、どうやら# cd /usr/local/lib # rm -rf python3.*としてから、
# portupgrade -rf python.3.9.18(インストールされている Python バージョンに合わせる)
とすると、解消する模様。やや強引かつ豪快な解決手段だが、これが確実なのだとか。
これをやったら、確かに問題は解消しました。
2023/11/03(金)FreeBSD14 と FreeBSD12
2023/11/03 7:07
質問やコメントにも目を通しているものの、殆ど反応出来ずな状態です。
さて、いつの間にか FreeBSD 12は、リリースから５年が経過しようとしています。2018/12/11 に 12.0 がリリースされました。
メンテナンスサポート期間は５年と定められたため、５年後の月末を以ってサポート終了です。
〔FreeBSD 公式サイト日本語版より https://www.freebsd.org/ja/security/#sup〕
FreeBSD 12.4 を稼動させるサーバ機器が７台あるのですが、そのうちの５台を急遽 13.2 (2023/04/11 リリース)へアップデート中。
さて、FreeBSD 14 ですが、これもいつの間にか近日リリースなのです。
〔FreeBSD 公式サイトより https://www.freebsd.org/releases/14.0R/schedule/〕
どういう新機能等があるのか、概要の意訳をして確認してみました：
・root アカウントのデフォルトシェルは、sh(1) になる。 → 何で？
・デフォルトのMTAは、sendmail(8) から dma(8) に変更される。 → 既に Postfix 使いなので、関係ないか？
・Locale が CLDR41.0 , Unicode 14.0 に対応 → ちょっと対応遅いと思う。
・Base64 ライブラリが標準装備になった
・portsnap は削除した。代わりに git を使え。 → えぇぇ！？（でも gitup が使えそうだ）
・pw(8),bsdinstall(8) は、ユーザホームディレクトリを /usr/home 配下ではなく、/home 配下に作成するようにした。→ まともにするための改修ですね。
・libfido2 ライブラリが 1.13.0 になった。→ あれ、既に(大手企業で流行りの)パスキーに対応しているらしい。
・OpenSSL ライブラリが、1.1.1 から 3.0.12 になった。→ 流石にこれはアップデート必須です。
・mergemaster(8) は非推奨になった。代わりに etcupdate(8) を使え。→ えぇぇ！？
・デバイスドライバ amr(4)、iir(4)、mn(4)、mly(4)、nlmrsa(4) 、twa(4) は削除した。→ 時代の流れだね。
・Wi-Fi6 に対応した。 → やっとか。
・FreeBSD15 以後は 32bitプラットフォームをサポートしない。但し、互換機能で32bit アプリケーションの動作は可能とする。 → これも時代の流れですね。。2029年には32bitCPU でFreeBSD は動作しなくなるのかな。
他、多くの項目ありますが、当方が興味なかったり、説明が難しかったりしたので、結構端折っています。
〔2023/12/16 追記〕
FreeBSD14 は、2023/11/20 付けでリリースされました。
FreeBSD13同様、５年間のサポート(2028/11/30 まで)を実施するようです。
また、本家から日本語のページが無くなってしまいました。非営利ベースで担当出来る人が居なくなった模様。
2023/04/15(土)複数の電源トランスを扱う場合の注意点がよく判らない・・・
2023/04/15 23:37
パワートランジスタが壊れた回路の概略図を描くとこんな感じ ↓
トランジスタの１つ、或いは２つがコレクタ・エミッタ間で短絡故障を起こしました。
電源トランスが複数あり、一次側の０Ｖ端子側、２次側の０Ｖ端子側を共に合わせて配線しています。
こうすることで、極性が合うはずと思っているんですが、
結果的に、金属ケース筺体を利用して、ダイオードブリッジの中間を共通接地にした形というアホな回路になっていたため、何かしらの循環電流が流れる感じになっていたのかもしれません。
C05 の端子間電圧が 54V になっていたり(ここは 42.5V 以上にはならないはず・・・・）、トランジスタが壊れなかったとしても、意味不明のスパークを筺体で発生させてヒューズが飛ぶ、とか起きる謎の現象もあったので、それは、この狂った配線が原因なのだろうか・・・？
いずれにしても、色々と直観的によろしくないと思うので、下記のように変更を予定しています。
ただ、これでもパワートランジスタ故障の原因が釈然としません。
破壊するとしたら、VEBOが絶対最大定格５Ｖを越えたくらいしか考えられない感じで、これが発生する条件というのがどうも判りません。。
2023/04/15(土)整流回路の平滑コンデンサは容量が大きければいいというものではないらしい
2023/04/15 6:09
１０年近く前に、PC-9801 のBASIC で組んで公開されていた整流回路シミュレーションがあったので、手元のMZ-2500 BASIC-M25 に移植して使っています。最低限機能させるための移植なので、色々変な部分はあるんですが。。orz
引用元の書籍を紹介しようとして、手持ちの書籍を漁ったのですが、何故か見つからない。
ということで、「原作者の方、申し訳ないです・・・」ということで、、、
いずれにしても、MZ-2500だったから移植出来たのです。他の機器だったら、かなり苦しい。
ここから本題なのですが、当初は、こんなふうにしていました ↓
そして、おもむろにこのシミュレーションを動作させてみると・・・
負荷電流１Ａという、意図的に悪い動作条件を与えたんですが、こんな感じになりました。
黄色の線は電流を示しますが、正確ではないし、描画がおかしいので、とりあえず無視。
注目すべきは赤っぽい実線。
このあとに５Ｖ出力の３端子レギュレータが繋がるのですが、安定動作には7.5Ｖ以上の電圧が必要なので、14ms あたりまでは何かしらの不具合が出る可能性がある。
静電容量が大きすぎて、電圧が上がり切りません。
ということで、平滑コンデンサ C01 を下記のようにしてみました ↓
静電容量だけ変えて、他は同じ条件です。
ここまでは、安定化電源装置を動作させるための補助電源部の話で、
本当の本題は、PT2-D3-C05 で構成する、この平滑回路です ↓
22mF(22,000μF)というオーディオアンプの電源に使うような大容量電解コンデンサを当初使っていました。
安定化電源装置の最高出力電圧は２４Ｖ、最高出力電流は３Ａの設計です。
２４Ｖの安定化出力を出すためには、平滑回路の電圧は２７Ｖは欲しい。
これを安定化電源装置の設計最大電流である３Ａでシミュレーションさせると・・・
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 付けの記事 メールサーバの中規模改修と基礎知識（３）～ 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
《起 動》 ↓ ┌─→《接続要求待ち》 ← ＬＡＮ・ＷＡＮからの接続要求 │ ↓ │ 《接続応答》 │ ↓ │ 《子プロセスを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どうやら、外国のＷｅｂサイトにて 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 追記〕
キャッシュＤＮＳ再起動したら復旧。。orz 何だったのだろう？？
2023/01/06(金)fml4 → fml8 へのアップデート
2023/01/06 5:00
本家のチュートリアルを見る限り、そんな印象は受けなかったので、本家のチュートリアルを参考に実施しています。
先ずは fml8 を新規インストールします。(2022/12/31(土) fml8 の新規インストール 参照)
fml4 既存ＭＬの fml8 移行の場合は、改めて fml8 で新規ＭＬ作成の必要は基本的に無しです。勝手に fml4 環境を上書きされることも無く、fml4 が既存でも問題はありません。
※ https://www.fml.org/software/fml8/ にて、チュートリアル → レシピ一覧 fml4 のＭＬを fml8 形式のＭＬへ変換する のリンクを辿っても閲覧出来ない。
チュートリアルページの下の方に
『II. fml のセットアップ～ＭＬの作成』の項目があって、その下の fml4 のＭＬを fml8 形式のＭＬへ変換する
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 で運用している、バーチャルドメインにおけるＭＬ一式を格納しているディレクトリを指定します。
既存環境に上書きされることはなく、fml8 環境設定ディレクトリに対応付けが設定されるのみです。
尚、これは該当バーチャルドメイン上に複数のＭＬがあっても、最初の一度だけ実施でよいです。
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 などにＭＬ関係の設定をしている場合は、必ず、それらを削除することを忘れないでください。
《※ 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> ### # 以下の５行に、@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> ### ----- 変更はここまで ----- ※ ＭＬごとの個別変更で、題名に通し番号を追加する（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 での運用が出来るようになりました。
このアップデートは、ＭＬ利用者側から見れば、特に利点はありません。
fml4 が運営側にとって、維持困難になってきているので、主な目的はその解消といったところですね。