After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 352828 - Allow setting zeroconf hostname depending on logged in user
Allow setting zeroconf hostname depending on logged in user
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2006-08-25 11:09 UTC by Bastien Nocera
Modified: 2008-11-01 03:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2006-08-25 11:09:25 UTC
Following http://avahi.org/ticket/46 getting fixed, it would be useful for NetworkManager to set a useful .local hostname when a person is logged in.

For example, if I were logged in to my Desktop, it would be called:
Bastien Nocera's Machine

Lennart explains how to use the API:
---8<---
This will be part of Avahi 0.6.13 which we will hopefully release this
week end.

I'd like to give you a few details about using this new function in NetworkManager:

There are two possible ways to call it: either directly with the D-Bus
libs, or with our libavahi-client. The former has the advantage of not
adding yet another dependency to NM. The latter has the advantage that
you can call avahi_strerror() to get a human readable error string,
and is of course easier to use. I'd suggest using la-c, however I can
understand if you prefer raw D-Bus.

If you do it directly via D-Bus everything that is required is the
equivalent of:

dbus-send  --system --dest=org.freedesktop.Avahi --type=method_call \
  --print-reply / org.freedesktop.Avahi.Server.SetHostName string:blabla

This will return an normal D-Bus error on failure. Failure reasons
might be: Avahi not running, an invalid host name was passed or the
the host name that should be set was the current host name
anyway. (Yes, that's an error condition for Avahi, because changing the
host name causes it to go through a lot of internal states which is
invalid if the name isn't really different from the old one due to
some reasons.)

The host name passed is a single label, no dots. i.e. "foobar", not
"foobar.local". 

if you want to access the server with libavahi-client, just do:

<snip>
simple_poll = avahi_simple_poll_new();
client = avahi_client_new(avahi_simple_poll_get(simple_poll), 0, NULL, NULL, &error);
avahi_client_set_host_name(client, "blabla");
avahi_client_free(client);
avahi_simple_poll_free(simple_poll);
</snip>

Of course, with a little bit more error checking! A more elaborate
example, with error checking, is:

http://avahi.org/browser/trunk/avahi-utils/avahi-set-host-name.c

If more than one machine is in a network hostnames might and *will*
conflict (especially when you choose the host name from the login
name). Right now Avahi just renames one of the hosts to "foobar-2" (if
the original name was "foobar") in such a case, which is what the spec
wants us to do. However, that name change is only logged to syslog, a
place where the user will probably never look. Hence I'd like to
suggest extending NM to show a small notification bubble if such a
host name conflict happens. For doing that NM needs to subscribe to
D-Bus signals of name org.freedesktop.Avahi.Server.StateChanged from
the / object of org.freedesktop.Avahi. That signal carries a single
integer variable
which describes the new state:

/** States of a server object */
typedef enum {
    AVAHI_SERVER_INVALID,          /**< Invalid state (initial) */
    AVAHI_SERVER_REGISTERING,      /**< Host RRs are being registered */
    AVAHI_SERVER_RUNNING,          /**< All host RRs have been established */
    AVAHI_SERVER_COLLISION,        /**< There is a collision with a host RR. All host RRs have been withdrawn. */
    AVAHI_SERVER_FAILURE           /**< Some fatal failure happened, the server is unable to proceed */
} AvahiServerState;

If the new state is AVAHI_SERVER_COLLISION (i.e. 3), the name
conflicted and a new one is chosen by the server. You may use the
GetHostName() method on the o.fd.A.Server interface to query the newly
chosen host name. (It just returns the host name as string and takes
no argument.)

If AVAHI_SERVER_COLLISION is entered you should just call
GetHostName() and print the new name in a notification bubble:
"Another computer on your network has been using the same machine name
as you. The local name has been changed to <b>%s</b>".

Should be fairly simple to do. It would be really cool if this would
be available in NM. I don't know any better place to put that
notification.

If you want to use libavahi-client for tracking name collisions you can
simply pass a callback function to avahi_client_new() which will be
called whenever the server (or client) state
changes. avahi_client_get_host_name() can be used to query the new
host name.

BTW, these are the docs for libavahi-client:

http://avahi.org/download/doxygen/

And these are the D-Bus introspection files for o.fd.A.Server:

http://avahi.org/download/Server.introspect.xml

Access to SetHostName is restricted to members of the group "netdev"
by default. 
---8<---
Comment 1 Dan Williams 2006-08-25 13:23:31 UTC
I'm not sure we can do this, though it's a great idea...

The reason NM doesn't honor DHCP-provided hostnames either is due to Xauth stupidity.  Your Xauth cookie is tagged to your hostname, so if NM or _anything_ else changes the hostname after you're logged in, for any reason, you can't start any X apps because your authentication cookie isn't correct.

Ok; for some reason this works now, but that might be because the hostname is 'localhost.localdomain', which in /etc/hosts is mapped to 127.0.0.1.  If you connect to a wired network, and get a hostname from there, then unplug and go to wireless and get a _different_ hostname that's not localhost.localdomain, I think you run into the problem.

Other hostname related stupidity:

[dcbw@localhost ~]$ sudo hostname foobar
[dcbw@localhost ~]$ gedit
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost.localdomain

(gedit:3968): GnomeUI-WARNING **: While connecting to session manager:
Could not open network socket.

What's that about?
Comment 2 Bastien Nocera 2006-08-25 13:33:14 UTC
Yeah, that's Xauth, and gnome-session's super-suckiness. You'll also notice the software mixing in ALSA (dsym and dmix) will stop working as well, and hang all your audio apps...

But the report is about changing the advertised .local name, not the real hostname of the machine. So when nss-mdns is installed and in use, the machine we're on would get a nice name, rather than the default, setup by Avahi.
Comment 3 Dan Williams 2006-08-25 13:46:24 UTC
Ahh, ok, that makes sense.  We can and should do this then.  I'd prefer the D-Bus method, and it should probably go somewhere in the system-specific backends.

"Access to SetHostName is restricted to members of the group "netdev"
by default."

That's _really_ odd, and it sounds a lot like Debian.  We don't do that, since we use pam_console instead.  We'll probably need to check their provided D-Bus .conf file to make sure that's not true for Fedora.
Comment 4 Dan Williams 2008-11-01 03:36:23 UTC
NM supports hostname setting now, but we should do it through davidz's xdg-hostname service which he's been thinking about in the past few weeks.  NM would be a provider of hostname information, but only one of a few.  xdg-hostname would consume the NM hostname and apply policy to it to derive the avahi machine name.