スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

who are you?

  • Sat
  • 00:33
  • OS
OSの手入れをしていたら、忘却されたでござるの巻き

[ryo@Millennia ~/src]$ su
su: who are you?
[ryo@Millennia ~/src]$ whoami
1001
[ryo@Millennia ~/src]$ su
su: who are you?
[ryo@Millennia ~/src]$ sudo
sudo: uid 1001 does not exist in the passwd file!
[ryo@Millennia ~/src]$

セキュリティに力を入れようと本気で思った瞬間。
多分、sysinstallのアップグレード中に逝ったんだと思うけど、何かの拍子にシステムに手がつけられなくなるのは怖い。

たまたまrootでログインしているコンソールが1つ生き残っていたので、作業データの退避がどうにか出来たものの…結局rootパスも失効してしまった。
OS組みなおし。
気をつけませう。
スポンサーサイト

今更だけれど

  • Sat
  • 00:46
  • OS
pkg_add早ぇorz
実行時の速度がワンテンポ遅く感じるだけで、小規模ユースでは特に不便は無い。
これは障害時の復旧用にpkg作っておいて即効で適用できるようにしておくと良いのかも。
システムのゴースト作るのと同じくらい自動化しておきたいところ。

----

JA山形が本気出しすぎていてワラたwww
http://plusmicro.blog98.fc2.com/blog-entry-847.html

sourceとportsの違い

  • Wed
  • 02:06
  • OS
ソースをtarボールで落としてmake installしたときは、大抵のプログラムは一箇所にまとめてインストールされる。
一方で、portsからmake install したときは、ディレクトリツリーのあちこちのPOSIX準拠な位置にインストールされる。
ついでに、portsは自動的にバージョン情報の取得やパッチ当て、依存関係の問題で足りないライブラリも自動で取得してくれる。

設定ファイルは、前者は見つけやすいが後者は名前を知らないと何処に存在するのか探すのが困難。しかし、依存関係のミスに陥りやすいのでメンテナンス性には疑問が残る。
後者は、メンテナンス性に優れるが、何処に何が行くのか分かりづらい部分があるので、変なところで詰まる可能性がある。


何だかな…。
何が重要なファイルなのか、それを記しておいてくれると助かるのだが。
マニュアル読めというのもあるが、要約された情報から得られる時間も時には大切だと思う。

インフラ整備の練習とメモ

  • Sun
  • 01:41
  • OS
来年以降サーバを使う機会が多そうなので、BSDの取り扱い練習をしてみた。
色々調べて触っていたら考え事が溜まったので、その整理を。

- Apache2
- Python
- MySQL
- FTP
- SSH
- NTP
- wget
- pico
-bash
- emacs
- useradd
- pw groupadd
- (Trac)

まず手作業で、ソースコードから全部makeしてみた。
恐ろしく時間がかかるのな。
バイナリ配布のありがたみが良く分かった。
あと、通常のDevelopperディストリ+上の構成だけで3.1GB以上もHDD容量を喰うので、貧弱なシステムでは一部の機能しか使えない。
…まぁコンパイルしてインストールする度に余分なバイナリをクリアすれば良いのだけれど、コンソールだけのシステムでコレ程容量を喰うとは予想外。

基本的にmake/make install で時間がかかる作業は全部終わりなのだけれど、その後各アプリケーションがきちんと動作するように適切な設定を行う必要がある。
この辺は何かスクリプトを作っておきたいところ。

いずれコマンド一発で環境整備を全部済ませられるようにしたいので、各アプリケーションのインストールから実際に利用可能な環境設定までにどれだけの手順が必要なのか一度試してみる必要があった。
今後は以下のプログラムの設定もそれぞれ試してみて、またそれぞれ適切な汎用設定を作り出しておきたいところ。

- Django
- jdk/jre/(Tomcat)
- NFS
- (PHP)
- 日本語環境一般
- Gnome2
- samba
- g4u

ヘッドレスシステムを想定しているので、リモートでの完全な制御を出来るようにしておく必要がある。
また、定期的なデータのバックアップ(ローカル/リモート)やディレクトリの整備(daily)も一通り試してみたい。
PHPは、一般的なUnix系OSの監視ツールでよく使われているので候補に挙げておく。
Tomcatは個人的にjava servletが(慣れの関係で)perlより使いやすいので挙げておく。
日本語環境、Gnome2 はヘッドレスでないノードを作成するときのための練習。
Sambaはその中でマルチOS環境で利用予定なので優先順位は下。

基本的な、環境整備のための読み書きの自動化には以下のステップを踏むつもり。

- ネットワークインストール
  1:sysinstall install.cfgの設定
  2:pxebootを利用したネットワークブート(スイッチを入れるだけでリモートにカーネルを読みに行く)
  3:必要なオプションを記したスクリプトの実行
  4:汎用のカーネルチューニング(明らかに必要なさそうなオプションを外しておく)

- 汎用ディスクイメージの作成
  5:インストールではなく、インストール済みのディスクイメージのコピーによって1~4を省略する

1は、sysinstall install.cfg はBSDに固有のOSのインストール情報を記述するスクリプト。
2は、pxebootはディスクレスでのOS起動が必要になった場合に備えて試しておく。特に、インストール用のスクリプトを勝手に読みに行くようにしておくと幸せかも。NFS,FTP辺りは必須ぽい。
(pxeとは、Intel版Wake On Lanみたいなもの。インストールの終了を知らせるシグナルの発信は出来ないだろうか…)
3は、一般的なアプリケーションの配備のための設定をスクリプト化したら、他のOSでもまんま使える状態にしておくのが望ましい。
5はできたらいいなといった感じ。g4uというシステムのゴーストを作成するソフトがあるのでそれでシステムのイメージをフロッピー起動で渡せる。3との違いは、これだと最低一回はコマンドを打つ必要があるという事。

完全自動化した環境構築の場合、特にネットワークアドレスは最初はDHCPによって自動で割り振っておく。
その後汎用のアプリケーションのインストール段階で自動で自分の位置を固定すれば何も触らないですむか…?

んで、ここまでやって、それぞれの機能がきちんと動作するようになったら次。
システムの監視とセキュリティの強化、パフォーマンス改善の勉強。

特に、障害時のデータの復旧、ディスクスライスの再割り当ての練習は特にしておく必要がある。
今日の練習でディスク容量が枯渇する事故があった。
こういう場合のディレクトリ構成の再割り当てをどうするのか良く調べておかないと色々困りそう。



当面は、これらを実験用のサンドボックスとしてVMwareの仮想マシンを利用して必要なスクリプトのテストを行う。
その後、有効なスクリプトを利用した環境のコピーをするための仮想マシンをもう一台作成して、必要が生じた時にそこからネットワーク経由で他のマシンに直接環境を構築するようにする。

うまく出来た仮想マシンは、DVDにでも焼いておけば他のヒトがその仮想マシンイメージを使うことが出来る。
またOSの基本部分のインストールの自動化をOS毎に作り分けておけば、その上で動作するプログラムのスクリプトもそのまま再利用できる。はず。


ローカルのDNS、メールサーバ、IP電話サーバ(Asterisk)も時間があったら試しておきたい。
セキュリティに関しては、オーソドックスなアクセス制御、侵入検知の仕方が攻撃に対してどの程度の威力があるのか、(各種田代砲やゲイツ砲、Apache砲による負荷攻撃やバッファオーバーフロー攻撃、ポートスキャン→侵入)実際試してみないことには分からないので、PCが汚染される危険はあるがサンドボックスでrootkitを探してきて試してみようと思う。

ロードバランサによるリクエストの分散化とファイルシステムの多重化、起動終了・日常タスクの自動化辺りが出来るようになるのが当面の目標。

容量的なスケールアップの下地が出来たら、次はリクエストではなくプロセス・タスクの並列・分散化の勉強がしたい。
コンピュータクラスタ、グリッドまでたどり着けると良いんだが...。

