I think it may be time to reexamine this process. We do need some way to
warn/stop the naive user from mixing backups, but it appears that the
universe keeps making better and better processes to fool us.
On Tue, Sep 30, 2014 at 5:47 AM, Hadley T. Canine <email address hidden>
wrote:
> This bug still exists and still doesn't make any sense. After doing an
> upgrade on my server and restoring some of the old backups, I get the
> error:
>
> Fatal Error: Backup source host has changed.
> Current hostname: c-98-223-yy-zzz.hsd1.il.comcast.net
> Previous hostname: localhost.my.domain
>
> Neither of these hostnames make any sense. Replacing the call to
> socket.getfqdn() with one to socket.gethostname() would cause it to
> return the hostname that I've actually set on this machine, rather than
> making a terrible guess based on what my ISP's DHCP server assigned me
> that day.
>
> Though I'm guessing that since this bug dates all the way back to 2010,
> I shouldn't hold my breath on it.
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/667885
>
> Title:
> duplicity prefers fully-qualified-domain-name (fqdn) over hostname
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> Confirmed
> Status in “deja-dup” package in Fedora:
> New
>
> Bug description:
> Duplicity determines the machine's hostname in order to warn the user
> about unexpectedly backing up to the same location from two machines.
>
> However, it does this using socket.getfqdn(). It seems many users
> expect the value of socket.gethostname() instead.
>
> Now, I don't fully understand exactly the difference between the two
> calls, so I'm not necessarily advocating for this change. But
> gethostname() seems to be what most home users at least expect. Is
> the situation different for server users?
>
> If we made this change, we'd have to be careful to gracfully accept
> previous uses of getfqdn() that we wrote to manifests. I'd be willing
> to whip up a patch, Ken, if you think this is a sensible change.
>
> Examples:
> =========
> (This original report)
> Duplicity gives: localhost6.localdomain6
>
> $ cat /etc/hostname
> mybox
>
> $ cat /etc/hosts
> 192.168.1.5 mybox # Added by NetworkManager
> 127.0.0.1 localhost.localdomain localhost
> ::1 mybox localhost6.localdomain6 localhost6
> =========
> (Bug 1086068)
> Duplicity gives: localhost
>
> $ cat /etc/hostname
> computername
>
> $ cat /etc/hosts
> 127.0.0.1 localhost computername
> =========
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/667885/+subscriptions
>
Are you getting your hostname from DNS?
I think it may be time to reexamine this process. We do need some way to
warn/stop the naive user from mixing backups, but it appears that the
universe keeps making better and better processes to fool us.
On Tue, Sep 30, 2014 at 5:47 AM, Hadley T. Canine <email address hidden>
wrote:
> This bug still exists and still doesn't make any sense. After doing an yy-zzz. hsd1.il. comcast. net gethostname( ) would cause it to /bugs.launchpad .net/bugs/ 667885 -domain- name (fqdn) over hostname gethostname( ) instead. localdomain6 localdomain localhost localdomain6 localhost6 /bugs.launchpad .net/duplicity/ +bug/667885/ +subscriptions
> upgrade on my server and restoring some of the old backups, I get the
> error:
>
> Fatal Error: Backup source host has changed.
> Current hostname: c-98-223-
> Previous hostname: localhost.my.domain
>
> Neither of these hostnames make any sense. Replacing the call to
> socket.getfqdn() with one to socket.
> return the hostname that I've actually set on this machine, rather than
> making a terrible guess based on what my ISP's DHCP server assigned me
> that day.
>
> Though I'm guessing that since this bug dates all the way back to 2010,
> I shouldn't hold my breath on it.
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https:/
>
> Title:
> duplicity prefers fully-qualified
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> Confirmed
> Status in “deja-dup” package in Fedora:
> New
>
> Bug description:
> Duplicity determines the machine's hostname in order to warn the user
> about unexpectedly backing up to the same location from two machines.
>
> However, it does this using socket.getfqdn(). It seems many users
> expect the value of socket.
>
> Now, I don't fully understand exactly the difference between the two
> calls, so I'm not necessarily advocating for this change. But
> gethostname() seems to be what most home users at least expect. Is
> the situation different for server users?
>
> If we made this change, we'd have to be careful to gracfully accept
> previous uses of getfqdn() that we wrote to manifests. I'd be willing
> to whip up a patch, Ken, if you think this is a sensible change.
>
> Examples:
> =========
> (This original report)
> Duplicity gives: localhost6.
>
> $ cat /etc/hostname
> mybox
>
> $ cat /etc/hosts
> 192.168.1.5 mybox # Added by NetworkManager
> 127.0.0.1 localhost.
> ::1 mybox localhost6.
> =========
> (Bug 1086068)
> Duplicity gives: localhost
>
> $ cat /etc/hostname
> computername
>
> $ cat /etc/hosts
> 127.0.0.1 localhost computername
> =========
>
> To manage notifications about this bug go to:
> https:/
>