Good Morning Everyone,
Our infrastructure is mostly a python store, meaning almost all our apps are
written in python and most using wsgi.
However in python we are using a number of framework:
* flask for most
* pyramid for some of the biggest (bodhi, FAS3)
* Django (askbot, Hyperkitty)
* TurboGears2 (fedora-packages)
* aiohttp (python3, async app: mdapi)
While this makes sometime things difficult, these are fairly standard framework
and most of our developers are able to help on all.
However, as I see us starting to look at JS for some of our apps (fedora-hubs,
wartaa...), I wonder if we could start the discussion early about the different
framework and eventually see if we can unify around one.
This would also allow those of us not familiar with any JS framework to look at
the recommended one instead of picking one up semi-randomly.
So has anyone experience with one or more JS framework? Do you have one that
would you recommend? Why?
Thanks for your inputs,
We have a request (
https://pagure.io/fedora-infrastructure/issue/5372 ) to setup ssl cert
pinning for ostree deliverables. It's also been a long wishlist item
to have that for rpm deliverables too. Unfortunately there's a bunch of
moving parts here that we need to sort out before we can move this
First some background/info:
* kojipkgs.fedoraproject.org currently uses a valid digisign cert. It
needs this because browsers download from it directly, our builders
download from it directly, etc.
* pkgs/koji currently use certs signed by the Fedora Koji CA (which
expires in 2024). This is currently needed by koji to do builds and
the upload cgi for lookaside.
* We are hoping to deploy soon a pair of freeipa servers in production
that get information from fas and allow us to issue kerberos tickets.
koji can already authenticate via this method.
* There's an outstanding ticket about having a verified way to get
Questions we need to figure out:
* Are we going to retire/replace the koji CA? My thought was yes, but I
think Dennis wasn't on board with this. Can anyone who wants to save
it speak up? :)
* The upload cgi would need to auth with kerberos and sigul would need
to auth with kerberos for this to work.
* If we are not completely retiring the koji CA, are we replacing it?
* Is ostree going to stay distributed at kojipkgs ? Or is it going to
move somewhere else? we should figure out the final place for it
before we go setting up cert pinning.
* The simple way to do pinning is for the application(s) to include a
hard coded list of valid certs. I guess this would require changes in
librepo and somewhere in ostree?
* The complex way to do pinning would be to setup
For this we would need to get backup keys for our cert(s) that are
used for this and setup webservers to send the right headers. This
would also need (more complex) changes in librepo and/or somewhere in
ostree. This would also optionally get us reports of violations.
Attendees: Xavier Lamien, Patrick Uiterwijk, Pierre-Yves Chibon, Paul
Agenda: Determine what remains to be done on FAS3 to get a new
instance for testing followed by production deployment
* * *
* Features needing forward-porting:
-> IPA Sync
* Token support required for Hubs support
* How to integrate with Ipsilon? - From FAS3 side, need a way to request token from Ipsilon and get it back into FAS3
* Cross-app authentication
-> hubs to FAS, fedocal, pkgdb, bodhi...
* Flock dead-line was F25-beta freeze (which we're past)
* At Flock, FAS2 issue --> dropped FAS3 data until we can get security audit of FAS3
* Also need update to db-migration script -- new license agreement function
* Convert this away from mechanism we used in FAS2
* This gives us a way to know which agreement(s) users agreed to, and/or prompt them accordingly
* AGREED: Convert current FPCA agreement into FAS3
* Build clean Ansible playbook for FAS3 with a true role, but perhaps do this as a github.com/fedora-infra/fas3-ansible (or other repo e.g. Pagure)
* Is there a method for getting client certificates in FAS3? Yes. Go to settings page for this. The certificate is no longer tied to the whole app, but rather per-group.
* So for Koji this would be tied to @packager group.
* Further, you can also optionally require SSH key for a group
PROPOSED: Merge FAS3.0 to development branch when we switch over, since we still have FAS2 elsewhere
supybot-fedora also has a fas3 branch which should be ready
Timezone handling... AGREED: keep things postgresql-only, storing TZ for the moment. We will add an issue to backlog to handle this down the road to make FAS3 more db-agnostic
* Security audit (already started, using latest git code) --> ETA unknown, will have it soon
* Meet to discuss FAS internals --> ETA: 2016-Oct-20, 0800 UTC (10:00 Paris/Amsterdam)
* Update db-migration script for CLA handling --> ETA: 2016-Oct-25
* Integration with Ipsilon --> ETA: 2016-Nov-01
* FAS3 in staging --> ETA: 2016-Nov-01
* Update python-fedora --> ETA: 2016-Nov-08?
* and deprecate functions where needed
* Port all the apps using it (but that's for later)
* Make this a major version update
* Target for production: 2016-Dec-01?
* If we don't make this, slip to early January
LATER (for separate followup, not FAS3 blocking)
* Updating all flask based apps
* kill off flask-fas-openid? <-- happy Patrick -- will break most of our flask app :(
* Patrick: would like to make it just use flask-openid transparently without anyone noticing :-)
* ouch, we will need to line up changes here then -> plan for later?1
* agreed, I moved this to its own task since it's not (IIUC) strictly required for FAS3 to be deployed
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
Rel-eng has been wanting a got hook that would notify the people involved with
secondary arches about changes made to packages involving ExclusiveArch or
I took a stab at this hook today and I would like to offer the result for
So with this email is an ansible patch adding the hook and installing it in our
Things that needs to be tweaked:
- Where to send the email?
- Turn off debug after we confirmed it works
- Currently I install the script as a file not a template, so the URL to point
to commits in CGIT will be the same in prod and in stg.
Comments and thoughts more than welcome :)
The last thing spacewalk needs to move off of fedorahosted is our Trac wiki. Can someone give me a pointer to how to get a copy/export of the current state of the wiki so we can start testing the move-to-github process? I'm assuming (but don't know for sure) that we're using the default SQLite db.
Principal Software Engineer, Red Hat Satellite
I'd like to propose employment of an upstream dist-git package for
deploying pkgs machines. This is the package I have in mind:
https://github.com/release-engineering/dist-git. This package contains
scripts and selinux policy for dist-git files.
Note however that I would like to make this package as compatible with the
infra dist-git as possible and that amounts to great deal of changes (main
one being usage of /srv/ to store repositories and tarballs). I have forked
the original repo into https://github.com/clime/dist-git and will continue
development from there.
The changes are going to be major so the main code-base could be e.g. here
https://pagure.io/group/Fedora-Infra in the end.
So far I have been testing only one use-case based on
I will collect all the other use-cases and ideally write a suite of
regression tests based on that. I know pkgs.fedoraproject.org is somehow
related to pagure but I need to additionally investigate this.
I would like to hear the tribe now.
I have written the SOP for the fedora-tagger, since I don't have yet
commit right to the infra-docs repository I can't update it myself.
Therefore I have been suggest to send this email containing the doc
itself. Special thanks to pingou for the guidance, it's my first
contribution to the fedora project.
I'm a programmer and have used Fedora for many years. I love fedora so much and very eager to contribute to it. This is my first time join a open source community. Nice to meet you guys. This is my basic information. Hope I can help you to do some thing. :)
Name Yisu Peng
Time Zone / Country East / US
Basic skills and experiences Strong in C/C++ skills, and good at shell. Know some kernel and also learned a little about gtk.
Why you're joining I want to help build good and powerful tools.
What you're looking to do (be specific) Basically some tools to improve the user experience and help fix bugs, but not limited to that.
How much time you can contribute (usually hours per week) 4 hours.