Re: [leaf-user] Shorewall rfc1918 list

2004-09-24 Thread Patrick Benson
Erich Titl wrote:
 
 Hi everybody
 
 Networks 83.0.0.0 and 84.0.0.0 have been assigned to RIPE last year. In my version 
 (1.4.8) of shorewall these networks are still blocked by the rfc1918 rules. It it 
 probably worthwhile to remove these two networks from /etc/shorewall/rfc1918 if they 
 should still be there.

Erich,

Shorewall 2.0.1 and later uses a file called bogons that lists the IP
ranges reserved by the IANA while the rfc1918 file will only apply to
those three ranges that are reserved by RFC1918 so any up-to-date
modifications that apply to IANA range listings will be found in the
bogons file. 

http://shorewall.net/pub/shorewall/errata/2.0.8/bogons
http://www.completewhois.com/bogons/


Regards,
Patrick

-- 
Patrick Benson
Stockholm, Sweden


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


RE: [leaf-user] Re: leaf-user digest, Vol 1 #2420 - 7 msgs

2004-09-24 Thread James Neave
 Any ideas how to make installation/configuration easier?

 Firewall users are not so likely to be Linux users.  Most Linux
distros
 come with installable/installed firewalls, and workstations can be
made
 fairly secure in themselves.  A LEAF installation tool should either
run
 with whatever OS the user has and is seeking to protect, i.e. most
likely
 Windows, or it should include its own OS.  Do the developers want to
 develop a Windows-based customization tool?  Now, one of LEAF's
 attractions is running from a floppy, but even with a 1680KB floppy
 there's little room left.  So if developers choose this route the
initial
 download would likely be two diskettes, one for the customization tool
 and some packages, and one for the common code base to be customized.
 Certainly both are do-able, but trying to develop a useful
customization
 tool isn't easy.

You know, I was just thinking that while I was reading this.
A configuration wizard for windows would be very handy. Something to
automate initial configuration and even updating, puts the correct LRPs
on, adds your network card modules to the disk.

Yes, something that stores your configuration and can then assembles a
floppy/ISO/HDD/CF/ETC LEAF image from the configuration, scripts and
LRPs + modules tarball. I know there is buildtool, but I'm thinking of
something simpler. No compiling, just grab the latest LRP, insert the
configuration files and burn/write/summon/conjure the disk. And no linux
required.

It could be made modular, allowing integration of new and updated LRPs.

But simple to start with, a windows or platform independent application
that automates the download, assembly and initial configuration (meaning
the necessary steps from the installation docs) would greatly increase
the accessibility of LEAF for the likes of, well, me.

Not that is would be simple of course...

Just my 2EUR.

James.


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


[leaf-user] challenge

2004-09-24 Thread B.
Hej all,
this is a true challenge:
We built up a server/router environment for a good friend and configured 
apache on the server being connected through the Bering-Box working with 
dyndns. We use ezipupdate for actualizing the name service.
Now our friend found a 'hacker' who tries to attack our machines. He told 
he will use the name service actualisation for this.
Now here is my thought about that: Knowing the URL, he will set up a 
sniffer on the IP. With that he will also be able to listen to the 
ezipupdate's dialogue with the dyndns server. Now the question: Is this 
dialogue crypted?

Thanks for any answer.
Boris

---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Lynn Avants
On Thursday 23 September 2004 11:23 pm, Geoff Nordli wrote:

 Just to add some more information.  I created an additional file in the
 same folder that somehow was successfully backed up, but I have no clue
 where it is kept.  I tried doing a tarball listing of the etc, root,
 dnscache, tinydns packages and it didn't show up.  So somehow it gets
 restored when the machine reboots.

 Is it possible that another package will overwrite the entire contents of a
 directory during startup?

 So are you saying that the etc package backup process parses all the *.list
 files in the /var/lib/lrpkg folder to see what files in the etc directory
 that it is supposed to backup.

Geoff,
The etc package is supposed to catch all the files that don't belong to
another package in /etc IIRC. The failure of the etc package to backup
this file indicates that it belongs to the dnscache package (which is 
correct). The way the backup system works is that package and backup
information is stored in flat text files in the /var/lib/lrpkg folder. The 
packagename.list file stores populated filenames for the packagename.
The packagename.include file stores the filenames to be included in
the backup process. The packagename.exclude stores the filenames
that should NOT be included in the backup process. 

To be clear about how this should be on your system, 'cd' to the 
/var/lib/lrpkg directory. The config filename should be listed in
dnscache.include file AND NOT included in the dnscache.exclude file.
UNLESS this configuration is actually intended to be stored somewhere
else that I don't remember and is likely included in the dnscache supplement
to the Bering Users Manual. 
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] Re: leaf-user digest, Vol 1 #2420 - 7 msgs

