ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already
On Mon, 11 Mar 2024 07:02:38 +0200, Martin-Éric Racine
wrote:
>Meanwhile a bare minimal system needs a non-GUI solution and swaping
>which DHCP client gets pulled by ifupdown is the simplest, least
>disruptive way of accomplishing this.
Most bare minimal non-GUI systems run fine with
ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > I hereby propose bin:dhcpcd-base:
> >
> > 1) already supported by ifupdown.
> > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> >
Hi,
On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> I hereby propose bin:dhcpcd-base:
>
> 1) already supported by ifupdown.
> 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> separation.
> 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> 4)
su 10. maalisk. 2024 klo 18.54 Santiago Ruano Rincón
(santiag...@riseup.net) kirjoitti:
>
> Hi there,
>
> El 20/11/23 a las 19:44, Martin-Éric Racine escribió:
> > (non-subscriber - please keep me in CC)
> > On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine
> > wrote:
> > >
> > > On Sat, Jul 22,
Hi there,
El 20/11/23 a las 19:44, Martin-Éric Racine escribió:
> (non-subscriber - please keep me in CC)
> On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine
> wrote:
> >
> > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
> > wrote:
> > >
> > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric
(non-subscriber - please keep me in CC)
On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine
wrote:
>
> On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
> wrote:
> >
> > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
> > wrote:
> > >
> > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano
Sent: Saturday, November 18, 2023 14:10
To: debian-devel@lists.debian.org
Subject: Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 18.11.23 um 15:26 schrieb Martin-Éric Racine:
> What is the current situation?
I don't think we reached a consensus yet.
One particular asp
Am 18.11.23 um 15:26 schrieb Martin-Éric Racine:
What is the current situation?
I don't think we reached a consensus yet.
One particular aspect I don't like of the current proposal is that users
upgrading from bookworm will end up with both, isc-dhcp-client and
dhcpcd-base being installed.
On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
wrote:
>
> On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
> wrote:
> >
> > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> > wrote:
> > >
> > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > > El 20/06/23 a las 08:29,
El 10/07/23 a las 14:52, Helmut Grohne escribió:
> On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote:
> > On top of that, a minimal installation chroot doesn't need a
> > fully-featured dhcp client. As Simon said already, busybox is there
> > for any reason for a minimal one. For the
On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
wrote:
>
> On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> wrote:
> >
> > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > On Mon, Jun 19, 2023 at 9:11 PM
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote:
> 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
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
On Sat, Jul 15, 2023 at 02:04:57PM -0400, nick black wrote:
> Sam Hartman left as an exercise for the reader:
> > I consider anything that requires me to write wpa_supplicant config to
> > be a bad idea (unless I'm running an AP) and NetworkManager driving
> > wpa_supplicant is a better idea.
>
Sam Hartman left as an exercise for the reader:
> > "nick" == nick black writes:
> I consider anything that requires me to write wpa_supplicant config to
> be a bad idea (unless I'm running an AP) and NetworkManager driving
> wpa_supplicant is a better idea.
i think everyone's agreed on this
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
> "Lukas" == Lukas Märdian writes:
Lukas> That would lead to a situation where users would need to
Lukas> differentiate what system they are on when doing their
Lukas> network configuration: Debian Cloud (Netplan)
No, I think if the user is feeding configuration into a cloud
> "nick" == nick black writes:
I consider anything that requires me to write wpa_supplicant config to
be a bad idea (unless I'm running an AP) and NetworkManager driving
wpa_supplicant is a better idea.
--Sam
Sam Hartman left as an exercise for the reader:
> In the wifi case though, I agree that netplan is a good idea.
> It doesn't look like systemd-networkd supports setting up the
> authentication for a wireless network. So, you'd need to be using
> wpa_supplicant directly and systemd-networkd. I
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
Hi Lukas,
* Lukas Märdian [2023-07-12 12:53]:
Thank you for pointing this out. It's been on my TODO list for a while to split
the netplan.io package, and make the Python-CLI parts optional. They are not
strictly required to configure a system at boot time.
I took your mail as an occation to
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
On Tue, 11 Jul 2023 at 17:48:40 +0200, Lukas Märdian 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:
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
On Jul 11, Sam Hartman wrote:
> 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.
I
On 2023-07-12 07:54, Gioele Barabucci wrote:
1) It's an extra layer. [...]
2) It's a layer that you cannot ignore when editing the config. [...]
I'd also add 3) It requires Python and various Python libraries. At
least the CLI tool does.
In some circumstances installing Python and a bunch
On 11/07/23 23:06, Sam Hartman wrote:
However, there are some significant disadvantages to netplan:
1) It's an extra layer. [...]
2) It's a layer that you cannot ignore when editing the config. [...]
I'd also add 3) It requires Python and various Python libraries. At
least the CLI tool
> "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 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
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
On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote:
> On top of that, a minimal installation chroot doesn't need a
> fully-featured dhcp client. As Simon said already, busybox is there
> for any reason for a minimal one. For the rest - installer and whatnot
> - the installer and
On Sat, 8 Jul 2023 at 08:39, Bastian Blank wrote:
>
> On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote:
> > > "Bastian" == Bastian Blank writes:
> > Bastian> Why do we need to have the priority adjusted instead of fix
> > Bastian> d-i to install what it knows the user
On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote:
> > "Bastian" == Bastian Blank writes:
> Bastian> Why do we need to have the priority adjusted instead of fix
> Bastian> d-i to install what it knows the user needs?
> Because it's not just D-I, it's bootstrapping in
> "Bastian" == Bastian Blank writes:
Bastian> On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón
wrote:
>> For the moment, ifupdown is still installed by the
>> debian-installer as default network interfaces manager. And after
>> sleeping over it, and discussing
On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote:
> For the moment, ifupdown is still installed by the debian-installer as
> default network interfaces manager. And after sleeping over it, and
> discussing with debian fellows, I would like to call for consensus to
> rise
On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
wrote:
>
> El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > wrote:
> > > > El 19/06/23 a las 13:54, Martin-Éric
El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > wrote:
> > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > Greetings,
> > > >
> > > > Seeing how the ISC
On Thu, 2023-06-22 at 20:51 +0200, Philipp Kern wrote:
> On 22.06.23 16:03, Marco d'Itri wrote:
>
>
> TBH time is too short to manually provision IP addresses on servers.
>
IP addresses are just one of many things that can be instantiated by
/etc/network/interfaces, /etc/network/interfaces.d/,
On Thu, Jun 22, 2023 at 08:51:01PM +0200, Philipp Kern wrote:
> TBH time is too short to manually provision IP addresses on servers.
And DHCP is gladly enough entirely optional since SLAAC exists. But
for that you need systemd-networkd/systemd-resolved or a whole bunch of
other software.
On 22.06.23 16:03, Marco d'Itri wrote:
On Jun 22, Martin-Éric Racine wrote:
The point has always been to ship some ifupdown-supported DHCP client
by default. This can be done either by keeping the default client's
priority to important or by making ifupdown Depends on one. I prefer
the later.
Marco d'Itri writes:
> On Jun 22, Martin-Éric Racine wrote:
>
>> The point has always been to ship some ifupdown-supported DHCP client
>> by default. This can be done either by keeping the default client's
>> priority to important or by making ifupdown Depends on one. I prefer
>> the later.
>
On Jun 22, Martin-Éric Racine wrote:
> The point has always been to ship some ifupdown-supported DHCP client
> by default. This can be done either by keeping the default client's
> priority to important or by making ifupdown Depends on one. I prefer
> the later.
It would be totally unacceptable
On Thu, Jun 22, 2023 at 3:58 PM Santiago Ruano Rincón
wrote:
> El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > wrote:
> > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > Greetings,
> > > >
> > > > Seeing how the
El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> wrote:
> > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > Greetings,
> > >
> > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > > good time to
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
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
On 2023-06-19 Sven Joachim wrote:
[...]
> If my above statements about debootstrap are correct, this will result
> in no dhcp-client being installed at all by debootstrap unless the
> override bug also requests bumping dhcpcd-base's priority from optional
> to important.
Not complety true.
On Tue, Jun 20, 2023 at 10:23:58AM +0100, Matthew Vernon wrote:
> We might be using slightly different terms, but for desktops I still
> tend to use ifupdown (since the network config is easily configured
> thus, and essentially never changes); laptops I have ifupdown &
> network-manager (since
Simon McVittie left as an exercise for the reader:
> I was using "desktop" in the sense of task-gnome-desktop and friends, more
> than as a class of hardware. Laptops and other portable computers are the
> main thing that really needs easily user-configurable networking.
> I think it makes sense
On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian wrote:
>
> 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
On Tue, 20 Jun 2023 at 11:42, Simon McVittie wrote:
>
> On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote:
> > Simon McVittie left as an exercise for the reader:
> > > At the moment I believe the status quo for d-i is that networking is
> > > managed by NetworkManager if a desktop task
On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > 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
On Tue, 2023-06-20 at 05:03 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > 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
Ansgar writes:
> I think this should be NetworkManager for desktop environments and I
> personally like systemd-networkd for other environments. In both cases
> these replace both ifupdown and isc-dhcp-client.
We might be using slightly different terms, but for desktops I still
tend to use
nick black writes:
> what
> does NetworkManager offer that makes it superior to
> systemd-networkd on the desktop
I don't know what systemd-networkd has to offer in this regard, but for
laptop usage I'm personally fond of the ModemManager integration along
with multihoming policies (eth0
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
Simon McVittie left as an exercise for the reader:
> 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
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 of resources to maintain those
setups, and the road should
Martin-Éric Racine writes:
> On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> wrote:
>> El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
>> > Greetings,
>> >
>> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
>> > good time to re-visit Debian's choice of
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
wrote:
> El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > Greetings,
> >
> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > good time to re-visit Debian's choice of standard DHCP client shipping
> > with
On 2023-06-19 21:37 +0100, Simon McVittie wrote:
> On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote:
>> I've never had to do this before, so I wonder if moving packages to
>> severity: standard or higher (in this case, important) requires any
>> decision from the CTTE or a similar
Am 19.06.23 um 22:37 schrieb Simon McVittie:
If you agree with the way forward that I'm suggesting, then I think the
way to do it would be:
1. open an override bug asking for isc-dhcp-client to be lowered from
important to optional
2. wait for the ftp team to do that
3. ask the ifupdown
On Mon, 19 Jun 2023 at 21:42:08 +0300, Martin-Éric Racine wrote:
> I've never had to do this before, so I wonder if moving packages to
> severity: standard or higher (in this case, important) requires any
> decision from the CTTE or a similar authority, before we proceed?
Regarding *whether* to
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 of resources to maintain those
> > setups, and the road should already be paved for it.
>
> I am
On Mon, 19 Jun 2023 at 20:00, Martin-Éric Racine
wrote:
>
> On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> wrote:
> > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > > good time to re-visit Debian's
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
wrote:
> El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > good time to re-visit Debian's choice of standard DHCP client shipping
> > with priority:important.
>
Hi,
El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> Greetings,
>
> Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> good time to re-visit Debian's choice of standard DHCP client shipping
> with priority:important.
>
> I hereby propose bin:dhcpcd-base:
>
> 1)
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
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 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].
On Mon, 19 Jun 2023 at 13:13, 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 and each network
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 and each network configuration system
> has its own preferred dhcp
On Mon, 19 Jun 2023 at 12:36, Michael Biebl wrote:
>
> Am 19.06.23 um 12:54 schrieb Martin-Éric Racine:
> > Greetings,
> >
> > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > good time to re-visit Debian's choice of standard DHCP client shipping
> > with
Am 19.06.23 um 12:54 schrieb Martin-Éric Racine:
Greetings,
Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
good time to re-visit Debian's choice of standard DHCP client shipping
with priority:important.
I hereby propose bin:dhcpcd-base:
1) already supported by
Greetings,
Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
good time to re-visit Debian's choice of standard DHCP client shipping
with priority:important.
I hereby propose bin:dhcpcd-base:
1) already supported by ifupdown.
2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with
75 matches
Mail list logo
