Re: How does one create virtual ethernet devices with modern tools on Debian 8 (jessie)?
Tom Browder <tom.browder@gmail.com> wrote:
> On Fri, Aug 25, 2017 at 09:26 Sven Hartge <sven@svenhartge.de> wrote:
>>
>> Tom Browder <tom.browder@gmail.com> wrote:
>>
>> Before we start:
>>
>> "virtual ethernet devices" are something totally different than you are
>> doing here. You just want to put multiple IP addresses on one interface.
>>
>> "virtual ethernet devices" are for example used with virtualization or
>> docker, to connect an isolated VM or container through the host to the
>> network.
>>
>> > Although not yet implemented (for fear of messing my remote host up),
>> > the following has been recommended:
> ...
>> > # The primary network interface
>> > allow-hotplug eth0
>> > auto eth
>>
>> One of "allow-hotplug" or "auto", not both
> Any preference for either line?
See what Greg wrote.
> Thanks, Sven, very helpful. Can you recommend a good modern book on networking?
The topic is quite broad today, I don't have general (or any)
recommendation at the moment.
>> > So how does one do the same thing with "modern" tools?
>>
>> I don't understand the question. Do you mean "systemd-networkd"?
> I'm indirectly referencing a long-running thread on this list about
> using ifconfig versus "modern" tools for viewing the current
> interfaces setup.
When using /e/n/interfaces and ifupdown you don't really come in contact
with "ip" or "ifconfig" directly.
> And just how does one restart the new interfaces with systemctl?
You don't. Commands like "service networking restart" have been
deprecated and partially non-functioning since at least Wheezy, because
of the internal limit of ifupdown itself.
> If I mess something up, is there any way to ssh into the remote
> system?
Unless you have an out-of-band login, for example via seriel console,
networked KVM switch or iLO/iDRAC: no. If you break the network
configuration on a hosted server, you either pay the hoster to fix it or
boot into the rescue system the hoster hopefully provides, allowing you
to mount your filesystems and fix it manually.
I, years ago, scripted a wrapper using "at" and a known-good backup
configuration, which would be copied into place and the server rebootet
if I didn't stop the at-job. That way, if I broke the configuration, I
knew the server would reboot in X minutes and be reachable again,
sparing me the drive to the housing place in the middle of the night to
fix the system.
Right now I am in the very fortunate situation of only having systems
with out-of-band management services available, removing the fear of
screwing something up fatally.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Reply to: