Re: Intel SR1325TP1-E & 3ware 9xxx RAID thoughts
Henrique de Moraes Holschuh wrote: >On Fri, 15 Oct 2004, Dave Watkins wrote: > > >>The reason i2c won't work on these boards is because they use IPMI >>rather than i2c and have a BMC on them which does much more in the way >>of management than desktop type boards >> >> > >Well, if it is anything like SE750x boards, you need to first setup the >entire BMC system using the Intel CD (that runs Windows :P) before it >will do anything useful. > >After that is done, you *can* access the sensor data though IPMI, and even >reconfigure the BMC from Linux. There is even an lm-sensors module for >accessing IPMI sensor data. It is slow, but it works. Mostly :P > >I don't recall where I found the IPMI sensor module anymore, though. >Maybe it is even packaged in sid/sarge nowadays. I think it was OpenIPMI >or something like that. > > > The 1325 should already be setup properly as the board is custom to the chassis and that the only way the system is sold.. Also the CD is self booting and doesn't require windows to setup anyway. You have to flash the BMC and set it up that way and configure the password for acces via the bootable CD. This will also install the "Service Partition" Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Thu, 14 Oct 2004 13:35, "Lucas Albers" <[EMAIL PROTECTED]> wrote: > > As long as the machine is fixed within four days of a problem we don't > > need > > more than one. Email can be delayed, it's something you have to get used > > to. > > Machines are cheap enough, wouldn't it be reasonable to throw in > redundancy? Unless having 2 machines adds unneccessary complexity to the > setup. Better to have one good machine than three cheap machines. The more machines you have the greater the chance that one of them will break. > Sometimes I don't even realize one of the external relays is broken for a > day...(even though the monitoring tools should tell you.) Which is another good reason for not having such redundant servers. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Thu, 14 Oct 2004 23:35, martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.10.14.1525 +0200]: > > Or we can do it in two, with capacity to spare AND no downtime. > > I would definitely vote for two systems, but for high-availability, > not load-sharing. Unless we use a NAS or similar in the backend with > Maildirs to avoid locking problems. Then again, that's definitely > overkill... A NAS in the back-end should not be expected to increase reliability. Every time you increase the complexity of the system you should expect to decrease reliability. KISS! -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Fri, 15 Oct 2004 03:19, Arnt Karlsen <[EMAIL PROTECTED]> wrote: > > Increasing the number of machines increases the probability of one > > machine failing for any given time period. Also it makes it more > > difficult to debug problems as you can't always be certain of which > > machine was involved. > > ..very true, even for aero engines. The reason the airlines like > 2, 3 or even 4 rather than one jet. You seem to have entirely misunderstood what I wrote. Having four engines on a jet rather than two or three should not be expected to give any increase in reliability. Having two instead of one (and having two fuel tanks etc) does provide a significant benefit. However the needs of an aircraft are significantly different from a mail server. When a mail server has a problem we have the option of pulling the plug and then taking some time to fix it. There is no equivalent operation for an aircraft. When installing two engines in an air-craft that can run on a single engine you are trading off an increased risk of having an engine fail against a greatly decreased risk that an engine failure will kill everyone on board. With mail servers if you have a second server you have more work to maintain it, more general failures, and you have no chance of saving anyone's life to compensate. Finally consider that one of the main causes of server unreliability is mistakes made during system maintenance. Increase the amount of work involved in running the systems and you increase the chance of problems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
On Wed, 13 Oct 2004 07:18, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote: > I'm currently writing a proposal for a webmail service for, say, 50 > 000 to 500 000 users. I'm looking for description of existing "big 50K isn't big by today's standards. An ISP I used to work for has something like 1,300,000 users. They have two SMTP machines for outbound email which do virus scanning (to stop customers from sending viruses). They have four SMTP machines for inbound mail which do anti-spam and virus scanning (RAV anti-virus and Qmail). Those four machines send mail to the back-end machines according to data in OpenLDAP (about four slave OpenLDAP servers and one master). There are six back-end machines for mail store that run Qmail for delivery and the Courier POP and IMAP servers, all data on user mail directory and password is in LDAP. The back-end servers use ReiserFS mounted noatime for storage. When a user connects via POP or IMAP they get to a Perdition server, there are three Perdition servers behind Cisco LocalDirectors (for reliability and load balancing) which proxy IMAP and POP to the correct back-end servers after doing an LDAP lookup. The Perdition server machines also run Apache and IMP for webmail, the webmail instance uses Perdition on localhost for IMAP access. The machines are pretty much all Dell servers with 2*2.8GHz P4 CPUs, about 4G of RAM, and 4*U160 disks in a RAID-5 array (with one hot spare). The machines were all running 2.4.2x last time I was there, but they may be moving to 2.6.x now. SAN and NAS are best avoided IMHO. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
Stephane Bortzmeyer wrote: I do not need general advice (such as "Postfix rules, Exim sucks" or "Maildirs are faster") but actual description of existing and running systems. Googling seems inefficient for that purpose and I presume that many interesting papers are only in closed and paying conference proceedings :-( Are 33 millions enough? :-) Here is something about outblaze: http://www.hserus.net/mailboxes-srs-inboxevent2004.ppt HTH, HAND -- Balla Emanuele[EMAIL PROTECTED] Spin InterNetWorking http://www.spin.it Via del Follatoio, 12 Phone: +39-40-9869090 I-34148 Trieste - Italy Fax : +39-40-8992286 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
## Russell Coker ([EMAIL PROTECTED]): > SAN and NAS are best avoided IMHO. We put our mailboxes (about 100GB per server with cyrus IMAP) in a fibrechannel-connected SAN (there're some EMC cabinets in out server rooms), wich runs fairly well. You have to look for changing LUNs (this might be really nasty), but LVM helps. Regards, Christoph -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
On Fri, Oct 15, 2004 at 06:56:21PM +1000, Russell Coker wrote: > The machines were all running 2.4.2x last time I was there, but they > may be moving to 2.6.x now. All the stores, relays and proxies are still on 2.4.x, but the LDAP servers are now on 2.6.x (mainly because I could, not for any technical reason. At the time I upgraded them I had enough redundancy to go around that the downtime didn't affect anything). The system is still mostly as you described, with just a few changes: Four perdition/apache/imp servers now, rather than three. The webmail is rather popular now, and three servers couldn't cut it on their own anymore. Seven backend mailstores now, and I really want an eighth, but can't get anyone to pay for it. -- Paul Dwerryhouse| PGP Key ID: Amsterdam, The Netherlands (X) <-> Melbourne, Australia ( ) | 0x6B91B584 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
Le vendredi 15 octobre 2004 à 12:08, Paul Dwerryhouse écrivait: > Seven backend mailstores now, and I really want an eighth, but can't get > anyone to pay for it. Your backend mailstores are running NFS on Linux 2.6 ? Don't you have any performance problems ? Do you know how many mails you receive per day ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
On Fri, Oct 15, 2004 at 12:30:56PM +0200, Aurélien Beaujean wrote: > Your backend mailstores are running NFS on Linux 2.6 ? Don't you have > any performance problems ? We don't use NFS. Only the LDAP servers are using 2.6.x - everything else is still on 2.4. > Do you know how many mails you receive per day ? If I'm reading our stats pages correctly, we seem to average 1.1 million email messages making it through to our stores per day. Paul. -- Paul Dwerryhouse| PGP Key ID: Amsterdam, The Netherlands (X) <-> Melbourne, Australia ( ) | 0x6B91B584 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
why multicasting is working?
Hello all, I have two linux debian systems, one with kernel 2.2.18, another with 2.4.20. Both kernels have option "IP: multicasting" DISABLED. However multicasting is working and both systems answered if I ping 224.0.0.1, and multicast programs are working! The question is: why this option "IP: multicasting" is present in the kernel, if multicasting is always working??? Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Fri, 15 Oct 2004, Russell Coker wrote: > On Thu, 14 Oct 2004 13:35, "Lucas Albers" <[EMAIL PROTECTED]> wrote: > > Machines are cheap enough, wouldn't it be reasonable to throw in > > redundancy? Unless having 2 machines adds unneccessary complexity to the > > setup. > > Better to have one good machine than three cheap machines. The more machines > you have the greater the chance that one of them will break. Just to make it clear, I am advocating two *good* machines. > > Sometimes I don't even realize one of the external relays is broken for a > > day...(even though the monitoring tools should tell you.) > > Which is another good reason for not having such redundant servers. Now, that is a bit too far. The correct answer is to monitor the damn things. And any sort of monitoring that would not catch a problem is not good enough. A good enough reacive (as opposed to predictive) monitoring for email is rather easy to do (just send one directly to the MX, and freak if it does not send it back to you in a given time window). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Fri, 15 Oct 2004, Russell Coker wrote: > You seem to have entirely misunderstood what I wrote. And I think I had misunderstood you, but your message cleared things up... > Having four engines on a jet rather than two or three should not be expected > to give any increase in reliability. Having two instead of one (and having > two fuel tanks etc) does provide a significant benefit. [...] > With mail servers if you have a second server you have more work to maintain > it, more general failures, and you have no chance of saving anyone's life to > compensate. > > Finally consider that one of the main causes of server unreliability is > mistakes made during system maintenance. Increase the amount of work > involved in running the systems and you increase the chance of problems. In other words, your point is not that two MX are not more "resilient to failure", but rather that the work of administrating them is not worth the gain in resilience ? That would depend directly on what sort of downtime you want to tolerate on the mail system. IMHO, >4h downtimes in Debian's mailsystem is something to avoid at any reasonable cost, and that would require either two active MX, or a ready-to-deploy MX kept inside the closet (which is more dangerous maintenance-wise than two live MX IMO) for the worst-case scenario. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
On Fri, 15 Oct 2004, Christoph Moench-Tegeder wrote: > ## Russell Coker ([EMAIL PROTECTED]): > > > SAN and NAS are best avoided IMHO. NAS is *always* best avoided on anything that has "mail" in the description, IMHO. > We put our mailboxes (about 100GB per server with cyrus IMAP) > in a fibrechannel-connected SAN (there're some EMC cabinets in That's how it is usually done with Cyrus IMAP (since upstream makes it quite clear that you are either stupid or a daredevil if you run Cyrus IMAP on top of any sort of NAS) :) Good SAN is the proper way to consolidade disks, and if you have the option to use it, it is usually worth the trouble. OTOH, using SAN for shared storage (HA) is prone to all sort of BIG blowups as any other HA setup, so if you can avoid it... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.10.15.1448 +0200]: > Just to make it clear, I am advocating two *good* machines. ENOSUCHTHING wrt it not failing. > > Which is another good reason for not having such redundant > > servers. > > Now, that is a bit too far. The correct answer is to monitor the > damn things. And any sort of monitoring that would not catch > a problem is not good enough. A good enough reacive (as opposed > to predictive) monitoring for email is rather easy to do (just > send one directly to the MX, and freak if it does not send it back > to you in a given time window). While I understand Russell's concerns, I think that we should have a second machine to be able to swap in. If the primary every goes down, then the secondary must be able to take over, or else we will have problems with the project. We cannot assume that the MX admin will be able to fix the problem ASAP. About backup MX... well, we can put them elsewhere. I run a couple reliable MXs and could also serve as backup for Debian. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.10.15.1455 +0200]: > In other words, your point is not that two MX are not more > "resilient to failure", but rather that the work of administrating > them is not worth the gain in resilience ? This is frequently a problem people do not (like to) see. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Fri, 15 Oct 2004, martin f krafft wrote: > also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.10.15.1448 +0200]: > > Just to make it clear, I am advocating two *good* machines. > > ENOSUCHTHING wrt it not failing. Nor did I intend to imply that they wouldn't fail :) > > > Which is another good reason for not having such redundant > > > servers. > > > > Now, that is a bit too far. The correct answer is to monitor the > > damn things. And any sort of monitoring that would not catch > > While I understand Russell's concerns, I think that we should have > a second machine to be able to swap in. If the primary every goes And it better be live, or it gets wy easier for it to fall out-of-sync with what was done to the primary machine. > About backup MX... well, we can put them elsewhere. I run a couple > reliable MXs and could also serve as backup for Debian. I'd rather we had no backup MX per se, but two equally-ranking ones (i.e. two primary ones)... this is also because of how Debian system administration is usually done, and because of the big drawbacks of secondary MX that are not configured exactly as the primary ones... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.10.15.1512 +0200]: > And it better be live, or it gets wy easier for it to fall > out-of-sync with what was done to the primary machine. That's a policy issue. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Fri, 15 Oct 2004 18:41:06 +1000, Russell wrote in message <[EMAIL PROTECTED]>: > On Fri, 15 Oct 2004 03:19, Arnt Karlsen <[EMAIL PROTECTED]> wrote: > > > Increasing the number of machines increases the probability of one > > > machine failing for any given time period. Also it makes it more > > > difficult to debug problems as you can't always be certain of > > > which machine was involved. > > > > ..very true, even for aero engines. The reason the airlines like > > 2, 3 or even 4 rather than one jet. > > You seem to have entirely misunderstood what I wrote. ..really? Compare with your average automobile accident and see who has the more adequate safety philosophy. > Having four engines on a jet rather than two or three should not be > expected to give any increase in reliability. Having two instead of > one (and having two fuel tanks etc) does provide a significant > benefit. ..common belief among pilots is 25% power loss is a fair bit less likely to put you in the drink than 50%, however airliners won't ever hang up in midair for 5 days, unless we return to Zeppeliners. ;-) > Finally consider that one of the main causes of server unreliability > is mistakes made during system maintenance. Increase the amount of > work involved in running the systems and you increase the chance of > problems. ..proven true in aviation too. ;-) Accepting this safety philosophy in aviation, is IMNTHO a flaw best shown in how safety problems are "fixed" with security measures; has anyone here worn a chute in an airliner? ;-) [EMAIL PROTECTED], "2 boxes watching each other" or some such, will give that "Ok, I'll have a look some time next week" peace of mind, and we don't need symmetric power here, one big and one or more small ones will do fine, and d.o does have Zeppeliner loiter endurance if we manage to cook the new big iron. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Check to see if the kernel switches are on (1) or off (0): find /proc/net -name '*cast* find /proc/sys -name '*cast*' On 15/10/04 15:20 +0400, Oleg Butorin wrote: > Hello all, > > I have two linux debian systems, one with kernel 2.2.18, another with > 2.4.20. > Both kernels have option "IP: multicasting" DISABLED. However > multicasting is working and both systems answered if I ping 224.0.0.1, > and multicast programs are working! The question is: why this option > "IP: multicasting" is present in the kernel, if multicasting is always > working??? > > Thank you. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which primates extrapolate an understanding of human existance. Existance itself is transient state that passes upon death. Like material gain, the knowledge gained in life is completely useless at the time of death. Not even the knowlege of death itself will save you. Thus, enjoy your transient existance for death is believed to be hastily approaching. -- an unknown smartass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secure Delivery between MTA and MDA
Just setup Postfix as an MTA on your MDA server with TLS enabled. This may seem complicated, however it can be fairly simple. You can have all email scanned/relayed through a gateway mail-server. The internal MTA can be firewalled to prevent other connections from using it. Additionally only dns and trasport modifcatinion need to be messed with, I think. Here is a working example :) MX record: imap2:/var/imap# host -t mx someplace.com someplace.comMX 3 ruby.someplace.com someplace.comMX 2 espresso.someplace.com Internal MDA runs postfix as a MTA: imap2:cat /etc/postfix/transport imap.someplace.com local:[imap.someplace.com] someplace.com local:[imap.someplace.com] * :[smtp.someplace.com] External MTA runs Postfix also: cat /etc/postf/transport someplace.com smtp:[imap.someplace.com] imap.someplace.comsmtp:[imap.someplace.com] * Note, you could also use NFS, but email messages might be lost if the connection is lost. On 15/10/04 11:20 +1300, Simon Buchanan wrote: > We are setting up mail services to service a small ISP (-2000 Mail > boxes) using postfix and DBmail, which we have configured and working > well. The MTA (postfix with spam/virus) sits on a pairing exchange > (along with a web server)... we are connected to the Internet from the > pairing exchange via a 100Mbit connection. From the exchange to our NOC > is a 5Mbit pipe. The MDA (postfix/DBMail) sits in off our NOC. > > What i want to do is setup some sort of secure transfer between the MTA > and MDA. In theory the only traffic that is comming into the MDA is > correctly filtered mail.. Outgoing is a different story and not an issue > here. > > The MDA is sitting in its own DMZ behind a Borderware firewall. > > Suggesions for/against/other are welcome (please!) > > Regards, > > Simon > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which primates extrapolate an understanding of human existance. Existance itself is transient state that passes upon death. Like material gain, the knowledge gained in life is completely useless at the time of death. Not even the knowlege of death itself will save you. Thus, enjoy your transient existance for death is believed to be hastily approaching. -- an unknown smartass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Actually, this set of find commands will work better:
find /proc/net -name '*cast* -print -exec cat {} ';'
find /proc/sys -name '*cast* -print -exec cat {} ';'
On 15/10/04 10:36 -0400, Theodore Knab wrote:
> Check to see if the kernel switches are on (1) or off (0):
>
> find /proc/net -name '*cast*
>
> find /proc/sys -name '*cast*'
>
>
> On 15/10/04 15:20 +0400, Oleg Butorin wrote:
> > Hello all,
> >
> > I have two linux debian systems, one with kernel 2.2.18, another with
> > 2.4.20.
> > Both kernels have option "IP: multicasting" DISABLED. However
> > multicasting is working and both systems answered if I ping 224.0.0.1,
> > and multicast programs are working! The question is: why this option
> > "IP: multicasting" is present in the kernel, if multicasting is always
> > working???
> >
> > Thank you.
> >
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact
> > [EMAIL PROTECTED]
> >
>
> --
> --
> Ted Knab
> Chester, Maryland 21619 USA
> --
> The perception of knowledge is an egotistical farce in which
> primates extrapolate an understanding of human existance.
> Existance itself is transient state that passes upon death. Like
> material gain, the knowledge gained in life is completely useless
> at the time of death. Not even the knowlege of death itself will save you.
> Thus, enjoy your transient existance for death is believed to be
> hastily approaching.
> -- an unknown smartass
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
--
Ted Knab
Chester, Maryland 21619 USA
--
The perception of knowledge is an egotistical farce in which
primates extrapolate an understanding of human existence.
Existence itself is transient state that passes upon death. Like
material gain, the knowledge gained in life is completely useless
at the time of death. Not even the knowledge of death itself will save you.
Thus, enjoy your transient existence for death is believed to be
hastily approaching.
-- an unknown smart-ass
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advice for an IP accounting program
The main purpose is identify periodically boxes on an internal private network which cause very high traffic, due to worms, virus and so. A per-IP simple report a la mrtg could be nice. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for an IP accounting program
also sprach Francesco P. Lovergine <[EMAIL PROTECTED]> [2004.10.15.1702 +0200]: > The main purpose is identify periodically boxes on an internal private > network which cause very high traffic, due to worms, virus and so. > A per-IP simple report a la mrtg could be nice. apt-cache search ip accounting -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Advice for an IP accounting program
Hi You might like the bandwidthd Debian package which is at http://fjortis.info/pub/debian/ Gerhard Francesco P. Lovergine wrote: The main purpose is identify periodically boxes on an internal private network which cause very high traffic, due to worms, virus and so. A per-IP simple report a la mrtg could be nice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
## Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > > We put our mailboxes (about 100GB per server with cyrus IMAP) > > in a fibrechannel-connected SAN (there're some EMC cabinets in > That's how it is usually done with Cyrus IMAP (since upstream makes it quite > clear that you are either stupid or a daredevil if you run Cyrus IMAP on top > of any sort of NAS) :) So, now we would like Russel to explain why he does not like SAN. > OTOH, using SAN for shared storage (HA) is prone to all sort of BIG blowups > as any other HA setup, so if you can avoid it... Even the slightest mistake in your HA config will really ruin your day. Larger mailstores are generally more PITA to fix than small ones, in an exponential type of "more". BTDT. Regards, Christoph -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for an IP accounting program
On Fri, Oct 15, 2004 at 04:12:17PM +0100, Gerhard Venter wrote: > > You might like the bandwidthd Debian package which is at > http://fjortis.info/pub/debian/ > Mmm, yes thanks quite near to what I was looking for, ntop is unfortunately too much complicated for a naive user. If you are yet looking for a sponsor I could be that. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for an IP accounting program
On Fri, Oct 15, 2004 at 05:09:02PM +0200, martin f krafft wrote: > also sprach Francesco P. Lovergine <[EMAIL PROTECTED]> [2004.10.15.1702 +0200]: > > The main purpose is identify periodically boxes on an internal private > > network which cause very high traffic, due to worms, virus and so. > > A per-IP simple report a la mrtg could be nice. > > apt-cache search ip accounting > Eh eh, that has been the first thing I tried. Unfortunately the (maybe) best one (ntop) is not in the list. So I suspect apt-cache search is largerly not sufficient for this kind of things. And btw ntop is largerly oversized for the thing. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for an IP accounting program
martin f krafft wrote: also sprach Francesco P. Lovergine <[EMAIL PROTECTED]> [2004.10.15.1702 +0200]: The main purpose is identify periodically boxes on an internal private network which cause very high traffic, due to worms, virus and so. A per-IP simple report a la mrtg could be nice. apt-cache search ip accounting The best ive seen was not in debian when i chacked. Its an ipacc but patched to lazyly report to a mysql database. This way the measurement doesnt take a lot of resources in a really demanding environment (after truly 10MBit mixed bandwidth, the measurment problem becomes really complex) search for ipaccounting mysql in google. begin:vcard fn:Alejandro Borges n:Borges;Alejandro email;internet:[EMAIL PROTECTED] url:http://www.stepone.com.mx version:2.1 end:vcard
Re: Advice for an IP accounting program
also sprach Alex Borges <[EMAIL PROTECTED]> [2004.10.15.1742 +0200]: > The best ive seen was not in debian when i chacked. Its an ipacc > but patched to lazyly report to a mysql database. This way the > measurement doesnt take a lot of resources in a really demanding > environment Yeah, except for the resources eaten by MySQL, which has no place in a "really demanding environment", IMHO. Not wanting to start a religious war... it is my opinion when I suggest to use a proper database server instead. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Documentation of big "mail systems"?
On Fri, 15 Oct 2004, Christoph Moench-Tegeder wrote: > So, now we would like Russel to explain why he does not like SAN. He probably doesn't advocate using SAN instead of local disks if you do not have a good reason to use SAN. If that's it, I *do* agree with him. Don't use SANs just for the heck of it. Even external JBOD enclosures are a bad idea if you don't need them. But not using a SAN that is already available at a datacenter where all disks are consolidated into large redundant FC SANs, well, that would be silly IMHO. Diskless machines are, if anything, much faster to replace with a spare one when you need to get them serviced :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of big "mail systems"?
## Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > > So, now we would like Russel to explain why he does not like SAN. > He probably doesn't advocate using SAN instead of local disks if you do not > have a good reason to use SAN. If that's it, I *do* agree with him. Don't > use SANs just for the heck of it. Even external JBOD enclosures are a bad > idea if you don't need them. Of course. Buying SAN for a single mailserver is not worth the money. Think of money per gigabyte and the extra trouble of managing your SAN, local disks are much easier to handle. > But not using a SAN that is already available at a datacenter where all > disks are consolidated into large redundant FC SANs, well, that would be > silly IMHO. Diskless machines are, if anything, much faster to replace > with a spare one when you need to get them serviced :) Yeah. "I need 250 GB" - "Wait a moment - there you are". That is fun. Regards, Christoph -- Spare Space -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for an IP accounting program
martin f krafft wrote: also sprach Alex Borges <[EMAIL PROTECTED]> [2004.10.15.1742 +0200]: The best ive seen was not in debian when i chacked. Its an ipacc but patched to lazyly report to a mysql database. This way the measurement doesnt take a lot of resources in a really demanding environment Yeah, except for the resources eaten by MySQL, which has no place in a "really demanding environment", IMHO. Not wanting to start a religious war... it is my opinion when I suggest to use a proper database server instead. Agreed. In my medium sized environment this scaled well, but if we are talking really post 10mbit very mixed traffic and complex stats, mysql aint gonna cut it. Still, if youre in charge of such a thing, it should be no problem for you to hack ipac-ng to work with postgres, or use iptables log+syslog-ng to relay to a log server and analyze it there (although im not shure this would be an ideal solution... id go for the lazy db). begin:vcard fn:Alejandro Borges n:Borges;Alejandro email;internet:[EMAIL PROTECTED] url:http://www.stepone.com.mx version:2.1 end:vcard
Re: why multicasting is working?
I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to your default route. Then the pkt would get multicasted and you would receve multiple responces. IIRC kernel level MC support is only for if you want to be on Mbone, not if you want to use it as a client/server. --- Oleg Butorin <[EMAIL PROTECTED]> wrote: > Hello all, > > I have two linux debian systems, one with kernel 2.2.18, another with > 2.4.20. > Both kernels have option "IP: multicasting" DISABLED. However > multicasting is working and both systems answered if I ping 224.0.0.1, > and multicast programs are working! The question is: why this option > "IP: multicasting" is present in the kernel, if multicasting is always > working??? > > Thank you. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Apache 2.0 ISP setup..
Hi there, At the moment we are running apache 1.3.x on a debian woody box with PHP/MySQL enabled for selected sites and also a shared verisign cert (also for selected sites). At the moment we store the config in MySQL and then have a script that writes lots of config files to a conf/ dir (one for each host). About 250 of them. A couple of things i would value input on are: 1). Is there a way for apache to read its vhosts config directly from db? 2). Whats your general thoughts on apache 2.0 3). Is using PHP cgi for virtual hosts OK (For Security)? Are their any TFYP here? Thanks Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initrd in Debian kernel-image
On Thu, Sep 30, 2004 at 12:12:30AM +1000, Donovan Baarda wrote: > > Le mercredi 29 septembre 2004 ? 12:37, Gavin Hamill ?crivait: > > > My question is... how does dpkg know that I need to load the megaraid > > > module in the initrd so the system can mount / for init to boot the > > > machine? I've looked in /etc/mkinitrd and seen the 'modules' file - > > > should I just stick 'megaraid' in there just in case? Would this cause > > > any harm if it's already been included? > [...] > The trick is getting the initrd right... Debian has /etc/mkinitrd/modules > and /etc/mkinitrd/mkinitrd.conf to tweak this... read up on the initrd-tools > package, and note that the Debian kernel-image packages depend on this > package to build their initrd images when they are installed. i find it far less hassle to build custom kernels without an initrd image. IMO, initrd is useful for a distribution kernel which has to run on lots of different machines, but is a waste of time, effort, and RAM when building a custom kernel for a specific machine. just make sure you compile the drivers you need to boot in to the kernel, and all other drivers can be either modules or compiled in (doesn't really matter). personally, i like most stuff compiled in but have non-essential stuff (sound, usb, v4l, etc) compiled as modules. i like the networking stuff compiled in - every machine i build needs networking so i see no benefit in having ipv4 or packet socket or any of the other core network stuff as modules. i usually compile various common network card drivers as modules - that way if a NIC dies, i can just replace it with whatever i have handy or can get on short notice and know that a driver module will be already on the system. the basic rule of thumb is: "if i'm likely to need it to boot or if it's essential for what the machine is supposed to do, then it gets compiled in to the kernel. otherwise as a module". craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initrd in Debian kernel-image
> the basic rule of thumb is: "if i'm likely to need it to boot or if it's > essential for what the machine is supposed to do, then it gets compiled in to > the kernel. otherwise as a module". > > craig Agree completely. In or case, we also compile in the 3ware RAID stuff, a few common NIC drivers like the cheapo NE2000 or similar so we can drop in a rubbish card if the Intel or 3com cards fail. In my experience, putting essentials built-into the kernel is wise, as they tend to have much less chance of fcsking up than modules. YMMV. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
