SyntaxHighlighter

2015年1月8日木曜日

ldapのユーザーでgdmからログインできない

こんにちは。

ldapサーバーとクライアントの設定をして、sshからログインとかCUIでログインしたらすんなりとうまく行ったから、やったー!とおもってたらGUI(gdm)のダイアログからはログインできなくて悩んだ。

ログインするとき、ユーザー名、パスワードを書いてボタンを押すと画面が黒くなって、マウスカーソルが考え中になって、しばらく(十数秒くらいか?)するとまたログインダイアログの表示になってしまう。

どこでエラーが起きているのかわからず、試行錯誤の連続。

Webで情報拾ったら、gdmを再起動してOKになったみたいな記述があったので、再起動したがうまく行かず。

クライアントのマシンを再起動するといいよみたいな記述があったので、再起動してログインしたら…入れた!

でもその後いろいろやってたらまたGUIログインができなくなった。


でいろいろしらべたのですが、結局、ホームディレクトリが何かしらの悪さをしていた模様。一度ログインしているユーザーのホームディレクトリを丸ごと削除したらサクサクとログインできるようになった。(ちなみに当方の環境では、nfsで共有しているディレクトリの中にホームディレクトリがある状態。またauthconfigの設定で、ホームディレクトリがない場合は作成する設定にしている)

以前、ldapじゃない環境で作ったホームディレクトリをコピーしてきたらダメだったのかなあ…?


なかなか同じような状況になる方は少ないかもしれませんが、何かの参考になれば幸いです。


2014年12月3日水曜日

LDAP pwdExpireWarningが効かないんだけど(解決)

こんにちは。

OpenLDAPを使ってRHELとCentOS上でlinuxユーザーアカウントを管理しようと奮闘しています。

Web上のいろいろな記事をみて、ログインなんかはできるようになったんだけど、pwdExpireWarning が効かない!

pwdMaxAge=15552000
pwdExpireWarning=15551900

とか設定して、ログインしてもなーんも表示されん。


未だわからず。だれかぽすけて。 

できた!

/etc/pam_ldap.conf の中の次の1行をコメントインするだけでOKでした。

pam_lookup_policy yes 
 
 
 
後日…
 
やっぱりできてない! いや、開発環境では上記の方法でできたんだけど、テスト環境で同じ設定してもできなかった。
 
ううううう(*`ω´*) 
 
 
更に後日… 
次の書込みを見つけた!(英語)
http://www.openldap.org/lists/openldap-technical/201303/msg00196.html 

なんか、policyを定義する順番をuserを定義する順番より先にすれば良いみたい。もしくは、1回パスワード変更すればOKみたい。

実際、パスワード変更して100秒くらい経ったあとログインしたら、

Your LDAP password will expire in 179 days.
Last login: Thu Jan  8 18:19:05 2015 from h1-bs-ps1.hogehoge.jp

みたいに表示されたよ!いぇい!

# pam_lookup_policy yesは必要なのかな…?必要なんだろうなきっと。うん。

ちなみにgdmのログイン時も残りの有効期限が表示されるようになった。パスワード入れてエンターしたあと、1~2秒の間だけだけど(´ー`)

2014年11月26日水曜日

「mv: failed to preserve ownership for `ファイルパス': 無効な引数です」にハマったよー

こんばんは。

nfsの話です。

CentOS6.5同士でnfsによるファイル共有を行ってたときは全然問題なかったのですが、CentOS6.3同士でnfsファイル共有し、rwでno_root_squashなディレクトリに mv かけたら、

mv: failed to preserve ownership for `ファイルパス': 無効な>引数です

みたいなエラーがでて何じゃこりゃ、と。

見たところmv自体はできているのですが ownershipがpreserveできてないってことで、もともとはroot:rootのものだったふぁいるがnobody:nobodyになってました。

ググり倒したところ… nfsのバージョンによってポリシーが異なるとかなんとか。

んー、香ばしい。

ということで、クライアントからマウントするときに次のようにしたら、クライアント側からもroot:rootで見えるようになりました。

mount -t nfs 192.168.10.10:/src/dir /mnt/pos -o vers=3

明示的にnfsのversion 3としてマウントする、と。

ふう。

2014年11月21日金曜日

CentOS6のタイムゾーン変更するよー

時刻見たら、あー9時間前だ… ってことでタイムゾーンがずれてるな、と。

UTC → JSTにするなら下記でOK。下記はコピーしてるけどSymbolic Linkでも良いね!

[Fri Nov 21 02:05:54]root@devcent:[~] $ date
Fri Nov 21 02:06:35 UTC 2014
[Fri Nov 21 02:06:35]root@devcent:[~] $ cp /etc/localtime /etc/localtime.org
[Fri Nov 21 02:07:07]root@devcent:[~] $ cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
cp: overwrite `/etc/localtime'? y
[Fri Nov 21 11:07:33]root@devcent:[~] $ date
Fri Nov 21 11:07:43 JST 2014

2014年10月27日月曜日

Linuxのbashスクリプト内で使ったsedの正規表現でハマったよ

こんにちは。

Linuxでbashスクリプトを作っております。

変数の文字列(ファイルパス)を加工するにあたり、置換にsedを使うわけですが、ちょっとハマりましたのでφ(..)メモメモ。


マッチした部分を指し示すカッコ()は\でエスケープせねばならぬ。

直前の文字1つ以上を示すプラス+は\でエスケープせねばならぬ。


特にカッコの方でハマった。

2014年9月25日木曜日

tarコマンドの末尾についてるハイフン

おはようございます。

他人が書いたbashスクリプトを見てたら、

tar -cf ${tarFile} -T -

っていうコマンド発行してるところがあって、浅学な私は「なんだこのゴミ…」って思ってしまったわけです。

でも実際動いてるコードだからなぁと思って調べてみると、「アーカイブするデータを標準入力から受け取る」っていうオプションだったのです。

なんでこんな仕様にしたんだろ… 理由があるのかも知れないけど。

2014年9月4日木曜日

DBD driver has not implemented the AutoCommit attribute at なんじゃこりゃー

こんばんは。

CentOS + mysql + perlの環境です。

3000000件以上のレコードをdeleteする処理がありまして、トランザクション使って削除しようとしてました。まだ開発段階のコードです。

トランザクション開始して、delete、delete、delete deleteと4回めのdelete処理(1回めは1件、2回めは30件くらい、3回めは3000件くらい、4回めは3000000件くらい)を行ったら4回めでエラーになった。

DBD driver has not implemented the AutoCommit attribute at ほげほげ

と表示されている。なんじゃこれ?とググるが有用な日本語記事は1件しかない。英語も引っかかるけど、なんかピンと来ない感じ。

同時刻の/var/lib/mysql/hostname.errのログを見ると、mysqlが落ちて、mysql_safeが再起動したみたいな。

140904 18:05:27 mysqld_safe Number of processes running now: 0
140904 18:05:27 mysqld_safe mysqld restarted
2014-09-04 18:05:30 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-09-04 18:05:31 21675 [Note] Plugin 'FEDERATED' is disabled.
2014-09-04 18:05:31 21675 [Note] InnoDB: The InnoDB memory heap is disabled
2014-09-04 18:05:31 21675 [Note] InnoDB: Mutexes and rw_locks use InnoDB's own implementation
2014-09-04 18:05:31 21675 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-09-04 18:05:31 21675 [Note] InnoDB: Using Linux native AIO
2014-09-04 18:05:31 21675 [Note] InnoDB: Not using CPU crc32 instructions
2014-09-04 18:05:31 21675 [Note] InnoDB: Initializing buffer pool, size = 128.0M

2014-09-04 18:05:31 21675 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-09-04 18:05:31 21675 [Note] InnoDB: Using Linux native AIO
2014-09-04 18:05:31 21675 [Note] InnoDB: Not using CPU crc32 instructions
2014-09-04 18:05:31 21675 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-09-04 18:05:31 21675 [Note] InnoDB: Completed initialization of buffer pool
2014-09-04 18:05:32 21675 [Note] InnoDB: Highest supported file format is Barracuda.
2014-09-04 18:05:35 21675 [Note] InnoDB: The log sequence numbers 23781084774 and 23781084774 in ibdata files do not match the log sequence number 24879295225 in the ib_logfiles!
2014-09-04 18:05:35 21675 [Note] InnoDB: Database was not shutdown normally!
2014-09-04 18:05:35 21675 [Note] InnoDB: Starting crash recovery.
2014-09-04 18:05:35 21675 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-09-04 18:05:38 21675 [Note] InnoDB: Restoring possible half-written data pages
2014-09-04 18:05:38 21675 [Note] InnoDB: from the doublewrite buffer...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 3033 row operations to undo
InnoDB: Trx id counter is 3525120
2014-09-04 18:05:41 21675 [Note] InnoDB: 128 rollback segment(s) are active.
InnoDB: Starting in background the rollback of uncommitted transactions
2014-09-04 18:05:41 8e985b70  InnoDB: Rolling back trx with id 3524767, 3033 rows to undo

InnoDB: Progress in percents: 12014-09-04 18:05:41 21675 [Note] InnoDB: Waiting for purge to start
2014-09-04 18:05:41 21675 [Note] InnoDB: 5.6.14 started; log sequence number 24879295225
 22014-09-04 18:05:42 21675 [Note] Server hostname (bind-address): '*'; port: 3306
2014-09-04 18:05:42 21675 [Note] IPv6 is available.
2014-09-04 18:05:42 21675 [Note]   - '::' resolves to '::';
2014-09-04 18:05:42 21675 [Note] Server socket created on IP: '::'.
 32014-09-04 18:05:42 21675 [Note] Event Scheduler: Loaded 0 events
2014-09-04 18:05:43 21675 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.14'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)
 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002014-09-04 18:06:22 21675 [Note] InnoDB: Rollback of trx with id 3524767 completed
2014-09-04 18:06:22 8e985b70  InnoDB: Rollback of non-prepared transactions completed
2014-09-04 18:14:34 21675 [Warning] IP address '10.0.2.2' could not be resolved: Name or service not known
2014-09-04 18:17:18 21675 [Note] /usr/sbin/mysqld: Normal shutdown


んー、、、 まぁmysqldがリスタートされて、トランザクションはRollbackされたんね。うん。

その後、同じことをやってもエラーはおきず。順調にコミットされる。

mysqldが腐ってた、ということなんだろうけど、なんで腐ったんじゃか。今はわかりません。