The Manjaro Linux developers announced the release of version 17.0.5 last week. My objective today is to use this release to show that Linux can be installed from scratch, configured and used for everyday work without using command line (text console) access, and without having to download, compile, install or otherwise perform any manual tasks to install device drivers or other hardware support.
Best of all, the complete installation and configuration can be done in well under an hour!
First, I want to be absolutely clear about this, if you already have Manjaro Linux installed it is not necessary to reinstall from scratch with this new release. All you need to do is make sure that your system has all the latest patches and updates installed and you will in fact be running this new release.
Often the best path to working with two vanguard technologies is unclear. That’s why OpenDev, a recent two-day event sponsored by the Ericsson, Intel and the OpenStack Foundation, dedicated a session to folks navigating Kubernetes and edge computing. Both technologies appear to be here to stay. “Containers are what the developers are using,” said Jeremy Huylebroeck of Orange Silicon Valley. “It’s way more convenient for them to actually publish their code and try things faster.”
OpenDev was devised as more of a workshop than a traditional conference, you can also check the event schedule for Etherpads from the individual sessions.
Moderated by Walmart’s Andrew Mitry, participants ranged from telecoms to large technology multinationals. The 54-minute working session touches on the following topics:
When last we met, we learned about lm-sensors, the excellent tool for monitoring CPU temperature, fan speeds, and motherboard voltages. Now we’re going to learn about changing the labels in sensors output to make it more useful, look at some good graphical front ends, and see how to configure and send notifications.
Customizing Labels
The default labels for your various sensors are sometimes not very helpful, as this snippet of sensors output shows.
fan1: 900 RPM
fan2: 1020 RPM
Fortunately, we can change the labels to anything we want. Let us relabel fan1 and fan2 more descriptively in the lm-sensors configuration file. (See Advanced lm-sensors Tips and Tricks on Linux for information on lm-sensor’s configuration file.)
Now in the sensors output it’s clear what they are.
CPU fan: 900 RPM
Case fan: 1020 RPM
Psensor
Psensor is my favorite lm-sensors graphical front-end. It supports multiple system monitors, including lm-sensors, hddtemp, smartmontools, and XNVCtrl for monitoring NVidia GPU temperatures. I love its nice user-friendly interface because all configurations are right there and you don’t have to hunt for them (Figure 1).
Psensor graphical front-end for lm-sensors.
There are checkboxes on the right of the main window to control which sensors appear in the graph. Click on any sensor to configure it; options include hiding it, graph color, setting alarm thresholds, enabling desktop notifications, and changing its name. Change colors, monitoring intervals, enable logging, and set which monitors Psensor listens to in the Psensor > Preferences menu (Figure 2).
Preferences menu
Desktop alerts are good, and Psensor supports scripts to execute any kind of notifications or actions you want. Enter your script name on the Psensor > Preferences > Sensors tab, in the “Script executed when alarm is raised” field. This example script sends an email and shuts down the computer when CPU temperatures are too high.
#!/bin/bash
echo "I am shutting down right now!" |
/usr/bin/mail -s "[LinuxServer] I'm melting, help"
carla@bratgrrl.com && shutdown -h now
This simple script plays a sad trombone:
#!/bin/bash
play /home/carla/sounds/sad_trombone.wav
These scripts use good old-fashioned Unix commands to do the work. /usr/bin/mail is provided by the s-nail package on my Ubuntu 16.04 system. Other distributions use mailx, which installs the traditional BSD mail client.
mail can send messages directly, without needing an SMTP server. Maybe it’s just me, but I kept having problems and couldn’t get it to send messages, so I installed ssmtp, the simple SMTP server. If you’re already running an MTA like Postfix or Exim, you don’t need ssmtp. ssmtp is not a mail transfer agent (MTA) like Postfix and Exim. It is a simple relay agent that sends messages to an upstream mail server. You must configure /etc/ssmtp/ssmtp.conf to accept messages in the same way that you configure your mail client, with the server name and port, TLS/SSL type, and your authorization if your upstream server requires it. This example is typical of hosted mail servers, which usually rely on STARTTLS.
It also has options for configuring the locations of SSL certificates if necessary. Whatever your regular mail client needs is what ssmtp needs. If you get the “sendmail: Cannot open mail.example.com:25” error when you send a message then your port number or TLS/SSL configuration is wrong. See man 5 ssmtp.conf for complete options.
You also need to add all local system users that will send notifications to /etc/ssmtp/revaliases:
Another cool notification option is to send yourself SMS text messages. There are a couple of ways to do this on Linux. One is to use a commercial SMS gateway, which is easy and costs a little money. Another way is to use a USB GSM modem plugged into your computer, with a prepaid SIM card. This is a fun topic for another day, and if you have done this, please give some details in the comments.
More Graphical Interfaces
Graphical front ends to lm-sensors come and go. Conky and xsensors are two reliable oldtimers. Conky is endlessly configurable and supports everything under the sun. xsensors is barebones. Both run without complaints on all Linux distributions.
Temperature sensor plugin
I like having a set of temperature sensors in my taskbar. These are specific to the graphical desktop environment you are running. Thermal Monitor for KDE is pretty nice. I use xfce4-sensors-plugin on my Xfce4 desktop (Figure 3).
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
At organizations of all types, launching and maintaining successful open source programs has become a business priority. A strong open source program office helps to ensure that open source is supported, nurtured, shared, explained, and leveraged. With such an office, organizations can establish and execute on their open source strategies in clear terms.
With all this in mind, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published a free collection of detailed open source guides to aid companies developing open source programs.The guides are availableto you now, and this is the first in a series of articles that can introduce you to the value of the guides.
Modular documentation is not a new concept. Writing documentation in modules that can be combined and reused has been around, in various incarnations, for many years, and it has many proponents as well as detractors. This article introduces a lightweight approach to documentation modularity. The idea is rooted in improving content by giving it a better focus through user stories. (See Documentation based on user stories for a discussion on how user story-based documentation compares with feature-based docs.)
DITA and friends
Let me emphasize right from the start: This is not DITA (Document Information Typing Architecture), nor has the approach been inspired by DITA. The focus is on user story-based documentation, and its modular structure is a means to an end—simplifying authoring, ensuring consistency, and streamlining documentation processes.
The types of logical storage structures used in today’s Kubernetes deployments offer some deeper revelations into the nature of workloads being deployed. Block storage is king, having been cited by two-thirds (66 percent) of respondents in our survey for The State of the Kubernetes Ecosystem as being involved with their Kubernetes implementations.
Object storage is used by 29 percent of respondents, which is relatively high compared with adoption rates for object storage that we’ve seen in the past. Since object storage is scalable, developers working on distributed systems likely have experience with it already. In addition, object storage is often used to deliver static content for websites, which is also a common type of workload for Kubernetes.
Both are designed to enable IT and DevOps professionals to more easily deploy, manage and scale container-based applications and services. This means enterprises can reduce application delivery cycle times.
SUSE CaaS Platform 2 adds powerful tools to simplify large-scale application deployment, incorporates an updated release of Kubernetes, and streamlines public cloud container orchestration.
Using microservices to solve real-world problems always involves more than simply writing the code. You need to test your services. You need to figure out how to do continuous deployment. You need to work out clean, elegant, resilient ways for them to talk to each other.
A really interesting tool that can help with the “talk to each other” bit is Lyft’s Envoy.
Lyft Envoy Overview
Lyft Envoy is a modern, high performance, small footprint edge and service proxy. Envoy adds resilience and observability to your services, and it does so in a way that’s transparent to your service implementation.
Today, a new class of field software updates is arising that has been fueled by security concerns but also allows engineers to add new features and fix bugs.
With regards to embedded devices, the firmware update mechanism must be not only secure, but also reliable in that it either succeeds in the update or fails to a recoverable state. In no way should the software update brick a device, and it should be able to happen unattended. Most updates must also preserve the previous device state, although on some occasions recovering a device could involve resetting to a default state.
There is also the question of atomicity. The Linux server world is used to performing package-based updates, and everything seems to work just fine. But an embedded device is not a server.
This week I was working on a Kubernetes networking problem. Basically our container network backend was reporting that it couldn’t delete routes, and we didn’t know why.
I started reading the code that was failing, and it was using a library called “netlink”. I’d never heard of that before this week.
what’s netlink?
Wikipedia says:
Netlink socket family is a Linux kernel interface used for inter-process communication (IPC) between both the kernel and userspace processes, and between different userspace processes, in a way similar to the Unix domain sockets.
The program I was debugging was creating/deleting routes from the route table.
