Re: dns update for ipv6 using dhcpv6

[Tim Coote]

> On 13 Dec 2016, at 19:08, Thomas Haller  wrote:
> 
> On Tue, 2016-12-13 at 16:13 +, Tim Coote wrote:
>> 
> 
> Hi Tim,
Hi Thomas,
> 
> sidenote:
> 
> When you use dhcp plugin "dhclient" (in NetworkManager.conf), then
> NetworkManager generates a suitable dhclient configuration in
> /var/lib/NetworkManager/dhclient-*.conf
> 
> Don't modify that file, because it will be overwritten.
Thanks. I’d got that.  That’s why I’m trying to find the upstream configuration 
location.
> 
> 
> NM merges other sources files into this file, so you can put your
> options there:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp/nm-dhcp-dhclient.c?id=eb77d4ed28fb7d72020fc4bce2a7f3477f0b8c1d#n219
> 
> If you turn on debug-logging, NM will also log lines like:
> 
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0469] dhcp4 
> (wlp3s0): creating composite dhclient config 
> /var/lib/NetworkManager/dhclient-wlp3s0.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0469] dhcp4 
> (wlp3s0): looking for existing config 
> /etc/NetworkManager/dhclient-7111201a-568f-4568-a0ed-cd1d4df11e8f.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
> (wlp3s0): looking for existing config /etc/NetworkManager/dhclient-wlp3s0.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
> (wlp3s0): looking for existing config /etc/NetworkManager/dhclient.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
> (wlp3s0): looking for existing config /etc/dhcp/dhclient-wlp3s0.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
> (wlp3s0): looking for existing config /etc/dhclient-wlp3s0.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
> (wlp3s0): looking for existing config /etc/dhcp/dhclient.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
> (wlp3s0): looking for existing config /etc/dhclient.conf
> Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
> (wlp3s0): no existing dhclient configuration to merge

I’ll try that.  I did try using /etc/NetworkManager/dhclient6-eth0.conf, but it 
didn’t seem to get merged. I need to review the syntax, I think.
> 
> 
> But can you not just configure ipv6.dhcp-send-hostname and ipv6.dhcp-
> hostname:
> 
>  nmcli connection modify $NAME ipv6.dhcp-send-hostname yes \
>ipv6.dhcp-hostname wibble.example.com 
Well that was how I was setting ipv6.dhcp-hostname, but after systemctl restart 
NetworkManager, it had been reset to '—‘. Now, I must have changed something, 
as it doesn’t change the value at all!

As an aside, the naming is a bit confusing to me: I’ve always understood 
hostname as a property of a computer, fqdn as a property of an interface.  I 
used to run a prof. services function of a discovery tool and the mean number 
of computers with a hostname of venus in a sizeable enterprise was 7. We’d find 
up to the small hundreds of fqdns per computer (physical boxes used for testing 
web functionality).

I’d assumed that if that worked across a service restart, I’d be able to find 
the file that it got stored in.
> Thomas

Thanks

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

Re: dns update for ipv6 using dhcpv6

[Thomas Haller]

On Tue, 2016-12-13 at 16:13 +, Tim Coote wrote:
> Hullo
> I’m trying to build a homenet environment that includes some fedora
> 25 vms running NetworkManager-1.4.2-1.fc25.x86_64.  I’d like these
> computers to update dns when they get new ipv6 addresses. Working
> from the discussion on this page: http://bit.ly/2hr2SnC, I was able
> to construct a suitable dhclient6-eth0.conf to run directly with
> dhclient by adding a line:
> 
> send fqdn.fqdn “wibble.example.com”
> 
> to the file created by NetworkManager in /var/lib/NetworkManager/.
> With the extra line, the relevant update is forwarded by dhclient.
> 
> However, I cannot work out where or what to put in NetworkManager’s
> or the redhat configuration to get NM to create a suitable dhclient6-
> eth0.conf file.
> 
> I also noted that the issue noted on the link above about ipv6.dhcp-
> hostname getting blown away each time the service is reset still
> holds with the nm version.
> 
> Am I looking at the right area to get the dns updated? If so, where
> should I be putting the configuration to get the right autogenerated
> dhclient file?
> 
> Thanks in advance

