Minulla on Pixelfed instanssi nimellä 400nm. Omalla serverillään ylhäisessä yksinäisyydessään. Olen sen ainoa käyttäjä (on se avoin rekisteröitymisille), joten en välttämättä ehdottomasti tarvitse sille ikiomaa VPS:ää.
Yleisfoorumini Katiskan foorumi (jep, hölmö nimi, mutta sille on historialliset syyt) on ja pysyy ikiomalla serverillään, koska siellä on muitakin käyttäjiä. Syy tähän jakoon on aika yksinkertainen: älä pidä kaikkia munia samassa korissa. Paitsi jos kori on arvokkaampi kuin munat.
Tilan säästöä
Aikoinaan minulla oli vain yksi iso serveri, ja pidin kaikki erilaiset sivustoni siellä. Kun sekaisin on WordPressiä, web-appia, dockeria jne. niin jossain vaiheessa tulee taatusti konflikteja. Eivätkä ne kaada vain yhden tai kaksi sivustoa, vaan tuppaavat jokainen tipahtamaan linjoilta. Joten joko kaikki toimivat, tai jokainen oli alhaalla.
Nykyinen hub, jossa on jokainen WordPress, on hieman liian iso. Syy on masentava. En osannut laskea oikein muistinkäyttöä Varnishin kanssa, ja jätin siivoamatta turhia tiedostoja. Useimmiten VPS:n RAM on muutettavissa ylös ja alas aika kivuttomasti, mutta kun kovalevytilaa kasvattaa, niin se on yksisuuntainen tie. Takaisin pienempään ei pääse ilman, että käynnistää uuden virtuaaliserverin ja tekee työteliään muuton. Joten aito tilantarve kannattaisi aina laskea ja mitoittaa.
Olen kuullut usein kuinka vaikeaa on siirtää Windows-asennus koneelta toiselle. Se on lasten leikkiä verrattuna säädetyn virtuaaliserverin muuttoon.
Joten lopputulema on kuitenkin se, että maksan turhaan Pixelfedin serveritilasta. Joten siirrän sen WordPressien kupeeseen.
Pixelfed uudelle serverille
Migraatio-ohjeita löytyy jonkun verrankin. Pixelfedin oma on hajanainen, eikä aina ajantasalla. Samaa ongelmaa siis kuin Mastodonin kanssa. Devaajat säätävät mieluummin koodia kuin paikkaisivat dokumentteja ja manuaaleja. En väitä, etteikö migraatio onnistuisi Pixelfedin ohjeilla, ja niitä kannattaisikin aina noudattaa. Mutta silti tämä on se resepti, jolla minä muuton tein.
Minulle ei downtime ole kynnyskysymys — edelleenkin, olen ainoa käyttäjä. Joten tein kaiken miettimättä aikaa.
Migraatiossa ja Pixelfedin muutossa toiselle serville on kaksi tapaa:
- siirretään vanhasta kaikki
- tehdään uusi asennus, ja siirretään tietokanta ja muut vastaavat roippeet
Usein kannattaa tehdä tuore ja blankkoasennus, ja sitten siirtää muuttuvat asiat. Eräällä tavalla tehdä siis varmuuskopiopalautus.
Se toimii usein. Ainakin niin kauan kun kaiken mahdollisen versiot ovat samanlaiset. Joten vanha kannattaa päivittää tuoreimpaan versioon ja vasta siirtyä muuttohommiin.
Minä en päivitellyt, vaan asensin GitHubista tuoreimman ja tein sen jälkeen siirtoasiat. Oliko se fiksua? Ei varmaankaan. Toisaalta, Pixelfed-asennukseni ei ollut ikivanha, vaan olin päivittänyt sen ehkä kuukausi sitten.
Siirrettäviä asioita on aika monta muistettavaa, joten tein scriptin, joka tehnee homman — suurimmaksi osaksi. Jos kokeilet sitä, niin muuta oleelliset tiedot.
Minä en ole koodari, mutta osaan kopypeistata. Joten scriptini ei ollut ihan niin hyvä kuin ajattelin. Olisi pitänyt olla hieman enemmän aikakriittisyyttä sen mukaan mitä kopioi. Mitään katastrofia ei tullut, mutta muutaman asian jouduin korjaamaan siirron jälkeen. Kun siirto itsessään vei aikaa kaikkine selvittelyineen pari tuntia (siksi tein tämän jutun, en enää koskaan toiste tee samaa google-urakkaa), niin muutaman jälkikorjauksen paikkailu vei neljä tuntia — siitä 3 tuntia 45 minuuttia Googlessa, 10 minuuttia tekoälyn kanssa jankatessa ja 5 minuuttia työtä.
Olisin toki voinut siirtää poisjääneet tai vajaasti tehdyt asiat scriptiin myöhemmin, mutta silloin se ei enää olisi ollut sama mitä itse käytin ja jonka tiedän silloin siinä hetkessä toimineen. Enkä yleensä julkaise muita ohjeita, tai tapauskertomuksia, kuin mitä itse olen tehnyt.
Joten koodi ei tee kerrasta valmista. Valitettavasti. Mutta lähelle pääsee ja tärkeimmät asiat se tekee.
Muuta nimipalvelintiedot
Vaihda A-tietue uudelle IP-osoitteelle suunnilleen nyt. Siellä on oma TTL-aikansa, ennenkuin muutos näkyy edes sinulle. Scriptin voi ajaa vasta DNS-muutosten jälkeen, koska se hakee Lets Encryptiltä SSL-sertifikaatin. Joten muutos ehtii toteutumaan sillä aikaa kun yrität päättää miten aiot muuton tehdä.
pixelfed_migration.sh
Makuasia miten skriptin nimeää, tai mihin sen asentaa. Se on kuitenkin kertaluontoinen ajettava. Itse laitoin skriptin /root
hakemistoon, koska tällaiset asiat tuppaa olemaan rootin oikeuksia vaativia — ja jatkuvasta sudon näpyttelystä pääsee sitten eroon sudo -s
komennolla.
Mutta sitä ennen täytyy composer
olla asennettuna. Se löytyy aptillakin, mutta tällä saat tuoreimman version:
❯ Näytä koodi
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php --install-dir=/usr/local/bin --filename=composer
php -r "unlink('composer-setup.php');"
Komenna composer -V
niin näet, että se toimii.
Muuta muukin ohjelma tarvitaan, kuten git. Ehkä kannattaa komentaa tämäkin, vaikka suurin osa varmasti löytyy jo valmiiksi.
❯ Näytä koodi
apt install git rsync openssh-client php-cli php-mbstring php-curl php-gd php-imagick php-intl php-zip php-mysql mariadb-client mariadb-server nginx certbot python3-certbot-nginx
Pixelfed haluaa Redisin. En asentanut sitä tässä vaiheessa, vaan vasta muuton jälkeen. Minä kun olin varma, että minulla on se asennettuna. Ei ollut, vaan olen poistanut sen aikoinaan tarpeettomana. Joten jos haluat välttää yhden ylimääräisen error 503 virheen, niin asenna Redis nyt.
❯ Näytä koodi
apt update
apt install -y redis-server php-redis
systemctl enable --now redis-server
# Varmista yhteys
redis-cli ping # -> PONG
php -m | egrep 'redis|mbstring|intl|imagick|zip|gd|curl|mysqli'
Minulla Redis kaatui samantien. Syy oli luultavasti siinä, että olen aikoinaan kertaallen asentanut Redisin, ja sitten poistanut sen. Ongelmani korjaantui, kun hakemisto-oikeudet laitettiin kuntoon:
❯ Näytä koodi
# Oletuspolut Ubuntussa
ls -ld /var/lib/redis /var/log/redis /run/redis 2>/dev/null || true
# Korjaa omistukset ja oikeudet:
mkdir -p /var/lib/redis /var/log/redis /run/redis
chown -R redis:redis /var/lib/redis /var/log/redis /run/redis
chmod 770 /var/lib/redis
Mainitaan itsestäänselvyys: uuden ja vanhan serverin täytyy osata jutella keskenään SSH:n kautta. Oletan, että osaat siirtää julkiset SSH-avaimet serverien välillä.
Kopioi allaoleva scriptiin. Muuta alusta mitä täytyy.
❯ Näytä koodi
#!/usr/bin/env bash
set -euo pipefail
############################
# MUUTA NÄMÄ ENNEN AJOA #
############################
# Vanha palvelin (josta kopioidaan .env + storage + DB)
OLD_SSH="root@VANHA_SERVER_IP_TAI_NIMI"
OLD_PATH="/var/www/400nm"
# Uusi polku ja unix-käyttäjä
NEW_USER="pixelfed"
NEW_GROUP="www-data"
NEW_BASE="/var/www/400nm"
# Domain (PIDÄ samana kuin vanhassa!)
DOMAIN="400nm.kvarkki.nexus"
APP_URL="https://400nm.kvarkki.nexus"
# DB: MariaDB/MySQL (sama tietokanta- ja käyttäjänimi kuin vanhassa .env:ssä)
MYSQL_DB="pixelfed"
MYSQL_USER="pixelfed"
# VANHAN palvelimen salasana dumpin ottamiseen:
OLD_MYSQL_PASS="VANHAN_SALASANA"
# UUDEN palvelimen salasana (tällä luodaan käyttäjä ja päivitetään uusi .env)
NEW_MYSQL_PASS="UUSI_SALASANA"
# Yhteydet uuteen
MYSQL_HOST="127.0.0.1"
MYSQL_PORT="3306"
# PHP-FPM soketti
PHP_FPM_SOCK="/run/php/php8.3-fpm.sock"
# SSL haku:
USE_CERTBOT="yes" # "yes" tai "no"
# Nginx-konffi:
WRITE_NGINX="yes" # "yes" kirjoittaa /etc/nginx/sites-available/$DOMAIN.conf
# Node-build (harvoin pakollinen Pixelfedissä)
BUILD_ASSETS="no" # "yes" = npm install && npm run build
############################
# EI TARVITSE MUUTTAA #
############################
REPO_URL="https://github.com/pixelfed/pixelfed.git"
NGINX_AVAIL="/etc/nginx/sites-available/${DOMAIN}.conf"
NGINX_EN="/etc/nginx/sites-enabled/${DOMAIN}.conf"
log(){ printf "\n\033[1;32m==> %s\033[0m\n" "$*"; }
warn(){ printf "\n\033[1;33m[WARN] %s\033[0m\n" "$*"; }
err(){ printf "\n\033[1;31m[ERR] %s\033[0m\n" "$*"; exit 1; }
need_cmd(){ command -v "$1" >/dev/null 2>&1 || err "Puuttuu komento: $1"; }
trap 'err "Jokin vaihe epäonnistui. Katso loki yltä ja korjaa."' ERR
main() {
prechecks
create_user_and_dirs
clone_or_update_repo
fetch_env_from_old
composer_install
maybe_build_assets
rsync_storage
storage_link
restore_database_mysql
laravel_prep
write_systemd_units
enable_systemd_units
maybe_write_nginx
maybe_certbot
final_checks
log "Valmis! Avaa ${APP_URL} ja testaa Webfinger sekä media."
}
prechecks() {
log "Tarkistetaan riippuvuudet"
for c in git rsync scp php composer sed systemctl curl mysql mysqldump; do need_cmd "$c"; done
if [[ "${WRITE_NGINX}" == "yes" ]]; then need_cmd nginx; fi
if [[ "${USE_CERTBOT}" == "yes" ]]; then need_cmd certbot; fi
}
create_user_and_dirs() {
log "Luodaan unix-käyttäjä ja hakemisto (jos puuttuvat)"
id -u "${NEW_USER}" >/dev/null 2>&1 || useradd -r -m -d "${NEW_BASE}" "${NEW_USER}"
mkdir -p "${NEW_BASE}"
chown -R "${NEW_USER}:${NEW_GROUP}" "${NEW_BASE}"
}
clone_or_update_repo() {
log "Haetaan Pixelfed-repo"
if [[ ! -d "${NEW_BASE}/.git" ]]; then
sudo -u "${NEW_USER}" git clone "${REPO_URL}" "${NEW_BASE}"
else
pushd "${NEW_BASE}" >/dev/null
sudo -u "${NEW_USER}" git fetch --all
sudo -u "${NEW_USER}" git pull --ff-only
popd >/dev/null
fi
}
fetch_env_from_old() {
log "Kopioidaan .env vanhalta palvelimelta"
if [[ -f "${NEW_BASE}/.env" ]]; then
warn ".env löytyy jo -> jätetään ennalleen"
else
scp "${OLD_SSH}:${OLD_PATH}/.env" "${NEW_BASE}/.env" || err ".env kopio epäonnistui"
chown "${NEW_USER}:${NEW_GROUP}" "${NEW_BASE}/.env"
fi
# Päivitä .env: APP_URL + DB-arvot uutta ympäristöä varten
sed -i "s|^APP_URL=.*|APP_URL=${APP_URL}|" "${NEW_BASE}/.env" || true
sed -i "s|^DB_CONNECTION=.*|DB_CONNECTION=mysql|" "${NEW_BASE}/.env" || true
sed -i "s|^DB_HOST=.*|DB_HOST=${MYSQL_HOST}|" "${NEW_BASE}/.env" || true
sed -i "s|^DB_PORT=.*|DB_PORT=${MYSQL_PORT}|" "${NEW_BASE}/.env" || true
sed -i "s|^DB_DATABASE=.*|DB_DATABASE=${MYSQL_DB}|" "${NEW_BASE}/.env" || true
sed -i "s|^DB_USERNAME=.*|DB_USERNAME=${MYSQL_USER}|" "${NEW_BASE}/.env" || true
if grep -q '^DB_PASSWORD=' "${NEW_BASE}/.env"; then
sed -i "s|^DB_PASSWORD=.*|DB_PASSWORD=${NEW_MYSQL_PASS}|" "${NEW_BASE}/.env"
else
echo "DB_PASSWORD=${NEW_MYSQL_PASS}" >> "${NEW_BASE}/.env"
fi
}
composer_install() {
log "composer install --no-dev --optimize-autoloader"
pushd "${NEW_BASE}" >/dev/null
sudo -u "${NEW_USER}" composer install --no-dev --optimize-autoloader
popd >/dev/null
}
maybe_build_assets() {
if [[ "${BUILD_ASSETS}" == "yes" ]]; then
log "npm install && npm run build"
pushd "${NEW_BASE}" >/dev/null
sudo -u "${NEW_USER}" bash -lc 'command -v npm >/dev/null 2>&1 && npm install && npm run build || echo "npm puuttuu, ohitetaan"'
popd >/dev/null
else
warn "Asset build ohitettu (BUILD_ASSETS=no)."
fi
}
rsync_storage() {
log "Rsync storage vanhalta"
rsync -aHAX --delete --info=progress2 "${OLD_SSH}:${OLD_PATH}/storage/" "${NEW_BASE}/storage/"
chown -R "${NEW_USER}:${NEW_GROUP}" "${NEW_BASE}/storage"
}
storage_link() {
log "php artisan storage:link"
pushd "${NEW_BASE}" >/dev/null
sudo -u "${NEW_USER}" php artisan storage:link || true
popd >/dev/null
}
mysql_exec_root() {
# Suorita mysql root-oikeuksilla: ensin yritetään unix-socket (sudo mysql),
# jos ei toimi, yritetään "mysql -u root -p" epäinteraktiivisesti ympäristömuuttujalla.
local sql="$1"
if command -v sudo >/dev/null 2>&1 && sudo mysql -e "SELECT 1" >/dev/null 2>&1; then
sudo mysql -e "$sql"
elif mysql -e "SELECT 1" >/dev/null 2>&1; then
mysql -e "$sql"
else
warn "mysql root -yhteys vaatii salasanan, suorita seuraavat manuaalisesti:\n${sql}"
return 1
fi
}
restore_database_mysql() {
log "Luodaan tietokanta ja käyttäjä uudelle palvelimelle"
# Luo kanta
mysql_exec_root "CREATE DATABASE IF NOT EXISTS \`${MYSQL_DB}\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" || true
# Luo käyttäjä molemmille isännille ja myönnä oikeudet
mysql_exec_root "CREATE USER IF NOT EXISTS '${MYSQL_USER}'@'127.0.0.1' IDENTIFIED BY '${NEW_MYSQL_PASS}';" || true
mysql_exec_root "CREATE USER IF NOT EXISTS '${MYSQL_USER}'@'localhost' IDENTIFIED BY '${NEW_MYSQL_PASS}';" || true
mysql_exec_root "GRANT ALL PRIVILEGES ON \`${MYSQL_DB}\`.* TO '${MYSQL_USER}'@'127.0.0.1';" || true
mysql_exec_root "GRANT ALL PRIVILEGES ON \`${MYSQL_DB}\`.* TO '${MYSQL_USER}'@'localhost';" || true
mysql_exec_root "FLUSH PRIVILEGES;" || true
log "Dumpataan kanta vanhalta palvelimelta"
TMPDUMP="/tmp/pixelfed_$(date +%s).sql"
ssh "${OLD_SSH}" "mysqldump --single-transaction --routines --triggers --events \
-h 127.0.0.1 -P 3306 -u ${MYSQL_USER} -p${OLD_MYSQL_PASS} ${MYSQL_DB} > ${TMPDUMP}" || err "mysqldump epäonnistui vanhalla"
scp "${OLD_SSH}:${TMPDUMP}" "${TMPDUMP}"
log "Palautetaan dump uuteen kantaan"
mysql -h "${MYSQL_HOST}" -P "${MYSQL_PORT}" -u "${MYSQL_USER}" -p"${NEW_MYSQL_PASS}" "${MYSQL_DB}" < "${TMPDUMP}"
rm -f "${TMPDUMP}"
ssh "${OLD_SSH}" "rm -f ${TMPDUMP}" || true
}
laravel_prep() {
log "Laravelin cachet ja optimoinnit"
pushd "${NEW_BASE}" >/dev/null
chown -R "${NEW_USER}:${NEW_GROUP}" bootstrap/cache || true
find storage -type d -exec chmod 775 {} \; || true
find storage -type f -exec chmod 664 {} \; || true
chmod -R 775 bootstrap/cache || true
sudo -u "${NEW_USER}" php artisan config:clear || true
sudo -u "${NEW_USER}" php artisan cache:clear || true
sudo -u "${NEW_USER}" php artisan route:clear || true
sudo -u "${NEW_USER}" php artisan view:clear || true
sudo -u "${NEW_USER}" php artisan migrate --force
sudo -u "${NEW_USER}" php artisan optimize || true
popd >/dev/null
}
write_systemd_units() {
log "Kirjoitetaan systemd-yksiköt (queue + scheduler)"
cat >/etc/systemd/system/pixelfed-queue.service <<EOF
[Unit]
Description=Pixelfed Queue Worker
After=network.target
[Service]
WorkingDirectory=${NEW_BASE}
ExecStart=/usr/bin/php artisan queue:work --sleep=3 --tries=3 --max-time=3600
Restart=always
User=${NEW_USER}
Group=${NEW_GROUP}
[Install]
WantedBy=multi-user.target
EOF
cat >/etc/systemd/system/pixelfed-scheduler.service <<EOF
[Unit]
Description=Pixelfed Scheduler
[Service]
Type=oneshot
WorkingDirectory=${NEW_BASE}
ExecStart=/usr/bin/php artisan schedule:run
User=${NEW_USER}
Group=${NEW_GROUP}
EOF
cat >/etc/systemd/system/pixelfed-scheduler.timer <<EOF
[Unit]
Description=Run Pixelfed scheduler every minute
[Timer]
OnCalendar=*:0/1
Persistent=true
[Install]
WantedBy=timers.target
EOF
systemctl daemon-reload
}
enable_systemd_units() {
log "Otetaan systemd-yksiköt käyttöön"
systemctl enable --now pixelfed-queue.service
systemctl enable --now pixelfed-scheduler.timer
}
maybe_write_nginx() {
if [[ "${WRITE_NGINX}" != "yes" ]]; then
warn "Nginx-konffin kirjoitus ohitettu (WRITE_NGINX=no)."
return
fi
log "Kirjoitetaan Nginx vhost ${NGINX_AVAIL}"
cat >"${NGINX_AVAIL}" <<EOF
server {
listen 80;
server_name ${DOMAIN};
return 301 https://\$host\$request_uri;
}
server {
listen 443 ssl http2;
server_name ${DOMAIN};
# Sertti lisätään certbotilla myöhemmin
root ${NEW_BASE}/public;
index index.php;
client_max_body_size 64M;
location / {
try_files \$uri \$uri/ /index.php?\$query_string;
}
location ~ \.php\$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME \$realpath_root\$fastcgi_script_name;
fastcgi_pass unix:${PHP_FPM_SOCK};
fastcgi_read_timeout 300;
}
location ~* \.(?:png|jpg|jpeg|gif|webp|svg|css|js|woff2?)\$ {
expires max;
add_header Cache-Control "public";
}
}
EOF
ln -sf "${NGINX_AVAIL}" "${NGINX_EN}" || true
nginx -t
systemctl reload nginx
}
maybe_certbot() {
if [[ "${USE_CERTBOT}" != "yes" ]]; then
warn "Sertin haku ohitettu (USE_CERTBOT=no)."
return
fi
log "Haetaan Let's Encrypt -serti (DNS osoitettava tälle koneelle)"
certbot --nginx -d "${DOMAIN}" || warn "certbot epäonnistui, yritä kun DNS on päivittynyt"
}
final_checks() {
log "Pikacheckit"
systemctl --no-pager status pixelfed-queue.service || true
systemctl --no-pager status pixelfed-scheduler.timer || true
if curl -fsS "https://${DOMAIN}/.well-known/webfinger?resource=acct:test@${DOMAIN}" >/dev/null; then
log "Webfinger endpoint vastaa (HTTP 200)."
else
warn "Webfinger ei vastannut 200. Tarkista Nginx/PHP/APP_URL."
fi
}
main "$@"
Scriptistä täytyy tehdä ajettava chmod +x pixelfed_migration.sh
tai miten sen sitten nimesitkään.
Sitten komennat ./pixelfed_migration.sh
ja ihmettelet hetken kun tavaraa siirtyy netissä.
Kun siirto on valmis, niin uusvanha Pixelfed-instanssisi ei toimi. Tuurilla et saanut error 503, mutta taatusti Pixelfedisi ei saa syötettä fediversumista ja jos pääset kirjautumaan, niin diagnoosissa on punaisena failina sellaisiakin asioita, joita ei pitäisi olla.
Tai ainakin minulle kävi niin.
Siirron jälkihuolto
Scriptini esimerkiksi asetti queue-servicen, jota ei enää käytetä — esimerkki vauhdikkaasta kopioinnista ikivanhasta lähteestä. Pitäisi käyttää horizonia. Samaten Pixelfed-hakemiston omistajuudet olivat pielessä.
Tässä vaiheessa turvauduin jo AI:n apuun. Joten tekemiset toimivat, mutta on olemassa riski, että tein liian paljon liian usein, kun olisi pitänyt tehdä jotain ihan muuta. Törmäsin näet yhteen hakemisto- ja cache-ongelmaan, joka on Googlen mukaan kiusannut useitakin instansseja vuodesta 2023 alkaen ihan tämän jutun kirjoituspäivään asti.
Joten listaan suunnilleen järjestyksessä mitä tein. Valitse siitä itsellesi sopivat — jos edes tarvitset.
pixelfed-horizon.service
Tee tämä ennen muita säätöjä. Luultavasti säästyt ainakin yhdeltä cachen tyhjentämiskierrokselta. Tai sitten et. Otetaan Horizon käyttöön nyt, koska sitä ei siirretty vanhasta.
Tehdään tiedosto:
nano /etc/systemd/system/pixelfed-horizon.service
Kopioi tämä:
❯ Näytä koodi
[Unit]
Description=Pixelfed Horizon (Laravel queue manager)
After=network.target
[Service]
User=pixelfed
Group=www-data
WorkingDirectory=/var/www/400nm
ExecStart=/usr/bin/php artisan horizon
ExecStop=/usr/bin/php artisan horizon:terminate
Restart=always
RestartSec=5
# Vapaaehtoista: rajoita muistia / avaa tiedostokahvoja:
# LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
Tuo on käytännössä sama kuin Pixelfedin tekemä, kun Horizon on otettu ohjeiden mukaisesti käyttöön. Nimi on vaan nyt kuvaavampi, koska tuo service ei tee töitä Pixelfedin kanssa, vaan Horizonin. Lisäksi nykyinen rakennelma on ehkä hieman turvallisempi kuin vakio.
Otetaan se käyttöön ja sammutetaan turha queue:
❯ Näytä koodi
systemctl daemon-reload
systemctl disable --now pixelfed-queue.service
systemctl enable --now pixelfed-horizon.service
Samaa sarjaa on scheduler. Usein asennusohjeet neuvovat käyttämään cronia, mutta nyt tehtiin timer. Joskus saa tulla 2020-luvullekin.
Koska scripti teki ajastukset, niin tämä on enemmälti vain dokumentointia:
pixelfed-scheduler.service
❯ Näytä koodi
[Unit]
Description=Pixelfed Scheduler
[Service]
Type=oneshot
WorkingDirectory=/var/www/400nm
ExecStart=/usr/bin/php artisan schedule:run
User=pixelfed
Group=www-data
pixelfed-scheduler.timer
❯ Näytä koodi
[Unit]
Description=Run Pixelfed scheduler every minute
[Timer]
OnCalendar=*:0/1
Persistent=true
[Install]
WantedBy=timers.target
Kirjaudu selaimella
Jos olit ennen siirtoa laittanut vanhan huoltotilaan, niin maintenancen saa pois näin:
cd /var/www/400nm
sudo -u pixelfed php artisan up
Viimeistään tässä vaiheessa on syytä tyhjentää cachet:
❯ Näytä koodi
sudo -u pixelfed bash -lc '
cd /var/www/400nm
php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
php artisan optimize
'
Kannattaa myös käynnistää Nginx uudestaan. Asia, jonka itse unohdin. En tiedä onko se ehdottoman tärkeää, mutta…systemctl restart nginx
Avaa selain, ja toivottavasti saat etusivun. Ja pääset kirjautumaan. Älä käytä appeja, ei edes PWA:ta.
Suuntaa admin-puolelle ja varmista kaikki asetukset. Protip: tallenna jokainen asetussivu. Se, että asetukset ovat kunnossa, ja myös .env
tiedostossa on oikeat asiat true
ei todellakaan tarkoita, että Pixelfed noudattaisi niitä.
Boostrap: Not writable
Mene diagnoosiin ja tarkista, että punaisella on vain sellaiset asiat, jotka ovat oikeasti poistettu käytöstä.
Minulla ongelman tuottivat nämä:
Bootstrap: Not writable ❌ ACTIVITYPUB instance actor cached: ❌ INSTANCE_DISCOVER_PUBLIC ❌ PIXELFED OPEN_REGISTRATION ❌
Viimeinen, OPEN_REGISTRATION, oli helpoin. Takaisin asetuksiin ja ensin muuttaa rekisteröintisäännön joksikin muuksi, ja tallentaa. Sitten vaihtaa sen takaisin avoimeksi, ja tallentaa. Siksi sanoin aiemmin, että jokainen asetussivu kannattaa tallentaa erikseen.
Kolme ensimmäistä on hankalampia. Ne kun estävät aika tehokkaasti federoinnin, joka suuntaan. Ne, varsinkin kaksi ensimmäistä, löytyvät myös helposti googlella, mutta useimmiten ilman varsinaista ratkaisua.
Mutta bootstrap on käytännössä aina omistajuus/kirjoitusongelma, instance actor cache-kysymys. Discover korjaantui jossain välissä noiden kahden kanssa riidellessä ja minulla on tunne, että se saattoi olla ihan vaan horizonin hidastelua. Tai jotain.
Instance actor korjaantuu menemällä sivulle https://instanssisi/i/actor
. Se siitä. Saatat joutua käymään siellä uudemmankin kerran, jos tyhjennät cachet.
Bootstrap-hakemiston ongelma oli se, että kaikki oli pixelfed:pixelfed
mutta PHP-FPM on www-data
. Joten muuttelin omistajuuksia:
❯ Näytä koodi
cd /var/www/400nm
# varmista että FPM-prosessi käyttää www-data -käyttäjää
grep -R "^\s*user\s*=" /etc/php/*/fpm/pool.d/*.conf || true
# korjaa omistukset ja oikeudet bootstrap/cache:lle
chown -R pixelfed:www-data bootstrap/cache
find bootstrap/cache -type d -exec chmod 2775 {} \;
find bootstrap/cache -type f -exec chmod 664 {} \;
# sama varmuudeksi storageen
chown -R pixelfed:www-data storage
find storage -type d -exec chmod 2775 {} \;
find storage -type f -exec chmod 664 {} \;
# tyhjennä ja rakenna cachet uudelleen
sudo -u pixelfed php artisan config:clear
sudo -u pixelfed php artisan cache:clear
sudo -u pixelfed php artisan route:clear
sudo -u pixelfed php artisan view:clear
sudo -u pixelfed php artisan optimize
Tuo ei auttanut. Yksi syy saattoi olla se, että varsinainen ylähakemisto oli edelleen pixelfed:pixelfed
, joten tein yhden kierroksen lisää:
❯ Näytä koodi
cd /var/www/400nm
chown -R pixelfed:www-data bootstrap
chmod 2775 bootstrap
chmod 2775 bootstrap/cache
find bootstrap -type f -exec chmod 664 {} \;
Tyhjensin cachet tässä välissä:
❯ Näytä koodi
cd /var/www/400nm
sudo -u pixelfed php artisan config:clear
sudo -u pixelfed php artisan cache:clear
sudo -u pixelfed php artisan route:clear
sudo -u pixelfed php artisan view:clear
sudo -u pixelfed php artisan optimize
Tuo riitti. Nyt ongelmakohdat muuttuivat vihreiksi ja syötekin oli mitä piti.
Kappas. Koodiaidat ei tule läpi ja rikkoo sisällön
Sain hiukan fiksattua, mutta… ei siitä hyvä tullut. Mutta parempi.
Laitoin koodit ja scriptit lisätietoja-lohkoon, niin eivät häiritse niin paljon. Mutta silti kun mukana on esimerkiksi #-merkki niin foorumi vääntää sen väkisin otsikoksi. Noissa yhteyksissä se tarkoittaa kommenttia. Sama juttu $-merkkien kanssa. Foorumilla se aloittaa matemaattisen kaavan, mutta scripteissä se on muuttuja.
Foorumin ei kuuluisi puuttua mitenkään koodilohkojen sisältöön, mutta puuttuu, kun se tulee ulkoa, kuten WordPress-sivustolta.
Sen verran sain avustettuna säädettyä sitä, että kun klikkaa jutun lopusta Näytä linkityksen teksti… eli tätä:
niin silloin se lataa sellaisen version, jossa skriptit näytetään oikein.
Tai jos laitetaan ne vierekkäin (onnistuukohan tämä…)
Vasen on sitä mitä foorumi nyt ehdoin tahdoin haluaa näyttää. Oikea on se mitä sen kuuluisi näyttää, ilman kikkailuja.
Mutta jos nuo asiat kiinnostaa, niin ehkä kannattaisi klikata suoraan sivustolle ja lukea siellä…