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

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

前提

前の業者が完成せずに中途半端に本番環境にのっている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持つドメインから送ってしのいでいる間に送信先に解除してもらうしかないかなぁ。