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
#

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

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] なら、正常に起動。
ブラウザから動作確認して、問題無ければ終了。

【余談】

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

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

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

手順

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

AAA.BBB.CCC.DDD

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

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

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

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

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

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

AAA.BBB.CCC.EEE/FF

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

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

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

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

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

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

iptables に追加（挿入）コマンド投入

  • 【例１】IP アドレスを範囲（サブネット単位）で SSH 開放する場合
# iptables -I INPUT 5 -s AAA.BBB.CCC.EEE/FF -p tcp
 -m state --state NEW -m tcp --dport 22 -j ACCEPT
  • 【例２】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

参考

【余談】将来こうしたい

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

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

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

フリーのＮＡＳ系ＯＳ

後者で触れる「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 の１強だと思ってる。
ちなみに 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 のハードウェアに併せてカーネルレベルで最適化しているようなイージ。
それによってシステムのスループットなど、機能向上に寄与しているはず。

デメリット

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

保証も含めて、メーカーは永久にサポートしてくれるわけではない。
ハードウェア部分のサポートは、一般的に製造終了後３～５年程度で終了するだろう。
そしてソフトウェア部分についても、手厚いメーカーですら、５年程度で終わると思う。
そうなった時点で、メーカーのホームページからは情報は抹消されてしまう可能性だってある。（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着、返却

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

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

インストール方法は割愛

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

ハマったこと

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

別に Nextcloud の問題ではなく。

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

結局原因は「これ」。

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

いきなり結論

重い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

外部ストレージ

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

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

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

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

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

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

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

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

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

遅い

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

レンタカー vs カーシェア

前回記事に関連。

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

以下、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万。

結論、断念

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

Redmineと別サーバの git リポジトリを連携する

ここでは概念的な話のみ。
実際の設定方法等については、各自でググッてください。

あと、これは昔話です。Redmine のバージョンは若干古いです。
最新の Redmine や Git では状況が異なる可能性あり。

「Redmine や Git には余計な手を加えず、Redmine や Git の標準機能だけで連携を実現する方法を導き出したらこうなった」というお話です。

下調べ

もしかしたら最新の Redmine は、こんな面倒なことしなくても、標準機能だけで別サーバの Git リポジトリを直接参照できるかもしれない。
でも、自分が環境構築した当時、調べてみた限りではこんな状態だった。

プラグインでの連携

そのプラグイン自体が最新だか何だかよく判らなかったし、情報が少ないし、よくわかんなかった。
プラグインがメンテされる可能性も未知数。

トリッキーな方法で連携

Redmine のプログラムソース弄ってなんたらとか、ディレクトリをマウントしてどうたらとか。
文字通りトリッキーな方法すぎて、正直メンド臭そうだった。

制約

あと、命題を実現するうえでの制約が以下。

Redmine の制約

標準的なパッケージ（プラグインとか入れない状態）では、 Redmine と同一のサーバ上にある Git リポジトリとしか連携できない。

前述の通り、絶対にできないわけではない。
プラグインの利用とか色々細々と弄れば、異なるサーバ間でも連携できるかも知れない。
あくまで、Git と Redmine 本体が提供している標準的な機能だけで可能な設定では実現できないという話

当方の運用上の制約

Git リポジトリを管理しているサーバは、Redmine とは別のサーバ

Redmine 搭載のサーバと Git リポジトリを管理しているサーバは、それぞれ公開の場所も、管理上のポリシーも異なる。
そのため Redmine サーバを、Git リポジトリとして一緒して運用する（開発者などに公開して操作させる）ことができない。

でも Redmine は、システム開発の基幹。何とかしてこれらを連携させたい。

そこで出た妙案

Git リポジトリには hook（フック）機能がある。

これを使う。具体的には以下。

  • Git ベアリポジトリに push されたら
    1. ssh で Redmine サーバにログイン。
    2. Redmine サーバ側にある Git ノンベアリポジトリから、Git サーバのベアリポジトリの内容を fetch。

これによって、以下のメリット。

  • Git ベアリポジトリの管理は、Redmine と別サーバ。
  • でも Redmine サーバ自らの Git ノンベアリポジトリ（クローン）にも、その内容が常時同期される。
  • Redmine は、同一サーバ上の、同期された Git ノンベアリポジトリの内容と連携することで、あたかも Git リポジトリの本体と連携しているように見える。

余談

そんなの GitHub とか GitLab 使えば、Redmine とか要らなくね？

その通り。
GitHub, GitLab で世界が完結できている幸せな方々については、Redmine なんか必要ない。
ぜひともこの話はなかったことにしてほしい。

でも世の中 Redmine をポータルにして運用している組織は沢山いるような気がしたので、記事にした次第。

私的高速移動考（下り線）

東京起点、東名-新東名の話。
まぁ、たまに使うので。

トラック事情

東京というか東京近郊発の物流路線便は、20～23時を中心に配送センターや営業所を出発する。

これは宅配関連であれば、日中集荷した荷物を拠点で仕分けし、長距離便のトラックに乗せるため、この時間となる。
また、工場などでの製造した品についてのチャーター便の場合も、概ね翌午前中着を目標としていることが多い。そのため、やはり20時以降に出発する事が多いと思う。

京阪神までの物流距離であれば、概ねこのスケジュール感で動いているのではないかと。

なので概ね以下の時間帯が混雑しているような感じ。

東京～御殿場⇒２０～２３時
御殿場～富士⇒２１～００時

ちなみに、０～５時頃まで、富士～豊田までの間もトラックはそれなりに走ってる状況。
さすが幹線。

走り難いか？

