投稿者「wpepea」のアーカイブ

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

昨日の
・一般の人が見ると「まだ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の動作確認していないけど、本番機(という名の残骸)に明日は直接設定。
動作確認は元々動いていないので難しいかな。。。

SSLで怒られてた

このブログをChromeでみてたらSSLのマークのところが緑ではない時が。

クリックすると

「このサイトで目にする画像は、悪意のあるユーザーによって差し替えられたものである可能性があります。」と。

httpで画像をよそから持ってきていると出るらしい。特に身に覚えがないとソースを見てみると。

<“img style=”margin: 2px;” title=”商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。お買い物される際には、必ず商品ページの情報を確認いただきますようお願いいたします。また商品ページが削除された場合は、「最新の情報が表示できませんでした」と表示されます。” src=”http://hbb.afl.rakuten.co.jp

と楽天アフリエイトがおりました。

https指定ができないならSEO的に悪そうなのでアフリエイト辞めるかな。取りあえず今日は遅いので放置決定

2017/4/17追記

楽天がSSL対応していたのでアフリエイト張りなおせました。数が少なかったから手作業で。

 

インデックスされていない。。

先日、SSL証明書の有効期限が切れたので無料のLets’s Encryptに変更。

導入自体は簡単にできたけれどもFirefoxではSSL証明書の接続エラーが発生。

たぶんこれが原因。

根本対処する時間とる前に古い証明書の有効期限が切れるので、Firefoxは取りあえずあきらめて導入。

 

で、1週間ほど空いた今日になって大きな問題が。

店のホームページ(https://www.rocher.kyoto.jp)がGoogleにインデックスされていない。

site:rocher.kyoto.jpでみると他のページの順位は変わっていなそうなのでホームページだけ外れている模様。心当たりはSSL証明書の変更ぐらいなのでSearch Consoleから再インデックスを依頼して様子見。

 

これ、再インデックスされたとしても順位戻るかどうかも怪しいな。証明書変更が原因かは特定できないけど安い証明書を使っているなら不要なリスク抱え込むより乗り換えないほうがいいかもしれない。

逆にこれからSSL化する人は高い証明書を最初に入れると切り替えのタイミングが難しくなるから、最初から安い証明書にしといてコスト削減のためにリスクとるか考えないようにしといた方がいいかもしれない。

そういうものらしい

chefなんとなく触っていただけでまとめて勉強していなかったのでChef実践入門をちょいちょい触りながら確認中。

 

ohai |head

とうったら

[hoge@localhost testsv02]$ ohai |head
{
 "cpu": {
 "0": {
 "vendor_id": "GenuineIntel",
 "family": "6",
 "model": "42",
 "model_name": "Intel(R) Celeron(R) CPU G555 @ 2.70GHz",
 "stepping": "7",
 "mhz": "2700.000",
 "cache_size": "2048 KB",
/home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/lib/ohai/application.rb:97:in `write': Broken pipe @ io_write - <STDOUT> (Errno::EPIPE)
 from /home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/lib/ohai/application.rb:97:in `puts'
 from /home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/lib/ohai/application.rb:97:in `puts'
 from /home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/lib/ohai/application.rb:97:in `run_application'
 from /home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/lib/ohai/application.rb:78:in `run'
 from /home/hoge/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/ohai-8.20.0/bin/ohai:41:in `<top (required)>'
 from /home/hoge/.rbenv/versions/2.3.1/bin/ohai:23:in `load'
 from /home/hoge/.rbenv/versions/2.3.1/bin/ohai:23:in `<main>'

Broken pipeでた。

しらべたらそういうものらしいので放置。(もう大丈夫かもしれんけど大事なとこでないので受け入れる。)

買った照明が強すぎた

店のペンキ塗りがある程度進みきれいになってきたところで照明を追加。

いままでは店が暗い、特にルーフの周りが暗いということで横から照射しようと投光器を購入。

アマゾンのレビューだとカタログデータの4割ぐらいということだったので既存のLEDと同じぐらいの明るさだろうと踏んでいたら、かなりまぶしい。。。。
室内でほかの明かりもあるのにイカリングを直接充てられているぐらいまぶしい。

お客さんからブーイングが出たのでいったん撤去。

もったいないので、ビニール傘を前に置いたらまぶしさはなくなった。
電気屋さんに工事してもらったLEDと同じぐらいの明るさ。

当初の予定と違うけど格安の照明と考えたらいい感じ。見た目はもうちょっとなんとかします。

DSC_0451

DSC_0451

DSC_0452

DSC_0452

Vagrantインストール

ECサイトの開発をdocerベースでやろうとしていたけどVagrant全く触っていない。というわけで、しばらくは勉強を兼ねVagrantベースで開発してみようと思う。

CentOS7のホストにインストールを開始。
KVM+qumeでも動くとのことでさくらのナレッジさんをそのままコピペしてインストール実行。

[yoshitake@localhost ~]$ sudo vagrant up
[sudo] password for yoshitake:
Bringing machine 'default' up with 'libvirt' provider...
==> default: Cleaned up shared folders
==> default: ================
==> default: Machine id: a3d96b45-fd52-4590-a598-9a63744b7d58
==> default: Should be mounting folders
==> default: /vagrant, opts: {:guestpath=>"/vagrant", :hostpath=>"/home/yoshitake", :disabled=>false, :__vagrantfile=>true, :target=>"/vagrant", :accessmode=>"passthrough", :mount=>true, :readonly=>nil, :mount_tag=>"05e62b45705da84350317538981ae9c"}
==> default: Starting domain.
There was an error talking to Libvirt. The error message is shown
below:

Call to virDomainCreateWithFlags failed: 内部エラー: モニターに接続中にプロセス が終了しました: 2016-09-07T21:13:31.339854Z qemu-kvm: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=05e62b45705da84350317538981ae9c,bus=pci.0,addr=0x4: 'virtio-9p-pci' is not a valid device model name

根深そう。。。。。

 

まともにやってくとはまりそうなのでvirtualboxで起動。

sudo vagrant destroy
sudo vagrant up --provider=virtualbox

ワーニングがでてしばらくリトライ繰り返した後に終了。

default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using newSSH key...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...

原因はVagrant 1.8.5のバグとのことでこちらを参考に修正。

一度起動しただけで、suspend->resumeで再度発生。CTRL+Cで一旦停止しhalt->upとしたところまだ発生。時間なくなってきたので状況メモ書いて後で確認。

 

(9/16追記)

リンク先のように plugins/guests/linux/cap/public_key.rb

chmod 0600 ~/.ssh/authorized_keys

を追記しているがゲストのauthorized_keysがvagrant destroty & upしても664になっている。

何か手順が間違っているかもしれないけど、ゲストのauthorized_keysを直接

chmod 600 authorized_keys

して対処。こんどこそ動いているっぽい。とりあえず作るたびにchmodすることにする。

 

(10/8追記)

単にTypoでした。手動でchmod対応だと、Test Kitchenが動かないですね。

 

オンラインショップ作成開始

オリンピック期間中は店が暇そう。
ということで、1年ぐらい前に作りかけてそのまま放置していたオンラインショップを改めて作り直そうと思う。
といっても、主目的は環境構築をほとんどしなくなって時代に全く追いついていないのでエンジニアとしての勉強。

というわけで、月の売り上げがあるかわからないものにリソースを突っ込む。

環境)
本番環境:既存のさくらVPS(CentOS6)に他と相乗り
開発環境:自宅の物理サーバ(CentOS7)上のDockerでCentOS6
Webサーバ:nginx(現在apache)
ソース管理+マイグレーション:gitベース(そのままだとカスタマイズしたときに面倒ぽいのでこちらの方法で)。ChefとDockerもここに。Jenkins2は開発機へのデプロイまでやろうと思う。
バックアップ:もりっとmondo+トランザクションデータはEC-Cubeの機能理解してから。

Windows 10 Anniversary Updateで(?)起動しなくなった

さっきWindowsマシンの電源をいれたらWindowsが起動しなかった。

最初は黒い画面にyという文字だけ表示される状態。

電源を数回入れ直したらWindows10の画面が表示され「以前のバージョンのWindowsを復元しています」と表示されしばらく待機し、Windowsが再起動。その後、使えるようになる模様。(まだWindowsの起動待ち)
再起動後アップデート前の状態でWindowsが使えるようになりました。

アニバーサリーアップデートでたばかりなのでそれの障害を踏んでしまったんだと思う。
Bash使いたかったけどゆっくりまつか

2016/8/5追記)
待とうと思ったら、OSが不安定のようで再度アップデートかけたらうまくいったようです。違いはさしてあったUSBメモリを抜いたぐらいかな?
再現できない(&する気もない)ので原因は特定できませんが。

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

ボルダリングの課題変更などでバタバタして気づいていなかったけど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だけにすれば十分なのだろうけどインフラ周りをちゃちゃっといじるのは怖いのでまたゆっくりやろうと思う。(後回しになってサーバ再起動してはまったらこの記事を自分で見直す)