RTX1210にLua導入
RTX1200の IPsec スループットが200Mbpsでそろそろ厳しくなってきたのと
RTX1210の中古もそれなりの価格になってきたので導入
DDNSで自宅の環境を一部公開しているので
Luaスクリプトの導入を
1. ガーベージコレクトの実行
Flash ROM領域の為に、基本は追記書き込み、容量一杯になったらガーベージコレクト実行という仕様
GC実行時の数十秒は通信も止まる為に、最初にGC実行
> administrator Password: # rtfs garbage-collect RTFS garbage collecting... Done. #
2. USB FlashにLuaスクリプトコピー
3. USB FlashをRTX1210に接続
4. LuaスクリプトをRTX1210にコピー
# show file list / # show file list usb1:/ # make directory /lua # copy usb1:/<FILE>.lua /lua/ # show file list /
5. 動作確認
# lua <FILE>.lua
6. ファイル or ディレクトリを削除するときは
# delete /lua/<FILE>
MyDNS.jpでLet’s Encrypt DNS認証
certbotツールは、HTTP/HTTPS認証の場合80/443 portがほぼ必須みたいなので、portを変更してたり、https onlyだったりすると認証でコケル
(というかProtocol指定やPort指定してるのに、デフォルトで通信にくんなや)
かといって、MyDNS.jpだと、_acme-challenge TXTレコード登録がサポートしていなのだけど
MyDNS.jp自らが、Let’s Encrypt DNS認証ツールを公開してくれたので
詳細はこちら
-> https://github.com/disco-v8/DirectEdit/
基本この通りにやればいいんだけど
1. certbot導入
2. 各種ツール導入
なぜかreadmeどおりに、wgetしたらunzipできなかったので
# mkdir /etc/letsencrypt/DirectEdit-master # chmod 700 /etc/letsencrypt/DirectEdit-master # cd /etc/letsencrypt/DirectEdit-master/ # wget https://raw.githubusercontent.com/disco-v8/DirectEdit/master/txtdelete.php # wget https://raw.githubusercontent.com/disco-v8/DirectEdit/master/txtedit.conf # wget https://raw.githubusercontent.com/disco-v8/DirectEdit/master/txtregist.php # chmod 600 ./*.conf # chmod 700 ./*.php
3. txtedit.conf修正
$MYDNSJP_MASTERID = 'yourmasterid'; $MYDNSJP_MASTERPWD = 'yourpasswd'; $MYDNSJP_DOMAIN = 'yourdomain';
4. certbotで証明書取得
--dry-runオプションで事前チェックしておくのが良いかも
certbot certonly --manual --preferred-challenges=dns \ --manual-auth-hook /etc/letsencrypt/DirectEdit-master/txtregist.php \ --manual-cleanup-hook /etc/letsencrypt/DirectEdit-master/txtdelete.php \ -d <Domain> \ --server https://acme-v02.api.letsencrypt.org/directory \ --agree-tos -m <Mail Address> --manual-public-ip-logging-ok
5. 無事成功して /etc/letsencrypt/live/
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/<Domain>/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/<Domain>/privkey.pem Your cert will expire on 2018-11-30. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
6. Nginxのconf書き換え
Nginxのドメイン設定ファイルを以下に修正
server { listen <Port> ssl http2; server_name <Domain>; ssl_certificate /etc/letsencrypt/live/<Domain>/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/<Domain>/privkey.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets on;
7. Nginxのreload
Configチェックして問題なければ reload
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # systemctl restart nginx
8. サイトにアクセスして証明書が更新されているか確認
一応これでいけることが判った
あとは毎月一回コマンドを実行すれば、証明書が更新される
後日自動実行するように仕込む予定だけど、cron嫌いなんだよねえ
ま、業務とかみたいに何十台もLinuxあるわけじゃないから、各サーバーで何が実行されてるかよくわからないことにはならないけど
http/https認証は、httpが必須っぽかったり、Portがデフォルト必須ぽいので
個人的に建てているサイトの場合はこれが一番いいかね
VMware ESXi 6.5u2 -> 6.7 Online Upgrade
いつのまにやら、6.6を素っ飛ばして 6.7がリリースされていたので
昔の記述をベースに
-> http://d.hatena.ne.jp/TKX/20131020#p1
1. ESXiをメンテナンスモードに
# esxcli system maintenanceMode get Disabled # esxcli system maintenanceMode set --enable=true # esxcli system maintenanceMode get Enabled
2. 利用可能なUpdate Profileの確認
# esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6.7 | grep standard ESXi-6.7.0-20180604001-standard VMware, Inc. PartnerSupported ESXi-6.7.0-20180704001-standard VMware, Inc. PartnerSupported ESXi-6.7.0-8169922-standard VMware, Inc. PartnerSupported ESXi-6.7.0-20180804001-standard VMware, Inc. PartnerSupported
3. Upgrade適用
VMware Tool入り(Standard)の最新版を選択
# esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.7.0-20180804001-standard
Upgrade適用まで暫く待つ(回線及びマシン状況で、10分程度〜数十分)
と思いきや、Errorが
[InstallationError] [Errno 28] No space left on device vibs = VMware_locker_tools-light_10.2.1.8267844-8941472 Please refer to the log file for more details.
Logを調べた所スワップが足りないということで(つか、スワップなんてあったのかというレベルなんだが・・・)
WebUIから、ホスト -> 管理 -> システム -> スワップ -> データストアで、適当なデータストアを指定する
(アップグレード終わったら、元に戻しておくか)
で、再度esxcli update実行
Update Result Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective. Reboot Required: true
わずか数分で終わった
4. Reboot実行
無事Upgrade適用されたので再起動
# reboot
5. ESXiのVersion確認
# esxcli system version get Product: VMware ESXi Version: 6.7.0 Build: Releasebuild-9484548 Update: 0 Patch: 20
6. ESXiのメンテナンスモードを終了
# esxcli system maintenanceMode set --enable=false # esxcli system maintenanceMode get false
昔は、httpClient Firewallの設定変更必要だったのに、いらなくなったのね
マムタロト 当たり武器 8/17 Ver
MHW のマムタロト武器ガチャの当たり武器
あちこち参照して適当に作成
☆は確実に入手しておきたい武器ということで
【大剣】- 【太刀】RERA8 ☆火、麻痺、水 RARE7 風漂 【片手】RARE8 火、水 RARE7 風漂、蛮顎 【双剣】RARE8 氷、水 RARE7 蛮顎 【ハンマー】RARE8 ☆睡眠 RARE7 土砂 【笛】 RARE8 麻痺、水、☆睡眠 【ランス】RARE8 雷、水 RARE7 ☆惨爪 【ガンス】RARE8 睡眠、毒、☆水 RARE7 王 RARE6 王 【スラアク】RARE8 ☆麻痺 RARE7 角 【チャアク】RARE8 ☆水 RARE7 角 【虫】 RARE8 ☆麻痺、水、氷 【弓】 RARE8 雷、水 RARE7 角 【ヘビィ】RARE8 援撃、爆撃 RARE7 角、☆賊 【ライト】RARE8 射撃、狙撃、迫撃、援撃 RARE7 王
体裁整えるの面倒臭かったので
x.264パラメーター
x.264 rev.2851 + x264guiEx 2.56
--preset slow --crf 20 --rc-lookahead 40 --keyint 300 --subme 9 --direct spatial --ref 4 --trelis 1 --sar 1:1 --level 4.1
CentOS7に Python 3.xをインストール
CentOS 7のデフォルトは、2.7.xで、最近のトレンドである 3.xは標準及びEPELリポジトリでは追加できないので
IUS Community Projectのリポジトリを追加して rpmパッケージをインストールする
# yum install https://centos7.iuscommunity.org/ius-release.rpm
Python 3.xのリポジトリが登録されたので、最新版を検索
# yum search python3
現時点では、3.6系が最新らしいので Python 3.6と関連パッケージをインストール
ここで python36パッケージとpython36uパッケージがあって違いが判らないので
調べてみた所
- python36
- EPELベース (3.6.3)
- python36u
- IUSベース (3.6.5)
ということらしく、Verが違うのに同じパッケージ名だと問題になるので u を付与しているとの事
どうせ IUSのリポジトリから入れるし、そちらのほうがVer新しいので python36u を導入
# yum install python36u python36u-devel python36u-pip
CentOS 7 + Nginx + rep2 で HTTPS & HTTP/2化 (SSLなう!編)
そんなわけで、取り敢えず SSLなう!で証明書は取得して
Nginxを HTTPS & HTTP/2化まではやってみようかと
MyDNS.jpは、2018/9/1時点ではWebUIからの_acme-challengeレコード投入に対応しなくなった模様
(正確には、投入できるけど検索できない)
代わりにphpのスクリプトを提供
-> http://d.hatena.ne.jp/TKX/20180902#p1
MyDNS.jpはDNS情報を変更する事は可能なので、DNS認証(dns-01)でドメイン確認までは実施
mydns.jpのコントロールパネルから "_acme-challenge"のホスト名で、TXTレコードを作成
# dig @8.8.8.8 _acme-challenge.<domain> any
を何回か実行して結果が帰ってきたら、確認ボタンを押下すればOK
自分のServerで
# openssl genrsa 2048 > server_private_key.pem
を実行して、サーバー秘密鍵を生成してサイトに貼り付ければ
サーバー証明書 / 中間証明書 / フル証明書
が生成/発行される
Nginxでは使用するのは、サーバー秘密鍵とフル証明書の2つ
/etc/nginx/ssl 以下に格納
DH鍵交換に使用するパラメータファイルを作成する
Nginx 1.12.x以降はこのパラメーターファイルとconfへの指定が必須になった
# openssl dhparam 2048 -out /etc/nginx/ssl/dhparam.pem
nginxのドメイン毎の confファイルは以下な感じで (FastCGI絡みもSSL設定の追記が必要)
server { listen <Port> ssl http2; server_name <Domain>; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/server_private_key.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets on; # modern configuration. tweak to your needs. ssl_protocols TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; ssl_prefer_server_ciphers on; # DH Key Parameter ssl_dhparam /etc/nginx/ssl/dhparam.pem; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) # add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; location / { root /var/www/html; index index.html index.htm index.php; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param HTTPS on; fastcgi_param SSL_PROTOCOL $ssl_protocol; fastcgi_param SSL_CIPHER $ssl_cipher; fastcgi_param SSL_SESSION_ID $ssl_session_id; fastcgi_param SSL_CLIENT_VERIFY $ssl_client_verify; fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} }
基本的に、HTTPポートは開放せず HTTPSポートのみ空ける方針なので
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
configチェックして問題なければ
# systemctl reload nginx
Reloadして再構成して終了
後は、ブラウザーから https://
追記 : SSL CipherSuiteの指定については
Mozilla SSL Configuration Generatorを参考に構成しています
余談
Qualys SSL Labs の SSL Server Testは、デフォルトの 443しか対応していないようで
Port指定しても "Port 8443 is not supported"といった感じ
CentOS 7 + Nginx + rep2 で HTTPS & HTTP/2化
最近のブラウザーは、httpではなくhttpsでないと
危険なサイト扱いされて表示そのものが出来無くなってくるとの事で
rep2サイトもHTTPS化を実行
ついでにHTTP/2化も同時に実施する
HTTP/2は規格としてはHTTPSとは別立てで、HTTP Server側で一言設定を入れることでHTTPSとは別に設定が可能だが
ChromeやFirefox、Safariのブラウザ側の実装として、HTTP/2はHTTPSとセットになっていないとデコードできない現実がある
その為 HTTP/2の前提条件として、HTTPSの実装が必要になる
SSL証明書については、無料の Let's Encryptを使用するとして
certbotを使用すると秘密鍵生成まで自動してくれる
Let's Encryptの非公式日本語解説サイトもあるので、一通り読んでおくと良い
(但し情報が古すぎてイマイチ使えないのだが)
CentOSの場合、EPELリポジトリに certbot パッケージが格納されているので
EPELリポジトリを導入するが、通常EPELリポジトリは導入しているのでスキップ
ちなみに今回
自宅サーバーなので、HTTPS化を実施した場合、HTTPSのPortだけ開放してHTTPのポートを閉じようと考えている
Webの色々なやり方を見ていると、HTTPSだけポート開放した例が見当たらなかったので
更新の時に試行錯誤しような予感・・・
# yum install certbot
certbot パッケージと依存関係のあるパッケージ 40個程インストール
certbotのVerは結構頻繁に変わっており、それに伴ってオプションも色々変更あるみたいなので
現行のVer(0.24.0-1.el7)のOptionを確認
# certbot --help ------------------------------------------------------------------------------- certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ... Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate. The most common SUBCOMMANDS and flags are: obtain, install, and renew certificates: (default) run Obtain & install a certificate in your current webserver certonly Obtain or renew a certificate, but do not install it renew Renew all previously obtained certificates that are near expiry enhance Add security enhancements to your existing configuration -d DOMAINS Comma-separated list of domains to obtain a certificate for (the certbot apache plugin is not installed) --standalone Run a standalone webserver for authentication (the certbot nginx plugin is not installed) --webroot Place files in a server's webroot folder for authentication --manual Obtain certificates interactively, or using shell script hooks -n Run non-interactively --test-cert Obtain a test certificate from a staging server --dry-run Test "renew" or "certonly" without saving any certificates to disk manage certificates: certificates Display information about certificates you have from Certbot revoke Revoke a certificate (supply --cert-path) delete Delete a certificate manage your account with Let's Encrypt: register Create a Let's Encrypt ACME account --agree-tos Agree to the ACME server's Subscriber Agreement -m EMAIL Email address for important account notifications More detailed help: -h, --help [TOPIC] print this message, or detailed help on a topic; the available TOPICS are: all, automation, commands, paths, security, testing, or any of the subcommands or plugins (certonly, renew, install, register, nginx, apache, standalone, webroot, etc.) -------------------------------------------------------------------------------
こんな感じで実行すれば取り敢えず大丈夫かな
dry-runで試行
certbot certonly --dry-run --webroot --http-01-port 8080 -w <DocumentRoot> -d <Domain> -m <Mail Address>
HTTPのportを変更していたので、http-01-portオプションを指定したのだが、確かにcertbot は 8080でポート確認しているのに
アクセスしてきてるのがデフォルトの 80 とか
なんだ、このバカ仕様?
これじゃPort変更しているサイトは全てダメなんじゃないかと思ったり
という所で一旦終了
なんか素直に安い証明書調達したほうが楽な気がしてきた _no
なんだけど、mydns.jpだとそういうわけにもいかないしなあ
追記
サイトによっては、Nginx側にサーバーチェック用ディレクトリ設定を入れる必要があると記載がある
例
location ^~ /.well-known/acme-challenge/ { root /usr/share/nginx/html/.well-known;
certbot実行中にディレクトリが作成されるのは確認していたけど、アクセス権の絡みで失敗していたんかな??
改めて後日検証してみるか