うまいぼうぶろぐ

linuxとhttpdとperlのメモ

12年勤めたSIerを2019年1月に退職して半年が経った

久しくブログ更新していなかったので生存報告も兼ねてます。

退職

2006年に新卒で入って、12年(13年目)勤めていた会社を1月に退職していました。
会社も自分も有名ではないので、主にリアルでこのブログの存在を知っている人向けのエントリです。
(本当は転職して試用期間が終わったぐらいに書こうと思っていたけど、気がついたら随分と経過してしまった)

どんな会社でどんなことしていたかというのはMackerelのイベントで発表したものを見てもらえばさらっとわかります。
mackerel.io
hogem.hatenablog.com

主にホスティングサーバ用のトップオブラック以下の環境の面倒を見てました。

退職を考えた大きな理由の一つは、クラウドを使う機会があまりなくて世間からどんどん離されていっている感じがして危機感を覚えたから。もともとISPもやっていた会社のため、回線/ネットワーク/サーバの環境を自前で持っていたこともあってクラウド使うよりもオンプレがメインだった。クラウド使ったことある人ならわかるけど、トラフィックのコストって意外と高い。ところがオンプレの環境だとそれは無視できたので、会社からするとオンプレで提供するほうがコストは断然安かったのもあってクラウドの利用はあまり進まなかった。
(めっちゃ雑な説明をすると、ISPをやるということはユーザのトラフィックは下りが大半になって、上りは空きます。その環境でホスティングサーバを提供すると、空いてる上りのトラフィックがまるっと使える(トラフィックの向きが逆転するので))
トータルのサーバ台数はそこそこ多かったけど、単体のシステムは小規模なものがほとんどで、もっと大きいのに携わりたいという考えもあった。

他には30代後半になって、自分のやりたいなどを改めて考えて、転職するなら年齢的に今しかないかなーというとこもありました。あと売り手市場と言われていることもあってちょうど良いタイミングだったかなと。

労働環境に不満はそんなになかった。(2012年頃には強烈に我慢ならない事象があってその時はtwitterでもだいぶ愚痴ってたけど、その件はもう解消されていた) 上司に恵まれていたのも大きかった。特に後半はリーダーというポジションだったこともあってか、かなり自分の好きなように仕事させてもらっていたし、そもそもリーダーになる前から、「お前が思うようにやったらええやん」的な感じで任されていたし。YAPC行きたいって言ったら「おう行ってこいやー」みたいな感じで最高だった。
給料も大阪の会社ということを考えたら悪くはなかったと思う。残業代も満額出ていた。

思い出

大きく覚えてるのは3つ。

1つ目はホスティングで使っていたファイアウォール機器を別メーカに変更したときのリプレース作業。(コストが理由)
ポリシー移行は一部ベンダに任せていたけど、チェックはこっちでしないといけなかったし、configが全く違うから数ヶ月 show run と戦う日々だった。
もちろんconfigの形が違うからshow runをdiffしても意味がないので、show runの結果をparse して統一した形になおしてからdiffするなどperlが大活躍した。
あと夜間作業当日の朝にシャワーを浴びて考え事していたら、ベンダですらわからなかったポリシー移行漏れがあることに気づいたときは俺すげーって思いましたね。


2つ目は自前クラウドのネットワーク障害。ストレージどころかホストも完全にぶった切られてめちゃ辛かった。
ちなみにこれがMackerelを導入したきっかけなので、冒頭のMackerelイベントの資料に事件の概要が書いています。


3つ目は子供が学校を登下校した際に親御さんにメールが飛ぶシステムのインフラを担当できたこと。これは他のシステムと比べるとユーザ規模やトラフィックなども大きくてやりがいがあった。サービスの性質上、障害に対してめちゃめちゃシビアなので緊張感もあった。(SMTPはキャリア側で止められることもあるし、リアルタイムに到達すること保証できない、という話をしても、「知らん、何とかして」みたいなことになってシステムを担当してる人が辛そうだった。ちなみにそれはSaaSを使って解決してた)
ユーザが増えてきてそろそろDBのスケール考えないといけない、みたいなところで転職したのは心残りだったけど引き継いだ人頑張って。
あとこのシステムを作ったっていうと、主婦層からの受けが良かったです。(怒られることもあった)

現在

退職を考えた理由を解消できるような企業を探して、面接でそのまま志望動機を言って無事内定をいただいたところに転職しました。職種はだいたい同じような感じでネットワーク、サーバのインフラを面倒見てる。
相変わらず大阪に住んでいるので知り合いの人は声かけてくれたら、ピューっと飛んでいくので飲みに行きましょう。

iOS 12でF5 Accessに証明書をインポートしてVPN接続する方法

