Re: [PATCH] nm-hostname-manager.c: Use fqdn for persistent hostname on Slackware

[Robby Workman]

On Sun, 19 May 2019 10:55:52 +0200
Thomas Haller  wrote:

> On Sat, 2019-05-18 at 21:08 -0500, Robby Workman wrote:
> > The attached patch can be applied to master and 1.12 branches.
> > It's specific to the hostname handling on Slackware, so it 
> > shouldn't affect anyone else.
> >   
> 
> 
> 
> Merged to upstream.
> 
> Since the patch only affects Slackware, I assume you know what you
> want and handle compatiblity (preserve previous behavior) on upgrade
> as you see fit :)


Yep yep. :-)


> master:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e1df17e0acd14418608c2057ea4f49c31208053e
> nm-1-18:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=065e810424372b5969bbf910cf39fb6fd5d0ce9e
> nm-1-16:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6160888e61d525552c8bdd0b64bfe137570daa83
> nm-1-14:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fb8d30a3dd000edb8272e7a512181cb3998bee50
> nm-1-12:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17709225eca69ae06860c3543fff6a93c0d2daf6
> 
> [FYI] You only asked for "master" and "nm-1-12", but all patches on
> old-stable-branch "nm-1-$x" must also be present on "nm-1-$((x+2))").
> In other words, an older branch must be a strict subset of the patches
> of the next-newer branch. That's why there is this chain of cherry-
> picks. 


Yes, only nm-1-12 was mentioned because that's the only stable
branch in existence at the time the patch (and commit message)
was done. Sadly, I've been sitting on it this long. Thanks for
understanding the intent :-)

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

[PATCH] nm-hostname-manager.c: Use fqdn for persistent hostname on Slackware

[Robby Workman]

The attached patch can be applied to master and 1.12 branches.
It's specific to the hostname handling on Slackware, so it 
shouldn't affect anyone else.

-RW
>From 53676bdf67e1132df02b61416fe03027213afdcc Mon Sep 17 00:00:00 2001
From: "Patrick J. Volkerding" 
Date: Mon, 13 Nov 2017 00:17:38 -0600
Subject: [PATCH] nm-hostname-manager.c: Use fqdn for persistent hostname on
 Slackware

This will be the default for Slackware 15.0 and on.

This should be safe for both master and 1.12.x stable branch, as
no existing Slackware releases are expected to run NM-1.12.x or
later.

Signed-off-by: Robby Workman 
---
 src/nm-hostname-manager.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/src/nm-hostname-manager.c b/src/nm-hostname-manager.c
index 3fcd84826..db5611160 100644
--- a/src/nm-hostname-manager.c
+++ b/src/nm-hostname-manager.c
@@ -131,8 +131,7 @@ read_hostname_slackware (const char *path)
 {
 	gs_free char *contents = NULL;
 	gs_strfreev char **all_lines = NULL;
-	char *tmp;
-	guint i, j = 0;
+	guint i = 0;
 
 	if (!g_file_get_contents (path, &contents, NULL, NULL))
 		return NULL;
@@ -142,17 +141,7 @@ read_hostname_slackware (const char *path)
 		g_strstrip (all_lines[i]);
 		if (all_lines[i][0] == '#' || all_lines[i][0] == '\0')
 			continue;
-		tmp = &all_lines[i][0];
-		/* We only want up to the first '.' -- the rest of the */
-		/* fqdn is defined in /etc/hosts */
-		while (tmp[j] != '\0') {
-			if (tmp[j] == '.') {
-tmp[j] = '\0';
-break;
-			}
-			j++;
-		}
-		return g_shell_unquote (tmp, NULL);
+		return g_shell_unquote (&all_lines[i][0], NULL);
 	}
 	return NULL;
 }
-- 
2.21.0

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

Re: NetworkManager Hostname Not Being Used

[Robby Workman]

On Sat, 19 Aug 2017 03:17:31 +
"Soule, Michael"  wrote:

> The hostname configured for the interface network script is set. The
> proper hostname is shown when checking nmcli for the
> ipv4.dhcp-hostname option, the ipv4.dhcp-send-hostname, and when
> viewing the generated interface configuration for send host-name
> option. With everything set and "dhclient eth0" as the executed
> command the hostname is not sent to the DHCP server. When "dhclient
> eth0 -H SPACE01" is executed the DHCP server finds hostname.
> 
> 
> Anyone seen this behavior before?


There is a configure option (build time) to enable persistent
hostname support:
  --with-hostname-persist

It takes an argument, so be sure to look farther than just 
passing that flag to configure -- you'll have to see which
of the available options best suits you based on what they
do (which will require reading a bit of the configure script
itself).

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

Re: Running NM without systemd

[Robby Workman]

On Tue, 2 May 2017 16:32:55 +0100 (BST)
Colin Helliwell  wrote:

> > On 02 May 2017 at 16:23 Colin Helliwell
> >  wrote: 
> > > On 02 May 2017 at 16:07 Dan Williams  wrote:
> > > 
> > > On Tue, 2017-05-02 at 15:54 +0100, colin.helliw...@ln-systems.com
> > > wrote:
> > >   
> > > > I'm hoping to use NetworkManager on a system which doesn't have
> > > > systemd . So
> > > > far I'm hitting a few dependency problems but, before I start
> > > > trying to wade
> > > > through them I wanted to check that what I'm trying to achieve
> > > > *is* possible
> > > > 
> > > > *   or is systemd essential for NM?  
> > > 
> > > systemd should not be essential for NM. The various points of
> > > systemd integration (suspend/resume, hostname, session-tracking,
> > > journal, etc) should be either build-time or runtime selectable.
> > > 
> > > What ./configure or ./autogen arguments are you using? What
> > > errors are you getting?
> > > 
> > > Dan  
> > 
> > Thanks for confirming that, Dan. Gives me hope (if not
> > enthusiasm :S) for pushing on with the goal. As I say, I've only
> > made a very brief stab at it so far, building under Yocto. But the
> > first one I've hit is consolekit being missing [from the overall
> > Yocto image recipes]. Because this causes an an initial dependency
> > parsing error .  
> 
> Let me first work on paring down the Yocto recipe, then I'll have a
> better feel for what is *actually* missing


We've got NM in Slackware and no systemd, so yeah, it should work :)

This might be useful:
http://mirrors.slackware.com/slackware/slackware-current/source/n/NetworkManager/

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

[PATCH] Fixup Slackware persistent hostname setting

[Robby Workman]

On Slackware, the expectation is for output of "hostname" without options
to be the same as "hostname --short" whereas "hostname --fqdn" would be
used if the full hostname+domain is desired.

With NM-1.2.x, using persistent hostname setting and pulling it from
/etc/HOSTNAME, it gets set to the fqdn and this breaks some of our
expectations. It's not technically a bug, I suppose, but we like it
the way we expect it, so: see attached patch from Volkerding to fix
it.

This doesn't affect anything unless HOSTNAME_PERSIST_SLACKWARE is
defined, so nobody else should be affected at all.

Please apply to both master and 1.2 branch.

-RW
>From 66b29e0c4afb141134a6d9e959b749f024369e6a Mon Sep 17 00:00:00 2001
From: "Patrick J. Volkerding" 
Date: Fri, 22 Apr 2016 20:30:56 -0500
Subject: [PATCH] nm-settings.c: Fixup Slackware hostname setting

---
 src/settings/nm-settings.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/src/settings/nm-settings.c b/src/settings/nm-settings.c
index ee6e4f8..f68c5f4 100644
--- a/src/settings/nm-settings.c
+++ b/src/settings/nm-settings.c
@@ -500,6 +500,41 @@ read_hostname_gentoo (const char *path)
 }
 #endif
 
+#if defined(HOSTNAME_PERSIST_SLACKWARE)
+static gchar *
+read_hostname_slackware (const char *path)
+{
+	gchar *contents = NULL, *result = NULL, *tmp;
+	gchar **all_lines = NULL;
+	guint line_num, i, j = 0;
+
+	if (!g_file_get_contents (path, &contents, NULL, NULL))
+		return NULL;
+	all_lines = g_strsplit (contents, "\n", 0);
+	line_num = g_strv_length (all_lines);
+	for (i = 0; i < line_num; i++) {
+		g_strstrip (all_lines[i]);
+		if (all_lines[i][0] == '#' || all_lines[i][0] == '\0')
+			continue;
+		tmp = &all_lines[i][0];
+		/* We only want up to the first '.' -- the rest of the */
+		/* fqdn is defined in /etc/hosts */
+		while (tmp[j] != '\0') {
+			if (tmp[j] == '.') {
+tmp[j] = '\0';
+break;
+			}
+			j++;
+		}
+		result = g_shell_unquote (tmp, NULL);
+		break;
+	}
+	g_strfreev (all_lines);
+	g_free (contents);
+	return result;
+}
+#endif
+
 #if defined(HOSTNAME_PERSIST_SUSE)
 static gboolean
 hostname_is_dynamic (void)
@@ -547,6 +582,10 @@ nm_settings_get_hostname (NMSettings *self)
 	hostname = read_hostname_gentoo (priv->hostname.file);
 #else
 
+#if defined(HOSTNAME_PERSIST_SLACKWARE)
+	hostname = read_hostname_slackware (priv->hostname.file);
+#else
+
 #if defined(HOSTNAME_PERSIST_SUSE)
 	if (priv->hostname.dhcp_monitor_id && hostname_is_dynamic ())
 		return NULL;
@@ -555,6 +594,7 @@ nm_settings_get_hostname (NMSettings *self)
 		g_strchomp (hostname);
 
 #endif /* HOSTNAME_PERSIST_GENTOO */
+#endif /* HOSTNAME_PERSIST_SLACKWARE */
 
 out:
 	if (hostname && !hostname[0]) {
-- 
2.8.1

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

Re: ANN: NetworkManager 1.1.91 (1.2-beta2) released

[Robby Workman]

On Mon, 21 Mar 2016 12:48:35 +0100
Thomas Haller  wrote:

> On Mon, 2016-03-21 at 01:32 -0500, Robby Workman wrote:
> > On Tue, 1 Mar 2016 16:10:21 +0100
> > Beniamino Galvani  wrote:
> >   
> > > 
> > > I'm pleased to announce the release of the second beta version of
> > > NetworkManager 1.2 (1.1.91), and the same version of nm-applet,
> > > nm-connection-editor and VPN plugins.  
> > 
> > 3. This is related to #1. It seems as though maybe this is a
> >    configurable option based on the NEWS file contents, but without
> >    manual pages to reference, it's not clear. Essentially, we 
> >    (Slackware) depend on /etc/resolv.conf being a regular file due
> >    to the fact that everything else on our system (including our
> >    distro-specific networking scripts) manipulate it directly.
> >    Having NM replace it with a symlink to an NM-specific location
> >    is not desirable at all. Is there a way to configure NM to use
> >    /etc/resolv.conf directly instead?  
> 
> How is it supposed to work to have different components all writing to
> /etc/resolv.conf?


That's never been an issue for us. If a user configures networking with
our distro-specific network scripts, then those scripts manage resolv.conf.
If a user configures networking with wicd, then wicd manages resolv.conf.
If a user configures networking with NM, then NM manages resolv.conf.

> As it is now, NM will *always* update
> /var/run/NetworkManager/resolv.conf. 


Sure, as expected. 


> Then, if you configure NetworkManager.conf with
>   [main]
>   dns=none
> NM will do nothing further.


That's not what we want though - we *need* NM to manage resolv.conf.

 
> Otherwise, if /etc/resolv.conf doesn't exist or is a regular file, NM
> will symlink it to /var/run/NetworkManager/resolv.conf.
> If /etc/resolv.conf is already a symlink to another file, NM does
> again nothing (because it assumes some other component manages
> resolv.conf).
> See 
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager/nm-dns-manager.c?id=b907d90f612818050f4a88d7b3f30ffd19c4e929#n601


This is the problem. We want NM to manage resolv.conf, but we also want
it to leave resolv.conf manageable by other things too if e.g. the user
decides to use other things. As it stands, that won't be the case, because
/etc/resolv.conf will be a broken symlink.

I can certainly carry a distro-specific patch to restore the pre-1.2
behavior, but if it's feasible to implement another option upstream to
do that, it would be preferable.

-RW


pgp2gRfswUpOo.pgp
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ANN: NetworkManager 1.1.91 (1.2-beta2) released

[Robby Workman]

On Mon, 21 Mar 2016 01:32:01 -0500
Robby Workman  wrote:

> 1. /var/run/NetworkManager/ is created with mode 0700, which is
>a problem because non-root clients are unable to read the
>resolv.conf inside it. On this system, /var/run is a bind
>mount to /run, which is mode 0755 itself, so I don't think
>this problem is a result of any local configuration.


Well, this is only a problem immediately after package installation.
The installation process installs a /var/run/NetworkManger/ directory
with mode 0700, but if one is not present already, src/nm-main-utils.c
creates it with mode 0755. 

In src/Makefile.am, there's this line:
$(mkinstalldirs) -m 0700 $(DESTDIR)$(rundir)
and rundir is defined as:
rundir=$(runstatedir)/NetworkManager
and runstatedir is defined as $localstatedir/run in configure.ac,
so essentially it's happening in src/Makefile.am

Given that src/nm-main-utils.c creates NMRUNDIR if it doesn't
already exist, it seems the best option is to kill that invocation
of $(mkinstalldirs) in src/Makefile.am or modify it to use 0755
instead of 0700.  Patch attached to do the latter, but of course,
handle as you guys deem best.

-RW
From a75e59161882f9989e3ea76e5c0dc5d5f0f503df Mon Sep 17 00:00:00 2001
From: Robby Workman 
Date: Mon, 21 Mar 2016 01:51:08 -0500
Subject: [PATCH] src/Makefile.am: Create $rundir mode 0755 instead of 0700

Otherwise, $NMRUNDIR/resolv.conf isn't readable by unprivileged
users.
---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 353a31d..aee7eae 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -638,7 +638,7 @@ EXTRA_DIST = \
 rundir=$(runstatedir)/NetworkManager
 statedir=$(localstatedir)/lib/NetworkManager
 install-data-hook:
-	$(mkinstalldirs) -m 0700 $(DESTDIR)$(rundir)
+	$(mkinstalldirs) -m 0755 $(DESTDIR)$(rundir)
 	$(mkinstalldirs) -m 0700 $(DESTDIR)$(statedir)
 	$(mkinstalldirs) -m 0755 $(DESTDIR)$(pkglibdir)
 
-- 
2.7.4



pgpCinnOzJu5i.pgp
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ANN: NetworkManager 1.1.91 (1.2-beta2) released

[Robby Workman]

On Tue, 1 Mar 2016 16:10:21 +0100
Beniamino Galvani  wrote:

> I'm pleased to announce the release of the second beta version of
> NetworkManager 1.2 (1.1.91), and the same version of nm-applet,
> nm-connection-editor and VPN plugins.


I've just now gotten around to trying this out, and there are a 
few issues from my vantage point:

1. /var/run/NetworkManager/ is created with mode 0700, which is
   a problem because non-root clients are unable to read the
   resolv.conf inside it. On this system, /var/run is a bind
   mount to /run, which is mode 0755 itself, so I don't think
   this problem is a result of any local configuration.

2. Some manual pages were not installed, e.g. NetworkManager.conf(5),
   although nm-system-settings.conf(5), which directs users to the
   former, is installed. Looking at the Makefile.am, it appears that
   maybe these are autogenerated during tarball creating and shipped
   there as pregenerated files, but if so, that didn't happen with
   the 1.1.91 tarball.

3. This is related to #1. It seems as though maybe this is a
   configurable option based on the NEWS file contents, but without
   manual pages to reference, it's not clear. Essentially, we 
   (Slackware) depend on /etc/resolv.conf being a regular file due
   to the fact that everything else on our system (including our
   distro-specific networking scripts) manipulate it directly.
   Having NM replace it with a symlink to an NM-specific location
   is not desirable at all. Is there a way to configure NM to use
   /etc/resolv.conf directly instead?

-RW


pgpdlgiUSUTSG.pgp
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM attempts connecting to nonexistent AP

[Robby Workman]

On Mon, 04 Jan 2016 10:50:23 -0600
Dan Williams  wrote:

> On Thu, 2015-12-24 at 17:38 -0600, Robby Workman wrote:
> > On Thu, 11 Sep 2014 16:47:45 -0500
> > Dan Williams  wrote:
> >   
> > > On Wed, 2014-09-10 at 22:53 -0500, Robby Workman wrote:  
> > > > Summary: when resuming from sleep, NM attempts to connect to an
> > > > AP
> > > > that no longer exists.
> > > 
> > > Hmm, odd.  You could turn on debugging and enable the "wifi_scan"
> > > log
> > > domain to see what's going on at resume time.  NM should be
> > > throwing
> > > away the scan list on resume and requesting a new scan from
> > > wpa_supplicant, and all that should be reflected in the debug logs
> > > when the wifi_scan domain is enabled.  
> > 
> > 
> > I filed this away to debug later, and "later" never arrived :/
> > 
> > However, a user on LQ reported some dbus messages getting rejected
> > on suspend:
> > 
> > http://www.linuxquestions.org/questions/slackware-14/current-xfce4-po
> > wer-manager-error-messages-on-suspend-resume-4175562257/#post5468365
> > 
> > I'm seeing those here too:
> > 
> > Dec 22 17:13:54 liberty dbus[1162]: [system] Rejected send message,
> > 4 matched \
> >   rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
> >   comm="xfce4-power-manager ")
> > interface="org.freedesktop.NetworkManager" \
> >   member="Sleep" error name="(unset)" requested_reply="0" \
> >   destination="org.freedesktop.NetworkManager" \
> >   (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")
> > Dec 22 17:16:41 liberty dbus[1162]: [system] Rejected send message,
> > 4 matched \
> >   rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
> >   comm="xfce4-power-manager ")
> > interface="org.freedesktop.NetworkManager" \
> >   member="Sleep" error name="(unset)" requested_reply="0" \
> >   destination="org.freedesktop.NetworkManager" \
> >   (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")
> > 
> > I notice that /etc/dbus
> > -1/system.d/org.freedesktop.NetworkManager.conf says
> > that they are root-only functions:
> > 
> >   
> >> send_member="SetLogging"/>  
> >> send_member="Sleep"/>  
> > 
> > and if I change it to allow one of my groups, then I no longer get
> > those 
> > logged Rejected messages.
> > 
> > So... three questions here:
> > 
> > 1) is this possibly related to my original problem report? I'm not
> > able to
> > test it just yet and won't be until I go back to work after the
> > holidays.  
> 
> If NM doesn't get the Sleep() method call when suspending, then yes it
> won't clear the scan list and when the device is moved it may still
> see old APs for a bit.


Okay, that makes sense.


> > 2) is xfce4-power-manager supposed to be calling that Sleep here?
> > There is
> > a configure option to --(en|dis)able-network-manager that is
> > currently
> > enabled in our build, but if it should be disabled, we can fix
> > that.  
> 
> Whatever tells the kernel to suspend the system should be calling
> Sleep() on NM.  In my experience that's always been a root process
> (like upower or systemd or pm-utils), and since Sleep() has the
> capability to drastically change you networking, it was restricted to
> root-only.  I'm a bit surprised that xfce4-power-manager is trying to
> call Sleep() as the normal user, not root, since suspending the
> machine takes root privileges anyway.


Yeah, I'm not sure why that was implemented at all, really, but it
looked like something that should be enabled :/

 
> > 3) what is the expectation for that Sleep? What is supposed to call
> > it (or 
> > is *anything* supposed to be calling it from outside NM)?  
> 
> Whatever tells the kernel to suspend (which requires root) should also
> be telling NM to Sleep() (and wake).


Well, then this bug is solved, and it's definitely a downstream 
problem that *I* caused :/ Dammit.

Here's a long analysis from my perspective in case others somehow
can find it useful:

http://www.linuxquestions.org/questions/slackware-14/current-xfce4-power-manager-error-messages-on-suspend-resume-4175562257/#post5473183

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

Re: NM attempts connecting to nonexistent AP

[Robby Workman]

On Thu, 11 Sep 2014 16:47:45 -0500
Dan Williams  wrote:

> On Wed, 2014-09-10 at 22:53 -0500, Robby Workman wrote:
> > Summary: when resuming from sleep, NM attempts to connect to an AP
> > that no longer exists.  
> 
> Hmm, odd.  You could turn on debugging and enable the "wifi_scan" log
> domain to see what's going on at resume time.  NM should be throwing
> away the scan list on resume and requesting a new scan from
> wpa_supplicant, and all that should be reflected in the debug logs
> when the wifi_scan domain is enabled.


I filed this away to debug later, and "later" never arrived :/

However, a user on LQ reported some dbus messages getting rejected on
suspend:

http://www.linuxquestions.org/questions/slackware-14/current-xfce4-power-manager-error-messages-on-suspend-resume-4175562257/#post5468365

I'm seeing those here too:

Dec 22 17:13:54 liberty dbus[1162]: [system] Rejected send message, 4 matched \
  rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
  comm="xfce4-power-manager ") interface="org.freedesktop.NetworkManager" \
  member="Sleep" error name="(unset)" requested_reply="0" \
  destination="org.freedesktop.NetworkManager" \
  (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")
Dec 22 17:16:41 liberty dbus[1162]: [system] Rejected send message, 4 matched \
  rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
  comm="xfce4-power-manager ") interface="org.freedesktop.NetworkManager" \
  member="Sleep" error name="(unset)" requested_reply="0" \
  destination="org.freedesktop.NetworkManager" \
  (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")

I notice that /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf says
that they are root-only functions:

  
  
  

and if I change it to allow one of my groups, then I no longer get those 
logged Rejected messages.

So... three questions here:

1) is this possibly related to my original problem report? I'm not able to
test it just yet and won't be until I go back to work after the holidays.

2) is xfce4-power-manager supposed to be calling that Sleep here? There is
a configure option to --(en|dis)able-network-manager that is currently
enabled in our build, but if it should be disabled, we can fix that.

3) what is the expectation for that Sleep? What is supposed to call it (or 
is *anything* supposed to be calling it from outside NM)?

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

Re: Unmanaged device still showin in nm-applet UI

[Robby Workman]

On Tue, 08 Dec 2015 11:36:20 +0100
Thomas Haller  wrote:

> On Mon, 2015-12-07 at 18:32 -0600, Robby Workman wrote:
> 
> > However, if I tell nm-applet to Disconnect it, it does so. My
> > understanding
> > is that setting it as unmanaged would remove the possibility to do
> > this, 
> > which is exactly what I want. I can of course work around this by
> > setting it
> > as unmanaged in the NetworkManager.conf, and I'm not opposed to
> > doing that,
> > but it seems that this is a bug. 
> 
> 
> On 1.0 branch (which you are testing) this works as follows:
> 
> (1) configuring a device as unmanaged via UDev rule sets the device
> as "default-unmanaged".
> (2) configuring it as unmanaged via "keyfile.unmanaged-devices" in
>     NetworkManager.conf configures the device as "user-unmanaged".
> 
> 
> For (2), a "user-unmanaged" device cannot be activated later on. It
> was configured as unmanaged, you cannot activate it.
> 
> For (1), a "default-unmanaged" device still allows you to activate the
> device if you do an active user-action (like clicking on nm-applet).
> 
> 
> 
> On master/1.2, also "user-unmanaged" will behave like "default-
> unmanaged". Thus, you will be able to overwrite a user-configuration
> (from files or UDev) via a user-action from D-Bus (e.g. when clicking
> on nm-applet).
> 
> 
> Does that make sense?


Indeed it does. That's not as intuitive as I'd like, but if that's
the designed behavior, then what I'm experiencing is not a bug.


> As to why nm-applet behaves differently on whether to show you the
> device for (1) or (2), I don't know.


If "default-unmanaged" still allows NM to manipulate the interface via
user action, then I think it makes sense to show the interface in the
applet.


> It certainly should not and I don't think that nm-applet is even aware
> whether a device is unmanged via (1) or (2). The difference is mainly
> about whether you are able to still activate the device.


For the sake of clarity, both for me and perhaps others, the 1.0.x behavior
is as follows:

default-unmanaged is set by e.g. udev rules, and essentially tells NM to
leave the interface alone at NM startup, i.e. don't try to configure it
or manipulate any existing configuration. However, if the user explicitly
requests NM to manipulate the interface, then this is permissible.

user-unmanaged is set in NetworkManager.conf and essentially tells NM to
disallow *any* configuration/manipulation of the interface. 

Is that correct?

On a related note, if the 1.2.x branch makes user-unmanaged behave the 
same as default-unmanaged (which I think is a good change from a "be
more consistent with what unmanaged means" point of view), then what
are the chances of implementing a new keyfile option to hide interfaces
from the applet? I find myself accidentally clicking on the virbr0 
interface occasionally (my bluetooth mouse is a bit unpredictable with
clicks sometimes), so I like to hide that interface completely - there's
absolutely no reason (for me, at least) to have NM even care that the
interface exists.

-RW


pgpcY4bQJXSIz.pgp
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Unmanaged device still showin in nm-applet UI

[Robby Workman]

This was briefly mentioned on IRC to dcbw while working with another user
on a different (barely) related problem, and it spurred me to do some more
research.

The short-ish summary is that libvirt's virbr0 interface is not getting 
removed from e.g. nm-applet's list of connections. For the sake of clarity,
there's no real *problem* with this aside from inconsistency, as it no
longer shows up there when I define it as an unmanaged connection in
the [keyfile] section of NetworkManager.conf, and so it seems to me that
it should also be invisible there if it's marked as unmanaged by the 
system's udev rules.

First, the udev rule looks like this:
  [rworkman@liberty ~]$ grep veth /lib/udev/rules.d/85-nm-unmanaged.rules 
  ENV{ID_NET_DRIVER}=="veth", ENV{NM_UNMANAGED}="1"

While running "udevmonitor -p" in another terminal to see the results,
I run "udevadm trigger --action=change --subsystem-match=net" and see
the following in the udevmonitor terminal:

  UDEV  [653.071290] change   /devices/virtual/net/virbr0 (net)
  ACTION=change
  DEVPATH=/devices/virtual/net/virbr0
  DEVTYPE=bridge
  ID_MM_CANDIDATE=1
  ID_NET_DRIVER=bridge
  IFINDEX=4
  INTERFACE=virbr0
  NM_UNMANAGED=1
  SEQNUM=4356
  SUBSYSTEM=net
  USEC_INITIALIZED=908332
  
  UDEV  [653.072176] change   /devices/virtual/net/virbr0-nic (net)
  ACTION=change
  DEVPATH=/devices/virtual/net/virbr0-nic
  ID_MM_CANDIDATE=1
  ID_NET_DRIVER=tun
  IFINDEX=5
  INTERFACE=virbr0-nic
  NM_UNMANAGED=1
  SEQNUM=4357
  SUBSYSTEM=net
  USEC_INITIALIZED=907541

So it appears to be set correctly as unmanaged. 

However, if I tell nm-applet to Disconnect it, it does so. My understanding
is that setting it as unmanaged would remove the possibility to do this, 
which is exactly what I want. I can of course work around this by setting it
as unmanaged in the NetworkManager.conf, and I'm not opposed to doing that,
but it seems that this is a bug. 

Is there a problem on my system or something in NM? I'm on NM-1.0.8 and
nm-applet-1.0.8 on Slackware -current (devel) with 4.3.0 kernel, if that's
relevant.

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

Re: The short road to 1.0 (ANN: 0.995 released)

[Robby Workman]

On Wed, 17 Dec 2014 09:56:59 -0600
Dan Williams  wrote:

> On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote:
> > Hi everyone!
> > 
> > The 1.0 release is imminent.  We've been cleaning out the 1.0
> > tracker bug [1] for more than a month.  With your help we'll get
> > there next week!  A holiday present for everyone!
> 
> We're getting very close to 1.0, so this is last call for any
> showstopper bugs that you can find.  Thanks!


It's all working well here, best I can tell.

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

NM attempts connecting to nonexistent AP

[Robby Workman]

Summary: when resuming from sleep, NM attempts to connect to an AP that no 
longer exists.

This is a new problem as of 0.9.10, best I can tell - at least, I never 
observed this problem in any previous versions of NM.  Other things have 
changed along the way too, so I cannot say with certainty that NM is the 
culprit.

I don't connect to my phone's wifi tether often, but the only time I've ever 
experienced this problem is when connecting to it, and even then, only when the 
previous AP connected (at time of sleep) was my home AP.  Here's the fun part: 
my home AP's SSID is "RWnMW" and my phone's SSID is "rw" - I'm wondering if 
there's any chance that there's a comparison error somewhere wrt "RW" vs. "rw"

I'm not opposed to doing some more testing of this, but it's a bit difficult to 
do without either inconveniencing other home users (disconnecting RWnMW 
temporarily) or leaving my house to connect to my phone -- typically I'm at 
work when I do that, and being at work means I can't really devote time to 
testing non-work-related stuff.

Has anyone else experienced anything like this to perhaps offer more data 
points, or am I on my own with this?  :-)

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

Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman]

