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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ただ、大手生保の営業が勧めてくる保険には、入らないくてもいい。
それが、たとえ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 を使用する。

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

東京湾一周(?)ドライブ

緊急事態宣言によって、幻に終わったドライブプラン。

この週末、東池袋とお台場で荷物と人の移動をサポートしつつ、日中の時間調整を子供とのドライブに充てる予定だった。
参考までに掲載。また使うかもしれない。

若干ドライバーにはハードなプラン。
わりと走りっぱなし。しかも子連れ。。。

湾岸経由ではなくアクアライン経由としたので、タイトルに(?)を追加した次第。

行程表

06:00発、貸出
06:30着、自宅
06:45発、(外環 ⇒ 首都高5)
07:30着、東池袋
07:45発、(首都高B,Y,11)
08:45着、お台場
09:00発、(首都高B ⇒ 東京湾アクアライン ⇒ 富津館山道、途中休憩:大井PA)
10:05着、金谷港、東京湾フェリー
–:–発、(航送(<6m)+大人4,100円、小人400円)
–:–着、久里浜港(5便10:25 ⇒ 11:05、6便11:20 ⇒ 12:00)
12:00発、(5便なら久里浜で昼食、6便なら金谷の売店で弁当)
12:30着、くりはま花の国(休憩)
14:30発、(横横道路 ⇒ 首都高B)
16:00着、お台場
16:15発、(首都高B,C2)
17:30着、東池袋
18:00発、(新青梅街道)
19:15着、帰宅
19:30着、返却

今度1人で深夜ドライブするかなぁ。
あ、でも東京湾フェリーって夜行便ないのか。詰み。

さくらのレンタルサーバに Nextcloud 入れてみた感想

インストール方法は割愛

ググれば既に解説されてるサイトがいくつかヒットするので、詳しくはそちらを参照。
自分の場合、この時点での最新バージョン(21.0.1)をインストールしたが、以下の点にハマったこと以外は、問題なくインストール、稼働してます。

ハマったこと

WAF は必ず「無効」にすること。

別に Nextcloud の問題ではなく。

インストールの途中で Nginx のエラーが出たり(レンタルサーバは Apache 稼働)、スタイルシートなどが反映されず、レイアウトが崩れたり、最初、理由がさっぱり判らなかった。無駄にすること数時間。

結局原因は「これ」。

WAF を有効にしてたのをすっかり忘れてた。
無効にしてインストールしたら、すんなり入った。

いきなり結論

重い

所詮「レンタルサーバ」(共用サーバ)なので、レスポンスは期待してなかったけれど、Web 画面はかなり「もっさり」してる。
遅いからと言って、レスポンスか返ってくるのを待たずにあちこちクリックすると 500 エラーになる。
でも、この辺りは WordPress(特にダッシュボード、管理画面)の挙動でも同様なので、期待しないほうが良いかも。

一応 Nextcloud 内部でも、キャッシュなどのレスポンス対策は施されているようだが、大量のユーザを抱えての運用には耐えられないと思う。
レンタルサーバ上の Nextcloud は、あくまで個人利用ぐらい。

ちなみに、レンタルサーバのプランを上げることによって「重さ」が軽減できるとは考えないほうがいい。

「多少」は軽くなる可能性があるものの、体感できるほどのレスポンス改善はおそらく期待できないと思う。

IT技術者じゃないとインストールは難しい、かも?

インストール等はかなり簡単にできるようになってはいる。しかしながら、Apache などの conf 設定や、Nextcloud 自体の config 設定など、細かな設定調整をしようとすると、IT技術者としての知識や経験・勘所が必要な部分がどうしても出てくる。

また、セキュリティ面の部分も考えると、適切なIT技術者がインストールや設定を担当するのが望ましいと思う。

Android, iOS などのアプリ提供を謳ってるけど、アプリで直接できるのは、ストレージ機能ぐらい

CalDAV, CardDAV を用いた同期(連携)については、Android, iOS の Nextcloud アプリを経由してやれるようだが、あくまで同期だけ。
Android, iOS の Nextcloud アプリが、直接カレンダー機能などのグループウェア機能を提供してるわけではない。

WebDAV に関連する機能は、レンタルサーバのプランに依存する

さくらインターネットの場合、レンタルサーバでも「マネージドサーバ」プラン(1台、丸ごとレンタルプラン)じゃないと、そもそも WebDAV 自体が使えない。

そして、それは WebDAV を使用した規格である CalDAV, CardDAV も使えないことを意味する。

カレンダーやメール閲覧機能について

Nextcloud システムは、アプリ(というかプラグイン?)機能として、カレンダーやメール、連絡先などの各種グループウェア機能を導入することができる。

しかしながら、機能面ではお世辞にも洗練されているとは言えない。
Nextcloud をビジネス上の統合環境として捉えるのであれば、選択するも良いとは思うが、その場合は、専用サーバを建てて運用するのが良いかと。

そして専用サーバを建てるぐらいであれば、Google Workspace(旧 G Suite)などのサービスを使ったほうが良い気がする、のだが?

それにレンタルサーバで Nextcloud を運用する場合、付加機能はそのままサーバ負荷になってしまう。
あくまでクラウドストレージとして割り切って、これらのアプリ導入は控えたほうが良いと思う。

外部ストレージ

たとえば、NextCloud のストレージから別サーバの領域を「外部ストレージ」として繋ぎ込むことが可能。
接続できるのは、Amazon S3 などの各種クラウドサービスのオブジェクトストレージや、FTP, SFTP で接続できるサーバ領域など。

ちなみに SMB/CIFS などにも接続できるが、今回はさくらのレンタルサーバに Nextcloud を設置したので、使えない(使わない)のではないかと。

自分の場合、いくつかの Web 領域として無駄に保有してる領域を FTP 接続して使ってみた。

「1つの外部ストレージの接続設定=1つのディレクトリ」として認識する

そのため、外部ストレージ配下の最大容量は、外部ストレージとして接続した先で個々に提供されている領域の上限になる。
接続先の領域サイズが極端に小さい場合は、その領域内に保存するファイルの容量に注意する必要がある。

あと、当たり前だが、ストレージ領域として合算された領域サイズとして、一連で使える訳でもない。

Web領域を繋ぎ込むことも可能だが、セキュリティに注意

ホームページ領域として提供された空間を FTP, SFTP で外部接続して有効利用すること自体は可能。
ただし、これらの領域は元々ホームページの領域として公開されている領域なので、外部接続先として繋ぎ込むディレクトリに対し、適切なアクセス制限を施さないと、ホームページの領域として丸見えになってしまうので、注意すること。

ちなみに ISP によっては、そもそもアクセス制限を施すことができない場合ホームページサービスもあるので、注意。
その場合、外部ストレージとしての使用は望ましくない。

遅い

ただでさえレンタルサーバ上の Nextcloud 本体への接続が遅い状況下で、さらに FTP 接続した先の外部ストレージを参照する以上、レスポンシブとは言い難い。
フォルダの同期という形で利用するのであれば、違和感を感じることはないかもだが、Nextcloud のWeb画面からテキスト等を直接参照・編集する場合には、かなり遅く感じる。
(たまに 500 エラーも発生する。)

レンタカー vs カーシェア

前回記事に関連。

弾丸で関西往復。往復で1000kmぐらい?
レンタカー2日間利用で、レンタカーかカーシェアかを考えてみた。
ちなみに5ナンバーワゴンを検討。

以下、2021年4月現在の48時間料金で試算。

ニッポンレンタカー

ちなみに以前はトヨタレンタカーを使ってたのだが、近所の店が、いつの間にかニッサンレンタカーになってしまった。
悪いけどニッサンレンタカーは使わない。。。

  • W-K、23,100円(会員料金:20,790円)
  • W-A、36,300円(会員料金:32,670円)

ちなみに会員料金は「10%引」。
最初は消費税分だけの割引になるが、利用回数の多い「ゴールド会員」様は 20% 割引になる。
ただし、割引対応車種やシーズン等によってかなり左右されるので、正直そこまでのメリットは感じにくい。

ちなみにこの手の会員サービスの割引、どこのレンタカーもやってるけど、特に「ブランド系レンタカー」の会員割引サービスは、とにかく「例外ルール」が大盛りすぎ。とても判り難い。本当にメリットあんのか?
消費者目線のサービスとは、とても言えない。

タイムズカー(カーシェア)

  • ベーシック、9,900円
  • ミドル 、13,200円
  • プレミアム、20,900円

レンタカーの場合、車種やプラン等によってはカーシェアより安くなることはある。
ところがミニバンなどのワゴンクラスの場合、一般的にカーシェアのほうが安い。

でもワゴン車はカーシェアでも人気あるので、それはそれで「空いてない」という問題が生じることがある。
(自分も予約開始時刻に合わせて取得することが多い。)

燃料費

これとは別に実際には「燃料費」がかかるのだが、タイムズカーの場合、利用料金に含まれる。
今回の場合、長時間利用ということで「距離料金」が生じるので、これに「燃料費」が含まれていると考えると、判りやすい。
というわけで、関西往復1,000km走るとすると、1.6万円。

燃料は車両付属の「専用カード」で給油。
自前で給油してしまっても、距離料金は必ず取られるので、絶対に「専用カード」で給油すること。

レンタカーの場合、完全自費で燃料入れることになるが、1万強ぐらい。
「燃料費」と考えると、若干レンタカーのほうが安くなると思うが、それでもレンタカー本体の料金が高いので、カーシェアとは比べものにならない。

結論

料金面では、カーシェアの圧勝。

ただ、カーシェアよりもレンタカーのほうがメリットある場合もある。
例えばワンウェイや乳児用のシート、ETC貸出などのオプション。いつも洗車済・整備済・満タンの車両が前提だし。

対してカーシェアは、とにかく汚いことや破損が目立つ。
例えばマットに泥や枯れ草がくっついてたり、シート下に菓子をこぼしたものが落ちてたり、飲み物やゴミが放置されてたり。
使用前点検もちゃんとやらないと、バンパーやサイドを擦ってたり。

結局のところ、前の利用者の問題ではある。
ただ、この手のマナー違反は、使用の都度報告しないと、自分の所為にされ、後日疑われることだってある。

このあたりの「割り切り」で、利用の選択肢としても良いかと。

大阪まで船移動を考えてみた

東京から大阪まで「往路は楽に車移動できないか、子連れだし」と、フェリーでの移動を考えてみた。

ところが

現在、東京ー関西を直通する一般向けフェリーはない。
そのためオーシャン東九フェリーで四国・徳島まで向かい、そこから神戸淡路鳴門道を経由して大阪に向かうことになる。

ちなみに今回は用事での移動。レジャーじゃないので、弾丸。
土曜午後出発、日曜日中着、月曜早朝までに戻り。

タイムスケジュールとおおよその料金

  • 土曜
    • 15:00発、レンタカー貸出、W-A、29,040円
    • 16:00発、自宅出発、関越、首都高
    • 17:30着、東京有明埠頭
    • 19:00発、オーシャン東九フェリー
      運賃12,730円/人、2名個室10,000円/室、自動車航送(<5m)34,700円/台、計44,700円。
      (船中泊)
  • 日曜
    • 13:20着、徳島沖洲桟橋
    • 14:00発、徳島道、大鳴門橋、阪神高速
    • 16:30着、大阪目的地着
    • 18:00発、阪神高速、名神、新名神、伊勢湾岸道、新東名、東名(高速代10,250円)
  • 月曜
    • 2:00着、自宅到着

自力で陸送した場合

高速代10,250円、燃料代5,000円。計15,250円。
しかも土曜日中に出発すれば、夜には着いてしまう。
日曜までのホテル泊したとしても、コロナ禍の影響で宿代は1万位で泊まれる。そうなると往路総額で2.5万。

結論、断念

これ、良案だと思ったものの、差額を考えてプラン断念。残念。