全くもって何のうまみも感じられない。
 そもそも最近はDB操作レイヤの抽象化が進んでて開発者サイドからはそれほどDBの違いを意識する必要なく、であればすでにLinux上でこなれてる各種DBを選択しない理由はない。しかもLinux版はフル機能じゃないんでしょ?
 SQL Serverに慣れた開発者が「やったー!Linuxでも使えるー!」なんて場面が想像できない。そんな人がわざわざLinuxに来る理由は無いし、そもそもLinuxに来れる人だったら他のDBでも問題ないだろう。

 正直、MS営業の口車にのって搭載した利用者からCALを徴収するための手段としか思えない。ほらインターネット利用者から受信料を強制徴収しようとしてるNHKと同じ。そのうちADのLinux版とかも出す気じゃんじゃないかね。むしろSQL Serverより実装しやすい気がするが。

関連タグ:LinuxMicrosoftDB
2016-03-09 [技術]

 なんかまたぞろ煽り記事っぽっくなってますが、例えばRedhatの詳細を見ると基本的にはローカルからアクセスされうる脆弱性のようで、即リモートから乗っ取られる類のものではないのかなと。

 まあAndroidの場合アプリに仕込まれて動作実行時にーという話はより現実的なので、まずは妙なアプリを入れないとゆー普通の対応が重要ですな。

関連タグ:AndroidLinux脆弱性
2016-01-20 [セキュリティ]

 標題通り。あくまでお試しのレベル。バージョンは現在の最新12から1つ落として11を試用。主な目的は「自前のWebアプリとSAML連携」及び「Google AppsとSAML連携」。

  • OSはCentOS7、Javaは標準添付のjava-1.7.0-openjdkを使用。Javaは標準品のインストールが推奨されてるが、とりあえずインストールはできて、今のところ不具合らしいものは発生していない。なおCentOS6.5付属の古いopenjdkではダメだった。なおtomcatも標準添付品を使用。
  • インストールはネット上で確認できる方式でほぼ問題なし。名称が「opensso」だったりするところを「openam」にするなどの細かい違いはある。
  • 待ち受けポートとかはTomcatの 設定に依存する。ちゃんとKey設定すればhttps通信も可能。なお標準に近い設定でhttps/8443にて稼働させようとする場合、うっかりhttpdが標準設定で起動してるとnss.conf上で同じ8443で待ち受ける設定が入っており、起動順でこっちが優先になってるためいくら設定変えても起動しないとゆー現象に見舞われる(た)。
  • OpenLDAP連携しようと思う場合:
    •  データストアに「汎用LDAP」設定で登録する。
    •  もし既に自前のLDAPがある場合、ある程度DN値やらマッピング設定やらすればとりあえずOpenAM上で認識するようになり、最低限のユーザ情報も取れる/書けるようにはなる。
    •  ただしここでSAMLによるSSO連携したい、という話になった場合、アカウントのアクティヴ設定だとかSAMLの一時データだとかで実はかなりの数の非標準属性値が必要になる(認証だけだったら少なくて済むかもしれないが)。既存の属性に対するキーマッピングでいけるのかもしれないが、いちいち検証するのも面倒なのでそれ用のスキーマを取り込んで属性を使えるようにした方が早い。
      • →Githubとかにスキーマを上げてくれてる方がいらっしゃった。「openam openldap ldif」とかでググると見つかるんじゃないでしょうか。OpenLDAPへの取り込みについては各自で。
      • →多分OpenAMと同時にインストールされ、テスト用?のデフォルトデータストアとなってる「OpenDS」のスキーマをOpenLDAP用に取り込ませるのが一番確実だろうとは思われる。
      • →OpenLDAPで属性追加後、管理コンソールから対象となるLDAP(データストア)設定にユーザ属性を追加してくわけだが、基本的にデフォルトデータストア「embedded」の設定にある属性値と追加した属性値を比較して、存在するものを入れていく。…一行ずつだととてもめどいのでCLIである「ssoadm」とか使った方が楽かもしれない。
      • →ここまで来ると、OpenAMから新規追加すれば必要なobjectclassと属性値を備えたユーザが作成される。既存のユーザはそれ見ながらobjectclassやら属性やら追加するのが良いんじゃないでしょうか。
  • 標準で存在するトップレベルのレルム「/」。ここに記述してあるDNS/エイリアス設定から、ホスト名のFQDNを削除すると、そもそも管理画面にログインできなくなって大変困る(※実はこのDNS/エイリアス設定の意味をよくわかっていない)。当然管理権限でアクセスできないので変更すらできないわけだが、やはりCLIの管理ツール「ssoadm」で強制的に叩きこむ事は可能。
    • コマンド例:ssoadm set-realm-attrs -e / -s sunIdentityRepositoryService -u amadmin -f ./pass.txt -p -a sunOrganizationAliases=[そのFQDN]
  • そんなこんなでいざとゆー時にはssoadmに頼る事になる可能性があるのでインストールしとくが吉。Web系とは別にインストールする必要がある。インストールマニュアル参照。
  • ログインページのカスタマイズは主に以下のファイルを編集する(パスは多少異なる可能性あり)。なおいずれもトップレベルレルムの場合。実際はレルム毎に複製される、のか?
    • /var/lib/tomcat/webapps/openam/config/auth/default/Login.jsp
      • →jsp本体。
    • /var/lib/tomcat/webapps/openam/config/auth/default_ja/DataStore.xml
      • →日本語用のテキストとかが入っている。ログインページの「OpenAMへのサインイン」とか文言の変更が可能。
    • /var/lib/tomcat/webapps/openam/css/new_style.css
      • →単にCSS。背景画像とかの調整に用いる。なおCSSファイル名は変わる可能性あり。
  • 自前WebアプリとのSAML連携について:
    • IdPをOpenAMで構築、SP側は「simpleSAMLphp」をZendFrameworkに喰わせる形で構築。標準的なIdP、SP設定でほぼ問題なし。というかその他詳細不明。
  • Google AppsとのSAML連携について:
    • 設定自体は管理コンソールのトップページにある「Google Appsとの連携」に従えば拍子抜けするほど簡単に終わる。もちろん細かい制御をしようと思ったらまた別だろうが。
    • Apps側の特権管理者はSAMLの配下には置かれない(自前認証)。確かにある検証ドメインではそのように動作するのだが、別のドメインで一時的に特権管理者もSAML連携するようになってた時があった。1日経ったら自前に戻ってた。謎。
    • POP&IMAP、Androidとの同期についてはSAMLの影響を受けない。そっちは普通の管理制御、管理API経由等で別に制御する必要がある模様。
    • SAMLサーバ側のアクセスURLがhttpになるかhttpsになるかはIdP登録時の管理コンソールにどっちで入ってるかに依存する。ただしあくまで表面上の話であり、例えばhttp/8080で作った(Apps側にもそれで登録した)後にhttps/8443通信を有効にした場合でも、Apps側に登録するURL設定をhttp/8443に書き換えるだけでフツーに動作してくれる。



 継続して調査中。
2014-09-04 [技術・作業]

 2,3日前の記事だが、ふと「ライブドアに買われて株価操作に使われた挙句衰退の道を歩んだTurboLinux」のことを思い出したもので。
 一時期は、少なくとも国内であればRedhatと張り合える有償ディストリだったのに、金転がしの毒牙にかかったばかりに惜しいことしたなぁと。この一事だけでもホリエモンとかいう元犯罪者を非難するに十分な出来事と思う。

 それはそうとMiracleLinuxは特に使ってないので特に痛痒はないです(苦笑)。
関連タグ:Linux買収
2014-07-10 [日記]

 タイトル通り。
 ありがちなPostfix+Dovecot環境(Maildirベース)を構築。今回バックアップ用にWindows Storage ServerベースのNASを用意していたためNFS共有を作成しメールサーバからマウント。そこにrsyncをかけようと試みた
 が、試みたところいくつかのファイルでエラーが発生している。いくつかとゆーか結構な数のエラーが出ている。エラー内容は以下の通り。

 rsync: recv_generator: failed to stat [rsync先]: Input/output error (5)

 大したエラーではなさそうと思いつつもネットで調べると「ディスク不良じゃね」的な話が多い。しかし成功してるファイルもあるし、NASにもサーバにもこれといってディスク不良の兆候は見られない。
 エラーが出てるファイルをよく見る。すると各ユーザのMaildir/cur内にある=一度閲覧されたメールで、メールファイルの最後に「:2~」とか着いたファイルであることに気づく。

 最初はrsyncがコロン(:)に対応してないのかと思って調べたが(※rsyncもコマンドの中でのデリミタに使ってたので)どうもそーゆー話は見られない。
 しばらくしてはたと「…ああ、そういやWindows Storage Serverだっけな」とゆー事を思い出す。NFSマウントなんかしてたからつい「Windowsである」とゆー認識が抜けていた。そりゃWindowsだったらコロンの着いたファイルが作れないのは当然であるさ。

 さて困った。このままではシンプルなrsyncがうまくいかない。バックアップをとるだけなら1圧縮ファイルにまとめるあり文字列コンバートするなりの方法はあるけれど、できればrsyncでカタを付けたい。一度内部の別領域にrsyncかけてからtarとかもあるだろうけれども今後のメールサーバの利用状況次第ではバックアップ用の領域までまかなえるかどーか分からない。
 Dovecotの設定で上記デリミタをコロンから変更できないものかとかも調べたができなそう。rsync単体で何か上手くコンバートしながら渡す方法はないかと調べて見たがそれっぽい方法に当たらない。(※複数の処理を連動させたシェルでも作れれば可能かもしれないが…)

 もーこんなんWindowsのせいなんだからなんとかしてよ!と思いなんとなく「Windows Server NFS ファイル名置換」とかでググったところ、以下の情報に辿り着く。

   ファイル名の文字変換の概要
   ファイル名の文字変換を構成する

 要するに特定文字を変換して保存しようというもの。試しに上記のサンプルにある通りコロン(:)をハイフン(-)に変換するよう設定し、Linux側でコロンの付いたファイルを生成したところ無事保存に成功!Linuxからはちゃんとコロン付きのファイル名で見えつつWindows側ではハイフン付きのファイルとして保存されてる。これで勝つる!


 …わけにいかないのがWindowsのWindowsたる所以。最近とあるMSの中の人がアンチMSの人に対して「今は問題ないんだから和解しよーぜへらへら」(意訳)とかブログで言ったらしいが、ぶちゃけ現在進行形でMSの問題は積み上がってるちゅーねん。先日アップデートされたIE11でも早速問題起きてるっちゅーねん。対MSの戦闘は相手の殲滅しかありえないねぶちゃけ。
 まあそれは良いとして。上記の変換、フツーに考えればすぐ気づくことだが「じゃあ変換後の文字を最初から使ったらどーなるか」とゆー疑問が出る。こんなファイル名に関するものだったら単純な変換ではなくうまく切り分けてマッピングしてくれる…などと(無駄な)期待して試してみたのだが、例えば「test:test-.txt」というファイルを作成してls打ってみると「test:test:.txt」とゆーふーに、本来変換されて欲しくない明示的なハイフンまで変換されてるじゃないですか。
 とするとこの機能を使って対応しようとした場合、Linux側で使う予定のない文字を変換対象として割り当てるしか手がない。しかしながら「Linuxでファイル名に使えない文字」とゆーのはスラッシュ(/)とNULLコードの2つだけ。そんなんWindowsでも使えるわけない。
 また、せめてこのマッピングが有効になる範囲を限定できればなと思ったのだが、この設定は「NFSサーバ全体」に対して反映されるため、このNFSサーバを利用する全てのLinuxサーバが同様の影響を受ける。正直あちこちのファイルをバックアップしてるため「それら全てで使われることのない文字」なんてのを特定することはとても困難だし、将来的な確約ももちろん持てない。
 となると1文字→複数文字の置換ができればとも思うが、どうもこの機能だと1文字単位でのマッピングしかできないらしい。


 …とゆー感じで振り出しに戻ったところ。ただまあある程度ファイル名の規則性を注意してれば文字置換でなんとかできそうではあるのでその方向で検討中。どっちにしてもNFSなんて明らかにxNIX向けの機能提供するんだったらカンペキな対応しとけっての。WindowsなんだからCIFSでやれって意見は却下ねw


追記:
 1バイト文字→2バイト文字、あるいは2バイト→1バイトへの置換が可能な事を確認。半角コロン(:)を、少なくともLinuxシステムのファイル名には使わなさそうな全角文字に変換することで対応。
関連タグ:LinuxWindows
2014-02-28 [技術・作業]

 色んな理由からLinuxからWindows(Server)の操作をしたい事があります。
 専用のAPIやらRPCやらを持ってるモノだったらそこに対してアクセスしますが、内部コマンドについて処理をしたい場合何らかのCLI系サーバをWin側で立ち上げるか、はたまたIISとASP等を経由して内部コマンドを実行、といった手段があります。

 そんな手法の1つ、「LinuxからWindowsのコマンドを直接実行する手段」としてsamba系のツール「winexe」があります。と言うかあることを最近知りました。これはWindowsで言うところの「psexec」に似ており、コマンドプロンプトで実行するようなコマンドを実行することができます。

 で、更にPHPのexec関数やらsystem関数やらを使う事でLinuxベースのWebアプリからWindowsの特定制御を行う事を試みたのが今回のお話です。そんなことしたい人間がどれだけいるかって話です(苦笑)。
 とりあえずLinuxはおなじみCentOS5系でPHPは5.1.6。WindowsはServer 2008 R2。winexeは1.00。

 winexeのインストールは割愛。ソースコンパイルして適当なbinにコピー。
 適当にコマンドテスト。

   winexe -U "Administrator%pass" --system //[HOST] ipconfig 1> /var/log/test_winexe.log

 とりあえず出力をファイルに書いてます。結果ipconfigの結果が素直に返って来て感動。但し今更SJIS。まあコマンドプロンプトだから仕方ないか。

 で、次にこれをPHPのexec関数から実行。

  exec("winexe -U \"Administrator%pass\" --system //[HOST] ipconfig 1> /var/log/test_winexe.log");

 …ところがコレが何時まで経っても応答が返ってこない。psでプロセス見るとコマンドは発行されて止まってる様子。killしないと残りっぱなし。
 ログファイルを見ると

   tevent: EPOLL_CTL_ADD failed (Operation not permitted) - falling back to select()

 というエラーが1行。
 「permitted」云々言ってるんでアクセス権かな、と思いsudoによるroot権限実行に変更。しかし変化無し。
 他の実行コマンド系はどうだろう、と「system()」「shell_exec()」を用いるものの変化無し。
 またコマンド内容をシェルスクリプトに移動し、そちらで起動しても変化無し。

 sudoでもそうだったがこういった場合標準出力関係でトラブる事が多いので、似た状況で稼働するcronでの起動を試す。ユーザはPHPの稼働環境と合わせる意味でapache。しかしコチラは無事に稼働。TTY及びapacheユーザ権限の問題の可能性が薄れる。

 仕方ないので(いや最初からやれよと)元々出ているエラーメッセージを追うことに。
 「EPOLL_CTL_ADD failed」はコネクション系のエラーぽい。しかしここで「Windows側に処理結果が残るバッチ」を作成して実行したところ、そちらの稼働は確認できた。つまるところ「コマンドを読んだ後の戻り」が上手く言ってない様子。

 そうなると、どちらかというと「PHPから起動した故にプロセスの戻りのパイプがよくわからんことになっている」という可能性があるのかなと。EPOLLについて調べてたらファイルディスクリプタがどうこう言われたし。
 なので上記シェルの起動を、プロセス単位で制御する「popen()」に変更。そしてポインタを開く際の権限モードを書き込み可能な「w」で動くように設定。

  $pp = popen("winexe -U \"Administrator%pass\" --system //[HOST] ipconfig 1> /var/log/test_winexe.log","w");
  pclose($pp);

 上記の様にしたところ、無事終了しつつ且つ結果も取れるようになりました。
 更に実験で上記popenの権限モードを読み専用の「r」に変更したところ、他のexecやらと同様に停止しつつプロセスに居残り、また同様のEPOLL_CTL_ADD系エラーが発生することを確認しました。


 まーこんな話が世の中役に立つかはアレですが、他の実行ファイルを起動する場合にも似たような話が発生する可能性はあるでしょう。まあ一例ってことで。
