タグ: apache Page 2 of 4

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のサイトが動くようになれば成功。

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

同一サーバ内でRedmineのドメインを変更するときの設定。(apacheバーチャルファイル編集)

ちょっとした事情で、既に稼働しているRedmineのドメインを変更しました。以下、作業メモです。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Redmine 4.2系

前提

  • apacheのバーチャルサイトでRedmineを設定していること。
  • 新しく割り当てるドメインが、稼働サーバと同じであること。
  • 新しいドメインの適切な証明書を取得し、所定の箇所に格納していること。

ここでは、aaa.hoge.comをbbb.hoge.comに変える手順を行います。

さっくりとした手順

  1. バーチャルサイトの設定ファイルをコピーします。(aaa→bbb)
  2. 新たなドメインの設定ファイルを編集します。
  3. 以前の設定ファイルを無効化します。
  4. 新たな設定ファイルを有効化します。
  5. apacheの再起動を行います。
  6. Redmineの設定変更を行います。

手順

設定ファイルコピー

cd /etc/apache2/sites-available && pwd
# 自分の環境に合わせます。

sudo cp -pi aaa.hoge.com.conf bbb.hoge.com.conf
# 設定ファイルは自身の環境に合わせます。

ファイル編集

以下の差分の通り修正します。信仰・教義に沿ったエディタで編集してください。

 <VirtualHost _default_:80>
-servername aaa.hoge.com
+servername bbb.hoge.com

 <VirtualHost _default_:443>
-    servername aaa.hoge.com
+    servername bbb.hoge.com

-SSLCertificateFile /etc/certs/aaa.hoge.com.crt
-SSLCertificateKeyFile /etc/private/aaa.hoge.com.key
+SSLCertificateFile /etc/certs/bbb.hoge.com.crt
+SSLCertificateKeyFile /etc/private/bbb.hoge.com.key
# 証明書と秘密鍵の適切な格納場所を指定します。
# ホスト名のみ変更し、ワイルドカード証明書を利用するのであれば証明書の部分は修正する必要はありません。

変更前設定ファイルの無効化

sudo a2dissite aaa.hoge.com.conf
# サービス再起動を求められますが、最後にまとめて行います。

変更後設定ファイルの有効化

sudo a2ensite bbb.hoge.com.conf

サービス再起動

  • 設定ファイル構文チェック
sudo apache2ctl configtest
# Syntax OKを確認します。
  • サービス再起動
sudo systemctl restart apache2.service

変更後の設定変更

  1. ブラウザで、変更後のドメインにアクセスします。
  2. 管理者権限でログインします。
    • ドメイン以外の設定は変えていないので、ログインは行えます。
    • ビルトインの2段階認証を利用している場合変更前のワンタイムパスワードを利用してください。
  3. 設定→管理に移動します。
  4. 概要タブのホスト名とパスを変更後のものに合わせます。

Apacheで動かしているWebサイトにセキュリティヘッダーを付与。

概要

AWS Lightsailを用いて外部公開しているWebサイトのセキュリティを高めるため、セキュリティヘッダを更に付与しました。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Headerモジュール導入済み

また、/etc/apache2/sites-availavle配下にバーチャルサイトファイルで管理しています。

さっくりとした手順

  1. 現行のバーチャルサイトのコンフィグのバックアップを取得します。
  2. コンフィグにセキュリティヘッダを付与します。
  3. Webサービスの再起動を行います。

実施した手順

バックアップ

cd /etc/apache2/sites-available &&pwd
# 自環境のバーチャルサイトの格納場所に移動します

sudo cp -pi hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# バックアップ元とバックアップ先は自分の環境に合わせます。

diff -u hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# 差分がないことでバックアップが取れていることを確認します。

セキュリティヘッダ追記

教義・進行に沿ったエディタを用いて、以下の差分になるようにセキュリティヘッダをコンフィグに付与します。

+    Header set X-Content-Type-Options "nosniff"
+    Header always append X-Frame-Options "SAMEORIGIN"
+    Header set X-XSS-Protection "1; mode=block"

以下はChantGPTによる解説です。

X-Content-Type-Options: "nosniff"

このヘッダーは、ブラウザがレスポンスのContent-Typeヘッダーと実際のコンテンツの種類が一致しない場合に、ブラウザが自動的にコンテンツのタイプを推測するのを防止します。これにより、悪意のあるコンテンツが実行されるリスクを低減することができます。

X-Frame-Options: "DENY" または "SAMEORIGIN"

このヘッダーは、クリックジャッキング攻撃を防止するために使用されます。"DENY" を指定すると、ページがフレーム内で表示されることが完全に禁止されます。"SAMEORIGIN" を指定すると、同じオリジン(ドメインとプロトコルが一致)のフレーム内でのみページが表示されます。

X-XSS-Protection: "1; mode=block"

このヘッダーは、クロスサイトスクリプティング(XSS)攻撃からの保護を目的としています。ブラウザによって検出されたXSS攻撃が検出された場合、ブラウザはページをブロックするように指示されます。

コンフィグの整合性確認と再起動

  • コンフィグ確認
sudo apache2ctl configtest
#Syntax OKを確認します
  • サービス再起動
sudo systemctl restart apache2.service

systemctl status apache2.service
#Active(running)を確認します

ヘッダ付与確認

  1. Google Chromeを開き、対象のウェブサイトにアクセスします。
  2. ウェブサイトを表示した状態で、右クリックしてコンテキストメニューを表示し、「検証」を選択します。
  3. 開発者ツールが表示されたら、上部のメニューバーの中から「Network」(ネットワーク)タブを選択します。
  4. ページをリロードするか、ウェブサイト上で任意のアクションを実行してネットワークタブにリクエストが表示されるようにします。
  5. ネットワークタブで、対象のリクエストを選択します。
  6. 右側のパネルで、"Headers"(ヘッダー)セクションを展開します。
  7. ヘッダーセクションには、レスポンスヘッダーが表示されるので、以下を確認してください。
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection

ヘッダーが正しく設定されていれば、それぞれのヘッダーの値が表示されます。

Mod_Securityが検知したIPアドレスの自動遮断スクリプト・修正。

以下のスクリプトを修正しました。

このスクリプトの主な動き

  1. Mod_Securityが検知したエラーログからIPアドレスのみを抜き出す。
  2. 重複を排除した上でsuscpicious_ip.YYYYMMDD形式で保存。
  3. 全てのsuscpicious_ip.YYYYMMDDを統合する。
  4. ここからnegativelist.txtを作成する。
  5. negativelist.txtの中に疑陽性(自身のアクセス元)のIPを排除する。
  6. Webサービスを再起動する。

そうして、「一度でもMod_Securityが疑わしいと検知すれば、次回以降のアクセスを許さない」という、言わば“ONE OUTS”システムを採用しています。

この可読性を高めました。

スクリプトが動く前提

  • ApacheとMod_Securityを運用している。
  • 以下のように、「negativelist.txt」に記録されたIP全てをブロックするようにしている。

apacheバーチャルサイト設定の抜粋

# Mod Security
SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
    # ネガティブリスト
    SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"

修正したスクリプト

※ 教義・信仰に沿ったエディタで記載します。

  • negativelist.sh
#!/bin/bash
# このシェルスクリプトは、変数で定義したエラーログからIPアドレスを抽出し、
# suspicious_ipディレクトリに保存し、その後、特定のIPアドレスを削除して
# /etc/apache2/sites-available/negativelist.txtに書き込むものです。

# 読み込むログのディレクトリとファイル名を変数指定
log_dir="/var/lib/redmine/log"
log_file="error.log"

# 除外するIPアドレスをファイルで指定
exclude_ips_file="/path/to/exclude_ips.txt"

# IPアドレスを抽出して重複を排除し、ファイルに保存
cd "$log_dir"
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort | uniq > "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
chown www-data:www-data "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"

# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$log_dir/suspicious_ip/suspicious_ip."2* | sort | uniq > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こす
cat "$log_dir/suspicious_ip_all.txt" > /etc/apache2/sites-available/negativelist.txt

# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
  sed -i "/$exclude_ip/d" /etc/apache2/sites-available/negativelist.txt
done < "$exclude_ips_file"

# Apacheを再起動
systemctl restart apache2.service
  • 除外するIPアドレスリスト

