Self-hosted updated to NextCloud 26.0.8!

Hi!

Thanks to an awesome dev team, we have a new version this month! :smiley_cat:
I’m proud to have been involved, as a tester.

No release notes yet, in a nutshell:

  • Nextcloud 26
  • mailserver 1.16
  • brand new autodiscover/autoconfig image!
  • MTA-STS for emails
  • some bugs fixed

As always, an upgrade guide is available here: https://gitlab.e.foundation/e/infra/ecloud-selfhosting/-/blob/master/upgrade-guides/upgrade-to-26.0.8.23.md.
Please read & follow carefully, feel free to post any question about his upgrade process.

@manoj, would be nice to mention in weekly newsletter :heart_eyes_cat:

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

@smu44 , thank you so much for this!

…throwing two things into the thread in the event they help someone else.

First is that I got myself into a LOT of trouble because I didn’t add the ‘dot’ and the ‘space’ before running scripts/base.sh. Without that CRITICAL punctuation, the $DOMAIN variable doesn’t get defined, which meant a bunch of other headaches that took me hours to sort out. Sylvain’s documentation is absolutely correct, but even the slightest oversight can have grave consequences.

The second thing is that I came to that realization because I remembered some of the principles from this forever-relevant document: http://www.catb.org/~esr/faqs/smart-questions.html. Between the clear reminder to meticulously read the documentation and the recommendation to post a response that walks the reader through the steps to reproduce the problem, I was able to figure out my error.

Thank you for your attention to detail Sylvain, and of course, for your work as a tester.

Thank you very much for your feedback @voyager529! :smiley_cat:

I ran this guide so many times that I forgot to put myself as a first-time runner …
I’ll try to remember to add a warning about the “dot - space” thing, in the next release.
Also with a warning at top, instructing to “read twice and execute once” :wink:

The document you linked is an absolute piece of art (except the “use Google” part, of course :wink: ), that’s what we learn after years of practice!
I’ll definitively keep it in my bookmarks, to be shared with junior engineers.

I prefer new installs over upgrades when I can. As I had very little on the server, I wiped it and reinstalled. And so, I had a few issues: (I tried a new install twice)

  1. I get the error emailed at 7PM for 10 directories
    /bin/sh: 1: cannot create /tmp/counters/cert_watcher: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/unbound: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/rspamd: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/postfix: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/freshclam: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/cron: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/rsyslogd: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/clamd: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/dovecot: Directory nonexistent
    /bin/sh: 1: cannot create /tmp/counters/_parent: Directory nonexistent

I manually created the directories, and changed it to chmod 777 but still getting the errors. (I recreated the directories tonight, but expect the same.)

  1. at the end of the script, the settings for the DNS was not clear. I had extra " and ’ in the names. I took them out, but not sure if they are right.

  2. I notice we don’t have “Gallery”. Did we not have it earlier and I didn’t notice? And can we add the Document, Spreadsheet and Presentation to the server and App dock?

Thanks again for all the help.

Hi,

  1. Never seen such error! I suppose it’s from the mailserver container? I’ll fire a new test instance and try to get some clue…
  2. In my experience, doesn’t matter much of the time. I suggest trying first without any (double)quote. Once done, check your instance with https://www.hardenize.com, look at “Email” part in the results.
  3. About Gallery: please read at bottom of Recommended Update Policy - #8 by smu44. About Office-like apps: Adding Nextcloud Office or Collabora Online to self hosting.

I used hardenize.com and everything in email came back green other than DANE which has an X. (Considering I don’t have DNSSEC, that is understandable.) But I do have a problem with my Certificate for my $DOMAIN having a certificate autoconfig.$DOMAIN, instead of www.$DOMAIN.

Also, one of my outbound links is Plaintext rather than secure. (Granted, it is the http://murena.io /termsandconditions link but I never like warnings.

HSTS Policy also has warnings. No Subdomains, Preloading not enabled, and one or more certificates not trusted. (I assume from the Certificate error above.)

Finally, there is a warning that XSS auditor blocking instead of disabling browser-based XSS protection.

I say all this in part because my emails to gmail.com go into spam instead of the inbox. Part of what I need to do is figure out why.

If the errors are in the mailserver container, I did not go into that to add the folders there. Probably only need to add /tmp/counters and the others would get created automatically.

Again, thanks for the help.

My memory is getting old :confused: Keep getting messages like /bin/sh: 1: cannot create /tmp/counters/dovecot: Directory nonexistent.
Couldn’t find what package or script added this cron…

DANE & XSS warning are OK, but you definitively have a certificate problem!
WWW certificate should be bound to your domain, no prefix.
Email certificate should be for mail.domain.tld.
Here are the results for my test domain:

How do I fix my tls certificate? for my $DOMAIN, it installed autoconfig.$DOMAIN certificate. I assume it is a NGINX configuration issue, since cerbot pulls from there, but I can’t find that either.

I was able to fix the error:
I get the error emailed at 7PM for 10 directories
/bin/sh: 1: cannot create /tmp/counters/cert_watcher: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/unbound: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/rspamd: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/postfix: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/freshclam: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/cron: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/rsyslogd: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/clamd: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/dovecot: Directory nonexistent
/bin/sh: 1: cannot create /tmp/counters/_parent: Directory nonexistent

with:

docker container exec -it 710bf89e0855 mkdir /tmp/counters

with 710bf89e0855 the name of the mailserver2/mailserver:1.1.16 docker container.

“docker container ls” is how I found the ID.

I do not know if this is a permanent, or if a server/docker reboot will reset it, but you can only create one level of directories at a time and /tmp/ did not have the directory “counters”, so it could not create the needed directories.

About missing directories:

Something went wrong at Docker container initialization :confused:

Digging into code, I found that the directories should have been created by https://github.com/mailserver2/mailserver/blob/26c8ab63404198c297a02fe29a9ba9fe81b2fb92/rootfs/usr/local/bin/setup.sh#L807 (to be run once at container first run, see https://github.com/mailserver2/mailserver/blob/26c8ab63404198c297a02fe29a9ba9fe81b2fb92/rootfs/usr/local/bin/run.sh#L139).

You can try the following:

  • cd /mnt/repo-base
  • docker-compose -f -s rm mailserver && docker-compose up -d && docker-compose logs --follow mailserver
  • exit with Ctrl+C when the log start to be very verbose (after “s6-supervise : spawning …” lines)

If you can see a line saying “[INFO] Finished container setup”, then your setup is probably OK.
You can check with docker-compose exec mailserver ls -alR /tmp.

You won’t lose any data, unless you made any other changes than creating /tmp directories, into your container (would be a very bad move, BTW).


About certificates:

The HTTP link between your domain certificate (no prefix) and Nginx is made in /mnt/repo-base/config/nginx/sites-enabled/nextcloud.conf.
You should see lines like this in the “4430 ssl server” section:

ssl_certificate /certs/live/domain.tld/fullchain.pem;
ssl_certificate_key /certs/live/domain.tld/privkey.pem;

The SMTP/IMAP link is done by mailserver Docker container, please check in your /mnt/repo-base/docker-compose.yml:

services:
  mailserver:
    image: mailserver2/mailserver:1.1.16
    container_name: mailserver
    domainname: ${DOMAIN} # Mail server A/MX/FQDN & reverse PTR = mail.${DOMAIN}.
    hostname: mail
...
    volumes:
      ...
      - /mnt/repo-base/config/letsencrypt/certstore:/etc/letsencrypt

Maybe container re-creation will put it back on the tracks…

The command gives an error that there is no file ./-s. And under -h there is no option for -s.

but I also tried installing the server twice… so there must be a syntax error in the script that isn’t creating that directory

So I looked at the SSL, and the:
The HTTP link between your domain certificate (no prefix) and Nginx is made in /mnt/repo-base/config/nginx/sites-enabled/nextcloud.conf.
You should see lines like this in the “4430 ssl server” section:

ssl_certificate /certs/live/domain.tld/fullchain.pem;
ssl_certificate_key /certs/live/domain.tld/privkey.pem;

is correct. And when using the web browser and looking at the certificate, it has just the $DOMAIN, but hardenize.com says that the certificate is autoconfig.$DOMAIN instead of $DOMAIN.

I have checked with https://www.sslchecker.com/sslchecker and https://mxtoolbox.com/SuperTool.aspx?action=https%3Amuskegonmi.us&run=toolpage and both show no problems… So is it a hardenize.com problem?

Sorry, there was a typo, my bad :frowning:
Try with docker-compose rm -f -s mailserver && docker-compose up -d && docker-compose logs --follow mailserver (tested OK).

I agree: if you don’t see any problem using other ways, it may be. Kinda strange anyway, it’s OK for all my domains :confused:
I tried to refresh Hardenize for your domain, it was abnormally fast. Maybe your server is behind some kind of CDN or WAF, and Hardenize get blacklisted (it’s common for scanning tools)?
Anyway, I think we can call it solved :smiley_cat: