Question regarding location of previous address history

[syntax53]

I am working on a windows fork of this. There really wasn't much to modify to get it to work under windows. Basically just remove the daemon imports and functionality (and then schedule it with a windows scheduled task).

I am not a python programmer but am able to follow the code for the most part. However, I noticed that it always thinks the address has changed and then tries to update dreamhost on every execution. I cannot see anywhere were it actually stores (and then recalls) the previous address that was pulled. Everytime it runs it thinks the previous address was 127.0.0.1.

Thanks

[syntax53]

So I am assuming you weren't storing it any way and the previous addresses were only used when it was running as a daemon. At least after fiddling with the code all day that's what it seems like :)

Here is my fork: https://github.com/syntax53/dhdynupdate-windows

I added support for windows and storing the previous addresses in a file as well as the ability to look up your external IP and use that instead, like a true dynamic DNS tool. I had to modify quite a bit for those last two things, mainly in the way the previous addresses get tossed around.

[ttelford]

I'll definitely review your fork, I've only glanced at it so far (busy day), but so far, it has some good ideas.

then schedule it with a windows scheduled task

Any interest in making it run as a Windows service? I'm not proposing removing the ability to run as a scheduled job; just recognizing that I don't have a Windows box to test with, and I'd personally like to have it capable of running as a Windows service.

So I am assuming you weren't storing it any way and the previous addresses were only used when it was running as a daemon.

Yup. No need to store it on disk when the dæmon tracks it.

I added support for windows and storing the previous addresses in a file as well as the ability to look up your external IP and use that instead, like a true dynamic DNS tool.

I can definitely see a worthy addition in being able to run as a scheduled job (which also can be done on unix-ish systems). Personally, I'd rather have it run as a Windows service (ie. dæmon-ish), and not store anything on disk, but options are good.

As far as looking up an external IP: In my particular case, it's not necessary: my interface addresses are the external addresses. So for my particular machine/network, it's only necessary to check the local interface addresses. My use case is not the most common for IPv4.

There's definitely value in alternative ways to get the external IPv4 addresses; for example, the original state of the code doesn't handle the use case where the system running dhdynupdate is sitting behind a NAT.