Tag: Fedora Project community

The Python developers have already released five alpha versions of Python 3.9.0 and you can already try the latest one in Fedora! Test your Python code with 3.9 early to avoid surprises once the final 3.9.0 is out in October.

Install Python 3.9 on Fedora

If you run Fedora, you can install Python 3.9 from the official software repository with dnf:

$ sudo dnf install python3.9

In order to get the very latest pre-release, you might need to enable the updates-testing repository:

$ sudo dnf install --enablerepo=updates-testing python3.9

As more alphas, betas and release candidates of Python 3.9 will be released, the Fedora package will receive updates. No need to compile your own development version of Python, just install it and have it up to date. New features will be added until the first beta planned for mid May.

Test your projects with Python 3.9

Run the python3.9 command to use Python 3.9 or create virtual environments with the builtin venv module, tox or with pipenv and poetry. For example:

$ git clone https://github.com/benjaminp/six.git
Cloning into 'six'...
$ cd six/
$ tox -e py39
py39 run-test: commands[0] | python -m pytest -rfsxX
================== test session starts ===================
platform linux -- Python 3.9.0a5, pytest-5.4.1, py-1.8.1, pluggy-0.13.1
collected 200 items test_six.py ...................................... [ 19%]
.................................................. [ 44%]
.................................................. [ 69%]
.................................................. [ 94%]
............ [100%] ================== 200 passed in 0.43s ===================
________________________ summary _________________________ py39: commands succeeded congratulations :)

What’s new in Python 3.9

So far, the first five alphas were released, more features will come until the first beta. You can however already try out the new dictionary merge & update operators:

$ python3.9
Python 3.9.0a5 (default, Mar 24 2020, 00:00:00) [GCC 10.0.1 20200311 (Red Hat 10.0.1-0.9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {'spam': 1, 'eggs': 2, 'cheese': 3}
>>> e = {'cheese': 'cheddar', 'aardvark': 'Ethel'}
>>> d | e
{'spam': 1, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}
>>> e | d
{'cheese': 3, 'aardvark': 'Ethel', 'spam': 1, 'eggs': 2}
>>> d |= e
>>> d
{'spam': 1, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}

And stay tuned for Python 3.9 as python3 in Fedora 33!

In Linux, dotfiles are hidden text files that are used to store various configuration settings for many such as Bash and Git to more complex applications like i3 or VSCode.

Most of these files are contained in the ~/.config directory or right in the home directory. Editing these files allows you to customize applications beyond what a settings menu may provide, and they tend to be portable across devices and even other Linux distributions. But one talking point across the Linux enthusiast community is how to manage these dotfiles and how to share them.

We will be showcasing a tool called Chezmoi that does this task a little differently from the others.

The history of dotfile management

If you search GitHub for dotfiles, what you will see are over 100k repositories after one goal: Store people’s dotfiles in a shareable and repeatable manor. However, other than using git, they store their files differently.

While Git has solved code management problems that also translates to config file management, It does not solve how to separate between distributions, roles (such as home vs work computers) secrets management, and per device configuration.

Because of this, many users decide to craft their own solutions, and the community has responded with multiple answers over the years. This article will briefly cover some of the solutions that have been created.

Experiment in an isolated environment

Do you want to try these below solutions quickly in a contained environment? Run:

$ podman run --rm -it fedora

… to create a Fedora container to try the applications in. This container will automatically delete itself when you exit the shell.

The install problem

If you store your dotfiles in Git repository, you will want to make it easy for your changes to automatically be applied inside your home directory, the easiest way to do this at first glance is to use a symlink, such as ln -s ~/.dotfies/bashrc ~/.bashrc. This will allow your changes to take place instantly when your repository is updated.

The problem with symlinks is that managing symlinks can be a chore. Stow and RCM (covered here on Fedora Magazine) can help you manage those, but these are not seamless solutions. Files that are private will need to be modified and chmoded properly after download. If you revamp your dotfiles on one system, and download your repository to another system, you may get conflicts and require troubleshooting.

Another solution to this problem is writing your own install script. This is the most flexible option, but has the tradeoff of requiring more time into building a custom solution.

The secrets problem

Git is designed to track changes. If you store a secret such as a password or an API key in your git repository, you will have a difficult time and will need to rewrite your git history to remove that secret. If your repository is public, your secret would be impossible to recover if someone else has downloaded your repository. This problem alone will prevent many individuals from sharing their dotfiles with the public world.

The multi-device config problem

The problem is not pulling your config to multiple devices, the problem is when you have multiple devices that require different configuration. Most individuals handle this by either having different folders or by using different forks. This makes it difficult to share configs across the different devices and role sets

How Chezmoi works

Chezmoi is a tool to manage your dotfiles with the above problems in mind, it doesn’t blindly copy or symlink files from your repository. Chezmoi acts more like a template engine to generate your dotfiles based on system variables, templates, secret managers, and Chezmoi’s own config file.

Getting Started with Chezmoi

Currently Chezmoi is not in the default repositories. You can download the current version of Chezmoi as of writing with the following command.

$ sudo dnf install https://github.com/twpayne/chezmoi/releases/download/v1.7.17/chezmoi-1.7.17-x86_64.rpm

This will install the pre-packaged RPM to your system.

Lets go ahead and create your repository using:

$ chezmoi init

It will create your new repository in ~/.local/share/chezmoi/. You can easily cd to this directory by using:

$ chezmoi cd

Lets add our first file:

chezmoi add ~/.bashrc 

… to add your bashrc file to your chezmoi repository.

Note: if your bashrc file is actually a symlink, you will need to add the -f flag to follow it and read the contents of the real file.

You can now edit this file using:

$ chezmoi edit ~/.bashrc

Now lets add a private file, This is a file that has the permissions 600 or similar. I have a file at .ssh/config that I would like to add by using

$ chezmoi add ~/.ssh/config

Chezmoi uses special prefixes to keep track of what is a hidden file and a private file to work around Git’s limitations. Run the following command to see it:

$ chezmoi cd

Do note that files that are marked as private are not actually private, they are still saved as plain text in your git repo. More on that later.

You can apply any changes by using:

$ chezmoi apply

and inspect what is different by using

$ chezmoi diff

Using variables and templates

To export all of your data Chezmoi can gather, run:

$ chezmoi data

Most of these are information about your username, arch, hostname, os type and os name. But you can also add our own variables.

Go ahead and run:

$ chezmoi edit-config

… and input the following:

[data] email = "fedorauser@example.com" name = "Fedora Mcdora"

Save your file and run chezmoi data again. You will see on the bottom that your email and name are now added. You can now use these with templates with Chezmoi. Run:

$ chezmoi add -T --autotemplate ~/.gitconfig

… to add your gitconfig as a template into Chezmoi. If Chezmoi is successful in inferring template correctly, you could get the following:

[user] email = "{{ .email }}" name = "{{ .name }}"

If it does not, you can change the file to this instead.

Inspect your file with:

$ chezmoi edit ~/.gitconfig

After using

$ chezmoi cat ~/.gitconfig

… to see what chezmoi will generate for this file. My generated example is below:

[root@a6e273a8d010 ~]# chezmoi cat ~/.gitconfig [user] email = "fedorauser@example.com" name = "Fedora Mcdora" [root@a6e273a8d010 ~]# 

It will generate a file filled with the variables in our chezmoi config.
You can also use the varibles to perform simple logic statements. One example is:

{{- if eq .chezmoi.hostname "fsteel" }}
# this will only be included if the host name is equal to "fsteel"
{{- end }}

Do note that for this to work the file has to be a template. You can check this by seeing if the file has a “.tmpl” appended to its name on the file in chezmoi cd, or by readding the file using the -T option

Keeping secrets… secret

To troubleshoot your setup, use the following command.

$ chezmoi doctor 

What is important here is that it also shows you the password managers it supports.

[root@a6e273a8d010 ~]# chezmoi doctor warning: version dev ok: runtime.GOOS linux, runtime.GOARCH amd64 ok: /root/.local/share/chezmoi (source directory, perm 700) ok: /root (destination directory, perm 550) ok: /root/.config/chezmoi/chezmoi.toml (configuration file) ok: /bin/bash (shell) ok: /usr/bin/vi (editor) warning: vimdiff (merge command, not found) ok: /usr/bin/git (source VCS command, version 2.25.1)
 ok: /usr/bin/gpg (GnuPG, version 2.2.18) warning: op (1Password CLI, not found) warning: bw (Bitwarden CLI, not found) warning: gopass (gopass CLI, not found) warning: keepassxc-cli (KeePassXC CLI, not found) warning: lpass (LastPass CLI, not found) warning: pass (pass CLI, not found) warning: vault (Vault CLI, not found) [root@a6e273a8d010 ~]# 

You can use either of these clients, or a generic client, or your system’s Keyring.

For GPG, you will need to add the following to your config using:

$ chezmoi edit-config

[gpg] recipient = "<Your GPG keys Recipient"

You can use:

$ chezmoi add --encrypt

… to add any files, these will be encrypted in your source respository and not exposed to the public world as plain text. Chezmoi will automatically decrypt them when applying.

We can also use them in templates. For example, a secret token stored in Pass (covered on Fedora Magazine). Go ahead and generate your secret.

In this example, it’s called “githubtoken”:

rwaltr@fsteel:~] $ pass ls Password Store └── githubtoken [rwaltr@fsteel:~] $ 

Next, edit your template, such as your .gitconfig we created earlier and add this lines.

token = {{ pass "githubtoken" }}

Then lets inspect using:

$ chezmoi cat ~/.gitconfig

[rwaltr@fsteel:~] $ chezmoi cat ~/.gitconfig This is Git's per-user configuration file. [user] name = Ryan Walter email = rwalt@pm.me token = mysecrettoken [rwaltr@fsteel:~] $ 

Now your secrets are properly secured in your password manager, your config can be publicly shared without risk!

Final notes

This is only scratching the surface. Please check out Chezmoi’s website for more information. The author also has his dotfiles public if you are looking for more examples on how to use Chezmoi.

Cockpit is a very useful utility allowing you to manage a compatible system over the network from the comfort of a web browser (See the list of supported web browsers and Linux distributions). One such feature is the ability to manage storage configuration. Cockpit contains a frontend for udisks2 – it allows you to create new partitions or format, resize, mount, unmount or delete existing partitions without the need to do it manually from a terminal.

Note: please exercise caution when managing your system disk and it’s partitions – incorrectly handling them may leave your system in unbootable state or incur data loss.

Installing Cockpit

If you don’t have Cockpit installed yet you can do so by issuing:

Note: Depending on your install profile, Cockpit might already be installed and you can skip the installation step! Also, some users may need to install cockpit-storaged package along with it’s dependencies if it has not been installed:

Add the service to the firewall:

Afterwards enable and start the service:

And after this everything should be ready and cockpit should be accessible by entering the computers IP address or network domain name in the browser followed by the port 9090. For example: https://cockpit-example.localdomain:9090

Note: you will need to authenticate as privileged user to be able to modify your storage configuration, so tick the “Reuse my password for privileged tasks” checkbox on the Cockpit login page.

Basic provisioning of the storage device

Visiting the “Storage” section will display various statistics and information about the state of the system storage. You can find information about the partitions, their respective mountpoints, realtime disk read/write stats and storage related log information. Also, you can format and partition any newly attached internal/external storage device or attach an NFS mount.

To format and partition a blank storage device, select the device under “Devices” section by clicking on it. This will bring you to the screen of the selected storage device. Here you’ll be able to create a new partition table or format and create new partitions. if the device is empty Cockpit will describe the content of the storage device as unknown.

Click on “Create New Partition Table” to prepare the device.
After the partition table has been created, create one or more partitions by clicking “Create Partition” – here you’ll be able to specify the size, name, mountpoint and mount options.

When partitioning the storage device you have the choice between “Don’t owerwrite exiting data” and “Overwrite existing data with zeroes” – this will take slightly longer but is useful if you want to confidently erase the content of the storage device. Please note that this may not be enough for a substitute if your organisation has regulations in place how securely storage data must be erased. If needed, you can also specify custom mount options if defaults don’t suit your needs.

To simply create a single partition taking up all the storage space on the device just specify the name, for example, use “test” then specify it’s mountpoint, such as “/mnt/test” and click “Ok”. If you don’t want it to be immediately mounted uncheck the “Mount Now” checkbox. Specifying the name is optional, but will help you to identify the partition when inspecting the mountpoints. This will create a new XFS (the default recommended filesystem format) formatted partition “test” and mount it to “/mnt/test”.

Here’s an example how that would look like :

$ df -h
Filesystem Size Used Avail Use% Mounted on /dev/mapper/fedora-root 15G 2.3G 13G 16% / /dev/vda2 1014M 185M 830M 19% /boot /dev/vda1 599M 8.3M 591M 2% /boot/efi /dev/vdb1 20G 175M 20G 1% /mnt/test

It will also add the necessary entry to your /etc/fstab so that the partition gets mounted at boot.

Logical Volume Management

Cockpit also offers users to easily create and manage LVM and RAID storage devices. To create new Logical Volume Group, click on the burger menu button in the devices section and select the “Create Volume Group”. Select the available storage device (only devices with unmounted or no partitions will show up) to finish the process and afterwards return to the storage section and select the newly created volume group. From here on you’ll be able to create individual logical volumes by clicking “Create new Logical Volume”. Similarly to individual partitions, you can specify the size of the logical volume during creation if you don’t want to use all the available space of the volume group. After creating the logical volumes you’ll still need to format them and specify mountpoints. This can be done just like creating individual partitions was described earlier only instead of specifying individual disk devices you’re selecting logical volumes.

Here’s how a Logical Volume Group named “vgroup” with two Logical Volumes (lvol0 and lvol1) named “test” mounted on /mnt/test and named “data” mounted on /mnt/data would look like:

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/fedora-root 15G 2.3G 13G 16% / /dev/vda2 1014M 185M 830M 19% /boot /dev/vda1 599M 8.3M 591M 2% /boot/efi /dev/mapper/vgroup0-lvol0 10G 104M 9.9G 2% /mnt/test /dev/mapper/vgroup0-lvol1 10G 104M 9.9G 2% /mnt/data

Just like before – all the necessary information has been added to the configuration and should persist between system reboots.

Other storage related Cockpit features

Apart from the described features above Cockpit also allows you to mount iscsi disks and nfs mounts located on the network. However, these resources are usually hosted on a dedicated server and require additional configuration going beyond this article. At this time Cockpit itself doesn’t offer the ability for users to configure and serve iscsi and nfs mounts but this may subject to change as Cockpit is an open source project under active development.

[This message comes directly from the desk of Matthew Miller, the Fedora Project Leader.  — Ed.] 

Congratulations to the Fedora community for the upcoming on-time release of Fedora 32 Beta. While we’ve gotten better at hitting our schedule over the years, it’s always nice to celebrate  a little bit each time we do. But that may not be what’s on your mind this week. Like you, I’ve been thinking a lot about the global COVID-19 pandemic. During the Beta period, many of us were unaffected by this outbreak, but as the effects intensify around the world, the month between now and the final release will be different.

“Friends” is the first of our Four Foundations for a reason: Fedora is a community. The most important Fedora concerns right now are your health and safety. Many of you are asked to work from home, to practice social distancing, or even to remain under quarantine. For some of you, this will mean more time to contribute to your favorite open source projects. For others, you have additional stress as partners, kids, and others in your life require additional care. For all of us, the uncertainty weighs on our minds.

I want to make one thing very clear: do not feel bad if you cannot contribute to the level you want to. We always appreciate what you do for the Fedora community, but your health — both physical and mental — is more important than shipping a release. As of right now, we’re planning to continue on schedule, but we understand that the situation is changing rapidly. We’re working on contingency plans and the option of delaying the Fedora 32 release remains on the table.

As you may already know, the Fedora Council has decided to refrain from sponsoring events through the end of the May. We will continue to re-evaluate this as the global situation changes. Please follow the directions of your local public health authorities and keep yourself safe.