Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On 07/04/2022 23:48, Jason A. Donenfeld wrote: A few conversations over the course of the day in an IRC channel isn't necessarily representative of the whole project, but the impression I got was way less so about hostility and more so just that nobody has gotten around to doing the work and tracking whatever bugs come out of it that need to be fixed. It's been started, but seems to have fizzled. Maybe the recent discussion here and funny happenings over in Debian will inject some life into it. So maybe we'll wind up with merged usr after all. No promises, but I think it's much more a matter of "when" than "if". (My personal 2¢ is that I'd be happy to see systemd help corral us stragglers into merged usr, and in the process, drop some complexity of its own for supporting unmerged usr.) I don't really have a horse in that race, I'm just left with the strong feeling that there are people who are strongly anti-systemd, and there are people who are pro-systemd, but what's important is THEY RESPECT EACH OTHER. It's just that the anti-systemd guys are in the majority, and it shows. (Funtoo left me with a very nasty taste, best described as "you always see in others, your own worst faults" :-( Cheers, Wol
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
Hi Wol, On Fri, Apr 8, 2022 at 12:02 AM Wol wrote: > > On 07/04/2022 17:47, Mike Gilbert wrote: > >> So, my guess would be that the people who dislike merged-/usr are also > >> the ones who dislike systemd, no? i.e. do they really matter if we are > >> talking about what to support in systemd? They'd not use our stuff > >> anyway, so why bother? > > There's probably also a big minority of users (like me) who may be > pro-systemd, but run a systemd-hostile distro for reasons that are > nothing to do with systemd ... > > > There's probably a large overlap between users who don't like systemd > > and users who don't like merged-/usr. I would guess we don't have a > > critical mass of users/developers running systemd. > > > > I could probably force the users who do run systemd to migrate to > > merged-/usr, but I don't really see much benefit from that if all > > other packages in Gentoo still need to support both configurations. > > And I'm sorry if I upset Mike, but I class gentoo as systemd-hostile. > It's MUCH easier to install/run Gentoo with OpenRC, systemd isn't that > well documented (it's better than it was). There are people who support > systemd, but I get the impression it's seen as an unwanted rival to OpenRC. I was actually just talking about merged usr with some people in #gentoo-dev the other day. I was at first wondering, "hey have we done this? what's the hold up?" And the answer seemed to be that nobody has really got around to it, and there's not currently a huge champion of the project moving it forward. Somebody piped up kind of mildly opposed, and then I explained what the general vision for merged usr is (hermetic OS in /usr and such), and felt like the reception to that was actually somewhat welcoming. Later I posted a link to Lennart's latest blog post, and people seemed to think it was cool. Somebody mentioned they were going to try out merged usr on Gentoo to see what happened, and another person mentioned they were the author of a blog post tutorial on how to do it. A few conversations over the course of the day in an IRC channel isn't necessarily representative of the whole project, but the impression I got was way less so about hostility and more so just that nobody has gotten around to doing the work and tracking whatever bugs come out of it that need to be fixed. It's been started, but seems to have fizzled. Maybe the recent discussion here and funny happenings over in Debian will inject some life into it. So maybe we'll wind up with merged usr after all. No promises, but I think it's much more a matter of "when" than "if". (My personal 2¢ is that I'd be happy to see systemd help corral us stragglers into merged usr, and in the process, drop some complexity of its own for supporting unmerged usr.) Jason
Re: [systemd-devel] Samba Config Reload
--On Thursday, April 07, 2022 12:30 PM +0200 Lennart Poettering wrote: The other two options are likely similar, i.e. synchronous and talk to smbd directly. But I don't know samba that well, so it's just an assumption. In fact, if ExecStop= in smbd.service just calls the smbcontrol they behave very very similar. FWIW, here's the unit file from samba-4.10.16-13 in CentOS 7.9: [Unit] Description=Samba SMB Daemon Documentation=man:smbd(8) man:samba(7) man:smb.conf(5) Wants=network-online.target After=network.target network-online.target nmb.service winbind.service [Service] Type=notify NotifyAccess=all PIDFile=/run/smbd.pid LimitNOFILE=16384 EnvironmentFile=-/etc/sysconfig/samba ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS ExecReload=/bin/kill -HUP $MAINPID LimitCORE=infinity Environment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba [Install] WantedBy=multi-user.target
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On 07/04/2022 17:47, Mike Gilbert wrote: So, my guess would be that the people who dislike merged-/usr are also the ones who dislike systemd, no? i.e. do they really matter if we are talking about what to support in systemd? They'd not use our stuff anyway, so why bother? There's probably also a big minority of users (like me) who may be pro-systemd, but run a systemd-hostile distro for reasons that are nothing to do with systemd ... There's probably a large overlap between users who don't like systemd and users who don't like merged-/usr. I would guess we don't have a critical mass of users/developers running systemd. I could probably force the users who do run systemd to migrate to merged-/usr, but I don't really see much benefit from that if all other packages in Gentoo still need to support both configurations. And I'm sorry if I upset Mike, but I class gentoo as systemd-hostile. It's MUCH easier to install/run Gentoo with OpenRC, systemd isn't that well documented (it's better than it was). There are people who support systemd, but I get the impression it's seen as an unwanted rival to OpenRC. But there's not much choice out there for systemd-friendly source-based distros. Funtoo is openly anti-systemd. Sourceror (which I plan to play with) seems not to be that successful - looks like there are few users beyond the core developers ... and that feels like it's one of the better ones ... Cheers, Wol
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On Thu, Apr 7, 2022 at 5:18 AM Luca Boccassi wrote: > > On Thu, 2022-04-07 at 10:59 +0200, Lennart Poettering wrote: > > On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote: > > > > > We are not likely to require merging of / and /usr for the foreseeable > > > future. We are a "rolling release" distro and basically never require > > > our users to re-install, which makes large file system migrations > > > difficult. Also, many of our users would resist any attempt to force > > > merged-/usr on them. > > > > So, my guess would be that the people who dislike merged-/usr are also > > the ones who dislike systemd, no? i.e. do they really matter if we are > > talking about what to support in systemd? They'd not use our stuff > > anyway, so why bother? > > > > > I think it would be ok if systemd drops support for installing itself > > > in /lib/systemd; we would just move everything under /usr/lib/systemd, > > > and possibly set up some symlinks in /lib/systemd for the > > > transition. > > > > You guys are making your life hell, because you are afraid if making > > it difficult... > > > > Lennart > > And regarding re-installing, Ubuntu and Debian are doing the transition > on the live filesystem, no reinstall required (I think other distros > did the same). You can find the script that does it in this repository: > https://salsa.debian.org/md/usrmerge apart from details about multi- > arch lib directories, it should be adaptable to other distributions. Thanks for the link!
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On Thu, Apr 7, 2022 at 4:59 AM Lennart Poettering wrote: > > On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote: > > > We are not likely to require merging of / and /usr for the foreseeable > > future. We are a "rolling release" distro and basically never require > > our users to re-install, which makes large file system migrations > > difficult. Also, many of our users would resist any attempt to force > > merged-/usr on them. > > So, my guess would be that the people who dislike merged-/usr are also > the ones who dislike systemd, no? i.e. do they really matter if we are > talking about what to support in systemd? They'd not use our stuff > anyway, so why bother? There's probably a large overlap between users who don't like systemd and users who don't like merged-/usr. I would guess we don't have a critical mass of users/developers running systemd. I could probably force the users who do run systemd to migrate to merged-/usr, but I don't really see much benefit from that if all other packages in Gentoo still need to support both configurations.
Re: [systemd-devel] all numeric usernames not allowed in systemd (version 245 onward)
On Do, 07.04.22 16:37, Nikhil Kshirsagar (nkshirsa...@gmail.com) wrote: > While I completely understand the motivation to do this, my concern is that > this change will break logins for users on a lot of servers that upgrade to > the new systemd. Well, it breaks anyway, since numeric user names are ambiguous. i.e. if you allow this, then the question is if user "0" actually is the user with UID 0, or the one with the literal user name "0". > Is there any chance systemd could support a configuration option in the > future to get the earlier "all numeric" user logins to work? With an > understanding that it would be at the users own risk? I already told you clearly: no. > Are there any pam_systemd configuration options under consideration that > might help anyone looking for such functionality? Or is the only option > "not to upgrade" for someone interested in preserving their all numeric > usernames? No. Sorry. Migrate away from such usernames. It cannot work. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] all numeric usernames not allowed in systemd (version 245 onward)
On Thu, Apr 07, 2022 at 04:37:48PM +0530, Nikhil Kshirsagar wrote: > Is there any chance systemd could support a configuration option in the > future to get the earlier "all numeric" user logins to work? With an > understanding that it would be at the users own risk? No. > Are there any pam_systemd configuration options under consideration that > might help anyone looking for such functionality? Or is the only option > "not to upgrade" for someone interested in preserving their all numeric > usernames? Not upgrading is one option, renaming the users before or after the upgrade are the other options. Zbyszek
[systemd-devel] all numeric usernames not allowed in systemd (version 245 onward)
Hello, I gather from the discussion on https://github.com/systemd/systemd/issues/15141 that all numeric usernames would no longer be supported on servers running systemd version 245 onward. This was also reiterated by Frantisek and Lennart (thank you for your email responses and for redirecting me to this mailing list.) While I completely understand the motivation to do this, my concern is that this change will break logins for users on a lot of servers that upgrade to the new systemd. Is there any chance systemd could support a configuration option in the future to get the earlier "all numeric" user logins to work? With an understanding that it would be at the users own risk? Are there any pam_systemd configuration options under consideration that might help anyone looking for such functionality? Or is the only option "not to upgrade" for someone interested in preserving their all numeric usernames? Regards, Nikhil.
Re: [systemd-devel] Antw: [EXT] Dropping split-usr/unmerged-usr support
On Wed, 2022-04-06 at 08:39 -0400, Neal Gompa wrote:
> On Wed, Apr 6, 2022 at 8:07 AM Luca Boccassi wrote:
> >
> > On Wed, 2022-04-06 at 06:51 -0400, Neal Gompa wrote:
> > > On Wed, Apr 6, 2022 at 6:45 AM Luca Boccassi
> > > wrote:
> > > >
> > > > On Wed, 2022-04-06 at 08:05 +0200, Ulrich Windl wrote:
> > > > > > > > Luca Boccassi schrieb am 05.04.2022
> > > > > > > > um 22:07 in
> > > > > Nachricht <05cf10d04274dcbff07fed88e98dca2eebb24b7d.ca...@gmail.com>:
> > > > > > Hi,
> > > > > >
> > > > > > As part of our spring cleaning effort, we are considering when to
> > > > > > drop
> > > > > > support for split/unmerged-usr filesystem layouts.
> > > > > >
> > > > > > A build-time warning was added last year:
> > > > > >
> > > > > > https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd
> > > > > > 954469
> > > > >
> > > > > Honestly to me the requirement that /usr be part of the root
> > > > > filesystem never had a reasonable argument.
> > > > > Instead I think systemd quit the concept of a simple scaled-down
> > > > > subset to bring up the system.
> > > > > Also with initrd/dracut the concept is even more odd, because the
> > > > > /usr found there is just some arbitrary subset of the real /usr
> > > > > (similar for other filesystems).
> > > > > So why couldn't that work with a really scaled-down /sbin?
> > > > >
> > > > > >
> > > > > > We are now adding a runtime taint as well.
> > > > > >
> > > > > > Which distributions are left running with systemd on a
> > > > > > split/unmerged-
> > > > > > usr system?
> > > > > >
> > > > > > (reminder: we refer to a system that boots without a populated /usr
> > > > > > as
> > > > > > split-usr, and a system where bin, sbin and lib* are not symlinks
> > > > > > to
> > > > > > their counterparts under /usr as unmerged-usr)
> > > > >
> > > > > Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> > > > > IMHO.
> > > > >
> > > > > It seems systemd is the new Microsoft ("We know what is good for you;
> > > > > just accept it!") ;-)
> > > > >
> > > > > Regards,
> > > > > Ulrich
> > > >
> > > > Sorry, but you are about ~10 years late to this debate :-) The question
> > > > today is not whether it's good or bad, but who's left to do the switch.
> > > >
> > > > We know Fedora/RHEL/CentOS/SUSE/Arch/Ubuntu have done the switch, and
> > > > presumably any of their derivatives.
> > > >
> > > > We know Debian is, er, working on it, as per the most recent article on
> > > > LWN.
> > > >
> > >
> > > Debian is expected to complete this with Debian 12, I believe.
> >
> > Yeah it's, uhm, complicated :-) Working on it...
> >
> > > > What about other distros that are not derivatives of the aboves and
> > > > that use systemd? Does anybody have any insight?
> > > >
> > >
> > > OpenMandriva and Yocto both haven't done the switch yet, as far as I'm
> > > aware. Might be worth reaching out to them and finding out when
> > > they're going to do it.
> >
> > Thanks, I'm not familiar with OpenMandriva at all, is anyone here? Any
> > pointers on where to reach out to?
> >
>
> You could try filing an issue here:
> https://github.com/OpenMandrivaAssociation/distribution
>
> Alternatively, I believe Bernhard Rosenkraenzer (berolinux on GitHub)
> is someone to reach out to. He does a lot of OpenMandriva
> architectural work.
Thank you, opened an issue:
https://github.com/OpenMandrivaAssociation/distribution/issues/2792
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Re: [systemd-devel] Samba Config Reload
On Mi, 06.04.22 06:21, Yolo von BNANA (y...@bnana.de) wrote: > What is the best way to reload the Samba Configuration – and why? > > 1. systemctl reload smbd > 2. smbcontrol smbd reload-config > 3. pkill -HUP smbd > > I think it's this Order. (1 is best) > But I couldn't explain it to somebody else. I don't know what the "smbcontrol" thing precisely does. So your option 3 is by far the worst. it will kill any process called "smbd" with HUP, even if it has nothing to do with the system service. Moreover, you only want to send SIGHUP to the main daemon process usually, not any children it might have (that likely carry the same name). Moreover, the operation is async: i.e. the reload request is just enqueued and when pkill returns the reload might not even have started yet, let alone completed. THus if you immediately follow with another command, then the changes you made to smb.conf earlier (which I presume is the reason why you want to reload) might or might not have been applied. The other two options are likely similar, i.e. synchronous and talk to smbd directly. But I don't know samba that well, so it's just an assumption. In fact, if ExecStop= in smbd.service just calls the smbcontrol they behave very very similar. If you do things through systemctl it has the benefit that systemd knows about the reload, this is nice because this means systemd can merge multiple reload requests, and you have better state tracking and logs. So yes, the order is correct, i'd say. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On Thu, 2022-04-07 at 10:59 +0200, Lennart Poettering wrote: > On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote: > > > We are not likely to require merging of / and /usr for the foreseeable > > future. We are a "rolling release" distro and basically never require > > our users to re-install, which makes large file system migrations > > difficult. Also, many of our users would resist any attempt to force > > merged-/usr on them. > > So, my guess would be that the people who dislike merged-/usr are also > the ones who dislike systemd, no? i.e. do they really matter if we are > talking about what to support in systemd? They'd not use our stuff > anyway, so why bother? > > > I think it would be ok if systemd drops support for installing itself > > in /lib/systemd; we would just move everything under /usr/lib/systemd, > > and possibly set up some symlinks in /lib/systemd for the > > transition. > > You guys are making your life hell, because you are afraid if making > it difficult... > > Lennart And regarding re-installing, Ubuntu and Debian are doing the transition on the live filesystem, no reinstall required (I think other distros did the same). You can find the script that does it in this repository: https://salsa.debian.org/md/usrmerge apart from details about multi- arch lib directories, it should be adaptable to other distributions. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote: > We are not likely to require merging of / and /usr for the foreseeable > future. We are a "rolling release" distro and basically never require > our users to re-install, which makes large file system migrations > difficult. Also, many of our users would resist any attempt to force > merged-/usr on them. So, my guess would be that the people who dislike merged-/usr are also the ones who dislike systemd, no? i.e. do they really matter if we are talking about what to support in systemd? They'd not use our stuff anyway, so why bother? > I think it would be ok if systemd drops support for installing itself > in /lib/systemd; we would just move everything under /usr/lib/systemd, > and possibly set up some symlinks in /lib/systemd for the > transition. You guys are making your life hell, because you are afraid if making it difficult... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Antw: Re: Antw: [EXT] Dropping split-usr/unmerged-usr support
On Thu, Apr 7, 2022 at 3:45 AM Ulrich Windl
wrote:
>
> >>> Wols Lists schrieb am 06.04.2022 um 21:41 in
> Nachricht :
> > On 06/04/2022 10:34, Luca Boccassi wrote:
> >>> Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> >>> IMHO.
> >>>
> >>> It seems systemd is the new Microsoft ("We know what is good for you;
> >>> just accept it!");-)
> >
> > Well, I saw a link to WHY we have /bin, /usr/bin, /sbin etc. Interesting
> > read ...
> >
> > / was disk0. /usr was apparently originally short for /user, on disk1.
> > Then the system disk ran out of space, so they created /usr/bin to have
> > more space. So when they got a 3rd disk, they called it /home and moved
> > all the user directories across ...
>
> However space is not the only reason: Back in the times of non-journaling
> filesystems (and slow disks where a fsck could take 40 minutes or more) it
> was highly desirable to have a small root filesystem that could be checked
> quickly, to root had the chance to become active.
> Even today when something bad happens, one would probably prefer to have
> multiple smaller filesystems to repair rather than one "huge pot". MHO.
> Agreed Windows users who only know C: never wasted much thoughts on
> structure; see the mess in C:\Windows. But I thought UNIX was highly
> structured...
>
On the contrary, Windows has been much more organized than UNIX has
been. In the C:\ hierarchy, the "Windows" directory contains all the
resources to run Windows itself. System-wide applications are all in
"Program Files", and user data is in "Users". Those three directories
form the core of the Windows experience. There are obviously more
directories, but those three are essential for Windows itself. And if
you don't need any applications (just the base Windows OS), then you
can get away with just C:\Windows.
UNIX, meanwhile, didn't have an opportunity to be thoughtful
about how the hierarchy worked. Things got stuffed in where they could
based on the size of diskettes and what could be held in memory. The
fact that /usr doesn't actually represent where user data is proves
it. "Unix System Resources" is a backronym to attempt to deal with the
mistake of not renaming the directory when it evolved away from
holding user data. The Unix hierarchy is *full* of mistakes and
post-rationalizations ideally would be fixed someday but probably
won't be.
--
真実はいつも一つ！/ Always, there's only one truth!
[systemd-devel] Antw: Re: Antw: [EXT] Dropping split-usr/unmerged-usr support
>>> Wols Lists schrieb am 06.04.2022 um 21:41 in
Nachricht :
> On 06/04/2022 10:34, Luca Boccassi wrote:
>>> Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
>>> IMHO.
>>>
>>> It seems systemd is the new Microsoft ("We know what is good for you;
>>> just accept it!");-)
>
> Well, I saw a link to WHY we have /bin, /usr/bin, /sbin etc. Interesting
> read ...
>
> / was disk0. /usr was apparently originally short for /user, on disk1.
> Then the system disk ran out of space, so they created /usr/bin to have
> more space. So when they got a 3rd disk, they called it /home and moved
> all the user directories across ...
However space is not the only reason: Back in the times of non-journaling
filesystems (and slow disks where a fsck could take 40 minutes or more) it was
highly desirable to have a small root filesystem that could be checked quickly,
to root had the chance to become active.
Even today when something bad happens, one would probably prefer to have
multiple smaller filesystems to repair rather than one "huge pot". MHO.
Agreed Windows users who only know C: never wasted much thoughts on structure;
see the mess in C:\Windows. But I thought UNIX was highly structured...
Regards,
Ulrich
>>>
>>> Regards,
>>> Ulrich
>> Sorry, but you are about ~10 years late to this debate:-) The question
>> today is not whether it's good or bad, but who's left to do the switch.
>>
>> We know Fedora/RHEL/CentOS/SUSE/Arch/Ubuntu have done the switch, and
>> presumably any of their derivatives.
>>
>> We know Debian is, er, working on it, as per the most recent article on
>> LWN.
>>
>> What about other distros that are not derivatives of the aboves and
>> that use systemd? Does anybody have any insight?
>
> gentoo defaults to OpenRC, but I'm running systemd. As far as I can tell
> I appear to have three distinct directories, /bin, /sbin, and /usr
>
> I also have a fourth and fifth distinct directory, /usr/bin and
> /usr/sbin. What if any plans there are to merge them I have no clue.
>
> Cheers,
> Wol
[systemd-devel] Antw: [EXT] Re: Dropping split-usr/unmerged-usr support
>>> Mike Gilbert schrieb am 06.04.2022 um 17:24 in
>>> Nachricht
:
> On Tue, Apr 5, 2022 at 4:07 PM Luca Boccassi wrote:
>>
>> Hi,
>>
>> As part of our spring cleaning effort, we are considering when to drop
>> support for split/unmerged-usr filesystem layouts.
>>
>> A build-time warning was added last year:
>>
>>
> https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd9
> 54469
>>
>> We are now adding a runtime taint as well.
>>
>> Which distributions are left running with systemd on a split/unmerged-
>> usr system?
>
> Gentoo still supports having /{bin,sbin,lib} and /usr/{bin,sbin,lib}
> as separate directories. We do not support officially booting without
> /usr mounted (via initramfs), but some users do it anyway.
>
> We are not likely to require merging of / and /usr for the foreseeable
> future. We are a "rolling release" distro and basically never require
> our users to re-install, which makes large file system migrations
> difficult. Also, many of our users would resist any attempt to force
> merged-/usr on them.
Well, many years ago HP-UX (I think it was around major version 9 or 10)
managed to migrate from /bin to /sbin and /usr/sbin (also from /usres/ to
/home) without reinstallation.
I always felt what systemd is demanding is a step back.
>
> I think it would be ok if systemd drops support for installing itself
> in /lib/systemd; we would just move everything under /usr/lib/systemd,
> and possibly set up some symlinks in /lib/systemd for the transition.
>
> We will still need to keep /bin and /sbin in PATH, and we can't assume
> that all binaries reside in /usr/bin.
What speaks for /sbin and /usr/sbin IMHO is the fact that the typical user did
not have them in the PATH, because those were mostly management commands a
normal user does not need.
Now we have a "huge pot" with everything in /usr/bin.
Regards,
Ulrich
