Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 1 month
upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
2 years, 3 months
Bodhi critpath package updates now gated on openQA results
by Adam Williamson
Hey folks!
Just wanted to flag up that, now the new Bodhi version has been
deployed to production, critpath updates are gated on openQA test
results. If any openQA test for your critpath update failed, the gating
status will be marked as 'failed' and you will not be able to push it
stable.
Waivers can be issued for failed tests where appropriate:
https://docs.fedoraproject.org/en-US/ci/gating/#_waive
But in almost all cases a failure indicates either a genuine bug or an
opportunity to improve the test, so I'd prefer to avoid use of waivers
where possible. I am trying to keep an eye on all failed tests, but if
you have a blocked update and you don't understand the failure and I
haven't yet commented on it, please do poke me and I'll take a look.
If a failure looks like some kind of transient issue, several folks
have the power to rerun tests: myself, lruzicka, kparal, tflink,
abokovoy (abbra / ab), pwhalen, and sumantrom. You can ask one of us to
do it. There have been plans in the past to implement some sort of
rerun request system in Bodhi but no-one's quite had the roundtuits to
work it out yet; sorry about that.
Thanks everyone, please be patient with any kinks while we see how this
goes :)
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 5 months
Fedora 32 System-Wide Change proposal: iptables-nft-default
by Ben Cotton
https://fedoraproject.org/wiki/Changes/iptables-nft-default
== Summary ==
Make iptables-nft the preferred iptables variant.
== Owner ==
* Name: [[User:psutter| Phil Sutter]]
* Email: psutter(a)redhat.com
== Detailed Description ==
<code>iptables-nft</code> package provides alternative implementations of
iptables, ip6tables, ebtables and arptables and associated save and restore
commands. These use nftables internally while providing the same look'n'feel as
the original tools. Users may choose between both implementations using
<code>alternatives</code> tool.
Upstream considers the traditional implementations legacy and therefore renamed
the binaries adding '-legacy' suffix. In Fedora, same has been done to
<code>arptables</code> and <code>ebtables</code> packages, namely renaming them
to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy
<code>iptables</code> and <code>ip6tables</code> remain in
<code>iptables</code> package, which in fact is the only one other packages
depend upon.
To change the status quo, two measures are planned:
=== Raise priority of nft-variants in <code>alternatives</code> ===
Currently, legacy variants are installed with priority 10 and nft
variants with priority 5. This must be changed as otherwise installing
<code>iptables-legacy</code> in a system with
<code>iptables-nft</code> installed would change the active
alternative (since they are in automatic mode by default).
On the other hand, existing systems using legacy variants should not
be changed by a system update. Therefore nft variants' priorities
should be chosen to match legacy ones.
=== Rename <code>iptables</code> package ===
New name should be <code>iptables-legacy</code> which aligns with
ebtables and arptables and reflects upstream status. To resolve
dependencies, <code>Provides: iptables</code> statement will be added
to <code>iptables-nft</code> package. This should automatically change
the default variant to nft.
== Benefit to Fedora ==
* RHEL8 ships nft-variants exclusively, make Fedora align with that by
default while still providing the option to fall back to legacy tools.
* New features and improvements are likely to hit nft-variants due to
the possibility nftables backend allows for. Although at this point
some legacy features (e.g. ebtables among match) are still missing,
others are already there (like, e.g. xtables-monitor tool) or are
being upstreamed right now (improved tool performance when dealing
with large rulesets).
== Scope ==
* Proposal owners:
Changes are rather simple: Rename <code>iptables</code> package, add
<code>Provides:</code> line to <code>iptables-nft</code> package,
change priorities used when calling <code>alternatives</code>.
* Other developers: N/A
The changed tools may cause regressions among packages using them and
it affects only new installations (or those manually switched over).
So while no explicit effort is required from them, they should be made
aware of the change so they take a possible regression in iptables
into account, quickly test against legacy variant and file a ticket
(or complain to the right person) if that fixes the problem.
* Release engineering: [https://pagure.io/releng/issue/8934 #8934]
* Policies and guidelines: No change required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Due to the package rename and <code>Provides:</code> line, upgrades will pull
in <code>iptables-nft</code> package. But due to the equal alternatives
priorities, existing choices won't be changed and so existing installations
shouldn't be harmed (apart from forced installation of
<code>iptables-nft</code> package).
Sadly, there are a few known issues, like e.g. missing support for ebtables
broute table or among match and a few iptables targets/matches. Users depending
on such features are advised to install <code>iptables-legacy</code> package
and switch variants using <code>alternatives</code>.
== How To Test ==
Any users of iptables/ebtables/arptables should switch to nft-variants using
alternatives tool (if necessary) and check that everything works as before. Any
issues should be reported despite the known compatibility issues described
above since knowledge about who uses the missing features is valuable
information for both up- and downstream.
== User Experience ==
Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock
file anymore, no problems with stale xtables-lock or parallel iptables calls in
different mount namespaces are expected anymore. Given the changes currently
being upstreamed, users dealing with large rulesets should see a performance
increase when manipulating the ruleset (lower run-times of iptables or
iptables-restore, packet processing speed should not really change).
== Dependencies ==
Other packages depending on iptables:
* NFStest
* clatd
* ctdb
* fail2ban-server
* firewalld
* fwsnort
* iptstate
* libvirt-daemon-driver-network
* libvirt-daemon-driver-nwfilter
* moby-engine
* nfacct
* origin
* podman
* psad
* python3-ipatests
* ravada
* rkt
* shorewall
* shorewall-init
* shorewall-lite
* shorewall6
* shorewall6-lite
* sshuttle
* sslsplit
* ufw
Since nft-variants are supposed to be drop-in replacements, no outside
contribution is needed in order to perform this change.
== Contingency Plan ==
* Contingency mechanism: Nothing needs to be done, the change should
be atomic.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools
* Man pages:
** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8]
** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8]
** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html
xtables-monitor.8]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd
Hi,
I added python-mailmerge to Fedora Linux as it was super important to
large parts of my work as FCAIC. In my current $dayjob I use it less
frequently, though I know of colleagues who still depend on it.
I'd love to find a maintainer to help me with it. There is a new
release pending, which I suspect will just be "build the rpm with new
code; test it; ship it" level effort. I am happy to hand the whole
thing off to someone or to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 6 months
co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd
Hi,
While I still actively use gocryptfs, I am busy enough with my $dayjob
that I know I am not able to put enough time into maintaining it.
Right now this has been OK as they have stopped new releases while
they get v2.0 out the door. However, that will ship soon.
I'd love to get some help maintaining the main rpm and the 6
dependencies I have for it. I am happy to hand it all over to you or
to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 6 months
Orphaning the cura-lulzbot package set
by Tom Callaway
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.
Accordingly, I've orphaned the following packages:
* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot
~spot
P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
2 years, 6 months
