infrastructure December 2014

infrastructure@lists.fedoraproject.org

27 participants
31 discussions

firewall rules on builders (iptables, firewalld, libvirt...)
by Matthew Miller 30 Apr '15

30 Apr '15

It's my understanding (Dennis please correct if I'm wrong) that the problem with cloud image creation was due to libvirt iptables rules being lost when iptables was restarted. This is a fundamental known issue (see last paragraph of <http://libvirt.org/firewall.html>), and one of the things firewalld was meant to solve. Dennis says that there are lot of complicated rules on the builders making switching to firewalld difficult. One possibility might be to move those complicated rules from the builders to a network firewall, and keep the host rules simple and functional. But that's probably a big undertaking. In the meantime, any time iptables is restarted or reloaded, libvirt needs a SIGHUP. (I suppose this means: ansible playbooks and also added to any manual procedures.) [cc rel-eng, reply-to infrastructure] -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

6 8

Updated usage needed for process-git-requests script
by Parag Nemade 13 Jan '15

13 Jan '15

Dear sysadmin-cvs group, I have seen after discussing with few members of sysadmin-cvs group that they found script process-git-requests[1] is not working for them and believe only limb knows how to run it. I see this is not good. We should have then new way of using process-git-requests documented somewhere. I am not sure if the new way of usage is updated here[2]. We already have less people working for this group and I guess except limb no one gets success with that script. Please update somewhere the usage so that when we need, other members can help needed people with their branch requests. Thanks & Regards, Parag [1] https://git.fedorahosted.org/cgit/fedora-infrastructure.git/plain/scripts/p… [2] https://infrastructure.fedoraproject.org/infra/docs/scmadmin.txt

6 16

Meeting Agenda Item: Introduction Atmn Patel
by Atmn Patel 28 Dec '14

28 Dec '14

Hello all, My name is Atmn Patel. I am a high school student in a small town near Windsor, ON, Canada. I am technically in grade 10, but I'm looking at a very early graduation. I was going to apply to the University of Toronto this year, but didn't because my parents wouldn't let me go. My dream school is MIT, double major in CS and Physics to pursue a doctorate in Quantum Computing. I started with Linux in grade 6, with Ubuntu (when they still used GNOME) but after they switched to Unity, I changed to Arch Linux. I stuck with Arch until about 10 months ago when I decided that I actually want to start contributing, I changed to Fedora. I spent the last 10 months getting used to it, understanding it, and toying with it, and now I think its time I start contributing. As for my computer skills, I know C and Python to the level of an introductory undergraduate course. I am currently learning Java in my spare time. I am also working towards getting the Linux Foundation Certified System Administrator. As for project experience, I have none. I believe that I am an excellent match for the project because I am willing to learn and dedicate time to the project (I have no experience whatsoever). Skills I would like to learn: - How to write more advanced shell scripting - How to fix system issues - Automation of system maintenance Time Zone: EST IRC Nickname: apatel GPG KEYID and fingerprint: pub 2048R/65B2C7F9 2014-12-28 [expires: 2015-12-28] Key fingerprint = 11E7 A451 66B8 E676 1B70 937E 31A0 9D5F 65B2 C7F9 uid Atmn Patel (Fedora Project) <atmnpatel.eiacps(a)gmail.com > sub 2048R/ACCE24D7 2014-12-28 [expires: 2015-12-28]

1 0

fas02/03 issue
by Kevin Fenzi 27 Dec '14

27 Dec '14

Seems there's an issue with fas2 and rhel7's version of gpgme: https://github.com/fedora-infra/fas/issues/98 because of this, new account requests that hit fas02/03 fail. I am going to just disable fas02/03 for now until we fix this up. This should allow new users to be created and I think fas01 can handle the load over the holidays. kevin

2 1

Plan for tomorrow's Fedora Infrastructure meeting (2014-12-18)
by Kevin Fenzi 18 Dec '14

18 Dec '14

The infrastructure team will be having it's weekly meeting tomorrow, 2014-12-18 at 18:00 UTC in #fedora-meeting on the freenode network. Suggested topics: #topic New folks introductions and Apprentice tasks. If any new folks want to give a quick one line bio or any apprentices would like to ask general questions, they can do so in this part of the meeting. Don't be shy! #topic Applications status / discussion Check in on status of our applications: pkgdb, fas, bodhi, koji, community, voting, tagger, packager, dpsearch, etc. If there's new releases, bugs we need to work around or things to note. #topic Sysadmin status / discussion Here we talk about sysadmin related happenings from the previous week, or things that are upcoming. #topic nagios/alerts recap Here we go over the last weeks alerts and see if we can find ways to make it so they don't happen again. #topic Upcoming Tasks/Items https://apps.fedoraproject.org/calendar/list/infrastructure/ #topic Open Floor Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 1

[release] anitya 0.1.15
by Pierre-Yves Chibon 18 Dec '14

18 Dec '14

Hi everyone, I just pushed out a new version of anitya which comes with a number of bug fixed. Here is the corresponding changelog: * Thu Dec 18 2014 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.1.15-1 - Fix changelog to include the release in addition to the version - Update to 0.1.15 - Fix links to the documentation to the proper github project - Mention the-new-hotness in the README file - Replace CNUCNU_* configuration keys by ANITYA_* keys - Adjust the unit-tests to test the logic in jenkins (while skipping the backend plugins) - Fix editing a project when version_url and regex are empty - Fix button text for project and distro edit (Praveen Kumar) - Display error message from the OpenID process (Patrick Uiterwijk) - Fix pagination when browsing the packages of a distro - Replace /api/projects/wiki by /api/packages/wiki and adjust the documentation - Adjust the case of the name of the backends - Allow an initial mapping when creating a project via GET arguments (Ralph Bean) - update distro page text (Elan Ruusamäe) - Replace "check now" button with spinner while ajax in transit (Ralph Bean) - Fix sorting version from newest to oldest (Ralph Bean) - Add the possibility for admins to delete a distro - Adjust the launchpad backend to rely on the project name rather than the project homepage - Strip all the inputs submitted by the user - Fix mail_logging for when we cannot retrieve the process information - Set a handler to the anitya logger to stderr Have a nice day, Pierre

1 0

App dev and maintenance brainstorming for 2015
by Ralph Bean 17 Dec '14

17 Dec '14

We started a document yesterday on gobby.fedoraproject.org to sketch out ideas for webapp/service development and maintenance for 2015. If you're interested, please check it out and add, edit, and annotate to your heart's content. It is currently kept in gobby. See this wiki page for information on how to access that: https://fedoraproject.org/wiki/Gobby This is mostly for brainstorming at this point. After the upcoming holidays, we'll move the contents to a wiki page for prioritization and future reference.

1 0

Gitolite3 on pkgs01.stg
by Pierre-Yves Chibon 17 Dec '14

17 Dec '14

Dear all, This morning Mathieu (bochecha) and I spent some time trying to get gitolite3 work on our pkgs01.stg. This is an overview of the situation. By design gitolite is meant to be installed with a dedicated user. Everyone uses that user. gitolite then maps the public ssh key to its user database and its configuration file to handle who is allowed to do what on which git repo. Our setup is quite different from this. We have a single configuration file at /etc/gitolite/conf/gitolite.conf that contains all the information about who is allowed to do what on which git repos. In addition we have a single /etc/gitolite/gitolite.rc configuration file that specifies to gitolite where are the git repositories located. Each user has then an account on the machine but by default no shell access. The access is restricted via ssh with in ~/.ssh/authorized_keys the instructions: `command="/usr/bin/gl-auth-command"` (people with shell access have a different command). That commands combines the info from /etc/gitolite/gitolite.rc and /etc/gitolite/conf/gitolite.conf and allow or deny the access/action. Now gitolite3 has changed quite a bit compared to our setup. Basically, gitolite3 expects the gitolite.rc file to be at ~/.gitolite.rc and the repositories to be at ~/repositories. Having symlink to these locations are fine, but they should be there. What we can do also is play on the $HOME variable. In pkgs01.stg we kept the configurations files (gitolite.conf and gitolite.rc) in /etc/gitolite as before, but we created a couple of symlink in /srv/git/ .gitolite -> /etc/gitolite/ repositories -> /srv/git/rpms/ The idea is to be able to set HOME=/srv/git and run the gitolite command. This way we managed to get the genacls.sh script working. It is the script that generates the gitolite.conf file based on the pkgdb information and compile that configuration file so that gitolite can use it. gitolite3 also changes the command in the ~/.ssh/authorized_keys file to: command="/usr/share/gitolite3/gitolite-shell user" That command is set in the sources in `src/triggers/post-compile/ssh-authkeys` and put in the file by (I believe) `gitolite compile` that is ran by genacls.sh. In order to test, I (manually) changed Mathieu's authorized_keys to look like: command="HOME=/srv/git/ /usr/share/gitolite3/gitolite-shell user" We then tried to get Mathieu to clone a repo and we found out: - the ~/.gitolite folder, that gitolite3 requires, needs to have a `logs/` subfolder, and that folder needs to be accessible read and write to everyone so `chmod 777 -R /srv/git/.gitolite/logs` (ie: chmod 777 /etc/gitolite/logs since it's a symlink) - the /etc/gitolite/conf/gitolite.conf-compiled.pm needs to be readable by everyone since it's the file gitolite uses to see who can do what on which repo so `chmod o+r conf/gitolite.conf-compiled.pm - Mathieu was finally able to clone and push in a repo he has access to and could not on the kernel repo (as supposed to since he does not have commit there), but the error returned is just plain ugly So to conclude: - we managed to get it to work - its needs chmod 777 on /srv/git/.gitolite/logs - its needs chmod o+r on conf/gitolite.conf-compiled.pm (and that after each time the file is generated) - we need to find a way to fix the command in the user's ~/.ssh/authorized_keys so that they specify the HOME variable to use when running the gitolite command -> Might very well require to patch gitolite itself for this (and thus keep the patch in our package ad vitam aeternam) That being said, I believe our options are: 1) Talk with upstream, in the past I believe he was quite reactive and willing to help us. We are the largest public deployment of gitolite maybe he'll still be willing to help us to discuss: - setting HOME in the authorized_keys - writing logs - accessing gitolite.conf-compiled.pm 2) Stick with gitolite2 -> We need to find out how easy it is to maintain it on epel7 and we need someone willing to maintain it (knowing that it's perl) -> Upstream said gitolite2 is still maintain wrt security fixes but I guess only for some time 3) Move to the model gitolite relies on (1 specific gitolite user everyone accesses the repo through). + No more need to create account on the machine for each and every packager + Inline with gitolite's design - Breaking all existing git clone around (as the push/pull urls change) --> URLs change could be handled at the fedpkg level + We are already forcing an update of fedpkg to our packager with the change from md5 to sha for the lookaside cache, so we could couple both change in the same update and preventing forcing two fedpkg updates. - Huge number of keys to handle for that user ? Performance impact of this number of users? ? Dennis mentionned logging at the meeting yesterday, but it looks like gitolite does provide logging itself 4) Move away from gitolite. I did not check what else would be available/suitable for us, so no ideas there. Suggestions welcome I guess :) I think that covers most if not all our findings. Questions and suggestions welcome :) Pierre and Mathieu

7 11

[release] pkgdb2 1.21
by Pierre-Yves Chibon 12 Dec '14

12 Dec '14

Hi all, I have just released and pushed to staging a new version of pkgdb2, here is the changelog: * Fri Nov 21 2014 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 1.21-1 - Update to 1.21 - DB optimization: do not use LIKE in queries where there is no '%' - Update the layout of the user list page - Add flag to set/update the monitoring flag on packages. This flag tells the-new-hotness whether the maintainers are interested in getting bugzilla tickets about updates available on their package (updates being monitored via anitya: release-monitoring.org) - Clean(er) logic to mark the fields mandatory in the forms - Fix indentation in the mail_logging module - Branch orphaned packages as well as we branch for new releases (Subho-bcrec) - Auto select packagers search in packager details page. (Ratnadeep Debnath) - Obsolete all ACLs on a package that is retired - Nicer docstring and API documentation by using textwrap.dedent() - Add a `former_poc` argument to the orphan API endpoint allowing to restrict the orphan to only the package of a certain packager - Add the former_poc keyword argument to api_acl_reassign, same principle as when orphaning a package - DB optimization: optimize the API endpoint returning the packager's ACLs - Include the monitoring state in the GET API. (Ralph Bean) - Include the api_groups and api_monitored in the API documentation - Update the update_package_info script to include other releases than rawhide The biggest change being likely the introduction of the monitoring flag to integrate pkgdb, anitya and the-new-hotness. Testing welcome :) Thanks, Pierre

2 5

Plan for tomorrow's Fedora Infrastructure meeting (2014-12-11)
by Kevin Fenzi 11 Dec '14

11 Dec '14

The infrastructure team will be having it's weekly meeting tomorrow, 2014-12-11 at 18:00 UTC in #fedora-meeting on the freenode network. Suggested topics: #topic New folks introductions and Apprentice tasks. If any new folks want to give a quick one line bio or any apprentices would like to ask general questions, they can do so in this part of the meeting. Don't be shy! #topic FAD recap We will recap our recent FAD. What we did and what needs to be done, etc. #topic Applications status / discussion Check in on status of our applications: pkgdb, fas, bodhi, koji, community, voting, tagger, packager, dpsearch, etc. If there's new releases, bugs we need to work around or things to note. #topic Sysadmin status / discussion Here we talk about sysadmin related happenings from the previous week, or things that are upcoming. #topic nagios/alerts recap Here we go over the last weeks alerts and see if we can find ways to make it so they don't happen again. #topic Upcoming Tasks/Items https://apps.fedoraproject.org/calendar/list/infrastructure/ #topic Open Floor Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure December 2014