Quantcast
Channel: ソフトウェア – What I Know ~ワッタイナ
Viewing all 96 articles
Browse latest View live

ConoHa で Zabbix 4.0 が(こっそりと?)リリースされていました

$
0
0

10月2日、監視ツールの Zabbix の新しいメジャーバージョン、Zabbix 4.0 LTS がリリースされました。

このブログでもお世話になっている ConoHa で自分でインストールしてみようかとダッシュボードを開いた瞬間、下記のお知らせが目にとまりました。

ConoHa Zabbix お知らせ

2018-10-10 【更新情報】テンプレートイメージ「Zabbix」の更新
サーバー追加で選択できる以下テンプレートイメージの更新を行いました。

・「サーバー追加」で選択できるテンプレートイメージ(アプリケーション)の「Zabbix」のメジャーバージョンアップ、およびベースとするCentOSのマイナーバージョンアップ

具体的なバージョンが書いていない物の、もしかして 4.0・・・? と思い、早速テンプレートイメージから作成することに。

サーバー追加画面

 ConoHa Zabbix サーバー追加画面 テンプレート説明
サーバー追加画面では、Zabbix は「2.4-64bit [centos-7.2]」…
本当にバージョンアップしたのか期待していない自分にながらも、画面に従いサーバーを追加します。

ConoHa Zabbix サーバー追加画面 接続許可ポート

もう一つ思ったのは、接続許可ポートで Zabbix の 10050 / 10051 ポート空けるボタン欲しいなと思いました。
(全 OS、アプリケーションで同じ画面を出していると思うので難しいと思いますが…)

いざ、サーバー確認

================================================
Welcome to Zabbix image!

URL: http://xxxxxxxxxx/zabbix
MySQL root password:   xxxxxxxxxx

MySQL Zabbix database name: xxxxxxxxxx
MySQL Zabbix username     : xxxxxxxxxx
MySQL zabbix_user password: xxxxxxxxxx

Enjoy!

To delete this message: rm -f /etc/motd
================================================

サーバーにログインすると、上記の情報が表示されます。

# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

ちなみに、OS のバージョンは CentOS 7.5 でした。
やはり、OS のマイナーマージョンアップは間違いないようです。

いよいよブラウザで確認…

 Welcome to Zabbix 4.0

Zabbix 4.0 でした!

サーバーにログインしたときの情報を参考に、この後のセットアップ画面を進めていきます。

 Zabbix 4.0 Dashboard

無事ダッシュボードが表示されました。

Zabbix 4.0 の良かったところ

公式サイトでもアップデート内容が紹介されています。

この中で自分が役立ちそうだなと思ったのは下記です。

  • タイムセレクタ(従来はマウスで選択していたが、思い通りの日付時刻が選びやすくなった)
  • タグによる権限設定、メンテナンス設定(一台のホストに複数の役割を入れているときに、従来のホスト単位だともう少し細かくしたいと思うことがあった)

上記のページには記載が無いので、3.x で実装されていたのかもしれませんが、下記も良くなったと思いました。

  • 左上のロゴをクリックすると、Zabbix 公式サイトでなく、ダッシュボードに遷移する(何度 Zabbix 公式サイトの PV 向上に貢献したことか…)
  • 監視データをタイムセレクタで選んだ後、プレーンテキストとして落とせるようになった
  • ホストのトリガーの設定で「値」が表示されるようになった(今までは、障害になっているトリガーを別画面で見る必要があった)

まだ数分しか触れていないのですが、まだまだ使いやすくなった点は多くあると思います。

まとめ

さくっと Zabbix 4.0 を試したい方は ConoHa が簡単でおすすめ。


macOS Mojave でパーティションのエラーで BootCamp のボリュームが削除できない問題の回避法

$
0
0

macOS Mojave 10.14.2 において、BootCamp でインストールした Windows 10 環境を削除しようとしたときに少し苦労したのでブログ記事にします。

正常時の Windows の削除方法

正常な場合、「Boot Camp アシスタント」を開き、画面の指示に従うと削除できるようです。

失敗編

ただ、手元の環境で実行しようとすると下記のエラーが表示され削除されませんでした。

Mojave Boot Campアシスタント 起動ディスクにはパーティションの作成および単一パーティションへの復元はできません

起動ディスクにはパーティションの作成および単一パーティションへの復元はできません。

起動ディスクがMac OS拡張(ジャーナリング)の単一ボリュームでフォーマットされているか、Boot Campアシスタントを使用してWindowsをインストールするためのパーティションがすでに作成されている必要があります。

ディスクユーティリティを確認したところ、Boot Campアシスタントを利用してWindowsをインストールするためのパーティションが既に作成されている状態です。
また、Macbook のため、標準以外のディスクの接続はありません。

Mojave ディスクユーティリティ Boot Camp パーティション存在

原因調査編

同様のエラーメッセージで検索すると、Apple 社の下記ページにリンクしているページがありましたが、現在はリンク切れのようでした。

Boot Camp:Boot Camp アシスタントの使用中にパーティション警告メッセージが表示される – Apple サポート
https://support.apple.com/ja-jp/HT203913

WeybackMachine で確認したところ下記が書かれていたようです。

> 「パーティション」タブをクリックします。
> 「disk0s3」または「disk0s5」という名前の余分なパーティションを探します。そのパーティションを選択して強調表示させます。

現行の Mojave 版のディスクユーティリティには、パーティションタブはありませんし、disk0s3またはdusk0s5といったものも見つけられませんでした。

ただ、

> Windows 8 から Windows 8.1 へのアップグレードインストールを実行すると、これらの追加パーティションが作成されます。この余分のパーティションを削除するまで、Boot Camp アシスタントを続行することはできません。

といった記載もあり、確かに Windows 10 April 2018 Update(1803)から、October 2018 Update(1809)にアップデートした心当たりもあり、パーティションの不整合が発生していると推測されます。

解決編

結論、下記のページを参考に解決できました。

1. 端末を起動する
2. diskutil list コマンドで /dev/disk0 のパーティション構成を確認する

$ diskutil list
/dev/disk0 (internal):
#:                  TYPE NAME            SIZE     IDENTIFIER
0: GUID_partition_scheme                 251.0 GB disk0
1:                   EFI EFI             314.6 MB disk0s1
2:            Apple_APFS Container disk1 210.0 GB disk0s2
3:  Microsoft Basic Data BOOTCAMP        39.8 GB  disk0s3
4:      Windows Recovery                 885.0 MB disk0s4

3. 次のコマンドを実行し、 Windows 領域のパーティションを統合する

$ diskutil eraseVolume jhfs+ BC1 disk0s3
Started erase on disk0s3 BOOTCAMP
Unmounting disk
Erasing
Initialized /dev/rdisk0s3 as a 37 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Finished erase on disk0s3 BC1

4. もう一度 diskutil list コマンドでパーティション構成を確認する

$ diskutil list
/dev/disk0 (internal):
#:                  TYPE NAME            SIZE     IDENTIFIER
0: GUID_partition_scheme                 251.0 GB disk0
1:                   EFI EFI             314.6 MB disk0s1
2:            Apple_APFS Container disk1 210.0 GB disk0s2
3:             Apple_HFS BC1             39.7 GB  disk0s3

この状態でなぜか disk0s4 が消えていました。
参考にした Qiita では disk0s4 を削除されていましたが、もちろんこの状態では削除できませんでした。

5. この状態で Boot Camp アシスタントを開いてみる

Mojave Boot Campアシスタント 既存パーティションが見えない状態

Windows のインストール画面が表示されました。
BootCamp 用の 40GB を無視した 210GB から Windows 用パーティションを捻出しようとしているのでこれではまだ足りないようです。

6. Windows 領域のパーティションのタイプを変更する

$ diskutil eraseVolume fat32 BOOTCAMP disk0s3
Started erase on disk0s3 BC1
Unmounting disk
Erasing
4096 bytes per physical sector
/dev/rdisk0s3: 9681056 sectors in 1210132 FAT32 clusters (32768 bytes/cluster)
bps=4096 spc=8 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=51346432 drv=0x80 bsec=9683456 bspf=1182 rdcl=2 infs=1 bkbs=6
Mounting disk
Finished erase on disk0s3 BOOTCAMP

これで全手順が完了しました。

6. Boot Campアシスタントより、ディスクを単一ボリュームに復元

Mojave Boot Campアシスタント ディスクを単一ボリュームに復元

正常に Boot Camp 領域が認識されたようで、「ディスクを単一ボリュームに復元」画面が表示されました。

Mojave Boot Campアシスタント Windows パーティションが削除されました

エラーも出ずに数分で完了。

Mojave ディスクユーティリティ Boot Camp パーティション削除後

ディスクユーティリティでも、250GB の単一ボリュームとして認識されたので、問題なさそうです。

まとめ

Windows 10 では半年に一回新バージョンがリリースされるので、そのたびに Boot Camp アシスタントで認識できなくなることが考えられるので、Boot Camp アシスタント側で対応していただきたいなと思いました。

そもそも、多くのユーザーは Boot Camp 領域を削除しようと思わないのかもしれませんが…

「令和」に対応した Gboard / Google 日本語入力で日向坂46 二期生の変換を検証してみた

$
0
0

Gboard ゴールド プロダクト エキスパートの yasu0796 です。

平成31年4月1日、平成の次の元号が「令和」となることが発表されました。

Android 版 Gboard・Google 日本語入力では、当日中に「令和」に対応する単語リストのアップデートが配信されました。

「単語リストのアップデート」については、以前、下記の記事で紹介しました。

現時点のバージョン

現在のバージョンは「ばーじょん」を変換することで確認できます。

辞書のバージョンが 24.6 以上であれば「令和」に対応していることが確認できました。

「令和」対応

  • Android 版 Gboard:GoogleJapaneseInput-2.24.3568.103+24.6.0
  • Android 版 Google 日本語入力: GoogleJapaneseInput-2.24.3535.3+24.6.9

「令和」非対応

  • iOS 版 Gboard: GoogleJapaneseInput-2.24.0.105+24.3.9
  • Windows 開発版 Google 日本語入力:GoogleJapaneseInput-2.24.3270.100+24.2.9

Android 版 Gboard については、「単語リストのアップデート」という項目はありませんでしたが、自動的にアップデートされていました。

日向坂46 二期生の対応について

今回の Google 日本語入力の単語リストのアップデートで、前回の記事で対応していなかった日向坂46(旧:けやき坂46)二期生のメンバーにも対応したことを確認しました。

検証結果をまとめます。

メンバー Android
Google 日本語入力
24.6.9
Android
Gboard
24.6.0
iOS
Gboard
24.3.9
令和(参考)
金村美玖
河田陽菜
小坂菜緒
富田鈴花
丹生明里
濱岸ひより
松田好花
宮田愛萌
渡邉美穂

「令和」に対応している Android 版 Gboard においても、日向坂46二期生には対応していないことが分かりました。

また、「令和」に対応していない iOS Gboard でも、小坂菜緒さんのように変換できるメンバーがいましたので、Android 版 Gboard は厳選された単語のみ収録されているようです。

その他変換できた単語

Android 版 Gboard(24.6.0)では推測候補にはなく、Android 版 Google 日本語入力(24.6.9)で推測候補に表示される語は他にもありましたので例を示します。

  • 真っ白なものは汚したくなる
  • カタカナケヤキ
  • さゆりんごマジョリティー
  • エバンジェリストスクール
  • 西脇資哲
  • 亜門虹彦
  • 伊藤衆人
  • ハリー杉山

最後まで入力すると確実に Android 版 Gboard でも変換できる語もありますので、推測候補で比較しています。

坂道合同オーディションのメンバーについて

日向坂46二期生以降に加入した、坂道合同オーディションの乃木坂46四期生、欅坂46二期生、日向坂46三期生については Android 版 Google 日本語入力でも対応していませんでした。

まとめ

  • Android 版 Google 日本語入力は「単語リストのアップデート」で令和に対応する
  • Android 版 Gboard は特に設定は無いが自動的にアップデートされる
  • iOS 版 Gboard、PC 版 Google 日本語入力にはまだアップデートは配信されていない
  • Android 版 Gboard のみ辞書のバージョンが x.x.0 で他の x.x.9 の辞書と比較して一部の語が収録されていない
  • Android 版 Gboard vs Google 日本語入力、日本語の単語リストが充実しているという面で、Google 日本語入力がおすすめ

Chrome 73 で対応した macOS Mojave のダークモードを無効化する方法

$
0
0

2019/05/03 追記:Windows 10 の方はこちらをご確認ください。


Chrome ゴールド プロダクト エキスパートの yasu0796 です。

macOS Mojave 10.14 で対応したダークモードに Chrome もバージョン 73 から対応しました。

ただ、シークレットタブも同じ色のため、区別が付きづらいという方もいるようです。

この記事では、macOS 側のダークモードは有効のまま、Chrome のみダークモードを無効化する方法を紹介します。

現状の確認

Chrome 73 macOS Mojave ダークテーマ適用

ダークモードで表示されています。

ダークモードの無効化

ターミナルを開いて下記のコマンドを入力すれば OK です。

$ defaults write com.google.Chrome NSRequiresAquaSystemAppearance -bool yes

この通り、Chrome のみダークモードが無効化されました。

Chrome 73 macOS Mojave ダークテーマ解除

ダークモードの有効化(設定を戻す場合)

デフォルトに戻す場合、下記を入力してください。

$ defaults delete com.google.Chrome NSRequiresAquaSystemAppearance 

確認のコマンドは下記で、デフォルトの場合、下記のメッセージが表示されます。

$ defaults read com.google.Chrome NSRequiresAquaSystemAppearance 
2019-04-07 23:00:09.178 defaults[606:7167] 
The domain/default pair of (com.google.Chrome, NSRequiresAquaSystemAppearance) does not exist

まとめ

他のアプリケーションにも応用可能なので、ダークモードを無効化したい場合、このコマンドを思い出していただけたらと思います。

様々な IME の「令和」対応状況について調べてみた(Google 日本語入力 / Gboard / Microsoft IME / ATOK / Apple)

$
0
0

Gboard ゴールド プロダクト エキスパートの yasu0796 です。

平成最後の日の更新です。

今回は、各 IME の「令和」の対応状況について調べてみました。

具体的に IME が対応していると判断する基準は下記となります。

  • 「れいわ」と入力し「令和」と変換されること
  • 「明日」「今日」などと入力し「令和元年5月1日」と表示されること

「令和」の対応については、4月3日に下記の記事を公開していますが、前者の漢字変換の確認結果でした。

調査対象

今回は、下記について調査しました。

  • Windows 10 標準の Microsoft IME
  • macOS Mojave / High Sierra 標準 の IME
  • iOS 標準の IME
  • ATOK
  • Google 日本語入力
  • Gboard

また、それぞれの環境において、確定履歴から学習している可能性があるため、学習内容のクリアもしくは、シークレットモードにより検証しています。

調査結果

Windows 標準の Microsoft IME

「令和」の漢字変換には4月1日の発表直後に対応したようです。

OS 側で「令和」のアップデートを適用することにより、「明日」で令和元年5月1日を表示できるようです。

Microsoft IME 令和対応

手元の環境では、すでに May 2019 Update に上げており、KB4497093(18362.86)を適用することで反映されました。

ただ、現状の最新の安定板の 1809(October 2018 Update)では、現時点では4月10日のビルドが最新であり、新元号に対応できていないようです。

1803 の場合、KB4493437(17134.753)で新元号に対応済みのため、Windows 10 でひとくくりにするのはよくなさそうです。

macOS Mojave / High Sierra 標準の IME

Mojave 10.14.4

Mojave 標準の IME では「令和」の漢字変換には対応していることを確認しました。
ただ、日付変換は平成となっています。

Mojave 10.14.4 も新元号発表以前にリリースされた物なので、どのタイミングで漢字変換に対応したのかは不明です。

High Sierra 10.13.6

High Sierra では「令和」の漢字変換にも対応していませんでした。

iOS 標準の IME

iOS 12.2 標準の IME では、「令和」の漢字変換には対応していることを確認しました。
ただ、日付変換は平成となっています。

iOS 12.2 も新元号発表以前にリリースされた物なので、どのタイミングで漢字変換に対応したのかは不明です。

ATOK

Windows 版、macOS 版、Android 版、iOS 版ともにサポートされているバージョンでしたら、無料でアップデートが可能です。

アップデートにより「令和」の漢字変換、日付変換にも対応しました。

ATOK 令和対応

Google 日本語入力

Android 版

最新版は「 GoogleJapaneseInput-2.24.3535.3+24.6.9 」となります。

4月3日に公開した記事に記載のように、「単語リストのアップデート」機能を有効化することにより、「令和」の漢字変換に対応しました。

ただ、日付変換には対応していません。

PC 版

Windows 版、macOS 版ともに、「令和」の漢字変換、日付変換に対応していません。

Windows の最新の開発版のバージョンは「 GoogleJapaneseInput-2.24.3270.100+24.2.9 」となります。

Gboard

Android 版

最新版は「 GoogleJapaneseInput-2.24.3601.103+24.6.0 」となります。

4月3日に公開した記事に記載のように、辞書が 24.6 系であるため「令和」の漢字変換に対応しています。

また、日付変換にも対応していました。

Android Gboard 令和対応

iOS 版

最新版は「 GoogleJapaneseInput-2.24.0.105+24.3.9 」となります。

辞書が 24.3 系となるため、「令和」の漢字変換には対応しませんが、変換エンジンと辞書が独立しているため、日付変換のみ対応していました。

まとめ

「令和」の漢字変換、日付変換ともに完全に対応しているのは下記となります。

  • ATOK
  • Windows 10 の Microsoft IME(ただし、OS 側の対応が必要)
  • Android 版 Gboard

新元号発表後一ヶ月でのリリースというのは難しいところもあるかと思いますが、まだの IME は今後の更新に期待したいです。

Chrome 74 で対応した Windows 10 のダークモードを無効化する方法

$
0
0

Chrome ゴールド プロダクト エキスパートの yasu0796 です。

Mac のみだった Chrome 73 についで、Chrome 74 で、Windows 10 のダークモードにも対応しました。

ただ、シークレットタブも同じ色のため、区別が付きづらいという方もいるようです。

この記事では、Windows 側のダークモードは有効のまま、Chrome のみダークモードを無効化する方法を紹介します。

Windows 10 の設定の確認

Windows の設定 → 個人用設定 → 色 → 色を選択する
において、下記の場合に、Chrome がダークモードになります。

  • カスタム(既定のアプリモード 黒)
Windows 10 設定 色

ダークモードが有効の場合

Windows 10 Chrome ダークモード

シークレットモードと同じ色で表示されています。

ダークモードの無効化

Chrome のショートカットの「リンク先」に「–disable-features=DarkMode」を追記すれば良いです。

環境に依存しますが、64bit 版 Windows 10 の Chrome 安定版だと下記になると思います。

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-features=DarkMode
Windows 10 Chrome ダークモードの無効化

