がるの健忘録 このページをアンテナに追加 RSSフィード

2017-08-13

[]本当にメモ書き程度

多くの場合において

/etc/dovecot/conf.d/10-mail.conf

あたりにあると思われる、いわゆるメール受信側(POP3とか)の設定で。


first_valid_uid


ってのがあるのかへぇしらなんだ。

色々と所以があって、一部のふる〜〜〜〜いアカウントは500番台の後半くらいからアサインされてるのがあるので。

その辺のアカウントが、これでひっかかってきたお。


うんまぁ色々と面白いなぁ、と思ったので、メモり。

2017-08-11

[]CentOS7にBIND 9、のナレッジ

お引越しでインストールした&案外とあちこち躓いたので、めも。

…いやまぁそもそも「そろそろBINDやめようよ」とか思わないわけでもないのですが、一応。


インストールは、大体こんな感じ、がベース。

yum -y install bind bind-chroot

firewall-cmd --add-service=dns

firewall-cmd --add-service=dns --permanent

firewall-cmd --list-services

/usr/libexec/setup-named-chroot.sh /var/named/chroot on

# すげぇ念の為

systemctl stop named

systemctl disable named


で、設定を終えた後で

systemctl start named-chroot

systemctl enable named-chroot

OK


……なんだけど、設定ファイルの記述ミスその他で大量に躓いたので。

おいちゃんの脳内フラッシュメモリから(ある意味奇跡的に)こぼれていない情報を、整理もせずに羅列。


情報としては

journalctl -xe

で出てくる……って言われるんだけど、色々と「もうちょっと情報よこせ」って感じの事が多々。

日付抜くの面倒なんで日付入りで晒すと、/var/log/messagesに

Aug 11 17:51:49 localhost named[4886]: ----------------------------------------------------

Aug 11 17:51:49 localhost named[4886]: BIND 9 is maintained by Internet Systems Consortium,

Aug 11 17:51:49 localhost named[4886]: Inc. (ISC), a non-profit 501(c)(3) public-benefit

Aug 11 17:51:49 localhost named[4886]: corporation. Support and training for BIND 9 are

Aug 11 17:51:49 localhost named[4886]: available at https://www.isc.org/support

Aug 11 17:51:49 localhost named[4886]: ----------------------------------------------------

Aug 11 17:51:49 localhost named[4886]: adjusted limit on open files from 4096 to 1048576

Aug 11 17:51:49 localhost named[4886]: found 2 CPUs, using 2 worker threads

Aug 11 17:51:49 localhost named[4886]: using 2 UDP listeners per interface

Aug 11 17:51:49 localhost named[4886]: using up to 4096 sockets

Aug 11 17:51:49 localhost systemd: named-chroot.service: control process exited, code=exited status=1

Aug 11 17:51:49 localhost systemd: Failed to start Berkeley Internet Name Domain (DNS).

Aug 11 17:51:49 localhost systemd: Unit named-chroot.service entered failed state.

Aug 11 17:51:49 localhost systemd: named-chroot.service failed.

Aug 11 17:51:49 localhost systemd: Stopping Set-up/destroy chroot environment for named (DNS)...

Aug 11 17:51:49 localhost systemd: Stopped Set-up/destroy chroot environment for named (DNS).

こんな感じで出てくるのを、ヘッジした時の諸々。


とりあえず前提として

・外向けの権威サーバ立ててる

・プライマリもセカンダリも自前

chrootは「とりあえず念の為やっとく」


大本の設定ファイルは、 /etc/named.conf 。

実際には /var/named/chroot/etc/named.conf を見ているはずなんだけど、これは systemctl start named-chroot とか systemctl restart named-chroot とかすると、/etc/named.conf から持ってきてくれるぽいので。

修正などは、 /etc/named.conf にそのままぶちかます。

ちなみに、restartとかしないと反映されないので、修正されたらretartしよう。


大体同じニュアンスで。

directory "/var/named";

を前提に、zoneファイルは /var/named に置いておく。

これも実際にはchrootで以下略。

ちなみに、restart以下略。


