isLandcenter 非番中

ブログトップ | ログイン

タグ:システム管理 ( 128 ) タグの人気記事

zabbix5 で SNMP デバイスを監視する方法を説明します。 SNMP  管理機能がある手頃な機器がないので、ここでは openSUSE Leap 15.2 に snmpd を走らせて、監視対象としています。

Zabbix4 はこちら
Zabbix4.2 snmp監視 デバイスのグラフを表示させるまで

ー openSUSE Leap 15.2 の snmpd 

openSUSE Leap 15.2 ではデフォルトで net-snmp はインストールされています。

SUSE Linux Enterprise(SLE) ではインストールされていないので、YaST か zypper でインストールし、YaST > System > Service Manager より snmpd を Start/Enable にセットします。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15462244.png

ー community String と、送信相手の設定

/etc/snmp/snmpd.conf を編集し、次の行を変更して、送信先コミュニティストリングと、応答先のアドレス範囲を指定します。さらに詳細な設定ができますが、ここでは最小限の説明です。

# rocommunity public 127.0.0.1
rocommunity public 192.168.1.0/24

変更したら systemctl か YaST の Service Manager からリスタートします。

myhost:~ # systemctl restart snmpd

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15470668.png

ー snmp の応答確認

zabbix  サーバーから snmpwalk を使って、応答があるかどうか確認します。指定する OID は System の値 ”.1.3.6.1.2.1.1” あたりが適当でしょう。

# snmpwalk -v 2c -c CommunityString  target_host.Yourdomain .1.3.6.1.2.1.1

zabbix5:~ # snmpwalk -v 2c -c public myhost.i.islandcenter.jp .1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Linux myhost 5.3.18-lp152.63-default #1 SMP Mon Feb 1 17:31:55 UTC 2021 (98caa86) x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4839) 0:00:48.39
SNMPv2-MIB::sysContact.0 = STRING: Sysadmin (root@localhost)
SNMPv2-MIB::sysName.0 = STRING: myhost
SNMPv2-MIB::sysLocation.0 = STRING: Server Room

: 略

ー 監視ホストを zabbix に作成

詳細はマニュアルをご参考下さい。ここでは最低限の説明をしています。あまり役に立たないこのページよりも正しい事が書かれています。

1 CONFIGURING A HOST

snmp でネットワーク内のデバイスオブジェクトを作成し、snmpwalk で応答があった Linux デバイスの snmp 監視ターゲットを作成します。

左のメニューから Configuration > Hosts > 右上の "Create Host"

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15475378.png

Hostname : myhost
Group : Select > "Type of host" ここでは Linux Server
Interface > "Add"

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15482879.png


Interface > "snmp"
IP か DNS 名をセット(DNS名を使う時は”Connect to” を DNS に)ポートは 151  そのまま。
SNMP version は、デフォルトで v2、コミュニティストリングは、public なら、そのまま、必要に応じて変更

最後に "Add"

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15485173.png

ここで"public"以外の、コミュニティストリングをネットワーク全体で使っている場合、 Macros > Inherited and host macros > より 、下の方にある ”{$SNMP_COMMUNITY}” を Change して、別なコミュニティストリングに変更します。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15492639.png

テンプレートを指定します。

Hosts > MyHost > Template > Select > 一番近いテンプレートを選択:ここでは ”Linux SNMP” を選択します。

”Update” で登録更新します。

※複数のテンプレートが選べますが、AND 条件でダブるとエラーになります。例えば Linux SNMP と Generic SNMP は同居できません。

※テンプレートは Zabbix Share https://share.zabbix.com/ に豊富にありますが、一発では動かない事が多いです。

Zabbix をアップデートした場合は、旧バージョンのテンプレートが引き継がれるため、テンプレートの選択はかなりややこしくなります。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15501248.png

登録して Configuration > Hosts のリストの中に、登録したホストが出てきて、数分以内に右の Availability が「緑 SNMP」 になれば、とりあえずオーケーですが、グラフの描画が始まりません。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15514575.png

グラフを見るには

Monitoring > Latest data より、Host Group > Select , Host > Select,  Application > 監視するアイテム、ここでは CPU を選んでいます。試しに CPU Utilization にチェックを付けて”Display Graph” を押します。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15522271.png

CPU使用率のグラフが確認できました。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15525666.png

ー 監視アプリケーションの有効化

とりあえず CPU 負荷はすぐグラフ化できましたが、他の情報を見るには Application を Enable にする必要があるようです。
Configuration > Hosts > "Myhost" を選び "Applications" のリンクを押して、全ての "Applications" を Check して Enable ボタンを押します。

同様の操作を "Items" についても行います。

zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15532745.png

開始してから、最低 3600 秒、一時間待ちます。しばらく放置した後

Monitoring > Latest data > Host > Application : interface

でトラフィック送受信のグラフが描画されました。
zabbix 5.2  openSUSE Leap 15.2 SNMP でデバイス監視_a0056607_15540433.png

ー まとめ

Zabbix で SNMP 監視ルータやスイッチの死活・トラフィック監視がは、見えない物を見える化する事です。

とりあえず、Linux Host を対象に zabbix から最低限のリソース管理ができました。SNMP 監視は設定方法に当たり外れが多いようです。まずは最低限、見たいことが見れればラッキーかもしれません。グラフの描画が始まらないのは焦りますが、とにかく一時間以上待って変化がないかチェックします。

まずはデフォルトでは3600 秒 、一時間ごとに SNMP でデバイスの値をディスカバリーるようなので、焦ってはいけないという事です。

テンプレートをとっかえひっかえしている内にグラフが描画される場合もあります。Applicatin を Enable すると動く場合もありました。何をどうすれば、SNMP での監視タスクを作れるかの最適解はまだ見つけていません。

Zabbix の難点ですが、マイナーなバージョン変更でもUIが変わったり、テンプレートが追加されてしまい、過去の経験とは違う手順を踏まなければならない事があります。バージョンアップする場合は、書籍の情報や、素人っぽい私のブログの様を参考せず、そのバージョンのオフィシャルドキュメントを見ておく事です。バージョンによって大きく手順が違う場合があります。

あわせて読みたい

Zabbix 5.2 on openSUSE Leap 15.2 インストール

zabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定






by islandcenter | 2021-03-01 16:01 | Linux | Comments(0)

Zabbix 5.2 on openSUSE Leap 15.2 Install

openSUSE Leap 15 の良い所は、有償版 SUSE Linux Enterprise 15 (SLE15) と、バイナリレベルの互換性があり、openSUSE Leap 15 から SLE へのアップデートが保証されている、という点です。SLE から openSUSE へ乗り換えても、ほとんど操作に違和感がなく、スムーズに移行できます。

openSUSE Leap は RHEL --> CentOS の様な、ソースレベルの互換性、クローンではありません。有償版 SLE のサブスクリプション購入の前に、openSUSE Leap で、とりあえず検証、トレーニングを行ってから、SLEに移行するというパスが用意されています。

ー zabbix

zabbix はヨーロッパ・ラトビア生まれのオープンソースライセンスのネットワーク管理ツールです。エージェントを使ったサーバーの負荷やリソース管理、SNMP を使ったルータやスイッチのトラフィック監視、Ping などサービスの死活監視など、広い用途でネットワークを監視できます。この種のソフトウェアとしては急速に利用者が増えており、キラーアプリケーション化して育ったプロダクトです。

何よりUIがブラウザという事で、操作に必要なプラットフォームを選びません。サーバーは主要なディストリビューションを網羅しています。

という事で、openSUSE Leap 15.2 に SLE 15 用の zabbix 5.2をインストールする手順を検証してみました。

zabbix5.2 をインストールする前の、openSUSE Leap 15,2 のインストール、Web LAMP のインストールは、次の記事、動画を参考にしてください。

ー Install openSUSE Leap 15.2

openSUSE Leap 15.2 のインストールは次の記事、動画を参考にしてください。

openSUSE Leap 15.2 Install First Look.(インストール)
https://www.youtube.com/watch?v=TvzrveD5lys (動画、音出ます)

※ /var は異なる仮想ディスク、別パーティションにしています。/var/lib/mysql/zabbixdb に zabbix データベースが作られます。/ パーティションは BtrFS 16Gb 以上、/var は別な仮想ディスクとして XFS フォーマット、10Gb 程度あれば、規模にもよりますがとりあえず充分でしょう。

ー Install Web LAMP on openSUSE Leap 15.2

openSUSE Leap がインストールできたら、Web LAMP 環境を導入します。大体の手順は次の動画を参考にしてください。

openSUSE Leap 15.2 Web LAMP install with YaST(動画、音出ます)

それでは zabbix5 をインストールします。

ー mariadb  の有効化

まずは、mariadb をスタートさせ、起動を有効化します。

 YaST > System > Service Manager から mariadb Start/Enable します。もしくは systemctl で起動します。

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13190152.png


ー Download and install Zabbix

https://www.zabbix.com を開いて右上の DOWNLOAD リンクを開きます。 

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13202641.png

バージョン > Distribution(SLES) > Version(15) > DBタイプ(MySQL) > Web Server(Apache) の順でクリックするか、ここでは次の URL を開きます。


Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13210736.png

このページに、必要なコマンドラインのサジェスチョンが記載されているので、順に実行します。

ー リポジトリの登録

rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm
zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'

YaST で確認します。

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13220703.png

次の操作は openSUSE Leap では不要です。

# SUSEConnect -p sle-module-web-scripting/15/x86_64

― パッケージのインストール

zypper か YaST を使って次のパッケージをインストールします。

zabbix-server-mysql
zabbix-web-mysql
zabbix-apache-conf
zabbix-agent
zabbix-web-japanese (<- 日本語化する場合必要)

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13224643.png


ー MySQL の開始/設定

事前に決定しておく事。ここでは次のユーザ名、パスワード、データベース名を使います。適時おき替えてください。

mysql の root パスワード : mysqlpwd
Zabbix Database 名: zabbixdb
Zabbix Database ユーザ/パスワード: zabbix/zdbpwd 

ー mysql の DB 作成

mysql -uroot -p
mysqlpwd
mysql> create database zabbixdb character set utf8 collate utf8_bin;
mysql> create user zabbix@localhost identified by 'zdbpwd';
mysql> grant all privileges on zabbixdb.* to zabbix@localhost;
mysql> show databases;
mysql> quit;

ー スキーマ拡張

zcat /usr/share/doc/packages/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbixdb
Enter password: zdbpwd

5分待ちます。

ー zabbix_server.conf の書き換え

zabbix_server.conf の次の三か所を必要に応じて書き換えます。

gedit /etc/zabbix/zabbix_server.conf &

DBUser=zabbix
DBName=zabbixdb
DBPassword=zdbpwd

ー restart zabbix_server

YaST か systectl コマンドで zabbix_server/agent, apache2 を onboot  start/enable にします。

systemctrl restart zabbix_server zabbix_agent apache2
systemctrl enable zabbix_server zabbix_agent

yast > System > Service Manager

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13232630.png

ー フロントエンドの起動、セットアップ


言語の選択 > とりあえず英語のまま次へ

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13250432.png

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13253426.png

データベースへ接続

Database name: zabbixdb
user: zabbix
password: zbxpwd

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_14225710.png

Server Detail : 特に変更なくNext

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13262909.png


Default Time Zone : UTC+9 Asia/Tokyo

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13271759.png


Summary

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13273531.png

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13281075.png

WebUI ログイン

Login:
Admin/zabbix (デフォルト初期値です case sensitive 大文字小文字注意)

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13283014.png


Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13284376.png

フロントエンドのセットアップが終わると、ダッシュボードが起動します。ダッシュボードの時計がローカルタイムになっている事を確認してください。

Monitering > Hosts > Zabbix Server が(ZBX 緑)になっていれば、サーバー/エージェント共に稼働中です。

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13290074.png

グラフも出てきました。

Zabbix 5.2 on openSUSE Leap 15.2 Install_a0056607_13291878.png

ー ポイント(忘れがちなこと)

・データベース名、DBユーザ名、パスワードは事前に決めておく事です。ダウンロードページの指示通りでも構いませんが、デフォルト password じゃいかにもですからね。大抵、何らかのエラーが起こるとすれば、この三つの設定がおかしい。
・Web LAMP のインストール手順が、サジェスチョンに含まれていないので、事前にインストールして mariadb を起動しておく事。
・WebUI へのログインは Admin/zabbix です。ケースセンシティブ、大文字小文字注意です。クラウド運用する時は早めに変更しておく事。
・ UI のURLは、http://ip-address/zabbix です。/index.html を書き換えて、リダイレクトすると良いでしょう。

ー まとめ

openSUSE Leap 15.2 で zabbix5.2 をインストールしてみました。公式サポートは SUSE Linux Enterprise 15 ですが、インストール自体は幾つかの間違えやすい点に注意すれば、特にストレスなく行えます。

CentOS8 の将来性に不安があるのなら、無償でオープンフリーの openSUSE Leap は、SLE の信頼性を引き継いでおり、rpm に慣れていて Debian/Ubuntu 系はちょっと、というシステム管理者にとっては一つの代替手段になります。

大規模なデータセンターでもなく、数十台のサーバー、スイッチなどのデバイスを管理したい中小規模のネットワークなら openSUSE Leap + zabbix の組み合わせは一つの良い選択になります。既に仮想環境が用意できているのなら、Zabbix5 は是非試して欲しいネットワーク管理ツールです。

zabbix5 で SUSE Linux15(SLE openSUSE Leap) を監視、snmp Agent, zabbix Agent の設定

zabbix4.2 を zabbix5.0 アップデート







by islandcenter | 2021-02-25 13:48 | SUSE | Comments(0)

Zabbix 5.2 がリリースされたので openSUSE 15.1 にインストールされた zabbix 5.0 からアップデートしてみました。

- Snapshot の削除と復元ポイントの作成 -

まず、大きな変更をする前に、システムのバックアップとスナップショットの確認をします。

もし KVM/XEN など、仮想化されたされたシステムをつかっているなら、仮想イメージのバックアップを取っておく事です。何が何でもバックアップは重要です。

次に、パーティションの空きを確保し、十分な空き容量があるかどうかを確認します。

yast2 > miscellaneous > Filesystem Snapshot (yast2 snapper) を起動して、スナップショットのうち、古いスナップショットを削除(Delete)します。スナップショットは定期的にメンテナンスされますが、パーティションの空きを最大確保するには、大きな変更点がある古いスナップショットを削除するのが最適とされます。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11173908.png

次に アップデート前の SnapShot を作成( Create ) します。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11185478.png

こちらの記事もご参考下さい。zypper up してシステム空き領域がなくなってしまってハマってしまう反省文です。

BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保

ちなみにデータベースは
/var/lib/mysql/zabbix
に作成される様です。ここは XFS フォーマットなのでスナップショットは取っていません。

本家 SUSE Enterprise Server のドキュメントもご参考下さい。

7 Snapperを使用したシステムの回復とスナップショット管理 REPORT DOCUMENTATION BUG#


- アップデート -

次のダウンロードページには SUSE Linux Enterprise 15 (SLES15) でのインストール手順です。今回はインストールではなくアップデートなので、

- リポジトリを変更して
- YaST でアップデート
- YaST で Zabbix を再起動

という手順です。

zabbix5.2 ダウンロード

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11222971.png

ダウンロードページにある次のコマンドを実行します。

# rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm
# zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'

zabbix:~ # rpm -Uvh --nosignature https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm
Retrieving https://repo.zabbix.com/zabbix/5.2/sles/15/x86_64/zabbix-release-5.2-1.sles15.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:zabbix-release-5.2-1.sles15 ################################# [ 50%]
Cleaning up / removing...
2:zabbix-release-5.0-1.el15 ################################# [100%]

zabbix:~ # zypper --gpg-auto-import-keys refresh 'Zabbix Official Repository'
Retrieving repository 'Zabbix Official Repository' metadata ................................[done]
Building repository 'Zabbix Official Repository' cache .....................................[done]
Specified repositories have been refreshed.
zabbix:~ #

次に YaST > Software Management > Software Repositories から、リポジトリが変更されている事を確認し "Enabeled" , "Autorefresh" の二つをチェックします。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11224356.png

次に YaST > Software Management から "zabbix" を Search して、Zabbix 5.2 のパッケージでチェック済み項目を全て、右ボタンで "Update" に変更します。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11232781.png

自動的にアップデートが始まります。

- サービスの再起動 -

