Just another Linux geek

Manage and tweak Fedora with Ansible (and apply Korora settings by default)

Published on 26 December, 2018 in Fedora, FOSS, Korora and Tech. 2 Comments

Korora Project is a Linux distro I created over 13 years ago, which (since 2010) takes Fedora and applies dozens of tweaks in an effort to make it more usable “out of the box” for every day users.

Even with one or two others helping, it has been a lot of work so I’ve taken a break from the project for the last year to focus on other things. There has been no release of Korora since and so lately I’ve been running stock Fedora 29 Workstation (GNOME) on my laptop.

I enjoy the Korora defaults though and given that my family also runs Korora, I wanted a way to be able to move them to stock Fedora while keeping the same packages as well as the look and feel.

So, I created a Korora Ansible Role (it’s also on Ansible Galaxy) to apply the same Korora tweaks for stock Fedora Workstation (GNOME) plus an example playbook which uses it.

I tried to make it flexible by using variables so that users can change default package lists and settings for each machine, as required.

Running it on your local machine is pretty trivial, there’s a shell script with a sample inventory for localhost.

$ git clone --recursive https://github.com/csmart/korora-ansible ~/korora-ansible $ cd ~/korora-ansible $ ./run.sh

The end result is something like this!

Fedora after running Korora Ansible Role.

Customising it for particular machines is pretty easy thanks to Ansible, especially when using a YAML inventory.

For example, the following inventory for localhost at ~/korora-ansible/inventory/hosts-custom.yml will override defaults and add a few extras.

Remove totem
Install kodi
Change GNOME favourites (links in the dash)
Install nginx webserver, enable it and open the firewall for web traffic
Install Adapta theme and set GTK and GNOME shell themes
Set fonts for the system
You can do more!

cd ~/korora-ansible cat > ./inventory/hosts-custom.yml<<EOF all: hosts: localhost: ansible_connection: local korora_packages_custom: remove: - totem korora_shell_favourites: install: - kodi apps: - firefox.desktop - vlc.desktop - kodi.desktop - shotwell.desktop - org.gnome.Nautilus.desktop - org.gnome.Software.desktop - org.gnome.Terminal.desktop korora_services_custom: install: - nginx enable: - nginx korora_firewall_custom: allow: - http korora_gtk_theme: name: Adapta install: - adapta-gtk-theme korora_shell_theme: name: Adapta korora_desktop_font: name: "Droid Sans Regular 11" install: - google-droid-sans-fonts korora_desktop_document_font: name: "Droid Sans Regular 11" korora_desktop_titlebar_font: name: "Droid Sans Bold 11" korora_terminal_font: name: "Droid Sans Mono Regular 11" install: - google-droid-sans-mono-fonts vars: ansible_python_interpreter: /usr/bin/python3 EOF

You would run the playbook with that custom inventory file by passing it in as the first argument.

$ ./run.sh ./inventory/hosts-custom.yml

Fedora on ODROID-HC1 mini NAS (ARMv7)

Published on 28 April, 2018 in Fedora and FOSS. 11 Comments Tags: arm, fedora, nas.

Hardkernel is a Korean company that makes various embedded ARM based systems, which it calls ODROID.

One of their products is the ODROID-HC1, a mini NAS designed to take a single 2.5″ SATA drive (HC stands for “Home Cloud”) which comes with 2GB RAM and a Gigabit Ethernet port. There is also a 3.5″ model called the HC2. Both of these are based on the ODROID-XU4, which itself is based on the previous iteration ODROID-XU3. All of these are based on the Samsung Exynos5422 SOC and should work with the following steps.

The Exynos SOC needs proprietary first stage bootloaders which are embedded in the first 1.4MB or so at the beginning of the SD card in order to load U-Boot. As these binary blobs are not re-distributable, Fedora cannot support these devices out of the box, however all the other bits are available including the kernel, device tree and U-Boot. So, we just need to piece it all together and the result is a stock Fedora system!

To do this you’ll need the ODROID device, a power supply (5V/4A for HC1, 12V/2A for HC2), one of their UART adapters, an SD card (UHS-I) and probably a hard drive if you want to use it as a NAS (you may also want a battery for the RTC and a case).

