はんかくさい日報

2021/11/26(金)clamAV は 0.104 から構築方法が変わっている模様・・・

2021/11/26 6:51 サーバ運営・管理

いつものように、ソースコードからの構築を行うべく、

# ./configure --enable-experimental --with-iconv --enable-milter

とか、やって構築しようとしたらエラーを吐くので、ちょっと見て見たら単純に configure スクリプトが無い。
更に調べたら、cmake を使う構築方法に変わったとのこと。

今まで、機会が無くやったことが無いので面食らいました。。。
clamAV 0.104 以降で cmake で構築する場合、先ず、

# cd clamav-0.104.1
# mkdir build
# cd build
# cmake .. -D ENABLE_EXPERIMENTAL=NO -D ENABLE_JSON_SHAREDOFF

とか実行して、まさに configure と同じ役割で構築環境を作り出すのですが、依存するモジュールやライブラリが結構あって、存在しないと、 cmake がエラーを吐いて終了します。最初は、これに面食らいます。

不足があるかもしれませんが、事前に下記の依存モジュールやライブラリが必須のようです：

　・pcre-8.45　　　（Ports から カテゴリ：devel）
　・pcre2-10.39　　（Ports から カテゴリ：devel）
　・autoconf-2.69_3（Ports から カテゴリ：devel）
　・cmake-3.21.4_1 （Ports から カテゴリ：devel）
　・libltdl-2.4.6　（Ports から カテゴリ：devel）
　・libtool-2.4.6_1（Ports から カテゴリ：devel）
　・libxml2-2.9.12 （Ports から カテゴリ：textproc）
　・db5-5.3.28_7 　（Ports から カテゴリ：databases）　　※ これは BerkeleyDB 5.3.28 です
　・curl-7.80.0　　（Ports から カテゴリ：ftp）
　・json-c-0.15_1　（Ports から カテゴリ：devel）
　・jsoncpp-1.9.5　（Ports から カテゴリ：devel）
　・check-0.15.2　 （Ports から カテゴリ：devel）
　・ncurses-6.3　　（Ports から カテゴリ：devel）

上手くいったら、

# cmake --build .
# cmake --build . --target install

とやると、ソースコードからインストールできるようです。
（ドットを省略しないことに注意を）

コメント（0件）

2021/08/28(土)FreeBSD13 からのソースコードによるＯＳ更新は、gitup が最も手軽

2021/08/28 5:00 サーバ運営・管理

先日、FreeBSD のソースコード管理が subversion から git に変更になった旨を『厄介だ』と紹介したのですが・・・
その厄介さを払拭するメンテナンスツールが既に用意されていたのでした。

この手の情報が数えるほどしかなく、日本語による情報を当方が見つけたのはここだけです → KNCN weblog　/usr/src を gitup で取得する
＃見落としの可能性もあるのでご容赦を・・

これは、ＯＳの標準コマンドではないので、出来る限り最新のports から、

# cd /usr/ports/net/gitup
# make install
# make clean
# rehash

とかやって、インストールします。インストール後、 /usr/local/etc/gitup.conf を以下のように適宜編集します：
（一部抜粋）

