Hi,
May I suggest the Subject in the email sent reads the Machine name instead of the Machine id? That would help when searching/filtering emails for a given client.
It shouldn’t be a big deal as the machine name is in the body of the mail.
This machine id stuff is pretty useless in mail reports, as far as I’m concerned.
Maybe below can explain and help for now:
If you choose option path, Settings Default options can put it in all the jobs on that system:
Thank you. I knew it was possible to alter the machine-id to reflect the machine-name in the Advanced Option. Which is odd, isn’t it?
You would agree that this default email template already knows the machine-name as per the body text in the mail (unless it is an other variable). So, as I suggested it would be nice that this default email template be modified to reflect the machine-name in the Subject instead of the machine-id.
True! I have updated it, and the change will hopefully be deployed today.
You can certainly use the machine-id == machine-name approach.
For the Duplicati console, note that it uses the machine-id as a unique identifier, so if you change it, it will appear as a new machine.
The logic for the Duplicati console is that you can keep the randomly generated id, and then set a display name for the machine. The display name can be changed without any other effects.
Yes, this is what I changed it to do. If there is no defined machine-name, it will show the machine-id instead.
@kenkendk
Thank you.
As per one other thread I raised on machine names on Win and macOS hosts (MachineName of Windows hosts), your variable machine-name is actually built upon the NetBIOS name which is problematic to my perspective. Although I understand we can tweak it on the Host settings, unfortunatley this has no effect on the Console, even after unregistering the host or deleting the machine from the Console and re-register.
For MacOS it is handled quite strangely, often taking names of nearby machines etc.
This related to the logic mentioned in the MachineName thread you linked to. The logic is here to keep the name, in case the user has changed it.
The reason that you can supply a name in the client is that you can use other solutions for monitoring than the console. If you set a name here, it will be picked up on the first use, and then “sticks” in the console.
I will update the ticket on the BackupName being sticky to also include the machine name.
@kenkendk
Thank you.
IMHO, this machine-name variable in Duplicati should not be alterable by the user in the WebUI or by CLI or from within the Console webapp potentially. As it is a parameter used in many places by Duplicati (support displays and reports), it should stay sticked to the real Computer Name either the Full name or LocalHostName (for macOS). If at some point the user decides to change the name of the Computer from an OS perspective, the Console webapp should be able to reflect that change by itself, relying on the machine-id, being the non-user-friendly reference of a given computer.
I’d tend to say the same for the machine-id. It shouldn’t be alterable. To me it must remain unique for a given machine, as it seems to be a core parameter for Duplicati.
The machine-id is intended as a unique identifier for the machine and should (generally) not change.
But, Duplicati is used in many different setups, and only one of them is with the Console, and for that reason we keep many of the values user-configurable, even if it does not make sense to change them when using Duplicati with the Console.
The machine name (in the Console) is just a label, so it only has visual effects if you rename a machine. If you customize the name in the Console, the logic is that it stays that way, so any changes on the client machine has no effect.
I think that since the user (in many cases) is the owner of the machine, they should be allowed to change the name as they see fit.
@kenkendk Has the fix been implemented? Because the subject title in the mail reports still include the machine-id instead of the machine-name.
The fix has not been deployed to the public setup yet, I will write back here once the deployment is done.
@macSOSfr That fix is now deployed.
@kenkendk
Thank you!