When building a Docker container image, in most cases, the machine where you build it on runs on the same CPU architecture as where you eventually want to use it. Today, more and more, there is a need for deploying containers on a different architecture as where it was built on. The most common scenario would be to build on your regular x86 desktop and to deploy to an ARM variant.Continue reading
When using the latest version of Debian 9 stable, even with all updates installed, by default, you can’t get a very recent kernel via the standard repositories in your package manager. While the idea of using Debian stable is to remain stable and rather conservative, there are several benefits with installing a newer kernel and in some cases it’s the only option to get the OS to support all your hardware. The risk and impact on stability is small and the process is rather simple.
The goal of cross compiling is to compile for one architecture on machine running another one. In this post, I’ll try to explain the steps required to be able to compile software that is executable on ARM-based hardware using a “normal” x64-based PC or virtual machine. ARM-based devices are usually limited in processing power and are mostly running stripped-down, embedded versions of Linux. This makes it sometimes difficult to compile on the target device directly.
SELinux is often seen as an evil, complex, unnecessary and especially annoying security component which exists in a lot of Linux distributions. Often you can hear something like: “Disable SELinux and try again” or , “The first thing I do on a new server is to disable SELinux”. The problem with SELinux is that it looks very complex and that it looks like you need to spend ages to understand it. In this post, I’ll try to explain a few basic SELinux principles and especially focus on daily, practical problems related to SELinux and their solutions. Don’t forget that there’s a very good reason for SELinux and it would be a shame to not use it.
When regularly installing Linux hosts or VM’s, it easily becomes annoying to constantly burn CD’s/DVD’s or mount ISO’s for all the Linux distributions that you want to deploy. Especially if you want to keep them current or customize them you’ll end up with a whole lot of discs. Booting your installations from the network, using a PXE boot server, makes life a lot easier and isn’t very hard to setup. In this post I’ll explain how to setup such a PXE boot server that is able to provide multiple Linux distribution installations for deployment over the network.
When configuring a Linux host running either Red Hat Linux 6, Red Hat Linux 7, CentOS 6 or CentOS7 with two network interface cards (NIC) that each have an IP address in a different network or subnet, you could end up in a situation where one of the IP addresses isn’t reachable outside it’s own network. Both IP’s will be responding to a ping from another host in the same network as those IP addresses but only one is responding to ping from another network. On most other distributions, like Debian, this issue, which is caused by asymmetric routing, doesn’t seem to exist.
Syslog is the target where you want all log message to go on all systems that you manage. Almost all Linux distributions use a syslog implementation to gather messages. Recently, rsyslog became the most used syslog-implementation for Linux. Messages can be saved locally or sent to a remote syslog server. When creating your own applications or tools or when you want to log messages coming from processes that don’t support writing to syslog directly, you can use Logger.
Besides using NAT for accessing the internet with multiple machines using a single IP address, there are many other uses of NAT. One of them is to forward all traffic that is sent to a certain TCP port to another host. In practice, this technique can be used to test a service on a new host without adjusting anything on the client. The users or the clients do not need to be pointed to a new machine in order to test it. When the test would be unsuccessful, removing the NAT-rule is all it takes to switch back.
When you’re running low on space on a file system, that can cause various unexpected behavior of the system, depending on which file system is filling up. For me, when that happens, I usually first issue a disk free (df) to see which is the file system that is almost full. Once I know which file system, I go and search which files take up the most space in that file system and take action. Sometimes, df show that a file system is almost full while, when summing up all the space by all files doesn’t even come near that value.
Earlier, I explained how to setup CentOS or RHEL as a KVM virtualization host. You can find that explanation here. It also contains some basic terminology about virtualization which is also applicable for Xen. When talking about KVM, somehow, I immediately associate it with the Red Hat family just as when you talk about Xen, I associate it to Debian derivatives. So for this post, I’ll use Debian to install a host that will run Xen-VM’s by using paravirtualization.
In almost all cases, when mounting a CIFS-share on a Linux host, you will need to supply some credentials. Either you could enter the credentials by hand every time you need the share or add the credentials to /etc/fstab to automatically mount the share. Entering the password manually is secure but not comfortable, leaving the password in /etc/fstab is comfortable but not secure since the file /etc/fstab is world readable.
When using the latest version of Debian Wheezy or CentOS 6.5, even with all updates installed, by default, you can’t get a very recent kernel via the standard repositories in your package manager. While the idea of both distributions is to remain stable and rather conservative, there are several benefits with installing a newer kernel and in some cases it’s the only option to run one of these distributions. The risk and impact on stability is small and the process is rather simple.