内容とは若干異なります。文中の【表】、【リスト】のリンクはJavaScriptを利用して別ウィンドウを開いています。JavaScriptが無効の場合は下記のリンクをご利用ください。2.2系と3.0系のバージョン選択基準Windowsネットワークへの参加SambaはUNIX/LinuxマシンとWindowsネットワークとの接続性を実現するため、Windowsのファイルサーバー/プリントサーバー機能を実装したオープンソースソフトウェアだ。Tridgell氏によって開発され、その後、ドメインコントローラやディレクトリサービスを利用した大規模ユーザー管理機能など、Windowsドメイン環境を置き換えるツールとしての地位を築いてきた。そのSambaが、約2年ぶりに3.0へとメジャーバージョンアップされたので、まずは変更点を中心に紹介する。3.0だが、すべてのユーザーにとって最適な選択であるとは限らない。3.0の必要性について確認しておく。XPマシンを導入する場合はバージョンアップが必要となった。ところが今回は、以前のバージョンでも致命的な不具合は存在しない。3.0でも問題ない)。それぞれのケースをまとめてみた。3.0を利用するメリットは、LDAPとの連携強化や大規模システムへの対応など、企業ユーザーがWindowsドメインコントローラの代替として利用することにある。逆に、機能が増えたことで使い方が難しくなったうえ、日本語利用における品質が低下しており、現時点では個人ユーザーへ勧めにくい状況といえる。3.0も徐々に品質が向上し、日本語ドキュメントが充実してくれば、万人に勧められる状態になるだろう。3.0の国際化および品質向上に取り組んでいる。3.0の新機能の詳細について紹介しよう。Directory(以下AD)ドメインにも参加できるが、その際はNTLM(ハッシュパスワードによる)認証となる。2000相当のKerberos(チケット方式)認証が利用可能となる。セキュリティを重視するユーザーにとっては有用な機能だ。残念ながらADサーバーとしての機能は備わっていない。Controller)にした場合は、Kerberos認証は利用できなくなる。9xと同じシフトJISである。このため、一部のWindowsアプリケーションでは互換性の問題が発生していた。9xのDOSプロンプトで問題が発生する【実行例1】。4.0では発生しない。NT/2000/2003と同じUCS-2(Unicode)へと変更された。2.2で問題となっていた通信時に使用される文字コードによるトラブル(注1)も解決するだろう。このような通信経路のUnicode化は、個人ユーザーにとってそれほど大きなメリットではない。Unicodeと既存文字コードとの変換テーブルの問題など、注意すべき点が増えている。ネットワークアプライアンス社のNetAppFilerには、Windowsドメインへ参加してユーザー管理機能をWindowsサーバーに任せる機能が備わっている。2.2がドメインサーバーになっている場合、NetAppFilerはドメインへ参加できなかった。2.2ではユーザー管理データベースとしてsmbpasswd、TDB、LDAPなどが利用できたが、LDAP機能を有効にしてコンパイルすると、LDAP以外のユーザー管理機構が使用できなくなった。そのため、ユーザー管理データベースを切り分けるには、それぞれの環境を構築しなければならない。smbpasswdとしておけば良い。これによって、従来どおり/etc/samba/smbpasswd(と/etc/passswd)を参照する。詳細については後述するが、Sambaサーバーをドメインコントローラにして、WindowsのADドメインのような大規模なユーザー管理機構が必要ならば、ldapsam機能を利用したほうが良いだろう。backendパラメータはユーザー管理データベース(パスワードの格納先)を指定するものであって、認証方法を指定するものではない」という点だ。ユーザー管理データベースにLDAPを利用したとしても、WindowsクライアントとSambaサーバーの認証については、(LDAPプロトコルによる)LDAP認証を使用できない。どのような場合でも、Sambaサーバーの認証は(SMBプロトコルの)NTLM認証となる(AD連携を使用したときのみKerberos認証)。SambaサーバーとLDAPサーバー間の接続は、LDAP管理者の権限でのみ行われ、各ユーザーの認証は、SambaサーバーがLDAP管理者の権限でLDAPデータを読み出した後、ユーザーのNTLM認証を行う仕組みになっている。backendパラメータの推奨値は次のようになる。Name)の2種類が存在する。Mangling)が実装されている。2.2では変換アルゴリズムが単純、かつ必要なときに生成されるため、SFNが永続的でなく、一部のプログラムで問題が発生した。methodパラメータのデフォルトは新しいアルゴリズム「hash2」となった(注2)。hash2アルゴリズムは現時点で日本語が考慮されていないので、従来の変換アルゴリズム「hash」を指定したほうが良いだろう。3.0アルファ版のロードマップには「生成したSFNをデータベースに記録し、永続的に保存する」という記述があったが、現時点では実現されていない。netコマンドのサポートWindowsに付属する管理用のnetコマンドが、Sambaでも標準サポートされた。ような操作が可能となった。vampire」コマンドでユーザー情報やグループ情報をSambaサーバー側へ複製する。NTドメインを簡単に移行できるわけだ。4.0ドメインとの信頼関係についても、netコマンドを使うことで簡単に実現できるようになった。ID:相対識別子)とLinuxのUID/GIDのマッピングはサーバーごとに行われるため、全マシンにおいて同一ユーザーが同じIDになるとは限らなかった。3.0では、UIDのマッピングをLDAPに保存し、すべてのマシンで同一のIDが振られるようになった。この機能を使う場合は、LDAPサーバーが必要となる。listパラメータを指定してユーザーやグループへのアクセス制御が可能だった。List)を設定できるようになった。これらの設定はLinuxから実行できないが、情報はsmb.confではなく、TDBの中に保存される。個々のファイルやディレクトリに関するACLは、従来どおりファイルシステム(XFSなど)がサポートしていれば利用可能だ。3.0ではnetコマンドを実行することでWindowsと同等のグローバルグループが利用できるようになった。グループマッピング機能もサポートされたため、UNIX/LinuxのグループをWindowsのグループに対応可能だ。ようなものが用意されている。この機能によってSambaのグループ管理は高機能化されたが、逆にグループ管理の手順は大変面倒になった。2.2ではグループ管理をOSに任せていたので、groupaddコマンドだけでOKだったが、Samba3.0ではgroupaddコマンドに加えて、netコマンドも実行する必要がある。LDAPSAM機能を使った場合のグループ管理は複雑で、初心者には敷居の高いものとなっている。3.0用のsmbldap-toolsはグループ管理に対応していないので、早急な改善が望まれる。3.0では文字コードの変換方式についても変更されている。パラメータで文字コードを指定し、コード変換は外部のiconvライブラリを使用するようになった【図】。2.2で解決した日本語の問題が再発するようになった。iconvライブラリでは、CAP(マッキントッシュとの共有用)やHEX(16進表記)が未サポートである。3.0で日本語が正常に扱えるかどうかは、iconvの機能と品質に依存してしまう。現在、WebDAVなどが抱えているものと同じ問題であり、「〜」や機種依存文字が利用できない。3.0で日本語が利用できないので注意してほしい。3.0だが、日本語への対応という面では若干手間が増えている。大規模向けの新機能がメインであるため、個人ユーザーが導入および移行するには悩むところだろう。2以降の具体的な導入および設定作業を参考にして、環境に応じたシステムを構築してほしい。3.0で日本語を利用するには、iconvライブラリが必要となる。したがって、事前にiconvライブラリを導入しておかなければならない。3.0系の最新版はバージョン3.0.0である。ソース以外に、RPM系Linuxディストリビューション用バイナリパッケージも用意されているので、初心者はこちらを利用したほうが簡単に導入できるだろう。RPM系のパッケージを利用したインストール方法から紹介する。3.0.0では内部構造が大幅に変更されたため、導入時に注意すべき点が存在する。CP932への対応DOSやWindows(95/98/Me系)で使われる文字コードは一般にシフトJISといわれるが、正確にはCP932(注1)というマイクロソフト独自のものである。Linuxディストリビューションで標準的に使用されるglibcはCP932に対応していないため、日本語の変換において一部問題が発生する。同様に、FreeBSDや商用UNIXなどでも、CP932の変換に対応したライブラリを持っていない。3.0で正しく日本語を扱えないわけだ(注2)。これを解決するには、次の2つの方法が考えられる。glibcに対してCP932対応パッチを適用(注3)CP932対応パッチを適用したlibiconvの導入どちらを選択しても良いが、以下の違いに留意してほしい。glibcにCP932対応パッチを適用する作業は複雑であるglibcにCP932対応パッチを適用すると、Linuxディストリビューション側に備わっている自動アップデート機能が利用できなくなる最近のLinuxディストリビューションはlibiconvを同梱していないこれらを考慮すると、最近のLinuxディストリビューションおよびUNIX系であれば、CP932対応パッチを適用したlibiconvを導入すると良いだろう。glibcにCP932対応パッチを適用する場合はSambaの公式サイトにあるRPMパッケージが利用できるが、libiconvにパッチを当てる際はconfigureスクリプト実行時にlibiconvの指定が必要となるため、この処理を行ったRPMパッケージを利用しなければならない。Pageの略で、国別の文字セットを表したものである。10.3は、CP932の変換用ライブラリを持っているようだ。V2.1の場合、CP932をサポートしたGLIBCを提供している。2.1用のCP932対応glibcパッケージとCP932対応libiconvパッケージが用意されている。2003年12月号付録CD-ROMにも収録しているので適宜利用してほしい。ftp://ftp.samba.gr.jp/pub/samba-jp/samba-3.0-ja/上記のLinuxディストリビューション以外を使用している場合は、【実行例1】のようにしてSRPMからRPMパッケージを作成してほしい。これによって、デフォルトでは/usr/src/redhat/RPMS/i386以下にRPMパッケージが生成されるので、それをインストールする。前述のとおり、CP932対応libiconvパッケージを導入した場合は、libiconv対応のRPMパッケージを利用する必要がある。該当するLinuxディストリビューション用のRPMパッケージがないときは、先ほどと同じようにSRPMから作成してほしい【実行例2】。あとは、これを利用してインストールするだけである。samba-3.0.0-3iconv.src.rpmソースからの導入作業RPMパッケージが利用できない場合は、ソースを入手してコンパイル・インストールする。libiconvの導入ソースからコンパイルするときは、まずlibiconvのソースアーカイブとCP932パッチを入手する。http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.8.tar.gzhttp://www2d.biglobe.ne.jp/~msyk/software/libiconv-patch.htmllibiconvのソースアーカイブを適当なディレクトリで展開し、パッチを適用する。install」を行う。-v」を実行しておく必要がある。インストール後は、iconvコマンドによってCP932に対応しているかどうかを確認しておこう。入手して、適当なディレクトリで展開する。古いバージョンのtarコマンドでは、「j」オプションではなく「I」オプションを指定する。続いて、samba-3.0.0/sourceディレクトリに移動して、configureスクリプトを実行する。ようなオプションが指定可能だが、詳細については「--help」オプションで表示される内容を参照してほしい。install」で完了だ。nsswitch/libnss_wins.soを実行後、libnss_wins.soを/lib以下へコピーしておこう。/lib設定ファイルの準備ソースを利用して導入した場合、Sambaの実行ファイルなどはインストールされるが、設定ファイルがインストールされない。Sambaを動作させるには、これらのファイルの準備、およびシステム側の設定ファイルの変更が必要となる。ここでは設定ファイルの内容の詳細については扱わない。ソースディレクトリのexamples以下やpackaging以下にはサンプルファイルなどが存在するので、これらを参考にすると良いだろう。smb.confSambaの設定ファイルであり、これがないとSambaは起動しない。Samba3.0.0で日本語を利用する場合は、必ず以下の3行を指定してほしい。CP9321行目の指定は、CP932をサポートしたlibiconvやglibcを導入していないと利用できない(Smabaが起動しない)ので注意しよう。2003年12月号付録CD-ROMの/Speciall/samba-3.0-ja以下に収録したので、参考にしてほしい。設定ファイルの置き場所は、configureスクリプトの「--with-configdir=<dir>」で指定したディレクトリとなる(デフォルトは/usr/local/samba/lib)。smbpasswd、passdb.tdbSambaユーザー用のパスワードを格納するファイル。pdbeditコマンドの実行によって自動的に作成される。LDAPを利用する場合を含めて、ファイル作成作業は必要ないが、格納されるディレクトリだけは必ず作成しておこう。SWAT用の設定Sambaの設定/管理をWebブラウザ経由で行うため、専用WebインターフェイスSWATが用意されている。経由で利用するが、前者の場合、/etc/servicesに次の行を追加しておく。SWATでの認証用としては、各システムにあわせた設定が必要となる。ような/etc/pam.d/sambaファイルを作成する。これは、ソースディレクトリのpackaging/RedHat以下にあるsamba.pamdをコピーしても良いだろう。/etc/logrotate.d/sambaSambaのログを定期的にローテーションさせるには、ログローテーション用の設定ファイルを用意する。ような/etc/logrotate.d/sambaファイルを作成しよう。これは、ソースディレクトリのpackaging/RedHat以下にあるsamba.logをコピーしても良い。起動スクリプトの準備システム起動時にSambaを自動実行させるには、システムにあわせた起動用スクリプトを用意する。ような/etc/rc.d/init/smbファイル(注5)を作成しよう。ような起動スクリプトも用意すること。最近のFHSに準拠したLinuxディストリビューションでは、/etc/init.d/smbとなる。9でも、/etc/init.dはシンボリックリンクとして存在する。起動スクリプトが用意できたら、それらがシステム起動時に読み込まれるように設定する。onと実行することで、現在のランレベルにおいてシステム起動時にSambaが自動実行されるようになる。3.0が起動したはずだ。WebブラウザからSambaサーバーの901/tcpへアクセスすることで(Webmin経由でSWATを利用する場合はWebminへアクセス)、設定/管理用の画面が表示されるだろう【図】。【図】SWATでの設定(図は動作状況の画面)開発者へのフィードバックが安定したSambaを生む筆者がLinux関連の仕事をしているため、Linux中心の解説となってしまったが、Sambaの開発チーム自体もLinux中心で開発を進めている。したがって、動作検証などもLinuxを重点的に行っているのも事実だ。それ以外のUNIX系OSで問題が発生した場合は、積極的に開発者へフィードバックしてほしい。そのような行動は、Sambaの安定性の向上へとつながっていくはずだ。最初に、Sambaを用いたスタンドアロンサーバーの構築方法について解説する。スタンドアロンサーバーとは別のホストと連携することなく単独で利用するもので、Windowsでいうワークグループサーバーのことである。この場合、ユーザーやグループの管理が重要なポイントとなる。基に注意点などを解説する。3.0の推奨設定ではスタンドアロンサーバー構築時のユーザー管理データベースとしてTDBを利用する。2.2で一般的に利用していたsmbpasswdと比較して、性能や拡張性の面で優れている。backendパラメータを指定する。2.2におけるユーザーの追加作業は、システム側のuseraddコマンドを実行した後、Samba側のsmbpasswdコマンドを実行した。netコマンドが提供されている。Sambaユーザーodagiriを作成する場合は次のように実行する。backendパラメータとして「tdbsam」、「smbpasswd」、「ldamsam」のいずれかを利用した場合にユーザーを管理できるが、事前にシステム側でもユーザーを追加しておく必要がある。odagiriと実行し、管理対象がSambaでもWindowsでもユーザー管理可能だが、ネットワーク経由でアクセスするためのユーザー/パスワードが必要だ。pdbeditコマンドとnetコマンドの大きな違いは、実行する場所である。2003にも対応している。scriptパラメータを指定しておけば、システム側でのuseraddコマンドやgroupaddコマンドの実行を省略できる。netコマンドを実行する際は、Samba側に管理者ユーザー(rootやAdministrator)を登録しておき、そのユーザーとパスワードを用いることになる。したがって、通常はpdbeditコマンドを利用したほうが良いだろう。Samba用パスワードの設定/変更は、smbpasswdコマンドで行う。2.2ではグループ管理機能を実装していなかったため、システム側のgroupaddコマンドでグループの追加を行えば良かった。3.0からはグループ管理機能を実装したため、groupaddコマンドに加えてnetコマンドでグループ管理を行わなければならない。SambaでWindowsドメイン環境を構築する場合、グローバルグループとローカルグループを区別できるようになったことで、管理上もこれらを使い分ける必要が出てきた。type=domainのように実行する。Sambaのグループ管理に先だって、次のグループを作成しておく必要がある。Usersこれらのグループは、netコマンド(注1)を利用して登録しておこう【実行例1】。UNIX/Linux側のグループ名wheel、nobody、smbusersは、それぞれの環境に応じてカスタマイズしてほしい。user」と同様にネットワーク経由でアクセスするためのユーザー/パスワードが必要になる。scriptパラメータの設定が必要だ。3.0ではWindowsからのユーザー/グループ管理が実現された。これによって、非常に管理しやすくなるだろう。Serverに付属するユーザーマネージャ(USRMGR.EXE)で行う【図1】。2000のサービスパックに含まれているので(「/x」オプション指定で展開できる)、これを利用すると良いだろう。ユーザーマネージャを利用するには、【リスト1】のようにsmb.confで次のパラメータを指定しておく必要がある。続いて、既存のADドメインに対して、Sambaサーバーをメンバサーバーとして登録してみよう。2003が動作していることを前提とする。Directoryのユーザーとコンピュータを管理する」から管理ツールを起動して、コンピュータをドメインに追加する【図2】。2000以前のコンピュータとして割り当てる」をチェックしてほしい【図3】。Sambaマシン上からnetコマンドでドメインへ参加する。administrator%<管理者パスワード>後は、Winbindデーモンを起動すれば完了だ。3.0.0ではSWATからWinbindが起動できるようになったので、これを利用すると良い。backendパラメータを指定しよう。2000-3000そのほか、LDAP関連のパラメータについては、以降の解説を参考にしてほしい。yes」と指定するだけでもOKだ。複数のSambaサーバーを用いた場合、個別のサーバーごとにユーザー登録しなければならず、BDCも構築できない。backend=ldapsam」としたほうが良いだろう。3.0.0+LDAPサーバーの環境構築手順について解説する。3.0.0をLDAPサーバーと連携させる場合、注意すべき点がある。LDAPスキーマを作成するための環境が用意されていないため、手順を間違えると正常に動作しないのだ(注2)。この状況は、後述するsmbldap-toolsが改良されれば解決するだろう。3.0+LDAPへ移行するほうが簡単である。OpenLDAPの導入Sambaのldapsam機能はOpenLDAPをベースに開発されているが、OracleやNovellなどのLDAPサーバーにも対応しており、スキーマさえ登録すれば問題なく利用可能だ。2.0.27による構築方法を解説する。Hat系Linuxディストリビューションの場合、RPMパッケージが用意されているので、これらを利用すると簡単だ。OpenLDAP具体的には、【実行例2】のようにインストールすれば良い。nss_ldap*.i386.rpmソースの利用RPMパッケージを利用できないOSについては、ソースを利用することになる。OpenLDAPのソースアーカイブは、次のサイトなどから入手可能だ。http://www.openldap.org/2003年10月10日現在、RPMパッケージの最新版は2.0系がほとんどだが、ソースの最新版は2.1.23である。ここではRPMパッケージにあわせるために2.0系を用いるが、2.1系でも問題なく動作するだろう。ソースアーカイブを入手したら、適当なディレクトリで展開する。openldap-2.0.27.tgz展開後、ソースディレクトリでconfigureスクリプトを実行するが、ここでは【実行例3】のオプションを指定した。オプションの詳細については、「--help」で出力される表示を参照してほしい。--help後は、依存関係を構築し、コンパイル、インストールすれば完了だ。--localstatedir=/var/runOpenLDAPの設定OpenLDAPを利用するには、LDAPサーバー動作用LDAPクライアント用という2種類の設定を行う必要がある。1.はLDAPデーモンを動作させるサーバーのみ行えば良く、2.はWindowsを除くすべてのUNIX/Linuxマシン(LDAPサーバーのマシン自体も含む)で行わなければならない。設定が必須なファイルは、/etc/openldap/slapd.confだけである。ここではSambaでドメイン環境を構築する際の関連事項のみ解説するので、OpenLDAPの詳細な設定方法については以下のWebページなどを参照してほしい。示したslapd.confのサンプルファイルを見てほしい。これをベースとして、次にあげる4つのパラメータに関連する作業を行う。includeSamba用のスキーマファイルの取り込みは、includeパラメータで指定する。3.0.0のソースアーカイブに含まれるexsample/LDAP/samba.schemaファイルを/etc/openldap/schema/samba30.schemaへコピーして、slapd.confで次のように設定する。2.2のソースコードに含まれるスキーマを/etc/openldap/schema/samba22.schemaへコピーし、次の設定を追加しておこう。/etc/openldap/shema/samba22.shemasuffixベースサフィックスはsuffixパラメータで指定する。これは、最低でも1つ以上設定しなければならない。ユーザー側で自由に設定できるが、全世界でユニークになるようにDNSドメイン名と同じものを使用するのが一般的だ。Unitを意味している。これ以外に「c」(Country)や「o」(Organization)なども使われるが、ユニークであれば何を使ってもユーザーの自由である。大文字・子文字の区別はない。Name:識別名)は、rootdnパラメータで指定する。管理者などユーザー用のDNについても自由に設定可能で(ベースサフィックスを含む必要がある)、大文字・子文字の区別はない。"cn=Administrator,ou=Users,ou=naniwa,dc=unixuser,dc=jp"rootpwLDAPサーバーの管理者パスワードは、rootpwパラメータで設定する。テスト環境では平文のパスワードを指定しても良いが、実運用では暗号化したものを用いてほしい。パスワード「miracle」をMD5ハッシュする場合は、slappasswdコマンドを使用して次のように実行する。{MD5}{MD5}0SLYzLSMIRdTdundlie/5A==ここで表示されたものをrootpwで指定すれば良い。{MD5}0SLYzLSMIRdTdundlie/5A==なお、rootdnパラメータとしてLDAPに登録されているユーザーを指定し、LDAP内にパスワードが格納されている場合は、rootpwを省略できる。設定終了後、OpenLDAPデーモンを起動しよう。start無事に起動したら、システム起動時に自動実行するように設定しておく。onLDAPクライアントとしての設定LDAPクライアントとなるすべてのUNIX/Linuxマシンでは、次の4つのファイルについて設定を行う必要がある。V2.xでは、設定ツールauthconfigが提供されているので、これを利用すると良いだろう。LDAPサーバーが動作しているマシンではサーバーを127.0.0.1とし、それ以外ではLDAPサーバーのIPアドレスやホスト名を指定する【図4】。authconfigで設定後、/etc/nsswitc.confと/etc/openldap/ldap.conf、/etc/pam.d/system-authの内容が以下のように変更されるので確認しておこう。authconfigが存在しない場合は、各ファイルを手動で修正していくことになる。/etc/nsswitch.confネームサービススイッチの設定ファイル/etc/nsswitch.confでは、次のようなLDAPに関する設定が必要となる。ldap/etc/ldap.confと/etc/openldap/ldap.confnss_ldapとpam_ldapの設定ファイルである/etc/ldap.confを編集し、ユーザーの組織と検索ベースを反映させる。/etc/openldap/ldap.confはldapsearchやldapaddなどのコマンドラインツール用設定ファイルであり、これもLDAP設定に合わせて編集する必要がある。md5のような内容も追加しておこう。/etc/pam.d/system-authPAM用設定ファイル/etc/pam.d/system-authには、次のような行が追加される。Daemon)を起動しておく。onこれによって検索結果がキャッシュされるため、アクセスが高速になる(これを起動させなくてもLDAPの動作に支障はない)。SambaとLDAPを利用した環境では、ユーザー情報はすべてLDAPに格納されているので、PDC/BDCといった役割は簡単に変更可能だ。したがって、Sambaを複数台利用する場合は、1台だけPDCを設定し、それ以外はすべてBDCにすると良いだろう。SambaをPDCにするときはWINSサーバーにしたほうが良いが、その際、WindowsクライアントにおけるWINS設定の変更も忘れずに行ってほしい。そのほか、smb.confで設定すべき項目は、次のとおりである(これ以外の項目についてはSWATのドキュメントなどを参照)。backendパラメータでは「ldapsam」を指定するが、同時にLDAPサーバーのホスト名も指定する。backend=ldapsam:ldap://デフォルトは「localhost」なので、同一マシン上の設定であれば「:ldap://」の部分は省略可能だ。suffixパラメータで設定する。ここでは「dc=miraclelinux,dc=com」とするため、次のように設定した。dnパラメータで設定する。これは/etc/openldap/slapd.confでの指定と同一にしなければならない。したがって、ここでは以下のように設定した。cn=Manager,dc=miraclelinux,dc=comまた、LDAP管理者用パスワードは、smbpasswdコマンドで設定する。ような設定ファイルを用意した。最後に、Sambaを起動する。startOpenLDAPへの初期データ投入LDAPへの初期データの格納や、ユーザーやグループの管理用のツールとして、smbldap-toolsが用意されている。これはSambaのソースアーカイブに含まれるが、次のサイトで最新ソースコードやRPMパッケージが用意されているので、そちらを利用してほしい。http://samba.idealx.org/dist/必要なPerlモジュールsmbldap-toolsはPerlで記述されており、以下のPerlモジュール(注3)が必要なので、パッケージシステムなどを利用して導入してほしい。スクリプト群がインストールされる。V2.1では、これ以外にもNet_SSLeay.pm-1.25.tar.gz、Test-Simple-0.47.tar.gz、File-Temp-0.14.tar.gzが必要だった。smbldap-populate.plの実行smbldap-toolsの使用前には、まず/etc/samba/smbldap_conf.pmファイルにおいて次の行を設定しておく。getlocalsid」コマンドで取得したSID>これ以外にも必要な項目については、適宜設定しておこう。後は、smbldap-populate.plスクリプトを実行するだけで、初期化データが投入される。NT/2000/XPをドメインメンバに追加する場合は、PDC上でドメインメンバのマシンアカウントを作成する。PDC上でのマシンアカウントの作成まずは、PDC上のroot権限で、ドメイン管理用ユーザーdomainaddを作成しよう。domanadd後は、ドメインメンバのマシン分だけ以下のコマンドを実行する。<Windowsマシン名>は英数字(子文字)で15バイト以下とし、日本語は使用できない。NT/2000/XP(注4)上では、まずAdministratorとしてログオンする。コントロールパネルの「システム」のプロパティにおいて、「ネットワークID」タブの[ネットワークID]のボタンをクリックしよう。PDCで設定したdomainaddユーザーとパスワード、ドメイン名を入力する【図5】。最後に、「ドメインへようこそ」というダイアログが表示されればOKだ。3.0では必要なくなった。groupmap」コマンドが必要となるので注意しよう。Users)の登録を忘れないでほしい。odagiriと実行し、Sambaドメイン環境でグローバルグループdevを作成する場合は次のように実行する。type=domainドメインログオン設定とユーザーの追加が終了したら、Windowsクライアントをリブートし、設定したWindowsドメインへログオンする。事前にログオンスクリプトを準備しておけば、問題なく動作するはずだ。3.0.0によるケース別の構築方法を駆け足で解説した。使い方が少し難しくなったが、魅力満載の機能が増えたともいえるだろう。今後の品質向上についても期待したいところだ。3.0の目玉機能の1つは、NTドメイン環境からの移行である。3.0では、次のような環境からの移行作業が可能となっている。vampire」コマンドを使用することでSamba3.0へ移行可能だ。2.2互換モード(ldapsam_compat)も利用できる。4.0ドメイン環境をLDAPへ移行した後、Samba2.2での運用も可能となる。2.2互換モードでは各ユーザーのSIDが移行できないので、移動プロファイルが保持できなくなる。3.0のtdbsamやldapsamの環境へ移行可能だ。3.0の新しいスキーマへと移行できる。3.0においてユーザー管理データベースにsmbpasswdやtdbsamを使用していた場合、tdbsamやldapsamの環境へと移行可能だ。3.0へ移行してみよう。2.2の場合と少し異なっている。2.2では移行できなかった情報や移動プロファイルなどにも対応できる(Samba2.2互換LDAPスキーマを使用した場合は、移動プロファイルなどが移行できない)。3.0側にはXFSなどのACLをサポートしたファイルシステムが必要となる。移行方法それでは、実際に移行作業を行ってみよう。示したsmb.confをベースに解説する。netコマンドによるSIDのコピーまずは、Samba起動用の設定ファイルsmb.confを準備しよう。変更する点は、次のパラメータである。2.2互換モードを利用したい場合は、以下のパラメータも変更する。前述のとおり、これを利用することで移動プロファイルなどが移行できなくなるので注意してほしい。389Sambaを起動する前に、netコマンドで既存のSIDをSamba側へコピーする。NT側とSamba側のSIDを表示させ、内容が同じであることを確認しよう【実行例1】。続いて、SambaマシンをBDCとしてNTドメインへ参加させる。join」コマンドによって行う。Administrator%<パスワード>Sambaを起動して、正常に参加できているかを確認しよう。start確認後、smbldap-populate.plスクリプトによって初期化を行う。共有データをSamba側へコピーする場合は、Windowsクライアントからエクスプローラでドラッグ&ドロップするのが簡単だ。Samba側でACLサポートのファイルシステムを利用しており、アクセス権限もコピーしたいときは、「/O」オプション指定のXCOPYコマンドを用いること。/Cユーザー/グループ情報の移行netコマンドのvampire機能を利用して、ユーザー/グループ情報をSamba側へ移行させる。3で解説したように、SambaをPDCとして起動すれば完了だ。現状での問題点NTドメインから移行してみたところ、現状では以下のような制限が存在した。実際に移行するときは、この点に注意してほしい。日本語やシングルクォート(')を使ったユーザー/グループ、および名前の先頭が数字のユーザー/グループは移行できない(UNIX/Linux側の制限)ホームドライブとしてネットワークドライブを指定しているユーザーは移行できないマシンアカウントがou=Computersではなくou=Usersに登録される。2.2からの移行は、比較的簡単だ。ユーザー管理データベース別に紹介しよう。smbpasswdと指定すれば、smbpasswdによって継続利用できる。tdbsamの利用smbpasswdからtdbsamへ変更したい場合は、pdbeditコマンドを使用する。tdbsam:/etc/samba/passdb.tdbこれによって、/etc/smbpasswdのデータが/etc/samba/passdb.tdbへ移行される。2.2でLDAPを使ったPDCを構築している場合は、まずslapcatコマンドによってLDAPデータをLDIFファイルへエクスポートする。3.0用スキーマへ変換する。--output=<変換後のLDIFファイル>変換後のLDIFファイルを、slapaddコマンドでLDAPへ投入すれば完了だ。3.0どうしでも、ユーザー管理データベースの変更を伴う移行は可能だ。この作業は、すべてpdbeditコマンドで行う【実行例2】。3.0に対する筆者の感想としては、品質的に問題のある部分も残っており、すべての用途において移行を勧められる状況とはいい難い。現在、ミラクル・リナックスのメンバーをはじめとする日本Sambaユーザ会が鋭意努力中なので、成果に期待してほしい。3.0から(GUIで)管理する」という運用が選択できるだろう。■この資料の評価をお願いします。参考になった参考になったどちらでもないあまり参考にならなかったまったく参考にならなかったコメントがある場合は以下に記述してください。技術資料として取り上げてほしいテーマも受け付けています。