CentOS7でルータのログを受け取るrsyslog設定


ここ1ヶ月、長らく使っていたWiFiルータの一部プロセスが良く死んでいた。

具体的には固定IP割り当てしているやつらは問題ないのだが、DHCPによるIP割り当てがうまく行かず、またルーター管理画面にアクセスしようとしても途中で接続が切断される、という状態になっていた。

復帰方法は電源off/onしかないのだが、まぁ、最近のWiFiに対応するやつにするかと4千円程度のものに交換した。

ルータ交換後の様子を継続的に見るためにCentOS7サーバにログを飛ばしておくか、と設定してみた。

その1 firewallの穴開け

標準ではsyslogポート(514)は開いていないので、開ける。

まず、firewalldが持っている規定のサービス名を確認

[root@blog ~]# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql munin-node murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius redis rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server
[root@blog ~]#

「syslog」が使えそう。あと、今回は不要だけど「syslog-tls」も入れておくか、ということで以下を実行

[root@niselog ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp14s0
  sources:
  services: dhcpv6-client http https ssh
  ports: 
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@niselog ~]# firewall-cmd --permanent --zone=public --add-service=syslog
success
[root@niselog ~]# firewall-cmd --permanent --zone=public --add-service=syslog-tls
success
[root@niselog ~]# firewall-cmd --reload
success
[root@niselog ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp14s0
  sources:
  services: dhcpv6-client http https ssh syslog syslog-tls
  ports: 
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@niselog ~]#

また、「22.5. ロギングサーバーでの RSYSLOG の設定」によればSELinuxによりポート制限をしている事もあるので「semanage port -l」でsyslogに許可されているポートを確認しろ、とのこと。

[root@niselog ~]# semanage port -l | grep syslog
syslog_tls_port_t              tcp      6514, 10514
syslog_tls_port_t              udp      6514, 10514
syslogd_port_t                 tcp      601, 20514
syslogd_port_t                 udp      514, 601, 20514
[root@niselog ~]#

その2 rsyslogにポート514での受信許可

標準の/etc/rsyslog.conf ではポート514の使用について下記の様にコメントアウトされています。

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

これのコメントを外します。

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

設定後、rsyslogの再起動で/var/log/messagesにログがたまる。

<pre class="wp-block-syntaxhighlighter-code">[root@niselog rsyslog.d]# systemctl restart rsyslog
[root@niselog rsyslog.d]# systemctl status -l rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 金 2019-11-01 11:04:53 JST; 1s ago
     Docs: man:rsyslogd(8)
           <blockquote class="wp-embedded-content" data-secret="pQOPhRmYhk"><a href="https://www.rsyslog.com/doc/">RSyslog Documentation</a></blockquote><iframe title="&#8220;RSyslog Documentation&#8221; &#8212; rsyslog" class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" src="https://www.rsyslog.com/doc/embed/#?secret=pQOPhRmYhk" data-secret="pQOPhRmYhk" width="525" height="296" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>
 Main PID: 2872 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq2872 /usr/sbin/rsyslogd -n

11月 01 11:04:53 niselog systemd[1]: Starting System Logging Service...
11月 01 11:04:53 niselog rsyslogd[2872]:  [origin software="rsyslogd" swVersion="8.24.0-41.el7_7.2" x-pid="2872" x-info="http://www.rsyslog.com"] start
11月 01 11:04:53 niselog systemd[1]: Started System Logging Service.
[root@niselog rsyslog.d]#</pre>

その3 ログを分ける

標準だと/var/log/messagesにまとめられてしまうため、ログを分離する。

/etc/rsyslog.d/remote.conf というファイルを新規作成し、下記を書いた。(「gateway」はルータについているホスト名)

if $fromhost == 'gateway' then {
  -/var/log/remote/gateway.log
  stop
}

これを設定したあと、「systemctl restart rsyslog」で/var/log/remote/gateway.log にログが保存されるようになった。

なお、最初、上記の「-/var/log/remote/gateway.log」ところは「-/var/log/remote/%fromhost%.log」として%fromhost%がホスト名に置き換わることを期待したのですが、実際に作られたログファイル名は「 /var/log/remote/%fromhost%.log 」とそのままでした・・・

FortiClientのSSL-VPNが80%ぐらいで-12のエラーとなり接続出来ない


FortiClientのSSL-VPNを設定し、接続しようとしたら80%ぐらいのところで「 Unable to logon to the server. Your user name or password may not be configured properly for this connection. (-12) 」というエラーとなり接続できない。

ぐぐってでてきたFortinetフォーラムの「Error Forticlient stop 80%」は2017/02/10の書き込みながら、2019/01/23のコメントとしてWindows10の場合の事例について記載があった。

で、この記載を実施したところなおった。

「Internet Explorer」を開き、「インターネットオプション」の「詳細設定」を開く

上記の「Internet Explorerの設定をリセット」にある「リセット」を実行する。

実行後は一度再起動する。

再起動後、 「Internet Explorer」を開き、「インターネットオプション」の 「セキュリティ」を開く。

上記の「信頼済みサイト」を選択し、「サイト」をクリックする。

開いたウィンドウではSSL接続先のホスト名もしくはIPアドレスを登録する。(不要かも?)

ここで一度、FortiClientを起動してSSL-VPNが接続できるかを確認する。

まだ接続できないようであれば、「コントロールパネル」を開く

「プログラムのアンインストール」を選択

「FortiClient」を選択し「修復」を行う。

修復完了後は、再起動を行う。

おそらく、これでSSL-VPNが接続できるようになると思われる。


後日、「Unable to establish the VPN connection. The VPN server may be unreachable. (-14)」というエラーがでる・・・なんで?

ESXiで使用できるUPS連動シャットダウンソフトの情報


ESXi 6.7からvMAというVMware提供の仮想アプライアンスが使えなくなった。
LinuxベースなのだがvCenter/ESXiをCLIから操作するためのツールが導入済みなので、UPS連動シャットダウンする際によく使われていた。

ESXi6.7以降は動かなくなってしまったので、代替を探す必要がある。

Schneider Electric (APC) PowerChute Network Shutdown

APC PowerChute Network Shutdownに関する情報は「PowerChute Network Shutdownプロダクトセンター | よくあるお問い合わせ」と「PowerChuteシリーズ 対応OS表」を起点に捜索する。

PowerChute Network Shutdown v4.3 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスイメージが提供されているのでそれを使う。
PowerChute Network Shutdown v4.2 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスか、vMAにPowerShuteインストールか、を選択できる。

PowerChute Network Shutdown v4.0以降のバージョンでVMware環境を保護する場合のPowerChuteインストール先について

PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例2
PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例3

VMware HA利用時やvSAN利用時は、VMware側がユーザ操作なしに停止することを全く考慮していないため、ESXiサーバのみの環境ではうまくシャットダウンを行うことができない。

別に物理のWindowsサーバを用意し、そこからシャットダウン命令を送る必要がある。また、復電後の起動についてはもっと考えられていないため、その処理も自前でどうにかする必要がある。

PowerChute Network Shutdown for Virtualization v4.x VMware HA環境でのサポート構成」(VMware HA環境では仮想マシン停止をサポートしていない)

20180222_VxRailccトラブルシューティングセミナーvSAN環境におけるUPS構成とシャットダウンシュナイダー出口様

HPE Power Protector

HPEブランドで販売されているUPSは、HPE Power Protector(HPEPP)を使用してシャットダウンを行う。

ソフトのダウンロードは「HPE swdepot Power Protector UPS Management Software」から行える。

ESXi 6.7以降の対応について「アドバイザリ: HPE Power Protector – VMware vSphere Management Assistantのサポートが終了したため、VMware ESXi 6.7 (またはそれ以降) を実行しているHPEサーバーでHPE Power Protectorが正しく機能しない」「Advisory: HPE Power Protector – HPE Power Protector Does Not Function Correctly On HPE Servers Running VMware ESXi 6.7 (Or Later) Due to The Discontinued Support For VMware vSphere Management Assistant」に記載している。

vMA使えないから、無料で使えるdebian使って仮想マシン作って、それにHPEPPを入れろ、ということになる。

EATON Intelligent Power Protector (IPP)とIntelligent Power Manager(IPM)

日本代理店ダイトロンの製品ページ「Intellignent Power Protector」「Intelligent Power Manager

メーカページ「Eaton Intelligent Power Manager

連動シャットダウンについてはWindows仮想マシンにIPMを入れる方向性のようだ

IPM SilverかIPM Goldを使うとVMware HAとvSANを含んだシャットダウンにも対応。

VMware HAはWindows仮想マシンにIPMを入れることで対応可能。復電も対応→「シャットダウン for vCSA on vSphere HA by IPM 1.62

vSANはvSANを使っていないESXi上にvCSAとWindows仮想マシン+IPMを置くことで対応可能。復電も対応→「シャットダウン for VMware vSAN 6.6.1 by IPM 1.60

10ドルの45W USB PDアダプタMAD GIGA PD Adapterを買ってみた


aliexpressで約10ドルという怪しげなUSB PDアダプタが売っているのを発見。

20V対応で45Wまで行けるらしいので買ってみた・・・

発注から2週間ちょいで到着。

・・・「公式ページ」があるのか

しかし、2019/10/04時点ではこのUSB PDアダプタは掲載されていなかった。

箱の中身は、USB PDアダプタ本体と説明書のみ

サイズ感の比較として、RAVPower 36Wと並べて見る。

裏面

USB端子側

AC側

そして、スペック表記。これは上がMAD GIGA

MODEL: PD45W+BC5V2.1A
INPUT: AC100-240V 50/60Hz 0.8A Max
OUTPUT USB-C: 5V3A / 9V3A / 15V3A / 20V2.2A
OUTPUT USB-A: 5V2.1A
MADE IN CHINA shanzhen hexinyu technology co,Ltd

で・・・こいつ、ACプラグの折りたたみ機構がちゃんと考えられていないようで、プラグを引き起こすために指を入れるスペースが確保されておらず、爪を差し込んで引き起こす的な感じになっています。

それ以外はぱっと見問題なさそうです。

次に電源を入れてみます。

手元にあるTC66Cで検査・・・

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・え?ほんとに販売ページに書いてあった「Type-C: 5V/3A, 9V/3A, 12V/3A, 15V/3A, 20V/3A 」ってマジなん?

いや、筐体に書いてあるスペックには載ってないけど12V3A隠し仕様で存在してる、ってのはよくあるけど、20V3Aって60W使えるって??いや、間違いかもしれないからPower-Zでも調べて見よう

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・どうやら間違い無いようですね(ちなみに本編とは関係ないですがRAVPower 36Wは5V3A/9V3A/15V3A/20V2.25Aと45W使えると出ました・・・)

自宅には20Vを使うUSB PD機器がないので、先日買ったUSB PD 20Vを丸形ノートパソコン電源に変換するアダプタを使ってテスト

うちにあるDynabookだと最大で20V2Aぐらいまでの使用に留まり、45W以上いくのかは確認出来ませんでした。

まぁ、約40W使用でそこそこ熱い感じだったので超えると危険そうですけどね

EC-CUBE 4.0をSELinux有効状態のOracle Linux 7上に構築する手順(仮


EC-CUBE 4.0のテスト環境が必要になったので、Oracle Cloud上のOracle Linux 7インスタンスを立てて、その上に作成した。

が・・・公式ドキュメントはSELinux関連の設定とか触れてないし、かなり面倒だった。
厳密にやろうとするとかなりキツイので、SELinux有効の中でも簡単な対処としている。

環境初期準備

タイムゾーンを日本に設定

# timedatectl set-timezone Japan

fail2ban設定

sshアタックがあった場合にとっととIPバンするためにfail2banをインストール。
・・・いや、ターゲットにされるとホント、すごい勢いでsshアクセスの試行がありますよ。

# yum install -y fail2ban fail2ban-hostsdeny fail2ban-systemd
# systemctl enable fail2ban.service
# cat <<EOF > /etc/fail2ban/jail.local
[DEFAULT]
# 24時間以内に3回不審なアクセスがあったら24時間BAN
#bantime  = 86400
#findtime  = 86400
bantime  = 259200
findtime  = 259200
maxretry = 5

#CentOS7なのでsystemd
#backend = systemd # jail.d/00-systemd.conf で設定されてた

# 除外IP
ignoreip = 127.0.0.1 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 <除外したいIPを追加>
[sshd]
enabled = true
banaction = firewallcmd-ipset
EOF
# systemctl start fail2ban.service
#

webサーバとphp設定

phpはOracleが用意しているphp 7.2を使用するため、「oracle-php-release-el7」をインストール。現状の標準設定だとphp 7.2が標準選択されている。なお、php 7.1かphp 7.0を使うこともできるが、いまさら利点は無いので使用しない方がよい。

# yum install oracle-php-release-el7
# 

phpパッケージとhttpdをインストールして、firewall開け設定実施

# yum install -y httpd mod_ssl php php-json php-mbstring php-pdo php-xml php-zip php-mysqlnd php-intl 
# systemctl enable httpd
# systemctl start httpd
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https
# firewall-cmd --reload

APCU(php-pecl-apcu)のインストールを推奨されたが、パッケージのコンフリクトが発生していたのでインストールしなかった。

SQLサーバ設定

今回はmariadbをSQLサーバとして使用した。

# yum install -y mariadb-server
# systemctl enable mariadb
# systemctl start mariadb
#

SQL起動後、ECCUBE用のデータベースを作成した。

# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.64-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database eccube character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all on eccube.* to cubesql@localhost identified by 'dbsqlp@ss';
Query OK, 0 rows affected (0.08 sec)

MariaDB [(none)]> exit
Bye
#

ECCUBEファイル展開

/var/www/html/eccube にEC-CUBE 4.0.3を展開した。

展開した中に.htaccessファイルが含まれていますが、標準設定では読み込まないのでApacheに設定追加を行います。 (もっとセキュリティを強化してもいいとは思いますが、面倒だったので・・・)

# cat <<EOF> /etc/httpd/conf.d/eccube.conf
<Directory "/var/www/html/eccube">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>
EOF
# systemctl restart httpd
#

で・・・SELinuxがらみがどうなるかですが、おもいっきり引っかかりまくりました。

とりあえず該当するコンテンツに対して「httpd_sys_rw_content_t」を割り当てることで対処しました。

最初は個別に対処していこうとしたのですが、インストールプロセスを進めていくと、/var/www/html/eccube全体に対して権限を要求されたため、最終的には下記となりました。

# chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube
#

とりあえず、これでEC-CUBE 4.0の初期セットアップ完了までできるようになりました。

エラーコレクション

SELinux設定をしていく中で出てきたエラー群です。

まず、 http://IPアドレス/eccube/ にアクセスすると以下が現れました。

(2/2) ContextErrorException
Warning: file_put_contents(/var/www/html/eccube/var/cache/install/EccubeInstallDebugProjectContainerDeprecations.log): failed to open stream: No such file or directory

(1/2) RuntimeException
Unable to create the cache directory (/var/www/html/eccube/var/cache/install)

このときに表示された /var/www/html/eccube/var に対して「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/var」を実行しました。

次にでたエラーは下記です。

Filesystem->copy('/var/www/html/eccube/html/template/default/assets/img/common/favicon.ico', '/var/www/html/eccube/html/user_data/assets/img/common/favicon.ico')

/var/www/html/eccube/html/user_data以下に書き込む権限がないというもの。
eccubeディレクトリ内を探すと他にも「user_data」というディレクトリがあったため、「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/html/user_data」と「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/app/template/user_data」を実行した。

最後に「権限チェック」で引っかかった。

以下のファイルまたはディレクトリに書き込み権限を付与してください。
>>☓:/var/www/html/eccube
>>☓:/var/www/html/eccube/app/Plugin
>>☓:/var/www/html/eccube/app/PluginData
>>☓:/var/www/html/eccube/app/proxy
>>☓:/var/www/html/eccube/app/template
>>☓:/var/www/html/eccube/html
>>☓:/var/www/html/eccube/vendor
<略>
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/README.md
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/composer.json
>>☓:/var/www/html/eccube/composer.json
>>☓:/var/www/html/eccube/composer.lock

ようはここまでで「httpd_sys_rw_content_t」を設定しなかった全ファイル。

「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube」を実行して再チェック・・・

>>○:アクセス権限は正常です

これでセットアップを進めることができました。