滅多にないのですが、SLES でサーバ運用しているシステム上で 「Office 系のアプリケーションを使いたい」というケースがあります。よくある例としては、例えば、マニュアルのネタを作成したいとか、スプレッドシートから、csv テキストでのエクスポートをしたいとかのケースでしょうか。そんな時に役立つのが ”SUSE Linux Enterprise Workstation Extension” です。


詳細はこちら

SUSE Linux Enterprise Workstation Extension

ダウンロードはこちら

SLE-12-SP3-WE-DVD-x86_64-GM-DVD1.iso

※ 二枚ありますが、二枚目はソースコードです。

ISOファイルをメディアに焼くなり直接 ISO をリポジトリに登録します。

a0056607_20023868.jpg


YaST > Software > Software Management から、"Lible..." とか "gimp" などのキーワード検索をします。インストールしたいアプリケーションをチェックして Accept すると、インストールが自動的に始まります。

a0056607_20030479.jpg

gnome Desktop を開くと、"Applications" にアイコンが追加されます。 "Add Desktop" していれば、 "nautilus Desktop" からもアクセスできます。

a0056607_20033068.jpg

# nautilus &

a0056607_20035404.jpg

# soffice &

で LibleOffice を起動してみました。

a0056607_20041680.jpg



メニューを日本語に切り替えます。

Tools > Options > Language Settings > より "Japanese" を User interface にセットして、アプリケーションを再起動

a0056607_20044287.jpg

メニューが日本語化されました。ただし、システム言語が English なので IME は使えないようです。SUSE Enterprise Desktop (SLED) ならどうなるか、これはまたの機会に試してみたいところです。

a0056607_20050593.jpg

ついでに gimp も使ってみましょう。

# gimp &

a0056607_20054258.jpg

※ gimp は Edit > Preferences > Language から日本語に変更できそうなのですが日本語化パッケージが含まれていないので、日本語メニューが使えません。2.8.18 Portable 版ならできるようです。

--

サーバーの実運用ではあまり利用方法がないでしょうが、スプレッドシートから、何がしかのデータを csv エクスポートしたり、画像のハードコピーを取って evernote にアップデートするとか、チョコチョコした目的で、「やっぱりオフィスアプリケーションが欲しい」という場合には便利でしょう。

ある意味では、単一のバイナリファイルで、複数ユーザが複数セッションで利用できる、Linux/Unix 系OSの特徴でもあり、マルチタスクシングルユーザの Windows OS とは違い、シンクライアント、マルチユーザアプリケーションとして、アプリケーションコンテナの様に少ないリソースで利用できるのはちょっと面白いな、と感じました。

今回の環境は英語システムなので、日本語入力ができない事、また gimp の日本語拡張パッケージがない事など、不満な点はありますが、値段が高く、ライセンスが厳しい Microsoft 製 Office Suite より気にせず使えて、しかもマルチセッションで使える点など、うまく利用方法を考えると、サーバー内部で完結しており、情報漏えいなどのリスクも少ない所は、面白い点がありました。



- Keyword -
SUSE Linux Enterprise Server, SUSE, SLES, Office Application, LibreOffice, gimp2, インストール




[PR]
by islandcenter | 2017-10-11 20:08 | SUSE | Trackback | Comments(0)


SUSE Linux Enterprise Server 12 Support Pack 3 (SLES12sp3) が 2017/8 にリリースされたので、インストールしてみました。ここではインストールの流れを見てゆきます。

- インストールのはじまりはじまり -

まず DVD からブートアップ > "Installation" を選びます。

a0056607_07110101.jpg

ライセンス同意画面と、キーボード、言語の選択です。

Language: English
Keybord : Japanese

を選び、日本語 106 キーで特殊キーや NUM Lock キーが押されていないかを "Keyboard Test" エリアで確認します。

※ いつものことですが、 Language : Japanese も選べますが、とても意味不明でステキなニッポン語のメニューになるため、SLES は常に第一言語 English 第二言語 Japanese を選んでいます。また、サーバーのコンソールはほとんどが英語ですし、YaST を使う場合の ALT+ショートカットキーが使いづらくなるので、日本語は優先言語としません。

License Agree をチェックして次へ

a0056607_07121664.jpg


アクティベーションの設定です。ここをチェックすると、インターネットに接続に行き、アクティベートされてしまうので、いつも Skip しています。リポジトリも登録されるため、細い回線環境だと、インストレーション作業に時間がかかるため、スキップして、ある程度チューニングした後にアクティベートして、アップデートを行っています。

a0056607_07133246.jpg

追加プロダクトです。通常は何もないので Add On Product は何もセットせず次へ

a0056607_07141729.jpg

デフォルトで入れるか XEN または KVM のハイパーバイザー起動とするかの選択です。ハイパーバイザーとして導入すると、アクティベートや 1 Click Install に必要なブラウザや yast2 や virt-manager などのGUIツールが入らないので、ここでは Default 導入して、後に ハイパーバイザーだけを導入しています。


a0056607_07150204.jpg


ボリューム定義です。マニュアルによると jeOS で 1.0Gb、最小のX環境で1.4Gb, フルインストールで 8.0Gb 程度のディスク容量が必要です。ただし SLES12 より "/" ルートパーティションは Default : BtrFS でスナップショットを取れるため、スナップショットからロールバックを使う場合は 使用量の倍の容量を確保することが推奨されます。そのまま鵜呑みすると 16G は欲しいネ、という事ですが、 ロールバックする対象はそれほど多くないですし、システムをロールバックするという事も滅多にありませんから 10Gb もあれば余裕でしょう。

SUSE Linux Enterprise Server 12 SP3 導入ガイド

なお、パーティションを分けた場合、 "/" ルート以外のパーティションは XFS がデフォルトになります。database などのロールバックが予測されるシステムでは BtrFS を使う事になります。

パーティションの構成を替えたい場合はここで "Expert Partitioner" を開きます。ここではデフォルトでそのまま進めます。


a0056607_07154653.jpg


タイムゾーンの設定です。世界地図から日本らしきところをクリックすると Asia/Japan が選択されます。

”Hardware Set to UTC” のチェックは外す事にしています。これはOSと CMOS クロックを UTC で同期させる機能なのですが、UTC で起動されると困る仮想サーバー(Windowsなど)のためのハイパーバイザー運用では、見事に9時間早くなってしまうので、このチェックを外して JST 運用することにしています。"UTC にしないのはどんなものなんでしょうね" という感じの警告を確認して次へ

a0056607_07164652.jpg


オペレータのフルネームとユーザ名、パスワードをセットします。

a0056607_07191429.jpg

root のパスワード設定です。必ず ”Test Keyboard” で特殊キーや NUM Lock のチェックをします。なお、パスワードとテストフィールドでテストした単語はシンクロしません。あくまでもテストのためのフィールドです。

a0056607_07211547.jpg


サマリ画面からデフォルト状態をいくつか修正します。

Firewall : Disable(Default Enable)
SSH : Open(Default Close)
Kdump : Disable (Default Enableカーネルダンプが必要なクリティカルなシステムでは Enable にしておくのが良いでしょう)
どうせコンソールは使わないので Systemd target : Text (Default Graphical )
その代わり gnome や yast2 などのパッケージはインストールされます。

a0056607_07222194.jpg

インストールが開始されます。

a0056607_07225418.jpg
ハードウェアの性能によりますが10~20分程度で自動で再起動します。

- 再起動 -

a0056607_07235405.jpg

再起動でログインプロンプトが出てくればOK


a0056607_07243573.jpg
あとは、IP アドレスの固定と NTP の設定をすれば、サーバーの基本的なインストール作業は終わります。この手順は SLES12 SP2 と同じです。

SUSE Linux (SLES12)  YaST で固定 IP アドレスの設定をする

SUSE Linux (SLES12) を YaST で NTP の設定

SUSE Enterprise Server 12, Ctrl+Alt+Del で誤って reboot させないようにするには


- インプレッション -

