Language Selection

English French German Italian Portuguese Spanish

Fedora Magazine

Syndicate content
Guides, information, and news about the Fedora operating system for users, developers, system administrators, and community members.
Updated: 5 hours 26 min ago

Contribute to Fedora Magazine

18 hours 23 min ago

Do you love Linux and open source? Do you have ideas to share, enjoy writing, or want to help run a blog with over 60k visits every week? Then you’re at the right place! Fedora Magazine is looking for contributors. This article walks you through various options of contributing and guides you through the process of becoming a contributor.

There are three main areas of contribution:

  1. Proposing ideas
  2. Writing articles
  3. Keeping it all running
Proposing ideas

Everything starts with an idea. We discuss ideas and how to turn them into articles that are interesting and useful to the Magazine’s audience.

Everyone is welcome to submit an idea. It can be a very specific article proposal, or really just an idea. The Editorial Board discusses each proposal and decides about the next step.

Many ideas are turned into a so-called Article Spec, which is a specific description of an article to get written for the Magazine. It usually describes the desired structure and other aspects of the article.

By submitting a proposal you’re not automatically committing to write it. It’s a separate step by design. But, of course, you’re very welcome to do both!

Submit an idea by opening an issue in our issue tracker. To do that, you’ll need a FAS (Fedora Account System) account.

See the docs on proposing articles for more info.

Writing articles

If you enjoy writing, you’re welcome to write for the Magazine! Being a good writer doesn’t necessarily mean that you also need to come up with the topic — we have a list of article specs ready to be written.

The Editorial Board maintains a Kanban board with cards representing specific articles. Each article starts as an Article Spec, and goes through various states to the very end when it’s published. Each column on the board represents a state.

If you want to write an article, just pick any card in the Article Spec column you like. First, assign yourself to the card of your choice, and move it to the In Progress column. That’s how you indicate to the rest of the community you’re working on it. Writing itself is done in the Magazine WordPress — log in, click new/post at the very top, and start writing.

We strongly encourage writers to read the Tips for Writers page in the docs.

Once you’re done writing, paste the preview URL from WordPress into the card. (You can get it using the Preview button at the top-right in the WordPress editor.) Then move the card to the Review column. An editor then reviews and moves it forward.

In some cases, an editor might ask for certain changes. When that happens, the card is moved back to In Progress. All you need to do is to make those changes and move it to the Review column again.

If you’re a first-time contributor, you’ll need to get access to WordPress and Taiga first. Start by introducing yourself on the Fedora Magazine mailing list, and an editor will set everything up for you.

See what article specs are ready to be written in the Article Spec column and you can just start writing.

Also, you can see the docs on writing articles for more info.

Becoming an editor

Looking for a longer-term contribution to the Magazine? Perhaps by setting the publishing schedule every week, reviewing ideas, editing articles, and attending the regular meeting? Become a member of the Editorial Board!

There are a few ways to start:

Help review ideas

The easiest start might be reviewing ideas and turning them into article spec. Provide feedback, suggest what should be included, and help decide what the article should look like overall. To do that, simply go to the issue tracker and start commenting.

Sometimes, we also receive ideas on the mailing list. Engaging with people on the mailing list is also a good way to contribute.

Attend the Editorial meeting

The Fedora Magazine editorial meeting is the place when we set the publishing schedule for the next week, and discuss various ideas regarding the Magazine.

You are very welcome to just attend one of the Editorial meetings we have. Just say hi, and maybe volunteer to edit an article (read below), create an image (read below), or even write something when we’re short on content. 

Article reviews

When there is any card in the Review column on the board, that means the writer is asking for a final review. You can read their article and put a comment in the card with what you think about it. You might say it looks great, or point out specific things you believe should be changed (although that is rare).

Design a cover image

Every article published on the Magazine has a cover image. If you enjoy making graphics, you can contribute some. See the cover image guidelines in our docs for more info, and either ask on the list or come to one of our editorial meetings to get assigned one. 

Recap

Fedora Magazine is a place to share useful and interesting content with people who love Linux by people who love Fedora. And it all happens thanks to people contributing ideas, writing articles, and helping to keep the Magazine running. If you like the idea of Fedora being popular, or people using open source, Fedora Magazine is a great place for anyone to discover and learn about all of that. Join us and be a part of Fedora’s success!

Use sshuttle to build a poor man’s VPN

Monday 14th of October 2019 08:00:16 AM

Nowadays, business networks often use a VPN (virtual private network) for secure communications with workers. However, the protocols used can sometimes make performance slow. If you can reach reach a host on the remote network with SSH, you could set up port forwarding. But this can be painful, especially if you need to work with many hosts on that network. Enter sshuttle — which lets you set up a quick and dirty VPN with just SSH access. Read on for more information on how to use it.

The sshuttle application was designed for exactly the kind of scenario described above. The only requirement on the remote side is that the host must have Python available. This is because sshuttle constructs and runs some Python source code to help transmit data.

Installing sshuttle

The sshuttle application is packaged in the official repositories, so it’s easy to install. Open a terminal and use the following command with sudo:

$ sudo dnf install sshuttle

Once installed, you may find the manual page interesting:

$ man sshuttle Setting up the VPN

The simplest case is just to forward all traffic to the remote network. This isn’t necessarily a crazy idea, especially if you’re not on a trusted local network like your own home. Use the -r switch with the SSH username and the remote host name:

$ sshuttle -r username@remotehost 0.0.0.0/0

However, you may want to restrict the VPN to specific subnets rather than all network traffic. (A complete discussion of subnets is outside the scope of this article, but you can read more here on Wikipedia.) Let’s say your office internally uses the reserved Class A subnet 10.0.0.0 and the reserved Class B subnet 172.16.0.0. The command above becomes:

$ sshuttle -r username@remotehost 10.0.0.0/8 172.16.0.0/16

This works great for working with hosts on the remote network by IP address. But what if your office is a large network with lots of hosts? Names are probably much more convenient — maybe even required. Never fear, sshuttle can also forward DNS queries to the office with the –dns switch:

$ sshuttle --dns -r username@remotehost 10.0.0.0/8 172.16.0.0/16

To run sshuttle like a daemon, add the -D switch. This also will send log information to the systemd journal via its syslog compatibility.

Depending on the capabilities of your system and the remote system, you can use sshuttle for an IPv6 based VPN. You can also set up configuration files and integrate it with your system startup if desired. If you want to read even more about sshuttle and how it works, check out the official documentation. For a look at the code, head over to the GitHub page.

Photo by Kurt Cotoaga on Unsplash.

Make your Python code look good with Black on Fedora

Friday 11th of October 2019 08:00:57 AM

The Python programing language is often praised for its simple syntax. In fact the language recognizes that code is read much more often than it is written. Black is a tool that automatically formats your Python source code making it uniform and compliant to the PEP-8 style guide.

How to install Black on Fedora

Installing Black on Fedora is quite simple. Black is maintained in the official repositories.

$ sudo dnf install python3-black

Black is a command line tool and therefore it is run from the terminal.

$ black --help Format your Python code with Black

Using Black to format a Python code base is straight forward.

$ black myfile.py All done!

Command line quick tips: Locate and process files with find and xargs

Wednesday 9th of October 2019 08:00:57 AM

find is one of the more powerful and flexible command-line programs in the daily toolbox. It does what the name suggests: it finds files and directories that match the conditions you specify. And with arguments like -exec or -delete, you can have find take action on what it… finds.

In this installment of the Command Line Quick Tips series, you’ll get an introduction to the find command and learn how to use it to process files with built-in commands or the xargs command.

Finding files

At a minimum, find takes a path to find things in. For example, this command will find (and print) every file on the system:

find /

And since everything is a file, you will get a lot of output to sort through. This probably doesn’t help you locate what you’re looking for. You can change the path argument to narrow things down a bit, but it’s still not really any more helpful than using the ls command. So you need to think about what you’re trying to locate.

Perhaps you want to find all the JPEG files in your home directory. The -name argument allows you to restrict your results to files that match the given pattern.

find ~ -name '*jpg'

But wait! What if some of them have an uppercase extension? -iname is like -name, but it is case-insensitive:

find ~ -iname '*jpg'

Great! But the 8.3 name scheme is so 1985. Some of the pictures might have a .jpeg extension. Fortunately, we can combine patterns with an “or,” represented by -o. The parentheses are escaped so that the shell doesn’t try to interpret them instead of the find command.

find ~ \( -iname '*jpeg' -o -iname '*jpg' \)

We’re getting closer. But what if you have some directories that end in jpg? (Why you named a directory bucketofjpg instead of pictures is beyond me.) We can modify our command with the -type argument to look only for files:

find ~ \( -iname '*jpeg' -o -iname '*jpg' \) -type f

Or maybe you’d like to find those oddly named directories so you can rename them later:

find ~ \( -iname '*jpeg' -o -iname '*jpg' \) -type d

It turns out you’ve been taking a lot of pictures lately, so narrow this down to files that have changed in the last week with -mtime (modification time). The -7 means all files modified in 7 days or fewer.

