[gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi,

i just wrote an init.d-script and i thought that the LANG variable was
inherited since it set system-wide in /etc/env.d/02locale and therefor
is also found in /etc/profile.env

Now i noticed, that LANG isn't set for the process started by my
init.d-script.

So what's the intension to ignore /etc/profile.env for init.d-script and
what's the gentoo-way of loading the all or specific variabled from
/etc/profile.env?

Thx
  Sven

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Roy Marples]

On Tue, 2005-08-23 at 16:33 +0200, Sven Köhler wrote:
> Hi,
> 
> i just wrote an init.d-script and i thought that the LANG variable was
> inherited since it set system-wide in /etc/env.d/02locale and therefor
> is also found in /etc/profile.env

Did you env-update?

> 
> Now i noticed, that LANG isn't set for the process started by my
> init.d-script.

I set LANG and a few other things in /etc/env.d/02locale

Here's a quick init script called test

#!/sbin/runscript

start() {
    set | grep LANG
}

Now, lets see what it does

uberpc init.d # ./test start
 * Starting service test
LANG=en_GB.utf8
LANGUAGE=en_GB.utf8
    set | grep LANG
 * Service test started OK


> 
> So what's the intension to ignore /etc/profile.env for init.d-script and
> what's the gentoo-way of loading the all or specific variabled from
> /etc/profile.env?

So we're not ignoring it. Maybe the process itself doesn't use LANG ?

Thanks

Roy


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Georgi Georgiev]

maillog: 24/08/2005-08:26:26(+0100): Roy Marples types
> On Tue, 2005-08-23 at 16:33 +0200, Sven Köhler wrote:
> > Hi,
> > 
> > i just wrote an init.d-script and i thought that the LANG variable was
> > inherited since it set system-wide in /etc/env.d/02locale and therefor
> > is also found in /etc/profile.env
> 
> Did you env-update?
> 
> > 
> > Now i noticed, that LANG isn't set for the process started by my
> > init.d-script.
> 
> I set LANG and a few other things in /etc/env.d/02locale
> 
> Here's a quick init script called test
> 
> #!/sbin/runscript
> 
> start() {
>     set | grep LANG
> }
> 
> Now, lets see what it does
> 
> uberpc init.d # ./test start
>  * Starting service test
> LANG=en_GB.utf8
> LANGUAGE=en_GB.utf8
>     set | grep LANG
>  * Service test started OK

Try unsetting the variable in your own shell first.

lion init.d # /etc/init.d/test restart
LANG=en_US.utf8
    set | grep LANG
lion init.d # LANG=C /etc/init.d/test restart
LANG=C
    set | grep LANG
lion init.d # env -u LANG /etc/init.d/test restart
    set | grep LANG

-- 
/    Georgi Georgiev   /  A new koan: If you have some ice cream, I    /
\     chutz@gg3.net    \  will give it to you. If you have no ice      \
/   +81(90)2877-8845   /  cream, I will take it away from you. It is   /
\  ------------------- \  an ice cream koan.                           \
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Roy Marples]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Wed, 2005-08-24 at 17:27 +0900, Georgi Georgiev wrote: 
> > uberpc init.d # ./test start
> >  * Starting service test
> > LANG=en_GB.utf8
> > LANGUAGE=en_GB.utf8
> >     set | grep LANG
> >  * Service test started OK
> 
> Try unsetting the variable in your own shell first.
> 
> lion init.d # /etc/init.d/test restart
> LANG=en_US.utf8
>     set | grep LANG
> lion init.d # LANG=C /etc/init.d/test restart
> LANG=C
>     set | grep LANG
> lion init.d # env -u LANG /etc/init.d/test restart
>     set | grep LANG
>                 \

Um, that's kinda like behaviour by design unless anyone can tell me
otherwise.

/etc/env.d/* just set shell variables, so if you change one then you
need to

env-update
source /etc/profile
/etc/init.d/thisdaemon restart

To refresh the daemon that needs the vars

-- 
Roy Marples <uberlord@gentoo.org>
Gentoo Linux Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

maillog: 24/08/2005-11:04:42(+0100): Roy Marples types
> On Wed, 2005-08-24 at 17:27 +0900, Georgi Georgiev wrote: 
> > > uberpc init.d # ./test start
> > >  * Starting service test
> > > LANG=en_GB.utf8
> > > LANGUAGE=en_GB.utf8
> > >     set | grep LANG
> > >  * Service test started OK
> > 
> > Try unsetting the variable in your own shell first.
> > 
> > lion init.d # /etc/init.d/test restart
> > LANG=en_US.utf8
> >     set | grep LANG
> > lion init.d # LANG=C /etc/init.d/test restart
> > LANG=C
> >     set | grep LANG
> > lion init.d # env -u LANG /etc/init.d/test restart
> >     set | grep LANG
> >                 \
> 
> Um, that's kinda like behaviour by design unless anyone can tell me
> otherwise.
> 
> /etc/env.d/* just set shell variables, so if you change one then you
> need to
> 
> env-update
> source /etc/profile
> /etc/init.d/thisdaemon restart
> 
> To refresh the daemon that needs the vars

The init script will not see those variables when it is run by /sbin/rc
which is in turn run by init which is what happens on boot. The
environment is empty then, and if you want to reproduce it accurately
for your tests, you should do:

	env -i /etc/init.d/test restart

It does see variables in /etc/rc.conf though:

lion ~ # echo LANGTEST=testme >> /etc/rc.conf
lion ~ # env -i /etc/init.d/test restart
 * Caching service dependencies ...                                                                        [ ok ]
LANGTEST=testme
    set | grep LANG

-- 
/    Georgi Georgiev   /  Honesty is the best policy, but insanity     /
\     chutz@gg3.net    \  is a better defense.                         \
/   +81(90)2877-8845   /                                               /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

> The init script will not see those variables when it is run by /sbin/rc
> which is in turn run by init which is what happens on boot. The
> environment is empty then, and if you want to reproduce it accurately
> for your tests, you should do:
> 
> 	env -i /etc/init.d/test restart
> 
> It does see variables in /etc/rc.conf though:
> 
> lion ~ # echo LANGTEST=testme >> /etc/rc.conf
> lion ~ # env -i /etc/init.d/test restart
>  * Caching service dependencies ...                                                                        [ ok ]
> LANGTEST=testme
>     set | grep LANG

And the init-script will also see the variables from /etc/conf.d/test

But i cannot says, that i like the design.
Should init.d-scripts see the env-variables from the current
environment? I don't think so - even if it's usually root's environment.

/sbin/rc could clear the environment and source /etc/profile.env
instead. That would be pretty clever i think. An init-script would
always run within the same environment no matter whether it's run by
init or root's shell.

How about that?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Wednesday 24 August 2005 12:04, Roy Marples wrote:
>
> Um, that's kinda like behaviour by design unless anyone can tell me
> otherwise.
>
> /etc/env.d/* just set shell variables, so if you change one then you
> need to
>
> env-update
> source /etc/profile
> /etc/init.d/thisdaemon restart
>
> To refresh the daemon that needs the vars

Perhaps the init script loader should be changed such that the environment 
variables from the shell calling the script are ignored, and an 
environment equal to that when being called by init is used.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

> Perhaps the init script loader should be changed such that the environment 
> variables from the shell calling the script are ignored, and an 
> environment equal to that when being called by init is used.

Definitely. There shouldn't be two different environments depending on
whether a init-script is run from the command-line or by the init-process.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Roy Marples]

On Thu, 2005-08-25 at 12:01 +0200, Paul de Vrieze wrote:
> On Wednesday 24 August 2005 12:04, Roy Marples wrote:
> >
> > Um, that's kinda like behaviour by design unless anyone can tell me
> > otherwise.
> >
> > /etc/env.d/* just set shell variables, so if you change one then you
> > need to
> >
> > env-update
> > source /etc/profile
> > /etc/init.d/thisdaemon restart
> >
> > To refresh the daemon that needs the vars
> 
> Perhaps the init script loader should be changed such that the environment 
> variables from the shell calling the script are ignored, and an 
> environment equal to that when being called by init is used.
> 
> Paul
> 

I've been looking into this and the only easy solution I can find is to
move /sbin/runscript.sh to say /lib/rcscripts/sh, change it to
source /etc/profile and then create a new /sbin/runscript.sh like so

#!/bin/sh

/bin/env -i \
    CONSOLETYPE="${CONSOLETYPE}" \
    IN_BACKGROUND="${IN_BACKGROUND}" \
    IN_HOTPLUG="${IN_HOTPLUG}" \
    /lib/rcscripts/sh/runscript.sh $*

Right away we can see that we actually do need some to keep some env
vars and the list would be constantly updated. There's also nothing to
stop the user from setting them and then running a script which kind of
defeats the purpose here anyway.

Personally I'm against this.I'd like to know what Azarah and Vapier
think of this though. Others too!

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Roy Marples]

I just love replying to myself!

On Tue, 2005-08-30 at 22:32 +0100, Roy Marples wrote:
> #!/bin/sh
> 
> /bin/env -i \
>     CONSOLETYPE="${CONSOLETYPE}" \
>     IN_BACKGROUND="${IN_BACKGROUND}" \
>     IN_HOTPLUG="${IN_HOTPLUG}" \
>     /lib/rcscripts/sh/runscript.sh $*

A quick reboot shows we need much more. Here's what works on my system

/bin/env -i \
    BOOT="${BOOT}" \
    CONSOLETYPE="${CONSOLETYPE}" \
    CRITICAL_SERVICES="${CRITICAL_SERVICES}" \
    START_CRITICAL="${START_CRITICAL}" \
    STOP_CRTIICAL="${STOP_CRITICAL}" \
    OLDSOFTLEVEL="${OLDSOFTLEVEL}" \
    SOFTLEVEL="${SOFTLEVEL}" \
    IN_BACKGROUND="${IN_BACKGROUND}" \
    IN_HOTPLUG="${IN_HOTPLUG}" \
    /lib/rcscripts/sh/runscript.sh $*


> 
> Right away we can see that we actually do need some to keep some env
> vars and the list would be constantly updated. There's also nothing to
> stop the user from setting them and then running a script which kind of
> defeats the purpose here anyway.
> 
> Personally I'm against this.I'd like to know what Azarah and Vapier
> think of this though. Others too!

I think I just added a few more reasons why I don't like this ....

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Francesco R]

Roy Marples wrote:

>I just love replying to myself!
>
>On Tue, 2005-08-30 at 22:32 +0100, Roy Marples wrote:
>  
>
>>#!/bin/sh
>>
>>/bin/env -i \
>>    CONSOLETYPE="${CONSOLETYPE}" \
>>    IN_BACKGROUND="${IN_BACKGROUND}" \
>>    IN_HOTPLUG="${IN_HOTPLUG}" \
>>    /lib/rcscripts/sh/runscript.sh $*
>>    
>>
>
>A quick reboot shows we need much more. Here's what works on my system
>
>/bin/env -i \
>    BOOT="${BOOT}" \
>    CONSOLETYPE="${CONSOLETYPE}" \
>    CRITICAL_SERVICES="${CRITICAL_SERVICES}" \
>    START_CRITICAL="${START_CRITICAL}" \
>    STOP_CRTIICAL="${STOP_CRITICAL}" \
>    OLDSOFTLEVEL="${OLDSOFTLEVEL}" \
>    SOFTLEVEL="${SOFTLEVEL}" \
>    IN_BACKGROUND="${IN_BACKGROUND}" \
>    IN_HOTPLUG="${IN_HOTPLUG}" \
>    /lib/rcscripts/sh/runscript.sh $*
>
>
>  
>
>>Right away we can see that we actually do need some to keep some env
>>vars and the list would be constantly updated. There's also nothing to
>>stop the user from setting them and then running a script which kind of
>>defeats the purpose here anyway.
>>
>>Personally I'm against this.I'd like to know what Azarah and Vapier
>>think of this though. Others too!
>>    
>>
>
>I think I just added a few more reasons why I don't like this ....
>
>Roy
>
>  
>
Read only the last three messages of the thread, hoping to not say
idiotic things.
Rewriting the previous script in the following manner:

[code]
VARS_TO_EXPORT="BOOT CONSOLETYPE CRITICAL_SERVICES START_CRITICAL
STOP_CRITICAL OLDSOFTLEVEL SOFTLEVEL IN_BACKGROUND IN_HOTPLUG"

RUNSCRIPT="/bin/env -i"
for i in ${VARS_TO_EXPORT} ; do
    RUNSCRIPT="${RUNSCRIPT} ${i}=\${${i}}"
done
RUNSCRIPT="${RUNSCRIPT} /lib/rcscripts/sh/runscript.sh $*"
eval $RUNSCRIPT
[/code]

should make it easyer to maintain, also "VARS_TO_EXPORT" could be placed
in /etc/rc.conf (with a better name) .
Running the rc scripts from a clean environment make easyer to debug
things, it caused at least one headheache to me installing SuSE + apache
+ php + informix some years ago.

just my 2 cents.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

> I've been looking into this and the only easy solution I can find is to
> move /sbin/runscript.sh to say /lib/rcscripts/sh, change it to
> source /etc/profile and then create a new /sbin/runscript.sh like so
> 
> #!/bin/sh
> 
> /bin/env -i \
>     CONSOLETYPE="${CONSOLETYPE}" \
>     IN_BACKGROUND="${IN_BACKGROUND}" \
>     IN_HOTPLUG="${IN_HOTPLUG}" \
>     /lib/rcscripts/sh/runscript.sh $*
> 
> Right away we can see that we actually do need some to keep some env
> vars and the list would be constantly updated. There's also nothing to
> stop the user from setting them and then running a script which kind of
> defeats the purpose here anyway.
> 
> Personally I'm against this.I'd like to know what Azarah and Vapier
> think of this though. Others too!

most init.d-scripts have "#!/sbin/runscript" as the first line. I don't
know what it does, but could that binary perhaps clear the environment?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] init.d-scripts don't see stuff from /etc/profile.env

[Mike Frysinger]

On Tuesday 30 August 2005 05:32 pm, Roy Marples wrote:
> On Thu, 2005-08-25 at 12:01 +0200, Paul de Vrieze wrote:
> > On Wednesday 24 August 2005 12:04, Roy Marples wrote:
> > > Um, that's kinda like behaviour by design unless anyone can tell me
> > > otherwise.
> > >
> > > /etc/env.d/* just set shell variables, so if you change one then you
> > > need to
> > >
> > > env-update
> > > source /etc/profile
> > > /etc/init.d/thisdaemon restart
> > >
> > > To refresh the daemon that needs the vars
> >
> > Perhaps the init script loader should be changed such that the
> > environment variables from the shell calling the script are ignored, and
> > an
> > environment equal to that when being called by init is used.
>
> I've been looking into this and the only easy solution I can find is to
> move /sbin/runscript.sh to say /lib/rcscripts/sh, change it to
> source /etc/profile and then create a new /sbin/runscript.sh like so
>
> Right away we can see that we actually do need some to keep some env
> vars and the list would be constantly updated. There's also nothing to
> stop the user from setting them and then running a script which kind of
> defeats the purpose here anyway.
>
> Personally I'm against this.I'd like to know what Azarah and Vapier
> think of this though. Others too!

init.d scripts should have a pure env given to them ... which means, they 
should be run with `env -i` and have only whitelisted variables given to them 
(and everything that appears in /etc/conf.d/$service /etc/conf.d/rc 
and /etc/rc.conf) ...

after all, you wouldnt want something like apache having all those vars in its 
env because they'd show up in php script env which means available to the 
public
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

> init.d scripts should have a pure env given to them ... which means, they 
> should be run with `env -i` and have only whitelisted variables given to them 
> (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc 
> and /etc/rc.conf) ...

Now that may be too few variables. At least the variable LANG (or
whatever the system-admin may chose to set) could be seen as a
system-wide language-setting. It could be intentional, that at least
some variables are available to the started server-processes. Especially
a system-wide language-setting would be a good idea.

After all, there's one point:
The 2 possible situations (init-script started by root-shell,
init-script started at by init-process) because of at least 2 reasons:

- less side-effects
- and of course the reason vapier mentiones:

> after all, you wouldnt want something like apache having all those vars in its 
> env because they'd show up in php script env which means available to the 
> public

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

[gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

>>>init.d scripts should have a pure env given to them ... which means, they
>>>should be run with `env -i` and have only whitelisted variables given to
>>>them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc
>>>and /etc/rc.conf) ...
>>
>>Now that may be too few variables. At least the variable LANG (or
>>whatever the system-admin may chose to set) could be seen as a
>>system-wide language-setting. It could be intentional, that at least
>>some variables are available to the started server-processes. Especially
>>a system-wide language-setting would be a good idea.
> 
> that is the point of the whitelist idea ... we gather a 'full 
> env' (source /etc/profile i guess) and rip out just the whitelisted variables 
> to pass on to init scripts

OK, you just didn't list /etc/profile in your first reply. The
whitelist-thing is a good idea and makes it very flexible.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Mike Frysinger]

On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote:
> > init.d scripts should have a pure env given to them ... which means, they
> > should be run with `env -i` and have only whitelisted variables given to
> > them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc
> > and /etc/rc.conf) ...
>
> Now that may be too few variables. At least the variable LANG (or
> whatever the system-admin may chose to set) could be seen as a
> system-wide language-setting. It could be intentional, that at least
> some variables are available to the started server-processes. Especially
> a system-wide language-setting would be a good idea.

that is the point of the whitelist idea ... we gather a 'full 
env' (source /etc/profile i guess) and rip out just the whitelisted variables 
to pass on to init scripts
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote:
> On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote:
> > > init.d scripts should have a pure env given to them ... which means, they
> > > should be run with `env -i` and have only whitelisted variables given to
> > > them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc
> > > and /etc/rc.conf) ...
> >
> > Now that may be too few variables. At least the variable LANG (or
> > whatever the system-admin may chose to set) could be seen as a
> > system-wide language-setting. It could be intentional, that at least
> > some variables are available to the started server-processes. Especially
> > a system-wide language-setting would be a good idea.
> 
> that is the point of the whitelist idea ... we gather a 'full 
> env' (source /etc/profile i guess) and rip out just the whitelisted variables 
> to pass on to init scripts

Although I agree, my personal opinion is that its going to be a major
PITA to maintain, and slow things down.  Also, not only runscript.sh
will have to be 'whitelisted', but also /sbin/rc, which will mean that
we now have to wrap two things.  I guess a solution could have been to
use /sbin/runscript (the C thing) for both (should work fine
as /sbin/rc's interpreter as well), as that would buy some speed and
kill one bash fork, but the problem comes in when we start with a
vanilla environment that do not have /etc/profile sourced.

(I guess we could do a function that just unset anything not in the
whitelist via a for loop that we call top of /sbin/rc and runscript.sh,
but bash for loops is kinda slow anyhow ...)


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Mike Frysinger]

On Tuesday 30 August 2005 10:15 pm, Martin Schlemmer wrote:
> On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote:
> > On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote:
> > > > init.d scripts should have a pure env given to them ... which means,
> > > > they should be run with `env -i` and have only whitelisted variables
> > > > given to them (and everything that appears in /etc/conf.d/$service
> > > > /etc/conf.d/rc and /etc/rc.conf) ...
> > >
> > > Now that may be too few variables. At least the variable LANG (or
> > > whatever the system-admin may chose to set) could be seen as a
> > > system-wide language-setting. It could be intentional, that at least
> > > some variables are available to the started server-processes.
> > > Especially a system-wide language-setting would be a good idea.
> >
> > that is the point of the whitelist idea ... we gather a 'full
> > env' (source /etc/profile i guess) and rip out just the whitelisted
> > variables to pass on to init scripts
>
> Although I agree, my personal opinion is that its going to be a major
> PITA to maintain, and slow things down.

with the first run, we cache the 'scrubbed' env, and then just use that in the 
future ?

> Also, not only runscript.sh 
> will have to be 'whitelisted', but also /sbin/rc, which will mean that
> we now have to wrap two things.  I guess a solution could have been to
> use /sbin/runscript (the C thing) for both (should work fine
> as /sbin/rc's interpreter as well), as that would buy some speed and
> kill one bash fork, but the problem comes in when we start with a
> vanilla environment that do not have /etc/profile sourced.

mmm unification is good :)
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

On Tue, 2005-08-30 at 22:21 -0400, Mike Frysinger wrote:
> On Tuesday 30 August 2005 10:15 pm, Martin Schlemmer wrote:
> > On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote:
> > > On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote:
> > > > > init.d scripts should have a pure env given to them ... which means,
> > > > > they should be run with `env -i` and have only whitelisted variables
> > > > > given to them (and everything that appears in /etc/conf.d/$service
> > > > > /etc/conf.d/rc and /etc/rc.conf) ...
> > > >
> > > > Now that may be too few variables. At least the variable LANG (or
> > > > whatever the system-admin may chose to set) could be seen as a
> > > > system-wide language-setting. It could be intentional, that at least
> > > > some variables are available to the started server-processes.
> > > > Especially a system-wide language-setting would be a good idea.
> > >
> > > that is the point of the whitelist idea ... we gather a 'full
> > > env' (source /etc/profile i guess) and rip out just the whitelisted
> > > variables to pass on to init scripts
> >
> > Although I agree, my personal opinion is that its going to be a major
> > PITA to maintain, and slow things down.
> 
> with the first run, we cache the 'scrubbed' env, and then just use that in the 
> future ?
> 

We both know when somebody finally notice that, they will bitch because
the environment is not updated :)  Damn, did I just point that out ? 8)

> > Also, not only runscript.sh 
> > will have to be 'whitelisted', but also /sbin/rc, which will mean that
> > we now have to wrap two things.  I guess a solution could have been to
> > use /sbin/runscript (the C thing) for both (should work fine
> > as /sbin/rc's interpreter as well), as that would buy some speed and
> > kill one bash fork, but the problem comes in when we start with a
> > vanilla environment that do not have /etc/profile sourced.
> 
> mmm unification is good :)

I did not argue .. was just wondering how much gain (tears?) it will
bring us :)


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Wednesday 31 August 2005 09:25, Martin Schlemmer wrote:
> >
> > with the first run, we cache the 'scrubbed' env, and then just use
> > that in the future ?
>
> We both know when somebody finally notice that, they will bitch because
> the environment is not updated :)  Damn, did I just point that out ? 8)

What about using this scrubbing to determine which variables to pass on to 
the init script. The actual values could then come from the sources they 
come from when started by init. This would mean 
that /etc/conf.d/servicename changes would still be incorporated.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Wed, 2005-08-31 at 09:25 +0200, Martin Schlemmer wrote:
> On Tue, 2005-08-30 at 22:21 -0400, Mike Frysinger wrote:
> > On Tuesday 30 August 2005 10:15 pm, Martin Schlemmer wrote:
> > > On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote:
> > > > On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote:
> > > > > > init.d scripts should have a pure env given to them ... which means,
> > > > > > they should be run with `env -i` and have only whitelisted variables
> > > > > > given to them (and everything that appears in /etc/conf.d/$service
> > > > > > /etc/conf.d/rc and /etc/rc.conf) ...
> > > > >
> > > > > Now that may be too few variables. At least the variable LANG (or
> > > > > whatever the system-admin may chose to set) could be seen as a
> > > > > system-wide language-setting. It could be intentional, that at least
> > > > > some variables are available to the started server-processes.
> > > > > Especially a system-wide language-setting would be a good idea.
> > > >
> > > > that is the point of the whitelist idea ... we gather a 'full
> > > > env' (source /etc/profile i guess) and rip out just the whitelisted
> > > > variables to pass on to init scripts
> > >
> > > Although I agree, my personal opinion is that its going to be a major
> > > PITA to maintain, and slow things down.
> > 
> > with the first run, we cache the 'scrubbed' env, and then just use that in the 
> > future ?
> > 
> 
> We both know when somebody finally notice that, they will bitch because
> the environment is not updated :)  Damn, did I just point that out ? 8)
> 
> > > Also, not only runscript.sh 
> > > will have to be 'whitelisted', but also /sbin/rc, which will mean that
> > > we now have to wrap two things.  I guess a solution could have been to
> > > use /sbin/runscript (the C thing) for both (should work fine
> > > as /sbin/rc's interpreter as well), as that would buy some speed and
> > > kill one bash fork, but the problem comes in when we start with a
> > > vanilla environment that do not have /etc/profile sourced.
> > 
> > mmm unification is good :)
> 
> I did not argue .. was just wondering how much gain (tears?) it will
> bring us :)
> 

Ok, the thing via /sbin/runscript won out - in baselayout-1.12.0_pre8.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]