ODROID-HC1 with UART, RTC battery, SD card and 2.5″ drive.

Note that the default Fedora 27 ARM image does not support the Realtek RTL8153 Ethernet adapter out of the box (it does after a kernel upgrade) so if you don’t have a USB Ethernet dongle handy we’ll download the kernel packages on our host, save them to the SD card and install them on first boot. The Fedora 28 image works out of the box, so if you’re installing 28 you can skip that step.

Continue reading ‘Fedora on ODROID-HC1 mini NAS (ARMv7)’

Auto apply latest package updates on OpenWrt (LEDE Project)

Published on 18 March, 2018 in FOSS. 8 Comments Tags: lede, openwrt, router, updates.

Running Linux on your router and wifi devices is fantastic, but it’s important to keep them up-to-date. This is how I auto-update my devices with the latest packages from OpenWrt (but not firmware, I still do that manually when there’s a new release).

This is a very simple shell script which uses OpenWrt’s package manager to fetch a list of updates, and then install them, rebooting the machine if that was successful. The log file is served up over http, in case you want to get the log easily to see what’s been happening (assuming you’re running uhttpd service).

Make a directory to hold the script.
root@firewall:~# mkdir -p /usr/local/sbin

Make the script.
root@firewall:~# cat > /usr/local/sbin/update-system.sh << \EOF #!/bin/ash opkg update # upgrade netifd first as it causes drop out and system upgrade fails opkg upgrade netifd # install luci-ssl, so we get web back after upgrades opkg install luci-ssl /etc/init.d/uhttpd restart # do package upgrades PACKAGES="$(opkg list-upgradable |awk '{print $1}')" if [ -n "${PACKAGES}" ]; then opkg upgrade ${PACKAGES} if [ "$?" -eq 0 ]; then echo "$(date -I"seconds") - update success, rebooting" \ >> /www/update.result exec reboot else echo "$(date -I"seconds") - update failed" >> /www/update.result fi else echo "$(date -I"seconds") - nothing to update" >> /www/update.result fi EOF

Make the script executable and touch the log file.
root@firewall:~# chmod u+x /usr/local/sbin/update-system.sh root@firewall:~# touch /www/update.result

Make sure the script and results are kept when upgrading the firmware.
root@firewall:~# echo "/usr/local/sbin/" >> /etc/sysupgrade.conf root@firewall:~# echo "/www/update.result" >> /etc/sysupgrade.conf

Next schedule the script in cron.
root@firewall:~# crontab -e

My cron entry looks like this, to run at 2am every day.

0 2 * * * /usr/local/sbin/update-system.sh

Now just start and enable cron.
root@firewall:~# /etc/init.d/cron start root@firewall:~# /etc/init.d/cron enable

Give it a run manually, if you want.
root@firewall:~# /usr/local/sbin/update-system.sh

Download a copy of the log from another machine (once the router has finished rebooting).
chris@box:~$ curl http://router/update.result 2018-03-18T10:14:49+1100 - nothing to update

That’s it! Now if you have multiple devices you can do the same, but maybe just set the cron entry for a different time of the night.

Patches for OpenStack Ironic Python Agent to create Buildroot images with Make

Published on 18 April, 2017 in FOSS and OpenStack. 3 Comments Tags: ironic, openstack.

Recently I wrote about creating an OpenStack Ironic deploy image with Buildroot. Doing this manually is good because it helps to understand how it’s pieced together, however it is slightly more involved.

The Ironic Python Agent (IPA) repo has some imagebuild scripts which make building the CoreOS and TinyCore images pretty trivial. I now have some patches which add support for creating the Buildroot images, too.

The patches consist of a few scripts which wrap the manual build method and a Makefile to tie it all together. Only the install-deps.sh script requires root privileges, if it detects missing dependencies, all other Buildroot tasks are run as a non-privileged user. It’s one of the great things about the Buildroot method!

Continue reading ‘Patches for OpenStack Ironic Python Agent to create Buildroot images with Make’

Creating an OpenStack Ironic deploy image with Buildroot

Published on 16 April, 2017 in Fedora, FOSS and OpenStack. 0 Comments Tags: buildroot, ironic, openstack.

Edit: See this post on how to automate the builds using buildimage scripts.

Ironic is an OpenStack project which provisions bare metal machines (as opposed to virtual).

A tool called Ironic Python Agent (IPA) is used to control and provision these physical nodes, performing tasks such as wiping the machine and writing an image to disk. This is done by booting a custom Linux kernel and initramfs image which runs IPA and connects back to the Ironic Conductor.

The Ironic project supports a couple of different image builders, including CoreOS, TinyCore and others via Disk Image Builder.

These have their limitations, however, for example they require root privileges to be built and, with the exception of TinyCore, are all hundreds of megabytes in size. One of the downsides of TinyCore is limited hardware support and although it’s not used in production, it is used in the OpenStack gating tests (where it’s booted in virtual machines with ~300MB RAM).

Continue reading ‘Creating an OpenStack Ironic deploy image with Buildroot’

Manage Intel Turbo Boost with systemd

Published on 8 February, 2017 in Fedora and FOSS. 14 Comments

If you have a little laptop with an Intel CPU that supports turbo boost, you might find that it’s getting a little hot when you’re using it on your lap.

For example, taking a look at my CPU:
lscpu |egrep "Model name|MHz"

We can see that it’s a 2.7GHz CPU with turbo boost taking it up to 3.5GHz.

Model name: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
CPU MHz: 524.633
CPU max MHz: 3500.0000
CPU min MHz: 400.0000

Here’s a way that you can enable and disable turbo boost with a systemd service, which lets you hook it into other services or disable it on boot.

By default, turbo boost is on, so starting our service will disable it.

Create the service.
cat << EOF | sudo tee \ /etc/systemd/system/disable-turbo-boost.service [Unit] Description=Disable Turbo Boost on Intel CPU [Service] ExecStart=/bin/sh -c "/usr/bin/echo 1 > \ /sys/devices/system/cpu/intel_pstate/no_turbo" ExecStop=/bin/sh -c "/usr/bin/echo 0 > \ /sys/devices/system/cpu/intel_pstate/no_turbo" RemainAfterExit=yes [Install] WantedBy=sysinit.target EOF

Reload systemd manager configuration.
sudo systemctl daemon-reload

Test it by running something CPU intensive and watching the current running MHz.

cat /dev/urandom > /dev/null & lscpu |grep "CPU MHz"

CPU MHz: 3499.859

Now disable turbo boost and check the CPU speed again.
sudo systemctl start disable-turbo-boost lscpu |grep "CPU MHz"

CPU MHz: 2699.987

Don’t forget to kill the CPU intensive process 🙂

kill %1

If you want to disable turbo boost on boot by default, just enable the service.

sudo systemctl enable disable-turbo-boost

As turbo boost is enabled on a Linux system by default, to turn it back on you just need to turn off the script which disables it.

sudo systemctl disable disable-turbo-boost

Fixing webcam flicker in Linux with udev

Published on 7 February, 2017 in Fedora, FOSS and OpenStack. 0 Comments Tags: fedora, flicker, Linux, udev, webcam.

I recently got a new Dell XPS 13 (9360) laptop for work and it’s running Fedora pretty much perfectly.

However, when I load up Cheese (or some other webcam program) the video from the webcam flickers. Given that I live in Australia, I had to change the powerline frequency from 60Hz to 50Hz to fix it.

sudo dnf install v4l2-ctl v4l2-ctl --set-ctrl power_line_frequency=1

I wanted this to be permanent each time I turned my machine on, so I created a udev rule to handle that.

cat << EOF | sudo tee /etc/udev/rules.d/50-dell-webcam.rules SUBSYSTEM=="video4linux", \ SUBSYSTEMS=="usb", \ ATTRS{idVendor}=="0c45", \ ATTRS{idProduct}=="670c", \ PROGRAM="/usr/bin/v4l2-ctl --set-ctrl \ power_line_frequency=1 --device /dev/%k", \ SYMLINK+="dell-webcam" EOF

It’s easy to test. Just turn flicker back on, reload the rules and watch the flicker in Cheese automatically disappear 🙂

v4l2-ctl --set-ctrl power_line_frequency=0 sudo udevadm control --reload-rules && sudo udevadm trigger

Of course I also tested with a reboot.

It’s easy to do with any webcam, just take a look on the USB bus for the vendor and product IDs. For example, here’s a Logitech C930e (which is probably the nicest webcam I’ve ever used, and also works perfectly under Fedora).

Bus 001 Device 022: ID 046d:0843 Logitech, Inc. Webcam C930e

So you would replace the following in your udev rule:

ATTRS{idVendor}==“046d”
ATTRS{idProduct}==“0843”
SYMLINK+=“c930e”

Note that SYMLINK is not necessary, it just creates an extra /dev entry, such as /dev/c930e, which is useful if you have multiple webcams.

Git hook to help with OpenStack development

Published on 30 January, 2017 in Fedora and OpenStack. 0 Comments Tags: development, git, openstack.

I wrote a small Git hook which may be useful in helping OpenStack devs run tests (and any script they like) before a commit is made (see Superuser magazine article).

This way we can save everyone time in the review process by fixing simple issues before they break in the check-pipeline.

Installation is easy (see the GitHub page) and all prompts default to no, so that the dev can easily just hit Enter to skip and continue (but still be reminded).

Building and Booting Upstream Linux and U-Boot for Raspberry Pi 2/3 ARM Boards

Published on 27 October, 2016 in Fedora. 35 Comments Tags: ha, home automation, Linux, raspberry pi, rpi, u-boot.

My home automation setup will make use of Arduinos and also embedded Linux devices. I’m currently looking into a few boards to see if any meet my criteria. Previously I looked at the Orange Pi One, now I’m looking at the Raspberry Pi 2 (which is compatible with the 3).

The most important factor for me is that the device must be supported in upstream Linux (preferably stable, but mainline will do) and U-Boot. I do not wish to use any old, crappy, vulnerable vendor trees!

The Raspberry Pi needs little introduction. It’s a small ARM device, created for education, that’s taken the world by storm and is used in lots of projects.

Raspberry Pi 2, powered by USB with 3v UART connected

The Raspberry Pi actually has native support for booting a kernel, you don’t have to use U-Boot. However, one of the neat things about U-Boot is that it can provide netboot capabilities, so that you can boot your device from images across the network (we’re just going to use it to boot a kernel and initramfs, however).

One of the other interesting things about the Raspberry Pi is that there are lots of ways to tweak the device using a config.txt file.

The Raspberry Pi 3 has a 64bit CPU, however it is probably best run in 32bit mode (as a Raspberry Pi 2) as 64bit userland is not particularly advanced in ARM world, yet.

Fedora 25 will finally support Raspberry Pi 2 and 3 (although not all peripherals will be supported right away).

Continue reading ‘Building and Booting Upstream Linux and U-Boot for Raspberry Pi 2/3 ARM Boards’

Building and Booting Upstream Linux and U-Boot for Orange Pi One ARM Board (with Ethernet)

Published on 23 October, 2016 in Fedora. 10 Comments Tags: arm, ha, home automation, Linux, orange pi.

My home automation setup will make use of Arduinos and also embedded Linux devices. I’m currently looking into a few boards to see if any meet my criteria.

The Orange Pi One is a small, cheap ARM board based on the AllWinner H3 (sun8iw7p1) SOC with a quad-Core Cortex-A7 ARM CPU and 512MB RAM. It has no wifi, but does have an onboard 10/100 Ethernet provided by the SOC (Linux patches incoming). It has no NAND flash (not supported upstream yet anyway), but does support SD. There is lots of information available at http://linux-sunxi.org.

Orange Pi One

Note that while Fedora 25 does not yet support this board specifically it does support both the Orange Pi PC (which is effectively a more full-featured version of this device) and the Orange Pi Lite (which is the same but swaps Ethernet for WiFi). Using either of those configurations should at least boot on the Orange Pi One.

Continue reading ‘Building and Booting Upstream Linux and U-Boot for Orange Pi One ARM Board (with Ethernet)’