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)

/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.
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.
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