[RFC] support PEER in ipv4-static service
jwrober at linuxfromscratch.org
Tue Jul 13 12:44:29 PDT 2004
Kevin P. Fleming wrote:
> Matthew Burgess wrote:
>> Is this a suggestion for the testing branch, i.e. to compliment the new
>> bootscripts & iproute2 setup? I see it supports things like PPP etc.,
>> which are dealt with more fully in BLFS. I'm not averse to putting this
>> patch in the book at all, as I don't believe it is sensible to have BLFS
>> overwrite our default ipv4-static configuration.
> Well, that's a difficult question to answer. The patch is not really for
> the book, it's for the bootscripts, so it's not necessarily related to
> testing, unstable or anything else. This begs the question of whether
> the bootscripts should have features in them that are not used in the
> LFS books (or even the BLFS books) at all, just because they are good
> things to have and some users will want to use them after they get their
> system up and running.
> This particular item will be used if I decide to try to get OpenVPN into
> BLFS, as the best OpenVPN service script arrangement uses ipv4-static
> with a specified peer address. However, I've not even proposed that to
> the BLFS crew yet, so it really can't be used as a justification.
> I've also heard from others in the group that "if users want to add
> these features they should figure out how", which may include using
> hints, patches or just doing it directly. While I can certainly see some
> value in that, I also think that distributing a hint/patch/whatever that
> adds 6 lines or so to an existing service script, and keeping that patch
> up to date as new versions of lfs-bootscripts are released, seems rather
> silly. However, if that logic is extended too far, we could end up with
> far more in the book/bootscripts that is really wanted.
> I guess the real issue is this: the lfs-bootscripts are the one item
> that makes LFS most like a "distro", rather than a book. If we really
> want the bootscripts to be robust, reliable and not have to be edited by
> users to use basic functionality (even if that functionality is not used
> in the LFS/BLFS books), then these sorts of patches should go into them.
> No reference to these features need ever appear in the books; if people
> want to write hints on how to use these features that are already there
> that's great; obviously if someone asks on lfs-chat or blfs-dev others
> can point them to these existing features as well.
> The only worry I've
>> got though, is that people will see the words "used for ...PPP" here and
>> think that we're adding (or intending to add) complete PPP support to
>> LFS, which I think was agreed not going to happen?
> No, this is underlying functionality that _could_ be used for PPP, but
> has nothing to do with the LFS book itself. If there's a better place to
> discuss lfs-bootscripts development that is not book-related, please let
> me know and I'll move the discussion there :-)
I _really_ like the bootscripts. They are awesome. The only changes I
make to them is what I call beautification (change what echo says to the
screen). Other than that, I love everything they do and how they work.
I agree with Kevin that the bootscritps are very "distro-like", but in
our case are a necessary evil. We cannot expect the regular Linux user
to have the bash or ash scripting knowledge to write their own. I could
never to do it. I think the inclusion of all this new stuff makes the
package well suitable for LFS and BLFS (you do what you want your box to
do). What I think we can do to meet both sides needs, is have the
makefile only install what the LFS book uses by default (the bare bones
basics). In the book, identify this fact, point the reader to the
README in the root of the source directory for more goodies. Hints or
other stuff can be provided to help/assist in the use of the more
esoteric specialty features of the scripts, but the foundation is laid
already, so the maintenance of patches to the scripts goes away.
My two cents. Did I mention I really like the scripts! Kudos
More information about the lfs-dev