ファイルをmvだったかcpだったかしようとしたら「same file云々」とかいうエラーメッセージが出たので、多分「内部的には完全に同一」だと思われ。

chrootのギミックなんだろうけど、一端ここは深堀せず。

そのうち余裕があったら。


んで、書式で結構色々と躓いたので、引っかかったところを列挙。

・named.confとzoneファイルで書式が違う。具体的にはコメントが。named.confは//と /**/が使えて、zoneは;がコメント。zoneで/**/は多分使えない

・named.confは後ろに ; がないとエラーになる

zoneファイルのパーミッションに注意。上述の起動の仕方だと named ユーザ起動になるんだけど。zoneファイルのパーミッション的に「読めない」と、エラーにはならないのに情報が見れないwww

・named.conf、allow-queryを「localhost;(たしか、デフォがこれ)」にすると「外部から見れない」ので注意。anyが正解

・同じくnamed.conf、「recursion no;」は忘れずに!! たしかデフォがyesなのだよねぇ……。「外向き」にするんなら必須なんじゃなかろうか?

・named.conf。「allow-transfer { none; };」「allow-update { none; };」「allow-query-cache { none; };」も必須。デフォだった気もするんだが、明示して悪いもんでもなかろうもん

・「version "unknown";」気分w

・プライマリには「notify yes;」「also-notify { 11.22.33.44; };」。セカンダリ散らかさないんなら、optionsん中でよいと思う

セカンダリzoneの中に「type slave;」「masters { 1.2.3.4; };」で、親からとってくる感じ。「同名ファイルがあるとNG」「ディレクトリパーミッションに気をつけろ」ってあたりがポイント? ここ、すんなり通ったからナレッジが今一つ……

zoneファイルのほう。おいちゃんCNAME好きなんだけど「CNAMEで宣言するドメインMXとかに使えない」ので注意。……はまりました orz

・あ。TXT書かなきゃ(まだ書いてない……メールサービス組む時でよいかし……)


ちな、試験は

dig ドメイン名 @localhost

dig ドメイン名 @[鯖のIPアドレス]

dig よそ様のドメイン名 @[鯖のIPアドレス] # エラーになる事

で実験。


さて引き続きいくつか実験君がまっているので……この三連休はその辺でつぶれそうな予感……

2015-07-02

[][]サーバ系ツールに関する雑感

開発環境とか本番環境とかデプロイとか「環境の各諸々のバージョンアップ」とかに関する雑感です。

「Jenkinsとchefとデプロイツールに関する雑感」と読み替えてもらっても、そんなに変化はない感じ。

いつも以上に「主観バリバリ」なんで、適当に加減しながら読んでくださいませませ。

想定はLAMP。PはPHPなので、そんな感じで。


さて。

開発環境なんだけど、 http://d.hatena.ne.jp/gallu/20120725/p1 にも書いたとおり、基本的には「開発マシン1台用意して、全員でよってたかって使う」のが好み。

言い方を変えると「個人のPCで各人がvagrantとか使って開発環境作って」ってのが嫌い。

「個人のVirtualが嫌い」な理由は簡単で「簡単に環境差異が発生しうるから」。

平気でroot権限で「合意の取れていないブツをインストールして」、その後出てくるのが「ステージングで動かない → "自分の環境では動いてます (`・ω・´)キリッ"のコンボ」なので。

過去に見てきた限り「禁止してもとまらない」ので、おいちゃん的には割とここは「ガチガチ」でいきたい。


Jenkins

「CIツールとしてのJenkins」については「あんまり存在価値がわからんけど、別にあるならあるで」程度。

コンパイル系言語ならいざしらず。PHPで、見聞きしている範囲で「Jenkinsでやりたいこと」って「git フックでいいぢゃん」って内容ばかりで。

だとすると本質的には「なくてもいい道具は使わない」がおいちゃんの流儀なので、いらにゃい。

