YunoHost 4.2 testing

Hi @mzed2k,
The switch to testing is done by changing the update repository files :

  • /etc/apt/sources.list
  • all the files present in /etc/apt/sources.list.d/

You can change them back.

You can check which files were edited by running this :

$ cd /etc/apt
$ grep -R testing .
./sources.list.d/yunohost.list.save:deb http://forge.yunohost.org/debian/ buster stable testing
./sources.list.d/yunohost.list:deb http://forge.yunohost.org/debian/ buster stable testing

Once you found which files/lines to edit, you just have to remove the word testing from those.

That being done, just run this to “commit the changes” and rollback to stable :

apt-get update
apt-get dist-upgrade -y
1 Like

Thanks, I also switch to testing without knowing ! I came back to stable for my prod server ^^

Thanks, @Salamandar ,
I will give it a try on the week-end!
Thanks,
Martin

Bonsoir,

Je viens de passer mon Raspberry Pi 3 B “up-to-date” en “Testing”.

Voici un résumé tronqué du Terminal :

Success! The application catalog has been updated!
apps:
system:
0:
current_version: 4.1.4
name: moulinette
new_version: 4.2.0
1:
current_version: 4.1.3
name: ssowat
new_version: 4.2.0
2:
current_version: 4.1.4
name: yunohost-admin
new_version: 4.2.0
3:
current_version: 4.1.7.4
name: yunohost
new_version: 4.2.0

The following NEW packages will be installed:
acl python3-argcomplete python3-bottle python3-certifi python3-chardet
python3-dnspython python3-gevent python3-gevent-websocket python3-greenlet
python3-idna python3-jinja2 python3-ldap python3-markupsafe
python3-miniupnpc python3-openssl python3-packaging python3-psutil
python3-publicsuffix python3-pyasn1 python3-pyasn1-modules python3-pyparsing
python3-requests python3-toml python3-tz python3-urllib3 python3-yaml
The following packages will be upgraded:
moulinette ssowat yunohost yunohost-admin
4 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.7 MB/10.7 MB of archives.

Setting up yunohost (4.2.0) 

Installing new version of config file /etc/bash_completion.d/yunohost 

Regenerating configuration, this might take a while

The configuration file ‘/etc/cron.d/yunohost-dyndns’ is now managed by YunoHost (category yunohost).
Configuration updated for ‘yunohost’
The configuration file ‘/etc/ssh/sshd_config’ has been manually modified and will not be updated
Configuration updated for ‘apt’
Configuration updated for ‘nginx’
Configuration updated for ‘dnsmasq’
The configuration file ‘/etc/fail2ban/jail.conf’ has been manually modified and will not be updated
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO)
Launching migrations

No migrations to run
Re-diagnosing server health

Found 1 significant issue(s) related to Base system!
Everything looks good for Internet connectivity! (+ 1 ignored issue(s))
Everything looks good for DNS records!
Everything looks good for Ports exposure!
Everything looks good for Web!
verything looks good for Services status check!
Everything looks good for System resources!
Everything looks good for System configurations! (+ 2 ignored issue(s))
To see the issues found, you can go to the Diagnosis section of the webadmin, or run ‘yunohost diagnosis show --issues’ from the command-line.
(Reading database 
 55608 files and directories currently installed.)
Preparing to unpack 
/yunohost-admin_4.2.0_all.deb 

Unpacking yunohost-admin (4.2.0) over (4.1.4) 

Setting up yunohost-admin (4.2.0) 

Processing triggers for systemd (241-7~deb10u6+rpi1) 

Processing triggers for man-db (2.8.5-2) 

Done!

YunoHost package upgrade completed.
Press [Enter] to get the command line back

Il y a une ligne qui me pose question : c’est grave ?

ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO)

La seule chose que j’ai faite pour le moment est de naviguer dans -la nouvelle- interface web sans problùme.
J’ai aussi lancĂ© un diagnostic qui m’a bien relevĂ©, tout en les gardant ignorĂ©es, les “anomalies” que j’avais prĂ©cĂ©demment ignorĂ©es suite au “tweak” volontaire.

Merci Ă  l’équipe <3

ppr

Oui et non, il faut creuser un peu :sweat_smile:

Si tu te connecte en root (ou bien depuis admin, puis deviens root avec sudo su) : est que la commande mysql (sans argument) ouvre bien un shell, ou est-ce que tu as la mĂȘme erreur ?

Bonsoir,

VoilĂ  le retour :

admin@:~$ sudo su
root@
:/home/admin# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 15
Server version: 10.3.27-MariaDB-0+deb10u1 Raspbian 10
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
MariaDB [(none)]>

Ça semble OK du coup, non ?

ppr

Oui ça a l’air goude :+1:

1 Like

When I try to access the services in the webadmin I get this error.
I don’t remember which of my actions led to such a disaster (I remember trying to remove Movim service with CLI
)

@ericg : cheers, should be fixed by services.py, python3: missing decode() in subprocess output fetch · YunoHost/yunohost@4f44df3 · GitHub in the next iteration :stuck_out_tongue_winking_eye:

1 Like

I am upgrading to 4.2.1. This message was not shown at the top of the page as it was the case before:

The special upgrade will continue in the background. Please don’t start any other actions on your server for the next ~10 minutes (depending on hardware speed). After this, you may have to re-log in to the webadmin. The upgrade log will be available in Tools → Log (in the webadmin) or using ‘yunohost log list’ (from the command-line).

The message was hidden on the buttom and only visible when clicking on the message thet yunohost is upgrading.

EDIT: Screenshot.

One has to click there

And after one more click you see the message

Hi,
Just upgraded my server from 4.2.0 to 4.2.1 and I get 500 errors on the portal and every application.
I have this recurring error in the nginx -error.log:

2021/04/10 15:02:12 [error] 853#853: *466 lua entry thread aborted: runtime error: /usr/share/ssowat/access.lua:296: bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
coroutine 0:
        [C]: in function 'pairs'
        /usr/share/ssowat/access.lua:296: in function </usr/share/ssowat/access.lua:1>, client: 192.168.1.254, server: <domain>, request: "GET /ynhtheme/custom_overlay.css HTTP/2.0", host: "monin.net", referrer: "https://<domain>/"

All systemd services are running OK, yet I also lost the possibility to log on my XMPP account via Pidgin (“Vous voulez un chiffrement, mais il n’est pas disponible sur ce serveur”).

Could you please point me to where to look for more hints?
Thanks!

that’s weird ? sounds like you’d have no "“permissions” entry in /etc/ssowat/conf.json ?

What if you run yunohost app ssowatconf ?

OK, it shows an LDAP error, and slapd has been actually failing to load since the update (didn’t see it, my bad).
journalctl -u slapd shows:

avril 10 14:49:05 Orwell systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
avril 10 14:49:05 Orwell slapd[511]: @(#) $OpenLDAP: slapd  (Feb 14 2021 18:32:34) $
                                             Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
avril 10 14:49:05 Orwell slapd[511]: main: TLS init def ctx failed: -1
avril 10 14:49:05 Orwell slapd[511]: DIGEST-MD5 common mech free
avril 10 14:49:05 Orwell slapd[511]: DIGEST-MD5 common mech free
avril 10 14:49:05 Orwell slapd[511]: slapd stopped.
avril 10 14:49:05 Orwell slapd[511]: connections_destroy: nothing to destroy.
avril 10 14:49:05 Orwell slapd[413]: Starting OpenLDAP: slapd failed!
avril 10 14:49:05 Orwell systemd[1]: slapd.service: Control process exited, code=exited, status=1/FAILURE
avril 10 14:49:05 Orwell systemd[1]: slapd.service: Failed with result 'exit-code'.
avril 10 14:49:05 Orwell systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
avril 10 14:49:08 Orwell systemd[1]: slapd.service: Service RestartSec=3s expired, scheduling restart.
avril 10 14:49:08 Orwell systemd[1]: slapd.service: Scheduled restart job, restart counter is at 1.
avril 10 14:49:08 Orwell systemd[1]: Stopped LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

This is a super obscure message but i know from experience that it’s related to a bad certificate 
 Are you aware of anything related to /etc/yunohost/certs/yunohost.org/crt.pem or key.pem ?

# ll /etc/yunohost/certs/yunohost.org/
total 16
-rw-r----- 1 root ssl-cert 1241 avril  3 13:31 ca.pem
-rw-r----- 1 root ssl-cert 4501 mai    2  2016 crt.pem
-rw-r----- 1 root ssl-cert 1704 mai    2  2016 key.pem

I’ve seen the 4.2.1 hotfix was related to ACL, nothing related to certificates
?

No but I’m starting to wonder about side effects of some changes in certificate in 4.2 that only surfaced because of the restart of slapd

(Also now that I think about it, maybe the XMPP issue is also related to slapd not starting, which in the yunohost world is kinda catastrophic)

Can you check ls -l /etc/ssl/certs/ca-yunohost_crt.pem and confirm it’s a symlink pointing to /etc/yunohost/certs/yunohost.org/ca.pem ?

Confirmed:

# ls -l /etc/ssl/certs/ca-yunohost_crt.pem
lrwxrwxrwx 1 root root 39 avril  3 13:31 /etc/ssl/certs/ca-yunohost_crt.pem -> /etc/yunohost/certs/yunohost.org/ca.pem

Okay, let’s try something: edit /etc/ldap/slapd.ldif

Find the lines

# TLS Support
olcTLSCertificateFile: /etc/yunohost/certs/yunohost.org/crt.pem
olcTLSCertificateKeyFile: /etc/yunohost/certs/yunohost.org/key.pem

And replace yunohost.org by yourmaindomain.tld ?

Then let’s try to restart slapd


Edit: hmpf in fact propagating the change is not that trivial 
 you need to do :

  # Validate the new slapd config
  # To do so, we have to use the .ldif to generate the config directory
  # so we use a temporary directory slapd_new.d
  rm -Rf /etc/ldap/slapd_new.d
  mkdir /etc/ldap/slapd_new.d
  slapadd -n0 -l /etc/ldap/slapd.ldif -F /etc/ldap/slapd_new.d/ 2>&1 \
      | grep -v "none elapsed\|Closing DB" || true
  # Actual validation (-Q is for quiet, -u is for dry-run)
  slaptest -Q -u -F /etc/ldap/slapd_new.d

  # "Commit" / apply the new config (meaning we delete the old one and replace
  # it with the new one)
  rm -Rf /etc/ldap/slapd.d
  mv /etc/ldap/slapd_new.d /etc/ldap/slapd.d

  chown -R openldap:openldap /etc/ldap/slapd.d/

 service slapd force-reload

Did the whole procedure (the change is taken into account), but the service still fails to load with the same cryptic message