Re: [systemd-devel] vt220 default for serial console still relevant?

[Christopher Cox]

On 7/14/20 4:27 PM, Mantas Mikulėnas wrote:
On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer > wrote:


I just tried vt241 and didn't get colorized output in konsole. I looked
around a bit and it doesn't really seem supported at all by terminal
emulators (or at least none that I found). I also tried TERM=xterm-256color
with 8 different terminal emulators and got colors with all of them. My
workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds
console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That
connects my terminal emulator to the serial console of the vm. I then
execute "ls -l --color /" in the vm and get colored output every time in
whatever terminal emulator that I try.

I'm probably missing something but I'm wondering what an example terminal
emulator would be where xterm-256color would not work at all (even st worked
perfectly and that is supposed to be pretty barebones afaik). Or is it just
that color is a commonly supported subset of xterm and stuff breaks down
with other escape codes instead? Or maybe qemu is doing some kind of
translation that magically makes every TERM setting work in whatever
terminal emulator I try? Apologies if this seems ignorant, I have no
experience at all with this domain.


The basic formatting codes (bold, reverse, 8/16-color) are practically the same 
everywhere. In fact they're so widespread that many programs and scripts just 
straight up hardcode them. (xterm, st, etc. are supersets of vt220/vt421 in that 
regard.)


But 256-color or even 24-bit-color codes are not as widely supported. The Linux 
VT has only recently started *recognizing* them (though still maps them down to 
8 colors). If you use TERM=xterm-256color with Linux VT, apps can look really 
weird because you told them they can use these extended color codes even though 
they cannot.


Graphical terminal emulators recognize the "update status line" codes (which 
goes the X11 window titlebar) -- but the Linux VT has no such thing and the same 
code will just show up as garbage on screen.


Google tells me VT421 supported sixel graphics. I'm not sure if any programs 
make use of that nowadays, but if they do, then trying to use TERM=vt421 with a 
terminal that doesn't do sixel will result in more garbage on screen.


There are various other differences like this.


Boot up logs should target "dumb" terminal only.

So, in the case of boot logs (where we have no idea where messages are going), 
if you want "color", I'd use some kind of markup and allow to be interpreted by 
whatever is viewing that.


But with regards to logs presumably going to a terminal (real or virtual or 
whatever), I'd lean on terminfo and end user selection (which could be by TERM 
in the case of an established terminal).


And of course, if it's ok for Dell/HP/IBM to assume Hyperterminal (ansi, 80x25) 
for BIOS setup,etc via serial, maybe it's not too far a stretch for Linux to 
assume something.  But IMHO, if at all possible, I'd make this configurable and 
again, lean on terminfo.


Personally I like log data that is parseable.  And data with a gazillion escape 
sequences is very noisy to look at.  Perhaps another reason for some sort of 
simple markup instead of escape sequences (?).  Hey, our developers are 
constantly hard coding ansi-escapes into their log messages so they look 
"pretty" in very very specific viewers.  Not the way I'd handle it.





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vt220 default for serial console still relevant?

[Mantas Mikulėnas]

On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer 
wrote:

> I just tried vt241 and didn't get colorized output in konsole. I looked
> around a bit and it doesn't really seem supported at all by terminal
> emulators (or at least none that I found). I also tried TERM=xterm-256color
> with 8 different terminal emulators and got colors with all of them. My
> workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds
> console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That
> connects my terminal emulator to the serial console of the vm. I then
> execute "ls -l --color /" in the vm and get colored output every time in
> whatever terminal emulator that I try.
>
> I'm probably missing something but I'm wondering what an example terminal
> emulator would be where xterm-256color would not work at all (even st
> worked perfectly and that is supposed to be pretty barebones afaik). Or is
> it just that color is a commonly supported subset of xterm and stuff breaks
> down with other escape codes instead? Or maybe qemu is doing some kind of
> translation that magically makes every TERM setting work in whatever
> terminal emulator I try? Apologies if this seems ignorant, I have no
> experience at all with this domain.
>

The basic formatting codes (bold, reverse, 8/16-color) are practically the
same everywhere. In fact they're so widespread that many programs and
scripts just straight up hardcode them.  (xterm, st, etc. are supersets of
vt220/vt421 in that regard.)

But 256-color or even 24-bit-color codes are not as widely supported. The
Linux VT has only recently started *recognizing* them (though still maps
them down to 8 colors). If you use TERM=xterm-256color with Linux VT, apps
can look really weird because you told them they can use these extended
color codes even though they cannot.

Graphical terminal emulators recognize the "update status line" codes
(which goes the X11 window titlebar) -- but the Linux VT has no such thing
and the same code will just show up as garbage on screen.

Google tells me VT421 supported sixel graphics. I'm not sure if any
programs make use of that nowadays, but if they do, then trying to use
TERM=vt421 with a terminal that doesn't do sixel will result in more
garbage on screen.

There are various other differences like this.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vt220 default for serial console still relevant?

[Daan De Meyer]

> About your other comments, systemd sits in user space and can query
(depend
> upon) terminfo.  Then, it should be able to support "whatever" terminfo
has
> defined which could include custom terminals by the way that an end
user has
> added.  And while all of that sounds incredibly ancient/old, I was on a
project
> post 2000 that had to do exactly that (of course, even that might sound
too old).

Interestingly enough, systemd's colors work even when TERM is set to vt220,
probably because it uses ansi escape codes regardless of the TERM setting.
I think there's probably lots of applications doing this except for ls in
coreutils which has an explicit list of terminals with color support
encoded in the dircolors configuration file.  If TERM isn't one of those,
you don't get colors. There's probably others that do this as well. I don't
think changing the default in systemd is a good idea since it might break
other stuff. I'm going to submit a mkosi PR instead that adds an option
that overrides serial-getty@ttyS0 with whatever terminal the user wants.
Colors won't work out of the box but at least it shouldn't be too hard to
find out how to get them to work when using mkosi.

Thanks for all the info as well. It's always fun to read how stuff was done
back in the early days.

Daan

On Tue, 14 Jul 2020 at 21:04, Christopher Cox  wrote:

> On 7/14/20 1:48 PM, Daan De Meyer wrote:
> > I just tried vt241 and didn't get colorized output in konsole. I looked
> around a
> > bit and it doesn't really seem supported at all by terminal emulators
> (or at
> > least none that I found). I also tried TERM=xterm-256color with 8
> different
> > terminal emulators and got colors with all of them. My workflow is
> simply "mkosi
> > qemu -nographic" (with a modified mkosi that adds console=ttyS0 and
> overrides
> > TERM for serial-getty@ttyS0 in the vm)." That connects my terminal
> emulator to
> > the serial console of the vm. I then execute "ls -l --color /" in the vm
> and get
> > colored output every time in whatever terminal emulator that I try.
> >
> > I'm probably missing something but I'm wondering what an example
> terminal
> > emulator would be where xterm-256color would not work at all (even st
> worked
> > perfectly and that is supposed to be pretty barebones afaik). Or is it
> just that
> > color is a commonly supported subset of xterm and stuff breaks down with
> other
> > escape codes instead? Or maybe qemu is doing some kind of translation
> that
> > magically makes every TERM setting work in whatever terminal emulator I
> try?
> > Apologies if this seems ignorant, I have no experience at all with this
> domain.
>
> So, some info (not necessarily direction).  Old guys like to talk...
>
> So, speaking of things of old, but not ancient old, when handling server
> equipment via serial, you normally do three things.  You route the BIOS
> (legacy)
> out the serial port, you send the kernel boot messages out the serial port
> and
> you establish a getty for login on the serial port.
>
> Just being honest, the "server world" decided everything was Microsoft
> Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25)
> during the PC revolution.
>
> So.. Windows doesn't come with Hyperterminal anymore, which makes sense
> since
> PCs in general don't have serial ports (apart from USB-serial dongles).
>
> So, can you, or should you adopt a serial console solution (ansi, 80x25)?
> IMHO,
> this is still interesting.  Especially in the Linux world.  Consider that
> network equipment still speaks serial for console, the concept (still,
> even
> though this in a old concept) of using, for example, ssh to serial console
> controllers for full out of band access might still be appealing.
>
> Why?  Well, for many reasons.  Cabling is much less (that is, less dense)
> as you
> can use flat velum for quite some distance for serial.  Since you're
> having to
> somehow deal with network devices anyway, by have all done serially, you
> have
> "one stop" shopping for out of band (more on this in a bit) console access.
>
> Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But
> noting
> that you don't get virtual media with a serial console head solution
> either.
>
> But still, if running remote facilities and you need true out of band, and
> by
> that I mean the ability to reconfigure everything, including the network,
> it
> could be just the thing you need.
>
> But ssh? Network reconfigure?  That's not going to work.  Often times
> those same
> ssh to serial console devices have additional serial support usually with
> a
> option of a modem (yep... old school I know).  Back in the day, using a
> callback
> modem (added security) your infrastructure could reach out to you and you
> could
> indeed reconfigure the whole datacenter, soup to nuts.  Something lacking
> in
> general today.
>
> About your other comments, systemd sits in user space and can query
> (depend
> upon) terminfo.  Then, it should 

Re: [systemd-devel] vt220 default for serial console still relevant?

[Christopher Cox]

On 7/14/20 1:48 PM, Daan De Meyer wrote:
I just tried vt241 and didn't get colorized output in konsole. I looked around a 
bit and it doesn't really seem supported at all by terminal emulators (or at 
least none that I found). I also tried TERM=xterm-256color with 8 different 
terminal emulators and got colors with all of them. My workflow is simply "mkosi 
qemu -nographic" (with a modified mkosi that adds console=ttyS0 and overrides 
TERM for serial-getty@ttyS0 in the vm)." That connects my terminal emulator to 
the serial console of the vm. I then execute "ls -l --color /" in the vm and get 
colored output every time in whatever terminal emulator that I try.


I'm probably missing something but I'm wondering what an example terminal 
emulator would be where xterm-256color would not work at all (even st worked 
perfectly and that is supposed to be pretty barebones afaik). Or is it just that 
color is a commonly supported subset of xterm and stuff breaks down with other 
escape codes instead? Or maybe qemu is doing some kind of translation that 
magically makes every TERM setting work in whatever terminal emulator I try? 
Apologies if this seems ignorant, I have no experience at all with this domain.


So, some info (not necessarily direction).  Old guys like to talk...

So, speaking of things of old, but not ancient old, when handling server 
equipment via serial, you normally do three things.  You route the BIOS (legacy) 
out the serial port, you send the kernel boot messages out the serial port and 
you establish a getty for login on the serial port.


Just being honest, the "server world" decided everything was Microsoft 
Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) 
during the PC revolution.


So.. Windows doesn't come with Hyperterminal anymore, which makes sense since 
PCs in general don't have serial ports (apart from USB-serial dongles).


So, can you, or should you adopt a serial console solution (ansi, 80x25)?  IMHO, 
this is still interesting.  Especially in the Linux world.  Consider that 
network equipment still speaks serial for console, the concept (still, even 
though this in a old concept) of using, for example, ssh to serial console 
controllers for full out of band access might still be appealing.


Why?  Well, for many reasons.  Cabling is much less (that is, less dense) as you 
can use flat velum for quite some distance for serial.  Since you're having to 
somehow deal with network devices anyway, by have all done serially, you have 
"one stop" shopping for out of band (more on this in a bit) console access.


Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But noting 
that you don't get virtual media with a serial console head solution either.


But still, if running remote facilities and you need true out of band, and by 
that I mean the ability to reconfigure everything, including the network, it 
could be just the thing you need.


But ssh? Network reconfigure?  That's not going to work.  Often times those same 
ssh to serial console devices have additional serial support usually with a 
option of a modem (yep... old school I know).  Back in the day, using a callback 
modem (added security) your infrastructure could reach out to you and you could 
indeed reconfigure the whole datacenter, soup to nuts.  Something lacking in 
general today.


About your other comments, systemd sits in user space and can query (depend 
upon) terminfo.  Then, it should be able to support "whatever" terminfo has 
defined which could include custom terminals by the way that an end user has 
added.  And while all of that sounds incredibly ancient/old, I was on a project 
post 2000 that had to do exactly that (of course, even that might sound too old).


Btw, as weird as it sounds, where I work today, and I'm not the network admin, 
the network admin has purchased a ssh to serial console controller with callback 
modem.  And he's in his early 30's.


Btw, when I used to help manage an entire datacenter (same time as contract 
below) with those ssh to serial controllers, I just let the the linux TERM 
remain as it was mostly compatible with the ANSI from the host BIOS (at least 
I'm pretty sure).


With regards to that post 2000 project, I was interfacing with an old accounting 
package called datamodes.  Company wanted a solution where by people at home 
could ssh into this character based gui, have all the key sequences (and I do 
mean all, every Fn, Ctrl, Shift, Alt combo) and have the ability to print to 
their local printers from that ssh terminal session.  All of this was doable 
with good old fashioned terminal handling from the ancient of days.  But I did 
have to craft my own terminfo entry.  Loosely based off the scoansi terminal 
(one of the most complete terminal definitions out there, but not totally 
complete).  The end users were already running a terminal emulator that had a 
SCO ansi mode.


(even back then, datamodes had a "Windows" 

Re: [systemd-devel] vt220 default for serial console still relevant?

[Daan De Meyer]

I just tried vt241 and didn't get colorized output in konsole. I looked
around a bit and it doesn't really seem supported at all by terminal
emulators (or at least none that I found). I also tried TERM=xterm-256color
with 8 different terminal emulators and got colors with all of them. My
workflow is simply "mkosi qemu -nographic" (with a modified mkosi that adds
console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the vm)." That
connects my terminal emulator to the serial console of the vm. I then
execute "ls -l --color /" in the vm and get colored output every time in
whatever terminal emulator that I try.

I'm probably missing something but I'm wondering what an example terminal
emulator would be where xterm-256color would not work at all (even st
worked perfectly and that is supposed to be pretty barebones afaik). Or is
it just that color is a commonly supported subset of xterm and stuff breaks
down with other escape codes instead? Or maybe qemu is doing some kind of
translation that magically makes every TERM setting work in whatever
terminal emulator I try? Apologies if this seems ignorant, I have no
experience at all with this domain.

Daan

On Tue, 14 Jul 2020 at 18:22, Christopher Cox  wrote:

> On 7/14/20 3:19 AM, Lennart Poettering wrote:
> > On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:
> >
> >>> No vt220 does not support colour. I used to work on one and it is
> >>> monochrome hardware.
> >>> Xterm and konsole support extensions beyond vt220 that add in the
> colour support.
> >>
> >> Not sure how much (offtopic) history we want to get into.  I used the
> VT240
> >> in my college graphics class.  The VT241 was the color variant.
> >>
> >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
> >>
> >> I still meet programmers what hard code ansi sequences rather than
> querying
> >> termcap/terminfo.  You know what they say about those who "assume".
> >
> > Hmm, if vt241 is a bettre featured terminal type, and both xterm and
> > the Linux console a superset of it, and the terminal widely available
> > in termcaps and stuff we can certainly change our default TERM to be
> > vt241.
> >
> > Daan, if this all is the case, could you prep a PR?
>
> I would think shooting for something low is actually good.  Let the
> individual
> configure for something "better".
>
> I'm not sure I'm ready to say monochrome is obsolete.  There can be beauty
> in
> simplicity and function.  My preference, aim low, and allow easy
> configuration
> upward.  You could take the opposite stance of course, it's just that it
> could
> cause some frustration.
>
> Just my opinion though.  I'm old and I think about a lot of things like
> terminals, "proxies" and callback modems... things of value, but most do
> not
> understand or care about anymore.
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vt220 default for serial console still relevant?

[Christopher Cox]

On 7/14/20 3:19 AM, Lennart Poettering wrote:

On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:


No vt220 does not support colour. I used to work on one and it is
monochrome hardware.
Xterm and konsole support extensions beyond vt220 that add in the colour 
support.


Not sure how much (offtopic) history we want to get into.  I used the VT240
in my college graphics class.  The VT241 was the color variant.

See: http://terminals-wiki.org/wiki/index.php/DEC_VT240

I still meet programmers what hard code ansi sequences rather than querying
termcap/terminfo.  You know what they say about those who "assume".


Hmm, if vt241 is a bettre featured terminal type, and both xterm and
the Linux console a superset of it, and the terminal widely available
in termcaps and stuff we can certainly change our default TERM to be
vt241.

Daan, if this all is the case, could you prep a PR?


I would think shooting for something low is actually good.  Let the individual 
configure for something "better".


I'm not sure I'm ready to say monochrome is obsolete.  There can be beauty in 
simplicity and function.  My preference, aim low, and allow easy configuration 
upward.  You could take the opposite stance of course, it's just that it could 
cause some frustration.


Just my opinion though.  I'm old and I think about a lot of things like 
terminals, "proxies" and callback modems... things of value, but most do not 
understand or care about anymore.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GNOME boot-complete.target integration ?

[Hans de Goede]

Hi,

On 7/14/20 10:03 AM, Lennart Poettering wrote:

On Di, 30.06.20 12:17, Hans de Goede (hdego...@redhat.com) wrote:


1. The user has logged in successfully and the session lasts
at least 2 minutes (could be a bit shorter, we want to catch the
case where the session immediately exits / crashes after login); or

2. The user selects reboot/shutdown from the GNOME system-control
menu.

In both these cases we want to block the boot-complete.target
from being considered finished/ready until GNOME says it is.

I can easily achieve this by not adding the grub2-bless-boot.service
to any targets, and then manually starting it (with a polkit rule to
allow a regular user to do this) when either condition becomes true,
but then I still have the GNOME code doing something grub (Fedora's
grub even) specific. So what I really want to do is delay the
the boot-complete.target from being considered finished/ready until
GNOME says it is.

So the question really is, is there a way to have a unit wait with
starting until a certain event happens?

I guess I could use a Oneshot type service and have a little helper app
which waits until it is signalled that the boot is complete? Any other
ideas?


Why not have a tiny service that is started as part of boot. It hangs
around for 2min or, and then exits with failure. If however it is
contacted by D-Bus before that it exist immediately with
success. Then, make GNOME just ping that service if all is good.

The service would then become part of the usual boot process, ordered
before the boot blessing.

Wouldn#t that suffice?


That will break in the following scenario:

1. User powers on the machine goes to grab coffee
2. User returns after 5 min. logs in and goes to work

Notice that the contacting by DBUS you suggest would not happen
until after 2, at which point the timeout has happened.


So on the low level we actually have a concept for marking a boot as
"neutral", but I think we only expose that in sd-boot, and
badly. i.e. the idea is that a boot can be considered "bad", "good" or
"neutral". I guess we could model things for you so that initially the
boot is marked as "bad", up to the point where gdm decides it
managed to start up. In that case we'd mark things as "neutral". As
soon as gdm then received user input so that the log in starts, it
would mark things as "bad" again. And when GNOME in the user's session
finally is done with everything we'd mark things as "good" and
everything is complete.

 From a boot loader that boots up and finds the boot success state as
"bad" it will increment the fail counter of the boot item. If it finds
it as "good" it will mark the boot item as "good" forever.  But if it
finds it in "neutral" it will do neither.

Such a logic would work for you, right?


No I do not think such a logic would work for the current Fedora workstation
hidden menu stuff.

The good/neutral/bad way of thinking seems to be very much oriented around
the automatic fallback to a previous boot-loader-menu entry (typically
an older kernel, but could also be a whole other os with a/b booting).

But that is not how things currently work in Fedora Workstation and also
not a direction which we want to go in.

Currently Fedora WS hides the boot-menu be default, we do good/bad detection
to decide if need to show the menu on the next boot to give the user easy
access to it (without key pounding at boot) when the previous boot as bad.

That is all that is done, there is no automatic fallback and no permanently
marking boot-menu-entries as bad/good.

So to go to your example how this could work:

1. Early at boot something (e.g. the bootloader itself) marks the boot as bad
2. Once GDM starts mark the boot as neutral
3. Re-mark as bad before doing login

If we then lack a functioning keyboard due to driver issues
(which is rare but does happen), we never reach 3, the user then power-cycles
to recover and we see a neutral state and this don't show the menu ?

Your example could work for Fedora ws if we treat neutral the same as bad.

But this whole discussion seems somewhat orthogonal to the original problem.

I guess your idea behind this is to not delay the marking of neutral with
some helper as discussed before and to still reach boot-complete.target
once gdm starts without waiting for user input ?

But then how would gdm re-mark as bad when starting to login the user and
how would the user-session mark things as good, in a way that does not
require root rights ?

Regards,

Hans

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: [EXT] Re: advice on how to address selinux-autorelabel issue with userdbd

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 14.07.2020 um 11:35
in
Nachricht <20200714093554.GC181282@gardel-login>:
> On Di, 14.07.20 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> >>> Lennart Poettering  schrieb am 14.07.2020 um
09:50
>> in
>> Nachricht <20200714075029.GC180968@gardel-login>:
>> > On Di, 14.07.20 09:10, Dac Override (dac.overr...@gmail.com) wrote:
>> >
>> >> selinux-autorelabel needs to be able to resolve users. Currently users
>> >> managed with systemd-serdbd are not resolvable in the
>> >> selinux-autorelabel.target..
>> >>
>> >> Should I be able to pull systemd.userdvd into the
>> >> selinux-autorelabel.target? Is there a better way to ensure that homed
>> >> users are resolvable when selinux-autorelabel.service runs?
>> >
>> > systemd-homed runs after /home, and the selinux relabel stuff runs
>> > much earlier, no?
>> >
>> > How does this work for LDAP/NIS/… users? They typically are late boot
>> > stuff too?
>>
>> Yes, it is a problem even at different places: You cannot use an LDAP user

> for
>> any tmpfiles, even if the directory is used only after LDAP us up.
> 
> We explicitly document that system users/groups cannot be served by
> LDAP, and if you do that you use systemd outside of its documented
> intended work environment:
> 
> https://systemd.io/UIDS-GIDS 
> 
> See last paragraph in the "Special Distribution UID ranges" section.
> 
> systemd-tmpfiles is a tool for creating system files/dirs, and runs
> very early. We explicitly don't support it being used for anything
> else, i.e. for creating files for regular users.
> 
>> Also the
>> password utilities refuse to add the same user locally that exists in
LDAP.
>> Typically I restart the tmpfiles unit again manually and then things are
OK.
>> (In this regard NFS "bg" mounts are much smarter than systemd's tmpfiles
>> unit.)
> 
> Don#t use tmpfiles for regular user stuff, do not use it for LDAP
> users. It's not for that. It's a usecase we explicitly do not cover. Sorry.

Hi!

I fully understand that you have no support for it, but when coming from a
system where those directories existed when booting, one needs to model it some
how.
Originally the directories required were created during package installation,
also setting the proper permissions. So you could verify that everything is
fine.
With systemd I tried to let it create the required directories at boot time
instead, because this is where they are needed. As there exists some mechanism
to create "tmpfiles". I used it.
As it seems to me this solution covers only part of the compatibility issue,
i.e.: the most essential services. For higher-level add-on services this is not
that nice.

The alternatives I see are:
a) Create another unit that creates files and directories _after_ the name
lookup services are up
b) Change each unit to re-create the required directories if they are missing

To me a) seems the more logical approach, while b) seems to be the more
modular approach.

I'm not 100% happy with any of those work-arounds. in a 100% clean concept
there would not be such issues.

Ulrich

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: advice on how to address selinux-autorelabel issue with userdbd

[Lennart Poettering]

On Di, 14.07.20 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >>> Lennart Poettering  schrieb am 14.07.2020 um 09:50
> in
> Nachricht <20200714075029.GC180968@gardel-login>:
> > On Di, 14.07.20 09:10, Dac Override (dac.overr...@gmail.com) wrote:
> >
> >> selinux-autorelabel needs to be able to resolve users. Currently users
> >> managed with systemd-serdbd are not resolvable in the
> >> selinux-autorelabel.target..
> >>
> >> Should I be able to pull systemd.userdvd into the
> >> selinux-autorelabel.target? Is there a better way to ensure that homed
> >> users are resolvable when selinux-autorelabel.service runs?
> >
> > systemd-homed runs after /home, and the selinux relabel stuff runs
> > much earlier, no?
> >
> > How does this work for LDAP/NIS/… users? They typically are late boot
> > stuff too?
>
> Yes, it is a problem even at different places: You cannot use an LDAP user for
> any tmpfiles, even if the directory is used only after LDAP us up.

We explicitly document that system users/groups cannot be served by
LDAP, and if you do that you use systemd outside of its documented
intended work environment:

https://systemd.io/UIDS-GIDS

See last paragraph in the "Special Distribution UID ranges" section.

systemd-tmpfiles is a tool for creating system files/dirs, and runs
very early. We explicitly don't support it being used for anything
else, i.e. for creating files for regular users.

> Also the
> password utilities refuse to add the same user locally that exists in LDAP.
> Typically I restart the tmpfiles unit again manually and then things are OK.
> (In this regard NFS "bg" mounts are much smarter than systemd's tmpfiles
> unit.)

Don#t use tmpfiles for regular user stuff, do not use it for LDAP
users. It's not for that. It's a usecase we explicitly do not cover. Sorry.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: advice on how to address selinux-autorelabel issue with userdbd

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 14.07.2020 um 09:50
in
Nachricht <20200714075029.GC180968@gardel-login>:
> On Di, 14.07.20 09:10, Dac Override (dac.overr...@gmail.com) wrote:
> 
>> selinux-autorelabel needs to be able to resolve users. Currently users
>> managed with systemd-serdbd are not resolvable in the
>> selinux-autorelabel.target..
>>
>> Should I be able to pull systemd.userdvd into the
>> selinux-autorelabel.target? Is there a better way to ensure that homed
>> users are resolvable when selinux-autorelabel.service runs?
> 
> systemd-homed runs after /home, and the selinux relabel stuff runs
> much earlier, no?
> 
> How does this work for LDAP/NIS/… users? They typically are late boot
> stuff too?

Yes, it is a problem even at different places: You cannot use an LDAP user for
any tmpfiles, even if the directory is used only after LDAP us up. Also the
password utilities refuse to add the same user locally that exists in LDAP.
Typically I restart the tmpfiles unit again manually and then things are OK.
(In this regard NFS "bg" mounts are much smarter than systemd's tmpfiles
unit.)

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vt220 default for serial console still relevant?

[Lennart Poettering]

On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com) wrote:

> > No vt220 does not support colour. I used to work on one and it is
> > monochrome hardware.
> > Xterm and konsole support extensions beyond vt220 that add in the colour 
> > support.
>
> Not sure how much (offtopic) history we want to get into.  I used the VT240
> in my college graphics class.  The VT241 was the color variant.
>
> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
>
> I still meet programmers what hard code ansi sequences rather than querying
> termcap/terminfo.  You know what they say about those who "assume".

Hmm, if vt241 is a bettre featured terminal type, and both xterm and
the Linux console a superset of it, and the terminal widely available
in termcaps and stuff we can certainly change our default TERM to be
vt241.

Daan, if this all is the case, could you prep a PR?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-analyze security and SystemCallFilter

[Lennart Poettering]

On So, 12.07.20 18:35, Reindl Harald (h.rei...@thelounge.net) wrote:

> why are these bad and scored?
> including syscalls to the blacklist is hardly wrong

Sounds like a bug. Can you file it on github please?

I figure the tool becomes confused by the blacklist logic. Doing a
whitelist is the preferred way and it handles that much better.

Please provide the unit file in question in the github issue.