※ 教義・信仰に沿ったエディタで作成します。

  • exclude_ips.txt 記載例
192.168.0.1
172.28.0.1
# 一行ずつ記載

記載後の設定

  • スクリプトの所有者変更
sudo chown root:root negativelist.sh
  • スクリプトの実行権付与
sudo chmod 744 negativelist.sh
  • cron登録
sudo crontab -e -u root
  • cron内容
0 6 * * * /home/manualmaton/bin/negativelist.sh

これによって、スクリプトを変数化。他のサーバへの転用を行いやすくしました。

検証:Ubuntu 20.04にRedmine 5.0のインストールと4.2へのダウングレード。

ふと思い立っての検証です。

あらまし

別サイトに記載しているRedmine4.2のインストール手順。

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/19

この手順で「Redmine 5.0を設定できるか?」と思い立ち、検証用のまっさらなUbuntu 20.04を用意しました。

前提

以下を設定しています。

  • インターネット回線に接続されていること
  • ドメインで名前解決できること
  • SSH接続が可能なこと

実施手順

上記のリンクの手順に沿いました。異なっている点は、Redmine 5.0をダウンロードするため、

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.0-stable /home/www-data/redmine

としただけです。

無事にRedmine5.0が動き、以下の参照どおりにSSLを設定。

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/20

これで試しにと思いましたが、

プラグインとの兼ね合い

「どうしても使いたいプラグインがRedmine 5.0に対応していない」事情により継続利用は無理だと断念。特に

  • knowlegebase
  • redmine_issue_badge_plugin

の2つが利用できないのは非常に痛い状況でした。

Redmine 5.0→4.2へのダウングレード

そこで、インストールしたばかりのRedmine5.0を4.2に即座に戻すことにします。

注意点

この手順は、データが全く入っていない状況で可能な作業です。「こんな手法を採ったのがいる」程度に参照ください。

前提

  • 上記手順を元にRedmine 5.0がインストールされ
  • なおかつデータが何も入っていない
  • RedmineのDB名は「redmine」
  • apache2設定ファイルは稼働済み

さっくりとした手順

  1. apache2サービスを落とします。
  2. データベースをまるごと削除します。
  3. 同じ名前でDBを再作成します。
  4. プログラムを再配置します。
  5. apache2サービスを起動します。

apache2サービス停止

sudo systemctl stop apache2.service
#これを行わないと後述のDBが消去できません

mysqlでDBを再作成します。

sudo mysql -u root -p
DROP DATABASE redmine;
# DBを削除します

CREATE DATABASE redmine character set utf8mb4;
# DB "redmine" を再作成します

exit

Redmineプログラムを再配置します。

sudo rm -rf /home/www-data/redmine
# Redmineを配置したディレクトリごと削除します

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /home/www-data/redmine
# 設定したときと同じディレクトリに4.2を再配置します

Redmineのコンフィグを設定します。

sudo cp -pi /home/www-data/redmine/config/database.yml.example /home/www-data/redmine/config/database.yml

sudo vi /home/www-data/redmine/config/database.yml
# 教義・信仰に従ったエディタで編集してください。

database.yml 編集内容

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  # rootからredmineに変更します
  password: "redmine用のパスワード"
  encoding: utf8mb4
# 本番環境(production)のみ設定を行います

Redmineのマイグレーションを行います。

cd /home/www-data/redmine/ && pwd
# /home/www-data/redmine/ (Redmineを配置したディレクトリ)であることを確認します

sudo -u www-data bundle install --without development test --path vendor/bundle

sudo -u www-data bundle exec rake generate_secret_token

sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate

sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

apache2サービスを起動します

すでにapache上でRedmineを動かす手はずは整っており、プログラムの実行ディレクトリも同じ。ならば、設定ファイルは修正せずに済むという判断のもとに実行。

sudo apache2ctl configtest
# Syntax OK を確認します

sudo systemctl restart apache2.service

systemctl status apache2.service

サイトの表示を確認します。

http://設定したRedmineドメイン

でRedmineのトップページが表示されれば成功です。

検証段階だからこそ行えた手荒な手段でした。

Apacheで特定のアクセス元からの通常アクセスをログに残さない設定。

概要

