devel April 2015

devel@lists.centos.org

63 participants
50 discussions

Re: [CentOS-devel] Hosting CentOS bugs on RH bugzilla
by Marcin Dulak 15 Apr '15

15 Apr '15

Hi, i would like to add some more to the discussion started at http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html 1. On the plot attached to http://bugs.centos.org/view.php?id=8447 one can see that since the CentOS 7 release the number of unresolved issues on bugs.centos.org has increased, and the number is currently more than 50 unresolved issues per month. Many issues do not obtain any attention (nothing in the notes). This continues for several months, and is an unprecedented situation. For me it shows that the CentOS community has not enough resources to deal with the reported issues. From this point of view it would be better to have CentOS issues integrated into RHEL's bugzilla, but the decision should also take into account Red Hat's long time plans for CentOS, unknown to me. 2. A single example I would like to bring up is the fate of http://bugs.centos.org/view.php?id=8249 The reporter made a substantial effort to collect usability issues encountered during an installation of CentOS, got asked to report the issues at bugzilla what he did, and there this got (politely) closed https://bugzilla.redhat.com/show_bug.cgi?id=1197377 This seems to be his only bug at bugzilla.redhat.com. Maybe if CentOS was at bugzilla then CentOS developers could focus more on the "open-source" way of dealing with people's reports, which will counteract a bit Red Hat's enforcement of compliance with it's strategies. 3. One more point, and it has to do with the way Fedora/EPEL package updates are handled. When I update an RPM package fixing a bug for Fedora/EPEL the update almost never gets any reviews. The update is sitting for some fixed amount of time (2 weeks for EPEL) and after that I push it to stable (still without any review). I'll bring the famous case here what the result of such releases could potentially be: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't know if the offending release was reviewed or not). Or another case which affected me: https://bugzilla.redhat.com/show_bug.cgi?id=1063493 Red Hat changed major version of software (mpich2 -> mpich3) which resulted in a couple months of empty running reviews (2 weeks each) at EPEL in order to fix all dependencies. I'm not familiar with the role CentOS could have in the process of preparation of new RHEL updates, but if there is anything that could be done to improve the RPM package update process, it should be considered as an important factor in case of merging CentOS issues to bugzilla. Best regards, Marcin

8 10

triggering external actions from koji builds
by Karanbir Singh 15 Apr '15

15 Apr '15

hi, I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ? My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

3 5

Welcoming Brian to CentOS Engineering Team at Red Hat
by Karanbir Singh 14 Apr '15

14 Apr '15

hi Everyone, I would like to take this opportunity to welcome Brian Stinson to the CentOS Engineering Team at Red Hat, as a part of the Open Source and Standards group. In this team he will initially be focused on the central authentication services. As an extention he will also own the user interface and toolings around the UI to the CentOS Build Services and Source control. As a part of his additional portfolio, he's going to help Thomas Oulevey and Fabian Arrotin on various CBS, CI, QA and associated infrastructure management. Brian has been a key community contributor to the centpkg and the buildsystem efforts and more recently in the QA teams. He lives and works out of the Midwest USA ( Summer time offset: UTC -5:00 ). Brian is also helping the EPEL effort as a member of their Steering Committee and helping bridge the CentOS to EPEL stories. You can find him on #centos-devel on irc.freenode.net as bstinson and on twitter as @bstinsonmhk Welcome aboard Brian! -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

4 3

Switching to centralized authentication for CBS Infrastructure (aka FAS vs IPA)
by Brian Stinson 14 Apr '15

14 Apr '15

Hi All, I wanted to revive this old thread so we can get moving with our Central Auth solution. I've been playing for the past few days with both FAS and IPA and I'd like to present my findings so far. Here are our requirements: - Generate and deliver x509 client certificates (this acts as a 'passport') for all CBS services - Self-Service account requests - Self-Service group management (e.g. SIG admins can easily add members to the SIG) - Easily auth for CBS services (koji, git, lookaside, etc.) FreeIPA ============= FreeIPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged ID/Security management system that includes setting up a CA in it's deployment process. As to our requirements: - FreeIPA's CA can be modified to generate and sign client certificates, but: - We would need to write/maintain our own storage and delivery tools - We would maintain our cert generation tools until client certs are supported upstream. (There is not a clear upgrade path for this, and would require us to roll our CA and redo our delivery tools) - We would need to develop or maintain our own 3rd-party Self-Service account request system (pwm[1] is the frontrunner). - There are built-in tools that can manage groups (this would be separate from the account request system) - LDAP is near universal, and FreeIPA speaks it fluently (for those tools that need more information than what is in a client certificate) Since our requirements do not yet include the need for machine accounts, we may not be able to take advantage of all of the features of a Security Management System. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. FAS ============= FAS's advantages come from being developed with some of our current tools in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production, and we would be able to rely on (and contribute to) testing in deployments similar to ours. As to our requirements: - FAS manages the generation, signing, and delivery of the client certificate - Self-Service account requests are built in - Self-Service group membership (and invitations) are built in - Most tools already talk to FAS if they need it. Gitblit will need a little custom work (likely a plugin) to pull user and group membership information FAS is developed primarily for Fedora and would require some debranding and other tweaks to make it "ours". It would also require a bit more 'sysadmin' type work on the backend. Conclusions ============ This email is already getting long, so I won't get too farther in the weeds, though I'm happy to discuss them in this thread. In conclusion, I would like to propose that we select FAS as our Central Authentication solution. FAS seems to meet all of our SIG-facing requirements without requiring many 3rd party (or custom) tools, and the work required to get productive looks to be largely polish and packaging. Thoughts/Questions? Brian -- Brian Stinson brian(a)bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk [1]: https://code.google.com/p/pwm/

2 2

compiling on EL 7.x, using -fsanitize=xxx
by Fred Smith 13 Apr '15

13 Apr '15

Hi all! Using Centos-7, I'm trying to build a C-language app using -fsanitize=address, or -fsanitize=thread. If I compile (and link) with -fsanitize=address when it tries to link it complains of missing libasan.so.x.x.x. Similarly compiling with -fsanitize=thread, it complains of a missing libtsan.so.x.x.x. I can't figure out where one is supposed to find those libraries. they don't appear to be part of the GCC packages, and doing yum whatprovides */libasan.so or yum whatprovides */libtsan.so turns up nothing. Clues appreciated, thanks in advance! Fred -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) -----------------------------

2 2

CBS/Infra Meeting 13-Apr-2015 14:00 UTC
by Brian Stinson 13 Apr '15

13 Apr '15

Hi All! It's time for another meeting to discuss the Community Build System. We will be meeting in #centos-devel on Freenode. Here's our Agenda: #info Topic: Quick Updates #info Topic: Koji Project Tags and Git Branches #info Topic: Open Floor See you there! Brian -- Brian Stinson brian(a)bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk

1 0

Hosting CentOS bugs on RH bugzilla
by Lokesh Mandvekar 12 Apr '15

12 Apr '15

Given that we now have a lot of co-operation amongst CentOS-RHEL-Fedora, I was hoping we could host CentOS bugs on RH's bugzilla instance itself under a CentOS product, just like how we have Fedora and RHEL products. My guess is this should make life easier for people who file/deal with bugs related to all 3 distros. Considering docker as an example, when people complain about docker bugs they notice on CentOS7, I'm not sure whether to ask them to file bugs on bugs.c.o or bugzilla.rh.c, as that bug is actually something from RHEL. My guess is their first choice is to file bugs on bugs.c.o. There's also the virt SIG 'docker' and 'docker-master' variants and these are not pulled from RHEL. For bugs related to these, I'll need to ask users to file bugs on bugs.c.o and if this affects fedora/rhel as well, there would be separate bugs on RH's bugzilla about this. I feel it'd be much more convenient for me (and possibly others) to keep track of bugs and reference them if they're all hosted in a single place. Comments? * This issue has been apparently raised in the past as per conversations with Evolution on #centos-devel but it's kinda hard to find out recorded history about it. If anyone could send logs about why this was rejected or whatever, it'd be great. -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD

5 8

No Storage SIG meeting today
by Lalatendu Mohanty 10 Apr '15

10 Apr '15

Looks like we have not made much progress on the action items. Hence moving the meeting to next week. Thanks, Lala #lalatenduM on Freenode

1 0

including 3rd party repo release RPMs in Extras
by Carl George 10 Apr '15

10 Apr '15

Howdy, My name is Carl, and I'm a developer for the IUS Community repository. CentOS users have easy access to the EPEL repo because the epel-release RPM is in the CentOS Extras repository. Obviously CentOS and EPEL have a special relationship, since they are both sponsored by Red Hat. A coworker suggested to me that it would be nice if the ius-release RPM could be included in Extras as well. I brought the idea up in IRC, and Karanbir suggested I draft up a specification that any third party repository can follow to be considered for inclusion. Here is what I have so far. https://gist.github.com/cgtx/b854281462a18007f509 If this looks familiar, it's because I used the IUS SafeRepo Initiative as a starting point. Please share your feedback and ideas. Carl George Rackspace RPM Development

8 17

etcd fails to start in latest CentOS Atomic images
by Lalatendu Mohanty 10 Apr '15

10 Apr '15

I was trying to use/test the latest CentOS Atomic images [1] [2] and got in to this issue i.e. "systemctl start etcd " is failing. =============================== -bash-4.2# systemctl start etcd -bash-4.2# systemctl status etcd etcd.service - Etcd Server Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled) Active: failed (Result: exit-code) since Fri 2015-04-10 05:26:54 UTC; 6s ago Process: 1724 ExecStart=/usr/bin/etcd (code=exited, status=200/CHDIR) Main PID: 1724 (code=exited, status=200/CHDIR) Apr 10 05:26:54 myhost.localdomain systemd[1]: Started Etcd Server. Apr 10 05:26:54 myhost.localdomain systemd[1724]: Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory Apr 10 05:26:54 myhost.localdomain systemd[1]: etcd.service: main process exited, code=exited, status=200/CHDIR Apr 10 05:26:54 myhost.localdomain systemd[1]: Unit etcd.service entered failed state. ================================ I suspect there is something wrong with systemd unit file of etcd. The service file looks like below as of now. I think "WorkingDirectory=/var/lib/etcd/`$hostname`.etcd" should have only 'hostname' not '$hostname'. -bash-4.2# cat /usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server After=network.target [Service] Type=simple # etc logs to the journal directly, suppress double logging StandardOutput=null WorkingDirectory=/var/lib/etcd/`$hostname`.etcd User=etcd ExecStart=/usr/bin/etcd [Install] WantedBy=multi-user.target [1] CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 [2] http://wiki.centos.org/SpecialInterestGroup/Atomic/Download Thanks, Lala #lalatenduM on Freenode

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel April 2015