5年ぐらい前に買っておいて3年前に故障。その後、長らく使っていなかったアイテムを新調しました。
こちらの撮影台。
折りたたみ式で、
展開、セットアップすると天井のライトと反射板で覆われた撮影ボックスになります。
早速、撮影してみました。
- 構図決めが楽になった
- より強い光で、1/6でも捉えやすくなった
が利点ですが、上から光が降り注ぐ関係上、顔に影が着くのが問題。ここをすこし直していくのが課題です。
概要
Ubuntu24.04にリポジトリを利用して追加したnginxは、apacheのようにバーチャルサイトが最初から備わっていませんでした。
そこで、その設定を施します。
バーチャルサイトの設定ファイル格納ディレクトリの作成
sudo mkdir -p /etc/nginx/sites-availablesudo mkdir -p /etc/nginx/sites-enabledls -ld /etc/nginx/sites*sites-availableとsites-enabledディレクトリがあることを確認します。
バーチャルサイト有効化
- ファイルバックアップ
sudo cp -pi /etc/nginx/nginx.conf /path/to/backup/directory/nginx.conf.$(date +%Y%m%d)任意のバックアップディレクトリを指定します。
- ファイルバックアップ確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf差分がなければバックアップは成功です。
- ファイル書き換え
sudo sed -i '/http {/a \ include /etc/nginx/sites-enabled/*;' /etc/nginx/nginx.conf- ファイル書き換え確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf以下の差分を確認します。
+ include /etc/nginx/sites-enabled/*;サンプルのhtmlファイルを作る
ファイル格納ディレクトリは自分の環境に合わせます。
sudo -u www-data tee /home/www-data/index.html > /dev/null <<EOL
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Welcome to example.com</title>
</head>
<body>
<h1>Welcome to example.com!</h1>
<p>This is a sample page served by Nginx.</p>
</body>
</html>
EOLサンプルのバーチャルサイトを作成する
ファイル名やserver_nameは自分の環境に合わせます。
- 設定ファイル作成
sudo tee /etc/nginx/sites-available/sample.conf > /dev/null <<EOL
server {
listen 80;
server_name example.com www.example.com;
root /home/www-data;
index index.html index.htm;
location / {
try_files \$uri \$uri/ =404;
}
# セキュリティ設定
# サーバー情報を隠す
server_tokens off;
# MIMEタイプの設定
include /etc/nginx/mime.types;
default_type application/octet-stream;
# XSS対策
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
# ファイルのアップロードサイズ制限
client_max_body_size 1M;
# ログの設定
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
}
EOL設定ファイル有効化
- シンボリックリンク作成
sudo ln -s /etc/nginx/sites-available/sample.conf /etc/nginx/sites-enabled/- 構文確認
sudo nginx -tnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
を確認します。
- サービス再起動
sudo systemctl restart nginx.service設定したURLでアクセスできることを確認します。
これで、バーチャルサイトが設定されました。
概要
好みはapacheではありますが、セットアップしたばかりのUbuntuサーバの性能を鑑みてnginxを入れていきます。
さっくりとした手順
- インストールに必要なパッケージを入れます。
- nginxのリポジトリーを追加します。
- インストールを行います。
- 基本的な設定を行います。
必要なパッケージの導入とリポジトリー追加
- 必要なパッケージの導入
sudo aptitude install curl gnupg2 ca-certificates lsb-release- リポジトリ追加
echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -cs) nginx" | sudo tee /etc/apt/sources.list.d/nginx.listcurl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -nginxインストール
- パッケージのアップデート
sudo aptitude update- nginxインストール
sudo aptitude install nginx- インストール確認
nginx -vnginx version: nginx/1.26.2を確認します。(2024/10/25現在)
- サービス起動
sudo systemctl start nginx.service- サービス起動確認
systemtl status nginx.serviceactive(running)を確認します。
初期設定(オプション)
ここからは筆者の好みの問題です。
オプション:nginxの実行をwww-dataに変更する
- ファイルバックアップ
sudo cp -pi /etc/nginx/nginx.conf /path/to/backup/directory/nginx.conf.$(date +%Y%m%d)任意のバックアップディレクトリを指定します。
- ファイルバックアップ確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf差分がなければバックアップは成功です。
- ファイル書き換え
sudo sed -i 's/user nginx;/user www-data;/g' /etc/nginx/nginx.conf- ファイル書き換え確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf以下の差分を確認します。
-user nginx;
+user www-data;- サービス再起動
sudo systemctl restart nginx.service- サービス再起動確認
systemctl status nginx.serviceactive(running)`を確認します。
オプション:Web格納ディレクトリを作成する
- web格納ディレクトリを作成
sudo mkdir -p /home/www-datasudo chown -R www-data:www-data /home/www-datasudo chmod -R 755 /home/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つだけであることを確認できたら設定完了です。
備考
この手順ではnginxのバーチャルサイトまではサポートしていないので、後述します。
apacheのバーチャルファイルにセキュリティ設定を追加します。
バーチャルサイトの設定ファイルバックアップ
- バックアップ
sudo cp -pi /etc/apache2/sites-avaiable/wordpress.conf /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d)ファイル及びバックアップディレクトリは自分の環境に合わせます。
- diffによる差分確認
diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.confエラーがなければバックアップは成功です。
バーチャルサイトの設定ファイル編集
DocumentRootの項目に、以下のように編集します。/home/www-data/wordpressの部分は自分の環境に合わせます。
ここでは、サーバのリソースを食い潰し、robots.txtを無視するクローラーを止めることにしています。
また、こういったクローラーであることを隠し、ユーザーエージェントを偽装するIPもレンジでブロックしています。
DocumentRoot /home/www-data/wordpress
<Directory /home/www-data/wordpress>
Options -Indexes
Options FollowSymLinks
AllowOverride All
## スパムクローラーを拒否
SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" spam_crawler
SetEnvIfNoCase User-Agent "SemrushBot/7~bl" spam_crawler
SetEnvIfNoCase User-Agent "AhrefsBot" spam_crawler
SetEnvIfNoCase User-Agent "MJ12bot" spam_crawler
SetEnvIfNoCase User-Agent "DotBot" spam_crawler
SetEnvIfNoCase User-Agent "Baiduspider" spam_crawler
SetEnvIfNoCase User-Agent "YandexBot" spam_crawler
SetEnvIfNoCase User-Agent "Sogou web spider" spam_crawler
SetEnvIfNoCase User-Agent "Exabot" spam_crawler
SetEnvIfNoCase User-Agent "MegaIndex.ru" spam_crawler
SetEnvIfNoCase User-Agent "SeznamBot" spam_crawler
SetEnvIfNoCase User-Agent "BLEXBot" spam_crawler
SetEnvIfNoCase User-Agent "Bytespider" spam_crawler
SetEnvIfNoCase User-Agent "DataForSeoBot" spam_crawler
SetEnvIfNoCase User-Agent "serpstatbot" spam_crawler
SetEnvIfNoCase User-Agent "SeekportBot" spam_crawler
SetEnvIfNoCase User-Agent "index.community crawler" spam_crawler
SetEnvIfNoCase User-Agent "PetalBot" spam_crawler
<RequireAll>
Require all granted
##スパムクローラーを拒否
Require not env spam_crawler
#偽装エージェントを拒否
Require not ip 190.92.0.0/16
Require not ip 159.138.0.0/16
Require not ip 166.108.0.0/16
Require not ip 124.243.0.0/16
Require not ip 114.119.0.0/16
Require not ip 119.8.0.0/16
Require not ip 110.238.0.0/16
Require not ip 217.113.194.0/24
Require not ip 34.123.0.0/16
</RequireAll>
## 設定ファイルのアクセス拒否
<Files wp-config.php>
Require all denied
</Files>
<Files xmlrpc.php>
Require all denied
</Files>
## キャッシュを有効
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</Directory> <Files xmlrpc.php>
Require all denied
</Files>は運用に合わせて無効化の可否を決めてください。
- モバイルアプリからのリモート投稿ができなくなります。
- ピンバックとトラックバックを受け付けることができなくなります。
- Jetpackの一部機能が動作しなくなります。
- その他、リモート投稿や自動投稿のプラグインが影響を受けます。
編集後、
diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.confとして、上記の差分が出ることを確認します。
設定反映
- 設定有効
sudo a2ensite wordpress.conf→ 一時的に無効にしている場合
- 構文確認
sudo apache2ctl configtestSyntax OKを確認します。
- Apache2再起動
sudo systemctl restart apache2.serviceその後、Wordpressが正常に閲覧できることを確認します。
確認後、追加のセキュリティ設定を行わないのであれば、
sudo a2dissite wordpress.confsudo systemctl restart apache2.serviceとして、無用な攻撃を防ぎます。
概要
CMSの代名詞、Wordpressをきちんとした手順で書いていなかったのでこの機会にメモを残します。
手順が比較的簡単なだけに狙われやすいのも納得。
なので、ここではインストールだけではなく、セキュリティ対策を含めて実施します。
環境
- Ubuntu 24.04
- Apache 2.4
- MySQL
- PHP 8.3
前提
- Apacheの初期設定は完了しています。
- mod_securityが稼働しています。
- 適切に名前解決できることが条件です。（DNS設定済み）
- 証明書は適切なものを準備済みです。
さっくりとした手順
- WordPress用のデータベースを作成します。
- WordPressのプログラムを配置します。
- WordPressをWebサービスで動かす設定を行います。
- WordPressをブラウザでインストールします。
- インストール後、一度、設定を解除します。
※Wordpressは非常に狙われやすいWebアプリです。そのため、安定稼働するまでは設定をするたびにWebサービスから切り離します。
DB作成
- MySQLログイン
mysql -u root -p- DB作成
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;DB名(mt)は自分の環境に合わせます。
- ユーザー作成
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'your_password';ユーザー(wpuser)やパスワードは自分の環境に合わせます。適正なパスワードを設定してください。
- 権限委譲
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';- 設定反映、MySQLログアウト
FLUSH PRIVILEGES;exit作成したDB確認
- MovableTypeのユーザーでログイン
mysql -u wpuser -p- DB確認
SHOW DATABASES;WordPressのDBがあることを確認します。
- DB切り替え
use wordpress;- DBの文字コード確認
SHOW VARIABLES LIKE 'character_set_database';Valueがutf8mb4であることを確認
- DBの照合順序確認
SHOW VARIABLES LIKE 'collation_database';Valueがutf8mb4_binであることを確認
exitWordPress取得
- 作業ディレクトリに移動
cd /hoge && pwd任意のディレクトリを指定します。
- wget
wget https://wordpress.org/latest.tar.gz- ファイルの解凍
tar -xzvf latest.tar.gz- ファイルの所有権変更
sudo chown -R www-data:www-data wordpress- www-dataディレクトリに移動
sudo mv wordpress /home/www-data/wordpress自分の環境に合わせます。
WordPressWebサイト設定編集
ログ格納用のディレクトリ作成
- ログ格納ディレクトリ作成
sudo mkdir -p /var/log/wordpress- ログ格納ディレクトリの所有者変更
sudo chown www-data:www-data /var/log/wordpressWordPressのバーチャルサイト作成
/etc/apache2/site-available配下に、wordpress.confを管理者権限で作成し、以下のように編集していきます。
<VirtualHost *:80>
# ドメイン名を指定します
servername hoge.example.com
# HTTPアクセスを強制的にHTTPSにリダイレクトします
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
# ドメイン名を指定します
ServerName hoge.example.com
CustomLog /var/log/wordpress/wp_access.log combined
ErrorLog /var/log/wordpress/wp_error.log
# WordPressを配置したディレクトリを指定します。
DocumentRoot /home/www-data/wordpress
<Directory /home/www-data/wordpress>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
#セキュリティヘッダー付与
Header always set Strict-Transport-Security "max-age=63072000"
Header set X-Content-Type-Options "nosniff"
Header always append X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
#SSL設定
SSLEngine on
Protocols h2 http/1.1
SSLCertificateFile /path/to/ssl/certificate.crt
SSLCertificateKeyFile /path/to/ssl/private.key
# 証明書と秘密鍵のパスを指定します
# Mod_Security設定
SecRuleEngine DetectionOnly
# Webでインストールを行うため、最初は検知モードに設定します。
## ファイルのアップロードをできるようにします。
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## テスト用の検知パラメーター
SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
</VirtualHost>
# これらのセクションはSSL暗号化強度を高めるための記述です
# </VirtualHost>の外側に書くことにご注意ください
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC6-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"設定ファイル有効化
- コンフィグ読み込み
sudo a2ensite wordpress.conf- 構文確認
sudo apache2ctl configtestSyntax OKを確認します。
- Webサービス再起動
sudo systemctl restart apache2.service- Webサービス再起動確認
systemctl status apache2.serviceブラウザから確認
ブラウザで設定したURLにログインします。
インストール画面が出てきます。言語を選びContinueをクリックします。
ボタンをクリックします。
設定したDB名、ユーザー、パスワードを入力します。
DBと接続されると、以下が表示されます。インストール実行をクリックします。
サイト名などを入れていきます。
ここまで出たらOKです。
インストール後の処理（一時停止）
圧倒的なシェアを誇るWordpressは攻撃者が真っ先に狙うサービスです。
そのため、安定稼働するまでは確認後に一度停止して、物理的なアクセスを防ぎます。
- バーチャルサイトの設定ファイル無効化
sudo a2dissite wordpress.conf- 構文確認
sudo apache2ctl configtestSyntax OKを確認します。
- Webサービス再起動
sudo systemctl restart apache2.service- Webサービス再起動確認
systemctl status apache2.service無効化後、上記の設定ファイルで指定したURLにアクセスできないことを確認します。
ヘッダーに別のサイトのリンクがほしいときは割とあるので、そのメモです。
動作環境
- Redmine 4.2 /5.0/5.1
- view_customize_pluginがインストール済み
コード
「新しい表示のカスタマイズ」で
- パスのパターン：空白
- プロジェクトのパターン：空白
- 挿入位置：ヘッダー
- 種別：JavaScript
で、以下のように入力。
$(document).ready(function(){
// メニューの準備
const menus = `
<li><a href="https://manualmaton.com" rel="noopener noreferrer">WordPress(manualmaton.com)</a></li>
<li><a href="http://barrel.reisalin.com" target="_blank" rel="noopener noreferrer">BookStack(Barrel Gazer)</a></li>
`;
// 追加する
$('#top-menu>ul').append(menus);
});こうすることで、Redmineのヘッダーに
このようにリンクが追加されます。
WebARENAにて新たなWebサービスを立ち上げようと思ったものの大失敗。
ちょっとハマってしまったので切り戻し。
しかし、同一サーバで稼働させているNextcloud上で、この謎の状況が起きました。
ロケールを en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 に設定できませんでした
これらのロケールのうちいずれかをシステムにインストールし、Webサーバーを再起動してください。
localectl を実行しても
System Locale: LANG=ja_JP.UTF-8
LANGUAGE=ja_JP:ja
VC Keymap: (unset)
X11 Layout: us
X11 Model: pc105と、正常な状況です。
何が起きたか？
新たに
- perl
- CGI
などを動かそうとパッケージをうにゃうにゃしていたときにこれが起きてしまったようです。
復旧
「転ばぬ先の杖」が功を奏しました。作業前にとっておいたスナップショットにより、作業前の状況に切り戻し。さながら「逆転時計(タイムターナー)」を起動させた気分です。
- DB
- データ
はバックアップを取ることで復旧できますが、新たなパッケージを動かしたときのようにシステム深奥まで影響を及ぼすような作業は全体のバックアップを取ることを学んで助かったという心境です。
Apacheのアクセスログを調査するとき何かと使うのでメモです。
アクセスログからIPのみを抽出してカウント
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "/var/log/apache/access.log" | sort -u 表示例
3 xxx.xxx.xxx.xxx
2 yyy.yyy.yyy.yyy
1 zzz.zzz.zzz.zzzと、煩雑なその他のログを探すことなく件数とIPをカウントします。
更にステータスコードも表示
awk 'match($0, /[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { ip = substr($0, RSTART, RLENGTH) } match($0, /" [0-9]{3} /) { status = substr($0, RSTART+2, 3); print ip, status }' /var/log/apache/access.log | sort | uniq -c | sort -nr表示例
5 xxx.xxx.xxx.xxx 200
3 yyy.yyy.yyy.yyy 404
2 zzz.zzz.zzz.zzz 500ステータスコードが入るので、アクセス制御の有無やそれを突破してきたIPも調べられます。
概要
過剰なWebクローラーによりサーバのパフォーマンスが落ちることがあるため、mod_dosdetectorを入れてみます。
mod_dosdetector は、Apache HTTP Server 用のモジュールで、DoS（Denial of Service）攻撃を検出し、対策を講じるためのものです。このモジュールは、特定のIPアドレスからの過剰なリクエストを監視し、しきい値を超えた場合にそのIPアドレスを一時的にブロックすることで、サーバーのリソースを保護します。
Ubuntu 20.04にはこちらを入れましたが、
- ufwとの連携でサーバに負荷がかかる
- 細かい設定が可能
ということで、こっちをUbuntu 24.04に入れてみます。
環境
- Ubuntu 24.04
- Apache 2.4
- Apache2-devがインストールされていることが前提です。
さっくりとした手順
- gitでソースをダウンロードします。
- Makefileを書き換えた上でインストールします。
- 設定ファイルを作成します。
- 設定を有効化し、Apacheを再起動します。
mod_dosdetectorのダウンロード
- ソース格納ディレクトリに移動
cd /usr/local/src && pwd自分の環境に合わせます。
- git clone
sudo git clone https://github.com/stanaka/mod_dosdetector.git- 展開したディレクトリに移動
cd mod_dosdetector && pwdMakefileの書き換えとインストール
- Makefile修正
デフォルトのMakefileは/usr/sbin/apxsとなっているため書き換えます。
sudo sed -i 's|^APXS=.*|APXS=/usr/bin/apxs|' Makefile- インストール
sudo make install- インストール確認
cat /etc/apache2/mods-available/dosdetector.loadLoadModule dosdetector_module /usr/lib/apache2/modules/mod_dosdetector.soと表示されます。
設定ファイル追加
参考: mod_dosdetectorを使ってみましょうよ。～挫折を乗り越え～
sudo tee /etc/apache2/mods-available/dosdetector.conf > /dev/null <<EOF
<IfModule dosdetector_module>
DoSDetection on
DoSPeriod 60
DoSThreshold 5
DoSHardThreshold 10
DoSBanPeriod 60
DoSTableSize 100
DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
</IfModule>
EOF- DoSDetection on
- 説明: DoS (Denial of Service) 検出を有効にします。
- DoSPeriod 60
- 説明: DoS攻撃を検出するための監視期間を秒単位で指定します。
- DoSThreshold 5
- 説明: DoS攻撃と見なすリクエストの閾値を指定します。
- DoSHardThreshold 10
- 説明: より厳しい閾値を指定します。
- 60秒間に同一IPアドレスから10回以上のリクエストがあった場合、即座にそのIPアドレスをブロックします。
- DoSBanPeriod 60
- 説明: DoS攻撃と見なされたIPアドレスをブロックする期間を秒単位で指定します。
- DoSTableSize 100
- 説明: DoS検出のために保持するIPアドレスの最大数を指定します。
- DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
- 説明: DoS検出から除外するコンテンツタイプを正規表現で指定します。
設定有効化とApache再起動
- mod有効化
sudo a2enmod dosdetector- Webサービス再起動
sudo systemctl restart apache2.serviceまずはこれで様子を見てみます。
概要
同一サーバに複数のバーチャルホストを運用している場合、個別のconfファイルの一括バックアップを取る必要があります。
その際、
sudo cp -pi /path/to/src/directory/*.conf /path/to/backup/directory/としたのでは、オリジナルのファイルがファイル名そのままコピーされます。そういうときに、
- 特定のファイルを一括でコピーしつつ
.bk.yyyy-mm-ddなどの識別子を付与
するTIPSです。
コマンド
for file in /path/to/src/directory/*.conf; do sudo cp "$file" "/path/to/backup/directory/$(basename "$file").bk.$(date +%Y%m%d)"; doneこれで、コピー元にある.confファイル全てが、バックアップ先に元のファイル名に.conf.bk.yyyy-mm-ddが付与された状態で保存されます。