So i just added my first Mac to urbackup. I only see one instance of urbackup started on the client machine, however it seems to be reporting to the backup server twice… Once as host-blahblah and the other one as users-imac.local
I tried removing 1 and it comes back the morning after the server cleanup occurs.
I noticed something similar, but I don’t know if my situation is identical to yours.
I add a new client, and it very quickly shows up on the server with client name = the-hostname-of-the-client. Then I go into the client and change its name to something shorter. Soon, this new client name shows up on the server, so I have two names for the same client displaying on the server. Next, I start a full file backup from the client end, and shortly the progress of the backup will display on the server. This progress indicator is showing for the second client name, the one I manually edited. Next, on the server, from the Status screen, I delete the extra client name (the first one, that was the hostname). It disappears from the Status screen, but is still present on some of the other screens. Then, on the UrBackup server command line (Linux), I run “urbackupsrv remove-unknown”. This last command is what gets rid of the extra client name (permanently).
These dual client names show up for me with both Linux and Windows clients. It appears that when you are configuring the client end, the server is in such a hurry to discover it, that it picks up a client name that you don’t want (because you haven’t gotten that configuration part set yet). But then the server is not smart enough to understand that you changed the client name, so it just adds a second client name for the same client. I don’t have any Macs to test with, but I imagine the behavior would be the same there. My UrBackup server is Linux, and the cleanup command there is “urbackupsrv remove-unknown”, but if your UrBackup server is Windows, I believe the cleanup command is “remove_unknown.bat”.
Except we are not having the same issue. I did not change the hostname at all and it discovered it twice multiple times. One is just called host-ip-address and the other one is user imac.local. No one changed the hostname at any time it is almost as if the machine has two hostnames for some reason.
Yes, that would be awesome and IMHO is the only way to be sure, that the same Mac won’t be backed up twice.
Don’t know if this is possible, but may be you use the serial internally and user can give a name/dns name/ip to the Mac to find it on local network, but then should check every time if the serial remains the same, or if the Mac with this serial is seen using other IP/dns name …
I’ll try to explain a bit more. Btw, we have nearly same problems as xylems, that’s why I’ve responded to this thread.
We use iMac/Macbooks in a heterogenous network, so no os x server, just bind/dns. Now, we clearly see certain situations:
macbook has different connections - one onboard, other one when connected to Mac Thunderbolt Display, third one maybe on WLAN, gets it’s IP per connection/Mac Address from dhcp server, normally static IP, with staticaly assigned hostname.domain.tld by dns server. So, user docks the macbook off from his display, goes to another room may be, now docking ethernet cable to onboard or network adapter. Means, IP and/or hostname changes per reverse dns. Next time the macbook is booted, it get’s it’s name from the reverse dns hostname - cause of other network connection. This is really annoying, for sure, but this is what we see.
on macbook, go to settings -> shares. you see the hostname of the iMac/Macbook like it is set by the admin. If you open the terminal, you see the name from ip/reverse dns - user@otherhostname! Sure you’d try to set these names in dns and local the same - but if ip changes, the local hostname changes, too, through reverse dns lookup (or other, apple specific mdns mechanisms - I don’t know).
sometimes (this bug seems to exist for several os releases now) this settings -> shares hostname counts up like “mymacbook (1)”, “mymacbook (2)”,… as the os claims to “see” itself yet existing same, duplicate name in the network when switching from one place to another - and to prevent duplicate names, counting up.
So, all this is not reliable. Now, what do we see in regard to UrBackup:
when installing urbackup client onto a new mac(book), giving the UrBackup server the name of client as mac-thunder.domain.tld. Sometimes it is found quickly, starting backup. Next time UrBackup sees the same client as “mac-thunder.local”, starting another full backup - we clearly see this on btrfs snapshots, there are two backups including snapshots with same names - some time later, in the web gui list, the “mac-thunder.domain.tld” is stated with “backup ok”, thereas “mac-thunder.local” has no backup.
Now - you mention Windows clients. No matter what you do - name of client is set in computer settings, and does not change, regardless of what has been set by dns. And, to
be clear, you have no network connections on Windows displays - but e.g. docking stations - but this doesn’t change anything regarding the client’s name.
So my conclusion was: only consistent attribute of the mac is it’s serial number, and so the idea is: why can’t you use it for checking if it is the same machine - or even as name of the entry in UrBackup, as you like - may be as optional behaviour. For me, it’d be necessary to have consistent backup of clients, even if they change their ip/hostname/whatever - and to use UrBackup for Mac clients at all.
Well, you name it … just did a " mac-exec-all ‘hostname -s’" for all our mac clients … just one example:
hostname -s output: macdisp-002
“Freigaben”/“Shares” shows: mac-robert
and in small underneath "computers in local network may connect to your computer under “mac-robert-2.local” -
which one is true, even from a linux box I can do:
~$ ping mac-robert-2.local
PING mac-robert-2.local (192.168.XX.YY) 56(84) bytes of data.
64 bytes from macdisp-002.domain.tld (192.168.XX.YY): icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from macdisp-002.domain.tld (192.168.XX.YY): icmp_seq=2 ttl=64 time=0.537 ms
The host name (hostname -s) does change based on DHCP.
If you have Bonjour Sleep Proxies on the network that misbehave you could also have your computer name change (adding (1)) etc. so querying the system isn’t foolproof. it’s also how Mac admin tools give names to multiple hosts, simply adding numbers.
Ideally the hostname taken on installation would be stored somewhere (e.g. In a database) or each client would get a truly unique identifier (UUID) in URBackup, you can still pass hostname as purely informational but hostname collisions do happen for all networks, I think URBackup should be able to handle hostname collisions and changes like that.
About the other ideas: serial numbers, MAC addresses etc all change - e.g. Virtual systems may pass the serial number of their hypervisor or moving a hard drive to another computer. It drives me absolutely nuts that even large companies like Mathworks doesn’t understand and binds things like licenses to the first MAC address it encounters and hopes the network ordering never changes.
Well, serial IMHO won’t change on physical hardware at least - but something like an uuid or client certificate, generated on first backup, sounds like good idea for me. Server has certificate too - so client cert is also good for security.
I have found that by doing the following and setting all the hostnames to the same exact name makes it so that it only shows up once. You have to do this prior to installing urbackup.
Open a terminal.
Type the following command to change the primary hostname of your Mac:
This is your fully qualified hostname, for example myMac.domain.com
sudo scutil --set HostName
Type the following command to change the Bonjour hostname of your Mac:
This is the name usable on the local network, for example myMac.local.
sudo scutil --set LocalHostName
Optional: If you also want to change the computer name, type the following command:
This is the user-friendly computer name you see in Finder, for example myMac.
sudo scutil --set ComputerName
Flush the DNS cache by typing:
Restart your Mac.