Re: How to avoid using policy kit with openvpn
I just noticed that I inserted that "Ping started to work" after wrong message chain. That must have been pretty confusing. I'm not worried about OpenVPN at the moment. It seems working quite well now. As I told before, problem was triggered uncompressing cert archive so that it produced /etc/openvpn directory whose owner did not exist in system records. There was no way back. Only re-installing Linux helped. These last messages should have been following chain with title: "Problems getting device state change events through" I'm terribly sorry about this confusion. -Matti 2016-12-15 19:36 GMT+02:00 matti kaasinen: > > 2016-12-15 18:41 GMT+02:00 Dan Williams : > >> > *route add default dev eth0 metric 99* >> > So, everything is fine! >> >> That implies that the default route was not set up correctly >> beforehand. What's the output of "ip route" before you add that >> default route? >> > Yes, there was no default route set at all. In fact it should have been > created by avahi-autoipd.action script command: > > ip route add default dev "$2" metric "$METRIC" scope link ||: > > Somehow this did not do the trick. I changed that to: > > ip route add default dev "$2" metric "$METRIC"||: > > Default route was produced after that. I did not check that command > manually, but I suppose that ip command is coming from busybox and do not > support ip command properly. It's also possibly that I had ordinary ip > command installed in that older set-up, I don > > I found out just before leaving office that connection did not recover > after unplugging and plugging again. It could come from the fact that I did > not fix "CONFLICT|UNBIND|STOP" branch of avahi-autoipd.action script that > seems also having these "scope link" statements. I'll check that tomorrow > >> >> You might try setting the "never-default" option in the VPN >> connection's config to "true", to indicate that the VPN shouldn't grab >> the default route. >> > I'll check this tomorrow. > > Thanks, > Matti > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-12-15 18:41 GMT+02:00 Dan Williams: > > *route add default dev eth0 metric 99* > > So, everything is fine! > > That implies that the default route was not set up correctly > beforehand. What's the output of "ip route" before you add that > default route? > Yes, there was no default route set at all. In fact it should have been created by avahi-autoipd.action script command: ip route add default dev "$2" metric "$METRIC" scope link ||: Somehow this did not do the trick. I changed that to: ip route add default dev "$2" metric "$METRIC"||: Default route was produced after that. I did not check that command manually, but I suppose that ip command is coming from busybox and do not support ip command properly. It's also possibly that I had ordinary ip command installed in that older set-up, I don I found out just before leaving office that connection did not recover after unplugging and plugging again. It could come from the fact that I did not fix "CONFLICT|UNBIND|STOP" branch of avahi-autoipd.action script that seems also having these "scope link" statements. I'll check that tomorrow > > You might try setting the "never-default" option in the VPN > connection's config to "true", to indicate that the VPN shouldn't grab > the default route. > I'll check this tomorrow. Thanks, Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Thu, 2016-12-15 at 15:14 +0200, matti kaasinen wrote: > Ping started to work after executing command: > > > *route add default dev eth0 metric 99* > So, everything is fine! That implies that the default route was not set up correctly beforehand. What's the output of "ip route" before you add that default route? You might try setting the "never-default" option in the VPN connection's config to "true", to indicate that the VPN shouldn't grab the default route. Dan > Cheers, > Matti > > 2016-12-13 11:37 GMT+02:00 matti kaasinen: > > > > > Lubomir, Dan, > > I found what triggers this issue. I don't know what the reason is, > > though! > > It has nothing to do with NetworkManager. > > > > The trigger: > > 1) I load openvpn cert as zipped tar archive to root. > > 2) I uncompress/untar the archive that creates /etc/openvpn > > directory with > > openvpn cert/config files, user = original user. > > There is no way back at this point. Whole system is corrupted. It > > does not > > help deleting /etc/openvpn directory and note that it is not needed > > to > > start openvpn service to get this triggered. Only way I have found > > to > > recover is re-install whole system! > > > > I'm somewhat worried how easily one can corrupt whole Linux system > > - just > > load files to /etc whose user is not a proper user of the > > installation! > > They can be loaded to other place, change owner there and load then > > tho > > /etc. Anyhow this is none of your worry, I suppose. > > > > Cheers, > > Matti > > > > 2016-12-09 16:35 GMT+02:00 matti kaasinen > >: > > > > > > > > Lubo, > > > It took some time before I had change to get to this issue again. > > > I got > > > new board and it did not start at all, so I had to study u-boot > > > in between.. > > > Anyhow, answers to your comments: > > > > > > 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : > > > > > > > > > > > That sounds very strange. > > > > > > > > Please enable eavesdropping on the system bus: > > > > https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system > > > > _bus > > > > > > > > And then monitor the actual bus traffic before starting the > > > > "openvpn > > > > service" (is that the NM VPN plugin?) and after starting it and > > > > look > > > > out for what changed. > > > > > > > No. That is coming from Yocto/meta-openembedded/meta-networking > > > layer. > > > Just pure openvpn binary and systemd unit file for starting > > > service. > > > Only (main) difference I noticed from dbus-monitor log was that > > > before > > > openvpn I got following errors: > > > > > > string "Could not get owner of name > > > 'org.freedesktop.nm_avahi_autoipd': > > > no such name" > > > string "Could not get owner of name > > > 'org.fedoraproject.FirewallD1': > > > no such name" > > > string "Could not get owner of name 'org.freedesktop.login1': > > > no such > > > name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.ModemManager1': > > > no such name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.nm_dispatcher': > > > no such name" > > > > > > And after enabling openvpn service I got: > > > > > > string "Could not get owner of name > > > 'org.freedesktop.nm_avahi_autoipd': > > > no such name" > > > string "Could not get owner of name > > > 'org.fedoraproject.FirewallD1': > > > no such name" > > > string "Could not get owner of name 'org.freedesktop.login1': > > > no such > > > name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.PolicyKit1': no > > > such name" > > > string "Could not get owner of name 'org.bluez': no such name" > > > string "Could not get owner of name > > > 'org.freedesktop.nm_dispatcher': > > > no such name" > > > > > > So, policy kit has vanished. > > > > > > I'm not sure at all that I could concentrate on the correct > > > details of > > > these logs, though. So, I would really appreciate any > > > suggestions. > > > > > > What I noticed from systemd journal regarding ntp synchronization > > > was: > > > > > > Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time > > > Synchronization... > > > Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to > > > allocate > > > manager: Permission denied[[0m > > > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd- > > > timesyncd.service: > > > Main process exited, code=exited, status=1/FAILURE[[0m > > > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network > > > Time > > > Synchronization.[[0m > > > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd- > > > timesyncd.service: > > > Unit entered failed state.[[0m > > > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd- > > >
Re: How to avoid using policy kit with openvpn
Ping started to work after executing command: *route add default dev eth0 metric 99* So, everything is fine! Cheers, Matti 2016-12-13 11:37 GMT+02:00 matti kaasinen: > Lubomir, Dan, > I found what triggers this issue. I don't know what the reason is, though! > It has nothing to do with NetworkManager. > > The trigger: > 1) I load openvpn cert as zipped tar archive to root. > 2) I uncompress/untar the archive that creates /etc/openvpn directory with > openvpn cert/config files, user = original user. > There is no way back at this point. Whole system is corrupted. It does not > help deleting /etc/openvpn directory and note that it is not needed to > start openvpn service to get this triggered. Only way I have found to > recover is re-install whole system! > > I'm somewhat worried how easily one can corrupt whole Linux system - just > load files to /etc whose user is not a proper user of the installation! > They can be loaded to other place, change owner there and load then tho > /etc. Anyhow this is none of your worry, I suppose. > > Cheers, > Matti > > 2016-12-09 16:35 GMT+02:00 matti kaasinen : > >> Lubo, >> It took some time before I had change to get to this issue again. I got >> new board and it did not start at all, so I had to study u-boot in between.. >> Anyhow, answers to your comments: >> >> 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : >> >>> That sounds very strange. >>> >>> Please enable eavesdropping on the system bus: >>> https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus >>> >>> And then monitor the actual bus traffic before starting the "openvpn >>> service" (is that the NM VPN plugin?) and after starting it and look >>> out for what changed. >>> >> No. That is coming from Yocto/meta-openembedded/meta-networking layer. >> Just pure openvpn binary and systemd unit file for starting service. >> Only (main) difference I noticed from dbus-monitor log was that before >> openvpn I got following errors: >> >>string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': >> no such name" >>string "Could not get owner of name 'org.fedoraproject.FirewallD1': >> no such name" >>string "Could not get owner of name 'org.freedesktop.login1': no such >> name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.ModemManager1': >> no such name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.nm_dispatcher': >> no such name" >> >> And after enabling openvpn service I got: >> >>string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': >> no such name" >>string "Could not get owner of name 'org.fedoraproject.FirewallD1': >> no such name" >>string "Could not get owner of name 'org.freedesktop.login1': no such >> name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.PolicyKit1': no >> such name" >>string "Could not get owner of name 'org.bluez': no such name" >>string "Could not get owner of name 'org.freedesktop.nm_dispatcher': >> no such name" >> >> So, policy kit has vanished. >> >> I'm not sure at all that I could concentrate on the correct details of >> these logs, though. So, I would really appreciate any suggestions. >> >> What I noticed from systemd journal regarding ntp synchronization was: >> >> Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... >> Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate >> manager: Permission denied[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Main process exited, code=exited, status=1/FAILURE[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time >> Synchronization.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Unit entered failed state.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: >> Failed with result 'exit-code'.[[0m >> Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has >> no hold-off time, scheduling restart. >> Dec 09 15:08:47 cpr3 systemd[1]: Stopped Network Time Synchronization. >> Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... >> >> >> Avahi was behaving pretty much the same besides that "Permission denied" >> message: >> >> Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... >> Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Main >> process exited, code=exited, status=255/n/a[[0m >> Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;31mFailed to start Avahi >> mDNS/DNS-SD Stack.[[0m >> Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Unit >> entered failed state.[[0m >> Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Failed
Re: How to avoid using policy kit with openvpn
Lubomir, Dan, I found what triggers this issue. I don't know what the reason is, though! It has nothing to do with NetworkManager. The trigger: 1) I load openvpn cert as zipped tar archive to root. 2) I uncompress/untar the archive that creates /etc/openvpn directory with openvpn cert/config files, user = original user. There is no way back at this point. Whole system is corrupted. It does not help deleting /etc/openvpn directory and note that it is not needed to start openvpn service to get this triggered. Only way I have found to recover is re-install whole system! I'm somewhat worried how easily one can corrupt whole Linux system - just load files to /etc whose user is not a proper user of the installation! They can be loaded to other place, change owner there and load then tho /etc. Anyhow this is none of your worry, I suppose. Cheers, Matti 2016-12-09 16:35 GMT+02:00 matti kaasinen: > Lubo, > It took some time before I had change to get to this issue again. I got > new board and it did not start at all, so I had to study u-boot in between.. > Anyhow, answers to your comments: > > 2016-11-25 18:15 GMT+02:00 Lubomir Rintel : > >> That sounds very strange. >> >> Please enable eavesdropping on the system bus: >> https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus >> >> And then monitor the actual bus traffic before starting the "openvpn >> service" (is that the NM VPN plugin?) and after starting it and look >> out for what changed. >> > No. That is coming from Yocto/meta-openembedded/meta-networking layer. > Just pure openvpn binary and systemd unit file for starting service. > Only (main) difference I noticed from dbus-monitor log was that before > openvpn I got following errors: > >string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': > no such name" >string "Could not get owner of name 'org.fedoraproject.FirewallD1': no > such name" >string "Could not get owner of name 'org.freedesktop.login1': no such > name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.ModemManager1': > no such name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.nm_dispatcher': > no such name" > > And after enabling openvpn service I got: > >string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': > no such name" >string "Could not get owner of name 'org.fedoraproject.FirewallD1': no > such name" >string "Could not get owner of name 'org.freedesktop.login1': no such > name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.PolicyKit1': no > such name" >string "Could not get owner of name 'org.bluez': no such name" >string "Could not get owner of name 'org.freedesktop.nm_dispatcher': > no such name" > > So, policy kit has vanished. > > I'm not sure at all that I could concentrate on the correct details of > these logs, though. So, I would really appreciate any suggestions. > > What I noticed from systemd journal regarding ntp synchronization was: > > Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... > Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate > manager: Permission denied[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Main > process exited, code=exited, status=1/FAILURE[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time > Synchronization.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Unit > entered failed state.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: > Failed with result 'exit-code'.[[0m > Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has no > hold-off time, scheduling restart. > Dec 09 15:08:47 cpr3 systemd[1]: Stopped Network Time Synchronization. > Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... > > > Avahi was behaving pretty much the same besides that "Permission denied" > message: > > Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... > Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Main > process exited, code=exited, status=255/n/a[[0m > Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;31mFailed to start Avahi > mDNS/DNS-SD Stack.[[0m > Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Unit > entered failed state.[[0m > Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Failed > with result 'exit-code'.[[0m > Dec 09 15:09:01 cpr3 systemd[1]: avahi-daemon.service: Service hold-off > time over, scheduling restart. > Dec 09 15:09:01 cpr3 systemd[1]: Stopped Avahi mDNS/DNS-SD Stack. > Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... > > Any help appreciated, > -Matti >
Re: How to avoid using policy kit with openvpn
Lubo, It took some time before I had change to get to this issue again. I got new board and it did not start at all, so I had to study u-boot in between.. Anyhow, answers to your comments: 2016-11-25 18:15 GMT+02:00 Lubomir Rintel: > That sounds very strange. > > Please enable eavesdropping on the system bus: > https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus > > And then monitor the actual bus traffic before starting the "openvpn > service" (is that the NM VPN plugin?) and after starting it and look > out for what changed. > No. That is coming from Yocto/meta-openembedded/meta-networking layer. Just pure openvpn binary and systemd unit file for starting service. Only (main) difference I noticed from dbus-monitor log was that before openvpn I got following errors: string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': no such name" string "Could not get owner of name 'org.fedoraproject.FirewallD1': no such name" string "Could not get owner of name 'org.freedesktop.login1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.ModemManager1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.nm_dispatcher': no such name" And after enabling openvpn service I got: string "Could not get owner of name 'org.freedesktop.nm_avahi_autoipd': no such name" string "Could not get owner of name 'org.fedoraproject.FirewallD1': no such name" string "Could not get owner of name 'org.freedesktop.login1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.PolicyKit1': no such name" string "Could not get owner of name 'org.bluez': no such name" string "Could not get owner of name 'org.freedesktop.nm_dispatcher': no such name" So, policy kit has vanished. I'm not sure at all that I could concentrate on the correct details of these logs, though. So, I would really appreciate any suggestions. What I noticed from systemd journal regarding ntp synchronization was: Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... Dec 09 15:08:47 cpr3 systemd-timesyncd[467]: [[0;1;31mFailed to allocate manager: Permission denied[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Main process exited, code=exited, status=1/FAILURE[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;31mFailed to start Network Time Synchronization.[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Unit entered failed state.[[0m Dec 09 15:08:47 cpr3 systemd[1]: [[0;1;39msystemd-timesyncd.service: Failed with result 'exit-code'.[[0m Dec 09 15:08:47 cpr3 systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. Dec 09 15:08:47 cpr3 systemd[1]: Stopped Network Time Synchronization. Dec 09 15:08:47 cpr3 systemd[1]: Starting Network Time Synchronization... Avahi was behaving pretty much the same besides that "Permission denied" message: Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Main process exited, code=exited, status=255/n/a[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;31mFailed to start Avahi mDNS/DNS-SD Stack.[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Unit entered failed state.[[0m Dec 09 15:09:01 cpr3 systemd[1]: [[0;1;39mavahi-daemon.service: Failed with result 'exit-code'.[[0m Dec 09 15:09:01 cpr3 systemd[1]: avahi-daemon.service: Service hold-off time over, scheduling restart. Dec 09 15:09:01 cpr3 systemd[1]: Stopped Avahi mDNS/DNS-SD Stack. Dec 09 15:09:01 cpr3 systemd[1]: Starting Avahi mDNS/DNS-SD Stack... Any help appreciated, -Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Fri, 2016-11-25 at 15:20 +0200, matti kaasinen wrote: > > 2016-11-24 16:03 GMT+02:00 matti kaasinen: > > > To be more exact: service that dos not start anymore after I enable and > > later disable it is avahi-daemon.service. It is told in that unit file that: > > Alias=dbus-org.freedesktop.Avahi.service. > > > > > In fact, it seems that any operations using dbus (NTP, avahi...) have > problems after starting openvpn service and it does not vanish if I stop > it. So, it seems that either openvpn sevice (or possibly NM) creates policy > some policy kit rule that does not vanish when I disable and stop openvpn. That sounds very strange. Please enable eavesdropping on the system bus: https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus And then monitor the actual bus traffic before starting the "openvpn service" (is that the NM VPN plugin?) and after starting it and look out for what changed. You can use "busctl monitor" or "dbus-monitor --system" to do the monitoring. Be sure to disable eavesdropping afterwards. If it won't be obvious what went wrong then please share the logs (preferably via a pastebin and after making sure you're not leaking your passwords). Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-24 16:03 GMT+02:00 matti kaasinen: > To be more exact: service that dos not start anymore after I enable and > later disable it is avahi-daemon.service. It is told in that unit file that: > Alias=dbus-org.freedesktop.Avahi.service. > In fact, it seems that any operations using dbus (NTP, avahi...) have problems after starting openvpn service and it does not vanish if I stop it. So, it seems that either openvpn sevice (or possibly NM) creates policy some policy kit rule that does not vanish when I disable and stop openvpn. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-23 19:31 GMT+02:00 matti kaasinen: > BTW, I got a feeling that I got more services failed after I enabled > openvpn.service (like avahi). Also these problems did not disappear when I > disabled openvpn.service and booted card. Same goes with modem problems. > So, does NetworkManager or somebody else keep some data regarding OpenVPN > set-up even though its been disabled. If so, would it be better managing > OpenVPN connection with NetworkManager (-plugin) than using openvpn.service > for that. Also is openvpn-plugin build automatically and get into use if > tun interface is not configured as unmanaged? To be more exact: service that dos not start anymore after I enable and later disable it is avahi-daemon.service. It is told in that unit file that: Alias=dbus-org.freedesktop.Avahi.service. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
2016-11-23 19:31 GMT+02:00 matti kaasinen: > 2016-11-23 18:13 GMT+02:00 Dan Williams : > >> If these are single-user systems, you can rebuild NM with PolicyKit >> disabled so that it never validates requests against PolicyKit. >> > I'll try rebuilding tomorrow. I suppose (hope) there is clear switch for > disabling it. > I thought I found the configuration switch. I ran build using: --enable-polkit=disabled set-up. >From configuration log I can see: following note NOTE: Running ../NetworkManager-1.0.10/configure --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=arm-poky-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/CPR3/sysroots/am335x-evm --enable-introspection --disable-ifcfg-rh --disable-ifnet --disable-ifcfg-suse --disable-more-warnings --with-iptables=/usr/sbin/iptables --with-tests --with-nmtui=yes --disable-static --enable-nls --enable-polkit=disabled--disable-bluez5-dun --with-libsoup=no --with-dhclient=/sbin/dhclient --with-dnsmasq=/usr/bin/dnsmasq --enable-ifupdown --with-modem-manager-1=yes --with-netconfig=yes --with-crypto=nss --disable-ppp --disable-qt --with-systemdsystemunitdir=/lib/systemd/system --with-session-tracking=systemd --enable-polkit --enable-wifi=no But later on there is also checking for POLKIT... yes and als Platform: session tracking: systemd suspend/resume: systemd policykit: yes (restrictive modify.system) (default=yes) polkit agent: yes selinux: no Also I got similar error message when trying to access SIM. >> > Could you 'nmcli g log level debug' on a problem machine and grab some >> log output from before and after the error? >> > I don't have access to that machine now, but I'll do that tomorrow. > Please find the NetworkManager journal with above nmcli executed before (would attachment be better?) Read config: /etc/NetworkManager/NetworkManager.conf Loaded settings plugin keyfile: (c) 2007 - 2015 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. keyfile: new connection /etc/NetworkManager/system-connections/eth0 (5769be4a-ee83-4674-890a-f19e96b6c31e,"eth0") monitoring kernel firmware directory '/lib/firmware'. Loaded device plugin: NMVxlanFactory (internal) Loaded device plugin: NMVlanFactory (internal) Loaded device plugin: NMVethFactory (internal) Loaded device plugin: NMTunFactory (internal) Loaded device plugin: NMMacvlanFactory (internal) Loaded device plugin: NMInfinibandFactory (internal) Loaded device plugin: NMGreFactory (internal) Loaded device plugin: NMEthernetFactory (internal) Loaded device plugin: NMBridgeFactory (internal) Loaded device plugin: NMBondFactory (internal) Loaded device plugin: NMWwanFactory (/usr/lib/NetworkManager/libnm-device-plugin-wwan.so) Loaded device plugin: NMBluezManager (/usr/lib/NetworkManager/libnm-device-plugin-bluetooth.so) WiFi enabled by radio killswitch; enabled by state file WWAN enabled by radio killswitch; enabled by state file WiMAX enabled by radio killswitch; enabled by state file Networking is enabled by state file (lo): link connected (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex: 1) (eth0): new Ethernet device (carrier: OFF, driver: 'cpsw', ifindex: 2) (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] ModemManager available in the bus (eth0): link connected (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] Auto-activating connection 'eth0'. (eth0): Activation: starting connection 'eth0' (5769be4a-ee83-4674-890a-f19e96b6c31e) (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0] NetworkManager state is now CONNECTING (eth0): device state change: prepare -> config (reason 'none') [40 50 0] (eth0): device state change: config -> ip-config (reason 'none') [50 70 0] Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds) address 192.168.3.1 plen 22 expires in 600 seconds gateway 192.168.1.2 nameserver '192.168.1.2' domain name 'sitecno.fi' (eth0): DHCPv4 state changed unknown -> bound (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0] (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0] (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0] NetworkManager state is now CONNECTED_LOCAL NetworkManager state is now CONNECTED_GLOBAL Policy set
Re: How to avoid using policy kit with openvpn
2016-11-23 18:13 GMT+02:00 Dan Williams: > If these are single-user systems, you can rebuild NM with PolicyKit > disabled so that it never validates requests against PolicyKit. > I'll try rebuilding tomorrow. I suppose (hope) there is clear switch for disabling it. > > Could you 'nmcli g log level debug' on a problem machine and grab some > log output from before and after the error? > I don't have access to that machine now, but I'll do that tomorrow. BTW, I got a feeling that I got more services failed after I enabled openvpn.service (like avahi). Also these problems did not disappear when I disabled openvpn.service and booted card. Same goes with modem problems. So, does NetworkManager or somebody else keep some data regarding OpenVPN set-up even though its been disabled. If so, would it be better managing OpenVPN connection with NetworkManager (-plugin) than using openvpn.service for that. Also is openvpn-plugin build automatically and get into use if tun interface is not configured as unmanaged? -Matti ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Wed, 2016-11-23 at 17:25 +0200, matti kaasinen wrote: > Version information: > OpenVPN: 2.3.8 > NetworkManager: 1.0.10 > ModemManager 1.4.12 > Dbus-daemon:1.10.6 If these are single-user systems, you can rebuild NM with PolicyKit disabled so that it never validates requests against PolicyKit. Could you 'nmcli g log level debug' on a problem machine and grab some log output from before and after the error? Dan > > 2016-11-23 16:37 GMT+02:00 matti kaasinen: > > > > > Hi! > > > > I do have kind of manager of NetworkManager who amongst of other > > things > > tries to connect modem automatically because my devices are > > embedded cards > > located somewhere in nowhere. These cards communicate to server > > through > > OpenVpn tunnel. This modem connection process worked quite well > > untill I > > tried using it with OpenVpn. It seems that I can't use > > AddAndActivateConnection method anymore (python api) as I do get > > now "Got > > "PolicyKit authorization failed" error message at the point where I > > try to > > access PIN. This does not happen if OpenVpn is not activated. I > > tried to > > use following option in NetworkManager.conf file: > > > > [keyfile] > > unmanaged-devices=interface-name:tun* > > > > Any suggestions appreciated! > > > > Thanks, > > Matti > > > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
Version information: OpenVPN: 2.3.8 NetworkManager: 1.0.10 ModemManager 1.4.12 Dbus-daemon:1.10.6 2016-11-23 16:37 GMT+02:00 matti kaasinen: > Hi! > > I do have kind of manager of NetworkManager who amongst of other things > tries to connect modem automatically because my devices are embedded cards > located somewhere in nowhere. These cards communicate to server through > OpenVpn tunnel. This modem connection process worked quite well untill I > tried using it with OpenVpn. It seems that I can't use > AddAndActivateConnection method anymore (python api) as I do get now "Got > "PolicyKit authorization failed" error message at the point where I try to > access PIN. This does not happen if OpenVpn is not activated. I tried to > use following option in NetworkManager.conf file: > > [keyfile] > unmanaged-devices=interface-name:tun* > > Any suggestions appreciated! > > Thanks, > Matti > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list