Re: [systemd-devel] Locale setup for non-shells

[Andrei Borzenkov]

22.05.2017 15:45, Mantas Mikulėnas пишет:
> 
> (Keep in mind that "sourceable by sh" means the value might be quoted and
> with the occassional backslash in the middle – e.g. LANG="en\_US\.UTF\-8"
> is within spec.)
> 

Well, the next sentence goes on with "beyond mere variable assignments,
no shell features are supported, allowing applications to read the file
without implementing a shell compatible execution engine", so I am not
sure your example satisfies it. Quoting is also "shell feature" of a
sort ...

In general I'd say "shell-compatible" is vague enough to raise all sort
of expectations. It would be better to have formal definition of what is
valid in those assignments.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Locale setup for non-shells

[Nikolai Kondrashov]

On 05/22/2017 04:46 PM, Lennart Poettering wrote:

On Mon, 22.05.17 14:11, Nikolai Kondrashov (nikolai.kondras...@redhat.com) 
wrote:

I'm trying to solve a problem of supplying locale settings to non-shell
programs acting as login shells in Fedora and RHEL, as described
below.


Which services precisely are running these PAM sessions?

Note that explicitly importing /etc/locale.conf should be entirely
unnecessary: systemd reads that anyway and adds it to the environment
of all services it spawns.

I am pretty sure instead of readding this to the env block through PAM
it should just stay in place anyway, and simply be inherited
down. Hence, I'd claim that the services setting up the PAM session
are simply too eager in cleaning up the environment and should be
fixed to leave LANG= and LC_*= in the environment passed to activates sessions.


So far it seems the Debian way of doing things will work.

Could you please confirm that the format of locale.conf is not going to change
in a way incompatible with what pam_env.so expects?

The pam_env.so manpage:

http://man7.org/linux/man-pages/man8/pam_env.8.html

The locale.conf manpage:

https://www.freedesktop.org/software/systemd/man/locale.conf.html

Also, am I missing anything? Is there another way systemd can help here?


The syntax described in the man page is unlikely to change. I have no
idea about the format pam_env expects though.

And I can only recommend fixing the services in question instead of
taping over the issue with pam_env...


Thanks for your prompt response, Lennart!

I'm talking about logins on console now, so I assume the service in question,
technically, is systemd-logind. However, I found out that it's working OK, and
the real problem is these two pieces in /lib/systemd/system/getty@.service:

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= 
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= 
LC_MEASUREMENT= LC_IDENTIFICATION=

and

ExecStart=-/sbin/agetty --noclear %I $TERM

What the first one does is obvious, and the second needs to be modified to
make login preserve the environment. Like this:

ExecStart=-/sbin/agetty -o "-p -- \u" --noclear %I $TERM

Do you think the two pieces above can be changed to let the locale environment
through?

Thank you.

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

Re: [systemd-devel] Locale setup for non-shells

[Mantas Mikulėnas]

On Mon, May 22, 2017, 16:40 Tomas Mraz  wrote:

> On Mon, 2017-05-22 at 15:45 +0300, Mantas Mikulėnas wrote:
> > On Mon, May 22, 2017 at 2:11 PM, Nikolai Kondrashov <
> > nikolai.kondras...@redhat.com> wrote:
> >
> > > Hi everyone on systemd-devel,
> > >
> > > I'm trying to solve a problem of supplying locale settings to non-
> > > shell
> > > programs acting as login shells in Fedora and RHEL, as described
> > > below.
> > >
> > > So far it seems the Debian way of doing things will work.
> > >
> > > Could you please confirm that the format of locale.conf is not
> > > going to
> > > change
> > > in a way incompatible with what pam_env.so expects?
> > >
> >
> > Well, the format of locale.conf is meant to be sourceable by sh/bash,
> > so I
> > don't expect it to ever change. It's also covered by the official
> > "stability promise" [1].
> >
> > A better question is what exactly pam_env.so expects... Last time I
> > couldn't quite figure out when it wants a key=value file and when it
> > wants
> > its own special "foo DEFAULT=bar" format, and in fact the manual
> > doesn't
> > seem to match the actual behavior... Does it autodetect or something?
>
> The 'key=value' format works by accident but I plan to make it official
>  one day.
>

Hmm, I guess the extended format in ~/.pam_environment is also allowed by
accident? I still use it for setting variables which depend on $HOME or
$XDG_RUNTIME_DIR (like the ssh-agent path).

> --

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

Re: [systemd-devel] Locale setup for non-shells

[Tomas Mraz]

On Mon, 2017-05-22 at 15:45 +0300, Mantas Mikulėnas wrote:
> On Mon, May 22, 2017 at 2:11 PM, Nikolai Kondrashov <
> nikolai.kondras...@redhat.com> wrote:
> 
> > Hi everyone on systemd-devel,
> > 
> > I'm trying to solve a problem of supplying locale settings to non-
> > shell
> > programs acting as login shells in Fedora and RHEL, as described
> > below.
> > 
> > So far it seems the Debian way of doing things will work.
> > 
> > Could you please confirm that the format of locale.conf is not
> > going to
> > change
> > in a way incompatible with what pam_env.so expects?
> > 
> 
> Well, the format of locale.conf is meant to be sourceable by sh/bash,
> so I
> don't expect it to ever change. It's also covered by the official
> "stability promise" [1].
> 
> A better question is what exactly pam_env.so expects... Last time I
> couldn't quite figure out when it wants a key=value file and when it
> wants
> its own special "foo DEFAULT=bar" format, and in fact the manual
> doesn't
> seem to match the actual behavior... Does it autodetect or something?

The 'key=value' format works by accident but I plan to make it official
 one day.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)

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

Re: [systemd-devel] Locale setup for non-shells

[Lennart Poettering]

On Mon, 22.05.17 14:11, Nikolai Kondrashov (nikolai.kondras...@redhat.com) 
wrote:

> Hi everyone on systemd-devel,
> 
> I'm trying to solve a problem of supplying locale settings to non-shell
> programs acting as login shells in Fedora and RHEL, as described
> below.

Which services precisely are running these PAM sessions?

Note that explicitly importing /etc/locale.conf should be entirely
unnecessary: systemd reads that anyway and adds it to the environment
of all services it spawns.

I am pretty sure instead of readding this to the env block through PAM
it should just stay in place anyway, and simply be inherited
down. Hence, I'd claim that the services setting up the PAM session
are simply too eager in cleaning up the environment and should be
fixed to leave LANG= and LC_*= in the environment passed to activates sessions.

> 
> So far it seems the Debian way of doing things will work.
> 
> Could you please confirm that the format of locale.conf is not going to change
> in a way incompatible with what pam_env.so expects?
> 
> The pam_env.so manpage:
> 
> http://man7.org/linux/man-pages/man8/pam_env.8.html
> 
> The locale.conf manpage:
> 
> https://www.freedesktop.org/software/systemd/man/locale.conf.html
> 
> Also, am I missing anything? Is there another way systemd can help here?

The syntax described in the man page is unlikely to change. I have no
idea about the format pam_env expects though.

And I can only recommend fixing the services in question instead of
taping over the issue with pam_env...

Lennart

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

Re: [systemd-devel] Locale setup for non-shells

[Mantas Mikulėnas]

On Mon, May 22, 2017 at 2:11 PM, Nikolai Kondrashov <
nikolai.kondras...@redhat.com> wrote:

> Hi everyone on systemd-devel,
>
> I'm trying to solve a problem of supplying locale settings to non-shell
> programs acting as login shells in Fedora and RHEL, as described below.
>
> So far it seems the Debian way of doing things will work.
>
> Could you please confirm that the format of locale.conf is not going to
> change
> in a way incompatible with what pam_env.so expects?
>

Well, the format of locale.conf is meant to be sourceable by sh/bash, so I
don't expect it to ever change. It's also covered by the official
"stability promise" [1].

A better question is what exactly pam_env.so expects... Last time I
couldn't quite figure out when it wants a key=value file and when it wants
its own special "foo DEFAULT=bar" format, and in fact the manual doesn't
seem to match the actual behavior... Does it autodetect or something?

(Keep in mind that "sourceable by sh" means the value might be quoted and
with the occassional backslash in the middle – e.g. LANG="en\_US\.UTF\-8"
is within spec.)

[1]: https://www.freedesktop.org/wiki/Software/systemd/
InterfacePortabilityAndStabilityChart/

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

