Tried going through that mailtester stuff, but already gave up on email. If it is that finicky and requires that much fooling around to just make it work, then forget about it. I got Yunohost to save me time, not waste my time fooling around with things that may or not work.
I have it working (I think) right now using my registrar’s email relay. It doesn’t really feel like self-hosted to me, so I don’t really use it. I just accept the fact that email is broken, and insecure and use other means for actual private messages (XMPP, Signal, etc).
Being cheap, I only got RPi-knockoffs with no official image, so I only ran Yunohost on Armbian. The Armbian image would check space and grow the filesystem on first boot (so the first boot took a bit longer before there was any discernable action).
This will probably be the same.
The RPi 4 comes with 4 GB of RAM, does it not? I ran Yunohost on Orange Pi Zero’s, with 512 MB of RAM, which was insufficient to install and run Nextcloud, Matrix, Wordpress, PHP-FPM, MySQL and PostgreSQL at the same time, but it did after creating a swap file of 512 MB.
I think I would add a small swap partition (or swap file) to be sure, 0.5-1.0 GB. Swap files may have liittle lower performance, but are easier to add or remove on a running system, allowing you to start without planning for something you don’t know at the moment.
The RPi 4 comes with 2GB, 4GB, or 8GB. I was able to buy two 8GB versions, fortunately. Traditional GNU/Linux theory teaches that if we have 2GB or less, then our swap should be 2 × RAM size. If we have 2GB to 64GB, then 1 × RAM size is sufficient.
I’m also considering doing away with the SD-cards altogether and just booting from the HDD’s. Is this even possible with my RPi 4B rev 1.4 devices? Would it be too much of a departure from the “vanilla” install of Yunohost that I’m aiming for? I just feel that the volatility of the SD-cards is a concern, moreso than the HDD vs SSD issue. In the absence of SSD, is HDD booting preferable to SD-card booting? I do intend to upgrade to SSD’s later, once I can afford them.
I don’t know about that, but for testing today, I would use the prepared SD cards. You got the SD cards in a set with the RPi’s, so they will be chosen for above average usability as boot drive; your Pi’s have loads of RAM, so Linux will be able to do a lot of caching without relying on reads/writes to SD (so even lower quality SD cards should be fine for quite a while).
Booting from SSD/HDD would not be so much of a change to ‘vanilla’ Yunohost, but just add (some) complexity at this point.
My router runs on a small, second hand M2 SSD, that I could get very cheaply. The HDD’s in my other systems were new when I bought them, but they all use small second hand SSD’s as cache. As long as you have back up in place, I see no reason to wait for a sale on a huge new SSD if you could get a small second hand one in a few months time.
Yes, for sure! I forget sometimes that the objective at present is just hands-on experience with Yunohost. I was already designing partition plans for both machines in their final state. I just want to be as prepared as I can be. But you’re right, I need to focus more on Yunohost itself for now. Thanks for the reminder.
I’d like to acknowledge TechDox and his YT video channel, which led me here to Yunohost. TechDox is a fellow Kiwi (a colloquial term for a “New Zealander” like me), and he has made some great videos about selfhosting, including a “let’s install” one about Yunohost. It was following TechDox’s videos that got me up and running with Pi-VPN and Pi-Hole during 2021.
I’ve struck a bit of a problem early on. I’m trying to do the port forwarding, and started at port 22 SSH. My router complained that “this port 22 is used to the Broadband Router SSH server, Please choose other port.” So I went in and disabled all of the monitoring ports for the router itself, so that my ISP (and potential nefarious actors) can’t access the router’s management interface using SSH. When I tried again to port-forward port 22 to the test-fmds.noho.st Raspi device’s port 22, I again got the same warning message from my router.
EDIT: I found the answer to this issue. Apparently my ISP has port filtering enabled by default, but there is a simple toggle option to disable it.
EDIT: I spoke too soon! The mentioned solution didn’t seem to help. I’m still facing a warning of “this port 22 is used to the Broadband Router SSH server, Please choose other port” whenever I try to port forward on port 22. I tested the port-forwarding on port 80, and that worked okay while I had the port filtering toggle option disabled. Until I can resolve this, I’ve turned port filtering back on for now, as a safety precaution.
EDIT: So I set up the port forwarding as much as I could (without port 22), disabled the port filtering, and re-ran the “Ports Exposure” diagnostics in Yunohost. This time the error changed from just complaining about the ports being “…not reachable from outside…” to now saying that they are unreachable “…in IPv6” specifically. I then went to test-ipv6.com and ran that test. The result came back saying that everything was ok except for…
Test if your ISP’s DNS server uses IPv6 bad (1.301s)
Find IPv4 Service Provider timeout (15.224s)
I think the problem here might be CloudFlare, as I am using them as my authoritative DNS. I could disable CloudFlare and use my ISP’s DNS for now, but it will take a while for the DNS changes to propagate. On second thoughts, CloudFlare is only for resolving my custom domain name fmds.geek.nz, isn’t it, which would have nothing at all to do with this? Sorry, I am n00b!
Peculiar. Maybe the router is managed by the ISP via SSH; maybe there’s a way out, but if it can’t be helped, it can’t be helped.
If you need SSH on-the-road access to your Yunohost, there are a few options:
Forward another port on the outside to port 22 on Yunohost (taking 21, for example)
You already intend to set up a VPN server on the Yunohost; via the VPN you can reach port 22 on the Yunohost
There is a web-SSH-client for Yunohost, ‘shell in a box’, that gives you an SSH-terminal in your browser
IPv6?
Does your ISP provide IPv6? If so, depending on your router, the devices in your LAN have a self configured IP (“SLAAC”) and/or a global IPv6 that is part of your IPv6 subnet. To make a device reachable, you have to open ports in the firewall of the router.
If there’s no IPv6 on your line, the devices that support IPv6 (most, if not all, by now) will choose an IPv6 by themselves (also SLAAC), and can communicate with each other, but not with the outside world over IPv6.
In that case, you could disable IPv6 on Yunohost.
diagnosis
Either way, as long as there are warnings in the diagnosis, Yunohost sends out diagnosis rapports by mail twice daily. They are sent to root, which is received by your primary user.
If you have not set up your mail client to receive mail from your Yunohost, and it is a temporary setup, it is easiest to add a webmail client like Rainloop (or Roundcube; somewhat more features, but sometimes problems updating to a new version) to read (and send) mail with your Yunohost account.
The diagnosis for SSH on port 22 will come back every time. In the diagnosis screen, you can click ‘ignore’, so that it does not trigger a diagnosis email.
I have raised a support ticket with my ISP about this, and they are looking into it. Hopefully I should hear back from them today. The L1 support monkey I was talking to had no idea what I was talking about, hahaha!
I would assume so. I can see my IPv6 address from whatismyv6.com.
Ah, I remember IPv4 has that functionality as well, with an auto-configured Class B IP address range, of something in the 172.x.x.x range, if I recall correctly.
I’ll wait and see what the story is with port 22 from my ISP first, then resolve the IPv6 issue, then hopefully it should all work, and I won’t need to worry about the email, it should all work as expected, “out of the box” then, right?
NAT is an IPv4 feature, and more specific to this screen, it says ‘Port triggering’. I recall it is useful for old fashioned plain FTP, but I may misremember.
With some luck your ISP didn’t hand you an obscure router without any manual. I recall you mentioning the router, but I forgot. Which one is it?
auto configuration
Close; a part of that range (172.16-172.32) is on of the private IP ranges, like those starting with 192.168 and 10. Auto configuration yields 169.254 local link addresses. Important difference with IPv6: SLAAC actually works, while I have never been able to use a local link address (probably by the time I didn’t see them anymore, my network elements were better ).
(it is actually half a page above the screenshot you posted earlier)
It does not state whether it is IPv4 or IPv6, you could try adding the IPv6 of your Yunohost.
Maybe this specific question is faster answered at an NZ forum
Yes, that is the screenshot that I showed earlier. That is for the port-forwarding, as in, enabling access to a port from the outside world. The screenshot that I’ve more recently posted is about port-filtering, as in, making a pinhole through the router’s built-in firewall. Sorry for the confusion.
I’m waiting on the Level 2 support techs from my ISP to get back to me on this. They offer a 24 to 48 hour response time for residential customers, but as I didn’t hear back from them by 5pm today, I doubt that I’ll hear from them now until Monday. I can wait, no urgency.
While I wait, what can I do with my brand new Yunohost installation until I have the ports open properly? I assume that even with local access I can start playing around with it. I have added a couple of test user accounts. Can I add apps to it now, or should I wait until the current issues are resolved?
Yes, correct assumption! And, as long as your visitors don’t rely on IPv6, all is ready. First thing to look at: enabling a Letsencrypt certificat for your domain(s).
It looks like I have an issue to resolve first before I can do the Let’s Encrypt certificate…
Should I just do… $ mv /etc/resolv.conf /etc/resolvconf/run/resolv.conf
… and then create the symlink with … $ ln -s /etc/resolvconf/run/resolv.conf /etc/resolv.conf
… is that all I need to do to fix that particular error? Any idea why this wasn’t automatically done as part of the installation procedure?
No, not the way you suggest. /etc/resolvconf/run/resolv.conf already exists.
You can mv /etc/resolv.conf /etc/resolv.conf.bak (or another name/place) if you like to keep a backup, or just remove it, and then make the symlink.
I don’t know why it was not set up initially. I think I also encountered it on the Yunohosts running in a container under Proxmox.
Symlink or not, things should already work. For enabling Letsencrypt, this is not an issue.
I just want to be as prepared as I can be. But you’re right, I need to focus more on Yunohost itself for now. Thanks for the reminder.
).
