Paul Anderson

paul@geeky1.ebtech.net

v3.6, June 1998 JF Project 日本語訳

JF@linux.or.jp

この HOWTO では、意外と知られていないちょっとしたヒントやコツを紹介しています。 これを知れば、Linux はもっと便利になるはずです。 ようこそ Linux Tips HOWTO へ。これは、Linux がもっと 楽しくなる小ワザやちょっとした最適化の方法を集めた文書です。いまのところ、 ここで紹介するのはわたしが思いつく限りの tips と、旧版 Tips-HOWTO から 転載した tips です(先人の知恵は拝借すべきなのです)。お気に入りのワザや tips が あったら何でも送ってください。Tips-HOWTO の次の版で紹介します。 Paul Anderson Linux TIPS HOWTO の管理者 <panderso@ebtech.net> /etc/syslog.conf を編集して、次の行を入れます。 # Dump everything on tty8 *.* /dev/tty8 注意事項：必ず Tab を使うこと！ syslog はスペースを 嫌います..... 初心者のわたしから同じく初心者のひと向けに、HOWTO 文書の検索と表示が簡単に できる短いスクリプトを紹介します。たとえば、わたしの環境だと HOWTO 文書は /usr/doc/faq/howto/ に圧縮されて入っています。ここで、文書の ファイル名は、XXX-HOWTO.gz であり、XXX の部分はその題名 とします。わたしは、次のような "howto" というスクリプトを作成して、/usr/local/sbin に置きました。 #!/bin/sh if [ "$1" = "" ]; then ls /usr/doc/faq/howto | less else gunzip -c /usr/doc/faq/howto/$1-HOWTO.gz | less fi 引数なしでコマンドを実行すると、ディレクトリ内にある HOWTO 全部を表示します。 次に、引数としてファイル名の最初の部分(ハイフンより左側)を入力すると、 (もとの文書自体には変更を加えずに)その文書を解凍して、表示します。 たとえば、Serial-HOWTO.gz を表示する場合は、次のように 入力します。 $ howto Serial マウントされているデバイス(ディスク、CD-ROM、フロッピー...)上に充分な空き スペースがあるかどうか定期的にチェックする短いスクリプト。 空きスペースが無くなると、X 秒ごとにメッセージが表示され、満杯のデバイスが 生じるたびに 1 通のメールが届きます。 #!/bin/sh # # $Id: Tips-HOWTO.sgml,v 1.4 2001/07/21 14:58:17 senda Exp $ # # # ディスクが一時ファイルで満杯になると、コンパイル中に奇妙なメッセージが # 表示されるようになったので、これを書いて、ディスクが満杯になる前に警告 # が表示されるようにした。 # # このスクリプトで君のサーバが爆発を免れたなら、僕にお礼のメールを # 送ってちょうだい zocki@goldfish.cube.net # このスクリプトで君のサイトが全滅したなら、お気の毒ですが、おいしい # 話はそうないものです。責任は負えません。 # sed の扱いに習熟されている方、おおめに見てださい。:) # # # 自動化する方法：rc.local に 'check_hdspace &' と記述すること。 # $SLEEPTIME 秒ごとにディスク上の空きスペースをチェックします。 # フロッピーやテープドライブもチェックできます。:) # 空きスペースが $MINFREE (kb) 以下になると、警告メッセージを表示し、 # 問題のあるデバイスごとに 1 通のメールを $MAIL_TO_ME に送信します。 # 基準値以上の空きスペースが確保されると、再度スペース不足になった # 場合に備えて、メール送信機能が準備されます。 # # TODO: デバイスごとに異なる $MINFREE を設定できるようにすること。 # 空きスペースがなくなった場合、/*tmp ディレクトリのゴミファイルを # 掃除して、空きスペースを作るようにすること。 DEVICES='/dev/sda2 /dev/sda8 /dev/sda9' # デバイス; ディスクの設定 MINFREE=20480 # kb; これ以下で警告表示 SLEEPTIME=10 # 秒; チェックの間隔 MAIL_TO_ME='root@localhost' # 誰か; 警告メールの送信先 # ------- これ以下の部分は、変更する必要がありません (希望) :) ------- MINMB=0 ISFREE=0 MAILED="" let MINMB=$MINFREE/1024 # yep, we are strict :) while [ 1 ]; do DF="`/bin/df`" for DEVICE in $DEVICES ; do ISFREE=`echo $DF | sed s#.\*$DEVICE" "\*[0-9]\*""\*[0-9]\*" "\*## | sed s#" ".\*##` if [ $ISFREE -le $MINFREE ] ; then let ISMB=$ISFREE/1024 echo "WARNING: $DEVICE only $ISMB mb free." >&2 #echo "more stuff here" >&2 echo -e "\a\a\a\a" if [ -z "`echo $MAILED | grep -w $DEVICE`" ] ; then echo "WARNING: $DEVICE only $ISMB mb free. (Trigger is set to $MINMB mb)" \ | mail -s "WARNING: $DEVICE only $ISMB mb free!" $MAIL_TO_ME MAILEDH="$MAILED $DEVICE" MAILED=$MAILEDH # put further action here like cleaning # up */tmp dirs... fi elif [ -n "`echo $MAILED | grep -w $DEVICE`" ] ; then # Remove mailed marker if enough disk space # again. So we are ready for new mailing action. MAILEDH="`echo $MAILED | sed s#$DEVICE##`" MAILED=$MAILEDH fi done sleep $SLEEPTIME done わたしと読者が同じ環境にあるとするなら、読者は 430 人の登録者リストと、日に 100 通以上のメッセージを UUCP 上で受け取っているはずです。こういう場合、 ハッカーならどうやってこの巨大なログを処理するんでしょうか？ そう、 chklogs をインストールすればいいのです。 chklogs は Emilio Grimaldo <grimaldo@panama.iadhv.nl> が作成したもので、 最新バージョンの 1.8 は、 ftp.iaehv.nl:/pub/users/grimaldo/chklogs-1.8.tar.gz から入手できます。 なによりもまず、これをインストールしましょう(もちろん、doc サブディレクトリにある info ファイルも チェックすること)。 インストールが完了したら、crontab に次の行を書き込んで ください。 # Run chklogs at 9:00PM daily. 00 21 * * * /usr/local/sbin/chklogs -m 作業のあいまに、このソフトウェアがどれほど素晴らしいか作者に伝えるのを 忘れないでください。 次のスクリプトを記述した rmcores というファイル ( このプログラムの作者は、これを handle-cores と呼んで います) を作成します。 #!/bin/sh USAGE="$0 <directory> <message-file>" if [ $# != 2 ] ; then echo $USAGE exit fi echo Deleting... find $1 -name core -atime 7 -print -type f -exec rm {} \; echo e-mailing for name in `find $1 -name core -exec ls -l {} \; | cut -c16-24` do echo $name cat $2 | mail $name done そして、cron のジョブとして、これを定期的に起動して ください。 あるディスクから他のディスクへ、ファイルツリーを丸ごとすばやく移動させる方法。 (cd /source/directory && tar cf - . ) | (cd /dest/directory && tar xvfp -) [事故でディレクトリをダメにしてしまわないように、 cd /source/directory; tar... の部分を変更しました。 これを教えてくれた Jim Dennis <jim@starshine.org> 、ありがとう。〜管理人 ] お使いのコンピュータでどのディレクトリが一番大きいか？って思ったことは ありませんか？ 次のコマンドで判ります。 du -S | sort -n Linux Gazette の創刊者、John Fisk に栄誉あれ！ 素晴らしいオンラインマガジンで あるばかりでなく、無料！！！なのです。これ以上何を期待します？ 次のサイトを チェックしてください。 http://www.linuxgazette.com 現在、Linux Gazette は (1) 月刊になり、(2) John Fisk は既に編集を退いて、 SSC が引き継いでいます。 この問題を抱えている人が多いかどうかは分かりませんが、GNU Make のバージョン 3.70 にはわたしの気に入らない「特徴」があります。VPATH を絶対パス名で与えた 場合、おかしな動作をするのです。これに対処するきわめて安定したパッチを Paul D. Smith <psmith@wellfleet.com> が提供しています。また、彼は GNU Make が更新 されるたびに、ニュースグループ gnu.utils.bug にドキュメントとパッチを投稿 しています。わたしは、アクセスするシステムのほぼすべての gmake にこのパッチを 当てて再コンパイルしています。 Q：ブートのたびに e2fsck がディスクをチェックします。やめさせるには？ カーネルを再構築すると、そのファイルシステムは "dirty" とマークされ、 その結果、ブートのたびにディスクがチェックされてしまいます。これを やめさせるには、次のコマンドを実行します。 rdev -R /zImage 1 このコマンドでカーネルが修正されるので、ファイルシステムは "dirty" だと 判断されることがなくなります。 lilo を使っている場合、lilo の設定ファイル (通常は、/etc/lilo.conf ) の linux 設定の部分に read-only を加えてくださ い。 シャットダウン時に "device busy" エラーが頻発する場合は、リブート時にファイル システムが fsck されます。以下に簡単な修正方法を述べます。 /etc/rc.d/init.d/halt か /etc/rc.d/rc.0 に移動し、そして mount -o remount,ro /mount.dir の一行を、umout -a を呼ぶ前に、/ を除いた、マウントする予定のすべてのファイル システムに対して付け加えます。こうすれば、何らかの理由で shutdown がプロセスの kill に失敗してディスクの umount ができなかった場合でも、リブートの際、ディスクは "clean" なままです。リブート時間をかなり節約してくれます。 ls -l | sort +4n あるいは、ディスクスペースがまさに逼迫している場合には、ちょっと時間が 掛かりますが、効果てきめんの次のコマンドを使ってください。 cd / ls -lR | sort +4n #!/bin/sh # /usr/local/bin/print # a simple formatted printout, to enable someone to # 3-hole punch the output and put it in a binder cat $1 | pr -t -o 5 -w 85 | lpr わたしはこのスクリプトを "forall" と呼んでいます。次のようにして使って ください。 forall /usr/include grep -i ioctl forall /usr/man grep ioctl 以下は、"forall" の中身です。 #!/bin/sh if [ 1 = `expr 2 \> $#` ] then echo Usage: $0 dir cmd [optargs] exit 1 fi dir=$1 shift find $dir -type f -print | xargs "$@" 以下で紹介するのは、emacs のオートセーブファイル( #)、バックアップファイル(~)、 .o ファイル、TeX の .log ファイルについて、ファイル階層を再帰的に下降して 削除する簡単な 2 行モノです。.tex と README ファイルの圧縮もします。わたしはこれを "sqeeze" と呼んでいます。 #!/bin/sh #SQUEEZE removes unnecessary files and compresses .tex and README files #By Barry tolnas, tolnas@sun1.engr.utk.edu # echo squeezing $PWD find $PWD \( -name \*~ -or -name \*.o -or -name \*.log -or -name \*\#\) -exec rm -f {} \; find $PWD \( -name \*.tex -or -name \*README\* -or -name \*readme\* \) -exec gzip -9 {} \; ps -aux | sort +4n または、 ps -aux | sort +5n わたしは、暇があると C プログラムを書いてます。その合間に、 vi で C を書きやすくするための修正を加えました。以下がわたしの .exrc です。 set autoindent set shiftwidth=4 set backspace=2 set ruler これが何をしているかというと、まず autoindent は、最初に一度 インデントを入れるとそれ以下の行でも自動的にインデントを入れるものです。 shiftwidth は、ˆT をスペース 4 つ 分に設定するもので、backspace は、backspace モードに 設定するもの、ruler は、行番号を表示するものです。 特定の行番号に移動する場合、たとえば 20 行目に行くには、次のコマンドを 使います。 vi +20 myfile.c たいていのハッカーは、コンピュータ上に ctags を入れていますが、使ってません。 でも、これは特定の関数を編集する際にとても便利です。たとえば、ある関数があり、 それが作成中のプログラム用ディレクトリ内のたくさんのソースファイルのひとつに 入っていて、ちょうど更新のためにその関数の編集をしたいのだとします。そして、 この関数の名前は、foo() だとして、これをどのソース ファイルに入れたのか忘れてしまったとします。ctags が便利なのはそういう場合 です。ctags を実行すると、tags というファイルが カレントディレクトリに作成され、そのファイルにすべての関数が表示されます。 そして、それらがどのファイルにあるのか、そのファイル内のどこにあるのかを 教えてくれます。tags ファイルの中身は次のようなものです。 ActiveIconManager iconmgr.c /^void ActiveIconManager(active)$/ AddDefaultBindings add_window.c /^AddDefaultBindings ()$/ AddEndResize resize.c /^AddEndResize(tmp_win)$/ AddFuncButton menus.c /^Bool AddFuncButton (num, cont, mods, func, menu, item)$/ AddFuncKey menus.c /^Bool AddFuncKey (name, cont, mods, func, menu, win_name, action)$/ AddIconManager iconmgr.c /^WList *AddIconManager(tmp_win)$/ AddIconRegion icons.c /^AddIconRegion(geom, grav1, grav2, stepx, stepy)$/ AddStartResize resize.c /^AddStartResize(tmp_win, x, y, w, h)$/ AddToClientsList workmgr.c /^void AddToClientsList (workspace, client)$/ AddToList list.c /^AddToList(list_head, name, ptr)$/ vim で、たとえば AddEndResize() を編集する場合は、次のようにします。 vim -t AddEndResize これによって、エディタに適切なファイルが読み込まれ、カーソル位置が指定した 関数の最初にきます。 これは、FAQ の対象になるくらい広く知られた問題です。Red Hat のディストリ ビューションでこのバグが修正されたのかどうかは知りませんが、自分で直すこと もできます。/etc/hosts ファイルを覗くと、次のように なっているのが分かると思います。 127.0.0.1 localhost yourbox sendmail は起動時にホスト名(上記の例では、 yourbox) を探します。そして、yourbox の IP が 127.0.0.1 であることを知るわけですが、 sendmail はこの IP が嫌いなので、もう一度、探そうとします。 これを何度か繰り返して、最後に諦めて終了してしまいます。この問題を解決するのは とても簡単で、/etc/hosts ファイルを開いて、たとえば次の ように変更するだけです。 127.0.0.1 localhost 10.56.142.1 yourbox Red Hat ディストリビューションには color-ls が同梱されていますが、 どうして初期設定の色使いのまま放置されているのか理解に苦しみます。 以下は、それを修正するものです。 まず、eval `DIRCOLORS` とタイプします。 次に、alias ls='ls --color=auto' とします。 そして、上記 alias..... を /etc/bashrc に記述します。 コンパイルの途中でリンクする必要があるライブラリが見当たらない場合、どうしま す？ gcc が報告するのは関数名だけです。以下の簡単なコマンド で、その関数を見つけることができます。 for i in *; do echo $i:;nm $i|grep tgetnum 2>/dev/null;done 上記の tgetnum という部分に、探している関数名が はいります。 おそらく、そのプログラムをコンパイルして、test という 名前のバイナリを作成したのではないでしょうか？ Linux には test というプログラムがもともと存在しています。これは、ある条件が 真か否かをテストするプログラムで、真の場合は画面に何も表示しません。単に test と打つのではなく、./test と打ってみてください。 まず、対象となるパーティションを DOS パーティションとしてフォーマットして、 そのパーティション上に Windows スワップファイルを作成します。しかし、まだ Windows は起動しないでください(あとで圧縮がよく効くように、この時点では スワップファイルを空にしておいてください)。 Linux を起動して、上記パーティションをファイルとして保存します。たとえば、 パーティションが /dev/hda8 であるとすると、以下の ようにします。 dd if=/dev/hda8 of=/etc/dosswap DOS スワップファイルを圧縮します。ほぼすべて 0 が並んでいるので、圧縮は非常に よく効きます。 gzip -9 /etc/dosswap /etc/rc ファイルに次のような行を加えて、Linux 上に スワップスペースを準備し、インストールします。 XXXXX の部分には、スワップパーティションのブロック数が 入ります。 mkswap /dev/hda8 XXXXX swapon -av /etc/fstab ファイルにこのスワップパーティションの エントリを加えるのを忘れないでください。 お使いの init および reboot パッケージが /etc/brc か /sbin/brc をサポートしている場合、次の行を /etc/brc に付け加えてください。サポートしていない時は、DOS もしくは OS/2 をブートする場合でスワップパーティションを DOS/Windows バージョンに 戻したい場合に、下記を手動で入力してください。 swapoff -av zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100 上記は、最初の 100 ブロックをパーティション上に書き戻すだけです。 わたしは、経験上これで充分だと思っています。 >> この方法の長所と短所 長所：かなりのディスクスペースを節約できること。 短所：ステップ 5 を自動化できない場合、毎回手動で入力しなければならないので、 リブートが 1 ナノ秒遅れてしまうこと。:-) ここでは、わたしがこれまで何度か使ったトリックを紹介します。 削除してしまったテキストファイルをなんとかして復活させる方法。 テキストファイル、たとえばメールや深夜のプログラミング作業の成果といった ものを誤って削除してしまったとしても、諦めてしまうのは早計です。 ファイルが一旦ディスクに書き込まれていた場合、すなわち、だいたい 30 秒以上 そこにあった場合は、その内容はまだディスクパーティションに残っているかも しれません。 grep コマンドを使って、生のディスクパーティション (raw disk partition)を検索し、ファイルの中身を探すことができます。 たとえば、最近わたしは誤ってあるメールを削除してしまいました。その際、まず わたしはメールが存在していたパーティションの内容を変更してしまうような作業を すべて急遽取りやめました。この時は、ファイルを保存したり、プログラムを コンパイルしたりしないようにしました。それ以外にも、実際にシステムをシングル ユーザモードに落として、そのファイルシステムを umount したこともありました。 次に、わたしは、対象となるディスクパーティションに egrep コマンドをかけました。その際、削除してしまったメールは /usr/local/home/michael/ に置かれていたので、 df コマンドの出力から、それが /dev/hdb5 にあることが分かりました。 sputnik3:~ % df Filesystem 1024-blocks Used Available Capacity Mounted on /dev/hda3 18621 9759 7901 55% / /dev/hdb3 308852 258443 34458 88% /usr /dev/hdb5 466896 407062 35720 92% /usr/local sputnik3:~ % su Password: [michael@sputnik3 michael]# egrep -50 'ftp.+COL' /dev/hdb5 > /tmp/x わたしは、ディスクパーティションをいじる際は極端に慎重になるので、ここでも リターンキーを押す前に、一旦間をおいて、コマンドの構文が正確かどうか確認しま した。この場合、メールには "ftp" という単語が含まれていて、その後に "COL" という単語で始まる文章が続いていました。メールのメッセージは 20 行くらいだった ので、-50 を使って該当する文章の前後すべてのテキストを 取得するようにしました。以前は、-3000 を使って、ソースコード のすべての行を取得できるようにしたこともありす。また、ここでは、 egrep の出力を別のディスクパーティションにリダイレクトしています。 これは、探しているメールが、egrep の出力で上書きされて しまうことを防止するためです。 つづいて、strings を使って、取得した出力を検査して みました。 strings /tmp/x | less 思った通り、メールはその中に入っていました。 この方法は、ディスクスペースの全部または一部がすでに上書きされているような 場合には、成功しないかもしれません。 このトリックが有効なのは、おそらく一人でシステムを使っている場合だけかもしれ ません。複数のユーザがいて、ディスクが頻繁に書き換えられる場合だと、削除 したファイルが置かれていた空間はすでに上書きされてしまっているかもしれません。 それに、たいてのユーザは、ファイルを復旧する必要があるときでも、マシンを勝手に 独り占めするようなことはできません。 わたしの自宅のシステムでは、過去数年で 3 度ほど、数日分の成果を間違って捨てて しまった際に、このトリックが役立ちました。こうした作業を通じて自分でもたいへん 進歩したと思っている点は、フロッピーに作業のバックアップを取っておくように なったことです。おかげで、このトリックを使う機会は随分減りました。 Immutable フラグを使おう。 システムのインストールと設定が済んだら、すぐに /bin、 /sbin、/usr/bin、 /usr/sbin、/usr/lib (その他、およそ 必要そうな場所) にいって、どんどん chattr +i コマンドを実行 します。そして、root になって、カーネルファイルにもそのコマンドを実行 してください。次に、mkdir /etc/.dist/ を実行して、 /etc 以下にある全ファイルをそのディレクトリにコピーします (わたしは、一旦 /tmp/etcdist.tar を作ることで、コピーが ループするのを防いでいます。/etc/.dist.tar.gz を 作るというのでもいいでしょう)。そして、それらのファイルも immutable にします。 このようにしておくと、root でログインした際でも起こりうるダメージを最小限に 食い止められます。リダイレクション操作を誤ってファイルを上書きすることが なくなりますし、rm -fr コマンドで間違ってスペースを 入れてしまいシステムを不安定にしてしまうこともなくなります(その場合でも、 データにはかなりのダメージが及ぶかもしれませんが、ライブラリとバイナリの 安全性は向上します)。 また、この作業によりセキュリティ全般が強化され、サービスを停止させるような 攻撃が不可能もしくはより困難になります(そうした攻撃の多くは、SUID された プログラムの挙動を悪用してファイルを上書きする方法をとっていますが、 そうした SUID されたプログラムは本来勝手なシェルコマンドの実行を許すもの ではないからです)。 この作業による唯一の短所は、様々なシステムコマンドをビルドして、 make install する際に不便が生じるという点です。 つまり、make install する場合でも、ファイルを上書き できなくなってしまいます。あらかじめ Makefile を読んで、 上書きされることになるファイル(およびファイルがインストールされるディレクトリ) に対して chattr -i を実行するのを忘れると、make が失敗 してしまいます。そうした場合は、chattr を実行し、 再度 make してください。また、その機会を利用して、古いバイナリやライブラリ などを .old/ ディレクトリに移動させたり、リネームしたり、 tar でまとめておいたりするといいかもしれません。 新しいモノはみんな /usr/local か /usr/local/'hostname' から始めよう。 お使いのディストリビューションの /usr/local 以下が 空になっているなら、自分で /usr/local/src や /usr/local/bin などを作成して使いましょう。 お使いのディストリビューションの /usr/local 以下に すでにファイルツリーがある場合は、mkdir /usr/local/'hostname' を実行した上で、'wheel' グループに書き込み権限(+w) を与えましょう(わたしはさらに、SUID および SGID することで、wheel グループの 個々のメンバだけがそこにファイルを置け、それらの全ファイルが wheel グループに 属するようにしています)。 これからは、いつも！いつも！いつも！新しいパッケージを /usr/local/src/.from/取得場所の名前($WHERE_I_GOT_IT)/ に 置いて、/usr/local/src (もしくは ... /$HOSTNAME/src) 以下でコンパイルするようにしましょう。 もし「どうしても」/bin や /usr/bin 等にインストールしなければならないプログラムであるなら、/usr/local/ 以下の階層から必要な場所にシンボリックリンクを張るようにしま しょう。 こうした作業は面倒ではありますが、これによって、ディストリビューションの メディア(最近は CD が一般的です)から全体を再インストールする際に、 バックアップやリストアすべき部分と、再インストールすべき部分を分けやすく なります。また、/usr/local/.from ディレクトリを使う ことで、ソースをどこから取ってきたかを不完全ながら記録しておくことが できるので、パッケージを更新するときに便利ですし、セキュリティ関係の アナウンスを追いかけるときには非常に重要な情報になります。 自宅のシステムのひとつ(今これを書いているマシン)を使い始めた当時、 わたしはまだこうした方針を実行していませんでした。それゆえ、 「インストールした当初の」状態と現在の状態とがどれだけ違うか未だに よく分かっていません。マシンのシステム設定はほとんどいじっておらず、 これを使っているのは自分だけであるにも関わらず、そんな状況なのです。 それにひきかえ、わたしが職場(システム管理者の役をやらされていた 頃です)で設置したシステムは、すべて上記の方法で設定しました。 それらのマシンは、契約先の SE や情報関係の様々なひとびとによって 管理されてきましたが、今でもわたしは、最初にインストールと設定を した後に組み入れられたパッケージがどれなのかをつぶさに理解しています。 Linux Gazette の issue 12 に掲載されている 2c tips (訳注：原文は、 こちらです。なお、この Tips は、Linux Gazette issue 13 に掲載されています。 山口さん、情報提供ありがとうございました。) で、ちょっと難しすぎるか不必要と思われる手順が紹介されていることに 気付きました。方法はいろいろあるわけなので、わたしからもその手順を紹介します。 #!/bin/sh # lowerit # カレントディレクトリの全ファイル名を小文字に変換するスクリプト # 通常ファイルだけを対象とする --ディレクトリ名は変更しない # 既存のファイルを上書きする前に、確認を求める for x in `ls` do if [ ! -f $x ]; then continue fi lc=`echo $x | tr '[A-Z]' '[a-z]'` if [ $lc != $x ]; then mv -i $x $lc fi done ん〜、長すぎます。わたしなら、こういうふうには書きません。むしろ、 次のコマンドを使います。 for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`; done; これなら、コマンドラインで出来ます。 この投稿者は、彼が使っている方法を分かり易いスクリプトにしたと いっていますが(下記参照)、ちょっと違うと思う。 次の tips は、ユーザの追加と削除についてです。Geoff は上手くやっています が、最後の手順がよくない。リブート？ 彼がユーザの削除のたびにリブート していないことを望みます。最初のふたつの手順で充分です。そのユーザがどんな プロセスを走らせているのでしょうか？ IRC ロボットでしょうか？ そうした プロセスは次のコマンドで簡単に kill できます。 kill -9 `ps -aux |grep ^<username> |tr -s " " |cut -d " " -f2` たとえば、ユーザ名が foo なら、以下のようになります。 kill -9 `ps -aux |grep ^foo |tr -s " " |cut -d " " -f2` これで充分です。忘れてた root パスワードが必要になりますが。 Linux Gazette で紹介されてる解決法は最も汎用性がありますが、一番簡単な方法と いうわけじゃありません。LILO や loadlin を使っているなら、ブートパラメタとして "single" を入力して、ログイン手続きやパスワードなし でデフォルトシェルを直接起動できます。その状態でパスワードを変更するか削除した 上で、"init" を入力し、マルチユーザモードに 移行すればいいと思います。この場合、リブート回数は 1 回で済みます。そうでない と 2 回必要です。 Justin Dossey ここでは、何も修正されていないオリジナルのソースを使います。まず、sendmail の ソースコードを入手します。わたしは、version 8.9.0 を取ってきました。これは、 お気づきかと思いますが、安定版ではありません。取得先は、 ftp.sendmail.org:/pub/sendmail/sendmail.8.9.0.tar.gz でした。 これは 1 メガ前後あり、現在わたしは 8.7.6 を使っていることを考慮すると、 この作業はなかなか大変です。上手くいけばメールのやりとりができますが、 そうでないと、メールなしでは HOWTO の新版を出せなくなってしまいます。:) ソースを落としたら、解凍します。解凍すると、カレントディレクトリに sendmail-8.9.0 というサブディレクトリが作成されます。その ディレクトリに移動して、README と README_NOTES を読みましょう(そして、開発者たちが達成した更新結果に 驚愕しましょう)。次に、src ディレクトリに移動します。 作業のほとんどは、ここで行います。 sendmail は、コンパクトでパワフルな非常に良くできたプログラムです。 sendmail のバイナリは、5x86 133MHx の CPU と 32M バイト RAM のわたしの 環境でも 5 分以下でコンパイルできました。(設定を除いた)コンパイルと インストール全体で、15 分以下です！ わたしは普段自分のシステム上で BIND を動かしていないので、次の行は、 # ifndef NAMED_BIND # define NAMED_BIND 1 /* use Berkeley Internet Domain Server */ # endif 1 を 0 に変更し、以下のようにしました。 # ifndef NAMED_BIND # define NAMED_BIND 0 /* use Berkeley Internet Domain Server */ # endif Debian 1.3.1 の場合、デフォルトで db.h は、sendmail で必要とされる /usr/include ではなく、 /usr/include/db にインストールされます。それゆえ、src 、mailstats、 makemap、 praliases、 rmail、 smrsh のそれぞれのディレクトリに移動して、次のコマンドを実行して ください。 ./Build -I/usr/include/db 以上が済んだら、cd .. を実行し、make install と打ってください。これで sendmail version 8.9.0 が インストールされます！ もちろんこれは、自分用の設定ファイルを既にもっている 場合です。わたしは majordomo を使ったフリーメーリングリストをホストしている ので、すべてをスムースに稼働させるために、次の行を /etc/sendmail.cf に付け加える必要がありました。 O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe sendmail 8.9.0 は、ディレクトリ配置やファイルパーミッションの設定を最近細かく チェックするようになっているので、エイリアスとなっているディレクトリや ファイル、もしくはグループでの書き込み権限や自由な書き込み権限が付けられた .forward ファイルについて sendmail から文句が出るかも しれません。こうした細かなチェック機能を停止させることはよい考えではありま せんが、わたしはシングルユーザでコンソールを使って作業するだけなので、 チェック機能停止が小さなセキュリティホールとなったとしても大丈夫だろうと 思っています。そのあたりは、ご自分の環境にあわせて判断してください。YMMV /README.'hostname' か /etc/README.'hostname' のどちらか一方もしくは両方を作って、それを管理すること [ あるいは、/usr/local/etc/README.'hostname' でもいいで しょう 〜管理人] システム管理を始めたその日から、必ずオンラインのログファイルに記録を 付けるようにしましょう。root の /bash_logout に "vi /README.$(hostname)" という 一行を入れておくこともできます。あるいは、次のような su もしくは sudo スクリプトを書いておいてもよいでしょう。 function exit \ { unset exit; exit; \ cat ~/tmp/session.$(date +%y%m%d) \ >> /README.$(hostname) && \ vi /README.$(hostname) } script -a ~/tmp/session.$(date +%y%m%d) /bin/su.org - (入力履歴を記録するコマンドを使ってセッションログを取るとともに、関数を 作成して自動的にそのログに追加・更新がなされるようにしています) わたし自身は、こうした自動化を方針として採用していません。これまで手動で 記録する習慣を守ってきました。ただ、自動化というのもアリかなと思っている だけです(ご覧のように、スクリプトやシェル関数を作ってみたりはしてるわけ です)。上記スクリプトで気になる点は、script コマンド が入っているところです。このコマンドのソースを取ってきて、(コマンド履歴の 記録を一時停止したり中止したり出来るような)コマンドラインパラメタを付け加え てから、これを使おうと考えています。 わたしの(今回の)最後の提案は、 root ユーザのパスは、'PATH= /bin' とすべきである ということです。root のパスにそれ以外を付け加えるべきではありません。 ルートの作業で使うコマンドは、/bin からのシンボリック リンクかエイリアス、もしくはシェル関数というかたちで提供するか、あるいは、 /bin にあるスクリプトかバイナリとするか、絶対パスを指定 するかのいずれかにすべきです。 こうしておけば、root 権限で作業をする人は、自分がどれほどバイナリを頼りに しているか(ときには、痛いほど)分かるはずです。マルチユーザのホストを管理する 賢明なシステム管理者なら、自分の /bin や /.*history ファイルを定期的に調べて、なんらかのパターンや抜け穴が ないかどうか探すようになるでしょう。 本当にヤル気のあるシステム管理者なら、自動化できる箇所を探し当て、 システムの妥当性を検査するプログラムを必要な場所に置くことで、root 権限が 必要な作業をいちいちしないで済むようにするでしょう (スクリプトによって機能を細かく調整できる、エディタや MTA その他の対話的な 巨大プログラムについては、透過的なファイルやデータファイルが利用されることに なるでしょう。たとえば、悪名高い vi の ./.exrc や emacs の ./.emacs、さらに面倒な $EXINIT および組み込みヘッダやフッタマクロといったものです)。 当然、そうしたコマンドは、次のように実行することもできます。 cp $data $some_users_home/tmp su -c $origcommand $whatever_switches cp $some_users_home/tmp $data (オプションや引数は、コマンドによって異なります) 自宅で利用する場合やユーザが自分だけという場合、後半部分での提案は大げさでは ありますが、マルチユーザシステムの管理者、特にインターネットに常時接続されて いる(ネット関連企業などの)システムの管理者の場合、これらは非常に有益な ポリシーであると思います。 xdm を起動するファイル(たいてい、/etc/rc/rc.6 か /etc/rc.local にあります)を開いて、xdm の起動セクション が次のような内容になるよう編集します。 /usr/bin/X11/xdm exec /usr/bin/X11/X -indirect hostname /usr/lib/X11/xdm/Xservers を開いて、ローカルマシン上の X サーバを起動させる行をコメントアウトします(すなわち、起動しないように します)。 マシンをリブートすると、ローカルマシン上の X サーバも、リモートマシンの X サーバも両方使えるようになります。 これを紹介するのは、わたしがなんとか自分自身のサブネットを設定して現在の 状態にもってくる際、すべての問題の解決に 2 週間ちかくかかったからです。 注意：古い SLS (1.1.1) を使う場合、理由はよく分かりませんが、xdm の設定行に -nodaemon という記述を入れたままにすることもできます。 ただし、これは、それ以降のバージョンには当てはまりません。 翻訳：鴨澤眞夫(1996/10/01) <JCD00743@niftyserve.jp> 更新：千旦裕司(2001/03/20) <ysenda@pop01.odn.ne.jp> 校正：山口さん(2001/07/07) <keita@kyomu.net> 誤訳・誤字・脱字等がありましたら、<JF@linux.or.jp> まで ご連絡ください。