Hogex spotted

Feed Rss

PowerShellからADをインストールする。

最近、Windows系スキルの弱さが色々と問題になってきたのでお勉強がてら色々触る事にしました。
今回はWindows Server 2012 R2でADを構築してみます。Windows超初心者なのでツッコミ大歓迎。

環境はAWS上でt2.mediumを使ってます。あとGUIで頑張ってる記事は他に色々とあるので、今回はなるべくPowerShellを使ってCLI中心で頑張ってみます。

今回の参考URL
サーバーの役割と機能を追加する [Microsoft Technet]
最初のドメインコントローラを構築する – Active Directory on AWS(2) [Developers.IO]
Windows Serve 2012 PowershellでADドメインサービスの追加、構成、削除 [SE’S BOOK]
Windows Server 2012におけるActive Directoryの変更点(2) [Always on the clock]

まずは1台目。

インストール中にセーフモード時のパスワードを決めて、パスワード入れたら自動再起動がかかる。起動までしばらく時間がかかります。

続いて2台目の設定。
事前にDNSのリゾルバを先ほどのサーバのものに変更しておきましょう。

セカンダリサーバのインストール時にはクレデンシャル入力の画面が出てきますので、ドメインのAdministrator権限を入力して下さい。
こちらも処理が終わったら再起動がかかります。とりあえずDCが出来たので次はクライアントですなー。

先日NIC2枚刺し+同一サブネットという個人的にはBondingでもすりゃいいじゃん的な用途を扱う事になりまして、ちょいハマったのでメモしておきます。

単純に同一サブネット内でのネットワークについては特に何も考えなくていいんですが、これ1つ以上ルータをホップするケースになると話がややこしい。要はeth1に飛んできたパケット、受信はちゃんと出来るんですが応答するときに他所のネットワーク経由だとデフォルトゲートウェイを通りたいからeth0から返したいってな具合になっちゃうと。

というわけで、これをどうにかするのがPolicy Routingです。
要するに、Source IP Addressと通信するIFの組み合わせのルールを作って、そのポリシーに従ってルーティングテーブル書いてやるわけですね。

お手軽にAWSで環境作ってみましょう。
通信可能な異なるサブネットに所属するインスタンスを2つ作って、片方にはENIを2つくっつけます。
Amazon Linuxはこの辺、ENIをアタッチすると非常に気を利かせてくれて全自動でやってくれちゃうので、今回はRHEL7.1のインスタンスを使います。何か特別な理由が無い限り、やっぱAWSではAmazon Linux使うのが一番無難ですね。

まずインスタンスを2つ立ち上げる

これで準備完了です。今回は各インスタンスのIPアドレスは次のように振られました。
インスタンスA eth0 172.31.4.246 eth1 172.31.9.117
インスタンスB eth0 172.31.17.18
※グローバルアドレスは省略しています。

この状態でインスタンスBからインスタンスAのそれぞれのアドレスにpingを打ってみます。
結果は次の通り

では、ポリシールーティングの設定をしてみましょう。
まずインスタンスAの現在のルーティングテーブルを確認します。

ip route show の結果の通り、eth1のインターフェースにはゲートウェイが何もありません。
そこで、Source IP Addressが172.31.9.117の場合、というルールを作ってそこにゲートウェイを設定するわけですね。

これでルータを跨いでもそれぞれのIFで正常に通信できます。
恒久的に設定を保存する時はいろいろ設定ファイルを書いてやります。

・/etc/sysconfig/route-eth1

・/etc/sysconfig/rule-eth1

・/etc/iproute2/rt_tables

 

ただ、RHEL7ではなぜかrule-eth1が上手く反映されず・・・。この辺は分かったらまた追記予定。

前回はとりあえずコンテナが動く所までいったので、今回はコンテナのカスタムと管理用のプライベートレジストリの作成をやりたいと思います。
Dockerは標準でDockerHubというPublicなレジストリがあるみたいなんですが、アプリケーションコードまで含んだコンテナをデプロイ用に使いたい等、Publicな場所はまずいケースも多々あると思うので・・・。
尚今回はホストが2台出てきます。

docker.un-is.local      docker実行用のホスト
docker-reg.un-is.local  プライベートレジストリ用ホスト

両方ストともdockerパッケージはインストール済みとします。

では、まずDockerfileから独自イメージを作成までを行いましょう。
テスト用ですので、比較的簡単なものでsshdが動くだけのCentOS7のイメージを作ってみます。
作業用に/tmp/docker/demo/sshディレクトリを切ってDockerfileを作成します。

ここまで出来たら準備完了です。docker buildコマンドでイメージを作成してみます。

docker buildコマンド実行後にdocker imagesコマンドで確認すると、demo/sshというイメージが一番上に追加されています。
実行してsshdがきちんと動作しているか確認。Dockerfile中でID/PWともに”hoge”のユーザーを作成しているので、そのユーザーでログイン。

無事にsshからログイン成功。
イメージが完成した所で次は独自レジストリへの登録を行います。

まずはサーバの準備。といっても、オフィシャルのコンテナイメージがあるので非常に簡単です。
イメージ名はstackbrew/registryなので、DockerHubからpullしてそのまま実行してやるだけです。

これでコンテナが起動しdocker-regのtcp:5000にコンテナのtcp:5000がバインドされます。
プロトコルはhttpなので、とりあえず動作確認をしてみる。

無事に動いてる。これで後はFWなんかが適切に動いてれば外部からも普通につながります。
逆に言えば、アドレスさえ分かってしまえば登録・DLやり放題なので要注意。
認証機構を設ける場合はApacheやnginxを噛ませてHTTPS + BASIC認証っていうやり方の模様。ちらっと調べたところ、HTTPS接続する場合オレオレ証明書だとクライアント側が接続を拒否しちゃうので、CA証明書をクライアント側に食わせないとダメみたい。
今回はとりあえずリモートからpush/pullしたいだけなので素のHTTPでつなぎます。といっても、クライアント側に一つ細工は必要なんだけどね。

ひとまず、登録のための下準備。登録する為に、対象のイメージに対して[DockerRegistryホスト名]:[ポート]/[任意の名前] の形式でタグを付けます。
今回のお名前は docker-reg.un-is.local:5000/ssh を使用。

タグ付けが出来た所で、docker pushコマンドで登録。といっても今回は失敗するんだけど・・・。

エラーメッセージ曰く、HTTPやオレオレ証明書のホストに接続するなら、デーモンの起動オプションに--insecure-registry docker-reg.un-is.local:5000 を追加するか、CA証明書を /etc/docker/certs.d/docker-reg.un-is.local:5000/ca.crtに追加しろって事らしい。
今回はHTTP接続なので、おとなしく起動オプションを追加。
/etc/sysconfig/docker に起動オプションを追記する所があるので

こんな感じでオプションを追加してやる。変更したら
systemctl restart docker.service
でdockerデーモン再起動。

無事成功。試しにレジストリ側でさっき登録したイメージをpullして起動してみる。
ちなみに、localhostは最初から信用されたホスト扱いっぽいので/etc/sysconfig/dockerの編集は無しで動く。まあ、当たり前かw

無事にSSH接続に成功。

世間での流行からしばし遅れること、ちょっとだけまじめにDocker触り始めたので備忘録。

 

とりあえず、1日目なのでごくごく簡単にインストールとコンテナ動かして見る所くらいまでを。環境はCentOS7で、Docker1.3.2(公式repoのRPM)を利用。

インストールはフツーにyum一発です。終わったらデーモン起動。

 

デーモンの起動が問題なければ、とりあえず適当にイメージを引っ張ってきて動かしてみます。

 

無事に立ち上がったら、コンテナで新しくシェルが立ち上がります。デタッチはC-p C-q

再度アタッチするときはdocker psコマンドでコンテナIDを確認してアタッチ。

 

現在はコンテナで走らせてるのがbashなので、シェルをexitで終了させたらそのままコンテナは終了します。

PID 1がsystemdでもinitでもなくbashなのが凄い違和感w

 

とりあえず、動かすだけならDistroに組み込まれただけあって非常に簡単に動きました。

Dockerfile作ってLAMP動かしたりデプロイしたりする所までは最低やるつもり・・・。

CentOS6.3 + SELinux Enforcing環境でPostfix + MySQL + PostfixAdminのバーチャルドメイン環境を作ったらSELinux周りで色々苦労したので覚書。

いい加減何も考えずにSELinux OFFというのからはインフラ屋として脱却したいところですねえ。

 

まず、SELinux関連のツールを入れないと何も出来ないのでyumで次のパッケージを入れましょう

setools

setroubleshoot

 

ツールを入れたら次はログからどこで引っかかっているかを見る。

/var/log/audit/audit.logのtype=AVCとなっているものがSELinuxのログ。参考に1つレコードを出すと

 

type=AVC msg=audit(1361331465.429:2108): avc: denied { connectto } for pid=7711 comm=”cleanup” path=”/var/lib/mysql/mysql.sock” scontext=unconfined_u:system_r:postfix_cleanup_t:s0 tcontext=unconfined_u:system_r:mysqld_t:s0 tclass=unix_stream_socket

 

このようなログが表示される。読み方としてはまず「avc: denied { connectto }」でconnecttoアクションがSELinuxで拒否されたという意味。次にscontextがソースプロセスのコンテクスト。これの内容は完全には把握しきれていないけれど、今回注目するのは「postfix_cleanup_t」の部分。tcontextはターゲットファイルのコンテクスト。こちらも同じく「mysqld_t」の部分に注目する。最後にtclassの右辺部分。今回はこの4つの情報を元にSELinux側で処理を通過させる為のデータを作成します。

 

これらのデータを元にSELinuxの挙動を変更するモジュールデータを作成します。まずは適当な作業ディレクトリ上で「local.te」というファイルを作成します。内容は前述したサンプルのログレコードの場合、次のようになります。

1行目はおまじないだそうです。尚、コメント行は#で挿入できます。

ファイルが出来たら

$ make -f /usr/share/selinux/devel/Makefile

コマンドを実行します。エラーが無ければカレントディレクトリに「local.pp」ファイルができるので、これを

$ semodule -i local.pp

コマンドで読み込ませます。読み込ませるのには少し時間がかかります。

成功していれば同じ処理をした時にaudit.logから該当ログが消えているはずです。

実際に私がバーチャルドメインを正常に動かす為に用意したlocal.teファイルがこちらになります。

また、これらのファイルをaudit.logから自動生成してくれるaudit2allowコマンドやaudit.logを解析して解決のヒントを提示してくれる「audit2why」コマンド等もあるようです。

いずれも $ audit2why < /var/log/audit/audit.log のような形で食わせてやれば結果が表示されます。

また、$ setsebool -P *****=true のようなコマンドで解決できる場合もあるので、そちらで解決できるならその方がお手軽だと思います。

GlusterFSの検証を行なっているので、作業の備忘録・メモ代わりに色々と使い方を書いてみます。

今回は

・サーバ2台、クライアント1台

・サーバ2台でレプリケーションクラスタを組む

という所までやってみたいと思います。

この先の展望としては

・フェイルオーバー時の動作検証

・Heartbeatとかと組み合わせて、フェイルオーバー時の自動切り替えが可能か

・ボリュームの設定変更の柔軟性

と、とりあえずこの辺は色々いじくってみたいなーと思います。

 

ひとまず、今回はGlusterFSでのレプリケーションファイルサーバを動かす所までいきます。

構成はこんな感じ↓

・サーバ#1 server1 192.168.1.1

・サーバ#2 server2 192.168.1.2

・クライアント client 192.168.1.3

尚、OSは全てCentOS6.3 x86_64です。

 

先ずは必要なパッケージを次のコマンドでインストールしておきます。サーバ・クライアントともに共通です。
# yum install fuse fuse-libs

 

次に、glusterの公式サイトからrpmを拾ってきます。全てのホストに3つのパッケージ全てをrpmコマンドでインストールします。

http://download.gluster.com/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-3.3.0-1.el6.x86_64.rpm

http://download.gluster.com/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-fuse-3.3.0-1.el6.x86_64.rpm

http://download.gluster.com/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-server-3.3.0-1.el6.x86_64.rpm

 

インストールが終わったら、サーバ側でglusterdを起動します。

[root@server1 ~]# chkconfig glusterd on

[root@server1 ~]# service glusterd start

[root@server2 ~]# chkconfig glusterd on

[root@server2 ~]# service glusterd start

 

次にサーバでクラスタピアの設定を行います。

[root@server1 ~]# gluster peer probe 192.168.1.2

これでserver1とserver2がクラスタピアとしてお互いを認識しました。

 

次にGlusterFSのボリュームを作成します。GlusterFSはボリュームを構成する部品を「ブリック」という単位で扱います。

「ブリック」の実態はディレクトリです。複数のブリック、つまりディレクトリをまとめて抽象化を行い、単一の大きなボリュームとして見せるのがGlusterFSのお仕事です。

ボリュームの作成は次のように行います。

[root@server1 ~]# gluster vol create ReplVol01 replica 2 192.168.1.1:/var/share/brick01 192.168.0.2:/var/share/brick01

[root@server1 ~]# gluster vol start ReplVol01

これで、Server1の/var/share/brick01とServer02の/var/share/brick01を組み合わせたGlusterFSボリューム「ReplVol01」が作成されます。

コマンド中の「replica 2」は2つのブリックを使ってレプリケーションボリュームを作成するという意味になります。

ボリュームタイプはレプリケーションの他に「分散」と「ストライピング」が選択できます。ストライピングを選択する場合はオプション「stripe」を選択します。ボリュームタイプ指定を省くと自動的に分散となります。

 

ボリュームの状態を確認するには↓のコマンドを発行します。

[root@server1 ~]# gluster vol info

このコマンドで、マウントするボリュームのStatusが「Started」になっていれば、利用可能な状態となっています。

 

次にクライアントからマウントします。マウントはGlusterのパッケージをインストールすれば、標準のマウントコマンドで行えます。

[root@client ~]# mount -t glusterfs 192.168.1.1:/ReplVol01 /mnt/

これで正常にサーバが動作していればマウントが完了します。ね、簡単でしょう?

あとはごく普通のファイルシステムとして扱えます。試しにクライアントからファイルを置いてみて、サーバ側で/var/share/brick01ディレクトリを直接除いてみたら、両方のサーバにファイルができていました。ただ、Gluster的にはこのスタイルのアクセスはアウトらしいので(ストライピングとかありますしね)、通常使う分にはネットワーク越しでマウントしてアクセスするだけにしてねって事でしょう。

ひとまず、今回は以上です。次回からはわざと落としてみたり、色々やってみますー。

https://rhn.redhat.com/errata/RHBA-2012-0541.html

 

Details:

複数のバグが修正されたopenswanパッケージがRHEL6で利用可能になりました。

OpenswanはフリーのIPsec及びIKE実装です。IPsecは認証サービスと暗号化サービスを提供する為に強力な暗号を使用します。これらのサービスは貴方が信頼性のないネットワークを通じて安全なトンネルを作成することを可能にします。OpenswaはデフォルトのLinuxカーネルに存在するNETKEY/XFRM IPsecカーネルスタックをサポートします。Openswan 2.6.xは更にIKEv2(RFC4306)をサポートしています。

