Discuss February 2015

discuss@lists.centos.org

153 participants
158 discussions

Start a nNew thread

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

07 Feb '15

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss February 2015