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

Yes, indeed it would;

“unfortunately”, yes, it makes sense :smiley:
It often takes a lot of roundabout work to make things seem simple and transparent for users of a system.

You can configure an app/service per domain as the ‘default’ when configuring via Yunohost. I think that in your case you would have Nextcloud as default app for fmds…(and let it forward to portal.fmds…); that would save your users from typing a few letters.
Another thing might be to have some sensitive apps (Bitwarden and Firefly come to mind) in a subdirectory instead of a subdomain; the subdomains are public knowledge via DNS queries while subdirectories are not. Or use another subdomain then ‘money’ or ‘password’, but that is less helpful for users.

1 Like

Yes, my original plan for this project, when manually configuring with Docker/Portainer/NGINX was to have certain apps (such as the ones you mentioned) only be available via a secure VPN tunnel. I’d still like to do that if possible under Yunohost. I understand that there is some problem currently with Yunohost and Wireguard. I’d want to get PiVPN and Wireguard set up to tunnel into my home network for those sensitive apps. Below is my earlier idea, using Docker/Portainer/NGINX, before I learned about Yunohost.

211114_2200_network-representation

You can click the link for a larger version of the image.

I am not sure you can easily access them via their domain name, in that case. Probably no problem: once configured on the phone, they will find the (VPN) IP of the server.

I thought the problem with Wireguard at the moment had to do with the flexibility of the GUI element used. It works ‘out of the box’ with the provided configuration in the root of a (sub) domain, but maybe does not support moving to another domain or multiple installs. I think it should suffice if you want to connect your smartphone(s) to your home network.

I wanted to run the VPN the other way around, that is possible with Wireguard itself in Yunohost (either after installing it via Yunohost or via Debian directly), but it needs command line configuration (which was relatively straight forward and runs nicely). In the end I used SSH directly, so I have no ‘production’ experience with Wireguard.

1 Like

Another thing I should mention here, is about my intended use of Cloudflare. Somewhere along the line (I can’t remember now who or where from) I learned that Cloudflare can be used to simulate the features of a dynamic DNS server, similar to the free tiers of No-IP or DuckDNS, but it can be set up to use my own domain name and subdomains *.fmds.geek.nz, rather than having to use *.fmds.ddns.net or *.fmds.duckdns.org at the free tier. I’m not exactly sure how this is done now, but this was a feature I was hoping for. As I explained above though, having my own domain name is not as critical for my project, and I might not be able to justify the ongoing cost of it to my wifey after the initial three-year contract has expired, anyway.

future-plans-goals-for-fmds

You can click the link for a larger version of the image, or see a live interactive version on Coggle.

Here is another mindmap from my planning for this project, which I hope to get started on in 2022. As you can see, I have long-term aspirations for this project. I expect to achieve Step 7 by about 2027, or earlier if I win Lotto. :money_mouth_face:

fmds-pyramid

You can click the link for a larger version of the image.

Here is the traditional cloud pyramid diagram for the FMDS selfhosted network which I’m intending to build in 2022. I’m still learning about this stuff, so I may have got some things wrong in the layers of this diagram.

I’m still hoping to automate as much of this as I can with Ansible, but that might need to come at a later stage, perhaps with the Yunohost v11 rollout.

There has been some suggestion recently that I may also need a VPS for routing a static IP address. I assume that would go in the IaaS layer of the diagram. I welcome all feedback on this plan, to improve on it before I get started building it out. Thanks.

I have a :dart: milestone coming up for this project which I’d like some final advice on before I make a financial decision for the future of this project. My billing cycle with my ISP is the constraint, and I want to go into 2022 with the foundation for my project laid properly, so I need to settle the question of whether I really need a static IP for this, or can I just use DDNS for it? Apparently DDNS use could cause problems with the email hosting setup in Yunohost, with blacklisting and IP reputation potentially causing problems whenever my dynamic IP address changes. Another option which has been suggested, but which I would need further clarification on, is to set up a cheap VPS for handling the static IP address, for the greater trust and reliability for the email server. As I say, I’m still very new to this, and I really need some guidance here. My main concern is that we can’t end up missing important emails, so I need a solution that solves this problem as best as it can. I need to get this part of the project settled by 22-Dec-2021 NZDT (UTC+13), as that is the date of the beginning of my next monthly billing cycle with my ISP. If I am going to be getting a static IP address from them, I need to request it before then, in order to go into 2022 with that part laid down, at least. This is where my journey begins! :star_struck:

