はんかくさい日報

2024/11/09(土)初めて両面基板を作ってみた（両面感光基板を使用）

2024/11/09 3:08 電子工作

初めてですが、結構上手く行ったので、一部でも参考になればと考えています。
今回は、サンハヤト社謹製の両面感光基板を使用しました。
最初にお断りしておきますが、当方は、サンハヤト社の回し者ではありません。道具を売っている製造業者をこれしか知らないので・・

○ 両面基板作成にあたって固有に必要と思われるもの

・両面感光基板	感光基板でプリント基板作るのであれば、必然的ではあるが・・・
・両面感光基板対応露光装置	当方は、昔買ったこれまたサンハヤト社謹製の BOX-W9B というものを使っています。　しかし、これはもう現在では製造自体していません。　後継となる対応機種はなく、両面基板対応のものは BOX-W7000 しかない。　しかもこれは２０万円以上するため、現実には、BOX-S3000 にて片面ずつ露光するか、BOX-S3000 も安くないため、各自の創意工夫が求められる部分であることがネックですね。
・両面テープ	露光時、基板の位置固定に使用します。粘着力は弱いのものを選びましょう。　撮影時、この粘着テープを使用しましたが、これでも粘着力が強すぎると感じました。
・プリント基板の切れ端	両面テープと共に、基板の位置固定に使用します。　プリント基板は1.6mm厚または1.0mm厚のものが多いので、　現物と同じ厚みのものを２枚必ず用意しましょう。　撮影時の不手際で、両面テープを張った状態の切れ端になっています。。
・スルピンキット（スルーホールを作る場合）	0.8mm用のものを用意しましょう。最も小径且つ最も多く使うのが 0.8mm穴。　個人的にはこれでも太いと思う。　ワンランク細いもの、例えば 0.7mm とか 0.6mm ものが欲しいですね。
・はんだ吸引機（スルーホールを作る場合）	スルーホールの生成時に必須なのです。詳細はスルピンキットの説明を参照お願いします。

次に、具体的な制作方法の要点です。

	１）パターン作成　先ずは通常通りパターンを作成します。　この時、基板アートワークの外側にトンボ線を必ず入れておきます。（いわゆる十字線とかトリムマークと称するもの）　これが重要です。
	２）ポジフィルムの張り合わせ　トンボ線に平行になるように２辺に両面テープで基板の切れ端を合わせ、　裏面と表面のトンボ線を合わせつつ、貼り合わせていきます。　この精度が裏表のズレの精度に直結しますが、トンボ線に合わせることで、　意外と0.1mm以下の誤差にすることが可能です。　裏表や上下を間違えないように、細心の注意を払いましょう。
	３）通常どおり、露光とエッチング　両面基板ですから、　露光もエッチングも片面基板２枚分の考慮が必要なことに注意しましょう。　いつも片面基板ばかりで作業していると忘れがちなところです。　過露光でごく一部のパターンが切れてしまいました・・・
	４）スルーホールの作成　スルーホールにしたい穴にスルピンキットでスルーホールを作成。　　― スルーホールを打ち込み、　　― ハンダで埋め込み、　　― ハンダ吸引機で余分なハンダを吸い取る・・　という工程の繰り返しですが、　慣れないので仕上がりがかなり汚くなってしまいました・・・　ハンダ吸い取り機は小さいほうがいいかもしれません。
	５）実装してみた　一部部品の実装サイズ確保を誤ってしまい、　更なる空中配線の部品が出てしまいました・・・ orz 　しかしながら、動作はしたので、これで完成としてしまいました。

コメント（0件）

2024/06/21(金)OpenLDAP 2.6.8 では、Cyrus-SASL 抜きの構築は出来ない

2024/06/21 16:53 ソフトウェア開発日誌・技術

