Arrive On Time With NTP — Part 1: Usage Overview

By

-

January 18, 2017

Few services on the Internet can claim to be so critical in nature as time. Subtle issues which affect the timekeeping of your systems can sometimes take a day or two to be realized, and they are almost always unwelcome because of the knock-on effects they cause.

Consider as an example that your backup server loses connectivity to your Network Time Protocol (NTP) server and, over a period of a few days, introduces several hours of clock skew. Your colleagues arrive at work at 9am as usual only to find the bandwidth-intensive backups consuming all the network resources meaning that they can barely even log into their workstations to start their day’s work until the backup has finished.

In this first of a three-part series, I’ll provide brief overview of NTP to help prevent such disasters. From the timestamps on your emails to remembering when you started your shift at work, NTP services are essential to a happy infrastructure.

You might consider that the really important NTP servers (from which other servers pick up their clock data) are at the bottom of an inverted pyramid and referred to as Stratum 1 servers (also known as “primary” servers). These servers speak directly to national time services (known as Stratum 0, which might be devices such as atomic clocks or GPS clocks, for example). There are a number of ways of communicating with them securely, via satellite or radio, for example.

Somewhat surprisingly, it’s reasonably common for even large enterprises to connect to Stratum 2 servers (or “secondary” servers) as opposed to primary servers. Stratum 2 servers, as you’d expect, synchronize directly with Stratum 1 servers. If you consider that a corporation might have their own onsite NTP servers (at least two, usually three, for resilience) then these would be Stratum 3 servers. As a result, such a corporation’s Stratum 3 servers would then connect upstream to predefined secondary servers and dutifully pass the time onto its many client and server machines as an accurate reflection of the current time.

A simple design component of NTP is that it works on the premise — thanks to the large geographical distances travelled by Internet traffic — that round-trip times (of when a packet was sent and how many seconds later it was received) are sensibly taken into account before trusting to a time as being entirely accurate. There’s a lot more to setting a computer’s clock than you might at first think, if you don’t believe me, then this fascinating web page is well worth looking at.

At the risk of revisiting the point, NTP is so key to making sure your infrastructure functions as expected that the Stratum servers to which your NTP servers connect to fuel your internal timekeeping must be absolutely trusted and additionally offer redundancy. There’s an informative list of the Stratum 1 servers available at the main NTP site.

As you can see from that list, some NTP Stratum 1 servers run in a “ClosedAccount” state; these servers can’t be used without prior consent. However, as long as you adhere to their usage guidelines, “OpenAccess” servers are indeed open for polling. Any “RestrictedAccess” servers can sometimes be limited due to a maximum number of clients or a minimum poll interval. Additionally, these are sometimes only available to certain types of organizations, such as academia.

Respect My Authority

On a public NTP server, you are likely to find that the usage guidelines follow several rules. Let’s have a look at some of them now.

The “iburst” option involves a client sending a number of packets (eight packets rather than the usual single packet) to an NTP server should it not respond during at a standard polling interval. If, after shouting loudly at the NTP server a few times within a short period of time, a recognized response isn’t forthcoming, then the local time is not changed.

Unlike “iburst” the “burst” option is not commonly allowed (so don’t use it!) as per the general rules for NTP servers. That option instead sends numerous packets (eight again apparently) at each polling interval and also when the server is available. If you are continually throwing packets at higher-up Stratum servers even when they are responding normally, you may get blacklisted for using the “burst” option.

Clearly, how often you connect to a server makes a difference to its load (and the negligible amount of bandwidth used). These settings can be configured locally using the “minpoll” and “maxpoll” options. However, to follow the connecting rules on to an NTP server, you shouldn’t generally alter the the defaults of 64 seconds and 1024 seconds, respectively.

Another, far from tacit, rule is that clients should always respect Kiss-Of-Death (KOD) messages generated by those servers from which they request time. If an NTP server doesn’t want to respond to a particular request, similar to certain routing and firewalling techniques, then it’s perfectly possible for it to simply discard or blackhole any associated packets.

In other words, the recipient server of these unwanted packets takes on no extra load to speak of and simply drops the traffic that it doesn’t think it should serve a response to. As you can imagine, however, this isn’t always entirely helpful, and sometimes it’s better to politely ask the client to cease and desist, rather than ignoring the requests. For this reason, there’s a specific packet type called the KOD packet. Should a client be sent an unwelcome KOD packet then it should then remember that particular server as having responded with an access-denied style marker.

If it’s not the first KOD packet received from back the server, then the client assumes that there is a rate-limiting condition (or something similar) present on the server. It’s common at this stage for the client to write to its local logs, noting the less-than-satisfactory outcome of the transaction with that particular server, if you ever need to troubleshoot such a scenario.

Bear in mind that, for obvious reasons, it’s key that your NTP’s infrastructure be dynamic. Thus, it’s important not to hard-code IP addresses into your NTP config. By using DNS names, individual servers can fall off the network and the service can still be maintained, IP address space can be reallocated and simple load balancing (with a degree of resilience) can be introduced.

Let’s not forget that we also need to consider that the exponential growth of the Internet of Things (IoT), eventually involving billions of new devices, will mean a whole host of equipment will need to keep its wristwatches set to the correct time. Should a hardware vendor inadvertently (or purposely) configure their devices to only communicate with one provider’s NTP servers (or even a single server) then there can be — and have been in the past — very unwelcome issues.

As you might imagine, as more units of hardware are purchased and brought online, the owner of the NTP infrastructure is likely to be less than grateful for the associated fees that they are incurring without any clear gain. This scenario is far from being unique to the realms of fantasy. Ongoing headaches — thanks to NTP traffic forcing a provider’s infrastructure to creak — have been seen several times over the last few years.

In part two, I’ll look at some important security configuration options and then describe server setup in part three.

Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.

Advance your career in system administration! Check out the Essentials of System Administration course from The Linux Foundation.

Lightning Talk – Realizing the Multi-Cloud Promise of Kubernetes by Blake White, The Walt Disney Co.

By

The Linux Foundation

-

January 18, 2017

Disney’s diverse business units and applications require running in multiple cloud environments. This talk will touch on some of the tools and techniques used to realize the cross cloud promise, as well as some of the challenges and their solutions.

Who Contributes to the Linux Kernel?

By

The New Stack

-

January 18, 2017

While many people tend to think of open source projects as being developed by passionate volunteers, the Linux kernel is mostly developed by people who are paid by their employers to contribute. According to The Linux Foundation, since 2005, “some 14,000 individual developers from over 1,300 different companies have contributed to the kernel.”

About once a year, The Linux Foundation releases the Linux Kernel Development report with data about release frequency, rate of change, who contributes, and which companies sponsor this work among other things. The 25th Anniversary Edition released in August 2016, covers development through the 4.7 release (July 24, 2016), with an emphasis on 3.19 to 4.7, which were released since the previous report in February 2015.

One of the most interesting data points is the decline of contributions from unpaid developers, which has decreased to just 7.7 percent in the period covered in the 2016 report compared to 14.6 percent in the 2012 version.

Moving Persistent Data Out of Redis

By

GitHub Engineering

-

January 18, 2017

Historically, we have used Redis in two ways at GitHub:

We used it as an LRU cache to conveniently store the results of expensive computations over data originally persisted in Git repositories or MySQL. We call this transient Redis.

We also enabled persistence, which gave us durability guarantees over data that was not stored anywhere else. We used it to store a wide range of values: from sparse data with high read/write ratios, like configuration settings, counters, or quality metrics, to very dynamic information powering core features like spam analysis. We call this persistent Redis.

Public Cloud on the Rise While Private Cloud Usage Declines

By

SDx Central

-

January 18, 2017

The use of public clouds has nearly doubled to 57 percent from 30 percent since 2012, while private cloud use has dropped to 40 percent from 52 percent, according to an Interop ITX and InformationWeek survey.

Even further, the respondents who use a private cloud estimate a 12 percent drop between current and future usage, with 28 percent expecting to use a private cloud for new projects.

17 Essential Skills for Growing Performance Engineers

By

SOASTA

-

January 18, 2017

Performance engineering as a discipline goes back several decades. I’ve heard firsthand accounts of testing and optimization of software from the 1960s. Still, much of what we practice today has built up in the last twenty years or so, since the first generation of commercial performance testing tools started appearing.

It can be hard to describe all the different skills that go into performance engineering. Most people in the field agree that it is a intersection of disciplines that includes testing, optimization, and systems engineering. There are great depths to be explored even in these subjects, and they need to be thought about in order to think about how to make more of us.

Quick jump to start NodeJS development on LTPS boards

By

Dmitry Dvorkin

-

January 18, 2017

Unlike Node.js, Git and Python 2.7, NPM is not installed on each LTPS by default.

To install it, you should connect to the LTPP board from an SSH client and do the following steps:

# Setup package repositories (if it's not done already)
smart channel --add a0 type=rpm-md name="LTPS all" baseurl=${RPMSBASE}/all/ -y
smart channel --add a1 type=rpm-md name="Tibbo LTPS general" baseurl=${RPMSBASE}/cortexa8hf_neon/ -y
smart channel --add a2 type=rpm-md name="Tibbo LTPS tpp" baseurl=${RPMSBASE}/tpp/ -y
smart update

# Install NPM
smart install nodejs-npm -y

# Enhance Git functionality. Required if you want to install NPM modules directly from Git.
smart install git-perltools -y

# Install build-essential (GCC, Make, libraries etc). Required for on-board compilation of native C addons.
smart install packagegroup-core-buildessential -y

Define your Tibbits layout

Various Tibbits require various resources. For instance, a relay Tibbit set into the socket S1 of the LTPP3 board will require the S1 interface lines to operate as general-purpose I/O (GPIO) lines. The RS232 Tibbit set into the same socket will need a UART to be enabled and mapped to this Tibbit’s interface lines.

The LTPP3 gives you an interactive graphical tool to define your Tibbit configuration (to specify what Tibbit goes into what socket). The tool also checks out if there are no problems/mistakes with your configuration. As soon as the desired layout is created and saved, you should reboot the board to let the new configuration take charge. See the video below to get the idea of the configuration process.

https://vimeo.com/185297307

When giving our code examples a try or testing your own projects, don’t forget to define the proper Tibbit configuration before running the corresponding code.

Writing SELinux Modules

By

Linux Pro Magazine

-

January 18, 2017

SELinux struggles to cast off its image as difficult to maintain and the cause of potential application problems. Yet in recent years, much has changed for the better, especially with regard to usability. For example, modules have replaced its monolithic set of rules. If you want to develop a new SELinux module, three files are typically necessary for this purpose.

Three Files for an SELinux Module

A type enforcement (.te) file stores the actual ruleset. To a large extent, it consists of m4 macros, or interfaces. For example, if you want to access a particular service’s resources, such as the logfiles, the service provides a corresponding interface for this purpose. If you want your own application to access these resources, you can draw this on the service’s interface without having to deal with the logfile details. For example, you do not need to know the logfile’s security label, because the interface abstracts access.

A Quick Guide to Network Administrator Course and Jobs

By

Michael warne

-

January 18, 2017

A career in network administration is full of opportunities today. With the world becoming more digitalized and the emergence of a booming IT industry, there are countless new prospects and jobs being shaped every year. With the increase in computer and software led companies, there is an even bigger need of network administrators, especially the large organisations.

What Does a Network Administrator Do Exactly?

An organisation who uses several computer systems or software platforms, requires a network administrator. A network administrator or a system administrator ensures that all the computer networks of an organisation are running smoothly and are always updated. This job can be extensive or narrow, based on the size of an organisation. The complexity of the network or the software platform is another factor. Installing computer systems and software; maintenance and troubleshooting; and updating the systems are some of the key roles played by a network administrator in an organisation. Moreover, a system or network administrator is also responsible for maintaining the wide area networks (WAN), local area networks (LAN), data and tele-communication networks, intranet and other similar segments. Other responsibilities include maintaining websites and all its functioning.

Skills and Qualifications Needed to Become a Network Administrator

If you are interested in becoming a network administer, you do not necessarily need a degree or qualification in the IT. Although, you do need an interest in the field in addition to some amount of fundamental knowledge of the roles discussed above. Any beginner who aspires to become a network administrator can sign up for a network administrator course. These courses can be studied at the undergraduate level (preferable by most). In fact, you can also major in network administration. A network administrator training would enable you to configure, troubleshoot and repair core network devices, communications systems and all types of IP services etc. The course structure might differ from the package you have selected. Some of these courses provide a general guide to network administrations but some courses provide training in vendor specific software and applications like Linux, Cisco, Microsoft etc. Several colleges, universities and local institutions offer these courses to both the beginners and experienced ones.

Employment Outlook and Demand for Network Administrators

Since the IT industry is growing rapidly and is expected to grow even more in coming years, network administrators have great job opportunities. These jobs are fairly compensated too. Though, your choice of organisation and expertise are the deciding factors in this case. The more skilled you are and bigger the responsibility, the better is the salary. With a relevant training and degree in network administration, you can work in almost any industry because almost all the industries are dependent on computer systems and networks for functioning.

In a nutshell, there are great prospects awaiting you, if you think you have got what it takes to set a foot in this door. Moreover, the compensation and roles are expected to grow in the upcoming years, promising better offers ahead.

3 Lessons in Web Encryption from Let’s Encrypt

By

Josh Aas

-

January 17, 2017

As exciting as 2016 was for encryption on the Web, 2017 seems set to be an even more incredible year. Much of the infrastructure and many of the plans necessary for a 100 percent encrypted Web really solidified in 2016, and the Web will reap the rewards in 2017. Let’s Encrypt is proud to have been a key part of that.

But before we start looking ahead, it’s helpful to look back and see what our project learned from our exciting first full year as a live certificate authority (CA). I’m incredibly proud of what our team and community accomplished during 2016. I’d like to share how we’ve changed, what we’ve accomplished, and what we’ve learned.

At the start of 2016, Let’s Encrypt was supporting approximately 240,000 active (unexpired) certificates. That seemed like a lot at the time! Now we’re frequently issuing that many new certificates in a single day while supporting more than 22 million active certificates in total.

We added several new features during the past year, including support for the ACME DNS challenge, ECDSA signing, IPv6, and IDN.

We were accepted into the Mozilla, Apple, and Google root programs. And we’re close to announcing acceptance into another major root program. These are major steps towards being able to operate as an independent CA. You can read more about why here.

Finally, supporting the kind of growth we saw in 2016 meant adding staff, and during the past year Internet Security Research Group (ISRG), the non-profit entity behind Let’s Encrypt, went from four full-time employees to nine. We’re still a pretty small crew given that we’re now one of the largest CAs in the world (if not the largest), but it works because of our intense focus on automation, the fact that we’ve been able to hire great people, and because of the incredible support we receive from the Let’s Encrypt community.

Let’s Encrypt is a Linux Foundation collaborative project whose mission is to help create a 100 percent encrypted Web. Our own metrics can be interesting, but they’re only really meaningful in terms of the impact they have on progress towards a more secure and privacy-respecting Web. Here are three big takeaways from our work in 2016 that we plan to build on this year in pursuit of our goal.

3 Lessons from Let’s Encrypt in 2016

1. Getting and managing certificates needs to be easy

The metric we use to track progress towards full Web encryption is the percentage of page loads using HTTPS, as seen by browsers. According to Firefox Telemetry, the Web has gone from approximately 39 percent of page loads using HTTPS each day to just about 49 percent during the past year.

We’re incredibly close to a Web that is more encrypted than not.

We’re proud to have been a big part of that, but we can’t take credit for all of it. Many people and organizations around the globe have come to realize that we need to invest in a more secure and privacy-respecting Web, and have taken steps to secure their own sites as well as their customers’.

What many of these efforts have in common is that they focus on making the switch to HTTPS easy, and that’s why so many sites have switched in the past year. Some providers moved sites to HTTPS by default, without site owners having to do anything. Some providers made HTTPS a one-click option. Others made the switch easier in various ways and greatly improved documentation. Let’s Encrypt offers a simple API for everyone to use, and our community has created great tools to make life easier.

2. Bugs happen and transparency is key

We learned some technical lessons this year. When we had service interruptions they were usually related to managing the rapidly growing database backing our CA. Also, while most of our code had proper tests, some small pieces didn’t and that led to incidents that shouldn’t have happened.That said, I’m proud of the way we handle incidents promptly, including quick and transparent public disclosure.

We’ve done a lot of optimization work, we’ve had to add some hardware and improve our testing, and there have been some long nights for our staff, but we’ve been able to keep up and we’re ready for another year of strong growth.

3. We need a strong community to create a diverse set of great ACME clients

We also learned a lot about our client ecosystem. At the beginning of 2016, ISRG/Let’s Encrypt provided client software called letsencrypt. We’ve always known that we would never be able produce software that would work for every Web server/stack, but we felt that we needed to offer a client that would work well for a large number of people and that could act as a sort of reference client.

By March of 2016, earlier than we had foreseen, it had become clear that our community was up to the task of creating a wide range of quality clients, and that our energy would be better spent fostering that community than producing our own client. That’s when we made the decision to hand off development of our client to the Electronic Frontier Foundation (EFF). EFF renamed the client to Certbot and has been doing an excellent job maintaining and improving it as one of many client options.

We thank everyone who contributed to our client ecosystem and also those who have installed a Let’s Encrypt certificate. Each of these conversions from HTTP to HTTPS make the Web a little bit more secure. Let’s Encrypt is a 501(c)3 nonprofit, so we are also grateful to our sponsors, for making our successes this past year possible.

Please consider getting involved or making a donation, and if your company or organization would like to sponsor Let’s Encrypt, please email us at sponsor@letsencrypt.org.