$ cat /etc/resolvconf/run/resolv.conf
cat: /etc/resolvconf/run/resolv.conf: No such file or directory
I can’t see it. 
It seems that I need to resolve this issue first, before I can do the Let’s Encrypt cert.
I have found a thread in French here about this, but I don’t understand French, unfortunately.
Woah, hang on a tick, my bad! 
I was SSH’ing into the wrong Raspi! 
Now I need to resolve the fact that my installation has changed on the same IP address, but SSH is still looking for the same old cert for the login credentials from the previous install on that Pi device. Derp!
If you checked the diagnosis for ‘DNS records’ and for ‘Web’, and they seem OK, you can still force the Letsencrypt registration attempt via SSH.
DNS records: Is your domain registered and propagated? There are DNS check websites to be found. I have never used the noho.st (and the other) services, I don’t know how DNS is maintained in that case.
Web: are ports 80 and 443 being forwarded?
Nooo! 
Yep, I can be really dense at times. Fixed that for now though, by updating the ~/.ssh/known_hosts file on my laptop, removing the cert for 192.168.1.4. Now I am connected to the proper Raspi device. Whew! 
And look at that, you were right, /etc/resolvconf/run/resolv.conf does exist, once I looked for it on the correct Raspi, hahaha.
Oh dear, I’m still getting that error about “This domain doesn’t seem ready for a Let’s Encrypt certificate” even though I tried a sudo systemctl restart resolvconf. The green button to create the Let’s Encrypt cert is still greyed out.
Aha! I think I know what the problem is here, and it is related to my silly mistake before, where I was on the wrong Raspi. I have two Raspi’s at home, right? One of them contains this new Yunohost install. The other one is still running my Pi-Hole and PiVPN setup from earlier. I guess Pi-Hole is the problem here now, as the error message in YNH says…
All my internet traffic at home goes through the existing Pi-Hole on the other Raspi, which I guess is interfering with YNH somehow.
As this was also mentioned in the error above, I thought I should check again …
Does that look right? You’ll notice the existing PiVPN port there, as well.
This morning I tried bypassing the the existing Pi-Hole machine which was acting as my DNS resolver here locally, to see if that was causing any troubles. I got this working originally by setting my 192.168.1.2 Raspi as the primary DNS resolver in my router’s DHCP settings, so that every device which connects locally will point to my Raspi for DNS. The two Raspi’s have DHCP reservations for 192.168.1.2 and 192.168.1.4 respectively, so they are essentially static IP’s. To bypass this configuration, I simply changed the DNS resolver in the DHCP packets to now point to my ISP’s primary and secondary DNS servers. After rebooting everything to obtain the new DHCP packets, I ran the Yunohost diagnostics again, but still received the same error …
So, clearly, having Yunohost behind an existing Pi-Hole installation isn’t the source of the problem. I guess I can rule that out. The error is more about external access into my homelab network though, right? I would have thought perhaps disabling CloudFlare might help, but I’m only using CloudFlare currently for the fmds.geek.nz domain name, which hasn’t been connected to my YH installation at all as yet. My YH installation uses the test-fmds.noho.st domain, so it has nothing to do with CloudFlare as yet. I’m stumped.
I may have found the cause of the problem. It seems that my ISP-supplied router might have trouble with IPv6, according to this post on Geekzone.
You could await the response from the ISP helpdesk. Maybe there has been an update to the firmware during the past year (my hopes are not high…)
In the mean time: the diagnosis tries to only give a green light after it is sure things work. Your server got an IPv6, so it must assume you want to use IPv6, but not reachable, so: red light.
Actually, you are fine with using only IPv4, mostly. On the command line you can override the diagnosis check on the certificate:
sudo yunohost domain cert-install --no-checks
will request a Letsencrypt certificate for the configured domains. Something might pop up of course, but you’ll never find out without trying 
I’m not keen on ignoring warnings. I really wanted to get this running properly the first time, so that when I roll it out to the production machine I can be assured that everything will work properly. However, the test machine is where we iron out the issues as much as possible. Once I get a reply from my ISP, and find a solution to the IPv6 port forwarding issue, I’ll probably re-install the test machine from scratch, just to make sure it works before the final rollout. I know that the Yunohost manual suggests against re-installing to solve problems, and that isn’t what I’m doing here. I want to resolve the issue first, and then re-install so that I can practice installing with the solutions in place from the start, as they should be in the production machine.
In the meantime though, I have followed your advice, @wbk. Check this out!
My first ever real SSL server certificate! I’m very happy with that. All of my attempts at self-hosting in the past have been over HTTP with local access only, no open ports to the outside world. This is the first time I have opened ports and used a proper SSL server cert. 
Downloaded the yunohost-buster-4.1.7.2-rpi-stable.img file from the yunohost.org website.
Checked the SHA256 checksum and the signature.
Wrote the image to the 16GB sd-card.
Insert 16GB sd-card into test raspi device and booted up.
Performed “initial diagnosis” on test raspi device. Log is here.
Created admin user and two regular user accounts on test raspi device.
Run yunohost tools upgrade system to update to latest YNH version.
Installed Let’s Encrypt SSL server certificate on test raspi device.
Performed another system diagnosis on test raspi device. Log is here.
Reduce swapiness for SD card.
Adding an external storage to your server.
Bookmarked sftp connection to test raspi device, in PCManFM-Qt file manager on laptop client.
This seems to have resolved all of the pending IPv6 and port-forwarding issues in one hit! I wonder how that worked? The only outstanding issues now relate to email…
I guess that the next step will be something to do with setting up a VPS to overcome the email server issues, would that be right?
indeed, congrats!
Getting a certificate would not impact IPv6 connectivity of course. If the server has IPv6 and there is no warning in the diagnosis: great 
Personally I’d postpone the VPS for a while. Actually, my home IP’s did not have any blacklist problems, while my VPS were on a blacklist when I just got them. Go figure. (They were in a datacenter where my VPS provider just set up; who knows to what use the IP’s were put before)
Do you have an impression of your ISP’s dynamic IP policy? Some providers officially provide dynamic IP’s ,but their IP’s turn out static in practice, with hardly a change. It could be worth your while looking if it is a lot of trouble to get your IP off Spamhaus etc.
If your ISP is willing, they might set up reverse DNS, but I give it little chance because of dynamic DNS (the reverse DNS would point to the wrong subscriber once your IP changed).
Oh snap! I almost missed it as it has changed from a big red issue to being just an orange warning, and it is no longer auto-expanded in the diagnostic report. But it is still there, that IPv6 issue.
Yes, this is definitely the case for my ISP.
Yes, I will look into what that involves.
I can only but ask. I might leave this one till Monday though, when the L2 techs get back.
In the meantime, should I start installing some apps? The first thing I’d want to set up and experiment with is BorgBackup.
EDIT: I’m just reading through the YNH docs for BorgBackup and came across this comment…
…so I guess this will have to wait until I resolve the email server issues first.
By all means! You won’t break anything unless trying really hard, is my experience. Now and again there’s an app that does not install right away (Roundcube webmail is hit or miss, for example). In my experience it never broke Yunohost itself; the installation is rolled back and you are back at square (where you where before that).
Borg is one of the more complex apps to start with, because it involves a server and a client installation (that may be on the same machine). Yunohost does have a built in backup mechanism as well (you’ll find it in the admin menu); it misses some of the advanced features of Borg.
I think I would start with webmail (Rainloop never gave me a problem…), Nextcloud or Wordpress, and create a backup via the admin menu. It gives some feeling with the installations menu, and some actual end user apps that give use to the server.
Thanks for the advice. As we intend to use NextCloud as our primary portal, including for webmail, I think that should be where I start then. I’ll definitely take your advice on the backup strategy. Sounds good!
I just did the sudo apt update command as recommended by Aleks in this announcement on the forums. It looks like it wants me to upgrade from YNH v4.1.7.2 to v4.3.4.2. Is this what I need to be doing first? I thought v4.1.7.2 is the latest version for the Raspberry Pi?
Yes, upgrade to the latest version. The recent upgrade to Yunohost 4 had some rough edges; 4.1.7.2 is the latest version that is available for the RPi as a complete package, but not the last version that is compatible with RPi (Yunohost itself is hardware-agnostic, as it runs on the abstraction provided by the Linux kernel and intermediate software)
Hmm, I did the upgrade, and now I can’t get back in to the test raspi device via the web interface. I have tried browsing to both the IP address and the FQDN, but neither seems to work. Also, I can’t SFTP in to it, as I could previously. (UPDATE: This at least now works, after the last reboot). However, I can still connect via SSH from the terminal. I’ve tried purging my web browser’s cache, and that didn’t help either. I assume that there is something wrong with the NGINX server, perhaps. How would I test this from the terminal, and get it working again?
I just tried service nginx status from StackOverflow and got the following result…
$ system nginx status
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-12-18 22:00:31 GMT; 13min ago
Docs: man:nginx(8)
Process: 745 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
I also tried sudo journalctl -xe which resulted in a long output, with the most recent lines being…
Since starting the upgrade, I have also received an email notification from my Yunohost server, which says…
Subject: Cron root@test-fmds yunohost dyndns update >> /dev/null
Traceback (most recent call last):
File “/usr/bin/yunohost”, line 9, in
import yunohost
File “/usr/lib/moulinette/yunohost/init.py”, line 7, in
import moulinette
ImportError: No module named moulinette
…I don’t know whether that is related to the NGINX failure or not.
I tried restarting the NGINX server with sudo yunohost service restart nginx, but it failed.
I guess this has been a salutary lesson in making backups before I do a system upgrade! I have tried all the suggestions in the article Get access back into YunoHost > NGINX web server is broken, but nothing there seemed to help. About now I would normally be reaching for the “reinstall” button, especially on a test machine like this, which isn’t a critical system. However, I remember reading in the Yunohost manual, “Do not reinstall every day”, and I hope that I can come across an answer to this without needing to reinstall. Sure, it would no doubt be faster and easier to just reinstall at this point, being that I’ve only just installed the system and have hardly made any configuration changes since, but I’ll wait and see what advice is forthcoming from the community here.
In other news, tomorrow my wife is getting me 2× SanDisk Ultra Luxe 32GB USB 3.1 Flash drive, Full cast metal, up to 150MB/s read which I’ll use to replace the current SD-cards in the two Raspberry Pi devices, and start booting the Raspi’s from the USB instead of the SD-cards. A nice, early Christmas gift! 
Sweet of her!
Bummer. My Yunohost, with all bells and whistles, is also at 4.3.4.2 without nginx giving problems.
Something seems to be searching for /usr/lib/moulinette/yunohost/init.py and not finding it. Is the error in the calling program, or is the error it the missing file?
My installation does not have init.py there either:
# ls /usr/lib/moulinette/yunohost/init.py
ls: cannot access '/usr/lib/moulinette/yunohost/init.py': No such file or directory
# ls /usr/lib/moulinette/yunohost/
app_catalog.py certificate.py domain.py __init__.py permission.py settings.py user.py
app.py data_migrations/ dyndns.py locales/ __pycache__/ ssh.py utils/
authenticators/ diagnosis.py firewall.py log.py regenconf.py tests/ vendor/
backup.py dns.py hook.py monitor.pyc service.py tools.py
If you search apt for moulinette, is it installed?
# apt search moulinette
Sorting... Done
Full Text Search... Done
moulinette/stable,now 4.3.2.2 all [installed,automatic]
prototype interfaces with ease in Python
yunohost/stable,now 4.3.4.2 all [installed]
manageable and configured self-hosting server
In case of app-upgrades, Yunohost would have had your back. I think there is no backup in case of system upgrades. When you log in via SSH and issue
$ sudo yunohost backup list
are there any archives listed?