まぁ取らぬ狸の皮算用。
期末試験の勉強が先だね。
とりあえず頭の中が整理できた。

Lenny

  • Tue
  • 01:10
  • OS
***

:::Branch
Debian GNU/Linux 「Lenny」 のRC版がようやく出た。

http://journal.mycom.co.jp/news/2008/11/14/019/

Lennyは、以前test版だった頃のものを触った事があったけれど、「Etch」に比べると大分使い勝手が良かった。

:::GUI
GUI関連は、Gnomeが2.2系に切り替わるので、αブレンドをデスクトップで標準サポートするようになる。
2.1系だと、そこそこのグラボ載せてないとこの機能が使えない。
w2kでも普通のPCで出来たことを何で今まで出来なかったのか意味が分からないけれど、これで少し見た目が綺麗に出来ます。

:::Looks
BSDとDebianて良く似てる。
Ubuntuやwin、macと違って、入れるもの入れないと一般ユーザにとっては普通に使う事すら厄介な点が特に。

その代わり、余分なモノが殆どないのでとてもシンプル。

:::softwares
拡張性に関しては、BSDは必要なものは(最新版にこだわらなければ)あらかじめローカルに全て揃っているけれど、Debianは必要なものは基本的にネットワークからパッケージを取得する。
インストールに関しては、BSDはローカルのportsからmakeする事が多いけれど、Debianはパッケージからバイナリをインストールする事が多い。

どちらが良いかというと、それは好き好き。

:::driver
ある程度この分野に慣れていると、BSDの方がディストリビューションが少ない分、ドライバ関係でトラぶらなくて良いのかもしれない。
(BSDというと、メジャーなところではFreeBSD , NetBSD , OpenBSDくらい。それに、カーネル周りの互換性もそれなりにあるだろうし…)
Linuxはディストリの裾野が広い分、カバーしている範囲も広いけれど、一応ディストリ毎の動作対応状況も頭の片隅に置かなければならないみたいなので少しめんどいか?

ちなみに、Solarisはアウト。
アレはドライバを構築できても、カーネルに登録するのが恐ろしく厄介。
バスのidを直接編集しなくてはならない。
失敗すると、OSが飛ぶ。
いつの時代だよ。

:::CUI
コンソール周りは、Debianはあらかじめある程度bashなどの設定が行き届いている反面、BSDは初期設定では完全モノトーン。
どこかから、設定例引っ張ってこないと目が痛くなる。

:::speed
明らかに、Debianが早い。
起動速度が倍くらい違う。
もちろん、カーネルをチューニングしたらBSDもそれなりだろうけれど、通常操作での応答速度もかなり違う。BSDは微妙なタイムラグがある。この違いはなんだろう?

:::robust
BSDは硬い硬い言われているけれど、自分はセキュリティに関してはさっぱりなのでどうなのかよく分からない。ただ、少なくともOSを入れる段階で全てのサービスの設定をがりがりチューニングできるのは流石。
この点では、Debianも相当硬いつくりになっていると思うけれど、Linuxは余計なソフトが標準でたくさん付いてくるので、何処に思いもよらぬ穴が空いているのかよく調べないといけないのかもしれない。
偏見だろうか?


こうして細かいところを見比べてみると、改めてBSDとDebianは設計思想が大分違うように思える。
Debianは、どちらかというとroot(管理者)よりも一般ユーザが使いやすいように出来ているけれど、BSDはrootがサービスを展開する向けみたいな感じがある。

どちらも使いこなせば変わらず、良いものだと思う。

そのようなわけで、BSDも良いけれどLennyには期待。

…って、あれ?
BSDの話などいつの間に…

カウンター

プロフィール

Hatabon

Author:Hatabon
日々精進。
基本的に管理人はゆるやかな人です。
コメントへの返信もゆるやかです。

Twitter on FC2

最新記事

最新コメント

月別アーカイブ

カテゴリ

検索フォーム

全記事表示リンク

RSSリンクの表示

リンク

  • pagetop
Copyright © Hatabon
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。