We're updating Copr servers from Fedora 33 to Fedora 35. The copr-backend storage (Copr build results) will stay mostly online during this outage but some downtime is expected.
This outage impacts the copr-frontend and the copr-backend.
admin)
on November 30, 2021 12:00 PM
We're updating Copr servers from Fedora 33 to Fedora 35. The copr-backend storage (Copr build results) will stay mostly online during this outage but some downtime is expected.
This outage impacts the copr-frontend and the copr-backend.
jlayton)
on November 29, 2021 09:04 PM
I do a lot of testing with the kernel cephfs client these days, and have had a number of people ask about how I test it. For now, I’ll gloss over the cluster setup since there are other tutorials for that.
For the cluster, I have a separate machine dedicated to running a set of 3 KVMs (8G each, running centos-stream8). I use cephadm to build a cluster that uses those machines as cluster hosts. Each KVM has a dedicated SSD so I get OK-ish performance (but not stellar).
Occasionally, I’ll also need to test against a vstart cluster, usually when I need work with some bleeding-edge userland changes, but for the most part I rely on my 3 node KVM setup.
The machines are connected via 1GB ethernet.
The cephadm cluster has 3 KVM hosts that act as cluster nodes. I run a mon on each, and each gets an OSD daemon.
From there I usually create two separate cephfs’s. One named “test” and one named “scratch”. I then bump up the MDS count in the orchestrator and max_mds on each filesystem to give each fs a set of 3 active MDSs, and one standby MDS.
I also enable random pinning on both fs’s with a 0.1% frequency, just to thrash things a bit more.
I run a KVM on my main workstation that acts as a client (with 16G of memory). The client VM is Fedora 34 (but I’ll probably upgrade it soon). Make sure the ceph-common package is installed (so you have the mount.ceph binary).
Next, you’ll need to set up the configuration. Here’s the script I use:
#!/bin/bash
# final locations
CONF=/etc/ceph/ceph.conf
KEYRING=/etc/ceph/ceph.keyring
CEPHADM=./cephadm
CONFTMP=`mktemp`
ssh $1 "sudo $CEPHADM shell ceph config generate-minimal-conf" > $CONFTMP
sudo chown root:ceph $CONFTMP
sudo chmod 0644 $CONFTMP
sudo cp -p $CONFTMP $CONF
KEYTMP=`mktemp`
ssh $1 "sudo $CEPHADM shell ceph auth get-or-create client.admin" > $KEYTMP
sudo chown root:ceph $KEYTMP
sudo chmod 0640 $KEYTMP
sudo cp -p $KEYTMP $KEYRINGRun it with the hostname of a cluster node where you have an acct as the first argument. Be sure to set $CEPHADM to the right location for the cephadm script on the machine.
Once you run that, you’ll have a minimal config on the client. You may want to test it by running “ceph -s” or something similar.
At this point, I usually mount up both the test and scratch filesystems and create a directory under there with the hostname of the client (client1 in this example), and set it up to do random pinning. This way I can run multiple clients and let them test in their own areas of each fs.
So you now have a cluster and a client, and the client’s userland code can talk to the cluster.
On the client, you’ll need to pull down the xfstests tree, and build it (e.g. run “make”). You may need to install some prerequisite packages (see the README file in the xfstests sources).
To run xfstests, you’ll need an appropriate config file. Here’s the main one I use (hopefully with some helpful comments). I usually replace local.config in the xfstests tree with this, just to make test running easy. You’ll need to do adjust this for your own environment, of course:
#
# This config file is or running xfstests on kcephfs. You'll require
# an existing cluster to test against (a vstart cluster is fine).
# To understand the mount syntax and the available options, see
# mount.ceph(8).
#
export TEST_DIR=/mnt/test
export SCRATCH_MNT=/mnt/scratch
#
# "check" can't automatically detect ceph device strings, so we must
# explicitly declare that we want to use "-t ceph".
#
export FSTYP=ceph
#
# In this example, we've created two different named cephfs filesystems:
# "test" and "scratch. They must be pre-created on the ceph cluster before
# the test is run.
#
# The check script gets very confused when two different mounts use
# the same device string. There is a project to change how the mount device
# syntax works, but it's not yet merged.
#
# For now, we must declare the location of the mons explicitly. Note that we're
# using two different monaddrs here on different hosts, though these are using
# the same cluster. The monaddrs must also match the type of ms_mode option
# that is in effect (i.e. ms_mode=legacy requires v1 monaddrs).
#
export TEST_DEV=192.168.1.81:3300:/client1
export SCRATCH_DEV=192.168.1.82:3300:/client1
#
# TEST_FS_MOUNT_OPTS is for /mnt/test, and MOUNT_OPTONS is for /mnt/scratch
#
# Here, we're using the admin account for both mounts. The credentials
# should be in a standard keyring location somewhere. See:
#
# https://docs.ceph.com/en/latest/rados/operations/user-management/#keyring-management
#
COMMON_OPTIONS="name=admin"
# if you want to use an explicit secret instead of finding it in a ceph keyring
# COMMON_OPTIONS+=",secret=AQAkaM5g7+GuIRAAM3xLNwSQc8953uo3/1QkLw=="
# use msgr2 in crc mode
COMMON_OPTIONS+=",ms_mode=crc"
# asynchronous directory ops
COMMON_OPTIONS+=",nowsync"
# enable copy offload
COMMON_OPTIONS+=",copyfrom"
# now for the per-mount options
TEST_FS_MOUNT_OPTS="-o ${COMMON_OPTIONS}"
MOUNT_OPTIONS="-o ${COMMON_OPTIONS}"
# select the correct cephfs
TEST_FS_MOUNT_OPTS+=",mds_namespace=test"
MOUNT_OPTIONS+=",mds_namespace=scratch"
# fscache -- each fs needs its own fsc= tag
TEST_FS_MOUNT_OPTS+=",fsc=test"
MOUNT_OPTIONS+=",fsc=scratch"
export TEST_FS_MOUNT_OPTS
export MOUNT_OPTIONS
Finally, you just need to run the tests. Some xfstests can take a very long time to run on cephfs. I often run the quick test group. It still takes a couple of hours on ceph, but it covers a variety of things.
Some tests always fail on cephfs. generic/003, for example complains about atime handling, and ceph really can’t (easily) offer the semantics it wants. I have a file called ceph.exclude in the root of the xfstests tree and I have a single line in it so I can skip that one:
generic/003Now we can run the tests!
$ sudo ./check -g quick -E ./ceph.excludeIf there are failures, please report them to the ceph-devel mailing list and we’ll try to help troubleshoot what happened.
rhughes)
on November 29, 2021 11:45 AM
I’ve just deployed some new functionality to the LVFS adding support for component <tag>s. These are used by server vendors to identify a known-working (or commercially supported) set of firmware on the machine. This is currently opt-in for each vendor to avoid the UI clutter on the components view, and so if you’re a vendor reading this post and realize you want this feature, let me know and it’s two clicks on the admin panel.
The idea is that when provisioning the machine, we can set HostBkc=vendor-2021q1 in /etc/fwupd/daemon.conf and then any invocation of fwupdmgr sync-bkc will install or downgrade firmware on all compatible devices (UEFI, RAID, network adapter, & SAS HBA etc.) to make the system match a compatible set. This allows two things:
The tags are either assigned in the archive firmware.metainfo.xml file or added post-upload on the LVFS and are then included in the public AppStream metadata. A single firmware can be marked with multiple tags, and tags can be duplicated for different firmwares. This would allow a server vendor to say “this set of firmware has been tested as a set for workload A, and this other set of firmware has been tested for workload B” which is somewhat odd for us consumer-types, but seems to be pretty normal for enterprise deployments.
As a bonus feature, updating or downgrading firmware away from the “Best Known Configuration” is allowed, but we’ll show a semi-scary warning. Using fwupdmgr sync-bkc will undo any manual changes and bring the machine back to the BKC. Needless to say fwupd will not ship with a configured BKC.
We’ll include this somewhat-niche-but-required feature with fwupd 1.7.3 which will hopefully be released before Christmas. Questions and comments welcome.
admin)
on November 29, 2021 08:00 AM
In the role of a packager, updating packages is a recurring task. For some projects, a packager is involved in upstream maintenance, or well written release notes make it easy to figure out what changed between the releases. This isn’t always the case, for instance with some small project maintained by one or two people somewhere on github, and it can be useful to verify what exactly changed. Diffoscope can help determine the changes between package releases.
Diffoscope is a “smart binary diff” tool that was born in the Reproducible Builds project in Debian, which is also available in Fedora. It “knows” about various types of text and binary formats, and will try to recursively unpack and compare two blobs. In particular it knows that some objects need to be decompressed before comparing, that archives need to be unpacked, and how to deconstruct binary objects like ELF programs and libraries, Java .jar files, Windows .cab files, etc.
Just today I received a bug report stating that there is a new version of python-libarchive-c available (3.2, while 3.1 is what is currently packaged). It is a simple Python package. But even a simple Python package has some binary files, so a straightforward diff on the unpackaged rpms doesn’t really work. Let’s see how Diffoscope can be used to show the differences between the binary packages in detail.
The first step is to compare the upstream archives:
$ diffoscope python-libarchive-c-3.{1,2}.tar.gz
+++ python-libarchive-c-3.2.tar.gz
│ --- python-libarchive-c-3.1.tar ❶
├── +++ python-libarchive-c-3.2.tar
│ ├── file list
│ │ @@ -1,46 +1,46 @@ ❷
│ │ -drwxrwxr-x 0 root (0) root (0) 0 2021-06-01 07:32:24.000000 python-libarchive-c-3.1/
│ │ --rw-rw-r-- 0 root (0) root (0) 25 2021-06-01 07:32:24.000000 python-libarchive-c-3.1/.gitattributes
│ │ -drwxrwxr-x 0 root (0) root (0) 0 2021-06-01 07:32:24.000000 python-libarchive-c-3.1/.github/
│ │ --rw-rw-r-- 0 root (0) root (0) 20 2021-06-01 07:32:24.000000 python-libarchive-c-3.1/.github/FUNDING.yml
...
│ │ --rw-rw-r-- 0 root (0) root (0) 1331 2021-06-01 07:32:24.000000 python-libarchive-c-3.1/version.py
│ │ +drwxrwxr-x 0 root (0) root (0) 0 2021-10-06 12:40:03.000000 python-libarchive-c-3.2/
│ │ +-rw-rw-r-- 0 root (0) root (0) 25 2021-10-06 12:40:03.000000 python-libarchive-c-3.2/.gitattributes
│ │ +drwxrwxr-x 0 root (0) root (0) 0 2021-10-06 12:40:03.000000 python-libarchive-c-3.2/.github/
│ │ +-rw-rw-r-- 0 root (0) root (0) 20 2021-10-06 12:40:03.000000 python-libarchive-c-3.2/.github/FUNDING.yml
...
│ │ +-rw-rw-r-- 0 root (0) root (0) 1331 2021-10-06 12:40:03.000000 python-libarchive-c-3.2/version.py
...
│ │ --- python-libarchive-c-3.1/libarchive/ffi.py
│ ├── +++ python-libarchive-c-3.2/libarchive/ffi.py
│ │┄ Files 0% similar despite different names
│ │ @@ -43,15 +43,15 @@
│ │ SEEK_CALLBACK = CFUNCTYPE(
│ │ - c_longlong, c_int, c_void_p, c_longlong, c_int ❸
│ │ + c_longlong, c_void_p, c_void_p, c_longlong, c_int
│ │ )
│ │ --- python-libarchive-c-3.1/libarchive/read.py
│ ├── +++ python-libarchive-c-3.2/libarchive/read.py
│ │┄ Files 2% similar despite different names
│ │ @@ -61,17 +61,18 @@
│ │ close_cb = CLOSE_CALLBACK(close_func) if close_func else NO_CLOSE_CB
│ │ + seek_cb = SEEK_CALLBACK(seek_func)
│ │ with new_archive_read(format_name, filter_name, passphrase) as archive_p:
│ │ if seek_func:
│ │ - ffi.read_set_seek_callback(archive_p, SEEK_CALLBACK(seek_func))
│ │ + ffi.read_set_seek_callback(archive_p, seek_cb)
│ │ ffi.read_open(archive_p, None, open_cb, read_cb, close_cb)
│ │ yield archive_read_class(archive_p)
...
│ │ --- python-libarchive-c-3.1/libarchive/write.py
│ ├── +++ python-libarchive-c-3.2/libarchive/write.py
│ │┄ Files identical despite different names
│ │ --- python-libarchive-c-3.1/setup.py ❹
│ ├── +++ python-libarchive-c-3.2/setup.py
│ │┄ Files identical despite different names
...
│ │ --- python-libarchive-c-3.1/version.py
│ ├── +++ python-libarchive-c-3.2/version.py
│ │┄ Files 1% similar despite different names
│ │ @@ -9,15 +9,15 @@
│ │ def get_version():
│ │ # Return the version if it has been injected into the file by git-archive
│ │ - version = tag_re.search('HEAD -> master, tag: 3.1')
│ │ + version = tag_re.search('HEAD -> master, tag: 3.2') ❺
│ │ if version:
│ │ return version.group(1)
At ❶ we see that we’re comparing two archives. (Note: this diff output has been heavily trimmed for readability.)
At ❷ we see that the listings of both archives are different, but the difference is as expected: the version number is included in the name of the top-level directory in the archives, so all paths are different. We also see that the two archives were created at different dates (2021-06-01 07:32:24 and 2021-10-06 12:40:03 respectively). This listing would alert us if upstream added or removed files unexpectedly.
At ❸ we see that there were some code changes in the SEEK_CALLBACK function.
Upstream release notes about it say that “this release fixes the seek callbacks passed to libarchive by the custom_reader and stream_reader functions”, so that change looks reasonable.
Most files are not changed, so at ❹ diffoscope dutifully reports that they are the same despite the file name change… And at ❺ we get another version releated change.
And that’s it — no more changes in the upstream tarball.
Let’s build the package then and compare it with a previous build.
After adjusting the spec file for the new version, the second step is to build the package and compare with an older version. fedpkg mockbuild puts the resulting packages in a subdirectory named after the version:
$ fedpkg mockbuild
...
INFO: Results and/or logs in: ~/fedora/python-libarchive-c/results_python-libarchive-c/3.2/1.fc36
$ diffoscope results_python-libarchive-c/3.1/3.fc36/python3-libarchive-c-3.1-3.fc36.noarch.rpm \
results_python-libarchive-c/3.2/1.fc36/python3-libarchive-c-3.2-1.fc36.noarch.rpm
+++ results_python-libarchive-c/3.2/1.fc36/python3-libarchive-c-3.2-1.fc36.noarch.rpm
├── header
│ @@ -1,79 +1,79 @@ ❶
│ -HEADERIMMUTABLE: 0000003d00001ed50000003f...1000003e8000000060000
│ +HEADERIMMUTABLE: 0000003d00001e8d0000003f...1000003e8000000060000
In the case of the binary packages, there are many more differences than in the upstream tarball. But let’s try to go through them.
│ HEADERI18NTABLE: │ - C │ -SIGSIZE: 26733 ❷ │ -SIGMD5: 1aa148ac91484fe8cb55fe3334aae10b │ -SHA1HEADER: 1659a1431af930a0a824c193780e27f28fc2d03e │ -SHA256HEADER: 60e4f84e905bd42693cabe88e63542916a7dfffef052f3e7499cb80a1770c736 │ +SIGSIZE: 26678 │ +SIGMD5: e35e3157e01b6ec26b8e1981f0ba38af │ +SHA1HEADER: faab0b7ee86b23f753b2c49a52d6a8f3deefc7ca │ +SHA256HEADER: 66d39a70dc9e081ba5cc4243e72f434e953d68c9bce8be1127b2b87fa1923d06 │ NAME: python3-libarchive-c │ -VERSION: 3.1 ❸ │ -RELEASE: 3.fc36 │ +VERSION: 3.2 │ +RELEASE: 1.fc36 │ SUMMARY: Python interface to libarchive │ DESCRIPTION: The libarchive library provides a flexible interface for reading and writing archives in various │ formats such as tar and cpio. libarchive also supports reading and writing archives compressed using │ various compression filters such as gzip and bzip2. A Python interface to libarchive. It uses the │ standard ctypes module to dynamically load and access the C library. │ -BUILDTIME: 1638015932 │ +BUILDTIME: 1638015863 ❹ │ BUILDHOST: spora.local │ -SIZE: 68979 │ +SIZE: 69052 │ LICENSE: CC0 │ GROUP: Unspecified │ URL: https://github.com/Changaco/python-libarchive-c │ OS: linux │ ARCH: noarch
We can see that Diffoscope does something similar to rpmdiff on the two archives, but with much more detail.
At ❶ we see that the rpm header changed, which is not surprising 
At ❷ we get the details of the signatures, and version info at ❸. Build timestamp and rpm size may also be interesting at ❹. Diffoscope then prints a comparison of the FILESIZES, FILEMTIMES, FILEMD5S tables in the rpm headers. This would be useful if we were trying to chase down some unexpected difference between packages.
│ CHANGELOGTIME: │ + - 1638014400 │ - 1627387200 ... │ - - 1570104000 │ - - 1566216000 │ CHANGELOGNAME: │ + - Zbigniew Jędrzejewski-Szmek 3.2-1 │ - Fedora Release Engineering - 3.1-2 ... │ - - Miro Hrončok - 2.8-10 │ - - Miro Hrončok - 2.8-9 │ CHANGELOGTEXT: │ + - - Version 3.2 (fixes #2027027) │ - - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild ... │ - - - Rebuilt for Python 3.8.0rc1 (#1748018) │ - - - Rebuilt for Python 3.8
Here we see that the changelog got trimmed (my entry is added, and two from Miro are dropped). In Fedora we set %_changelog_trimage to 2 years, so even if the spec file defines a longer changelog, in the built package the oldest entries are trimmed away.
Then we get some expected but important differences:
│ PROVIDEVERSION: │ - - 3.1-3.fc36 │ + - 3.2-1.fc36 ❶ │ OBSOLETEVERSION: │ - - 3.1-3.fc36 │ + - 3.2-1.fc36 ... │ DIRNAMES: ❷ │ - - /usr/lib/python3.10/site-packages/libarchive_c-3.1-py3.10.egg-info/ │ + - /usr/lib/python3.10/site-packages/libarchive_c-3.2-py3.10.egg-info/ ... │ @@ -1 +1 @@ │ -RPM v3.0 bin i386/x86_64 python3-libarchive-c-3.1-3.fc36 │ +RPM v3.0 bin i386/x86_64 python3-libarchive-c-3.2-1.fc36 ├── content │ ├── file list │ │ @@ -1,35 +1,35 @@ │ │ -drwxr-xr-x 1 0 0 0 2021-10-27 12:20:33.000000 ./usr/lib/python3.10/site-packages/libarchive ❸ │ │ --rw-r--r-- 1 0 0 601 2021-06-01 07:32:24.000000 ./usr/lib/python3.10/site-packages/libarchive/__init__.py │ │ -drwxr-xr-x 1 0 0 0 2021-10-27 12:20:34.000000 ./usr/lib/python3.10/site-packages/libarchive/__pycache__ ... │ │ +drwxr-xr-x 1 0 0 0 2021-11-27 12:24:23.000000 ./usr/lib/python3.10/site-packages/libarchive ❹ │ │ +-rw-r--r-- 1 0 0 601 2021-10-06 12:40:03.000000 ./usr/lib/python3.10/site-packages/libarchive/__init__.py │ │ +drwxr-xr-x 1 0 0 0 2021-11-27 12:24:24.000000 ./usr/lib/python3.10/site-packages/libarchive/__pycache__ ... │ ├── ./usr/lib/python3.10/site-packages/libarchive/ffi.py │ │ @@ -43,15 +43,15 @@ │ │ SEEK_CALLBACK = CFUNCTYPE( │ │ - c_longlong, c_int, c_void_p, c_longlong, c_int ❺ │ │ + c_longlong, c_void_p, c_void_p, c_longlong, c_int │ │ ) │ │ @@ -61,17 +61,18 @@ │ │ close_cb = CLOSE_CALLBACK(close_func) if close_func else NO_CLOSE_CB │ │ + seek_cb = SEEK_CALLBACK(seek_func) │ │ with new_archive_read(format_name, filter_name, passphrase) as archive_p: │ │ if seek_func: │ │ - ffi.read_set_seek_callback(archive_p, SEEK_CALLBACK(seek_func)) │ │ + ffi.read_set_seek_callback(archive_p, seek_cb) │ │ ffi.read_open(archive_p, None, open_cb, read_cb, close_cb) ...
At ❶ we see that the package version change is reflected in the PROVIDEVERSION and OBSOLETEVERSION tables in the rpm header. There are also PROVIDENAME and OBSOLETENAME tables, but those are unchanged in this case. This is good: we are not expecting any changes to Provides or Obsoletes, except for the version bump.
At ❷ we again see that the version is reflected in a path.
You can see ❸ and ❹ are the heavily trimmed lists of files in both packages. All files are reported as different because the modification time changed. But please look closely at the timestamps: __init__.py is a file provided by upstream, and the mtime is preserved during installation, so we see the same timestamps as in the first listing from the upstream tarball comparison. But the __pycache__ directory was created during build and has a timestamp that shows when the build was done. We would see the same for other files produced during build.
Now comes the boring part:
│ ├── ./usr/lib/python3.10/site-packages/libarchive/__pycache__/__init__.cpython-310.pyc │ │ @@ -1,8 +1,8 @@ │ │ -00000000: 6f0d 0d0a 0000 0000 88e2 b560 5902 0000 o..........`Y... ❶ │ │ +00000000: 6f0d 0d0a 0000 0000 2399 5d61 5902 0000 o.......#.]aY... │ ├── ./usr/lib/python3.10/site-packages/libarchive/__pycache__/entry.cpython-310.pyc │ │ @@ -1,8 +1,8 @@ │ │ -00000000: 6f0d 0d0a 0000 0000 88e2 b560 0c14 0000 o..........`.... ❷ │ │ +00000000: 6f0d 0d0a 0000 0000 2399 5d61 0c14 0000 o.......#.]a.... ... │ │ --- ./usr/lib/python3.10/site-packages/libarchive_c-3.1-py3.10.egg-info/PKG-INFO │ ├── +++ ./usr/lib/python3.10/site-packages/libarchive_c-3.2-py3.10.egg-info/PKG-INFO │ │┄ Files 0% similar despite different names │ │ @@ -1,10 +1,10 @@ │ │ Name: libarchive-c │ │ -Version: 3.1 ❸ │ │ +Version: 3.2 │ │ Summary: Python interface to libarchive │ │ Home-page: https://github.com/Changaco/python-libarchive-c
… yes, diffoscope shows the diff between the hexdump listings of .pyc files (Python bytecode at ❶ and ❷). Those files were created during the build, so we know that those changes correspond to the changes to the sources shown in previous listings. At the end we again see the version changed in the PKG-INFO file (❸).
Currently, diffoscope does not know how to show Python bytecode in a better way. But it is possible that in the future it will be able to deassemble the bytecode back into some more readable form and show the diff on that. New parsers are regularly being added to diffoscope. For compiled programs, it will already show a diff on the disassembled machine code.
After looking at all those diffs, I think one can say with some confidence that the upgrade from python-libarchive-c-3.1 to python-libarchive-c-3.2 is safe. In particular, it is suitable even for a stable release because it has only a bug fix.
Big shout out to Chris Lamb and the other maintainers of diffoscope.
Poezio est un logiciel du dépôt Fedora. Il est disponible pour tous les utilisateurs de Fedora Linux 35 qui souhaitent utiliser la messagerie instantannée XMPP. J'utilise tous les jours ce protocole de messagerie instantannée, et j'avais envie de vous partager mon expérience avec un client en console.
Poezio n'est pas installé par défaut, il faut le récupérer dans le dépôt :
dnf install poezio poezio-doc poezio-omemo
Le paquet "poezio" contient le client XMPP, et le paquet "poezio-omemo" contient le plugin OMEMO pour le client.
Pour lancer le logiciel, il suffit de taper la commande en utilisateur simple :
$ poezio
On peut le lancer dans un multiplexeur de terminal comme screen ou tmux. On peut aussi le lancer dans une session en init 3 (multi-user.target).
On peut également le lancer dans un container docker/podman, mais ce n'est pas le sujet de cet article.
Il est possible de configurer le client à chaud, en tapant des commandes pendant qu'il fonctionne, ou bien à froid, en modifiant directement le fichier de configuration.
Pour modifier un paramètre pendant le fonctionnement, il faut taper la commande /set dans Poezio.
Les commandes de configuration suivantes permettent de se connecter à son compte XMPP :
/set jid <mon_compte@domaine.tld>
/set password <mot_de_passe>
/set default_nick <Pseudo>
/set ca_cert_path /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/connect
Une ligne de confirmation apparait pour chacune des commandes fournies. Une fois le client configuré et connecté, Poezio va sauvegarder la config pour le prochain démarrage.
Pour faire une configuration plus avancée, je recommande de passer directement par le fichier de configuration. Le fichier est au format INI, et il est vraiment facile à lire.
Si Poezio est lancé pour la première fois, le fichier de configuration par défaut est créé dans le répertoire ~/.config/poezio/. Il est recommandé de ne pas modifier ce fichier pendant l'exécution de Poezio.
Toutes les options sont concentrées dans un seul et unique fichier :
~/.config/poezio/poezio.cfg
Pour activer le support de OMEMO, il faut modifier le paramètre "plugins_autoload" de la manière suivante :
plugins_autoload = omemo
Chemins vers les plugins :
plugins_dir = /usr/lib64/python3.9/site-packages/poezio_plugins
plugins_conf_dir = /home/USER/.config/poezio/plugins
Réglage des timeouts :
connection_check_interval = 60
connection_timeout_delay = 300
whitespace_interval = 180
Il est fortement recommandé de configurer l'option ca_cert_path. Cette option n'est pas configurée par défaut.
Lancer la commande dans Poezio :
/set ca_cert_path /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
Ou bien modifier le fichier de config :
ca_cert_path = /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
Au démarrage, le client vérifie l'empreinte du certificat du serveur, et vérifie si l'empreinte n'a pas changé depuis la dernière connexion au serveur. Il est possible de désactiver cette fonctionnalité :
ignore_certificate = True
Avec ce paramètre, Poezio ne va plus demander à l'utilisateur de valider l'empreinte du certificat, mais va vérifier le certificat avec la base des certificats du système (avec l'option "ca_cert_path").
Référence : TLS in poezio
Poezio fourni une commande très utile pour comparer son fichier de configuration avec les valeurs par défaut.
$ poezio -c
Cette commande ne lance pas le client, mais affiche toutes les différences avec la configuration par défaut, ce qui permet de retrouver facilement une erreur dans le fichier de config.
Pour naviguer :
| Touche | Fonction |
|---|---|
| F5 | onglet précédent |
| F6 | onglet suivant |
| Echap puis un chiffre | va sur l'onglet correspondant |
| Alt-j puis 2 chiffres | va sur l'onglet correspondant |
Fenêtre d'information :
| Touche | Fonction |
|---|---|
| F7 | réduit la fenêtre d'information |
| F8 | agrandi la fenêtre d'information |
| Alt-Maj-d | scroll vers le haut |
| Alt-Maj-c | scroll vers le bas |
Pour formater les messages avant envoi :
| Touche | Fonction |
|---|---|
| Ctrl-a | déplace le curseur au début de la ligne |
| Ctrl-e | déplace le curseur à la fin de la ligne |
| Ctrl-j | ajoute un retour à la ligne |
| Tab | complète automatiquement le pseudo |
Pour scroller :
| Touche | Fonction |
|---|---|
| Flèche haut | remonte l'historique des envois |
| Flèche bas | descend dans l'historique des envois |
| Page Up | remonte l'historique de la discussion |
| Page Down | descend l'historique de la discussion |
Les fichiers journaux sont créés par défaut dans le répertoire ~/.local/share/poezio/logs/. Mais il est possible de modifier le chemin du répertoire :
log_dir = /home/USER/.local/share/poezio/logs
Si l'on souhaite désactiver les journaux système :
log_errors = False
La récupération de l'historique des salons est configurable, mais dépend du serveur qui héberge le salon. Personnellement, je préfère que le client récupère la valeur fournie par le serveur, c'est à dire la valeur maximum :
muc_history_length = -1
Cette fonctionnalité de récupération de l'historique du serveur entre en conflit avec l'option load_log. Cette option permet d'afficher une dizaine de lignes de log qui étaient stockées dans les fichiers de log de Poezio. Si les 2 options sont activées en même temps, alors on obtient un historique incohérent, et en double.
use_log = True
load_log = 0
Poezio est un client XMPP largement personnalisable. Il est possible d'afficher la liste des salons dans une ligne en bas, ou dans une colonne à gauche. Il est également possible d'afficher la liste des participants du salon, ou pas. Et enfin, on peut afficher, avec une taille variable, la fenêtre d'information en dessous des fenêtres de conversation.
Chemin vers les thèmes :
themes_dir = /usr/lib64/python3.9/site-packages/poezio_themes
Si vous souhaitez utiliser le thème "dark" :
theme = dark
Il est possible de se connecter au serveur XMPP en passant par un serveur proxy. Pour celà, il faut installer et configurer le programme proxychains.
dnf install proxychains
Pour que ce programme puisse se connecter au bon serveur proxy, il faut renseigner le fichier /etc/proxychains.conf.
Par exemple, si l'on veut établir une connexion au proxy SOCKSv5 de Tor :
[ProxyList]
socks5 ::1 9050
Si le serveur XMPP possède une adresse .onion, on peut l'indiquer aussi dans le fichier de configuration de Poezio :
jid = <mon_compte@domaine.tld>
server = <adresse.onion>
Une fois les 2 programmes correctement configurés, on peut lancer Poezio :
$ proxychains poezio
La documentation est disponible en ligne pour la toute dernière version. Elle est également fournie avec le paquet poezio-doc pour une version donnée. Le RPM installe la doc dans le répertoire système :
/usr/share/doc/poezio/rst/
Il est possible de compiler les fichiers ReST en document PDF, ou en pages HTML (pour un usage hors-ligne ou purement esthétique).
bressers)
on November 29, 2021 12:01 AM
Josh and Kurt talk about an article about how expertise has a limited lifetime. We are all experts in something, but some of us will find our expert knowledge to be outdated eventually. We discuss what that means in the context of security and tech and disagree about how to best keep your skills up to date.
<audio class="wp-audio-shortcode" controls="controls" id="audio-2614-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/secure/opensourcesecuritypodcast/Episode_299_Experts_From_A_World_That_No_Longer_Exists.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/secure/opensourcesecuritypodcast/Episode_299_Experts_From_A_World_That_No_Longer_Exists.mp3</audio>
ttorcz)
on November 27, 2021 04:00 PM
Chances are you are reading this post on a blog aggregator (“planet”) named We Make Fedora (lack of link deliberate). We Make Fedora was apparently organised by Daniel Pocock. He copied all the blog sources from Planet Fedora, but mixed-in some shady, anonymous sources. This way, “conspiracy theory”-like nameless posts build on credibility of real Fedora developer's blogs.
I do not want neither my name nor mine posts to appear alongside such content. Examples of recent posts:
borderline slanderous posts about Chris Lamb, former Debian leadership (on allegely Fedora-related site!) personal matters
insinuations about trafficking of underage girls by open source communities, on one occasion implicating Justin W. Flory from Fedora
comparison between Adolf Hitler's activities (!!!) and German Free Software Foundation of Europe
equaling Google's Youth Hacking 4 Freedom with nazi Concentration Camps
Holocaust is a very painful memory for European society. It should never be forgotten, the memory should be treated with seriousness in places like Yad Vashem Institue. It should never be used in an anonymous slanderous content.
Again, I do not want my name used to legitimise above content. I've asked Daniel to remove my blog from his aggregator three times:
on Tue, 24 Aug 2021 12:00:33 +0200, in a direct email
on Mon, 6 Sep 2021 09:17:35 +0200, in an email to Daniel and fedora-devel (apparently still in moderation queue)
on Mon, 6 Sep 2021 17:08:42 +0200, in a reply to Daniel
Despite above efforts, my posts still appear on We Make Fedora. I don't want to see my name on a site with such dubious content. I going to block access to my RSS/ATOM feeds for the aggregator. Unfortunately anyone can utilize public feeds to create any site he wants.
renault)
on November 26, 2021 10:53 PM
Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.
Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 9 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.
Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.
Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.
Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.
Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.
Les rôles au sein du conseil sont complexes.
Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.
Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.
Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.
Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !
Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.
Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.
Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.
Ils vont donc traiter en particulier les points suivants :
Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.
Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.
Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :
Et ses nouvelles compétences :
Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.
czanik)
on November 26, 2021 03:33 PM
Better late than never I just put online the November syslog-ng newsletter. Topics include:
It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2021-11-3-35-ssb-macos-mqtt-destination-updates
admin)
on November 26, 2021 02:00 PM
Here’s your weekly Fedora report. Read what happened this week and what’s coming up. Your contributions are welcome (see the end of the post)!
Fedora Linux 33 will reach end of life on Tuesday 30 November. The F35 retrospective survey is open through 4 December.
I have weekly office hours on Wednesdays in the morning and afternoon (US/Eastern time) in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else. See the upcoming meetings for more information.
| Conference | Location | Date | CfP |
|---|---|---|---|
| SCaLE | Pasadena, CA, US | 5–8 Mar | closes 30 Nov |
The call for F36 Test Days is open.
See the Prioritized Bugs documentation for information on the process, including how to nominate bugs.
| Release | open bugs |
|---|---|
| F33 | 4622 |
| F34 | 5514 |
| F35 | 1965 |
| F36 (rawhide) | 6641 |
The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.
<figure class="wp-block-table">| Proposal | Type | Status |
|---|---|---|
| Package information on ELF objects | System-Wide | FESCo #2687 |
| ELN-Extras | System-Wide | FESCo #2700 |
| Unit Names in Systemd Messages | Self-Contained | FESCo #2701 |
| Remove Wire Extensions Support | Self-Contained | FESCo #2702 |
| ostree native containers / CoreOS layering | System-Wide | Announced |
| Plocate as the default locate implementation | Self-Contained Change | Announced |
| PostgreSQL 14 | Self-Contained | Announced |
The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.
<figure class="wp-block-table">| Proposal | Type | Status |
|---|---|---|
| RetireARMv7 | System-Wide | FESCo #2703 |
Have something you want included? You can file an issue or submit a pull request in the fedora-pgm/pgm_communication repo.
The post Friday’s Fedora Facts: 2021-47 appeared first on Fedora Community Blog.
We're happy to announce Kiwi TCMS version 10.5 which celebrates the very positive reception we had at WebSummit 2021!
IMPORTANT: this is a medium sized release which contains various improvements and new features, database changes, new settings and API methods, bug-fixes, internal refactoring and updated translations.
You can explore everything at https://public.tenant.kiwitcms.org!
Supported upgrade paths:
5.3 (or older) -> 5.3.1 5.3.1 (or newer) -> 6.0.1 6.0.1 -> 6.1 6.1 -> 6.1.1 6.1.1 -> 6.2 (or newer)
Container images:
kiwitcms/kiwi latest 0574b19b5d66 583 MB kiwitcms/kiwi 6.2 7870085ad415 957 MB kiwitcms/kiwi 6.1.1 49fa42ddfe4d 955 MB kiwitcms/kiwi 6.1 b559123d25b0 970 MB kiwitcms/kiwi 6.0.1 87b24d94197d 970 MB kiwitcms/kiwi 5.3.1 a420465852be 976 MB
Warning:
For Postgres data dir changed from /var/lib/pgsql/data to /var/lib/postgres/data. Environment variables inside docker-compose file changed as well, see docker-compose.postgres.
For MariaDB data dir changed from /var/lib/mysql/data to /var/lib/mysql. MYSQL_CHARSET & MYSQL_COLLATION environment variables are no longer recognized. Instead they are present as command line options passed to the container, see docker-compose.yml. Previous workaround for these variables was also removed.
If you want to migrate from the previous centos/mariadb-103-centos7 or centos/postgresql-12-centos7 containers to mariadb:latest and postgres:latest make sure to update your container control files!
Warning:
These newly added models create additional permission labels with names testcases | template | Can .... template, testcases | property | Can .... property, testruns | test execution property | Can .... test execution property
Execute manage.py refresh_permissions and/or assign them manually to users and groups if they should be able to interact with the new objects!
Warning:
The visual markdown editor explicitly didn't follow markdown syntax rules by allowing indentation with 2 spaces and treating tabs as 2 spaces as well. See "Indentation/Tab Length" at https://python-markdown.github.io/#differences
The backend markdown rendering engine explicitly followed an undefined behavior which happens to be different from what the visual markdown editor does. See "Consecutive Lists" at https://python-markdown.github.io/#differences
The previous 2 changes make sure the visual editor and backend rendering engine follow the same rules. This may result is "broken" display of existing text which doesn't follow the markdown syntax rules. If you spot such text just edit to make it render the way you wish.
Private images:
quay.io/kiwitcms/enterprise 10.5-mt 3e597c91d057 804 MB quay.io/kiwitcms/version 10.5 0574b19b5d66 583 MB
IMPORTANT: version tagged and Enterprise container images are available only to subscribers!
Backup first! Then execute the commands:
cd path/containing/docker-compose/ docker-compose down docker-compose pull docker-compose up -d docker exec -it kiwi_web /Kiwi/manage.py migrate
Refer to our documentation for more details!
Happy testing!
---
If you like what we're doing and how Kiwi TCMS supports various communities please help us!
Signed-off-by: Mattia Verga mattia.verga@tiscali.it
jstribny)
on November 26, 2021 12:00 AM
Developers usually think of timezones, but European summertime changes can be easily overlooked. I have to admit I overlooked them when parsing dates with DateTime.from_naive!/2.
What’s the issue, you ask?
Let’s parse some time with DateTime.from_naive!/:
iex> datetime = DateTime.from_naive!(DateTime.utc_now(), "EET")
#DateTime<2021-11-26 10:36:32.810393+02:00 EET EET>
Most of the time, this works as you would expect – and looks innocent.
But it all breaks for summer and winter time changes which are known as Daylight Saving Time (DST). Consider getting a datetime string on the day and minute of the change:
iex(17)> datetime = DateTime.from_naive!(~N[2021-10-31 03:00:00], "EET")
** (ArgumentError) cannot convert ~N[2021-10-31 03:00:00] to datetime because such instant is ambiguous in time zone EET as there is an overlap between #DateTime<2021-10-31 03:00:00+03:00 EEST EET> and #DateTime<2021-10-31 03:00:00+02:00 EET EET>
(elixir 1.12.3) lib/calendar/datetime.ex:559: DateTime.from_naive!/3
At 3 am, the daylight saving time changes in the EET timezone for winter…
Luckily Elixir provides a nice error message with all the details, and hopefully, it’s not too late to fix it.
In case of parsing naive date time, you’ll have to leave the bang method. DateTime.from_naive/2 supports handling ambiguous times:
datetime = case DateTime.from_naive(~N[2021-10-31 03:00:00], "EET") do
{:ok, datetime} ->
datetime
{:ambiguous, before_dst_change, after_dst_change} ->
after_dst_change
{:gap, timezone_before, timezone_after} ->
timezone_after
{:error, error} ->
# handle error, raise...
end
The before datetime would be #DateTime<2021-10-31 03:00:00+03:00 EEST EET> and the one after the change would be
#DateTime<2021-10-31 03:00:00+02:00 EET EET>. Most will probably consider the edge case as a start of the new time, therefore I used the after_dst_change date.
I also had to pattern-match on :gap since that’s what would be used for a datetime that doesn’t actually exist, but falls inbetween two valid datetimes.
Although clarified and well documented (thank you Elixir!), you want to implement this beforehand so your processes don’t fail, and you don’t have to go back to fix some data.
admin)
on November 26, 2021 12:00 AM
Voting in the Fedora Linux 35 elections is now open. Go to the Elections app to cast your vote. Voting closes at 23:59 UTC on Thursday 9 December. Don’t forget to claim your “I Voted” badge when you cast your ballot. Links to candidate interviews are below.
There is one seat open on the Fedora Council.
There are five seats open on FESCo.
There is one seat open on the Mindshare Committee.
The post F35 Elections voting now open! appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:55 PM
This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I am using Fedora workstation on a daily basis, for personal and professional use. I also do packaging tasks for nmstate and nispor packages from Fedora 32.
In 2020, I have actively participated as a mentor for the Fedora organisation in the Google Summer of Code and Outreachy programmes. I have also participated in several Fedora events like the Fedora Nest 2020 and Fedora 36 release party.
As a free software enthusiast, I have always liked to motivate potential contributors to step forward, as others motivated me. I love working in mentoring programs like Outreachy or GSoC. I find that the work of organisations like Fedora make a difference in the spread and adoption of free software.
I also feel that I am very much aligned with the ideas of inclusion and diversity that Fedora advocates so I feel that I can help in the efforts.
I am part of a GNU/Linux user group and therefore have some experience in organising promotional and outreach events in local communities.
Fedora is a good place to grow and improve, helping others at the same time and that’s why I would like to be part of the Mindshare committee.
I believe that one of the best ways to improve the visibility of the Mindshare committee is to promote mentoring programmes. This can let people outside the community know what Fedora is and how it works, as well as promote the committee’s work internally.
I also find the ambassador position interesting and how this committee can work with them so that their work is really valued and has a very positive impact on the community.
I would like to be able to contribute to mentoring programmes, not only as a mentor but also as an organiser. I would also like to be able to communicate with other organisations that promote these types of programmes so that Fedora can participate in as many programmes as possible, as long as they are aligned with our community.
Last but not least, I would like to be able to promote Fedora more in my local community. I would like to draw up a plan on how to organize local events and test it out, this way, it will serve as a guideline for other organizers in the community.
The post Mindshare election: Interview with Fernando Fernández Mancera (ffmancera) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:55 PM
This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
Currently, I am serving in the Mindshare committee. I participated in many areas of Fedora, here are my milestones:
There is a lack of candidates for Fedora’s elections. To give more meaning to the election, I stepped up allow the community to have a choice and to give a more clear and supporting mandate to the winner. I am a Fedora Ambassador and enjoyed representing Fedora at events in the past to get in contact with the community.
One approach that I like to ensure that something important is moving forward is to give it regular attention. So to work on this inside the Mindshare committee, I would make it a repeating topic for each week and ask all members to do one thing to improve it each week – it can be something simple like a short post to social media, on a blog or replying to some discussion that has some relevance to it or moving a longer idea a little bit forward.
I would like to contribute my perspective to contribute to a better quality of the commitee’s output.
The post Mindshare election: Interview with Till Maas (till) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:55 PM
This is a part of the Mindshare Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I have/still help out with moderation at discussion.fp.o and ask.fp.o as well as general support for users where I can.
I am also an editor for the Fedora Magazine and have written some posts for it as well, which makes me a part of Mindshare in any case. Though I don’t edit as much currently. I have also helped out a bit with Silverblue documentation early on, though Alan Day is doing a great job at it now for sure.
I started my Fedora journey as a Fedora Ambassadors and learning all about Fedora values, “How to become a successful Fedora Ambassadors “. All Community members from the Fedora Ambassadors team welcomed me, warm Just like my motivations to moderate forums, write blog posts about Fedora stuff, and help with documentation, I feel I get way more from the community than I give in return. This is as much a part of my personality as my smile, and I am driven internally to satisfy that compulsion to assist in the community. This really stems (in the Fedora POV) from the foundation of Fedora the community, with those four principles, that were true enough when first proposed by like minded individuals, that their truth endures today.
By active engagement regularly with the community. Where the community in general, is meeting to discuss things Fedora related has spread a bit with the introduction of Matrix rooms, and discussion and ask on Discourse. Being active across those areas plus IRC and mailing lists takes time and a bit of dedication. Since I have done some editing for Fedora Magazine, I would definitely suggest we create a post for it detailing what Fedora Mindshare is, who is in the group, how the community can use this resource, and anything else that should be noted about Fedora Mindshare.
Personally, I would like to be able to help out wherever I am needed and can exploit my knowledge/experience, though selfishly I would embrace learning new things because I enjoy learning new things! My background is pretty diverse as far as career path is concerned. Though primarily a technician/technologist I have soft skills developed in roles like PM and supervision, as well as documentation and presentation experience. I think I can use all of my skills to assist the Fedora community, and am comfortable working alongside many different workgroups. I envision the role with Mindshare is a facilitator role, for the diverse workgroups that exist as part of the Fedora Community. Enabling cross communication and sharing of ideas, platforms, knowledge, diversity.
The post Mindshare election: Interview with Stephen Snow (jakfrost) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
As a long-term community member, contributor in various areas of the Fedora Project, and long-term user of Fedora Workstation and Server, I think that I bring an important perspective to the discussions and decisions that FESCo regularly makes. I am excited by the recent success of Fedora Linux in general, and I want to make sure that this success is sustainable.
I make regular contributions to the Fedora Project in different areas:
Even though I had concerns about this in the beginning, I think this has been handled well so far. Most contributors to Fedora packages have not needed to know or care about ELN at all, unless they want to – and I think we should work
to keep it that way. For those who want to contribute to what the next version of RHEL will look like ELN should be an approachable way to do that, but for all others who do not care about that, it should not negatively affect their work.
I think the decisions that go into which packages are included in ELN rebuilds are somewhat opaque. For example, some of the packages I maintain are included, but their automatic rebuilds always fail – probably because there is no person who is responsible for Rust libraries on the ELN / RHEL side. This does not directly affect me and my work, but it is annoying and creates notification spam, and situations like this should probably be improved – either by more
regularly monitoring the list of included packages, or by more closely paying attention to regular build failures.
A hot dog is a sandwich. No pineapple, and definitely not on Pizza.
The post FESCo election: Interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I think I bring a important historical perspective to FESCo, telling newer members what has been tried in the past and what works and doesn’t work.
I’m currently employed by Red Hat in the CPE team to lead Fedora Infrastructure. In my spare time though, I maintain tons of packages, and am active in a number of sigs and groups in Fedora. I try and help folks as much as I can.
I think Fedora ELN is a great idea, allowing us to provide more value to enterprise linux projects. I don’t think our balance needs to change from what it has been. Integrating the latest upstream and innovating as we can for our community and consumers. ELN will follow along and if adjustments are needed, RHEL engineering can convince Fedora it’s good for them too, or make the changes downstream of ELN just as they always have. ELN just allows them to keep rawhide in a more consumable state.
I think it’s great, I think the eln-extras proposal is good and will increase/improve things. I’d leave further changes up to the ELN sig.
My positions are probibly pretty well known by now, but I think we should try and drive forward as fast as we safely can do so. Fedora has always led the way, and we should keep doing so.
Happy to talk with anyone on my positions on anything.
The post FESCo election: Interview with Kevin Fenzi (kevin) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I have served in FESCo for three years now and I’d like to continue to do so.
At FESCo, my mission is to make sure that our engineering community (Fedora and EPEL packagers and developers, both within Red Hat and outside of Red Hat) are not left out from the decision-making process, that every opinion is heard and everybody has been given space to express their technical opinion.
I also want to make sure that our policies are up to date and serve the purpose they were designed for. If we have a bad policy, we should strive to amend it rather than ignore it or bypass it. In the past, I’ve participated in updating the non-responsive maintainer policy and the policy for packages that fail to build and/or install. I’ve been working with releng to make sure we follow these policies and I’ve collaborated with the Program Manager to amend the Change process to include the feedback section. Work like this is never finished, but I’d like to continue it because it’s necessary to keep Fedora fresh and relevant.
When we vote about changes in Fedora, I always evaluate the feedback the proposal received on the devel mailing list. That’s where I believe most of the discussions should happen instead of inside the FESCo tickets or small private silos. When a change proposal impacts parties that were initially left out of the discussion, I try to circle back to include them. When an already accepted and implemented proposal turns out to negatively impact the work of Fedora packagers, I work hard to return things to a working state once again and to prevent future breakages.
I don’t claim to deeply understand every technical aspect of all the software in Fedora. Sometimes I don’t even have an opinion of my own about the proposed change. However, in all cases, I evaluate the impact of the change on our users — both external (users of the distro) and internal (our contributors).
I work at Red Hat in the Python Maintenance team and I’m a member of the Python SIG. I’m mostly taking care of the Python ecosystem in Fedora as an upstream for RHEL and CentOS. Besides Python SIG and FESCo, I am also a member of the Fedora Packaging Committee (FPC), 3D Printing SIG, Xfce SIG, and the Lua Packager SIG.
As a Python maintainer and a meta-packager, I invent and maintain new packaging macros and automation, mostly for (but not limited to) the Python ecosystem, so that our packagers can leverage new technical possibilities in the packaging world. I make sure to backport all such improvements to EPELs, whenever technically feasible, to ensure our EPEL packagers can keep maintaining more or less compatible spec files. To make this all technically possible, I am also a provenpackager and I’m actively sponsoring new packagers. I’ve been packaging for Fedora since Fedora 17, and I’m now taking care of close to 200 packages directly and hundreds more through the Python SIG.
I have two overreaching goals. First, my goal is to make the packaging experience better by improving the tools our packagers use. I feel this is more important than revolutionizing the packaging technology. And second, my goal is to make Fedora the best operating system for developers. To that end, I’m participating in various upstream decision-making processes (for example in various projects throughout the Python ecosystem) to make sure that on Fedora, Everything Just Works
.
I am also in charge of the day-to-day execution of some of the not-yet-fully-automated Fedora policies, making sure our package ecosystem remains in a healthy state.
And lately, I’ve been trying to get more involved in packaging for EPEL 9 Next, so I can help bootstrap and maintain some of the essential Python tools for CentOS Stream 9 and to allow future EPEL 9 packagers to enjoy the benefits of the ever-improving Fedora Python RPM packaging.
I am very proud of the upstream shift that we have seen in RHEL 9 development and even more excited about the possibilities for the future. I think delivering changes in Fedora first should be the only encouraged workflow, as exceptions to this rule tend to only bring more technical debt. For example, we still have packages in Rawhide today that fail to build with OpenSSL 3, while they were fixed months ago in CentOS Stream 9.
I would like to see a larger involvement of RHEL package maintainers in Fedora processes and better awareness of our policies and standards. For example, I’d like to avoid situations where RHEL packagers were pushing changes only suitable for Rawhide to Fedora 34 after the Beta release, just because they assumed this is necessary to land them in RHEL 9. Hopefully, this is now getting better, but I will keep doing my best to improve the situation. I’d also like to see more RHEL packagers taking active maintainer roles in their corresponding Fedora components, instead of saying “we maintain this in RHEL, not in Fedora”, and more support from managers for such upstream work.
One thing I’d like to see more of in ELN is leveraging it for possibly breaking changes that both Fedora and RHEL want but Fedora Linux is not yet ready to deliver. For example dropping support for old hardware. On the other hand, I wouldn’t like for ELN to become the space for things that we would not even consider for future Fedora Linux or things that we have already tried and failed in the past.
While ELN is “like RHEL”, I believe it should be governed by Fedora (with RHEL needs in mind), rather than directly by Red Hat. For ELN to remain relevant in RHEL development, it must be useful for Red Hat, but for it to remain a successful forward-thinking project within Fedora, the decision process must remain open. The transparency of the ELN SIG that I see today is a great way to achieve that.
See the previous answer. My suggestions to improve it were communicated on the devel mailing list and on various occasions where I met with the members of the ELN SIG:
%if conditionals in their spec files or those that need different CI configuration for Rawhide and ELN can achieve that. However, this is a very complex problem.I’d love to see more packagers using the pull request workflow because I want us to test our changes (via CI) before we merge them. And I’d love to see an environment where we don’t perceive the package maintainers as owners, but rather curators of the content set we provide to our users. These two concepts can work great together: Ultimately, I imagine a future where everyone can contribute anything, anywhere, pending a semi-automated, semi-manual review from other packagers, without the need for a provenpackager or a release engineer to be involved.
You could also read my previous interview from November 2020 (from which I adapted some paragraphs for this interview as well).
The post FESCo election: Interview with Miro Hrončok (churchyard) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
[Parts copied directly from 2020 and 2019… Clearly some things change slowly.]
I see the role of FESCo as a place where all voices are heard so that a consensus decision can be reached. It is individual community members, SIGs, and other groups who should propose and implement changes. I see the role of FESCo in making sure that questions about purpose, backwards compatibility, user experience, schedules, and contingency plans are asked and answered. I think it’s totally fine when the majority of decisions by FESCo is unanimous after that.
Overall, I think Fedora is in a good place. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. Each of the last few releases has been well received by the press and users.
The part I worry about is where we go from here: I would love to see Fedora more widely used, with more packages delivered more reliably. To make that happen, we should automatize packaging: we have been working on package gating for a long time, but updates that don’t even install are still being pushed. Each and every package update should go through basic installation/uninstallation/upgrade tests (like Debian’s piuparts). This should be implemented at the global level: individual packages may add custom tests, but the basics should be tested without any additional work. Crucially, if the package fails some test, the results need to be provided in a human-readable manner. Unreliable results and unreadable reporting of failures are currently the weakest parts of our CI story.
Once we have reliable update testing, it becomes reasonable to do package updates automatically. At least for Python and Rust packages we’re moving towards a model where upstream metainformation is fully sufficient to build a package in Fedora (including versioned dependencies and subpackages and package descriptions), and the .spec file is just a thin wrapper. We’ve been hacking away at the problem (with release-monitoring.org, rebase-helper, packit, forge macros, rpm’s %generate_buildrequires, tarball signature verification, pyp2rpm, rust2rpm, rpmautospec, source-git, and so on), but we’re not there yet: packaging involves a lot of manual drudge work. I expect that 80% of packages could be “maintained” through automated updates and testing, freeing our maintainers to spend more time on the remaining “hard” packages, improving tools, and fixing more complicated bugs. I also think automated packaging (not bundling or modules) is the only reasonable way to deal with language ecosystems like Rust or Go where hundreds or thousands of packages are pulled in as dependencies.
To achieve those goals without sacrificing quality, our tooling needs to improve across the board. We also need more people. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.
I think it is important for FESCo to remain receptive to new ideas. For example, I think that the process to switch to Btrfs as the default file system was performed correctly: we discussed things in great detail, but at some point the technical evaluation showed more plusses than minuses, and even though some people still had reasonable concerns, the choice was made and implemented. I hope we do the same with other bold ideas in the future.
I’m active in systemd upstream, and I’ve been doing systemd package maintenance in Fedora since 2013; if you’ve submitted a systemd bug in Bugzilla or in the upstream bugtracker, chances are I’ve looked at it. I maintain a few dozen packages, and I try to do new package reviews regularly (436 so far). I’ve been in FESCo since F28. I’be been involved in various initiatives, like the transition of various upstream to Python 3, mass rename of Python 2 packages during the transition to Python 3, improvements to packaging tools (rust2rpm, rpmautospec), transition of the packaging documentation from the wiki, updating of Packaging Guidelines for new techniques. I try to help with all aspects of packaging, but I’m especially interested in mass cleanups and automatization of various packaging processes.
Red Hat is our closest downstream, but over the years the separation between Fedora and RHEL packaging has slowly increased. This is visible in the number of RedHatters who are involved in Fedora packaging — this number hasn’t substantially changed over the years, while Red Hat itself has grown, and the number of packages in Fedora has also increased.
I consider ELN to be a big opportunity for Fedora. It is better for us when the downstream work is done closer to Fedora, when new ideas are hatched in the open and in close cooperation with upstream, and when the pool of people who can help with maintenance in Fedora is increased. The biggest risk with ELN would be if downstream requirements and practices had too much influence on Fedora packaging. But so far this doesn’t seem to be much of a problem: the work that is done for ELN is clearly separated.
I hope that we can keep a balance where anyone who wants to be involved in ELN and/or rawhide packaging can do so, in particular many of the RHEL maintainers who so far were not active in Fedora until now, while other maintainers who only care about the Fedora side can ignore ELN. Such a split has been working just fine with EPEL packages, and I expect the same will happen with ELN.
Automatism and smooth rebuilds in ELN are key to keeping the friction with working on ELN to the minimum. A lot of progress has been done in this regard since ELN was initially introduced, but things still occasionally get stuck, in particular with big mass rebuilds. ELN should be completely automatic, and maintainers should only need to get involved when they want to purposefuly make something different than in Fedora.
ELN will prove its worth when the next version of RHEL is released.
Things that I expect to happen in 2022 in Fedora packaging:
Things that I would love to see, but I don’t see a clear path forward:
The post FESCo election: Interview with Zbigniew Jędrzejewski-Szmek (zbyszek) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I have a background in compilers and toolchains, and I would like to use some of the knowledge I’ve gained over the years of building and troubleshooting applications to help make Fedora better. Specifically, I’m interested in helping packagers avoid common mistakes through standardized macros and packaging practices and also by increasing the reliance on CI.
I’m currently one of the maintainers of the LLVM packages in Fedora which are a set of 14 packages that provide C/C++/Fortran compilers as well as a set of reusable compiler libraries that are used for developing other languages and for developer tools like IDEs.
I’ve also worked on system-wide changes to help standardize the use of make within Fedora packages. These changes helped to make spec files more consistent across all of Fedora and also made it possible to remove make from the default buildroot.
One of the things that has always impressed me about the Fedora Project is how well structured and documented the decision making processes are. For me, the best way to balance RHEL engineering with the community is to lean on those processes and ensure that any change proposals, not matter where they come from, all follow the same objective decision making processes.
I am a big fan of Fedora ELN. I would like to see its tooling be generalized so that it is easy for anyone to create their own Fedora derivative. I think there is a lot of value in having an alternative buildroot to experiment with and to try out new features. ELN plays this role for RHEL, but I think we could create other alternative buildroots to test out new features for Fedora too.
I work for Red Hat on the Platform Tools team. I am the technical lead for our LLVM team and the overall technical lead for the Go/Rust/LLVM compiler group. This means that I work on packaging, bug fixing and upstream feature development for LLVM and work on high-level technical issues common across all 3 compilers.
The post FESCo election: Interview with Tom Stellard (tstellar) appeared first on Fedora Community Blog.
admin)
on November 25, 2021 11:50 PM
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
I want to continue to be part of FESCo because I genuinely enjoy the work and want to continue helping Fedora lead from an engineering perspective. Making sure Fedora remains a top preferred Linux development platform and a system usable by a wide range of users is important to me. For me, I feel FESCo is one of the best places I can provide that help.
I wear many hats. I maintain several packages in Fedora and EPEL. I am also the upstream author and maintainer of several projects where I am also the package maintainer. I am the Engineering Representative on the Fedora Council, where I represent FESCo and general engineering interests and questions for the Fedora Council. Finally, I am a provenpackager and try as best as I can to mentor new contributors.
I also read a lot of the mailing lists. I spend a lot of time reading the devel and test lists. I try to read every thread and stay up to date on what’s happening in the project. I comment and answer questions when appropriate, but one of the best things contributors can do is read and listen.
Lastly, I’m not just a Fedora contributor, I’m also a Fedora user. I run stable and rawhide releases and report bugs and try to help patch problems where I find them.
Speaking as a Red Hat engineer, I like ELN because it lets me see if packages in Fedora are building correctly for RHEL. The rate of change in Fedora is much faster than RHEL, so as we update packages in Fedora, knowing that those updates can build “the RHEL way” without having to wait for a new major version of RHEL to start is a huge benefit. I also like that it gives community visibility to how package builds differ in RHEL vs. Fedora.
As a Fedora engineer, I like that Red Hat incorporates this work upstream into Fedora rather than keeping it internal. It allows community participation and will enable Fedora to see how a significant downstream user of Fedora includes packages. That information can help the Fedora package maintainer retain the necessary flexibility for RHEL.
The way ELN has been working so far has been excellent because it has not added any additional work for me as a Fedora or RHEL package maintainer. Instead, it has provided additional information.
My view of ELN so far has shown that it has not added any significant work for package maintainers. Instead, it provides information and offers a mechanism for participation. I want this to continue.
I do not want ELN to become a release, and sometimes there may be confusion around that. We should continue to communicate what the expectations are for ELN.
Stability and migration plans are essential to me. Fedora usually does an excellent job with this, but for new features, I often ask myself (a) is the feature well-tested and (b) what is the migration path for users. Well-tested means there is a test plan (or even a test suite) and an objective for testing. Fedora is great about integrating new features, but we also want to make sure we plan to test those well to ensure they work. By migration paths, I mean for things that introduce
a significant system change, how will existing users migrate to the new functionality? In some instances, it is not possible, but most of the time, it is. It could be a matter of documentation or providing compatibility symlinks or something similar. We want new features, but we also want to make sure we do not alienate existing users.
I also want to continue working towards making the development environment and contribution environment for Fedora better. For example, could we use additional documentation? Could a tool be improved? What can we learn from other distributions, and is that applicable to Fedora?
Lastly, I spend far more time listening and reading than I do speaking. When new ideas surface, I assume good intent and begin reading and listening with an open mind. After that, I ask questions.
The post FESCo election: Interview with David Cantrell (dcantrell) appeared first on Fedora Community Blog.
RC6 was GOLD, so version 8.1.0 GA is just released, at planed date.
A great thanks to all developers who have contributed to this new major and long awaiting version of PHP and thanks to all testers of the RC versions who have allowed us to deliver a good quality version.
RPM are available in the remi-php81 repository for Fedora ≥ 33 and Enterprise Linux ≥ 7 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository.
RPM are also available in the php:remi-8.1 module for Fedora and Enterprise Linux ≥ 8.
Read the PHP 8.1.0 Release Announcement and its Addendum for new features detailed description.
Installation: read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.
Replacement of default PHP by version 8.1 installation (simplest):
Fedora modular or Enterprise Linux ≥ 8:
dnf module reset php dnf module install php:remi-8.1
Fedora or Enterprise Linux 7:
yum-config-manager --enable remi-php81 yum update php\*
Parallel installation of version 8.1 as Software Collection (x86_64 only, recommended for tests):
yum install php81
To be noticed :
Information, read:
Base packages (php)
Software Collections (php81)
tl;dr: if you’re using libfwupd to download firmware, nothing changes and everything continues as before. If you’re using something like wget that doesn’t follow redirects by default you might need to add a command line argument to download firmware from the LVFS.
Just a quick note to explain something that some people might have noticed; if you’re using fwupd >= 1.6.1 or >= 1.5.10 when you connect to the LVFS to download a firmware file you actually get redirected to the same file on the CDN. e.g. downloading https://fwupd/download/foo.cab gets a redirect to https://cdn.fwupd/download/foo.cab which is then streamed to the user. Why this insanity?
As some of you know, egress charges from AWS are insanely high. The Linux Foundation are the kind people that kindly pay the LVFS bill every month, and a 4 years ago that was just a few hundred dollars and that was a rounding error to them. Last year we again grew at more than 100% and the projection for next year is going to surpass even that; the average size of firmware files has gone from ~30MB to ~50MB with much, much, larger server firmware in the pipeline. We certainly can’t watch the egress bill scale linearly with the LVFS popularity, else some accountant at the Linux Foundation is going to start asking questions – especially when Fastly provides the LF a geo-replicated CDN – which we’re not using.
So why don’t we put the CDN URL in the XML metadata directly, and then avoid all this redirect complexity altogether? This time the lawyers get us, as we’re required by US law to restrict distribution of some firmware to some countries on an embargo list. It’s very complicated, and it varies by vendor, but it’s not something we can avoid. So for this reason, the LVFS does a GeoIP lookup on the client IP, and if it’s all okay we then redirect the client to the CDN-cached version. It also lets us tell the vendor how many times the firmware has been downloaded without importing the CDN logs every 24 hours – which would be even harder as we only keep them for a short time for privacy reasons.
We are pleased to announce a new release of Valgrind, version 3.18.1, available from http://valgrind.org/downloads/current.html.
3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new platforms x86/FreeBSD and amd64/FreeBSD. Debuginfo reading is faster, and Rust demangling has been improved. For PPC64, ISA 3.1 support has been completed, and some newer ARM64 and S390 instructions are also supported. See the release notes for details of changes. Note, 3.18.0 had no formal release — it was pulled at the last minute due to a packaging problem.
Our thanks to all those who contribute to Valgrind’s development. This
release represents a great deal of time, energy and effort on the part of many people.
Happy and productive debugging and profiling,
admin)
on November 25, 2021 03:27 PM
This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
The datanommer and datagrepper stacks are currently relying on fedmsg which
we want to deprecate.
These two applications need to be ported off fedmsg to fedora-messaging.
As these applications are ‘old-timers’ in the fedora infrastructure, we would
also like to look at optimizing the database or potentially redesigning it to
better suit the current infrastructure needs.
For a phase two, we would like to focus on a DB overhaul.
Duffy is a system within CentOS CI Infra which allows tenants to provision and
access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the current state
of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.
Move current Fedora CoreOS pipeline from the centos-ci OCP4 cluster to the newly
deployed fedora infra OCP4 cluster.
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.
Kindest regards,
CPE Team
The post CPE Weekly Update – Week of November 22nd – 26th appeared first on Fedora Community Blog.
This post will be short. Recent FreeIPA versions contain ACME server implementation, which makes TLS certificate issuance a breeze.
FreeIPA is a solution giving you LDAP for user accounts, CA for issuing certificates and Kerberos for SSO, delivered with nice WebUI in an integrated package.
Automated Certificate Management Environment is a protocol designed to automate process of getting a TLS certificate. It was popularised by Let's Encrypt, BuyPass, Venafi and others.
When you have FreeIPA, you have your own Certificate Authority. It is most sensible to use it for securing your internal endpoints. Your clients should already trust this CA. Your internal network may not be reachable by external ACME providers. And you may want to hide your internal hostnames from appearing in global Certificate Transparency Databases.
Ready to start? Make sure package pki-acme is installed on you FreeIPA server. Next, enable ACME functionality:
$ ipa-acme-manage enable
The ipa-acme-manage command was successful
Done! Now configure the client – for my k8s I'm using awesome cert-manager. Start with definition of a ClusterIssuer with your FreeIPA URL (put you own email and server address, of course):
--- kind: ClusterIssuer apiVersion: cert-manager.io/v1 metadata: name: pipebreaker-freeipa spec: acme: email: tomek@pipebreaker.pl server: https://ipa-ca.pipebreaker.pl/acme/directory privateKeySecretRef: # Secret resource that will be used to store the account's private key. name: issuer-pbrk-account-key solvers: - http01: ingress: {}
Second (and last) step is to annotate each ingress which should get a TLS certificate automatically provided:
--- kind: Ingress apiVersion: networking.k8s.io/v1 metadata: annotations: cert-manager.io/cluster-issuer: pipebreaker-freeipa […]
And that's basically it. After few moments certificate should be issued:
When using cert-manager, make sure it's version 1.6.0 or later. There was a fix for ambiguity in spec which solved some interoperability problems with FreeIPA implementation. The fix may be backported for older cert-manager releases.
dchen)
on November 25, 2021 12:02 AM
I have scripts that will utilise the SFDC case number, but why type it manually when the computer can do it?
Firstly, you need to have xdotool installed, for RHEL or CentOS Stream, it is in EPEL. I have tried xprop and xwininfo, but they do not accept search with WM_Class
Secondly, get the WM_Class of the X program, usually it is just the program name. If you are unsure, open that X program, then run xprog and click at the X program, then search WM_CLASS amongst the output.
Thirdly, for X program that has multiple tabs, make sure you activate the tab you want.
Now, to get the active title of firefox:
for i in $(xdotool search --onlyvisible --class firefox); do xdotool getwindowname $i; done
Two titles will be shown like:
Firefox
The actual title
For me, I am only interest in the number which are in the beginning of the title, so my command is:
for i in $(xdotool search --onlyvisible --class firefox); do xdotool getwindowname $i; done | sed -rne '/^[0-9]+/ s/^([0-9]+).*$/\1/p'
Toolbx now has its own room on matrix.org. Point your Matrix clients to #toolbx:matrix.org and join the conversation.
<figure class="wp-block-image size-large">
</figure>
We are working on setting up an IRC bridge with Libera.Chat but that will take a few more months as we go through the process to register our project channel.
<script> __ATA.cmd.push(function() { __ATA.initDynamicSlot({ id: 'atatags-26942-619e23e613dc7', location: 120, formFactor: '001', label: { text: 'Advertisements', }, creative: { reportAd: { text: 'Report this ad', }, privacySettings: { text: 'Privacy', onClick: function() { window.__tcfapi && window.__tcfapi( 'showUi' ); }, } } }); }); </script>
admin)
on November 24, 2021 08:00 AM
For a piece of software infrastructure, nothing is more important than good applications to showcase it’s features and demonstrate the possibilities it enables. Fortunately there is a very large body of existing applications because PipeWire implemented the PulseAudio and Jack APIs. This article highlights some of the great efforts undertaken in the community around creating interesting applications for PipeWire in an interview with the maintainers of two of the most popular applications built with PipeWire. They are Wellington Wallace, maintainer of EasyEffects for PipeWire and Tom Wagner, maintainer of the Helvum patchbay application for PipeWire.
Christian Schaller: First of all thank you both for taking the time to talk with me. I am really excited about your projects and I know a lot of people in the PipeWire community are too. So let’s start with introductions, tell us a little about yourself and how you got involved with open source development.
<figure class="wp-block-image">
<figcaption>Screenshot the Helvum patchbay in action </figcaption></figure>
Tom Wagner: I am a 7th semester Computer Science student at the Technical University Berlin, currently working on my Bachelors degree. My first real contact with Linux was in my school, where the computers ran Linux Mint.
I started using Linux on my personal devices a few years later, because at that point I already had some experience with it and because I became increasingly annoyed by Windows.
After some smaller contributions to different open source projects, looking for a project to work on, I found PipeWire and started working on Helvum and PipeWires Rust bindings.
Wellington Wallace: I am a physicist currently working as a professor in a Brazilian federal education center called Centro Federal de Educação Tecnológica Celso Suckow da Fonseca. My first contact with Linux happened in the computational physics lectures I attended at the beginning of my studies. From that moment on Linux became the only operating system installed on my computer. But it was only some years later that programming became part of my day to day life.
The focus of my PhD was experimental physics. In order to understand the measurements I did about magnetic nanoparticles I started to do Monte Carlo simulations. First in Python and after some time in C++. But, as it was the kind of simulation that took many days to finish, I eventually started to use OpenCL.
My first open source project was a tool to make graphs in my experimental physics classes. But the one where I really felt I was contributing with something unique to the open source community was PulseEffects. This later became EasyEffects when I switched to PipeWire. The project started one day when Pulseaudio suddenly stopped playing audio in one of the channels. I could have tried to fix the problem but the truth was that I wanted more than just an equalizer. That was how PulseEffects was born. Although I expected it to be useful for some people I did not think this project would get so big.
Christian Schaller: Could both of you give us a short introduction to your project and what it does, for those who might be unfamiliar?
Wellington Wallace: EasyEffects(formerly known as PulseEffects) is a tool that allows the user to add global audio effects for applications. Among the possibilities are dynamic range compression, equalization, automatic volume control, noise reduction, bass enhancement, etc. Besides applications output, users can add effects for microphones too.
Tom Wagner: PulseAudio is mostly designed to have applications receive audio input from one single input device and/or send audio to a single output device, which makes it difficult to adapt to more complicated use-cases.
Contrary to PulseAudio, PipeWire runs a full media graph. This means that audio and other kinds of media can be freely routed between any number of devices and even to other applications at the same time.
For example, you could route the audio output of your music streaming software to your speakers as well as your voice-chat software to listen with others, while routing the audio and video of a game to a recording software to make a recording without the music in it.
Helvum is a GUI to do exactly this: create and delete connections between devices and/or programs to route data through the system in exactly the way you want it.
Christian Schaller: Wellington, so EasyEffects started out as an application targeting PulseAudio, but you switched it over to PipeWire relatively early on. What made you decide to jump on and target PipeWire with EasyEffects?
<figure class="wp-block-image">
<figcaption>Screenshot of EasyEffects in action</figcaption></figure>
Wellington Wallace: Actually, between the first time users asked for PipeWire to be supported and my move to do that, took about 2 years. It may seem, for some people, that it was early. But almost all that we needed was already available.
Besides the usual “low latency” argument people give when talking about PipeWire, there were other reasons that were important from an application implementation point of view. Pulseaudio does not offer a way to naturally do the kind of processing we do. There is no support for third party plugins in Pulseaudio that could be used to write filters. What is done in PulseEffects, in a way, is a hack. I had to “take the audio away from the server” so I could process it in GStreamer. After everything was done I had to send the result to Pulseaudio. It may seem simple but that approach had lots of problems with clock drift in the beginning. Audio got out of synchronization so fast that I almost gave up on the project. It took lots of attempts with different GStreamer configurations until I found a way to make the clock drift negligeable.
In PipeWire the whole process feels natural and the filter API is super simple. Way easier than writing GStreamer plugins. Handling the pipeline is a lot easier too. I like GStreamer but sometimes removing or inserting plugins from/to its pipeline on the fly can be a nightmare….
Another thing we get for free on PipeWire is realtime priorities in the filter thread. On Gstreamer I had to handle that myself. That was mostly fine. But, since Flatpak did not have RealtimeKit support, people using PulseEffects through Flatpak could not have realtime priorities in our audio thread.
Another reason that indirectly contributed to the early adoption was the release of gtk4(gtkmm4). The combination of Pulseaudio and GStreamer did things in a very different way when compared to PipeWire. Moving from gtkmm3 to gtkmm4, while keeping Pulseaudio and GStreamer, would make me work twice in some places once the move to Pipewire was made. If I had to change the graphical interface anyway it is better to do it once using the new audio server.
Christian Schaller: Tom, so Helvum is a brand new application written explicitly for PipeWire. What was your motivation for starting this project?
Tom Wagner: I used to play World of Warcraft and wanted to record my guilds raids with separated game and voice chat audio tracks so I could mute the voice chat for some clips and keep them for others.
This was fairly complicated and painful with PulseAudio, where I had to do some complicated setup of creating multiple virtual loopback sinks to first record these audio streams separately and later combine them to send them to my headphones.
I was looking for some open source project to contribute to, and became interested in PipeWire, where this could be achieved much easier by rerouting the media graph.
Back then, there was no native PipeWire patchbay, so you had to rely on JACK tools.
While those could be used to route audio and MIDI through a compatibility layer, JACK and therefore any JACK tools can’t handle video, so as my contribution to the open source community I started work on PipeWire Rust bindings and, using those, came Helvum.
Christian: Wellington and Tom, what has your experience been working with Wim Taymans and the PipeWire community so far?
Wellington Wallace: I consider it a good experience. Whenever I need help to get things done in PipeWire Wim Taymans responds reasonably fast. Especially when considering the amount of work he has on his hands now.
Tom Wagner: It’s been great so far. The IRC channel (#pipewire on OFTC), including Wim, is always able to answer any questions that come up quickly, and we already had many great contributions to both Helvum as well as the Rust bindings.
Christian Schaller: Wellington, so what are your plans for EasyEffects going forward? What do you see as the next steps for EasyEffects?
Wellington Wallace: At this moment I am in the process of using gtk4 API directly. GTKMM has served us well but now that I want to use LibAdwaita it will be more straightforward to talk to gtk4 directly. It is not the first time I do something like that. I started this project in Python. Its gtk wrapper is good but eventually it got in the way. And now the same thing is happening with gtkmm.
Besides that there are 2 more things that are on the horizon but for which I do not have a solution yet. The first is adding support for multiple instances of a given filter. For example some people would like to have more than one equalizer instance in the pipeline. At this moment this is not possible. Another rough edge in EasyEffects is the lack of upmixing from stereo to surround devices. But I still think that some of the work required for that would also have to be done on PipeWire.
Christian Schaller: And Tom, where do you plan on taking Helvum from this point forward?
Tom Wagner: At the moment, to configure things such as volume, default audio devices etc. via GUI, the best way is still via PulseAudio applications such as pavucontrol.
I’d like for Helvum to become a full PipeWire management interface, able to handle all these use cases natively.
There are also many quality-of-life improvements such as zooming and better scrolling that are still missing.
Christian Schaller: Tom and Wellington, what do you like the most about PipeWire and do you have any wishes or feature improvements you would like to see from PipeWire?
Tom Wagner: The best thing about PipeWire for me is definitely its flexibility and versatility.
It allows routing data through the system any way you want, even between PulseAudio and JACK applications, without any trouble. It lets power users run their audio with minimal latency, and still remains a drop-in pulseaudio replacement even for casual users.
From my perspective, PipeWire is already in really great shape, and while there can still be some issues, especially with less common setups, it keeps getting better with each release.
Wellington Wallace: Some of my thoughts on that are scattered in my previous comments. It has a simple API that fits our needs and the latency is low enough. Another thing I consider important is a short release cycle. Pulseaudio takes too long to make new releases. I understand that it is an old project by now but I saw in the past some annoying bugs being fixed in Pulseaudio’s development branch that took forever to get to the users. I hope that PipeWire keeps the current approach where releases are done more frequently.
About the improvements, it depends on the point of view. Thinking about it as a user I think PipeWire still has some rough edges when it comes to on-the-fly device connection/disconnection. Like headphones, for example. It still resets volumes to 100% or mutes them in cases that Pulseaudio did not do. It is not often that this happens. But it still happens.
From the EasyEffects point of view I think that the process available to link filters needs some love. Right now if a filter has to link to a surround, or any other device that has a different number of channels, the whole upmixing/downmixing process becomes the audio clients (EasyEffects) responsibility. As I do not have the knowledge for that, the current situation is that there is no upmixing or downmixing being done in these cases. We did a few attempts with the loopback module but it does not fit very well with how we do things. It also generates additional streams that will only confuse the user and increase the chances our audio routing is broken by something that decides to move the loopback streams somewhere they should not be. In an ideal world I would like to have a way to just tell PipeWire “link this filter’s channels to this input/output device and do upmixing/downmixing if necessary”.
Christian Schaller: So if anyone wants to contribute to either Helvum or EasyEffects what is the best way to get started and get involved?
Wellington Wallace: Up to now 65 people have contributed in some way to EasyEffects(PulseEffects). In all these cases either a pull request was done at https://github.com/wwmm/easyeffects or an issue was opened to discuss things first. In many cases people contributed only with an idea. If it is something that can be done and is compatible with how EasyEffects works, I or someone else usually implements it when time is available.
Tom Wagner: Similar to EasyEffects, reporting any problems or pet peeves to the issue tracker already goes a long way towards improving the application.
From there, anyone can start work on a Merge Request to fix the issue. Any questions and requests for help are also welcome there, and I’ll do my best to answer them.
Christian Schaller: Are there any projects you would like to see started with PiperWire that you feel are clearly outside the scope of your application?
Tom Wagner: Anything that involves processing the actual data that is being sent is definitely out of scope. For example, people have already asked for support for hosting plugins such as VST and OFX plugins. These would be better handled by a separate app, as the focus for Helvum is on controlling the PipeWire server, not the data being routed through it.
Wellington Wallace: I think that what Helvum is trying to achieve is exactly the kind of thing I have always considered out of EasyEffects scope. I want to focus on providing as many useful effects as possible in a way that is flexible enough for advanced users without making new users too scared. Managing devices, like Pavucontrol does for Pulseaudio and to some extent to PipeWire, is something that another application should do.
Christian Schaller: Tom, from what I know, you are a Fedora Linux user. What has made it your distribution of choice?
Tom Wagner: Yes, after a while of using Arch, I wanted something that works well out of the box, and after trying a number of different distros I stayed with first Fedora Workstation and now Fedora Silverblue.
I love how up-to-date yet stable and polished everything is in Fedora Linux. For Silverblue, specifically, I love how I can let it update in the background without any fear of things breaking and then reboot into the new updated version later without any waiting, and rollback to a previous deployment or even reset to a pristine state if I break something.
admin)
on November 24, 2021 08:00 AM
Some time ago I was thinking if it’s possible to rebase my ostree system from one to another and how difficult this is. After some thinking I decided to try it by rebasing Fedora 35 Silverblue on my gaming machine to Fedora 35 Kinoite. In this post I will write what I did and what difficulties I had along the road.
DISCLAIMER: This is not something that is supported by the Fedora KDE SIG so do it at your own risk.
First thing I needed to do is find the correct rebase target on Fedora 35 Silverblue.
$ostree remote refs fedora
I checked for the potential candidate and found the correct Kinoite entry.
fedora:fedora/35/x86_64/updates/kinoite
There are other options for Kinoite for different architectures or older versions of Fedora. You can even try to rebase to Fedora Core OS if you want. 
Rebase itself is similar to update to a new version of Fedora Silverblue. You just need to run the following:
$ rpm-ostree rebase fedora:fedora/35/x86_64/kinoite
And then reboot the machine.
So after reboot I was welcomed by kdm (KDE Display Manager) and logged in, but instead KDE I found out I’m in broken GNOME, which doesn’t work as it should. At the first sight I thought something went wrong during the rebase. But this was not the case. I checked the state of the rpm-ostree
$ rpm-ostree status
And I noticed that one of the layered packages I had for Silverblue is gnome-shell-extension-appindicator for tray icons in GNOME.
So I decided to remove it.
$ rpm-ostree uninstall gnome-shell-extension-appindicator
And rebooted.
After reboot I found out that the KDE is working fine. It looks like when layered package was applied above the ostree image it also added all the required GNOME dependencies, which broke the KDE.
But this wasn’t the end of it.
When looking for installed flatpaks using the search option from menu in panel I wasn’t able to find them. I was wondering why, so I started searching for this. After some search I came across this issue in flatpak: XDG_DATA_DIRS is not set on fish shell (at the time of writing this blog post this is already solved).
As you can probably guess by now I have fish layered above the base ostree image. For those who don’t know what fish is. It’s a really nice alternative to standard bash shell, so I like to have it. If you find to know out more about fish, I can point you to official page.
From what I was able to found out is that gdm (GNOME Display Manager) is doing the initialization of the desktop in bash and then switching to user defined shell. So everything applied in the initialization phase, like /etc/profile.d/ profiles, which is where the flatpaks directories are registered in the desktop, is run in bash. In kdm /etc/profile.d/ profiles are applied using the logged in user default shell and this didn’t work in fish, because the syntax is slightly different and the fish needs to have it’s own profile file.
To fix this issue, I changed my default shell to bash from fish using lchsh command, but to not lose the fish as a main shell, I set it as a default shell for tmux session. After this change the flatpak integration started working correctly!
The change itself was really easy and the issues I encountered were all caused by the packages I had layered above the base ostree image.
I’m still getting used to KDE, but it’s a nice experience. Just some struggle with multi-monitor setup, but multi-monitor setup is always struggle on any desktop environment.
The post Rebasing Fedora Silverblue to Kinoite appeared first on Fedora Community Blog.
I was interested in how much work a vaapi on top of vulkan video proof of concept would be.
My main reason for being interested is actually video encoding, there is no good vulkan video encoding demo yet, and I'm not experienced enough in the area to write one, but I can hack stuff. I think it is probably easier to hack a vaapi encode to vulkan video encode than write a demo app myself.
With that in mind I decided to see what decode would look like first. I talked to Mike B (most famous zink author) before he left for holidays, then I ignored everything he told me and wrote a super hack.
This morning I convinced zink vaapi on top anv with iris GL doing the presents in mpv to show me some useful frames of video. However zink vaapi on anv with zink GL is failing miserably (well green jellyfish).
I'm not sure how much more I'll push on the decode side at this stage, I really wanted it to validate the driver side code, and I've found a few bugs in there already.
The WIP hacks are at [1]. I might push on to encode side and see if I can workout what it entails, though the encode spec work is a lot more changeable at the moment.
[1] https://gitlab.freedesktop.org/airlied/mesa/-/commits/zink-video-wip
I love photography. I started taking photos four decades ago using a camera called Lubitel, a cheap Russian knock off of Rolleiflex. I switched from film to digital photography back in 2000, which was quite a bit earlier than most. I always treated mobile photography with strong skepticism (small sensor, too much processing, etc.) and have a dedicated camera with me everywhere.
Well, the problem is with the words “always” and “everywhere”. There can be many reasons why I do not have my camera with me:
However, I do not leave my eyes at home together with my camera. I never know when I’ll see some beautiful scenes while walking to the shop. Earlier I just took a deep breath that it’s a helpless situation and I went on, as I did not have a dedicated camera with me. Nowadays my view changed. Even if I do not have a real camera with me, I always have my mobile with me. As usual, there are exceptions here too: when I accidentally leave it in the charger :-)
Some of my favorite photos during the past few weeks were taken by my mobile phone. Yes, these photos are far from perfect from the technical point of view. But still, they captured the mood of the moment perfectly. And without my mobile I would have missed some nice moments of Autumn. So, using my mobile phone to take photos is still better than nothing.
<figure>
<figcaption>
<figcaption>
You can find some of my photos on Gurushots
eseyman)
on November 22, 2021 08:48 PM
I was at the Open Source Experience event in Paris, France last week.
While it was nice to see friends from the FLOSS community, it did feel that the general public decided to stay away, probably because Covid cases are on the rise in France again. I was manning a Perl booth but used the fact that we were 4 people to wander again and ask vendors if they would be willing to support their applications in Fedora. As you can probably guess, results were mixed...
The first person I talked to was Clément Oudot, maintainer of LemonLDAP-NG. He was more than willing to add LL-NG to the Fedora repositories. I then talked to Benoît Mortier, the main developer of FusionDirectory and he was also enthusiastic about doing the same.
My stops at the OCS-Inventory and Bluemind booths proved less fruitful. People on both booths told me they did not have the resources to support a distribution like Fedora that releases every 6 months.
I then found myself at the Dolibarr booth where I had a talk with Laurent Destailleur, Dolibarr's main developer. We talked a lot about Dolibarr's experience with having their software packaged in Debian and the troubles they had over the years with Debian's policies on bundling and upgrades.
Finally, I dropped by the Centreon booth and discussed a number of things (their use of Perl, automatic deployment, distribution support). The Centreon people are looking to diversify the distributions they support and they seemed open to supporting Fedora Server as well as other distributions.
ankursinha)
on November 22, 2021 09:25 AM
Photo by William White on Unsplash.
Please join us at the next regular Open NeuroFedora team meeting on Monday 22 November at 1300UTC in #fedora-neuro on IRC (Libera.chat). The meeting is a public meeting, and open for everyone to attend. You can join us over:
You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:
$ date --date='TZ="UTC" 1300 2021-11-22'
The meeting will be chaired by @vanessa_kris. The agenda for the meeting is:
We hope to see you there!
admin)
on November 22, 2021 08:00 AM
This article will demonstrate how to configure Fedora Server as an alert and notification server that can place calls using an Asterisk PBX and send SMS text messages using Twilio. The use of the SMS message feature is optional. By using the call_only endpoint of the caller_prometheus_webhook component, you can limit the alerts to voice calls only.
Please consider that interacting with the Asterisk PBX is not easy. But it isn’t too hard either. If this is your first time working with this kind of application, coming to understand the concepts may require some patience. Fortunately, Fedora Server can be configured with Ansible and the installation of the py-phone-caller containers will not be difficult.
Note: The py-phone-caller packages do not have any endorsement or relation with Twilio or Asterisk PBX/FreePBX. These services and products were chosen for their ease of use and their commitment to open source.
Note: This guide assumes that the server is on a local area network (LAN) that is behind a firewall configured to block all outside connections. Do not open the services’ ports to the internet without requiring authentication.
The py-phone-caller components are represented by the blue boxes. The third party components or dependencies are the green boxes. And the yellow box represents the receiver of the calls and/or text messages.
<figure class="wp-block-image">
</figure>
generate_audio
caller_sms
caller_prometheus_webhook
– call_only: used to originate a single call
– sms_only: used to send a single SMS
– sms_before_call: first, send an SMS and later originate a call (after the number of seconds configured in: sms_before_call_wait_seconds)
– call_and_sms: used to send the SMS and place the call at the same time.
call_register
asterisk_ws_monitor
asterisk_recall
asterisk_call
Version 0.0.2 of the py-phone-caller application does not have a call traffic controller. Consequently, if multiple events are sent to asterisk_call at the same time, some notifications may be dropped. For reliability, be sure to send no more than one alert at a time from the caller_prometheus_webhook and send only one HTTP POST at a time when using a HTTP client such as curl. To avoid collisions between messages in asterisk_call, do not send events more frequently than the value configured in seconds_to_forget.
Optionally, support for concurrent calls can be enabled by adding more instances of asterisk_call and asterisk_ws_monitor behind an instance of HAProxy. Each additional instance of asterisk_call will require an additional entry in extensions_custom.conf.
To be clear, you need to add one more instance of each of the following for each additional concurrent request that you want to be able to handle:
Note: You can use the same configuration file and override the settings with environment variables. The variables will have priority over the values in the configuration file. The environmental variables use the same names as their corresponding settings, but they must be in upper case. For example, asterisk_stasis_app becomes ASTERISK_STASIS_APP.
Note: chan_pjsip (PJSIP channel) is not yet supported. Support will be added in a future release.
Note: Twilio is the only SMS service provider currently available. Other providers will be added.
Note: If you choose not to send SMS (Short Message Service) messages and not to place calls to paid phone networks, you can still make calls over a SIP (Session Initiation Protocol) or IAX2 (Inter-Asterisk eXchange version 2) extension of the PBX (Private Branch eXchange) to a softphone (software phone) installed on your cell phone or to a physical phone that supports either of these protocols.
Note: You will need to pay a few cents to place calls and send SMS messages to landlines or cell phones. These services are rarely free.
This guide will use the FreePBX Asterisk distribution. It has a web interface that is more user-friendly. The components that initiate calls will be based on Fedora Server 34. Other Fedora Linux variants such as Fedora Workstation or Fedora Cloud Base might work. But all tests and working setups have been based on Fedora Server or CentOS 7 in Docker containers. I am also planning to test this deployment on RHEL 8 and OpenShift/Kubernetes.
Note: You can use different IP addresses for the Fedora Server and the Asterisk system.
A SIP Trunk is required to place calls to cell phones or landlines. If you choose to use only local extensions and you do not intend to place calls to external phones, you can configure a SIP or IAX2 extension instead.
The py-phone-caller will also require a custom extension and an ARI (Asterisk REST Interface) user.
</figure>
</figure>
</figure>
</figure>
An example PEER Details configuration:
type=peer auth=md5 username=your-username fromuser=your-username secret=your-password host=sip.provider.com port=5060 qualify=yes insecure=very
</figure>
</figure>
You should now have a trunk that can be used to place calls to cell and landline phones.
Note: This configuration has a cost depending on the provider or device used to access the public phone network (cell or landline).
This extension will initiate the call and then pass control to py-phone-caller. The message will be the description of a Prometheus alert. It will be sent from the Alertmanager to the caller_prometheus_webhook.
</figure>
</figure>
</figure>
</figure>
An example dial plan:
[py-phone-caller]
exten => 3216,1,Noop()
; Greeting message
same => n,Playback(greeting-message)
; Give the control of the ongoing call to the 'py-phone-caller' Stasis application
same => n,Stasis(py-phone-caller)
; Do a get HTTP request against the 'call_register' when the message was played
same => n,Set(RES=${CURL(http://192.168.122.104:8083/heard?asterisk_chan=${CHANNEL(uniqueid)})})
; Play an audio message in order to get the acknowledgement
; in our case we wait for '4'. "see line xx: {IF($[ ${get} = 4 ..."
same => n,Playback(press-4-for-acknowledgement)
same => n,Playback(beep)
same => n,Read(get,"silence/1",,,,2)
; If not digit is provided go to the priority 20 in order to say 'goodbye'
same => n,Set(gotdigit=${ISNULL(${get})})
same => n,GotoIf(${gotdigit}=1?20)
; When '4' is pressed go to the priority 30, update the DB record
; and say Goodbye.
same => e,Playback(vm-goodbye) ; If there's an error, say goodbye
same => n,Set(NOTIFYACK=${IF($[ ${get} = 4]?3:0)})
same => n,Wait(1)
same => n,GotoIf(${NOTIFYACK}=3?30)
same => 20,Set(NOTIFYACK=2)
same => 21,Playback(vm-goodbye)
same => 22,Wait(1)
same => 23,Hangup()
; Do a get HTTP request against the 'call_register' to update the DB record
; when the call was acknowledged.
same => 30,Set(RES=${CURL(http://192.168.122.104:8083/ack?asterisk_chan=${CHANNEL(uniqueid)})})
same => 31,Playback(vm-goodbye)
same => 32,Wait(1)
same => 33,Hangup()
same => n,Playback(vm-goodbye)
same => n,Hangup()
A step-by-step breakdown of the above dial plan:
</figure>
A SIP or IAX2 extension can be used instead of a SIP Trunk. However, these protocols will only be able to dial out to softphones or VoIP phones. You will not be able to call a PSTN or cell phone using SIP or IAX2. There are no additional costs when using these extensions. They can be configured directly within the PBX. They can be used on the same local network the PBX is connected to. Or they can be routed over the internet. If you choose to route these protocols over the internet, please use a security layer such as TLS and use secure passwords. If you use a softphone installed on your cell phone, be sure that your internet connection has sufficient bandwidth to provide high-quality audio.
Note: When using these alternative protocols, the value of asterisk_chan_type will be SIP instead of SIP/sip-provider. When using these protocols, a SIP Trunk or Media Gateway is not required.
Note: This endpoint can be viewed as the callee. It is the extension or phone number that will be called when a new Prometheus alert or HTTP POST request is sent to asterisk_call. It is also is possible to initiate calls directly from cron jobs and other scripts.
</figure>
</figure>
</figure>
</figure>
</figure>
</figure>
The ARI (Asterisk REST Interface) user will be used in asterisk_ws_monitor to register the Stasis application (a permanent WebSocket connection). This account will also be used by asterisk_call to make calls to the Asterisk PBX (or FreePBX).
</figure>
</figure>
</figure>
</figure>
</figure>
Install espeak.
$ sudo dnf -y install espeak
Generate the audio files in wave format.
$ espeak -s 140 -g 4 -w /tmp/greeting-message_22050.wav "Hello. This is a recorded message from the alerting system." $ espeak -s 140 -g 4 -w /tmp/press-4-for-acknowledgement_22050.wav "After the beep, please press the number four to acknowledge this call."
The espeak program records the audio files with a sampling frequency of 22050 Hz. However, Asterisk requires 8000 Hz. Install sox and use it to convert the files to the required format.
$ sudo dnf -y install sox $ sox /tmp/greeting-message_22050.wav -r 8000 -c 1 /tmp/greeting-message.wav $ sox /tmp/press-4-for-acknowledgement_22050.wav -r 8000 -c 1 /tmp/press-4-for-acknowledgement.wav
You can read more about espeak in its man pages and on Fedora Magazine. Alternatively, if you have a microphone and you know someone with a good voice you can record a real person.
The above example audio files are available here: assets/generic-audio-for-dialplan
Upload the audio files you created in the previous section to your Asterisk system.
$ scp /tmp/*.wav root@192.168.122.234:~ root@192.168.122.234's password: greeting-message.wav 100% 107KB 21.7MB/s 00:00 press-4-for-acknowledgement.wav 100% 77KB 21.9MB/s 00:00
Login to the Asterisk (FreePBX) system.
$ ssh root@192.168.122.234 root@192.168.122.234's password: Last failed login: Tue Aug 3 23:29:04 UTC 2021 from 192.168.122.1 on ssh:notty There was 1 failed login attempt since the last successful login. Last login: Tue Aug 3 23:33:50 2021 from 192.168.122.1 ______ ______ ______ __ __ | ___| | ___ \| ___ \\ \ / / | |_ _ __ ___ ___ | |_/ /| |_/ / \ V / | _| | '__| / _ \ / _ \| __/ | ___ \ / \ | | | | | __/| __/| | | |_/ // /^\ \ \_| |_| \___| \___|\_| \____/ \/ \/ NOTICE! You have 2 notifications! Please log into the UI to see them! Current Network Configuration +-----------+-------------------+-------------------------+ | Interface | MAC Address | IP Addresses | +-----------+-------------------+-------------------------+ | eth0 | 52:54:00:F1:1C:F6 | 192.168.122.234 | | | | fe80::5054:ff:fef5:6cf1 | +-----------+-------------------+-------------------------+ [...] [root@freepbx ~]#
This guide uses Asterisk’s default language, English. For English, the audio files are stored in /var/lib/asterisk/sounds/en. Move the uploaded audio files to this directory. If you configured a different language, you would need to move the files to a different directory.
The audio files should be in root’s home directory (/root). Move them to Asterisk’s directory.
[root@freepbx ~]# mv greeting-message.wav press-4-for-acknowledgement.wav /var/lib/asterisk/sounds/en
Finally, set the ownership for the files to asterisk:asterisk.
[root@freepbx ~]# chown asterisk:asterisk /var/lib/asterisk/sounds/en/{greeting-message.wav,press-4-for-acknowledgement.wav}
The configuration of the Asterisk PBX should now be complete.
This guide is using Fedora Server edition. Login to your Fedora server and use the sudo command to change to root user.
$ sudo -i
Install Podman.
# dnf -y install podman podman-plugins podman-docker Last metadata expiration check: 0:42:59 ago on Wed 28 Jul 2021 23:31:23 PM CEST. Dependencies resolved. ============================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================= Installing: podman x86_64 3:3.2.3-1.fc34 updates 12 M podman-docker noarch 3:3.2.3-1.fc34 updates 177 k podman-plugins x86_64 3:3.2.3-1.fc34 updates 2.6 M Installing dependencies: conmon x86_64 2:2.0.29-2.fc34 updates 53 k container-selinux noarch 2:2.164.1-1.git563ba3f.fc34 updates 48 k containernetworking-plugins x86_64 1.0.0-0.2.rc1.fc34 updates 8.9 M containers-common noarch 4:1-21.fc34 updates 61 k criu x86_64 3.15-3.fc34 fedora 521 k criu-libs x86_64 3.15-3.fc34 fedora 31 k crun x86_64 0.20.1-1.fc34 updates 172 k fuse-common x86_64 3.10.4-1.fc34 updates 8.5 k fuse3 x86_64 3.10.4-1.fc34 updates 54 k fuse3-libs x86_64 3.10.4-1.fc34 updates 91 k libbsd x86_64 0.10.0-7.fc34 fedora 106 k libnet x86_64 1.2-2.fc34 fedora 58 k libslirp x86_64 4.4.0-4.fc34 updates 68 k yajl x86_64 2.1.0-16.fc34 fedora 38 k Installing weak dependencies: catatonit x86_64 0.1.5-4.fc34 fedora 305 k fuse-overlayfs x86_64 1.5.0-1.fc34 fedora 75 k slirp4netns x86_64 1.1.9-1.fc34 fedora 57 k Transaction Summary ============================================================================================================================================================================= Install 20 Packages Total download size: 25 M Installed size: 123 M [...]
Install Ansible and PostgreSQL.
# dnf install -y ansible python3-psycopg2 postgresql Last metadata expiration check: 0:38:54 ago on Wed 28 Jul 2021 23:41:48 PM CEST. Dependencies resolved. ============================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================= Installing: ansible noarch 2.9.23-1.fc34 updates 15 M python3-psycopg2 x86_64 2.8.6-3.fc34 fedora 183 k Installing dependencies: libpq x86_64 13.3-1.fc34 updates 202 k libsodium x86_64 1.0.18-7.fc34 fedora 165 k python3-babel noarch 2.9.1-1.fc34 updates 5.8 M python3-bcrypt x86_64 3.1.7-7.fc34 fedora 44 k python3-cffi x86_64 1.14.5-1.fc34 fedora 244 k python3-chardet noarch 4.0.0-1.fc34 fedora 214 k python3-cryptography x86_64 3.4.6-1.fc34 fedora 1.4 M python3-idna noarch 2.10-3.fc34 fedora 99 k python3-jinja2 noarch 2.11.3-1.fc34 fedora 493 k python3-jmespath noarch 0.10.0-1.fc34 updates 46 k python3-markupsafe x86_64 1.1.1-10.fc34 fedora 32 k python3-ntlm-auth noarch 1.5.0-2.fc34 fedora 53 k python3-ply noarch 3.11-11.fc34 fedora 103 k python3-pycparser noarch 2.20-3.fc34 fedora 126 k python3-pynacl x86_64 1.4.0-2.fc34 fedora 110 k python3-pysocks noarch 1.7.1-8.fc34 fedora 35 k python3-pytz noarch 2021.1-2.fc34 fedora 49 k python3-pyyaml x86_64 5.4.1-2.fc34 fedora 194 k python3-requests noarch 2.25.1-1.fc34 fedora 114 k python3-requests_ntlm noarch 1.1.0-14.fc34 fedora 18 k python3-urllib3 noarch 1.25.10-5.fc34 updates 174 k python3-xmltodict noarch 0.12.0-11.fc34 fedora 23 k sshpass x86_64 1.09-1.fc34 fedora 27 k Installing weak dependencies: python3-paramiko noarch 2.7.2-4.fc34 fedora 287 k python3-pyasn1 noarch 0.4.8-4.fc34 fedora 133 k python3-winrm noarch 0.4.1-2.fc34 fedora 79 k Transaction Summary ============================================================================================================================================================================= Install 28 Packages Total download size: 25 M Installed size: 144 M [...]
Exit the root shell.
# exit logout
Install the Ansible role for managing Podman.
$ ansible-galaxy collection install containers.podman Process install dependency map Starting collection install process Installing 'containers.podman:1.6.1' to '/home/fedora/.ansible/collections/ansible_collections/containers/podman'
Install the Ansible role for managing PostgreSQL.
$ ansible-galaxy collection install community.postgresql Process install dependency map Starting collection install process Installing 'community.postgresql:1.4.0' to '/home/fedora/.ansible/collections/ansible_collections/community/postgresql'
Verify the Podman installation by running a small test container.
$ podman run hello-world
Resolved "hello-world" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob b8dfde127a29 done
Copying config d1165f2212 done
Writing manifest to image destination
Storing signatures
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
The following files will be required to install py-phone-caller via Ansible.
Fisrt, create a directory to store the installation playbook and cd into it.
$ mkdir ansible_py-phone-caller $ cd ansible_py-phone-caller
Now download the files.
$ wget https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/caller_config.toml.jinja2 --2021-07-28 23:48:11-- https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/caller_config.toml.jinja2 Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.110.133, ... Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 3730 (3.6K) [text/plain] Saving to: ‘caller_config.toml.jinja2’ caller_config.toml.jinja2 100%[========================================================================================>] 3.64K --.-KB/s in 0s 2021-07-28 23:48:11 (20.4 MB/s) - ‘caller_config.toml.jinja2’ saved [3730/3730] $ wget https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/py-phone-caller-podman.yml --2021-07-28 23:49:55-- https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/py-phone-caller-podman.yml Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.108.133, 185.199.111.133, ... Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 10793 (11K) [text/plain] Saving to: ‘py-phone-caller-podman.yml’ py-phone-caller-podman.yml 100%[========================================================================================>] 10.54K --.-KB/s in 0s 2021-07-28 23:49:55 (25.7 MB/s) - ‘py-phone-caller-podman.yml’ saved [10793/10793] $ wget https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/py_phone_caller_vars_file.yml --2021-07-28 23:51:20-- https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/ansible/rh/py_phone_caller_vars_file.yml Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.110.133, 185.199.109.133, ... Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 7149 (7.0K) [text/plain] Saving to: ‘py_phone_caller_vars_file.yml’ py_phone_caller_vars_file.yml 100%[========================================================================================>] 6.98K --.-KB/s in 0s 2021-07-28 23:51:20 (14.6 MB/s) - ‘py_phone_caller_vars_file.yml’ saved [7149/7149]
The variables file py_phone_caller_vars_file.yml:
---
# Variables files for the 'py-phone-caller' installed through Podman
ansible_python_interpreter: /usr/bin/python3
# Podman / 'py-phone-caller' vars
container_host: 192.168.122.104
installation_user: fedora
installation_folder: "/home/{{ installation_user }}"
installation_folder_name: py-phone-caller
caller_config_toml_template_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/9c0bb97110cef988adfd23a6c0cb8e25168bbdfc/assets/ansible/rh/caller_config.toml.jinja2"
py_phone_caller_config_tmp_path: /tmp/caller_config.toml.jinja
py_phone_caller_config_path: "{{ installation_folder }}/{{ installation_folder_name }}/config/caller_config.toml"
config_mounted_in_container: /opt/py-phone-caller/config/caller_config.toml:Z
py_phone_caller_version: 0.0.2
container_registry_url: quay.io/py-phone-caller
py_phone_caller_network: py-phone-caller
py_phone_caller_subnet: 172.19.0.0/24
asterisk_ws_monitor_ip: 172.19.0.10
asterisk_recall_ip: 172.19.0.11
postgres_ip: 172.19.0.50
generate_audio_ip: 172.19.0.82
call_register_ip: 172.19.0.83
asterisk_call_ip: 172.19.0.81
caller_prometheus_webhook_ip: 172.19.0.84
caller_sms_ip: 172.19.0.85
# PostgreSQL container vars
db_schema_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/DB/db-schema.sql"
postgresql_container_image: "docker.io/library/postgres:13.3-alpine3.14"
postgresql_login_host: 127.0.0.1
postgresql_admin: postgres
postgresql_admin_pass: Use-A-Secure-Password-Here
# SystemD user integration
container_asterisk_call_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_call.service"
container_asterisk_call_register_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_call_register.service"
container_asterisk_recall_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_recall.service"
container_asterisk_ws_monitor_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_ws_monitor.service"
container_caller_prometheus_webhook_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-caller_prometheus_webhook.service"
container_caller_sms_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-caller_sms.service"
container_generate_audio_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-generate_audio.service"
container_postgres_13_service_url: "https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-postgres_13.service"
systemd_user_path: "/home/{{ installation_user }}/.config/systemd/user"
container_asterisk_call_service_unit: "container-asterisk_call.service"
container_asterisk_call_register_service_unit: "container-asterisk_call_register.service"
container_asterisk_recall_service_unit: "container-asterisk_recall.service"
container_asterisk_ws_monitor_service_unit: "container-asterisk_ws_monitor.service"
container_caller_prometheus_webhook_service_unit: "container-caller_prometheus_webhook.service"
container_caller_sms_service_unit: "container-caller_sms.service"
container_generate_audio_service_unit: "container-generate_audio.service"
container_postgres_13_service_unit: "container-postgres_13.service"
# py-phone-caller - 'caller_config.toml' vars
# [commons]
asterisk_user: "py-phone-caller"
asterisk_pass: "Use-A-Secure-Password-Here"
asterisk_host: "192.168.122.234"
asterisk_web_port: "8088"
asterisk_http_scheme: "http"
# [asterisk_call]
asterisk_ari_channels: "ari/channels"
asterisk_ari_play: "play?media=sound"
asterisk_context: "py-phone-caller"
asterisk_extension: "3216"
asterisk_chan_type: "SIP/sip-provider"
asterisk_callerid: "Py-Phone-Caller"
asterisk_call_http_scheme: "http"
asterisk_call_host: "{{ container_host }}"
asterisk_call_port: "8081"
asterisk_call_app_route_asterisk_init: "asterisk_init"
asterisk_call_app_route_play: "play"
seconds_to_forget: 300
client_timeout_total: 5 # For 'ClientTimeout(total=5)'
# [call_register]
call_register_http_scheme: "http"
call_register_host: "{{ container_host }}"
call_register_port: "8083"
call_register_app_route_register_call: "register_call"
call_register_app_route_voice_message: "msg"
call_register_app_route_acknowledge: "ack"
call_register_app_route_heard: "heard"
# [asterisk_ws_monitor]
asterisk_stasis_app: "py-phone-caller"
# [asterisk_recall]
times_to_dial: 3
# [generate_audio]
generate_audio_http_scheme: "http"
generate_audio_host: "{{ container_host }}"
generate_audio_port: "8082"
generate_audio_app_route: "make_audio"
gcloud_tts_language_code: "es"
serving_audio_folder: "audio"
num_of_cpus: 4
# [caller_prometheus_webhook]
prometheus_webhook_port: "8084"
prometheus_webhook_app_route_call_only: "call_only"
prometheus_webhook_app_route_sms_only: "sms_only"
prometheus_webhook_app_route_sms_before_call: "sms_before_call"
prometheus_webhook_app_route_call_and_sms: "call_and_sms"
prometheus_webhook_receivers: '[ "+123456789" ]'
# [caller_sms]
caller_sms_http_scheme: "http"
caller_sms_host: "{{ container_host }}"
caller_sms_port: "8085"
caller_sms_app_route: "send_sms"
sms_before_call_wait_seconds: 120
caller_sms_carrier: "twilio"
twilio_account_sid: "Your-Twilio-account-sid"
twilio_auth_token: "Your-Twilio-auth-token"
twilio_sms_from: "+1987654321"
# [database]
db_host: "{{ postgres_ip }}"
db_name: "py_phone_caller"
db_user: "py_phone_caller"
db_password: 'Use-A-Secure-Password-Here'
db_max_size: 50
db_max_inactive_connection_lifetime: 30.0
# [logger]
log_formatter: "%(asctime)s %(message)s"
acknowledge_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/ack?asterisk_chan=[The Asterisk Channel ID]"
heard_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/heard?asterisk_chan=[The Asterisk Channel ID]"
registercall_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/?phone=[Destination Phone Number]&messagge=[Alert Message Text]&asterisk_chan=[The Asterisk Channel ID]"
voice_message_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/msg?asterisk_chan=[The Asterisk Channel ID]"
asterisk_call_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/asterisk?phone=[Destination Phone Number]&messagge=[Alert Message Text]"
asterisk_play_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/play?asterisk_chan=[The Asterisk Channel ID]&msg_chk_sum=[The message cecksum]"
generate_audio_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/make_audio?messagge=[Alert Message Text]&msg_chk_sum=[The message cecksum]"
caller_sms_error: "Lost parameter, Usage: Method: POST - http://ADDRESS/?phone=[Destination Phone Number]&messagge=[Alert Message Text]"
lost_directory_error: "The folder to serve the audio files was not found."
Install and configuring py-phone-caller using Ansible.
Ansible is a really cool configuration management and orchestration tool. Using Ansible, all the py-phone-caller components can be installed and configured automatically. After all the parameters are set in the assets/ansible/rh/py_phone_caller_vars_file.yml file, run ansible-playbook and in a few minutes you will have a fully configured and ready to be used py-phone-caller.
Variables that you might want to change in the assets/ansible/rh/py_phone_caller_vars_file.yml file:
[...] # Podman / 'py-phone-caller' vars [...] container_host: 192.168.122.104 # Here we need to configure the IP address of our Fedora Server instance installation_user: fedora # The user within the installation will be done. [...] # PostgreSQL container vars [...] postgresql_admin_pass: Use-A-Secure-Password-Here # The administrative password for PostgreSQL (user: postgres) [...] # py-phone-caller - 'caller_config.toml' vars # [commons] asterisk_pass: "Use-A-Secure-Password-Here" # The password for the 'py-phone-caller' Asterisk ARI user asterisk_host: "192.168.122.234" # The IP address of the Asterisk (in our case FreePBX) instance. [...] # [caller_sms] # Only if we want send SMS through Twilio [...] twilio_account_sid: "Your-Twilio-account-sid" # The Twilio SID twilio_auth_token: "Your-Twilio-auth-token" # The Twilio auth token twilio_sms_from: "+1987654321" # The Twilio number [...] # [database] [...] db_password: 'Use-A-Secure-Password-Here' # The password for the PostgreSQL 'py-phone-caller' user. [...]
To install py-phone-caller, run ansible-playbook.
$ ansible-playbook --connection=local --limit=127.0.0.1 --inventory=127.0.0.1, ansible_py-phone-caller/py-phone-caller-podman.yml
PLAY [Configuring 'py-phone-caller' installed through 'Podman'] *************************************************************************************************************
TASK [Gathering Facts] ******************************************************************************************************************************************************
ok: [127.0.0.1]
TASK [Creating the 'py-phone-caller' directory tree at '/home/fedora/py-phone-caller'] **************************************************************************************
changed: [127.0.0.1]
TASK [Check that the 'caller_config.toml' exists] ***************************************************************************************************************************
ok: [127.0.0.1]
TASK [Download the 'caller_config.toml' template file] **********************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the configuration file 'caller_config.toml' through a template] **********************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'py-phone-caller' container network] *********************************************************************************************************************
changed: [127.0.0.1]
TASK [Checking if the 'pgdata' volume exists] *******************************************************************************************************************************
fatal: [127.0.0.1]: FAILED! => {"changed": true, "cmd": ["podman", "volume", "inspect", "pgdata"], "delta": "0:00:00.059469", "end": "2021-07-28 22:04:44.174686", "msg": "non-zero return code", "rc": 125, "start": "2021-07-28 22:04:44.115217", "stderr": "Error: error inspecting object: no such volume pgdata", "stderr_lines": ["Error: error inspecting object: no such volume pgdata"], "stdout": "[]", "stdout_lines": ["[]"]}
TASK [Creating the 'pgdata' volume for the PostgreSQL container] ************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'postgres_13' container] *********************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'asterisk_call' container] *******************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'caller_prometheus_webhook' container] *******************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'caller_sms' container] **********************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'generate_audio' container] ******************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'py_phone_caller' PostgreSQL user] ***********************************************************************************************************************
changed: [127.0.0.1]
TASK [Gattering info about the 'py_phone_caller' DB (if exists)] ************************************************************************************************************
fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "unable to connect to database: FATAL: database \"py_phone_caller\" does not exist\n"}
TASK [Download the dumped 'py_phone_caller' DB schema (SQL format)] *********************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'py_phone_caller' DB] ************************************************************************************************************************************
changed: [127.0.0.1]
TASK [Restoring the 'py_phone_caller' DB by restoring a dump of the schema] *************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'asterisk_ws_monitor' container] *************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'asterisk_recall' container] *****************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the 'call_register' container] *******************************************************************************************************************************
changed: [127.0.0.1]
TASK [Creating the Systemd user folder] *************************************************************************************************************************************
changed: [127.0.0.1]
TASK [Download the Systemd Unit files] **************************************************************************************************************************************
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_call.service', 'path': 'container-asterisk_call.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_call_register.service', 'path': 'container-asterisk_call_register.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_recall.service', 'path': 'container-asterisk_recall.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-asterisk_ws_monitor.service', 'path': 'container-asterisk_ws_monitor.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-caller_prometheus_webhook.service', 'path': 'container-caller_prometheus_webhook.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-caller_sms.service', 'path': 'container-caller_sms.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-generate_audio.service', 'path': 'container-generate_audio.service'})
changed: [127.0.0.1] => (item={'url': 'https://raw.githubusercontent.com/jcfdeb/py-phone-caller/main/assets/systemd-units/as-non-root-container/container-postgres_13.service', 'path': 'container-postgres_13.service'})
TASK [Enable and run the user SystemD services for 'py-phone-caller'] *******************************************************************************************************
changed: [127.0.0.1] => (item=container-asterisk_call.service)
changed: [127.0.0.1] => (item=container-asterisk_call_register.service)
changed: [127.0.0.1] => (item=container-asterisk_recall.service)
changed: [127.0.0.1] => (item=container-asterisk_ws_monitor.service)
changed: [127.0.0.1] => (item=container-caller_prometheus_webhook.service)
changed: [127.0.0.1] => (item=container-caller_sms.service)
changed: [127.0.0.1] => (item=container-generate_audio.service)
changed: [127.0.0.1] => (item=container-postgres_13.service)
TASK [Deleting the '/tmp' files] ********************************************************************************************************************************************
changed: [127.0.0.1] => (item=/tmp/db-schema.sql)
changed: [127.0.0.1] => (item=/tmp/caller_config.toml.jinja)
PLAY RECAP ******************************************************************************************************************************************************************
127.0.0.1 : ok=23 changed=21 unreachable=0 failed=0 skipped=0 rescued=2 ignored=0
Run the following Firewalld commands to allow the necessary connections.
$ sudo firewall-cmd --add-source="192.168.122.0/24" --permanent success $ sudo firewall-cmd --add-source="172.19.0.0/24" --permanent success $ sudo firewall-cmd --add-port=8081/tcp --permanent success $ sudo firewall-cmd --add-port=8082/tcp --permanent success $ sudo firewall-cmd --add-port=8083/tcp --permanent success $ sudo firewall-cmd --add-port=8084/tcp --permanent success $ sudo firewall-cmd --reload success
The final pieces to be installed are the Node Expoter, the Alertmanager and Prometheus. With these, you will be able to monitor, alert and collect metrics when some metric violates a condition defined in the alerting rules.
Packages to be installed:
Enter the following command to install the packages.
$ sudo dnf -y install golang-github-prometheus golang-github-prometheus-alertmanager golang-github-prometheus-node-exporter Last metadata expiration check: 0:17:09 ago on Thu 12 Aug 2021 21:23:21 PM CEST. Dependencies resolved. ============================================================================================================================================================================= Package Architecture Version Repository Size ============================================================================================================================================================================= Installing: golang-github-prometheus x86_64 2.24.1-6.fc34 updates 31 M golang-github-prometheus-alertmanager x86_64 0.21.0-3.fc34 fedora 13 M golang-github-prometheus-node-exporter x86_64 1.1.1-2.fc34 fedora 4.5 M Transaction Summary ============================================================================================================================================================================= Install 3 Packages Total download size: 48 M Installed size: 212 M Downloading Packages: [...]
Node Exporter <-- Prometheus --> Alertmanager --> caller_prometheus_webhook
The Node Exporter exposes the metrics of the Fedora Server system. Prometheus does a periodic pull of these metrics. If some alerting rules are defined and one or more metrics violates a condition then Prometheus will send a request to the Alertmanager. Alertmanager will then call caller_prometheus_webhook.
The role of this component is to trigger the different notification systems (e-mail, PagerDuty, Slack, VictorOps, etc.). It can also make a POST request to a webhook receiver such as caller_prometheus_webhook to place a call or send an SMS message (or whatever else you have configured it to do).
One useful feature of this component is the ability to silence the alerts from the web interface. When someone takes an action to resolve the problem, they can silence it. Otherwise the default configuration would repeat the alert in three hours (repeat_interval: 3h).
A list of the package contents:
# dnf repoquery -l golang-github-prometheus-alertmanager Last metadata expiration check: 0:50:29 ago on Thu 12 Aug 2021 04:23:21 PM CEST. /usr/bin/alertmanager /usr/bin/amtool /usr/lib/.build-id /usr/lib/.build-id/0b /usr/lib/.build-id/0b/275747139b1a6f1b398166b54ee83f625e1d4e /usr/lib/.build-id/4d /usr/lib/.build-id/4d/be93dda0226df14625b47ea1a6747eacd1e0d1 /usr/share/doc/golang-github-prometheus-alertmanager /usr/share/doc/golang-github-prometheus-alertmanager/CHANGELOG.md /usr/share/doc/golang-github-prometheus-alertmanager/MAINTAINERS.md /usr/share/doc/golang-github-prometheus-alertmanager/README.md /usr/share/doc/golang-github-prometheus-alertmanager/doc /usr/share/doc/golang-github-prometheus-alertmanager/doc/arch.svg /usr/share/doc/golang-github-prometheus-alertmanager/doc/arch.xml /usr/share/doc/golang-github-prometheus-alertmanager/doc/design /usr/share/doc/golang-github-prometheus-alertmanager/doc/design/secure-cluster-traffic.md /usr/share/doc/golang-github-prometheus-alertmanager/doc/examples /usr/share/doc/golang-github-prometheus-alertmanager/doc/examples/simple.yml /usr/share/doc/golang-github-prometheus-alertmanager/examples /usr/share/doc/golang-github-prometheus-alertmanager/examples/ha /usr/share/doc/golang-github-prometheus-alertmanager/examples/ha/alertmanager.yml /usr/share/doc/golang-github-prometheus-alertmanager/examples/ha/send_alerts.sh /usr/share/doc/golang-github-prometheus-alertmanager/examples/webhook /usr/share/doc/golang-github-prometheus-alertmanager/examples/webhook/echo.go /usr/share/licenses/golang-github-prometheus-alertmanager /usr/share/licenses/golang-github-prometheus-alertmanager/COPYRIGHT.txt /usr/share/licenses/golang-github-prometheus-alertmanager/LICENSE /usr/share/licenses/golang-github-prometheus-alertmanager/NOTICE
From the previous code snippet you can see that there is no systemd service file, directory to store the data, or configuration directory. You will need to create them manually.
# mkdir -p /etc/alertmanager/template /var/lib/prometheus/alertmanager/data # chown -R prometheus. /var/lib/prometheus/alertmanager # cp /usr/share/doc/golang-github-prometheus-alertmanager/doc/examples/simple.yml /etc/alertmanager/alertmanager.yml
Next, add the following configuration blocks to /etc/alertmanager/alertmanager.yml.
In the routes section:
[...]
# py-phone-caller example
- match:
severity: disaster
receiver: py-phone-caller
[...]
In the receivers section:
[...]
- name: 'py-phone-caller'
webhook_configs:
# Onr of the endpoints of 'caller_prometheus_webhook'
- url: 'http://127.0.0.1:8084/sms_before_call'
send_resolved: false
[...]
The complete /etc/alertmanager/alertmanager.yml file:
global:
# The smarthost and SMTP sender used for mail notifications.
smtp_smarthost: 'localhost:25'
smtp_from: 'alertmanager@example.org'
smtp_auth_username: 'alertmanager'
smtp_auth_password: 'password'
# The directory from which notification templates are read.
templates:
- '/etc/alertmanager/template/*.tmpl'
# The root route on which each incoming alert enters.
route:
# The labels by which incoming alerts are grouped together. For example,
# multiple alerts coming in for cluster=A and alertname=LatencyHigh would
# be batched into a single group.
#
# To aggregate by all possible labels use '...' as the sole label name.
# This effectively disables aggregation entirely, passing through all
# alerts as-is. This is unlikely to be what you want, unless you have
# a very low alert volume or your upstream notification system performs
# its own grouping. Example: group_by: [...]
group_by: ['alertname', 'cluster', 'service']
# When a new group of alerts is created by an incoming alert, wait at
# least 'group_wait' to send the initial notification.
# This way ensures that you get multiple alerts for the same group that start
# firing shortly after another are batched together on the first
# notification.
group_wait: 30s
# When the first notification was sent, wait 'group_interval' to send a batch
# of new alerts that started firing for that group.
group_interval: 5m
# If an alert has successfully been sent, wait 'repeat_interval' to
# resend them.
repeat_interval: 3h
# A default receiver
receiver: team-X-mails
# All the above attributes are inherited by all child routes and can
# overwritten on each.
# The child route trees.
routes:
# This routes performs a regular expression match on alert labels to
# catch alerts that are related to a list of services.
- match_re:
service: ^(foo1|foo2|baz)$
receiver: team-X-mails
# The service has a sub-route for critical alerts, any alerts
# that do not match, i.e. severity != critical, fall-back to the
# parent node and are sent to 'team-X-mails'
routes:
- match:
severity: critical
receiver: team-X-pager
- match:
service: files
receiver: team-Y-mails
# py-phone-caller example
- match:
severity: disaster
receiver: py-phone-caller
routes:
- match:
severity: critical
receiver: team-Y-pager
# This route handles all alerts coming from a database service. If there's
# no team to handle it, it defaults to the DB team.
- match:
service: database
receiver: team-DB-pager
# Also group alerts by affected database.
group_by: [alertname, cluster, database]
routes:
- match:
owner: team-X
receiver: team-X-pager
continue: true
- match:
owner: team-Y
receiver: team-Y-pager
# Inhibition rules allow to mute a set of alerts given that another alert is
# firing.
# We use this to mute any warning-level notifications if the same alert is
# already critical.
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
# Apply inhibition if the alertname is the same.
# CAUTION:
# If all label names listed in `equal` are missing
# from both the source and target alerts,
# the inhibition rule will apply!
equal: ['alertname', 'cluster', 'service']
receivers:
- name: 'team-X-mails'
email_configs:
- to: 'team-X+alerts@example.org'
- name: 'team-X-pager'
email_configs:
- to: 'team-X+alerts-critical@example.org'
pagerduty_configs:
- service_key: <team-X-key>
- name: 'team-Y-mails'
email_configs:
- to: 'team-Y+alerts@example.org'
- name: 'team-Y-pager'
pagerduty_configs:
- service_key: <team-Y-key>
- name: 'team-DB-pager'
pagerduty_configs:
- service_key: <team-DB-key>
- name: 'py-phone-caller'
webhook_configs:
# Onr of the endpoints of 'caller_prometheus_webhook'
- url: 'http://127.0.0.1:8084/sms_before_call'
send_resolved: false
Note: This is an example file and several blocks can be removed because they aren’t used. For your use case it will work fine. The unused parts weren’t removed in order to show a complete landscape of this file.
Run systemctl cat prometheus.service to view the prometheus.service systemd unit file.
# systemctl cat prometheus.service
# /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus service monitoring system and time series database
Documentation=https://prometheus.io/docs/introduction/overview/ man:prometheus(1)
Wants=network-online.target
After=network-online.target
[Service]
Restart=on-failure
EnvironmentFile=/etc/sysconfig/prometheus
User=prometheus
Group=prometheus
ExecStart=/usr/bin/prometheus \
--config.file=${CONFIG_FILE} \
--storage.tsdb.path=${STORAGE_TSDB_PATH} \
--web.console.libraries=${WEB_CONSOLE_LIBRARIES_PATH} \
--web.console.templates=${WEB_CONSOLE_TEMPLATES_PATH} \
--web.listen-address=${WEB_LISTEN_ADDRESS}
ExecReload=/bin/kill -HUP $MAINPID
TimeoutStopSec=20s
SendSIGKILL=no
[Install]
WantedBy=multi-user.target
The /etc/systemd/system/alertmanager.service file:
[Unit] Description=Alertmanager for the Prometheus monitoring system Documentation=https://prometheus.io/docs/alerting/latest/alertmanager/ Wants=network-online.target After=network-online.target [Service] Restart=on-failure User=prometheus Group=prometheus ExecStart=/usr/bin/alertmanager --config.file="/etc/alertmanager/alertmanager.yml" --storage.path="/var/lib/prometheus/alertmanager/data" ExecReload=/bin/kill -HUP $MAINPID TimeoutStopSec=20s SendSIGKILL=no [Install] WantedBy=multi-user.target
Enable alertmanager.service.
# systemctl enable --now alertmanager.service Created symlink /etc/systemd/system/multi-user.target.wants/alertmanager.service → /etc/systemd/system/alertmanager.service.
Use the following command to verify that the service is running.
# systemctl status alertmanager.service
● alertmanager.service - Alertmanager for the Prometheus monitoring system
Loaded: loaded (/etc/systemd/system/alertmanager.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-08-12 21:44:32 CEST; 1s ago
Docs: https://prometheus.io/docs/alerting/latest/alertmanager/
Main PID: 49281 (alertmanager)
Tasks: 11 (limit: 4647)
Memory: 16.2M
CPU: 86ms
CGroup: /system.slice/alertmanager.service
└─49281 /usr/bin/alertmanager --config.file=/etc/alertmanager/alertmanager.yml --storage.path=/var/lib/prometheus/alertmanager/data
Aug 12 21:44:32 fedora systemd[1]: Started Alertmanager for the Prometheus monitoring system.
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.390Z caller=main.go:216 msg="Starting Alertmanager" version="(version=, branch=, revision=)"
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.390Z caller=main.go:217 build_context="(go=go1.16rc1, user=, date=)"
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.391Z caller=cluster.go:161 component=cluster msg="setting advertise address explicitly" addr=1>
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.392Z caller=cluster.go:623 component=cluster msg="Waiting for gossip to settle..." interval=2s
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.425Z caller=coordinator.go:119 component=configuration msg="Loading configuration file" file=/>
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.426Z caller=coordinator.go:131 component=configuration msg="Completed loading of configuration>
Aug 12 21:44:32 fedora alertmanager[49281]: level=info ts=2021-08-12T19:44:32.430Z caller=main.go:485 msg=Listening address=:9093
This component exposes various metrics on the host where it is running. For more information about the metrics exposed by this component, see the README.md file in the Github repository.
Enable and start the node_exporter service.
# systemctl enable --now node_exporter.service Created symlink /etc/systemd/system/multi-user.target.wants/node_exporter.service → /etc/systemd/system/node_exporter.service.
Check the status of the node_exporter service.
# systemctl status node_exporter.service
● node_exporter.service - Node Exporter
Loaded: loaded (/etc/systemd/system/node_exporter.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-08-12 21:55:48 CEST; 7s ago
Main PID: 49401 (node_exporter)
Tasks: 6 (limit: 4647)
Memory: 5.3M
CPU: 15ms
CGroup: /system.slice/node_exporter.service
└─49401 /usr/sbin/node_exporter --collector.textfile.directory /var/lib/node_exporter/textfile_collector
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=thermal_zone
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=time
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=timex
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=udp_queues
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=uname
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=vmstat
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=xfs
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:113 collector=zfs
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.066Z caller=node_exporter.go:195 msg="Listening on" address=:9100
Aug 12 21:55:48 fedora node_exporter[49401]: level=info ts=2021-08-12T19:55:48.067Z caller=tls_config.go:191 msg="TLS is disabled." http2=false
You will need to make some changes before starting the Prometheus service. You need to change the default listening port from 9090 to another value. Port 9090 is reserved by Cockpit on Fedora Server edition.
# ss -wenotulipas | grep :9090
tcp LISTEN 0 4096 *:9090 *:* users:(("systemd",pid=1,fd=139)) ino:18756 sk:e cgroup:/system.slice/cockpit.socket v6only:0 <-
The /etc/sysconfig/prometheus file:
CONFIG_FILE=/etc/prometheus/prometheus.yml STORAGE_TSDB_PATH=/var/lib/prometheus WEB_CONSOLE_LIBRARIES_PATH=/etc/prometheus/console_libraries WEB_CONSOLE_TEMPLATES_PATH=/etc/prometheus/consoles WEB_LISTEN_ADDRESS=127.0.0.1:9091
In the /etc/prometheus/prometheus.yml file, modify are the following blocks.
The alertmanagers block:
[...]
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
[...]
The scrape_configs block:
[...]
# The local node exporter
- job_name: 'node-exporter'
static_configs:
- targets: ['localhost:9100']
[...]
The rule_files block:
[...] # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: - "alert_rules.yml" [...]
The /etc/prometheus/prometheus.yml file:
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
- "alert_rules.yml"
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9091']
# The local node exporter
- job_name: 'node-exporter'
static_configs:
- targets: ['localhost:9100']
The /etc/prometheus/alert_rules.yml file:
groups:
- name: py-phone-caller test alerts
rules:
- alert: NodeExporterDown
expr: up{job="node-exporter"} == 0
for: 5m
labels:
severity: disaster
annotations:
summary: "The Node Exporter instance is down"
description: "The Node Exporter instance is down, please check soon as possible"
Enable and start the prometheus service
# systemctl enable --now prometheus.service Created symlink /etc/systemd/system/multi-user.target.wants/prometheus.service → /usr/lib/systemd/system/prometheus.service.
Check the status of the prometheus service.
# systemctl status prometheus.service
● prometheus.service - Prometheus service monitoring system and time series database
Loaded: loaded (/usr/lib/systemd/system/prometheus.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-08-12 22:03:57 CEST; 6s ago
Docs: https://prometheus.io/docs/introduction/overview/
man:prometheus(1)
Main PID: 49560 (prometheus)
Tasks: 12 (limit: 4647)
Memory: 31.9M
CPU: 102ms
CGroup: /system.slice/prometheus.service
└─49560 /usr/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus --web.console.libraries=/etc/prometheus/consol>
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.753Z caller=head.go:645 component=tsdb msg="Replaying on-disk memory mappable chunks if any"
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.753Z caller=head.go:659 component=tsdb msg="On-disk memory mappable chunks replay completed" dur>
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.754Z caller=head.go:665 component=tsdb msg="Replaying WAL, this may take a while"
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.754Z caller=head.go:717 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.754Z caller=head.go:722 component=tsdb msg="WAL replay completed" checkpoint_replay_duration=32.>
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.755Z caller=main.go:758 fs_type=XFS_SUPER_MAGIC
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.755Z caller=main.go:761 msg="TSDB started"
Aug 12 22:03:57 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:57.756Z caller=main.go:887 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml
Aug 12 22:03:58 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:58.005Z caller=main.go:918 msg="Completed loading of configuration file" filename=/etc/prometheus/p>
Aug 12 22:03:58 fedora prometheus[49560]: level=info ts=2021-08-12T20:03:58.006Z caller=main.go:710 msg="Server is ready to receive web requests."
Add the following firewall rules for Prometeus and the Alertmanager.
$ sudo firewall-cmd --add-port=9091/tcp --permanent success $ sudo firewall-cmd --add-port=9093/tcp --permanent success $ sudo firewall-cmd --reload success
As always, the logs are useful in order to understand what’s happening with your programs.
When an alerts is sent from Prometheus to the Alermanager, then the Alertmanager sends an HTTP POST request to the caller_prometheus_webhook. In this example we’ve used the /sms_before_call endpoint and as consequence an SMS will be sent soon as possible and later, the phone call.
2021-08-12 18:45:01,803 Call/Message 'The Node Exporter instance is down, please check soon as possible.' for '+393312345678' through the endpoint 'sms_before_call' 2021-08-12 18:45:01,807 - 172.19.0.84 [12/Aug/2021:16:45:01 +0000] "POST /sms_before_call HTTP/1.1" 200 180 "-" "Alertmanager/"
When the caller_prometheus_webhook receives the POST request from the Alertmanager it does other POST requesto to the caller_sms to send the message to the contact configured in prometheus_webhook_receivers. Through the SMS service provider.
2021-08-12 18:45:01,812 Sending the SMS message 'The Node Exporter instance is down, please check soon as possible.' to '+393312345678'
2021-08-12 18:45:01,862 - POST Request: https://api.twilio.com/2010-04-01/Accounts/C3RTyd674gtalirS567q25687g57980gtr53/Messages.json
2021-08-12 18:45:01,862 - PAYLOAD: {'To': '+393312345678', 'From': '+15596123456', 'Body': 'The Node Exporter instance is down, please check soon as possible.'}
2021-08-12 18:45:02,543 - POST Response: 201 {"sid": "ABcDEFGhIJKLMNoPqRsTU1234565671z", "date_created": "Thu, 12 Aug 2021 18:45:02 +0000", "date_updated": "Thu, 12 Aug 2021 18:45:02 +0000", "date_sent": null,
"account_sid": "C3RTyd674gtalirS567q25687g57980gtr53", "to": "+393312345678", "from": "+15596123456", "messaging_service_sid": null, "body": "The Node Exporter instance is down, please check soon as possible.",
"status": "queued", "num_segments": "1", "num_media": "0", "direction": "outbound-api", "api_version": "2010-04-01", "price": null, "price_unit": "USD", "error_code": null, "error_message": null,
"uri": "/2010-04-01/Accounts/C3RTyd674gtalirS567q25687g57980gtr53/Messages/ABcDEFGhIJKLMNoPqRsTU1234565671z.json",
"subresource_uris": {"media": "/2010-04-01/Accounts/C3RTyd674gtalirS567q25687g57980gtr53/Messages/ABcDEFGhIJKLMNoPqRsTU1234565671z/Media.json"}}
2021-08-12 18:45:02,544 - 172.19.0.85 [12/Aug/2021:18:45:01 +0000] "POST /None?phone=%2B393312345678&message=The+Node+Exporter+instance+is+down,+please+check+soon+as+possible. HTTP/1.1" 200 178 "-" "Python/3.9 aiohttp/3.7.4.post0"
Some seconds or minutes after the SMS (configured in sms_before_call_wait_seconds) the asterisk_asterisk_call starts the calls round against the receiver number.
seconds_to_forget = 300 times_to_dial = 3
seconds_to_forget is the time window where asterisk_recall will try to recall the receiver. times_to_dial is the number of times to retry to call.
2021-08-12 18:47:02,655 - 172.19.0.81 [12/Aug/2021:18:47:02 +0000] "POST /asterisk_init?phone=00393312345678&message=The+Node+Exporter+instance+is+down,+please+check+soon+as+possible. HTTP/1.1" 200 178 "-" "Python/3.9 aiohttp/3.7.4.post0" 2021-08-12 18:47:22,690 Asterisk server 'http://192.168.122.234:8088' response: 201. Playing audio 'e23c1ebc.wav' to the channel '1628886822.1' 2021-08-12 18:47:22,694 Restoring the call control to the PBX on the channel '1628886822.1' 2021-08-12 18:47:22,694 - 172.19.0.81 [12/Aug/2021:18:47:22 +0000] "POST /play?asterisk_chan=1628886822.1&msg_chk_sum=e23c1ebc HTTP/1.1" 200 178 "-" "Python/3.9 aiohttp/3.7.4.post0" 2021-08-12 18:48:17,711 - 172.19.0.81 [12/Aug/2021:18:48:17 +0000] "POST /asterisk_init?phone=00393312345678&message=The+Node+Exporter+instance+is+down,+please+check+soon+as+possible. HTTP/1.1" 200 178 "-" "Python/3.9 aiohttp/3.7.4.post0" 2021-08-12 18:48:32,391 Asterisk server 'http://192.168.122.234:8088' response: 201. Playing audio 'e23c1ebc.wav' to the channel '1628886897.2' 2021-08-12 18:48:32,393 - 172.19.0.81 [12/Aug/2021:18:48:32 +0000] "POST /play?asterisk_chan=1628886897.2&msg_chk_sum=e23c1ebc HTTP/1.1" 200 178 "-" "Python/3.9 aiohttp/3.7.4.post0" 2021-08-12 18:48:32,393 Restoring the call control to the PBX on the channel '1628886897.2'
When the number 4 is not pressed by the receiver/callee, this component will recall again (times_to_dial).
2021-08-12 18:10:56,388 - Using the default path 'config/caller_config.toml' 2021-08-12 18:48:17,679 Retry to call phone number: '00393312345678' to play the message: 'The Node Exporter instance is down, please check soon as possible.' - Total retry period: '300' seconds
This component manages and records into the asterisk_ws_events table of the database the events of the Asterisk PBX when the py-phone-caller components are managing the call.
2021-08-12 18:47:22,695 Response for the playing audio 'e23c1ebc.wav' on the Asterisk channel '1628886822.1': '{"status": 201}'
2021-08-12 18:48:32,394 Response for the playing audio 'e23c1ebc.wav' on the Asterisk channel '1628886897.2': '{"status": 201}'
The call_register component writes all the managed calls into the calls table. An example of table structure from the assets/DB/db-schema.sql file:
CREATE TABLE calls (
id integer NOT NULL,
phone character varying(64),
message character varying(1024),
asterisk_chan character varying(64),
msg_chk_sum character varying(64),
call_chk_sum character varying(64),
unique_chk_sum character varying(64),
times_to_dial smallint,
dialed_times smallint,
seconds_to_forget integer,
first_dial timestamp without time zone,
last_dial timestamp without time zone,
heard_at timestamp without time zone,
acknowledge_at timestamp without time zone,
cycle_done boolean DEFAULT false
);
You can send messages and place calls from the terminal. This can be useful if you don’t intend to use the Prometheus monitoring system. You can trigger the messages or calls from cron or other scripts, for example.
An example of the payload sent from the Prometheus Alert Manager
The test-alert-from-the-alertmanager.json file:
{
"receiver":"webhook",
"status":"firing",
"alerts":[
{
"status":"firing",
"labels":{
"alertname":"TestAlertFromAlertmanager",
"instance":"localhost:9090",
"job":"prometheus"
},
"annotations":{
"description":"This text will be an audio message in order to verify if the setup is working",
"summary":"our summary"
},
"startsAt":"2021-03-02T21:52:26.558311875+01:00",
"endsAt":"0001-01-01T00:00:00Z",
"generatorURL":"http://prometheus:9090/graph"
}
],
"groupLabels":{
"alertname":"TestAlertFromAlertmanager",
"job":"prometheus"
},
"commonLabels":{
"alertname":"TestAlertFromAlertmanager",
"instance":"localhost:9090",
"job":"prometheus"
},
"commonAnnotations":{
"description":"our description",
"summary":"our summary"
},
"externalURL":"http://alertmanager:9093",
"version":"4",
"groupKey":"{}:{alertname=\"TestAlertFromAlertmanager\", job=\"prometheus\"}"
}
Make an HTTP POST request to simulate a Prometheus Alert.
$ curl --header "Content-Type: application/json" -X POST -d @ansible_py-phone-caller/alert.json http://127.0.0.1:8084/sms_before_call
{"status": "200"}
You can start a call from the shell using the curl command. Please pay attention to format of the number that’s using the 00 and the country code 39 because we’re using the Asterisk trunk without dial rules to modify the number. For example if you want to place a call in the UK, the first four numbers will be 0044.
Make a HTTP POST request to place a call from the terminal.
$ curl -X POST "http://127.0.0.1:8081/asterisk_init?phone=00392235896425&message=New%20message%20from%20the%20Fedora%20Server%20shell"
{"status": 200}
Something similar to the previous curl command happens when you want to send a single SMS message. Twilio wants the + symbol instead of the 00 prefix. You will have to use %2B to encod the + symbol.
Make a HTTP POST request to send a SMS message from the terminal.
$ curl -X POST "http://127.0.0.1:8085/send_sms?phone=%2B392235896425&message=New%20message%20from%20the%20Fedora%20Server%20shell"
{"status": 200}
In future versions I hope to make this more user-friendly.
By following the steps in this guide you can create a mini pager system. py-phone-caller isn’t intended to be used in mission critical environments because it is not yet ready for that kind of workload.
Thanks for reading. I hope this article was useful to you.
bressers)
on November 22, 2021 12:01 AM
Josh and Kurt talk to David A. Wheeler about everything OpenSSF. The Open Source Security Foundation is part of the Linux Foundation, and there are 6 OpenSSF working groups. David does a great job explaining how the OpenSSF works and what the 6 working groups are doing. The working group are (in no particular order): Identifying Security Threats, Security Tooling, Best Practices, Vulnerability Disclosures, Digital Identity Attestation, Securing Critical Projects.
<audio class="wp-audio-shortcode" controls="controls" id="audio-2608-2" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/secure/opensourcesecuritypodcast/Episode_298_David_A_Wheeler_discusses_the_OpenSSF.mp3?_=2" type="audio/mpeg">https://traffic.libsyn.com/secure/opensourcesecuritypodcast/Episode_298_David_A_Wheeler_discusses_the_OpenSSF.mp3</audio>
admin)
on November 20, 2021 02:39 PM
This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/).
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
Duffy is a system within CentOS CI Infra which allows tenants to provision and
access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the current state
of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.
Move current Fedora CoreOS pipeline from the centos-ci OCP4 cluster to the newly
deployed fedora infra OCP4 cluster.
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.
Kindest regards,
CPE Team
The post CPE Weekly Update – Week of November 15th – 19th appeared first on Fedora Community Blog.
admiyo)
on November 19, 2021 03:54 PM
For the next couple tasks I want to do in assembly, I need to be able to inspect an array of numbers. This is useful for debugging searching and sorting algorithms. Since my last attempt to convert binary to ASCII was so ugly, I figured I would clean that up at the same time.
It turns out I can use the reverse code as well.
Unlike my last couple of posts where I show each of the interim steps, I have made this one work, and will just go through the final product. There was a lot of trial and error getting this to work, and I can see the need for getting organized in Assembly. The scale of the programs will quickly get beyond the scope of what I can keep in my head.
One thing this code required me to learn was how to nest function calls. I have two functions, one which calls the other. Thus, the return location for the first needs to get pushed on the stack before it calls the second, and needs to get popped off the stack at the end.
Here is the program main body. It is a function call, and a system call
_start:
bl display_array
/* syscall exit (int status) */
mov x0, #0 /* status := 0 */
mov w8, #93 /* exit is syscall #1 */
svc #0
I can now see how the C programming language evolved from assembler macros.
Here is the logic to convert binary to ASCII decimal. It puts into the provided buffer in reverse order, from least to most significant digit. This little endian approach means we do not have to pre-calculate the size of the buffer.
display_array:
str LR, [SP, #16]!
/*read the first value out of the array. In the final implementation, I need to be able
to advance this pointer value by bvalue */
mov x0, #0
ldr x6, =Array
loop1:
/* this is the pointer to location where we write
the latest value. At the end of the loop, it points
to the end of the text written. */
ldr x8, =msg /* buf := msg */
ldr x7, =msg
/*x2 has the result of the msub that we want to use
as the basis on the second and additional iterations.
by loading the initial value into x2, we keep that logic
at the start of the loop. In doing so, we allow x2 to
stay unchanged at the end of the loop, where we us it
for the comparison. */
ldr w2, [x6]
mov x1, #10
loop2:
/* caluculate modulus of the working binary number */
mov x0, x2
udiv x2, x0, x1
msub x3, x2, x1, x0
/* convert binary to ascii digit */
add x3, x3, #48
strb w3, [X8]
add x8, x8 ,#1
cmp x2, #0
B.NE loop2
It does mean we have to reverse the string at the end.
/* reverse the string */
ldr x1, =msg /* buf := msg */
sub x2, X8, X7 /* count = len */
add x2, x2, #1
bl reverse
Append a space and null terminate the string (Probably not needed) and print out the buffer.
mov x3, #32 /*space */
strb w3, [X8]
add x8, x8, #1
mov x3, #0 /*null terminate the string */
strb w3, [X8]
/* calculate the string length of the number we just wrote*/
sub x2, x8, x7
/*syscall write(int fd, const void *buf, size_t count) */
mov x0, #1 /* fd := STDOUT_FILENO */
ldr x1, =msg /* buf := msg */
mov w8, #64 /* write is syscall #64 */
svc #0 /*invoke syscall */
Advance the pointer to the initial buffer by 4 bytes, which is the size of a word. Make sure we don’t go off the end when we loop to the beginning.
add x6, x6, #4
ldr x1, =Array
ldr x2, =ArrayLen /* count = len */
add x2, x1, x2
cmp x6, x2
B.LT loop1
After we print the buffer, print a final newline so we can compare it with the next line.
mov x0, #1 /* fd := STDOUT_FILENO */
ldr x1, =newline /* buf := msg */
ldr x2, =len_newline /* buf := msg */
mov w8, #64 /* write is syscall #64 */
svc #0 /*invoke syscall */
Restore the stack and return to the calling location.
LDR LR, [SP], #16
ret
In AARCH64 assembly, we have 16 General purpose registers. In order to keep from pushing and popping registers onto and off of the stack, I use a separate number of registers for the reverse code, allowing me to leave the values in the registers that are used for the numeric conversions. Thus, my reveser function now looks like this.
reverse:
add X14, X1, 0
add X16, x1, x2
sub X16, X16, #1
loop:
sub X16, X16, #1
ldrb w15, [x14]
ldrb w17, [x16]
strb w15, [X16]
strb w17, [X14]
add X14, X14, #1
cmp X14, X16
b.lt loop
ret
I just added 10 to the register values in the first version.
This function does not call another function, so it does not need to save and restore the return value in LR.
Here is the output
503 87 61 908 170 897 709 901 271 528 834 154 231 303 435 707 424 861
admin)
on November 19, 2021 02:00 PM
Here’s your weekly Fedora report. Read what happened this week and what’s coming up. Your contributions are welcome (see the end of the post)!
Fedora Linux 33 will reach end of life on Tuesday 30 November. The F35 retrospective survey is open through 4 December.
I have weekly office hours on Wednesdays in the morning and afternoon (US/Eastern time) in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else. See the upcoming meetings for more information.
| Conference | Location | Date | CfP |
|---|---|---|---|
| FOSS Backstage | Berlin, DE & virtual | 17–18 Mar | closes 22 Nov |
| SCaLE | Pasadena, CA, US | 5–8 Mar | closes 30 Nov |
The call for F36 Test Days is open.
See the Prioritized Bugs documentation for information on the process, including how to nominate bugs.
| Release | open bugs |
|---|---|
| F33 | 4649 |
| F34 | 5524 |
| F35 | 1805 |
| F36 (rawhide) | 6589 |
The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.
<figure class="wp-block-table">| Proposal | Type | Status |
|---|---|---|
| Package information on ELF objects | System-Wide | FESCo #2687 |
| Stratis 3.0.0 | Self-Contained | Approved |
| Remove .la files from buildroot | Approved | |
| java-17-openjdk as system JDK in F36 | System-Wide | Approved |
| ELN-Extras | System-Wide | Announced |
| Unit Names in Systemd Messages | Self-Contained | Announced |
| Remove Wire Extensions Support | Self-Contained | Announced |
The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.
<figure class="wp-block-table">| Proposal | Type | Status |
|---|---|---|
| RetireARMv7 | System-Wide | Announced |
Have something you want included? You can file an issue or submit a pull request in the fedora-pgm/pgm_communication repo.
The post Friday’s Fedora Facts: 2021-46 appeared first on Fedora Community Blog.
RPMs of PHP version 8.0.13 are available in remi repository for Fedora 35 and remi-php80 repository for Fedora 33-34 and Enterprise Linux (RHEL, CentOS).
RPMs of PHP version 7.4.26 are available in remi repository for Fedora 33-34 and remi-php74 repository Enterprise Linux (RHEL, CentOS).
RPMs of PHP version 7.3.33 are available in remi-php73 repository for Enterprise Linux (RHEL, CentOS).
PHP version 7.2 have reached its end of life and is no longer maintained by the PHP project.
These versions are also available as Software Collections in the remi-safe repository and as module for Fedora and EL ≥ 8.
Version announcements:
Installation: use the Configuration Wizard and choose your version and installation mode.
Replacement of default PHP by version 8.0 installation (simplest):
yum-config-manager --enable remi-php80 yum update
or, the modular way (Fedora and EL ≥ 8):
dnf module reset php dnf module enable php:remi-8.0 dnf update php\*
Parallel installation of version 8.0 as Software Collection
yum install php80
Replacement of default PHP by version 7.4 installation (simplest):
yum-config-manager --enable remi-php74 yum update
or, the modular way (Fedora and EL ≥ 8):
dnf module reset php dnf module enable php:remi-7.4 dnf update php\*
Parallel installation of version 7.4 as Software Collection
yum install php74
Replacement of default PHP by version 7.3 installation (simplest):
yum-config-manager --enable remi-php73 yum update php\*
or, the modular way (Fedora and EL ≥ 8):
dnf module reset php dnf module enable php:remi-7.3 dnf update php\*
Parallel installation of version 7.3 as Software Collection
yum install php73
And soon in the official updates:
To be noticed :
Information:
Base packages (php)
Software Collections (php73 / php74 / php80)
Over the last few years in the Enarx project, we have been struggling with iPXE. Enarx needs a bare-metal infrastructure so that we can have access to the underlying confendial computing hardware. We also have to boot a custom kernel on this hardware. We also want the environment to be reproducable.
Early on we tried using NixOS to get these properties. But this also implied that we had to build our custom kernel on each device. Some of the devices are very slow. So this proved not to be workable. Mostly we settled on a Fedora installation with a kickstart to automate installs. This had… problems.
First, there was the state management. We tried to have a declarative infrastructure by rebooting to install via a kickstart. But since this took ~30 minutes of downtime to reboot the machine, users were incentivized to make local changes. And so the local changes would drift from our declarative install. We needed something faster.
Second, there was the iPXE cipher suites problem. You see, iPXE wants to download the OS for installs over the network. This, of course, means you need TLS encryption for any hope of security. But iPXE only supports ancient cipher suites. You know, the ones modern servers are disabling. We needed something more secure.
What we wanted was the container experience, but on bare-metal. We should always reboot to get the latest OS changes. But the reboots should be fast, not a full re-install. We also didn’t want to bring up infrastructure to manage state. Sure, products exist to solve this problem. But I don’t want more infrastructure to manage my infrastructure. Container registries already exist and don’t require any infrastructure to download and run them. And they are completely declarative.
I just wanted to boot a container.
Wyrcan is a bootloader that boots into a container. That’s all it does.
But of course, that’s not the only thing that Wyrcan implies. Using Wyrcan to boot a container also means that you can use a tried and trusted software packaging ecosystem to have a bare-metal OS that is:
Stateless: Booting a container with Wyrcan means that nothing is installed
on the disk. There is no state to manage except the state you put into
your container. You never have to worry about whether packages are updated:
you can schedule reboots to make sure you always have the latest OS. And if
all your mounts of local storage are noexec, you can just reboot when
compromised.
Memory-Resident: The full operating system is resident in RAM. That means it is fast. However, you can also set up swap in your container so that unused pages are written to disk, saving memory for your application.
Declarative: Your bare-metal operating system is developed using the same delarative tooling that you have come to expect from the container development pipeline. But your OS config in git. Host it in your favorite git forge (GitHub, GitLab, Bitbucket, etc). Build the images automatically. Host them in your favorite container repo.
Wyrcan supports three modes of operation:
Using the direct boot mode of operation, you just point your VM or (i)PXE-enabled system at the Wyrcan kernel and initrd. You can see more details at the project website.
Download the ISO. Write it to a CD, DVD or USB storage device. Boot it.
On the first boot, you can associate Wyrcan with a kernel image and store this association in an EFI variable for automated boot. Then walk away. Your system that formally couldn’t netboot, now can.
Wyrcan is itself a bootable container. So you can chain from one Wyrcan instance to another. This allows you to upgrade to the latest version of Wyrcan without physically managing a machine.
Check out Wyrcan’s website. We have many more examples, including numerous bootable containers to try from all the distributions you love. If you need a feature or find a bug, we’d love to hear from you.
Get Wyrcan!
admiyo)
on November 18, 2021 02:02 AM
This is not my finest code. It is the worst case of “just make it work” I’ve produced all week.
But it runs.
What does it do? It takes the first binary number in an array, and converts it to decimal. It assumes that the number is no more than 3 digits long.
It divides that number by 100 to get the 100s digit. Then it multiples that number by 100, assuming that it has gotten truncated. It subtracts that value from the original number to chop off the 100s digit, and divides the result by 10 to get the 10s digit.
Similar process to get the 1s digit.
EDIT: Here is the plan for how to do it better:
It sticks these character by character into the Hello World Buffer, and calls the write system call.
.data
Array: .word 503,87,61,908,170,897,709,901,271,528,834,154,231,303,435,707,424,861
ArrayLen = . - Array
msg:
.ascii "Hello, World!\n"
len = . - msg
.text
// app entry point
.globl _start
_start:
/*syscall write(int fd, const void *buf, size_t count) */
mov x0, #1 /* fd := STDOUT_FILENO */
ldr x1, =msg /* buf := msg */
ldr x2, =len /* count = len */
/* make a copy of the buffer pointer, as we are going to be writing to it character by
character, and we need to advance the pointer. Yes, we could reuse x1 and just reset
it at the end. That would be better. */
ldr x8,=msg
/*read the first value out of the array. In the final implementation, I need to be able
to advance this pointer value by bvalue */
ldrsw x3, =Array
ldrsw x4, [x3]
/* Divide by 100 to isolate the 100s digit */
mov x5, #100
sdiv x7, x4, x5
ADD w6, w7, #48
strb w6, [X8]
/*advance the write buffer pointer, so next time we write to the second character */
ADD X8, X8, #1
ldrsw x4, [x3]
/* restore the hundreds digit to the hundreds place so we can chop it off the original
number */
mul x7, x7, x5
sub w4, w4, w7
/* divide the result by 10 to isolate just the 10s digit */
mov x5, #10
sdiv x6, x4, x5
ADD w6, w6, #48
strb w6, [X8]
ADD X8, X8, #1
ldrsw x4, [x3]
/* if we remove the #48 we can reuse this register. Should have done this last time */
sub w6, w6, #48
/* get the 10s digit back into the 10s place */
mul x6, x6, x5
add x7, x7, x6
/*at this point, the x7 register has the original value without the 1s digit. */
sub w6, w4, w7
ADD w6, w6, #48
strb w6, [X8]
mov w8, #64 /* write is syscall #64 */
svc #0 /*invoke syscall */
/* syscall exit (int status) */
mov x0, #0 /* status := 0 */
mov w8, #93 /* exit is syscall #1 */
svc #0
Here is the output.
$ make shellsort ; ./shellsort
as -g -o shellsort.o shellsort.s
ld -o shellsort shellsort.o
503lo, World!
I promise I will clean this up.
Tomorrow.
admiyo)
on November 18, 2021 12:55 AM
Sometime your shell scripts get out of control. Sometimes you are proud of them. Sometimes….both.
I need to be able to re-add a bunch of nodes to an OpenStack cluster on a regular basis. Yes, I could do this with Ansible, but, well, Ansible is great for doing something via SSH, and this just needs to be done here and now. So shell is fine.
This started as a one liner, and got a bit bigger.
This is a utility script that I keep modifying as I need new things from it. I have not cleaned it up or anything, but I find it works OK as is and is not too big that I lose sight of what it is doing.
It reads a csv file that has the list of nodes in it. The order of fields is
name,ipmi_ip, mac1, mac2,resource-class
The second MAC address is ignored for now.
#! /usr/bin/bash
#set -x
check_enroll(){
ironic_host_name=$1
ironic_ipmi_address=$2
ironic_pxe_interface_mac=$3
openstack baremetal node show $ironic_host_name 2>&1 > /dev/null
if [ $? -eq 0 ]
then
echo $ironic_host_name already exists
return 0
else
echo $ironic_host_name does not yet exist
return 1
fi
}
ironic_enroll(){
ironic_host_name=$1
ironic_ipmi_address=$2
ironic_pxe_interface_mac=$3
ironic_resource_name=$4
echo "ironic_host_name: " $ironic_host_name
echo "ironic ipmi interface: " $ironic_ipmi_address
echo "ironic pxe interface mac address: " $ironic_pxe_interface_mac
openstack baremetal node show $ironic_host_name 2>&1 > /dev/null
if [ $? -eq 0 ]
then
echo $ironic_host_name already exists
return [0]
fi
echo enrolling $ironic_host_name
set -x
openstack baremetal node create \
--driver ipmi \
--name ${ironic_host_name} \
--driver-info ipmi_username=${IPMI_USERNAME} \
--driver-info ipmi_password=${IPMI_PASSWD} \
--driver-info ipmi_address=${ironic_ipmi_address} \
--driver-info ipmi_terminal_port=8901 \
--resource-class $ironic_resource_name \
--property cpus=1 \
--property memory_mb=512 \
--property local_gb=1 \
--property cpu_arch=arm64 \
--property capabilities='boot_mode:uefi' \
--driver-info deploy_kernel=${IRONIC_DEPLOY_KERNEL} \
--driver-info deploy_ramdisk=${IRONIC_DEPLOY_INITRD}
set +x
# Add this to enable console
# --console-interface ipmitool-socat \
# --deploy-interface iscsi \
# --deploy-interface direct \
# --raid-interface agent \
sleep 10
NODE_UUID=$(openstack baremetal node list | grep ${ironic_host_name} | awk '{print $2}' | tr '\012' ' ' | awk '{print $1}')
echo "*** IRONIC NODE UUID = " ${NODE_UUID} " ***"
echo "*** IRONIC Baremetal node show" ${NODE_UUID} " ***"
openstack baremetal node show ${NODE_UUID}
echo "*** IRONIC Baremetal node console enable" ${NODE_UUID} " ***"
openstack baremetal node console enable ${NODE_UUID}
echo "*** IRONIC Creating baremetal port added for node " ${NODE_UUID} " ***"
openstack baremetal port create ${ironic_pxe_interface_mac} --node ${NODE_UUID}
sleep 10
echo "*** IRONIC baremetal node validate " ${NODE_UUID} " ***"
openstack baremetal node validate ${NODE_UUID}
sleep 10
echo "*** IRONIC baremetal node manage " ${NODE_UUID} " ***"
openstack baremetal node manage ${NODE_UUID}
sleep 10
echo "*** IRONIC baremetal node inspect " ${NODE_UUID} " ***"
openstack baremetal node inspect ${NODE_UUID}
sleep 10
echo "*** IRONIC Baremetal node show" ${NODE_UUID} " ***"
openstack baremetal node show ${NODE_UUID}
echo "*** IRONIC Baremetal node provide" ${NODE_UUID} " ***"
openstack baremetal node provide ${NODE_UUID}
echo "*** IRONIC Baremetal node show" ${NODE_UUID} " ***"
openstack baremetal node show ${NODE_UUID}
# Show Hypervisor Stats
echo "*** OpenStack Hypervisor stats show ***"
openstack hypervisor stats show
echo "*** OpenStack Hypervisor show " ${NODE_UUID} " ***"
openstack hypervisor show ${NODE_UUID}
}
ipmi_check(){
ironic_host_name=$1
ironic_ipmi_address=$2
ironic_pxe_interface_mac=$3
echo ipmitool -H $ironic_ipmi_address -U $IPMI_USERNAME -I lanplus -P $IPMI_PASSWD power status
ipmitool -H $ironic_ipmi_address -U $IPMI_USERNAME -I lanplus -P $IPMI_PASSWD power status
}
IPMI_USERNAME=ADMIN
IPMI_PASSWD=`cat ipmi_passwd.txt`
PROJECT_DIR=$(pwd)
DEPLOY_KERNEL='ironic-deploy-kernel'
DEPLOY_INITRD='ironic-deploy-initrd'
IRONIC_DEPLOY_KERNEL=$( openstack image show ${DEPLOY_KERNEL} -f value -c id )
IRONIC_DEPLOY_INITRD=$( openstack image show ${DEPLOY_INITRD} -f value -c id )
echo "Ironic Deploy Kernel: " ${IRONIC_DEPLOY_KERNEL}
echo "Ironic Deploy Initrd: " ${IRONIC_DEPLOY_INITRD}
#input='jades.csv'
#input='mystiques.csv'
input='nodes.csv'
while IFS= read -r line
do
IFS=', ' read -r -a array <<< "$line"
echo Processing ${array[0]}
check_enroll ${array[0]} ${array[1]} ${array[2]}
if [ $? -eq 1 ]
then
ipmi_check ${array[0]} ${array[1]} ${array[2]}
ironic_enroll ${array[0]} ${array[1]} ${array[2]} ${array[4]}
fi
done < "$input"
If I were to rework this, I would unroll the loop, and perform all of the same actions first; create the nodes, then port, validate etc. That would avoid the need for the sleep commands when doing it in bulk. However, for just adding a single node, it would break things, and that is more important right now.
Here is my current nodes.csv file.
mystique01-r097,10.76.97.185,98:03:9B:AD:49:0C,98:03:9B:AD:49:0D,baremetal-mystique
jade01-r097,10.76.97.173,1c:34:da:71:01:66,1c:34:da:71:01:67,baremetal-jade2
jade02-r097,10.76.97.174,1c:34:da:51:a0:8c,1c:34:da:51:a0:8d,baremetal-jade2
jade03-r097,10.76.97.175,0c:42:a1:52:1d:8c,0c:42:a1:52:1d:8d,baremetal-jade2
jade04-r097,10.76.97.176,1c:34:da:51:d6:c0,1c:34:da:51:d6:c1,baremetal-jade2
jade05-r097,10.76.97.177,98:03:9b:ad:67:20,98:03:9b:ad:67:21,baremetal-jade2
jade06-r097,10.76.97.178,1c:34:da:5a:c7:b0,1c:34:da:5a:c7:b1,baremetal-jade2
jade07-r097,10.76.97.179,98:03:9b:ad:67:38,98:03:9b:ad:67:39,baremetal-jade2
jade08-r097,10.76.97.180,1c:34:da:72:95:4e,1c:34:da:72:95:4f,baremetal-jade2
jade09-r097,10.76.97.181,b8:59:9f:c7:5c:6e,b8:59:9f:c7:5c:6f,baremetal-jade2
jade10-r097,10.76.97.182,98:03:9b:ad:7e:7c,98:03:9b:ad:7e:7d,baremetal-jade2
jade11-r097,10.76.97.183,0C:42:A1:45:3D:24,0C:42:A1:45:3D:25,baremetal-jade2
jade12-r097,10.76.97.184,B8:59:9F:AC:15:4C,B8:59:9F:AC:15:4D,baremetal-jade2
renault)
on November 17, 2021 09:07 PM
Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 35 !
Bien entendu je passe sous silence mon blog et le forum de fedora-fr.
Soit 4 sites sur les 25 contactés.
Soit 6 sites.
Le nombre de sites parlant de Fedora 35 est en légère augmentation, en particulier auprès des non sollicités.
La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :
Si vous avez connaissance d'un autre lien, n'hésitez pas à partager !
Rendez-vous pour Fedora 36.
admin)
on November 17, 2021 09:00 PM
We will be updating and rebooting various servers to bring them up to date. During the outage window any services may be up and down as proxies and gateways are rebooted. Any fedoraproject services may be affected with the exception of mirrorlists and static web content.
czanik)
on November 17, 2021 12:34 PM
One of the most popular applications to feed Splunk with syslog messages is syslog-ng. However not everyone is happy to work on the command line anymore. This is where syslog-ng store box (SSB), an appliance built around syslog-ng, can help. The SSB GUI provides you not only with an easyto-use interface to configure most syslog-ng features, but also a search interface and complete log life cycle management. It can forward log messages to several destinations, recently also to Splunk’s HTTP Event Collector (HEC).
From this blog you can learn about how SSB fits into your logging infrastructure and how to configure SSB for Splunk: https://www.syslog-ng.com/community/b/blog/posts/sending-logs-from-syslog-ng-store-box-to-splunk
With more games being developed with the Godot engine, we need to learn how to package these games for Fedora.
Developing a game is complex. The requirements for each game differ. In the past developers created new game engines for each game. Over time game engines become more generic. They adapt to cover a style of game. Some engines can create a wide variety of games.
Godot is a well known open source game engine. Both open source and closed source games use the system. The Godot packages for Fedora run these games but no RPM package examples exist.
Much of the packaging is the same regardless of the application. RPM spec files need summary, version, license, description, etc. For build requirements, you need the godot-headless package. Godot publishes a pck file but requires a graphical user interface to run. Godot headless builds a project without needing a graphical user interface.
Linux cannot run a pck file. By adding godot-runner to the requirement section of the spec, the game can run on systems which install the RPM. The pck file is not completely platform independent But I believe it will work on all Linux systems. The build architecture can be set to noarch for this reason.
The same setup macro for another program can extract the tgz file. No macros exist for building Godot projects. You call godot-headless with ‐‐export-pack option. You specify the export name and the output filename. The install section simply needs to create a directory in $RPM_BUILD_ROOT/%{_datadir}/%{name} and copy the output file. Specify the files section and you are ready to build.
...
BuildRequires: godot-headless
Requires: godot-runner
BuildArch: noarch
...
%build
godot-headless --export-pack Linux64 pigeonascent.pck
%install
mkdir -p $RPM_BUILD_ROOT/%{_datadir}/%{name}
install -p -m 644 pigeonascent.pck $RPM_BUILD_ROOT%{_datadir}/%{name}
%files
%{_datadir}/%{name}
...
Anyone can run the game by installing the package and running godot-runner with the specified pck file. Searching for the application on the GNOME desktop will not find it. Searching for the application in GNOME Software will not find it.
Two files can fix these problems but you may need a third. The first file allows you to easily run the game from the GNOME desktop. The desktop file has the name of the program, how to execute the program, and other details.
[Desktop Entry] Name=Pigeon Ascent Comment=Take care of your own pigeon as they fight Exec=godot-runner --main-pack /usr/share/pigeonascent/pigeonascent.pck Terminal=false Type=Application Icon=pigeonascent Categories=Game;RolePlaying;
In addition to the Exec entry, many desktop files include TryExec that tests if the executable exists in the path. If you include it, it would be godot-runner. In this example we call godot-runner. We could create a shell script to allow you to run the program easily from the command line.
For the icon you may be able to reuse the icon in the Godot project. If it is not the right size or you want a scalable vector version, you will need to create it. For Pigeon Ascent the icon image needs to be one pixel bigger in both directions.
The other file gives meta information to GNOME Software. It contains yet another name and description. It also has links to the website and screenshots. For games, Fedora includes the Open Age Rating System. This gives descriptors to allow parents to determine if the game content is acceptable. The Open Age Rating System generates this section after you enter the information for the game.
<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2021 Dennis Payne <dulsi@identicalsoftware.com> -->
<component type="desktop-application">
<id>pigeonascent</id>
<metadata_license>FSFAP</metadata_license>
<project_license>MIT</project_license>
<name>Pigeon Ascent</name>
<summary>Take care of your own pigeon as they fight</summary>
<description>
<p>
Take care of your own pigeon as they fight increasingly stronger foes, and
then facing the legendary Pigeon God at the end… can you keep death far from
your bird?
</p>
</description>
<launchable type="desktop-id">pigeonascent.desktop</launchable>
<screenshots>
<screenshot type="default">
<image>https://static.jam.vg/raw/777/31/z/30974.png</image>
</screenshot>
<screenshot>
<image>https://static.jam.vg/raw/777/31/z/3097c.png</image>
</screenshot>
<screenshot>
<image>https://static.jam.vg/raw/777/31/z/30982.png</image>
</screenshot>
</screenshots>
<url type="homepage">https://escada-games.itch.io/pigeon-ascent</url>
<releases>
<release version="1.5.2" date="2021-07-16" />
</releases>
<content_rating type="oars-1.1">
<content_attribute id="violence-cartoon">moderate</content_attribute>
<content_attribute id="language-humor">mild</content_attribute>
</content_rating>
</component>
Some additional changes are needed to the RPM spec to include these files.
Sometimes Godot is insufficient to perform the tasks needed for a game. Gdnative allows C++ code to be added to a project. The gdnative code can be packaged as a separate project if it is used by multiple Godot projects. Unfortunately you need both godot cpp and header files which use the same download filename. Instead of using a url for the source tag in the spec file, specify the renamed file and include a comment above with the url.
# https://github.com/godotengine/godot-cpp/archive/refs/tags/godot-3.3.4-stable.tar.gz Source1: godot-cpp-godot-3.3.4-stable.tar.gz # https://github.com/godotengine/godot-headers/archive/refs/tags/godot-3.3.4-stable.tar.gz Source2: godot-headers-godot-3.3.4-stable.tar.gz
Building gdnative assumes the godot cpp and headers are one directory above gdnative project. The following prep and build code builds the gdnative project.
%prep
%setup -q
cd ..
rm -rf godot-cpp
rm -rf godot-cpp-godot-3.3.4-stable
%setup -T -D -b 1
cd ..
rm -rf godot-headers-godot-3.3.4-stable
%setup -T -D -b 2
%build
cd ..
mv godot-cpp-godot-3.3.4-stable godot-cpp
rmdir godot-cpp/godot-headers
mv godot-headers-godot-3.3.4-stable godot-cpp/godot-headers
cd godot-cpp
scons platform=linux generate_bindings=yes -j4
cd ../%{name}-%{version}
mkdir bin
scons platform=linux
The install section copies the dynamic library to the library directory. If you build an executable for your godot project, the gdnative library works in the same directory. To avoid duplication we create the pck file and use godot-runner. When running with godot-runner, the library needs to be in the same directory as specified in the project. Typically this will be gdnative/linuxbsd.
Install the godot project the same as a project without gdnative. Add to the install section to create a gdnative/linuxbsd directory. Create a symlink to gdnative library. In order to run the game, you need to add a Path entry to the desktop file and set it to the directory with the pck file. This causes the program to run from that directory which allows it to find the gdnative library.
Pigeon Ascent is awaiting approval to be added to Fedora along with Gdnativegamerzilla. My Pinball Disc Room requires Gdnativegamerzilla before submitting. The developers of Pigeon Ascent also created Diver Down which I recommend. Godot Wild Jams are good places to look for Godot games.
Development on Godot 4 continues. It will not be backward compatible. I do not know if Fedora will ship both versions or if we will need to convert games to the new Godot. They plan on having a tool to help with the conversion.