Got it.

I figured I was responsible for writing the python script, so that's what I'm doing (using sbin/vyatta_update_hosts.pl as reference) :)

I'll look into /opt/vyatta/share/vyatta-cfg/templates/system/static-host-mapping/host-name/node.def and will not add the 127.0.0.1 /etc/hosts entry.

I'll update the PR once I have something that looks like it's working :)

Regarding Phabricator vs Github PR, the connection would be to update the PR title to reference this task number ?

EDIT:
Ok, I think what you meant is to not update /etc/hosts from this script, so I won't do that :)

I'll update /etc/mailname though, seems ok to do it.

Please make sure to read the guideline: http://blog.vyos.net/vyos-2-dot-0-development-digest-number-5-doing-1-dot-2-x-and-2-dot-0-development-in-parallel
You can use the cron script as an example, too.

The PR and the commit descriptions should reference the task (like "Add new style scripts and definitions for system host-name (fixes T574)".

As of updating /etc/hosts, yes, I think the ability to resolve 127.0.0.1 to $hostname is hardly valuable enough to try to reconcile two scripts that want to write to the same file. If we ever want to implement non-disruptive rollback, we'd better make sure that every script is responsible for one file and that no in-place file modification is done by any of them.

Well, I added an initial version of the script.

I don't usually code in python, so I have to learn patterns (write lines to a file, use/check a regexp, etc) :)

A couple of thoughts:

• I'm not sure where to default the hostname to 'vyos'. Since verify prevents an empty hostname, my thinking is that generate or apply will never get an empty hostname that they would need to default to 'vyos'
• How can I test that this works ?
• How to debug ? With 'println' or similar ?

Turns out updating the hosts entry is more important than I thought: if it's missing, sudo constantly complains that it cannot resolve the hostname. While it appears to have no ill effect, it's still quite a nuisance.