2004-09-24 Thread Lynn Avants
On Thursday 23 September 2004 04:47 am, James Neave wrote:
 You know, I was just thinking that while I was reading this.
 A configuration wizard for windows would be very handy. Something to
 automate initial configuration and even updating, puts the correct LRPs
 on, adds your network card modules to the disk.
[...]
 But simple to start with, a windows or platform independent application
 that automates the download, assembly and initial configuration (meaning
 the necessary steps from the installation docs) would greatly increase
 the accessibility of LEAF for the likes of, well, me.

 Not that is would be simple of course...

I don't think most people can even begin to understand the complexity
of what is being desired here. A lot of work has been done and far 
more discussed into making this a reality. The only cross-platform 
options for GUI is Java, TK/TCL, and maybe Perl which drives the
frontend that you see and doesn't actually *do* any work. The backend
that does what you don't see must be able to be run on the LEAF box
limiting things to either Ash shell script or compiled C. Futher there isn't
a good way to work this w/o changing the packaging format to include
integration. BTW, there is over 200 available packages available for the
various branches. Upgrades to the packages (different conf files, variables
and the like) need to be approached and either the system must be
network savy (which LEAF generally isn't) to transfer information OR 
you must create a new floppy everytime. 

In short, you need a person or group that programs entirely different
languages on different systems and set a defination of the process to
take that integrates. Then you will likely have to completely rework
every package that could be added to the system to conform. Multiply
this by the various branches and their idiosyncrises to each other and
the support that the developers of the system will have to deal with
and things just really aren't freaking simple at all. To be flat honest,
I'd done a lot more work on this if attempting to feed my family and
keep a house over their head hasn't been near impossible the last
two years in this economy. 

If you just want something extremely that works like this, my suggestion
is to use FreeSCO or BBImage. If you want or need more than they
offer, please feel free to contribute to the system we have been working
on or write one that meets your needs. I'll be honest the entirety of LEAF
is NOT simple by any means of the imagination as it is now. It has taken
Cisco years to provide a similar sytem with all of their resources to do the'
same thing that is generally misconfigured after being available to the
public. 

Paul, you've been telling me how simple this should be for years, PLEASE,
PLEASE to a stab at doing it if it is so simple. I also expect you to realease
it to the general public and support it through all the ways it can be borked
by the end users. Only then can you convey to me how simple this process
really is.
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] challenge

2004-09-24 Thread Lynn Avants
On Friday 24 September 2004 09:11 am, B. wrote:
[...]
 Now the question: Is this
 dialogue crypted?

I doubt it, check with the developers to ez-ipupdate to get
the answer to this question. To be honest, any publically 
available webserver is a major point of compromise that
is not necessarily protected by the firewall which doesn't
actually look into any contents of any information... expecially
not accepted traffic. You would likely want to check with
the developers of the webserver program for vunerabilities
as well.
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


RE: [leaf-user] Re: leaf-user digest, Vol 1 #2420 - 7 msgs

2004-09-24 Thread Mike Noyes
On Thu, 2004-09-23 at 02:47, James Neave wrote:
 You know, I was just thinking that while I was reading this.
 A configuration wizard for windows would be very handy. Something to
 automate initial configuration and even updating, puts the correct LRPs
 on, adds your network card modules to the disk.

James,
Configuration during initial setup is considerably different than when
running. We have discussed both topics on our devel list in the past.
Feel free to join the conversation there. Comments and suggestions by
the extended community are welcome.

Initial Setup  Configuration:

A) Live Linux CD: use to generate a target image.
e.g. http://distrowatch.com/dwres.php?resource=cd

B) Web based build system.
e.g. http://www.rom-o-matic.net/5.0.4/


Operational/Production Configuration:

Lead Developer: Chad Carr 
http://cvs.sourceforge.net/viewcvs.py/leaf/src/config/leaf-tools/

Lead Developer: Nathan Angelacos
http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/

-- 
Mike Noyes mhnoyes at users.sourceforge.net
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


RE: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Geoff Nordli
[EMAIL PROTECTED] wrote:
 On Thursday 23 September 2004 11:23 pm, Geoff Nordli wrote:
 
 Just to add some more information.  I created an additional file in
 the same folder that somehow was successfully backed up, but I have
 no clue where it is kept.  I tried doing a tarball listing of the
 etc, root, dnscache, tinydns packages and it didn't show up.  So
 somehow it gets restored when the machine reboots.
 
 Is it possible that another package will overwrite the entire
 contents of a directory during startup? 
 
 So are you saying that the etc package backup process parses all the
 *.list files in the /var/lib/lrpkg folder to see what files in the
 etc directory that it is supposed to backup.
 
 Geoff,
 The etc package is supposed to catch all the files that don't
 belong to
 another package in /etc IIRC. The failure of the etc package to backup
 this file indicates that it belongs to the dnscache package (which is
 correct). The way the backup system works is that package and backup
 information is stored in flat text files in the
 /var/lib/lrpkg folder. The
 packagename.list file stores populated filenames for the
 packagename. The packagename.include file stores the filenames to
 be included in the backup process. The packagename.exclude stores
 the filenames that should NOT be included in the backup process.
 
 To be clear about how this should be on your system, 'cd' to the
 /var/lib/lrpkg directory. The config filename should be listed in
 dnscache.include file AND NOT included in the dnscache.exclude file.
 UNLESS this configuration is actually intended to be stored somewhere
 else that I don't remember and is likely included in the
 dnscache supplement
 to the Bering Users Manual.

In the /var/lib/lrpkg directory I ran:

#grep root\/servers *.list
dnscache.exclude.list:etc/dnscache/root/servers/*

So this tells me that the root/servers directory is only listed in the
dnscache.execlude.list file.  So backing up etc.lrp should include the
/dnscache/root/servers/* directory.  I performed a backup using lrcfg.

In the location where the etc.lrp package is stored I ran:

tar tzvf etc.lrp | grep servers

But there was no output (there is a file listing if I don't grep it).  If
that tarball stored the servers directory then it should show up.  

I guess the question is when does etc build its package list.  At the
beginning when it first starts up or when it does the backup?

Thanks Lynn.





---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread M Lu
Hi Geoff,

Just tried on my Bering U 2.2 with

/var/lib/lrpkg more dnscache.exclude.list
etc/dnscache/log/supervise
etc/dnscache/supervise
etc/dnscache/root/ip/*

/var/lib/lrpkg more dnscache.list
usr/bin/dnscache
etc/dnscache
etc/init.d/dnscache
var/lib/lrpkg/dnscache.*
etc/dnscache/root/servers/*

and when I tried to untar the temporary LRP then I see the files. Are those
file you want to backup?

/tmp/ttt tar xzvf ../dnscache.lrp
..
etc/dnscache/root/servers/myhouse.com
etc/dnscache/root/servers/.1.168.192.in-addr.arpa
etc/dnscache/root/servers/@
..
var/lib/lrpkg/dnscache.version
var/lib/lrpkg/dnscache.list
var/lib/lrpkg/dnscache.help
var/lib/lrpkg/dnscache.exclude.list
var/lib/lrpkg/dnscache.conf
var/lib/lrpkg/dnscache.bktype
etc/init.d/dnscache
etc/dnscache
etc/dnscache/seed
etc/dnscache/root
etc/dnscache/root/servers
..
etc/dnscache/root/ip
etc/dnscache/run
etc/dnscache/env
etc/dnscache/env/QUERYLOG






- Original Message - 
From: Geoff Nordli [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 23, 2004 6:27 PM
Subject: [leaf-user] I can't backup files in /etc/dnscache/root/servers


 Hello Everyone.

 For some reason I can't backup the files that are stored in
 /etc/dnscache/root/servers for the dnscache package.  I am not sure why
but
 the dnscache has an exclusion on that directory.  Even if I remove that
 exclusion I still can't backup it up.

 Can someone please tell me how to backup those files,

 Thanks,



 Geoff Nordli
 Asentus Consulting Group
 4941 Hartwig Cres
 Nanaimo, BC V9V 1R2
 Office:  604.639.6928
 Cell:  250.714.4102



 ---
 This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
 Project Admins to receive an Apple iPod Mini FREE for your judgement on
 who ports your project to Linux PPC the best. Sponsored by IBM.
 Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
 
 leaf-user mailing list: [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/leaf-user
 SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Lynn Avants
Geoff,
Ok, I got into my router to figure this out.
You are attempting to configure these options in the wrong place.
Dnscache is configured out of the /etc/dnscache/env/ directory.
If you use the lrcfg menu, select 3. for packages, then dnscache.
The first two option are likely to be the ones you need to change.

The files you are attempting to modify are created on the fly by 
the binary and init script, therefore non-savable. The server file
is to include only root servers, which you are not.
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


RE: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Geoff Nordli
[EMAIL PROTECTED] wrote:
 Geoff,
 Ok, I got into my router to figure this out.
 You are attempting to configure these options in the wrong place.
 Dnscache is configured out of the /etc/dnscache/env/ directory.
 If you use the lrcfg menu, select 3. for packages, then dnscache.
 The first two option are likely to be the ones you need to change.
 
 The files you are attempting to modify are created on the fly by
 the binary and init script, therefore non-savable. The server file
 is to include only root servers, which you are not.

My understanding is if you have specific domains that you would like
resolved then you have to populate the /etc/dnscache/root/servers/ directory
with the name of domains and the servers that are able to resolve those
domains.  Tinydns is resolving my domaina.com so I created the domaina.com
file in the /etc/dnscache/root/servers and entered 127.0.0.1.  So when
dnscache gets a request for domaina.com it will pass that on to the server
residing on 127.0.0.1.

Have a great day!

Geoff




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Lynn Avants
On Friday 24 September 2004 06:34 pm, Geoff Nordli wrote:
 My understanding is if you have specific domains that you would like
 resolved then you have to populate the /etc/dnscache/root/servers/
 directory with the name of domains and the servers that are able to resolve
 those domains.  Tinydns is resolving my domaina.com so I created the
 domaina.com file in the /etc/dnscache/root/servers and entered 127.0.0.1. 
 So when dnscache gets a request for domaina.com it will pass that on to the
 server residing on 127.0.0.1.

Ahhh a more complete picture now, is tinydns residing on the same box?
dnscache cannont be authoritive, so you need dnscache to refer to tinydns
for the private domain. First you CANNOT bind both tinydns and dnscache
to the same address. As resolv.conf generally points to localhost first, you 
need to bind tinydns to 127.0.0.1. Then you bind dnscache to the actual
interface (stock is 192.168.1.254) and have your private clients use this
internal address as their DNS server. Setup this way, the clients will poll
dnscache which will in turn poll tinydns. 

It appears that you are attempting to run dnscache authoritive, which breaks
several RFC's and is NOT suggested. Bind the interfaces/address'es as 
noted above. Setup the services through the lrcfg menu, as that is where
they are to be configured running DJB's daemontools instead of the
typical init.d scripts.

Link to the Bering Users Manual concerning dnscache:
http://leaf.sourceforge.net/devel/jnilo/dnscache3.html#AEN96
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


Re: [leaf-user] Re: leaf-user digest, Vol 1 #2420 - 7 msgs

2004-09-24 Thread Lynn Avants
On Friday 24 September 2004 05:59 pm, Tom Eastep wrote:
 In my 35 years in this business, I've come to learn that all
 System/Programming projects are easy in the opinion of people who are
 not responsible for delivering them.

You've done a mind boggling job with Shorewall and Seawall 
throughout the years Tom. I've been simply amazed at all the
work and document (not to mention support) that you have
done. It sure won't ever be underrated by me. Even more amazing
is that it hasn't cost you a divorce. :)
-- 
~Lynn Avants
Linux Embedded Appliance Firewall Developer
http://leaf.sourceforge.net
http://guitarlynn.homelinux.org:81


---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html


RE: [leaf-user] I can't backup files in /etc/dnscache/root/servers

2004-09-24 Thread Geoff Nordli
[EMAIL PROTECTED] wrote:
 On Friday 24 September 2004 06:34 pm, Geoff Nordli wrote:
 My understanding is if you have specific domains that you would like
 resolved then you have to populate the /etc/dnscache/root/servers/
 directory with the name of domains and the servers that are able to
 resolve those domains.  Tinydns is resolving my domaina.com so I
 created the domaina.com file in the /etc/dnscache/root/servers and
 entered 127.0.0.1. So when dnscache gets a request for domaina.com
 it will pass that on to the server residing on 127.0.0.1.
 
 Ahhh a more complete picture now, is tinydns residing on
 the same box?
 dnscache cannon be authoritive, so you need dnscache to
 refer to tinydns
 for the private domain. First you CANNOT bind both tinydns
 and dnscache
 to the same address. As resolv.conf generally points to
 localhost first, you
 need to bind tinydns to 127.0.0.1. Then you bind dnscache to
 the actual
 interface (stock is 192.168.1.254) and have your private
 clients use this
 internal address as their DNS server. Setup this way, the
 clients will poll
 dnscache which will in turn poll tinydns.
 
 It appears that you are attempting to run dnscache
 authoritive, which breaks
 several RFC's and is NOT suggested. Bind the interfaces/address's as
 noted above. Setup the services through the lrcfg menu, as
 that is where
 they are to be configured running DJB's daemontools instead of the
 typical init.d scripts. 
 
 Link to the Bering Users Manual concerning dnscache:
 http://leaf.sourceforge.net/devel/jnilo/dnscache3.html#AEN96


I read through the jnilo's page about the dns and everything was configured
OK.  I installed the daemontl.lrp package as per the documentation.  One of
the nice things about Leaf/Bering is the great documentation, especially the
shorewall configuration.  

BTW tinydns and dnscache binding to the same ports had me stumped for a
couple of hours.  Though it was so obvious after I figured it out.  Maybe
this is something that should be added to the documentation when downloading
tinydns.  

I added the /etc/dnscache/root/servers/* to the dnscache.list file and did a
backup.  It looks like the files were backed up OK.  I won't know for sure
until I do a reboot next week.  If this is the correct fix then it should
also be added to the dnscache docs.

Thanks for all your time.

Have a great weekend.

Geoff 




---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html