-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch issue 21 (Issues on OpenWRT 22.03.4) #22
base: master
Are you sure you want to change the base?
Conversation
Fixes Issue 3 in filiparag#21
Removes Number 2 in filiparag#21
Remove .sh suffix Helps on filiparag#21
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @carstencodes,
thank you for your patch! Appreciate it!
I felt so free and commented two small things and also reported from my test. If you want, please feel free to look into the review details.
Despite the strange behaviour around the owner of the config file (and the two comments) this looks good to me.
I also was able to spawn a manual daemon process as root, without managing the hetzner_ddns
with the service
command by simply typing: hetzner_ddns -d
. So this still works in addition, if someone don't want to use the init script.
Also permissions on .pid
and log .log
look good:
# ll /var/log/hetzner_ddns.log
-rw-r--r-- 1 nobody nogroup 8570 Dec 27 20:26 /var/log/hetzner_ddns.log
# ll /var/run/hetzner_ddns.pid
-rw-r--r-- 1 nobody nogroup 6 Dec 27 20:26 /var/run/hetzner_ddns.pid
I also tested a change for the IP address, which worked fine (currently I have no IPv6 entry):
[2024-12-27 20:44:20] Update IPv4 for cloud.refractedlight.eu: 172.0.0.1 => 84.135.98.123
EDIT:
Wanted to leave the info
output from the inital bug, which looks also fine now:
# service hetzner_ddns info
{
"hetzner_ddns": {
"instances": {
"[hetzner_ddns]": {
"running": false,
"command": [
"/usr/bin/hetzner_ddns",
"-d"
],
"term_timeout": 5,
"exit_code": 0,
"limits": {
"core": "0"
},
"pidfile": "/var/run/hetzner_ddns.pid",
"user": "nobody"
}
}
}
}
_LOG_FILE=/var/log/hetzner_ddns.log | ||
_PID_FILE=/var/run/hetzner_ddns.pid | ||
|
||
fix_permissions() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also set the owner of the config file to nobody:nogroup
?
I did encounter issues when leaving it to root:root
.
What I did:
- changed the config file contents in order to match my zone on hetzner
- restarted the service with
service hetzner_ddns restart
- had a look in my log file which showed me the following:
[2024-12-27 19:52:00] Started Hetzner DDNS daemon
[2024-12-27 19:52:00] Error: unable to read configuration file /etc/config/hetzner_ddns.conf
- after changing the owner of
hetzner_ddns.conf
tonobody:nogroup
I could process the config file, because the log showed me this:
[2024-12-27 20:26:07] Started Hetzner DDNS daemon
[2024-12-27 20:26:07] Reading configuration from /etc/config/hetzner_ddns.conf
[2024-12-27 20:26:07] Info: update of A records not set, enabling by default
[2024-12-27 20:26:07] Info: update of AAAA records not set, enabling by default
[2024-12-27 20:26:09] Zone for refractedlight.eu: <redacted>
[2024-12-27 20:26:09] IPv4 record for cloud.refractedlight.eu: <redacted>
[2024-12-27 20:26:09] IPv6 record for cloud.refractedlight.eu: (missing)
[2024-12-27 20:26:09] Configuration successful
[2024-12-27 20:26:09] Watching for IP address and record changes
- then I also could confirm that the process is running:
# ps | grep hetzner
17873 nobody 1564 S {hetzner_ddns} /bin/sh /usr/bin/hetzner_ddns -d
But maybe this was just something strange on my installation... I am not that sure.
Did test that with
hetzner-ddns_0.2.7-1_all.ipk.txt
(.txt
suffix only because of GitHub rejecting pure .ipk
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is strange. I will give it some further investigations in the course of the weekend, but what permissions did your config file have after installation/editing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the fuss, seems that I did something wrong previously or had some older configuration files.
Installation history
root@danielcpe ~
# opkg install hetzner-ddns_0.2.7-1_all.ipk
Installing hetzner-ddns (0.2.7-1) to root...
Configuring hetzner-ddns.
root@danielcpe /etc/config
# ll hetzner_ddns.conf
-rw-r--r-- 1 root root 453 Dec 27 14:34 hetzner_ddns.conf
root@danielcpe /etc/config
# cat hetzner_ddns.conf
interval=60 # Seconds between updates / TTL value
key='********************************' # Hetzner DNS API key
domain='example.com' # Top level domain name
records='homelab media vpn' # Space separated host subdomains (@ for domain itself)
ipv4=true # Enable updating A records (IPv4)
ipv6=true # Enable updating AAAA records (IPv6)
root@danielcpe /etc/config
# cat /var/log/hetzner_ddns.log
[2024-12-29 17:14:55] Started Hetzner DDNS daemon
[2024-12-29 17:14:55] Reading configuration from /etc/config/hetzner_ddns.conf
[2024-12-29 17:14:56] Error: Invalid API key
Now the configuration file is owned by root, but the daemon process is running and owned by nobody and the update works:
16841 nobody 1564 S {hetzner_ddns} /bin/sh /usr/bin/hetzner_ddns -d
[2024-12-29 17:32:34] Watching for IP address and record changes
[2024-12-29 17:36:14] Update IPv4 for cloud.refractedlight.eu: 127.0.0.1 => 84.135.98.106
TL;DR Seems fine now ✔️
As described in filiparag#22 (comment) this must be updated as well
Closes #21
/cc @LLdaniel