2020-05-31

バックアップに Nextcloud クライアントと B2 Cloud Storage を使うのはやめた方がいいかも

サーバー側の Nextcloud と B2 Cloud Storage を合わせるのは多分問題ないと思う。
問題なのは Windows 側に入れる Nextcloud クライアントで、こいつの挙動がもうマジ謎すぎる。

少量のファイルで試している間は何ともなかったけど、
B2 側にドーンともの入れるとなんかもう同期を頑張りすぎてチェックしまくるわなんやでやたら遅い。
Explorer を透過的に扱えるのでまぁいいかと思っていたがさらに面倒な問題があって B2 上にすでにアップロードしたファイルを取得しようとするのがもうマジむり。
初回バックアップなので通信回数も多くなるのはしゃあなしでアップロードのため API のキャパ増やしたりはまぁ許容できる。
できるんだけどなんでダウンロードのキャパ増やす必要があるのかと。
いやー、これはちょっとしんどい。GB データをダウンロードしだしたときに諦めた。

ただ B2 連携せずサーバー上に直接ファイル送ったりする連携はなかなかきれいに動いてくれたので恐らく外部ストレージの扱いがうまくないんだと思う。
重ねて恐らくだけどサーバー側 Nextcloud は外部ストレージをうまく扱えてて、Nextcloud クライアントがサーバー側ストレージ情報を知らずに処理しちゃってる感がすごい。

なので今のところの運用はでっかいバックアップ分は rclone で B2 に飛ばす、
ちょっと頻繁っぽいデータは Nextcloud クライアントから サーバー側 Nextcloud のディレクトリに飛ばすようにした。

あれこれテストしまくったっていうのもあるけどここ1日で $1 は使ったよ。疲れたよ。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2020-05-30

バックアップ体制を Nextcloud と B2 Cloud Storage で構築した

先週メイン使用のデスクトップが死んでついでにデータ用のHDDがすべて死んだ悲しみを繰り返さないためにバックアップ体制を構築した(というかデータが主に悲しみの原因)。
まず OS の載っているストレージについては正直どうでもいいのでバックアップはできたらいいな程度に考え、データ用のストレージ冗長化を主眼に置いた。

手っ取り早くは NAS 買ってきてそこにデータ突っ込むというのが無難だと思ったけど電源つけっぱなしは精神的にしんどいし毎回電源ON/OFFするのも気持ちしんどい。
なので外部(インターネット越し)に配置したいと思ったが選択肢が多くてあれやこれや考えた結果、B2 Cloud Storage を選んだ。

B2 Cloud 自体はブラウザで開いてアップロードしたりできるがどうにも面倒なので Windows Explorer 上の OneDrive みたいに透過的に扱いたかったのでクライアントソフトを探したが
よくわからん + データ喪失の悲しみであんまりやる気ない状態だったので手っ取り早そうな Nextcloud クライアントソフトを使用することにした。
B2 Cloud は S3 互換の API を扱えるので S3 を扱える Nextcloud(サーバー側) にストレージ整理を任せて、Nextcloud クライアント側に Windows との連携を任せることにした。

B2 Cloud Storage を使用/ストレージの作成

まずは https://www.backblaze.com/b2/cloud-storage.html にアクセスしてアカウントを作成する。

B2 Cloud Storage (以下 B2) はカード情報がなくても 10 GB まで保存できるので動作確認・使用感を得るには都合がよい。なによりカード入力しなくても試せる安心感がすごい。

サインインしたら Nextcloud とやり取りさせるために設定を行っていく。
  1. [メニュー] Bucket
    1. Create a Bucket
      1. バケット名は適当に入力（入れるデータに合わせた名前）
      2. 公開範囲も適当に設定（バックアップの意味合いから private が普通だと思う）
  2. [メニュー] App Keys
    1. Add a New Application Key
      1. キー名を適当に入力
      2. 対象バケットの選択で API キーを制限しないなら ALL 、バケットごとに制限するなら対象を選択
      3. アクセス権限を All に設定
      4. その他オプションは必要な入力
      5. 出来上がった API キー の Secret をメモっておく
これで B2 の準備は完了。

Nextcloud のインストール

すでに使用可能な Nextcloud が存在すればこれは不要。

ここでは Nginx の稼働している CentOS8 を対象として、 snap を用いる。
Nextcloud 自体を直接動かしたいなら止めはしないけどやりたいのはバックアップであって Nextcloud の世話ではないので保守は snap に任せる。

# dnf install snapd -y
# systemctl start snapd
# snap install nextcloud
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not restarted your session
         since you installed snapd, try doing that. Please see https://forum.snapcraft.io/t/9469
         for more details.

これでインストールは完了。
ただこの時点ではまだ起動していないし、PATH に追加された内容も反映されていないのでいったんログアウトするなりして PATH を最新化する。

次に Nginx のリバースプロキシ設定を行う。
適当なディレクティブに適当に設定値を入力。

http {
...
# アップロードサイズの変更
client_max_body_size 5g;

...

server {
...
# リバースプロキシとして動作させる
location /<NextcloudのURLパス> {
rewrite ^/<NextcloudのURLパス>(.*) $1 break;
proxy_pass http://<Nextcloud稼働IPアドレス>:<Nextcloudのポート>;
}
...
}
}

# systemctl reload nginx

これで Nginx 側の設定ができたので Nextcloud を構築していく。

# snap set nextcloud ports.http=<Nextcloudのポート>
# nextcloud.manual-install <ログインユーザー名> <ログインパスワード>
# nextcloud.occ config:system:set trusted_domains 1 --value=<リバースプロキシホスト>
# nextcloud.occ config:system:set overwritehost --value="<リバースプロキシホスト>"
# nextcloud.occ config:system:set overwriteprotocol --value="<リバースプロキシプロトコル>"   ※ http / https のどっちか
# nextcloud.occ config:system:set overwritewebroot --value="/<NextcloudのURLパス>"
# nextcloud.occ config:system:set overwrite.cli.url --value="<稼働プロトコル>://<リバースプロキシホスト>/<NextcloudのURLパス>"

これで設定OKなので <稼働プロトコル>://<リバースプロキシホスト>/<NextcloudのURLパス> にアクセスする。
※起動してなかったら起動しておくこと (多分 -> # snap start nextcloud )
※同一ホスト内だと selinux 周りで死ぬかも(一応の対応 -> # setsebool httpd_can_network_connect on -P )

Nextcloud の設定

  1. とりまログインしたら右上のアバターアイコンから アプリを選択
    1. 「External storage support」を検索して有効にする
  2. 右上のアバターアイコンから 設定 を選択
    1. 左メニュー 管理欄 の「外部ストレージ」
      1. 「フォルダー名」を適当に入力
      2. 「ストレージを追加」から「Amazon S3」を選択
      3. 「バケット名」に作成したバケット名を入力
      4. 「ホスト名」にバケットのEndpointを入力
      5. 「ポート」は空白
      6. リージョンに バケットのEndpoint のリージョンっぽいのを設定
        • s3.us-west-002.backblazeb2.com なら us-west-002
        • 作業中にどこかのページで見て知ったけどURL失念
      7. 「SSLを有効」をチェック
      8. 「パス形式を有効」をチェック（なんのこっちゃ知らん）
      9. 「レガシー認証(v2)」は非チェック
      10. 「アクセスキー」に作成した API キーの「keyID」を入力
      11. 「シークレットキー」に作成した API キーのメモしておいた Secret を入力
      12. ✔ をクリック

構築完了

これで Nextcloud と B2 を連携が完了する。
あとは Nextcloud クライアントを PC にインストールして連携すればOK。


  • B2 を使えば無料+カード情報なし(電話番号は必要)で 10 GB まで扱える
    • API 使用に関してもある程度まで同じ
  • 10 GBを超えたい、API使用数を増やしたいと思うまで無料運用可能
  • B2 連携した場合 Nextcloud 上にファイルは格納されない(一時ファイルは知らん)
  • 良い点
    • 意外と速度が速かった
    • Nextcloud クライアントアプリがアップロード失敗時に自動リトライ処理してくれる
    • Nextcloud クライアントアプリがリネームも検知してくれる
      • B2 側にも一応対応してくれてるっぽいけど遅い(?)
  • 悪い点
    • B2 提供サイト backblaze は右下で言語変えれられるけど機械翻訳で完全に何言ってるのかわからないサイトになるので素直に英語表示した方がいい

  • まだ分かってないところ
    • クライアント側未ダウンロードでアイコン表示が可能か
      • 絶対ダウンロードされる？ 試してないから知らんけど
    • Nextcloud による API 使用料がちょっとまだ読めない
      • 時間がたてばどれくらいっていう目測ができるようになると思うけど導入したばっかなのできつい



投稿者 時刻: 0 件のコメント:
ラベル: , ,

2020-05-24

とりあえずメインPCを買った

一旦デスクトップPCを買うことにした。というか買った。
多分今回買ったPCがデスクトップ端末としては最後になると思う。

旧端末はOSがSSDで、それ以外のデータがHDDに入っていたけどなんかHDDも全滅してるっぽくて心折れまくる。
リカバリソフトでデータ見れたから頑張れば復旧できそうな気がしないでもないけど稼働してるノートPCのストレージが500GBしかないから新端末が来たら復元試してみる。

ここ最近NASとかクラウドストレージでデータ管理していこうかなーと思っていたんだけどその矢先にこれはきっつい。
投稿者 時刻: 0 件のコメント:
ラベル: ,

メインパソコンこわれる

ブート領域が壊れたっぽい。

もろもろ手順を試したがダメっぽかったので再インストール中。
この記事はノートPCで書いてるけど、なんかデスクトップでどうこうするのも疲れてきた感ある。

修復の可・不可によらずそろそろメイン端末を買い替えたいと思ってたところではあるし手持ちの機器類を整理しておきたい。

前にも壊れてるし、四年そこらが耐久限界なんかね。五年くらいはいけると思ってたけどなー。
投稿者 時刻: 0 件のコメント:
ラベル:

2020-02-29

Pe 0.87.001

致命的にバグってたので緊急リリース。
コマンドライン引数が設定されていない場合に ps1 実行で死んでいた。

しんどい。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2020-02-26

PowerShell AA Pe 0.86.0 版

こーいう配列があって、
9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 1, 1, 1, 0, 0, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 2, 2, 9, 2, 2, 9, 9, 9, 2, 9, 9, 2, 2, 2, 9, 2, 2, 2, -1
9, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 3, 2, 9, 2, 3, 2, 9, 2, 3, 2, 9, 3, 2, 3, 9, 2, 3, 3, -1
9, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 9, 9, -1
9, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 9, 2, 9, 2, 9, 2, 2, 2, 9, 2, 9, 2, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 2, 2, -1
9, 1, 0, 1, 0, 0, 0, 1, 1, 1, 0, 1, 9, 2, 9, 2, 9, 2, 3, 3, 9, 2, 9, 2, 9, 2, 2, 2, 9, 9, 2, 9, 9, 2, 3, 3, -1
9, 1, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, 9, 2, 9, 2, 9, 2, 9, 9, 9, 2, 9, 2, 9, 2, 3, 2, 9, 9, 2, 9, 9, 2, 9, 9, -1
9, 1, 0, 1, 0, 0, 0, 1, 1, 1, 0, 1, 9, 2, 2, 2, 9, 2, 9, 9, 9, 2, 2, 3, 9, 2, 9, 2, 9, 9, 2, 9, 9, 2, 2, 2, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 3, 3, 3, 9, 3, 9, 9, 9, 3, 3, 9, 9, 3, 9, 3, 9, 9, 3, 9, 9, 3, 3, 3, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, -1
こー言う処理に食わせて
foreach ($dot in $appIcon) {
    switch ($dot) {
        0 { Write-Host '   ' -NoNewline -ForegroundColor White -BackgroundColor White }
        1 { Write-Host '|||' -NoNewline -ForegroundColor Black -BackgroundColor Black }
        2 { Write-Host '===' -NoNewline -ForegroundColor Red -BackgroundColor Red }
        3 { Write-Host '---' -NoNewline -ForegroundColor DarkRed -BackgroundColor DarkRed }
        9 { Write-Host '   ' -NoNewline }
        -1 { Write-Host '' }
    }
}
こーなる











こういう実装中の暇つぶしは好きです。。。
投稿者 時刻: 0 件のコメント:
ラベル:

2020-02-25

Pe 0.84.0 リリースで分かったこと

  • まぁ動くだろ的なノリで適当にリリースするとやっぱ泣く
  • Nuget から落としてきたライブラリでも依存ライブラリがある
    • CefSharp が Microsoft Visual C++ 再頒布可能パッケージ が必要なのを完全に見落としていた
    • 見落としていたというかまっさら Win7 で動かなかったのを .NET Core のなんかだろと軽視していたツケ
    • VSで開発してるからライブラリあって当たり前でまったく気にならなかった
  • 自環境でダウンロード検証したが、帯域絞るなりしてみた方がよかった
    • 0.83.0付属のアップデート処理機能だと落としきる前にタイムアウトしてるっぽい
      • これに関してはもうどうしようもないが、リリースノートの差し替え差し替えでぐっだぐだ
  • もうまじ💩
投稿者 時刻: 0 件のコメント:
ラベル: ,

2020-02-24

Pe 0.84.0 リリース！

Pe を .NET Framework から .NET Core に変更した。
以下文書は酔っぱらいながら書いてる🍶。

移行に当たり git log を確認すると諸々の流れはこんな感じ
  1. 2017/06/11 0.83.0 リリース
  2. 2018/11/19 バージョンアップに着手
  3. 2019/01/06 バージョンアップ諦め
  4. 2019/03/02 バージョンアップに再着手
  5. 2019/06/08 バージョンアップ再諦め
  6. 2019/08/20 バージョンアップに再々着手しつつ .NET Core に唾を付ける
  7. 2020/02/24 .NET Core にて 0.84.0 のリリース
まぁ色々あった。

.NET Framework から .NET Core への移行

まぁ気になる人はこれだと思う。
基本的には問題ない、と言いたいが対象ユーザー層との相談が必要になると思う。

サーバーサイドならなんも考える必要はないけどデスクトップ界隈ならば、
  • 対象端末に .NET Core ランタイムはあるか
  • ランタイムがないのであれば自己完結型で💩レベルに膨れ上がるバイナリを許容できるか
なのでこれを解決する必要がある。

Pe の場合、これは自己完結型でユーザー許可を取らずにぶち込んだ。
ただこれも見映えの話で、自己完結型だと DLL が山ほど出力されるのでユーザーがなんも考えず EXE を起動できる必要がある。
(ユーザー目線で見ると .NET Core 自己完結型の EXE 探してダブルクリックとか結構な無理がある)
Pe では自己完結型の出力先を <Pe>\bin\ にして必要な諸々を bin ディレクトリに委譲したうえでユーザー操作では <Pe>\Pe.exe (と互換性保持用の PeMain.exe)だけに限定した。
起動順序として Pe.exe -> bin\Pe.Main.exe となる。
せっかく .NET Core(C#) で作ってるのにこの起動アプリケーションを C で作るというなんかもう何してんのか分からないことになっているしコマンドライン引数の再受け渡しでさらに何してんのか分けわからんことになってる。
プログラマー様に渡すならどうでもいいけど配布プログラムになるとこうするのが妥協案として一番まともだと思う。

ちなみに UI 系のものはことごとく捨てた。
UI 系ライブラリの .NET Core 対応を待つのもバカっぽいのですてた。
※ .NET Framework 版の .NET Core 上での再使用はなんとなく嫌だったので除外
これに関しては現行(.NET Framework)版の UI 充実度に左右されると思うので .NET Framework ライブラリ を .NET Core 上で動かすのが最適解だと思う。

ていうかサーバー用途じゃなけりゃ .NET 5 になっても MS が互換レイヤー用意するだろうから Windows だと無理くり .NET Core 自己完結型 にする必要ないと思う。

ブラウザに関して .NET Core に移ってまで WebBrowser に心ポキポキ折られると心が持たないので CefSharp を入れたがこれもまたサイズがでっかい。
まぁ .NET Core 自己完結型の中だと誤差だよ、誤差。

リリースに関して

これもうアップデート処理が出来たからリリースしましたとしか言えない。

.NET Core だと 1 exe で MB 単位の EXE 出来上がるのでこれのためにアップデート用 EXE に切り分ける選択肢はなし、本体側で実行できないと💩状態。
.NET Framework でもそうだったけど、 EXE を殺すのはどうでもよくて依存 DLL があるとなんもできなくなるのでこれを実現するためにいろいろ考えた結果 Pe.exe(Pe.Main.exe) から powershell を呼び出して呼び出し先で渡された Pe の PID 終了を待つようにした。

正直一番ましな方法だと思ってる。
ちなみに pwsh を優先して、なければ powershell を呼び出すようにしてるから多分どこでも動く。
これに関しては bat でも何でもよかったけど、 win10 なら bat でも ps1 でもなんでも動くだろっていう安直な想い。

PowerShell

  • Pe の可動部分(アップデート周り)では PowerShell の命令に限定している。
  • ビルドスクリプトは .NET の処理使ったり好き勝手やってる。
ビルド環境(おおよそ CI 環境)は開発者側で何とでもなるのでどうでもいいが、
アップデート環境 = リリース版 = 知らない人 の環境なのでここで動くシェルスクリプトっぽくでコマンドプロンプトより高機能で bash よりどこでも動くとなるともう PowerShell しかないのでこれでやるのが現状最強だと思う(ver 5 だけに限定するなら特に)。

.NET Core(3) への移行について

  • .NET Framework から移行するのは簡単
    • ただし移行だけに専念して .NET Core にまつわるロジック変更以外は何もしない方がいいと思う
    • Pe の場合、組み直し中の .NET Core 移行だったのでかなりしんどかった
  • (非プログラマの)ユーザーがクッソ重いバイナリを許容してくれてクッソ多いファイルから EXE を見つけてくれるなら .NET Core に移行してもいいと思う。無理なら何かしら解決策を提示する必要はある
  • プログラム組む側の人間なら移行していいと思う。たのしい！
  • プログラム組まない人間であれば情シスが .NET Core って言って来たら工数を要件と確認した方がいいともう。さらに言えば 1.5 倍にした方が安全だと思う(はまると死ぬ)

結論

うちは好きにしたけど君はまぁ頑張れ。

2020/02/25 12:00 追記

0.83.0 -> 0.84.0 の自動アップデートがたぶんタイムアウトかなんかで無理な可能性あり。
俺んちではできたけど会社ではだめだった。
0.83.0 までは軽量だったから問題なかったんだろうね、手動だ手動。


投稿者 時刻: 0 件のコメント:
ラベル: , , , ,
登録: 投稿 (Atom)