On Thu, Mar 10, 2016 at 09:10:30PM +0200, Nikolai Kondrashov wrote:
On 03/04/2016 12:54 PM, Jakub Hrozek wrote:
>I was playing with tlog yesterday and for the 'local configuration' I
>suggest we start small and avoid adding too many options, because we'd
>have to support them for a long time.
Agreed.
>It seems to me that all the options except the user's shell could just
>be set in the global tlog configuration. Maybe, if some users complain
>that they would like some per-user configs, tlog could offer a
>/etc/tlog.d directory where a file named after the user would override
>some settings, but I wouldn't go there before we hear some demand
>myself..
Yes, I wouldn't like tlog to have that kind of mechanism. At least not until
we get feedback from users about how they would prefer to use it.
>I was even wondering if it wasn't easiest to always set the original
>shell as a PAM env variable if a shell is overriden? If we did that, we
>could just use the existing options to override the shell either
>globally for all users or using the local overrides. If we don't want to
>set the env variable always, we could special-case tlog-rec, but I'm not
>a big fan of special-casing..
I too would prefer to have an env variable set always than have a special
case. I.e. it would require setting TLOG_REC_CONF_TEXT to:
{"shell": "ACTUAL_JSON_ESCAPED_USER_SHELL"}
As an alternative I can add support for a TLOG_REC_SHELL variable which value
wouldn't need escaping. Perhaps I'll do that in any case as it can be useful
for others.
Is the escaping easy to do or would it require a dependency?