GeeklogというCMSがあるようです。日本語版はhttp://www.geeklog.jp/で紹介されています。XOOPSとかと何がちがうのかよくわかりませんが、各機能はプラグイン形式のような雰囲気です。WebアプリケーションでのCMSツールはこういったプラグイン形式のものが多いのですが、これといった決定打になるものはない、というのが個人的にもっている感想ですが、Geeklogはどうなのでしょうか。
Webアプリケーションの一番の利点は、Webブラウザでアクセスできれば動作するということであり、利用する場面に応じて好きな技術、ソフトウェアを組み合わせて使えるという事が重要なのではないかと考えています。
そろそろXOOPS, ZOPE, Geeklog といったものも考慮しようかなと思いますが、これらが登場してから結構な時間が経つのに、いまだブレイクしていないところを見ると、決定的なものが抜けているのではないかと言う気がしてしまいます。それが何か見抜ける眼力が欲しいのですが…
Fedora Cora 5 へOpenLDAPをインストールしてみました。
# yum install openldap-server openldap-client # yum install openldap-servers openldap-clients # rpm -qa | grep openldap openldap-clients-2.3.19-4 openldap-devel-2.3.19-4 openldap-2.3.19-4 openldap-servers-2.3.19-4
設定ファイルはコピーしておきます。
# cp /etc/ldap.conf /etc/ldap.conf.original # cp -r openldap/ openldap.original # ls -dl openldap openldap.original/
サーバ証明書などのありかを確認します。例えば、Apache HTTPD Server でHTTPSが使えるようにしてあるなら、すでにSSLを使ってサーバ証明書などを作成しているはずですから、/etc/httpd/conf.d/ssl.conf をみてOpenSSLで生成されたサーバ証明書、秘密鍵のファイル名を確認しておきます。もしなければこちらを参考にするなどして作成をしてください。
SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
ldapサーバの起動ユーザが参照できるようにグループ、モードを変更しておきます。
# chgrp ldap /etc/pki/tls/private/localhost.key # chgrp ldap /etc/pki/tls/certs/localhost.crt # chmod g+r /etc/pki/tls/certs/localhost.crt # chmod g+r /etc/pki/tls/private/localhost.key
ちなみに、SSLRandomSeedで /dev/random、/dev/urandom どちらを使うか指定ができることを初めて知りました。/dev/randomが調子悪いときは /dev/urandom を使うように指定するといいようです。
SSLRandomSeed startup file:/dev/urandom 256
設定は「 /etc/openldap/slapd.conf 」にあります。これを以下のように編集します。なお、LDAPのデータベースファイルは，/var/lib/ldapディレクトリ内に格納されますから、データベースを破棄したい場合は/var/lib/ldapディレクトリにあるファイルを削除します。ここでは、変更分だけ示しておきます。「TLSCACertificateFile」にはFedora Core 5であらかじめ用意されているファイル 「 /etc/pki/tls/certs/ca-bundle.crt 」を指定しています。
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/pki/tls/certs/localhost.crt
TLSCertificateKeyFile /etc/pki/tls/private/localhost.key
database bdb
suffix "dc=localhost,dc=localdomain"
rootdn "cn=Manager,dc=localhost,dc=localdomain"
# slappasswd -h {SSHA} -s changeit
# rootpw changeit
rootpw {SSHA}Yl8SUby2Ry2qq5/EbKE847dhqb7ZcNef
TLS/SSL対応のために、/etc/openldap/ldap.conf も次のように編集しておきます。
HOST 127.0.0.1 BASE dc=localhost,dc=localdomain #TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERTDIR /etc/pki/tls/certs TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
暗号化されたパスワード用文字列はslappasswdコマンドを使って取得することができます。次の例ではMD5、SHA、SSHAでchangeitという文字列の暗号化をする方法を示しています。
# slappasswd -h {MD5} -s changeit
# slappasswd -h {SHA} -s changeit
# slappasswd -h {SSHA} -s changeit
slapaddを実行することにより、オフラインでのデータ追加ができます。データは次の通りで、suffix_entry.ldifへ保存しておきます。
#root dn: dc=localhost,dc=localdomain dc: localhost objectClass: dcObject objectClass: organizationalUnit ou: localhost dot localdomain organization # person organizational unit dn: ou=people,dc=localhost,dc=localdomain ou: people objectClass: organizationalUnit
追加は次のコマンドで行います。データベースの設定をしていないので警告がでています。
# slapadd -b 'dc=localhost,dc=localdomain' < suffix_entry.ldif bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2) Expect poor performance for suffix dc=localhost,dc=localdomain. # chown -R ldap:ldap /var/lib/ldap/
追加したデータの確認は下記の通りです。データベースの設定をしていないので警告がでています。
# slapcat -b 'dc=localhost,dc=localdomain' bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2) Expect poor performance for suffix dc=localhost,dc=localdomain. dn: dc=localhost,dc=localdomain dc: localhost objectClass: dcObject objectClass: organizationalUnit ou: localhost dot localdomain organization structuralObjectClass: organizationalUnit entryUUID: 9e205cd2-83e6-102a-952b-d718202c6772 creatorsName: cn=Manager,dc=localhost,dc=localdomain modifiersName: cn=Manager,dc=localhost,dc=localdomain createTimestamp: 20060530051221Z modifyTimestamp: 20060530051221Z entryCSN: 20060530051221Z#000000#00#000000 dn: ou=people,dc=localhost,dc=localdomain ou: people objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 9e332dc6-83e6-102a-952c-d718202c6772 creatorsName: cn=Manager,dc=localhost,dc=localdomain modifiersName: cn=Manager,dc=localhost,dc=localdomain createTimestamp: 20060530051221Z modifyTimestamp: 20060530051221Z entryCSN: 20060530051221Z#000001#00#000000
次にユーザを追加しました。ここではパスワードを暗号化していませんが、「slappasswd -h {SHA} -s changeit」のようにして暗号化したパスワードをuserPasswordへ指定することもできます。
# hiro dn: uid=hiro,ou=people,dc=localhost,dc=localdomain objectClass:inetOrgPerson cn: hiro sn: yuki uid: hiro userPassword: vf3pai # akira dn: uid=akira,ou=people,dc=localhost,dc=localdomain objectClass:inetOrgPerson cn: akira sn: yuki uid: akira userPassword: vf4evo
ldap関係のサービスポートは下記の通りです。lokkitなどで必要なポートを開けてからクライアントからアクセスするようにします。
# cat /etc/services | grep ldap ldap 389/tcp ldap 389/udp ldaps 636/tcp # LDAP over SSL ldaps 636/udp # LDAP over SSL www-ldap-gw 1760/tcp # www-ldap-gw www-ldap-gw 1760/udp # www-ldap-gw ldap-admin 3407/tcp # LDAP admin server port ldap-admin 3407/udp # LDAP admin server port
OpenLDAPの起動と停止には /etc/rc.d/init.d/ldap を使います。
# /etc/rc.d/init.d/ldap start # /etc/rc.d/init.d/ldap stop
LDAP Browser/Editorなどいろいろとあります。ここまでの設定できちんと動作しているか、LDAPクライアントを使って動作確認しておきましょう。
次のように指定してConnectすると、anonymousで接続します。
Host: 192.168.0.1 Base Dn: dc=localhost,dc=localdomain
オプションで、SSLをチェックするとldapsでアクセスしますし、anonymousのチェックを外すと、ユーザ単位でアクセスができます。User Infoへは、次のような値を設定します。パスワードは暗号化される前のuserPasswordの値を指定すればいいです。
User Dn: uid=hiro,ou=people,dc=localhost,dc=localdomain Password: vf3pai
管理者としてアクセスするには次のようにすれば良いでしょう。
User Dn: cn=Manager,dc=localhost,dc=localdomain Password: changeit
/etc/httpd/conf/httpd.conf で認証の設定を追加します。Apache2.2ではmod_authnz_ldapモジュールを使います。認証段階ではBASIC認証を指定し、その際にLDAPを使うようにするために、AuthBasicProviderでldapを指定しています。また、入力された値と比較するためにLDAPから検索する属性をAuthLDAPURLで指定します。この場合はuidを検索して、一致したuidから対応するdnを取得し、そのdnが持つuserPassword属性の値と入力されたパスワードの値を使って認証が行われます。今回の承認段階では、認証が行われた人はだれでもこのURIへアクセスしてもよいので、require vaild-userとして、AuthLDAPAuthoritativeをoffにしておきます。もっと高度な承認をすることもできるので、その場合はマニュアルを参考にして設定しましょう。
<Location /secret>
# 認証
AuthType Basic
AuthBasicProvider ldap
AuthName "Secret"
AuthLDAPURL ldap://localhost/ou=people,dc=localhost,dc=localdomain?uid
# 承認
require valid-user
AuthzLDAPAuthoritative off
</Location>
ちなみにApache2.0の場合は次のように設定するらしいです。
<Location /secret> AuthType Basic AuthName "Secret" AuthLDAPURL ldap://localhost/dc=localhost,dc=localdomain?uid require valid-user </Location>
アクセス制御リストを指定して、anonymousでLDAPへアクセスした場合は、パスワードが見えないようにします。ただし、認証時にはanonymousでアクセスしてくるので、その場合には使えるように設定をします。本人であることが認証できたら、表示して編集できるようにしています。もちろん管理者も編集できるようにしておきます。「 /etc/openldap/slapd.conf 」へ次を追加してLDAPを再起動しましょう。これで、パスワードが他の人には見えなくなるはずです。
access to attrs=userPassword
by self write
by dn="cn=Manager,dc=localhost,dc=localdomain" write
by anonymous auth
by * none
access to *
by dn="cn=Manager,dc=localhost,dc=localdomain" write
by self write
by * read
Fedora Core 5 では /etc/pki/ に証明書関係のファイルは配置されるようです。ここでは、OpenSSLによるサーバ証明書の発行の手順をまとめてみました。
コマンドを実行して，サーバ証明書署名要求(csr.pem)と秘密鍵(privkey.pem)を作成します。
# openssl req -new -out csr.pem
作成にあたっては下記の項目について決めておく必要があります。いくつかは省略可能なのでそのままエンターキーを押下することにします。
開発で利用する場合には、秘密鍵(privkey.pem)から，パスフレーズを削除した秘密鍵(server.key)が欲しいこともあるでしょう。その場合は次のようにします。どちらのファイルも秘密鍵のファイルとして使うことができます。
# openssl rsa -in privkey.pem \
-out /etc/pki/tls/private/server.key
自己認証局（プライベートCA）を構築するには、次のようなコマンドを実行します。最初に作成するファイル名を指定するプロンプトがでますが、指定しないのならそのままエンターキーを押下します。デフォルトではカレントディレクトリにファイルはできあがります。「/etc/pki/CA」などへ作成してもいいでしょう。
# /etc/pki/tls/misc/CA -newca
構築にあたっては下記の項目について決めておく必要があります。いくつかは省略可能なのでそのままエンターキーを押下することにします。CAの構築前にデフォルト設定値を変更したい場合は/etc/pki/tls/openssl.cnfを編集します。たとえば、有効期間を30日に指定するには「 default_days = 30 」のようにします。
自己認証局を構築するとサーバ証明書署名要求(csr.pem)から、サーバ証明書を作成することができます。ただし、ここでは自己認証局を使って署名をするため、自己署名証明書になります。
# openssl ca -out /etc/pki/tls/certs/server.crt \
-infiles csr.pem
作成したサーバ証明書のフィンガープリントは次のコマンドで表示することができます。
# openssl x509 -fingerprint -noout \
-in /etc/pki/tls/certs/server.crt
Grails 0.1 がでているようです。
会社における教育というものを考えてみたときに、できるだけコストを抑えるためにはどうするのがよいだろうか? 必要性が高い教育については教育費を会社がもってでも行なうべきなのだろうが、一般教養に近いものについては各自の努力で身につけてもらいたいということがあるだろう。ここで、一般教養とそれ以外はどこで線引きができるのか、という問題はあるのだが、たとえば社内システムの使用方法は明らかに会社独自の話なので一般教養ではない。しかし社内で使用するメーラについては、自社以外の会社でもメーラを使えることはひとつの技能として認められることなので一般教養と考えてもいいだろう。
こういう視点で大雑把でもいいのでシステムを分類して、教育コストを含めた上でのシステム運用コストを計算してみるとおもしろそうである。データをとってみたわけではないが、社内で独自のシステムを動かすよりも、普及しているシステムを動かした方が有利ではないだろうか。ちょっと飛躍するがインターネットの普及により独自のLANで動作するグループウェアというのは、より汎用的なWebベースのものになったりインターネットメーラへ置き換わっているあたりをみても、一般教養としてWebブラウザやインターネットメーラの使い方を知っている人が多くなって、教育コストを抑えることができることが１つの要因ではないかと考えられる。
ここで重要なのは、「いかにして普及しつつあるシステムを会社の教育コストを抑えつつ導入するか」である。たとえば、社員自身があるシステムを有効に使えると社内での自分の競争力が高くなる、ということを自覚できるような環境にした上で、普及しつつあるシステムを導入すれば会社の教育コストは抑えることができるはずである。そのコストは社員自身が払ってくれるはずなのだ。例として、英会話を考えてみてもわかりやすいのではないだろうか。英会話ができることに価値を見いだしている人は、自分でお金を払ってでも英会話教室へ通っている。社員自身が投資に見合う価値があると思うことに対しては、それにかかるコストを厭わないのだ。
完全に普及しているシステムについては、意識しなくても使用するメリットは何かを解説するものは世の中に汎濫しているのでいいのだが、難しいのは「普及しつつあるシステム」とか「普及しているが社内での有効な利用方法がわからないシステム」である。Wiki, Blog, 掲示板, Instant Messenger, Skype, ITS/BTS など色々とあるわけだが、社員がそれらを使うメリットを認識できないと、せっかく用意したシステムも使われないまま放置されてしまうことになる。社員の責任だけではない。社内で使用するのに適していない方法で導入をすると使われないのも仕方がないということになるので、導入をリードする側でもそのメリットをわかりやすく説明をしたり、適切な分野で利用するように枠組みを決める必要があるだろう。
これまでの個人的な経験からすると、共同作業をネットワーク上で行なうにあたって誰もが利用しているものというのは、電子メールだけである。掲示板は多数の参加者がいないとうまくいかない。Wikiは編集する人が偏ってしまって共同作業になりにくい。ITS/BTSは開発者はみんな使うが他の分野への適用はよくわからない。その他は、使うメリットはあるのだが、社内システムというレベルでの導入はまだなかなかできない、という感じである。
こういったあたり、ちょっと研究をしてみたい気分だ。
サーバ管理担当の皆さんのおかげで、ブログが再開できる状態になりました。多謝。
茶樹茸（ちゃじゅたけ）がいいらしい。かならず火を通してたべるのがいいらしい。とりすぎはいけないらしい。