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

@tituspijean takes precedence :slight_smile:

Advertisement of .local is new in the current version of Yunohost, I didn’t have the opportunity to use it yet. My hosts file is a mess of temporary domains (notice the ‘#’ for comment in front, they are not active now)

$ cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
#192.168.1.30 gialinh.nl
#192.168.1.30 osba.nl
#192.168.1.30 online.osba.nl online

Yes, that is what the tunnels could look like. Traffic will be bound by the slowest link, with some overhead for the VPN. Upload speed of the home internet connection is most often the bottleneck.

1 Like

Haha, it figures! I finally get the chance to use FQDN’s in my home network, but technology has moved on so that I don’t even need to. :rofl:

Fortunately my ISP has just given me a free upgrade on my Fibre plan, from 100/20 to 300/100, so I should get better upload speed as well.

I’ve turned off the old portal.local Raspi now, the one which had NextCloud on it. Later today I’ll take out the SD-card from it, reformat it, and put Yunohost v4.1.7.2 on it as test.local instead, for some practice with it. I’ll let you know how it goes, later. :wave:

That is quite nice of them :slight_smile:

Good luck flashing the SD card!

1 Like

211214_0601_raspi-se_comment-on-zeroconf
I just saw this comment on the RaspberryPi StackExchange, from 2014. From what I understand, mDNS is something to do with Zero-configuration networking (zeroconf), right? This is great that Yunohost now implements zeroconf without me needing to follow Milliways’ older advice and have to install something separately for it to work. Very cool!

3 Likes



One of the big changes between my earlier network diagram and my latest version is the lack of an SSL connection for the Wordpress blog. I understand that Yunohost will manage the SSL cert for me, (which is very handy, by the way), but what I want to ensure is that there is some way for the general public to view the Wordpress blog without needing to use the VPN tunnel.

Also, on the same topic, you mentioned earlier about CalDAV from NextCloud. Similar to the Wordpress issue above, I would want this to be accessible publicly, so that I can publish certain calendars from NextCloud out to the WWW on an HTTPS connection, without need for the VPN tunnel. How would this go with my current network diagram?

Similarly with the filesharing features of NextCloud, I understand that there is a way for the public to be able to upload files to my NextCloud instance, “blindly”, without ever seeing the contents of the folder. I’d want this to be possible via HTTPS and via the VPN tunnel, such that I can set different filesize / filetype limits depending on how the user is connected. Is this all possible? Sorry for the hundreds of questions, which are more NextCloud related than Yunohost. I’ll get NextCloud support elsewhere if needed.

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.