www.kinryo.net

ある時rsyncdを再起動しようとして
# systemctl restart rsyncd
Failed to restart rsyncd.service: Unit rsyncd.service not found.
え！無！！勿論以前にインストールはしているのでが？
兎も角、インストール
# dnf install rsync
メタデータの期限切れの最終確認: 2:06:23 前の 2024年04月23日 07時31分27秒 に実施しました。
パッケージ rsync-3.1.3-19.el8_7.1.x86_64 は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!
え！インストールされているじゃん、じゃあ再度インストール
# dnf reinstall rsync
メタデータの期限切れの最終確認: 2:21:54 前の 2024年04月23日 07時31分27秒 に実施しました。
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン リポジトリー サイズ
================================================================================
再インストール:
rsync x86_64 3.1.3-19.el8_7.1 baseos 409 k

トランザクションの概要
================================================================================

ダウンロードサイズの合計: 409 k
インストール後のサイズ: 825 k
これでよろしいですか? [y/N]: u
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
rsync-3.1.3-19.el8_7.1.x86_64.rpm 1.6 MB/s | 409 kB 00:00
——————————————————————————–
合計 506 kB/s | 409 kB 00:00
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
再インストール中 : rsync-3.1.3-19.el8_7.1.x86_64 1/2
整理 : rsync-3.1.3-19.el8_7.1.x86_64 2/2
scriptletの実行中: rsync-3.1.3-19.el8_7.1.x86_64 2/2
検証 : rsync-3.1.3-19.el8_7.1.x86_64 1/2
検証 : rsync-3.1.3-19.el8_7.1.x86_64 2/2
再インストール済み:
rsync-3.1.3-19.el8_7.1.x86_64
完了しました!
再インストールしたのでconfファイルが変更になっているか確認したら、オリジナルがそのままだったので、再度スタート
# systemctl start rsyncd
Failed to restart rsyncd.service: Unit rsyncd.service not found.
と、まだ無いと怒られる。なので /usr/lib/systemd/systemを調べるとrsyncd.serviceなどが無い。というわけで他のサブホストに有る、rsyncd.service, rsyncd.socket, rsyncd@.serviceを持って来て/usr/lib/systemd/systemに所有者をrootで保存後、再度
# systemctl start rsyncd
Job for rsyncd.service failed because of unavailable resources or another system error.
See “systemctl status rsyncd.service” and “journalctl -xe” for details.
と言われたので
# journalctl -xe
をやると
rsyncd.service: Failed to load environment files: No such file or directory
とあるので、/usr/lib/systemd/system/rsyncd.serviceをチェックすると
EnvironmentFile=/etc/sysconfig/rsyncdがあるので、再度別のサブホストで調べると、このファイルは
OPTIONS=””
とだけ書いてあるので、/etc/sysconfig/rsyncdを作成し、再度
# systemctl start rsyncd
# systemctl status rsyncd
● rsyncd.service – fast remote file copy program daemon
    Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled; vendor pre>
    Active: active (running) since Tue 2024-04-23 10:19:27 JST; 13s ago
    Main PID: 2521603 (rsync)
    Tasks: 1 (limit: 24667)        以下省略
でやっとスタートした。

自身でLISTENしているポートを調べる
# netstat -ant |grep LISTEN
# ss -atn | grep LISTEN でも同じ

ポートを開ける
# nc -l -k -p ポート番号

参考(https://syutaku.blog/php-8-configuration-trouble/）
ある時動画をアップロードする為に今までの最大ファイルサイズを512MBから1024MBに変更するために/etc/php.iniのupload_max_filesize を1024Mにして、アパッチとphp-fpmを再起動する
# systemctl restart httpd
# systemctl restart php56-php-fpm
# systemctl restart php74-php-fpm
(注：私は古いXOOPSをやる為にphp56をインストールし、wordpressの為にphp74をインストールしている）
あれー？？反映して無い！
では、どのphp.iniを使っているの？
# php -i | grep /php.ini
Loaded Configration File => /etc/php.ini
うーん、正しいphp.iniを変更してるがなー？ちょっと待て確か他にもサイズに関するパラメーターがあったなーと思いだし、改めて眺めていると、あったぞー
post_max_size = 1024Mと変更し再度上の三つを再起動。
ばんざーい！！ちゃんと反映された
普通はこんな大きなファイルサイズにはしないが、このＷＥＢは自宅にあるＷＥＢサーバーで動いているので、大風呂敷を広げてもいいかな？

どうもRHEL８ あたりからVNC SERVER からログアウトするとVNCSERVERが停止し、次回にログインできなくなって、いちいちSSHで接続してからVNC SERVER を立ち上げないとVNCサーバーが使えなくてすごく不便。これを解消する方法をGOOGLE先生に聞くとhttps://www.concurrent-rt.co.jp/external/TechSup/VNCforV84.htmlに答えがあったので、
# gedit /usr/lib/systemd/system/vncserver@.service
前略
[Service]
Type=forking
ExecStartPre=+/usr/libexec/vncsession-restore %i
ExecStart=/usr/libexec/vncsession-start %i
PIDFile=/run/vncsession-%i.pid
SELinuxContext=system_u:system_r:vnc_session_t:s0
Restart=on-success　　　← これを追記
後略
ただこの設定をしても、次は再起動しないので、SSHでログイン後、VNCサーバーを起動、でもそれ以降はログアウト後再起動してくれる（考えて見れば当たり前、起動時に設定を読むがこの時点でRestart=on-successが無いので）
ばんざーい！！！
参考：https://tex2e.github.io/blog/linux/systemd-restart-config

突然メールが送れ無くなった。送ろうとするとserver unabailable のエラーが帰って来る。
早速メールのログを(/var/log/mail.log) すると
clamav-milter[3040]: Failed to initiate streaming/fdpassing
clamav-milter[3040]: No clamd server appears to be available
とエラーになっている。clamd サーバーが無いだと？で早速
# systemctl status milter-manager
これはアクティブ
# systemctl status milter-greylist
これもアクティブ
# milter-manager –show-config|less
** (process:1293): WARNING **: 16:47:11.345: libruby.so.3.0: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません
後略
libruby.so.3.0が無いと言っている。どうもmilter-managerがアップデートにより必要になったようです。（参考：https://vicsfactory.com/?p=362）rubyはsclを利用すれば簡単にインストールできるようなので、まずはsclをインストール。
# yum install centos-release-scl
インストールされていた。ので
# yum -y install rh-ruby30 rh-ruby30-ruby-devel
インストールされたかチェック
# find /usr -type f -name “libruby*” |grep libruby.so.3.
アレー /usr にはインストールされていない、じゃあ何処だ
# find / -type f -name “libruby*” |grep libruby.so.3
ルートから調べるので、少し時間が係る
/opt/rh/rh-ruby30/root/usr/lib64/libruby.so.3.0.2
/opt/rh/rh-ruby30/root/usr/share/systemtap/tapset/libruby.so.3.0.stp
後略
場所が分かったので、ここからリンクを作るが /opt/rh/rh-ruby30/root/usr/lib64/ を見ると本体の libruby.so.3.0.2 とlibruby.so.3.0 と libruby.so の二つがlibruby.so.3.0.2 のリンクとしてあるので、
/usr/lib64/libruby.so.3.0.2 と /usr/share/systemtap/tapset/libruby.so.3.0.stp にリンクとして置いた。さらに libruby.so.3.0.2 のリンクとして libruby.so.3.0 と libruby.so を置いた。そして関連を再起動
# systemctl restart milter-manager
# systemctl restart spamassassin
# systemctl restart postfix
これでテストメールを送ると無事配信された。バンザーイ

ある時、pcs clusterを的確に判断出来るように、(データーの流れるネットワークとクラスターの生死判断のためのネットワークを別にする）ネットワークカード(マザーボードにある同じICのrtl8111を使っている）を追加したらネットワークが死んだ。ルーターにもpingが届かない！
奮闘2時間、原因が判らなかったが、結論はマザーボードのdevice名とネットワークカードのdevice名が入れ替わっている！！
原因が判れば簡単なのだが、入れ替わっているとは！そのヒントは
# nmcli device show
前略
GENERAL.DEVICE: enp2s0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 00:F0:4C:68:F2:04
GENERAL.MTU: 1500
GENERAL.STATE: 100 (接続済み)
GENERAL.CONNECTION: bridge-slave-enp2s0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveC>
WIRED-PROPERTIES.CARRIER: オフ 　これが問題
IP4.GATEWAY: —
IP6.GATEWAY: —
WIRED-PROPERTIES.CARRIER: オフと言うことは物理的にネットワークケーブルが接続されていないという事。(偉そうな事を言うがこれを知ったのはこの問題が出たから）
入れ替わっているとは知らず、マザーボードにケーブルを接続して、今はenp2s0は増設したカードに割り当てられているので、ケーブルが刺さってないとなる。なので、ケーブルをネットワークカードの接続口にさしたら、問題なくなった。
増設前のマザーボードのdevice名はenp2s0、増設後は
マザーボードのdevice名はenp3s0、増設した方のdevice名はenp2s0になった。もちろん再起動後もこの状態。ディスクの名前が再起動後に変化するように、ネットワークICの名前も変わったら大変だけど、何回か再起動しても変化はしなかった。後日もし変化したらここでお知らせしますが、サーバーなのでテスト後の再起動はあまり無いかな。

ある時、DRBDの作業中、対向するサブホストを設定するために、sambaの設定が終了しているホストからroot領域をrsyncでコピーして来た。もちろんIPアドレスやhost名を変更し（ディスクのUUIDも同じだが取りあえず変更していない）
そしてpcs関連の設定が終わりステイタスを確認する
# pcs status
Error: error running crm_mon, is pacemaker running?
error: Could not connect to launcher: Connection refused
crm_mon: Connection to cluster failed: Connection refused
アレー、pcsdはアクティブだがpacemakerが死んでいる。何故だ！！
pingを対向するホストに打ってみる
# ping 192.168.xx.xx
PING 192.168.xx.xx (192.168.4.63) 56(84) bytes of data.
送信元 192.168.xx.yy icmp_seq=10 目的のホストへ届きません。
だけども、このローカルネットワークの他のホストにはpingは正常、対向するホスト同士だけpingが通らない。これには何時間も費やした。
結論：macアドレスが同じだったのが原因。コピーした時、変更をしていないので！
サブホストを停止して。
このサブホストのmacアドレスは /etc/libvirt/qemu/smb4.xmlで定義しているので（本来はこれを直接いじらない様だが、私はvimが嫌い）エディターで
<interface type=’bridge’>
  <mac address=’52:54:00:cc:94:15’/>　← 最後は:cc:94:a3だったのを:cc:94:15に変更
  <source bridge=’br0’/>
  <model type=’virtio’/>
  <address type=’pci’ domain=’0x0000′ bus=’0x01′ slot=’0x00′ function=’0x0’/>
</interface>
:cc:94:15は他のサブホストが使っていないものを指定。上桁はkvmのサブホストはすべて同じになる。そしてこの変更を反映する
# virsh define /etc/libvirt/qemu/smb4.xml
でもって、サブホストを起動。pingも通るしpcs statusも正常に表示された。やれやれ

いつも忘れるので個人の防備録用、(でも設定ファイルの方がやりやすいのになー。特にKVMでクローンしたサブホストは固定のIPアドレスやホスト名がダブっているので、ログインしないと変更出来ない。設定ファイルならlosetupやkaprtxを使い簡単に変更出来るのに）
ブリッジの追加
# nmcli con add type bridge ifname br0
# nmcli con mod bridge-br0 bridge.stp no
固定IPにし、アドレス設定
# nmcli con mod bridge-br0 ipv4.method manual ipv4.address 192.168.xx.xx/24
ipv4.gateway 192.168.xx.xx
ipv4.dns 168.168.xx.xx +ipv4.dns 8.8.8.8
インターフェイスを割り当てる。インターフェースはenp2s0、ブリッジはbridge-br0の時
# nmcli con add type ethernet ifname enp2s0 master bridge-br0
で、rebootし設定の反映。
インターフェースの固定IPなどを変更した場合等はリブートせず、
# nmcli con down デバイス名(enp2s0など）
# nmcli con up デバイス名
で反映させられる