SLES11 より、インストール全体は簡素化されていますが、省略された分、後で設定すべきことが沢山出てきます。やはり initd より systemd による、起動/終了の高速化は素晴らしいと思いました。どれほど変わったか、細かな設定などはもう少し照査すべきですが、従来の SLES12.x とあまり変わらないな、という印象です。ここから本格的に評価したいのですが、使えるPCがないので、ハイパーバイザー運用より当面は仮想サーバーとしての評価になります。ちなみに、SLES11 の XEN 環境からもインストールできたのですが、 Full Virtual でないと動かないという問題がありました。恐らくブートアッププロセスにチューニングが必要なようです。当面は USB ブート用の環境でのテストもやってみたいところです。






- Keyword -

SUSE Linux, SLES12, SLES12sp3, インストール, 導入, 手順, DVD ブート, USB ブート, Howto


[PR]
by islandcenter | 2017-09-29 07:51 | SUSE | Trackback | Comments(0)

今回は SUSE Linux Enterprise Server 12 (SLES sp2) で PHP スクリプトを HTTP サービス を動かす方法を説明します。 SLES11 までは Web LAMP をインストールするだけで HTTP サーバーで PHP スクリプトを動かす事ができたのですが、 SLES 12 以降はちょっと面倒になりました。マニュアルにも記載がなかったり、誤記があるようなので、細かい所のご指摘があればコメント下さい。なお、この記事は参考程度に見てもらえればありがたいです。

公式には評価版ではなく、E-Media でインストールしたうえでアクティベーションしてサポートを受けることをお勧めします。

今回は第一言語 English の CUI 版 yast を使って作業をしてみました。 X が使える環境であれば yast2 を利用しても、日本語第一言語でもほぼ同じ操作です。

SUSE Linux Enterprise Server 12 SP3 管理ガイド

31.4 モジュールのインストール、有効化、および設定


SLES11 はこちらを参考にしてください。

Apache のインストールと設定まで30秒、SUSE Linux はこんなに簡単

- はじまりはじまり -

まずは YaST から

# yast
> Software > Software Management

を開きます。

a0056607_12351213.jpg


ここで Web and LAMP をチェックして、まとめてインストールします。

Filter > をトグルして "Patterns"


a0056607_12355694.jpg

"Web and LAMP server" をスペースキーでチェック > Acceptします。


a0056607_12361986.jpg

依存性のあるパッケージを確認して”OK”


a0056607_12363810.jpg


インストールが始まります。> Finish

a0056607_12365531.jpg

HTTPサーバーの細かな設定をします。

# yast
> Network Servece > HTTP server


a0056607_12390355.jpg

Wizard に従い”Next”

PHP5 Scripting を Enable にするため、選んで、スペースキーでチェック(敗因)


a0056607_12401312.jpg

※ 敗因 SLES11 までは、このチェックだけで apache2_mod_php5 がインストールできたのですが、SLES12 より PHP5 は Evaluation DVDから削除されたようです。マニュアルも、この指示通りでしたが動きません。評価版ではなく、アクティベーションした場合はまた違う動きがあるかも知れませんね。かと言って、開発途中でアクティベーションするのも何だか勿体ない。

詳しい理由は判らないのですが、PHP の様々な不具合により、サポート対象となっていないようです。php5 は openSUSE のリポジトリからインストールできるので、これは後述します。

オプションの確認、ここでは特に何も変更はありません。


a0056607_12403854.jpg

Virtual Host の設定、特にやることもないので、空欄のまま Next

a0056607_12411300.jpg

Start Apache2 server When Booting をスペースキーでチェック

a0056607_12413566.jpg

Apache2_mod_PHP5 が追加でインストール(敗因 - 実態は何も起こりません)

a0056607_12415786.jpg

一応インストールされた様に見えますが、実は YaST > Software Management で "Search" しても、php5 はリストされません。

ブラウザから、デフォルト index.html を開きます。

sles12:~ #
sles12:~ # w3m 192.168.1.199
sles12:~ #

a0056607_12422273.jpg

apache は動いているようです。

- PHP5 のインストール -

apache2_mod-php5 は openSUSE のソフトウェアページからダウンロード、インストールします。

FireFox ブラウザから


より PHP5 を "package Search"


を開き SLE12 > "PHP5.5.3.xx を "1 Click Install します。

a0056607_12430720.jpg

SUSE SL"12 を開き home:onzi をYaST 1-Click Install > OK

リポジトリの追加

a0056607_12434363.jpg

2017/9 現在 SUSE:SLES-12:GA/standard のレポジトリは実体がなく、エラーになるのでスキップして構いません。

インストールされるソフトウェアパッケージを確認して

a0056607_12450236.jpg

一応警告を確認して OK  (2017/9 現在、他にも途中エラーが出ますが無視しました)

a0056607_12452714.jpg

GNUpg_Key を "Trust" します。

a0056607_12455304.jpg

リポジトリが登録されたので YaST Software Management > Search > "apache" を検索し apache2_mod_php5 をスペースキーでチェック、インストールします。


a0056607_12462718.jpg

依存性のあるパッケージを確認して OK


a0056607_12464583.jpg
Finish

- apatche のサーバーモジュールの有効化 -

# yast
> Network Service > HTTP Server から "Server Modules" タブを開いて "php5" を選び "Toggle Status"Enabled に変更します。

a0056607_12470707.jpg

※ ここまでは E Media でも同じなのですが、E Media では Enable にはなりませんでした。結局 openSUSE のリポジトリからインストールして apach2_mod_php5 が結果OKという事になります。


簡単な /srv/www/htdocs/index.php を作成してみます。

a0056607_12472567.jpg

- ディレクトリインデックスの修正 -

/etc/apache2/httpd.conf にデフォルトファイルとして index.phpindex.htm を追加します。

sles12:~ # vi /etc/apache2/httpd.conf

: 編集中

sles12:~ # cat /etc/apache2/httpd.conf | grep DirectoryIndex
DirectoryIndex index.php index.htm index.html index.html.var
sles12:~ #

これで、ブラウザから URL でディレクトリを指定すると、index.php > index.htm > index.html > index.html.var の順で、ディレクトリのデフォルトページを表示します。HTTP サーバー全体を PHP で記述する場合、これで、ディレクトリ指定だけで index.php が最初に開かれる事になります。また html ではなく index.htm を記述したので、よくある Windows 用のオーガナイザーで作られる、htm 3文字拡張子にも対応できます。
apache2 を再起動して、デフォルト index.php が優先して、開けるか確認してみます。

sles12:~ # rcapache2 restart
sles12:~ # w3m 192.168.1.199
sles12:~ #

a0056607_12474880.jpg

PHP スクリプトが実行されました。

- あとがき -

SLES11 の場合は、このあたりは何の悩みもなくできましたが、SLES12 以降はかなり制限が厳しくなっています。理由は何となく想像するしかないのですが、マニュアル、ドキュメントの不備はちょっと不満があります。なお、MySQL はインストールされず mariadb がインストールされます。

a0056607_12480785.jpg

ちょっと SLES11 とは手順が違い、結局 openSUSE のリポジトリからインストールする結果になってしまいました。実際には、評価版である程度 Web サイトのデザインを作って、顧客から発注を受けたところでアクティベーションする事が多いと思います。

実際に MySQL も mariaDB に置き換わっていますし、このあたりは、SLES12 の新しい方針を示すものでしょう。従来の PHP+MySQL の環境で作業をする場合は SLES11 の方が良いかも知れません。新しい技術を身に着けたい場合はやはり SLES12 を選ぶことになります。



-Keyword-

SUSE Linux、SLES12, Apache HTTP サーバー PHP, PHP5, スクリプト、インストール, 有効化, 無効化, enable, disable, SLES11との違い











[PR]
by islandcenter | 2017-09-25 13:23 | SUSE | Trackback | Comments(0)

ここでは SUSE Linux Enterprise 12 (SLES12) を使って、YaST ツールから ntpd の初期設定の手順を説明しています。 openSUSE も大体似たようなものなので参考にしてください。

- はじまりはじまり -

今回は主に GUI 版 YaST (yast2) を使って説明します。キャプチャ画面は英語ですが、これは第一言語を英語にしているからで、第一言語が日本語であれば、一応日本語メニューも出てきます。(でも何だか英語版の方が私にはほっとするんですね)一部 CUI 番 yast のキャプチャがありますが、機能は全く同じです。

