Categorie: Yunohost

Geplaatst op

Nextcloud upgrade van NC27 naar NC28

Nextcloud upgrades verlopen meestal zonder problemen, maar niet elke keer. Krap vier jaar terug had ik problemen met de upgrade van NC18 naar NC19: de database was gegroeid tot 440 GB, wat moeite gaf (timeout) bij de backup. In dat geval bleek het gros van de database te bestaan uit cache van externe bestanden; na truncate (truncate oc_filecache;) van de tabel verliep de upgrade zonder problemen.

Nu een aantal versies later: de upgrade van Nextcloud 27 naar Nextcloud 28 wil niet. Aan het begin van het jaar heb ik het eens geprobeerd, zonder succes, en een rollback gedaan naar het snapshot van juist daarvoor.

Ondertussen is Nextcloud 29 al een tijdje beschikbaar en raakt NC27 ‘unsupported’. In de hoop dat mogelijke bugs gevonden zijn, heb ik opnieuw een upgrade gestart. Helaas weer zonder succes.

Tweede poging

Deze stappen heb ik genomen:

  • Alle systeemcomponenten bijwerken : apt upgrade && apt update -y
  • Alle NC-apps bijwerken naar de laatste versie via admin login –> gezichts-menu –> Apps –> Your apps en dan “Upgrade all”
  • Controleren welke apps nog geen ondersteuning hebben in de nieuwe Nextcloud. Er is zo’n lijstje voor unsupported apps in NC29, maar voor NC28 heb ik dat niet kunnen vinden. Er zijn geen apps actief die in dat lijstje voorkomen
  • Shutdown container in Proxmox ; voor snapshots is dat niet nodig, maar om een consistente staat van de databases de garanderen lijkt het me een goed idee
  • Create snapshot in Proxmox en start de container
  • Log in in Yunohost en start de upgrade van Nextcloud
    • Yunohost creeert eerst een backup
    • Voert de upgrade uit
    • Klapt op “App ‘Text file editor’ not supported in NC28”, of iets in die geest
    • Probeert een restore van de backup uit te voeren
    • Restore hangt op “Restoring the MySQL database”
  • Shutdown container in Proxmox
  • Restore container snapshot in Proxmox
  • Start container

Anders dan de ‘unsupported app’-melding heb ik de specifieke fout niet kunnen herleiden; door de restore van het snapshot is de logging niet meer beschikbaar.

Derde poging

Nadat het snapshot teruggezet is:

  • Applicatie “Edit text files” verwijderen
  • De nu beschikbare MariaDB-updates installeren
  • Shutdown container, snapshot maken, boot container
  • Nextcloud upgraden vanaf de command line voor wat meer live-inzicht: yunohost app upgrade nextcloud
  • De upgrade loopt weer fout, ik laat het proces verder lopen in de achtergrond om te zien wat de restore van de backup doet
  • Na geruime tijd te blijven hangen op ‘Restoring the MySQL database’, wordt het script vervolgd
  • Restore van de backup klapt uiteindelijk op ontbrekende cachebestanden of previews,
    Info: WARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/f/8/6/8/e/8': Structure needs cleaning
  • Logging is via de Yunohost-logpublicatieservice te vinden op:

Omdat de restore mislukt, is er geen Nexctloud beschikbaar. Het is aantrekkelijk om het snapshot van voor de mislukte upgrade terug te zetten, maar daarmee vervallen tussentijdse wijzigingen: conceptversies van deze blogpost bijvoorbeeld, of tussentijds binnengekomen emails.

Logging doorzoeken

In willekeurige volgorde valt op in de logging, om verder uit te zoeken:

  • Bij de upgrade:
    • DEBUG - An unhandled exception has been thrown:
      DEBUG - Error: Undefined constant OCA\Keeweb\Migration\RegisterMimeType::CUSTOM_MIMETYPEALIASES in /var/www/nextcloud/apps/keeweb/lib/Migration/RegisterMimeType.php:25
  • Bij de restore:
    • DEBUG - Checking smb.conf with testparm
      WARNING - Load smb config files from /etc/samba/smb.conf
      WARNING - Loaded services file OK.
      WARNING - Weak crypto is allowed
      WARNING - Server role: ROLE_STANDALONE
    • WARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/1/d/c/6/2': Structure needs cleaning

Gezien het beperkte aantal emails en m’n offline kopie van deze tekst, is restore van het snapshot de snelste weg naar een nieuwe poging. Ik verwijder daarvoor eerst de Keeweb-app. De Keeweb-app heeft nooit gewerkt, maar ook nooit in de weg gezeten; het is de enige foutmelding in het upgrade-log.

Er zou een werkende versie van de app moeten zijn, hoewel er nu bij de app vermeld staat dat er upstream, bij Keeweb zelf, geen updates zijn sinds 2021. Na disable+remove van Keeweb sla ik het concept op en maak ik een nieuw snapshot, klaar voor een vierde poging.

Vierde poging

De vierde poging komt verder; de upgrade naar Nextcloud 28 (meer specifiek: 28.0.8 blijkt uit het log) lijkt voltooid: er wordt gemeld dat de upgrade naar Nextcloud 29.0.5 start.

Die upgrade slaagt niet; het log meldt:

InvalidArgumentException: Index name "sa" for table "oc_social_3_stream_act" collides with the constraint on table "oc_social_stream_act".
Update failed
Maintenance mode is kept active
Resetting log level

Ik wacht de restore van de backup niet af; ik controleer of er mail ontvangen is gedurende de update en ga meteen door met een rollback van het snapshot.

Er zijn een paar aanwijzingen te vinden op ’t Net: op de Nextcloud-fora en op de Gitub-pagina van Nextcloud. De oc_social_3_*-tabellen zijn in de loop van de tijd hernoemd naar oc_social_*, zonder “3” in de naam. De social app was al disabled wegens niet compatibel na een eerdere upgrade; ik heb de tabellen meteen verwijderd zoals gesuggereerd in een van de threads:

drop table oc_social_3_action; drop table oc_social_3_actor; drop table oc_social_3_cache_actor; drop table oc_social_3_cache_doc; drop table oc_social_3_client; drop table oc_social_3_follow; drop table oc_social_3_hashtag; drop table oc_social_3_instance; drop table oc_social_3_req_queue; drop table oc_social_3_stream; drop table oc_social_3_stream_act ; drop table oc_social_3_stream_dest; drop table oc_social_3_stream_queue; drop table oc_social_3_stream_tag;

Concept opslaan, snapshot maken en nog eens proberen.

Vijfde poging

Geslaagd! De upgrade van NC27 via NC28 naar NC29 besloeg een kwartier, waarvan het grootste deel voor rekening van de backup van de database kwam.

Er is een niet-fatale waarschuwing, 

Warning: File /var/www/nextcloud/config/config.php has been manually modified since the installation or last upgrade. So it has been duplicated in /var/cache/yunohost/appconfbackup//var/www/nextcloud/config/config.php.backup.20240917.184213

Ik meen dat ik de configuratie als read-only gemarkeerd heb; voor de rest moet ik de verschillen erop naslaan.

Bij het oproepen van de site en bij het inloggen heeft Nextcloud geen vervelende verrassingen. Een nieuw jasje en onder de motorkap vast veel gewijzigd, maar aan de buitenkant ‘gewoon’ de bestanden die er altijd al stonden. Fijn.

Print this entry

Geplaatst op

VPS-migratie

Een van de VPS’en zit vol. Uitbreiden van de opslagruimte is niet (goedkoop) mogelijk, maar omdat het er al een tijdje aan zat te komen, heb ik een ruimere VPS beschikbaar.

Bij een eerdere migratie, van thuis naar VPS, heb ik een howto op lowendspirit gevolgd waarmee het disk-image goed te versturen was. Ik had nu moeite hem weer terug te vinden, dus voor de volgende keer leg ik het hier ook vast.

Het idee is in grote lijnen:

  • Sluit de draaiende server af, om een statische situatie te hebben zodat het bestandssysteem consistent blijft.
  • Start een rescue-mode op de VPS-omgeving. In de rescue-mode zijn de diskpartities van de VPS beschikbaar.
  • Kopieer de partitie van de ene machine naar de andere machine met dd over SSH

In dit geval is het resultaat: 

rescue # dd if=/dev/vda1 bs=32M status=progress | ssh -C root@185.193.158.65 "dd of=/dev/vda"
The authenticity of host '185.193.158.65 (185.193.158.65)' can't be established.
RSA key fingerprint is SHA256:+EhOiwW9GjD4wv2S/0eRveRdoxV8Mlf1x8sICc9JxUY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '185.193.158.65' (RSA) to the list of known hosts.
root@185.193.158.65's password: 
973078528 bytes (973 MB, 928 MiB) copied, 35.8094 s, 27.2 MB/s

De partitie gaat van een datacenter in Frankfurt naar eentje in Amsterdam. De doorvoersnelheid stabiliseert zich op iets boven 33 MB/s, waarmee de partitie van 20 GB in ongeveer 10 minuten gekopieerd is.

De partitie is meteen al 40 GB, maar het bestandssysteem is nog 20 GB. Met resize2fs kan de grootte van het ext4-bestandssysteem aangepast worden: 

# e2fsck -f /dev/vda
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
....
# resize@fs /dev/vda
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/vda to 10485760 (4k) blocks.
The filesystem on /dev/vda is now 10485760 (4k) blocks long. 
#

Het enige probleem is dat het doelsysteem niet boot. Als ik de schijf boot in rescue-modus, staat alle data er op, inclusief de bootdirectory.

Wat blijkt? Bij het kopieren heb ik uit gewoonte de eerste partitie van de schijf (/dev/vda1) gepakt, terwijl er op de doelserver geen partitie is de schijf zit: het had /dev/vda1 ipv /dev/vda moeten zijn, of allebei /dev/vda.

Opgelost vanuit een system-rescue door:

  • Bestandssysteem krimpen tot minimum, de grootte van de bezette ruimte (resize2fis -M)
  • Nogmaals kopieren, nu van /dev/vda1 naar /dev/vda1
  • Bestandssysteem laten groeien tot partitiegrootte

Het systeem bootte toen wel, maar de netwerkconfiguratie was nog die van de oude server. Toen het eenmaal half-en-half werkte, vond ik de ‘reconfigure networking’ knop in de Solus-management-omgeving.

Daarmee werkte routing voor IPv6 weer; DNS was al gecorrigeerd.

Nu lijkt alles weer naar behoren te werken, met ruim het dubbele aan beschikbare ruimte.

Print this entry

Geplaatst op

Yunohost SSH toegang

Normaliter hebben Yunohost-gebruikers geen SSH-toegang. Zodoende is het lastig om de bestanden via SSHFS te benaderen. Om de bestanden via SSHFS te benaderen, zijn er twee dingen aan te passen.

  1. SSH toegang beschikbaar maken voor de gebruiker
  2. Toegang op bestandsniveau regelen voor die gebruiker via ACL

1 – SSH toegang

Via het Yunohost forum werd ik gewezen op de SSH-toegang die vanaf (ongeveer) versie 4.2 van Yunohost uitgedeeld kan worden. Ik gebruik voor SSH toegang een afzonderlijke gebruiker, die naast SSH-toegang, geen applicaties toegewezen krijgt.

Gebruiker voor SSH toegang

Via ‘Manage groups and permissions’ kun je SSH-toegang toewijzen:

Maak een nieuwe groep (hier sshfsnc), en geef die SSH-permissie
Voeg de gebruiker die je net gemaakt hebt toe aan de SSH-groep

2 – ACL’s

Via access control lists kun je extra rechten toekennen aan bestanden, naast de reguliere eigenaar/groep/iedereen rechten op bestandsniveau.

De toegangsrechten van Yunohost zijn erg nauw gedefinieerd. Via het bestandssysteem kun je als gebruiker niet bij je eigen bestanden die in Nextcloud staan, en Nexctloud kan niet bij je bestanden in je home-directory. De admin-gebruiker kan ook maar beperkt bij verschillende bestanden komen, alleen root kan overal bij.

Om via de gebruiker met SSH toegang de bestanden uit Nextcloud te benaderen, moeten die vrijgegeven worden via ACL. Hoe dat gaat, heb ik in dezelfde forumthread gepost:

# cd /home/yunohost.app/nexctloud/data/
# setfacl -Rm u:boudewijn_ssh:rx boudewijn/
# setfacl -dRm u:boudewijn_ssh:rx boudewijn/
# setfacl -m u:boudewijn_ssh:rx .
# setfacl -dm u:boudewijn_ssh:rx .

