これあんまりやらんからすぐ忘れちゃう。
mail -S "smtp=smtp://192.0.2.1:25"
もしくは~/.mailrc
set smtp=smtp://192.0.2.1
ちなみにsendmailコマンドの場合
- /etc/mail/submit.mc
FEATURE(`msp', `[192.0.2.1]')dnl
あとでまじめに調べる
perconaはMySQL互換で独自機能を加えたRDBサーバ
Slowログに拡張がされてたりするのは良い感じ。
http://qiita.com/nownabe/items/7d4420f8a657aafe85f6
http://qiita.com/nownabe/items/462f46f2702ce1ad4b6d
便利ソフトウェアです。
incronを知らなかったので、昔はこんなことしてた。
inotifywatchでイベントを監視してコマンド実行する
一時的なコマンドならこれでも良かったけど、ファイルが増えるとさすがに面倒。
incrondはincrontabコマンドでcrontab風に書かれた設定ファイルを読み込んで、指定したファイルに変更があれば、特定のコマンドを実行してくれる。
yum install incron --enablerepo=epel service incrond start
incrontabを編集したらincrontab -d でreloadする
event 一覧は
# incrontab -t IN_ACCESS,IN_MODIFY,IN_ATTRIB,IN_CLOSE_WRITE,IN_CLOSE_NOWRITE,IN_OPEN,IN_MOVED_FROM,IN_MOVED_TO,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_CLOSE,IN_MOVE,IN_ONESHOT,IN_ALL_EVENTS,IN_DONT_FOLLOW,IN_ONLYDIR,IN_MOVE_SELF
ファイルの変更を検知したい場合は
IN_MODIFY,IN_ATTRIB,IN_CREATE,IN_DELETE,IN_MOVE
このあたりを設定しておけば良い?
たぶん普通?は逆で、例えば 403 error時にproxy_passではなく
localのerror_pageを見せたいというときは
こう。
error_page 403 /403.html; proxy_intercept_errors on;
今回は、403 error時にbackendのapacheの特定のURLを見せたいという場合
named locationでいけた。
error_page 403 @error; proxy_intercept_errors on location @error { set $error_page "/index.jsp"; proxy_pass http://backend-tomcat$error_page; }
proxy_passには直接urlを書くとsyntax errorになったので
一旦変数をかましている。
proxy_pass" cannot have URI part in location
30日、5Mbps制限の評価版
参考:
hogem.hatenablog.com
www.f5networks.co.jp
証明書によるクライアント認証を行いたい場合、
普通はclientssl profile でClient Authenticationにrequireにする。
かつ、OCSP レスポンダを使う場合はvirtualserverでAuthentication Profilesを選択する。
が、big-ip APMを使う場合、Client Authenticationはignoreかrequestにしないと
(requireを選ぶと)、ログイン後でネットワークアクセスを選択した場合に
"コンフィグレーションをダウンロードできませんでした"とエラーになった。
ただ、OCSP Responderを使う場合はrequestにしないと証明書チェックで失敗した。
From the Client Certificate list, select the option that is applicable to the item you selected when you edited the access policy.
Select request if the Client Cert Inspection agent is used in the access policy.
Select ignore if the On-Demand Cert Auth agent is used.
OCSPレスポンダはaccess policyでしなくて、
virtualserver の時点でチェックしてもどっちでも出来た。
APM単体で考えたら、他でも色々な認証とか制御をするならaccess policyで統一しておくほうが良いかも?
一方、他のvirtualserverでSSLクライアント認証をやっていて、OCSP Responders Profileを使っている場合、
virtualserver側でOCSP Respondersやっても良い気がする。
つまりどっちでもいい。
Windows、Mac + Safari/ChromeではどちらでOCSP 認証をしても問題はなかったけど、
Mac + FirefoxでのみvirtualserverでOCSP認証をするとSSLエラーで接続できなかった。
(Compatibility Matrixにないfirefox versionだったのも関係あるかも)
いろいろあるけど、個人的に扱いやすいかなと思ったのは
Local Database (big-ipに認証情報持つ)
RADIUS
HTTP
にくわえて証明書失効チェックをする場合はOCSP Responderも併用
何となくの雰囲気だけど、あまり認証などの仕事をbig-ipでさせたくないので、
数10ユーザぐらいの規模: Local Database
それ以上になったら外部の認証サーバ使いたい。
Form Basedな認証(user,passをPOST)やbasic認証がある。
他webアプリケーションと連携するなどで、DBにuser/passをもたせてformで認証したり、
単純にbasic認証使ったりできる。
Form Basedの場合
Start URL: FormのURL
Form Action: POST先のURL
Successful Logon Detection Match Type:
リダイレクトするURL(By Resulting Redirect URL)、応答文字列(By Specific String in Response)など。
Successful Logon Detection Match Value: 判別する文字列
status codeでは判別できないぽい。
文字列で"200 OK"で設定してログイン成功した場合のみに200 OK を返すアプリ書いてみたけど認証失敗しても通ってしまった。
たぶんStart URLのFormを見に行ったときにもレスポンスヘッダが200 OKになるからだと思う。
なんか微妙な気がするけど、手取り早く認証が通ったときだけ特定の文字列を応答するようにして、
それをSuccessful Logon Detection Match Valueに設定しておいた。
あらかじめデータベースに設定しておいて
Session Variable:session.localdb.groups
DB Property: groups
を選んであとはBranch Rulesで分岐を作っていく
devcentral.f5.com
例えばwebアプリケーション側でX-GROUP: hogehoge などとヘッダでグループを返すようにしておいて、
variable assignで
session.custom.groupname = regexp {X-GROUP: (\w*)} [mcget {session.http.last.response_header.0}] 1 group; return $group
とやれば、session.custom.groupname でグループを取ってこれる。
groupだけの分岐条件を作るならGeneral Purpose - Emptyあたりから作れば良い。
expr { [mcget {session.custom.groupname}] eq "group1" }
適当なアトリビュートでグループの情報を返す。
例えばReply-Messageに設定した場合は
session.radius.last.attr.reply-message
で取ってこれる。
default 以外のroute domainを割り当てる場合は各種認証が終わって、resource assignする直前で、
Route Domain and SNAT Selection を割り当てればよさげ。
(認証の手前でやってもいいけど、各種リソースの割り当ての分岐を考えるとリソースアサインの直前がわかりやすそう)
access policy内でroute domainを割り当てるため、
split tunnelingを使う場合でもNetwork Access - Network Settingsで
192.168.0.0%1/255.255.255.0 などのようにroute domainのIDで設定する必要なく、
普通に192.168.0.0/255.255.255.0 とすれば良い。
webブラウザ or Edge Client から接続
初回に管理者権限が必要
natしていたらsource ipはbig-ipのself ipになる (floating ipではない)
(snat poolで他のIPに割り当てることも可能)
big-ip 自身のvirtualserver宛に通信する場合は
source ipはnatされずにdhcpで払い出した(lease poolで設定)IPから来る?
natしなかったらクライアントに払い出す仮想IPアドレスになるのでサーバ側でroutingが必要になる
(default gatewayがbig-ipに向いてたら不要?)
nat について追記
https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-visual-policy-editor-11-5-0/3.html#unique_728503150
Network AccessでSNATがnone以外に設定されている場合は常にそれが適用される。
(access policy内でRoute Domain and SNAT SelectionによるSNAT変更は不可能)
ちなみにnetwork accessのSNAT automapの場合、floating ip ではなくnon-floatingのself ipでnatされる。
VirtualServerでSource Address TranslationでSNAT automapでもnatできる。
こちらの場合はfloating ipでnatされる。
network accessの簡易版?
特定のIP、portのみをトンネルする
sshの-L のport forward のようなもの
app tunnel接続時に、remote desktopを起動して自動的に目的のhostに接続、というようなことができる。
Application Path: C:¥windows¥system32¥mstsc.exe
Parameters: /v:%HOST%:%PORT%
webアプリケーションのみに利用可能
big-ipがリバースプロキシになる
clientはブラウザだけあれば良い
リンク先はbig-ipが書き換える
(なのでvirtual serverにrewrite profileを当てる必要がある)
big-ipがリバースプロキシになるので、NATは不要だと思ってたけど、動作/パケットキャプチャを見ている限り、
VirtualServerのSource Address TranslationでNATするか、
access policyのどこかでRoute Domain and SNAT Selectionを適用してNATする必要ある。
とりあえずFullを割り当てておくのが無難。
単一のリソースしか割り当てない&ログイン時に自動的に目的のリソースへアクセスさせたい、
ということであればfullではなくそれぞれの接続方式にあったものを選ぶと良い。
ログイン時に任意のリソース(接続方式)を選べる。
Resource Assingで複数のportal accessを設定しておけば、
複数のwebアプリケーション、network accessへアクセス可能。
1つのwebアプリケーションだけ指定可能
クライアントはapmにログインした瞬間にwebtopで設定したURLにアクセス
=> Resource Assignで指定したportal accessのURLは無視される
1つのnetwork accessのみ利用可能
resource assignで複数のnetwork accessをアサインしていても
webtopがnetwork accessにしていると自動的に1つのみが選ばれてしまう
ややこしいのは/var/log/apmには
notice apd[12278]: 01490008:5: 2a35b42c: Connectivity resource '/Common/network_access1' assigned notice apd[12278]: 01490008:5: 2a35b42c: Connectivity resource '/Common/network_access2' assigned
と2つアサインされて見えるが、実際にはnetwork_access1 のルーティングしか追加されていなかった。
Logon PageをOn-Demand Cert Authより前に持ってこないとEdge Clientから接続できなかった。
証明書インストールしてアクセスして、ログインしても
tail -f /var/log/apm して見てるとなぜかUsername が空白で処理されている。
PCの場合はOn-Demand Cert Authが始めでも大丈夫。
まあログインできればどっちでもいいんだけど、
On-Demand Cert Authを一番初めにもってくる利点としては
1. Logon Pageの前にVariable Assignを持ってきて
session.logon.last.username = expr { "[lindex [split [lindex [split [mcget {session.ssl.cert.subject}] ,] 0] =] 1]" }
などとすれば、証明書からusernameを自動入力させられる。
かつLogon PageでusernameをReadonly yes にしておけば変更もできなくなる。
補足
正確に言うとLogon Page をOn-Demand Certの前に持ってきたとしても、
On-Demand Certの直後にvariable assignをつかって
↑のsession.logon.last.username を証明書から読み取れるので
Logon Pageでusername はnoneにしてても良い。
2. 証明書がインストールされていない時点でtlsの接続を拒否するので、
ログインページすら表示させないでよくなる。
もちろんOn-Demand Cert Authが後ろの場合でも証明書を持ってなければ
ログインできないからそない気にしなくても良いけど。
シェルスクリプトの平文パスワードをセキュアにする方法
これ良いですね。たいていの場合、sshの認証で鍵を作ってるだろうから
余計なファイル作らなくてもできるので手っ取り早いし。
### encrypt $ openssl rsautl -encrypt -inkey ~/.ssh/id_rsa -in plain.txt -out pass.rsa ### decrypt $ openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in pass.rsa
続きのエントリで書かれてるように運用次第で何がいいか変わりそうだけど
パスワード共有するときに良さそう。