Discuss May 2014

discuss@lists.centos.org

165 participants
146 discussions

files mysteriously changing ownership
by Tim Dunphy 07 May '14

07 May '14

We have a directory that holds the media for a website. We want that directory owned by the apache user and group. But for some reason that directory and all it's files keep reverting to being owned by a user account and group. [root@webservera ourwebsite]# ls -ld media/ drwxrwxr-x 163 user_a user_a_group 143360 Apr 29 13:29 media/ I have even setup a cron job to automate the ownership of this file to the right group to run every hour. 0 * * * * /bin/chown -R apache:apache /var/www/ourwebsite/media/ But every hour that directory keeps reverting to being owned by user_a and user_a_group. I've checked history files and crontabs for all users including root for rsync's and chowns. And I can find no evidence of what is causing this phenomenon of the directory automatically changing its' owner and group. How can I best investigate this in ways I haven't tried yet? The host in question is a CentOS 5.7 host. Thanks Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

3 4

centosplus kernel-debug
by Steve Clark 07 May '14

07 May '14

Hi, I am setting up crashkernel and was wondering where I get the kernel-debug rpm for centosplus kernels. Thanks, -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark(a)netwolves.com http://www.netwolves.com

3 4

CentOS-announce Digest, Vol 111, Issue 3
by centos-announce-request＠centos.org 07 May '14

07 May '14

1 0

Re: [CentOS] Opendkim and SELinux
by James B. Byrne 06 May '14

06 May '14

