年賀状の宛名書き 2023

年賀状の宛名印刷の宛名データ生成は自作のPerlスクリプトでやってます.元になる住所はLDAP (OpenLDAP) に登録してあります.

何でそんな面倒くさいことをしているかというと,住所の二重登録が嫌だからです.かつてはMicrosoft Accessに年賀状を出す人の宛名を登録してありました.そこでよくあったトラブルは,自分用の汎用のアドレス帳とその年賀状専用のAccessのデータに齟齬が生じたのだけれどもどちらか正しいか解らないという事態でした.

それなら,自分の汎用アドレス帳から年賀状宛名を生成するか,少なくとも自分の汎用アドレス帳と年賀状のアドレス帳を同じツールで見比べることができるようにしよう,と考えました.たぶん2000年頃だと思います.

アドレス帳のデータベースと言えば,LDAPしかないようでした.もちろん,MySQLを使う手もないことはないですが,「同じツールで見比べる」という条件はクリアできそうにないです.

そこで適当にネットのドキュメントを斜め読みしたり,試行錯誤してデータベースを築き上げてたぶん20年間くらい使ってます.

「個人用の汎用のアドレス帳」も,そんなにこれが良いと言うこともなかったのですが,長年Macintoshを使い続け,1000件以上の登録があります.2011年から運用開始されたiCloudでアドレス帳がMacintosh, iPhone, iPod touch, iPadで同期されるようになってからは,何の迷いもなくiCloudのアドレス帳を使い続けて,メンテもよくしています.

iPhoneやMacintoshのアドレス帳でかつてはOpenLDAPのサーバーに接続できていたのですが,もうずいぶん前のiOSのupgrade時につながらなくなり,以降iOSやmacOSのupgradeのあとなどときどき試していますが利用できていません.

今一番優秀なLDAPのクライアントはMozilla Thunderbirdです.ThunderbirdとmacOSのアドレス帳を立ち上げて比較ができます.

そんなわけでLDAPに登録したアドレスと,今年年賀状を出すか出さないかを記したCSVファイルを照らし合わせて,年賀状を出す人のアドレス帳を吐き出し(CSV),それをLibreOfficeのDataベースに読み込ませて,宛名の差し込み印刷をしています.

いつの頃からかLDAPのslapdを

/path/to/slapd/slapd -h "ldaps:///"

という形で起動して,TLSのポートのみ聞くようにしていました.今回困ったのは,PerlのNet::LDAPがslapdに接続できないことです.TLSのみでもThunderbirdのLDAPクライアントはちゃんと接続できます.

この問題について,ベタな方法としては一旦slapdをkillallなどで止めてから,

/path/to/slapd/slapd -h "ldaps:/// ldap:///"

で起動し直せば解決します.

その後,得意なネットの斜め読み調査で,Net::LDAPの代わりにNet::LDAPSを使えば良いと言うことが解り,よりスマートな形で解決しました.

ただ,現在LDAPサーバーのメンテ方法で困っていて,phpLDAPadminというWeb UIがありますが,一旦開発者が見捨て,PHPのupdateで何年も前に使えなくなりました.その後GitHubでボランティアたちがPHPの仕様変更にだけ対応しているようです.また,上記のLDAPSのみのクライアントにはつなげられないようで,平文接続できるようにしてもエラーが出てデータベースのメンテ作業ができません.

いずれにしても元々のアドレスデータベースの一本化はかなり早い段階であきらめてしまったので,その後の経緯は妥当だったのかどうか考えると微妙ではありますがトラブルなくできているのでよしとします. 一番重要な,汎用アドレス帳とLDAPの年賀状用アドレスリストの齟齬を生じさせないということについては,修正は必ず両方のデータベースに対して行う,メモ欄に修正日を記す,でなんとかなっています.

LDAPという訳の分からないデータベース・デーモンを動かして利用することがむしろ目的化しています.

大半は現役時代の仕事がらみの登録で,現在はそのほとんどが無効と思われますが,消す作業はあえてしていません.

Re: httpsのnssがslabを大量に使うからswapが発生する件が依然解らないまま解決した模様

2022年11月2日の「httpsのnssがslabを大量に使うからswapが発生する件が依然解らないまま解決した模様」ですが,その後も安定して,メモリーが空いています.

Slackware ARM for Raspberry Pi 4 Model B 15.0 (32bit)の話です.

11月2日よりあとに,WordPressにRedisクライアントをインストールしたりして,httpdのそれぞれのスレッドの占有するメモリーはかなり増えましたが,起動してから一週間経っても “avail Mem” は2GB以上空いていますし, “free mem” も1GB以上空いていて, “Swap” はほとんど使われていませんから余裕です.

ということでKernelのバグだったと言うことで間違いないと思います

「httpsのnssがslabを大量に使う」当サイト内の関連記事

仕様だったのかも知れませんが😓 あくまで “当社調べ” です.

新しいタブレットをどうするか

WACOMはドライバーのupdate/upgradeで古いモデルをサポートしなくなります.これまでもそのことで何度か買い換えを余儀なくされました.

タブレットの利用は絵を描くのではなくマウス代わりなので,小さい方が手を動かす範囲が狭く都合が良いので,現行モデルで買うとすると, “Intuos small ベーシック USBモデル” ないし, “One by WACOM small” です.これらを買うのはやぶさかではないのですが,最新のWACOMタブレットを買うと,X.orgやLinux Kernelのドライバーがサポートしていない,という問題に遭遇します.

X.orgとLinux Kernelがサポートしている少し古いタブレットを探し出して買えばKVMスイッチに繋がっている全てのPC/WSで使えますが,古い分早くWACOMに見切られます.

少し考えます.

httpsのnssがslabでswapの問題が解決したところでWordPressの対策をしたらメモリー使用量が増えた

そんなわけで,Kernelのupdateをしたらnssがslabでメモリーを大量消費する問題が解決しました.

それとは別に,WordPressのパフォーマンス改善のために,Page cacheRedisを導入したところ,httpdの使用メモリーがかなり増えました.

従前は1スレッドあたり6%弱くらいでしたが,現在は1スレッドあたり8%弱です.1スレッドあたり2ポイントくらい増えてますから,

4096 x 0.02 x 4 ≅ 330MB

ということで,コンベンショナルメモリーを330MB位余計に食うようになりました.

それでも,そのhttpsのnssがslabでメモリーを消費する問題が解決したので,swapを使う事は今のところないです.

「httpsのnssがslabを大量に使う」当サイト内の関連記事