ntpd のインストールは YaST を起動して、"Network Services" > "NTP Configuration" を選ぶと自動的にインストールが開始されます。

a0056607_15591361.jpg

まれに YaST メニューに "NTP Configuration" のアイコンがない場合があります。"Software Management" から "NTP" をキーワードに "Search" して "yast2-ntp-client" のチェックが入っているかどうか確認します。チェックが入っていない場合、チェックして、 NTP Configuration ツールをインストールします。もちろんここから ntp のデーモンもチェックしてインストールしても構いません。チェックを入れたら、いったん YaST を終了して、もう一度 YaST を立ち上げるとメニューに出てきます。

a0056607_16001458.jpg


インストールが終わると、設定画面が自動的に開きます。 "Start NTP Deamon" が "only Manually" となっているところを "Now and on Boot" に設定しなおします。

※ この時点で 
0.opensuse.pool.ntp.org,
1.opensuse.pool.ntp.org,
2.opensuse.pool.ntp.org, or 3.opensuse.pool.ntp.org
の3つがデフォルトで NTP ソースとして選択されるようです。

Configuring an NTP Client with YaST
https://www.suse.com/documentation/opensuse121/book_opensuse_reference/data/sec_netz_xntp_yast.html



a0056607_16011410.jpg
まず "Security Settings" タブを開いてください。"Run NTP Deamon in Chroot Jail" にデフォルトでチェックが入っているはずです。たまに入っていない事があるので、確認します。もう一度 "General Settings" タブを開きます。

a0056607_16020532.jpg

初期値には "Synchronization Type" : "Undiscriplined Local Clock" が指定されています。この画面は別なベアメタルサーバーで見た CUI 版 YaST の設定画面です。

a0056607_16025029.jpg

ここで、重要なことは、

1 - ntpd が起動する時に "Undisciplined" な "設定されていないローカル時刻" をソースとする、つまりハードウェアクロックをソースとするかどうかです。SUSE をハイパーバイザー運用のためにインストールする場合など、 ntpd が起動する前に、"Orphan 状態"、つまりネットワークに繋がっていない"孤独な状態" に使用するものです。信頼できなくてもハードウェアの CMOS クロックをもらうようなので、まだネットワークが行動していない ntpd が起動していない、あるいは、ネットワーク障害が発生している時やブート時のログには、あまり正確とはいえないまでも、ローカルクロックで立ち上がってくれるわけです。ベアハードウェア上のサーバーは、この行をとりあえず残しておきます。

Undisciplined Local Clock

IDEA! The Undisciplined Local Clock should generally no longer be used.

とある様に、将来的にはサポートされない手段になるものです。

2 - このシステムが XEN や KVM, Hyper-V などで動作する場合は、”Undisciplined Local Clock”Delete します。

openSUSE のマニュアルなのですが、

第2章 KVM の制限事項

"時刻同期"

"多くのゲストでは、時刻を正確に維持するのに追加のサポートを必要とします。 利用可能であれば、 kvm-clock を使用してください。 それ以外にも NTP やその他のネットワークベースの時刻同期プロトコルを利用し、 安定した時刻を維持することを強くお勧めします (VM ホストサーバ と VM ゲスト の 両方に対して) 。ゲスト内での NTP は、 kvm-clock を利用している場合には推奨されません。詳しくは 8.7項 「時計の設定」 をお読みください。"

とあり、仮想環境下では、ホストOSからのハードウェア時刻同期は推奨されません。暗に ntpd が推奨です(と読めます)。そこで、仮想運用する場合、タイムソース "Undisciplined Local Clock" を削除して ntpd の設定は必須の事となります。

- タイムソースの追加 -

ntpd にタイムソースを追加します。”Add” ボタンを押して "Server" を選び Next

a0056607_16040057.jpg
"Address" の右にある、"Select" リストから "Public NTP Server" を選び、地域 "Japan" にある NTP ソースのリストが出てきます。 SLES12 の用意した List の中には NICT と "jp.pool.ntp.org" のリストが出てきます。SLES11 までは、jp.pool.ntp.org と福岡大学の NTP ソースがリストされました。

a0056607_16041880.jpg

1- セレクタを使わないで、オリジナルの NTP ソースを使う場合、"Server Settings" の "Address" 欄には、直接サーバーのアドレス ”ntp.nict.jp” とか "ntp1.mylocal.net"、”192.168.1.123” のように記載できます。一応 IP 直アドレスでも構わないのですが、FQDN 名で設定すべし、という事になっています。

社内向けのDNSサーバーがある場合、DNSサーバーの CNAME に LAN内 NTP ソースとなるレコードを追加しておくのが良いでしょう。

 ※ ちなみに time.windows.com とも同期できましたが、世界何億台が参照するため、滅茶苦茶時間がかかりました。できるだけ経路の短い国内の公開サーバーか、契約先ISPが提供する NTP サーバーを利用すべきでしょう。有名だからと言って、昔、人気があった福岡大学の NTP は様々なシステム機器のデフォルトで、トラフィックと遅延問題が大きく、あまりご迷惑をかけないように利用を控えた方が良いようです。(今は学内のみ利用可能なようです)


2- 公開NTPサーバーや ISP の指定 NTP を使うのは、ローカルネットワーク内部の2~3台までとして、他のシステムやWindows などのPCはこのローカルLAN内のNTP参照をすべきでしょう。(と言っても Windows が time.windows.com をデフォルト参照先になっているのはやっぱり問題ですよね)

NICT のFAQによくまとまっています。他、mfeed.ad.jp やリングサーバープロジェクトなどに、専門家が書いた使い方が載っています。この零細出鱈目ブログよりよっぽど為になりますので一読してください。

NICT公開NTP FAQ

インターネットマルチフィード(時刻情報提供サービス for Public)

NTP service : ntp.ring.gr.jp

どうやったらpool.ntp.orgを利用出来るのでしょうか?

NTP Download (Meinberg 氏による Windows 用 ntpd のバイナリ配布先)

3- NTP のプロトコルは 123 番ポートでほぼ UDP だそうです。ただ RFC のドキュメントには UDP の記述しかないので、TCP を使っても構わないようですが、かなり希少な存在なようです。ファイアウォール屋さんと相談の上、穴をあけてください。

「NTP のポート番号と UDP か TCP かどちらか教えろ」と質問してきた信じられない自称プロトコルの専門家、ファイアウォール担当の SI 屋が居ましたが、今なら首を絞めて教えてあげたい。というか、当時は Google 先生もいないし、マニュアルにもポート番号の記述しかなく、そんなことも知らなかった私が一番悪いんですけどね。

4- NTP の問い合わせは「行って」「帰って」の経路が同じものと想定して、その時差の真ん中あたりが、NTPソースサーバーが返した時刻だと補正の判断をするそうです。だからなるべく「行って帰って」の経路が単純で短い NTP ソースを誤差なく使うべし、という事です。他の海外製ディストリビューションでは、インストールした後のデフォルトが、海外にある自社の NTP プールを指定していることが多いようですが、あまり好ましいものではないでしょう。

ここで "Test" ボタンを押して、軽快にレスポンスが返ってくれば、NTPソースとして利用可能です。

a0056607_16044994.jpg
これをタイムソースとして利用するサーバー複数個を指定します。LAN 内サーバーであれば、内部にあるNTPサーバーを複数と、予備にISP指定の NTP サーバーや、nict や mfeed などの公開NTPサーバーを指定するのが良いでしょう。

"Display Log" ボタンから、 "Advanced" > "Save Settings and Restart NTP Deamon" を選ぶと設定内容が保存され、ntpd が起動します。

a0056607_16051267.jpg
ntpd は大きな時刻ずれを検出すると minpoll 64 秒の短い間隔から "徐々に時刻を正確なものに寄せて” このチェック間隔も広げます。さもないと、スケジューラをすっ飛ばしたりするような、予期せぬ動作が起こってしまいます。

おおよそ安定してくると Stepping Mode から Slew modeとなり、デフォルトで 1024 秒間隔で時刻ずれをチェックします。このあたりの詳細は


で確認してください。

なお、SLES12 (spなしの初期版) では apparmor の不具合らしいバグがあるため ntpd の起動に失敗します。

SLES12 ntpd が Fail 起動できない <とその解決方法

簡単に修正できるので、参考にしてください。


SUSE Linux, SLES, SLED, NTP 設定方法, YaST,




[PR]
by islandcenter | 2017-09-21 16:24 | SUSE | Trackback | Comments(0)

ここでは SUSE Linux (SLES12) をインストールした後、DHCP のランダムな IP アドレスを Static IP に固定する手順を説明します。
SLES/SLED/openSUSE のバージョンによって、若干違う場合がありますが、ほとんど共通のインターフェースなので簡単に設定することができます。


テキストコンソールの場合は
# yast

もしくは X 環境では gnome デスクトップの Computer アイコンから YaST の GUI 版を使います。テキストターミナルを開いて
# yast2 &

で GUI 版を開くこともできます。

ここでは主に CUI 版 YaST で説明します。

- はじまりはじまり -

※ ここでは、第一言語 English, 第二言語 Japanese で設定されていますので、なのでキャプチャ画面は表記は英語です。第一言語が Japanese だと訳の分からない変な”ニッポン語”でメニュー表記されるし、 ALT+ ショートカットキーもわかりづらいですし、それをまた英訳するのも面倒なので、サーバー運用に問題がないのであれば、英語で設定しています。

CUI 版 yast の操作は、ほとんどが TAB, カーソルキー, Space キー、 Enter キー、あるいは ALT+alphabet キーで操作します。第一言語がニッポン語の場合は、 ALT+Alphabet が分かりにくいので、やっぱりここは英語版がいいでしょう。

# yast から[Tab] キーで System > Network Settings を[Enter]開きます。

※ SLES11 までは Network Devices > Network Settings でした。

a0056607_16015344.jpg

Overview の Network Bridge (br0) が初期値 "DHCP" になっています。Device eth0 は IP アドレス "NONE" となっていますが、このデバイスは None のまま変更しません。SUSE Linux では "実NIC(ethX)" <-- "Brigde(BrX)" でブリッジ接続するため、 ethX は無設定、固定 IP の割り当ては BrX に行います。

ここでは br0 に対して設定します。"Edit" します。

a0056607_16031896.jpg

環境によっては物理NIC (Eth0) しか表示されない場合があるので、 Eth0 の設定を "Delete" して "Add" ボタンから、Brige ネットワークが構成できます。その際も Eth0 は設定なし(NONE) br0 に IP を設定します。必要なブリッジネットワークの構成ツールが自動的にインストールされます。

物理NIC が複数ある場合、 "Add" メニューから Bridge ネットワークを追加します。これは GUI 版 YaST の画面です。

a0056607_16034437.jpg

”Bridged Device” (BrX) にどの物理 NIC を繋げるかを選んでスペースキーでチェックします。ここでは一つの物理 NIC しかないのですが、NIC の複数差しの場合、 br0 --> eth0, br1 --> eth1 .... という感じで、異なる構内LANと管理用物理配線、あるいは SAN 用配線に割り当てることができます。

a0056607_16041999.jpg

DHCP から Statically Assigned IP Address に固定IP、サブネットマスク、インストール時のデフォルトランダムな Hostname の書き換えをします。

a0056607_16050452.jpg

例えば、 XEN や KVM などの仮想化システムのホストとして運用する場合、ホスト本体は内部の管理ネットワークやストレージ LAN だけに繋ぎ、仮想システムは公開ネットワークに繋げる、などの柔軟な運用で、仮想システムを非公開ネットワークだけに繋いで保護する事ができます。

"Hostname/DNS" を開き、 ランダムな初期値の "Hostname" と ”Domain Name” を、目的の環境、命名規則に合わせて変更します。

"Name Server 1,2,3" に、必要な DNS サービスの IP アドレスを与えます。

この作業でYaST を終了すると /etc/resolv.conf と /etc/HOSTNAME が更新されます。

a0056607_16054048.jpg

”Routing” を開いて "Default Gateway" の IP アドレスを設定します。

a0056607_16060699.jpg
[OK] ボタンを押して、設定を保存すると、設定ファイルの書き換え、ネットワークの再起動が行われます。

- 確認 -

ifconfig と ping で通信確認をします。この様な感じで ifconfig で brX に IP アドレスが割り当てられればOKです。恐らく、ping も成功するでしょう。

sles12:~ # cat /etc/HOSTNAME
sles12.intra

sles12:~ # ifconfig

br0 Link encap:Ethernet HWaddr 00:16:3E:24:71:21
inet addr:192.168.1.199 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe24:7121/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:699 errors:0 dropped:0 overruns:0 frame:0
TX packets:203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41287 (40.3 Kb) TX bytes:19384 (18.9 Kb)

eth0 Link encap:Ethernet HWaddr 00:16:3E:24:71:21
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:805 errors:0 dropped:0 overruns:0 frame:0
TX packets:207 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:49634 (48.4 Kb) TX bytes:19732 (19.2 Kb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:38 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:2888 (2.8 Kb) TX bytes:2888 (2.8 Kb)
sles12:~ #

- 再起動 -

コンソールからログオンすると、プロンプトが初期値のランダムな HOSTNAME なので、一旦リブートします。

- よくあるトラブル -

"あれ ???? ping が飛ばないよー”とここでハマることがよくあります。

ifconfig で lo しかなく、 br0 に何も IP アドレスが出てこない場合、Bridged Device が、実装されている NIC とのチェックが外れていることがほとんどなので、ブリッジネットワークと、実NICの接続をチェックします。ここのチェックを入れ忘れる事が多いので注意してください。

これは、GUI 版 YaST のネットワーク設定の画面です。

また、複数 NIC を装着した場合、物理 NIC brX 仮想ブリッジを間違えてチェックしてしまう間違えも、よくある間違えです。実際のケーブリングと、物理ポートを確認してください。

a0056607_16064178.jpg

この様に、 SUSE Linux でのネットワークの設定は YaST で行うのが一番漏れもなく、確実であること。また、驚くほどタイプする作業がありません。

--
ほとんどの場合、SLES はサーバー運用になるので、Text Mode での起動となるでしょう。X 環境が使える場合は、 Windows などから GUI 版 yast2 を使ってもいいのですが、CUI テキスト版 yast コマンドの方が、軽快なので、ほとんど CUI 版を使う事になると思います。

インストール後の DHCP から固定IPへの変更は、 SUSE Linux では一番最初に行う作業でしょう。ここで YaST の使い方を覚えておけば、後の設定も楽です。


SUSE, SLES, openSUSE, DHCP 固定 IP の設定, Howto, YaST, ネットワーク設定,





[PR]
by islandcenter | 2017-09-20 16:10 | SUSE | Trackback | Comments(0)

地味で意味不明のKSKロールオーバー

総務省の「勧告」があり始めて知りました。


※ DNSについては「知っている」程度の知識なので、このブログの内容は内容は丸のみしないように.....関連文書はごっちょり出ています。

ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバーなど設定確認を! 今年9月は特に注意

影響があるのは、DNSサーバーを運用しているネットワークで、管理者は「何それ」と言って「朝日新聞」以外の大手メディアは「狼が来た」程度で、騒いでもいないので、突然の対策に苦慮しているようですね。

企業LAN、ネット遮断のおそれ 総務省が確認呼びかけ

詳細はこちら

KSKロールオーバーについて(JPNIC)

-まず DNSSEC-

大抵、一般企業のゾーン mycompany.com には www, mail, mydns など自社の社外向けサービスが、ISP の DNS マスターに記載されていて、企業の mydns は、ISP のマスターからゾーン転送を受けるスレーブとなって、もし、ISP の DNS が停止する場合のバックアップになります。逆に自社オンプレミスのDNSサーバーがゾーンマスターのケースもあります。

しかし、この二つは、お互い IP アドレスだけで信頼関係があるので、万が一、相手が「なりすましIP」を使うと、DNSのゾーン転送がうまく行かなくなり、メールの誤転送や、フィッシングサイトへ引き込まれたりします。そこで DNSSEC という鍵交換方式で相手のDNSが正しいかどうかを検証するのがDNSSEC という事らしいです。

. (ドット)のルートゾーンから、.jp -> .co.jp -> mycompany.co.jp までそれぞれゾーンを管理する団体が違うので、その間、どのような経路を通るのか分からないので DNSSEC を使ってお互いを確認しあう仕様になって7年目。本来、5年でルートゾーンのKSK 電子鍵 "Key Signing Key" を更新する予定だったのが、色々調整に手間取り、いよいよルートの鍵更新をするのがこの秋ということなのです。そもそも DNSSEC 自体、実装され始めて10年と経っていないDNSの保護対策なので、ワタシのように「古いエンジニア」には何がなんだかさっぱり。そもそも閉じた環境では 古いDNSサーバーをそのまま使っている場合、DNSSEC自体実装していないケースも多いようです。最新の Bind DNS では、 DNSSEC 自体デフォルトで Auto となっているケースがあるようなので、それぞれのディストリビューションに問い合わせて対策する必要がありそうです。

で、SUSE のマニュアルしらべてみましたが、named.conf の ”dnssec-validation” のパラメータの記述さえありません。勿論 YaST のオプションにも設定項目なし。逆に、dnssec の validation 機能の脆弱性情報に載っていたくらいなので、一つの脆弱性があれば、また次にも見つかる機能なので、無理して使わないのが、無難なのでしょうかね。

もともと私が愛用している Bind の教科書にも DNSSEC については、ほとんど記述がないほどの機能ですから、大多数意見では DNSSEC 自体は設定する必要はまず無いようです。上位 ISP にも問い合わせてみたら、「DNSSEC は無効にしている」という回答。そもそも資料も少ないですから。というか DNSSEC 無用(悪機能)論もあるくらいだから、ほとんど一般の管理者にとっては無視するのも仕方ないのかなと思います。DNSSEC は日本では 2017 年現在 10% 前後しか普及していないらしい論もあります。そもそもそれほど通信事業者間、公共団体で普及していないものを、取り出して「ああ、こう」言っても、聞く耳がないのも仕方がない事です。

- それでも起こるDNSのトラブル -

それでも上位ISP同志で鍵交換をする、この秋に、一般的なDNSクエリ以上のパケットサイズの通信が起こり、通常 1280 バイトのDNS更新情報が、1424 バイト程度まで膨らんでオーバーフローして情報が正しく伝わらない現象が「KSKロールオーバー」という現象です。この影響は全インターネットユーザの1/4程度が影響される可能性があるということなんですね。これほどの大袈裟な影響なのに、一般に認知されていないところは、ずいぶん疑問符が出てきます。

これによって、相手のウェブサイトの名前解決ができない。名前解決ができないため、メールが転送できない、という現象が大本営発表によると発生する(らしい)のですね。

実際に、SOHO向けルータのDNSサーバーを使っているワタシの様な零細事業者とか、スレーブDNSを自社にオンプレミスで運用しているとか、DNSについてはド素人なワタシのようなSI業者なんかがiDC の中の顧客のサーバーの面倒を見ているような場合は、「KSKロールオーバー? 何それ?」という事になり、ろくな知識もないまま慌ててしまう事になるわけです。

1) 確認方法

1-1) bind dig コマンドで dns の reply size limit の値をチェック

reply size limitの値が1424より大きいこと

sles11:~ # dig @dns2 +bufsize=4096 +short rs.dns-oarc.net txt
rst.x1008.rs.dns-oarc.net.
rst.x1968.x1008.rs.dns-oarc.net.
rst.x2454.x1968.x1008.rs.dns-oarc.net.
"173.194.171.12 sent EDNS buffer size 4096"
"173.194.171.12 DNS reply size limit is at least 2454"
"Tested at 2017-09-05 03:27:22 UTC"
sles11:~ #

※一発で答えが返らない場合もあるので2、3度繰り返してみてください。

1-2) DNSSEC Key Size Testのサイトでテストする。

にアクセスして、Result の 1~4が Pass していること、5は(This should fail なので) パスしないはず。
a0056607_13383419.jpg
以上で問題がなければ、一応、KSK ロールオーバー対策は「準備OK」という事になるそうです。

問題がある場合、上位ISPの DNS のプロに問い合わせて対策するのが一番のようですね。もっとも、「影響なし」と公表しているISPも少ないので、みんな知らないのも当たり前なのかも知れません。

2) DNS は最新版を

DNS サーバーはいったん設定を済ますと、中々中身をイジリたくないシステムです。でも Bind というソフトウェアはバグや脆弱性が多い事でも有名なソフトウェアなので、Bind を最新版に更新した方がいい。という事になります。

それにしても、この問題があまり大きく IT 関連のメディアにすら載らないし、ほとんど JPNIC と大本営総務省発表のコピペ記事で、具体性に欠けるのが最大の謎だったりします。

ご意見ある方のコメント期待しています。


KSKロールオーバー, DNSSEC, dnssec-validation, 無効化, 有効化




[PR]
by islandcenter | 2017-09-05 13:40 | SUSE | Trackback | Comments(0)

- 目的 -

全社、あるいは多くの部署で読み書き可能だったファイルサーバーのフォルダのアクセス権を特定の部署、あるいはグループに特定できるように変更したい。

- OES Linux での操作 -

次の OES ファイルサーバーのフォルダ VOL:test には O=ACE(組織全部)と Yoiko.Uses.Osaka.Ace(グループ)に権限が与えられています。

既に O=ACE に [ RWCEFM ] の権限が与えられているため、全社 O=ACE がこのファイルサーバーのフォルダを読み書きできる状態です。グループオブジェクト Yoiko.Osaka.Ace にもトラスティが与えられていますが、この権限はこの場合は余分です。
a0056607_11070253.jpg
したがって、OES ファイルサーバーの VOL:test には グループに関係なくすべてのユーザに権限が与えられています。

これを Users.Tokyo.ACE の OU にのみ解放したい場合 ....

いったんすべてのファイルサーバーの権限を削除して、
a0056607_11072836.jpg

特定の部門、グループにだけ権限を与えます。ここでは Users.Tokyo.Ace に権限が与えられ、Osaka.Ace には与えられていません。全社からではなく、一部の部署がファイルサーバーの特定のフォルダにアクセスできるようになります。

a0056607_11075388.jpg
これで Osaka.ACE のユーザには権限が与えられなくなります。

※ただし、ログインスクリプトで map f:=VOL: などの記述があると、全くボリュームに権限がないと、マップエラーになります。本来であれば、権限がない時点で map のスクリプトを削除するのがベストですが、何か理由があって、ログインスクリプトに手を加えたくない場合は、dummy ファイルを置いて、[ F ] 権だけを与えたファイルを作っておくと良いでしょう。

試しに VOL:dummy.txt のユーザに [ F ] 権のみ与えてみると、東京では見えるフォルダは見えませんし、F権のみなのでフォルダを見ることはできても中身を確認することができません。

a0056607_11081955.jpg
Windows のファイル共有と違って、OES のファイルサーバーのアクセス権(トラスティ)の割り当ては、一か所変えるだけで、メタファイルを一か所変えるだけなので、一瞬で終わります。フォルダの中にどれほどサブフォルダやファイルがあっても、ディレクトリとファイル全体の権限をスキャンして変更しませんので、ファイルサーバーの負荷はほとんど0%です。Windows ファイルサーバーでは数分から数時間かかり、ほとんどその間は、ファイルサーバが利用できない激重状態になります。

次のデモビデオでは、数万ファイルの大量のデータのアクセス権を変える操作を Novell OESでは一瞬、 Windows ファイルサーバーでは30分以上かかり、その間、ほとんどサーバーが使えなくなっている様子を比較したビデオクリップです。

Novell versus Microsoft: Granting Access Rights



また、権限のない不可視のフォルダ共有はエクスプローラにも表示されないため、共有サーバー上に数百、数千の読み書き不可の共有ディレクトリがあっても、ファイルサーバーが返すディレクトリ情報のポケットは「権限のある」ディレクトリだけなので、ネットワークの負荷が少なく高速に表示されます。



- keyword -

ファイルサーバー アクセス権限 変更 共有フォルダを見せない フォルダのアクセス権限を変える 遅い 重い ファイルサーバーの負荷100%

[PR]
by islandcenter | 2017-07-19 11:23 | OES Linux | Trackback | Comments(0)

すっかり落ち着いてしまったようですが、世間が wannacry ランサムウェアで大騒ぎしていた頃、気になる記事を Gigazine に見つけました。

Gigazine

Windows XPでランサムウェア「WannaCry」の被害が少なかった一因は「ブルースクリーン・オブ・デス」

"WannaCryは「MS17-010」で報告されている、Microsoft Windows SMB サーバーというWindowsのファイル共有システムの脆弱性を利用して広がりましたが"

Gigazine のこの記事によると、 wannacry については Windows XP に感染する前にブルースクリーンになり拡散に失敗するケースが多く、 Windows10 では比較的被害が少ないし、Windows8x 系はそもそもサンプルが少ないので、実際に感染したコンピューターは Windows7 の SMB なんだろうなぁ、という事がぼんやりと気になっていました。

そこで SMB のバージョンについて調べてみました。まぁまぁ良く整理されている記事がこちら。

第7回 ファイル共有プロトコルSMBの概要

そこで wannacry に関する情報を探ると出てくる出てくる。Windows サーバーから、おなじみの samba も影響があるのですね。


- 一番初めに試した対策 -

ほとんどどこでも言及している「SMB 1.0/CIFS のファイル共有のサポート」 デフォルト・イネーブルを削除してみました。

ランサムウェア WannaCrypt 攻撃に関するお客様ガイダンス

「コントロールパネル」>「プログラムと機能」> 「Windows の機能の有効化または無効化」から "SMB 1.0/CIFS ファイル共有のサポート"のチェックを外します。後は「再起動しろ」と言ってくるので、再起動します。すごく再起動に時間がかかります。

a0056607_17592725.jpg
再起動すると見事に samba サーバーが「ネットワーク」から消えました。\\IP\Share_name でアクセスもできません。

全滅

です。

という事でこいつ(SMB1.0/CIFS .....)は元にもどす事になりました。つまりはこれも拡散を防ぐための一時的な対策に過ぎません。

- samba サーバー側で対応してみる -

==========
Workaround
==========

Add the parameter:

nt pipe support = no

to the [global] section of your smb.conf and restart smbd. This
prevents clients from accessing any named pipe endpoints. Note this
can disable some expected functionality for Windows clients.

という事だそうです。

smb.conf — Samba の設定ファイル
によると

nt pipe support (G)

この真偽値パラメーターにより、 smbd(8) が Windows NT のクライアントに対して、 Windows NT の SMB 固有の IPC$ パイプへの接続を許可するかどうかが制御される。 これは開発者のデバッグオプションであり、意識する必要はない。

既定値: nt pipe support = yes


意識する必要はないとはありますので、とりあえず 手元の SUSE Linux SLES11 で設定してみます。

yast(or yast2) > Network Service > Samba の Identity タブ Advanced Setting からこの Expert Global Settings を書き換えます。

a0056607_18000345.jpg

Add ボタンで "nt pipe support" にチェック(デフォルト)が入っているので、このチェックを外すと smb.conf が書き換えられます。この状態で yast でOKすると samba が再起動します。

a0056607_18003739.jpg

ところが

a0056607_18010151.jpg

見事にアクセスが拒否られます。また Windows7 とサンドボックスの Windows XP も見事アクセスが拒否されました。
つまり

nt pipe support = no

パラメータはあくまでも一時的なものであり、根本解決には至りません。

という事で SUSE から出ているパッチを探してみました。これの様です。

- SUSE のパッチ -

CVE-2017-7494

結構メンド臭そう。やっぱり公式リポジトリからセキュリティ系のアップデートを全部パッチするのが正解の様です。

怖いのは、Linux のディストリビューション各社はパッチをだしているのですが、よく国道沿いのディスカウントショップで「家族計画用品」の隣で売られているご家庭製品専門のメーカーで出しているような、「なんちゃって我が家のNAS」みたいなものがパッチを出していなかったり、当てるのも面倒だったり、そもそも wannacry に対策しているかどうかもわからないところですね。


ということで

第一段階

SMB1.1/CIFS の利用をやめて Samba や NAS の使用を停止して、エンドユーザに総スカンを食らう
その間にパッチを全部確認する。

第二段階

手に入る限りの Windows パッチ、Samba パッチを当てまくり、リブートしまくり、ついでにあちこちでトラブルが出て、みんなに総スカンを食らう。

第三段階

PCを「安全性が高い」とマイクロソフトが豪語する Windows10 と Windows 2016 Server にリプレースして、SMB3.11 にアップデートして samba も 4.x にアップデートして SMB3.x のみサポートして、動かないアプリケーション続出しまくり、繋がらない古いPCユーザから総スカンを食らい、金をかけた効果はあったのかと経営者に詰問されて、辞表を書く。

というのが対策の手順となりそうです。




- Keyword-

wannacry, 対策, Windows10, Windows7, samba, SMB, CIFS, Linux, 脆弱性



[PR]
by islandcenter | 2017-07-10 18:08 | プライベートクラウド | Trackback | Comments(0)

このブログで「如何にして Linux は SUSE Linux の事しか書かないのか」という疑問を読者の方がお持ちだと思います。私は、「他人と違う事をやらねばITエンジニアとして生きていけない」というのが、ほとんど人生のコンセプトみたいなものでして、流石に Novell の Uniux Ware には手が出なかったけれど(後にひと悶着した SCO UNIXですね)、やっぱり若いころ使った UNIX 系 OS をやりたかったし、PC用に(当時は高価だった)C言語コンパイラもついてくるという、入門用の Linux ディストリビューションを探していました。 Live Door が販売した Lindows(後のLinspire) を使ってみてなんじゃこれと挫折し、Cardela Open Linux を突っ込んでGUI見て「だからこれは何じゃ?」と3日で諦めた、90年代後半。そして2000年以降、いよいよ Linux がどこでも使えるようになった頃、 RedHat に苦しみました。


一応ベテランとなっていた当時、ヒマそうにしていると、後輩から「そんなにヒマならRedHat をインストールを手伝って欲しい、ベテランで高い給料もらってるんだから働け」と言われ、ま、いい暇つぶし、と思って入れてみたけれど、もう大変。SCSI のディスクドライバが認識できない。おまけにインストーラはテキストだし、途中でハングアップしたりするしで、どうもハードベンダーではテスト済のモデルなですが、ドライバーは別に入れなければならないわけです。正直、昔の Lindows より面倒くさい。しかも配布されているのはフロッピーのイメージのみ。「ヲイ、このモデルどう見てもFDD付いてないンだけどなァ」「いやぁ RedHat ならよくあることですよ」と若者に馬鹿にされたのは言うまでもありません。

納品までヒマがかなりあったので、試しに 評価用の SLES9 を入れてみると、ドンピシャで、何のトラブルもなくYaST の GUI インストーラが立ち上がり、インストールが出来ました。それ以来、 Linux と言えば SUSE Linux なんですね。RedHat と SUSE を比較すると、圧倒的にトラブルの少ない SUSE の方が入門するには敷居が低い。

ところで 「SUSEは日本語のドキュメントが少ない」とか「ドマイナーな Linux 」という印象がありますが、もともとが企業向けのミッションクリティカルなサーバーOSとして人気があるので、比較すると RedHat のように「誰でもお気軽」に情報を出せないところがデメリットなのかも知れません。

= Google Trend による認知度傾向 = 

Google Trends によると、過去、近年の日本での検索ワードのレート 6:45 なので、SUSE Linux は RedHat の 1/7 以下の認知度、という感じでしょうか。

過去1年の日本でのトレンド
a0056607_00412819.jpg

ところが、海外も含むトレンドを見ると RedHat が 100弱に対して SUSE は 50 弱のレートですから、「商用 Linux では第二の人気のディストリビューション」と言っても、まず誤解ではなさそうです。1:2 程度の認知度であるわけですね。

ワールドワイドの過去1年のトレンド
a0056607_00425212.jpg
※もっともこれは「商用 Linux」としての認知度で、これに CentOS とか Ubuntu なんかの無償ディストリビューションを加えると全然違う数字になります。ってか、(Ubuntu って商用なの?)


ちなみに、RedHat の過去5年の都市別人気度を見ると、一位は「千代田区」です。3位に中央区が入っています。他にも、渋谷区、新宿区、東京じゃないけど横浜市などがベスト20位以内に入って行って、「首都圏」というざっくばらんな地域でみると、「RedHat というアメリカ製品だけが大好きな異常な東京人」という構図が見えてきます。何故か日の丸ディストリビューションはほとんど人気がありません。他には、シンガポールやインドの各都市、ソウル、香港などがランク入りしています。「東アジアで大人気の RedHat」なのですね。


過去5年の都市別のトレンド
a0056607_00434014.jpg
もっとも、逆に Google Trend では、SUSE の人気都市の上位はズラリと「ドイツの都市」が並ぶのも、まぁ当たり前なんですけどね。

国別でみると、ドイツはもちろんですが、チェコ、ロシア、ポーランドなどの東欧諸国、何故かブラジルなどのポルトガル語圏など、非・米英語圏での認知度が高いようです。私のサイトを訪れる海外言語は、英語がもちろんですが、en_gb やチェコ、ポルトガル語(ブラジル)などのアクセスがたまにあります。たまに Google Trends を見てみると、Novell 傘下になって以降、年を追うごとに en_us での認知度は上がり続けており、米国からオフショアで仕事をするインドなどでの認知度も年々上がってきているような気がします。

= SUSE Linux のメリット =

本題に入る前にずいぶん寄り道しました。SUSE のここが嫌いという前にどこにメリットがあるのかまずは並べてみます。

- 圧倒的に使い易い YaST

SUSEは YaST に始まり、YaST に終わる、というくらい、Linux の管理者にとっては萬金丹のような万能ツールです。これがある意味では最悪のデメリットになります。

- 比較的新しいハードウェアでもまず動く

一度だけ、10Gb NIC にはまったことがありましたが、他のサーバーに合わせて古いバージョンの SLES を入れたので、コンパイルする必要がありました。
それ以外、まずドライバ問題でインストールで戸惑うことはほとんどありません。新しい機種の場合は、できるだけ新しい SLES のバージョンを入れた方が無難ですね。
これもある意味 SUSE のデメリットになります。

- 落ちたことがない

もう10年以上 SLES を扱ってきて、まず、本番環境で「落ちた」「再起動できない」という経験に当たった事がありません。もっともテスト環境だと、古いハードディスクが御昇天して起動できなくなったという経験はよくあるのですが、まずハードウェアのトラブルがなければ、運用中のトラブルはまず皆無でした。あくまでも自分の経験ですが、システムがトラブると、エンジニアとしては必死に原因探しをするので、スキルも上がります。本番環境で滅多にトラブルが出ない、 SLES の安定感は、安心感は絶大なのですが、逆にこれもエンジニアのスキルとしてはデメリットになります。

= SUSE Linux のデメリット =

- 何でもYaST 頼りになる

SLES,SLED, openSUSE いずれも YaST があれば、ほとんどの管理作業は自動化されるので、Linux の基本的な設定を行うコマンドをほとんど覚えません。LPICなどの公認資格を取ろうにも、YaST で何でもできてしまう SUSE のエンジニアは不利ですね。逆にCLP (Certified Linux Professional)というマイナーでSUSE ローカルな資格制度があります。残念ですが、現在日本では行われていないようです。所詮ノベルさんの製品資格ですからね。

コマンドラインで yum や apt-get に相当する zypper というパッケージ管理ツールもありますが、まず、zypper は使いません。綴り間違えると面倒だし。

初心者にもお勧めな SUSE Linux ですが、レベルを上げるためには、やっぱり vi の基本操作ができるとか、サービスのリスタートができるとか grep でログの見方を知っているとか、簡単なシェルスクリプトが書けるとか、その手の技術に達するにはやっぱり Linux の知識は必要なんです。でもYaST にもログビューワなんかが付いていると、ついつい YaST 頼りになってしまいます。このテの操作は、Debian 系を除く他のディストリビューションとほとんど同じなので、基本的なアンチョコ本を持っている必要はあります。正直に白状すると私は YaST なしでは Static IP の変更ですら方法を知りません。一応できるようですが、マニュアルを見て5秒で諦めてしまいました。

~.conf なんてどこにあるのか知らないし、ついつい「httpd.conf ってどこにあるんだっけ?」と find を使ってしまいます。YaST で細かいチューニングはほぼできます。この程度の知識は欲しいのに、その知識自体が身につかないことが多いです。サービス関連はもっぱらアンチョコ本が頼りであることには変わりありません。もっともディストリビューションが違ったり、ソースからインストールする場合は探すことになるんですね。それは何を選んでも同じです。

逆に SUSE から他のディストリビューションに乗り換えた方は、よく海外のフォーラムなんかに「Ubuntu 版の YaST に相当するツールはないのか」という投稿が見当たります。一応 YaST も OSS なので、ディストリビューターが実装する事はできるのですが、非公式にサポートしているのは Oracle くらいの様です。CentOS に Oracle 版の YaST を入れた猛者がいらっしゃるようですが、慣れって怖いものです。

テキスト端末でも簡単なUIで管理作業ができる YaST の恐ろしさは、ベテラン Linux の管理者にとっては仕事を奪うほどのキラーツールです。

- インストールの敷居が低すぎる

これもエンジニアとしてのスキル向上の問題になります。何しろほとんど SUSE Linux ではシステムやパッケージのインストールでは躓かないので、「あの手この手」を使わなければならないシーンに滅多にお目にかからないのはいいことなのですが、いざ「あの手この手」をつかわなければならない時の、「技術の陳列棚」が身に付きません。だから「SUSE で困っています」という Yahoo 知恵袋の質問なんか探しても、情報が少ないのです。Apache を入れようとして「# yum install httpd とやったら拒否られた」」とかそんなレベルなのです。

- 日本語の情報の少なさ

これは、日本総販売元のノベル株式会社のリソースの問題もありますが、日本での利用者が少ないため、日本語情報が少なすぎる、とよく言われます。もっとも英語で検索すると、ゴロゴロ出てくるのですが、英語アレルギーなニッポン・ガラパゴスなエンジニアにとってはつらい事かも知れません。これは、 SUSE Linux を利用している顧客の多くがベンダーのサポートを適切に受けたヒミツのハイエンドプロジェクトのシステムなどが多く、最新の SLES12 では Live Patch などと言う怖い機能がサポートされるなど、話題にもならないけれど、深刻な問題が表面に出てこない事も考えられます。

幸いな事に openSUSE を含めマニュアルは、そこそことニホンゴでも充実しています。また、openSUSE と SLES, SLED は共通点が多く、openSUSE である程度トレーニングしておけば、まず SLES, SLED の商用版でも応用が利きます。openSUSE のサイトには、SUSE Enterprise の公式リポジトリにない、SUSE 非公認の OSSパッケージも見つかるので、ブラウザから自己責任で1クリックでインストールできます。まず、はじめてトライする Linux の無償ディストリビューションとしては openSUSE は良い一つの選択肢です。

よほどマイナーなパッケージでなければ、まず openSUSE ≒ SLES/SLED というケースが多いでしょう。RedHat における Fedora との違いほどの差はありませんし、openSUSE は GUI や最新のハードウェアにトライが多く新鮮さを感じても、サーバーとして割り切った場合でも、そこそこ安定して利用できます。それほどクリティカルな目的でなければ、openSUSE でもいいやという場合もあります。ただしサポートがない、LTSが短いという点は心得ておくべきでしょう。ハードウェアのライフサイクルを考えると、企業ユーザさんには openSUSE はトレーニング目的以上にはお勧めしません。Fedora や Ubuntu ではないデスクトップ向けの Linux を、重要でもなく、低コストで古いPCに入れたいというのなら、お勧めできるディストリビューションの一つです。

また、手軽になった Windows10 の Hyper-V にも初めから対応しているので、Hyper-V 環境下で仮想ドライバは Microsoft 標準のドライバが自動認識されてインストールされます。

