1度サーバーをガチャンと切り替えてみます (2) 準備に手間取ってます

4月8日頃にガチャンと切り替える予定

2022年4月6日(水)の午前中に,ガチャンと切り替えようかと思いましたが,肝心なBIND (named)の設定がまだと気がつき,着手しましたが,難航しています.

もともとBINDのことはあんまり理解してないまま使ってきてました1動けばいいのだ™.解ってないのにいろいろ過去の複雑な事情が設定に盛りこまれています.

BINDもセキュリティーの事情からバージョンが上がる度にそういう曖昧さが許されなくなってきているようで,Slackware 14.xで動いていた設定をそのままコピーしても,エラーが出て動いてくれませんでした.

ということで,1, 2日かけて,BINDの設定をチューニングしてから,いよいよガチャンと切り替えます.

追記: とりあえずBIND動きました

BIND (named)の設定のエラーは,メッセージを見ながら,理解していないなりに😓 直して,エラーが出なくなりました.

しかし,システムを起動しても,namedもntpdも動いていない.前のシステムの起動手順などを見てみても,特に変わらないのですが.

なんとなく勘で,システムの時間が設定されていないとnamedが動かず,namedが動いていないから,ntpdがサーバーのipアドレスを取得できなくて動かないのではないか,と当たりを付けました.

一番の問題は,Raspberry Pi Model Bシリーズが,バッテリーにより駆動されるhardware clockを持っていないことです.起動時に何もしないと,1970年1月1日から始まってしまいます.

もともとの起動順は,rc.Mから呼ばれたrc.inet2によって,rc.bindがスタートして,そのあと,rc.Mの少し後でrc.ntpdが起動されます.これでしばらくするとclockが同期しますが,少し時間がかかるので,ntpd起動の前に,

/usr/sbin/ntpdate 0.pool.ntp.org

を実行するように,rc.ntpdに追加してあります.

SlackwareARM 14.xではこれで問題ありませんでした.つまり,システムの時間が1970年1月1日でもnamedは起動して,その後に起動するntpd2ntpdate実行時も.のサーバー名を解決してくれます.しかし,SlackwareARM 15.0付属のBIND 9.16.xでは,システムの時間がめちゃくちゃだと,namedが居座らずに異常終了してしまいます.

そして,ntpdが時間サーバーのipアドレスを解決できずにやはり異常終了してしまう.

「ニワトリが先かたまごが先か」問題です.

仕方がないので,0.pool.ntp.orgでたまたま表示される1つのipアドレス(仮にnn.nn.nn.nn)を使い,rc.Mの中のrc.inet2起動の前に,

/usr/sbin/ntpdate  nn.nn.nn.nn

を書いて,解決しました.poolなのに,固定的に使うのは趣旨に反すると思いますが,起動時の一回だけだから勘弁しもらいましょう.

LDAPの移転で難儀する

LDAPは,データベースの内部ファイルをバイナリーコピーしても新しいマシンでうまく動かなかった記憶があるので,旧いマシンから正攻法でテキストダンプ(ldif型式)して,新しいマシン側でimportします.

長いこと,phpLDAPadminを便利に利用さてもらってきました.このldifエクスポートは完璧に使えます.しかし,phpLDAPadiminも,もう7年くらい前でメンテが終わってしまっているようで,バージョンアップの度にAPIに少なからぬ変更のあるphpのサポートされている一番古いバージョンでも全くもって動かなくなってしまいました.

そこで,ネット検索すると,Apache Directory Studioなるソフトがあり,macOS版もあると言うことで,喜んでダウンロードしました.

しかし,Big Sur(macOS 11.x)以降では動かないようです😓

ldap browserという大昔のソフトは動くのですが,ldifのエクスポートでエンコーディングされた長い行は改行が入ってしまい,インポートできないのです.

さて困ったと思ったら,仮想マシンのWindows 10があるのでした.Apache Directory StudioのWindows版を試してみます.

WindowsもNG

なんだかよく解らないけれど,Windows版も長ったらしいエラーを出して動きませんでした.

ldapsearch

ふつうに,ldapsearchを使うことにします.長いコメント行が改行される不具合はありますが,-Lオプションでコメントの出力を止められることが解りました.

1度サーバーをガチャンと切り替えてみます

LAN内で,新しいサーバーの準備をしています.デフォルトのmail transfer agent (MTA)がsendmailからPostfixに変わったとか,httpdはたぶん動くだろうとか解りましたが,実際に外からアクセスできるようにしてみないと,動くかどうか解りません.

2022年4月6日(水)の午前中に切り替えを予定しています.あんまりひどかったら元に戻します.

以後しばらくは当サイトの運用が不安定になるかもしれませんので,ご承知ください.

安定しましたら,またお知らせします.

iCloud マイフォトストリームが同期しない (6) 15.4.1で改善なし

iPhoneで撮影した写真(HEIF型式=拡張子がHEICのもの)が,iCloudのマイフォトストリーム(無料)にjpegに変換されてuploadしてくれない件ですが,今日リリースされたupdate iOS 15.4.1でも改善されてないようです(当社調べ).

15.4.2まで,iPhoneのカメラ設定を,フォーマット > 互換性優先 にしとくしかなさそうです.15.4.2で直る保証もないんですが😓

iCloud マイフォトストリームが同期しない (5) iOSのバグでしょう

これまで,仕様も知らずにマイフォトストリームを使ってきましたが,あらためて見てみると,

とあります.この仕様から推測するに,iPhoneでHEIF型式で撮影・保存した写真をiPhone (iOS)がマイフォトストリームにuploadする際,自分でJPEGに変換してからuploadするのでしょう.

マイフォトストリームを介して伝播した(シンクロされた)写真は,上記資料で説明されている通りJPEG型式です.

タイミング的にiOS 15.4にupgradeした直後からシンクロしない状態が続いているので,iOS 15.4にマイフォトストリームと同期する際にHEIFをJPEGに変換しようとしないというバグがあるのでしょう.

あるいは,無料のマイフォトストリームを使うユーザーに対する嫌がらせかな😓1上記資料にあるように,有料の “iCloud写真” にすれば,HEIFのままシンクロされます.

iOS 15.4.1がリリースされるまでJPEGで撮影します.

関連記事