2012-09-01 [技術・作業]

 これまで私が仕事で扱うメールサーバ環境はqmail+vpopmailによるヴァーチャルドメイン環境がほとんどでした。
 接続元をほぼ制限できることが多いのでIP単位での制限を実行。代わりにSMTP認証等は用いず、必要に応じてPOP before SMTPで対応、といったどっちかつーと古めの環境です。利点と言えばqmailのセキュリティ性及びMaildir管理、vpopmailによるOSのアカウントによらないドメイン&ユーザ管理。時折IMAPが必要な場合にこれらと相性のよいCourier-IMAPを組み合わせてました。

 ですがまあ世の中的にもう古いですよね、そして上記利点は既に他の環境でも実現可能っぽい。
 最近サーバの置き場をクラウドに移行する話が出たため、ここらでプラットフォームを最新に置き換えるのもアリかなと、Redhat系ディストリで標準と化したPostfix+Dovecotに移行できないかと検討をしてみました。

 ただ、ここで前提条件として2件。
 1つは「vpopmailで管理していたユーザアカウントは全て無変更で移行したい」。メールアカウントは当然の事として一度パスワードをリセットして再設定したもらう、などとゆー手間も省きたい。ユーザは、少なくともメーラーのサーバ設定をFQDNで設定していれば、若干のダウンタイムのみで後はほぼそのまま使えるようにしたい。
 そしてもう1つは「qmail、vpopmailは(最終環境では)インストールしない」。Courier-IMAPと連携させてたときもそうだったのですがユーザ、メールの管理はvpopmailが行い、認証系とアクセスをCourierに任せるとゆー動きをしてました。ただコレだと「新しいプラットフォームに置き換えたい」とゆー要望を満足しない。データはvpopmail等のをそのまま利用するのはアリとしても、ソフトウェアとしてqmail、vpopmailをインストールはしない方向で。

 あちこち調べてみるとPostfix+Dovecotのみでヴァーチャルドメイン環境を実現することは可能。またDovecotとvpopmailを連携させることも可能。でも後者はvpopmail(果てはqmail)のインストールが必須。試しに一度Dovecotのvpopmailオプション付きリビルドを試みましたが、リビルド時にvpopmailのライブラリ・ヘッダ情報の読み込みが必須だったので断念。まあ他の環境からライブラリとかだけコピーする、インストール後に削除するとかの手も可能だったかもしれないけど、以後のメンテナンス性を考えると多分あんまり意味ないだろうなぁということで断念。
 次にvpopmailの、いわゆる「vpasswd」をDovecotの管理形式にコンバートする手法はないのかなと探したものの、そんなマイナーな事をしたがる人はいないためか情報無し(苦笑)。

 じゃあ、何かしらvpopmailとDovecot間でユーザ情報の中継をする手法は無いものか。…こう考えれば「データベースを経由すればいいんじゃね」とゆー案にたどり着きます。cdbとかで独自管理してる各ツール独自のユーザアカウント情報にはイマイチてを出しづらいけど、汎用DBに書かれてしまえば検索側の設定、もしくはデータコンバートもSQLでできるんじゃないか。
 PostfixやらDovecotやらはさすがに割りと新しい?ものだけあってDB連携の手法が数多く見つかります。そして「そういやvpopmailもPostgreSQL連携手法があったよな、やったこと無いけど」。

 上記をまとめて、

 1.「仮環境」としてPostgreSQLオプション付きvpopmail環境を構築する。
 2.上記「仮環境」に移行対象のvpopmail管理情報を複製→DB化。
 3.「仮環境」のユーザデータをエクスポート→「新環境」にインポート。

 することで、Postfix、Dovecotがその情報を閲覧することはできないかなぁと。
 てことで試しました。
 なお下記の各手順はある程度記憶の元に書かれているのでテキトーに端折られてる恐れがあります。PostgreSQLのユーザ設定周りとか。その辺他のサイトさんなんかも参照にして下さい。

 まず「1.」のように新規サーバに「--with-pgsql」オプション付きのqmail+vpopmail環境を構築します。…この辺別に新規環境である必要はなく、そもそもpgsqlオプション付きで使ってれば、更に言えば既にvpopmailの頃からpgsql経由で使ってれば別途新規に作成する必要はありません。
 私の場合pgsqlオプション付きのメールサーバは一台も無かった・ユーザが利用中などなどから新規に作った方が安全かつ手っ取り早かったとゆーだけです。

 次に「2.」の環境移行。
 その前に新規でサーバ作った場合、移行対象となるヴァーチャルドメインは仮環境のvpop系コマンドで作成します。既存環境のコピーだけだと足りない情報があるような気がするし、そもそもqmail側の情報が更新されないので。
 ドメインを作ったら、既存環境の「~domains/[移行対象ドメイン]」を丸々複製。
 次にPostgreSQLの調整…なんですか新規テーブル作成とかは必要なく、pg_hba.conf等でローカルかrなお接続だけtrustにしておきます。
 ここまで済んだらvpasswd→PostgreSQL移行コマンド「vconvert」を実行。

 例:vconvert -c -m [移行対象ドメイン]

 「-c」はvpaswd.dbから、「-m」はSQLに、を意味します。また全ドメインを移行対象とする場合は移行対象ドメインの指定は不要なようです。
 コマンドが正常に成功するとPostgreSQL上にDB「vpopmail」が作成されます。中のテーブルはこんな感じ。

vpopmail=# \d
            List of relations
 Schema |    Name     | Type  |  Owner  
--------+-------------+-------+----------
 public | dir_control | table | postgres
 public | vpopmail    | table | postgres

 vpopmail=# \d dir_control
            Table "public.dir_control"
    Column    |          Type          | Modifiers
--------------+------------------------+-----------
 domain       | character varying(96)  | not null
 cur_users    | integer                |
 level_cur    | integer                |
 level_max    | integer                |
 level_start0 | integer                |
 level_start1 | integer                |
 level_start2 | integer                |
 level_end0   | integer                |
 level_end1   | integer                |
 level_end2   | integer                |
 level_mod0   | integer                |
 level_mod1   | integer                |
 level_mod2   | integer                |
 level_index0 | integer                |
 level_index1 | integer                |
 level_index2 | integer                |
 the_dir      | character varying(160) |
Indexes:
    "dir_control_pkey" PRIMARY KEY, btree ("domain")

vpopmail=# \d vpopmail;
               Table "public.vpopmail"
     Column      |          Type          | Modifiers
-----------------+------------------------+-----------
 pw_name         | character varying(32)  | not null
 pw_domain       | character varying(96)  | not null
 pw_passwd       | character varying(40)  |
 pw_uid          | integer                |
 pw_gid          | integer                |
 pw_gecos        | character varying(48)  |
 pw_dir          | character varying(160) |
 pw_shell        | character varying(20)  |
 pw_clear_passwd | character varying(16)  |
Indexes:
    "vpopmail_pkey" PRIMARY KEY, btree (pw_domain, pw_name)


 このうち、テーブル「vpopmail」に各ユーザアカウント情報が保存されます。このデータをPostfix、Dovecotが読めるかがポイント。
 DBの内容をまとめてダンプします。

 pg_dump vpopmail > vpopmail.dmp
 
 ダンプデータを移行対象の新環境に複製します。
 で、その前に新環境ではPostfix+Dovecot+PostgreSQLの環境がそれぞれ整ってる必要があります。その辺は詳しいサイトさんが他にいるので割愛しますが、とりあえずCentOS5系列の場合標準のPostfixだとDB未対応版なのでちょっと手を入れる必要が発生します。
 さて新環境のPostgreSQLに上記ダンプデータをインポートします。

 createdb vpopmail
 psql vpopmail < vpopmail.dmp


 ちなみに今更ですがPostgreSQL上のユーザはスーパーユーザであるところのpostgresでやってます。ホントはReadWriteとか厳密に考えて作るべきでしょうが、今は検証段階とゆーことで割愛します。

 また、新環境におけるドメイン、Maildirの保存環境は従来のvpopmailと同様「/usr/local/vpopmail/domains」の下とします。別にこれは変更しても構いませんが、DBの値も合わせて書き換える必要があるので好みに応じて。
 で、既存メールサーバのdomains配下を新規環境下にコピーします。とりあえず属性維持コピーを行なって、uid:8001、gid:8000とします。

 さてここまで整えばPostfix、Dovecotからデータが読めるか検証できます。
 まずPostfix。とりあえずヴァーチャル系の設定を一通り行った事を前提とした上で、メールボックス系の情報をPostgreSQLから読めるように変更します。
 ざっと変更したのはmain.cfの以下の所。

virtual_mailbox_maps = pgsql:/etc/postfix/pgsql_vmailbox.cf
virtual_mailbox_domains = pgsql:/etc/postfix/pgsql_virtualdomain_pa.cf
#virtual_alias_maps = pgsql:/etc/postfix/pgsql_virtual.cf
local_recipient_maps = pgsql:/etc/postfix/pgsql_vmailbox.cf
virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql_vquota.cf


 このうち「virtual_alias_maps」がコメントになってる理由は後述します。
 とりあえず普段は「hash:~」とかで自前DBで管理してるところをpgsqlを読むように変更した上で、それぞれの設定を別ファイルで編集します。
 例えばユーザアカウントそのもの系であるところの「pgsql_vmailbox.cf」の場合、

hosts = localhost
user = postgres
password =
dbname = vpopmail
query = SELECT substr(pw_dir,length('/usr/local/vpopmail/'))||'/Maildir/' as maildir FROM vpopmail WHERE pw_name = '%u' and pw_domain = '%d'


 てな感じにすればテーブル「vpopmail」のユーザアカウント情報を元にヴァーチャルメールボックスを検索してくれます。
 上記を見れば分かりますがmain.cfの「virtual_mailbox_maps」が期待する戻り値は指定されたメールアドレスに対する保存先フォルダです。ただここでちと面倒な話がありまして、テーブル「vpopmail」中のメール保存フォルダを指定するカラム「pw_dir」は「/」からのフルパスで書いてあります。しかしPostfixでヴァーチャルドメインを指定する場合、その更に上位フォルダを指定するパラメータ「virtual_mailbox_base」が必須項目となっているようで無視できません。つまりSQLは「virtual_mailbox_base」を取り除いたパスを取得する必要があり、そのためわざわざ取得文字列の左側と取り除き、且つvpopmailに指定されたパスでは足りない「/Maildir/」をプラスしています。
 面倒ですが逆の見方をすればこの辺の制御を自由にできるので各ソフト間の連携が容易であるとも言えるわけです。一度設定してしまえばそこまでですし。
 他の検索系の設定ファイルも似たような手法で調整します。ここでは長くなるので割愛します。

 次にDovecotです。Dovecotもある意味似たような感じです。
 まずはdovecot.confを編集します。今回は検証のために認証プロトコルを

 protocols = pop3

 に限定します。しなくてもいいとは思いますが。
 次に認証方法を編集します。
 まず今回はSQL認証に限定するので標準で開いている「passdb pam」をコメントアウトします。ここの閉じかっこがちょっと離れた位置にあるのでそちらのコメント化も忘れないように。
 そして逆に「passdb sql」のコメントアウトを外し、SQL用設定ファイルを指定します。

  passdb sql {
    # Path for SQL configuration file, see doc/dovecot-sql-example.conf
    args = /etc/dovecot-sql.conf
  }


 似たような感じでuserdbの値も変更します。

  userdb sql {
    # Path for SQL configuration file, see doc/dovecot-sql-example.conf
    args = /etc/dovecot-sql.conf
  } 


 さて次に肝心の「dovecot-sql.conf」を作成するわけですが、上記コメントにもあるようにサーバ内を探すとサンプルファイル「dovecot-sql-example.conf」がありますのでそちらをベースに編集します。
 まず接続するDBを指定します。

driver = pgsql

 次に接続条件。下記には環境によっては「password=xxxx」を追加する必要があるでしょう。

connect = dbname=vpopmail user=postgres

 次にメールアカウントパスワード検証時の方式を指定します。
 vpopmailの場合、バージョンによってパスワードの暗号化形式が若干異なるのですが、とりあえず私の環境では混在してても下記のみで対応できておりました。

default_pass_scheme = CRYPT


 次にパスワード用クエリ。ここではユーザIDとそのパスワードを取得するようになっています。またこの場合のユーザIDは基本的にメールアドレス「user@domain」形式になりますので、vpopmail形式の場合文字列連結を行う必要があります。

password_query = SELECT pw_user||'@'||pw_domain as user, pw_passwd as password FROM mailbox WHERE pw_name = '%n' and pw_domain = '%d'

 次に各ユーザの保存環境クエリ。ここでは保存先フォルダの他、各ファイル・フォルダを制御するuid、gidを指定します。各ユーザをバラバラにすることもできますが、今回の場合vpopmailの元設定であるところの8001:8000を指定します。

user_query = SELECT pw_dir as home, 8001 as uid, 8000 as gid FROM vpopmail WHERE pw_name = '%n' and pw_domain = '%d'

 ここまで設定してPostfix、Dovecotをそれぞれ再起動すればメールの受信やPOPによる取得が可能になってる…ハズです。ダメだったらmaillogを参照にレッツデバッグ。


 さて。
 ここまでは「PostgreSQL中のvpopmail環境をそのまま移行してPostfixとかDovecotから使えるか」の検証でした。より正確に言えば「vpopmailの挙動で作られたテーブル情報をSQLとかの設定をいじることでPostfix、Dovecotからそのまま検索することができるか」の実験でした。
 つまるところ必要な情報さえ揃っていればテーブルの構造は問わないとゆーことです。

 そしてこのままだとぶちゃけ実用的ではありません。
 ユーザの追加変更削除、ドメインの追加変更削除を行うのにいちいちSQLを発行する必要があるからです。まあPostfixとDovecotを別々に管理する手間に比べれば一発で済んで楽と言えば楽なんですけどね。
 でもここでもう1段楽にするためにPostfixの定番管理ツール「postfixadomin」を使うことにします。
 ご存知の通りpostfixadminはmysql経由でPostfixのアカウント管理を行うPHPのセットですが、DBはPostgreSQLを参照することもできます。
 ただ、postfixadminは自前のテーブル構造を前提としており、先にやったようにある特定のテーブル構造に合わせるような事はできません。まあソースいじればできるでしょうけど当然面倒なんでやりません。
 であればむしろDB「vpopmail」の内容を「postfixadmin」の構造に置き換えてしまえば良いわけです。

 まずpostfixadminをインストール&初期設定します。ここんとこ面倒なんで割愛(笑)。他のサイトさんを参考にして下さい。
 さあpostfixadminが入りましたw
 まずドメイン設定をGUI経由で行なって下さい。その方が後腐れが無いと思われます。
 次に初期設定まで無事済んでいればPostgreSQL上にDB「postfix」ができているハズ。ここに先のダンプデータをインポートします。

 psql postfix < vpopmail.dmp

 DB「postfix」内にテーブル「dir_control」と「vpopmail」ができます。
 さて、postfixadminがユーザ管理に必要とするテーブルは「alias」と「mailbox」。aliasはその名の通りエイリアスを入れるものなハズですが、どうもローカル配送用に自分自身の記述も必要としている様子。mailboxはユーザアカウントやパスワード、保存フォルダを設定しておく核となるテーブルです。
 テーブル「vpopmail」の内容を上記2テーブルにそれぞれカラムを合わせつつ、且つ形式を合わせつつコピーします。とは言え基本的には以下のSQLで大丈夫かと。

○mailbox移行用
insert into mailbox select (pw_name||'@'||pw_domain),pw_passwd,pw_name,substr(pw_dir,length('/usr/local/vpopmail/domains/')+1)||'/',cast(pw_shell as int),NULL,NULL,true,pw_domain,pw_name from vpopmail

○alias移行用
insert into aliase select (pw_name||'@'||pw_domain),(pw_name||'@'||pw_domain),pw_domain,NULL,NULL,true from vpopmail

 ユーザアカウントは「user@domain」型に連結。登録時間とか持ってないデータはNULLで問題なし。でも一部not NULLがあるので適当に代入。一方でquota情報は型変換でint型に、といった感じ。

 次にPostfix、Dovecotの各Pgsql参照設定をpostfixadmin用に変更。

例:pgsql_vmailbox.cf
query = SELECT ('domains/'||maildir||'Maildir/') as maildir FROM mailbox WHERE username = '%s'

例:dovecot-sql.conf
password_query = SELECT username as user, password FROM mailbox WHERE username = '%u'
user_query = SELECT '/usr/local/vpopmail/domains/'||maildir as home, 8001 as uid, 8000 as gid FROM mailbox WHERE username = '%u'


 またPostfixは上の方でコメント化していた「virtual_alias_maps」をpostfixadminのテーブル形式に合わせて作成する必要があります。vpopmailテーブル形式だとエイリアスに関する情報が無かったので手が出せなかったのですがこれ以降は管理できます。
 Postfix&Dovecot再起動。
 以上でvpopmailのMaildir環境のまま、Postfix&Dovecotを利用し、且つユーザ制御をpostfixadminで行えるようになります。新規ユーザ作成も可能。


 なお実際の所上述したユーザアカウント以外の所にも手を入れなきゃいけないところがあります。
 まずPOP before SMTP。古い発想のためかPostfix+Dovecot単体では実現できないようです。私は「DRAC」を経由することにしましたが、実の所せっかくDBでPostfix+Dovecot間の連携が出来てるんだから今更他のツール、DB使わなくても接続IP情報とかもDB経由で処理できるんじゃねーかとか思わなくもありません。これは後の検討課題。
 そしてもうひとつエイリアス。vpopmailの場合各ユーザ毎のエイリアスは「.qmail-[ユーザ名]」で管理されています。これは何かしら自前でコンバートするしか無い。postfixadominでがりがり書いてくのもアリですが、CSVファイルかなんかにまとめて、テーブル「alias」に叩き込んだ方が安全かつ早いと思われます。
 他にも旧来tcpserver.dで管理していた接続許可元設定なんかもDB化できますので必要に応じて手を加えると良いでしょう。

 まーこんなマネは過渡期の一時的なものなのでしばらくすれば不要な手順になるわけですけどね。 基本的にはpostfixadminのテーブル構造さえ押さえておけばなんでもできるんじゃないでしょうか。

2012-06-11 [技術]

 …現象的になんとも言いかねる話でひょっとしたら世の中的に当たり前なのかもしれないけどなんか納得しかねるのでとりあえず備忘。

 Linux上のある2ヶ所に同名のファイルがあったとします。まあ最終的に同じ名称のファイルにコピーされればよいので別に同名でなくても良いのですが、話を簡単にするためにとりあえずそうしときます。
  例:
    /home/aaa/test.txt
    /home/bbb/test.txt
 ところがこの2ファイル、名前は同じだけども中身は全く別物で、例えば「~/aaa/test.txt」は1GB、「~/bbb/test.txt」は1KBだったとします。

 で、これをほぼ同時に、同一のパスとしてコピーします。ただし「サイズの大きい方を若干先に」実行し、その実行が完了する前に「サイズの小さい方を実行」します。
  例:
    cp /home/aaa/test.txt /home/ccc/
    cp /home/bbb/test.txt /home/ccc/  ←数秒後に実施(上書き実施)

 まあ多分何をしたいかは見ればお分かりかと思いますが同一ファイルに対する同時コピー時の排他制御はどー動くのかを確認したかったわけです。
 期待値としては「後からのコピーは拒否されて先にコピーされたファイルが残る」か「先のコピー終了後に後のコピーが実行されて入れ替わる」のどちらか…だったわけですが、コレがやってみると「先の(大きい)ファイルの先頭だけ後の(小さい)ファイルの中身が合成されたファイルが出来上がった」モノだからびっくり。
 より具体的には
  ・後から実行した小さいファイルのコピーが先に終了。
  ・最終的なファイルサイズは先に実行した大きいファイルのもの。
  ・小さいファイルの内容分、大きいファイルの先頭バイトが置き換わっている。
…とゆー状態。これがサイズがある程度近くなると発生せず、この場合後からコピーされた物が有効になってる様子(完全には未確認)。改めてmd5で比較したら別物になってました。

 まー内部的な挙動は想像できるのでそう不思議な話じゃないかもしれないけど、そんな同時コピーくらいでファイルが合成されるなんてのがしょっちゅう起きてたら世の中もっと騒いでてもいいんじゃないかなぁと思いつつ、そんな話は聞いたことないので実は大した話じゃない、既に解決策がある、実はオマエが無知なだけだpgr、って話だったりするのだろうか…うーむ。

 ちなみに環境としてはCentOS5.7上のext3、CentOS6.2上のext4どちらでも確認。
 更に言えば元々の発端は最近何度か話題に出してる「GlusterFS」で、異なるクライアントから同一ファイルに対し同時コピーしたらどうなるねん、という排他の確認が発端で、その際にわかりやすくするために極端にサイズが異なるのを使ってみた、ってだけだったわけですが。当然その際にもファイルが合成されたもんだから、うげ、GlusterFSって排他処理やってないのんか…と思ったら実は要因はそこではなかったという話。まあGlusterFSの要因ではないようなのでむしろ軽く安堵したわけですが。

 初期のext4には色々遅延系で問題があったらしいのでそれに起因したりしてるのかなぁ、と思ったらext3でもそうだし。いくらコピー時に「上書きしていいですか?→y」としたとしてもそーゆー「上書き」ではないよなぁ(苦笑)。世の中他の人はどうなってるんだろう。
関連タグ:Linux
2012-05-01 [技術]

 続き。

 Distributed-Replicatedでボリュームを構築した場合、後からフォルダを追加する際には初期構築時と同様全ての合計がreplicaで指定した数の倍数になるようにしないといけない。replicaの最小数である2とした場合、追加するフォルダも2の倍数ずつ、最小で2つaddする必要がある。

 この場合、先にreplicaとして登録されたフォルダ群は後から追加されたフォルダとは無関係に、そのままreplicaを構成する。なんのことかとゆーと初期に

  例:gluster volume create VOL replica 2 srv1:/fol1 srv2:/fol1 srv1:/fol2 srv2:fol2

として構築したglusterボリュームは、[srv1:/fol1] -[srv2:/fol1]を1ペア、[srv1:/fol2] -[srv2:/fol2]を1ペアとしてreplicaをするわけで、この上で

  例:gluster volume add-brick VOL srv3:/fol1 srv3:/fol2 ~

とかしてフォルダを追加しても[srv1:/fol1] -[srv2:/fol1]、[srv1:/fol2] -[srv2:/fol2]のペアはそのままに追加されたフォルダで[srv3:/fol1] -[srv3:/fol2]というペアが作られる事になる。追加するフォルダが物理的に別サーバ上にあるならば別に問題ないが、上の例のように1つのサーバ上の2フォルダを追加しただけでは同一サーバ上にreplicaを作成するだけなので冗長性がほぼ無意味になる。(RAID1的な挙動でいいならアリ)

 さてこの場合フォルダを追加した後に「replicaペアリングの再構成」をしたくなるわけだが、どうもそれに該当する操作は今のところ見当たらない。
 とりあえずスマートではないが一度「replace-brick」を行なってペアリングのフォルダを「移動」後、ペアリング可能なように空けたフォルダを再び「add-brick」で登録することで一応再構成することはできた。が、replaceはまんまフォルダの内容を移動することになるので容量が増えればそれだけ時間がかかるのが難点である。その分整合性にも気をつけなきゃいけないし。
 また、上記でreplaceを行った際に元フォルダ→新フォルダにデータのコピーが行われるわけだが、元フォルダに入っていたファイルはそのまま消されずに残る。なのでうっかりそのまま再利用しようとするとファイルの状況がめちゃくちゃになる場合があるようである。当初実験でreplace→addを行った後、分散ファイルの再構成を行う「rebalance」を行ったわけだが、なんか同名の空ファイルができたりと変な挙動をされてしまった。まあこの状況に限らず「createやaddする時は空フォルダをね」とゆーのを徹底したほうがよさそうだ。

 まーどっちにしろ私の例のように「1サーバ上の2フォルダを連結」なんて貧乏性的なマネをしなければ無問題な話ではある(苦笑)。
