ここでは SUSE Linux Enterprise Server 12 (SLES12) の ext3 パーティションを BTrFSに変換する手順をまとめました。本家 Oracle に詳細な手順がありますが、この手順を SUSE12 風にアレンジします。

5.11 Ext2、Ext3またはExt4ファイル・システムのBtrfsファイル・システムへの変換
https://docs.oracle.com/cd/E39368_01/b71105/ol_use_case7_btrfs.html


-変換前に-

からなず、失うと強く後悔するファイルは別メディアにバックアップしましょう。どんな場合でもバックアップさえあれば、強く後悔せず、ただ辛い思いでリストアすれば、幾分気持ちが楽になるというものです。


-ボリュームのアンマウント-
次に変換するボリュームをアンマウントして fsck します。

yast からボリュームをアンマウントする場合、アンマウントするデバイスを選び、Edit
a0056607_1075852.jpg


(×) Mount Partition から "Do not mount partition"をチェックしてアンマウントします。
a0056607_10102096.jpg



-fsck でファイルシステムのチェック-

sles12:~ # ls /dev/x*
/dev/xconsole /dev/xvda /dev/xvda2 /dev/xvdb1 /dev/xvdc1
/dev/xvc0 /dev/xvda1 /dev/xvdb /dev/xvdc
sles12:~ #
sles12:~ # fsck.ext3 -f /dev/xvdc1
e2fsck 1.42.11 (09-Jul-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/xvdc1: 13/262144 files (15.4% non-contiguous), 94919/1048320 blocks
sles12:~ #


-変換-

sles12:~ # btrfs-convert /dev/xvdc1
creating btrfs metadata.
creating ext2 image file.
cleaning up system chunk.
conversion complete.
sles12:~ #


yast で確認してみます

無事変換できたようです。
a0056607_10145635.jpg


-BTrFSのマウント-
yast > Partitioner > パーティション > edit からマウントポイントを指定してマウントします。
Subvolume Handling のメニュー項目が増えています。
a0056607_1015532.jpg


mount できたかどうか確認してみます。
a0056607_10181337.jpg

上手く変換できたようです。

snapper に登録します。

sles12:~ #
sles12:~ # snapper -c my-config create-config /ext
sles12:~ #

新しい Snap Shot コンフィギュレーションができています。
a0056607_10203094.jpg


そのほかの情報は
islandcenter.jp

-keyword-
SUSE Linux Enterprise Server 12 SLES12 btrfs ext3 ext4 フォーマット変換、ファイル スナップショット
[PR]
# by islandcenter | 2014-12-01 10:23 | SUSE | Trackback | Comments(0)

XEN などの仮想環境で、テキスト端末から

# xm console windows-vm (または xl, virsh で)

などとやってしまうと、本来 GUI 環境で動くべき Windows のコンソールが出ません。出来ないものは出来ないので、kill してしまうしか方法がありません。

しかし、肝心のテキスト端末にプロンプトが戻ってこないわけです。

その場合は、別なテキスト端末を開いて、プロセス番号を探して kill します。


sles11:~ # who 誰がどの端末からログインしているかを調べる
root pts/6 Nov 29 06:45 (192.168.1.45)
root pts/10 Nov 29 08:01 (192.168.1.45)
sles11:~ #

pts で二つセッションが開いています。ttyの場合もあります。
そこで ps コマンドで pts を grep してみます。

sles11:~ # ps ax | grep pts
2524 ? Ss 0:01 sshd: root@pts/6
2614 pts/6 Ss 0:00 -bash
4419 ? Ss 0:00 sshd: root@pts/10
4424 pts/10 Ss 0:00 -bash
27171 pts/6 Sl+ 0:00 /usr/lib64/xen/bin/xenconsole 5 --num 0 --type serial
<---- 犯人はこいつだ
27238 pts/10 R+ 0:00 ps ax
27239 pts/10 S+ 0:00 grep --color=auto pts
sles11:~ # kill 27171 <--- kill する
sles11:~ #


プロンプトが戻ります。

そのほかの情報は
islandcenter.jp

-Keyword-
SUSE SLES xen xm console xl console virsh console 仮想コンソール プロンプトが戻らない できない。
[PR]
# by islandcenter | 2014-11-30 12:08 | XEN | Trackback | Comments(0)

前回
SLES12 大きく変わった仮想化管理
で仮想管理の方法が随分変わり、戸惑いました。その続きです。

SUSE Linux Enterprise Server12 (SLES12) では大きくXEN 仮想化管理が変わりました。従来の xend から libvirtd に移行しました。内部的にどうなった、こうなったという話はこちらにまかせて

SUSE Linux Enterprise Server 12 Virtualization Guide

実際のオペレーションから、、どうすればいいのかを書いてみます。

- xm -

まず、/usr/sbin/xm 自体がありません。/usr/sbin/xl に置き換わっています。

また、xl コマンド自体が libvirtd を管理する virsh コマンドとの互換性がありません。
xl コマンド自体は xm との下位互換性を維持するために存在するものです。

- virsh / virt-manager -

このツールは /etc/libvirt/libxl/myvm.xml を使って制御します。

virsh create /etc/libvirt/libxl/myvm.xml で起動
virsh list (libvirt 管理のものだけ表示、xl create したものはリストされない)
virsh shutdown myvm (xl create したものはシャットダウンできない)

※ xl で起動、終了はできるが GUI コンソールを virt-manager からは制御できない。(バックグラウンドで virsh を使うから)

実際に virt-manager で作成した仮想化された SLES を動かしてみます。


xl create -f /etc/xen/vm <---- xl コマンドで vm ファイルを指定して起動

sles12:~ # xl create -f /etc/xen/vm/sles12
Parsing config from /etc/xen/vm/sles12

sles12:~ # xl list <--- 起動した
Name ID Mem VCPUs State Time(s)
Domain-0 0 7237 4 r----- 236110.8
sles12 31 1024 2 r----- 9.6

sles12:~ # xl console sles12 <--- コンソールを切り替え
Welcome to GRUB!

: 中略

[ OK ] Reached target Host and Network Name Lookups.
[ OK ] Started Login Service.

Welcome to SUSE Linux Enterprise Server 12 (x86_64) - Kernel 3.12.28-4-xen (xvc0).

linux-gisu login: <---- xl console で操作できる。

CTRL+] でコンソールに戻る

sles12:~ # xl shutdown sles12 <--- シャットダウンしてみる
Shutting down domain 31
sles12:~ #


しかし、この方法では virt-manager からGUI制御できません。ドメインのリストにも出ません。

virsh で制御してみます。


sles12:~ # virsh console sles12
Connected to domain sles12
Escape character is ^]
Welcome to GRUB!

: 中略

Loading Linux xen ...
Loading initial ramdisk ...
[ 0.161234] PCI: Fatal: No config space access function found
[ 0.161545] Unable to read sysrq code in control/sysrq
[ 1.841010] i8042: No controller found

Welcome to SUSE Linux Enterprise Server 12 (x86_64) - Kernel 3.12.28-4-xen (xvc0).

linux-gisu login:

CTRL+]で終了

sles12:~ #
sles12:~ # virsh shutdown sles12 <--問題なくシャットダウン
Domain sles12 is being shutdown
sles12:~ #

virt-manager からコンソールを開くことができます。
a0056607_1336594.jpg



- xl -

/etc/xen/bm/myvm を使って制御
xl list (libvirt で稼働中のものも表示)
xl create -f /etc/xen/vm/myvm で起動(-f は必須のオプションとなります)
xl shutdown myvm で終了

virsh shutdown では終了できない。
virt-manager からGUIコンソールに接続できない。

virtsh create したものは

sles12:~ # xl shutdown sles12 <---- xl shutdown できない
Warning: This domain is managed by libvirt. Using xl commands to modify this
domain will result in errors when virsh or virt-manager is used.
Please use only virsh or virt-manager to manage this domain.

(This check can be overridden with the -f option.)
sles12:~ #
sles12:~ # virsh shutdown sles12 <---- virsh shutdown はできる。
Domain sles12 is being shutdown

xl crerate した Dom-U は virt-manager からGUI制御できないため、Windows のような GUI を必要とする Domain-U は制御できません。万が一、ネットワークの構成を変えたい、などの場合、リモートデスクトップのセッションが切れると、制御不能となってしまいます。

そこで、Windows 系のシステムを SLES12 に移植する場合は、vm ファイルを使う xl ベースの操作ではなく virsh / virt-manager への移行が必要になります。

ということで SLES12 には xen2libvirt という変換ツールがあります。

https://www.suse.com/documentation/sles-12/book_virt/data/xen_xen2libvirt.html

が見事に失敗しました。(Failed)

sles12:~ # xen2libvirt -f xm -c /etc/xen/vm/myvm.xml
libvirt: Config File error : configuration file syntax error: memory conf:1: expecting a name
Traceback (most recent call last):
File "/usr/sbin/xen2libvirt", line 121, in
import_domain(conn, args.path, args.format, args.convert_only)
File "/usr/sbin/xen2libvirt", line 77, in import_domain
xml = conndomainXMLFromNative('xen-xm', config, 0)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3344, in domainXMLFromNative
if ret is None: raise libvirtError ('virConnectDomainXMLFromNative() failed', conn=self)
libvirt.libvirtError: configuration file syntax error: memory conf:1: expecting a name
sles12:~ #

という事で、SLES11 から SLES12 へP2P Migration する場合は、xl での起動、終了はできるのですが、設定変更などが必要な場合 vm2libvirt で convert をする必要があります。しかしうまく動かないケースが多くあります。

そこで「 virt-manager で作り直す」という手段が一番手っ取り早い、という事になります。

- virt-manager は /usr/bin へ-

virt-manager の GUI は /usr/sbin から /usr/bin へ移動しました。しかし、実際に利用するには root の権限が必要です。実際にユーザが仮想マシンを操作できる様にするには Policy Kit による認証が必要なようです。

第9章 PolKit を利用した権限認可
http://manual.geeko.cpon.org/ja/cha.security.policykit.html

https://www.suse.com/documentation/sled-12/book_security/data/cha_security_policykit.html


適切に設定すれば、一般ユーザが、自前の VPS を作成する事ができるわけですね。

- 仮想マシンのイメージ -

SLES12 での XEN 環境での仮想マシンイメージのデフォルトストレージの格納場所は /var/lib/xen/images から /var/lib/libvirt/images に代わりました。iSCSI や NFS などで共有している環境では問題になってくるでしょう。

仮想マシンの起動と終了

virsh 環境で作成された起動ファイルは /etc/libvirt/libxl/xxxxxx.xml という名前で保存されます。xm コマンドの様に仮想マシン名だけで create できません。 xml ファイルをフルパスで指定します。


sles12:/etc # virsh list
Id Name State
----------------------------------------------------
12 sles12 running
19 salamandra running

sles12:/etc # virsh create /etc/libvirt/libxl/myvm.xml
Domain myvm created from /etc/libvirt/libxl/myvm.xml

sles12:/etc # virsh list
Id Name State
----------------------------------------------------
12 sles12 running
19 salamandra running
34 myvm running

sles12:/etc # virsh shutdown myvm
Domain myvm is being shutdown

sles12:/etc #


- まどめ -

xl コマンドと virsh コマンドとを使い分ける注意点をまとめてみましょう。

- xm はなくなり xl に変わった。
- xl create したものは virsh shutdown できない。
- xl list では virsh で起動しても xl list で確認できる。
- xl create したものは virt-manager から制御、仮想コンソールアクセスはできない。
- xl create したものは virsh consolle できない、xl console を使う。
- virsh create したものは xl shutdown できない。
- virsh create したものは xl console できない。virsh console を使う。
- xl create したものは virsh list / virt-manager で確認できない。
- virt-manager で作成した Dom-U は xl create/shutdown できない virsh で行う。

SLES12 における仮想化は、xend からの移行を考慮したものです。単体の「ハイパーバイザー」そのものの提供から、プライベートクラウド基盤への移行を念頭に置いた実装への過渡期でしょう。

また virsh を中心としたオペレーションでは、ほとんどXEN と KVM のハイパーバイザーの違いを意識せずにオペレーションをする事ができます。

SLES10/11 からの単純移行、平行運用は、オペレータの負荷を考慮すると、あまりお勧めできるものではありませんが、今後のプライベートクラウド基盤としてはOpenstack などの標準的な機能に準拠した実装ができます。

それでも、過去の仮想基盤がそのまま移行できることは、やはり便利な事です。

関連記事
SUSE SLES12 の大きな変化 systemd、さらば init
SUSE Enterprise Server (SLES12) on SLES12+XEN 準仮想化


その他の情報はこちら
islandcenter.jp

-Keyword-

SUSE Linux Enterprise Server 12 (SLES12) XEN KVM 仮想化 libvirtd xend virsh xl コマンド
[PR]
# by islandcenter | 2014-11-26 13:44 | SUSE | Trackback | Comments(0)

-現象-

movaXterm で、ssh キーが整合しない。
同じホスト名、あるいはIPアドレスで接続先を再インストールしたなど。


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
00:72:b2:ee:e9:53:9b:6f:96:e7:8b:f7:74:db:f2:b3.


If you changed or re-install this server recently, and if you are really sure
that no other computer is using its IP address, then you can reset this alarm
by deleting the ~/.ssh/known_hosts in a new MobaXterm local terminal.
Add correct host key in /home/mobaxterm/.ssh/known_hosts to get rid of this mess
Offending ECDSA key in /home/mobaxterm/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attac
X11 forwarding is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,keyboard-interactive).


SUSE Linux の場合 ~#.ssh/know_host のホスト名、もしくはIPの行を消します。

movaXterm の場合
C:/user/myname\Documents\MobaXterm\home に known_host があるので、ここから問題の接続キーを削除します。

Settings > General で確認できます。
a0056607_11151294.jpg




islandcenter.jp
[PR]
# by islandcenter | 2014-11-17 13:10 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server 12 のメダマの一つに Btrfs(B Tree FS、ビー木FS、バターFSなどと言うようです)を使ったスナップショットの機能があります。

SLES12 は Btrfs がデフォルトの / (ルート)ファイルシステムとなりました。 btrfs はopenSUSE13.2 からもデフォルトルートのファイルシステムです。

追加ボリュームはデフォルトが XFS です。当然、追加ボリュームに btrfs も利用できます。

ここでメダマとなる、スナップショットの機能を見てみます。

-用意-
こんな感じのパーティションを用意しました。
a0056607_17425073.jpg


Btrfs と EXT3の異なるパーティションを作ってマウントします。この作業は全て yast > System > Partitioner で行う事ができます。

初期状態はこんな感じです。

sles12:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda2 5244928 3115132 1861572 63% /
devtmpfs 500424 8 500416 1% /dev
tmpfs 530780 0 530780 0% /dev/shm
tmpfs 530780 8036 522744 2% /run
tmpfs 530780 0 530780 0% /sys/fs/cgroup
/dev/xvda2 5244928 3115132 1861572 63% /var/spool
/dev/xvda2 5244928 3115132 1861572 63% /var/opt
/dev/xvda2 5244928 3115132 1861572 63% /var/lib/pgsql
/dev/xvda2 5244928 3115132 1861572 63% /var/lib/named
/dev/xvda2 5244928 3115132 1861572 63% /var/crash
/dev/xvda2 5244928 3115132 1861572 63% /srv
/dev/xvda2 5244928 3115132 1861572 63% /var/tmp
/dev/xvda2 5244928 3115132 1861572 63% /home
/dev/xvda2 5244928 3115132 1861572 63% /opt
/dev/xvda2 5244928 3115132 1861572 63% /boot/grub2/x86_64-efi
/dev/xvda2 5244928 3115132 1861572 63% /tmp
/dev/xvda2 5244928 3115132 1861572 63% /boot/grub2/i386-pc
/dev/xvda2 5244928 3115132 1861572 63% /var/log
/dev/xvda2 5244928 3115132 1861572 63% /usr/local
/dev/xvda2 5244928 3115132 1861572 63% /var/lib/mailman
/dev/xvdb1 4193280 16592 3918784 1% /btrfs
/dev/xvdc1 4061888 8252 3843972 1% /ext

sles12:~ #

