2021/08/21(土)OpenLDAP 2.5系の導入はまだ駄目っぽい・・・
2021/08/21 02:46
2.5.4 からリリースされ、現在の最新バージョンは 2.5.7 です。
FreeBSD もサポートプラットフォームになっています。
最近は開発コアメンバーがどうもアンチＢＳＤっぽいんですが、元々はＢＳＤ系で開発が進められていた記憶があります。
※2023/02/26 追記 当方では、2022年９月中旬に OpenLDAP 2.6.3 にて、OpenLDAP 2.4系からの移行が正常に機能するようになったことを確認しました。 運用を考慮すると、OpenLDAP 2.5 系を採用した方がよいかもしれませんが、動作確認を OpenLDAP 2.6系にて、作業の合間でやっとのことで確認したため、そのまま OpenLDAP 2.6系を使っています。 恐らく、OpenLDAP 2.5系は、同時期リリースの 2.5.13 ～ なら使えそうですが、当方では OpenLDAP 2.5系の検証は、そのような時間が取れず、行うことができません。当方で 2.5 系にすべく、アップデートを試みたですが、結局『まだ使い物にならない』が結論です。
データを登録しても、
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 fd=13 ACCEPT from IP=[::1]:37442 (IP=[::]:389)のように、mdb_opinfo_get: err Bad file descriptor(9) という内部処理エラーが発生し、情報が取得できません。
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 BIND dn="cn=admin,dc=isp" method=128
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 BIND dn="cn=admin,dc=isp" mech=SIMPLE bind_ssf=0 ssf=0
Aug 20 04:30:34 www0 slapd[21837]: mdb_opinfo_get: err Bad file descriptor(9)
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 RESULT tag=97 err=0 qtime=0.000012 etime=0.000111 text=
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=1 SRCH base="dc=isp" scope=2 deref=0 filter="(objectClass=*)"
Aug 20 04:30:34 www0 slapd[21837]: mdb_opinfo_get: err Bad file descriptor(9)
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=1 SEARCH RESULT tag=101 err=80 qtime=0.000006 etime=0.000046 nentries=0 text=internal error
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=2 UNBIND
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 fd=13 closed
OpenLDAP のエラーも 80(Internal Error) が返り、どうにも出来ません。
何故か、付属のテストプログラムは普通に機能するみたいなんですけどね。。。
少しデバッグをしてみましたが、どうも結果を出力する際に、何故か Read 処理をしようとしているようで、これが「Bad file descriptor」の原因を作っているみたいです。根深そうなので、バグ潰しに時間を割けない当方は、当面は、従来通り OpenLDAP 2.4系を使い続けることにしています。
その他にも、テストプログラムに不具合があります。うち２つは、BSD系 sed と、GNU 系 sed の仕様が異なるからのような感が。。。
先ず、構築の際の configure オプションは、
./configure --enable-crypt=yes --enable-rlookups --enable-ldap=yes --enable-mdb=yes --enable-perl=yes --with-fetch --with-tls --enable-overlays=yes --without-cyrus-sasl --disable-dynlist --with-picこれで、幾つかの Warning が出るが、コンパイルは正常終了します。但し、FreeBSD の BSD系Make コマンドだと、
Entering subdirectory liblberのようなエラーとなってしまうため、代わりに gmake (GNU系make) を使用します。
make[2]: "/usr/local/src/openldap-2.5.7/libraries/liblber/Makefile" line 302: Need an operator
make[2]: "/usr/local/src/openldap-2.5.7/libraries/liblber/Makefile" line 304: Need an operator
make[2]: Fatal errors encountered -- cannot continue
make[2]: stopped in /usr/local/src/openldap-2.5.7/libraries/liblber
*** Error code 1
OpenLDAP 2.4系のように、コンパイルに先立ち、FreeBSD 10系以降で生じる configure の問題(FreeBSD 1.x系と誤認する問題)回避のためのスクリプト修正は不要です。
gmake dependのあと、
gmake
gmake testで、テストするのですが、 test022-ppolicy・test079-proxy-timeout・test082-remoteauth は、FreeBSD ではそのままでは動作しません。
<<<<< Starting test022-ppolicy for mdb...これは、tests/scripts/test022-ppolicy を以下のように修正します：
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
sed: 1: "s/.*seconds_before_unlo ...": RE error: trailing backslash (\)
Waiting seconds for lockout to reset...
usage: sleep seconds
ldapsearch failed (49)!
<<<<< test022-ppolicy failed for mdb after 8 seconds
(exit 49)
gmake[2]: *** [Makefile:301: mdb-yes] エラー 49
gmake[2]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake[1]: *** [Makefile:287: test] エラー 2
gmake[1]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake: *** [Makefile:299: test] エラー 2
106 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \ 107 - -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*seconds_before_unlock=\(\d*\)/\1/p'` 107 + -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*seconds_before_unlock=\([0-9]*\)/\1/p'` 122 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \ 123 - -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'` 123 + -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'` 492 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \ 493 - -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'` 493 + -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'` 737 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \ 738 - -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'` 738 + -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'`
<<<<< Starting test082-remoteauth for mdb...tests/scripts/test082-remoteauth を以下のように修正します：
running defines.sh
Running slapadd to build slapd database... DB tweaks...
Starting slapd on TCP/IP port 9011 for configuration...
Loading test remoteauth configuration...
Preparing second server on ldap://localhost:9012/ and ldaps://127.0.0.1:9013/... loading data... tweaking DB contents... starting up...
Waiting 7 seconds for slapd to start...
Saving generated config before server restart...
Checking bind handling... 1 2 3 ok
Stopping slapd on TCP/IP port 9011...
Starting slapd on TCP/IP port 9011...
Saving generated config after server restart...
Checking bind handling... 1 2 3 ok
Stopping slapd on TCP/IP port 9011...
Testing slapd.conf support...
sed: 1: "s,database\s*monitor, ...": RE error: trailing backslash (\)
Starting slapd on TCP/IP port 9011...
Saving generated config from a slapd.conf sourced server...
ldapsearch failed (32)!
<<<<< test082-remoteauth failed for mdb after 13 seconds
(exit 32)
gmake[2]: *** [Makefile:301: mdb-yes] エラー 32
gmake[2]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake[1]: *** [Makefile:287: test] エラー 2
gmake[1]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake: *** [Makefile:299: test] エラー 2
312 echo "Testing slapd.conf support..." 313 - sed -e "s,database\\s*monitor,\\ 313 + sed -e "s,database[ \f\n\r\t]*monitor,\\あと、test079-proxy-timeout も何か変なのですが、下記の修正でテストは成功します。
tests/scripts/test079-proxy-timeout を以下のように修正します：
119 RC=$? 120 - if test $RC != 0 ; then 120 + if test $RC = 0 ; then 121 echo "ldapsearch failed for base: dc=idle-timeout,$BASEDN ($RC)!"test079-proxy-timeoutの修正は、ちょっと自信がありません・・・
英語でのコミュニケーションが出来ない故、誰か代わりに報告してくれないか、と他力本願モードです。。 orz
2021/06/07(月)ＣＡや証明書に問題無いのに「不正な証明書」となる・・・
2021/06/07 07:04
厄介なのは、普通の受信操作ではこのメッセージは出ず、電子メールアカウントを指定して受信を試みることや、電子メールの送信操作で初めて表示されるというところ。
こんな感じです：
Thuderbird 単体でもこのメッセージが表示され、対処方法は、
https://www.atmarkit.co.jp/ait/articles/1702/09/news032.html 〔ThunderbirdでプライベートCA発行の証明書がエラーになる場合の対策方法（Windows）＠ＩＴ〕 あたりで示されてはいます。
しかしながら、これをやっても現象が解消しないことがあります。
何故なら、アンチウィルスソフトウェアでTLS/SSL な通信を監視しており、「大手企業以外のＣＡをプライベートＣＡ」と定義し、それ自体を「不正」と見做すことが多々あるため。
当方の環境も ThunderBird ＋ Avast! な環境で問題の解消は出来ませんでした。
このモーダルウィンドウは、ThunderBird が表示しているのですが、大手企業ではないところで生成したＣＡは一律に「不正」という暴挙な扱いを Avast! でしているため、元凶は Avast! なのです。
一応、回避方法は示されていますが、（https://support.avast.com/ja-jp/article/Troubleshoot-invalid-email-certificate/ ）
これをやっても当方の環境では、どうにも上手く解消せず、結局
のようにして「セキュリティ例外を承認」という策で回避しました。
ＣＡや証明書自体には全く問題が無いからです。
2021/04/18(日)なんと！ FreeBSD 13 から、ソースコード管理が subversion から git へ・・・
2021/04/18 05:47
今回から、aarch64(arm64) と称されるアーキテクチャが amd64 と同等の Tier 1 に、
最初のTier 1 サポートになった i386 が Tier 2 に変更となっています。時代の変化です。
aarch64 は Raspberry pi に代表される小型のボードが主な対応機器になります。
Tier 1 は、フルサポートが保証されるプラットフォームで amd64 と aarch64 が該当、
Tier 2 は、実使用出来るものの、新機能追加やセキュリティサポートが積極的に行われないバージョンで、最も多くのプラットフォームがこれです。
FreeBSD の Tier ランクは４つあり、Tier 3 が実験的アーキテクチャ(FreeBSD 13 では該当なし)、
Tier 4 は「サポート終了宣言」のアーキテクチャで、現在は、pc98(NEC系の古いパソコン) と sparc64(20年近く前にかなり普及していた、サンマイクロシステムズのワークステーション) が主に該当します。
前置きが長くなりましたが、今回から変更になったものがもう一つ。ソースコードの管理です。。
リリースが近くなってから話には聞いていたものの、『実に厄介だ』というのが第一印象。
いつものように、メンテナンスのためにソースコードからアップデートかけようと、
ソースコード取得を下記のように試みるが・・・
このように「そんなものは無い」と拒絶されます。
今まではＯＳバージョンアップデート時には、/usr/src と /usr/obj 配下をまっさらにしてから、
# svnlite checkout https://svn.freebsd.org/base/releng/xx.x/ /usr/srcパッチアップデート時には、
# svnlite updateみたいな形で、と直感的なものがあったが、今回からはそれぞれ、
# cd /usr # git clone -b releng/xx.x ssh://anongit@git.freebsd.org/src.git # cd /usr/src
# cd /usr # git pull # cd /usr/srcとする必要がある。
-b に続く文字列は FreeBSD のリリースブランチ（タグ名とも称す）を示し、
FreeBSD 12.2 だと releng/12.2 FreeBSD 13.0 だと releng/13.0 FreeBSD 13-stable だと stable/13 のようになります。
慣れの問題なのでしょうが、git の第一印象は悪い（当方と同世代なエンジニアは概ね同じ印象を持っている人が案外多い）のもあり、抵抗感がややあります。
git ツールはデフォルトではインストールされていないので、
portsツリーを最新版にしてから、
# cd /usr/ports/devel/git # make install # rehashみたいなコマンドを実行して、git をインストールすることが必要なのです。
ただ、ソースコード取得は subversion よりは高速なようです。
また、今回から、make buildworld , make buildkernel にかかった所要時間が秒数で表示されるようになったようです。
コンパイルにかかる所要時間は、FreeBSD 12 より若干高速になったようです。
2021/04/18(日)FreeBSD におけるディスク追加・変更・パーティション管理
2021/04/18 04:35
今どきの FreeBSD では、ＨＤＤなどのストレージデバイス管理に GEOM と呼ばれるフレームワークを採用しています。
昔は、専用のユーティリティツール(FLabel や FDisk ユーティリティ)を使うのが一般的だった記憶があるが、
現在は、GEOM フレームワークの下で gpart というコマンドひとつでも出来るようになっており、
あとからＨＤＤを交換したり、増設やパーティション割り当て変更したい場合は gpart コマンドの方がやりやすい。
後日の参考とするため、手順や注意点などを記述していきます：
注意点) メンテナンス作業対象のＨＤＤやパーティションは mount 状態であってはいけない。
単純なＨＤＤ増設なら何も考えることは無いですが、
パーティション変更や交換であれば、mount を外すか、ＯＳ起動時に mount されないようにする必要があります。
例えば、ada0 と ada1 の２つのＨＤＤがあって、ada1 を交換またはパーティション変更するのであれば、
# vi /etc/fstab
として、該当ファイルの内容を、
# Device Mountpoint FStype Options Dump Pass# /dev/ada0p2 / ufs rw 1 1 /dev/ada0p3 none swap sw 0 0 /dev/ada0p4 /usr ufs rw 2 2 /dev/ada0p5 /tmp ufs rw 2 2 # /dev/ada1p1 /home ufs rw 2 2 # /dev/ada1p2 /db ufs rw 2 2 # /dev/ada1p3 /ftp ufs rw 2 2 # /dev/ada1p4 /var ufs rw 2 2のように、該当デバイスに関係する部分全てを、コメントアウト編集しておく必要があります。
もちろん、必要に応じて事前にバックアップしておくことは言うまでもありません。
このあとは、シャットダウンして、機器の電源を落としましょう。
手順１）ＨＤＤ増設・取り外しの作業を行う
該当ＨＤＤを除去するだけなら、ＨＤＤを取り外し後、再度電源ＯＮ・起動すれば作業完了です。
ＨＤＤ増設の実作業は、このタイミングで行います。
マザーボードとＨＤＤの結線状態によっては、増設後の起動時にデバイス名の認識順序が変わる場合があるため、要注意です。
通常はマザーボードに振られているコネクタ番号(SATA1,SATA2,SATA3.... といったもの)順にデバイス名が割り当てされていきます。
推奨 ）インストールＣＤ・ＤＶＤにて shell を起動するのが確実
前述したように、メンテナンス対象のＨＤＤが mount 状態になるのを避けるために、
最も確実な手法は、インストールＣＤ・ＤＶＤでＯＳを起動させ、shell が稼動する状態にすることです。
この状態では、全てのＨＤＤは mount 状態になりません。
しかしながら、この状態にするのは実際には結構面倒なので、ＯＳ起動時にシングルユーザモードで起動するのも手法のひとつです。
但し、この場合は、起動ディスクのルートパーティション '/' が mount された状態になります。
上記で言うと、
/dev/ada0p2 / ufs rw 1 1のみが mount された状態になります。
また、あまりお勧めはしませんが、初めに /etc/fstab で該当ＨＤＤのパーティション全てをコメントアウト編集したした状態で再起動した場合、通常の起動はマルチユーザーモードですが、この通常起動モードでも作業は出来ます。
マルチユーザモードの場合、必ず root ユーザにて作業を行います。
手順２）パーティションの状態を確認し、余計なパーティションが有れば削除
パーティションの確認は、
# gpart show ada1
=> 34 1953525101 ada1 GPT (932G)
34 901775360 1 freebsd-ufs (430G)
901775394 251658240 2 freebsd-ufs (120G)
1153433634 251658240 3 freebsd-ufs (120G)
1405091874 548433260 4 freebsd-ufs (262G)
1953525134 1 - free - (512B)
のような形で確認できます。'show' はサブコマンド、'ada1' ＯＳがＨＤＤに割り当てたデバイス名です。上記パーティションの削除は、
# gpart delete -i 1 ada1 ada1p1 deleted # gpart delete -i 2 ada1 ada1p2 deleted # gpart delete -i 3 ada1 ada1p3 deleted # gpart delete -i 4 ada1 ada1p4 deleted # gpart destroy ada1 ada1 destroyedまたは、
# gpart destroy -F ada1 ada1 destroyed一旦、パーティション情報をまっさらにすると、この後の作業確実です。
尚、初めて使用する新品ＨＤＤの場合は
# gpart show ada1
=> 34 1953525101 ada1 none (932G)
34 1953525101 - free - (932G)
みたいな表示になるため、この作業は必要ないはずです。手順３）パーティションを設定
現在は殆どの場合、GPT 形式のパーティションテーブルを採用します。
かなり古いマザーボードだと、GPT 形式に対応していないことがあるため、この場合は MBR 形式を使用します。
先ずは、 GPT 形式パーティションを使用する宣言・指定です。
# gpart create -s GPT ada1 ada1 created次に、具体的にパーティションを指定します。
パーティションの追加は下記のようにします：
# gpart add -t freebsd-ufs -s 12G ada1 # gpart add -t freebsd-ufs ada1-t でパーティションタイプ、-s でパーティションサイズを指定し、最後のキーワードは該当ＨＤＤデバイス名です。
-s のサイズ指定を省略すると、自動的に残部の割り当て可能最大領域を確保したパーティションサイズになります。
上記の場合、パーティションを確認すると、下記のような感じになるはずです：
# gpart show ada1
=> 40 1953525088 ada1 GPT (932G)
40 25165824 1 freebsd-ufs (12G)
25165864 1928359264 2 freebsd-ufs (920G)
手順４）パーティションの初期化(フォーマット)
パーティションを設定した後は、必ずファイルシステムの初期化を行います。
Windows などでいうところの「論理フォーマット」に該当する作業になります。
# newfs -U /dev/ada1p1 # newfs -U /dev/ada1p2各コマンドを実行すると、数字の羅列が表示されて初期化が行われます。
この数字は、ＨＤＤが一部破損した時などのバックアップに使用する管理上の番号ですが、ＵＮＩＸ系のファイルシステム詳部に関わる話題なので、ここでは説明を割愛します。
ＯＳ起動ＨＤＤとするには、もう少し面倒な手順を踏みますが、通常はインストーラがナビゲートするため、これも説明を割愛します。
手順５）自動マウントの設定
最初の「注意点）」の項目で、 /etc/fstab の該当デバイスをコメントアウトしましたが、
今度はＯＳ起動時に自動的に今回作成したパーティションをマウントさせるために、再び書き換えを行います。
今回の例において、/dev/ada1p1 と /dev/ada1p2 に自動マウントさせるには、以下のようにします：
# vi /etc/fstab
# Device Mountpoint FStype Options Dump Pass# /dev/ada0p2 / ufs rw 1 1 /dev/ada0p3 none swap sw 0 0 /dev/ada0p4 /usr ufs rw 2 2 /dev/ada0p5 /tmp ufs rw 2 2 /dev/ada1p1 /home ufs rw 2 2 /dev/ada1p2 /backup ufs rw 2 2ルートディレクトリ '/' 配下にマウントポイントとなるディレクトリが存在しない場合、エラーになりますので、ルートディレクトリにマウントポイントとなるディレクトリを作ります：
# cd / # mkdir backupこれで、通常の再起動を行えば、作業完了です。
起動後、freebsd-ufs パーティションを追加した場合に限りますが、
% df /dev/ada0p2 73122268 664920 66607568 1% / devfs 1 1 0 100% /dev /dev/ada0p4 335160852 23687292 284660692 8% /usr /dev/ada0p5 48491312 36960 44575048 0% /tmp /dev/ada1p1 12180252 32836 11172996 0% /home /dev/ada1p2 933907000 32836 859161604 0% /backupのように、増設または変更したパーティションが表示されていれば作業完了。
2021/04/12(月)落下させた東芝製ＨＤＤのテスト結果公表
2021/04/12 06:00
一応、再度試験してテスト結果のスクリーンショット撮影を。
下記 ada0 は落下させた東芝製ＨＤＤ、 ada1 は２年半ほど使って遊休状態だった東芝製ＨＤＤ。
型番同じですが、 ada1 の方が製造時期は２ヵ月ほど遅い。
※ 画像をクリックすると、大きめの画像が表示されます。
全領域の読み出しテストを行っています。
FreeBSD 12.2(Release版) のインストールＣＤ上のＯＳを起動しています。
of の指定が /dev/null なので、実際には書き込みは一切行いませんが、
読み込みが出来なければ、書き込みも出来ない故、ＨＤＤの損傷検出に使えるのです。
ちなみに、読み込み出来ない場合は、TIMEOUT や FAILURE などのメッセージが必ず表示されます。
２つのＨＤＤ共に「エラーがありませんでした」という結果でした。
2021/04/10(土)日本メーカのＨＤＤは丈夫らしい・・・
2021/04/10 23:31
東芝は現在では日本で唯一と思われるが。。ただ、このＨＤＤの生産自体は中国共産党な国。
＃最近は、違うらしい
以前は、日立が HGST という名称の傘下企業を抱えていたが、これは今は Western Digital の傘下。
2015年10月に購入し、２年くらい使っていたが、
容量の大きなものに換装するために交換作業をしていたところ、誤って床に強打する形で落下させてしまい、
「壊してしまった・・・」と半ばあきらめていたのですが、認識はするので暫く使う用途もなく放置状態でした。
ところが、どうしてもハードディスクが必要な状況が発生し、２～３回全領域の読み取りテストを行ったところ、
全く異常が無いことが判り、ちょっと驚いているところ。
最初、Western Digital の製造ラインを引き継いだころは、東芝製は何かとトラブルが多かったが、
数年でこの品質に改善なのでこれもちょっと驚き。
今年は、今のところ５月から６月と、８月に多忙の山が来そうです。
2020/11/06(金)rsync 3.2.3 のインストール
2020/11/06 06:33
rsync は、別名「ソフトウェア RAID」とも言われ、任意のディレクトリやファイル単位で複写を行うことが出来るソフトウェアで、ご存じの方も多いでしょう。
ネットワークを介して、物理的に別の機器にバックアップする、といったことが可能です。
今年６月になって、3.2.x にバージョンアップし、現在の最新バージョンは、3.2.3 になっています。
3.2 系になってから、下記のライブラリが必要になった模様。
FreeBSD の場合は、予め Ports で導入してしまいます：
liblz4 (Ports カテゴリ：archivers) zstd (Ports カテゴリ：archivers) xxhash (Ports カテゴリ：devel)その後、
# tar xvzf rsync-3.2.3.tar.gz # cd rsync-3.2.3 # setenv CPPFLAGS '-I/usr/local/include -I/usr/include' # setenv LDFLAGS '-L/usr/local/lib -L/usr/lib' # setenv LD_LIBRARY_PATH '/usr/local/lib /usr/lib' # ./configure --disable-md2man # gmake # gmake install（※注 csh を使用)
とすると、インストールできます。使用方法は、3.1 系と変わりません。
〔2024/06/17 追記〕
rsync の最新版は、3.3系 になっていますが、今のところ、インストールに関しては 3.2系と同様の手順で上手くいくようです。
2020/07/08(水)Whois情報の入力不備？？
2020/07/08 14:52
こちらからすると、「正しい情報」を提示して登録しているのであるが、この有様。
問い合わせしてから２日目の返信とか、対応は今一つだが、全く返信が無いよりはマシですね。
返事内容も「Whois 情報に入力不備がございます」の一点張りで、このままでは埒があかない。
正直なところ営業妨害されている状態で胸糞悪いが、何が問題なのか判らないので「こうして欲しい」が出てこない限りどうにも出来ませんね。
とはいえ、予測は出来ます。悪い奴かもしれませんが、おそらく
実務に合わない変更を強要されることになるので、ここで問題提起です。
ここでは、存在しない住所を敢えて例示しますが、問題なのはおそらく「北５０条西２１丁目」といった住所表記です。
札幌市では市街地の一部が「条丁目」表記になっていて、南北方向は「南〇条」「北〇条」といった表記、東西方向は「東〇丁目」「西〇丁目」といった表記です。
これを一般的な英語表記では、N50W21 のように表記するのが通例。
kita50jo nishi21chome でも通じるとは思うが、表記が長い・却って読みにくい、何よりも「間違いの原因を作る」ので実務では使われないことが多く、当方も見たことが無いですね。
また、電話番号も 札幌の市外局番は011 だが、(英語表記)における通常は先頭のゼロを省き、
日本の国番号 81 を加え、+81.11-987-6543 のような表記が一般的。
たぶん、実務に合う・合わないに関係なく、「体裁だけは整えろ」と強制的に来るだろうと思うところ。
こんなことでゴタゴダするほど暇では無いですが、釈然としないのでね、、、
2020/07/12 追記：
予測したとおり、住所表記がお気に入りでなかっただけの模様でした。
理由も述べずに「不備があります！！！」では、話になりませんね。
これでは「何故こうするのか」が判らない。改善も出来ない。
いつから日本の大手企業は、こうも馬鹿になってしまったのか。
2019/08/16(金)少なくとも Passenger Ver 5 以降は、FreeBSD11.3 ではコンパイル不能
2019/08/16 21:57
redmime を一部のプロジェクトで運用していますが、これを Apache で動作させるために、Passenger という連携モジュールが必要。
今回はこれにハマりました。現状の最新版 Passenger-6.0.2 でも同様です。
先ず、 redmine の動作に必要な ruby ライブラリをインストール後、最後にこのモジュールのインストール作業を行います。
通常、redmine をインストールしたディレクトリにて、
# gem install passenger # passenger-install-apache2-moduleとやるんですが、これがどうも上手く行かない。調べると、上記手順を実施する前に、
# setenv APXS2 '/usr/local/apache2/bin/apxs' # setenv PATH '/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/pgsql/bin:/usr/local/apache2/bin'といった、環境変数の設定が必要な模様。
ソースコードから Apache をインストールした場合、passenger インストーラがApache を確認できないらしい。
これで、
# gem install passengerは、上手く行きます。しかし、
# passenger-install-apache2-moduleは、途中でコンパイルエラーになります。こんな感じ：
/usr/include/c++/v1/string_view:771:37: note: 'Passenger::ApiAccountUtils::string_view' declared here調べると、どうも C++17 からでないと、サポートしていない構文を使っている模様。
typedef basic_string_viewstring_view;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
1 warning and 20 errors generated.
rake aborted!
Command failed with status (1): [c++ -o buildout/support-binaries/WatchdogMain.o -Isrc/agent -Isrc/cxx_supportlib -Isrc/cxx_supportlib/vendor-copy -Isrc/cxx_supportlib/vendor-modified -Isrc/cxx_supportlib/vendor-modified/libev -Wno-ambiguous-member-template -Isrc/cxx_supportlib/vendor-copy/libuv/include -Isrc/cxx_supportlib/vendor-copy/websocketpp -I/usr/local/include -DHAS_CURL_EASY_RESET -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -g -fno-limit-debug-info -Wno-unused-local-typedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -c src/agent/Watchdog/WatchdogMain.cpp]
Tasks: TOP => apache2 => buildout/support-binaries/PassengerAgent => buildout/support-binaries/WatchdogMain.o
C++17 をコンパイラに強制させて解決するには、こうします：
# setenv EXTRA_CXXFLAGS '-std=c++17'要するに、上記の環境変数にて、追加のコンパイラオプションを設定し、再度
# passenger-install-apache2-moduleと、するのです。ですが、これで解決するはずが、別の場所でエラーが出ました。こんな感じ：
pedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -std=c++17 -c src/cxx_supportlib/IOTools/IOUtils.cppん～、、調べると、この random_shuffle という関数は C++17では「廃止」されたらしい。
src/cxx_supportlib/IOTools/IOUtils.cpp:288:3: error: use of undeclared identifier 'random_shuffle'
random_shuffle(result.begin(), result.end());
^
1 error generated.
rake aborted!
Command failed with status (1): [c++ -o buildout/apache2/module_libpassenger_common/IOTools/IOUtils.o -Isrc/cxx_supportlib -Isrc/cxx_supportlib/vendor-copy -Isrc/cxx_supportlib/vendor-modified -Isrc/cxx_supportlib/vendor-modified/libev -Wno-ambiguous-member-template -Isrc/cxx_supportlib/vendor-copy/libuv/include -O -fPIC -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apache2/include -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -g -fno-limit-debug-info -Wno-unused-local-typedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -std=c++17 -c src/cxx_supportlib/IOTools/IOUtils.cpp]
Tasks: TOP => apache2 => buildout/apache2/mod_passenger.so => buildout/apache2/module_libpassenger_common/IOTools/IOUtils.o
なのでエラーになるのです。これには困った・・・というか、バグの類でしょう。。
結局、３箇所修正することで、コンパイルできます。
/usr/local/lib/ruby/gems/2.5/gems/passenger-6.0.2/src/cxx_supportlib/IOTools/IOUtils.cpp
37 #include <algorithm>
38 #include <string>
39 #include <vector>
+ 40 #include <random>
41 #include <sys/socket.h>
42 #include <sys/types.h>
287 freeaddrinfo(res);
288 if (shuffle) {
289 // random_shuffle(result.begin(), result.end());
+ 290 std::shuffle(result.begin(), result.end(),std::mt19937());
291 }
292 return result;
293 }
/usr/local/lib/ruby/gems/2.5/gems/passenger-6.0.2/src/cxx_supportlib/vendor-copy/websocketpp/websocketpp/common/memory.hpp65 #ifdef _WEBSOCKETPP_CPP11_MEMORY_ 66 using std::shared_ptr; 67 using std::weak_ptr; 68 // using std::auto_ptr; 69 using std::enable_shared_from_this; 70 using std::static_pointer_cast; 71 using std::make_shared; 72 using std::unique_ptr;ソースコード修正後、
# setenv EXTRA_CXXFLAGS '-std=c++17' # passenger-install-apache2-moduleとすることで、使用できるモジュールが出来上がるようです。
2019/07/12(金)FreeBSD11/FreeBSD12 にて無償利用可能なサーバ証明書 Let's Encrypt を使う
2019/07/12 17:39
Let's Encrypt は、有効期間90日（自動延長可能）な無償サーバ証明書です。
FreeBSD におけるやり方について、余り情報が書かれていないので、ここで提示しておきます。
これを使うには、先ずは使用するサーバにて、管理ツールのようなものをインストールします：
FreeBSD Ports においては、 securiry/py-certbot をインストールします。
＃Python を使用したスクリプトなので、依存関係で Python 本体と、動作に必要な python モジュールが
＃インストールされます。
インストールが終わったら、Apache や nginx を一旦停止して、
のようにコマンドを入力します。# certbot certonly --standalone -d 《FQDN名》-m 《通知電子メールアドレス》
# certbot certonly --standalone --non-interactive --agree-tos --keep --expand --email 《通知電子メールアドレス》 --no-eff-email --domains 《FQDN名》
＃このスクリプトが一時的に http サーバになるため、ポート番号が競合するからのようです。
《FQDN名》は、証明書発行申請するときのコモン名。例えば https://server.example.com/ のサーバ証明書が欲しければ、 ここに server.example.com と記述します。
《通知電子メールアドレス》は、何かある場合に連絡が入る電子メールアドレスを指定します。
実在する電子メールアドレスを指定します。
証明書の期限が間近になった場合などに連絡が入るようです。
コマンドの実行が始まると、先ず、下記のメッセージが表示されます：
Saving debug log to /var/log/letsencrypt/letsencrypt.log使用条件・契約条件を許諾するか否かの問いです。Agree のA を入力します。
Plugins selected: Authenticator standalone, Installer None
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -次に、各種の連絡を電子メールで送るけれど、本当に良いか？ という趣旨の問いです。
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
これも Yes の Y を入力します。
Obtaining a new certificate上記で、'Congratulation' のメッセージが含まれていたら、作成は成功です。
Performing the following challenges:
http-01 challenge for server.example.com
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/usr/local/etc/letsencrypt/live/server.example.com/fullchain.pem
Your key file has been saved at:
/usr/local/etc/letsencrypt/live/server.example.com/privkey.pem
Your cert will expire on 2019-10-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /usr/local/etc/letsencrypt. You should
make a secure backup of this folder now. This configuration
directory will also contain certificates and private keys obtained
by Certbot so making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
正直なところ、少し判り難いです。
上記例では有効期限は 2019/10/10 だと言っています。
失敗しているような場合は、再度、
上記のコマンドを入力してみましょう。# certbot certonly --standalone -d 《FQDN名》-m 《通知電子メールアドレス》
# certbot certonly --standalone --non-interactive --agree-tos --keep --expand --email 《通知電子メールアドレス》 --no-eff-email --domains 《FQDN名》
但し、FQDN名がDNSで正引き出来ないと、上手く行かないみたいです。
Apache には以下の要領で設定します (要所を抜粋)：
SSLCACertificateFile /usr/local/etc/letsencrypt/live/server.example.com/chain.pem'server.example.com' の部分を、使用するFQDN に合わせて変更します。
SSLCertificateFile /usr/local/etc/letsencrypt/live/server.example.com/cert.pem
SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/server.example.com/privkey.pem
最後に自動更新させるには、以下を、crontab に追加します：
0 6,21 * * * /usr/local/bin/certbot renew --agree-tos --webroot -w＃表示の便宜上３行に分けているが、実際に適用の際は半角スペースで区切って１行にすること。
/home/webroot/server.example.com/public --renew-by-default
&& /usr/local/etc/rc.d/apache2 restart
-w のあとのフルパスは、該当 FQDN におけるドキュメントルート絶対パスを指定します。
１日２回の更新チェックが推奨されているようです。しかしながら、実用上、月に１回でもよいと思います。
※ certbot certonly コマンドが例示だと上手く動作しなくなっていたので、動作確認出来た内容に修正。〔2021/09/13〕