この通り、Chrome のダークモードが無効化されました。

Windows 10 Chrome ダークモード 無効化後

ダークモードの有効化(設定を戻す場合)

上記で設定したショートカットの「–disable-features=DarkMode」を除去すれば元に戻ります。

参考文献

下記の記事を参考にしました。ありがとうございます。

VMWare Workstation 15.0.4 で Windows 10 1903 (18362) の VM が起動しない問題

$
0
0

現象

現在、Release Preview でリリースされている、Windows 10 May 2019 Update 1903(ビルド 18362) にアップデート後、VMWare 15.0.4 の VM が起動しなくなりました。

具体的には、黒い画面で、VMWare のプロセスが CPU のみ高く、ゲストの操作が受け付けられない状態です。
VM を止めることもできず、ホストの再起動が必要でした。

May 2019 Update で追加された「Windows サンドボックス」の確認のため、一時的に有効化して VMWare と共存できないことを知り、切り戻したときに上手くいかなかったのかなと思っていましたが、Windows サンドボックスを使用できない Pro 版でない OS でも再現したので、別の原因がありそうです。

Windows 10 1903 VMWare Workstation Player 15 black.

対応方法

下記のページに記載されています。

This issue is fixed internally in VMware. Please be patient for the update.

とのことなので、次回のバージョンアップで解決すると思われます。

・・・がそうはいっていられない事情の方もいるようで、回避策が書かれていました。

仮想プリンタの削除

仮想マシンの設定より「プリンタ」を削除します。

デフォルトでは有効化されていますが、今まで利用してこなかったので、削除しても影響はありませんでした。

仮想プリンタを活用されている方は、アップデートがリリースされるまでは、ネットワーク越しで利用したり、PDF で出力したりする必要はありそうです。

NICの変更

NIC をデフォルトの「e1000」「e1000e」から、「vmxnet3」に変更します。

NIC の種類の詳細は、下記のページをご確認ください。

変更した場合、通信するには、VMWare Tools をインストールしておく必要があります。

ethernet0.virtualDev = "e1000e"
ethernet0.virtualDev = "vmxnet3"

まとめ

手元の環境では、仮想プリンタの削除、NIC の変更で解決しました。

一つのみでよい場合もありましたが、両方とも対応しないと起動しない場合もあったため、念のため二つとも対応するとよいと思います。

ConoHa のスタートアップスクリプトで Splunk 環境をサクッと作ってみる

$
0
0

下記の Advent Calender 21日目の記事です。

Advent Calendar に参加したきっかけ

ConoHa

ConoHa に関する記事はたびたび公開してきましたが、Advent Calendar には初めて参加します。

オブジェクトストレージがリリースされた翌日に公開した記事があるなど、ConoHa のオブジェクトストレージについては古参ユーザーだと思います(自称)

Splunk

実は、今年の Splunk の Advent Calendar のきっかけは自分だったりします。

Splunk ユーザー会 GOJAS の Slack より。

最初は全然埋まらず、運営の方にご迷惑をかけたなと思っていたのですが、無事埋まって良かったです。
投稿いただいた皆さまに感謝です。

本題

Splunk の新しいバージョンや、特定の App、設定などを試してみたいときに、クリーンな環境で試してみたいというのが多々あります。

そんなとき、ConoHa なら、

  • 時間単位の課金(テストが終わったらすぐ消せる)
  • 高速起動(公式的には25秒)
  • 高速SSD(サーチが高速)
  • スタートアップスクリプトにより設定された状態で起動できる

といったメリットがあります。

今回は、ConoHa のスタートアップスクリプトを利用して、Splunk の検証環境をサクッと作ってみようという記事です。

同様の取り組みとして、Splunk Advent Calender 13日目に Docker の事例が紹介されていました。

ConoHa にも Docker のイメージがあるので、そちらで使うのもよさそうですね。

今回のこだわりポイント

ConoHa は IPv6 アドレスが最大17個利用可能なので、下記を参考に、IPv6 を有効化する設定を行いました。

URL の取得

この Splunk Advent Calendar を読んでいる皆さんは大丈夫だと思いますが、wget 用の URL をゲットします。

Splunk の場合、ディストリビューションが異なっても同じ rpm / deb が使えるのが便利ですね。

スタートアップスクリプトの利用

サーバーの作成画面で、下記のスタートアップスクリプトを入力します。

作成されたサーバーの接続情報を確認し、ブラウザで 8000 ポートを開くとログイン画面が表示されます。

CentOS 7, 8 / Fedora 31

URL と seed-password の部分は適宜変更してください。

#cloud-config
write_files:
- path: /opt/splunk/etc/system/local/server.conf
  content: |
    [general]
    listenOnIPv6 = yes
- path: /opt/splunk/etc/system/local/web.conf
  content: |
    [settings]
    listenOnIPv6 = yes
runcmd:
- rpm -i '※Splunk rpm URL'
- ln -s /opt/splunk/bin/splunk /usr/local/bin/splunk
- /opt/splunk/bin/splunk enable boot-start --accept-license --answer-yes --seed-passwd changeme
- /opt/splunk/bin/splunk start
- firewall-cmd --add-port=8000/tcp --permanent
- firewall-cmd --add-port=8089/tcp --permanent
- firewall-cmd --add-port=9997/tcp --permanent
- firewall-cmd --reload

rpm + firewalld の場合、これで対応可能です。

Web(8000)、管理用(8089)、データ転送用(9997)を空けています。
その他 syslog も受ける場合は 514 も空ける必要があったりします。

CentOS 6

#cloud-config
write_files:
- path: /opt/splunk/etc/system/local/server.conf
  content: |
    [general]
    listenOnIPv6 = yes
- path: /opt/splunk/etc/system/local/web.conf
  content: |
    [settings]
    listenOnIPv6 = yes
runcmd:
- rpm -i '※Splunk rpm URL'
- ln -s /opt/splunk/bin/splunk /usr/local/bin/splunk
- /opt/splunk/bin/splunk enable boot-start --accept-license --answer-yes --seed-passwd changeme
- /opt/splunk/bin/splunk start

Ubuntu / Debian

#cloud-config
write_files:
- path: /opt/splunk/etc/system/local/server.conf
  content: |
    [general]
    listenOnIPv6 = yes
- path: /opt/splunk/etc/system/local/web.conf
  content: |
    [settings]
    listenOnIPv6 = yes
runcmd:
- wget -O /root/splunk-8.0.1-linux-2.6-amd64.deb '※Splunk deb URL'
- dpkg -i /root/splunk-8.0.1-linux-2.6-amd64.deb
- ln -s /opt/splunk/bin/splunk /usr/local/bin/splunk
- /opt/splunk/bin/splunk enable boot-start --accept-license --answer-yes --seed-passwd changeme
- /opt/splunk/bin/splunk start

dpkg は URL 指定でインストールできなかったので、一旦 wget で落としています。

最後に:気づいたこと

Firewalld、iptables、ufw など様々なファイアウォールがあり、複数 OS に対応するのは大変かと懸念していましたが、今回テストした OS の中で、ファイアウォールが有効化されていたのは、CentOS 7、8 のみでした。

ConoHa 側のセキュリティグループで制限すればよいので、VM 側はそこまでしっかり制限しなくても良いのかもしれませんが。

とにかく、サクッと ConoHa で Splunk の検証環境が構築できました。


macOS Catalina (10.15.3) 上の VMware Fusion 11.5.1 でマウスが操作できない問題

$
0
0

macOS Catalina 上の VMware Fusion の仮想マシンが、マウスのクリック操作が効かず、キーボードのみの操作になってしまい困っていました。

今回無事解決したので記事を投稿します。

環境情報

  • ホスト OS:macOS Catalina 10.15.3
  • ハイパーバイザー:VMware Fusion 11.5.1
  • ゲスト OS:macOS Mojave 10.14.6

現象と一次対応

VM のログインについては、キーボードでパスワードの入力後 Enter キーを押すだけのため、マウスが使えないことに気づきません。

デスクトップ画面が表示され、いざ操作しようと思ったら、マウスカーソルは動くものの、クリックが効かない・・・という事に気づきます。

Command + Space の Spotlight は効くため、ハングアップしているということはないようです。

まずは、シャットダウン

VMware Fusion の画面からシャットダウンできますが、安全に停止するために、VM から停止を試してみます。

Mac の場合、Ctrl + Fn + F2 でメニューが表示されるのでそこからカーソルキーを操作して「システム終了」を選びます。

Windows の場合(検証していませんが)Command キーが Windows キーの代替となりますので、Command + X キーを押したりしてシャットダウンします。

VMware Fusion 上でマウスを使うには

VM が停止できたら、原因の調査です。

同様の事例が VMware Communities でも報告がありました。

手元の環境では、下記手順で解消しました。

  1. システム環境設定を開く
  2. セキュリティとプライバシーを開く
  3. プライバシータブを選択する
  4. アクセシビリティを選択する
  5. 必要に応じて画面左下のカギアイコンをクリックする
  6. VMware Fusion」を選択し、削除する
  7. この状態で VMware Fusion を起動すると、アクセシビリティアクセスの画面が表示されるので画面の指示に従い有効化する
macOS Catalina システム環境設定 アクセシビリティ VMWare Fusion
macOS Catalina VMWare Fusion アクセシビリティアクセス

設定完了後も、同様に最初の画像のように VMware Fusion にチェックが入っている状態になります。

仮想マシンでも正常にマウスが利用できるようになり、無事解決しました。

VMware Workstation Tech Preview + Windows 10 Insider Preview 20H1 で Hyper-V との共存が可能になったので検証してみた

$
0
0

開発版のアプリケーションの情報のため、正式リリース時は仕様等が異なる可能性があります。

従来、Hyper-V を有効化すると、VMware が利用できないというのが常識でした。

したがって、Hyper-V だけでなく、それをベースにした、Windows サンドボックス、Docker for Windows、WSL2 も、VMware ユーザーには縁が無いものでした。

ただ、最新のプレビュー版にて、共存が可能になったという情報が得られたので、早速検証してみました。

環境の準備

公式サイトより、下記が必要だと記載されています。

  • Windows 10 20H1 from Windows insider program. Minimum build number: 19041
  • Intel Haswell or newer CPU
  • AMD Bulldozer or newer CPU

今回は、Skylake の環境で、Windows 10 Insider Preview の環境を用意してテストしました。

VMware Workstation Technology Preview 20H1 Pro バージョン情報
バージョン情報

サポートされていないですが、Sandy Bridge 環境にもインストールし起動はするところまでは確認しました。

VM の起動

従来のバージョンで使用していた仮想マシンをそのまま持ってきて起動すると、このようなエラーが。

VMware Workstation does not support nested virtualization on this host
VMware Workstation does not support nested virtualization on this host
モジュール MonitorMode のパワーオンに失敗しました。

仮想マシンの設定の CPU の「Intel VT-x/EPT または AMD-V/RVI を仮想化」のチェックを外すと起動できました。

VMware Workstation Intel VT-x/EPT または AMD-V/RVI を仮想化

VM 内で Nested していた方は注意が必要かもしれません。

パフォーマンスの検証

今度こそと、VM を起動すると、下記のようなメッセージが。

仮想マシンで VMware Workstation を実行すると、パフォーマンスが低下します。
仮想マシンで VMware Workstation を実行すると、パフォーマンスが低下します。

その後無事起動しましたが、Hyper-V 上で動いているという挙動のようです。

そこで、UnixBench でベンチマークを取ってみました。

比較条件

ゲスト

  • CentOS 8.1 (Kernel 4.18.0-147.5.1)
  • UnixBench 5.1.3
  • CPU:1Core
  • メモリ:1GB

ホスト

  • CPU:Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
  • VM イメージ保存 SSD:ADATA SU750 1TB
  • Windows 10 Insider Preview 2004 (19041.153)
    • VMware Workstation Tech Preview ★今回の環境
    • Hyper-V
  • Windows 10 1909 (18363.720)
    • VMware Workstation 15.5.2

安定版とのパフォーマンスを比較しました。

比較結果

Windows 10 Insider 2004 1909
ハイパーバイザー VMWare Hyper-V VMWare
Dhrystone 2 using register variables 3106.0 3281.5 3240.7
Double-Precision Whetstone 1115.1 1101.3 1097.8
Execl Throughput 227.2 1051.8 976.7
File Copy 1024 bufsize 2000 maxblocks 1496.6 1520.6 1877.5
File Copy 256 bufsize 500 maxblocks 973.9 971.4 1243.3
File Copy 4096 bufsize 8000 maxblocks 3131.3 3236.8 3530.0
Pipe Throughput 622.8 642.2 832.0
Pipe-based Context Switching 506.9 578.8 637.9
Process Creation 768.6 903.9 753.6
Shell Scripts (1 concurrent) 713.6 1242.3 1239.9
Shell Scripts (8 concurrent) 700.0 1178.8 1182.6
System Call Overhead 290.0 295.3 473.9
System Benchmarks Index Score 841.6 1084.3 1188.7

パフォーマンスのランキングは下記となります。

  1. Hyper-V を使用しない純粋な VMware 環境
  2. Hyper-V
  3. Hyper-V 有効化環境の VMware

同一物理環境ではありますが、OS が異なるのでホスト側のドライバの問題もあると思いますが、
高パフォーマンスを実現したい場合、VMware を単独利用を続けるのもよし
WSL2 や Docker for Windows、Windows サンドボックスといった、Hyper-V 必須の機能を利用したい方も、VMware を利用できるのは良い流れと思いました。

Ubuntu 20.04 LTS Server で登場した Autoinstall YAML で自動インストールを行う(試行錯誤篇)

$
0
0

Linux ディストリビューションの一つ、Ubuntu の最新の LTS 版 20.04(Focal Fossa)がリリースされました。

最近は、いろいろなOSを素早く利用するために、CentOS なら kickstart といった自動インストールする仕組みを利用して、OS を導入しています。

Ubuntu 18.04 以前のインストール

従来、Debian ベースの Preseed を用いて自動でインストールする仕組みが提供されていました。

インストーラで聞かれるすべての質問を答えるような形で、 個人的には、直感的ではないと感じていました。

例えば、下記。
インストーラでよくある、パスワードの再入力を自動化しています。

d-i passwd/root-password password hogehoge
d-i passwd/root-password-again password hogehoge

Ubuntu 20.04 で導入された Autoinstall

新しく YAML 形式の自動インストール機能が利用可能になりました。

Preseed のような名称があるのか確認したのですがよく分からず、ここでは Autoinstall と呼びます。

cloud-init と同様に、user-data という YAML ファイルをインストーラに読み込ませます。

user-data の作成

詳細は後ほど説明しますが、試行錯誤の結果この user-data を使用します。

#cloud-config
autoinstall:
    version: 1
    identity:
        hostname: ubuntu-vm
        username: yasu
        password: "$6$以下略"
    ssh:
        install-server: yes
        authorized-keys:
            - "ssh-ed25519 以下略"
        allow-pw: true
    packages:
        - language-pack-ja
    keyboard:
        layout: jp
    refresh-installer:
        update: yes
    late-commands:
        - "mkdir -p /target/root/.ssh/"
        - "echo 'ssh-ed25519 以下略' >> /target/root/.ssh/authorized_keys"
        - chroot /target /bin/sh -c "apt-get -y upgrade"
    user-data:
        disable_root: false

Preseed よりかなりシンプルになりました。

自動インストールの実施

user-data の渡し方として、下記があります。

  • PXE インストール
  • インストール ISO でブートオプションで URL 指定
  • インストール ISO と user-data の ISO をマウント

一般的な家庭用ネットワークなので、PXE はできず、ブートオプションで URL を指定する方法を検討したのですが

autoinstall ds=nocloud-net;s=http://(Apache IP)

のように、起動オプションで渡しても、自動インストールが走らず、Apache のアクセスログを見ても来ている様子はありませんでした。

そこで、user-data の ISO をマウントすることにしました。

まずは、ボリュームラベルが「cidata」となる ISO を作成します。

Amazon Linux 2 をローカルで実行するときと同様の手順で作成可能です。

genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data

あとは、VMware なり、VirtualBox なりで、

  1. ubuntu-20.04-live-server-amd64.iso
  2. seed.iso

の順でマウントして仮想マシンを起動させます

そのままだと、しばらく読み込んだ後に本当に自動インストールするか yes / no で聞かれます。

起動オプションに「autoinstall」を追記するとこの質問をスキップできます。

試行錯誤を繰り返す場合、autoinstall を追記したものをインストール ISO として用意しておくと便利かもしれません。

また、シリアルポートが用意できる環境なら、「console=ttyS1,9600」と書いておくとファイルに書き出されるのでデバッグは楽になるかもしれません。

Ubuntu 20.04 autoinstall grub

ただ、日本語キーボードの問題で = が打てないので、これをやる場合にはインストール ISO も作成した方が良いかと思います。

動作しない点

下記は設定したものの動作を確認できませんでした。

identity username, password などのユーザー作成

サンプルにも記載されている下記の部分です。

    identity:
        username: yasu
        password: "$6$以下略"
    ssh:
        authorized-keys:
            - "ssh-ed25519 以下略"

yasu というユーザーを作成するように指定するも無視され、実際は ubuntu というユーザーが作成されています。

root@ubuntu-vm:~# ll /home/
total 12
drwxr-xr-x  3 root   root   4096 Apr 26 02:33 ./
drwxr-xr-x 20 root   root   4096 Apr 26 02:33 ../
drwxr-xr-x  3 ubuntu ubuntu 4096 Apr 26 02:33 ubuntu/

パスワードも、authorized-keys も設定されていないのでログイン不可能です。

root@ubuntu-vm:~# grep ubuntu /etc/shadow
ubuntu:!:18378:0:99999:7:::

今回は、late-commands で root ユーザーに authorized_keys を流し込んで無理矢理ログインしました。
ubuntu ユーザーを使う場合も、ここを工夫するしかなさそうです。

    late-commands:
        - "mkdir -p /target/root/.ssh/"
        - "echo 'ssh-ed25519 以下略' >> /target/root/.ssh/authorized_keys"

地域の設定

日本語を利用、タイムゾーンも JST を設定しています。

    locale: ja_JP.UTF-8
    user-data:
        timezone: "Asia/Tokyo"

しかし、反映されず・・・

root@ubuntu-vm:~# localectl
   System Locale: LANG=C.UTF-8
       VC Keymap: n/a
      X11 Layout: jp
       X11 Model: pc105
root@ubuntu-vm:~# timedatectl status | grep zone
                Time zone: Etc/UTC (UTC, +0000)

キーボードだけは反映されているようです。

    keyboard:
        layout: jp

まとめ

Autoinstall YAML により従来は手作業、もしくは煩雑な Preseed で自動インストールしていた作業を簡単に自動化できることを確認しました。

wget, curl, git などは明示的に指定しなくてもインストールされていました。

また、VMware のゲストの場合、open-vm-tools もインストールされていました。

Preseed でインストールした Ubuntu 18.04 ではこれらは明示的にインストールしていたのでとても良いです。

ユーザー設定、言語設定といったリファレンスに書かれているものも、正常に動作しない部分もありこれからといった印象がありますが、コマンドを流し込むことも可能なので、工夫次第でなんとかなりそうです。

macOS Catalina のファイアウォールを pf (packet filter)で強化する

$
0
0

macOS のファイアウォールはこのようなもので非常に簡易なものです。

macOS Catalina ファイアウォール

例えば、上記だとすべての環境から SSH が可能になります。

IPv4 のプライベートIPアドレスなら問題はないものの、IPv6 の場合、たいていの場合 ISP からグローバルユニキャストアドレスが付与されるため、適切な設定を行わないと、外部から SSH によるログインが可能となってしまします。

一時的な IPv6 アドレス(匿名 IPv6 アドレス)が有効化されている場合、アドレスが頻繁に変わるのですが、何らかの原因で現在の IPv6 アドレスが知られた場合、ログイン試行される懸念があります。

今回は、macOS 標準の pf(packet filter)の紹介を行います。
インターネットにも日本語の資料がほとんどないので、役に立てばと思います。

Windows の場合

Windows 10 では「セキュリティが強化された Windows Defender ファイアウォール」という機能があります。

Windows 10 セキュリティが強化された Windows Defender ファイアウォール

アプリケーションだけでなく、IP アドレス、ポートでも制限が可能で、様々な制限が可能です。

macOS pf 設定方法

今回は、下記の環境です。

  • macOS Catalina 10.15.4

pf を便利に使うための GUI ツールとして、IceFloor というのがあるとのことですが、Catalina では動作しませんでした。

pf の有効化・無効化

-s info (-si)オプションで確認できます。
出力が多いですが、最初のほうだけ確認すれば OK です。

停止中

% sudo pfctl -si | head -n 1
No ALTQ support in kernel
ALTQ related functions disabled
Status: Disabled                              Debug: Urgent

動作中

% sudo pfctl -si | head -n 1
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 0 days 01:11:41           Debug: Urgent

有効化

-e オプションで有効化できますが、これは一時的なもので、再起動時には自動で起動されません。

下記が参考になりました。

/System/Library/LaunchDaemons/com.apple.pfctl.plist を書き換えるとよいのですが正常に書き換えできず、

システム環境設定 → セキュリティとプライバシー → ファイアウォール → ファイアウォールのオプション → ステルスモードを有効にする
(記事最初の画像)

を有効にすると、自動的に pf が有効化されました。

pf 設定変更

基本的には下記の流れになります。

  1. /etc/pf.conf の編集
  2. pfctl -nf /etc/pf.conf による確認
  3. sudo pfctl -f /etc/pf.conf による反映
  4. sudo pfctl -v -sr (-s rules)による現在ロードされているルールの確認

信頼できるネットワークからのみ SSH をログイン

  • 192.0.2.0/24
  • 2001:db8:1234:5678::/64

をプライベートIP、ISP からアサインされている IPv6 サブネットとした場合の、特定のネットワークからのみ SSH ログインする設定は下記となります。

priv_nw = "{192.0.2.0/24, 2001:db8:1234:5678::/64}"

block in proto tcp from any to any port = 22
pass in proto tcp from $priv_nw to any port = 22

基本的に pass 設定となっているため、事前に block を入れておきます。

また、priv_nw という変数としておくことで、汎用性も考慮しています。

この設定の場合、異なる IPv6 ネットワークに接続している場合、家庭からの SSH も可能になりますが、グローバルユニキャストアドレスのためここは許可しています。

pf では NIC 名 :network で該当ネットワークの IP アドレスが自動的に反映されるのですが、pf 起動時にネットワークに接続していなかったり、ネットワーク環境が変わった場合に正常に設定が入らないため、このような設定にしています。

ログの確認

最初の一回だけ、ログを出力するためのインターフェースを作成します。

ifconfig pflog0 
ifconfig pflog0 create # does not exist と表示される場合のみ

block in / pass in のあとに log を記載したルールがログに出力されるようになります。

tcpdump -v -n -e -ttt -i pflog0

まとめ

情報が少ない、macOS のファイアウォールについて、設定方法を確認し、反映されることを確認しました。

昨今の在宅勤務の増加に伴い、IPv6 が利用可能な回線に切り替えている方が増えていますので、これを機にセキュリティも考慮していただけたらと思います。

参考資料

CentOS・RHEL 8 から 1GB RAM でも kdump の crashkernel メモリ 160MB が確保される件

$
0
0

昨日、CentOS 7.7 から CentOS 8.1 にマイグレーションしたのですが、想定以上にメモリの使用率が高かったので確認しました。

ConoHa の 1GB プランで動作しているのですが、合計メモリの認識に差異があるようです。

状況の確認

調査を進めたところ、カーネルクラッシュダンプをキャプチャーする kdump が有効になっていて、その分システムメモリが減少していることを確認しました。

CentOS 7.7 – 1GB

以前の環境は、いろいろチューニングしていた可能性があったので、念のため新規のVMで確認しました。

CentOS 7 1GB RAM kdump failed

CentOS 7 で 1GB メモリの場合、kdump は無効であることを確認できました。

CentOS 8.1 – 1GB

CentOS 8 1GB RAM kdump active

こちらも、念のため新規の VM で確認しましたが、CentOS 8 の場合、1GB メモリでも kdump が有効であり、その分 OS 上のメモリ総容量が160MB以上減っていることが確認できました。

CentOS 8.1 – 512MB

CentOS 8 512MB RAM kdump failed

もしやと思って確認しましたが、CentOS 8 でも 512MB メモリの場合は kdump は無効でした。

仕様の確認

私の認識としては、数GB以上のメモリがないと crashkernel=auto によりメモリが予約されず、kdump も動作しない認識でした。

RHEL のドキュメントを確認してみます。

どちらも crashkernel=auto の「自動メモリー予約に必要な最小メモリーサイズ」は 2GB なので、1GB の場合確保されないように読み取れます。

ただ、「kdump 用に必要な最小予約メモリー」については、

  • RHEL7:使用可能なメモリー 2GB以上(以下略)
  • RHEL8:使用可能なメモリー 1GB から 64GB→160 MB のメモリー(以下略)

となっており、8からは 1GB 以上から使用可能になったようです。

kdump・crashkernel の無効化

クラッシュ時の原因究明には必要な情報とは理解しつつも、メモリが少ない環境なので、メモリ不足によるクラッシュの方が可能性が大きいと考え、今回は無効化します。

まずは /boot/grub2/grub.cfg の crashkernel=auto の部分を削除します。

GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet net.ifnames=0 console=tty0 console=ttyS0,115200n8r"

GRUB_CMDLINE_LINUX="rhgb quiet net.ifnames=0 console=tty0 console=ttyS0,115200n8r"

そして、grub2-mkconfig -o /boot/grub2/grub.cfg コマンドにて更新、サーバーを再起動します。

# free -m
              total        used        free      shared  buff/cache   available
Mem:            981         662          75          26         242         152
Swap:          2047          21        2026

# systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2020-05-10 19:11:18 JST; 1min 11s ago
  Process: 1338 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
 Main PID: 1338 (code=exited, status=1/FAILURE)

May 10 19:11:18 systemd[1]: Starting Crash recovery kernel arming...
May 10 19:11:18 kdumpctl[1338]: No memory reserved for crash kernel
May 10 19:11:18 kdumpctl[1338]: Starting kdump: [FAILED]
May 10 19:11:18 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
May 10 19:11:18 systemd[1]: kdump.service: Failed with result 'exit-code'.
May 10 19:11:18 systemd[1]: Failed to start Crash recovery kernel arming.

無事、メモリが160MB増加し、kdump も動作しないことを確認しました。
気になるようなら systemctl disable kdump を実行しても良いかと思います。

運用後、クラッシュが発生するようなら、設定を戻したいと思います。

まとめ

CentOS 8 ではメモリ 1GB でも kdump が有効化されるようになりました。

インターネット上でこれに言及している情報が見つけられませんでしたが、メモリ 1GB でサーバーを運用されている方は、160MB というのは大きな違いだと思うので頭に入れておいた方がよい情報だと思いました。

CentOS 7 / 8 で kickstart するにはメモリ 2GB 以上必要

$
0
0

昨日更新した下記の記事で、念のためローカル環境でも確認を行おうとしました。

先日紹介した、Ubuntu 20.04 の Autoinstall yaml のようにローカルでの OS インストールは自動化しています。

CentOS 7 / 8 については、Kickstart による自動インストールを行っています。

今回も、Kickstart で OS を入れようと思ったら、下記のようなエラーでインストールが始まらない状態になってしまいました。

dracut-initqueue[687]: curl: (23) Failed writing body (9184 != 16384)
dracut-initqueue[687]: mount: wrong fs type, bad option, bad superblock on /dev/loop0,
dracut-initqueue[687]: missing codepage or helper program, or other error
dracut-initqueue[687]: In some cases useful info is found in syslog - try
dracut-initqueue[687]: dmesg | tail or so.
dracut-initqueue[687]: umount: /run/initramfs/squashfs: not mounted
dracut-initqueue[687]: /sbin/dmsquash-live-root: line 110: printf: write error: No space left on device

最初、ディスクが認識されないのかと思って試行錯誤したのですが、Preseed による Ubuntu 18.04 インストールは途中まで走ることを確認したので、ディスクも問題なさそうです。

