openSUSE 11.4 がリリースされましたが、
今回は geeko を折り紙で折ってみる方法をご紹介します！

続きを読む »

こんばんは、桔梗です。
Linuxでサーバーを立てるとき、どのように考えて作っていますか？

これは今の職場で実際にあった話ですので、参考にしてください。

・必要ないパッケージまで全部入れる。
これはまず、間違っているでしょう。OSはRHEL3.9です。RHELの古いやつはアップデートにものすごい時間がかかるんです。
さらに、パッケージによっては強制的に設定ファイル上書きするみたいで、必要な設定ファイルを全部バックアップとって・・・とやるから一日がけなんですよね。その点、SUSEであれば、DeltaRPM の機能で差分だけの提供ですから、設定ファイル書き換えなんていう事態も発生しないと思います。そして何より、アップデートにさほど時間がかからない点でしょうか。
後は、必要ないパッケージまで入れることで、セキュリティホールを生み出しています。いやね、使いもしないもの入れておいて、クラッキングされた後が怖い。自分ならそんな変な構成はしませんよ。
私なら、必要最低限のパッケージを導入した後に必要なものを導入していきます。これが一番構築の手間はかかるけれども、後の管理は楽です。SUSEなら、CUI上でもYaSTくんが使えるのでGUIじゃなくてもさほど苦労しないかと思います。

・セキュリティOSが有効になっていない
外部に公開しているサーバーなのに、セキュリティOSが有効ではありませんでした。
RHELなのでSELinuxなのですが、SELinux Policy Editorができたとはいえまだ、難解な面は残っています。とは言っても、軍の用途にも耐えられるくらい強力なものです。いくら強力なものを作ったとしても使い勝手がよくなければ、ユーザーは増えないものですよね。
SUSEであれば、AppArmerという機能があります。SELinuxより設定が簡単で使い勝手がよいものです。これはYaSTくんから設定が可能です。拍子抜けするくらい簡単に設定ができますよ。

・FWの設定は？
FWの設定はGUIでやれば今でこそ簡単ですが、実際に運用されているサーバー群でどれだけXが使えるというのでしょうか。
FWはGWでやっているから安全だ、という人がいますが、実際は違います。GWに設置してあるFWは確かに外からの攻撃には強いですが、 LAN内部からの攻撃は素通りしてしまいます。また、LAN内部のユーザー全体がTelnet等でサーバーにアクセスできてしまうのも考え物です。サーバーごとに制御をかけるのであれば、サーバー自体にもFWの設定は必要でしょうね。

サーバーを守る手段は考えてみればいくらでもあるものです。
攻撃にあったときに被害を最低限にとどめるために、もう一度セキュリティを見直しを含めて、サーバー全体を見直してみませんか？
そして、実際にこれじゃだめだ、ということがわかったとき、乗り換え対象のディストリビュージョンとして、openSUSEやSLES、SLEDが候補に挙がってくれれば幸いです。openSUSEやSLES、SLEDであればセキュリティ対策はとても簡単にできるものなのですから。

気がついたら一年ぶりですか?
どうも、お久しぶりです、桔梗です。
仕事が忙しくてなかなか更新する暇がありませんでした。

表記、八月勉強会のネタですが・・・・
C++＆QtによるSUSE Linuxでのクロスプラットホーム開発入門＆SUSE LinuxでWAFを作ろうの二本立てを予定していますが、どこまで準備できるのかが疑問です。
現在、メインマシンがトラブル(発熱)を抱えており、プレゼンで使えるマシンがない状態になっています。
仕方ない、はやりのNetBookでも買おうかな・・・・
#それはそれでWintelの策略に乗ったみたいで悔しい。

ちなみにIDEは物置から引っ張り出してきたBorland　C++ BuilderXもしくは、Turbo C++を予定していますが、
時代が時代なのできちんとKDEのIDEでもやる予定です。

<< Wednesday, January 7th, 2009 by Andreas Jaeger >>

openSUSE プロジェクトで使われているバグ・レポート・ツール(bugzilla.novell.com)が、1月10日にバージョン 3.2 へとアップデートされます(いくつかの Novell 独自の変更が含まれています)。

変更の中で特筆すべきことは、バグ報告にあたって新たにガイド・モードが追加され、これが Novell 外のアカウントで報告する際のデフォルトとなるということです。

ガイドなしモードを使っていて、ガイド・モードに切り替えたい場合は(あるいは、その逆を望む場合は)、”新しいバグレポート”のテンプレートをブックマークしておくことも可能です(詳細については下記をご覧ください)。こうしておくと、ブックマークの URL を編集して“?format=guided”を追記したり(ガイド・モードに切り替えたい場合)、この部分を削除して元に戻すことができるようになります。このブックマークを使うことにより簡単にアクセスできるようになりますし、あらかじめいくつかの情報 — たとえば“Found By”の欄には“Community User”が記入済み — が記入されている openSUSE 11.1 のバグレポート用のブックマークを既に作ってあります。ただし、ガイド・モードが使えるようになるのは bugzilla がアップデートされた後のことになりますので、ご注意ください。

アップストリームの bugzilla についての 3.2 で変更点については、bugzilla 側にドキュメントがあります。我々が用意した bugzilla にはいくつかのバグ・フィックスと拡張が追加されています。

bugzilla はこのアップデート作業のため、10日の 10:00 AM から 2:00 PM の間(Mountain Time – 訳注:日本時間だと11日 2:00 AM から 6:00 AM の間)、使用できなくなります。

なお、バグ報告にあたっては、ガイドラインにも目を通しておいてください。

手順：新しいバグ報告のテンプレート作成方法

• “New”を選択して新規のバグ報告を作成します。事前に定義しておきたい属性の値を記入してください。
• このボタンをクリックします。
• 新しいページが表示されます：
• ハイパーリンク上で右クリックして、[このリンクをブックマーク](Firefox の場合)を選んでブックマークに追加してください。
• このブックマークを選択すれば、事前に属性が記入されている新たな不具合報告を作成することができます。

原文はこちら

news.opensuse.org に流れた告知ですが、現在公開中の openSUSE 11.1 Beta1及び SUSE Linux Enterprise 11 Beta1(こちらは一般公開されていません) に含まれる Intel e1000e ネットワークカードドライバに深刻な不具合が発見されています。

e1000e ドライバ(e1000 ドライバなら問題はないとのこと)を使用するネットワークカードが付いているハードウェアをopenSUSE 11.1 Beta1 もしくは SUSE Linux Enterprise 11 Beta1 で起動した場合、最悪ネットワークカードを壊してしまう可能性もあります。

お使いのハードウェアに付いているネットワークカードが該当するかどうかは、上記からも辿れるこことかここあたりの情報を参照して確認してください。

もし Intel 製の Gigabit Eathernet Card が装着されていて、上記を参照しても該当しているか否か確認が取れないようでしたら、念のため openSUSE 11.1 Beta1 及び SUSE Linux Enterprise 11 Beta1 ではマシンを起動しないようにしておいたほうが良さそうです。

備忘録代わりですが・・・

Zebraってなんざらしょ？
職場で使うことになり、調べてみました。なになに、ルーティングソフトウェア・・・？それじゃ、CiscoIOSみたいなものか？と思ってみたら、それがビンゴ。設定ファイルを介さないで設定するのでめんどくさいような楽なような・・・なんだかよくわからん代物です。

でも・・・・LinuxわかってないNetwork屋さんがいじる分にはちょうど良さそうなものです。私は、サーバー屋さんなので まずは、設定ファイルありきですがね。
このZebraというソフト、使いこなせればそれなりに強力そうです。詳しくは以下のURLをどうぞ。

http://www.zebra.org/ 

Weekly News/28 で紹介されていた Benjamin Weber のブログ記事より。

以下に紹介するアップグレード手順はある程度システムに精通している方を対象とした手順であり、完全に無保証です。実行される場合は自己責任で行ってください。また、必要なデータのバックアップをお忘れなく！

稼働中の openSUSE を新しいバージョンにアップグレードしようと思っても、現状では公式にサポートされた方法はありません。インストールメディアから起動してオプションでアップグレードを選択するという方法のみがサポートされています。とはいえ、稼働中のシステムをアップグレードすることは可能です。RPM のペイロード・フォーマットが bz2 から lzma に変更されたことに伴い 10.3 のシステムへ 11.0 の RPM をインストールすることができなくなったため、10.3 から 11.0 へのアップグレードは、これまでよりも難しくなっています。

以下がその方法の概要です。

1. RPM を 11.0 で使われているものにアップグレードする

2. 11.0 のすべてのパッケージマネジメントスタックをインストールする

3. すべてのパッケージをアップグレードする

手順

アップグレードするための具体的なステップはシステムにより異なってきます。以下はあくまで一例です。

10.3 で使っていたすべてのリポジトリを無効にする。

mv /etc/zypp/repos.d /etc/zypp/repos.d.old

リポジトリのキャッシュを削除する。

rm /var/cache/zypp/zypp.db

openSUSE 11.0 のメインリポジトリを追加する。

zypper ar http://download.opensuse.org/distribution/11.0/repo/oss \
openSUSE110

openSUSE 11.0 の新しい RPM をインストールする。

64bit 版の場合

rpm -Uhv ‘http://download.opensuse.org/distribution/11.0/repo/oss/suse/x86_64/rpm-4.4.2-199.1.x86_64.rpm’

32bit 版の場合

rpm -Uhv ‘http://download.opensuse.org/distribution/11.0/repo/oss/suse/i586/rpm-4.4.2-199.1.i586.rpm’

11.0 のパッケージマネジメントスタックをインストールする。

zypper in zypper

インストールソースとして追加していたリポジトリがあるなら、それらの 11.0 対応リポジトリを追加する。(以下、例として nonoss と packman の 11.0 対応リポジトリを追加する場合)

zypper ar http://download.opensuse.org/distribution/11.0/repo/non-oss \
openSUSE110_NonFree

zypper ar http://packman.iu-bremen.de/suse/11.0/ packman

すべてのパッケージをアップグレード。この段階でいくつかのパッケージでベンダが変更されることや、いくつかの古いパッケージがなくなっていることを確認されます。

zypper ref
zypper dup

再起動します。

問題点

アップグレードの後、いくつか重要な問題が発生するようです。以下に例として紹介する2点については、いずれもアップデートされた設定ファイルが自動では上書きされず、自前で編集した設定ファイルがなくなってしまっていたために起こる問題でした。

Networkmanager が、接続後すぐに切断してしまう。これは、古い dhclient の設定ファイルがなくなっていたことに起因していました。これについては以下の通り対処します。

mv /etc/dhclient.conf.rpmnew /etc/dhclient.conf

openSUSE updater がバックエンドを見つけ出せない。これは、古い zypp の設定ファイルがなくなっていたことに起因していました。これについては以下の通り対処します。

mv /etc/zypp/zypp.conf.rpmnew /etc/zypp/zypp.conf

アップグレードに伴い設定ファイルが欠落すると、予期せぬ箇所での不具合がを引き起こされます。アップグレード後何らかの問題が確認された場合、ど の設定ファイルを見ればいいのか、どう修復すればいいのか見当がつかないようでしたら、上記手順でのアップグレードは止めておいた方が無難かもしれませ ん。その点はどうぞご承知置きください。