Archive for the 'FOSS' Category

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.

Physical devices

My router has a bunch of physical interfaces:

  • eth0 (switch)
  • eth1 (ethernet)
  • wlan0 (wireless card)
  • wlan1 (5GHz wireless card)

The eth1 device maps to the physical WAN port on the back of the router. It’s important to note that the physical interfaces may differ from router to router, depending on the chipsets.

The Switch

The switch (eth0) includes a number of ports, including the four physical ones on the back of the router, a fifth one that’s not used, as well as one that connects to the CPU.

The switch supports VLANs (virtual LANs), and by default OpenWRT puts all of those ports into VLAN 1. This means that physical connections in those four ports at the back are on the same virtual switch and are able to communicate with each other. You can imagine that if I changed the VLAN of one of those ports to VLAN 10, that the device plugged into that port would no-longer be able to communicate with other devices on the switch. This is the basis for our DMZ.

That VLAN 1 actually creates a new interface on the router:

  • eth0.1 (VLAN 1)

The configuration of the switch (including the mapping of ports to VLANs) is available under the switch menu, Network -> Switch.

Note: The port numbers on the switch in OpenWRT do not necessarily map in the right direction to the back of the router. In my case, port 0 on the switch is port 4 on the back of the router.

Creating a new VLAN

The first thing we want to do is create VLAN 10 and then assign one of the ports to that VLAN, removing it from VLAN 1.

  • Browse to Network -> Switch
  • Click Add to make a new VLAN entry
  • Set this new entry’s VLAN ID to 10
  • In the VLAN 1 row, change Port 0 to off
  • In the VLAN 10 row, change Port 0 to untagged
  • In the VLAN 10 row, change CPU port to tagged
Create VLAN

Create VLAN

Setting VLAN to untagged tells the switch to add the appropriate VLAN tag to each ethernet frame as the traffic exits that port. The setting tagged means that the switch should expect that traffic leaving the port has already been tagged, perhaps by the operating system running on the device which is attached to the port.

Port 0 (port 4 on the back of the router) is now in VLAN 10, while the remaining three ports are in VLAN 1 and so it is now isolated from the others. The CPU is also in VLAN 10, else we would not be able to pass any traffic to port 0.

That new VLAN 10 creates a new interface on the router:

  • eth0.10 (VLAN 10)

Interfaces

In OpenWRT you create virtual network interfaces which map to physical devices on the router. These are available under the Network -> Interfaces menu.

For example, my router has:

  • LAN (for my internal local area network)
  • WAN (for the external Internet connection)

One or more physical devices are attached to these zones, for example in my case:

  • LAN (bridges VLAN 1 eth0.1, wlan1 and wlan0 together)
  • WAN (eth1)

The LAN bridge creates a new interface on the router:

  • br-lan (bridged LAN)

Creating a new interface

Once we have created our new VLAN, we want to create a new a interface for the DMZ. In the same way that the VLAN 1 device, eth0.1, is attached to the LAN interface, we will attach VLAN 10 device, eth0.10, to our new DMZ interface.

  • Browse to Network -> Interfaces
  • Click Add New Interface to make a new DMZ zone
  • Set the name of the new interface to DMZ
  • Leave the protocol of the new interface to static
  • Ensure bridge over multiple interfaces remains unchecked
  • For the interface, select only VLAN Interface: “eth0.10″
  • Click Submit
Create Interface

Create Interface

You should be presented with a new configuration screen for this interface.

  • Set IPv4 address to something in a new range different to LAN, e.g. if your LAN is 192.168.1.1 then set DMZ to 192.168.0.1
  • Leave the rest of the settings blank, you do not need to set routes, or IPv6 if you don’t want to
Interface Configuration

Interface Configuration

  • Click on the Advanced Settings tab
  • Ensure Bring up on boot is ticked
  • If you don’t want IPv6, untick Use builtin IPv6-management
Interface Configuration - Advanced

Interface Configuration – Advanced

  • Click on the Physical Settings tab, should already be set to eth0.10
Interface Configuration - Physical

Interface Configuration – Physical

  • Click on the Firewall Settings tab
  • Under Create / Assign firewall-zone select unspecified -or- create and type dmz
  • Click Save and Apply
Interface Config - Firewall

Interface Config – Firewall

  • If you want to run DHCP on your DMZ, then under DHCP Server click Setup DHCP Server button, leave default settings
Interface Config - DHCP

Interface Config – DHCP

We now have a new interface or zone called for the DMZ that’s set to use out DMZ VLAN. It has a new firewall policy assigned to it, dmz, which we now need to configure.

Firewall

Now we need to configure the firewall to do a few things:

  • Allow the DMZ to talk to the WAN zone, so that devices can access the Internet
  • Allow the LAN zone to talk to the DMZ, but not the other way around
  • Add some traffic rules opening ports 53 and 67, so that devices from the DMZ can access DNS and DHCP services on the router’s DMZ IP address
  • Finally, forward the HTTP port (80) from external internet WAN interface onto a device in the DMZ

