Re: Changes to contrib bootscripts
Jeremy Huntwork wrote: > On 5/21/11 1:20 PM, Bryan Kadzban wrote: >> The service script might work, but it's a complete re-training for me, >> and I'm a bit of a curmudgeon. That's probably not a reason to avoid >> doing it, though. :-P > > The first picture that came back in google's image search for curmudgeon: > > http://americaexplained.files.wordpress.com/2011/02/curmudgeon.jpg That's it! -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 5/21/11 1:20 PM, Bryan Kadzban wrote: > The service script might work, but it's a complete re-training for me, > and I'm a bit of a curmudgeon. That's probably not a reason to avoid > doing it, though. :-P The first picture that came back in google's image search for curmudgeon: http://americaexplained.files.wordpress.com/2011/02/curmudgeon.jpg :-D JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 5/21/11 12:52 PM, DJ Lucas wrote: > Oh, I didn't realize that it had continued beyond the new network script > and ifup/ifdown scripts, or rather I read it as just example, not an > actual suggestion. Give me a few minutes to run through the thread again. I didn't actually see the new scripts. I took a cursory look at what was in subversion and it looked the same as before... Maybe I missed something? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
DJ Lucas wrote: > There are a couple of packages, non-obvious packages at that, that > install their own bootscripts and they work in the current proposal > without modifications using the lsb functions. I must not install them, then. Alternately, I do install them, but don't care to use their bootscripts (I think that might apply to one; fcron, bind, dhcpcd v5, or something like that, maybe). :-) > I suspect that we'll see more in the future, however, I have not > actually confirmed that they do not work within the old layout > (sysinit/S change is required). Changing sysinit to S is fine. I don't generally use the rc*.d directory names, just init.d. > Bryan pointed out that the old layout lent itself better to tab > completion, the savings is only one keystroke, but you actually have > to type more _characters_ in the new layout as opposed to pressing > tab repeatedly. I don't yet know how much work is involved in > reversing that decision, but it should at least be discussed. If other packages are a concern, then I think an /etc/init.d symlink might work as well. There's already too much in /etc that starts with in or ini, so adding one more entry there doesn't seem too bad. I dislike littering /usr/sbin with symlinks, for the record. I actually dislike it even more since it's in /usr, given that these are links to bootscripts, but moving it to /sbin is also pretty bad (since now it's a much larger chunk of a small directory). It's also one more set of links that needs to be kept up to date (though that's probably rare). The service script might work, but it's a complete re-training for me, and I'm a bit of a curmudgeon. That's probably not a reason to avoid doing it, though. :-P signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 11:17 AM, Robert Xu wrote: > On Sat, May 21, 2011 at 08:10, Jeremy Huntwork > wrote: >> On 5/21/11 2:48 AM, DJ Lucas wrote: >>> I do plan to add a "service" script later that would alleviate the issue >>> completely, as was suggested by Jeremy a few months ago, but I'm a >>> little stuck as far as how to handle multi-level, conditional tab >>> completions in bash, so it is on hold for a sec. Plus, I haven't seen >>> how Jeremy and Archaic handle that in LightCube OS yet. My simple >>> solution turned out to be not as simple as I had thought. That may even >>> turn out to be a C program included with initd-tools or somewhere >>> later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any >>> ideas/suggestions on that? >> We've kept it simple, but possibly we have not met all the reqs: >> >> http://dev.lightcube.us/sources/lsb-bootscripts/service >> >> And then that's just installed to /usr/sbin: >> >> http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec >> > Have you guys thought of using insserv? It's what SuSE has been using > for years and what Debian Squeeze and on is using. > No, I haven't looked at it. I think it is a bit more than what we were looking for initially, but that could certainly be an option. For right now, I'd like to use the simple method as it will certainly come to completion on the stated goal a little quicker. What we have now (in this thread) works well enough. > Or, you could just symlink all the initscripts to a rc location in > /usr/sbin/rc > like /usr/sbin/rcnetwork for tab completion. I don't think the tab completion would be any better in that you'd have to add an additional complete command every time a script is added to the system as opposed to it being dynamic (see my response to Jeremy). There is a simple solution, others use it in a case statement for a different purpose, I just haven't been able to understand it just yet as the documentation is lacking IMO. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/21/2011 07:10 AM, Jeremy Huntwork wrote:
> On 5/21/11 2:48 AM, DJ Lucas wrote:
>> I do plan to add a "service" script later that would alleviate the issue
>> completely, as was suggested by Jeremy a few months ago, but I'm a
>> little stuck as far as how to handle multi-level, conditional tab
>> completions in bash, so it is on hold for a sec. Plus, I haven't seen
>> how Jeremy and Archaic handle that in LightCube OS yet. My simple
>> solution turned out to be not as simple as I had thought. That may even
>> turn out to be a C program included with initd-tools or somewhere
>> later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any
>> ideas/suggestions on that?
> We've kept it simple, but possibly we have not met all the reqs:
>
> http://dev.lightcube.us/sources/lsb-bootscripts/service
>
> And then that's just installed to /usr/sbin:
>
> http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec
>
Ok, cool. Thank you for the links. That was the direction I had headed.
I got stuck with the bash completion though. Every time I try to use a
second conditional for tab completion, those options of second functions
in the event of -W, show in the first list. What I would like to do is
use the value of $prev (in the example below) to set another variable
that greps for "Usage:", sed out that and the brackets, and use IFS of
"|" to display the options for the selected script. The example below is
good enough to get a list of available scripts by typing "servi"
#!/bin/bash
# Begin /etc/profile.d/service-completion.sh
#
# service scriptname {start|stop|restart|reload|force-reload|status}
#
__service()
{
local cur prev opts
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
prev="${COMP_WORDS[COMP_CWORD-1]}"
opts="$(ls /etc/init.d | sed 's@/etc/init.d/@@')"
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
}
complete -F __service service
# End /etc/profile.d/service-completion.sh
While that is kind of cool IMO, I really do want it to spit out the
script options as well. Prior to a few days ago, I had never explored
the complete command.
>> 2nd, Jeremy's concern was the contents of rc.site. I agreed with all
>> suggestions, including combining lfs-fucntions with init-functions, save
>> one. I've made all the agreed changes locally. Most of everything in
>> rc.site has been moved into rc, with the exception of clock params,
>> hostname, conditional boot off/on and prompt time, boot logging off/on,
>> and the command that is run when a boot script ends in an unexpected
>> error ('read Enter' in our case). The last one I had just added and was
>> on the fence about, but after consideration, I've decided that to be
>> something that should be user configurable. Perhaps a function is best,
>> as I had suggested originally instead of putting a command in a variable
>> in a user configuration file. Make it configurable there by a simple
>> yes/no for PAUSE_ON_ERROR or some such.
> Sounds great. I can live with that.
Ok. I'll skip the easy way out. :-)
>> Theads got long quick, and a little OT at times, but I do believe that
>> is the remainder of the concerns.
> Are we treating the handling of network down logic as a separate issue?
> I think there was still some discussion out on that one.
Oh, I didn't realize that it had continued beyond the new network script
and ifup/ifdown scripts, or rather I read it as just example, not an
actual suggestion. Give me a few minutes to run through the thread again.
> JH
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On Sat, May 21, 2011 at 08:10, Jeremy Huntwork wrote: > On 5/21/11 2:48 AM, DJ Lucas wrote: >> I do plan to add a "service" script later that would alleviate the issue >> completely, as was suggested by Jeremy a few months ago, but I'm a >> little stuck as far as how to handle multi-level, conditional tab >> completions in bash, so it is on hold for a sec. Plus, I haven't seen >> how Jeremy and Archaic handle that in LightCube OS yet. My simple >> solution turned out to be not as simple as I had thought. That may even >> turn out to be a C program included with initd-tools or somewhere >> later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any >> ideas/suggestions on that? > > We've kept it simple, but possibly we have not met all the reqs: > > http://dev.lightcube.us/sources/lsb-bootscripts/service > > And then that's just installed to /usr/sbin: > > http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec > Have you guys thought of using insserv? It's what SuSE has been using for years and what Debian Squeeze and on is using. Or, you could just symlink all the initscripts to a rc location in /usr/sbin/rc like /usr/sbin/rcnetwork for tab completion. -- later, Robert Xu -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 5/21/11 2:48 AM, DJ Lucas wrote:
> I do plan to add a "service" script later that would alleviate the issue
> completely, as was suggested by Jeremy a few months ago, but I'm a
> little stuck as far as how to handle multi-level, conditional tab
> completions in bash, so it is on hold for a sec. Plus, I haven't seen
> how Jeremy and Archaic handle that in LightCube OS yet. My simple
> solution turned out to be not as simple as I had thought. That may even
> turn out to be a C program included with initd-tools or somewhere
> later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any
> ideas/suggestions on that?
We've kept it simple, but possibly we have not met all the reqs:
http://dev.lightcube.us/sources/lsb-bootscripts/service
And then that's just installed to /usr/sbin:
http://dev.lightcube.us/projects/lightcubeos/repository/entry/lightcube_os/trunk/packages/lsb-bootscripts/lsb-bootscripts.spec
> 2nd, Jeremy's concern was the contents of rc.site. I agreed with all
> suggestions, including combining lfs-fucntions with init-functions, save
> one. I've made all the agreed changes locally. Most of everything in
> rc.site has been moved into rc, with the exception of clock params,
> hostname, conditional boot off/on and prompt time, boot logging off/on,
> and the command that is run when a boot script ends in an unexpected
> error ('read Enter' in our case). The last one I had just added and was
> on the fence about, but after consideration, I've decided that to be
> something that should be user configurable. Perhaps a function is best,
> as I had suggested originally instead of putting a command in a variable
> in a user configuration file. Make it configurable there by a simple
> yes/no for PAUSE_ON_ERROR or some such.
Sounds great. I can live with that.
> Theads got long quick, and a little OT at times, but I do believe that
> is the remainder of the concerns.
Are we treating the handling of network down logic as a separate issue?
I think there was still some discussion out on that one.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Changes to contrib bootscripts
On 05/20/2011 03:47 AM, Matthew Burgess wrote:
> On Thu, 19 May 2011 17:25:15 -0500, DJ Lucas
> wrote:
>> Matthew Burgess wrote:
>>
>>> make-aux-files.sh: Why renaming things to lsb-bootscripts? If we're
>>> migrating (which I think we should), shouldn't we just move the lsb
>>> scripts out of contrib and then continue to refer to the package as
>>> the lfs-bootscripts?
>>>
>> No change, just file layout in SVN.
> As I noticed after doing an 'svn update' in my own working copy.
>
>>> chapter07/console.xml: 1) Where did the consolelog script/configuration
>>> go?
>>>
>> echo "kernel.printk=4">> /etc/sysctl.conf
> Ah yes, of course. Is this documented anywhere though, seeing as it's
> a change from how we handled it in the past?
No actually. It really wasn't mentioned in the book other than in
passing on the console page, but no example. Should probably find a way
to put fit that in.
>
>>> chapter07/network.xml: I quite like Red Hat's layout, but probably just
>>> because
>>> I've become accustomed to it through my day job. On that distro,
>>> network device
>>> config lives in /etc/sysconfig/network-scripts, and those files namely
>>> ifcfg-
>>> and route-. I certainly don't see the need for subdirectories
>>> under
>>> whichever directory is chosen to house the network configuration files,
>>> but
>>> maybe I'm being blinkered by my only needing static wired interfaces to
>>> be
>>> configured.
>> Might have to configure multiple services on one interface, for instance
>> ip and ipx, or maybe one interface does not provide default gw, but a
>> static route is still needed for a dual homed machine.
> OK, I guess that makes sense :)
>
>>> Why are network scripts put under /lib/network-services? Again,
>>> possibly blinkered
>>> by my exposure to Red Hat, but keeping the service scripts in the same
>>> directory as
>>> the interface config files makes sense to me.
>> Executables don't belong in /etc, this one was covered in Jeremy's thread.
> Yeah, that makes sense too; unfortunately I only glanced over Jeremy's thread.
>
> Thanks. In my opinion, this is ready to go in, but I don't know whether you
> want final approval from Bruce?
>
> Matt.
>
Thanks Matt. Sorry I took so long to get back to you (I didn't want to
type a long message on a touch screen). I think we are just about all on
the same page, but I got the impression above that Bruce did want to
review it as well. Also, Bryan and Jeremy still have outstanding
questions. I'll summarize:
1st, Bryan's concern was about moving from
/etc/rc.d/{rc{sysinit,0,1,2,3,4,5,6},init}.d to
/etc/{rc{S,0,1,2,3,4,5,6},init}.d - There are a couple of packages,
non-obvious packages at that, that install their own bootscripts and
they work in the current proposal without modifications using the lsb
functions. I suspect that we'll see more in the future, however, I have
not actually confirmed that they do not work within the old layout
(sysinit/S change is required). The reason for the new layout originally
was only to follow other distros' examples of the time that they were
written (mid 2007). I personally like the new layout better without the
extra path element, and that is probably only muscle memory...hardly
justification. Bryan pointed out that the old layout lent itself better
to tab completion, the savings is only one keystroke, but you actually
have to type more _characters_ in the new layout as opposed to pressing
tab repeatedly. I don't yet know how much work is involved in reversing
that decision, but it should at least be discussed.
I do plan to add a "service" script later that would alleviate the issue
completely, as was suggested by Jeremy a few months ago, but I'm a
little stuck as far as how to handle multi-level, conditional tab
completions in bash, so it is on hold for a sec. Plus, I haven't seen
how Jeremy and Archaic handle that in LightCube OS yet. My simple
solution turned out to be not as simple as I had thought. That may even
turn out to be a C program included with initd-tools or somewhere
later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any
ideas/suggestions on that?
2nd, Jeremy's concern was the contents of rc.site. I agreed with all
suggestions, including combining lfs-fucntions with init-functions, save
one. I've made all the agreed changes locally. Most of everything in
rc.site has been moved into rc, with the exception of clock params,
hostname, conditional boot off/on and prompt time, boot logging off/on,
and the command that is run when a boot script ends in an unexpected
error ('read Enter' in our case). The last one I had just added and was
on the fence about, but after consideration, I've decided that to be
something that should be user configurable. Perhaps a function is best,
as I had suggested originally instead of putting a command in a variable
in a user configuration file. Make it configurable there by a simple
yes/no for PAUSE_ON_ERROR or some such.
Theads got lon
