[08:51:17]
<n00bundercover> Hi everyone! Got a niche issue, would like to hear what you think. To make it short: the new dyndns system to update noho.st and other yunohost domains does not work with openwrt routers when using https dns proxy with "force router dns" enabled (aka dns hijacking). This option is very handy for me, because you can use it to force all dumb smart devices etc that won't let you change dns server to use a privacy friendly server like quad9 over https.
With this option enabled, when I do "yunohost dyndns update --force" I get this error:
ERROR id 54864
opcode UPDATE
rcode NOTIMP
flags QR RA
;ZONE
noho.st. IN SOA
;PREREQ
;UPDATE
;ADDITIONAL
Not sure if the dns request to check if an update is necessary is blocked, or the update itself. I guess the former. Is there a way to make it work with this option? Or: Is there maybe even a way to update the yunohost dns with another client, like the one for openwrt? And just disable the service on the yunohost server? If we could add yunohost to this list it could solve the problem: https://github.com/MarvellEmbeddedProcessors/openwrt-packages/blob/master/net/ddns-scripts/files/services
[08:52:15]
<訢劃> 习近平死妈了
[08:55:17]
<n00bundercover> I know it's a very rare combination... 😅
[08:58:36]
<tituspijean> Hi, can you share the full error log of the `dyndns update` command?
[09:05:30]
<tituspijean> What's the actual effect of that "force router dns" feature?
I feel like the file you pointed to is needed for the router to handle a dyndns. Here we need your YunoHost server to handle it :)
Does the "force router dns" feature intercept requests on port 53? :o
[09:07:47]
<n00bundercover> yunohost dyndns update --force
INFO Update needed, going on...
ERROR id 5689
opcode UPDATE
rcode NOTIMP
flags QR RA
;ZONE
noho.st. IN SOA
;PREREQ
;UPDATE
;ADDITIONAL
INFO Der Vorgang'Die IP, die mit der YunoHost-Subdomain 'mysubdomain.noho.st' verbunden ist, aktualisieren' konnte nicht abgeschlossen werden. Bitte teile das vollständige Protokoll dieser Operation mit dem Befehl 'yunohost log share 20260913-082213-dyndns\_update-mysubdomain.noho.st', um Hilfe zu erhalten
ERROR Konnte die IP-Adresse für DynDNS nicht aktualisieren
[09:07:48]
<n00bundercover> translation: INFO The operation 'Update the IP associated with the YunoHost subdomain 'mysubdomain.noho.st'' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20260913-082213-dyndns_update-mysubdomain.noho.st' to get help.
ERROR Could not update the IP address for DynDNS.
[09:07:51]
<n00bundercover> full log: https://pastebin.com/raw/F4vkmpgv
[09:07:55]
<n00bundercover> yes I believe that's what it does! https://docs.mossdef.org/https-dns-proxy/#force_dns
[09:07:57]
<n00bundercover> regarding the file with dyndns providers: I was not clear. I mean: If I could update yunohost domains with my openwrt router, I would not have to do it on the yunohost device. So I could still force all dns over https and quad9.
[09:07:58]
<n00bundercover> oh and I replaced my actual subdomain with "mysubdomain" if that's not clear
[09:10:23]
<tituspijean> OK I see. One issue is that your YunoHost server directly sends an `nsupdate` command to our BIND server. The configuration file only mentions API services with username and passwords. To authenticate with our BIND server, you only need to use a private/public key, which does not seem to be handled by openwrt.
[09:10:25]
<tituspijean> Is there any way to have an exception list? That would be easier.
[09:10:26]
<tituspijean> Considering all of this, I feel like the empty response is from DNS server that's not YunoHost's 😅
[09:10:28]
<n00bundercover> no excemption list. I don't fully understand what's going on. I think not the nsupdate command is blocked, but the dns request to see if an update is necessary. Is that right you think?
[09:10:32]
<n00bundercover> openwrt routes all dns requests over quad9 with ecs (9.9.9.11). It does resolve all my urls for sure, including the yunohost ones!
[09:10:32]
<n00bundercover> *domains
[09:10:33]
<n00bundercover> I guess the yunohost dyndns tries to force the use of the yunohost nameserver (somehow) to check wetcher ip needs to be updated.
[09:10:35]
<n00bundercover> and because it can't reach it I get an empty response?
[09:13:34]
<tituspijean> that's my understanding of the situation :
- openwrt redirects all DNS requests to quad9
- YunoHost's dyndns needs three requests :
1. check the current IP address with ip.yunohost.org (that's HTTP, so no problem)
2. check that the YunoHost DNS has the correct IP (not checked, but I guess it's intercepted by Quad9 and the request goes to YunoHost DNS anyways)
3. send a `nsupdate` if the IP has changed (or `--force` is used): here my guess is that the nsupdate is sent to quad9, not YunoHost's DNS. Quad9 simply ignores that or returns nothing, hence your log
[09:15:56]
<n00bundercover> (2 is skipped with --force option probably I guess)
[09:17:24]
<tituspijean> You need to find a way around the `force_dns` option. Maybe a firewall rule that has higher priority than your openwrt's to tell "route any request 53 from <YunoHost serverIP> to its destination". I do not know how it's implemented.
(and we are talking about both my nemeses, DNS and network routing 😓 )
[09:30:08]
<n00bundercover> makes sense, will see if I find a way
[09:32:57]
<n00bundercover> thanks!
[09:38:35]
<tituspijean> @n00bundercover:matrix.orgwe might have a hint here: https://github.com/mossdef-org/https-dns-proxy/issues/3
[09:52:29]
<tituspijean> Note that the nsupdate request is made over TCP (regular DNS requests are UDP), so you can add a firewall rule only for your YunoHost server over TCP and port 53.
[09:56:19]
<tituspijean> Something like this maybe? (warning: I am not a Openwrt user, and be wary about tweakin firewall rules 😅):
```
rule
option name 'YunoHost dyndns update'
option src 'lan'
option src_ip '192.168.1.100' # Your YunoHost server IP
option proto 'tcp'
option dest_port '53'
option target 'ACCEPT'
```
[10:00:11]
<n00bundercover> How exactly does the server authenticate me? Is it a random key pair created when first connecting? Would still love to get it to work with the openwrt dyndns package (that's where I update all other domains anyways).
[10:04:20]
<n00bundercover> That's pretty neat, so I could still have most the yunohost dns requests automatically made over my router. Thanks.
[10:09:01]
<tituspijean> Yes, like this: https://github.com/YunoHost/yunohost/blob/c206fff7466ee36b6ed1774a2607d5f52e9be342/src/dyndns.py#L186
Your server sends a subscription request with the generated key and requested domain to our DynDNS registration server, Dynette (https://github.com/YunoHost/dynette).
Dynette checks that the domain is available, updates the BIND server configuration (basically telling it "you can allow requests encoded with that key for that domain"), and returns a success code to your domain.
[10:09:04]
<tituspijean> I'd prefer the firewall option. What you are suggesting is reimplementing the YunoHost-Dynette protocol so that OpenWRT handles it. I understand the request, but I think that could lead to abuse (free dyndns for OpenWRT, not YunoHost servers).
[10:09:05]
<n00bundercover> Well I doubt I'll get that far but one could implement it in a way that in openwrt, it only asks for the already set up key. It would not contain the whole setup/handshake part. So for abusing it and getting free subdomains, the openwrt part would be useless, and one would still have to look that up in the yunohost sources.
[10:09:06]
<n00bundercover> But I agree the firewall option for tcp on port 53 is quick and easy and should work reasonably well, thanks for the idea.
[10:14:48]
<訢劃> Who on earth could tolerate their own country's territory being given directly to an enemy nation?
[10:15:08]
<訢劃> Obviously, there is such a talent in China.
[10:15:15]
<訢劃> His name is Jiang Zemin.
[10:16:28]
<訢劃> He signed an agreement with Russia called the Treaty of Good-Neighborliness and Friendly Cooperation.
[10:16:44]
<訢劃> Abandoned all claims to territories occupied by Russia.
[10:32:35]
<sitegui> Hello :)
I've organized a small "ynh install party" with friends and we've explored using tailscale to securely expose the Yunohost server.
It went pretty well and the people were very happy and impressed with the project 🤘
We've installed tailscale to a phone and to the server. The way tailscale works, once connected, the phone can refer to the server using a "long" or "short" DNS:
- https://jauto-heberge.taile123.ts.net
- https://jauto-heberge
Yunohost didn't accept the short DNS (both the [admin UI](https://github.com/YunoHost/yunohost-admin/blob/707318b8d171a7a4c100dbb79c3d34d51dee4303/app/src/helpers/validators/customValidators.ts#L15) and [admin CLI](https://github.com/YunoHost/yunohost/blob/c206fff7466ee36b6ed1774a2607d5f52e9be342/share/actionsmap.yml#L102) have regexes that reject it).
Would you be open to a MR updating the regexes so that domains without dots are accepted?
Do you anticipate any problem in some sub-system (nginx, sso, ldap, etc) with the short DNS?
I can help implementing and testing it ☺️
[10:54:01]
<orhtej2> > <@sitegui:matrix.org> Hello :)
>
> I've organized a small "ynh install party" with friends and we've explored using tailscale to securely expose the Yunohost server.
> It went pretty well and the people were very happy and impressed with the project 🤘
>
> We've installed tailscale to a phone and to the server. The way tailscale works, once connected, the phone can refer to the server using a "long" or "short" DNS:
> - https://jauto-heberge.taile123.ts.net
> - https://jauto-heberge
>
> Yunohost didn't accept the short DNS (both the [admin UI](https://github.com/YunoHost/yunohost-admin/blob/707318b8d171a7a4c100dbb79c3d34d51dee4303/app/src/helpers/validators/customValidators.ts#L15) and [admin CLI](https://github.com/YunoHost/yunohost/blob/c206fff7466ee36b6ed1774a2607d5f52e9be342/share/actionsmap.yml#L102) have regexes that reject it).
>
> Would you be open to a MR updating the regexes so that domains without dots are accepted?
> Do you anticipate any problem in some sub-system (nginx, sso, ldap, etc) with the short DNS?
>
> I can help implementing and testing it ☺️
I believe there's a tutorial for this exact use case here: https://forum.yunohost.org/t/create-your-intranet-with-a-vpn-and-your-own-dns-with-yunohost-adguard-and-headscale/37393
[10:55:13]
<orhtej2> there's some DNS-fu involved IIRC
[10:56:59]
<tituspijean> I'd put that short domain thing pretty low on the list of our priorities, especially if you did not or cannot assess the safety implications. 😅
[11:00:01]
<tituspijean> Bonus from my tutorial, you can use an internal subdomain instead of relying on tailscale's ts.net. Yay, more independence. :)
[11:45:46]
<sitegui> Thanks for writing that tutorial, it's pretty complete!
I've had already read it (forgot to mention in my question, sorry).
I understand the suggestion, but I'm aiming for a simpler setup for people new to self-hosting, and also something that they can learn and apply during the install party workshop.
So this means, for example, that configuring their routers is not possible (the workshop is a city room).
So from the tutorial I can take many ideas, but with some changes:
- no headscale, using tailscale in a first attempt is okay and simpler
- no need for Yunohost to be publicly accessible, since that is the goal
I understand that tailscale doesn't let us set subdomains like https://wiki.jauto-heberge and for that I need to use a DNS (like AdGuard) on the server itself.
However, the same 2 regex I've linked do not allow it because the top level domain has a `-`.
I can help assessing the security (and functional) impact on the rest of the system of accepting such short DNS (and "custom" tld).
But if you believe that following this work is too risky and not a priority, I can let go and only work with the long DNS in the workshops 👍️
[12:55:16]
<Romain[m]> Recently I started to notice warning in my backups logs about not being able to write to `/home/yunohost.backups/tmp/xxxx`, both in my nightly backups and in the pre-upgrade app backups. Just now when upgrading synapse I also saw similar warnings about `/var/cache/yunohost/app_tmp_work_dirs/app_ik4wymw7/scripts`. It could be happening since the recent permissions migration, but I'm not sure.
The backups seem to proceed successfully and have the expected size, though I have not tried to restore one. The first one could be because `/home/yunohost.backups//` is mounted on a separate hard drive, but no clue what could explain the second one, I didn't mess with permissions as far as I can remember.
Should I worry about these warnings?
[14:38:08]
<tituspijean> can you share the full logs (with yunopaste)?
With an SSH shell, what's the output of the following commands?
```
sudo ls -ld /home
sudo ls -ld /home/yunohost.backup
sudo ls -ld /home/yunohost.backup/tmp
```
[14:41:37]
<tituspijean> ```
sudo ls -ld /var/cache/yunohost
```
[18:25:43]
<Romain[m]> Sure thing, here is today's log of synapse upgrade : https://paste.yunohost.org/raw/ijohifiguw
I realise I said "could not write to" but to be more precise, the log says "could not change to".
Also you can see in the logs the warning about the cache folder, but not the one about `/home/yunohost.backups/tmp`, though I can still see it in my SSH shell.
> INFO Now upgrading synapse…
> INFO Creating a safety backup prior to the upgrade
> INFO Collecting files to be backed up for synapse…
> WARNING It's highly recommended to make your backup when the service is stopped. Please stop synapse service with this command before to run the backup 'systemctl stop synapse.service'
> INFO Declaring files to be backed up...
> WARNING could not change directory to "/home/yunohost.backup/tmp/synapse-pre-upgrade1/apps/synapse/backup": Permission denied
And here are the ls outputs:
```
root@my-server:~# ls -ld /home
drwxr-xr-x 20 root root 4096 Apr 1 2025 /home
root@my-server:~# ls -ld /home/yunohost.backup
drwxrwx--- 6 root admins 4096 May 5 2025 /home/yunohost.backup
root@my-server:~# ls -ld /home/yunohost.backup/tmp
drwxrwxr-x 2 root root 4096 Sep 13 12:42 /home/yunohost.backup/tmp
root@my-server:~# sudo ls -ld /var/cache/yunohost
drwx------ 10 root root 4096 Sep 13 12:45 /var/cache/yunohost
```
[18:53:23]
<Chatpitaine Caverne #antifa> Salut,
Nous avons un souci avec les mails. Le diag nous a signalé trop de messages dans la file d'attente.
J'ai lancé la commande mailq et il en ressort que le mail de l'un de nos utilisateurs est utilisé pour des activités suspectes. Nous nous retrouvons black-listés à pas mal d'endroits. Ce n'est pas massif et probablement pas un bot (197 messages en 3 jours).
Comment pouvons-nous faire pour investiguer où est la faille et comment stopper cela ?
A noter que cet utilisateur a surtout utilisé Funkwhale et je soupçonne que l'attaquant soit passé par là, mais pas du tout certain.
[19:09:39]
<Chatpitaine Caverne #antifa> Romain: Looks like I have the same kind of warning messages on permission during my Synapse upgrade. I just saw the "Fixing DB collation version" issue, but my mail issue took all my attention and I forgot.
[19:14:13]
<Romain[m]> Right, I think that's a different warning, which indeed has been in my logs for a long time. Probably a small thing to fix but I've been delaying it over and over 🙈
[19:17:38]
<Chatpitaine Caverne #antifa> Sorry, I was not clear enough. I have also the same other errors as you.
[19:32:54]
<Chatpitaine Caverne #antifa> Dois-je supprimer les messages dans la file par la commande `postsuper -d ALL`. Ceux-ci seront-ils re-tentés en envoi ou bien restent-ils juste là ?
J'ai sauvegardé ces messages par `mailq > FICHIERDESORTIE`
[20:12:01]
<Chatpitaine Caverne #antifa> Bon, ben j'ai arrêté le service postfix en attendant d'y comprendre quelque chose.
Je suis crevé, je dois dormir. Je n'aime pas poser une question et partir, mais là, pas le choix.
[20:17:45]
<DrPi> I had the same problem with several applications. It looks like it was a one shot warning since another upgrade did not output the same kind of warning.
Maybe this is due to the recent migration rewriting permissions.
[22:28:53]
<miro5001> > <@chatpitaine:cirkau.art> Bon, ben j'ai arrêté le service postfix en attendant d'y comprendre quelque chose.
> Je suis crevé, je dois dormir. Je n'aime pas poser une question et partir, mais là, pas le choix.
Essai avec ce script https://github.com/DeMiro5001/Linux-scripts/blob/main/yunohost/mail-report
Il faut faire quelques modifications pour afficher le log au lieu de l'envoyer par mail. Il faut aussi lire le script pour comprendre ce qu'il fait