Bug 3782 - networkmanager changes hostname upon connect but does not notify s2u (resulting in failure to start any GUI applications under the running X-session)
Summary: networkmanager changes hostname upon connect but does not notify s2u (resulti...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard: MGA2TOO
Keywords: NEEDINFO
: 5230 5962 6792 7300 (view as bug list)
Depends on:
Blocks: 7557
  Show dependency treegraph
 
Reported: 2011-12-16 14:05 CET by Christian Lohmaier
Modified: 2015-09-22 19:43 CEST (History)
19 users (show)

See Also:
Source RPM: networkmanager
CVE:
Status comment:


Attachments

Description Christian Lohmaier 2011-12-16 14:05:00 CET
Description of problem:
Trying to lauch the mageia control center or other drak-tools just prints
"no protocol specified This programm cannot be run in console mode"
(although when you start drakconf as root, it runs find in console mode)

I suspect a missing dependency or something.

The check runs (in check_for_xserver in libDrakX/common.pm)
$::xtest = xf86misc::main::Xtest($ENV{DISPLAY});

and that is a DynaLoader the Xtest function apparently is in libDrakX/auto/xf86misc/main/main.so but apparently it fails...

critical - not being able to run the distro's configuration tools (and that includes rpmdrake) is a stopper.
Comment 1 Thierry Vignaud 2011-12-16 14:33:07 CET
How you try running them?
Do you try running from a terminal after sudo su or sg like that?

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud
Component: Installer => RPM Packages
Severity: critical => normal

Comment 2 Christian Lohmaier 2011-12-16 14:42:47 CET
from the menu / overlay-thingie, or from gnome-terminal, as live user or switched to root user using "su" - apart from drakconf that then starts in console mode, the message is the same for the other tools)

Keywords: NEEDINFO => (none)

Comment 3 Christian Lohmaier 2011-12-16 23:19:12 CET
You reduced severity - while I don't really agree with that, it seems OK, as it indeed requires more investigation regarding the exact circumstances.

Rebooted into Mageia alpha2 (GNOME live iso), and at the beginning the tools did work. After having setup network connection, browsing a little, tried again and the tools won't launch.

Logging out and back in (resets keyboard layout to en-US btw) makes the tools work again.

It is unclear to me what triggers this (at least not yet) - would be great if you could ping QA folks to have a look at this, i.e. to check whether they can start drakconf or laucn the network-configuration via netapplet or launch rpmdrake also after using the system for a while.
Comment 4 Thierry Vignaud 2011-12-16 23:24:06 CET
It's very clear: the odds're high you changed hostname.
I guess quite a lot of other tools then fail too...
Comment 5 Christian Lohmaier 2011-12-16 23:36:14 CET
well, I myself did not type in any hostname - if hostname was changed, then not by me, but as a sideeffect of connecting to (wireless) network - but I'll double check.
Comment 6 Christian Lohmaier 2011-12-17 00:57:45 CET
(oh, and obviously: just changing the hostname should not have such a massive effect on the distro's configuration tools - so if it turns out to be hostname related, the issue is just as valid as any other reason)
Comment 7 Thierry Vignaud 2011-12-17 12:29:00 CET
Changing the hostname has an effect on _all_ graphic tools
Comment 8 Christian Lohmaier 2011-12-17 20:38:17 CET
So indeed it is a changed hostname that makes the tools fail because there is no matching xauthority entry anymore.

So two (and a half) solutions
* network-manager must not change hostname
or
* when netowork-manager changes hostname, it must add the new hostname
  xauth add "$(hostname)/unix:0" MIT-MAGIC-COOKIE-1 $COOKIEOF_OLD_HOSTNAME
or
* draktools should not just print "no protocol specified, command cannot be run in console mode", but suggest "the hostname changed, please log out and back in".
if (xauth list |grep $(hostname) >/dev/null 2>&1)

Summary: Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) => Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname)

Comment 9 Thierry Vignaud 2011-12-18 00:11:17 CET
Impossible: when you run any of our tools, they just see the new hostname, they don't know whether it has changed or not. Like other tools too.
Thierry Vignaud 2011-12-18 00:11:24 CET

Source RPM: drakxtools => (none)

Thierry Vignaud 2011-12-18 00:12:19 CET

Source RPM: (none) => network-manager

Comment 10 Christian Lohmaier 2011-12-18 00:47:02 CET
not impossible, only impossible when you don't bother to check whether current xauth list contains the new hostname.

And even if you cannot tell whether the hostname was changed: adding a hint "this could also be because the hostname was changed since you last logged in" is nowhere near the impossible.
Comment 11 Thierry Vignaud 2011-12-18 01:46:35 CET
Sure it's possible to patch thousands of graphical applications for that...
Comment 12 Christian Lohmaier 2011-12-18 02:02:04 CET
This is a stupid response, as this is about Mageias drakx-based tools.

All other GUI applications I tried did not have any problems launching despite the hostname change. 

You need to patch one single location for that.
Comment 13 Thierry Vignaud 2011-12-18 03:37:56 CET
Before saying other people are stupid, you should check running other programs as root too...
Comment 14 Christian Lohmaier 2011-12-18 03:42:49 CET
before making ridiculous statements like "it's possible to patch thousands of graphical applications for that.." you should think about how many applications are affected by a hostname change. 

So: please name a few that the regular desktop-user will try to launch after installing Mageia / when playing around with a live iso. (and that are not drak-based)

(and note that I called that response stupid, not you)
Comment 15 Frank Griffin 2011-12-18 13:54:46 CET
What does your hostname change from, and what does it change to ?  And do you know where these values come from , e.g. /etc/hosts, DHCP, default set in drakconnect ?

CC: (none) => ftg

Manuel Hiebel 2011-12-18 15:43:18 CET

Summary: Fails to start drak-tools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname) => Fails to start drakxtools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname)

Comment 16 Christian Lohmaier 2011-12-21 15:59:22 CET
from the live-ISO's default "localhost" / no hostname to one from DHCP (and wrongly so to a fqdn) linux.fritz.box or something like that. And after disconnecting to localhost.localdomain

( not being able to configure the dhcp vs static ip settings is bug #3798 )
( being forced to use nm and not net-applet is bug #3799 - being forced to use network manager is a big step backwards regarding usability - for me at least)

But it doesn't really matter where the value comes from - why does nm change the hostname in the first place?
Comment 17 Marja Van Waes 2012-02-11 13:41:20 CET
removed the dash in the package name

no maintainer, so cc'ing the two persons who committed networkmanager most often

CC: (none) => balcaen.john, dmorganec, marja11
Source RPM: network-manager => networkmanager

Comment 18 Marja Van Waes 2012-03-29 21:29:43 CEST
@ Christian

Did you run into this issue again with Mga2b2?

Keywords: (none) => NEEDINFO

Comment 19 Christian Lohmaier 2012-03-29 21:41:10 CEST
If there was a live iso, I could test, but there has not been a new live-iso since reporting this bug.
Comment 20 Marja Van Waes 2012-03-30 08:00:04 CEST
(In reply to comment #19)
> If there was a live iso, I could test, but there has not been a new live-iso
> since reporting this bug.

I missed that this was about the Live CD, sorry.

*No ping before new LiveCD*

Whiteboard: (none) => LiveCD

Comment 21 Christian Lohmaier 2012-03-30 14:20:01 CEST
it mostly applies to liveCD, yes. But if the installer doesn't explicitly set a hostname, it would also apply to an installed copy.
Comment 22 Frank Griffin 2012-03-30 14:40:04 CEST
(In reply to comment #16)
> from the live-ISO's default "localhost" / no hostname to one from DHCP (and
> wrongly so to a fqdn) linux.fritz.box or something like that. And after
> disconnecting to localhost.localdomain
> 
> ( not being able to configure the dhcp vs static ip settings is bug #3798 )
> ( being forced to use nm and not net-applet is bug #3799 - being forced to use
> network manager is a big step backwards regarding usability - for me at least)
> 
> But it doesn't really matter where the value comes from - why does nm change
> the hostname in the first place?

If you have checked "Accept hostname from DHCP" in drakconnect (NEEDHOSTNAME=yes in ifcfg-xxx) then bringing up that interface is *supposed* to set the hostname.  Are you using this option ?

If you are not, and you really want the hostname to stay localhost, then it is a bug on the part of whatever is changing it.  If you are using the option, and you really want the hostname returned by DHCP as your hostname, then the problem is a longstanding complaint of mine that the DM is allowed to come up before the network is connected, or equivalently that network-up (especially wireless) is started too late in the boot sequence to be finished by the time the DM starts.
Comment 23 Christian Lohmaier 2012-04-01 23:53:52 CEST
> If you have checked "Accept hostname from DHCP" in drakconnect
> (NEEDHOSTNAME=yes in ifcfg-xxx) then bringing up that interface is *supposed*
> to set the hostname.  Are you using this option ?

If this option is set, then it is the default, as it is impossible to configure the connection in the Live iso (see bug 3798)

But even when the option is active, it should come with a warning/notification that the current desktop-session will be rendered unusable for big parts, as administrative programs cannot be started anymore.

This is a "dangerous" option and thus should not be default for wireless connections.
Comment 24 Frank Griffin 2012-04-02 01:00:30 CEST
>This is a "dangerous" option and thus should not be default for wireless
connections.

It isn't the default, at least in a standard install or a standard configuration of an interface via drakconnect.

Is the option set in your ifcfg or not ?
Comment 25 Marja Van Waes 2012-04-19 15:41:36 CEST
@ Christian

Beta 3 CD's are released, please test whether this bug is still valid

http://blog.mageia.org/en/2012/04/18/last-run-for-mageia-2-test-beta-3/
Comment 26 Marja Van Waes 2012-05-06 16:45:55 CEST
@ Christian

Could you please reply to the previous question? If you won't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
Comment 27 Christian Lohmaier 2012-05-06 22:19:12 CEST
It is still valid... It still doesn't offer a way to configure the network *before* connecting - so how would a user even request or disable a option to use a hostname provided by a remote machine? (Network manager doesn't even expose such a configuration setting)

Again I'm booting straight into the live iso, fire up netapplet to change the CRDA domain (that network manager stupidly doesn't allow to change/set and without no connection is possible at all), then use network-manager to connect.

network-manager did fix the password-prompt so it is no longer modal and one can open a file with the password and use copy'n'paste more easily, but that's the only change I can observe.

before: localhost, while connected: linux.fritz.box 

# cat /etc/sysconfig/network-scripts/ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

# grep -i need /etc/sysconfig/network-scripts/ifcfg-*
# 

# cat /etc/sysconfig/network-scripts/ifcfg-ESSID
ESSID="ESSID"
MODE=Managed
KEY_MGMT=WPA-PSK
TYPE=Wireless
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=ESSID
UUID=095affa7-677d-4390-bd7d-c9aa0d04a3b8
ONBOOT=yes
HWADDR=00:22:5F:62:81:80
WPA_ALLOW_WPA=yes
WPA_ALLOW_WPA2=yes
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_PRIVACY=rfc3041
#

So not requested by me by clicking any button, not requested by the config files either.
And even if it was: When the hostname is changed and has such a big impact, there *needs* to be a warning/information dialog that one needs to relogin to complete the change and not run into "random" problems.
Comment 28 Marja Van Waes 2012-05-07 08:11:55 CEST
@ Christian

Thanks :)

cc'ing docteam. Although we won't write documentation for networkmanager, we'll consider adding a few lines about this issue in the help for drakxtools and/or drakx-net (still to be written).


@ Thierry

Do you have a suggestion as to what to write? I don't use networkmanager and have no experience with this issue, it is possible that I do not fully comprehend it.

Keywords: NEEDINFO => (none)
CC: (none) => doc-bugs

Thierry Vignaud 2012-05-07 10:06:23 CEST

CC: (none) => mageia

Comment 29 Remco Rijnders 2012-05-15 07:12:52 CEST
Problem is still present with RC (ran into it myself). Reworded summary to point to the root cause of this issue.

Summary: Fails to start drakxtools (like Mageia Control Center, rpmdrake, etc) in alpha2 (GNOME) (network-manager changes hostname) => networkmanager changes hostname upon connect (resulting in failure to start any GUI applications under the running X-session)
Whiteboard: LiveCD => (none)
Severity: normal => major

Remco Rijnders 2012-05-15 07:13:17 CEST

CC: (none) => remco

Comment 30 Olivier Blin 2012-05-23 01:01:59 CEST
This should be handled by the s2u daemon.
Though, it seems to be broken when using NetworkManager.
When using ifup/ifdown, s2u was notified by /etc/sysconfig/network-scripts/hostname.d/s2u

NetworkManager should call this script as well when modifying the hostname.

CC: (none) => mageia

Comment 31 Marja Van Waes 2012-05-26 13:05:58 CEST
Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 32 Christian Lohmaier 2012-06-15 14:43:22 CEST
it is still valid for Mageia 2. The final iso has just the same problem as the previous ones.

No matter whether you use wired or wireless network: When using DHCP the hostname is changed, rendering the system useless for administrative stuff (at least for those users who don't know this issue and just wonder why nothing happens when they try to launch control-center or other tools)
Marja Van Waes 2012-06-15 15:12:31 CEST

Keywords: NEEDINFO => (none)
Whiteboard: (none) => MGA2TOO

Comment 33 Manuel Hiebel 2012-06-25 04:53:44 CEST
*** Bug 5230 has been marked as a duplicate of this bug. ***

CC: (none) => n54

Comment 34 Manuel Hiebel 2012-06-26 22:46:42 CEST
*** Bug 6362 has been marked as a duplicate of this bug. ***

CC: (none) => tac

Olivier Blin 2012-06-30 13:12:33 CEST

Summary: networkmanager changes hostname upon connect (resulting in failure to start any GUI applications under the running X-session) => networkmanager changes hostname upon connect but does not notify s2u (resulting in failure to start any GUI applications under the running X-session)

Comment 35 Kamil Rytarowski 2012-06-30 20:18:46 CEST
Still valid
Comment 36 Manuel Hiebel 2012-07-02 23:24:57 CEST
any work around possible ?
Philippe Leblanc 2012-07-10 04:01:14 CEST

CC: (none) => philippe.l

Comment 37 Manuel Hiebel 2012-07-13 16:10:04 CEST
*** Bug 5962 has been marked as a duplicate of this bug. ***

CC: (none) => pip

Comment 38 Manuel Hiebel 2012-07-19 00:12:03 CEST
*** Bug 6792 has been marked as a duplicate of this bug. ***

CC: (none) => yves.brungard_mageia

Comment 39 John Balcaen 2012-07-20 11:35:03 CEST
For the record a link from pterjan : http://old.nabble.com/Re%3A-X-session-and-hostname-changing-policy-p28917407.html
So we can « workaround » eventually this problem by not using hostname for X authentification.
Comment 40 Doug Laidlaw 2012-09-01 04:14:25 CEST
Strangely, I wasn't seeing this bug until a recent reinstall.  Kwrite wouldn't start with sudo because of dbus issues, so I used mousepad.  Now both Kwrite and mousepad give me "no protocol specified."  I haven't tried kdesu, suggested to somebody who insisted on being root.

CC: (none) => laidlaws

Manuel Hiebel 2012-09-08 09:58:25 CEST

Priority: Normal => release_blocker

Comment 41 Manuel Hiebel 2012-09-08 09:58:30 CEST
*** Bug 7300 has been marked as a duplicate of this bug. ***

CC: (none) => info

Manuel Hiebel 2012-09-23 21:29:53 CEST

Blocks: (none) => 7557

Comment 42 Frank Griffin 2012-10-29 13:24:08 CET
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID.

For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect.  GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there.  

You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface".

Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
Comment 43 Valery Pipin 2012-10-29 13:34:41 CET
I can confirm that the NM related things are gone away recently (mageia3).
The upower service has to be restarted after resume still. I hear some 'ticks' inside laptop otherwise. Don't know what device produces it.  They disappear after I restart upower service manually
Comment 44 Frank Griffin 2012-10-29 14:38:15 CET
(In reply to comment #42)

n/a here
Comment 45 Valery Pipin 2012-10-29 14:41:39 CET
(In reply to comment #44)
> (In reply to comment #42)
> 
> n/a here
Sorry I meant
https://bugs.mageia.org/show_bug.cgi?id=7551
Comment 46 Frank Griffin 2012-10-29 14:49:07 CET
Re: comment@27 :

The interesting thing here is that NEEDHOSTNAME isn't set explicitly at all.

If NM is generating the ifcfg-ESSID (I assume it is, since it contains way more than the ifcfg's I see from drakconnect), *and* if dhclient/dhcpcd defaults to requesting hostname, then that would explain the behavior.

drakconnect defaults to explicitly setting NEEDHOSTNAME=NO, so for consistency, either NM should do this as well, if possible, or dhclient/dhcpcd should change its default behavior on this for MGA.

Another point is that "linux.fritz.box" is not the usual DHCP hostname artificially created by the client, which means that someone has configured dhcpd to return a meaningful hostname.
Comment 47 Remco Rijnders 2012-11-12 15:35:36 CET
Hi,

I've adjusted our xinitrc package, implementing the solution as proposed in comment 39 . I believe this should fix this issue.

Once the new live cd's are available (I fear this was just too late to go into Alpha 3), I appreciate if people experiencing this problem can test it.
Comment 48 Olivier Blin 2012-11-12 16:34:11 CET
While this should work and be ok, it does not look like the proper fix in
our architecture, see comment 30 and the bug title...

Ideally, s2u should edit the X11 cookie when the hostname changes.
It already has code to do this, it should just be hooked into some NM event (directly in s2u) or hook script
(if some hostname.d scripts are run by NM on hostname change).
Comment 49 Remco Rijnders 2012-11-12 18:14:22 CET
@blino: I see what you are saying. I'll have a further look at it and see if I can get this changed in networkmanager. Still, I think the change as I made it is good to keep as:
1) It makes the symptoms of the problem go away, resulting in a usable live-CD etc. for affected configurations;
2) It will also allow one to change the hostname manually or through other means than networkmanager while still allowing one to launch new X11 applications.

Let me know if you disagree.
Andras Salamon 2012-12-21 17:14:18 CET

CC: (none) => andras.salamon

Comment 50 Anne Nicolas 2013-02-03 19:35:31 CET
can we have a status on this bug? Is it still valid ?

CC: (none) => ennael1

Comment 51 Doug Laidlaw 2013-02-03 22:35:36 CET
My issue (Comment 40) was with trying to start Kwrite from a terminal as root.  On a test, I can now start "sudo kwrite,"  but I can't su to root then start kwrite; it crashes. I am not sure if that is related to the principal bug at all.
Comment 52 Manuel Hiebel 2013-02-03 23:06:58 CET
no, it's completly unrelated and also not a bug (you need complete environnement with su -)

Keywords: (none) => NEEDINFO
Priority: release_blocker => High

Comment 53 Doug Laidlaw 2013-02-03 23:15:52 CET
In that case, I will take myself off the CC list.
Doug Laidlaw 2013-02-03 23:16:22 CET

CC: laidlaws => (none)

Comment 54 Valery Pipin 2013-02-04 02:14:00 CET
The bug is not actual for me. However, I used to assign the hostname  under fresh install. I'll  take myself off the CC list
Comment 55 Kim Garren 2013-04-17 20:54:35 CEST
It's unknown as to if this is still valid by this user, as the issue never presented itself in M2. HOWEVER... seeing an interesting process here may shed some light (then again, I could be totally completely wrong).

There may be a reason why I've not had the issue. Of note is my hostname dedanna.rockz.net. It used to be that I had dedanna.rocks.net for years and years, until I found strange things happening right after installation of M2 with it, such as "domain is in use, dedanna.rocks.net". After a check online, indeed, the domain rocks.net is now on park. I further came to find when I changed to dedanna.rockz.net, that even though I was changing the SYSTEM hostname only (via editing /etc/sysconfig/network), it was also acting as an FQDN, which was not the intention, or what I wanted (I do not own rocks.net or rockz.net domains). I wondered what was going on until I did another search on setting the hostname, and found that our system hostname can be set as our owned domain (thanks to Jason Blevins here: http://jblevins.org/log/hostname).

Note: My system hostname is actually a sub-domain format: dedanna.rockz.net (it was mentioned earlier in this bug about having that format for the system hostname), I set the hostname immediately after installation of my distribution (in all cases) permanently, and I've had absolutely no problem with draktools, other programs running, or with my hostname changing. It has remained permanent (and now that I know the difference of system hostname vs. an FQDN, I may be able to change back to dedanna.rocks.net). I also keep my CRDA set to the area I'm in, in the world. Why it "went" initially as an FQDN, is unknown by this user.

Food for thought.

.:[ dedanna@dedanna.rockz.net : 19:40:30 : ~ ]:.
:) cat /etc/sysconfig/network
HOSTNAME=dedanna.rockz.net
NETWORKING=yes
CRDA_DOMAIN=GB

That was my only single hostname issue, all along, with Mageia 2.

CC: (none) => skeeter1029

Comment 56 Kim Garren 2013-04-17 20:57:59 CEST
Oh, this was on a netbook, Toshiba NB255, wireless and wired both.
Comment 57 Nic Baxter 2015-03-31 02:21:51 CEST
can we have a status on this bug? Is it still valid ?

CC: (none) => nic

Comment 58 Marja Van Waes 2015-09-22 19:43:58 CEST
(In reply to Nic Baxter from comment #57)
> can we have a status on this bug? Is it still valid ?

There was no reply and the only activity on this bug since april 2013 was your question.

Closing as OLD

Feel free to reopen if needed, or to file a new bug report (this one already contains too many comments, reading them all is exhausting)

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.