Groups > linux.debian.user > #167938 > unrolled thread

/etc/init.d/networking does not start everything in /etc/network/interfaces

Started by	Gene Heskett <gheskett@shentel.net>
First post	2016-05-17 14:10 +0200
Last post	2016-05-20 20:10 +0200
Articles	20 on this page of 47 — 14 participants

Back to article view | Back to linux.debian.user

  /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 14:10 +0200
    Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Peter Ludikovsky <peter@ludikovsky.name> - 2016-05-17 14:20 +0200
      Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 14:40 +0200
    Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-17 14:20 +0200
      Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Mimiko <vbvbrj@gmail.com> - 2016-05-17 14:40 +0200
        Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Gilles Mocellin <gilles.mocellin@nuagelibre.org> - 2016-05-17 19:20 +0200
          Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-17 19:30 +0200
            Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-18 13:40 +0200
              Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-18 16:00 +0200
              Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-18 16:00 +0200
                Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces <tomas@tuxteam.de> - 2016-05-18 16:10 +0200
              Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-18 17:00 +0200
                Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces <tomas@tuxteam.de> - 2016-05-18 17:10 +0200
                  Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-18 17:20 +0200
                    Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-18 17:40 +0200
                      Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-18 18:00 +0200
                        Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-18 18:10 +0200
                    Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Curt <curty@free.fr> - 2016-05-19 17:20 +0200
                Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Darac Marjal <mailinglist@darac.org.uk> - 2016-05-18 17:40 +0200
                Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-18 18:00 +0200
                  Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Brian <ad44@cityscape.co.uk> - 2016-05-18 18:50 +0200
                    Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-18 19:40 +0200
                      Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Brian <ad44@cityscape.co.uk> - 2016-05-19 00:40 +0200
          Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 21:00 +0200
            Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-17 21:40 +0200
      Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 15:00 +0200
      Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces <tomas@tuxteam.de> - 2016-05-17 15:10 +0200
        Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-17 15:50 +0200
          Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces <tomas@tuxteam.de> - 2016-05-17 15:50 +0200
        Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 16:00 +0200
          Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-17 16:40 +0200
            RE: /etc/init.d/networking does not start everything in  /etc/network/interfaces Bonno Bloksma <b.bloksma@tio.nl> - 2016-05-17 17:20 +0200
            Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-17 17:30 +0200
            Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 17:30 +0200
              Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-17 18:50 +0200
                Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 20:10 +0200
                Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces <tomas@tuxteam.de> - 2016-05-18 11:00 +0200
                  Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-18 19:30 +0200
              Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Elimar Riesebieter <riesebie@lxtec.de> - 2016-05-17 19:30 +0200
                Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-17 21:20 +0200
                  Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces Andy Smith <andy@strugglers.net> - 2016-05-17 21:30 +0200
                    Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-18 00:50 +0200
                      Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-18 01:40 +0200
                        Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Gene Heskett <gheskett@shentel.net> - 2016-05-18 04:10 +0200
            Re: /etc/init.d/networking does not start everything in  /etc/network/interfaces David Wright <deblis@lionunicorn.co.uk> - 2016-05-17 20:30 +0200
    Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Rodary Jacques <rodaryj@free.fr> - 2016-05-20 19:30 +0200
      Re: /etc/init.d/networking does not start everything in /etc/network/interfaces Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-20 20:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#168032 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Brian <ad44@cityscape.co.uk>
Date	2016-05-18 18:50 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rAcPw-4AL-17@gated-at.bofh.it>
In reply to	#168028

On Wed 18 May 2016 at 10:44:40 -0500, David Wright wrote:

> On Wed 18 May 2016 at 10:56:01 (-0400), Gene Heskett wrote:
> > 
> > auto lo eth0 eth1
> 
> Agree with Lisi, I've never seen this (though I'm not claiming it's
> either wrong or harmful).

It's an ok line. From interfaces(5):

  Lines beginning with the word "auto" are used to identify the physical
  interfaces to be brought up when . . . .
	   ^
	   |
	   ^
	   |
	 Plural

[toc] | [prev] | [next] | [standalone]

#168035 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-05-18 19:40 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rAdBU-584-19@gated-at.bofh.it>
In reply to	#168032

On Wed 18 May 2016 at 17:39:45 (+0100), Brian wrote:
> On Wed 18 May 2016 at 10:44:40 -0500, David Wright wrote:
> 
> > On Wed 18 May 2016 at 10:56:01 (-0400), Gene Heskett wrote:
> > > 
> > > auto lo eth0 eth1
> > 
> > Agree with Lisi, I've never seen this (though I'm not claiming it's
> > either wrong or harmful).
> 
> It's an ok line. From interfaces(5):
> 
>   Lines beginning with the word "auto" are used to identify the physical
>   interfaces to be brought up when . . . .
> 	   ^
> 	   |
> 	   ^
> 	   |
> 	 Plural

Sorry, that wasn't my point. Here's the context again:

On Wed 18 May 2016 at 10:56:01 (-0400), Gene Heskett wrote:
[...]
> Now,  for those complaining about my lack of posting the complete
> interfaces file, here it is:
> --------------------------------------------
> # This file describes the network interfaces available on your
> system
> # and how to activate them. For more information, see interfaces(5).
>
> auto lo eth0 eth1
>
> # The loopback network interface
> iface lo inet loopback
> address 127.0.0.1
> netmask 255.0.0.0

Agree with Lisi, I've never seen this (though I'm not claiming it's
either wrong or harmful).

To elaborate, interfaces(5) says:

   The loopback Method
       This method may be used to define the IPv4 loopback interface.

       Options

              (No options)

So these options:

> address 127.0.0.1
> netmask 255.0.0.0

may or may not cause trouble.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#168051 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Brian <ad44@cityscape.co.uk>
Date	2016-05-19 00:40 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rAiid-89L-9@gated-at.bofh.it>
In reply to	#168035

On Wed 18 May 2016 at 12:32:24 -0500, David Wright wrote:

> On Wed 18 May 2016 at 17:39:45 (+0100), Brian wrote:
> > On Wed 18 May 2016 at 10:44:40 -0500, David Wright wrote:
> > 
> > > On Wed 18 May 2016 at 10:56:01 (-0400), Gene Heskett wrote:
> > > > 
> > > > auto lo eth0 eth1
> > > 
> > > Agree with Lisi, I've never seen this (though I'm not claiming it's
> > > either wrong or harmful).
> > 
> > It's an ok line. From interfaces(5):
> > 
> >   Lines beginning with the word "auto" are used to identify the physical
> >   interfaces to be brought up when . . . .
> > 	   ^
> > 	   |
> > 	   ^
> > 	   |
> > 	 Plural
> 
> Sorry, that wasn't my point. Here's the context again:

Sorry. Hopefully it will be useful for someone, though. :)

> On Wed 18 May 2016 at 10:56:01 (-0400), Gene Heskett wrote:
> [...]
> > Now,  for those complaining about my lack of posting the complete
> > interfaces file, here it is:
> > --------------------------------------------
> > # This file describes the network interfaces available on your
> > system
> > # and how to activate them. For more information, see interfaces(5).
> >
> > auto lo eth0 eth1
> >
> > # The loopback network interface
> > iface lo inet loopback
> > address 127.0.0.1
> > netmask 255.0.0.0
> 
> Agree with Lisi, I've never seen this (though I'm not claiming it's
> either wrong or harmful).
> 
> To elaborate, interfaces(5) says:
> 
>    The loopback Method
>        This method may be used to define the IPv4 loopback interface.
> 
>        Options
> 
>               (No options)
> 
> So these options:
> 
> > address 127.0.0.1
> > netmask 255.0.0.0
> 
> may or may not cause trouble.

127.0.0.1 is a class A address so has 255.0.0.0 as its netmask. The line
above above is redundant. The installer never uses it. Why a user would
add it is beyond me. I have

  brian@desktop:~$ /sbin/ifconfig lo
  lo        Link encap:Local Loopback  
            inet addr:127.0.0.1  Mask:255.0.0.0
            inet6 addr: ::1/128 Scope:Host
            UP LOOPBACK RUNNING  MTU:65536  Metric:1
            RX packets:695157 errors:0 dropped:0 overruns:0 frame:0
            TX packets:695157 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0 
            RX bytes:135710702 (129.4 MiB)  TX bytes:135710702 (129.4 MiB)

without that line. As can be seen, the netmask is sorted out automatically.

[toc] | [prev] | [next] | [standalone]

#167972

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 21:00 +0200
Message-ID	<rzSnL-8gV-3@gated-at.bofh.it>
In reply to	#167962

On Tuesday 17 May 2016 13:09:33 Gilles Mocellin wrote:

> Le 17/05/2016 à 14:34, Mimiko a écrit :
> > On 17.05.2016 15:16, Elimar Riesebieter wrote:
> >> Ask your search engine: "init.d/networking restart is deprecated"
> >
> > This was the only tool to fully restart all networking even the
> > interface thru which connection is made.
> > Are the `ifdown eth & ifup eth` the only option now?
>
> Just to add these commands in that thread.
>
> To restart all the interfaces as they are defined in
> /etc/network/interfaces, I do :
>
> # ifdown -a; ifup -a

Apparently I do not have something fully correct in my interfaces file, 
the above command string does not shut down or restart eth1.  It leaves 
it in the state it found it in.  Bug in ifdown -a? I dunno, and 

"ifconfig eth1 down"

also has the only effect of nuking its address block in a route -n 
report.

Kernel IP routing table
Destination    Gateway       Genmask       Flags Metric Ref    Use Iface
0.0.0.0        192.168.71.1  0.0.0.0       UG    0       0       0 eth0
169.254.0.0    0.0.0.0       255.255.0.0   U     1000    0       0 eth0
192.168.71.0   0.0.0.0       255.255.255.0 U     0       0       0 eth0

root@coyote:/etc/network# ifconfig eth1 up
root@coyote:/etc/network# route -n
Kernel IP routing table
Destination    Gateway       Genmask       Flags Metric Ref    Use Iface
0.0.0.0        192.168.71.1  0.0.0.0       UG    0      0      0   eth0
169.254.0.0    0.0.0.0       255.255.0.0   U     1000   0      0   eth0
192.168.1.0    0.0.0.0       255.255.255.0 U     0      0      0   eth1
192.168.71.0   0.0.0.0       255.255.255.0 U     0      0      0   eth0

Spacing adjusted above to defeat my word wrap.

So how did I make it work in the first place?
DIIK. :(
So it quite likely will be gone if I reboot.

Interesting is that in a man 5 interfaces, it says the gateway address is 
colon delimited. I don't recall ever seeing that since my first install 
in early 1998.  Does anyone ever actually read these man pages but me?

Thanks Gilles

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167976 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-05-17 21:40 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzT0t-iJ-1@gated-at.bofh.it>
In reply to	#167972

On Tue 17 May 2016 at 14:51:57 (-0400), Gene Heskett wrote:

> Interesting is that in a man 5 interfaces, it says the gateway address is 
> colon delimited. I don't recall ever seeing that since my first install 
> in early 1998.  Does anyone ever actually read these man pages but me?

Yes, but I haven't studied the IPv6 part!

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#167944

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 15:00 +0200
Message-ID	<rzMLo-4Gf-9@gated-at.bofh.it>
In reply to	#167940

On Tuesday 17 May 2016 08:16:32 Elimar Riesebieter wrote:

> * Gene Heskett <gheskett@shentel.net> [2016-05-17 08:05 -0400]:
> > Greetings all;
> >
> > 32 bit Debian wheezy, updated at least daily.
> >
> > This fact was brought to my attention because I needed a path to a
> > router I needed to do a hard reset on, and reconfigure to do my
> > stuff, but my normal home network isn't on the usual 192.168.1.1
> > class C, and a hard reset puts the router back to the 1.1 address.
> >
> > So in order to use eth1 as a path to this router, I have to do a
> > separate
> >
> > sudo ifconfig eth1 up
> >
> > as a sudo service networking restart will not restart the second
> > eth1 stanza in my interfaces file, starting only eth0.
> >
> > Normally the interface is not even graced with a cat5 in the socket,
> > and ATM it is but the far end of 5 feet of cat5 is laying on the
> > floor.
> >
> > Is it possible to make this init.d/networking script start
> > everything it finds in the interfaces file?
>
> Ask your search engine: "init.d/networking restart is deprecated"
>
> Elimar

This is wheezy, Elimar.  What has replaced it?  Doing the search  as 
recommended, and clicking on the debian answer, what I see may work, I 
didn't try it, but thats the biggest kludge I've seen in a while, even 
Rube Goldberg would have been impressed. So I will continue to use the 
deprecated method until such time as it quits working entirely, or has 
been replaced by something equally simple and elegant. That solution for 
sure isn't it.  Thats like me going to the store for a daily paper, a 
distance of 1.5 miles, but taking a 1400 mile round trip detour to see 
the arch in St. Louis Mo.  BTDT, rode the elevator even. If the script 
we have been using for a decade doesn't work under some obscure 
condition, fix the script!  Sheesh...

Thanks Elimar.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167947 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	<tomas@tuxteam.de>
Date	2016-05-17 15:10 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzMV4-4YN-25@gated-at.bofh.it>
In reply to	#167940

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 17, 2016 at 02:16:32PM +0200, Elimar Riesebieter wrote:

[...]

> Ask your search engine: "init.d/networking restart is deprecated"

I don't know about yours, but *my* /etc/init.d/networking is alive
and healthy! More to the point, it's so useful to me that I'd rewrite
it, should it fall off Debian.

Instead of scaring off people by some strange warning picked out of
the huge echo chamber of the Intertubesi [1], how about doing some
real research and explain to people what's up?

/etc/init.d/networking will bring your system to its default state
(like after a reboot). Thus, the interfaces marked with "auto" in
/etc/network/interfaces will be up, all others, down.

Anything you changed manually since boot (e.g. by issuing an
explicit "sudo ifup eth0", same for an ifdown) will be gone.
This could be, depending on circumstances, somewhat unexpected,
unwanted, or totally intended.

In my opinion, a warning is in order ("this might not be doing
what you think it does"), but deprecated seems exaggerated to me.

regards

[1] Schocking Truth! Not everything seen on the Internet is true!

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlc7F+cACgkQBcgs9XrR2kavhwCfUbMcBMxqWDreJl3ed+eEDi52
L20An2gnWomTxyx1UnfymXas5apMzZhA
=HOSL
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#167949 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Elimar Riesebieter <riesebie@lxtec.de>
Date	2016-05-17 15:50 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzNxL-5cf-5@gated-at.bofh.it>
In reply to	#167947

* tomas@tuxteam.de <tomas@tuxteam.de> [2016-05-17 15:08 +0200]:

> On Tue, May 17, 2016 at 02:16:32PM +0200, Elimar Riesebieter wrote:
> 
> [...]
> 
> > Ask your search engine: "init.d/networking restart is deprecated"
> 
> I don't know about yours, but *my* /etc/init.d/networking is alive
> and healthy! More to the point, it's so useful to me that I'd rewrite
> it, should it fall off Debian.
> 
> Instead of scaring off people by some strange warning picked out of
> the huge echo chamber of the Intertubesi [1], how about doing some
> real research and explain to people what's up?

I don't understand why  "init.d/networking restart is deprecated" is
scaring off people? It is a matter of fact! Reading the results will
give all answers a user want.

> /etc/init.d/networking will bring your system to its default state
> (like after a reboot). Thus, the interfaces marked with "auto" in
> /etc/network/interfaces will be up, all others, down.

Well, you must be sure that all interfaces in your system get their
assigned names. To make sure they will, you have to define udev
rules, probably by hand if not done by udev itself ( i.e.
/etc/udev/rules.d/70-persistent-net.rules).

> Anything you changed manually since boot (e.g. by issuing an
> explicit "sudo ifup eth0", same for an ifdown) will be gone.
> This could be, depending on circumstances, somewhat unexpected,
> unwanted, or totally intended.
> 
> In my opinion, a warning is in order ("this might not be doing
> what you think it does"), but deprecated seems exaggerated to me.

On modern systems running systemd (and in some circumstances
sysvinit sytems as well) you may get unwanted if names. So
users have to keep their eyes on what is deprecated (which may be
valid only for future updates) and can be obtained on legacy
installations as well. Just FYI:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

So rely on the kernel in naming network interfaces is nothing else
as a guess.

Sigh
Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)

[toc] | [prev] | [next] | [standalone]

#167950 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	<tomas@tuxteam.de>
Date	2016-05-17 15:50 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzNxM-5cf-21@gated-at.bofh.it>
In reply to	#167949

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 17, 2016 at 03:36:58PM +0200, Elimar Riesebieter wrote:

[...]

> I don't understand why  "init.d/networking restart is deprecated" is
> scaring off people? It is a matter of fact! Reading the results will
> give all answers a user want.

No, *you* are scaring off people :-)

> Well, you must be sure that all interfaces in your system get their
> assigned names. To make sure they will, you have to define udev
> rules, probably by hand if not done by udev itself ( i.e.
> /etc/udev/rules.d/70-persistent-net.rules).

...you gotta know what you're doing, obviously.

[...]

> > In my opinion, a warning is in order ("this might not be doing
> > what you think it does"), but deprecated seems exaggerated to me.
> 
> On modern systems running systemd (and in some circumstances
> sysvinit sytems as well) you may get unwanted if names. So
> users have to keep their eyes on what is deprecated (which may be
> valid only for future updates) and can be obtained on legacy
> installations as well. Just FYI:
> 
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

 - my system is modern and is not running systemd
 - I never get unwanted names. I know I might get some
   and I know how to cope with that when it comes up

> 
> So rely on the kernel in naming network interfaces is nothing else
> as a guess.

WorksForMe (TM)

> Sigh

Snort
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlc7IIkACgkQBcgs9XrR2kaYCgCXX5F9GQ64oqZmv2htmy+HtNOO
LQCaA7vsT4m/1Ev7R7yqDz7Rqd80iIQ=
=3ZhM
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#167951

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 16:00 +0200
Message-ID	<rzNHw-5fA-9@gated-at.bofh.it>
In reply to	#167947

On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:

> On Tue, May 17, 2016 at 02:16:32PM +0200, Elimar Riesebieter wrote:
>
> [...]
>
> > Ask your search engine: "init.d/networking restart is deprecated"
>
> I don't know about yours, but *my* /etc/init.d/networking is alive
> and healthy! More to the point, it's so useful to me that I'd rewrite
> it, should it fall off Debian.
>
> Instead of scaring off people by some strange warning picked out of
> the huge echo chamber of the Intertubesi [1], how about doing some
> real research and explain to people what's up?
>
> /etc/init.d/networking will bring your system to its default state
> (like after a reboot). Thus, the interfaces marked with "auto" in
> /etc/network/interfaces will be up, all others, down.
>
> Anything you changed manually since boot (e.g. by issuing an
> explicit "sudo ifup eth0", same for an ifdown) will be gone.
> This could be, depending on circumstances, somewhat unexpected,
> unwanted, or totally intended.
>
> In my opinion, a warning is in order ("this might not be doing
> what you think it does"), but deprecated seems exaggerated to me.
>
> regards
>
> [1] Schocking Truth! Not everything seen on the Internet is true!
>
> -- tomás

About 4th or 5th down in that list of hits, this one labeled for debian, 
is a bit long winded  but finishes up recommending one edit his 
personal .bash-aliases file to contain this:

alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop; date; 
echo sleeping; sleep 2; echo waking; date; invoke-rc.d networking 
start'"

Is that simple?  Elegant and correct?  No, if the networking script was 
broken, its still broken!

Note that it uses seems to use the same exact script in init.d so the net 
result should be the same but its being run by invoke-rc.d instead of 
service.  Which means that if the networking script is broken, it is 
STILL BROKEN!

Elegant and correcting a bug in the networking script?  I have a bridge, 
currently in Sun City AZ I'd like to sell to whoever dreamed this up.

Surely, we can do better than that.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167953 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Elimar Riesebieter <riesebie@lxtec.de>
Date	2016-05-17 16:40 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzOk9-5Kj-3@gated-at.bofh.it>
In reply to	#167951

* Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:

> On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
> 
[...]
> > In my opinion, a warning is in order ("this might not be doing
> > what you think it does"), but deprecated seems exaggerated to me.
> >
> > regards
> >
> > [1] Schocking Truth! Not everything seen on the Internet is true!
> >
> > -- tomás
> 
> About 4th or 5th down in that list of hits, this one labeled for debian, 
> is a bit long winded  but finishes up recommending one edit his 
> personal .bash-aliases file to contain this:
> 
> alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop; date; 
> echo sleeping; sleep 2; echo waking; date; invoke-rc.d networking 
> start'"
> 
> Is that simple?  Elegant and correct?  No, if the networking script was 
> broken, its still broken!

Again, I recommend to read [0] and [1].

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Elimar
-- 
  We all know Linux is great... it does infinite loops in 5 seconds.
        -Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#167955 — RE: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Bonno Bloksma <b.bloksma@tio.nl>
Date	2016-05-17 17:20 +0200
Subject	RE: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzOWR-6ct-5@gated-at.bofh.it>
In reply to	#167953

Hi Elimar,

>> On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
>> 
>[...]
>> > In my opinion, a warning is in order ("this might not be doing what 
>> > you think it does"), but deprecated seems exaggerated to me.
>> >
>> > regards
>> >
>> > [1] Schocking Truth! Not everything seen on the Internet is true!
>> >
>> > -- tomás
>> 
>> About 4th or 5th down in that list of hits, this one labeled for 
>> debian, is a bit long winded  but finishes up recommending one edit 
>> his personal .bash-aliases file to contain this:
>> 
>> alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop; date; 
>> echo sleeping; sleep 2; echo waking; date; invoke-rc.d networking 
>> start'"
>> 
>> Is that simple?  Elegant and correct?  No, if the networking script 
>> was broken, its still broken!
>
> Again, I recommend to read [0] and [1].

I (re)read those just now, I think I read it before.
I still think this will change my interface name(s) when I swap a defective board for a new one as udev will see new interface(s).
The solution will probably still be the same, kill the 70-persistent-net.rules file and do a reboot / restart.

I have never seen a interface name change without a hardware change. And with udev enabled I have NEVER had the right change and needed to do some delete / edit of the udev 70-* file to get the "proper" interface name for my (firewall) scripts that use interface names.
So I don’t understand what the improvement is, there will probably be some in specific cases, just not in my case I think. Instead of rewriting all my scripts I will probably edit the 70-* udev file to create my familiar ethX names.

> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
> [1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Bonno Bloksma

[toc] | [prev] | [next] | [standalone]

#167956

From	Lisi Reisz <lisi.reisz@gmail.com>
Date	2016-05-17 17:30 +0200
Message-ID	<rzP6y-6hY-11@gated-at.bofh.it>
In reply to	#167953

On Tuesday 17 May 2016 15:38:52 Elimar Riesebieter wrote:
> * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
>
> [...]
>
> > > In my opinion, a warning is in order ("this might not be doing
> > > what you think it does"), but deprecated seems exaggerated to me.
> > >
> > > regards
> > >
> > > [1] Schocking Truth! Not everything seen on the Internet is true!
> > >
> > > -- tomás
> >
> > About 4th or 5th down in that list of hits, this one labeled for debian,
> > is a bit long winded  but finishes up recommending one edit his
> > personal .bash-aliases file to contain this:
> >
> > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop; date;
> > echo sleeping; sleep 2; echo waking; date; invoke-rc.d networking
> > start'"
> >
> > Is that simple?  Elegant and correct?  No, if the networking script was
> > broken, its still broken!
>
> Again, I recommend to read [0] and [1].
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
> [1]
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfa
>ceNames/

Sufficient unto the day is the evil thereof.  Why would someone who is running 
Wheezy without systemd need [1]?  By the time cnc, or whatever Gene's special 
milling software is called, is using Jessie, or even Stretch, and systemd, 
the world may have been blown up - or things may simply have changed again.

Lisi

[toc] | [prev] | [next] | [standalone]

#167957

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 17:30 +0200
Message-ID	<rzP6y-6hY-19@gated-at.bofh.it>
In reply to	#167953

On Tuesday 17 May 2016 10:38:52 Elimar Riesebieter wrote:

> * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
>
> [...]
>
> > > In my opinion, a warning is in order ("this might not be doing
> > > what you think it does"), but deprecated seems exaggerated to me.
> > >
> > > regards
> > >
> > > [1] Schocking Truth! Not everything seen on the Internet is true!
> > >
> > > -- tomás
> >
> > About 4th or 5th down in that list of hits, this one labeled for
> > debian, is a bit long winded  but finishes up recommending one edit
> > his personal .bash-aliases file to contain this:
> >
> > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop;
> > date; echo sleeping; sleep 2; echo waking; date; invoke-rc.d
> > networking start'"
> >
> > Is that simple?  Elegant and correct?  No, if the networking script
> > was broken, its still broken!
>
> Again, I recommend to read [0] and [1].
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240

Looks like mine has been "fixed" by the removal of the hotplug stuff.  I 
do not see that as a disadvantage, udev can do that much unwanted damage 
all by itself.

> [1]
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkIn
>terfaceNames/
>
And this falls over in its morning oatmeal if the box you installed on 
turns out to be a dud, so you go  get another box and just move the hard 
drive because you've already moved 20 megs worth of gcode you don't want 
to do again if you reinstall on the newer box.  udev remembers the old 
interface and very helpfully dreams up a new name for it, without 
reaching into the interfaces file to correct the port names there.  Or 
advising the user about it unless he goes crawling thru the logs.  You 
get no warning other than the networking can't be brought up that worked 
perfectly on the box with an AMD Family 15 cpu with an unfixable halt 
bug because it doesn't yet do a microcode update at the family 15 time 
point.  That non-warned about renaming is not an excusable behavior.  
But it took me 2 days to fix it each time I moved the drive because I 
had to come here and hope for an answer each time.  I learned a lot 
thanks to the kind folks here, but I fail to grok the reason for that 
behavior in the first place.  Because of some rare condition, you make 
all the other users with a less rare condition suffer?

> Elimar

Thank Elimar.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167960 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-05-17 18:50 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzQlX-6YU-7@gated-at.bofh.it>
In reply to	#167957

On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
> On Tuesday 17 May 2016 10:38:52 Elimar Riesebieter wrote:
> > * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
> > [...]
> > > > In my opinion, a warning is in order ("this might not be doing
> > > > what you think it does"), but deprecated seems exaggerated to me.
> > > >
> > > > [1] Schocking Truth! Not everything seen on the Internet is true!
> > >
> > > About 4th or 5th down in that list of hits, this one labeled for
> > > debian, is a bit long winded  but finishes up recommending one edit
> > > his personal .bash-aliases file to contain this:
> > >
> > > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop;
> > > date; echo sleeping; sleep 2; echo waking; date; invoke-rc.d
> > > networking start'"
> > >
> > > Is that simple?  Elegant and correct?  No, if the networking script
> > > was broken, its still broken!
> >
> > Again, I recommend to read [0] and [1].
> >
> > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
> 
> Looks like mine has been "fixed" by the removal of the hotplug stuff.  I 
> do not see that as a disadvantage, udev can do that much unwanted damage 
> all by itself.

I'm not sure what this has to do with your argument with udev.
IIRC you had been switching cards and got up to eth5 when you posted.
Apparently you hadn't read man udev, and though you said you'd scanned
/etc/udev/rules.d/70-persistent-net.rules you didn't post it, so we
couldn't point anything out. udev had been doing what it was designed
to do.

You don't see any disadvantage to removing the "hotplug stuff".
Hooray, let's go back to PCs as static boxes. Shut it down to add
a USB device. Who needs udev anyway?

> > [1]
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> >
> And this falls over in its morning oatmeal if the box you installed on 
> turns out to be a dud, so you go  get another box and just move the hard 
> drive because you've already moved 20 megs worth of gcode you don't want 
> to do again if you reinstall on the newer box.  udev remembers the old 
> interface and very helpfully dreams up a new name for it, without 
> reaching into the interfaces file to correct the port names there.  Or 
> advising the user about it unless he goes crawling thru the logs.  You 
> get no warning other than the networking can't be brought up that worked 
> perfectly on the box with an AMD Family 15 cpu with an unfixable halt 
> bug because it doesn't yet do a microcode update at the family 15 time 
> point.  That non-warned about renaming is not an excusable behavior.  
> But it took me 2 days to fix it each time I moved the drive because I 
> had to come here and hope for an answer each time.  I learned a lot 
> thanks to the kind folks here, but I fail to grok the reason for that 
> behavior in the first place.  Because of some rare condition, you make 
> all the other users with a less rare condition suffer?

A previous time this reference was pointed out to you, you realised
that it has no relevance to wheezy. Even if you upgrade to jessie,
it's of little relevance as Debian preserves the existing behaviour
if you don't try to wreck it/second-guess it/believe every posting on
the internet.

If you remember that far back, the linux kernel, faced with two NICs,
would toss a coin before naming one eth0 and the other eth1. This had
the splendid side-effect that you could think your LAN was the WAN and
vice versa, and there was nothing you could do about it.

udev meant that each NIC always got the same name even if you took it
out of the box one week and put it back the next. It is easy to
override that behaviour if it's undesired.

You appear to think that the old behaviour (the first NIC discovered
gets named eth0) is the only sensible behaviour because everyone is
always tinkering with the hardware, swapping boards out etc. as you do.
If that is really important, why not just write a script to clean
/etc/udev/rules.d/70-persistent-net.rules at every reboot.
That solves your problem, but allows other people to have a default
system that can sensibly give a stable configuration on machines
that have more than instance of each type of hardware (multiple
NICs, burners, USB devices.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#167969

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 20:10 +0200
Message-ID	<rzRBn-7V2-5@gated-at.bofh.it>
In reply to	#167960

On Tuesday 17 May 2016 12:22:29 David Wright wrote:

> On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
> > On Tuesday 17 May 2016 10:38:52 Elimar Riesebieter wrote:
> > > * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > > > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
> > >
> > > [...]
> > >
> > > > > In my opinion, a warning is in order ("this might not be doing
> > > > > what you think it does"), but deprecated seems exaggerated to
> > > > > me.
> > > > >
> > > > > [1] Schocking Truth! Not everything seen on the Internet is
> > > > > true!
> > > >
> > > > About 4th or 5th down in that list of hits, this one labeled for
> > > > debian, is a bit long winded  but finishes up recommending one
> > > > edit his personal .bash-aliases file to contain this:
> > > >
> > > > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop;
> > > > date; echo sleeping; sleep 2; echo waking; date; invoke-rc.d
> > > > networking start'"
> > > >
> > > > Is that simple?  Elegant and correct?  No, if the networking
> > > > script was broken, its still broken!
> > >
> > > Again, I recommend to read [0] and [1].
> > >
> > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
> >
> > Looks like mine has been "fixed" by the removal of the hotplug
> > stuff.  I do not see that as a disadvantage, udev can do that much
> > unwanted damage all by itself.
>
> I'm not sure what this has to do with your argument with udev.
> IIRC you had been switching cards and got up to eth5 when you posted.
> Apparently you hadn't read man udev, and though you said you'd scanned
> /etc/udev/rules.d/70-persistent-net.rules you didn't post it, so we
> couldn't point anything out. udev had been doing what it was designed
> to do.
>
> You don't see any disadvantage to removing the "hotplug stuff".
> Hooray, let's go back to PCs as static boxes. Shut it down to add
> a USB device. Who needs udev anyway?
>
Don't get too carried away, I was referring to the missing "hotplug" line 
in my interfaces file.  I didn't take it out. Out of 4 machines here, 
that line does not exist on any machine.

> > > [1]
> > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetwo
> > >rkInterfaceNames/
> >
> > And this falls over in its morning oatmeal if the box you installed
> > on turns out to be a dud, so you go  get another box and just move
> > the hard drive because you've already moved 20 megs worth of gcode
> > you don't want to do again if you reinstall on the newer box.  udev
> > remembers the old interface and very helpfully dreams up a new name
> > for it, without reaching into the interfaces file to correct the
> > port names there.  Or advising the user about it unless he goes
> > crawling thru the logs.  You get no warning other than the
> > networking can't be brought up that worked perfectly on the box with
> > an AMD Family 15 cpu with an unfixable halt bug because it doesn't
> > yet do a microcode update at the family 15 time point.  That
> > non-warned about renaming is not an excusable behavior. But it took
> > me 2 days to fix it each time I moved the drive because I had to
> > come here and hope for an answer each time.  I learned a lot thanks
> > to the kind folks here, but I fail to grok the reason for that
> > behavior in the first place.  Because of some rare condition, you
> > make all the other users with a less rare condition suffer?
>
> A previous time this reference was pointed out to you, you realised
> that it has no relevance to wheezy. Even if you upgrade to jessie,
> it's of little relevance as Debian preserves the existing behaviour
> if you don't try to wreck it/second-guess it/believe every posting on
> the internet.
>
> If you remember that far back, the linux kernel, faced with two NICs,
> would toss a coin before naming one eth0 and the other eth1. This had
> the splendid side-effect that you could think your LAN was the WAN and
> vice versa, and there was nothing you could do about it.

I ran the registered pc version of dd-wrt on an old K6-III box for 
several years, and not once did I observe the NIC's had been swapped on 
a reboot.  If linux ever had that problem I am unaware of it. And these 
were identical 100mbit nics.
>
> udev meant that each NIC always got the same name even if you took it
> out of the box one week and put it back the next. It is easy to
> override that behaviour if it's undesired.
>
> You appear to think that the old behaviour (the first NIC discovered
> gets named eth0) is the only sensible behaviour because everyone is
> always tinkering with the hardware, swapping boards out etc. as you
> do. If that is really important, why not just write a script to clean
> /etc/udev/rules.d/70-persistent-net.rules at every reboot.

Now thats a jolly good idea, so next time it has to start from scratch.
The point is however moot, I finally found a box that runs LCNC very 
well.  Not quite the latency results one can get from the long since out 
of stock intel D525MW motherboard, but that one can only do that one 
thing well as its out of both cajones and memory quickly if you want it 
to do more than that.  This box, a dell dimension 745, can run LCNC and 
do all the other stuff one needs to do at the same time. Without 
bothering LCNC, including running a hidef camera watching what the 
machine is doing and its video processing chain displayed on a separate 
workspace screen at the same time.

> That solves your problem, but allows other people to have a default
> system that can sensibly give a stable configuration on machines
> that have more than instance of each type of hardware (multiple
> NICs, burners, USB devices.

Only slightly valid today.  In fact since this install, my ups has 
remained on /dev/ttyUSB0 quite reliably even if I have moved cabling to 
put the same speed of device on a given exterior hub. I have several, 
and I've put the slow stuff on its own hub so the faster stuff can run 
at its full speed on a different hub. 5 years ago it was a problem.

I didn't intend to start a flamefest here, I was just asking for a little 
help with an edge case that only 2% will encounter in real life, but at 
the same time it has been educational, and different points of view have 
been well aired. But my instant problem HAS been solved, so lets put 
this one to bed for the time being?

> Cheers,
> David.

Thanks David & everybody else who replied.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#167992 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	<tomas@tuxteam.de>
Date	2016-05-18 11:00 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rA5uF-8b8-21@gated-at.bofh.it>
In reply to	#167960

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 17, 2016 at 11:22:29AM -0500, David Wright wrote:
> On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:

[...]

> You don't see any disadvantage to removing the "hotplug stuff".
> Hooray, let's go back to PCs as static boxes. Shut it down to add
> a USB device. Who needs udev anyway?

This is the typical red herring which helps heating up those
discussions. *You* see an advantage. *You* use it. Gene doesn't
Everyone is happy. Once you introduce this idiotic "we" as in
"let's go back...", things get messed up. The optimum set up
may vary from person to person (and *will* vary: if you have
a laptop with two USB hubs hanging off it, with three Ethernet
dongles randomly distributed in there, your requirements
envelope will differ from Gene's, who has a pretty stable
hardware setup once it's shaken out).

So there's an answer to your rhetorical question anyway:
"some need it, some need it not".

> A previous time this reference was pointed out to you, you realised
> that it has no relevance to wheezy. Even if you upgrade to jessie,
> it's of little relevance as Debian preserves the existing behaviour
> if you don't try to wreck it/second-guess it/believe every posting on
> the internet.

Tries. That's the word.

> If you remember that far back, the linux kernel, faced with two NICs,
> would toss a coin before naming one eth0 and the other eth1. This had
> the splendid side-effect that you could think your LAN was the WAN and
> vice versa, and there was nothing you could do about it.

Been there, done that (many moons ago, I was part of a small group of
people doing the software for a Debian based PC based router box, and
had to "solve" exactly this problem. There was no udev back then.

So I pretty well *know* what udev is trying to solve in this case, and
*know* there's no "simple" policy which will always do what the user
wants/expects.

> udev meant that each NIC always got the same name even if you took it
> out of the box one week and put it back the next. It is easy to
> override that behaviour if it's undesired.

Yeah, right. Based on the NIC's MAC address. Enter virtual machines,
which basically throw dice to come up with a MAC: every boot, a new
interface. Remember that? We laughed a lot ;-D

Or... the case of a disk clone you stuff into new hardware (because
the old one went down in flames, and you back up by mirroring the
disk). Absolutely the same hardware... just a different MAC address.
If you haven't had that fun of a customer calling in panic because
of that, you haven't been for long enough in business. And I can't
really blame the customer for fucking up here.

> You appear to think that the old behaviour (the first NIC discovered
> gets named eth0) is the only sensible behaviour because everyone is
> always tinkering with the hardware, swapping boards out etc. as you do.
> If that is really important, why not just write a script to clean
> /etc/udev/rules.d/70-persistent-net.rules at every reboot.
> That solves your problem, but allows other people to have a default
> system that can sensibly give a stable configuration on machines
> that have more than instance of each type of hardware (multiple
> NICs, burners, USB devices.

Note that I'm not pro or against "the new way" of doing things, but
very much miffed by the arrogant stance "My Way Is The Only Right
Way". I always recommend: "study, understand, decide". And for
$DEITY's sake, show some respect for those deciding otherwise. If
they seem like idiots to you, it just might be more your problem
than theirs.

Peace
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlc8LM8ACgkQBcgs9XrR2kZ4MgCfQSnjPs4BM8VCz7dw9EG6tHr5
en8AnAhXGwrhlzNS2JeHWdhVjdx8gM3+
=1vsC
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#168034 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	David Wright <deblis@lionunicorn.co.uk>
Date	2016-05-18 19:30 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rAdsd-54h-1@gated-at.bofh.it>
In reply to	#167992

On Wed 18 May 2016 at 10:50:23 (+0200), tomas@tuxteam.de wrote:
> On Tue, May 17, 2016 at 11:22:29AM -0500, David Wright wrote:
> > On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
> 
> [...]

What was snipped is "I do not see that as a disadvantage, udev can do
that much unwanted damage all by itself."

> > You don't see any disadvantage to removing the "hotplug stuff".
> > Hooray, let's go back to PCs as static boxes. Shut it down to add
> > a USB device. Who needs udev anyway?
> 
> This is the typical red herring which helps heating up those
> discussions. *You* see an advantage. *You* use it. Gene doesn't
> Everyone is happy. Once you introduce this idiotic "we" as in
> "let's go back...", things get messed up. The optimum set up
> may vary from person to person (and *will* vary: if you have
> a laptop with two USB hubs hanging off it, with three Ethernet
> dongles randomly distributed in there, your requirements
> envelope will differ from Gene's, who has a pretty stable
> hardware setup once it's shaken out).
> 
> So there's an answer to your rhetorical question anyway:
> "some need it, some need it not".

What that snipped line conveys to me is:
"Yes, [udev's stable naming of interfaces] its a certified PITA and
needs fixed by debian or the maintainer."

"So when udev screws me, I an not able to access anything or anybody
to ask what hapoened."

"I guess the udev way is the way it will be, but in that event, the
bug, a huge one, needs a fixit script included with udev"

"And its far simpler to maintain than all the moving targets udev and
dhcp can be and are giving us, IMO just to harrass the long time
users, which it does a fine job of."

If that's happy...

> > A previous time this reference was pointed out to you, you realised
> > that it has no relevance to wheezy. Even if you upgrade to jessie,
> > it's of little relevance as Debian preserves the existing behaviour
> > if you don't try to wreck it/second-guess it/believe every posting on
> > the internet.
> 
> Tries. That's the word.
> 
> > If you remember that far back, the linux kernel, faced with two NICs,
> > would toss a coin before naming one eth0 and the other eth1. This had
> > the splendid side-effect that you could think your LAN was the WAN and
> > vice versa, and there was nothing you could do about it.
> 
> Been there, done that (many moons ago, I was part of a small group of
> people doing the software for a Debian based PC based router box, and
> had to "solve" exactly this problem. There was no udev back then.
> 
> So I pretty well *know* what udev is trying to solve in this case, and
> *know* there's no "simple" policy which will always do what the user
> wants/expects.

Wants, no. Expects, yes. udev's stable naming of interfaces was
documented in the squeeze Release Notes (4.6.2) for people who were
used to the previous behaviour. It's then newish behaviour was not a
bug, and was not designed to cause grief for anyone.

> > udev meant that each NIC always got the same name even if you took it
> > out of the box one week and put it back the next. It is easy to
> > override that behaviour if it's undesired.
> 
> Yeah, right. Based on the NIC's MAC address. Enter virtual machines,
> which basically throw dice to come up with a MAC: every boot, a new
> interface. Remember that? We laughed a lot ;-D
> 
> Or... the case of a disk clone you stuff into new hardware (because
> the old one went down in flames, and you back up by mirroring the
> disk). Absolutely the same hardware... just a different MAC address.
> If you haven't had that fun of a customer calling in panic because
> of that, you haven't been for long enough in business. And I can't
> really blame the customer for fucking up here.
> 
> > You appear to think that the old behaviour (the first NIC discovered
> > gets named eth0) is the only sensible behaviour because everyone is
> > always tinkering with the hardware, swapping boards out etc. as you do.
> > If that is really important, why not just write a script to clean
> > /etc/udev/rules.d/70-persistent-net.rules at every reboot.
> > That solves your problem, but allows other people to have a default
> > system that can sensibly give a stable configuration on machines
> > that have more than instance of each type of hardware (multiple
> > NICs, burners, USB devices.
> 
> Note that I'm not pro or against "the new way" of doing things, but
> very much miffed by the arrogant stance "My Way Is The Only Right
> Way". I always recommend: "study, understand, decide". And for
> $DEITY's sake, show some respect for those deciding otherwise. If
> they seem like idiots to you, it just might be more your problem
> than theirs.

Please point out where I've taken an arrogant stance on "My Way" of
doing things (and not just in this thread, if you wish).

There *is* a Debian Way. There has to be a defined, preferably
documented, default behaviour. But when I don't agree with the choices
Debian made, I don't claim that things are now broken, and that they
were broken to give me grief. Is it wrong to defend against such
accusations?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#167964 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

From	Elimar Riesebieter <riesebie@lxtec.de>
Date	2016-05-17 19:30 +0200
Subject	Re: /etc/init.d/networking does not start everything in /etc/network/interfaces
Message-ID	<rzQYH-7s5-35@gated-at.bofh.it>
In reply to	#167957

* Gene Heskett <gheskett@shentel.net> [2016-05-17 11:26 -0400]:

[...] 
> Because of some rare condition, you make 
> all the other users with a less rare condition suffer?

I was just talking about facts, nothing else. If you open
/etc/init.d/networking (ifupdown_0.7.8) in an editor and scroll down
to a line containing "log_warning_msg" (must be line number 157 and
173) you see what the wheezy standard is......

Elimar
-- 
  Experience is something you don't get until
  just after you need it!

[toc] | [prev] | [next] | [standalone]

#167974

From	Gene Heskett <gheskett@shentel.net>
Date	2016-05-17 21:20 +0200
Message-ID	<rzSH7-aP-17@gated-at.bofh.it>
In reply to	#167964

On Tuesday 17 May 2016 13:26:35 Elimar Riesebieter wrote:

> * Gene Heskett <gheskett@shentel.net> [2016-05-17 11:26 -0400]:
>
> [...]
>
> > Because of some rare condition, you make
> > all the other users with a less rare condition suffer?
>
> I was just talking about facts, nothing else. If you open
> /etc/init.d/networking (ifupdown_0.7.8) in an editor and scroll down
> to a line containing "log_warning_msg" (must be line number 157 and
> 173) you see what the wheezy standard is......
>
> Elimar

I did somewhat better that that, I set VERBOSE=yes in that script,
and got this: (word wrap off)

root@coyote:/etc/network# geany ../init.d/networking (to set verbose=yes)
root@coyote:/etc/network# service networking restart
[warn] Running /etc/init.d/networking restart is deprecated because it may not re-enable some interfaces ... (warning).
[....] Reconfiguring network interfaces...run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/avahi-autoipd
run-parts: executing /etc/network/if-down.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-down.d/upstart
run-parts: executing /etc/network/if-down.d/wpasupplicant
Configuring interface eth0=eth0 (inet)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/avahi-autoipd
run-parts: executing /etc/network/if-down.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-down.d/upstart
run-parts: executing /etc/network/if-down.d/wpasupplicant
 ip route del default via 192.168.71.1  dev eth0 2>&1 1>/dev/null || true 
ip -4 addr flush dev eth0 label eth0
ip link set dev eth0 down
run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/avahi-daemon
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/avahi-daemon
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
Configuring interface eth0=eth0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.71.3/255.255.255.0 broadcast 192.168.71.255 	  dev eth0 label eth0
ip link set dev eth0   up
 ip route add default via 192.168.71.1  dev eth0 
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant
Configuring interface eth1=eth1 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.1.3/255.255.255.0 broadcast 192.168.1.255 	  dev eth1 label eth1
RTNETLINK answers: File exists
Failed to bring up eth1.
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/clamav-freshclam-ifupdown
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant
done.
====================
It makes no attempt to shut down eth1, so of course it exists.

Here is the REAL bug.

Now, who gets to fix it as I don't know as I can do it correctly.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

/etc/init.d/networking does not start everything in /etc/network/interfaces

Contents

#168032 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#168035 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#168051 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167972

#167976 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167944

#167947 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167949 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167950 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167951

#167953 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167955 — RE: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167956

#167957

#167960 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167969

#167992 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#168034 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167964 — Re: /etc/init.d/networking does not start everything in /etc/network/interfaces

#167974