infrastructure October 2014

infrastructure@lists.fedoraproject.org

40 participants
58 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

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

MM2/Ansible FAD Hotel rooms
by Pierre-Yves Chibon 22 Nov '14

22 Nov '14

Hi all, I would like to book the rooms for the hotel. Since we have 2 period (first days for MirrorManager, then the ansible migration part), I'd like to ask who will be there for which part? Patrick and I arrive on the 2rd and leave on the 9th, so we'll have an extra day to handle the jet-lag. The official dates are from Dec 4th to Dec 9th, as in, we start working on the 4th and finish on the 8th, thus departure on the 9th, so arrival dates should be Dec 3rd. So, Kevin, Ralph, Luke, David and Stephen, what would be your arrival date/departure dates? Thanks, Pierre

8 11

Ask Fedora and SPAM again
by Ankur Sinha 17 Nov '14

17 Nov '14

Hi, Seems our beloved spammer is back. We've had mods keeping an eye out and deleting posts, but of course, it isn't a proper solution. Q. I remember enabling stopforumspam - does it work? I've filed an RFE for Akismet alternatives: http://askbot.org/en/question/12507/alternatives-to-akismet/ Mollom looks nice, and it's open source too. There's already a django-mollom module available: https://pypi.python.org/pypi/django-mollom/0.1 Would a django guru like to see if it can be used with our deployment already without requiring code changes to ask? Thanks, Ankur

7 21

[release] pkgdb2 1.20.1
by Pierre-Yves Chibon 08 Nov '14

08 Nov '14

Hi all, I just pushed to staging the version 1.20.1 of pkgdb2, here is the changelog: * Sun Oct 05 2014 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 1.20.1-1 - Update to 1.20.1 - Better email handler for the logs - Re-write update_package_info cron script using yum's metadata instead of pkgwat Since most of the changes are backend stuff and don't touch the user space, I'll try to do some testing this afternoon and push to prod today or tomorrow. Have a nice day, Pierre

1 3

Fedora 21 Beta Freeze now in effect
by Kevin Fenzi 05 Nov '14

05 Nov '14

Greetings. we are now in the infrastructure freeze leading up to the Fedora 21 Beta release. This is a pre-release freeze. This means that hosts that are marked as freezing should not have any changes made to them except as part of a freeze break request (see below) We do this to make sure that our infrastructure is stable to allow for building/composing/testing and distributing Fedora 21 Beta. This freeze will end 1 day after Fedora 21 Beta is released. (Currently scheduled for 2014-10-28) Freeze breaks should be sent to this list, clearly describing the planned change and include patches (if applicable). Freeze breaks should not be applied until they have gotten at least 2 +1's from members of sysadmin-main and/or releng groups. You can see a list of hosts that do not freeze by checking out the ansible repo and running the freezelist script: git clone http://infrastructure.fedoraproject.org/infra/ansible.git scripts/freezelist -i inventory Thanks, kevin

1 1

Ask Fedora twitter keys
by Ankur Sinha 05 Nov '14

05 Nov '14

Hi, Could whoever hooked Ask Fedora to Twitter just check if the keys etc. are correct in the configuration? I can manually share posts to twitter, but the automatic "start tweeting" part doesn't work. https://ask.fedoraproject.org/en/question/39952/auto-tweet-not-working/ Thanks, Regards, Ankur Sinha "FranciscoD"

2 2

Plan for tomorrow's Fedora Infrastructure meeting (2014-10-30)
by Kevin Fenzi 30 Oct '14

30 Oct '14

The infrastructure team will be having it's weekly meeting tomorrow, 2014-10-30 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 Freeze reminder Just a reminder that we are in Beta freeze. #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

Meeting Agenda Item: Introduction Sritanu Chakraborty
by Sritanu Chakraborty 29 Oct '14

29 Oct '14

Hi, I am from Kolkata,India.I want to contribute to Fedora Infrastructure projects. IRC handle: sritanu Skills : Python and Basic system administration skills I am new to the FOSS world.Mr.Kushal Das suggested me to join this group and contribute to Fedora. Regards, Sritanu Chakraborty

1 0

Meeting Agenda Item: Introduction - Zach Villers
by Zach Villers 29 Oct '14

29 Oct '14

Infrastructure Team, My Hello World - 1...IRC aikidouke 2...I am studying for my RHCSA exam, so I have a decent grasp on basic requirements for that cert. 3...Interested in gaining experience in all aspects of administration and learning more about bash scripting and python. 4...I think I would fit best as an apprentice just learning my way around the environment. Thanks, Zach

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure October 2014