CentOS5にCentOS6の環境を作ってchrootする方法を書いておく
諸事情でCentOS5の環境を渡されたので、同じ不幸に見舞われた人向けに書いておく。
一般的な話でいえば、すぐにCentOS7の環境に移行すべきだが、世の中にはいろいろな不幸があるのでめげずに頑張ってほしい。
rinse でCentOS6をインストールする
CentOSでchroot環境を作るにはrinseというものがある。Debianでいうdebootstrapみたいなツールで、 rpmパッケージを展開し、chrootできるディレクトリツリーを構築する。
古くからあるパッケージなので、CentOS以外のディストリビューションでも利用できる。
rinse のセットアップ
Debianの場合以下のようにaptでインストールできる。
apt-get install rinse rpm
CentOS6のchroot環境を用意する
mkdir -p ./centos6 rinse --directory=./centos6 --distribution=centos-6 --arch=amd64
この状態で ./centos6
を持っていけばchroot環境を持ち出せる。簡単。
CentOS6にchrootする
sudo mount --rbind /dev ./centos6/dev sudo mount -t proc none ./centos6/proc sudo mount --rbind /sys ./centos6/sys sudo chroot ./centos6 /bin/bash
END
Pythonのパッケージ管理とsystemdでプロセスをずっと上げておく方法を書いておく
タイトルは半分当たっていて、半分は嘘。
Pythonをちゃんと環境作ってやったことが今までなかったので、今わかってる範囲の情報をまとめていく。
pip
Pythonのパッケージ管理システム。Pythonで作られたプロジェクトのインストールにもよく使われている。
依存パッケージの管理
pipにはfreeze
サブコマンドがあり、現在の環境で使っているパッケージとバージョンを出力できる。
このリストをrequirements.txt
で出力しておき、pipでこれをインストールするということがよく行われているらしい。
これらは後述するvirtualenv
やvenv
と組み合わせて使うとクリーンな環境を用意できる。
環境のパッケージを出力
pip freeze > requirements.txt
環境にパッケージをインストール
pip install -r requirements.txt
virtualenv
実行環境管理ツール。rvm
がツールとしては近い。
シェルと組み合わせて仮想環境を構築する。
仮想環境にpip
を使って必要なパッケージをインストールして、動作環境を作ることでpython環境を隔離できる。
と思ったけど、Python3.3からvenv
が公式に組み込まれたと聞きつけたので、virtualenvはもっぱらPython2系の環境を隔離したいときに使うことになる。
venv
Python3.3からバンドルされている環境管理ツール。 virtualenvと同様の機能を提供するが個別にインストールする必要はなく、Python3.3以降の環境であればデフォルトで使えると考えて良い。
python3 -m venv (環境名)
venvの実行例
python3 -m venv foo cd foo source bin/activate
venvが行うこと
他にもあるかもしれない。あんまりちゃんと読んではいない。
注意点
source
を使って追加のスクリプトをシェルに食わせているので、環境はディレクトリ以下でなくとも有効。- 解除するには
deactivate
を使うが、同じ名前の関数を用意しているとハマるので注意する- まあ大した問題ではない気もする
venv環境の切り方
この辺りから我流になってくるが、動作させたいプロジェクトのディレクトリを作ったらその名前でvenvを用意してもいいと思う。
共通で使えるvenvを用意するとすぐ書き始められる利点はあるが、依存パッケージの管理と言う面ではややとっ散らかりそうな雰囲気があるので慣れてくるまでは控える。
環境を揃える
インストール
brew install python3
PATHを通す
pipでインストールされるスクリプトを簡単に呼び出せるように PATH
に追加しておくと便利。
export PATH="$HOME/Library/Python/3.6/bin:$PATH"
PDB
Pythonのデバッグツール。とりあえず適当に試したいときに使えば便利っぽい。
インタラクティブコマンド
whatis
オブジェクトの型を調べるときに使う。
> whatis res[0] <class 'dict'>
venv環境でwebサーバのように永続的に動くものをsystemdで起動する
venv環境は環境変数を切り替えた上でシンボリックリンクやコピーを使って仮想環境を構築しているので
、仮想環境にpip
で依存ライブラリをインストールした後は、仮想環境内の /bin
以下に置かれた実行可能スクリプトを直接呼び出すだけで同様の動作にできる。
例えば以下のように systemd を使って起動できる。
[Unit] Description=Gunicorn instance to serve the falcon application After=network.target [Service] User=centos Group=centos PIDFile=/tmp/gunicorn.pid Environment="PATH=/home/centos/venv/project-name-env/bin" WorkingDirectory=/home/centos/project-name ExecStart=/home/centos/venv/project-name-env/bin/gunicorn index:app --bind=0.0.0.0:8000 --reload ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID
この点はRubyのbundlerと比較して簡単に書けるので好き。結婚したい。
その他
コーディングスタイルガイド
終わり
こんなところか。あとは適当にコード書いていけばいい気はする。
とりあえずPythonはマニュアル読めばだいたい書けそうだし、 ライブラリもそれなりに充実しているので、Webアプリケーションを作るくらいなら苦労はしなさそうだ。
git-browse-remoteが恋しくなったのでgolangで書いてみた
現職場で何か足りないなーと思っていたことがあって、そうか git-browse-remote
かと思ったので、お得意の gem install
しようと思いましたが、
手元のRubyはバージョンアップのたびに入れなおすのが面倒と思ったので、golangの勉強がてらgoで書き直すことにしました。
urfave/cli
が割と簡単でこれくらいのコマンドなら簡単に作れるのがいいなと思いました。
あまり時間もかかっていませんが、golangに慣れたという感じもしないのが不思議ですね。
Visual Studio Codeを使って書いてみましたが、特にそれほど設定しなくても便利という感想です。
if
とか for
くらいしか使ってないので、スライスとかそういう概念がほぼなく練習にするにしてももうちょっと機能があるものにすればよかったかもと思いましたが、まあいいか...。
Pythonほどマニュアル見ただけで使えるようになってないけど、追々慣れていく...
勉強がてらでいうと docker とかもキメておきたいな、時間の有り余る今こそ修行
HOMEを手に入れる話
世の中にはいろいろな不幸がある。今回の不幸はユーザが作れないLinuxサーバの運用を任されたことだ。
まあ、こんな不幸は滅多に遭遇することでもないとは思うけど、今後また同じ不幸に遭遇した時のために書いておく。
こんな情報いるのか?という疑問もあるけど、不幸にもぶち当たった人のヒントになるかもしれない。ホント、みんな useradd
に感謝したほうがいい。
ホームディレクトリ
useradd
ができない環境では自分のユーザを作成できず、共通のユーザで操作することになるため、.toprc
のようないわゆるドットファイルを用意することができない。
今まで触ってきた環境があまりにもぬるま湯過ぎたのか、この事態に対処する方法がすぐには思いつかず、構築されたサーバと運用ルールを呪ったものだが、幸い他の作業をする時間があったため Linuxのホームディレクトリについて調べることにした。
まあ、いわゆるホームディレクトリについて書かれている。マルチユーザで使う時にユーザが自由にファイルを作成できるディレクトリというなんともオアシスのような世界について記述されている。
しかし現実の世界に自由はない。そもそもマルチユーザなんて世界じゃないし。
そうそう、ホームディレクトリはログインした時のワーキングディレクトリで /etc/passwd
に記述されている。
そしてホームディレクトリは環境変数 $HOME
に格納され、多くのプログラムがこれを参照する仕組みになっている。
$HOME
を設定するのはログインシェルで具体的には sshd
から呼び出される bash
みたいなものになるが、sshで接続した直後に環境変数$HOME
を設定できれば実質的なホームディレクトリが手に入る。
sshdのAcceptEnv
sshd
の設定にローカルから送られた環境変数を引き継ぐ AcceptEnv
という設定がある。
ただ、この設定は sshd
の設定で、反映には sshd
を再起動する必要があるし、
クライアント側でも SendEnv
を書く必要があるとはいえ、AcceptEnv HOME
ってのはかなりヤバい気がする。
sshでシェル起動時に環境変数を渡す
まあこっちのほうが現実的か。ログインシェルを変更する用途にも使えて便利だし。
こっちの方法は、 ssh
で bash
のようなシェルをログインモードで起動するようコマンドを渡し、その際に環境変数を上書きするという方法。
ssh -t remote_addr HOME=/tmp /usr/bin/bash -i -l
ssh
のオプション -t
は tty の割り当て。コマンドを渡す場合にはデフォルトでは tty
が生成されないため。
bash
のオプション -l
はログインシェル、-i
はインタラクティブモード。これらを指定するとよく見る入力待ちの端末が出来上がる。
ただ、ログイン直後のカレントディレクトリは /tmp
になっていない。
ログイン後 cd
するのもいいが、/tmp/.bashrc
の最後に cd
と書いておけばいいだけではある。
あと、ssh-keygen
のように一部のプログラムは $HOME
を参照しない。まあ、こいつらは数が少ないので大抵は無視できる。
終わりに
長々と書いたけど、こういう不幸にはあまり遭遇したくない。
シェル周りのオプションを調べたり、sshのことをこんなに調べるなんてことは今までなかったから面白くはあったけど普通こんなことしないし。
単に top
打ったときの動作をいい感じにしたりするのにこんなことしないといけない環境を若い子には触らせたくないね。
あ、そうそう。実はもう一つの不幸に遭遇していて、そっちは timestamp_timeout=0
を設定された環境を任されたことだけど、これは解消したからよしとする(よくはない)。
askpassのことを書いておく
askpassとは何なのか
askpass とはその名の通り、プログラムからパスワードが必要になったときに呼ばれるプログラムのこと。
よくある使われ方としては、GTKのプログラムで特権が必要になった際に、sudo
のパスワードを尋ねるためのウィンドウを出すみたいなやつ。
なので、 ssh-askpass
のようなワードで調べると、X11とかその辺が引っかかるが、そもそも askpass
が何をするものなのかよくわからなかったので、書くことにした。
askpass を思い出したきっかけ
今の仕事で特権取得を自動化できないかというのが考え始めたきっかけで、RubyのCapistranoのことを考えていた。
ちょっと前までWeb屋をやっていたころはRubyで書かれたコードをデプロイすることも多く、capistranoを使ってデプロイをしていたのですが、 その際にたまたま見かけたのが以下のエラーメッセージ。
sudo: no tty present and no askpass program specified
これは sudo
が出すエラーメッセージで、tty
がないし askpass
もないよというものである。
当時は今より弱かったので、なんのこっちゃという感じで意味もよくわからずなんとなく直していたのですが、 ふと考えてみると、capistranoで特権がいる場合に何度もパスワードを入れた覚えがないな、ということはここは自動化してるのかと気づきました。
ところで、似たようなものは Ansible を使っているときにも見かけることがあって、-K
オプションみたいなやつですね。
もちろんどちらもSSHを自動化するものなので当たり前なんですが。
askpass がやること
askpass program とか書かれると、何やら大層なプログラムなのではないかと身構えていて、なんだか大変そうと思っていたのですが、 askpassとは要はパスワードを標準出力に書き出すプログラムのことなのである。 パスワードを書き出すまでにいろいろとやるものもあるが、必要なのはパスワードを標準出力に出すところだけ。 以下のようなシェルスクリプトでも構わないそうな。。。
#!/bin/bash echo "secure_password!!!!"
askpass プログラムの指定
askpass の指定は環境変数を使う。例えばSSHのパスワード入力を自動化したければ、上記のスクリプトを /tmp/askpass
という名前で置いて、 chmod +x
しておいて
export SSH_ASKPASS=/tmp/askpass
としておく。SSHでパスワードが必要になった場合、代わりにこのスクリプトが出力する secure_password!!!!
が使われて大変便利。
capistranoはこれと同じようなことを、sudoでも使っていて、内部的には sudo -A #{command}
とでもしているんだろうとは思う。
何はともあれ
askpassを使うとパスワードの入力を自動化できるので使いこなせば非常に便利。
ただ、調べ方がうまくないとその存在に気付きづらい。こういうのみんなどうやって調べているんだろ。
すごいどうでもいいんですが、転職したばっかりなのに割と飽きてるので、現状引き抜きOKなエンジニアです。
そこそこ使えるストレージサーバを作るときに考えていたこと(概念)
前置き
私がWebサービスの会社でサーバ構築・運用の仕事をやっていた頃の話です。
ストレージサーバはユーザさんのコンテンツを保存する重要なサーバでしたが、 コンテンツの増加に伴い、既存のサーバでは十分な性能を出せていなかったことがありました。
運用面でのコスト増加、スケールアウトを行う上での問題などいくつかの条件が重なった時期を見て、 コスト計算、技術的な問題点などを洗い出し、サーバを新規に作り直す提案をしたところ、会社として了承が得られ、 ちょっとしたリプレイスを行うことになりました。
その際、運用コストが増加している原因をあわせて取り除きつつ、安定するサーバ構成を取れればよいと思い、 ストレージサーバの性能向上と、データ冗長化を強化できる構成としました。
目標は、低コストで読み込み性能がそれなりにあり、メンテナンス性がよく耐障害性のあるサーバですが、 確保した予算を超えない範囲で性能、安定性の向上を果たす必要があります。
この件では考える機会が多く、日頃知っている知識を広く使った総合的なお仕事でしたので、 自分でも後から見直したときに便利そうということでまとめておきます。
(余談ですが職場にはこのページには書いていない具体的な戦略などをまとめた文書を置いてあり、 また特定の環境のことについては触れていないため、同僚の方は読まなくても差し支えないと思います。)
続きを読むC92夏コミに来てくださった皆様、ありがとうございました!
C92お疲れ様でした。ようやく落ち着いたのでちょこっとアフター記事を書きます。
今年の夏コミは曇りということもあって比較的涼しく過ごしやすい天候でしたね。
た13bは東7ホールの端っこです。よろしくお願いしますー pic.twitter.com/yHswKSOIf2
— シリルういろう@金曜日東た13b (@d_cyrill1129) 2017年8月10日
東7ホールめっちゃ涼しい😇
— シリルういろう@金曜日東た13b (@d_cyrill1129) 2017年8月11日
今回は東7ホール配置でした。東7ホールは空調がちゃんと効く素晴らしいホールなので端に配置された!とか思ってはいけません。
C92参加のお知らせを直前まで出せずほぼ告知なしの状態でしたが、足を運んでいただいた皆様には感謝です。
今回は既刊のひだまりPHP vol3と新刊のAnsible本を持っていきましたが、 手で持っていけるくらいの少ない搬入数でしたので、お昼過ぎにすべて完売しました。
結構疲れが来てるので今日は撤収します!ありがとうございましたー!
— シリルういろう@金曜日東た13b (@d_cyrill1129) 2017年8月11日
13時前には抜けてしまったので遅めに来てくださった方には頒布できず申しわけなかったです。
次回のC93はサークル参加は見送りの予定です。
またどこかでお会いできる機会があればぜひお越しください。
夏コミ打ち上げっぽい写真です pic.twitter.com/SADJPmrATZ
— シリルういろう@金曜日東た13b (@d_cyrill1129) 2017年8月15日