YaST > System > Service Manager から、 Zabbix_Server/Agent の Start/Stop を切り替えて、サービスの再起動をして、状態が On boot/Active になっている事を確認します。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11235426.png


コマンドで再起動するには systemctrl コマンドを使います。

opensuse151:~ # systemctl restart zabbix-server.service
opensuse151:~ # systemctl restart zabbix-agent.service

サービスを再起動したら # tail /var/log/message して、エラーが出ていない事を確認しておきます。

アップデートが終わったら、 ブラウザで http://myzabbix_ip/zabbix にログインして、ダッシュボードの下中央にある Zabbix のバージョン番号を確認します。

openSUSE 15: zabbix5.0 から 5.2 へのアップデート_a0056607_11245526.png


どうやらうまく行ったみたいです。






by islandcenter | 2020-12-02 11:16 | SUSE | Comments(0)

ーセキュリティポリシーは、ホワイトカラーの業務改善の一つの要素であるー

PDCAサイクルから考えるセキュリティポリシーの見直し_a0056607_09193635.jpg

PDCA サイクルと呼ばれる「継続的改善」手法は、本来QC活動:「品質保証」用語として用いられます。

PDCAサイクル

-1. Plan : 計画
-2. Do : 実施
-3. Check : 見直し
-4. Action : 執行

という4つの要素がグルングルンとサイクリックに回って「品質改善」を目指そうという皆さんご存知の QC 活動ですね。

で、セキュリティポリシーというのは、ビジネス上重要な、ホワイトカラーにとっては一つの重要な「業務改善」の手段なのです。

ーなんの Plan もなくDo されて始まるセキュリティポリシーー

スタートアップビジネスでは、「とりあえずやっちまおう」的なノリで仕事を始めてしまうので、セキュリティポリシー自体の Pサイクル(Plan) も何もないところから始まって(Do) してしまいます。

つまり、セキュリティポリシー自体、何もないところから始まり、いつの間にか「慣習化」された理由で Do されているところがおおいのではないかとそう考える訳です。

これは、スタートアップ企業だけではなく、大手企業でのスタートアップビジネスにもあり得る話かもしれません。悪しき記憶として印された、ADSLビジネスを始めた頃のソフトバンクの大量の情報漏洩事故なんかがそうでしょう。なんの情報管理ポリシーもなかったわけですね。

ー文書化されたポリシーと慣習化されたセキュリティポリシーー

セキュリティポリシーに限らず、コンピュータシステムを使う上で重要なのは、運用ルールが文書化されているかどうかの視点です。コンピュータの命名規則や、ユーザアカウントの命名規則も、文書化されていれば破綻することは少ないでしょう。この様なルールも PDCA のサイクルで見直しが必要なのですが、不思議と文書化されている組織は少ないようです。多くの運用ルールは「慣習化」されたモノから始まるのです。

コンピュータ名(ホスト)の命名規則? 15文字の63バイト制限、ホスト名の命名権利はだれの責任?

ユーザアカウント名は8文字以内にすべきか?ユーザの命名規則の理由と対策

ー一番重要な Check サイクルー

セキュリティポリシーは「慣習化されたポリシー」と「文書化されたポリシー」の二つに分類されます。

そこで、セキュリティポリシーが「どういった理由でその様に慣習化されたのか」「文書化されたポリシーは徹底されているか、形骸化しているか、妥当かどうか」という「現状チェック」、つまり PDCA サイクルの Check のサイクルを把握し理解することがとても大切なのです。

この中で「慣習化されたポリシー」が「有効」と判断されたら、セキュリティポリシーの中に文書化すべきであるし、文書化されたポリシーでも、不適切で運用上、意味のないものであれば削除したり、方式を見直すべきなんですね。

特に文書化されていない「慣習化したポリシー」には、どういった背景があるかを吟味することは大切です。意外とエンドユーザの考えることは「妥当」であり「有用」な事が多いのです。

「取引先の要求でこんな感じで文書ファイルを扱わなければならない」

とか

「パスワードは難しく、かつ簡単にこんな風に個人的に管理している」

とか、色々あるわけですね。

特に「パスワードはメモ帳やノートに書かない」というのは、今の時代「死語」に等しいという事も、ユーザ部門はよくわかっているのです。

ー厳格なポリシーは形骸化し易いー

パスワードは大文字小文字記号混じりで12字以上、同じアルファベットはつかってはダチかんぞ、30日に一度パスワード変えないとダメだ、なんていうセキュリティポリシー、よく見ますよね。

しかしユーザはよく知っているのです。システム管理部門が知らないだけで、実業務に関してはユーザさんたちはその道の玉筋金太郎並みに抜け道を作るンです。自分のパスワードのルール化です。

意外と社内システムで使われるパスワードなんて、厳しくしなくても簡単には他人がわかるものじゃありません。それよりパスワードを管理して運用させるための利用者側、運用担当者双方のコストを考えれば、厳格なポリシーが如何に形骸化しやすいかを理解できそうなものです。

セキュリティの厳格化を誤ると、運用面でも形骸化が進み、本来守らなければならないルールも形骸化します。その結果「社内ルールがルーズになりセキュリティインシデントが発生する」「本来遵守すべき事項が守られず捏造されたセキュリティチェックだけが残された」という結果にも繋がりかねません。

こんなのは形骸化したルールを見直せば如何に現実性がなかったポリシーだったかがわかるでしょう。

霞ヶ関でパスワード付きzipファイルを廃止へ 平井デジタル相

ー同意を得てのアクションー

ここまで書いてみて、言いたいことは、セキュリティポリシーの PDCA サイクルは「利用者の日常業務の PDCA に関わるもの」だと言うことです。セキュリティポリシーの Check サイクルは、利用者の業務全般の、無理、無駄のチェックのプロセスを含み、業務の運用改善にも繋がるものなのです。

PDCA サイクルの中で重要なのは、Check のサイクルなのです。重要なものをチェックしてピックアップし、形骸化して意味をなさないポリシーは削除する。取捨選択して、現状をどう改善するか。Plan と Do はシステム運用者の業務の範疇でしょう。そして重要なのは Action に必要な、セキュリティポリシーの文書化と徹底するための組織を挙げての規定化です。

必要なことであれば、就業規則にも取り入れ、罰則規定も絡めて検討します。

ーセキュリティルールの習慣化ー

どの企業、組織にも「文化」というものがあります。セキュリティポリシーの習慣化、セキュリティ文化は、組織の意識を向上させます。

PDCA の Action がもたらした結果です。

よく「ウチは ISOxxxxx の認証を取っているから」という事をウリにする組織がありますが、あれは形骸化して「形だけのセールストーク」に使われる仕組みなんですね。

逆に安心して使える取引先は、たとえ ISMS認証がなくとも、数分お話しただけでしっかりしているな、という印象があるものです。ちょっとしたことでもスキがなく素人さんと話しても理路整然としています。

こういった組織はセキュリティだけではなく実業務についても信頼できてスキがないんです。






by islandcenter | 2020-11-18 16:02 | 雑文 | Comments(0)

BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保_a0056607_13230031.png

BtrFS の甘い罠、アップデートの前に空き容量を確保

どんなショボいシステムでも、安易に変更は加えない方がいいわけです。
openSUSE Leap 15.1 のシステムを

 # zypper dup

したところ、見事に罠にハマりました。BtrFS の罠です。スナップショットを取っているので、空き容量がなかったんです。
空き容量がないところでパッケージのアップデートなんかすると、openSUSE Leap 15x はルートパーティションが Copy On Write の BtrFS ですからファイルは上書きではなく、差分をドンドンと CoW してしまう。遂にディスクの空きを使い果たして、中途半端な zypper dup の結果、

「システムが立ち上がらない」

という最悪の結果に陥りました。BtrFS のスナップショットの残骸ってロック掛かっていて、レスキューディスクで起動しても消せないのですね。

という事で、BtrFS のファイルシステムに変更を加える場合は

「空き容量を確認して空きを確保してから行え」

という「鉄の法則」を学びました。



- BtrFS 空き容量確認 -

How much free space do I have? or My filesystem is full, and I've put almost nothing into it!

1 Linuxファイルシステムの概要

これらのドキュメントによると


 opensuse151:~ # btrfs fi show
Label: none  uuid: 8466aee4-2738-4b0a-924a-79edad4b4676
        Total devices 1 FS bytes used 8.13GiB
        devid    1 size 14.00GiB used 10.57GiB path /dev/vda2
opensuse151:~ #

"
ファイルシステムの合計サイズとその使用量を表示します。最後の行のこれら2つの値が一致する場合、ファイルシステム上の領域はすべて割り当て済みです。
"
上のケースでは14Gbのデバイスサイズのうち、 10.57Gb 使用中です。

opensuse151:~ # btrfs fi df /
Data, single: total=8.01GiB, used=7.50GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.25GiB, used=641.95MiB
GlobalReserve, single: total=30.22MiB, used=0.00B
opensuse151:~ #

"
ファイルシステムの割り当て済みの領域(total)および使用済みの領域の値を表示します。メタデータのtotalおよびusedの値がほぼ等しい場合、メタデータ用の領域はすべて割り当て済みです。

メタデータ 1.25 Gb 中、641Mb 使用中です。

opensuse151:~ # btrfs fi usage /
Overall:
    Device size:                  14.00GiB
    Device allocated:             10.57GiB
    Device unallocated:            3.43GiB
    Device missing:                  0.00B
    Used:                          8.76GiB
    Free (estimated):              3.93GiB      (min: 2.22GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               30.22MiB      (used: 0.00B)

Data,single: Size:8.01GiB, Used:7.50GiB
   /dev/vda2       8.01GiB

Metadata,DUP: Size:1.25GiB, Used:641.95MiB
   /dev/vda2       2.50GiB

System,DUP: Size:32.00MiB, Used:16.00KiB
   /dev/vda2      64.00MiB

Unallocated:
   /dev/vda2       3.43GiB
opensuse151:~ #


前の2つのコマンドを組み合わせたのと同様のデータを表示します

つまり btrfs fi usage <mount_point> が一番使われやすいコマンドだという事です。

- ncdu, du コマンド -

duコマンドは当てになりません。ncdu でルートからスキャンしたらこれ。このシステムは物理的に25Gbしかない仮想VMです。

BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保_a0056607_13232822.png

スナップショットサイズが「150Gb 使用中」と、あり得ない数字を示しています。

- 完全な見積は不可能 -

こちらの文書の中に

How much free space do I have? or My filesystem is full, and I've put almost nothing into it!

"
So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet.
"

Google 先生の翻訳によると

"
したがって、一般に、btrfsファイルシステムの空き容量を正確に見積もることは不可能です。はい、これは最悪です。ユーザーがどれだけのスペースを残したかを簡単に理解できるようにする方法について本当に良いアイデアがある場合は、私たちに知らせてください。また、btrfs開発の最高の心がこの問題について考えていることに注意してください。少なくとも数年間は、簡単な解決策はまだ見つかりませんでした。
"

とあり、もう BtrFS では、正確な空き容量確認は現時点で「不可能」と断じています。

そもそも、ファイルコピーの段階で、当然システムの API は空き容量を確認するわけですが、その元ネタは何なんだろうか? という疑問がわいてきます。

- BtrFS の鉄則 -

- 想定されるデータ量の倍のサイズのパーティション確保

例えば、openSUSE Leap 15.x では / (ルート)の BtrFS パーティションは、最低でも 15Gb のサイズ以上確保しておかないと、インストールの際、警告が出ます。実際のインストールで使用されるディスク容量は openSUSE Leap 15.2/SLE15 で 7.5 Gb 程度です。SLE12 では6Gb 程度でした。

空き容量の把握は難しいので、長期運用でバージョンアップに伴い必要とされる空き容量は、将来に渡って不明です。将来バージョンアップしたり、パッチを頻繁に充てるクリティカルなシステムなら 25Gb ~ 30Gb 程度のルートパーティションサイズが欲しいところです。「ディスク容量を食う」点は、誰も指摘していませんが BtrFS の隠されたデメリットです。

もし、コンパクトで JeOS な仮想サーバーを作りたいのであれば ext3、4 などの古来のファイルシステムを検討すれば 10Gb 程度でも使えるわけです。

- スナップショットの定期的なメンテナンス scrub

デフォルトではシステムは毎週 scrub によるメタデータの修復、デフラグ、破損ファイルの修復を実行します。scrub はファイルシステムの破損などがないかメタデータをチェックし、自動修復する機能です。sysconfig に設定されます。BtrFS の信頼性を確保するための重要な機能です。

BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保_a0056607_13241420.png


手動で scrub するには

# brtfs scrub start <mount point>

を実行し、 btrfs scrub status -d -R <mount point> で結果を確認できます。

- スナップショットのメンテナンス

スナップショットの作成と削除は自動化されています。こちらの文書によると SUSE Linux(SLE15) においては

7.1.3.4 スナップショットのアーカイブの制御

"
デフォルトでは、最大10個の重要なインストールスナップショットと管理スナップショット、および最大10個の標準のインストールスナップショットと管理スナップショットが保持されます。これらのスナップショットがルートファイルシステムのサイズの50%超を占有する場合、追加のスナップショットは削除されます。最低でも、4つの重要なスナップショットと2つの標準スナップショットは常に保持されます。
"

とあり、この定義は snapper -c MySnapConfig create-config <partition> によって作成された /etc/snapper/configs/ にされた MySnapConfig ファイルによって定義されます。

7.4.1 既存の設定の管理

7.6.2 タイムラインスナップショットのクリーンアップ

それぞれ、スナップショットの作成と削除はタイムラインによって snapper -c MySnapConfig ファイルに作成されます。

opensuse151:/etc/snapper/configs # cat mysnapconfig  | grep TIMELINE
TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"
opensuse151:/etc/snapper/configs #

通常運用では問題にならないので、デフォルトの scrub のタイミングも、スナップショットを有効化した場合の、スナップショットのメンテナンス間隔は、そのままで構わないでしょう。

- アップデート前のスナップショットの削除

手動でのスナップショットの状態、最新のスナップショットの状態確認は YaST2 Snapper で確認し、内容のチェックとロールバック、削除などの操作を行います。

BtrFS の甘い罠、SUSE Linux アップデート前の空き容量の確認と確保_a0056607_13250586.png

4.1.1 スナップショットとディスク容量

ヒント: 容量を空ける/ディスクの使用率
スナップショットを含むBtrfsパーティションの容量を空けるには、ファイルではなく、不要なスナップショットを削除する必要があります。古いスナップショットは、最近のスナップショットよりも多くの領域を使用します。






とある様に、アップデートに必要な空き領域を確保するには、古いスナップショット、意図的に取得した古いスナップショットを削除して、空き領域を確保し、 btrfs fi usage <Partition> か btrfs fi df <Partition> コマンドで空き容量を確認し、その後、明示的にアップデートからのスナップショットロールバック、復元ポイントを作ってから、アップデートを実施すべきでしょう。

忘れてはならないのは、zypper up や zypper patch など、あるいはメジャーアップデートする時、同じファイルであっても物理的なファイルそのものが上書きされずに、古いファイルはスナップショットに「移動」し、空き領域に新しいファイルが作られることです。

- まとめ -

BtrFs においては、ファイルの空き領域に常に注意し、ファイルコピーなどによる空きスぺースの Run Out には気をつけよ、という事です。








by islandcenter | 2020-07-26 13:28 | SUSE | Comments(0)

openSUSE 15.1 に入れた zabbix5 で、インターネットの疎通、サービス状態の確認をする方法です。

この春先から、どうもインターネット接続が遅かったり、切れたりする症状に悩まされています。その都度、google なんかに ping して、レスポンスを確認してたのですが、メンドクサイ。何しろ「リモートワーク」の時代。地方拠点から本社への出張なども憚れると、どうしても気になるのはインターネットトラフィックです。

その後の新型コロナウイルスのフレッツトラフィックへの影響


という事で openSUSE Leap 15.1 で動いている zabbix5 に、外部サービスの死活監視、ping の応答時間などをチェックさせてみました。

How to setup zabbix4.2 on openSUSE Leap 15.1 セットアップ
https://islandcnt.exblog.jp/239366228/

zabbix4.2 を zabbix5.0 アップデート openSUSE Leap 15.1
https://islandcnt.exblog.jp/240337666/

対象は

- Google などの海外の大手
- Google DNS の様な巨大インフラへの Ping 監視
- 契約先の経路の短い Web サイトの HTTP 監視
- 契約先の経路の短い NTP サーバーへの Ping 監視

などを、可視化できないものか試してみました。



- Zabbix5 で HTTP サービスと PINGの監視 -

左のメニューから、Configuration > Hosts > リストが出てきたら、 Create Host
zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12213034.png

Host Name と group はとりあえず Google で Linux Servers、Interfacesは Zabbix Agent を remove して とりあえず IMPI、ホストのDNSを設定して Port は443 をセットして "Add" ボタンを押します。この辺りは適当でかまわないかも.....

次に左上の"Template" メニューを開きます。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12215508.png

Link new templates から "select" ボタンで”Linux Server” > Template App http や https サービスをチェックします。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12223668.png

ping もチェックしたいのなら Template ICMP Ping もチェックします。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12230824.png


最後に "Add" ボタンを押します。

Hosts の上にある Applications, Items, Triggers を、それぞれ Enable ボタンを押して監視を開始しました。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12233447.png

幾つかの HTTP サービスが Down State で見えない時があるのが分かります。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12240321.png

サービスがアップしているかどうかは。1と0の値で評価されるので、グラフがV字化している時は繋がりにくかったことが分かります。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12242658.png

ダウンしていた事が報告されていますね。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12245202.png

Yahoo.co.jp と Google.com の状態です。ダウンしている時間帯がほぼリンクしているので、海外との通信より、ウチと契約先の ISP、あるいは契約回線の問題だと判ります。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12252509.png
GoogleDNS と、契約先の ntp.bbtec.net (経路的には一番近いかな)を ping して値をみてみます。まず Ping 応答が無くなり、結果 HTTP サービスも動かないという事です。


拡大しました。全体的に google のサービスより Yahoo BB の ping 応答が遅い様な感じですね。Avarage も、Google DNS より ntp.bbtec.net の方がレスポンスが悪い様です。海外との回線よりISP内部の遅延がある様です。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12260847.png

朝の3時は iOS のアップデートが始まります。このタイミングでも google のレスポンスは見事に遅延しています。

zabbix5 でインターネットの疎通、監視、リモートワーク時代の「ネットが遅い」をチェック_a0056607_12271394.png

ダメじゃん、ウチの契約回線が悪いのだ..... と判断しています。

SoftBank Air の様な容量無制限モバイル Wifi でも、共有 IP (シェアドIP)なので、グローバルIPが切り替わる都度に、遅延や切断は起こりそうです。まぁ、モバイル Wifi では明示的に速度制限の対象となる場合もあるので「ビデオ会議」などのライブストリーミングが制限されない事を確認すべきでしょう。

Softbank Air: Wifi ネットワークの暗い闇、シェアード IP


--
今回は外部の ICMP Ping とHTTP サービスを Zabbix5 でトレンドを見てみました。今までの Zabbix4 までのグラフ機能では、複数のデバイスのトレンドが見れなかったので、良くなったと思います。

例えばオンラインミーティングが始まる午前9時とか、午後13時とかにハッキリ遅延が起こるのであれば、これは、コロナ騒動でのリモートワークの影響だとキッパリ言えそうなんですが、冒頭の IIJ のブログにもあるように、リモートワークの影響ではなさそう。やっぱりウチの Yahoo BB のプアな回線状況が原因と考えられます。

さて、プアな自宅回線の強化、月々の利用料金はどう会社負担になるのでしょう、今後のリモートワークの課題ですね。

応用として、例えば支店に設置したインターネットVPNルータや管理用 HTTP などのサービスの状態のチェック。自社の提供するサービスの死活管理などに利用できます。Pingの応答速度は、折れ線グラフ化できるので、昼間と夜間の違いはないかを可視化できます。

拠点間ルータの snmp 管理機能や、リモート拠点間のサービス状況を調べる事で、拠点の「ネットが遅い」問題の原因を検討する事もやってみる事です。明かに、ISPのサービスレベルの問題であると判断できる要因が長期のトレンドで見つかるなら、契約ISPを変える為の稟議書を書く根拠にもなります。

Zabbix のように応用力の高いツールがあれば、「その時」ではなく、たとえ数時間でもトレンドが見える事はよいことです。








by islandcenter | 2020-05-31 13:27 | SUSE | Comments(0)

Windows10 タブレットは、もう終わった技術なのです


- インターネット端末の Microsoft のシェアは30%を切っている? -

いうまでもなく Windows はPC分野の80数%のシェアがあり。10数%が Apple 残りが Linux という事は、いろいろなリサーチにある訳ですよ。

じゃぁ、インターネットのサービスを受ける、あらゆるデバイスの何パーセントが Windows なのか。スマートフォン、タブレットを含めれば、恐らく50%もないんじゃないでしょうか。多分スマートフォンが過半数なので、実際の「インターネットにおける Windows のシェア」はPCだけで3割もあればいいほうでしょうね。

PR


- 高価すぎて重すぎ -

Windows10 で最低限欲しいと思うスペックを考えると Core i3m とか i3yと言った Core 3 系のモバイル向けCPU が欲しくなるところです。ディスコンになった Atom 系SoCでは人を馬鹿にしている。正統派 Celeron でやっと使える感じがします。

Windows Update を問題なくこなせて、安定して使うには、最低64Gbのストレージが欲しい。しかし、「Window が動くタブレット」として考えるなら、256Gbのストレージが欲しくなってしまうでしょう。
そう考えると、自動的に12~3万円程度は最低限予算が必要なんですよね。

しかし意外と Core i3 系のCPUは人気がない。というかメーカーもこのクラスより、より高価な Core i5/7 系を売りたがる。こうなると安くても15万円コースですね。

キーボードもマウスもない Windows に15万円も普通払いません。しかし、「Windows デバイスを快適に使う」なら、オプションのキーボードとマウス、あるいはデジタイザペンは必須です。

それなら普通のクラムシェルか 2 in 1 ラップトップを私なら選びます。

2Gbのメインメモリ、32Gbのストレージ、Atom系 SoC では、「一応 Windows が動くタブレット」でしかなく、実際に使い物になるとは思えません。それでもWindowsがとりあえず動く環境にするには5万円前後するわけで、この値段で Android や iPad などの他社製タブレットならすコスコつかえるわけですよ。


- 処理が重すぎ -

大体、 Windows はフットプリントが重すぎて、タブレットには向かないぞ、という事だ。

GIGAスクール構想の実現について

1人1台のPCで教育のICT化を推進――日本マイクロソフトが「GIGAスクールパッケージ」を提供開始

Google、管理などの無駄な時間を減らし4万5千円以下で提供可能な「Google GIGA School Package」を開始

この勝負、どうみても Google に分があるんだが、どんなものでしょう。GIGA スクールパッケージに Windows は勝ち目がない。3万円の Android や Chrome タブレットを子供の Youtube 端末として使わせている親が、わざわざその倍の値段もして、華奢で壊れやすく安っぽい筐体の7万円の Windows タブレットを買うわけにはいかない。

私が、中高で「情報C(情報社会)」を教える立場だったら、間違えなく Windows10 タブレットは「アウトオブ眼中」です。Chrome Book で安く済ませて、余った予算を別に使う事を考えるでしょう。




マイクロソフト Surface Pro 6
[サーフェス プロ 6 ノートパソコン]
Office Home and Business 2019 
 Windows 10 Home





iPad mini Wi-Fi 64GB
 (最新モデル)





HUAWEI MediaPad M5 lite 8
 タブレット 8.0インチ
 Wi-Fiモデル




- 最悪の Windows Update -

スリープ解除して、通信が開始されるといきなり始まる Windows アップデート、いざ使おうとすると半日は使えないモバイルデバイス。それが Windows10 タブレットの宿命。

毎月のアップデートだけで、格安SIM二月分のパケット料金と貴重な時間を使いたくない

そんなものに普通15マン近い大金払いませんって。よっぽど Apple の iPad がひどくてもこんなにひどくはない。それにもっとシンプルで堅牢なハードウェアだし、軽くて高性能、高機能なのです。4万円も出せば普通に使えるし、128Gb程度のストレージがあれば、スチルカメラやビデオカメラ並みに使える。

それに iOS や Android, Chrome タブレットは機能を絞っただけシンプルで長時間のモバイル運用ができる。

- Windows だから求められるデスクトップアプリという呪縛 -

街を歩いていて、ちょっと調べ事をしたいと思えば、スマートフォンより小型のタブレットは実にいい選択なのです。

だけどそれが Windows タブレットとなれば、たとえタブレットと言えども、そこに "Windows らしさ" を求めるユーザ需要があるのですね。たとえタブレットであろうとも Microsoft Office が使えないと嫌だという、ユーザの奇妙なわがままを満たす必要があります。 Office アプリが必要であれば、当然マウスとキーボードもいるよね。

「いざという時 MS Office が使える」という事は、その「いざと言う時」のために普段使わないキーボードもカバンに入れておく必要があるわけです。そして充電用のアダプタとケーブル。

もう、 Windows10 なんて、一般家庭では「年賀状の印刷に年に一度使う」ためにある、というのが実態じゃないでしょうか。

- 銀行取引、金融機関では蚊帳の外 Windows 10は信頼されていない -

最近の銀行取引では、大体 iOS か Android のタブレットで最適化されたアプリケーションが頒布されていまして、もし Windows タブレットで、銀行振り込みしようと思ったら、別に iOS か Android が必要と言う矛盾、無駄。そもそも、銀行振り込み用のアプリがない、どころかワンタイムパスワードアプリもない。携帯電話必須という不自然さ。

ちなみに、 Windows ストアから片っ端に、大手都市銀行の名前を入れて調べると良い。一体、どこの預金者が、Windows OS を信頼しているんだろうってくらいに、ストアアプリは、銀行から嫌われています。頼むから Windows 端末から、預貯金の操作してくれるな、という位の総スカン状態なのですね。

Windows PCのブラウザ経由で決算してくれるなって位の嫌われようなのです。専用の exe アプリケーションすら配布されない。 Windows は金融機関から唾棄され嫌われているのです。

- モバイルOSから撤退した Microsoft -

ご存知の通り、 Windows Mobile はディスコンになり、既にサポートも終わっているわけで、 Microsoft としては、「マイクロソフト部屋に最後に残った幕内力士:Windows10」 をモバイルデバイスの切り札に残しているわけです。徳俵にかろうじて親指が残った崖っぷち張り出し大関、小錦みたいな状態。とてもじゃないけど、こんな危なっかしいOSを、フットプリントの小さな x86 環境にインストールして使う事自体、燃えないゴミにお金を投資するようなもの。

Windows10 タブレットは、もはや大相撲の中日に全廃している張り出し大関のようなものです。とてもじゃないけど、私は「Windows10 タブレット」には、「引退という引導」を渡すべきだとおもいます。



- Intel はブランドを整理すべきだ -

これほど、顧客が混乱しているのは Intel のブランド戦略が破綻しているからなのですね。もっとブランドを整理すべきです。「Celeron に名前を変えた Atom」 があったり、ほとんど使われない Pentium があったり、低スペック、低電圧版の Core i3/i3m/i3y なんてモデルがあるのはいかがかと思います。

その未整理な Intel のブランディング戦略にただ乗りしている、タブレットベンダーも責任を取るべきでしょう。

「2コア4スレッド搭載タブレット」とか言っても、中途半端な Atom 系 Celeron だったりするわけで、ほとんど消費者騙しです。2コア4スレッド搭載「パーソナルコンピュータ」であれば、最低でも Core i3 程度を想像するのですが、よーく仕様を見ると Celeron でしかも Atom 系コアだったりします。

Nxxxxx Celeron というNで始まる Celeron は、バチモノ系だそうです。

つまり、もう生産中止になって在庫がごっちょりある Atom 系 CPU の悪く言えば生産余剰した、リマーク品なのですね。 これを消費者に 「Atom とは別物」と言う、リ・ブランドして売りさばくのが Intel の今のやり方なのです。Celerorn 選ぶくらいなら AMD の Ryzen 系、モバイル SoC 選んだ方がよっぽどウソがない気がします。


- 使えない Windows タブレットの使い道 -

それでも Windows10 タブレットのニーズは根強くあるでしょう。それは「組み込み用途」です。こないだガス屋の端末見たら、Windows タブレットでした。 Windows 7 だったけど。

しかし、企業でこういった外勤者に何百台と使わせるとなると、コスト、持ち運びの容易さ、堅牢性、電池の持ち、アプリケーション開発の容易さなどを考慮すると、別に、保険のオバちゃんが Windows タブレットを使わなければならない必然性はありません。ブラウザ経由のアプリケーションであれば、別に何でもいいんです。

- まとめ -

ということで、Windows10 タブレットの将来性のなさ、致命的な欠点、わざわざ選ぶ理由がない事などをズラズラとまとめてみました。

それでも Windows10 タブレット買いますか? それとも Android や Chrome, あるいはPC化する iOS 搭載 iPad ? もうタブレット戦争では、ほとんど Windows 10タブは「アウトオブ眼中」、タブレットOSシェアのパイチャートでは「その他」に分類されるようになるでしょう。

202x 年 Windows 最期の日





by islandcenter | 2020-04-08 14:58 | Windows | Comments(0)

- はじめに -

久しぶりに SUSE 11 の仮想マシンを起動したら、見事にコケました、仕方がないので、 fsck して起動しましたが、あまりいいものじゃありません。


SUSE Linux Enterprise 12 から採用され、以降 SUSE Linux 15(SLE/openSUSE15) で openSUSE Leap で使われている BtrFS は、やれ「修復のため起動時の fsck の必要がない」とか、fsck しないので起動が速いとか、起動中にファイルシステムのチェックができるとか、いいことばかり書かれています。実際、この記事を書く時にたどり着いた情報は「BtrFS にクソハマった話」ばかりなのですが、それほど情報が少ないのはやはり安心して使えるファイルシステムだからでしょう。

現実には、論理障害よりも、物理障害もあるわけですから、

「困った!」

時のために、BtrFS の、修復だとかチェック、メンテナンス、スナップショットの設定の方法について、ちゃんと勉強しておくことにします。

- 参考にしたドキュメント -

SDB:BTRFS


- btrfs の修復 -

btrfs scrub start [mount_point]

パーティションの論理障害を修復します。

opesuse151:~ # btrfs scrub start /
scrub started on /, fsid 8466aee4-2738-4b0a-924a-79edad4b4676 (pid=23058)
opesuse151:~ #

- 前回 scrub した結果の確認 -

brtfs scrub status [mount_point]

scrub した結果を確認します。

opesuse151:~ # btrfs scrub status /
scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676
scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50
total bytes scrubbed: 7.54GiB with 0 errors
opesuse151:~ #

-dR オプションを付けると詳細な情報が分かります。

opesuse151:~ # btrfs scrub status -dR /
scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676
scrub device /dev/vda2 (id 1) history
scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50
data_extents_scrubbed: 247304
tree_extents_scrubbed: 31902
data_bytes_scrubbed: 7577907200
tree_bytes_scrubbed: 522682368
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 5030
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 11178868736
opesuse151:~ #

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

btrfs check [/dev/partition]

ファイルシステムのパーティションチェックです。

※ --force を付けるとマウント中のファイルシステムをチェックできる。

opesuse151:~ # btrfs check --force /dev/vda2
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/vda2
UUID: 8466aee4-2738-4b0a-924a-79edad4b4676
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 7839363072 bytes used, no error found
total csum bytes: 7380260
total tree bytes: 261373952
total fs tree bytes: 238518272
total extent tree bytes: 13942784
btree space waste bytes: 41699539
file data blocks allocated: 7779311616
referenced 7561506816
opesuse151:~ #

- btrfs での df (利用量)の確認 -

btrfs filesystem df [mount_point]

従来の df コマンドの代わりになるものです。

opesuse151:~ # btrfs filesystem df /
Data, single: total=8.01GiB, used=7.06GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.12GiB, used=249.25MiB
GlobalReserve, single: total=21.73MiB, used=0.00B
opesuse151:~ #

btrfs filesystem usage [mount_point]

opesuse151:~ # btrfs filesystem usage /
Overall:
Device size: 14.00GiB
Device allocated: 10.32GiB
Device unallocated: 3.68GiB
Device missing: 0.00B
Used: 7.54GiB
Free (estimated): 4.63GiB (min: 2.79GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 21.73MiB (used: 0.00B)

Data,single: Size:8.01GiB, Used:7.06GiB
/dev/vda2 8.01GiB

Metadata,DUP: Size:1.12GiB, Used:249.25MiB
/dev/vda2 2.25GiB

System,DUP: Size:32.00MiB, Used:16.00KiB
/dev/vda2 64.00MiB

Unallocated:
/dev/vda2 3.68GiB
opesuse151:~ #

- デフォルトのメンテナンスは一週間ごと -

sysconfig の File systems の中に、自動メンテナンスの間隔を設定します。

"BTRFS_BALANCE_PERIOD" のキーに設定されます。デフォルトは weekly となっています。

SDB:Disable btrfsmaintenance

weekly から none にすると、無効となります。

SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13465207.png

- snappper の初期設定 -

snapper は初期設定では無効です。snapper コマンドでスナップショットを初期化します。

snapper -c create [YourSnapSotName] create-config [PathToYouNeedSpapShot]

ここではルートパーティション全体を取っていますが、例えば DB ファイルがあるところとか、 /srv/www/htdocs などを指定します。設定ファイルは /etc/snapper/configs/ の下に作られます。

opesuse151:~ # snapper -c mysnapconfig create-config /
opesuse151:~ #
opesuse151:~ # ls /etc/snapper/configs -l
total 4
-rw-r----- 1 root root 1169 Feb 27 10:37 mysnapconfig
opesuse151:~ #
opesuse151:~ # cat /etc/snapper/configs/mysnapconfig


# subvolume to snapshot
SUBVOLUME="/"

# filesystem type
FSTYPE="btrfs"


# btrfs qgroup for space aware cleanup algorithms
QGROUP=""


# fraction of the filesystems space the snapshots may use
SPACE_LIMIT="0.5"

# fraction of the filesystems space that should be free
FREE_LIMIT="0.2"


# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS=""

# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="no"


# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"


# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"


# create hourly snapshots
TIMELINE_CREATE="yes"

# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"


# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"

# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"

詳細はこちらをご参考下さい。

4 Snapperによるスナップショットとロールバック

SLES12 の Snapper のチューニング

- snapper のスナップショットの設定 -

snapper を起動したら、YaST2 snapper で、スナップショットの設定をします。

opesuse151:~ # yast2 &

SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13430414.png

定義したパーティションルートに .snapshot ディレクトリが創られます。ここは snapshot の保管場所です。

opesuse151:~ # ls /.snapshots/1/snapshot/
.snapshots boot etc lib mnt proc run selinux sys usr
bin dev home lib64 opt root sbin srv tmp var
opesuse151:~ #


SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13480760.png

実際のスナップショットの取り方、ロールバックの方法はこちらの過去記事をご参考にしてください。

SLES12が採用した btrfs, snapper を使った Snap Shot
なるほど、SUSE Linux 12, 15 でルートパーティションは標準の BtrFS は COW (Copy On Write) なので、ファイルの論理障害には強いんだ、という事です。しかし物理障害には無力な事には変わりません。やっぱり必要なのはバックアップです。

一通りやってみて、Windows の起動直後の chkdisk や EXT3 の場合の fsck の待ち時間を考えると実に楽になったなと実感しています。








by islandcenter | 2020-02-27 14:20 | SUSE | Comments(0)

ファイル名とファイルパスの最大長について。

Samba にファイルを保存しようとしたら、「ファイル名が長すぎる」と怒られたので、ファイルサーバーで保存するファイル名の長さ、トータルのパスの長さを調べてみました。
ここでは Samba だけではなく、Windowsや macOS のファイル名、パスの長さ制限についても調べました。


- SUSE Linux(openSUSE Leap 15.1)-

SUSE に限らず多くの Linux ディストリビューションや UNIX 系では getconf コマンドで NAME_MAX を調べてみると良いでしょう。 255 バイトで、最後の一文字は NULL なので、実質 254 バイトになるはずです。誤っていたらコメントください。これは posix 準拠のためなんでしょうね。

sle15:~ # getconf -a | grep NAME
NAME_MAX 255
_POSIX_NAME_MAX 255
LOGNAME_MAX 256
TTY_NAME_MAX 32
TZNAME_MAX
_POSIX_TZNAME_MAX
CHARCLASS_NAME_MAX 2048
HOST_NAME_MAX 64
LOGIN_NAME_MAX 256
sle15:~ #

IBM の資料ですが、getconf の詳細はこちらをご参考ください。
getconf — 構成値を取得する

Samba や NAS などでは 255 「バイト」、Windows では260「文字」。長いファイル名は Samba では使えないわけです。

長いファイル名を扱うことができない

ただし、これは「ファイル名の制限」で、limits.h によるとパスも含める 4096 バイトの様です。これはファイルシステムフォーマットの問題ではなくシステムAPIによる制限です。


最大パスサイズは「バイト」で日本語でパスを作成する場合、UTF8 では3~4バイト使うため、「日本語の文字数」に注意が必要です。

opensuse151:~ # cat /usr/include/linux/limits.h | grep PATH
#define PATH_MAX 4096 /* # chars in a path name including nul */

opensuse151:~ # getconf -a |grep PATH
PATH_MAX 4096
_POSIX_PATH_MAX 4096
PATH /bin:/usr/bin
CS_PATH /bin:/usr/bin
opensuse151:~ #


実際にプログラムを書いて試したヒトがいました。中々面白いプログラムです。

Check File Systems maximum path depth

Now run it:
$ time ./createDirectories

return code : -1
Created sub-directories : 1018
length of pathname : 4096

real 0m0.281s
user 0m0.004s
sys 0m0.180s


私の openSESE Leap 15.1 の環境では若干違いがありました。

opensuse151:~/test # ./ptest
return code : -1
Created sub-directories : 1022
length of pathname : 4098

1023 バイト説もありますが、その根拠が分かりませんでした。コメントいただけると幸いです。

- Novell NSS はパスも含めて 1023の Unicode 文字 -

ファイルサーバー専用OSの Novell Open Enterprise Server (OES)では、ファイル名そのものは16ビット Unicode で 255 文字、フルパスは 1023 文字です。

6.4 Naming NSS Storage Objects

6.4.2 Number of Characters Allowed
For the NSS file system, the maximum length supported for a filename (the name and file extension) is 255 16-bit Unicode characters. The maximum length supported for the full path name (which includes the volume name, directories, filename, extension, and delimiters in the path) is 1023 16-bit Unicode characters.

However, different tools, applications, and file systems place different limits on filenames and path lengths, some of which can be more or less restrictive than these limits.

16bit Unicode でパスも含めて 1023 文字です。もっとも、それだけの長さを扱えるソフトウェアやアプリケーションがあるとは限らないのでマウントしたシステムによる、という事です。標準的なシステムより、長いパスを作ってマルチベンダー対応、という事なのですが、良くある話でマルチベンダー固有のトラブルも抱えます。

なお、上の記事は、OES2018 のNSSなので OES2 以前のバージョンや NetWare カーネルでは 255 文字という記述もありました。多分ファイル名だけの制限でしょう。

- Windows NTFS -

NTFS の概要

拡張パスのサポート: 多くの Windows API 関数には、MAX_PATH 設定で定義された 260 文字のパスの上限を超える約 32,767 文字の拡張パスを許可する Unicode バージョンがあります。
最大 32,767 文字が MAX_PATH 変数によって 260 文字(パスも含む)に制限されています。この数値は Win32 の制限によるもので、グループポリシーで変更できます。

> gpedit > コンピュータの構成 > 管理用テンプレート > システム > ファイルシステムに "Win32の長いパスを有効にする" を有効にして > gpupdate を実行します。

ファイル名とパスの最大長の色々_a0056607_13581623.png

例えば、サーバー上の "D:\(フルパス含めて全部で260文字).txt" をネットワーク共有で "\\server\my-long-share\(共有名を含めると260文字超えちゃった).txt" でアクセスする場合などにはこの制限を撤廃すべきでしょうか。やはり「255文字前後が一般的な壁」なので、濫用は要注意です。

バックアップからのリカバリなどでも、このファイル名の長さ制限でリストアできないファイルがある場合も考えられます。
Windows Server -> Samba でバックアップエラーが起こるとややこしい事になりそうですね。

Linux側では、4096(NULL含) のパスの長さなので、 Unix 系OSや macOS とファイル共有すると、ファイル名の長さで Windows からアクセスできないケースも出てくるわけです。

- MacOS HFS+ -

Wikipedia によると

最大ファイル名長
255文字(UTF-16での文字数。Appleが改変したUnicode正規化形式Dに正規化される)
https://ja.wikipedia.org/wiki/HFS_Plus

残念ながら、パスを含んだ最大の数字は見つからなかった...ので getconf してみました。

etesian-mini:etc uhoge$ uname -a
Darwin etesian-mini.local 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64
etesian-mini:etc uhoge$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.1
BuildVersion: 19B88
etesian-mini:etc uhoge$ getconf NAME_MAX /
255
etesian-mini:etc uhoge$ getconf PATH_MAX /
1024
etesian-mini:etc uhoge$

ファイル名とパスの最大長の色々_a0056607_12410148.png

どうも macOS X 10.15.1 では、ファイル名の長さは 255(NULLを除いて254)バイト、最大パスは 1024 ということになりそうです。

古いHFSの場合は31文字です。また、AFP を使う時も 31 文字のよう。








- まとめ -

色々調べてわかったのは....

- 大体のシステムでは2020 年現在 255 文字前後のUTF16、またはバイトが、ファイル、ディレクトリ名で使える
- バイトの場合と UTF16 の場合がある。
- Unix 系システムでは、ディレクトリパスも含めて、4095(+null) で 全部で4096バイトのようだ
- Unix 系システムで Samba を使う場合、長いパスは Windows からアクセスできない場合がある。
- ただし OS が扱うファイル名の文字コードが UTF16 であるとは限らない。最近は大抵 UTF8 だったりする
- Windows10 系は 260 文字だが、「初期の Windows は 254" バイト"」だったりでバージョンによってはバラバラ。
- Windows10 系のパスの長さ制限は「拡張パス」という秘密の扉を開けると32,767 文字まで使える
- システムが使う文字コードが Shift-JIS だったり、Unicode だったり、UTF-8 だったり EUC だったりするとどうなるか不明
- 日本語コードに慣れたプログラマとはトモダチにになっておくべきだ。
- バイト数と UTF16、UTF8、の「文字数」とは違う事をエンドユーザに説明するのはインド人にウナギを食わせるくらい難しい
- 特に文字数とバイト数の違いに注意。chars が、いわゆる char 変数なのか、文字通りの「非アルファベット」の複数バイトの文字数(letter数)なのか
- 職場を辞めたヤツが、Mac からファイルサーバーの日本語フォルダの深さをチャレンジ、しかも読み込み専用のフラグを立てて退職したことを思い出した。頭にきた。
- 長くて深いディレクトリ名、ファイル名をユーザは使わないで欲しい。ってか、よくそんな面倒なことするなよ。
- ファイルシステムに制限がなくても(no limit) OS の API 制限に引っかかることが多い。Windows のエクスプローラは「アプリケーション」である。
- アプリケーションからアクセスできないファイルは夜作られる。
- ファイル名とパスの長さは、誰か Wikipedia に記事を書いてまとめて欲しいくらい、面倒である。





他にも文字コードの違いや機種依存文字、使えない記号符号特殊文字などもあります。これはまた別の機会に調べてみます。

コンピュータ名(ホスト)の命名規則? 15文字の63バイト制限、ホスト名の命名権利はだれの責任?





by islandcenter | 2020-02-24 14:12 | SUSE | Comments(0)

SUSE Linux での fuser、ファイルを開いているプロセスを kill します。

マウント中のデバイスを umount しようとすると ”Device busy” なんてことがあります。あるいは、ファイルを開こうとしたら、ファイルがゾンビなプロセスなんかに、ロックされている。

そんな時に覚えておきたいコマンドが lsof と fuser です。

lsof はインストールされていないようなので、YaST か zypper を使ってインストールします。

SUSE Linux でパッケージインストールの色々な方法





- fuser のヘルプ -

まずは使い方から

opensuse151:~ # fuser
No process specification given
Usage: fuser [-fIMuvw] [-a|-s] [-4|-6] [-c|-m|-n SPACE]
             [-k [-i] [-SIGNAL]] NAME...
       fuser -l
       fuser -V
Show which processes use the named files, sockets, or filesystems.

  -a,--all              display unused files too
  -i,--interactive      ask before killing (ignored without -k)
  -I,--inode            use always inodes to compare files
  -k,--kill             kill processes accessing the named file
  -l,--list-signals     list available signal names
  -m,--mount            show all processes using the named filesystems or
                        block device
  -M,--ismountpoint     fulfill request only if NAME is a mount point
  -n,--namespace SPACE  search in this name space (file, udp, or tcp)
  -s,--silent           silent operation
  -SIGNAL               send this signal instead of SIGKILL
  -u,--user             display user IDs
  -v,--verbose          verbose output
  -w,--writeonly        kill only processes with write access
  -V,--version          display version information
  -4,--ipv4             search IPv4 sockets only
  -6,--ipv6             search IPv6 sockets only
  -                     reset options

  udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]


- lsof でディレクトリ以下のオープンファイルを確認 -

opensuse151:~ #
opensuse151:~ # lsof /home/
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sftp-serv 21170 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
bash      21204 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
oosplash  23270 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
soffice.b 23289 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
soffice.b 23289 knakaj    3u   REG   0,47     8107  826 /home/knakaj/test/test.odt
soffice.b 23289 knakaj   24uW  REG   0,47       91  728 /home/knakaj/.config/libreoffice/4/user/uno_packages/cache/log.txt
soffice.b 23289 knakaj   26uW  REG   0,47      127  772 /home/knakaj/.config/libreoffice/4/user/extensions/bundled/extensions.pmap
dbus-daem 23304 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
at-spi-bu 23305 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
at-spi-bu 23305 knakaj  mem    REG   0,47      787  825 /home/knakaj/.config/dconf/user
dbus-daem 23310 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
at-spi2-r 23312 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
gvfsd     23318 knakaj  cwd    DIR   0,47      404  258 /home/knakaj
gvfsd-fus 23323 knakaj  cwd    DIR   0,47      404  258 /home/knakaj


- fuser でオープンファイル、プロセスID、ユーザを確認 -

-a 全部、-u ユーザID、-v 詳細モード

opensuse151:~ # fuser -avu /home/knakaj/test/test.odt
                     USER        PID ACCESS COMMAND
/home/knakaj/test/test.odt:
                     knakaj    23289 F.... (knakaj)soffice.bin


- fuser でオープンしているプロセスを kill -

-k で kill、 -i で kill の確認メッセージ

opensuse151:~ # fuser -avuki /home/knakaj/test/test.odt
                     USER        PID ACCESS COMMAND
/home/knakaj/test/test.odt:
                     knakaj    23289 F.... (knakaj)soffice.bin
Kill process 23289 ? (y/N) y
opensuse151:~ #


- マウント中のデバイスとユーザ、プロセスの確認 -

-m でマウントオプション

opensuse151:~ # fuser -mauv /mnt/sdc
                     USER        PID ACCESS COMMAND
/mnt/sdc:            root     kernel mount (root)/mnt/sdc
                     knakaj    22618 f.c.. (knakaj)smbd
opensuse151:~ #


-m と ki オプションでモンダイの smb プロセスを kill する。 

opensuse151:~ # fuser -mauvki /mnt/sdc
                     USER        PID ACCESS COMMAND
/mnt/sdc:            root     kernel mount (root)/mnt/sdc
                     knakaj    21867 f.c.. (knakaj)smbd
Kill process 21867 ? (y/N) y


セッションが kill され、開いているファイルがリセットされました。

ディレクトリに cd している場合は bash がディレクトリファイルをオープンしています。よくある話。

opensuse151:/home/knakaj # fuser -vau .
                     USER        PID ACCESS COMMAND
/home/knakaj:        root      22884 ..c.. (root)bash
                     root      22982 ..c.. (root)fuser
opensuse151:/home/knakaj #
opensuse151:/home/knakaj # fuser -vau /home/knakaj/
                     USER        PID ACCESS COMMAND
/home/knakaj:        root      22884 ..c.. (root)bash
                     root      23149 ..c.. (root)fuser
opensuse151:/home/knakaj # cd ..
opensuse151:/home # fuser -vau /home/knakaj/
                     USER        PID ACCESS COMMAND
/home/knakaj:
opensuse151:/home #

※ ちなみに bash のプロセスを kill するとそのターミナルは固まります......





by islandcenter | 2020-02-19 12:45 | SUSE | Comments(0)