> systemd-243.8-1.fc31.x86_64
>
> ✗ SystemCallFilter=~@clockSystem
> call blacklist defined for service, and @clock is included   0.1
> ✗ SystemCallFilter=~@debugSystem
> call blacklist defined for service, and @debug is included   0.1
> ✗ SystemCallFilter=~@module   System
> call blacklist defined for service, and @module is included  0.1
> ✗ SystemCallFilter=~@mountSystem
> call blacklist defined for service, and @mount is included   0.1
> ✗ SystemCallFilter=~@raw-io   System
> call blacklist defined for service, and @raw-io is included  0.1
> ✗ SystemCallFilter=~@reboot   System
> call blacklist defined for service, and @reboot is included  0.1
> ✗ SystemCallFilter=~@swap System
> call blacklist defined for service, and @swap is included0.1
> ✗ SystemCallFilter=~@privileged   System
> call blacklist defined for service, and @privileged is not included  0.2
> ✗ SystemCallFilter=~@resourcesSystem
> call blacklist defined for service, and @resources is not included   0.2
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)

[Lennart Poettering]

On Sa, 11.07.20 22:54, PGNet Dev (pgnet@gmail.com) wrote:

> cd /etc/systemd/network
> grep Link -A1 *
>  20-enp3s0.network:[Link]
>  20-enp3s0.network-RequiredForOnline=no
>  --
>  20-enp5s0.network:[Link]
>  20-enp5s0.network-RequiredForOnline=no

Ah, eh. As it turns out we added that only in v242. See NEWS.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] service vs target

[Lennart Poettering]

On Mi, 08.07.20 11:01, Mkrtchyan, Tigran (tigran.mkrtch...@desy.de) wrote:

> Dear systemd developers,
>
> I failed to get the answer to my question from other sources, so
> here I am.
>
> We have a software that consist out of many components. Each component
> is a single service, let say A.service, B.service, C.service However,
> often you want to be able to start and stop them together. There are
> two options that I am aware of: a grouping service of a grouping
> target.

Target unit's raison d'etre is grouping stuff.  Use a target.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ensuring that a unit starts before any networking

[Lennart Poettering]

On Di, 30.06.20 11:45, Mark Rogers (m...@more-solutions.co.uk) wrote:

> >From that, is it reasonable to conclude that this is just an omission that
> has no potential negative effects from being fixed? I can't see any reason
> why adding After=network-pre.target would have direct a negative impact
> (it's plausible that on some systems it could subtly alter startup ordering
> and expose a bug that was previously hidden by luck, but that's not a
> reason to avoid doing it) and so there is no good reason not to do this,
> but my knowledge of this isn't adequate to make an informed statement on
> that matter. Before I make the argument for it being fixed I want to be
> sure of my argument!

well, one never knows what might triger bugs somewhere, but afaics
this should be a relatively riskless fix.


Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GNOME boot-complete.target integration ?

[Lennart Poettering]

On Di, 30.06.20 12:17, Hans de Goede (hdego...@redhat.com) wrote:

> > > 1. The user has logged in successfully and the session lasts
> > > at least 2 minutes (could be a bit shorter, we want to catch the
> > > case where the session immediately exits / crashes after login); or
> > >
> > > 2. The user selects reboot/shutdown from the GNOME system-control
> > > menu.
> > >
> > > In both these cases we want to block the boot-complete.target
> > > from being considered finished/ready until GNOME says it is.
> > >
> > > I can easily achieve this by not adding the grub2-bless-boot.service
> > > to any targets, and then manually starting it (with a polkit rule to
> > > allow a regular user to do this) when either condition becomes true,
> > > but then I still have the GNOME code doing something grub (Fedora's
> > > grub even) specific. So what I really want to do is delay the
> > > the boot-complete.target from being considered finished/ready until
> > > GNOME says it is.
> > >
> > > So the question really is, is there a way to have a unit wait with
> > > starting until a certain event happens?
> > >
> > > I guess I could use a Oneshot type service and have a little helper app
> > > which waits until it is signalled that the boot is complete? Any other
> > > ideas?
> >
> > Why not have a tiny service that is started as part of boot. It hangs
> > around for 2min or, and then exits with failure. If however it is
> > contacted by D-Bus before that it exist immediately with
> > success. Then, make GNOME just ping that service if all is good.
> >
> > The service would then become part of the usual boot process, ordered
> > before the boot blessing.
> >
> > Wouldn#t that suffice?
>
> That will break in the following scenario:
>
> 1. User powers on the machine goes to grab coffee
> 2. User returns after 5 min. logs in and goes to work
>
> Notice that the contacting by DBUS you suggest would not happen
> until after 2, at which point the timeout has happened.

