Thanks! That clarifies this a lot!
Can you check if hostname also changes if it uses hostname -s to get the hostname? (The increment bug I guess?)
Yeah, because the hostname is what you configured during installation/setup. Same for Linux. It tries to get the FQDN, though, but I guess this is only appended if a Windows computer joins a domain.
Well, you name it … just did a " mac-exec-all ‘hostname -s’" for all our mac clients … just one example:
"computers in local network may connect to your computer under “mac-robert-2.local” -~$ 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
May be it is resolved by bonjour as described here: https://support.apple.com/en-us/HT201275
Just found out how you can get this name - like serial as mentioned above - on cmd line:
system_profiler SPSoftwareDataType | grep “Computer Name:”
Computer Name: mac-robert
Then, did
mac-exec-all ‘system_profiler SPSoftwareDataType | grep “Computer Name:”’
and got e.g. these:
Computer Name: mac-air2 (4)
Computer Name: mac-air3 (260)
which, btw, can even be changed by user - what a nightmare for administrators.
So, what do you think about using serial for Mac clients … at least as attribute to make sure you don’t do several backups for the same client?
Thank you very much for your great work.
So that shouldn’t change all the time, correct? So something like Computer Name-RANDOM would suffice? (UrBackup can store it into it’s database so the RANDOM part does not change)
yes, may be - if the user doesn’t change it himself. Something like
Computer Name([0-9 ()]*)
would be ok, as the (numbers) are not always there.
But you can’t have computers with same name and several domains then, right?
(We don’t have these - just thinking).
If I’d try adding a new client using hostname only - without domain name - atm UrBackup would add .local to it?
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.
well in IT we use virtualisation and thus cloning a lot and having to track errors because uuid have not been cleaned is a pain.
So, having a (optional) setting what will be used as client-identifier would be much appreciated.
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:
dscacheutil -flushcache
Restart your Mac.
Thank you very much, this seems to work for now at least for new clients.
Any idea what we should do with existing clients? BTW: found a mac client this morning with two urbackup jobs running at the same time - but with different names…
On a test macbook, deinstalled urbackup client, set the hostnames using scutil, rebooted, reinstalled again.
Backup is not working and in log I get:
ERROR: Signature error: Verification failed
Even deleted the client from server, removed+installed client software - no way.
Falko,
What i did with my existing clients, i archived their backups and removed the clients on the server
Then i uninstalled the client from the Mac and in a sudo terminal window ran locate urbackup
Removed anything that still existed from urbackup on that mac and then reinstalled after running the scutil commands.
This has worked for me on all of my clients so far.
Let me know if this helps at all.
Thanx, mostly this works, but sometimes we have to fully delete the backups, then rename or at least set the names the same. Deleting all backups is not so sane for this moment, but luckily we’ve backups of the backup thanx btrbk 
In client beta 2.2.2 anyways there seems changes to our problems (just hit the symlink problem, too):
Do not follow symlinks if the symlink target is excluded
Use computer name and serial id to construct default macOS client name
Proper hash send error failure handling in file server UrBackup Server 2.2.3 beta/Client 2.2.2 beta
Is it possible to try beta client 2.2.0 with server 2.1.19, or should we wait for release?
So, after upgrading to UrBackup Server to 2.2.7 all Macs are named now mac-[name]-SERIAL, which seems ok.
But as the clients are not renamed, “old” client backup has it’s btrfs snapshots under urbackup/mac-[name], whereas now all clients get new dir/snapshot urbackup/mac-[name]-SERIAL not respecting the btrfs snapshot from mac-[name], which leads to duplication of needed backup space.
Tried something like
btrfs subvol snapshot urbackup/mac-name/180220-1600 urbackup/mac-name-C02SERIAL/180220-1600
But, as urbackup server doesn’t know of that, it doesn’t use that as snapshot parent and creates new full file backup.
Any advise on that?
In my situation, i would just archive the old backups to an external drive and start fresh with the clients. However what has worked for me in the past was simply stopping the urbackup server and moving the old backups into the newly created directory. I am not sure if there are any implications with this on the new version but it has worked for me previously.
Or give the clients the old name. It won’t append the serial if you manually name a client.
It links the files with the new client (global file level dedup), so it won’t use much new space.
Ok, thank you very much for your answers. Just tried to mv mac-name to mac-name-serial and to my surprise even the btrfs snapshots were renamed - so I’ll see if that works.
IMHO for renaming the client I have to activate “different settings for this client” - so e.g. the (lots of) excludes from the group settings cannot be updated for all clients at a time. Or is there some inheritance of the settings possible?
Another problem: most of the clients did rename itself to “mac-name-serial”, but some not - though the client version had been updated automagically to 2.2.4. Anything I can do about that?
8th checkbox of settings->general->server (actually just click settings) is “Autoupdate clients:”
Yes, auto update clients is activated. Or do you mean I should disable/enable the setting?
For me it seems that only these clients, which were online when upgrading UrBackup server from 2.1.19 to 2.2.4, could get the serial from the Macs, but none of the clients which came online any later.
If you don’t want the clients to update their version automatically, uncheck that.
As for the client names, i don t know.
ok, I thought you’ve wrote about the rename problem 