マイクラ 1.18 の話

この記事は、今後随時追加・変更・訂正・削除する可能性あり。
また流動的な内容を取り扱っているため、間違った内容となる可能性もあり。
さらに掲載後の時間経過によって、最新版を対象とした記事でなくなる。
これらに十分注意し、記事を参照すること。

Java版(JE版、Java Edition)の記事。
統合版は若干仕様が異なる場合があるので、注意。

  • Y(上下)座標が拡大された。
  • バイオームの新設や整理が為された。

この辺の話は、調べればよく聴く話だと思うので割愛。

敵 Mob の明るさに関するスポーン条件が変更になった

今までは明るさレベルが7以下がスポーン条件だったが、これが0でないかぎり、つまり光源ブロックからの明かりが少しでも当たっていれば、敵 Mob はスポーンしなくなった。

そのため、今まで湧き潰しが甘い箇所箇所が近くにあったりすると、クリーパーが湧いたりして、いきなり背後で爆発に巻き込まれるとかあったが、このような事態は、かなり減った。

むしろ地上拠点など、湧き潰しされてる空間上での不意な「湧き」がかなり少なくなってしまったので、当初は「アップグレードのバグか?」と思ったぐらい。

鉱石分布の変更

すでにブランチマイニングされているエリア(チャンク)は、掘ってなくてもワールド(ブロックの情報)が生成済のため、それが書き換わることはない。
しかしながら、今回追加した Y=0 より下の層や未踏のエリアについては、プレーヤーの移動によって追加生成されるのだが、その際注意しなくてはならないのは、鉱石分布の変更。

特にダイヤモンド鉱石の場合、今までは Y=1~15 に分布していたが、1.18 では Y=16 以下、しかも深くなるにつれ、出やすくなるように変更された。
(ただし溶岩溜まりなどの Y 座標は 1.17.1 と同じなので、深層を掘る際のマグマダイブは従来通り注意が必要だし、横掘りや上掘り時の注意も必要)
それ以外の鉱石についても、一定数の生成頻度とは別に、出やすい高度の傾斜が追加された。
そのためブランチマイニングなどの効率重視の場合、目的の鉱物別に高度を変更する必要があるなど、適宜方針変更する必要が出るくると思う。

以下、気になったら記事追加する予定。

【スポンサー広告】

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 分ぐらいかかった。

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

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

> 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環境を整備しておこうかと考えているところ。

【スポンサー広告】

マイクラおじさん、はじめました。

最近この歳になって、VTuber にハマってしまい。
その影響で、今さら Minecraft にハマってしまい。

…この流れで察することができる人は、そこそこいるのではないかと。

という事で、今回は環境の話。

現在のマイクラには、C++でコーディングされた「統合版」(Bedrock Edition, 通称 BE)と「Java版」(Java Edition, 通称 JE)の2種類がある。
歴史的には「Java版」がルーツだが、ゲーム機やタブレット端末では「統合版」のみ利用可能、対して PC では「統合版」「Java版」の両方が利用できる。

なぜ「統合版」のみがスマホやゲーム機に対応したのか考えてみたが、おそらく Java Runtime Environment(JRE)がボトルネックになっているものと思われる。

Java とマイクラ(というかゲーム)は愛称が良くなかった

そもそも Java は、Oracle の方針など諸々の経緯から、現在「事実上」PC 向けのプログラミング言語になりつつあり、スマホなどのモバイル機器やゲーム機などの環境、特にゲーム分野においては距離を置かれつつある。

その理由として、 JRE(いうか Java)は、スマホやゲーム機の場合、原則としてハードウェア側に Java (JRE)が「別途」インストールされていることが前提となる。
この「別途」というのが曲者。
たとえば Java のバージョンアップに対応する必要が常に生じるわけで、デバイスによってはそれが難しい場合がある。
しかも Java は(表現の適切かは、さておき)「半分コンパイルしたプログラムを半分インタープリターで動かす」つまり「ランタイムプログラム」というアーキテクチャー上、動作時のメモリと CPU の負担が大きい。

Java 版のゲームプログラム側でこれらの差異を補完することは、できなくはないとは思う。
しかし当然ながらアプリ本体が巨大化するだろうし、レガシーな機種を意識する必要が生じてしまうため、ゲームの発展を考えると、それが「足枷」にもなってしまう。

オフィスなどの業務システムについては、今まで C/C++ 言語などでの生じていた開発コストが、Java の登場と発展によって削減されたり、オブジェクト指向の概念の加速化など、プログラミングの世界において貢献した点は色々とある。
ただゲームなどの機種(スペック)差や、挙動がシビアなソフトの開発には向かなかったという事だと思う。

JRE は際限なくメモリを喰う

メモリ制御が重い

Java においてもメモリ制御は、プログラミング次第で柔軟にできる。しかしながら、この処理が正直、重い。

これはマイクラのプログラミング上の問題でもあるのだが、たとえばマイクラは、一般的な RPG などとは異なりワールドの生成が、キャラクターの移動に応じて、動的に生成される。
このワールド情報、一度生成されてしまえばデータが保存されるので、それ以降はデータの読み込みのみになり、負担は下がるのだが、それでもメモリを大量に消費したり、解放する場面がある。

こういった場面は他のゲームでもあるとは思うが、前述の通り Java はランタイムプログラム経由という構造上、その処理がどうしても遅くなってしまう。

メモリを喰う

ただでさえ JRE の動作だけでもメモリを喰うのに、マイクラ本体を稼働させるのに、さらにメモリを喰う。

これをスマホやゲーム機など、性能差のあるデバイスで採用するのは、おそらく現実的ではなかったのだと思う。

そのため「統合版」は、C++ で作成され、かつ、各デバイス毎に対応したことにより、ラグなどを生じない形でのゲームを展開することができた。
おそらく、この選択肢がより現実的だったのだと思う。

ただし Java 版にもメリットがある

それは Java にすることによって、「有志」が独自の機能を追加することが容易になった点にある。

これは自前のサーバを立てることも可能にし、自前のサーバー上でワールドを構成、しかもマルチプレイをすることが可能にした。
しかも、それぞれ別々のワールドを、ポータル(穴)を経由して接続することも可能。
それ以外にも様々なプラグインなどが展開され、独自の拡張・発展を続けている。

ちなみに「統合版」も Microsoft が独自に提供している Minecraft サーバサービス等を利用しており、それを利用すれば、マルチプレイが簡単にできる。(ただし有料サービス)

さらに「統合版」の場合、様々なイベントや追加 Mod が提供されており、いわゆる大衆的なゲーム要素を公式が提供するという、本来のゲームサービスの姿となっている。

Java 版の未来

正直なところ、個人的には悲観的に考えている。

現在 Minecraft は Microsoft が買収し、サービスを提供している。
そして開発形態も、以前は「Java 版」でアップデートされた機能を、各デバイスなどのプラットフォーム版(「統合版」になる前の姿)に移植される形だったが、現在は「統合版」で実装された機能を「Java 版」に移植するという「逆の流れ」になってしまった。

これはおそらく、開発コストなどを踏まえた結果だと思うが。Java 版の開発が後発になった事に、正直不安を感じている。

「統合版」で実装された機能が「Java 版」で実現できなくなる未来

現時点でも「統合版」と「Java 版」の間では、細かな機能や挙動が異なる部分が既に生じている。
そもそも Java は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

「『統合版』だけあればいいんじゃね?」という流れに向かうのはとても自然な気がするのだが、この考えは杞憂なのだろうか。。。

【スポンサー広告】

三重、弾丸帰省。再

実家のオヤジが退院したのだが、頸椎の疾患の影響で、寝たきりではないけど、歩行困難(移動は基本、車イス)など、介護が必要な状態なったので、様子見にレンタカー弾丸帰省することに。

これはその際の記録。

オヤジは元々持病もあるので、この先のことは判らないけど。
まぁ「それはそれ」、別の話という事で。

レンタカーの話

以前は近所にトヨタレンタカーがあったので、複数日利用とか商用車利用の際はそちらを使っていたが、閉店してしまい。

もともと自分が住んでいる場所には、レンタカーやらカーシェアスポットが多いので、競争率は高い。

そんな中、トヨタレンタカーはメーカー系ということで、車両を準備する能力は高いのだから、本来であれば、ディーラーを利用するなどして駐車場確保さえできれば、最強のレンタカー業者になれるはず。

でもどのメーカー系レンタカーがそれをやらないのは、おそらく「レンタカーの普及=新車が売れない」というジレンマを抱えているからだと思う。

そのため今回は、ニッポンレンタカーをはじめて使ってみた。
まぁ老舗チェーンなので、トヨタレンタカーとサービス自体は遜色ないのだが、予想通りというか、カーナビが使いにくかった。

カーナビ

ニッポンレンタカーは基本、ECLIPSE(デンソーテン)のカスタマイズ品(機能制限版)を採用しているのだが、カーシェアを使っていると carrozzeria (Pioneer) が搭載されていることが多い。

そのため純正も含め、他社製品のカーナビは、どうしてもUIの使用感が異なるため、まずこれが使い難く感じてしまう。

しかもニッポンレンタカーの場合、機能制限が結構キビしいのか、ナビそのものの仕様なのかは分からないが、色々と細かな調整ができない。
たとえば、オート・サウンド・レベライザー(車速・走行音に応じて音量を調整する機能)などが調整できなかったり、(こちらもナビの所為なのかは不明だが)ラジオが聞き取りづらくなる場面が多かった。

特にラジオの性能については、carrozzeria ではそう感じる事が少なかっただけに、残念な気がした。

でも最近は、ラジオ聞かない人も多いのか?
だからメーカー自体も性能追求が適当になってるのかも?

利用した車種

シエンタ、7人乗りのタイプ。
シエンタはフルフラットシートにできないものの、コの字型に畳んで、床面や荷室部分を荷物やクッション等で埋め、厚めのマットを入れれば、座面は斜めにはなるものの、就寝可能。個人的にはコレでかなりイケる。

でも最近は5人乗りタイプ FUNBASE もある。
こちらのほうはセカンドシートが凹み収納でき、フルフラットになるうえ、室内高も稼げることもあり、居住性は高い。

ちなみに就寝定員は、5ナンバー車の場合は大人2名が限界。個人的には1名で贅沢快適に使うのがベスト。

仮眠であれば、座席定員のままでもイケるかもだけど、そこそこ快適な就寝を目的とする場合、既成車両での就寝はかなり限界がある。

大人2名+未就学児1名ならアルファードなどの3ナンバー車、それ以上の車中泊の場合はキャンピングカーをレンタルしたほうが良いと思う。

またシエンタは、レンタカーとして大量に導入された時期のモデルの場合、クルーズコントロールが標準装備されていない。そのため運転は普通に必要。(最新モデルは知らん)

ガソリンとか燃費とか回転数とか

普通車の場合、関東⇒東海圏超えたあたりで給油が必要なのだが、シエンタも概ねそれに沿ったレベル。片道で1度給油が必要。

ちなみにカタログ燃費で20km/L前後のところ、高速道の巡航走行で15km/L前後だったので、これもほぼ想定内の結果。

高速道のエンジン回転数は、新東名の 120km/h 巡航走行 で 2000rpm 強で安定する。

帰りは中央道経由で戻ってきたのだけど、坂道などでも、それほど気後れするような挙動はなかったと思う。
とはいえ3ナンバー車や走り重視の車ではなので、それらに比べれば加速は劣るけど、別に困るほどでもない。
「速い車は、とっとと抜いていけ」というスタンスで車線を譲るメンタルで運転すれば問題ない。

ちなみに今回は自分1人だけの移動で家族乗車がなかった。
そのぶん荷重も少なかったから、運転も快適だった可能性もあるのかも?

準備まわり

セットアップに時間がかかる

仮眠前提の装備で出発するときは、いつもそう。永遠の課題。
夜間の仮眠のため、寝具やシェードなどはアウトドア並みの機材を持ち出した。
そのためセットアップにどうしても手間がかかってしまい、出発が遅れてしまった。

この辺り、前準備をもう少しできないか試行錯誤してるのだけど、なかなか難しい。

忘れた物

虫刺され薬

車には必須。虫除けスプレーしてても、蚊には刺されます。対策してても刺されるときは刺される。
なので、小さくても1つないと困ります。

あったほうが便利なもの

虫除け機器

「どこでもベープ未来」とか「カトリス」とか。
人体用の虫除けスプレーは持ってたけど、衣類や肌がベタ付くので、それとは別に虫除け機器もあったほうが良い

ちなみに屋外(キャンプなどの完全アウトドア)であれば蚊取り線香もいい。
でも今回は車内で使うので、非加熱・非ボンベ式のものが良いかと。

スペースクッション

寝台にする際、座面以外の部分にクッションなどの「詰め物」がないと、マットレスが沈んでしまい、具合が悪い。
荷物などがあればそれを詰めれば良いけど、そうでない場合は、空気で膨らませることができるクッションなどあったほうが良いかも。

充電式空気入れ

マキタ MP100DSH が気になっている。(やり過ぎ)
クッションを膨らませる際に便利。

フロントカーテンを抑えるための小道具

仮眠用にカーテンを所持しているのだが、フロントガラス用カーテンは傾斜に合わせて、斜めに抑える道具が必要と感じた。

まぁ小物類の収納をうまくやって、就寝時はそれらをダッシュボード上に設置できれば良いとおもうので、その方向で検討してみようかと。

持っていかなくても良かったもの

パソコンまわりの小物

事前にバタバタしたため、厳選できなかった。
コード類やUSBメモリ、マウス、モバイル機器など、もっとスマートにしたい。

次持って行くもの

ビデオカメラ用の架台

ダッシュボード上固定用。
以前購入したものが、使用開始5分で雲台下の部分がへし折れた。
そのため急遽架台を撤去し、カメラをダッシュボード上に直置き。でもそのままだと車の動きでカメラが暴れてしまうので、滑り防止に小物を置いてみたが、結局暴れてしまい、複数回映像が傾いてしまった。

次回購入の際は、ビデオカメラは重いので、ちゃんとした土台を購入したほうが良さそう。

余談

新東名の3車線化、全線120kmは強力

3車線化が整備された効果は、やはり大きかった。

今回は深夜帯の走行に終始したので日中の状態は分からないが、深夜帯はトラックが多く、乗用車はかなり少ない。
そのため以下の「暗黙のルール」が確立されている状態になっていると感じた。

  • トラックは第1第2走行車線をほぼ占拠。
  • 120km 走行が容易な乗用車は、ほぼ追越車線走行。
  • 後方から高速車が来たら、追いつかれる前に第2走行車線に退避する。
    速い車とは張り合わない。とっとと退避して、先へ行かせる。「事故ろうが捕まろうが自業自得、知らん」のスタンスが大事。

ただし新東名は長距離区間ということもあり、また開通後の微調整なのか、工事している場所も多い。
そのため2車線、場合によっては1車線になる事もあるので、交通情報や前方には常に注意する必要がある。

それに夜間でも交通量がそれなりに多い。
中には「何をしたいのかよく分からない」運転をする車両は何処にでもいるので、その辺は注意が必要。

今回仮眠した場所

新名神、鈴鹿PA(下り)

深夜到着・夜明け前出発なら大丈夫かも知れないが、普通車の仮眠は、正直お勧めできない。
理由としては、盛り土をした高台に設置されたPAだから。
朝日をモロに浴びるし、それを樹木がほぼ一切ない。
そのためエンジン停めたままでは、とてもじゃないが、室温が急上昇し寝ていられないくなる。

仮眠するなら、湾岸長島PAがオススメ。
こちらは駐車場周辺に樹木が植生されてるし、高台ではないので。

中央道、小黒川PA(上り)

山間部かつ大型車が駐車できない「離れ」の駐車帯があるので、個人的には、かなりお気に入りの仮眠場所。

最近SICが設置され、その影響で「離れ」の駐車帯が減ったうえ、SIC利用者が意外に多いので、以前にくらべれば静粛性は減った。
ただそれでも、まだ個人的には便利に使わせて貰ってる。

ただし夜間は売店等が閉まるので、自販機(飲み物)以外の食料調達が困難になるのが難点。
あとハイシーズンや週末は、おそらく利用者が増える。そのため「離れ」に駐車できない場合もある。

ちなみにこのような「離れ」や「樹木植生」があって、仮眠し易いPASAはいくつかある。個人的には以下が候補。

  • 北陸道、黒埼PA(下り)(新潟、離れ)
  • 上信越道、妙高SA(上下、離れ)
    (冬期は積雪のため、おそらく利用できない)
  • 東関道、酒々井PA(上下、植生)
  • 中央道、双葉SA(上り、植生)
  • 東名、富士川PA(下り、植生)

ただし雨天荒天時は、木々から落ちる雨粒音がうるさいので、あくまで天候次第。
個人的に天候が悪い場合は、宿泊施設か某満喫チェーンを利用。

【スポンサー広告】

あおり運転などの危険運転

昨今のテレビというか、ネタが枯渇しているからか、あおり運転や逆走といった危険運転が報道されることが増えた。

まぁ「昔はこんな運転する奴は、いなかった」わけではないと思う。
でも昔(MT車全盛の頃)の車は、加減速の際、適宜ギアチェンジする必要があったので、結果的にギアに適した速度で走行する必要もある。
つまり車両性能だけでなく、運転操作そのものにテクニックを要したわけで。そんな中で他人の車を煽るなんていう、面倒な行為への考えは至らなかったのではないかと思う。
しかも今のような安全性能も担保されていない車で、危険運転で事故を起こしでもしたら、死なないにしても、脚や腕の1本は持っていかれる危険すらある。

それに比べると現在の車は、加減速の自由度が高くなり、結果的に個々人の運転に対する自由度つまり余裕も増した。
そこに、ゲームやマンガ的なフィクションの世界に感化されたののか、自己中心的な運転をする人も増えた。

いずれにせよ「時代の流れ」ではあるのは仕方ないが、結果的に極めて自己中心的で稚拙、かつ、運転免許を所持するには向いていない思考を持つ方々が運転されることが増えてしまった。

対策

ただ幸いな事に、技術の進歩もあって、自衛策についても選択肢も増えた。
あおり運転に巻き込まれないようにするためのテクニックを持つことも大事だが、まずは、あおり運転に不運にも巻き込まれてしまった場合の事を考えて、対策と行動を考えてみた。

ドラレコなどの記録をする

あおり運転の検挙向上のためには、これが必須。
防犯にも有用だが、煽られた時、違反行為の証拠物件となる。これが一番大きな要素。

ただし安価なドラレコ製品もあり、そのような製品だと、ナンバーが不鮮明だったり、時間が正しく記録できない、記録時間が短い、すぐ壊れるなどの問題もある。車種に併せて最適な製品を搭載するのが良いと思う。

即110番。

特に最近(ここ数年以内に)購入したスマホの場合、GPS を使って、警察側から通報者の位置情報を取得することが可能になっている機種が多い。

なので、安全な場所に停車したうえで、スマホから即110番通報すること。

同乗者がいる場合は、同乗者に通報してもらうほうが良い。
逆に、運転しながら直接通話することは、可能なかぎり避けるべき。運転しながらの通話については、それこそ交通違反に問われる可能性もある。
そして何よりも、気が動転してしまっている状況下で、運転しながらの通話は危険極まりない。

また停車の際、あおり運転した者が近くにいる場合は、絶対にドアをロックし、ウインドウを閉めること。
とにかく警察に介入して貰うことが大事。

警察に通報した以上、自身への聴取には素直に従うこと

自身に非がない以上、聴取を受けて困ることはない。
時間や手間を取られる可能性は高いが、検挙するためには、録画データ(証拠資料)の提出など、警察への協力が必要になる。

必要であれば、報道機関やネット上で公開する

社会問題になっている昨今、報道番組やネット上で話題になることで、警察が動く可能性もある。

もちろん検挙前の状況なので、あおり運転した者であってもプライバシーなどの配慮は必要だが、被害者としての選択できる手段としてはあり。

免許取消への道

ここからは、あおり運転を働いた者への話。

警察の捜査の結果、対象者を「危険性帯有者」として警察が認定した時点で、最長180日間の免許停止になる可能性がある。

昨今あおり運転が社会問題化した関係で、警察においても「危険性帯有者」の場合、違反点数の累積は関係なく、いわゆる「一発免停」とすることが可能になった。

ちなみに一般的な免停の場合「出頭要請通知書」「意見の聴取通知書」などが送付されてきて、通知に応じて指定場所(警察署や免許センターなど)に出頭することになる。

しかしこれは基本的に「行政処分」上の話。

交通関係取締は特殊で「行政処分」による判断と「刑事処分」による判断の2種類が存在する。

いわゆる駐車違反やスピード違反などで、巷で取り締まられる場合は「行政処分」のみの取締がほとんど。

ところが交通違反を常習的に行っている場合や人身事故などの重大事故、重大な違反行為等については「行政処分」だけでなく「刑事処分」も併せて取り締まられることになる。
要するに「違反」だけでなく、「犯罪行為」としても取り締まりの対象となる。

そして、あおり運転行為などで「危険性帯有者」と判断された場合も、これに当て嵌められ、実際に行われた行為に対して「妨害運転罪」としての「刑事処分」について、並行して調べられる。
そして「刑事処分が相当」と判断された場合、犯罪行為として取り締まることになる。
この場合は、おそらく別途警察署から出頭要請、もしくは捜査員が自宅などに直接お迎えに来ることになるのではいかと。

そうなった場合、あとは刑事処分に基づいた流れになる。
内容によって大きく異なるので、一概には言えないが、逮捕拘留、送検、取調べ、裁判、刑事罰(罰金・懲役等)といった流れに繋がっていくのではないかと。

そして「妨害運転罪」として認定された場合、場合によっては「免許取消」の可能性もある。

免許停止(免停)と免許取消(免取)その違い

「免許停止」は、指定の期間内、免許の効果が停止されること。
こちらは指定の期間が経過すれば、免許を効果が復活する。

対して「免許取消」は、免許そのものが無効になる。
この場合、免許が再度欲しい場合は、再取得のため、教習所に通ったり試験・講習などを受ける必要がある。

しかも免許取消の場合は「欠格期間」が定められ、その期間内は取得すること自体が、そもそもできない。

以下、参考

無免許運転

一発で「行政処分」「刑事処分」の対象となる。
つまり、免許取消と罰金または懲役のセットである。
刑事処分が問われるレベルの嫌疑なので、逮捕や拘留の可能性だってある。

ちなみに無免許運転が成立する条件は、以下の通り。

  • 免許を最初から持たない者が運転。(純無免)
  • 免許停止中の者が運転。(停止中無免)
    (しかも、免許停止⇒免許取消になる。)
  • 免許取消となった者が運転。(取消無免)
  • 免許で与えられている資格外の車両を運転。(免許外無免)
    (大型免許じゃないのに大型車を運転した場合など)

そして「危険性帯有者」「妨害運転罪」などで免停・免取となった者が無免許運転なぞすれば、逮捕・拘留は確実ではないかと。

処分保留や不起訴処分

「妨害運転罪」に問われたとしても、処分保留や不起訴処分は、可能性としてはあるかもしれない。

ただし捜査対象となった前歴は、確実に警察・検察等に残ることになる。
それの意味する事は、よく考えたほうがいい。

免許再取得と一発試験

免許を再取得する際は、再度教習所に通って、その過程で免許を取得する方法と、試験場での「一発試験」の2種類がある。

そして免許取消後の再取得で「再度、教習所通いはしたくない」という人も一定数いると思う。
そういう人が「一発試験」を選択することがあるそうで。

今は文字通りの「一発試験」ではない

制度改正され、以前よりも手間がかかるようになった。
箇条書きすると、以下の通り。

  • 仮免合格のための練習や勉強
  • 仮免学科試験(免許センター)
  • 仮免技能試験(免許センター)
  • 本免路上練習(5日以上必須、指導者の記録必須)
  • 本免学科試験(免許センター)
  • 本免技能試験(免許センター)
  • 取得時講習(免許センターまたは委託先教習所等)

通常の「一発試験」の流れは上記だが、免許取消者の場合、これとは別に以下を、本免試験までに受講する必要がある。

  • 取消処分者講習

取消処分者講習とは

取消処分者が免許を再取得したい人のために行う講習で、都道府県によっては、民間の教習所等に委託されて行われている場合もある。

取消処分者講習は開催頻度が高くないため、受講するまでの予約が大変な場合があるが、受講内容自体は、あくまで修了することが目的。

無論、遅刻早退や不遜な態度、講習の妨害などの行為を行えば、受講そのものが取消になったり、業務妨害として取締の対象になることはあると思う。

受講内容の結果(カウンセリングをはじめとした受講状況や適正検査の結果、感想文の内容等)については、免許センター(再教習を受けている場合は教習所)にフィードバックされる。
そのため、技能試験(卒業検定)の際に参考資料として取り扱われている可能性は否定できない。

【参考】停止処分者講習

こちらは、成績(優、良、可、不可)による考慮があり、「可」以上の成績に応じて、免停期間が短縮される可能性がある。

本免の技能試験は、れっきとした警察官が試験管

そして最大の難関が、本免技能試験。
これがとにかく難しい。

当然「危険性帯有者」「妨害運転罪」の者が、一発試験に来れば、その素性は知られた状態です。
当然ながら「合格させたくない」のが本音のはず。

もちろん試験は公正に行われるとは思う。
だが試験管も人間。
当然ながら試験管に認められる範囲・裁量でチェックされる。
結果として、通常よりも合格はかなり狭き門になる。

その点は覚悟が必要。
教習所に通う以上の時間がかかる可能性だって、あり得る。

免停・免取時の免許証

免許停止中の免許

違反をした場合、基本的に警察署から「運転免許行政処分出頭通知書」が対象者に届く。
そして指定された場所(警察署など)に免許証を持参して出頭し、聴取・手続の過程で免許証を預けることになる。

そして免停期間が終了した時点で、預けた場所に行けば返還されることになる。

免許取消の免許

免停と同じく、出頭の際に免許証を持参し、聴取・手続の過程で免許証を預けることになる。

そして、その後の審査の結果「取消処分書」が発行され、預けた免許証はそのまま没収となる、という流れが一般的ではないかと。

もちろん出頭要請に応じなかったり、出頭の際に免許証を持参しなければ、免許証没収には繋がらない(できない)。
しかしながら、併せて警察官の心証も当然悪くなる。結果的に警察官が直接お宅に訪問してきたり、逮捕・拘留のリスクが高くなる。

それに免許証がなくても、事実が揃っているのであれば、当事者が意見聴取に応じなくても、司法上は違反行為は成立する。
その結果として「取消処分書」は発行されることになる。

そもそも取消になった免許証を所持することは、それを悪用する恐れもある。
そして警察(公安委員会)自らが発行した免許証を、取消になったにも拘わらず、そのまま放置するのは看過できない。
そう考えると警察側の道理も、かなっている。

最後に

運転免許は「試験に合格すれば貰える特典」ではない

誤解してはいけないのだが、試験に合格するのは当たり前であり、かつ運転するに値することが許された者だけが所持することができる「免状」であるという点。

だからこそ定期的に審査され、必要に応じて運転行為を確認し、問題があれば免状の行使を制限されたり、没収される可能性もある物であると考えるべき。

自衛も必要だし、社会に適宜訴える必要が違反行為・犯罪

警察も人員に限りがあり、一市民が通報したところで、取り締まりに動くことはかなり少ない。
まぁ訴えたところで「様子を見にくる」程度。
この程度で、危険な運転を常習的に行っているような輩が、何とかなるわけがない。

それに「危険性帯有者」の判断や「妨害運転罪」は、現実的には被害を訴えなくては成立困難なので、ドラレコなどでの記録など、密に自衛する必要がある。

【スポンサー広告】

生保の新入社員勧誘(昔話)

学校卒業後、最初の会社に就職した際に契約した保険証書が出てきた。

まぁ最初の会社は、割と早いタイミングで辞めてしまい、その時のゴタゴタで引落に使っていた銀行口座の残額を空っぽにしたので、その過程で未払い⇒失効したと思う。

褒められたもんではないけれど、まぁ、色々と当時の「若気の至り」という事で。
色々、察してください。。。

でも、彼らの当時のセールス方法、今もこんなセールスをやっているのかは知らないが、今を思っても、正直ウザかった記憶しかない。

もしかしたら、個人情報や社外秘に対する意識が変わっている昨今では考えられない話かも知れないが、経験ログとして記事にしてみた。

何故か、職場に入ってくる

昼休みに、彼らは何故か職場に入ってきて「営業」をするのだ。
入口の受付(総務)の人が制止する素振りもない。

そして春先に入社した社員(つまり私)は、格好の餌食に

おそらく、今は情報セキュリティなどの理由で入室する機会は減ったかもしれない。

でも、今でも外の通路や社員食堂で営業が待ってたりするのではないかと。
もしかしたら、機密保持契約を結んでて、正々堂々と執務室に入室してくることだって、あるかも知れない。

そして、目が合ったが最後、会話したら最後、とにかく保険の資料とか書類を渡してくる。

今となっては、とにかく昼食は、屋外に食べに行くべきだったと思う。

生命保険への加入は必要か?

結論から言うと、加入しておいた方がいい
病気や事故などは、いつ遭遇するか分からないし、実際遭ってしまった場合でも家賃や生活費は必要になるわけで。

そんな時、会社は保障してくれない。

ただ、大手生保の営業が勧めてくる保険には、入らないくてもいい。
それが、たとえ1万円だったとしてもだ。特に一人暮らしの人。
新人時点で、何かと物入りで欲求も多い時期に、自分の薄給から出すような額ではない。

個人的には都府県民共済で十分。
しかも健康なのであれば、共済の提供する特約もとりあえずは必要ない。
高額なオプションの付属する生命保険は、必要ない。

割と知らない人が多いが、もともと健康保険に加入していれば、その保険の範囲内で可能な治療はできる。
生命保険はそれに上乗せされるサービスと考えるべき。

例えば、入院するにしても衣類やテレビ等の付加サービスを利用するには、追加料金が必要になる。
部屋だって個室を希望すれば、差額ベッド代が請求される。

どちらかというと生命保険は、その部分を補うシステムであるとシンプルに考えたほうがいい。
そこに保険の種類として、高度先進医療や特定疾病に特化したものや、各種特約によってサービスや保険金が上乗せされる。

そして更さら、老後の積立金や一時金支払い、金融資産などとの連携サービスなど、色々なものがくっついてきて、正直わけが分からなくなる。

保険掛金での積立は、儲からない確率が高い

生命保険を財テクの一種として考えている人がいるが、分散投資の一つとして考えるのならまだしも、就職直後のお金の余裕がない時期に、生保だけを財テクとして考えるのは勿体ないので、絶対にやめたほうがいい。

それに例えば定年(満期)まで、保険掛金を支払ったとして、その掛金総額以上の保険金が返ってくることは、ほぼない。

無論、不慮の病などで人生半ばでこの世を去ることになる人などにおいては、保険掛金の総額よりも保険金のほうが多くなる場合はあるかもしれない。
でもそれは、あくまでケース・バイ・ケースな話であって確実性はない。

世の中の大半の人は、定年まで生き延びるわけで。
そうなった時に、満期まで支払った保険掛金の総額よりも、保険金が上回る事は、まずない。

将来の子供のため、妻のため、万一自分に何かあった時の事を考えると入っておいた方が良いかもと考えるかも知れないが、基本的に家族に残すための保険とした場合、莫大な保険掛金が必要になる。

生命保険は税制上の優遇(控除)があるので、そのメリットを活かすという点では、加入してもよいかも知れない。
ただし、あくまで「そのメリットを活かす」という程度の掛金に留めたほうがいい。

個人的には、この「メリットを活かす」ためには、現時点での払込掛金の上限でを超えない額とするのが良いと思う。
そうなると一般生保の掛金では簡単に超えてしまうため、個人的には、都道府県民共済のような小規模かつ年毎に返戻金があるような、小規模な保険のほうが良いと思う。

生命保険のデメリット

保険会社の倒産・資産運用が不明瞭・不祥事

今まで様々な保険会社が不祥事起こしたり、経営破綻したり(破綻しなくても吸収・合併を繰り返したり)と、大手生命保険会社にて一貫して健全な運営が行われている企業は、あまり多くない。

自分が若い頃に契約した会社は2社あったが、そのいずれも現在はその会社単体では存続しておらず、合併してしてしまった。

理由は色々あるだろうが、結局の所、社会変化に追随できなかったわけで、そのような保険会社に一生涯の保険掛金を預けるだけのメリットが、どうしても捻出できない。

保険資産の運用が不適切

特にこれ。
高度経済成長時においては、物価上昇や社会成長に併せて、漫然とした資産運用であっても問題なかっただろうが、それが頭打ちとなった1970年代後半以降、マトモな資産運用ができる保険会社は、かなり減ったはず。

特に現在においては、とてもシビアな資産運用を行わないと利益なぞ出せない時代。保険会社ごときの資産運用でそれができるわけがない。

春先、保険営業の餌食となりそうな方々へ

まず、保険の知識がほぼないはず。

とりあえずは、都道府県民共済のような小規模共済に加入して、保険の営業とは絶対に目を合わせないほうがいい。
そして「別の保険に入ってるから」という理由も含めて、絶対に言わないこと。

【余談】生保に入っていた方が良い人は、どのような人か?

こういった人は、普通の生保に契約したほうがよい。

  • お金に余裕のある人
  • 細かい事について興味のない人、面倒に思う人。
  • 運転などにおいて性格が豹変する人。自身の健康に対して無頓着な人。つまり最終的に生保の厄介になる確率が高い人。

【スポンサー広告】

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 再起動してる。

【スポンサー広告】