APLawrence - Information and Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds Get APLawrence.com by RSS














(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version



Best of the Newsgroups: changing ip address, dhcp, ipfilter


What is this stuff?

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):



Lot of good suggestions here

From: "Brian K. White" <brian@aljex.com>
References: <vjptti92rith2d@corp.supernews.com> <raorjv4mnei2d1n8fbe509g0kmg6oraqoa@4ax.com> <vjqavihoj2n009@corp.supernews.com> <dklqjvou8nkd8c2srj5kcrjhh4hnfpehu9@4ax.com> <vjst1u2aoe1l18@corp.supernews.com> 
Subject: Re: Help request: network connectivity
Date: Sun, 17 Aug 2003 13:53:23 -0400


"bill" <nobody@spamcop.net> wrote in message
news:vjst1u2aoe1l18@corp.supernews.com...
> Jeff Liebermann wrote:
>
> > On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobody@spamcop.net> wrote:
> >
> >
> >>it turns out that someone (read "me") debugged a new set of ipf rules
> >>when I removed an interface and forgot to write the new rules to
> >>ipf.rules.  This box has been up ever since (over a year) and I was
> >>using the test rules, but when I rebooted the old rules were reloaded.
> >
> >
> > Ah, IP filters wasn't around when I first scribbled that document.
> > I'd like to add those to the document.  Could you save me the trouble
> > of reaching 3 ft to turn on the OSR5 server box and kindly supply the
> > full filenames that have IP's and/or names in IP filters?  Nice to
> > hear about a box with >1 year uptime.
>
>
> /etc/ipf.rules




If I am not mistaken that is not a file Jeff should really list as if it
were a standard system file. Although I agree he should list it as a
possibility and/or a suggested replacement for whatever currently might be
found on joe random box.

I can't find anything in the man pages that ship with TLS709 or 5.0.7 that
even makes a suggestion about start scripts or config files so people will
have done all kinds of wierd things inventing their own arrangement from
scratch.

For example, on Tony Lawrences site, there is a nice post spelling out all
of someones live working ipf/ipnat setup so people can have a working
example to start from. That person used:
  /etc/rc2.d/S99aroute
  /usr/local/bin/firewallsetup

He should mention, somehow, to look for a file or files *like* this, but
that it might be named anything and that the script that runs it might
also be named anything or be called from anywhere in the rc startup maze.

Much the same way that until 5.0.6 there was no official place to put your
default route command.



Even the supplied /etc/mkfilters script avoids the issue by only printing
it's suggested rules to stdout.

Since sco's ipf/ipnat are just sco builds of an open source package that
already existed on other platforms, perhaps we should adopt the
arrangement used on one of those other platforms, or as close as can be
translated to OSR's directory structure? Your suggested /etc/ipf.rules
appears to follow that logic. Here is what I found...

netbsd:
/etc/rc.d/ipf.sh
/etc/rc.d/ipnat.sh
/etc/ipf.conf
/etc/ipnat.conf

openbsd:
?? probably /etc/rc.d/ip*.sh or /usr/local/etc/rc.d/ip*.sh
/etc/ipf.rules
/etc/ipnat.rules

freebsd:
/etc/rc.d/ipf.sh or /usr/local/etc/rc.d/ipf.sh
/etc/rc.d/ipnat.sh or /usr/local/etc/rc.d/ipnat.sh
/etc/ipf.rules
/etc/ipnat.rules


The start scripts obviously need to change.
I would suggest:
  /etc/init.d/ipf
  /etc/init.d/ipnat
and symlinks:
  /etc/rc2.d/S98ipf
  /etc/rc2.d/S99ipnat

The config files look good to me. I'd probably use .conf instead of .rules
so that they look like other config files to keep life simpler.
Supporting this idea, I found "man -a ipf" produced, among others,
ipf(SFF) which describes "ipf.conf" but does not say what directory to put
it in.

There is also a reasonable case for using
  /etc/default/ipf
  /etc/default/ipnat
instead of
  /etc/ipf.conf
  /etc/ipnat.conf

but I think I would slightly prefer the latter.

If anyone has a good rc script that also accounts for the event of the sco
box being a DHCP client perhaps it should be posted somewhere and
recommended to any who ask anything about ipf/ipnat.

Then answering questions would be a lot simpler. You could just answer
within this agreed-upon context and say: "this is not _the_ way to do it,
but it's _a_ way and it's the way most of us do it and as such it's the
way we will answer questions. get this tar, edit these files..."
The tar would contain the rc scripts, the symlinks (or the rc scripts
could have enable/disable options like the prngd & openssh ones have), and
the config files.

Then Jeff's page could list the files but only while at the same time
suggesting their use in the first place.

Brian K. White  --  brian@aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani

Brian later added:

Since writing the above, I have discovered, or there appeared, an official start script and config files.

cnfig files do not exist by default, and as stated, mkfilters will not create them except to stdout, and the start script is not enabled by default, nor does it provide a handy "enable" option. So given all that it's easy to miss all of it.

But there is a start script and so the correct name and path for the config files is wherever that start script looks for them.

So, the real answers are:

create either or both of the following files as desired: /etc/ipf.conf /etc/ipnat.conf

and enable ipf/ipnat to run at boot by doing: ln -s /etc/init.d/ipfnat /etc/rc2.d/S99ipfnat

and manually run it from now to the next boot: /etc/init.d/ipfnat start

Now the start script is in place and during boot it will look for both config files and if either are found it will launch the appropriate facility. There is only one start script for both services, but you do not need both (or any) config files. If a config file doesn't exist, that facility is not started. So really, everyone should always have the start script enabled and then merely create or remove one or both config files as desired.

after making changes to the config files you can trigger ipf/ipnat to reread them any time you want by doing: /etc/init.d/ipfnat stop /etc/init.d/ipfnat start

I haven't found a way to tell the running daemons to re-read the config files that doesn't involve clearing all rules momentarily*, which means this may break some active tcp sessions. I haven't tested since I don't actually use ipnat much on sco, just ipf, and so haven't tried setting up an ssh login session trough a sco box running ipnat to see if above would break it.

This applies as of 5.0.6 stock (ie: even before any patches) 





Click here to add your comments


---November 18, 2004

Since writing the above, I have discovered, or there appeared, an official start script and config files.

cnfig files do not exist by default, and as stated, mkfilters will not create them except to stdout, and the start script is not enabled by default, nor does it provide a handy "enable" option. So given all that it's easy to miss all of it.

But there is a start script and so the correct name and path for the config files is wherever that start script looks for them.

So, the real answers are:

create either or both of the following files as desired:
/etc/ipf.conf
/etc/ipnat.conf

and enable ipf/ipnat to run at boot by doing:
ln -s /etc/init.d/ipfnat /etc/rc2.d/S99ipfnat

and manually run it from now to the next boot:
/etc/init.d/ipfnat start

Now the start script is in place and during boot it will look for both config files and if either are found it will launch the appropriate facility. There is only one start script for both services, but you do not need both (or any) config files. If a config file doesn't exist, that facility is not started. So really, everyone should always have the start script enabled and then merely create or remove one or both config files as desired.

after making changes to the config files you can trigger ipf/ipnat to reread them any time you want by doing:
/etc/init.d/ipfnat stop
/etc/init.d/ipfnat start

I haven't found a way to tell the running daemons to re-read the config files that doesn't involve clearing all rules momentarily*, which means this may break some active tcp sessions. I haven't tested since I don't actually use ipnat much on sco, just ipf, and so haven't tried setting up an ssh login session trough a sco box running ipnat to see if above would break it.

This applies as of 5.0.6 stock (ie: even before any patches)




Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar



/Bofcusm/2294.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.



More:
       - OSR5
       - Bofcusm


Unix/Linux Consultants

Skills Tests

Guest Post Here











My Favorites

Change Congress