screen 縦分割

ubuntu

Ubuntuに入ってるscreenはデフォルトで縦分割が効いてるので良いね。

  • C-a |        縦分割
  • C-a tab    分割したWindow間の移動
  • C-a X       Forcusがある側のウインドウを閉じる
  • C-a c        新規ウインドウ作成
  • C-a num    ウインドウ番号を指定して移動
  • C-a n        ウインドウを順番に移動


俺、これ以外のコマンド使ってない。



何はともあれ、ワイドな画面では縦分割が俄然使いやすくてよいですね。


f:id:norizo3:20090928225546p:image

Ubuntu 9.04 LDAPクライアント設定

ubuntu ldap linux

LDPAサーバの設定

IPアドレス 192.168.0.1
suffix dc=example,dc=com
rootdn cn=Manager,dc=example,dc=com
rootpw secret

この設定でクライアントとは別にLDAPサーバが構築されているとして

LDAPクライアント設定

Ubuntuに以下のパッケージをインストール

$ sudo apt-get install libnss-ldap libpam-ldap ldap-utils

インストール中にサーバの情報入力を求めてくるのでIPアドレス、suffix、rootdn、rootpwを適宜入力する。


/etc/pam.d/common-*は問題なく変更されていたが、/etc/ldap.confと/etc/nsswitch.confは手で一部修正を加えた。
最終的に各ファイルが以下のように変更されていればOK。



/etc/ldap.conf

base dc=example,dc=com
uri ldap://192.168.0.1
ldap_version 3
rootbinddn cn=Manager,dc=example,dc=com
pam_password md5


/etc/ldap.secret

secret


/etc/nsswitch.conf

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis


/etc/pam.d/common-account

account	[success=2 new_authtok_reqd=done default=ignore]	pam_unix.so 
account	[success=1 default=ignore]	pam_ldap.so 
account	requisite			pam_deny.so
account	required			pam_permit.so


/etc/pam.d/common-auth

auth	[success=2 default=ignore]	pam_unix.so nullok_secure
auth	[success=1 default=ignore]	pam_ldap.so use_first_pass
auth	requisite			pam_deny.so
auth	required			pam_permit.so


/etc/pam.d/common-password

password	[success=2 default=ignore]	pam_unix.so obscure sha512
password	[success=1 user_unknown=ignore default=die]	pam_ldap.so use_authtok try_first_pass
password	requisite			pam_deny.so
password	required			pam_permit.so


/etc/pam.d/common-session

session	[default=1]       pam_permit.so
session	requisite         pam_deny.so
session	required          pam_permit.so
session	required          pam_unix.so 
session	optional          pam_ldap.so 
session	optional          pam_ck_connector.so nox11

Ubuntu 9.04 インストール(後の設定)メモ

linux ubuntu

vmwareにUbuntuを入れなおしたので設定メモ。
インストール自体は基本的にはウィザードに従ってなので割愛。
簡易設定は使わずに、HDの割当やMEM割当、ホスト名などを調整。
パッケージは全部アップデート。
ruby1.9とmysqlが使える所まで。Webサーバは必要になったら入れる。今はいらん。

VMware Toolsインストール

  1. 「仮想マシン」→「VMware Tools のインストール」
  2. ツール実行
mkdir vmware
cd vmware
cp /media/cdrom0/VMwareTools-7.9.6-173382.tar.gz .
tar zxvf VMwareTools-7.9.6-173382.tar.gz
cd vmware-tools-distrib/
sudo ./vmware-install.pl

vmware-config-tools.plも流れで実行する。
途中で解像度の設定が無かったので、「システム」→「設定」→「ディスプレイ」から「1280x800」に変更。


ネットワーク設定

「システム」→「設定」→「ネットワークの接続」から固定IPに変更。
とりあえずNetworkManagerでも今の所問題ないのでしばらく様子みる。


opensshインストール

sudo apt-get install openssh-server

パスワード認証禁止。
公開鍵をMacからコピって、~/.ssh/authorized_keysとして保存。


Vimインストール

デフォルトのvimはコンパクト版のvim-tinyなのでvim-fullをインストール。
.vimrcはMacから持って来て調整。

sudo apt-get install vim-full

screenは入ってるので

.screenrcだけコピっとく。


zshインストール

sudo apt-get install zsh

chshしとく。
.zshrcコピって、微調整。


ruby1.9インストール

zlib入れとく。

sudo apt-get install zlib1g-dev
wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p243.tar.gz
tar zxvf ruby-1.9.1-p243.tar.gz
cd ruby-1.9.1-p243
./configure --enable-shared --enable-pthread
make
sudo make install

vim-rubyインストール

sudo gem install ruby-mode
vim-ruby-install.rb

MySQLインストール

sudo apt-get install mysql-server-5.1 libmysqlclient16-dev

5.1指定でインストールしないと5.0入れようとしてた。
libmysqlclient16-dev入れとかないと、mysql/ruby入れるときにエラーになる。


/etc/mysql/my.cnfに追加

[mysqld]
skip-character-set-client-handshake
default-character-set = utf8

[mysql]
default-character-set = utf8

[mysqldump]
default-character-set = utf8

skip-character-set-client-handshakeは文字化け対策。まだいるんかな？後で確認。


MySQL/Rubyインストール

sudo gem install mysql

libmysqlclient16-dev忘れてなければすんなり入る。


とりあえず今ここ。

スキーマ

lpic ldap
スキーマ

データベース構造の定義。

LDAPスキーマ

  • 格納されるデータの形態が決定付けられる。
  • オブジェクトクラスの定義と、属性の定義からなる。
  • 基本的なスキーマは、あらかじめスキーマファイルとして提供されている。

基本スキーマファイル

core.schema OpenLDAPのコアスキーマ(必須)
cosine.schema CosineとInternet X.500スキーマ(RFC1274)
inetorgperson.schema 人に関した定義に関するスキーマ(RFC2798)
corba.schema CORBAスキーマ(RFC2714)
nis.schema NIDに関するスキーマ(RFC2307)
java.schema JAVAに関するスキーマ(RFC2713)
openldap.schema OpenLDAP Projectの実験用スキーマ
misc.schema その他の実験的なスキーマ
ppolicy.schema パスワードポリシーの為の開発中のスキーマ
スキーマファイルの利用

slapd.confファイルのincludeディレクティブを利用して読み込むスキーマファイルを指定する。

include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema

オブジェクトクラスと属性

  • 各スキーマ要素は、全世界的に一意のOID(Object Identifier: オブジェクト識別子)によって管理されている。
  • オブジェクトクラスはobjectclassにより定義される。
  • オブジェクトクラスには、ABSTRACT・STRUCTURAL・AUXILIARYの3つの構造型がある。
  • オブジェクトクラスにはMUST属性(必須属性)、MAY属性(許可属性)が指定できる。
  • 属性はattributetypeにより定義される。
  • 属性の検索方法の定義を照合規則といい、EQUALITY・ORDERING・SUBSTRの3つがある。
  • 属性のデータ型はSYNTAXに、OIDを使って指定する。

OIDの概要

  • 全世界的に一意で無ければならない。
  • IANA(Internet Assigned Numbers Authority)によって管理されている。

オブジェクトクラスの定義

objectclassディレクティブを利用

objectclass ( 2.5.6.6 NAME 'person'     ←　OIDと名前の定義：　OID NAME objectclass名
  DESC 'RFC2256: a person'              ←　オブジェクトクラスの説明
  SUP top STRUCTURAL                    ←　オブジェクトクラスの形式
  MUST ( sn $ cn )　　　　　　　　　　　←　必須属性
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )    ←　許可属性
  • SUPには基底オブジェクトクラスを指定する。指定したオブジェクトクラスの機能が、継承されて利用される。personはtopというクラスを継承している。
オブジェクトクラスの構造型
ABSTTACT(抽象型) 他のオブジェクトクラスの基底クラスとして使われるオブジェクトクラス
STRUCTUAL(構造型) ディレクトリ構造を作る事ができるオブジェクトクラス。各エントリには必ず1つの構造型オブジェクトクラスが必要。
AUXILIARY(補助型) 構造型と組み合わせる事で属性を追加する事が出来るオブジェクトクラス。単独でディレクトリ構造を形成する事はできない。

属性の定義

attributetypeディレクティブを利用。

attributetype ( 2.5.4.5 NAME 'serialNumber'   　　　←　OIDと属性の名前の定義
  DESC 'RFC2256: serial number of the entity'       ←　属性の説明
  EQUALITY caseIgnoreMatch　　　　　　　　　　　　　←　照合規則の設定
  SUBSTR caseIgnoreSubstringsMatch                  ←　照合規則の設定
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )　　　　←　属性のデータ型の設定
照合規則
  • 属性の検索をどのような方法で行うかについての定義。
  • 1つの属性には、必ず1つ以上の照合規則が定義されてなければならない。


照合規則の型

EQUALITY(同値照合) 文字列や値の全体に対して照合を行う。
ORDERING(順序照合) 値の大小や文字列の順序を使って照合を行う。
SUBSTR(部分文字列照合) 文字列の一部分に対して照合を行う。


EQUALITY型の照合規則の例

booleanMatch 真偽(0/1)として照合
caseIgnoreMatch 英大小文字を区別せず、スペースを無視して照合。
caseExactMatch 英大小文字を区別し、スペースを無視して照合。
distinguishedNameMatch 識別名(DN)として照合。
intergerMatch 整数として照合。
numbericStringMatch 数値として照合。
octetStringMatch オクテット文字列として照合。
objectidentiferMatch OIDとして照合。


ORDERING型の照合規則の例

caseIgnoreOrderingMatch 英大小文字を区別せず、スペースを無視して照合。
caseExactOrderingMatch 英大小文字を区別し、スペースを無視して照合。
intergerOrderingMatch 整数として照合。
numericStringOrderingMatch 数値として照合。
octetStringOrderingMatch オクテット文字列として照合。


SUBSTR型の照合規則の例

caseIgnoreSubstringsMatch 英大小文字を区別せず、スペースを無視して照合。
caseExactSubstringsMatch 英大小文字を区別し、スペースを無視して照合。
numericStringSubstringsMatch 数値として照合。
octetStringSubstringsMatch オクテット文字列として照合。
SYNTAX
  • SYNTAXには属性がどのようなデータ型をとるか指定する。
  • 指定にはOID(属性のOIDとは別物)を利用する。


SYNTAXに指定できるデータ型のOID

1.3.6.1.4.1.1466.155.121.1.7 真偽値
1.3.6.1.4.1.1466.155.121.1.12 DN形式の文字列
1.3.6.1.4.1.1466.155.121.1.15 Unicode(UTF-8)文字列
1.3.6.1.4.1.1466.155.121.1.26 ASCII文字列
1.3.6.1.4.1.1466.155.121.1.27 整数値
1.3.6.1.4.1.1466.155.121.1.34 DNよびUID
1.3.6.1.4.1.1466.155.121.1.36 数値文字列
1.3.6.1.4.1.1466.155.121.1.38 OID形式の文字列
1.3.6.1.4.1.1466.155.121.1.40 任意のオクテット文字列
1.3.6.1.4.1.1466.155.121.1.44 表示可能な文字列
1.3.6.1.4.1.1466.155.121.1.50 電話番号

拡張スキーマ

  • 既存のスキーマで定義できないスキーマ要素がある場合、独自のスキーマを定義する事ができる。
  • OIDが他と重複しないよう注意する必要がある。
  • 既存のスキーマファイルを編集するのではなく、新しいスキーマファイルを作成する。
  • slapd.confの適合性を確認する為には、slaptestコマンド利用する。

slaptest

構文
slaptest [オプション]

オプション

-d 数 デバッグレベルを指定する。
-f ファイル名 slapd.confの代わりに利用する設定ファイルを指定する。
-u dry-runモードで検査を行う(データベースがオープンできなくても設定が正しければエラーを返さない)。
-v 冗長モードで実行する。

ディレクトリ設計

lpic ldap

管理したい情報の性質や組織の形態などにより、管理に適切なDITの構造は異なってくる。いったん作成したディレクトリの構造を改変するのは大変な労力がかかる為、基本構造の設計は慎重に行う。

DIT構造の設計

どのような情報をどのように管理するか検討し、適切なツリーを構築する。

ディレクトリ設計の原則
  • ディレクトリの上位から下位に向けて分類は細分化される。
  • アクセス管理を行う際、同一の権限を持つエントリが同一階層に存在する事が望ましい。
  • DNが一意になるようディレクトリを構築する。
深い階層を持つDITのメリット・デメリット
  • メリット
    • 詳細な検索ベースが得られるため、検索効率が上がる場合がある。
    • 階層をグループとして扱うことが出来る。
  • デメリット
    • 個別のエントリのDNが長くなる
    • ディレクトリのメンテナンスに手間がかかる。
浅い階層を持つDITのメリット・デメリット
  • メリット
    • 個別のエントリが短くなる。
    • ディレクトリのメンテナンスにかかる時間を軽減できる。
  • デメリット
    • 頻繁にエントリを更新する際の更新速度が低下する。
コンテナ

エントリを分類する目的のみに作られるエントリの事。


エントリの設計

エントリのオブジェクトクラス・属性の検討事項
  • エントリが持つ属性が属性値としてすべて表現できるかどうか。
  • エントリに必ず入れなければならない情報は何か、入る可能性のある情報は何か。
  • その情報はどのような値とて表現されるか(文字列/数値/画像データなど)
  • 検索の際にどのように利用されるものか(完全一致か、属性の有無のみか)


たいていの場合、あらかじめ用意されているスキーマファイルを利用すれば、一般的なデータは表現できる為、これらのスキーマファイルの内容を検討して、扱うべきデータの表現方法を検討する。

サービスクラス(Class of Service: CoS)

クライアントアプリケーションがエントリを取り出すときに計算された属性を動的に生成し、勤務地や電話番号などといった、複数のユーザが共通に利用する属性値の管理を集中化する事ができる機能。