# $FreeBSD$
#
# Default configuration options for gitup.conf.
{
        "defaults" : {
                "host"           : "git.freebsd.org",
                "port"           : 443,
#               "proxy_host"     : "",
#               "proxy_port"     : 0,
#               "proxy_username" : "",
#               "proxy_password" : "",
#               "source_address" : "",
                "low_memory"     : false,
                "display_depth"  : 0,
                "verbosity"      : 1,
                "work_directory" : "/var/db/gitup",
        },

        "ports" : {
                "repository_path"  : "/ports.git",
                "branch"           : "main",
                "target_directory" : "/usr/ports",
                "ignores"          : [
                        "distfiles",
                        "packages",
                ],
        },

        "release" : {
                "repository_path"  : "/src.git",
                "branch"           : "releng/13.0",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },

        "stable" : {
                "repository_path"  : "/src.git",
                "branch"           : "stable/13",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },

見ての通り、JSON 形式な設定ファイル。
初めてだと JSON 形式に面食らうんですが、割と直感的に変更できます。
gitup.conf を編集後、

# gitup release

とやれば、今まで同様の /usr/src 配下へのソースコード取得、
今後は、ports ツリーもgit 管理になるらしいので、そうなった際は、

# gitup ports

で、従来のように /usr/ports 配下への取得が出来るようです。
ただ、ports ツリーの取得は、前処理・後処理があるので、portsnap のほうが使い勝手は良いです。
〔参考〕portsnap が更新しない場合の対処法

尚、新規取得時も更新時も同じコマンドラインで出来ます。

コメント（0件）

2021/08/21(土)OpenLDAP 2.5系の導入はまだ駄目っぽい・・・

2021/08/21 2:46 サーバ運営・管理

１０年以上の永らくの期間、OpenLDAP は 2.4 の時代でしたが、今年(2021)年の４月末に OpenLDAP 2.5 系がリリースされています。
2.5.4 からリリースされ、現在の最新バージョンは 2.5.7 です。
FreeBSD もサポートプラットフォームになっています。
最近は開発コアメンバーがどうもアンチＢＳＤっぽいんですが、元々はＢＳＤ系で開発が進められていた記憶があります。

当方で 2.5 系にすべく、アップデートを試みたですが、結局『まだ使い物にならない』が結論です。
データを登録しても、

Aug 20 04:30:34 www0 slapd[21837]: conn=1005 fd=13 ACCEPT from IP=[::1]:37442 (IP=[::]:389)
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

のように、mdb_opinfo_get: err Bad file descriptor(9)　という内部処理エラーが発生し、情報が取得できません。
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
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

のようなエラーとなってしまうため、代わりに gmake (GNU系make) を使用します。

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...
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

これは、tests/scripts/test022-ppolicy を以下のように修正します：

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...
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

tests/scripts/test082-remoteauth を以下のように修正します：

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

コメント（0件）

2021/07/26(月)気候が変だ・・

2021/07/26 16:28 地元(札幌)・北海道の話題

最低気温が 25℃ ～ 26℃ とか、北海道ではあり得なかったんだが、、
夏が暑い分、冬は寒くなるかもしれないです。はい。

※ 上記は、拙作サイト　https://www.basekernel.co.jp/pc/weather/foreweek/016000.html で最新発表をいつでも閲覧可能です。

コメント（0件）

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

2021/06/07 7:04 サーバ運営・管理

どうも、Thuderbird を使っていると、この現象に悩まされる模様……
厄介なのは、普通の受信操作ではこのメッセージは出ず、電子メールアカウントを指定して受信を試みることや、電子メールの送信操作で初めて表示されるというところ。
こんな感じです：

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/ ）

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

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

コメント（0件）

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 ランクは４つあり、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 より若干高速になったようです。

コメント（0件）

2021/04/18(日)FreeBSD におけるディスク追加・変更・パーティション管理

2021/04/18 4: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

のように、増設または変更したパーティションが表示されていれば作業完了。

コメント（0件）

2021/04/12(月)落下させた東芝製ＨＤＤのテスト結果公表

2021/04/12 6:00 修理や再生などサーバ運営・管理

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

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

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

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

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

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

コメント（0件）

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

2021/04/10 23:31 修理や再生などサーバ運営・管理

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

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

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

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

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

今年は、今のところ５月から６月と、８月に多忙の山が来そうです。

コメント（0件）

2020/11/23(月)何だこれ。。

2020/11/23 15:28 はんかくさい

発信元も晒します。アマゾンではありません。

※画像クリックで大きな画面が出てきます。

コメント（0件）

		2021/12
日	月	火	水	木	金	土
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31