日本語の記事が少なくて解決するのに時間かかったので、せっかくなので共有。

概要

iPhoneをiOS12にアップデートしたらF5 Accessが証明書を認識しなくなって、ややハマっていた。
レビューを見ても、皆同じように証明書が使えないと書いていたので、
当初はアプリの問題かと思ってしばらくアプリがアップデートされるのかなーと思っていた。

https://itunes.apple.com/jp/app/f5-access/id1354638393?mt=8

で、色々調べていたらF5 Accessの問題ではなくてiOSの仕様が変わって、本体にインストールした証明書をアプリ側で読めなくなって、明示的にアプリを指定して共有すれば良いだけだった。

通知の設定

ここもややハマった。(実はアプリ起動時に聞かれるので良く見てたら間違えないはず)

  • 設定 - 通知 でF5 Accessの通知を有効にする
  • 通知を有効にしないと、ログイン時にユーザ名/パスワードを聞かれるポップアップが出ないので認証に失敗する

証明書インポート

証明書をメールで添付する。ポイントは長押ししてインストールするだけ。

f:id:hogem:20181108185008p:plain

添付された証明書を長押しタップ (iOS11以下でやっていたように、普通にタップするとiPhone本体にインストールされてしまうのでダメ)

共有メニューからF5 Accessを選択。ない場合はその他からF5 Accessを選んで有効にする。

f:id:hogem:20181108185014p:plain

F5 Accessを選択

f:id:hogem:20181108185023p:plain

VPNの設定

これは以前のF5 Access Legacyと同じ

apache 2.4 virtualhost 内で一部の無効な設定が警告されない

概要

こんな設定。
確認したのはRHEL7/CentOS7の標準のhttpd (2.4.6)とsclのhttpd24-httpd (2.4.27)

httpd.conf 抜粋

Loglevel warn
# 他は省略
<VirtualHost *:80>
  DocumentRoot /hoge
  <Location />
    AllowOverRide All
  </Location>

  Alias /foo       /path/to/foo
  Alias /foo/hoge  /path/to/hoge
</VirtualHost>

警告

この設定には3つの警告がある。

  1. DocumentRoot /hoge が存在していない
  2. Locationで使用できないAllowOverRide を設定している
  3. Alias /fooが優先されてAlias /foo/hogeが効かない
configtest
$ apachectl configtest
AH00112: Warning: DocumentRoot [/hoge] does not exist
Syntax OK

DocumentRoot についてしか警告が出ない。

解決した設定内容

試行錯誤した結果、Virtualhost内に任意のLoglevelを設定すると警告が出ることがわかった。

<VirtualHost *:80>
  DocumentRoot /hoge
  ## Loglevel を問題の設定より前に書く
  LogLevel warn

  <Location />
    AllowOverRide All
  </Location>

  Alias /foo       /path/to/foo
  Alias /foo/hoge  /path/to/hoge
</VirtualHost>


httpd.conf 内に既に同じLogLevel warnを設定しているけど、この設定を足すと

$ apachectl configtest
AH00112: Warning: DocumentRoot [/hoge] does not exist
[Wed Sep 05 17:59:45.814156 2018] [core:warn] [pid 9709] AH00114: Useless use of AllowOverride in line 359 of /opt/rh/httpd24/root/etc/httpd/conf/httpd.conf.
[Wed Sep 05 17:59:45.814267 2018] [alias:warn] [pid 9709] AH00671: The Alias directive in /opt/rh/httpd24/root/etc/httpd/conf/httpd.conf at line 363 will probably never match because it overlaps an earlier Alias.
Syntax OK

※ forum とかbug情報等はまだ見てない。

big-ip irule でURL Routingしているときの謎の仕様

謎の仕様というかほぼbugかな。

前提

pool を2つ容易

  • pool
    • pool1 default pool
    • pool2 特定URLを処理するpool
      • /hoge/ or /fuga/ からはじまるURL
    • pool1、pool2 ともにcookie persistence を有効
  • virtual server
    • default pool にはpool1 を適用
    • HTTP Profile を適用

irule

when HTTP_REQUEST {
  if { [HTTP::path] starts_with "/hoge/" } {
    pool pool2
  }
  elseif { [HTTP::path] starts_with "/fuga/" } {
    pool pool2
  }
}

確認した動作

よし、オッケーと思っていた。

謎の挙動

curl では再現せず、ブラウザによるアクセスで発生。
pool2 で処理するURLにアクセスして、同一ブラウザで数秒以内 (3秒ぐらい?) に
pool1 で処理するURLにアクセスすると、なぜかpool2 に振られる。


