Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

Hi Nick,

On Mon, Sep 27, 2021 at 06:25:03PM -0400, nick black wrote:
> Marc Haber left as an exercise for the reader:
> > But maybe an alternative? I find the partitioning step one of the most
> > error-prone and hard-to-use parts of non-trivial Debian installations.
> 
> so overall, i've got to say the feedback i heard here was a lot
> more positive than i was expecting, though there was a bit less
> than i had hoped for. but perhaps something that can be touched
> would see more interest?
> 
> given that no one seemed to reject the idea out of hand, i'm
> going to go ahead and rebase my work from 2012 (or more likely
> look at it once and redo it) in a Salsa fork of d-i, and make
> some installation media available. forgive me for likely only
> having x86 available at first. i'll try to have this done within
> a week or so, and put it up on my server. people can then give
> it a whirl.

I hadn't replied to it *yet*, but had fully intended to do so (just
didn't get around to that yet).

One thing that partman does is "support plug-ins", to allow for
configuring block devices before being able to partition them, where
needed. This can be useful for iSCSI, multipath, or (the one I care most
about) NBD. I wrote a "partman-nbd" a few years back to do just that:

https://salsa.debian.org/installer-team/partman-nbd

This adds a few options to the partitioner menu to allow you to
add or remove an NBD device, and then if used makes sure the resulting
system is configured properly so that the NBD device(s) configured in
the installer will work after the system has been booted.