これも嵌ったので自分メモ：
OpenLDAP をソースコードから構築する場合、configure で指定するオプションに --without-cyrus-sasl を指定して、Cyrus-SASL のサポートを外すことが出来ます。
ところが、こうすると、 OpenLDAP 2.6.8 では、途中で下記のエラーを吐いて構築不能になるのです：

ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_host_connected_to' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_int_sasl_config' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_int_sasl_get_option' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_int_sasl_open' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_int_sasl_set_option' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_cbinding' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_cbinding_parse' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_install' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_mutex_dispose' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_mutex_lock' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_mutex_new' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_mutex_unlock' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_remove' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_secprops' failed: symbol not defined
ld: error: version script assignment of 'OPENLDAP_2.200' to symbol 'ldap_pvt_sasl_secprops_unparse' failed: symbol not defined
cc: error: linker command failed with exit code 1 (use -v to see invocation)

これは、Cyrus-SASL をインストールし、更に --without-cyrus-sasl のオプションを外さないとエラーが取れない。
弊社の使用形態では Cyrus-SASL は使わないため、このオプションは必須の形で指定していたが、嫌でも Cyrus-SASL をインストールし、サポートさせないといけない状態に…

このバージョンだけの問題なのか、本来は Cyrus-SASL と OpenLDAP はセットで使う仕様であるので、今後の強制的な方針なのかは判りません。
メンテナンス・運用管理の観点からは、出来る限り余計なものは入れたくないんだけどね・・・

コメント（0件）

2024/06/20(木)FreeBSD 13.3R で dovecot 2.3.21 はそのまま構築できない

2024/06/21 16:36 サーバ運営・管理

先日、ちょっと嵌ったので自分メモ
FreeBSD 13.3 では、clang が Ver 17 になった影響か、dovecot 2.3.21 ではこんな感じで、コンパイルエラーになる：

test-mail-index-transaction-update.c:633:14: warning: comparison of function 'timezone' equal to a null pointer is always false [-Wtautological-pointer-compare]
  633 |         test_assert(timezone == 0);
      |                     ^~~~~~~~    ~
../../src/lib-test/test-common.h:20:8: note: expanded from macro 'test_assert'
   20 |         if (!(code)) test_assert_failed(#code, __FILE__, __LINE__); \ 
      |               ^~~~
test-mail-index-transaction-update.c:633:14: note: prefix with the address-of operator to silence this warning
  633 |         test_assert(timezone == 0); 
      |                     ^ 
      |                     & 
../../src/lib-test/test-common.h:20:8: note: expanded from macro 'test_assert'
   20 |         if (!(code)) test_assert_failed(#code, __FILE__, __LINE__); \ 
      |               ^ 
test-mail-index-transaction-update.c:648:42: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  648 |                 hdr.day_stamp = tests[i].old_day_stamp + timezone; 
      |                                                        ^ ~~~~~~~~ 
test-mail-index-transaction-update.c:648:17: error: incompatible pointer to integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char *(*)(int, int)' [-Wint-conversion]
  648 |                 hdr.day_stamp = tests[i].old_day_stamp + timezone; 
      |                               ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
test-mail-index-transaction-update.c:650:49: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  650 |                 mail_index_update_day_headers(t, tests[i].now + timezone); 
      |                                                               ^ ~~~~~~~~ 
test-mail-index-transaction-update.c:650:36: error: incompatible pointer to integer conversion passing 'char *(*)(int, int)' to parameter of type 'time_t' (aka 'long') [-Wint-conversion]
  650 |                 mail_index_update_day_headers(t, tests[i].now + timezone); 
      |                                                  ^~~~~~~~~~~~~~~~~~~~~~~ 
./mail-index-transaction-private.h:127:77: note: passing argument to parameter 'day_stamp' here
  127 | void mail_index_update_day_headers(struct mail_index_transaction *t, time_t day_stamp); 
      |                                                                             ^ 
test-mail-index-transaction-update.c:654:63: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith]
  654 |                 test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i); 
      |                                                                             ^ ~~~~~~~~ 
../../src/lib-test/test-common.h:26:9: note: expanded from macro 'test_assert_idx'
   26 |                 if (!(code)) test_assert_failed_idx(#code, __FILE__, __LINE__, i); \ 
      |                       ^~~~ 
test-mail-index-transaction-update.c:654:37: warning: comparison between pointer and integer ('uint32_t' (aka 'unsigned int') and 'char *(*)(int, int)') [-Wpointer-integer-compare]
  654 |                 test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i); 
      |                                 ~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
../../src/lib-test/test-common.h:26:9: note: expanded from macro 'test_assert_idx'
   26 |                 if (!(code)) test_assert_failed_idx(#code, __FILE__, __LINE__, i); \ 
      |                       ^~~~ 
5 warnings and 2 errors generated.
gmake[3]: *** [Makefile:916: test-mail-index-transaction-update.o] エラー 1
gmake[3]: ディレクトリ '/usr/local/src/dovecot-2.3.21/src/lib-index' から出ます
gmake[2]: *** [Makefile:573: all-recursive] エラー 1
gmake[2]: ディレクトリ '/usr/local/src/dovecot-2.3.21/src' から出ます
gmake[1]: *** [Makefile:704: all-recursive] エラー 1
gmake[1]: ディレクトリ '/usr/local/src/dovecot-2.3.21' から出ます
gmake: *** [Makefile:548: all] エラー 2

軒並み、timezone 絡みのようで、この件に関するパッチが３つ公開されています：
その１　https://github.com/dovecot/core/commit/e983ead775671186b3c8567d59973d2e52b678c7
その２　https://github.com/dovecot/core/commit/1a7b1f66fe4b86cb642dbcfe5a0192c1b77d0e17
その３　https://github.com/dovecot/core/commit/867a37fa7b74f798a931fb582214b5377f57610e

〔その１　src/lib/ioloop-notify-kqueue.c を修正〕

			@@ -11,6 +11,7 @@
11	11
12	12		#include "ioloop-private.h"
13	13		#include "llist.h"
	14	+	#include "time-util.h"
14	15		#include <unistd.h>
15	16		#include <fcntl.h>
16	17		#include <sys/types.h>

〔その２　src/lib-index/test-mail-index-transaction-update.c を修正〕

			@@ -6,6 +6,7 @@
6	6		#include "test-common.h"
7	7		#include "mail-index-private.h"
8	8		#include "mail-index-transaction-private.h"
	9	+	#include "utc-offset.h"
9	10
10	11		#include <time.h>
11	12
			@@ -630,7 +631,9 @@
630	631
631	632		/* daylight savings times were confusing these tests, so we'll now
632	633		just assume that TZ=UTC */
633		-	test_assert(timezone == 0);
	634	+	time_t now = time(NULL);
	635	+	struct tm *local_time = localtime(&now);
	636	+	test_assert(utc_offset(local_time, now) == 0);
634	637
635	638		hdr.messages_count = 10;
636	639		t = mail_index_transaction_new();

〔その３　src/lib-index/test-mail-index-transaction-update.c を修正〕

			@@ -648,13 +648,13 @@
648	648		i_zero(&hdr);
649	649		for (j = 0; j < N_ELEMENTS(hdr.day_first_uid); j++)
650	650		hdr.day_first_uid[j] = 8-j;
651		-	hdr.day_stamp = tests[i].old_day_stamp + timezone;
	651	+	hdr.day_stamp = tests[i].old_day_stamp;
652	652		memcpy(t->post_hdr_change, &hdr, sizeof(hdr));
653		-	mail_index_update_day_headers(t, tests[i].now + timezone);
	653	+	mail_index_update_day_headers(t, tests[i].now);
654	654
655	655		struct mail_index_header new_hdr;
656	656		memcpy(&new_hdr, t->post_hdr_change, sizeof(new_hdr));
657		-	test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp + timezone, i);
	657	+	test_assert_idx(new_hdr.day_stamp == tests[i].new_day_stamp, i);
658	658		test_assert_idx(memcmp(new_hdr.day_first_uid,
659	659		tests[i].new_day_first_uid,
660	660		sizeof(uint32_t) * 8) == 0, i);

これらのパッチを手動で当て、いつもの手順でコンパイルすることで、いくつか Warning が出るものの、通常通りの使用可能となるようです。
バージョンアップで、この不具合が解消されることを期待したいところ。

コメント（0件）

2024/01/13(土)危うく騙されそうになった、、

2024/01/13 6:03

可能な限り全文晒します：

EXPIRATION REMINDER

This notice is to bring to your notice that your domain invoice number
nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn is OVERDUE. example.com to be due
in 12 January 2024 is SUSPENDED.

The contact currently listed is xxxxxxxxx xxxxxxxxx.

RENEW example.comT
https://csschecker.com/cart/nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

EXPIRATION:
12 JANUARY 2024

DISCLAIMER NOTICE:
We can not be held legally accountable for any claims, damage or
suffering that you may incur owing to the expiration of
example.com. Any such damages may include but are not solely
limited to: sales losses, lost files without backups, loss of results
in search rankings, lost appointments, undeliverable email and any
other business, service or technical damages that you may incur. For
further reference please refer to section 22.l.3.g of our TOS

LIABILITY:
This is the final notice that we are required to send out with regards
to the expiration of example.com.

SECURE ONLINE RENEWAL
https://csschecker.com/cart/nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

Unable to click the link? Copy and Paste this into your browser:
HTTPS://CSSCHECKER.COM/CART/nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

All web services will be restored automatically on example.com upon
receipt of payment. We thank you for your cooperation and continued
business.

ALERT SENT ON JANUARY 12 2024

The contents of this email are strictly confidential.

当該ドメインがレジストリ的に有効期限切れで使用不能になった、みたいな通知だが、
２ヶ月くらい前に自動更新したばかりで、whois で確認してもドメインステータスには問題は無さそう。

恐らく、ドメイン更新料金を騙し取ろうとしているのだろう。
ドメインレジストラ業者でないと、入手できない個人情報を使っているので、たちが悪い。
今後、こういうのには注意が必要である。皆さまもご注意ください。

コメント（0件）

2023/12/17(日)ドラッグストアや100円ショップで入手できるエッチング液を試す

2023/12/17 19:24 電子工作

『ドラッグストアや100円ショップで入手できるエッチング液』と言っても、エッチング液そのものを販売しているわけではありません。
ですが、エッチング液を作る材料をドラッグストアや大手の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 見ながら少しずつ混ぜたので、適量が良く判っていません。

中和した液は、２倍量以上の水道水と一緒に下水に流します。
次回、作業した際には、もうすこしマトモな手順を書き残したいと考えています。

コメント（0件）

2023/11/12(日)Python 一部モジュール・ライブラリが更新できない

2023/11/13 1:03 サーバ運営・管理ソフトウェア開発日誌・技術

FreeBSD12 → FreeBSD13 に更新後、アプリケーションのライブラリ等が旧ＯＳバージョンにて構築したものだったりすると、それが原因で謎の動作不具合起こしたりする場合が稀にあるため、「安定動作」を目的として、全てのアプリケーションを再構築します。

通常、ＯＳバージョンアップの場合、前バージョンまでの動作互換性は保証しているので、必ずしも必要ではないはずなのですが、それでも不可解な挙動が生じる場合があり、それを未然に防ぐために「全てのアプリケーション再構築」という作業を行うことにしているのです。

多くのマトモな方々には信じられないかもしれないですが、この事業を始めたばかりの頃、
『たった１回のアプリケーション障害で、しかもたった１日で一方的なサーバホスティング解消』をされたことがあり、これは純粋にアプリケーションの不具合で、ＯＳアップデートが問題ということでもなく、運用側でどうすることも出来ない不可抗力な原因の事象でした。

当然、「一方的」だったので、説明責任のかけらも果たすことが出来ませんでした。
まぁ、そんなに信用できないなら「最初から易々と近づくな」と言いたいし、何より舐められまくってますね。
そんな態度の「上から目線なクライアント」は、相手にしないことは言うまでもないです。
きっと、他所でも毛嫌いされていることだろうと思われます。
２０年以上やっていますが、この類の不具合は、この件含めて２回。
２回目は説明責任果たせたので、理解してもらえました。過去２０年に限れば安定稼働しています。

