On Mon, 2003-04-21 at 16:27, Antoine Martin wrote: > Sorry, but I meant on the server. > The client can use portmap to find out the port numbers and portmap can > be allowed through the firewall as it uses a specific port (111) > But the ports for the various nfs daemons are dynamically allocated by > portmap. You should be able to set port=0 then, and that will cause it to query the remote host's portmapper for the port number to use. If the remote host's NFS deamon is not registered with its portmapper, the standard port number of 2049 will be used instead. > > > > > * Where is the tool for configuring NIS? > > > > System Settings->Authentication or: > > > > authconfig-gtk > > Sorry, I meant on the server side again... > Client-side is there, which is why I am wondering why the server side > isn't. I'm not sure what you're after here. Why would there be a tool on your local box to configure NIS? If you're talking about hosting NIS with RedHat 9, well then you're looking at the wrong product, I believe the Enterprise Server edition has NIS services, someone correct me if wrong. > > > * kudzu: > > > - why is kudzu in /etc/fstab? it is not a filesystem option! It does > > > not belong there! > > > > It does in this case AFAIK, it's set as owner of the floppy drive due to > > probing I believe. > > >From man fstab: > "The fourth field, (fs_mntops), describes the mount options associated > with the filesystem." > I still don't see what kudzu could have to do with filesystem mount > options... Removable media drives are automatically added to /etc/fstab, this is because RedHat Linux includes the ability for users to mount and unmount removable media drives. This is done by the updfstab program (which is part of the kudzu boot-time hardware configurator). It adds and removes the necessary entries in /etc/fstab. Note that each entry managed by updfstab contains the new kudzu option this acts as a token indicating that the entry may subsequently be removed; if you wish to permanently add such an entry to your fstab, simply remove the kudzu option. > That is good if you want to disable all unsafe probes, but I just want > to be able to say: do not probe ttyS2... but keep probing to see which > monitor is plugged in. You should file a bug then about this. Why do you want it to not probe serial anyway? > > wget works perfectly behind a firewall, assuming you've configured it > > properly. I'm behind one, and it works just fine... > > Most of the time. All of the time here, several boxes in fact. I use wget a *lot*. > Any idea what needs updating? XFree? (hope it hasn't got too many deps) No. I think it's kernel related actually. > I am not asking for lokkit to do all the work, I am quite happy with my > firewall script. I just want the ability to hook it up to the system > more cleanly. rc.local isn't ideal, and iptables save does not work for > dynamic ips If you're creative enough, you can often write most rules without using any IP address at all, however if you must use specific ones, well then dynamic IP addressing just sucks. That's more the fault of the architecture of the firewall system than anything. One solution is to load the iptables-restore scripts first, and then load a specific shell script that inserts more dynamic rules in their proper places. Of course, as you can understand, this is just as clumsy as the first solution. iptables-restore is simply not very well suited for configurations where IP addresses are dynamically assigned to your firewall or where you want different behaviors depending on configuration options and so on. One possibility to get around this is to make a small script which grabs the values you would like to use in the script, then sed the iptables-restore file for specific keywords and replace them with the values collected via the small script. At this point, you could save it to a temporary file, and then use iptables-restore to load the new values. This causes a lot of problems however, and you will be unable to use iptables-save properly since it would probably erase your manually added keywords in the restore script. It is in other words a clumsy solution. What we do for our own firewall is use export environment variables that contain the IP Address of the machine in question, we then execute a script that uses those variables instead of a specific IP Address. -- Shawn <drevil@xxxxxxxxxxxx> http://www.warpcore.org/