※ btrfsでは df コマンドでの容量チェックはあまり意味がありません。btrfs のコピーオンライト(COW)の効果を見たかったのですが、snapshot の効果が優先で、 COW の効果はないようです。

-snapper の有効化-

この状態で yast2 > snapper を起動します。
a0056607_19342243.jpg


この状態では snapper の初期設定ができていないため、snapper は起動できません。そこで snapper の初期化を行います。

※ コマンドラインから snapper GUI を起動する場合は、X端末のコンソールから
# yast2 snapper &
で起動します。

4.4 Snapper設定の作成と変更
https://www.suse.com/ja-jp/documentation/sles-12/book_sle_admin/data/sec_snapper_config.html


snapper -c config-name create-config /your-mount-point

sles12:~ # snapper -c myconfig create-config /btrfs

設定ファイルは /etc/snapper/configs に作成されます

sles12:~ # ls /etc/snapper/configs/myconfig -l
-rw-r----- 1 root root 934 Nov 28 12:16 /etc/snapper/configs/myconfig
sles12:~ # cat /etc/snapper/configs/myconfig

# subvolume to snapshot
SUBVOLUME="/btrfs"

# filesystem type
FSTYPE="btrfs"
:
: 以下略
:

sles12:~ #


これで yast > snapper を起動することができます。
a0056607_19392129.jpg


-snapper のデフォルト設定-
デフォルトでは snapper は一時間ごとにタイムラインのスナップショットを作成します。古いスナップショットは自動的に削除されます。
a0056607_2121430.jpg


4.1 デフォルト設定
https://www.suse.com/ja-jp/documentation/sled-12/book_sle_admin/data/sec_snapper_setup.html#snapper_dir-excludes

- snapshot の保存先 -
snapshot は同じ btrfs パーティションの .snapshots ディレクトリに作成されます。他のパーティションやファイルシステムは利用できません。したがってスナップショットを取る実ファイルサイズの倍以上の空き容量が同じパーティションにあることが推奨されています。

第4章 snapper を利用したスナップショット採取と巻き戻し
http://manual.geeko.cpon.org/ja/cha.snapper.html

実際には .snapshots にスナップショットファイルが保存されています。

sles12:/btrfs # ls -l
total 359676
drwxr-x--- 1 root root 8 Nov 28 14:30 .snapshots
-rw-r--r-- 1 root root 122765701 Nov 28 14:33 file-a.txt
-rw-r--r-- 1 root root 122765626 Nov 28 13:35 file-b.txt
-rw-r--r-- 1 root root 122765701 Nov 28 14:34 file-c.txt
sles12:/btrfs # du -h
0 ./.snapshots/1/snapshot/.snapshots
0 ./.snapshots/1/snapshot
4.0K ./.snapshots/1
0 ./.snapshots/2/snapshot/.snapshots
118M ./.snapshots/2/snapshot
118M ./.snapshots/2
0 ./.snapshots/3/snapshot/.snapshots
235M ./.snapshots/3/snapshot
235M ./.snapshots/3
0 ./.snapshots/4/snapshot/.snapshots
235M ./.snapshots/4/snapshot
235M ./.snapshots/4
586M ./.snapshots
937M .
sles12:/btrfs #


-スナップショットからファイルをロールバックする-
snapper から、ロールバックしたいポイントを選んで "Show Changes" を押します。
a0056607_2126153.jpg


実際にファイルの変更点が確認できます。
a0056607_21434273.jpg


そこで、ロールバックしたいファイルを選び、"Restore Selected" を押すと
a0056607_21305714.jpg


ファイルが元にロールバックされます。
a0056607_21313426.jpg


-btrfs でのファイルサイズの確認-

実際に df コマンドでは使用しているファイルサイズの確認はできません。そこで

# btrfs filesystem df /your-mount-point

で確認します。

sles12:/btrfs # btrfs filesystem df /btrfs
Data, single: total=840.00MiB, used=702.68MiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=264.00MiB, used=992.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B
sles12:/btrfs #


-削除したファイルの復旧-
スナップショットが取れるという事は、削除ファイルの salvage もできるということです。

sles12:/btrfs # ls
.snapshots file-a.txt file-b.txt file-d.txt

ファイルを消す
sles12:/btrfs # rm file-d.txt
sles12:/btrfs # ls -l
total 239784
drwxr-x--- 1 root root 38 Nov 29 00:30 .snapshots
-rw-r--r-- 1 root root 122765671 Nov 28 16:53 file-a.txt
-rw-r--r-- 1 root root 122765626 Nov 28 13:35 file-b.txt
sles12:/btrfs # 消えた


TimeLine を選び "Show Changes"
a0056607_8325722.jpg


消されたファイルを選び "Restore Selected"
a0056607_8364839.jpg


ファイルが元に戻ります。

sles12:/btrfs # ls -al
total 239848
drwxr-xr-x 1 root root 80 Nov 29 08:08 .
drwxr-xr-x 1 root root 152 Nov 28 10:43 ..
drwxr-x--- 1 root root 38 Nov 29 00:30 .snapshots
-rw-r--r-- 1 root root 122765671 Nov 28 16:53 file-a.txt
-rw-r--r-- 1 root root 122765626 Nov 28 13:35 file-b.txt
-rw-r--r-- 1 root root 64251 Nov 28 14:49 file-d.txt
sles12:/btrfs #

--
実際に"ファイルのロールバック"という作業はあまりやりたい作業ではありません。おそらく通常の運用では、年に1度やるかやらないかの作業かもしれません。

また、ファイルのロールバックは、下手をすると「誤ったロールバック」という事故もあるわけです。

「ロールバックが簡単にできる」

という事を大きなメリットとして考えるのは誤りです。ロールバックは十分な検証と訓練、マニュアル化が重要です。やはり別メディアへのバックアップは重要です。

また、通常のバックアップでは「スナップショット」をバックアップする事はできません。バックアップの操作は、「今生きているライブなデータ」をバックアップします。(出来るのかもしれないけれど...)スナップショットが万能の萬金丹の様な効果があるわけではない事を心すべきです。

しかし、スナップショットからのロールバックは、短時間でシステムの復旧を行う事ができます。例えばスタティックなウェブサイトの改ざんからの復旧であるとか、ミスオペレーションからの急速復旧など -- もっともミスオペするオペレータが正しくロールバックできるスキルがあるかは別ですが -- には効果があります。

また、XEN の様な基本機能にスナップショットがない仮想化システムでは、システムのロールバックは魅力的な機能です。仮想環境下で、アプリケーションのインストール手順やテストに失敗した場合など、容易にロールバックできるのは魅力的でしょう。

重要なことはスナップショットを理解し、ロールバックの手順をしっかり確認する事です。

そのほかの情報はこちらから
islandcenter.jp

-Keyword-

SUSE Linux Enterprise Server 12 SLES12 btrfs snapshot スナップショット ファイルのロールバック機能 サーバー 仮想化
[PR]
# by islandcenter | 2014-11-16 11:22 | SUSE | Trackback | Comments(0)

仮想化管理は SLES12 の大きな変更点です。XEN 仮想化環境では xm コマンドが xl コマンドに代わりました。

これは XEN 4.4 から 4.5 に移行するにあたり xend が無くなる序章の様です。
http://wiki.xen.org/wiki/XL

副作用として xm による VM の作成ができなくなります。代わりに Libvirt による VM の作成が用意されました。

実際にSLES11 と SLES12 を見比べてみると xend が sles12 では使われていないことが判ります。

-SLES11-

SLES11:~ # ps ax | grep xend
3863 ? S 0:00 /usr/bin/python /usr/sbin/xend start
3864 ? SLl 160:40 /usr/bin/python /usr/sbin/xend start
3923 ? S 0:00 python /usr/lib64/python2.6/site-packages/xen/xend/server/HalDaemon.py
18283 pts/13 D+ 0:00 grep xend
SLES11:~ #

-SLES12-

SLES12:~ # ps ax | grep xend
8506 pts/10 S+ 0:00 grep --color=auto xend
SLES12:~ #

その代り SLES12 では libvirtd が起動しています。

SLES12:~ # ps ax | grep libvirt
1203 ? SLsl 0:02 /usr/sbin/libvirtd --listen
8718 pts/10 S+ 0:00 grep --color=auto libvirt
SLES12:~ #

ここでも "さらば xend こんにちは libbirt" という変更がありました。

xl コマンドは libvirtd へのコマンドインターフェースになります。

XL vs Xend Feature Comparison
http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison

SUSEのドキュメントに XM の Libvirt へのインポート方法が記載されています。
Import Xen Domain Configuration into libvirt
https://www.suse.com/documentation/sles-12/book_virt/data/xen_xen2libvirt.html

SUSE Linux Enterprise Server 12 Virtualization Guide
https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html

xl or virsh ?

仮想マシンの管理コマンドとしては別に virsh コマンドがあります。
Choice of Toolstacks
http://wiki.xen.org/wiki/Choice_of_Toolstacks



One really great feavirtd ture of the Xen Project hypervisor is that there are several choices of toolstacks that can be used to manage it.

とあり、xen project では様々な管理ツールを提供することで、柔軟な運用ができる、と言うような一文がありました。つまり xl コマンドと virsh コマンドは、いわば並列状態。環境にあったツールを使えばよい、という事になります。選択肢が増えた分、どっちを使っていいかわからない状態もある訳ですね。上の文書にあるように一応 XEN 4.4 では xl コマンドがデフォルトです。

OpenStack などの xapi を使うクラウド環境では libvirt との相性が良さそうなので、xend > libvirtd への変更は将来への布石でしょうか。

具体的に従来の SLES11+XEN 環境から SLES12 へ移行する方法については、別の機会に報告します。

続き
SUSE SLES12 の XEN仮想化管理

その他の情報は
islandcenter.jp
[PR]
# by islandcenter | 2014-11-14 09:52 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server 12 (SLES12) が出て大騒ぎしている間に、openSUSE 13.2 がリリースされました。

早速、インストールしてみたのでファーストインプレッションです。

なお、比較として SLES12 のファーストインプレッションはこちらです。
SUSE (SLES 12) ファーストインプレッション

ほとんど SLES12 と同じプロセス

openSUSE は SLES の先行プロジェクトである、という思いに反して、SLES12 と openSUSE12.3 は非常に似通ったものでした。また、openSUSE12.3 より先に同じ技術が利用されている SLES12 が出たこともちょっとした驚きです。

インストール

インストール言語は English、キー配列 Japanese でインストールします。途中追加言語を入れるのを忘れたのですが、これは後で YaST の Language 設定でインストールできます。

なぜ、インストール言語を Japanese にしないのかというと、例えば YaST メニューにある "Services Manager" というキーワードが御丁寧にも「サービスマネージャー」などと日本語に翻訳されているとします。世界中にある豊富な SUSE Linux の情報を調べる事ができません。

いちいち「日本語>英語」変換しなければならないです。エラーメッセージが余計に日本語化されていると、まずその日本語で検索して結果が出てくるはずはないでしょう。だから私は日本語でのインストールはしません。

もっとも openSUSE はサーバー用途以外にデスクトップ、ラップトップ用途でも利用できる優れた機能があります。そこで、サーバー用途以外に、実際に生産性のあるアプリケーションを使う場合は日本語で利用する事になるでしょう。

デフォルトで BtrFS

openSUSE では 13.1 までデフォルトで EXT4 でした。しかしコンマ1のアップデートで B Tree FS (BtrFS) がデフォルトです。ここも SLES12 と同じ。他に選択できるのは EXT4 と XFS です。
a0056607_13585332.jpg


ここは SLES12 と違うオペレータの設定

初期ユーザの設定は従来の openSUSE と変わりません。デフォルトで root パスワードと一致するよう "Use this password for administrator" と "Automatic Login" のチェックが付いています。
a0056607_140812.jpg

これらのチェックを外すと、 root パスワードの設定を別なものに設定できます。

root パスワードの設定では、Test 用のボックスが使えます。このあたりの親切設計も SLES と同じです。従来の openSUSE では Test ボックスがありませんでした。
a0056607_141183.jpg


サマリ画面

openSUSE では FireWall が Enable, SSH が Disable です。これもデスクトップアプリケーションを主に使う目的では意にかなっています。初期トラブルを避けるためには、ここは Firewall を Disable に、SSH を Enable にします。
a0056607_1423849.jpg


systemd の target設定

これも SLES12 と同じ systemd の設定です。デフォルトは Graphical Mode です。サーバー用途で使う場合は Text Modeで良いでしょう。この切り替えは、後で yast の Service Manager から行う事ができます。
a0056607_142412.jpg

関連記事
SUSE SLES12 の大きな変化 systemd、さらば init

ということで、サマリが整った後はインストールを開始します。15分から20分ほど(マシンの性能による)で自動的に再起動、ログインプロンプトが出てきました。

後処理

一応、ネットワークの設定が DHCP なので、これを固定IPにしてみます。モバイルで使う場合は DHCP でも構わないでしょう。

サーバー名が Linux-xxxx.site なので /etc/HOSTNAME を書き換えてホスト名を固定します。

NTPは自動的に opensuse.org の NTP プールを設定していました。SLES12 では未定義なので手動で設定しました。ここは openSUSE と 商用版 SLES との違いです。

言語設定(Language) に追加言語 "Japanese" を追加します。

先祖帰りした GUI版 yast2

すっかり使いづらくなった SLES12 の yast と違って openSUSE13.2 の yast2 は、先祖帰りしたように、左のペイン、右のアイコンという配置です。
a0056607_1474519.jpg



カーネルバージョン

カーネルバージョンは 3.16 です。SLES12 は 3.12 でした。このあたりは openSUSE の方が実験的です。

sles123:~ # uname -a
Linux sles123 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 x86_64 x86_64 GNU/Linux
sles123:~ # cat /etc/SuSE-release
openSUSE 13.2 (x86_64)
VERSION = 13.2
CODENAME = Harlequin
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead
sles123:~ #

--
駆け足で、openSUSE13.2 を見てみましたが、 13.1 とは大きく変化しており、中身は SLES12 とほとんど変わりない、という感想です。バージョン番号こそ 13.2 ですが SLE12 のオープン版の位置づけでした。

SLES12 を社内に導入する前に、ちょっと SUSE をいじってみたいという目的や、ラップトップ、デスクトップPCの置き換えには、一つの選択肢としての価値があります。元々、周辺機器の認識には定評がある SUSE なので、ラップトップでどの様に使えるかも楽しみです。

また商用版である SLES12 との共通点が多いので、かなり堅牢で、YaST 一つとってもGUIは使いやすそうなでした。た

だ例の左上の"Activities"から始まるI/Fは何とかして欲しいものです。

そのほかの情報はこちら
islandcenter.jp
[PR]
# by islandcenter | 2014-11-12 14:10 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server 12(SLES12) では,init に代わり systemd が採用されています。

openSUSE で既に採用されており、あらかじめ知識として知っておくべき事でした。

openSUSE 12 から、

「随分起動と終了が速くなったなぁ」

と単純に考えていたのですが、本気で付き合わなかった罰は後から付いてきます。

init を使わないので、当然 /etc/inittab も使わなければ /etc/init.d/ の下にあるスクリプト群も使いません。一部の互換性の為に存在しているだけです。

という事で、SLES12 以降では /usr/sbin/rcXXXXX のスクリプトを使って、コマンドラインからサービスの再起動を行います。まず、SLES11 から SLES12 に乗り換えたオペレータがハマる第一の関門です。/etc/init.d/ のスクリプトが随分少ないな、と不審に思っていましたが、サービスの起動の仕掛けが全く変わりました。

そもそも init とは

init は Linux が起動して、最初に実行するプロセスです。/etc/inittab に記述された runlevel によって ..../rcN.d/ 配下のシンボリックリンク先、 /etc/init.d/xxxxx のシェルを順次実行します。サービスは逐次起動します。DOS で言う所の Autoexec.bat みたいなものです。したがって時間が掛かります。

シャットダウンプロセスも init のシャットダウンプロセスによって順次終了します。

しかし、サービスの中には依存性のないものもあり、いちいち前の処理が終わってから起動/終了しなくても構わないサービスもあります。平行起動しても構わないものであれば同時に起動してもよい。終了、シャットダウンする時も、別に逐次処理で終了する必要はない。

そこで systemd

systemd によって、システムの起動と終了は格段に高速になるという事です。

SUSE Linux では systemd のパラメータを記述した、サービスユニット設定ファイルは /etc/systemd/system の下にあります。xxxxx.service というファイル名です。サービスは UNIT という概念で管理されます。

例えば httpd のサービスは次の様に記載されています。

sles12:/etc/systemd/system # cat httpd.service
[Unit]
Description=The Apache Webserver
Wants=network.target nss-lookup.target
After=network.target nss-lookup.target
Before=getty@tty1.service

[Service]
Type=notify
PrivateTmp=true
EnvironmentFile=/etc/sysconfig/apache2
ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k start
ExecReload=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k graceful
ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k graceful-stop

[Install]
WantedBy=multi-user.target
Alias=httpd.service
sles12:/etc/systemd/system #

この中の wants という記述が、サービスの依存性を示します。apache が起動する前に起動すべきサービスはこれですよ、という事です。そこで不要な依存性を排除して、非同期にサービスを起動するのが systemd という訳です。

過去のクセで /etc/ini.d/apache2 restart などのコマンドでサービスのリスタートは行えなくなりました。ただし SUSE Linux の場合 /usr/sbin/rcXXXX というシェルがあるので、このシェルを使ってコマンドラインからサービスの再起動ができます。

SLES11 までは /usr/sbin/rcXXXXX は /etc/init.d/XXXXX へのシンボリックリンクでした。


sles11:/usr/sbin # ls rc* -al
lrwxrwxrwx 1 root root 17 Aug 2 2012 rcacpid -> /etc/init.d/acpid
lrwxrwxrwx 1 root root 21 Jun 23 2012 rcalsasound -> /etc/init.d/alsasound
lrwxrwxrwx 1 root root 19 Oct 9 2013 rcapache2 -> /etc/init.d/apache2
lrwxrwxrwx 1 root root 16 Jun 23 2012 rcarpd -> /etc/init.d/arpd
lrwxrwxrwx 1 root root 15 Jun 23 2012 rcatd -> /etc/init.d/atd
: 略

SLES12 からは /usr/sbin/rcXXXXX は /usr/sbin/service というスクリプトへのシンボリックリンクです。

sles12:/usr/sbin # ls rc* -al
lrwxrwxrwx 1 root root 7 Nov 7 02:26 rcSuSEfirewall2 -> service
lrwxrwxrwx 1 root root 7 Nov 7 13:10 rcapache2 -> service
lrwxrwxrwx 1 root root 7 Nov 7 02:08 rcapcupsd -> service
lrwxrwxrwx 1 root root 7 Nov 7 02:17 rcatd -> service
lrwxrwxrwx 1 root root 7 Nov 7 02:21 rcauditd -> service
lrwxrwxrwx 1 root root 7 Nov 7 02:25 rcautofs -> service
: 略

/usr/sbin/service のスクリプトは /usr/bin/systemctl を呼び出します。これが systemd を制御します。/usr/lib/systemd/systemdに、デーモンの実体があります。

単純に systemctl を実行すると、サービスの一覧が出てきます。

sles12:~ # systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys..._misc.automount loaded active running Arbitrary Executable File F
sys-devi...i_video0.device loaded active plugged /sys/devices/pci0000:00/000
sys-devi...net-eth0.device loaded active plugged Ethernet Connection I217-V
sys-devi...sda-sda1.device loaded active plugged WDC_WD20EZRX-00D
sys-devi...sda-sda2.device loaded active plugged WDC_WD20EZRX-00D
sys-devi...sda-sda3.device loaded active plugged WDC_WD20EZRX-00D
sys-devi...sda-sda4.device loaded active plugged WDC_WD20EZRX-00D
sys-devi...sda-sda5.device loaded active plugged WDC_WD20EZRX-00D
sys-devi...sda-sda6.device loaded active plugged WDC_WD20EZRX-00D
: 以下略

systemctl は他にも、サービスの詳細な状態を調べたり、サービスの再起動、有効・無効化などのチェックに利用するコマンドです。

通常は yast(2) の Services Manager (従来の Run Level Editorに代わるもの)でサービスの起動と停止、有効・無効化、サービスの状態を調べます。
a0056607_8282344.jpg


a0056607_15132179.jpg


/sbin/init は実体はなく /usr/lib/systemd/systemd へリンクしているため、一応、従来の init コマンドと互換性を確保しています。

sles12:~ # whereis init
init: /sbin/init /etc/init.d /usr/share/man/man1/init.1.gz
/usr/src/linux-3.0.76-0.11/init /usr/src/linux-3.12.28-4/init
sles12:~ # ls /sbin/init -al
lrwxrwxrwx 1 root root 26 Nov 7 02:00 /sbin/init -> ../usr/lib/systemd/systemd
sles12:~ #

更に詳しい説明は管理ガイドをご参考ください。
SUSE Linux Enterprise Server 12 管理ガイド

当たり前の事ですが、起動は早くなっても中で systemd がサービスを処理しているため、 Login: プロンプトが出てからの動作は非常に重いです。

サービスの再起動や再起動などで init を使っていたクセがあった私にとっては

さらば init

なのですね。

-Key Word-
SUSE Linux SLES12 init initd systemd systemctl サービスの管理 サービスの起動 サービスの終了 サービスの再起動 できない。

他の情報はこちら
islandcenter.jp
[PR]
# by islandcenter | 2014-11-11 08:38 | SUSE | Trackback | Comments(0)

前回、Hyper-V 環境に SUSE Linux Enterprise Server 12 (SLES12) をインストールし、インストールの流れを見てみました。
SUSE (SLES 12) ファーストインプレッション

数年ぶりのメジャーアップデートなので SUSE Linux Enterprise Server 12 (SLES12) は様々な所でインターフェースが従来と異なっています。openSUSE 12/13 に近い感じです。バージョンは SLES12 ですが、細かな点は openSUSE 13 の技術が反映されています。これを「進化」と捉えるべきか、「改良」と捉えるべきか、「改悪」と捉えるべきかは、様々なご意見があるでしょう。

実際にインターフェースが異なるために SLES9/10/11 から SLES12 に移行すると戸惑う事が多いでしょう。その一つが XEN による仮想マシンの追加です。

yast2 > virt-manager より従来のアイコン "Create New Virtual Machine" をクリックすると
a0056607_9283646.jpg


こんな画面が出てきます。ここでは選択肢として、

- ネットワークブート
- 仮想マシンのイメージのインポート

です。iso や 物理DVDからの作成はできない様になっています。しかし一番下の Paravirt を Full Virt に変えると ISO からのインストールができる様になります。
a0056607_929285.jpg

「何! SLES12 は完全仮想化(Full Virtual)しかできないのか?」

とビックリする事になります。そこで、ネットワークブートする環境をどう構築するのか、という悩みにぶち当たってしまいます。

また "Create New Virtual Machine" から作成すると、仮想マシンの作成は ISO イメージを自動判別してウィザード形式で行われます。
a0056607_9314936.jpg


SLES12 上で SLES を準仮想化(Para virt)するにはどうすればよいのでしょうか。

"Create New Virtual Machine" の右横のドロップダウンボタンを押すと "VM-Install" という項目が出ます。
a0056607_9325351.jpg

ここからインストールすると、従来のインターフェースで仮想マシンの作成ができます。
a0056607_9331819.jpg

勿論 ISO からのインストールも Full/Para Virtual の選択もできます。
a0056607_9371691.jpg


この手順で準仮想化した SLES12 ではちゃんと XEN 用のドライバも読み込まれています。

linux-vugj:~ # cat /var/log/messages | grep xen
2014-11-07T05:57:34.348173+09:00 linux-vugj kernel: [ 0.000000] Linux version 3.12.28-4-xen (geeko@buildhost) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4)
2014-11-07T05:57:34.348331+09:00 linux-vugj kernel: [ 0.162190] xen_mem: Initialising balloon driver.
2014-11-07T05:57:34.348340+09:00 linux-vugj kernel: [ 0.162190] Switched to clocksource xen
2014-11-07T05:57:34.348445+09:00 linux-vugj kernel: [ 1.843152] xenbus_probe: Device with no driver: device/vbd/51712
2014-11-07T05:57:34.348446+09:00 linux-vugj kernel: [ 1.843153] xenbus_probe: Device with no driver: device/vbd/51728
2014-11-07T05:57:34.348447+09:00 linux-vugj kernel: [ 1.843154] xenbus_probe: Device with no driver: device/vif/0
2014-11-07T05:57:34.348454+09:00 linux-vugj kernel: [ 2.004701] xen-vbd: registered block device major 202
linux-vugj:~ #
linux-vugj:~ # uname -a
Linux linux-vugj 3.12.28-4-xen #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux
linux-vugj:~ #

実際に SLES12 on SLES12+XEN で仮想化してみると、SLES12 on Windows+Hyper-V より遥かに高速で、インストール時間も6割程度の時間で済みました。しかも動作自体が全く快適です。

Hyper-V の遅さ、激重さにはイライラします。Microsoft は真剣に NTFS に変わるファイルシステムを開発すべきであると実感します。
Hyper-V に手を出せない理由

もう少し解説してみました。
SUSE SLES12 の XEN仮想化管理

SLES12 の日本語導入ガイドはこちら
SUSE Linux Enterprise Server 12 導入ガイド

その他の情報は
islandcenter.jp
[PR]
# by islandcenter | 2014-11-08 09:55 | SUSE | Trackback | Comments(0)

本来なら、ニューマシーンに SLES12 を導入してみたかったのですが、色々な事情(察してください)がありまして、既存の SUSE Enterprise Server 11 sp3 (SLES11sp3) をアップデートしてみました。

1) ウェルカムスクリーンまで時間がかかる。

Boot から周辺デバイスの認識まで時間がかかります。5分くらいかかったでしょうか。ロゴスクリーンが表示されなくて、ビックリしましたが、Boot のログが流れた後 F2 キーを押すと、黒いロゴスクリーンの代わりにちゃんと何かのF2の制御コードのテキストが表示されました。

そこからは、通常のアップデートの手順です。インタビューに答えながら、ほぼ現状の設定を引き継いでアップデートしてくれました。

アップデートするパッケージを置き換える作業なので、アップデートは時間がかかります。手持ちのPCでは約40分程かかりました。勿論CDからの読出しに時間がかかることは言うまでもありません。

2) 全体的に軽くなった。

特に起動と、シャットダウンは特に早くなりました。XEN 4.4 では従来のシャットダウンに伴う仮想PCの終了処理も高速なようです。

3) 特に指定しなければ gnome

私のように gnome ばかり使っている人にはこれでいいと思います。SUSE9/10/11 と gnome がデフォルトでしたので、これでいい。ただ、インターフェースがずいぶん変わってしまったのは残念です。

4) カーネルは 3.12.28 XEN は 4.41

sles12:~ # uname -a
Linux sles12 3.12.28-4-xen #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux
sles12:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 0
# This file is deprecated and will be removed in a future service pack or release.
# Please check /etc/os-release for details about this release.
sles12:~ # rpm -qa xen
xen-4.4.1_06-2.2.x86_64
sles12:~ #


5) XEN 回りの変更

SLES12 の XEN 環境はそこそこに問題を抱えつつ無事移行しました。

5-1) xm -> xl コマンドに変更

/usr/sbin/xm コマンドは xl にリネーム変更されました。これも openSUSE13.1 と同じです。ちょっと戸惑うし、cron などで、定時再起動を行う環境では問題になるでしょう、

5-2) virt-manager に仮想マシンのリストが表示されなくなった。

a0056607_165357.jpg


これはちょっとのけ反りました。「リストにない」virt-manager に仮想マシンをリストアップするには、一旦仮想マシンをイメージを元に作り直す必要があります。/etc/xen/vm の仮想マシンの起動パラメータを見ながら、virt-manager から作り出します。

ちなみに、直接 xl create で仮想マシンを起動しても virt-manager にはリストアップされません。これも注意が必要です。 xl list を使うと動いているのが判ります。

5-3)

-f オプションを付けないと xl create できなくなった。

sles12:~ # xl create wsus
Failed to read config file: wsus: No such file or directory
sles12:~ # cd /etc/xen/vm
sles12:/etc/xen/vm # xl create wsus
Parsing config from wsus
WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
sles12:/etc/xen/vm #
sles12:/etc/xen/vm # xl destroy wsus
sles12:/etc/xen/vm # cd
sles12:~ #
sles12:~ # xl create -f /etc/xen/vm/wsus
Parsing config from /etc/xen/vm/wsus
WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware
WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model
sles12:~ #

これまで xm create myvm を実行すると、デフォルトで /etc/xen/vm 以下のパラメータファイルを読みに行ったのですが、明示的に -f オプションを付けて指定するか、直接 /etc/xen/vm 以下で実行する必要があります。

また、上にあるようなちょっと変な警告が出ていますので、これは修正が必要かもしれません。動作に影響はありませんでした。

6) xming で yast2 が起動できない。

xming で接続はできますが、yast2 & を実行すると、強制終了しました。nautilus & は動きます。 SLES12 では今のところ movaXterm が推奨です。

アップデートインストールをしてみたセカンドインプレッションはこんな所です。


-参考文献-
SUSE Linux Enterprise Server 12 導入ガイド SUSE 公式

いずれにせよ XEN 回りはかなり変わってしまったので、もう一度レポートします。


そのほかの情報は
islandcenter.jp
[PR]
# by islandcenter | 2014-11-07 16:03 | SUSE | Trackback | Comments(0)

よく文章を作るアイディアパッドとして Evernote を使います。個人としては便利なのですが、 Evernote を使って他人とアイディアを共有しようと言うつもりはありません。同じことが DropBox 始め、様々なクラウドのストレージサービスに言えます。

相手の事を考えてみましょう。

私が Evernote のある文書を、誰か他者のユーザと共有できる、と触れ込んでも、その方は使ってくれるでしょうか。

まずは、相手が共有を受け入れてくれるかどうか。

次に、こちらがアップデートした情報を読んでくれるかどうか。

そして共有したい情報を気軽にアップデートしてくれるかどうか。

これらを考えると社外のユーザとの情報共有というのは非常に「難しい」と言えます。

単にセキュリティ上の問題だけではありません。あるいは情報漏えいに繋がるのではないか、という問題でもありません。

相手の文化の問題です。

相手の文化に自分のやり方を押し付ける。

これは中々できるものではありません。

ちなみに、私は Microsoft Office を使いません。Libre Office を愛用しています。とは言え、せいぜい見積書を作るとか簡単なレイアウトを使った文書を作るだけです。大抵、問題なく相手は開けます。そんな私の元に、あの悪名高い "Excel 方眼紙" のフォームが送られました。Libre Calc で読めるし変更もできるのですが、返送したら、見事に文字化けしたそうです。

たったそれだけの事で何万円もする Microsoft Office を必要だと思いません。これも仕事のやり方の押し付けです。

私も経験があるのですが、gmail のアカウントを作ったので、そのアカウントから、システムベンダーに問い合わせる様に、というルールを押し付けられた事があります。しかもセキュリティ上「メールは POP してはならん」ということです。全てウェブ上で作業を済ませろというルールです。

先方はそのルールで長年お仕事をしてこられたので、受け入れやすく、こちらにも押し付けることができます。またそのルールには長けています。

私は既に gmail のアカウントを持っていて、様々な Google のサービスを利用しています。そのアカウントを捨てて、別な gmail のアカウントを使う事を強制するわけですね。そのアカウントでログインしている限り、Google カレンダーにもアクセスできない。しかもパスワードは複雑で、共有する以上、パスワードの変更はできない。

しかし、こちらは長年POPメールを使っていて、メールのバックアップも取る習慣がある訳です。
当然その運用ルールには慣れる事ができませんでした。先方としては「便利だから」という理由なのですが、それは便利の押し付けに過ぎません。こちらでは便利なものでも相手には非常に不自由で不愉快なこともあるわけです。

これはグループウェアを使う時、最大の問題となる点です。

特にスケジュール管理は、手帳でやる人、スマートデバイスを使う人、それぞれやり方が違うところに、無理やりグループウェアを導入しても、手持ちの手帳に転記するわけにもいかないし、使っているスマートデバイスが対応していなければ、結局誰も使わなくなります。

Yahoo のカレンダーを使っている人が、先方との打ち合わせや、資料を Yahoo のカレンダーにアップしても、誰も使わないでしょう。その本人にとって便利なことでも、相手には単に迷惑になるだけなのですね。

この様なお付き合いが爆発的に増えると、朝のチェック項目が爆発的に増えてしまいます。

取引上、弱者は、相手のルールに従わざるを得ません。それだけ時間もコストもかかるということを元請は考慮しません。

という事で、連絡や資料の共有などは、徹底的にレガシーな方法、電話か電子メールで済ませます。
[PR]
# by islandcenter | 2014-11-04 15:32 | Trackback | Comments(0)

SUSE Linux Enterprise Server 12 (SLES12) の評価版が入手できましたので、早速インストールの流れを見てみました。

1枚目のDVDは2.7Gb、 SLES11sp3 が 3.4Gb あったことを考えると、ずいぶんパッケージ類を絞り込んだ様です。

※ SLES12 から 32bit 版はなくなったそうです。だからでしょうね。

とりあえず SLES11sp3 の XEN 環境に入れてみました。

- メモリ:512Mb
- 仮想ディスクサイズ:8G バイト
- 仮想CPU:4vcpu
- SLE11 のテンプレート

SLES12 はSUSE が Novell からスピンアウトして初めてのメジャーバージョンアップです。まず随分インストーラの印象が変わりました。
a0056607_238532.jpg

今どきの商用 Linux でも 512Mb でGUIインストーラが起動できる所は中々良いことです。

いつも通り、言語は変なJapaneseを避けて English のまま、キーボード配列だけJapaneseを選び Licenseに Agree をチェックして次へ
a0056607_23105869.jpg


次の画面でいきなり SUSE Customer Center への登録画面です。ここは後でも良いのでスキップ
a0056607_127993.jpg


次にアドオンプログラムの指定ができます。ここでは何も追加アプリケーションがないのでそのまま次へ
a0056607_130136.jpg


さて、ここでいきなり難関です。ここではどのファイルフォーマットを選択するかを指定します。
a0056607_1321853.jpg


SLES12 では btrfs がデフォルトとなりました。EXT4 を選ぶ事もできます。SLES11 で標準だった ext3 は選択肢にありませんね。
a0056607_134385.jpg

SLES12 ext3 から BTrFS への変換

SLES12が採用した btrfs, snapper を使った Snap Shot


タイムゾーンの選択です。地図から東京あたりをクリックして Asia/Japan を選択します。 Hardware Clock set to UTC はチェックを外します。この機能は、OSが管理するクロックをハードウェアと同期させるもので、仮想環境では意味がないので、使いません。警告がでるのでOK
a0056607_1383861.jpg


次にオペレータのフルネームとログイン名/パスワードをセット
a0056607_1401019.jpg


続いて root のパスワードをセットします。3番目は確認用のボックスです。キーボード設定によっては符号文字がパスワードにセットされた場合、違うキーに割り当てられるので、ここで確認します。親切設計です。
a0056607_1431859.jpg


インストールのサマリ画面です。ファイアウォールはデフォルトで Enable なので、とりあえず Disable に変更します。
a0056607_146669.jpg


さてこれがちょっと判りにくい Default System Target なのですが、これはつまり runlevel を3(Multi User Network) にするか 5(XDMのGUIログイン) にするかの選択です。従来の RunLevel Editor の置き換えです。
a0056607_1501325.jpg

※追記:SLES12 から初期化プロセスは initd から systemd に置き換わった事が大きな変更点です。openSUSE 12.1 より systemd が採用されています。ここでまずハマります。
SUSE SLES12 の大きな変化 systemd、さらば init

Software リンクから、追加するアプリケーションセットをチェックします。ここでは WEB/LAMP を選んでみました。
a0056607_1531191.jpg

この設定はインストールした後 YaST の Software Management からでも行えます。

Auto YaST のレスポンスファイルの作成は、何百台とインストールするわけでなければ、作る必要がないのでチェックを外します。

全ての選択ができたら、Install を開始します。
a0056607_157188.jpg


インストールが開始されました。 Detail タブを押すと、インストールの進捗状況が判ります。
a0056607_1575648.jpg


大体ここから15分から20分程度でインストールが終わり、再起動します。

ここで問題発生
さてリブートした後なのですが、再起動すると XEN が「カーネルが見つからん」となり、インストール作業が進みません。ホストが SLES11 だからでしょうか。 「XEN のカーネルの問題」はそうあるものではないので、今のところ原因不明。

ということで Hyper-V に入れてみた

急きょ Hyper-V に入れてみました。Linux に比べるとやっぱり Windows ベースの Hyper-V は劇重です。512Mb のメモリでは、設定を変更する時にあまりにも遅いので、シャットダウンして900Mb のメモリを与えてみました。それでも SLES に入れるよりレスポンスが悪くて一つ一つが遅い。インストールは3割程度、余計に時間が掛かりました。マシンの性能もありますが、やっぱり Hyper-V は厳しいですね。

間違えて GUI 起動させたので何となくこれならつかえそうな、いつもの画面が出てきました。
a0056607_274988.jpg

YaST の GUI 版は openSUSE 12 と同じデザインになりました。このデザイン好きじゃないンだけどなぁ。

一旦 init 3 で起動して startx を実行すると、なんとこの画面になりました。
a0056607_2173690.jpg

openSUSE12 の gnome 版を入れた時のデザインそのものです。実はこのスクリーンが大嫌いなので、あまり openSUSE は好みではないのですが、ちょっとがっかりです。ターミナル開くにも、いちいち Activities > アプリケーションボタン>"term" で検索して実行。今悪評の真っただ中の Windows8 並に使いづらいUIです。今までは壁紙から右ボタンでテキストターミナル開けたンだけどなぁ。がっかりしています。

runlevel editor は System Manager という名前になりました。困惑しています。
a0056607_2233991.jpg

※追記:ここが init から systemd に変わった部分!

Default System Target で runlevel を決めます。
a0056607_2244213.jpg


ホスト名とネットワークの設定項目がない
ここまでの流れの中で、

1) ネットワークの固定IPを設定する箇所がない。(DHCP)
2) ホスト名を設定する事ができない。(linux-xxxxxとなる)
3) XEN,KVMの選択、仮想化する/しないの選択がない。

の3か所に問題がありました。もっとも XEN ではなく Hyper-V 上で動かした罰なのかもしれませんが、ログを見る限り Hyper-V のドライバは読み込まれているので、これでOKなのでしょう。


1) はインストールが終わって YaST の Network Settings で固定IPにします。
2) は /etc/HOSTNAME を編集して再起動すれば、プロンプトが好みのコンピュータ名に変わります。
3) はベアハードウェアで試してみます。

最後に

かなり印象も変わったので今まで SLES9/10/11 に慣れていた人でも、一瞬「なんじゃこれ」というシーンがありました。「良くなった」と前向きに考えるか「使いにくくなった」と思うかは主観の問題でしょう。全体的に openSUSE に似てきたなぁ、という印象です。

幾分、インストールの手順や、用語、画面のデザインが変わったため、従来の運用、操作マニュアルなどは、変更する必要があります。 SLES10/11 では、多少画面のデザインが違う程度なので、笑ってごまかすことができました。
しかし SLES12 では、全面的に作り替える必要があります。

また、SLES11 よりサイズが小さくなった分、今までDVDに入っていたパッケージも幾つかはなくなっているはずなので、その点も注意が必要です。

ちなみに、カーネルのバージョン、リリース名などは以下の通りです。

sles12:~ # uname -a
Linux sles12 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux
sles12:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 0
# This file is deprecated and will be removed in a future service pack or release.
# Please check /etc/os-release for details about this release.
sles12:~ #


今度は実ハードウェアに入れてみて、慣れていくしかないでしょうね。

関連記事:
そうか、systemd ってこういうモノだったんだ!
SUSE SLES12 の大きな変化 systemd、さらば init
SLES12 ext3 から BTrFS への変換

SLES12が採用した btrfs, snapper を使った Snap Shot

SUSE SLES12 の XEN仮想化管理

SLES12 大きく変わった仮想化管理



お問い合わせ
islandcenter.jp

-KeyWord-

SUSE 12 SLES12 SUSE Linux Enterprise Server 12 XEN 仮想化 Hyper-V インストール手順
[PR]
# by islandcenter | 2014-11-03 19:03 | SUSE | Trackback | Comments(0)

SUSE Linux Enterprise Server 12 リリースされました。

評価版は既にダウンロードできる状態です。
https://download.suse.com/index.jsp

SUSE Linux Enterprise 12」がリリース--ジオクラスタリングなどの新機能
http://japan.zdnet.com/os/analysis/35055734/

ファーストインプレッションは後ほどに。
[PR]
# by islandcenter | 2014-10-31 19:29 | SUSE | Trackback | Comments(0)

メールに送付するドキュメントを圧縮してパスワードをかけろ、というポリシーをよく聞きます。

そういうポリシーで運用し、ユーザに励行するよう定めているところも多いでしょうね。

私もそれが、最善だと思っていました。

あまり意味がないなという事にある日気が付いてしまったのです。

メールの盗聴には確かに効果はあるでしょう。
しかし、その対策だけの効果しかありません。

メールに添付ファイル付けて、別便でパスワードを送る。人によっては、ほぼ同時にメールを送ってきます。メールの盗聴はタイミングでエイヤでやる訳ではなく、特定のユーザや送信相手。あるいは一網打尽方式でスニッフィングする訳ですから、あまり効果はありません。

「添付ファイルはパスワード付です、パスワードは××です」と同じメールに書くこととあまり違いはありません。

もっともスニッフィングでどれだけのメールの盗聴が可能かは私は知りませんが、現代のスイッチングネットワークではスニッフィングして、メールの中身を読む事はできません。昔のノンスイッチのHUBならスニッファーで読み放題でしたが。もっともスイッチングHUBでも、専用のスニッフィングっポートを使えば、全てのパケットをキャプチャできますが、一般的なISPの場合、通信の秘密がある訳ですから、システムトラブルでもない限り、一般人のメールがスニッフィングされることは、「基本的にない」筈です。

むしろ、送信ボックスを含むメールストレージ全体がごっそり被害にあった場合などが怖いわけです。とは言っても、その場合はもっと大事な内容のメールが全部被害を受ける訳ですから、これもあまり意味がない。

ということで、送信途中のスニッフィングが怖いなら、ファイルとは別な方法でパスワードを伝えた方が安全だということになります。例えば、フリーメールで圧縮ファイルを送って、パスワードは正規のメールアドレスを使うとかですね。これなら経路が違うから安全性は高いのです。

どうせ圧縮ファイルですから、相手に届いて、相手の記憶媒体に圧縮ファイルとして保存されていれば、パスワードを同便で送ろうが別便で送ろうが変わりはないのです。


さて、重要なファイルがパスワード付で届きました。受け取ったあなたは何をするのでしょう。

まず解凍します。

解凍したら、元のパスワード付ファイルはいらないわけですから、削除するかもしれません。そうすると生身のデータがそのまま受取人の記憶メディアの中にある訳です。これでは何のセキュリティ対策にもなりません。受け取った側のセキュリティポリシーの自由にされてしまいます。

少なくとも重要なファイルであるならば、取扱い注意の上、パスワード付で保管すべしと送信者はアドバイスすべきです。これは受け取った側にもかなりな労苦を生み出すものです。まぁそれだけの極秘情報であると受取るべきでしょう。

パスワード付圧縮ファイルを受け取る場合、別途、業務契約とは別に、取引上に詳細な守秘義務励行に関する覚書程度は交しておくべきです。

私はそんな世界転覆計画のような書面を受け取ることはまずないので、対策はしません。

勿論、受取人にとっては重要なファイルなわけですから、パスワードは「自分が使っているパスワード」にリセットしなければなりません。受け取ったまま、パスワード付の圧縮ファイルである場合、解凍が必要な都度、そのメールを探して解凍しなければならない訳ですね。

煩雑なことです。

ということで、パスワード付圧縮ファイルは送信側の自己満足を満たすセキュリティ対策であって、受け取った側のポリシーに従って扱われる可能性が高いわけですから、ほとんど意味ないじゃないか、と最近私は考えています。

islandcenter.jp
[PR]
# by islandcenter | 2014-10-29 14:38 | Trackback | Comments(0)

ファイルサーバーのメンテナンスや移行などで、ボリューム全体を読み込み専用にしたい場合があります。

ファイルサーバーのマイグレーションはほとんどの場合、ボリューム全体のアクセス権限をそっくり新しいサーバーに移行することです。

しかし「ファイルの棚卸」も重要なことで、これはシステム管理者の仕事ではなく利用部門が行うべきことです。つまり

「新しいボリュームにはデータは入っていないから、古いボリュームから『必要な』データだけ新しいサーバーに移行して欲しい」と宣言し、利用部門にデータの移行をおこなわせれば、どれほど「ゴミデータ」を抱え込んでいたのかを彼らも実際に実感するでしょう。実際に1Tバイトのファイルを保有していても、実際に業務に必要なファイルの棚卸をしてみると100Gバイトも必要なかった、という事に気が付いてくれると有難いものです。

また「とりあえず全部コピーしちゃえ」ということでは、莫大な時間が掛かることにきがつくわけで、やっぱりファイルの棚卸は重要なのです。

となると、古いサーバは読み込み専用にしてしまうのが一番効果があります。

Windows サーバーでは、ボリュームのプロパティから全体を「読み込み専用」にして

「サブフォルダにも適用する」

をチェックして実行するとディスクアクセスの嵐。
終わるまで、今日は帰って寝ようか、ということで翌日変なエラーで止まってショボーン、という事がある訳です。

また解除するためには、「読み取り専用」のフラグをリセットして「明日の朝の結果」を待つことになります。

--
Novell Openenterprise Server では NCPcon コマンド一発でボリューム全体を読み込み専用ボリュームに変更することができます。

How to mount an NCP volume as read-only.
https://www.netiq.com/support/kb/doc.php?id=7014969

マニュアルはこちら

https://www.novell.com/documentation/oes2/file_ncp_lx/data/ncpvol.html

実際に RW 可能なディスクがあります。
a0056607_12135850.jpg


これを読み込み専用に変更します。
oes11x1:/media/nss/VOL1 # ncpcon disable write VOL1
... Executing "disable write VOL1"
Volume write disabled.
... completed OK [elapsed time = 4 msecs 609 usecs]
a0056607_12142215.jpg


ユーザはファイルを書き込むことができません。
a0056607_12146100.jpg


読み込み専用を解除するには ncpcon enable write を実行します。
oes11x1:/media/nss/VOL1 # ncpcon enable write VOL1
... Executing "enable write VOL1"
Volume write enabled.

... completed OK [elapsed time = 419 usecs]
oes11x1:/media/nss/VOL1 #
a0056607_12172190.jpg


ファイルの書き込みが許可されました。
a0056607_12172022.jpg


ちなみにこれは NCP の機能ですので、直接サーバーコンソールから mkdir などをしても効果はありません。
a0056607_12312362.jpg


一般には、システム管理部門は、バックオフィスの経理や総務のデータには詳しくても、業務部門でどの情報が重要化までは判断できないものです。

この様に古いファイルサーバーのボリューム全体を読み込み専用にしておけば、ファイルサーバー移行から例えば「1か月の猶予」を置いて、事業部門のファイルの棚卸をさせます。

テープで古いサーバーのバックアップを取り、例えば「5年間だけ保管しておく」と宣言してしまえば、膨れ上がったサーバーのディスク容量がスリムになります。物理的なスリムさだけではありません。部門ユーザにとっても、必要、不要が判断できないファイルが多すぎると業務自体のボリュームが増えるのです。

その後古いサーバーを停止、破棄すればよいのです。

-Keyword-
Windows Novell OES Openenterprise Server ボリューム全体 ドライブ全体 読み込み専用 書き込み禁止


そのほかの情報は
islandcenter.jp
[PR]
# by islandcenter | 2014-10-08 10:48 | OES Linux | Trackback | Comments(0)