Tag: Fedora Project community

The Fedora CoreOS team is pleased to announce that Fedora CoreOS is now available for general use. Here are some more details about this exciting delivery.

Fedora CoreOS is a new Fedora Edition built specifically for running containerized workloads securely and at scale. It’s the successor to both Fedora Atomic Host and CoreOS Container Linux and is part of our effort to explore new ways of assembling and updating an OS. Fedora CoreOS combines the provisioning tools and automatic update model of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host.  For more on the Fedora CoreOS philosophy, goals, and design, see the announcement of the preview release.

Some highlights of the current Fedora CoreOS release:

• Automatic updates, with staged deployments and phased rollouts
• Built from Fedora 31, featuring:
  • Linux 5.4
  • systemd 243
  • Ignition 2.1
• OCI and Docker Container support via Podman 1.7 and Moby 18.09
• cgroups v1 enabled by default for broader compatibility; cgroups v2 available via configuration

Fedora CoreOS is available on a variety of platforms:

• Bare metal, QEMU, OpenStack, and VMware
• Images available in all public AWS regions
• Downloadable cloud images for Alibaba, AWS, Azure, and GCP
• Can run live from RAM via ISO and PXE (netboot) images

Fedora CoreOS is under active development.  Planned future enhancements include:

• Addition of the next release stream for extended testing of upcoming Fedora releases.
• Support for additional cloud and virtualization platforms, and processor architectures other than x86_64.
• Closer integration with Kubernetes distributions, including OKD.
• Aggregate statistics collection.
• Additional documentation.

Where do I get it?

To try out the new release, head over to the download page to get OS images or cloud image IDs.  Then use the quick start guide to get a machine running quickly.

How do I get involved?

It’s easy!  You can report bugs and missing features to the issue tracker. You can also discuss Fedora CoreOS in Fedora Discourse, the development mailing list, in #fedora-coreos on Freenode, or at our weekly IRC meetings.

Are there stability guarantees?

In general, the Fedora Project does not make any guarantees around stability.  While Fedora CoreOS strives for a high level of stability, this can be challenging to achieve in the rapidly evolving Linux and container ecosystems.  We’ve found that the incremental, exploratory, forward-looking development required for Fedora CoreOS — which is also a cornerstone of the Fedora Project as a whole — is difficult to reconcile with the iron-clad stability guarantee that ideally exists when automatically updating systems.

We’ll continue to do our best not to break existing systems over time, and to give users the tools to manage the impact of any regressions.  Nevertheless, automatic updates may produce regressions or breaking changes for some use cases. You should make your own decisions about where and how to run Fedora CoreOS based on your risk tolerance, operational needs, and experience with the OS.  We will continue to announce any major planned or unplanned breakage to the coreos-status mailing list, along with recommended mitigations.

How do I migrate from CoreOS Container Linux?

Container Linux machines cannot be migrated in place to Fedora CoreOS.  We recommend writing a new Fedora CoreOS Config to provision Fedora CoreOS machines.  Fedora CoreOS Configs are similar to Container Linux Configs, and must be passed through the Fedora CoreOS Config Transpiler to produce an Ignition config for provisioning a Fedora CoreOS machine.

Whether you’re currently provisioning your Container Linux machines using a Container Linux Config, handwritten Ignition config, or cloud-config, you’ll need to adjust your configs for differences between Container Linux and Fedora CoreOS.  For example, on Fedora CoreOS network configuration is performed with NetworkManager key files instead of systemd-networkd, and time synchronization is performed by chrony rather than systemd-timesyncd.  Initial migration documentation will be available soon and a skeleton list of differences between the two OSes is available in this issue.

CoreOS Container Linux will be maintained for a few more months, and then will be declared end-of-life.  We’ll announce the exact end-of-life date later this month.

How do I migrate from Fedora Atomic Host?

Fedora Atomic Host has already reached end-of-life, and you should migrate to Fedora CoreOS as soon as possible.  We do not recommend in-place migration of Atomic Host machines to Fedora CoreOS. Instead, we recommend writing a Fedora CoreOS Config and using it to provision new Fedora CoreOS machines.  As with CoreOS Container Linux, you’ll need to adjust your existing cloud-configs for differences between Fedora Atomic Host and Fedora CoreOS.

Welcome to Fedora CoreOS.  Deploy it, launch your apps, and let us know what you think!

The Domain Name System, or DNS, as it’s more commonly known, translates or converts domain names into the IP addresses associated with that domain. DNS is the reason you are able to find your favorite website by name instead of typing an IP address into your browser. This guide shows you how to configure a Master DNS system and one client.

Here are system details for the example used in this article:

dns01.fedora.local (192.168.1.160 ) - Master DNS server
client.fedora.local (192.168.1.136 ) - Client 

DNS server configuration

Install the bind packages using sudo:

$ sudo dnf install bind bind-utils -y

The /etc/named.conf configuration file is provided by the bind package to allow you to configure the DNS server.

Edit the /etc/named.conf file:

sudo vi /etc/named.conf

Look for the following line:

listen-on port 53 { 127.0.0.1; };

Add the IP address of your Master DNS server as follows:

listen-on port 53 { 127.0.0.1; 192.168.1.160; };

Look for the next line:

allow-query  { localhost; };

Add your local network range. The example system uses IP addresses in the 192.168.1.X range. This is specified as follows:

allow-query  { localhost; 192.168.1.0/24; };

Specify a forward and reverse zone. Zone files are simply text files that have the DNS information, such as IP addresses and host-names, on your system. The forward zone file makes it possible for the translation of a host-name to its IP address. The reverse zone file does the opposite. It allows a remote system to translate an IP address to the host name.

Look for the following line at the bottom of the /etc/named.conf file:

include "/etc/named.rfc1912.zones";

Here, you’ll specify the zone file information directly above that line as follows:

zone "dns01.fedora.local" IN {
type master;
file "forward.fedora.local";
allow-update { none; };
}; zone "1.168.192.in-addr.arpa" IN {
type master;
file "reverse.fedora.local";
allow-update { none; };
};

The forward.fedora.local and the file reverse.fedora.local are just the names of the zone files you will be creating. They can be called anything you like.

Save and exit.

Create the zone files

Create the forward and reverse zone files you specified in the /etc/named.conf file:

$ sudo vi /var/named/forward.fedora.local

Add the following lines:

$TTL 86400
@   IN  SOA     dns01.fedora.local. root.fedora.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          dns01.fedora.local.
@       IN  A           192.168.1.160
dns01        IN  A   192.168.1.160
client          IN  A   192.168.1.136

Everything in bold is specific to your environment. Save the file and exit. Next, edit the reverse.fedora.local file:

$ sudo vi /var/named/reverse.fedora.local

Add the following lines:

$TTL 86400
@   IN  SOA     dns01.fedora.local. root.fedora.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          dns01.fedora.local.
@       IN  PTR         fedora.local.
dns01       IN  A   192.168.1.160
client          IN  A   192.168.1.136
160     IN  PTR         dns01.fedora.local.
136     IN  PTR         client.fedora.local.

Everything in bold is also specific to your environment. Save the file and exit.

You’ll also need to configure SELinux and add the correct ownership for the configuration files.

sudo chgrp named -R /var/named
sudo chown -v root:named /etc/named.conf
sudo restorecon -rv /var/named
sudo restorecon /etc/named.conf

Configure the firewall:

sudo firewall-cmd --add-service=dns --perm
sudo firewall-cmd --reload

Check the configuration for any syntax errors

sudo named-checkconf /etc/named.conf

Your configuration is valid if no output or errors are returned.

Check the forward and reverse zone files.

$ sudo named-checkzone forward.fedora.local /var/named/forward.fedora.local $ sudo named-checkzone reverse.fedora.local /var/named/reverse.fedora.local

You should see a response of OK:

zone forward.fedora.local/IN: loaded serial 2011071001
OK zone reverse.fedora.local/IN: loaded serial 2011071001
OK

Enable and start the DNS service

$ sudo systemctl enable named
$ sudo systemctl start named

Configuring the resolv.conf file

Edit the /etc/resolv.conf file:

$ sudo vi /etc/resolv.conf

Look for your current name server line or lines. On the example system, a cable modem/router is serving as the name server and so it currently looks like this:

