devel May 2015

devel@lists.centos.org

36 participants
31 discussions

[SIG Hardening] hardening classes
by Tim 11 May '15

11 May '15

Hi all, I know this SIG is still founding, but I like to discuss classes of hardening. I imagine security assessment classes (SAC) like: SAC1: low SAC2: middle SAC3: high SAC4: very high Every selective measure (e.g. disabling user list) could be put into these classes where every class depends on the underlying one (2 on 1, 3 on 2, etc.) What's your opinion? Regards Tim

6 13

Proposal to cancel the CBS meeting scheduled for 11-May-2015
by Brian Stinson 10 May '15

10 May '15

Hi Folks, Since there's not anything that needs urgent discussion, and since I'll be travelling for much of the day on Monday I propose we cancel this week's CBS/Infra meeting. If there are topics that need action, please reply here and we can handle them on-list. Hope you're all having a great weekend! Brian -- Brian Stinson brian(a)bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

2 1

The CentOS Project Visual Identity Structure
by Alain Reguera Delgado 08 May '15

08 May '15

Hello Everyone, I am wondering if we could have a talk about CentOS visual identity, so to consolidate the path to follow and coordinate further efforts in this matter. There are two points I would like to call attention to. The first one is the visual structure of CentOS Project (see http://wiki.centos.org/ArtWork/Identity). The second one is the CentOS Project logo (see http://wiki.centos.org/ArtWork/Brand/Logo). In the very specific case of CentOS Logo it is necessary to note that it is being used in different manners in official places. This affects the strength of the CentOS brand. For example, consider the construction described in the wiki page above and the logos shown in wiki.centos.org, bugs.centos.org and mirror.centos.org sites. Although they are similar they aren't exactly the same. The construction I propose in the wiki is based on the CentOS logo published in the sources of CentOS 5. In these files, the CentOS logo is entirely plain and does not have any ornament (like shadow or bright) on it. I am planning to put ready-to use CentOS logos files in SVG format in the wiki and I would like you to express your opinion in the correct CentOS logo that should be used so we can unify this and give more strength to CentOS Project visual identity. Best Regards, al.

3 5

Fwd: [Cloud SIG] BOF/Meetup space at Summit?
by Rich Bowen 08 May '15

08 May '15

FYI, the RDO project has been assigned a slot for our BoF session. It will be Thursday, 9:50am - 10:30am, and is listed in the schedule at https://www.openstack.org/summit/vancouver-2015/schedule/ Note that this is during regular conference sessions, so be sure to check that time period on the schedule, and try to make it to this event if at all possible. The agenda for the event is at https://etherpad.openstack.org/p/RDO_Vancouver and includes discussion of our participation in the CentOS Cloud SIG. Thanks! -------- Forwarded Message -------- ... May 7, 10:17 Hi Rich, Thanks! Your BoF session will be on Thursday from 9:50am - 10:30am in East Building, Room 10. This session will be added to the official schedule in the next couple of days.

3 2

Signed repomd.xml.asc files for CentOS-6 and CentOS-7 (testing)
by Johnny Hughes 08 May '15

08 May '15

We are looking at the possibility of providing signed repomd.xml.asc files for all CentOS controlled repos for CentOS-6 and CentOS-7. I have created an update repository for CentOS-6 and CentOS-7 for testing. They are not going to be maintained current (and are already a couple of updates behind) and should *NOT* be used in production ... but if we can get some people to test these on some testing platforms that would be great: http://dev.centos.org/centos/6/updates/x86_64/ http://dev.centos.org/centos/7/updates/x86_64/ Basically, to use signed metadata for these testing repos, you would need to modify the /etc/yum.repos.d/CentOS-Base.repo and do the following to the 'updates' section: 1. Remark out the current mirrorlist and/or baseurl statements. 2 Add the following: For CentOS-6: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/6/updates/x86_64/ For CentOS-7: repo_gpgcheck=1 baseurl=http://dev.centos.org/centos/7/updates/x86_64/ ================================ *DO NOT USE THESE REPOS FOR UPDATES LONG TERM, THEY ARE FOR TESTING ONLY* ================================ One thing we would like to figure out (and then tes)t is the ability to somehow get this key to be added automatically via a kick start so that one can use signed metadata for unattended installs. Without testing and feedback, and possibly key auto import capability, this proposal will likely go nowhere .. so if this is a feature that you want, please test and provide feedback and help us find a solution for auto import of the yum key. Thanks, Johnny Hughes

4 7

Building a downstream CentOS Atomic Host
by Karanbir Singh 07 May '15

07 May '15

Hi, One of the things that the Atomic SIG will attempt to do is build a downstream CentOS Atomic host, that is modelled on the RHEL Atomic host. Most code and info needed for this is now available, and its a good point to think about the build, release process. I've attached a map of what that might look like. Think of it as a proposal. Some of the things that are marked with red stars are things that we will try and help, from the Core SIG, to get this process onramped - but largely we are looking at community and SIG involvement here with the aim that the entire process can be offload ( taken over ? ) but the community. This process proposed here very closely maps to the Core CentOS Linux process. I would very much like to hear comments and thoughts around this from everyone on centos-devel, specially around areas where people can help. 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

9 29

Self Introduction [GSoC]
by kunaal jain 07 May '15

07 May '15

Hi guys, I am Kunal Jain from India doing my undergraduate studies in Computer Science from Indian Institute of Technology Guwahati (IITG). I and Lei will be creating a new toolchain that will lower the barrier for contributing new content under the mentor-ship of Karsten this summer. I look forward working with you guys. More details : http://lists.centos.org/pipermail/centos-docs/2015-May/005647.html Regards, Kunal Jain

1 0

moving from gitorious
by Karanbir Singh 07 May '15

07 May '15

Hi, We have some of our content currently hosted on gitorious.org that we mirror from git.centos.org - the intention being that git.centos.org is still the authority, but people can use the easier contribution path at gitorious to build karma and then get direct git commit access at git.centos.org since gitorious is going away, what are everyone's thoughts to consolidating all of this external contribution path on github.com/CentOS - we already host a bunch of content there. 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

10 17

CentOS SCLo SIG sync-up meeting on #centos-devel (2015-05-06)
by Honza Horak 06 May '15

06 May '15

SCLo SIG meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * sync-up on current status * propose some other topics :) Honza

1 0

Fixing up Xfce for CentOS 7
by Toni Spets 01 May '15

01 May '15

Hello list, I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release. What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better. Here are some initial things that we think are critical (give or take, Anders has his own list): 1. Packaging issues - comp group @xfce-desktop doesn't depend on @X Window System so it doesn't really work and has some wrong packages and some missing - @xfce-desktop depends on gdm instead of lightdm, we think it should do that instead - dejavu sans fonts are not a dependency and fonts are broken because of that - gtk-xfce-engine package is missing (EPEL7) 2. Branding issues - "Default" appearance theme is missing (requires gtk-xfce-engine, request sent to EPEL) - default background is blank (broken Fedora branding, patch submitted) - default icon set is wrong and broken (should be GNOME because "Fedora" doesn't exist on RHEL, patch submitted) There are more, but these are one of the first usability issues that you would hit when installing Xfce from EPEL 7. I have submitted bug reports with proposed fixes for the background issue, default theming issue and missing gtk-xfce-engine package: https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124 Now, getting EPEL fixed up would be in general a good effort since it's shared between all derivatives of RHEL/CentOS and more people will get the base benefits. That said, there are two ways this SIG could be constructed: a) shim wrapper around EPEL to create a spin and possibly add some CentOS specific branding, give EPEL maintainer all the help we can to get the packages working, try push most if not all packaging work to EPEL b) completely replace EPEL by our own repo which has all the Xfce packages and anything we would want The A option depends on if the maintainer is willing to let us help as much as we want and would accept some of the changes we'd need. It would also imply the current EPEL maintainer(s) would continue maintaining and be our upstream or someone would join the EPEL folks as co-maintainers. The amount of initial work would be minimal compared to doing everything custom and as I said before, it benefits every RHEL derivative, including RHEL itself. We still need some SIG specific packages like CentOS specific branding and possibly our own default panel layout so it's not all upstream work. This approach might also be tad slower because we have an upstream and all packaging stuff except barnding would go through them. The B option gives us more power and could speed up the process a lot. We can select and backport the set of Xfce packages as fast as we can.Karanbin Singh was kind enough to provide some info about how CentOS SIGs work and what resources would be available (automatic builds, official SIG repos etc.) so all the backend stuff is there waiting to be untilized for this kind of SIG. However, this approach would be very CentOS specific and would require the SIG to be fairly active in maintaining the packages when our upstream (the Xfce project) makes point releases. I can say upfront that person wouldn't be me, so if someone is up to this after the initial sprint of work has ended, that would be something to consider. One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core. I'm up for either one, it's up to what you other people would see as being more useful. Maybe both if there is enough interest? Fix EPEL for the greater good and still have our own SIG 4.12 stuff on top of it for CentOS only. Anyone into this except me and Anders? Ideas, suggestions? -- Toni Spets

8 16

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel May 2015