Er is telkens een regel voor de nieuwe default (met -d), en dezelfde voor de rechten op de bestaande bestanden. Daarnaast telkens een recursieve regel (-R) voor de data-directory van gebruiker boudewijn, en een niet-recursieve op de huidige directory (/home/yunohost.app/nextcloud/data/). Setfacl heeft -m nodig, daarmee geef je aan dat het een wijziging/modificatie is.

Synchronisatie

Zolang je via SSHFS enkel bestanden leest, blijft alles werken zoals vanouds. Als je ook bestanden wegschrijft via SSHFS, loopt die actie buiten Nextcloud om. Het bestand wordt daardoor niet in Nextcloud geregistreerd, en is daarvandaan niet zichtbaar. Er is een OCC-opdracht om de opslagruimte te scannen op wijzigingen en de database bij te werken.

WebDAV

Om het toevoegen van bestanden, en alle wijzigingen aan bestanden, meteen in Nextcloud beschikbaar te maken, moet de verbinding via WebDAV gemaakt worden. Het werkt minder snel, maar wordt op meer platformen ondersteund dan SSHFS.

Print this entry

Geplaatst op

Apt key van sury.org ongeldig

Bij het ophalen van pakketlijsten met apt update treedt er een fout op, 

root@akashaduocyen:~# apt update
Hit:1 http://ftp.debian.org/debian buster InRelease
Get:2 http://security.debian.org buster/updates InRelease [65.4 kB]                                                         
Get:3 http://ftp.debian.org/debian buster-updates InRelease [51.9 kB]                                                       
Get:4 https://packages.sury.org/php buster InRelease [6,823 B]                                                              
Hit:5 http://forge.yunohost.org/debian buster InRelease                       
Err:4 https://packages.sury.org/php buster InRelease
  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
Fetched 124 kB in 1s (122 kB/s)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
110 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Failed to fetch https://packages.sury.org/php/dists/buster/InRelease  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Zoeken op apt key sury.org of apt signatures were invalid: EXPKEYSIG B188E2B695BD4743 geeft voldoende resultaten, maar alleen 

apt-key adv --keyserver keys.gnupg.net --recv-keys B188E2B695BD4743

of 

curl -sSL -o /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

lost het probleem niet altijd op.

Soms bleek het nodig om eerst de bestaande sleutel te verwijderen:

apt-key del B188E2B695BD4743

gevolgd door toevoegen van de nieuwe sleutel.

Print this entry

Geplaatst op

Nextcloud fout bij upgrade: 1118 row size too large

Geen idee meer bij welke upgrade het speelde (NC18 naar NC20?), maar: 

An exception occurred while executing 'ALTER TABLE oc_social_3_stream ADD nid BIGINT UNSIGNED DEFAULT NULL, ADD chunk SMALLINT UNSIGNED DEFAULT 1 NOT NULL': SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

opgelost met:

su mysql 
mysql 
show databases; 
use nextcloud;
show columns from  oc_social_3_stream;


exit ;


cd /var/www/nextcloud/
 chmod +x occ
sudo -u nextcloud ./occ maintenance:repair

Print this entry

Geplaatst op

Yunohost onderhoud

Help, de Yunohost is niet bereikbaar!

Troubleshoot

Wat doet het nog? Een webserver bestaat uit een toren van losse systemen. Als een van de systemen het niet doet, stort de rest van de toren in. Vanaf de fundamenten naar boven zijn de bouwstenen die je het makkelijkste kunt controleren:

  1. Staat ‘ie aan?
    • Kun je zelf alleen controleren als hij bij je thuis staat
  2. Geeft het appparaat levenstekenen?
    • Kun je zelf alleen controleren als hij thuis staat
    • Hangt er ook vanaf wat voor appaatje je hebt
    • Orange Pi Zero: met seriele poort, verhaal voor een andere keer
    • Oude laptop: iets typen of muis bewegen
  3. Reageert de server op pings? In het geval van osba.nl:
    • ping 80.127.182.180
    • ping 2001:985:b79a:1:6d21:81ff:a52e:6f3
    • ping -4 osba.nl
    • ping -6 osba.nl
  4. Kun je met SSH in de server komen?
    • ssh admin@domeinnaam.nl
  5. Werkt de admin-pagina nog?
    • ga naar het IP van je server; je kunt het vinden via ping. Bijvoorbeeld:
    • https://[2001:985:b79a:1:6d21:81ff:a52e:6f3]
    • https://80.127.182.180
    • https://osba.nl/yunohost/admin
    • Als het werkt via het IP-adres, krijg je een beveiligingswaarschuwing vanwege het certificaat (SSL of TSL). Als je browser het toestaat, kun je verder gaan met de onveilige instelling. Als je het certificaat bekijkt en je weet dat het bij je server hoort kun je ook inloggen.
  6. Kun je inloggen op de gebruikerspagina?
    • Ga naar het reguliere login-adres voor Yunohost,
    • https://osba.nl/yunohost/sso/

