Discuss

discuss@lists.centos.org

34758 discussions

Start a nNew thread

about repository
by TheIsmaelAzman . 11 Feb '15

11 Feb '15

i am offering my storage for the download mirror link for the centos. is there any guide? thank you.. ismael

2 1

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

11 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:0162 CentOS 6 augeas BugFix Update (Johnny Hughes) 2. CESA-2015:0165 Moderate CentOS 6 subversion Security Update (Johnny Hughes) 3. CESA-2015:0166 Moderate CentOS 7 subversion Security Update (Johnny Hughes) 4. CESA-2015:0164 Moderate CentOS 5 kernel Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Feb 2015 14:29:12 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0162 CentOS 6 augeas BugFix Update Message-ID: <20150210142912.GA29085(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0162 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0162.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 830e112850754e1e366d87813eeab40dca1465b08759cf1d5944d1372284fdc3 augeas-1.0.0-7.el6_6.1.i686.rpm a0a6a000351426710831fbe0f529a69cf5e9c125348b7e7b288d928d1df4609a augeas-devel-1.0.0-7.el6_6.1.i686.rpm 48980fbfc8f19e665036b8dd3cbdbce079536f361bfec7f7133130156f2f3921 augeas-libs-1.0.0-7.el6_6.1.i686.rpm x86_64: bfffb8078feca3c4509ec20529d5683562f49c223d40bb74e8ec3d2b584f1db6 augeas-1.0.0-7.el6_6.1.x86_64.rpm a0a6a000351426710831fbe0f529a69cf5e9c125348b7e7b288d928d1df4609a augeas-devel-1.0.0-7.el6_6.1.i686.rpm 97fdfb8da2056af339026d3894e288505ffd4c850726c6d53cd7187ab11e2b2d augeas-devel-1.0.0-7.el6_6.1.x86_64.rpm 48980fbfc8f19e665036b8dd3cbdbce079536f361bfec7f7133130156f2f3921 augeas-libs-1.0.0-7.el6_6.1.i686.rpm 7bece2edec3fd7439b8928bfe02d37745008e95758bbe0e72d23a1a8442595ee augeas-libs-1.0.0-7.el6_6.1.x86_64.rpm Source: e113f6d4d6f55466fcb66b7055209779f701bea3a8bdf33020d016fe7ed09a29 augeas-1.0.0-7.el6_6.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Tue, 10 Feb 2015 22:32:42 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0165 Moderate CentOS 6 subversion Security Update Message-ID: <20150210223242.GA48394(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0165 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0165.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 32a3927ae4971b23bc81f9123363306d8d9a5939b139a3c802de82e5b79644bb mod_dav_svn-1.6.11-12.el6_6.i686.rpm 6c23fef4443d27c6e82193bdfbdda82b7898093c1006615dbcc75e3cf68a815a subversion-1.6.11-12.el6_6.i686.rpm 6cc1d25aa4ac53e913242ec41159d8de42fadb871384062e45fffecb1d31e175 subversion-devel-1.6.11-12.el6_6.i686.rpm 6596246e0c441e32c50e6c90c016a714c6c6b0c6ce109c2a69992bbcdb7c00ac subversion-gnome-1.6.11-12.el6_6.i686.rpm 1ed02f11d33fd55628ff0d97f2c4b2a901431f9340c59bdb862db3aef6f4dd6a subversion-javahl-1.6.11-12.el6_6.i686.rpm e8a59903e9b33553cf4b1dffe1e191d331496a4e56afdb22dad22eca9c08b2e6 subversion-kde-1.6.11-12.el6_6.i686.rpm 32906e72f51ff99aa406438d53e538ea2cf7b5e90d84d05258a3a74e8fe329df subversion-perl-1.6.11-12.el6_6.i686.rpm 2efa70361dd48f5ebdf2cf5a85f0e58a748760483e6573c37c99e2c2ea12d5b4 subversion-ruby-1.6.11-12.el6_6.i686.rpm 768cf02d302b8469f9d3960c7bcfecc0358b67e48b389e057db5689d64d43a37 subversion-svn2cl-1.6.11-12.el6_6.noarch.rpm x86_64: cfe4ec1671cf414256ebdf9453c2395084cec939c33f2fecc78adfca6a7e2f05 mod_dav_svn-1.6.11-12.el6_6.x86_64.rpm 6c23fef4443d27c6e82193bdfbdda82b7898093c1006615dbcc75e3cf68a815a subversion-1.6.11-12.el6_6.i686.rpm 870fc0650e8d86a5e48c4628d6b67d52c20a751e51e6a232e54a4b20b1fb7efa subversion-1.6.11-12.el6_6.x86_64.rpm 6cc1d25aa4ac53e913242ec41159d8de42fadb871384062e45fffecb1d31e175 subversion-devel-1.6.11-12.el6_6.i686.rpm e431d9f4b9790c57e42e9148ffcf13ca00ce688e3c22ab61a128aff3bb73daaa subversion-devel-1.6.11-12.el6_6.x86_64.rpm 6596246e0c441e32c50e6c90c016a714c6c6b0c6ce109c2a69992bbcdb7c00ac subversion-gnome-1.6.11-12.el6_6.i686.rpm 22fe7bcc6134958b412fc10381341810a5d3a3e70c9c360aba782936c189a4d3 subversion-gnome-1.6.11-12.el6_6.x86_64.rpm 1ed02f11d33fd55628ff0d97f2c4b2a901431f9340c59bdb862db3aef6f4dd6a subversion-javahl-1.6.11-12.el6_6.i686.rpm 0e79ef2ce0f6897b4802be09c2f9f6fe9b737cfda476732cc191e615b57422bb subversion-javahl-1.6.11-12.el6_6.x86_64.rpm e8a59903e9b33553cf4b1dffe1e191d331496a4e56afdb22dad22eca9c08b2e6 subversion-kde-1.6.11-12.el6_6.i686.rpm f7bc0a34c739ccb42822099d9d137b53af5f5cd1dcf5102fb71f7966d527b82f subversion-kde-1.6.11-12.el6_6.x86_64.rpm 32906e72f51ff99aa406438d53e538ea2cf7b5e90d84d05258a3a74e8fe329df subversion-perl-1.6.11-12.el6_6.i686.rpm a4f559b9031bb7671ad0885d94c91b0aee15b7a1894a845cdd876e08540ec467 subversion-perl-1.6.11-12.el6_6.x86_64.rpm 2efa70361dd48f5ebdf2cf5a85f0e58a748760483e6573c37c99e2c2ea12d5b4 subversion-ruby-1.6.11-12.el6_6.i686.rpm db41dfd9c8b081d35e3931757813a551fe3ddbec09bfe7f2a94b6cb5b192fe9f subversion-ruby-1.6.11-12.el6_6.x86_64.rpm 768cf02d302b8469f9d3960c7bcfecc0358b67e48b389e057db5689d64d43a37 subversion-svn2cl-1.6.11-12.el6_6.noarch.rpm Source: 2044b1b915eec1cc021681fd599cbf2fd37106670883426e2e24c08d1d45095f subversion-1.6.11-12.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Wed, 11 Feb 2015 00:09:48 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0166 Moderate CentOS 7 subversion Security Update Message-ID: <20150211000948.GA59999(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0166 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0166.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: ad1d62c0aa11709378918e05cd8f66425901af7759d8ef8119918991bc4a1dcd mod_dav_svn-1.7.14-7.el7_0.x86_64.rpm 4095d987c67eb61556befe167d0f74ad0b777f1a4fe1a94b24441c94b283e933 subversion-1.7.14-7.el7_0.i686.rpm f63835d6f425a1628c58afdb484cb89de3bd1e26869dee151b665f2472e6e48a subversion-1.7.14-7.el7_0.x86_64.rpm 51ca7f8c8a5413385f99f6dd0acddce223603f7a9f3718983bc5c99eb01ad40d subversion-devel-1.7.14-7.el7_0.i686.rpm 8f612efc6b30488c81e08597cf653f55897a6b837bf4236252e0c9afdc478975 subversion-devel-1.7.14-7.el7_0.x86_64.rpm 7ffc0bf23a85735e8444c4641c186e7c5a4d8cb57b883301c9038fac2b18f49f subversion-gnome-1.7.14-7.el7_0.i686.rpm 201a8e4b1971d99e45e705004361b0a6ba8165bd1690a5352acdc82035247d25 subversion-gnome-1.7.14-7.el7_0.x86_64.rpm ae5430e9cfcbfd5bc2655827f4cfcc7c57c7301c8402b632c1ee0a8db03bae34 subversion-javahl-1.7.14-7.el7_0.i686.rpm 26335d6ee4935df7332fd8e2160da8439a03d5ad0777f4e86edb2fa0335874be subversion-javahl-1.7.14-7.el7_0.x86_64.rpm af9c6ade8371afde8f05b7d74bae455c75065804fc3dba52e7fec1868d02ac3e subversion-kde-1.7.14-7.el7_0.i686.rpm 7ebb23191473eb503dd2a960e014406dcbc86cde1fd9a9651d83732c65049ec3 subversion-kde-1.7.14-7.el7_0.x86_64.rpm 43ad268e519c29af89eefcd9cd785189bfcb1953398ac4a4b0ae5b0ec8e51726 subversion-libs-1.7.14-7.el7_0.i686.rpm 88de3d6dde9da26988a107be00f10726b27a00f530f5529b4bc24ad924c89618 subversion-libs-1.7.14-7.el7_0.x86_64.rpm 1ea88f946da1d932fa4b1b123eae486dd0dd599e6b6368c31f701b8603538a99 subversion-perl-1.7.14-7.el7_0.i686.rpm 2855e7f06197f820ae35ed99be61fbf39b36df38cfcdd8dfe1221af0ad62b606 subversion-perl-1.7.14-7.el7_0.x86_64.rpm c912c363a08ac2cdcb7ffab146a1b20c825df729883051d8e558a7a5384ad7ac subversion-python-1.7.14-7.el7_0.x86_64.rpm 346e2e09bfd19ca048ff437999e02136ac8d58670c2df9c3ab14097dcf83c257 subversion-ruby-1.7.14-7.el7_0.i686.rpm fe1a3f846fa82245479230d0ae834ceefee70756dc41f015dd57736fadcae0f0 subversion-ruby-1.7.14-7.el7_0.x86_64.rpm b4a223ec01851dbc0add439b90e8de40597e3ea21b054903a3a2794597df960a subversion-tools-1.7.14-7.el7_0.x86_64.rpm Source: 80de3e657ce5343d61d45c3b52453a23d3ac6d069aab1186996ee3d91370b455 subversion-1.7.14-7.el7_0.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Wed, 11 Feb 2015 05:47:40 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0164 Moderate CentOS 5 kernel Security Update Message-ID: <20150211054740.GA23002(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0164 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0164.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: fbc6e365d23d3da286bf9bded550eabd318a21040f34fa096f1738ebb085767a kernel-2.6.18-402.el5.i686.rpm d477e8c147231636fb3b4ff56faba8aab779e2879e17fc04572bc8807988e472 kernel-debug-2.6.18-402.el5.i686.rpm 03fa9ae6513e5d2a707af5f4bccd8b1015c84b2bfbc7d1d10d6c80e1ad9a93f9 kernel-debug-devel-2.6.18-402.el5.i686.rpm 231997d5368ad7f96cd257cbf18cfcfbe430696d8af4f3974aa11d4016e30b60 kernel-devel-2.6.18-402.el5.i686.rpm 6acd771664c710e4ab60e2411f445346f277993525db15f67369ecf6960fc8ac kernel-doc-2.6.18-402.el5.noarch.rpm 7acf02229076c89de3aaca3d30362b37bb2d13a472031a30aaf81160489bbc0f kernel-headers-2.6.18-402.el5.i386.rpm 4b6e411599708a2fd881009b5dcbd676af58827b96cccb082cb3f5854f1871e9 kernel-PAE-2.6.18-402.el5.i686.rpm d75baea1b6c5d5027c7f9d75408ca0bf63efca74fe3f36bbd257dbe5f3fd4288 kernel-PAE-devel-2.6.18-402.el5.i686.rpm 2dd5a0cd5c2b15081026fe5ece64a9ae32d6ae306fa807f50211b871f68e58df kernel-xen-2.6.18-402.el5.i686.rpm 493f77a0af04025edbdc0350488477f39752ba59d4765efcb49f427bb6dfd761 kernel-xen-devel-2.6.18-402.el5.i686.rpm x86_64: e2d3e0ca21641dac3412c38d076ea849f5269a607be6146edad1952efa67ec5e kernel-2.6.18-402.el5.x86_64.rpm 5ab8f391d375c1fefcbc570d9bd1293fbee2140c1c6e6a8fa8ab73554b1fe24b kernel-debug-2.6.18-402.el5.x86_64.rpm cfaf3065d7e69629c50cbe3b4d9178b93f8cdfc30e85e74811fddb91d8357a25 kernel-debug-devel-2.6.18-402.el5.x86_64.rpm 1d562cbc7192f4fb46cc77d123adfbfe30e31c30ed37edcef568fd529954e888 kernel-devel-2.6.18-402.el5.x86_64.rpm 6acd771664c710e4ab60e2411f445346f277993525db15f67369ecf6960fc8ac kernel-doc-2.6.18-402.el5.noarch.rpm 2041c9eb7f889c907f34c1e04749304f69298f352f2ba7d19f2c3d726fda8726 kernel-headers-2.6.18-402.el5.x86_64.rpm 53be0ecf7943ece4f03c815af776891f8901c8faf589bf1fff0aa05684a13248 kernel-xen-2.6.18-402.el5.x86_64.rpm e416468d318e5af8228ec6e1248fb5f3b60b656827b6232f47f6918bc224c872 kernel-xen-devel-2.6.18-402.el5.x86_64.rpm Source: bf2745e93b295e13bb88c3d10304f0403cb943373110f26db204c75704df7000 kernel-2.6.18-402.el5.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 4 ***********************************************

1 0

CentOS 7 : create RAID arrays manually using mdadm --create ?
by Niki Kovacs 11 Feb '15

11 Feb '15

Hi, When installing CentOS 7, is there a way to 1. leave the GUI installer and open up a console 2. create RAID arrays manually using mdadm --create 3. get back in the GUI installer and use the freshly created /dev/mdX arrays? I tried to do this, but the installer always exits informing me that he can't create the RAID arrays (since they're already created, duh). Any suggestions? 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

4 8

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

11 Feb '15

On Sat, January 31, 2015 05:14, Johnny Hughes wrote: > On 01/30/2015 06:09 PM, Scott Robbins wrote: >> On Fri, Jan 30, 2015 at 11:27:55PM +0000, Marko Vojinovic wrote: >>> On Fri, 30 Jan 2015 14:15:05 -0800 >>> Akemi Yagi <amyagi(a)gmail.com> wrote: >>>> On Fri, Jan 30, 2015 at 2:04 PM, Scott Robbins >>>> <scottro(a)nyc.rr.com> >>>> wrote: >>>>>> >>>>>> Centos 7 does that as well. >>>>> Heh, I guess I've used good passwords in my installs then. >>>> >>>> I have to tap it twice all the time. But don't tell this to >>>> anyone! ;-) >>> >>> OP's point is that probably in RHEL8 you won't be able to do even >>> that anymore. >> >> Exactly. There is some complaining going on on the Fedora testing >> list, >> not sure where else one can protest. >> > > Well, protesting here would be meaningless .. as is protesting systemd > here. CentOS-8 will have whatever is in the RHEL-8 source code, > exactly > as it is in that source code minus branding. Just like CentOS-2.1, 3, > 4, 5, and 6. Our goal is to rebuild the source code exactly, bugs and > all. We want all the behaviors and the experience to be identical in > every way. > > If you want to effect change before it gets in RHEL, then Fedora is > the place. If you want to get it changed in CentOS, then buy RHEL > and providing feedback there is the way. We are, by design, exactly > as Red Hat pushes the RHEL source code. > Reading between the lines of the Fedora list discussion leads me to the conclusions that: 1. The password strength decision is driven by RH corporate. 2. There is not going to be any back-off by the developers. 3. This is going to be in RH-8. 4. There is absolutely no rational argument that can be made to anyone alter any of this. 5. Protesting there is evidently meaningless as well. The Fedora Server WG has already asked that this be optionally enforced if it cannot be removed. Answer: No. This change was not discussed, it was announced. There has been zero support for it from the community and a large amount of criticism. All requests for information respecting the rational and evidential support driving he change are met with what can only be described as political doublethink amounting to: See the unrelated discussion on this thread over here; and when you discover that it has nothing to do whatsoever with your request then see that tangential thread over there; and when you persistently return to your original request because there is no answer in either then be told that you are a conspiracy theory nut-case. > On Fri, Jan 30, 2015 at 2:49 PM, Chris Murphy > <lists at colorremedies.com> wrote: > On Fri, Jan 30, 2015 at 1:21 PM, Adam Williamson > <adamwill at fedoraproject.org> wrote: >> On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote: >>> What's the actual, real world, >>> non-imaginary impetus behind the change? >> >> It's exactly what all the list posts I pointed you to say it is. > > Please go find quotes because I just went through them all and I > found: > > "Better security is always a plus." > > "Instead I propose that we increase our minimum password..." > > "In principle I don't disagree with it; But IMO it can not be > a replacement to stronger defaults." > > And that's it. No actual reasons, let alone any data to back it up. > And all three of those statements have flaws which I've already > addressed. > >> I don't know how to stop the conspiracy virus which causes >> people to leap to the conclusion that there's some shadowy >> secret motive behind every change they don't like, but there >> *isn't*. ( Odd, is it not, that Mr. Williamson professes that there is no secret motive but cannot actually provide one when asked. ) The most telling line in the entire thread, for me, is this one: On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote: > When you stop trusting me. I stop trusting you. And that's a > huge problem, and thus far the engineering types are looking > at this with narrow vision, it's 2 more key presses. They > aren't looking at this at all from the perspective of its > connotation. Personally, from the outside looking in, this all smells of a pointy haired boss directive that the devs are trying to cover their collective asses from. Of course, my corporate days are long behind me so perhaps things have changed. Equally it could be simple incompetence by highly strung people that do not like being criticised for an ill-considered hasty decision but who actually have no evidence to support it. I have to go off now and find a nice bone bed to lie down in; and fossilize. -- *** 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

23 194

LUKS on EL6 / enable block device after reboot
by Leon Fauster 10 Feb '15

10 Feb '15

Is there an easy way (cli) to enable a luks encrypted partition after reboot (a partition that was not enabled while booting, because not in the crypttab). I can execute the necessary command stack [1] but just wondering if there is an "enterprise/easy" way to do that ... [1] cryptsetup luksOpen $(blkid -t TYPE="crypto_LUKS" -o device) \ luks-$(cryptsetup luksUUID $(blkid -t TYPE="crypto_LUKS" -o device)) -- LF

2 1

Re: [CentOS] KISS networking with CentOS 7
by Niki Kovacs 10 Feb '15

10 Feb '15

Le 10/02/2015 17:20, m.roth(a)5-cent.us a écrit : > Please explicate - offlist is fine. I really dislike the naming > convention.... I was installing on a new HP dl560 g8, and it came up with > ensf1 (which is*great* fun if you're trying to do a pxeboot build....) The CentOS FAQ explains how to restore the traditional naming scheme: http://wiki.centos.org/FAQ/CentOS7#head-31ebc6642958a0df12304d6aab9a49034a3… That being said, everything works fine now with the new interface names. I guess I'll just have to get used to it. Feels a bit like FreeBSD. :oD 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

4 4

Central hostname management?
by Niki Kovacs 10 Feb '15

10 Feb '15

Hi, Our local school has a 100 % Slackware Linux network with two servers and 14 desktop clients. The main server is running Dnsmasq, and he's providing static IP addresses to the desktop clients. Hostnames are also managed centrally. All client machines only have this in /etc/hosts: 127.0.0.1 localhost.localdomain localhost And in /etc/HOSTNAME: localhost.localdomain The hostname gets sent to each of the desktop clients by the server. The big advantage is I can manage everything centrally from the server. One line in /etc/dnsmasq.conf, and that's it. Client installs can all be cloned with Ghost4Linux. Now I'm trying to do the same thing on CentOS 7. /etc/hosts: 127.0.0.1 localhost.localdomain localhost (IPv6 is disabled) /etc/hostname: localhost I'm experimenting with all this while reading the RHEL Networking Guide. I understand CentOS 7 is using hostnamectl to manage the hostname. In that case, what do I have to do? Can hostnamectl be somewhat disabled and/or removed? 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

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

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