Menu
▾
▴
devil-linux-develop — developer discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(44) |
Nov
(156) |
Dec
(123) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(130) |
Feb
(156) |
Mar
(162) |
Apr
(171) |
May
(97) |
Jun
(127) |
Jul
(58) |
Aug
(81) |
Sep
(86) |
Oct
(45) |
Nov
(41) |
Dec
(84) |
| 2003 |
Jan
(71) |
Feb
(87) |
Mar
(133) |
Apr
(152) |
May
(151) |
Jun
(232) |
Jul
(320) |
Aug
(237) |
Sep
(271) |
Oct
(536) |
Nov
(301) |
Dec
(393) |
| 2004 |
Jan
(393) |
Feb
(184) |
Mar
(314) |
Apr
(225) |
May
(139) |
Jun
(77) |
Jul
(87) |
Aug
(75) |
Sep
(139) |
Oct
(50) |
Nov
(8) |
Dec
(28) |
| 2005 |
Jan
(66) |
Feb
(63) |
Mar
(14) |
Apr
(14) |
May
(8) |
Jun
(23) |
Jul
(21) |
Aug
(6) |
Sep
(29) |
Oct
(55) |
Nov
(38) |
Dec
(8) |
| 2006 |
Jan
(5) |
Feb
(10) |
Mar
(1) |
Apr
(15) |
May
(32) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(9) |
Oct
(14) |
Nov
(4) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(35) |
Aug
(49) |
Sep
(8) |
Oct
(42) |
Nov
(44) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(7) |
Mar
(8) |
Apr
(80) |
May
(74) |
Jun
(29) |
Jul
(5) |
Aug
(7) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
(19) |
Mar
(3) |
Apr
(24) |
May
(22) |
Jun
(23) |
Jul
(8) |
Aug
(23) |
Sep
(8) |
Oct
(27) |
Nov
(52) |
Dec
(27) |
| 2010 |
Jan
(36) |
Feb
(29) |
Mar
(17) |
Apr
(28) |
May
(21) |
Jun
(4) |
Jul
|
Aug
(28) |
Sep
(18) |
Oct
(6) |
Nov
(34) |
Dec
(16) |
| 2011 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(16) |
Nov
(26) |
Dec
(17) |
| 2012 |
Jan
(6) |
Feb
(34) |
Mar
(52) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(11) |
| 2015 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heiko Z. <he...@zu...> - 2003-10-11 16:06:21
|
Hey ! I'm currently reworking the build system. ( https://sourceforge.net/tracker/index.php?func=detail&aid=693367&group_id=34096&atid=410646 ) The major change is that you can define dependencies (i.e. which libs are required for this package). It uses the insserv utility and will be the same as our init system. cya Heiko |
|
From: <no...@fr...> - 2003-10-11 15:49:44
|
This email is to inform you about the release of version '0.69' of 'File::Scan' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/filescan/ The changes in this release are as follows: The W32/Swen@MM virus signature has been updated and a new functionality has been added to the scanner example, as well a fix to security vulnerability. Project description: File::Scan allows users to make multiplataform virus scanners which can detect Windows/DOS/Mac viruses. It include a virus scanner and signatures database. If you would like to cancel subscription to releases of this project, login to freshmeat.net and choose 'home' from the personal menubar at the top of the page. You'll be presented with a list of projects you're subscribed to in the right column, which you may cancel by highlighting the project in question and clicking the 'delete' button. Sincerely, freshmeat.net |
|
From: <no...@fr...> - 2003-10-11 15:48:40
|
This email is to inform you about the release of version '0.9.90' of 'GNU Transport Layer Security Library' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/gnutls/ The changes in this release are as follows: This the first prerelease of the new stable branch. Project description: GNU Transport Layer Security Library is a library which implements a secure layer over a reliable transport layer such as TCP/IP. It implements the TLS 1.0 and SSL 3.0 protocols. GnuTLS is available for beta testing. If you would like to cancel subscription to releases of this project, login to freshmeat.net and choose 'home' from the personal menubar at the top of the page. You'll be presented with a list of projects you're subscribed to in the right column, which you may cancel by highlighting the project in question and clicking the 'delete' button. Sincerely, freshmeat.net |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 14:16:20
|
Bruce Smith wrote: >>Sorry if my question has already been discussed, but is it possible to >>recover Devil-linux's "Configuration Media" from : >> - an hard disk drive ? >> - a NFS volume ? >> - the devil-linux's cdrom ? >> >> > >No on the first two, but yes DL can read the config from it's own CD >upon boot. If DL can't find a floppy or USB flash drive, then it will >check for the etc.tar.bz2 file in the root directory of the CD. > >The distribution comes with a script that lets you custom add or change >files on the CD (makes a new ISO). You can use this to add your config >to the CD. > I was just checking the linuxrc script, either I'm still not awake (very much possible).,, I didn't find the part were you load the etc.tar.bz2 from the CD ROM Heiko |
|
From: Friedrich L. <fl...@fl...> - 2003-10-11 13:07:37
|
Bruce Smith wrote: > > I can point you to a web page that says rc.local is a standard, and my > squid enhancements should be included too! (give me a minute, I have to > write those pages! ;->>>) > > Should I shut up now? Sorry, one too many beers with dinner ... :-) > If you really need a rc.local if you can please write an init script which eventually calls this file but don't modify the /etc/init.d/rc file (runlevel controller) to call this file. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 01:31:19
|
Bruce Smith wrote: >>>I'm sorry, but this is crazy. These are small stand alone programs >>>which are part the squid package, and should be included. All they do >>>is check a password crypt and send "OK" or "ERR" to stdout. >>> >>>There are tons of other non-optional programs that are just as much of a >>>security risk (none) as these are. We could go crazy making every >>>binary optional. >>> >>> >>I'm trying to find a solution which makes everybody ( a kind of ) happy. >> >> > >I understand, and it's a good idea in general. I'm trying to explain >that this isn't necessary in this particular case. > > I personally don't care.... >>But there's probably a bug anyway: when you don't select the yp stuff, >>the squid compile should actually fail since it's specified as a >>required module. >> >> > >No, that isn't a bug in this case. It compiles fine without the YP >stuff, it just doesn't run. I was surprised that it compiled too, but I >know this for a fact because the first CD I tried built fine, and it >took me awhile to figure out why yp_auth wouldn't run. (before I added >ANY of the yp programs) > > Oh ok, then never mind. Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-10-11 01:23:45
|
> >I'm sorry, but this is crazy. These are small stand alone programs > >which are part the squid package, and should be included. All they do > >is check a password crypt and send "OK" or "ERR" to stdout. > > > >There are tons of other non-optional programs that are just as much of a > >security risk (none) as these are. We could go crazy making every > >binary optional. > > I'm trying to find a solution which makes everybody ( a kind of ) happy. I understand, and it's a good idea in general. I'm trying to explain that this isn't necessary in this particular case. > But there's probably a bug anyway: when you don't select the yp stuff, > the squid compile should actually fail since it's specified as a > required module. No, that isn't a bug in this case. It compiles fine without the YP stuff, it just doesn't run. I was surprised that it compiled too, but I know this for a fact because the first CD I tried built fine, and it took me awhile to figure out why yp_auth wouldn't run. (before I added ANY of the yp programs) - BS |
|
From: Bruce S. <bw...@ar...> - 2003-10-11 01:16:40
|
> >And I also wrote some enhancements to yp_auth.c, now a patch on DL. > >(I'll spare you the details unless you really want to hear about it) > >Maybe I should submit that patch to the squid people ... > > > Yes please submit the patch, so others can benefit from it to. OK, I sent them a link and a description of my patch. It'll be interesting to see if I get a reply ... - BS |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 01:15:19
|
Bruce Smith wrote: >>>>Not necessary. All the squid authorization modules are completely stand >>>>alone binaries. They only take up a little space on the CD. They are >>>>not run unless you add a line in /etc/squid.conf something like: >>>> >>>> auth_param basic program /usr/sbin/yp_auth ... >>>> >>>> >>>Ok, good, but for a real firewall can we offer a configure option so >>>those modules can be selected on an per module basis or just "auth >>>modules yes or no"? So the security consious people can create their >>>own stripped down firewall only version. Just a thought. >>> >>> >>> >>He got a point again.... >> >>Bruce already added the option to (de-)select the nis and port mapper stuff. >>I would suggest that you (Bruce) add some more intelligence to the squid >>script. This should make everybody happy. >> >> > >I'm sorry, but this is crazy. These are small stand alone programs >which are part the squid package, and should be included. All they do >is check a password crypt and send "OK" or "ERR" to stdout. > >There are tons of other non-optional programs that are just as much of a >security risk (none) as these are. We could go crazy making every >binary optional. > > I'm trying to find a solution which makes everybody ( a kind of ) happy. But there's probably a bug anyway: when you don't select the yp stuff, the squid compile should actually fail since it's specified as a required module. Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-10-11 01:03:26
|
> >> Not necessary. All the squid authorization modules are completely stand > >> alone binaries. They only take up a little space on the CD. They are > >> not run unless you add a line in /etc/squid.conf something like: > >> > >> auth_param basic program /usr/sbin/yp_auth ... > > > > Ok, good, but for a real firewall can we offer a configure option so > > those modules can be selected on an per module basis or just "auth > > modules yes or no"? So the security consious people can create their > > own stripped down firewall only version. Just a thought. > > > He got a point again.... > > Bruce already added the option to (de-)select the nis and port mapper stuff. > I would suggest that you (Bruce) add some more intelligence to the squid > script. This should make everybody happy. I'm sorry, but this is crazy. These are small stand alone programs which are part the squid package, and should be included. All they do is check a password crypt and send "OK" or "ERR" to stdout. There are tons of other non-optional programs that are just as much of a security risk (none) as these are. We could go crazy making every binary optional. - BS |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 00:56:17
|
Howdy folks! I was thinking a little bit more about Dean's idea to provide preconfigured chroots on CD to save RAM. This would also add some more security, since the CDs are just so... so read-only. ;-) I would dedicate one ramdisk (the real /dev/ramX stuff ) per chroot, with a specific size defined per chroot. Then just link /etc to /ram/etc and /var to /ram/var The jail script can then ( if needed ) mount the directories under /var to a harddisk or so. I don't think that this will work with Postfix, since it uses a different approach with the directory structure. Thoughts ? Comments ? cya Heiko |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 00:46:18
|
Friedrich Lobenstock wrote: > Bruce Smith wrote: > >>> Isn't there a patch or config option where you could disable the >>> nis support in squid's authorization module? I would not really >>> want to run a bloated squid on a caching firewall. >> >> >> >> Not necessary. All the squid authorization modules are completely stand >> alone binaries. They only take up a little space on the CD. They are >> not run unless you add a line in /etc/squid.conf something like: >> >> auth_param basic program /usr/sbin/yp_auth ... > > > Ok, good, but for a real firewall can we offer a configure option so > those modules can be selected on an per module basis or just "auth > modules yes or no"? So the security consious people can create their > own stripped down firewall only version. Just a thought. > He got a point again.... Bruce already added the option to (de-)select the nis and port mapper stuff. I would suggest that you (Bruce) add some more intelligence to the squid script. This should make everybody happy. cya Heiko |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 00:31:21
|
Bruce Smith wrote: >>Isn't there a patch or config option where you could disable the >>nis support in squid's authorization module? I would not really >>want to run a bloated squid on a caching firewall. >> >> > >Not necessary. All the squid authorization modules are completely stand >alone binaries. They only take up a little space on the CD. They are >not run unless you add a line in /etc/squid.conf something like: > > auth_param basic program /usr/sbin/yp_auth ... > > *and* they're compiled with the stack smashing protector *and* grsecurity watches over all that stuff too. Don't you just love Devil-Linux ? cya Heiko |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 00:31:21
|
Bruce Smith wrote: >>>Now wait a minute. I thought 1.0 was frozen to new additions? :-) >>> >>> >>Standards - you might say damned standards ;-) >> >> >http://www.pathname.com/fhs/2.2/fhs-6.1.html >> >see 6.1.2 >> >> > >Now wait another minute. They have an entire section just to say that >ONE binary should be included as a standard on the Linux filesystem? >Sounds fishy to me!!! ;-) > >I can point you to a web page that says rc.local is a standard, and my >squid enhancements should be included too! (give me a minute, I have to >write those pages! ;->>>) > >Should I shut up now? Sorry, one too many beers with dinner ... :-) > > > That would have been my next question, you seem to be in a really good mood. ;-) Heiko |
|
From: Friedrich L. <fl...@fl...> - 2003-10-11 00:29:29
|
Bruce Smith wrote: >>Isn't there a patch or config option where you could disable the >>nis support in squid's authorization module? I would not really >>want to run a bloated squid on a caching firewall. > > > Not necessary. All the squid authorization modules are completely stand > alone binaries. They only take up a little space on the CD. They are > not run unless you add a line in /etc/squid.conf something like: > > auth_param basic program /usr/sbin/yp_auth ... Ok, good, but for a real firewall can we offer a configure option so those modules can be selected on an per module basis or just "auth modules yes or no"? So the security consious people can create their own stripped down firewall only version. Just a thought. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-10-11 00:22:07
|
> Isn't there a patch or config option where you could disable the > nis support in squid's authorization module? I would not really > want to run a bloated squid on a caching firewall. Not necessary. All the squid authorization modules are completely stand alone binaries. They only take up a little space on the CD. They are not run unless you add a line in /etc/squid.conf something like: auth_param basic program /usr/sbin/yp_auth ... - BS |
|
From: Heiko Z. <he...@zu...> - 2003-10-11 00:21:18
|
Bruce Smith wrote: >>>Now wait a minute. I thought 1.0 was frozen to new additions? :-) >>> >>> >>> >>Yeah it is. >>But Friedrich (he again...) send out this email with the this link.... >>http://www.pathname.com/fhs/2.2/fhs-6.1.html >>see 6.1.2 >> >>So I classified it as bug., because I got the message. ;-) >> >> > >In that sense, all the stuff I've been doing in 1.1 are really bug >fixes. I can rationalize too, check this out: :-) > >It started out with the squid authorization modules not working. >(because they were not being compiled). Then I tried the yp_auth module >and it didn't run because it needed ypbind to be running. So I added >ypbind, but it wouldn't compile without yp-tools, so I added it. Then >ypbind didn't run because it needed the RPC portmapper. So I added the >portmapper, but it wouldn't compile because it needed tcp_wrappers, so I >added it ... (talk about dependency hell! :) > >You see, all one big BUG FIX!!! ;-) >(and the most amazing thing is it even works!) >Feel free to back port the changes to 1.0! (or not :) > You'll use a CVS version anyway, so I don't even argument with you. >BTW, while I was adding all the NIS crap, I also added ypserv so it's >all there, also a bug fix since we don't want only part of the yp crap. > > You're so full of shit sometimes ! But that's why I like you. ;-) >And I also wrote some enhancements to yp_auth.c, now a patch on DL. >(I'll spare you the details unless you really want to hear about it) >Maybe I should submit that patch to the squid people ... > > Yes please submit the patch, so others can benefit from it to. cya Heiko |
|
From: Friedrich L. <fl...@fl...> - 2003-10-11 00:17:52
|
Bruce Smith wrote: > In that sense, all the stuff I've been doing in 1.1 are really bug > fixes. I can rationalize too, check this out: :-) > > It started out with the squid authorization modules not working. > (because they were not being compiled). Then I tried the yp_auth module > and it didn't run because it needed ypbind to be running. So I added > ypbind, but it wouldn't compile without yp-tools, so I added it. Then > ypbind didn't run because it needed the RPC portmapper. So I added the > portmapper, but it wouldn't compile because it needed tcp_wrappers, so I > added it ... (talk about dependency hell! :) > > You see, all one big BUG FIX!!! ;-) > (and the most amazing thing is it even works!) > Feel free to back port the changes to 1.0! (or not :) > > BTW, while I was adding all the NIS crap, I also added ypserv so it's > all there, also a bug fix since we don't want only part of the yp crap. > > And I also wrote some enhancements to yp_auth.c, now a patch on DL. > (I'll spare you the details unless you really want to hear about it) > Maybe I should submit that patch to the squid people ... Isn't there a patch or config option where you could disable the nis support in squid's authorization module? I would not really want to run a bloated squid on a caching firewall. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <br...@ar...> - 2003-10-11 00:14:59
|
> > Now wait a minute. I thought 1.0 was frozen to new additions? :-) > > Standards - you might say damned standards ;-) > > >http://www.pathname.com/fhs/2.2/fhs-6.1.html > >see 6.1.2 Now wait another minute. They have an entire section just to say that ONE binary should be included as a standard on the Linux filesystem? Sounds fishy to me!!! ;-) I can point you to a web page that says rc.local is a standard, and my squid enhancements should be included too! (give me a minute, I have to write those pages! ;->>>) Should I shut up now? Sorry, one too many beers with dinner ... :-) - BS |
|
From: Bruce S. <br...@ar...> - 2003-10-11 00:07:01
|
> >Now wait a minute. I thought 1.0 was frozen to new additions? :-) > > > Yeah it is. > But Friedrich (he again...) send out this email with the this link.... > http://www.pathname.com/fhs/2.2/fhs-6.1.html > see 6.1.2 > > So I classified it as bug., because I got the message. ;-) In that sense, all the stuff I've been doing in 1.1 are really bug fixes. I can rationalize too, check this out: :-) It started out with the squid authorization modules not working. (because they were not being compiled). Then I tried the yp_auth module and it didn't run because it needed ypbind to be running. So I added ypbind, but it wouldn't compile without yp-tools, so I added it. Then ypbind didn't run because it needed the RPC portmapper. So I added the portmapper, but it wouldn't compile because it needed tcp_wrappers, so I added it ... (talk about dependency hell! :) You see, all one big BUG FIX!!! ;-) (and the most amazing thing is it even works!) Feel free to back port the changes to 1.0! (or not :) BTW, while I was adding all the NIS crap, I also added ypserv so it's all there, also a bug fix since we don't want only part of the yp crap. And I also wrote some enhancements to yp_auth.c, now a patch on DL. (I'll spare you the details unless you really want to hear about it) Maybe I should submit that patch to the squid people ... - BS |
|
From: Heiko Z. <he...@zu...> - 2003-10-10 22:00:21
|
Bruce Smith wrote: >>>And this is LSB? http://www.devil-linux.org/newdoc/ch01s04.html >>> >>> > >I tried the LVM method and found a couple errors in the documentation. > >First you cannot use the "link" (i.e /dev/hdb1) in the LVM commands >with devfs, you have to use the full/LONG device file name. > >Typo: your "lvcreate" example needs a space before the "-n". > > Ok both are fixed. >Other than that, it works great! :-) > > cool ! cya Heiko |
|
From: Heiko Z. <he...@zu...> - 2003-10-10 21:46:20
|
Bruce Smith wrote: >>>Status: Closed >>>Resolution: Fixed >>>Assigned to: Heiko Zuerker (smiley73) >>> >>> >>Summary: add setserial >> >> > >Now wait a minute. I thought 1.0 was frozen to new additions? :-) > > Yeah it is. But Friedrich (he again...) send out this email with the this link.... http://www.pathname.com/fhs/2.2/fhs-6.1.html see 6.1.2 So I classified it as bug., because I got the message. ;-) cya Heiko |
|
From: Friedrich L. <fl...@fl...> - 2003-10-10 21:42:16
|
Bruce Smith wrote: >>>Status: Closed >>>Resolution: Fixed >>>Assigned to: Heiko Zuerker (smiley73) >> >>Summary: add setserial > > > Now wait a minute. I thought 1.0 was frozen to new additions? :-) Standards - you might say damned standards ;-) -------- Original Message -------- Subject: Re: [Devil-Linux-discuss] Re: Serial add-on card Date: Fri, 10 Oct 2003 14:26:49 -0400 From: Heiko Zuerker <hz...@pr...> Reply-To: dev...@li... To: dev...@li... On 10/10/2003 01:47:15 PM Friedrich Lobenstock wrote: >Heiko Zuerker wrote: >> On 10/10/2003 05:41:43 AM "ferris bueller" wrote: >> >>>Is it possible to add setserial to the distrib? >> >> sure >> I add it to the feature requests. But it won't be in 1.0 ! > >http://www.pathname.com/fhs/2.2/fhs-6.1.html >see 6.1.2 OK got the message. ;-) I'll classify it as a bug and add it to 1.0. cya Heiko -------- /Original Message -------- -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Friedrich L. <fl...@fl...> - 2003-10-10 21:39:55
|
Bruce Smith wrote: > If I was going to run a real service/daemon, then sure, I'd create a > script. But sometimes start scripts don't apply, IMO. > > Suppose I just want to run a simple command, like delete a file. > There is no service to "start" or "stop", as the skeleton script reads. Then create an init script called "cleanup" or whatever you want to call it. According to http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html your script then can eg. return the exitcode 3 - unimplemented feature if someone calls it with the option "stop". And in the head of the script between "### BEGIN INIT INFO" and "### END INIT INFO" just leave "Default-Stop:" empty. http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html Nice and clean. And you even can have dependences and running insserv will take care that everything is in the right order. Now if you want to do some cleanup at shutdown to then just implement the stop, add the runlevel you want it to do the cleanup in "Default-Stop:" and you are done. > It's really handy just to have a script for miscellaneous commands. But where do you call this rc.local script then? Always at the end? If someone wants to do something not always at the end, what do we gona tell him? I'd rather tell everybody the same - no exceptions. I know this might be some more work to do when you want to accomplish some little task but I think it pays of later. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-10-10 21:26:05
|
> >Status: Closed > >Resolution: Fixed > >Assigned to: Heiko Zuerker (smiley73) > Summary: add setserial Now wait a minute. I thought 1.0 was frozen to new additions? :-) - BS |
35 messages has been excluded from this view by a project administrator.
