Fwd: [Insecure mail sending from Fedora mailing lists] Fwd:
[Posteo-Status] Unsicherer E-Mail-Empfang abgelehnt
by rugk
See the mail below, whcih was rejected as I am not in that mailing
list, I guess this one here fits better anyway:
---------- Weitergeleitete Nachricht ----------
Von: rugk <rugk(a)posteo.de>
Betreff: [Insecure mail sending from Fedora mailing lists] Fwd:
[Posteo-Status] Unsicherer E-Mail-Empfang abgelehnt
Datum: 2022-05-30T20:25:37+0200
An: mailman(a)lists.fedorahosted.org
Hi,
my email provider is set to reject unencrypted emails and so the email
was not delivered to me and was rejected instead.
Therefore, please check the security settings of your email servers,
apparently they do not support up- to-date TLS encryption.
I have activated a guarantee for secure mail reception (TLS) with my
provider Posteo to protect myself against data theft and insecure data
transmission.
Sending emails that are not encrypted in transit is no longer
considered adequate. If they contain personal data such as names and
addresses, it is also illegal. In this way, data can simply be tapped
on the way through the internet.
More information here:
https://posteo.de/en/help/activate-tls-receiving-guarantee
I have a corresponding security response from the Posteo servers is
attached below (in German).
Please correct this deficiency and give me feedback when you’ve done
so.
Best regards
rugk
---------- Weitergeleitete Nachricht ----------
Von: Posteo Support <support(a)posteo.de>
Betreff: [Posteo-Status] Unsicherer E-Mail-Empfang abgelehnt
Datum: 2022-05-19T23:37:56+0200
An: rugk(a)posteo.de
Liebe Posteo-Nutzerin, lieber Posteo-Nutzer,
wir haben soeben einen unsicheren E-Mail-Empfang vom Absender
coreos-status-bounces(a)lists.fedoraproject.org
(bastion-iad01.fedoraproject.org, 38.145.60.11) abgelehnt. Wir haben
die E-Mail wie gewünscht nicht angenommen, weil Sie die
TLS-Empfangs-Garantie aktiviert haben.
Mit freundlichen Grüßen,
das Posteo-Team
1 year, 10 months
CPE Weekly Update – Week 23 2022
by Michal Konecny
Hi everyone,
This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).
Week: 6th - 10th 2022
If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update--week-23-2022/
# Highlights of the week
## Infrastructure & Release Engineering
Goal of this Initiative
-----------------------
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release (mirrors,
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible
initiatives that CPE might take on.
Link to planning board: https://zlopez.fedorapeople.org/I&R-2022-06-08.pdf
Link to docs: https://docs.fedoraproject.org/en-US/infra/
Update
------
### Fedora Infra
* Staging instance of release-monitoring.org migrated to OCP4 (fixed
authentication issue)
* the-new-hotness 1.2.1 released and deployed on production
* Got a bunch of f34 machines reinstalled with f36.
* In the middle of upgrading the wiki (some plugins and theme currently
broken in staging)
* Image builder prod deployment in process, hit some snags with networks
* Map of critical services is now available in [Fedora Infra
docs](https://docs.fedoraproject.org/en-US/infra/map_critical_services/)
### CentOS Infra including CentOS CI
* Git.centos.org [scheduled
migration](https://lists.centos.org/pipermail/centos-devel/2022-June/1203...
(new RHEL8 hosts being prepared)
### Release Engineering
* Fedora 34 is EOL
* Perl side-tag merged into Fedora 37
## CentOS Stream
Goal of this Initiative
-----------------------
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
Updates
-------
* Completed scripting for initial import of module RPMs and module-*
tags. Initial importing in progress to c9s koji from c8s koji..
* Working on automated scripting to pull new builds so that the c9s koji
can be automatically updated until we shift to the new koji builder for
c8s as well as c9s.
## CentOS Duffy CI
Goal of this Initiative
-----------------------
Duffy is a system within CentOS CI infrastructure allowing tenants to
provision and access machines (physical and/or virtual, of different
architectures and configurations) for the purposes of CI testing.
Development of Duffy is largely finished, we're currently planning and
testing deployment scenarios.
Updates
-------
* Release 3.0.1, 3.1.0, 3.2.0 (maybe shouldn’t have skipped betas 🤔).
* Add client (end user) CLI commands for requesting/retiring/etc. sessions.
* Add API endpoints and corresponding CLI commands for retrieving
information about configured node pools.
* Fix dependencies to have finer-granular installation options using
Python package extras (client CLI, task worker, current and legacy web
API servers).
## Package Automation (Packit Service)
Goal of this initiative
-----------------------
Automate RPM packaging of infra apps/packages
Updates
-------
* Working on adding packit to datagrepper and noggin
* Fasjson-client in bugzilla review
## Flask-oidc: oauth2client replacement
Goal of this initiative
-----------------------
Flask-oidc is a library used across the Fedora infrastructure and is the
client for ipsilon for its authentication. flask-oidc uses oauth2client.
This library is now deprecated and no longer maintained. This will need
to be replaced with authlib.
Updates:
--------
* We now have a very early barebones
[POC](https://app-flask-oidc-dev.apps.ocp.stg.fedoraproject.org/oidc/)
in place which makes use of authlib to authenticate over oidc with
Noggin/IPA.
* Working towards implementing the existing flask-oidc API to retrieve
user data.
## EPEL
Goal of this initiative
-----------------------
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL),
Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will
never conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror
manager and more.
Updates
-------
* This week we have 6018 (+155) packages, from 2730 (+58) source packages
* Unused marketing information and links were removed from EPEL docs
* Fedora's backported java_arches macro got merged into epel9
Kindest regards,
CPE Team
1 year, 10 months
ocp4 and ipv6
by Kevin Fenzi
So, we are moving more and more things over to our ocp4 cluster
(which is great!). However, I noticed this weekend, it's going to mean
some of our applications that are reachable via ipv6 will no longer be.
;(
The ocp3 cluster is on our vpn and can be reached by all our proxy
network. Many of our proxies have ipv6 connectivity.
The ocp4 cluster is not on our vpn and can only be reached by the 2 iad2
proxies. iad2 has currently no ipv6 support.
I'm asking networking folks about ipv6 support in iad2, but last I heard
it was waiting for some hardware upgrades, so I don't know that we can
count on it anytime soon.
So, we can:
1. Just not care, and move everything to ocp4 and people will need to
use ipv4 to reach those services.
2. Try and get the ocp4 compute nodes on our vpn. I looked around and
could not find any handy openvpn reference for openshift4. I'm guessing
this needs a machine-config of some kind to establish the vpn and
possibly some kind of ingress policy to allow incoming connections
there.
3. Another layer of proxy. ie, proxies -> vpn -> secondproxyiniad2 ->
ocp4.
4. Some other clever plan?
IMHO, I'd like to do 2... but I have no idea if it's possible/easy.
Can some of you more savvy openshift folks weigh in? I think if we do 1
there will be complaints, 3 could get super complex fast and also is
going to be slow with another hop in the middle there. 4 might be good
if anyone can think of some plan I missed. ;)
Thoughts?
kevin
1 year, 10 months
old vm's
by Kevin Fenzi
Looking at our current hosts (ansible_distribution_major_version):
275 35
120 8
90 7
22 34
11 36
6 33
2 9
2 31
1 37
1 32
1 27
(The reason so many are f35 is because builders are f35)
Anyhow:
- 27 -> This is notifs-backend01. We are still trying to get the python3
FMN deployed and working in stg so we can repave this and move it to a
supported version.
- 31 -> These are resultsdb01 and resultsdb01.stg. We already have the
openshift replacement in staging working, we just need to cut over
prod. We should schedule a time/date to do that.
- 32 -> This is odcs-backend-releng01. I am just going to reinstall it
and hopefully odcs is happy on f36. :) I'll mail odcs folks to
confirm.
- 33 -> These are osbs-aarch64 prod and stg. I'm open to suggestion on
what to do here. I'd personally say we should leave them and hasten
our move to image builder and hopefully by then they have container
building and aarch64? Other ideas welcome.
- 34 -> These are still supported at least, but we need to move them
soon. I can do most of these, will be contacting people about them.
Finally after that we should try and start moving the 8's and 7's to
9's. ;)
kevin
1 year, 10 months
Planned Outage - Bodhi upgrade - 2022-06-08 09:00 UTC
by Mark O'Brien
Hi all,
Apologies for the very delayed notice on this. I should have sent this mail
a lot earlier.
TL;DR there will be an outage of Bodhi tomorrow morning EU time for some
upgrades
Planned Outage - Bodhi upgrade - 2022-06-08 09:00 UTC
There will be an outage starting at 2022-06-08 09:00 UTC,
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2022-06-08 09:00 UTC'
Reason for outage:
Swtich to OpenID connect for authentication and more...
Affected Services:
Bodhi and any service which relies on it
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/10754
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Thanks,
Mark
1 year, 10 months
Upcoming MirrorManager changes (removal of Internet2 support)
by Adrian Reber
I will remove Internet2 support from MirrorManager in the next few
weeks.
The main reason is, that the source for the Internet2 routing tables
does not exist any more: http://routes.net.internet2.edu/
It changed a couple of years ago and it seems Fedora was one of the only
users of that data. They fixed it for us, but the latest ticket I opened
to access this information was closed with "This service was decomd".
I do not think that the removal of Internet2 support for our users will
be noticed at all. Removing Internet2 will remove some complexity from
the code and using ASN and GeoIP should still provide a reasonably close
mirror for most of out users.
I will start to update the different components to not expose and rely
on Internet2 information any more in the next couple of weeks.
Let me know if you see any major problems in removing Internet2 support
from MirrorManager.
Adrian
1 year, 10 months
