On Tue, 2018-11-06 at 12:23 +0100, Thomas HUMMEL wrote:
> On 10/26/18 12:55 PM, Thomas HUMMEL wrote:
> > > Generally, there are the device states "unmanaged" ->
> > > "unavailable" ->
> > > and "disconnected". For ethernet devices, a device is usually
> > > "unavailable" because it has no carrier.
On Wed, 2018-11-07 at 12:14 +0100, Thomas HUMMEL wrote:
> Hello,
>
> I was playing with the externally managed concept and I experienced
> the
> following :
>
> modifying an autocreated/autoconnected profile corresponding to an
> externally managed device seems to be (silently) auto-reapplied.
Hello,
I was playing with the externally managed concept and I experienced the
following :
modifying an autocreated/autoconnected profile corresponding to an
externally managed device seems to be (silently) auto-reapplied.
Afterward, once NetworkManager takes over (and really manages the
dev
On 10/26/18 12:55 PM, Thomas HUMMEL wrote:
Generally, there are the device states "unmanaged" -> "unavailable" ->
and "disconnected". For ethernet devices, a device is usually
"unavailable" because it has no carrier.
As a matter of fact, when no udev rules for NM_UNMANAGED, the device is
in
On Fri, 2018-10-26 at 20:14 +0200, Thomas HUMMEL wrote:
> On 10/25/2018 03:47 PM, Thomas Haller wrote:
> > For example,
> >
> > nmcli connection up "$PROFILE" ifname "$DEVICE"
> > nmcli connection modify "$PROFILE" +ipv4.addresses
> > 192.168.77.5/24
> > nmcli device reapply "$DEVICE"
On Fri, 2018-10-26 at 19:34 +0200, Thomas HUMMEL wrote:
> On 10/25/2018 03:47 PM, Thomas Haller wrote:
> > Remember, that a modification of the profile (`nmcli connection
> > modify`) does not take effect immeiately (except "connection.zone"
> > and
> > "connection.metered" properties). You usually
On 10/25/2018 03:47 PM, Thomas Haller wrote:
For example,
nmcli connection up "$PROFILE" ifname "$DEVICE"
nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24
nmcli device reapply "$DEVICE"
is basically the same as:
nmcli connection up "$PROFILE" ifname "$DEVICE"
On 10/25/2018 03:47 PM, Thomas Haller wrote:
Remember, that a modification of the profile (`nmcli connection
modify`) does not take effect immeiately (except "connection.zone" and
"connection.metered" properties). You usually need to do a full re-
activation for the changes to take effect (`nmcli
Generally, there are the device states "unmanaged" -> "unavailable" ->
and "disconnected". For ethernet devices, a device is usually
"unavailable" because it has no carrier.
As a matter of fact, when no udev rules for NM_UNMANAGED, the device is
in the disconnected state.
As for the traces
On Fri, 2018-10-26 at 12:01 +0200, Thomas HUMMEL wrote:
> On 10/26/2018 10:05 AM, Thomas Haller wrote:
>
>
> > Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `,
> > but
> > this just returns (state != "unmanaged").
>
> Wait : what's the diffence (if any) between GENERAL.NM-MANA
On 10/26/2018 10:05 AM, Thomas Haller wrote:
The return value of the nmcli command is odd, maybe a bug.
In any event, it may be confusing for the user or a script indeed which
then could legitimely think the managed request succeeded.
It returns success, because it successfully flagged the
Hi,
On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote:
> On 10/18/2018 11:30 PM, Thomas Haller wrote:
> > Btw, note that if you configure the device as unmanaged via
> > NM_CONTROLLED=no in ifcfg, then the device cannot be set to
> > managed.
> > This way of unmanaging a device is definite,
On 10/18/2018 11:30 PM, Thomas Haller wrote:
Btw, note that if you configure the device as unmanaged via
NM_CONTROLLED=no in ifcfg, then the device cannot be set to managed.
This way of unmanaging a device is definite,
Hello again, another use case I'm still wrapping my head around (even
with
On Wed, 2018-10-24 at 16:40 +0200, Thomas HUMMEL wrote:
> On 10/24/2018 04:11 PM, Thomas HUMMEL wrote:
>
> > > Reapply doesn't seem to have any relevance with modification or
> > > persistance.
> >
> > Yes so now my understanding of reapply is more like "restore" (to
> > its
> > original setting
On Thu, 2018-10-25 at 15:09 +0200, Thomas HUMMEL wrote:
> On 10/25/2018 03:05 PM, Thomas Haller wrote:
> > On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote:
> > > On 10/24/2018 01:19 PM, Thomas Haller wrote:
> > >
> > >
> > > > Both the device and the profile must be willing to autoconnect
On Wed, 2018-10-24 at 19:58 +0200, Thomas HUMMEL wrote:
> On 10/24/2018 06:22 PM, Thomas Haller wrote:
>
> > Let's call this "externally managed". Not sure that's helpful, but
> > in
> > NetworkManager source code it's called like that.
> >
> > In nmcli output, you cannot really distinguish a reg
On 10/25/2018 03:05 PM, Thomas Haller wrote:
On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote:
On 10/24/2018 01:19 PM, Thomas Haller wrote:
Both the device and the profile must be willing to autoconnect for
it
to happen. It's both ways. That's why you can suppress autoconnect
on
both si
On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote:
> On 10/24/2018 01:19 PM, Thomas Haller wrote:
>
>
> > Both the device and the profile must be willing to autoconnect for
> > it
> > to happen. It's both ways. That's why you can suppress autoconnect
> > on
> > both sides.
>
>
> Also, how
On 10/24/2018 01:19 PM, Thomas Haller wrote:
Both the device and the profile must be willing to autoconnect for it
to happen. It's both ways. That's why you can suppress autoconnect on
both sides.
Also, how can I check the status of a device autoconnect flag (as set by
nmcli device set au
On 10/24/2018 06:22 PM, Thomas Haller wrote:
Let's call this "externally managed". Not sure that's helpful, but in
NetworkManager source code it's called like that.
In nmcli output, you cannot really distinguish a regular activated
profile from such an externally managed one. Except, that in th
On Wed, 2018-10-24 at 15:52 +0200, Thomas HUMMEL wrote:
> On 10/24/2018 01:23 PM, Thomas Haller wrote:
>
> > Hi,
> >
> > An unmanaged device is in state "unmanaged". All other states (like
> > "100 (connected)") are not-unmanaged, which means they are
> > "managed".
> >
> >$ nmcli -f GENERAL
On 10/24/2018 04:11 PM, Thomas HUMMEL wrote:
Reapply doesn't seem to have any relevance with modification or
persistance.
Yes so now my understanding of reapply is more like "restore" (to its
original settings). Does this make sense even with non disk backed
applied profiled (I guess that's
On 10/24/2018 01:14 PM, Thomas Haller wrote:
Hm, `nmcli device reapply` does not modify the profile at all, does it?
Correct.
Sorry, I did so many tests that I misinterpreted this one.
Reapply doesn't seem to have any relevance with modification or
persistance.
Yes so now my understanding
On 10/24/2018 01:23 PM, Thomas Haller wrote:
Hi,
An unmanaged device is in state "unmanaged". All other states (like
"100 (connected)") are not-unmanaged, which means they are "managed".
$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show
$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device sh
On Tue, 2018-10-23 at 17:29 +0200, Thomas HUMMEL wrote:
> On 10/17/2018 10:38 AM, Thomas Haller wrote:
> > 3) if you do
> >
> >nmcli device disconnect eth0
> >ip addr add 192.168.7.5/24 dev eth0
> >
> > NM now creates an in-memory connection "eth0". This means that
> > NetworkManager*does
On Tue, 2018-10-23 at 15:25 +0200, Thomas HUMMEL wrote:
> On 10/18/2018 11:30 PM, Thomas Haller wrote:
> > The profile has a "connection.autoconnect" property. If it's "no",
> > the
> > profile never autoconnects. Period.
> >
> > But there also needs to be a device which is currently in a state
>
On Fri, 2018-10-19 at 19:22 +0200, Thomas HUMMEL wrote:
Hi,
> > > > Usually, NetworkManager (the daemon) does not automatically
> > > > create
> > > > connection profiles
> > >
> > >
> > > But when it does (as in your cases), is it always only in RAM
> > > (unless
> > > we
> > > then save the
On 10/17/2018 10:38 AM, Thomas Haller wrote:
3) if you do
nmcli device disconnect eth0
ip addr add 192.168.7.5/24 dev eth0
NM now creates an in-memory connection "eth0". This means that
NetworkManager*does not* manage this device.
Among the things I forgot : I understand what you expla
On 10/18/2018 11:30 PM, Thomas Haller wrote:
The profile has a "connection.autoconnect" property. If it's "no", the
profile never autoconnects. Period.
But there also needs to be a device which is currently in a state where
it would like to autoconnect a profile. With `nmcli device set
"$DEVICE"
Thanks again.
Your info are precious ! Some of them should make their way into the
official doc to me.
Again, a lot to digest but it's getting pretty clear.
Usually, NetworkManager (the daemon) does not automatically create
connection profiles
But when it does (as in your cases), is it al
On Wed, 2018-10-17 at 19:34 +0200, Thomas HUMMEL wrote:
> Hello,
>
> thanks for your answers. Very useful !
> Much content to digest ;-)
>
> > you can ignore
> > initscripts entirely.
>
> I know, I was just curious about how they used D-Bus and nmcli and
> how
> compatibility worked both ways (
Hello,
thanks for your answers. Very useful !
Much content to digest ;-)
you can ignore
initscripts entirely.
I know, I was just curious about how they used D-Bus and nmcli and how
compatibility worked both ways (network-scripts <-> NM)
There is little difference
- `nmcli connection
> > -> where is that magic described ? How does a simple connect
> > CREATES
> > a
> > connection. Man states that connect looks for a matching EXISTING
> > connection ?
>
> man nmcli:
>
>connect ifname
>Connect the device. NetworkManager will try to find a
> suitable connec
On Tue, 2018-10-16 at 14:56 +0200, Thomas HUMMEL wrote:
> I forgot : it seems to me that nmcli connection add also imply
> "managed"
> as in nmcli device set managed yes.
>
> Am I correct ? Then again when do we need those device commands
> manipulation ?
>
I don't see that happening, and it s
On Tue, 2018-10-16 at 14:40 +0200, Thomas HUMMEL wrote:
Hi,
>
> I'm considering migrating from a CentOS 6 HPC cluster to CentOS 7
> one.
> For this purpose I've read quite a lot of doc (man, guides, ...)
> about
> systemctl and NetworkManager to be fluent in their use.
>
> Regarding Network
I forgot : it seems to me that nmcli connection add also imply "managed"
as in nmcli device set managed yes.
Am I correct ? Then again when do we need those device commands
manipulation ?
thanks.
___
networkmanager-list mailing list
networkmanager-l
Hello,
I'm considering migrating from a CentOS 6 HPC cluster to CentOS 7 one.
For this purpose I've read quite a lot of doc (man, guides, ...) about
systemctl and NetworkManager to be fluent in their use.
Regarding NetworkManager, I've been at first confused by the induced
complexity or numb
37 matches
Mail list logo
