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の初期セットアップ完了までできるようになりました。

なお、サイトによっては「getsebool -a|grep httpd_can_network_connect」で「httpd_can_network_connect」の値を確認し、offであればonに変更する、と記載されているものもありますが、必要ありませんでした。

エラーコレクション

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」を実行して再チェック・・・

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

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

Oracle Cloud上にWindows Server 2016インスタンスを作ったら記号が入らずパスワード入力ができなかった件

Oracle Cloudの登録特典でもらえる30日有効の33000円分のクレジットがまだまだ余ってるので、Windows Server 2016インスタンスを作ってみた。

画像

初期パスワードはシステム側で自動生成される・・・と

画像

ありますね。

初回ログインはコンソール画面から行う必要があるので、上記の画面をスクロールして「リソース」の「コンソール接続」から「コンソール接続の作成」を選択

sshの公開鍵を指定して・・・

コンソール接続が「アクティブ」となったら、右側のメニューから「VNCを使用して接続」を選択

「プラットフォーム:WINDOWS」を選択して、文字列を「コピー」

Windows上でPowerShellを開いて、コピーしたものを貼り付けて実行

で・・・VNC Viewerを起動して「localhost:5900」に接続を実行すると下記の様にログイン画面が出てくる。

画像

で・・・ココで問題が発生。

パスワードを入力しようとしても 「:→;」「@→2」「^→6」「`→~」「=→+」 という感じで期待通りの入力が行えない。

Windows 10の日本語キーボード環境で「;キー」と「:キー」のどちらを押しても「;」が入力される事態。UltraVNCにあるSend Custom Keyを使用して「85」「86」を送っても、同じく「;」が入力されてしまう。

UltraVNCには「Japanese keyboard」という設定項目があるのでそれを設定しても状況は変わらず。

画像

UltraVNC
RealVNC
TigerVNC
この3つを試したところ、TigerVNCでは、Windows上のキーボード認識がUSキーボードになってるけど、実際につながっているのは日本語キーボード、という場合に相当する動きをしてくれた。

この動きであれば、日本語キーボードを英語配列だと思い込んで操作することによってなんとか記号を入力することができる(一部入力できないものもあるが、UltraVNC/RealVNCよりはずっとマシ)

TigerVNC Viewerでログインに成功し、デバイスマネージャー(Device Manager)から「Standard PS/2 Keyboard」を「Japanese PS/2 Keyboard (106/109 key)」に変更することで、日本語キーボードであっても期待通りに入力出来る環境を用意することができた。

(下記の画像はWindows Server 2012R2のだけど、Windows Server 2016もほぼ同じ)

「Standard PS/2 Keyboard」の「Properies」を開き、「Driver」タブを選択する。

「Update Driver」を選択し、下記では「Browse my computer from driver software」を選択

下記は「Let me pick from a list of device drivers on my computer」を選択

「Show compatible hardware」に入っているチェックを外す

チェックを外すと下記の様に選択肢がたくさん現れる。

下記の様に「(standard keyboards)」内の「Japanese PS/2 Keyboard (106/109 Key)」を選択し、「Next」

警告は「Yes」

変更完了

再起動して、変更を反映させます。

また、コントロールパネルの「Language」にて

「Add an input method」を選択し、リストから「QWERY Japanese」を選択し、「Add」

「Save」します。

Save実行とともに時計の横に「ENG US」が表示されますので、それをクリックすると「ENG JA」が選択できます。

これにより日本語キーボードをつかって正常に入力することが可能となります。

なお、この設定を行ってもUltraVNC,UltraVNC(Japanese Keyboard設定あり),RealVNCでは相変わらずな動作をして記号や日本語変換が行えませんでした。

Oracle Cloudでは使用状況レポートを有効にしないとVM内にアクセスエラーログがたまりまくるので注意

東京リージョンでOracle Cloud Always Freeインスタンスを作れないので、US West(Phoenix)リージョンでアカウントを作り直してOracle Linux 7インスタンスを作ってみたところ /var/log/oracle-cloud-agent/agent.log にスクリプトの実行エラーが毎秒出ている。

画像

作り直し前の方ではagent.logは正常なのに何故?と思ったら、Oracle Cloudコンソールの「アカウント管理」の「使用状況レポート」が未設定なためだった。

画像

上記にある様に「アイデンティティ」の「ポリシー」にて「ポリシーの作成」をクリックし、上記ページに書かれている「ステートメント1」「ステートメント2」を下記画面の「ポリシーステートメント」に貼り付ければOK。(名前と説明は適当につける)

なお、ステートメント2にある「<group>」は「Administrators」に置き換える必要がある。(「アイデンティティ」の「グループ」に登録済みのグループ名に置き換える)

この設定を行ったあと、agent.logへエラーを吐き出していたインスタンス上で「 systemctrl restart oracle-cloud-agent.service 」を実行することでエラーは収まりました。

画像

Oracle CloudのAlways Freeインスタンスを作る際に誤って有料インスタンスを作ってしまいがちな件

他のよくある質問とその答え
・Always Freeインスタンスが作れない件→「Tokyoで作れないのは仕様
・ホームリージョンの変更できるの→「アカウント作成後の変更は不可能
・作ったOracle Linuxインスタンスにsshログインできない件→「インスタンス名に日本語入れてるから」)

Oracle CloudでAlways Freeインスタンスを作成する際、誤って有料のインスタンスを作ってしまうことがある。

例えば、下記の画面だとAlways Freeインスタンスではない。

どこを見ればそれがわかるのか?

上記の「シェイプとタイプ」のところに「常に無料の対象(Always Free対象)」という記載があるかどうかです。

「Always Free対象」である場合は、下記の様に「VM.Standard.E2.1.Micro(仮想マシン)」であることと、その横に「Alwasy Free対象」があります。

Always Free対象の表示が無いので変更するかと「シェイプ、ネットワークおよびストレージオプションの表示」を選択してみましょう。

次の罠が登場です。

「インスタンスタイプ」のところの「仮想マシン」は「Always Free対象」と書かれていますが、「インスタンスのシェイプ」には「Always Free対象」の表記がありません。

正しく「Always Free対象」が選択されている場合は、下記の様にインスタンスのシェイプでもAlways Free対象と表記されています。

Always Free対象となっていない場合は、「シェイプの変更」から変更しましょう。

・・・ないですか?

それは、いまいるリージョンがホームリージョンではないからですね。

右上にあるリージョン切り替えから「ホームリージョン」とかかれたものを選択しましょう。すると下記の様に「Always Free対象」が現れるはずです。

・・・え?

「Japan East(Tokyo)」リージョンだと「Out of host capacity」で作成できないから他のリージョンに変更したい?

残念ながらホームリージョンでしかAlways Free対象とならず、またホームリージョンの変更は不可能とのことです。 (ネタ元 Freedom to Build – Announcing Oracle Cloud Free Tier with New Always Free Services and Always Free Oracle Autonomous Database)

画像

諦めてアカウントを作り直すか、運良く東京に空きができたタイミングで作成できることを期待してインスタンス作成を繰り返してみてください。

Oracle Cloud Always Free Tierはホームリージョンでのみ作成できるが、現在North AmericaとEMEAリージョンでしか作成できない

2021/08/24追記

ドキュメント上は相変わらずAlways Freeはホームリージョンで作成できる、とありますが、ARMプロセッサのインスタンスに関しての記述が緩いな?と思って試してみると、ホームリージョン:Tokyoなんですが、US WestでARMインスタンスが作成作成できてしまいました。

画像

2019/10/04 追記
昨日から東京でもAlways Freeインスタンスの作成に成功するようになりました。
→その後、10/6には作れなくなる。10/8頃から作成可能。10/10には作れなくなる、と頻繁に状況が変わっています


Oracle Cloud Free Tier(“Always Free”,”Free Tier”といろいろ表記があって謎)を使って見ようと、ホームリージョンを日本で設定してみたところ、「Out of host capaticy」という表示で作成できない。

画像

データリージョン一覧ページに「Free Oracle Cloud Promotion is only available in North America and EMEA data regions.」と書かれていたので、North AmericaかEMEAリージョンで作成すればいいのかな?と考えていた。(なお、「Free Oracle Cloud Promotion」と「Always Free」が同じモノを指しているかは不明です)

画像

しかし、ホームリージョン以外では、Always Free(常に無料の対象)となる「VM.Standard.E2.1.Micro」が表示されない。

画像

画像
画像

どういうことかと調べ回ったところ「Freedom to Build – Announcing Oracle Cloud Free Tier with New Always Free Services and Always Free Oracle Autonomous Database」に記載を発見。

画像

「Alwasys Freeはホームリージョンでのみ提供」「アカウント作成時に指定したホームリージョンは変更できない」

twitterを検索すると、東京リージョンでも時々作成に成功することはあるようなので、空きが無くて作れないだけではあるようだ。

はたして東京リージョンで気軽にAlways Freeを使える日は来るのだろうか???