On Mon, May 5, 2014 11:48, Daniel J Walsh wrote: > > On 05/05/2014 11:22 AM, James B. Byrne wrote: >> CentOS-6.5 >> OpenDKIM-2.9.0 (epel) >> Postfix-2.6.6 (updates) >> >> I am trying to get opendkim working with our mailing lists. In the course >> of that endeavour I note that these messages are appearing in our syslog: >> >> >> May 4 20:50:02 inet08 setroubleshoot: SELinux is preventing >> /usr/sbin/opendkim from using the signull access on a process. For complete >> SELinux messages. run sealert -l 442cb257-3db2-488c-a92e-bfc936e16a0c >> . . . > Attaching the output of the sealert command or the audit.log would help. > FYI # grep dkim /var/log/audit/audit.log type=AVC msg=audit(1399250949.323:82972): avc: denied { signull } for pid=32289 comm="opendkim" scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=process type=SYSCALL msg=audit(1399250949.323:82972): arch=c000003e syscall=234 success=yes exit=0 a0=6932 a1=769f a2=0 a3=7f2264ff6110 items=0 ppid=26929 pid=32289 auid=0 uid=494 gid=493 euid=494 suid=494 fsuid=494 egid=493 sgid=493 fsgid=493 tty=(none) ses=5283 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399251319.711:82997): avc: denied { dac_override } for pid=327 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399251319.711:82997): arch=c000003e syscall=2 success=yes exit=3 a0=15aace7 a1=0 a2=1b6 a3=0 items=0 ppid=326 pid=327 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11446 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399254500.911:83137): avc: denied { dac_override } for pid=1326 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399254500.911:83137): arch=c000003e syscall=2 success=yes exit=3 a0=1161ce7 a1=0 a2=1b6 a3=0 items=0 ppid=1325 pid=1326 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11446 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399277028.540:84183): avc: denied { search } for pid=10770 comm="opendkim" name="/" dev=sysfs ino=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir type=AVC msg=audit(1399277028.540:84183): avc: denied { read } for pid=10770 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1399277028.540:84183): avc: denied { open } for pid=10770 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=SYSCALL msg=audit(1399277028.540:84183): arch=c000003e syscall=2 success=yes exit=20 a0=7ff020cd12b8 a1=80000 a2=2803ff a3=7fefff5fdba0 items=0 ppid=1329 pid=10770 auid=0 uid=494 gid=493 euid=494 suid=494 fsuid=494 egid=493 sgid=493 fsgid=493 tty=(none) ses=11446 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399300306.429:85270): auid=0 uid=494 gid=493 ses=11446 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=1331 comm="opendkim" sig=6 type=AVC msg=audit(1399300307.258:85271): avc: denied { dac_override } for pid=32612 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399300307.258:85271): arch=c000003e syscall=2 success=yes exit=3 a0=24b1d37 a1=0 a2=1b6 a3=0 items=0 ppid=32611 pid=32612 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399300584.801:85284): avc: denied { dac_override } for pid=488 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399300584.801:85284): arch=c000003e syscall=2 success=yes exit=3 a0=d28d37 a1=0 a2=1b6 a3=0 items=0 ppid=487 pid=488 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399301445.943:85340): avc: denied { dac_override } for pid=972 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399301445.943:85340): arch=c000003e syscall=2 success=yes exit=3 a0=25acd37 a1=0 a2=1b6 a3=0 items=0 ppid=971 pid=972 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399304087.588:85446): avc: denied { dac_override } for pid=3500 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399304087.588:85446): arch=c000003e syscall=2 success=yes exit=3 a0=908d37 a1=0 a2=1b6 a3=0 items=0 ppid=3499 pid=3500 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399304622.087:85517): avc: denied { search } for pid=3899 comm="opendkim" name="/" dev=sysfs ino=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir type=AVC msg=audit(1399304622.087:85517): avc: denied { read } for pid=3899 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1399304622.087:85517): avc: denied { open } for pid=3899 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=SYSCALL msg=audit(1399304622.087:85517): arch=c000003e syscall=2 success=yes exit=18 a0=7f8c877a92b8 a1=80000 a2=2803ff a3=7f8c6a1fbba0 items=0 ppid=3501 pid=3899 auid=0 uid=494 gid=493 euid=494 suid=494 fsuid=494 egid=493 sgid=493 fsgid=493 tty=(none) ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399305489.246:85560): avc: denied { dac_override } for pid=4711 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399305489.246:85560): arch=c000003e syscall=2 success=yes exit=3 a0=21c8db7 a1=0 a2=1b6 a3=0 items=0 ppid=4710 pid=4711 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399305489.250:85561): auid=0 uid=0 gid=0 ses=11755 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=4711 comm="opendkim" sig=11 type=AVC msg=audit(1399305583.965:85562): avc: denied { dac_override } for pid=4821 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399305583.965:85562): arch=c000003e syscall=2 success=yes exit=3 a0=21a5db7 a1=0 a2=1b6 a3=0 items=0 ppid=4820 pid=4821 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399305583.970:85563): auid=0 uid=0 gid=0 ses=11755 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=4821 comm="opendkim" sig=11 type=AVC msg=audit(1399306005.965:85609): avc: denied { dac_override } for pid=5210 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399306005.965:85609): arch=c000003e syscall=2 success=yes exit=3 a0=896db7 a1=0 a2=1b6 a3=0 items=0 ppid=5209 pid=5210 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=11755 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399306007.204:85610): auid=0 uid=494 gid=493 ses=11755 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=4859 comm="opendkim" sig=6 type=ANOM_ABEND msg=audit(1399308116.940:85723): auid=0 uid=494 gid=493 ses=11755 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=5324 comm="opendkim" sig=6 type=AVC msg=audit(1399308117.051:85724): avc: denied { dac_override } for pid=6402 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399308117.051:85724): arch=c000003e syscall=2 success=yes exit=3 a0=1f55db7 a1=0 a2=1b6 a3=0 items=0 ppid=6401 pid=6402 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=11813 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399313980.345:86053): avc: denied { dac_override } for pid=9683 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399313980.345:86053): arch=c000003e syscall=2 success=yes exit=3 a0=6ebdb7 a1=0 a2=1b6 a3=0 items=0 ppid=9682 pid=9683 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=11842 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399313981.617:86054): auid=0 uid=494 gid=493 ses=11813 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=6407 comm="opendkim" sig=6 type=AVC msg=audit(1399314071.098:86061): avc: denied { dac_override } for pid=9748 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399314071.098:86061): arch=c000003e syscall=2 success=yes exit=3 a0=f42db7 a1=0 a2=1b6 a3=0 items=0 ppid=9747 pid=9748 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=11842 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=AVC msg=audit(1399316862.527:86239): avc: denied { dac_override } for pid=13015 comm="opendkim" capability=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=unconfined_u:system_r:dkim_milter_t:s0 tclass=capability type=SYSCALL msg=audit(1399316862.527:86239): arch=c000003e syscall=2 success=yes exit=3 a0=e4ddb7 a1=0 a2=1b6 a3=0 items=0 ppid=13014 pid=13015 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=11842 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) type=ANOM_ABEND msg=audit(1399316863.171:86240): auid=0 uid=494 gid=493 ses=11842 subj=unconfined_u:system_r:dkim_milter_t:s0 pid=9753 comm="opendkim" sig=6 type=AVC msg=audit(1399322293.847:86503): avc: denied { search } for pid=19335 comm="opendkim" name="/" dev=sysfs ino=1 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir type=AVC msg=audit(1399322293.847:86503): avc: denied { read } for pid=19335 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1399322293.847:86503): avc: denied { open } for pid=19335 comm="opendkim" name="online" dev=sysfs ino=23 scontext=unconfined_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=SYSCALL msg=audit(1399322293.847:86503): arch=c000003e syscall=2 success=yes exit=18 a0=7f202bbd82b8 a1=80000 a2=2803ff a3=7f200ebfcba0 items=0 ppid=13066 pid=19335 auid=0 uid=494 gid=493 euid=494 suid=494 fsuid=494 egid=493 sgid=493 fsgid=493 tty=(none) ses=11842 comm="opendkim" exe="/usr/sbin/opendkim" subj=unconfined_u:system_r:dkim_milter_t:s0 key=(null) The sealerts are no longer available for some reason. sealert -l 442cb257-3db2-488c-a92e-bfc936e16a0c Error query_alerts error (1003): id (442cb257-3db2-488c-a92e-bfc936e16a0c) not found -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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

1 0

CentOS-announce Digest, Vol 111, Issue 2
by centos-announce-request＠centos.org 06 May '14

06 May '14

Send CentOS-announce mailing list submissions to centos-announce(a)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-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)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-2014:0466 CentOS 6 perl-Crypt-SSLeay FASTTRACK Update (Johnny Hughes) 2. CEBA-2014:0468 CentOS 6 ethtool Update (Johnny Hughes) 3. CEBA-2014:0467 CentOS 6 spice-gtk Update (Johnny Hughes) 4. CEBA-2014:0465 CentOS 6 device-mapper-persistent-data Update (Johnny Hughes) 5. CEBA-2014:0470 CentOS 6 nss_db Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 May 2014 11:15:04 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0466 CentOS 6 perl-Crypt-SSLeay FASTTRACK Update To: centos-announce(a)centos.org Message-ID: <20140505111504.GA8978(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0466 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0466.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: e0f1b658d20235c12112356d66a43b89f5b95bb1db55b3b5284ce7b22ee493eb perl-Crypt-SSLeay-0.57-17.el6.i686.rpm x86_64: 6e5489afca2c1cfeeeab73e9aeb2e5f90503f2383461172f972d0296a3e7ce62 perl-Crypt-SSLeay-0.57-17.el6.x86_64.rpm Source: b91a3a300402567966e896c6fe22e5523efbc5a6dce04a9f2e7749c158fc0400 perl-Crypt-SSLeay-0.57-17.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Mon, 5 May 2014 11:16:46 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0468 CentOS 6 ethtool Update To: centos-announce(a)centos.org Message-ID: <20140505111646.GA9178(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0468 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0468.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: c3d7618a65c081bd8bc6daddf9c708b79acf19183a5cb1cb9a09dc918dce9937 ethtool-3.5-1.4.el6_5.i686.rpm x86_64: d96a3b937287a15b7686d29ac84f5a88bafd6573cfb8e7ea8da678c46d41b011 ethtool-3.5-1.4.el6_5.x86_64.rpm Source: 4447f03d471f3c875a766e236f3bb7ae5ac48b46aa7e78f9d8e8950aa83135ba ethtool-3.5-1.4.el6_5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Mon, 5 May 2014 11:18:06 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0467 CentOS 6 spice-gtk Update To: centos-announce(a)centos.org Message-ID: <20140505111806.GA9519(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0467 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0467.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: dcf81b9b26c7938f26faa899c26b60111d1e68417df3d1a23dad39e503860b33 spice-glib-0.20-11.el6_5.1.i686.rpm bd70640a2b23c3e099861776c840846a1cd41b13a43a0233fb1e4e3c5d7eb33a spice-glib-devel-0.20-11.el6_5.1.i686.rpm ebfa5631a57e3c0dc3f02b7c07662f5d01b649cde82334face7ba8e3380d7e98 spice-gtk-0.20-11.el6_5.1.i686.rpm 60082305be76ba1c857e1a6ca739c7a6e9791dba9fd7a5da155b8d763fe55adb spice-gtk-devel-0.20-11.el6_5.1.i686.rpm 351258290b803aae61b85b9b8741768251762c8cb1bbef2ac825787f996e5763 spice-gtk-python-0.20-11.el6_5.1.i686.rpm 2f97cf00201d9ddf6a86a795a27c2d771259d5ae1e001b58e6b57e1110b72249 spice-gtk-tools-0.20-11.el6_5.1.i686.rpm x86_64: dcf81b9b26c7938f26faa899c26b60111d1e68417df3d1a23dad39e503860b33 spice-glib-0.20-11.el6_5.1.i686.rpm 9ba085cd8d5fc6030a66b475a1a56cb4846a0e88ec7f3ce264dfef411e05459e spice-glib-0.20-11.el6_5.1.x86_64.rpm bd70640a2b23c3e099861776c840846a1cd41b13a43a0233fb1e4e3c5d7eb33a spice-glib-devel-0.20-11.el6_5.1.i686.rpm 5c19ff3c5dec894c7d1f21d8549e721465d35342c56a350e812e73c4be4535bb spice-glib-devel-0.20-11.el6_5.1.x86_64.rpm ebfa5631a57e3c0dc3f02b7c07662f5d01b649cde82334face7ba8e3380d7e98 spice-gtk-0.20-11.el6_5.1.i686.rpm d19b714a535f0e11d8377cf62c592350f8d1e0efc0370ea23a7bbeda1c05eba5 spice-gtk-0.20-11.el6_5.1.x86_64.rpm 60082305be76ba1c857e1a6ca739c7a6e9791dba9fd7a5da155b8d763fe55adb spice-gtk-devel-0.20-11.el6_5.1.i686.rpm 4e0c146b9b5be0d6e4cd9d44f67211ed3c29f309957b3796233532ff81481957 spice-gtk-devel-0.20-11.el6_5.1.x86_64.rpm e34358ea4db112d28d72bade7b7d281f1da180bc692c74361ae10d2d270684fb spice-gtk-python-0.20-11.el6_5.1.x86_64.rpm 8f45dbc12cc73f13654abc2d459d81a575c2791c48f545795b95430e468e10af spice-gtk-tools-0.20-11.el6_5.1.x86_64.rpm Source: 310380162b9ec071da49b02ac14ce9d01fe373bd70f291d0badd5fa54e7a8b78 spice-gtk-0.20-11.el6_5.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Mon, 5 May 2014 11:20:04 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0465 CentOS 6 device-mapper-persistent-data Update To: centos-announce(a)centos.org Message-ID: <20140505112004.GA9732(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0465 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0465.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: a166e6475d8a35e62f4c0a090c6cc5a84d1b69005d6dc51941d237fc91eb2f99 device-mapper-persistent-data-0.2.8-4.el6_5.i686.rpm x86_64: fdf161bb4e44862fca78156c7fe7e6aac66cc00e8178117615b3f38dfd09949e device-mapper-persistent-data-0.2.8-4.el6_5.x86_64.rpm Source: d7e6602fe31d7087f4bbb058b0bd7d6a2ae28251061079377658f0a7a93b4db4 device-mapper-persistent-data-0.2.8-4.el6_5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 5 Date: Mon, 5 May 2014 14:40:53 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0470 CentOS 6 nss_db Update To: centos-announce(a)centos.org Message-ID: <20140505144053.GA20450(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0470 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0470.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: be100ec1fc9689cea7c8ffdbad8d85b278bdecd36bca8d34c86c78d5c0eec38a nss_db-2.2.3-0.5.pre1.el6_5.1.i686.rpm x86_64: be100ec1fc9689cea7c8ffdbad8d85b278bdecd36bca8d34c86c78d5c0eec38a nss_db-2.2.3-0.5.pre1.el6_5.1.i686.rpm 0db7c505a55e377346f37c965553dd2f30ce800d40d240df6fc18d7d41f675d8 nss_db-2.2.3-0.5.pre1.el6_5.1.x86_64.rpm Source: 5449a63262a8e32e97e3ad286cb34c8798a1be1d013bd356e38ac622e8f9ced1 nss_db-2.2.3-0.5.pre1.el6_5.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 111, Issue 2 ***********************************************

1 0

kvm libvirt vms import
by Alessandro Baggi 06 May '14

06 May '14

Hi there, I'm new to Centos. I've installed version 6.5 x86_64. I'm coming from slackware/debian utilizzation environment. I'm trying to setup libvirt and qemu-kvm, but I have some problems. I've different vms (2 centos, 2 slackware, 3 Debian) and I'm trying to import all of them. I want prefix that all of them was created from debian host and vdisk had bus=sata and format=qcow2. Importing debian I've no problem with the following command: # virt-install -n DEB -r 1024 --vcpus=2 --accelerate --os-type=linux --os-variant=debianwheezy --disk path=/path/to/deb.img,format=qcow2,bus=ide,cache=writeback --import --network=bridge:br0 --vnc -v It starts and works fine. Importing Centos 6.5 with the following command: # virt-install -n CENT1 -r 1024 --vcpus=2 --os-type=linux --os-variant=rhel6 --accelerate --disk path=/path/to/cent.img,format=qcow2,bus=ide,cache=writeback --import --network=bridge:br0 --vnc -v return an error: Starting install... ERROR errore interno Process exited while reading console log output: char device redirected to /dev/pts/3 qemu-kvm: -drive file=/mnt/dati/qemu-system/CENTOS1/cent.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback: 'drive-ide0-0-0' uses a qcow2 feature which is not supported by this qemu version: QCOW version 3 qemu-kvm: -drive file=/mnt/dati/qemu-system/CENTOS1/cent.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback: could not open disk image /mnt/dati/qemu-system/CENTOS1/cent.img: Operation not supported Domain installation does not appear to have been successful. I've tried also to remove disk options and set to virtio,scsi. It starts but says "no bootable disk". The same happens with slackware 14.1 without --os-type and --os-variant. Always, trying delete cent.img and recreate it, all works with the same option (but is not so good, because I must reinstall all). On my new centos installation I have qemu-kvm-0.12.1.2, on the last Slackware system I had qemu-1.7.0 and on Debian 1.1.2+dfsg-6+deb7u2. I've also tried to reimport them on another system with Slackware and have no problem. Maybe there is a problem with version of qemu-kvm tools or some problem with img. It's possible? I can't get the real problem. Can someone point me in the right direction? Thanks in advance.

1 1

KVM Linux Guest Resolution only 1024x768
by Chris 06 May '14

06 May '14

Dear All, I'm trying to install a Debian Wheezy KVM guest on a CentOS 6.4 Host. The only resolutions supported are 1024x768 or 800x600. I increased the video RAM to 500 MB, but the guest still says: [ 10.321] (II) CIRRUS(0): Not using default mode "1920x1200" (insufficient memory for mode) Only 32 MB are recognized: 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc Device 1100 Physical Slot: 2 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M] Region 1: Memory at f2000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at f2010000 [disabled] [size=64K] How can I increase the resolution? Are any guest modifications necessary? -- Christian

2 2

Terminal settings
by Ashley M. Kirchner 05 May '14

05 May '14

So this has been bugging me for a few years now and I can always "fix" the problem, but I don't know if that's actually the correct way. So the issue is terminal emulation. I use Secure CRT (vandyke.com) to connect to any and all of my servers through SSH. Whether the terminal is set to 'linux' or 'xterm' makes no difference, I always get this output when I run a 'tree' command (and others that have some sort of graphical output): [13] 05:04:53 <root@brasco:~> tree rpmbuild/ rpmbuild/ â”â”€â”€ BUILD â”‚Â Â â””â”€â”€ ncftp-3.2.5 â”‚Â Â â”â”€â”€ autoconf_local â”‚Â Â â”‚Â Â â”â”€â”€ acconfig.h â”‚Â Â â”‚Â Â â”â”€â”€ aclocal.m4 â”‚Â Â â”‚Â Â â””â”€â”€ aclocal.m4.ncursesw â”‚Â Â â”â”€â”€ bin â”‚Â Â â”‚Â Â â”â”€â”€ ncftp â”‚Â Â â”‚Â Â â”â”€â”€ ncftpbatch â”‚Â Â â”‚Â Â â”â”€â”€ ncftpbookmarks â”‚Â Â â”‚Â Â â”â”€â”€ ncftpget â”‚Â Â â”‚Â Â â”â”€â”€ ncftpls â”‚Â Â â”‚Â Â â”â”€â”€ ncftpput â”‚Â Â â”‚Â Â â””â”€â”€ ncftpspooler -> ncftpbatc Now, the way I fix that is by changing the LANG setting. By default it's set to 'en_US.UTF-8' right after a fresh install. If I change that to simply 'en_US', then I get the output I'm expecting: [16] 05:06:14 <root@brasco:~> tree rpmbuild/ rpmbuild/ |-- BUILD | `-- ncftp-3.2.5 | |-- autoconf_local | | |-- acconfig.h | | |-- aclocal.m4 | | `-- aclocal.m4.ncursesw | |-- bin | | |-- ncftp | | |-- ncftpbatch | | |-- ncftpbookmarks | | |-- ncftpget | | |-- ncftpls | | |-- ncftpput | | `-- ncftpspooler -> ncftpbatch ... So my question is: why is that? Why would the default setting not work? Is it actually something that I need to be doing on the server (like changing the LANG setting), or is it with SecureCRT? And if so, can anyone give me any suggestions of what I need to be looking for and change? Like I said, it's been a couple of years and it's never a big deal since I know what to do to sort of fix the problem. Thanks.

4 8

Ulimit problem - CentOS 5.10
by Nathan Duehr 05 May '14

05 May '14

Running across some curious stuff with ulimit on CentOS 5.10. We have a non CentOS packaged version of Asterisk (using their packages) that we start at boot time with a typical RC script. Recently it started whining that it couldn't open enough file handles. As we dug further into this, it appears that at boot time, it inherits ulimit from init, which is pretty low: 1024. We've set /etc/security/limits.conf and sysctl significantly higher both for root/system wide and also for the user Asterisk runs under, to no avail. If we log in via ssh as root (or sudo) the correct root/system-wide ulimit of 8192 is set. Looking in /proc/[PID]/limits shows the lower ulimit only if the package is started from init (standard rc3.d type sysV stuff...). If we restart it via console, remote ssh, anything else, the limit bumps to 8196. Attempting to force the ulimit up inside the RC script has no effect, since the package is running as a non-root user. It fails to raise the limit. Right now, we're not totally against just taking it out of the startup and starting it manually anyway, since we really don't want the Asterisk platform coming up after a crash/reboot anyway, and any other reboots there will always be a human involved, but the way init is handling ulimit seems utterly retarded and broken. Some indication (different engineer found it, I haven't seen the RHEL case number) appears to indicate that folks wanted init ulimited heavily in case of startup DDoS type stuff, but we haven't figured out a semi-sane unix-conventional type way AROUND this when it's needed that if we were hit by the proverbial bus, a "normal" unix guy would find. Perhaps we're missing something. Thoughts? -- Nate Duehr denverpilot(a)me.com

5 10

Re: [CentOS] Disappearing Network Manager config scripts
by Les Mikesell 05 May '14

05 May '14

On Thu, May 1, 2014 at 5:54 AM, Steve Clark <sclark(a)netwolves.com> wrote: > On 04/30/2014 02:41 PM, Les Mikesell wrote: > > On Wed, Apr 30, 2014 at 1:28 PM, Steve Clark <sclark(a)netwolves.com> wrote: > > So, have you ever had to deal with a CentOS box and multiple NICs. > Especially one where you've cloned it or moved a disk to a new > chassis? Apparently there is just not a good way to identify > interfaces. > > Yep, do it all the time - first two thing I do are: > rm -f /etc/udev/rules.d/70-persistent-net.rules > rm -r /etc/sysconfig/network-scripts/ifcfg-eth* > and then reboot. > > So, now you've got 6 NICs connected to 6 different switches. Which > name is which? This is a really fun exercise when the box is remote > and you are trying to tell someone used to configuring windows systems > how to get it to a point where you can ssh in. > > I guess I am confused, you haven't ever worked with the hardware you are > installing the cloned > drive in? If that is true then I guess you have a problem. > "Working with it" doesn't matter. And network manager or not doesn't matter. Interfaces get named in a random order unless it is a Dell with the netbios naming scheme and probably then only for the motherboard NICs. Our servers generally have on-board Broadcomm and Intel cards and the names within a set may stay ordered, but the cards and motherboards will flip randomly if there are not already matching items with the correct MAC addresses in the udev rulss file (in 6.x, in 5.x having a matching MAC in the ifcfg-eth? file was enough to rename the device to match). This is just a response to your comment about windows names being difficult to know, (and a long-standing problem on its own) and doesn't relate much to the NetworkManager discussion. If you only have one (or maybe even a pair on the motherboard or a single card) you might always see the same ordering - if so consider yourself lucky because that is not the general case. We usually have to run through a drill like 'ip link ls' to get a list of interface names, then iterate through them with 'ifconfig up' and use ethtool to see which has link up, connecting one at a time. So, in my opinion, there are problems with the old system that need to be fixed, but they aren't the things that networkmanager does. A way to restore a backup to an identical machine and have the same NICs in the same positions get the old configurations would be nice. Or at least to know the names of the NICs in the same positions. (And if you go back to CentOS3 they did - detection was single threaded back then and would always probe in the same order). -- Les Mikesell lesmikesell(a)gmail.com

5 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss May 2014