Discuss

discuss@lists.centos.org

2 participants
34758 discussions

Re: [CentOS] https and self signed
by James B. Byrne 18 Jun '16

18 Jun '16

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree > with you in general (shorter period public key is exposed smaller > chance secret key brute-force discovered), Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant certificate generation and distribution simply increases the opportunities for key theft and tampering. Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. So having a guillotine date on a personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail 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

Getting hibernate to work on a new CentOS 7.2.1115 install
by Globe Trotter 18 Jun '16

18 Jun '16

Hi, I am a new CentOS user (quite familiar with Fedora 1-23+) and I decided to try a new install of CentOS on a ASUS R503U. However, I can not get hibernate to work. I try: systemctl hibenaate and I get: Failed to execute operation: sleep verb not supported Btw, the problem does not go away with super-user. I was wondering how to get around this issue. I would like the abililty to hibernate and come back in the last state. Thanks!

3 5

[Fwd: Re: https and self signed]
by James B. Byrne 17 Jun '16

17 Jun '16

On Fri, June 17, 2016 12:31, Valeri Galtsev wrote: > > On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > >> Keys issued to individuals certainly should have short time limits >> on them. In the same way that user accounts on systems should >> always have a near term expiry date set. People are careless. >> And their motivations are subject to change. > > James, though in general one is likely to agree with this, I still > consider the conclusion I came to after discussions more than decade > ago valid for myself. Namely: forcing everyone to change password > often pisses careful people off for nothing. Passwords they create > and carefully keep can stand for decades, and only can be > compromised on some compromised machine. But I never mentioned anything about passwords. I quite agree with you with respect to avoiding needless password churn. What I wrote was specifically user accounts and their expiry dates. These should be short. Say six to twelve months or so. When the account expires then it can be renewed for another six or 12 months. The password for it is not changed. One can always write a script to automatically search for and report pending expirations. There is no real need for accounts to actually expire. But, even if accounts do expire for active users then it is not much of a hardship to report the fact and to have them reactivated. On the other hand, disused accounts never get reported and remain deactivated. Also, when a person leaves our employ and somehow the cancellation of all or some their accounts gets overlooked in the out-processing then shortly their accounts will be deactivated automatically. A fail safe mechanism. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail 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

Would centos 7 backport this libnl3 header fix
by Harry Mallon 17 Jun '16

17 Jun '16

Hello, Would CentOS7 consider adding the following patch to libnl3? https://github.com/thom311/libnl/commit/cdf2d4baf376e4a3030a2c1169516358b4f… g++ fails to build against the headers in the default devel package at the moment so I am having to package my own. The patch is very small and easily applies on top of the c7 branch from the RPM git. https://git.centos.org/summary/rpms!libnl3.git Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry(a)codexdigital.com<mailto:harry@codexdigital.com> | T +44 203 7000 989<callto:+44%20203%207000%20989> Website<www.codexdigital.com> | Facebook<https://www.facebook.com/codexdigital> | Twitter<http://twitter.com/codexdigital> [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85…]<http://www.codexdigital.com>

2 1

Re: [CentOS] https and self signed
by Valeri Galtsev 17 Jun '16

17 Jun '16

On Fri, June 17, 2016 10:19 am, James B. Byrne wrote: > > On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: >> >> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >>> >>> I doubt that most users check the dates on SSL certificates, >>> unless they are familiar enough with TLS to understand that >>> a shorter validity period is better for security. >> >> Oh, this is what he meant: Cert validity period. Though I agree with you in general (shorter period public key is exposed smaller chance secret key brute-force discovered), > > Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant > certificate generation and distribution simply increases the > opportunities for key theft and tampering. > > Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. James, though in general one is likely to agree with this, I still consider the conclusion I came to after discussions more than decade ago valid for myself. Namely: forcing everyone to change password often sets careful people off for nothing. Passwords they create and carefully keep can stand for decades, and only can be compromised on some compromised machine. Now, from my (careful person) point of view, US National labs forcing me change password every 6 Months is just confirming the fact they imply their boxes are compromised often. As: my passwords (passphrases) are different everywhere, and I only connect one way ever: from trusted (maintained by me that is) machine to untrusted (maintained by someone else that is). Never from untrusted machine elsewhere. Now, simple argument we had: if you force person to change password often, even worse thing will happen: person will never remember ever changing password and the last will be written on a piece of paper stuck to the back of the screen or similar. Yes, I know about and I do use encrypted storage dedicated for passwords. Does everybody? Things change but people don't (almost don't). So, the best bet for multi-user machine is to run it under assumption that bad guys are already inside. Occasionally you see them attempting elevation of privileges, smash them, and make the user whose password was stolen change that, and change all his/her passwords everywhere, banks and other $$$ accounts first. After this sort of exercise this same person never is the one in this same sort of trouble. Yes I had these cases, not many during last decade and a half. I also have seen an opposite attitude on occasion (user didn't care his password was compromised on machine I administer), then that user had all [bad] what sysadmin can get him... > So having a guillotine date on a > personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed > servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? My point exactly. Only I usually try to say it in so short way, that my point fails to propagate to readers ;-( > > We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA > certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That > development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? Well, I started to avoid Lenovo after they shipped laptop with malware preinstalled. It took them some time after they bought laptop line from IBM. But yes, firmware/microcode malware is something that will bite us soon. BTW, the secret known to two people is not a secret.... Who said that? Cheers, Valeri > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > 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 > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

1 0

Speaking of firefox updates
by m.roth＠5-cent.us 17 Jun '16

17 Jun '16

I haven't gone past 38, because when the 45 update came out, and video... like, say, my *required* training from work, when I tried to run it, it crashed firefox. Repeatedly. 100% of the time. Has anyone been using the current version had trouble with video, etc? I'd like to update, but not if I can't do required training.... mark

2 6

Today's firefox update
by Frank Cox 17 Jun '16

17 Jun '16

Johnny's announcement refers to: firefox-45.2.0-1.el5.centos.src.rpm firefox-45.2.0-1.el6.centos.src.rpm firefox-45.2.0-1.el7.centos.src.rpm The linked rhel webpage refers to: firefox-45.2.0-1.el5_11.src.rpm firefox-45.2.0-1.el6_8.src.rpm firefox-45.2.0-1.el7_2.src.rpm These do not appear to be the same thing. Note the numbers just before the .src part of the filenames. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

4 4

Error: Could not find or load main class with OpenJDK and Oracle Java
by Alexander Farber 17 Jun '16

17 Jun '16

Hello fellow Linux users, on CentOS 7.2 I have successfully downloaded and installed Oracle Java [1] with: # rpm -Uvh jdk-8u91-linux-x64.rpm Also there is already OpenJDK installed: # rpm -qa | grep -i jdk java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64 java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64 jdk1.8.0_91-1.8.0_91-fcs.x86_64 I can switch between the 2 using this command: # alternatives --config java There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- * 1 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java + 2 /usr/java/jdk1.8.0_91/jre/bin/java Enter to keep the current selection[+], or type selection number: And see the selected version with: # java -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) # javac -version javac 1.8.0_91 Now to my problem please - I have created a simple java file named TheClassName.java: package thepackagename; public class TheClassName { public static final void main(String[] args) { System.out.println("Hello World!"); } } After successfully compiling it with "javac TheClassName.java" (which produces TheClassName.class file in the same dir) I unfortunately can not run it: # java -cp . thepackagename.TheClassName Error: Could not find or load main class thepackagename.TheClassName Here another try: # export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre # $JAVA_HOME/bin/java -cp . thepackagename.TheClassName Error: Could not find or load main class thepackagename.TheClassName Setting another environment variable does not help either: # export CLASSPATH=. Similar command on Windows 7 works well and I have tried copying the TheClassName.class file from there to Linux too. The setting is SELINUX=disabled and the server was installed few weeks ago, serving (without errors) as LAMP with MySQL/PostgreSQL/Apache/WordPress. Any suggestions please, have I missed anything? Regards Alex [1]: http://www.oracle.com/technetwork/java/javase/

1 1

CentOS-announce Digest, Vol 136, Issue 3
by centos-announce-request＠centos.org 17 Jun '16

17 Jun '16

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://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. Updated Vagrant Box's are now available : 1605 (Karanbir Singh) 2. CESA-2016:1217 Critical CentOS 6 firefox Security Update (Johnny Hughes) 3. CESA-2016:1217 Critical CentOS 5 firefox Security Update (Johnny Hughes) 4. CESA-2016:1217 Critical CentOS 7 firefox Security Update (Johnny Hughes) 5. CESA-2016:1237 Important CentOS 6 ImageMagick Security Update (Johnny Hughes) 6. CESA-2016:1237 Important CentOS 7 ImageMagick Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 16 Jun 2016 15:39:58 +0100 From: Karanbir Singh <kbsingh(a)centos.org> To: CentOS Announcements List <centos-announce(a)centos.org> Subject: [CentOS-announce] Updated Vagrant Box's are now available : 1605 Message-ID: <e9c5d74b-6b6f-6e55-04b7-f6fc1a991a11(a)centos.org> Content-Type: text/plain; charset=utf-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Updated Vagrant box's are now available for CentOS Linux 7/x86_64 and for the first time for CentOS Linux 6/x86_64; We are providing box's for Livbirt provider and the Virtual Box provider. ref: https://atlas.hashicorp.com/centos/boxes/6 https://atlas.hashicorp.com/centos/boxes/7 Release Notes for these images are published at : https://seven.centos.org/2016/06/updated-centos-vagrant-images-available / regards, - -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXYro+AAoJEI3Oi2Mx7xbtD0wH/258qtXogCXBwFDOId4d7PmV bRVyYp+i0wX+yG6xWrziDXjWoRB/xa+YUJX39qvhP2PGikJg7aj9K+z5DS9Y9Dfp hBMfmQ17MvIV53cfPeNnL06wSOZ+Y93awN7fr7It8nR4imAgXXouAX0YjDioOP2j GTteuu0ieyYU87sG/CZuHBGPgvsL4u5XVba19VY+0b12pv3z9kHJeHIwReQX3WVT 7C2cstXTsnEC/BYdbfPj+hFKRZGwuAiA5JDLN53eoOuQReIfnYfU2a/ugebTUH8G X12J64IaKDfCd6018DC+uUDtmaiFwXlxeaKyHqXO7m6EiCMQrhRty2CPNajVk08= =wR1K -----END PGP SIGNATURE----- ------------------------------ Message: 2 Date: Wed, 8 Jun 2016 23:13:32 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1217 Critical CentOS 6 firefox Security Update Message-ID: <20160608231332.GA55602(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1217 Critical Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1217.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: acc8466a5e2e7b4f97e476ef08608babd3957f9dea929ede45436549dd189940 firefox-45.2.0-1.el6.centos.i686.rpm x86_64: acc8466a5e2e7b4f97e476ef08608babd3957f9dea929ede45436549dd189940 firefox-45.2.0-1.el6.centos.i686.rpm 3c0badf351a25c811dce868afd434b9341a3da64018937be7bac76c39ecb5a42 firefox-45.2.0-1.el6.centos.x86_64.rpm Source: 733ca4db9bc0d6dcb4edc0d270299834e4b78b0f115025fd310146ce420380e2 firefox-45.2.0-1.el6.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Wed, 8 Jun 2016 23:28:21 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1217 Critical CentOS 5 firefox Security Update Message-ID: <20160608232821.GA24655(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1217 Critical Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1217.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 4f682310ef08803318d69e4044446dac5beab8bc046daf8e66ac5c1c4f95e373 firefox-45.2.0-1.el5.centos.i386.rpm x86_64: 4f682310ef08803318d69e4044446dac5beab8bc046daf8e66ac5c1c4f95e373 firefox-45.2.0-1.el5.centos.i386.rpm 95a69b243ad4569af34a05fc1806d826a665a38550abe275f93de0b4378ddf95 firefox-45.2.0-1.el5.centos.x86_64.rpm Source: 02393904e04805e7f719e8b2d47d0f63a639e788a7c0f9f9df13826db83edb74 firefox-45.2.0-1.el5.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: JohnnyCentOS ------------------------------ Message: 4 Date: Thu, 16 Jun 2016 15:30:39 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1217 Critical CentOS 7 firefox Security Update Message-ID: <20160616153039.GA61351(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1217 Critical Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1217.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: f79412140473a03de8d8f29357d9b4c6ce48cc2a0284c5a88f05fa28a6cf289d firefox-45.2.0-1.el7.centos.i686.rpm 4c9e18cfccc1942cc39ccb2644b308d4c381128f2ee39f4f735c34325354feb5 firefox-45.2.0-1.el7.centos.x86_64.rpm Source: 54784c2a92a040f721608d254a75f95cbab5ba33d436f63f20479145b486c334 firefox-45.2.0-1.el7.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 5 Date: Thu, 16 Jun 2016 23:05:59 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1237 Important CentOS 6 ImageMagick Security Update Message-ID: <20160616230559.GA7783(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1237 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1237.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 65c983e6e5121fe3739bef92b59f71c343a382b583ecc2ad29c536d48e354a74 ImageMagick-6.7.2.7-5.el6_8.i686.rpm 1ce7dfba86870708042cba5180c90d04e66067444192fad0c94cd89a64f8d25c ImageMagick-c++-6.7.2.7-5.el6_8.i686.rpm 3f5b4e728b60086914fb981d691bdf85c693119e4a9d4be21db3bc7c805e710a ImageMagick-c++-devel-6.7.2.7-5.el6_8.i686.rpm b84e69c4ae62329d7b39d9c872755056e08b1b749d8a527f8b77d1ce072854db ImageMagick-devel-6.7.2.7-5.el6_8.i686.rpm ae675e2b4041e3c5616f866eb200403e7a534ca485902b4216615907382fa89a ImageMagick-doc-6.7.2.7-5.el6_8.i686.rpm 78b1ee094571ea9cfe915c63cd9ad1a0406221c7428b08bd4521cc19635223c7 ImageMagick-perl-6.7.2.7-5.el6_8.i686.rpm x86_64: 65c983e6e5121fe3739bef92b59f71c343a382b583ecc2ad29c536d48e354a74 ImageMagick-6.7.2.7-5.el6_8.i686.rpm 7b18fce8ab88c27d216956e7719664cf1d4295483a2cd1558034d299f886185d ImageMagick-6.7.2.7-5.el6_8.x86_64.rpm 1ce7dfba86870708042cba5180c90d04e66067444192fad0c94cd89a64f8d25c ImageMagick-c++-6.7.2.7-5.el6_8.i686.rpm 9c64febc2372c91e557adfead3481b2d7c6c44aff7bc96061a97b3a0b3c1dcfc ImageMagick-c++-6.7.2.7-5.el6_8.x86_64.rpm 3f5b4e728b60086914fb981d691bdf85c693119e4a9d4be21db3bc7c805e710a ImageMagick-c++-devel-6.7.2.7-5.el6_8.i686.rpm 96874c4e1b25ce7dd6ab5754dae183d738f9092f128a7088fef6ba7d5df8dd2c ImageMagick-c++-devel-6.7.2.7-5.el6_8.x86_64.rpm b84e69c4ae62329d7b39d9c872755056e08b1b749d8a527f8b77d1ce072854db ImageMagick-devel-6.7.2.7-5.el6_8.i686.rpm 61b212db7fba37e77b24bdd29830da40af93bfc6fd435f14b13b48cb7fc4c99e ImageMagick-devel-6.7.2.7-5.el6_8.x86_64.rpm 2089a7c8bdec3d78fc317bf665050221a387f5388378dad3111d156733573647 ImageMagick-doc-6.7.2.7-5.el6_8.x86_64.rpm 8fb705c93e211aa5c177175c045fb848efd0fae691d8a97333508b73e06a7295 ImageMagick-perl-6.7.2.7-5.el6_8.x86_64.rpm Source: 426aa2c46e8591e4fafc55d1c7c32f5f154a0dd48b81afc1485f360c1871f565 ImageMagick-6.7.2.7-5.el6_8.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 6 Date: Thu, 16 Jun 2016 23:49:33 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1237 Important CentOS 7 ImageMagick Security Update Message-ID: <20160616234933.GA12051(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1237 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1237.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: c2381a8bc056204b610b111e957897b0992c3814d9a8e7dbdd304a85ac401aa8 ImageMagick-6.7.8.9-15.el7_2.i686.rpm b47a343b21df93744f88fa94eb049905763150f97804ed7971d0cdfad28e6bf8 ImageMagick-6.7.8.9-15.el7_2.x86_64.rpm 5a3ffb1e7eecb59304481181a6b0935e4fcd8ecadd0630a43934143d7c97be51 ImageMagick-c++-6.7.8.9-15.el7_2.i686.rpm 492fc944f8908199248f1fdba5b6c5a15aa1422aaece6eae899747380cb20d5f ImageMagick-c++-6.7.8.9-15.el7_2.x86_64.rpm f6f17de463a7378fc3ae7126d5d1112a26b1566c3e73051eaea4ac0dfec3408e ImageMagick-c++-devel-6.7.8.9-15.el7_2.i686.rpm 7106ca5a407e75158056c82bd2cd9ecbb112be6e29d599594d952c779bdd57f5 ImageMagick-c++-devel-6.7.8.9-15.el7_2.x86_64.rpm e0c9445f1d7a1b4a0ee97d7d1e3c6665667ebf84557f87227cbe7f1950930496 ImageMagick-devel-6.7.8.9-15.el7_2.i686.rpm 03f51bda15c581bcc6e56d5f24803c44ac46d56bf180058e93ddb39258cd1fbe ImageMagick-devel-6.7.8.9-15.el7_2.x86_64.rpm 8c5b7f5064340a04eb8cdbfb8a20d3e0cb11d6867ef64820fd9edc7be89c7329 ImageMagick-doc-6.7.8.9-15.el7_2.x86_64.rpm feb0024d0d98cb90f3dc02b08af565548ac9d6e0b9548a7af2fc0b1d66289b4f ImageMagick-perl-6.7.8.9-15.el7_2.x86_64.rpm Source: 401974be1ac1a9e64fe9a8d8a0d8ee9a32fbf8deef2ee23ad7e37c0f43a9d184 ImageMagick-6.7.8.9-15.el7_2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 136, Issue 3 ***********************************************

1 0

Installing 6.8 from DVD1.iso, changes
by Zube 16 Jun '16

16 Jun '16

Downloaded 6.8 DVD1.iso, dd to stick. Went through same selections I have gone through since 6.2, only this time it got to the end and stated it couldn't find rear, which is under "backup client". OK, try it again without rear. This time it's yum-plugin-ovl from base (?). Then chrony, also in base (?). Then flightrecorder, libreswan, at least 2 of openmpi & co. and finally unbound, which is a rather apt description of my current mental state. So, a heap of stuff has either moved to DVD2 or is new and lives on DVD2. The same set of selections, especially if you choose all the optional packages of a group, may not work as they previously did in the install of <= 6.7. Cheers, Zube

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss