Re: debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

Thank you for your mail.

On Wed, Mar 27, 2024 at 12:42 AM Andy Smith  wrote:
> On Tue, Mar 26, 2024 at 06:33:42PM +0100, Steffen Dettmer wrote:
> > I changed a gateway on a remote site using /etc/network/interfaces by
> > changing gateway. However, at reboot some old gateway IP reappears. I
 I also think that there is some Debian packaging rule about one
> package not altering the config file of another package unless by
> co-operation between the maintainers, so if this does actually turn
> out to be Debian there might be bugs to report.

Thanks to Pierre-Elliott it became clear that this was caused
by a virtualisation platform, so to say "change from outside",
and thus I found nothing related "inside".
(This is a Proxmox feature to setup containers, and someone
made a mistake in the Proxmox configuration;so nothing
wrong in Debian at all)

Steffen

Re: debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

Thank you for your quick reply.

On Wed, Mar 27, 2024 at 12:22 AM Henning Follmann
 wrote:
> On Tue, Mar 26, 2024 at 06:33:42PM +0100, Steffen Dettmer wrote:
> > I changed a gateway on a remote site using /etc/network/interfaces by
> > changing gateway. However, at reboot some old gateway IP reappears. I
> > I have no clue where the wrong 2.43 comes from.
> [...] deleted that nonsense.
Nonsense? I think the lines illustrate the issue to the
experienced eye and in fact, it did, so that Pierre-Elliott
spotted the issue (I tell it in a second).

> why are you making it so difficult to anyone trying to help you?

I don't know, surely not intentional. I just ran out of ideas.

> Nobody is interested in your way how you edit that file.

Sure, except: Emacs or Vim, which is better?
(Just kidding :))

> please show us two versions of that file (pre reboot and after)
> Also tell us any programs you use to manage your network settings

I had told I would use vim to edit the file... but I had been wrong!
The machine I SSH'd to in fact was not a machine, but rather
a container, and the network configured by the virtualisation
environment! That is what changes the IP. The container op
made an error in the IP and I was the unfortunate one just
arriving in time :)

> [] NetworkManager
> [] systemd-networkd
> [] some magic own  scripts
> [] ...
[x] vim
[x] Proxmox (but I didn't know this)
(*1)

(*1) don't work together well :)

Regards,
Steffen

Re: debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

On Tue, Mar 26, 2024 at 11:27 PM Dustin Jenkins  wrote:
> On my Debian 12 system, the connman service was helping itself to interfaces, 
> including my bridge interfaces that I wanted left alone.  Maybe try disabling 
> or removing it?
>
> sudo systemctl stop connman
> sudo systemctl disable connman

Thank you for your help! Yes, good idea!
  (I don't have it, but a good point. Related, I
  read often in internet of similar possible issues with
  some network manager versions)

I couldn't see the cause in the whole file system, and as
Thankfully Pierre-Elliott Bécue correctly saw from a wide
distance that this is because - it is in fact not in the
file system. But outside. Namely a virtualisation
environment set it into a container (the machine
actually is "just" a container).

Regards,
Steffen

Re: debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

Thank your for your quick and detailed reply.

On Tue, Mar 26, 2024 at 7:01 PM Greg Wooledge  wrote:
> On Tue, Mar 26, 2024 at 06:33:42PM +0100, Steffen Dettmer wrote:
> > I changed a gateway on a remote site using /etc/network/interfaces by
> > changing gateway. However, at reboot some old gateway IP reappears.
>
> So then the question is *which* of the many different subsystems is in
> use to set the system's default gateway.  It might be coming from /e/n/i
> or from NetworkManager or from systemd-networkd or others.

Yes, but I found nothing in any logfile, the IP did not appear anywhere
in the file system and I had no idea what to do...

It turned out the machine actually is a virtualisation container
and the infrastructure configures the IP (which was incorrectly set in the
virtualization web GUI). Well, and I didn't see this, but
fortunately Pierre-Elliott Bécue (from this list) saw it instead.

> > root@site4-nas:~# ls -l /etc/network/interfaces
> > -rw-r--r-- 1 root root 117 Mar 26 18:19 /etc/network/interfaces
> > root@site4-nas:~# grep gateway /etc/network/interfaces
> > gateway 192.168.2.43
>
> See, that's not useful.  That's not how this file is structured.  It's
> NOT just a series of independent lines.

Yes, thanks, sure, I know. I just wanted to show that it does change
automagically at reboot (it is written by virtualisation environment
when the container is being started). The stanza was correct,
just gateway IP was wrong, because someome made an error
in the container configuration and it just so happend that it was
my little foot where it fell onto...

Best regards,
Steffen

Re: debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

On Tue, Mar 26, 2024 at 7:18 PM Pierre-Elliott Bécue  wrote:
> As it's a PVE kernel I guess you rely on Proxmox.
> *Theoretically*, Proxmox VE uses /etc/network/interfaces.new to apply

THIS! (OMG why didn't I see this! Thank you!!)

ohh thanks so much for your quick reply, my "machine" indeed is a
Proxmox-Container, and someone made a typo in the container settings,
so Proxmox configures the container accordingly.
For other files, like resolv.conf, Proxmox adds "# --- BEGIN PVE ---"
lines, but not in interfaces.

Thank you
Steffen

debian12: something destroys /etc/network/interfaces at boot

[Steffen Dettmer]

Hi,

I changed a gateway on a remote site using /etc/network/interfaces by
changing gateway. However, at reboot some old gateway IP reappears. I
really hate when some magic knows better than an explicitly set value.
What happens here? How can I get rid of this? It is 100% reproducible.

I have no clue where the wrong 2.43 comes from.

Any hints appreciated!

Steffen


root@site4-nas:~# ls -l /etc/network/interfaces
-rw-r--r-- 1 root root 117 Mar 26 18:19 /etc/network/interfaces
root@site4-nas:~# grep gateway /etc/network/interfaces
gateway 192.168.2.43
root@site4-nas:~# perl -npi -e 's/gateway 192.168.2.43/gateway
192.168.2.1/' /etc/network/interface
s
root@site4-nas:~# grep gateway /etc/network/interfaces
gateway 192.168.2.1
root@site4-nas:~# ls -l /etc/network/interfaces
-rw-r--r-- 1 root root 116 Mar 26 18:21 /etc/network/interfaces
root@site4-nas:~# sync
root@site4-nas:~# date; sleep 1m; date
Tue Mar 26 06:21:47 PM CET 2024
Tue Mar 26 06:22:47 PM CET 2024
root@site4-nas:~# ls -l /etc/network/interfaces
-rw-r--r-- 1 root root 116 Mar 26 18:21 /etc/network/interfaces

OK, so gateway is correct in 18:21 timestamped user config file. Lets reboot.

root@site4-nas:~# reboot
root@site4-nas:~# Connection to site4-nas closed by remote host.
Connection to site4-nas closed.
root@site4-pve:~# ssh site4-nas
Linux site4-nas 6.5.11-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-8
(2024-01-30T12:27Z) x86_64...
Last login: Tue Mar 26 18:20:50 2024 from 192.168.2.28
root@site4-nas:~# ls -l /etc/network/interfaces
-rw-r--r-- 1 root root 117 Mar 26 18:23 /etc/network/interfaces
root@site4-nas:~# grep gateway /etc/network/interfaces
gateway 192.168.2.43

root@site4-nas:~# find /etc /lib/systemd/ /var/lib/ -type f -print0 |
xargs --null grep 192.168.2.43
/etc/network/interfaces:gateway 192.168.2.43

user config file has updated timestamp and contains bougous gateway.

Help please!

Re: Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

Hi,

thanks for your reply.

On Tue, Oct 22, 2019 at 5:45 AM Peter Wiersig  wrote:

> Steffen Dettmer  writes:
> > So you propose not to use init.d scripts. I usually prefer a simple shell
> > script that is easy to test, systemd is just way to complex.
>


> Like Greg says, systemd units are really much simpler.
>

Thank you for your opinion. I'm sure it is fully true in your context.


> The thing with the compatibility mode is that that part has do *guess*
> what the init.d tries to call and adapt that to its inner working and
> can fail.
>

Not sure if on topic, but I what is needed to guess, it should run the
scripts in order of their rcX/Snn number? I though the difficulty
would be to use a suited nn number (and in fact, if my init.d script
would get started at all it won't work because of a missing user as
it is started before pam ldap - this are places where I expect problems,
not at the attempt to run or not at all).
 it's documentation with Debian 9 (stretch) is in


> "If your distribution removes SysV init scripts in favor of systemd unit
> files typing "/etc/init.d/foobar start" to start a service will not
> work, since the script will not be available. Use the more correct
> "/sbin/service foobar start" instead, and your command will be forwarded
> to systemd."
>

In my case, the script does exist and I can call it manually. The problem
is that it sources lsb functions that source "hooks" which includes
some s40systemd-wrapper (or such) which calls "exit 0" instead of
letting the sourcing script continue.
Unless DPKG_MAINTSCRIPT_PACKAGE is set.


> There are many more details on that page and maybe buried in there is a
> hint why the init.d you have does not work.
>

Technically it is clear, because some sourced systemd script calls some
exit 0, since sourced, it does not terminate the sourced script, but also
the calling script.

Maybe it is a bug that it exits. Maybe it is a bug that it exits in my
situation.
I noticed that it does not exits when DPKG_MAINTSCRIPT_PACKAGE is
set. This suggests me that there must be some trick (even if fragile).
(Since its not most recent and systemd I think it makes no sense to
file a bug report, I just tried to understand and get it working).

>> https://wiki.debian.org/systemd#Failed_units
> >> HINT: Extensive debugging information about systemd is on this
> >> FreeDesktop page.
> https://freedesktop.org/wiki/Software/systemd/Debugging/
> >
> > I didn't find anything about init.d or DPKG_MAINTSCRIPT_PACKAGE in these
> > pages.
>
> Correct, as they are about systemd units/services/timers etc.
>

(These places were mentioned as points where to read, I just told that
I read them but still did not understand whats happening and especially
if it is a bug, or what kind of bug I'm facing)
So although systemd is assumed to be simple, my issue
"just start a script" still isn't solved, even with all the help from this
list,
so I think under the hood things are more complex than they seem to be.

 > Only I found using "status", but this does not help either:

> >
> >   root@node17-0:/etc/init.d# systemctl status gitlab-runner2.service
> >   - gitlab-runner2.service
> >  Loaded: not-found (Reason: No such file or directory)
> >  Active: inactive (dead)
>
> Was the ...-runner2 intentional? Your other quoted error showed
> "gitlab-runner.service".
>

Yes, it was. I patched the gitlab-runner script to set
DPKG_MAINTSCRIPT_PACKAGE,
and installed a gitlab-runner2 without that.


> > funny that it does not even tell WHICH file was not found and why it was
> > loaded anyway.
>
> Yeah, that's probably jessies ancient systemd at fault.


systemd is from 2010, so in Debian 8 it should be somewhat
stable already I think.


> Newer output is more detailed and looks like that:
>
>server:/etc/apt/sources.list.d# systemctl status atd.service
>  ● atd.service - Deferred execution scheduler
> Loaded: loaded (/lib/systemd/system/atd.service; enabled; vendor
> preset: enabled)
> Active: active (running) since Wed 2019-07-24 04:48:30 CEST; 2
> months 29 days ago
>   Docs: man:atd(8)
>   Main PID: 570 (atd)
>   (...)
>

I think in Debian 8 / Jessie it looks the same, IF it works.
Here my problem is, that it does NOT work :(

But as already said, maybe with systemd its impossible
to get init.d script running correclty so that I need to
write such a unit file (using Devuan is no option here).

> There is no such file "gitlab-runner.service" (I tried "find /etc" and
> > "locate").
> > It seem that some systemd magic applies here. Maybe, if its content is
> > needed for technical reasons, systemd crea

Re: Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

On Mon, Oct 21, 2019 at 9:32 PM Greg Wooledge  wrote:

> On Mon, Oct 21, 2019 at 09:26:57PM +0200, Steffen Dettmer wrote:
> > On Mon, Oct 21, 2019 at 3:27 PM Greg Wooledge 
> wrote:
> > > This is not correct.  Debian's systemd will use init.d scripts in
> > > compatibility mode.
> >
> > Ahh, this sounds good! But how to do that correctly?
>
> wooledg:~$ systemctl status exim4
>

as I already explained in detail, this does not work.

Steffen

Re: Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

Hi,

thanks for your reply.

On Mon, Oct 21, 2019 at 3:27 PM Greg Wooledge  wrote:

> > But probably
> > for Debian you are right, if I understood correctly, newer versions do
> not
> > even support init.d / LSB anymore, so using systemd units seems to be
> > required there.
>
> This is not correct.  Debian's systemd will use init.d scripts in
> compatibility mode.


Ahh, this sounds good! But how to do that correctly?

Installing the script and calling insserv does not work; by reading the
wrapper scripts I accidentally found that it works with I set
DPKG_MAINTSCRIPT_PACKAGE, otherwise it does not work.
I found no hint in the documentation and no helpful error messages
in the places pointed by it.
What am I missing?

Steffen

Re: Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

Hi,

thanks for your reply.

On Sun, Oct 20, 2019 at 10:26 PM Peter Wiersig 
wrote:

> 5.)
> Instead of init.d scripts create systemd units.
> https://wiki.debian.org/systemd#Creating_or_altering_services

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


So you propose not to use init.d scripts. I usually prefer a simple shell
script that is easy to test, systemd is just way to complex. But probably
for Debian you are right, if I understood correctly, newer versions do not
even support init.d / LSB anymore, so using systemd units seems to be
required there.

About your gitlab-runner.service failure:
>
> https://wiki.debian.org/systemd#Failed_units
> HINT: Extensive debugging information about systemd is on this
> FreeDesktop page. https://freedesktop.org/wiki/Software/systemd/Debugging/


I didn't find anything about init.d or DPKG_MAINTSCRIPT_PACKAGE in these
pages.
I just see that I'm supposed to reboot (!) with special parameters to debug
a shell script.

Only I found using "status", but this does not help either:

  root@node17-0:/etc/init.d# systemctl status gitlab-runner2.service
  - gitlab-runner2.service
 Loaded: not-found (Reason: No such file or directory)
 Active: inactive (dead)

funny that it does not even tell WHICH file was not found and why it was
loaded anyway.
I tried "journalctl -b > journal.txt" and found in journal.txt several
blocks like that:

  09:40:09 node17-0 systemd[1]: Started LSB: gitlab-runner.
  09:40:09 node17-0 gitlab-runner[17967]: Starting multi-runner from
/local/users/sdettmer/work/_gitlab/config.tom   l ...  builds=0
...
  09:44:08 node17-0 systemd[1]: Stopping LSB: gitlab-runner...
  09:44:08 node17-0 gitlab-runner[17967]: WARNING: Requested service stop:
terminated builds=0
  09:44:08 node17-0 gitlab-runner[17967]: All workers stopped. Can exit now
  builds=0
  09:44:08 node17-0 gitlab-runner[10318]: Stopping GitLab Runner:.
  09:44:08 node17-0 systemd[1]: Stopped LSB: gitlab-runner.

which does not give any hint (except that it works with
DPKG_MAINTSCRIPT_PACKAGE set).

The string "gitlab-runner2" does not appear anywhere in the whole file at
all.

Any other places where I could look?

What is in gitlab-runner.service on that one server anyways?
>

There is no such file "gitlab-runner.service" (I tried "find /etc" and
"locate").
It seem that some systemd magic applies here. Maybe, if its content is
needed for technical reasons, systemd creates some "virtual unit" on the
fly, who knows.


> Somewhen in 2016-2018 someone on debian planet posted multiple blogs of
> a great systemd introduction series, I can't find my bookmark right now
> :(
>

What a pitty, I though init.d scripts would be in support of systemd, but
apparently they are not anymore :(
So in future portable packages won't be that easy.

Steffen

Re: Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

Hi,

thank you for your reply.

On Fri, Oct 18, 2019 at 3:34 PM Jonas Smedegaard  wrote:

> Quoting Steffen Dettmer (2019-10-18 15:17:10)
> > in short: how to use "init.d" scripts on Debian?
>
> In short:
>
>   service $SERVICE stop
>

Thanks for the tip. man insserv does not tell about service, and neither
man init.

Anyway, it does not work.

I created a new file and:

  root@node17-0:/etc/init.d# service gitlab-runner2 start
  Failed to start gitlab-runner2.service: Unit gitlab-runner2.service
failed to load: No such file or directory.

(It is a 230 line wrapper to call a shell script with a single parameter,
which calls a binary with more than 100 command line options - to call a
shell script. Unfortunately, no --debug or --verbose. Using strace showed,
that this binary seems to send socket commands only, so it seems it
communicates with some complex server. To start a shell script with a
single parameter. And it does not work.)


> > in detail:
> >
> > On one server a init.d script with LSB header does not work, at least
> > when started by command line.
>
> Diving into the rabbit hole of messing directly with those files,


Unfortunately I don't understand what you mean.
Do you mean, I shall not have any own software on Debian?


> I suggest to start here:

  man service


Obviously, the man page is outdated. Tracing the service script (bash -x)
shows 83 lines of output ending with:

  exec systemctl start gitlab-runner2.service

so actually the script delegates to "systemctl", which is something from
systemd, which is not described in the man page at all.

I still think systemd makes some magic when called with
DPKG_MAINTSCRIPT_PACKAGE set...

Steffen

Debian 8 how to install and run init.d scripts?

[Steffen Dettmer]

Hi,

in short: how to use "init.d" scripts on Debian?

in detail:

On one server a init.d script with LSB header does not work, at least when
started by command line. I traced down the following:

#1 init.d/script sources /lib/lsb/init-functions

#2 /lib/lsb/init-functions has support for hooks:
  # Include hooks from other packages in /lib/lsb/init-functions.d
  for hook in $(run-parts --lsbsysinit --list /lib/lsb/init-functions.d
2>/dev/null); do
  [ -r $hook ] && . $hook || true
  done
and, among others, sources /lib/lsb/init-functions.d/40-systemd

#3 /lib/lsb/init-functions.d/40-systemd first implements some
anti-debugging technique by checking PPID for being init to ensure that
testing on command line might gain different results than interactive
testing:

 # Redirect SysV init scripts when executed by the user
 if [ $PPID -ne 1 ] && [ -z "${init:-}" ] && [ -z
"${_SYSTEMCTL_SKIP_REDIRECT:-}" ]; then

then seem to check if a service unit with same name as init.d script can be
used instead (I guess):

case $(readlink -f "$0") in
/etc/init.d/*)
_use_systemctl=1
# Some services can't reload through the .service file,
# but can through the init script.
prog=${0##*/}
service="${prog%.sh}.service"
if [ "$(systemctl -p CanReload show $service 2>/dev/null)"
= "CanReload=no" ] && [ "${1:-}" = "reload" ]; then
_use_systemctl=0
fi
;;
esac

for some reason  use_systemctl=0 is set back only if second parameter is
"reload", so when it is e.g. "start",  use_systemctl remains 1 in my case.

#4   /lib/lsb/init-functions.d/40-systemd then with  use_systemctl=1
performs:

  if [ "$_use_systemctl" = "1" ]; then
  # Some init scripts use "set -e" and "set -u", we don't want that
  # here
  set +e
  set +u

  if  [ "x$1" = xstart -o \
  "x$1" = xstop -o \
  "x$1" = xrestart -o \
  "x$1" = xreload -o \
  "x$1" = xforce-reload -o \
  "x$1" = xstatus ] ; then

  systemctl_redirect $0 $1
  exit $?
  fi
  fi

which in my case fails with:

  +++ /bin/systemctl start gitlab-runner.service
  Failed to start gitlab-runner.service: Unit gitlab-runner.service failed
to load: No such file or directory.

(just for the records, I like "set -e" and I do want that in general).

As a workaround / hack I set DPKG_MAINTSCRIPT_PACKAGE=HACK_ACTIVE. In
contrast to my expectation, the scripting then did not do nothing as
expected and let the main script work, but instead  /bin/systemctl start
gitlab-runner.service was still executed but now successfully!

It seems that the "hook" as a side effect changes my system if for example
DPKG_MAINTSCRIPT_PACKAGE=NO is set, can this be the case?

My questions:

1) How is this supposed to work? Is this some systemd hack that generates
some virtual service units because systemd actually cannot run init.d
scripts correctly?

2) Why do I need to set DPKG_MAINTSCRIPT_PACKAGE? Where is it documented
how DPKG_MAINTSCRIPT_PACKAGE influences systemd?

3) Why does systemd depend on DPKG_MAINTSCRIPT_PACKAGE? Is this a systemd
generic or a Debian 8 specific dependecy?

4) Is DPKG_MAINTSCRIPT_PACKAGE set by dpkg during installation, so that the
hack normally is invisible as long as not installing packages in any
different way (i.e. no "make install")?

