Solarisの運用管理を紹介します。システムの確認にも使える様にまとめました。

・Syslogの設定
・ログの管理
・ロギングのアラート設定
・サービスの管理
・Solaris管理ツール
・ユーザーの管理
・ディスククォータの設定
・FTPゲストユーザの設定
・バックアップ計画
・戻る

SolarisにはSunOS特有のloghostという機能があり（たしかSun特有の機能だったハズ）syslogは他のサーバーが吐いたログもloghostが書き込みます。(他にmailhostなどもあります。）
閉じたネットワークでは大変に便利な機能ですが インターネットサーバー上でこの様な機能がそのままの場合、Dos攻撃の対象になりますので不必要ならこの機能は省いておくか、或いはsyslogdのポート514/UDPにアクセス可能なホストの範囲を制限するべきです。syslogdに-tオプションを付けて起動すれば外からのログ出力は受け取らなくなりますので起動スクリプトにも-tオプションをつけておいて 起動スクリプトからsyslogを再起動させればいいでしょう。

caseのstartの中にある
/usr/sbin/syslogd >/dev/msglog 2>&1 & を
/usr/sbin/syslogd -t >/dev/msglog 2>&1 & に書き換えればいいでしょう。

ではsyslog.confの基本構文を紹介します。
[ファシリティー].[プライオリティー] <TAB> [action]
よくsyslogが上手く機能しない場合やエラーを返す場合などは<TAB>をスペースと間違っているケースが考えられます。
複数のファシリティーとプライオリティーを連結させる場合はセミコロンで結びます。
[ファシリティー].[プライオリティー];[ファシリティー].[プライオリティー] <TAB> [action]
つまり 次の様な場合

*.alertとkern.errとdaemon.errが連結されており、うしろにアクションがくっついています。それぞれ
[*]ファシリティー
[alert]プライオリティー
[kern]ファシリティー
[err]プライオリティー
[daemon]ファシリティー
[err]プライオリティー
[operator]アクション
となっています。

ファシリティーとはアプリケーションが用意しているものです。どのカテゴリーにログを吐くのかをアプリケーションが指定してきます。それによってアクションをこちらで指定するわけです。プライオリティーもアプリケーションがフラグとして用意しているものです。そのアプリケーションの吐くログがどの程度重要な情報なのか、重要性を表したパラメーターフラグと思って良いのではないでしょうか。つまり、アプリケーションがログ出力をsyslogに渡す時に、どんな内容[ファシリティー]でどれほどの重要なログ[プライオリティー]なのか、教えてくれているわけです。管理者はそれに従ってアクションを指定します。アプリケーションが大して重要では無いというフラグを吐いた場合syslog.confで指定したプライオリティー以下の重要度ならそのアクションは実行されません。つまり

すべてのファシリティーに対してerrフラグ以上の重要性を持つ情報を受け取った場合、
kernに対してnoticeフラグ以上の重要性を持つを受け取った場合、
authに対してnoticeフラグ以上の重要性を持つを受け取った場合、
に /dev/sysmsg アクション(コンソール出力)を実行します。

プライオリティーのフラグ

noneは そのファシリティーを除外します。

ファシリティーのフラグ

auth	認証、セキュリティー
cron	cronシステム
daemon	デーモン
kern	カーネル
lpr	印刷
mail	メールシステム
mark	タイムスタンプの付与
news	netnewsシステム
syslog	syslogシステム
user	ユーザーのプロセス
uucp	uucpシステム
local0 から local7	local な facility に 利用される

表にまとめていますので参考にしてください。しかし実際は管理者の仕事として、ファシリティーやプライオリティーのフラグ単体を考えても全く意味はなく、それをどう実行するかといった[アクション]との組み合わせが肝心です。優れた管理者はログ取りが上手いと言いますが、その組み合わせでログファイルの内容は決まります。

アクション

基本的なsyslog.conf構造の説明は以上で終了です。しかし、Linuxの場合はこれで問題ないのですが、SunOS独特なsyslogの動作というものが存在します。Solarisのsyslog.confをみれば "ifdef" や "LOGHOST"といった記述を目にするのではないでしょうか？これはsyslog.confの動作をよりこまかく制御できる機能です。

ifdef ( `<変数>',
<変数が定義されている場合の処理>
<変数が定義されていない場合の処理>)

mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost)
次の様な場合
mail.debug /var/log/syslog
mail.debug @loghost
この２つの動作が 変数LOGHOSTによって場合分けされている、ということになります。

Solarisではhostsテーブルにloghostというホスト名（ニックネーム）を必ず指定しなければなりません。自分自身がloghostの場合、LOGHOST変数が定義されている事になりますので、 /var/log/syslogファイルにログを吐きます。このとき"/var/log/syslog"がアクションになっています。しかし自分自身にloghostというホスト名（ニックネーム）が指定されていない場合、変数LOGHOSTは定義されていない訳ですからloghostというホスト名をもつホストにログ出力を転送します。この時は@loghostがアクションになるわけです。これにより一度記述したsyslog.confを編集せずとも ホスト名（ニックネーム）にloghostを付ければ一気にログ出力の鉾先を他に向けれるわけです。
ただし、loghostがLinuxやBSDの場合、そちら側でsyslogdに-rオプションを付けて起動するようにしてください。そうしなければSolarisのログ出力を転送できません。また前述したようにSolarisがloghostで外部からのログ出力を受け取る場合は-tオプションをつけずにデフォルトのままで起動させてください。 syslog.confの編集が終わったら、再読み込みをさせて完了です。

# kill -HUP `cat /etc/syslog.pid`

ログは環境により一気に膨れ上がるものですから まず大きく膨れ上がる可能性のあるlogファイルを分割するスクリプトを用意します。下記は実行した際に/var/abmにあるログファイルmessasgeをmessage1 message.2 message.3 に分けて保存するスクリプトです。

まずmsessage.2をmessage.3に移して　次にmessage.1をmessage.2に移し、今ログを取っているファイルmassage をmassage.1に移します。　そして空のファイルmessageを作ります。最後にsyslogdを再起動さて空のファイルmessageに書き込み処理が移すようにします。
次に日付でファイルを分けるスクリプトを下に記します。

/bin./dateによって日付を抜き出し、.以下、拡張子として日付を利用しました。一番膨らみやすい/var/log/syslogファイルを日付で分割しました。
次に crondによっていつこのスクリプトを実行させるかの設定をします。ただしapacheなど別 ユーザーのログをcronに依存する場合はパーミッションにくれぐれも気を付けて下さい。

# crontab -l これでcrondの予定が一覧できます。
# crontab -e これで予定を編集します。

作ったファイルをnewsyslogなど適当なファイル名にして　適当な場所に置きます。たとえば/usr/lib にしておきます。

1行目は30分に一回 newsyslogを実行します。
2行目は毎日12時0分に実行します。（5番目のフィールドは年ではなく曜日です）
Solarisではcronの出力をメールで通知しますので、不必要である場合は> /dev/null 2>&1を末尾に付け加えてください。今回はエラー出力のみ有効にしています。（無条件で出力を吐き捨てる場合、2>&1は要りません）

ロギングの設定を紹介したところで、今度はログ内のメッセージにトラップを仕掛ける方法を紹介します。

loggreコマンド
このコマンドはsyslogにログ情報を渡すコマンドで、スクリプトからsyslogに情報を渡したい時や、syslog.confを変更した際の動作確認などに便利です。

-pオプションを使ってファシリティーとプライオリティーを指定することができますので この場合、user.errでsyslogサービスに"test"と出力することを示しています。

swatchの紹介
このツールのインストール方法はメインページの「インストールログ」を参照してください。このswatchはsyslogの動作を追跡し、それにともなって様々なプログラムを実行できることができます。たとえば、rootログインに失敗したユーザーがいたらrootユーザーにメッセージを送る。そのユーザーが連続3回失敗したら管理者の携帯電話に警告メールを送る、など事細かな監視が可能になります（FAXでの通 知など取り入れればおもしろいでしょうね） 。ただし、欠点として、一つの追跡に対して１つのプロセスを対で走らせなければなりません。

任意の設定ファイルを記述した後

叉は

で動作します。

設定ファイルの記述
watchfor /[監視対象文字列]/
[action]

ignore /[無視する文字列]/

となります。[action]とはmail やexecといった動作が入ります。
mail=<管理者メールアドレス>,suubject=<題名>
exec "<実行ファイル>"
throttle <連続的に実行しないためのスリープタイム>
when=<予約時間>
bell <ベルを鳴らす回数>
pipe <ログの一行をパイプする実行ファイル>

この6種類のアクションで大体のことはできるでしょう。mail execの使い方は下の様になります。

これによりserveradm@syns.netとhoge@docomo.ne.jp宛てに「your system boot」という題名のメールを送り、apacheが立ち上がります。インストールすればついていたかも知れませんが標準設定は次の様なものなので、これを基に自分の環境にあったものに変えていってください。最後のwatchfor /syslogd: going down/は、必ず知らせるようにしておきましょう。syslogdが落ちた事を知らずにswatchを起動している状況は異常ですので。

基本的な設定を終えてサーバーを外部にさらす場合はinetd.confの修正が必要です。LinuxやBSDの初期設定ではほとんどのデーモンが閉じている状態です。しかしSolaris8では逆にほとんどのデーモンがinetdにより立ち上がるようになっています。ファイアーウォールが無い状態では大変無防備な環境です。立ち上げないデーモンには先頭に#を置いてコメントアウトして下さい。場合によってはtcp wrapperでアクセスコントロールする方法もあります。

自分のinetd.confをみると先頭に番号がついている行があるかと思いますがそれは/etc/servisesで定義されていないポート番号です。デーモン名は先頭をみずに末尾を見て下さい。

inetdの起動
日本語Solarisの場合、inetdがjaロケールで起動されることになります。従って、inetdから起動される全てのサービスプログラムもjaロケールで動作することになり、in.telnetdから呼ばれるエラーメッセージなどの出力が日本語表示となっています。日本語を対応していないクライアントからのログインも考えた場合、サービスプログラムがjaロケールで動作するのは好ましくありません。 そこで、inetdがCロケールで動作するように、inetdの起動スクリプトinetsvcの最後の行を書き換えます。

そしてinetdを再起動すれば英語環境のサービスを提供できます。（-tオプションでsyslogによるログ出力が可能になります。）

inetdから立ち上がる必要のないサービスはinetd.confから停止できますが、起動時にも必要のないサービスがたちあがっています。SolarisではLinuxと違ってランレベル3を使っています。ランレベル3は2の拡張サービスを立ち上げるもので、NFSやNISがそれに入ります。

ランレベルの種類

/etc/init.dから構成されるサービス

この/etc/init.dから構成される起動スクリプトの中から必要のないものはrc.dから省いておくべきです。誤ってシステムが起動しなくなってしまっては困りますので￣/stopなどバックアップ用のディレクトリを作っておいて、その中に移す様にした方がいいでしょう。

Sunが用意してくれているツール、セキュリティーパッチがありますので、それを利用すると便利です。バイナリ配布されていますのでsparc版、intel版選択の上、インストールファイルを実行しましょう。パッチもpatchaddコマンドを使ってください。

パッチは4〜5ヶ月に一回くらいの周期ででています。毎月チェックしておくのが理想です。雑誌などてSystemV系UNIXのバグ報告やセキュリティーホールが発見され注意を呼び掛けていても、Sunが用意してくれているパッチ群でほとんど網羅されています。大体そういった警告を耳にしたころにSunサイトを訪れれば新しいパッチが公開されていて、それで問題を解決できるケースが多いです。ちなみに毎月の様に発見されているLinuxシステム及びデーモンのセキュリティーホールとSystemV UNIXシステム及びデーモンのセキュリティーホールとはまた別物です。
Solarisのセキュリティーパッチは http://sunsolve.sun.co.jp/pub-cgi/show.pl?target=patches/patch-license&nav=pub-patches ここから落として下さい。
（注意） 配布はzipで行われているため、unzipコマンドで解凍すれば一気にカレントディレクトリに飛び散りる場合があります。必ず解凍先ディレクトリを先に作っておいてそこで解凍しましょう。

たとえばダウンロードした123456-01.zipというパッチファイルを/tmpに移してから

としてください。
もしかしたらメッセージに「あなたの環境にこのパッチは必要ありません」と言われるかもしれませんが、それはそれで幸い問題ないと言うことです。オプション-Mを使用して、各パッチが入っているディレクトリと、各パッチ番号をリスト指定すると、1つのpatchaddコマンドで複数のパッチを当てることもできます。

もしもパッチを削除する場合は先程のパッチナンバー（そのままファイル名になっています）をpatchrmに渡せばきれいに消してくれるでしょう。

SunのGUIツール群をインストールするには　pkginfoコマンドで今現在のインストールされているパッケージを確認してください。pkginfo [パッケージ名]でインストールされているのかも確認できます。-xオプションで詳細な情報を得る事ができます。-dオプションで任意のディレクトリを指定すればそこにそのパッケージが含まれているのか確認できます。
インストール後にpkgchk [パッケージ名]でインストール後の情報を得る事ができます。最後にパッケージの削除は pkgrm [パッケージ名]で行えます。バージョンが低いパッケージが先にインストールされている場合は削除してからインストールするか、Sunのドキュメントの指事に従って下さい。パッケージ管理コマンドについてはメインページのUNIXコマンドを参照して下さい。 これらはAdmintoolsのGUIを使って行う事もできます。

Solaris Management Console
パッケージ管理などを行う。

AdminSuite
ユーザー管理、サービス管理などを行う

SolarisScreen Lite
ファイアーウォール設定などを行う。

自分、個人的に思うのですが、数々のプログラムをソースからインストールする事はかなりの必要性を感じますが、パッケージからインストールできるものはそうするベきです。なぜならパッケージからインストールしたものはパッケージ管理ができます。ソースからインストールしたものなら、いつ、どのパージョンでどこに？と時が経過するにつれて忘れていくものでしょう。 BSDならports、Linux RedhatならRPM、色々とパッケージの種類があるのはパッケージを管理するためのモノであり、インストールを簡単にするためのモノと理解するのは初級者の見解です。

ユーザーの環境
一般ユーザーがログインするときに環境変数はcsh&tcshの場合$HOME/.cshrc $HOME/.login /etc/.login です。リモートログインによる初期環境変数は/etc/.loginから引っ張ってきます。これは$HOME以下のファイルと異なりすべてのcshユーザーが共有するものです。これらの記述方法は.csh .login供に同じですが,$HOME/以下が一番初めに読み込まれる為、$HOME/.cshrc $HOME/.loginが優先的に設定されます。
ksh また、ユーザーデフォルトシェルのshの場合は$HOME/.profile /etc/profileです。ほとんどのshは$HOME/.profileを使いません。今現在、何も$HOME以下に環境設定ファイルを作成していないのならば 今の環境は/etc/profileから引っ張ってきているものです。もしもユーザーを作成する場合、この環境設定ファイルを定義することができます。-kオプションでどのひな形ファイルを環境設定ファイルにするのか指定できます。一般 には/etc/skel以下にそのひな形がありますので、一度みてみてください。そしてuseradd コマンドで-kオプションを使えばそのひな形を使う事ができます。

ユーザーセキュリティー
umaskはファイルを作成する際のデフォルトパーミッションを定義します。chmodはその後のパーミッション変更に用いられています。umaskとchmodはセットする値が逆転しており、利用目的は同じです。
umask 000 = chmod 666
umask 111 = chmod 555
umask 222 = chmod 444
ただし、umaskでセットした実行パーミッションはディレクトリにしか作用されません。
chmodを使ってsetuidをセットする場合は4***又はu+sを使って下さい。
chmodを使ってsetgidをセットする場合は2***又はg+sを使って下さい。

パスワードの管理
admintoolを利用するとの[ユーザー追加]ウインドウまたは[ユーザーの変更]ウインドウの[アカウントセキュリティー設定]セクションを使って設定した/etc/shadowファイルのパラメータに基づいて、パスワードの有効期限が決定されます。useraddコマンドを使って指定する場合はオプション-fの最長非使用日数と-eの有効期限です。
最長非使用日数 : 有効期限がきれた後、アカウントを使えない状態にする日数
有効期限 : アカウントの有効期限。この日を過ぎるとアカウントは無効になります。

一般ユーザーがパスワードを変更する際にはスーパーユーザーが一般ユーザーのパスワードをセットする場合とは別 にいくつかの制約があります。
ユーザーアカウントと同じパスワードはセットできません。
新しいパスワードは前のパスワードと少なくとも3文字は異なっている必要があります。
パスワードの先頭からPASSLENGTHで指定した文字数の部分に少なくとも2文字の英数字と1文字の数字が含まれていなくてはいけません。
パスワードは、/etc/default/passwdファイル(/etc/passwd)のPASSLENGTHパラメータに指定された文字数と同じかそれ以上でなければなりません。
6文字以上のパスワードをセットしなくてはいけません。またDES暗号方式(5.8の場合)を使用されているので8文字以上の文字は無効になります。

スーパーユーザーの制限
/etc/default/loginファイルはユーザーのログイン時に関する様々な設定が定義されています。そして/etc/default/loginと同様にrootユーザーにスイッチするsuの設定が定義されているのが/etc/default/suファイルです。FreeBSDなどの場合、Wheelグループといったものがありますが、Solaris8にはありません。ですから、もしも複数で管理しているシステムなどはBSD同様に管理ユーザーグループが必要になるかもしれません。
1) /etc/groupを編集して、wheelグループを作成する。
2) wheelグループにrootになることができるユーザを追加する。
3) /usr/bin/su コマンドのグループのownerをwheelにする。
4) /usr/bin/su コマンドのパーミッションを4510に設定する。
この様な方法でWheelグループで管理者をまとめてもよいですし、UID0(ゼロ)のユーザーを複数作ること考えられます。
それとは別に、完全なスーパーユーザー権限を渡す必要はない場合、簡単な管理を複数のユーザーで共有する場合などadmintoolコマンドを利用して一定のシステム管理作業をおこう事が可能です。Solaris8のソフトウェアadmintoolsはsysadminグループという特別 に用意されたグループを用いることによりシステムのセキュリティーを損なわずして基本的は管理作業を実行できます。

ディスククォータを利用することで、ディレクトリ毎やユーザ毎に最大容量を決めることができます。
まず、クォータを設定するファイルシステムのマウントポイントにquotasファイルを作成してください。

/etc/vfstabを編集して次の様に該当するファイルシステムにrqオプションを付けて下さい。

ユーザーの制限にはedquotaコマンドを使って編集します。

上記の記入は 指定した [ユーザー名]が/export/homeと/varに対して書き込めるソフトリミットとハードリミットです。
そのユーザーが他のファイルシステムにも書き込みパーミッションを持っているのであれば、そのファイルシステムにも制限をかける方がようでしょう。blocksは1KB単位 です。inodesは個数です。１人のユーザーのquota設定 を他のユーザーにも使う場合は-pオプションで同じ制限をコピーすることができます。

quotaの設定確認はrepquota -avで行って下さい。

特定のユーザーの情報を知りたい場合は以下の様に実行してください。

クォータタイムリミットは-tオプションを使います。

デフォルトでは0になってい場合がありますが、1weekが一般 です。
以上が終えればquotaを起動させてみましょう。

整合性をチェックするために次のコマンドも忘れずに実行して下さい。

以上、quota簡単にまとめてみました。 整合性をとったあとで repquota -avコマンドを実行すると、ユーザーがどの程度のblockあるいはinodeを利用しているかわかるはずです。

chrootを使ったユーザ（FTPゲストユーザ）を作成することで、閉じたホームディレクトリをFTPで公開させることができます。
まずchroot用のユーザを作成します。今回はftpuserというユーザ名にしました。

次にguestuserエントリを/etc/ftpd/ftpaccessファイルに追加します。

ftpaccess ファイルで、ゲストユーザがclassのメンバーであることを確認します。

ftpconfig スクリプトを使用して、chroot領域の必要なファイルを作成します。

次に、FTPゲストユーザ用の /bin/trueが含まれる/etc/shells ファイルを作成します。
その他、ftpを使うユーザのログインシェルもここに記入します。(例)/bin/bash、/bin/tcshなど
/sbin/sh
/bin/csh
/bin/jsh
/bin/ksh
/bin/remsh
/bin/rksh
/bin/rsh
/bin/sh
/usr/bin/csh
/usr/bin/ksh
/usr/bin/bash
/usr/bin/tcsh
/usr/bin/zsh
/bin/tcsh
/bin/true

以上で設定は完了です。以降ftpuserがftpでログインした際は閉じたホームディレクトリのみの公開になります。

バックアップには動的バックアップと静的バックアップがあります。

静的バックアップ
ハードディスクやテープドライブなどに一定の時期毎バックアップをとることです。欠点は毎日05:00に静的バックアップを取っていた場合、時刻11:00にクラッシュしても復旧できるデータは時刻05:00のリソースになるわけです(6時間分のリソースは消えます)。しかし、動的バックアップと違って静的バックアップは人為的ミスで起こる障害に対しての復旧には対応できます。

動的バックアップ
リソースをハードディスク2台以上を使って並列的に書き込む事です。単一のディクスがクラッシュしても他のディスクで稼動させることができます。欠点はディスクコントローラーやディスク以外の故障には対応できません。また人為的なミスによるファイルの消失にも対応できません。

静的にバックアップを取るか動的に取るか、など迷う必要はありません。2種類のバックアップを重ねて取ればいいのです。例えばHDDx2(RAID)+tape等が一般 的なのではないでしょうか。

静的バックアップの種類

ufsdumpコマンドによるバックアップ
特徴：
バックアップの単位はファイルシステムごと
ネットワーク上のファイルをバックアップできない（リモートのデバイスにはバックアップ可能 ）
１つのファイルシステムを複数のボリュームにわたってバックアップ可能
テープ長の長さは不要
復旧コマンドはufsrestoreのみ対応
実行はrootのみ

使用例：
フルダンプ

uオプションは/etc/dumpdatesファイルを更新を表示するためのオプションです。このファイルの情報は差分ダンプを行う時や差分ダンプからファイルをリストアする時に使用されます。もし-uオプションを付けずにufsdumpを実行すると/etc/dumpdatesの更新をしなくなり、差分バックアップのリストア時にひとつひとつ内容を確認することになります。効率が悪くなりますので必ず-uオプションをつける事にしましょう。
0オプションはレベル0(フルダンプ)のことです。
cオプションはテープドライブ(カードリッジ)を使う事を示しています。
fオプションでデバイスファイルを指定します。
oオプションはオフライン機能のことです。ダンプ完了時やテープの終端時にリワインドしてオフラインにするためです。フルダンプは容量 が比較的大きくなるものですからoオプションをつけるのが一般的なのです。

リモートダンプ
.rhostsやNFSをつかってバックアップ先をリモートデバイスに指定します。

差分ダンプ

差分ダンプはメディア容量 を比較的に使いませんが、どのファイルがリストアされたかわかりにくくなるものです。そこでaオプションをつけてindexログファイルを作成する事をおすすめします。
この例では/homeの差分ダンプをとる様にしていますがネットワークファイルシステムはバックアップできません。/export/homeの部分だけになるでしょう。

ufsdump実行前に
1,シングルユーザーモードになる事をお勧めします。
2,バックアップ対象のファイルシステムの整合性をチェックしてください。

3,バックアップ対象の容量 を確認してください。