解決策

下記のページがヒットしました。

結論、2GB 以上のメモリが必要だそうです。

今回は 1GB の挙動を調べたかったのですが、今まで作るときは 2GB 以上に設定していた気もしてきました。

無事、2GB でインストールを完走、その後 1GB に変更しても問題無く動作することを確認しました。

まとめ

CentOS 7 / 8 で kickstart で OS をインストールするにはメモリ 2GB 以上必要であることが分かりました。

VMware のウィザードから CentOS 7 を作成すると、デフォルトでは 1GB になるので注意と思いました。

VMware wizard CentOS 7

Ansible 2.9 の firewalld モジュールで NIC の zone を変更しても permanent で永続化されない件

$
0
0

Ansible で Firewalld の設定を行ったところ、NIC の Zone の変更について、OS を再起動すると設定がリセットされる現象を確認しました。

具体的な例

環境

  • Ansible 2.9.10
  • CentOS 8.2 (2004)

Playbook

firewalld モジュールを使います。

- name: set eth0 internal
  firewalld:
    zone: internal
    interface: eth0
    permanent: yes
    state: enabled
    immediate: yes

実行前の状態

# firewall-cmd --list-interface --zone=public
eth0 eth1

実行結果

-v を付けた結果となりますが、実行直後は設定変更されているように見えます。

TASK [common : set eth0 internal] *
 changed: [cent8-router-vm] => {"changed": true, "msg": "Permanent and Non-Permanent(immediate) operation, Changed eth0 to zone internal"}
# firewall-cmd --list-interface --zone=internal
eth0

再起動後

このように元の状態に戻ってしまいました。

# firewall-cmd --list-interface --zone=public
eth0 eth1

他の方の報告

この件は、2年前の2018年に最初の報告がありますが、現時点でも解消していないようです。

回避方法

Ansible の Firewalld モジュールではなく、firewall-cmd コマンドを実行するしかなさそうです。

- name: set eth0 internal
  command: "firewall-cmd --zone=internal --permanent --add-interface=eth0"

- name: reload firewalld
  command: "firewall-cmd --reload"

英語の情報はありましたが、日本語での事例はなかったので、今回ブログにまとめました。


Windows 10 2004 でプロトコルエラー(0x112f)でリモートデスクトップできない場合の対処法

$
0
0

久々に外出し、外から自宅の Windows 10 の PC に Windows リモートデスクトップをしようとしたところ下記のエラーが表示され、接続できませんでした。

プロトコル エラー(コード: 0x112f)のため、リモート セッションは切断されます。リモート コンピューターへの接続をもう一度実行してください。

プロトコル エラー(コード: 0x112f)のため、リモート セッションは切断されます。リモート コンピューターへの接続をもう一度実行してください。

macOS や Android からは正常に接続できたため、Windows のリモートデスクトップクライアントとの相性のようです。

解決しなかった対策

外出先ではなく、ローカルネットワークでも確認しましたが再現しました。

同様のメッセージで確認したところ、

  • 再起動したら直る
  • メモリが少ないのでは

というのはありましたが、再起動は実施済み、メモリも 32GB あり十分余裕はありました。

解決策

下記のページがヒントになりました。

接続先の PC のローカル グループ ポリシー エディターを開き設定を変更します。
下記の手順でたどっていきます。

  1. ローカル コンピューター ポリシー
  2. コンピューターの構成
  3. 管理用テンプレート
  4. Windows コンポーネント
  5. リモート デスクトップ サービス
  6. リモート デスクトップ セッション ホスト
  7. リモート セッション環境

この画面で下記の二点が「有効」になっていたので「未構成」に変更しました。

  • リモート デスクトップ接続で H.264/AVC 444 グラフィックモードを優先する
  • リモート デスクトップ接続用に H.264/AVC 444 ハードウェア エンコードを構成する
ローカル コンピューター ポリシー → コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → リモート デスクトップ サービス → リモート デスクトップ セッション ホスト
リモート セッション環境

その後無事、Windows 10 の PC から正常にリモートデスクトップができるようになりました。

原因

H.264/AVC 444 に関する項目は、以前どこかのページで、リモートデスクトップの圧縮率を高めたり、画質を向上させるのに有効という情報を見かけて有効化していました。

デフォルトでは「未構成」のためほとんどの場合は影響がないと思います。

H.264/AVC 444 有効化状態でもリモートデスクトップ接続できるようになることを願い、フィードバックを送信しました。

VirtualBox の virtio(準仮想化)・Intel・PCnet のアダプターでパフォーマンスを比較してみる

$
0
0

VirtualBox でネットワークを使用する際、バージョン 6.1.10 の場合アダプタータイプとして下記の6つが選べます。

  • PCnet-PCI Ⅱ (Am79C970A)
  • PCnet-Fast Ⅲ (Am79C973)
  • Intel PRO/1000 MT デスクトップ (82540EM)
  • Intel PRO/1000 T サーバー (82543GC)
  • Intel PRO/1000 MT サーバー (82545EM)
  • 準仮想化ネットワーク (virtio-net)

VirtualBox のマニュアルによると、virtio はハードウェアのエミュレーションを行わないため、最も性能が高いとのことです。

ただし、Windows ゲストの場合は標準のドライバでは対応していないため、下記のページからドライバをダウンロードする必要はあります。

自分も VirtualBox を利用する際は、できるだけ virtio を使用するようにしています。

ただ、どれくらい早いのというのは理解していなかったので実際に iperf3 でベンチマークを取ってみました。

測定環境

同一のホスト、同一の仮想ネットワーク内に二つ下記の仮想マシンを立てて検証しました。

  • ホスト CPU:Intel Core i5 2405S
  • ホスト OS:Windows 10 Version 2004 64bit
  • ハイパーバイザー:VirtualBox 6.1.10
  • ゲスト OS:Ubuntu 20.04 Kernel 5.4.0-40
  • 速度測定に使用したツール:iperf 3.7

測定結果

3回測定して、平均値を記載します。

  1. 準仮想化ネットワーク (virtio-net):7.01 Gbps
  2. Intel PRO/1000 T サーバー (82543GC):2.05 Gbps
  3. Intel PRO/1000 MT サーバー (82545EM):1.91 Gbps
  4. Intel PRO/1000 MT デスクトップ (82540EM):1.88 Gbps
  5. PCnet-Fast Ⅲ (Am79C973):1.03 Gbps
  6. PCnet-PCI Ⅱ (Am79C970A):927 Mbps

まとめ

パフォーマンスがよいといわれている virtio が Intel PRO/1000 の3倍以上高速というのが分かりました。

また、測定中 CPU を1コア占有していたため、より高速な CPU であれば、パフォーマンスも向上するかもしれません。

inspircd-docker で素早く IRC サーバーを構築する

$
0
0

令和になって、需要があるかは不明ですが、IRC サーバーを構築してみたのでメモしてみます。

CentOS 8 においては、IRC サーバーのパッケージがないようで、自分でビルドする必要があるようです。

そこで、今回は、Docker を用いて IRC サーバーと立ててみます。

Docker Hub にこのようなものがありましたので使ってみます。

環境

Docker なので細かく環境は書く必要はないと思いますが、一応記載します。

  • CentOS 8.2
  • Docker 19.03.13
  • InspIRCd 3.7.0

環境構築

例のように、下記のコマンドを実行します。

docker run --name ircd -p 6667:6667 inspircd/inspircd-docker

動作確認

Windows 用 IRC クライアントソフトの LimeChat を用いて確認してみます。

Docker が動いている IP の 6667 ポートに接続するように設定するだけで完了です。

LimeChat inspircd-docker

画像では見えていないですが、Docker ならではのメッセージもありましたので、こちらに全文記載します。

00:00   _____                        _____   _____    _____      _
00:00  |_   _|                      |_   _| |  __ \  / ____|    | |
00:00    | |    _ __    ___   _ __    | |   | |__) || |       __| |
00:00    | |   | '_ \  / __| | '_ \   | |   |  _  / | |      / _` |
00:00   _| |_  | | | | \__ \ | |_) | _| |_  | | \ \ | |____ | (_| |
00:00  |_____| |_| |_| |___/ | .__/ |_____| |_|  \_\ \_____| \__,_|
00:00      __________________| |_______________________________
00:00     |__________________|_|_______________________________|
00:00  
00:00                          Putting the ricer in IRCer since 2007
00:00  
00:00         //\
00:00         V  \    WELCOME TO AN INSPIRCD NETWORK
00:00          \  \_    If you see this, I am probably new.
00:00           \,'.`-.   If I'm not new, my owner is lazy.
00:00            |\ `. `.
00:00            ( \  `. `-.                        _,.-:\
00:00             \ \   `.  `-._             __..--' ,-';/
00:00              \ `.   `-.   `-..___..---'   _.--' ,'/
00:00               `. `.    `-._        __..--'    ,' /
00:00                 `. `-_     ``--..''       _.-' ,'
00:00                   `-_ `-.___        __,--'   ,'
00:00                      `-.__  `----"""    __.-'
00:00                           `--..____..--'
00:00  
00:00  
00:00  
00:00           ------ To change, see docker.motd ------
00:00         /                                          \
00:00        /   * Web: http://www.inspircd.org           \
00:00        |   * IRC: irc.inspircd.org #inspircd        |
00:00        |   * Docs: http://wiki.inspircd.org         |
00:00        |   * Bugs: http://inspircd.org/bugs         |
00:00        |                                            |
00:00        | We hope you like this software. Please do  |
00:00        | make  sure  you  put  some  effort  into   |
00:00        | your configuration, though, so you love it.|
00:00        | Enjoy.                                     |
00:00        |                                            |
00:00        \                   -- The InspIRCd Team    /
00:00         -------------------------------------------
00:00  
00:00  -------------------------------------------------------------
00:00  
00:00                          ##         .
00:00                    ## ## ##        ==
00:00                 ## ## ## ## ##    ===
00:00             /"""""""""""""""""\___/ ===
00:00        ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
00:00             \______ o           __/
00:00               \    \         __/
00:00                \____\_______/
00:00  
00:00  
00:00  
00:00        A warm welcome from the InspIRCd-Docker Team, too!
00:00        For Issues:
00:00        https://github.com/inspircd/inspircd-docker/issues
00:00  
00:00        Have fun with the image!
00:00 End of message of the day.

まとめ

Docker で素早く IRC サーバーを構築することができました。

今回はとりあえず立ててみるだけの記事ですが、TLS による暗号化で自分の所有しているものも設定できたり、ある程度の設定変更は可能なようです。

Zabbix Agent 2 の StatusPort を設定した場合に得られる情報を確認する

$
0
0

Zabbix Agent 2 を使ってみたところ、従来の Agent と比較し StatusPort という項目が増えていたのですが、何ができるのかなどの情報が見つからなかったので確認してみました。

StatusPort

The port agent 2 will be listening on for HTTP status request and display of a list of configured plugins and some internal parameters

確認環境

下記のバージョンで確認しました。

  • Zabbix Agent 2 v5.0.3
  • Linux 版:CentOS 8.2 上の Docker
  • Windows 版:Windows 10

設定方法

設定ファイルにこのような項目があり、デフォルトでは設定されていないポート番号を設定した上で Agent 2 を起動します。

### Option: StatusPort
#	Agent will listen on this port for HTTP status requests.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# StatusPort=

http://(IPアドレス):(StatusPort)/status にアクセスします。/だと404になります。

Linux 版

Zabbix Agent 2 [0360ed6a460c]. (5.0.3)
using configuration file: /etc/zabbix/zabbix_agent2.conf
ServerActive: zabbix-server:10051
ListenPort: 10050

[Agent]
active: false
capacity: 0/100
tasks: 0
agent.hostname: Returns Hostname from agent configuration.
agent.ping: Returns agent availability check result.
agent.version: Version of Zabbix agent.

[Cpu]
active: false
capacity: 0/100
tasks: 0
system.cpu.discovery: List of detected CPUs/CPU cores, used for low-level discovery.
system.cpu.num: Number of CPUs.
system.cpu.util: CPU utilisation percentage.

[Docker]
active: false
capacity: 0/100
tasks: 0
docker.container_info: Return low-level information about a container.
docker.container_stats: Returns near realtime stats for a given container.
docker.containers: Returns a list of containers.
docker.containers.discovery: Returns a list of containers, used for low-level discovery.
docker.data_usage: Returns information about current data usage.
docker.images: Returns a list of images.
docker.images.discovery: Returns a list of images, used for low-level discovery.
docker.info: Returns information about the docker server.
docker.ping: Pings the server and returns 0 or 1.

[File]
active: false
capacity: 0/100
tasks: 0
vfs.file.cksum: Returns File checksum, calculated by the UNIX cksum algorithm.
vfs.file.contents: Retrieves contents of the file.
vfs.file.exists: Returns if file exists or not.
vfs.file.md5sum: Returns MD5 checksum of file.
vfs.file.regexp: Find string in a file.
vfs.file.regmatch: Find string in a file.
vfs.file.size: Returns file size.
vfs.file.time: Returns file time information.

[Kernel]
active: false
capacity: 0/100
tasks: 0
kernel.maxfiles: Returns maximum number of opened files supported by OS.
kernel.maxproc: Returns maximum number of processes supported by OS.

[Log]
active: false
capacity: 0/100
tasks: 0
log: Log file monitoring.
log.count: Count of matched lines in log file monitoring.
logrt: Log file monitoring with log rotation support.
logrt.count: Count of matched lines in log file monitoring with log rotation support.

[Memcached]
active: false
capacity: 0/100
tasks: 0
memcached.ping: Test if connection is alive or not.
memcached.stats: Returns output of stats command.

[Mysql]
active: false
capacity: 0/100
tasks: 0
mysql.db.discovery: Databases discovery.
mysql.db.size: Database size in bytes.
mysql.get_status_variables: Values of global status variables.
mysql.ping: If the DBMS responds it returns '1', and '0' otherwise.
mysql.replication.discovery: Replication discovery.
mysql.replication.get_slave_status: Replication status.
mysql.version: MySQL version.

[NetIf]
active: false
capacity: 0/100
tasks: 0
net.if.collisions: Returns number of out-of-window collisions.
net.if.discovery: Returns list of network interfaces. Used for low-level discovery.
net.if.in: Returns incoming traffic statistics on network interface.
net.if.out: Returns outgoing traffic statistics on network interface.
net.if.total: Returns sum of incoming and outgoing traffic statistics on network interface.

[Postgres]
active: false
capacity: 0/100
tasks: 0
pgsql.archive: Returns info about size of archive files.
pgsql.autovacuum.count: Returns count of autovacuum workers.
pgsql.bgwriter: Returns JSON for sum of each type of bgwriter statistic.
pgsql.cache.hit: Returns cache hit percent.
pgsql.connections: Returns JSON for sum of each type of connection.
pgsql.db.age: Returns age for each database.
pgsql.db.bloating_tables: Returns percent of bloating tables for each database.
pgsql.db.discovery: Returns JSON discovery rule with names of databases.
pgsql.db.size: Returns size for each database.
pgsql.dbstat: Returns JSON for sum of each type of statistic.
pgsql.dbstat.sum: Returns JSON for sum of each type of statistic for all database.
pgsql.locks: Returns collect all metrics from pg_locks.
pgsql.oldest.xid: Returns age of oldest xid.
pgsql.ping: Test if connection is alive or not.
pgsql.replication.count: Returns number of standby servers.
pgsql.replication.lag.b: Returns replication lag with Master in byte.
pgsql.replication.lag.sec: Returns replication lag with Master in seconds.
pgsql.replication.master.discovery.application_name: Returns JSON discovery with application name from pg_stat_replication.
pgsql.replication.recovery_role: Returns postgreSQL recovery role.
pgsql.replication.status: Returns postgreSQL replication status.
pgsql.uptime: Returns uptime.
pgsql.wal.stat: Returns JSON wal by type.

[Proc]
active: false
capacity: 0/100
tasks: 0
proc.cpu.util: Process CPU utilisation percentage.

[Redis]
active: false
capacity: 0/100
tasks: 0
redis.config: Returns configuration parameters of Redis server.
redis.info: Returns output of INFO command.
redis.ping: Test if connection is alive or not.
redis.slowlog.count: Returns the number of slow log entries since Redis has been started.

[SystemRun]
active: false
capacity: 0/100
tasks: 0
system.run: Run specified command.

[Systemd]
active: false
capacity: 0/100
tasks: 0
systemd.unit.discovery: Returns JSON array of discovered units, usage: systemd.unit.discovery[<type>].
systemd.unit.info: Returns the unit info, usage: systemd.unit.info[unit,<parameter>,<interface>].

[TCP]
active: false
capacity: 0/100
tasks: 0
net.tcp.port: Checks if it is possible to make TCP connection to specified port.
net.tcp.service: Checks if service is running and accepting TCP connections.
net.tcp.service.perf: Checks performance of TCP service.

[UDP]
active: false
capacity: 0/100
tasks: 0
net.udp.service: Checks if service is running and responding to UDP requests.
net.udp.service.perf: Checks performance of UDP service.

[Uname]
active: true
capacity: 0/100
tasks: 0
system.hostname: Returns system host name.
system.sw.arch: Software architecture information.
system.uname: Returns system uname.

[Uptime]
active: false
capacity: 0/100
tasks: 0
system.uptime: Returns system uptime in seconds.

[VFSDev]
active: false
capacity: 0/100
tasks: 0
vfs.dev.discovery: List of block devices and their type. Used for low-level discovery.
vfs.dev.read: Disk read statistics.
vfs.dev.write: Disk write statistics.

[VfsFs]
active: false
capacity: 0/100
tasks: 0
vfs.fs.discovery: List of mounted filesystems. Used for low-level discovery.
vfs.fs.get: List of mounted filesystems with statistics.
vfs.fs.inode: Disk space in bytes or in percentage from total.
vfs.fs.size: Disk space in bytes or in percentage from total.

[Web]
active: false
capacity: 0/100
tasks: 0
web.page.get: Get content of a web page.
web.page.perf: Loading time of full web page (in seconds).
web.page.regexp: Find string on a web page.

[ZabbixAsync]
active: false
capacity: 0/100
tasks: 0
net.tcp.listen: Checks if this TCP port is in LISTEN state.
net.udp.listen: Checks if this UDP port is in LISTEN state.
sensor: Hardware sensor reading.
system.boottime: Returns system boot time.
system.cpu.intr: Device interrupts.
system.cpu.load: CPU load.
system.cpu.switches: Count of context switches.
system.hw.cpu: CPU information.
system.hw.macaddr: Listing of MAC addresses.
system.localtime: Returns system local time.
system.sw.os: Operating system information.
system.swap.in: Swap in (from device into memory) statistics.
system.swap.out: Swap out (from memory onto device) statistics.

[ZabbixStats]
active: false
capacity: 0/100
tasks: 0
zabbix.stats: Return a set of Zabbix server or proxy internal metrics or return number of monitored items in the queue which are delayed on Zabbix server or proxy.

[ZabbixSync]
active: false
capacity: 0/1
tasks: 0
net.dns: Checks if DNS service is up.
net.dns.record: Performs DNS query.
proc.mem: Memory used by process in bytes.
proc.num: The number of processes.
system.hw.chassis: Chassis information.
system.hw.devices: Listing of PCI or USB devices.
system.sw.packages: Listing of installed packages.
system.swap.size: Swap space size in bytes or in percentage from total.
system.users.num: Number of users logged in.
vfs.dir.count: Directory entry count.
vfs.dir.size: Directory size (in bytes).
vm.memory.size: Memory size in bytes or in percentage from total.

Windows 版

Zabbix Agent 2 [Windows host]. (5.0.3)
using configuration file: (省略)
ServerActive: 127.0.0.1
ListenPort: 10050

[Agent]
active: false
capacity: 0/100
tasks: 0
agent.hostname: Returns Hostname from agent configuration.
agent.ping: Returns agent availability check result.
agent.version: Version of Zabbix agent.

[Cpu]
active: false
capacity: 0/100
tasks: 0
system.cpu.discovery: List of detected CPUs/CPU cores, used for low-level discovery.
system.cpu.load: CPU load.
system.cpu.num: Number of CPUs.
system.cpu.util: CPU utilisation percentage.

[File]
active: false
capacity: 0/100
tasks: 0
vfs.file.cksum: Returns File checksum, calculated by the UNIX cksum algorithm.
vfs.file.contents: Retrieves contents of the file.
vfs.file.exists: Returns if file exists or not.
vfs.file.md5sum: Returns MD5 checksum of file.
vfs.file.regexp: Find string in a file.
vfs.file.regmatch: Find string in a file.
vfs.file.size: Returns file size.
vfs.file.time: Returns file time information.

[Log]
active: false
capacity: 0/100
tasks: 0
log: Log file monitoring.
log.count: Count of matched lines in log file monitoring.
logrt: Log file monitoring with log rotation support.
logrt.count: Count of matched lines in log file monitoring with log rotation support.

[Memory]
active: false
capacity: 0/100
tasks: 0
vm.memory.size: Returns memory size in bytes or in percentage from total.

[NetIf]
active: false
capacity: 0/100
tasks: 0
net.if.discovery: Returns list of network interfaces. Used for low-level discovery.
net.if.in: Returns incoming traffic statistics on network interface.
net.if.list: Returns a list of network interfaces in text format.
net.if.out: Returns outgoing traffic statistics on network interface.
net.if.total: Returns sum of incoming and outgoing traffic statistics on network interface.

[Postgres]
active: false
capacity: 0/100
tasks: 0
pgsql.archive: Returns info about size of archive files.
pgsql.autovacuum.count: Returns count of autovacuum workers.
pgsql.bgwriter: Returns JSON for sum of each type of bgwriter statistic.
pgsql.cache.hit: Returns cache hit percent.
pgsql.connections: Returns JSON for sum of each type of connection.
pgsql.db.age: Returns age for each database.
pgsql.db.bloating_tables: Returns percent of bloating tables for each database.
pgsql.db.discovery: Returns JSON discovery rule with names of databases.
pgsql.db.size: Returns size for each database.
pgsql.dbstat: Returns JSON for sum of each type of statistic.
pgsql.dbstat.sum: Returns JSON for sum of each type of statistic for all database.
pgsql.locks: Returns collect all metrics from pg_locks.
pgsql.oldest.xid: Returns age of oldest xid.
pgsql.ping: Test if connection is alive or not.
pgsql.replication.count: Returns number of standby servers.
pgsql.replication.lag.b: Returns replication lag with Master in byte.
pgsql.replication.lag.sec: Returns replication lag with Master in seconds.
pgsql.replication.master.discovery.application_name: Returns JSON discovery with application name from pg_stat_replication.
pgsql.replication.recovery_role: Returns postgreSQL recovery role.
pgsql.replication.status: Returns postgreSQL replication status.
pgsql.uptime: Returns uptime.
pgsql.wal.stat: Returns JSON wal by type.

[Proc]
active: false
capacity: 0/100
tasks: 0
proc.num: The number of processes.
proc_info: Various information about specific process(es).

[Redis]
active: false
capacity: 0/100
tasks: 0
redis.config: Returns configuration parameters of Redis server.
redis.info: Returns output of INFO command.
redis.ping: Test if connection is alive or not.
redis.slowlog.count: Returns the number of slow log entries since Redis has been started.

[Swap]
active: false
capacity: 0/100
tasks: 0
system.swap.size: Returns Swap space size in bytes or in percentage from total.

[SystemRun]
active: false
capacity: 0/100
tasks: 0
system.run: Run specified command.

[TCP]
active: false
capacity: 0/100
tasks: 0
net.tcp.listen: Checks if this TCP port is in LISTEN state.
net.tcp.port: Checks if it is possible to make TCP connection to specified port.
net.tcp.service: Checks if service is running and accepting TCP connections.
net.tcp.service.perf: Checks performance of TCP service.

[UDP]
active: false
capacity: 0/100
tasks: 0
net.udp.service: Checks if service is running and responding to UDP requests.
net.udp.service.perf: Checks performance of UDP service.

[Uname]
active: false
capacity: 0/100
tasks: 0
system.hostname: Returns system host name.
system.sw.arch: Software architecture information.
system.uname: Returns system uname.

[Uptime]
active: false
capacity: 0/100
tasks: 0
system.uptime: Returns system uptime in seconds.

[Users]
active: false
capacity: 0/100
tasks: 0
system.users.num: Returns number of useres logged in.

[VfsFs]
active: false
capacity: 0/100
tasks: 0
vfs.fs.discovery: List of mounted filesystems. Used for low-level discovery.
vfs.fs.get: List of mounted filesystems with statistics.
vfs.fs.size: Disk space in bytes or in percentage from total.

[Web]
active: false
capacity: 0/100
tasks: 0
web.page.get: Get content of a web page.
web.page.perf: Loading time of full web page (in seconds).
web.page.regexp: Find string on a web page.

[WindowsEventlog]
active: false
capacity: 0/100
tasks: 0
eventlog: Windows event log file monitoring.

[WindowsPerfInstance]
active: false
capacity: 0/1
tasks: 0
perf_instance.discovery: Get Windows performance instance object list.
perf_instance_en.discovery: Get Windows performance instance object English list.

[WindowsPerfMon]
active: false
capacity: 0/100
tasks: 0
perf_counter: Value of any Windows performance counter.
perf_counter_en: Value of any Windows performance counter in English.

[WindowsServices]
active: false
capacity: 0/100
tasks: 0
service.discovery: List of Windows services for low-level discovery.
service.info: Information about a service.
services: Filtered list of Windows sercices.

[Wmi]
active: false
capacity: 0/100
tasks: 0
wmi.get: Execute WMI query and return the first selected object.
wmi.getall: Execute WMI query and return the whole response converted in JSON format.

[ZabbixAsync]
active: false
capacity: 0/100
tasks: 0
system.localtime: Returns system local time.

[ZabbixStats]
active: false
capacity: 0/100
tasks: 0
zabbix.stats: Return a set of Zabbix server or proxy internal metrics or return number of monitored items in the queue which are delayed on Zabbix server or proxy.

[ZabbixSync]
active: false
capacity: 0/1
tasks: 0
net.dns: Checks if DNS service is up.
net.dns.record: Performs DNS query.
vfs.dir.count: Directory entry count.
vfs.dir.size: Directory size (in bytes).

まとめ

StatusPort を設定することで

  • バージョン情報
  • 利用している Plugin
  • サポートされているアイテムキー
  • Capacity

などが得られることを確認しました。

これにより、Zabbix で監視が正常に行えない場合、正常に起動しているか、そのアイテムキーがサポートされているか、Capacity が溢れていないか等を切り分けができるようになりました。

現状、Zabbix Server からはこの値はとれないようなので、今後使えるようになるとうれしいなと思います。

SoftEther で使われる MAC アドレスを整理してみた

$
0
0

自宅で SoftEther の VPN サーバーを立てているのですが、MAC アドレスが一般的な MAC アドレスリストに載っておらず、調査するときに困るので整理してみました。

SoftEther VPN Client 利用時

Windows や Linux で利用可能な、SoftEther VPN Client を使用した場合の MAC アドレスを整理します。

[5E]

2018/04/21 にリリースされた SoftEther VPN 4.27 Build 9666 Beta 以降、仮想 LAN カードをインストールする際に初期設定されるランダムな MAC アドレスに最初の文字列になります。

[00:AC]

SoftEther VPN 4.25 Build 9656 以前のバージョンで設定した仮想 LAN カードはこの MAC アドレスになっているようです。

L2TP/IPsec, SSTP, OpenVPN L3

SoftEther VPN Client が使えない環境では、汎用的なプロトコルを使用し、こちらの MAC アドレスが使用されます。

[AE] L2TP/IPsec, SSTP, OpenVPN L3 における仮想 MAC アドレスのユーザーごとの固定機能

2019/11/18 にリリースされた SoftEther VPN 4.31 Build 9727 Beta 以降で、SoftEther VPN Client 以外の方法で接続された場合の MAC アドレスが固定できるようになりました。

先頭 1 バイトは「ae」で始めることを推奨されているため、この MAC アドレスが見えたらここで設定したものの可能性があります。

[CA] 固定しない場合

上記のように設定しない場合、CA から始まるようです。

Viewing all 96 articles
Browse latest View live