duplicity prefers fully-qualified-domain-name (fqdn) over hostname

Same problem here, on Fedora 13/dejadup 14.4, FWIW. (I'd test with a newer dejadup, but to get that I need to upgrade, which requires... doing a backup first :)

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 my setup at home, using the socket.getfqdn() function is definitely broken. Some of my machines have more than one name in the DNS. This is required because they run several servies that are available under different addresses.
Apparently, socket.getfqdn() will cycle through the list of hostnames, returning another one on each call(). socket.gethostname() works just fine for me.

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.

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
> 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
>

I experienced a similar problem recently, with my office network changing the domain name. I'd also very much support the solution of using gethostname(), which should be enough to warn users about machine mismatches.

I read through this, because I am rethinking Déjà Dups handling of this.

As far as I understand the only concern against changing to socket.gethostname() is, that this might not be backwards compatible. Which is indeed a problem. So how about accepting both names when doing a backup (or restore) and setting the value from socket.gethostname() for new backups?

This would enable a smooth transition process. It of curse introduces a theoretical risk, that the hostname of one machine is used in the socket.getfqdn() of another machine. Although that case seems to be purely academic to me.

What do you think about this?

Bumping this because I'm currently affected by it with Ubuntu 18.04.
My fqdn is different than my hostname, and the initial backup name was set to my hostname.

Now, every time a backup is scheduled, it checks first. This is very inconvenient and also makes my backup times inconsistent.

Related to this bug: https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1268182

For me, I would be fine with using either fqdn or hostname, so long as I could override the warning somehow to make sure my backups remain automated.

More info: `socket.gethostname()` queries the DNS system as all right-thinking applications should. `socket.getfqdn()`, however, queries the /etc/hosts file. Which may be useful sometimes, but...

Somehow when my /etc/hosts file contains:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

it looks _somewhere_ else and gets a hostname that has nothing to do with my machine.

A workaround:

Add a line like the following to /etc/hosts:

127.0.1.1 <your host name here>

I'm not sure what other effects that might have, but it _seems_ to be safe. Caveat user.

The bizarre socket.getfqdn behavior is detailed in this python bug: https://bugs.python.org/issue5004

The BorgBackup maintainer at the end of the thread ended up replacing their use of it - which seems similar to Duplicity's - with this: https://github.com/borgbackup/borg/pull/3484/commits/9b0d0f3127289fc3bbe620e8adce8038ed594e9f#diff-4b53f84e19a3bb376bf2202371ed269aR188

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 status confirmed
 importance medium
 done
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEExwf+p6/3mDvUSsaGH1G0ZBEHM/EFAmBmHTAACgkQH1G0ZBEH
M/EiEgf/VaWnI3EAz/pXDwlk03h5GiA/pL8A0HZLVH5hEUDX1owYAl57+dnPSawC
C8ICwuB1E0RdKJhOF9l089kLXPD415W6UghEVvPMhBldc7gWnFhlPTJ4ZywY9ril
SzeXItYaAT6+owFE8hIkoejvZxtsA6igMgBy8jKbz+9hJzeUjoWg5fcY7fubT6DC
EHGReMMYPz5Sj93iTJ25cDs0nstBEoM9PqjicILKCdWhlcJKk6lAoLtXzUq9cgqq
oMPQGmRGrfbor4VMMwzjr3G4ntP/cqh1ZTJ8HCGuSKb4JYC57jTQpy0QkPNkiLwP
1IPx9Amu9iX/W2yMVxkyL0hFnZ7o1w==
=t+7n
-----END PGP SIGNATURE-----