Webサービスの運用時、「誰がいつどこにアクセスしたか」を判別するアクセスログはとても重要なものです。


ではありますが、Webアクセス解析時に自分のアクセスログが邪魔になるケースがありました。

そこで、Apacheの設定ファイルで特定のアクセス元からのログを残さないようにしました。

確認環境

  • OS : Ubuntu 20.04 LTS
  • Apache 2.4.55

前提

  • 大本のコンフィグ(httpd.conf)ではなくバーチャルサイトで設定していること。
  • Apache設定ファイルに管理者権限で設定ができること。
  • 除外するIP/NWに対し、合意が取れていること。

注意事項

  • この方法でエラーログの除外設定はできません。

実施した手順

ほぼ全てSSHクライアントターミナルからの操作です。

さっくりとした手順

  1. コンフィグのバックアップを取ります。
  2. ログを残さない除外IP/NWを加えます。
  3. コンフィグの整合性を確認し、設定を反映します。
  4. 除外したIP/NWからのアクセスログが出ないことを確認します。

コンフィグ設定

コンフィグのバックアップを取ります。

sudo cp -pi /etc/apache2/sites-available/sites.conf /path/to/backup/directory/sites.conf.$(date +%Y%m%d)
# 自分が設定しているバーチャルサイトのコンフィグ / バックアップディレクトリに合わせます。

diff -u /etc/apache2/sites-available/sites.conf /path/to/backup/directory/sites.conf.$(date +%Y%m%d)
# 差分が無いことでバックアップが取れていることを確認します。

コンフィグファイルを編集します。

sudo vi /etc/apache2/sites-available/sites.conf
# 教義・信仰に従ったエディタで編集してください。
編集例

ここでは、以下の設定とします。

  • 除外IP: 192.168.1.11
  • 除外NW: 192.168.2.0/24
  • アクセスログの格納場所: /var/log/redmine/access.log
    # 以下のIP/NWはアクセスログに記録させません
    SetEnvIf Remote_Addr "192.168.1.11" dontlog
    SetEnvIf Remote_Addr "^192\.168\.2\." dontlog
    CustomLog /var/log/redmine/access.log combined env=!dontlog

保存後、以下のような差分を確認します。

diff -u /path/to/backup/directory/sites.conf.$(date +%Y%m%d) /etc/apache2/sites-available/sites.conf
  • ●差分
+    # 以下のIP/NWはアクセスログに記録させません
+    SetEnvIf Remote_Addr "192.168.1.11" dontlog
+    SetEnvIf Remote_Addr "^192\.168\.2\." dontlog
-    CustomLog /var/log/redmine/access.log combined
+    CustomLog /var/log/redmine/access.log combined env=!dontlog

設定反映

コンフィグの整合性を確認後に設定を反映します。

sudo apache2ctl configtest
# Syntax OKを確認します。

systemctl status apache2.service
# active (running)を確認します。

sudo systemctl restart apache2.service

systemctl status apache2.service
# active (running)を確認します。

動作確認

設定後の動作を確認します。

  • ●アクセスログ確認コマンド発行
tail -f /var/log/redmine/access.log
# 自分の環境(設定したアクセスログ)に合わせます。
  • ●エラーログ確認コマンド発行

※別ターミナルで開きます。

tail -f /var/log/redmine/error.log
# 自分の環境(設定したエラーログ)に合わせます。
  • ●ブラウザで以下を実施
  1. 設定したIP / NWから設定対象のWebサイトにアクセスする。
  2. 設定していないIP / NWから設定対象のWebサイトにアクセスする。
  3. 設定したIP / NWから設定対象のWebサイトにアクセスするがエラーを起こす。(404/403エラーなど)
  4. 設定していないIP / NWから設定対象のWebサイトにアクセスするがエラーを起こす。(404/403エラーなど)

その間、以下をターミナルで開いたアクセスログ/エラーログで確認できれば設定は完了です。

  1. 設定したIP / NWからのアクセスログが出ないこと。
  2. 設定していないIP / NWからのアクセスログが出ること。
  3. 設定したIP / NWからのエラーログが出ること。
  4. 設定していないIP / NWからのエラーログが出ること。

Page 2 of 4

Powered by WordPress & Theme by Anders Norén