On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote:
Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit :
If you architect a system that accounts for networking changing states,
then it works for *everyone*. If you depend on networking always being
there, then it only
On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote:
In general doing something like this is a bit backwards since networks
come and go and come and go in todays world, and we also don't want to
This seems like a very desktop-focused view of things. I appreciate that
that's
On Thu, 2011-10-20 at 07:46 -0400, Matthew Miller wrote:
On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote:
In general doing something like this is a bit backwards since networks
come and go and come and go in todays world, and we also don't want to
This seems like a very
Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit :
If you architect a system that accounts for networking changing states,
then it works for *everyone*. If you depend on networking always being
there, then it only works for some subset of users that have one type of
installation.
On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote:
Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit :
If you architect a system that accounts for networking changing states,
then it works for *everyone*. If you depend on networking always being
there, then it only
Le jeudi 20 octobre 2011 à 12:27 -0700, Adam Williamson a écrit :
On Thu, 2011-10-20 at 21:22 +0200, Nicolas Mailhot wrote:
Le jeudi 20 octobre 2011 à 13:08 -0500, Dan Williams a écrit :
If you architect a system that accounts for networking changing states,
then it works for
On Thu, Oct 20, 2011 at 11:51 AM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
No, it's an attempt to explain a general concept and not to point the
finger at anyone. Because as soon as you provide specifics, someone will
feel offended, get defensive, and refuse to listen to the general
Le jeudi 20 octobre 2011 à 11:59 -0800, Jef Spaleta a écrit :
On Thu, Oct 20, 2011 at 11:51 AM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
No, it's an attempt to explain a general concept and not to point the
finger at anyone. Because as soon as you provide specifics, someone will
On Thu, Oct 20, 2011 at 12:26 PM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
On anything more complex a new connexion will usually be established in
addition to the existing ones, and will have a specific pre-set
configuration. For example, a port can be dedicated to guest systems, or
Le jeudi 20 octobre 2011 à 12:40 -0800, Jef Spaleta a écrit :
And NM's dispatcher.d capability doesn't allow you to define and
remember per connection rules of the complexity you need?
The problem is mostly integration with networked apps, which are either
of the 'network can be up or not, if
On Thu, Oct 20, 2011 at 1:03 PM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
The problem is mostly integration with networked apps, which are either
of the 'network can be up or not, if it's up always do foo' kind, or the
'can manage multiple networks, but expects all of them to exist at
On Mon, Oct 17, 2011 at 19:10:04 +0200,
Lennart Poettering mzerq...@0pointer.de wrote:
So, while my first response to this would be the suggestion to improve
the sw in question to make it more robust to today's dynamic networking
I do acknowledge that this is not always feasible. So
here's
On Thu, 20.10.11 07:46, Matthew Miller (mat...@mattdm.org) wrote:
On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote:
In general doing something like this is a bit backwards since networks
come and go and come and go in todays world, and we also don't want to
This seems
I want to try to modprobe netconsole during boot, but it needs to happen
after the network is up. Is there any standard place (rc.local and
modules-load seem to happen too early) to do this?
I filed https://bugzilla.redhat.com/show_bug.cgi?id=746481 against systemd,
but it has been closed
On 10/17/2011 10:20 AM, Bruno Wolff III wrote:
I want to try to modprobe netconsole during boot, but it needs to happen
after the network is up. Is there any standard place (rc.local and
modules-load seem to happen too early) to do this?
I filed
On Mon, 17.10.11 09:20, Bruno Wolff III (br...@wolff.to) wrote:
I want to try to modprobe netconsole during boot, but it needs to happen
after the network is up. Is there any standard place (rc.local and
modules-load seem to happen too early) to do this?
Well, yes and no.
In general doing
On Mon, 2011-10-17 at 19:10 +0200, Lennart Poettering wrote:
On Mon, 17.10.11 09:20, Bruno Wolff III (br...@wolff.to) wrote:
I want to try to modprobe netconsole during boot, but it needs to happen
after the network is up. Is there any standard place (rc.local and
modules-load seem to
On Mon, 17.10.11 13:21, Simo Sorce (s...@redhat.com) wrote:
Note that you might still need to enable
NetworkManager-wait-online.servce with systemctl enable so that bootup
is delayed until NM configured a network. (more precisely: delay
network.target until NM configured a network).
If
On 10/17/2011 01:10 PM, Clyde E. Kunkel wrote:
On 10/17/2011 10:20 AM, Bruno Wolff III wrote:
I want to try to modprobe netconsole during boot, but it needs to happen
after the network is up. Is there any standard place (rc.local and
modules-load seem to happen too early) to do this?
I filed
19 matches
Mail list logo
