Re: ifupdown maintenance

[Marco d'Itri]

On Jul 09, Martin-Éric Racine  wrote:

> I just had a look at ifupdown-ng.  The /etc/network/interface syntax
> is not a drop-in replacement for ifupdown. That's a big no-no. Those
> "use dhcp" have to go.
Agreed: either it's drop-in compatible or we may as well switch the 
default to NM and/or systemd-networkd.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Daniel Gröber]

Hi Martin,

On Tue, Jul 09, 2024 at 09:26:50AM +0300, Martin-Éric Racine wrote:
> su 7. heinäk. 2024 klo 16.56 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> > For me the reason to work on ifupdown-ng is that it has a better core
> > design, clean&modern code, an active upstream community, a ***test suite***
> > and the potential to fully replace ifupdown without breaking anyone's
> > system doing it. Full compatibility is not there yet. I'm working on it,
> > see [1] but I'm optimistic so far.
> >
> > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
> 
> I just had a look at ifupdown-ng.  The /etc/network/interface syntax
> is not a drop-in replacement for ifupdown. That's a big no-no. Those
> "use dhcp" have to go.

Not reading the documentation carefully is a bigger no-no :)

For legacy configurations statements "use" is optional:

>   If the auto_executor_selection ifupdown-ng.conf option is enabled, use
>   statements will automatically be added for executors when their config‐
>   uration statements are present in the interfaces file.

The idea being that your config should declare the "executor" scripts it
needs, a good thing IMO.

That being said I'm sure there are a couple of dark corners where
ifupdown-ng is not yet compatible that I haven't noticed yet, but this
isn't one of them.

Please note that the examples in the manpages are in what upstream
considers the "proper new way" of doing things, they don't show the legacy
way (also a good thing), you may have to read the code to get the full
picture. Do let me know if any legacy-format behavioural
reference-documentation is missing though.

Since I only just realised people may now actually want to try out
ifupdown-ng: You can co-install it with traditional ifupdown with
--no-install-recommends, the ifupdown-ng-compat package is the one that
conflicts: ifupdown. ifupdown-ng itself doesn't.

Use ifup-ng/ifdown-ng, check dpkg -L for manpages some are named *-ng some
aren't. Executors have their own interfaces-* manpage eg. interfaces-bridge(5).

--Daniel


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Daniel Gröber]

Hi Santiago,

On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote:
> > > Santiago, how do you feel about ifupdown's future maintainability and
> > > feature development? I honestly never looked into why people started
> > > writing ifupdown replacements. I had my own gripes with it so I never
> > > questioned it but I'm happy to hear why we should all rally around it.
> > 
> > I've long wondered how we ended up with so many implementations. Team
> > maintenance of just one implementation would make more sense.
> > 
> > > For me the reason to work on ifupdown-ng is that it has a better core
> > > design, clean&modern code, an active upstream community, a ***test
> > > suite***
> 
> I fully acknowledge this. After trying to fix some of the ifupdown bugs
> but hitting some design issues, 

Can you elaborate on that point? What are the sort of issues you run into
with the traditional ifupdown design and/or it's maintenance.

> I think it makes more sense to focus all
> the efforts in just one of the implementations, and since ifupdown-ng
> has all the above mentioned advantages, I'd would be in favor of
> replacing ifupdown by ifupdown-ng...

Good to hear.

From the looks of the BTS page I feel like part of the burdon of
maintaining ifupdown is that people just default to reporting any
networking issues there, is that something you see a lot?

Perhaps we should have a debian-networking mailing list as Maintainer to be
able to load-share the user-support better?

> > > and the potential to fully replace ifupdown without breaking anyone's
> > > system doing it. Full compatibility is not there yet. I'm working on it,
> > > see [1] but I'm optimistic so far.
> > >
> > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
> > 
> > Noted.
> 
> ... but it would be *great* to make ifupdown-ng a drop-in replacement
> first.

Naturally.

It is pretty close though. The remaining issues I know about are documented
in the GH issue: the locking protocol is sligtly suboptimal (and more
importantly for interop: different), ifstate file is separate and interface
renaming ("rename" statanza) isn't supported. I didn't even know that last
one existed, does anyone use those?

