[Leaf-user] Dachstein-CD, ipsec rsasigkey ???
Why does this *never* complete? ipsec rsasigkey --verbose 2048 mykey Is there some special source for randomness other than /dev/random? I've tried this with various lengths, including the shortest allowable: 16 It appears to hang on two (2) different machines: 486/66 celeron/600 What do you think? -- 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] portfw to *multiple* hosts ???
Charles Steinkuehler wrote: ??? Please explain a bit more about exactly what you're trying to accomplish... Large medical images -- some approaching gigabyte sizes. The internal network connects multiple facilities. The images may need to be shared across multiple facilities. Our preferred solution is to put one (1) copy of each image on a large and robust fileserver inside their network. The catch is, they are using proprietary systems for viewing and analyzing the images and we may not be granted access nor information adequate to implementing our preferred solution. Currently, the remote sources are using their proprietary systems (black boxes) to auto-magically transfer the files directly to one (1) proprietary system inside our customer's network. Yes, this looks everyway like ftp -- except the proprietary system vendor says, no, it is not that simple ; When one of these images is needed on another proprietary system inside this network, somebody needs to push the required file to another proprietary system. Our customer wants ``pull'' access from any given system. In brainstorming alternatives, this occured to me: send images | V internet | V firewall | - | | | V V V host_1host_2host_n ... Regardless, whether or not this is the best solution for this application, how can this be done? Well, it sounds like you're in black-box hell : Do I detect a bit of empathy from somebody who's been here before? My current understanding of your problem (please correct me if I'm wrong): - A remote, black-box system pushes images to one black-box system in your customer's network (let's call it Master) - Your customer can push images from the Master black box system to several other black-box systems (Slaves) - Your customer wants to be able to view images from any slave system w/o having to push the file from the master system (ie pull, not push) Yes -- this pretty much sums it up ; Without an understanding of the black-boxes involved, there's not a lot you can do here. If I am now understanding your initial question properly, you are asking if it's possible to somehow get the remote system to push the image content to multiple systems on your internal network. The simple answer is no...there is no straight-forward network slight-of-hand that will allow you to trick one system into talking multiple remote systems at the same time. The more complex answer is maybe, and depends a lot on unknown details of your black-box systems... Yes, that is core to my question: can port forwarding process do a ``tee'' to multiple addresses? I can think of a few things that could potentially help you: 1) Get the remote system to push the data to all clients. This will chew up lots of internet bandwidth, and will either require multiple external IP's, or control over which ports are used to connect (assuming you're running a masqueraded internal network). 2) Get the Master internal system to push the data to all slave systems. This may be possible to automate, or it may require a console jocky...depends on unknown (to me) details of your black-box systems. 3) Whip up a Black-Box emulator, that can talk the file-transfer protocol used by your systems. Have your remote system transfer files to your fake system, then push the data from there to all internal systems, as required. This will require network programming (not too tough in modern languages like Java, Perl, Python, c) and an understanding (or reverse engineering) of the file transfer protocols used by your equipment. 4) Read through the docs for your black-boxes, and see if they support any kind of image-server access. I think this is really what you want...a central image server. If you're lucky, you can do this with a *nix box. If you're unlucky, you'll need a propriatery box from your vendor for the other systems. If you're really-really unlucky, there's no support for any kind of 'pull' technology on the individual Slave stations. NOTE that everything but the last option requires lots of storage capacity on each image station, since each station is storing copies of all the image files. Yes, these are the alternatives we are considering. Yes, all of these depend -- more or less -- on access to proprietary information to which we may or may not be privy ; Of course, the image/fileserver approach makes most sense from many perspectives. Nevertheless, the port forwarding ``tee'' feasibility is an interesting question, regardless of our current customer's predicament! man ipmasqadm, on my potato box, contains and interesting example, which may or may not shed light on this; but, which I also do *not* fully understand: ``Redirect all web traffic to internals
Re: [Leaf-user] Dachstein-CD: port forward w/dmz proxy_arp ???
Doh! Of course -- again, not thinking -- addled by all of this holiday spirit ; Thank you. Charles Steinkuehler wrote: 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? The EXTERN_IP *and* port don't show up because you haven't explicitly opened them. You don't need to, since ports =1024 are already open. You don't see the port-forwarding entries in ipchains -nvL, because ipchains doesn't control the port-forwarding. Do a net ipfilter list and you'll see the configured port-forwards...the output of the command: ipmasqadm portfw -nl -- 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
[Leaf-user] portfw to *multiple* hosts ???
Quite simply, what is the simplest, secure way to forward to two (2) hosts? There are probably better ways to accomplish the end goal; but, we have an application whereby we may need to push very large files from the internet to two (or, more) locations behind a Dachstein firewall. What do you think? -- 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] portfw to *multiple* hosts ???
Charles Steinkuehler wrote: Quite simply, what is the simplest, secure way to forward to two (2) hosts? There are probably better ways to accomplish the end goal; but, we have an application whereby we may need to push very large files from the internet to two (or, more) locations behind a Dachstein firewall. What do you think? scp or https/PUT to separate ports (22 and 2022, or 443 and 4443, for example), one port for each host. The hosts could each see input on the nominal port (22 or 443). Yes, I see this; but, is there someway to accomplish this -- simultaneously -- with one (1) remote operation? ??? Please explain a bit more about exactly what you're trying to accomplish... Large medical images -- some approaching gigabyte sizes. The internal network connects multiple facilities. The images may need to be shared across multiple facilities. Our preferred solution is to put one (1) copy of each image on a large and robust fileserver inside their network. The catch is, they are using proprietary systems for viewing and analyzing the images and we may not be granted access nor information adequate to implementing our preferred solution. Currently, the remote sources are using their proprietary systems (black boxes) to auto-magically transfer the files directly to one (1) proprietary system inside our customer's network. Yes, this looks everyway like ftp -- except the proprietary system vendor says, no, it is not that simple ; When one of these images is needed on another proprietary system inside this network, somebody needs to push the required file to another proprietary system. Our customer wants ``pull'' access from any given system. In brainstorming alternatives, this occured to me: send images | V internet | V firewall | - | | | V V V host_1host_2host_n ... Regardless, whether or not this is the best solution for this application, how can this be done? What do you think? -- 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] 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] Dachstein-CD V1.0.2 Available
Tony wrote:
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.
In root.lrp: /var/lib/lrpkg/root.dev.mk
{snip}
The main changes include the inclusion of net-snmp (modified
version of
Andrew Hoying's package), an update to the latest kernel (2.2.19-3),
modifications to the init-scripts and general configuration
to intelligently
create and use /dev/cdrom (which will hopefully avoid the
requirement for
most folks to customize their PKGPATH), and a minor tweak to
/etc/network.conf.
--
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] Dachstein-CD: port forward w/dmz proxy_arp ???
No ideas?
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 - *
We've also tried:
tcp_${eth1_IPADDR}_55631_${PAM}_5631
udp_${eth1_IPADDR}_55632_${PAM}_5632
with exactly same result.
How can we do this?
What do you think?
--
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] Is this newbie even in the right ballpark with LEAF?
Dan Schwartz wrote: Over the past few days I've received some very helpful guidance about assembling LEAF VPN appliances to handle multi-megabit 3DES encryption throughput rates; and I really appreciate the guidance given this Mac NT geek ( linux newbie). However, since LEAF is essentially a small, stripped down (yet robust!) router that fits on 1 or 2 floppies, is there another router/encryption project out there in *nix land that's more suited for high capacity, i.e. something on the order of an Intel NetStructure 31xx VPN gateway http://www.intel.com/network/idc/products/vpn_gateway.htm? What is it that these products have that you believe cannot be done with LEAF? ``The Intel NetStructure VPN Gateway Family features an Intel® Pentium® processor-based PC architecture with solid-state design (no moving parts), protected OS kernel and optional hardware acceleration.'' Don't be fooled by the ``no moving parts'' ; The fact that we boot off of floppy or cdrom doesn't really conflict with that quotation, since, once it's running, we, too, have no moving parts! How often do you plan on rebooting? And, as I asked last night, that pentium processor does *not* have the processing power of the celerons my systems are running! I don't know about you; but, when I read: ``Windows* OS-based utilities for centralized and remote management'' I wonder if that added gui overhead couldn't better be used in the encryption, firewalling and routing processes ??? The fact that LEAF is a ``small, stripped down'' linux os should be a strong selling point -- *all* of your os can be delegated to the primary function of the system. It is not likely that anybody can claim that for any ``Windows* OS-based'' system. What do you think? -- 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] Update: ATT Transition Woes
gc wrote: It looks like Charles and Dan nailed it. My ISP seemed to be keying off of the MAC address. When I spoofed the router's MAC address (as per Charles' instructions below), it was able to get a good IP address. It still bugs me, though, that the ISP WAS giving me an IP address, just not a good one. I guess they just didn't want to make it easy on me :) Now, I guess I'll try figuring out how to get my ISP to accept the new MAC address. Or, I guess I can just change the MAC address as the router boots. Thanks for the good ideas, gentlemen. And thanks to Charles for the Dachstein release - wonderfully simple and easy to use. [ snip ] Good! You're making progress . . . I suggest that you post the contents of: /var/state/dhcp/dhclient.leases from Dachstein *after* it negotiates _both_ a good and a bad lease. Make certain that you reboot the firewall in between, so the file is clean each time. Then, for grins, bootup on the w2k box. Once you successfully negotiate a good lease, goto a dos prompt and do this: ipconfig /release Then, unplug that box from the cable modem and plug in your powered OFF firewall. Turn that ON, see what happens and if that doesn't successfully negotiate a good lease, publish a third instance of /var/state/dhcp/dhclient.leases Unfortunately, the isp-end hardware for att.broadband is so diverse throughout the country that this great variation obtains. In my case, I couldn't successfully negotiate a good lease until I *stopped* sending the client-id. Prior to the transition, I could not negotiate a good lease *without* the client-id ; What do you think? -- 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] Starting from scratch to build a high capacity VPN tunnel appliance, part 2
Dan Schwartz wrote: Dear Charles: Thank you *very* much for the offer. Right now they are in the process of getting the T-1 line provisioned (still 30+ days away, courtesy of Verizon); and as they get closer to deciding on whether they want a VPN channel between their offices I'll shepherd them towards this. [By the way, you're probably wondering why they would need a dual CPU encryption appliance: The firm is a service bureau, scanning in over 100,000 documents per day - About 5 gigabytes per day. Then, they send the image files to Manila, where a crew of 200 operators key in and verify the data (sort of a manual OCR), then FTP the text back to NJ where it's put on disk or tape for the customer. Right now, they're sending a DVD every day via DHL to Manila with the scans: It's actually slightly cheaper than a T-1; but they lose a day. Basically, with T-1 lines on both ends (they are 4 miles from the Pennsauken peering point) the 1.544 megabit line will be fully loaded for 11 hours just transmitting the data. Where the encryption (VPN circuit) comes in is that some of the customers are financial institutions, and it's a selling point in the highly competitive business.] [ snip ] What am I missing? How is that you think that you can saturate a single 500 MHz celeron with an encrypted 1.5 Mbps connection? Unless I'm missing something, you might do well to redo that math . . . -- 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] Timelag in Dachstein 1.0.2
Maxim Heijndijk wrote: I run Dachstein 1.0.2 and the time is one hour earlier than it should be. How can I change this ? I run 'rdate -p -s some.time.server hwclock --systohc', but still one hour earlier. This link contains good timezone information, although much of it no longer applies to Dachstein -- files mentioned early in the doc are already uptodate . . . Make sure that /etc/default/rcS is setup correctly. Preferably, you need the correct /etc/localtime -- which is your correct timezone? Do you have access to a Linux system? In lieu of that, supposedly, you can set /etc/tzvalue -- I've never used it ; Hope this helps . . . -- 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] Timelag in Dachstein 1.0.2
Sorry, the link: http://c0wz.steinkuehler.net/dox/ntp.txt Michael D. Schleif wrote: Maxim Heijndijk wrote: I run Dachstein 1.0.2 and the time is one hour earlier than it should be. How can I change this ? I run 'rdate -p -s some.time.server hwclock --systohc', but still one hour earlier. This link contains good timezone information, although much of it no longer applies to Dachstein -- files mentioned early in the doc are already uptodate . . . Make sure that /etc/default/rcS is setup correctly. Preferably, you need the correct /etc/localtime -- which is your correct timezone? Do you have access to a Linux system? In lieu of that, supposedly, you can set /etc/tzvalue -- I've never used it ; Hope this helps . . . -- 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
[Leaf-user] RESOLVED: LEAF development box, 2.2.19 kernel cannot use old ide hdd???
Michael D. Schleif wrote: I am building a development box with slink. The system is up and functioning; but, now, I need to implement a 2.2.19 kernel. It builds successfully; but, has problems at bootup. The system: Pentium 150 64MB RAM /dev/sda1 - swap /dev/sda2 - / /dev/scd0 - cdrom /dev/hdb1 - /usr/local Under the original slink, *ALL* of this functions properly! My new (2.2.19) kernel properly recognizes everything *except* /dev/hdb1: ``Checking all file systems . . . Parallelizing fsck version 1.12 (9-Jul-98) fsck.ext2: Operation not supported by devices while trying to open /dev/hdb1 /dev/hdb1: The superblock could not be read or does not describe a correct ext2 filesystem ...'' [ snip ] For the archives: Pertinent system details: Asus P55TVP4 mainboard, latest official BIOS w/Intel 430VX PCI chipset Quantum LPS270A IDE hdd (/dev/hdb1) Through rigorous testing, the following .config lines must be set differently than the stock 2.2.19-3-LEAF kernel: CONFIG_BLK_DEV_HD=n CONFIG_BLK_DEV_HD_IDE=n CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y This could be due to either the mainboard or hdd, or both ; NOTE: It's been along time since I've been bitten by this; but, it is absolutely imperative that one of the 'make config' processes be run prior to any 'make zImage', when run on a brand new, pristine /usr/src/linux -- otherwise, 'make __Image' will *not* work ; -- 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
[Leaf-user] LEAF development box, 2.2.19 kernel cannot use old ide hdd ???
I am building a development box with slink. The system is up and functioning; but, now, I need to implement a 2.2.19 kernel. It builds successfully; but, has problems at bootup. The system: Pentium 150 64MB RAM /dev/sda1 - swap /dev/sda2 - / /dev/scd0 - cdrom /dev/hdb1 - /usr/local Under the original slink, *ALL* of this functions properly! My new (2.2.19) kernel properly recognizes everything *except* /dev/hdb1: ``Checking all file systems . . . Parallelizing fsck version 1.12 (9-Jul-98) fsck.ext2: Operation not supported by devices while trying to open /dev/hdb1 /dev/hdb1: The superblock could not be read or does not describe a correct ext2 filesystem ...'' When I do this: e2fsck -b 8193 /dev/hdb1 I get this: ``The superblock could not be read or does not describe a correct ext2 filesystem ...'' I've varied several variables in .config to no avail ; What do you think? -- 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] LEAF development box, 2.2.19 kernel cannotuse old ide hdd ???
Ray Olszewski wrote: At 05:37 PM 12/14/01 -0600, Michael D. Schleif wrote: ... Interestingly, under the kernel that is functioning properly, there is *NO* /proc/ide !?!? ... So, how is this handling the IDE hdd? Is it using scsi to interpret ide? It would be easier to answer this if we know what kernel version was involved. An earlier message mentioned Under the original slink, *ALL* of this functions properly! So I dusted off my old Slink workstation and started it up. My version runs kernel 2.0.36; is that what we are talking about as original? 2.0.38 If so, I match your observation that there is no /proc/ide ... but the changes between kernel 2.0.x and 2.2.x were pretty far-reaching ... contrasted with a Potato workstation running 2.2.19, the /proc pseudo-directory differs in many ways, with many fewer file-style paths into kernel variables than the newer kernels have ... so I wouldn't worry much about this one difference. I'm sure it isn't using scci to interpret ide, since none of my systems include scsi drives or drivers. Nevertheless, the problem remains -- the system does *not* recognize /dev/hdb1. Any ideas how to correct this? -- 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
[Leaf-user] Silent_Deny by destination address ???
I want to silently deny all traffic with destination 255.255.255.255, regardless of source. This is in response to: input DENY eth0 PROTO=17 12.242.20.34:67 255.255.255.255:68 Is there any protocol or destination port for which these should *not* be denied? Yes, I can write the ipchains rule; but, *where* should it go? I'm really trying to avoid editing: /etc/ipfilter.conf Is this a job for: IPCH_IN=/etc/ipchains.input What do you think? -- 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] What is This
Matthew Schalit wrote: [ snip ] All these are blocked by rule #42. What is that rule? These log messages are from strange hosts. 80% of them don't resolve to a real hostname. All the packets you listed are tcp packets with no SYN flag, meaning they are theoretically responses to some tcp dns request your machine made. Because they are all response packets, I'm not sure what's going on. I don't know why you're getting responses from so many odd computers. The other strange thing, is that I would expect your firewall rules to allow response to outgoing TCP DNS requests. That's why I want to see rule 42. ipchains -L /tmp/myrules vi /tmp/myrules, find line 42, and post it. Actually, I like this -- and have added it to weblet's: /var/sh-www/cgi-bin/viewfw : ipchains -L -nv --line-numbers This automatically lists line numbers . . . -- 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] Silent_Deny by destination address ???
Ray Olszewski wrote: At 01:03 PM 12/9/01 -0600, Michael D. Schleif wrote: I want to silently deny all traffic with destination 255.255.255.255, regardless of source. This is in response to: input DENY eth0 PROTO=17 12.242.20.34:67 255.255.255.255:68 Is there any protocol or destination port for which these should *not* be denied? ... It depends on how your router gets its external address. The example you gave is a dhcp server replying to an (as yet) unconfigured dhcp client. If you need to get your external address via dhcp, you need to allow the very example you provided (assuming eth0 is external). Yes; but, in the case of Dachstein, the rules are *not* in place until after I negotiate an address for eth0 ; Conversely, if your router acts as a dhcp server, it needs to accept the corresponding sorts of requests from dhcp clients on the relevant interface(s). I believe the Windows sharing services -- the ones that run on port 137-139 -- make some use of broadcast addresses as well. I don't run them here so cannot recall details. Unless you want to respond to broadcast pings (and why would you?), I can't think of any other common services that use broadcast IP packets. This entry in /etc/ipchains.input appears to do as I need: $IPCH -I input -j DENY -p all -s 0/0 -d 255.255.255.255 -i $EXTERN_IF One thing that concerns me is this statement from man ipchains: ``The mask can be either a network mask or a plain number, specifying the number of 1's at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.'' Do I need to specify /32? At this point, I do not know what else can come to me for 255.255.255.0/24 -- so, I'm trying to be careful in what I deny. If 255.255.255.255 is noise, regardless of port, protocol source, then I'm all for keeping it out of my logs . . . What do you think? -- 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] logging
Brian Camp wrote: How can I keep denied packes with the 255.255.255.255 destination address from being logged? If you are using Dachstein, or some other distribution that understands this supplemental file, this entry in /etc/ipchains.input appears to do as you need: $IPCH -I input -j DENY -p all -s 0/0 -d 255.255.255.255 -i $EXTERN_IF -- 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] EIGRP (88) protocol ???
Charles Steinkuehler wrote: Regarding silent deny's...you can block the whole 224.0.0.0/4 range (RFC-1112 Class-D multicast) without worry. That catches IGMP, IGRP, EIGRP, and probably others. As you'd expect, this is in the same reduce my log noise section of echowall.rules. And, what is the best way to do this? Charles, is this possible with SILENT_DENY? SILENT_DENY=all_224.0.0.0/4 Is this for Source or Destination -- 224.0.0.0 ??? If I understand the underlying code, your example will silently deny everything from the 224.0.0.0/4 network, regardless to where (destination) it is destined. However, how do I silently deny anything from any source that is destined for 255.255.255.255 ??? Since ATT Broadband moved me to the new network, I am flooded with this crap: PROTO=17 12.242.20.50:67 255.255.255.255:68 What do you think? -- 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] very large /var/log/wtmp
Richard Burt wrote: OK, I took a look at the man pages for last. With no arguments, it should tell me all logins from the wtmp file. Here is what I get: # last USER TTY PID TIMEON FROM reboot ~ 0 48452.2.19 Figuring it has to do with logins, I also took a look at auth.log (also pretty big). I think the answer is here, but I don't know what to do to fix it. It is full of these. Dec 7 06:45:12 firewall /sbin/getty[11929]: /dev/tty1: cannot open as standard input: Operation not supported by device Dec 7 06:45:13 firewall /sbin/getty[11930]: /dev/tty2: cannot open as standard input: Operation not supported by device This is your problem. I've seen this on a SCO box, where /etc/inttab was grossly misconfigured and the experiences a 10 GB wtmp file !!! My box does not have any serial ports, so is there something I can do to stop it from trying to open them? Thanks, Rich Message: 5 Date: Thu, 6 Dec 2001 23:10:32 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-user] very large /var/log/wtmp To: LEAF User Mailing List [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] On 12/6/01 at 5:38 PM, Richard Burt [EMAIL PROTECTED] wrote: I saw a posting a few weeks ago of someone who was having this problem. I don't ever remember seeing an answer. This is a new clean Dachstein 1.01 installation. Been up for just shy of 3 days. As you can see my wtmp file is 7.5 MB. Anyone have any thoughts? Or what more info should I provide. Thanks. wtmp is used by the last command (that is -- probaby -- /bin/last); try it. You might want to check the help for a way to limit the number of entries to list (I don't remember what it was, but it can be done). Then you can see what is filling your wtmp file. -- 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] Re:
Am I the doofus or what? My only excuse is, when my lrpkg.cfg looks like this, it is easy to miss one: etc,local,bash,bwidth22,daemontl,djbutils,dhclient,dhcpd,dnscache,ifconfig,libdb,libm,libpcap,libz,lncurses,lrdline2,mawk,modules,netsnmpd,netsnmpu,ramlog,rsync,sftp,ssh,sshd,tcpdump,tinydns,vim,weblet Thank you . . . Charles Steinkuehler wrote: Did you see my post about net-snmp? This package requires libdb.so.2 which is not part of the libraries on the Dachstein CD. I found the file on the Debian web site in the libdb++ package. Did you include it in either of your net-snmp packages? If not, what do you think about making libdb++ an LRP package? I just grabbed David's libdb package and added it to the CD. We're still getting this: ``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries libm.so.6: cannot open shared object file: No such file or directory'' We have loaded libdb.lrp; yet, this: root@trout:/root # ls -al `find / | grep libm` -rw-r--r--1 root root 104192 Feb 20 1999 /usr/local/lib/libm-2.0.7.so lrwxrwxrwx1 root root 13 Dec 5 06:59 /usr/local/lib/libm.so.6 - libm-2.0.7.so What to do? How about loading libm.lrp? It's on the CD... -- 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
[Leaf-user] dnscache w2k servers ???
Normally, we've been setting up all systems with dhcp and assigning dns servers thusly: 192.168.1.254 # firewall, w/dnscache x.y.z.2 # ISP assigned dns server(s) x.y.z.3 ... I suppose, our theory is, if dnscache gets trashed, at least dns queries will continue to function within the environment. Normally, this works great and dnscache gets a good workout and we cannot see any failover to ISP assigned dns servers. In one of our environments, our customer is running win2k servers active directory services. In this particular environment, (nearly) all dns queries get handled by the second (x.y.z.2) dns server specified. Of course, if we remove all dns servers other than the firewall/dnscache, then dnscache gets all of the requests and handles them accordingly. H:\nslookup www.lrp.com *** Can't find server name for address 192.168.1.254: Non-existent domain *** Default servers are not available Server: UnKnown Address: 192.168.1.254 Non-authoritative answer: Name:www.lrp.com Address: 208.218.136.74 We've seen this non-existent domain on other wintel boxen; but, dnscache continues to function properly. Note, this example is without any additional dns servers defined. As you know, active directory services requires that m$oft dns run on the primary domain controller (or, whatever ADS has transmogrified PDC to). The only other oddity in this environment is that, inside the firewall, there is a Cisco router: Internet | firewall/dnscache | Cisco router || | subnet1 subnet2 subnet3 ... What do you think? -- 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] Re:
Charles Steinkuehler wrote: Did you see my post about net-snmp? This package requires libdb.so.2 which is not part of the libraries on the Dachstein CD. I found the file on the Debian web site in the libdb++ package. Did you include it in either of your net-snmp packages? If not, what do you think about making libdb++ an LRP package? I just grabbed David's libdb package and added it to the CD. We're still getting this: ``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries libm.so.6: cannot open shared object file: No such file or directory'' We have loaded libdb.lrp; yet, this: root@trout:/root # ls -al `find / | grep libm` -rw-r--r--1 root root 104192 Feb 20 1999 /usr/local/lib/libm-2.0.7.so lrwxrwxrwx1 root root 13 Dec 5 06:59 /usr/local/lib/libm.so.6 - libm-2.0.7.so What to do? -- 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] Re:
Michael D. Schleif wrote: Charles Steinkuehler wrote: Did you see my post about net-snmp? This package requires libdb.so.2 which is not part of the libraries on the Dachstein CD. I found the file on the Debian web site in the libdb++ package. Did you include it in either of your net-snmp packages? If not, what do you think about making libdb++ an LRP package? I just grabbed David's libdb package and added it to the CD. We're still getting this: ``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries libm.so.6: cannot open shared object file: No such file or directory'' We have loaded libdb.lrp; yet, this: root@trout:/root # ls -al `find / | grep libm` -rw-r--r--1 root root 104192 Feb 20 1999 /usr/local/lib/libm-2.0.7.so lrwxrwxrwx1 root root 13 Dec 5 06:59 /usr/local/lib/libm.so.6 - libm-2.0.7.so What to do? I should, probably, also listed this: root@trout:/root # ls -al `find / | grep libd` -rw-r--r--1 root root 6492 Dec 5 09:27 /lib/libdl-2.0.7.so lrwxrwxrwx1 root root 14 Dec 5 06:59 /lib/libdl.so.2 - libdl-2.0.7.so -rw-r--r--1 root root55588 May 18 2000 /usr/lib/libdb-2.0.7.so lrwxrwxrwx1 root root 14 Dec 5 07:00 /usr/lib/libdb.so.2 - libdb-2.0.7.so -rw-r--r--1 root root 64 Sep 27 2000 /var/lib/lrpkg/libdb.list -- 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] DMZ considerations ???
Charles Steinkuehler wrote: Just port-forward the service from the public IP of the firewall (the near end IP of the T1 link). The reverse masqerade rules will do the right thing, and everything should work fine. There are also hooks in place to do this already, so no custom forwarding and static-NAT rules, making the system easier to maintain. The public IP of the server system will fall outside the DMZ range, but unless your customer has their own IP range (unlikely, since you mentioned it's a /26), they're using 'borrowed' IP's from the ISP anyway...might as well make effective use of ALL the IP's you've been given, and save yourself some trouble in the process... If DNS can be setup -- on the customer's side -- to point server.customer.com to and address in ISP.com's domain, then this appears straightforward. Is this what you're suggesting? Yes. Remember, you typically have full control over forward lookups in yourdomain.com. So I could (for instance) point lrp.steinkuehler.net to www.whitehouse.gov, if I really wanted to. Your DNS server just translates arbitrary names in the domain you lease from the IANA to IP addresses...you control what IP addresses you want to map to various names. Our concern is about forward lookup of an address from outside of customer.com domain, using a name from within that domain and within our domain configuration ; That being said, you may or may not be able to create a reverse DNS entry, although this shouldn't be too much of a problem. Your ISP 'owns' the IP range you're using (likely the range for both the point-point T1 and the /26 subnet they route to you). You'll have to talk to their DNS guru if you want reverse lookups of your IP's to say something other than their default (typically something like ip.city.bigisp.com). This, too, is a legitimate concern. In general, as long as your ISP is actually running a valid reverse DNS for your IP range (lots of things will time out cause delays if your IP doesn't reverse resolve), you probably don't need to worry about the reverse lookups... To us, being in control and truly managing our domain necessitates doing so from within our DNS configuration. We find that we can do our job most reliably if we only require the ISP to forward to our domain from within their upstream DNS. Although, many ISP's are eminently competent, it is becoming all too common for us to bump into incompetently setup DNS - especially those run from wintel ; Actually, we did this: wan1_IP_EXTRA_ADDRS=x.y.z.65 and, without any DMZ, we get what we want. Actually, going to the Internet from the internal, private network, we appear to the Internet as a.b.c.157, which does not appear to be any conceivable issue. Most importantly, when we do http://x.y.z.65/ from a remote Internet site, we can get to our port-forwarded internal server !!! This is what our customer wants, so we are pleased. The confusion stems from doing this: wan1_IP_EXTRA_ADDRS=x.y.z.64/26 Although this is accepted by ipchains, only x.y.z.64 is pingable from the Internet; but, as the network itself, we couldn't get to anything, port-forwarding or not. What do you think? -- 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 . . . Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinumrefcd=PT97 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Delays in updating wanpipe.lrp
We are very sorry for any delays we may incur; but, we are among the unlucky @Home victims. Notwithstanding ATT's six weeks of assurances that we would experience no interruptions, apparently the dear judge judged the case at least one week quicker than ATT anticipated and transition us to the new network. Thank goodness for modems and netZero ; I can receive Email; but, not in realtime, for the near future. And, large uploads to anywhere are intolerable ; -- 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 . . . Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinumrefcd=PT97 ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] EIGRP (88) protocol ???
We just connected Dachstein-CD to a T-1 via Sangoma panpipe pci card. We are receiving a plethora of these: kernel: Packet log: input DENY wan PROTO=88 x.y.z.158:65535 224.0.0.10:65535 L=60 S=0xC0 I=0 F=0x T=2 (#39) Yes, we know that protocol 88 is EIGRP. No, Ethernet http://www.echogent.com/cgi-bin/fwlog.pl does not recognize this. [1] Does this represent a problem? Or, is this a candidate for Silent Deny? [2] Dachstein Silent Deny handles *only* icmp, tcp and udp. What is the best way to Silent Deny these? What do you think? -- 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
[Leaf-user] Dachstein-CD Sangoma wanpipe
There have been several people on this List who have mentioned problems with Sangoma's wanpipe since upgrading to Dachstein. We have worked closely with Sangoma and have a solution, which we will be releasing early next week -- after a long weekend of testing. Suffice it to say, existing wanpipe.lrp, sdladrv.o, syncppp.o, wanpipe.o and wanrouter.o files *cannot* work with kernel 2.2.19x. Everything appears to be OK at two of our sites. Sangoma has agreed to host the package that we are putting together. We also hope to get user input from others on this List. So, if you are interested, please, send me an Email . . . -- 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
[Leaf-user] DMZ considerations ???
We have a couple sites connected by T-1 to the Internet and the ISP's have allocated /26 and /28 public networks for our customers' domains. As you know, typically T-1's use a public /30 network to connect the external wan port to its peer address on the ISP side. This network belongs to the ISP and cannot be assigned to the customer. So, in Dachstein, we do something like this: wan1_IP_EXTRA_ADDRS=x.y.z.64/26 During interface initialization, this network gets associated with the interface wan1, which also is assigned the ISP's ip address. Is this ip aliasing? We're not quite sure why assigning the whole network results in only the first address responding to pings from the Internet; but, that is moot, for now . . . What is the best use of that public network in a DMZ ??? In other words: [1] We need one (1) ip address associated with the external interface, wan1; [2] We need one (1) ip address associated with the DMZ interface, eth1; [3] We need two (2) ip addresses, one for the network and one for broadcast; and [4] We want *all* of the rest available on the DMZ. How to configure this with Dachstein-CD ??? What do you think? -- 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] EIGRP (88) protocol ???
Charles, thank you! Charles Steinkuehler wrote: kernel: Packet log: input DENY wan PROTO=88 x.y.z.158:65535 224.0.0.10:65535 L=60 S=0xC0 I=0 F=0x T=2 (#39) Yes, we know that protocol 88 is EIGRP. No, Ethernet http://www.echogent.com/cgi-bin/fwlog.pl does not recognize this. [1] Does this represent a problem? Or, is this a candidate for Silent Deny? Not a problem, unless you feel compelled to get a Cisco or other advnced router running so you can start swapping routing info with your ISP...of course they probably won't listen to you anyway (unless they don't know how to properly configure their router). Ideal candidate for the bit-bucket. [2] Dachstein Silent Deny handles *only* icmp, tcp and udp. What is the best way to Silent Deny these? Um...not exactly. IPChains (and hence most of the network.conf settings) only knows about icmp, tcp, and udp by NAME, but you can stick in arbitrary protocols if you want. From Dachstein network.conf: # Traffic to completely ignore...define here to prevent filling your logs # Space seperated list: protocol_srcip/mask_dstport #SILENT_DENY=udp_207.235.84.1_route udp_207.235.84.0/24_37 So you want something like: SILENT_DENY=88_x.y.z.158 Of course, you know that I tried: SILENT_DENY=88_x.y.z.158_65535 which did *NOT* work -- and, I blindly assumed that SILENT_DENY could not work for this scenario ; Again, the laugh is on me! Anyway, yes, your solution works perfectly -- thank you !!! humorMust be one of those new ipv6 addresses...is that base64 encoding?/humor Note the missing third field (port number), which only makes sense with icmp/tcp/udp. Leaving this blank prevents the error you would get trying to specify a port with a custom protocol. Not really obvious, but it should work... Maybe I should make the comment something like: # Space seperated list: protocol_srcip/mask[_dstport] It would have saved me a post ; Nevertheless, it is good that this scenario is now in the archives . . . -- 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] DMZ considerations ???
Charles Steinkuehler wrote: We have a couple sites connected by T-1 to the Internet and the ISP's have allocated /26 and /28 public networks for our customers' domains. As you know, typically T-1's use a public /30 network to connect the external wan port to its peer address on the ISP side. This network belongs to the ISP and cannot be assigned to the customer. So, in Dachstein, we do something like this: wan1_IP_EXTRA_ADDRS=x.y.z.64/26 This is not what you really want to do...see below Yes, but what about the NAT'ed internal network? Does it need a public ip address on the customer's domain? Or, once the domain points entirely to the DMZ, does it *not* matter what public ip address is NAT'ed to the internal network? Will this cause problems if somebody on the internal network wants to run www or ftpd from the internal network? During interface initialization, this network gets associated with the interface wan1, which also is assigned the ISP's ip address. Is this ip aliasing? We're not quite sure why assigning the whole network results in only the first address responding to pings from the Internet; but, that is moot, for now . . . What is the best use of that public network in a DMZ ??? In other words: [1] We need one (1) ip address associated with the external interface, wan1; [2] We need one (1) ip address associated with the DMZ interface, eth1; [3] We need two (2) ip addresses, one for the network and one for broadcast; and [4] We want *all* of the rest available on the DMZ. You have almost perfectly defined a proxy-arp based DMZ, which is easily supported with Dachstein. I run several of these personally in similar circumstances (except I have SDSL instead of T1 : ) Yes, we have done PROXY_ARP with LRP-CD; but, the publicly visible ip address for the internal network was handled by another network. How to configure this with Dachstein-CD ??? See the DMZ comments inline in network.conf. Basically: wan1_PROXY_ARP=YES wan1_ROUTES=DEFAULT_GW intern_PROXY_ARP=YES intern_ROUTES=x.y.z.64/26 DMZ_SWITCH=PROXY DMZ_EXT_ADDRS=DEFAULT_GW EXTERN_IP DMZ_OPEN_DEST= as required Your one problem may be that the WAN interface doesn't support proxy-arp...I don't know if they send ARP packets down the T1 or not. This may not matter, however, as I think the kernel will do the right thing with the packets as long as they actually make it to the interface. Since the T1 link will probably recieve all packets anyway (is there a non-promiscuous mode for a T1 interface?), I think you'll be OK. Let me know how this works out...I can only talk to our T1 through an aging Cisco 4000 that can't even ssh (IOS 11.2...but it does do nice protocol based priority queueing :) We're going to try this in a couple hours and we'll let you know. Thank you, again again . . . -- 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] DMZ considerations ???
Charles Steinkuehler wrote: So, in Dachstein, we do something like this: wan1_IP_EXTRA_ADDRS=x.y.z.64/26 This is not what you really want to do...see below Yes, but what about the NAT'ed internal network? Does it need a public ip address on the customer's domain? Or, once the domain points entirely to the DMZ, does it *not* matter what public ip address is NAT'ed to the internal network? You're confusing me...what domain? How does the domain point entirely to the DMZ? Are you possibly talking about routes and IP addresses? If so, there's not really a problem. The firewall/router has two public IP's, one on the upstream link and one on the DMZ interface. All traffic from the internal net will be masqueraded behind the public IP of the firewall. Internal net access to DMZ sytstems will masquerade behind the public IP of the firewall DMZ interface. Here's the issue: a.b.c.156/30wan network (domain: ISP.com) a.b.c.157 local wan address (wan1) a.b.c.158 remote wan address (peer) x.y.z.64/26 public ip block (domain: customer.com) x.y.z.64/26 dmz network For example, when I ssh out to somewhere on the Internet from 192.168.1.101 and invoke `w' I see that I am FROM a.b.c.157. This is OK for most situations, because all network traffic, originating from the Internet, through the firewall should have destination on the dmz. However, what if I want to run ftpd on 192.168.1.101 and I want users to use ftp://myhost.customer.com, *not* by ip or myhost.ISP.com ??? Yes, I know about port forwarding, c. *HOW* can I take one (1) address out of x.y.z.64/26, let's say x.y.z.72, and have that address also bound to wan1? Or, is this a matter of leaving x.y.z.72 unused by any actual system on the dmz and portforwarding x.y.z.72:80 to 192.168.1.101:80? Since dmz hosts cannot/should not have access to private, internal hosts, we anticipate this to be a problem . . . Also, despite the fact that you have a route sending traffic for the whole /26 net out the DMZ interface, the way routing works in linux, more specific routes take precidence over less specific routes, so the route to your gateway IP via the T1 will override the /26 route, and the fact that a local interface is configured with a particular IP will cause any packets recieved for that IP to be directed to anything locally attached to that IP (netstat -ln). Will this cause problems if somebody on the internal network wants to run www or ftpd from the internal network? Well, they won't be visible from the outside world unless you port-forward or static-NAT... Let me know how this works out...I can only talk to our T1 through an aging Cisco 4000 that can't even ssh (IOS 11.2...but it does do nice protocol based priority queueing :) We're going to try this in a couple hours and we'll let you know. Oh...I almost forgot. If the proxy-arp thing doesn't work with your T1 link for some reason, you should be able to use static-NAT as a fall-back. This isn't quite as user friendly as proxy-arp (it's hard to get machines on the DMZ to talk to each other, and there's constant confusion when configuring regarding the public/private IP's, and which ones to use where), but if you can assign multiple IP's to your T1 and get packets on all of them, a static-NAT DMZ should definatly work. I'm pretty sure proxy arp will work properly, however, and do just what you need... Actually, we are very pleased with the results using ProxyArp! The only issue we had with your instructions were converting: intern_PROXY_ARP=YES -- dmz_PROXY_ARP=YES intern_ROUTES=x.y.z.64/26 -- dmz_ROUTES=x.y.z.64/26 Once we understood this, everything worked as expected. Thank you! -- 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] EIGRP (88) protocol ???
Scott C. Best wrote: Heya. Thanks for the packet log, am updating fwlog.pl to include an awareness of protocol 88. It knew about regular IGRP (IP protocol 9) but not this one. :) Regarding silent deny's...you can block the whole 224.0.0.0/4 range (RFC-1112 Class-D multicast) without worry. That catches IGMP, IGRP, EIGRP, and probably others. As you'd expect, this is in the same reduce my log noise section of echowall.rules. And, what is the best way to do this? Charles, is this possible with SILENT_DENY? Or, need we implement a special ipchains rule in /etc/ipchains.input ??? What do you think? We just connected Dachstein-CD to a T-1 via Sangoma panpipe pci card. We are receiving a plethora of these: kernel: Packet log: input DENY wan PROTO=88 x.y.z.158:65535 224.0.0.10:65535 L=60 S=0xC0 I=0 F=0x T=2 (#39) Yes, we know that protocol 88 is EIGRP. No, Ethernet http://www.echogent.com/cgi-bin/fwlog.pl does not recognize this. [1] Does this represent a problem? Or, is this a candidate for Silent Deny? [2] Dachstein Silent Deny handles *only* icmp, tcp and udp. What is the best way to Silent Deny these? What do you think? -- 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
[Leaf-user] IPTraf vs. wan ???
Is there away to get IPTraf to show ip traffic over a wan link? Is this something related to *not* using an interface of the form ??? ethnum -- 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] wanpipe
Any luck on this? I've spent much of the last two days trying to get this to work -- without success ; As Eddie said, everything appears to work, except there is *no* interface . . . Eddie Wilson wrote: Has anyone configured Dachstein-CD to use a wanpipe card? I started with LRP 2.9.8 then switched to eigerstein kernel to support ipsec. I am unable to get ipsec running so I have decided to start from scratch with Dachstein-CD. I have had no previous problems with wanpipe but I don't get an interface using DCD. The drivers seem to load without error messages but no device is created. -- 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] wanpipe
Doug O'Halloran wrote: When you say 'everything appears to work', what do you mean? Does dmesg or tailing /var/log/messages say anything about your card? Anything like: Damn... Adapter won't start! - from latest sdladrv.c When it was working under LRP 2.9.8, were you loading a wanpipe.lrp in syslinux.cfg? If you just changed your kernel to Eigerstein, and it still worked, maybe your old version had some of the config tools already installed. From perusing the Dachstein-CD, it doesn't appear to be there. Again, it's been a while since I played with one, but a little bit more detail would be helpful. In my case, syslogd messages show that the four (4) .O files from Sangoma's wanpipe.lrp are functioning and without error. There is *no* ominous statement like your example. For me, the most startling indicator is this: Starting all WANPIPE devices: When I review /usr/sbin/wanrouter, case start), I cannot see any condition under which *NOTHIING* more is echo'd than this line, unless there is *NO* file in /etc/wanpipe/ ; Nevertheless, that line is all that I see, then starting the eth0 interface. Sometimes, depending on which errant configuration permutation I use, I will get three of these: Cannot find device wanpipe1 Or, this: Error: an inet prefix is expected rather than dev. Any ideas? Michael D. Schleif wrote: Any luck on this? I've spent much of the last two days trying to get this to work -- without success ; As Eddie said, everything appears to work, except there is *no* interface . . . Eddie Wilson wrote: Has anyone configured Dachstein-CD to use a wanpipe card? I started with LRP 2.9.8 then switched to eigerstein kernel to support ipsec. I am unable to get ipsec running so I have decided to start from scratch with Dachstein-CD. I have had no previous problems with wanpipe but I don't get an interface using DCD. The drivers seem to load without error messages but no device is created. -- 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
[Leaf-user] Dachstein-CD: bash help built-in ???
Bash includes a built-in ``help'' command, which supercedes any PATH statement. Therefore, the LEAF/LRP /etc/profile admonishment *cannot* work: ``Type in help if you are really lost'' Of course, we could change this to; but, who will remember? ``Type in /usr/bin/help if you are really lost'' Instead, we've added this alias to /etc/profile: alias help=/usr/bin/help What do you think? -- 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] Announcing Dachstein CD RC5
Charles Steinkuehler wrote: [ snip ] Rebuilt log.tgz (part of ramlog.lrp) using busybox tar in hopes of eliminating broken pipe messages appering on some systems. Did I tell you that that fixes the problem? Of course, in my modified instance, it took me quite sometime to figure out how to un-archive, modify and re-archive in the same manner. Thank you . . . -- 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] Dachstein-CD: dnscache vs. tinydns ???
Jacques Nilo wrote: OK, this is really not about Dachstein, although that is the distribution that we're using ; What are the primary differences between dnscache and tinydns ??? http://leaf.sourceforge.net/devel/jnilo/dnscache1.html http://leaf.sourceforge.net/devel/jnilo/tinydns1.html What are the criteria we ought to consider, in deciding which to deploy? Really two different needs. If you only need to access the web dnscache will speed up your requests (that is the cache part of it) but it will also make your request more secure. Tinydns is needed if you want to serve the adresses of your domain(s). Basically it will be here a replacement for BIND (in fact BIND combines the dnscache tinydns function in the same program). But tinydns is much more secure and a LOT LOT smaller (compare size of tinydns.lrp bind.lrp :-) ) Background material here: http://leaf.sourceforge.net/devel/jnilo/dnscache6.html Aha! That's exactly why I didn't want to trust my first reaction ; I misread those links and thought that it was an either-or scenario. Now, I understand where I need *both* dnscache and tinydns; but, that I need dnscache on every system . . . Thank you. -- 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] Dachstein-CD: dnscache vs. tinydns ???
Richard Doyle wrote: snip Background material here: http://leaf.sourceforge.net/devel/jnilo/dnscache6.html Aha! That's exactly why I didn't want to trust my first reaction ; I misread those links and thought that it was an either-or scenario. Now, I understand where I need *both* dnscache and tinydns; but, that I need dnscache on every system . . . You don't actually _need_ dnscache on every system. I suspect most leaf-ers run dnscache only on the firewall box; other machines are configured to ask the firewall box for dns information. By *every system*, I mean every Dachstein firewall system -- we build alot of these for many different networks . . . -- 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] Announcing official release of Dachstein-CD
Charles Steinkuehler wrote: As always, this is truly superb stuff! Bravo, Charles !!! Couple questions, even though these items appeared in RC5: [1] What is the purpose of the ``leaf'' user? It was in Jacques' example passwd file...I added it mainly as a 'stub' entry for pointing to if someone wanted to add/create a new user account. It should not be used in most instances (having actual user accounts on your firewall isn't necessarily all that useful or prudent), so I changed the /etc/shadow entry for this user to dis-allow logins by default. [2] Should /home/leaf exist -- provided that we agree that such an user ought to exist? Probably, but let's see if I can rationalize my way out of an oversight...Hmm...making a directory isn't that hard, and other than a .profile entry, which isn't really necessary, it's just a place-holder taking up space in /root...if we add a .profile entry, it takes up even more space...but perhaps the best excuse..er reason it's not there, is you shouldn't really create user accounts in the first place, and I did really intend the leaf user to be either a stub entry you'd modify, or or a default entry for any non-root owned files you might want to put in a package (so they don't come up as user 100 on ls -l listings). As I studied these /etc/passwd inclusions, trying to decide their ultimate fate, it occured to me that if I made root unable to login and put leaf into a high numbered GID, subscribed to nothing, and an isolated home directory, then the only way to gain login access would be through this account and then su to root . . . Obviously, I, too, am not persuaded -- what are the merits and dangers of such logic? Perhaps, as you say, this is only an example to be followed by those adventurous enough to really want user accounts -- ought this passwd entry rather be: # leaf:x:100:1000:Default User:/home/leaf:/bin/sh -- 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] Announcing official release of Dachstein-CD
Charles Steinkuehler wrote: Interestingly enough, logged in as leaf, I *cannot* su - root su: Incorrect password What gives? Trust me, I know the root password ; But, I cannot eliminate root login if I cannot su to root . . . Hmm...does su have the setuid bit set? It has to inherit root privliges to be able to change your UID to root... Aha! Good catch ; -- 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
[Leaf-user] Dachstein-CD: dnscache vs. tinydns ???
OK, this is really not about Dachstein, although that is the distribution that we're using ; What are the primary differences between dnscache and tinydns ??? What are the criteria we ought to consider, in deciding which to deploy? What do you think? -- 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] Announcing official release of Dachstein-CD
Michael D. Schleif wrote: Charles Steinkuehler wrote: The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ There was a 'silent' release of v1.0.0 for internal use yesterday. Changes from the last release candidate include configuration tweaks (dnscache and ipsec), the inclusion of the ipsec binaries patched for x.509 certificate support, and fixes to a couple minor bugs (a problem with the POSIXness cut command, and setting custom backup destinations didn't work properly). As always, this is truly superb stuff! Bravo, Charles !!! Couple questions, even though these items appeared in RC5: [1] What is the purpose of the ``leaf'' user? [2] Should /home/leaf exist -- provided that we agree that such an user ought to exist? Interestingly enough, logged in as leaf, I *cannot* su - root su: Incorrect password What gives? Trust me, I know the root password ; But, I cannot eliminate root login if I cannot su to root . . . -- 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] Dachstein CD Install Documentation
Charles Steinkuehler wrote: Does anyone know of a way to create the CD from the CD-Contents under Windoze? I suspect that will be the biggest challenge for a non-Linux person if they want to add/remove packages from the CD. I've used Nero to create CD's on windows boxes. The version of Adaptec's EZ-CD I've got doesn't recognize the syslinux boot-disk as valid, so won't make a bootable CD from the CD-Contents. I think CDR-Win will also make appropriate disk images... Nero !!! Yes. We're running several instances of modified Dachstein-CD, RC4 and Nero, as well as WinImage (floppy images), are totally indispensable tools. Yes, they are shareware; but, the price is modest, especially regarding to the value returned for the firewalls alone. Please, pay the modest price and encourage the developers to keep these products alive . . . -- 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
[Leaf-user] Cyclades in trouble ???
Is Cyclades in trouble? Sangoma says that they're having serious business problems. We cannnot seem to get Cyclades on the telephone. What do you think? -- 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] host ignores redirect ???
These continue to come -- every four (4) hours. No ideas ??? Michael D. Schleif wrote: I've found references to this issue in the archives; but, have not found adequate explanation nor resolution. host 0a02a8c0/if8 ignores redirects for 0a02a8c0 to 0a02a8c0. Yes, the ip address is 192.168.2.10; but, *what* is it trying to redirect? *Why* is it trying to redirect _whatever_ to itself? What does this really mean? How can we correct this? What do you think? -- 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 -- 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
[Leaf-user] portfw from unused public ip ???
Since converting an open /26 network to Dachstein-CD and NAT, we have several unused ip addresses ; For example: x.y.z.66# Dachstein x.y.z.100 # unused 192.168.2.10# internal host How can we, for example, portfw tcp port 80 from an unused public address to an internal host? x.y.z.100:80 - 192.168.2.10:80 In other words, how can some remote internet user point her browser at x.y.z.100 and get the webserver on 192.168.2.10 ??? What do you think? -- 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
[Leaf-user] Dachstein-CD: $dev_IP_EXTRA_ADDRS ???
Will this scheme work on *all* interfaces? $dev_IP_EXTRA_ADDRS I'm not sure what is going on here and don't want to dive in before I understand the implications . . . How does this work? What are the ramifications? -- 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
[Leaf-user] Dachstein-CD rc4
Charles, et al. How did I miss your announcement for RC4 ??? Does everybody else know that RC4 was released on 7Nov ??? -- 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] Dachstein-CD rc4 available
Charles Steinkuehler wrote: How did I miss your announcement for RC4 ??? Does everybody else know that RC4 was released on 7Nov ??? Um...because I think I forgot to make one. clears throat...begins fanfare Announcing the availability of Dachstein-CD release candidate 4 (rc4) This file is corrupt in RC4 ISO: /lib/modules/usb/wmforce.o Apparently, this file has not changed in awhile; but, it makes for a pain to move this distribution into my development tree . . . -- 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] Weblet suggestion
Charles Steinkuehler wrote: Anyone know of an extended-precision shell-script math library before I go off and write one? After years and years of Perl programming, I've recently returned to my roots: awk, sed and shell. I often use sed in shell scripting, because it gives me better control over regexp's than grep. O, how quickly I forgot the power of awk! ``... all numeric values are represented within awk in double-precision floating point.'' O boy, is that sucker fast -- compared to myriads of calls to sed! It may take a different way of looking at your math problems; but, especially with awk's powerful matrix handling, I suggest -- strongly -- that you consider awk for this job. I vaguely remember a ksh extended precision math library; but, that url no longer functions. And, [b]ash is *not* ksh! No matter what math routines you find or develop, I seriously doubt that you will compete with the already compiled speed of awk . . . I would love to use something off the shelf like awk, or even dc, but I don't really want to add another 25K (dc) to 100K (mawk) binary just to do some simple addition and subtraction on byte/packet counts, since I think a lot of folks running on floppy would still like to use this, and most floppy installs are pretty pressed for size... Oooo, I forgot the ``cost'' of adding [m]awk . . . Does ash support arrays? I think that you're going to need it . . . -- 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] New packages available
Charles Steinkuehler wrote: Also available is a new weblet package. This includes numberous updates from the previous Dachstein weblet. You can now access the weblet logs via weblet, a bug with the text to html conversion has been fixed, so and now show up properly in the log listings, I added a file in /etc/crontab.daily to rotate the weblet logs, the status images now make more sense, ALL of the cgi scripts now use the new web 'look', and numerous minor changes were made to the cgi-scripts to clean up formatting. Why do you need both of these? /var/sh-www/cgi-bin/viewlogs /var/sh-www/cgi-bin/viewlogs-www - viewlogs -- 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] New packages available
Charles Steinkuehler wrote: Why do you need both of these? /var/sh-www/cgi-bin/viewlogs /var/sh-www/cgi-bin/viewlogs-www - viewlogs Take a look at the code... The script includes code to prevent 'directory walking' attacks, so something like: http://myfirewall.com/cgi-bin/viewlogs?../../etc/passwd will fail. The symlink is used to change the basename of the program, which is then used to select the root directory to provide files from. There are many other ways this could be done, but this is the one I picked. One reason was to avoid parsing a parameter provided by the user, which is always a bit dangerous and tricky in shell-script (just look at how many buffer based attacks there are for 'real' programs!). OK, now I understand. Is this, then, a security hole ??? /var/sh-log - /var/log -- 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] Weblet suggestion
Charles Steinkuehler wrote: With weblet, I would find a feature that showed hourly use of bandwidth very useful. Maybe others would too, those on pay-per-meg deals? It could be grabbed from the ipchains accounting figures. I tried to set up a shell script to do it but couldn't get it running automatically. Would it fit on weblet somewhere? Keep up the good work - Charles; look forward to v1 of Dachstein! The biggest problem with this is the lack of anything but the limited numeric processing available with shell parameter expansion. My tests have shown it to work correctly to 9 digits in ash, but I've got routers with byte counts MUCH larger than that. While it's possible to do arbitrary length calculations by breaking them up, I haven't generally included this sort of processing, since it seems like overkill for current status monitoring. Running every hour or so, however, wouldn't be too bad, and I can see where logging this might be very handy. If I get some free time, I may try to implement something... Anyone know of an extended-precision shell-script math library before I go off and write one? After years and years of Perl programming, I've recently returned to my roots: awk, sed and shell. I often use sed in shell scripting, because it gives me better control over regexp's than grep. O, how quickly I forgot the power of awk! ``... all numeric values are represented within awk in double-precision floating point.'' O boy, is that sucker fast -- compared to myriads of calls to sed! It may take a different way of looking at your math problems; but, especially with awk's powerful matrix handling, I suggest -- strongly -- that you consider awk for this job. I vaguely remember a ksh extended precision math library; but, that url no longer functions. And, [b]ash is *not* ksh! No matter what math routines you find or develop, I seriously doubt that you will compete with the already compiled speed of awk . . . -- 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] Simple scripting question
Charles Steinkuehler wrote: You can generally replace 'wc -l' with sed -n '$=', although you won't get a zero output if there are no lines. I know about this construct, using two (2) sed's: sed -n = | sed -n '$p' On Dachstein-CD: sed -n '$=' returns: sed: -e expression #1, char 1: Unknown command: ``?'' What do you think? Hmm...works for me: krypton.private.network: -root- # sed -n '$=' /etc/network.conf 767 krypton.private.network: -root- # The sed man page from debian lists = as a Zero- or One- address command, and $ is a valid single address... Yes, from the CLI, as you illustrate, it *does* work. I didn't try that ; However, these *all* fail: sed -n '/ DENY /s/DENY//p' /var/log/kern.log | sed -n '?=' sed: -e expression #1, char 1: Unknown command: ``?'' sed -n '/ DENY /s/DENY//p;?=' /var/log/kern.log sed: -e expression #1, char 19: Unknown command: ``?'' sed -n '/ DENY /s/DENY//;?=' /var/log/kern.log sed: -e expression #1, char 18: Unknown command: ``?'' I want to use sed to filter on [address]: / DENT / perhaps (or not) execute some command: s/DENY// and -- in that same instance of sed -- *count* the lines of output. What do you think? -- 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] Simple scripting question
Oo, talk about my bad };Þ Charles Steinkuehler wrote: Hmm...works for me: krypton.private.network: -root- # sed -n '$=' /etc/network.conf 767 krypton.private.network: -root- # The sed man page from debian lists = as a Zero- or One- address command, and $ is a valid single address... Yes, from the CLI, as you illustrate, it *does* work. I didn't try that ; However, these *all* fail: sed -n '/ DENY /s/DENY//p' /var/log/kern.log | sed -n '?=' sed: -e expression #1, char 1: Unknown command: ``?'' sed -n '/ DENY /s/DENY//p;?=' /var/log/kern.log sed: -e expression #1, char 19: Unknown command: ``?'' sed -n '/ DENY /s/DENY//;?=' /var/log/kern.log sed: -e expression #1, char 18: Unknown command: ``?'' Try changing the ?= to $=, and maybe it won't complain about the unknown command ? ;-) -- 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
[Leaf-user] sed: pass variable in ???
Speaking of sed scripts ; How can I pass a shell variable into a sed script pattern space? I've seen two (2) means documented elsewhere; but, I cannot get them to work in Dachstein-CD: sed -n '/'$var'/p' file sed -n '/$(var)/p' file Yes, I've found that I can do it this way; but, I'd prefer a single step: regx=/$var/p sed -n $regx file What do you think? -- 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] sed: pass variable in ???
Jeff Newmiller wrote: On Thu, 1 Nov 2001, Michael D. Schleif wrote: Speaking of sed scripts ; How can I pass a shell variable into a sed script pattern space? I've seen two (2) means documented elsewhere; but, I cannot get them to work in Dachstein-CD: sed -n '/'$var'/p' file This works... sed -n '/$(var)/p' file ...but this won't because substitutions are not made inside single quotes. Yes, I've found that I can do it this way; but, I'd prefer a single step: regx=/$var/p sed -n $regx file What do you think? This is a single step? :) No, that's my point . . . Shouldn't sed -n /$var/p work? My bad -- again ; This just isn't my day. I don't know what I was doing differently; but, yes, now these work . . . -- 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] Dachstein-CD-rc3 available: bash.lrp error
Charles Steinkuehler wrote: I haven't tried bash.lrp since pre-release. There used to be two (2) bash-related problems; now, I find one (1): Mounting local filesystems... ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg: line 33: 1001 Broken pipegunzip -c $pkgdir/$pkg 1002 Done | qt tar -x -Finished. I'm not sure what is wrong here -- I do not see wrong with the scripts. log.tgz *does* get un-archived and bash is working. Nevertheless, this is some kind of error -- hopefully *not* to manifest itself elsewhere . . . P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . . I still don't know why this is happening...what happens if you run the script manually? (ie svi ramdisk.pkg start). There *was* a problem like this early on, reflecting differences between different busybox versions of gzip, if memory serves, but I haven't seen a problem like that for a while... Of course, I blew away all of my current logs ; root@trout:/var/log # svi ramdisk.pkg start ramdisk.pkg: Uncompressing archives - log.tgz/etc/init.d/ramdisk.pkg: line 33: 22910 Broken pipe gunzip -c $pkgdir/$pkg 22911 Done| qt tar -x - Finished. NOTE: first line of output (ramdisk.pkd: ...) is very long -- there are only three (3) lines of output . . . -- 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] Martians: please, help track this one down ???
George Metz wrote: On Tue, 30 Oct 2001, Michael D. Schleif wrote: now for the header ll header: ff ff ff ff ff ff 00 30 c1 d8 b6 80 08 06 Found it! Eradicated it! Thank you, all for quick response . . . Out of curiosity, what's the manufacturer on that NIC card? I did a search for the first three at standards.ieee.org and it came up blank, so I'd be interested in knowing if you've got the info available and easily to hand. Yes -- it turns out that mac's beginning with: 00 30 c1 d8 at least in this case (3 specimens), are HP switches. -- 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] Dachstein-CD-rc3: mail anomolies
Blanton Lewis wrote: This is the way that the memo headers are created (headers, like subject, that are actually part of the mail body and not the envelope), so as far as the mail client is concerned, you're giving more headers for the email. You need the blank line to tell the mail client that the body has begun. from RFC 822, section 4.1 (Message specification, Syntax): message = fields *( CRLF *text ) ; Everything after ; first null line ; is message body [1] If the first line of the mail body begins with at least one (1) non-whitespace, non-colon (:) character and is followed by a colon (:) and anything else, then *NO* body will be received with the Email !?!? For example: host: Odin date: Fri Oct 26 20:35:13 CDT 2001 src : trout Perhaps, that is the case -- need to scrounge around in POSIXness.mail, again, to see . . . However, my point is centered around the pingcheck() function in /etc/cron.daily/multicron-d, which *does not* work in my testing; but, succeeds with the prepended echo. Of course, this also applies to mailspacelow() function in that same script, as well as any other similarly constructed calls to mail. -- 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] Help with getting weblet logs into weblet
John Desmond wrote: --- Michael D. Schleif [EMAIL PROTECTED] wrote: John Desmond wrote: --- Michael D. Schleif [EMAIL PROTECTED] wrote: [ snip ] I believe that (additional) ramdisks are created *after* root.lrp is unrolled; but, *before* anything goes into /var/log or /tmp. But how does LRP know to install ramdisk.lrp and execute the included bootup file before any of the other .lrp's that depend on it? *I* didn't tell it to! I don't know about sequence and race conditions; but, without ramdisk/ramlog.lrp, /var/log will be empty on bootup -- until up comes the network and stuff happens and logs are created. Same goes for /tmp . . . Which brings up another question that's been nagging at me ever since I installed ramdisk.lrp to put /var/log on it's own: why do I need ramdisk.lrp, anyway? The whole LRP-thing is operating out of a ram drive! Can't a second ramdrive be specified in /etc/fstab mounted at /var/log? Is it a different kind of ramdrive? Anybody know? If your logs go crazy and expand they can consume the entire filesystem on which they reside. If you have only ram0, that is the filesystem that will fill up. If ram0 fills up, then the operating system *cannot* operate, because to do something new, it needs memory in which to do it. Placing /var/log on ram1 gives your logfiles limited space in which to expand. Even if ram1 fills up, the operating system can continue to operate . . . -- 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] Dachstein-CD-rc3: mail anomolies
Charles Steinkuehler wrote:
[ snip ]
[1] If the first line of the mail body begins with at least one (1)
non-whitespace, non-colon (:) character and is followed by a
colon (:) and anything else, then *NO* body will be received
with the Email !?!? For example:
host: Odin
date: Fri Oct 26 20:35:13 CDT 2001
src : trout
This can be alleviated by prepending *all* bodies with a blank
line (echo).
The blank lines are *supposed* to be in there already, but I've verified
they don't actually make it into the message. The problem is with shell
parsing...I really need to be able to have two input file descriptors open.
I'll probably need to re-work a big chunk of the mail script to fix this,
but it will be fixed soon.
Actually, adding (pre-pending) the echo line to your block ({ ... })
works *without* further modifications.
Also, could you verify the shell you're running?
Your bash.lrp.
[3] /var/log/mail.log exists; but, I've not yet seen anything
write to it. In order to facilitate debugging Email issues,
as well as to keep track of outgoing Email attempts, I suggest
adding the following subroutine to /lib/POSIXness/POSIXness.mail:
log () {
LOG=/var/log/mail.log
STR=`date '+%b %d %T'`
STR=${STR} ${HOSTNAME} mail[$$]: $user = [$envelopes]: $subject
echo $STR $LOG
}
I suggest calling log prior to that final `exit 0' and the last
`done'; but, there maybe a more sane location ;
What do you think?
Yes, I should probably add some sort of logging facilities to the mail
script.
NOTE: Subsequent to this first post, I amended the function above with a
call to logger. Actually, quite a simple addition; but, you may want to
local-ize all of my function variables, since I cannot guarantee
var-name collisions, or lack thereof, from other scripts . . .
[4] There seems to be a problem with the busybox hostname...I'll fix that
too.
Should I understand this reference ???
--
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
[Leaf-user] Dachstein-CD weblet.lrp: issues
In a previous thread, Charles Steinkuehler wrote: P.S. Nifty solution to the weblet logs issue coming as soon as I come up with one and can test it. I'll probably just fix the viewlogs cgi script, which is intentionally paranoid about which files it allows to be accessed (weblet logs should also be rotated and added as links to the main weblet page). It can be real easy to create gaping security holes (from simple ../../ expansions to shell meta-character expansion vunerabilities) in conventional web-servers, much less one written in shell-script...I've tried to close as many holes as possible, although I'm sure there are still a number of potential vunerabilities if anyone cares enough to try and find them, but that can make some things a bit harder than it seems like they should be at first glance... It should be noted, on these security issues, that the meta-character issue needs a rigorous going-over. In some of my logs, I have this string often repeated: == Here is how that same string appears in the weblet view: =gt; This ought to be covered by some transliteration routine, such as done by Perl's CGI.pm. I'm sure there are other issues. I'm starting this new thread in hopes of gathering other questionable weblet behaviours from ardent users. Once we know where shoring up needs to be done, I'm sure our community will step up to the challenge ; What do you think? -- 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
[Leaf-user] Martians: please, help track this one down ???
Yes, I know what martians are. Yes, I know how they can occur. No, I do not know how to locate and eradicate this one ; martian source 3edb5d3f for 03db5d3f, dev eth1 ll header: ff ff ff ff ff ff 00 30 c1 d8 b6 80 08 06 3edb5d3f == 63.93.219.62 03db5d3f == 63.93.219.3 However, now that I know that it's there, on a network from which it cannot escape, *HOW* do I track it down? How do we interpret that second line? Am I right in assuming that the MAC address is buried somewhere in line 2? Anybody have any suggestions on how to locate this ugly bugger? What do you think? -- 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] Martians: please, help track this one down ???
Simon Bolduc wrote:
[ snip ]
now for the header
ll header: ff ff ff ff ff ff 00 30 c1 d8 b6 80 08 06
ff ff ff ff ff ff = destination MAC address - this equates to a binary of
or simply a broadcast
to anything on the LAN with a MAC address - probably shouldn't be forwarded
off the LAN in any case
00 30 c1 d8 b7 80 = Source MAC address
Remaining characters define the ARP Protocol type:
arp packet type 08:06
arp_hrd 00:01 /* Ethernet1*/ arp_prot
08:00 /* IP=0x800 */ arp_hlen 06
/* hlen = 6 */ arp_plen 04
/* plen = 4 */ arp_op00:01 /* arp
ARP_REQ*/ arp_sha 00:c0:7b:61:44:fe /* 123 */ arp_spa
cc:b2:d7:7b /* 123 */ arp_tha
00:00:00:00:00:00
arp_tpa cc:b2:d7:13 /* 19 */
All info gathered from
http://www.cpm.ru/service/manuals/pipeline/pipe130/6.0.0/usergde/filter.htm
and
http://lists.suse.com/archive/suse-linux-e/2000-Jul/0282.html
Found it!
Eradicated it!
Thank you, all for quick response . . .
--
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] Help with getting weblet logs into weblet
John Desmond wrote:
--- Michael D. Schleif [EMAIL PROTECTED] wrote:
John Desmond wrote:
[ snip ]
First, un-tar weblet.lrp into a temporary directory.
cd temp/var
rm -fr sh-log
ln -s /var/log sh-log
At this point, rebuild weblet.lrp from this tree.
Actually, I rebuild my .lrp's by setting up the system
the way I want, hacking the package .list files and
jiggling the handle. Your basic technique I can do as
long as I don't have to recompile something :)
I must have a different version... no sh-log directory
in the package. I think it's dynamic.
Which version are you using? I have v1.1.2.
It can go anywhere you tell it in /etc/sh-httpd.conf -- this is default
in mine:
LOGFILE=/var/sh-log/sh-httpd.log
H. Important question: if I create a symlink and
use the LRP package backup, will it save the symlink
or the contents of the linked file? If the former,
this will work for me.
Yes.
[ snip ]
Also, as you surmised, you will need to edit
/etc/cron.daily/multicron-d, modifying the call to
savelog in the
rotatelogs subroutine:
savelog -p -c ${lrp_LOGS_DEPTH:-4} $LOG /dev/null
Of course, etc.lrp requires backup/update for these
changes to persist.
What do you think?
I'm going to have to play with this some more. It
seems like putting the simlinks into weblet is the
best bet if they can be backed up.
You know, I just remembered why I dropped this in
confusion a few weeks back. I was uncertain when the
ramdisk gets created, and whether it would be there to
receive files from a package installation during
bootup. I was guessing that /etc/init.d/ramdisk
wouldn't be run until after all the packages were read
in; therefore, no ramdisk when weblet.lrp was read;
so, no place for my symlinks. I was thinking that
perhaps empty weblet logs and the links to them should
be created in one of the bootup scripts like the links
to 'ln' and 'grep', but that was such a dark forest, I
wasn't ready to go in it.
I believe that (additional) ramdisks are created *after* root.lrp is
unrolled; but, *before* anything goes into /var/log or /tmp.
P.S. Charles, *why* isn't ``savelog -p'' the default
in Dachstein-CD? I
cannot figure out any reason to force ownership of
everything to
root:adm, as this current configuration does:
savelog -g adm -m 640 -u root -c
${lrp_LOGS_DEPTH:-4} $LOG /dev/null
I added the -p option back when I was experimenting
with it and it didn't seem to help.
It works OK in my scenario.
--
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
[Leaf-user] Dachstein-CD: directoy file permissions ???
Need we be concerned about directory file permissions? Notice, I ask this in general, regarding *all* LEAF/LRP distributions; but, because I am deeply into Dachstein-CD, my issues directly affect this distribution. For instance, should /var/log be 640, root:adm? Or, at least 750 -- so sh-httpd can write to sh-httpd.log? I don't have alot of specific issues; rather, I find alot of directories root:root and 755, which beg the general question. I don't know if there is any standard for this, much less a high security standard. However, I'm asking this now, since it is a good time to tighten this up on Dachstein-CD. What do you think? -- 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] Dachstein-CD-rc3: mail anomolies
Michael D. Schleif wrote:
[ snip ]
[3] /var/log/mail.log exists; but, I've not yet seen anything
write to it. In order to facilitate debugging Email issues,
as well as to keep track of outgoing Email attempts, I suggest
adding the following subroutine to /lib/POSIXness/POSIXness.mail:
log () {
LOG=/var/log/mail.log
STR=`date '+%b %d %T'`
STR=${STR} ${HOSTNAME} mail[$$]: $user = [$envelopes]: $subject
echo $STR $LOG
}
I suggest calling log prior to that final `exit 0' and the last
`done'; but, there maybe a more sane location ;
Of course, I meant this:
done
log
exit 0
--
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] Dachstein-CD-rc3 available: bash.lrp error
Charles Steinkuehler wrote: I haven't tried bash.lrp since pre-release. There used to be two (2) bash-related problems; now, I find one (1): Mounting local filesystems... ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg: line 33: 1001 Broken pipegunzip -c $pkgdir/$pkg 1002 Done | qt tar -x -Finished. I'm not sure what is wrong here -- I do not see wrong with the scripts. log.tgz *does* get un-archived and bash is working. Nevertheless, this is some kind of error -- hopefully *not* to manifest itself elsewhere . . . P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . . I'm running bash (and vim) on my development systems here, and I have not seen this problem. Can you provide more details about your system: Hardware details (cpu, memory, NIC's, etc) DECpc LPv+ 450d2 PC 486d2 50 MHz 64 MB, 36-bit SIMM's 3c509 ISA NIC's (2x) see below for boot lines from syslog Configuration (packages modules loaded from CD) lrpkg.cfg == etc,local,bash,bwidth22,dhclient,dhcpd,dnscache,ifconfig,libpcap,lncurses,lrdline2,mawk,modules,ramlog,rsync,snmp,ssh-1,sshd-1,tcpdump,vim,weblet Which packages you have local configuration information for on your floppy. I boot from floppy, so the standard linux, root.lrp, c. is on floppy; but, *nothing* else LRP is loaded from floppy . . . I'm not sure what the problem could be... Boot lines from syslog = Oct 26 00:51:50 trout syslogd 1.3-3#31.slink1: restart. Oct 26 00:51:51 trout kernel: klogd 1.3-3#31.slink1, log source = /proc/kmsg started. Oct 26 00:51:51 trout kernel: Cannot find map file. Oct 26 00:51:51 trout kernel: Loaded 18 symbols from 14 modules. Oct 26 00:51:51 trout kernel: Linux version 2.2.19 (root@debian) (gcc version 2.7.2.3) #6 Mon Oct 22 17:21:06 CDT 2001 Oct 26 00:51:51 trout kernel: BIOS-provided physical RAM map: Oct 26 00:51:51 trout kernel: BIOS-88: 0009f000 @ (usable) Oct 26 00:51:51 trout kernel: BIOS-88: 03f0 @ 0010 (usable) Oct 26 00:51:51 trout kernel: Console: colour VGA+ 80x25 Oct 26 00:51:51 trout kernel: Calibrating delay loop... 24.93 BogoMIPS Oct 26 00:51:51 trout kernel: Memory: 62156k/65536k available (1112k kernel code, 412k reserved, 1024k data, 52k init) Oct 26 00:51:51 trout kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Oct 26 00:51:51 trout kernel: Dentry hash table entries: 8192 (order 4, 64k) Oct 26 00:51:51 trout kernel: Buffer cache hash table entries: 65536 (order 6, 256k) Oct 26 00:51:51 trout kernel: Page cache hash table entries: 16384 (order 4, 64k) Oct 26 00:51:51 trout kernel: CPU: Intel 486 DX/2 stepping 05 Oct 26 00:51:51 trout kernel: Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Oct 26 00:51:51 trout kernel: Checking 'hlt' instruction... OK. Oct 26 00:51:51 trout kernel: POSIX conformance testing by UNIFIX Oct 26 00:51:51 trout kernel: PCI: No PCI bus detected Oct 26 00:51:51 trout kernel: Linux NET4.0 for Linux 2.2 Oct 26 00:51:51 trout kernel: Based upon Swansea University Computer Society NET3.039 Oct 26 00:51:51 trout kernel: NET4: Unix domain sockets 1.0 for Linux NET4.0. Oct 26 00:51:51 trout kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Oct 26 00:51:51 trout kernel: IP Protocols: ICMP, UDP, TCP, IGMP Oct 26 00:51:51 trout kernel: TCP: Hash tables configured (ehash 65536 bhash 65536) Oct 26 00:51:51 trout kernel: Linux IP multicast router 0.06 plus PIM-SM Oct 26 00:51:51 trout kernel: klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: 1.91 Oct 26 00:51:51 trout kernel: early initialization of device ipsec0 is deferred Oct 26 00:51:51 trout kernel: early initialization of device ipsec1 is deferred Oct 26 00:51:51 trout kernel: early initialization of device ipsec2 is deferred Oct 26 00:51:51 trout kernel: early initialization of device ipsec3 is deferred Oct 26 00:51:51 trout kernel: Initializing RT netlink socket Oct 26 00:51:51 trout kernel: Starting kswapd v 1.5 Oct 26 00:51:51 trout kernel: Detected PS/2 Mouse Port. Oct 26 00:51:51 trout kernel: Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled Oct 26 00:51:51 trout kernel: Software Watchdog Timer: 0.05, timer margin: 60 sec Oct 26 00:51:51 trout kernel: Real Time Clock Driver v1.09 Oct 26 00:51:51 trout kernel: RAM disk driver initialized: 16 RAM disks of 20480K size Oct 26 00:51:51 trout kernel: hda: CD-ROM 40X/AKU, ATAPI CDROM drive Oct 26 00:51:51 trout kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Oct 26 00:51:51 trout kernel: Floppy drive(s): fd0 is 1.44M Oct 26 00:51:51 trout kernel: FDC 0 is a post-1991 82077 Oct 26 00:51:51 trout kernel: md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 Oct 26 00:51:51 trout kernel: raid5: measuring checksumming speed Oct 26 00:51:51 trout kernel:8regs :28.575 MB/sec Oct 26 00:51:51 trout kernel:32regs:16.764 MB/sec Oct 26 00:51:51 trout kernel: using fastest
Re: [Leaf-user] Dachstein-CD-rc2 available
Robert Williams wrote: My Dachstien CD rc1 boots from the floppy. Can I update to the new kernal by copying the the new one to the floppy? If so what file(s) do I need to copy over. Thanks, Robert You need two (2) new files on your boot floppy: linux root.lrp There are many ways to do this; but, the simplest maybe to create a second floppy from the RC2 bootdisk.bin, then copy these two files to your boot floppy . . . Charles Steinkuehler wrote: The second release-candidate version of Dachstein-CD is now available. I forgot to mention...anyone wanting to upgrade from the previous (rc1) version of Dachstein-CD can simply switch to the new CD and reboot (keeping your existing config floppy)...no manual tweaking of anything required. To me this is one of the coolest things about running the CD release (that and it boots a lot faster than floppies :-) Unless, of course, you actually need to boot from the floppy, because your firewall won't boot from CD-ROM -- in which case, you won't have benefit of that new kernel ; -- 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
[Leaf-user] Remote access VPN -- from anywhere ???
A client of ours wants to take the plunge and VPN their way around their corporate intranetwork from any old place on earth. OK, so they want remote access VPN and their poor DSL is going to really show its limited bandwidth ; Is IPSEC and FreeS/WAN the way to go? Can LRP-CD (their current firewall) be configured to accept connections from any IP on the planet? Can this be done? What do I need to read? Are there any working examples? Any templates to follow? What do you think? -- 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] New Kernels available
Charles Steinkuehler wrote: I have new kernels available, which include patches for a couple recent kernel bugs: [ snip ] I notice that your site http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/CD-Contents/ indicates file change dates more recent than your original issue of Dachstein-CD, rc1: -r-- 1 1474560 Oct 19 11:11 bootdisk.bin -r-- 1 43858 Oct 18 17:11 dhcpd.lrp -r-- 1334739 Oct 19 11:31 ipsec.lrp dr-x 2 4096 Oct 17 19:16 lib/ -r-- 1754089 Oct 19 11:06 root.lrp Other than kernel updates, what has changed in these files from RC1 ??? -- 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] Dachstein-CD vs. mailonerr ???
Charles Steinkuehler wrote: Is there a reason that your utility: mailonerr will not work on Dachstein-CD? I haven't tested it yet...I do recall having to change a couple of things when I migrated the script to a system running bash instead of ash... I'll try to test it here soon. mailonerr *DOES* work! Apparently, after adding the POSIXness* changes, a reboot is required -- or, at least, it now works for me . . . Alas! Now I'm off to build the new Dachstein-CD release ; -- 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] New Dachstein-CD pre-release version avaialble
Charles Steinkuehler wrote: As you stated in the first release announcement: ``But if you're grabbing the CD image, you'll probably have better luck with the faster mirrors:'' http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ All of the files I've downloaded from http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ have been unusable -- ostensibly because the html download adds something to the file content ; Hmm...that shouldn't happen. Have you compared the downloaded file size with the source file size (or the other file d/l that apparently worked)? Yes, file sizes *differ*. This happens on *both* ISO and individual files -- twice burned on the large ISO's ; What system/browser are you using? Netscrape v4.76. I was going to try ie6; but, I know that the alternate sites have always worked for me (i.e., too lazy ;) -- 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] Dachstein-CD: large floppies take *FOREVER* to boot ???
Charles Steinkuehler wrote: fd0h1440 floppies boot as expected. Unfortunately, I'm working on a system that cannot boot from CD-ROM ; You could boot from a 1440 floppy and run from CD-Rom...I do that a lot when I'm testing (easier/faster to edit the floppy than burn a new CD!). Yes, I do. However, there ain't much room left for backing up stuff ; Hence my desire for larger formats . . . This same system previously ran Edge/ThinLinux firewall on fd0u1680 and fd0u1743 (when I could find media that would take this larger size) -- quite successfully. Now, regardless winimage (v6) or fdformat/mformat, larger formats take 10-15 minutes to load root.lrp and linux -- and the resulting system is *NOT* stable! No, there are no errors during boot. Nor are there errors -- on these floppies -- during format. Is this and issue with syslinux v1.62? If it worked better previously, this could be a problem with syslinux 1.62, or your BIOS, or some wierd interaction between the two. You might try using the syslinux version that worked well previously. Is there any reason that you chose v1.62? -- 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
[Leaf-user] Dachstein-CD: localtime vs. UTC ???
As you know, I've been using LRP-CD for quite sometime. Yes, I know that I had to resolve this issue with LRP-CD; but, for life of me, I cannot remember how ; System time is set to my localtime (CST6CDT). Using /etc/localtime that comes with Dachstein, date command returns correct hms; but, UTC. Using /etc/localtime that I'm using on LRP-CD boxen, date command returns CDT; but, *wrong*, offset hms. Please, advise me on the error of my ways . . . -- 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] New Dachstein-CD pre-release version avaialble
Charles Steinkuehler wrote: I've just put a new version of the Dachstein pre-release CD image online: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ As you stated in the first release announcement: ``But if you're grabbing the CD image, you'll probably have better luck with the faster mirrors:'' http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ All of the files I've downloaded from http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ have been unusable -- ostensibly because the html download adds something to the file content ; -- 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] Dachstein-CD: localtime vs. UTC ???
Charles Steinkuehler wrote: As you know, I've been using LRP-CD for quite sometime. Yes, I know that I had to resolve this issue with LRP-CD; but, for life of me, I cannot remember how ; System time is set to my localtime (CST6CDT). Using /etc/localtime that comes with Dachstein, date command returns correct hms; but, UTC. Using /etc/localtime that I'm using on LRP-CD boxen, date command returns CDT; but, *wrong*, offset hms. Please, advise me on the error of my ways . . . Oops...I apparently left the CST localtime file on the CD version...see my writeup on setting time on LRP: http://c0wz.steinkuehler.net/dox/ntp.txt That's the one! I always forget about /etc/default/rcS and GMT=-u or = . . . Thank you. -- 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
[Leaf-user] Dachstein-CD vs. mailonerr ???
Charles == Is there a reason that your utility: mailonerr will not work on Dachstein-CD? -- 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] Dachstein-CD vs. mailonerr ???
Brad Fritz wrote: On Wed, 17 Oct 2001 09:55:58 CDT [EMAIL PROTECTED] wrote: Charles == Is there a reason that your utility: mailonerr will not work on Dachstein-CD? Not to answer for Charles, but in case he's busy with other stuff, it's possible that you're running into the POSIXness mail() problem described in http://www.geocrawler.com/lists/3/SourceForge/7325/25/6832196/ and http://www.geocrawler.com/lists/3/SourceForge/7325/0/6833683/ The first link describes the problem, and the second link has temporary fixes for POSIXness.mail from Charles. (Thanks, Charles, they work well.) Actually, I applied those within 3 hours of their post. No, that is not the problem . . . -- 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
[Leaf-user] bash.lrp broken pipes ???
I like the idea behind a bash.lrp, especially since we're running Dachstein-CD and plenty of RAM. However, bash.lrp breaks two (2) other modules, complaining about ``broken pipe'': /etc/rcS.d/S36ramdisk.pkg, line 33 /etc/rcS.d/S55urandom.pkg, line 56 Notice, also, that those line numbers are *not* the lines with the pipe ``|''. What do you think? -- 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
[Leaf-user] syslinux.cfg: *maximum* line length ???
Trying to load many modules at the LRP= point in syslinux.cfg in Dachstein-CD. It appears that when the third line, beginning ``default linux . . .'' exceeds 253 characters, all items _after_ this point are ignored. Is the only workaround adding an lrpkg.cfg to floppy? What do you think? -- 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
[Leaf-user] ERROR: iptraf ???
Anybody seen this error on executing iptraf? ``Error opening TCP/UDP filter file Press a key to continue'' What do you think? -- 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
[Leaf-user] Dachstein-CD: network.conf ???
How to configure external interface when it gets IP, et al., from ISP? /etc/network.conf has these defaults: eth0_IPADDR=1.1.1.2 eth0_MASKLEN=30 eth0_BROADCAST=+ Are these dummies that are always *overwritten* during the address subscription phase? Also, I notice ``+'' used several places for broadcast address. What is this? What do you think? -- 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
[Leaf-user] *real* grep for LEAF ???
Anybody compiled any *real* grep for use in LEAF? I can't say how many times that I wished I could do -i or -v . . . -- 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
[Leaf-user] Who's experienced integrating WIC's into LEAF/LRP ???
We have an application that behooves us to include T-1/CSU/DSU into an LEAF/LRP box. So far, we have built several boxen that relied on Cisco routers to handle the WAN side. We are investigating products by Cyclades and Sangoma, which seem to meet our needs. However, never having done this, now is the time to ask questions: [1] Which product is the most cost effective for a single T-1 situation? [2] What are typical prices? How ought we to select from the alternatives? [3] What drivers are available? [4] What type of setup is required? [5] What changes/modifications are required to LEAF/LRP? [6] What else need we consider? Basically, we are interested in hearing any and all experiences, in this regard. What do you think? -- 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
[Leaf-user] WIC's LRP-CD ???
We have an application that behooves us to include T-1/CSU/DSU into an LEAF/LRP box. So far, we have built several boxen that relied on Cisco routers to handle the WAN side. We are investigating products by Cyclades and Sangoma, which seem to meet our needs. [1] Is LRP-CD ready to run these WIC's? [2] What changes/modifications are required to LRP-CD? Basically, we are interested in hearing any and all experiences, in this regard. What do you think? -- 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] dhcp on public interface ???
Charles Steinkuehler wrote: Yes, of course. I looked at that last night and I understand how to use it. Thank you. *Where* in syslinux.cfg should it go? LRP=etc,local,dhcpd,modules,ramdisk,ssh-1,sshd-1,update I'd _guess_ between local and dhcpd ??? Actually, anywhere in the LRP= string is fine. The packages are loaded in the order given, but assuming the LRP pakcages are created cleanly (ie the same file doesn't exist in more than one package), the order of the LRP= line is immaterial. I usually just tack new packages on to the end. FYI: The startup order *IS* important, but this is handled properly by the init scripts saved with the LRP package, not by the order the LRP pacages are loaded. Actually, I did have problems sometime back, which prompted this question. I get a little anal about code for which I'm responsible to maintain. So, as a matter of course, I usually alphabetize lists, the order of which does not matter. Having done this in syslinux.cfg, I was surprised when things did *not* work! I found that, in LRP-CD, ``local'' must precede ``dhcpd'' or surprising results obtain. I left it at that, never pursuing the root cause, and assumed that sometimes sequence in syslinux.cfg is critical -- hence the question . . . -- 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
[Leaf-user] dhcp on public interface ???
I am preparing to change an Edge/thinlinux firewall to LRP-CD. Unlike my other successful implementations, the external interface gets an dhcp address; but, requires a special identifier, which Edge calls ``dhcpcd_clientid''. Can I use dhcpd.lrp in this scenario? How do I configure this *required* special identifier? Is it this option: option dhcp-client-identifier CLIENT-FOO; Either way, *where* do I configure this? How do I configure /etc/dhcpd.conf for this special case of eth0? What do you think? -- 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] dachstein-pr2 available
Charles == Will this work as updates to LRP-CD? What needs to be done? Charles Steinkuehler wrote: I have just posted pre-release version 2 (pr2) of dachstein. The main change from pr1 is the merging of the several versions of firewall scripts I've got floating around. I've finally updated the (somewhat hacked) static-NAT DMZ support of the extended scripts V1.1, and merged this functionality with the Eiger based proxy-arp scritps from LRP-CD. I don't have an updated network.txt file documenting everything, but I did add and clarify the comments in network.conf, so if you're familiar with any of the existing scripts you shouldn't be too lost. I haven't done a lot of debugging on the DMZ aspect of the scripts yet, but the internal network portion is working OK. If anyone has the time or inclination to test firewall scripts, I'd be grateful. Disk image readme available here (and the normal mirror locations): http://lrp.steinkuehler.net/files/diskimages/dachstein/ Other info from the changelog: -- Changes from pr1 to pr2: -- dnscache modified to use 0.0.0.0 for listen IP, allowing local name resolution to work using 127.0.0.1 as the dns server /etc/network.conf no longer sourced in dnscache config file, as local IPs are no longer required firewall scripts changed to LRP-CD (Eiger based proxy-arp) version with extended scripts 1.1 functionality folded in...full support for routed, proxy-arp, static-nat, and port-forwarded DMZ systems dhclient init script fixed to support multiple interfaces -- 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
[Leaf-user] PCAnywhere vs. LRP-CD ???
OK, we know how to open ports tcp 5631 and udp 5632, and we can connect to PCAnywhere hosts behind LRP-CD -- from the Internet in general. However, specifically, when site A is behind LRP-CD(A) and site B is behind LRP-CD(B) and we are inside site B, we *cannot* connect to PCAnywhere hosts inside site A. What do you think? -- 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] http://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] mailonerr does *not* work!
Charles Steinkuehler wrote:
We've *not* been able to get mailonerr/moe.config to work (from Charles'
website: http://lrp.steinkuehler.net/Packages/Utilities.htm).
root@bluetrout:/var/log
# /usr/local/bin/mailonerr
/usr/local/bin/mailonerr: 56: Syntax error: end of file unexpected
(expecting })
root@bluetrout:/var/log
# /usr/local/bin/mailonerr moe.config
/usr/local/bin/mailonerr: 56: Syntax error: end of file unexpected
(expecting })
It fails at this line:
{ su $su_usr -c $cmd } 2$prefix.err 1$prefix.out
The command:
su $su_usr -c $cmd
works from the CLI; but, *fails* when called from this script. Yes, of
course, we have accounted for variable expansion . . .
What do you think?
Hmm...barring a problem with the script itself (like DOS end-of-lines or
something when it got downloaded), I don't know what's wrong. Verify the
script didn't get mangled, and if it looks OK, provide details on the system
you're running. I did have to make some mods to moe when I migrated it to a
'full' linux system (a RH 7.0 system running bash). I don't think this was
one of the problems I encountered, but it could have been...
First, let me say that we're still struggling with mail server issues;
so, success on this issue probably does *not* require mail received ;
Yes, we cleanse all scripts of the dreaded ^M, including this one. If
there is some other mangling issue, we remain unaware . . .
I'm puzzled by the use of curly braces '{ }' in that line. *Without*
the braces, we can call mailonerr from CLI _without_ error.
Once this issue is resolved, the next question is, How does LRP call
mailonerr? Ought we to put it in some crontab file?
What do you think?
--
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]
http://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] PCAnywhere vs. LRP-CD ???
Charles Steinkuehler wrote: OK, we know how to open ports tcp 5631 and udp 5632, and we can connect to PCAnywhere hosts behind LRP-CD -- from the Internet in general. However, specifically, when site A is behind LRP-CD(A) and site B is behind LRP-CD(B) and we are inside site B, we *cannot* connect to PCAnywhere hosts inside site A. What do you think? Does PCAnywhere make other connections? The behavior described would be expected if the system behind LRP-CD(A) tried to make a TCP (or other) connection to the system behind LRP-CD(B) after system (B) initiated the session. Check your firewall logs on both LRP-CD systems looking for denied packets. I'd bet you're dropping some traffic PCAnywhere needs to function... Yes, our first thoughts also -- however, neither side has anything in /var/log/kern.log . . . Actually, we're hoping that somebody has experienced -- and resolved -- precisely this, because symantec's website is worthless when it comes to troubleshooting ; Anybody tried VNC? -- 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] http://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] PCAnywhere vs. LRP-CD ???
Charles Steinkuehler wrote: Check your firewall logs on both LRP-CD systems looking for denied packets. I'd bet you're dropping some traffic PCAnywhere needs to function... Yes, our first thoughts also -- however, neither side has anything in /var/log/kern.log . . . Only packets acutally flagged for logging show up here...make sure you check the actual ipchains rules with svi network ipfilter list, and look for non-zero counts by any deny or reject rules... OK, I understand that not all DENY/REJECT/RETURN's are logged. Neither do I see any packet/byte quantities next to any DENY/REJECT/RETURN line that does not also sport the log flag. Let's recap: OK: wintel(A) - PCAnywhere - Internet - LRP-CD(B) - wintel(B) NOT: wintel(A) - PCAnywhere - LRP-CD(A) - Internet - LRP-CD(B) - wintel(B) So, it appears that there is something other than ports tcp 5631 and udp 5632 required -- on the connector's side -- to establish connection. Since nobody, apparently, has direct experience, we remain open to other guesses and recommendations . . . -- 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] http://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Need firewall design advice
We have a network of (64) public addresses connected to the Internet via DSL modem. This network consists of wintels and macs, and management of each is by different groups. Other than the Netopia DSL router, everything inside this network is 100% switched. Management insists that any user must be able to plug in anywhere on the network, regardless of platform -- so, we cannot divide platforms or systems by different switches. Two (2) of the wintels require remote (internet) PC Anywhere access. All of the macs require remote (internet) access via Timbuktu (tcp 407) and Retrospect remote backup (tcp/udp 497). The environment is growing and constantly in flux. Currently, there are a couple free IP addresses; but, keeping track of which are in use or free is nearly impossible! Clearly, that is what DHCP is for ; We tried putting LRP-CD into this network, using eth1 for a MASQ'd, DHCP'd, private network and a public DMZ on eth2 for those that require remote access. Unfortunately, broadcasts from eth1 are broadcast to eth2 by the switches, and vice versa, all of which are seen as martians!?!? It appears to us that this martian overhead is excessive and probably not a good network design ; Is there away to port forward on a given port (e.g., 407 *OR* 497) to a _group_ of systems? That way, we could assign private addresses to everything, and never worry about running out of public addresses . . . What other designs/solutions ought we to consider? What do you think? -- 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] http://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] mailonerr does *not* work!
We've *not* been able to get mailonerr/moe.config to work (from Charles'
website: http://lrp.steinkuehler.net/Packages/Utilities.htm).
root@bluetrout:/var/log
# /usr/local/bin/mailonerr
/usr/local/bin/mailonerr: 56: Syntax error: end of file unexpected
(expecting })
root@bluetrout:/var/log
# /usr/local/bin/mailonerr moe.config
/usr/local/bin/mailonerr: 56: Syntax error: end of file unexpected
(expecting })
It fails at this line:
{ su $su_usr -c $cmd } 2$prefix.err 1$prefix.out
The command:
su $su_usr -c $cmd
works from the CLI; but, *fails* when called from this script. Yes, of
course, we have accounted for variable expansion . . .
What do you think?
--
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]
http://lists.sourceforge.net/lists/listinfo/leaf-user