Wat nu?

Het hangt er vanaf hoe ver je gekomen bent. Per nummertje:

  1. Het makkelijkste is natuurlijk als de server gewoon thuis staat en je de stroom kunt controleren. Als het apparaatje aan een batterij hangt, kan het maar zo zijn dat er een paar dagen eerder een stekker uitgetrokken is, en dat je het nu pas merkt.
  2. Kijken of er iets gebeurt gaat eigenlijk hetzelfde als met een laptop, mobiele telefoon of een computer. Vastlopen kan gebeuren als de voeding van de Orange Pi net niet sterk genoeg is. Hij gaat dan wel aan, maar eigenlijk doet ‘ie het voor de helft niet.
  3. Ping kun je voor het hele internet (en alle apparaten thuis) gebruiken om te kijken of ze bereikbaar zijn op het netwerk. Het commando stuurt een berichtje voor het apparaat dat je noemt, en als dat apparaat het ontvangt, stuurt het een antwoord terug. Zo ziet het er bijvoorbeeld uit:

    ping -4 osba.nl
    PING osba.nl (80.127.182.180) 56(84) bytes of data.
    64 bytes from online.osba.nl (80.127.182.180): icmp_seq=1 ttl=64 time=0.457 ms
    64 bytes from online.osba.nl (80.127.182.180): icmp_seq=2 ttl=64 time=0.092 ms

    Je kan een ping sturen naar een IP-adres of naar een domeinnaam. In het geval van IP-adres, kan het een van versie 4 (vier blokjes cijfers met een punt ertussen) of van versie 6 (heel veel cijfers en letters met dubbele punten ertussen) zijn. Daarom de verschillende voorbeelden.
    Voor computers zijn de IP-adressen het makkelijkste. Voor domeinnamen is een extra stap via DNS nodig. Elke extra stap is een stap die kan mislukken.
    Als je server reageert op ‘ping domeinnaam’, dan werkt het ook met minstens een van de twee IP-versies. Andersom hoeft niet. Als het wel werkt met het IP-adres, maar niet met de domeinnaam, dan is er een probleem met DNS. Voor alle Yunohosts die ik zelf ingericht heb, gaat DNS via your-webhost.nl (met een gebruikersnaam met qb….) of via dns.he.net (met de gebruikersnaam die daar bij hoort)
  4. Als er een reactie op de ping terugkomt, kun je proberen om met SSH in te loggen. Dat gaat met:
    ssh admin@domeinnaam
    Je logt in met het wachtwoord dat je ook voor de admin-pagina van Yunohost gebruikt (de witte pagina, met de instellingen).
    1. Misschien is het voldoende om het systeem opnieuw op te starten. Gebruiker ‘admin’ mag dat niet, maar gebruiker ‘root’ mag dat wel. Type:
      sudo reboot
      en dan enter. De verbinding wordt verbroken. Als dat genoeg was, dan is even later je website weer terug.
    2. Als dat niet genoeg was, dan wordt het wat lastiger. Misschien staat er iets in het logboek waarmee je op internet een oorzaak kunt vinden. Type:
      sudo tail -f /var/log/messages
      … en dan enter. De laatste regels van het logboek komen nu tevoorschijn. Als de server nog ergens mee bezig is, dan komt er een regeltje bij.
      Je kan stoppen met kijken door ctrl-c in te drukken.
      Verhaal voor een andere keer.
  5. Soms doet de normale loginpagina het niet, maar de adminpagina het nog wel. Je kan vanuit de adminpagina naar de diagnosepagina gaan. Dat is ook nog wel een beetje lastig, maar makkelijker te lezen dan de berichten rechtstreeks in het logboek. Ik ga er nu niet verder op in.
  6. Als we zover gekomen zijn zonder problemen, dan zou eigenlijk de website gewoon moeten werken. Probeer in te loggen op de zwarte pagina met de gekleurde blokjes. Als je standaaard naar een blog of andere pagina gaat, dan moet je achter het adres ‘/yunohost’ typen, bijvoorbeeld
    https://osba.nl/yunohost
    Je kan dan de verschillende apps proberen, om te zien of ze het allemaal niet doen, of dat er bijvoorbeeld een probleem is met alleen WordPress of alleen met Nextcloud.

