Re: [CentOS] Intel NIC
Greetings, On Thu, Dec 23, 2010 at 4:27 PM, Les Mikesell wrote: > On 12/23/2010 10:02 AM, Alexander Dalloz wrote: > The licensed vCenter stuff refers to a single app that is > simultaneously aware of all of your ESXi servers and their guests and > can move/fail resources across servers - concepts that I don't think the > other hypervisors even have. Duh.. What is RHEV then? I am in front of the box now. Can you tell me which feature is missing? if any, perhaps we can raise a point with redhat. Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Friday, December 24, 2010 01:03 AM, Les Mikesell wrote: > On 12/23/2010 10:28 AM, Christopher Chan wrote: >> > Matt wrote: >> Is ext4 stable on CentOS 5.5 64bit? I have an email server with a >> great deal of disk i/o and was wandering if ext4 would be better then >> ext3 for it? > > Before committing to ext4 on a production server, it > would be good to consider the comments made in > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 > which presumably still apply to current CentOS 5.5 64-bit kernels. > As I read it, Ts'o argues that the apparent loss of stability > compared to ext3 is a design issue in the realm of applications > that run atop it. I hope this is not a misreading. Waiting for applications to be properly written, ie use fsync(), is no way to pick a file system. You'd have the same problems on xfs or any other file system that does delayed writes. >>> >>> But note that the reason applications don't use fsync() when they should >>> is probably due to linux historically not implementing it in a >>> reasonable way (i.e. it would flush the entire filesystem buffer and >>> wait for completion instead of just the requested file's outstanding >>> blocks). Not sure when/if that was fixed - but it is also probably >>> behind the old impressions that mysql is faster than postgresql. >>> >> >> Can we drop the fsync nonsense? > > No, if you don't remember history you are doomed to repeat it. Well, come to think of it, I guess most open source apps are developed on Linux and so its implementation does colour how devs think about fsync...nevermind that it is done properly on the BSDs and UNIXes > >> Apps that are data sensitive should be >> using fsync/fsyncdata (fsync is a posix specification so the history of >> how linux implemented fsync has nothing to do with whether applications >> used it or not) otherwise it should not be even consider for the task. >> The lying fsync/fsyncdata was fixed when write barrier support was >> introduced and filesystems updated to use write barriers. As for the >> flush entire buffer...IIRC, that is specific to ext3 and even that >> should be now gone with the update to write barrier support. > > It's one of those 'have you stopped beating your wife things'. Apps > that correctly used fsync were slow because of the OS implementation, so > people used other apps. So now you have popular apps that do things > wrong. > Yeah, funny how ext3 managed to become the dominant Linux filesystem when it was the one with the flush everything quirk and at a time when fsync did not really honour the 'yes it is safely on the platters' maxim. Let's thank Redhat for this mess. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Friday, December 24, 2010 05:25 AM, Ross Walker wrote: >> I'd stick with ext3 + data=journal with the journal either on some uber >> fast and large external BBU nvram block device (you can get up to 1TB >> with speeds of 750MiB/sec+ if you have a fat enough bus) or on hardware >> raid with sufficient BBU cache for an email server. Or anything with >> barrier support through the entire chain (read: no LVM). > > I believe barrier support is being deprecated in current kernels. Don't > remember what they are replacing them with, straight FUA maybe. Barriers > never performed well enough. Yea, I get a heads up. I did not know about barriers until after a year it was implemented. But I'll still want to use some nvram solution from umem or fusionio for scenarios where a lot of files are transient or created and deleted almost immediately and high performance is required. Storage usually means get the hardware to mitigate data loss due to whatever or ensure barrier/whatever support. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Dec 23, 2010, at 4:25 PM, Ross Walker wrote: > On Dec 23, 2010, at 11:21 AM, Christopher Chan > wrote: > >> On Thursday, December 23, 2010 11:08 PM, Ross Walker wrote: >>> On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: >>> Matt wrote: > Is ext4 stable on CentOS 5.5 64bit? I have an email server with a > great deal of disk i/o and was wandering if ext4 would be better then > ext3 for it? Before committing to ext4 on a production server, it would be good to consider the comments made in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 which presumably still apply to current CentOS 5.5 64-bit kernels. As I read it, Ts'o argues that the apparent loss of stability compared to ext3 is a design issue in the realm of applications that run atop it. I hope this is not a misreading. >>> >>> Waiting for applications to be properly written, ie use fsync(), is no way >>> to pick a file system. You'd have the same problems on xfs or any other >>> file system that does delayed writes. >> >> Whoa, whoa. 1) Theodore was not pushing fsync, he was pushing fsyncdata >> and switching from storing configuration in thousands of small files to >> everything in one sqlite database or similar single file solution 2) you >> bet applications that are data sensitive better be properly written and >> making proper and efficient use of system calls such as fsync, fsyncdata >> and whatever else there is and 3) write barriers were introduced to >> ensure that fsync/fsyncdata do not lie unlike the previous behaviour >> where they return before data is safely written to media. In the case of >> email, you bet the entire toolchain better do fsync. postmark from >> Netapp as a benchmark for mail delivery was completely laughable because >> it does not use a single fsync call whereas all mta credible software >> (sendmail, postfix, qmail, exim) use fsync/fsyncdata where needed. >> Unless you want thousands of zero'd files in say the mail queue, you >> better make sure that both the app and the filesystem do what they are >> supposed to do. Which is use fsync/fsyncdata and filesystem must support >> write barriers if disk write caches are to be left on or disable disk >> write caches and take big performance hit. >> >> If a filesystem does not support write barriers (like JFS) you bet it is >> a concern to take note of with regard to your hardware (eg: do you have >> hardware raid with sufficient BBU cache?). Then there is the case of >> running on top of LVM which I suspect does not have write barrier >> support backported to RHEL/Centos 5.5. >> >> >>> >>> It was only a side-effect of ext3's journal=ordered that caused it to flush >>> dirty pages every 5 seconds. If that's what you want then you can use >>> sysctl to tune vm to flush every 5 seconds and that will cover all delayed >>> write file systems. >>> >> >> More precisely, the journal is committed every 5 seconds no matter what >> the mode. >> >> I'd stick with ext3 + data=journal with the journal either on some uber >> fast and large external BBU nvram block device (you can get up to 1TB >> with speeds of 750MiB/sec+ if you have a fat enough bus) or on hardware >> raid with sufficient BBU cache for an email server. Or anything with >> barrier support through the entire chain (read: no LVM). > > I believe barrier support is being deprecated in current kernels. Don't > remember what they are replacing them with, straight FUA maybe. Barriers > never performed well enough. > > If you have BBU write cache there is no need to worry about barriers. Barrier deprecation link: http://www.linux-archive.org/device-mapper-development/412783-block-deprecate-barrier-replace-blk_queue_ordered-blk_queue_flush.html -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] IT8218 PCI IDE RAID CARD
On Thu, 23 Dec 2010, Keith Roberts wrote: > To: CentOS mailing list > From: Keith Roberts > Subject: [CentOS] IT8218 PCI IDE RAID CARD > > I have big problems with this card not working on Centos 5.5 > > If I run Parted Magic (kernel 2.6.32.11) from CD, then the > IT8212F IDE PCI controller is detected OK, and I can access > the WD hard drive on the controller, in r/w mode. > > Running Centos 5.5 I get lots of I/O errors at boot time, > and cannot get r/w access to the drive from GParted. It seems that to get this card to work as a plain non-RAID controller under Centos 5.5, one has to do an overwrite of the PCI controller card's BIOS. It either works in RAID mode, or ATAPI controller mode as a mass storage controller. There one BIOS upgrade for programming it as a RAID controller, and another BIOS upgrade to program the PCI card as an ordinary IDE controller. Well I have flashed the BIOS on the ITE8212F PCI controller card with the ATAPI upgrade, and now it appears to the Centos 5.5 kernel as a plain PCI IDE controller - 100% native. This is just what I needed, as I would like to move all disk I/O intensive stuff onto a small 40GB drive on this controller. So the kernel needs to see this drive at boot time, before the kernel has a chance to load any dynamic drivers. Kind Regards and a very Happy Christmas to all, Keith Roberts -- In theory, theory and practice are the same; in practice they are not. This email was sent from my laptop with Centos 5.5 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Dec 23, 2010, at 11:21 AM, Christopher Chan wrote: > On Thursday, December 23, 2010 11:08 PM, Ross Walker wrote: >> On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: >> >>> Matt wrote: Is ext4 stable on CentOS 5.5 64bit? I have an email server with a great deal of disk i/o and was wandering if ext4 would be better then ext3 for it? >>> >>> Before committing to ext4 on a production server, it >>> would be good to consider the comments made in >>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 >>> which presumably still apply to current CentOS 5.5 64-bit kernels. >>> As I read it, Ts'o argues that the apparent loss of stability >>> compared to ext3 is a design issue in the realm of applications >>> that run atop it. I hope this is not a misreading. >> >> Waiting for applications to be properly written, ie use fsync(), is no way >> to pick a file system. You'd have the same problems on xfs or any other file >> system that does delayed writes. > > Whoa, whoa. 1) Theodore was not pushing fsync, he was pushing fsyncdata > and switching from storing configuration in thousands of small files to > everything in one sqlite database or similar single file solution 2) you > bet applications that are data sensitive better be properly written and > making proper and efficient use of system calls such as fsync, fsyncdata > and whatever else there is and 3) write barriers were introduced to > ensure that fsync/fsyncdata do not lie unlike the previous behaviour > where they return before data is safely written to media. In the case of > email, you bet the entire toolchain better do fsync. postmark from > Netapp as a benchmark for mail delivery was completely laughable because > it does not use a single fsync call whereas all mta credible software > (sendmail, postfix, qmail, exim) use fsync/fsyncdata where needed. > Unless you want thousands of zero'd files in say the mail queue, you > better make sure that both the app and the filesystem do what they are > supposed to do. Which is use fsync/fsyncdata and filesystem must support > write barriers if disk write caches are to be left on or disable disk > write caches and take big performance hit. > > If a filesystem does not support write barriers (like JFS) you bet it is > a concern to take note of with regard to your hardware (eg: do you have > hardware raid with sufficient BBU cache?). Then there is the case of > running on top of LVM which I suspect does not have write barrier > support backported to RHEL/Centos 5.5. > > >> >> It was only a side-effect of ext3's journal=ordered that caused it to flush >> dirty pages every 5 seconds. If that's what you want then you can use sysctl >> to tune vm to flush every 5 seconds and that will cover all delayed write >> file systems. >> > > More precisely, the journal is committed every 5 seconds no matter what > the mode. > > I'd stick with ext3 + data=journal with the journal either on some uber > fast and large external BBU nvram block device (you can get up to 1TB > with speeds of 750MiB/sec+ if you have a fat enough bus) or on hardware > raid with sufficient BBU cache for an email server. Or anything with > barrier support through the entire chain (read: no LVM). I believe barrier support is being deprecated in current kernels. Don't remember what they are replacing them with, straight FUA maybe. Barriers never performed well enough. If you have BBU write cache there is no need to worry about barriers. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] two cents or not two cents
On 12/23/2010 2:23 PM, Sean wrote: > >> Java stuff seems to be more self-contained so there is a little more >> freedom to mix component versions between applications and you aren't >> completely tied to someone else's update schedule. >> > Yes, superior exploitation must be granted Java (over say Cpan, > C-libraries etc) in scenarios that are naturally exploitation-heavy, > such as you indicate. But for everything? Hmmm. > A long ago tale goes thus: There was once a problem I would have > attacked with half a page of Prolog had I known I would end up writing > all the code myself, no matter how hard to actually get it right. I > conceded to Java for the sake of team effort and wrote my portion as far > as I could, but was unable to test properly without the other 3 portions > which, as it turned out, never eventuated. Towards the death knell I > stayed up and wrote them myself, chapter after chapter .. on .. and on > .. and on. It ran, but no surprise it produced incorrect results, and > too much code to go back through and try fix all that spaghetti logic in > the time available. A lesson learnt, and I haven't written a line of > Java since! I see two different ways this applies. One is that large applications typically assemble their own collections of jars instead of expecting them in the system classpath so they don't affect each others' updates (like using static libs for everything). The other is that java developers seem to buy into writing unit tests and doing full regression testing before releases more than anyone else (my impression anyway...). Maybe it is because development is so cumbersome already that adding testing overhead doesn't make that much difference - or they've had to automate it with something like Hudson. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] two cents or not two cents
Les Mikesell wrote: > On > 12/21/2010 1:06 PM, Sean wrote: >> >>>If you can treat something as a black box and trust it, the size of >>> the component isn't that important. >> "If" or "IFF" ..(IF AND ONLY IF)..? A deep scepticism forces me to >> treat all boxes as grey no matter how long since last visited... >> (including my own, which are a sort of dark grey!?). > > Yes, especially my own. That's the value of using components that are > maintained by others and widely used. The code gets much better QA > than I could ever do myself and all you have to do is peek at the mail > list once in a while to know if previously-working interfaces are > going to be broken if you update. For things from the base CentOS > package repositories and to a slightly lesser extent EPEL, you can > assume someone else has already made sure that the updates aren't > behavior-changing and required dependencies are met. > > Java stuff seems to be more self-contained so there is a little more > freedom to mix component versions between applications and you aren't > completely tied to someone else's update schedule. > Yes, superior exploitation must be granted Java (over say Cpan, C-libraries etc) in scenarios that are naturally exploitation-heavy, such as you indicate. But for everything? Hmmm. A long ago tale goes thus: There was once a problem I would have attacked with half a page of Prolog had I known I would end up writing all the code myself, no matter how hard to actually get it right. I conceded to Java for the sake of team effort and wrote my portion as far as I could, but was unable to test properly without the other 3 portions which, as it turned out, never eventuated. Towards the death knell I stayed up and wrote them myself, chapter after chapter .. on .. and on .. and on. It ran, but no surprise it produced incorrect results, and too much code to go back through and try fix all that spaghetti logic in the time available. A lesson learnt, and I haven't written a line of Java since! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] tomcat errors starting after upgrade from cent5.3 to 5.5 (/rebuild-jar-repository: error: Could not find)
We just upgraded Cent from 5.3 to 5.5 on a bunch of servers with little to no issues (kudos to you guys) except on a few servers where it appears we are having a problem w/ the Tomcat upgrade. Previously our application server was working fine under 5.3 with Tomcat/Java installed as such: java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5 java-1.6.0-openjdk-devel-1.6.0.0-0.30.b09.el5 java-sun-jdbc-stdext-2.0.1-1mamba java-sun-jdbc-stdext-javadoc-2.0.1-1mamba tomcat5-5.5.23-0jpp.7.el5_2.1 tomcat5-common-lib-5.5.23-0jpp.7.el5_2.1 tomcat5-jasper-5.5.23-0jpp.7.el5_2.1 tomcat5-jsp-2.0-api-5.5.23-0jpp.7.el5_2.1 tomcat5-server-lib-5.5.23-0jpp.7.el5_2.1 tomcat5-servlet-2.4-api-5.5.23-0jpp.7.el5_2.1 Now that we've run the full update, we have this installed: java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 java-1.6.0-openjdk-1.6.0.0-1.16.b17.el5 java-1.6.0-openjdk-devel-1.6.0.0-1.16.b17.el5 java-sun-jdbc-stdext-2.0.1-1mamba java-sun-jdbc-stdext-javadoc-2.0.1-1mamba tomcat5-5.5.23-0jpp.11.el5_5 tomcat5-common-lib-5.5.23-0jpp.11.el5_5 tomcat5-jasper-5.5.23-0jpp.11.el5_5 tomcat5-jsp-2.0-api-5.5.23-0jpp.11.el5_5 tomcat5-server-lib-5.5.23-0jpp.11.el5_5 tomcat5-servlet-2.4-api-5.5.23-0jpp.11.el5_5 tzdata-java-2010l-1.el5 I don't see any significant changes. All of the configs appear to be the same. Yet now on our application startup, we see the following: Starting tomcat5: /usr/bin/rebuild-jar-repository: error: Could not find jdbc-stdext Java extension for this JVM /usr/bin/rebuild-jar-repository: error: Could not find jndi Java extension for this JVM /usr/bin/rebuild-jar-repository: error: Some detected jars were not found for this jvm /usr/bin/rebuild-jar-repository: error: Could not find jaas Java extension for this JVM /usr/bin/rebuild-jar-repository: error: Some detected jars were not found for this jvm what could have changed to have caused these issues? Having trouble hunting this down. Any help that could be provided would be sincerely appreciated. Thanks, Frank ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The case of the missing mail
On Thu, Dec 23, 2010 at 9:22 AM, Anne Wilson wrote: > On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote: >> LASTFOLDER is informational, procmail sets it immediately before >> delivering to that folder; if you see LASTFOLDER in your logs, the >> only way the message should fail to arrive in that folder is in the >> event of an error writing to that folder. >> > They do arrive there - it just defines it as /var/mail/anne, which is useless > on my IMAP server. Sure, but the point is that assigning to LASTFOLDER yourself is meaningless. Procmail will fall back on the folder named in $ORGMAIL in the event that it is unable to deliver to $DEFAULT, for example because of a locking issue. It's quite likely that this assignment to LASTFOLDER is coming from ORGMAIL. > In fact I misquoted when I first wrote. The line I gave is correct, but it > should have been followed by > DEFAULT=$MAILDIR/new/ I'm pretty sure that's wrong. From the procmailrc manual: If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliver the message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new". So you should not have the "new/" on the end of the DEFAULT value unless you want a folder that is *named* "new" (and thus file paths ending in new/new/ and new/cur/ etc.) > In fact my logs show no mail going to /var/mail/anne today, so I will have to > watch and wait. I repeat, I'm using a procmailrc that has worked perfectly > for years. Unfortunately that it "worked" doesn't always mean that it is correct, it just means you haven't hit the corner cases before. >> If you haven't already, you really should add >> >> LOGABSTRACT=all >> VERBOSE=yes >> > When I first set this up it was with a printed set of documentation. I do > have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has > something changed in the meantime? Again from the manual pages: LOGABSTRACT Just before procmail exits it logs an abstract of the delivered message in $LOGFILE showing the `From ' and `Subject:' fields of the header, what folder it finally went to and how long (in bytes) the message was. By setting this variable to `no', generation of this abstract is sup- pressed. If you set it to `all', procmail will log an abstract for every successful delivering recipe it pro- cesses. So "all" includes some cases that "yes" does not, particularly copies made with the "c" flag on recipes. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] changing background image
I'm running centos 5.5 - 64 on Nvidia hardware. I am getting video from totem mixed in with my background image when I stop totem. If I change the background back to the default it does not seem to happen. However, as soon as I change the background to something else like ladybug.jpg and run totem fullscreen, then ask totem to quit with "totem --quit" the last video image is mixed in with my background. I did the standard (I think) way to change the background image: /usr/bin/gconftool-2 -t string --set /desktop/gnome/background/picture_filename "/usr/share/backgrounds/images/ladybug.jpg" su silentm -c "/usr/bin/gconftool-2 -t string --set /desktop/gnome/background/picture_filename '/usr/share/backgrounds/images/ladybug.jpg'" Is there something else I might be missing so the "still" of the video is not mixed in with my background? Thanks, Jerry ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] IT8218 PCI IDE RAID CARD
I have big problems with this card not working on Centos 5.5 If I run Parted Magic (kernel 2.6.32.11) from CD, then the IT8212F IDE PCI controller is detected OK, and I can access the WD hard drive on the controller, in r/w mode. Running Centos 5.5 I get lots of I/O errors at boot time, and cannot get r/w access to the drive from GParted. Any ideas what's happening, and why Centos 5.5 cannot get access to the IDE drive on the IT8212F controller card? Kind Regards, Keith Roberts -- In theory, theory and practice are the same; in practice they are not. This email was sent from my laptop with Centos 5.5 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The case of the missing mail
On Thursday 23 December 2010 16:53:22 Bart Schaefer wrote: > On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson wrote: > > All the recipes work perfectly - it's just those that fall off the end. > > For some reason it overrides the DEFAULT setting in procmailrc. > > I'm seeing messages from you about this on the procmail list as well > so pardon me if I've got my threads confused, but did you indicate > this has been happening some of the time for several days before you > noticed it? From the dates of messages I found in /var/mail/anne, it began on the day I left for a short vacation. Consequently it was 5 or 6 days before I noticed. Few message fail the procmail recipes, normally, so I don't expect to see many there. > Have you determined that it's consistent for any message > that "falls off the end" or is it intermittent? > I found that yesterday morning at 6 am messages were being delivered correctly, including a couple that "fell off the end". Suddenly though, things changed. In the logs I saw messages about by-passing a lock file. I'm wondering if some of the longer html messages are causing locks to be set that don't expire in time for the next message. I do remember in the past using the setting for No Lock (and yes, I read the warning), but can't remember where I found that. I'll think more about that. > If its consistent and there's a reasonably well-defined time that it > started happening, you should be looking for changes to the system > such as an automatically-applied update that occurred shortly before > the symptoms began. However ... > > Earlier in this thread you said MAILDIR=/home/anne/Maildir/ ... but > MAILDIR is procmail's equivalent of the shell's PWD, it has nothing to > do with delivery except as the path prefix if you use a relative path > name in a delivering recipe. Assigning to MAILDIR is just a "cd". > > Have you tried DEFAULT=/home/anne/Maildir/ ? > No, I haven't touch the settings, because they have worked well for several years. > > This is a recent > > development, and in the log I see LASTFOLDER - is it possible that > > DEFAULT is no longer read and I need to define LASTFOLDER? > > LASTFOLDER is informational, procmail sets it immediately before > delivering to that folder; if you see LASTFOLDER in your logs, the > only way the message should fail to arrive in that folder is in the > event of an error writing to that folder. > They do arrive there - it just defines it as /var/mail/anne, which is useless on my IMAP server. > I don't recall whether setting DEFAULT to a pipe (e.g., to > delivermail) is supposed to work, but I wouldn't rely upon it. In > some simple tests I tried, the pipe was never opened and the mail was > passed through to standard output. Setting DEFAULT to a file or > directory worked. > In fact I misquoted when I first wrote. The line I gave is correct, but it should have been followed by DEFAULT=$MAILDIR/new/ In fact my logs show no mail going to /var/mail/anne today, so I will have to watch and wait. I repeat, I'm using a procmailrc that has worked perfectly for years. > If you haven't already, you really should add > > LOGABSTRACT=all > VERBOSE=yes > When I first set this up it was with a printed set of documentation. I do have VERBOSE=YES, but I have LOGABSTRACT=YES. Are these equivalents or has something changed in the meantime? Not that I'm worried about that - I repeat, everything has been fine up to now. > to your procmailrc until you have resolved the problem. This isn't a > guarantee that you'll be able to track it down but it'll help > eliminate a lot of possibilities. I've not had a single message to my Inbox today, but nor have any ended in the Local mail account, so I'll just have to wait to see whether the problem recurs. Anne -- KDE Community Working Group New to KDE Software? - get help from http://userbase.kde.org signature.asc Description: This is a digitally signed message part. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On 12/23/2010 10:28 AM, Christopher Chan wrote: > Matt wrote: > Is ext4 stable on CentOS 5.5 64bit? I have an email server with a > great deal of disk i/o and was wandering if ext4 would be better then > ext3 for it? Before committing to ext4 on a production server, it would be good to consider the comments made in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 which presumably still apply to current CentOS 5.5 64-bit kernels. As I read it, Ts'o argues that the apparent loss of stability compared to ext3 is a design issue in the realm of applications that run atop it. I hope this is not a misreading. >>> >>> Waiting for applications to be properly written, ie use fsync(), is no way >>> to pick a file system. You'd have the same problems on xfs or any other >>> file system that does delayed writes. >> >> But note that the reason applications don't use fsync() when they should >> is probably due to linux historically not implementing it in a >> reasonable way (i.e. it would flush the entire filesystem buffer and >> wait for completion instead of just the requested file's outstanding >> blocks). Not sure when/if that was fixed - but it is also probably >> behind the old impressions that mysql is faster than postgresql. >> > > Can we drop the fsync nonsense? No, if you don't remember history you are doomed to repeat it. > Apps that are data sensitive should be > using fsync/fsyncdata (fsync is a posix specification so the history of > how linux implemented fsync has nothing to do with whether applications > used it or not) otherwise it should not be even consider for the task. > The lying fsync/fsyncdata was fixed when write barrier support was > introduced and filesystems updated to use write barriers. As for the > flush entire buffer...IIRC, that is specific to ext3 and even that > should be now gone with the update to write barrier support. It's one of those 'have you stopped beating your wife things'. Apps that correctly used fsync were slow because of the OS implementation, so people used other apps. So now you have popular apps that do things wrong. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The case of the missing mail
On Thu, Dec 23, 2010 at 3:03 AM, Anne Wilson wrote: > > All the recipes work perfectly - it's just those that fall off the end. For > some reason it overrides the DEFAULT setting in procmailrc. I'm seeing messages from you about this on the procmail list as well so pardon me if I've got my threads confused, but did you indicate this has been happening some of the time for several days before you noticed it? Have you determined that it's consistent for any message that "falls off the end" or is it intermittent? If its consistent and there's a reasonably well-defined time that it started happening, you should be looking for changes to the system such as an automatically-applied update that occurred shortly before the symptoms began. However ... Earlier in this thread you said MAILDIR=/home/anne/Maildir/ ... but MAILDIR is procmail's equivalent of the shell's PWD, it has nothing to do with delivery except as the path prefix if you use a relative path name in a delivering recipe. Assigning to MAILDIR is just a "cd". Have you tried DEFAULT=/home/anne/Maildir/ ? > This is a recent > development, and in the log I see LASTFOLDER - is it possible that DEFAULT > is no longer read and I need to define LASTFOLDER? LASTFOLDER is informational, procmail sets it immediately before delivering to that folder; if you see LASTFOLDER in your logs, the only way the message should fail to arrive in that folder is in the event of an error writing to that folder. I don't recall whether setting DEFAULT to a pipe (e.g., to delivermail) is supposed to work, but I wouldn't rely upon it. In some simple tests I tried, the pipe was never opened and the mail was passed through to standard output. Setting DEFAULT to a file or directory worked. If you haven't already, you really should add LOGABSTRACT=all VERBOSE=yes to your procmailrc until you have resolved the problem. This isn't a guarantee that you'll be able to track it down but it'll help eliminate a lot of possibilities. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Moving from Fedora -- Advice??
On Wed, 22 Dec 2010, Paul Johnson wrote: On Fri, Dec 17, 2010 at 11:04 AM, Beartooth wrote: She's far more likely to outlive me than I her; so I want to install something requiring a lot less maintenance on her machine, so that she'll have it and be used to it, years ahead of need. I'm thinking CentOS 6, whenever it's ready, is probably my best choice. Any thoughts? (And yes, I do mean what my .sig says.) Hello, Beartooth. I have given this a lot of thought over the last few months. You certainly can't leave her on Fedora. That turns over too fast. On a server or in a public lab, I run Centos or RHEL. This is a Centos list, and I don't want to inspire a big distro flame war, but here's an opinion. If you are serious that you may die and leave your wife with an OS she can't manage, you might think about installing the LTS version of Ubuntu. The Ubuntu email list folks are more helpful to non-experts. The distro team is more energetic about making device drivers work, even if you happen to own the "wrong" hardware (proprietary drivers for Nvidia video, MP3 encoding, etc). They are somewhat like Macintosh in attitude. "If we can't package it up for you to click on, it is not worth doing." That's not the way experts need it, but for somebody who is just using the system, it may be about right. On the other hand, if I have a really serious problem, something wrong in the kernel, I'd much rather seek help in the Fedora list. There are more true experts floating about in there. I suppose that once you install the OS, the trouble due to automatic updates from either Ubuntu LTS or Centos/RedHat will be about the same. The trouble will come when she either has to get a new computer or make a major distribution update, eg from Centos 5.5 to Centos 6.0. If she needs to find Linux help, my *guess* is that she will be more likely to find a teenager who has used Ubuntu than the others. She'd have the same trouble with Windows, the only difference there is that it is easier to find/hire geeks to help on a Windows system. From my point of view, that's tremendously good advice. I too suspect that *among desktop/laptop users* she's more likely to find Ubuntu assistance than RHEL/CentOS/Fedora assistance. It's not a certainty by any means, but I agree it's likely. My only bit of unsolicited advice would be to set up a fairly robust backup system (using, perhaps, a USB hard drive) and train her on it until she's got the procedure in muscle memory. Should the hard drive fail, someone will at least be able to restore her data. -- Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Friday, December 24, 2010 12:02 AM, Les Mikesell wrote: > On 12/23/2010 9:08 AM, Ross Walker wrote: >> On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: >> >>> Matt wrote: Is ext4 stable on CentOS 5.5 64bit? I have an email server with a great deal of disk i/o and was wandering if ext4 would be better then ext3 for it? >>> >>> Before committing to ext4 on a production server, it >>> would be good to consider the comments made in >>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 >>> which presumably still apply to current CentOS 5.5 64-bit kernels. >>> As I read it, Ts'o argues that the apparent loss of stability >>> compared to ext3 is a design issue in the realm of applications >>> that run atop it. I hope this is not a misreading. >> >> Waiting for applications to be properly written, ie use fsync(), is no way >> to pick a file system. You'd have the same problems on xfs or any other file >> system that does delayed writes. > > But note that the reason applications don't use fsync() when they should > is probably due to linux historically not implementing it in a > reasonable way (i.e. it would flush the entire filesystem buffer and > wait for completion instead of just the requested file's outstanding > blocks). Not sure when/if that was fixed - but it is also probably > behind the old impressions that mysql is faster than postgresql. > Can we drop the fsync nonsense? Apps that are data sensitive should be using fsync/fsyncdata (fsync is a posix specification so the history of how linux implemented fsync has nothing to do with whether applications used it or not) otherwise it should not be even consider for the task. The lying fsync/fsyncdata was fixed when write barrier support was introduced and filesystems updated to use write barriers. As for the flush entire buffer...IIRC, that is specific to ext3 and even that should be now gone with the update to write barrier support. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Intel NIC
On 12/23/2010 10:02 AM, Alexander Dalloz wrote: > >> The ESX/ESXi host is limited to a maximum of 32 logical (sockets x >> cores x hyperthreading) CPUs. The free license only allows access >> through the vSphere client and all other features such as >> vMotion/vStorage/HA are disabled. Otherwise the host's hardware limits >> are the same. > > All the nifty VMware features are technically bound to the existance and > functioning of a vCenter Server. It's all controlled by it and without one > (reboot, failure, whatever) the VMs will go on running but no vMotion, HA > or DRS will work. This is the case for whatever vSphere product and > feature set you choose. Of course, beyond the 60 days trial period the > vCenter Server must be licensed as well the required number of physical > CPUs. > > The named vSphere Essentials license does not cover vMotion and HA, not to > speak about Storage vMotion. Neccessary to choose at least vSphere > Essentials Plus. > > To put this back in the context of comparison to other free virtual host servers, you can run the console client (windows app) to connect to as many ESXi servers as you want, but on a one to one basis. That is, open a new instance of the client for each connection, and within those you can open consoles to as many VM guests as you want (although once the network is up I usually prefer to use vnc or NX/freenx directly to the guest). The licensed vCenter stuff refers to a single app that is simultaneously aware of all of your ESXi servers and their guests and can move/fail resources across servers - concepts that I don't think the other hypervisors even have. I don't think there is an overall restriction on how many of the free ESXi servers you install - you just have to treat them as standalone instances. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Thursday, December 23, 2010 11:08 PM, Ross Walker wrote: > On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: > >> Matt wrote: >>> Is ext4 stable on CentOS 5.5 64bit? I have an email server with a >>> great deal of disk i/o and was wandering if ext4 would be better then >>> ext3 for it? >> >> Before committing to ext4 on a production server, it >> would be good to consider the comments made in >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 >> which presumably still apply to current CentOS 5.5 64-bit kernels. >> As I read it, Ts'o argues that the apparent loss of stability >> compared to ext3 is a design issue in the realm of applications >> that run atop it. I hope this is not a misreading. > > Waiting for applications to be properly written, ie use fsync(), is no way to > pick a file system. You'd have the same problems on xfs or any other file > system that does delayed writes. Whoa, whoa. 1) Theodore was not pushing fsync, he was pushing fsyncdata and switching from storing configuration in thousands of small files to everything in one sqlite database or similar single file solution 2) you bet applications that are data sensitive better be properly written and making proper and efficient use of system calls such as fsync, fsyncdata and whatever else there is and 3) write barriers were introduced to ensure that fsync/fsyncdata do not lie unlike the previous behaviour where they return before data is safely written to media. In the case of email, you bet the entire toolchain better do fsync. postmark from Netapp as a benchmark for mail delivery was completely laughable because it does not use a single fsync call whereas all mta credible software (sendmail, postfix, qmail, exim) use fsync/fsyncdata where needed. Unless you want thousands of zero'd files in say the mail queue, you better make sure that both the app and the filesystem do what they are supposed to do. Which is use fsync/fsyncdata and filesystem must support write barriers if disk write caches are to be left on or disable disk write caches and take big performance hit. If a filesystem does not support write barriers (like JFS) you bet it is a concern to take note of with regard to your hardware (eg: do you have hardware raid with sufficient BBU cache?). Then there is the case of running on top of LVM which I suspect does not have write barrier support backported to RHEL/Centos 5.5. > > It was only a side-effect of ext3's journal=ordered that caused it to flush > dirty pages every 5 seconds. If that's what you want then you can use sysctl > to tune vm to flush every 5 seconds and that will cover all delayed write > file systems. > More precisely, the journal is committed every 5 seconds no matter what the mode. I'd stick with ext3 + data=journal with the journal either on some uber fast and large external BBU nvram block device (you can get up to 1TB with speeds of 750MiB/sec+ if you have a fat enough bus) or on hardware raid with sufficient BBU cache for an email server. Or anything with barrier support through the entire chain (read: no LVM). ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sendmail / logwatch relaying issue - driving me crazy
> -Original Message- > From: centos-boun...@centos.org > [mailto:centos-boun...@centos.org] On Behalf Of Les Mikesell > Sent: Thursday, December 23, 2010 10:57 > To: centos@centos.org > Subject: Re: [CentOS] sendmail / logwatch relaying issue - > driving me crazy > > On 12/23/2010 8:01 AM, Jason Pyeron wrote: > > >> > >> On 12/23/10 3:44 AM, Götz Reinicke - IT-Koordinator wrote: > >>> Hallo, *<:-) > >>> > >>> may be I'm to tired to see the solution, maybe someone can > >> give me a hint? > >>> > >>> I do have a couple of servers, sending the daily logwatch > >> report to a > >>> central support email account. > >>> > >>> Some servers do have DNS A and CNAME records. On my mailserver > >>> relaying for the servers is allowed. > >>> > >>> Only one server drives me crazy, getting user unknown or > releaying > >>> denied messages. > >>> > >>> Any idea, how to debug this issue? I'd be glad to fix this as a > >>> christmas gift. I could provide logmessages of course. > >>> > >> > >> If there is an MX record for the target address, it will go there > >> instead of to > >> the A record for that name. The receiving server will > >> usually try to resolve > >> the From: host address and reject if it can't, so the sender must > >> have a valid hostname in your DNS (or turn off that > feature). If the > >> receiving server doesn't accept for the target domain/host address > >> you'd get the relaying denyed error. If it does accept for the > >> domain but does not have the user in the address you'd get > the user > >> unknown error. > >> > > > > In your /etc/mail/sendmail.mc: > > > > dnl # Uncomment and edit the following line if your outgoing mail > > needs to dnl # be sent out through an external mail server: > > dnl # > > define(`SMART_HOST',`mail.pdinc.us')dnl > > > > * the mail.pdinc.us resolves to a different ip inside as > compared to > > the public dns entry > > > > Each box in your network should send the mail to a central > smtp server > > which allows relaying from your network. We have 2-5 new virtual > > machines every day, they usually dont last more than a few > days. If > > we had to admin that centrally either by dns or mail server > config we > > would go bonkers. This way every new machine is responsible > for its self. > > This is good advice and will let you relay to outside > addresses as well, but not necessary if all of your mail is > internal. If you have an MX or A record in your DNS for the The first time you try to send non-local mail the house of cards will fall apart unless you centrally admin the mail. > destination address the sender will find it directly, and if In this situation, only one machine needs to make correct decisions. On that machine here we have a list of domains which get delivered locally and all others are tried to be delivered by DNS lookups, etc. > the recipient is a local user or alias at that machine it > isn't considered a relay. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On 12/23/2010 9:08 AM, Ross Walker wrote: > On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: > >> Matt wrote: >>> Is ext4 stable on CentOS 5.5 64bit? I have an email server with a >>> great deal of disk i/o and was wandering if ext4 would be better then >>> ext3 for it? >> >> Before committing to ext4 on a production server, it >> would be good to consider the comments made in >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 >> which presumably still apply to current CentOS 5.5 64-bit kernels. >> As I read it, Ts'o argues that the apparent loss of stability >> compared to ext3 is a design issue in the realm of applications >> that run atop it. I hope this is not a misreading. > > Waiting for applications to be properly written, ie use fsync(), is no way to > pick a file system. You'd have the same problems on xfs or any other file > system that does delayed writes. But note that the reason applications don't use fsync() when they should is probably due to linux historically not implementing it in a reasonable way (i.e. it would flush the entire filesystem buffer and wait for completion instead of just the requested file's outstanding blocks). Not sure when/if that was fixed - but it is also probably behind the old impressions that mysql is faster than postgresql. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Intel NIC
>>> I can confirm the socket/cpu limitation is at least 8, at least on >>> ESXi 3.x. I have an 8 core IBM x445 running on a free license. :-) >> >> The free and essentials licensing is restricted to max 2 sockets, max 6 >> cores a socket. > > The vSphere Essentials license is limited to 3 servers of 2 sockets w/ > 6core CPU's each. I have two sites right now running on licensed > editions. Correct. > The ESX/ESXi host is limited to a maximum of 32 logical (sockets x > cores x hyperthreading) CPUs. The free license only allows access > through the vSphere client and all other features such as > vMotion/vStorage/HA are disabled. Otherwise the host's hardware limits > are the same. All the nifty VMware features are technically bound to the existance and functioning of a vCenter Server. It's all controlled by it and without one (reboot, failure, whatever) the VMs will go on running but no vMotion, HA or DRS will work. This is the case for whatever vSphere product and feature set you choose. Of course, beyond the 60 days trial period the vCenter Server must be licensed as well the required number of physical CPUs. The named vSphere Essentials license does not cover vMotion and HA, not to speak about Storage vMotion. Neccessary to choose at least vSphere Essentials Plus. > Drew Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sendmail / logwatch relaying issue - driving me crazy
On 12/23/2010 8:01 AM, Jason Pyeron wrote: >> >> On 12/23/10 3:44 AM, Götz Reinicke - IT-Koordinator wrote: >>> Hallo, *<:-) >>> >>> may be I'm to tired to see the solution, maybe someone can >> give me a hint? >>> >>> I do have a couple of servers, sending the daily logwatch >> report to a >>> central support email account. >>> >>> Some servers do have DNS A and CNAME records. On my mailserver >>> relaying for the servers is allowed. >>> >>> Only one server drives me crazy, getting user unknown or releaying >>> denied messages. >>> >>> Any idea, how to debug this issue? I'd be glad to fix this as a >>> christmas gift. I could provide logmessages of course. >>> >> >> If there is an MX record for the target address, it will go >> there instead of to >> the A record for that name. The receiving server will >> usually try to resolve >> the From: host address and reject if it can't, so the sender >> must have a valid hostname in your DNS (or turn off that >> feature). If the receiving server doesn't accept for the >> target domain/host address you'd get the relaying denyed >> error. If it does accept for the domain but does not have >> the user in the address you'd get the user unknown error. >> > > In your /etc/mail/sendmail.mc: > > dnl # Uncomment and edit the following line if your outgoing mail needs to > dnl # be sent out through an external mail server: > dnl # > define(`SMART_HOST',`mail.pdinc.us')dnl > > * the mail.pdinc.us resolves to a different ip inside as compared to the > public > dns entry > > Each box in your network should send the mail to a central smtp server which > allows relaying from your network. We have 2-5 new virtual machines every day, > they usually don’t last more than a few days. If we had to admin that > centrally > either by dns or mail server config we would go bonkers. This way every new > machine is responsible for its self. This is good advice and will let you relay to outside addresses as well, but not necessary if all of your mail is internal. If you have an MX or A record in your DNS for the destination address the sender will find it directly, and if the recipient is a local user or alias at that machine it isn't considered a relay. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Intel NIC
>> I can confirm the socket/cpu limitation is at least 8, at least on >> ESXi 3.x. I have an 8 core IBM x445 running on a free license. :-) > > The free and essentials licensing is restricted to max 2 sockets, max 6 cores > a socket. The vSphere Essentials license is limited to 3 servers of 2 sockets w/ 6core CPU's each. I have two sites right now running on licensed editions. The ESX/ESXi host is limited to a maximum of 32 logical (sockets x cores x hyperthreading) CPUs. The free license only allows access through the vSphere client and all other features such as vMotion/vStorage/HA are disabled. Otherwise the host's hardware limits are the same. -- Drew "Nothing in life is to be feared. It is only to be understood." --Marie Curie ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] do i need a dedicated ip address for https?
On Dec 23, 2010, at 3:03 AM, David Hrbáč wrote: > Dne 23.12.2010 1:08, Les Mikesell napsal(a): >> The issue is that the server needs to know the hostname given to the >> browser to find the matching certificate, and the only way to do that >> and stay on the standard port 443 with the apache version on centos is >> to bind each virtual host to a different IP address. Per the apache ssl >> faq at http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2, 2.2.12 >> or later supports SNI where the browser passes the hostname before the >> ssl session starts. >> > > Guys, > Of course that it's possible to host multi-site on ONE ip. As Les has > said, it's about SNI enabled web clients and servers. Not all clients > support SNI. As to Apache, there's no need to go with 2.2.12. SNI is > very easy to support with both Centos 4 and Centos 5. There's module > mod_gnutls packed for Centos in one of my repo. Used in production for a > few years now. > > http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/i386/repoview/ > http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/x86_64/repoview/ > http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/i386/repoview/ > http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/x86_64/repoview/ As long as the forward DNS resolves to the common name the cert will be accepted and you can have multiple host names resolve to the same IP. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ext4 on CentOS 5.5 64bit
On Dec 23, 2010, at 2:12 AM, cpol...@surewest.net wrote: > Matt wrote: >> Is ext4 stable on CentOS 5.5 64bit? I have an email server with a >> great deal of disk i/o and was wandering if ext4 would be better then >> ext3 for it? > > Before committing to ext4 on a production server, it > would be good to consider the comments made in > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 > which presumably still apply to current CentOS 5.5 64-bit kernels. > As I read it, Ts'o argues that the apparent loss of stability > compared to ext3 is a design issue in the realm of applications > that run atop it. I hope this is not a misreading. Waiting for applications to be properly written, ie use fsync(), is no way to pick a file system. You'd have the same problems on xfs or any other file system that does delayed writes. It was only a side-effect of ext3's journal=ordered that caused it to flush dirty pages every 5 seconds. If that's what you want then you can use sysctl to tune vm to flush every 5 seconds and that will cover all delayed write file systems. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sendmail / logwatch relaying issue - driving me crazy
> -Original Message- > From: centos-boun...@centos.org > [mailto:centos-boun...@centos.org] On Behalf Of Les Mikesell > Sent: Thursday, December 23, 2010 8:30 > To: centos@centos.org > Subject: Re: [CentOS] sendmail / logwatch relaying issue - > driving me crazy > > On 12/23/10 3:44 AM, Götz Reinicke - IT-Koordinator wrote: > > Hallo, *<:-) > > > > may be I'm to tired to see the solution, maybe someone can > give me a hint? > > > > I do have a couple of servers, sending the daily logwatch > report to a > > central support email account. > > > > Some servers do have DNS A and CNAME records. On my mailserver > > relaying for the servers is allowed. > > > > Only one server drives me crazy, getting user unknown or releaying > > denied messages. > > > > Any idea, how to debug this issue? I'd be glad to fix this as a > > christmas gift. I could provide logmessages of course. > > > > If there is an MX record for the target address, it will go > there instead of to > the A record for that name. The receiving server will > usually try to resolve > the From: host address and reject if it can't, so the sender > must have a valid hostname in your DNS (or turn off that > feature). If the receiving server doesn't accept for the > target domain/host address you'd get the relaying denyed > error. If it does accept for the domain but does not have > the user in the address you'd get the user unknown error. > In your /etc/mail/sendmail.mc: dnl # Uncomment and edit the following line if your outgoing mail needs to dnl # be sent out through an external mail server: dnl # define(`SMART_HOST',`mail.pdinc.us')dnl * the mail.pdinc.us resolves to a different ip inside as compared to the public dns entry Each box in your network should send the mail to a central smtp server which allows relaying from your network. We have 2-5 new virtual machines every day, they usually dont last more than a few days. If we had to admin that centrally either by dns or mail server config we would go bonkers. This way every new machine is responsible for its self. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sendmail / logwatch relaying issue - driving me crazy
On 12/23/10 3:44 AM, Götz Reinicke - IT-Koordinator wrote: > Hallo, *<:-) > > may be I'm to tired to see the solution, maybe someone can give me a hint? > > I do have a couple of servers, sending the daily logwatch report to a > central support email account. > > Some servers do have DNS A and CNAME records. On my mailserver relaying > for the servers is allowed. > > Only one server drives me crazy, getting user unknown or releaying > denied messages. > > Any idea, how to debug this issue? I'd be glad to fix this as a > christmas gift. I could provide logmessages of course. > If there is an MX record for the target address, it will go there instead of to the A record for that name. The receiving server will usually try to resolve the From: host address and reject if it can't, so the sender must have a valid hostname in your DNS (or turn off that feature). If the receiving server doesn't accept for the target domain/host address you'd get the relaying denyed error. If it does accept for the domain but does not have the user in the address you'd get the user unknown error. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The case of the missing mail
On Wednesday 22 December 2010 19:35:33 m.r...@5-cent.us wrote: > Anne Wilson wrote: > > On Wednesday 22 December 2010 16:51:02 Paul Heinlein wrote: > >> On Wed, 22 Dec 2010, Anne Wilson wrote: > >> > On Wednesday 22 December 2010 13:33:10 Anne Wilson wrote: > >> >> I became suspicious that I should have received a certain message, > >> >> and reading pm.log I discovered that it had indeed arrived and had > >> >> been allocated to /var/mail/anne, despite procmailrc telling it > >> >> that > >> >> > >> >> MAILDIR=/home/anne/Maildir/ > >> >> > >> >> Any idea what might have caused this? It seems to have been > >> >> working like this only in the last 24 hours or so. > > > > > There's nothing obvious, at first scan. Everything seems to be > > "Delivered to command /usr.bin/procmail" which of course is correct. > > The only > > messages > > > affected are thos which should be in my Inbox, having failed to match any > > recipe. > > Dumb question: um, is the ".", rather than "/", a typo, in > /usr.bin/procmail? > Never discount the possibilities :-) Yes, a typo - I'm on the laptop, close to the server. All the recipes work perfectly - it's just those that fall off the end. For some reason it overrides the DEFAULT setting in procmailrc. This is a recent development, and in the log I see LASTFOLDER - is it possible that DEFAULT is no longer read and I need to define LASTFOLDER? Anne -- KDE Community Working Group New to KDE Software? - get help from http://userbase.kde.org signature.asc Description: This is a digitally signed message part. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sendmail / logwatch relaying issue - driving me crazy
unedited error messages and sendmail config from both servers is needed. eero ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] sendmail / logwatch relaying issue - driving me crazy
Hallo, *<:-) may be I'm to tired to see the solution, maybe someone can give me a hint? I do have a couple of servers, sending the daily logwatch report to a central support email account. Some servers do have DNS A and CNAME records. On my mailserver relaying for the servers is allowed. Only one server drives me crazy, getting user unknown or releaying denied messages. Any idea, how to debug this issue? I'd be glad to fix this as a christmas gift. I could provide logmessages of course. Thanks and best regards Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt smime.p7s Description: S/MIME Cryptographic Signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I/O size distribution?
@ Charles Polisher yes, seems that avgrq-sz does provide the info I needed, thanks for pointing that out! @ Keith I am not sure if blktrace can monitor which files being written to disk or if it is the best tool for that. But you could check out the inotify-tools (iwatch and related) which go on that directions. An example usage is here http://openquery.com/blog/tool-day-inotify or iwatch http://iwatch.sourceforge.net/index.html cheers Antonello ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] do i need a dedicated ip address for https?
Dne 23.12.2010 1:08, Les Mikesell napsal(a): > The issue is that the server needs to know the hostname given to the > browser to find the matching certificate, and the only way to do that > and stay on the standard port 443 with the apache version on centos is > to bind each virtual host to a different IP address. Per the apache ssl > faq at http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2, 2.2.12 > or later supports SNI where the browser passes the hostname before the > ssl session starts. > Guys, Of course that it's possible to host multi-site on ONE ip. As Les has said, it's about SNI enabled web clients and servers. Not all clients support SNI. As to Apache, there's no need to go with 2.2.12. SNI is very easy to support with both Centos 4 and Centos 5. There's module mod_gnutls packed for Centos in one of my repo. Used in production for a few years now. http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/i386/repoview/ http://fs12.vsb.cz/hrb33/el5/hrb-tls/stable/x86_64/repoview/ http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/i386/repoview/ http://fs12.vsb.cz/hrb33/el4/hrb-tls/stable/x86_64/repoview/ Regards, David Hrbáč ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