このアップデートでopenswanパッケージは多くのバグフィックスを行いました。この変更についてのドキュメントはまもなくテクニカルノートドキュメントに記載される予定です。
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.2_Technical_Notes/openswan.html#RHBA-2012-0541

全てのopenswanユーザーにバグが修正された最新版へのアップグレードを推奨します。

Learn more

https://rhn.redhat.com/errata/RHBA-2012-0500.html

 

Details:

1件のバグが修正されたlibvirtパッケージがRHEL6で利用可能になりました。

libvirtライブラリはLinux及び他のOSの仮想化システムの管理、または対話的な操作の為のC言語APIです。さらに、libvirtはリモートの仮想化システムの為のツールも提供します。

次のバグが修正されました:

 

ゲストOSのライブマイグレーションが(Ctrl+Cコンビネーションによって)唐突に終了した時、libvirtデーモンは受け入れた将来のマイグレーションも次のエラーメッセージで終了していました。

「error: Timed out during operation: cannot acquire state change lock」

このアップデートで呼び出されたドメインの接続が閉じられた時の登録のクリーンアップコールバックが追加サポートされました。マイグレーションAPIは障害に対して堅牢になり、プロセスが途中で終了した場合後続のコマンドで再開が可能です。(BZ#806206)

 

全てのlibvirtユーザーにバグが修正された最新版へのアップグレードを推奨します。このパッケージをインストールした後、”service libvirtd restart”コマンドでlibvirtdを再起動する必要があります。

Learn more

https://rhn.redhat.com/errata/RHBA-2012-0536.html

 

Details:

1件のバグが修正されたcorosyncパッケージがRHEL6で利用可能になりました。

CorosyncパッケージはCorosyncクラスタエンジンとC言語APIをRHELクラスタソフトウェアに提供します。

次のバグが修正されました:

 

corosyncの基礎ライブラリはInter-Process Communication(IPC)に利用する/dev/shm共有メモリファイルシステム上のテンポラリバッファを削除していませんでした。したがって、もし適切な権限を持たないユーザーがIPC接続を試みた場合、テンポラリバッファが解放されていない旨のエラーメッセージと共にその試みは失敗します。これは最終的に/dev/shmが飽和しDoSにつながります。このアップデートでcorosyncサーバがテンポラリバッファを削除していない場合にアプリケーションから呼び出されたcoroipccライブラリが削除するよう変更しました。/dev/shmファイルシステムはこのシナリオと同様に不要なデータで散らかる事はなく、IPCコネクションは期待通りに確立します。(BZ#810917)

 

全てのcorosyncユーザーにバグが修正された最新版へのアップグレードを推奨します。

Learn more

https://rhn.redhat.com/errata/RHSA-2012-0533.html

 

Details:

1件のセキュリティ問題修正されたsamba3x及びsambaパッケージがRHEL5,RHEL6で利用可能になりました。

RedHatセキュリティレスポンス・チームの評価はImportantです。Common Vulnerability Scoring System (CVSS) 基礎スコアは、CVEリンクのリファレンスセクションから利用可能です 。

SambaはオープンソースのServer Messages Block(SMB)またはCommon Internet File System(CIFS)プロトコル実装で、これはPC互換機でファイル、プリンタ及びその他情報を共有することができます。

 

SambaがLocal Security Authority(LSA) Remote Procedure Calls(RPC)を処理する際に問題が見つかりました。認証されたユーザーはこの問題を利用して、共有されたファイルやディレクトリのパーミッション変更や作成、削除、変更、またSamba認証データベースの書き換えの為のRPCコールを管理者権限と同様に発行することができます。(CVE-2012-2111)

 

RedHatはこの問題を報告したSamba Projectに感謝します。また、この問題の上位レポーターとしてIvano Cristofoliniを認めます。

この問題へのバックポートパッチを含んだパッケージへのアップグレードをSambaユーザーに推奨します。アップデートをインストールした際にsmbサービスは自動的に再起動されます。

Learn more


   Beat diabetes   Diabetes diet