On Thu, 26 Jun 2014 15:49:20 -0500
Dan Williams  wrote:

> On Thu, 2014-06-26 at 14:58 -0500, Dan Williams wrote:
> > On Thu, 2014-06-26 at 12:44 -0500, Robby Workman wrote:
> > > On Thu, 26 Jun 2014 12:27:14 -0500
> > > Robby Workman  wrote:
> > > 
> > > > On Thu, 26 Jun 2014 10:16:41 -0500
> > > > Dan Williams  wrote:
> > > > 
> > > > > On Thu, 2014-06-26 at 01:19 -0500, Robby Workman wrote:
> > > > > > On Thu, 26 Jun 2014 07:55:58 +0200
> > > > > > Vincent Bernat  wrote:
> > > > > > 
> > > > > > >  ❦ 25 juin 2014 21:36 -0500, Robby Workman
> > > > > > >  :
> > > > > > > 
> > > > > > > > Okay, looks like that's ncurses, so let's link ncurses
> > > > > > > > too:
> > > > > > > >
> > > > > > > >   [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o
> > > > > > > > testrl -lreadline -lncurses testrl.c [rworkman@liberty
> > > > > > > > NetworkManager-0.9.9.98]$ strings testrl | grep readline
> > > > > > > > libreadline.so.6 readline
> > > > > > > >   readline
> > > > > > > >
> > > > > > > > Now, here's where I'm unclear.  If I add
> > > > > > > > LDFLAGS="-lnurses" to the configure environment, the
> > > > > > > > test passes and the complete build occurs successfully.
> > > > > > > > What's unclear is *why* that's needed -- is this an
> > > > > > > > omission in the NM sources (isn't nmtui a curses client
> > > > > > > > and thus ncurses should be linked?) or is something
> > > > > > > > different about how we (Slackware) build readline?
> > > > > > > 
> > > > > > > GNU readline requires linking to ncurses as well to get
> > > > > > > termcap symbols. Here is an autoconf recipe for that:
> > > > > > >  http://www.gnu.org/software/autoconf-archive/ax_lib_readline.html
> > > > > > 
> > > > > > If I'm reading that correctly, that snippet above tries to
> > > > > > link in curses if it encounters failure, so perhaps NM
> > > > > > should use it? Maybe not though - there's at least one
> > > > > > other project (nftables) where I've encountered the same
> > > > > > problem.
> > > > > > 
> > > > > > While digging around a bit after sending this, I found that
> > > > > > we add "--with-curses" to the readline configure to use it
> > > > > > instead of libtermcap, so it's *supposed* to be linked in
> > > > > > already and this would not be a problem.  However, for
> > > > > > whatever reason (it's not clear whether it's intentional or
> > > > > > not), the upstream sources don't use TERMCAP_LIBS (set to
> > > > > > "-lcurses" per the configure flag) when building the shared
> > > > > > library.  It appears that at least one distro solves that
> > > > > > by running 'make SHLIB_LIBS="-lcurses"' when building, but
> > > > > > I don't see where Fedora did that, so it's not clear at all
> > > > > > how they link curses (or even if they do, when means I
> > > > > > wonder how the configure test in OP works there). 
> > > > > > 
> > > > > > Assuming this is indeed a problem, it's been in Slackware
> > > > > > for years without causing any actual issues - the readline
> > > > > > library from 13.37 (released in April 2011) doesn't link
> > > > > > ncurses either, so I'm not convinced that we're doing
> > > > > > anything wrong (but I'm open to argument).
> > > > > 
> > > > > What does 'ldd' on your libreadline.so return?  Mine has:
> > > > > 
> > > > >   linux-vdso.so.1 =>  (0x7fff191fe000)
> > > > >   libtinfo.so.5 => /lib64/libtinfo.so.5
> > > > > (0x00347340) libc.so.6 => /lib64/libc.so.6
> > > > > (0x00345ac0) /lib64/ld-linux-x86-64.so.2
> > > > > (0x00345a80)
> > > > > 
> 

Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman]

On Thu, 26 Jun 2014 12:27:14 -0500
Robby Workman  wrote:

> On Thu, 26 Jun 2014 10:16:41 -0500
> Dan Williams  wrote:
> 
> > On Thu, 2014-06-26 at 01:19 -0500, Robby Workman wrote:
> > > On Thu, 26 Jun 2014 07:55:58 +0200
> > > Vincent Bernat  wrote:
> > > 
> > > >  ❦ 25 juin 2014 21:36 -0500, Robby Workman
> > > >  :
> > > > 
> > > > > Okay, looks like that's ncurses, so let's link ncurses too:
> > > > >
> > > > >   [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl
> > > > > -lreadline -lncurses testrl.c [rworkman@liberty
> > > > > NetworkManager-0.9.9.98]$ strings testrl | grep readline
> > > > > libreadline.so.6 readline
> > > > >   readline
> > > > >
> > > > > Now, here's where I'm unclear.  If I add LDFLAGS="-lnurses" to
> > > > > the configure environment, the test passes and the complete
> > > > > build occurs successfully. What's unclear is *why* that's
> > > > > needed -- is this an omission in the NM sources (isn't nmtui a
> > > > > curses client and thus ncurses should be linked?) or is
> > > > > something different about how we (Slackware) build readline?
> > > > 
> > > > GNU readline requires linking to ncurses as well to get termcap
> > > > symbols. Here is an autoconf recipe for that:
> > > >  http://www.gnu.org/software/autoconf-archive/ax_lib_readline.html
> > > 
> > > If I'm reading that correctly, that snippet above tries to link
> > > in curses if it encounters failure, so perhaps NM should use it?
> > > Maybe not though - there's at least one other project (nftables)
> > > where I've encountered the same problem.
> > > 
> > > While digging around a bit after sending this, I found that we add
> > > "--with-curses" to the readline configure to use it instead of 
> > > libtermcap, so it's *supposed* to be linked in already and this 
> > > would not be a problem.  However, for whatever reason (it's not
> > > clear whether it's intentional or not), the upstream sources don't
> > > use TERMCAP_LIBS (set to "-lcurses" per the configure flag) when
> > > building the shared library.  It appears that at least one distro
> > > solves that by running 'make SHLIB_LIBS="-lcurses"' when building,
> > > but I don't see where Fedora did that, so it's not clear at all 
> > > how they link curses (or even if they do, when means I wonder how
> > > the configure test in OP works there). 
> > > 
> > > Assuming this is indeed a problem, it's been in Slackware for
> > > years without causing any actual issues - the readline library
> > > from 13.37 (released in April 2011) doesn't link ncurses either,
> > > so I'm not convinced that we're doing anything wrong (but I'm
> > > open to argument).
> > 
> > What does 'ldd' on your libreadline.so return?  Mine has:
> > 
> > linux-vdso.so.1 =>  (0x7fff191fe000)
> > libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00347340)
> > libc.so.6 => /lib64/libc.so.6 (0x00345ac0)
> > /lib64/ld-linux-x86-64.so.2 (0x00345a80)
> > 
> > so at least the dynamic linker knows that libtinfo (provided by
> > ncurses) is required here, and should load that in for the configure
> > test program.
> 
> 
> # ldd /usr/lib64/libreadline.so.6
>   linux-vdso.so.1 (0x743ff000)
>   libc.so.6 => /lib64/libc.so.6 (0x7ffda6b37000)
>   /lib64/ld-linux-x86-64.so.2 (0x7ffda7179000)
> 
> I don't have any links to support this, but in talking with a couple
> of folks who've "been around a while," it seems that the lack of
> direct linking is intentional on the part of upstream readlinke --
> this allows the specific apps to use whichever (termcap / ncurses) is
> appropriate for them.  The autoconf stuff linked earlier seems to
> somewhat support that, but again, I don't have a definitive answer on
> it.


...and comment #1 seems to support that (but apparently the official
RH position changed since then):

https://bugzilla.redhat.com/show_bug.cgi?id=162023

Also, the INSTALL file in readline sources says this (no idea how I 
originally missed it): 

`--with-curses'
This tells readline that it can find the termcap library functions
(tgetent, et al.) in the curses library, rather than a separate
termcap library.  Readline uses the termcap functions, but does not
link with the termcap or curses library itself, allowing applications
which link with readline the to choose an appropriate library.
This option tells readline to link the example programs with the
curses library rather than libtermcap.

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

Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman]

On Thu, 26 Jun 2014 10:16:41 -0500
Dan Williams  wrote:

> On Thu, 2014-06-26 at 01:19 -0500, Robby Workman wrote:
> > On Thu, 26 Jun 2014 07:55:58 +0200
> > Vincent Bernat  wrote:
> > 
> > >  ❦ 25 juin 2014 21:36 -0500, Robby Workman  :
> > > 
> > > > Okay, looks like that's ncurses, so let's link ncurses too:
> > > >
> > > >   [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl
> > > > -lreadline -lncurses testrl.c [rworkman@liberty
> > > > NetworkManager-0.9.9.98]$ strings testrl | grep readline
> > > > libreadline.so.6 readline
> > > >   readline
> > > >
> > > > Now, here's where I'm unclear.  If I add LDFLAGS="-lnurses" to
> > > > the configure environment, the test passes and the complete
> > > > build occurs successfully. What's unclear is *why* that's
> > > > needed -- is this an omission in the NM sources (isn't nmtui a
> > > > curses client and thus ncurses should be linked?) or is
> > > > something different about how we (Slackware) build readline?
> > > 
> > > GNU readline requires linking to ncurses as well to get termcap
> > > symbols. Here is an autoconf recipe for that:
> > >  http://www.gnu.org/software/autoconf-archive/ax_lib_readline.html
> > 
> > If I'm reading that correctly, that snippet above tries to link
> > in curses if it encounters failure, so perhaps NM should use it?
> > Maybe not though - there's at least one other project (nftables)
> > where I've encountered the same problem.
> > 
> > While digging around a bit after sending this, I found that we add
> > "--with-curses" to the readline configure to use it instead of 
> > libtermcap, so it's *supposed* to be linked in already and this 
> > would not be a problem.  However, for whatever reason (it's not
> > clear whether it's intentional or not), the upstream sources don't
> > use TERMCAP_LIBS (set to "-lcurses" per the configure flag) when
> > building the shared library.  It appears that at least one distro
> > solves that by running 'make SHLIB_LIBS="-lcurses"' when building,
> > but I don't see where Fedora did that, so it's not clear at all 
> > how they link curses (or even if they do, when means I wonder how
> > the configure test in OP works there). 
> > 
> > Assuming this is indeed a problem, it's been in Slackware for years
> > without causing any actual issues - the readline library from 13.37
> > (released in April 2011) doesn't link ncurses either, so I'm not
> > convinced that we're doing anything wrong (but I'm open to
> > argument).
> 
> What does 'ldd' on your libreadline.so return?  Mine has:
> 
>   linux-vdso.so.1 =>  (0x7fff191fe000)
>   libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00347340)
>   libc.so.6 => /lib64/libc.so.6 (0x00345ac0)
>   /lib64/ld-linux-x86-64.so.2 (0x00345a80)
> 
> so at least the dynamic linker knows that libtinfo (provided by
> ncurses) is required here, and should load that in for the configure
> test program.


# ldd /usr/lib64/libreadline.so.6
linux-vdso.so.1 (0x743ff000)
libc.so.6 => /lib64/libc.so.6 (0x7ffda6b37000)
/lib64/ld-linux-x86-64.so.2 (0x7ffda7179000)

I don't have any links to support this, but in talking with a couple
of folks who've "been around a while," it seems that the lack of direct
linking is intentional on the part of upstream readlinke -- this allows
the specific apps to use whichever (termcap / ncurses) is appropriate
for them.  The autoconf stuff linked earlier seems to somewhat support
that, but again, I don't have a definitive answer on it.

I am fairly certain though that libreadline *directly* linked to either 
tinfo (which is actually ncurses) or termcap requires some sort of 
deviation from the upstream build options -- Fedora explicity links
tinfo, while Arch explicitly links ncurses.  Perhaps it's not a battle
worth fighting at this point, but I'd prefer not to see other projects
(e.g. NM) dependent upon distro-specific enhancements of upstream 
libraries.

That said, perhaps the path of least resistance is to just explicitly
link ncurses with our readline library.  That's not my decision though :)

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

Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman]

On Thu, 26 Jun 2014 07:55:58 +0200
Vincent Bernat  wrote:

>  ❦ 25 juin 2014 21:36 -0500, Robby Workman  :
> 
> > Okay, looks like that's ncurses, so let's link ncurses too:
> >
> >   [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl
> > -lreadline -lncurses testrl.c [rworkman@liberty
> > NetworkManager-0.9.9.98]$ strings testrl | grep readline
> > libreadline.so.6 readline
> >   readline
> >
> > Now, here's where I'm unclear.  If I add LDFLAGS="-lnurses" to the
> > configure environment, the test passes and the complete build
> > occurs successfully. What's unclear is *why* that's needed -- is
> > this an omission in the NM sources (isn't nmtui a curses client and
> > thus ncurses should be linked?) or is something different about how
> > we (Slackware) build readline?
> 
> GNU readline requires linking to ncurses as well to get termcap
> symbols. Here is an autoconf recipe for that:
>  http://www.gnu.org/software/autoconf-archive/ax_lib_readline.html

If I'm reading that correctly, that snippet above tries to link
in curses if it encounters failure, so perhaps NM should use it?
Maybe not though - there's at least one other project (nftables)
where I've encountered the same problem.

While digging around a bit after sending this, I found that we add
"--with-curses" to the readline configure to use it instead of 
libtermcap, so it's *supposed* to be linked in already and this 
would not be a problem.  However, for whatever reason (it's not
clear whether it's intentional or not), the upstream sources don't
use TERMCAP_LIBS (set to "-lcurses" per the configure flag) when
building the shared library.  It appears that at least one distro
solves that by running 'make SHLIB_LIBS="-lcurses"' when building,
but I don't see where Fedora did that, so it's not clear at all 
how they link curses (or even if they do, when means I wonder how
the configure test in OP works there). 

Assuming this is indeed a problem, it's been in Slackware for years
without causing any actual issues - the readline library from 13.37
(released in April 2011) doesn't link ncurses either, so I'm not
convinced that we're doing anything wrong (but I'm open to argument).

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

Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released

[Robby Workman]

On Fri, 20 Jun 2014 21:55:24 -0500
Dan Williams  wrote:

> We're planning the final 0.9.10 release for later this week, so get
> your party hats ready!


If I understand correctly, readline is only needed if nmtui is
enabled.  If that's correct, then there's probably a bug in the
build system, as it's unconditionally checking for readline.

That said, I *want* nmtui, so that's not really a concern to me
personally - I'm having a different problem.  

  ./configure
  ...
  checking for readline in -lreadline... no
  configure: error: readline library is required

readline *is* installed though - I've got readline-6.3 and the 
corresponding libreadline.so.6 ; I also tried on another system
(also Slackware) with libreadline.so.5 (readline-5.2) and it fails
the same way.  I don't know autotools well at all, but it looks 
like this is how configure checks for readline support:

  [rworkman@liberty NetworkManager-0.9.9.98]$ cat testrl.c 
  #ifdef __cplusplus
  extern "C"
  #endif
  char readline ();
  int
  main ()
  {
  return readline ();
;
return 0;
  }

So... let's see what happens:
  
  [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl -lreadline testrl.c 
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tputs'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tgoto'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tgetflag'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `UP'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tgetent'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tgetnum'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `PC'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `tgetstr'
  /usr/lib64/gcc/x86_64-slackware-linux/4.8.3/../../../../lib64/libreadline.so: 
undefined reference to `BC'
  collect2: error: ld returned 1 exit status

Okay, looks like that's ncurses, so let's link ncurses too:

  [rworkman@liberty NetworkManager-0.9.9.98]$ gcc -o testrl -lreadline 
-lncurses testrl.c 
  [rworkman@liberty NetworkManager-0.9.9.98]$ strings testrl | grep readline
  libreadline.so.6
  readline
  readline

Now, here's where I'm unclear.  If I add LDFLAGS="-lnurses" to the configure
environment, the test passes and the complete build occurs successfully.
What's unclear is *why* that's needed -- is this an omission in the NM
sources (isn't nmtui a curses client and thus ncurses should be linked?)
or is something different about how we (Slackware) build readline?

On a related note, assuming ncurses *should* be linked in too, then 
should we uses ncursesw instead of ncurses?

-RW

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

Re: [PATCH] Allow NetworkManager-SSH plugin

[Robby Workman]

On Thu, 21 Mar 2013 10:54:59 -0500
Dan Williams  wrote:

> On Thu, 2013-03-21 at 11:13 +1100, Dan Fruehauf wrote:
> > Thanks for that guys.
> > 
> > Sounds like the best thing to do is to actually allow the installed
> > VPN plugins to control that configuration. i.e. every VPN plugin
> > can provide a DBUS file that will allow itself to communicate with
> > NetworkManager. However with the one file - one policy type of
> > configuration in dbus it'll be rather difficult.
> > 
> > On the other hand, try to count all the "famous" VPN protocols you
> > know today, there aren't that many. I don't expect 500 plugins
> > popping up tomorrow, so perhaps keeping it the way it is is not too
> > bad and we can have our efforts invested in more important things.
> > 
> > But that's just my humble opinion.
> 
> Yeah, best thing to do is probably to have the plugins themselves
> provide the configuration.  However, I can't recall the historic
> reasons we didn't do that, possibly upgrade-related, though the note
> there says:
> 
> 
> 
> This was a huge bug back in the day, and i'm not 100% confident that
> it's actually been solved in the bus daemon yet.  If it was, then we
> could get rid of this block.


I'm pretty sure this isn't needed any more.  I may have some details
wrong, but if my memory serves me correctly, the user would have to
reload the messagebus config (have it reread its configuration) after
adding a new file in $sysconfdir/etc/dbus-1/system.d/ -- these days,
that directory has an inotify watch or some such on it, and the
daemon automatically reloads its config when a new file appears in
that directory. 

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

Re: Dropping support for libnl1 and libnl2?

[Robby Workman]

On Thu, 06 Dec 2012 14:29:26 -0600
Dan Williams  wrote:

> On Thu, 2012-12-06 at 13:57 -0600, Robby Workman wrote:
> > On Thu, 06 Dec 2012 12:11:49 -0600
> > Dan Williams  wrote:
> > 
> > > All the major distros appear to have been shipping libnl3.x for
> > > quite a while already, and it's becoming increasingly difficult
> > > to support libnl1.x and 2.x with some of the newer features that
> > > are being added to NM like bridging, bonding, vlan, etc.
> > > 
> > > So, given that libnl 3.2.7 has been out for almost a year
> > > (2012-01-20), and most major distros are packaging it (Ubuntu,
> > > OpenSUSE, Debian, Fedora, Gentoo, Arch), would anyone object to
> > > libnl
> > > >= 3.2.7 as a build requirement for the next release of
> > > >NetworkManager?
> > 
> > 
> > We've got 3.2.11 in the last stable Slackware, so sure, that's fine
> > with us, even if we're not "major" enough to warrant concern ;-)
> 
> Aww, not true.  Thanks for the update; by "major" I really mean those
> that don't have derivatives.  eg Mint would be a derivative distro,
> but Slackware would be a major one.


I think you meant s,don't have,aren't, but yeah.  Even so, no offense
was taken - my response was completely good-natured.  :-)

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

