Re: [Bastille-linux-discuss] Release!

[Jay B. <ja...@ba...>]

In the wise words of Peter W:

> On Thu, Oct 19, 2000 at 08:51:49PM -0700, Jay Beale wrote:
> > In the wise words of Peter W:
> > >  - it will replace the different "official" variables with what you
> > >    choose the second time around [there may be a workaround for that [0]]
> > >  - but it will modify the existing firewall script, so any other changes
> > 
> >                        ^---  (I think Peter meant "not modify" :)   )
> 
> No, by "existing script" I meant to suggest "the script currently in use",
> as opposed to "the new ipchains template script". That is, it starts with
> whatever is in init.d, instead of using the current, blank template.

Got it.  Cool.  Yes, so, to fully clarify, we're both saying that it should
leave your hacked script's main code alone.
---

Gets a little scary when we're going into three or four levels of reply on a
footnote...

> > > [0] IIRC, the Bastille "replace" API that the installer uses only replaces
> > > the first instance of a matching line, so if you duplicated the official
> > > variable assignment lines in bastille-firewall, the second install run
> > > would modify the first assignment lines, which your dupes would override
> > > at run time. E.G. if you dupe the DNS_SERVERS line like this
> > >  DNS_SERVERS=""
> > >  DNS_SERVERS=""
> > > and then run through the 1.1.1 script, it should change that to
> > >  DNS_SERVERS="0.0.0.0/0"
> > >  DNS_SERVERS=""
> > > with the end result being that the effect of your script is preserved.
> > 
> > <grokking code...>
> > 
> > OK, so it's actually the other way around.  The API routine replaces every
> > line that matches the needed pattern, returning the number of lines
> > replaced.  So, in the previous example, both lines would be changed.
> 
> OK, so this might work for a workaround:
> 
> DNS_SERVERS=""
> X=foo;DNS_SERVERS=""
> 
> Bastille should clobber the first of those lines, but not the second.

Yup, definitely.

> Thanks for double checking on that API issue, Jay. The only change I might
> suggest is having another optional argument to the B_replace() call, an
> int N representing the maximum number of lines to replace. Values of N < 1
> (or calls with N not specified) would emulate the current behavior,
> replacing all matches.

This is a great idea! Much like the issues in C, like strcpy() vs strncpy().

Let's do this.

  - Jay