and most important:

5) How to install, use, maintain and run init.d scripts at all?
I have the feeling that every time I'm facing a problem with running a
little simple daemon since a couple of years I end up in debugging script
code over script code, so I'm doing it wrong (and so do the packages I use).
How to do it right?
I'm afraid this depends on the Debian version as well, so what works for
Debian 8 can fail with Debian 10. Is there some documentation explaining
how to do that, how to maintain init.d scripts for Debian or even "Linux"
in general?

Any hints / links appreciated.

Steffen

Re: Why do UID values of system users matter?

[Steffen Dettmer]

Hi,

thanks for your quick reply.

I see, multiboot with different /etc but shared /usr or /local could invite
a lot of trouble if using different UIDs, indeed! Thanks for the quick
explanation.

> (Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 /
> > Stretch).
>
> AFAICS, user "man" has had UID 6 since at least Debian 6/squeeze
>

 Ohh, this is interesting, so I wonder why I had a different value then,
maybe something else was wrong with my system then...

Steffen

Re: Debian Wiki and LSB (https://wiki.debian.org/LSB)

[Steffen Dettmer]

Hi,

ok, thank you for your quick reply! I hope it is OK to edit there. To avoid
confusion I added a hint with a link to https://lwn.net/Articles/658809/
and updated the following WikiTopics:

- https://wiki.debian.org/LSB
- https://wiki.debian.org/DebianLsb
- https://wiki.debian.org/LsbRuntimeCompliance
- https://wiki.debian.org/LSBInitScripts
- https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

It would be great if someone experienced could take a look. Especially the
last two pages could need more updating, since AFAIK init.d scripts
unfortunately are superseeded by systemd units.

Steffen


On Fri, Aug 16, 2019 at 11:19 PM Roberto C. Sánchez 
wrote:

> On Fri, Aug 16, 2019 at 11:15:32PM +0200, Steffen Dettmer wrote:
> >Hi,
> >is the "Debian Wiki" at  [1]https://wiki.debian.org/ "official"? If
> so, I
> >hope here is the right place to ask. The wiki at e.g.
> >[2]https://wiki.debian.org/LSB tells "Currently all major
> distributions
> >comply with the LSB" and [3]https://wiki.debian.org/DebianLsb tells
> >"Debian strives to follow and comply with the Linux Standard Base".
> This
> >are high ranked google hits for searching "debian lsb".
> >I though Debian essentially dropped (almost all) LSB compliance.
> >Is the Wiki just outdated or is LSB support back?
> >Steffen
>
> The first page has not been updated in over 10 years and the second page
> in over 9 years.  They are definitely outdated.
>
> Regards,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>

Why do UID values of system users matter?

[Steffen Dettmer]

Hi,

just for my curiosity I wonder why the numeric UID values matter at all,
for example:

  update-passwd has found a difference between your system
  accounts and the current Debian defaults. It is advisable to
  allow update-passwd to change your system; without those
  changes some packages might not work correctly. For more
  documentation on the Debian account policies, please see
  /usr/share/doc/base-passwd/README.

  The proposed change is:

  Change the UID of user "man" from 13 to 6

(Apparently man used uid 13 in Debian 8 / Jessi but 6 in Debian 9 /
Stretch). Normally I would assume that the numeric values would not be use
anywhere at all, only the symbolic names.
If the numeric value matters, why are their values no kept across releases?

Steffen

Debian Wiki and LSB (https://wiki.debian.org/LSB)

[Steffen Dettmer]

Hi,

is the "Debian Wiki" at  https://wiki.debian.org/ "official"? If so, I hope
here is the right place to ask. The wiki at e.g. https://wiki.debian.org/LSB
tells "Currently all major distributions comply with the LSB" and
https://wiki.debian.org/DebianLsb tells "Debian strives to follow and
comply with the Linux Standard Base". This are high ranked google hits for
searching "debian lsb".

I though Debian essentially dropped (almost all) LSB compliance.

Is the Wiki just outdated or is LSB support back?

Steffen

Re: Static IP not working ("connmand" problem)?

[Steffen Dettmer]

Hi,

On Sun, Aug 20, 2017 at 8:09 PM, Sven Hartge  wrote:
>> How to configure static IP? network/interfaces as in [1] seem not to
>> work because of a "connmand".
>
> connmand? The package "connman" is not contained in the default
> installation of Debian.

Thank you for your help. Just to report my final result, after
removing the package and rebooting the system, it seems to work fine!
I didn't made a test with unavailable DHCP yet but I think it will
pass, logs look better now.

So what I think what had been left open:
- how came the package onto this system?
- the Wiki documentation of network config is imprecise / incomplete
As I did not fully understand the issue, I think I better not update the Wiki.

Steffen

Re: Static IP not working ("connmand" problem)?

[Steffen Dettmer]

On Sun, Aug 20, 2017 at 8:09 PM, Sven Hartge  wrote:
>> How to configure static IP? network/interfaces as in [1] seem not to
>> work because of a "connmand".
>
> connmand? The package "connman" is not contained in the default
> installation of Debian.
>
>> What is "connmand", where can I learn more about it, and why is it
>> installed at all? Can I / should I simply "apt-get purge" it?
>
> You can remove it. You will then see which package depends on it. From
> the dependencies I can see it may be pulled in via "lxqt" via the "cmst"
> package.

There were no dependencies shown. So I removed it.

Now the server is unreachable :-(

Steffen

Static IP not working ("connmand" problem)?

[Steffen Dettmer]

Hi,

in short:
How to configure static IP? network/interfaces as in [1] seem not to
work because of a "connmand".

in detail:
I had a failure of my DHCP server and was unable to connect to my
statically configured Debian 8 server. Or at least I intended to
configure static IP. The setup is very simple, just one Ethernet NIC,
static IP and static routing. However I failed to configure it
unfortunately.

According to [1] I configured a "iface eth0 inet static" stanza with
"address 192.168.9.24" etc in /etc/network/interfaces[2] and I though
I would be done, but this seems not work for me.

After fixing DHCP server I checked /var/log/syslog and found during
the fail time:

  Aug 20 18:42:03 lia connmand[1444]: eth0 {del} address
169.254.141.65/16 label eth0
  Aug 20 18:42:03 lia connmand[1444]: eth0 {del} route 169.254.0.0 gw
0.0.0.0 scope 253 

and after fixing DHCP entries change to:

  Aug 20 19:21:24 lia connmand[1444]: eth0 {add} address
192.168.9.24/24 label eth0 family 2
  Aug 20 19:21:24 lia connmand[1444]: eth0 {add} route 192.168.9.0 gw
0.0.0.0 scope 253 

but as said, I have to use static IPs for servers of course (namely to
be safe for DHCP failures).

Except a non helping man page, I found no documentation about
"connmand" (using google). I'm pretty sure that I did a standard
server installation and did not install network manager things
manually, so I have no clue why I have this package installed at all.
Also I found none of the documented configuration files on disk, but
there is e.g. /etc/init/connman.conf.

I hope someone can answer my questions:

How do I configure a static IP to my server?

Where do I find the log messages about DHCP? I'm used to see DHCP
server IP, max lease time etc.

What is "connmand", where can I learn more about it, and why is it
installed at all? Can I / should I simply "apt-get purge" it?

Is the documentation [1] the wrong place to look? If not, should I
update it according to the replies to my questions?

"dpkg -i connman" tells "Intel Connection Manager daemon" and points
to "https://connman.net;, but there I get ERR_CONNECTION_REFUSED.  Is
this an official debian package at all? Google search seem to suggest
Ubuntu packages only. I hope I didn't somehow to manage to install
Ubuntu packages and messed up something...

Any background info (documentation links) that helps me to understand
what happens would be highly appreciated!

Steffen



[1] 
https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually
[2] /etc/network/interfaces:
allow-hotplug eth0
iface eth0 inet static
  address 192.168.9.24
  netmask 255.255.255.0
  gateway 192.168.9.30

Re: systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Steffen Dettmer]

On Tue, Jan 10, 2017 at 12:51 PM, Dominique Dumont <d...@debian.org> wrote:
> On Monday, 9 January 2017 22:49:02 CET Steffen Dettmer wrote:
>> I'm looking at Jessie (Debian 8) man fsck. I found no refernce
>> to systemd. I think this is some compatiblity feature of systemd.
>
> See  systemd.mount(5) and systemd.swap(5)
>
> Compatiblity is done by systemd-fstab-generator

Thank you, this are very good entry points and explain a lot!

Steffen

Re: systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Steffen Dettmer]

On Tue, Jan 10, 2017 at 1:01 AM, Michael Biebl  wrote:
>>> I'd rather keep it as simple as possible
>>
>> you can still use sysvinit as init

I read that trying to use sysvinit causes trouble and several things
depend on systemd at the moment.

> The shell scripts used by sysvinit are not simpler. More familiar maybe,
> but not simpler.

Simplicity can very roughly approximated by source code size.
Do you think the systemd implementation of the fsck wrapper
is simpler that "fsck -A"?

I hope GNU/Linux forks off as soon as systemd integrates an own
kernel (systemk) and its reimplementation of Wayland (systemx)
in one binary image blob, which for technical reasons will
temporarily be called \EFI\BOOT\BOOTx64.EFI, but only until
UEFI BIOS functionalities are fully integrated. Then you can POST
and fsck in parallel, write units that depend on POST (so X won't
start before POST passed! Imagine that!!) to form a clean, simple
and modern-to-the-max system.

SCNR :-)

