Factory-AJ Blog: any

2018年10月

	1	2	3	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

2006年2月24日

FTPレスポンスの向上

cobaltサーバーにFTPするとき、コネクトしてからファイル名が表示されるのに非常に時間がかかっていた。
これはこういうものだろうと思っていたが解決策が見つかった。

/etc/proftpd.conf に以下の記述を追加。

IdentLookups off

　　DefaultRoot　/ wheel
　　　DefaultRoot 　 / admin-users
　　　DefaultRoot　 ~/../../.. site-adm
　　　DefaultRoot　 ~ !site-adm
　　　AllowOverwrite　on
　　　IdentLookups off
　　　DisplayLogin　ftphelp

BlueQuartzの場合、xinetd 経由で起動しているので下記の場所も修正。

/etc/xinetd.d/proftpd で

service ftp
{
　　socket_type = stream
　　wait = no
　　user = root
　　server = /usr/sbin/in.proftpd
　　log_on_success += HOST PID
　　log_on_failure += HOST
　　nice = 10
　　disable = no
　　instances = 100
}

log_on_success += HOST PID と
log_on_failure += HOST　の2行を修正する。
これで劇的にレスポンスは向上。

投稿者 AJ : 10:59 【トラックバック (0)】

2005年9月 9日

Cobaltサーバーでのquotaのズレ

( root にて )
/sbin/quotacheck -ga
/sbin/quotacheck -ua
を実行

投稿者 AJ : 10:42 【トラックバック (0)】

2005年7月20日

Cobalt-.htaccessによるパスワード制限

Cobalt(RaQ3,RaQ4,RaQ550)でパスワード認証の付いたページを作りたいと思った場合、手っ取り早く行うときには保護したい Web ディレクトリ以下に、.htaccess という名前で（ファイル名先頭の . (ドット) を忘れずに）下記のような内容のファイルを作ればOK。このサーバに登録されたユーザのうち、require で指定されたユーザ名だけが、このページを見ることが出来るようになる。この時のパスワードは、このサーバのパスワードと同じものになる。

AuthName "Limited page for member."
AuthType Basic

require user sample

（上記の例なら「sample」というユーザーがログインできる）

ただ上記例であれば、サーバーに登録されていないユーザーはログインできない。
登録ユーザ以外の人に、ユーザ名とパスワードで限定されたページを提供したい場合は、.htaccess の名前を下記のよう変更。
（※1　AuthPAM_Enabled offに注意。RaQ550 ではこの行は不要。）
（※2　AuthUserFileのパスは/home/sites/homeとか/home/sites/site1とかより/home/sites/www.hogehoge.comというようにサイト名で書く方がよい）

AuthUserFile /home/sites/home/users/foo/password1.dat
AuthGroupFile /dev/null
AuthName "Limited page for member."
AuthType Basic
AuthPAM_Enabled off

require user sample

AuthUserFile に指定されたファイルには、限定するユーザ名とパスワードの列を登録する。
ここに登録されたユーザ名とパスワードの組み合わせを知っている人だけが、アクセス出来るようになる。
例えば上の例だと、passwrod1.dat ファイルの中身は、

sample:PfyJ0.mjA.LQI
Yasu:bSm6OpAYUIIao

というようになっている。（試しにユーザが二つ登録されている。そのうち上の例の .htaccess では sample ユーザだけがアクセス可能になる。）

もし、上記例で passwrod1.dat ファイルに登録しているユーザーすべてをログインさせたい場合は

require user sample

を

require valid-user

という具合にrequireの記述を変更すればOK。

このファイルを作るツールはいろいろあり、Googleなどで「htpasswd」と検索してやれば何件かヒットするはず。
たとえば

http://www1.neweb.ne.jp/user_manual/htaccess/htpasswd.html

http://www.futomi.com/lecture/htaccess/htpasswd.html

http://www.rescue.ne.jp/cgi/htpasswd/

が有名どころである。

あと少し高度だが、とりあえず Cobalt に telnet login できる人なら、htpasswd コマンドがある。

最初に password1.dat という名前のパスワードファイルを、sample という名前のユーザだけで作成する場合は、

% htpasswd -c password1.dat sample

などとする。既にパスワードファイルに登録されているユーザのパスワードを変える場合、または既存のファイルにユーザを追加する場合は、-c オプションを抜いて、

% htpasswd password1.dat sample

のようにする。

※1　RaQ550 ではデフォルトでは PAM 認証モジュールが入っていないため、 AuthPAM_Enabled on/off の記述があるとエラーが出る。（httpd.confでコメントアウトされている）

※2　サーバーが壊れリストアしたときに必ず同じsite番号で登録されるとは限らないため・・・

投稿者 AJ : 15:19 【トラックバック (0)】

2005年7月19日

Cobalt-Logのrotateについて

Cobaltのログは一定容量になれば整理対象となるのだが、これが非常に見にくい。サイトの容量を仮に100MBと設定したのであれば[mail],[ftp],[http]のログは10MBになれば*.1.gzという具合に1世代だけ圧縮され整理される。

これでは障害時の追跡や管理を考えると、非常に不便である。
で、rotateを日単位で圧縮していけば、後々の追跡も非常に楽ということで設定を変更してみる。

このrotate設定は/etc/logrotate.d/の中にある各サイトのファイルによって行われる。例えばsite1であればsite1というファイルhomeに関するものであればhomeというファイルといった具合である。

で、このファイルを下記のように変更してやれば、過去30日まで、daily にて分割／圧縮される。（ただしWeb管理画面でのダウンロード対象にはならず、 FTPにて転送する事となる。)

--------/ /etc/logrotate.d/home 改造例 /----
/home/sites/home/logs/mail.log {
daily
missingok
compress
rotate 30
}

/home/sites/home/logs/ftp.log {
daily
missingok
compress
rotate 30
}

/home/sites/home/logs/web.log {
daily
missingok
compress
rotate 30
}

又、下記ファイルを直接同様の方法にて Backup しておいた方が、障害を過去に遡って追跡する際に何かと便利である。

(アクセスログが１日にて更新されてしまう程のアクセス量ならば、それなりの負荷となっているはず・・・
過去に遡って追跡する場合、時系列にて追跡できた方が良い事もある)

/var/log/messages
/var/log/maillog
/var/log/httpd/access
/var/log/httpd/error

上記ファイル整理設定を調整する場合には
/etc/logrotate.d/syslog
/etc/logrotate.d/apache
等を修正する事となる

投稿者 AJ : 22:17 【トラックバック (0)】

Cobalt-メーリングリストの返信先変

Cobaltサーバーのメーリングリストはmajordomoが使用されているのだがデフォルトだと送信者にしか返信されない設定になっている。

これを、メーリングリストに返信できるようにconfigを変更してみる。

/usr/local/majordomo/(mlnamedomain)/lists/(mlname).config の2か所を変更すると、一応?使えるようになるかと思う。

<237行目付近・変更前>
message_headers << END
Resent-From: $LIST
Resent-Cc: recipient list not shown: ;

END

<変更後>
message_headers << END
END
#Resent-From: $LIST
#Resent-Cc: recipient list not shown: ;

END

<284行目付近・変更前>
reply_to =

<変更後>
reply_to = mlname@domain(メーリングリストのアドレス)

こんな感じでどうだろう・・・

投稿者 AJ : 22:05

2005年7月14日

Cobalt-Logキャッシュのクリア

> #cat /var/log/kernel
> kernel: Unable to load interpreter /lib/ld-linux.so.2
> Jan 11 06:51:13 hostname last message repeated 4 times

cronが走る時間帯から確認していると、parseReport.plがメモリを大量消費していることが判明。
(過去ログ検索で同様の内容があった...)
これが動いている間に、メモリがつきるとLCDパネル表示がなくなり、commandもsegmentation faultでうけつけないということになる。

動き出す前のtop
[root root]#top
3:53am up 74 days, 23:37, 1 user, load average: 0.09, 0.05, 0.01
60 processes: 59 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.5% user, 0.7% system, 0.0% nice, 98.6% idle
Mem: 517188K av, 336736K used, 180452K free, 163772K shrd, 77508K buff
Swap: 131532K av, 12312K used, 119220K free 183916K cached

これから徐々にメモリを食っていき、残り2Mあたりをさまよいつつ、回復
[root root]#top
6:22am up 75 days, 2:05, 1 user, load average: 1.41, 1.33, 1.28
62 processes: 59 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 91.3% user, 8.4% system, 0.1% nice, 0.0% idle
Mem: 517188K av, 461248K used, 55940K free, 163336K shrd, 119908K buff
Swap: 131532K av, 6220K used, 125312K free 260900K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
13353 root 5 0 9288 9288 1376 S 0 88.7 1.7 0:34 split_logs
13565 root 15 0 2940 2940 1156 R 0 5.9 0.5 0:00 parseReport.pl

その後analogが動き出し一気にメモリ消費。そのparseReport.plも動き出しswapまでもが窒息寸前に...
[root root]#top
6:48am up 75 days, 2:31, 1 user, load average: 2.21, 2.41, 1.97
64 processes: 61 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 98.6% user, 1.3% system, 0.0% nice, 0.0% idle
Mem: 517188K av, 513660K used, 3528K free, 21468K shrd, 10648K buff
Swap: 131532K av, 126580K used, 4952K free 13848K cached

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
15505 root 11 0 538M 433M 488 R 0 98.2 85.8 5:33 parseReport.pl

この時間帯のプロセスは
[root root]#ps ax (関係ありそうなもののみ)
14076 ? SW 0:00 [sh]
14077 ? S 3:43 perl -w /usr/local/sbin/split_logs web
15504 ? SW 0:00 [sh]
15505 ? R 10:57 perl /usr/admserv/cgi-bin/.cobalt/webUsage/parseRepor
t.pl -t web -s main -o /usr/admserv/html/.cobalt/report/web/

このプロセスの段階でどうやらサービスが不安定になる模様。
ML-過去ログよりparseReport.plを検索し、次のように行う。
[root root]#cd /home/.cobalt/report
[root root]du -sm *
13 ftp.cache
13 ftp.cache.new
12 ftp.stats
5 mail.cache
5 mail.cache.new
3 mail.stats
0 stats.tab
213 web.cache
213 web.cache.new
84 web.stats
となっている。(あとは各siteのdatファイルが存在)

あとは、上記ファイル(〜.cache)を削除し、空のファイルを作成。

すると、kernelからのerrorもなくなり、logrotateも3時間から40分くらいで終了するようになる。
logrotate終了後の結果
[root report]# du -sm *
0 ftp.cache
0 ftp.cache.new
0 ftp.stats
0 mail.cache
0 mail.cache.new
0 mail.stats
0 web.cache
3 web.cache.new
2 web.stats

投稿者 AJ : 19:44 【トラックバック (0)】