タグ: apache Page 1 of 3

Ubuntuサーバのサイト停止とLet’s Encryptの自動更新停止。

ドメイン変更を伴うサーバのサイト移転を行いました。そこで、旧サーバのサイトのみの停止措置を行います。

環境

  • Ubuntu 20.04
  • Apache 2.4のバーチャルサイトを利用
  • Let's Encryptの自動更新を止める

再確認

データの移行が完全に済んでいることを確認します。

手順

設定ファイルを無効化します。

  • ディレクトリ移動
cd /etc/apache2/sites-enabled && pwd
  • 有効化されているサイトの確認
ls -la

sites-le-ssl.confのように、Let's Encryptの自動更新を利用しているサイトにシンボリックリンクが張られていることを確認します。

コマンドによるサイト停止

sites-le-ssl.conf
  • リンクがないことを確認
ls -la

シンボリックリンクがないことを確認します。

旧サイトの設定ファイルを退避します。

  • ディレクトリ移動
cd /etc/apache2/sites-available/ && pwd
  • ファイル退避
sudo mv sites-le-ssl.conf /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)
  • ファイル退避確認
ls -la sites-le-ssl.conf

ファイルがないことを確認します。

ls -la /path/to/backup/directory/sites-le-ssl.conf.$(date +%Y%m%d)

ファイルがあることを確認します。

Apacheを再起動します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス稼働確認
systemctl status apache2.service

active (running)を確認します。

旧サイトにアクセスできないことを確認します。

Let's Encryptの一部の自動更新を無効化します。

sudo certbot delete --cert-name 無効化するドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Deleted all files relating to certificate ドメイン
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

のように、メッセージが出ればOKです。

Ubuntu 24.04のphp環境構築と環境設定。

「Nextcloud等のLAMP環境が動くか」を考慮しながらUbuntu 24.04サーバを構築しています。

そこで、php8.3のインストール及びモジュールの追加を行います。

さっくりとした手順

  1. レポジトリを追加します。
  2. php並びに必要なパッケージを段階的にインストールします。
  3. Nextcloud等で必要になるように設定をしていきます。

レポジトリ追加とアップデート

  • phpレポジトリの追加
sudo add-apt-repository ppa:ondrej/php
  • パッケージ全体のアップデート
sudo aptitude update

段階的なインストール

  • php本体
sudo aptitude install php8.3
  • 周辺モジュール(APCuとMemcached)
sudo aptitude memcached php8.3-apcu
  • Webアプリに必要な周辺モジュール(MySQLを使う場合)
sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • Webアプリに必要な周辺モジュール(Postgresを使う場合)
sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,pgsql,pdo_pgsql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • インストール確認
php -v
PHP 8.3.11 (cli) (built: Aug 30 2024 09:28:18) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.11, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.11, Copyright (c), by Zend Technologies

2024/09/06現在のバージョンです。

OPcacheとAPCuの有効化

Nextcloudはこの設定が無いと警告の対象となります。(或いはエラーが発生します)

  • 設定ファイル待避
sudo mv /etc/php/8.3/mods-available/opcache.ini /path/to/backup/directory/opcache.ini.$(date +%Y%m%d)
sudo mv /etc/php/8.3/mods-available/apcu.ini /path/to/backup/directory/apcu.ini.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • 設定ファイル差し替え
cat <<- __EOF__ | sudo tee -a /etc/php/8.3/mods-available/opcache.ini
; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.3/mods-available/apcu.ini
extension=apcu.so
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__

※ メモリ量などは環境に合わせます。

  • 設定反映
sudo systemctl restart apache2.service
  • Apache稼働確認
systemctl status apache2.service

active (running)を確認します。

Apacheのホームディレクトリを変更。

Ubuntu系LinuxにapacheやnginxといったWebサーバをパッケージ管理システムでインストールすると、通常は

/var/wwwがホームディレクトリとなります。

コンテンツ系を/varに余り入れたくないという好みの問題があるため、ここを変えていきます。

通常、www-dataは/usr/sbin/nologinとなっているためシェルでログインはできませんが、rubyでbundle installを行う際にホームディレクトリを参照するケースがあるため、この措置を執ります。

さっくりとした手順

  1. 新たなホームディレクトリを作成して設定します。
  2. /etc/passwdファイルを書き換えます。

ディレクトリの作成と設定

  • ディレクトリ作成
sudo mkdir -p /home/www-data

運用に合わせます。

  • ディレクトリの所有者変更
sudo chown -R www-data:www-data /home/www-data
  • 設定確認
ls -ld /home/www-data

所有者がwww-dataになっていることを確認します。

passwdファイルの書き換え

※システム全体のアカウントを制御する重要なファイルです。取り扱いは慎重に行ってください。※

  • バックアップ作成
sudo cp -pi /etc/passwd /path/to/backup/directory/passwd.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • バックアップ作成確認
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

エラーがなければバックアップは成功です。

  • ファイル書き換え
sudo sed -i 's|/var/www|/home/www-data|' /etc/passwd
  • 書き換え確認
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

以下の差分を確認します。

-www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
+www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologin

差分がこの2つだけであることを確認できたら設定完了です。

Ubuntu 24.04、Apacheのインストールと初期設定

概要

Ubuntu24.04にWebサーバーApacheをインストールします。最近のトレンドではNginxではあるものの、

  1. 豊富なモジュールとカスタマイズ
  2. 動的コンテンツの設定をしやすい
  3. 小規模サイトを立ち上げる上での手間の少なさ

を考慮してのApache設定です。

さっくりとした手順

  1. Apacheのインストールを行います。
  2. Apacheの設定を行います。
  3. 設定の反映を確認します。

インストールを行います。

  • レポジトリ追加
sudo add-apt-repository ppa:ondrej/apache2
  • パッケージ全体のアップデート
sudo aptitude update 
  • apacheのインストール
sudo aptitude install apache2
  • バージョン確認
apache2ctl -v
Server version: Apache/2.4.62 (Ubuntu)
Server built:   2024-07-22T12:37:10
  • サービス稼働確認
systemctl status apache2.service

enabledactive (running)を確認します。

設定を行います。

  • 設定ファイルのバックアップ
sudo cp -pi /etc/apache2/apache2.conf /path/to/backup/directory/apache2.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • 設定ファイルのバックアップ確認
diff -u /path/to/backup/directory/apache2.conf.$(date +%Y%m%d) /etc/apache2/apache2.conf

差分が無いことでバックアップを確認します。

  • 設定ファイル追記
sudo tee /etc/apache2/apache2.conf > /dev/null << 'EOF'
ServerSignature Off
ServerTokens Prod
ServerName 自分のサーバー名
EOF

自分のサーバー名を英数字で置き換えてください。

  1. サーバーの署名をオフにして
  2. 最小限の情報のみを公開し
  3. Webサーバの名前を指定する

内容です。

  • 追記確認
diff -u /path/to/backup/directory/apache2.conf.$(date +%Y%m%d) /etc/apache2/apache2.conf
  • 差分内容
+ ServerSignature Off
+ ServerTokens Prod
+ ServerName 自分のサーバー名

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active (running)を確認します。

  • 設定反映確認
curl -I http://localhost

以下のように、ServerヘッダーにApacheのみが表示されていることを確認します。

Server: Apache

Ubuntu20.04サーバにApacheのDoS対策モジュール(mod_evasive)を導入。

概要

DoS/DDoS対策ができるモジュールをApacheに導入したときのメモです。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • FWにufwを利用

さっくりとした手順

  1. mod_evasiveモジュールをインストールします。
  2. apache2実行ユーザー(www-data)がufwを利用できるように設定します。
  3. mod_evasiveモジュールの設定をします。
  4. 設定の反映を行います。

まずはサーバにターミナルログインするところから始めます。

mod_evasiveのインストール

sudo aptitude install libapache2-mod-evasive

このとき、postfixが依存関係でインストールされる場合があります。メール機能が使えない(AWS等で送信が制限されているなど)は、途中の設定で「何もしない」を選択します。

apache2実行ユーザーの権限変更

これは、www-dataがufwを実行する場合の処理です。権限昇格の危険性を承知した上で、慎重に作業を行ってください。

  • sudoersファイルのバックアップ
sudo cp -pi /etc/sudoers /path/to/backup/directory/sudoers.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • diffによるバックアップ確認
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers

差分がないことを確認します。

  • ファイル追記
echo 'www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw' | sudo tee -a /etc/sudoers
  • ファイル追記確認
sudo diff -u /path/to/backup/directory/sudoers.$(date +%Y%m%d) /etc/sudoers

以下の差分を確認します。

+www-data ALL=(ALL) NOPASSWD: /usr/sbin/ufw

evasiveの設定変更

  • ファイルバックアップ
sudo cp -pi /etc/apache2/mods-available/evasive.conf /path/to/backup/directory/evasive.conf.$(date +%Y%m%d)
  • diffによるバックアップ確認
sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf

差分がないことを確認します。

  • 以下のファイルを教義・信仰に沿ったエディタで編集していきます。
    • /etc/apache2/mods-available/evasive.conf
  • 編集例
    DOSHashTableSize    3097
    DOSPageCount        100
    DOSSiteCount        100
    #かなり緩く設定して、後で狭めていった方が偽陽性を防げます。
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10

    #DOSEmailNotify      you@yourdomain.com
    #メール通知を行わないため、ここを省いています
    DOSSystemCommand    "sudo ufw deny proto tcp from %s to any port 80,443"
    # 検証時に自分のサイトがブロックされるのを防ぐため、ポートは80/443に絞っています
    DOSLogDir           "/var/log/mod_evasive"
    DOSWhitelist        127.0.0.1
    DOSWhitelist        xx.xx.xx.xx
    # 対象外としたいIPアドレス(自分の環境など)

参考:Apache の DoS攻撃対策モジュール mod_evasive

  • 設定編集確認
sudo diff -u /path/to/backup/directory/evasive.conf.$(date +%Y%m%d) /etc/apache2/mods-available/evasive.conf
  • 差分例
-    #DOSHashTableSize    3097
-    #DOSPageCount        2
-    #DOSSiteCount        50
-    #DOSPageInterval     1
-    #DOSSiteInterval     1
-    #DOSBlockingPeriod   10
+    DOSHashTableSize    3097
+    DOSPageCount        100
+    DOSSiteCount        100
+    DOSPageInterval     1
+    DOSSiteInterval     1
+    DOSBlockingPeriod   10

     #DOSEmailNotify      you@yourdomain.com
-    #DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
-    #DOSLogDir           "/var/log/mod_evasive"
+    DOSSystemCommand    "sudo ufw deny proto tcp from %s to any port 80,443"
+    DOSLogDir           "/var/log/mod_evasive"
+    DOSWhitelist        127.0.0.1
+    DOSWhitelist        xx.xx.xx.xx
 </IfModule>

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • apache再起動
sudo systemctl restart apache2.service

これで、不審なアクセスが大量にあったときにufwで弾く体制が整いました。

Growi v7でページ編集時に空白になる問題に対処(Apache リバースプロキシのWebSocket設定)

事象の内容

  • Growiのバージョンをv6.3.5→v7.0.11にアップグレード後、既存のページを編集しようとすると編集エリアが空白になってしまう。
  • 新規ページを作成する際に、テンプレートが適用されない。

先のエントリーで述べたようにWikiとしては致命的な弱点だったため、やむなくv6.3.5に戻したという経緯があります。

ですが、回避策が見つかりましたのでメモとして残します。

事象が発生した環境

  • Ubuntu 22.04
  • Apache 2.4
  • Growi v7.0.11をDockerではなくオンプレ環境で利用。
  • Apacheによるリバースプロキシを設定

同一事象をネットで確認。

How to reproduce? (再現手順)

2台のHostPCでそれぞれGrowiを立ち上げています。A環境・B環境と呼称します。

「データ移行」機能を用いて、A環境からB環境にデータをインポートする
B環境のGrowiに他のPCからアクセスする
記事の編集画面を表示する

What happens? (症状)

記事の編集画面が白紙になっており、そのまま保存しても記事の内容が失われる(添付画面参照)

と、事象が一致。

事象の原因

上記issueのツリーに

私の環境でも編集画面が空白になる現象が観測されました。

私は https-portal を使ってデプロイしているのですが、 growi-docker-compose/examples/https-portal にある WEBSOCKET: 'true' の環境変数を設定し損ねていたのが原因でした。
私の環境では、これを設定すると通常通り編集を行えることを確認しております。逆に、コメントアウトすると空白に戻ります。

とあります。

これを原因と断定し、対処に臨みます。

対応方法のさっくりとした手順

  1. 現状のgrowiのリバースプロキシの設定を確認。
  2. 設定ファイルのバックアップ。
  3. 設定ファイルを修正。
  4. 修正を反映。
  5. 事象の解決確認。

参考にしたURL

How to Reverse Proxy Websockets with Apache 2.4

現段階でのリバースプロキシの設定を確認します。

  • Apacheのバーチャルファイルを確認
cat /etc/apache2/sites-available/growi.conf

自分の環境に合わせます。

  • 内容の一部抜粋
    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]

    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/

設定そのものはgithubのgrowi公式ドキュメントに沿ったものでしたが、これが引っかかっていたようです。

設定ファイルのバックアップを取ります。

  • バックアップ
sudo cp -pi /etc/apache2/sites-available/growi.conf /path/to/backup/directory/growi.conf.$(date +%Y%m%d)

ファイル名は自分の環境に合わせます。適宜、任意のバックアップディレクトリを指定します。

  • バックアップ確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf

差分が無いこと(エラーがないこと)でバックアップを確認します。

ファイルを修正します。

上記、バックアップを取ったファイルを教義・信仰に沿ったエディタで編集します。(要管理者権限)

  • 削除する内容
    # socket.io の path を rewrite する
    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /(.*) ws://localhost:3000/ [P,L]
  • 削除した箇所に追記する内容
     # WebSocketのための設定
     RewriteEngine On
     RewriteCond %{HTTP:Upgrade} =websocket [NC]
     RewriteCond %{HTTP:Connection} upgrade [NC]
     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

編集後、差分を取ります。

  • 差分確認
diff -u /path/to/backup/directory/growi.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi.conf
  • 差分結果
-    # socket.io の path を rewrite する
-    RewriteEngine On
-    RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
-    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
-    RewriteRule /(.*) ws://localhost:3000/ [P,L]
+     # WebSocketのための設定
+     RewriteEngine On
+     RewriteCond %{HTTP:Upgrade} =websocket [NC]
+     RewriteCond %{HTTP:Connection} upgrade [NC]
+     RewriteRule /(.*) ws://localhost:3000/$1 [P,L]

設定を反映します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動前確認
systemctl status apache2.service

active (running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active (running)を確認します。

事象の解決を確認します。

上記、設定を行ったGrowiサイトにアクセスします。

編集後、左ペイン(エディタ部分)がそのまま残っていれば対処完了です。

apacheで特定のユーザーエージェントからのアクセスを拒否。

概要

自分のサーバのアクセスログを見たら

"GET /picture.php?/6797/category/73 HTTP/1.1" 200 14394 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

と、クローラーが大量にアクセスしてきました。robots.txtも意に介さない悪名高いbotのようなので、このアクセスを、サーバで拒否します。

環境

  • Ubuntu 20.04
  • Apache 2.4 (aptでインストールしたため、ディレクトリは/etc/apache2配下にあります。

また、バーチャルサイトによる複数のサイトを運用しているので、そのうちの1つだけを弾きます。

さっくりとした手順

  1. Apacheのバーチャルサイトの設定ファイルのバックアップを取ります。
  2. 設定ファイルを追記します。
  3. 設定を反映します。
  4. 拒否されていることを確認します。

設定ファイルのバックアップ

  • ディレクトリ移動
cd /etc/apache2/sites-available && pwd
  • ファイルバックアップ
sudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定を行いたい自分の設定ファイルを、任意のバックアップディレクトリにバックアップします。

  • バックアップ確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf

差分が無ければ(エラーがなければ)バックアップは成功です。

設定ファイル追記

上述した設定ファイルを教義・進行に則ったエディタで編集します。(要管理者権限)

  • 追記例
    DocumentRoot /var/www/html/hoge
    <Directory /var/www/html/hoge>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
     SetEnvIfNoCase User-Agent "Googlebot" bot
     ## Facebookのクローラーを拒否
     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
     <RequireAll>
      Require all granted
      Require not env bot
      Require not env fb_bot
     </RequireAll>

/var/www/html/hogeは自分の環境に合わせます。

※ついでにGoogleBOTも拒否します。

  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
  • 差分例
-        Require all granted
+     ## GoogleBOTを拒否(正常bot不正bot両方拒否)
+     SetEnvIfNoCase User-Agent "Googlebot" bot
+     ## Facebookのクローラーを拒否
+     SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" fb_bot
+     <RequireAll>
+      Require all granted
+      Require not env bot
+      Require not env fb_bot
+     </RequireAll>

設定反映

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動確認
systemctl status apache2.service

active(running)を確認します。

設定反映確認

設定を行ったアクセスログを開きます。

403 3772 "-" "facebookexternalhit/1.1 

のように、ステータスコードが「403」になっていれば、アクセス拒否されています。

Ubuntu 20.04 / 22.04で稼働しているApache HTTP Server 2.4の脆弱性対応。

2024年4月に発表された脆弱性への対処を行います。

脆弱性内容

  • Apache HTTP Serverのコア機能におけるHTTPレスポンス分割の問題(CVE-2023-38709)
  • 複数のモジュールにおけるHTTPレスポンス分割の問題(CVE-2024-24795)
  • HTTP/2 CONTINUATIONフレームの検証不備に起因したメモリ枯渇の問題(CVE-2024-27316)

https://jvn.jp/vu/JVNVU99032532

環境

  • Ubuntu 20.04 および Ubuntu 22.04
  • Apache 2.4系を利用

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

Apacheのバージョンアップを行います。

  • パッケージ全体のアップデート
sudo aptitude update
  • パッケージのアップグレード
sudo aptitude upgrade

このリストの中にapache2とapache2関連パッケージが更新される(2024/04/10現在)ため、それぞれアップグレードを行います。

バージョンアップを確認します。

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

対応を行った日付

2024/04/10

ApacheコンフィグファイルによるIP拒否。(アドレスべた書き)

概要

WordPressなどの特定のディレクトリに対して攻撃を仕掛けてくるIPアドレスやNWをブロックする方法についてメモします。

環境

以下で動作を確認しました。

  • Ubuntu 20.04
  • Apache 2.4
  • /etc/apache2/site-available/example.confなど、バーチャルサイトを利用

さっくりとした手順

  1. バーチャルサイトのコンフィグのバックアップを取ります。
  2. コンフィグを追記します。
  3. 設定を反映します。
  4. 動作を確認します。

コンフィグファイルのバックアップ

  • ディレクトリ移動
/etc/apache2/sites-available && pwd
  • バックアップ
sudo cp -pi example.conf /path/to/backup/directory/example.conf.$(date +%Y%m%d)

バックアップするファイルやディレクトリは自分の環境に合わせます。

  • バックアップ確認
diff -u example.conf /path/to/backup/directory/example.conf.$(date +%Y%m%d)

バックアップがなければ(エラーがなければ)バックアップはできています。

コンフィグの追記

  • /etc/apache2/site-available/example.conf

以下のように追記します。

<Directory "/var/www/html/example">
    <RequireAll>
        Require all granted
        Require not ip 192.168.1.1
    </RequireAll>
</Directory>

拒否対象のディレクトリや、IPアドレスは対象に合わせて修正してください。

動作確認に万全を期すなら、自分が用意できるアクセス元のIPアドレスを指定します。(その後、設定を削除します)

  • 追記後の差分確認
diff -u /path/to/backup/directory/example.conf.$(date +%Y%m%d) /etc/apache2/site-available/example.conf

上記の追記内容が出ていることを確認します。

設定反映

  • 設定ファイル確認
sudo apache2ctrl configtest

SyntaxOKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service

反映確認

  • 対象ディレクトリがあるサイトにアクセスして、通常にアクセスできることを確認。
  • 自分が用意できるアクセス元のIPアドレスを指定しているなら、そこからのアクセスができないことを確認。

今後の対応

  • ネガティブリストではなくポジティブリストでの運用
  • 別ファイルの参照

など、改良していきます。

Tips:apacheバーチャルサイトのオフオン(切り替え)

ちょっとした小技が役立ったのでメモに残しておきます。

環境

  • Ubuntu 20.04系
  • Apache 2.4系

で、バーチャルサイトでサイトを検証していました。

背景

検証で動かしているWebアプリAがaaa.hoge.comで動いていました。

そこに、同じ環境でWebアプリBを動かす需要がありました。

本来なら、DNSで

  • aaa.hoge.com
  • bbb.hoge.com

とするところ、

  • DNS登録が間に合わない
  • 2つ同時に動かせるようなスペックではない

という背景がありました。そこで、「一度WebアプリAを無効にしつつ、WebアプリBをaaa.hoge.com」として動かすようなすり抜けを使いました。

さっくりとした手順

  1. WebアプリAの設定ファイルを無効化します。
  2. WebアプリBの設定ファイルを作成します。
  3. WebアプリBを有効にします。

前に動いているサイトの無効化

sudo a2dissite app_a.conf

sudo systemctl restart apache2.service

WebアプリB用の設定ファイル作成

  • /etc/apache2/sites-available/app_b.conf

に以下のように作っていきます。

略
<VirtualHost *:443>
    # ドメイン名を指定します
    ServerName aaa.hoge.com
    # アプリB用のログディレクトリを指定します。
    CustomLog /var/log/nextcloud/nextcloud_access.log combined
    ErrorLog /var/log/nextcloud/nextcloud_error.log

    # アプリB用のドキュメントルートディレクトリを指定します。
  # アプリAno参照ドキュメントとは違うディレクトリにします
    DocumentRoot /home/www-data/nextcloud
    <Directory /home/www-data/nextcloud>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>
略

サイトBを有効化します。

sudo a2ensite app_b.conf

sudo apache2ctl configtest

sudo systemctl restart apache2.service

動作を確認します。

aaa.hoge.com(など、今までアプリAが動いていたサイトのドメインで)アプリBのサイトが動くようになれば成功。

一時的な手段ではありますが、効果はありました。

Page 1 of 3

Powered by WordPress & Theme by Anders Norén