Dat was een lang verhaal. Vaak als er een niet te groot probleem is, kun je met deze stappen de oorzaak vinden en verhelpen.

Software bijhouden

Als alles het doet dan is dat fijn. Maar het is wel belangrijk om bij te blijven met beveiligingsupdates. Sommige beveiligingsupdates worden door Yunohost zelf gedaan. Om volledig bij te werken, en ook nieuwe functionaliteit beschikbaar te maken, kun je het systeem bijwerken via de admin-pagina of via SSH.

update via admin-pagina

Een van de menupunten op de admin-pagina is systeem-update. Als je die aanklikt, wordt infomatie over alle updates opgehaald en weergegeven.

Daarna kun je kiezen of je het systeem wil bijwerken of de apps. In het laatste geval kun je ze ook een-voor-een bijwerken. Soms is dat nodig omdat de bovenste een probleem heeft bij de update, en de rest niet in een rijtje afgewerkt wordt. Soms wil je juist weer snel alleen het onderste programma bijwerken.

Bovenin de pagina wordt weergegeven bij welke stap van de upgrade Yunohost is: downloaden van de nieuwe versie, backup maken, installeren, etc. Daar wordt ook een berichtje gegeven als de upgrade klaar is, of als er juist iets fout gaat.

Update via SSH

Inloggen met SSH kan met een SSH-programma op je computer of op je telefoon, of via “Terminalscherm in je browser / shell in a box”. Je logt in met admin en het wachtwoord van admin (er komen bij het wachtwoord geen sterretjes of balletjes in beeld, dus gewoon typen en enter drukken).

Daarna kun je met drie commando’s het systeem bijwerken, telkens met enter achteraan de regel:

sudo yunohost tools update
sudo yunohost tools upgrade --system
sudo yunohost tools upgrade --apps

Laatst werkte Nextcloud niet meer na een upgrade. Bij het openen van Nextcloud werd een melding over onderhoudsmodus / maintenance mode getoond.

Het bleek dat Nextcloud na de update een nieuwe versie van een programmeertaal nodig had (PHP 7.3 ipv PHP 7.0). De upgrade dat wel de nieuwe versie van PHP geinstalleerd, maar gebruikte standaard nog versie 7.0. Daardoor lukte het me niet om de onderhoudsmodus te deactiveren:

sudo -u nextcloud php /var/www/nextcloud/occ maintenance:mode --off

gaf een foutmelding. Ik heb PHP handmatig laten wijzen naar versie 7.3 met sudo update-alternatives –set php /usr/bin/php7.3 , maar achteraf gezien had ik misschien moeten proberen de aanroep van PHP aan te passen ( dus sudo -u nextcloud /usr/bin/php7.3 /var/www/nextcloud/occ maintenance:mode –off ), dat merk ik vast later weer. Nextcloud doet het in ieder geval weer, en de rest van het systeem ook.

Print this entry

Geplaatst op

Public IPv4 subnet with Fritz!Box

Port forwarding kapot

De Engelstalige versie heeft het hele verhaal, hier mijn stappen om te voorkomen dat de Fritzbox een duplicaat apparaat krijgt. Zo’n duplicaat apparaat (dezelfde hostname met twee MAC-adressen) zorgt voor een heel irritante foutmelding bij het aanmaken van een nieuwe portforwarding of het aanpassen van een bestaande:

Een publiek IPv4 toewijzen

Voor Yunohosts met Armbian op OPi Zero’s volg ik bij benadering het volgende stappenplan:

  • Gewoon aansluiten en een adres per DHCP laten toewijzen
  • Blijf van de hostname af in de Fritzbox
  • Configureer het systeem via SSH op het locale IP
  • Zorg dat zowel een verbinding via ethernet als via seriele kabel beschikbaar is
  • Gebruik nmtui om het publieke IP in te richten
    • Activeer de nieuwe inrichting nog niet
  • Maak de ethernetkabel los
  • Gebruik de seriele verbinding om het apparaatje af te sluiten
  • Wacht totdat de Fritzbox het apparaatje van actieve naar inactieve aansluitingen verplaatst heeft in de thuisnetwerk-instellingen
  • Verwijder het apparaat uit de lijst met apparaten
    • Dat kan enkel wanneer de FB denkt dat het apparaat inactief is
    • Het heeft enkel effect wanneer de naam van het apparaat niet veranderd is vanaf de eerste keer dat de FB het apparaat gesignaleerd heeft
    • Soms helpt het de FB eens te rebooten, maar niet altijd, en het maakt het proces ook niet altijd sneller
  • Zodra je ‘m verwijderd hebt, sluit de ethernetkabel weer aan
  • Zet het apparaatje weer aan . network manager gebruikt de nieuwe configuratie om de netwerkaansluiting in te richten
    • Soms zie je het apparaat niet direct staan, omdat het met een naam gebaseerd op het IP-adres in de lijst gezet wordt
    • Pas de (onhandige) naam niet aan
  • Nu is het apparaat te bereiken op het publieke IP. Het inrichten van port forwardings mag geen problemen opleveren.

Troubleshooting

Print this entry

Geplaatst op

Fediverse met Nextcloud/nginX op Yunohost part II

Het resultaat van deel I was dat ik gebruikers op dezelfde server kon vinden: iedereen die een account op online.osba.nl heeft. Leuk, maar dat was niet wat ik voor ogen had. De afgelopen weken heb ik zo nu en dan een blik op het probleem geworpen, in de hoop dat me een makkelijke oplossing onder ogen zou komen. Helaas.

Vanavond heb ik er meer tijd dan ik had gehoopt besteed, maar ik heb wel een deel van de (weg naar de) oplossing gevonden. De test op webginger.net geeft nu een nuttig resultaat terug:

https://webfinger.net/lookup/?resource=wbk%40online.osba.nl

geeft:

Request log

18:20:13 Looking up WebFinger data for acct:wbk@online.osba.nl
18:20:13 GET https://online.osba.nl/.well-known/webfinger?resource=acct%3Awbk%40online.osba.nl

JSON Resource Descriptor (JRD)

