Re: [Leaf-user] Dachstein-CD-rc3: mail anomolies
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 ___ 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
--- Michael D. Schleif [EMAIL PROTECTED] wrote: John Desmond wrote: --- Michael D. Schleif [EMAIL PROTECTED] wrote: John Desmond wrote: 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 *was* in there! My Windoze-based archive viewer-extracter ignores empty directories. 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! 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? -John __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ___ 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
[Leaf-user] word to the wise
D'err... if you're having trouble getting it to work and the interfaces are right and routing is right and firewall rules are right and everything pings but inbound masq's are rejected, don't rebuild the box several times... just make sure you don't have a kernel version mismatch on ip_masq_portfw and ip_masq_autofw :-) -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Re: Dachstein-CD-rc3 available
Thanks for the response. Patrick Benson wrote: Greg Morgan wrote: I ran nmap against the firewall. It was from the internal net against the external interface so I don't know if this counts? I saw these ports open. Shouldn't these be closed or am I being fooled by the firewall and these are really on the inside?: (The 1520 ports scanned but not shown below are in state: closed) Port State Service 53/tcp opendomain 80/tcp openhttp 1023/tcp openunknown The main structure of the firewall is designed to prevent packets from entering on to your external interface from ip's on the outside, trying to initialize connections from their end and to penetrate your system without your consent. What you're trying to do with nmap is to peek from the inside and you will usually get ports that are listed as open but only from the inside part of your network. If you scan them from outside then they will be listed as closed, since the firewall is shielding them from that end. Rick Onanian has a security list with sites that use nmap, nessus, etc., try Secure Design or Vulnerabilities.org: http://leaf.sourceforge.net/devel/thc/#Security dnscache - 53/tcp open domain weblet - 80/tcp open http bandwidth monitor (weblet) - 1023/tcp openunknown Closed on the outside but open on the inside (but weblet can be configured to be seen on the outside but it's not, by default)... -- Patrick Benson Stockholm, Sweden ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Help with getting weblet logs into weblet
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 . . . Continuing, the reason you need ramdisk.lrp (or ramlog.lrp) is because otherwise there is no provision for creating and formatting additional ramdisks. You could put mount entries in fstab, but without formatting them first, the ramdisks are pretty much useless. There are something like 16 available ramdisks...try mounting one: mount -t minix /dev/ram7 /mnt ramdisk.lrp provides the mkfs.minix binary, for formatting the additional ramdisks, and an init script to create the new ramdisks from a configuration file. Ramlog.lrp also provides a script that uncompresses any files found in /etc/ramdisk/ (they're assumed to be tar.gz files), so it can populate things like the /var/log filesystem after it's been created and mounted. It would be better to create yet another packge...something like loadmore.lrp, which would load LRP packages *after* extra ramdisks have been created/formatted/mounted, avoiding the problems encountered when trying to get several packages to use an additional ramdisk...I would have done this already, but there are only so many hours in the day sigh Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) 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... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD-rc3: mail anomolies
Of course, most of these anomalies are probably inherent in most other
versions of LEAF/LRP; but, this is the version I am using to debug and
solve these issues.
[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.
Also, could you verify the shell you're running?
[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.
[4] There seems to be a problem with the busybox hostname...I'll fix that
too.
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Dachstein-CD-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
[Leaf-user] Repost properly formatted Re: Martians: please, help track this one down ???
OOPS : - that didn't look to good - here it is a little easier on the eyes hopefully. Sorry for the repost Found out some more info for this issue - forgot to mail to the list previously, but here is pretty much everything you ever wanted to know about those pesky martian packets: as you explained martian source 3edb5d3f for 03db5d3f, dev eth1 3edb5d3f == 63.93.219.62 = source IP 03db5d3f == 63.93.219.3 = destination IP (may actually be your subnet broadcast address on the external interface - can't tell without gateway and subnet info tho) 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 type08:06 arp_hrd00:01 /* Ethernet1*/ arp_prot 08:00 /* IP=0x800 */ arp_hlen 06 /* hlen = 6 */ arp_plen 04 /* plen = 4 */ arp_op 00:01 /* arp ARP_REQ*/ arp_sha00:c0:7b:61:44:fe /* 123 */ arp_spacc:b2:d7:7b /* 123 */ arp_tha00:00:00:00:00:00 arp_tpacc: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 Hope it helps a little Simon From: Michael D. Schleif [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: LEAF [EMAIL PROTECTED] Subject: [Leaf-user] Martians: please, help track this one down ??? Date: Mon, 29 Oct 2001 22:33:15 -0600 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 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Martians: please, help track this one down ???
http://leaf.sourceforge.net/devel/thc/dox/martian.txt is the FM By the way, the FM at lrp.c0wz.com, seems to be down, at least on ports 80 and 81. 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
