Alpha-stage testing for YunoHost 11.0 on Debian Bullseye (and migration that will be shipped in Yunohost 4.4.x)

Limesurvey has known issues.
https://dash.yunohost.org/appci/app/limesurvey

Uuuh yeah but what’s the relation with nginx restarting during upgrades 
?

1 Like

I just migrated an existing YH instance from Debian 10 and everything worked smoothly! I used this instance for testing before, only Dotclear, IFM and Rainloop were installed and they all still work fine. I installed YesWiki and it works fine as well. Keep on the good work!

(As @Aleks mentioned, the update log stops (or hangs) after a while in the webadmin, so you keep wondering when it will be finished, as you will never know, this is the only issue I encountered)

I did a migration from 10 to 11 on a VPS (DigitalOcean) with Nextcloud, Calibre-web, and Transmission installed.

When I try to access Nextcloud from the SSO I got this message:

    PHP module zip not installed.
    Please ask your server administrator to install the module.
    PHP modules have been installed, but they are still listed as missing?
    Please ask your server administrator to restart the web server.

Anybody encountered this? Or know of a fix?

So I re-installed YNH_11 in a fresh VPS.
First thing, I have run the diagnosis.
Apart from the usual not yet configured setting errors, I get in systĂšme de base:

Il semble qu'apt (le gestionnaire de paquets) soit configuré pour utiliser le dépÎt des rétroportages (backports). A moins que vous ne sachiez vraiment ce que vous faites, nous vous déconseillons fortement d'installer des paquets provenant des rétroportages, car cela risque de créer des instabilités ou des conflits sur votre systÚme.

and in Connectivité Internet

La résolution DNS semble fonctionner, mais il semble que vous utilisez un /etc/resolv.conf personnalisé.

Edit: Let’s Encrypt certificat fails : https://paste.yunohost.org/raw/hegulogove
the only thing I have set in my DNS settings is the A record


Edit2: I have deactivated XMPP in domain config settings and rerun Let’s Encrypt certificate with the same error. https://paste.yunohost.org/raw/dexaviqisu

Yeah I had the same issue. It’s well understood from the fact that Yunohost automagically reconfigures all php7.3 apps to use php7.4, but it doesn’t install the new php7.4-* dependencies, it keeps the old php7.3-* dependencies (because there’s no code handling that, but maybe we should add some)

What’s really puzzling is why did we not had that issue with previous stretch->buster transitions 


1 Like

Yunohost in LXC container up to date. Apps installed : roundcube, nextcloud, netdata, calibreweb.

Migration launched from the cli failed :

https://paste.yunohost.org/raw/haniqocuse

So I’m just attempting an install the alpha via SSH on a new test VPS with Bullseye, but I’m getting the following message:

This CPU lacks support for the Supplemental Streaming SIMD Extensions 3 (SSSE3) instruction set that is required to execute programs linked against hyperscan.

Really install package?

Does this mean that Yunohost won’t install on this VPS, or can I safely install/skip this?

EDIT: I tried just saying no to installation, but that made the install script abort. From the logs:

Preparing to unpack .../libhyperscan5_5.4.0-2_amd64.deb ...
Aborting installation because of missing SSSE3 extension.
dpkg: error processing archive /var/cache/apt/archives/libhyperscan5_5.4.0-2_amd64.deb (--unpack):
 new libhyperscan5 package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libhyperscan5_5.4.0-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
[FAIL] Installation of Yunohost packages failed

Uuuuh wokay I have no idea what that lib is and why the system would want to install it 


I don’t know if that helps:

Hyperscan is a high-performance multiple regex matching library.

# apt-cache rdepends --recurse libhyperscan5
libhyperscan5
Reverse Depends:
  libhyperscan-dev
  suricata
  suricata
  rspamd
libhyperscan-dev
Reverse Depends:
suricata
Reverse Depends:
  suricata-oinkmaster
  suricata-oinkmaster
  fever
  fever
rspamd
Reverse Depends:
  fbx-all
  yunohost
  opensmtpd-filter-rspamd
suricata-oinkmaster
Reverse Depends:
fever
Reverse Depends:
fbx-all
Reverse Depends:
yunohost
Reverse Depends:
  moulinette
  yunohost-admin
opensmtpd-filter-rspamd
Reverse Depends:
moulinette
Reverse Depends:
  yunohost
yunohost-admin
Reverse Depends:
  yunohost
1 Like

Also

sudo yunohost domain cert-install MYDOMAIN.TLD

gives:

Warning: 'yunohost domain cert-install' is deprecated and will be removed in the future

So, uh
 how do we install ssl certs now, or has this been made automatic?

1 Like

It has merely been reworded:

# yunohost domain cert install --help
usage: yunohost domain cert install [domain_list ...] [-h] [--force] [--no-checks] [--self-signed] [--staging]

Install Let's Encrypt certificates for given domains (all by default).

positional arguments:
  domain_list    Domains for which to install the certificates

optional arguments:
  -h, --help     show this help message and exit
  --force        Install even if current certificate is not self-signed
  --no-checks    Does not perform any check that your domain seems correctly configured (DNS, reachability) before attempting to install. (Not
                 recommended)
  --self-signed  Install self-signed certificate instead of Let's Encrypt
  --staging      Use the fake/staging Let's Encrypt certification authority. The new certificate won't actually be enabled - it is only intended to test
                 the main steps of the procedure.
2 Likes

OK, no deprecation warning, but


sudo yunohost domain cert install MYDOMAIN.TLD

just gives:

Error: 'NoneType' object has no attribute 'get'

The result is the same whether I use my primary domain or a secondary domain that was successfully used to install Nextcloud. If I don’t specify a domain I get two sets of this error message (I have two domains). Both domains still show as self signed using cert status.

EDIT: I was able to create an SSL cert eventually by accepting the warning message about the self signed cert for my admin domain. From there the web gui worked fine for creating the let’s encrypt cert. There’s definitely an issue with the cli cert install though. It looks like the domain name just isn’t being passed to it correctly.

1 Like

So
 would it help to post an issue for this on Github, or is posting it here enough?

By the way, I also managed to get a crash by installing Synapse (which installed perfectly) on a subdomain, and then selecting “Make default” (which caused a crash with backtrace). 100% reproducible.

**Error**: `"500" Internal Server Error`

**Action**: `"PUT" /yunohost/api/apps/synapse/default`

**Error message:**

Unexpected server error

**Traceback**


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/api.py", line 494, in process
    ret = self.actionsmap.process(arguments, timeout=30, route=_route)
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 579, in process
    return func(**arguments)
  File "/usr/lib/python3/dist-packages/yunohost/log.py", line 419, in func_wrapper
    result = func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/yunohost/app.py", line 1081, in app_makedefault
    if "/" in app_map(raw=True)[domain]:
KeyError: 'SUBDOMAIN.MYAWESOMEDOMAIN.TLD'
1 Like

Yes, posting on Github could help (ideally with a full stacktrace, if there’s any available)

Hmyeah that one may not be specific to bullseye, I think it’s more related to the fact that Synapse is not a webapp and therefore it doesnt make sense to “make it default”, hence it crashes. The fix would be that we just do not display this UI bit for non-webapp as it’s not relevant

1 Like

It doesn’t seem to successfully create a log when this error occurs, unless I’m missing it.

Does anyone here know, or is able to make an educated guess, on a release date for YunoHost v11 as a complete install for production use? As you probably know by now from my discussion thread, I am a new YNH user, who is preparing for a new installation in the New Year. I am planning to start with v4.3.4.2 which, I believe, is the current stable version available.

I could wait for this new v4.4.x before I begin my install, and then upgrade to v11 from there. Alternatively, I could wait until v11 ships, and do a complete clean install of it, without having to do the upgrade from v4.4.x at all. I am in a good position right now to make such a decision. I just need to get some idea of how far back this would push my installfest start date.

  • YunoHost v4.3.4.2 installfest — can begin immediately
  • YunoHost v4.4.x installfest — t.b.a
  • YunoHost v11 installfest — t.b.a

Somebody asked a similar question and imho you should just stop procrastinating and go for it ¯\_(ツ)_/¯ :stuck_out_tongue_winking_eye:

On one hand, migrating major debian version is always a bit delicate, and at the same time, we try to make it as smooth as possible. Usually there’s a couple of rough edges in the migration in the early days right after we release it as stable, but then it gets smoother. Apart from maybe a couple cases, I never heard of any miserably epic failure for the migration that resulted in an unsolvable, unfixable setup 
 In the worst case scenario, just come to the support chatroom or forum, provide logs, be patient and methodical, and we’ll find a way to fix whatever went wrong.

Considering that we still need to release a beta then the stable, i wouldn’t expect a stable bullseye before at least mid-february. Don’t waste six weeks just waiting for Bullseye.

4 Likes

Wise words, thanks for that. From my perspective, this project has already been delayed by about 10-20 years! :stuck_out_tongue_closed_eyes: I’m in no hurry. I want to do this right and make it as bulletproof as possible. Over the years I have slowly improved my

“Frittro’s Managed Data Store” project, and in 2022 I expect it to be the best ever, being that I’ll be selfhosting it using YunoHost. Another 6 weeks or so is no big deal to me, if it will improve the quality of the finished product at my end.

This is particularly encouraging, thanks for this reassurance. I’m good to go then, installing v4.3.4.2 starting on 1-Jan-2022. I’m looking forward to it!

3 Likes

I spent the day today trying to get Debian 10 Buster installed on my test raspi, so that I could install YunoHost v4.3.4.2 directly. Encountered several issues (see my discussion thread for details) and had to abandon it.

At present it is looking like I may have to alter my sights, and begin with installing YunoHost v4.1.7.2, and then do the upgrade to v4.3.4.2, as it seems that I cannot install Debian 10 Buster as the base, as had been recommended. Unless someone can provide a solution that helps me get v4.3.4.2 installed, I will start again tomorrow, with v4.1.7.2 instead. Thanks.

Sorry, I really think v4.3.4.2, as the current stable, should be the priority here. Can we please get that working as a complete installable package, with its base OS in place, just as v4.1.7.2 already is?