関連タグ:LinuxglusterFS
2012-04-18 [日記]

 先日のGlusterFSにおけるDistributed-Replicated話の際に、以下のような「同一ノード上の別フォルダを、ちょっと開けて設定」するボリューム構築例を挙げ、「でも同一ノード上に複製ファイルが集中する可能性は否定できないカモ」とゆー旨の事を書きましたが、

 例:gluster volume create glusterVol replica 2 transport tcp svr1:/home/brick1 svr2:/home/brick1 svr1:/home/brick2 svr2:/home/brick2

 その後の検証の結果、上記の場合まず「svr1:/home/brick1」と「svr2:/home/brick1」、及び「svr1:/home/brick2」と「svr2:/home/brick2」でそれぞれReplicaを構成し「ひとかたまり」とした上で、そのカタマリ毎にDistribute的にファイルを分散する、という動きをするようです。大雑把に言えばRAID1+0的な。0ではないけれども。
 なので同一ノード上の別フォルダを使って分散複製ボリュームを構築しても、設定時に離して書けば複製が同一ノード上に集中する=冗長性がなくなるという事態は防げるようです。ひょっとして当たり前?(苦笑)
 但しこの場合、後から構成対象のノードを追加する時にはノードの再構成する必要が出てくるでしょうけれども。

関連タグ:LinuxglusterFS
2012-04-18 [技術・作業]

 ちと複数サーバによるファイル分散、しかもある程度の冗長性を持った分散を実現する必要に迫られた。最初は自分で管理システムでも作って適度に分散ーとか思ってたのだが、いちいち整合性とか考えるのめんどくさい。今ならきっとお手軽なファイル分散管理システムがあるに違いない!と探して最も要件にマッチしたのが「GlusterFS」。ちょうど去年辺りRedHatの傘下に入ったらしく将来性と安定性にも一定の評価ができる点もポイント。
 Glusterのバージョンは3.2.6。OSはCentOS6.2でインストールはオフィシャルサイトにあったrpmから。

 で、これまでのバージョンだと連携した複数サーバに順繰りでファイルを保存していく「Distribute」、ファイルを全てのサーバに複製する「Replica」、ファイルを分割して並行保存する「Stripe」の3パターンからしか挙動を選べなかったらしいが、3.2.5以降辺りから基本の「Distribute」と、「Replica」もしくは「Stripe」を連携させた動きが取れるようになったらしい。今回は安全性重視なので「Distributed-Replicated」構成で構築することに。以降は環境構築時における微妙な実験結果を含む備忘録です。ちなみに間違ってる可能性も否定できないのでご注意を。

  • rpmでインストールする場合今のところx86_64環境しかないっぽい。今回別機能のために32bit環境も必要だったのだが、64bit環境で構築したホストのKVM上に32bit仮想環境をインストすることで対応した。
  • とりあえずgluster関係をインストールしたのはホストとなる4台の64bit環境。ゲストからはNFSでのアクセスで対応することに(後述)。
  • まずはglusterとしてのペアリング?を取るために「gluster peer probe HOSTNAME」コマンドで関連するサーバの登録を行うのだが、コレは複数台のうちどれで実行しても問題ない。また、最初に実行したサーバとは別のサーバで後から実行しても問題ない。→「管理サーバ」を特定する必要はないということ。
  • 実際に連携することになるボリュームは他のファイルシステム(extなど)でフォーマットしてあって構わない。というかしといたほうが何かと便利かな。
  • 1つのサーバ、というかノード上の異なるフォルダを指定することが可能。
   例:gluster volume create glusterVol replica 2 transport tcp svr1:/home/brick1 svr1:/home/brick2
  • ただし「Replica」系の設定をした場合、「同一ノードを避ける」事は行なわないようなので、状況によっては冗長化のためのReplicaが全くのムダに終わる恐れがある。
  • 「Distribute」の場合、基本的にボリューム作成時のノードの順序でコピーを行うらしい。容量によるバランシングはその後。「Distributed-Replicated」の場合も同様。
  • なので、各ノードの「複数ボリューム」を連結する場合、同一ノード上のフォルダを離して記述することである程度同一ノード上に複製されるリスクを減らす事ができるだろう。※完全に無くせるかは未検証。
   例:gluster volume create glusterVol replica 2 transport tcp svr1:/home/brick1 svr2:/home/brick1 svr1:/home/brick2 svr2:/home/brick2 ←svr1の間を開けている
  • その前の話だが、「Distributed-Replicated」を構築する場合、連結するノードの数はreplicaで設定する複製の数の倍数になってないといけないらしい、というか倍数になってないとコマンドが通らない。上記でわざわざ同一ノードの2フォルダを連結しようとしたそもそもの発端は、当初奇数であるサーバ3台で構成しようとしたためである。replica=2の2フォルダx3ノードで6フォルダ、と。一応これで構築は可能。当然のように後からノードを追加する場合もreplicaの倍数ずつ追加しなければならない。
  • 構築したボリュームは何らかの方法でマウントすることで利用可能になる。
  • 構築したサーバ、というかglusterがインストールされているサーバ上ならばマウントタイプ「glusterfs」でマウントできる。
     mount -t glusterfs svr1:glusterVol /mnt
  • そうでない場合NFSマウントがてっとり早いか。
     mount -o mountproto=tcp -t nfs svr1:/glusterVol /mnt
  • 「KVMで32bit仮想環境を構築」と上述したが、そのゲスト環境からはこのnfsマウントを行なっている。
  • マウントさえ済めば後はフツーにコピーなりでファイルを置け、かつ自動的に分散・複製を行なってくれる。
  • その性質上DBとかも置けるとは思うが、レスポンス的にどーだかは未検証。やらない方が良いとおもわれる。
  • 「Distributed-Replicated」で、「ノード数未満のreplica数を指定した」≒「全てのサーバには複製されない」設定でも、フォルダについては全てのサーバに作成される。なので「フォルダ作成時、条件に基づき特定ノードに分散して作成され、以降そのフォルダにコピーしたファイルはそのノードに集中してしまうのではないか」とゆー懸念は不要。

 …今のところこんなところ。またいずれ追加情報があったら記事追加します。
関連タグ:LinuxglusterFS
2012-04-17 [技術・作業]

 タイムゾーンがJSTに設定されてないCentOSをJSTに変更する場合、一般的には「/usr/share/zoneinfo/Japan」をコピーなりシンボリックリンクなりで「/etc/localtime」に紐づかせれば良いのだが、CnetOS5.7だとこの方法を行なってもJSTに変わらない、正確には「EST」に変わってしまう場合がある。
 どうも特定のver?の/usr/share/zoneinfo/JapanがESTのそれと置き換わってるらしい。対策としては別verでちゃんと動いてるJapanファイルを持ってくればOK。しかしなんでだかねぇ。
関連タグ:Linux
2011-11-24 [技術]

 おっと、噂では色々とゴタゴタしてリリースが遅れていたとゆー話の6がようやくお目見えですか。ついでだからここらでScientific Linuxへ乗り換えるのもアリかなとか考えていたが(まあそれはそれで引き続き検討として)現行CentOSベースのモノを入れ替える必要が出てきた場合はこちらの方がよかろうかなと。
関連タグ:Linux
2011-07-12 [日記]

 なによりカタカナ化した名前の響きが脱力系で良いw
