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 系と変わりません。

〔2024/06/17 追記〕
rsync の最新版は、3.3系 になっていますが、今のところ、インストールに関しては 3.2系と同様の手順で上手くいくようです。

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 のデバッガは、英語だらけで正直発狂しそうになります...

2020/08/20(木)今度はアマゾンのアカウント停止??

2020/08/20 14:22 はんかくさい
今回はふざけ過ぎなので、全て晒します。

先月末頃から、
「(Amazonで)お客様のアカウントのパスワードを無効にいたしました。」
「残念ながら、Аmazon のアカウントを更新できませんでした。」
とか、不安を煽るようなアホメールが散発的に来るのだが、ついに8月19日になって、
20200820_1.png

※画像クリックで大きな画像が表示されます。

というのが来て、IPアドレスが提示されてきたので、見てみたら・・・
Yahoo Taiwan のIPアドレスの模様。台湾に大阪府があるのか。知らんかった(笑)
に始まり、このメール発信元の「info@jncuiyantang.com」は実在するドメインなようなので、調査したら、
登録者は武漢に近い地方都市の模様。マルウェアに侵されているか、意図的に流しているかは不明ですが。
いずれにせよ、こういうのは止めれ、、、

更に同じ日に・・・
20200820_2.png

※画像クリックで大きな画像が表示されます。

これです。目的不明ですね。単なる嫌がらせなのか、不安を煽りたい馬鹿なのか。
賢明な方々であれば難なく無視できるのですが、インターネット初心者のような方々だと、
最悪パニックに陥る。

アマゾンや、当方に恨みでもあるのかもしれんが、こういうのは何の解決にもならないですね。

2020/07/08(水)Whois情報の入力不備??

2020/07/08 14:52 サーバ運営・管理
今般、委託を受けて取得したドメインだが・・・
20200708.png


こちらからすると、「正しい情報」を提示して登録しているのであるが、この有様。
問い合わせしてから2日目の返信とか、対応は今一つだが、全く返信が無いよりはマシですね。

返事内容も「Whois 情報に入力不備がございます」の一点張りで、このままでは埒があかない。
正直なところ営業妨害されている状態で胸糞悪いが、何が問題なのか判らないので「こうして欲しい」が出てこない限りどうにも出来ませんね。

とはいえ、予測は出来ます。悪い奴かもしれませんが、おそらく
実務に合わない変更を強要されることになるので、ここで問題提起です。

ここでは、存在しない住所を敢えて例示しますが、問題なのはおそらく「北50条西21丁目」といった住所表記です。

札幌市では市街地の一部が「条丁目」表記になっていて、南北方向は「南〇条」「北〇条」といった表記、東西方向は「東〇丁目」「西〇丁目」といった表記です。
これを一般的な英語表記では、N50W21 のように表記するのが通例。
kita50jo nishi21chome でも通じるとは思うが、表記が長い・却って読みにくい、何よりも「間違いの原因を作る」ので実務では使われないことが多く、当方も見たことが無いですね。

また、電話番号も 札幌の市外局番は011 だが、(英語表記)における通常は先頭のゼロを省き、
日本の国番号 81 を加え、+81.11-987-6543 のような表記が一般的。

たぶん、実務に合う・合わないに関係なく、「体裁だけは整えろ」と強制的に来るだろうと思うところ。
こんなことでゴタゴダするほど暇では無いですが、釈然としないのでね、、、

2020/07/12 追記:
予測したとおり、住所表記がお気に入りでなかっただけの模様でした。
理由も述べずに「不備があります!!!」では、話になりませんね。
これでは「何故こうするのか」が判らない。改善も出来ない。
いつから日本の大手企業は、こうも馬鹿になってしまったのか。

2020/07/06(月)アホすぎるSPAMメール

2020/07/06 5:52 はんかくさい
こんなのも久々・・
そもそも楽天なんかにアカウント持っていないし、
「異常行為」とやらが意味不明だし、「画面の指示」とやらを示すものが一切無い。
更に「ヘルプページ」とやらの案内はどこに? 状態で・・

ちなみに発信元は、楽天とは全く関係のない滅茶苦茶なメールアドレスです。
20200706.png