In theory we should be able to make the change to hostname going forward,
instead of fqdn, as long as the first part of the fqdn was properly named
as the hostname, i.e. mymachine.example.com should treated the same as bare
mymachine in future backups. If they don't have proper naming on the
machine, the test should fail and the option --allow-source-mismatch should
be required.
In the case of home machines without an external domain, I'm inclined to
say that foo.localhost and foo.localhost6 should probably match as the same
machine. If they have the machine name as foo and the fqdn as
localhost.localdomain, then they will have to use --allow-source-mismatch
if they've already got a backup under localhost.localdomain.
Thoughts?
On Thu, Dec 6, 2012 at 5:53 PM, Michael Terry
<email address hidden>wrote:
> ** Summary changed:
>
> - duplicity gets wrong hostname when ipv6 is disabled
> + duplicity prefers fully-qualified-domain-name (fqdn) over hostname
>
> --
> 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
>
In theory we should be able to make the change to hostname going forward, example. com should treated the same as bare source- mismatch should
instead of fqdn, as long as the first part of the fqdn was properly named
as the hostname, i.e. mymachine.
mymachine in future backups. If they don't have proper naming on the
machine, the test should fail and the option --allow-
be required.
In the case of home machines without an external domain, I'm inclined to localdomain, then they will have to use --allow- source- mismatch localdomain.
say that foo.localhost and foo.localhost6 should probably match as the same
machine. If they have the machine name as foo and the fqdn as
localhost.
if they've already got a backup under localhost.
Thoughts?
On Thu, Dec 6, 2012 at 5:53 PM, Michael Terry
<email address hidden>wrote:
> ** Summary changed: -domain- name (fqdn) over hostname /bugs.launchpad .net/bugs/ 667885 -domain- name (fqdn) over hostname gethostname( ) instead. localdomain6 localdomain localhost localdomain6 localhost6 /bugs.launchpad .net/duplicity/ +bug/667885/ +subscriptions
>
> - duplicity gets wrong hostname when ipv6 is disabled
> + duplicity prefers fully-qualified
>
> --
> 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:/
>