[Environment]::GetEnvironmentVariable(<環境変数名>,[EnvironmentVariableTarget]::User)
で現在の値がゲットできる。
[Environment]::SetEnvironmentVariable(<環境変数名>,<値>,[EnvironmentVariableTarget]::User)
でセットできる。
pathを追加する場合は
[Environment]::SetEnvironmentVariable("path",[Environment]::GetEnvironmentVariable("path",[EnvironmentVariableTarget]::User)+<値>,[EnvironmentVariableTarget]::User)
こんな感じ。
DHCP パッケットをDHCPサーバへ転送するエージェント。
DHCPclient -- DHCPrelayagent -- DHCPserver
みたいな感じで、DHCPclientとDHCPserverが同一セグメントにいない場合に間に入ってくれるやつ。
clientから、DHCPDISCOVERがブロードキャストされると、relayagentは、giaddrにパケットを受け取ったインターフェースのアドレスを入れ、 serverがある方のインターフェースからパケットを送信
serverは受け取ったDHCPDISCOVERをもとにDHCPREPLYパケットを作成。このとき、OFFERするIPAddresは、giaddrを見て決める。 作成したパケットは、giaddr宛に送信。
relayagentは、DHCPREPLYパケットを受け取ったあと、giaddrを見て、送信するインターフェースを決め、そこからclientに向けてパケットを送信する。
DHCPclient -- ○DHCPrelayagent● -- DHCPserver
つまり、serverがいる方。ただ、serverからの戻りは、giaddrが宛先になっています。(でないとrelayagentがどのアドレスからそのパケットを送信すればよいか判断できなくなるため RFCに記載がある。)
relayagent と serverの間に、ステートフルなFirewallがあったりすると…… relayagentから送信したパケットの戻りが、同一ステートとみなされず、破棄されることが。
Cisco IOSは、relayagentのsource addressをgiaddrに合わせている。ASAは、serverに近い方のアドレスだったのを、IOSに合わせる変更を行っている (CSCuo89924)。
Juniperは、紆余曲折あったようで 最初はsource addressをgiaddrに合わせていて変更不可だったのを、serverに近い方のアドレスに変更し、最後には、source addressをgiaddrに合わせるのをデフォルトとして、設定で変更できるようにしている。
Linux(CentOS7)では、source addreessは、宛先端末へ近いインターフェースのものが使われる。
ステートレスに扱うよう、対応してほしい。
Web API: The Good Partsを読みました。
WebAPIを作るうえで、どんなことに気を付けるとよいのかというのがコンパクトにまとまっていてよかったです。
基本は、長いものに巻かれろ。多数は正義。みたいな感じでしょうか。
ほかのAPIをたくさんみて、どんな風に作っているのか、同じように作れば、ユーザは混乱しない、という事実。
また、HTTPの特性をきちんとつかって、無駄なmetadataを付与しないというのも重要なんだなぁと。
HTTP Status Code 200 で、responseが {"error": "500","message":"some error"} みたいなのはまぁありえないっしょという。
最近の話なので、セキュリティにも言及しています。
配列ではなくオブジェクトを返したほうが若干セキュアだよとか、ブラウザで直接アクセスすることを想定していないのであれば、そうでないことを示すヘッダを付けて、scriptタグで読み込めないようにしましょうとか。
そんな感じで、なんとなく、基本的なところを抑えておくには良い本だと思いました。
