[7.902][BUG][UNABLETODUPLICATE] Can't make DynDNS update

7.902 - upgraded from fresh 7.900 install.

I added a DynDNS entry yesterday, and since it wasn't updating I tried to delete it and recreate it.

When I do the status of "The last update was successful." and modified timestamp of "DynDNS modified: Thu Apr 15 09:37:01 2010" comes back on the newly created DynDNS before I've even turned it on. So the status data must not be deleted when I delete it from the Astaro.

Because of this I can't seem to find any way to force the Astaro to update my DynDNS. Did a renew on my cable modem interface (getting the same IP I had) and it still says that the last update was successful with yesterday's date/time. I've turned the DynDNS off and back on, and it still doesn't try to update. 

No matter what I do it continues to say "The last update was successful." with yesterday's timestamp and my dyndns still has the wrong IP.

  • Hi physon!

    Can you grep for ddclient in /var/log/system.log if there is any suspicious ?
    grep ddclient /var/log/system.log

    Whats in /var/cache/ddclient/ddclient.cache?
    cat /var/cache/ddclient/ddclient.cache

    Cheers
     Ulrich
  • fw:/home/login # fgrep ddclient /var/log/system.log
    
    fw:/home/login # cat /var/cache/ddclient/ddclient.cache
    ## ddclient-3.8.0
    ## last updated at Thu Apr 15 09:37:21 2010 (1271338641)
    atime=1271338621,backupmx=0,custom=0,host=removedfw.homeunix.com,ip=8.8.8.50,mtime=1271338621,mx=,static=0,status=good,warned-min-error-interval=0,warned-min-interval=0,wildcard=0,wtime=30 removedfw.homeunix.com
    fw:/home/login #


    Nothing matching that in system.log. Probably in the rotated log from yesterday. But it was today that I was trying to readd the DynDNS and did a DHCP renew. I have also switched the DynDNS rule on and off today.

    Hostname and IP censored. DNS for removedfw.homeunix.com does not match 8.8.8.50.
  • Is the ddclient process running?
    ps ax -o pid,start,cmd|grep ddclient

    Does the config file exists: /etc/ddclient/ddclient.conf
  • fw:/tmp/systemlog # fgrep ddclient system-2010-04-15.log
    
    2010:04:15-09:37:02 fw ddclient[4495]: SUCCESS:  updating removedfw.homeunix.com: good: IP address set to 8.8.8.50

    Yesterday's log. 

    I get that it thinks that since 8.8.8.50 is still my external IP it doesn't think it needs to update. But after completely deleting the DynDNS rule and recreating it, and turning it on and off multiple times, you would expect it to try to update my ip again and not hold on to the cache from the deleted DynDNS rule.
  • Is the ddclient process running?
    ps ax -o pid,start,cmd|grep ddclient

    Does the config file exists: /etc/ddclient/ddclient.conf



    fw:/root # ps ax -o pid,start,cmd|grep ddclient
     8549 13:59:00 grep ddclient
    18265 10:33:48 ddclient - sleeping for 290 seconds
    fw:/root # ls -l /etc/ddclient/ddclient.conf
    -rw------- 1 root root 306 Apr 16 10:33 /etc/ddclient/ddclient.conf
    fw:/root #
  • Everything looks fine so far...

    Is the resolving IP address of removedfw.homeunix.com
    a LAN IP address or is it an former used public one?

    Are there multiple ip addresses configured on the interface or only one?
    ip addr show dev eth0
  • Astaro Beta Report
    --------------------------------
    Version: 7.902
    Type: BUG
    State: UNABLETODUPLICATE
    Reporter: physon
    Contributor: 
    MantisID: 
    Target version: 
    Fixed in version: 
    --------------------------------

  • Everything looks fine so far...

    Is the resolving IP address of removedfw.homeunix.com
    a LAN IP address or is it an former used public one?

    Former used.


    Are there multiple ip addresses configured on the interface or only one?
    ip addr show dev eth0

    Just one.

    I think the problem is that ddclient.cache isn't ever being cleared and there is no way to do it from the Astaro webgui. Deleting the rule does not delete the cache. If I wanted to fix this I could probably just delete that file from the shell and all would be well.
  • Well thats weird...

    Is it possible to get remote access to you system ?