ただ、Jenkinsの中を見ていると結構「しゅっ」とした作りなので。「すでにあるから使いたい」とか「視認性的に便利だから使いたい」とかで「使用に肯定的な意見が多い」ようであれば、かたくなに「使うな!!」ってほどの何かはないので、使ってもいいんじゃないかなぁ、と。


Chef

Chefは…正直、まったく「ピン」とこない(苦笑

「Chefなら冪等性が保障される」って話はわりと多々、耳に目にするのですが、正直「レシピ次第」としか。

あと、書き方によっては「意図しないdaemonのupdate」とか「未テストな状態のdaemonのupdate」とか、いろいろ考えちゃうと正直、いまひとつ。

「tar ballを使いたい」っておいちゃんの好みにもわりと合致しないし。結局の所「コードでの管理」なので、事前のコード設計とかちゃんとやらないと「DRYと対極にあるような状況」とかが平気で出てくるので、結局「散らかる → 作り直す」の繰り返しで、手間かかるだけなんじゃねぇかなぁ? って感じがひしひしと。

個人的には、特にクラウドを使ってる場合は「Immutable Infrastructure」って発想がお好みかなぁ。

いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 http://www.publickey1.jp/blog/14/immutable_infrastructure_1.html にある、 http://www.publickey1.jp/blog/14/imm04.jpg の絵がとても近いような気がするのですが。

ようは、ELBをうまくつかいつつ「新しいインスタンスつくったら古いインスタンスは削除すればいいよね」な感じで、大変にクラウドちっくな方法(笑

具体例は以下を参照してくんなまっしょ。


ちなみに「fabric」なるツールを聞いたのですが…まだ斜めに飛ばし読みしかしていないのですが、なんとなく「好みのにおいがした!!!」(笑

気をつけないと乱用しそうなので丁寧に使い倒したいなぁと思うのですが(笑)、使うんならこーゆーシンプルなもののほうがお好みでやんす。


デプロイツール

rsyncぢゃだめ?

いろいろと「デプロイツールの利点」とか聞くのですが。特に「容易に巻き戻せる」とか。

正直、デプロイで「巻き戻し」っておいちゃんの感覚的には「極めて稀」な事象で、かつ基本的に「手順で1つ2つ、致命的なミスがあった結果」だと思っているので、その部分で「利点」言われても、いまひとつピンとこないでふ。

DBのマイグレーションも同様。

なので、多分これからも「困った事象に直面」しない限り、rsyncベースで進めてくような気がするなぁ正直。


総括

全体としては、Dockerとかのような感じのノリが、わりとしっくりくる感じ。

Dockerそのものについてはなんか見てると(実装の完成度とかの点で)賛否があるようなのと、まだ触ってないのでそこにはふれませんが。

「基本となる考え方/発想」的には、おいちゃんは大変に「好みだなぁ」と感じた次第でございます。


困ったときに「道具をつかって困りごとを解消する」のを、必ずしも否定はしないのですが。

「いあまる道具は なぜこの形を しているのか?」( http://d.hatena.ne.jp/gallu/20080827/p1 )という考察は、道具を使うときには、必要不可欠でございます。

この辺をすっかりと失念して「できるからいいでしょ」で使うと、大抵、ロクなことになりません。


また道具ってのは「必要最低限を適切に使う」ほうが、作成物の仕上がりがよろしくなるのではないか、と愚考いたします。

道具の乱用を留め立てするつもりはないのですが、経験上、それやると大抵「ひっちゃかめっちゃかになる」ので、個人的には避けたいなぁ、とか思っています。


以上、現場から雑感をお送りいたしました。


[][]サーバ系ツールに関する雑感(実践変)

いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 http://www.publickey1.jp/blog/14/immutable_infrastructure_1.html にある、 http://www.publickey1.jp/blog/14/imm04.jpg の絵がとても近いような気がするのですが、こんな感じ。

とりあえずAWS用語を使うので、他のクラウドなら適宜読み替えてくださいませ。ンなに固有の機能は使わないので。


登場人物

ELB:Webのロードバランサ@AWS。「ロードバランサ」と読み替えていただければ、大抵のところでイケるんじゃなかろうか、と。

ec2:いわゆるヴァーチャルなサーバインスタンス@AWS。これも「サーバインスタンス」って読み替えていただければ以下略。

AMI:マシンイメージ。これもAWS。サーバインスタンス作る元ねた的なもの。これも大抵あると思うので以下略。


初手

・必要と思われるdaemonを一式いれて「基本AMI」を独自に作成

・「基本AMI」から、開発用のサーバ、いるんならステージングサーバ(おいちゃんはよく、開発用サーバに共存させちゃう)、本番用のサーバ(とりあえず1台を仮定)をそれぞれ作成

・ELBを適切に紐付けます*1。本番サーバは、一旦「本番サーバテスト用ELB」に紐付けておきます

・開発サーバで適宜開発が進んでいる、と仮定します

・適当なタイミングで、一旦「これをデプロイしませう」なブランチなりなんなりを、ステージングサーバに持ち上げます。具体的には、おいちゃんは「ステージングサーバで、masterなりdevelopなりdeployなり、適切なブランチを git pull する」程度

・ステージングで適宜確認

・本番サーバにデプロイ。おいちゃんは「あらかじめ用意してあるrsync叩く」程度。このタイミングで、本番サーバは「本番サーバテスト用ELB」と紐づいている

・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する

・本番サーバのインスタンスを「本番サーバテスト用ELB」からはずして「本番用のELB」につなげる


以降のプログラムソースのデプロイ(開発中も、本番時も)

・とりあえず1台、AMIから新しく鯖インスタンスを作成 → 新鯖

・「新鯖」に、ステージングのソースを一式デプロイする

・新鯖を「本番サーバテスト用ELB」に紐付ける

・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する

・新鯖をcopyして、「現在、本番用のELBにぶら下がってる鯖と同じ数の新しい鯖(理由があるならインスタンス数を増減させてももちろんOK)」を作成する。これを「新鯖群」と呼称

if(ELB的なものの「接続ドメイン」がスイッチできるのなら) {

 ・「本番用のELB」と「本番サーバテスト用ELB」のドメインをスイッチ(スワップ)する

} else(スイッチできないのなら) {

 // 幾分スピード勝負なんで、バッチ的なもので処理をするとよりよいように思います

 ・新鯖群を一通り「本番用のELB」に紐付ける

 ・旧鯖群を全部、一気にはずす

 ・新鯖群を「本番サーバテスト用ELB」からはずす:ここは落ち着いて、少々タイムラグがあってもよし

}

・不安なら、旧鯖群の1台を、AMIとかでスナップショットっておく

・1時間くらい様子をみて、問題なさそうなら、旧鯖群のインスタンスを全部削除する


daemon等のupdate

・新しいAMIつくる。「0から作る」でもいいんだけど、既存最新のAMIから作ったほうがいろいろと楽

・新しいAMIから新しい鯖インスタンスを作成、開発環境で使って「問題ない」事を確認する

 →あたらしいAMI作る

 →あたらしいAMIからインスタンスを1つ作る

 →開発を一旦停止、ソースは全部gitにしまっていただく

 →開発DBの中身をダンプする

 →新開発鯖にDBの中身を入れる

 →ソースコードを新開発鯖にpullする

 →開発ELBの向き先を「新開発鯖」にする

 →開発を続ける:不具合があったら適宜対応をする

・ステージング鯖を作り直す:開発鯖とおおむねいっしょ。

・本番鯖を作り直す:「以降のプログラムソースのデプロイ」と手順一緒


DBの変更:テーブルの追加

・開発鯖で確認

・ステージングでとっととcreate tableして確認

・本番鯖DBには「ソースコードあげる前」にとっととテーブル作っておく(使われないだけだから、エラーは起こさないし)

DBの変更:カラムの追加

・開発鯖で確認

・ステージングでとっととalter tableして確認

・本番鯖DBには「ソースコードあげる前」にとっととカラム追加しておく(使われないだけだから、エラーは起こさないでしょ?)


DBの変更:INDEXの追加

・開発鯖で確認

・ステージングでとっととalter tableして確認

・本番鯖DBのもとっととalter


DBの変更:テーブル/カラムの削除

・まずそもそも、削除なんてそんなに頻繁にあるの?

・開発鯖で確認

・ステージングで確認

・本番鯖に、まず「修正後のコード」をデプロイする

・デプロイ後、問題がおきなければ、本番鯖DBのテーブルを消すなりカラムを消すなりする


基本はこんなところかなぁ、と。

これで「どうしてもにっちもさっちもいかない」ような状態は、とりあえずおいちゃんは経験ないのと、だから「比較的レアケースなんじゃないか?」って思うので。

レアケースなら、レアな時くらい「1時間程度のメンテナンス停止をかけて作業」でもいいんじゃないかなぁ? っと。


「どうしてもにっちもさっちもいかない」が恒常的に発生するようなケースなら…むしろ話を聞いてみたいなぁ、と思います(笑

*1:開発用ELB、(作ってるんならステージング用のELB、)本番用のELB、あと「本番サーバテスト用ELB」を、それぞれ、こさえておきます。開発ELBは開発サーバに紐付けておきます。ステージング用ELBがある場合、ステージングサーバに紐付けておきます

2014-09-27

[][]bashのインストールメモ

超絶ただのメモw

普段なら手元において終わり、なんだけど、もしかしたら参考にする人が、全世界で一人くらいはいるかもかなぁ、と思ったのでw


先に。

お手元のbashのバージョンを確認しておきませう。

bash --version

もしこれで4.3.0よりも「古い」んなら、持ち上げておいた方がよいかもしんまい。

おいちゃんはyumとか使わない子ちゃんなので、tar ballでコンパイルすますた。

cd /usr/src/
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
tar zvxf bash-4.3.tar.gz
cd bash-4.3
echo "./configure --prefix=/usr" > ./bash_ccc
sh ./bash_ccc
make -j 3
sudo make install

タダのメモなんで色々垣間見えるものがありますが、適宜アレンジなどしてくださいませ。

2011-02-06

[][]Webにかかわるエンジニア全員の必読書

以前に書いた書籍なのですが。読み終わったので改めてw



感想。

…よくもまぁここまで微粒子レベルにかみ砕けるものだなぁ、と。

今まで、わかりやすさという点で、ネットワークに疎い子達には大抵、以下の書籍をまず薦めていたのですが。

この2冊と並びうる…或いはこの2冊よりも「先に読んだ方が良いかもしれない」とすら言えそうな感じなのではなかろうか、という一冊でした。


マンガ式 IT塾 パケットのしくみ

マンガ式 IT塾 パケットのしくみ

[改訂3版] 図解でよくわかる ネットワークの重要用語解説

[改訂3版] 図解でよくわかる ネットワークの重要用語解説


面白いなぁ、って思ったのが。

TPC/IPどころかMACアドレス&ARPにまで踏み込んでいることと、最後に「サーバ管理のこと」というところに、少なからぬページを割いている事、でしょうか。


あんど。


最後の、加藤さんの一言が………

最終的には未経験者向けというよりも、インターネットの概念的な勉強をしないまま、現場で働いてきたエンジニアやディレクターにとって役立つ内容になっていると思います。

インターネットの概念的な勉強をしないまま、現場で働いてきた

インターネットの概念的な勉強をしないまま、現場で働いてきた

インターネットの概念的な勉強をしないまま、現場で働いてきた


大切なポイントでもあり…一方で、ロンギヌスの槍レベルの貫通力を持つ一言でもあります orz


痛みを感じた人は速やかに。

痛みさえ感じられないほど鈍い人は、もっと速やかに。

この書籍で、せめて「専門ではない、アルバイトな女子大生さんよりはインターネットの諸々に関する知識を身につける」必要があるのではないでしょうか?

お金を貰っているプロとして。


あんど。

基本的な知識を一通り網羅している諸氏的には。

絵柄が可愛かったり理解のしかたがほっこりしていたりするので、ちょっと疲れた時の「癒やし的書籍」としても面白いんじゃなかろうか、と思います。