Re: [CentOS] Postfix setup

[Austin Einter]

Dear All
I am able to send receive mail properly with use of roundcube.

Thanks a lot for all your support.

The last thing I did was started dovecot service, then roundcuble was able
to work properly.

Next, I will look into security aspect, spam filtering etc etc. Will start
a new thread for that.

Many thanks for great tips to me.

Best Regards
Austin







On Mon, Mar 11, 2013 at 8:24 AM, Austin Einter wrote:

> Dear All
> I am planning to setup mail server for my domain.
>
> Which one is preferred postfix or sendmail.
>
>
> I came across a link *
> http://ostechnix.wordpress.com/2013/02/08/setup-mail-server-using-postfixdovecotsquirrelmail-in-centosrhelscientific-linux-6-3-step-by-step/
> * for postfix mail setup.
>
> It says,
> Prerequisites:
>
>- The mail server should contain a valid MX record in the DNS server.
>Navigate to this link how to setup DNS 
> server
>.
>- Firewall and SELinux should be disabled.
>
>
> I have disabled iptables as my m/c is behind the firewall.
>
> It says I need to disable firewall. Is it really required. Kindly let me
> know.
>
> Best Regards
> Austin
>
>
>
>
>
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix setup

[Austin Einter]

Dear All
I have got partial success with postfix setup. So far I am able to do

1. Access the postfix admin
2. Was able to login to postfix admin
3. Created one more admin account
4. From newly created admin account sent a mail to my gmail account, and I
received that mail.
5. I am able to add a domain
6. I was able to add a virtual mailbox

However many things are NOT working. Things that I have observed NOT
working are

1. Not able to login to mailbox through roundcube
In link https://www.example.com/webmail/ (after security exception
confirmation) , I entered the u...@example.com and password.
It says "*Connection to storage server failed.*".

Any idea why it happen?

I checked my /home/vmail path. I hope here there will be individual
folder/file for individual mailboxes (not sure though). Did not see any
file/folder as of now.

Kindly guide why it gives "*Connection to storage server failed.*".

Thanks
Austin











On Wed, Mar 13, 2013 at 6:54 AM, SilverTip257 wrote:

> On Tue, Mar 12, 2013 at 10:02 AM, James B. Byrne  >wrote:
>
> >
> > On Mon, March 11, 2013 16:56, Craig White wrote:
> >
> > >
> > > 
> > > develop good, consistent habits… postfix or whatever config files you
> > > edit, backup the distribution's version of the config file first
> > > before you ever edit…
> > >
> > > cp main.cf main.cf-dist
> > >
> >
> > Alternatively:
> >
> > yum install postfix
> > yum install git
> > cd /etc/posfix
> > git init
> > git add ./
> > git commit -m"Postfix config file initial commit"
> >
> > Now all the default config files are stored as hashed blobs in
> > /etc/postfix/.git and you can modify them in place.  Once you are
> >
>
> Nice.  git-r-done  ;)
>
> I've been rather content with using RCS (as opposed to other version
> control systems) on the individual boxes.
>
> Version control of some sort is a must.
> And backups ... multiple backups ...  :D
>
>
> > satisfied with your latest set of changes do this (always issue git
> > commands from the repository root, in this case /etc/postfix):
> >
> > git add ./  or  git add 
> > git commit -m"explanation of why the changes were made"
> >
> > If you screw up and need to get back what was there originally do this:
> >
> > git checkout 
> >
> > If you want to see what was different between this config and the
> > previous version do this:
> >
> > git diff 
> >
> > You can compare any previous version of any tracked file with any
> > other version of the same file by specifying the commit ids.
> >
> > git diff .. -- 
> >
> > Git also provides a blow by blow history of all changes applied to a
> > file and what logon id made them.
> >
> > git blame .. -- 
> >
> > See http://git-scm.com/ for details on what git is and how to use it.
> > I use git for version control of system config files on all my uptime
> > sensitive servers.  It makes getting back to a working config trivial
> > when things turn ugly following a change.
> >
> > --
> > ***  E-Mail is NOT a SECURE channel  ***
> > James B. Byrnemailto:byrn...@harte-lyne.ca
> > Harte & Lyne Limited  http://www.harte-lyne.ca
> > 9 Brockley Drive  vox: +1 905 561 1241
> > Hamilton, Ontario fax: +1 905 561 0757
> > Canada  L8E 3C3
> >
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
>
>
>
> --
> ---~~.~~---
> Mike
> //  SilverTip257  //
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT/HW] hardware raid -- comment/experience with 3Ware

[Keith Keller]

On 2013-03-12, SilverTip257  wrote:
>
> I've not had any MegaRAID controllers fail, so I can only say they've been
> reliable thus far!

I think that this is not a helpful comment for the OP.  He wants to
know, in the event the controller does fail, can he replace it with a
similar-but-possibly-not-identical controller and have it recognize the
original RAID containers.  Just because you have not seen any failures
so far does not mean the OP never will.

> You start by failing/removing the drive via mdadm.  Then hot remove the
> disk from the subsystem (ex: SCSI [0]) and finally physically remove it.
>  Then work in the opposite direction ... hot add (SCSI [1]), clone the
> partition layout from one drive to the new with sfdisk, and finally add the
> new disk/partitions to your softraid array with mdadm.
>
> You must hot remove the disk from the SCSI subsystem or the block device
> (ex: /dev/sdc) name is occupied and unavailable for the new disk you put in
> the system.  I've used the above procedure many times to repair softraid
> arrays while keeping systems online.

This is basically the same procedure for replacing a failed drive in a
hardware RAID array, except that there is no need to worry about drive
names (since individual drives don't get assigned a name in the kernel).
But the point is that replacing a failed drive is the same amount of
on-site work in either scenario, so that should not deter the OP from
choosing software RAID.  (There may be other factors, such as the
aforementioned write cache on many RAID cards.)

--keith


-- 
kkel...@wombat.san-francisco.ca.us


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what is "single spanned virtual disk" on RAID10????

[SilverTip257]

On Tue, Mar 12, 2013 at 7:37 PM, SilverTip257 wrote:

> On Tue, Mar 12, 2013 at 7:44 AM, mcclnx mcc  wrote:
>
>> We have DELL R910 with H800 adapter in it.  several MD1220 connect to
>> H800.
>>
>
> MD1220 = your Dell storage array?
>
>
>>
>> Since MD1220 have 24 hard disks in it.  When I configured RAID10, there
>> is a choice call 'single spanned virtual disk"  (22 disks).
>>
>> Can anyone tell me how "single spanned virtual disk" work?
>>
>
> Not to be a troll, but that's probably a question better suited for the
> Dell and/or PowerEdge list.
>


hehe - shows how closely I was looking at the recipients.

Date: Tue, 12 Mar 2013 19:44:55 +0800 (CST)
From: mcclnx mcc 
Subject: [Linux-PowerEdge] what is "single spanned virtual disk" on
RAID10
To: centos@centos.org
Cc: linux-powere...@lists.us.dell.com



>
>
>>
>> Any document relate to it?
>>
>
> http://www.dell.com/support/Manuals/us/en/19/product/powervault-md1220
>
>
>>
>> Thanks.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
>
>
> --
> ---~~.~~---
> Mike
> //  SilverTip257  //
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel panic after update to 6.4

[Emmett Culley]

On 03/12/2013 04:23 PM, lists-centos wrote:
> 
> 
>  Original Message 
>> Date: Tuesday, March 12, 2013 04:05:28 PM -0700
>> From: Emmett Culley 
>> To: centos@centos.org
>> Cc:
>> Subject: Re: [CentOS] Kernel panic after update to 6.4
>>
>> On 03/12/2013 01:48 PM, Akemi Yagi wrote:
>>> On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley
>>>  wrote:
 After successfully updating three CentOS 6.3 VM guests to 6.4 I
 decided to update the host as well.  And it failed to boot.

 Kernel panic - Not syncing: Attempted to kill init!
 Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
>>>
>>> At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is
>>> not out yet. Where did you get this one from ???  Did you build it
>>> yourself?
>>>
>>> Akemi
>>
>> I did yum update --enablerepo=epel.  I just checked and it appears
>> that kernel was from the updates repo:
>>
>> [~]# yum list kernel
>> Installed Packages
>> kernel.x86_64 2.6.32-279.9.1.el6   @updates
>> kernel.x86_64 2.6.32-279.14.1.el6  @updates
>> kernel.x86_64 2.6.32-279.19.1.el6  @updates
>> kernel.x86_64 2.6.32-279.22.1.el6  @updates
>> kernel.x86_64 2.6.32-358.0.1.el6   @updates
>>
>> [~]# rpm -qa |grep kernel
>> abrt-addon-kerneloops-2.0.8-15.el6.centos.x86_64
>> kernel-2.6.32-279.19.1.el6.x86_64
>> dracut-kernel-004-303.el6.noarch
>> kernel-devel-2.6.32-279.14.1.el6.x86_64
>> kernel-2.6.32-279.14.1.el6.x86_64
>> kernel-devel-2.6.32-279.22.1.el6.x86_64
>> kernel-headers-2.6.32-358.0.1.el6.x86_64
>> kernel-firmware-2.6.32-358.0.1.el6.noarch
>> kernel-2.6.32-358.0.1.el6.x86_64
>> kernel-devel-2.6.32-279.19.1.el6.x86_64
>> kernel-devel-2.6.32-358.0.1.el6.x86_64
>> kernel-2.6.32-279.9.1.el6.x86_64
>> libreport-plugin-kerneloops-2.0.9-15.el6.centos.x86_64
>> kernel-2.6.32-279.22.1.el6.x86_64
>> kernel-devel-2.6.32-279.9.1.el6.x86_64
>>
>> This is from a VM that succeeded with the update to the "359"
>> kernel.  There are three more like that.
>>
>> Emmett
>>
> 
> You are giving conflicting information.
> 
> You indicated that the kernel that you are getting the panic on is:
> 
>>> Kernel panic - Not syncing: Attempted to kill init!
>>> Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
> 
> i.e., ...358.2.1
> 
> What you are showing as available from @updates and installed in the
> VM that is working is:
> 
>kernel.x86_64 2.6.32-358.0.1.el6   @updates
> 
>kernel-2.6.32-358.0.1.el6.x86_64
> 
> i.e., ...358.0.1
> 
> 
> RedHat released ...358.2.1 earlier today, but I haven't seen centos
> announce its release yet, and it's not available from the centos
> repositories as of a few moments ago. So, the VM that is ok is using
> ...358.0.1, the centos released kernel. The one that is panic would
> appear to have come from elsewhere.
> 
> Also note, it's the "358", not "359" kernel:
> 
>> This is from a VM that succeeded with the update to the "359"
>> kernel.  There are three more like that.
Yes, kernel "358". the "359" was a typo.  And... the kernel panic lines were 
transcribed for a photo I took of the screen after the failed boot.  On second 
look I see that the version is 2.6.32-358.0.1.el6.x86_64.

So let's start again.

Kernel panic - Not syncing: Attempted to kill init!
Pid: 1, comm: init not tainted: 2.6.32-358.0.1.el6.x86_64 #1

After yum upgrade --enablerepo=epel on two of five machines, one of which is 
the host for the three VM's that succeeded and the one that failed, just as the 
host.

I have a screen shot of that VM's boot failure, but I don't know the proper way 
to include it in a post.

I've uninstalled that kernel and ran yum upgrade again, it still fails on that 
kernel, on both the host and the VM.  I suppose the good thing is that it 
happened on a VM guest that is not critical, so I don't have to experiment with 
the host that has four important guests running on it.

Any ideas?

Emmett


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] raid 1 question

[SilverTip257]

On Tue, Mar 12, 2013 at 1:28 PM, Dave Johansen wrote:

> On Fri, Mar 8, 2013 at 6:14 AM, SilverTip257 
> wrote:
> >
> > On Thu, Mar 7, 2013 at 6:54 PM, Gerry Reno  wrote:
> >
> > > On 03/07/2013 06:52 PM, Les Mikesell wrote:
> > > > On Thu, Mar 7, 2013 at 5:40 PM, John R Pierce 
> > > wrote:
> > > >> On 3/7/2013 3:35 PM, Gerry Reno wrote:
> > > >>> Dave,  I've been using software raid with every type of RedHat
> distro
> > > RH/CentOS/Fedora for over 10 years without any
> > > >>> serious difficulties.  I don't quite understand the logic in all
> these
> > > negative statements about software raid on that
> > > >>> wiki page.  The worst I get into is I have to boot from a bootdisk
> if
> > > the MBR gets corrupted for any reason.  No big
> > > >>> deal.  Just rerun grub.
> > > >> have you been putting /boot on a mdraid?  that's what the article is
> > > >> recommending against.
> > > > I've put /boot on md  raid1 on a lot of machines (always drives small
> > > > enough to be MBR based) and never had any problem with the partition
> > > > looking enough like a native one for grub to boot it.  The worst
> thing
> > >
> >
> > No problems here either - I have had /boot on software raid1 on quite a
> few
> > systems past and present.
> >
> >
> > > > I've seen about it is that some machines change their idea of bios
> > >
> >
> > If I do have a drive fail, I can frequently hot-remove them and hot-add
> the
> > replacement drive to get it resyncing without powering off.
> >
> >
> > > > disk 0 and 1 when the first one fails, so your grub setup might be
> > > > wrong even after you do it on the 2nd disk - and that would be the
> > > > same with/without raid.   As long as you are prepared to boot from a
> > > > rescue disk you can fix it easily anyway.
> > > >
> > > Good point, Les.   Rescue disks and bootdisks are key and critical if
> > > you're going to use software raid.
> > >
> > >
> > I think we could argue that rescue disks are a necessity regardless one
> is
> > using software raid or not.  :)
>
> Thanks for all of the helpful info, and now I have a follow on
> question. I have a Dell m6500 that I've been running as a RAID 1 using
> the BIOS RAID on RHEL 5. The issue is that when you switch one of the
> drives, the BIOS renames the RAID and then RHEL 5 doesn't recognize it
> anymore. So here are my questions:
>
> 1) Has this issue of handling the renaming been resolved in RHEL 6?
> (my guess is no)
>

I've not seen any weird bios naming issues.


> 2) Would a software RAID be a better choice than using the BIOS RAID?
>

It depends!  In another thread on this list someone said they prefer the
reliable Linux toolset over the manufacturer tools/RAID controllers.

In a way it comes down to what you can afford and what you are comfortable
with.
And then there are chips on the hardware RAID controllers on which the RAID
operations are offloaded.


> 3) If a software RAID is the better choice, are there going to be an
> impact on performance/stability/etc?
>

Supposedly hardware RAID performs better.  I've not done any tests to
quantify this statement I've heard others make.

Since it's software RAID, the OS will be using a few CPU cycles to handle
the softraid.  But I'll doubt you'll miss those CPU cycles ... I haven't
and I have a mix of hardware raid and software raid systems.  In the end
that it will come down to drive performance in terms of how many IOPS you
can squeeze out of your drives.

Make certain to set up checks for your array health and disk health
(smartd).  If you use hardware raid many controllers don't allow directly
accessing the drives with smartctl ... you have to use a vendor
binary/utility (or open source one if available).

And then there's aligning your hardware RAID boundaries... [0] [1]  :)

[0]
http://www.mysqlperformanceblog.com/2011/06/09/aligning-io-on-a-hard-disk-raid-the-theory/
[1]
http://www.mysqlperformanceblog.com/2011/12/16/setting-up-xfs-the-simple-edition/


>
> Thanks,
> Dave
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what is "single spanned virtual disk" on RAID10????

[SilverTip257]

On Tue, Mar 12, 2013 at 7:44 AM, mcclnx mcc  wrote:

> We have DELL R910 with H800 adapter in it.  several MD1220 connect to H800.
>

MD1220 = your Dell storage array?


>
> Since MD1220 have 24 hard disks in it.  When I configured RAID10, there is
> a choice call 'single spanned virtual disk"  (22 disks).
>
> Can anyone tell me how "single spanned virtual disk" work?
>

