2021/06/07(月)CAや証明書に問題無いのに「不正な証明書」となる・・・

2021/06/07 7:04 サーバ運営・管理
どうも、Thuderbird を使っていると、この現象に悩まされる模様……
厄介なのは、普通の受信操作ではこのメッセージは出ず、電子メールアカウントを指定して受信を試みることや、電子メールの送信操作で初めて表示されるというところ。
こんな感じです:
20210607_1.png


Thuderbird 単体でもこのメッセージが表示され、対処方法は、
https://www.atmarkit.co.jp/ait/articles/1702/09/news032.html 〔ThunderbirdでプライベートCA発行の証明書がエラーになる場合の対策方法(Windows)@IT〕 あたりで示されてはいます。

しかしながら、これをやっても現象が解消しないことがあります。
何故なら、アンチウィルスソフトウェアでTLS/SSL な通信を監視しており、「大手企業以外のCAをプライベートCA」と定義し、それ自体を「不正」と見做すことが多々あるため。
当方の環境も ThunderBird + Avast! な環境で問題の解消は出来ませんでした。

このモーダルウィンドウは、ThunderBird が表示しているのですが、大手企業ではないところで生成したCAは一律に「不正」という暴挙な扱いを Avast! でしているため、元凶は Avast! なのです。
一応、回避方法は示されていますが、(https://support.avast.com/ja-jp/article/Troubleshoot-invalid-email-certificate/

これをやっても当方の環境では、どうにも上手く解消せず、結局
20210607_2.png

のようにして「セキュリティ例外を承認」という策で回避しました。
CAや証明書自体には全く問題が無いからです。

2021/04/18(日)なんと! FreeBSD 13 から、ソースコード管理が subversion から git へ・・・

2021/04/18 5:47 サーバ運営・管理
2021/04/13 付けで、FreeBSD 13 が公開されました。
今回から、aarch64(arm64) と称されるアーキテクチャが amd64 と同等の Tier 1 に、
最初のTier 1 サポートになった i386 が Tier 2 に変更となっています。時代の変化です。
aarch64 は Raspberry pi に代表される小型のボードが主な対応機器になります。

Tier 1 は、フルサポートが保証されるプラットフォームで amd64 と aarch64 が該当、
Tier 2 は、実使用出来るものの、新機能追加やセキュリティサポートが積極的に行われないバージョンで、最も多くのプラットフォームがこれです。

FreeBSD の Tier ランクは4つあり、Tier 3 が実験的アーキテクチャ(FreeBSD 13 では該当なし)、
Tier 4 は「サポート終了宣言」のアーキテクチャで、現在は、pc98(NEC系の古いパソコン) と sparc64(20年近く前にかなり普及していた、サンマイクロシステムズのワークステーション) が主に該当します。

前置きが長くなりましたが、今回から変更になったものがもう一つ。ソースコードの管理です。。
リリースが近くなってから話には聞いていたものの、『実に厄介だ』というのが第一印象。

いつものように、メンテナンスのためにソースコードからアップデートかけようと、
ソースコード取得を下記のように試みるが・・・
20210418.png

このように「そんなものは無い」と拒絶されます。

今まではOSバージョンアップデート時には、/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 4:35 サーバ運営・管理
どちらかというと、自分メモ的記事。
今どきの FreeBSD では、HDDなどのストレージデバイス管理に GEOM と呼ばれるフレームワークを採用しています。

昔は、専用のユーティリティツール(FLabel や FDisk ユーティリティ)を使うのが一般的だった記憶があるが、
現在は、GEOM フレームワークの下で gpart というコマンドひとつでも出来るようになっており、
あとからHDDを交換したり、増設やパーティション割り当て変更したい場合は gpart コマンドの方がやりやすい。

後日の参考とするため、手順や注意点などを記述していきます:

注意点) メンテナンス作業対象のHDDやパーティションは mount 状態であってはいけない。
単純なHDD増設なら何も考えることは無いですが、
パーティション変更や交換であれば、mount を外すか、OS起動時に mount されないようにする必要があります。
例えば、ada0 と ada1 の2つのHDDがあって、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
のように、該当デバイスに関係する部分全てを、コメントアウト編集しておく必要があります。
もちろん、必要に応じて事前にバックアップしておくことは言うまでもありません。
このあとは、シャットダウンして、機器の電源を落としましょう。

手順1)HDD増設・取り外しの作業を行う
該当HDDを除去するだけなら、HDDを取り外し後、再度電源ON・起動すれば作業完了です。
HDD増設の実作業は、このタイミングで行います。
マザーボードとHDDの結線状態によっては、増設後の起動時にデバイス名の認識順序が変わる場合があるため、要注意です。
通常はマザーボードに振られているコネクタ番号(SATA1,SATA2,SATA3.... といったもの)順にデバイス名が割り当てされていきます。

推奨 )インストールCD・DVDにて shell を起動するのが確実
前述したように、メンテナンス対象のHDDが mount 状態になるのを避けるために、
最も確実な手法は、インストールCD・DVDでOSを起動させ、shell が稼動する状態にすることです。
この状態では、全てのHDDは mount 状態になりません。
しかしながら、この状態にするのは実際には結構面倒なので、OS起動時にシングルユーザモードで起動するのも手法のひとつです。
但し、この場合は、起動ディスクのルートパーティション '/' が mount された状態になります。
上記で言うと、
/dev/ada0p2     /               ufs     rw      1       1
のみが mount された状態になります。
また、あまりお勧めはしませんが、初めに /etc/fstab で該当HDDのパーティション全てをコメントアウト編集したした状態で再起動した場合、通常の起動はマルチユーザーモードですが、この通常起動モードでも作業は出来ます。
マルチユーザモードの場合、必ず root ユーザにて作業を行います。

手順2)パーティションの状態を確認し、余計なパーティションが有れば削除
パーティションの確認は、
# 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' OSがHDDに割り当てたデバイス名です。
上記パーティションの削除は、
# 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
一旦、パーティション情報をまっさらにすると、この後の作業確実です。
尚、初めて使用する新品HDDの場合は
# gpart show ada1

=>        34  1953525101  ada1  none  (932G)
          34  1953525101        - free -  (932G)
みたいな表示になるため、この作業は必要ないはずです。

手順3)パーティションを設定
現在は殆どの場合、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 でパーティションサイズを指定し、最後のキーワードは該当HDDデバイス名です。
-s のサイズ指定を省略すると、自動的に残部の割り当て可能最大領域を確保したパーティションサイズになります。
上記の場合、パーティションを確認すると、下記のような感じになるはずです:
# gpart show ada1
=>        40  1953525088  ada1  GPT  (932G)
          40    25165824     1  freebsd-ufs  (12G)
    25165864  1928359264     2  freebsd-ufs  (920G)

手順4)パーティションの初期化(フォーマット)
パーティションを設定した後は、必ずファイルシステムの初期化を行います。
Windows などでいうところの「論理フォーマット」に該当する作業になります。
# newfs -U /dev/ada1p1
# newfs -U /dev/ada1p2
各コマンドを実行すると、数字の羅列が表示されて初期化が行われます。
この数字は、HDDが一部破損した時などのバックアップに使用する管理上の番号ですが、UNIX系のファイルシステム詳部に関わる話題なので、ここでは説明を割愛します。

OS起動HDDとするには、もう少し面倒な手順を踏みますが、通常はインストーラがナビゲートするため、これも説明を割愛します。

手順5)自動マウントの設定
最初の「注意点)」の項目で、 /etc/fstab の該当デバイスをコメントアウトしましたが、
今度はOS起動時に自動的に今回作成したパーティションをマウントさせるために、再び書き換えを行います。

今回の例において、/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(月)落下させた東芝製HDDのテスト結果公表

どうも「本当か??」みたいな反応が多いので、
一応、再度試験してテスト結果のスクリーンショット撮影を。

下記 ada0 は落下させた東芝製HDD、 ada1 は2年半ほど使って遊休状態だった東芝製HDD。
型番同じですが、 ada1 の方が製造時期は2ヵ月ほど遅い。
20210412.jpg

※ 画像をクリックすると、大きめの画像が表示されます。

全領域の読み出しテストを行っています。
FreeBSD 12.2(Release版) のインストールCD上のOSを起動しています。

of の指定が /dev/null なので、実際には書き込みは一切行いませんが、
読み込みが出来なければ、書き込みも出来ない故、HDDの損傷検出に使えるのです。
ちなみに、読み込み出来ない場合は、TIMEOUT や FAILURE などのメッセージが必ず表示されます。

2つのHDD共に「エラーがありませんでした」という結果でした。

2021/04/10(土)日本メーカのHDDは丈夫らしい・・・

今や、ハードディスクを製造しているメーカは減っていて、
東芝は現在では日本で唯一と思われるが。。ただ、このHDDの生産自体は中国共産党な国。
#最近は、違うらしい

以前は、日立が HGST という名称の傘下企業を抱えていたが、これは今は Western Digital の傘下。
20210410_1.jpg


2015年10月に購入し、2年くらい使っていたが、
容量の大きなものに換装するために交換作業をしていたところ、誤って床に強打する形で落下させてしまい、
「壊してしまった・・・」と半ばあきらめていたのですが、認識はするので暫く使う用途もなく放置状態でした。

ところが、どうしてもハードディスクが必要な状況が発生し、2~3回全領域の読み取りテストを行ったところ、
全く異常が無いことが判り、ちょっと驚いているところ。

最初、Western Digital の製造ラインを引き継いだころは、東芝製は何かとトラブルが多かったが、
数年でこの品質に改善なのでこれもちょっと驚き。

今年は、今のところ5月から6月と、8月に多忙の山が来そうです。

2020/11/06(金)rsync 3.2.3 のインストール

2020/11/06 6:33 サーバ運営・管理
いつもの自分メモ。

rsync は、別名「ソフトウェア RAID」とも言われ、任意のディレクトリやファイル単位で複写を行うことが出来るソフトウェアで、ご存じの方も多いでしょう。
ネットワークを介して、物理的に別の機器にバックアップする、といったことが可能です。

今年6月になって、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 系と変わりません。

2020/10/16(金)話題の soumu.online レジストリ情報

2020/10/16 6:44 はんかくさい
報道で広く知られた、定額給付金詐欺サイト soumu.online のドメイン登録情報です。
Domain Name: SOUMU.ONLINE
Registry Domain ID: D204207873-CNIC
Registrar WHOIS Server: whois.namesilo.com
Registrar URL: https://www.namesilo.com
Updated Date: 2020-10-15T11:17:35.0Z
Creation Date: 2020-10-14T17:37:39.0Z
Registry Expiry Date: 2021-10-14T23:59:59.0Z
Registrar: NameSilo, LLC
Registrar IANA ID: 1479
Domain Status: serverHold https://icann.org/epp#serverHold
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientHold https://icann.org/epp#clientHold
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: addPeriod https://icann.org/epp#addPeriod
serverHold:ドメイン使用不可
serverTransferProhibited:レジストラ移管許可禁止
clientHold:DNS情報は無効
clientTransferProhibited:レジストラ移管申請禁止
addPeriod:ドメイン登録取り消し猶予が与えられている

要するに、現在はドメインそのものが使用を認められておらず、ドメイン削除を求めている状態。
日本政府当局からの通報で行った措置でしょう。
取り敢えず、金融取引情報をすっぱ抜かれる被害は抑え込みましたが、別のトップドメイン使って同じことする可能性は高いですね。

2020/08/22(土)javascript の fetch と XMLHttpRequest

今回は、これにちょっと嵌ったので自分メモ。
fetch も XMLHttpRequest も Javascript 内でWebサーバと通信処理が出来る便利な機能で
ちょっと前は「Ajax」とか言ってもてはやされたものですが、今はほぼ死語でしょうかね。
それでも今はWebサイトでちょっとしたことをするには欠かせなくなってきているもの。

今回は、オンラインでの画像編集機能をサイト内にて実現するために、
最初は fetch による以下のコードを書きました(一部を公開用に変更部分あり):
async function gosub_canvasimg(serial,imgblob) {
  var responce = await (await fetch('/editor.cgi', {
                          method : 'POST',
                          cache  : 'no-cache',
                          headers : {'Content-Type' : 'application/x-www-form-urlencoded' } ,
                          body   : 'imgblob=' + imgblob ;
                         })).text() ;
  if (responce != 'valid') {
    alert(serial + "つめの画像ファイル保存に失敗しました。" );
  }
}
ところが、これだと、
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
というエラーが出て、fetch 自体が実行されないのです。*1
これは、拙作のシステムにて「画像があるはずだが、編集画面で表示されない」という現象を作り出す直接原因になっていました。

同期処理でないと、編集時に不具合が更に出るので、こうしています。
『同期処理なんぞ殆ど使われません』と大声で叫ぶサイトなんかも散見されますが、
それはよほど精通している方か、同期処理の必要な案件に出会ったことが無い方なのでしょう。
少なくともハードウェアの制御がシステム全体として絡んで来ると、同期処理はどうやっても必須。

結局、fetch がエラーになる原因は判らず仕舞いで、fetch のところを同じ処理になるように、
async function gosub_canvasimg(serial,imgblob) {
  var imgxhr  = new XMLHttpRequest() ;
  var msgbody = 'imgblob=' + imgblob ;

  imgxhr.open('POST', '/editor.cgi', false) ;
  imgxhr.send(msgbody) ;
  var responce = imgxhr.response ;

  if (responce != 'valid') {
    alert(serial + "つめの画像ファイル保存に失敗しました。" );
  }
}
みたいな感じにすると、エラーは出なくなった模様。
これで不具合は出なくなったと思うが様子見です。
fetch の実装バグなのか、「同期方式」という使い方が悪いのか調べても全く判らないのです。

やっぱり XMLHttpRequest() のほうが断然判りやすい。
fetch は Promise という挙動の概念を理解しなければならず、これが当方にはあまり直感的ではなく判りずらさの極みです。これを使いこなせないのがこの顛末の一因でしょう。

何せ、類似の事例が殆ど表に出てきていない案件なので、エンドユーザに動作検証してもらうという暴挙を敢行するしかないのです。

*1 : 当方は英語が苦手なので、日本語表示がある程度出来る Firefox でデバッグをしています. chrome のデバッガは、英語だらけで正直発狂しそうになります...

OK キャンセル 確認 その他