Steffen

Re: Systemd: no error but "maintenance mode"

[Steffen Dettmer]

On Sun, Jan 8, 2017 at 7:45 PM, Joe  wrote:
>> What happened before:
>> I had issue with a Debian server SATA bus [1]. I noticed because
>> apt-get upgrade hung, because initramfs updater calls "sync" which
>> hang because of [1]. All operations accessing a certain (backup) disk
>> blocked. Shutdown over network. It was reported server power LED still
>> up, so probably shutdown hang, too. Server was powered off and disk
>> pulled.
>
> The disc you removed: did it have an entry in /etc/fstab? Does this
> server use systemd? If yes to both, comment the /etc/fstab entry or
> give it an extra option 'noauto'.

In short: yes, this was the problem. I didn't found this first because
there was no easily visible error message.

Thanks you for your help!

Do you - or anyone - know how to mount a disk at boot without
failing when it is not there? Like normal "classic" behavior?
Of course I can write a simple script if I somehow manage
systemd to execute it. In the old days there was some rc.local,
surely I find something like this. I just wonder what to put
into fstab that script detects as to be mounted without
systemd aborting when it is missing (without patching
systemd of course)

Longer story (aka "what actually happened"):

The disk I removed had no entry. But I put it into
external USB dock, replacing the disk that there was before
(not assuming an USB disk could be required at all).

The removed USB disk had an entry in fstab, but with "noauto".
Yeah, but unfortunately in wrong format
(I think it was "  noauto noauto 0 0",
but of course noauto is not a valid file type).

And yes, this was the problem. systemd seems to ignore the
check flag and always checks (if auto or unless noauto).
That's why "fsck -a" worked. But systemd does not run fsck -a
but (I guess) implements an own parser for fstab, then does not
even call fsck (which gives a clear error message when it is called
with an non-existing device), so there was no error message
from fsck either (actually fsck would even pass on the
example, which does not matter, since it was not even started).

Then I was in "maintenance mode" with 0 failed units, because
"fs mount unit" does not count in here. Also on Console all
lines were prefixed with "OK".

> Systemd assumes that any local drive
> listed in /etc/fstab without 'noauto' is essential for booting, and will
> drop you to maintenance mode if the drive cannot be found.

Yes, maintenance mode without network. The network card
was available, but not IP configured (an error message about missing
firmware was also present in journal and I assumed it would be the real
problem, but this message seems to be normal).

So my problem was that systemd makes a wrong assumption,
does not report the error well, does not start fsck which would report
and then go to maintenance mode without without remote access
possibility and finally does not show this error as failed unit or on
console. Only in the journal there was an error together with several
others. These others are "normal" for systemd.

This worked well before systemd when some init script just started
"fsck -a && mount -a" :-)

>> Then server did not come up. Now I went to its location with monitor
>> and keyboard. I saw a screen full of boot messages, each line prefixed
>> with green "[OK]". On bottom, I got asked for root password. I though
>> Debian does not use root passwords? I'm old fashioned so fortunately I
>> set one, so I could log in.
>
> Yes, a plain Debian installation will ask you to set a root password.

Ahh good, so this is safe.

> No, there is no special server variant, Debian Stable would normally be
> used, with whatever additional software the user wishes.

Alright, so seems I chose correctly.

Steffen

Re: systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Steffen Dettmer]

Hi,

thank you for your quick reply.

On Mon, Jan 9, 2017 at 1:38 AM, David Wright <deb...@lionunicorn.co.uk> wrote:
> On Sun 08 Jan 2017 at 15:56:36 (+0100), Steffen Dettmer wrote:
>> apparently is ignored and "1" is assumed instead, BUT systemd does not
>> call fsck! fsck parsed the line as intended (pass=0 -> no check), so
>> is all fine.
>
> Why would fsck parse /etc/fstab?

Because man page says so? Because fsck's job is to check fs?
Don't know what systemd interferes at all.

> man fstab   in jessie is pretty long in the tooth (from the days of
> lenny) and might have some clarification of how systemd scans it,
> which does seem to differ from sysvinit's approach.

I'm looking at Jessie (Debian 8) man fsck. I found no refernce
to systemd. I think this is some compatiblity feature of systemd.

> How essential it was to read §5.6.1 in jessie's release notes!

Thanks for pointing this. Indeed. So no need to write a bug
report, already documented :)

I remember similar issues long time ago with messages like
"failed to mount the root file system, dropping an emergency
shell" or alike.

> I think they might usefully have added here a recommendation to
> check /etc/fstab thoroughly for non-compliance with the stricter
> behaviour of systemd. I got caught out by systemd's acting upon
> cruft that sysv happily ignored as redundant.

You cannot check everything everytime. Next time systemd
includes a kernel and you need to migrate boot options... SCNR :)

> A bug report would involve an explanation of exactly what you
> think the bug is, without the words "apparently", "probably",
> "assumed", "intended", "do things itself", etc.

I can explain what I see and wait I expect, but not be sure about
the cause. There are so many possible reasons why an error
message could be missing.
Or it is not a bug at all but a feature, to avoid irritating the emergency
shell users with too much technical details. I'm not familiar with
systemd, surely a source of problems. I just used it because I was
told using sysv on Debian 8 or other recent Linuxes caused more
difficulties. I'd rather keep it as simple as possible.

Steffen

Re: systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Steffen Dettmer]

Hi,

main problem was the disk indeed! Apparently there was a typo in
fstab, probably leading to a parse error (which isn't shown
unfortunately) then the value "0" in the "pass" row for fsck
apparently is ignored and "1" is assumed instead, BUT systemd does not
call fsck! fsck parsed the line as intended (pass=0 -> no check), so
is all fine. I tested with pass=1, then fsck has correct error
behavior and logs a clear error message. But systemd tries to do
things itself and then the chain of bugs and odds start. Maybe systemd
should be dropped until properly implemented (or superseeded).

I think actually this is the main bug: systemd uses /etc/fstab like
fsck and friends do, but wrongly (differently). This even seems to be
a known issue (google found quite a lot of related rants).

Does it make sense to submit a bug report at least for the most
important bugs? Probably not, because the issues seem to be known
already?

Steffen


On Sun, Jan 8, 2017 at 2:56 PM, Steffen Dettmer
<steffen.dett...@gmail.com> wrote:
> Hi,
>
> I think I found some more information.
>
> In short:
> "Failed at step exec spawning /bin/plymouth: no such file or directory"
> but I have no clue why it is suddenly missing or suddenly required.
> I found postings in the internet that simply installing plymouth seems
> not to solve this issue.
>
> What can I do about this?
> Any hints appreciated.
>
> In detail:
> Google suggested "systemctl status". This shows "State: maintenance",
> "Jobs: 0 queued", "Failed: 0 units" and some output looking like
> pstree which tells me nothing.
> Why "maintenance" when there are no fails?
> Is it true that logging, debugging and troubleshooting still is not
> implemented correctly in systemd?
>
> "systemctl --failed" shows "0 loaded units listed". According to man
> page the command is supposed to list failed units, not loaded units,
> so I'm not sure what is true. 0 fails would be good, 0 loaded probably
> be bad. It could explain why I don't get syslog messages.
>
> I also found the command "journalctl -p 3 -xb". man page tells
> something about a so-called "system journal". Man page references some
> desktop stuff (freedesktop.org) and seems to be related to systemd as
> well (seems all my recent issues are systemd issues -  hope it dies as
> fast as upstart). Man page of systemd-journald.service suggests
> systemd invented an own wheel called syslog which does not write to
> /var/log? Man page mentions /var/log/journal/ files, but no such
> directory exists.
>
> "journalctl -p 3 -xb" shows some information in red color, in reverse
> order assuming the later the more important:
> 1) "r8169 firmware: failed to load rtl_nic/rtl8168g-2.fw"
> but eth0 is state UP, so should be fine. At least I should get a
> normal local login prompt.
>
> 2) "Failed at step exec spawning /bin/plymouth: no such file or directory"
> Google suggest this is some graphical whatever, so I think it would be
> a bug if found on a server
>
> 3) "Dependency failed for local file systems"
> sounds bad, but all file systems are there?
>
> 4) "Depencency failed for /mnt/grace"
> /mnt/grace was used to mount a USB disk and of course the system must
> not depend on it
>
> 5) "TImed out waiting to device dev-disk-by-\x2dlabel-Grace.device
> I guess "\x2d" is just a funny systemd way to write "-".
> This probably is the cause for 4) and 5).
> I have no idea why systemd waits for this disk at all. As it noticed
> it is not even connected. I assume this is systemds replacement of USB
> automouter and that it is safe to ignore it.
>
> So only problem I can see is missing /bin/plymouth. Could it got lost
> during apt-get ugrade? Shall I install it? I hope I don't need
> graphical whatever, can it be disabled?
>
> Steffen

systemd requires "plymouth" on server? (was: Systemd: no error but "maintenance mode")

[Steffen Dettmer]

Hi,

I think I found some more information.

In short:
"Failed at step exec spawning /bin/plymouth: no such file or directory"
but I have no clue why it is suddenly missing or suddenly required.
I found postings in the internet that simply installing plymouth seems
not to solve this issue.

What can I do about this?
Any hints appreciated.

In detail:
Google suggested "systemctl status". This shows "State: maintenance",
"Jobs: 0 queued", "Failed: 0 units" and some output looking like
pstree which tells me nothing.
Why "maintenance" when there are no fails?
Is it true that logging, debugging and troubleshooting still is not
implemented correctly in systemd?

"systemctl --failed" shows "0 loaded units listed". According to man
page the command is supposed to list failed units, not loaded units,
so I'm not sure what is true. 0 fails would be good, 0 loaded probably
be bad. It could explain why I don't get syslog messages.

I also found the command "journalctl -p 3 -xb". man page tells
something about a so-called "system journal". Man page references some
desktop stuff (freedesktop.org) and seems to be related to systemd as
well (seems all my recent issues are systemd issues -  hope it dies as
fast as upstart). Man page of systemd-journald.service suggests
systemd invented an own wheel called syslog which does not write to
/var/log? Man page mentions /var/log/journal/ files, but no such
directory exists.

"journalctl -p 3 -xb" shows some information in red color, in reverse
order assuming the later the more important:
1) "r8169 firmware: failed to load rtl_nic/rtl8168g-2.fw"
but eth0 is state UP, so should be fine. At least I should get a
normal local login prompt.

2) "Failed at step exec spawning /bin/plymouth: no such file or directory"
Google suggest this is some graphical whatever, so I think it would be
a bug if found on a server

3) "Dependency failed for local file systems"
sounds bad, but all file systems are there?

4) "Depencency failed for /mnt/grace"
/mnt/grace was used to mount a USB disk and of course the system must
not depend on it

5) "TImed out waiting to device dev-disk-by-\x2dlabel-Grace.device
I guess "\x2d" is just a funny systemd way to write "-".
This probably is the cause for 4) and 5).
I have no idea why systemd waits for this disk at all. As it noticed
it is not even connected. I assume this is systemds replacement of USB
automouter and that it is safe to ignore it.

So only problem I can see is missing /bin/plymouth. Could it got lost
during apt-get ugrade? Shall I install it? I hope I don't need
graphical whatever, can it be disabled?

Steffen

Systemd: no error but "maintenance mode"

[Steffen Dettmer]

Hi,

What happened before:
I had issue with a Debian server SATA bus [1]. I noticed because
apt-get upgrade hung, because initramfs updater calls "sync" which
hang because of [1]. All operations accessing a certain (backup) disk
blocked. Shutdown over network. It was reported server power LED still
up, so probably shutdown hang, too. Server was powered off and disk
pulled.

Then server did not come up. Now I went to its location with monitor
and keyboard. I saw a screen full of boot messages, each line prefixed
with green "[OK]". On bottom, I got asked for root password. I though
Debian does not use root passwords? I'm old fashioned so fortunately I
set one, so I could log in.

I noticed /var/log/syslog had not been updated recently. Obviously
logging is not running / working. All file systems are correctly
mounted read-write.

What happens? Why is however dropping me only a shell when everything
from booting worked fine?
What is this for a bad idea to spawn a LOCAL shell on a server? Or is
Debian nowadays desktop only? I know ubuntu-server, is there also some
debian-server?

Any hint appreciated.

Steffen



[1]
task kworker/u8:0:27432 blocked for more than 120 seconds
Workqueue: writeback bdi_writeback_workfn (flush-8:48)
[] ? io_schedule+0x99/0x120
...

Re: bridges with multiple static IPs or DHPC - how to configure?

[Steffen Dettmer]

Hi,

thanks for your mail!

On Thu, Jun 5, 2014 at 5:03 PM, Curt cu...@free.fr wrote:
 On 2014-06-05, Steffen Dettmer steffen.dett...@gmail.com wrote:
 Do you - or anyone else - know the ip replacement for brctl show?

 ip link show br1 is too brief, no information about the slave
 devices or STP mode.

 ip -stats -stats link show br1

Interesting, didn't knew that.

Yeah, and as Tom wrote in meantime, a replacement command could be:

$ ip link|grep master br0
3: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
master br0 state UP mode DEFAULT qlen 1000
9: eth1.77@eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN mode DEFAULT
10: eth2.78@eth2: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN mode DEFAULT
40: mslot4: BROADCAST,MULTICAST,NOARP mtu 1500 qdisc noop master br0
state DOWN mode DEFAULT qlen 1000

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caobounnavearfxymjbhpbev2sunfrsl54bfbtyxrdqxqw6d...@mail.gmail.com

Re: bridges with multiple static IPs or DHPC - how to configure?

[Steffen Dettmer]

Hi all,

thanks for all your answers!

I think I found the solution:
all bridge parameters must go into the first iface stanza.
Subsequent stanzas configure IPs and/or DHCP.
Using allow-hotplug instead of auto, the bridge is not bought up
at boot and can be started asynchrously by some script.

Yesterday I was sure that I tested this as one of the options,
even at the very beginning; obviously I made a mistake, sorry.

Working Example:
  auto eth1.77
  iface eth1.77 inet manual

  auto eth2.78
  iface eth2.78 inet manual

  allow-hotplug br0
  iface br0 inet static
bridge_ports eth0 eth1.77 eth2.78
bridge_stp on
bridge_waitport 0
bridge_fd 3
bridge_maxwait 0
address 172.22.9.2
netmask 255.255.0.0
  iface br0 inet static
address 10.1.4.1
netmask 255.255.255.248
  iface br0 inet dhcp

(works even without any eth0 stanza)

I reply any to Bzzz, Curt and Karl, but in one single mail
to keep list traffic lower. I hope this helps instead of just
adding confusion :)



On Wed, Jun 4, 2014 at 8:17 PM, Bzzz lazyvi...@gmx.com wrote:
 ifconfig br0:1 192.168.1.201

Yes, even when replacing this deprecated command by

$ ip addr 192.168.1.201/24 dev br0

it works
(this I meant with configuring manually with `ip', `brctl' etc.).



On Wed, Jun 4, 2014 at 8:28 PM, Curt cu...@free.fr wrote:
 You looked here already?
 https://wiki.debian.org/BridgeNetworkConnections

Yes, I did, similar as the man page, it contains a simple
single-IP example only.




On Wed, Jun 4, 2014 at 10:25 PM, k...@jorgensen.org.uk wrote:
 otherwise no bridge can use it any only gives an error message
 like interface eth3.14 does not exist!.

 Hm. have you got the vlan package installed?

No, I don't have. I know that installing this package breaks VLAN
configuration on Debian 7 (in contrast to the documentation).

See also:
https://lists.debian.org/debian-user/2013/10/msg01069.html
https://lists.debian.org/debian-user/2013/10/msg01065.html

   auto eth3.10
   iface eth3.10 inet static
 address 10.72.9.17
 netmask 255.255.255.248
   iface eth3.10 inet static
 address 10.72.9.25
 netmask 255.255.255.248

 Hm.. it doesn't complain about having multiple stanzas with the name
 iface !?  (I'm surprised here, so I may well learn something)

No, it doesn't complain. I think this is the way to set multiple
IP address, am I wrong?

 The same approach as for Ethernet does not work for Bridges:

   iface br1 inet static
 address 10.1.1.1
 netmask 255.255.255.248
 bridge_ports eth3.10
 bridge_maxwait 0
   iface br1 inet static
 address 10.1.1.9
 netmask 255.255.255.248
 bridge_ports eth3.11
 bridge_ports eth3.12
 bridge_maxwait 0

 This adds all interfaces to br1, but only the IP address from the
 last block.

 And you're bridging VLANs 10,11 and 12. Very unusual. If the VLANs
 should be bridged, this is usually done on the switch...

Yes, this example is artificial; better would be eth1.10, eth2.11, eth3.12.

Background:
  I think we can assume this box is the switch.
  Later I'll need to bridge something like

- br0: wlan1 eth2.1 eth3.1 eth4.1
- ...
- brN: wlanN eth2.N eth3.N eth4.N

  or such, each with several IP addresses.

   Using a DHCP address on a bridge interface is .. unusual. But I guess
   there must be use cases where it is valid.

  Some shall support DHCP to ease some maintenance/testing.
  Key factor is that DHCP support shall not get lost when using bridging.

 I'd suggest something like this:

 # ---8-- cut here ---8---
 auto br0
 iface br0 inet dhcp
   bridge-ports eth3
   post-up ip address add 10.1.1.1/24 dev br0
   post-up ip address add 10.1.1.9/24 dev br0
 # ---8-- cut here ---8---

yeah, I so far I hesitated from scripting inside configs, it looks
to dangerous (where does the scripting logs? what about error handling?),

and I think Debian supports multiple IP addresses (without writing an own
script calling ip addr ...).

 or alternatively:
 auto br0:

mmm... I'm afraid using deprecated features may lead into trouble in future?

(With vlan package I already met a few :))

 I assume you only want ONE IP address from DHCP :-)

yes, up to one per VLAN.

 In general, I suspect that you are confusing VLANs with IP aliasing:

Thanks for this nice summary. Yes, it is really easy to confuse that,
but here I hope it didn't happen.

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caobounn0kgcbexnx1a+het7i69kt5pwr3comsnxucrjjzkm...@mail.gmail.com

Re: bridges with multiple static IPs or DHPC - how to configure?

[Steffen Dettmer]

Hi!

thanks so much for you mail. As I wrote in my other mail just a
minute ago, it seems I solved the issue (and it works in one of
the most intuitive ways).

Thanks so much, you already helped so much to tackle down
my VLAN problem last year (where to solution was, not to install
package vlan when using VLAN).

On Wed, Jun 4, 2014 at 11:59 PM, Tom H tomh0...@gmail.com wrote:
 On Wed, Jun 4, 2014 at 2:00 PM, Steffen Dettmer:
 Of course everything works as expected when configuring manually
 with ip, brctl etc.

 (By the way, you don't need brctl; ip link can create bridges.)

Ohh, I see, man ip-link (not man ip as I tried before).
Thanks for pointing that out!

I case someone else also has difficulties to find that, like me,
here an example:

  $ ip link add name br1 type bridge
  $ ip link set eth0 master br0
  $ ip link set eth1 master br0

  $ ip link set eth1 nomaster
  $ ip link set eth0 nomaster
  $ ip link del br1

Do you - or anyone else - know the ip replacement for brctl show?

ip link show br1 is too brief, no information about the slave
devices or STP mode.

How to enable STP (and set timeouts etc) using ip?

 otherwise no bridge can use it any only gives an error message
 like interface eth3.14 does not exist!.

Update: This message appears only if using ifup br0,
but NOT when booting. Seems networking start is smart
enough to bring slave devices up before the bridge.

The conclusion is that ifdown dev  ifup dev is not suited
for testing.

 I suspect that the bridge-utils-interfaces man page refers to physical
 interfaces. You might want to file an RFE bug for it to work for
 vlan-tagged interfaces so that:

 iface br0.100
 bridge_ports eth0.100

Ohh, thanks to bringing this into attention.
This happily creates a bridge called br0.100 (without VLAN) :-)
so the implicite magic like eth0.10 creating a VLAN tag 10 does
not apply here, good to know.

For the case that the bridge shall bridge VLAN transparently on
all physical ports, but itself should be in a VLAN 100.
This would be like a fully transparent VLAN switch with a
management interface in a VLAN.

With ip it works straight-forward:

have in /etc/network/interfaces:
# bridge all VLANs
iface br0
  bridge_ports eth0 eth1...

and add VLAN interface to the bridge:

$ ip link add link br7 name br7.10 type vlan id 100

I guess (not tested) when one tagged interface such as eth2.101
is in the bridge, it would get the br7.10 traffic with tag 101.

I think at least it should work when using

iface br0
  bridge_ports eth0 eth1...
  up ip link add link br7 name br7.10 type vlan id 100

 This might work:

Yes, almost. I tried that with minor modifications it does work:

 iface br0 inet static
 address 10.1.1.1
 netmask 255.255.255.248
# NO: gateway 10.1.1.254
# must be in network of course (SCNR :)):
gateway 10.1.1.7
 bridge_ports eth0
 bridge_ports eth1

 iface br0 inet static
 address 10.1.1.2
 netmask 255.255.255.248
# NO: gateway - can have only one default route without printing an error
#NO: bridge_ports eth0
#NO: bridge_ports eth1

When bridge_ports appear again, it does not work. It could be
that in such cases the bridge gets created again - thus losing
all previously configured properties.

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caobounpzshglojs8-jdbxrjjm8428dq3nfct7gm3fqhcpcb...@mail.gmail.com

bridges with multiple static IPs or DHPC - how to configure?

[Steffen Dettmer]

Hi,

how to configure a bridge with multiple static IPs and/or DHPC
via /etc/network/interfaces?

I tried many combinations, but I didn't find any working one.

Of course everything works as expected when configuring manually
with ip, brctl etc.

Any working example would be great!

The rest of the mail discusses what I tried so far.

Yes, I read man bridge-utils-interfaces(5), but it has simple
examples only (single static IP or no IP). The man page tells,
interfaces used as bridge_ports

   are the  interfaces  that  are  part  of  the  bridge,  and
   they shouldn't  have  any  stanzas defining them on the
   interfaces file  -- man bridge-utils-interfaces(5)

but this is wrong. There must be a stanza like

  auto eth3.14
iface eth3.14 inet manual

otherwise no bridge can use it any only gives an error message
like interface eth3.14 does not exist!.

For an ordinary ethernet interface, the following works:

  auto eth3.10
  iface eth3.10 inet static
address 10.72.9.17
netmask 255.255.255.248
  iface eth3.10 inet static
address 10.72.9.25
netmask 255.255.255.248

For bridges, it is not clear how to use multiple stanzas for
multiple IPs; it seems, the options to create the bridge and to
add IPs to it are somehow mixed.
There are options like bridge_ports. They have to be in each
iface br0 stanza?

  (Experiments show that bridge_ports are accumulated (probably
  simply because each stanza brctl addif each, in total producing
  the desired result), but other options such as bridge_maxwait
  are not.)

The same approach as for Ethernet does not work for Bridges:

  iface br1 inet static
address 10.1.1.1
netmask 255.255.255.248
bridge_ports eth3.10
bridge_maxwait 0
  iface br1 inet static
address 10.1.1.9
netmask 255.255.255.248
bridge_ports eth3.11
bridge_ports eth3.12
bridge_maxwait 0

This adds all interfaces to br1, but only the IP address from the
last block.

It is similar when it comes to DHCP.

For an ordinary ethernet interface, the following works:

  allow-hotplug eth1
  iface eth1 inet static
address 10.72.9.33
netmask 255.255.255.248
  iface eth1 inet dhcp

(I cannot use auto eth1, because system boots must never block)

The same approach as for Ethernet does not work for Bridges:

  iface br1 inet static
address 10.1.1.9
netmask 255.255.255.248
bridge_ports eth3.11
bridge_ports eth3.12
  iface br1 inet dhcp
bridge_ports eth3.13

Again, the static IP address is missing.

Also experiments show, that bridge_maxwait does not work with dhcp:

iface br1 inet dhcp
  bridge_ports eth3.13
  bridge_maxwait 0

this blocks.

Probably I miss a simple detail, please help me. Any working
examples appreciated!

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caobounmw2p_zkv+4zquosupdkkjzoajosmkvttwrbqj-gy9...@mail.gmail.com

Re: persistent-net.rules for fixed ethX names and VLANs

[Steffen Dettmer]

Hi,

this is a reply to an very old posting just to tell the solution
to the mailing list archives.

Problem was that Micrel Driver does net set DRIVER name. Here a patch.

On Tue, Nov 26, 2013, Steffen Dettmer steffen.dett...@gmail.com wrote:
 On Tue, Nov 19, 2013, Pascal Hambourg pas...@plouf.fr.eu.org wrote:
 On Thu, Nov 14, 2013, Steffen Dettmer steffen.dett...@gmail.com wrote:
 I have persistent-net.rules in form:

   SUBSYSTEM==net, KERNEL==eth* ACTION==add,
 ATTR{address}==40:d8:55:09:43:0f, NAME=eth3

 How to use fixed ethX device names and VLAN devices at the same time?

 The behaviour you describe does not happen on a standard Debian system.
 I guess it is because the standard rules have the DRIVERS=?*

 Yes, the rules generated by the Debian net rule generator (which
 are the standard rules, right?) include DRIVERS=?* (and are
 only generated for devices that have a DRIVER=).

 condition. A real network interface has the (non-null) driver name in
 its parent device and thus matches the rule, whereas a virtual VLAN
 interface does not.

 Thank you for your explanation. I think I understood well, but
 there seems to be a missing detail in my case: although for
 almost any device this might be true, but as the udevadm info from
 my original posting shows, there are drivers that do not do so.
   (For such devices, the Debian udev scripts do not even generate
   persistent net rules, because DRIVER must match non-empty in
   the generator script).

 The driver used here is ksz884x.

The following patch solves this problem:

---8===
diff --git a/drivers/net/ethernet/micrel/ksz884x.c
b/drivers/net/ethernet/micrel/ksz884x.c
index 14ac0e2..023f2f9 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -7072,6 +7072,7 @@ static int pcidev_init(struct pci_dev *pdev,
const struct pci_device_id *id)
 dev = alloc_etherdev(sizeof(struct dev_priv));
 if (!dev)
   goto pcidev_init_reg_err;
+ SET_NETDEV_DEV(dev, pdev-dev);
 info-netdev[i] = dev;

 priv = netdev_priv(dev);
===8---

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnMb9pWCsuzUctybHWK1ETpjE5bH10zCSCbA=0ruxjs...@mail.gmail.com

udevd and persistent network rules for USB NICs

[Steffen Dettmer]

Hi,

I have a device with several internal mini PCIe card slots usable
for PCI Express mini modem cards (UMTS, LTE...). These cards
normally are USB cards and get some ethX device name assigned by
Linux, which I don't like. Instead, they should get another name,
for example usb-ethX.

Is it possible to write a udev rule that renames *multiple* eth
devices to usb-eth devices?

The obvious attempt to use something like:

  SUBSYSTEM==net, ACTION==add, DRIVERS==?*, KERNEL==eth*,
  more matching condtions
  NAME=usb-eth%n

does not work. The kernel assignes a free eth name, let's say
eth4, udevd renames it via a temporary sequence name, let's say
rename23, to usb-eth4. eth4 is free again.
The second device gets eth4 assigned by kernel, udevd renames it
via a temporary sequence name, let's say rename24 and then
(probably) fails to rename to usb-eth4, because this name already
exists. The result is that the device is called rename24.

This is not the biggest problem. When booting a Debian 7.5
configured with such rules, the initrd (?) hangs at boot after
printing populating /dev - presumably because it waits for
renameXX be renamed correctly, which never happens.

Unfortunately there is no udev directive like %n but not using
the kernel number but using the next free or any free number.

What so far works best is to manually assign names to the mPCIe
slots, in form of having some 99-persistent-overwrite-all.rules:

  SUBSYSTEM==net, ACTION==add,
  DEVPATH==/devices/pci:00/*/usb1/1-2*/net/*,
  NAME=usb-eth1

because each mPCIe has a distinct DEVPATH.

As a side effect, interestingly an entry is made in
70-persistent-net.rules, which is fortunately overwritten by my
99-persistent-overwrite-all.rules file and thus has no effect.

Now, when it comes to USB pluggable NICs, I could of course use a
similar rule for the DEVPATH of the USB plug, but as soon as an
USB hub with two NICs is connected, the rename24 situation
occures and plugging before power on, it hangs at populating /dev.

NB: Interestingly, it works when not using any USB rule for the
USB plugs DEVPATHs. The kernel assignes e.g. eth4, and
althrough there is no eth4, udev renames it to eth5. I guess
that could be because the rule generator generates a rule for
it, uses eth5 which is according to the rules file is the
next free (as it is the default behavior when not having any
own rules).

How to use udev to rename devices without risking hanging boot?

Any help, hints or pointers appreciated!

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnOGxYp2zoZfAPcUZdno_hYRJOONS=wj0qs10dc8kn9...@mail.gmail.com

Debian 7.5 fails with kernel.org backports

[Steffen Dettmer]

Hi,

after upgrading to Debian 7.5 (linux-headers-3.2.0-4-common),
backports 3.10.2 [1] does not compile anymore [2]. Without it, I have
issues with Antheros WLAN cards.

Does Debian 7.5 include another backported versions? Can it be removed
and replaced by official backports 3.10.2 from [1]?

It could be that it is related to some e1000e backport (the sources
also don't compile anymore, I did not yet tested whether the driver
included in 7.5 works without backported driver.

How do I get wireless backports working again with 7.5?

Is it normal to have such breaking changes in a minor release? I was
really surpised, what can I do?

Any help appreciated!

Have a nice weekend,

Steffen

[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10/backports-3.10-2.tar.bz2

[2] In file included from
/tmp/nd-ath9k/backports-3.10-2/compat/compat-3.7.c:13:0:
/tmp/nd-ath9k/backports-3.10-2/backport-include/linux/pci.h:112:19:
error: redefinition of ‘pcie_capability_set_word’
/usr/src/linux-headers-3.2.0-4-common/include/linux/pci.h:806:19:
note: previous definition of ‘pcie_capability_set_word’ was here


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnMR2Uzp9FXE-HJ_QWhs=NvAe=hjqqc0n9gbahpy-8q...@mail.gmail.com

Re: dpkg -i first.dep second.dep: installs but does not configure one?

[Steffen Dettmer]

Hi,

thanks for your fast replies and nice answers!

It turned out that it is a bit more complicated, so it took me
some time to ask around here, sorry for the delay, I hope you
still remember the context:

On Thu, Apr 3, 2014 at 7:35 PM, Sven Joachim svenj...@gmx.de wrote:
  Le 03.04.2014 11:46, Steffen Dettmer a écrit :
   $ dpkg -i first.dep second.dep
  
   pre-dependency problem:
nd-second pre-depends on nd-first
 nd-first is unpacked, but has never been configured.

 dpkg is smart enough to figure out the order in which
 packages need to be configured.

Isn't it a bug then, that if dpkg is even smart enough to figure
out the configuration order, but is not smart enough to figure
out the order in which packages need to be unpacked?

 Rather the problem is that both packages are _unpacked_ before
 the first one is configured, and this is where the
 pre-dependency is not fulfilled.

  Other that that, why are you using pre-depends and not depends? That
  would fix the problem.

 Indeed.

I still unsure if I found the right answer, but I think the
reason for Pre-Depends is, that one package debian/preinst
script depends on another package being installed. The preinst
script creates a partion and a file system which might be
needed to install/unpack further packages on; for the creation, it
needs configured contents from the package it pre-depends on.

The idea was to have a package that provides this file system and
other packages that need it can depend on it. These further
packages should be able to unpack directly on this filesystem.

In in short, before unpacking further.deb, filesystem.deb has not
only to be unpackaged but full installed (configured).

What would be the right way to do this?

Is this a bug in dpkg?

Regards,
Steffen


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnO_RfFiOeZp-nNkT00UNoL1+=s-7wkofpfnza+nrwa...@mail.gmail.com

dpkg -i first.dep second.dep: installs but does not configure one?

[Steffen Dettmer]

Hi,

I have two packages, first and second. Package second depend on
package first. I have to use dpkg (I don't use apt, because there is
no package server / no online link etc).

When I run

$ dpkg -i first.dep second.dep

I get the error:

dpkg: regarding .../nd-second_5.0.02_i386.deb containing nd-second,
pre-dependency problem:
 nd-second pre-depends on nd-first
  nd-first is unpacked, but has never been configured.

After that I am suprised by:

root@NOMAD-BLN-R3200Xstd:/# dpkg -l nd-portal nd-persist
ii  nd-first 5.0.02 i386  first package
in  nd-secondnonei386  (no
description available)

When I now repeat dpkg -i first.dep second.dep; it works.

It also works when I run:

$ dpkg -i first.dep  dpkg -i second.dep

According to man dpkg, configuring is step 6 of installation and it
should make no difference whether installing two packages at once or
not.

Do I missunderstand the man page?
Or Is this a bug? In my package or in dpkg or in the man page?

However, I already were surprised that dpkg seems not to install in
the needed order but in order as specified at command line and that it
installs packages even if predeps fail (my wish had been that it
atomically works or fails instead).

Some articles suggest things like dpkg -i *deb, but if dpkg does not
even installs in the needed order, dpkg -i *deb should be a bad
advice.

What is correct?

Any comments appreciated!

Regards,
Steffen


Selecting previously unselected package nd-first.
(Reading database ... 23638 files and directories currently installed.)
Unpacking nd-first (from .../nd-persist_5.0.02_i386.deb) ...
D20: process_archive conffile '/etc/cron.d/nd-first' no package, no hash
D01: process_archive oldversionstatus=not installed
D02: fork/exec /var/lib/dpkg/tmp.ci/preinst ( install )
--- DEBUG: nd-first/debian/preinst script called
D20: tarobject fnnf_new_conff deref='etc/cron.d/nd-first'
D01: process_archive updating info directory
D02: process_archive tmp.ci script/file '..' contains dot
D02: process_archive tmp.ci script/file
'/var/lib/dpkg/tmp.ci/control' is control
D02: process_archive tmp.ci script/file
'/var/lib/dpkg/tmp.ci/postinst' installed as
'/var/lib/dpkg/info/nd-first.postinst'
D02: process_archive tmp.ci script/file '.' contains dot
D02: process_archive tmp.ci script/file
'/var/lib/dpkg/tmp.ci/md5sums' installed as
'/var/lib/dpkg/info/nd-first.md5sums'
D02: process_archive tmp.ci script/file
'/var/lib/dpkg/tmp.ci/preinst' installed as
'/var/lib/dpkg/info/nd-first.preinst'
D02: process_archive tmp.ci script/file
'/var/lib/dpkg/tmp.ci/conffiles' installed as
'/var/lib/dpkg/info/nd-first.conffiles'
D01: generating infodb hashfile
dpkg: regarding .../nd-second_5.0.02_i386.deb containing nd-second,
pre-dependency problem:
 nd-second pre-depends on nd-first
  nd-first is unpacked, but has never been configured.

dpkg: error processing /var/lib/nomad/nd-second_5.0.02_i386.deb (--install):
 pre-dependency problem - not installing nd-second
D40: checking dependencies of nd-first:i386 (- none)
D40: ok 2 msgs 
D40: checking Breaks
Setting up nd-first (5.0.02) ...
D01: deferred_configure updating conffiles
D20: deferred_configure '/etc/cron.d/nd-first' (=
'/etc/cron.d/nd-persist') useredited=-1 distedited=-1 what=24
D02: fork/exec /var/lib/dpkg/info/nd-first.postinst ( configure  )
--- done.
Errors were encountered while processing:
 /var/lib/nomad/nd-second_5.0.02_i386.deb


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caobounotoj7ytjpsrynrgedwsv00gtl-7ds-ahaqvh3gow4...@mail.gmail.com

How to migrate multiple *.dep package files into one?

[Steffen Dettmer]

Hi,

two (or more) *.deb packages now become one. All files that were in
any of the packages now are in one and the same, which supersedes them
all.

I dont think it is the best idea to call some dpkg -r oldpackage
from the postinst script of the only remaining package.

How to do this right?

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnMF6nevUr5n=1l1t2zdw0bzq-k-vqtmnx7vt15h6zg...@mail.gmail.com

Re: How to migrate multiple *.dep package files into one?

[Steffen Dettmer]

On Thu, Mar 27, 2014 at 6:03 PM, steffen.dett...@gmail.com wrote:
 I dont think it is the best idea to call some dpkg -r oldpackage
 from the postinst script of the only remaining package.

ps: I tried
Replaces: oldpackage
Conflicts: oldpackage
in control file, but the old package remains installed.

Should I simply leave it installed, because it does not harm anyone?
In dpkg -l I see status ic (Installed and Configuration
files?):

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
ic  oldpackage 1.0.01-0 i386 Do not use, replaced by newpackage

but dpkg -L oldpackage tells:

Package `oldpackage' does not contain any files (!)

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOBoUnM0Xstmh=p9=EY1zC=m1uucsk8el9xiqt8nbbfxrmf...@mail.gmail.com

How to use logrotate postrotate *bash* script

[Steffen Dettmer]

Hi,

logrotate seems to execute postrotate scripts using /bin/sh and I
found no way where to specify which script interpreter to use.
Starting with a she-bang line seem to have no effect. Even if I
manually run logrotate as root who has /bin/bash as login shell,
/bin/sh is used.

How to make logrotate to use the correct interpreter for postrotate scripts?

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnMn1NiDJ=09z+q26u19ogdiwdnxk3dalwiq-ruegw2...@mail.gmail.com

Re: persistent-net.rules for fixed ethX names and VLANs

[Steffen Dettmer]

Hi,

sorry, unfortunately I missed your mail, thank you for your
response and sorry for the delay.

On Tue, Nov 19, 2013 at 11:24 PM, Pascal Hambourg
pas...@plouf.fr.eu.org wrote:
 Hello,

 Steffen Dettmer a écrit :
 On Thu, Nov 14, 2013 at 4:36 PM, Steffen Dettmer
 steffen.dett...@gmail.com wrote:
 I have persistent-net.rules in form:

   SUBSYSTEM==net, KERNEL==eth* ACTION==add,
 ATTR{address}==40:d8:55:09:43:0f, NAME=eth3

 How to use fixed ethX device names and VLAN devices at the same time?

 The behaviour you describe does not happen on a standard Debian system.
 I guess it is because the standard rules have the DRIVERS=?*

Yes, the rules generated by the Debian net rule generator (which
are the standard rules, right?) include DRIVERS=?* (and are
only generated for devices that have a DRIVER=).

 condition. A real network interface has the (non-null) driver name in
 its parent device and thus matches the rule, whereas a virtual VLAN
 interface does not.

Thank you for your explanation. I think I understood well, but
there seems to be a missing detail in my case: although for
almost any device this might be true, but as the udevadm info from
my original posting shows, there are drivers that do not do so.
  (For such devices, the Debian udev scripts do not even generate
  persistent net rules, because DRIVER must match non-empty in
  the generator script).

The driver used here is ksz884x.

If it is required that a driver for a physical network card sets
DRIVER and no other driver is allowed to do so (which IMHO would
be a precondition to safely bind udev rules on that), I think
this would indicate an issue with the driver ksz884x.

What do you think, is this right?

  (By the way, from a technical viewpoint I dislike the idea to
  distinguish ethernet/parent/physical devices from virtual
  devices like VLAN devices by determining the presence of a
  DRIVER name.  Also, different virtual devices, like VLAN and
  [guessed] bridge interfaces would be indistinguishable. This
  seems not to be a Debian thing but possibly a general udev
  weakness?)

   # Avoid renaming of VLAN interfaces:
   SUBSYSTEM==net, KERNEL==eth*.* ACTION==add, NAME=$kernel

 Of course this only works as long as following the naming
 convention to call the VLAN interface ethX.V with V being
 the number of the VLAN tag, for example eth3.77.

 It does not matter : the other naming convention vlanV won't match the
 rule and thus won't be renamed, which is the desired behaviour IIUC.

(assuming with other naming convention you mean the standard
rules as generated by Debian net rule generator:)
You are absolutely right, but the standard naming convention
here already fails for the network card, because its driver does
not set the DRIVER name field to a non-empty value.

Regards,
Steffen


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounojt1mqhhop5d613khuyf_o3phmquwcihrjubc5jut...@mail.gmail.com

persistent-net.rules for fixed ethX names and VLANs

[Steffen Dettmer]

Hi,

I have persistent-net.rules in form:

SUBSYSTEM==net, KERNEL==eth* ACTION==add,
ATTR{address}==40:d8:55:09:43:0f, NAME=eth3

which makes the Ethernet device with the given MAC address known
as eth3, so far so good.

When trying to add a VLAN using e.g.:

ip link add link eth3 name eth3.77 type vlan id 77

this rule matches (because same mac address) and I end up with an
interface called e.g. rename9 (number of course differs). I tried

  $ udevadm info -a -p /sys/class/net/dev

to see a difference, but after ip link set up dev rename9 the
only difference I see are ATTR{ifindex}, ATTR{operstate} and
ATTR{tx_queue_len} and none of them is suited to be used as
matching condition in my udev rule.

How to use fixed ethX device names and VLAN devices at the same time?

Any hint appreciated!

Regards,
Steffen

syslog:
udevd[673]: error changing net interface name rename9 to eth3: File exists

  looking at device '/devices/virtual/net/eth3':
KERNEL==eth3
SUBSYSTEM==net
DRIVER==
ATTR{addr_assign_type}==0
ATTR{addr_len}==6
ATTR{dev_id}==0x0
ATTR{ifalias}==
ATTR{iflink}==4
ATTR{ifindex}==4
ATTR{type}==1
ATTR{link_mode}==0
ATTR{address}==40:d8:55:09:43:0f
ATTR{broadcast}==ff:ff:ff:ff:ff:ff
ATTR{carrier}==0
ATTR{speed}==10
ATTR{duplex}==half
ATTR{dormant}==0
ATTR{operstate}==down
ATTR{mtu}==1500
ATTR{flags}==0x1003
ATTR{tx_queue_len}==1000
ATTR{netdev_group}==0


  looking at device '/devices/virtual/net/rename9':
KERNEL==rename9
SUBSYSTEM==net
DRIVER==
ATTR{addr_assign_type}==0
ATTR{addr_len}==6
ATTR{dev_id}==0x0
ATTR{ifalias}==
ATTR{iflink}==4
ATTR{ifindex}==9
ATTR{type}==1
ATTR{link_mode}==0
ATTR{address}==40:d8:55:09:43:0f
ATTR{broadcast}==ff:ff:ff:ff:ff:ff
ATTR{carrier}==0
ATTR{speed}==10
ATTR{duplex}==half
ATTR{dormant}==0
ATTR{operstate}==lowerlayerdown
ATTR{mtu}==1500
ATTR{flags}==0x1003
ATTR{tx_queue_len}==0
ATTR{netdev_group}==0


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounnt2pmg7bd-xvqrzqp1qjrruzk71pmqz0uxbcyeffp...@mail.gmail.com

Re: persistent-net.rules for fixed ethX names and VLANs

[Steffen Dettmer]

On Thu, Nov 14, 2013 at 4:36 PM, Steffen Dettmer
steffen.dett...@gmail.com wrote:
 I have persistent-net.rules in form:

   SUBSYSTEM==net, KERNEL==eth* ACTION==add,
 ATTR{address}==40:d8:55:09:43:0f, NAME=eth3

 How to use fixed ethX device names and VLAN devices at the same time?

I found a workaround that seems to solve my issue. At the end of
persistent net rules or a higher file I added:

  # Avoid renaming of VLAN interfaces:
  SUBSYSTEM==net, KERNEL==eth*.* ACTION==add, NAME=$kernel

Of course this only works as long as following the naming
convention to call the VLAN interface ethX.V with V being
the number of the VLAN tag, for example eth3.77.

NB: interestingly, according to the documentation [1], %r
should be the same as $kernel, but here %r does not work.
When using NAME=prefix%r the interface is renamed
accordingly. Seems to be a bug?

Regards,
Steffen


[1] http://www.freedesktop.org/software/systemd/man/udev.html


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounot-ieo8owpxjxyjtotbtaofykg0+svjucq28vk6kn...@mail.gmail.com

Fwd: Questions about SIGHUP behavior

[Steffen Dettmer]

Hi,

thanks for your detailed answer.

On Tue, Nov 12, 2013 at 6:02 PM, David F deb...@meta-dynamic.com wrote:
 On 11/12/2013 07:35 AM, Steffen Dettmer wrote:

 Debian 7.2 with /bin/bash as login shell (via /etc/passwd), shopt
 huponexit off (as by default), bash run via SSH from other host.

 When closing shell with CTRL-D, sleep  continues to run. I had
 expected I had to use nohup, setsid, disown or a combination of them
 in order to keep background jobs running after ending a shell session.

 Short answer: I doubt that this ever worked as you think it did;

(I think at least when using a physical modem it should have been
worked, wasn't this what the signal was defined for?)

 Fast-forward to today: bash by default uses job control except when
 executing a script, and in the case of SSH, a pseudo-tty is used to simulate
 the real device and its driver [details at pty(7)].

Ahh yes, so this is the source of the SUGHUP delivered to the
shell, thanks for explaining.

 For the final piece of the puzzle, check the relevant section of bash(1):
 The shell exits by default upon receipt of a SIGHUP.  Before
 exiting, an interactive shell resends the SIGHUP to all jobs [...] If the
 huponexit shell option has been set with shopt, bash sends a SIGHUP to all
 jobs when an interactive login shell exits.

I did my tests all without changing huponexit, so I'd expect the
same behavior (I could understand whether bash always or never
resending SIGHUP, depending whether huponexit is applied to the
exit caused by a signal)

 A little investigation with ps will show see why your sleep process didn't
 receive a SIGHUP: when job control is enabled, bash moves background jobs
 out of the foreground process group; they therefore won't receive a SIGHUP

But the shell process does receive a SIGHUP:

  # ps -A -O sid,pgid|grep -e '\(sleep\|bash\)'
  11702 11702 11702 S pts/000:00:00 -bash
  11707 11702 11707 S pts/000:00:00 sleep 1h
  root@NOMAD-BLN-R3200Xstd:~# strace -p 11702
  Process 11702 attached - interrupt to quit
  read(0, 0xbfa6975f, 1)  = -1 EIO (Input/output error)
  --- SIGHUP (Hangup) @ 0 (0) ---
  --- SIGCONT (Continued) @ 0 (0) ---
  [...]
  kill(-11707, SIGHUP)
  [...]
  kill(11702, SIGHUP) = 0
  sigreturn() = ? (mask now [])
  --- SIGHUP (Hangup) @ 0 (0) ---
  Process 11702 detached

In this test, it behaves like expected: bash gets SIGHUP and
resends to the background process group 11707 using
kill(-11707, SIGHUP).

I repeated this test (with and without strace) and noticed, that
in all cases when using strace, the background sleep process
terminate along with the SSH session and in cases when not using
strace in most (!) cases the sleep process continued to exist,
but I also found a few cases where the sleep process did
terminate.

 Note that had bash
 exited due to receiving a SIGHUP *itself* (which would happen e.g. if sshd
 died and released the pty), it would have delivered the SIGHUP to all of its
 jobs, foreground and background, which is one reason why you want to use
 commands like nohup, disown, etc. if you want to really be sure that your
 background commands continue to run even after you logout.

this was my assumption, but my observation is different.
I see several cases where I ended SSH using ~. causing SIGHUP to
be delivered to bash, but and a background process continued to
tun.

 ~ % ssh localhost
[...]
 ~ % exit
 logout
 Connection to localhost closed.

I think this does not lead to a SIGHUP delivered to bash, I think
you have to end SSH session using ~. or maybe closing the xterm.

My test a bit more in detail.

Client (with prompt $) opens SSH session to test system (with
prompt #). On this pts/0, observation is made using ps.

On a second xterm on the Client a second SSH session is opened
(pts/1) and the command sleep 1h is issued.

On the first xterm, the ps command is issued.
Result: sleep 1h process exists.
On the second xterm, the SSH session is disconnected using SSH
escape ~..
On the first xterm, the second ps command is issued.
Result: no sleep 1h process anymore.

Repeat.

On the first xterm, the ps command is issued.
Result: sleep 1h process exists.
On the second xterm, the SSH session is disconnected using SSH
escape ~..
On the first xterm, the second ps command is issued.
Result: sleep 1h process still exists.

Here the transscript; the first xterm 18 space intended, I hope
that it reads better.


second xterm   first xterm

 $ ssh 172.22.9.1
 #

$ ssh 172.22.9.1
# sleep 1h
[1] 12147

 # ps -A -O sid,pgid|grep -e '\(sleep\|-bash\)'
 12132 12132 12132 S pts/000:00:00 -bash
 12140 12140 12140 S pts/100:00:00 -bash
 12147 12140 12147 S pts/100:00:00 sleep 1h
 12149 12132 12148 S pts/000:00:00 grep -e \(sleep\|-bash\)

# Connection to 172.22.1.9 closed

Questions about SIGHUP behavior

[Steffen Dettmer]

Hi,

Debian 7.2 with /bin/bash as login shell (via /etc/passwd), shopt
huponexit off (as by default), bash run via SSH from other host.

When closing shell with CTRL-D, sleep  continues to run. I had
expected I had to use nohup, setsid, disown or a combination of them
in order to keep background jobs running after ending a shell session.

Was shopt huponexit used to be on in the past (or non-existing and
behaving like if it had been on) or do I incorrectly remember? I think
I remember correctly, otherweise the nohup tool would not be needed
and probably would not exist...

When closing shell with CTRL-D, cat  does not continue to run,
because it receives SIGTERM. I had expected it behaves like sleep. I
cannot test nohup cat, because nohup also redirects inputs and thus
cat instantly terminates, but anyway nohup should not change behavior
of SIGTERM. Why are cat and sleep different? Note: in strace sleep,
I don't see that file handles get closed, so it is not obviously
related to that, as I initially assumed.

When aborting SSH session with ~., sleep  continues to run. I had
expected that the sshd process sends a SIGHUP to the process session,
but ps told that bash does not run in the process session as sshd, but
in an own session. strace shows that the bash process receives a
SIGHUP, but it does not send SIGHUP (but there is no shopt huponhup
off). As I understand the man page of bash, I had expected that bash
sends SIGHUP to all created process groups (i.e. my sleep ), unless
disown was used.

I tried to see who is sending the SIGHUP and ran strace on the parent
process sshd, but I saw now kill() invocation. To go for sure I even
ran strace on the parent parent process (the master sshd process),
but also saw no kill (but the SIGCHLD handling as expected). Where
does the SIGHUP received by -bash come from?

Best regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnNeGn9i-G0bzugORa_uL3QCW=vkwctdyew3wom5yda...@mail.gmail.com

How to configure udev to rename USB network cards correctly

[Steffen Dettmer]

Hi,

we have USB network cards and udev rules for them, for example:

SUBSYSTEM==net, ACTION==add, ATTRS{manufacturer}==Novatel
Wireless*, ATTRS{serial}==?*, NAME=ethnovatel%n

when booting, we see e.g., ethnovatel3 and ethnovatel4, as expected.

When unplugging/replugging (or power cycling) the USB devices, it
often happens that one devices is called rename22 (with an
arbitrary, increasing number). My guess is that this happens because
%n is unfortunately not a unique counter but the number of the device
befor renaming it, and that it happens that first device gets kernel
name eth4, is renamed to ethnovatel4, second device gets eth4
from kernel (no conflict) and cannot be renamed to ethnovatel4,
because already existing.

I looked to udev scripts, which seem to be quite complicated and
difficult to write and debug, so I assume it is not intended to change
them.

How to configure udev to rename USB network cards correctly?

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounpmuba55zcp5xdjdgkayqbc6rwxd4qk4gqpa9ck370...@mail.gmail.com

Re: Passing nowait command line option to dhclient

[Steffen Dettmer]

Hi,

thanks for your quick and helpful reply!

On Thu, Oct 17, 2013 at 11:09 PM, Bob Proulx b...@proulx.com wrote:
 Steffen Dettmer wrote:
 Your indention is terrible!

Sorry, I'll improve.

 I think I have to pass the option -nw to dhclient, but how do I do
 that correctly?

 If you want dhclient not to wait then change the auto to
 allow-hotplug. Using auto means bring the interface up at system
 boot time. It runs the /etc/init.d/* scripts.  This is a synchronous
 operation.  allow-hotplug means bring the interface up when the
 interface is detected.  That is the new dynamic event driven way and
 runs asynchronously.

This is interesting. I like to have the interface bought up at
system boot time, so auto seemed correct. allow-hotplug is
supposed to bring the interface up when the interface is
detected (also told by the Debian Reference), but apparently that
is not true, my Ethernet interfaces are detected very early, I
think already during initramfs when there is no
/etc/network/interfaces, but interestingly allow-hotplug is
working (maybe by emulating some cold-plug),
EXCEPT a VLAN tag is used.

If a VLAN tag is used, the interface ethX.ttt is not
automatically started (ifup ethX.ttt is needed).

 I noticed that DHCP leases are kept as long as the lease is valid when
 moving from one LAN to another, not sure if this behavior is correct.

 It is required.  It is possible for clients to actively release the
 lease.  But if a client crashes then the dhcp server never gets an
 indication and therefore must keep the lease active for the full time
 to live.

Yes, of course, but I meant a different case.
When unplugging a device from one switch (one LAN) and plugging
it to another switch (different LAN), or moving it from one
switch port to another when both forward by applying different
VLAN tags, the client uses a lease that is not valid for its
new LAN, so a new DHCP request could be suited. Laptops usually
work this way (restarting DHCP when link gets up). But I was told
this is no important case.

 How to configure DHCP correctly without causing boot delays?

 Use allow-hotplug.

Thanks for this tip, this helps for non-VLAN interface, a big
step forward, thank you!

About the VLAN issue, does anyone knows how to configure DHCP on
VLAN tagged interfaces correctly without causing boot delays?

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounodnbk2mqlw+lmpz-wtmq7glljh2ko6hkwo-qmvyeu...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

On Fri, Oct 18, 2013 at 9:40 AM, Tom H tomh0...@gmail.com wrote:
 On Thu, Oct 17, 2013 at 12:57 PM, Steffen Dettmer
 steffen.dett...@gmail.com wrote:
 but I get an error message that ifup tries to configure the VLAN
 interface twice, but the addresses are set.
 I assume that you mean auto eth3.77 not auto eth3.107.

Yes, of course, sorry for the typo. I CP wrongly (I did too many
tests :)).

 works for me in the form of

 allow-auto eth0.9

 iface eth0.9 inet static
 address 192.168.1.119
 netmask 255.255.255.0
 gateway 192.168.1.1

 iface eth0.9 inet static
 address 192.168.1.199
 netmask 255.255.255.0

I used literally this (1:1 copied), but I get the same message I
had during my tests, about already existing interfaces.
Unfortunately they are not stored in any /var/log/* file, so I
hopefully retype correctly:

[] Configuring network interfaces...Set name-type for VLAN subsystem. Should
 be visible in /proc/net/vlan/config
ERROR: trying to add VLAN #9 to IF -:eth0-  error: File exists
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config:
ERROR: trying to add VLAN #9 to IF -:eth0-  error: File exists
done.

Beside this looks as vconfig messages are unexpected (they
distrub the screen layout), the big ERROR messages look really bad.

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounpk77nqalv139qn9mzuwg_ntzfzg4umgnhdqaampmn...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

Hi!

On Thu, Oct 17, 2013 at 11:39 PM, Bob Proulx b...@proulx.com wrote:
 Steffen Dettmer wrote:
 However all of the docs I see just now suggest using a bridge.

There are docs recommending to take the burden of kernel software
briding to add an alias IP?!

 Configuring multiple IP addresses on interfaces like that is new in
 recent versions of ifupdown.

Wow, this is surprising! I considered it an old basic classic standard feature.

 Whether it works or not depends upon the version of the program.

Amazing.

 Previously it was necessary to use different tagged interfaces
 or to use up/down commands to add additional ip addresses.

Ahh, you mean I could try the old eth0:0 approach? But I guess it
won't be compatible with VLANs.

 First I thought ifup would be a shell script, but apparently
 ifupdown uses source code generation to generate Perl code from some
 noweb code and uses the generated Perl code to generate C code which
 then is compiled using a generated Makefile -- all this is not easy to
 read / understand, so I decided to write a mail here hoping someone
 can enlighten me :)

 It depends upon the version of ifupdown.  Previously it used a
 literate programming technique with TeX embedded documentation and C
 code using notangle and .nw files.

yeah, I see you also took a look :)

   apt-cache show noweb

Wikipedia tells:
noweb is a literate programming tool, created in 1989–1999 by Norman Ramsey.

But it seems to be maintained.

 Recent versions have been converted to plain C.  The changelog for
 version 0.7.44 says:
 * Convert from noweb to plain C

Good to know :) But I think it is not yet released in stable.

Regards,
Steffen


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounnj9wxydqnavtk3oyxpktmzxrs8ldrrf-mitv-fxk9...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

On Fri, Oct 18, 2013 at 9:53 AM, Tom H tomh0...@gmail.com wrote:
   auto eth0
   iface eth0 inet static
   address 10.0.5.16
   netmask 255.255.255.0
   iface eth0.77 inet manual
   auto br0.77
   iface br0.77 inet manual
   bridge_ports eth0.77
   bridge_fd 0
   bridge_maxwait 0

 You're bridging in strange/incorrect way. :(

 It's br0.77 that should have an ip address assigned and the physical
 devices should have inet manual only.

The physical interface eth0.77 has no IP in the example above,
but is it possible to bridge VLAN devices?
I had assumed someone has to bridge e.g. eth0 and use the VLAN
tags only on top of br0.

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnPzOR=8UEPA2He-=ou8rrt2sso-t0yorf6yyffume4...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

Hi,

thanks again for your fast help.

On Fri, Oct 18, 2013 at 1:18 PM, Tom H tomh0...@gmail.com wrote:
 So Bob must be right about your ifupdown version not using iproute

I'm using Wheezy with ifup version 0.7.8, I think this is the
latest officially released (aka the best) one?

 and, as he suggested, you're going to have to use the equivalent of:

 allow-auto eth0.9
 iface eth0.9 inet static
 address 192.168.1.119
 netmask 255.255.255.0
 gateway 192.168.1.1
 post-up ip address add 192.168.1.199/24 dev eth0.9

I took this 1:1 resulting in the following /etc/network/interfaces file:

---8===
auto lo
iface lo inet loopback

allow-auto eth0.9
iface eth0.9 inet static
  address 192.168.1.119
  netmask 255.255.255.0
  gateway 192.168.1.1
  post-up ip address add 192.168.1.199/24 dev eth0.9
===8---

Now I get ERROR: trying to add VLAN #9 to IF -:eth0-  error: File exists
only once, but still.

Is the example above correct? Does it work for you? Could your
machine be boot so quickly that it might not be visible without
adding --noclear to /etc/inittab for tty1 getty?

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnMZyXhLcLgxbL-x1eWAWnDOeBrMO9760sHy=reg22r...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

Hi,

just in case someone still reading my boring DHCP client attempts, to
complete the topic here my findings about behavior at shutdown. Even
with simply /etc/network/interfaces configuration:

  allow-hotplug eth3.77
  iface eth3.77 inet dhcp

and manually starting ifup eth3.77 after boot, on shutdown there are
error messages from dhclient. According to syslog dhclient is not
killed but aborts with:

  dhclient: receive_packet failed on eth3.77: Network is down

and very soon afterwards:

  dhclient: Bind socket to interface: No such device

which leads to error messages to the console as well. I tried to
analyze with strace, but of course output is quite complex.  dhclient
-v -r -pf [...] is called to release a lease, if any. Although pidfile
is specified, dhclient does not write to it. A bit later the pid from
the pid file is killed, this is not synchronized with waiting for the
started dhclient to finish nor for the killed dhclient to terminate.

I think this forms a race condition that on some systems may not lead
to an error.

Am I simply too picky when not wanting error messages on Console?

Interestingly ifdown kills pid from pidfile without further checking,
which IMHO also is wrong. For hotplug-interfaces it could be a very
old PID in the file and the number could have been reused by another
process (isn't it a bit unexpected to find such things in base
services like ifup that are supposed to be rock-solid?).

Steffen

On Fri, Oct 18, 2013 at 2:05 PM, Steffen Dettmer
steffen.dett...@gmail.com wrote:
 Hi,

 thanks again for your fast help.

 On Fri, Oct 18, 2013 at 1:18 PM, Tom H tomh0...@gmail.com wrote:
 So Bob must be right about your ifupdown version not using iproute

 I'm using Wheezy with ifup version 0.7.8, I think this is the
 latest officially released (aka the best) one?

 and, as he suggested, you're going to have to use the equivalent of:

 allow-auto eth0.9
 iface eth0.9 inet static
 address 192.168.1.119
 netmask 255.255.255.0
 gateway 192.168.1.1
 post-up ip address add 192.168.1.199/24 dev eth0.9

 I took this 1:1 resulting in the following /etc/network/interfaces file:

 ---8===
 auto lo
 iface lo inet loopback

 allow-auto eth0.9
 iface eth0.9 inet static
   address 192.168.1.119
   netmask 255.255.255.0
   gateway 192.168.1.1
   post-up ip address add 192.168.1.199/24 dev eth0.9
 ===8---

 Now I get ERROR: trying to add VLAN #9 to IF -:eth0-  error: File exists
 only once, but still.

 Is the example above correct? Does it work for you? Could your
 machine be boot so quickly that it might not be visible without
 adding --noclear to /etc/inittab for tty1 getty?

 Regards,
 Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounp1nr8uj+gds6kkkbn_5eizvvn7x4qqdjoj3xs7car...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

Hi!

On Fri, Oct 18, 2013 at 3:24 PM, Tom H tomh0...@gmail.com wrote:
 I'm using Wheezy with ifup version 0.7.8, I think this is the
 latest officially released (aka the best) one?

 Strange. I was under the impression that Debian 7's ifupdown is using
 iproute but you had a vconfig error in an earlier email - and the
 trying to add error below also looks like an ioctl error rather than
 a netlink one.

Ahh, that is a good point, yes, of course, there are old-style
errors instead of this NETLINK: file already exists! I saw the
message but completed missed that.

I'm looking at strace -e execve -f -o out ifup eth1.77, and one
one box I see:

  (no stat vconfig)
  ip link add link eth1 name eth1.77 type vlan id 77

and on the other I see:

  stat64(/sbin/vconfig, {st_mode=S_IFREG|0755, st_size=8032, ...}) = 0
  vconfig set_name_type DEV_PLUS_VID_NO_PAD
  vconfig add eth3 78

I think I manually installed package vlan on only this second
box at a previous test. This package is not on the first box
(altough documentation seems to suggest it would be needed).

If first strace would include stat(...vconfig...) I would assume
ifup tries vconfig and fall-backs to ip (but I think it should be
other way around), but may be there is a different way to detect
usage of vconfig...

 Does anyone know whether adding an ip address with ip to an interface
 configured with ifconfig isn't possible? Probably not.

On Shell and without VLAN, I'm used to create first IP with
ifconfig ethX ip netmask ... up and then use ip addr add
 (mostly because I always forget the ip link set up syntax :))
and this works, so simply setting IPs normally is no issue
(except that they are normally not visible in ifconfig of course).

 So the post-up should be post-up ifconfig eth0.9:0 192.168.1.199
 netmask 255.255.255.0 up, although I can't remember ever coming
 across such an interface (or know whether it's possible to do
 something like this with net-tools!).

The following commands procedure no error:

ifconfig eth3.78:0 192.168.1.199 up
ip addr add 192.168.1.200 dev eth3.78
ip addr add 192.168.1.201 dev eth3.78:0   # funny :)

resulting in

9: eth3.78@eth3: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
noqueue state UP
link/ether 08:00:27:46:0a:34 brd ff:ff:ff:ff:ff:ff
inet 10.0.5.15/24 brd 10.0.5.255 scope global eth3.78
inet 192.168.1.199/24 brd 192.168.1.255 scope global eth3.78:0
inet 192.168.1.199/32 scope global eth3.78
inet 192.168.1.200/32 scope global eth3.78

So seems to be nicely compatible.

 Maybe you could try to do what you want using net-tools manually to
 remove any ifupdown bug from the mix.

Yes, this could be an option, but probably taking a day to
implement and another for testing (I'm always optimistic, you see :)).

 Is the example above correct? Does it work for you? Could your
 machine be boot so quickly that it might not be visible without
 adding --noclear to /etc/inittab for tty1 getty?

 I tested once. I just took down the network so that only lo was
 defined and then brought it up with what I'd posted.

Do you have package vlan installed? Maybe I should retest after
removing package vlan...

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounnjohdmb1tc5ubswhrqatgmy2_buexqoduukoed0pk...@mail.gmail.com

Re: Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

On Fri, Oct 18, 2013 at 3:24 PM, Tom H tomh0...@gmail.com wrote:
 ---8===
 auto lo
 iface lo inet loopback

 allow-auto eth0.9
 iface eth0.9 inet static
   address 192.168.1.119
   netmask 255.255.255.0
   gateway 192.168.1.1
   post-up ip address add 192.168.1.199/24 dev eth0.9
 ===8---
 Is the example above correct? Does it work for you? Could your
 machine be boot so quickly that it might not be visible without
 adding --noclear to /etc/inittab for tty1 getty?

 I tested once. I just took down the network so that only lo was
 defined and then brought it up with what I'd posted.

I retested after dpkg -P vlan, booted a couple of times and got
no single error. Seems this mean to use VLAN someone should better
not install package vlan... :-)

Good spot about the non-NETLINK errors!! Thanks so much, I completely
missed that!

So maybe there is just some issue about some vconfig
backward-compatiblity in ifup?

Have a great weekend, Tom and all the list!

Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnNKOkDh=bnb1jPuwv1XUWwdV_3vUU=FYecNGdnR7PN-=g...@mail.gmail.com

Configuring multiple IP addresses on VLAN interface using ifupdown

[Steffen Dettmer]

Hi,

I'd like to configure multiple IP addresses to a VLAN tagged interface. I tried

auto eth3.107
  iface eth3.77 inet static
  address 10.0.5.15
  netmask 255.255.255.0
  iface eth3.77 inet static
  address 10.0.5.16
  netmask 255.255.255.0

but I get an error message that ifup tries to configure the VLAN
interface twice, but the addresses are set.

When I remove the second iface eth3.77 inet static line, which
should be correct according to my understanding of man interfaces,
where it is not forbidding to pass multiple address directives in a
stanza, I get an error about unexpected address line and the
addresses are not set.

First I thought ifup would be a shell script, but apparently
ifupdown uses source code generation to generate Perl code from some
noweb code and uses the generated Perl code to generate C code which
then is compiled using a generated Makefile -- all this is not easy to
read / understand, so I decided to write a mail here hoping someone
can enlighten me :)

Best regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caobounotvn9b6_vtoptspua_dc0fqr+s2rctoxyqw8mn59k...@mail.gmail.com

Passing nowait command line option to dhclient

[Steffen Dettmer]

Hi,

I configured several interfaces using ifupdown using DHCP by stanzas like:

auto eth2
  iface eth2 inet dhcp

When booting and one of the DHCP interfaces has no cable attached,
booting is delayed about around 60 seconds (seems to be value of
dhclient.conf:timeout). I think I have to pass the option -nw to
dhclient, but how do I do that correctly? Apparently the dhclient
invocation call is hardcoded in ifupdown, but surely I didn't
understand the C source code (which is generated by a generated source
code generator).

I noticed that DHCP leases are kept as long as the lease is valid when
moving from one LAN to another, not sure if this behavior is correct.
I considered ifplugd which solves both issues, but then all static
addresses of the interface are missing as long as no cable is plugged
(which might usually be expected on Desktops / Laptops, but might not
be desired on other devices, because it prevents from binding sockets
to specific IP addresses).

How to configure DHCP correctly without causing boot delays?

Regards,
Steffen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOBoUnPcfMLd0SoQnRBJiWnL4h1ZwvSffGWD-8GkgEr=t_z...@mail.gmail.com