Re: [gentoo-dev] /etc/init.d

[Yannick Koehler <yannick.koehler@colubris.com>]

I now have my solution so I'm mostly arguing just for the fun of it now ;-)


Matt Beland wrote:
> On Mon, Mar 11, 2002 at 11:10:14PM +0200, Martin Schlemmer wrote:
> 
>>On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote:
>>
>>>Matt Beland wrote:
>>>
>>>><snip>
>>>>They are sometimes both scripts and config files. Personally, I like the 
>>>>layout of the Gentoo initscripts, particularly with regard to the "local"
>>>>script and the ability to start "simple" daemons and scripts with a config
>>>>file. However, many of the scripts we add to the init.d directory are not
>>>>custom-written for Gentoo, they're written for Linux in general. They 
>>>>include the necessary config settings in the init file itself. And those
>>>>should not be clobbered.
>>>> 
>>>>
>>>While I understand that by having seen some of those scripts in the 
>>>past, I don't see a reason not to either do work by removing those 
>>>'config' part and moving them to a /etc/ file and then committing a 
>>>patch into gentoo or the original package owner.  I'm pretty sure doing 
>>>so wouldn't be considered gentoo either.  I've seen some distro doing 
>>>that inside most of their init scripts in order to ensure no one play 
>>>with them directely and kind of filtering the dangerous settings from 
>>>the config file (always by warning the end-user thought through a log or 
>>>something like that).
>>>
> 
> But we're not talking about Gentoo init scripts, necessarily. If the script was
> installed by some program, and there's no build for it nor is there any real
> interest in creating an ebuild for it, then why create a config file and all of
> this extra effort you're proposing for what may be a very simple script. If
> the program is not part of an ebuild, you might not notice emerge clobbering
> your script thanks to an unfortunate collision in the script name.
> 

The same occurs if I create a software and I give it a name and inside a 
package there's a binary with the name which obviously will get over my 
/usr/bin file.  The chance are probably the same.  If you write binary 
you'll have this problem,  if you write script, well... you'll have the 
problem too.  Try to compare both ...  believe it or not I may write 1-2 
utilities for my testing per week and name clashing can occurs as I'm 
not the only one working on the cvs repository we use.  The trick, well, 
I move my stuff into my own folder and I create sym links, the same 
trick can safely be done in /etc/init.d.  I don't see a complication in 
there, most people that customize script surely know about sym links. 
At least this way it's easy for me to figure out if my exe are mine or 
someone else.

>>Once again ... if you have everthing latest, you should not need to edit
>>a file in /etc/init.d/ .  All the config settings is in /etc/conf.d/ .
>>This should anyhow go for most users who do not have a unusual setup.
>>
>
> I am not necessarily referring to Gentoo programs or scripts. I am aware that
> the Gentoo init scripts, as designed, do not require any protection. The issue
> is init scripts that are created for some other daemon not installed as part
> of Gentoo potentially being clobbered by a Gentoo-installed script.

But I don't see what's wrong with that.  Again the same could be 
occurring with a binary and it may take a certain time before someone 
figure it out.  The chance of that occuring are as unlikely for script 
that they are for binary because some people do test and find out that 
there's file being overwritten.  At least in that case only interested 
parties (the one with the script in use through rc-update) gets 
affected.  And not all other users who don't use that script while still 
using the 20-25 other scripts inside init.d

> <snip>
> 
>>>>That's fine for things like the tweaked pcmcia script - but what if the 
>>>>tweaks are in order to permit a specific driver to work properly? Those 
>>>>changes should not be in the default initscript, they should at most be
>>>>provided as a commented-out section - which, again, would require user 
>>>>intervention to create the required "tweaked" script.
>>>>
>>>I don't agree here.  If you have script that make a piece of hardware 
>>>work they should get committed inside Gentoo.  Otherwise other people 
>>>that have the same issues won't be able to make it work either.  If it's 
>>>  for a specific hardware combination then why making all other users 
>>>spend their time diff/mv files while you'll be the only one with that 
>>>problem?
>>>
> 
> Because this is *one example* of an issue which creates problems. It is not 
> an exclusive problem where this is the only time it would create a problem.
> 
> I updated my workstation and two test Gentoo boxes last night, including 
> baselayout changes. It took an extra minute maximum per box to look through
> the scripts, identify the two that might be a problem, and update the rest.
> I hardly think that's a terrible burden to assume.

I won't go and argue on how much time it takes.  It all depends on 
what's occuring and who's behind the screen.  What I'm saying thought is 
that right now, the way it's done it's more prone to broke a system and 
get the newbie running than helping him out while doing the reverse may 
not affect the experienced greatly while helping the newbie a lot.

> 
>>>Also having something like I mentionned called user.d where you could 
>>>put your own script file would be resolving that.  Maybe even better 
>>>would be to have gentoo write scripts by default to system.d and have 
>>>symlink inside init.d so that if it attempt to copy a script inside 
>>>init.d and see that it's not a  link to a system.d files then it doesn't 
>>>override it and warn instead.  The whole idea could also be used for the 
>>>/etc folder completely.
>>>
> 
> It would resolve the problem but break compatability with every other Linux 
> distribution. 

Euh, I'm talking about gentoo here, people are interested to run the 
same init script, / partition for other distro at the same time?  But 
even then it probably would work as sym link are kernel/fs thing and not 
distro related.  Therefore the script would get executed as long as the 
target for the link exists.  Also the operation of moving the script 
inside a system.d folder is a gentoo thing and would only be doable from 
an ebuild script.  scripts coming out of tarball would be treated as if 
they were custom and therefore they won't be a symlink and gentoo would 
not overwrite them because of that. (if it's done like I mentionned 
previously)

> 
>>><snip>
>>>Actually I think the opposite.  Convenience for me is really important. 
>>>  The less I have to do the more I'm happy and can do something else. 
>>>That's why I'm complaining at the first place.  I've merge a couple of 
>>>time baselayout and while this package shouldn't be updated frequentely 
>>>IMHO it shouldn't be kept idle either if it can still be enhanced. 
>>>Therefore I think to make the thing more convenient and less annyoing we 
>>>should enhance it a little more.
>>>
> 
> Quite franky, convenience should never be given priority in cases like this.
> System updates should be as convenient as possible *without compromising the
> system*. We're not talking about making it easier to read your email, we're
> talking about modifying a core system directory with files that are critical
> to the proper operation of the system. Convenience is and should always in
> such cases be secondary to stability and security.
> 
> 

If you do emerge without looking into each file that got changes then 
your system may have been compromised.  I mean I can write a ebuild make 
a single syntax error inside a domain entry for the file, and buy that 
domain and get the file in there and you'll download it like most people 
once its approve and you'll get a buggy version which will compromise 
your system.  If your only put attention to what you put in /etc don't 
think you're system is ok.

Yannick Koehler