変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

ReadyNAS-212

[ReeadyNAS212]言語

初期設定は・・・

何もしていなかったので

設定してみた。

# localedef -f UTF-8 -i ja_JP ja_JP
# 以下を追記
LANG=ja_JP.UTF-8
LANGUAGE=
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

ここまでしなくても

# 以下を追記
LANG=ja_JP.UTF-8

で十分そう。



[ReadyNAS212]タイムゾーン

初期設定は、PDT 米国太平洋標準時(夏時間) UTC-0700 だったのでJSTに変えてみた。

# timedatectl list-timezones
# timedatectl set-timezone Asia/Tokyo

これだけだと、ログインしなおすと元に戻ると思いきや

# ls -la /etc/localtime
lrwxrwxrwx 1 root root 32  5月 25 22:59 /etc/localtime -> ../usr/share/zoneinfo/Asia/Tokyo

の様にシンボリックリンクを書き換えているので、再起動しても安心?



【ReadyNAS212】PostgreSQLインスト~exportに泣く~

安易にNASにPostgreSQLをインストしてみたら

# apt install postgresql
# psql --version
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
psql (PostgreSQL) 9.4.26
・・・
# apt purge postgresql

知っているpostgresql.conf ファイルらしきものが無く挫折したので、

v.14.3をソースでインストを試みる記事です。

説明書ソースの取得を読みつつソースページから一式ダウンロード。

# wget https://ftp.postgresql.org/pub/source/v14.3/postgresql-14.3.tar.gz
・・・
ERROR: The certificate of 'ftp.postgresql.org' is not trusted.
ERROR: The certificate of 'ftp.postgresql.org' has expired.
・・・(考え中)・・・
# wget http://ftp.postgresql.org/pub/source/v14.3/postgresql-14.3.tar.gz
HTTP request sent, awaiting response... 200 OK
Length: 28930973 (28M) [application/octet-stream]
Saving to: 'postgresql-14.3.tar.gz'

postgresql-14.3.tar 100%[=====================>]  27.59M  5.87MB/s   in 4.7s

2022-05-24 11:14:11 (5.87 MB/s) - 'postgresql-14.3.tar.gz' saved [28930973/28930973]
# gunzip postgresql-14.3.tar.gz
# tar xf postgresql-14.3.tar

インストールの手順を読みつつ、

# cd postgresql-14.3
# ./configure
・・・
configure: error: readline library not found
If you have readline already installed, see config.log for details on the
failure.  It is possible the compiler isn't looking in the proper directory.
Use --without-readline to disable readline support.

ググってみると参考になりそうなページを見つける。

# apt install readline
# apt install readline-devel
# export CPPFLAGS=-I/usr/share/readline

シェアライブラリィっぽいのでldconfigしなおしたら・・・

#ldconfig
/sbin/ldconfig.real: /usr/local/gcc-11.2.0/lib/libstdc++.so.6.0.29-gdb.py is not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig.real: /usr/lib/libreadycloud.so.1 is not a symbolic link

やばいかも(汗

とりあえず、readline以外のエラーが無いかチェックしてみる。

# ./configure --without-readline
・・・
configure: creating ./config.status
config.status: creating GNUmakefile
config.status: creating src/Makefile.global
config.status: creating src/include/pg_config.h
config.status: creating src/include/pg_config_ext.h
config.status: creating src/interfaces/ecpg/include/ecpg_config.h
config.status: linking src/backend/port/tas/dummy.s to src/backend/port/tas.s
config.status: linking src/backend/port/posix_sema.c to src/backend/port/pg_sema.c
config.status: linking src/backend/port/sysv_shmem.c to src/backend/port/pg_shmem.c
config.status: linking src/include/port/linux.h to src/include/pg_config_os.h
config.status: linking src/makefiles/Makefile.linux to src/Makefile.port

どうやら、readlineパッケージをどうにかすればいいらしい。

ログを見ると

configure:12388: checking for library containing readline
configure:12420: gcc -std=gnu99 -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2  -D_GNU_SOURCE    conftest.c -lreadline -lpthread -lrt -ldl -lm  >&5
/usr/bin/ld: cannot find -lreadline
collect2: error: ld returned 1 exit status

ldconfigの設定を追加してldconfigしてみても変わらず

# /usr/share/readline
/usr/share/readline

ncursesもaptでインストしてみたがダメだったのでpurgeした。

readlineのインストの仕方が悪かったらしい。

参考ページの通りにソースからインストしてldconfig

# cd /usr/local/src
# wget http://ftp.gnu.org/gnu/readline/readline-4.3.tar.gz
# tar zxvf readline-4.3.tar.gz
# cd readline-4.3
# ./configure
# make
# make install
# find / -name readline
/usr/share/readline
/usr/local/include/readline
※libパスがgccのデフォルトパスと異なるみたいなので
  /etc/ld.so.conf.d/readline.confファイル作成しておく
# cat /etc/ld.so.conf.d/readline.conf
# /usr/share/readline
/usr/share/readline
# ldconfig

これで./configureが通ったので

# make
# make install

インストは成功。

しかし、psqlが 9.4.26のまま

どうやら、purgeがうまくいかなかったらしい

# find / -name psql
/home/admin/postgresql-14.3/src/bin/psql
/home/admin/postgresql-14.3/src/bin/psql/psql
/data/home/admin/postgresql-14.3/src/bin/psql
/data/home/admin/postgresql-14.3/src/bin/psql/psql
/usr/lib/postgresql/9.4/bin/psql
/usr/bin/psql
/run/nfs4/home/admin/postgresql-14.3/src/bin/psql
/run/nfs4/home/admin/postgresql-14.3/src/bin/psql/psql

/usr/lib/postgresql

/usr/lib/postgresql-common
/usr/bin/psql

を削除してもダメ。

INSTALLファイルを見ると、手短なケースでも

    ./configure
    make
    su
    make install
    adduser postgres
    mkdir /usr/local/pgsql/data
    chown postgres /usr/local/pgsql/data
    su - postgres
    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
    /usr/local/pgsql/bin/createdb test
    /usr/local/pgsql/bin/psql test

としなければいけないらしい。

更にじっくりインストするなら、かなりだるいことになりそう。

まず、先の9.4で作成されたpostgresユーザ設定のホームディレクトリィが変だったのでユーザを作り直す。

※su - で、ja_JP.UTF-8を作る
# localedef -f UTF-8 -i ja_JP ja_JP
# localectl list-locales | grep -i ja
※ユーザを一旦削除
# userdel postgres
※普通の設定でpostgresユーザを作成しなおす
# adduser postgres
※以下、postgresユーザで処理
# su -postgres
# vi .profile
$
a
LANG=ja_JP.UTF-8
LANGUAGE=
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=
# logout
※以下、最短ルートで初期化してみる
# /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
# /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
# /usr/local/pgsql/bin/createdb test
# /usr/local/pgsql/bin/psql test

※postgreSQLのコマンドのパスが通っていないので.profileにパスの追加を追記
PATH=$PATH:/usr/local/pgsql/bin

やれやれ、postgreSQLのインストがメンドクサイと思ったら、

初期設定がグダグダだから、

パッケージをインストする前に先回りしてしまえ!

というコトらしい。

# systemctl start postgresql
# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2022-05-24 13:58:04 PDT; 7s ago
  Process: 5094 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 5094 (code=exited, status=0/SUCCESS)

May 24 13:58:04 SlanyNAS0901 systemd[1]: Starting PostgreSQL RDBMS...
May 24 13:58:04 SlanyNAS0901 systemd[1]: Started PostgreSQL RDBMS.
# systemctl stop postgresql

後は pg_hba.confを設定すればいいはず。

$ cd /usr/local/pgsql/data
$ diff postgresql.conf postgresql.conf.org
63d62
< listen_addresses = '*'  # どこからでもOK
66d64
< port = 5432
445c443
< logging_collector = on  # stderrをログファイルにリダイレクトする ー>$PGDATA/logの下にログファイルができる
---
>
$ diff pg_hba.conf pg_hba.conf.org
91,92c91
< #host    all             all             127.0.0.1/32            trust
< host      all             all              0.0.0.0/0                 md5
---
> host    all             all             127.0.0.1/32            trust
$

しかし、リモート接続がうまくいかないというか全くログが取れないので、コンフィグしなおす。

# ./configure --enable-debug --with-openssl --enable-nls=UTF_JP
以下同じ

でもダメ、pg_ctlコマンドを試してみると

$ pg_ctl start
pg_ctl: no database directory specified and environment variable PGDATA unset
Try "pg_ctl --help" for more information.
$ echo $PGDATA
/usr/local/pgsql/data

PGDATA環境変数は通っているがpg_ctlからは見えない

もしかして、pg_ctlの中でshell起動してるのかな?

exportを付けてみた

export PGDATA=/usr/local/pgsql/data # 無いと動作しない
export PGLIB=/usr/local/pgsql/lib # 無くても動作する

記事によっては

export LD_LIBRARY=$LD_LIBRARY:/usr/local/pgsql/lib

を付けているところがあるけど、

今時のシェアライブラリィはldconfigコマンドで処理しないといけない(ハズ

$ pg_ctl start
waiting for server to start....2022-05-25 03:59:15.293 PDT [6764] LOG:  redirecting log output to logging collector process
2022-05-25 03:59:15.293 PDT [6764] HINT:  Future log output will appear in directory "log".
 done
server started

さて

PCからA5でリモート接続もできた。

export を付けずに環境変数を設定するとechoで設定できていても

それは只のシェルの内輪の変数でしかなく、

起動した子プロセスとかに引き継がれる環境変数ではない。

なので、

$ export -p

で確認しとかないと・・・

暫く使わないと忘れるw(罠



[ReadyNAS212]公開キーでログインできない

アカウント管理画面から公開キーをアップロードできるんだけど・・・

公開キーをアップロードしたら「RSYNCのみ」って書いてあった

TeraTermで公開キーを使ってログインしようとすると

一瞬「Rejected」の文字が見え、直ぐにTeraTermが終了してしまう。

原因は、 アカウント管理画面が複数の公開キーを保存できる様な仕組みになっているけど、

command="/frontview/bin/validate-rsync" ssh-rsa AAAA・・・

となっているので、/frontview/bin/validate-rsync というコマンドを実行して即終了している。

※RSYNCのみなんだからこれで正解なんだろう。

しかも、管理画面で作成した ssh_authorized_keys ファイルは書き換えも上書きもできない。

COMMANDの中身のファイルを見ると、rsync形式のコマンドチェックになっているから、

$SSH_ORIGINAL_COMMANDの内容がrsyncコマンドっぽくないのでダメらしい

しかし、TeraTermから $SSH_ORIGINAL_COMMANDを送る方法が見当たらなし。

見つけてもrsyncのコマンドを実行するだけなんで意味は無さそう。

...
# Add Begin.
"")
RC_FILE=/home/`whoami`/.bash_profile  # Need ".bash_profile" file.
exec $SHELL --rcfile $RC_FILE
;;
# Add End.
*)
echo "Rejected"
;;
esac

これで、 キーストアに「command=”/frontview/bin/validate-rsync”」が書かれているけど、インタラクティブな接続もできるようになる。

TeraTermから $SSH_ORIGINAL_COMMANDを送る方法があれば、rsync コマンド+ログインを送ればいいのかもしれない。

rsync --server****** ; exec $SHELL --rcfile /home/'whoami’/.bash_profile

しかし、問題が発生。今まで他のサーバーでやってる様に

※TeraTermで電子鍵を作成する
※TeraTermでパスワード認証でログイン
※TeraTermに公開キーをドロップする
# mv {公開キーファイル名}  .ssh/authorized_keys

とすると公開キーでログインできるが、管理画面で公開キーをアップロードした後では

ドロップすると、先ssh_authorized_keysの「 /frontview/bin/validate-rsync 」が「rejected」してくる!

authorized_keysと ssh_authorized_keys は併用できるから

TeraTerm用とRSYNC用に分けて運用した方がよさそうだ。



[ReadyNAS212]node-v14.17.6 インスト

やはりバージョンがあがっていたので、

# sudo wget https://nodejs.org/dist/v14.17.6/node-v14.17.6.tar.gz
# tar xvzf node-v14.17.6.tar.gz
# cd node-v14.17.6
# export CCFLAGS='-march=armv7-a'
# export CXXFLAGS='-march=armv7-a'
# sudo -E ./configure     ※要python
# date; sudo -E make -j4 ; date;
Fri Sep 17 21:03:47 JST 2021
・・・
Fri Sep 17 23:04:00 JST 2021
-j4でも結構限界に近い

最初は -j8 でやってみたら、盛りすぎてエラったらしい。

virtual memory exhausted: Cannot allocate memory
tools/v8_gypfiles/v8_compiler.target.mk:259: recipe for target '/home/{ユーザ}/node-v14.17.6/out/Release/obj.target/v8_compiler/deps/v8/src/compiler/js-operator.o' failed
make[1]: *** [/home/{ユーザ}/node-v14.17.6/out/Release/obj.target/v8_compiler/deps/v8/src/compiler/js-operator.o] Error 1
make[1]: *** Waiting for unfinished jobs....

では

# date; sudo -E make -j4 ; date;
Fri Sep 17 21:03:47 JST 2021
...
Fri Sep 17 23:04:00 JST 2021


[ReadyNAS212]gcc-11.2.0

バージョンが上がってたので、

# apt-get install build-essential libssl-dev
# wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-11.2.0/gcc-11.2.0.tar.gz
# tar xzf gcc-11.2.0.tar.gz
# cd gcc-11.2.0
# ./contrib/download_prerequisites
2021-09-17 00:49:04 URL:http://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2 [2383840/2383840] -> "gmp-6.1.0.tar.bz2" [1]
2021-09-17 00:49:06 URL:http://gcc.gnu.org/pub/gcc/infrastructure/mpfr-3.1.6.tar.bz2 [1287202/1287202] -> "mpfr-3.1.6.tar.bz2" [1]
2021-09-17 00:49:07 URL:http://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.0.3.tar.gz [669925/669925] -> "mpc-1.0.3.tar.gz" [1]
2021-09-17 00:49:09 URL:http://gcc.gnu.org/pub/gcc/infrastructure/isl-0.18.tar.bz2 [1658291/1658291] -> "isl-0.18.tar.bz2" [1]
gmp-6.1.0.tar.bz2: OK
mpfr-3.1.6.tar.bz2: OK
mpc-1.0.3.tar.gz: OK
isl-0.18.tar.bz2: OK
All prerequisites downloaded successfully.
# mkdir build
# cd build/
# ../configure --enable-languages=c,c++ --prefix=/usr/local/gcc-11.2.0 --disable-bootstrap
# date; make; date
Fri Sep 17 01:17:54 JST 2021
(中略)
Fri Sep 17 04:14:29 JST 2021

NASを再初期化したせいか、/etc/sudoers が無いので、sudoパッケージをインストしてからsudo設定。

# apt-get install sudo
# chmod +w /etc/sudoers
# vi /etc/sudoers
Defaults        secure_path="/usr/l..."
↓
Defaults        secure_path="/usr/local/gcc-11.2.0/bin:/usr/l..."
# chmod -w /etc/sudoers
# sudo vi /etc/ld.so.conf.d/arm-gcc-11.2.0.conf
で以下を追記。
# gcc-11.2.0 configuration
/usr/local/gcc-11.2.0/lib

gccのビルド&インストが終わったら・・・

# sudo ldconfig
/sbin/ldconfig.real: /usr/local/gcc-11.2.0/lib/libstdc++.so.6.0.29-gdb.py is not an ELF file - it has the wrong magic bytes at the start.

/sbin/ldconfig.real: /usr/lib/libreadycloud.so.1 is not a symbolic link

新たな敵が出現した?(かも

# ls -l /usr/lib/libreadycloud.so.1
-rwxr-xr-x 1 root root 86568 Jan  8  2021 /usr/lib/libreadycloud.so.1
  1. 対策1
    • /usr/local/gcc-11.2.0/lib/libstdc++.so.6.0.29-gdb.py を削除する。
      • rm /usr/local/gcc-11.2.0/lib/libstdc++.so.6.0.29-gdb.p
  2. 対策2
    • /usr/lib/libreadycloud.so.1をリンクファイルに変える。
      • rm /usr/lib/libreadycloud.so.1
      • WinSCPで同名のリンクファイル(リンク先:libreadycloud.so.1.0.0)を作成。

これはsudoインスト・プロテクトなのか?

それよりもNAS上のエラーが出ている間、アプリのインストやアンスコが失敗判定になっていたから、

これで正しいんだろう。

ソースがかなりの容量(3GB近く)になっているので圧縮。

# tar cvzf gcc-11.2.0_pack.tar.gz gcc-11.2.0/

make install はソースを展開したディレクトリィに特化してる(ハズな)ので再利用時は注意。

おっと、ユーザをsudoグループに追加するのを忘れていた。

#  gpasswd -a {ユーザ名} sudo


[ReadyNas212]Node.jsインスト再び

前回インストからしばらく経ったので、Node.js本家からVer14をインスト。

curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
apt-get install -y nodejs
Reading package lists... Done
N: Skipping acquire of configured file 'main/binary-armel/Packages' as repository 'https://deb.nodesource.com/node_14.x jessie InRelease' doesn't support architecture 'armel'

## Run `sudo apt-get install -y nodejs` to install Node.js 14.x and npm
## You may also need development tools to build native addons:
     sudo apt-get install gcc g++ make
## To install the Yarn package manager, run:
     curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --dearmor | sudo tee /usr/share/keyrings/yarnkey.gpg >/dev/null
     echo "deb [signed-by=/usr/share/keyrings/yarnkey.gpg] https://dl.yarnpkg.com/debian stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
     sudo apt-get update && sudo apt-get install yarn

今回もダメだった。一応 apyでもやってみたが

# sudo apt-get install -y nodejs
# node -v
v0.10.29

安定のVer0でした。ちゃんとお掃除しとこ。

# sudo apt-get remove -y nodejs
NASの状態 By PHPSystemInfo

Node.jsの32Bit版はarmhf (ARM 32-bit hard-float, ARMv7 and up: arm-linux-gnueabihf)対応なのはそのまま。



[RadyNAS212]node.js再び

OS入れなおしたのでnode.jsやgitの環境が消えてしまった。

やり直すのがメンドクサイ。

  1. gitインスト
  2. gccビルド
  3. gccの共有ライブラリィの設定(arm-gcc-9.2.9.conf作成)
  4. opensslビルド
  5. python3ビルド
  6. node.js

の順でいいはず。

しかしバージョンが上がる度に何かが可笑しくなるのはいつものこと

nginXを入れてWANからは80でLANからは80以外のポートでWordPressを動かすのも悪くないかな

  • PHP 7.3 以上
  • MySQL 5.6 以上または MariaDB 10.1 以上

の条件が厳しいからphpenvとphp-frmでnginx実行時のみ最新のphpを動かせばいいかも

# php -v
PHP 5.6.40-0+deb8u12 (cli) (built: Jun 28 2020 13:19:50)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
# mysql --version
mysql  Ver 14.14 Distrib 5.5.62, for debian-linux-gnu (armv7l) using readline 6.3
# mysqladmin --version
mysqladmin  Ver 8.42 Distrib 5.5.62, for debian-linux-gnu on armv7l



[ReadyNAS212]ファームウェアのアップデート

最新のファーム(6.10.5 Hotfix1)にアップデートした後

  • NASの管理画面でアプリのアイコンが全部NotFound的な表示になった
  • Windowsのアプリは「NASは見れれど、オフライン」的な表示
  • Windowsのアプリ の「バックアップ PCフォルダー」のリンクが出る時もあるが大抵出てない

な状況になっていた。

HTTPSにちゃんと対応できてないから、PCのブラウザの一時的なものかな?

と思ってたけど、一向に治る気配が無い。

メインはクラウドサービス(写真など)のバックアップだし、困ってないし、このままでもいいんだけど・・・

NASの管理画面の設定をいじったのが原因な気がしてきたので、

NASをぶっ壊した時に重宝する「工場出荷状態に戻す」ボタンを使って初期化してみたら、

上記の症状が嘘のように消えました。

※でも、しばらく使っているうちに、戻ってしまうかもしれない。



[ReadyNAS212]iSCSI

iSCSIってNASにHDDのブロック管理を丸投げしてアクセスするので非力なNASなら効果が大きそう。

でも今時のWindowsは自動的に色々動き出すので、PC間でいくら注意深く運用しても共有すればベタに製造元的にも使用者的にも想定外なコトが起こるのは必然で、まともな使い道は思いつかなかった。

でも、一応あるので、通常の共有フォルダとiSCSIでパフォーマンスに差があるのか調べてみた。

NASの共有フォルダ(4TBぐらい)をベンチした結果
NASのiSCSI接続のドライブ(512GB)をベンチした結果

と云う感じで、パフォーマンスの差はなぜか微妙。CPUは非力だがメモリが2GBもあるせいかな?

意外とHDDがSMR(Shingled Magnetic Recording)なんで、こっちがデッドロックになってるかもしれないのでSATAもチェックしてみるが、SATA接続(Hitachi HDS723020BLA642)の恐らくCMRと思えるHDDでも

SATA接続のHDDをベンチした結果1

SMRとは云え、古いせいかNASの方が速い気がする。

異音はしないけど不安定なSegate ST2000DM001も

SATA接続のHDDをベンチした結果2

なので、チョコまかとアクセスしそうなWindows10のHyper-Vの仮想マシンはSATA接続のHDDよりNASの方が向いてそう。

一方ネットワーク上のNASや他のPCの共有フォルダは仮想マシンの ハードディスクファイルの置き場所に選択できるけど

共有フォルダを選択して作成した仮想マシンを起動した結果

こうなる。確かWindowsServerの管理下に無いネットのリソースには「Hyper-Vのアクセス権限」と云う概念が無いせいでハジかれたハズなのでWindows10クライアントのみでは不可なんだろう。

何故かiSCSI接続なら起動できるし、動きもSATA接続のHDDよりはマシな感じ。

性能は大差無いので、「共有フォルダ」はアカウントでアクセスを管理したい方、「iSCSI」はイニシエーターでPC単位でリソースを管理したい方・・・に向いているのかな。

NASでPXEネットワークブートをすれば、ディスクレスなPCをiSCSIブートもできそうだから、そっちがメインターゲットかな?

今、ブログサーバはITXにひとまとめにしているけど、定期的にスペック的な入替えが必要なCPUやメモリと、壊れる直前までそのまんまにしておきたいディスクを分離するのも悪くない。

ReadyNASのアプリからWordPressが消えて久しくNASとブログサーバを一体化しにくくなったけど、 ブログサーバ のディスクをiSCSIで共有するのは意外と使えるかも。

※一体化するとNAS管理画面も公開してしまうので、Apacheの設定を編集しないといけないけど、どうやってもアプリのインストールに成功するけど、ログにインスト失敗が書かれるので、何かうまくいっていないようだ。

ん?

ブログサーバ、NAS、Windowsと3台のCPUを使って、この記事書いてるのか。

無駄に、とある意味、贅沢な環境になってた。

ps.2022/02/24

iSCSIドライブが見つからなくなっていた。

原因はNASのIPアドレスが変わっていたこと。

ルータで固定IPアドレス指定にするも、iSCSIイニシエータが旧IPアドレスを覚えてたままなので

「ターゲット」タブから一旦削除し、「ターゲット」でNASを指定して【クイック接続(Q)】押下して新しいIPアドレスに差し替えた。

iSCSIのイニシエータ名は「構成」タブで入力した時のままだったので入力しなおす手間はかからなかった。

あ、Wifiルータも固定にしておこう。




top