About JS framework
by Pierre-Yves Chibon
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,
Pierre
1 year, 6 months
anheath - reaching out
by Andrew Heath
Hey all, my name is Andy Heath and I'm a Senior Information systems
engineer at Red Hat. I have been using Fedora for the better part of 7+
years and would like to give back. Some of the skills I have developed over
the years I think can help with the Fedora infrastructure, those skills
include.
- System administration
- Ansible Automation
- Security
- monitoring & logging
- Identity management
- RPM
- SELinux
Hope to hear from you soon.
2 years, 2 months
Building VM images for Copr builders
by Pavel Raiskup
Hello infra!
Currently, in Copr team we are periodically preparing those kinds of images for
our VM builders:
- x86_64 AMI image for AWS
- aarch64 AMI
- x86_64 image for hypervisors
- ppc64le qcow2 image (uploaded to Power9 OpenStack and to our Power8 hypervisors)
- s390x qcow2 (built in IBM Cloud)
- internally we build also x86_64 images for OpenStack
The way we do this now is pretty complicated:
- we start with the officially provided Fedora images (AMI/QCOW2)
- we modify and update them using ansible scripts and/or libguestfs
- then the images are uploaded, and tested in our development stack
- and if everything is OK, then these images are used in production
Some more info https://docs.pagure.org/copr.copr/how_to_upgrade_builders.html
This is a tedious and repetitive list of tasks, and I'm sure we
should/could automatize some parts. At least it would be awesome if we
could try to trigger the build(s) for all the images by "a single button",
somehow, somewhere... So I am here to ask you how you would do this.
- I thought the answer is Image Builder, but there's a missing support for
Fedora ppc64le and s390x targets for now (rhbz#2040685).
- livemedia-creator, seems to be a bit related to Image Builder but I was told
some time ago that AMI support is experimental, the docs say
"At this time I have not tested the image with EC2. Feedback would be
welcome."
- There's a Packer software (packer.io) used by testing farm folks (the tooling
is not available in Fedora yet).
- Koji is able to build some images using Kickstarts. This one looks like
low-hanging fruit. Existing and working solution, we could built on top of
of the maintained fedora-kickstarts files that we "use" anyway (through the
pre-built official images). But I'm not sure if our team could be allowed to
use Koji like this, and provide additional *ks files?
Are there any other possibilities? Opinions?
Thanks, Pavel
2 years, 2 months
dsastrem - self introduction
by David Sastre
Hello,
Introducing myself to the infra community.
My name is David Sastre, and I'm currently employed by Red Hat (4 and a
half years), currently working as a Senior Product Security Engineer.
I come from a system administration background and I'm familiar with
GNU/Linux, and RHEL and Fedora in particular. I'm not new to Fedora (I've
been using it as my primary desktop since around F17, Debian before that).
I've also spend 3 years as a Cloud Architect (also at Red Hat)
I'm currently going through the code in the ansible repo to familiarise
myself with what's in there, and reading the suggested wiki pages as well.
I'll be in listening mode for some time, to learn how this group manages
things, and I'll be attending meetings in the EMEA time zone if work
permits. I can also be found @libera (dawud).
Things I can help with:
- Ansible
- RHEL/Fedora hardening
- IdM/FreeIPA
- Documentation, Fedora wiki
- Threat modeling, if there's appetite for that kind of thing
- Openshift
- sysadmin related tasks
Cheers!
2 years, 2 months
Note about commenting out j2 configs
by Stephen Smoogen
I have done this myself a couple of times myself so wanted to be clear that
when you comment out regions in j2 it doesn't act like you would expect.
Basically, j2 decisions end of lines are 'eaten' and the next line is
appended to your previous one. This works great in many places but can kill
you in others.
A change like this:
```
# Comment out emails until we fix deeper issue
#{% if env == 'production' %}
#'mail_admins',
#{% endif %}
],
```
will end up with this:
```
# Comment out emails until we fix deeper issue
# #'mail_admins',
# ],
```
versus what is expected. If you are commenting out some j2 decision code,
always add either a blank line after words OR an addition comment line at
the end
```
# Comment out emails until we fix deeper issues
#{% if env == 'production' %}
#'mail_admins',
#{% endif %}
#
```
will go to
```
# Comment out emails until we fix deeper issues
# #'mail_admins',
# #
```
The most likely place you will run into this is the giant mess of nagios
configs I left for infrastructure. There are many times where you may need
to comment out a decision to see if it's the place nagios is currently
puking itself.. and you end up with now two places nagios is puking itself.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
2 years, 2 months
Fedora 36 Beta Freeze now in effect
by Kevin Fenzi
Greetings.
We are now in the infrastructure freeze leading up to the Fedora 36
Beta release. This is a pre release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 36 Beta when it's available.
You can see a list of hosts that do not freeze by checking out the
ansible repo and running the freezelist script:
git clone
https://infrastructure.fedoraproject.org/infra/ansible.git
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2022-03-15 (or later if
release slips). Frozen hosts should have no changes made to them without
a sign-off on the change from at least 2 sysadmin-main or rel-eng
members, along with (in most cases) a patch of the exact change to be
made to this list or a pull request for review.
Thanks,
Kevin
2 years, 2 months
Bodhi's move to OIDC
by Aurelien Bompard
Hey folks!
A long email to give you some context, please bear with me :-)
A while back, Bodhi's integration tests stopped working on the "pip"
release (basically the latest python packages from PyPI). Since the
integration tests were flaky at that time, they were disabled on the
"pip" release. Now that the flakiness has been fixed (for now ;-) )
I've revisited why they still fail. It led me to open a bodhi ticket
<https://github.com/fedora-infra/bodhi/issues/4356> that explains the
situation: basically Pyramid is switching the session serializer from
pickle to JSON, because pickle is pretty insecure. However, one of our
dependencies, python-openid, stores an object instance in the session,
and that can't be serialized to JSON. A ticket has been opened on
python-openid about that in *2011*, and the last comment in 2014
states that the library is pretty much unmaintained.
I think it's the final nail in Bodhi's OpenID auth coffin, we've
wanted to switch to OIDC (OpenID Connect) for a long while but haven't
got around to it yet. Now I don't think we can delay it much longer,
as the newer versions will find their way in Fedora releases and
things will stop working without horrible ad-hoc patches.
I've started to convert Bodhi to OIDC, using the authlib library. The
server part isn't so hard (there isn't a ready-made integration layer
for Pyramid as there is for Flask and Django, but it's fine, it's not
a big layer). The client however is going to be pretty different after
the conversion. To log in, users won't be able to pass the login and
password as they do now. When an authenticated operation is requested,
the command-line client will open a browser window to ask the user to
login on id.fp.o, as for web apps. After a successful login the page
will say "You can now close this page and go back to bodhi". I know it
looks weird to have a command-line tool open a graphical tool, but
it's actually the recommended way to do things securely.
Weirdness aside, I'm wondering if this could hurt people who may run
the bodhi client CLI on a headless server. The browser must be opened
on the same host where the CLI is running. There could be a way around
that but it would need a (minor, according to Patrick) addition to
Ipsilon. (this workaround does not involve starting elinks instead)
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
their workstation?
- Do you use the --username and --password command-line switches of
bodhi-client?
- How far ahead should we warn users of this change? There's doc to update too.
I don't think I can easily keep both stacks (OpenID and OIDC) working
simultaneously, but in the interest of ease of migration I can try, if
it's worth the non-negligible effort.
I think I can get this work done in the context of the Bodhi
initiative this quarter. If things don't explode too big.
Comments? Opinions?
Thanks for reading this far :-)
Aurélien
2 years, 2 months