find ~ \( -iname '*jpeg' -o -iname '*jpg' \) -type f -mtime -7 Taking action with xargs

The xargs command takes arguments from the standard input stream and executes a command based on them. Sticking with the example in the previous section, let’s say you want to copy all of the JPEG files in your home directory that have been modified in the last week to a thumb drive that you’ll attach to a digital photo display. Assume you already have the thumb drive mounted as /media/photo_display.

find ~ \( -iname '*jpeg' -o -iname '*jpg' \) -type f -mtime -7 -print0 | xargs -0 cp -t /media/photo_display

The find command is slightly modified from the previous version. The -print0 command makes a subtle change on how the output is written: instead of using a newline, it adds a null character. The -0 (zero) option to xargs adjusts the parsing to expect this. This is important because otherwise actions on file names that contain spaces, quotes, or other special characters may not work as expected. You should use these options whenever you’re taking action on files.

The -t argument to cp is important because cp normally expects the destination to come last. You can do this without xargs using find‘s -exec command, but the xargs method will be faster, especially with a large number of files, because it will run as a single invocation of cp.

Find out more

This post only scratches the surface of what find can do. find supports testing based on permissions, ownership, access time, and much more. It can even compare the files in the search path to other files. Combining tests with Boolean logic can give you incredible flexibility to find exactly the files you’re looking for. With build in commands or piping to xargs, you can quickly process a large set of files.

Portions of this article were previously published on Opensource.com. Photo by Warren Wong on Unsplash.

IceWM – A really cool desktop

Monday 7th of October 2019 08:00:45 AM

IceWM is a very lightweight desktop. It’s been around for over 20 years, and its goals today are still the same as back then: speed, simplicity, and getting out of the users way.

I used to add IceWM to Scientific Linux, for a lightweight desktop. At the time, it was only a .5 Meg rpm. When running, it used only 5 Meg of memory. Over the years, IceWM has grown a little bit. The rpm package is now 1 Meg. When running, IceWM now uses 10 Meg of memory. Even though it literally doubled in size in the past 10 years, it is still extremely small.

What do you get in such a small package? Exactly what it says, a Window Manager. Not much else. You have a toolbar with a menu or icons to launch programs. You have speed. And finally you have themes and options. Besides the few goodies in the toolbar, that’s about it.

Installation

Because IceWM is so small, you just install the main package, and default theme. In Fedora 31, the default theme will be part of the main package.

Fedora 30 / IceWM 1.3.8 $ sudo dnf install icewm icewm-clearlooks Fedora 31/ IceWM 1.6.2 $ sudo dnf install icewm

In Fedora 31, the IceWM package will allow you to save disk space. Many of the dependencies are soft options.

$ sudo dnf install icewm --setopt install_weak_deps=false Options

The defaults for IceWM are set so that your average windows user feels comfortable. This is a good thing, because options are done manually, through configuration files.

I hope I didn’t lose you there, because it’s not as bad as it sounds. There are only 8 configuration files, and most people only use a couple. The main three config files are keys (keybinding), preferences (overall preferences), and toolbar (what is shown on the toolbar). The default config files are found in /usr/share/icewm/

To make a change, you copy the default config to you home icewm directory (~/.icewm), edit the file, and then restart IceWM. The first time you do this might be a little scary because “Restart Icewm” is found under the “Logout” menu entry. But when you restart IceWM, you just see a single flicker, and your changes are there. Any open programs are unaffected and stay as they were.

Themes IceWM in the NanoBlue theme

If you install the icewm-themes package, you get quite a few themes. Unlike regular options, you do not need to restart IceWM to change into a new theme. Usually I wouldn’t talk much about themes, but since there are so few other features, I figured I’m mention them.

Toolbar

The toolbar is the one place where a few extra features have been added to IceWM. You will see that you can switch between workplaces. Workspaces are sometimes called Virtual Desktops. Click on the workspace to move to it. Right clicking on a windows taskbar entry allows you to move it between workspaces. If you like workspaces, this has all the functionality you will like. If you don’t like workspaces, it’s an option and can be turned off.

The toolbar also has Network/Memory/CPU monitoring graphs. Hover your mouse over the graph to get details. Click on the graph to get a window with full monitoring. These little graphs used to be on every window manager. But as those desktops matured, they have all taken the graphs out. I’m very glad that IceWM has left this nice feature alone.

Summary

If you want something lightweight, but functional, IceWM is the desktop for you. It is setup so that new linux users can use it out of the box. It is flexible so that unix users can tweak it to their liking. Most importantly, IceWM lets your programs run without getting in the way.

In Fedora 31, 32-bit i686 is 86ed

Friday 4th of October 2019 08:00:42 AM

The release of Fedora 31 drops the 32-bit i686 kernel, and as a result bootable images. While there may be users out there who still have hardware which will not work with the 64-bit x86_64 kernel, there are very few. However, this article gives you the whole story behind the change, and what 32-bit material you’ll still find in Fedora 31.

What is happening?

The i686 architecture essentially entered community support with the Fedora 27 release. Unfortunately, there are not enough members of the community willing to do the work to maintain the architecture. Don’t worry, though — Fedora is not dropping all 32-bit packages. Many i686 packages are still being built to ensure things like multilib, wine, and Steam will continue to work.

While the repositories are no longer being composed and mirrored out, there is a koji i686 repository which works with mock for building 32-bit packages, and in a pinch to install 32-bit versions which are not part of the x86_64 multilib repository. Of course, maintainers expect this will see limited use. Users who simply need to run a 32-bit application should be able to do so with multilib on a 64-bit system.

What to do if you’re running 32-bit

If you still run 32-bit i686 installations, you’ll continue to receive supported Fedora updates through the Fedora 30 lifecycle. This is until roughly May or June of 2020. At that point, you can either reinstall as 64-bit x86_64 if your hardware supports it, or replace your hardware with 64-bit capable hardware if possible.

There is a user in the community who has done a successful “upgrade” from 32-bit Fedora to 64-bit x86 Fedora. While this is not an intended or supported upgrade path, it should work. The Project hopes to have some documentation for users who have 64-bit capable hardware to explain the process before the Fedora 30 end of life.

If you have a 64-bit capable CPU running 32-bit Fedora due to low memory, try one of the alternate desktop spins. LXDE and others tend to do fairly well in memory constrained environments. For users running simple servers on old 32-bit hardware that was just lying around, consider one of the newer ARM boards. The power savings alone can more than pay for the new hardware in many instances. And if none of these are on option, CentOS 7 offers a 32-bit image with longer term support for the platform.

Security and you

While some users may be tempted to keep running an older Fedora release past end of life, this is highly discouraged. People constantly research software for security issues. Often times, they find these issues which have been around for years.

Once Fedora maintainers know about such issues, they typically patch for them, and make updates available to supported releases — but not to end of life releases. And of course, once these vulnerabilities are public, there will be people trying to exploit them. If you run an older release past end of life, your security exposure increases over time as a result, putting your system at ever-growing risk.

Photo by Alexandre Debiève on Unsplash.

Fedora projects for Hacktoberfest

Wednesday 2nd of October 2019 02:02:13 PM

It’s October! That means its time for the annual Hacktoberfest presented by DigitalOcean and DEV. Hacktoberfest is a month-long event that encourages contributions to open source software projects. Participants who register and submit at least four pull requests to GitHub-hosted repositories during the month of October will receive a free t-shirt.

In a recent Fedora Magazine article, I listed some areas where would-be contributors could get started contributing to Fedora. In this article, I highlight some specific projects that provide an opportunity to help Fedora while you participate in Hacktoberfest.

Fedora infrastructure
  • Bodhi — When a package maintainer builds a new version of a software package to fix bugs or add new features, it doesn’t go out to users right away. First it spends time in the updates-testing repository where in can receive some real-world usage. Bodhi manages the flow of updates from the testing repository into the updates repository and provides a web interface for testers to provide feedback.
  • the-new-hotness — This project listens to release-monitoring.org (which is also on GitHub) and opens a Bugzilla issue when a new upstream release is published. This allows package maintainers to be quickly informed of new upstream releases.
  • koschei — koschei enables continuous integration for Fedora packages. It is software for running a service for scratch-rebuilding RPM packages in Koji instance when their build-dependencies change or after some time elapses.
  • MirrorManager2 — Distributing Fedora packages to a global user base requires a lot of bandwidth. Just like developing Fedora, distributing Fedora is a collaborative effort. MirrorManager2 tracks the hundreds of public and private mirrors and routes each user to the “best” one.
  • fedora-messaging — Actions within the Fedora community—from source code commits to participating in IRC meetings to…lots of things—generate messages that can be used to perform automated tasks or send notifications. fedora-messaging is the tool set that makes sending and receiving these messages possible.
  • fedocal — When is that meeting? Which IRC channel was it in again? Fedocal is the calendar system used by teams in the Fedora community to coordinate meetings. Not only is it a good Hacktoberfest project, it’s also looking for a new maintainer to adopt it.

In addition to the projects above, the Fedora Infrastructure team has highlighted good Hacktoberfest issues across all of their GitHub projects.

Community projects
  • bodhi-rs — This project provides Rust bindings for Bodhi.
  • koji-rs — Koji is the system used to build Fedora packages. Koji-rs provides bindings for Rust applications.
  • fedora-rs — This project provides a Rust library for interacting with Fedora services like other languages like Python have.
  • feedback-pipeline — One of the current Fedora Council objectives is minimization: work to reduce the installation and patching footprint of Fedora releases. feedback-pipeline is a tool developed by this team to generate reports of RPM sizes and dependencies.
And many more

The projects above are only a small sample focused on software used to build Fedora. Many Fedora packages have upstreams hosted on GitHub—too many to list here. The best place to start is with a project that’s important to you. Any contributions you make help improve the entire open source ecosystem. If you’re looking for something in particular, the Join Special Interest Group can help. Happy hacking!

Contribute at the kernel and IoT edition Fedora test days

Monday 30th of September 2019 08:00:49 AM

Fedora test days are events where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.

There are two upcoming test days in the upcoming week. The first, starts on Monday 30 September through Monday 07 October, is to test the Kernel 5.3. Wednesday October 02, the test day is focusing on Fedora 31 IoT Edition. Come and test with us to make the upcoming Fedora 31 even better.

Kernel test week

The kernel team is working on final integration for kernel 5.3. This version was just recently released and will arrive soon in Fedora. This version will also be the shipping kernel for Fedora 31. As a
result, the Fedora kernel and QA teams have organized a test week for
Monday, Sept 30 through Monday, October 07. Refer to the wiki page for links to the test images you’ll need to participate. The steps are clearly outlined in this document.

Fedora IoT Edition test day

Fedora Internet of Things is a variant of Fedora focused on IoT ecosystems. Whether you’re working on a home assistant, industrial gateways, or data storage and analytics, Fedora IoT provides a trusted open source platform to build on. Fedora IoT produces a monthly rolling release to help you keep your ecosystem up-to-date. The IoT and QA teams will have this test day for on Wednesday, October 02. Refer to the wiki page for links and resources to test the IoT Edition.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about both test days are on the wiki pages above. If you’re available on or around the days of the events, please do some testing and report your results.

How to contribute to Fedora

Friday 27th of September 2019 08:00:07 AM

One of the great things about open source software projects is that users can make meaningful contributions. With a large project like Fedora, there’s somewhere for almost everyone to contribute. The hard part is finding the thing that appeals to you. This article covers a few of the ways people participate in the Fedora community every day.

The first step for contributing is to create an account in the Fedora Account System. After that, you can start finding areas to contribute. This article is not comprehensive. If you don’t see something you’re interested in, check out What Can I Do For Fedora or contact the Join Special Interest Group (SIG).

Software development

This seems like an obvious place to get started, but Fedora has an “upstream first” philosophy. That means most of the software that ends up on your computer doesn’t originate in the Fedora Project, but with other open source communities. Even when Fedora package maintainers write code to add a feature or fix a bug, they work with the community to get those patches into the upstream project.

Of course, there are some applications that are specific to Fedora. These are generally more about building and shipping operating systems than the applications that get shipped to the end users. The Fedora Infrastructure project on GitHub has several applications that help make Fedora happen.

Packaging applications

Once software is written, it doesn’t just magically end up in Fedora. Package maintainers are the ones who make that happen. Fundamentally, the job of the package maintainer is to make sure the application successfully builds into an RPM package and to generally keep up-to-date with upstream releases. Sometimes, that’s as simple as editing a line in the RPM spec file and uploading the new source code. Other times, it involves diagnosing build problems or adding patches to fix bugs or apply configuration settings.

Packagers are also often the first point of contact for user support. When something goes wrong with an application, the user (or ABRT) will file a bug in Red Hat Bugzilla. The Fedora package maintainer can help the user diagnose the problem and either fix it in the Fedora package or help file a bug in the upstream project’s issue tracker.

Writing

Documentation is a key part of the success of any open source project. Without documentation, users don’t know how to use the software, contributors don’t know how to submit code or run test suites, and administrators don’t know how to install and run the application. The Fedora Documentation team writes release notes, in-depth guides, and short “quick docs” that provide task-specific information. Multi-lingual contributors can also help with translation and localization of both the documentation and software strings by joining the localization (L10n) team.

Of course, Fedora Magazine is always looking for contributors to write articles. The Contributing page has more information. [We’re partial to this way of contributing! — ed.]

Testing

Fedora users have come to rely on our releases working well. While we emphasize being on the leading edge, we want to make sure releases are usable, too. The Fedora Quality Assurance team runs a broad set of test cases and ensures all of the release criteria are met before anything ships. Before each release, the team arranges test days for various components.

Once the release is out, testing continues. Each package update first goes to the updates-testing repository before being published to the main testing repository. This gives people who are willing to test the opportunity to try updates before they go to the wider community. 

Graphic design

One of the first things that people notice when they install a new Fedora release is the desktop background. In fact, using a new desktop background is one of our release criteria. The Fedora Design team produces several backgrounds for each release. In addition, they design stickers, logos, infographics, and many other visual elements for teams within Fedora. As you contribute, you may notice that you get awarded badges; the Badges team produces the art for those.

Helping others

Cooperative effort is a hallmark of open source communities. One of the best ways to contribute to any project is to help other users. In Fedora, that can mean answering questions on the Ask Fedora forum, the users mailing list, or in the #fedora IRC channel. Many third-party social media and news aggregator sites have discussion related to Fedora where you can help out as well.

Spreading the word

Why put so much effort into making something that no one knows about? Spreading the word helps our user and contributor communities grow. You can host a release party, speak at a conference, or share how you use Fedora on your blog or social media sites. The Fedora Mindshare committee has funds available to help with the costs of parties and other events.

Other contributions

This article only shared a few of the areas where you can contribute to Fedora. What Can I Do For Fedora has more options. If there’s something you don’t see, you can just start doing it. If others see the value, they can join in and help you. We look forward to your contributions!

Photo by Anunay Mahajan on Unsplash.

Fedora and CentOS Stream

Tuesday 24th of September 2019 07:32:14 PM

From the desk of the Fedora Project Leader:

Hi everyone! You may have seen the announcement about changes over at the CentOS Project. (If not, please go ahead and take a few minutes and read it — I’ll wait!) And now you may be wondering: if CentOS is now upstream of RHEL, what happens to Fedora? Isn’t that Fedora’s role in the Red Hat ecosystem?

First, don’t worry. There are changes to the big picture, but they’re all for the better.

If you’ve been following the conference talks from Red Hat Enterprise Linux leadership about the relationship between Fedora, CentOS, and RHEL, you have heard about “the Penrose Triangle”. That’s a shape like something from an M. C. Escher drawing: it’s impossible in real life!

We’ve been thinking for a while that maybe impossible geometry is not actually the best model. 

For one thing, the imagined flow where contributions at the end would flow back into Fedora and grow in a “virtuous cycle” never actually worked that way. That’s a shame, because there’s a huge, awesome CentOS community and many great people working on it — and there’s a lot of overlap with the Fedora community too. We’re missing out.

But that gap isn’t the only one: there’s not really been a consistent flow between the projects and product at all. So far, the process has gone like this: 

  1. Some time after the previous RHEL release, Red Hat would suddenly turn more attention to Fedora than usual.
  2. A few months later, Red Hat would split off a new RHEL version, developed internally.
  3. After some months, that’d be put into the world, including all of the source — from which CentOS is built. 
  4. Source drops continue for updates, and sometimes those updates include patches that were in Fedora — but there’s no visible connection.

Each step here has its problems: intermittent attention, closed-door development, blind drops, and little ongoing transparency. But now Red Hat and CentOS Project are fixing that, and that’s good news for Fedora, too.

Fedora will remain the first upstream of RHEL. It’s where every RHEL came from, and is where RHEL 9 will come from, too. But after RHEL branches off, CentOS will be upstream for ongoing work on those RHEL versions. I like to call it “the midstream”, but the marketing folks somehow don’t, so that’s going to be called “CentOS Stream”.

We — Fedora, CentOS, and Red Hat — still need to work out all of the technical details, but the idea is that these branches will live in the same package source repository. (The current plan is to make a “src.centos.org” with a  parallel view of the same data as src.fedoraproject.org). This change gives public visibility into ongoing work on released RHEL, and a place for developers and Red Hat’s partners to collaborate at that level.

CentOS SIGs — the special interest groups for virtualization, storage, config management and so on — will do their work in shared space right next to Fedora branches. This will allow much easier collaboration and sharing between the projects, and I’m hoping we’ll even be able to merge some of our similar SIGs to work together directly. Fixes from Fedora packages can be cherry-picked into the CentOS “midstream” ones — and where useful, vice versa.

Ultimately, Fedora, CentOS, and RHEL are part of the same big project family. This new, more natural flow opens possibilities for collaboration which were locked behind artificial (and extra-dimensional!) barriers. I’m very excited for what we can now do together!

— Matthew Miller, Fedora Project Leader

CodeReady Containers: complex solutions on OpenShift + Fedora

Tuesday 24th of September 2019 08:00:49 AM

Want to experiment with (complex) solutions on OpenShift 4.1+? CodeReady Containers (CRC) on a physical Fedora server is a great choice. It lets you:

  • Configure the RAM available to CRC / OpenShift (this is key as we’ll deploy Machine Learning, Change Data Capture, Process Automation and other solutions with significant memory requirements)
  • Avoid installing anything on your laptop
  • Standardize (on Fedora 30) so that you get the same results every time

Start by installing CRC and Ansible Agnostic Deployer (AgnosticD) on a Fedora 30 physical server. Then, you’ll use AgnosticD to deploy Open Data Hub on the OpenShift 4.1 environment created by CRC. Let’s get started!

Set up CodeReady Containers $ dnf config-manager --set-enabled fedora $ su -c 'dnf -y install git wget tar qemu-kvm libvirt NetworkManager jq libselinux-python' $ sudo systemctl enable --now libvirtd

Let’s also add a user.

$ sudo adduser demouser $ sudo passwd demouser $ sudo usermod -aG wheel demouser

Download and extract CodeReady Containers:

$ su demouser $ cd /home/demouser $ wget https://mirror.openshift.com/pub/openshift-v4/clients/crc/1.0.0-beta.3/crc-linux-amd64.tar.xz $ tar -xvf crc-linux-amd64.tar.xz $ cd crc-linux-1.0.0-beta.3-amd64/ $ sudo cp ./crc /usr/bin

Set the memory available to CRC according to what you have on your physical server. For example, on a physical server with around 100GB you can allocate 80G to CRC as follows:

$ crc config set memory 81920 $ crc setup

You’ll need your pull secret from https://cloud.redhat.com/openshift/install/metal/user-provisioned.

$ crc start

That’s it — you can now login to your OpenShift environment:

eval $(crc oc-env) && oc login -u kubeadmin -p <password> https://api.crc.testing:6443 Set up Ansible Agnostic Deployer

github.com/redhat-cop/agnosticd is a fully automated two-phase deployer. Let’s deploy it!

$ su demouser $ cd /home/demouser $ git clone https://github.com/redhat-cop/agnosticd.git $ cd agnosticd/ansible $ python -m pip install --upgrade --trusted-host files.pythonhosted.org -r requirements.txt $ python3 -m pip install --upgrade --trusted-host files.pythonhosted.org -r requirements.txt $ pip3 install kubernetes $ pip3 install openshift $ pip install kubernetes $ pip install openshift Set up Open Data Hub on Code Ready Containers

Open Data Hub is a machine-learning-as-a-service platform built on OpenShift and Kafka/Strimzi. It integrates a collection of open source projects.

First, create an Ansible inventory file with the following content.

$ cat inventory $ 127.0.0.1 ansible_connection=local

Set up the WORKLOAD environment variable so that Ansible Agnostic Deployer knows that we want to deploy Open Data Hub.

$ export WORKLOAD="ocp4-workload-open-data-hub" $ sudo cp /usr/local/bin/ansible-playbook /usr/bin/ansible-playbook

We are only deploying one Open Data Hub project, so set user_count to 1. You can set up workshops for many students by setting user_count.

An OpenShift project (with Open Data Hub in our case) will be created for each student.

$ eval $(crc oc-env) && oc login -u kubeadmin -p <password> https://api.crc.testing:6443 $ ansible-playbook -i inventory ./configs/ocp-workloads/ocp-workload.yml -e"ocp_workload=${WORKLOAD}" -e"ACTION=create" -e"user_count=1" -e"ocp_username=kubeadmin" -e"ansible_become_pass=<password>" -e"silent=False" $ oc project open-data-hub-user1 $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD jupyterhub jupyterhub-open-data-hub-user1.apps-crc.testing jupyterhub 8080-tcp edge/Redirect None

On your laptop, add jupyterhub-open-data-hub-user1.apps-crc.testing to your /etc/hosts file. For example:

127.0.0.1 localhost fedora30 console-openshift-console.apps-crc.testing oauth-openshift.apps-crc.testing mapit-app-management.apps-crc.testing mapit-spring-pipeline-demo.apps-crc.testing jupyterhub-open-data-hub-user1.apps-crc.testing jupyterhub-open-data-hub-user1.apps-crc.testing

On your laptop:

$ sudo ssh marc@fedora30 -L 443:jupyterhub-open-data-hub-user1.apps-crc.testing:443

You can now browse to https://jupyterhub-open-data-hub-user1.apps-crc.testing.

Now that we have Open Data Hub ready, you could deploy something interesting on it. For example, you could deploy IBM’s Qiskit open source framework for quantum computing. For more information, refer to Video no. 9 at this YouTube playlist, and the Github repo here.

You could also deploy plenty of other useful tools for Process Automation, Change Data Capture, Camel Integration, and 3scale API Management. You don’t have to wait for articles on these, though. Step-by-step short videos are already available on YouTube.

The corresponding step-by-step instructions are also on YouTube. You can also follow along with this article using the GitHub repo.

Photo by Marta Markes on Unsplash.

Managing network interfaces and FirewallD in Cockpit

Friday 20th of September 2019 09:30:47 AM

In the last article, we saw how Cockpit can manage storage devices. This article will focus on the networking functionalities within the UI. We’ll see how to manage the interfaces attached to the system in Cockpit. We’ll also look at the firewall and demonstrate how to assign a zone to an interface, and allow/deny services and ports.

To access these controls, verify the cockpit-networkmanager package is installed.

To start, log into the Cockpit UI and select the Networking menu option. As is consistent with the UI design we see performance graphs at the top and a summary of the logs at the bottom of the page. Between them are the sections to manage the firewall and interface(s).

Firewall

Cockpit’s firewall configuration page works with FirewallD and allows admins to quickly configure these settings. The page has options for assigning zones to specific interfaces, as well as a list of services configured to those zones.

Adding a zone

Let’s start by configuring a zone to an available interface. First, click the Add Zone button. From here you can select a pre-configured or custom zone. Selecting one of the zones will display a brief description of that zone, as well as the services, or ports, allowed, or opened, in that zone. Select the interface you want to assign the zone to. Also, there’s the option to configure the rules to apply to the Entire Subset, or you can specify a Range of IP addresses. In the example below, we add the Internal zone to an available network card. The IP range can also be configured so the rule is only applied to the specified addresses.

Adding and removing services/ports

To allow network access to services, or open ports, click the Add Services button. From here you can search (or filter) for a service, or manually enter the port(s) you would like to open. Selecting the Custom Ports option provides options to enter the port number or alias into the TCP and/or UDP fields. You can also provide an optional name to label the rule. In the example below, the Cockpit service/socket is added to the Internal zone. Once completed, click the Add Services, or Add Ports, button. Likewise, to remove the service click the red trashcan to the right, select the zone(s), and click Remove service.

For more information about using Cockpit to configure your system’s firewall, visit the Cockpit project’s Github page.

Interfaces

The interfaces section displays both physical and virtual/logical NICs assigned to the system. From the main screen we see the name of the interface, the IP address, and activity stats of the NIC. Selecting an interface will display IP related information and options to manually configure them. You can also choose to have the network card inactive after a reboot by toggling the Connect automatically option. To enable, or disable, the network interface, click the toggle switch in the top right corner of the section.

Bonding

Bonding network interfaces can help increase bandwidth availability. It can also serve as a redundancy plan in the event one of the NIC’s fail.

To start, click the Add Bond button located in the header of the Interfaces section. In the Bond Settings overlay, enter a name and select the interfaces you wish to bond in the list below. Next, select the MAC Address you would like to assign to the bond. Now select the Mode, or purpose, of the bond: Round Robin, Active Backup, Broadcast, &c. (the demo below shows a complete list of modes.)

Continue the configuration by selecting the Primary NIC, and a Link Monitoring option. You can also tweak the Monitoring Interval, and Link Up Delay and Link Down Delay options. To finish the configuration, click the Apply button. We’re taken back to the main screen, and the new bonded interface we just created is added to the list of interfaces.

From here we can configure the bond like any other interface. We can even delve deeper into the interface’s settings for the bond. As seen in the example below, selecting one of the interfaces in the bond’s settings page provides details pertaining to the interface link. There’s also an added option for changing the bond settings. To delete the bond, click the Delete button.

Teaming

Teaming, like bonding, is another method used for link aggregation. For a comparison between bonding and teaming, refer to this chart. You can also find more information about teaming on the Red Hat documentation site.

As with creating a bond, click the Add Team button. The settings are similar in the sense you can give it a name, select the interfaces, link delay, and the mode or Runner as it’s referred to here. The options are similar to the ones available for bonding. By default the Link Watch option is set to Ethtool, but also has options for ARP Ping, and NSNA Ping.

Click the Apply button to complete the setup. It will also return you to the main networking screen. For further configuration, such as IP assignment and changing the runner, click the newly made team interface. As with bonding, you can click one of the interfaces in the link aggregation. Depending on the runner, you may have additional options for the Team Port. Click the Delete button from the screen to remove the team.

Bridging

From the article, Build a network bridge with Fedora:

“A bridge is a network connection that combines multiple network adapters.”

One excellent example for a bridge is combining the physical NIC with a virtual interface, like the one created and used for KVM virtualization. Leif Madsen’s blog has an excellent article on how to achieve this in the CLI. This can also be accomplished in Cockpit with just a few clicks. The example below will accomplish the first part of Leif’s blog using the web UI. We’ll bridge the enp9s0 interface with the virbr0 virtual interface.

Click the Add Bridge button to launch the settings box. Provide a name and select the interfaces you would like to bridge. To enable Spanning Tree Protocol (STP), click the box to the right of the label. Click the Apply button to finalize the configuration.

As is consistent with teaming and bonding, selecting the bridge from the main screen will display the details of the interface. As seen in the example below, the physical device takes control and the virtual interface will adopt that device’s IP address.

Select the individual interface in the bridge’s detail screen for more options. And once again, click the Delete button to remove the bridge.

Adding VLANs

Cockpit allows admins to create VLANs, or virtual networks, using any of the interfaces on the system. Click the Add VLAN button and select an interface. Furthermore, in the Parent drop-down list, assign the VLAN ID, and if you like, give it a new name. By default the name will be the same as the parent followed by a dot and the ID. For example, interface enp11s0 with VLAN ID 9 will result in enp11s0.9). Click Apply to save the settings and to return to the networking main screen. Click the VLAN interface for further configuration. As always, click the Delete button to remove the VLAN.

As we can see, Cockpit can help admins with common network configurations when managing the system’s connectivity. In the next article, we’ll explore how Cockpit handles user management and peek into the add-on 389 Directory Servers.

Announcing the release of Fedora 31 Beta

Tuesday 17th of September 2019 01:47:20 PM

The Fedora Project is pleased to announce the immediate availability of Fedora 31 Beta, the next step towards our planned Fedora 31 release at the end of October.

Download the prerelease from our Get Fedora site:

Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices like the Raspberry Pi 2 and 3:

Beta Release Highlights GNOME 3.34 (almost)

The newest release of the GNOME desktop environment is full of performance enhancements and improvements. The beta ships with a prerelease, and the full 3.34 release will be available as an update. For a full list of GNOME 3.34 highlights, see the release notes.

Fedora IoT Edition

Fedora Editions address specific use-cases the Fedora Council has identified as significant in growing our userbase and community. We have Workstation, Server, and CoreOS — and now we’re adding Fedora IoT. This will be available from the main “Get Fedora” site when the final release of F31 is ready, but for now, get it from iot.fedoraproject.org.

Read more about Fedora IoT in our Getting Started docs.

Fedora CoreOS

Fedora CoreOS remains in a preview state, with a planned generally-available release planned for early next year. CoreOS is a rolling release which rebases periodically to a new underlying Fedora OS version. Right now, that version is Fedora 30, but soon there will be a “next” stream which will track Fedora 31 until that’s ready to become the “stable” stream.

Other updates

Fedora 31 Beta includes updated versions of many popular packages like Node.js, the Go language, Python, and Perl. We also have the customary updates to underlying infrastructure software, like the GNU C Library and the RPM package manager. For a full list, see the Change set on the Fedora Wiki.

Farewell to bootable i686

We’re no longer producing full media or repositories for 32-bit Intel-architecture systems. We recognize that this means newer Fedora releases will no longer work on some older hardware, but the fact is there just hasn’t been enough contributor interest in maintaining i686, and we can provide greater benefit for the majority of our users by focusing on modern architectures. (The majority of Fedora systems have been 64-bit x86_64 since 2013, and at this point that’s the vast majority.)

Please note that we’re still making userspace packages for compatibility when running 32-bit software on a 64-bit systems — we don’t see the need for that going away anytime soon.

Testing needed

Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in #fedora-qa on Freenode. As testing progresses, common issues are tracked on the Common F31 Bugs page.

For tips on reporting a bug effectively, read how to file a bug.

What is the Beta Release?

A Beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the Beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora, but Linux and free software as a whole.

More information

For more detailed information about what’s new on Fedora 31 Beta release, you can consult the Fedora 31 Change set. It contains more technical information about the new packages and improvements shipped with this release.

Copying large files with Rsync, and some misconceptions

Monday 16th of September 2019 08:00:15 AM

There is a notion that a lot of people working in the IT industry often copy and paste from internet howtos. We all do it, and the copy-and-paste itself is not a problem. The problem is when we run things without understanding them.

Some years ago, a friend who used to work on my team needed to copy virtual machine templates from site A to site B. They could not understand why the file they copied was 10GB on site A but but it became 100GB on-site B.

The friend believed that rsync is a magic tool that should just “sync” the file as it is. However, what most of us forget is to understand what rsync really is, and how is it used, and the most important in my opinion is, where it come from. This article provides some further information about rsync, and an explanation of what happened in that story.

About rsync

rsync is a tool was created by Andrew Tridgell and Paul Mackerras who were motivated by the following problem:

Imagine you have two files, file_A and file_B. You wish to update file_B to be the same as file_A. The obvious method is to copy file_A onto file_B.

Now imagine that the two files are on two different servers connected by a slow communications link, for example, a dial-up IP link. If file_A is large, copying it onto file_B will be slow, and sometimes not even possible. To make it more efficient, you could compress file_A before sending it, but that would usually only gain a factor of 2 to 4.

Now assume that file_A and file_B are quite similar, and to speed things up, you take advantage of this similarity. A common method is to send just the differences between file_A and file_B down the link and then use such list of differences to reconstruct the file on the remote end.

The problem is that the normal methods for creating a set of differences between two files rely on being able to read both files. Thus they require that both files are available beforehand at one end of the link. If they are not both available on the same machine, these algorithms cannot be used. (Once you had copied the file over, you don’t need the differences). This is the problem that rsync addresses.

The rsync algorithm efficiently computes which parts of a source file match parts of an existing destination file. Matching parts then do not need to be sent across the link; all that is needed is a reference to the part of the destination file. Only parts of the source file which are not matching need to be sent over.

The receiver can then construct a copy of the source file using the references to parts of the existing destination file and the original material.

Additionally, the data sent to the receiver can be compressed using any of a range of common compression algorithms for further speed improvements.

The rsync algorithm addresses this problem in a lovely way as we all might know.

After this introduction on rsync, Back to the story!

Problem 1: Thin provisioning

There were two things that would help the friend understand what was going on.

The problem with the file getting significantly bigger on the other size was caused by Thin Provisioning (TP) being enabled on the source system — a method of optimizing the efficiency of available space in Storage Area Networks (SAN) or Network Attached Storages (NAS).

The source file was only 10GB because of TP being enabled, and when transferred over using rsync without any additional configuration, the target destination was receiving the full 100GB of size. rsync could not do the magic automatically, it had to be configured.

The Flag that does this work is -S or –sparse and it tells rsync to handle sparse files efficiently. And it will do what it says! It will only send the sparse data so source and destination will have a 10GB file.

Problem 2: Updating files

The second problem appeared when sending over an updated file. The destination was now receiving just the 10GB, but the whole file (containing the virtual disk) was always transferred. Even when a single configuration file was changed on that virtual disk. In other words, only a small portion of the file changed.

The command used for this transfer was:

rsync -avS vmdk_file syncuser@host1:/destination

Again, understanding how rsync works would help with this problem as well.

The above is the biggest misconception about rsync. Many of us think rsync will simply send the delta updates of the files, and that it will automatically update only what needs to be updated. But this is not the default behaviour of rsync.

As the man page says, the default behaviour of rsync is to create a new copy of the file in the destination and to move it into the right place when the transfer is completed.

To change this default behaviour of rsync, you have to set the following flags and then rsync will send only the deltas:

--inplace update destination files in-place --partial keep partially transferred files --append append data onto shorter files --progress show progress during transfer

So the full command that would do exactly what the friend wanted is:

rsync -av --partial --inplace --append --progress vmdk_file syncuser@host1:/destination

Note that the sparse flag -S had to be removed, for two reasons. The first is that you can not use –sparse and –inplace together when sending a file over the wire. And second, when you once sent a file over with –sparse, you can’t updated with –inplace anymore. Note that versions of rsync older than 3.1.3 will reject the combination of –sparse and –inplace.

So even when the friend ended up copying 100GB over the wire, that only had to happen once. All the following updates were only copying the difference, making the copy to be extremely efficient.

GNOME 3.34 released — coming soon in Fedora 31

Friday 13th of September 2019 08:00:34 AM

Today the GNOME project announced the release of GNOME 3.34. This latest release of GNOME will be the default desktop environment in Fedora 31 Workstation. The Beta release of Fedora 31 is currently expected in the next week or two, with the Final release scheduled for late October.

GNOME 3.34 includes a number of new features and improvements. Congratulations and thank you to the whole GNOME community for the work that went into this release! Read on for more details.

GNOME 3.34 desktop environment at work Notable features

The desktop itself has been refreshed with a pleasing new background. You can also compare your background images to see what they’ll look like on the desktop.

There’s a new custom application folder feature in the GNOME Shell Overview. It lets you combine applications in a group to make it easier to find the apps you use.

You already know that Boxes lets you easily download an OS and create virtual machines for testing, development, or even daily use. Now you can find sources for your virtual machines more easily, as well as boot from CD or DVD (ISO) images more easily. There is also an Express Install feature available that now supports Windows versions.

Now that you can save states when using GNOME Games, gaming is more fun. You can snapshot your progress without getting in the way of the fun. You can even move snapshots to other devices running GNOME.

More details

These are not the only features of the new and improved GNOME 3.34. For an overview, visit the official release announcement. For even more details, check out the GNOME 3.34 release notes.

The Fedora 31 Workstation Beta release is right around the corner. Fedora 31 will feature GNOME 3.34 and you’ll be able to experience it in the Beta release.

How to set up a TFTP server on Fedora

Wednesday 11th of September 2019 08:00:39 AM

TFTP, or Trivial File Transfer Protocol, allows users to transfer files between systems using the UDP protocol. By default, it uses UDP port 69. The TFTP protocol is extensively used to support remote booting of diskless devices. So, setting up a TFTP server on your own local network can be an interesting way to do Fedora installations, or other diskless operations.

TFTP can only read and write files to or from a remote system. It doesn’t have the capability to list files or make any changes on the remote server. There are also no provisions for user authentication. Because of security implications and the lack of advanced features, TFTP is generally only used on a local area network (LAN).

TFTP server installation

The first thing you will need to do is install the TFTP client and server packages:

dnf install tftp-server tftp -y

This creates a tftp service and socket file for systemd under /usr/lib/systemd/system.

/usr/lib/systemd/system/tftp.service /usr/lib/systemd/system/tftp.socket

Next, copy and rename these files to /etc/systemd/system:

cp /usr/lib/systemd/system/tftp.service /etc/systemd/system/tftp-server.service cp /usr/lib/systemd/system/tftp.socket /etc/systemd/system/tftp-server.socket Making local changes

You need to edit these files from the new location after you’ve copied and renamed them, to add some additional parameters. Here is what the tftp-server.service file initially looks like:

[Unit] Description=Tftp Server Requires=tftp.socket Documentation=man:in.tftpd [Service] ExecStart=/usr/sbin/in.tftpd -s /var/lib/tftpboot StandardInput=socket [Install] Also=tftp.socket

Make the following changes to the [Unit] section:

Requires=tftp-server.socket

Make the following changes to the ExecStart line:

ExecStart=/usr/sbin/in.tftpd -c -p -s /var/lib/tftpboot

Here are what the options mean:

  • The -c option allows new files to be created.
  • The -p option is used to have no additional permissions checks performed above the normal system-provided access controls.
  • The -s option is recommended for security as well as compatibility with some boot ROMs which cannot be easily made to include a directory name in its request.

The default upload/download location for transferring the files is /var/lib/tftpboot.

Next, make the following changes to the [Install] section:

[Install] WantedBy=multi-user.target Also=tftp-server.socket

Don’t forget to save your changes!

Here is the completed /etc/systemd/system/tftp-server.service file:

[Unit] Description=Tftp Server Requires=tftp-server.socket Documentation=man:in.tftpd [Service] ExecStart=/usr/sbin/in.tftpd -c -p -s /var/lib/tftpboot StandardInput=socket [Install] WantedBy=multi-user.target Also=tftp-server.socket Starting the TFTP server

Reload the systemd daemon:

systemctl daemon-reload

Now start and enable the server:

systemctl enable --now tftp-server

To change the permissions of the TFTP server to allow upload and download functionality, use this command. Note TFTP is an inherently insecure protocol, so this may not be advised on a network you share with other people.

chmod 777 /var/lib/tftpboot

Configure your firewall to allow TFTP traffic:

firewall-cmd --add-service=tftp --perm firewall-cmd --reload Client Configuration

Install the TFTP client:

yum install tftp -y

Run the tftp command to connect to the TFTP server. Here is an example that enables the verbose option:

[client@thinclient:~ ]$ tftp 192.168.1.164 tftp> verbose Verbose mode on. tftp> get server.logs getting from 192.168.1.164:server.logs to server.logs [netascii] Received 7 bytes in 0.0 seconds [inf bits/sec] tftp> quit [client@thinclient:~ ]$

Remember, TFTP does not have the ability to list file names. So you’ll need to know the file name before running the get command to download any files.

Photo by Laika Notebooks on Unsplash.

Firefox 69 available in Fedora

Monday 9th of September 2019 08:00:57 AM

When you install the Fedora Workstation, you’ll find the world-renowned Firefox browser included. The Mozilla Foundation underwrites work on Firefox, as well as other projects that promote an open, safe, and privacy respecting Internet. Firefox already features a fast browsing engine and numerous privacy features.

A community of developers continues to improve and enhance Firefox. The latest version, Firefox 69, was released recently and you can get it for your stable Fedora system (30 and later). Read on for more details.

New features in Firefox 69

The newest version of Firefox includes Enhanced Tracking Protection (or ETP). When you use Firefox 69 with a new (or reset) settings profile, the browser makes it harder for sites to track your information or misuse your computer resources.

For instance, less scrupulous websites use scripts that cause your system to do lots of intense calculations to produce cryptocurrency results, called cryptomining. Cryptomining happens without your knowledge or permission and is therefore a misuse of your system. The new standard setting in Firefox 69 prevents sites from this kind of abuse.

Firefox 69 has additional settings to prevent sites from identifying or fingerprinting your browser for later use. These improvements give you additional protection from having your activities tracked online.

Another common annoyance is videos that start in your browser without warning. Video playback also uses extra CPU power and you may not want this happening on your laptop without permission. Firefox already stops this from happening using the Block Autoplay feature. But Firefox 69 also lets you stop videos from playing even if they start without sound. This feature prevents unwanted sudden noise. It also solves more of the real problem — having your computer’s power used without permission.

There are numerous other new features in the new release. Read more about them in the Firefox release notes.

How to get the update

Firefox 69 is available in the stable Fedora 30 and pre-release Fedora 31 repositories, as well as Rawhide. The update is provided by Fedora’s maintainers of the Firefox package. The maintainers also ensured an update to Mozilla’s Network Security Services (the nss package). We appreciate the hard work of the Mozilla project and Firefox community in providing this new release.

If you’re using Fedora 30 or later, use the Software tool on Fedora Workstation, or run the following command on any Fedora system:

$ sudo dnf --refresh upgrade firefox

If you’re on Fedora 29, help test the update for that release so it can become stable and easily available for all users.

Firefox may prompt you to upgrade your profile to use the new settings. To take advantage of new features, you should do this.

Performing storage management tasks in Cockpit

Friday 6th of September 2019 08:00:47 AM

In the previous article we touched upon some of the new features introduced to Cockpit over the years. This article will look into some of the tools within the UI to perform everyday storage management tasks. To access these functionalities, install the cockpit-storaged package:

sudo dnf install cockpit-storaged

From the main screen, click the Storage menu option in the left column. Everything needed to observe and manage disks is available on the main Storage screen. Also, the top of the page displays two graphs for the disk’s reading and writing performance with the local filesystem’s information below. In addition, the options to add or modify RAID devices, volume groups, iSCSI devices, and drives are available as well. In addition, scrolling down will reveal a summary of recent logs. This allows admins to catch any errors that require immediate attention.

Filesystems

This section lists the system’s mounted partitions. Clicking on a partition will display information and options for that mounted drive. Growing and shrinking partitions are available in the Volume sub-section. There’s also a filesystem subsection that allows you to change the label and configure the mount.

If it’s part of a volume group, other logical volumes in that group will also be available. Each standard partition has the option to delete and format. Also, logical volumes have an added option to deactivate the partition.

RAID devices

Cockpit makes it super-easy to manage RAID drives. With a few simple clicks the RAID drive is created, formatted, encrypted, and mounted. For details, or a how-to on creating a RAID device from the CLI check out the article Managing RAID arrays with mdadm.

To create a RAID device, start by clicking the add (+) button. Enter a name, select the type of RAID level and the available drives, then click Create. The RAID section will show the newly created device. Select it to create the partition table and format the drive(s). You can always remove the device by clicking the Stop and Delete buttons in the top-right corner.

Logical volumes

By default, the Fedora installation uses LVM when creating the partition scheme. This allows users to create groups, and add volumes from different disks to those groups. The article, Use LVM to Upgrade Fedora, has some great tips and explanations on how it works in the command-line.

Start by clicking the add (+) button next to “Volume Groups”. Give the group a name, select the disk(s) for the volume group, and click Create. The new group is available in the Volume Groups section. The example below demonstrates a new group named “vgraiddemo”.

Now, click the newly made group then select the option to Create a New Logical Volume. Give the LV a name and select the purpose: Block device for filesystems, or pool for thinly provisioning volumes. Adjust the amount of storage, if necessary, and click the Format button to finalize the creation.

Cockpit can also configure current volume groups. To add a drive to an existing group, click the name of the volume group, then click the add (+) button next to “Physical Volumes”. Select the disk from the list and click the Add button. In one shot, not only has a new PV, been created, but it’s also added to the group. From here, we can add the available storage to a partition, or create a new LV. The example below demonstrates how the additional space is used to grow the root filesystem.

iSCSI targets

Connecting to an iSCSI server is a quick process and requires two things, the initiator’s name, which is assigned to the client, and the name or IP of the server, or target. Therefore we will need to change the initiator’s name on the system to match the configurations on the target server.

To change the initiator’s name, click the button with the pencil icon, enter the name, and click Change.

To add the iSCSI target, click the add (+) button, enter the server’s address, the username and password, if required, and click Next. Select the target — verify the name, address, and port, — and click Add to finalize the process.

To remove a target, click the “checkmark” button. A red trashcan will appear beside the target(s). Click it to remove the target from the setup list.

NFS mount

Cockpit even allows sysadmins to configure NFS shares within the UI. To add NFS shares, click the add (+) button in the NFS mounts section. Enter the server’s address, the path of the share on the server, and a location on the local machine to mount the share. Adjust the mount options if needed and click Add to view information about the share. We also have the options to unmount, edit, and remove the share. The example below demonstrates how the NFS share on SERVER02 is mounted to the /mnt directory.

Conclusion

As we’ve seen in this article, a lot of the storage-related tasks that require lengthy, and multiple, lines of commands can be easily done within the web UI with just a few clicks. Cockpit is continuously evolving and every new feature makes the project better and better. In the next article we’ll explore the features and components on the networking side of things.

How to build Fedora container images

Wednesday 4th of September 2019 09:45:28 AM

With the rise of containers and container technology, all major Linux distributions nowadays provide a container base image. This article presents how the Fedora project builds its base image. It also shows you how to use it to create a layered image.

Base and layered images

Before we look at how the Fedora container base image is built, let’s define a base image and a layered image. A simple way to define a base image is an image that has no parent layer. But what does that concretely mean? It means a base image usually contains only the root file system (rootfs) of an operating system. The base image generally provides the tools needed to install software in order to create layered images.

A layered image adds a collections of layers on top of the base image in order to install, configure, and run an application. Layered images reference base images in a Dockerfile using the FROM instruction:

FROM fedora:latest How to build a base image

Fedora has a full suite of tools available to build container images. This includes podman, which does not require running as the root user.

Building a rootfs

A base image comprises mainly a tarball. This tarball contains a rootfs. There are different ways to build this rootfs. The Fedora project uses the kickstart installation method coupled with imagefactory software to create these tarballs.

The kickstart file used during the creation of the Fedora base image is available in Fedora’s build system Koji. The Fedora-Container-Base package regroups all the base image builds. If you select a build, it gives you access to all the related artifacts, including the kickstart files. Looking at an example, the %packages section at the end of the file defines all the packages to install. This is how you make software available in the base image.

Using a rootfs to build a base image

Building a base image is easy, once a rootfs is available. It requires only a Dockerfile with the following instructions:

FROM scratch ADD layer.tar / CMD ["/bin/bash"]

The important part here is the FROM scratch instruction, which is creating an empty image. The following instructions then add the rootfs to the image, and set the default command to be executed when the image is run.

Let’s build a base image using a Fedora rootfs built in Koji:

$ curl -o fedora-rootfs.tar.xz https://kojipkgs.fedoraproject.org/packages/Fedora-Container-Base/Rawhide/20190902.n.0/images/Fedora-Container-Base-Rawhide-20190902.n.0.x86_64.tar.xz $ tar -xJvf fedora-rootfs.tar.xz 51c14619f9dfd8bf109ab021b3113ac598aec88870219ff457ba07bc29f5e6a2/layer.tar $ mv 51c14619f9dfd8bf109ab021b3113ac598aec88870219ff457ba07bc29f5e6a2/layer.tar layer.tar $ printf "FROM scratch\nADD layer.tar /\nCMD [\"/bin/bash\"]" > Dockerfile $ podman build -t my-fedora . $ podman run -it --rm my-fedora cat /etc/os-release

The layer.tar file which contains the rootfs needs to be extracted from the downloaded archive. This is only needed because Fedora generates images that are ready to be consumed by a container run-time.

So using Fedora’s generated image, it’s even easier to get a base image. Let’s see how that works:

$ curl -O https://kojipkgs.fedoraproject.org/packages/Fedora-Container-Base/Rawhide/20190902.n.0/images/Fedora-Container-Base-Rawhide-20190902.n.0.x86_64.tar.xz $ podman load --input Fedora-Container-Base-Rawhide-20190902.n.0.x86_64.tar.xz $ podman run -it --rm localhost/fedora-container-base-rawhide-20190902.n.0.x86_64:latest cat /etc/os-release Building a layered image

To build a layered image that uses the Fedora base image, you only need to specify fedora in the FROM line instruction:

FROM fedora:latest

The latest tag references the latest active Fedora release (Fedora 30 at the time of writing). But it is possible to get other versions using the image tag. For example, FROM fedora:31 will use the Fedora 31 base image.

Fedora supports building and releasing software as containers. This means you can maintain a Dockerfile to make your software available to others. For more information about becoming a container image maintainer in Fedora, check out the Fedora Containers Guidelines.

How RPM packages are made: the spec file

Monday 2nd of September 2019 08:00:34 AM

In the previous article on RPM package building, you saw that source RPMS include the source code of the software, along with a “spec” file. This post digs into the spec file, which contains instructions on how to build the RPM. Again, this article uses fpaste as an example.

Understanding the source code

Before you can start writing a spec file, you need to have some idea of the software that you’re looking to package. Here, you’re looking at fpaste, a very simple piece of software. It is written in Python, and is a one file script. When a new version is released, it’s provided here on Pagure: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz

The current version, as the archive shows, is 0.3.9.2. Download it so you can see what’s in the archive:

$ wget https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz $ tar -tvf fpaste-0.3.9.2.tar.gz drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/ -rw-rw-r-- root/root 25 2018-07-25 02:58 fpaste-0.3.9.2/.gitignore -rw-rw-r-- root/root 3672 2018-07-25 02:58 fpaste-0.3.9.2/CHANGELOG -rw-rw-r-- root/root 35147 2018-07-25 02:58 fpaste-0.3.9.2/COPYING -rw-rw-r-- root/root 444 2018-07-25 02:58 fpaste-0.3.9.2/Makefile -rw-rw-r-- root/root 1656 2018-07-25 02:58 fpaste-0.3.9.2/README.rst -rw-rw-r-- root/root 658 2018-07-25 02:58 fpaste-0.3.9.2/TODO drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/ drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/ drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/ -rw-rw-r-- root/root 3867 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/fpaste.1 -rwxrwxr-x root/root 24884 2018-07-25 02:58 fpaste-0.3.9.2/fpaste lrwxrwxrwx root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/fpaste.py -> fpaste

The files you want to install are:

  • fpaste.py: which should go be installed to /usr/bin/.
  • docs/man/en/fpaste.1: the manual, which should go to /usr/share/man/man1/.
  • COPYING: the license text, which should go to /usr/share/license/fpaste/.
  • README.rst, TODO: miscellaneous documentation that goes to /usr/share/doc/fpaste.

Where these files are installed depends on the Filesystem Hierarchy Standard. To learn more about it, you can either read here: http://www.pathname.com/fhs/ or look at the man page on your Fedora system:

$ man hier Part 1: What are we building?

Now that we know what files we have in the source, and where they are to go, let’s look at the spec file. You can see the full file here: https://src.fedoraproject.org/rpms/fpaste/blob/master/f/fpaste.spec

Here is the first part of the spec file:

Name: fpaste Version: 0.3.9.2 Release: 3%{?dist} Summary: A simple tool for pasting info onto sticky notes instances BuildArch: noarch License: GPLv3+ URL: https://pagure.io/fpaste Source0: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz Requires: python3 %description It is often useful to be able to easily paste text to the Fedora Pastebin at http://paste.fedoraproject.org and this simple script will do that and return the resulting URL so that people may examine the output. This can hopefully help folks who are for some reason stuck without X, working remotely, or any other reason they may be unable to paste something into the pastebin

Name, Version, and so on are called tags, and are defined in RPM. This means you can’t just make up tags. RPM won’t understand them if you do! The tags to keep an eye out for are:

  • Source0: tells RPM where the source archive for this software is located.
  • Requires: lists run-time dependencies for the software. RPM can automatically detect quite a few of these, but in some cases they must be mentioned manually. A run-time dependency is a capability (often a package) that must be on the system for this package to function. This is how dnf detects whether it needs to pull in other packages when you install this package.
  • BuildRequires: lists the build-time dependencies for this software. These must generally be determined manually and added to the spec file.
  • BuildArch: the computer architectures that this software is being built for. If this tag is left out, the software will be built for all supported architectures. The value noarch means the software is architecture independent (like fpaste, which is written purely in Python).

This section provides general information about fpaste: what it is, which version is being made into an RPM, its license, and so on. If you have fpaste installed, and look at its metadata, you can see this information included in the RPM:

$ sudo dnf install fpaste $ rpm -qi fpaste Name : fpaste Version : 0.3.9.2 Release : 2.fc30 ...

RPM adds a few extra tags automatically that represent things that it knows.

At this point, we have the general information about the software that we’re building an RPM for. Next, we start telling RPM what to do.

Part 2: Preparing for the build

The next part of the spec is the preparation section, denoted by %prep:

%prep %autosetup

For fpaste, the only command here is %autosetup. This simply extracts the tar archive into a new folder and keeps it ready for the next section where we build it. You can do more here, like apply patches, modify files for different purposes, and so on. If you did look at the contents of the source rpm for Python, you would have seen lots of patches there. These are all applied in this section.

Typically anything in a spec file with the % prefix is a macro or label that RPM interprets in a special way. Often these will appear with curly braces, such as %{example}.

Part 3: Building the software

The next section is where the software is built, denoted by “%build”. Now, since fpaste is a simple, pure Python script, it doesn’t need to be built. So, here we get:

%build #nothing required

Generally, though, you’d have build commands here, like:

configure; make

The build section is often the hardest section of the spec, because this is where the software is being built from source. This requires you to know what build system the tool is using, which could be one of many: Autotools, CMake, Meson, Setuptools (for Python) and so on. Each has its own commands and style. You need to know these well enough to get the software to build correctly.

Part 4: Installing the files

Once the software is built, it needs to be installed in the %install section:

%install mkdir -p %{buildroot}%{_bindir} make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}

RPM doesn’t tinker with your system files when building RPMs. It’s far too risky to add, remove, or modify files to a working installation. What if something breaks? So, instead RPM creates an artificial file system and works there. This is referred to as the buildroot. So, here in the buildroot, we create /usr/bin, represented by the macro %{_bindir}, and then install the files to it using the provided Makefile.

At this point, we have a built version of fpaste installed in our artificial buildroot.

Part 5: Listing all files to be included in the RPM

The last section of the spec file is the files section, %files. This is where we tell RPM what files to include in the archive it creates from this spec file. The fpaste file section is quite simple:

%files %{_bindir}/%{name} %doc README.rst TODO %{_mandir}/man1/%{name}.1.gz %license COPYING

Notice how, here, we do not specify the buildroot. All of these paths are relative to it. The %doc and %license commands simply do a little more—they create the required folders and remember that these files must go there.

RPM is quite smart. If you’ve installed files in the %install section, but not listed them, it’ll tell you this, for example.

Part 6: Document all changes in the change log

Fedora is a community based project. Lots of contributors maintain and co-maintain packages. So it is imperative that there’s no confusion about what changes have been made to a package. To ensure this, the spec file contains the last section, the Changelog, %changelog:

%changelog * Thu Jul 25 2019 Fedora Release Engineering < ...> - 0.3.9.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Thu Jan 31 2019 Fedora Release Engineering < ...> - 0.3.9.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Tue Jul 24 2018 Ankur Sinha - 0.3.9.2-1 - Update to 0.3.9.2 * Fri Jul 13 2018 Fedora Release Engineering < ...> - 0.3.9.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Wed Feb 07 2018 Fedora Release Engineering < ..> - 0.3.9.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Sun Sep 10 2017 Vasiliy N. Glazov < ...> - 0.3.9.1-2 - Cleanup spec * Fri Sep 08 2017 Ankur Sinha - 0.3.9.1-1 - Update to latest release - fixes rhbz 1489605 ... ....

There must be a changelog entry for every change to the spec file. As you see here, while I’ve updated the spec as the maintainer, others have too. Having the changes documented clearly helps everyone know what the current status of the spec is. For all packages installed on your system, you can use rpm to see their changelogs:

$ rpm -q --changelog fpaste Building the RPM

Now we are ready to build the RPM. If you want to follow along and run the commands below, please ensure that you followed the steps in the previous post to set your system up for building RPMs.

We place the fpaste spec file in ~/rpmbuild/SPECS, the source code archive in ~/rpmbuild/SOURCES/ and can now create the source RPM:

$ cd ~/rpmbuild/SPECS $ wget https://src.fedoraproject.org/rpms/fpaste/raw/master/f/fpaste.spec $ cd ~/rpmbuild/SOURCES $ wget https://pagure.io/fpaste/archive/0.3.9.2/fpaste-0.3.9.2.tar.gz $ cd ~/rpmbuild/SPECS $ rpmbuild -bs fpaste.spec Wrote: /home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm

Let’s have a look at the results:

$ ls ~/rpmbuild/SRPMS/fpaste* /home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm $ rpm -qpl ~/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm fpaste-0.3.9.2.tar.gz fpaste.spec

There we are — the source rpm has been built. Let’s build both the source and binary rpm together:

$ cd ~/rpmbuild/SPECS $ rpmbuild -ba fpaste.spec .. .. ..

RPM will show you the complete build output, with details on what it is doing in each section that we saw before. This “build log” is extremely important. When builds do not go as expected, we packagers spend lots of time going through them, tracing the complete build path to see what went wrong.

That’s it really! Your ready-to-install RPMs are where they should be:

$ ls ~/rpmbuild/RPMS/noarch/ fpaste-0.3.9.2-3.fc30.noarch.rpm Recap

We’ve covered the basics of how RPMs are built from a spec file. This is by no means an exhaustive document. In fact, it isn’t documentation at all, really. It only tries to explain how things work under the hood. Here’s a short recap:

  • RPMs are of two types: source and binary.
  • Binary RPMs contain the files to be installed to use the software.
  • Source RPMs contain the information needed to build the binary RPMs: the complete source code, and the instructions on how to build the RPM in the spec file.
  • The spec file has various sections, each with its own purpose.

Here, we’ve built RPMs locally, on our Fedora installations. While this is the basic process, the RPMs we get from repositories are built on dedicated servers with strict configurations and methods to ensure correctness and security. This Fedora packaging pipeline will be discussed in a future post.

Would you like to get started with building packages, and help the Fedora community maintain the massive amount of software we provide? You can start here by joining the package collection maintainers.

For any queries, post to the Fedora developers mailing list—we’re always happy to help!

References

Here are some useful references to building RPMs:

More in Tux Machines

MX-19 Release Candidate 1 now available

We are pleased to offer MX-19 RC 1 for testing purposes. As usual, this iso includes the latest updates from debian 10.1 (buster), antiX and MX repos. Read more

The Linux Mint 19.2 Gaming Report: Promising But Room For Improvement

When I started outlining the original Linux Gaming Report, I was still a fresh-faced Linux noob. I didn’t understand how fast the ecosystem advanced (particularly graphics drivers and Steam Proton development), and I set some lofty goals that I couldn’t accomplish given my schedule. Before I even got around to testing Ubuntu 18.10, for example, Ubuntu 19.04 was just around the corner! And since all the evaluation and benchmarking takes a considerable amount of time, I ended up well behind the curve. So I’ve streamlined the process a bit, while adding additional checkpoints such as out-of-the-box software availability and ease-of-installation for important gaming apps like Lutris and GameHub. Read more

Something exciting is coming with Ubuntu 19.10

ZFS is a combined file system and logical volume manager that is scalable, supplying support for high storage capacity and a more efficient data compression, and includes snapshots and rollbacks, copy-on-write clones, continuous integrity checking, automatic repair, and much more. So yeah, ZFS is a big deal, which includes some really great features. But out of those supported features, it's the snapshots and rollbacks that should have every Ubuntu user/admin overcome with a case of the feels. Why? Imagine something has gone wrong. You've lost data or an installation of a piece of software has messed up the system. What do you do? If you have ZFS and you've created a snapshot, you can roll that system back to the snapshot where everything was working fine. Although the concept isn't new to the world of computing, it's certainly not something Ubuntu has had by default. So this is big news. Read more

Pack Your Bags – Systemd Is Taking You To A New Home

Home directories have been a fundamental part on any Unixy system since day one. They’re such a basic element, we usually don’t give them much thought. And why would we? From a low level point of view, whatever location $HOME is pointing to, is a directory just like any other of the countless ones you will find on the system — apart from maybe being located on its own disk partition. Home directories are so unspectacular in their nature, it wouldn’t usually cross anyone’s mind to even consider to change anything about them. And then there’s Lennart Poettering. In case you’re not familiar with the name, he is the main developer behind the systemd init system, which has nowadays been adopted by the majority of Linux distributions as replacement for its oldschool, Unix-style init-system predecessors, essentially changing everything we knew about the system boot process. Not only did this change personally insult every single Perl-loving, Ken-Thompson-action-figure-owning grey beard, it engendered contempt towards systemd and Lennart himself that approaches Nickelback level. At this point, it probably doesn’t matter anymore what he does next, haters gonna hate. So who better than him to disrupt everything we know about home directories? Where you _live_? Although, home directories are just one part of the equation that his latest creation — the systemd-homed project — is going to make people hate him even more tackle. The big picture is really more about the whole concept of user management as we know it, which sounds bold and scary, but which in its current state is also a lot more flawed than we might realize. So let’s have a look at what it’s all about, the motivation behind homed, the problems it’s going to both solve and raise, and how it’s maybe time to leave some outdated philosophies behind us. Read more