結局、FreeBSD11.1Stableで使用していたZFSの写真など重要部分が読めないままに、FreeBSD12.1Rを新規インストールする羽目に、、、、。 (消失したデータはCD等にあるので、コツコツと構築して、見つからなくなったものは諦めるーという泣く泣くの判断。 みんな自分が悪いので、已むをえません。)
今回はUSBスティックにインストーラーを用意して、ZFSファイルに(凝りもせず)インストール。
インストールする前に、古いZFSファイルから設定ファイルなど、救出できるファイルは全て1TBのHDDにコピーしておいて、今まで使っていたZFSファイルに新規にFreeBSD12.1Rを入れ、後にHDDをマウントして必要な設定ファイルをコピーしていった。
当然、初期のインストールなどは全く問題なく終了。 pkgを使ってgnome, apache24, postgreSQL, php, wildfly14等をインストールしてゆき、都度必要なセットアップファイルをコピーしてきて、動作確認。 samba24, gnome, apache24, wildfly14, postgreSQLとinstallそのものは無事終了しましたが;
全体としてココを参考にしながら
ー>しかし、ごみのような写真(気安く携帯で撮ったような)も全て保存されているので、これの整理は将来的に何か方法を考えないと、ただ大容量のスペースに保存するだけでは拙い。
ついでにこの記事に刺激されvm-bhyveもここを参考に入れてみたが、問題なく動きそう。
あれ?再起動するとzfsのルート以外がマウントされていない? でググったらココにありました。 rc.confを書き換えた時にzfs_enable="YES"を消してしまっていたみたい。
ZFS絡みのバージョンアップの失敗は2-3度やって、その都度ファイルを失っていますので、二度と同じ間違いをしないように、もう少しzfsのsnapshotやbackup機能の利用を自動化してゆくことを検討中。
>zfstoolsを使う方法があったので、実験中。 cronで起動しても何故かうまくsnapshotが取れていませんでしたが、ココを参考にして設定してみたらうまく行きました。 必要のない所を個別に以下の様にauto-snapshot=falseを設定した後に
# zfs set com.sun:auto-snapshot=false zroot/tmp
# zfs set com.sun:auto-snapshot=false zroot/usr/ports
# zfs set com.sun:auto-snapshot=false zroot/usr/src
# zfs set com.sun:auto-snapshot=false zroot/var/crash
# zfs set com.sun:auto-snapshot=false zroot/var/tmp
zrootに対して com.sun:auto-snapshot=trueしてあげないとダメみたい。
# zfs set com.sun:auto-snapshot=true zroot
確かにsnapshotが出来ていました。
# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
zroot@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/R@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/R/vm@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 240K -
zroot/R/vm/windows@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 123K -
zroot/ROOT/default@zfs-auto-snap_hourly-2020-03-16-18h00 938K - 6.77G -
zroot/usr/home@zfs-auto-snap_hourly-2020-03-16-18h00 432K - 444G -
zroot/var/audit@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/var/log@zfs-auto-snap_hourly-2020-03-16-18h00 95.9K - 501K -
zroot/var/mail@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 165K -
#
> wildfly16(wildfly14から新しい物に更新)を立ち上げてみたら、立ち上がらない! 「おいおい、何だろう?」ってなわけで、/var/log/wildfly16/logを眺めてみると、「動かしているマシンのアドレスが分からない?」って出て来ている。 「ありゃま、named立ち上げないとダメなんか」ということで、local domain用にnamed立ち上げて、解決。
長ったらしいログだなー、しかし。
namedの設定も久しぶりで、ちょっと手間取りました。 何故かCNAMEの所をちゃんと読んでくれないので、暫定的にCNAME使うのはヤメ。
Wildfly16とpostgreSQLを繋ぐのにもちょっと躓いたのでココを参考にした。 (ここで使っているwildflyは9.0.2とか11.0.0なのでその所為か、mouduleの置き場所が、/modules/直下に/org/postgresql/main/を作って、、、となっています。 cliを使ってインストールすると、/module/org/postgresql/main/{module.xml, posgtresql-42.2.11.jar}が出来ていました。 (どこかで、/module/system/layers/baseの下に置くような記事を見たような気がしましたがこれは違いますね、多分。jboss/wildflyは結構階層が深くてわかり難い)
今回はUSBスティックにインストーラーを用意して、ZFSファイルに(凝りもせず)インストール。
インストールする前に、古いZFSファイルから設定ファイルなど、救出できるファイルは全て1TBのHDDにコピーしておいて、今まで使っていたZFSファイルに新規にFreeBSD12.1Rを入れ、後にHDDをマウントして必要な設定ファイルをコピーしていった。
当然、初期のインストールなどは全く問題なく終了。 pkgを使ってgnome, apache24, postgreSQL, php, wildfly14等をインストールしてゆき、都度必要なセットアップファイルをコピーしてきて、動作確認。 samba24, gnome, apache24, wildfly14, postgreSQLとinstallそのものは無事終了しましたが;
全体としてココを参考にしながら
- gnome-terminalは LANGの設定が拙くて立ち上がらず、ココを参考に。
- postgreSQLも暫く使っていなかったので、コマンドを忘れてしまい苦労しましたが、ココを見ながら、csvファイルで残っていた気温、湿度のデータなどを復元させ。
- 気象データの取り込みのphpプログラムもバックアップデータから引っ張り出してきてインストール。(センサーデータを送ってくるESP32側を再起動しないと、定期的に送信するようにはなりませんでした。何故?)
- 気象データをグラフ化してWEBに表示している JpGraphに食わせるデータを作っているView(PostgreSQLの)をphpのコードを見ながら再構築中ー>道半ば。
- Sambaは、前の設定ファイルを取り込んで、すんなり動作。Win10のファイルサーバ状態。(以前は苦労した記憶があるので、助かった!)
ー>しかし、ごみのような写真(気安く携帯で撮ったような)も全て保存されているので、これの整理は将来的に何か方法を考えないと、ただ大容量のスペースに保存するだけでは拙い。
ついでにこの記事に刺激されvm-bhyveもここを参考に入れてみたが、問題なく動きそう。
あれ?再起動するとzfsのルート以外がマウントされていない? でググったらココにありました。 rc.confを書き換えた時にzfs_enable="YES"を消してしまっていたみたい。
ZFS絡みのバージョンアップの失敗は2-3度やって、その都度ファイルを失っていますので、二度と同じ間違いをしないように、もう少しzfsのsnapshotやbackup機能の利用を自動化してゆくことを検討中。
>zfstoolsを使う方法があったので、実験中。 cronで起動しても何故かうまくsnapshotが取れていませんでしたが、ココを参考にして設定してみたらうまく行きました。 必要のない所を個別に以下の様にauto-snapshot=falseを設定した後に
# zfs set com.sun:auto-snapshot=false zroot/tmp
# zfs set com.sun:auto-snapshot=false zroot/usr/ports
# zfs set com.sun:auto-snapshot=false zroot/usr/src
# zfs set com.sun:auto-snapshot=false zroot/var/crash
# zfs set com.sun:auto-snapshot=false zroot/var/tmp
zrootに対して com.sun:auto-snapshot=trueしてあげないとダメみたい。
# zfs set com.sun:auto-snapshot=true zroot
確かにsnapshotが出来ていました。
# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
zroot@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/R@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/R/vm@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 240K -
zroot/R/vm/windows@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 123K -
zroot/ROOT/default@zfs-auto-snap_hourly-2020-03-16-18h00 938K - 6.77G -
zroot/usr/home@zfs-auto-snap_hourly-2020-03-16-18h00 432K - 444G -
zroot/var/audit@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 117K -
zroot/var/log@zfs-auto-snap_hourly-2020-03-16-18h00 95.9K - 501K -
zroot/var/mail@zfs-auto-snap_hourly-2020-03-16-18h00 0 - 165K -
#
> wildfly16(wildfly14から新しい物に更新)を立ち上げてみたら、立ち上がらない! 「おいおい、何だろう?」ってなわけで、/var/log/wildfly16/logを眺めてみると、「動かしているマシンのアドレスが分からない?」って出て来ている。 「ありゃま、named立ち上げないとダメなんか」ということで、local domain用にnamed立ち上げて、解決。
長ったらしいログだなー、しかし。
namedの設定も久しぶりで、ちょっと手間取りました。 何故かCNAMEの所をちゃんと読んでくれないので、暫定的にCNAME使うのはヤメ。
Wildfly16とpostgreSQLを繋ぐのにもちょっと躓いたのでココを参考にした。 (ここで使っているwildflyは9.0.2とか11.0.0なのでその所為か、mouduleの置き場所が、/modules/直下に/org/postgresql/main/を作って、、、となっています。 cliを使ってインストールすると、/module/org/postgresql/main/{module.xml, posgtresql-42.2.11.jar}が出来ていました。 (どこかで、/module/system/layers/baseの下に置くような記事を見たような気がしましたがこれは違いますね、多分。jboss/wildflyは結構階層が深くてわかり難い)
0 件のコメント:
コメントを投稿