Hello,
here's now what I found. I'll also post a bug report later.
It's quite normal that the SME Server does not update the DynDNS records due the boot process -- because there is, from the point of view of SME Server, no need for.
SME Server stores the external IP address it was given at the last DHCP request. At the next boot, SME requests for an IP again. If the DHCP server sends the same IP address than before, there is no change of the IP address for the server, so SME don't generate the event ip-change -- because no service or configuration file needs any update, everything is like before.
When the SME server is connected directly to an internet provider via DSL or LAN and gets always the same IP address (e.g., static IP), everything is fine and the DynDNS record needs no update either -- so only the cron job running once a week on Sunday, 4:22 am, updates the record regularly so the DynDNS hostname don't get deleted because it's obviously unused. If the DHCP server changes its mind and sends a new IP, SME generates the ip-change event, updates the config files and the DynDNS entry, so it's ensured that the DynDNS hostname points always to the SME Server.
But when the SME Server resides behind a router, e.g. a Fritzbox configured to make some SME services available trough port forwarding, and you use some kind of dynamic DNS service which retrieves your IP address from the update request you send, you need DynDNS updates very time you make a new internet connection. In that case, you should use your router for the dynamic DNS updates -- this is the only device which knows when your external IP address has changed.
There is another problem: When you left out the dynamic DNS configuration when configuring SME Server at first, or if you made any typing error at the DynDNS username or password or there is no internet connection when you configure the server first.
At the first bootup, the configuration script asks for several network settings, including the dynamic DNS service. If you enable the dynamic DNS at this point, the first startup, the SME server detects an ip-change because of the initial configuration of your network devices and updates the DynDNS records as desired. After that, a reconfiguration is only required if the external IP address of the SME Server changes -- or on Sunday to keep the DynDNS hostname. But SME Server does not check if the initial call of update-dns was successfull -- if you have a typing error in the username or password of the DynDNS account, or there was for any reason no internet connection or any problem doing the record update, you face exactly the same problems as if you configure DynDNS later on. That's the first thing I call a bug.
If you reconfigure your server later and add the dynamic DNS feature, SME Server configures everything -- but there is no ip-change event! Therefor, SME Server does not update the DynDNS record after the config script ends -- it waits for the next IP address change or next sunday. This means, your DynDNS hostname does not point to your server, and the admin wonders why. Of course, he'll fiddle around with the DynDNS configuration -- but this will not help, SME waits for the ip-change signal. I call this a bug and will report it.
The easy workaround is, to call "signal-event ip-change" after configuring the dynamic DNS feature, or to call /etc/e-smith/events/action/update-dns instead. Both will work.
One, possibly false, assumption SME Server makes is, that the DynDNS records will never change outside of SME Server. To ensure that the DynDNS record really points to the IP of the external address, SME should check every time the device is bound or rebound to an IP address where the DynDNS hostname is pointing to. This is the only relieable method. I suggest to add this check and the possibly needed update-dns call in one of the next versions of SME Server.
Greetings, Mirko
8 Replies
2160 Views