ただ openSUSE や SLED (SuSE Enterprise Desktop) をデスクトップとして利用する場合は、日本語を優先言語にしますが、私が SLES を使う場合は、優先言語を英語にして、まず使わない日本語は追加言語としています。メッセージが日本語だと、探しても全然ヒットしない。英語のマニュアルを見ながら操作する場合も、日本語では非常に面倒くさい事になります。

まぁ、英語に強くなりたいITエンジニアには、日本語情報が少ない事も英語のトレーニングにはメリットかもしれません。

- 国内サードパーティで未対応

これは、非常に困った問題で、これだけメジャーなディストリビューションでも、Linux ≒ RedHat と考えるガラパゴス・サードパーティ・ソフトウェアビジネスでは、まず 「SUSE Linux 何それ?」という困ったIT企業が非常に多い所が問題です。何しろ、少子化や先の経済発展が見込めない日本国内ビジネスだけでも当面は食っていけるので、コストを考えるとサポートどころかマニュアルさえ、英語化しないし、海外向けの会社案内のページさえ作らないのが普通ですから、Google Trends でも見たように、RedHat 大好きな、首都圏ビジネス主義、地方無視のニッポンのIT産業では、まぁ当然です。

だから、日本企業でも中規模企業が海外に進出する時は、現地担当者が当たり前のように、先進的で世界スタンダードな情報システムを使っているのに、日本では、海外グループ企業との情報化の一本化ができないのですね。こういうところから日本の斜陽化が始まっています。もっとも、これは顧客のシステムの首根っこを押さえている日本のSI屋ではパスポート持っているエンジニアやセールスマンがいないのか、顧客が海外進出しても「そっちは知らんぷり」なので止むを得ないのです。

そもそも、海外のIT業界では「日本市場参入の高い壁は世界の常識」という事で、東京をパスして、シンガポールやソウルに極東地区のビジネス展開した方が、成長性の高い中国ビジネスに参入しやすい。

まぁ SUSE と RedHat を比較してどっちがいいか、と思っている方、そうこのブログを読んでいる貴方です。グローバルで活躍できる人材になるか、それとも先が見えない、英語嫌いなガラパゴスエンジニア、ガラパゴス経営者で会社が潰れるまで働きたい、という方にはもうお分かりかも知れません。

どうせサードパアーティ製品なんて、ソフトウェアそのもののサポートをやればいいのであり、「インストールができるか否か」のチェックすら主だったディストリビューションで行わないので、まったく困ったものです。

- チューニングのスキがない

普通、デフォルト状態でインストールしてほとんど最高の性能がでるようで「それからチューニングするのが楽しみウッフン!」という方には物足りないのかも知れません。SAP なら SAP 用のパッケージにカーネルパラメータが用意されています。もしかしたらハイエンドのシステムではカーネルチューンしているのかも知れませんが、カーネルを直接つつく様な作業はほとんどやりません。

また SAP や Oracle と言った、ベンダーと、積極的に "Enterprise" な商売をやってきたせいか、オープンソースにコミットした「オープン性」の強い RedHat と違い、ダンマリと守秘性が高い「企業向けの SUSE Linux」というスタイルが企業には安心感を作っています。

- あまりに良すぎる安定性

まず、ハードウェアのトラブルでもなければ、リセットボタンに手を出す機会がないという、超安定性は、逆に言うとデメリットになります。まぁ、Windows なんか使っているとパッチを当てては毎月再起動、そのうちレスポンスも帰らず「またか...」という感じで、おまじないを唱えつつハードリセットをかけるMTBFの短さが当たり前なのですが、 SuSE Linux Enterprise の場合、まずハードリセットする機会がありません。もっともそんなことした後の fsck の怖さ(とにかく MTTR に時間がかかる)がありますから、やりません。というより「松竹梅」の「松竹」クラスの信頼性が高いハードウェアの運用環境ではやった経験がないのです。ラッキーな事に、お客様の責任感にも感謝しています。勿論、私のように「梅以下」の安物PCを酷使しているテスト環境では日常茶飯事ですが、これはそれなりに勉強になります。他のディストリビューションは知りませんが、ベンツでアウトバーンを安心して 250Km/h でかっ飛ばすような安定感は、V8 のコルベットでバンピーな Route 66 を 55Ml/h 出してパンクする怖さと違い、何とも言えません。

だから、事故った時が怖い。

これが SUSE Linux の怖さであり、デメリットなのです。

--
とまぁ、思いっきり悪口羅列したいと思って書き始めたのですが、結局は、SUSE Linux の安定感、管理の容易さという良い面が、デメリットとして相反するような書き方になってしまいました。



--
商用, Linux, SUSE, RedHat, 比較, メリット, デメリット




[PR]
by islandcenter | 2017-07-03 00:54 | SUSE | Trackback | Comments(0)


どうも世の中、Linux のサービスの、リストアップ、起動、停止を行うために chkconfig、service というコマンドがあるそうなのですが、 SUSE Linux を使う場合、まずお世話になることがありません。勿論、これらのコマンドは実装されているのですが、ほとんどのサービスの管理は # yast (or yast2) > System > System Service(SLES12 では Servie Manager) の中で行います。

SLES11 の System Servie
a0056607_13281346.jpg

この使い勝手よ良さは systemd を採用した SLES12 でも引き継がれ、Servie manager となりよりシンプルになりました・

SLES12 の Service Manager
a0056607_13284102.jpg

SLES12 の Service Manager , CUI 版
a0056607_13290645.jpg


勿論テキスト端末から、慣れた Service の再起動には # rcXXXX" コマンドや "#/etc/init.d/xxxx restart" を使いお世話になることもあります。その程度なら、何しろお手軽ですからね。

でも YaST で、インストールし、During boot をアクティブ設定をして、その他、必要な設定をすませば、ほとんどサービスマネージャを使う事もありません。もしサービスが安定していなくて「よく分からんぞ」という時は、YaST のサービスマネージャで、サービスのステータスチェックから、起動、再起動、chckconfig, inittab, fstab の書き換えまで行えます。
画面をスクロールしたり、難しそうに「うーむ」と唸りだしそうに眉間にシワを寄せて、非番の殺し屋が、突然ゴルゴ13の様なムズカシイ顔に変身して、綴りを間違ってキーボードを乱打しないので、非常に楽なのです。

何しろ、本棚の中から「誰でもカンタン Linux コマンドリファレンス」なんてアンチョコ本を取り出してページをピロリピロリと探すヒマがあれば、さっさと YaST を立ち上げればいい。まぁ私の場合、それほど難しい事をやっていないということもあるのですけどね。

※ ちなみに SLES12 では service/usr/sbin/rcXXXXX は service コマンドのシンボリックリンクになりました。

「難しいを簡単にできる」事が SUSE Linux の YaST なんですね。

でも、「自宅のXXサーバー」なんて記事を見ると、いかにもコマンドがズラズラで、これで「やっぱ Linux サーバーは使い易いや」なんて思っている人ってどれくらいいるのでしょうか。Linux の入り口で本当にその通りにやって途中で綴りミスなんかでエラーが出てしまって「挫折する」ヒトもいるわけだから、chkconfig だとか、yum や apt-get のマニュアルページをひたすらじーっと眺めて、YaST なら数クリックでできる作業も、Apache のインストールごときに、ごっちょりページを割いて「俺は Linuxの 使い手なのだ。タッチタイプのプロだぞ。スゴイだろ」という感じのコムズカシイドキュメントを作っているヒトってやっぱり、私よりは賢いけれど平均的なヒトから見ると、ちょっと特殊に思えてしまい、「やっぱり Linux では HTTPサーバーのインストールすら難しそう」となってしまいます。

YaSTは、昔、映画で見た、良く設計されたドイツの潜水艦の司令室みたいなもので、一つ人のコマンドを別個に使うのではなく、各種パラメータを一つのコントロールパネルで設定して最後にレバーを下すと、YaST に設定されたパラメータを次々と処理して「魚雷発射!ズシン!」となるわけですね。例えは悪いかも知れませんがいかにも SUSE Linux に標準の YaST はドイツ製、質実剛健、合理的な設計なのです。






- Keyword -

Linux サービス管理、chkconfig rcコマンド SUSE SLES openSUSE


[PR]
by islandcenter | 2017-06-06 13:20 | SUSE | Trackback | Comments(0)