nameserver 192.168.1.1

This needs to be changed to the IP address of the Master DNS server:

nameserver 192.168.1.160

Save your changes and exit.

Unfortunately there is one caveat to be aware of. NetworkManager overwrites the /etc/resolv.conf file if the system is rebooted or networking gets restarted. This means you will lose all of the changes that you made.

To prevent this from happening, make /etc/resolv.conf immutable:

$ sudo chattr +i /etc/resolv.conf 

If you want to set it back and allow it to be overwritten again:

$ sudo chattr -i /etc/resolv.conf

Testing the DNS server

$ dig fedoramagazine.org

; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc30 <<>> fedoramagazine.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8391
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c7350d07f8efaa1286c670ab5e13482d600f82274871195a (good) ;; QUESTION SECTION: ;fedoramagazine.org. IN A ;; ANSWER SECTION: fedoramagazine.org. 50 IN A 35.197.52.145 ;; AUTHORITY SECTION: fedoramagazine.org. 86150 IN NS ns05.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns02.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns04.fedoraproject.org. ;; ADDITIONAL SECTION: ns02.fedoraproject.org. 86150 IN A 152.19.134.139 ns04.fedoraproject.org. 86150 IN A 209.132.181.17 ns05.fedoraproject.org. 86150 IN A 85.236.55.10 ns02.fedoraproject.org. 86150 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 ns05.fedoraproject.org. 86150 IN AAAA 2001:4178:2:1269:dead:beef:cafe:fed5 ;; Query time: 830 msec ;; SERVER: 192.168.1.160#53(192.168.1.160) ;; WHEN: Mon Jan 06 08:46:05 CST 2020 ;; MSG SIZE rcvd: 266

There are a few things to look at to verify that the DNS server is working correctly. Obviously getting the results back are important, but that by itself doesn’t mean the DNS server is actually doing the work.

The QUERY, ANSWER, and AUTHORITY fields at the top should show non-zero as it in does in our example:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6

And the SERVER field should have the IP address of your DNS server:

;; SERVER: 192.168.1.160#53(192.168.1.160)

In case this is the first time you’ve run the dig command, notice how it took 830 milliseconds for the query to complete:

;; Query time: 830 msec

If you run it again, the query will run much quicker:

$ dig fedoramagazine.org 

;; Query time: 0 msec
;; SERVER: 192.168.1.160#53(192.168.1.160)

Client configuration

The client configuration will be a lot simpler.

Install the bind utilities:

$ sudo dnf install bind-utils -y

Edit the /etc/resolv.conf file and configure the Master DNS as the only name server:

$ sudo vi /etc/resolv.conf

This is how it should look:

nameserver 192.168.1.160

Save your changes and exit. Then, make the /etc/resolv.conf file immutable to prevent it from be overwritten and going back to its default settings:

$ sudo chattr +i /etc/resolv.conf

Testing the client

You should get the same results as you did from the DNS server:

$ dig fedoramagazine.org

; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc30 <<>> fedoramagazine.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8391
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: c7350d07f8efaa1286c670ab5e13482d600f82274871195a (good) ;; QUESTION SECTION: ;fedoramagazine.org. IN A ;; ANSWER SECTION: fedoramagazine.org. 50 IN A 35.197.52.145 ;; AUTHORITY SECTION: fedoramagazine.org. 86150 IN NS ns05.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns02.fedoraproject.org. fedoramagazine.org. 86150 IN NS ns04.fedoraproject.org. ;; ADDITIONAL SECTION: ns02.fedoraproject.org. 86150 IN A 152.19.134.139 ns04.fedoraproject.org. 86150 IN A 209.132.181.17 ns05.fedoraproject.org. 86150 IN A 85.236.55.10 ns02.fedoraproject.org. 86150 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed5 ns05.fedoraproject.org. 86150 IN AAAA 2001:4178:2:1269:dead:beef:cafe:fed5 ;; Query time: 1 msec ;; SERVER: 192.168.1.160#53(192.168.1.160) ;; WHEN: Mon Jan 06 08:46:05 CST 2020 ;; MSG SIZE rcvd: 266

Make sure the SERVER output has the IP Address of your DNS server.

Your DNS server is now ready to use and all requests from the client should be going through your DNS server now!

Sway is a tiling Wayland compositor which has mostly the same features, look and workflow as the i3 X11 window manager. Because Sway uses Wayland instead of X11, the tools to setup X11 don’t always work in sway. This includes tools like xrandr, which are used in X11 window managers or desktops to setup monitors. This is why monitors have to be setup by editing the sway config file, and that’s what this article is about.

Getting your monitor ID’s

First, you have to get the names sway uses to refer to your monitors. You can do this by running:

$ swaymsg -t get_outputs

You will get information about all of your monitors, every monitor separated by an empty line.

You have to look for the first line of every section, and for what’s after “Output”. For example, when you see a line like “Output DVI-D-1 ‘Philips Consumer Electronics Company’”, the output ID is “DVI-D-1”. Note these ID’s and which physical monitors they belong to.

Editing the config file

If you haven’t edited the Sway config file before, you have to copy it to your home directory by running this command:

cp -r /etc/sway/config ~/.config/sway/config

Now the default config file is located in ~/.config/sway and called “config”. You can edit it using any text editor.

Now you have to do a little bit of math. Imagine a grid with the origin in the top left corner. The units of the X and Y coordinates are pixels. The Y axis is inverted. This means that if you, for example, start at the origin and you move 100 pixels to the right and 80 pixels down, your coordinates will be (100, 80).

You have to calculate where your displays are going to end up on this grid. The locations of the displays are specified with the top left pixel. For example, if we want to have a monitor with name HDMI1 and a resolution of 1920×1080, and to the right of it a laptop monitor with name eDP1 and a resolution of 1600×900, you have to type this in your config file:

output HDMI1 pos 0 0
output eDP1 pos 1920 0

You can also specify the resolutions manually by using the res option: 

output HDMI1 pos 0 0 res 1920x1080
output eDP1 pos 1920 0 res 1600x900

Binding workspaces to monitors

Using sway with multiple monitors can be a little bit tricky with workspace management. Luckily, you can bind workspaces to a specific monitor, so you can easily switch to that monitor and use your displays more efficiently. This can simply be done by the workspace command in your config file. For example, if you want to bind workspace 1 and 2 to monitor DVI-D-1 and workspace 8 and 9 to monitor HDMI-A-1, you can do that by using:

workspace 1 output DVI-D-1
workspace 2 output DVI-D-1

workspace 8 output HDMI-A-1
workspace 9 output HDMI-A-1

That’s it! These are the basics of multi monitor setup in sway. A more detailed guide can be found at https://github.com/swaywm/sway/wiki#Multihead. 

Some topics are very popular, no matter when they’re first mentioned. And Fedora Magazine has a few articles that have proven to be popular for a long time.

You’re reading the last article from the “best of 2019” series. But this time, it’s about articles written before 2019, but being very popular in 2019.

All of the articles below have been checked and updated to be correct even now, in early 2020. Let’s dive in!

i3 tiling window manager

Wish to try an alternative desktop? The following article introduces i3 — a tiling window manager that doesn’t require high-end hardware, but is powerful and highly customizable. You’ll learn about the installation process, some initial setup, and a few tricks to get you started.

Getting started with the i3 tiling window manager

Powerline

Would you like to have your shell a bit more organized? Then you might want to try Powerline — a utility that gives you status information, and some visual tweaks to your shell to make it more pleasant and organized.

Add power to your terminal with powerline

Monospace fonts

Do you spend a lot of your time in terminal or a code editor? And is your font making you happy? Discover some beautiful monospace fonts available in the Fedora repositories.

6 great monospaced fonts for code and terminal in Fedora

Image viewers

Is the default image viewer on your desktop not working the way you want? The following article shows 17 image viewers available in Fedora — varying from simpler to ones full of features.

17 alternatives to your default image viewer on Fedora

Fedora as a VirtualBox guest

Love Fedora but your machine runs Windows or macOS? One option to get Fedora running on your machine is virtualization. Your system keeps running and you’ll be able to access Fedora at the same time in a virtual machine. The following article introduces VirtualBox that can do just that.

How to install Fedora as a VirtualBox guest