YunoHost 3.3 testing / Call for feedback

Announcements
, ,
1

Hello everyone !

We just released a new testing version for YunoHost and would be happy to receive feedback before releasing it as a stable version :yum:

This release includes various highlights :sparkles: such as:

  • the rework on the app install page, which makes it more beautiful and includes important info about the level/state of the app (c.f. screenshot)
  • the root password shall now be synced with the admin password. In addition, and in order to improve security, passwords constrains have been increased to require passwords to not be too common and at least 8 characters (advices are also displayed to encourage users to use various kind of characters).
  • the Metronome configuration has been updated! Some features which were previously disabled should now be working.
  • a few important bugs were fixed (namely dyndns update sometimes not updating properly, or a bug with php apps uninstalls breaking php-fpm)
  • many improvements on translations!

Thanks to all the (numerous!) contributors (ljf, irinia11y, Maniack, e-lie, tbille, xaloc33, Bram, flashemade, Maranda, Josue, frju365, Aleks, randomstuff, jershon, Genma, tituspijean, Quent-in, MyNameIsTroll, ButterflyOfFire, Jibec, silkevicious, Krzysztof Dmowski, tYYGH, goofy-mdn)! :heart:

Detailed changelog

:rainbow: Highlights

:hammer_and_wrench: Misc fixes / improvements

  • [enh] Add OCSP Stapling to nginx configuration if using Lets Encrypt (YunoHost#533)
  • [enh] Add CAA record in recommended DNS conf (YunoHost#528)
  • [enh] Improve cookie security (SSOwat#103)
  • [enh] Redirect after logout if r URI argument exists (SSOwat#109)
  • [helpers] Add ynh_delete_file_checksum (YunoHost#524)
  • [helpers] When using ynh_setup_source, silent unecessary messages (YunoHost#545)
  • [helpers] Use more blocks for dd in ynh_string_random (YunoHost#569)
  • [fix] Potential key error when retrieving install_time (YunoHost#551)
  • [fix] Remove unappropriate ‘whoami’ ldap warning (moulinette#173)
  • [fix] Allow - in user last names (YunoHost#565)
  • [fix] Fix possible HTTP2 issue with curl (YunoHost#547)
  • [fix] Fix BASE/URI in ldap conf (YunoHost#554)
  • [fix] Use random serial number for CA (prevent browser from complaining about some selfsigned certs) (YunoHost#557)
  • [enh] Pass Host header to YunoHost API (YunoHost#560)
  • [enh] Sort backup list according to their date (YunoHost#562)
  • [fix] Improve UX when admin tries to allocate reserved email alias (YunoHost#553)
  • [fix] Misc fixes / improvements in SSOwat (SSOwat#91, SSOwat#92)

How to participate to the beta-testing :construction_worker_woman: :construction_worker_man:

:warning: Do not do this on a critical server !

In the command line, you can launch this command to switch to testing :

curl https://install.yunohost.org/switchToTesting | bash

(if you are familiar with bash scripting, you might want to read what this does before blindly running the command)

After this command, you should see that you are running YunoHost 3.3.0.

What to test ? :space_invader: :telescope:

Here are a few specific items for which tests and feedback would be quite important ! If you tweaked nginx or metronome’s conf manually, make sure to update / regen the conf with yunohost service regen-conf nginx --force and yunohost service regen-conf metronome --force.

  • Check that the last migration (0006?) ran successfully during the upgrade;
  • Check out the new app installation page in the webadmin and report anything that shocks you or that you find is not clear;
  • Try to change a user password from the SSOwat interface (try to put a dummy password) and check that what happens make sense to you;
  • Try to navigate to apps from the SSO, especially apps that require authentication and are installed on a different domain than the main domain
  • If you are familiar with XMPP, try to see with a compliance tester if your XMPP setup got improved compared to the previous Yunohost versions…
  • Check that HTTPS is still working properly with a Lets Encrypt certificate (bonus point if you find a way to validate that OCSP stapling is active ;P)
8 Likes
2

Thanks for the work. Here is a quick feedback

yunohost service regen-conf

output of yunohost service regen-conf

root@yunohost:~# yunohost service regen-conf

Success! The configuration has been updated for service 'dnsmasq'
dnsmasq: 
  applied: 
    /etc/resolv.dnsmasq.conf: 
      status: updated
  pending: 
root@yunohost:~# 
root@yunohost:~# yunohost service regen-conf
Success! The configuration has been updated for service 'dnsmasq'
dnsmasq: 
  applied: 
    /etc/resolv.dnsmasq.conf: 
      status: updated
  pending: 
root@yunohost:~#
  • Check that the last migration (0006?) ran successfully during the upgrade;

:+1:

  • Check out the new app installation page in the webadmin and report anything that shocks you or that you find is not clear;

First impression of the new panel:

  • Too many apps showned by default, it was like an “overflow” of information (and no category)
  • All apps sare howned so it made me feel that all can be installed and that they will work. The distinction between official and community is not really obvious IMO.
  • button “Only validated apps” does nothing (should list only officials apps?)
  • Try to change a user password from the SSOwat interface (try to put a dummy password) and check that what happens make sense to you;
  • changed the password twice and it worked each time.
  • Try to navigate to apps from the SSO, especially apps that require authentication and are installed on a different domain than the main domain
  • Apps on the different domain does not work anymore. The SSO login screen is displayed (freashrss, kanborad, agendac, roundcube, transmission)

main domain : a
different domain: b

  • If you are familiar with XMPP, try to see with a compliance tester if your XMPP setup got improved compared to the previous Yunohost versions…
  • Check that HTTPS is still working properly with a Lets Encrypt certificate (bonus point if you find a way to validate that OCSP stapling is active ;P)

Did not tried this

2 Likes
3

Bonsoir @Aleks ,

J’ai fait une sauvegarde et passé la commande pour passer en testing.
Tout s’est bien passé.
J’ai, comme indiqué, exécuté la migration 6 via l’interface web du panel.
Cette migration a eu pour conséquence de changer mon mot de passe root par le mot de passe admin de l’interface web.
J’ai donc pu me reconnecter en SSH avec l’utilisateur root et du coup avec le mot de passe admin - maintenant commun au panel web.
J’ai pu me connecter également à mon NextCloud et tout y était bien là.

Bravo la Team Dev’ YunoHost :slight_smile:

ppr

2 Likes
4

Hello,

I do not think this is a good idea. Or it should be optionnal. Admin and root have not the same rights on the server. I prefer having too different passwords.

5

Do they ? If you are root, then you have all rights, and in particular you can su admin. And admin can sudo su without password so you are basically root. My understanding is that the only reasons behind the existence of the root user are :

  • Yunohost had to have some sort of root-like user in the LDAP ;
  • (more like a small, nice-to-have side effect) admin is a different name than root so you escape 90% of automatic bruteforce attacks on root

So having different passwords is just unecessary complexity in that case, and it opens a security hole if people forget to change an old / default root password somehow.

But if you really want to have different password, you can still define the admin password, then change the root password with passwd. Just be aware that if you change the admin password again, you need to re-set the root password.

6

I did not know admin ssh connection was possible and you could sudo su without password. I don’t use this. I usually install a Debian classical machine with root and user which I use for distant connection.

On a classical Debian installation, distant root access is disabled.
You make admin the default account access on all YunoHost installations and it is not so original. Perhaps there less brute forc attacks on admin than on root, but they exist. As ftp, mail… accounts. But that’s no the point, I ignored this behaviour (sudo su without password) and use my own custom account to connect to the server.

root password is set during Debian installation so it should not be " old ". :slight_smile:

Thanks for the answer, I understand better this change.

7

I wish it could be that simple :wink: But one use case is to use pre-installed image, and some people run the postinstall directly from the web browser and might end up never connecting through SSH … So in that case, they might end up with an old/default password - so it shall be changed one way or another :confused:

8

When running testing version, is there a way to switch back to stable ? Or to migrate from testing to the next stable when available?

( I did not break my Yunohost with this version :sweat_smile: :no_mouth:)

1 Like
9

You should edit /etc/apt/sources.list.d/yunohost.list (not 100% sure about the path) and remove 'testing'. (I’ll write a script that does this automatically at some point …)

This way, once that more up-to-date stable packages will be available, they’ll replace your current testing packages (when doing apt update && apt dist-upgrade)

2 Likes
10

Hello,

Everything seems ok after upgrading to YNH 3.3 on my raspberry 2B, great work :tada:

I have just something to say about changing user passwords :

  • From SSOwat interface : works well and error message is clear when password is too weak :+1:

  • From admin panel : putting a weak password causes an internal error. A look into the traceback can put us on the way but it’s really not explicit.
    In this case, having password inputs and advices about password strength text in red after submitting a weak password seem clearer to me

1 Like
11

I followed your instructions and upgraded smoothly to stable 3.3.1 :tada:

Apps on an an other domain run again :cowboy_hat_face:

root@yunohost:~# sudo apt-get update && sudo apt-get dist-upgrade
Réception de:1 http://debian.mirrors.ovh.net/debian stretch-updates InRelease [91,0 kB]
Ign:2 http://debian.mirrors.ovh.net/debian stretch InRelease                                   
Réception de:3 http://debian.mirrors.ovh.net/debian stretch Release [118 kB]                                              
Réception de:4 http://security.debian.org stretch/updates InRelease [94,3 kB]                                             
Réception de:5 http://forge.yunohost.org/debian stretch InRelease [18,2 kB]                                               
Réception de:7 http://security.debian.org stretch/updates/main Sources [185 kB]         
Réception de:8 http://security.debian.org stretch/updates/main amd64 Packages [460 kB]
Réception de:9 http://security.debian.org stretch/updates/main Translation-en [200 kB]
Réception de:10 http://forge.yunohost.org/debian stretch/stable amd64 Packages [4 305 B]
1 171 ko réceptionnés en 2s (400 ko/s)
Lecture des listes de paquets... Fait
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
  ssowat yunohost yunohost-admin
3 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 9 639 ko dans les archives.
Après cette opération, 8 192 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] 
Réception de:1 http://forge.yunohost.org/debian stretch/stable amd64 ssowat all 3.3.1 [405 kB]
Réception de:2 http://forge.yunohost.org/debian stretch/stable amd64 yunohost all 3.3.1 [665 kB]
Réception de:3 http://forge.yunohost.org/debian stretch/stable amd64 yunohost-admin all 3.3.1 [8 569 kB]
9 639 ko réceptionnés en 1s (6 422 ko/s)    
(Lecture de la base de données... 61304 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../archives/ssowat_3.3.1_all.deb ...
Dépaquetage de ssowat (3.3.1) sur (3.3.0) ...
Préparation du dépaquetage de .../yunohost_3.3.1_all.deb ...
Dépaquetage de yunohost (3.3.1) sur (3.3.0) ...
Préparation du dépaquetage de .../yunohost-admin_3.3.1_all.deb ...
Dépaquetage de yunohost-admin (3.3.1) sur (3.3.0) ...
Paramétrage de ssowat (3.3.1) ...
Traitement des actions différées (« triggers ») pour systemd (232-25+deb9u6) ...
Paramétrage de yunohost (3.3.1) ...
Regenerating configuration, this might take a while...
Success! The configuration has been updated for service 'ssl'
Success! The configuration has been updated for service 'dnsmasq'
Launching migrations..
Warning: No migrations to run
Restarting YunoHost firewall...
Paramétrage de yunohost-admin (3.3.1) ...
12

How can we override this default behavior ?
Our CI will fail on every app with a password, and we need to override that behavior for all dev instances.

13

Yes, you can run the following commands and it should disable every password strength check

$ yunohost settings set security.password.admin.strength -v -1
$ yunohost settings set security.password.user.strength -v -1
1 Like
14

Désolé je ne sais pas trop s’il faut poster ici ou sur le post de testing de la 3.4.
Sur la version 3.3, j’ai quelques problèmes à la création d’un nouvel utilisateur.
J’ai l’impression que c’est lié à Yunohost.

Échec de l’exécution du script « /etc/yunohost/hooks.d/post_user_create/50-nextcloud »
setfacl: /home/daddyetamai: No such file or directory
Échec de l’exécution du script « /etc/yunohost/hooks.d/post_user_create/50-wallabag2 »
fos:user:create [--super-admin] [--inactive] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--]
ed: failed to open stream: Permission denied
The stream or file "/var/www/wallabag2/var/logs/prod.log" could not be open
[UnexpectedValueException]
chown: invalid user: ‘nomDeMonUtilisateur’
ln: failed to create symbolic link '/home/nomDeMonUtilisateur/Multimedia': No such file or directory
L’utilisateur a été créé
La configuration de SSOwat a été générée
Impossible de créer le dossier personnel de l’utilisateur

Pour info, j’ai un disque externe monté automatiquement sous /home
Voici ce que donne un ls -ld /home :

drwxr-xr-x 25 root root 4096 Dec 27 04:00 home

Y a-t-il un problème de ce côté là ?

15

Ça m’a l’air d’etre un problème lié à wallabag, qui rajoute un hook de type post_user_create … pas sur qu’on puisse faire grand chose du côté du core, il faut aller toquer à la porte du packageur je dirais…

17

Here is the result of the XMPP compliance test on my server using https://github.com/iNPUTmice/caas

RFC 6121: Roster Versioning                                      PASSED
XEP-0045: Multi-User Chat                                        PASSED
XEP-0065: SOCKS5 Bytestreams (Proxy)                             FAILED
XEP-0115: Entity Capabilities                                    PASSED
XEP-0153: vCard-Based Avatar (MUC)                               PASSED
XEP-0160: Best Practices for Handling Offline Messages           PASSED
XEP-0163: Personal Eventing Protocol                             PASSED
XEP-0191: Blocking Command                                       PASSED
XEP-0198: Stream Management                                      PASSED
XEP-0280: Message Carbons                                        PASSED
XEP-0313: Message Archive Management                             PASSED
XEP-0313: Message Archive Management (Multi-User Chat)           PASSED
XEP-0352: Client State Indication                                PASSED
XEP-0357: Push Notifications                                     PASSED
XEP-0363: HTTP File Upload                                       PASSED
XEP-0368: SRV records for XMPP over TLS                          FAILED
XEP-0384: OMEMO Encryption                                       PASSED
XEP-0398: User Avatar to vCard-Based Avatars Conversion          PASSED
XEP-0411: Bookmarks Conversion                                   PASSED

Informational tests:
XEP-0077: In-Band Registration                                   FAILED
XEP-0156: Discovering Alternative XMPP Connection Methods (HTTP) FAILED
XEP-0157: Contact Addresses for XMPP Services (Abuse)            FAILED
XEP-0363: HTTP File Upload (CORS Headers)                        FAILED
1 Like