2011-06-30 [モバイル]

 先日、本サイト稼働用の自宅サーバの「/home」領域としていたUSB外付けHDDが不調に、でも少し様子見する、とゆー話をしたがその後やっぱ不調が続いたのでなんとか入れ替えることに。

 前回は余り物の320GB2.5インチHDDをUSBHDDケースに入れてext3フォーマットしようとしたのだが、mkfsのところでよくわからないエラーになって完遂できず。
 試しにそのHDDをWin7につないでNTFSフォーマットしてみたところ問題なくできたので「CentOS5のファイルシステム系コマンドにはバグがある説」が濃厚かなぁと思いつつ、面倒だからNTFSフォーマットしたそのHDDをそのままマウントしちゃうことに。
 「mount -t ntfs…」しかし「Unknown」。あれー、man的にはできるみたいに書いてあるけどなー、と思い軽く調べたところ、CentOSはいくつかパッケージを追加しないとNTFSをマウントできないとの事。ここでそれらパッケージを入れてもよいのだが、次にOS毎再構築する必要が生じた際に、追加パッケージを導入しないとHDDをマウントできないとゆーのは互換性から考えるとあまりよろしくない気がしたので途中で却下。

 とりあえず違うHDDで試してみるか、とパーツ入れを漁ったら正体不明な1.5TBのHDDを発見(苦笑)。中を見ると32bitとおぼしきWindowsがインストされ、かつインスト直後で放置されてたよーなほぼまっさらの状態。いったい何のためにこんなん作ったんだっけ…と疑問に思いつつ、おそらくいらないモノだろーと判断。USBHDDケースに入れ替えてext3フォーマット。お、今度はフツーに完了。

 完了したところで適当にマウントさせ、元々のHDDのコピー作業に入る。さすがに何度かI/Oエラーでこけて完全にはバックアップできなかったものの重要なデータはほぼ無事で、復旧率は80%といったところ。

 さて次に新旧HDDのマウントポイントを入れ替え。/etc/fstabを書き換え…ようと思ったら最近は(※最近、とゆーにはだいぶ前からのようだが)デバイスを直接指定しないでデバイスに「LABEL」とゆーのを割り当てれば良いようになってるのね。なってるのね、と言いつつ普段デバイス名を認識して管理してる人にはかえって分かりづらくなってるのかもしれないが。
 ともかくコマンド「e2label」で旧HDDのラベルを別名に変更、新HDDのラベルを元々のラベルに振り替え。ちなみにちゃんと動作するかどうかは不明が別のデバイスに同じラベル名をつけることもとりあえずは可能だった。多分おかしくなるだろうからちゃんと別物に変更したが。

 ひと通り設定を終えたところで再起動。ちゃんと新しいHDDが「/home」として自動マウントされましたとさ。
2011-06-20 [日記]

 ちょっと需要があってCDブート(もしくはDVD、USBメモリブート)Linuxを作成する事に。
 CDブートLinuxは世に色々出ており有名どころではKnoppixだが、自分が求める環境には少々カスタマイズが必要でKnoppixそのままでは使えない。Knoppixのカスタマイズも試したけどクセがあって細かいカスタマイズが出来るようになるまでには時間がかかると判断し断念。

 まずはそれなりに使い慣れてるFedoraで、LiveCD、もしくはそのGUIフロントエンドである revisorを使う方向に落ち着いた。
 とは言えこの双方のツール自体未だ不完全ぽくクセがあってなかなか上手くいかない。とりあえず少しいじった中で把握…というかこうじゃね?という内容を羅列してきます。

 なおlivecd-tools-009-1.fc7、revisor-2.0.4.1-2.fc7を元に記述しています。
 また内容にはいーかんじでデタラメが混じってる可能性がありますので鵜呑みにしないで下さいw


○コンフィグ(キックスタート)ファイルは用意してからやったほうが良い。
 LiveCDだと長いコマンドオプション、revisorだとGUIで作成する内容を指定できるけど先にキックスタートのコンフィグファイルを作成してそれをカスタマイズ→読み込むようにした方がラク。
 コンフィグファイルはLiveCDのデフォルトのものを参考というかベースにするのが無難。 GUIのキックスタート作成ツールでksファイル作って読み込ませた事もあったけど、途中でエラー吐いて止まってしまった。
 ただしLiveCD用のサンプルファイルをベースにしても下手すると止まるので注意。

○止まった時は再起動が吉
 LiveCDの場合Pythonのエラー、revisorの場合フリーズして止まる事がままある。パッケージのダウンロード元が混んででダウンロードに失敗したパッケージがあった時や、コンフィグファイルに不備があると止まる。長々と時間かけた後に止まられると結構萎える。
 この場合、コンフィグファイルを正常なものに替えて再実行してもまた止まる事がある。どうやらエラーの時に色んなイメージファイルとかを掴んだまま放さないで落ちてるっぽい。裏でナニがどうなってるかはわかりにくいので素直にOSをリブートした方が早いと思われる。

○revisorはコンフィグファイルを正常に読んでないっぽい。
 コンフィグファイルでインストールするパッケージを取捨選択することができるが、 revisorでそれを読み込んでも上手く反映されてないよーな気がする。特ににパッケージを取り除く「-[パッケージ名]」の表記が悉く無視されてるよーな気がする。
 また、SELinuxの設定、タイムゾーンの設定もコンフィグの内容を無視してデフォルトに戻してるよーに見える。ひょっとしたら表面上の事だけかも知れないが。
ある程度コンフィグがまとまってきたらrevisorではなくLiveCDで作成した方が良いかもしれない。

○リポジトリは近場に
 コンフィグファイルでリポジトリを指定する「repo=〜」の記述があるが、デフォルトのままだと遅くてやってられないので近場を探して変更するが吉。

○LiveCDのisoイメージベース再作成には注意
 livecd-creatorの場合、既に存在するLiveCDのisoイメージをベースにパッケージを追加変更するとゆーマネができる。(オプション「--base-on、--package、--exclude-package」等参照)
 しかしながらまず「パッケージを取り除くだけ」というマネ、つまりは--exclude-packageだけを指定することができない。必ずナニかしらパッケージを追加しつつ、excludeしなければならない。
 そして、元のisoイメージの情報を完全に複製はしてくれないらしい点にも注意。具体的には言語、キーボード、タイムゾーン等の設定。日本語デフォルトになるよう作ったのにこれで再作成したら英語デフォルトに戻されてしまった。

○パッケージはしつこく消しても消えないモノがある
 詳細は不明。はっきり「消せ」としてるのにいつまでも残ってるパッケージがある。依存性があると思われてるのかもしれないが…。

○起動後の挙動について
 これはサンプルコンフィグファイル「livecd-fedora-desktop.ks」を見ると分かり易い。上記ファイルは「%post」で起動直後の挙動を記述しているが、そこに起動時の挙動を制御する「etc/rc.d/init.d/fedora-live」を作成するシェルを記述している。自動で行いたい処理を追加する場合はこのファイルに便乗するのも手である。

○時間差・自動ログイン
 上記fedora-liveの中でGUI起動時の時間差ログインの記述をしている箇所がある。
sed -i -e 's/\[daemon\]/[daemon]\nTimedLoginEnable=true\nTimedLogin=fedora\nTimedLoginDelay=3/' /etc/gdm/custom.conf
がそれ。見ての通り「/etc/gdm/custom.conf」に時間差ログインのパラメータ「TimedLoginEnable」「TimedLogin」「TimedLoginDelay」を書き込む処理であり、この行自身が時間差ログインを制御しているわけではない。ここを編集してユーザ名、ディレイ時間、そもそもの時間差ログイン有無などを設定できる。
 またこの3つのパラメータを「AutomaticLoginEnable=true」と「AutomaticLogin=[ユーザ名]」の2つに入れ替えると時間待ちをせず自動ログインするようになる。

○「ハードドライブにインストール」を消す
 livecd-fedora-desktop.ksで作成したブートイメージだと、ログインするとデスクトップ上に「ハードドライブにインストール」というショートカットが作成される。そういう環境向けにはいいだろうが、完全にCDブートに限定したい場合は少々邪魔である。このファイルの本体は[各home]/Desktop/liveinst.desktopというショートカットであり、削除すればデスクトップ上からアイコンが消えるのだが、元から存在するファイルではなくGUI起動時に後から生成されるファイルであり、例えばfedora-live内で
rm -rf /home/fedora/Desktop/liveinst.desktop
とかやっても消えてくれない。
 これは、GUI起動時に自動実行される「/etc/X11/xinit/xinitrc.d/zz-liveinst.sh」が毎回ショートカットを作成しているため。fedora-live内でこのファイルの実行権限を剥奪すると自動実行されなくなりアイコンは作成されなくなる。
