2012年1月29日日曜日

LDAPオブジェクトの識別名

オブジェクトの識別名は常に使うのだが、ついつい語彙(意味)を正確に覚えていないので明記する。
■LDAP サービスで使用される代表的な属性
属性名 意味(タイプ)
dc ドメイン名の要素(Domain Component)
o 会社名、組織名(Organization)
ou 部署名(Organization Unit)
uid ユーザー ID(UserID)
cn 氏名(Common Name)
sn 姓(Surname)
givenName
mail メールアドレス

■認証サーバーを構築する場合に使用される属性
属性名 意味(タイプ)
shadowLastChange 1970/01/01 から最後にパスワードを変更した日までの日数
shadowMax ユーザーに新しいパスワードを保持させる日数
shadowMin ユーザーが同じパスワードを使用できる日数
shadowWarning が近づいたことを、何日前からユーザーに通知するかを指定
loginshell ログインシェル
uidNumber ユーザー ID
gidNumber グループ ID
homeDirectory ユーザーのホームディレクトリ
userPassword ユーザーのパスワード

2012年1月14日土曜日

Linux(CentOS5.7)でGUIログインできなくなった。

Sambaの最新版のパッケージを作成してインストールを実行しているとファイルの競合が発生し、競合するファイルに依存するパッケージを削除していたら、デスクトップ環境に影響のパッケージを削除することになり、GUIログインすらできなくなってしまった。(T-T)(泣)

init: Id "x" respawning too fast: disabled for 5 minutes
上記のように表示されて、GUIログインされなくなってしまった。
とりあえず、Sambaの設定は後回しにして環境の復旧に務めることにした。

2012年1月5日木曜日

rpmパッケージのデータベース情報削除

パッケージのインストールやアンインストールでエラーが発生して処理が途中で終了してしまうと、実際にはアンインストールされているのにパッケージデータベース情報は削除されずに残っていたりして整合性が取れなくなってしまう場合がある。今回まさにその通りの事がは発生したのでメモしておく。

今回は、clamavの調子が悪いので再インストールしようとしていたところ clamd だけが実際にはアンインストールされているがパッケージデータベース情報は残ったままとなってしまった。

# rpm -e --justdb パッケージ名
  ↓(今回の件では下記のように)
# rpm -e --justdb clamd
上記で、パッケージデータベース情報が削除された。

上記とは逆の現象(パッケージがインストールされたのにパッケージデータベース情報に登録されていない)の場合は下記のコマンドになる。

# rpm -i --justdb パッケージ名

おまけ...重複してインストールされたパッケージの検索


[hoge@hoge01 ~]# package-cleanup -d
Setting up yum
[hoge@hoge01 ~]# 

もし、重複してインストールされたパッケージがあったら rpm -e --justdb パッケージ名 で古いほうを削除する。

2012年1月2日月曜日

Oracle10g OEMコンソールが起動しない

WindowsXpのOracle10g OEMコンソールが昨年末から起動しなくなった。

今までだと、サイトでググッて確認した oemapp.bat のメモリ割り当て設定を変更して対応できた。
if "%ORACLE_OEM_JAVAMX%" == "" set ORACLE_OEM_JAVAMX=-mx384m
REMif "%ORACLE_OEM_JAVAMX%" == "" set ORACLE_OEM_JAVAMX=-mx128m
上記は、以前にメモリを128mから384mに変更して起動できるようになったが、今回はこの値を大きくしても起動せず、なんど768mにしたら一度起動ができたが、その後起動ができない...

これは、ちょっとおかしいよなぁ~
こんなにメモリを必要なんて考えれない。(ーー;)

仕方ないので、調査を行う事にした。
タスクマネージャを起動してからOEMコンソールを起動してメモリ使用量の推移を監視してみる。

上記の先頭行を参照のこと。
なんと、メモリ使用量がどんどん増加して384MBどころか700MB以上になっていく。そして、oemapp.bat のORACLE_OEM_JAVAMXの設定値を超えるとエラーが発生する。
一度は、設定値を768mで起動しただが、その後は768mを越えていきエラーになる。こんなのはおかしい。

そこで、オラクルのクライアントフォルダの中でOEMコンソール起動時に書き込みが行なわれるログもしくは設定ファイル的はものはないかとフォルダを検索したところ、 dbappprf.properties というファイルが更新されているので、確認するとなんと260MBものファイルになっている。
オラクルの拡張子が .properties のファイルは設定ファイル系であったと記憶しているので、これはおかしい。
実際にファイルの内容を確認してみると、案の定...
よって、上記のファイル(dbappprf.properties)を削除してからOEMコンソールを起動したところ、無事に起動することができました。

また、oemapp.batORACLE_OEM_JAVAMXの値も当初の128mに戻して起動したが問題なく起動した。

要するに、オラクルクライアント9i から 11g まで複数バージョンインストールしてあるので、インストール時のPATHの設定状況悪い時に、違うバージョンのOEM(たぶん9i)に dbappprf.properties に異なるエンコード書き込まれて設定内容を読み込む際にトラブルを起こしているのではないかと思います。

なんとか無事に起動するようになり安心した次第です。