EDIT: To clarify, another constraint for this milestone is our budget. I can afford the ongoing cost of a static IP address from my ISP if I need it, or I can afford the ongoing cost of a cheap VPS solution. I can not afford both.

I recall it being mentioned, but I did not look further into it (I already used dns.he.net, which also provides dynamic DNS, and luckily I have hardlu had a need for dynDNS). Anyway, enabling it must be hidden in their settings, and of course you need to run a client on your server or router).
I can’t comment on how nicely autoconfig of the noho.st etc domains plays with cloudflare. Is dynDNS the only reason for using cloudflare?

1 Like

Indeed, that was the reason that I set up a free account with them … and then I promptly forgot about the rest of the instructions for how to make use of it. I’m old and forgetful. Now, if I had a self-hosted homelab with a centralised place to store such information, which wasn’t privy to spying on by Google etc, then I wouldn’t have as many problems. :stuck_out_tongue_winking_eye:

I still at least know about Cloudflare, and I’m at the early stages of planning my project yet, so I have time to research this further and remind myself why I started down this path. Teeheehee.

I posted a bit about my project on the Geekzone forums, (the local watering-hole for all things nerdy in New Zealand), and got an interesting, if somewhat negative/snarky, reply from one of their moderators…

“Lastly, what you’re wanting to do isn’t the best use-case for a Raspberry Pi. You’re hosting too much on it, SD cards are fragile with limited writes and will likely mean your entire environment will nuke itself rather quickly. Consider an ex-lease machine like a Lenovo Tiny or NUC if you’re that set on self-hosting. Also I would recommend against using Yuno Host, a project I’ve never heard of for anything important.”michaelmurfy

EDIT: Don’t bother clicking those Geekzone links, they are dead now. Eventually the Admin/Owner of the site stepped in, abused me verbally, then deleted the whole thread and kicked me out of his site. Very professional behaviour! :scream:

If only! :smiley:

The dns.he.net interface is quite basic, but has an easily identifiable tick box for enabling dynamic DNS:
image

I imagine Cloudflare’s option has to be somewhere where it can be found :slight_smile:

I guess the guy on the geekzone forums is rather knowledgeable in his field and also wants to be helpful, as long as it is in his comfort zone. From the same post,

Especially because many people who want to self host, whatever their reasons, have those questions, Yunohost was started.

For example, following any tutorial on the 'Net to get a working mailserver is peanuts; having it work without malicious visitors joining in is another story. Yunohost takes care of that part.

With Michael being a security professional, it would be great if he got interested in validating and improving the Yunohost security even more :slight_smile:

He has a point about uSD-cards. I have had a few die on me, but only a few. They hold longer than I expected (then again, they didn’t run heavy traffic sites). RPi’s are no performance monsters, but they are more performant by an order than the Orange Pi Zero’s my daughters gave their classmates for their birthdays (running Yunohost with swap on uSD :scream: because Nextcloud + Matrix would require too much RAM for the 512MB board). I do run Borg backup to a HDD backed machine. You also intend to connect an external HDD; it would make perfect sense to have a backup of the SD card there. Do RPi’s offer boot from connected SSD’s, by the way?

If it were my budget on the balance, I would forego the fixed IP from my ISP. There’s two sides to emailing: sending and receiving. Your worry is first and foremost with the receiving part. On that side there is no problem with having a dynamic IP, as long as the dynamic DNS is set up.
On the sending side, speaking for myself, I would just go ahead and see how things run. You should be able to use your ISP-provided SMTP-server as a relay, foregoing any problems sending mail. That reminds me, some ISP’s block port 25 alltogether (handily pre-empting blocklists…), how is than on your side?
Taking that route, there is no contract pressure or long lasting commitment with your ISP for the fixed IP. You still can take the (monthly, or longer) cost of the VPS, if your need and want to. By then you also have an idea of the load on the server, and have a better idea of the sizing of the needed VPS.