Let’s do zone settings first.

  • Browse to Network -> Firewall
  • Under the Zones section on General Settings page, edit the dmz zone
  • Leave the name set to dmz
  • Set input to reject, so that we drop all incoming packets by default
  • Leave output as accept, although you could set this to reject by default but you’ll require specific outgoing rules as required (like for Yum updates)
  • Leave Masquerading and MSS clamping disabled
  • Under Covered networks ensure that only dmz is selected
Firewall

Firewall

  • Under the section Inter-Zone Forwarding, ensure Allow forward to destination zones is set only to WAN
  • ensure Allow forward from source zones is set only to LAN
Zone Forwarding

Zone Forwarding

  • Click Advanced Settings tab
  • If you don’t want IPv6, you can set Restrict to address family to IPv4 only
  • Tick Enable logging on this zone, so that we can see what’s happening
Firewall Configuration - Advanced

Firewall Configuration – Advanced

Now let’s do port forwards.

  • Click on the Port Forwards tab
  • Under New port forward section, give a name, such as dmz-http
  • Set Protocol to TCP
  • Set External zone to WAN
  • Set External port to 80
  • Set Internal zone to DMZ
  • Set Internal IP address to your DMZ server, e.g. 192.168.0.100
  • Set Internal port to 80
  • Click Add when you’re happy
  • Repeat for HTTPS port 443 if you want to run a secure server
Port Forwarding

Port Forwarding

Finally, let’s finish with traffic rules.

  • Click on the Traffic Rules tab
  • Under Open ports on router, set a name like dhcp-dns
  • Under Protocol, select UDP
  • Under Port, set 53
  • Click Add
  • Find your new rule in the list and click edit
  • Set Destination address to your router’s DMZ IP address
  • Repeat for DHCP port 67 UDP if you want to use router’s DHCP server, but don’t set the destination address as DHCP is broadcast
Firewall Traffic - DHCP & DNS

Firewall Traffic – DHCP & DNS

If you want to be able to ping the router from the DMZ clients, do this.

  • Set a name like ping-dmz
  • Set protocol to Other
  • Click Add
  • In the new configuration page, set Protocol to ICMP
  • Set Match ICMP type to echo reply
  • Set Source zone to dmz
  • Leave Destination zone to Device (input)
  • Set Destination address to your router’s DMZ IP address
  • Click Save
Firewall Traffic - Ping

Firewall Traffic – Ping

Checking the logs

Remember we told the router to log the DMZ? Well now we can monitor the firewall rules by browsing to Status -> Kernel Log. Here you should be able to see any rejects that are happening, which is useful to work out why something isn’t happening as you expect on the DMZ.

For example, disable the dmz-ping rule and then try to ping the router from your DMZ server. Refresh the Kernel Log and you should see entries appear.

Testing

Plug in a device, see if it gets an IP address. Try to ping 8.8.8.8 (Google DNS server), then try to ping google.com.

Set up a web server on your DMZ box, or use netcat to listen on port 80. Get your external IP address from the router, or Google “my ip”. Now get a friend to browse to your IP and see if you see your web server.

Nice.

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 systemd.unit=emergency.target 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 (192.168.0.100) 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 192.168.0.100
[root@ipa-server ~]# ipa dnsrecord-add 0.168.192.in-addr.arpa. 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.
 
IFS=$'\n'
 
#
# 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 ;;
esac
 
if ! [ -z "$is_kernel_package" ]; then
cat > /dev/null
exit 0
fi
 
print_modaliases() {
declare class=$1 variants=$2 pos=$3
if [ -n "$variants" ]; then
echo "${class:0:pos}[$variants]${class:pos+1}"
else
[ -z "$class" ] || echo "$class"
fi
}
 
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-6.30.223.142-5.fc20.x86_64.rpm
kernel-modules-for-kernel = 3.13.10-200.fc20.x86_64
kmod-wl-3.13.10-200.fc20.x86_64 = 6.30.223.142-5.fc20
kmod-wl-3.13.10-200.fc20.x86_64(x86-64) = 6.30.223.142-5.fc20
modalias(pci:v*d*sv*sd*bc02sc80i*)
wl-kmod = 6.30.223.142-5.fc20

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}"
else
[ -z "$class" ] || echo "$class"
fi
}
 
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-6.30.223.142-5.fc20.x86_64.rpm
akmod-wl = 6.30.223.142-5.fc20
akmod-wl(x86-64) = 6.30.223.142-5.fc20
modalias(pci:v*d*sv*sd*bc02sc80i*)
wl-kmod = 6.30.223.142-5.fc20

Beautiful!

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…

Find out what is using your swap, by Erik Ljungstrom

Ever wondered what it is that’s using that swap on your machine? Erik has a great post about it and a script that will help answer that question.

Here is his script:
#!/bin/bash
# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d | egrep "^/proc/[0-9]"` ; do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"
let OVERALL=$OVERALL+$SUM
SUM=0
 
done
echo "Overall swap used: $OVERALL"

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 freenode.net 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!