前置きが長くなり過ぎたのですが、ここから本題。
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 バージョンに合わせる)
とすると、解消する模様。やや強引かつ豪快な解決手段だが、これが確実なのだとか。
これをやったら、確かに問題は解消しました。

コメント（1件）

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 まで)を実施するようです。
また、本家から日本語のページが無くなってしまいました。非営利ベースで担当出来る人が居なくなった模様。

コメント（0件）

2023/04/15(土)複数の電源トランスを扱う場合の注意点がよく判らない・・・

2023/04/15 23:37 電子工作

実際、事例が少ない上、要点しか書いていない場合が殆どで「何故か」の言及は殆ど皆無。

パワートランジスタが壊れた回路の概略図を描くとこんな感じ ↓

トランジスタの１つ、或いは２つがコレクタ・エミッタ間で短絡故障を起こしました。
電源トランスが複数あり、一次側の０Ｖ端子側、２次側の０Ｖ端子側を共に合わせて配線しています。
こうすることで、極性が合うはずと思っているんですが、

結果的に、金属ケース筺体を利用して、ダイオードブリッジの中間を共通接地にした形というアホな回路になっていたため、何かしらの循環電流が流れる感じになっていたのかもしれません。
C05 の端子間電圧が 54V になっていたり(ここは 42.5V 以上にはならないはず・・・・）、トランジスタが壊れなかったとしても、意味不明のスパークを筺体で発生させてヒューズが飛ぶ、とか起きる謎の現象もあったので、それは、この狂った配線が原因なのだろうか・・・？

いずれにしても、色々と直観的によろしくないと思うので、下記のように変更を予定しています。

ただ、これでもパワートランジスタ故障の原因が釈然としません。
破壊するとしたら、V_EBOが絶対最大定格５Ｖを越えたくらいしか考えられない感じで、これが発生する条件というのがどうも判りません。。

コメント（0件）

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Ωよりも小さく、このシミュレーションで得られる電圧よりは若干高めになると思います。

シミュレーション上の紫の実線の山と赤っぽい実線の山の間隔が広いと、それだけ電力損失が増え、整流ダイオードあたりが発熱しやすくなるのではないかと思われます。
ですが、このことがパワートランジスタの破損に直結するとは思えないです。

コメント（0件）

2023/04/06(木)Let's encrypt のサーバ証明書をpostfix で使う場合の注意

2023/04/06 16:15 サーバ運営・管理

今回、初めての経験だったのでメモ。。。
発端は、「こんなメッセージが出るんだが・・・」という一報。

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

こんな感じになるらしい。確かにここでは「期限切れ」になっています。

証明書の誤認識であることには間違いないので、クライアント側の設定で何か問題を引き起こしているのではないかと思うのですが、いろいろと不可解なので、一報を頂いた会社へ許可を得て出向いて、原因究明と解消を試みました。

証明書チェーンはあっているが、変にキャッシュしているのかと思い、色々と余計な「オレオレ証明書（最近まで使わせていました）」を削除したが、進展せず。

よく聞くと、最初の送信時だけ出て、電子メール送受信ソフトウェアを終了させない限りは「出ない」とのこと。
また、受信時は一切出ないとのこと。ということは postfix の問題か？

ということで、結局、試行錯誤と考察でひらめいたのが、postfix のhash DB です。
試しに

# postmap -F hash:tls_sni.map
# postfix reload

（tls_sni.map には、証明書の一覧などが所定フォーマットで記述してある）

とやったあと、試してみると、当初のメッセージは一切でなくなりました。
ここには、証明書の有効期限までもデータとして保存される作りらしい。

ということで、
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 が扱う証明書情報も更新しないと駄目です。
これでこの件は解決。

コメント（0件）

		2025/02
日	月	火	水	木	金	土
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28