Re: Dropping support for libnl1 and libnl2?

[Robby Workman]

On Thu, 06 Dec 2012 12:11:49 -0600
Dan Williams  wrote:

> All the major distros appear to have been shipping libnl3.x for quite
> a while already, and it's becoming increasingly difficult to support
> libnl1.x and 2.x with some of the newer features that are being added
> to NM like bridging, bonding, vlan, etc.
> 
> So, given that libnl 3.2.7 has been out for almost a year
> (2012-01-20), and most major distros are packaging it (Ubuntu,
> OpenSUSE, Debian, Fedora, Gentoo, Arch), would anyone object to libnl
> >= 3.2.7 as a build requirement for the next release of
> >NetworkManager?


We've got 3.2.11 in the last stable Slackware, so sure, that's fine
with us, even if we're not "major" enough to warrant concern ;-)

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

Re: Please take me off the mailing list. Thank you, Clark Webb nyca...@gmail.com

[Robby Workman]

On Thu, 30 Aug 2012 16:57:05 -0400
NY CAJUN  wrote:

Take yourself off the list.  That link down at the bottom of
each list mail has an unsubscribe link.  Use it.  It's okay
to be self-sufficient.

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

Re: Problem automatically unmounting VPN shares

[Robby Workman]

On Sat, 28 Jul 2012 18:18:11 -0300
"Lamarque V. Souza"  wrote:

> Em Saturday 28 July 2012, Robby Workman escreveu:
> > 
> > Peter Rockett  wrote:
> > > 
> > > ... snipped ...
> > > 
> > > The weird thing is that, if I delete the dispatcher script above,
> > > connect to VPN, mount the drive manually in a terminal, then
> > > umount it manually, and disconnect from VPN, everything is fine
> > > and as it should be. So it seems like the dispatcher daemon is
> > > making a mess of running the unmount... but not the mount.
> > > 
> > > Any ideas where to go with this?
> 
>   What is happening is that NetworkManager is taking down the
> connection before running the dispatch script. That is a known
> problem. 


Ah, I wasn't aware of that.  I don't know if there's a reason for it
to occur that way, so I can't say for sure, but that seems less than
ideal...


> > See mount(8), particularly the -l and -f options:
> > 
> >   -f  Force unmount (in case of an unreachable NFS system).
> >   -l  Lazy unmount. Detach the filesystem from the filesystem
> > hierarchy now, and cleanup all references to the
> > filesystem as soon as it is not busy anymore.
> 
>   Those options can prevent other programs from hanging. But
> keep in mind that nfs clients maintain a local cache that may not
> have been sync'ed to the server by the time the connection is taken
> down. Files can be corrupted because of that though I have never seen
> that happening.


I've never seen corruption, but I have had some occasions with the
server having stale info (basically, the local cache never got synced
to the server, it seems)...

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

Re: Problem automatically unmounting VPN shares

[Robby Workman]

On Sat, 28 Jul 2012 12:50:13 +0100
Peter Rockett  wrote:

> Hi
> 
> I am trying to automatically mount and unmount a share at my office.
> I have a script in /etc/NetworkManager/dispatch.d which runs along
> the lines:
> 
> #!/bin/bash
> 
> case "$2" in
>  vpn-up)
>  exec mount blah-blah-blah
>  ;;
>  vpn-down)
>  exec umount blah-blah-blah
>  ;;
> esac
> 
> which mounts the share in my home directory (on Ubuntu 11.10 +
> Network Manager v. 0.9.1.90). I swear this all worked fine when I set
> it up in 2010. But some time in the intervening period it has broken.
> (I am infrequent user of VPN since I got DropBox!) I have also
> upgraded from Natty to Oneiric in the meantime...
> 
> Now, VPN connects fine, the remote share is mounted OK. I can
> see/access all the remote files. But when I disconnect from VPN, the
> running of the umount seems to go very wrong. After disconnect, if I
> open a terminal and type "ls" to list the contents of my home
> directory (the mount point), the "ls" command hangs. (Nautilus also
> hangs - either it won't start or, if it was running already, it
> hangs.) Everything else in the OS seems to work OK. It seems for all
> the world as if the mount point is getting screwed and the only
> recovery is to restart (in which the shutdown takes much longer than
> usual).
> 
> The weird thing is that, if I delete the dispatcher script above, 
> connect to VPN, mount the drive manually in a terminal, then umount
> it manually, and disconnect from VPN, everything is fine and as it
> should be. So it seems like the dispatcher daemon is making a mess of
> running the unmount... but not the mount.
> 
> Any ideas where to go with this?


See mount(8), particularly the -l and -f options:

  -f  Force unmount (in case of an unreachable NFS system).
  -l  Lazy unmount. Detach the filesystem from the filesystem 
hierarchy now, and cleanup all references to the
filesystem as soon as it is not busy anymore.

-RW

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

[PATCH] Trivial: fix missing "@" in .pc file template

[Robby Workman]

Attached patch is trivial fix to mobile-broadband-provider-info
in the pkgconfig file:  @libdir  --> @libdir@

-RW
From d4b0ba4ca7e3cd5054476468303d67c87b6bfb1f Mon Sep 17 00:00:00 2001
From: Robby Workman 
Date: Thu, 21 Jun 2012 08:55:20 -0500
Subject: [PATCH] Trivial: fix missing "@" in .pc file template

---
 mobile-broadband-provider-info.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mobile-broadband-provider-info.pc.in b/mobile-broadband-provider-info.pc.in
index 51cd0fd..5898171 100644
--- a/mobile-broadband-provider-info.pc.in
+++ b/mobile-broadband-provider-info.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
 exec_prefix=@exec_prefix@
-libdir=@libdir
+libdir=@libdir@
 datarootdir = @datarootdir@
 pkgdatadir=${datarootdir}/@PACKAGE@
 includedir=@includedir@
-- 
1.7.11

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

Re: connect to internet via android phone as usb-modem

[Robby Workman]

On Wed, 16 Mar 2011 22:53:34 -0500
Robby Workman  wrote:

> For whatever reason, /usr/local/bin/easytether is not getting 
> started, so I still have to run that manually.  I've edited 
> the sample udev rule with correct attributes for my device,
> so I don't know what's going on.  No big deal - I'll mess with
> that later...


Well, I had to invoke a wrapper script:

  root@liberty:~# cat /etc/udev/rules.d/99-easytether.rules 
  ACTION=="add", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="22b8", \
ATTR{idProduct}=="2d66", \
RUN+="/usr/local/bin/MB300 &", \
ENV{REMOVE_CMD}="/bin/killall easytether 2>/dev/null"

  root@liberty:~# cat /usr/local/bin/MB300 
  #!/bin/sh
  /usr/local/bin/easytether connect &
 
The REMOVE_CMD probably isn't necessary, but I left it there anyway :)

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

Re: connect to internet via android phone as usb-modem

[Robby Workman]

On Wed, 16 Mar 2011 23:16:43 +0100
Torsten Spindler  wrote:

> On Wed, 2011-03-16 at 15:50 -0500, Dan Williams wrote:
> ...
> > That said, the best way to go about this is likely to use udev
> > scripts to initially create the easytether0 interface, and then we
> > could add some custom code to NM to recognize the easytether0
> > interface as a normal ethernet device and run DHCP on it.  That
> > wouldn't be *too* hard, probably < 30 lines of code.  It would
> > involve using g_str_has_prefix() looking for easytether in the
> > nm-udev-manager.c code, and if so, bypassing some of the
> > udev /sysfs hierarchy checks that determine hardware relationships
> > and device attributes like driver and description.  That's not
> > something we should be doing for most "virtual" network interfaces,
> > but it's probably OK in the case of easytether.
> 
> Thanks for the advice where to patch network manager. Attached is a
> very first version, plus a basic udev rule for a Motorola Milestone
> and connect script. It works fine on my Ubuntu 10.04 machine right
> now, though it could use some polishing.


Minor typo in "ignorning device driver not found"  :)

Here's what shows in syslog:
   /sys/devices/virtual/net/easytether0: couldn't determine device 
driver; ignoring...
   easytether0: is an easytether device, ignorning device driver not found
   Ignoring driver = NULL for easytether
Perhaps have the code that spawns the first warning not do that if it's an 
easytether device..

Anyway, the NetworkManager side of this works fine - thanks!
For whatever reason, /usr/local/bin/easytether is not getting 
started, so I still have to run that manually.  I've edited 
the sample udev rule with correct attributes for my device,
so I don't know what's going on.  No big deal - I'll mess with
that later...

As an aside, it would be nice if the mobile-stream folks (authors
of easytether) would address the missing sysfs bits, and perhaps 
make the easytether client daemonize properly -- currently it grabs
the console regardless of whether it's backgrounded or not.

I mailed them quite some time ago asking for an ARM client, and
they indicated that the plan was to eventually open-source the
linux client.  Perhaps some encouragement from here will help :-)

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

Re: bug report - samsung n150 netbook - after update not able to connect 3G broadband + debug

[Robby Workman]

On Fri, 18 Feb 2011 00:16:06 +0100
Daniel Duris  wrote:

> No response? This is how you treat users reporting *major* bugs? Nice,
> indeed.


No, only the ones who appear to be pretentious assholes with a
sense of entitlement.

Sarcasm aside, you should check with your distribution first;
chances are, something went wrong in the "complete update,"
and the distro guys are most qualified to determine what that
something might be.

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

Re: Strange error in NetworkManager 0.8.2

[Robby Workman]

On Sat, 15 Jan 2011 09:30:19 +0300
Andrey Borzenkov  wrote:

