Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <he...@zu...> - 2010-05-08 13:56:11
|
I think the simplest way would be to just copy the /etc/init.d/skeleton script and insert it into the runlevel wherever it fits best. Heiko > -----Original Message----- > From: roy barnard [mailto:roy...@ya...] > Sent: Thursday, May 06, 2010 3:52 PM > To: devil linux-develop > Subject: [Devil-linux-develop] Setting up directories in /var > during boot. > > Hi, > > Can anyone help me with setting up directories in /var during boot? > > I have configured DL-1.4RC3 as a Print Server using LPRNG. > To load the parallel port kernel driver I added "modprobe lp" to > the boot.local file, which works fine. > > I then configured the printcap file, again fine. > I needed to create the directory /var/spool/lpd/lp, which I tried > to do be putting "checkpc -f" in the boot.local file and let it > automatically do this for me. > > This failed because the boot.local is executed prior to the > hostname being set which "checkpc" needs. > (my work around to put mkdir,chown and chmods into boot.local) > > Will the same issues happen when running other programs which > expect new directories in /var ? > > Is there a rc.local file later in to boot sequence I have missed? > > I wonder if a better way forward would be to have each /etc/init.d > scripts call PRE/POST start-up scripts using run-parts. The same > idea could be used for shutdown allowing cleaning up when a service > shuts down. > > An other example for this would be if you need to download a proxy > whitelist prior to squid starting but after networking is up. > > Many thanks, > Roy Barnard > > > > > > > ------------------------------------------------------------------- > ----------- > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: roy b. <roy...@ya...> - 2010-05-11 14:28:06
|
Serge,
If I just add the commands I need to the specific init.d scripts, then it will solve my issues but it also means I will need to edit and maintain these scripts each time I upgrade to the next version of DL. If I need to apply patches to any of my modified init.d scripts (from mantis for example), I will need to remove my changes, patch and then reapply my changes.
I was trying to think about more of a global solution. If this is an issue for me then I always try to consider if it might be an issue for others.
Devil-Linux is different from, say, RHEL / Centos / Fedora, because the machine is partially stateless.
The etc-mods.tar.bz2 config file only handles etc (and root) but not the other parts of the system - this design is really good for firewalls and other security devices.
I have given some thought concerning a more global implementation for my suggestions, so here goes:
1) New subdirs are created eg:
/etc/init.d/local-scripts/start/pre
/etc/init.d/local-scripts/start/post
/etc/init.d/local-scripts/stop/pre
/etc/init.d/local-scripts/stop/post
2) Each init.d script is modified along these lines (I based this on /etc/init.d/skeleton):
start)
[ -d /etc/init.d/local-scripts/start/pre/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/start/pre/$0
# Existing Start code
[ -d /etc/init.d/local-scripts/start/post/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/start/post/$0
;;
stop)
[ -d /etc/init.d/local-scripts/stop/pre/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/stop/pre/$0
# Existing Stop code
[ -d /etc/init.d/local-scripts/stop/post/$0 ] && /usr/bin/run-parts /etc/init.d/local-scripts/stop/post/$0
;;
These proposals do *NOT* modify the existing behaviour of the current boot process in any way.
The directory check is done on the ramdisk so there should be minimal performance impact.
For my specific "lpd" problem, I would create a subdir "/etc/init.d/local-scripts/start/pre/lpd" and place any scripts here, naming them to set the run-parts ordering.
To migrate my changes between DL Versions I would copy the entire contents of "/etc/init.d/local-scripts/", in the same way that I would copy any other specific configuration.
I agree that some services may never need this, like beep, but I think this type of solution would work for me on lpd, squid, firewall and networking.
Does anyone else need this type of configuration flexibility?
Many Thanks,
Roy Barnard
--- On Mon, 10/5/10, Serge Leschinsky <fi...@in...> wrote:
> From: Serge Leschinsky <fi...@in...>
> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot.
> To: dev...@li...
> Cc: "roy barnard" <roy...@ya...>
> Date: Monday, 10 May, 2010, 0:09
> On 05/08/2010 03:16 PM, roy barnard
> wrote:
> > Heiko,
> >
> > I have looked at that and it's still not perfect.
> > I you need to stop and start a service like squid you
> might also need to remember to stop and start the new
> services created from skeleton.
> >
> > The default numbering of the rc3.d services makes it
> tricky to insert the new services in the best places.
> >
> > It's better than my fudge (boot.local) but I still
> wonder if there is any better option.
> >
> > If the run-parts idea is accepted I am happy to do the
> work building all the patches.
> >
>
> Roy, as far as I understand, you are resolving the issue
> globally by adding a
> new entity. It's OK if we have at least 2-3-4 services with
> such prerequisites.
> In your case the simplest way, I guess, is direct
> modification of the init
> script - start/stop sections. You can add any commands
> there or invoke external
> scripts. It's your idea but not global and applied to only
> one service.
>
> Sincerely,
> Serge
>
> > Roy
> >
> > --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...>
> wrote:
> >
> >> From: Heiko Zuerker <he...@zu...>
> >> Subject: Re: [Devil-linux-develop] Setting up
> directories in /var during boot.
> >> To: dev...@li...
> >> Date: Friday, 7 May, 2010, 19:49
> >> I think the simplest way would be to
> >> just copy the /etc/init.d/skeleton
> >> script and insert it into the runlevel wherever it
> fits
> >> best.
> >>
> >> Heiko
> >>
> >>> -----Original Message-----
> >>> From: roy barnard [mailto:roy...@ya...]
> >>> Sent: Thursday, May 06, 2010 3:52 PM
> >>> To: devil linux-develop
> >>> Subject: [Devil-linux-develop] Setting up
> directories
> >> in /var
> >>> during boot.
> >>>
> >>> Hi,
> >>>
> >>> Can anyone help me with setting up directories
> in /var
> >> during boot?
> >>>
> >>> I have configured DL-1.4RC3 as a Print Server
> using
> >> LPRNG.
> >>> To load the parallel port kernel driver I
> added
> >> "modprobe lp" to
> >>> the boot.local file, which works fine.
> >>>
> >>> I then configured the printcap file, again
> fine.
> >>> I needed to create the directory
> /var/spool/lpd/lp,
> >> which I tried
> >>> to do be putting "checkpc -f" in the
> boot.local file
> >> and let it
> >>> automatically do this for me.
> >>>
> >>> This failed because the boot.local is executed
> prior
> >> to the
> >>> hostname being set which "checkpc" needs.
> >>> (my work around to put mkdir,chown and chmods
> into
> >> boot.local)
> >>>
> >>> Will the same issues happen when running
> other
> >> programs which
> >>> expect new directories in /var ?
> >>>
> >>> Is there a rc.local file later in to boot
> sequence I
> >> have missed?
> >>>
> >>> I wonder if a better way forward would be to
> have each
> >> /etc/init.d
> >>> scripts call PRE/POST start-up scripts using
> >> run-parts. The same
> >>> idea could be used for shutdown allowing
> cleaning up
> >> when a service
> >>> shuts down.
> >>>
> >>> An other example for this would be if you need
> to
> >> download a proxy
> >>> whitelist prior to squid starting but after
> networking
> >> is up.
> >>>
> >>> Many thanks,
> >>> Roy Barnard
>
|
|
From: Dick M. <di...@fo...> - 2010-05-11 15:35:41
|
On 05/11/10 15:27, roy barnard wrote: > If I just add the commands I need to the specific init.d scripts, then it will solve my issues but it also means I will need to edit and maintain these scripts each time I upgrade to the next version of DL. If I need to apply patches to any of my modified init.d scripts (from mantis for example), I will need to remove my changes, patch and then reapply my changes. > > I was trying to think about more of a global solution. If this is an issue for me then I always try to consider if it might be an issue for others. ... > Does anyone else need this type of configuration flexibility? It seems like a lot of overhead to run maybe one script. It does depend how much this capability is likely to be used. Although a bit of a bodge I think it would be more appropriate for one to patch the few init files that are affected after each reinstall (a relatively rare event) than impose all this dynamic on every service just in case. Or better still put the service in a wrapper script so that all startup matters are part of the application concerned. Dick |
|
From: roy b. <roy...@ya...> - 2010-05-12 12:56:00
|
Dick, > Although a bit of a bodge I think it would be more appropriate for one > to patch the few init files that are affected after each reinstall > (a relatively rare event) than impose all this dynamic on every service I don't disagree. On my main firewall I run the same version of DL for a year or two then upgrade. When a new major version comes out I normally follow the Release Candidates, so this would incease my testing. I agree that the idea of only patching init.d scripts as required is "a bit of a bodge" and in my opinion makes things more difficult for others using the mechanic,as they would first have to check if the required init.d has been patched for Pre-Start scripts and then created the directory as per previous email. I think this make the idea more complicated, I don't now if that is an issue as I would expect DL to be used by Linux Savvy SysAdmins. I did consider using an eviroment variable to enable/disable the functionality but as the directory existance checks are on the ram drive I could see no gain. I am interested in your other comment: > Or better still put the service in a wrapper script so that all > startup matters are part of the application concerned. Can you please expand your wrapper script idea, as this may be a better solution. Many Thanks, Roy Barnard --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote: > From: Dick Middleton <di...@fo...> > Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot. > To: dev...@li... > Date: Tuesday, 11 May, 2010, 16:20 > On 05/11/10 15:27, roy barnard > wrote: > > > If I just add the commands I need to the specific > init.d scripts, then it will solve my issues but it also > means I will need to edit and maintain these scripts each > time I upgrade to the next version of DL. If I need to apply > patches to any of my modified init.d scripts (from mantis > for example), I will need to remove my changes, patch and > then reapply my changes. > > > > I was trying to think about more of a global solution. > If this is an issue for me then I always try to consider if > it might be an issue for others. > ... > > Does anyone else need this type of configuration > flexibility? > > It seems like a lot of overhead to run maybe one > script. It does > depend how much this capability is likely to be used. > > Although a bit of a bodge I think it would be more > appropriate for one > to patch the few init files that are affected after each > reinstall (a > relatively rare event) than impose all this dynamic on > every service > just in case. Or better still put the service in a > wrapper script so > that all startup matters are part of the application > concerned. > > Dick > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
|
From: Heiko Z. <he...@zu...> - 2010-05-14 17:26:02
|
Hey, would it help to have multiple boot.xxx scripts? E.g. boot.mountfs, boot.network, boot.last ? We would consider those user-scripts, just like the boot.local one. Heiko Quoting roy barnard <roy...@ya...>: > Dick, > >> Although a bit of a bodge I think it would be more appropriate for one >> to patch the few init files that are affected after each reinstall >> (a relatively rare event) than impose all this dynamic on every service > > I don't disagree. On my main firewall I run the same version of DL > for a year or two then upgrade. > When a new major version comes out I normally follow the Release > Candidates, so this would incease my testing. > > I agree that the idea of only patching init.d scripts as required is > "a bit of a bodge" and in my opinion makes things more difficult for > others using the mechanic,as they would first have to check if the > required init.d has been patched for Pre-Start scripts and then > created the directory as per previous email. I think this make the > idea more complicated, I don't now if that is an issue as I would > expect DL to be used by Linux Savvy SysAdmins. > > I did consider using an eviroment variable to enable/disable the > functionality but as the directory existance checks are on the ram > drive I could see no gain. > > I am interested in your other comment: >> Or better still put the service in a wrapper script so that all >> startup matters are part of the application concerned. > > Can you please expand your wrapper script idea, as this may be a > better solution. > > Many Thanks, > Roy Barnard > > > --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote: > >> From: Dick Middleton <di...@fo...> >> Subject: Re: [Devil-linux-develop] Setting up directories in /var >> during boot. >> To: dev...@li... >> Date: Tuesday, 11 May, 2010, 16:20 >> On 05/11/10 15:27, roy barnard >> wrote: >> >> > If I just add the commands I need to the specific >> init.d scripts, then it will solve my issues but it also >> means I will need to edit and maintain these scripts each >> time I upgrade to the next version of DL. If I need to apply >> patches to any of my modified init.d scripts (from mantis >> for example), I will need to remove my changes, patch and >> then reapply my changes. >> > >> > I was trying to think about more of a global solution. >> If this is an issue for me then I always try to consider if >> it might be an issue for others. >> ... >> > Does anyone else need this type of configuration >> flexibility? >> >> It seems like a lot of overhead to run maybe one >> script. It does >> depend how much this capability is likely to be used. >> >> Although a bit of a bodge I think it would be more >> appropriate for one >> to patch the few init files that are affected after each >> reinstall (a >> relatively rare event) than impose all this dynamic on >> every service >> just in case. Or better still put the service in a >> wrapper script so >> that all startup matters are part of the application >> concerned. >> >> Dick >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Serge L. <fi...@in...> - 2010-05-14 20:59:57
|
Heiko, I'd understood it a bit different way. Each init script has 4 external calls (pre/post start, per/post stop) and those scripts are in the following filesystem hierarchy xxxx/start/pre/<service-name> xxxx/start/post/<service-name> xxxx/stop/pre/<service-name> xxxx/stop/post/<service-name> Those calls might be commented out by default to decrease unnecessary activity. In general, I like the idea, because it shows the unified way for init script extensions. And, the most attractive part, it's disabled by default :) Serge On 05/14/2010 10:25 AM, Heiko Zuerker wrote: > Hey, > > would it help to have multiple boot.xxx scripts? > E.g. boot.mountfs, boot.network, boot.last ? > We would consider those user-scripts, just like the boot.local one. > > Heiko > > Quoting roy barnard <roy...@ya...>: > >> Dick, >> >>> Although a bit of a bodge I think it would be more appropriate for one >>> to patch the few init files that are affected after each reinstall >>> (a relatively rare event) than impose all this dynamic on every service >> >> I don't disagree. On my main firewall I run the same version of DL >> for a year or two then upgrade. >> When a new major version comes out I normally follow the Release >> Candidates, so this would incease my testing. >> >> I agree that the idea of only patching init.d scripts as required is >> "a bit of a bodge" and in my opinion makes things more difficult for >> others using the mechanic,as they would first have to check if the >> required init.d has been patched for Pre-Start scripts and then >> created the directory as per previous email. I think this make the >> idea more complicated, I don't now if that is an issue as I would >> expect DL to be used by Linux Savvy SysAdmins. >> >> I did consider using an eviroment variable to enable/disable the >> functionality but as the directory existance checks are on the ram >> drive I could see no gain. >> >> I am interested in your other comment: >>> Or better still put the service in a wrapper script so that all >>> startup matters are part of the application concerned. >> >> Can you please expand your wrapper script idea, as this may be a >> better solution. >> >> Many Thanks, >> Roy Barnard >> >> >> --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote: >> >>> From: Dick Middleton <di...@fo...> >>> Subject: Re: [Devil-linux-develop] Setting up directories in /var >>> during boot. >>> To: dev...@li... >>> Date: Tuesday, 11 May, 2010, 16:20 >>> On 05/11/10 15:27, roy barnard >>> wrote: >>> >>>> If I just add the commands I need to the specific >>> init.d scripts, then it will solve my issues but it also >>> means I will need to edit and maintain these scripts each >>> time I upgrade to the next version of DL. If I need to apply >>> patches to any of my modified init.d scripts (from mantis >>> for example), I will need to remove my changes, patch and >>> then reapply my changes. >>>> >>>> I was trying to think about more of a global solution. >>> If this is an issue for me then I always try to consider if >>> it might be an issue for others. >>> ... >>> > Does anyone else need this type of configuration >>> flexibility? >>> >>> It seems like a lot of overhead to run maybe one >>> script. It does >>> depend how much this capability is likely to be used. >>> >>> Although a bit of a bodge I think it would be more >>> appropriate for one >>> to patch the few init files that are affected after each >>> reinstall (a >>> relatively rare event) than impose all this dynamic on >>> every service >>> just in case. Or better still put the service in a >>> wrapper script so >>> that all startup matters are part of the application >>> concerned. >>> >>> Dick >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Devil-linux-develop mailing list >>> Dev...@li... >>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >>> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > > > |
|
From: Heiko Z. <he...@zu...> - 2010-05-14 22:48:35
|
I did understand it the same way you did, but I was looking for a compromise which would make everyone happy. *If* we would implement something like the proposal below, I'd rather call 1 script and just give it a parameter like 'prestart' or 'poststop'. This way there would be a lot less scripts. Although I like the idea, I'm still not convinced that we should do it. It may be something we should add to Mantis for 1.5 (I created that project already in Mantis). I'd rather get a final 1.4 out, so we can start working on new features but still have a stable tree. Heiko > -----Original Message----- > From: Serge Leschinsky [mailto:fi...@in...] > Sent: Friday, May 14, 2010 4:00 PM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Setting up directories in /var > during boot. > > Heiko, > > I'd understood it a bit different way. > > Each init script has 4 external calls (pre/post start, per/post > stop) and those > scripts are in the following filesystem hierarchy > > xxxx/start/pre/<service-name> > xxxx/start/post/<service-name> > xxxx/stop/pre/<service-name> > xxxx/stop/post/<service-name> > > Those calls might be commented out by default to decrease > unnecessary activity. > > In general, I like the idea, because it shows the unified way for > init script > extensions. And, the most attractive part, it's disabled by default > :) > > > Serge > > On 05/14/2010 10:25 AM, Heiko Zuerker wrote: > > Hey, > > > > would it help to have multiple boot.xxx scripts? > > E.g. boot.mountfs, boot.network, boot.last ? > > We would consider those user-scripts, just like the boot.local > one. > > > > Heiko > > > > Quoting roy barnard <roy...@ya...>: > > > >> Dick, > >> > >>> Although a bit of a bodge I think it would be more appropriate > for one > >>> to patch the few init files that are affected after each > reinstall > >>> (a relatively rare event) than impose all this dynamic on every > service > >> > >> I don't disagree. On my main firewall I run the same version of > DL > >> for a year or two then upgrade. > >> When a new major version comes out I normally follow the Release > >> Candidates, so this would incease my testing. > >> > >> I agree that the idea of only patching init.d scripts as > required is > >> "a bit of a bodge" and in my opinion makes things more difficult > for > >> others using the mechanic,as they would first have to check if > the > >> required init.d has been patched for Pre-Start scripts and then > >> created the directory as per previous email. I think this make > the > >> idea more complicated, I don't now if that is an issue as I > would > >> expect DL to be used by Linux Savvy SysAdmins. > >> > >> I did consider using an eviroment variable to enable/disable the > >> functionality but as the directory existance checks are on the > ram > >> drive I could see no gain. > >> > >> I am interested in your other comment: > >>> Or better still put the service in a wrapper script so that all > >>> startup matters are part of the application concerned. > >> > >> Can you please expand your wrapper script idea, as this may be a > >> better solution. > >> > >> Many Thanks, > >> Roy Barnard > >> > >> > >> --- On Tue, 11/5/10, Dick Middleton <di...@fo...> wrote: > >> > >>> From: Dick Middleton <di...@fo...> > >>> Subject: Re: [Devil-linux-develop] Setting up directories in > /var > >>> during boot. > >>> To: dev...@li... > >>> Date: Tuesday, 11 May, 2010, 16:20 > >>> On 05/11/10 15:27, roy barnard > >>> wrote: > >>> > >>>> If I just add the commands I need to the specific > >>> init.d scripts, then it will solve my issues but it also > >>> means I will need to edit and maintain these scripts each > >>> time I upgrade to the next version of DL. If I need to apply > >>> patches to any of my modified init.d scripts (from mantis > >>> for example), I will need to remove my changes, patch and > >>> then reapply my changes. > >>>> > >>>> I was trying to think about more of a global solution. > >>> If this is an issue for me then I always try to consider if > >>> it might be an issue for others. > >>> ... > >>> > Does anyone else need this type of configuration > >>> flexibility? > >>> > >>> It seems like a lot of overhead to run maybe one > >>> script. It does > >>> depend how much this capability is likely to be used. > >>> > >>> Although a bit of a bodge I think it would be more > >>> appropriate for one > >>> to patch the few init files that are affected after each > >>> reinstall (a > >>> relatively rare event) than impose all this dynamic on > >>> every service > >>> just in case. Or better still put the service in a > >>> wrapper script so > >>> that all startup matters are part of the application > >>> concerned. > >>> > >>> Dick > >>> > >>> > >>> > >>> --------------------------------------------------------------- > --------------- > >>> > >>> _______________________________________________ > >>> Devil-linux-develop mailing list > >>> Dev...@li... > >>> https://lists.sourceforge.net/lists/listinfo/devil-linux- > develop > >>> > >> > >> > >> > >> > >> > >> ---------------------------------------------------------------- > -------------- > >> > >> _______________________________________________ > >> Devil-linux-develop mailing list > >> Dev...@li... > >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > >> > > > > > > > > > ------------------------------------------------------------------- > ----------- > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Dick M. <di...@fo...> - 2010-05-15 08:14:41
|
On 05/14/10 18:25, Heiko Zuerker wrote: > Hey, > > would it help to have multiple boot.xxx scripts? > E.g. boot.mountfs, boot.network, boot.last ? > We would consider those user-scripts, just like the boot.local one. If I understand the OP's problem correctly (which I might not) his problem arises because his spool directory is in ram and so its structure does not persist over reboots. This may be a common difficulty for apps in diskless systems. I think the problem might be resolved by having another script which is run after all disks, logical volumes etc are present but before any apps are started. I think this can be done from a script in /etc/init.d/boot.d similar to boot.local but which is run last. It could be called lateboot.local. One issue that might arise is that the network is not running at this point and hostname has been set to a default value. Setting the hostname to a configured value in localnet may be a way around that. Since such changes reside entirely in /etc a solution like this can be implemented by users on an ad-hoc basis and thus not impact the release of 1.4. Dick |
|
From: roy b. <roy...@ya...> - 2010-05-08 22:17:06
|
Heiko, I have looked at that and it's still not perfect. I you need to stop and start a service like squid you might also need to remember to stop and start the new services created from skeleton. The default numbering of the rc3.d services makes it tricky to insert the new services in the best places. It's better than my fudge (boot.local) but I still wonder if there is any better option. If the run-parts idea is accepted I am happy to do the work building all the patches. Roy --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote: > From: Heiko Zuerker <he...@zu...> > Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot. > To: dev...@li... > Date: Friday, 7 May, 2010, 19:49 > I think the simplest way would be to > just copy the /etc/init.d/skeleton > script and insert it into the runlevel wherever it fits > best. > > Heiko > > > -----Original Message----- > > From: roy barnard [mailto:roy...@ya...] > > Sent: Thursday, May 06, 2010 3:52 PM > > To: devil linux-develop > > Subject: [Devil-linux-develop] Setting up directories > in /var > > during boot. > > > > Hi, > > > > Can anyone help me with setting up directories in /var > during boot? > > > > I have configured DL-1.4RC3 as a Print Server using > LPRNG. > > To load the parallel port kernel driver I added > "modprobe lp" to > > the boot.local file, which works fine. > > > > I then configured the printcap file, again fine. > > I needed to create the directory /var/spool/lpd/lp, > which I tried > > to do be putting "checkpc -f" in the boot.local file > and let it > > automatically do this for me. > > > > This failed because the boot.local is executed prior > to the > > hostname being set which "checkpc" needs. > > (my work around to put mkdir,chown and chmods into > boot.local) > > > > Will the same issues happen when running other > programs which > > expect new directories in /var ? > > > > Is there a rc.local file later in to boot sequence I > have missed? > > > > I wonder if a better way forward would be to have each > /etc/init.d > > scripts call PRE/POST start-up scripts using > run-parts. The same > > idea could be used for shutdown allowing cleaning up > when a service > > shuts down. > > > > An other example for this would be if you need to > download a proxy > > whitelist prior to squid starting but after networking > is up. > > > > Many thanks, > > Roy Barnard > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > ----------- > > > > _______________________________________________ > > Devil-linux-develop mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
|
From: Heiko Z. <he...@zu...> - 2010-05-09 13:37:59
|
Does anybody else have an opinion on this? I'm hungover and it's a bit challenging today to make decisions... ;-) Heiko Quoting roy barnard <roy...@ya...>: > Heiko, > > I have looked at that and it's still not perfect. > I you need to stop and start a service like squid you might also > need to remember to stop and start the new services created from > skeleton. > > The default numbering of the rc3.d services makes it tricky to > insert the new services in the best places. > > It's better than my fudge (boot.local) but I still wonder if there > is any better option. > > If the run-parts idea is accepted I am happy to do the work building > all the patches. > > Roy > > --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote: > >> From: Heiko Zuerker <he...@zu...> >> Subject: Re: [Devil-linux-develop] Setting up directories in /var >> during boot. >> To: dev...@li... >> Date: Friday, 7 May, 2010, 19:49 >> I think the simplest way would be to >> just copy the /etc/init.d/skeleton >> script and insert it into the runlevel wherever it fits >> best. >> >> Heiko >> >> > -----Original Message----- >> > From: roy barnard [mailto:roy...@ya...] >> > Sent: Thursday, May 06, 2010 3:52 PM >> > To: devil linux-develop >> > Subject: [Devil-linux-develop] Setting up directories >> in /var >> > during boot. >> > >> > Hi, >> > >> > Can anyone help me with setting up directories in /var >> during boot? >> > >> > I have configured DL-1.4RC3 as a Print Server using >> LPRNG. >> > To load the parallel port kernel driver I added >> "modprobe lp" to >> > the boot.local file, which works fine. >> > >> > I then configured the printcap file, again fine. >> > I needed to create the directory /var/spool/lpd/lp, >> which I tried >> > to do be putting "checkpc -f" in the boot.local file >> and let it >> > automatically do this for me. >> > >> > This failed because the boot.local is executed prior >> to the >> > hostname being set which "checkpc" needs. >> > (my work around to put mkdir,chown and chmods into >> boot.local) >> > >> > Will the same issues happen when running other >> programs which >> > expect new directories in /var ? >> > >> > Is there a rc.local file later in to boot sequence I >> have missed? >> > >> > I wonder if a better way forward would be to have each >> /etc/init.d >> > scripts call PRE/POST start-up scripts using >> run-parts. The same >> > idea could be used for shutdown allowing cleaning up >> when a service >> > shuts down. >> > >> > An other example for this would be if you need to >> download a proxy >> > whitelist prior to squid starting but after networking >> is up. >> > >> > Many thanks, >> > Roy Barnard >> > >> > >> > >> > >> > >> > >> > >> ------------------------------------------------------------------- >> > ----------- >> > >> > _______________________________________________ >> > Devil-linux-develop mailing list >> > Dev...@li... >> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Serge L. <fi...@in...> - 2010-05-09 23:10:09
|
On 05/08/2010 03:16 PM, roy barnard wrote: > Heiko, > > I have looked at that and it's still not perfect. > I you need to stop and start a service like squid you might also need to remember to stop and start the new services created from skeleton. > > The default numbering of the rc3.d services makes it tricky to insert the new services in the best places. > > It's better than my fudge (boot.local) but I still wonder if there is any better option. > > If the run-parts idea is accepted I am happy to do the work building all the patches. > Roy, as far as I understand, you are resolving the issue globally by adding a new entity. It's OK if we have at least 2-3-4 services with such prerequisites. In your case the simplest way, I guess, is direct modification of the init script - start/stop sections. You can add any commands there or invoke external scripts. It's your idea but not global and applied to only one service. Sincerely, Serge > Roy > > --- On Fri, 7/5/10, Heiko Zuerker <he...@zu...> wrote: > >> From: Heiko Zuerker <he...@zu...> >> Subject: Re: [Devil-linux-develop] Setting up directories in /var during boot. >> To: dev...@li... >> Date: Friday, 7 May, 2010, 19:49 >> I think the simplest way would be to >> just copy the /etc/init.d/skeleton >> script and insert it into the runlevel wherever it fits >> best. >> >> Heiko >> >>> -----Original Message----- >>> From: roy barnard [mailto:roy...@ya...] >>> Sent: Thursday, May 06, 2010 3:52 PM >>> To: devil linux-develop >>> Subject: [Devil-linux-develop] Setting up directories >> in /var >>> during boot. >>> >>> Hi, >>> >>> Can anyone help me with setting up directories in /var >> during boot? >>> >>> I have configured DL-1.4RC3 as a Print Server using >> LPRNG. >>> To load the parallel port kernel driver I added >> "modprobe lp" to >>> the boot.local file, which works fine. >>> >>> I then configured the printcap file, again fine. >>> I needed to create the directory /var/spool/lpd/lp, >> which I tried >>> to do be putting "checkpc -f" in the boot.local file >> and let it >>> automatically do this for me. >>> >>> This failed because the boot.local is executed prior >> to the >>> hostname being set which "checkpc" needs. >>> (my work around to put mkdir,chown and chmods into >> boot.local) >>> >>> Will the same issues happen when running other >> programs which >>> expect new directories in /var ? >>> >>> Is there a rc.local file later in to boot sequence I >> have missed? >>> >>> I wonder if a better way forward would be to have each >> /etc/init.d >>> scripts call PRE/POST start-up scripts using >> run-parts. The same >>> idea could be used for shutdown allowing cleaning up >> when a service >>> shuts down. >>> >>> An other example for this would be if you need to >> download a proxy >>> whitelist prior to squid starting but after networking >> is up. >>> >>> Many thanks, >>> Roy Barnard |