So on the low level we actually have a concept for marking a boot as
"neutral", but I think we only expose that in sd-boot, and
badly. i.e. the idea is that a boot can be considered "bad", "good" or
"neutral". I guess we could model things for you so that initially the
boot is marked as "bad", up to the point where gdm decides it
managed to start up. In that case we'd mark things as "neutral". As
soon as gdm then received user input so that the log in starts, it
would mark things as "bad" again. And when GNOME in the user's session
finally is done with everything we'd mark things as "good" and
everything is complete.

>From a boot loader that boots up and finds the boot success state as
"bad" it will increment the fail counter of the boot item. If it finds
it as "good" it will mark the boot item as "good" forever.  But if it
finds it in "neutral" it will do neither.

Such a logic would work for you, right?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seccomp allow/log action

[Lennart Poettering]

On Mo, 13.07.20 10:02, Chris PeBenito (chpeb...@linux.microsoft.com) wrote:

> > I think it would be more flexible to extend the error code return per
> > system call, like
> > SystemCallFilter=gettimeofday:LOG
>
> Yes, that provides much more granularity but is it necessary to support that
> level of granularity in systemd?  Fine-grained system call logging is
> available in the audit subsystem and is much more flexible.

Well, if libseccomp supports this already and it feats neatly into our
syntax/model I think we can suport for Topi suggested. And I think the
syntax Topi suggests makes a lot of sense and is a nice extension to
what we already have in place.

I mean, I personally don't like audit very much, I'd always prefer
using something else over audit...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] advice on how to address selinux-autorelabel issue with userdbd

[Lennart Poettering]

On Di, 14.07.20 09:10, Dac Override (dac.overr...@gmail.com) wrote:

> selinux-autorelabel needs to be able to resolve users. Currently users
> managed with systemd-serdbd are not resolvable in the
> selinux-autorelabel.target..
>
> Should I be able to pull systemd.userdvd into the
> selinux-autorelabel.target? Is there a better way to ensure that homed
> users are resolvable when selinux-autorelabel.service runs?

systemd-homed runs after /home, and the selinux relabel stuff runs
much earlier, no?

How does this work for LDAP/NIS/… users? They typically are late boot
stuff too?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: vt220 default for serial console still relevant?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 11.07.2020 um 21:04
in
Nachricht <20200711190418.GA178957@gardel-login>:
> On Sa, 11.07.20 17:51, Daan De Meyer (daan.j.deme...@gmail.com) wrote:
> 
>> Hi,
>>
>> I was playing around with mkosi's qemu support, more specifically adding
>> the ‑nographic option to have the virtual machine output in my terminal
>> instead of a separate window. After figuring out that I had to add
>> console=ttyS0 to mkosi's kernel command line, I got the output from the vm
>> in my terminal as expected. However, because systemd defaults to
TERM=vt220
>> for serial consoles, the output is not colorized. I searched around a bit
>> and found that this is done for compatibility reasons. Will there ever be
a
>> point where we can switch the default to something that supports colors
>> (like TERM=linux)?
> 
> TERM=linux means Linux console, but that's just too much, as it not
> only implies a multitude of ESC sequences specific to the Linux
> console, but also indicates that certain ioctls might work. In our own
> code we also bind certain behaviour to TERM=linux, as indicator if we
> are on the Linux console.
> 
> I am not aware of any widely‑supported TERM value that would be a
> reasonable subset of all currently used terminals and does color.

I think "ansi" was modeled after the (at those times) very popular "vt100",
and "ansi" knows about colors (even MS-DOS had an ANSI.SYS driver to support
those ESC sequences). I think "linux" is a superset of "ansi".

> 
>> I managed to get around the problem by overriding serial‑getty@ttyS0 and
>> setting Environment=TERM=linux explicitly but it's a bit of a pain and has
>> to be added to every rootfs that wants to support colored output on its
>> serial console.
> 
> Unfortunately we can't guess the right terminal, we cannot propagate
> TERM=xterm or TERM=linux depending if you invoke qemu on an xterm or
> from a Linux console, hence the best thing we can do is stick to a
> reasonably powerful subset that is likely going to exist everywhere,
> and that's vt220 right now, as noone had a better suggestion so far...

I think there is an "identifying sequence" command defined (you send an ESC
sequence to the terminal, and the terminal responds with an identifier). The
"tack" utility can identify some terminals...

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] advice on how to address selinux-autorelabel issue with userdbd

[Dac Override]

selinux-autorelabel needs to be able to resolve users. Currently users
managed with systemd-serdbd are not resolvable in the
selinux-autorelabel.target..

Should I be able to pull systemd.userdvd into the
selinux-autorelabel.target? Is there a better way to ensure that homed
users are resolvable when selinux-autorelabel.service runs?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel