- our natd source directory contains a samples/natd.cf.sample example config file. It would be better to offer this config file in /etc - you can force natd to read a special config file, but it doesn't look for a default config file - manpage doesn't have a FILES section - if verbose=1, natd doesn't report, which config file is being parsed Fix: - teach natd to use a default config file /etc/natd.conf if present - do not read default config file if natd has been invoked with the command line options -config | -f file introduced new variable haveConfigFile to trigger that - teach natd to report which config file will be used, if verbose is set - update documentation - new file: src/etc/natd.conf - update src/etc/Makefile, add natd.conf to BIN1 - document changes in natd.8 - Add missing FILES section in manpage Here is the fix matching against FreeBSD-4.1-STABLE of Tue Aug 29 23:43:25 CEST 2000 Sorry, no -current system around. How-To-Repeat: cd /usr/src/
Responsible Changed From-To: freebsd-bugs->ru Over to maintainer.
On Wed, Aug 30, 2000 at 05:02:54PM +0200, andreas@FreeBSD.org wrote: > Problem: > - our natd source directory contains a samples/natd.cf.sample example > config file. > > Fix: > - It would be better to offer this config file in /etc > It makes sense to install this file in /usr/share/examples/natd. > Problem: > - you can force natd to read a special config file, but it > doesn't look for a default config file > > Fix: > - teach natd to use a default config file /etc/natd.conf if present > > - do not read default config file if natd has been invoked with the > command line options -config | -f file > introduced new variable haveConfigFile to trigger that > I don't like the idea to force natd to use config file. > Problem: > - if verbose=1, natd doesn't report, which config file is being parsed > > Fix: > - teach natd to report which config file will be used, if verbose is set > Why would it do so? You already know what the file is because it is you who tells it what file it should use with -f option. After all, -v option is provided solely for debugging purposes, see the manpage. > Problem: > - manpage doesn't have a FILES section > > Fix: > - Add missing FILES section in manpage > Will do, thanks. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
On Fri, Sep 01, 2000 at 06:55:13PM +0300, Ruslan Ermilov wrote: > On Wed, Aug 30, 2000 at 05:02:54PM +0200, andreas@FreeBSD.org wrote: > > Problem: > > - our natd source directory contains a samples/natd.cf.sample example > > config file. > > Fix: > > - It would be better to offer this config file in /etc > > > It makes sense to install this file in /usr/share/examples/natd. If you don't like it in /etc, yes it would make sense, but please see my comments below. > > Problem: > > - you can force natd to read a special config file, but it > > doesn't look for a default config file > > > > Fix: > > - teach natd to use a default config file /etc/natd.conf if present > > > > - do not read default config file if natd has been invoked with the > > command line options -config | -f file > > introduced new variable haveConfigFile to trigger that > > I don't like the idea to force natd to use config file. Is there a certain technical or esthetic reason behind it ? Or is it the old "I want it minimalistic" approch (sorry ;-). We already offer prepared configuration files in /etc to make it more easy to users to configure system services. I think the current situation of not having /etc/natd.conf in /etc is not consistent with our nifty firewall enabling solution. For firewalling we offer the user a bunch of predefined defaults as example via rc.firewall. natd also is an important service concerning firewall / gateway machines. Additionaly I think it makes it easier to distribute a natd configuration through several machines, compared to an natd_flags entry in rc.conf which is mainly created via system installation. So in my eyes it would be a consistent step forward to have a /etc/natd.conf file in /etc. > > Problem: > > - if verbose=1, natd doesn't report, which config file is being parsed > > > > Fix: > > - teach natd to report which config file will be used, if verbose is set > > > Why would it do so? You already know what the file is because it is you > who tells it what file it should use with -f option. After all, -v option > is provided solely for debugging purposes, see the manpage. It was mainly for me for testing purposes, that my patch is working correctly. After that I deceided to leave it it, since it doesn't disturb in my eyes. Feel free to remove it if you dislike this little message. > > - manpage doesn't have a FILES section > > Fix: > > - Add missing FILES section in manpage > > > Will do, thanks. O.k. thanks. -- Andreas Klemm Powered by FreeBSD SMP Songs from our band >>64Bits<<............http://www.apsfilter.org/64bits.html My homepage................................ http://people.FreeBSD.ORG/~andreas Please note: Apsfilter got a NEW HOME................http://www.apsfilter.org/
On Fri, Sep 01, 2000 at 06:22:24PM +0200, Andreas Klemm wrote: > On Fri, Sep 01, 2000 at 06:55:13PM +0300, Ruslan Ermilov wrote: [...] > > I don't like the idea to force natd to use config file. > > Is there a certain technical or esthetic reason behind it ? > Or is it the old "I want it minimalistic" approch (sorry ;-). > The reason is simple - in a typical setup running natd with just a network interface as an argument is sufficient. But if we would use the configuration file by default, then how we would export ${natd_interface} into /etc/natd.conf? > We already offer prepared configuration files in /etc to make > it more easy to users to configure system services. > Sure, and by that reason we have ${natd_flags} here. Putting natd_flags="-f /etc/natd.conf" in /etc/rc.conf is essentially equivalent to part of your patch that forces natd(8) to use config file. > I think the current situation of not having /etc/natd.conf in > /etc is not consistent with our nifty firewall enabling solution. > > For firewalling we offer the user a bunch of predefined defaults > as example via rc.firewall. > > natd also is an important service concerning firewall / gateway > machines. > I can't see what you would put into /etc/natd.conf except for the default values, so forcing natd to always read this file would just be a waste of startup time. Your firewall example is not good, because firewall does not have the default (preconfigured) ruleset while natd(8) does for its options. > Additionaly I think it makes it easier to distribute a natd > configuration through several machines, compared to an natd_flags > entry in rc.conf which is mainly created via system installation. > I can't see how that would help to distribute the natd configuration. You can put ${natd_flags} into /etc/rc.conf.local, or into /etc/rc.conf.site and add /etc/rc.conf.site to the list of ${rc_conf_files}, or ... -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
On Fri, Sep 01, 2000 at 08:05:29PM +0300, Ruslan Ermilov wrote: > On Fri, Sep 01, 2000 at 06:22:24PM +0200, Andreas Klemm wrote: > > On Fri, Sep 01, 2000 at 06:55:13PM +0300, Ruslan Ermilov wrote: > [...] > > > I don't like the idea to force natd to use config file. > > > > Is there a certain technical or esthetic reason behind it ? > > Or is it the old "I want it minimalistic" approch (sorry ;-). > > > The reason is simple - in a typical setup running natd with just > a network interface as an argument is sufficient. But if we would > use the configuration file by default, then how we would export > ${natd_interface} into /etc/natd.conf? keep ${natd_interface} to specify, what interface natd should use. /etc/natd.conf is for the rest like -redirect_xxx, where multiple redirects would result in a very long command line. That was my basic idea ... I thought, the commandline in complex environments might become relatively long and prone for editing errors. The /etc/natd.conf file could contain the "complex" part of configuration, whereas the commandline only gets arguments like ${natd_interface}. > > We already offer prepared configuration files in /etc to make > > it more easy to users to configure system services. > > > Sure, and by that reason we have ${natd_flags} here. Putting > natd_flags="-f /etc/natd.conf" > in /etc/rc.conf is essentially equivalent to part of your patch > that forces natd(8) to use config file. Nearly every utility has a default config file. And I think it would be good, if FreeBSD also would have a default place for a natd config file as other services have like amd, csh, dhcclient, ... > > I think the current situation of not having /etc/natd.conf in > > /etc is not consistent with our nifty firewall enabling solution. > > > > For firewalling we offer the user a bunch of predefined defaults > > as example via rc.firewall. > > > > natd also is an important service concerning firewall / gateway > > machines. > > > I can't see what you would put into /etc/natd.conf except for the > default values, so forcing natd to always read this file would just > be a waste of startup time. Isn't it the same for hosts.allow ? > Your firewall example is not good, > because firewall does not have the default (preconfigured) ruleset > while natd(8) does for its options. o.k., I understand that difference. O.k., my last weapon, until I let you nuke my changes ;-) And what about user friendlyness ? (BTW what a wast of time, and I thought it would make sense :-/ ) -- Andreas Klemm Powered by FreeBSD SMP Songs from our band >>64Bits<<............http://www.apsfilter.org/64bits.html My homepage................................ http://people.FreeBSD.ORG/~andreas Please note: Apsfilter got a NEW HOME................http://www.apsfilter.org/
Responsible Changed From-To: ru->freebsd-bugs ENOTIME.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped