Since its inception the CII has considered network time, and implementations of the Network Time Protocol, to be “core infrastructure.” Correctly synchronising clocks is critical both to the smooth functioning of many services and to the effectiveness of numerous security protocols; as a result most computers run some sort of clock synchronization software and most of those computers implement either the Network Time Protocol (NTP, RFC 5905) or the closely related but slimmed down Simple Network Time Protocol (SNTP, RFC 4330).
The CII recently sponsored a security audit of the Chrony code, carried out by the security firm Cure53 (here is the report). In recent years, the CII has also provided financial support to both the ntpd project and the NTPSec project. Cure53 carried out security audits of both ntpd and NTPSec earlier this year and Mozilla Foundation’s Secure Open Source (SOS) project funded those two audits. SOS also assisted the the CII with the execution of the Chrony audit.
Since the CII has offered support to all three projects and since all three were reviewed by the same firm, close together in time, we thought it would be useful to present a direct comparison of their results.
Open source software can be a double-edged sword for startups. It can be a startup’s lifeblood, because it helps you innovate rapidly without starting from scratch. But, as they say, open source software is free like a puppy is free: The true cost of open source software is obeying open source licenses.
Misuse of open source software can delay or derail investment and corporate exit opportunities. But you can easily comply with open source licenses if you follow these simple rules.
Don’t use software without license terms. Some software on the internet doesn’t contain licensing notices, but that doesn’t mean that it can be used freely. The people posting the software may not have complied with upstream licensing terms. Or the author of the software may not yet have applied a license to the software—open source or otherwise. “No license terms” means no license: You should either avoid using the software or ask the author to apply a permissive license.
The open-source OpenDaylight project release its second milestone update for 2017 on Sept. 26, with the debut of the Nitrogen release.
Nitrogen is the seventh major release from OpenDaylight and follows the Carbon release that debutedin June 2017. OpenDaylight first started in April 2013 as a Linux Foundation Collaborative Project, with the goal of building an open SDN platform.
The primary update in the Nitrogen release is a re-factoring to support the Apache Karaf 4.0 container bundle.
At this year’s Kids Day workshop at Open Source Summit in Los Angeles, The Linux Foundation collaborated with LA MakerSpace.org to provide kids with an introduction to coding ideas and approaches. The LA MakerSpace is heavily influenced by the maker culture, so they have a very hands-on approach when it comes to teaching coding.
Hands On
That hands-on approach was visible at the workshop through the use of a lot of real-life accessories. For example, the space featured a huge ball pit with sensors installed so kids could program the sensors and collect data. A cup of water was used as a switch; when you dipped your finger in the water, it sent a signal to turn a device on or off. And, the kids used an open source Scratch program to learn coding.
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.