## 解決
irule に明示的にdefaultのpoolを書いたら発生しなくなった。
これが仕様らしい。

when HTTP_REQUEST {
  if { [HTTP::path] starts_with "/hoge/" } {
    pool pool2
  }
  elseif { [HTTP::path] starts_with "/fuga/" } {
    pool pool2
  }
  else {
    pool pool1
  }
}

apacheのrewriteによるredirectをmod_mruby で置き換えてみた

参考

queryがついているURLを扱う場合mod_aliasのredirectでは処理できないので、
mod_rewriteを使うことになるが、数が多いと辛くなる。
また変更の度にapache再起動が必要となる。

.htaccess が使える場合、再起動は不要だが、
apacheをreverse proxyとして利用している場合(ProxyPass)、.htaccess は使えない。

mod_mruby 使ったら簡単にできないかな?と思って少し調べたメモ。

使いそうなディレクティブ

  • mrubyHandlerMiddle
  • mrubyFixupsMiddle

- ProxyPass で扱うURL部分もredirectなどの処理対象にしたい場合はこれ?

  • mrubyQuickHandlerMiddle

- フックポイント ap_hook_quick_handler
- RewriteRule で処理しているURLもmrubyで上書きしたい場合はこれ?

mrubyQuickHandlerMiddle /var/www/mruby/redirect.rb

/var/www/mruby/redirect.rb

何もしない場合はapacheの次の処理に渡すので
Apache::DECLINED を使う

csvの処理にmodule使ってなくて、エラー処理もしてない簡単なsample

r = Apache::Request.new
s = Apache::Server.new

redirect_csv = '/var/www/mruby/redirect.csv'
hash = {}
File.open(redirect_csv, 'r') do |f| 
  while l = f.gets
    key, value = l.chomp.split(",")
    hash[key] = value
  end
end

key = r.uri
if r.args then
  key = key + '?' + r.args
end

if hash[key] then
  r.headers_out["Location"] = hash[key]
  Apache::return(Apache::HTTP_MOVED_TEMPORARILY)
else
  Apache::return(Apache::DECLINED)
end

redirect.csv

/hoge/,http://example.com/hoge/
/fuga/,http://example.com/fuga/
/hogem?num=10,http://example.com/hogem/?num=10

BIG-IP iruleでクライアントがTLS 1.1以下でアクセスしたときに別poolに振り分ける

PCI-DSS 絡みとかでTLS 1.1 以下が徐々に閉鎖されていっているなか、あらかじめWebページで告知したとしてもやはり接続してくるクライアントは一定数いてそうなので救済策を考えて見た。


TLS のバージョンはCLIENTSSL_HANDSHAKE eventで SSL::cipher version で取得できる。
(SSL3.0以下はclient-ssl profile で落としているのでここでは考慮しない)

VirtualServer にはdefaultでpoolが既に割り当てられているとする。

  • irule
when CLIENTSSL_HANDSHAKE {
    if { ( [SSL::cipher version] equals "TLSv1" ) or ( [SSL::cipher version] equals "TLSv1.1" ) } {
        pool another-https-pool
    }
}

もし、複数のVirtualServer があって、個別にirule 作るのが面倒な場合、
TLS 1.1以下のときに振るpool の命名規則さえ揃えておけば

when CLIENTSSL_HANDSHAKE {
    if { ( [SSL::cipher version] equals "TLSv1" ) or ( [SSL::cipher version] equals "TLSv1.1" ) } {
        pool [LB::server pool]-oldtls
    }
}

みたいにすれば、

のようにpool作れば、irule使い回しできそう。

ちなみにpoolが存在しない場合、clientからの接続は切断されて、/var/log/ltm にログが出る。

TCL error: /Common/tls_version_routing_test <CLIENTSSL_HANDSHAKE> - no such pool: /Common/example.com-https-oldtls (line 1)     invoked from within "pool [LB::server pool]-oldtls"

Mackerel Meetup #12 に登壇してきました

mackerel.io

8/2 に実施されたイベントに行ってきました。
会場: 目黒 アルコタワー ドリコムさんのセミナースペース

現職はマネージドホスティングを提供している会社で、
Mackerel としてはあまりなかった使い方ということで声をかけていただき、発表してきました。
監視システムに課題があったところをMackerel で解決したよ、というお話。

普段会えない開発チーム、CRE の方々と会えて良かったです。
当日はガチガチに緊張してて直前のセッションの内容あまり覚えてないので今復習してます(^p^)

資料

当日 reveal.js で作ったgithub pages にあげてしゃべってましたが、簡単埋め込みできるspeakerdeck にupしなおしました。内容は同じです。


おまけ

発表者特典でmkr Tシャツ貰えました!