An autistic approach to installing YunoHost. (Warning - lots of graphics)

The tunnel between VPS and homeserver does not imply any impediment to visiting the services behind it.
In the hypothetical situation, where

  • VPS is on IPv4 93.17.22.72, domain fmds.noho.st
  • homeserver (actually, homeconnection) is on IPv4 23.11.102.89 (at the moment), domain portal.fmds.noho.st (dynDNS)
  • (yes, both IP’s under your control get their own domainname)
  • blog is at fmds.noho.st/stories
  • MX records, for mail, point to fmds.noho.st ; the A(aaa) record tells the IP, and the VPS also offers an option to configure reverse DNS / pointer.
  • Nextcloud, because of possible higher traffic, could be at portal.fmds.noho.st ; traffic skips the VPN tunnel, but is still served via HTTPS

Visitors of the blog point their browser at fmds.noho.st/stories, their system gets told the domain is to be found at 93.17.22.72, so it makes a connection at IP:port 93.17.22.72:80.
The VPS is configured to transparently forward the traffic to your homeserver via the VPN. Yunohost (nginx) switches the connection from port 80 (plain HTTP) to 433 (HTTPS), recognizes the request for fmds.noho.st/stories the location of one of its apps, and forwards it to the Wordpress instance.

Upload for Nextcloud: when sharing a folder, you can give specific permissions to named users (either on the system or identified by mail) for objects, and to objects without naming a user


The slightly highlighted ‘File drop’ must be the option you wondered about.

Once again, let the flashed SD card get configured, visit the site to finalize the installation/configuration for first use (or login via SSH), and get started.
I recall your mail is handled externally for now, so for the time being you don’t have to worry about fixed IP’s, VPS’s or tunnels.
You and your visitors will use offered services via their domain name, so if in the future it turns out to be handy to run traffic through a tunnel via a VPS, it only takes an update of (a couple) of the DNS entries.

Yes, I considered the dilemma of trying to use my custom domain email addresses before/while building out my home server, including the email server services; and I came up with a solution of temporarily having an externally hosted MX exchange for now, until everything is bedded down properly.

Yes indeed, that’s the one. Thanks.

Yep, I’m on it. It is grocery day for us here today, so later this afternoon I’ll make a start on flashing the SD-card and installing my test.local Yunohost. Yay!

Priorities count :slight_smile: Good luck, looking forward to reading about the results!

Ah, damn, another unexpected roadblock … and another expense to factor in to my project. It seems that my current 8-port ethernet switch here is only a 10/100Mbit/s device. To take advantage of the new 300Mbit/s download speed from my ISP, I’ll have to replace the switch. I’m now off down to my local computer hardware store to buy a Ubiquiti UniFi Switch USW-Flex-Mini 5-Port Managed Gigabit Ethernet Switch. I see that this switch also features PoE, so eventually I can get a PoE hat for the raspi if I want to. Should be good, huh?

Right, I bought the new switch and it is installed, replacing the old 10/100Mb/s device. However, I think I was duped on the PoE specs. I’m not sure if it can provide PoE on the 4 other ports, but it has one ethernet port which can be used for PoE in, to power the switch itself via PoE. Oh well, you live and learn.

Next hurdle I have to overcome is that my initial setup had the 2TB hard drive and 32GB SD-card installed originally on the Raspi machine which was going to be the portal.local machine, but which is now going to be the test.local machine instead. The current proxy.local machine currently has a working PiVPN and Pi-Hole installation on it, which I’d like to keep in place during the pre-rollout testing phase of this project. What this means is that I’ll need to swap the SD-cards over, migrating the data from my 16GB card to my 32GB card, before I can wipe the 16GB card and install Yunohost on it. Fortunately neither of the two HDD’s have any data on them, so swapping them over will be much simpler. Hopefully I’ll get started installing Yunohost tomorrow! :grinning_face_with_smiling_eyes:

I don’t think this is the same tutorial that I was looking at earlier, but here is a tutorial about using Cloudflare for dynamic DNS updating in Yunohost. I’m sure there are plenty of other tutorials like this out there as well.

EDIT: Oh dear, I see that the tutorial I linked to is out of date. It made use of this script which, according to a PR in the script’s repo, “Cloudflare no longer accepts the old X-Auth methods and instead accepts just the key as an Authentication Bearer”. I’ll try again to find a suitable solution for using Cloudflare as DDNS for Yunohost.

EDIT: I found a recent post here on the Yunohost forums related to this issue, which may be of interest. The solution in that case was “to enable Full SSL Mode (end to end encryption), as I was on flexible mode before, which only encrypts the connection through cloudflare”. Might come in handy.

EDIT: Another related Yunohost forums post, this one is about issues with Let’s Encypt certs not auto-renewing when using Cloudflare, and there is a solution for this issue.

I just posted this elsewhere on the Yunohost forums, which is also relevant, and which I want to keep together here with the information about my advanced use case.

orcon-netcomm-nf18acv_ddns-settings
Also, this is where I can set up dynamic DNS directly on my ISP-supplied router if I wanted to. This interface only supports DynDNS.org, TZO, and no-ip.com though, not CloudFlare for DDNS. Of the three that are supported by my router, I believe that only no-ip.com is actually still functioning/free. Sad.

if I wanted to might be key here: there is no need to use the dynDNS client in your router. I suppose Yunohost takes care of updating your IP with noho.st.

Yep, and now we see why I was casting around for another solution when I was originally intending to deploy this project using Docker/Portainer! Part of that initial idea was using the router’s DDNS settings. My earlier network diagram (above) even had no-ip.com in there, in preparation for that. Since I came across Yunohost, all that has changed, and hopefully things will go smoother for this project because of it.

BUT forget about having 100% reliable email delivery

I have to disagree on that point. I’m curious about your setup because I’ve also been running yunohost for a couple years and I have never had this kind of problems.

Have you checked your setup on https://www.mail-tester.com as suggested in the docs? I get a 10/10 for example.

So cloudflare and namecheap good in the realm of over reaching corporate world but not others? I’m truly confused. Anyway rimuhosting NZ based haven’t used them for years but they had excellent support or a cheaper but still close AUS alternative is binarylane so you could use them for email/webhosting and use the pis for data nextcloud etc. with subdomains. That said haven’t checked ownership lately but they were both local (in their respective countries) owned companies last time I looked but might be VC now though??

Very good point, thanks for that Campbell. You’re right, I’m not keen on NameCheap, but it was the cheapest option that I could find as a temporary host for my email setup until I can get it fully selfhosted. It is going to take me a while to set this all up properly, with pre-deployment testing. As for CloudFlare, I clearly need to do more homework on them. I hadn’t really come across them before, but they came highly recommended amongst other selfhosting communities as a possible solution. Thanks for the info though, I’ll look into them more.

Ah, I do remember hearing about them when I was last active with linux.conf.au, back in 2015 (as I recall, they sponsored the coffee cart at LCA2015 in Auckland). My problem here is very limited budget. I can’t just make snap decisions based on company ethics, and jump ship half-way through a contract. My wife and I are both retired and/or disabled, and live on a fixed beneficiary budget, so I’m trying to do this as cheaply as possible. I haven’t done any selfhosting before, so I will no doubt make mistakes along the way, but I will eventually make better decisions to align with my own ethical framework. Thanks for challenging me on this though, it is important to me.

I’m shutting down my online life vic department of health just sent me an email:
“Microsoft on behalf of Department of Health Victoria msonlineservicesteam@microsoftonline.com

So yeah they pay MS to take our data it would seem, your data isn’t going to be safe anywhere, if you want cheap though buyvm is another option. I’m a stay at home carer so I know what it’s like not having cash and now I know what it’s like to not have healthcare went into town to the GP the other day (Geelong) it wasn’t a pleasant experience ahh well I’m sure the interment camps wont move down from the NT our government wouldn’t do that… Stay safe and good luck.

:heavy_check_mark: Downloaded the yunohost-buster-4.1.7.2-rpi-stable.img file from the yunohost.org website.
:heavy_check_mark: Checked the SHA256 checksum and the signature.
:heavy_check_mark: Wrote the image to the 16GB sd-card.

There were a few intermediary steps involved for my particular situation. As I want to retain my existing Pi-Hole and PiVPN setup for now, until I have Yunohost working perfectly, I have swapped over the sd-cards and hdd’s between the two raspi devices. I now have the smaller sd-card and hdd running on the test machine (which will be the first to get Yunohost installed on it), and the larger sd-card and hdd will be for the production machine, when pre-deployment testing is complete early in 2022. Neither hdd had any data on them, so there shouldn’t be any problems there.

Before my first boot, I’d like to know a couple of things. Firstly, should / can I enlarge the rootfs partition on the sd-card for Yunohost? Flashing the image resulted in a normal 256MB /boot partition, and a 2GB /rootfs partition, on the 16GB sd-card.

Secondly, should I create a swap partition on the hdd? I am at a good stage right now to re-partition the 500GB hdd which I will be using for the test machine. Similarly, I can re-partition the 2TB hdd for the production machine and create a swap partition on it for that one as well. Any advice?

Yes, I understand that there are some concerns already about data sovereignty with NZ’s COVID vaccine passes.

About the email thing…

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).

Indeed, managing a mail server is known to be complicated, but less complicated using yunohost I think.

I would not recommend using it for professional usage though if you’re not on a proper dedicated server with static IP.

Looks good!

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.