Archive for the 'Fedora' Category

Korora 21 available

It has taken a few weeks longer than we had hoped, but Korora 21 images are now available. I strongly recommend downloading with BitTorrent if you can.

The 21 beta was quite successful and we were able to make some minor changes to help improve the overall experience. Users who are currently on the beta need not re-install, updates are provided via the package manager. Users who are on 20 may consider upgrading, however this is not necessary as version 20 is supported for another 6 months or so.

Creating a DMZ in OpenWRT

In computing, a DMZ (demilitarized zone) is a method for separating untrusted traffic from a trusted network. One of the most common implementations of this would be for supporting a publicly accessible server (such as web) on a local internet connection. The server sits in the DMZ and can be accessed from the Internet, but it cannot access the trusted network.

OpenWRT probably needs no introduction, the brilliant open source and community driven Linux based embedded router stack. I run it on my Netgear WNDR3800.

Netgear WNDR3800 running OpenWRT

Netgear WNDR3800 running OpenWRT

I have an ODRIOD-U3 (little ARM box) running Fedora, which runs a web server. This is what I want to make publicly available in my DMZ.

So, how to create a DMZ in OpenWRT? Some commercial routers have a single button “make a DMZ” and everything is handled behind the scenes for you. Not so with OpenWRT; it’s powerful, transparent, and only does what you tell it to, so we have to create it manually.
Continue reading ‘Creating a DMZ in OpenWRT’

Korora 21 beta images available

Korora 21 beta images are now available! Please leave a comment or ping me on social media with any issues or ideas so we can make it better.

Single emergency mode with systemd

Just to remind myself.. add to the kernel line, or if that fails, try init=/sbin/sh and remove both quiet and rhgb options.

Afterwards, exit or:
exec /sbin/init

Can also enable debug mode to help investigating problems with systemd.log_level=debug

You can get a console early on in the boot process by enabling debug-shell:
systemctl enable debug-shell.service

Creating certs and keys for services using FreeIPA (Dogtag)

The default installation of FreeIPA includes the Dogtag certificate management system, a Certificate Authority for your network. It manages expiration of certificates and can automatically renew them. Any client machines on your network will trust the services you provide (you may need to import the IPA CA cert).

There are a number of ways to make certificates. You can generate a certificate signing request or you can have Dogtag manage the whole process for you. You can also create individual cert and key files or put them into a nss database. My preferred method is to use individual files and have Dogtag do the work for me.

If you so desire, you can join your servers to the realm in just the same manner as a desktop client. However, even if they are not joined to the realm you can still create certs for them! You will need to run a few additional steps though, namely creating DNS records and adding the machine manually.

Let’s create a certificate for a web server on www.test.lan ( which is has not joined our realm.

SSH onto your IPA server and get a kerberos ticket.
[user@machine ~]# ssh root@ipa-server.test.lan
[root@ipa-server ~]# kinit admin

If the host is not already in the realm, create DNS entries and add the host.
[root@ipa-server ~]# ipa dnsrecord-add test.lan www --a-rec
[root@ipa-server ~]# ipa dnsrecord-add 100 --ptr-rec www.test.lan.
[root@ipa-server ~]# ipa host-add www.test.lan

Add a web service for the www machine.
[root@ipa-server ~]# ipa service-add HTTP/www.test.lan

Only the target machine can create a certificate (IPA uses the host kerberos ticket) by default, so to be able to create the certificate on your IPA server you need to allow it to manage the web service for the www host.
[root@ipa-server ~]# ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan

Now create the cert and key.
[root@ipa-server ~]# ipa-getcert request -r -f /etc/pki/tls/certs/www.test.lan.crt -k
/etc/pki/tls/private/www.test.lan.key -N CN=www.test.lan -D
www.test.lan -K HTTP/www.test.lan

Now copy that key and certificate to your web server host and configure apache as required.
[root@ipa-server ~]# rsync -P /etc/pki/tls/certs/www.test.lan.crt /etc/pki/tls/private/www.test.lan.key root@www.test.lan:

You can also easily delete keys so that they aren’t tracked and renewed any more, first get the request id.
[root@ipa-server ~]# ipa-getcert list

Take note of the id for the certificate you want to delete.
[root@ipa-server ~]# getcert stop-tracking -i [request id]

A CRL (certificate revocation list) is automatically maintained and published on the IPA server at ​https://ipa-server.test.lan/ipa/crl/MasterCRL.bin

FreeIPA How To (Fedora)

My OpenLDAP How To (Fedora) article has proven very popular over the years but now I’ve mostly moved on to FreeIPA.

So I thought it might be good to write up a FreeIPA How To (Fedora) article (CC BY-SA 4.0) in case it’s useful for anyone else out there.

Decorating (a)kmod packages with modalias info for use with RPM

Originally posted by firnsy at Korora Project news.

Whilst developing Pharlap, our utility for easing the installation and removal of drivers, we came across a big hurdle that other distributions had seemingly solved. The hurdle was being able to identify packages that provide support for a particular piece of hardware. Our initial workarounds used a dedicated map and for a while it was sufficient but it wasn’t ideal. Over time, the frustration of it’s inelegance grew and thus began our journey to investigate a more elegant solution.

Before developing Pharlap, there was Jockey, originally ported over from Ubuntu land by Hedayat Vatankhah for his Parsidora Fedora Remix. We started to contribute to and incorporate Hedayat’s work around version 16. At this time Hedayat, proposed the integration of Jockey into the RPM Fusion repositories which was met with a level of positivity. Could this already be implemented and we just don’t know? Darn, doesn’t look like it. Let’s continue.

So I mentioned earlier that other distributions had already solved this problem and indeed they had Debian/Ubuntu decorate their kernel module packages with the modaliases that the modules provide support for. Awesome? Yes it is! That allows the higher level package utilities to query the “provides” information using a device ID of interest.

So with that in mind, we set out to identify how we could adequately decorate kmod and akmod packages with appropriate modalias information.

kmod Packages

Starting with kmod packages (more specifically those rpm packages which contain pre-compiled kernel *.ko modules) it turns out that is reasonably trivial to decorate them using the builtin pluggable fileattr decorators of RPM with some post-processed information derived from ‘modinfo’.

To achieve this first build an appropriate “what provides” decorator that can interpret our kernel module files (*.ko). Fortunately this already exists in a standard installation but for reasons I’m not entirely sure of, is not enabled. So we just copy the modalias.prov out of the /usr/lib/rpm/redhat directory as a new file /usr/lib/rpm/kmod.prov.

Here’s the file for reference.

$ cat /usr/lib/rpm/kmod.prov
#! /bin/sh
# heavily based upon find-suggests.ksyms by Andreas Gruenbacher .
# with modifications by Michael Brown
# -- added module versioning info to modalias() symbols
# -- removed code which inspects spec files.
# Initially, dont generate modalias() lines for kernel package. This needs
# additional discussion. Would like to eventually add them for
# completeness, so that we can determine when drivers are folded into
# mainline kernel.
case "$1" in
kernel-module-*) ;; # Fedora kernel module package names start with
# kernel-module.
kernel*) is_kernel_package=1 ;;
if ! [ -z "$is_kernel_package" ]; then
cat > /dev/null
exit 0
print_modaliases() {
declare class=$1 variants=$2 pos=$3
if [ -n "$variants" ]; then
echo "${class:0:pos}[$variants]${class:pos+1}"
[ -z "$class" ] || echo "$class"
combine_modaliases() {
declare tag class variants pos n
read class
while read tag; do
for ((n=0; n<${#class}; n++)); do if [ "*" != "${class:n:1}" -a \ "${class:0:n}" = "${tag:0:n}" -a \ "${class:n+1}" = "${tag:n+1}" ] && ( [ -z "$pos" ] || [ $n = $pos ] ); then variants="${variants:-${class:n:1}}${tag:n:1}" pos=$n break fi done if [ $n -eq ${#class} ]; then print_modaliases "$class" "$variants" "$pos" variants= pos= class=$tag fi done print_modaliases "$class" "$variants" "$pos" }   for module in $(grep -E '/lib/modules/.+\.ko$') $*; do # | head -n1 because some modules have *two* version tags. *cough*b44*cough* modver=$(/sbin/modinfo -F version "$module"| head -n1) modver=${modver// /_}   # only add version tag if it has a version if [ -n "$modver" ]; then /sbin/modinfo -F alias "$module" \ | sed -nre "s,(.+),modalias(\\1) = $modver,p" else /sbin/modinfo -F alias "$module" \ | sed -nre "s,(.+),modalias(\\1),p" fi done \ | sort -u \ | combine_modaliases

We need to plug in our new provider by adding an attribute file in the /usr/lib/rpm/fileattrs directory. To follow suit, we'll call it kmod.attr which looks like this:

$ cat /usr/lib/rpm/fileattrs/kmod.attr
%__kmod_provides %{_rpmconfigdir}/kmod.prov
%__kmod_path ^/usr/lib/modules.*\\.ko$

The two lines indicate that any kernel module captured by %__kmod_path is to be passed onto the kmod.prov decorator.

So how does it look? Here's a listing of the provides for a kmod package built with the above changes:

$ rpm -qp --provides ./kmod-wl-3.13.10-200.fc20.x86_64-
kernel-modules-for-kernel = 3.13.10-200.fc20.x86_64
kmod-wl-3.13.10-200.fc20.x86_64 =
kmod-wl-3.13.10-200.fc20.x86_64(x86-64) =
wl-kmod =

Sweet, that looks exactly like what we want. So that takes care of kmods, what about akmods?

akmod Packages

Unfortunately the above method won't satisfy our initial requirement for akmods to also provide modalias information. The main reason is that akmod packages don't contain any pre-built kernel modules, they contain the source RPM from which a suitable kmod package can be built from.

Damn! Ideally, doing a "provides" search via dnf or yum should return both kmod and akmod packages.

We mentioned that an akmod package actually contains the source code and thus no directly suitable files (such as *.ko files) that can be interrogated by the fileattrs. Fortunately, akmod packages are produced by the same spec that is used to create the kmod packages and thus we have the ability to leverage some information to generate a dedicated file with sufficient information that can be interrogated for decoration at a later stage.

So looking at the typical structure of an akmod package it contains normally two files, the source RPM and a symlink to the latest source RPM (normally itself). Our proposal involves the addition of another file using similar unique naming to the source RPM (e.g. kmod-$name-$version-$release.modalias) that contains the associated modaliases that will be present when the kmod is built.

With the file in place, we can then perform a similar process to what we used for the kmod packages and ensure the decorator can process our new modalias file.

So in order to build this file, we need to unravel the complexities of how akmods are produced. I won't go into the nitty gritty but suffice to say there's a reasonable amount of magic provided by the kmodtool which does some dynamic macro creation for the kmod spec files. The final stages of these spec files, throws a call to %{?akmod_install}. It's this macro that we need to extend to create our modalias file. The following small diff is all that is needed to generate the .modalias file which we can then have picked up by an appropriate decorator.

$ diff -Nurd /usr/bin/kmodtool /tmp/kmodtool
--- /usr/bin/kmodtool 2013-12-08 04:17:24.000000000 +1100
+++ /tmp/kmodtool 2014-04-22 16:35:50.564309505 +1000
@@ -66,7 +66,14 @@
rpmbuild --define "_sourcedir %{_sourcedir}" \\\
--define "_srcrpmdir \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/" \\\
-bs --nodeps %{_specdir}/%{name}.spec ; \\\
-ln -s \$(ls \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/) \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod.latest
+ln -s \$(ls \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/) \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod.latest ; \\\
+for kernel_version in %%{?kernel_versions}; do pushd _kmod_build_\${kernel_version%%___*} ; \\\
+for module in *.ko; do \\\
+ modver=\$(modinfo -F version "\$module"| head -n1) \\\
+ modver=\${modver// /_} \\\
+ [ -n "\$modver" ] && modinfo -F alias "\$module" | sed -nre "s,(.+),modalias(\\\\1) = \$modver,p" || modinfo -F alias "\$module" | sed -nre "s,(.+),modalias(\\\\1),p" ; \\\
+done >> \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod-%{version}-%{release}.modalias ; \\\
+popd ; done
%package -n akmod-${kmodname}
Summary: Akmod package for ${kmodname} kernel module(s)

With our modalias file now being created, we need to build an appropriate decorator. The astute will notice that a portion of our original decorator has made it's way into the macro diff above. This in turn allows us to simplify the final decorator which in this case we call modalias.prov and place it in the /usr/lib/rpm directory.

$ cat /usr/lib/rpm/modalias.prov
#! /bin/sh
# heavily based upon find-suggests.ksyms by Andreas Gruenbacher .
# with modifications by Michael Brown
# -- modalias file already contains modalias information and just needs to
# be sorted and combined
print_modaliases() {
declare class=$1 variants=$2 pos=$3
if [ -n "$variants" ]; then
echo "${class:0:pos}[$variants]${class:pos+1}"
[ -z "$class" ] || echo "$class"
combine_modaliases() {
declare tag class variants pos n
read class
while read tag; do
for ((n=0; n<${#class}; n++)); do if [ "*" != "${class:n:1}" -a \ "${class:0:n}" = "${tag:0:n}" -a \ "${class:n+1}" = "${tag:n+1}" ] && ( [ -z "$pos" ] || [ $n = $pos ] ); then variants="${variants:-${class:n:1}}${tag:n:1}" pos=$n break fi done if [ $n -eq ${#class} ]; then print_modaliases "$class" "$variants" "$pos" variants= pos= class=$tag fi done print_modaliases "$class" "$variants" "$pos" }   while read FILE; do cat $FILE done | sort -u | combine_modaliases

We hook up the modalias decorator by adding a modalias.attr attribute file in the /usr/lib/rpm/fileattrs directory, which looks like the following:

$ cat /usr/lib/rpm/fileattrs/modalias.attr
%__modalias_provides %{_rpmconfigdir}/modalias.prov
%__modalias_path ^/usr/src/akmods/.*\\.modalias$

And the final result yields:

$ rpm -qp --provides ./akmod-wl-
akmod-wl =
akmod-wl(x86-64) =
wl-kmod =


OK, so what now? Well this is just the results of us investigating if it was possible and how it could be done. The above mechanism would require a diff to the kmodtool and rpm-build packages to provide the auto-decorating of modalias information on kmod and akmod packages.

Knowing that this can work, we think it might be a good time to revisit the possibilities with the RPMFusion team and see if we can make this a reality that all users of RPMFusion packages can benefit from.

Stay tuned!

Disable animations in GNOME 3 for older hardware

If you love GNOME 3 but the animations are really sluggish on an older machine (driving you crazy) then you can disable them using dconf-editor (install that first).

In dconf-editor, browse to org.gnome.desktop.interface and set enable-animations=false. Hope that stops someone from un-installing GNOME on an older machine…

Fix problem updating packages in Fedora/Korora due to broken SELinux update

Unfortunately an update to the SELinux policy package in Fedora 20 (and therefore Korora 20) caused RPM scriptlets to fail when updating packages.

This bug only affects systems that have SELinux mode set to enforcing (which is the default) and were updated to version 3.12.1-116 of the selinux-policy package. If you have seen the following sort of error when updating packages, then this bug may affect you:

warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64

Below are the commands to resolve this issue (which has been fixed in an updated 3.12.1-117 version of selinux-policy).

sudo setenforce 0
sudo yum clean expire-cache
sudo yum update selinux-policy\*
sudo setenforce 1

The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum cache and install the SELinux policy update which fixes this issue. The last command re-enables SELinux enforcement.

If you previously installed any packages which failed with scriptlet errors like above, you can reinstall them using the following command:

sudo yum reinstall

You can find out what packages were installed after the broken update using a command like this:

sudo sed '1,/selinux-policy-3.12.1-116/d' /var/log/yum.log

If you require any assistance please don’t hesitate to ask for help using Engage or jump onto the #korora channel in IRC servers.

Add permanent rules to FirewallD

Someone at work wanted to know how to add rules permanently to FirewallD, Fedora’s dynamic firewall (iptables), so I’m posting it in case it’s useful to someone else.

Get the default zone, this is usually “public”:
firewall-cmd --get-active-zones

List services on that zone:
firewall-cmd --zone=public --list-all

Add required TCP ports (let’s do port 80):
firewall-cmd --permanent --zone=public --add-port=80/tcp

If you need a UDP port:
firewall-cmd --permanent --zone=public --add-port=123/udp

You could restart the firewall for them to take affect, or set the rules again without the –permanent option to add them dynamically.

Restart firewall:
systemctl restart firewalld.service

You can also specify services, rather than ports if you like.

sudo firewall-cmd --permanent --zone=public --add-service=http

You’re done!