If you're on-board with transitioning to -ng that should make the ifstate
compat pretty easy since we can freeze the old format and behaviour.

I haven't thrown -ng at a large legacy setup in anger yet (since I don't
have any), but for regular desktop usage with some mildly custom stuff in
/etc/network/interfaces I hardly notice which ifupdown* I have installed.

Note: For testing you have to keep in mind to (tranditional) ifdown the
ifaces you want to test first since the ifstate is still disjoint
currently.

> > > From where I'm sitting ifupdown2 is completely out of the question as
> > > *the* Debian ifupdown since it doesn't even support *basic* IPv6
> > > use-cases like DHCPv6. Upstream community seems nonexistant since
> > > this is software by a corp for a corp where community building was
> > > probably never the goal. Admittedly I didn't look very hard, this is
> > > just my impression currently.
> > 
> > That's also my impression.
> 
> and the python dependency makes me consider ifupdown2 as not an option.

Right, glad we're on the same page here.

--Daniel


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Phil Wyett]

On Sun, 2024-07-07 at 13:20 +0200, Joerg Jaspert wrote:
> On 17283 March 1977, Soren Stoutner wrote:
> 
> > P.S.  Based on Phil’s work on Mentors and my interactions with him, I 
> > have 
> > advocated for him to become a Debian Developer, uploading.  I think 
> > his 
> > contributions to Debian will be even more impactful when he can 
> > sponsor the 
> > packages he feels are ready.
> 
> It is only just July. He got rejected in May once - that's a bit too
> soon yet. (The usual time for a retry is somewhere around 6 month, and
> includes acknowleding (and working on) issues of the rejection).
> 
> Note that it is not only technical knowledge that is required. That's
> "just" part of it.
> 

Morning Joerg,

Thank you for your comments. Indeed, less than 24 hours later, I received an
email stating my Debian Developer (DD), with upload application was to be closed
and now has been.

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

--



signature.asc
Description: This is a digitally signed message part

Re: ifupdown maintenance

[Matthias Urlichs]

Hello,

Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.


Well, here's a heretical thought: why don't we do that anyway, at least 
for new installations?


Somebody could even write a converter. Shouldn't be that difficult, 
AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: default network management tools (was: ifupdown maintenance)

[Simon McVittie]

On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote:
> Agreed: either it's drop-in compatible or we may as well switch the
> default to NM and/or systemd-networkd.
> 
> Well, here's a heretical thought: why don't we do that anyway, at least for 
> new
> installations?

To some extent, we are already there: for new laptop/desktop
installations, NM is already the default (certainly true for GNOME,
and hopefully for most/all of the other tasksel-supported desktops).

For new server/embedded installations, I think networkd would be a
better default than ifupdown (I switched my servers from ifupdown to
networkd sometime between Debian 9 and 10, according to the etckeeper
logs). See my recent mail about how we should probably not be inventing
Debian-specific container frameworks that will end up with one overworked
maintainer being a single point of failure for the distribution, but
replace "container framework" with "network management tool" and the
same ideas are equally valid. Like Podman in the containers space, NM
and systemd-networkd both have the advantage of being used outside the
Debian bubble, sharing the responsibility for their continued existence
among *considerably* more people.

networkd seems like an entirely reasonable implementation of "make the
easy things easy" (/lib/systemd/network/80-ethernet.network.example
shows how to bring up DHCPv4 and DHCPv6 on every Ethernet device in 4
non-comment lines, without having to hard-code the name of any specific
device), which is the main thing we want from a default - I continue to
believe that defaults should be chosen to be appropriate for new users
without specialized requirements, because experienced users already
know how to apply different configuration if they want to, and users
with specialized requirements will have to apply special configuration
to achieve what they require whatever we do.

At the same time, networkd also has "make the hard things possible"
available in its configuration language (see man pages for details).

I'm sure that when ifupdown was written, having our own network management
tool was seen as a necessary part of providing an OS distribution
(in the same way that the Red Hat family historically had its own
framework based on /etc/sysconfig, and so on), but thankfully things
have changed since then, and we now have non-distro-specific network
management components that can do just as good a job (if not better). It
used to be the case that ifupdown could bring up many network interfaces
"statically" with no extraneous background processes, but available RAM
has grown by several orders of magnitude, and DHCP and modern wifi both
require long-running processes to supervise them *anyway*, making that
much less of an advantage.

Of course, there is nothing to stop anyone who is interested in it from
keeping non-default frameworks available, either Debian-specific or not -
if nothing else, users of non-systemd init systems are going to want an
alternative to networkd - but if those frameworks aren't load-bearing for
the distribution as a whole, then that will give their maintainers less
support burden and more freedom to experiment.

smcv

Re: ifupdown maintenance

[Bjørn Mork]

Matthias Urlichs  writes:

>> Agreed: either it's drop-in compatible or we may as well switch the
>> default to NM and/or systemd-networkd.
>
> Well, here's a heretical thought: why don't we do that anyway, at
> least for new installations?
>
> Somebody could even write a converter. Shouldn't be that difficult,
> AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.

Run user scripts on up/down events.  That's a huge blank spot in
systemd-networkd.  And by design, so it's really not fixable.

Sure, we do have networkd-dispatcher but it's not quite the same.  And
"Somebody" would have to do a really huge job to create a complete
automatic converter.  I don't think that's worth the effort.  But it's
of course up to "Somebody" to decide how they want to spend their
resources.


Bjørn

Bug#1076009: ITP: dysk -- Give information on mounted filesystems

[NoisyCoil]

Package: wnpp
Severity: wishlist
Owner: NoisyCoil 
X-Debbugs-Cc: debian-devel@lists.debian.org, noisyc...@tutanota.com

* Package name: dysk
  Version : 2.9.0
  Upstream Contact: Denys Séguret 
* URL : https://github.com/Canop/dysk
* License : MIT
  Programming Lang: Rust
  Description : Give information on mounted filesystems

Long description:
```
A command-line utility to get information on filesystems, like df
but better.

Previously known as lfs.
```

`dysk`, previously known as `lfs`, is one of the few tools written in Rust I 
always compile from source first-thing when I install a new system. It serves 
the same purpose as `df` - namely, listing mounted filesystems and their space 
usage (total size, space available, percentage of use, and so on) on the 
command line - but does so with a much nicer and more intuitive UI. 
Additionally, it can provide output in the JSON or CSV format.

`dysk` is currently distributed by distros such as Arch Linux, Manjaro, NixOS 
and openSUSE Tumbleweed, and Alpine (under the old name). I believe it would be 
a great addition to Debian. I plan to maintain it with the Rust Team in 
debcargo-conf.

Re: ifupdown maintenance

[Simon McVittie]

On Tue, 09 Jul 2024 at 12:27:58 +0200, Bjørn Mork wrote:
> Matthias Urlichs  writes:
> > Somebody could even write a converter. Shouldn't be that difficult,
> > AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.
> 
> Run user scripts on up/down events.  That's a huge blank spot in
> systemd-networkd.  And by design, so it's really not fixable.

If we were considering a migration from ifupdown to sd-networkd on
existing installations, then that would indeed be a reason not to do it
(without someone writing suitable mitigations, for example having the
converter pull in networkd-dispatcher if that's necessary and sufficient
in most cases).

I don't think this is a reason to avoid changing the default for new
installations, though. The purpose of a default is to have something that
does the right thing, reliably, for users who do not have specialized
requirements and do not necessarily know the necessary information to
make decisions like "which network management framework do I want?" yet.

I would tend to count "execute arbitrary user-supplied code on
networking changes" as a specialized requirement - by definition,
for this to happen, someone (the sysadmin) needs to have written and
installed the user-supplied hook script. If the sysadmin has made the
decision to do that, then they can equally well make the decision to
install networkd-dispatcher, or ifupdown{,-ng,2} or any other networking
management framework of their choice that supports the feature they need.

(Because non-trivial networking is dynamic and can be shared between
multiple components, and in practice this has been the case for years,
I would personally say that if you want arbitrary actions to happen
as a side-effect of networking state changes, a better way to achieve
that is for long-running processes to monitor the network interfaces
via e.g. netlink, and trigger those arbitrary actions whenever there is
a state change, regardless of whether the state change was initiated
by the ifupdown family, NM, networkd, Docker, libvirtd, VPN services, or
something else. But I realise opinions might vary.)

smcv

Re: ifupdown maintenance

[Martin-Éric Racine]

ti 9. heinäk. 2024 klo 11.58 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> On Tue, Jul 09, 2024 at 09:26:50AM +0300, Martin-Éric Racine wrote:
> > su 7. heinäk. 2024 klo 16.56 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> > > For me the reason to work on ifupdown-ng is that it has a better core
> > > design, clean&modern code, an active upstream community, a ***test 
> > > suite***
> > > and the potential to fully replace ifupdown without breaking anyone's
> > > system doing it. Full compatibility is not there yet. I'm working on it,
> > > see [1] but I'm optimistic so far.
> > >
> > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
> >
> > I just had a look at ifupdown-ng.  The /etc/network/interface syntax
> > is not a drop-in replacement for ifupdown. That's a big no-no. Those
> > "use dhcp" have to go.
>
> Not reading the documentation carefully is a bigger no-no :)
>
> For legacy configurations statements "use" is optional:
>
> >   If the auto_executor_selection ifupdown-ng.conf option is enabled, use
> >   statements will automatically be added for executors when their 
> > config‐
> >   uration statements are present in the interfaces file.

Which is not a drop-in substitute. It depends upon a configuratiomn option.

> The idea being that your config should declare the "executor" scripts it
> needs, a good thing IMO.

No.

> That being said I'm sure there are a couple of dark corners where
> ifupdown-ng is not yet compatible that I haven't noticed yet, but this
> isn't one of them.
>
> Please note that the examples in the manpages are in what upstream
> considers the "proper new way" of doing things, they don't show the legacy
> way (also a good thing), you may have to read the code to get the full
> picture. Do let me know if any legacy-format behavioural
> reference-documentation is missing though.

Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.

> Since I only just realised people may now actually want to try out
> ifupdown-ng: You can co-install it with traditional ifupdown with
> --no-install-recommends, the ifupdown-ng-compat package is the one that
> conflicts: ifupdown. ifupdown-ng itself doesn't.
>
> Use ifup-ng/ifdown-ng, check dpkg -L for manpages some are named *-ng some
> aren't. Executors have their own interfaces-* manpage eg. 
> interfaces-bridge(5).

Which again shows that this is not a drop-in substitute.

Martin-Éric

Re: ifupdown maintenance

[Daniel Gröber]

Hi Martin,

On Tue, Jul 09, 2024 at 02:25:02PM +0300, Martin-Éric Racine wrote:
> > > I just had a look at ifupdown-ng.  The /etc/network/interface syntax
> > > is not a drop-in replacement for ifupdown. That's a big no-no. Those
> > > "use dhcp" have to go.
> >
> > Not reading the documentation carefully is a bigger no-no :)
> >
> > For legacy configurations statements "use" is optional:
> >
> > >   If the auto_executor_selection ifupdown-ng.conf option is
> > >   enabled, use statements will automatically be added for
> > >   executors when their config‐ uration statements are present in
> > >   the interfaces file.
> 
> Which is not a drop-in substitute. It depends upon a configuratiomn option.

Which of course defaults to enabled in order to be compatible.

Users may choose to opt-in to the more declarative "use" stanzas if they
wish and I'd expect any new upstream executors like vrf will need them
(haven't tried) but not traditional stanzas or if-*.d based extensions.

I wish ifupdown-ng upstream hadn't chosen to introduce an additional set of
global config options in /etc/network/ifupdown-ng.conf and I am still
mulling getting rid of that somehow but so far I don't see a real problem
there.

> > Please note that the examples in the manpages are in what upstream
> > considers the "proper new way" of doing things, they don't show the legacy
> > way (also a good thing), you may have to read the code to get the full
> > picture. Do let me know if any legacy-format behavioural
> > reference-documentation is missing though.
> 
> Claiming to offer a drop-in substitute all while nudging people
> towards a new paradigm is not welcome.

If ifupdown's paradigm were working for people we wouldn't be having this
conversation.

I'm honestly not sure what the problem is? IMO ifupdown has a good basic
approach but some of the details of it's design are ... questionable by
todays standards.

How else would you move /etc/network/interfaces forward without breaking
anything?

> > Since I only just realised people may now actually want to try out
> > ifupdown-ng: You can co-install it with traditional ifupdown with
> > --no-install-recommends, the ifupdown-ng-compat package is the one that
> > conflicts: ifupdown. ifupdown-ng itself doesn't.
> >
> > Use ifup-ng/ifdown-ng, check dpkg -L for manpages some are named *-ng some
> > aren't. Executors have their own interfaces-* manpage eg. 
> > interfaces-bridge(5).
> 
> Which again shows that this is not a drop-in substitute.

Have you actually looked at the packaging? There are symlinks in the
ifupdown-ng-compat package to put things in the right places, but in order
to test that the two implementations actually behave the same it is
exceedingly convinient to have them co-installable.

We can all have bad days, so don't take this as an attack on your
character, but if this discussion is representative of the level of care
you put into your Debian work I'm not sure we're a good fit for
co-maintance, however I invite you to prove me wrong.

--Daniel


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Pierre-Elliott Bécue]

Hello,

Phil Wyett  wrote on 09/07/2024 at 11:40:32+0200:

> On Sun, 2024-07-07 at 13:20 +0200, Joerg Jaspert wrote:
>> On 17283 March 1977, Soren Stoutner wrote:
>> 
>> > P.S.  Based on Phil’s work on Mentors and my interactions with him, I 
>> > have 
>> > advocated for him to become a Debian Developer, uploading.  I think 
>> > his 
>> > contributions to Debian will be even more impactful when he can 
>> > sponsor the 
>> > packages he feels are ready.
>> 
>> It is only just July. He got rejected in May once - that's a bit too
>> soon yet. (The usual time for a retry is somewhere around 6 month, and
>> includes acknowleding (and working on) issues of the rejection).
>> 
>> Note that it is not only technical knowledge that is required. That's
>> "just" part of it.
>> 
>
> Morning Joerg,
>
> Thank you for your comments. Indeed, less than 24 hours later, I
> received an email stating my Debian Developer (DD), with upload
> application was to be closed and now has been.
>
> Regards

FTAOD I closed this process without interacting DAM or Joerg and not
having read his mail. I will reopen it as I stated to you when the
proper time comes.

I'm really happy that you're trying to work on making mentors.d.n more
proficient and active, and I'm also happy that you didn't get
demotivated by the different exchanges we collectively had in the past.

As Joerg stated, we'll probably need to have a chat about the reasons
that led to the initial rejection and your thoughts on the whole
thing. That being said, I won't go into details publicly and I do hope
that you'll indeed come back to us in a few months so we can try going
forward.

In the meantime, I'd like to express my gratitude for your commitment.

Bests,
-- 
PEB


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Phil Wyett]

On Tue, 2024-07-09 at 14:23 +0200, Pierre-Elliott Bécue wrote:
> Hello,
> 
> Phil Wyett  wrote on 09/07/2024 at 11:40:32+0200:
> 
> > On Sun, 2024-07-07 at 13:20 +0200, Joerg Jaspert wrote:
> > > On 17283 March 1977, Soren Stoutner wrote:
> > > 
> > > > P.S.  Based on Phil’s work on Mentors and my interactions with him, I 
> > > > have 
> > > > advocated for him to become a Debian Developer, uploading.  I think 
> > > > his 
> > > > contributions to Debian will be even more impactful when he can 
> > > > sponsor the 
> > > > packages he feels are ready.
> > > 
> > > It is only just July. He got rejected in May once - that's a bit too
> > > soon yet. (The usual time for a retry is somewhere around 6 month, and
> > > includes acknowleding (and working on) issues of the rejection).
> > > 
> > > Note that it is not only technical knowledge that is required. That's
> > > "just" part of it.
> > > 
> > 
> > Morning Joerg,
> > 
> > Thank you for your comments. Indeed, less than 24 hours later, I
> > received an email stating my Debian Developer (DD), with upload
> > application was to be closed and now has been.
> > 
> > Regards
> 
> FTAOD I closed this process without interacting DAM or Joerg and not
> having read his mail. I will reopen it as I stated to you when the
> proper time comes.
> 
> I'm really happy that you're trying to work on making mentors.d.n more
> proficient and active, and I'm also happy that you didn't get
> demotivated by the different exchanges we collectively had in the past.
> 
> As Joerg stated, we'll probably need to have a chat about the reasons
> that led to the initial rejection and your thoughts on the whole
> thing. That being said, I won't go into details publicly and I do hope
> that you'll indeed come back to us in a few months so we can try going
> forward.
> 
> In the meantime, I'd like to express my gratitude for your commitment.
> 
> Bests,

Afternoon,

There will be no seeking to reopen the application.

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

--



signature.asc
Description: This is a digitally signed message part

Re: ifupdown maintenance

[Simon Richter]

Hi,

On 7/9/24 17:57, Matthias Urlichs wrote:


Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.


Well, here's a heretical thought: why don't we do that anyway, at least 
for new installations?


Both are overly complex for a static-IP-only server installation, where 
there is no requirement for an unprivileged user to modify the network 
configuration, or any background process at all, really. At least in 
expert mode I would expect a way to generate a static, 
unmanaged-by-anything configuration.


What would be needed for new installations is d-i support, mainly, and 
the difficulty there is saving the configuration.


I believe NM does not have a fixed configuration format, but only a dbus 
API. Our best bet there would be a firstboot unit, but I have no idea 
whether accessing NM from a unit attached to firstboot is safe or leads 
to a dependency loop[1].


I'm not sure if systemd-networkd is much happier long-term if we write 
its configuration from a shell script, we'd need to get some commitment 
from upstream that this is an interface, not an implementation detail, 
at least.


Or we accept the UX regression of having to configure the network again 
on the first graphical login, when per-user credential stores are 
available through the appropriate services.


   Simon

[1] there should really be documentation in Policy what dependencies are 
allowed.

Re: ifupdown maintenance

[Luca Boccassi]

On Tue, 9 Jul 2024 at 14:44, Simon Richter  wrote:
>
> Hi,
>
> On 7/9/24 17:57, Matthias Urlichs wrote:
>
> >> Agreed: either it's drop-in compatible or we may as well switch the
> >> default to NM and/or systemd-networkd.
>
> > Well, here's a heretical thought: why don't we do that anyway, at least
> > for new installations?
>
> Both are overly complex for a static-IP-only server installation, where
> there is no requirement for an unprivileged user to modify the network
> configuration, or any background process at all, really. At least in
> expert mode I would expect a way to generate a static,
> unmanaged-by-anything configuration.

As per smcv's point, if you need to manually write a static
configuration then you can also install your favourite tool to use it.
This is not the default case - the default case is "I have ethernet
and/or wifi and I want DHCP v4+v6 on anything that can talk to a
router kkthxbye"

> What would be needed for new installations is d-i support, mainly, and
> the difficulty there is saving the configuration.
>
> I believe NM does not have a fixed configuration format, but only a dbus
> API. Our best bet there would be a firstboot unit, but I have no idea
> whether accessing NM from a unit attached to firstboot is safe or leads
> to a dependency loop[1].
>
> I'm not sure if systemd-networkd is much happier long-term if we write
> its configuration from a shell script, we'd need to get some commitment
> from upstream that this is an interface, not an implementation detail,
> at least.

I'm not sure what this means, you can write networkd configuration
files from wherever you like, the tool doesn't care, it wouldn't even
be able to tell the difference anyway, just drop them in the
appropriate location in /etc/ and off you go.

Re: ifupdown maintenance

[Ansgar 🙀]

Hi Simon,

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

> Our best bet there would be a firstboot unit, but I have no idea
> whether accessing NM from a unit attached to firstboot is safe or leads 
> to a dependency loop[1].

So this is not required and seems overly complicated.

> I'm not sure if systemd-networkd is much happier long-term if we write 
> its configuration from a shell script, we'd need to get some commitment 
> from upstream that this is an interface, not an implementation detail, 
> at least.

This seems similar to writing .service units via a shell script (or
manually) which doesn't seem to be a problem.

Or similar to writing /etc/network/interfaces: are we really sure this
is safe long-term? We probably should not bet on that!

Ansgar

Re: ifupdown maintenance

[Simon McVittie]

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.

 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.

smcv

Re: ifupdown maintenance

[Matthias Urlichs]

On 09.07.24 12:27, Bjørn Mork wrote:

Run user scripts on up/down events.  That's a huge blank spot in
systemd-networkd.  And by design, so it's really not fixable.


Well, I've been apt-purging ifupdown for almost a decade by now and 
didn't yet miss any of it.



You can think whether that script is still required; maybe 
systemd-networkd / -resolved can do it for you.


Or you can monitor systemd's and systemd-networkd's dbus for network 
devices appearing (or vanishing) and run the requisite script.


Or you can use udev rules.

Or you can tell a unit to run only when a specific network interface is 
present.


Or you can use NM and its script dispatcher instead.

Or, well, you can of course continue to use ifupdown if none of the 
above work for you. But that doesn't mean ifupdown should be the default 
IMHO.


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076037: ITP: mozjs128 -- SpiderMonkey JavaScript library

[Jeremy Bícha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
Control: affects -1 src:mozjs128
Owner: jeremy.bi...@canonical.com

Package Name: mozjs128
Version: 128.0.0
Upstream Author: Mozilla etc
License: mostly MPL-2.0, other files are licensed under other open
source licenses
Programming Lang: C++

Description: SpiderMonkey JavaScript library
 SpiderMonkey is the code-name for Mozilla Firefox's C++ implementation of
 JavaScript. It is intended to be embedded in other applications
 that provide host environments for JavaScript.
 .
 This library is intended for use in contexts where only trusted
 JavaScript code will be run, such as GNOME's gjs, Cinnamon's cjs, and
 polkit's rules parsing. It should not be used to run untrusted JavaScript
 from web pages: use a security-supported implementation such as Firefox,
 Chrome or WebKitGTK's JavaScriptCore instead.

Other Info
--
mozjs is the JavaScript engine from Firefox ESR. Today, a new Firefox
ESR series was released. It will be supported by Mozilla for about 14
months.

It is likely but not yet certain that GNOME 47, specifically gjs 1.82,
will switch from mozjs115 to mozjs128. If that happens, the next major
release of Debian (Debian 13 "Trixie") will include mozjs128.

The other user of mozjs* in Debian is Cinnamon, specifically their cjs
fork of gjs. Based on previous history, it is expected that cjs will
continue to use mozjs115 for Debian 13.

mozjs102 will be removed from Debian Unstable once cjs 6.2 reaches
Unstable which is expected to happen "soon".

References
--
https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/936
https://whattrainisitnow.com/calendar/

Thanks,
Jeremy Bícha

Re: ifupdown maintenance

[Simon Richter]

Hi,

On 7/9/24 23:01, Luca Boccassi wrote:


As per smcv's point, if you need to manually write a static
configuration then you can also install your favourite tool to use it.
This is not the default case - the default case is "I have ethernet
and/or wifi and I want DHCP v4+v6 on anything that can talk to a
router kkthxbye"


For a server installation, I absolutely need the option to configure a 
static IP from d-i text mode interface or a preseed file, and this 
configuration to be taken over into the installed system.


The last three machines I've installed I've used the IPMI console to set 
up the IP address, then used the "continue installation via ssh" 
function to do the main installation.


On one of these networks was a rogue DHCP server. :P


I'm not sure if systemd-networkd is much happier long-term if we write
its configuration from a shell script, we'd need to get some commitment
from upstream that this is an interface, not an implementation detail,
at least.



I'm not sure what this means, you can write networkd configuration
files from wherever you like, the tool doesn't care, it wouldn't even
be able to tell the difference anyway, just drop them in the
appropriate location in /etc/ and off you go.


That's my question, essentially: is this an interface with full support 
from upstream, or something that may change in an incompatible way later 
that will require us to deploy additional infrastructure to support?


The key feature of both sysvinit and ifupdown, from Debian's 
perspective, has always been control: with sysvinit, there were no 
"upstream" definitions, it was all defined by us as part of Debian 
Policy, and if we needed to change anything, we could do that without 
introducing an incompatibility; with ifupdown, we are also upstream, and 
therefore upstream is aware that if they want to change the 
configuration file format, they have to talk to all the other 
stakeholders inside the project and coordinate that change.


With systemd, we no longer have that level of control and large parts of 
Policy are now defined externally, and on an external schedule that does 
not match our release schedule. That is not necessarily a bad thing, but 
it is a huge deviation from our slow but reliable processes of the past 
where we could delay a change until it was ready for release.


So we need to weigh all the benefits of switching to systemd-networkd 
against the drawback that we are again tying part of our system to an 
externally defined release schedule, so we will need to nominate someone 
who will be responsible for integrating any changes that will be 
required as a result of upstream changes in a timely manner, and in a 
way that does not introduce any more technical debt.


The issue is not whether we can hack together a perl script *now*, but 
how big of a commitment that change can potentially be. If we can get a 
guarantee that any changes to that interface will be communicated two 
years in advance, that calculation is entirely different than when it 
can change with any upstream release and we need to provide an upgrade 
path with the next backport package or risk breaking "stable" systems 
that for some reason have backports of core system packages installed.


I fully expect some breaking changes, as we are storing the WiFi 
credentials into a configuration file, when they should be stored in 
some secrets manager -- so this is already "legacy", and I'm not sure if 
it is a "legacy interface" or a "legacy implementation detail."


   Simon

Re: ifupdown maintenance

[Bjørn Mork]

Matthias Urlichs  writes:
> On 09.07.24 12:27, Bjørn Mork wrote:
>> Run user scripts on up/down events.  That's a huge blank spot in
>> systemd-networkd.  And by design, so it's really not fixable.
>
> Well, I've been apt-purging ifupdown for almost a decade by now and
> didn't yet miss any of it.
>
>
> You can think whether that script is still required; maybe
> systemd-networkd / -resolved can do it for you.
>
> Or you can monitor systemd's and systemd-networkd's dbus for network
> devices appearing (or vanishing) and run the requisite script.
>
> Or you can use udev rules.
>
> Or you can tell a unit to run only when a specific network interface
> is present.
>
> Or you can use NM and its script dispatcher instead.
>
> Or, well, you can of course continue to use ifupdown if none of the
> above work for you. But that doesn't mean ifupdown should be the
> default IMHO.

FWIW, I agree with all that.

Just tried to point out that automatic conversion will be hard.  And
probably not very useful. Many of the old ifupdown configs should be
redone and re-thought rather than reimplemented.  There are most likely
better ways to do much of it, using the new possibilities you get with
NM and systemd-networkd.



Bjørn

Re: ifupdown maintenance

[Marco d'Itri]

On Jul 09, Simon Richter  wrote:

> For a server installation, I absolutely need the option to configure a
> static IP from d-i text mode interface or a preseed file, and this
> configuration to be taken over into the installed system.
I do not understand why you are explaining this as if it were some 
unusual requirement: it is quite common and indeed you can easily do it 
with both NM and systemd-networkd.

> That's my question, essentially: is this an interface with full support from
> upstream, or something that may change in an incompatible way later that
> will require us to deploy additional infrastructure to support?
Multiple people, one of the systemd upstream maintainers among them, 
already told you that creating configuration files is a normal and fully 
supported interface.

> The key feature of both sysvinit and ifupdown, from Debian's perspective,
> has always been control: with sysvinit, there were no "upstream"
> definitions, it was all defined by us as part of Debian Policy, and if we
What you mean is that it has always been that they were basically 
abandoned upstream so there were no new features were coming that way 
and we had to implement in Debian everything that we needed.

> So we need to weigh all the benefits of switching to systemd-networkd
> against the drawback that we are again tying part of our system to an
> externally defined release schedule, so we will need to nominate someone who
But we switched to NM for Wi-Fi enabled systems and the sky has not 
fallen yet.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown maintenance

[Marco d'Itri]

On Jul 09, Bjørn Mork  wrote:

> Just tried to point out that automatic conversion will be hard.  And
And I believe that nobody argued to do that.

-- 
ciao,
Marco


signature.asc
Description: PGP signature