At some point, it would be good to see fedrtc.org migrate to Fedora
infrastructure and use the fedoraproject.org domain
I'd be happy to submit the full request for resources but I just want
to see if there is any initial comment on it. Here is a list of what is
- it uses a PostgreSQL database schema
- it requires some DNS entries (SRV and NAPTR), examples
- it needs a TLS cert for fedoraproject.org on the host(s) where it runs
- it has static HTTP content and PHP that is currently hosted with all
but one problem on a RHEL7 httpd. Content is in Github, it could
be presented as an RPM if necessary.
- all packages are in EPEL7, except:
cajun-json in EPEL6, in testing for EPEL7
resiprocate in Fedora, builds from SRPM on RHEL7
- the SIP proxy is a single daemon, managed by systemctl. All settings
in a single file, /etc/repro/repro.config
- the TURN server process is also a single daemon, managed by systemctl.
All settings in a single file, /etc/reTurn/reTurnServer.config
Just to clarify the scope of this: it is not a full telephony service
like Asterisk, just a SIP proxy and TURN server. There is no persistent
state information (as there would be for voicemail, email service, etc)
and no customized routing.
Ongoing maintenance requirements:
- TLS certificate renewals
- monitoring the ports
- package updates from time to time
It currently runs on a lab machine, I'd be happy to arrange SSH access
to the Fedora Infrastructure team to see exactly what is involved and
verify that it is manageable.
I just completed a bit of a Docker POC at Flock, and put together a
bit of a wiki page on it. Not a whole ton there right now, but as we
look towards more nimble deployment mechanisms, Docker might be
something worth looking at.
I hacked together a container with pastebin (sticky-notes) in it, and
a database external to the container. It didn't take more than a few
hours of work going from an Ansible playbook to a working container.
Let me know if anyone has questions or comments on the work so far.
Currently it's just on a transient cloud instance, and there are a lot
of things to think about (some of which I noted on the wiki page)
before we think about moving stuff somewhere more permanent.
There's a mention of something on the wiki page called Custodia. This
is a mechanism for securely provisioning, storing, distributing, and
auditing access to secret data. I wasn't able to find much on the
Internet, but Simo gave a talk on it at Flock if you went there :)
Anyhow, the wiki page is
I have just cut a new release of pagure: 0.1.23
It's a pretty big release with a large number of bug fixes and few features.
Here is the changelog:
* Sun Aug 30 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.1.23
- Update to 0.1.23
- Return a 404 error if we can't find the doc repo asked
- Fix for #106 Allow setting the default branch of the git repo and in the UI
- Improve unit-tests suite
- Add a global boolean to disable entirely tickets on all projects of a pagure
instance (with no way to re-set them per project)
- Do display uploading a tarball if it is not entirely configured
- Ensure we do not offer to reply by email if the milter is not set up
- Ensure there is no new line character on the msg-id and improve logging in the
- Add a configuration key to globally disable creating projects
- Add a configuration key to globally disable deleting projects
- Add the possibility to search projects/users
- Drop links to the individual commits in a remote pull-request
- Input that are cleaned via the noJS filter are safe to be displayed (avoid
double HTML escaping)
- When writing the authorized_key file, encode the data in UTF-8
- Makes page title easier to find in multi-tab cases (dhrish20)
- Fix authorized_keys file creation (Patrick Uiterwijk)
- Honor also symlinked README's in repo overview (Jan Pakorný)
- Fix the patch generation for remote PR
- Fix showing the comment's preview on the pull-request page
- Fix bug in checking if a PR can be merged
I am considering making the next release a 1.0 release, pagure has been running
quite smooth for some time now and it sounds like it's time to move along in the
This is currently in stg and will reach prod probably tomorrow.
infrastructure mailing list
Hello folksI want to join the development of Fedora Linux OS, I mainly do the work of the operating system transplantation, I am not sure to join which mailing list.I would like to ask what is the main work involved in the Fedor infrastructure group?
infrastructure mailing list
I had a short conversation with Xavier at Flock and it sounded like
things are coming along well with FAS3:
Xavier and I agreed we should have a longer discussion about this with
the team after the conference. So I figured this was worth bringing
up here so everyone can contribute. A couple things (and we can split
this thread up if needed):
1. FAS3 roadmap
How much more work is needed to make FAS3 test- and then
deployment-ready? And since obviously this will be an important
infrastructure change, is it a goal to try to deploy after F23 GA?
2. FreeIPA web UI demo
One of the developers on the freeIPA project, Christian Heimes,
reached out to me after Flock to ask whether he could present it to
the infrastructure team. He's been working on some additional web-UI
bits for administering freeIPA. He was hoping this team could offer
critique and suggest improvements to make the workflows more suitable
for a self-signup, free software project like ours. It would probably
be a video demo, venue TBD.
I don't see this being at odds with FAS3 deployment, although if
anyone sees things differently, please speak up. Hopefully the
questions above support that goal too.
If a few years down the line, a different solution (not necessarily
freeIPA) makes sense for us, then great, we can consider it. IMHO if
input from the infrastructure team makes freeIPA more suitable for
free software projects, it helps everyone. It's also helpful for the
freeIPA roadmap if their devs know when FAS3 will be up, and what
feature parity is needed for projects like ours to find their work
useful in the future.
Are there people on the team willing to attend this demo?
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
I'm about to start Jenkins migration to the new cloud.
I'll reply with more details after the process is complete.
The migration shouldn't take longer than a few hours. During that period
Jenkins may be unavailable. Sorry for any inconvenience.
Software Engineer, Red Hat
infrastructure mailing list
I want to help the Fedora Infraistructure group, and would like to introduce myself.
- IRC handle: vk (or vkaigoro)
I have 9 years of devops/sysadmin experience (started as a junior
sysadmin in a web hosting company around May 2005).
- config mgmt systems: Ansible, Puppet, CFengine 2
- scripting langs: Perl, Python, Ruby, Bash
- all kinds of web, database, load balancing and caching services
(not worth it to list all those)
- here is my GitHub account: https://github.com/br0ziliy
- I would like to work on tools the group is using, and also probably
contribute to the playbooks (for last year I'm mainly using Ansible
anyway). Actually I do enjoy all things related to the
infrastructure management and support, so probably can help in
Tried to keep it short, see you all during the meeting today.
Vasyl Kaigorodov | Red Hat Product Security
PGP: 0xABB6E828 A7E0 87FF 5AB5 48EB 47D0 2868 217B F9FC ABB6 E828
infrastructure mailing list
The infrastructure team will be having it's weekly meeting tomorrow,
2015-08-27 at 18:00 UTC in #fedora-meeting on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
This shared document is for the next fedora infrastructure meeting.
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2015-08-27)
#chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk pbrobinson
#topic New folks introductions / Apprentice feedback
= Status / information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info Bunch more work on bodhi2 rollout - lmacken/threebean
#info Mass update/reboot cycle next week: monday/cloud, tuesday/build, wed/the rest - kevin/patrick/smooge
#info Week after next is freeze (2015-09-08) - everyone
#info May swap lockbox01 out for new batcave01 on friday if it's ready - kevin
#info Apprentice wiki pages updated. Look today! - kevin
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus or decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#topic fas3 plans - kevin/smootherfrogz
#topic TRAC tickets review - p_klos
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for improvement,
etc. Whoever would like to do this, just add the info in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
infrastructure mailing list
I'm sorry to announce that I had to rollback the migration of
lists.fedorahosted.org to Mailman 3.
There's a missing feature again, that is heavily used by two lists on
this server, it's the header_filter_rules. It lets the admin decide on
header regexes that will set a different action on the email
(rejecting, holding, etc). It's designed for spam filtering: detect
X-Spam-Flag and drop the email. Those lists use it to filter commit
emails on the master branch only and drop the rest. The migration to
Mailman3 caused an email avalanche on their list when someone pushed a
branch, so... not very nice :-/
In Mailman3 this is implemented differently, you can only have a
global action set for emails whoose headers match the filters. Not per
regex as in Mailman 2, not even per list, only per server.
So I'll discuss this on the mailman dev list and write this feature,
in the meantime I had to rollback the migration.
I wish it had worked better, sorry for the inconvenience.