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

I don’t have an ‘initial’ install as recent as Yunohost 4.1.x; so, for me it was (indeed) necessary to explicitly accept the repository change. Did you have to do that as well, when running apt? (There would be some five times a message along the line of ‘changed from stable to old-stable, accept?’)

I ask, because though in theory an upgrade via apt upgrade yields the same result as using yunohost tools upgrade system, the yunohost command has some extra logging and error recovery built in. If everything runs the way it should, there is no difference, but in case of problems, the yunohost command gives some more information.

Besides that, it also gives a nice command you can copy and paste to have your logs anonymized and uploaded to paste.yunohost.org. The output from apt prior to upgrading (as posted on git) is only a list of intended changes, but does not give information at what actually happened.

Dec 18 22:21:15 test-fmds.noho.st ntpd[585]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution

and

Dec 18 22:00:31 nginx[745]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org" in the certificate "/etc/yunohost/certs/test-fmds.noho.st/crt.pem"

have in common ‘host not found’; that rings a bell. Could you have a look at your /etc/hosts ? And see if you can ping any hostname on the 'net?

As in your example, my machine also has the __init__.py file, but no init.py file in that folder.

$ 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

Yes, looks like it is there.

No, none.

Yes, I did have to do that first. Sorry, I should have documented that step in my most recent Progress Report. They will become a handy step-by-step procedure list if/when I come to reinstall.

I hadn’t seen that command yet. I’ll keep that one in mind. On my laptop, I am quite used to using sudo apt-get update && sudo apt-get upgrade regularly. But now that I’m running a server which will (eventually) be hosting other people’s data, I need to learn some new tricks, like you have suggested here. Thanks.

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1               yunohost

127.0.0.1       test-fmds

I just tried to ping the test-fmds hostname from my laptop, and got this reply…

ping: test-fmds: Temporary failure in name resolution

I should probably point out that in this post from earlier, I had mentioned that I’ve disabled my existing Pi-Hole Raspi, and changed the DHCP packet being sent by my router to all devices, such that it now points to my ISP for the primary and secondary DNS resolvers for all devices connected to my network. I don’t know whether that is a factor, but it seems relevant to mention it here. Everything else seems to work fine, and my wife hasn’t complained about “no Internet access”. That is normally my litmus test, haha.

Do you want to keep pursuing this, and see if we can fix this problem? I’m happy to just blitz the box and start again, at this point. I’ll be getting those new USB3.1 flash drives later today, anyway.

EDIT: Also of note, I haven’t received any more automated emails from the root@test-fmds.noho.st Yunohost root account since the upgrade to v4.3.4.2 yesterday. Nothing at all.

Sorry, I shouldn’t have asked for the hosts-file, but for /etc/resolv.conf which had a warning earlier on! How about that one? Mine is a symlink to /etc/resolvconf/run/resolv.conf, and has localhost as nameserver (where the honours are observed by dnsmasq):

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

$ ls -ahls /etc/resolv.conf
0 lrwxrwxrwx 1 root root 31 Oct 28 21:03 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf

$ service dnsmasq status
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-12-17 06:45:40 UTC; 2 days ago
  Process: 1407136 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
  Process: 1407137 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
  Process: 1407145 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
 Main PID: 1407144 (dnsmasq)
    Tasks: 1 (limit: 38276)
   Memory: 1012.0K
   CGroup: /system.slice/dnsmasq.service
           └─1407144 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --l

Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 185.233.100.100#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 185.233.100.101#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 195.160.173.53#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 89.233.43.71#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 194.150.168.168#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 2a01:3a0:53:53::#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 2001:910:800::40#53
Dec 17 06:45:38 online dnsmasq[1407144]: using nameserver 2a0c:e300::100#53
Dec 17 06:45:38 online dnsmasq[1407144]: read /etc/hosts - 6 addresses
Dec 17 06:45:40 online systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

Here are my results…

admin@test-fmds:~ $ ls -ahls /etc/resolv.conf
0 lrwxrwxrwx 1 root root 31 Dec 17 10:06 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf
admin@test-fmds:~ $ service dnsmasq status
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-12-18 22:00:29 GMT; 22h ago
  Process: 535 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
  Process: 571 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
  Process: 620 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
 Main PID: 619 (dnsmasq)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/dnsmasq.service
           └─619 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --

By the way, can you please tell me what you use in your forum posts here after the three backticks, to get your formatted output? I have tried sh, bash, and console, but I can’t get the same output as you get.

The tasty bits are missing :slight_smile: Resolving of domainnames gets stuck somewhere. Which nameservers are listed in /etc/resolvconf/run/resolv.conf, and does service dnsmaq status output a list of nameservers? (In my paste above, they drop just below the bottom of the code window)

I use three or four backticks on a line by themselves, then a new line where I paste my texst, and then the same number of backticks on a new line by themselves. My console output looks quite drab, it is the forum that deals with the colours :slight_smile: (but it is Bash on Konsole with a more or less standard profile on my end)

Does this help at all?

admin@test-fmds:~ $ cat /etc/resolvconf/run/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search Home

No, my results for service dnsmaq status are exactly as I posted them above, with no extra information underneath.

Hmm, normally we can specify the language code after the three backticks, (such as ```js) to get the code formatting to look right in the specified language. Your BASH output always looks so much prettier than mine, so I was just wondering what you use as the language code, to make them look that good.

I don’t know whether that is significant. I’ll check another server, see what the response there is.
For the time being, you could add another nameserver to resolv.conf; it will be overwritten later when you found the cause of the problem, but for now it is a workaround to, I expect, get name resolution back. With some luck that will give you access to the web interface.

Another server did not show a list of used nameservers; it shows the last few lines of the log, if the log has been rotated, there’s nothing to show.
After restarting dnsmasq, I also get a list of nameservers on that host. Care to give it a try?

admin@test-fmds:~ $ sudo yunohost service restart dnsmasq
Success! Service 'dnsmasq' restarted
admin@test-fmds:~ $ service dnsmasq status
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-12-19 21:57:04 GMT; 50s ago
  Process: 19825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
  Process: 19826 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
  Process: 19838 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
 Main PID: 19837 (dnsmasq)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/dnsmasq.service
           └─19837 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new 

Still nothing underneath there, except for a whole heap of lines with just a tilde ~ on them. The web interface is unreachable.

Did you add a nameserver to resolv.conf as a workaround?

I have just tried editing /etc/resolv.conf now, and tried it with /etc/resolvconf/run/resolv.conf as well, but the web interface for Yunohost is still unreachable. Do I need to do anything else after changing the nameserver, such as restarting the dnsmasq service again?

By the way, I now have my two new 32GB USB3.1 flash drives, and I’m keen to reinstall this all from scratch, whenever.

The one should be a symlink to the other; /etc/resolv.conf is actually used by the system.

I don’t recall that being necessary. Your public IP has not changed, by coincidence? Is domain resolving working now, when you ping an external domain for example?

You want to replace the uSD card anyway, no reason to postpone it. Does the RPi boot directly from USB?

Yes! It works! :tada: :heart_eyes: I have conscripted an old 8GB USB2.0 flash drive as my new “rpi-rescue” boot disk, and installed Raspbery Pi OS 11 (Bullseye) on it. It boots nicely from the USB port on the pi, without any SD-card. I’ll keep that one on hand if I get into any troubles again with booting up.

I might just take a break here for Christmas. I’m satisfied with what I’ve achieved so far. I’ll be back in the New Year, and get my setup running fully under Yunohost on the test-fmds.noho.st raspi. By about June 2022 I hope to roll out my production system on the primary fmds.noho.st raspi. Thanks for all the help so far everyone, and especially to @wbk for sticking with me through this project.

yunohohohost-meri-kirihimete

3 Likes

I have created a rollout plan for my test-fmds.noho.st installation. My plan involves a fortnightly staged rollout of each app under YunoHost, giving me time to focus on configuring and fine-tuning each app. The rollout plan is available on this calendar, but here are the essentials…

  1. debian_80px Debian base and yunohost_80px YunoHost — :dart: 16-Jan-2022

  2. netdata_80px Netdata:dart: 30-Jan-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  3. pi-hole_80px Pi-Hole:dart: 13-Feb-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  4. wireguard_80px WireGuard:dart: 27-Feb-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  5. nextcloud_80px NextCloud:dart: 13-Mar-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  6. vaultwarden_80px VaultWarden:dart: 27-Mar-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  7. borg_80px BorgBackup:dart: 10-Apr-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  8. firefly-iii_80px Firefly III:dart: 24-Apr-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  9. grocy_80px Grocy:dart: 8-May-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  10. monica_80px Monica pCRM:dart: 22-May-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  11. wordpress_80px Wordpress:dart: 5-Jun-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  12. webtrees_80px Webtrees:dart: 19-Jun-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  13. calibre_80px Calibre-web:dart: 5-Jun-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  14. owntracks_80px OwnTracks:dart: 17-Jul-2022 — yunohost-apps_80px yunohost-forum-tags_80px

  15. jellyfin_80px Jellyfin:dart: 31-Jul-2022 — yunohost-apps_80px yunohost-forum-tags_80px

I want to get Netdata installed early, so that I can keep an eye on the load on the Raspberry Pi, particularly CPU and RAM load, as I add extra apps. I may need to purchase another Raspberry Pi for this project before I finally deploy my production fmds.noho.st environment.

211230_1158_fmds-deployment-plan_test_tree-view

The apps identified in the image above, with •VPN at the end, will only be accessible from within our home LAN network, or via a secure VPN tunnel connection.

211230_1101_fmds-deployment-plan_test_github-project-board

Looks like a plan, good luck!

I have just posted a question on the prometheus_80px Prometheus Discourse forums, enquiring about how best to use their software as I roll out my project, to ascertain the load on my RasPi device. I’m still weighing up whether to use prometheus_80px Prometheus or netdata_80px Netdata for the monitoring. Any advice from the user community here?

EDIT: See also this thread by @wbk.

:heavy_check_mark: I have requested a reset of my former test-fmds.noho.st domain, as I prepare for the new install on the 32GB USB3.1 flash drive in the New Year.

I have asked a question elsewhere on the YNH forums, about which version I should install…

  • YunoHost v4.3.4.2 installfest — can begin immediately
  • YunoHost v4.4.x installfest — t.b.a
  • YunoHost v11 installfest — t.b.a

EDIT: I had a reply from @Aleks on this question, and now I’m good to go, ready to start installing v4.3.4.2 from 1-Jan-2022 (that is tomorrow, for me). I’m looking forward to it!

2 Likes

nga-mihi-o-te-tau-hou

Happy New Year! My project of installing yunohost_80px YunoHost on my raspberrypi_80px Raspberry Pi devices begins in earnest today. Don’t expect this to be a quick install though. My planned “installfest” is going to be spread throughout 2022 in two major stages: ❶ rolling out the test-fmds.noho.st machine first; then later in the year I’ll be ❷ rolling out the full fmds.noho.st device. Also during this project I will be learning more about git_80px git and github_80px GitHub, as I attempt to make my project easily replicable for future rollouts and deployments from the test to prod devices. My ultimate goal is to have two fully operational yet independent devices, both capable of running my

“Frittro’s Managed Data Store” project, but with one able to be freely modified and “hacked on” while the other remains highly available and resolute for my end users. In the future, as new software releases and updates become available, I will deploy them to the test device first, and ensure that everything is working properly there. Then, hopefully, I can deploy the required changes and updates to the prod device just using git. That is my hope, anyway. I still have a lot to learn about using git and GitHub first though, as I am more of a sysadmin/ops person than a developer, so I don’t have a huge amount of experience with git.

220101_0835_github-showing-1-commit-ahead

1 Like

:warning: Can’t boot the test raspi from the USB! — :white_check_mark: SOLVED

Oh dear, my very first step went awry. A few days ago, I tested the booting from USB on the prod raspi and it worked perfectly. When I went to do it for real on the test raspi, I just get the error screen at boot time, saying that it can’t find the sd-card. I then tried booting the test raspi from the sd-card which I had used in the prod device earlier, so that I could see the BASH history, and re-run the same commands to get the EEPROM updated on this one, the same as I did on the other one. I assume that is the problem here. Unfortunately, that didn’t seem to help this time. I’m searching for a solution now.

EDIT: I went back to the YT video where I had learned how to do this, and realised that by using the BASH history I had missed an important step which was done in the UI, not on the CLI. I hadn’t changed the Bootloader Version. I’ve done that now, and written the changes, and my test raspi now boots from the USB drive. Yay!

1 Like