gemlog/public/uk/about-gemlog-administration.gmi

# Про адміністрування блогів Gemini

Оскільки надаю перевагу децентралізації, мій блог розміщено на різних платформах і мережах. Щоб не синхронізувати все вручну, для автоматизованих релізів, я користуюсь певною інфраструктурою проєкту на базі скриптів з публікації оновлень на всі дзеркала одночасно.

Цей огляд стосується адміністрування статичного формату файлів, CMS я не користуюсь принципово.

## Редагування

Тут в мене все типово для програміста: редактор коду VSCodium з плагіном gemini-improved:
=> https://open-vsx.org/extension/printfn/gemini-improved
=> https://github.com/printfn/gemini-vscode

Щоб переглянути сторінку в форматі Gemtext до її публікації, я просто відкриваю локальний файл у браузері (Yoda або Lagrange). Були думки зробити редактор GTK з прев'ю, але поки не доходять руки.

## Публікація

### Git

Цей блог має локальний та публічний апстрім-репозиторії, де зберігається історія змін:
=> https://codeberg.org/postscriptum/gemlog

### Хостинг

Окрім Git/HTTP, сайт публікується на безкоштовному хостингу Yesterweb:
=> gemini://ps.cities.yesterweb.org

Також планую додати ще одне дзеркало на платформі Flounder, де є вбудований агрегатор оновлень:
=> gemini://ps.flounder.online
* утім, досі (і вже не вперше) очікую на підтвердження облікового запису

Віднедавна, організував для анонів локальне дзеркало в мережі I2P:
=> gemini://shxxkkrws2m6qowjse5jpgmu64vzupnnhxrhdzrn6fr6m7ynddbq.b32.i2p

Стосовно самої зв'язки Gemini+I2P, рекомендую наступні матеріали:
=> i2p-capsule-in-gemini-space-with-agate.gmi Публікація капсули Gemini в I2P на прикладі сервера Agate
=> agate-virtual-host-usage-examples.gmi Специфіка роботи з віртуальними хостами Agate

Повний перелік дзеркал актуалізується тут:
=> mirrors.gmi Список офіційних дзеркал

## Синхронізація

Донедавна, для відвантаження файлів на віддалені сервери, користувався такими плагінами:
=> https://github.com/Natizyskunk/vscode-sftp Форк SFTP
=> https://github.com/YGGverse/vscode-webdav Форк плагіна vscode-webdav (з функцією авто-відвантаження при збереженні файлу)

Але згодом, втомився від глюків розсинхронізації потоків VSCode. Мені потрібно було ходити на кожен сервер і вручну перевіряти чи не заглючило відвантаження певного файлу: іноді URL матеріалу підмінявся індексним файлом та відбувалась всяка інша містика, властива плагінам на JS.

Щодо хостингу Yesterweb - в мене є окрема нотатка, де я пройшов довгий шлях до поточної моделі релізів:
=> /en/yesterweb-connection-with-webdav.gmi Yesterweb connection with WebDAV
* внизу є приклад скрипта, яким користуюся й досі; нижче коротко опишу, як він працює

### Скрипт bash

Актуальна версія скрипта є в репозиторії блогу, продублюю поточну його версію з коментарями:

``` 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 відбувається командою:

``` bash
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://<username>.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 крок