Re: NetworkManager-list Digest, Vol 49, Issue 2

Dan Williams wrote:
On Wed, 2008-10-01 at 16:14 -0700, Howard Chu wrote:
Message: 5
Date: Wed, 1 Oct 2008 23:58:22 +0200
From: Alexander Sack<asac jwsdot com>
Subject: [PATCH] hostname support for ifupdown plugin + allow
	read-only	hostname system provider + move nm_inotify_helper to plugin
	independent place (system-settings/src/)
To: networkmanager-list gnome org
Message-ID:<20081001215822 GC26713 jwsdot com>
Content-Type: text/plain; charset="us-ascii"

Implement system hostname support for debian/ubuntu

Fix "only system-setting plugins with NM_SYSTEM_CONFIG_INTERFACE_CAP_MODIFY_HOSTNAME
are considered a valid hostname provider"

Make nm-inotify-helper from ifcfg-fedora plugin usable
for other plugins too
Is any of that really necessary? Any tool that rewrites /etc/hostname is also
going to already call sethostname(); shouldn't you only need to call
gethostname() to get NM in sync? Why go thru the hassle of opening and reading
a file and calling sethostname() to tell the kernel what it already knows?

It's a matter of persistent storage... when you reboot you'd probably
like to have the hostname come back as what you set it before, and that
means you have to store the persistent hostname somewhere on the

Right, and /etc/init.d takes care of reading it on boot, so NM doesn't need to worry about restoring the persisted state. Moreover, NM gets started too late in the boot process for it to be useful for this purpose.

But it's just good programming to ensure that when that file changes,
updates are recognized, because whatever wrote that file out doesn't
_have_ to call sethostname(2).

Yes, but it's whatever wrote that file's responsibility to worry about it. After all, not everyone out there will even be running NetworkManager in the first place. Any admin tool that mucks around here can't assume that some other process will cleanup after it. Any sysadmin using vi has to know what they're doing.
  -- Howard Chu
  CTO, Symas Corp. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]