この画面は、簡易表示です
初期設定は・・・
何もしていなかったので
設定してみた。
# 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で十分そう。
初期設定は、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の様にシンボリックリンクを書き換えているので、再起動しても安心？
安易に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 ファイルらしきものが無く挫折したので、
説明書のソースの取得を読みつつソースページから一式ダウンロード。
# 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 statusldconfigの設定を追加してldconfigしてみても変わらず
# /usr/share/readline
/usr/share/readlinencursesも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/dataPGDATA環境変数は通っているが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で確認しとかないと・・・
暫く使わないと忘れるｗ（罠
アカウント管理画面から公開キーをアップロードできるんだけど・・・
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用に分けて運用した方がよさそうだ。
やはりバージョンがあがっていたので、
# 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
最初は -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バージョンが上がってたので、
# 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 2021NASを再初期化したせいか、/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/libgccのビルド＆インストが終わったら・・・
# 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これはsudoインスト・プロテクトなのか？
それよりもNAS上のエラーが出ている間、アプリのインストやアンスコが失敗判定になっていたから、
これで正しいんだろう。
ソースがかなりの容量（３GB近く）になっているので圧縮。
# tar cvzf gcc-11.2.0_pack.tar.gz gcc-11.2.0/make install はソースを展開したディレクトリィに特化してる（ハズな）ので再利用時は注意。
おっと、ユーザをsudoグループに追加するのを忘れていた。
# gpasswd -a {ユーザ名} sudo前回インストからしばらく経ったので、Node.js本家からVer14をインスト。
curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
apt-get install -y nodejsReading 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
Node.jsの32Bit版はarmhf (ARM 32-bit hard-float, ARMv7 and up: arm-linux-gnueabihf)対応なのはそのまま。
OS入れなおしたのでnode.jsやgitの環境が消えてしまった。
やり直すのがメンドクサイ。
の順でいいはず。
しかしバージョンが上がる度に何かが可笑しくなるのはいつものこと
nginXを入れてWANからは80でLANからは80以外のポートでWordPressを動かすのも悪くないかな
の条件が厳しいから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最新のファーム（6.10.5 Hotfix1）にアップデートした後
な状況になっていた。
HTTPSにちゃんと対応できてないから、PCのブラウザの一時的なものかな？
と思ってたけど、一向に治る気配が無い。
メインはクラウドサービス（写真など）のバックアップだし、困ってないし、このままでもいいんだけど・・・
NASの管理画面の設定をいじったのが原因な気がしてきたので、
NASをぶっ壊した時に重宝する「工場出荷状態に戻す」ボタンを使って初期化してみたら、
上記の症状が嘘のように消えました。
※でも、しばらく使っているうちに、戻ってしまうかもしれない。
iSCSIってNASにHDDのブロック管理を丸投げしてアクセスするので非力なNASなら効果が大きそう。
でも今時のWindowsは自動的に色々動き出すので、PC間でいくら注意深く運用しても共有すればベタに製造元的にも使用者的にも想定外なコトが起こるのは必然で、まともな使い道は思いつかなかった。
でも、一応あるので、通常の共有フォルダとiSCSIでパフォーマンスに差があるのか調べてみた。
と云う感じで、パフォーマンスの差はなぜか微妙。CPUは非力だがメモリが２GBもあるせいかな？
意外とHDDがSMR(Shingled Magnetic Recording)なんで、こっちがデッドロックになってるかもしれないのでSATAもチェックしてみるが、SATA接続（Hitachi HDS723020BLA642）の恐らくCMRと思えるHDDでも
SMRとは云え、古いせいかNASの方が速い気がする。
異音はしないけど不安定なSegate ST2000DM001も
なので、チョコまかとアクセスしそうなWindows１０の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と３台のCPUを使って、この記事書いてるのか。
無駄に、とある意味、贅沢な環境になってた。
ps.2022/02/24
iSCSIドライブが見つからなくなっていた。
原因はNASのIPアドレスが変わっていたこと。
ルータで固定IPアドレス指定にするも、iSCSIイニシエータが旧IPアドレスを覚えてたままなので
「ターゲット」タブから一旦削除し、「ターゲット」でNASを指定して【クイック接続(Q)】押下して新しいIPアドレスに差し替えた。
iSCSIのイニシエータ名は「構成」タブで入力した時のままだったので入力しなおす手間はかからなかった。
あ、Wifiルータも固定にしておこう。