指定速度以上の速さを出したい「スピード至上主義者」みたいな方々には、トラックの多い新東名は走りにくいと思う。
トラック同士の追越はとても遅いので、それに焦れる普通車は多いのではないかと。
でも巡航してるトラックもそれなりにいるので、ACC使って「流れ」に乗って走るのは楽。

個人的な走り方

深夜時間帯については、第１、第２走行車線はトラックが多く、走りにくいので、結果的に普通車は第２走行車線、はたまた追越車線をずっと走ることになる場面が多い。
というか、それが「暗黙の了解」のような気がする。

走行提案

以降は個人的な意見妄想・戯言です。
あまり気にしないでください（笑）

できれば、こう言った走りをしてほしい。

トラック

過積載・ローリーなどの80km遵守車は第１走行車線必須として、巡航は基本、第１・第２走行車線。
追い越したいときだけ、第２走行・追越車線を走る。

普通車

巡航は第２走行車線、追越用途で追越車線を走る。
追越車線走行中、自分より速度の速い車両が続行してきたら、すぐ第２走行車線に戻る。

IC・JCT・SA・PAなどで流出するとき

流出の3kmほど手前（混雑時は5km手前）から、第１走行車線に移動することを思考する。出口の予告標識に差し掛かる頃までには、第１走行車線に移動。

この時、前方に特大車など低速車がいても焦れないことが大事。

一番危険なのは

雨の中、トラックが混雑している時間帯

これが１番危ないです。あと、トラック同士の追越中とか。
このような状態では危険なので、頻繁な追越はせず、第２走行車線を巡航するようにしています。

浜松いなさ、岡崎SA間

この区間は２車線。
しかも勾配の抑えられている新東名の中でも、周辺景色と２車線の所為か、それなりのアップダウンがあるように見えてしまう区間。
なので、交通量の多い時間帯の追越には気を付けている。

実家弾丸見舞い（練馬⇔三重）

お馴染みの「机上の空論」。
といいますか、検討した備忘録。折角考えたので記事にしてみた。

はじめに

トヨタレンタリースには「片道GO!」プランという激安プランがある。
この利用を考えたスケジュール設定を検討してみた。

ちなみに、元々はワンウェイ利用された車両の回送を、自社や代行業者の自腹でやっていた。（今もそれで回送してる車両もあるはず。）
それを、おそらく「激安料金で貸し出したほうがコスト下がるんじゃね？」という事で始まったのが、このプランなんだと思う

正直なところ、急ぐなら夜行バスでも新幹線でも使うのが良いのだが、荷物牽いて道中移動とか交通費とか時間の融通とかロマンとかなどを鑑みて、レンタカーにしてみた。

ちなみに同様のサービスは、ニッポンレンタカーも開始してる。
それ以外のレンタカー屋さんもやってるかも。

行程

  • 1日目
    • 12:00、トヨタモビリティサービス（往路指定店舗）、往路貸出
    • 14:00、自宅着
    • 22:00、自宅出発、東京IC-東名-新東名-伊勢湾岸道-新名神
  • 2日目
    • 4:00、鈴鹿PA/SIC着、仮眠4h
    • 8:00、出発
    • 9:00、実家着、昼食・買物
    • 13:00、病院着、見舞・買物
    • 16:00、実家戻り、伊勢湾岸道-名古屋高速
    • 19:00、トヨタレンタリース名古屋（復路貸出指定店）、往路返却-復路貸出、名古屋高速-名神-中央
    • 23:00、小黒川PA着、仮眠6h
  • 3日目
    • 5:00、出発、中央-調布IC
    • 10:00、自宅着
    • 12:00、トヨタモビリティサービス（自宅最寄店）、復路返却

【往路】
鈴鹿PA/SICだと行き過ぎるので、本当な長島PAで休憩したいところだが、四日市市内通過の際、確実に渋滞へ巻き込まれる。

【復路】
中央道経由にしたのは、到着時の都心渋滞を避けつつ、ゆっくり帰るため。寄り道設定も可能。
急いで帰る場合は、みえ川越IC-伊勢湾岸道-新東名-東名が一直線ルートだし速い。

メリット

  • 通常レンタカーを借りた場合、コンパクトカークラスで1.2万円なのに対し、「片道GO!」を利用した場合は「往路＋現地移動4.4千円（48h）、復路2.2千円（24h）、合計6.6千円」と、およそ半額で済む。
  • 返却店は管轄地域の営業所であれば、どこでも返却オッケー。

本当は往路も24h貸にしたところだが、そうすると現地移動で利用する時間が不足してしまう（別途、移動の足と調達必要が生じる）ため、ここだけ48h貸にしている。

デメリット

  • 貸出店が選べない。指定店舗まで出向く必要あり。
  • 燃料代は自腹。
    そのため特にハイエースなど大型車を利用した場合、コンパクトカーよりも燃料費がかかるので、レンタカー代が半値で済んでも、燃料代でメリットが削がれる可能あり。
  • レンタカーマイルは利用不可だし、付与もされない。
  • 電話予約のみ。
    そのためトヨタレンタカーメンバーとして（ゴールドメンバーになるため）のカウントも対象外。（だったはず？）
  • 延長・装備オプションは一切できない。
    特に指定場所以外の返却や遅延した場合、正規料金での精算になる。
  • レンタカーのゴールド会員だと、最初から20%引。
    「特割GO!」の「直前割」の場合、最大で40%引の場合もある。
    こうなると、50%引との差額や片道返却などの手間を考えると、正直微妙な気もする。
  • 足かけ３日間なので、確実に疲れる。
    （新幹線利用で日帰りできることを比較して）