Ubuntu18.04でPython環境構築
先日、Ubuntu18.04LTSがリリースされました。早速、Windows 10のVirtualbox上にUbuntuをインストールしてPythonの環境構築を行ったので知見をメモしておきます。
pipのインストール
下記のコマンドを実行します。
sudo apt-get install python3-pip
pipのアップデート
以下のインストール時のpipが9.0.1(最新は10.0.1 2018/05/04現在)だったのでアップデートします。
pip3 --version # pip 9.0.1 sudo pip3 install --upgrade pip # pip 10.0.1
venvのインストール
仮想環境構築に用いるvenvも入っていなかったのでapt-getをインストールしていきます。
sudo apt-get install python3-venv
これで最低限の実行環境が整ったかなと思います。
おまけ
以下はおまけでVSCodeをインストールしてPythonの拡張機能を追加します。
VSCodeのインストール
Pythonのコーディングに用いるエディタはPythonの特性上、何でも良いですが、個人的な好みでVSCodeをインストールします。 下記の記事を参考にインストールしていきます。
https://vscode-doc-jp.github.io/docs/setup/linux.html
ただ、記事に書いているコマンドそのままだとパッケージの依存関係でエラーが発生するので下記の順番で実行します。
sudo apt-get install -f sudo dpkg -i [ダウンロードしたインストーラーのパス].deb sudo apt-get install -f
これでインストールが完了して、
code
で起動するようになります。
Python拡張機能のインストール(CUI)
以下のコマンドを実行すると一発でPythonの拡張機能をインストールすることが可能です。
code --install-extension ms-python.python
これでコーディングできそうな感じですね。
WSLホストにSSHができるようにする
日本時間の5/1にWindows 10の機能更新プログラムの配信が開始になりました。 このアップデートによってWSLがバックグランドで実行できるようになりました。
今後、リモート上の端末(例えば、Macだったりとか他の端末からteratermで接続するとか)からWSLにSSH接続を行なって作業を行いたいとかansibleで設定を行いたいという需要も増えてくるかと思いますのでリモートからSSH接続を行う方法を書きたいと思います。
今回の実行環境
SSH接続先:Windows 10 Pro(version1803) SSH接続元:MacOS X 10.12.6
Windows自体の設定
まずは、ホストとなるWindowsに対して設定を行なっていきます。
SSHサービスの停止
まずは、WSLと競合する二つのサービスを停止します。 スタートメニューもしくはWindowsボタン+Rで「ファイル名を指定して実行」を開いて、「サービス」画面を立ち上げます。 そして、以下の二つのサービスを「無効」にします。
ファイアウォールの設定
Windowsファイアウォールが競合して接続できなくなるのでファイアウォールの設定を変更します。
既存プロファイルの無効化
次にセキュリティが強化されたWindowsファイアウォールを開き、受信の規則から以下の規則を無効化します。
- SshProxy-Service-Domain
- SshProxy-Service-Private
新規プロファイルを作成
そして、新たに以下のような規則でプロファイルを作成します。
- ローカルポート:22番
- アクション:許可
※必要に応じて接続元IPアドレスを指定しても構いません
以上でWindows側の設定はおしまいです。
WSL側の設定
WSL側でも以下の通りに設定を行います。
sshd_configの設定
ssh_configファイルを以下のように変更してSSH接続を受け付けるようにします。
- UsePrivilegeSeparation をnoに設定する
- AuthorizedKeysFile %h/.ssh/authorized_keys にかかっているコメントを外す
接続元の設定
接続するクライアントの設定です。
SSH公開鍵の作成、転送
以下の通りにコマンドを作成してSSHキーを作成し、接続先の「authorized_keys」に保存します。
cd ~/ mkdir .ssh chmod 700 .ssh vi .ssh/authorized_keys chmod 600 .ssh/authorized_keys ssh-copy-id [ユーザ名]@[ホスト名]
以上で設定は全て終了です。
これで
ssh [ユーザ名]@[ホスト名]
と接続すると接続ができます。
AWSで請求内容をIAMユーザで確認できるようにする
今日朝からAWSを初めて見て、できる限り「rootをできる限り使用しない」と考えたときに、「請求内容もIAMユーザで見たいな」と思って権限をつけても見ることができなくて少しハマったので備忘録を兼ねてメモ
通常IAMユーザに請求書を見る権限をつけたとしても以下のような画面が表示されて、請求情報を見ることができないです。
これを解消するにはrootユーザにて以下のように設定する必要があります。
手順
1 rootユーザにてログインする。
2 アカウント画面を開いて、「IAM ユーザー/ロールによる請求情報へのアクセス」を確認する。 3 「IAM ユーザー/ロールによる請求情報へのアクセスは有効になっています。」ことを確認する。もし「無効になっています。」という表示が出たら右上の「編集」ボタンを押す。 4 編集ボタンを押すと「IAM アクセスのアクティブ化」という欄が表示されるのでチェックマークをつけて更新ボタンを押す。
5 その後、請求書を参照したグループに以下の権限を付与する。
- ViewBilling
これでIAMユーザでも請求内容を確認することができるはずです。
rootを使わせない以外にも経理の人にコンソールを見るだけの権限を与えるなどに使用できそうですね。
2018年5月に配布される更新プログラムを適用するとリモートデスクトップに接続ができなくなる可能性がある件
※レジストリに関して言及している箇所がありますがあくまでも設定は自己責任でお願いいたします。
今のところあまり騒がれてないですが、バッチ適用の運用方針によっては結構影響範囲が大きいと感じたので書いてみました。
ざっくりまとめると
- 5月度の月次更新プログラム適用でリモートデスクトップ接続ができなくなる可能性がある
- 3月の月次更新プログラムでリモートデスクトップ接続に関する脆弱性が修正された
- これにより脆弱性に対処していないサーバ×脆弱性に対処したクライアントという組み合わせでリモートデスクトップ接続ができなくなった
- ただし現状は明示的にグループポリシーもしくはレジストリの設定を変えないと事象は発生しない
- 5月度の更新プログラムを適用したクライアント端末は同時に新しく追加されたグループポリシー(もしくはレジストリ値)を変えないと更新プログラムを適用していないサーバにリモートデスクトップ接続ができなくなる
詳細
2018年3月度月次更新プログラム
現状サポートがされているほぼすべてのバージョンのWindowsOSにて3月度の月次更新プログラムでリモートデスクトップ接続における脆弱性の対処がなされました。 MS公式のドキュメントはこちら。認証プロトコルに脆弱性が見つかり放置状態だと情報が抜き取られる危険があるそうです。(※ただし実際に実行するためにはさらに何ステップか踏む必要があり今のところ悪用事例はないです) この月次更新プログラムによって以下のグループポリシー(およびレジストリ)が追加されて脆弱性に対処が可能な状態となりました。
ポリシーのパス | 設定名 |
---|---|
[コンピューターの構成] -> [管理用テンプレート] -> [システム] -> [資格情報の委任] | Encryption Oracle Remediation |
設定値 | クライアント側動作 | サーバ側動作 |
---|---|---|
Force updated clients | 脆弱性に対処していないサーバにリモートデスクトップ接続できない | 脆弱性に対処していないクライアント端末からのリモートデスクトップ接続を受け入れない |
Mitigated | 脆弱性に対処していないサーバにリモートデスクトップ接続できない | 脆弱性に対処していないクライアント端末からのリモートデスクトップ接続を受け入れる |
Vulnerable | 脆弱性に対処していないサーバにリモートデスクトップ接続できるがそれによってリモートサーバーは攻撃にさらされることになります。 | 脆弱性に対処していないクライアント端末からのリモートデスクトップ接続を受け入れる |
レジストリのパス | 値 | データの種類 |
---|---|---|
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters | AllowEncryptionOracle | DWORD |
各値は
Force updated clients→0
Mitigated→1
Vulnerable→2
となります。
ただし、現状は既定値を「Vulnerable」としているのでグループポリシーやレジストリの設定を加えていない場合はリモートデスクトップ接続が可能な状態となっております。(ただし「Vulnerable」だと脆弱性は放置されたままになります)
5月度月次更新プログラムにて
上記のように移行期間の形をとっていた上記の脆弱性ですが2018年5月の月次更新プログラムにて本格的な対処が行われることとなり、特に何も設定していないときの既定値が「Vulnerable」から「Mitigated」に変更されます。そのため、クライアント端末に対して5月度の月次更新プログラムを適用した状態では月次更新プログラム未適用のサーバに対してリモートデスクトップ接続が出来なくなります。 すなわち、クライアント端末に対してはバッチの適用を毎月行うが、サーバに対してはバッチの適用を行っていないという運用をしている場合は5月月次更新プログラムを適用した端末からリモートデスクトップ接続を行うことができなくなります。
対処方法
下記のいずれかの対応を行う必要があります。
- すべてのクライアント端末およびリモートデスクトップサーバになりうる端末において5月度月次更新プログラムを適用する
- すべてのクライアントに対して上記で述べたグループポリシーまたはレジストリの設定を適用する(※ただし、脆弱性は放置)
おそらく、残りの期間と影響を考えると多くの会社さんでは暫定で2.の対処をしつつ1.の対処も可能な範囲で進めていくのが現実的かなと思います。 ともかく、5月の月次更新プログラムを配布してユーザさんから「リモートデスクトップ接続ができなくなった」と言われないように今から準備しておきたいものですね。
【Hello】ansibleに入門してみた【ansible】
きっかけ
前から使おう使おうと思っていたansibleを少し触ってみて色々苦労しながら簡単な設定を入れたりはできるようになったので備忘録を兼ねてメモを残しておこうと思う。
要件
色々考えてみて、一個のファイルを単純にmain.ymlに全てを書くよりは最初からある程度roleに各設定値を外出ししていくことに慣れていければと思って以下の通りの要件でやることにする。
- ホストOS:OS X 10.12 ターゲットOS:CentOS7.4
- commonsetロール内のタスクを実行する
- タイムゾーンをAsia/Tokyoに設定する
- SELinuxをpermissiveにする
- ファイアウォールでTCPポート80番をdisableに443番をenableに設定する
実際に設定したファイル
以下のように実装した。一応実行したら無事にタスクが実行できたのでこれで問題にないかと。 ansibleは入れ方が色々あるけど自分はpipでインストールした。
./roles/commonset/tasks/main.ymlにおいて、カレントディレクトリのmain.ymlを実行する
作成する中で苦労したこと
- 普段は案件でWindows系の仕事しかやってない(Windowsの案件しかやったことない)せいかLinuxの基本的な部分がわからなかったように感じた。特にターゲットサーバにssh接続する部分は久しぶりに物理上の端末にvirtualboxで仮想マシンを立てる作業をしたのでいろいろなサイトを見てやっとできるようになったという感じだった。
- ymlファイルのお作法的な部分がわからなくてansibleさんにすごく怒られた。
- まだ一つのロールを実行しているだけだけど「これを業務で使うレベルまでスケールさせるときにタスクの分け方とかどうするんだろう」みたいな疑問を感じた。(この辺はansibleのコードに限らずプログラマな人のコードを見てどうやって関数とか分けてるんだろう、どう設計しているんだろうみたいな視点を持って業務に当たりたいなと思った)
今後は
- このファイルを用いて例えば、wordpressのインストールを自動化するなどやっていければいいなと思う。(phpとかMySQLとかロールに設定したし...)
- serverspecとかと連携して、インフラの構築からテストまで自動化できるみたいなことできるといいな
とかとか色々思ってるので、また時間ができたら色々いじりたいな思う。
terraformでカンタンAzure操作
きっかけ
職場の勉強会でgitとgithubの簡単なデモをした時にAzureでデモをしようと思った。 普通ならAzure PowerShellなりを使うことが多いけど運が良いのか悪いのか以前に勉強会でAzure PowerShellを取り上げてしまった。 どうしたものかと思ってる時に - terraformというものでもInfrastructure as Codeなことが出来ること - マルチクラウドの管理に対応しているので今後なんか使えそう(独断と偏見)
という二点から試しに使ってみることにした。
要件
今回は試しということもあり以下のような簡単な要件で作成した。
- Azure上に簡単なストレージアカウントを作成する
- ストレージアカウントにテキストファイルを置く
- 置いたテキストファイルには誰からもアクセス可能(匿名アクセス可能)
ハマったところ
主にterraformとAzureの連携の部分で苦労したがこちらのブログを参考にした。
また、Azureの仕様だがストレージアカウントの名前がダブってしまってエラーとかも多く出してしまった記憶
作成したコード
早速実践ということで以下が作成したコードである。
ちなみに匿名アクセスを許可するうにはcotainer_access _typeをblobもしくはcontainerにすることで匿名アクセス可能である。
やってみた感想
HSLによってGUIポチポチでオペレーションミスを誘発するといった危険性を排除することができる(検証環境で実行した結果をそのまま「terraform apply」で使用できる)といった点はすごく便利だなと感じた。 その一方で大規模環境などでどの程度通用するか、使えるかはまだまだ検証の余地があるなと感じた。 もっと色々試してみたいなと思う。
気なったツイートをPython3でサクッと実装してみた
なんとなくTwitterをみていたら気になるツイートが目に留まりました。
有名な統計力学ゲーム。6人が均等にコインを持つとする。サイコロを二つ振り、一つ目の出目の人はコインを中央に、二つ目の出目の人はそのコインを貰う。無い人は出さない(借金なし)。これを繰り返すと少数の金持ちと多数の貧乏人ができる。ルール平等でも貧富の差が。
— Yuki Nagai (@cometscome_phys) January 8, 2018
これを見た私は以下の二点のことを思い浮かべました。
- 確率は収束するんだから嘘に違いない
- 調べるの簡単そう…
ということで、実際にコードを書いて検証することにしました。ただ、そのまま実装しても面白くないような気がしたので人数は100人としました。
環境は、
- Python3
- Jupyter Notebook
を用いることにしました。
以下、汚いですがコードを晒しておきます。(特に、再利用等考えてなかったので関数などもルール無視ですがご容赦を。。。)
このような結果から、
多少の上下動はあるものの、試行回数を増やせば増やしていくと、中央値は低下し、標準偏差は大きくなる傾向にあった(格差が拡大している)
と言えるのではないでしょうか。
ある意味人生もこのような偶然のような運命がいたずらして大きな結果の差になるのかもしれませんね。