- Discuss - lists.centos.org

KISS networking with CentOS 7
by Niki Kovacs 10 Feb '15

10 Feb '15

Hi, I'm currently experimenting with CentOS 7 on a couple of installations. I'm reasonably proficient with CentOS 5.x and 6.x. I'd like to manage networking using a more traditional approach (Keep It Simple Stupid). Here's what I tried so far, starting from a minimal install: Install net-tools (to be able to use ifconfig). Get rid of NetworkManager: # yum remove NetworkManager* Add 'net.ifnames=0' and 'biosdevname=0' to kernel boot options to name interfaces eth0, eth1, etc. Edit '/etc/sysconfig/network-scripts/ifcfg-eth{0,1}' like I did under previous versions. Eventually, edit '/etc/udev/rules.d/70-persistent-net.rules' to switch interfaces: # /etc/udev/rules.d/70-persistent-net.rules # # eth0 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:1e:c9:42:84:7b", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth0" # eth1 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:30:f1:6a:2f:40", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth1" So far, no way to bring either eth0 or eth1 up. What am I doing wrong here? Is NetworkManager now a mandatory part of the base system? Some other mistake somewhere else? I'm a bit puzzled here. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

1 1

Re: [CentOS] SELinux context for ssh host keys?
by James B. Byrne 10 Feb '15

10 Feb '15

On Tue, February 10, 2015 04:18, Andrew Holway wrote: > On 10 February 2015 at 06:32, Mark Tinberg <mark.tinberg(a)wisc.edu> > wrote: > >> >> > On Feb 9, 2015, at 12:27 PM, Robert Nichols >> <rnicholsNOSPAM(a)comcast.net> >> wrote: >> > >> > On 02/09/2015 11:14 AM, James B. Byrne wrote: >> >> So, I decided to run restorecon -v to >> >> >> ... >> >> restorecon reset /etc/ssh/ssh_host_rsa_key_4096 context >> >> unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0 >> > > Why are you putting your SSH key in /etc/ ? > > With SELinux its normally better to go with the flow. find out which > directories have the desired label and keep your objects in there. > > I'm guessing in this case ~/.ssh/ > > -- *** 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

2 2

Gnome-3 - can't drag menu items out
by Les Mikesell 10 Feb '15

10 Feb '15

I've mostly been using MATE from epel when I use GUI access on CentOS7 because it works with x2go, but just noticed on a system with Gnome3 that I can't drag items out of the menus to the desktop or top bar for easier access. Is there some way to make the desktop space useful for more than pretty wallpaper? -- Les Mikesell lesmikesell(a)gmail.com

2 2

Packages installation in CentOs
by Venkateswara Rao Dokku 10 Feb '15

10 Feb '15

Hi, I have a customized CentOS 5.5 kernel. I want it to upgrade it to CentOS 7. The approach I have decided was to take the CentOS 7 and then install the customized packages that are there in the CentOS 5.5. While trying to install the customized packages, I could install most of the packages, but I couldn't install the below in the latest CentOS 7. 1. rhpl 2. mod_perl 3. notification-daemon 4. vixie-cron 5. kudzu 6. redhat-lsb 7. mod_pyton 8. webalizer 9. pam_ccreds 10. libnotify 11. irda_utils 12. readahead 13. Mkinitrd 14. Alchemist 15. Cadevar 16. sustem-config-network-tui 17. firstboot-tui I tried to install the above packages as other packages using *YUM*, it is complaining that no such package. So I tried installing them by rpm's. But, installing rpm's giving "failed dependencies" error. Can you please suggest best way to install the above listed packages on CentOs 7? Are the packages listed above deprecated for CentOS 7 or merged into some other packages? Thanks for the help. -- Thanks & Regards, Venkateswara Rao Dokku.

3 4

SELinux context for ssh host keys?
by James B. Byrne 10 Feb '15

10 Feb '15

I generated a new host key for one of our systems using: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key_4096 I then ran 'ls -Z on the keys' ll -Z *key* -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_dsa_key -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_dsa_key.pub -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_key -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_key.pub -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_rsa_key -rw-------. root root unconfined_u:object_r:sshd_key_t:s0 ssh_host_rsa_key_4096 -rw-r--r--. root root unconfined_u:object_r:sshd_key_t:s0 ssh_host_rsa_key_4096.pub -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_rsa_key.pub As it seems odd, to me, that all the other files had a system_u user while the new had unconfined_u. So, I decided to run restorecon -v to presumably set the SELinux user correctly for the new keys: But that is not what happened: restorecon -v * restorecon reset /etc/ssh/ssh_host_rsa_key_4096 context unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0 restorecon reset /etc/ssh/ssh_host_rsa_key_4096.pub context unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0 As you can see, not only did the user not get set to system_u but the type was changed to etc_t. Why were the new key files changed from sshd_key_t types to the generic etc_t types? Why was the user not changed in either case from unconfined_u to system_u or vice versa? There is no REQUIREMENT that a host key have a particular file name is there? The sshd_config provides for setting one explicitly and doing so seems to cause no problems with ssh connections that I have yet encountered. -- *** 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

4 3

Recommendations for good CentOS 7 documentation
by Niki Kovacs 09 Feb '15

09 Feb '15

Hi, I'm looking for recommendations for documentation about the specificities of RHEL/CentOS 7.x. It can be either online or in printed book format, and I'm fluent in german, french and english. I have a good books about 5.x: "RHEL 5 Unleashed" from Sams, "Foundations of CentOS Linux" and "The Definitive Guide to CentOS", both from Apress. Can anyone recommend anything similar on 7.x? Cheers from South France, Niki Kovacs -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

4 5

Another Fedora decision
by Scott Robbins 09 Feb '15

09 Feb '15

So, probably some of you, at least, follow Fedora, perhaps in part to see what new desktop user oriented decision will make it into the next version of RHEL/CentOS. You may have noticed how if Fedora, by some odd scheme, deems your password unworthy, you have to click Done two times. So, the latest Ananconda takes this one step further. Passwords that the system considers weak will no longer be allowed. While this will probably only be a minor inconvenience, (add 3 bangs to the end or something equally meaningless), a few on the fedora-testing list, including myself, think it's just one more solution seeking a problem. At present, I don't know where one can lodge a protest. Hopefully, someone will care enough to file a bugzilla RFE. Others may think it's a great idea--at last, users can't install with a password of 1234. Anyway, as part of their push for it is that no one minds it, thought I'd mention it here, as many of the desktop oriented decisions get into Fedora, then into RH and it's already too late. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

12 15

reboot - is there a timeout on filesystem flush?
by Les Mikesell 09 Feb '15

09 Feb '15

I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that fragile? -- Les Mikesell lesmikesell(a)gmail.com

9 19

lost at 'repository' entry installing centos7
by g 08 Feb '15

08 Feb '15

greetings. while attempting to install c7, i got lost at 'repository' entry. i canceled, loaded centos.org, looked for help for installing c7, but did not find. i know, i did not look in right place. if such has been posted, i missed. so what/where is 'the right place'? much appreciate some help. -- peace out. in a world with out fences, who needs gates. CentOS GNU/Linux 6.6 tc,hago. g .

5 13

anthem details
by Chris Wensink 08 Feb '15

08 Feb '15

Hello Everyone, Does anyone have any more detail about what kind of system Anthem / Blue Cross was running and what kind of attack broke into their system? It's terrible that it happened, but I think it would benefit all Admins everywhere to learn how it happened so that we can secure our systems from a similar breach of information. Anyone know? Chris

8 9

CentOS-announce Digest, Vol 120, Issue 3
by centos-announce-request＠centos.org 07 Feb '15

07 Feb '15

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. CEEA-2015:0141 CentOS 5 tzdata Enhancement Update (Johnny Hughes) 2. CEEA-2015:0141 CentOS 6 tzdata Enhancement Update (Johnny Hughes) 3. CEEA-2015:0141 CentOS 7 tzdata Enhancement Update (Johnny Hughes) 4. CESA-2015:X003 kernel Xen4CentOS Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Fri, 6 Feb 2015 18:04:27 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEEA-2015:0141 CentOS 5 tzdata Enhancement Update Message-ID: <20150206180427.GA5336(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2015:0141 Upstream details at : https://rhn.redhat.com/errata/RHEA-2015-0141.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 44a9932b22ec57dae5c56e3442e6e31e9190e34083358f64600b71798e5b0853 tzdata-2015a-1.el5.i386.rpm 18985fa3cc78d13ab79b081a6836c4648e898587c52e6c74dc5301f437fef77e tzdata-java-2015a-1.el5.i386.rpm x86_64: 7c23500ec921b8a55837c4cf5a3d7f4a13d0d759dd4a45b993c5660e092819ea tzdata-2015a-1.el5.x86_64.rpm c1a4dc3190482b0d204341fb34f66c40aeb37fa3f9dec0b003835faf6e139455 tzdata-java-2015a-1.el5.x86_64.rpm Source: 43cb09a77bb5d0ed7cdee1b4dc3f3048ee486d1c67c4fa3dee45dbd0db036550 tzdata-2015a-1.el5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Fri, 6 Feb 2015 18:13:00 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEEA-2015:0141 CentOS 6 tzdata Enhancement Update Message-ID: <20150206181300.GA59340(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2015:0141 Upstream details at : https://rhn.redhat.com/errata/RHEA-2015-0141.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 0eed49ffbfe3a3af9e29e74072531a567cb05578f3050380f04df7e28c093ff7 tzdata-2015a-1.el6.noarch.rpm 4a23515cf9b03dcde28bbf82f516cbd9609433d41d53da53778f3e3cf792c407 tzdata-java-2015a-1.el6.noarch.rpm x86_64: 0eed49ffbfe3a3af9e29e74072531a567cb05578f3050380f04df7e28c093ff7 tzdata-2015a-1.el6.noarch.rpm 4a23515cf9b03dcde28bbf82f516cbd9609433d41d53da53778f3e3cf792c407 tzdata-java-2015a-1.el6.noarch.rpm Source: dc7dc3c9fb0dc563879803d4d6bf14bb84910d12a21905e878a816849fe32ebd tzdata-2015a-1.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Fri, 6 Feb 2015 18:44:54 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEEA-2015:0141 CentOS 7 tzdata Enhancement Update Message-ID: <20150206184454.GA4732(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2015:0141 Upstream details at : https://rhn.redhat.com/errata/RHEA-2015-0141.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 921a3e9d60400d5fff290f41d5c3a8290893efdf82916dd25ba4fedf43704d6e tzdata-2015a-1.el7_0.noarch.rpm 697a93ca1f89d37f62f8dec3148a9f6416951a13b1180838cd0a13b6273d53b8 tzdata-java-2015a-1.el7_0.noarch.rpm Source: e83a3cfd7f10e75c194ef53d63e661b9494ffa4799d494ee0b7d5aaed4e120b0 tzdata-2015a-1.el7_0.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Fri, 6 Feb 2015 19:41:13 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:X003 kernel Xen4CentOS Security Update Message-ID: <20150206194113.GA7620(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii The following packages are updated for Xen4CentOS for CentOS 6: Source: 91e65bf3d0bd8586fbbfcac77ecc7b677ef3582acd8ac11893c71d511edb59cb e1000e-2.5.4-3.10.68.2.el6.centos.alt.src.rpm d2019ca40e3d4beb2c7a55ed8bfd7bb0295d9028726f71bf6dff1389d79ae5cd kernel-3.10.68-11.el6.centos.alt.src.rpm x86_64: be570bc1212273433fb7df1c4f1a7b5ba471db9a61c78b88756f306528847138 e1000e-2.5.4-3.10.68.2.el6.centos.alt.x86_64.rpm 0ea9ea9afa93d26f6e28635b060295d76a7b090e44ea64124f375036db055ab0 kernel-3.10.68-11.el6.centos.alt.x86_64.rpm 58a36c6314dabe487165538f508de60e57429c328263113d152cc324daf5a483 kernel-devel-3.10.68-11.el6.centos.alt.x86_64.rpm f7c24fb8439b505ca1af7c43bc6803721a055c82d5cf0d167a78e2271c610dae kernel-doc-3.10.68-11.el6.centos.alt.noarch.rpm 9c282481f31b4761e6f4b8b0091b96331cd1a5dbb2f135db110289caab4fcc1b kernel-firmware-3.10.68-11.el6.centos.alt.noarch.rpm c59984f2f5d635eec7362ee60ad63262e7dd133fbee1b7094f99f722547c983e kernel-headers-3.10.68-11.el6.centos.alt.x86_64.rpm 35a21a2eea7e4f4a8ea11bfe349068ec1b84d579cbd2c852d8d453533aa43a20 perf-3.10.68-11.el6.centos.alt.x86_64.rpm ======================================================================== These updates address the following issues: e1000e: Just a rebuild of the module for the new kernel. ======================================================================== Kernel: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.64 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.65 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.66 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.67 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.10.68 Kernel CVE's: CVE-2014-8134, CVE-2014-8989, CVE-2014-9529 -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos at 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 120, Issue 3 ***********************************************

1 0

Re: [CentOS] anthem details OT
by Tom Bishop 06 Feb '15

06 Feb '15

On Fri, Feb 6, 2015 at 8:17 AM, Chris Wensink < cwensink(a)five-star-plastics.com> wrote: > Hello Everyone, > > Does anyone have any more detail about what kind of system Anthem / Blue > Cross was running and what kind of attack broke into their system? > > It's terrible that it happened, but I think it would benefit all Admins > everywhere to learn how it happened so that we can secure our systems from > a similar breach of information. > > Anyone know? > > Chris > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > This is pretty much off topic but I do wish we could have a infosec related mail list I think that would be a good idea. >From what I have read this morning it appears to be an APT, should know more in the coming days and weeks but most times with APT's details will be slow coming. Here are some sites that you may want to look at: http://krebsonsecurity.com/ http://securelist.com/blog/research/ http://www.csoonline.com/author/Steve-Ragan/ http://blog.crowdstrike.com/ This one will be interesting in a few weeks: http://www.csoonline.com/article/2880095/cyber-attacks-espionage/crowdstrik…

1 0

CentOS-announce Digest, Vol 120, Issue 2
by centos-announce-request＠centos.org 06 Feb '15

06 Feb '15

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-2015:0129 CentOS 6 device-mapper-multipath BugFix Update (Johnny Hughes) 2. CEBA-2015:0130 CentOS 6 resource-agents BugFix Update (Johnny Hughes) 3. CEBA-2015:0123 CentOS 6 xorg-x11-server BugFix Update (Johnny Hughes) 4. CESA-2015:0118 Moderate CentOS 7 mariadb Security Update (Johnny Hughes) 5. CEEA-2015:0122 CentOS 7 resource-agents Enhancement Update (Johnny Hughes) 6. CEBA-2015:0131 CentOS 7 libvirt BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 Feb 2015 13:59:29 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0129 CentOS 6 device-mapper-multipath BugFix Update Message-ID: <20150205135929.GA63487(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0129 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0129.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: a50f6c4932fdf9d035576570d981131142bbadcd65741393c30897273253a0eb device-mapper-multipath-0.4.9-80.el6_6.3.i686.rpm 8c66823188be42a06e0725d1721314ccb33d09f701f006afabea0cac304523d9 device-mapper-multipath-libs-0.4.9-80.el6_6.3.i686.rpm 41db17f1ee29ecf64e69670d6b69be517bcdf74f3d4b3327e313468deb78a9fb kpartx-0.4.9-80.el6_6.3.i686.rpm x86_64: 29128315b4a8b219f9db11277fba2775033e473cb93ad37b716bad8084566279 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64.rpm 8c66823188be42a06e0725d1721314ccb33d09f701f006afabea0cac304523d9 device-mapper-multipath-libs-0.4.9-80.el6_6.3.i686.rpm e441885d3aadb68fd2054ad47e5347ac382509379735036c6c70e424b96ce55f device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64.rpm 402a73ef2ac94a4c61ea0f5078c7e6255f86d5c0d490b1341abcb63a7db1d227 kpartx-0.4.9-80.el6_6.3.x86_64.rpm Source: 8c32f972a4afea74c8362d6e75747eb147314f0e37bcb6b890c2a996ad8372a8 device-mapper-multipath-0.4.9-80.el6_6.3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Thu, 5 Feb 2015 14:00:09 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0130 CentOS 6 resource-agents BugFix Update Message-ID: <20150205140009.GA63706(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0130 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0130.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 042e4525d919eefcb11ddd40daf3f8b36bfd36835c541d4d9d9559fb93f1ffed resource-agents-3.9.5-12.el6_6.3.i686.rpm x86_64: 2ddf1fa020816a97162c1ef712a2faa93ba927a83a8a5143447c139501afcb9f resource-agents-3.9.5-12.el6_6.3.x86_64.rpm 50d0851b848ee248cfdf075a76ad49d76e76415b3cfc59f21444c2fcc8ed2b4f resource-agents-sap-3.9.5-12.el6_6.3.x86_64.rpm Source: b6c9abc00209e828586393c24414fa391f3abe05dadbad2f6e2f3e79823f3482 resource-agents-3.9.5-12.el6_6.3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Thu, 5 Feb 2015 14:00:55 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0123 CentOS 6 xorg-x11-server BugFix Update Message-ID: <20150205140055.GA64079(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0123 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0123.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 2c2e39e0ba36026de247eedaa5a733f27403600578a6330da9f7c1180c5fec19 xorg-x11-server-common-1.15.0-25.1.el6.centos.i686.rpm 81080ae713a1acd0ea30d84be54b04dba632c231399357d935bad3d591b73957 xorg-x11-server-devel-1.15.0-25.1.el6.centos.i686.rpm b4014fd130801be327a405a7d7bcce8e2448546daa8a9244171194a40f4d1ef4 xorg-x11-server-source-1.15.0-25.1.el6.centos.noarch.rpm 8322884a868f43d2c213987a6df3f3e4437440a2602d9f1c81b34b48c94aeb9a xorg-x11-server-Xdmx-1.15.0-25.1.el6.centos.i686.rpm e5cd7b182deb9e54ac4f580ad009baa48b6959f230caa18dd78cf574c3f854be xorg-x11-server-Xephyr-1.15.0-25.1.el6.centos.i686.rpm 93148cb5b77194501ba3ea7f915c40c1e529f2c3ba391c8dd7fb4987bb17a7b6 xorg-x11-server-Xnest-1.15.0-25.1.el6.centos.i686.rpm 58c14d3273d8edc6d5c215b1fc519064750a48181c413c7e4e1cee415c4b56aa xorg-x11-server-Xorg-1.15.0-25.1.el6.centos.i686.rpm 8b1583b961d2e31f720b7674883187c602e46fa8d4429557f14eac0dc463464c xorg-x11-server-Xvfb-1.15.0-25.1.el6.centos.i686.rpm x86_64: da6cb1aadca9ac7539113bcc892011e7aec0902b4c81ab350eb6754855b354b7 xorg-x11-server-common-1.15.0-25.1.el6.centos.x86_64.rpm 81080ae713a1acd0ea30d84be54b04dba632c231399357d935bad3d591b73957 xorg-x11-server-devel-1.15.0-25.1.el6.centos.i686.rpm 6adf16b9a2cc397fc54bab110093f1591bc02586c196de8b4b7c9fbd94bcce65 xorg-x11-server-devel-1.15.0-25.1.el6.centos.x86_64.rpm b4014fd130801be327a405a7d7bcce8e2448546daa8a9244171194a40f4d1ef4 xorg-x11-server-source-1.15.0-25.1.el6.centos.noarch.rpm aac00cfabe20cadf545cc9218f97b990e175ba2ded7928b4078a0e5755f30e8b xorg-x11-server-Xdmx-1.15.0-25.1.el6.centos.x86_64.rpm c7515cf4862ca3d74df10cb2e8c63449295920f85f6d74e00d3c475ce80e7242 xorg-x11-server-Xephyr-1.15.0-25.1.el6.centos.x86_64.rpm 88efbb1cd6d3cd08c363703c46486b158e4d0046ff04eb09e622edfbb1a91bf4 xorg-x11-server-Xnest-1.15.0-25.1.el6.centos.x86_64.rpm 0651a9d480cc2a883183892165b66a06d648490fa00d29a2306239d9457b6c13 xorg-x11-server-Xorg-1.15.0-25.1.el6.centos.x86_64.rpm 9379a70a17375b21779f28036a4a138dcbf30eb652c63399a3672a65dac4080b xorg-x11-server-Xvfb-1.15.0-25.1.el6.centos.x86_64.rpm Source: 9cc1156ecd7ce73b45b49aa8c0c28a13b5f4f33ce67e3ebc1cf4d552ccc13f8d xorg-x11-server-1.15.0-25.1.el6.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Thu, 5 Feb 2015 16:54:20 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0118 Moderate CentOS 7 mariadb Security Update Message-ID: <20150205165420.GA22060(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0118 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0118.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: bad3e25be040d04b3465b004f1bf5e6bb59ed199002d6d30518c1b37ff9a599c mariadb-5.5.41-2.el7_0.x86_64.rpm 9f358d65718915fb9fa1a3f8cd5503c0c57d3898dab104168b7ed268927afc2c mariadb-bench-5.5.41-2.el7_0.x86_64.rpm 66841b0dfafe27b0441abdbfcc0c3cf0162ed232e0b7fb866cae2e1b89fd0c73 mariadb-devel-5.5.41-2.el7_0.i686.rpm d48dfe12ff12f83b67a41aca0df648b9f1fa19fd854476c0693bac25cc6f8181 mariadb-devel-5.5.41-2.el7_0.x86_64.rpm 650af06e10952a904d7f049eebbcff503baf1a872dce7b95158a9240ceba9f93 mariadb-embedded-5.5.41-2.el7_0.i686.rpm 762eb26cad7b854c356edd88fc9b28ca2fa61dbd1848eb9e8e75d5d7ea184455 mariadb-embedded-5.5.41-2.el7_0.x86_64.rpm 5cb480c0a99d9c5711f524d9172560f1d6cdf38c6b299381fe5f5b1d11ac2109 mariadb-embedded-devel-5.5.41-2.el7_0.i686.rpm 8874ac0173ead6080d28be02101f893e358f07524f54f14a2f970f8eecb7522c mariadb-embedded-devel-5.5.41-2.el7_0.x86_64.rpm 55797074c08ac8857232db2cc91336cbac1323404a902ce7d990a5835558043e mariadb-libs-5.5.41-2.el7_0.i686.rpm d67c7aebd7066e1f896d10e3c366535c03a423ed07151890849a828edecb10dc mariadb-libs-5.5.41-2.el7_0.x86_64.rpm 9b85fe1caf5a8688cd84f41de6ffb4c10a4dc1c29b5eb58bed4ba0346a0256ee mariadb-server-5.5.41-2.el7_0.x86_64.rpm 29a9b071e5eaf820f6a8cfd8ec1442ffb395daa5a1480b8416694b9c58a0cff8 mariadb-test-5.5.41-2.el7_0.x86_64.rpm Source: bed5735782a8cd30854f7158d6c96b775d62d89c9b14cdcdba80b6fb7715addc mariadb-5.5.41-2.el7_0.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 5 Date: Thu, 5 Feb 2015 16:54:38 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEEA-2015:0122 CentOS 7 resource-agents Enhancement Update Message-ID: <20150205165438.GA22128(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2015:0122 Upstream details at : https://rhn.redhat.com/errata/RHEA-2015-0122.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 124869a5c14448855093765e68cf8193023be1b33d7180342926f15d78cae95f resource-agents-3.9.5-26.el7_0.7.x86_64.rpm Source: ea73e94698ddd5bfbd0c2bd5d46116d7b08bbdaa733ed09598d3be9ef59cb9eb resource-agents-3.9.5-26.el7_0.7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 6 Date: Thu, 5 Feb 2015 16:54:59 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0131 CentOS 7 libvirt BugFix Update Message-ID: <20150205165459.GA22290(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0131 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0131.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 3770a731974751dc27346b9ed4f7c494588dde884fd79969a61a8eeb84c79680 libvirt-1.1.1-29.el7_0.7.x86_64.rpm 7ae2765d426b30af80ada68da0df2c780cc0c4113b20845f0a37dbfef195be3d libvirt-client-1.1.1-29.el7_0.7.i686.rpm 4ddeb8022ccbef07a27c75ca3f688280e773a39473f42ce425629801ef1fd554 libvirt-client-1.1.1-29.el7_0.7.x86_64.rpm 288afae70fb572284bbbc88911ff2c79b3cdce0b869b5052afe0cd380313de7d libvirt-daemon-1.1.1-29.el7_0.7.x86_64.rpm 1e4e40d6d4095c9204cd17c195c35e558d5c6342bbf9fcb925e424f8bde849ea libvirt-daemon-config-network-1.1.1-29.el7_0.7.x86_64.rpm 49d44b254a0e7d97c8e5f41ce066f31c8516a9d62837f7d1b37d43ddd72419b4 libvirt-daemon-config-nwfilter-1.1.1-29.el7_0.7.x86_64.rpm 1f39b5292ef41daec4a31655a379049548e78a52f2ce4102bd90cccc504f4ef8 libvirt-daemon-driver-interface-1.1.1-29.el7_0.7.x86_64.rpm 4ac04029552b385e7f1c37e3b3a24eabf69aa67782ef5d5231180263f749786c libvirt-daemon-driver-lxc-1.1.1-29.el7_0.7.x86_64.rpm 872e6fc763daad41f532dcdeec794a63bded4a8abbf81d15993420a2c32bb46b libvirt-daemon-driver-network-1.1.1-29.el7_0.7.x86_64.rpm e3a409c3146ad32187075bdcf18effabef4533ddf65452c6e531a2ab5efec302 libvirt-daemon-driver-nodedev-1.1.1-29.el7_0.7.x86_64.rpm 61c5d1d9ff716f528780fe2bf627c8f94298bc6cc25d25af49020e2738f9bb1f libvirt-daemon-driver-nwfilter-1.1.1-29.el7_0.7.x86_64.rpm 05a3ee1682742b9da5973c4528455efd995799ba612cddb7c5750adbaaefe27d libvirt-daemon-driver-qemu-1.1.1-29.el7_0.7.x86_64.rpm 64e9577205411042eb603ac73c2217153e7023cea0e643322e6738ce31460aaa libvirt-daemon-driver-secret-1.1.1-29.el7_0.7.x86_64.rpm 9e24e5619ae8da15e66a946b3a66033258aa3a26213a8ec1379d9a2e2dfe0f95 libvirt-daemon-driver-storage-1.1.1-29.el7_0.7.x86_64.rpm 3ed24427f2e1931f9c83925063b8a969d36d8a71f705f578d41c399cd544fe9c libvirt-daemon-kvm-1.1.1-29.el7_0.7.x86_64.rpm fd3c6750e0c7440c8de31a99ddaa26ed2582ddd9263a3b60718dd428280c61ba libvirt-daemon-lxc-1.1.1-29.el7_0.7.x86_64.rpm 0a75eeabdd9f3383905b1b31f26b4f299fbf3ddc625ef065f0ff981599ecef0f libvirt-devel-1.1.1-29.el7_0.7.i686.rpm 8137bec6ba39de42836cac97799818fda7cfc6b532e17d65f892ce0e09a2f09b libvirt-devel-1.1.1-29.el7_0.7.x86_64.rpm 3b483a537b07e90ebfa32a257ebc71c04361f17ca2377a09c01db897eae00d38 libvirt-docs-1.1.1-29.el7_0.7.x86_64.rpm 0c24b88d75a072b5d9b19e8a08873ff8754dbe5c14f6942800c91726b989b471 libvirt-lock-sanlock-1.1.1-29.el7_0.7.x86_64.rpm 17e1f0bab66a3e43c7381d08de98ddbf9629ee1275e9458dd1fad6342d86bc4c libvirt-login-shell-1.1.1-29.el7_0.7.x86_64.rpm 6e730906804572cd2c08ed08b5f89b5c1f4a49209e5324317c3405059c8f76ab libvirt-python-1.1.1-29.el7_0.7.x86_64.rpm Source: 0bdc1c1589d71ee5cc681cac25646f219f8d6baa52bd5a8872117004c6feb168 libvirt-1.1.1-29.el7_0.7.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 120, Issue 2 ***********************************************

1 0

Anaconda: inst.repo doesn't work.
by dE 06 Feb '15

06 Feb '15

Although you can choose this in the installer, isnt the provided values supposed to be the default? I tired the following inst.repo=hd:/dev/sdb1:/repo Result: /dev/sdb1 is not mounted. inst.repo=nfs:[fc00::6009]:/home/auser/repo Result: NFS is not mounted even the correct ip is set by passing ip= parameters. Of course I tested the NFS share using CentOS itself. Thanks for any assistance!

2 2

Another Fedora decision
by Chris Murphy 06 Feb '15

06 Feb '15

Warren Young wyml at etr-usa.com Tue Feb 3 00:32:15 UTC 2015 > Are you telling me you cannot memorize a series of 8 characters that do > not violate those rules? Keep in mind the original context isn't for production computers, it's testing Fedora. Many testers do dozens of installs per week, some do dozens per day. The password requirement is pretty annoying, I for one haven't tested it since I worked with the first build that includes the change. Why? While ostensibly it's an 8 character minimum, pwquality is sufficiently capricious that 8 characters is frequently insufficient. I tried about a dozen times and failed, gave up, and went with an ill advised 10 character password that I forgot within 30 minutes after the installation was complete. The problem is the decision to stop innovating ways to incentivize irrational users into producing stronger passwords voluntarily, and instead bringing out boxing gloves to make everyone do it by force. It's inherently adversarial. Someone else made an analogy with the anti-immunization camp. The analogy has some fatal flaws, but one of the ways it works is the irrational reaction component. As it turns out if you call these people names, tell them it's safe, give them all the facts, they just become even more intractable because it's not even about that. Making it compulsory is likely to do the same thing and worse. The way to do it is to establish incentives. If you want your kid going to public schools of any grade, then immunization is a prerequisite. Of course it's your choice, ultimately. Good luck with private school. Here too what's going on is a lack of a mechanism to tie default services with a sufficiently acceptable password. e.g. a checkbox for sshd being enabled is grayed out, not even checkable, so long as the password is crap. Or iterate upon the basic concept which is, you get something for something, bring the user along and get them to change their behavior rather than poking them in the eyeball without any respect to the use case. Windows, OS X, iOS, Android, have much weaker password enforcement than is currently in Fedora 21 and older (and RHEL 7 and older). There's no password even required on mobile devices. I can use a 4 digit PIN to get money out of an ATM. Context, use case, and other mitigation mechanisms are relevant. And the debate is whether a stronger password requirement is really worth, e.g. having root remote login enabled by default on Fedora Server. Whereas sshd isn't enabled on Fedora Workstation. Over on Windows and OS X Servers (try not to laugh, stay on topic!), the expectation is you bring over a USB keyboard, or connect with serial or ethernet console. You opt into remote services explicitly. I’m the first to fight boneheaded “password security” schemes like a > required change every N weeks, but this is not that. Actually I put it in the category of rearranging the deck chairs. It's a debate about very weak vs weak passwords. And I think this will just cause some people to consider their less crap password to now be fair or strong. If we really want strong passwords, we're talking in the vicinity of a compulsory 20+ character password (or passphrase rather). No need to tell me how you feel about that, I'm pretty confident I can predict the response. > (Another gripe of mine: this recent trend toward using some “cloud” login > as your OS login. Apple, Microsoft, and Google are now all doing this! ) It's a good gripe, I don't like it either. However at least Apple and Microsoft have direct paths to work around this seeming requirement. I don't know about ChromeBooks, but certainly on my Android (actually cyanogen) phone I don't have to use a password at all for the phone itself, just services. > (Though, if this server will be used via SSH, it might be a good idea to > do that anyway. SSH keys — optionally with passphrases — are more secure > than even quite a long human-memorizable password. Disable password auth > and use keys.) Yes and it's under discussion to make keys compulsory by default rather than passwords for at least root remote logins. Hard to setup compared to a password. But once that's done it's actually easier to use. -- Chris Murphy

1 0

Re: [CentOS] Another Fedora decision
by Valeri Galtsev 05 Feb '15

05 Feb '15

On Thu, February 5, 2015 12:45 pm, m.roth(a)5-cent.us wrote: > Valeri Galtsev wrote: >> On Thu, February 5, 2015 10:08 am, Always Learning wrote: > <snip> >>>> I know, I know, everybody is reasonable, it is just I didn't have my >>>> coffee yet... >>> >>> Your logic is amazingly good for a coffee drinker. >>> >> No, I wasn't born here though I live here, so I don't take to my heart >> any >> jokes about people living in one of the colonies you lost ;-) Just >> stealing it from some movie I like. Still didn't have chance for my >> morning coffee yet (which I deserve: I was working hard all morning). >> Don't take me too seriously too, just get nice cup of tea (or wait till >> morning for it) ;-) > > Get in, 09:00: tea, British-strength*, w/ milk > Noon, ditto, w/ lunch. > Mid-afternoon, *strong* (not "office") coffee (Cafe Bustelo), vs. the > mid-afternoon sleepiness. Yes. Using my brother's joke, whole life is struggle: before lunch with hunger, after lunch with sleepiness... Valeri > > First full-time job, I went from 6 or so cups of office coffee to my own > mint tea in six months.... USan-born. > > mark > > * Per George Orwell's mid-forties essay: at least 4-5 min of brewing with > boiling water.** > > ** From an article in the Guardian a few months ago: "Sorry, Americans, > the teabag has to actually be *in* the mug, not merely in the room." > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

1 0

build c7 packages for i686 using mock
by Gordon Messmer 05 Feb '15

05 Feb '15

This might be an embarrassingly simple question. How are people building multi-arch library packages on CentOS 7? On older releases one could "mock -r epel-6-i386" and "mock -r epel-6-x86_64" to build a library twice. With no 32-bit release, there's no epel-7-i386 target for mock. Specifying --target=i386 or --arch-i386 both fail. Do we have to set up the environment manually and rpm --rebuild inside the mock root?

4 5

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 16:55, Warren Young wrote: >> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen(a)pari.edu> wrote: >> >> Again, the real bruteforce danger is when your /etc/shadow is >> exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They do not need to crack > your passwords now. You are already boned. > > > My thought exactly. -- *** 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

4 5

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 17:55, Warren Young wrote: > > But of course the same people fighting this move to more secure > password minima are the same ones that turn off SELinux. > Ah. Sorry, NO. First, we are not talking about a more secure password minima. We are discussing an arbitrary change made to an installer program that adversely impacts usability and that only has a tenuous connection to security on a production system. A change which assumes that people installing RHEL systems lack the competence to alter system account passwords subsequent to installation. Second, while I have serious concerns with the delusions respecting security that this fascination with 'strong' passwords evidences I do not turn off SELinux on any of my production servers. Excepting one which to date I have been unable to get to run the critical (third-party) application it hosts with SELinux switched on (short of a custom module which effectively gives http access to the whole host anyway). And that server is hardened against Internet access via other means and only runs this one application. You need to paint with a finer brush I think. -- *** 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

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 17:16, Lamar Owen wrote:. > > Now, I have seen this happen, on a system in the wild, where the very > first thing the attacker did was grab a copy of /etc/shadow, even with > an interactive reverse shell and root access being had. So even when > you recover your system from the compromise you have the risk of all > those passwords being known, and unfortunately people have a habit of > using the same password on more than one system. > > Further, lists of usernames and passwords have market value. > And the arbitrary change made to Anaconda deals with this difficulty how, exactly? Look, I am neither for nor against setting arbitrary standards for user-passwords. In fact, his is what I do to generate system passwords: cat /proc/sys/kernel/random/entropy_avail 3459 openssl enc -base64 <<< $(head -c 32 /dev/random) | \ sed 's/$....$/\1:/g; s/.$//' BuRd:f8qU:yY8M:pbtO:uDlw:D53k:whW+:eJtC:z8Tc:4zlo:hiIK and discard the ':' which I provide simply to make it easier for me to read and type the damn things (once). My belief is that trust in such passwords is totally misplaced. However, if such things makes you feel comfortable (like avoiding crossing paths with a black cat or walking under ladders) then that is your affair and who am I to disagree with your choice. The change to Anaconda is not an issue because of what it is but for how it was done; arbitrarily, without community input, and without consideration of other points of view. That arrogant act was then excused under the rubric of 'increased security'. It that part which irritates me. My indulgence in raising this issue at all is to highlight the inappropriate responses that the human desire to do 'something', 'anything', no matter how pointless, so often trump considered reflective contemplation of the problems and what options are available to deal with them. I am tired of reading of so much wasteful nonsense being excused under the general heading of 'security'. And so I call people out on it now. Prove to me that any increase of cost imposed on me by your decision actually improves my security to a degree that the benefit is measurably greater than the cost. And DO NOT discount my time as having no value. If you cannot prove that then just b*gger *ff. I may have to put up with that crap for want of any viable alternative but, I am not going to nod sagely and pretend that I agree just because currently that is the socially acceptable way of receiving such professions of belief. It is BS. It has always been BS. And it will always be BS. There are no secure methods of public communication. One can only attempt to increase the expense of surveillance to the point where the value of the information received is less than the cost of getting it. If someone values it highly enough then no amount of expense is going to dissuade them and they will have it, eventually. If the cost of surveillance is cheap enough then everything will be surveyed and everyone will have access to your information. But surely, it is the choice of the parties owning the information to decide how much value it has and exactly how much expense is justified in protecting it? Access to computer systems has to considered from the point of view of eventual compromise. Is not if, it is when, you are compromised. The critical considerations are: how will you detect it; how much penetration will result from each potential point of entry before it is detected; and how much effort will it take to recover? -- *** 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

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Tue, February 3, 2015 14:01, Valeri Galtsev wrote: > > On Tue, February 3, 2015 12:39 pm, Les Mikesell wrote: >> On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev >> <galtsev(a)kicp.uchicago.edu> wrote: >>> >>> Sounds so I almost have to feel shame for securing my boxes no >>> matter what job vendor did ;-) >> >> Yes, computers and the way people access them are pretty much a >> commodity now. If you are spending time building something exotic >> for a common purpose, isn't that a waste? > > Do I have to take that people who are not sysadmins themselves just > hate an existence of sysadmins? > I had a friend, now deceased, who worked as an RCA colour TV technician when he was very young. In the 1950s he would be sent to the homes of people having trouble adjusting the colour settings on their new RCA's. That was system administration then. Who needs them now? We are dinosaurs. People do not hate us. They just do not understand why we are still around. Other than lifting the display into a comfortable position for viewing the latest MacBooks cannot even be physically opened for servicing (by a user) as far as I can discover. An iPhone is a sealed unit. Both devices are orders of magnitude more powerful computers than the i486 I first installed RH on. The point Les makes is entirely correct. The systems we install should not require the degree of slavish attention to arcane details that is necessary to make them both useful and safe to use. That said, the original issue remains, making manual configuration slightly more cumbersome than it already is. That this is done solely in order to make a claim that it somehow improves security is, in my opinion, self-defeating. It is certainly a deceit. Whether it is self-delusion or overt pretence I have no idea. One might question why *nix distributions insist on providing a known point of attack to begin with. Why does user 0 have to be called root? Why not beatlebailey, cinnamon or pasdecharge? If brute forcing passwords is the problem then why not make it ever more difficult by forcing crackers to guess what the superuser name is to begin with? Oh, I know. Too much software exists that presumes that the superuser name is root. Evidently adherence to that convention is valued more highly than providing security. God forbid that one simply check for user 0. I seldom use root other than for peer-to-peer rsync via password-less login. Consequently I do not really care whether Anaconda forces me to use 32 character Base64 encoded passwords for root or none at all. I just cannot bear to stand by and read the BS about how anything of that nature improves security. It is just self-deception. Twenty years ago it might have had some validity, although I doubt it. Things that are hard to remember tend to get written down. Things that are written down tend to be read by eyes other than those that were intended. The whole matter of attending to the risk of brute force password discovery rather misses the point. Amateurs hack systems, professionals hack people. No matter how resistant your password is to brute force discovery, it only takes one careless mistake to have it revealed by an incautious or suitably deceived sysadmin. Look up 'Robin Sage' and the follow on study 'Emily Williams' and then ask yourself: How does a strong password on the root account deal with that? I really wonder sometimes if the software development people that write so much about security 'best-practice' have much of a clue about how penetrations are actually carried out. For example, how many of you have ever plugged a USB key into one of your hosts? If you have then you have permanently compromised the security of that system and nothing, short of pulling the entire USB controller, can ever undo it; and not even then I suspect. You may not, probably have not (yet), have been infected, but then you will never know for sure whether you have or not. There are so many computer control systems that are embedded in the devices we call computers that the attack surface is incomprehensibly large. And most of these embedded systems are completely open to exploitation; at the fabrication level. The Internet is not even the preferred vector. Have you ever used a USB charging station in an airport for your laptop, tablet or phone? Too bad. Have you ever plugged a personal device into one of your hosts at work via USB or Thunderbolt (not likely for the latter I admit)? Oh well. At least you can increase the strength of your root password. Is your home or business network device provided to you by your provider? Has it been changed (upgraded) recently without your request (or even with it)? I have to SSH tunnel all of my traffic on my home network now because traffic through my (recently upgraded) xxxxxx provided yyyyy router phones home to yyyyy; and I cannot stop it short of jail-breaking, which is in violation of my terms of service (AND I have to pay rent for this device). This is not paranoia, this is observed activity. (Sorry about the xxxxx yyyyy stuff, but on consideration I would rather not run the risk of being harassed by either or both of the two major corporations involved.) Sometimes I just cannot bear to think about this stuff anymore. -- *** 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

7 11

Re: [CentOS] UC multipathd
by Rushton Martin 05 Feb '15

05 Feb '15

>-----Original Message----- >From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On >Behalf Of Alexander Dalloz >Sent: 04 February 2015 22:44 >To: CentOS mailing list >Subject: Re: [CentOS] multipathd > >Am 04.02.2015 um 15:02 schrieb Rushton Martin: >> Our cluster was supplied with two IBM DS3400 RAID arrays connected >> with fibre channel. Both are old and one is failing so we bought an >> IBM >> V3700 to replace it. The V3700 complained that we were using the >> IBM's RDAC driver (true) and we were advised to change to using Linux >> multipath. I've done that but the default configuration for the >> DS3400s > >So you switched from IBM's proprietary multipath driver to the native >Linux multipathing. Correct? Yes. We were told to do so by the suppliers of the V3700. > >> is: >> device { >> vendor IBM >> product 1726-4xx >> path_checker rdac >> features 1 queue_if_no_path >> hardware_handler 1 rdac >> prio_callout /sbin/mpath_prio_rdac /dev/%n >> no_path_retry 300 >> rr_min_io 1000 >> } > >The right settings are documented here: > >https://access.redhat.com/solutions/85223 Thanks, I shall investigate. The stanza I've used was the one that multipath itself supplies. >Yoi should be a little more specific about the conflict you see. The V3700 GUI reports: "Error 1624 : Controller configuration has unsupported RDAC mode" Attempting to run the fix results in two messages: ----%<------- Incorrect controller configuation It is detected that storage system ds3400-01 has been incorrectly configured. The storage system configuration has an unsupported RDAC mode. ----%<------- Incorrect configuration The storage system named ds3400-01 has been configured to use a failover mode called RDAC. This failover mode is not supported by the system, and will prevent the system from causing managed disks to fail over between controller A and controller B when required. Resolve this by setting the host type in the storage system configuration as defined in the IBMÂ® Storage ITE Software Configuration Guide. If available, the correct host type will be "IBM TS SAN VCE". Once the issue has been resolved, click Next to continue. The following additional information may help with correcting the problem: Storage system name: ds3400-01 WWNN (Worldwide Node Name): XX:XX:XX:XX:XX:XX:XX:XX WWPN (Worldwide Port Number): XX:XX:XX:XX:XX:XX:XX:XX Problem type : Unsupported RDAC Mode Set ----%<------- The fix then runs, but reports the same 1624 error. > >> The V3700 is still complaining and I note the "path checker rdac" and >> mpath_prio_rdac lines. Is this rdac the same as IBM's RDAC, and if so >> how can I get rid of it? > >The DS3400 is an OEM product, provided by NetApp. RDAC is the the name of >the hardware access type originally for LSI Corp controllers, later on >NetApp. > >mpath_prio_rdac is code from the Linux kernel. > >> OS is CentOS 5.3 (yes, I know - upgrade), filesystem is GPFS. > >Update! Not upgrade. That old piece of software is full of well known >severe security issues and bugs already fixed. There is not really an >excuse to not properly maintain a system. Off-net machine. Updates are non-trivial, download is over a slow broadband (between 500K and 1M) and takes well over 24 hours continuously. Then I've still got to burn or copy to transfer. >Alexander > >_______________________________________________ >CentOS mailing list >CentOS(a)centos.org >http://lists.centos.org/mailman/listinfo/centos This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.

1 0

Re: [CentOS] UC multipathd
by Rushton Martin 05 Feb '15

05 Feb '15

Yep, that's what I do at home. The trouble for off-net machines is the download time - over 24 hours for CentOS 7 + epel, and then copy over. If you don't grab everything, the one package you miss is the one that stops the update. :-( >-----Original Message----- >From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On >Behalf Of John R Pierce >Sent: 04 February 2015 19:01 >To: centos(a)centos.org >Subject: Re: [CentOS] multipathd > >On 2/4/2015 6:02 AM, Rushton Martin wrote: >> OS is CentOS 5.3 (yes, I know - upgrade) > >at least patch CentOS 5. 5.3 is a snapshot from 6 years ago (2009), >there've been 6 years of updates to CentOS 5 since that point, both >security and bug fixes. `yum update` would bring you up to CentOS the >.11 update plus security/bug fixes since. > > > >-- >john r pierce 37N 122W >somewhere on the middle of the left coast > >_______________________________________________ >CentOS mailing list >CentOS(a)centos.org >http://lists.centos.org/mailman/listinfo/centos This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.

1 0

Re: [CentOS] multipathd
by Alexander Dalloz 04 Feb '15

04 Feb '15

Am 04.02.2015 um 15:02 schrieb Rushton Martin: > Our cluster was supplied with two IBM DS3400 RAID arrays connected with > fibre channel. Both are old and one is failing so we bought an IBM > V3700 to replace it. The V3700 complained that we were using the IBM's > RDAC driver (true) and we were advised to change to using Linux > multipath. I've done that but the default configuration for the DS3400s So you switched from IBM's proprietary multipath driver to the native Linux multipathing. Correct? > is: > device { > vendor IBM > product 1726-4xx > path_checker rdac > features 1 queue_if_no_path > hardware_handler 1 rdac > prio_callout /sbin/mpath_prio_rdac /dev/%n > no_path_retry 300 > rr_min_io 1000 > } The right settings are documented here: https://access.redhat.com/solutions/85223 Yoi should be a little more specific about the conflict you see. > The V3700 is still complaining and I note the "path checker rdac" and > mpath_prio_rdac lines. Is this rdac the same as IBM's RDAC, and if so > how can I get rid of it? The DS3400 is an OEM product, provided by NetApp. RDAC is the the name of the hardware access type originally for LSI Corp controllers, later on NetApp. mpath_prio_rdac is code from the Linux kernel. > OS is CentOS 5.3 (yes, I know - upgrade), filesystem is GPFS. Update! Not upgrade. That old piece of software is full of well known severe security issues and bugs already fixed. There is not really an excuse to not properly maintain a system. Alexander

1 0

Re: [CentOS] multipathd
by John R Pierce 04 Feb '15

04 Feb '15

On 2/4/2015 6:02 AM, Rushton Martin wrote: > OS is CentOS 5.3 (yes, I know - upgrade) at least patch CentOS 5. 5.3 is a snapshot from 6 years ago (2009), there've been 6 years of updates to CentOS 5 since that point, both security and bug fixes. `yum update` would bring you up to CentOS the .11 update plus security/bug fixes since. -- john r pierce 37N 122W somewhere on the middle of the left coast

1 0

Re: [CentOS] Traditional network interface naming scheme vs. persistent naming
by Niki Kovacs 04 Feb '15

04 Feb '15

Le 04/02/2015 18:48, m.roth(a)5-cent.us a écrit : > That directory, and that file, exist in CentOS, also, since 6. And the new > naming... it's*so* much easier to deal with... yeah, right, I'll run the > install, and wait till it hangs, so I can see that the NIC is named, what > was it, on that HP last month, oh, yeah, I need to use ip -f inet link, > far simpler than ifconfig, yes, it's ens3f0.... > > mark "why would I*possibly* prefer a same-on-every-box eth0?"* > > * For the satire-impaired, this is satire. LOL !!! After a bit more experimenting, looks like I've found a clean solution for this. Simply create the /etc/udev/rules.d/70-persistent-net.rules file from scratch and edit it like this: # /etc/udev/rules.d/70-persistent-net.rules # # eth0 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:1e:c9:42:84:7b", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth0" # eth1 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:30:f1:6a:2f:40", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth1" Reboot, and everything's working as expected. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

1 0

Traditional network interface naming scheme vs. persistent naming
by Niki Kovacs 04 Feb '15

04 Feb '15

Hi, I'm currently experimenting with CentOS 7 in order to get a grasp of everything that's new. After having read the FAQ entry on network interface names, I decided to revert to the tradictional interface naming scheme by adding the relevant kernel options to the bootloader. This went well, I have now two interfaces names 'eth0' and 'eth1' as expected. In my office I have another server with two network interface cards, running Slackware64 14.1. On a stock Slackware installation, as soon as there is more than one NIC, the system creates a file /etc/udev/rules.d/70-persistent-net.rules, which looks like this: # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:27:d7:15:54:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:04.0/0000:03:00.0 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:64:8a:4c:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" Usually I have a 50 % chance of getting the network interface right (well, according to Murphy, I have more like a 100 % chance of getting it wrong the first time :oD). In that case, I simple edit the 70-persistent-net.rules file, permutate the "eth0" and "eth1" entries and then reboot. How would I go about that under CentOS with traditional interface names? The 70-persistent-net.rules file doesn't exist. Do I have to create it from scratch? Cheers, Niki Kovacs -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

3 2

Setting up Samba as fileserver for existing Windows domain
by Chris Adams 04 Feb '15

04 Feb '15

This is probably covered in many places, but my Google-fu is failing. I have an existing office of Windows computers, in a domain, with a couple of Windows Server 2012 AD servers. I need to add a file server, so I'd prefer to use CentOS 7 and Samba to do it (because I know very little about Windows). However, I'm not finding a good how-to on that. When I search for "samba active directory" or "samba domain", the results are mostly about setting up Samba to be the domain controller, or join an AD domain as a controller, which I don't really want to do if I don't have to. Anybody have any tips, pointers, etc.? -- Chris Adams <linux(a)cmadams.net>

3 5

multipathd
by Rushton Martin 04 Feb '15

04 Feb '15

Our cluster was supplied with two IBM DS3400 RAID arrays connected with fibre channel. Both are old and one is failing so we bought an IBM V3700 to replace it. The V3700 complained that we were using the IBM's RDAC driver (true) and we were advised to change to using Linux multipath. I've done that but the default configuration for the DS3400s is: device { vendor IBM product 1726-4xx path_checker rdac features 1 queue_if_no_path hardware_handler 1 rdac prio_callout /sbin/mpath_prio_rdac /dev/%n no_path_retry 300 rr_min_io 1000 } The V3700 is still complaining and I note the "path checker rdac" and mpath_prio_rdac lines. Is this rdac the same as IBM's RDAC, and if so how can I get rid of it? OS is CentOS 5.3 (yes, I know - upgrade), filesystem is GPFS. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.

1 0

user nobody can't access file
by Tim Dunphy 04 Feb '15

04 Feb '15

Hey guys, I need to give the 'nobody' user (which is what our apache runs as) no password access to a file, via sudo. This is what I've tried: nobody ALL=(ALL) NOPASSWD: /var/www/qa/launchpadnew/site/ftp_check.php But if I become the nobody user and try to access the file, it tries to prompt me for a password: -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php [sudo] password for nobody: Can someone please point out for me where I'm going wrong? Cuz I don't see it!! Thanks ! :) Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

6 5

Re: [CentOS] Another Fedora decision
by James B. Byrne 03 Feb '15

03 Feb '15

I think it well to recall that the change which instigated this tempest was not to the network operations of a RHEL based system but to the 'INSTALLER' process, Anaconda. Now, I might be off base on this but really, ask yourself: Who exactly uses an installer program? And what is the threat model being addressed by requiring that the installer set a suitably strong password for root? For what purpose? Because RHEL sets the sshd on and allows root access over ssh via password by default? Then is not the correct approach to disable that access instead? But wait! Is it not true that the network services are not started by default? So, exactly where is the threat? Does it not occur much, much later in the workflow than at the installer? Would it not be more sensible to require root access to start sshd (hummmm. . . is that not a requirement now?) and to ask for the root password at that time. And then of course, you could catch those sneaky people that change the root password after the install is complete. Surly, it is when starting network services that then, and only then, one should check that one of the following conditions are true: 1.) root access over the network is disabled; 2.) root access over the network is allowed via RSA only; 3.) if root can log in via ssh using a password then the root password must be strong? That process seems like something that could be setup in a network init script, upstart system job, or systemd service file without a great deal of effort. Why does arbitrarily requiring 'strengthening' of the root password have to go into the installer program? Yes, the alternative approach would adversely impact automatic system restarts. And your point? Is not the easy answer but to disallow root access over the network entirely; or to force the use of RSA certs for root logons? Are not these far, far superior approaches to dealing with this issue than requiring a 'strong' root password everywhere, all the time, regardless of what purpose the system is used for? This change to Anaconda is not security, it is theatre. It is directly equivalent to airport passenger security checks. Totally ineffectual but so intrusive and inconvenient that we have to believe that it works. For otherwise the inescapable conclusion is that we are all fools for putting up with it; and no-one likes to think of themselves as a fool. I call this the 'Buckley's Mixture' approach to social engineering. In any case, allowing an eight character password on credentials exposed to public network access is laughable. -- *** 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

4 3

Kickstart setup
by Ashley M. Kirchner 03 Feb '15

03 Feb '15

Is there a way to use kickstart to boot a machine into a manual setup process? Basically what I'm getting to is this, the machine doesn't not have a CD drive in it (nor can I add one), but I can boot it via kickstart. The install media is on the network. What I'd like to do is boot this machine up and rather than have kickstart do everything for me as far as installing the OS and packages, instead present me with a manual setup (that I can get to via vnc) where I get to pick what I want or don't want on the machine. After it's all done, I'm going to go through the anaconda files and generate a base kickstart for all future installs. Does anyone have an example kickstart file I can go off of to do that?

3 4

Re: [CentOS] Another Fedora decision
by James B. Byrne 03 Feb '15

03 Feb '15

On Mon, February 2, 2015 21:34, PatrickD Garvey wrote: > OK, folks. You're doing a great job of describing the current milieu > with a rough description of some best practices. > > Now how about some specific sources you personally used to learn your > craft that we can use likewise? > > PatrickD > > Go to http://www.ccc.de/en/. Visit and view some of the videos of presentations from previous congresses and hackfests. Educate yourself on the threats. Once you see what you are up against then you will have some ideas about what questions to ask. Then you can find the material you need. -- *** 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

Squid3 on CentOS 6.6: IPv6 PTR endianess
by Max Grobecker 03 Feb '15

03 Feb '15

Hello, I'm running a Squid cache (Version 3.1.10) on CentOS 6.6 as a forward proxy which is reachable over a global IPv6 address. For whatever reason, Squid tries to perform PTR lookups on the client's IPv6 address. The weird thing is, that Squid seems to struggle with the "endianess" of the IPv6 address blocks. For example: My current client IP is 2003:6e:d79:2104:7163:7ecd:9333:f0be. Squid tries to resolve b.e.f.0.3.3.9.3.c.d.7.e.6.3.7.1.0.4.2.1.7.9.0.d.6.e.0.0.0.3.2.0.ip6.arpa. That means: b.e.f.0.3.3.9.3.c.d.7.e.6.3.7.1.0.4.2.1.7.9.0.d.6.e.0.0.0.3.2.0.ip6.arpa -> 0.2.3.0.0.0.e.6.d.0.9.7.1.2.4.0.1.7.3.6.e.7.d.c.3.9.3.3.0.f.e.b -> 0230 : 00e6 : d097 : 1240 : 1736 : e7dc : 3933 : 0feb For comparison: Squid: 0230:00e6:d097:1240:1736:e7dc:3933:0feb Real: 2003:006e:0d79:2104:7163:7ecd:9333:f0be It seems, that Squid just messes with the order of the Bytes on each block. I couldn't find any related bug report on this (checked Squid and CentOS bug tracker), so I'm not sure if it's a CentOS or Squid related problem. Is anyone else experiencing this? It seems to be happen on IPv6 client addresses only - with IPv4 it works just fine. And besides of these broken PTR lookups Squid is working as expected. Greetings from Wuppertal Max

2 1

Re: [CentOS] Very slow disk I/O
by Jatin Davey 03 Feb '15

03 Feb '15

On 2/2/2015 10:32 AM, John R Pierce wrote: > On 2/1/2015 8:25 PM, Jatin Davey wrote: >> >> On 2/2/2015 9:25 AM, John R Pierce wrote: >>> On 2/1/2015 7:31 PM, Jatin Davey wrote: >>>> >>>> I ran your script and here is the output for it: >>>> >>>> Start of the Output*************************** >>>> [root@localhost bin]# lsi-raidinfo >>>> sh: /opt/MegaRAID/MegaCli/MegaCli64: No such file or directory >>>> -- Controllers -- >>> >>> as I said, you need to install the MegaCli software from LSI so you >>> can manage the raid card. >> I am using a server which has a Cisco 12G SAS Modular Raid Controller >> , So wondering if software from LSI would work on it. Please correct >> me if am wrong. > > >> [root@localhost ~]# lspci | grep RAID >> 05:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 >> 3108 [Invader] (rev 02) > > thats a LSI Logic Megaraid 3108 chip. This is used on the LSI > 9361-8i and many other OEM rebranded cards. If cisco has their own > package of the megacli management software, then sure, use that. > Hi John I managed to install the software from LSI on my box and ran the script that you had provided and here is what i get from it. ************Output ****************** [root@localhost bin]# lsi-raidinfo -- Controllers -- -- ID | Model c0 | Cisco 12G SAS Modular Raid Controller -- Volumes -- -- ID | Type | Size | Status | InProgress volume c0u0 | RAID10 2x2 | 1816G | Optimal | None -- Disks -- -- Encl:Slot | vol-span-unit | Model | Status disk 252:1 | 0-0-0 | 9XG7TNQVST91000640NS CC03 | Online, Spun Up disk 252:2 | 0-0-1 | 9XG4M4X3ST91000640NS CC03 | Online, Spun Up disk 252:3 | 0-1-1 | 9XG4LY7JST91000640NS CC03 | Online, Spun Up disk 252:4 | 0-1-0 | 9XG51233ST91000640NS CC03 | Online, Spun Up End of Output ************************** Let me know if i need to change or configure anything else to make the I/O a bit faster than what it currently does. I cannot go in for using SSD's due to budget constraints. Need to make the best use of the SATA disks that i have currently. Thanks Jatin

6 9

Very slow disk I/O
by Jatin Davey 03 Feb '15

03 Feb '15

Hi Users I am using RHEL 6.5 on my server. From top command i can see that the processors in my server are spending a lot of time on wait for I/O. I can see high percentage in terms of 30-50% on "wa" time. Here is the df output about the disk space in my system: ********** [root@localhost images]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 1915071844 103227908 1714563936 6% / tmpfs 32931472 0 32931472 0% /dev/shm ********** Could someone point me on how to improve the disk I/O on my server and reduce the wait time on I/O. Thanks Jatin

8 15

NVidia on encrypted Q. RE: Intel Displayport on Centos 7
by Denniston, Todd A CIV NAVSURFWARCENDIV Crane 02 Feb '15

02 Feb '15

> -----Original Message----- > From: Lamar Owen [mailto:lowen@pari.edu] > Sent: Saturday, January 31, 2015 1:53 PM > To: CentOS mailing list > Subject: Re: [CentOS] Intel Displayport on Centos 7 > <SNIP> > the stock ATI drivers. I haven't tried with the fglrx driver; it seems > to be a bit of a problem child on C7 at the moment. For that matter, > the nVidia proprietary driver is a bit of a problem child if you have > any encrypted partitions like I do. <SNIP> I have not gotten to testing C7 (or RHEL7 for that matter) yet, but I expect to need the NVidia driver (from elrepo) on them and for the drives to be encrypted, SO ... What kinds of issues do the proprietary drivers and encrypted partitions together seem to be causing? Are your problems all related to: https://www.centos.org/forums/viewtopic.php?f=49&t=47460 http://elrepo.org/bugs/view.php?id=496 https://www.centos.org/forums/viewtopic.php?f=47&t=49304&start=10 Or are there other issues? Thanks for the feedback. Even when this disclaimer is not here: I am not a contracting officer. I do not have authority to make or modify the terms of any contract.

1 0

CentOS-announce Digest, Vol 120, Issue 1
by centos-announce-request＠centos.org 01 Feb '15

01 Feb '15

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-2015:0106 CentOS 6 libvirt BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Sat, 31 Jan 2015 13:42:07 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0106 CentOS 6 libvirt BugFix Update Message-ID: <20150131134207.GA14009(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0106 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0106.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ea5d48d18878658b540b1f263cf5c6b5275816eef56592f2ad1ea81435a0856c libvirt-0.10.2-46.el6_6.3.i686.rpm c70aef109c73e5a2ea4a1aacd8f994ce082038b7bbf68b78e7463a5295edcf46 libvirt-client-0.10.2-46.el6_6.3.i686.rpm ae2a478f26b7556fb67a280eb9609e62d30bfbb103b691a8bdaff359fa82688f libvirt-devel-0.10.2-46.el6_6.3.i686.rpm e7426898e565a6d173aac3b2f1f22eb24aebbe865923d8d509ccba7fc9391d7a libvirt-python-0.10.2-46.el6_6.3.i686.rpm x86_64: 77ccd05d7ff093dcf14d1f57628df7912754178f02a613ea87ab905114806110 libvirt-0.10.2-46.el6_6.3.x86_64.rpm c70aef109c73e5a2ea4a1aacd8f994ce082038b7bbf68b78e7463a5295edcf46 libvirt-client-0.10.2-46.el6_6.3.i686.rpm 17bfed0bfd3305f1464fa7d145ff7b000f8c720108c2857e8c7799fea0624d54 libvirt-client-0.10.2-46.el6_6.3.x86_64.rpm ae2a478f26b7556fb67a280eb9609e62d30bfbb103b691a8bdaff359fa82688f libvirt-devel-0.10.2-46.el6_6.3.i686.rpm 6c412b887b82b69bbafde5d005c9417f2d256b54aa5a32994813d25fee75473a libvirt-devel-0.10.2-46.el6_6.3.x86_64.rpm 28897e103ff2f7dc7bba07ddde217df7958906df861d8f73e8228e15538d69ac libvirt-lock-sanlock-0.10.2-46.el6_6.3.x86_64.rpm f25e4b29c8ad46f97f6ae2a07db51d5f907d550b2285d5e7bef495e594edc558 libvirt-python-0.10.2-46.el6_6.3.x86_64.rpm Source: 2012ad82ddfcda7d4989f299888e1f6c58812680bfd033130d1c246690575507 libvirt-0.10.2-46.el6_6.3.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 120, Issue 1 ***********************************************

1 0

Intel Displayport on Centos 7
by Frank Cox 31 Jan '15

31 Jan '15

Since my current monitor appears to be slowly dying, I'm looking for a replacement. I generally use hardware replacement as an excuse to get something bigger/better/faster than what I had before, so I'm currently considering something like a BenQ GW2765HT. The manual for my Intel motherboard has this to say about DisplayPort on the built-in graphics controller: QUOTE: DisplayPort’s maximum supported display resolution is 2560 x 1600 at a 60 Hz refresh rate with a 16:10 aspect ratio (WQXGA). END OF QUOTE It also states that the maximum supported resolution on the built-in DVI-I port is 1920x1200, which is the resolution of the monitor that I have right now; the one that appears to be dying. Therefore, this new monitor wouldn't work at full resolution with that output. Having never used DisplayPort before, I'm wondering if this means that if I purchase the BenQ monitor above, or something similar, I can then reasonably expect to plug it in and have it just-work with my Centos 7 setup. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

5 9

Installation of qtiplot in Centos 7
by MOHD HOMAIDUR RAHMAN 31 Jan '15

31 Jan '15

Dear all I am trying to install qtiplot in Centos 7 (qtiplot is a graph plotting software similar to Origin). I followed the same step as this mention on this. http://poolinfo.physik.hu-berlin.de/qtiplot-installer/README.html At step 8, I experience the following error. cd fitPlugins && make -f Makefile make[1]: Entering directory `/home/rahman/Downloads/qtiplot-0.9.8.9/fitPlugins' cd explin/ && make -f Makefile make[2]: Entering directory `/home/rahman/Downloads/qtiplot-0.9.8.9/fitPlugins/explin' rm -f libexplin.so.1.0.0 libexplin.so libexplin.so.1 libexplin.so.1.0 g++ -Wl,-O1 -Wl,-z,relro -shared -Wl,-soname,libexplin.so.1 -o libexplin.so.1.0.0 explin.o -L/usr/lib64 ../../3rdparty/gsl/lib/libgsl.a ../../3rdparty/gsl/lib/libgslcblas.a -L/opt/local/lib -lpthread -lQtGui -lQtCore g++: error: ../../3rdparty/gsl/lib/libgsl.a: No such file or directory g++: error: ../../3rdparty/gsl/lib/libgslcblas.a: No such file or directory make[2]: *** [../libexplin.so.1.0.0] Error 1 make[2]: Leaving directory `/home/rahman/Downloads/qtiplot-0.9.8.9/fitPlugins/explin' make[1]: *** [sub-explin-make_default] Error 2 make[1]: Leaving directory `/home/rahman/Downloads/qtiplot-0.9.8.9/fitPlugins' make: *** [sub-fitPlugins] Error 2 Please suggest me how to resolve this problem. Thank you in advanced for help Regards Rahman ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' *Md Homaidur Rahman* PhD Research Scholar Computational Biophysics Lab. Department of Biotechnology Indian Institute of Technology-Madras Chennai-600 036 *Mobile No = +91- 7845991785* '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

1 0

C6 server responding extremely slow on ssh interactive
by Patrick Bervoets 30 Jan '15

30 Jan '15

I have a C6 server acting as a kvm-host. When connecting with ssh the console is extremely slow and hangs for minutes at a time. Connecting to this server is not the problem. If I use: ssh root@host "whatever" I got immediate response even when interactive consoles opened with ssh are hanging. Linux [...] 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux total used free shared buffers cached Mem: 47 35 11 0 0 0 -/+ buffers/cache: 35 11 Swap: 7 0 7 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-lv_root 50G 6,4G 41G 14% / tmpfs 24G 0 24G 0% /dev/shm /dev/sda1 477M 123M 329M 28% /boot 13:33:34 up 1 day, 18:30, 2 users, load average: 3.39, 2.53, 2.36 (it's an 8-core) Nothing particular in log/messages. The vm's are running normally and they are not showing the same behaviour. Can anybody give me a pointer? Thanks Patrick

6 18

CentOS-announce Digest, Vol 119, Issue 12
by centos-announce-request＠centos.org 30 Jan '15

30 Jan '15

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-2015:0108 CentOS 6 tcsh BugFix Update (Johnny Hughes) 2. CEBA-2015:0097 CentOS 6 libssh2 BugFix Update (Johnny Hughes) 3. CEBA-2015:0098 CentOS 6 curl BugFix Update (Johnny Hughes) 4. CEBA-2015:0110 CentOS 6 nss-softokn BugFix Update (Johnny Hughes) 5. CESA-2015:0102 Important CentOS 7 kernel Security Update (Johnny Hughes) 6. CESA-2015:0102 Important CentOS 7 kernel Security Update (Johnny Hughes) 7. CESA-2015:0100 Moderate CentOS 7 libyaml Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Jan 2015 12:45:48 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0108 CentOS 6 tcsh BugFix Update Message-ID: <20150129124548.GA61000(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0108 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0108.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 2534940990a5957d0d18a19ca1ab803df8febda4dcdc74cdd4d1fb4ed77ac4f3 tcsh-6.17-25.el6_6.i686.rpm x86_64: 4ef1392aef0a90045b8147235bafe2faa195b49ecf3404f8f1a3468c6569e50d tcsh-6.17-25.el6_6.x86_64.rpm Source: d94793dc7e12799e65c46dd420a12c48f3b7b152d578d5b4aded7ca90faa4a77 tcsh-6.17-25.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Thu, 29 Jan 2015 12:56:15 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0097 CentOS 6 libssh2 BugFix Update Message-ID: <20150129125615.GA61798(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0097 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0097.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 28ab4d79c33a10d055b6eed05dc0c2051e9abb5932a69889cb2f70bb2172a7b7 libssh2-1.4.2-1.el6_6.1.i686.rpm 4650f891e63ecf6f13a1e5c1e84a5675f69188af5250a9ed8768c595fb5eb652 libssh2-devel-1.4.2-1.el6_6.1.i686.rpm 9435dc4114a3e66619562863bb5f4af4473c9f2c6bef4c503bd9767df863f6b5 libssh2-docs-1.4.2-1.el6_6.1.i686.rpm x86_64: 28ab4d79c33a10d055b6eed05dc0c2051e9abb5932a69889cb2f70bb2172a7b7 libssh2-1.4.2-1.el6_6.1.i686.rpm 2e07438d7789237523d415dd3a92d99215867b7641ad267b424880b0dca9c89c libssh2-1.4.2-1.el6_6.1.x86_64.rpm 4650f891e63ecf6f13a1e5c1e84a5675f69188af5250a9ed8768c595fb5eb652 libssh2-devel-1.4.2-1.el6_6.1.i686.rpm 7e00157f2af61f22fe18260a9f2204982d92066cf8613384168d6972643df70c libssh2-devel-1.4.2-1.el6_6.1.x86_64.rpm 57800bbe07d3f5cfe4315c9aff91145fb2463e324ef18d9a82a0f2ddf1c22fac libssh2-docs-1.4.2-1.el6_6.1.x86_64.rpm Source: 10684ae17a697ab8cce1cfca1dcd8915c0a7d2a5f4e84f568bf52dabe97c1c6c libssh2-1.4.2-1.el6_6.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Thu, 29 Jan 2015 12:56:38 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0098 CentOS 6 curl BugFix Update Message-ID: <20150129125638.GA61893(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0098 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0098.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 4e4cd05361833384ad287cfb5cfcd8aed1ec0461d83bc754e51ee6c630e06c63 curl-7.19.7-40.el6_6.4.i686.rpm 1fdd61fea79c7e0f4f1c416909a54269f01f7879d2f2199e296089b52bb5f042 libcurl-7.19.7-40.el6_6.4.i686.rpm 6ff5a5059dfde80bdb33add0894bc6d89d9de5aa805d790c9b29784f79cabd41 libcurl-devel-7.19.7-40.el6_6.4.i686.rpm x86_64: 43ac2a840e3bc14b3397ab4bc094315f6e285e291739d53146d4ec9c8287d221 curl-7.19.7-40.el6_6.4.x86_64.rpm 1fdd61fea79c7e0f4f1c416909a54269f01f7879d2f2199e296089b52bb5f042 libcurl-7.19.7-40.el6_6.4.i686.rpm f05250feaea200500e271cf1bff1725bdebef29f002bb8fb80dfd9653dfc9f30 libcurl-7.19.7-40.el6_6.4.x86_64.rpm 6ff5a5059dfde80bdb33add0894bc6d89d9de5aa805d790c9b29784f79cabd41 libcurl-devel-7.19.7-40.el6_6.4.i686.rpm 3d853c62440e5ac2fdd67d2abd6fd438ba0170d6c9f2698c9654f192541fb9f3 libcurl-devel-7.19.7-40.el6_6.4.x86_64.rpm Source: 44dfa657f77c2777366f6255b71938278db86014fc407e659c228dd3665a4e6b curl-7.19.7-40.el6_6.4.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Thu, 29 Jan 2015 23:20:58 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0110 CentOS 6 nss-softokn BugFix Update Message-ID: <20150129232058.GA16550(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0110 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0110.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 77c7dfa9cdac123d789f1d1a65b8ecb22bd02cf70cf0d74cca4aedcb873be103 nss-softokn-3.14.3-22.el6_6.i686.rpm 845a74c34377474614a69035b2741c8e2e420bfd98b37676cdbed09534fd84c4 nss-softokn-devel-3.14.3-22.el6_6.i686.rpm c7de3e40ada40624174bd4aea2b3903b3f1dd71ab6ad16ed3a05e9d5574b2bc0 nss-softokn-freebl-3.14.3-22.el6_6.i686.rpm 027aeee015b2281bebdb09ff87b34933380e3bfd79a40f28d14fd3983c730458 nss-softokn-freebl-devel-3.14.3-22.el6_6.i686.rpm x86_64: 77c7dfa9cdac123d789f1d1a65b8ecb22bd02cf70cf0d74cca4aedcb873be103 nss-softokn-3.14.3-22.el6_6.i686.rpm fb22476443aa77b1ec969dc09416a9cabde6e652e4712a6a33266a9140c2b7d9 nss-softokn-3.14.3-22.el6_6.x86_64.rpm 845a74c34377474614a69035b2741c8e2e420bfd98b37676cdbed09534fd84c4 nss-softokn-devel-3.14.3-22.el6_6.i686.rpm cb9d3dbde5a336160083312dc033ded182f2f811c1c2aa9ae5fe98dd5f59f0cf nss-softokn-devel-3.14.3-22.el6_6.x86_64.rpm c7de3e40ada40624174bd4aea2b3903b3f1dd71ab6ad16ed3a05e9d5574b2bc0 nss-softokn-freebl-3.14.3-22.el6_6.i686.rpm 1078c1194369da908b57512aa6f76655b26694f00106756e290852deda12742b nss-softokn-freebl-3.14.3-22.el6_6.x86_64.rpm 027aeee015b2281bebdb09ff87b34933380e3bfd79a40f28d14fd3983c730458 nss-softokn-freebl-devel-3.14.3-22.el6_6.i686.rpm 2dae21d39a4658bc2977f6119f177ec587af385a16b193c1da012d27bcb81849 nss-softokn-freebl-devel-3.14.3-22.el6_6.x86_64.rpm Source: db139757d5d628729ad254de68e45d8595c2727159d991388a93296e221b2c81 nss-softokn-3.14.3-22.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 5 Date: Thu, 29 Jan 2015 23:49:27 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0102 Important CentOS 7 kernel Security Update Message-ID: <20150129234927.GA23654(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0102 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0102.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 5953bcabb2801ceddffe79684dbef64022546b17d1cebb24a2151e0b2778a04a kernel-3.10.0-123.20.1.el7.x86_64.rpm 584521ddf9d103e9e869e22f50953f6232f9de6ea0a78ade5e9bdb081e7f17a9 kernel-abi-whitelists-3.10.0-123.20.1.el7.noarch.rpm cafb58042763975693af60cce298fd9d28aae34ba75e2d92b98d0eb94ae1ad82 kernel-debug-3.10.0-123.20.1.el7.x86_64.rpm 535b053dda66e67f163dc0dc05398d5ee0b8aecbc7192071cdf13f3f2f0075c1 kernel-debug-devel-3.10.0-123.20.1.el7.x86_64.rpm 81bc8dc435ff275160c5e3d63180924af1a96dd14307df2c6e7ea2232d86d3fe kernel-devel-3.10.0-123.20.1.el7.x86_64.rpm 39171964cd2f7baa878b6033d5b14d06d3251dd058f92b2237de3dcb3609b5a5 kernel-doc-3.10.0-123.20.1.el7.noarch.rpm a88bfde708df6f4c0e4a8f894c52812b50d4323e5e1f3912af163fc18a5245ce kernel-headers-3.10.0-123.20.1.el7.x86_64.rpm 36fe40c396d283c429e74204458da5883a5dc1047f4ed39c6395d44693c7f70a kernel-tools-3.10.0-123.20.1.el7.x86_64.rpm 05aeaf149987da5bc8e8fd927c4517f93cdb3df7519a48ada13363d944f836f1 kernel-tools-libs-3.10.0-123.20.1.el7.x86_64.rpm 755f49173741b2c38925cf6eeeae21f0aacfbe03257002af866f6114cb10a710 kernel-tools-libs-devel-3.10.0-123.20.1.el7.x86_64.rpm e4fbd51094a12cb9e44cc2c279e6415aa87bc6198eb794cb2cb18f6b586c6228 perf-3.10.0-123.20.1.el7.x86_64.rpm 98a1598f025b8c3c2029a7d30bbcfaabca3121562c5a64a5fb81c5875a910dac python-perf-3.10.0-123.20.1.el7.x86_64.rpm Source: c8c549348d11f6a676976c6a81ba1551b382f8bfd1cae8d1cd25cd2df6e754be kernel-3.10.0-123.20.1.el7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 6 Date: Fri, 30 Jan 2015 00:20:47 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0102 Important CentOS 7 kernel Security Update Message-ID: <20150130002047.GA43239(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0102 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0102.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 5953bcabb2801ceddffe79684dbef64022546b17d1cebb24a2151e0b2778a04a kernel-3.10.0-123.20.1.el7.x86_64.rpm 584521ddf9d103e9e869e22f50953f6232f9de6ea0a78ade5e9bdb081e7f17a9 kernel-abi-whitelists-3.10.0-123.20.1.el7.noarch.rpm cafb58042763975693af60cce298fd9d28aae34ba75e2d92b98d0eb94ae1ad82 kernel-debug-3.10.0-123.20.1.el7.x86_64.rpm 535b053dda66e67f163dc0dc05398d5ee0b8aecbc7192071cdf13f3f2f0075c1 kernel-debug-devel-3.10.0-123.20.1.el7.x86_64.rpm 81bc8dc435ff275160c5e3d63180924af1a96dd14307df2c6e7ea2232d86d3fe kernel-devel-3.10.0-123.20.1.el7.x86_64.rpm 39171964cd2f7baa878b6033d5b14d06d3251dd058f92b2237de3dcb3609b5a5 kernel-doc-3.10.0-123.20.1.el7.noarch.rpm a88bfde708df6f4c0e4a8f894c52812b50d4323e5e1f3912af163fc18a5245ce kernel-headers-3.10.0-123.20.1.el7.x86_64.rpm 36fe40c396d283c429e74204458da5883a5dc1047f4ed39c6395d44693c7f70a kernel-tools-3.10.0-123.20.1.el7.x86_64.rpm 05aeaf149987da5bc8e8fd927c4517f93cdb3df7519a48ada13363d944f836f1 kernel-tools-libs-3.10.0-123.20.1.el7.x86_64.rpm 755f49173741b2c38925cf6eeeae21f0aacfbe03257002af866f6114cb10a710 kernel-tools-libs-devel-3.10.0-123.20.1.el7.x86_64.rpm e4fbd51094a12cb9e44cc2c279e6415aa87bc6198eb794cb2cb18f6b586c6228 perf-3.10.0-123.20.1.el7.x86_64.rpm 98a1598f025b8c3c2029a7d30bbcfaabca3121562c5a64a5fb81c5875a910dac python-perf-3.10.0-123.20.1.el7.x86_64.rpm Source: c8c549348d11f6a676976c6a81ba1551b382f8bfd1cae8d1cd25cd2df6e754be kernel-3.10.0-123.20.1.el7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 7 Date: Fri, 30 Jan 2015 00:21:21 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0100 Moderate CentOS 7 libyaml Security Update Message-ID: <20150130002121.GA43359(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0100 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0100.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 27be0d9c4fdc9d6d7b83f141e70c7fea1ede9183686f9f4fcbaf4d7708492241 libyaml-0.1.4-11.el7_0.i686.rpm 01fe6b8eb0518670dc14b3095870a96cfcc75de6bf4769cd62c7d21109b13a65 libyaml-0.1.4-11.el7_0.x86_64.rpm 2802f4a924e386b02bab904c9cd2314692ae94821ac939054b420c79a9e21476 libyaml-devel-0.1.4-11.el7_0.i686.rpm cd06f287cb9fdd77e4b3a91d576ee9912959aecb818bd24d7797d04922827c50 libyaml-devel-0.1.4-11.el7_0.x86_64.rpm Source: f87eb345fdd5adac1236e7144286c6f6ba9f7e490dc84fc1e7c1930868aae5b9 libyaml-0.1.4-11.el7_0.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 119, Issue 12 ************************************************

1 0

CentOS 6.6: Webcam problem
by Ron Yorston 30 Jan '15

30 Jan '15

Last month we discussed the problems with webcams in CentOS 6 and I raised Bugzilla #1158988 with Red Hat. This bug has now been declared a duplicate of 1145805. Unfortunately I'm unable to access that report so although I know Red Hat are looking into the matter I don't know what they're doing. Ron

4 7

network copy performance is poor (rsync) - debugging suggestions?
by Götz Reinicke - IT Koordinator 29 Jan '15

29 Jan '15

Hi, I do have two centos 6.6 servers. With a "performance optimized" rsync I get an speed of 15 - 20 MB/s The options I use are: rsync -aHAXxv --numeric-ids --progress -e "ssh -T -c arcfour -o Compression=no -x" If I copy files by smb to/from the servers I do get 60 - 80 MB/s, a dd (r/w) on the storages attached gives 90 MB/s on the 1Gbit ISCSI (Source Server) and up to 600MB/s on the 10Gbit ISCSI (Destination Server) storage. Both servers have plenty of memory and cpu usage looks low. Currently we dont use jumbo frames. Network over all usage is moderate to low. There are no special sysctl tweeks yet in use. As mentioned, I'm confused that even with SMB I do get 3 to 4 times better performance. Any hint and suggestion to track that problem down is welcome! Thanks and best regards . Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 82 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Jürgen Walter MdL Staatssekretär im Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg Geschäftsführer: Prof. Thomas Schadt

9 12

Re: [CentOS] Kickstarting several *different* setups
by James B. Byrne 29 Jan '15

29 Jan '15

Ansible, Bcfg2, Chef, Cobbler, Puppet, and Salt; I notice that Spacewalk is not mentioned. Any particular reason that it gets no recommendations? What about CFEngine? Any comments on this one? -- *** 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

2 1

Re: [CentOS] Kickstarting several *different* setups
by James B. Byrne 29 Jan '15

29 Jan '15

On Tue, January 20, 2015 18:37, Les Mikesell wrote: > > There's also saltstack which is one of the newer of the bunch. It has > some chance of working reasonably across different platforms. How > you feel about it will probably depend on how you feel about python in > general - and how you expect upgrades to go in the future. > Is this what you are talking about? Available Packages salt.noarch 2014.7.0-3.el6 epel salt-api.noarch 2014.7.0-3.el6 epel salt-cloud.noarch 2014.7.0-3.el6 epel salt-master.noarch 2014.7.0-3.el6 epel salt-minion.noarch 2014.7.0-3.el6 epel salt-ssh.noarch 2014.7.0-3.el6 epel salt-syndic.noarch 2014.7.0-3.el6 epel -- *** 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

2 1

"Monitor" RPMs in Repo
by Markus "Shorty" Uckelmann 29 Jan '15

29 Jan '15

Hi all, Sorry for the bad subject. I'd like to do two things. - Know when a RPM which is currently in only one repository pops up in a different repository. E.g. RPM going from epel-testing to epel. - Get notified when a RPM pops up in a repository. E.g. waiting for an RPM to appear. I know that this is quite easy to find out manually. But did anyone build a script or something else to do this "automagically"? In my company we have a mix of self-build packages, epel-testing & rpmforge packages and some other obscure things. With something like I described above we would be sure when we could throw away the makeshift packages and transition to more or less stable packages from Base, Extra or EPEL. Cheers, Shorty

2 2

CentOS-announce Digest, Vol 119, Issue 11
by centos-announce-request＠centos.org 29 Jan '15

29 Jan '15

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. CESA-2015:0100 Moderate CentOS 6 libyaml Security Update (Johnny Hughes) 2. CESA-2015:0087 Important CentOS 6 kernel Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Wed, 28 Jan 2015 22:40:28 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0100 Moderate CentOS 6 libyaml Security Update Message-ID: <20150128224028.GA35225(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0100 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0100.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: e1cbe81e3041167ffaa66311a3aa2b1844988ec2b88f6387dc1ac2b83b2a2714 libyaml-0.1.3-4.el6_6.i686.rpm fc34f6a55ec35a240bb8adc5ceceb270f5d16cfa90a3df78a2ed244850cbafb7 libyaml-devel-0.1.3-4.el6_6.i686.rpm x86_64: e1cbe81e3041167ffaa66311a3aa2b1844988ec2b88f6387dc1ac2b83b2a2714 libyaml-0.1.3-4.el6_6.i686.rpm a2edbc9cda1d710f27d09af40f3780d9b69933e21e54d61c1c7400b03281ec2a libyaml-0.1.3-4.el6_6.x86_64.rpm fc34f6a55ec35a240bb8adc5ceceb270f5d16cfa90a3df78a2ed244850cbafb7 libyaml-devel-0.1.3-4.el6_6.i686.rpm 41226a5117f6e34f6c1028615742fef8a3acf663efbefa11b664c010e32c45c5 libyaml-devel-0.1.3-4.el6_6.x86_64.rpm Source: 80ee67196d7c279836002fc9d78667cacb09c26f87d441b02ddc1067fd7536b8 libyaml-0.1.3-4.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Wed, 28 Jan 2015 22:43:51 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0087 Important CentOS 6 kernel Security Update Message-ID: <20150128224351.GA35701(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0087 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0087.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 94ab95f3538737900c033c35b6cddab925c14e98c1b631fa053c8ff5f498461f kernel-2.6.32-504.8.1.el6.i686.rpm 93eec82ece225b086896b7c4f5f16af12a01f63e36584e1b6a5dbc6588a77427 kernel-abi-whitelists-2.6.32-504.8.1.el6.noarch.rpm fab5bf5c42f887a41d74ac6f9e5ce04e88c0174da5387f96d0f6ca79502ab279 kernel-debug-2.6.32-504.8.1.el6.i686.rpm bba6a3e485cb3bbe62601ea8b562dd68f1c40d7ab4817d9a48fa78467fe14127 kernel-debug-devel-2.6.32-504.8.1.el6.i686.rpm feba5bf77ba9999e8ceba3cdace5011789f287b8dc4ee13cec77f21e2b597466 kernel-devel-2.6.32-504.8.1.el6.i686.rpm 6607141df93f8942c97ec62efa6a94ef3f55f4edd1ec5170127fc6df5f6e233b kernel-doc-2.6.32-504.8.1.el6.noarch.rpm 267e47d4661ebe0d792e168ac8ab8cea13392ebc941bf4fb2555e8ba9f60d491 kernel-firmware-2.6.32-504.8.1.el6.noarch.rpm 7178d1695bb488a58dd68fe6f292bfaab89c95aaa97fc2bde172de2709cdf53c kernel-headers-2.6.32-504.8.1.el6.i686.rpm aae456c0f81e72e6e97ae801fb5a8bfd12a75eb2da64513130df451e274cc06a perf-2.6.32-504.8.1.el6.i686.rpm 4bff539dd14f78703fd024d81d7d567630a88f0669592b701c2e253f9bc3ab0b python-perf-2.6.32-504.8.1.el6.i686.rpm x86_64: b560c92df0e9bde6ca0c6f69422f68996631c48032b910e273cf29bae5975171 kernel-2.6.32-504.8.1.el6.x86_64.rpm 93eec82ece225b086896b7c4f5f16af12a01f63e36584e1b6a5dbc6588a77427 kernel-abi-whitelists-2.6.32-504.8.1.el6.noarch.rpm 999a188bf7b1bf4a2baa128ec5db0d7659bb032f88160d6f483ef40a60713d21 kernel-debug-2.6.32-504.8.1.el6.x86_64.rpm 40aad0abba0365c19f422db044285049dea4d023d8bcbdf48df26e6980e3f5ad kernel-debug-devel-2.6.32-504.8.1.el6.x86_64.rpm d569c488353082fbb24b980dcb5d9c7616203bafeee21917181a8055bb02bf54 kernel-devel-2.6.32-504.8.1.el6.x86_64.rpm 6607141df93f8942c97ec62efa6a94ef3f55f4edd1ec5170127fc6df5f6e233b kernel-doc-2.6.32-504.8.1.el6.noarch.rpm 267e47d4661ebe0d792e168ac8ab8cea13392ebc941bf4fb2555e8ba9f60d491 kernel-firmware-2.6.32-504.8.1.el6.noarch.rpm baa01c254be105e0e56b48f784813d5ec601460aa75c12b86eef96a581435b64 kernel-headers-2.6.32-504.8.1.el6.x86_64.rpm 9b9abc0f737dd4c3e15180c093395cb1a65e03c5afe94a0c8ae58852ec346284 perf-2.6.32-504.8.1.el6.x86_64.rpm 0151584f3e8196718572b4aaa4344398484cfbc6e5b4b131f0a00de99102fef6 python-perf-2.6.32-504.8.1.el6.x86_64.rpm Source: 468cf0e8fe7ed619fe4595a5139acce5fc7b62b28b3a821c9d030a38a2e2843a kernel-2.6.32-504.8.1.el6.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 119, Issue 11 ************************************************

1 0

CVE-2015-0235 - glibc gethostbyname
by Always Learning 29 Jan '15

29 Jan '15

Saw this on the Exim List:- From: Tony Finch <dot--at--(a)dotat.at> Subject: [exim] CVE-2015-0235 - glibc gethostbyname remotely exploitable via exim Date: Tue, 27 Jan 2015 17:33:45 +0000 "The Exim mail server is exploitable remotely if configured to perform extra security checks on the HELO and EHLO commands ("helo_verify_hosts" or "helo_try_verify_hosts" option, or "verify = helo" ACL); we developed a reliable and fully-functional exploit that bypasses all existing protections (ASLR, PIE, NX) on 32-bit and 64-bit machines. http://www.openwall.com/lists/oss-security/2015/01/27/9 --------------------------------- "- We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example." ------------------------------------- I use Exim on C5 and C6 - should I be worried about Exim on C6 ? -- Regards, Paul. England, EU. Je suis Charlie.

7 11

Apache and SSLv3
by Alessandro Baggi 29 Jan '15

29 Jan '15

Hi list, I'm configuring apache with https and I've a question about sslv3 deactivation. Running "openssl ciphers -v" I get a list of cypher suite of openssl like: ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ......... Each lines report relative protocol. Disabling sslv3 with "SSLProtocol all -SSLv3" I can use cypher like: ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 that has protocol SSLv3? Disabling SSLv3 protocol, apache will use only TLSv1.2 cypher protocol? Thanks in advance. Alessandro.

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss