技術メモ」カテゴリーアーカイブ

有線LANとWiFiを同時に使って通信速度が速くならないかを調べてみた

実際に構成して確認したわけではないのですが、結論「速くはならない」「リスクが大きい」と考えるのが良いかと思います。
これはその備忘禄。

上流の通信速度の問題

通常家屋の場合、ゲーム用途やメディア視聴など、通信速度を確保する必要のあるPCについては有線LANを用いているとは思います。
そして一般的には、契約しているインターネットサービスプロバイダー(ISP)の通信速度上限よりも、家庭内LANの通信速度の方が遙かに高いです。

そのため有線で接続している以上、理論的にはISPの通信速度上限までの回線速度を利用できることになります。

例えばISPの契約上「1ギガbpsのプラン」を使用し、屋内のLAN機器すべてがギガビットイーサネットを使っていたとしても、実際にはISPの通信速度で1ギガbpsの速度は出ません。
なので、この状態で WiFi など複数の通信接続したとしても、結局ISP側の通信速度がボトルネックとなるので、わざわざ複数接続をする恩恵を受けることはできません。

ネットワークモジュールやOSの問題

次にPC個々の問題。たとえ複数接続したとしても、PCの負荷が上がることになります。
もちろん、それでも問題のないマシンであればいいけれど、両方のネットワークからのデータを同時に処理する事は、普通に負荷は増えます。

ISPを2系統にすればいいんじゃね?

確かに上流を2系統にすれば、理論上、回線容量は増えるので、その分を振り分けることができる可能性はあります。

ただし費用面を含めて考えると、相応のメリットがあるとまで言えないのではないかと考えています。

パケットロスのリスク

あとこれは直接的な理由ではないのですが、複数のネットワークカードを介した同時通信に対応していないシステムやアプリケーション・プログラムもあります。

その場合、有線で接続していたプログラムが、途中でWiFiを利用しはじめた途端、通信ができなくなったり、不安定になる可能性があります。

QuarkXPress 3.31のファイルを何とかするのは難しい

まぁ今になって、およそ20年ぐらい前に作成した QX3.3のファイルを何とかしてくれという話が舞い込んできまして、そんときのお話。

今の QuarkXPress

現在も QuarkXpress はありまして、最新版は QuarkXpress 2024 となってます。ただし以前は、日本語にローカライズされたWebサイトがあったのですが、現在は欧米系の言語のみのサイト提供。

しかしながら、どうやらパッケージそのものは日本語対応しているようで。
しかも一括販売だけでなく、サブスク販売もされているので、一時期メチャクチャ高かった時代では過ぎ去った模様。てか、サブスクで3万円台(パッケージ販売でも10万弱)っていうのは、随分良心的になったのではないかと。

ちなみに公式Webからの販売方法は、今どきのWebダウンロード販売。
パッケージ版も販売・流通しているのかもしれないけど、今の時代、メディアは必要ないかと。
そして通販ページに入ると、そこからは日本語ローカライズでの販売になるので、購入そのものに困ることはないかと思う。

ちなみに旧バージョンもある程度ダウンロードはできる模様。見た感じでは、QuarkXPress 7 からダウンロードできるので、レガシーなOSにインストールして利用できるみたい。
ただしMac版は、OSがここ数年の最新版だと、古いバージョンはマルウェア対策?(セキュリティ?)でインストールできないバージョンがかなりある。Windows 版の場合、Windows 11 でも古いのはインストール可能で、自分の端末では、QuarkXPress 7もインストールできた。が、QX3.3のファイルを開くことができたのは、Windows版の QuarkXPress 9 以降であった。。

QX3.3 のファイル最初の状態

そもそも、こちらのファイル自体が、当時の lzh という形式で圧縮されたファイルでした。
というのも、当時の原稿は「QuarkXPress のファイル&画像ファイル&追加フォントファイル」みたいな感じで、1つの原稿データが複数のファイルで管理されていた。(今もそうなのかな?)

これらを、入稿した時点で当時の mac で lzh 圧縮されたみたいで、まずはこれを解凍するところから。

解凍できても前途は多難

次に、Mac であればこのまま使えるのかも知れませんが、QuarkXpress 2024 の場合、別途「Legacy Document Converter」という、Quark社が提供している公式の XTentions(エクステンション=拡張モジュール)が必要で、これが体験版だとインストールできない。

という事で、古い QuarkXpress をインストールしてみたところ、今度は「QuarkXpress はアップデートの必要があります」など、インストールの過程や起動の過程で阻まれてしまい、詰む。

次に Windows で試したところ QuarkXpress 9 のインストールに成功。

当時 Mac で作ったファイルを Windows で開くときの「落とし穴」と言えば?

そう「Macバイナリ」です。これもツールで削り落とす必要があります。
これも当時の Windows 版アプリで Mac-bin(Macバイナリ除去)というソフトを探し出して、実行。

これでようやく、当時のファイルを表示できる段階までに到達。

ちなみに、この時点でファイルの拡張子「.qxd」も追加。
最近の QX は、拡張子が「.qxp」らしいのですが、当時の拡張子にした。

このあとやること

当時 QuarkXpress 9 は旧バージョンからの再現性の高さを謳っていただけあって、懸念の「レイアウト崩れ」は殆どなかった。
でも、所々「□」に「×」の赤文字が表示されている。

あとファイルを開くと、フォントのエラー(当時のよく使われていたモリサワの書体とか)が出ていたり、EPSの画像ファイルのパスエラーが出ていたり(画像も何だか粗い?)といくつか気になる箇所がある。

この辺りは当時の原本を確認して、一つずつ確認していくしかないのかな、と思っている。

InDesign にはできないか?

結論からいうと、簡単にはできない。

まず最新版の InDesign は、QuarkXpress の qxd 形式からのコンバートが可能と謳われているのだが、バージョンが3.3〜4 に限られるうえ、レイアウトがズレたり崩れてしまう。

まぁ、単純なレイアウトでページ数も少なければ、時間をかけて修復できるとは思うが、数十〜数百ページの原稿となると、ちょっと現実的ではない。

対して、QuarkXpress から InDesign の形式に書き出す機能は存在しない。
(それはそうだわな。あえて商売敵のファイル形式に書き出す機能はないでしょう。)

でもって世の中には QXPMarkz(旧 Q2ID)という、形式コンバータを提供するサードパーティツールもあるのだが、こちらは縦組み文章には非対応みたいで、テキストが見事に横組みになって出力されてしまうという感じ。
(InDesignみたいにレイアウトのズレは最小限なので、再現性はかなり良さそうなんだけど…残念。)

あとは、こういった形式を半手動でコンバートしてくれる会社があるみたい。
(とはいえ、Webを調べた限りだと、おそらくビジネス用途なので、値段までは調べませんでした。おそらく人件費ベースの金額になるので、それなりの覚悟が必要なお値段ではないかと思います。。)

pdf 形式も考えたけど

InDesign は pdf 形式も読み込めるですが、画像ファイルを組み込むイメージと同じで、あくまでオブジェクトとして組み込まれるだけであって、別に InDesign で pdf の中身を編集ができるわけではなさそう。

ちなみに pdf は Illustrator で弄ることができるんだけども、これも元々編集されたスフとレイヤーを意識して読み込まれるわではないので、pdfによっては、編集はあまり現実的ではない。

ちなみに QuarkXpress も InDesign も、pdf形式の出力ができる。
そのため、現在におけるオフセット印刷なんかは、この pdf さえ出せれば印刷に支障は殆どない。
(ちゃんとフォントを埋め込んでさえいれば、ほぼ問題ないはず。)

eset_daemon の CPU が 100% で張り付く

長年、ESET Syber Security を使っているのだが、mac 版の唯一の不満として、これが存在する。

ネットでも色々と断片的に対応方法が記載されていたのだが、一旦解決したので、まとめてみた。

Time Machine の影響

外付けなどので Time Machine (バックアップ機能)を利用している場合、それらイメージファイルの大きさや多さ、構造などが影響して固まることがある。

Docker イメージの影響

VIrtual Box をはじめとする、他の VM でも発生する可能性が高そうな話として、これら仮想環境のイメージなどを ESET が検査したタイミングで固まる可能性がありそう。

また、そもそも、これらイメージファイルを検査する事によって、仮想環境そのものの挙動が不安定になったり、クラッシュする可能性もある。

では、どうすべきか

これら対象のディスクやディレクトリ、ファイルに対して「除外」設定するのが最も効果的。

ただしこれは、セキュリティ上のリスク(特に仮想環境イメージを場外設定する場合、イメージを構成するファイルのダウンロード元が信頼あるサイトでない可能性)を考えると、トレード オフの関係となる。

そもそも企業内PCなどの場合、除外設定そのものを禁止していたり、できないように設定されている場合もあると思うので、その点は十分注意されたし。

ちなみに他のウイルス対策ソフトでは、この問題は発生しないものが多い

しかしそれはおそらく、ウイルス対策ソフトそのものが、これらファイルやディレクトリについての検査そのものを除外(もしくは簡略化)しているからではないかと思います。

これらイメージファイル内の検査については、それぞれのウイルス対策ソフトによって、その検査ポリシー(例えば「イメージの中身を検査したいのなら、ゲストOS側にウイルス対策ソフトを別途導入して検査しろ」とか?)なども含めて、色々ありそうなので、何とも言えないところ。

NoCode はタダではうまく行かないなぁ

タダ=無料という話。

最近、仕事とかのコミュニケーションは専ら Slack を使っているのだが、並行してメールも受信している。

このメールの受信と通知を Slack にできないかなぁと、調べたときの備忘録。

Slack 側の前提条件

少なくともプロ版以上の有料プランを設定する必要がある。
チャンネルにメッセージを直接突っ込むなどのAPI連携は、基本有料プランにする必要がある。

メール ⇒ Slack 連携で利用するブリッジサービス

選定したのは、とりあえず以下。

  • Make(旧 Integromat)
  • Zapier

いずれも有名なグローバルサービス会社であったのが選定の理由。
考え方は安直だけど、ビジネスの継続性とか発展性とか、それがまぁまぁ重要な理由でもある。

GMail ⇒ Make ⇒ Slack

最初に試したのがこれ。

Google の API 開放手順がかなり面倒

まぁこれは、Make 内に対処手順が動画やドキュメントが事細かくあるので、頑張って英語と戦って対処すれば何とかできる。

ISO-2202-JP 非対応

これが Make 利用を断念した最大の理由。
一応 Make には、文字コード変換するためのコンバーターがモジュールとして提供されてはいるのだが、ShiftJIS には対応してるものの ISO-2202-JP は非対応。

これを対策するには、別途 Webhook かなんかで ISO-2202-JP ⇒ UTF8 変換するサイトかなんかを作成して、それを通してから Slack に投げ込むしかない。

もしくは、ISO-2202-JP がこの世界から滅んで、全ての文字コードが UTF8 になれば良い。

それはさておき、この Webhoock を実装・設置するのを今すぐはできないので、ここで一時保留。

IMAP ⇒ Make ⇒ Slack

これも技術的には問題ないけど、やはり ISO-2202-JP 文字コードの問題が歓待に解決できないので、保留。
Make を使う以上は、この問題がずっと、つきまとう。

GMail ⇒ Zapier ⇒ Slack

@gmail.com の場合、連携不可能

Google Workspace などを利用し、企業ドメインなどを GMail で受け取っている場合は、モジュールを接続するだけで連携することができる(みたい)

しかしながら、@gmail.com など(「一般消費者アカウント」と言うらしい、これ)を利用していて、これを外部連携やサードパーティアプリなどと連携する場合は、認証には OAuth が必要になる。

GMail(IMAP) ⇒ Zapier ⇒ Slack

GMail を使う場合、おそらくこれが最も現実的な連携方法なのかも知れないが、この場合「安全性の低いアプリ」として当該アカウントの許可設定をする必要があり、それはそれで不安。

IMAP ⇒ Zapier ⇒ Slack

そもそも IMAP で繋ぐのであれば、自分の場合は GMail に拘る必要がないので、別のメールサービスを使って IMAP を使う。

ISO-2202-JP の問題は特に発生しない。特に文字コードの仕掛けは必要なく、普通に ISO-2202-JP のメールも文字化けなく Slack に配信可能。

ところが、フィルタを追加すると有料。

というのも Zapier を無料で利用する場合はシングルステップのみ、しかも月間100タスクまでという制限がある。

指定メアドに着信したメールをすべて Slack に流して良いのであれば、以下のようなシングルステップとなる。

IMAP⇒ Slack

これであれば、月 100 タスクまでであれば問題ない。
(100 タスク ≒ 処理 100 回、まぁメール100通だけという訳ではないが、正直これはこれで心許ない。)

しかしながら「題名」や「送信者」など、特定条件のみのメールだけをフィルタリングしてメッセージを Slack に流す場合、別途「フィルタ」という処理が別途必要になる。つまり以下。

IMAP⇒ フィルタ ⇒ Slack

これだと処理的にはマルチステップと見做されるらしく、そしてマルチステップは Free プランで利用できない。Starter プラン以上の有料プランにする必要がある。(2022 年 11 月現在、およそ $20/mo …)

詰んだ。

そもそもの話

Slack はプロ版以上だと、チャンネルに個別にメアドを取得することができるので、そこに直接放り込まれるような仕掛けにしたほうがいいのかも。

とはいえ機械的なメアドをそのまま送信者に案内するのも何なので、判りやすいメアドを別途取得して、以下のような感じにするのが良いかと思ってる。

メアド1
(判りやすいメアド)

(転送)

メアド2
(Slack チャンネルと連携している機械的なメアド)

Slackチャンネル

多分コレが一番手間も余計なカネもかからない気がする。

BkBsfilWrapper

Becky! でスパムフィルタを実現するためのプラグイン。
公開されてからかなり経過してるのと、フィルタのコアとなる bsfilter を最新(とはいえ、こちらもかなり前)のものを使おうとするとインストールの際に Ruby もインストールする必要があるなど、若干クセがあるので、備忘録がてら記事にした次第。

同じ bsfilter ライブラリを利用したプラグインとして、bkbsfilter なるものも以前あったようだが、こちらはサイトが閉鎖された模様。
おそらく現在で bsfilter を利用した Becky! プラグインの唯一なものではないかと。

インストール手順などは上記プラグイン配布元の解説があるので、そちらを参照の事。

上記サイトとは別に bsfilter、さらに bsfilter の最新版を利用する場合は Ruby もインストールする必要あり。

上記サイトから最新版をダウンロードすればよいかと。

Ruby のインストール手順については、別途ググってインストール。
ただしインストールの際は、Ruby 2系を使用すること、最新バージョンの Ruby 3系は不可。

Ruby 2系を使うこと、Ruby 3系だと正しく動作しない

bsfilter 自体が 2系時代(しかも初期)に作成されたもの。
そして Ruby は2系 ⇒ 3系になった際にサポートされなくなった機能(仕様? 文法?)があるようで、それらが影響しているのかはわからないが、bsfilter スクリプトが途中でエラー終了してしまう。

これらは Becky! に bkbsfilter プラグイン導入後して動作させると、受信時の動作が明らかにスローダウンするうえ、フィルターに一切引っかからないなど挙動が起こすので容易に分かる。
もしこの挙動が確認されたら、Ruby のバージョンを疑うこと。

ちなみに Ruby 3系と2系を同一マシンにインストールしても問題なさそう。
BkBsfilWrapper 上で使用する Ruby は、プラグインの設定内でプログラムパスを直接指定する設定する。そのため環境変数 Path の影響を受けないように実装されている。

もし開発環境としてRuby 3系を利用している場合は、別ディレクトリに Ruby 2系をインストールすれば同居可能。
(同居については、この記事の主体ではないので省略。2系⇔3系の切替方法や Path の変更方法など色々調べたうえで、自己責任で。)

Ruby 2系のバージョン

執筆時点での Ruby 2系のバージョンは最新版の 2.7.5 を利用しているが、今のところ動作に問題はなさそう。

Spigot 1.17.1 ⇒ 1.18 アプデしてみた

Minecraft Java版も 1.18 になり、Spigot も 1.18 が公開されたので、うちの貧弱環境で動作するのかも含めて、早速アップデートしてみた。

ちなみにシングルで遊ぶのであれば、自分のPC上で「シングルプレイ」で普通に遊ぶのが、あくまで一般的なはず。
最近のゲーミングPCであれば、スペックとかも問題ないはず。

この記事は、Spigot サーバをわざわざ建てて、マルチ環境でシングルプレイするという奇特な人(私)を前提とした内容。
なので、その辺の無粋なツッコミは、なしの方向で。

もうメモリ1Gではムリです。

今まで「さくらのVPS 1Gプラン」で稼働させてましたが、1.18 へのビルド・アップグレードについては、なんとか可能。
しかしながらゲーム中の動作中、以下のような事象が発生していた。

  • 移動やブロック破壊中などの動作が、固まる。そして数秒前の状態に戻る。
  • チェストやインベントリを開くことができない。
  • 新規エリア(チャンク)移動の際、トロッコやボートなどの速い速度で移動すると固まったり、ゲームが強制切断される。
  • 普通に移動したり、ブロックを破壊していてもゲームが強制切断されることがある。
  • 強制切断後、再接続できない。

このような状態になっていると、往々にして Spigot サーバーのコンソールに、以下の過負荷警告が繰り返し表示されることがある。

> Can't keep up! Is the server overloaded? Running XXXXXms or YYY ticks behind

【意訳】
もうついていけねぇ! サーバーが過負荷じゃね? XXXXX ミリ秒または YYY ティック遅れてる。
(ティック:ゲームの処理単位、マイクラだと1/20秒単位)

つまり現実時間軸に対して、ゲーム内の処理量が多すぎて時間が追いつけていないという状態。
これが積み重なるとゲームは処理落ちを跳ばして無理矢理、時簡短縮をしたり(プレイヤーは見かけ上、コマ落ちやキャラがワープしたように、移動や操作前の状態に巻き戻されたように見える)、ゲームが強制終了してしまう。

ちなみにこの事象、1.18 ほどではないにしろ 1.17.1 でも発生していた。
それでも 1.17.1 の場合、個人的にはシングルプレイで利用するかぎり、まだ耐えられる程度だったが、1.18 では頻発するため、さすがにストレスがキビしい。

いずれにせよ、この現象はメモリ不足や処理の過負荷が原因。
1.18 にはアップグレード(ビルド・インストール)できるものの、プレイは現実的ではない
という結論。

対策、カネで解決するしかない。

そのため、急遽 VPS のプランを 1G ⇒ 2G に変更。
その結果、頻発していた負荷警告は(発生はするものの、1.17.1 の時よりも少ない状態に)収まった。

この状況から、今後のマイクラ JAVA 版は、普通にゲームするだけでも、少なくとも2G以上のプランが必須となってきそう。

ちなみに Spigot の動作スペックを少し調べてみたが、どうやら最近は 2GB 以上のメモリを最小としている模様。
もしかしたらメモリ 1G での挙動させる猛者はいるのかも知れないが、普通に Spigot をセットアップしてあくまで標準的に利用する場合、メモリ 1G での動作は無理だと思う。

あと以前の記事にも記載した通り、自分が利用しているサーバは契約自体が年間契約のものを流用した関係と、AWSなどを再契約した場合、またイチからサーバを構築しなくてはならない。
そのため今回は緊急避難的にスケールアップで対応し、契約満了までは利用することにした。

しかしながら 1G⇒2G へのプラン変更は、概ねどこの VPS サービスもそうなのだが、利用料金がほぼ倍になってしまう。正直なところ、お値打ち感はない。

なので個人的には契約満了後、AWS(EC2)に切り替え、かつ弾力的にインスタンスの開始/終了ができるようなシステムを構築する方向で、費用圧縮を考えている。

1.17.1 ⇒ 1.18

そして本題です。

まずビルド・実行にあたり、Minecraft 1.18 は java 17 のバージョンが必須となる。
そのため、まずは java のバージョンを 16 ⇒ 17にアップグレードする必要がある。

でも、何はともあれ、まずはバックアップから。

# sudo su
# cd /opt
# cp -a spigot spigot.1.17.1
# exit

自分の場合、spigotを導入している /out/spigot ディレクトリ配下を、権限そのままで、ごっそりコピー。

ちなみに apt コマンド等は Ubuntu 20.x.x の場合。
CentOS や Windows など、各自のOS環境や権限、ディレクトリ構成などによって、手順やコマンドや手順は異なる。
そのあたり、各自で適宜調べて実施する必要あり。

次にパッケージインデックスを更新。

$ sudo apt update

ついでに、他のアップグレードがある場合、必要に応じて更新。

$ sudo apt upgrade

自分の場合、最も環境変化の影響の少ないアップグレードをしている。(余計な機能は追加しない。)

本題に戻り、OpenJDK 17 をインストール。

$ sudo apt install java-17-openjdk

最後に Java 17 になったか、バージョン確認。

$ java -version

これでjava 17.x.x がバージョン表示されればOK。

次に ビルドツールを最新化。

$ cd spigot
$ rm BuildTools.jar
$ wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar

このビルドツール、頻繁に更新されていて、古い BuildTools.jar だと最新版のビルドができない場合が多い。
なので BuildTools.jar は、常に最新版を使う。

必ず Spigot 公式が提供している jar ファイルをダウンロードして使用すること。
BuildTools.jar をググったりして探すと、野良サーバの jar ファイルがヒットすることがある。これがセキュリティ上とても危険。
必ず公式サイトからダウンロードしているか、URLを確認すること。

そしてビルド。

$ java -jar BuildTools.jar --rev 1.18

これによって、Spigot 1.18(Spigot-1.18.jar)がビルドされる。

次に、既存のワールドデータや設定ファイルなどを、1.17.1 ⇒ 1.18 にアップグレードしつつ、spigot サーバを一旦起動。

$ java -jar spigot-1.18.jar --nogui --forceUpgrade

このタイミングで、現時点でのワールドデータやプレイヤーのデータがすべて書き換わる。

ちなみにこのアップグレード作業、ワールドの広さによって、かなり時間がかかる。
もしかしたら半日以上とか、かかるかも。
自分の場合、まだ数百座標単位しか展開していない。
しかしそれでも 15 分ぐらいかかった。

だからといって、上記コマンドを入力したら、絶対に途中で止めず、辛抱強く待つこと。
途中で止めると、ワールドデータが破損する可能性があり、その場合、二度と起動できなくなる可能性すらある。

バージョンによっては、上記アップグレードコマンドにて操作終了後、何もしていないのにメモリ不足などの例外エラーで終了したり、コマンドの入力挙動がモッサりして不安定になることがある。
自分の環境では、1.18.1 アップグレードの際に発生した。
ただ今のところアップグレード時のみ生じている問題で、OSごと再起動し Spigot を通常起動させた状態では安定。
少しゲームプレイしたかぎり、問題も起きていない。むしろ動作が軽くなった気がする。現状様子見。

無事に起動が確認できたら、一旦停止。

> stop

Spigot を終了させる。
そして最後に –forceUpgrade オプションなしの状態で Spigot を再起動。
これで問題なく起動し、ゲームにログインインして普通に操作できれば、アップグレードは無事終了。

以上アップグレードの作業そのものは、特段難しくはない。
しかしながらアップグレード前に、記事冒頭の記載通り、サーバースペックの問題を確認・解決する必要がある。

マイクラサーバ、立ち上げの試み

この記事は、今後更新される可能性があります。

サーバのインストール手順については、ググると先達の Web 記事がいくつかヒットするので、ここでは解説していない。
あくまでプラン選択の経緯を記事にしてみた。

また、利用したマイクラサーバは Vanilla(バニラ)ではなく、今後の利用を考えて、Spigot を選択。

さくらのVPC 512MB プラン

以前は512MBなど、低スペックなVPCサーバでも利用できたようなので、元々所有していたサーバ契約を流用して、インストールを試みてみた。

ビルドは何とか成功、でも起動しない。

コンパイル時にもメモリ不足のエラーが表示されたが、無理矢理ビルドすることは可能。
しかしながら、サーバ実行(起動)の過程でメモリ不足となり、立ち上がらなかった。

さくらのVPC 1Gプラン(今ここ)

こちらのプランだと、サーバも起動できる。
ところがプレイ中、ボートやトロッコなどで高速移動すると、処理落ち(移動が巻き戻ったり、切断、例外発生によるサーバーエラー終了など)が頻発。

原因がメモリ制御なのか、処理速度(CPU)の問題なのかは不明だが、いずれにせよ、メモリ1Gであっても、新規ワールド(空間)への立ち入りや複数人でサーバに接続すると、かなり不安定になるのではと思う。

現状、拠点でブランチマイニングや、精々近所の村や洞窟探索を中心にプレイしてるので、何とか動作している。
しかしながら飽き足らなくなれば遠征することになると思う。
おそらくそれは、時間の問題かと。

結論

メモリは最低でも1G以上必要、ただし限界は近い

おそらくクラウドサービスを利用してマイクラサーバを立ち上げる場合、CPU やハードディスク容量については、一定以上のプランを利用すれば、ほぼクリアできることが判明した。

しかしながら Java を利用しているため、初期のモジュールビルドにも、マイクラサーバの実行にも、とにかくメモリを喰う。

おそらく2G以上のサービスを利用するのが安泰だと思うが、そうすると今度は、費用面が問題になると思う。
例えば、さくらインターネットの場合だと、プランを1G⇒2Gにすると、基本料金がほぼ倍になる。
ざっくりだが、年額でおよそ1万⇒2万の差。
いくつか他の VPC 事業者もみたが、ほぼ同じ傾向。

個人的にはAWS(EC2)に移行しようと思ってる

ちなみに仕事用を中心に、オンプレサーバをクラウドに移行したので、玉突きで空いたオンプレサーバをマイクラサーバにしようかとも思った。

しかしながら、オンプレサーバのディスクをSSDに換装したり、電気代などの維持費を考えると、先のクラウド移行した理由が破綻してしまう。
なので今のところは、AWS(EC2)などのインスタンスの自由度が高いクラウドにマイクラサーバを移行することを検討中。

ただし、正直なところ AWS のようなクラウドサービスは、一般的な VPC サービスに比べて、設定や操作が煩雑なのと、費用面のコストが見えにくいので、かなり躊躇している。

しかしながらインスタンス(CPU やメモリのスペック)切替が容易なところは正直魅力的だし、バッチを頑張って作れば、未使用時にはサービス停止して、費用節約も不可能ではない。

でもまぁ、さくらインターネットのVPC契約を1年契約にしてしまったため、とりあえず、解約時期までにEC2環境を整備しておこうかと考えているところ。

Zoom 利用時のビギナーメモ

これは自分が Zoom ミーティングを主催した時の案内に利用したテキスト。
ミーティング主催した当時の資料のため、現在の Zoom 仕様では内容が異なる場合があるので、ご注意。

あとテキストが「です・ます」調なのも、元々が案内テキストだから。
いちいち修正するのは面倒なので、このままで。

ちなみに「ミーティング」=「会議・打合せ」って事で。

ミーティング主催者設定によって、サインイン(会員登録)しなくても閲覧可能

ホスト(会議主催者)の設定により、指定URLから(またはミーティングID・パスコードを用いて)直接入室することができます。

注意事項

主催者がミーティング開始するまでは、ミーティングルームへは接続できない場合があります。
その場合は、少し待ってから再接続してください。
それでも入れない場合は、主催者に問い合わせてください。

社内ミーティングなどの場合(主催者向け)

赤の他人の参加を防ぐなど、セキュリティの観点から Zoom にサインインしている人に限定する、待機室を設定する(主催者側で入室可否を判断する)などを設定するのが無難です。
もしくは同じ観点から、自分⇒全員へのカメラ許可もしたほうが良いと思います。

この辺どれを選択するかは、ミーティングの内容によって異なると思うので、主催者・参加者等にて適宜検討が必要かと。

初めてスマホで接続される方へ

スマホの場合は、アプリで接続するのが原則となります。

Chrome, FireFox など一部のリッチブラウザであれば、主催者側の設定によっては接続可能ですが、現在は Zoom 側の接続時判定により、スマホの場合はアプリの選択(インストール)を強制される模様。

でも PC版も含めて、アプリを入れたほうが「機能制限がない」などのメリットが大きい。そのため、主催者のサポートも含めて、Zoom 参加者はアプリインストールして利用するのが無難。

Zoom の利用が初めての方は、主催者の指定した URL をクリックすると、ブラウザが開いてアプリのインストールを促されると思います。
そのまま指示に従って Android の場合は Google Play ストア、iPhone/iPad(iOS) の方は App Store から「Zoom」アプリをインストールしてください。

そのあとで指定したURLに、改めて接続してください。

お名前について

サインインせずにミーティングに参加する場合

ミーティングに接続する過程で、自分の「名前を入力してください」と表示される場合があります。
ミーティンの内容によっては、相手(会議参加者)から誰が参加しているかを名前で判断する場合があります。
主催者の指示に従って入力をしてください。

必要に応じて、主催者は名前の入力等について検討・指示する必要があり。

サインインしてミーティングに参加する場合

プロフィールで設定された名前が表示されます。
こちらの名前変更は、プロフィールを変更しないと反映されません。

この辺について、シビアな方は、Zoom利用前にや利用後に「サインアウト」しているかを常に確認する必要があります。

カメラを利用しない場合の、固定画像について。

Zoom 会員登録した場合のプロフィール画像が採用されます。
アプリやミーティング上の設定で固定画像を指定することは、できません。

よって固定画像を表示したい場合、会員登録(サインイン)が必須になります。

ちなみにミーティングルームに参加した場合、ミーティング参加者には以下の文字列が表示されます。

  • サインイン(会員登録)した場合
    ⇒ プロフィールの「表示名」(未設定の場合は「名,姓」)
  • サインインしない場合
    ⇒ ミーティング参加時に設定した「名前」

通信量(通信料)について

携帯回線など従量制課金の通信を利用されている場合

通信料が肥大化するおそれがあります。

ミーティングは長時間の接続が予想されるため、従量制課金を中心としたプランの通信を利用されている方は、通信料金について注意が必要です。
できれば、自宅回線(Wi-Fi)からの接続を推奨します。

とはいえ画質はそこまで良くはないので、YouTube など動画視聴ほどの容量にはなりません。。

参考値ですが、Zoom ミーティングの場合、高速回線で概ね以下の通り。

  • フルスペックミーティング(双方向・音声ビデオあり)
    ⇒ 1時間あたり 0.5 ギガバイト強
  • テレカン(双方向・音声のみ)
    ⇒ 1時間あたり 0.1ギガバイト程度

これはあくまで企業ベース・映像もHD画質であるなど、かなりの高スペックな状態の双方向ミーティングにおける測定値。
よって「上限」と考えれば良いかと。

スマホやフリー Wi-Fi など、低速回線や品質の定まらない回線を利用した場合、回線速度に応じて大幅に軽減されるそうです。
ただし通信品質に応じて、コマ落ちがノイズもかなり増えます。

通信量軽減のヒント

自分⇒相手への音声や画像が不要な場合、音声ミュートやビデオ(カメラ)オフにすることで、通信量を減らすことができます。
また自分⇒相手への通信を減らすことにより、アプリ等の処理不可も下がるので、相手⇒自分の受信品質が向上する可能性もあります。
スマホやノートPCの場合、電池消費量も軽減されると思います。

注意事項

「オーディオ」(スピーカー音)と「カメラ」の設定

アプリを利用する際、接続(入室)の過程では、オーディオ「オフ」にはしないでください。
相手⇒自分への音声が聞こえなくなる場合があります。

「カメラ」については、自分⇒相手への利用予定がなければ、接続時「オフ」で構いません。

ちなみにマイク・カメラの「オン・オフ」は、ミーティング参加後の画面で操作可能。
そのためミーティング参加の過程でオーディオやカメラの設定を変更する必要はありません。

絶対に自分⇒相手に「カメラ」表示したくない参加者のみ、接続の過程で「カメラ」をオフにしてください。

さくらの VPS のパケットフィルタリングを使った SSH ポート開放

以前は iptables にてフィルタリングしていたが、「さくらの VPS」コンソールにある「パケットフィルタリング機能」が拡張され、任意 IP アドレスのフィルタリング設定が可能となったため、SSH ポート開放の制御をそちらに寄せることにした。

手順

自分が接続しているマシンのネットワークIP(グローバルIP、ゲートウェイIP)を探す

AAA.BBB.CCC.DDD

さくらのVPSに接続

パケットフィルタの設定を追加(変更)

設定項目は以下。

  • フィルタの用途「カスタム」
  • プロトコル「TCP」
  • ポート番号「22」
  • 許可する送信元IPアドレス「AAA.BBB.CCC.DDD/32」
    (サブネット「/32」は、上記1つのIPアドレスのみ許可の意。「/32」とかアドレス範囲とか知りたい人は GGR)

この状態で Teraterm, WinSCP などから接続確認

問題なければ、これで終了。
かなり簡単になった。

メリット

  • GUI (Web) 上での設定なので、操作自体が簡単。

デメリット

  • GUI (Web) 上での設定が必須なので、手動作業。一連作業の自動化ができない。
  • パケットフィルタリングの機能自体による制約が生じる。
  • ログを残すような設定など iptables で可能なことができない。
  • カスタムフィルタリングは最大で10個までしか設定できない。
  • 個々のフィルタリングに対してコメントが残せないため、可読性が下がる。
    (間違えて別のパケットフィルタリングを上書きしてしまう恐れなど、ケアレスを誘発する恐れあり。
    まぁ iptables の場合は煩雑で失敗した場合のインパクトは同じような気がする。
    どっちもどっち。)

これらデメリットから、特にログが残せないなどの点については、企業によっては監査が通らない気がする。
その場合はこの設定簡略化そのものが採用できない。

注意

「パケットフィルタを利用しない」とか「SSHを『すべて許可する』」には、くれぐれも選択しないこと。
iptables で適切にフィルタリングをしているなら話は別だが、サーバが丸見えになってしまい、セキュリティ上のリスクが爆増する。

特にビギナーや素人

繋がらないからと言って、この辺りの操作をすると、「あっ」と言う間に何処かの大陸方面からサーバ乗っ取られて、踏み台にされて、さくらインターネットから「サーバー強制停止 ⇒ コンソール(コマンドライン)で対処するか、サーバ初期化するまでパケット全閉塞(実質利用できない)」を喰らうことになる。

少なくとも、SSH からの root 認証不可は絶対だし、鍵認証必須(パスワード認証不可)は強推奨。

【参考】

Web については、.htaccess にてドメインフィルタリングしている。
そのためパケットフィルタは、敢えて「すべて許可する」にしている。

Apache 再起動時に他のプロセスのポートと被ってエラーが出た場合

この記事では、根本原因については、調査すらしていない。
ただ単に Apache を再起動することだけに言及している。

システム構成上や設定などで、何らかの不具合が存在する場合においても、この現象が発生することがあると思う。
その場合は、原因を探ることが肝要。

はじめに

# service httpd restart

としたとき、正常に STOPPED するのに、START に失敗するという事象が発生することがある。

# netstat -lnp | grep :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1531/httpd
#

とか言って、正しくプロセスが終了していないことが確認できる。
(通常は2行目の応答なんか出ずに、すぐに次のプロンプトが返ってくる。)

Apache は、動作の過程で複数のプロセス(子プロセス)を作成するのだが、service から httpd を停止しても、これらの正しく終了しない事がある。

原因はおそらく以下のような部分が影響しているような気がしているが、正直、真相は不明、闇の中。

  • Apache を動作させている状態で、Apache に影響する何らかの設定やプログラムなどを変更した事によって、正しくプロセスが停止しなくなった。
    (Apache 停止せずに SSL を更新した、とか)
  • 別の Apache と連携しているプログラムが稼働中のため、停止できなかった。
    (Passenger が稼働中、とか)
  • そもそも Apache のプロセス起動の過程が変、とか。

対処

以下を参考にして対処した。

プロセスを強制終了する

普通に強制終了。

# kill -9 1531
#

この状態で再度確認。

# netstat -lnp | grep :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1543/httpd
#

まだあがってくるようであれば、全部、強制終了する。
(ひたすら繰り返し)

# kill -9 1543
#

ポートを利用しているプロセスが上がってこなくなったら、すべての Apache プロセスが終了したことになる。

再度 Apache 再起動

# service httpd start

STARTED [O K] なら、正常に起動。
ブラウザから動作確認して、問題無ければ終了。

【余談】

バッチにしたので、今はコマンド1発で Apache 再起動してる。