カテゴリー
Linux

Ansible で CentOS 7 の自己署名の SSL 証明書を作成するタスク 2 種の方法をメモ

まとめ

sudo bash /etc/pki/tls/certs/make-dummy-cert filename を使う方法

  • PRIVATE KEY と CERTIFICATE が一つのファイルに出力される。
  • Nginx 設定ファイルで使えるようにするために、シンボリックリンクを作って ssl_certificate と ssl_certificate_key に指定する。

Ansible の openssl_privatekey, openssl_csr, openssl_certificate モジュールを使う方法

カテゴリー
Linux

メモリの 2 倍の領域を持つ swap を作成してマウントする Ansible プレイブックを作りました

はじめに

Amazon Lightsail 低スペックインスタンスのメモリ不足を解消するために Swap を作り、快適になりました♪ – oki2a24 の効果を実感しましたので、次からは自動で行えるようにするために Ansible のプレイブック化いたしました。

カテゴリー
Linux

Ansible で一時的に変数を使用するやり方メモ

まとめ

  • register を使う。
  • 使うときは、”{{ variable_name.stdout }}” などととする (ダブルクオーテーションは必要) 。
カテゴリー
Linux

Ansible で CentOS 7 に MySQL 5.7 を構築する時のお勉強メモ

構築の進め方

まず、日本語で流れを確認しました。

mysql_secure_installation 時において、Ansible 的に、初期パスワードを入れる必要があるのが辛そうでした。

次に本家ドキュメントに従って構築していきました。

その後、Ansible プレイブックを確認しながら書いていく、という順番です。

カテゴリー
Linux

Let’ Encrypt 証明書の certbot を使った設定、cron による更新を行う Ansible プレイブックを作った際の勉強ノート

SSL/TLS を含めた Ansible プレイブックを開発するための環境を ConoHa に作った時のメモ – oki2a24 の続きとなります。

やっと SSL/TLS の Ansible プレイブックを作りました。その時のメモを残します。

certbot コマンドオプションの理解

# certonly: 証明書の発行と配置のみで、Webサーバの設定ファイルの書き換えは行わない。
# -w: Webサーバルートディレクトリを指定
# -d: ドメインを指定
# --agree-tos: 規約に同意
# -m: アカウントの登録や回復などに使用する電子メールアドレス
# --keep-until-expiring: リクエストされた SSL/TLS サーバ証明書が既に存在している証明書とマッチする場合には、証明書の更新が必要になるまでは、新規の証明書を取得しない
# --non-interactive: ユーザからの入力を一切求めない
# --staging: SSL/TLS サーバ証明書の取得時に、ステージングサーバを使用して、無効な証明書を取得する
certbot certonly --nginx -w /srv/wordpress/ -d test.oki2a24.com --agree-tos -m oki2a24@gmail.com --keep-until-expiring --non-interactive --staging

Ansible の cron モジュール

# crontab -l
#Ansible: None
* 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew
#
# crontab -l
#Ansible: renew cert
* 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew
#

certbot エラーへの対処

  • DNS レコード設定をしていないと、certbot コマンドはエラーになる。

certbot 実行時にエラーとなりました><。Ansible の出力は見づらいこともあり、ログを確認しました。どうやら、ドメイン名と DNS の A/AAAA レコードと IP アドレスの設定が誤っているのでは? という内容です。

2018-07-10 17:16:24,442:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: test.oki2a24.com
Type:   connection
Detail: Fetching http://test.oki2a24.com/.well-known/acme-challenge/_Ao4A2VfgQWKNAYtTH842j9AHCYGLrea9VW6TVvzSMc: Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

確かに、仮想マシンを作成しなおせば IP アドレスも変わります。そして、DNS レコードの設定は修正してませんでした。そこで、これを修正し、無事エラーは出なくなりました♪

SELinux の影響で、ウェブブラウザから WordPress 本体の更新が不可能になった><

これは、、、まずは諦めようと思います。つまり、SELinux は Enforcing にしたままとします。諦めて、サーバに SSH 接続し、root ユーザで WP-CLI を使って更新をしようと思います。コマンドは次のようになります。

# wp core check-update
+---------+-------------+----------------------------------------------------------------+
| version | update_type | package_url                                                    |
+---------+-------------+----------------------------------------------------------------+
| 4.9.7   | minor       | https://downloads.wordpress.org/release/ja/wordpress-4.9.7.zip |
+---------+-------------+----------------------------------------------------------------+
# wp core update
Updating to version 4.9.7 (ja)...
https://downloads.wordpress.org/release/ja/wordpress-4.9.7.zip から更新をダウンロード中...
更新を展開しています…
Success: WordPress updated successfully.
# wp core check-update
Success: WordPress is at the latest version.
#

うまい SELinux 設定方法が無いか調べましたけれども、次のページでも同様に運用しているということで、それに倣うことといたしました。

Ansible の Handler は 1 回かけばどこでも使えるグローバルスコープだった!

notify をもつタスクを別の場所に移したとき、handler も移すのを忘れていました。けれども、元の場所にあった handler が動いたことで、気が付きました。

実際に動かしてみると、Ansible の出力は次のようになりました。

TASK [ssl : Replace Nginx default.conf] ***************************************************************************
changed: [163.44.169.218]

TASK [ssl : Set renew cert] ***************************************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [mariadb : Restart mariadb] ***********************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [nginx : Restart nginx] ***************************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [php-fpm : Restart php-fpm] ***********************************************************************
changed: [163.44.169.218]

Let’s Encrypt の制限に引っかかる><。

プレイブックが完成し、ブラッシュアップしようと弄っては実行していましたら、次のエラーとなりました。

{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new cert :: too many certificates already issued for exact set of domains: test.oki2a24.com: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

ログの Rate Limits – Let’s Encrypt – Free SSL/TLS Certificates を見てみますと、、、たしかに、やっちまったようです。。。どうやら、1 ドメインで 1 週間あたり 20 証明書まで のようです。

お試しの場合は、Staging Environment – Let’s Encrypt – Free SSL/TLS Certificates を使え!とのことです。。。

  • certbot ならば、–staging を付ければ Staging Environment となる。
  • Staging Environment ならば、1 ドメインで 1 週間あたり 30000 証明書まで。
  • Staging Environment で発行した証明書は正規のものではないため、ウェブサイトは “このサイトへの接続は保護されていません” といった警告がブラウザに出る。

certbot コマンドのエラー><。Webサーバの SSL 対応後の設定ファイルは、certbot コマンド実行後に入れ替える

なぜならば、certbot --nginx の場合、certbot 実行中に nginx 設定ファイルのチェックを行うようです。

したがって、その時点では正しくない設定ファイルですと、エラーとなってしまいました。

ログが、その時の状況をよく物語っております><。

2018-07-11 14:00:36,456:ERROR:certbot.util:Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/test.oki2a24.com/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/test.oki2a24.com/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

出来上がったリポジトリ

certbot –staging となっているますので、このオプションは削除しなければなりません。いつか。

おわりに

BackWPup のバックアップファイルを使い Ansible プレイブックを実行することで、自身のサイトを簡単に復元できるようになりました♪

何度も DNS レコード設定と、仮想マシンの作成を行い、これに慣れることができたことが、一番うれしく感じました。

以上です。

カテゴリー
Linux

SSL/TLS を含めた Ansible プレイブックを開発するための環境を ConoHa に作った時のメモ

やりたいこと

  • SSL/TLS を含めた Ansible プレイブックとしたいので、そのための環境を作りたい
  • ConoHa で SELinux が disabled だが、enforcing で試したい
カテゴリー
WordPress

BackWPup から WordPress をサーバ構成も含めて復元する Ansible プレイブックを作った時の勉強ノート

BackWPup – WordPress Backup Plugin | WordPress.org でファイルとデータベースのバックアップを Zip ファイルにして DropBox にアップロードすることを、日々自動実行しております。

このファイルをダウンロードして、これを元にサーバ環境も含めて復元する Ansible プレイブックを作成しました。

サーバに障害が起きたときや、サーバを引っ越ししたいときは、バックアップファイルとプレイブックを実行すれば復元できるようになります (正確には、SSL/TLS 証明書発行はできてませんのでまだ未完成ですけれども)。

その中で、気がついたことをメモいたします。

カテゴリー
Linux

Conoha 作業。WordPress サーバを Ansible で構築した時の、主に playbook 実行前の作業メモ

はじめに

そうだ、ブログサーバを引っ越ししましょう。

引っ越し前のブログサーバは、1 台の VPS に WordPress や MySQL などすべてを入れて動かしています。

今回、引越し先のサーバをセットアップし、WordPress が使用できる状態にするまでを記録します。

サーバインスタンスを立ち上げて、接続設定を行い、最後に Ansible を実行するところまでが範囲となります。

カテゴリー
Linux

【Ansible】playbook 実行時に sudo パスワードを入力して実行する方法

まとめ

  • ターゲットノードでのユーザに sudo コマンドが実行できるようにしておくこと。
    • CentOS 7.5 では、wheel グループに属させれば sudo コマンドが実行できるようになる。
  • ansible 実行時に指定する playbook (site.yml) の remote_user にターゲットノードのどのユーザで実行するかを指定すること。
    • become は true を指定すること。
  • ansible 実行時に、–ask-become-pass オプションを付けること。

他にもあるかもしれませんけれども、私は以上のポイントで動くようになりました。

以下、ターゲットノードで playbook の内容を実行するユーザ名を、ansible として説明します。

カテゴリー
Linux

Ansible コントロールノードからターゲットノードへの疎通確認メモ

はじめに

検索をしてみても、Ansible 入門はさまざまありますけれども、理屈は抜きにして Ansible でコントロールする側 (コントロールノード) からコントロールされて構築される側 (ターゲットノード) の、Hello World 的なシンプルな手順がなかなかわかりませんでしたので、今回自分のためにメモいたしました。