Proposal v2: enable stateless persistant network interface names
Hello all, some 4 weeks ago I sent a first proposal to change persistent network interface naming away from our current /lib/udev/rules.d/75-persistent-net-generator.rules (which is inherently racy and doesn't apply to all virtualized environments) to udev's "net.ifnames": https://lists.debian.org/debian-devel/2015/05/msg00170.html Thanks to the comments and followups! Based on that I updated the proposal. (Sorry for the delay..) Martin Pitt [2015-05-08 7:59 +0200]: > Details about [ifnames] > --- > This is a generic solution which extends the [biosdevname] idea and > thus applies to all practical cases and all architectures. It doesn't > need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus > applies nicely to snappy/touch, and also avoids the race condition. > > The main downside is that by nature the device names are not familiar > to current admins yet. For BIOS provided names you get e. g. ens0, for > PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a > necessary price to pay (biosdevname names look similar). The main objection in the discussion was that path based names aren't appropriate for USB based devices. I agree, so I change my proposal to use MAC based names for anything USB based. The names will look even worse as they include the MAC in hex (enx112233445566), but the two goals "use MAC for these devices", "don't maintain state files in /etc", and "avoid any collisions" don't leave room for much else. However, on a desktop you don't ever care about the device names, and higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) > Proposal > > I propose to retire [mac], i. e. drop > /lib/udev/rules.d/75-persistent-net-generator.rules and enable > [ifnames] by default. Amendment: ... and ship a naming policy by default which uses MAC based names for USB. FYI, this will look like | $ cat /lib/systemd/network/01-mac-for-usb.link | [Match] | Path=*-usb-* | | [Link] | NamePolicy=kernel database mac onboard slot path | MACAddressPolicy=persistent It's easy enough to override/customize, see man systemd.link. (Despite the name, this is all udev; it doesn't depend on using systemd or networkd). This will of course also be included in the documentation. > For upgrades: As we don't know what refers to existing stable network > names, we can't ever safely remove a generated > /etc/udev/rules.d/70-persistent-net.rules. So when we do the above, > names on existing installations will *not* change (as > 70-persistent-net.rules trumps [ifnames]). > > So we can only let time and replacing/reinstalling machines take care > of this. Michael Biebl and I discussed that the other day. We plan to do that in steps: stretch: - Enable ifnames for new installations - Drop [mac] generator - Point out the transition/documentation in NEWS - Ship example rules to show how to use your own custom names stretch+1 (or maybe +2): - Check existance/non-emptiness of /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, Show critical debconf note, and refuse to upgrade - Drop our hack to retry renames for a while (to mitigate the race) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
Martin Pitt [2015-06-03 12:01 +0200]: > | $ cat /lib/systemd/network/01-mac-for-usb.link > | [Match] > | Path=*-usb-* > | > | [Link] > | NamePolicy=kernel database mac onboard slot path > | MACAddressPolicy=persistent Sorry, that was an old version. We want this: NamePolicy=kernel database onboard mac I. e. prefer onboard names over mac, and never use slot/path based names for USB; the latter will hardly make a practical difference, but it's cleaner that way. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: Proposal v2: enable stateless persistant network interface names
Le 03/06/2015 12:01, Martin Pitt a écrit : > stretch+1 (or maybe +2): > - Check existance/non-emptiness of > /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, > Show critical debconf note, and refuse to upgrade No. It is always a real pain when a preinst script fails. It is (nearly) ok when you upgrade only one package. But if you upgrade lots of packages, when the preinst script will fail, other packages will be in non-canonical state (unpacked but unconfigurated, etc.) and recovering from such a state is always really problematic. "apt-get install -f" can help but, I observed several times, the resolution is not necessarily the same as the one tried before, leading to new packages installed and, more problematic, other packages to be removed even if not expected initially. So, you can show a debconf note, try (or not) to migrate the file automatically, remove (or comment-out) the 70-persistent-net.rules, or ... but, please, do not write a preinst script that fails because the admin did not update its config before upgrading. One "good" solution would probably a new kind of scripts run by dpkg and apt *prior to any other things* (for all involved packages) to decide if the upgrade can run or not. But that would involve lots of change in apt/dpkg and I'm sure I do not oversee all the implications of such a proposal. Regards, Vincent > - Drop our hack to retry renames for a while (to mitigate the race) > > Martin > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556eda66.9010...@free.fr
Re: Proposal v2: enable stateless persistant network interface names
On Jun 03, Vincent Danjean wrote: > > stretch+1 (or maybe +2): > > - Check existance/non-emptiness of > > /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, > > Show critical debconf note, and refuse to upgrade > No. It is always a real pain when a preinst script fails. This part is not negotiable, because: > So, you can show a debconf note, try (or not) to migrate the file > automatically, remove (or comment-out) the 70-persistent-net.rules, > or ... but, please, do not write a preinst script that fails > because the admin did not update its config before upgrading. None of these solutions is applicable: either the upgrade can continue or the network interfaces names will change with unpredictable consequences. > One "good" solution would probably a new kind of scripts run > by dpkg and apt *prior to any other things* (for all involved > packages) to decide if the upgrade can run or not. But that This is more or less what apt does when apt-extracttemplates from apt-utils is available. -- ciao, Marco pgpjkqAZNTbcx.pgp Description: PGP signature
Re: Proposal v2: enable stateless persistant network interface names
Am 03.06.2015 um 12:59 schrieb Marco d'Itri: > On Jun 03, Vincent Danjean wrote: > >>> stretch+1 (or maybe +2): >>> - Check existance/non-emptiness of >>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, >>> Show critical debconf note, and refuse to upgrade >> No. It is always a real pain when a preinst script fails. > This part is not negotiable, because: > >> So, you can show a debconf note, try (or not) to migrate the file >> automatically, remove (or comment-out) the 70-persistent-net.rules, >> or ... but, please, do not write a preinst script that fails >> because the admin did not update its config before upgrading. > None of these solutions is applicable: either the upgrade can continue > or the network interfaces names will change with unpredictable > consequences. Does anyone remember how linux-base handled this when there was the /dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the conversion? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Proposal v2: enable stateless persistant network interface names
On Wed, 2015-06-03 at 13:11 +0200, Michael Biebl wrote: > Am 03.06.2015 um 12:59 schrieb Marco d'Itri: > > On Jun 03, Vincent Danjean wrote: > > > >>> stretch+1 (or maybe +2): > >>> - Check existance/non-emptiness of > >>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, > >>> Show critical debconf note, and refuse to upgrade > >> No. It is always a real pain when a preinst script fails. > > This part is not negotiable, because: > > > >> So, you can show a debconf note, try (or not) to migrate the file > >> automatically, remove (or comment-out) the 70-persistent-net.rules, > >> or ... but, please, do not write a preinst script that fails > >> because the admin did not update its config before upgrading. > > None of these solutions is applicable: either the upgrade can continue > > or the network interfaces names will change with unpredictable > > consequences. > > Does anyone remember how linux-base handled this when there was the > /dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the > conversion? It gave the option to retry conversion (assuming you manually fix something before answering) or to continue without automatic conversion. In that case the old kernel version would generally still be available as a fallback, whereas this is of course not true with udev. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Re: Proposal v2: enable stateless persistant network interface names
On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: However, on a desktop you don't ever care about the device names, and Of course you do. How will you use tcpdump or tshark without the device names? In most desktop setups a „tcpdump -i eth0” is the right command. higher-level firewall tools will also hide this. After all, we survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-) Well, but /dev/sda1 is still available. And I prefer /dev/sdaX because I have far less problems with it than with UUID=XXX. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Invoking ‘init’ from an init.d script (Wheezy)
The short question: Is it acceptable to boot a server into runlevel 1, and then invoke "init 2" from an /etc/rc1.d script to interrupt the execution of any further scripts in that runlevel and continue in RL2? The long story: We have a setup with multiple servers (running Wheezy). When booting, the servers check whether updates are available on a master server. If available, they are pulled in through a dist-upgrade. This check/update needs to happen before any of the normal services are started, to avoid the need of taking down everything and then starting it back up after the update. The most sane thing to do would be to perform this check/update as the very first init script in runlevel 2. This however seems impossible to guarantee, aside from the unmaintainable practice of adding every possible service to the Required-Start field of this script. There is a way to make a script run last (Required-Start: $all), but as you may have guessed, "X-Start-Before: $all" does not work. The next most sane thing to do would be to run the script at the end of runlevel S. When we do this however, the dist-upgrade will often hang indefinitely after the unpacking stage. Any attempt to perform the upgrade while we're still in level S, results in the same hang. Therefore to both avoid this hang and guarantee that the update is performed before any runlevel 2 service, we boot the servers into runlevel 1 and check the update there. The init script is configured as "X-Start-Before: killprocs", because we do not want anything to be killed at boot. /etc/rc1.d therefore looks like this: S01bootlogs S01motd S01magic-update-script S02killprocs S03single To allow runlevel 1 to be used normally, the script does nothing if this is not the first runlevel after boot. Otherwise it does its thing, and when done invokes "init 2" to replace the entire shell and therefore (in theory) prevent S02killprocs and S03single from being executed. This works fine in most cases. On one particular server however, we noticed that killprocs was sometimes (in about 20% of all boots) still being executed even though the 'runlevel' command already reports the current level to be 2. We managed to work around this by adding an extra check to the killprocs script that skips it if the runlevel is not 1. However, we realize that what we're doing might not be perfectly sane and wonder whether it might have other risks. We could avoid this 'init-inside-an-initscript' hack if someone had a foolproof way of guaranteeing that the init script is always executed as the very first in runlevel 2. -- Alexander Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKr4yMxo8VQiy7w8JRZf3Uh-snEygCxxsJsv8o=yq-ygi_w...@mail.gmail.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Wed, 3 Jun 2015 17:26:21 +0200 Alexander Thomas wrote: [...] > The long story: > > We have a setup with multiple servers (running Wheezy). When booting, > the servers check whether updates are available on a master server. If > available, they are pulled in through a dist-upgrade. This > check/update needs to happen before any of the normal services are > started, to avoid the need of taking down everything and then starting > it back up after the update. [...] Wouldn't it be simpler to implement this check and update using initramfs hooks? You could bind-mount /dev, /sys and /proc to the root filesystem, chroot there and run there a script which would check for updates, apply them, if any, and exit. After that the system would just resume booting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150603190921.9c5c265a63b6a12ef039a...@domain007.com
Re: Proposal v2: enable stateless persistant network interface names
Le 03/06/2015 12:59, Marco d'Itri a écrit : > On Jun 03, Vincent Danjean wrote: > >>> stretch+1 (or maybe +2): >>> - Check existance/non-emptiness of >>> /etc/udev/rules.d/70-persistent-net.rules in udev.preinst, >>> Show critical debconf note, and refuse to upgrade >> No. It is always a real pain when a preinst script fails. > This part is not negotiable, because: All is negotiable. It is a matter of what is less problematics. >> So, you can show a debconf note, try (or not) to migrate the file >> automatically, remove (or comment-out) the 70-persistent-net.rules, >> or ... but, please, do not write a preinst script that fails >> because the admin did not update its config before upgrading. > None of these solutions is applicable: either the upgrade can continue > or the network interfaces names will change with unpredictable > consequences. I would *largely* prefer a debconf notice + question asked to retry (admin can fix in-between) or continue (admin will have to leave with consequence of interface rename) than having a dist-upgrade aborted in the middle of its way. I remember upgrades aborted due to dependencies between udev and the running kernel. It was really a mess when I forgot to upgrade the kernel at first (until, if I remember correctly, the abort was modified to big debconf warnings). >> One "good" solution would probably a new kind of scripts run >> by dpkg and apt *prior to any other things* (for all involved >> packages) to decide if the upgrade can run or not. But that > This is more or less what apt does when apt-extracttemplates from > apt-utils is available. You would have to ensure that the apt hook is available *before* dist-upgrade is run. To my knowledge, no dependency can ensure this. So, this hook would have to be imposed in strech so that strech+1 can use it. Anyway, I will be very pleased if you find a way to abort the upgrade before its begining (and not just before udev upgrade) Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556f4c89.8040...@free.fr
Making a .deb file to be added into the debian repository.
I have a forum php / mysql software that I need to create a .deb for. I would like to create the .deb file so that it can be installed into the apache2 default-site folder, xampp htdocs, or both but I have noticed that both phpbb3 and mediawiki deb files installs into /var/lib and /usr/share. Is there a reason why they install into those folders and not into /usr/share/apache2/default-site ? The goal is to have my open source forum software added to the debian software center / package manager. What should I do first to try to get the software into the debian repository?
Making a .deb file to be added into the debian repository.
I have a forum php / mysql software that I need to create a .deb for. I would like to create the .deb file so that it can be installed into the apache2 default-site folder, xampp htdocs, or both but I have noticed that both phpbb3 and mediawiki deb files installs into /var/lib and /usr/share. Is there a reason why they install into those folders and not into /usr/share/apache2/default-site ? The goal is to have my open source forum software added to the debian software center / package manager. What should I do first to try to get the software into the debian repository?
Re: Making a .deb file to be added into the debian repository.
On Thu, Jun 4, 2015 at 8:17 AM, ea he wrote: > The goal is to have my open source forum software added to the debian > software center / package manager. What should I do first to try to get the > software into the debian repository? Please read this document: http://mentors.debian.net/intro-maintainers > I have a forum php / mysql software that I need to create a .deb for. I > would like to create the .deb file so that it can be installed into the > apache2 default-site folder, xampp htdocs, or both but I have noticed that > both phpbb3 and mediawiki deb files installs into /var/lib and /usr/share. > Is there a reason why they install into those folders and not into > /usr/share/apache2/default-site ? First I should mention that web app packaging is quite suboptimal at the moment. What you have suggested with default-site is an awfully specific way to install the software and won't work for many sysadmins. In particular, it only works with one web server (Apache) while there are many others and Apache is becoming less popular. A much better way would be to install everything into /usr/share/ and then have upstream provide a script that can be run by the sysadmin to setup instances of the software, with sysadmin provided web server choice, URLs and data storage locations. If you want the .deb package could then ask the sysadmin if they want to setup an instance of the software, which web server to configure for, which domain and URL to put the software at and where to store data and then pass the relevant details to the script. Or the sysadmin could be expected to run the script manually. You might be interested in this project to help improve this stuff: https://wiki.debian.org/SummerOfCode2015/Projects/AutoConfigWebApps https://wiki.debian.org/SummerOfCode2015/StudentApplications/#Automated_configuration_of_packaged_web_applications -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FPNLz347QunSLeV8zuFDrubuS74cTAj=kmoyrlx_j...@mail.gmail.com
Re: Proposal v2: enable stateless persistant network interface names
]] Stephan Seitz > On Wed, Jun 03, 2015 at 12:01:34PM +0200, Martin Pitt wrote: > >However, on a desktop you don't ever care about the device names, and > > Of course you do. How will you use tcpdump or tshark without the > device names? In most desktop setups a „tcpdump -i eth0” is the right > command. `-i any` is quite often just as easy. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mmoj9e7@xoog.err.no
