データ整理

COVID-19の外出自粛で家に籠っているので、懸案のデータ整理。長年(20年以上)ファイルサーバにためこんで、マシンを入れ替えても整理することなくディスクの肥やしになっていた各種ファイルを片づける。

1.5TBの領域をもったファイルサーバスペースの75%が占有されている。

大きな容量を占めているのが、自動・手動で録りためたテレビ・ラジオ・その他のビデオ、オーディオファイル。数百GBくらいある感じ。

いつか視聴するかもしれないので一律削除もしたくないし、中身を確認検討する暇もないので、一応はジャンル分け・分類してAWS S3に保管する。

とはいえ千時間を超えるビデオ、オーディオをいつか視聴する日が来るのか、暇ができるのか。老後の娯楽に、とか?もう残された時間はあまりないので、過去を振り返るのに時間をかけるのもどうかとは思う。

ダウンロードしたアプリインストールファイル、古いバージョンのrpm、そういうのはもう使わないだろうし必要になったらどこかのリポジトリで見つければいい、と考えて削除するのだが、それに該当するのかを確認するのに時間がかかる。

なくしたくないのが家族や旅行時の写真、動画。家族の作った作品で本人がメンテしていないもの。こちらは慎重になる。二重三重にバックアップしていたりして、重複チェックがまた大変。

ISP二社で使い分け

メインのISPはOCNを利用していて、それと別にIPv6のトンネリング用にInterlinkのZoot Connectで固定IPを取っていたのだがv6以外に何も使ってなかった。最近OCNが異常に遅く、特に午後から深夜にかけてping 8.8.8.8が40msとか大きな遅延。みんな在宅ワークでネットつかってるのか、外出自粛で動画みてるのか知らんが、ネットが遅いのは困ったもんだ。

しかしすぐにISP乗換というのも面倒というか能がないしどこがいいか調べるのも面倒なので、ISP二社を使い分けることを考える。フレッツ光の2セッション使い、ルータ二台(Cisco 1812JとFortigate 50B)で別々につないでいたが、ルーティングを考えて切り替える。

HOMELANのデフォルトはCiscoルータ(192.168.1.254)に向いていて、OCNにはそのルータのDialer1(PPPoE)でつながっている。FortigateのInternal Interfaceは同じセグメントにあって(192.168.1.247)、WAN InterfaceからInterlinkへPPoE接続、従来IPv6用のHurricane*他ごく少数の宛先だけCiscoルータ上でstatic routeを切っていた。

Ciscoルータ上にstatic routeを追加、IP SLAでtrackingして、OCN経由での遅延が10msを超えたらInterlinkに切り替える。

Cisco Routerのコンフィグ

track 9 ip sla 2
ip sla 2
 icmp-echo 8.8.4.4 source-interface Dialer1
 threshold 10
ip sla schedule 2 life forever start-time now

ip route 0.0.0.0 0.0.0.0 Dialer1 track 9
ip route 0.0.0.0 0.0.0.0 192.168.1.247 10
ip route 0.0.0.0 0.0.0.0 Null0 255
ip route 8.8.4.4 255.255.255.255 Dialer1


Dialer1からGoogleDNS 8.8.4.4への遅延をみて、10msを超えたらInterlink側へデフォルトルートをふる。

とりあえずうまく切り替わる(いきなりInterlink側に切り替わってるし)ようなので24~48時間様子を見る。

gw1812#sh track 9
Track 9
 IP SLA 2 state
 State is Down
  32 changes, last change 00:17:56
 Latest operation return code: Over threshold
 Latest RTT (millisecs) 11
 Tracked by:
  STATIC-IP-ROUTING 0
gw1812#sh ip sla config 2
IP SLAs, Infrastructure Engine-II.
Entry number: 2
Owner:
Tag:
Type of operation to perform: icmp-echo
Target address/Source interface: 8.8.4.4/Dialer1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Verify data: No
Vrf Name:
Schedule:
 Operation frequency (seconds): 60 (not considered if randomly scheduled)
 Next Scheduled Start Time: Start Time already passed
 Group Scheduled : FALSE
 Randomly Scheduled : FALSE
 Life (seconds): Forever
 Entry Ageout (seconds): never
 Recurring (Starting Everyday): FALSE
 Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 10 (not considered if react RTT is configured)
Distribution Statistics:
 Number of statistic hours kept: 2
 Number of statistic distribution buckets kept: 1
 Statistic distribution interval (milliseconds): 20
History Statistics:
 Number of history Lives kept: 0
 Number of history Buckets kept: 15
 History Filter Type: None
Enhanced History:


gw1812#sh ip ro | inc 0.0.0.0/0
S* 0.0.0.0/0 [10/0] via 192.168.1.247



(*: IPoEでネイティブIPv6が使えるはずなのにうまくいってなくていまだにトンネル使ってる)

ZeroTierでVPN

ながらく書いてなかったが何もやっていなかったわけではない。 今日はZerotierというVPNの仕組みを見つけたので試してみる。 OSSの有料プロジェクトだというのだがFreeプランがあるのでそれで。

アカウント作成

ログイン画面からCreate An Accountを選べばいいらしいのだが、Windows版のソフトをインストールして起動したら自動的にアカウント作成が要求された。

ソフトウェアのインストールと起動

ダウンロードサイトの通りといえばそれまで。Windows 7, iphone, Linux CentOS7.1, Linux Ubuntu LTS16.04(それぞれVMwareとかGCP, Tencent cloudの仮想マシン)にインストールして使ってみる。 あっけないくらいに動くので何か書いておくこともないが、自宅の場合はFirewallに変更を加えて外向きUDP/9933を開けておく必要がある。 とりあえずpingだけだが、 自宅(日本, OCN) / US LAX (GCP) / 上海(Tencent Cloud)から接続して通ることを確認

RTD

From To RTD (ms)
iPhone(OCN Mobile One)Home(OCN)112
Home(OCN)LAX(GCP)117
Home(OCN)SHA(Tencent)199
LAX(GCP)SHA(Tencent)202

imaputils

imapに何万通も溜まっていて、整理をどうするか悩んでいたのだが、imaputilsというツールがあるのを発見。検索してまとめて移動、削除ができるので便利。 とりあえずどうでもいいメール約19万通を削除した。 https://sourceforge.net/projects/imaputils/files/?source=navbar

E-mail整理

仕事(会社)のメールの問題。過去3年程で10万通くらいある。どんどん削除する人もいるが、いついるかわからないからSPAMも含めて全部保管。OutlookにPSTフォルダを作って毎日整理するほか、3ヵ月(四半期)毎にPSTを新しくして過去のものはアーカイブする。

なにせSubjectすら書き直さないで「こんな事件があったから、今日から新しい承認手続きを実施する」なんてメールが流れてくる。じゃあ明日入社した人はこの通達をどこで知ればいいというのか。

3年も前に流れた通達に従って「お前のやってることはルール違反だ」などと言われる。

5年前に実施した設計変更が、正しくインプリされていなかったことが発覚、誰のエラーなのか、とか追及される。

それどころかほんの1週間前に依頼したことも忘れていて、返事がないのに気が付き、督促を送ろうにも元の依頼メールが見つからない。

というわけで自分だけでも過去メールをすぐ取り出せる仕組みを作っておかないと、危なっかしくて仕事できない。

今検討、用意しつつある仕組みは、メールを一か所にあつめてMaildirフォーマットで保管、MU (http://www.djcbsoftware.nl/code/mu/) で検索する仕組み。いくつかブログ記事をみると検索性能も高いしmu4eなら検索して読むのが便利そうでいい。

まずは過去メール(Outlook PST)をMaildir形式にして集めないといけない。

File Server (samba + AWS S3)

手元のLinuxでSambaを動かし、そのディスクにAWS S3をマウントする。巨大なファイルサーバーが出来上がる。

ディスクの故障も心配しないでいいし、容量は無限(1PB)だし、いい感じ。

東京リージョンで遅延もそこそこ。

しかし小さいファイルを大量にコピーしようとしたらスループットが極端

に下がる。Steelheadでも入れたいところだな。