{
  "subject": "acct:wbk@online.osba.nl",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "http://online.osba.nl/nextcloud/nextcloud/index.php/apps/social/@wbk"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

Dat was telkens 404, niets gevonden.

Meer details zijn (in het Engels) te vinden Yunohost forum, maar het belangrijkste deel is de benodigde configuratie en waar je het moet laten. Het configuratiebestand waar het om gaat is de nginx-configuratie op

/etc/nginx/conf.d/online.osba.nl.conf

Er zijn twee servers gedefinieerd, de onversleutelde op poort 80 en de versleutelde verbinding op poort 443. De eerste had na het installeren via Yunohost / Nextcloud alle redirects cadeau gekregen, die op poort 443 niets. Ik vond het opvallend, maar bij gebrek aan kennis van nginx deed het ook geen alarmbellen rinkelen. Het blijkt dat de verwijzingen op beid e servers gedefinieerd moeten staan, anders werkt het niet via TLS. Bovendien moet het een combinatie van doorverwijzing en herschrijven van de URL zijn:

Het gecombineerde stanza ziet er zo uit:

location = /.well-known/webfinger {
  rewrite ^ https://online.osba.nl/nextcloud/public.php?service=webfinger&$1 last; # $1 will use the first parameter (?resource=…)
}

Stop het stukje tussen de ‘include …’ en ‘log ..’ regels.

Ookal werkt de test op webfinger.net nu, het lukt nog niet om op de ene Nextcloud een gebruiker op een andere Nextcloud-server te vinden.

Wordt vervolgd…

Print this entry

Geplaatst op

Foto’s bewaren en delen met Nextcloud

Nextcloud is een systeem om allerlei dingen die op je computer of op je telefoon staan te bewaren of te delen. Bijvoorbeeld foto’s, muziek, plaatjes, savegames of backups.

Een blauwe, vierkante knop met de tekst 'Fotos en andere bestanden delen (Nextcloud)'
Zoek Nextcloud uit en klik erop

Je kunt gewoon inloggen op je Nextcloud door op het vierkantje de drukken en te bladeren in de bestanden die al naar Nextcloud gestuurd zijn, of je kan op je computer/telefoon instellen dat nieuwe foto’s automatisch geupload worden: backup (kopie voor de zekerheid) en synchronisatie (zodat de foto van je telefoon automatisch op je computer komt te staan).

Foto upload

Het hoofdscherm van Nextcloud ziet er ongeveer zo uit:

Een lijst met menu-items, direcories en foto's
Nextcloud startscherm

Het ziet er een beetje uit als de lijst met bestanden op je computer, maar dan op je webserver. Als je voor het eerst kijkt, zie je dat er tijdens de installatie van het systeem al wat voorbeeldbestanden neergezet zijn. Die kun je gerust weggooien.

Een nieuwe foto kun je met het plusje naast het huisje toevoegen. Als je het plusje aanwijst, komt er een menu’tje tevoorschijn waar je kun kiezen een nieuw bestand te uploaden (‘Upload file’/’Bestand uploaden’):

Het kleine menu'tje waar je kun kiezen een bestand te upoaden
Bovenaan de pagina, naast ‘All files’ / ‘Alle bestanden’

De foto is na een paar ogenblikken (afhankelijk van hoe groot de foto is en hoe snel de verbinding) te zien in de lijst met bestanden.

Foto delen

Drie balletjes en twee lijntjes: delen
poena@osba.nl als emailadres, of klik ‘Share link’

Onder elke foto (en elk ander bestand) staat een ikoontje, drie balletjes met streepjes ertussen. Dat is om aan te geven dat je iets kan delen. Als je het ikoontje aanklikt, krijg je een nieuw menu aan de rechterkant. Je kan een emailadres of de naam van iemand anders invullen om rechtstreeks te sturen, of je kan op ‘share link’ klikken om een hyperlink klaar te zetten. Die link moet je daarna zelf aan iemand sturen: met een email, overschrijven of een ander berichtje.

Klaar!

Je foto is nu bereikbaar voor iedereen aan wie je de link stuurt, of enkel voor degene aan wie je de email stuurde. Wat die mensen vervolgens doen weet je maar nooit, als je eenmaal iets gedeeld hebt op internet, is het voor altijd gedeeld.

Behalve de foto zelf delen, kun je ook iets over de foto zeggen, of andere mensen er iets over laten zeggen. Iedereen met een account op je Yunohost kan dat in ieder geval, maar je kan ook vrienden op hun eigen Nextcloud rechtstreeks benaderen. Het is me nog niet goed gelukt dat te laten werken, wordt vervolgd.

Print this entry

Geplaatst op

Een verhaal schrijven met WordPress

Zoek naar ‘inloggen’ om bij het loginscherm te komen.

Druk op het vierkantje voor WordPress om een nieuw verhaal te schrijven. Je krijgt een achtergrond-plaatje te zien, je moet een heel eind naar beneden schuiven om “Inloggen” te vinden onder het kopje “Meta”.

Je naam en wachtwoord worden al ingevuld.

Je gebruikersnaam wordt dan al ingevuld. Als dat een keer niet zo is: het is dezelfde naam als om in te loggen op Yunohost om bij de vierkantjes te komen.

De pagina verandert nu: er komt een stukje boven en aan de linkerkant is een nieuw menu. Bovenaan Dashboard, daaronder Berichten, Media en veel meer.

Wijs “Berichten” aan, en na een seconde komt er een klein menu’tje waar je “Nieuw bericht” kunt klikken. Het grootste deel van het scherm wordt nu wit, en bovenaan staat een stukje over blokken. Dat kun je op het plaatje hieronder ook zien, en als je het gelezen hebt, kun je het met het kruisje wegkrijgen.

Linksbovenaan “Berichten” aanwijzen, en dan “Nieuw bericht” aanklikken.

Het is niet zo goed te zien, maar je kan nu een titel schrijven. Ik heb als titel: “Een verhaal schrijven met WordPress”. Het staat bovenaan deze pagina.

Begin met typen om een titel te schrijven

Telkens als je op enter drukt, wordt er een nieuw blok gemaakt waarin je verder kunt typen. In zo’n blok kun je ook plaatjes en foto’s stoppen, zoals ik hier telkens gedaan heb.

Er kan nog veel meer met WordPress, maar nu kun je al allerlei verhalen schrijven.

Print this entry