…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!
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”
The document you linked is an absolute piece of art (except the “use Google” part, of course ), 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)
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.)
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.
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?
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…
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.
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.
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.
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.
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:
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:
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.
Sorry, there was a typo, my bad
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
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
