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, 7 months
Meeting Agenda Item: Introduction Atmn Patel
by Atmn Patel
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]
8 years, 11 months
fas02/03 issue
by Kevin Fenzi
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
8 years, 11 months
Plan for tomorrow's Fedora Infrastructure meeting (2014-12-18)
by Kevin Fenzi
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
8 years, 11 months
[release] anitya 0.1.15
by Pierre-Yves Chibon
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
8 years, 11 months
App dev and maintenance brainstorming for 2015
by Ralph Bean
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.
8 years, 11 months
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, 11 months
[release] pkgdb2 1.21
by Pierre-Yves Chibon
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
8 years, 12 months
Plan for tomorrow's Fedora Infrastructure meeting (2014-12-11)
by Kevin Fenzi
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
8 years, 12 months
