Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for June 10th, 2014:
New FPL Board Meeting
We held the first public Fedora Project Board meeting of my new tenure as Fedora Project Leader yesterday, as an informal town-hall discussion. You can read the summary or full log. We’ll be holding these every two weeks. Usually, we’ll have an agenda based on decisions to be made or (as suggested in this discussion, actually) with representatives from different parts of the project talking about their area of Fedora. But when we don’t have a pre-planned schedule, we’ll do open floor like this for whatever people want to talk about. (In this week’s case, it’s largely this: Fedora QA could use your help!)
Rawhide Mass Rebuild
Periodically, we do a “mass rebuild” of all of the packages in Rawhide, our development branch. This makes sure that all of the software uses the latest compilers and build macros. This is mostly an automated process, but sometimes some software does not rebuild successfully. If that software doesn’t get updated by its maintainers, and no one picks it up, it will eventually be dropped from the distribution. Fedora Release Engineer Dennis Gilmore posted a Fedora 21 Mass rebuild update, including a link to the packages which need work. If any of these are yours, please fix. Or if there’s something that you’re interested in that isn’t rebuilding, considerer helping by becoming a co-maintainer. (If you’re curious, the standard operating procedure followed for these rebuilds is available on the Fedora wiki at Mass Rebuild SOP.)
Fedora Workstation and Firewalld
In April, there was a large discussion over a proposal to drop the firewall by default from Fedora Workstaion. The basic argument was that the the current state of application integration with the firewall service FirewallD isn’t adequate to provide a good user experience, and that the security benefits aren’t really meaningful in actual practice. Others disagreed, and ultimately, Workstation designers and FirewallD developers met to figure out a solution. Developer Bastien Nocera summarizes the resulting plan, which includes additional automated testing, a new firewall zone, and adding network awareness to GNOME’s “sharing” controls.
Update on 64-bit ARM and Fedora 21
Fedora contributor and ARM hacker Peter Robinson provides an aarch64 (arm64) on Fedora 21 update. Current ARM support in Fedora is 32-bit, and focused mostly on low-cost consumer devices. The new 64-bit “aarch64” architecture promises an exciting future of low-cost, energy-efficient, high-density servers — the “hyperscale” datacenter. Peter says that progress is going nicely, with some porting work remaining particularly around support of newer langages like Go and server-side Javascript, but an overall status of “looking awesome”.
DNF Proposed for Fedora 22 (and user survey)
DNF is an experimental package manager, similar to the current Yum. It’s largely a drop-in replacement, promising faster dependency-solving and (more critically) a new explicitly-defined API designed to make it easier to develop higher-level software like GUI tools an plugins. There was a great article in January on Linux Weekly News about a previous long discussion on DNF, and that’s recommended reading if you missed it before. But also, the DNF developers are asking for user feedback on Yum features missing in DNF, so please do register your feedback about what is important to you. And there is a feature proposal, not for the upcoming Fedora 21, but for next year’s Fedora 22, to replace the current Yum with DNF (possibly as “yum 4”).
Bonus Item! RHEL 7 and Fedora
You may have noticed that a new version of Red Hat Enterprise Linux was released — RHEL 7. Former Fedora Project Leader Robyn Bergeron has a great blog post about the process by which Fedora serves as the upstream for RHEL, and the history of some features of RHEL 7 in particular: Fedora, Red Hat, RHEL 7, & Open Source. (Or: How RHEL 7 is literally “Beefy.”)
Gary Scarborough
Instead of using Firewalld when its not ready, why not go back to IPTables which is still included in the distro? Also, what about the new firewall the kernel team wrote to replace IPTables? Are there any plans to move to it?
Matthew Miller
Well, from the point of view of the problem presented (user interface and application integration), the iptables shell scripts are even worse.
As for using the new kernel firewall (nftables), from this point of view, that’s really an implementation detail. FirewallD doesn’t really replace iptables in the kernel — it just provides a more sophisticated API and management layer to that kernel-level functionality. I’m sure that once it’s ready, FirewallD will move to the more modern backend as well.
Stephen Gallagher
FirewallD is an API layer. As Matthew says, it uses the iptables kernel interfaces under the hood (and any of the changes it makes can be viewed with the classic ‘iptables’ command). It provides two things that old iptables scripts really didn’t: 1) an interface to apply programmatic changes (for example, only opening a port in the firewall for 10s while you accept an expected incoming request). 2) A command-line tool that human beings can understand without first taking a training course (‘firewall-cmd –persistent –add-port 80’ and you’re done!)
And yes, I believe the plan is for FirewallD to switch to supporting nftables under the hood eventually. However, the API will likely stay the same (or backwards-compatible), meaning that existing applications won’t have to make big changes to take advantage of the new functionality.
Gary Scarborough
Ahh, thanks for the info on Firewalld. I didn’t realize it still used IPTables.
On a separate thought line, will a 32 bit build continue for Fedora? I see that RHEL has dropped 32 bit installs.