Re: How to avoid using policy kit with openvpn

2016-12-15 Thread matti kaasinen
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 Thread 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 Thread Dan Williams
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

2016-12-15 Thread matti kaasinen
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

2016-12-13 Thread 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
> 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

2016-12-09 Thread 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
___
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-25 Thread Lubomir Rintel
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-25 Thread matti kaasinen
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-24 Thread matti kaasinen
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-24 Thread matti kaasinen
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 Thread 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.

>
>
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

2016-11-23 Thread Dan Williams
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

2016-11-23 Thread matti kaasinen
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