It would be nice if whatever component you write to replace partman has
support for things along these lines too. I don't mind having to rewrite
partman-nbd if that ends up being necessary (it's trivial enough), but
others might have different ideas about, say, partman-iscsi (just using
that as an example though, no idea about the details there).

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> 
> 
> > On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> > 
> > Even if that interpretation would work as an excuse to never do
> > anything, and I'm not really sure it does, this specification has been
> > published in 2014 [0] so even by Debian standard it's old stuff.
> 
> That’s not what I said so. You’re trying to dismiss my opinion as completely 
> invalid now by trying to frame it such that I am against progress. I am not.
> 
> > It's
> > older than Debian Jessie, which was EOL'd last year. If libparted can't
> > keep up with 7 years old stuff that in the meantime was implemented in
> > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> > and so on, then to me it sounds like a tool in maintenance mode:
> > perfectly fine and adequate for existing tools and programs, but not
> > quite the best choice for new tools developed from scratch.
> 
> Whether a tool that was developed new from scratch is automatically better is
> not a given. The burden of proof is on the person trying to introduce the new
> software, not on the people maintaining the current set of software.

I think you're reading too much into the question here. The whole
*point* of Nick asking whether people would be opposed to that is
precisely *because* he wants to provide proof that his solution is
better than parted.

You've shown some things that are missing, and his immediate answer is
"ah, right, I'll need to add that then, but would need some assistance
to test that properly".

What's the problem with that?

Nobody is proposing to replace partman tomorrow.

Nobody is proposing to replace partman without testing the replacement.

It's also perfectly possible to imagine a transition period where both
partitioners are supported. That's the whole point of making d-i
modular: you can replace one component with another, and it adds new
features that support more use cases without killing off the older ones
because you can always ask for the other module. In fact, if memory
serves well, partman is the *second* partitioner that was written for
d-i, the first one having been replaced after just such a transition.

IOW, chill out, nobody's going to kill off partman unless there's
something that's *actually* better than partman.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[nick black]

Wouter Verhelst left as an exercise for the reader:
> One thing that partman does is "support plug-ins", to allow for
> configuring block devices before being able to partition them, where
> needed. This can be useful for iSCSI, multipath, or (the one I care most
> about) NBD. I wrote a "partman-nbd" a few years back to do just that:
> https://salsa.debian.org/installer-team/partman-nbd

Thanks a lot for pointing this out, Wouter -- this is *exactly*
the kind of feedback I was hoping for! I allow loopback devices
to be set up, but not in any reboot-crossing manner, and I have
no NBD nor iSCSI functionality.

 https://github.com/dankamongmen/growlight/issues/150

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[John Paul Adrian Glaubitz]

On 9/28/21 12:13, Wouter Verhelst wrote:
> IOW, chill out, nobody's going to kill off partman unless there's
> something that's *actually* better than partman.

Just some comments after reading after this [1] because I honestly find it
unfair the way I am being cornered here.

First of all, neither Fedora or openSUSE seem to use glowlight as their
primary partitioning tool nor are they using discoverable partitions.

Secondly, discoverable partitions are primarily intended for containers
and systemd is using mkosi [2] for generating such images with discoverable
partitions.

Thirdly, Luca Boccassi considers himself to be systemd upstream [3] without
disclosing that information here. This is an information that he should
at least have disclosed before starting to voice his support for discoverable
partitions and insisting that the feature is important enough to kill off
parted.

Thanks,
Adrian

> [1] https://lwn.net/Articles/859240/
> [2] http://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html
> [3] https://lwn.net/Articles/859769/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Tue, Sep 28, 2021 at 06:19:28AM -0400, nick black wrote:
> Wouter Verhelst left as an exercise for the reader:
> > One thing that partman does is "support plug-ins", to allow for
> > configuring block devices before being able to partition them, where
> > needed. This can be useful for iSCSI, multipath, or (the one I care most
> > about) NBD. I wrote a "partman-nbd" a few years back to do just that:
> > https://salsa.debian.org/installer-team/partman-nbd
> 
> Thanks a lot for pointing this out, Wouter -- this is *exactly*
> the kind of feedback I was hoping for! I allow loopback devices
> to be set up, but not in any reboot-crossing manner, and I have
> no NBD nor iSCSI functionality.
> 
>  https://github.com/dankamongmen/growlight/issues/150

NBD is fairly easy to set up (well, it is for me, but then I'm biased).
For the server side, you install nbd-server, you create a (probably
sparse) large file somewhere, and then edit /etc/nbd-server/config to
point to that. For the client side, you install nbd-client and read "man
5 nbdtab" if you want to persist things, or you read "man 8 nbd-client"
if you just want to connect now and not care about reboot.

iSCSI works very differently and is way more complex, but I remember
from when I last played with it (which is a while ago, so the details
are hazy) that it's not possible to set up in a non-persistent manner
(i.e., all iSCSI connections survive reboot unless explicitly deleted,
although obviously partman-iscsi has to do some dark magic to ensure the
configuration is migrated from the d-i environment to the live system).

There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath,
and a whole slew of other things, if you want to configure this from
growlight.

That said though, I would personally recommend against doing that. From
where I'm standing, it seems to be out of scope for growlight? If you're
replacing partman in d-i, you'd still need to add *some* d-i
integration, and I'd imagine that integration is where this type of
device configuration would go. As far as running growlight outside of
d-i goes, there I'd think you'd just tell the user to configure the
device before starting growlight (or you'd give them the ability to
re-scan for new devices after they'd set up the device in a (different)
terminal), and then that'll be all? Otherwise you'll end up with a
neverending story of "oh here's another type of device that needs to be
added", and I don't think that's a great rabbit hole to go down.

I could be wrong though, haven't looked at growlight in much detail, and
in the end it's your call, not mine :-D

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Cyril Brulebois]

Hi nick,

[ cc += debian-boot@ ]

nick black  (2021-09-27):
> Marc Haber left as an exercise for the reader:
> > But maybe an alternative? I find the partitioning step one of the
> > most error-prone and hard-to-use parts of non-trivial Debian
> > installations.
> 
> so overall, i've got to say the feedback i heard here was a lot more
> positive than i was expecting, though there was a bit less than i had
> hoped for. but perhaps something that can be touched would see more
> interest?

FWIW I've followed the answers to your mail over the last few days,
but I haven't had a chance to look at either the video or the slides
(only 4 days before your initial mail and the one I'm replying to…).


At first glance, it seems fine to be experimenting with a different
partitioner; of course all people are somewhere on the love/hate
spectrum regarding partman and the zillions of partman-* packages, but
it's indeed a shell maze and it *probably* could use some heavy lifting.
I keep hoping that simple use cases are made simple(r)… maybe growlight
could help there (e.g. “I'd like soft RAID1 with encrypted LVM, all that
with a UEFI boot — therefore ESP —, without being a storage wizard”).

I suppose some step (once you've experimented on a growlight-only
d-i) would be to have both partman and growlight, and let people
choose (maybe with a flag at boot time, or by entering expert mode or
whatever), until we have a better idea what works, what doesn't, what
can be fixed, what cannot, and until a decision is made for the next
Debian stable release.


Leaving the technical integration aside for a moment, one question
that comes to mind is whether this would be a one-shot contribution or
some kind of longer commitment to maintain that different partitioner.
I seem to remember earlier attempts at revamping the partitioning
step, which stalled eventually.

(Your recent mail to debian-newmaint@ is a hint; your apparent
steadiness of those packages maintenance-wise is another; and your
apparent interest in adding support to possibly missing features yet
another.)

Of course, one might object that the question is moot as there isn't
much active development on partman components (even if some patches have
been submitted over the last few days), but at least that's a known
(imperfect, but…) beast.

> given that no one seemed to reject the idea out of hand, i'm going to
> go ahead and rebase my work from 2012 (or more likely look at it once
> and redo it) in a Salsa fork of d-i, and make some installation media
> available. forgive me for likely only having x86 available at first.
> i'll try to have this done within a week or so, and put it up on my
> server. people can then give it a whirl.

Feel free to touch base with debian-boot@ and/or debian-cd@ once you
have a working proof of concept that some people have toyed with; we can
discuss how the “alternative” part could be implemented (different
images, or both partitioners ship together, with some option/selection —
people might remember GRUB vs. LILO). I cannot guarantee a timely answer
(life tends to keep me busy), but you shouldn't see a lack of answer
after just a few days as if people were not interested.

> note that there would still be some questions where i'd need input
> from Project members (as noted in my Debconf [0] presentation),
> particularly regarding translation (even if i can lift significant
> portions from partman, i'd need it looked over) and facilitating
> accessibility technology.

I won't delve into specifics (I did mention I didn't do any research,
right?) but as long as your application can be controlled via debconf,
it should fit right in within all our installation images (text based
installer, graphical installer, network-controller installer, etc.), and
things like localization and accessibility support should be automatic
(of course you'd still need to get the translation process bootstrapped
for your own strings at some point, but the inner workings should all be
there already).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[nick black]

Wouter Verhelst left as an exercise for the reader:
> iSCSI works very differently and is way more complex, but I remember
> from when I last played with it (which is a while ago, so the details
> are hazy) that it's not possible to set up in a non-persistent manner
> (i.e., all iSCSI connections survive reboot unless explicitly deleted,
> although obviously partman-iscsi has to do some dark magic to ensure the
> configuration is migrated from the d-i environment to the live system).

i've actually worked pretty extensively with iSCSI--i presented
on it at LPC2015 [0] =]. as far as i understand, iSCSI
connections are initiated and managed by the iscsid userspace
daemon (aside from root-on-iSCSI, which uses iscsistart, or at
least did. UEFI/BIOS iSCSI can also server here).

> There's also ATA-over-Ethernet, Fibrechannel-over-ethernet, multipath,
> and a whole slew of other things, if you want to configure this from
> growlight.

as you note, most of this is not stuff i want to slap a UI on,
but i'd certainly want to hit full partman feature parity...in
time. if it's best early on, i feel no shame punting more
esoteric setups to partman; as i've said, i would expect partman
to remain present on the installation media for at least some
significant time.

> I could be wrong though, haven't looked at growlight in much detail, and
> in the end it's your call, not mine :-D

nope, pretty much totally correct.

--nick

[0]
https://nick-black.com/dankwiki/images/e/ea/Public_LPC2015_-_Dynamic_iSCSI_at_Scale-_Remote_paging_at_Google.pdf

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Tue, Sep 28, 2021 at 12:22:18PM +0200, John Paul Adrian Glaubitz wrote:
> On 9/28/21 12:13, Wouter Verhelst wrote:
> > IOW, chill out, nobody's going to kill off partman unless there's
> > something that's *actually* better than partman.
> 
> Just some comments after reading after this [1] because I honestly find it
> unfair the way I am being cornered here.

Yes, and what I'm saying is, I don't think anyone is trying to corner
you here, Nick are just saying "hey here's some cool new tech, what do
people think". The consensus in my reading is that people like it enough
that we might want to see some proof of concept, and then, assuming it
doesn't lack functionality that we don't want to lose and gives us
something new that we do like (e.g., better usability, more features,
etc etc) then we can perhaps replace partman one or more releases down
the line as the default partitioner.

You have some very good arguments against growlight in its *current*
state. That's fine. Just stay on top of things, and perhaps help Nick
out with testing a few of the more exotic features that partman
currently supports? Either through emulators or by giving him access to
real hardware if you can provide it (and given your collection, I
suspect you can ;-) ).

partman is currently being maintained by the d-i team very much in a
drive-by patches manner, but it's not actually seeing development of new
features. If Nick is offering to take over that work by replacing the
parted bits in d-i by his pet project, *and* he's offering to make sure
that we don't lose functionality we actually care about, then I think
that's a good thing? It's just a matter of making sure Nick *knows*
about the important bits, and that they get implemented in whatever we
end up replacing partman with before we actually do so...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Bug#995189: RFH: isc-dhcp

[Marc Haber]

On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri  wrote:
>On Sep 28, Noah Meyerhans  wrote:
>> For what it's worth, my preference would be transition to
>> systemd-networkd with bookworm.
>I think that a good default would be systemd-networkd for servers and 
>NetworkManager for systems with Wi-Fi or a GUI.

Afaik, NetworkManager uses an external DHCP client and thus is not a
solution for the problemt hat ISC DHCP client is EOL.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Bug#995189: RFH: isc-dhcp

[Marc Haber]

On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans 
wrote:
>It's worth noting also that ISC's DHCP client, packaged as
>isc-dhcp-client from the isc-dhcp source package, is considered EOL
>upstream.

Same applies to the relay, doesn't it?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Bug#995189: RFH: isc-dhcp

[Vincent Blut]

Hi,

Le 2021-09-28 13:00, Marc Haber a écrit :
> On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri  wrote:
> >On Sep 28, Noah Meyerhans  wrote:
> >> For what it's worth, my preference would be transition to
> >> systemd-networkd with bookworm.
> >I think that a good default would be systemd-networkd for servers and 
> >NetworkManager for systems with Wi-Fi or a GUI.
> 
> Afaik, NetworkManager uses an external DHCP client and thus is not a
> solution for the problemt hat ISC DHCP client is EOL.

Starting with version 1.19.90-2, NetworkManager uses its internal DHCP client:

  * Demote isc-dhcp-client to Suggests.
The DHCP client now defaults to "internal". This default can be
overridden at run time by setting the main.dhcp option in the
configuration file. The old default was "dhclient" and required
isc-dhcp-client. (Closes: #933545)

> 
> Greetings
> Marc

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Bug#995189: RFH: isc-dhcp

[Michael Biebl]

Am 28.09.21 um 13:00 schrieb Marc Haber:

On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri  wrote:

On Sep 28, Noah Meyerhans  wrote:

For what it's worth, my preference would be transition to
systemd-networkd with bookworm.

I think that a good default would be systemd-networkd for servers and
NetworkManager for systems with Wi-Fi or a GUI.


Afaik, NetworkManager uses an external DHCP client and thus is not a
solution for the problemt hat ISC DHCP client is EOL.


Not quite. Quoting man NetworkManager.conf


   dhcp
   This key sets up what DHCP client NetworkManager will use. Allowed 
values are dhclient, dhcpcd, and internal. The
   dhclient and dhcpcd options require the indicated clients to be 
installed. The internal option uses a built-in DHCP
   client which is not currently as featureful as the external clients.

   If this key is missing, it defaults to internal. If the chosen 
plugin is not available, clients are looked for in this
   order: dhclient, dhcpcd, internal.


In Debian, we do compile in support for dhclient and internal.
For dhcpcd there is a stale bug report [1]. If someone is interested in 
that: I'd be ok in enabling support for dhcpcd if that someone adds an 
autopkgtest for that.



Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810151



OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug#995189: RFH: isc-dhcp

[Santiago Ruano Rincón]

El 28/09/21 a las 13:01, Marc Haber escribió:
> On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans 
> wrote:
> >It's worth noting also that ISC's DHCP client, packaged as
> >isc-dhcp-client from the isc-dhcp source package, is considered EOL
> >upstream.
> 
> Same applies to the relay, doesn't it?

Indeed. Just to give some references:

https://gitlab.isc.org/isc-projects/dhcp/:

  Please note that this project is in maintenance mode - we are not
  actively adding new functionality and may not respond to non-critical
  issues.

https://www.isc.org/dhcp/:

  ISC is developing a new DHCP server, Kea, which we intend to
  eventually replace ISC DHCP in most server implementations. We
  recommend that new implementers use Kea and implement ISC DHCP only if
  Kea does not meet their needs. The Kea distribution does not currently
  include either a client or a relay.

Regarding the server, I don't find very appealing to have to install a
relational DB along with the DHCP server.

About the client and server, if I am not wrong, about 3 years ago ISC
dhcp was the only implementation able to configure DHCPv6 clients by
their MAC addresses (thing that I needed at work). It is a pity that ISC
is giving less love to it. That said, the EOL date is still TBA
(https://www.isc.org/dhcp/)

  -- Santiago


signature.asc
Description: PGP signature

Bug#995243: ITP: linux-apfs-rw -- APFS module for linux, with experimental write support

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: linux-apfs-rw
  Version : 0+git20210928
  Upstream Authors: Ernesto A. Fernández 


Corellium LLC
* URL : https://github.com/linux-apfs/linux-apfs-rw
* License : GPL-2-only
  Description : APFS module for linux, with experimental write 
support
 The Apple File System (APFS) is the copy-on-write filesystem currently 
used on
 all Apple devices. This module provides a degree of experimental 
support on

 Linux.
 .
 It's supposed to work with a range of kernel versions starting at 4.9 
or

 before, but only a few of those have actually been tested.

See for WIP: https://mentors.debian.net/package/linux-apfs-rw/

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 01:29 -05, Richard Laager:

> 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:
[...]

OTOH, netplan is just an abstraction above existing systems and does not
allow proper reconfiguration. ifupdown2 is also written in Python and
has an implementation of "ifreload -a" which just works.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#995246: ITP: apfsprogs -- Experimental APFS tools for Linux

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: apfsprogs
  Version : 0+git20210928
  Upstream Authors: Ernesto A. Fernández 


* URL : https://github.com/linux-apfs/apfsprogs
* License : GPL-2-or-later
  Description : Experimental APFS tools for Linux
 This is a suite of userland software to work with the Apple File System 
on
 Linux. For now only mkfs and fsck tools are available, both functional 
but
 lacking in features. Compatibility with the Apple implementations has 
barely

 been tested; please exercise caution.

See for WIP: https://mentors.debian.net/package/apfsprogs/

Re: Bug#995189: RFH: isc-dhcp

[Richard Laager]

On 9/28/21 8:44 AM, Vincent Bernat wrote:

  ❦ 28 September 2021 01:29 -05, Richard Laager:


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:

[...]

OTOH, netplan is just an abstraction above existing systems


Agreed.


and does not
allow proper reconfiguration.

What do you mean?

--
Richard

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 11:16 -05, Richard Laager:

>>> 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:
>> [...]
>> OTOH, netplan is just an abstraction above existing systems
>
> Agreed.
>
>> and does not
>> allow proper reconfiguration.
> What do you mean?

Make a change, reload your configuration, everything breaks. 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.

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.
-- 
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain

Re: Bug#995189: RFH: isc-dhcp

[Richard Laager]

On 9/28/21 11:49 AM, Vincent Bernat wrote:

  ❦ 28 September 2021 11:16 -05, Richard Laager:


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:

[...]
OTOH, netplan is just an abstraction above existing systems


Agreed.


and does not
allow proper reconfiguration.

What do you mean?


Make a change, reload your configuration, everything breaks.


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.



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?



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)?


Can you articulate why ifupdown2 is better than e.g. systemd-networkd + 
netplan? I'm not looking for an exhaustive comparison or anything, but 
just a brief statement or two if you're willing?


I've never used it, and if it's better than systemd-networkd + netplan, 
I might consider switching.


--
Richard

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 13:04 -05, Richard Laager:

> 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.

I am saying: remove the IP address from an interface, move it to a VLAN
instead. You'll get a duplicate IP.

>> 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.
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)

Re: partman, growlight, discoverable partitions, and fun

[Steve McIntyre]

Hi Nick!

On Tue, Sep 28, 2021 at 12:47:11PM +0200, Cyril Brulebois wrote:
>Hi nick,
>
>[ cc += debian-boot@ ]
>
>nick black  (2021-09-27):
>> Marc Haber left as an exercise for the reader:
>> > But maybe an alternative? I find the partitioning step one of the
>> > most error-prone and hard-to-use parts of non-trivial Debian
>> > installations.
>> 
>> so overall, i've got to say the feedback i heard here was a lot more
>> positive than i was expecting, though there was a bit less than i had
>> hoped for. but perhaps something that can be touched would see more
>> interest?
>
>FWIW I've followed the answers to your mail over the last few days,
>but I haven't had a chance to look at either the video or the slides
>(only 4 days before your initial mail and the one I'm replying to…).

Amen to that!

>At first glance, it seems fine to be experimenting with a different
>partitioner; of course all people are somewhere on the love/hate
>spectrum regarding partman and the zillions of partman-* packages, but
>it's indeed a shell maze and it *probably* could use some heavy lifting.
>I keep hoping that simple use cases are made simple(r)… maybe growlight
>could help there (e.g. “I'd like soft RAID1 with encrypted LVM, all that
>with a UEFI boot — therefore ESP —, without being a storage wizard”).

ACK. I've done a *bit* of hacking around partman over the last few
years - it's heavy going and probably the least well understood part
of d-i... :-/

>I suppose some step (once you've experimented on a growlight-only
>d-i) would be to have both partman and growlight, and let people
>choose (maybe with a flag at boot time, or by entering expert mode or
>whatever), until we have a better idea what works, what doesn't, what
>can be fixed, what cannot, and until a decision is made for the next
>Debian stable release.
>
>Leaving the technical integration aside for a moment, one question
>that comes to mind is whether this would be a one-shot contribution or
>some kind of longer commitment to maintain that different partitioner.
>I seem to remember earlier attempts at revamping the partitioning
>step, which stalled eventually.
>
>(Your recent mail to debian-newmaint@ is a hint; your apparent
>steadiness of those packages maintenance-wise is another; and your
>apparent interest in adding support to possibly missing features yet
>another.)
>
>Of course, one might object that the question is moot as there isn't
>much active development on partman components (even if some patches have
>been submitted over the last few days), but at least that's a known
>(imperfect, but…) beast.

Nod!

>> given that no one seemed to reject the idea out of hand, i'm going to
>> go ahead and rebase my work from 2012 (or more likely look at it once
>> and redo it) in a Salsa fork of d-i, and make some installation media
>> available. forgive me for likely only having x86 available at first.
>> i'll try to have this done within a week or so, and put it up on my
>> server. people can then give it a whirl.
>
>Feel free to touch base with debian-boot@ and/or debian-cd@ once you
>have a working proof of concept that some people have toyed with; we can
>discuss how the “alternative” part could be implemented (different
>images, or both partitioners ship together, with some option/selection —
>people might remember GRUB vs. LILO). I cannot guarantee a timely answer
>(life tends to keep me busy), but you shouldn't see a lack of answer
>after just a few days as if people were not interested.

100% true - expect people are busy, rather than hostile! :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   https://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Re: partman, growlight, discoverable partitions, and fun

[nick black]

Steve McIntyre left as an exercise for the reader:
> 100% true - expect people are busy, rather than hostile! :-)

i must have come across as far more disappointed than i felt --
i meant "hoped" in the literal sense, of "did not expect, but
thought plausible and welcome" =]. no, this has been an A-, A
interaction in my book--i half-expected flat rejection.

so thanks, debian! i will return to my codehole and bring
back something more tangible. but i found this quite promising.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature