Solid state drives sound ideal as they have no spinning parts and are very quiet, but they have a limited lifespan as you can’t write a memory cell only an X amount of times. But how to check your SSD on Linux to see if it is still in good shape? S.M.A.R.T. has become the standard for disk health years ago and can be queried by smartctl. So if we query for the health status and show all available attributes we get a good overview.
$ sudo smartctl -AH /dev/sda
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.14.8-300.fc27.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 000 Pre-fail Always - 0
5 Reallocate_NAND_Blk_Cnt 0x0033 100 100 000 Pre-fail Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 26329
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 164
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0
173 Ave_Block-Erase_Count 0x0032 010 010 000 Old_age Always - 2708
174 Unexpect_Power_Loss_Ct 0x0032 100 100 000 Old_age Always - 79
180 Unused_Reserve_NAND_Blk 0x0033 000 000 000 Pre-fail Always - 4403
183 SATA_Interfac_Downshift 0x0032 100 100 000 Old_age Always - 0
184 Error_Correction_Count 0x0032 100 100 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 048 036 000 Old_age Always - 52 (Min/Max 21/64)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 16
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 1
202 Percent_Lifetime_Used 0x0031 010 010 000 Pre-fail Offline - 90
206 Write_Error_Rate 0x000e 100 100 000 Old_age Always - 0
210 Success_RAIN_Recov_Cnt 0x0032 100 100 000 Old_age Always - 0
246 Total_Host_Sector_Write 0x0032 100 100 000 Old_age Always - 115599678623
247 Host_Program_Page_Count 0x0032 100 100 000 Old_age Always - 2235969936
248 Bckgnd_Program_Page_Cnt 0x0032 100 100 000 Old_age Always - 3472676821
The most interesting attributes are 202 on how much lifetime is left, but also 5, 180 and 9 that show your the number of replaced storage cells and how many hours the disk has been running. If attribute 5 and 180 are changing it is most definitely time to replace this solid state drive as memory cells have been worn out.
Bert Hubert from PowerDNS made an interesting announcement today. Retrieving the coordinates for an IPv4 address with just a DNS query.
Hopefully the country code will also be included, but this is an interesting way of using DNS as a directory service with public data.
Big sites like GitHub or GitLab are hosting a lot of projects and have numerous of releases a day. And while you as a person can watch a repository on GitHub, you can’t filter out new releases easily. At least not easily findable in the interfaces and checking all the repositories manually because they aren’t part of a build process is too much hassle and will fail in the end. So also for me with highlight.js as it has been updated from version 9.11.0 to 9.12.0 months ago.
Looking at some solutions people were writing about on StackOverflow for example was to parse the HTML and use that as a basis for actions to be executed. A quick check and grep of the output shown that we only have links to releases, but no structured data we can easily parse.
$ curl -s https://github.com/isagalaev/highlight.js/releases | grep -i releases\/tag
If we take the same URL and add the extension .atom to it, then GitHub presents the same data in a consumable feed format. Now we have structured data with timestamps, URLs and descriptions.
$ curl -s https://github.com/isagalaev/highlight.js/releases.atom
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/" xml:lang="en-US">
<link type="text/html" rel="alternate" href="https://github.com/isagalaev/highlight.js/releases"/>
<link type="application/atom+xml" rel="self" href="https://github.com/isagalaev/highlight.js/releases.atom"/>
<title>Release notes from highlight.js</title>
<link rel="alternate" type="text/html" href="/isagalaev/highlight.js/releases/tag/9.12.0"/>
<content type="html"><p>Version 9.12.0</p></content>
<media:thumbnail height="30" width="30" url="https://avatars2.githubusercontent.com/u/99931?v=4&s=60"/>
This data can be used by a custom parser or RSS-readers like TT-RSS, but also used by platforms like IFTTT to trigger actions like adding it to a backlog or posting it to a Slack-channel.
With the creation of RFC 4408 also new a record type 99 for DNS was created to identify SPF Resource Records. It was advised to have both TXT and SPF records in DNS with the same content. RFC 4408 was obsoleted by RFC 7208 in 2014 with paragraph 3.1 stating the following:
SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.
Now that the SPF Resource Record has been discontinued for a while, the time has come to remove it from DNS (if not done already) and make sure it never comes back. Luckily most code libaries already preferred the TXT variant, but still this is one to put on the maintenance checklist to remove it for any application code and/or infrastructure.
Last month CentOS 7.4 was announced and it was time to rebuild some servers from scratch to make sure all playbooks were still correct as it is always good to know you can quickly (re)build servers when needed. For some other servers, the impact would be big due to huge amounts of data that needed to be moved around and an in-place upgrade would be sufficient.
Upgrading is very straightforward as it the same as the update option with “–obsoletes” flag set which removes obsoleted packages. So let start with CentOS 7.3.
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)'
First, make sure all cached data is purged so we get the latest information. Secondly, run yum upgrade to download all required packages and install them. And thirdly, reboot your system.
$ sudo yum clean all
$ sudo yum upgrade
$ sudo systemctl reboot
When logging back into the system it presents itself as a server running CentOS 7.4.
$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
A side note to this procedure is not to use it on a server that has running applications and/or has users connecting to it. They may experience errors/failure during the upgrade procedure as libraries may not match what an application expects to start correctly or an essential service that is not running during the upgrade.