Beta-stage testing for Yunohost 11.0/Bullseye and Buster->Bullseye migration

Announcements
1

Following the alpha-testing opened a few weeks ago, we are happy to announce that we are moving to the beta-testing stage for Bullseye :tada: !

The feedback from the alpha-testing was pretty positive and allowed to polish a few issues and rough edges. Therefore we consider that it should be okay to upgrade to or install a fresh Yunohost 11.0+ running on Bullseye for a production server if you are a tech-savvy person not afraid to debug stuff if needed. However, you should still remain careful, especially when running the Buster->Bullseye migration depending on the complexity of your setup (but doing so helps spotting issues !). Additionally, some apps are still known to not be Bullseye-ready yet though fixes are on the way for many of them.

:construction: Please keep in mind that this is a beta-testing and small issues or edge-cases are still expected, so be careful. :construction:

:scroll: Detailed changelog

Show/Hide
  • [mod] Various tweaks for Python 3.9, PHP 7.4, PostgreSQL 13, and other changes related to Buster->Bullseye ecosystem
  • [mod] debian: Moved mysql, php, and metronome from Depends to Recommends (#1369)
  • [mod] apt: Add sury by default (#1369)
  • [enh] mysql: Drop super old mysql config, now rely on Debian default (44c972f
144126f)
  • [enh] regenconf/helpers: Better integration for postgresql (#1369)
  • [mod] quality: Rework repository code architecture (#1377)
  • [mod] quality: Rework where yunohost files are deployed (yunohost now a much closer to a python lib with files in /usr/lib/python3/dist-packages/yunohost/, and other “common” files are in /usr/share/yunohost) (#1377)
  • [enh] upgrade: Try to implement a smarter self-upgrade mechanism to prevent/limit API downtime and related UX issues (#1374)
  • [mod] regenconf: store tmp files in /var/cache/yunohost/ instead of the misleading /home/yunohost.conf folder (00d535a6)
  • [mod] dyndns: rewrite tsig keygen + nsupdate using full python, now that dnssec-keygen doesnt support hmacsha512 anymore (63a84f53)
  • [mod] app: During app scripts (and all stuff run in hook_exec), do not inject the HOME variable if it exists. This aims to prevent inconsistencies between CLI (where HOME usually is defined) and API (where HOME doesnt exists) (f43e567b)
  • [mod] quality: Drop legacy commands or arguments listed below
    - Drop --other_vars options in ynh_add_fail2ban_config and systemd_config helpers
    - Drop deprecated/superold ynh_bind_or_cp, ynh_mkdir_tmp, ynh_get_plain_key helpers
    - Drop obsolete yunohost-reset-ldap-password command
    - Drop obsolete yunohost dyndns installcron and removecron commands
    - Drop deprecated yunohost service regen-conf command (see tools regen-conf instead)
    - Drop deprecated yunohost app fetchlist command
    - Drop obsolete yunohost app add/remove/clearaccess commands
    - Drop deprecated --installed and --filter options in yunohost app list
    - Drop deprecated --apps and --system options in yunohost tools update/upgrade (no double dashes anymore)
    - Drop deprecated --status and --log_type options in yunohost service add
    - Drop deprecated --mail option in yunohost user create

:space_invader: What to test ?

(N.B. : all these can be tested independently)

Pre-installed images


 Upcoming 
 we need to work on this before the stable release : classic x86 ISO image, RPi image, other-ARM-boards image 


Installing a fresh YunoHost on top of a fresh Debian 11/Bullseye

$ wget https://install.yunohost.org/bullseye -O install_script
$ bash install_script -d testing

Migrating an existing YunoHost 4.x/Buster server to 11/Bullseye

YunoHost 4.4.x (currently testing) ships a migration that allows to upgrade to YunoHost 11.x/Bullseye.

Before going through this process, we reiterate that ideally, you should have a way to entirely rollback your server before proceeding with the upgrade. That way, if you spot issues, we’ll be able to provide a fix then validate that the fix works by re-running the upgrade from the same starting point.

  1. Switch to testing by running:

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

  1. After upgrading, in the webadmin, under Tools > Migrations, you should now see an available migration to upgrade to Bullseye. Read the disclaimer and start the migration.

  2. 
 be patient, this will take a while. But try to stay attentive to what’s going on. Share the detailed log if anything that goes wrong.

  3. Ideally after the upgrade, test that everything (e.g. apps installed) still works as expected.

24 Likes
3

Migration done, all services up and running after the reboot.

Some warnings but nothing abnormal or worrying during the migration process.

Everything went smoothly otherwise :heart:

6 Likes
4

I will use this one post to follow up with my upgrades, expect multiple edits. :slight_smile:

  1. RPi3, used locally for testings: No issue with upgrade from 4.4.0. :white_check_mark:
    • Two apps on the system with no issues after upgrade: ZeroTier, and in-dev Deconz app.
    • Since I only access it via .local domains, I discovered that yunomdns was not started, seemingly due to a systemd warning. PR opened to fix that.
    • One additional thought, my yunomdns service is not enabled, so won’t start at boot. It may be a legacy issue from my development of the feature, but maybe adding a setting somewhere in the webadmin would be nice. Or assume that anytime there’s a .local domain in the system, we make sure the service is enabled?
  2. VPS amd64:
  3. :warning: RPi4 ARM64:
    • Migration fails due to homeassistant-ynh-deps : Depends: libmariadbclient-dev but it is not going to be installed. Manually installing that package and apt upgrade'ing allows for the upgrade to continue.
      • During upgrade, the system asks to review changes to configuration files:
        • /etc/sshd_config : refused, it was removing anything related to YunoHost
        • /etc/default/useradd, /etc/default/dnsmasq, /etc/dnsmasq.conf, /etc/fail2ban/jail.conf: accepted
        • /etc/ldap/ldap.conf: refused, same as above
        • 
 anyway I feel that the accepted ones will get rewritten upon next YunoHost’s regen-conf
      • migration still fails with same error as above. :confused:
        • solved by apt-mark unhold homeassistant-ynh-yunodeps then apt install libmariadbclient-dev-compat then running migration again.
        • yunohost tools regen-conf dnsmasq nsswitch fail2ban -fbut fail2ban does not start anymore (reason: ERROR Could not find server)
3 Likes
5

Hi there,

Thanks for the huge work for Bulleyes :slight_smile:

I tried the migration this evening : it tooks about 1 hours on an apud2d4 (amd64).

At this end, only php7.3 and 7.4 were not working, and it was not possible to start them from the web interface. Many of the application were not accessible.
I rebooted the server, and most of it work now (email, rouncube, netdata, nextcloud, piwigo, aeneria, element).

Only php 7.3 won’t start, photoview, funkwhale, and matrix (this last is more annoying).

For matrix, the error is the following:

Jan 20 21:10:28 systemd[1]: Starting Synapse Matrix homeserver...
Jan 20 21:10:28 python[8195]: /opt/yunohost/matrix-synapse/bin/python: Error while finding module specification for 'synapse.app.homeserver' (ModuleNotFoundError: No module named 'synapse')
Jan 20 21:10:28 systemd[1]: matrix-synapse.service: Control process exited, code=exited, status=1/FAILURE
Jan 20 21:10:28 systemd[1]: matrix-synapse.service: Failed with result 'exit-code'.
Jan 20 21:10:28 systemd[1]: Failed to start Synapse Matrix homeserver.

For php 7.3, I have the following service status:

● php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2022-01-20 21:09:20 CET; 5min ago
       Docs: man:php-fpm7.3(8)
    Process: 8010 ExecStart=/usr/sbin/php-fpm7.3 --nodaemonize --fpm-config /etc/php/7.3/fpm/php-fpm.conf (code=exited, status=78)
    Process: 8020 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.3/fpm/pool.d/www.conf 73 (code=exited, status=0/SUCCESS)
   Main PID: 8010 (code=exited, status=78)
        CPU: 328ms

edit :
It seems that synapse (matrix) and php 7.3 issue are related :

[20-Jan-2022 21:29:36] ERROR: Another FPM instance seems to already listen on /run/php7.3-fpm-synapse.sock

For funkwhale and photoview, I am not entirely sure that they were working well before the migration, so I will dig it later.

Again, I am very impressed how it went well :confetti_ball:

6

The switchtoTesting script should be run with sudo :wink:

7

If we encounter a bug while testing Bullseye, and don’t know if it’s new or existed in Stretch, would you rather we just post it here (as below) or file a general bug on GitHub?

For example, I’m encountering a bug where it looks like Yunohost is trying to log in to the mail server of the person I’m emailing, but I don’t know if this happened on Stretch, as I never tried email stuff on my production server
 eg:

This is the mail system at host YunohostDomain.tld

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<[recipient@RecievingMailHost.tld](mailto:recipient@RecievingMailHost.tld)>: host mail.ReceivingMailHost.tld[50.87.146.185] said:
550-Verification failed for <[sender@YunohostDomain.tld](mailto:sender@YunohostDomain.tld)> 550-No Such User
Here" 550 Sender verify failed (in reply to RCPT TO command)

All diagnosis sections for the sending domain report that everything is good.

PS The other server is also mine, not running Yunohost, so no one is likely to be getting angry at log in attempts at this stage. :stuck_out_tongue_winking_eye:

8

Hello,

I try to migrate from RPi3B (arm64, exotic ssh port and boot ssd on usb) but it failed.
It can’t upgrade postgresql 11 to 13 https://paste.yunohost.org/raw/ocagadukov
Then, when i reboot in order to launch this postgresql migration, dhcp.service failed :

failed to start dhcp client daemon
systemctl status dhcpd.service
loaded /lib/systemd/system/dhcpd.service; enable; vendor preset: enable
drop-in /etc/systemd/system/dhcpd.service.d
wait.conf
failed result: exit code

I reinstall from the YunoHost RPi image (armhf and micro sd-card) without post-installation but with update/upgrade before restore my archive and try to migrate again.
When i reboot the same error with dhcpd.service and searx app failed to restore https://paste.yunohost.org/raw/pihipiluli

I reinstall from the YunoHost RPi image (armhf and boot ssd on usb) without post-installation but with update/upgrade before restore my archive and don’t try to migrate again.
Searx app failed to restore.

ppr

9

Sounds like it’s unhappy about log directory permissions:

Jan 21 17:08:22 uwsgi[23446]: open("/var/log/uwsgi/searx/searx.log"): Permission denied [core/logging.c line 288]

Can you check the output of namei -l /var/log/uwsgi (or maybe /var/log/uwsgi/searx but maybe the dir doesnt exist if the app aint installed right now)

If you’re able to reproduce the issue, it would be nice to look at the service logs with journalctl -u dhcp -n 1000 --no-pager --no-hostname

10

Hi,

For searx, i’ve reinstall it (without any problem).
If i’ve got time tomorrow, i’ll retry the migration Buster-Bullseye and i’ll take a look at your commands for searx ( namei -l /var/log/uwsgi and namei -l /var/log/uwsgi/searx).

When the dhcpd.service error occurs ssh and other network stuff is down.
I’m not always very comfortable with cli so is there a way to write the result of journalctl -u dhcp -n 1000 --no-pager --no-hostname into a file that i can share (as things like journalctl -u dhcp -n 1000 --no-pager --no-hostname > dhcpd.service.journalctl.1000.txt) ?

edit :
After before and reboot sudo journalctl -u dhcp -n 1000 --no-pager --no-hostname is (because admin is not in groups adm, systemd-journal)

–Journal begins at Fri 2022-01-22 17:10:53 GMT, ends at >Sat 2022-01-22 11:04:20 GMT. –
– No entries –

I’m going to poweroff the RPi and wait before reinstall from YunoHost and restore from YunoHost backup if you want to see something else. Note that i had to have keyboard and screen connected because even on local network nothing works (nor ssh on 22 or exotic port and 80 or 443 via web browser).

ppr

11

Hello,
After yunohost update to 4.4, i tried the migration tool to bulleyes on a RP4, but I ran into a dependencies problem:
https://paste.yunohost.org/raw/botiqiwivo
I used the web interface to launch the migration, but i’m mostly sure it doesn’t matter for my problem.

12

:white_check_mark: Upgraded on a fresh 4.3 install on scaleway VPS : all good ! Nextcloud and Searx survived. It’s a big jump from 4.3 to 11.0.2 :laughing:

But the :scream: list of broken apps is frightening at this point in time (mastodon, ffsync, wallabag
) so I will wait for some more updates :slight_smile: :slight_smile: how can we help packagers there ?

Edit : Just found that the nextcloud config panel spring an error (even if no regression listed in CI):
Erreur: "500" Internal Server Error
Action: "GET" /yunohost/api/apps/nextcloud/config-panel?full&locale=fr
**Message d’erreur :**Les versions du panneau de configuration ‘0.1’ ne sont pas prises en charge.

To be continued :muscle:

13

I had issues transitioning on a raspberry pi 4. Unavailable UI, backup restore failures, etc. Eventually did a clean install, but still had trouble.

For me, it was an nginx issue.

Diagnosed:

admin@home:~$ sudo nginx -t

nginx: [emerg] BIO_new_file("/usr/share/yunohost/other/ffdhe2048.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/share/yunohost/other/ffdhe2048.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

Investigated:

admin@home:~$ sudo ls /usr/share/yunohost

100000-most-used-passwords.txt	admin  config_domain.toml  ffdhe2048.pem  helpers.d  locales		  ssl
actionsmap.yml			conf   dnsbl_list.yml	   helpers	  hooks      registrar_list.toml

Fixed:

admin@home:/etc/nginx$ sudo nano conf.d/security.conf.inc

from: '/usr/share/yunohost/other/ffdhe2048.pem

to: '/usr/share/yunohost/ffdhe2048.pem

Very likely a problem of my own making somehow, but in case anyone else runs into the same thing.

14

I have this at the beginning of the migration. I am currently reading the migration script to find why.

The repository ‘Index of /debian/ buster Release’ no longer has a Release file

EDIT: i have

9764 DEBUG Err:8 Index of /debian/ buster Release
9768 DEBUG Redirection loop encountered

And it seems paste.yunohost.org and forge.yunohost.org are in infinite loop currently.

EDIT 2 : ok i just fix it on the infra

15

Hi,
Hi all
I installed on armbian bullseye (arm64), and then I launched a backup restore with a backup previously made where there is only the post-install which was carried out on a domain in ynh.fr
My concern is that in SSH the “admin” user does not appear in the sudoers file. So I can’t use “sudo” and “root” access is no longer allowed.
Curiously, I can still update via the webadmin

If you have any idea what I should do, thanks in advance.
tools-postinstall.log => https://paste.yunohost.org/raw/pifusevihe
backup-restore.log => https://paste.yunohost.org/raw/retumewaxi

16

Seems there may have been a regression just recently. Only about a week ago I was able to choose from my domains in a dropdown when I was installing an app. Now when I go to the app install screen, the domain dropdown is empty. Clicking on “Manage domains” though, shows all my domains correctly.

I have unattended-upgrades installed and set to upgrade daily, so I’m not sure exactly which upgrade caused the regression.

11.0.3+202201262115 (unstable).

17

It is not in the sudoers file because it’s not an UNIX user, it’s an LDAP users, for which sudo rights are managed in the LDAP DB

If you cannot use sudo, please share what exactly it is that you’re trying to do and what’s the output

Yes indeed, broke that a couple days ago, I need to find a few minute to dig this and fix it

2 Likes
18

Thank @Aleks , When I connect in SSH I can’t do any “sudo” command despite I connect as “admin”, and the diagnostic page asks me to run " yunohost dyndns update --force" but I need “sudo” to launch a “yunohost” command, and in addition impossible to launch an ssh connection as “root”, I am blocked

log of slapd service => hastebin
log of ssh service => hastebin
all services are green


19

Hi,

I’ve restore and below -before rebooting- the results with the reproduce problem with Searx and nothing in journalctl :

Résumé

Success! Restoration completed
apps:
dolibarr: Success
galene: Success
mumbleserver: Success
my_webapp: Success
phpmyadmin: Success
roundcube: Success
searx: Error
shaarli: Success
system:
conf_ldap: Success
conf_manually_modified_files: Success
conf_ynh_certs: Success
conf_ynh_settings: Success
data_home: Success
data_mail: Success
data_multimedia: Success
data_xmpp: Success
root@yunohost:~# namei -l /var/log/uwsgi
f: /var/log/uwsgi
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root log
uwsgi - No such file or directory
root@yunohost:~# namei -l /var/log/uwsgi/searx
f: /var/log/uwsgi/searx
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root log
uwsgi - No such file or directory
root@yunohost:~# journalctl -u dhcp -n 1000 --no-pager --no-hostname
– Logs begin at Thu 2022-01-27 12:42:49 GMT, end at Thu 2022-01-27 13:17:59 GMT. –
– No entries –
root@yunohost:~#

ppr

20

Have you an error message when you try to run this command? What is the exact output ?