sendmail traffic analysis
Recently I setup FreeBSD 4.3 on a HP Netserver (SMP) at my workplace and am stoked to be using FreeBSD for a production server in a predominantly Microsoft oriented distributed computing environment. It's a wonderful opportunity to show how well FreeBSD performs :^). This is the first time I've run FreeBSD on a SMP platform, the box has two processors and I was wondering if top shows an aggregate cpu load or just the load on cpu #0. This box will be the primary SMTP relay for our domain and I I'm looking for a way to measure the sendmail traffic load. I currently use MRTG to monitor our Sun SPARC based systems and run ucd-snmp on them. I'm not sure how to monitor sendmail with SNMP, and would be interested in hearing from others what tools they use to monitor SMTP traffic on their FreeBSD systems. -- __ / )_/_ It is a capital mistake to theorise before one has data. /--/ __ /Insensibly one begins to twist facts to suit theories, / (_/ (___ Instead of theories to suit facts. -- Sherlock Holmes, A Scandal in Bohemia Arthur W. Neilson III, WH7N - FISTS #7448 Bank of Hawaii Tech Support http://www.pilikia.net [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sendmail traffic analysis
On Fri, 11 May 2001, Arthur W. Neilson III wrote: Recently I setup FreeBSD 4.3 on a HP Netserver (SMP) at my workplace and am stoked to be using FreeBSD for a production server in a predominantly Microsoft oriented distributed computing environment. It's a wonderful opportunity to show how well FreeBSD performs :^). This is the first time I've run FreeBSD on a SMP platform, the box has two processors and I was wondering if top shows an aggregate cpu load or just the load on cpu #0. This box will be the primary SMTP relay for our domain and I I'm looking for a way to measure the sendmail traffic load. I currently use MRTG to monitor our Sun SPARC based systems and run ucd-snmp on them. I'm not sure how to monitor sendmail with SNMP, and would be interested in hearing from others what tools they use to monitor SMTP traffic on their FreeBSD systems. -- __ MRTG comes with contribs for monitoring sendmail. Todays root password is brought to you by /dev/random .-. | Steve Mickeler * Network Operations | +-+ | Neptune Internet Services | `-' 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.3-STABLE panics while mounting CD-R
Is it an audio cd? I've experienced the instant panic when mistakenly trying to mount such as a cd9660 fs. Of course it shouldn't panic, but the workaround is not to do that. Barney Wolff On Sat, May 12, 2001 at 01:24:46AM +0800, Eugene Grosbein wrote: Hi! 4.3-STABLE built 26 April 2001 does panic immediatly after mount -t cd9660. This is 100% repeatable with one particular CD-R when I do mount /cdrw (it runs very stable while I do not start playing with this disk). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sendmail traffic analysis
In article 20010511172756$[EMAIL PROTECTED] you write: I'm not sure how to monitor sendmail with SNMP, and would be interested in hearing from others what tools they use to monitor SMTP traffic on their FreeBSD systems. Depends on what and how you want to monitor. For BIND, I wrote a little script that stuffs those annoying statistics dumps into an RRD. You could conceivably do the same thing with sendmail, although you would have to collect your own stats by analyzing the log files. The one place where we use SNMP to monitor sendmail is by using ucd-snmp's process monitoring feature. We then use Cricket to monitor the number of sendmails active. While this is statistically invalid (because cricket measures every five minutes exactly) it still gives us a useful look at what's going on. (I just looked at my long-term cricket graphs and learned something which was totally new to me: there seems to be a new outbreak of the Hybris worm on the seventh day of every month, although the population seems to have peaked last February.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.3-STABLE panics while mounting CD-R
Is it an audio cd? I've experienced the instant panic when mistakenly trying to mount such as a cd9660 fs. Of course it shouldn't panic, but the workaround is not to do that. I get similar situations when mounting the 4.2-RELEASE 3rd CD for reading packages... This is with a 4.2-RELEASE system... From the boot messages: atapci0: Intel PIIX4 ATA33 controller port 0xd8 00-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 acd0: CDROM BCD E520C at ata1-master using PIO4 And here's an example: May 3 09:13:18 fjord /kernel: cd9660: RockRidge Extension May 3 09:14:02 fjord /kernel: acd0: READ_BIG - NO SENSE asc=00 ascq=00 error=00 May 3 09:14:12 fjord /kernel: acd0: READ_BIG - NO SENSE asc=00 ascq=00 error=00 May 3 09:15:00 fjord /kernel: acd0: READ_BIG command timeout - resetting May 3 09:15:00 fjord /kernel: ata1: resetting devices .. done May 3 09:15:30 fjord /kernel: acd0: READ_BIG command timeout - resetting May 3 09:15:30 fjord /kernel: ata1: resetting devices .. ata1-master: timeout w aiting for command=ef s=00 e=50 May 3 09:15:30 fjord /kernel: done May 3 09:15:56 fjord su: rivers to root on /dev/ttyp1 May 3 09:16:00 fjord /kernel: acd0: READ_BIG command timeout - resetting May 3 09:16:00 fjord /kernel: ata1: resetting devices .. ata1-master: timeout w aiting for command=ef s=00 e=50 May 3 09:16:00 fjord /kernel: done May 3 09:16:30 fjord /kernel: acd0: READ_BIG command timeout - resetting May 3 09:16:30 fjord /kernel: ata1: resetting devices .. ata1-master: timeout w aiting for command=ef s=00 e=50 May 3 09:16:30 fjord /kernel: done At which point the cdrom was hung and a reboot was needed... I can reproduce this when I NFS mount the CDROM with the 4.2-RELEASE Disk #2 in the drive. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sendmail traffic analysis
Today Garrett Wollman wrote: I'm not sure how to monitor sendmail with SNMP, and would be interested in hearing from others what tools they use to monitor SMTP traffic on their FreeBSD systems. Depends on what and how you want to monitor. For BIND, I wrote a little script that stuffs those annoying statistics dumps into an RRD. You could conceivably do the same thing with sendmail, although you would have to collect your own stats by analyzing the log files. Or use mailstats(1). -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- A Microsoft Certified Systems Engineer is to computing what a McDonalds Certified Food Specialist is to fine cuisine. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Sound (PCM) in 4.3
On Fri, 11 May 2001 15:45:42 +0100 (BST) George Reid [EMAIL PROTECTED] wrote: On Fri, 11 May 2001, Curtis King wrote: Some error messages (boot -v dmesg, pciconf -l etc) would help. Here is some more information as my SB Live doesn't work either. You seem to have the Plug Play OS (or similar) setting in your BIOS turned on. Ensure it's turned off. That did the trick - everything works fine now. thanks, ck --- ACI Worldwide Phone: 403-670-8838 Email: [EMAIL PROTECTED] Curtis King To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sendmail traffic analysis
jack ([EMAIL PROTECTED]) wrote: Today Garrett Wollman wrote: I'm not sure how to monitor sendmail with SNMP, and would be interested in hearing from others what tools they use to monitor SMTP traffic on their FreeBSD systems. Depends on what and how you want to monitor. For BIND, I wrote a little script that stuffs those annoying statistics dumps into an RRD. You could conceivably do the same thing with sendmail, although you would have to collect your own stats by analyzing the log files. Or use mailstats(1). I wrote a perl script to parse the named stats log file and return the number of queries. These results are available via snmp by using the 'exec' feature of ucd-snmpd to call the script. I use a shell script and snmpget(1) on my monitoring machine to collect the results and update a rrdtool database every 5 minutes. It would be easy to parse the output of mailstats(1) and return the results via snmp. Cheers, -- Mark Drayton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: What gives?
Rasputin wrote: ... -rw-r--r-- 1 root wheel 1955761 May 10 00:30 gnome -rw-r--r-- 1 root wheel 636835 May 10 02:46 kde2 Freaky - those two both work for me. Sounds like your ports tree is shafted, because the ports work for others. Interesting suggestion. Never mind the obvious 'how could it have been shafted?', but rather point out how one can verify the state of ones port collection. Please :). Each tarball has an unique MD5 hash. Each port release has the distinfo file with the MD5's it has been based upon. Hence each port can verify if the tarball fetched is the right one. Alternatively it can check if needed needed stuff like libs or execs are present. Yet how can a sysop check the correctness of the collection itself? As well as supporting utilities, of course. Just wipe /usr/ports and refetch the whole shebang? Coupled with a CVSup of the source, is it advisable to also wipe the /usr/src tree? Or are there diagnostic tools? Would be nice since that would be a nice first step in the diagnostic process. Roelof -- ___ eBOA® est. 1982 http://eBOA.com/tel. +31-58-2123014 mailto:[EMAIL PROTECTED]?subject=Information_requestfax. +31-58-2160293 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: What gives?
The most common thing I find is leftovers, like a Makefile.inc or a work directory, do a make clean on them, I periodically do a make clean in /usr/ports. I know there is probably a more efficient way to do it, but I just let it go for a while. You could also do it before you install somethings, just do a make clean install, because it also cleans the dependencies. - Original Message - From: Roelof Osinga [EMAIL PROTECTED] To: Rasputin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 4:15 PM Subject: Re: What gives? Rasputin wrote: ... -rw-r--r-- 1 root wheel 1955761 May 10 00:30 gnome -rw-r--r-- 1 root wheel 636835 May 10 02:46 kde2 Freaky - those two both work for me. Sounds like your ports tree is shafted, because the ports work for others. Interesting suggestion. Never mind the obvious 'how could it have been shafted?', but rather point out how one can verify the state of ones port collection. Please :). Each tarball has an unique MD5 hash. Each port release has the distinfo file with the MD5's it has been based upon. Hence each port can verify if the tarball fetched is the right one. Alternatively it can check if needed needed stuff like libs or execs are present. Yet how can a sysop check the correctness of the collection itself? As well as supporting utilities, of course. Just wipe /usr/ports and refetch the whole shebang? Coupled with a CVSup of the source, is it advisable to also wipe the /usr/src tree? Or are there diagnostic tools? Would be nice since that would be a nice first step in the diagnostic process. Roelof -- ___ eBOA® est. 1982 http://eBOA.com/tel. +31-58-2123014 mailto:[EMAIL PROTECTED]?subject=Information_requestfax. +31-58-2160293 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
fat32 slower than dogshit?
Well, i think it is, i'm actually not too sure exactly how fast dogshit is in the first place. But in doing a simple untar on a fat32 partition using both 4-stable a couple days after release and a recently updated 4-stable as of yesterday (5/10) it goes about 20-30 times slower than an untar on a UFS partition. Now i know fat32 is supposed to be slower than UFS, but this seems a little bit rediculous. Does this sound like a known problem? If someone wants more information I can probably dig down and get it if I know what you want... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: What gives?
If you really question your ports tree, just rm -rf /usr/ports/* and cvsup again. -Otter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David W. Chapman Jr. Sent: Friday, May 11, 2001 6:06 PM To: Roelof Osinga; Rasputin Cc: [EMAIL PROTECTED] Subject: Re: What gives? The most common thing I find is leftovers, like a Makefile.inc or a work directory, do a make clean on them, I periodically do a make clean in /usr/ports. I know there is probably a more efficient way to do it, but I just let it go for a while. You could also do it before you install somethings, just do a make clean install, because it also cleans the dependencies. - Original Message - From: Roelof Osinga [EMAIL PROTECTED] To: Rasputin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 4:15 PM Subject: Re: What gives? Rasputin wrote: ... -rw-r--r-- 1 root wheel 1955761 May 10 00:30 gnome -rw-r--r-- 1 root wheel 636835 May 10 02:46 kde2 Freaky - those two both work for me. Sounds like your ports tree is shafted, because the ports work for others. Interesting suggestion. Never mind the obvious 'how could it have been shafted?', but rather point out how one can verify the state of ones port collection. Please :). Each tarball has an unique MD5 hash. Each port release has the distinfo file with the MD5's it has been based upon. Hence each port can verify if the tarball fetched is the right one. Alternatively it can check if needed needed stuff like libs or execs are present. Yet how can a sysop check the correctness of the collection itself? As well as supporting utilities, of course. Just wipe /usr/ports and refetch the whole shebang? Coupled with a CVSup of the source, is it advisable to also wipe the /usr/src tree? Or are there diagnostic tools? Would be nice since that would be a nice first step in the diagnostic process. Roelof -- __ _ eBOA® est. 1982 http://eBOA.com/tel. +31-58-2123014 mailto:[EMAIL PROTECTED]?subject=Information_requestfax. +31-58-2160293 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: fat32 slower than dogshit?
Lamont Granquist wrote: Well, i think it is, i'm actually not too sure exactly how fast dogshit is in the first place. But in doing a simple untar on a fat32 partition using both 4-stable a couple days after release and a recently updated 4-stable as of yesterday (5/10) it goes about 20-30 times slower than an untar on a UFS partition. That sounds about right. This is one of many reasons I don't run WinDOS anymore. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