Not to be a troll, but that's probably a question better suited for the
Dell and/or PowerEdge list.


>
> Any document relate to it?
>

http://www.dell.com/support/Manuals/us/en/19/product/powervault-md1220


>
> Thanks.
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT/HW] hardware raid -- comment/experience with 3Ware

[SilverTip257]

On Tue, Mar 12, 2013 at 4:30 AM, Arun Khan  wrote:

> On Thu, Mar 7, 2013 at 12:07 AM, Gordon Messmer  wrote:
> > On 03/06/2013 08:35 AM, Arun Khan wrote:
> >
> >> Any preference between 1 and 2 above.
> >
> > Based on about 10 years of running a hundred or so systems with 3ware
> > controllers, I would say that you're better off with an LSI MegaRAID
> > card, or with Linux software RAID.  3ware cards themselves have been the
> > most problematic component of any system I've run in my entire
> > professional career (starting in 1996).  Even very recent cards fail in
> > a wide variety of ways, and there is no guarantee that if your array
> > fails using a controller that you buy now that you'll be able to connect
> > it to a controller that you buy later.
>
> @ Gordon - thanks for sharing this piece of info!  In case of RAID
> card failure, it is important to be able to recover the data (RAID
> device) with a compatible replacement.Are the LSI MegaRAID
> controller more reliable in this respect?
>

I've not had any MegaRAID controllers fail, so I can only say they've been
reliable thus far!


>
> > At this point, I deploy almost exclusively systems running Linux with
> > KVM on top of software RAID.  While I lose the battery backed write
> > cache (which is great for performance unless you sustain enough writes
> > to fill it completely, at which point the system grinds nearly to a
> > halt), I gain a consistent set of management tools and the ability to
> > move a disk array to any hardware that accepts the same form factor
> > disk.  The reliability of my systems has improved significantly since I
> > moved to software RAID.
>
> Software RAID is an option but I don't think hot swap is possible
> without some tinkering with the mdadm tool a priori.
>

Hot swap really depends on what your HBA or RAID controller supports.

You start by failing/removing the drive via mdadm.  Then hot remove the
disk from the subsystem (ex: SCSI [0]) and finally physically remove it.
 Then work in the opposite direction ... hot add (SCSI [1]), clone the
partition layout from one drive to the new with sfdisk, and finally add the
new disk/partitions to your softraid array with mdadm.

You must hot remove the disk from the SCSI subsystem or the block device
(ex: /dev/sdc) name is occupied and unavailable for the new disk you put in
the system.  I've used the above procedure many times to repair softraid
arrays while keeping systems online.

[0]
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html
[1]
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/adding_storage-device-or-path.html

The systems will go to client site (remote),  prefer to keep the
> support calls to remove/replace hardware activity :(
>
> Thanks,
> -- Arun Khan
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[SilverTip257]

On Tue, Mar 12, 2013 at 3:45 PM, David Hrbáč  wrote:

> Dne 12.3.2013 19:03, Fabien Archambault napsal(a):
> > I too have the same problem but couldn't figure where is the issue. It
> > stops working even if the service says all is right. I have to restart
> > the service to let it work again...
> >
> > I will try to find through your idea.
> >
> > Thanks,
> > Fabien
> >
>
> As temporary solution you can always use fail2ban from Repoforge. It's a
> little bit older, but works on 6.x.
>

The newest is slightly older as you noted:
http://pkgs.repoforge.org/fail2ban/

Quite a selection of older versions too...


> Regards,
> David Hrbac
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[SilverTip257]

On Tue, Mar 12, 2013 at 1:57 PM, Theo Band  wrote:

> On 03/12/2013 05:35 PM, Timothy Murphy wrote:
> > I'm running fail2ban on my server (under CentOS-6.4)
> > and it seems to be running according to
> > -
> > [tim@grover fail2ban]$ sudo service fail2ban status
> > Fail2ban (pid 31794) is running...
> > Status
> > |- Number of jail:  1
> > `- Jail list:   ssh-iptables
> > -
> > I have absolutely no idea how fail2ban works,
>

First off, as a good security practice do not let SSH open to the world
unless you have to (and even then I'd go so far as to say restrict it the
best you can).  Fail2ban can become a band aid for good security practices.


> > and I'm running it with the default /etc/fail2ban/fail2ban.conf ,
> > which seems to set the logfile to /var/log/fail2ban.log .
> > Should I actually study how it is meant to be configured?
>

I'd suggest at least checking out information on fail2ban's wiki and
perusing the config files (especially jail.conf).


> >
> > I just yum-installed it (from Epel, I assume)
> > and hope it does its job, whatever that is.
> It sets up iptables rules for every jail that is configured (iptables
> -L). You seem to have only the ssh-iptables configured. Check the date
> of the logfile. I noticed that SYSLOG is now used for logging. It used
> to be /var/log/fail2ban.log in the past. I removed the old log file.
> If ssh is the only public service you want to protect against brute
> force, then you don't need to setup anything. But have a look in
> /etc/fail2ban/jail.conf and add at least your email address to get a
>

You can tweak things quite a bit to make sure logs are going where you want
them to and that fail2ban is watching the right files.


> notification when it blocks access. There lots of other "jails" that can
> be enabled.
> Normally I receive several messages a day. So not receiving them means
> that the service is no longer protecting. Simply because it watches a
> renamed no longer updated version of /var/log/secure:
>

I'll add that if someone decides to restart iptables, your fail2ban chains
will be removed.  So you'll need to restart fail2ban and check that the
chains and rules are present again.  Otherwise fail2ban will report, but
won't be able to actually add a firewall rule to block the brute forcing
host.


>
> ls -l /var/log/secure*
> -rw--- 1 root root 2130892 Mar 12 18:25 /var/log/secure
> -rw--- 1 root root 1374710 Feb 17 01:31 /var/log/secure-20130217
> -rw--- 1 root root 1482646 Feb 24 03:09 /var/log/secure-20130224
> -rw--- 1 root root 1732930 Mar  3 03:13 /var/log/secure-20130303
> -rw--- 1 root root  656454 Mar 10 03:12 /var/log/secure-20130310
>
> Once a week fail2ban stops working as a new secure log file is created
> (logrotate) and it seems to watch the only old name. You will not see
> any error message and status show as running.
> But I have no proof that it keeps working with the gamin fix.
>

I've not seen any problems since I switched to the gamin backend some time
ago.  As you do, I generally get at least one daily notification email that
my FTP daemon is being brute forced.  So I'd say it's working fine.


>
> Theo
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Shorewall and upgrade from 6.3 to 6.4

[Kahlil Hodgson]

Just got burnt by this one this morning.

If you are upgrading from 6.3 to 6.4 and you use shorewall, you will 
want to run

restorecon -Rv /sbin

before rebooting.  Original solution from:

> http://www.mail-archive.com/shorewall-users@lists.sourceforge.net/msg14885.html

Cheers,

kal
-- 
Kahlil (Kal) Hodgson   GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd(w) +61 (0) 3 9008 5281

Suite 1415
401 Docklands Drive
Docklands VIC 3008 Australia

"All parts should go together without forcing.  You must remember that
the parts you are reassembling were disassembled by you.  Therefore,
if you can't get them together again, there must be a reason.  By all
means, do not use a hammer."  -- IBM maintenance manual, 1925

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel panic after update to 6.4

[Emmett Culley]

On 03/12/2013 01:48 PM, Akemi Yagi wrote:
> On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley  wrote:
>> After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to 
>> update the host as well.  And it failed to boot.
>>
>> Kernel panic - Not syncing: Attempted to kill init!
>> Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
> 
> At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is not
> out yet. Where did you get this one from ???  Did you build it
> yourself?
> 
> Akemi

I did yum update --enablerepo=epel.  I just checked and it appears that kernel 
was from the updates repo:

[~]# yum list kernel
Installed Packages
kernel.x86_64 2.6.32-279.9.1.el6   @updates
kernel.x86_64 2.6.32-279.14.1.el6  @updates
kernel.x86_64 2.6.32-279.19.1.el6  @updates
kernel.x86_64 2.6.32-279.22.1.el6  @updates
kernel.x86_64 2.6.32-358.0.1.el6   @updates

[~]# rpm -qa |grep kernel
abrt-addon-kerneloops-2.0.8-15.el6.centos.x86_64
kernel-2.6.32-279.19.1.el6.x86_64
dracut-kernel-004-303.el6.noarch
kernel-devel-2.6.32-279.14.1.el6.x86_64
kernel-2.6.32-279.14.1.el6.x86_64
kernel-devel-2.6.32-279.22.1.el6.x86_64
kernel-headers-2.6.32-358.0.1.el6.x86_64
kernel-firmware-2.6.32-358.0.1.el6.noarch
kernel-2.6.32-358.0.1.el6.x86_64
kernel-devel-2.6.32-279.19.1.el6.x86_64
kernel-devel-2.6.32-358.0.1.el6.x86_64
kernel-2.6.32-279.9.1.el6.x86_64
libreport-plugin-kerneloops-2.0.9-15.el6.centos.x86_64
kernel-2.6.32-279.22.1.el6.x86_64
kernel-devel-2.6.32-279.9.1.el6.x86_64

This is from a VM that succeeded with the update to the "359" kernel.  There 
are three more like that.

Emmett


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] 6.x - USB key

[m . roth]

I just had to rebuild my USB key for a generic install (got to do that for
a drive to send with the system back to the OEM for repair, y'know). This
time, I used unetbootin, which took a while to build the key, and worked
*almost* well.

The two annoying hangups: it took a *long* time to extract the packages
and put them all on the USB key, looking like a repo... EXCEPT that during
the install, anaconda *demands* the .iso. I went back, deleted
/mnt/usb/Packages, since it's only an 8G key, and just copied DVD 1 onto
it. anaconda stopped, asked me where, I told it, and it happily went on
its way.

Then, it doesn't give you any kind of default grub.conf

Oh, well. Drive's built and boots.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOs 6.4 and video drivers

[Ned Slider]

On 12/03/13 17:24, Trevor Cooper wrote:
>
> On 03/11/2013 10:14 PM, Ned Slider wrote:
>> On 11/03/13 21:58, Trevor Cooper wrote:
>>> On 03/10/2013 03:45 AM, Ned Slider wrote:
 On 10/03/13 01:24, Yves Bellefeuille wrote:
> Akemi Yagi wrote:
>
>> Depend on how "new" your card is. :)
> HD 4800 series, RV770
>
> >  More details are in this ELRepo bug report:
>> http://elrepo.org/bugs/view.php?id=355
> So I guess I should try enabling the testing repository. Thanks.
>
> Yves Bellefeuille
>
>
 Unfortunately older Radeon HD 4000, HD 3000, HD 2000 Series are NOT
 currently supported as the current AMD driver does NOT support the new
 version of Xorg in 6.4.

 So your HD 4800 series is NOT supported.

 Radeon HD 7000, HD 6000, HD 5000 Series ARE supported by the version
 13.1 driver currently in the testing repo. I've had a couple of reports
 that this driver works so I'll move it to the main repo shortly. If you
 have supporting hardware I would recommend updating to this driver
 before performing the 6.4 update.
>>> I've read the Known Issues in the C64 Release Notes.
>>>
>>> Any thoughts on whether it's sufficient to 'exclude=xorg*' prior to updating
>>> from 6.3 to 6.4 to keep the X server compatible with AMD 4xxx series
>>> card/driver? Will I be the first to try this?
>>>
>> Yes that works fine, but you also need to exclude mesa* too for the
>> upgrade. You're not the first to try this, at least one user I know has
>> downgraded xorg*, mesa* after a failed update to get things working
>> again so it's a confirmed option.
>
> That's interesting.
>
> A downgrade of xorg-x11* worked for me WITHOUT a downgrade of mesa*.
>
> fglrxinfo and fgl_glxgears work fine for me.
>
> [root ~]# fglrxinfo
> display: :0.0  screen: 0
> OpenGL vendor string: Advanced Micro Devices, Inc.
> OpenGL renderer string: ATI Radeon HD 4800 Series
> OpenGL version string: 3.3.11631 Compatibility Profile Context
>
> How would I know that upgrading mesa* had caused a problem? For example,
> glxinfo, glxgears (which depend on libGLU.so.1) work fine.
>
> The update upgraded the following mesa packages...
>
> mesa-dri-drivers x86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libGL   x86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libGL-devel x86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libGLU  x86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libGLU-develx86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libOSMesa   x86_64  7.11-5.el6  ->  9.0-0.7.el6
> mesa-libOSMesa-devel x86_64  7.11-5.el6  ->  9.0-0.7.el6
>
> ...easy enough to downgrade now that I know how but do I need to?
>
> Thanks,
>
> Trevor
>

I guess not, if it's not causing you an issue.

It might be that the new xorg needs the new mesa packages, but the old 
xog is equally happy to run with the new or old mesa packages. So 
apologies for the apparent misinformation :-)




___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Kernel panic after update to 6.4

[Akemi Yagi]

On Tue, Mar 12, 2013 at 1:41 PM, Emmett Culley  wrote:
> After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to 
> update the host as well.  And it failed to boot.
>
> Kernel panic - Not syncing: Attempted to kill init!
> Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1

At the time of this writing, CentOS kernel 2.6.32-358.2.1.el6 is not
out yet. Where did you get this one from ???  Did you build it
yourself?

Akemi
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Kernel panic after update to 6.4

[Emmett Culley]

After successfully updating three CentOS 6.3 VM guests to 6.4 I decided to 
update the host as well.  And it failed to boot.

Kernel panic - Not syncing: Attempted to kill init!
Pid: 1, comm: init not tainted: 2.6.32-358.2.1.el6.x86_64 #1
Plus a call trace I couldn't see

Luckily I was able to boot from the previous kernel and get my system back up.  
After booting to the previous kernel I removed the "358" kernel and all of it's 
related module and devel packages using yum remove, then did yum update again, 
as I could only guess that the install somehow didn't complete.  But it still 
fails to boot.

Now the kernel panic has happened to a 6.3 VM guest I upgraded, now it isn't 
just the host hardware that is a problem.

Has anyone else seen this?

Any ideas where to start troubleshooting?

Emmett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[David Hrbáč]

Dne 12.3.2013 19:03, Fabien Archambault napsal(a):
> I too have the same problem but couldn't figure where is the issue. It
> stops working even if the service says all is right. I have to restart
> the service to let it work again...
>
> I will try to find through your idea.
>
> Thanks,
> Fabien
>

As temporary solution you can always use fail2ban from Repoforge. It's a
little bit older, but works on 6.x.
Regards,
David Hrbac
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] strange sporadic sssd problem on centos

[Gelen James]

>From time to time on centos 6 sssd I got login problems like 'connection 
>closed by *.*.*.*.', after a while then I login in again and the problem 
>already disappeared. 

For the ssh login problem, I can see the following entries in /var/log/secure. 
'Failed public key for '  is the entry for the login problem. Any one has 
some ideas why this happens?

Mar 12 04:30:12 master01 sshd[25185]: Set /proc/self/oom_score_adj to 0
Mar 12 04:30:12 master01 sshd[25185]: Connection from 192.168.1.80 port 48718
Mar 12 04:30:18 master01 sshd[25185]: Found matching RSA key: 
55:52:5e:6c:fe:74:ab:cd:ef:94:96:f4:f7:44:fb:fc
Mar 12 04:30:18 master01 sshd[25186]: Postponed publickey for gotcha from 
192.168.1.80 port 48718 ssh2
Mar 12 04:30:18 master01 sshd[25185]: Found matching RSA key: 
55:52:5e:6c:fe:74:ab:cd:ef:94:96:f4:f7:44:fb:fc
Mar 12 04:31:51 master01 sshd[25185]: Failed publickey for gotcha from 
192.168.1.80 port 48718 ssh2
Mar 12 04:31:51 master01 sshd[25186]: fatal: Access denied for user gotcha by 
PAM account configuration

Thanks.

--Gelen
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT/HW] hardware raid -- comment/experience with 3Ware

[Keith Keller]

On 2013-03-12, Arun Khan  wrote:
>
> Software RAID is an option but I don't think hot swap is possible
> without some tinkering with the mdadm tool a priori.

Hot-swapping a failed drive is basically the same process AFAICT with a
3ware array or an md array.  The primary issue would be to make sure the
controller supports hot swap, and how you tell it to release a drive
from the kernel (a la tw_cli /cx/px remove).  And if you have one or two
spares on a modest array then you can schedule site visits around your
own schedule if a drive fails--either a hardware RAID or linux md will
automatically rebuild with a spare when an active drive is marked as
failed.

Did you have other concerns about hot swapping?  I may be confusing what
you're hoping to do.

--keith


-- 
kkel...@wombat.san-francisco.ca.us


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[Fabien Archambault]

2013/3/12 Theo Band :
> On 03/12/2013 05:35 PM, Timothy Murphy wrote:
>> I'm running fail2ban on my server (under CentOS-6.4)
>> and it seems to be running according to
>> -
>> [tim@grover fail2ban]$ sudo service fail2ban status
>> Fail2ban (pid 31794) is running...
>> Status
>> |- Number of jail:  1
>> `- Jail list:   ssh-iptables
>> -
>> I have absolutely no idea how fail2ban works,
>> and I'm running it with the default /etc/fail2ban/fail2ban.conf ,
>> which seems to set the logfile to /var/log/fail2ban.log .
>> Should I actually study how it is meant to be configured?
>>
>> I just yum-installed it (from Epel, I assume)
>> and hope it does its job, whatever that is.
> It sets up iptables rules for every jail that is configured (iptables
> -L). You seem to have only the ssh-iptables configured. Check the date
> of the logfile. I noticed that SYSLOG is now used for logging. It used
> to be /var/log/fail2ban.log in the past. I removed the old log file.
> If ssh is the only public service you want to protect against brute
> force, then you don't need to setup anything. But have a look in
> /etc/fail2ban/jail.conf and add at least your email address to get a
> notification when it blocks access. There lots of other "jails" that can
> be enabled.
> Normally I receive several messages a day. So not receiving them means
> that the service is no longer protecting. Simply because it watches a
> renamed no longer updated version of /var/log/secure:
>
> ls -l /var/log/secure*
> -rw--- 1 root root 2130892 Mar 12 18:25 /var/log/secure
> -rw--- 1 root root 1374710 Feb 17 01:31 /var/log/secure-20130217
> -rw--- 1 root root 1482646 Feb 24 03:09 /var/log/secure-20130224
> -rw--- 1 root root 1732930 Mar  3 03:13 /var/log/secure-20130303
> -rw--- 1 root root  656454 Mar 10 03:12 /var/log/secure-20130310
>
> Once a week fail2ban stops working as a new secure log file is created
> (logrotate) and it seems to watch the only old name. You will not see
> any error message and status show as running.
> But I have no proof that it keeps working with the gamin fix.
>
> Theo
>

I too have the same problem but couldn't figure where is the issue. It
stops working even if the service says all is right. I have to restart
the service to let it work again...

I will try to find through your idea.

Thanks,
Fabien
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[Theo Band]

On 03/12/2013 05:35 PM, Timothy Murphy wrote:
> I'm running fail2ban on my server (under CentOS-6.4)
> and it seems to be running according to
> -
> [tim@grover fail2ban]$ sudo service fail2ban status
> Fail2ban (pid 31794) is running...
> Status
> |- Number of jail:  1
> `- Jail list:   ssh-iptables
> -
> I have absolutely no idea how fail2ban works,
> and I'm running it with the default /etc/fail2ban/fail2ban.conf ,
> which seems to set the logfile to /var/log/fail2ban.log .
> Should I actually study how it is meant to be configured?
>
> I just yum-installed it (from Epel, I assume)
> and hope it does its job, whatever that is.
It sets up iptables rules for every jail that is configured (iptables 
-L). You seem to have only the ssh-iptables configured. Check the date 
of the logfile. I noticed that SYSLOG is now used for logging. It used 
to be /var/log/fail2ban.log in the past. I removed the old log file.
If ssh is the only public service you want to protect against brute 
force, then you don't need to setup anything. But have a look in 
/etc/fail2ban/jail.conf and add at least your email address to get a 
notification when it blocks access. There lots of other "jails" that can 
be enabled.
Normally I receive several messages a day. So not receiving them means 
that the service is no longer protecting. Simply because it watches a 
renamed no longer updated version of /var/log/secure:

ls -l /var/log/secure*
-rw--- 1 root root 2130892 Mar 12 18:25 /var/log/secure
-rw--- 1 root root 1374710 Feb 17 01:31 /var/log/secure-20130217
-rw--- 1 root root 1482646 Feb 24 03:09 /var/log/secure-20130224
-rw--- 1 root root 1732930 Mar  3 03:13 /var/log/secure-20130303
-rw--- 1 root root  656454 Mar 10 03:12 /var/log/secure-20130310

Once a week fail2ban stops working as a new secure log file is created 
(logrotate) and it seems to watch the only old name. You will not see 
any error message and status show as running.
But I have no proof that it keeps working with the gamin fix.

Theo



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Installing VNCSERVER on Linux machine

[Scott Robbins]

On Tue, Mar 12, 2013 at 05:16:18PM +, Norah Jones wrote:
> How can I install vncserver on my linux machine so that I can connect from 
> windows client.
> 
Try the wiki instructions.

http://wiki.centos.org/HowTos/VNC-Server



> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Willow: So, how did it go? 
Xander: On a scale from one to ten? It sucked. 
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOs 6.4 and video drivers

[Trevor Cooper]

On 03/11/2013 07:33 PM, Yves Bellefeuille wrote:
> On Monday 11 March 2013, Trevor Cooper  wrote:
>
>> Any thoughts on whether it's sufficient to 'exclude=xorg*' prior to
>> updating from 6.3 to 6.4 to keep the X server compatible with AMD
>> 4xxx series card/driver? Will I be the first to try this?
> I can confirm that you can backtrack by enabling the proper vault 
> repositories (and giving them the appropriate priorities), and then 
> doing "yum remove xorg-x11-drv-modesetting", "yum downgrade xorg-x11*".
>
While I did not have xorg-x11-drv-modesetting installed (thus did not need to
remove it). I can confirm this was able to get my xorg-x11 downgraded. For the
less educated (myself included BEFORE this process) here is the command that I
used to downgrade my xorg-x11*...

yum --enablerepo=C6.3-base --enablerepo=C6.3-updates downgrade xorg-x11*

Hope that helps others.

Trevor
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] raid 1 question

[Dave Johansen]

On Fri, Mar 8, 2013 at 6:14 AM, SilverTip257  wrote:
>
> On Thu, Mar 7, 2013 at 6:54 PM, Gerry Reno  wrote:
>
> > On 03/07/2013 06:52 PM, Les Mikesell wrote:
> > > On Thu, Mar 7, 2013 at 5:40 PM, John R Pierce 
> > wrote:
> > >> On 3/7/2013 3:35 PM, Gerry Reno wrote:
> > >>> Dave,  I've been using software raid with every type of RedHat distro
> > RH/CentOS/Fedora for over 10 years without any
> > >>> serious difficulties.  I don't quite understand the logic in all these
> > negative statements about software raid on that
> > >>> wiki page.  The worst I get into is I have to boot from a bootdisk if
> > the MBR gets corrupted for any reason.  No big
> > >>> deal.  Just rerun grub.
> > >> have you been putting /boot on a mdraid?  that's what the article is
> > >> recommending against.
> > > I've put /boot on md  raid1 on a lot of machines (always drives small
> > > enough to be MBR based) and never had any problem with the partition
> > > looking enough like a native one for grub to boot it.  The worst thing
> >
>
> No problems here either - I have had /boot on software raid1 on quite a few
> systems past and present.
>
>
> > > I've seen about it is that some machines change their idea of bios
> >
>
> If I do have a drive fail, I can frequently hot-remove them and hot-add the
> replacement drive to get it resyncing without powering off.
>
>
> > > disk 0 and 1 when the first one fails, so your grub setup might be
> > > wrong even after you do it on the 2nd disk - and that would be the
> > > same with/without raid.   As long as you are prepared to boot from a
> > > rescue disk you can fix it easily anyway.
> > >
> > Good point, Les.   Rescue disks and bootdisks are key and critical if
> > you're going to use software raid.
> >
> >
> I think we could argue that rescue disks are a necessity regardless one is
> using software raid or not.  :)

Thanks for all of the helpful info, and now I have a follow on
question. I have a Dell m6500 that I've been running as a RAID 1 using
the BIOS RAID on RHEL 5. The issue is that when you switch one of the
drives, the BIOS renames the RAID and then RHEL 5 doesn't recognize it
anymore. So here are my questions:

1) Has this issue of handling the renaming been resolved in RHEL 6?
(my guess is no)
2) Would a software RAID be a better choice than using the BIOS RAID?
3) If a software RAID is the better choice, are there going to be an
impact on performance/stability/etc?

Thanks,
Dave
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOs 6.4 and video drivers

[Trevor Cooper]

On 03/11/2013 10:14 PM, Ned Slider wrote:
> On 11/03/13 21:58, Trevor Cooper wrote:
>> On 03/10/2013 03:45 AM, Ned Slider wrote:
>>> On 10/03/13 01:24, Yves Bellefeuille wrote:
 Akemi Yagi wrote:

> Depend on how "new" your card is. :)
 HD 4800 series, RV770

>  More details are in this ELRepo bug report:
>http://elrepo.org/bugs/view.php?id=355
 So I guess I should try enabling the testing repository. Thanks.

 Yves Bellefeuille


>>> Unfortunately older Radeon HD 4000, HD 3000, HD 2000 Series are NOT
>>> currently supported as the current AMD driver does NOT support the new
>>> version of Xorg in 6.4.
>>>
>>> So your HD 4800 series is NOT supported.
>>>
>>> Radeon HD 7000, HD 6000, HD 5000 Series ARE supported by the version
>>> 13.1 driver currently in the testing repo. I've had a couple of reports
>>> that this driver works so I'll move it to the main repo shortly. If you
>>> have supporting hardware I would recommend updating to this driver
>>> before performing the 6.4 update.
>> I've read the Known Issues in the C64 Release Notes.
>>
>> Any thoughts on whether it's sufficient to 'exclude=xorg*' prior to updating
>> from 6.3 to 6.4 to keep the X server compatible with AMD 4xxx series
>> card/driver? Will I be the first to try this?
>>
> Yes that works fine, but you also need to exclude mesa* too for the 
> upgrade. You're not the first to try this, at least one user I know has 
> downgraded xorg*, mesa* after a failed update to get things working 
> again so it's a confirmed option.

That's interesting.

A downgrade of xorg-x11* worked for me WITHOUT a downgrade of mesa*.

fglrxinfo and fgl_glxgears work fine for me.

[root ~]# fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: ATI Radeon HD 4800 Series   
OpenGL version string: 3.3.11631 Compatibility Profile Context

How would I know that upgrading mesa* had caused a problem? For example,
glxinfo, glxgears (which depend on libGLU.so.1) work fine.

The update upgraded the following mesa packages...

mesa-dri-drivers x86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libGL   x86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libGL-devel x86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libGLU  x86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libGLU-develx86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libOSMesa   x86_64  7.11-5.el6  ->  9.0-0.7.el6
mesa-libOSMesa-devel x86_64  7.11-5.el6  ->  9.0-0.7.el6

...easy enough to downgrade now that I know how but do I need to?

Thanks,

Trevor



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Installing VNCSERVER on Linux machine

[Bo Lynch]

I would take a look at this

http://wiki.centos.org/HowTos/VNC-Server



On Tue, March 12, 2013 1:16 pm, Norah Jones wrote:
> How can I install vncserver on my linux machine so that I can connect from
> windows client.
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Installing VNCSERVER on Linux machine

[Norah Jones]

How can I install vncserver on my linux machine so that I can connect from 
windows client.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[Timothy Murphy]

Theo Band wrote:

> I have updated recently to 6 and see that fail2band ssh dos no longer
> works. Indeed after log rotate fail2ban seems to follow the old log file
> instead of the newly created /var/log/secure.
> I had backend = auto in /etc/fail2ban/jail.conf and gamin and pyinotify
> are both installed. I now changed backend to gamin and give it another
> try. The next log rotate is next week
> Anyone else using fail2ban with CentOS6 installed from epel?

I'm running fail2ban on my server (under CentOS-6.4)
and it seems to be running according to
-
[tim@grover fail2ban]$ sudo service fail2ban status
Fail2ban (pid 31794) is running...
Status
|- Number of jail:  1
`- Jail list:   ssh-iptables
-
I have absolutely no idea how fail2ban works,
and I'm running it with the default /etc/fail2ban/fail2ban.conf ,
which seems to set the logfile to /var/log/fail2ban.log .
Should I actually study how it is meant to be configured?

I just yum-installed it (from Epel, I assume)
and hope it does its job, whatever that is.

Incidentally, I am running shorewall on this server.
Should I tell shorewall something about fail2ban,
or vice versa?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[SilverTip257]

On Tue, Mar 12, 2013 at 11:51 AM, Theo Band  wrote:

> On 10/17/2012 05:51 PM, SilverTip257 wrote:
> > I recall others on this list are using fail2ban to block brute force
> > login attempts.
> > Packages are from the EPEL repo, so I'm just sharing some knowledge here.
> >
> > For about two months now I've had a CentOS 6.3 box (web host) in
> > production that occasionally is ftp brute forced.
> > Oddly enough fail2ban wasn't nabbing the perpetrators.  I found that
> > the iptables chain for VSFTP isn't created for one.
> >
> > I have finally come to find [0] that indicates there's a problem with
> > the inotify backend.
> > Setting backend=gamin in /etc/fail2ban/jail.conf gives me the iptables
> > chain I expect to find and one blocked host.
> >
> > Hope this is helpful to somebody until a new version is commited to EPEL.
> >
> > 
> > yarikoptic:
> > ok -- that point was not yet good ;) now (0.8.6-95-gc0c1232) that
> > branch seems to work just perfect. If I hear no complaints or do not
> > see problem with my instance -- I will merge it into master tomorrow,
> > thus closing this issue
> > 
> >
> > [0] https://github.com/fail2ban/fail2ban/issues/44
> >
>
> Thanks for the tip (I know it's a very old message).
>

Happy you found it useful.


> I have updated recently to 6 and see that fail2band ssh dos no longer
> works. Indeed after log rotate fail2ban seems to follow the old log file
> instead of the newly created /var/log/secure.
>

I've also recently noticed fail2ban choking on name resolution.  By that I
mean f2b determines the name of the connecting host and it complains
indicating the pointer record doesn't match.  Based on the number of login
attempts it doesn't seem to be actually blocking the host either.

I have SSH locked down for my access only, but FTP is wide open for
customer access.  I let fail2ban keep tabs on logins with the
vsftp-iptables jail.


> I had backend = auto in /etc/fail2ban/jail.conf and gamin and pyinotify
> are both installed. I now changed backend to gamin and give it another
> try. The next log rotate is next week
> Anyone else using fail2ban with CentOS6 installed from epel?
>
> fail2ban-0.8.8-2.el6.noarch on CentOS6.4
>
> Theo
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 - fail2ban not working properly + workaround

[Theo Band]

On 10/17/2012 05:51 PM, SilverTip257 wrote:
> I recall others on this list are using fail2ban to block brute force
> login attempts.
> Packages are from the EPEL repo, so I'm just sharing some knowledge here.
>
> For about two months now I've had a CentOS 6.3 box (web host) in
> production that occasionally is ftp brute forced.
> Oddly enough fail2ban wasn't nabbing the perpetrators.  I found that
> the iptables chain for VSFTP isn't created for one.
>
> I have finally come to find [0] that indicates there's a problem with
> the inotify backend.
> Setting backend=gamin in /etc/fail2ban/jail.conf gives me the iptables
> chain I expect to find and one blocked host.
>
> Hope this is helpful to somebody until a new version is commited to EPEL.
>
> 
> yarikoptic:
> ok -- that point was not yet good ;) now (0.8.6-95-gc0c1232) that
> branch seems to work just perfect. If I hear no complaints or do not
> see problem with my instance -- I will merge it into master tomorrow,
> thus closing this issue
> 
>
> [0] https://github.com/fail2ban/fail2ban/issues/44
>

Thanks for the tip (I know it's a very old message).
I have updated recently to 6 and see that fail2band ssh dos no longer
works. Indeed after log rotate fail2ban seems to follow the old log file
instead of the newly created /var/log/secure.
I had backend = auto in /etc/fail2ban/jail.conf and gamin and pyinotify
are both installed. I now changed backend to gamin and give it another
try. The next log rotate is next week
Anyone else using fail2ban with CentOS6 installed from epel?

fail2ban-0.8.8-2.el6.noarch on CentOS6.4

Theo
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Solr 4.1 - how to check replication staistics using wget?

[Rafał Radecki]

Hi All.

I am currently migrating from solr 3.6 to solr 4.1.
In 3.6 to check the status of solr master/slave replication I've been using url:

http://${SOLRMASTER}:${SOLRPORT}/solr/admin/replication/index.jsp

from script.
After migration to 4.1 this url is no longer available. Can you tell
which url can be used from script to check replication status?

Best regards,
Rafal.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix setup

[James B. Byrne]

On Mon, March 11, 2013 16:56, Craig White wrote:

>
> 
> develop good, consistent habits… postfix or whatever config files you
> edit, backup the distribution's version of the config file first
> before you ever edit…
>
> cp main.cf main.cf-dist
>

Alternatively:

yum install postfix
yum install git
cd /etc/posfix
git init
git add ./
git commit -m"Postfix config file initial commit"

Now all the default config files are stored as hashed blobs in
/etc/postfix/.git and you can modify them in place.  Once you are
satisfied with your latest set of changes do this (always issue git
commands from the repository root, in this case /etc/postfix):

git add ./  or  git add 
git commit -m"explanation of why the changes were made"

If you screw up and need to get back what was there originally do this:

git checkout 

If you want to see what was different between this config and the
previous version do this:

git diff 

You can compare any previous version of any tracked file with any
other version of the same file by specifying the commit ids.

git diff .. -- 

Git also provides a blow by blow history of all changes applied to a
file and what logon id made them.

git blame .. -- 

See http://git-scm.com/ for details on what git is and how to use it. 
I use git for version control of system config files on all my uptime
sensitive servers.  It makes getting back to a working config trivial
when things turn ugly following a change.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Postfix setup

[James B. Byrne]

On Mon, March 11, 2013 14:01, Les Mikesell wrote:
>
> On the other hand, if you do 'normal' things with sendmail, all you
> have to do is tweak a few values in the provided sendmail.mc and
> restart to rebuild the configs, and if you do anything unusual you can
> drop in MimeDefang as a milter and gain complete control of all of the
> internal steps in a small snippet of perl.

Could not be any simpler then the way you put it. Which is why I
suggest starting out with Postfix for first time MTA admins.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 97, Issue 6

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CEBA-2013:0311-01  CentOS 6 qemu-kvm Update (Johnny Hughes)
   2. CEBA-2013:0618  CentOS 6 selinux-policy Update (Johnny Hughes)
   3. CEBA-2013:0617  CentOS 5 kexec-tools Update (Johnny Hughes)
   4. CESA-2013:0623 Important CentOS 6 tomcat6 Update (Johnny Hughes)
   5. CESA-2013:0628 Moderate CentOS 6 389-ds-base  Update
  (Johnny Hughes)
   6. CESA-2013:0627 Important CentOS 6 thunderbird Update
  (Johnny Hughes)
   7. CESA-2013:0627 Important CentOS 5 thunderbird Update
  (Johnny Hughes)
   8. CESA-2013:0621 Important CentOS 5 kernel Update (Johnny Hughes)


--

Message: 1
Date: Mon, 11 Mar 2013 16:23:37 +
From: Johnny Hughes 
Subject: [CentOS-announce] CEBA-2013:0311-01  CentOS 6 qemu-kvm Update
To: centos-annou...@centos.org
Message-ID: <20130311162337.ga21...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2013:0311-01 

Upstream details at : http://bugs.centos.org/view.php?id=6297

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
897e67048ef2b567763de9ff31820b22ac3071f9b4d4b18eecd53781b4fa6d5e  
qemu-guest-agent-0.12.1.2-2.355.0.1.el6.centos.2.i686.rpm

x86_64:
981d66828d3cd79feb99d01e88c9a590d4b78cc0cbbcb249ba339bdc1e57d9a1  
qemu-guest-agent-0.12.1.2-2.355.0.1.el6.centos.2.x86_64.rpm
2acde5847e166e2144a59861e664a095fcfa49748db1e2c07f36e960180d8679  
qemu-guest-agent-win32-0.12.1.2-2.355.0.1.el6.centos.2.x86_64.rpm
b5b202da0781fbcb7bab37e69b4d5c058c88c67853ab5b23fe712ea596e0dbec  
qemu-img-0.12.1.2-2.355.0.1.el6.centos.2.x86_64.rpm
b150502d2a542742c1da405dca021b57f3709e87da9546aa53f14a0abcd02296  
qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.2.x86_64.rpm
cc76f7c1bfc2da33c5fdac478aa9130f23471283124b81331c1b69c67792d285  
qemu-kvm-tools-0.12.1.2-2.355.0.1.el6.centos.2.x86_64.rpm

Source:
b49342afe3d898ce79001b7ffa78abb8f13353fcff2c0bc6eb5d1dae0e43f20e  
qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.2.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net



--

Message: 2
Date: Mon, 11 Mar 2013 16:25:56 +
From: Johnny Hughes 
Subject: [CentOS-announce] CEBA-2013:0618  CentOS 6 selinux-policy
Update
To: centos-annou...@centos.org
Message-ID: <20130311162556.ga21...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2013:0618 

Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-0618.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
332c75df42630f6db81d8ef27938da3c6cc8d7f8fba92b1882fc9799ee6eefca  
selinux-policy-3.7.19-195.el6_4.3.noarch.rpm
d3f61dd2304b1e7f1bbf4718506057d2d974e6b646ab13b42bb23dd00a1d2765  
selinux-policy-doc-3.7.19-195.el6_4.3.noarch.rpm
d864c9a484ccfdc2ef73cde3a34bb3d2a2ab964fa38d263147ef1e70d40e074b  
selinux-policy-minimum-3.7.19-195.el6_4.3.noarch.rpm
6f67038d255b6daf51ac8670dc2b68203bdd93a3f29033e50a662f41acbcc6af  
selinux-policy-mls-3.7.19-195.el6_4.3.noarch.rpm
524bc2b068422c8a16999a37fa0c2fa81590fe22ea1833a1bca07d46a00b0bfb  
selinux-policy-targeted-3.7.19-195.el6_4.3.noarch.rpm

x86_64:
332c75df42630f6db81d8ef27938da3c6cc8d7f8fba92b1882fc9799ee6eefca  
selinux-policy-3.7.19-195.el6_4.3.noarch.rpm
d3f61dd2304b1e7f1bbf4718506057d2d974e6b646ab13b42bb23dd00a1d2765  
selinux-policy-doc-3.7.19-195.el6_4.3.noarch.rpm
d864c9a484ccfdc2ef73cde3a34bb3d2a2ab964fa38d263147ef1e70d40e074b  
selinux-policy-minimum-3.7.19-195.el6_4.3.noarch.rpm
6f67038d255b6daf51ac8670dc2b68203bdd93a3f29033e50a662f41acbcc6af  
selinux-policy-mls-3.7.19-195.el6_4.3.noarch.rpm
524bc2b068422c8a16999a37fa0c2fa81590fe22ea1833a1bca07d46a00b0bfb  
selinux-policy-targeted-3.7.19-195.el6_4.3.noarch.rpm

Source:
10132a4de570253024de2ab642253c2a93221984e4dae4585968ebb27dc11a01  
selinux-policy-3.7.19-195.el6_4.3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net



--

Message: 3
Date: Mon, 11 Mar 2013 16:29:56 +
From: Johnny Hughes 
Subject: [CentOS-announce] CEBA-2013:0617  CentOS 5 kexec-tools Update
To: centos-annou...@centos.org
Message-ID: <20130311162956.ga21...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2013:

[CentOS] Where's crm (from pacemaker-cli) on CentOS 6.4?

[Antonio da Silva Martins Junior]

Hi,

   After upgrade the nodes on one of my HA clusters I find that "crm" isn't 
on the pacemaker-cli package. After some research on the web I find this:

http://www.gossamer-threads.com/lists/linuxha/pacemaker/84376?page=last

   That thread points to this OpenSuSE repo:

http://download.opensuse.org/repositories/network:/ha-clustering/RedHat_RHEL-6/

   Which suply the new "crm" from "CRM shell" project: 

http://savannah.nongnu.org/projects/crmsh/

   Then, after upgrade, put the new repo on, and install "crmsh".

   Hope this helps.

   Att.,

  Antonio.

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antonio S. Martins Jr. - Support Analyst | "Only The Shadow Knows |
| Universidade Estadual de Maringá - Brasil|   what evil lurks in the   |
| NPD - Núcleo de Processamento de Dados   |   Heart of Men!"   |
| E-Mail: asmart...@uem.br / sha...@uem.br | !!! Linux User: 52392 !!!  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 "Real Programmers don’t need comments — the code is obvious."

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 6.4 - yum update gives: Error: kernel conflicts with bfa-firmware

[Giles Coochey]

On 11/03/2013 16:55, Johnny Hughes wrote:

On 03/11/2013 08:30 AM, Tru Huynh wrote:

On Mon, Mar 11, 2013 at 01:24:17PM +, Giles Coochey wrote:

Yes - I use my own local repo and don't sync the 'os' part - I
assumed that was going to be static and only updated with 'updates'

you can't update to 6.4 from 6.3 with only updates, you MUST have 6.4/os and 
6.4/update

The os ([base]) part is unchanged during the 6.n lifetime, not during the 6.n 
-> 6.n+1.


In other words ... we just updated from CentOS-6.3 to CentOS-6.4 ... so
the OS directory and the UPDATES directories both changed ... so your
assumption is incorrect.

This is because, 6.4/os is not the same as 6.3/os.  Remember that the OS
directory is what is on the ISOs ... that obviously updates if we move
to a newer point release and release new ISOs.

You know what they say about assume :D

So I rsync'd with 6 os on the mirrors and everything works now. Thanks 
for clarifying.


--
Regards,

Giles Coochey, CCNP, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
gi...@coochey.net


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] what is "single spanned virtual disk" on RAID10????

[mcclnx mcc]

We have DELL R910 with H800 adapter in it.  several MD1220 connect to H800.

Since MD1220 have 24 hard disks in it.  When I configured RAID10, there is a 
choice call 'single spanned virtual disk"  (22 disks).

Can anyone tell me how "single spanned virtual disk" work?

Any document relate to it?

Thanks.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6.3 early panic on Xeon E3-1270V2 - CentOS 6.4 too

[Tilman Schmidt]

Having read that RHEL/CentOS 6.4 came with new VMware drivers I checked
whether this problem might perchance be fixed. It isn't.

In the meantime I got a report that Windows 8 (64 bit) showed a similar
problem.

So, updated problem matrix (ESXi build omitted as it has no influence):

ProcessorE5620E3-1230  E3-1270V2

Windows XP/2003/2008   ok   ok   ok

Windows 8   ??  Panic

CentOS 5.8 ok   ok   ok
2.6.18-308.13.1.el5

CentOS 6.2 ok   ok   ok(*)
2.6.32-220.7.1.el6.x86_64

CentOS 6.3 ok   ok  Panic
2.6.32-279.2.1.el6.x86_64

CentOS 6.4 ok   ok  Panic
2.6.32-358.0.1.el6.x86_64

(*) keyboard shows panic blink but system works fine otherwise

Reminder of the problem description: trying to boot a VM with
CentOS 6.3 or later on a VMware ESXi 4 host with a Xeon E3-1270V2
processor fails immediately after GRUB, with the VM locking up,
console message:

Sep 11 17:21:31.498: vmx| PANIC: early exception 0d rip
10:81038879 error 0 cr2 0

and ESXi log messages:

Sep 11 17:21:19.628: vcpu-0| RDMSR: unknown MSR[0x1a0] (read as zero):
rip=0x810388db count=1
Sep 11 17:21:19.628: vcpu-0| RDMSR: unknown MSR[0x1a0] (read as zero):
rip=0x810388db count=2
Sep 11 17:21:19.629: vcpu-0| X86Fault_Warning:
vmcore/vmm64/cpu/interp.c:427: cs:eip=0x10:0x81038879 fault=13
Sep 11 17:21:19.632: vcpu-0| Vix: [1125838 vmxCommands.c:9609]:
VMAutomation_HandleCLIHLTEvent. Do nothing.
Sep 11 17:21:19.632: vcpu-0| MsgHint: msg.monitorevent.halt (sent)
Sep 11 17:21:19.632: vcpu-0| The CPU has been disabled by the guest
operating system. Power off or reset the virtual machine.


-- 
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] sendmail stops accepting e-mail after sending 40 to 50 messages

[Alexander Dalloz]

Am 11.03.2013 09:30, schrieb pedro figueiredo:
> i have a centos box (vps) with sendmail and i'am using it to 
> send a newsletter to mail clients. 
> 
> I'am using a machine in my local network to send the e-mails 
> via SMTP (AUTH PLAIN) but after sending some e-mail (35 .. 50) 
> the connection starts to get closed by the server 
> (centos/sendmail)
> 
> I've searched google for a limit configuration on number of 
> e-mails in sendmail but didn't find anything.
> 
> any ideias on what configuration can i use to allow me to 
> send more e-mails?

Read your maillog. It will for sure tell you why the acceptance of mails
stops. Typically that is due to the load level. Sendmail comes with such
a feature which is configurable.

https://www.sendmail.com/sm/open_source/docs/m4/tweaking_config.html#confREFUSE_LA

Alexander


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT/HW] hardware raid -- comment/experience with 3Ware

[Arun Khan]

On Thu, Mar 7, 2013 at 12:07 AM, Gordon Messmer  wrote:
> On 03/06/2013 08:35 AM, Arun Khan wrote:
>
>> Any preference between 1 and 2 above.
>
> Based on about 10 years of running a hundred or so systems with 3ware
> controllers, I would say that you're better off with an LSI MegaRAID
> card, or with Linux software RAID.  3ware cards themselves have been the
> most problematic component of any system I've run in my entire
> professional career (starting in 1996).  Even very recent cards fail in
> a wide variety of ways, and there is no guarantee that if your array
> fails using a controller that you buy now that you'll be able to connect
> it to a controller that you buy later.

@ Gordon - thanks for sharing this piece of info!  In case of RAID
card failure, it is important to be able to recover the data (RAID
device) with a compatible replacement.Are the LSI MegaRAID
controller more reliable in this respect?

> At this point, I deploy almost exclusively systems running Linux with
> KVM on top of software RAID.  While I lose the battery backed write
> cache (which is great for performance unless you sustain enough writes
> to fill it completely, at which point the system grinds nearly to a
> halt), I gain a consistent set of management tools and the ability to
> move a disk array to any hardware that accepts the same form factor
> disk.  The reliability of my systems has improved significantly since I
> moved to software RAID.

Software RAID is an option but I don't think hot swap is possible
without some tinkering with the mdadm tool a priori.
The systems will go to client site (remote),  prefer to keep the
support calls to remove/replace hardware activity :(

Thanks,
-- Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos