-
-
Owntoneでファイルサーバーから音楽を配信する(ユーザーごとに)
Owntoneを使ってユーザーごとにdaapサーバを動かして音楽を共有した話 -
プライベートのタスク管理用にOpenprojectを試す
プライベートのタスク管理を目的にOpenprojectをインストールしてみた話 -
Lightsail上で動かしているDebian BusterをBullseyeにアップグレードした話
今月(2021年8月、投稿時点)Debianの新しいバージョン、Debian 11 Bullseyeがリリースされた。早速試したい1のだが、AWS -
SquidでCertbotの検証用の通信を転送する、なるべくセキュアに
経緯 自宅サーバ上でNextcloudなどのwebアプリケーションを稼働させるにあたって悩ましいのがhttpsをどうするか。 パブリックへは公開 -
Lightsailの初期ユーザ名をデフォルトから変える
デフォルトのユーザ名・鍵に抵抗があるので変えた話 -
リンクローカルアドレスとssh
リンクローカルアドレスでsshするときに躓いた話と対応 -
IPアドレスを決めるのにハッシュ値を使ってみた
Host名などの文字列からハッシュ関数でIPアドレスを生成できるようにし、これをツール化した話 -
WireGuard VPNを利用しVPSを介して外部から自宅サーバへアクセスする
外部からVPSを踏み台にして自宅サーバにアクセスするためのVPNをWireguardで構築する話 -
F600Aを自宅サーバ公開用に設定する
nuroのルータF600Aを自宅サーバ公開用に設定した話 -
自宅サーバの公開に向けてまとめ(更新中)
自宅サーバを公開するにあたっての経緯とやることの一覧など -
NextcloudでBasic認証とクライアントアプリを両立する
NextcloudでBasic認証をするようにしたらクライアントアプリが接続できなくなったので、できるよう試行錯誤した話 -
外部から自宅サーバにアクセスするためMyDNS(DDNS)を利用する
自宅サーバに外からアクセスしたい。そのためにDDNSで家の非固定IPとドメインを結び付けたい。ということでMyDNSを試した話 -
Wordpressの記事を静的サイトジェネレータZoraへ移行する
こちらの記事はQiitaに投降した記事と同一の内容になります
ブログをWordpressからZola(Rust製の静的サイトジェネレータ)へ移行して数か月、自作テーマはテーマは依然として作成途中であるが、とりあえず今のところ問題もなさそうなので、重い腰を上げて旧ブログの記事を移行することにした。
具体的な工程としては以下
- Wordpressの記事をSSG用のテキストファイルへ出力
- 記事ファイルの整理
- フロントマターをZola用のものに修正
- リンクなど記事内の情報の修正(これは今回の記事では扱わない)
前提
移行前の環境
ブログプラットフォームでおなじみのWordpress ブログから大規模サイトまで作れる CMS | WordPress.org 日本語
多言語用にサブディレクトリ型のマルチサイトを使用
本記事の工程でも多言語、マルチサイト用の余計な工程ががかかってる。シングルサイトならもっと楽。
移行先の環境
静的サイトジェネレーターZolaで生成 Zola
今回はZolaだが、移行の手順の流れや考え方自体は他でも使えるのではないかと思う。
手順1: WordpressからSSG向けの形式への出力
Zola用のツールがあるとは思えなかったので、ほかにメジャーなSSGであるところのHUGO用のツールを探す。
puluginのインストール
SSHでサーバーに入り、以下のようにプラグインを入れる
$ cd /path/to/wordpress/wp-content/plugins/ $ sudo wget https://github.com/SchumacherFM/wordpress-to-hugo-exporter/archive/2.0.0.zip $ sudo unzip 2.0.0.zip
自分のケースでは
sudo
が必要だったが共有してるタイプのレンタルサーバーならHOMEディレクトリ以下にあると思うので、sudo
しなくてもいい。次にWordpress上の画面で対応
プラグインを有効化し… {{image(src=“activate.png”, alt=“有効化!”)}}
エクスポート {{image(src=“export.png”, alt=“エクスポート!”)}}
中身の確認
なぜか一部のマークダウンがAtomにディレクトリ扱いされて読めないというイレギュラーがあったが、VSCodeでは開けたのでそのまま続行する。 Atom最近使ってなかったから更新されてなくてバグってたのかもしれない。
Hugoならこれで終わりかもしれないが、今回は別のSSGなので、ここからが本番。
手順2: フォーマットの修正
正直今回のケースでは記事が少ないので手動修正のほうが早かったのだけれど、せっかく記事にするなら役に立つ記事にしたいというのと、bashを学ぶちょうどいい機会ということもあって、極力bashで一括でやれるようにした
ファイルの移動
出力時のディレクトリの構造としてはこんなかんじ
- hugo-export
- about
- index.md
- posts
- yyyy-mm-dd-slug1.md
- yyyy-mm-dd-slug2.md
- etc
- wp-content
- config.yaml
- about
posts内のファイル名は
投稿日-スラッグ.md
という形式だったaboutが固定ページで、ほかの投稿はpost配下に日付-スラッグという形式で入っている模様。
補足: config.yamlと固定ページについて
config.yamlはサイトの設定だが今回は移行先のブログはすでにあるので使わない また、固定ページは1件しかなかったのと内容を更新するつもりだったので後述の自動処理では扱っていない。
これが日本語と英語と2組ある(英語は英語勉強したい気分の時にしか にある
まずはこれを移行先の構造に合わせ以下のようなレイアウトに移動したい
- content
- post
- slug1
- index.md
- index.en.md
- slug2
- index.md
- index.en.md
- 略
- slug1
- post
一括処理用にBashを書く
最終的に出来たのがこれ
ROOT=${PWD} # hugo-exportの親ディレクトリで実行することを想定。 SRC="$ROOT/hugo-export/posts" # 移動元のディレクトリ DST="$ROOT/content/posts" # 移動先のディレクトリ cd $SRC for $FILE in *.md do LEN=$((${#FILE} - 14)) # スラッグ未設定の場合は日付だけだったので、判別する。 if [[ $LEN -eq 0 ]]; then AFTER="$DST/${FILE:0:-3}" # 日付だけの場合は仕方がないのでとりあえずそのまま移行する。 else AFTER="$DST/${FILE:11:-3}" # スラッグがある記事については日付を取り除く。 fi mkdir $AFTER echo "$FILE to $AFTER" cp "$FILE" "$AFTER/index.md" # 英語記事を移動するときはここだけ変える done
これでだいたい移動ができた。
誤算だったのは下書きで、slugがファイル名にもフロントマターにも反映されていなかった。原因が下書きだからかスラッグが未入力だったからか? とはいえブログを移行して数か月という状況で、旧ブログに残っていた下書きの必要はなさそうなので、気にせず続行する。
フロントマターの修正
Hugo-exporterはその名の通りHUGO用なので、Zolaとはフロントマター(ワードプレスで言うところの記事名とかスラッグとか、要は本文以外の情報が書いてるとこ)の書式が違う。 具体的に言うとHugo exporterの出力形式だとフロントマターはYAMLだが、ZolaはTOMLというのを使っているらしい。
出力時が以下
-
Nextcloudのセキュリティ&セットアップ警告の解消
本記事はQiitaに投稿した記事と同一の内容となります。 経緯 半年前にサーバーの移転に伴ってNextcloudも引っ越ししたのだが、いくつかエ -
サーバーの移行について(2019年末/2020年始)
ドメインを移行したついでにサーバー自体をレンタルサーバーからAmazon Light sailに移行した。
-
Nextcloudを試す
ファイル共有兼同期できるメモ帳としてNextcloudを導入したら思ったよりもいろいろできて感動した話。
-
ファイルサーバのOSをmanjaroに移行する2 (サーバ設定移行編)
前回の記事の続き。
サーバのOSを入れ直しに伴いバックアップと再設定をした。 -
ファイルサーバのOSをmanjaroに移行する1(Manjaroのインストール)
これまでUbuntu19.04で運用していたファイルサーバが、アップグレードに伴いなぜか自動でサスペンドするようになってしまった。
非常に不便なので早急になんとかしたかったがざっと調べても同様の事例が見つからなかったので、諦めてクリーンインストールすることにした。ついでに興味があったManjaroにOSを変えることにした。
-
Ubuntu 19.04 Server をLAN経由で起動できるようにする (Wake-on-LAN)
引数として先程のMACアドレスを使って## 経緯
節電のためにファイルサーバを平日の昼間サスペンドさせることにしたのだが、そうすると祝日の平日に手動でサスペンドを解除する必要がある。
コレ自体は仕方ないとして、せめて電源ボタンではなくメインマシンからLAN経由で遠隔で電源を入れられるようにしたい。
調べたところWake-on-LANというそれらしい機能があったので利用する -
自作NAS (ubuntu 19.04) を平日の日中のみサスペンドさせる
経緯
自作のファイルサーバがあるのだが、平日の日中は当然使われていない。
にもかかわらずつけっぱなしなのもどうかと思うので、そのあいだサスペンドするようにする調べたところ、 時間を指定してサスペンド、一定時間後の復帰をさせる
rtcwake
と
定期的にコマンドを実行させるcrontab
を使えば行けそうなので設定してみる。 -
Ubuntu Server 19.04 に ZFS を導入しRAID1を構成する
経緯
PCを自作NASに移行して半年弱、当時は予算の関係で保留にしていたが、そろそろHDD買い足してバックアップなども万全にしたい
当初はファイルシステムは無難にext4、マザーボードの機能でRAID1を組むつもりだったが、いろいろ調べた結果ZFSというファイルシステムを導入することにした。