プチフリ解決に管理外メモリ利用
SSD(RealSSD C300の256GB)を購入。いきなり書き込みできない素子が発生するというトラブルに見舞われるも、交換されたSSDは順調(少なくとも今のところは)
しかし、それもつかの間プチフリーズに見舞われる。
解決策として、キャッシュを32bitOS(Windows 7 Professional)で管理できてない約1GBを使うことを想定する。
1GBと少ないので他のサイトに従ってみたが効率悪く感じたので次のようにした。
その備忘録
- RAMディスクソフトはGavotte Ramdiskを使う。
- OS管理外の1GBをFixed DiskとしてJドライブに割り当て。
- このソフトは他の人が詳しく説明しているので説明割愛。
- できればBuffaloやIOが提供しているRAMディスクソフト使いたかった(日本ビイキのため)が、それぞれのメーカー製品を購入していないと制限(管理外使用不可や256MB限定)される。
当環境では「キャッシュを割り当てられません。ファンクションが間違ってます」と表示されるため、仕方なく仮想メモリに割り当てた。
Fixed Diskにした事で仮想メモリにRAMを割り当てることができる。16-1024MBを割り当て。他は無効にした。これだと不測の事態が発生したためSSD(Cドライブ)も仮想メモリとして使用
- tmpフォルダの設定 →変更せず
- SystemのTempフォルダ->変更しないほうがよいだろう。なぜなら、WindowsUpdateの用に再起動後に自動設定するためのファイルが保存されると思われ、RAMでは消えてしまう
- ユーザのTempフォルダ。
J:\USERPROFILE\AppData\Local\Temp
RoundCube設定メモ
RoundCubeというWebMailソフトは有用そう。Gmailと同等の機能を実装できそうだけど、設定が面倒。バージョンアップ毎に設定をしないといけないとなると時間がかかるけど利用者は高々20数名...費用対効果があ、あわないような....
設定に有益そうなサイトが見つかったのでメモしておく
Postfix+LDAPでPAM経由でユーザ情報が取得できなかった
当サーバ(Debian 6.0)にてOpenLDAPにユーザ情報を記載し、PAM経由でSambaやWeb,Mailなどの認証をしている。
先日のldapの設定変更でmailが正しく取得できなくなった。設定を何度見直しても原因は分からなかったが、原因はpostfix-ldapパッケージを削除するとうまく動いたのでどうやらこのパッケージが邪魔をしていたようである。
問題を理解するため、ミドルウェア間の連携を考えてみた
postfix <> saslauthed <> pamとどうやらユーザ情報をやり取りするようである。
問題切り分け方法として、
①PAM認証を試す方法は、当サーバならsambaやweb認証に用いているので、そこで問題ないか否かで判断した
②次にsaslauthedが正しく動いているかは/usr/sbin/testauthed -u ユーザ名 -p パスワードで試すのが良いかと。
③当動かない理由もpostfixに限定できたのだが、postfix-ldapパッケージが邪魔するとは思ってなかった(なんで今まで動いてたんだ??)。
なんにせよ、やっと動いた。。。。一日つぶれた。もう、サーバ触りたくない。
参考:
http://futuremix.org/2009/11/postfix-smtp_auth-pam
現導入パッケージ(メール関連)
・ii postfix 2.7.1-1 High-performance mail transport agent
・ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstraction library
・ii libsasl2-modules 2.1.23.dfsg1-7 Cyrus SASL - pluggable authentication modules
・ii php-auth-sasl 1.0.4-1 Abstraction of various SASL mechanism responses
・ii sasl2-bin 2.1.23.dfsg1-7 Cyrus SASL - administration programs for SASL users database
■ SASLの設定
・/etc/default/saslauthed は"Start=yes"に変更。"MECHANISM="pam""のままでOK
・/usr/lib/sasl2/smtpd.confはPLAIN Loginなら
pwcheck_method: saslauthed
mech_list:plain login
と書き換え、/etc/postfix/sasl/smtpd.confにコピーorSリンク。
・testsaslauthedでテストして問題なければOK
重複するOpenLDAPの設定ファイルの管理簡略化の備忘録
我々のDebian GNU/Linux 6.0サーバでOpenLDAPを使ってssh、メール、ファイル共有、Web認証と様々な認証を可能にしています。
LDAPの設定を変えてしまった時にLDAPが動かなくなった。その時LDAPの設定ファイルを認識できていなかったので下記のように取りまとめる事とした。
- 問題:同じ設定で良いLDAP設定ファイルがあり、管理を簡易化したい。
- 解決策:1つのLDAP設定ファイルにシンボリックリンクを張る
- 実現のための条件:同一の接続方法で、同一baseDNを使う場合(たぶん)。
- ベースファイル:/etc/ldap.secret
※Sambaではsmbldap-toolsを使ってLDAPへ認証するため、上記設定ファイルは認証に影響しません。
補足:
- 認証キャッシュするnscdというのがあるそうな。おそらくネットワーク経由だと効果ありそうだが、内は単一サーバ内で認証するので効果はあまり無いんじゃないかと。
Rでbrowser()が正しく働かない時の対処方法
問題:
関数の最後のreturn(data.frame(...))の後に、なぜか(...)に記述されていないlist変数へのアクセスエラーで停止した。
対応:
最初はreturn()の前行にbrowser()を設置した。この箇所でブラウジングモードに入ってnキーを押すと1行ずつ実行を確認できる。nキーで確認しながら実行すると、return直後にエラーで停止したのでreturn()内の問題と考えられるが、(...)内に無いlist変数へのアクセスで停止するのか理解できなかった。
対応策として、関数内のreturnの前と後と、関数実行後の次行にbrowser()を記述して、nキーで1行ずつ実行してみると別関数にて上記のアクセスエラーが起こっていることが分かった。
注意は上記のようにbrowser()を配置しても、cキーでは関数の次行のbrowser()にてブラウジングモードに移行せず(していないように見える)ので大分悩んだ。
解決策:
関数の入出力が絡んだ箇所では、browser()コマンド1つをnキーで正しく確認できると思わずに、問題箇所に複数browser()を配置し、nキーにて動作を確認するのがよい(だろう)。