adduser + NIS [Debian 1.3 _RELEASE_CANDIDATE_ Available]
I just noticed that adduser 3.1 doesn't work together with NIS, a proper bug
report is submitted. I just mention this here again since it might be relevant
for the release of Debian 1.3.
Cheers,
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5166
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: what about Netplan?
On 11.07.24 09:16, Philip Hands wrote: Simon McVittie writes: On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote: On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote: I believe NM does not have a fixed configuration format, but only a dbus API. It's perfectly fine to edit configuration files for NM manually, see man:nm-settings-keyfile(5). ... and debian-installer already knows how to write out these files, and has done so for more than a decade if I'm reading correctly. This is not a recent innovation, and anyone who has installed our default desktop environment in the last few years - especially if they used wifi during installation - has been relying on this code path. <https://salsa.debian.org/installer-team/netcfg/> is responsible for converting the network configuration that was used temporarily in the d-i environment into a NM configuration file if NM is installed, or an ifupdown configuration otherwise. Writing the equivalents into /etc/systemd/network for systemd-networkd would presumably not be rocket science, it's a simple .ini-like syntax similar to the one NM uses. We're just in the process of adding support for netplan as well: https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 I've only seen netplan mentioned in passing in this thread so far. It seems like it is exactly what we need as a replacemtent for ifupdown (given that is what it's designed for AFAICT -- I've not yet tried it out myself though) and it already supports configuring systemd-networkd, so seems like a more sensible route than duplicating that effort in D-I. See: https://netplan.readthedocs.io/ Yes, please! As Phil mentions, we're pretty close in getting D-I support for Netplan merged [d-i/netcfg !9]. The implementation enables Netplan+systemd-networkd for new installations, except for cases where NetworkManager is available (e.g. Desktop installations). In the latter case it would enable Netplan+NetworkManager, as it is today. That way, we will be able to rely on the two most popular, well tested and well maintained networking daemons (systemd-networkd & NetworkManager), while also being able to use the common Netplan configuration language, controlling both (optionally!). Everybody is still free to write their own custom sd-networkd .network or N-M .nmconnection in /etc/ or configure the daemon through corresponding D-Bus APIs or GUI/TUI applications, by just not putting any configuration for a given interface into /etc/netplan/. Netplan should be considered a unification layer on top of those networking daemons, which allows Debian as a project to use common language around networking, e.g. in Debian-Installer [d-i/netcfg !9], [cloud] deployments or [documentation], independent of the chosen backend daemon (sd-networkd on Cloud & Server, NetworkManager on Desktop). Additional benefits of Netplan: * Already used on Debian Bookworm [cloud] images by default * Well tested (big autopkgtest suite) and supported by a company * Lots of knowledge, Q/A & tutorials on the internet, as its being used by millions of people since many years * Proven track record, being the default for several Ubuntu LTS releases * Python dependency considered optional, base installations only need the "netplan-generator" package * Solid documentation and a stable API for libnetplan, as of [Netplan 1.0] This would allow us to combine the best of two worlds, while leaving everybody with full flexibility for custom configurations. In addition to that, I'd propose to keep ifupdown in maintenance mode for a transitional period (Trixie at least), to keep backwards compatibility for existing systems and give people some time in transitioning to new networking tools. Cheers, Lukas PS: If you happen to be at Debconf in Korea in a few weeks, please join my [networking BoF]. [d-i/netcfg !9] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [cloud] https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ [documentation] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_cloud [Netplan 1.0] https://blog.slyon.de/2024/04/04/netplan-v1-0-paves-the-way-to-stable-declarative-network-management/ [networking BoF] https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/
Re: default network management tools
On 11.07.24 02:18, Thomas Goirand wrote: On 7/10/24 20:03, Michael Biebl wrote: Since there is a lot of support for this idea, the next logical step as smcv said, would be to make d-i/netcfg networkd aware. At the beginning, this could be opt-in (for testing purposes) and we could make it the default later on. Any takers? If someone were to add that support in d-i for Trixie, that'd be great. Even better IMO, if it had support for Netplan. Then we could switch the default for Forky? We're actually pretty close in getting D-I support for Netplan merged [d-i/netcfg !9], which would enable Netplan+systemd-networkd for new installations by default. In addition to that it supports Netplan+NetworkManager backend for Desktop installations, as it is today. That way, we will be able to rely on the two most popular, well tested and well maintained networking daemons (systemd-networkd & NetworkManager), while also being able to use the common Netplan configuration language, controlling both (optionally!). Everybody is still free to write their own custom sd-networkd .network or N-M .nmconnection in /etc/ or configure the daemon through corresponding D-Bus APIs or GUI/TUI applications, by just not putting any configuration for a given interface into /etc/netplan/. Netplan should be considered a unification layer on top of those networking daemons, which allows Debian as a project to use common language around networking, e.g. in Debian-Installer [d-i/netcfg !9], [cloud] deployments or [documentation], independent of the chosen backend daemon (sd-networkd on Cloud & Server, NetworkManager on Desktop). Additional benefits of Netplan: * Already used on Debian Bookworm [cloud] images by default * Well tested (big autopkgtest suite) and supported by a company * Lots of knowledge, Q/A & tutorials on the internet, as its being used by millions of people since many years * Proven track record, being the default for several Ubuntu LTS releases * Python dependency considered optional, base installations only need the "netplan-generator" package * Solid documentation and a stable API for libnetplan, as of [Netplan 1.0] This would allow us to combine the best of two worlds, while leaving everybody with full flexibility for custom configurations. In addition to that, I'd propose to keep ifupdown in maintenance mode for a transitional period (Trixie at least), to keep backwards compatibility for existing systems and give people some time in transitioning to new networking tools. Cheers, Lukas PS: If you happen to be at Debconf in Korea in a few weeks, please join my [networking BoF]. [d-i/netcfg !9] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [cloud] https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ [documentation] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_cloud [Netplan 1.0] https://blog.slyon.de/2024/04/04/netplan-v1-0-paves-the-way-to-stable-declarative-network-management/ [networking BoF] https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/
Re: what about Netplan?
On 11.07.24 11:13, Marco d'Itri wrote: On Jul 11, Philip Hands wrote: I've only seen netplan mentioned in passing in this thread so far. Because I believe that Netplan is the answer to a question that nobody asked here. It has all the disadvantages of switching to a new configuration format, but then it limits you to the features that it actually implements from each backend and you have an indirection layer that must be used when interacting with the backend daemon. Yes, it brings a new configuration format. So do systemd-networkd and NetworkManager. Netplan's feature set is pretty comprehensive and certainly enough for a default installation, see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/ But it's not an indirection layer that MUST be used. Should the features of Netplan not be enough for an advanced usecase, everybody is free to write configuration for the underlying backend directly. Netplan will not interfere with that and go out of the way. Just don't write Netplan configuration for a specific interface (or all of them) that you want to handle differently. -- Lukas
Re: what about Netplan?
On 13.07.24 17:40, Luca Boccassi wrote: On Thu, 11 Jul 2024 at 12:12, Lukas Märdian wrote: On 11.07.24 11:13, Marco d'Itri wrote: On Jul 11, Philip Hands wrote: I've only seen netplan mentioned in passing in this thread so far. Because I believe that Netplan is the answer to a question that nobody asked here. It has all the disadvantages of switching to a new configuration format, but then it limits you to the features that it actually implements from each backend and you have an indirection layer that must be used when interacting with the backend daemon. Yes, it brings a new configuration format. So do systemd-networkd and NetworkManager. Netplan's feature set is pretty comprehensive and certainly enough for a default installation, see its reference: https://netplan.readthedocs.io/en/stable/netplan-yaml/ But it's not an indirection layer that MUST be used. Should the features of Netplan not be enough for an advanced usecase, everybody is free to write configuration for the underlying backend directly. Netplan will not interfere with that and go out of the way. Just don't write Netplan configuration for a specific interface (or all of them) that you want to handle differently. I appreciate the work you've done on Netplan and I am quite sure your D-I MR should be merged, it looks ready to me. It's good to have this support in the installer. ACK. Cyril has been pretty busy with release management stuff, but we'll get there. However, I do not think it should be the default. First of all, only Ubuntu uses it, nobody else - as Simon says, we don't want the defaults to be super-special things that nobody else uses. And then Actually, I think this is an agrument FOR Netplan, not against it. Netplan is being used by millions of users for 7+ years. Plenty of usecases have been tried and documented. It's clearly not a "super-special thing that nodbody uses". Whereas I'm not aware of a major Linux distro using systemd-networkd directly, Debian would be singeling out itself. I see some of networkd's strengths with advanced users who want to dig deep and have full control at minimal resource usage (e.g. Arch Linux). Also with lightweight container usecases, where network config only needs minimal manipulation after deployment (if at all). The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have (natually) been very close to each other (e.g. package management) and together with its derivatives create the Debian ecosystem. Going with Netplan by default would further harmonize the shared knowlege within our ecosystem. again, not your fault in the slightest, but Canonical is known for shifting its priorities every now and then - perfectly normal for a for-profit company, but a bit worrying when one wants to pull all eggs in that basket. And also for the minimal case, an additional layer of indirection and set of dependencies, when there's an alternative that requires none of that, is not the ideal solution. We want to have a default choice that is easy to grok for everybody. Reading through this tread and other places, this doesn't seem to be true for sd-networkd. That's one reason why people are driving it through Netplan instead (e.g. Debian cloud & Ubuntu). But the minimal sd-networkd solution has its merit for sure and should be considered when optimizing producs or usecases. As the upstream maintainer of Netplan I've been building the Netplan community over the last couple of years, trying to help everybody getting along with their contributions. And I'm seeing continuous growth and adoption. It's not an "all egs in one basked" situation. We've had major corporations like "Deutsche Telekom" dropping their internal [netplanner] tool in favor of upstream Netplan, after they've contributed a new feature that they had been lacking in Netplan. Also Microsoft contributed to improve integration with [Azure Linux], besides plenty of individual contributors that help with feature develpment and bug fixes for every [Netplan release]. This happens without commercial engegemnt of Canonical. So I am quite sure that yes netplan should be supported in the installer and your MR should be merged, but the new default for the default, simple, wired case should be networkd, and for the GUi/desktop case the default should continue to be NetworkManager. We shouldn't have too many special cases, this will only increase fragmentation. But rather strive to have single way to tell the common user "how to do networking on Debian". With Netplan, no differentiation between Server/Desktop/Cloud or wired/wireless would be needed. Cheers, Lukas [netplanner] https://github.com/telekom/netplanner/blob/main/README.md [Azure Linux] https://github.com/canonical/netplan/pull/445 [Netplan release] https://github.com/canonical/netplan/releases
Re: what about Netplan?
the responsibility of them being an important system component. So those two are actually not my main concern here, and if we had no good alternative, I'd be saying: yes they're relatively bulky for a container/embedded use-case, but on a typical server installation they're fine. python3-dbus is a concern to me, though. [...] I am not involved in libyaml, python3-yaml and other dependencies enough to comment on whether they raise similar concerns. I dropped some of the python3-* concerns from the citation, as I think it's not relevant (anymore). We've had a similar networking discussion last year where Netplan's Python dependency was brought up as a concern. That's why we split out the "netplan-generator" package. The Python dependency is only needed for Netplan's CLI that brings convenience features and can be installed optionally. For the default installation, we're only talking about "netplan-generator" + "libnetplan1", which does have transitive dependencies on GLib (yes), libuuid and libyaml, besides libc. So the footprint is fairly small. Benefits vs. costs -- I can see that Netplan aims to have some benefits over configuring the backend directly: its configuration format might be nicer than networkd's or NM's (this is a matter of opinion, I personally think networkd syntax is fine in at least the simple cases that are relevant for a default), and it lets a sysadmin switch between backends without explicitly translating configuration (I'm not convinced this actually happens frequently enough to justify the complexity, but opinions can vary). The question for the project is whether those benefits, in total, exceed the costs of adding this layer over the top of what we could just be using directly (networkd or NM, or for that matter, ifupdown). I think you're lacking a very important point here. As a project we want to have a congruent answer following question: = "How to do networking on Debian?" = If we have to tell our users and sysadmins to do "X" on Debian server systems (using ifupdown or potentially sd-networkd), while doing "Y" on Debian desktop systems (using NetworkManager), while doing "Z" on Debian cloud systems (using Netplan), while doing something totally different on RaspberryPi (or alike) boards that run a Debian server setup, but using WiFi as their primary network interface, that's just a really bad user experience. Using Debian should NOT feel like using different distros. And we really need a common way to do network configuration. With Netplan we can tell people to just use use the "dhcp4: true" setting (for example), which will work on all Debian systems and is automatically translated to the corresponding backend for server/desktop/cloud/embedded usecases. All while giving sysadmins the flexibilty to fully utilize the underlying network daemon directly, if they feel like writing native configuration for it (or don't like Netplan). Cheers, Lukas
Re: what about Netplan?
On 15.07.24 15:50, Luca Boccassi wrote: On Sun, 14 Jul 2024 at 19:21, Simon McVittie wrote: Dependency size and maintenance --- I also notice that the netplan.io package would bring GLib, Python, python3-dbus and python3-yaml into the dependencies of the base system, among others. As an upstream and downstream maintainer of GLib, and in practice the only upstream and downstream unmaintainer[1] of python3-dbus, I'm not comfortable with that, both for size reasons (GLib and Python are not small) and for quality and maintainedness reasons (python3-dbus). GLib and Python are relatively large in both on-disk size and attack surface, but they're essential to our desktop installations anyway, reinventing them in parallel would be worse than reusing them, and their maintainers have already accepted the responsibility of them being an important system component. So those two are actually not my main concern here, and if we had no good alternative, I'd be saying: yes they're relatively bulky for a container/embedded use-case, but on a typical server installation they're fine. Let's put some hard numbers on the table given this is an important detail. The following is all starting from a default debootstrapped unstable. With networkd only we can drop ifupdown, net changes: REMOVING: ifupdown Summary: Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0 Freed space: 207 kB Using network-manager in headless mode (no GUI) brings in: Installing: network-manager [...] Summary: Upgrading: 0, Installing: 69, Removing: 0, Not Upgrading: 0 Download size: 28.2 MB Space needed: 110 MB / 8295 MB available Installing netplan.io instead brings in: Installing: netplan.io [...] Summary: Upgrading: 0, Installing: 42, Removing: 0, Not Upgrading: 0 Download size: 25.2 MB Space needed: 101 MB / 8340 MB available So we have a net gain of ~200K when using networkd, a net loss of ~110M when using network-manager, and a net loss of ~101M when using netplan. Furthermore, netplan pulls in a lot of python dependencies that are not exactly recommended, as Simon said. And I think one of the reasons ifupdown2 never gained traction was because it pulled in python3, which was considered a deal breaker for the default minimal install. It seems to me if something other than networkd is desired, network-manager would be the better choice. As stated previously, we don't need the Netplan CLI's Python dependency. It's nice and convenient and can be installed is Python is installed anyway. Let's re-do the Netplan numbers: # apt install netplan-generator Installing: netplan-generator Installing dependencies: libglib2.0-0t64 libglib2.0-data libicu72 libnetplan1 libxml2 libyaml-0-2 shared-mime-info xdg-user-dirs Suggested packages: low-memory-monitor network-manager | wpasupplicant openvswitch-switch iw Summary: Upgrading: 0, Installing: 9, Removing: 0, Not Upgrading: 0 Download size: 13.9 MB Space needed: 59.9 MB / 22.5 GB available The "shared-mime-info" seems to be the culprit for most of the additional size here. Not sure if that'd be needed in the minimal setup? And for the fun of it, let's do it once more with the minimal required set: # apt install --no-install-recommends netplan-generator Installing: netplan-generator Installing dependencies: libglib2.0-0t64 libnetplan1 libyaml-0-2 Suggested packages: low-memory-monitor network-manager | wpasupplicant openvswitch-switch iw Recommended packages: libglib2.0-data shared-mime-info xdg-user-dirs Summary: Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 0 Download size: 1,728 kB Space needed: 5,265 kB / 22.5 GB available So yes, we have an additional overhead of ~5M, in cases where GLib is not already installed and even less on systems with NetworkManager, as we'd share some dependencies. 5M of additional storage shouldn't be a huge issue in today's world, IMHO. For the benefit of gaining a common way do to networking on Debian. -- Lukas
Re: what about Netplan?
On 15.07.24 16:06, Marvin Renich wrote: * Lukas Märdian [240715 09:36]: I don't want people to think too much in terms of "sd-networkd VS Netplan", but rather in terms of "sd-networkd PLUS Netplan". I'm a little confused. Much earlier in this thread it was stated that ifupdown2 was out of the running simply because it brings in python, even though some consider it a better alternative than ifupdown-ng. However, netplan.io also brings in python. Do I misunderstand which package would be used to implement Netplan as being discussed here? If we _are_ talking about netplan.io, then shouldn't we also bring ifupdown2 back into consideration? No. We're talking about the "netplan-generator" package, which comes without any Python dependencies. It's a part of the netplan.io source package and everything that would be required in the default installation. -- Lukas
Re: what about Netplan?
On 16.07.24 08:00, Marc Haber wrote: On Mon, 15 Jul 2024 15:35:32 +0200, Lukas Märdian wrote: I don't want people to think too much in terms of "sd-networkd VS Netplan", but rather in terms of "sd-networkd PLUS Netplan". Contributors to Netplan naturally build up knowledge in sd-networkd (and NetworkManager), so we would actually have more minds knowledgeable about our network stack. Other than being fully RFC 1925 6a compliant, why do we need that layer then? And why do we need it in the installer, which is only geared to supposed the most easy network configurations? Haha, nice one (RFC 1925)! Sure, if it would be just "sd-networkd PLUS Netplan", i.e. one layer on top of another layer, it wouldn't make any sense and could be reduced to subjective preference of the corresponding config format. But it's not just this. Netplan's beauty starts to shine when we're talking about the full picture: * Netplan PLUS sd-networkd (server/cloud/container) * Netplan PLUS NetworkManager(desktop/laptop) * Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi) * Netplan PLUS Open vSwitch (cloud/HPC) So instead of having multiple different ways of configuring networking on Debian systems, we should be telling one coherent story. In the end we want to have a compelling answer to this question: = "How to do networking on Debian?" = Using Debian should NOT feel like using different distros. We want a common way to do network configuration. With Netplan we can tell people to use the "dhcp4: true" setting (for example), which will work on all Debian systems and is automatically translated to the corresponding backend for server/desktop/cloud/embedded usecases. All while giving sysadmins the flexibility to fully utilize the underlying network daemon directly, to optimize their special case. = Why in the installer(s)? = The same argument applies for having it in the installer(s. Supporting a common network-configuration format across our installers, instead of multiple different "special cases" sounds like a more feasible and maintainable solution. Yes, we already have special cases in the installers today, but we should strive to reduce them over time, instead of adding more. Netplan is integrated with [cloud-init] "v2" network configuration and the "cloud-config" is adopted by many major public cloud providers (AWS, GCE, Azure, ...) as a deployment method, which makes it a well-known format. Similarly default configuration for [debian-cloud] is provided via Netplan. It is already supported in [Calamares] for our live-images and as of recently landed in [debian-installer] as well. So we should have all the technical pieces in place for a streamlined installation and network configuration story across Debian! Cheers, Lukas [Calamares] https://github.com/calamares/calamares/pull/2284 [debian-installer] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [cloud-init] https://docs.cloud-init.io/en/latest/reference/network-config-format-v2.html [debian-cloud] https://salsa.debian.org/cloud-team/debian-cloud-images/-/tree/master/config_space/sid/files/etc/netplan
Re: what about Netplan?
On 16.07.24 11:24, Jose Luis Tallon wrote: On 16/7/24 10:54, Lukas Märdian wrote: [snip] But it's not just this. Netplan's beauty starts to shine when we're talking about the full picture: * Netplan PLUS sd-networkd (server/cloud/container) * Netplan PLUS NetworkManager(desktop/laptop) * Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi) * Netplan PLUS Open vSwitch (cloud/HPC) So instead of having multiple different ways of configuring networking on Debian systems, we should be telling one coherent story. In the end we want to have a compelling answer to this question: [snip] Out of curiosity+ignorance: how does Netplan detect the environment? How reliably? It doesn't, it is all part of the explicit, declarative Netplan configuration. So the sysadmin or installer makes that decision. E.g. in the case of [debian-installer] or [calamares], we're checking if the "network-manager" package is installed in the target system and install an additional Netplan config file in that case. /etc/netplan/01-network-manager-all.yaml: network: version: 2 renderer: NetworkManager This file controls Netplan's [default renderer] on a global level and is the most common case. But different "renderer" settings can also be applied to individual interfaces; as we learned in this thread before, using multiple network daemons (i.e. backend renderers) at the same time comes with its very own challenges. Still, it works and can be useful in certain edge cases. In other cases, where only one backend option is supported in Netplan, e.g. for setting up SR-IOV devices, certain Open vSwitch configurations or wireless configurations on sd-networkd, it will pick the corresponding renderer implicitly (e.g. wpa_supplicant, ovsdb). I personally disfavour Netplan and other related tools (but open to be convinced on technical merits) Netplan isn't very common in the Debian world, yet, at least that was my impression from DebConf 2023. Still, it's already part of our stack and I'd like to invite you to play around with it, to learn more about its technical abilities. E.g. using one of our official Bookworm cloud images in a local VM: https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ Cheers, Lukas [debian-installer] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9/diffs#ba5cc2a898d2537d7b6ec1de1ec1b70a6477c2a4_53_75 [calamares] https://github.com/calamares/calamares/pull/2284/files#diff-5960a6e192d1804ed3e3b84905264cff37275564879d6d87d0668369b495c21bR150 [default renderer] https://netplan.readthedocs.io/en/latest/examples/#how-to-use-networkmanager-as-a-renderer [reference] https://netplan.readthedocs.io/en/stable/netplan-yaml/#properties-for-all-device-types
Re: what about Netplan?
On 16.07.24 11:06, tho...@goirand.fr wrote: On Jul 16, 2024 4:55 PM, Lukas Märdian wrote: > Netplan is integrated with [cloud-init] "v2" network configuration and the "cloud-config" > is adopted by many major public cloud providers (AWS, GCE, Azure, ...) as a deployment > method, which makes it a well-known format. Similarly default configuration for > [debian-cloud] is provided via Netplan. It is already supported in [Calamares] for our > live-images and as of recently landed in [debian-installer] as well. It'd be very nice if it could also support a bgp-to-the-host setup natively as well. Maybe I can catch you in Busan to explain that use case? Sure! I'm always interested in supporting new, useful scenarios. And we're also accepting PRs [upstream] ;-) This bgp-to-the-host case sounds like it needs some explanation :), so feel free to join my [networking BoF] in Busan, or catch me afterwards for an extended chat. -- Lukas [upstream] https://github.com/canonical/netplan/pulls [networking BoF] https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/
Re: what about Netplan?
On 16.07.24 11:24, Stephan Seitz wrote: Am Di, Jul 16, 2024 at 10:54:47 +0200 schrieb Lukas Märdian: * Netplan PLUS NetworkManager(desktop/laptop) All my desktops have only LAN and are working very well with ifupdown since the beginning. My Laptops are mostly in a LAN either. So NM is onlay needed for the rare cases I’m in a WLAN. Today, if you install a desktop environment that comes with NetworkManager, debian-installer will already opt to configure N-M for you (instead of /etc/network/interfaces). ifupdown is still installed and can be used, as you apparently do. With Netplan+sd-networkd (+wpa_supplicant) you would even gain another minimal option that supports the rare WLAN cases. But it sounds like you prefer using ifupdown, which is totally fine, see below. * Netplan PLUS wpa_supplicant (server/embedded, using sd-networkd on WiFi) None of my servers are using WLAN. They all work very well with ifupdown including bonding/vlans. This might not be your usecase, but I regularly see setups of "embedded boards", like Raspberry Pi, that use a server image but have the WiFi adapter as their primary network interface. The only times I didn’t get a working network with ifupdown are a) missing firmware and b) the installer doesn’t support VLAN/Bonding. And I don’t think Netplan will help here. Netplan supports VLAN & Bonding, but debian-installer deliberately writes a very basic configuration only (DHCP or static IP), leaving more advanced setups to the sysadmin, AFAIK. Maybe this is something to be discussed with the d-i team? Using Debian should NOT feel like using different distros. We want Sorry, I call this bullshit. I’m using Debian exactly because it feels different like other distros. There wouldn’t be a need for Debian if not. As Colin stated, what I said is that Debian should have a congruent networking story in itself, independent of the context you're using it in (desktop, server, cloud, etc.). I'm sorry if that wasn't clear. ifupdown *is* one of the reasons I’m using Debian. I’m not interested in editing yaml files to configure the network. Using ifupdown is totally fine! I'm not suggesting for it to go away. I even think it should continue to be part of the default installation (in Trixie at least), for backwards compatibility and to give sysadmins a choice of when and if they want to transition to new tooling. Given the maintenance burden discussed in other parts of this thread, it remains to be decided if this should be handled by ifupdown-ng or ifupdown itself. But the current maintainers (Santiago, Daniel, ...) are probably in the best position to decide about such combined "ifupdown*" efforts. People that prefer using ifupdown could then just not touch /etc/netplan, or even "rm /etc/netplan/*.yaml" and continue using /etc/network/interfaces as usual. -- Lukas
Re: what about Netplan?
On 16.07.24 15:05, gregor herrmann wrote: On Tue, 16 Jul 2024 13:13:16 +0200, Philip Hands wrote: I suspect having something that's agnostic about the underlying implementation as our default would be rather better for the non-systemd options that people care about, … Also, networkd doesn't support non-Linux and non-systemd systems AFAIK, AFAICS, the netplan packages (netplan.io, netplan-generator) currently have a hard dependency on systemd. That's true. Netplan functions as a [systemd-generator] at its core, so it will have the same limitations as sd-networkd. So ifupdown[-ng] would still be needed as a fallback for the non-systemd ports. Not saying this isn't something that couldn't be changed.. but it would be some bigger effort. In theory the "/usr/libexec/netplan/generate" binary could be called independently of systemd and produce NetworkManager configuration, for example. But looking at the Netplan backends (NM, networkd, OVS), non of them is built for non-linux architectures. So dependencies would need to be worked out first. -- Lukas [systemd-generator] https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html
Re: Network stack for Trixie
Hi Daniel, On 20.08.24 16:25, Daniel Gröber wrote: Hi Lukas, CCing d-devel, This email was intended to first gauge opinions from networking maintainers, before pushing it out to debian-devel@l.d.o.. All the points still hold and are fine to be public. But let me at least add the preamble and references that you dropped from the email quotation. --- 8< --- On 20.08.24 12:58, Lukas Märdian wrote: Hi network maintainers! After our [Networking BoF] at DebConf24 in Busan I had the impression that Santiago is primarily interested in sunsetting classic ifupdown while avoiding to pull in any Python dependency into our base installations. Furthermore, I had a chat with bluca, trying to find a compromise about the suggestion made around 38:30 of the BoF recording. – He's fine with the proposal I'll be presenting below. From previous discussion on debian-devel@l.d.o I also deduced that Daniel is interested in making ifupdown-ng a [drop-in replacement] for classic ifupdown, while the ifupdown2 maintainers are not interested in pushing their tool to become a default choice in Debian. I myself have been trying to introduce Netplan to a broader audience, after it got adopted by our [cloud-images] and integrated with [debian-installer]. --- 8< --- tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky as well as raising netplan to Priority: standard. To move this forward without conflict I think we should base the default networking tool decision on data not developer opinion. In the end it still needs to be a developer decision, because someone needs to do the work. Otherwise, we would be suffering the same way we did with classic ifupdown in the past years, as it's becoming harder and harder to maintain. We need a healthy upstream project and people willing to do the actual maintenance work in Debian. Can you please elaborate why you're opposed to raising "netplan-generator" to "Priority: standard"? That's independent of keeping ifupdown-ng installed in Forky+ and I can't find any explanation about that in your comments below. On Tue, Aug 20, 2024 at 12:58:28PM +0200, Lukas Märdian wrote: So I want to find a compromise involving all interested parties. If there are no strong objections, I'd like to move forward with a proposal (and change in priorities via ftpmasters) that is structured as follows: * Keep ifupdown[-ng] installed (Priority: important) as a fallback and for existing installations - Replacing ifupdown with ifupdown-ng, if reaching a drop-in compatible state is feasible in time for Trixie (@Daniel, what's you stance on this?) If we can find enough testers, yes. The implementation work still to be done is small enough. - bluca is requesting ifupdown[-ng] to be dropped from the default installation for Forky, which is sensible, IMO. But we also want to keep it around for a transitioning period (in Trixie), so that people relying on specific if-up/down.d hooks are covered and have plenty of time to migrate to new tooling NACK. I'm not going to do the work to get ifupdown-ng into shape for being the default just to have it removed again that's a ridiculous ask. That being said I realise that without Santiago's support as ifupdown maintainer I don't have much of a procedural leg to stand on in opposing this. It wasn't an ask, the intention was to have it only if feasible, with acceptable efforts. Keeping classic ifupdown maintained for a transitioning period in Trixie would be an option, too, IMO. That's why we started forming the new "Debian Networking Team" after our BoF discussions in Busan, so we could bundle resources and help each other out with critical maintenance & have a common channel for communications. Testing new/compat functionality in ifupdown-ng could certainly fall into the same category where the [networking team] could provide support. Sunsetting classic ifupdown earlier and having a drop-in compatible ifupdown-ng would certainly be nicer, in order to reduce maintenance burden. And knowing there is a tool around that can be used by people relying on /etc/network/interfaces longer term, even after it might (potentially) get dropped from the base installation in Forky+. * Keep sd-networkd installed (as part of the systemd package), becoming the recommended network config tool for minimal installations - In debootstrap/chroots and also in minimal D-I installations (without "standard utilities"),after the [networkd enablement] MR is landed NACK. I have a counter proposabl for this but let's focus the discussion the the idea below first. Yes! This was the original intention of my email. Please share your proposal with us, so we can discuss and find consensus. We shouldn't be holding things back, as after finding consensus we'll still need to impleme
Re: Community survey on network stack for Trixie
On 03.09.24 16:13, Alexandru Mihail wrote: Hi, I second Hakan's thoughts and reasons for using NetworkManager going forward, as opposed to netplan. I work in a company which ships boat loads of network devices (think industrial routers, GSM gear, factory equipment) running a wide variety of Linux from Ubuntu, RHEL, Debian, etc. The way NetworkManager (including nmcli commands) interoperate seamlessly between RHEL land, SUSE, Arch, Gentoo and Ubuntu(maybe Debian) helps a lot with maintaining complex network appliances which run on everything with minimal effort. Think multiple VLANs on GSM connections, testbeds with hundreds of network namespaces (managed with NetworkManager), docker fleets with predictable network topology, etc. All of this is very much possible and reasonably well documented with NetworkManager+systemd-networkd. I also think using a system which most of Linux land already uses can potentially drive talent to maybe help with NetworkManager integration here. There's waay more knowledgeable people in NM land than in netplan in my opinion. On a more personal note, I enjoy using NetworkManager more than netplan as well, I find the syntax and nmcli way easier to use and harder to result in a borked network config. I also think my personal preference is of little importance, compared to my professional experience with both networking systems. I’m a system administrator, and with my colleagues, we manage approximately 1200 servers from physical installation to managing users’ applications and everything in between. This includes network design, wiring and implementation. To be honest, not of our fleet is completely Debian, but many are, and I personally prefer to work with NetworkManager rather than Netplan. The reasons are numerous. Thank you Alexandru and Hakan for sharing your experiences! The nice thing about Netplan is that it would not force you into any of those stacks (NetworkManager or systemd-networkd), but functions as a layer on top. Yes - this is an additional abstraction layer, but it brings the benefit of unification. Keeping simple configurations simple across Debian. Independent of the underlying network stack. It avoids user confusion if we can provide a single way of how to configure the networking on Debian. Advanced sysadmins (like you) will probably choose a network stack for their specific needs, as you already do. In such cases Netplan can easily be ignored and the underlying NetworkManager or systemd-netword stacks can be configured natively, as you do today. Netplan will by default get out of your way if you don't configure it specifically. Cheers, Lukas
Re: Community survey on network stack for Trixie
Hi all! On 04.09.24 15:46, Marc Haber wrote: On Wed, 4 Sep 2024 11:27:45 +0200, Chris Hofstaedtler wrote: * Marco d'Itri [240903 14:04]: My position is that I am happy for Debian to have the option of netplan but I do not think that it should be installed by default, because it is an abstraction which adds complexity and that nobody asked for other than its developers. And this is an orthogonal issue with deciding if ifupdown is appropriate for a modern system (I have been using it for close to 30 years and at this point I think that it has served its purpose and there are better defaults...). I want to echo all of this. All my customers sites are currently migrating away from ifupdown to networkd, and they don't need or want an intermediate layer. For the desktop(-like) systems, NetworkManager works nicely, again without a need for an intermediate layer. This, and this. Again, having the option is nice. But I don't see netplan as a useful default. And, choosing Netplan as a default doesn't solve the issue, since we'd still have to decide what we'd use below it by default, leaving us with the same hard decision: NetworkManager which bears its mock name NetworkDamager for a reason, systemd-networkd which is kind of unsuitable for desktop(-like) systems, comes from the much-hated systemd world (thus igniting a systemd debate everywhere it is mentioned) and contains way to much not-invented-here code regarding IPv6, or ifupdown, which is outdated if I'm being friendly, and a Debianism. That's exactly the point of Netplan. Try looking at the bigger picture: Debian as a whole. With Netplan we could provide coherent network configuration across all variants of Debian (server, cloud, laptop, ...), while choosing the best underlying stack for the usecase (i.e. systemd-networkd on server/cloud and NetworkManager on desktop/laptop). Yes, it's an additional abstraction layer, but it brings the big benefit of coherence across Debian. Not confusing our users by having 4 different ways to do network configuration. In our documentation we could reference a single Netplan configuration, that would get applied to both of the underlying stacks. As stated previously, advanced users can easily configure the underlying stack natively and Netplan will get out of their way. Cheers, Lukas
Re: Community survey on network stack for Trixie
On 04.09.24 13:28, Daniel Baumann wrote: On 9/3/24 18:24, Lukas Märdian wrote: The nice thing about Netplan is that it [...] functions as a layer on top. I don't understand what actual problem netplan is trying to solve. On servers I want systemd-networkd directly anyway (for lacp, vlan and bridges), and on end-user desktops I'm not modifying anything other than selecting the WLAN. Is netplan then only ment for "power-users" who don't want systemd-networkd or need a everything-in-one-file oversimplification of systemd-networkd? I'd argue it's the exact opposite, actually. Netplan is for the average user who googles about "how to configure network on debian" and ends up with the "4 ways to configure the network" [4ways] or even more options in the Debian Reference [debref]: * The modern network configuration for desktop * The modern network configuration without GUI * The modern network configuration for cloud * The low level network configuration Now, what configuration does the average user chose, without necessarily knowing the underlying stack? With Netplan we could slowly converge to a set of instructions that work everywhere. While at the same time we could still support/provide two modern upstream stacks (NetworkManager & systemd-networkd) for everybody's liking. OTOH, "power-users" (and I count most people on this mailinglist into that group) know exactly what network stack comes with their chosen variant of Debian and they know how to drive it. -- Lukas PS: Netplan isn't a everything-in-one-file thing. It parses a hierarchy of configuration files and packages or installers could for example ship drop-in config snippets in /usr/lib/neptlan/, as debian-installer [d-i] and Calamares [live] are doing. [4ways] https://wiki.debian.org/NetworkConfiguration#A4_ways_to_configure_the_network [debref] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html [d-i] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [live] https://github.com/calamares/calamares/pull/2284
Re: Community survey on network stack for Trixie
On 04.09.24 17:26, Marco d'Itri wrote: With Netplan we could provide coherent network configuration across all variants of Debian (server, cloud, laptop, ...), while choosing the best underlying stack for the usecase (i.e. systemd-networkd on server/cloud and NetworkManager on desktop/laptop). Of course we could. But who would actually care? That's exactly the problem! The network stack discussion has been going on since at least 2021 when Maximilian presented ifupdown-ng at DebConf 2021 [debconf21]. DDs and other people close to Debian know exactly what they are doing and just start configuring their machines with one of the modern stacks they like (e.g. NetworkManager or systemd-networkd), see the experienced shared above in this thread. But we ought to look at the bigger picture! People looking from the outside in will get very confused by the scattered Debian networking landscape. Yes, it's an additional abstraction layer, but it brings the big benefit of coherence across Debian. Not confusing our users by having 4 different ways to do network configuration. XKCD 927 Right, I've heard/red that so many times ... :-/ But in the end we don't want to bloat our base-installation with NetworkManager and systemd-networkd is not fit to cover the desktop/laptop usecase. So why not put some glue around it, to make it all feel coherent, without limiting anybody in their decision to choose whatever stack they like? In our documentation we could reference a single Netplan configuration, that would get applied to both of the underlying stacks. As stated previously, advanced users can easily configure the underlying stack natively and Netplan will get out of their way. Do we even have general documentation about configuring networking? Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref: * https://wiki.debian.org/NetworkConfiguration * https://www.debian.org/doc/manuals/debian-reference/ch05.en.html Together, they show something like 5+ ways of how to do things: * /etc/network/interfaces * iproute2 * Netplan * NetworkManager * systemd-networkd Which one to choose? Well it all depends on the underlying stack, which the average user might not necessarily know. So it's very confusing. -- Lukas [debconf21] https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/
Re: Community survey on network stack for Trixie
On 05.09.24 11:36, Daniel Baumann wrote:
On 9/5/24 10:43, Marc Haber wrote:
I don't see a problem with keeping ifupdown{2,-ng,} if none of those
packages is part of the default install and we remove it from the
beginner- and intermediate-level docs.
right, me neither; but Lukas' argument was that introducing netplan is
"unifying documentation" which there are better ways to get to that (one
of which you just suggested too, thanks).
Me neither!
My draft proposal that was shared in the beginning of this thread intents
to keep ifupdown (maybe ifupdown-ng, once it's drop-in compatible) around.
At least for a transitioning period. If we want to drop it from the base
installation eventually or not is fine for me either way. But for the
release where we switch our network stack, we should definitely keep it
around, to give sysadmins some time to adopt to the new recommended tooling.
C'mon, you stated yourself above that "unifying documentation" is an
exaggeration. It is a visible example that leads to user confusion.
In reality it's about unification of network configuration:
I want to cleanup the the scattered networking landscape in Debian, using
modern, maintained and tested tools.
You can read-up on the more detailed reasoning in my [slides] from DebConf.
-- Lukas
[slides] https://people.ubuntu.com/~slyon/slides/debconf24/debian-networking.pdf
Re: Community survey on network stack for Trixie
On 04.09.24 21:41, Daniel Baumann wrote: sorry, one more.. On 9/4/24 18:00, Lukas Märdian wrote: But we ought to look at the bigger picture! From that point of view, it doesn't make sense to even consider netplan. No distribution other than ubuntu is using it. If Debian uses network-manager and systemd-networkd, there's hardly any difference in the configuration wrt/ to the other major distributions, so, *that* has the potential to unify documentation. Except that others recommend only ONE tool and stick to it, while Debian would recommend two at the same time. (Three actually, as Netplan is used in our cloud-images.) That's exactly what leads to confusion. * Fedora/RHEL recommends NetworkManager * Ubuntu recommends Netplan * For others like Arch Linux or Gentoo, people choose their stack explicitly, so it doesn't really matter. Debian would recommend NetworkManager for desktop/laptop, systemd-networkd for server, Netplan for cloud. And people would need to do their research to understand what stack they are on, to then better understand how to control it. or in other words: If you would truly care for that then let's use the chance to *remove* some Debian-isms (ifupdown and friends) from the "big picture", rather than further *adding* more divergence by fostering netplan. I'm all for removing Debian-isms, but I guess that's a discussion for another year... Agreeing on Netplan would provide us with the hybrid stack that you described above, but without the confusion. Furthermore, it's been proven in Ubuntu for 7+ years, so lots of edge-cases have already been hit and handled. Cheers, Lukas
Re: Policy wrt mail lockfile (section 4.3)
[EMAIL PROTECTED] said:
> Hmm, but why would that cause a problem with mailers/programs that use
> lockfile locking *and* flock/fcntl locking at the same time?
Last time this discussion came up, Bruce found some info in the debian mail
archive related to this. Can't find it now, though. If I remember correctly,
the problem is that flock/fcntl locking on NFS mounted filesystems can cause
complete lockup ( :-) ) of the process.
cheers,
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5166
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Bug#4064: sendmail should recommend deliver, not depend
[EMAIL PROTECTED] said:
> You (Michael Shields) wrote:
...
> > perfectly without deliver. sendmail should only recommend it.
>
> And as a result you can install sendmail without deliver and your
> mail installation won't work at all..
One could introduce another virtual package (e.g., local-mail), have sendmail
depend on this. Both procmail and deliver could provide this package. Sounds
like a bit of an overkill for this problem, though.
> Sendmail should come with mail.local instead of deliver IMHO.
I think that is the simpler and better solution.
Cheers,
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4090: /etc/init.d/kerneld uses grep
Package: modules
Version: 2.0.0-6
The script /etc/init.d/kerneld uses grep - which might not be available. The
problem is that if you put `auto' into /etc/conf.modules, kerneld is started
before any extra mounts are done. So if you have /usr on a separate partition,
/usr/bin/grep (which is where grep lives) is not yet available.
Possible solution: If /etc/init.d/kerneld accepts `auto' as an argument, it is
possible to distinguish if it is called by /etc/init.d/modules or as part of
the links in one of the /etc/rc?.d.
I include a patch which works on my system which does the following:
- /etc/init.d/modules calls /etc/init.d/kerneld with the argument `auto'
instead of `start' if the keyword `auto' is found in /etc/conf.modules.
- /etc/init.d/kerneld interprets `auto' like `start', except that it skips the
test if the keyword `noauto' is present in /etc/conf.modules
Feel free to use the patch if you like my solution and if my patch looks ok to
you.
Cheers,
Lukas
--- modules.origFri Aug 9 16:55:11 1996
+++ modules Fri Aug 9 16:55:33 1996
@@ -34,7 +34,7 @@
do
case "$module" in
auto) [ ${startkerneld} -eq 0 -a -x /sbin/kerneld ] && \
- echo && /etc/init.d/kerneld start && startkerneld=1;
+ echo && /etc/init.d/kerneld auto && startkerneld=1;
continue ;;
noauto) continue ;;
\#*|"") continue ;;
--- kerneld.origFri Aug 9 16:53:26 1996
+++ kerneld Fri Aug 9 16:54:57 1996
@@ -6,7 +6,9 @@
test -f /sbin/kerneld || exit 0
# Check if noauto is set
-grep "^[ ]*noauto" /etc/modules 2>&1 > /dev/null && exit 0
+if [ "$1" != "auto" ]; then
+grep "^[ ]*noauto" /etc/modules 2>&1 > /dev/null && exit 0
+fi
KDOPT=""
@@ -14,7 +16,7 @@
[ -d /lib/modules/`uname -r` ] || exit 0
case "$1" in
- start)
+ start|auto)
#
# is /proc mounted ?
#
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Re: CC's on this mailing list
[EMAIL PROTECTED] said:
> Dale Scheetz <[EMAIL PROTECTED]> writes:
>
> > In fact it would be nice if this message didn't go to you twice, but
...
>
> I may have already said this, but for those interested, gnus will
> generally remove duplicates for you if you want it to. It keeps a
> cache of incoming mail message ID's and can be cofigured to do
The procmail package also allowes you to set up a message-id cache. Have a look
at formail(1) and at the `vacation' example in procmailex(5).
Cheers,
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Bug#4130: Old motif applications don't run
[EMAIL PROTECTED] said:
> [EMAIL PROTECTED] wrote:
> >
> > Thomas> But they're loaded by irisVxm, the graphical front end:
> >
> >Which I don't use ..., I use the xmaple shell script (see below).
>
...
>
> $ strace -f -e trace=open,execve,uselib,fork,_exit -o ~/xmaple.log xmaple
>
> (and immediately exiting once it's come up).
...
I got a strace output similar to yours. My fix to get xmaple up and running
was to create the following symlinks:
/usr/X386 -> X11R5
/usr/X11R5/lib/X11/nls -> ../../../X11R6/lib/X11/nls
Cheers,
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Re: Do we ever retire packages?
> [EMAIL PROTECTED] writes:
> > I have argued before that a2ps and a2gs are effectively replaced by
> > genscript, and that we should remove them. I think a similar case could be
Please don't do that. Personally, I am used to a2ps and I'm a lot more attached
to my habits than to genscript :-). And I don't see why we should retire a
package just because some other package with similar functionality is provided.
Think of the different flavours of vi which are available as debian packages.
But I see the point that lack of interest might be a reason to retire a
package. I can see two cases in which a package would be considered obsolete:
a) The package is obsolete because the functionality (in the low level sense
of, say, the programs provided) is moved into some other package(s). An example
would be what happened to libgr.
b) A package is orphaned for a long time and similar functionality (in the high
level sense, like genscript vs. a2ps) is provided by another package available.
Or the package is considered to be irrelevant for all but a small minority
which doesn't express its interest. Maybe such a package should be moved into
one directory like {unstable,non-free,contrib}/obsolete for a longer period (to
preserve the effort of debianizing the package in case someone wants to take it
up later). Eventually, packages can get purged from the obsolete directories if
nobody expresses interest in maintaining them.
By moving a package into one of the obsolete directories, the distribution
maintaines and/or the developers express their opinion that a given package is
not sufficiently important from their point of view. At the same time, this
acts as a final call for a new maintainer to step forward and express his
interest in keeping the package alive.
Lukas
---
Dr. Lukas Nellen | Email: [EMAIL PROTECTED]
Depto. de Fisica Teorica, IFUNAM |
Apdo. Postal 20-364 | Tel.: +52 5 622 5014 ext. 218
01000 Mexico D.F., MEXICO| Fax: +52 5 622 5015
Re: Changelog issues with (among others) tkdiff 1:3.08-4
Brian Nelson <[EMAIL PROTECTED]> writes: > I really enjoy reading a well-written changelog (and I'm subscribed to > d-d-changes so I tend to read them all), so I'm interested in improving > the quality of ones that aren't quite up-to-par. If there's a consensus > that it's futile or pointless effort, I'll readily stop. What about just contacting the maintainer in private? Why does this have to be on -devel? I think it is nice to have a meaningful changelog, but the human race and Debian will survive some not-quite-up-to-par changelog entries. If this was a separate bug, I would consider it "minor", and thus not worth Cc-ing to -devel. Lukas
Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
Millis Miller <[EMAIL PROTECTED]> writes: > I've already spoken to the upstream author, and he does not see > mwilling to convert to a DFSG license. Probably the only thing I can > do is to make it suitable for the non-free section for the time > being. Can you indicate to me how the license shoudl be changed to > be suitable for the non-free section? I am not for abandoning the non-free section, but I think we should really limit it to software for which no free replacement exists. I am not really sure that "email" satisfies this criterion. Maintaining non-free packages is a hassle, it might be easier to write a free replacement in the time saved by messing around with non-free packages and getting special Debian redistribution permissions. (Remember, there is no build daemon for non-free.) Lukas
Re: but I want the GNU versions of packages
Dan Jacobson <[EMAIL PROTECTED]> writes: > So, how does one find the rest of the packages on one's system that > "Conflicts:" with genuine GNU alternative packages. > > From the tone of your message, I bet there are lots that you fellows > have pre-chosen for us new debian users. So far I have discovered > mawk, and mailx. So, out with it, what are the rest? Why don't you look for them yourself? Some people have more important things to do with their time, even if it is hard to imagine what would be more important than this... Lukas
Re: Work-needing packages report for Jul 11, 2003
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > >wavtools (#155263), orphaned 342 days ago > > Description: WAV play, record, and compression > > Just like sox! Not really... Well, wavtools is a pile of crap, as detailed by Daniel Kobras in #97589. I just filed for its removal. Lukas P.S.: Thanks for the commented junkya^Wlist, Marcelo. I found it very useful. -- Give a man an answer, and he's satisfied today. Teach him to program, and he will be frustrated for the rest of his life.
Package removals and the BTS
Hi all, I was looking for old posts, because I was sure that this must have been discussed before, but I could not find any. When a package removal is requested, there is a bug filed against ftp.debian.org. Following procedures, the maintainer should also know about it (either filing it himself or being contacted about it). However, for other people browsing the BTS, and for orphaned packages, it would be much nicer if there was a bug filed against the package itself, or some remark on bugs.debian.org/package that its removal is requested. There could be several ways to achieve this. - Always file two bugs for removal, one against the package and the other one against ftp.debian.org. This requires no modification in any of the tools involved and could be recommended in the developers' reference. - The BTS is made aware of this, e.g. by having it possible to file a bug against two packages at once. Alternatively, there could be some special pseudo-header for bugs against ftp.debian.org. The second alternative is probably ugly and should be avoided. - The QA pages are made aware of this. This would probably require some standardized subject line like the bugs against wnpp have. One possibility would just be RFR (request for removal), maybe with some tags indicating which distribution would be affected. I like this solution but one disadvantage is that a request for removal of N packages would require filing N bugs. This would make things like #198449 a little more inconvenient. Probably there are other possibilities which I might have missed. The first question is, would other people find this useful? Lukas
Re: LWN subscription for Debian developers
Dan Jacobson <[EMAIL PROTECTED]> writes: > Bdale> ... I announced a group subscription to lwn.net for Debian > Bdale> developers, sponsored by HP... > > Debian may be seen as supporting non-disclosure conditions / > protected proprietary information / trade secrets / etc. whatever. What are you smoking? lwn.net makes articles available after one week, they are only trying to get some money from subscriptions. I don't see any relations to trade secrets and non-disclosure agreements, except if you see all subscription-based services that way. But that would also apply to people subscribing to newspapers, using the local library (certain services only available for residents in public libraries or university affiliates for academic libraries...) and tons of other stuff. > Bdale> If you are a Debian developer and want full LWN access, go to > Bdale> lwn.net and create an account for yourself (no money is > Bdale> required... > > But the Debian developer cannot disclose the information seen with non > Debian developers. I don't think that is true. We cannot set up mirror sites, sure, but if I share this information with some friends, I don't see how this would violate anything. Lukas P.S.: I still would prefer lwn.net to be free. In fact, I would prefer to get my NY Times without paying for it, but unfortunately my wishes do not always come true...
[OT] American version of Harry Potter (Was: Debian should not modify the kernels!)
Russell Coker <[EMAIL PROTECTED]> writes: > Bad analogy. Consider the way that the Harry Potter books have been > modified for the limited vocabulary of the American audience. Ha, the Australians want American kids to read sentences like "Fred and I managed to keep our peckers up somehow." (In the American edition "peckers" was changed to "spirits".) Be aware that the current administration and Fox News might view this as an act of war... Lukas
Bug#430896: and author of
Aquire Precsriptions and Medicaitons right now www.addictartistry.bifreca.com on armchairadulate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Other nethack options (Was: nethack popularity contest - number_pad?)
Colin Watson <[EMAIL PROTECTED]> writes: > It's trivial to reconfigure it in nethack's option screen, just like any > other option. I'm not sure why this one should be special. > > IMO, leave it at the upstream default; you'll surprise nethack players > coming from non-Debian systems less that way. And it's not like nethack > doesn't have a host of other quirks. :) Right, that reminds me of a default option which I always change, namely pickup_types. I don't know what the default is at the moment (in woody it seems to be just $), but IMHO things to be auto-pickuped are "$!?+/=, and some characters might even leave out the spellbooks, though one can at least sell them for decent money. Making nethack options debconf question seems a bit silly to me, but I don't see why we should stick to upstream defaults when they are wrong... Lukas
Re: Other nethack options (Was: nethack popularity contest - number_pad?)
"Steve C. Lamb" <[EMAIL PROTECTED]> writes: > On Sat, Oct 18, 2003 at 08:09:00AM -0400, Lukas Geyer wrote: > > Right, that reminds me of a default option which I always change, > > namely pickup_types. I don't know what the default is at the moment > > (in woody it seems to be just $), but IMHO things to be auto-pickuped > > are "$!?+/=, and some characters might even leave out the spellbooks, > > though one can at least sell them for decent money. Making nethack > > options debconf question seems a bit silly to me, but I don't see why > > we should stick to upstream defaults when they are wrong... > > Define "right". Opinions don't constitute "right". If they did here's > "right": numberpad w/NO auto-pickup except for money. I don't want my packs > full of crap; let me decide what to pick up and what to leave laying on the > ground. I didn't use "right" in the paragraph above (except for the very first word, but I assume you don't want me to define that, it does not have any meaning in that context), so why should I define it? And for your preference of not picking up anything except money, that is very dangerous if monsters pick things up instead. Think of wands of death, wands of digging, scroll of create monster and stuff like that, or amulet of life saving. And if you want to avoid getting burdened or stressed by auto-pickup, then why pick up money? And auto-pickup for money is also annoying when leprechauns are around etc. I find the default of auto-pickup=$ hard to defend. Having auto-pickup turned off is another matter, that would be fine with me, as long as pickup_types is sane. Lukas P.S.: For the humor-impaired: Here are some smileys, feel free to spread them over the text of this email: :) :) :) :)
Re: ITH: gnugo, gnugo-dv
Martin Godisch <[EMAIL PROTECTED]> writes: > I intend to hijack the gnugo package, and to ask for removal of the > gnugo-dv package. Both packages were updated last time around 18 months > ago, there are outstanding bug reports, none with a maintainer's comment, > and I'd like to get the new upstream release into unstable. gnugo-dv was > intended to be the development version of gnugo, but is now older than > gnugo itself. I tried talking to the maintainer two times, without reply. > Please CC me, if you have any objections. I don't have objections, I just found it curious that Brian is actually not MIA, e.g. his latest mail to #171769 is only 6 days old. Brian, I think it would be best just to tell Martin that it is OK to take the package. And Martin, it really looks like he doesn't particularly care about the package, so if you already have a package ready, I don't mind you hijacking it to get it in sarge. And for a development version which is not actively maintained, well... kill it. :) Best regards, Lukas
Re: Other nethack options
Colin Watson <[EMAIL PROTECTED]> writes: > On Sun, Oct 19, 2003 at 11:11:15AM +0200, Adam Borowski wrote: > > hjkl is extremely newbie-unfriendly. > > And? Come on, this is *nethack*. It's the hardest game I know of, bar > none. You have to learn a pile of keystroke commands when you first > start up nethack anyway. Have you tried slashem? Well, it is a nethack variant, so maybe you included it in the statement, but I would actually say it is harder than nethack. :) > Leave the newbie-friendliness to falconseye, which actually stands some > chance of managing that rather than making a tiny concession in the form > of number_pad. I don't like number_pad either, because my main computer is a laptop, but I don't really care either way. > > Arrows require the player to manually turn NumLock on. > > Both things need some action from a first-time user (be it reading the > > help files, or finding out NumLock needs to be on). > > How long is a first-time user going to survive without reading the > keystroke help files anyway? Funnily, I know some newbies/computer illiterates who like to play nethack. And they have probably never read the help file, but had someone explain the keystrokes to them. (Some people seem to get allergic shock reactions when exposed to manuals...) However, I agree with Colin that nethack is not intended to be self-explanatory without the manuals or help files. I like this discussion because I like nethack, and arguing about best options or ascension equipment. (Do you wear amulet of life saving or reflection? A crystal ball to detect the portals on the elemental planes? Do you use cockatrice eggs? ...) However, I also find this discussion utterly insignificant, as nethack is only a game and num_pad is really something that can be changed in a second by the user. It would be slightly more relevant to discuss what compile-time options to turn on, but then I also leave that to the discretion of the maintainer(s). Lukas
Re: Grsec/PaX and Exec-shield
Peter Busser <[EMAIL PROTECTED]> writes: > > I volunteered to make a package for exec-shield because it meets > > the Debian criteria, I have time to do it, and it interests me. > > PaX would take much more time so I can't do it. > > You cannot do it or you don't want to do it? In fact, anyone can do > it Russell, I'm pretty sure even you can do it: > > apt-get install kernel-source-2.4.22 > cd /usr/src > tar xvfj kernel-source-2.4.22 > cd kernel-source-2.4.22 > wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch > patch -p1 < pax-linux-2.4.22-200310051430.patch > > And now you can make menuconfig etc. Now, that wasn't too difficult, > right? If this is your idea of maintaining a package, I am glad that you are not a Debian developer. I hope you take better care in putting together Adamantix, otherwise I pity the poor souls who use it and believe it is "Trusted"... Lukas P.S.: Why does everyone attack Russell these days? Seems to me like the field of Linux security is populated by lots of trolls.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
er packages is no excuse to stop it from working for the kernel. > And as I've seen in some other message, quoting kernel-package generated > postinst, the current packages _do_ suffer of the same problem. Only if you update a new Debian revision of the same kernel version. Furthermore, you can always tweak EXTRAVERSION to make the name unique. > You know, I could have RTFMed inmediately and respond I know what System.map > is, but I don't see why this insignificant argument should actualy waste my > time in reading docs for the only purpose of proving I can read docs. You are making it worse with every post. So you think reading docs for your own packages is wasting time? Nice. OK, the rest of your message is more ignorance and arrogance, I will stop it here. Do you actually know what the project expects of its package maintainers? You seem to have a rather shallow understanding of all the issues involved with kernel packaging, and I strongly object to this package being uploaded to sid. Experimental would be fine with me for people to test it. Lukas
Re: Latest version of fvwm packaged
> Manoj Srivastava <[EMAIL PROTECTED]> [2003-11-11 09:58]: > > Hi, > > The development branch of fvwm is nearing a stable release, > and has had a huge number of new features. The maintainer has been > very reluctant to package this branch, even in a people.debian.org > repository, so I decided to package FVWM 2.5.8 for myself; and I have > decided to share this with others as well. The packages are > lintian clean, and can be found at: > > deb http://people.debian.org/~srivasta/ packages/ > deb-src http://people.debian.org/~srivasta/ packages/source/ > >There have been significant new features in the 2.5.X series, > and just the GNOME 2 compatibility should be enough to require this > in Sarge. > >These packages were configured as follows (I see no reason not > to allow rplay and xrender compatibility in fvwm). As you can see > below, I have included as many of the features as I could. > can I simply update to the new packages by inserting the deb-statements into my /etc/apt/sources.list ? I'm running unstable. Thanks for any help. wbr, Lukas -- Lukas Ruf | Wanna know anything about raw | <http://www.lpr.ch> | IP? <http://www.rawip.org> |
Re: ftpmaster accepts packages that have been rejected a few days ago
"Luca - De Whiskey's - De Vitis" <[EMAIL PROTECTED]> writes: > it was probably proven that oxygen was > better thatn flogiston (I don't really know what both are) He, this would be a great signature... (Luca, oxygen is the quite essential stuff you breathe, constitutes about 20% of the air around us...) > If you are in charge of any position in a community you inevitably > get a political role. You can take popular or unpopular decision, > but in neither case you can behave rudely or cut disuccion short or > take any mail lightly. You are discussing with people from other > countries with different language and different culture. You _must_ > take time and give your best to explaint the reason of any choice > you made because it's not obvious the the recipient might > understand. _THIS_ is the problem. No, in this particular case this was not at all the problem. The original complaint explicitly stated that James' email was very polite and also stated the reason for the rejection. In most of the other conflicts surrounding James, it was not rudeness but lack of communication which was mostly criticized. In the meantime, the NM process has improved significantly, people are approved by the DAM and, as I understand it, the waiting applicants got quite a lot of feedback now. In fact, in the last DPL election I voted for Branden, and one of the major reasons was the state of the NM process. I am pleasantly surprised that Martin Michlmayr managed to improve the situation without creating big conflicts, thanks to both him and James Troup. > Do we want to talk about keyring? What is the current state there? Do you have any evidence of James' rudeness in discussions about the keyring (I haven't) or is this all just about a gut feeling that you don't like him? If you think that James is not able to fulfill all his duties, it is up to us (or the DPL) to propose others to help or replace him. However, I do not see much basis in fact for your allegations of rudeness, so please either substantiate it or stop spreading such accusations. Lukas
Re: Intel f90 compiler for Debian.
alberto <[EMAIL PROTECTED]> writes: > Intel has a powerful f90 compiler, the only one freely available on > the market, as far as I know, which runs under Linux. It is an > extremely important tool for those who run numerical simulations for > scientific purposes. > http://www.intel.com/software/products/compilers/downloads/forlin.htm > > Unfortunately for Debian users, Intel distribute the compiler as an > rpm archive, and the install script is accordingly written. > > I have succesfully and easily installed the compiler on my Debian > Woody in a kind of a dirty way and I've put a brief HOWTO on my web > site: > http://www.nordita.dk/~bigazzi/varie/Intel_F90_on_a_Debian_GNU_system > .html > > I'm sure, though, that the install script, wich you find on the same > page of mine, can be just adapted to Debian and made available to > Intel for them to include Debian as a supported platform for their > compiler. > > Notice that, in the scientific community, the availability of such a > compiler for Debian, will greatly benefit our favorite distro. > > Does anyone want to take the task of rewriting the script for Debian? There are more problems to this than the rpm format. As I understand their website, Intel provides a binary-only version of this compiler, and the license agreement prohibits disassembly and reverse engineering. Furthermore, it is available only for the i386 architecture. The non-freeness prevents it from becoming part of Debian. The free software community would profit much more from making gcc's Fortran compiler compatible with the Fortran 95 standard. For those interested, the TODO list is at http://gcc.gnu.org/fortran/todo.html Of course, if somebody (maybe you?) sends Intel some patches to make their compiler work on Debian systems, that can not be bad. As an aside, I don't quite understand why Fortran is still so popular in the numerical mathematics community... :) Lukas
Re: Intel f90 compiler for Debian.
Matthias Urlichs <[EMAIL PROTECTED]> writes: > Hi, Lukas Geyer wrote: > > > As an > > aside, I don't quite understand why Fortran is still so popular in the > > numerical mathematics community... :) > > There still are a lot of Fortran libraries which people are used to, > and they have been heavily optimized over the years. > > The sad trutz is also that historically, since C is a language where any > pointer can point anywhere, some optimizations which are rather obvious in > Fortran compilers are difficult if not impossible in C. This has changed > somewhat (C99), but ... I thought that all or most of these libraries had C bindings in the meantime. And for optimization purposes, it might not be as easy to do in C, but there have always been options like -fstrict-aliasing and such. However, that is probably not so much an issue if the C functions are just wrappers for the Fortran library. People who want the last percent in optimization would probably not use gcc anyway, but some sort of vendor-optimized compiler for the respective architecture they are using. Lukas
Re: DAM approval wait time?
Jim Lynch <[EMAIL PROTECTED]> writes: > On Thu, 28 Nov 2002 11:58:38 +1100 > Andrew Lau <[EMAIL PROTECTED]> wrote: > > I was referring to your own post to my "DAM approval wait time" > > outburst. Before this email, I had made some attempt at contributing > > to the discussion with two posts in the little free time I have. > > Unless you think it's actually useful, perhaps you shouldn't start > a thread you know you can't participate in. If you're not even willing > to read from it, I continue to question your maturity. If he thinks there is an urgent matter, and then he drowns in exam stress, why is that a sign of immaturity? The thread will only survive if other people are interested enough to keep it going, and it may have important results no matter whether the original poster participates in it or not. > Funny how you don't mention the good > things I have said about your potential. I don't think you read the whole > posts I make, just as much as I don't believe you don't read the replies > to posts made to your original post about Gentoo. I fail to see why he should pick up the good things in your posts. Overall they are arrogant and belittling, and throwing in some nice patronizing sugar is just a standard trick of rhetoric. > > You have no right to judge me > > Actually, all developers gained that right when you submitted your app. > If you didn't want to be subjected to scrutiny, you shouldn't have > applied. It's as simple as that. If you think you're not in good company > with you not being approved yet, GO LOOK AT THE NEW MAINT LIST; you will > find Richard M. Stallman's app. Fact is, you're actually FURTHER than him > in the new maint process; he's stuck for some reason. > > In fact, you seem to be in... your AM has approved you... Of course new maintainers are subject to scrutiny but what you are doing here is some kind of public humiliation, that is completely different. Funny that you criticized Andrew Suffield for insulting other people on the list. Should I start publicly pounding on you because you have an open bug of severity "important" on which you have not commented since April? I think that would be bad style, like mentioning that the last 3 uploads of said package were NMUs... Do you really want _that_ kind of scrutiny on debian-devel? So please, move this to private mail or, even better, to /dev/null. Lukas P.S.: I really mean that you should orphan or RFA packages for which you have no time/interest anymore.
Re: plagiarism of reiserfs by Debian
Florian Weimer <[EMAIL PROTECTED]> writes: > Hans Reiser <[EMAIL PROTECTED]> writes: > > > You'll note that ReiserFS anticipated the GNU GPL V3 by including > > clauses that forbid removal of credits in its license, and for a long > > time I have been telling Stallman that he needs to get V3 of the GPL > > out the door. > > Oh, I think it's natural to assume that these clauses are superfluous > because the GPL explicitly states that a distributor "may not impose > any further restrictions on the recipients' exercise of the rights > granted herein". If these clauses were of any legal relevance, your > software wouldn't be redistributable at all. > > Just don't use the GPL for your software if you don't like it, but > don't complain if anyone misunderstands your homemade license > mishmash. Well, usually we also try to use common sense, syllogism and rocket science to find out what the author's intent was. Fortunately Hans Reiser made his intent clear by posting this statement to debian-devel. The only consequence I can see is to move reiserfsprogs to non-free. For those who have not followed the discussion and such, the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Cheers, Lukas P.S.: Cc'ed to debian-legal, which is probably the better place to discuss this. -- Give a man an answer, and he's satisfied today. Teach him to program, and he will be frustrated for the rest of his life.
Re: Jumped up developers [Re: stop the "manage with debconf" madness]
"Matt Ryan" <[EMAIL PROTECTED]> writes: > Unfortunately your choice is rather weak and doesn't back up your > argument so I feel obliged to continue the thread a bit further > (plus its giving my brain some exercise). > > [Oh yeah, the quotes are from some developer who's name I've > promised not to use in my emails] Is that necessary? > > ...and telling Ben Collins to "take a Valium" after what appeared > > to be a pretty even-handed message > > Unless he's a lunatic who has to take valium to keep some control I > don't see what's wrong with that. Many people would use a similar > analogy to indicate to someone they need to crank it down a notch or > two. It is insulting nonetheless. Certainly there are stronger insults, but that Valium thing was not necessary. Furthermore, you have not engaged in serious discussion about what the issue was. Hans Reiser accused Debian as a whole of plagiarism and asked whether we support some mysterious "de-crediting of Stallman and KDE" by RedHat, whatever that is supposed to mean. As of yet, he has not even explicitly stated what the exact license violation is, so we started guessing. Most probably he means removal of 24 lines of listing of sponsors, advertising of paid support etc. from the output of mkreiserfs and similar tools. In my opinion this is not compatible with GPLv2 (which is claimed to be the license of reiserfs), and thus the whole Reiser rant qualifies as trolling, no matter whether he is an upstream author or not. Ben Collins actually advised him on the recommended course of action, i.e. filing a bug/contacting the maintainer. > There are no ranks in Debian, no one gets paid (AFAIK) and so no > view is more or less valid than another. I think a small minority of > developers can easily get identified as pushing their own agendas if > we did an informal poll on this list. Those are the one's I have > issue with and will continue to say so. Most likely a strong feeling > to respond to this message will promote you to the top of the list > 8-) I do not count myself as member of the cabal or an important member of the project, maintaining only two chess engines. However, the debconf issue has been discussed in the past, and it seems that some informal consensus involved that debconf is not to be used as a registry. There were some good arguments for that point of view, and a point of view is not much worth if it is not backed up by arguments. The points which stick from your emails are the insults, and that may be due to my superficial reading, but it seems that others have the same impression. (Matt Zimmerman did not even mention the point about "anal retentives"...) So, please calm down and discuss technical merits of debconf usage, not personal motivations of some imagined developer cabal, Lukas
Request for gnuchess packaging change
Hi, after unsuccessful attempts to contact the maintainer of gnuchess, Martin Mitchell (he did not answer at all to my emails), I would like to propose a change to the packaging of gnuchess. Andreas Tille did at least do an NMU to update to version 5.03 which fixes several outstanding bugs. One remaining bug is that gnuchess does not use its opening book. This has in the meantime been separated from the upstream source, due to its enormous size. I propose that Debian follows this step and splits gnuchess into gnuchess and gnuchess-book. The book in the current version is completely architecture-independent, so this separation makes sense as it only has to be built on one architecture for all. Furthermore, the book is not bound to change with every new upstream version of gnuchess, so that people will not have to download it every time the code changes. I have put up sample source packages under http://www.mathematik.uni-dortmund.de/lsix/geyer/gnuchess/debian and would be glad about any comments. The package gnuchess will only install gnuchess without any opening book (this might be changed to provide some small default opening book) and the package gnuchess-book builds and installs the book. (The build takes approximately one hour on my iBook with 500MHz PPC, gnuchess compiled just with -O2.) I am not an expert on Debian packets, but I have used debhelper before, and I started from the package by Andreas Tille. My interest in gnuchess comes from the fact that I am co-maintaining the upstream gnuchess release. It seems to me that the maintainer has no real interest in the package and before the NMU of Andreas Tille it was completely broken for several architectures. I would be willing to provide Debian packages but I am not a member of the Debian project (yet). Best regards, Lukas P.S.: Please Cc me on replies, I am not subscribed to this list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian ova instance generator
Hi, I've seen that you stop dbus via invoke-rc.d because it's started from its postinst script. There's a way to prevent the starting of services so you don't need to stop it: Just install https://github.com/grml/grml-policyrcd into the chroot, it will make "invoke-rc.d start" a NOP if run inside a chroot. Regards, Lukas On Sun, Oct 6, 2013 at 3:54 PM, wrote: > Dear fellows, > > This is a simple Makefile which generates ova[1] of customized debian, > inpired by an ova build script of sagemath[2], and a guide from > archlinux[5]. > > It is a by-product of AireLinux[3], a customized Debian for > astrophysics. > > It basically creates a hdd image with debian debootstrapped and > additional packages installed, and then calls virtualbox to generate the > ova from the hdd image. > > Why not automated d-i in a virtual machine(vm)? vm overhead can be > avoided using kpartx and chroot, resulting in faster image > build. Furthermore, commands in chroot can be controled from the > building host (e.g. the file dependences by Makefile, while d-i has > another command context inside virtual machine. > > Why not Debian Live[4]? While strong in creating iso and squashfs > automagically, it is not mature in creating a plain simple hdd image > (not to mention a grub2 powered hdd image). > > Future versions are tracked in the repo[6]. > > Enjoy! > Benda > > Footnotes: > > 1. http://en.wikipedia.org/wiki/Open_Virtualization_Format > 2. http://trac.sagemath.org/ticket/11330 > 3. http://www.airelinux.org > 4. http://live.debian.net > 5. https://wiki.archlinux.org/index.php/Creating_Arch_Linux_disk_image > 6. https://sourceforge.net/p/aire/code/ci/master/tree/ > >
Re: RFH: dropbear initramfs support
Hi Gerrit, first I want to say thank you for maintaining dropbear and the cryptsetup patches. The package works well and reliable for me on a number of hosts. However, it's a bit rough around the edges and didn't see any improvements for some time so I started to update it locally by myself. I created a man page for dropbearconvert, added a watch file, get-orig-source target, converted the package to Debhelper 9, enabled the compilation of dropbear scp, which is a long wanted feature in the Debian BTS and did some minor cleanup. This was around summer 2013, I lost interest after some time because I filed some bug reports (#720987, #692611, #715534) against packages you maintain (dropbear, git, dash) and since I saw no reaction I had a good excuse for myself to settle my work. I believe that the initramfs patches should be eventually moved from dropbear to cryptsetup-dropbear (and probably maintained in the cryptsetup source package) because they only utilize dropbear to have a SSH daemon running in the initramfs but they aren't needed to run dropbear itself. Or to put it another way: Just because you install dropbear doesn't mean you want to run it in the initramfs and decrypt your LUKS devices with it. Admittedly, that's probably the number one use case on Debian (as opposed to an embedded system like OpenWRT where the tininess is a also a compelling argument). I also believe that echo'ing your passphrase to /lib/cryptsetup/passfifo is a thing you don't want to do on a regular basis, instead a pass prompt like it appears when booting with an encrypted drive would be nice. All in all I believe that the "I want to unlock my drives remotely" problem actually needs a major redesign to, first, address some of the bugs in the BTS for dropbear and, second, be more user friendly and configurable. I fully understand that you probably have no interested in such a thing since you wouldn't even use it. I would be interested but I'm not even a Debian developer and a good solution would touch some packages (initramfs-tools, dropbear, cryptsetup at least) and has potential for great failure. Regards, Lukas On Tue, Jan 14, 2014 at 2:24 PM, Gerrit Pape wrote: > Hi, in 2008 initramfs support was contributed to the dropbear package. > Unfortunately the contributor seems to be no longer active and quite > some bug reports concerning this feature have been collected in the BTS. > > Since I don't use ssh support in initrams, I hereby look for helpers or > even a co-maintainer who take care of the bug reports and further > development of this feature. > > A package git repository is available through > http://smarden.org/git/dropbear.git/ > and I'd be happy to receive patches through the BTS. > > Thanks, Gerrit. > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/20140114132404.7481.qm...@30c3a586213ae7.315fe32.mid.smarden.org > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacb1aev2ogwmsojj4ldwwdq9cqmp3uarxzphfamov7p9ryp...@mail.gmail.com
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On Wed, Feb 5, 2014 at 12:08 AM, Charles Plessy wrote: > The 3.0 (native) format is useful when packaging a work that is developped and > distributed in a Git repository. Please leave us this possibility. Can you elaborate a bit? From my understanding of your description I'd consider your (git) workflow flawed since your generated source package has the upstream tar ball and all your Debian specific changes merged into it. git-buildpackage helps you to separate the upstream sources and the Debian folder with its patches. This way it's possible to maintain a package conveniently in git but also produce 3.0 (quilt) packages where even if one doesn't use git (or the git repo vanishes) is still possible to see what modifications has been done to the source compared to the upstream release. Regards, Lukas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacb1aeuzsoc9oedbouddqqz7nzahihcee3uuxmepprg1fvd...@mail.gmail.com
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 19.06.23 um 21:05 schrieb Luca Boccassi: On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote: On 2023-06-19 14:37, Luca Boccassi wrote: The advantage of doing that is that it's what Ubuntu does IIRC, so there will be extra pooling&sharing of resources to maintain those setups, and the road should already be paved for it. I am not sure if I have seen this play out in practice[1]. Ubuntu^WCanonical has been doing its own development in this space as well with netplan. Ubuntu will continue to do its own fixes to glue things together. Kind regards Philipp Kern [1] With notable exceptions like doko maintaining the toolchain - and I'm sure I'm not crediting everyone. But that's also explicit package maintainership. I've been working for a long time with many Canonical engineers, happily and fruitfully, to the benefit of both Debian and Ubuntu, so my experience is quite different. This includes the developers working on src:systemd. As the maintainer of Netplan and (soon to be [1]) DD, I have a strong interest in this topic. I agree, going with systemd-networkd on servers and NetworkManager on desktops, the pooling & sharing of resources between Debian and Ubuntu will be a win-win situation! Netplan allows seeding and configuration for both of those tools and is already being used in Debian cloud-images for this purpose. All while keeping full flexibility to use the underlying tool's native config files in addition to Netplan's YAML. E.g. /etc/netplan/*.yaml will generate configuration in /run/systemd/network/... and/or /run/NetworkManager/system-connections/... while /etc/systemd/network/... and /etc/NetworkManager/system-connections/... are still there for native or override configurations. I think we shaped up the Netplan package in Debian [2] pretty nicely in the recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not least, at the Netplan project we're happy to help out with any rough edges that Debian might run into, as we might have already seen those in Ubuntu and of course we're also open for contributions! Cheers, Lukas [1] https://nm.debian.org/process/1180/ [2] https://tracker.debian.org/pkg/netplan.io
Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
Am 19.06.23 um 20:01 schrieb Simon McVittie:
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
Why does isc-dhcp-client have priority:important to begin with?
I don't think users care so much about a dhcp client but rather a
network configuration system
The priority question isn't the important one. The real question is:
What network configuration system should users end up with (by
default)?
Indeed, this is the correct question to ask!
Yes, whatever DHCP client ifupdown would prefer to use, that seems
like an implementation detail of ifupdown: it should pull it in via
an appropriate level of dependency, and that's orthogonal to whether a
particular class of installation has its networking managed by ifupdown,
NetworkManager, systemd-networkd or something else by default.
ACK.
At the moment I believe the status quo for d-i is that networking is
managed by NetworkManager if a desktop task happens to have pulled it in,
or ifupdown otherwise? And that seems reasonable (although I personally
prefer to set up systemd-networkd on servers).
Of our desktop tasks, all except possibly LXDE and LXQT pull in
NetworkManager via Recommends or stronger, which seems right. LXDE
and LXQT might pull in connman as a higher preference than NM, via an
alternative dependency that includes connman-gtk or cmst: it's not
immediately obvious to me what actually happens, and I don't have a
recent installation of either one to look at right now.
As the maintainer of Netplan, I have a strong interest in this topic. I agree with
bluca, going with systemd-networkd on servers and NetworkManager on desktops, the
pooling & sharing of resources between Debian and Ubuntu will be a win-win
situation! I'd propose to use Netplan.io on top of that, to seed the configuration
for either network configuration tool in a common way, which should make life
easier for the d-i team.
Netplan allows to configure both of those tools and is already being used
across Ubuntu and in Debian cloud-images for this purpose. All while keeping
full flexibility to use the underlying tool's native config files, should
Netplan's simple YAML settings not be enough for a given complex usecase. E.g.
/etc/netplan/*.yaml will generate configuration in /run/systemd/network/...
and/or /run/NetworkManager/system-connections/... while
/etc/systemd/network/... and /etc/NetworkManager/system-connections/... are
still there for native (or override) configurations!
I think we shaped up the Netplan package in Debian [2] pretty nicely in the
recent 1-2 years, e.g. having extensive autopkgtest coverage. Last but not
least, at the Netplan project we're happy to help out with any rough edges that
Debian might run into, as we might have already seen those in Ubuntu and of
course we're also open for contributions!
The other possible reason to have a DHCP client is for recovery, but
most bootable Debian systems will have busybox (via Recommends from
initramfs-tools-core), and that has a small DHCP client included anyway.
I also think that installing both ifupdown and NetworkManager on
desktop environments is worse than only NM.
ifupdown should be fairly harmless when not configured to manage any
non-loopback interfaces (which is what d-i does when NM is installed),
but I agree that it seems better not to have it if it's not needed.
ifupdown is mostly in "life support" mode, as stated by andrewsh at Debian
Reunion Hamburg [2].
ifupdown2 is implemented in Python and has some backing by CumulusNetworks.
ifupdown-ng has only ever seen a single upload in Debian, but was deemed to be
the best ifupdown implementation currently.
IMHO ifupdown{2,-ng} is the "old world" and when doing such change we should rather go the systemd-networkd
(server) + NetworkManager (desktop) path, potentially in combination with Netplan, in order to switch to a more modern
and future proof network configuration tool, that also supports advanced features such as WiFi regulatory domain
settings or SR-IOV network virtualization, to cover today's usecases. We'd also get nice CLI tools to control this
stack for free, such as "networkctl", "nmcli" or "netplan status".
Cheers,
Lukas
[1] https://tracker.debian.org/pkg/netplan.io
[2]
https://hamburg-2023.mini.debconf.org/talks/5-network-configuration-on-debian-systems/
Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)
On Thu, Jun 22, 2023 at 01:39:02PM +0800, Paul Wise wrote: > On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > > > Netplan allows to configure both of those tools and is already being > > used across Ubuntu and in Debian cloud-images for this purpose. All > > while keeping full flexibility to use the underlying tool's native > > config files, should Netplan's simple YAML settings not be enough for > > a given complex usecase. > > Is Netplan able to parse an existing native config for each of the > tools and then output either Netplan configs or native configs for each > of the other network config tools? For example could you use Netplan to > auto-migrate from ifupdown to systemd-networkd or NetworkManager etc? Netplan is implemented as a systemd-generator [1] and primarily intended to be used as a one-directional genreator from Netplan YAML -> native config. We've been making some moves in adding bidirectional parsing capabilities for NetworkManager's keyfiles, though, e.g.: NM keyfile <-> Netplan YAML And there's also an ifupdown migration prototype, but that is pretty limited, didn't see much love in the recent years and might not live up to expectations, e.g.: ENABLE_TEST_COMMANDS=1 netplan migrate Cheers, Lukas [1] https://manpages.debian.org/testing/systemd/systemd.generator.7.en.html signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jul 10, 2023 at 09:39:52AM -0400, nick black wrote: > Helmut Grohne left as an exercise for the reader: > > And yeah, please work on changing that ifupdown by default. I'm faced > > with having to uninstall it from more and more systems. In case, you > > do a straw poll, I vote for systemd-networkd, which happens to be > > installed by default. Would there be any volunteers doing the d-i > > integration? > > I'd be interested in taking this on, though I wouldn't want to > step on anyone's toes, so if someone with a feeling of ownership > would rather take it, please let yourself be known. I'd want > clarity as to whose approval I need to merge code (and their > buy-in to the effort overall) before starting. > > I've messed with d-i and systemd-networkd both a good bit, and > like you (I assume) believe systemd-networkd to be the best > option at this time, and also moving forward. Having touched both of those projects sounds like a good starting point! I agree we should be going with systemd-networkd for minimal/server setups. It is slim and comes pre-included with systemd, so is already part of many Debian installations. From the discussions above, it seems that NetworkManager is relevant as well, though, and is being pulled in whenever a desktop task is installed (in addition to ifupdown or future systemd-networkd). Therefore, I'd love to see Netplan to be used in combination with this! It's a clean, declarative configuration language not specifically tied to systemd-networkd as an implementation. So it could also be used on desktop installs where NetworkManager is important, for example to handle roaming between varying WiFi networks. It would also allow for d-i to install a single, common default network configuration, independently of the underlying daemon. The Netplan + systemd-networkd stack is already being used in Bookworm cloud-images [1]. So going with that in d-i as well, would have the additonal benefit of common network configuration accorss different variants. Cheers, Lukas [1] https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/ signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote: > >>>>> "Lukas" == Lukas Märdian writes: > > > Lukas> Therefore, I'd love to see Netplan to be used in combination > Lukas> with this! It's a clean, declarative configuration language > Lukas> not specifically tied to systemd-networkd as an > Lukas> implementation. So it could also be used on desktop installs > Lukas> where NetworkManager is important, for example to handle > Lukas> roaming between varying WiFi networks. It would also allow > Lukas> for d-i to install a single, common default network > Lukas> configuration, independently of the underlying daemon. > > I currently use netplan.io when I need to interact with cloud-init and > network configs. > > I think netplan is a great tool when > > 1) You need to interact with cloud-init > > or > > 2) When a human is generating systemd-networkd config or NetworkManager > config. > systemd-network splits its config across multiple files in a way that's > really nice when you have some provisioning system generating it, but > isn't so nice when you are wanting to look at the config all in one > place as a human. > NetworkManager's config is a bit fiddly to generate by hand, much less > so than netplan.io. I agree, cloud-init is a strong use-case. And another one is the ability to support systemd-networkd and NetworkManager with a common configuration file, which can be amended by a human or another package (like NetworkManager) shipping a drop-in config, to amend which networking daemon is configured. Let me give a specific example below... > However, there are some significant disadvantages to netplan: > > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. It is an extra layer, but this also brings the benefit of being compatible with networkd and NetworkManager. Let me give an example: D-i could install a basic Netplan config to "run dhcp on my ethernet", e.g. /etc/netplan/90-default.yaml: ``` network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ``` This would generate systemd-networkd (Netplan's default backend) configuration at boot time in /run/systemd/network/10-netplan-eth0.network Now, if a desktop task is pulling in the network-manager package, that could ship a /usr/lib/netplan/00-network-manager-all.yaml Netplan drop-in config: ``` network: version: 2 renderer: NetworkManager ``` Which would change the default setup to now generate NetworkManager config in /run/NetworkManager/system-connections/netplan-eth0.nmconnection instead. This is without any changes to the installation system or the file shipped in /etc/netplan/90-default.yaml. Of course, users can still override that decision (even on the interface level) by specifying the "renderer" setting explicitly in some /etc/netplan/ config. > 2) It's a layer that you cannot ignore when editing the config. Netplan > is one way. It takes in config in its format and spews out either > NetworkManager config or systemd-networkd config. You can generate > extra config on top of what netplan does, but in my experience if you > want to edit the config that netplan controls, you need to either do it > through netplan or remove netplan and generate those config chunks by > hand (possibly after looking at how netplan did it). Yes, you can easily define your own /etc/systemd/network/* config besides any /etc/netplan/* config that generates files in /run/systemd/network. Netplan tries to always play nice with any interfaces configured outside of /etc/netplan/, for example manually configured Open vSwitch bridges. In fact, you can also easily amend or override systemd-networkd configuration generated by Netplan, using systemd's usual override-config approach. Picking up the example above, you could create a file in: /etc/systemd/network/10-netplan-eth0.network.d/override.conf Which can add or change anything configured by Netplan in: /run/systemd/network/10-netplan-eth0.network > It's possible there are some netplan modes I missed and some other ways > of doing things. It's also possible netplan has evolved since I looked > at it. Netplan has evolved a lot since its early days in 2016 and there are many more possiblities, e.g. a libnetplan.so for deeper integration in other tools (e.g. to validate Netplan YAML configs from a 3rd party tool). > In the non-wifi case I think d-i's networking is too simple to justify > netplan. > A simple .network unit for systemd-networ
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 01:33:02PM +0200, Andrey Rakhmatullin wrote: > On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > > From the discussions above, it seems that NetworkManager is relevant as > > > well, > > > though, and is being pulled in whenever a desktop task is installed (in > > > addition to ifupdown or future systemd-networkd). > > > > What happens at the moment is: > > > > - if the tasks install NetworkManager, then d-i translates the install-time > > networking into NetworkManager configuration, together with essentially > > blank ifupdown configuration that makes ifupdown mostly a no-op (it > > might still try to bring up `lo`, but systemd brings that up as an "API" > > interface anyway, and probably so does NM if systemd didn't already) > Something also enables the ifupdown plugin in NM (and does something about > managed=true/false? I'm not familiar with this integration). If we remove > ifupdown this should be changed I think. We could save that translation step in d-i when using Netplan. We'd just need the network-manager package ship a /usr/lib/netplan/00-network-manager-all.yaml ``` network: version: 2 renderer: NetworkManager ``` > > - otherwise, d-i translates the install-time networking into ifupdown > > configuration > > > > Doing that, but with s/ifupdown/systemd-networkd/ throughout, makes > > sense to me. Is that what others in this thread had in mind? > > > > The practical result would be NM on desktop/laptop class systems, and > > systemd-networkd on server/embedded systems, which as it happens is what > > I'm already doing on my own machines. > I also wonder how complicated would it be to get WiFi configured in the > GUI-less setup. Currently it's easy if NM was installed for some reason > (with nmtui) and not easy otherwise. That would lead to a situation where users would need to differentiate what system they are on when doing their network configuration: Debian Cloud (Netplan) vs Desktop (NetworkManager) vs Server (systemd-networkd) All using different formats and locations to store their configuration. On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > Therefore, I'd love to see Netplan to be used in combination with this! > > It's a clean, declarative configuration language not specifically tied to > > systemd-networkd as an implementation. So it could also be used on desktop > > installs where NetworkManager is important, for example to handle roaming > > between varying WiFi networks. > > One of the major reasons why the desktop tasks use NetworkManager > is that it's well-integrated in desktop environments (particularly > our default GNOME desktop, but also others like KDE Plasma). If GNOME > controls NetworkManager directly, using its client library and D-Bus > API, is that going to conflict/collide with Netplan also trying to > control/configure NetworkManager? If I'm understanding Netplan correctly, > it treats NM and networkd configuration as essentially "write-only" > (like a compiler that inputs its own syntax and outputs NM or networkd > syntax), which doesn't seem compatible with GNOME going behind its back? > > It seems unlikely that GNOME upstream is going to switch to using > a Netplan API and having it as a dependency unless it has extremely > compelling benefits, because they are happy with their design choice to > have tight integration with NetworkManager; and the Debian GNOME team > already does not have the resources to maintain GNOME in Debian as well > as we would like to, so I think I can safely say we aren't going to be > able to maintain a patch for GNOME to use Netplan APIs downstream. I'm > sure other major desktops like KDE Plasma are in the same situation. I fully agree on NetworkManager being very well integrated in desktop environments and I don't want to force the Netplan API onto anybody. It isn't needed. Netplan plays nicely side-by-side with NetworkManager. When Netplan's default "renderer" is set to be "NetworkManager" (see config snippet above, which could be shipped by the network-manager package), Netplan would just feed NM connection profiles into /run/NetworkManager/, while NM is still free to choose which connection profile to use, or add additional profiles in /etc/NetworkManager/ as usual. (We're also working on a bidirectional Netplan-NetworkManager integration, that allows NM to feed back it's configuration into Netplan YAML format. It is a small patch for NetworkManager and is purely optional.) -- Lukas signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 14, 2023 at 09:33:12AM -0400, Jeremy BĂcha wrote: > On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > > (We're also working on a bidirectional Netplan-NetworkManager integration, > > that allows NM to feed back it's configuration into Netplan YAML format. It > > is > > a small patch for NetworkManager and is purely optional.) > > Does that already exist in Ubuntu 23.10 "Mantic"? Yes, we enabled it in Ubuntu just recently. The code can be found here: https://git.launchpad.net/network-manager/tree/debian/patches/netplan Cheers, Lukas signature.asc Description: PGP signature
Re: Bug#995189: RFH: isc-dhcp
Hi,
Thank you for considering netplan as the distro default in Debian!
I am the upstream netplan maintainer (and downstream maintainer of the
netplan.io package in Ubuntu) and would be happy to help with
implementing this switch to netplan. Also, I do have a few thoughts to
share wrt. this discussion.
Are you saying "everything breaks" as in:
A) the change is not applied (correctly) in the way that it would be if
the system was rebooted, or
B) the change is applied, but the human made a mistake in the config and
the change breaks things, or
C) B + the human gets cut off from e.g. SSH due to the error?
I would say (generally) that A is a bug, B is inherent to any tooling
applying a human's instructions, and C can be addressed by a rollback
function.
`netplan try` covers C (and thus also B).
`netplan apply` (and thus `netplan try`) have a caveat that they don't
remove virtual devices that are no longer described in the config.
This feels like an example of A, though it's arguable how much it
matters.
B & C: ACK
Regarding A: We have just recently landed a change in upstream netplan
that allows to mitigate this exact problem, by passing the previous
state. netplan can then calculate the delta of virtual interfaces and
cleanup after itself (in some cases this can and is done automatically):
https://github.com/canonical/netplan/pull/231
I am saying: remove the IP address from an interface, move it to a VLAN
instead. You'll get a duplicate IP.
This sounds like another bug, that should be addressable in a similar
way to the fix mentioned above.
ifupdown2
is smart and will converge to the new configuration. Network Manager can
restart and minimize impact. AFAIK, systemd-networkd is as dumb as
ifupdown and does not know how to converge.
What does converge mean in this context? Is something needing to apply
parts of the changes iteratively to arrive at the desired state?
It makes a diff between the current system state and the desired state
and applies actions to move to this state. The current system state
could be from a previous application of the tool or from manual action
from the operator, it does not matter (this is a second advantage of
such a tool). The above situation is handled perfectly.
My point is that ifupdown2 was a possible successor to ifupdown but was
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
Am I understanding correctly that ifupdown2 is an alternative to
systemd-networkd and NetworkManager (as opposed to netplan, which is a
layer on top of them)?
Yes.
Well.. netplan is not actually written in Python. But is primarily
implemented in C, consisting of the libnetplan library that contains all
the parsing and YAML progressing logic and a small "generate" binary
that is usually executed during bootup as a systemd-generator [0] to
prepare any systemd-networkd / NetworkManager / OVS / SR-IOV
configuration that might be needed.
Only the interactive and user facing CLI is implemented in Python,
calling into libnetplan and executing the 'generate' binary if need be.
I'm not a Debian Developer, so it's not my call, but still I'd like to
provide a few more points as to why netplan should be the distro default
in Debian:
* Netplan is under active development, providing several new releases
per year and supported by Canonical.
* Licensed under GPL v3.0 without any CLA.
* Implemented as an efficient C binary (systemd-generator)
* It provides a single place for network configurations in /etc/netplan,
independently of it being used on a server (systemd-networkd) or
desktop/wifi setup (NetworkManager). This increases usability as the
documentation does not need to differentiate too much between different
scenarios.
* Reducing the delta to Ubuntu and making use of the big knowledge base
that grew since 2018 when Ubuntu switched to netplan by default (e.g.
https://askubuntu.com/questions/tagged/netplan?tab=Frequent). Many
scenarios have already been discussed in this time and solutions have
been found.
* Smaller configuration files (in comparison to (networkd/NM), that can
be split up into multiple files if wanted or needed, can be overwritten
by the user or admin (via /{lib,etc,run}/netplan overrides) and other
packages can ship drop-in snippets that provide a certain piece of
network configuration on installation.
Cheers,
Lukas
[0] https://www.freedesktop.org/software/systemd/man/systemd.generator.html
Re: netplan.io: call for co-maintainers
Hi, Hi, On Tue, 28 Sep 2021, at 08:29, Richard Laager wrote: I don't think we should install something like netplan by default. I agree: it only adds complexity. I personally use netplan everywhere. As to what should be the distro default, I'm not sure I am convinced either way, but to argue the other side... There is some value in using netplan by default. Some random thoughts: This default would match Ubuntu. (I value reducing that delta. Not everyone does, and that's fine.) netplan can configure both systemd-networkd and NetworkManager (though I've only used it with systemd-networkd). As the downstream maintainer of netplan in Debian, I’d like to use this opportunity to invite more people to co-maintain it in Debian :) I like the idea of netplan, but unfortunately I never started using it myself, to it would only be fair if someone who actually uses it could help keeping it up-to-date in Debian. As the upstream maintainer of netplan (and downstream maintainer in Ubuntu) I'd like to step up and volunteer to help with the maintenance of the netplan.io package in Debian! I'd also be happy to support the switch to netplan as the distro default. But as I'm only starting to re-activate my Debian activities after some longer break and I'm not a Debian Developer (yet?) this is not my call. Please let me know if I can help out with any specific things wrt. netplan! Otherwise, I will get back to Andrew, discussing some changes that we landed in the recent netplan releases: Most of the integration tests can nowadays be run inside containers and can thus be used as autopkgtests inside the Debian infrastructure. I think it would be a good first step for me to enable those tests. Cheers, Lukas
Re: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence
[cc += pkg-sysvinit-de...@lists.alioth.debian.org, pkg-systemd-maintain...@lists.alioth.debian.org, debian-ker...@lists.debian.org, debian-devel@lists.debian.org (as requested by Andreas Henriksson)] [cc += #785445, #785419, Rick Thomas (bug reporter)] Hi Andreas, sorry for the delay. Attached is a new patch to address your review comments. (Thanks a lot for them!) The patch no longer merely fixes the issue relating to systemd presence, but seeks to tackle the problem more comprehensively by making hwclock-set behave identically to hwclock.sh. That way, users can switch between sysvinit and systemd-udevd and get the same behavior without having to change their hwclock configuration or experiencing unpleasant surprises. On Tue, Feb 28, 2017 at 10:20:24PM +0100, Andreas Henriksson wrote: > On Mon, Feb 27, 2017 at 02:34:34PM +0100, Lukas Wunner wrote: > > Okay, let's define a policy first. How about: > > > > (1) Users can set HWCLOCKACCESS=no in /etc/default/hwclock to prohibit > > setting the system time or time zone from any RTC. (The parameter > > is already defined in the config file, but it's not honored by > > hwclock-set.) > > > > (2) Users can set HCTOSYS_DEVICE in /etc/default/hwclock to constrain > > setting the system time or time zone to a specific RTC. (Same as > > above, parameter is already defined but not honored by hwclock-set. > > This will also fix #785445.) If this parameter is not set, > > hwclock-set will pick the first RTC that becomes available. I've changed (2) to pick rtc0 (instead of the first RTC that becomes available), otherwise I'd introduce a change of behavior (as you've correctly pointed out). > > (3) If the kernel has already set the system time from *any* hwclock, > > we don't set it once more in hwclock-set. (We only adjust the > > timezone.) > > (3. would unfix #785445 from 2. again though, right? Maybe also support > HWCLOCKACCESS=force which skips 3. would really offer a solution > option for #785445 ? Reminder: This might also need 'force' to be > converted to simply 'yes' (default) in /etc/init.d/hwclock.sh) Good catch. I've changed (3) to not set the system time if the kernel has already done so AND the kernel used the same clock that was chosen by the user in HCTOSYS_DEVICE (or rtc0 if not set by the user). Thus, in a situation as described in #785445, the user would configure HCTOSYS_DEVICE=rtc1, thereby instructing hwclock-set to override the unreliable rtc0 used by the kernel. This is actually just like hwclock.sh behaves (if udev is not used). @Rick Thomas: Could you verify if the attached patch solves this issue for you? > Targeting this at Debian (doesn't suffer from the problem you're trying > to fix in any officially supported system AFAIK) we'll need to be > careful to not introduce regressions for any currently existing > configuration. (There are unfortunately many (non-default) combinations > to consider, like sysvinit, etc.) The issue relating to systemd presence does affect Debian if the RTC's driver is compiled as a module, which is true for these arches: $ git clone https://anonscm.debian.org/git/kernel/linux.git $ egrep -rc 'CONFIG_RTC_DRV.*=m$' linux/debian/config | egrep -v ':0$' linux/debian/config/config:5 linux/debian/config/kernelarch-mips/config.malta:11 linux/debian/config/kernelarch-powerpc/config-arch-64-be:1 linux/debian/config/arm64/config:1 Agreed on being careful to avoid regressions though. > > diff --git a/debian/hwclock.rules b/debian/hwclock.rules > > index 972e4aa..8584deb 100644 > > --- a/debian/hwclock.rules > > +++ b/debian/hwclock.rules > > @@ -1,4 +1,4 @@ > > # Set the System Time from the Hardware Clock and set the kernel's timezone > > # value to the local timezone when the kernel clock module is loaded. > > > > -KERNEL=="rtc0", RUN+="/lib/udev/hwclock-set $root/$name" > > +KERNEL=="rtc*", RUN+="/lib/udev/hwclock-set $root/$name $kernel" > > In general taking the initial policy and inlining it as comments in the > sources would be useful for future generations trying to figure out what > the idea was when this was changes. Also rephrasing it as eg. > # Don't touch timezone when running systemd, because . > The 'because ...' part makes it easy for future generations to evaluate > if the the check is still valid. I've added some code comments to hwclock-set to hopefully improve clarity, however I'm skeptical about keeping old code as comments, the git history should be sufficient for archeologists. :-) All your other comments make total sense to me and I
Re: proposal: Hybrid network stack for Trixie
Hi! On 22.09.24 15:58, Ansgar 🙀 wrote: On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote: I've repeated the reasons why I think a hybrid stack using Netplan is a feasible solution many times in previous threads, therefore I'd like to refer to a list of frequently asked questions, instead of spreading more reasons across more replies: https://wiki.debian.org/Netplan/FAQ The FAQ states: "If native backend configuration is applied on top of that, Netplan will now know, nor care about it (unless they try to configure an interface controlled by Netplan in a conflicting way)." What does that mean on desktop systems? What will happen when a user wants to change the configuration using the UI (which usually talks to NetworkManager)? This is a very good question, also asked by Chris above. If users want to control their network configuration through the NetworkManager UI, they can just continue to do that as always, it's a case of configuration at the native layer. NM will continue to function as always, storing its profiles in /etc/NetworkManager/system-connections. Netplan would not know about those connection-profiles, but would not interfere, as long as people do not try to configure the same interface through /etc/netplan/ settings. The benefit that Netplan would provide in such cases is that debian-installer installs a /etc/netplan/01-network-manager-all.yaml config file, reading: network: version: 2 renderer: NetworkManager This sets Netplan's default renderer to NetworkManager, so that any configuration added in /etc/netplan/ would show up in the NetworkManager UI, and the interface will be handled by the NetworkManager daemon. Still, config files in /etc/netplan/ need to be driven through Netplan settings. In Ubuntu we carry patches, which had been discussed with [upstream] (but were rejected back then). Those might need some more refinement before wider adoption. Those allow to configure interfaces through Netplan and NetworkManager at the same time, e.g. a config originating from /etc/netplan/ can be modified via the UI tooling provided by NetworkManager. In my [blog] I wrote about how we utilize this in Ubuntu. Cheers, Lukas [blog] https://blog.slyon.de/2023/11/12/netplan-brings-consistent-network-configuration-across-desktop-server-cloud-and-iot/ [upstream] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556
Re: proposal: Hybrid network stack for Trixie
On 22.09.24 23:59, Josh Triplett wrote:
On Sun, Sep 22, 2024 at 10:30:12PM +0200, Andrea Pappacoda wrote:
On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
There's one other desirable feature that would make this a robust
solution: having NetworkManager do something to handle or ignore
interfaces managed by networkd.
If I'm interpreting correctly what you mean, this should already be
possible, see <https://mastodon.social/@pid_eins/112398647693125514>.
That's exactly what I mean, and that looks promising! As long as the
version of NetworkManager in Debian supports that, this should work
perfectly out of the box, even when a user installs a non-GUI system and
later installs a GUI that includes NetworkManager.
It's great that we now have a more standardize way to define this in udev!
In Netplan we faced this issue a lot over the years, when users had
configurations using multiple backends at the same time, e.g. some
interfaces set to "renderer: networkd" while others were set to
"renderer: NetworkManager" in their Netplan configuration.
It was solved by controlling the ENV{NM_UNMANAGED}="0" variable via udev
rules and configuring the [device-*].managed={true,false} NetworkManager
settings accordingly.
-- Lukas
Re: proposal: Hybrid network stack for Trixie
On 23.09.24 11:04, Marco d'Itri wrote: On Sep 23, Holger Levsen wrote: ifupdown2 is like ifupdown, just rewritten in python. Yes, that's the problem: there was a consensus that it is not an appropriate dependency for the base system. ifupdown2 will still be around for anybody who wants to install it. Quoting Julien: "Back in 2016, with Cumulus, we had the goal and ambition to become the default debian network manager, but we realized that the python dependency would be a blocker, so we don't have that goal anymore. And we are happy with the way things are now, supporting our community users and customers." See: https://lists.debian.org/debian-devel/2024/07/msg00204.html
Re: proposal: Hybrid network stack for Trixie
On 22.09.24 12:22, Chris Hofstaedtler wrote: * Lukas Märdian [240920 13:13]: I've repeated the reasons why I think a hybrid stack using Netplan is a feasible solution many times in previous threads, therefore I'd like to refer to a list of frequently asked questions, instead of spreading more reasons across more replies: https://wiki.debian.org/Netplan/FAQ # Why The ifupdown package is a Debian only solution that is becoming a maintenance burden. We've had plenty of discussions over the years and consensus is that we want to get rid of it. Some variations of Debian have already moved forward with choosing a different stack, such as desktop/laptop installations (using NetworkManager) and cloud images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern re-implementation of the classic tooling, that strives to become drop-in [compatible]. Thanks for providing the FAQ and this "Why" section, but it seems to leave open why we would want or need netplan as the default. As the FAQ shows, netplan is available as an optional package in many distros. The same is already true in Debian thanks to you. As described in the "Proposal" section and first answer of the FAQ, it's all about consistency. There seems to be a tendency for moving towards a hybrid stack, using sd-networkd and NetworkManager in different contexts/use-cases. But having fragmented ways of doing network configuration provides bad UX, as it can confuse users, who first need to understand what sortf of Debian they are using, before looking for solutions. Netplan solves this and allows for providing common solution that work across the system. The Netplan tooling around that, like "netplan status" or "netplan try" to query/debug the network configuration or apply, but roll-back configuration, in case it did not work out as expected, are only added benefits. For your described usecase groups, which seem to clearly map to the backends used by netplan, I do not see what netplan brings to the table. The "server" group supposedly wants (and I agree) networkd, but they also want the configuration interface of networkd. The "laptop" group supposedly wants (and I agree) NetworkManager, but they also want the configuration interface of NetworkManager. Who actually wants the configuration interface of netplan, especially by default? I see nobody saying "yet another layer is a lot of fun!", and the usecase groups do not overlap that much, that they both would *need* the same interface? The opposite seems to apply. It's sad to see that fellow DDs do not seem to care about consistency and usability in this regard. PS: I know this proposal doesn't please everybody, but I think it's the most actionable option that we have on the table and strikes a good compromise. As a replacement for ifupdown is overdue, we should adopt our network stack for Trixie. d-i could make (or offer) a choice between networkd and NetworkManager. Doesn't have to be netplan. I can vaguely see how d-i might be simpler by writing netplan config, but it still has to make a choice of the default backend? And then what does netplan help here? Given d-i then will have to make a choice, *none* of the networking stack packages should have a "Priority:" higher than optional. As in, even if we would go with netplan in d-i, there is no "default" anymore and people have to make choices. As stated below, d-i already makes this choice between ifupdown, NetworkManager and Netplan, depending on context of installed packages in the target system. There's also a (stale?) MR to add systemd-networkd to the mix [1]. Personally, I do not necesarily think showing more options to the users is better. But I've heard this being suggested several times. So how do others think about having a network-stack selection in debian-installer/tasksel? Similar to the desktop-stack selection. Cheers, Lukas [1] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/11
Re: proposal: Hybrid network stack for Trixie
On 23.09.24 12:27, Ansgar 🙀 wrote: On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote: On 22.09.24 15:58, Ansgar 🙀 wrote: On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote: I've repeated the reasons why I think a hybrid stack using Netplan is a feasible solution many times in previous threads, therefore I'd like to refer to a list of frequently asked questions, instead of spreading more reasons across more replies: https://wiki.debian.org/Netplan/FAQ The FAQ states: "If native backend configuration is applied on top of that, Netplan will now know, nor care about it (unless they try to configure an interface controlled by Netplan in a conflicting way)." What does that mean on desktop systems? What will happen when a user wants to change the configuration using the UI (which usually talks to NetworkManager)? This is a very good question, also asked by Chris above. If users want to control their network configuration through the NetworkManager UI, they can just continue to do that as always, it's a case of configuration at the native layer. NM will continue to function as always, storing its profiles in /etc/NetworkManager/system-connections. Netplan would not know about those connection-profiles, but would not interfere, as long as people do not try to configure the same interface through /etc/netplan/ settings. The benefit that Netplan would provide in such cases is that debian-installer installs a /etc/netplan/01-network-manager-all.yaml config file, reading: network:   version: 2   renderer: NetworkManager So on desktop installations including NetworkManager, netplan will be configured to do nothing? Why install netplan at all on desktop systems then? Because it allows to add configuration in a way that is common with server, cloud and other instances of Debian. It's not about enforcing this, or breaking people's use-cases. But about working towards unified network configuration. -- Lukas
Re: proposal: Hybrid network stack for Trixie
On 23.09.24 13:33, Richard Lewis wrote: Lukas Märdian writes: On 23.09.24 12:27, Ansgar 🙀 wrote: On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote: On 22.09.24 15:58, Ansgar 🙀 wrote: On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote: The benefit that Netplan would provide in such cases is that debian-installer installs a /etc/netplan/01-network-manager-all.yaml config file, reading: network:   version: 2   renderer: NetworkManager So on desktop installations including NetworkManager, netplan will be configured to do nothing? Why install netplan at all on desktop systems then? Because it allows to add configuration in a way that is common with server, cloud and other instances of Debian Could you give an example of why this is useful to unify? For example: is there a scenario in which someone is using systemd-networkd but then finds they need to do X, which they cant essily do using systend but which nm support is better--- therefore if they are using netplan they can simply install network-manager, change a netplan setting and gain X with no need to understand the differences between the network-manager and systemd configuration languages? My ideas was not so much about switching from one networking daemon to another. In most cases users will probably stick to the network stack of their chosen environment. With systemd-networkd and NetworkManager being good candidates for their corresponding scenarios. But knowledge builds up over the years in our community and spreads around forums, stack overflow, etc. Those are the places where we figure out "How to setup a bond on Debian?", "How to connect a headless embedded board to the WiFi network" or "How to change the embedded-switch mode on SR-IOV physical functions?". We find solutions and help each other out, which is great! But with fragmented network-configuration tooling those solutions will not work in many cases, as they depend on a specific context of the base-image in use (e.g. server vs desktop vs embedded vs cloud). With Netplan I'm hoping to avoid such frustration by providing a way to configure the network that works independently of the base-image context. Of course without forcing people to use it or impacting the lower layer to be configured directly. -- Lukas
proposal: Hybrid network stack for Trixie
Hi all! After hosting a networking [bof] at DebConf 2024, consulting with the networking [team] and receiving comments from others on this mailing list, I'd like to summarize the state of affairs in our network tooling discussion and make a formal proposal of how we can move forward. The change from deprecated ISC dhclient to dhcpcd-base (Bug #1038882) has been a long time coming and was finally accepted (kudos to Martin-Éric, Santiago and Sean for moving that case forward!), but that's not enough and we should re-consider our full network stack. There's also a write-up on this case by LWN.net, if you're looking for another summary, but in the end it boils down to having consensus that we want to get off ifupdown/status quo (as has been discussed for so many years) and therefore we should to consider the modern and well-maintained alternatives that we have on the table: https://lwn.net/Articles/989055/ # Proposal My proposal is to enable a hybrid network stack, using systemd-networkd (on server/cloud/container/embedded systems) and NetworkManager (on desktop/laptop systems) unified through a common layer of Netplan configuration on top, to avoid fragmentation. This utilizes 3 tools that are under active upstream development and are already used as defaults in certain variants of Debian today. Furthermore, it allows people to control this stack on the native systemd-networkd/NetworkManager layer directly, while at the same time providing a way to describe network configuration that is common across Debian. I've repeated the reasons why I think a hybrid stack using Netplan is a feasible solution many times in previous threads, therefore I'd like to refer to a list of frequently asked questions, instead of spreading more reasons across more replies: https://wiki.debian.org/Netplan/FAQ # Why The ifupdown package is a Debian only solution that is becoming a maintenance burden. We've had plenty of discussions over the years and consensus is that we want to get rid of it. Some variations of Debian have already moved forward with choosing a different stack, such as desktop/laptop installations (using NetworkManager) and cloud images (using Netplan+systemd-networkd). Also, ifupdown-ng exists as a modern re-implementation of the classic tooling, that strives to become drop-in [compatible]. # How Initially, I suggested pulling the minimal "netplan-generator" package into the base installation, but discussions showed that that's not appreciated by fellow DDs and community members. So, I want to propose bumping to "Priority: standard" only, but using the "netplan.io" package (Netplan generator + CLI). This way, Netplan would only be installed and configured for new installations through Debian-Installer, when the "standard system utilities" task is selected. The "standard" task is very easy to opt-out from for people who do not want to use Netplan and already comes with the Python runtime pre-selected, which allows for installing the full Netplan CLI tooling, providing improved usability (e.g. "netplan status" commands) without too much overhead. Myself and others have already laid the technical groundwork in Debian-Installer [d-i], Calamares, FAI and autopkgtest tooling to have Netplan support readily available. So all we need to do is switching the "Priority" of the "netplan.io" binary package. # Compatibility We do not want to break existing systems or people that want to keep using the classic way of /etc/network/interfaces. Therefore, I'm intentionally NOT suggesting to remove ifupdown from the base installation. I would love to see it being replaced by ifupdown-ng, to reduce the maintenance burden of classic ifupdown. This means base installations would still come pre-installed with ifupdown[-ng] and systemd-networkd (as part of the systemd package). This leaves us with some network configuration fragmentation, but still feels like a reasonable step into the right direction. Dropping network related packages from the base installation is not part of this proposal. Let's keep this for another time, after Trixie is released. Thanks for considering my proposal. Cheers, Lukas PS: I know this proposal doesn't please everybody, but I think it's the most actionable option that we have on the table and strikes a good compromise. As a replacement for ifupdown is overdue, we should adopt our network stack for Trixie. Therefore, we should consider making a change at this time of the cycle, so that we still have plenty of time to test, fix integrations or roll back, should it turn out to be a bad decision. [bof] https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/ [team] https://tracker.debian.org/teams/networking/ [faq] https://wiki.debian.org/Netplan/FAQ [d-i] https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 [compatible] https://github.com/ifupdown-ng/ifupdown-ng/issues/247 signature.asc Description: PGP signature
