インフラ」カテゴリーアーカイブ

Let’s Encryptの認証局が古いAndroidで使えなくなるので延命

いまさらながら、もう少しで古いAndroid(7.1以下?未満? 大体3割強ぐらい?)だとLet’sEncriptのsslが効かなくなることを知った。「出来立てのころは自前のCAだと知名度なくて実質認証できないからよそのCAに協力してもらってたけど基本自立するよ」ということらしい。(意訳)

optionで1年ぐらい延命できるとのことなので対応中。作業メモがてら記録に残しておく。

certbotの場合はoption(–preferred-chain)で元々のCA(DST Root CA X3)をしていすれば良いらしい。なお、–force-renewalオプションを付けていないとまだ期限内だよと更新してくれないから付けておく。まとめると下の感じ。

certbot-auto certonly --preferred-chain "DST Root CA X3"  --force-renewal +いつものオプション

いちおう証明書のCAと内容も確認しておく

openssl s_client -connect ドメイン:ポート | openssl x509 -noout -enddate
openssl s_client -connect ドメイン:ポート -showcerts

見た感じ想定どおり更新されている。程良い試験端末ないので動作確認はしない!

メインのサーバ群はletsencrypt-nginx-proxy-companion使っているけどそっちでの設定方法(あるのか?)はこれから調べる。

(追記)

2020/10/1時点では対応されていなけど、issueがあがっていて使っているsimp_leが対応してからの模様。「先にsimp_le(のフォーク)にイシューたてな!」といっているのですぐではなさそうな雰囲気。

GitlabPagesでアカウント名にドットが入っているとうまく動かない

事象

アカウント名がfoo.varとドットが入っているとGitlabPagesは https://foo.var.gitlab.io/val  みたいなURLになる。

しかし、GitlabPagesからもらえる証明書は*.gitlab.ioのワイルドカード証明書なため、foo.varと二段階になっているサブドメインではエラーとなる。

対処

URLにこだわりはないのでドットの入っていないグループを作成しそちらにレポジトリ移管した。https://epea.gitlab.io/sanko5/ (epeaが新しくつくったグループ)

自力でLetsEncript動かしてもよさそうなきもするけどそれはそれで面倒そうなので試していない。

取得してしばらくしたドメインがDNS_PROBE_FINISHED_NXDOMAIN

TwitterにWordpressのサイトを立ち上げて少し立ったサイトがDNS_PROBE_FINISHED_NXDOMAINでつながらないという事象で困っているクライマーがいました。

ブログのネタついでに切り分けしたので、切り分け方法と解消方法をメモしときます。

DNS_PROBE_FINISHED_NXDOMAINとは

インターネットのアドレスのドメイン部分(https://www.rocher.kyoto.jp/arbr/〜のwww.rocher.kyoto.jp部分)はどのサーバ(インターネットの向うの機械)かを表していて、管理は数字(ipアドレス)メインで行われています。

で、ざくっと雰囲気で説明すると、ドメインの文字が実際にはどの数字かを教えてくれるシステムがあってそれをDNSといいます。そのDNSにドメインのIPを教えてと自分の端末(PC/スマホetc)からサーバに接続しようと自動で質問したけどその答えが得られないときに発生するのがDNS_PROBE_FINISHED_NXDOMAINというエラーです。

結構あたる解決策

ドメインをお名前comなりムームードメインなりで取得したと思いますが、期限内にメールアドレスの認証をきちんとしていないとそのドメインのDNS機能を停止させられます。

ドメインを取得してしばらく経った後に、使えていたドメインが止まってしまったら認証漏れの可能性が高いです。

「【重要】~ ドメイン 情報認証のお願い」みたいなメールが来ていると思うのでそいつに従って手続きをしたら、通常数10分ほどで復活します。

切り分け

きちんと調べてから治したい人向けの切り分けです。(そもそもお名前comなりの管理画面にログインしたら分かり易い警告でているかもしれません。)

自分の端末の問題かつなげているDNSがおかしいかの切り分けが必要です。

確実ではないですが、自分の端末がおかしいか確かめるために違うwifiの友達なりにおかしいURLを送って、同じブラウザで同じエラーが出るか確かめてもらうのが手軽です。

同じエラーが出なかったら自分の端末側の問題が大きいですが、ここでは取り扱いません。(ほかを再度ぐぐってください)

で、他の人もおかしかったらDNS側の問題の可能性が高いです。
whoisというコマンドで調べられます(オンラインだとこことかですが、管理アドレスによってどこで調べ直せと管理先URLを教えられてもう一度調べ直しになります。

で、そこで「Domain Status」という処がclientHoldというものになっていたらメールアドレスの認証エラーです。

clientHoldの理由には認証のメールに返信していなかった以外にも、登録した個人情報が怪しまれた場合もありますがそちらはレアケースなのでそうなってしまったら、サポートに連絡するしか無いと思います。

追記

ピンバックはできるだけ対応するので、参考になったらリンクはっていただけるとありがたいです

/etc/sudoers.dの#

vagrantのsudo設定
/etc/sudoers.d/vagrant
にしかなさそうだけど/etc/sudoersコメントアウトアウトされてるよねと必死に設定探していたら

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

!! コメントじゃない。

これはみな一度は騙されるに違いない。。。。

 

Dockerサポート外

会社用メインサーバは秘伝のたれが詰まったCentOS6でミドルも都度都度足していったもので構成よくわからなくなっている。取りあえず、よく使うやつらだけでもDockerに切り出しておこうかと思ったらCentOS6系はもうサポート対象外なのね。昔からあるサーバは特にいじっていなかったから知らなかった。

このまま使い続けるのもより、いっそのこと今OSもCentOS7にあげてしまった方がいいかな。Docker用OSも考えたけど、何かあったときにミドルをコンテナでなくホストに慌ててインストールとか時間かかりそうなので、メインサーバは無難にCentOSにしとく。

 

取り急ぎのメンテナンス画面(実作業)

昨日の
・一般の人が見ると「まだOPENしてませんよ」に飛ばす
・業者はものを見れるようにしておく。
・触ると色々巻き込まれそうなのでできるだけ今あるものには手を加えたくない
という感じの告知画面追加の実作業。

まずは、dockerのopenresty使って、クッキーチェック付きのリバースプロキシを表に出す。
SSLもプロキシを通そうとしたけど、ECCubeが乗っているapacheのhtaccessに告知画面への302リダイレクト追加

コンテナからグローバルIPの8081ポートを指定したのでファイヤウォールを開けてやる。
稼働予定の本番環境では内部のネットワークのみにしてやらんといけんけどそのままもりっと。
で、apacheのポートやらを変えてやって取りあえずいったん終了。

取り急ぎのメンテナンス画面

前提

前の業者が完成せずに中途半端に本番環境にのっているECCube、認証もかけずに放置していたらプレスリリースしていた関係かURL直打ちでものが売れてしまったとさ。。
というわけで、慌てて一般の人は見れないようにしてほしいとの電話が。
でも、次の業者は物を見てほしいので業者は見れるようにしてほしいと。

色々突っ込みどころはあるけれども取り急ぎ満たさなければいけない(?)要件は
・一般の人が見ると「まだOPENしてませんよ」に飛ばす
・業者はものを見れるようにしておく。
・触ると色々巻き込まれそうなのでできるだけ今あるものには手を加えたくない

ということで、認証付きのリバースプロキシを経由して認証していない人は告知画面に飛ばすことにする。
業者さんが見る目的なのでSSL証明書はそのままでhttpでアクセスしてもらえば既存webサーバのport番号を変えるだけで既存のものには影響でないつもり。
プロキシは認証処理あるので、インストール/アンインストールを考えるとdockerのopenrestyで作るのがよさそうかな。
同一ホスト上にあるので決裁モジュール等もきっと動いてくれるだろう。

という方針で作業開始。

試験機で

nginx周り

本番機はCentOS7.2。
portやらやら触るのでグルーバルIPあるやつでやらんと混乱しそう。
バックアップ機になる予定で契約だけしているさくらVPSにOSインストールして動作確認からはいる。

yum -y install docker
systemctl start docker
systemctl enable docker
docker pull openresty/openresty
docker run -d -p 80:80 --name proxy openresty/openresty:trusty

きっと公式っぽいopenrestyのイメージ。最初タグ無し(latest)でpullしたけれどもUsageにはopenresty/openresty:trustyとなっていたのでこっちを利用。

ここでサーバのIPでhttpアクセスすると、起動はしている。
とりあえず中に入って確認。

docker exec -it proxy /bin/bash

多分、/usr/local/openresty/nginx/conf/nginx.conf
だけいじれば大丈夫そう。そのままいじってもいいけど、入っているエディタがvimでなくviで嫌いなのでコピー

docker cp proxy:/usr/local/openresty/nginx/conf/nginx.conf nginx.conf
vi nginx.conf

中身はこんな感じ

    server {
        listen       80;
        server_name  localhost;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;
        location /auth.html {
          access_by_lua_block{
            ngx.header['Set-Cookie'] = 'gyousya=desu; path=/'
          }
          root   html;
        }

        location /kokuchi.pdf {
          root   html;
        }

        location / {
            root   html;

            rewrite_by_lua_block{
              local cookie_val = ngx.var.cookie_gyousya
              if (not cookie_val) then
                return ngx.redirect("https://www.rocher.kyoto.jp/")
              end
            }
            proxy_pass http://49.212.208.218:8081;
        }

location /auth.htmlに来た時にクッキーセットして
location / でクッキーがNilだとよそに飛ばす。
本来だとkokuchi.pdfに飛ばすけど告知分まだできていないということで自分の店に。

上の方のproxy_set_header系は後ろにあるapacheがリモートアドレス拾えるように。

proxy_passはhostのグローバルIP直接指定。

docker cp nginx.conf proxy:/usr/local/openresty/nginx/conf/nginx.conf

コンテナにコピー。コンテナへのコピーも今はできるのね。。

apache

apacheの設定も一応。ECCubeのドキュメントチラ見した感じだと必要なさそうな気もするけど元のIPもapache本体でも。実際にはheaderにX-Forwarded-For系がついていれば大丈夫そう。

#httpd -M | grep remoteip
 remoteip_module (shared)

yumで取りあえず入れたやつだけどmod_remoteip入っている。
本番機もyum(chefでpackage install)でやっているのできっと入っているはず。(未確認)

こちら参考に設定。

SSL止めてないけど明日。
EC-Cubeの動作確認していないけど、本番機(という名の残骸)に明日は直接設定。
動作確認は元々動いていないので難しいかな。。。

メールが受信できていなかった

ボルダリングの課題変更などでバタバタして気づいていなかったけど2週間ほど前から会社のメールが受信できていませんでした。

原因はサーバにhostnameが設定されていなかったためで、hostnameを設定しPostfixとDovecotを再起動して復旧。停止期間中のメールも受信できました。

修復したけど切り分けでしたことをメモ。

環境はCentOS6+Postfix+Dovecot。

日曜日にしばらくメールが来ていないことに気づき、携帯からメールを送ってみたが届かず。

 

カーネルアップデート後にサーバ再起動していたので、PostfixとDovecotが起動しているか確認したけど問題なさそう。

chkconfig –list
ps -Af

メールクライアントがうまく同期していない可能性を考えてサーバ側の受信状況も確認したけどサーバのメールボックスにも届いていない。

mail -f ~/Maildir

そのころのメールログ(view /var/log/maillog-20160724)を見直すとエラーいた。

Jul 18 01:47:38 epea postfix/local[15727]: warning: valid_hostname: numeric hostname:数字でIP
Jul 18 01:47:38 epea postfix/local[15727]: fatal: unable to use my own hostname
Jul 18 01:47:38 epea postfix/smtpd[15722]: disconnect from 接続元メールサーバ名
Jul 18 01:47:39 epea postfix/qmgr[1697]: warning: private/local socket: malformed response
Jul 18 01:47:39 epea postfix/qmgr[1697]: warning: transport local failure — see a previous warning/fatal/panic logfile record for the problem description
Jul 18 01:47:39 epea postfix/master[1685]: warning: process /usr/libexec/postfix/local pid 15727 exit status 1

「ホスト名(文脈的にはドメイン名?)が数字だよ。そんな変なの使えんよ。」ということっぽい。

Postfixの設定を確認すると「mydestination = $myhostname, localhost.$mydomain, localhost,$mydomain」となっていてこちらによると$myhostnameのデフォルト値は「hostname」コマンドで得られるローカルホスト名らしい。

postconf -n

hostsにホスト名を設定していないからサーバ再起動時にホスト名がデフォルトの数字になってローカル転送できなくなっていたということらしい。そもそもいつどんなホスト名を設定したのかも覚えていないけど、メールサーバのインストール前にたまたま何か設定していて動いていたということらしい。

転送を考えなければ$mydomainが正しく設定されていれさえすれば$myhostnameはなにでも動くっていうことね。ということでhostnameを適当に設定したうえでPostfixとDovecotを再起動して暫定対処。

そもそもmydestinationを$mydomainだけにすれば十分なのだろうけどインフラ周りをちゃちゃっといじるのは怖いのでまたゆっくりやろうと思う。(後回しになってサーバ再起動してはまったらこの記事を自分で見直す)

ASAHIネットの固定IP+フレッツのゲートウエイ変更でトラブル

昨日事務所においてあるフレッツのゲートウエイRT-500MIが故障し機器交換をしてもらった。

ASAHIネットの固定IPを振ってもらっているのだけれども、外から繋がらなくなってしまった。

 

PING返事なし。
TRACERT途中で迷子になる。
店の端末と、さくらVPS両方からで同じ状況。

ルーティングっぽい。情報が途中でキャッシュされている??

試しに、店PCに
ROUTE ADD 店のゲートウエイが見ているデフォゲ
を指定。

PINGは通ったので多分あたり。

 

これでVPNつながるだろうと思ったら、まだつながらず。
とりあえず今朝試したらつながった。

 

Barracuda Reputation

社内SE(という名のシステム全般担当)やっている会社からあるところにメールが送れないという連絡がきた。

添付された内容を見ると

Remote host said: 554 Service unavailable; 
Client host [XXXX.jp] blocked using Barracuda Reputation; 
http://bbl.barracudacentral.com/q.cgi?ip=nnn.nnn.nnn.nnn
Giving up on nnn.nnn.nnn.nnn.

迷惑メール判定システムのバラクーダにがっつりはじかれています。調べてみたところ利用ドメインでの登録な無し。バーチャルドメインなメールサーバに間借りしているので巻き添えっぽい。

サーバは他のソフトハウス管理で、対応依頼も面倒。

Barracuda Spam & Virus Firewall Plusってので受け取り側で解除できるらしいので、他のIP持つドメインから送ってしのいでいる間に送信先に解除してもらうしかないかなぁ。