Hi Tim,

 sidenote:

When you use dhcp plugin "dhclient" (in NetworkManager.conf), then
NetworkManager generates a suitable dhclient configuration in
/var/lib/NetworkManager/dhclient-*.conf

Don't modify that file, because it will be overwritten.


NM merges other sources files into this file, so you can put your
options there:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp/nm-dhcp-dhclient.c?id=eb77d4ed28fb7d72020fc4bce2a7f3477f0b8c1d#n219

If you turn on debug-logging, NM will also log lines like:

Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0469] dhcp4 
(wlp3s0): creating composite dhclient config 
/var/lib/NetworkManager/dhclient-wlp3s0.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0469] dhcp4 
(wlp3s0): looking for existing config 
/etc/NetworkManager/dhclient-7111201a-568f-4568-a0ed-cd1d4df11e8f.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
(wlp3s0): looking for existing config /etc/NetworkManager/dhclient-wlp3s0.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
(wlp3s0): looking for existing config /etc/NetworkManager/dhclient.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0470] dhcp4 
(wlp3s0): looking for existing config /etc/dhcp/dhclient-wlp3s0.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
(wlp3s0): looking for existing config /etc/dhclient-wlp3s0.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
(wlp3s0): looking for existing config /etc/dhcp/dhclient.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
(wlp3s0): looking for existing config /etc/dhclient.conf
Dec 13 12:15:29 x250 NetworkManager[388]:  [1481627729.0471] dhcp4 
(wlp3s0): no existing dhclient configuration to merge


<


But can you not just configure ipv6.dhcp-send-hostname and ipv6.dhcp-
hostname:

  nmcli connection modify $NAME ipv6.dhcp-send-hostname yes \
ipv6.dhcp-hostname wibble.example.com


Thomas

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

dns update for ipv6 using dhcpv6

[Tim Coote]

Hullo
I’m trying to build a homenet environment that includes some fedora 25 vms 
running NetworkManager-1.4.2-1.fc25.x86_64.  I’d like these computers to update 
dns when they get new ipv6 addresses. Working from the discussion on this page: 
http://bit.ly/2hr2SnC , I was able to construct a 
suitable dhclient6-eth0.conf to run directly with dhclient by adding a line:

send fqdn.fqdn “wibble.example.com ”

to the file created by NetworkManager in /var/lib/NetworkManager/. With the 
extra line, the relevant update is forwarded by dhclient.

However, I cannot work out where or what to put in NetworkManager’s or the 
redhat configuration to get NM to create a suitable dhclient6-eth0.conf file.

I also noted that the issue noted on the link above about ipv6.dhcp-hostname 
getting blown away each time the service is reset still holds with the nm 
version.

Am I looking at the right area to get the dns updated? If so, where should I be 
putting the configuration to get the right autogenerated dhclient file?

Thanks in advance

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

Re: I would like to call attention to a documentation bug that only the Application developers will be able to remedy/close.

[Thomas Haller]

