Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Dan Williams

On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
 On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
  NetworkManager sets logind inhibitor lock to monitor for suspend
  events. So it implicitly requires logind to be present when NM
  starts.

NM doesn't actually require that, it just wants to know about the
signals that logind sends and have a chance to respond to them.  If
logind isn't running, NM shouldn't really care.  But perhaps expectation
is not matching reality in the code.

 Any idea what it needs the inhibitor for?

To be aware of suspend/resume events of course.  NM may want to
disconnect the network cleanly before suspending, and on resume may need
to clean up network connections and restart certain operations.

  logind is ordered after nss-user-lookup.target. If we have remote
user
  database, it means that logind depends on network to be up and
running.
  
  If network is provided by NetworkManager we have a loop.
  
  Due to the fact that NetworkManager service itself does not declare
  dependency on logind, it can be pretty hard to recognize.
  
  Any idea how it can be solved nicely? I can only think of delaying
  inhibitor logic in NM until logind is started. Not sure what side
  effects it may have.
 
 Yeah, I figure if they want to be able to run in early parts of boot
 they should watch logind's bus name and create their inhibitor only
 after it appears.

Does logind get D-Bus autolaunched?  NM is just creating a bus proxy for
the logind DBus service, and then attempting to call a D-Bus method on
logind to take an inhibitor.  It doesn't actually care that much about
the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
prohibit logind from launching.

Perhaps NM is requesting logind to start through D-Bus autolaunch, but
since the network isn't up yet logind then fails itself?

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


NetworkManager permissions

2014-12-15 Thread Peter Magnusson
Im having some problems with permissions on NetworkManager. We are in
the process of migrating our clients from RHEL 6.6 to RHEL 7.
The clients connect to our wireless network using eap-tls, we provide
the configuration,certificate and keys for this from our central
configurationserver so that the connection is transparent to the user.

In RHEL6.6 the password for the privatekey(pkcs12 used for
authentication) was not visible to the users only to administrators.
This was achieved by setting the connection as system wide in which
case the configfile was stored under /etc/sysconfig/network-scripts
and only accessible by root.

In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild
from git) we can still limit the permissions to NM config using polkit
but when doing this we also limit the possiblity for the user to add
new wifi-networks.

So what i would like to achieve is to limit access to existing
connections (or connections not added by user) but i still want the
users to be able to add new wificonnections. Is this possible ?

Any advice would be much appreciated!

Best Regards
Peter
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Lennart Poettering
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 NetworkManager sets logind inhibitor lock to monitor for suspend
 events. So it implicitly requires logind to be present when NM
 starts.

Any idea what it needs the inhibitor for?

 logind is ordered after nss-user-lookup.target. If we have remote user
 database, it means that logind depends on network to be up and running.
 
 If network is provided by NetworkManager we have a loop.
 
 Due to the fact that NetworkManager service itself does not declare
 dependency on logind, it can be pretty hard to recognize.
 
 Any idea how it can be solved nicely? I can only think of delaying
 inhibitor logic in NM until logind is started. Not sure what side
 effects it may have.

Yeah, I figure if they want to be able to run in early parts of boot
they should watch logind's bus name and create their inhibitor only
after it appears.

Lennart

-- 
Lennart Poettering, Red Hat
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Andrei Borzenkov
В Mon, 15 Dec 2014 11:34:17 -0600
Dan Williams d...@redhat.com пишет:

 
 On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
  On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
  
   NetworkManager sets logind inhibitor lock to monitor for suspend
   events. So it implicitly requires logind to be present when NM
   starts.
 
 NM doesn't actually require that, it just wants to know about the
 signals that logind sends and have a chance to respond to them.  If
 logind isn't running, NM shouldn't really care.  But perhaps expectation
 is not matching reality in the code.
 
  Any idea what it needs the inhibitor for?
 
 To be aware of suspend/resume events of course.  NM may want to
 disconnect the network cleanly before suspending, and on resume may need
 to clean up network connections and restart certain operations.
 
   logind is ordered after nss-user-lookup.target. If we have remote
 user
   database, it means that logind depends on network to be up and
 running.
   
   If network is provided by NetworkManager we have a loop.
   
   Due to the fact that NetworkManager service itself does not declare
   dependency on logind, it can be pretty hard to recognize.
   
   Any idea how it can be solved nicely? I can only think of delaying
   inhibitor logic in NM until logind is started. Not sure what side
   effects it may have.
  
  Yeah, I figure if they want to be able to run in early parts of boot
  they should watch logind's bus name and create their inhibitor only
  after it appears.
 
 Does logind get D-Bus autolaunched?

Yes.

NM is just creating a bus proxy for
 the logind DBus service, and then attempting to call a D-Bus method on
 logind to take an inhibitor.  It doesn't actually care that much about
 the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
 prohibit logind from launching.
 
 Perhaps NM is requesting logind to start through D-Bus autolaunch, but
 since the network isn't up yet logind then fails itself?
 

systemd tries to launch logind service which now waits for services it
is ordered After and eventually times out.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

2014-12-15 Thread Dan Williams
On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
 В Mon, 15 Dec 2014 11:34:17 -0600
 Dan Williams d...@redhat.com пишет:
 
  
  On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
   On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
   
NetworkManager sets logind inhibitor lock to monitor for suspend
events. So it implicitly requires logind to be present when NM
starts.
  
  NM doesn't actually require that, it just wants to know about the
  signals that logind sends and have a chance to respond to them.  If
  logind isn't running, NM shouldn't really care.  But perhaps expectation
  is not matching reality in the code.
  
   Any idea what it needs the inhibitor for?
  
  To be aware of suspend/resume events of course.  NM may want to
  disconnect the network cleanly before suspending, and on resume may need
  to clean up network connections and restart certain operations.
  
logind is ordered after nss-user-lookup.target. If we have remote
  user
database, it means that logind depends on network to be up and
  running.

If network is provided by NetworkManager we have a loop.

Due to the fact that NetworkManager service itself does not declare
dependency on logind, it can be pretty hard to recognize.

Any idea how it can be solved nicely? I can only think of delaying
inhibitor logic in NM until logind is started. Not sure what side
effects it may have.
   
   Yeah, I figure if they want to be able to run in early parts of boot
   they should watch logind's bus name and create their inhibitor only
   after it appears.
  
  Does logind get D-Bus autolaunched?
 
 Yes.
 
 NM is just creating a bus proxy for
  the logind DBus service, and then attempting to call a D-Bus method on
  logind to take an inhibitor.  It doesn't actually care that much about
  the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
  prohibit logind from launching.
  
  Perhaps NM is requesting logind to start through D-Bus autolaunch, but
  since the network isn't up yet logind then fails itself?
  
 
 systemd tries to launch logind service which now waits for services it
 is ordered After and eventually times out.

NM patch filed for review by NM dev team:

https://bugzilla.gnome.org/show_bug.cgi?id=741572

Also, I don't think logind should fail if there is no network; no reason
for it to crash and burn just because everything isn't quite ready when
it starts.  I presume it's got capability to deal with sporadic network
outages, and that's not really different than waiting for networking to
show up soon after it starts.  But not my department...

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list