RE: [Leaf-user] PPPoP DachStein Firewall going to two disk - completed
I have everything up and running on DachStein with a two floppy set-up including sshd! Thanks Everyone for the help and tips. Charles thanks for the great work on DachStein. You might think about updating the docs to include documentation support for two floppy set-ups. I did not see that in the docs and it might help others. -Original Message- From: Kevin [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 23, 2001 8:34 PM To: Michael Leone; LEAF-User Subject: RE: [Leaf-user] PPPoP DachStein Firewall going to two disk Thanks for the tip on the multidisk support!!! It seems I have run into the 255 character limit in the syslinux.cfg file. I did notice on the old Eiger it was set-up like this: display syslinux.dpy timeout 0 default linux append=load_ramdisk=1 initrd=root.lrp initrd_archive=minix ramdisk_size=16384 root=/dev/ram0 boot=/dev/fd0u1680,msdos PKGPATH=/dev/fd0u1680,/dev/fd1u1680 LRP=etc,log,local,modules,ppp,pppoe,dhcpd,dnscache,psentry,weblet,sshd,jbust er,oidentd It seems on the NEW DachStein, line 3 does not contain a line feed, so it appears like this: display syslinux.dpy timeout 0 default linux append=load_ramdisk=1 initrd=root.lrp initrd_archive=minix ramdisk_size=12288 root=/dev/ram0 boot=/dev/fd0,msdos PKGPATH=/dev/cdrom:iso9660 LRP=etc,ramlog,local,modules,dhclient,dhcpd,dnscache,weblet I know the packages are different, these are just as an example. Charles - is this correct or should this be updated to allow for loading more packages? I added a line feed and now I can load everything again. [Big Smile] Now to set-up sshd and use putty and all is done ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] JunkBuster start-up help
I have used JunkBuster version 2.0.1 on my system for over one year. Great piece of proxy and blocking software. Under Eiger, it would not auto load due to a missing SU command. I was never able to get this to work, so I had to manually start by ssh into the box and issue junkbuster /etc/junkbuster/config (no quotes) and all was well until the next reboot. I get the following error message while booting under DachStein - junkbustersu not found Has anyone fixed this error, if not what can I do to have the above command issued after boot-up? I am not a *nix expert, so any help or web page to search the answers would be helpful. Thanks attachment: winmail.dat
Re: [Leaf-user] Is this newbie even in the right ballpark with LEAF? (Summary)
Do not make the mistake of equating stripped down with low capacity. I'm not confusing the two. However, I've already identified two optimizations that can't be used with the standard LEAF distro 1) No linux support for hardware encryption accelerators; 2) No IP stack multithreading in the 2.2 kernel, which effectively neuters dual CPU hardware. Both correct, AFAIK, but you can use the 2.4 kernel with LEAF and get around the second issue... With an ipsec tunnel in place, throughput was between 3268 and 3402 KB/sec [Which is 32 to 34 megabits per second encryption rate] --- This 3.3 megabit 3DES encryption rate with the PIII/733 is only about that of a pair of T-1 lines; while the similar hardware in the Intel box has an encryption rate of 95 megabits. ??? You're confusing me...how do you go from 32-34 MBits/s to 3.3 MBits/s? Testing with single processor 733 MHz Pentium III systems, and measuring with ttcp, unencrypted traffic moved at 10644-11320 KB/s, or about 92 MBits/s (that's a pretty saturated 100Mbit ethernet link!). Adding encryption overhead caused these speeds to drop by about 1/3, to 3268-3402 KB/s, or about 27 MBits/s. My point exactly: The Intel reference design - Now being sold by H-P as well - seems to be about 3 times as efficient in 3DES encryption as FreeS/WAN with (essentially) the same PIII/733 architecture. major snipage I'm not trying to bash FreeS/WAN - Quite to the contrary! I know it's a decent product that does its job well. When I see something with about the same hardware (PIII/733) that's 3 times more efficient, though, it raises a flag. Yeah, but those are the specs with the optional hardware crypto accelerator. You can't compare the hardware assisted numbers of the intel box with the CPU only numbers of FreeS/WAN, and claim the intel box is 3x faster code, or 3x more efficient code...it's faster because it has a crypto ASIC built-in to offload the CPU. I've seen a number of reports from folks successfully using hardware acceleration with FreeS/WAN, although this is not a particularly main-stream thing. If you really want to burst to 155 MBits/sec, you'll probably need some form of hardware acceleration (at least for a year or two, until the 5-6 GHz CPU's come out). You might also want to note that the new AES crypto algorithm is much more CPU friendly than 3DES (as are several other cryto standards). You may be able to find FreeS/WAN patches for rijendall (sp?) or some of the other alternate crypto schemes that will give you higher throughput than 3DES. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD V1.0.2 Available
I have a question Charles, how/where is the /dev/cdrom symlink created? I took a stock version of your 1.0.2 image and modified it to fit my needs (i.e. set a root passwd, included some other packages like psentry, setup network config for my net, stuff like that). I then did full backups of the packages to floppy. I then created an image with the updated *.lrp files from the floppy overwriting the default packages on the CD. When I reboot, all my settings are there, but the /dev/cdrom symlink is missing and everything is trying to load from /dev/hda. I could just reset the modules to point to /dev/hda and probably be happy, but I was wondering what went wrong, and if I can just find it and fix it, that would be easier than burning a bunch of cd's experimenting. The /dev/cdrom symlink is created in the /linuxrc script, but the actual code to do this is in /var/lib/lrpkg/root.dev.mk This should be part of the root.lrp package, which is part of the bootable floppy disk image embedded on the CD-ROM (or on your boot floppy, if you're not booting directly from the CD). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Advanced firewall tricks
Doesn't look like either article's available online, but here's a link to the issue contents: http://www.sysadminmag.com/articles/2002/0201/ Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) - Original Message - From: Dan Schwartz [EMAIL PROTECTED] Subject: RE: [Leaf-user] Advanced firewall tricks Charles, do you have a URL to the articles? Thanks! Dan -Original Message- From: Charles Steinkuehler Subject: [Leaf-user] Advanced firewall tricks For those of you who don't subscribe to Sys Admin, there are a couple of interesting articles in the latest issue (Jan 2002) that are somewhat applicable to LEAF. In Halted Firewalls, Mike Murray discusses the interesting fact... [cut] Even more interesting is Redundant Internet Connections Using Linux by Seann Herdejurgen. He describes a simple method for bandwidth sharing between two interfaces, a topic that surfaces occasionally on this list... [Balance cut] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD: port forward w/dmz proxy_arp ???
No ideas?
Sorry...been busy w/XMas stuff.
Michael D. Schleif wrote:
I'm not sure where the problem is. Here are the facts:
external interface
wan1
a.b.C.157
a.b.C.156/30 -- public
proxy_arp=yes
internal interface
eth0
192.168.1.254
192.168.1.0/24 -- private
proxy_arp=no
dmz interface
eth1
a.b.D.65
a.b.D.64/26 -- public
proxy_arp=yes
How can we port forward this?
tcp internet:55631 - 192.168.1.20:5631
udp internet:55632 - 192.168.1.20:5632
We've tried:
tcp_${EXTERN_IP}_55631_${PAM}_5631
udp_${EXTERN_IP}_55632_${PAM}_5632
However, this results:
# ipchains -nvL | grep 563
0 0 MASQ tcp -- 0xFF 0x00 * 192.168.1.20 0.0.0.0/0
5631 - *
0 0 MASQ udp -- 0xFF 0x00 * 192.168.1.20 0.0.0.0/0
5632 - *
With what variable? I use the following to forward tftp and ssh (on port
221) to an internal system:
INTERN_SERVERS=udp_${EXTERN_IP}_tftp_10.28.18.33_tftp
tcp_${EXTERN_IP}_221_10.28.18.33_22
In your case, you need (assuming PAM=internal IP):
INTERN_SERVERS=tcp_${EXTERN_IP}_55631_${PAM}_5631
udp_${EXTERN_IP}_55632_${PAM}_5632
You shouldn't need to open the ports...being high ports, they should
already be open for inbound connections.
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] fsck.ext2: erro in loading shared libraries
So... I finally got nice clean download and got the hard disk going on my Dachstein system. (pick the right mirror and stomp on the shift key...) So, being faithful to Charles' HOWTO, I installed the hdsupp_s.lrp package. Fsck cannot find a shared library and neither can I... when the system boots or when I try to run fsck.ext2, I get the following message: Parallelizing fsck version 1.12 (9-Jul-98) fsck.ext2: error in loading shared libraries libuuid.so.1: cannot open shared object file: no such file or directory I am running Dachstein and loaded the Materhorn hdsupp_s, which is the latest version I have found. The disk is set-up precisely per Charles' HOWTO, except for the partition sizes (the names were not even changed to protect the innocent.) Any ideas... I am running out of them myself... Only that lots of the libraries and binaries changed between Eiger and Dachstein. I'll take a look at this, and make a new HDD support package if required, but it probalby won't be until Wedensday or so... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] PPPoP DachStein Firewall going to two disk
I am having all sorts of problems. I tried to upgrade from Eiger2Beta v4 with PPPoP to the new Dachstein. I was running a two floppy set-up because I needed ssh to admin the box. I have the single floppy up and running as designed, however I can not get the multi294.lrp to load so I can backup root and use two floppies. I did edit syslinux.cfg to add and installed on the first boot floppy. The scripts load all packages and stop at the multi294 and all others after that one. Anyone have any clues as what to try next? I really need the two floppies and no my motherboard does not support booting from CD Rom as I have fought all day with this. As others have mentioned, Dachstein supports multiple disks out of the box. To add a second (or third, or fourth...) disk, simply add it to the PKGPATH= part of syslinux.cfg. Since you mentioned you're running out of space on the syslinux command line, you may want to use the available overrides for LRP= and PKGPATH=. For PKGPATH, add the file pkgpath.cfg on your boot floppy. For LRP=, use lrpkg.cfg. Some details on how this works are in the CD-ROM readme (available online: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/README.txt ). I hope to get some floppy-orineted documetation of these new features written soon. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD: port forward w/dmz proxy_arp ???
Charles ==
My bad ;
Charles Steinkuehler wrote:
No ideas?
Sorry...been busy w/XMas stuff.
Michael D. Schleif wrote:
I'm not sure where the problem is. Here are the facts:
external interface
wan1
a.b.C.157
a.b.C.156/30 -- public
proxy_arp=yes
internal interface
eth0
192.168.1.254
192.168.1.0/24 -- private
proxy_arp=no
dmz interface
eth1
a.b.D.65
a.b.D.64/26 -- public
proxy_arp=yes
How can we port forward this?
tcp internet:55631 - 192.168.1.20:5631
udp internet:55632 - 192.168.1.20:5632
We've tried:
tcp_${EXTERN_IP}_55631_${PAM}_5631
udp_${EXTERN_IP}_55632_${PAM}_5632
However, this results:
# ipchains -nvL | grep 563
0 0 MASQ tcp -- 0xFF 0x00 * 192.168.1.20 0.0.0.0/0
5631 - *
0 0 MASQ udp -- 0xFF 0x00 * 192.168.1.20 0.0.0.0/0
5632 - *
My normal attempts resulted in failed connections. Since this box uses
wanpipe for EXTERN_IP, I couldn't troubleshoot with the normal tools
(e.g., iptraf, tcpdump, c.) I kept thinking that I should see
5563[1|2] in the output of ipchains -nvL -- I was wrong ;
I found the problem, which is nothing to do with /etc/network.conf --
indeed, the normal INTERN_SERVERS stuff works perfectly with this
network!
However, why is it that EXTERN_IP *and* port do not show up in ipchains
-nvL ? Is it because 5563[1|2] are already open?
With what variable? I use the following to forward tftp and ssh (on port
221) to an internal system:
INTERN_SERVERS=udp_${EXTERN_IP}_tftp_10.28.18.33_tftp
tcp_${EXTERN_IP}_221_10.28.18.33_22
In your case, you need (assuming PAM=internal IP):
INTERN_SERVERS=tcp_${EXTERN_IP}_55631_${PAM}_5631
udp_${EXTERN_IP}_55632_${PAM}_5632
You shouldn't need to open the ports...being high ports, they should
already be open for inbound connections.
Yes.
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] PPPoP DachStein Firewall going to two disk
Kevin wrote: I have the single floppy up and running as designed, however I can not get the multi294.lrp to load so I can backup root and use two floppies. I did edit syslinux.cfg to add and installed on the first boot floppy. The scripts load all packages and stop at the multi294 and all others after that one. You don't need the multi294.lrp, there is multi-disk support in dachstein already. Just change PKGPATH= /dev/fd0u1680 in syslinux.cfg to something like PKGPATH=/dev/fd0u1680,/dev/fd1u1680 where /dev/fd1u1680 means that you have a second 1680KB formatted floppy in the second floppy drive. Ewald Wasscher ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] whereis ifconfig
Please forgive my obvious newbie-ness but you gotta start somewhere. I am trying to run Eiger Stein Dynamic on a floppy-only PI system with identical Netgear FA311 PCI NIC's. EigerStein Dynamic is pretty old. You should consider moving to a current LEAF distribution ... DachStein or Oxygen. OK I will do that, I was told Oxygen was hard to configure and wasn't sure what all was in it. I have adapted the network.conf and the modules file, I uncommented 8390 as per Charles S's suggestion, and also uncommented ne2k-pci My internal network (already going off another router I built) is a 192.168.100.0/24 so I set all the eth1 stuff accordingly. eth1 seems to be able to ping. I can not locate ifconfig on this system, that's how I've always checked settings. Is that a redhat thing or what? what. That is, it is an Eiger thing. Eiger and its descendants use the ip command (the package is sometimes called iproute) instead of ifconfig. Try ip link show or ip addr show, depending on what information you want. BTW, you will also find the route command to be missing. Use netstat -nr where you would otherwise use route -n. Yes I noticed that too. My error the same as his: dhcp says no subnet has been written (0.0.0.0) and that I should fix up dhcpd.conf but I looked at it and it does have the correct subnet in it. What EXACTLY am I supposed to do to dhcpd.conf? What EXACTLY are you running DHCP for? The most obvious thing, to get an IP dynamically from external and then share it by routing packets internally. I know I don't need my router to dish out IP's dynamically. My old and now dead hand made redhat based router got its ip from DHCP but all the downstream boxes have static private IP's that I made up for them. I figured I need the DHCP client not the server. My mistake not pruning it off the floppy. I hope it comes in its own .lrp!! If you already have address assignments on your LAN, you don't need your LEAF router to dish them out (so you can either ignore this error or fix it by deleting the package from the load list). If you need to use DHCP to get your *external* address assigned by your ISP, you need to run dhclient (the client), -NOT- dhcpd (the server). Any other info you need to answer this I will give. I don't even know what's important and what's not. You guys do, so ask me the questions. It also says that eth0 will be the first PCI slot and eth1 will be the second. That's top to bottom, skips irrelevent, yes? Just covering that base--this is the first time I've allowed myself the luxury of 2 PCI NICS in the same box, all the old ones have had at least one ISA. It *should* work that way. In practice, I never count on it. I use a netgear FA311 NIC in another router i built, the driver for it is natsemi.o which is not in the modules directory in the EigerStein distro I have. Should I just put this module in as well? Not if the router works now (that is, if the interfaces are recognized, can be assigned IP addresses, and support pings). Netgear and Linux modules have been moving targets. I wouldn't say it exactly works. From what I could tell the internal interface may have been working somewhat because I could ping internally on it. It was unclear just exactly what was working before I knew how to do the equivalents of ifconfig and route -n Seemed like the DHCP stuff didn't work (ergo nothing meaningful off of eth0) but that is probably dhcp and not the modules since the both use the same one. and if I do should I recomment 8390? For those dependency things I'm beginning to see via inductive reasoning that the dependency is implied by the order in which they are listed? Right, I think. If module A depends on module B, then B has to be loaded (that is, listed in /etc/modules.conf) ahead of A. Thanks you guys on this list are great. I want to see a linux router for every home LAN by the end of 2002. Go team! Colleen Dick Laugh your way to the bank at http://www.navehumor.com ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] FW: Debian Weekly News - December 19th, 2001
Debian Slink is the original basis of LRP and its descendants. It is now available at http://archive.debian.org/dists/slink/ -Richard -Original Message- From: Martin Schulze [mailto:[EMAIL PROTECTED]] Sent: Friday, December 21, 2001 6:09 AM To: Debian News Channel Subject: Debian Weekly News - December 19th, 2001 --- Debian Weekly News http://www.debian.org/News/weekly/2001/34/ Debian Weekly News - December 19th, 2001 --- Archive.debian.org is Back. The server that holds old Debian releases, aliased to archive.debian.org, has been [1]resurrected after it was offline for several months due to hardware problems. The machine now runs with a nice new 144 GB RAID and a new host, the Computer Science Department at the [2]University of Minnesota and is now administered by Scott Dier. However, sad news: One of the new disks began to fail recently. snip --- References 1. http://lists.debian.org/debian-mirrors-0111/msg0.html 2. http://www.cs.umn.edu/ snip ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Is this newbie even in the right ballpark with LEAF? (Summary)
-Original Message- From: Charles Steinkuehler Subject: Re: [Leaf-user] Is this newbie even in the right ballpark with LEAF? (Summary) Do not make the mistake of equating stripped down with low capacity. I'm not confusing the two. However, I've already identified two optimizations that can't be used with the standard LEAF distro 1) No linux support for hardware encryption accelerators; 2) No IP stack multithreading in the 2.2 kernel, which effectively neuters dual CPU hardware. Both correct, AFAIK, but you can use the 2.4 kernel with LEAF and get around the second issue... With an ipsec tunnel in place, throughput was between 3268 and 3402 KB/sec [Which is 32 to 34 megabits per second encryption rate] --- This 3.3 megabit 3DES encryption rate with the PIII/733 is only about that of a pair of T-1 lines; while the similar hardware in the Intel box has an encryption rate of 95 megabits. ??? You're confusing me...how do you go from 32-34 MBits/s to 3.3 MBits/s? My bad: I slipped a decimal point major snipage I'm not trying to bash FreeS/WAN - Quite to the contrary! I know it's a decent product that does its job well. When I see something with about the same hardware (PIII/733) that's 3 times more efficient, though, it raises a flag. Yeah, but those are the specs with the optional hardware crypto accelerator. You can't compare the hardware assisted numbers of the intel box with the CPU only numbers of FreeS/WAN, and claim the intel box is 3x faster code, or 3x more efficient code...it's faster because it has a crypto ASIC built-in to offload the CPU. I've seen a number of reports from folks successfully using hardware acceleration with FreeS/WAN, Oh? I didn't see any drivers for hardware accelerators - Or did I miss something. although this is not a particularly main-stream thing. If you really want to burst to 155 MBits/sec, you'll probably need some form of hardware acceleration (at least for a year or two, until the 5-6 GHz CPU's come out). If I need more CPU horsepower, I'll use 21264 (Alpha) CPU's instead. You might also want to note that the new AES crypto algorithm is much more CPU friendly than 3DES (as are several other cryto standards). You may be able to find FreeS/WAN patches for rijendall (sp?) or some of the other alternate crypto schemes that will give you higher throughput than 3DES. Charles Steinkuehler Cheers! Dan When the chips are down, the buffalo is empty ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] serial port in Dachstein cd 1.02
Is Dachstein CD Serial port ready? If not I think I need a HowTo. Thanks in advance.
Re: [Leaf-user] whereis ifconfig
On 12/24/01 at 11:16 AM, Colleen R. Dick [EMAIL PROTECTED] wrote: EigerStein Dynamic is pretty old. You should consider moving to a current LEAF distribution ... DachStein or Oxygen. OK I will do that, I was told Oxygen was hard to configure and wasn't sure what all was in it. I don't think Oxygen is any harder than Red Hat, say, and it certainly has a lot more documentation in the configuration files. As for what is in it it has a lot more than Dachstein, but then it's more of a general distribution than Dachstein is. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Dachstein-CD V1.0.2 Available
[snip] The /dev/cdrom symlink is created in the /linuxrc script, but the actual code to do this is in /var/lib/lrpkg/root.dev.mk Found it, thanks! This should be part of the root.lrp package, which is part of the bootable floppy disk image embedded on the CD-ROM (or on your boot floppy, if you're not booting directly from the CD). Ok, next question. I update and backup my root.lrp to floppy. When I reboot, it does not read my root.lrp from the floppy, all my settings (i.e. my .ssh directory in /root) is missing. So, what the heck am I missing? I don't have to use that root.lrp to burn a new cd in order to use the it, do I? I know I must be missing something simple. Thanks and Happy Holidays! Tony Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD V1.0.2 Available
- Original Message - From: Tony [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Charles Steinkuehler' [EMAIL PROTECTED] Sent: Tuesday, December 25, 2001 3:20 AM Subject: RE: [Leaf-user] Dachstein-CD V1.0.2 Available [snip] The /dev/cdrom symlink is created in the /linuxrc script, but the actual code to do this is in /var/lib/lrpkg/root.dev.mk Found it, thanks! This should be part of the root.lrp package, which is part of the bootable floppy disk image embedded on the CD-ROM (or on your boot floppy, if you're not booting directly from the CD). Ok, next question. I update and backup my root.lrp to floppy. When I reboot, it does not read my root.lrp from the floppy, all my settings (i.e. my .ssh directory in /root) is missing. So, what the heck am I missing? I don't have to use that root.lrp to burn a new cd in order to use the it, do I? As far as I know, no settings are stored in the root.lrp package The /root directory belongs to the local.lrp package what other settings don't get saved ?? Regards, Etienne I know I must be missing something simple. Thanks and Happy Holidays! Tony Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