On Fri, 2016-12-09 at 11:55 -0500, Calvin Arndt wrote:
> First a caveat...
> My system is an Ubuntu 16.04 Desktop system.
> I use it for daily management of a 54 device network
> of Windows PC's (10), cameras (9), scales (4), Linux DVR's (2)
>   CentOS Pos system and many other Iot type stuff.
> My system functions as the network router, firewall, Wifi access
> point
> caching dns server, as well as serving all my admin needs (email,
> document writing
> web research and more). It supplies the tunnelled components
> that are remotely critical to our operation via ssh tunnels (using
> autossh for permanence).
> This is where Ubuntu has always shined for me! Ubuntu and
> NetworkManager have always
> been well up to the task of providing this functionality! So firstly
> Thanks for your efforts.
> The snag that I continuously run into when setting up systems like
> this one is this...
> The documentation for NetworkManager doesn't go into detail about
> dnsmasq. It's uses
> and configuration, while not under the scope of NetworkManager
> documentation, are
> critical to the operation of a system like mine. So why bother you
> guys?
> To get my system and all its quirks configured, I have to do two
> things. Wait for NetworkManager to finish
> configuration of the basic interfaces on my machine. Kill the dnsmasq
> daemon that NetworkManager leaves
> laying around then start my own custom configuration of dnsmasq.
> I don't like killing daemons on any system, but it is what I have to
> do. No amount of tinkering has lead me
> to any other solution.  Two things play into this, in my mind. First,
> the simple fact that I can kill NetworkManager's
> dnsmasq daemon (ie NetworkManager doesn't notice and restart dnsmasq)
> makes me wonder why it is started
> with the (hard coded???) option --keep-in-foreground anyway. Second,
> also apparently hard coded, is the --cache-size=0.
> which as I understand it tells dnsmasq not to cache dns requests.
> The documentation really falls short here. No mention of dns caching,
> no mention of the proper way to use dnsmasq's
> many many other talent's without interrupting/destroying
> NetworkManager. We all can see that NetworkManager has
> given us some wiggle room in configuring dnsmasq (ie.
> /etc/NetworkManager/dnsmasq.d) but without anything in the
> documentation
> about common usage of this we are left to endless hours of google
> searching of trial and error scenarios! Minimally something ought to
> be said
> about the seemingly hard coded options NetworkManager starts dnsmasq
> with. Some discussion of NetworkManager design philosophy would be
> helpful.
> Again, thanks for your time and consideration of these issues!

Hi,


using dnsmasq via NetworkManager is supposed to give you a solution
that just works, without much configuration (or documentation).

It's not supposed to allow you to configure dnsmasq with all options
that dnsmasq understands. If you want that, use dnsmasq directly, not
via NetworkManager.

It's also not supposed to be the most flexible DNS solution, but a
simple one that works in many cases. Again, maybe systemd-resolved
could be that. Or of course, running your local caching DNS server
yourself.


See `man NetworkManager.conf` for main.dns and main.rc-manager
settings.


You are also not supposed to kill processes started by NetworkManager.
If you really want to forcefully restart the DNS plugin, `killall -HUP
NetworkManager`. If you have any issues that really require killing the
DNS plugin, it's a bug.

NM runs dnsmasq with --keep-in-foreground, because it started and
watches the dnsmasq process. This avoid for dnsmasq to double-fork,
which would prevent NetworkManager to notice when the dnsmasq process
exits. It very much notices when you kill the process, but it doesn't
restart it on purpose (at least not right away, only after the next DNS
update happens).


Thomas


>  
> Calvin
>  
> On 12/09/2016 05:13, Thomas Haller wrote:
> > On Wed, 2016-12-07 at 14:47 -0500, Calvin Arndt wrote:
> > > NetworkManager documentation does not document proper way to use
> > > different tools for dns /dhcp management. This additional
> > > documentation will need to be written by someone who develops
> > > this package. Its the philosophy behind the software that must be
> > > explained.
> > 
> > Hi,
> > 
> > your request is not very specific.
> > 
> > Are you looking at any specific documentation that you think is
> > lacking? Which documentation, and how precisely is it lacking?
> > 
> > Or were you unable to find any relevant documentation? For what
> > exactly? "dns/dhcp management" is not very clear what you want to
> > do.
> > 
> > 
> > Thanks,
> > Thomas
> 
>  
> -- 
>  Calvin Arndt
> (217) 778-8740
> car...@macksrecycling.com

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmana

Re: NetworkManager doesn't "Connect automatically"

[Thomas Haller]

On Mon, 2016-12-12 at 22:51 -0800, Chris Marusich wrote:


Hi,


> * If I check the "Make available to other users" check-box, then
>   NetworkManager DOES automatically connect to my wireless network.
>   However, my understanding is that this is only a workaround, and
> that
>   in fact NetworkManager should automatically connect when "Connect
>   automatically" is checked and "Make available to other users" is
> not
>   checked.  Please correct me if I'm mistaken.

This restricts the connection to a certain user, determined by the
connection.permissions property (see `nmcli connection show $NAME`
and `man nm-settings`).

This makes the connection only available, when a session for that user
exists. Is that user logged-in?

Did you build NetworkManager yourself? Is session-tracking properly
enabled to use systemd-logind or consolekit.



Starting NetworkManager with --debug is usually not that useful. The
most interesting thing it does is to turn on debug-logging, which you
can do  otherwise [1].



best,
Thomas


[1] 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=c90ec2d8c8a12b44c908bf7f80b23059c29f68fa

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

NetworkManager doesn't "Connect automatically"

[Chris Marusich]

Hi,

I'm trying to get NetworkManager working in GuixSD [1].  I've got it
working well enough so that I can manually connect to my wireless
network, which is great!  However, I've noticed that even when I've
checked the "Connect automatically" check-box [2], NetworkManager
doesn't automatically connect to my wireless network.  I expected it to
automatically connect.

I'd be very grateful if you could please help me figure out why
NetworkManager isn't automatically connecting.  This is the last issue
stopping the Guix project from using NetworkManager as the default
network management application in GuixSD.  I'm not subscribed to the
networkmanager-list@gnome.org email list, so please include me
explicitly when replying so that I'm sure to get your message.

I've done some investigation, but I can't figure out how to
NetworkManager automatically connect to my wireless network.  Here's
what I know:

* Even when I restart my computer, NetworkManager doesn't automatically
  connect.  This is true even though NetworkManager is running, and even
  though the "Connect automatically" check-box remains checked.

* The only suspicious message emitted by NetworkManager appears to be
  this one, which seems unrelated:

Dec 12 21:22:05 localhost NetworkManager[348]: 
[1481606525.8773] error poking ModemManager:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.ModemManager1 was not provided by any .service files

* I tried running NetworkManager with the "--debug" option, and I saw a
  lot of messages, but nothing jumped out at me (I'm not a
  NetworkManager developer though, so I'm not sure what constitutes
  normal or abnormal output).

* The "auto connect" setting for my wireless network is definitely being
  saved correctly.  I know this because I've observed messages from
  NetworkManager saying that it successfully saved the settings. In
  addition, when I invoke 'nmcli -f all c show', my wireless network is
  listed with a "yes" in the "AUTOCONNECT" column.

* If I check the "Make available to other users" check-box, then
  NetworkManager DOES automatically connect to my wireless network.
  However, my understanding is that this is only a workaround, and that
  in fact NetworkManager should automatically connect when "Connect
  automatically" is checked and "Make available to other users" is not
  checked.  Please correct me if I'm mistaken.

I've peeked at the NetworkManager code, but I don't have a lot of
experience with GNOME programs, so I was a little lost.  Hopefully with
your guidance, I can figure out what the problem is and fix it.

Here's information about my system; please let me know if you need more:

* NetworkManager version: 1.4.2.

* Linux version: Linux-Libre 4.8.12.

* GNOME version: The GNOME Control Center reports "3.0" (under "Details"
  in the System section), and the gnome-shell I'm using is GNOME Shell
  3.20.4.

* Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter
  (PCI-Express) (rev 01)

* Driver: ath9k, srcversion 9A67368256E430AA90B3557.

[1] https://www.gnu.org/software/guix/

[2] See attached screenshot.  This checkbox is in the "Identity" section
of my network's settings, as viewed via the "Networking" application in
the GNOME Control Center).

-- 
Chris


signature.asc
Description: PGP signature
___
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

[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
>
___
netw