firewall rules on builders (iptables, firewalld, libvirt...)
by Matthew Miller
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
8 years, 1 month
Gitolite3 on pkgs01.stg
by Pierre-Yves Chibon
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
8 years, 5 months
MM2/Ansible FAD Hotel rooms
by Pierre-Yves Chibon
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 years, 6 months
[release] pkgdb2 1.20.1
by Pierre-Yves Chibon
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
8 years, 6 months
Fedora 21 Beta Freeze now in effect
by Kevin Fenzi
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
8 years, 7 months
Plan for tomorrow's Fedora Infrastructure meeting (2014-10-30)
by Kevin Fenzi
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
8 years, 7 months
Meeting Agenda Item: Introduction Sritanu Chakraborty
by Sritanu Chakraborty
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
8 years, 7 months
Meeting Agenda Item: Introduction - Zach Villers
by Zach Villers
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
8 years, 7 months