1 Like

Hi Frittro!
Obviously you put a lot of thought into what you want to do. I have been self-hosting behind my consumer internet connection for 14 years now, including email, and here are the 2 most important things I’d share:

  1. do not over-engineer it unless you are ready to invest a lot of time in the long run to maintain it. My advice is to start simple and add new features gradually as needed
  2. regarding email, I resorted to go through a relay for my outgoing emails. You can use your ISP relay for that. This has solved all my email delivery issues. Sending emails from a residential IP is unfortunately a dead-end - it is not even an issue with DDNS vs static IP: an IP declared as residential by your ISP will be blocked or will weight heavily towards spam in various filters.
    You are still going to receive the incoming emails directly on your server and your emails will be stored locally, but outgoing email will go through an intermediate server.

If you are interested I tried to document what I learnt here: 14 years of self-hosting

2 Likes

Indeed, I was aware of the volatility of the SD-cards. That’s why I intend to transition to booting from an SSD (yes, it is possible to do this) eventually, once I can afford it. My long term plans for this project include migrating to SSD booting once I have a RAID5 array of SSD’s set up. I could change that to an earlier stage of my project (eg. after the purchase of my first SSD) if need be, with the main constraint there being financial considerations for purchasing the hardware.

I have seen this recommended several times now. It is definitely something that I will be looking into for my project. Thanks for this!

Another great question for me to ask my ISP before my milestone on 22-Dec-2021. I’ll get right on that, thanks!

I’m still a little unsure of where a VPS fits in with this project. I don’t think I have quite grasped this concept yet. Running on a VPS seems counter to the “self-hosting” ethos, as we are going back to being hosted by a third-party again, right? Sorry to be so dense.

Wow, great advice, thanks! :+1:

Your blog is really very helpful at the current stage of my project. Thanks for sharing that. I think the most important piece of advice that I took from it was…

…this just makes so much sense. I have been toying with the idea of deploying with Ansible, so that I can capture and reproduce my configuration changes. I have no prior experience with Ansible, so that was going to be yet another steep learning curve for me. However, your advice here to keep my Yunohost deployment as close to vanilla as possible is a much better solution for me. I don’t need to track configuration changes if I don’t make them! :exploding_head: However, I do want to heavily customise my server for my users. I assume that I can do that at the SaaS level of NextCloud, rather than the PaaS level of Yunohost itself, though.

Thanks everyone for all the great advice. I’ll be able to clarify some issues with my ISP over the next few days, and settle on a decision about the foundation for my project. If someone here could explain further what a VPS would look like as part of this project, and how it would help, I’d really appreciate that. If I can divert the money from the static IP address to a VPS instead, then the financial constraint could still be met for my first milestone.

The VPS can be put to (in this context) two uses:

  • Running your whole setup there; requires a heavier VPS, might qualify as self-hosting, but surely not a homeserver
  • Running a light VPS with VPN to your homeserver (as in your picture with tunnel above, but the other way around). The VPS is reachable for everyone on every (open) port, at a fixed IP. The VPN forwards traffic to your Yunohost at the respective ports

For myself: while trying to get Wireguard configured for this use, I figured I’d better use the resources of the VPS as much as possible, and offload storage (via SSHFS) to my homeserver. By the time I had Wireguard running, I also had the VPS running with a backup of one of the homeservers, so I have no actual experience in this regard.

1 Like

That is what I would mention as well! Have a go at installing Yunohost on your not-in-use RPi, see how the port forwarding on your router works, configure DNS, add some users and apps to Yunohost, try the backups and restores, get a feel of the management interface of Yunohost and its possibilities. Make notes! But I got a feeling the notes are in safe hands :slight_smile:

All apps that work the way you like after that, can quite easily be transferred to the other RPi when you are ready for that (via backup/restore the Yunohosts of my children got migrated from the ARM-based Orange Pi’s, to LXC containers on a small homeserver once I got that running, to the current VPS’s when I lost the IPv4 subnet, all with minor downtime and no tears)

1 Like

So what you seem to be saying is that my home network would then be accessing the Internet outwards via a VPN tunnel to the VPS, and then out to the public Internet from there, right? So if I want to secure my mobile device when I’m not at home, I would need another VPN connection, the same way around as in my diagram above, which connects my mobile device to my home network (tunnel 1), then back out to the VPS (tunnel 2), then from there out to the public Internet. Have I got that right?

I thought that was the job of NGINX Proxy Manager, within Yunohost?

Oh this is a great idea! I had started out with my original Docker/Portainer-based setup, with NextCloud running in a container on that second Raspi. But your suggestion is even better. That way I can retain my existing, working deployment of Pi-Hole and PiVPN for now on Raspi #1, and try Yunohost on Raspi #2. Is there anything else that I need to consider before I trash the existing Raspi #2’s OS and put Yunohost on it instead, to play around with?

I imagine Nextcloud does not yet have unique data, that would be my only concern.
For the test installation of Yunohost, as long as you have not made the system publicly reachable (by opening ports in your router), edit the hosts-file on your laptop/desktop so that you can reach the Pi by its designated domainname without going through DNS. When using the IP address of the Pi, you will only be able to reach the admin webpages.
There’s an image for RPi’s that you couldn’t miss on Install YunoHost | Yunohost Documentation, but you can take any plain Debian 10 installation as a base.
That’s it, I guess.

For the largest part, it would run like:
Homeserver ← tunnel → VPS ← fixed IP → internet
You can assign a DNS entry to the fixed IP on the VPS as well as a dynamic DNS entry to your homeserver. That way you could skip the roundtrip (and traffic) via the VPS for services that don’t need a fixed IP (for example, have your Nexctloud/portal.fmds directly connecting to your homeserver, but have the fmds domain itself pointing to the VPS for email.
Once again: start easy and cheap, add the VPS later on. It only takes an update in DNS to effect the change, once the tunnel is up, so worry about that later.

1 Like

Correct. I just used it temporarily to see if NextCloud would do what I want it to do. It looks great, I’m satisfied, and I’m fine with blowing that install away, without needing a backup of anything.

Ah, right I see, so I’ll temporarily be using a manual setting in my /etc/hosts file to fool my laptop into looking locally instead of with a DNS lookup to find my test.local machine, right? Sounds good.

Right, I’ll start there, as I’ve been advised to keep my Yunohost setup as “vanilla” as possible, so that I don’t need to remember too many configuration changes, thus avoiding the need for Ansible.

I’m still not sure where my mobile device goes in this diagram, so as to protect my connection on the way in to my internal network. What am I missing here?

That sounds great, especially if I can avoid purchasing the static IP from my ISP straight away, as I had intended to. I should expect that when I do get a VPS, it will be assigned a static IP by the VPS supplier, right? So no need at all for an ISP-supplied static IP?

Thanks so much for all your advice on this. I can at last envision this project taking shape!

Just in passing, sorry for not having read everything in here…

Starting YunoHost 4.3 automatically advertises .local domains via mDNS/Bonjour protocol. So you would not need to tweak your hosts file. :wink:

It also works via VPN, so that I have an Internet-facing VPS with my biggest apps and with some relays/proxies towards a fully local RPi at home.

3 Likes

Yes, correct. It wouldn’t point to test.local, I’d set it do a …fmds… domain directly to see how it works out.

Sorry, I omitted it. It could go two ways:

  • either connecting to your VPS via VPN, and then to your home network (also over -another- VPN): mobile ← VPN(mobile) → VPS ← VPN(server) → homeserver
  • or directly to an endpoint on your homeserver, skipping the extra hoop through the VPS mobile ← VPN(mobile) → homeserver

Correct. The description of the offer will tell that you get an IPv4 and/or an IPv6; usually it is a single IPv4 and a subnet of IPv6, BUT there are exceptions, so keep an eye open when that time comes.

1 Like

These look like conflicting pieces of advice. I have never (successfully) used an FQDN in my internal home network before, so that sounds interesting. I’m up for the challenge.

This looks like what I am looking for. I assume that with the two VPN tunnels to navigate, browsing my home network from my mobile device away from home is going to be rather slow though, right?

I have updated my main diagram with the latest information. What does this look like now?