なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

git-browse-remoteが恋しくなったのでgolangで書いてみた

現職場で何か足りないなーと思っていたことがあって、そうか git-browse-remote かと思ったので、お得意の gem install しようと思いましたが、 手元のRubyはバージョンアップのたびに入れなおすのが面倒と思ったので、golangの勉強がてらgoで書き直すことにしました。

github.com

urfave/cli が割と簡単でこれくらいのコマンドなら簡単に作れるのがいいなと思いました。

あまり時間もかかっていませんが、golangに慣れたという感じもしないのが不思議ですね。

Visual Studio Codeを使って書いてみましたが、特にそれほど設定しなくても便利という感想です。

if とか for くらいしか使ってないので、スライスとかそういう概念がほぼなく練習にするにしてももうちょっと機能があるものにすればよかったかもと思いましたが、まあいいか...。

Pythonほどマニュアル見ただけで使えるようになってないけど、追々慣れていく...

勉強がてらでいうと docker とかもキメておきたいな、時間の有り余る今こそ修行

HOMEを手に入れる話

世の中にはいろいろな不幸がある。今回の不幸はユーザが作れないLinuxサーバの運用を任されたことだ。

まあ、こんな不幸は滅多に遭遇することでもないとは思うけど、今後また同じ不幸に遭遇した時のために書いておく。

こんな情報いるのか?という疑問もあるけど、不幸にもぶち当たった人のヒントになるかもしれない。ホント、みんな useradd に感謝したほうがいい。

ホームディレクト

useradd ができない環境では自分のユーザを作成できず、共通のユーザで操作することになるため、.toprc のようないわゆるドットファイルを用意することができない。

今まで触ってきた環境があまりにもぬるま湯過ぎたのか、この事態に対処する方法がすぐには思いつかず、構築されたサーバと運用ルールを呪ったものだが、幸い他の作業をする時間があったため Linuxのホームディレクトリについて調べることにした。

ホームディレクトリ - Wikipedia

まあ、いわゆるホームディレクトリについて書かれている。マルチユーザで使う時にユーザが自由にファイルを作成できるディレクトリというなんともオアシスのような世界について記述されている。

しかし現実の世界に自由はない。そもそもマルチユーザなんて世界じゃないし。

そうそう、ホームディレクトリはログインした時のワーキングディレクトリで /etc/passwd に記述されている。

そしてホームディレクトリは環境変数 $HOME に格納され、多くのプログラムがこれを参照する仕組みになっている。

$HOME を設定するのはログインシェルで具体的には sshd から呼び出される bash みたいなものになるが、sshで接続した直後に環境変数$HOMEを設定できれば実質的なホームディレクトリが手に入る。

sshdのAcceptEnv

sshd の設定にローカルから送られた環境変数を引き継ぐ AcceptEnv という設定がある。

ただ、この設定は sshd の設定で、反映には sshd を再起動する必要があるし、 クライアント側でも SendEnv を書く必要があるとはいえ、AcceptEnv HOME ってのはかなりヤバい気がする。

sshでシェル起動時に環境変数を渡す

まあこっちのほうが現実的か。ログインシェルを変更する用途にも使えて便利だし。

こっちの方法は、 sshbash のようなシェルをログインモードで起動するようコマンドを渡し、その際に環境変数を上書きするという方法。

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 を思い出したきっかけ

今の仕事で特権取得を自動化できないかというのが考え始めたきっかけで、RubyCapistranoのことを考えていた。

ちょっと前まで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お疲れ様でした。ようやく落ち着いたのでちょこっとアフター記事を書きます。

今年の夏コミは曇りということもあって比較的涼しく過ごしやすい天候でしたね。

今回は東7ホール配置でした。東7ホールは空調がちゃんと効く素晴らしいホールなので端に配置された!とか思ってはいけません。

C92参加のお知らせを直前まで出せずほぼ告知なしの状態でしたが、足を運んでいただいた皆様には感謝です。

今回は既刊のひだまりPHP vol3と新刊のAnsible本を持っていきましたが、 手で持っていけるくらいの少ない搬入数でしたので、お昼過ぎにすべて完売しました。

13時前には抜けてしまったので遅めに来てくださった方には頒布できず申しわけなかったです。

次回のC93はサークル参加は見送りの予定です。

またどこかでお会いできる機会があればぜひお越しください。

HTTPでバックアップファイルを軽く配る

最近はバックアップファイルを配る時にHTTPを使っている。

クライアント側では curl を使って手軽に引っ張ってこれてそのまま tar に流して簡単に展開できて便利。

あとは scp だとCPUが貧弱なマシンだとやや使いづらい。

クライアント側からのアップロードをするには WebDAV を使う必要があって少し手間だけどその程度で一回用意すれば使い勝手はそこそこよい。

あとは Subversion と組み合わせるのとかも便利かな。いや、これはどっちでもいいか。

curl

curlでhttpリクエスト飛ばすだけでいいけど、バックアップサーバはHDDのようなストレージを乗せていて、 バックアップを取ってる時に復元しようとするとIO的にしんどいタイミングがある。

そういうタイミングは --limit-rate をつけてちょっとだけ優しくするとよい。

curl --limit-rate 100M http://backup.local/data.tar.gz | tar xzv

100M は何となく。シーケンシャルで取るならHDDでも100Mくらいは軽く出るけど、出ないときもあるのでその時はもっと優しくする。 あとは、 ionice しておくとか。ただサーバ側でつけるのは面倒だしクライアント側だけで完結する --limit-rate 程度が手間がなくていいかな。人力なのがちょっとだけ温かみがある。

rsync と scp

暗号化されてCPUが貧弱だと辛い時があるけど、一般にはよく使われる。 rsync はパスの指定で最後に / を付けるようにしているけどたまに忘れると面倒なことになる。 まあこれはどうでもいい。

あと、暗号化方式を軽くする時に -e "ssh -c arcfour" を入れるというテクニックもあったけど、 openssl のバージョンアップに伴って RC4 は使えなくなりつつある。

まとめ

HTTPサーバは apache とか nginx あたりを適当に使えばいいので作るのは簡単。 Web屋さんなら軽く用意できるかな、って感じです。