Про адміністрування блогів Gemini
Оскільки надаю перевагу децентралізації, мій блог розміщено на різних платформах і мережах. Щоб не синхронізувати все вручну, для автоматизованих релізів, я користуюсь певною інфраструктурою проєкту на базі скриптів з публікації оновлень на всі дзеркала одночасно.
Цей огляд стосується адміністрування статичного формату файлів, CMS я не користуюсь принципово.
Редагування
Тут в мене все типово для програміста: редактор коду VSCodium з плагіном gemini-improved:
Щоб переглянути сторінку в форматі Gemtext до її публікації, я просто відкриваю локальний файл у браузері (Yoda або Lagrange). Були думки зробити редактор GTK з прев'ю, але поки не доходять руки.
Публікація
Git
Цей блог має локальний та публічний апстрім-репозиторії, де зберігається історія змін:
Хостинг
Окрім Git/HTTP, сайт публікується на безкоштовному хостингу Yesterweb:
Також планую додати ще одне дзеркало на платформі Flounder, де є вбудований агрегатор оновлень:
- утім, досі (і вже не вперше) очікую на підтвердження облікового запису
Віднедавна, організував для анонів локальне дзеркало в мережі I2P:
Стосовно самої зв'язки Gemini+I2P, рекомендую наступні матеріали:
Повний перелік дзеркал актуалізується тут:
Синхронізація
Донедавна, для відвантаження файлів на віддалені сервери, користувався такими плагінами:
Але згодом, втомився від глюків розсинхронізації потоків VSCode. Мені потрібно було ходити на кожен сервер і вручну перевіряти чи не заглючило відвантаження певного файлу: іноді URL матеріалу підмінявся індексним файлом та відбувалась всяка інша містика, властива плагінам на JS.
Щодо хостингу Yesterweb - в мене є окрема нотатка, де я пройшов довгий шлях до поточної моделі релізів:
- внизу є приклад скрипта, яким користуюся й досі; нижче коротко опишу, як він працює
Скрипт bash
Актуальна версія скрипта є в репозиторії блогу, продублюю поточну його версію з коментарями:
#!/bin/bash # базові змінні конфігурації деплойменту, # що залежать від конкретного проєкту, відносно якого знаходиться цей скрипт SRC="public" ZIP="ps.zip" # створення архіву файлів для завантаження # використовується для офлайн читання та як додатковий бекап # таким чином, юзерам не потрібно грабати сайт різними скриптами типу gemini-dl echo "snap $SRC > $ZIP ..." cd $SRC rm $ZIP zip -r -9 $ZIP ./ cd ../ # реєстрація змін в локальному репозиторії та публікація в апстрім # якщо перед виконанням скрипта не робити ручний коміт з коментарем, # для цього коміту буде використовуватись поточна дата у форматі UT echo "update repository ..." git pull git add . git commit -m "$(date +%s)" git push # синхронізація дзеркала I2P/SFTP echo "update remote host (localnet) ..." rclone sync $SRC localnet:ps/public --update -v # синхронізація з хостингом Yesterweb/WebDAV echo "update remote host (yesterweb) ..." rclone sync $SRC yesterweb:/ --update --no-check-certificate -v # тут планую додати Flaunder/FTP (та інші хостинги) # ...
Конфігурація rclone
В скрипті вище можна побачити, що в останніх рядках використовується rclone. Спочатку я користувався легким rsync, але згодом перейшов на більш функціональний інструмент з підтримкою WebDAV - rclone.
Щоб описаний вище скрипт міг відвантажувати файли, потрібно спочатку викнути усі додатки синхронізації для поточного проєкту VSCode (SFTP і WebDAV) і налаштувати локальний профіль rclone (власне як і git). Налаштування профілів rclone відбувається командою:
rclone config
- і далі відповідаємо на питання
На замітку, лишу тільки нотатку стосовно специфіки налаштування Yesterweb/WebDAV.
Після реєстрації на цьому хостингу, можна побачити наступний текст вітання з подробицями підключення:
Success!
>
Your account has been created. You may now access your page from gemini://<username>.cities.yesterweb.org/
>
To edit your site, connect via WebDAV
Hostname: cities.yesterweb.org
Port: 1994
Encryption: SSL/TLS
Username and Password are the same as the ones you just set
(username must be all lowercase!)
>
OR
>
Use our gemini/titan file manager
Over here!
Отже, коли конфігуруєте rclone, потрібно обрати WebDAV, вказати у якості логіну ваш юзернейм Yesterweb і наступний "host" у форматі URL:
https://.cities.yesterweb.org:1994
- як бачимо, цей рядок повинен містити схему https (замість davs), <username> і не типовий порт 1994
Дерево файлів
Я довго експериментував зі структурою дерева, але врешті зупинився на такому варіанті:
- створюю кореневу теку проєкту для VSCode
- додаю в цей корінь описаний вище скрипт деплойменту
- також, створюю в корені теку ./public, де власне будуть розміщуватись публічні файли
- інші компоненти .git і .vscode - створяться автоматично, але при цьому не потраплятимуть до публічного простору ./public (як і в архів .zip)
Таким чином, локальна структура файлів виглядатиме наступним чином:
/
.git/
.vscode/
.gitignore
public/
index.gmi
pu.sh
- pu.sh або push - це скрипт, який я виконую в терміналі (або хоткеєм) для публікації ресурсу в 1 крок