chmod 000 /etc/X11/xinit/xinitrc.d/zz-liveinst.sh
○微妙な日本語の文字化け
 日本語環境に合わせてコンフィグファイルを作成する際には「lang」「keyboard」「timezone」の値をそれぞれそれっぽく編集する(※もちろん日本語フォントパッケージもインストールするが)。これは他の日本語対応で作成したキックスタートファイルを参考に「lang ja_JP」「keyboard ja106」「timezone Asia/Tokyo」とすれば良いが、このままだとビミョ−−−に文字化けするところがある。全部じゃなくてビミョーに起きるので質が悪い。
 これは「lang」が不完全なのが原因。むしろ元のlivecd-fedora-desktop.ksを参考に「lang ja_JP.UTF-8」と、マルチバイトの文字コードまで指定する必要がある。

 とりあえず気付いた点を列挙しました。また何か気付いたら追記します。
関連タグ:Linux
2007-10-19 [技術・作業]

 ネットワーク経由で時刻合わせを行うntpサーバ。某所で動かしてたこの ntpサーバが、なんだか時折サービスがダウンするよーになってしまった。 バージョンは現時点でのRHEL v3最新4.1.2-4.EL3.1。結構前のリリースではあるが それから上がる様子が無い。
 とりあえず該当エラーについて調べた所、bugzillaとか経由して以下の情報に到達。

[ntp:hackers] [PATCH] - ntpd Exiting:out of memory.

 ntpdの-Uオプション(※稼働ユーザをrootから他に移す)を付けてた際に、RLIMIT_MEMLOCKの値が 小さいと起こるとかなんとか。パッチも出てるし最新版では対応されてるみたいだけど、 RHEL標準外のを入れると後々管理がメンドーになるかと思ったので、 とりあえずRLIMIT_MEMLOCKの値をいじる事で対応する事に。
 RLIMIT_MEMLOCKの値はulimitの-lオプションで変更可能。ntpd起動シェルのアタマにulimit -l [テキトーな数値] を書き込む事で対応可能なようだけど、他のプロセスとの兼ね合いも考えて、init配下の起動スクリプトの 起動前に読み込まれて実行される「/etc/initscript」に以下を記述。ちなみにこのファイルはデフォルトで無かったので 新規作成。

ulimit -l [テキトーな数値]
eval exec "$4"

 書き込んだ数値は15MBくらい。ここらへんはマシンスペックとご相談になりますが。 これでntpdを再起動したところ、上記エラーは出なくなりました。

 なお上記エラーは必ず発生するとゆーわけでもなく、ほぼ同環境で発生しないサーバもあります。 使用頻度とか親ntpサーバとかの兼ね合いもあるのかもしれません。
関連タグ:Linuxバグ
2005-12-13 [技術・作業]

 ※取り急ぎ試しただけなので余計な設定を入れてる可能性があるので注意。

 Fedora Core4でrsshを使ってsftp限定&jailをやろう話。
 インストールそのものはアップされてた(※現時点で本家には無かったが)rpmでOK。 個別にコンパイルする必要はないっぽい。sftp限定だけならrssh.confの設定変更だけで出来た。

 jail話。jailを行うには一般的なchroot設定と同じように、稼働に必要なファイルを chroot対象のフォルダに叩き込む必要があるようだが、最新版rsshにはそれらをある程度勝手にやってくれる mkchroot.shが付属してたので実行。いくつかエラーがでるけど、見たところ余計なコピーをやろうとしてるだけで 特に問題は無いっぽい。その後rssh.confのchrootpathを修正するわけだが、これだけではうまくいかなかった。
 なので一般的なchroot環境構築の手法に従って、dev下の追加、bin下の追加と、sh及びbash、及びそれらの稼働に必要な lib関係のコピー、及びetc下のgroup、shadowの設定を行い、とりあえずフツーにchrootを可能にしてから sftpしたところ、無事jail環境で稼働するようになった。
2005-11-19 [技術・作業]

 諸事情によりログの集中管理システムを構築する必要に迫られ、とりあえずsyslogを集めた後、 PHPで簡単に解析して表示するLinuxサーバを構築したのだが、複数ヴァーチャルドメインを扱う メールサーバのログが膨大にあり、ファイルに溜めてると処理が結構重い事が判明。 どっちにしろファイルベースでのコントロールは解析時の自由度が低く扱いづらいので、 集めたログをDBに溜める手法を模索した結果、見つかったのが「Modular Syslog」、通称msyslog。 ほぼsyslog互換ながらMySQL、PostgreSQLへの吐き出しや、暗号化による改竄対策、 TCPでの接続サポートなどの機能拡張を行ったモノ、らしい。

 インストール、設定はこちらのサイト様 を参考に、私の場合PostgreSQLなので随時読み替えで対応。ただ、今回の場合ログ収集サーバのローカルに PostgreSQLも構築したのだが、syslog.confでDBを指定する際に

 %pgsql -s [サーバ名] -u [ユーザ名] -p [パスワード]・・・

という風にサーバ指定でTCP接続しようとすると何故か上手くDBに吐いてくれない(※pg_hba.confやpostgresql.conf、接続ユーザのGRANTは設定済み)。 なのでpostgresql.confでTCPソケットを無効化、ローカルでの接続に限定した上で、

 %pgsql -u [ユーザ名] -p [パスワード]・・・

のようにサーバ指定を外したらちゃんとDBに吐いてくれるようになった。具体的にはこんなカンジ。ちなみに念のためファイルにも落としてます。ファシリティ、プライオリティはお好みで。

local4.* %pgsql -u [ユーザ名] -p [パスワード] -d [DB名] -t [テーブル名] -F -P

local4.* /var/log/[ファイル名]

これでとりあえず各種Linuxサーバのログを(syslog経由限定だが)集中管理できるようになった。 あ、ちなみにリモート側は標準syslogのリモート送信設定で問題ないです。UDP限定になるけど。

 で、次にやりたくなるのがWindowsサーバのログ収集。ぶっちゃけイベントビューアで見れる内容を syslogのプロトコルで吐き出してくれる手法があればいいのだが・・・ってありました。 「NTSyslog」。ありがたい事に日本語をEUC-JPに変換して送信してくれるそうで。 早速インストール&実行。ところが確かにログは吐いてくれたのですが、受け取った側で 日本語が全て「XXXXXX・・・」となってる。試しにmsyslogを標準のsyslogに戻してみると、 こっちではちゃんと日本語で保存されるので出し側には問題ないみたい。msyslogの挙動か。
 試しに標準syslogとmsyslogのソースを見比べたけど、書き出し部分にそれほど大きな差は見受けられない。 てゆかよくよく観察してみるとログ管理サーバ本体が書いてるログは日本語も化けずに書き出されてたけど、 リモートサーバから受け取ったログは上記のように化け(つか変換)されてる。てことは 問題はUDPで受け取る際の挙動かな、と推察。msyslogのUDP受信モジュール(?)im_udp.cのソースを眺めてみると、 112行目付近に以下のような記述を発見。

/* change non printable chars to X, just in case */

for(p = ret->im_msg; *p != '\0'; p++)

if (!isprint((unsigned int) *p) && *p != '\n')

*p = 'X';



 ホントはここんところをEUC-JP対応に書き換えればいいんだろうけど、ちょいと面倒だったので お気楽に丸々コメントアウト。リコンパイルの結果、無事リモートから送られた EUC-JPもきちんと受け取れるようになりましたとさ。
 あ、言い忘れてましたがmsyslogのバージョン1.08gの話です。
関連タグ:LinuxWindows
2005-07-06 [技術・作業]

1.oci8対応のPHPで、時々Oracleにアクセス出来なくなる。Apacheの再起動で直るけど。

2.同じくoci8対応のPHPで、コマンドラインからシェル起動させてoci8関数を使うとシェル終了時に必ず セグメント違反が発生する。終了したタイミングなんでデータの処理は一見問題ないのだが・・・。

3.Redhat-EL-AS-v3標準OpenLDAPのSRPMのconfigureオプションに--enable-phoneticつけてもphoneticが 有効にならない。
関連タグ:LinuxApacheOracle
2005-02-02 [技術・作業]