Re: [systemd-devel] Locale setup for non-shells

[Nikolai Kondrashov]

Hi everyone on systemd-devel,

I'm trying to solve a problem of supplying locale settings to non-shell
programs acting as login shells in Fedora and RHEL, as described below.

So far it seems the Debian way of doing things will work.

Could you please confirm that the format of locale.conf is not going to change
in a way incompatible with what pam_env.so expects?

The pam_env.so manpage:

http://man7.org/linux/man-pages/man8/pam_env.8.html

The locale.conf manpage:

https://www.freedesktop.org/software/systemd/man/locale.conf.html

Also, am I missing anything? Is there another way systemd can help here?

Thank you.

Nick

On 04/04/2017 06:06 PM, Nikolai Kondrashov wrote:

Hi everyone,

At the moment users logging into Fedora on a text terminal (console, SSH,
etc.) get their locale environment variables (LANG, LC_ALL, etc.) set up by
the shell they use. I.e. the shell ultimately sources the /etc/locale.conf
file. This works fine in most cases.

However, if the user has his/her "shell" set to any program that is not one of
the traditional shells, i.e. it doesn't source any shell profiles, or even
doesn't understand any shell language at all, then that program doesn't get
locale settings.

Theoretical examples can include captive portals on jump-hosts, or
special-purpose systems with dedicated TUI instead of a shell. A practical
example that concerns me is a user session recording program [1] which needs
to run before user shell, and intercept all I/O going to and from the
terminal.

I would like to know if it is possible to change Fedora to provide the locale
variables through the environment user "shell" inherits, instead of expecting
it to read /etc/locale.conf, which is distro-specific.

This is done in Debian already. During session setup in login/sshd/etc. they
use pam_env to read /etc/default/locale. Similar thing is possible to do in
Fedora too. E.g. just put this into /etc/pam.d/system-auth:

session required  pam_env.so envfile=/etc/locale.conf

Nick

[1] Tlog - terminal I/O logger
https://github.com/Scribery/tlog
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

Re: [systemd-devel] dbus and exit-on-idle

[Lennart Poettering]

On Mon, 22.05.17 02:26, Matthijs van Duin (matthijsvand...@gmail.com) wrote:

> I've been pondering how to allow my bus-activated service to exit when
> it's unneeded (which is 99% of the time), and in particular how to deal
> with exit/activate races correctly...
> 
> In the systemd sources I stumbled across the helper function
> bus_event_loop_with_idle() which does a clever trick by
>  - using sd_notify("STOPPING=1") to make sure systemd will queue any
>activations from here on
>  - releasing the dbus service name
>  - handling any remaining requests until the name deregistration is
>confirmed by the dbus daemon
> 
> Thus, any incoming request will either be delivered to you, or trigger a
> new activation and be delivered to the next instance of your service.
> 
> I see two problems here:
>  1. sd_notify is asynchronous and nothing is done to ensure systemd has
> acted on it before the service name is released.
>  2. If you get an incoming request that requires you to continue running
> after you've told systemd you're stopping, you're screwed.
> 
> The first problem could be solved by monitoring your own unit status I
> suppose, although it would be more elegant if the sd_notify() could be
> replaced by a dbus call.
> 
> The second problem is more annoying... although you could just register
> your bus name again (which presumably suffices to get any queued calls
> delivered to you?), once you've told systemd you're stopping there's no
> way back currently, and it will SIGKILL you if you take too long.
> 
> Could this be solved by simply allowing a stopping service to change its
> mind, e.g. with sd_notify("STOPPING=0") or perhaps another READY=1 ?

Yes, the exit-on-idle logic on dbus is impossible to implement
correctly for non-trivial cases right now. It's a pity. I think the
best option to solve this properly would be to switch to
AF_UNIX/SOCK_SEQPACKET sockets for this, as an alternate transport,
then do away with all the auth/nego logic and permit assigning names
to such bus connects as part of systemd itself. That way we'd have
unified all connection state logic in a single socket, and could do
dbus activation the same way as normal socket activation and the whole
race problem goes away... 

But of course, that's a lot of work, and would require non-trivial
additions to the dbus spec.

In the meantime, adding a way to "cancel" stopping sounds OK to me.

Lennart

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