月別アーカイブ: 2021年5月

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

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

まぁ「昔はこんな運転する奴は、いなかった」わけではないと思う。
でも昔(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 再起動してる。

接続元 IP が変更された際の iptables の SSH 設定変更

当方は、一般的なプロバイダーから接続している。
そのためルータを再起動するなどによって PPPoE を再確立した時点で、接続元の IP が変わってしまう。
この影響により、SSH 接続を制限しているサーバに対し、以下の作業を都度行う必要がある。

手順

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

AAA.BBB.CCC.DDD

そのIPアドレスの WHOIS 情報を探す

次項は、再接続時の際に「偶然、以前に設定したセグメント内に入る」という可能性を考え、このような作業を追加としている。
個人的な「こだわり」の部分。

これは、全開放に比べたら極めて小さい穴だし、SSH 接続は鍵認証しかできないなど、他の部分でセキュリティレベルは上げるなどの処置を施している。
その点からして、リスクはカバーしてると思う。

あくまで参考程度とすること。十分考慮のうえ注意すること。
熟考せず無為に参考のまま設定すると、セキュリティ的にガバガバになるリスクがある。
参考にしての設定は、あくまで自己責任で。

登録情報からネットワーク IP アドレス(付与されている IP アドレス範囲)を探す。

なるべく広めの IP で SSH ポートを開くため。上位があるなら、なるべく広めに開ける。

AAA.BBB.CCC.EEE/FF

「さくらの VPS」コントロールパネルからコンソールに root ログイン

TeraTerm などで接続できない以上、仮想コンソールを使うしかない。

何番目に SSH 開放 IP アドレス(範囲)を突っ込むか探す。

この辺りは、手探りで探すしかない。
主に利用するコマンドは以下。

  • ルールの確認(設定コマンド原文)
# iptables -S
  • ルールの確認(設定順番号、表示整形)
# iptables -L --line-numbers

iptables の構成次第によって、追加(挿入)する場所が厳密な場合があったり、何も考えず、最後に追加すればよい場合など、そこは個々の構成に併せて考える。

iptables に追加(挿入)コマンド投入

  • 【例1】IP アドレスを範囲(サブネット単位)で SSH 開放する場合
# iptables -I INPUT 5 -s AAA.BBB.CCC.EEE/FF -p tcp
 -m state --state NEW -m tcp --dport 22 -j ACCEPT
  • 【例2】1つの接続元 IP アドレスだけ SSH 開放する場合
# iptables -I INPUT 5 -s AAA.BBB.CCC.DDD -p tcp
 -m state --state NEW -m tcp --dport 22 -j ACCEPT

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

TeraTerm などで、以前の通り接続できるか確認。
問題なければ、次項。

sysconfigに設定情報を保存

# service iptables save

念のため、ちゃんと保存されたかの確認もする。

# cat /etc/sysconfig/iptables

参考

【余談】将来こうしたい

ルーターの切断や再起動した時にしか必要のない作業とはいえ、毎回この設定をするのは、いちいち面倒。
なので、何かしらの自動化を考えている。

NASか、クラウドストレージか。そしてフリーか、メーカーか。

標題の件。
いつもリプレースとかで悶々と考えたり調べたりするので、つらつらとまとめてみた。

フリーのNAS系OS

後者で触れる「OS 上のアプリとして動く『クラウドストレージ』ソフト」とは異なり、OS レベルで NAS としての機能を提供する。
よって OS インストールと同時に、NAS としての機能も併せてインストールされる。

記事作成時点での主な OS は、以下。

  • TrueNAS(旧 FreeNAS)
  • openmediavault
  • Rockstor
  • XigmaNAS(旧 NAS4Free)

メリット

無料。

何と言ってもこれでしょう。

デメリット

バグ対策。

何と言ってもこれでしょう。(またかw)

CentOS など無料版 Linux OS とは、開発体制(というか、単純に言うと、関わっている人の数)からして、あまりにも脆弱。
保証? フリーなのだから、目標とかポリシー・スタンスはあるだろうけど、保証なんてものはない。

そのため、OS などのバグによって、データが破損したり、危険に晒されるリスクは常にある。
勿論そうならないようにするため、RAID 機能やバックアップ機能の提供はされているが、それすらフリーの機能なわけで。

でも NAS 上で管理するデータは、運用する個人・組織の「資産」にも等しいもの。
リスクがあるのは、あまり気分がよいものではないかも。

メーカー製 NAS に比べて、遅い(という可能性)

動作するハードウェア、たとえば CPU などを広範囲化する等、より汎用的に動作するように OS が実装されている。
そのため、OS 部分をはじめとしたプログラムが膨大になり、結果的に処理スピードの劣化に繋がってしまう。

所詮「フリー」という点に尽きる。

TrueNAS(旧 FreeNAS)⇒ ベース OS が FreeBSD = 主流じゃない。

FressBSD 系には ZFS という、とても多機能で魅力的なファイルシステムを利用できるメリットもある。
しかしながら、いかんせん FreeBSD は主流ではない。
そのため、Web 上での情報が少なく、例えばハードウェアに適合するデバイスドライバーを探すのに難儀する可能性や、トラブルシューティングの際のハードルが高くなる点が考えられる。

【記事注】
ZFS は最近 Linux 系 OS にも移植され、利用できるようになりつつある。
FreeBSD 系の普及があまりにもしないため、ZFS 作った人が折れて Linux を容認したからか?

クラウドストレージ

OS 上のアプリとして動く『クラウドストレージ』ソフトのこと。
ソフトウェアとはいえ、ミドルウェア的な位置づけのような感じ。

主なソフトウェアは、以下。

  • Nextcloud
  • ownCloud(商用版もあり)

これ以外にもあるとは思うが、個人的には Nextcloud の1強だと思ってる。
ちなみに Nextcloud は ownCloud からのフォーク(いわゆる「派生」)であり、ownCloud 自体にもフリー版はある。
でも、関係者や歴史的経緯(いわゆる「仲違い」)からして、現在フリーのクラウドストレージとしての代名詞は、Nextcloud になっているような気がする。

メリット

無料。

もういい(笑)

ファイルの世代管理など、付帯機能の可能性。

クラウドストレージは、ネットワーク先にあるディスクのファイルと同一の「コピー」を自分のマシンに保存し、「同期」する形態が基本。
そのためNASに比べて、ファイルを破損するリスクが軽減されたり、ファイルそのものの世代管理機能が提供されている場合もある。

デメリット

バグ対策。

これも NAS と同じ。

クライアントにも(原則として)領域が必要。

上記に触れた通り、コピーとは言え、利用中(編集・表示中)のファイルをローカル内に保存することが原則。
そのためローカルのディスク内から、ある程度の容量がクラウドストレージとの連携用に必要となる。

とはいえ、クラウド上のすべてのファイルを同期(コピー)を保存しているわけではなく、利用しているファイルのみ同期されることが基本。
それにローカルディスクで「どの程度の容量をクラウドストレージの同期用領域として使用するか」を設定で調整することができることも多い(または自動的にやってくれる)。
そのため、動画などの馬鹿みたいに大きなファイルを扱っていなければ、ローカルディスクは逼迫されないと思う。

【余談】クラウドストレージ ≠ NAS

最近はクラウドストレージの機能を有する NAS(たとえば、Web ブラウザやアプリを経由して NAS にアクセスする)、逆に NAS のようなファイルアクセスが可能なクラウドストレージ(WebDAV を使用し、通常のファイルのようにアクセスできる)など、お互いの垣根を越えるような機能が提供されることが多い。
しかしながら、そもそもクラウドストレージと NAS には大きな違いがある。

NAS はあくまで、ネットワーク接続して利用するストレージ領域。ネットワークディスク。

NAS には、ネットワークの先にあるサーバ上のディスクのファイルに直接アクセスする。これが基本。

クラウドストレージは、サーバにあるファイルの「コピー」をクライアント作成して、同期を取る。

ネットワーク先にあるサーバ上ディスクのファイルと同一の「コピー」を、自分のローカルマシンに保存している。
そして、参照や編集の都度、サーバ上のファイルとの整合性を確認し同期を取っている。
そのため、ネットワーク先にある実ファイルとのやりとりが生じるため、タイムラグが生じる場合がある。

ちなみに、NAS・クラウドストレージともに、例えば同一ファイルを複数人が編集していた場合、デッドロックや不整合、はたまたファイルの破損が生じる可能性がある。
しかしながらこの場合、最近のクラウドストレージだと、ファイルの履歴を保存(世代管理)する機能が提供されていること多い。この場合、万一ファイルが破損しても、破損前のファイルに戻すことができる。

NAS の場合は、編集・参照ともにファイルを直接弄っている事になる。
そのため、Excel ファイルの場合など一部のアプリケーションではファイル編集時に排他制御を行っているものものあるが、基本的には同時編集などが生じた場合は「あと勝ち」つまり最後に保存した状態のものが、実際に保存されることになってしまうし、世代管理もしていないので、後戻りすることは基本的に不可能。

ここまで考えると、クラウドストレージのほうが軍配かなぁ。
フリーのNASはちょっと危険な臭いがする。
バックアップや RAID は、クラウドストレージとは別物で考えても良さそうだし。

メーカー系NAS

メリット

保証がある。

保証の形態は有料・無料、ディスク(データ領域)までの保証有無など、メーカーや購入機材によって様々だとは思う。

だが、それでもなお、ハードウェアだけでなくソフトウェアの保証まで範囲があるメリットは大きい。
使用者の心理手的負担が少なくて済む。

ベースシステム(ソフトウェア・ファームウェア・BIOS など)が最適化されている

各メーカーとも、NAS を制御するためのシステムは、独自開発されている。
そしておそらくそれらは、(余程の聴いたことのようなヘボいメーカーでないかぎり)各ハードウェアに併せて最適化されているはず。
言わば Linux OS を、NAS のハードウェアに併せてカーネルレベルで最適化しているようなイージ。
それによってシステムのスループットなど、機能向上に寄与しているはず。

デメリット

サポートには期限がある。

保証も含めて、メーカーは永久にサポートしてくれるわけではない。
ハードウェア部分のサポートは、一般的に製造終了後3~5年程度で終了するだろう。
そしてソフトウェア部分についても、手厚いメーカーですら、5年程度で終わると思う。
そうなった時点で、メーカーのホームページからは情報は抹消されてしまう可能性だってある。(Drobo は、まさにそうだった。)

メーカーの継続性にも注意する必要がある。

企業が途中で買収されたり、メーカーは維持されても、ブランドやNAS ハードウェアのビジネスにメーカーつまり企業としての事業メリットがなければ、事業が売却されたり、事業そのものが廃止される可能性だってある。

そうなった場合は、購入者も一蓮托生。

新たなテクノロジーや規格への追随性。

NASのテクノロジーも、年々進化している。
例えば内蔵されるディスクの容量は、年々増加の一途を辿っているわけだが、NAS によっては、その上限(ディスクの最大容量)が決まっていることが多い。

それと NAS に接続するためのネットワークプロトコル。
例えば、NAS のプロトコルでよく使われる SMB は、この記事作成時点では v3.0 や v3.1 が最新になりつつある。
このネットワーク規格の進化に、いつまでファームウェア更新で追随してくれるのかは、正直だれも判らない。

ちなみに当方で 10 年ほど前に設置した NAS は、SMBv1.0 のままファームウェアサポートが終了してしまった。
そのため、ある日、Windows 10 のアップデートを行った時に、接続できなくなるという憂き目に遭った。

後日これは何とか接続できるよう、Windows10 側の設定を変更したが、SMBv1.0 にはランサムウェアによるセキュリティリスクがある。
それを考えると、この NAS を継続的に利用することは、リスクになってしまう。

これらの点を踏まえると、いつまでも同一の NAS ハードウェアを使用することには躊躇が残る。

クラウドストレージサービス

おそらく理想的な最適解。
以下のサービスが有名。

  • DropBox
  • GoogleDrive
  • OneDrive (Microsoft)
  • box

メリット

企業としての保証・サポート

文字通り。

バックアップやハードウェアの心配が不要

これは「ある程度」という話。
今のところ、極めて稀にだが、復旧できないレベルの障害が発生するリスクは存在する。ほとんどの場合は心配は少ないと思われる。フリーNASやオンプレに比べると、故障リスクは低いのではないかと思う。

デメリット

高い。特にストレージ。

何よりも、これが筆頭ではないかと。
どうしても「月々」といったランニングコストが発生する。
企業系などの規模によっては、こちらのほうが安価な可能性はあるが、一般利用するには、どうしても「お高い」感が出てしまうう。

メンテナンスやネットワーク障害に影響される。

オンラインサービスの場合、この問題を避けることができない。
そのため、たとえば企業などの場合だと、オンラインストレージとオンプレの多重化を施す必要もあると思う。

自分なりの現実解

とは言え、まだ現時点では到達してないのだが、最終的にこうする予定。

  • オンプレサーバをファイルストレージとし、そこに Nextcloud を設置。(HDD 4台で RAID6 構成)
  • バックアップとして、Amazon S3 Glacier を使用する。

予定は変更する場合があります。