Simple DynDNS bash script for deSEC

[KapernMagIchNicht]

Hi there

After my GO script, I decided to write something simpler in bash.

deSEC_DynDNS is a very basic bash script that caches the last set IP and only issues an update command, when it changed.

It can’t catch errors and is unable to handle timeouts or anything like that. It also can only handle a single domain.

If you have any feedback or suggestions, I am happy to hear them. I don’t know if I can implement them, since I currently don’t have a lot of time and I am not a coder.

Maybe this is of use for some of you.

GitHub - jameskimmel/deSEC_DynDNS

[nils]

Hi,

Thanks for sharing!

We recently had some performance issues that stem from everyone updating their dynDNS at the same time. Popular times are full hours, quarter hours, and at the top of each minute.

A great improvement for deSEC would be if the script incentives avoiding these times somehow, e.g. by adding a randomized sleep (0 to 60seconds). Also, the readme could contain a note to avoid rush hour times or ok how to randomize execution time.

Erratic 502 Bad Gateway responses on update.dedyn.io

Reasonable. However, I don’t think many user will see this advice here. I suggest adding it to the docs. And maybe it would make sense for you to customize the 502 error response to include information on the problem and how user can solve it from themselves and for others. I wonder what kind of limit would help. Limiting to one update in 5 or 15 minutes would probably just make people schedule their cron jobs to */5 or */15, contributing to rush hour problem. Something like once per hour mig…

Thanks!
Nils

[mihi]

Just a small nit, but when you try to obey the filesystem hierarchy standard and put your script to /usr/local/sbin (as opposed to, /root or /opt), you should put the cache files to /var/local as they are variable and not static data.

[KapernMagIchNicht]

@nils

A great improvement for deSEC would be if the script incentives avoiding these times somehow,

Since the script is run by crontab, my guess is that probably it is best to use some kind of sleep in the crontab. Something like this:

sudo */5 * * * * sleep $(( RANDOM % 300 )); /usr/local/sbin/deSEC_DynDNS.sh > /dev/null

but then again, I am unsure what this would achieve. As I said, the script only sends an update request to deSEC, if the IP changes. So in 99% of the cases this is run, it won’t connect to deSEC. On the other hand, if the IP actually changed, you probably don’t want even more delay than the 5min you already have because of the crontab. Or am I missing something?

@mihi

put your script to /usr/local/sbin (as opposed to, /root or /opt), you should put the cache files to /var/local as they are variable and not static data.

Cheers for that, will edit it.
While we are at it, even though I did some reasearch, I wasn’t able to find a good answer for this; wouldn’t it be even better to not run this script as root? I tried to put it in /usr/local/bin but even that folder is set to root permissions. Some people suggest /opt/bin, but at the same time it is gone from newer Ubuntu installations.

[mihi]

@KapernMagIchNicht

On the other hand, if the IP actually changed, you probably don’t want even more delay than the 5min you already have because of the crontab. Or am I missing something?

The average delay until an IP change is detected is 2.5 minutes, regardless whether you start it at full 5 minute, or offset by a constant amount of seconds, or offset by a random amount of seconds. Think that way - if the IP changes at 12:51, without delay you would have a 4 minute delay, but when your delay happend to be 70 seconds, it would have only a 10 seconds delay.

This is true under the assumption that IP changes happen randomly - if your ISP times IP changes to always happen at the same time, it is more advisable to check at that time or one minute later.

by the way, crontab also supports 2-59/5 syntax to run at minutes 2,7,12,…

While we are at it, even though I did some reasearch, I wasn’t able to find a good answer for this; wouldn’t it be even better to not run this script as root?

In general, yes. Running as nobody won’t work as nobody has no write permissions anywhere except /tmp, so you would need to create a dedicated user (and group) for it.

I tried to put it in /usr/local/bin but even that folder is set to root permissions.

Difference between /bin and /sbin is not about who may put binaries there (bot only root), but who is supposed to run them (/sbin is in $PATH only for root).

If your program running as a different user needs variable files that it has to edit, the convention is to put them below a custom directory /var/{local/}spool/<programname> or /var/{local/}/cache/<programname> (by convention, cache may be cleared by the OS or sysadmin if it desires while spool should be preserved), and change the permissions of that directory to be group writable (or even sgid) and add your files in there.

Some people suggest /opt/bin, but at the same time it is gone from newer Ubuntu installations.

The convention would be /opt/<programname>/bin while other files for the same program would go to /opt/<programname>. Note that this is not in $PATH for anybody by default, so binaries that should be ran by regular users are often symlinked elsewhere.

And while directories from the filesystem hiearchy standard need not exist, the convention for installers is to use /bin/install instead of /bin/cp to copy the files there, which will create missing directories and set the permissions correctly as well.