So with Fedora 22 well and truly out for both ARMv7 and aarch64 lets have a look at the release in general and also at the 4.0 kernel it ships.
It’s all to easy to get bogged down in the actual technical components that make up the actual release and not forget that there’s work that goes on all over the place that contributes to making the release easy to use even before you begin the download.
Anyway! On to ARMv7. We shipped GA with the 4.0.4 kernel and u-boot 2015.01. This combination gives us improved support for numerous devices primarily through new DT support and improvements to drivers. The 4.0 kernel from an ARM HW support PoV really was a minor revision. With the fully packaged and updated fedora-arm-installer it’s even easier to get a device up and running.
We were hoping to get enough time to rebase this to 2015.04 but we just plain ran out of time, although we do have a plan to be able to update the u-boot when writing an image to card/stick without the need to regenerate the images. More details on the improvements we’re planning for fedora-arm-installer for another post!
From an aarch64 point of view the big change, although one an average user won’t notice, was we went from carrying a rather large (around 65K lines) enablement patch for the kernel to a small collection of 4 bug/problem specific patches! This is a massive change where in the F-21 cycle we had a gigantic architecture enablement patch! This makes it much more straight forward and less stressful for both myself as the architecture maintainer and the core Fedora kernel developers. In terms of the rest of aarch64 we still support VExpress, APM Storm platform primarily with the Mustang boards, and the AMD Seattle platform.
Overall the Fedora 22 release on the ARM platforms is a really nice release, there’s been some good changes there to enable easier and quicker updates in the future and easier means of adding decent support to new devices mid cycle. AArch64 is maturing and hopefully we’ll start to see some more platforms land and the architecture start to depart the niche status!
In the past I’ve traveled for work, conferences and personal a lot. The first category has declined a little from the “travel all the time” I’ve done in the past since I’ve joined the release engineering team. When travelling regularly I have a collection of things I pack that make life easier and a little more pleasant.
On of these is a travel router, often hotels have wired but no wireless, or flaky wireless or you need to pay for more than one device (or even one device). I don’t have a high spec need but it must have the following:
- Dual ethernet WAN/LAN (everyone knows I have lots of ARM devices!)
- Wireless, doesn’t need to be massivly fast (hotel internet is the bottle neck!) but it does need to be stable
- Standard power cables, either figure 8 plug with inbuilt switching PSU or micro USB
- Open source and hackable. Probably supportable with OpenWRT
- Quick and easy to reconfigure
For a number of years the device I used was an Apple Airport Express as it was one of the few that met most of the above criteria. But then I stopped using a iPod touch which meant the last option was dead due to the lack of openness.
Time for a new one! I’ve been looking for a while, I almost went for the popular TP-Link WR703N router as it’s well supported in OpenWRT but it meant that I lost the extra wired network port.
Then I came across the NEXX WT3020. It comes in four official options all of which have 802.11n, dual 100Mb ethernet, and runs from a micro USB connector! All but the bottom end model have a USB port for 3G or storage. The top two models just seem to have SW options but no other HW. Perfect, it even has OpenWRT support! So I went with the WT3020H, all for around $20.
I ordered one, while I was awaiting for it to arrive the OpenWRT project released Chaos Calmer 15.05-rc1 which has a prebuilt image and literally in less than five minutes I’d reflashed it to OpenWRT via the standard web flash interface! I’ve not had time to test performance, throughput and features such as USB but it seems to work pretty well for a $20 router and all the core features I need are working and it’s in a form factor that is TINY and I don’t even need to take an extra power supply. I’d call that a WIN!
I’ve been a bit lazy on the ARM kernel status updates. There wasn’t one at all for 3.18 but the fact was, that while there was lots of under the hood improvements for ARM/aarch64, the new device support or improvements from a user’s point of view was positively boring so I never bothered!
That said the 3.19 kernel is now on it’s way to the stable Fedora releases and there’s some bit of interest there
Beginning with aarch64 there’s been a raft of code support landing upstream for the core platforms we support (VExpress, APM Storm, and AMD Seattle) which means the enablement patch set has shrunk massively. The core missing bit from this is primarily the ACPI patches for the server standards. There’s also been a lot of stability improvements for various device drivers particularly on the APM Storm SoC (which massively helps the high network and IO traffic we generate when doing composes in release engineering!). Other improvements include support for seccomp. The upstream support for aarch64 is really starting to settle down nicely which is good because there’s devices finally starting to get to the point where they’ll be more widely available and affordable
On to ARMv7 changes. In terms of new supported SoCs the support for AllWinner A-23 (aka sun8i) is the most interesting in terms of new devices. There was also a lot of general SoC improvements and cleanups. The largest here is probably Rockchips, QCom and ZYNQ with notable mentions to Tegra, OMAP and i.MX6 too. In terms of new devices we now solely support DeviceTree devices and the built .dtb files we ship that are possible to support with the kernel jumped from 250 to 265 devices. Of course it doesn’t mean we’re testing all of those devices but we’re testing devices across all main SoC groups to ensure at least the core support works. Of course feedback for what works and doesn’t is always welcome. In this cycle there was also significant driver work with special mention to Hans and his significant movement on the Allwinner devices.
I’ll do a longer post for 4.0 and the new u-boot we’ll be supporting in Fedora 22 soon.
I always forget the exact commands to change the port ssh (or any default service in the case of the selinux bits) runs on. It’s nicely simple though!
Edit /etc/ssh/sshd_config to change the port number:
You can add a second line if you wish to initially leave it running on Port 22 too in case something goes wrong, obviously don’t forget to remove it once the new port is working!
To add port 2022 to port contexts, enter:
# semanage port -a -t ssh_port_t -p tcp 2022
You can verify new settings, enter:
# semanage port -l | grep ssh
ssh_port_t tcp 2022,22
Reload the sshd service to pick up the new config:
#systemctl reload sshd.service
And of course don’t forget to update your firewall to allow the new port through.
So around three months ago (yes, I must do a post on that too) I changed roles at Red Hat and moved from constantly travelling and being on customer sites to working from home. As a result I needed to setup a workspace that I could use day to day.
One thing I’ve always wanted to try is a standing desk. I have back problems, and generally not the best posture, so I thought that would be one way to be able to deal with at least the later, and potentially even the former. The main problem, until recently, is that decent standing desks tend to be very expensive and I didn’t want to needlessly go and spent a lot of extra money for something that would be used for a week and never again. So I decided I would start with a cheap height adjustable desk, which I needed to get anyway due to my height, and then use it as a the basis of a standing desk and then hack it from there. The initial combo I decided on after a lot of looking was the IKEA Galant Height Adjustable Desk at £49 and the IKEA Lack Side table at £8 plus delivery. I figured at less than £100 including delivery if it was terrible I wasn’t wasting a lot of money!
As it turns out it’s been much better than I ever expected it to be. I initially setup the desk to the height I would want when sitting. At a height of six foot three inches I’m not the shortest of people so when sitting I prefer a higher than average desk. Sitting the Lack table on top of the desk by chance also ended up also giving me the perfect standing height. Bonus! A few quid for some foam gym mats plus a decent height adjustable monitor (the most expensive bit by far!) and I was done! Well mostly, I still haven’t decided on a decent keyboard yet.
So how does it look? Well a little bit weird to be honest. How does it work? Better than I ever expected as I find I can happily stand at the desk for a full eight hour working day without too much issue and I’ve even done longer (hello Fedora beta release candidates!!) and my back feels better than it has in a long time! I was also trying to decide on a decent but reasonably priced office chair to buy but now I’m not going to bother. Interestingly IKEA has also just launched the BEKANT sit/stand desk which is reasonably priced and has electric motors for raise/lower. It’s likely I’ll end up getting one of these one day but for the moment my IKEA hack is working pretty well.
The default network config for libvirt is simple and works for most basic use cases but there’s a number of use cases where you need more complex config like Adam outlined for a local bridged config.
I run a number of VMs on a hosted server on the internet and I’ve had on my ToDo list for some time to add a IPSEC site to site VPN but the default network doesn’t make that easy because libvirtd deals with the iptables networking including the NAT automagically.
The network config looks like this:
*-----* 192.168.100.0/24 --| Hyp |-(eth0)- internet (br0) VM net *-----*
Create non routed network bridge
Initially create a basic network bridge and disable STP (spanning tree protocol). Note we don’t bind it with eth0 which is a public internet facing interface.
nmcli con add type bridge ifname br0 nmcli con modify bridge-br0 bridge.stp no
I then edited the /etc/sysconfig/network-scripts/ifcfg-bridge-br0 file and to add IP network config and adjust a few bits to get the following:
DEVICE=br0 STP=no TYPE=Bridge BOOTPROTO=static DEFROUTE=yes IPV4_FAILURE_FATAL=no IPADDR=192.168.100.254 NETMASK=255.255.255.0 IPV6INIT=no IPV6_FAILURE_FATAL=no NAME=bridge-br0 UUID=
Once we’ve done that we can bring the bridge online and check the config looks OK:
ifup br0 nmcli c show nmcli -f bridge con show bridge-br0 ip addr
Now we have a network bridge with an IP address you can now edit any VM configuration and reassign the virtual NICs to the new bridge and adjust the VM network config to the new subnet and assign static IPs to each VM, or configure dhcpd to assign IPs on the br0 interface. Once that’s done you should be able to ping the gateway (192.168.101.254) and have local network connectivity.
Once you’ve moved everything over you can delete the original libvirtd network config.
Outbound NATed networking
Using the traditional iptables.service (firewalld investigation is on my todo list) you can add a basic outbound NAT configuration which restores the last of the missing functionality with the following basic rule set which will NAT by masquerading the br0 network out through the public IP on eth0:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p icmp -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited iptables -A FORWARD -i eth0 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i br0 -o eth0 -j ACCEPT iptables -A FORWARD -j REJECT --reject-with icmp-host-prohibited iptables-save > /etc/sysconfig/iptables systemctl enable iptables.service systemctl start iptables.service
With the network now under complete control of NetworkManager and a IP firewall/NAT configuration under control from a single point it now makes it easier to add things like IPSEC connections and IPv6 configuration both of which are next on the list.
It always annoyed me I couldn’t use my ssh key in a screen session. Every now and again I would try and work it out with google and some trial and error. Eventually with the help of a couple of good bits off the net I worked out what I thought to be the easiest way to achieve it consistently.
Firstly the ssh config bits:
Add the following to your ~/.ssh/config file, creating it if you don’t already have one:
host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:p
And create the ~/.ssh/rc file:
#!/bin/bash if test "$SSH_AUTH_SOCK" ; then ln -sfv $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock fi
And make sure they have the correct permissions for ssh:
chmod 600 ~/.ssh/config ~/.ssh/rc
Finally add the following to your ~/.screenrc file:
setenv SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock
I’m not sure it’s the best and most effective way but it’s nice and simple and to date it’s been working well for me, I’ve not had issues with it. Any suggestions for improvement feel free to comment.
Disabling SSLv3 in Dovecot is nice and straight forward.
In the /etc/dovecot/conf.d/10-ssl.conf file edit the ssl_cipher_list line to look as below (or adjust to suit your specific requirements):
ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:+MEDIUM
To test the option to ensure it’ll work you can run the following command before you restart dovecot and the output should look something like below:
$ openssl ciphers -v 'ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:+MEDIUM' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
Finally to test it from client side you can run the following command to ensure it’s not enabled. If it’s configured as expected the negotiation should fail and it’ll return you straight to the command prompt:
openssl s_client -connect mail.example.com:993 -ssl3
A question that I’ve had a few times in the last couple of weeks is whether Fedora supports Cute Embedded Nonsense Hacks, also known as u-boot and device tree, on aarch64 (ARM64) platforms?
The answer is YES!, of course, why wouldn’t we?
I know people are well aware of Red Hat’s involvement in the Server Base System Architecture (SBSA) which mandates the use of UEFI 2.4 and ACPI 5.1 bindings and that the Red Hat Partner Early Access Program uses that standard to enable easy booting and support of server platforms running on aarch64 platforms but the fact is that is not Fedora.
Fedora plans to support the SBSA to enable easy use of Fedora on aarch64 server platforms. But we also plan to support the current standard u-boot with device tree boot options. The fact of the matter is that a lot of non server based aarch64 platforms will continue to use these options and so we’ll continue to actively support them. Just like Fedora support Xen when the Fedora derived enterprise product does not. Basically it’s not hard for us to continue these options and with the improved generic distro support in u-boot, which we’ve actively participated in and driven, testing of Cute Embedded Nonsense Hacks on aarch64 should be easy and straight forward.
Of course the support of both SBSA based uEFI/ACPI or u-boot/DTB isn’t perfect on aarch64 yet so if you’ve got access to aarch64 systems on either platforms I would love testing and bug reports. If you’re a vendor that plans on using u-boot/DTB on aarch64 I would ask to ensure that you support the generic distro options because it’ll enable out of the box booting of at least Fedora, Debian and openSUSE to seamlessly just work on your devices.
With 3.17 due momentarily and Fedora 21 been delayed a little we’ll now be bumping the kernel that ships in F-21 GA. So lets have an overview of what improvements and changes are going to be there for ARM.
Overall 3.17 has been relatively boring in terms of shiny new hardware support for ARMv7. We’ve added support for a bunch of new devices through the addition of appropriate device tree bits. Some of the highlights there include a number of AllWinner devices such as the Banana Pi, a number of new FreeScale i.MX6 devices, some of RockChips devices, and the ZYNQ Parallella.
On the aarch64 side there’s been general improvements all over the place. Over all we don’t have any new platforms but there’s improvements to the three we do support (VExprees, APM X-Gene, AMD Seattle) but the VExpress Juno device should work and initial support for the ACPI 5.1 standard and improved uEFI both of which are part of ARM SBSA Server standard.
Along side 3.17, or at least very shortly there after, u-boot 2014.10 or at least a release candidate should land in F-21 as well. This release adds support for a lot of new devices, primarily AllWinner A-10/13/20 categories, as well as the Tegra Jetson K1, a few i.MX6 devices such as the RIoT Board and the newly upstream distro standards for booting. This makes it much easier for us to “just boot” Fedora ARM with a lot more devices making the experience of getting started a lot easier for most people with supported devices.
The combination of u-boot 2014.10 and the 3.17 kernel will be what we head towards Fedora 21 GA with and things are starting to come together nicely.