> On Sat, Jan 15, 2011 at 12:45 AM, Robert Gabriel
>  wrote:
> > On Fri, Jan 14, 2011 at 22:41, Dan Williams  wrote:
> >> On Fri, 2011-01-14 at 20:21 +0100, Robert Gabriel wrote:
> >>> Hello,
> >>>  Im getting the below errors once in a while, mostly when shutting
> >>> down the system or NetworkManager:
> >>
> >> This is suppressed in git and should be part of NM 0.8.4.  It's
> >> because an applet shut down earlier than NM did.  The message is
> >> harmless, but annoying.
> >>
> >> Dan
> >
> > But it's normal for networkmanager-applet to shutdown earlier. Is
> > there a patch for this?
> > If not, if I clone the current git repository for
> > networkmanager-applet will it fix the issue?
> > Or I actually need to pull NetworkManager?
> >
> 
> You need this commit from NM:
> 
> commit 83e02840b5ce1cf8c122cc70918ddd57396c91db
> Author: Dan Williams 
> Date:   Tue Nov 23 22:17:21 2010 -0600
> 
> core: suppress error message when user settings service is not
> active
> 
> Don't bother trying to initialize the user settings proxy when it
> isn't even active.  Would trigger a warning to syslog if PolicyKit
> permissions changed via changes to /usr/share/polkit-1/actions/.


Robert,

That patch (among others) is included in the build I maintain
at SlackBuilds.org - you might consider tracking that and save
yourself some effort :-)

http://slackbuilds.org/repository/13.1/network/NetworkManager/

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

[PATCH] Slackware init script fixes

[Robby Workman]

Attached are two patches for the Slackware init script

0001: Remove HAL requirement in rc.networkmanger
0002: Add a "sleep 2" in the restart() function

-RW

From e55d67e40e8f3aaa6f2816b74f74bca33d99a831 Mon Sep 17 00:00:00 2001
From: Robby Workman 
Date: Wed, 22 Dec 2010 08:51:30 -0600
Subject: [PATCH 1/2] initscript/Slackware/rc.networkmanager.in: Remove HAL requirement

NM no longer requires HAL to work, so let's remove that from the
provide init script for Slackware
---
 initscript/Slackware/rc.networkmanager.in |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/initscript/Slackware/rc.networkmanager.in b/initscript/Slackware/rc.networkmanager.in
index 0489038..35c42a4 100644
--- a/initscript/Slackware/rc.networkmanager.in
+++ b/initscript/Slackware/rc.networkmanager.in
@@ -27,11 +27,6 @@ nm_start()
 return
 	fi
   
-	if [ "`pgrep hald`" = "" ]; then
-	 echo "HAL must be running to start NetworkManager"
-	 return
-	fi
- 
   # Just in case the pidfile is still there, we may need to nuke it.
   if [ -e "$PIDFILE" ]; then
 rm -f $PIDFILE
-- 
1.7.3.4

From faf8237b11e148095a66b6b837b0d822831e3fe1 Mon Sep 17 00:00:00 2001
From: Robby Workman 
Date: Wed, 22 Dec 2010 08:52:29 -0600
Subject: [PATCH 2/2] initscript/Slackware/rc.networkmanager.in: Add sleep in restart()

The restart() function almost never works here - perhaps some part
of NM takes a bit too long to stop() and then blocks the start()
operation - but "sleep 2" between them makes everything fine.
---
 initscript/Slackware/rc.networkmanager.in |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/initscript/Slackware/rc.networkmanager.in b/initscript/Slackware/rc.networkmanager.in
index 35c42a4..6eed87e 100644
--- a/initscript/Slackware/rc.networkmanager.in
+++ b/initscript/Slackware/rc.networkmanager.in
@@ -62,6 +62,7 @@ nm_stop()
 nm_restart()
 {
   nm_stop
+  sleep 2
   nm_start
 }
 
-- 
1.7.3.4

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

Re: No user settings service available

[Robby Workman]

On Thu, 16 Dec 2010 19:01:10 -0600
alkos333  wrote:

> After updating to 0.8.2, NetworkManager pretty much stopped working
> entirely.  When I plug in the ethernet cord or my the phone via usb
> (with dhcpcd server running on it), nothing happens - NetworkManager
> shows that they are plugged in, but doesn't conntect to them
> automatically like it used to.
> 
> When I try to connect to a wireless signal using the nm-applet,
> nothing happens either and I get the following in the console:
> 
>  activate_connection_cb(): Connection activation failed: No user
> settings service available.
> 
> I'm running Slackware64 13.1 here.  Anybody else ran into similar
> issues?


Well...

There's this commit in the NM_0_8 branch:

  commit 5a3b773cd520aaf0b615880a6565ca2ca27612af
  Author: Dan Williams 
  Date:   Tue Aug 10 15:46:33 2010 -0500
  
  libnm-glib: better handling of missing user settings service
  
  If it's not running or we can't spawn it (it's not supposed to be
  autospawned anyway) we should just ignore the error and poke clients
  that we've tried and failed to get user settings instead of warning
  with an annoying message.

However, I don't see how that would muck up anything.

More importantly, I'm seeing this locally:

  Dec 17 19:43:43 liberty NetworkManager[2209]:  [nm-manager.c:1368] 
user_proxy_init(): could not init user settings proxy: (3) Could not get owner 
of name 'org.freedesktop.NetworkManagerUserSettings': no such name

Everything is working fine for me though, but I have all of my 
connections configured to be system-wide, so maybe that's why.


> The following page:
> http://live.gnome.org/NetworkManager/RemovingUserSettings  explains
> the removal of user settings service, but does not explain anything
> specifically.


I think that page is an account of what's planned for 0.9, so not
relevant here.

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

NM and pm-utils sleep hook

[Robby Workman]

Hi Dan, 

Re this commit:

  commit 8310593ce48a85aa82d4a2adf805662f2b019ef5
  Author: Dan Williams 
  Date:   Fri Oct 15 10:28:38 2010 -0500
  
  core: ignore authorization for sleep/wake requests (but restrict to root) 
(rh #638640)
  
  Everyone uses pm-utils still for sleep/wake support, and that's
  traditionally how NM was put to sleep and woken up.  But pm-utils
  uses dbus-send without --print-reply so dbus-send quits immediately
  after sending the message.  That doesn't give NM enough time to
  get the senders UID and thus validate the request, so the request
  gets denied, and sometimes NM stays asleep after the machine is
  woken up.
  
  Instead, don't get the sender's UID and try to authorize it, but
  just let the request go through.  Rely on D-Bus permissions to
  make sure that only root can call sleep/wake methods.

Why not have NM ship the pm-utils sleep hook instead of having to
work around what they ship?  Last I checked, NM is the only app
for which upstream pm-utils ships a sleep hook, and Victor (the
lead dev there) was hoping to have apps ship their own so that
he didn't have to maintain stuff that he may not be familiar with.

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

Re: Persistent hostname issues

[Robby Workman]

On Mon, 08 Nov 2010 14:02:38 +
Roy Marples  wrote:

> Hi
> 
> I'm not on the list, but was CC'ed, so direct responses please.
> I'm also upstream author for dhcpcd.
> 
> On 08/11/2010 13:45, Ozan Çağlayan wrote:
> > I'm really confused how the hostname things are handled in NM. I'm
> > trying to understand looking through the code but I'm completely
> > lost as there are methods which wraps methods which wraps methods,
> > etc.
> >
> > Here's the setup:
> >
> > * NetworkManager 0.8.1
> > * DHCP client is dhcpcd 5.2.7
> > * plugin used: only keyfile
> > * All hostname related hooks are removed from dhcpcd package
> >
> > Problem:
> >
> > There are user reports which complains that the machine hostname
> > changes once the machine acquires an IP from DHCP. Same reports
> > tells that removing option host_name from /etc/dhcpcd.conf fixes
> > the issue.
> 
> As no hooks in dhcpcd are used (NM overrides them), dhcpcd itself
> won't set the hostname. However, the default dhcpcd.conf does request
> the hostname which NM can in turn use to set the hostname. The DHCP
> server can also send options which a DHCP client did not request,
> like hostname. Again, dhcpcd offers an option to trim these from the
> message before processing.
> 
> nooption hostname
> 
> in dhcpcd.conf should fix that so NM will never see a hostname from
> DHCP.


On the other hand, if your goal is to have a persistent hostname
that never changes, then you want something like this:

  [rwork...@liberty ~]$ cat /etc/NetworkManager/NetworkManager.conf 
  # /etc/NetworkManager/nm-system-settings.conf
  #
  # See NetworkManager.conf(5) for more information on this file
  
  [main]
  plugins=keyfile
  dhcp=dhcpcd
  
  [keyfile]
  hostname=liberty

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

Re: NetworkManager Won't Save Passwords

[Robby Workman]

On Mon, 13 Sep 2010 01:05:20 -0500
alkos333  wrote:

> I'm running Slackware64 13.1 and NetworkManager 0.8.1, have
> gnome-keyring installed and started along with WM, but prior to
> nm-applet.
> 
> I'm starting my fluxbox session using ck-launch-session for HAL, etc.
> 
> I've done plenty of Googling and one solution people suggested was
> making sure gnome-keyring-daemon was running before starting
> nm-applet, which I've done, but it didn't help.
> 
> I'm stuck at this point.  Any points/suggestions would be greatly
> appreciated.  Thank you so much in advance.


Does it work in a desktop environment (e.g. kde or xfce)?

It's fine here in xfce, fwiw.

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

Re: Changes between NetworkManager 0.8 and 0.8.1

[Robby Workman]

On Fri, 20 Aug 2010 13:33:52 -0500
Dan Williams  wrote:

> On Fri, 2010-08-13 at 19:22 -0500, Robby Workman wrote:
> > On Fri, 13 Aug 2010 19:10:16 -0500
> > Dan Williams  wrote:
> > 
> > > On Fri, 2010-08-13 at 18:58 -0500, Robby Workman wrote:
> > > > On Wed, 11 Aug 2010 18:41:01 -0500
> > > > Dan Williams  wrote:
> > > > 
> > > > > You can always select your preferred DHCP client using 
> > > > > dhcp-client=[dhclient|dhcpcd] in the [main] section of 
> > > > > the config file too though.
> > > > 
> > > > 
> > > > Maybe I misunderstood, but this should work, right?
> > > > 
> > > >   [rwork...@liberty ~]$
> > > > cat /etc/NetworkManager/nm-system-settings.conf [main]
> > > >   plugins=keyfile
> > > >   dhcp-client=dhcpcd
> > > >   
> > > >   [keyfile]
> > > >   hostname=liberty
> > > > 
> > > > If the answer is yes, then one of us has a problem 
> > > > (that's a good-natured comment - no insult intended) :-)
> > > 
> > > Yeah, that should work...  if not then yeah, there's a problem :)
> > > 
> > 
> > 
> > Well, here's what I see in ps output:
> > 
> > /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action
> > -pf /var/run/dhclient-wlan0.pid
> > -lf 
> > /var/lib/dhclient/dhclient-93af950b-1619-4ce9-a172-645147565970-wlan0.lease
> > -cf /var/run/nm-dhclient-wlan0.conf wlan0
> > 
> > This is after a reboot (to ensure that both the daemon and 
> > nm-applet were started fresh).  I suppose it's possible that
> > my NM configure arguments could be at fault, so here they are:
> > 
> > ./configure \
> >   --prefix=/usr \
> >   --libdir=/usr/lib${LIBDIRSUFFIX} \
> >   --sysconfdir=/etc \
> >   --localstatedir=/var \
> >   --mandir=/usr/man \
> >   --docdir=/usr/doc/$PRGNAM-$VERSION \
> >   --with-pppd-plugin-dir=/usr/lib${LIBDIRSUFFIX}/pppd/2.4.5 \
> >   --with-crypto=gnutls \
> >   --without-resolvconf \
> >   --with-dhcpcd=/sbin/dhcpcd \
> >   --with-dhclient=yes \
> >   --build=$ARCH-slackware-linux
> > 
> > Where should I begin looking to see what's going on here?  
> 
> So I lied earlier.  The key is:
> 
> dhcp=dhcpcd
> 
> not 'dhcp-client'.  Which should also be documented in 'man
> NetworkManager.conf' actually.


Yay, outstanding.  I should have found that on my own though :/

Anyway, it does indeed work; thanks, Dan!

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

Re: Changes between NetworkManager 0.8 and 0.8.1

[Robby Workman]

On Fri, 13 Aug 2010 19:10:16 -0500
Dan Williams  wrote:

> On Fri, 2010-08-13 at 18:58 -0500, Robby Workman wrote:
> > On Wed, 11 Aug 2010 18:41:01 -0500
> > Dan Williams  wrote:
> > 
> > > You can always select your preferred DHCP client using 
> > > dhcp-client=[dhclient|dhcpcd] in the [main] section of 
> > > the config file too though.
> > 
> > 
> > Maybe I misunderstood, but this should work, right?
> > 
> >   [rwork...@liberty ~]$
> > cat /etc/NetworkManager/nm-system-settings.conf [main]
> >   plugins=keyfile
> >   dhcp-client=dhcpcd
> >   
> >   [keyfile]
> >   hostname=liberty
> > 
> > If the answer is yes, then one of us has a problem 
> > (that's a good-natured comment - no insult intended) :-)
> 
> Yeah, that should work...  if not then yeah, there's a problem :)
> 


Well, here's what I see in ps output:

/sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf 
/var/run/dhclient-wlan0.pid -lf 
/var/lib/dhclient/dhclient-93af950b-1619-4ce9-a172-645147565970-wlan0.lease -cf 
/var/run/nm-dhclient-wlan0.conf wlan0

This is after a reboot (to ensure that both the daemon and 
nm-applet were started fresh).  I suppose it's possible that
my NM configure arguments could be at fault, so here they are:

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --with-pppd-plugin-dir=/usr/lib${LIBDIRSUFFIX}/pppd/2.4.5 \
  --with-crypto=gnutls \
  --without-resolvconf \
  --with-dhcpcd=/sbin/dhcpcd \
  --with-dhclient=yes \
  --build=$ARCH-slackware-linux

Where should I begin looking to see what's going on here?  

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

Re: Changes between NetworkManager 0.8 and 0.8.1

[Robby Workman]

On Wed, 11 Aug 2010 18:41:01 -0500
Dan Williams  wrote:

> You can always select your preferred DHCP client using 
> dhcp-client=[dhclient|dhcpcd] in the [main] section of 
> the config file too though.


Maybe I misunderstood, but this should work, right?

  [rwork...@liberty ~]$ cat /etc/NetworkManager/nm-system-settings.conf 
  [main]
  plugins=keyfile
  dhcp-client=dhcpcd
  
  [keyfile]
  hostname=liberty

If the answer is yes, then one of us has a problem 
(that's a good-natured comment - no insult intended) :-)

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

Re: X session and hostname changing policy

[Robby Workman]

On Tue, 22 Jun 2010 02:21:27 -0700
Dan Williams  wrote:

> On Tue, 2010-06-22 at 10:06 +0200, Ludwig Nussel wrote:
> > Dan Williams wrote:
> > > On Tue, 2010-06-22 at 09:14 +0200, Ludwig Nussel wrote:
> > > > Dan Williams wrote:
> > > > > On Mon, 2010-06-14 at 23:16 +0300, Fırat Birlik wrote:
> > > > > > I experience a problem with hostname manipulation of
> > > > > > NetworkManager and the X session.  DHCP server sends a
> > > > > > hostname within the dhcp offer, which is different the
> > > > > > current one.  There is no persistent hostname definition
> > > > > > within the 'nm-system-settings.conf' as this is a default
> > > > > > installation.  NetworkManager just changes the hostname and
> > > > > > as new hostname is not authenticated (xhost cookie
> > > > > > MIT-MAGIC-COOKIE-1 for new hostname does not exist) no new
> > > > > > application can be started afterwards.
> > > > > 
> > > > > The solution is *not* to use hostname for local X
> > > > > authentication at all.
> > > > 
> > > > Even if that problem didn't exist... What's the benefit of
> > > > allowing a DHCP server in a foreign network to modify the
> > > > hostname by default anyways?
> > > 
> > > One example: single-image boots on multiple systems (computer lab,
> > > datacenter, whatever).  You don't want each one to have the same
> > > hostname, so you let DHCP assign a hostname to the machine when
> > > it boots up.
> > 
> > I have no doubt that there are use cases for setting the host name
> > via DHCP. I wonder whether those cases are wide spread enough to
> > justify tuning NetworkManager's *default* behavior for them though.
> > Given that NetworkManager is most useful for WiFi and situations
> > where users need to switch networks often a default of not changing
> > the hostname seems sensible to me.
> 
> For most people, I'd expect a persistent hostname set though.
> Installers will often do this for you (at least RH and Ubuntu's
> installers do) and thus I'd expect most people won't get their
> hostname changing dynamically.


Well, having the installer do it isn't an option here since Slackware
doesn't ship NetworkManager, but I did the next best thing that came
to mind here:

http://slackbuilds.org/gitweb/?p=slackbuilds.git;a=commit;h=3a608519b69

-RW

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

Re: X session and hostname changing policy

[Robby Workman]

On Mon, 14 Jun 2010 15:26:06 -0500
Robby Workman  wrote:

> On Mon, 14 Jun 2010 23:16:52 +0300
> Fırat Birlik  wrote:
> 
> > Hi there,
> > 
> > I experience a problem with hostname manipulation of NetworkManager
> > and the X session.  DHCP server sends a hostname within the dhcp
> > offer, which is different the current one.  There is no persistent
> > hostname definition within the 'nm-system-settings.conf' as this is
> > a default installation.  NetworkManager just changes the hostname
> > and as new hostname is not authenticated (xhost cookie
> > MIT-MAGIC-COOKIE-1 for new hostname does not exist) no new
> > application can be started afterwards.
> > 
> > To avoid this behavior, I can define a persistent hostname equal the
> > content of /etc/HOSTNAME (this is a slackware system) as the
> > following:
> > 
> > --- /etc/NetworkManager/nm-system-settings.conf~
> > +++ /etc/NetworkManager/nm-system-settings.conf
> > @@ -1,2 +1,5 @@
> >  [main]
> >  plugins=keyfile
> > +
> > +[keyfile]
> > +hostname=myhostname
> > 
> > 
> > As persistent hostname has highest precedence, problem looks solved;
> > but this should be repeated for each installation.
> > 
> > What I'm asking is, is there any config option or some way to not
> > let NetworkManager change the hostname?
> > 
> > As a note, current precedence order for hostname (taken from
> > NetworkManagerPolicy.c):
> > 
> >  * 1) a configured hostname (from system-settings)
> >  * 2) automatic hostname from the default device's config
> > (DHCP, VPN, etc)
> >  * 3) the original hostname when NM started
> >  * 4) reverse-DNS of the best device's IPv4 address
> > 
> 
> 
> Do you have NM built to use dhcpcd?  If so, dhcpcd should not change
> the system hostname unless you have force_hostname=(YES|TRUE|1) in
> /etc/dhcpcd.conf.   From dhcpcd(8):
> 
>   If the hostname is currently blank, (null) or localhost, or
> force_hostname is YES or TRUE or 1 then dhcpcd sets the 
> hostname to the one supplied by the DHCP server.
> 
> -RW
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list