Archive: Jan 2016

  1. How to keep your linux server secure – unattended security upgrades

    There are many steps to securing a server, but one of the most fundamental is to make sure that all of the core software running on it has all of the latest security patches implemented. Yet most linux installations, including the numerous virtual servers that can be deployed almost instantly, don’t have any automatic mechanism for updating the installed software packages enabled by default. That’s primarily because of the flexibility that linux offers – there is no assumption that one solution will suit every deployment.

    However, there is a minimum that is recommended for most situations – and that is to run all of the security updates for the installed linux distribution on a daily basis. Although you wouldn’t likely stumble on the solution as to how to do this by accident, it is relatively painless to set up using the unattended-upgrades package.

    First, you have to install the package itself, along with some mail software so that the system can email you the results of the process. Then it’s just a question of making a few configuration changes. After that, the update process should be picked up by the cron.daily script and run every day.

    Step 1

    Install the unattended-upgrades package and bsd-mailx (which will be used to send you email notifications of the success or otherwise of an update):

    apt-get install unattended-upgrades bsd-mailx
    

    As part of the bsd-mailx installation you will need to configure Postfix, if you haven’t already done so. Assuming your server has a fully qualified domain name (FQDN) and is connected to the internet, it is likely that you will be able to use the default options.

    Step 2

    The main configuration file for the unattended-upgrades updates will be located here:

    /etc/apt/apt.conf.d/50unattended-upgrades
    

    To edit it, it’s probably easiest to use one of the built in command line editors like vi, although you’ll need to remember to type ‘i’ to insert text and then ‘:wq’ to save afterwards:

    vi /etc/apt/apt.conf.d/50unattended-upgrades
    

    There are a lot of lines in that file, most of which are already commented out. The default configuration should have the following section uncommented – which is all that you need to get the security updates to work:

    // Automatically upgrade packages from these 
    // (origin:archive) pairs
    Unattended-Upgrade::Allowed-Origins {
        “${distro_id}:${distro_codename}-security”; 
    };
    

    The other lines in that section of the file which are commented out deal with running other, non-security updates automatically. You can ignore those for now. But you will need to uncomment the Unattended-Upgrade::Mail line further down in the file if you want the system to report progress to you:

    // Send email to this address for problems or packages upgrades
    Unattended-Upgrade::Mail “root@localhost”;
    
    You can change the email address here to your own. However, I prefer to leave it to send email notifications to root and to set up an alias to forward all email sent to root to me. You can do this by adding a line to the /etc/aliases file: `root: your@email.com`. Remember to run `newaliases` afterwards to rebuild the aliases database.

    Step 3

    Finally, edit the file that runs the upgrades on a periodic basis:

    vi /etc/apt/apt.conf.d/10periodic
    

    When you’re finished it should contain the following:

    APT::Periodic::Enable "1"; 
    APT::Periodic::Update-Package-Lists "1"; 
    APT::Periodic::Download-Upgradeable-Packages "1"; 
    APT::Periodic::Unattended-Upgrade "1"; 
    APT::Periodic::AutocleanInterval "7";
    

    That’s it! You should start receiving daily emails about any packages that have been upgraded on your server. You really should read these because there may be problems with the process, and there definitely will be occasions when a reboot is required to finish the upgrade.

    This solution only deals with security updates. There will be lots of other updates to the software packages you use on your server – such as new features or other non-security related changes. If you want, you can enable those in the 50unattended-upgrades file as well, by uncommenting the other files in the main configuration section. However, I prefer to handle those changes manually in case an upgrade impacts other parts of the system.

  2. Responsive Images – native browser support and WordPress 4.4

    Using responsive images means ensuring that the right type and size of image is sent to the browser requesting it. That means not sending a massive image file to a mobile browser that is only going to display it in a tiny window. It also means ensuring that if the user is viewing your site on a big, high resolution display that they don’t end up with something blurry and hard to make out.

    Browsers have begun gradually to support [responsive images] natively

    It is some time since I last looked at responsive images in detail, during which time browsers have begun gradually to support them natively – without the need for the various javascript workarounds that were required before.

    There remain two approaches to the use of responsive images: a new <picture> element (which this site used to use), and new srcset and sizes attributes to extend <img> and <source> elements. A full explanation of the difference, and how they can be used together, can be found on the Responsive Images Community Group site; with more information about use cases in an excellent A List Apart article: Using Responsive Images (Now).

    In short, the <picture> element allows for art direction-based selection – you can specify entirely different images to display at different browser sizes and have complete control over the process; the srcset attribute (and associated sizes attribute) lists the pool of source images from which the browser can pick to load depending on the browser environment. They are complimentary technologies – both can be used to ensure that, typically, a mobile browser is sent a smaller file than a desktop browser – and both are being drafted into the HTML 5.1 specification.

    All of the leading browsers (and by leading browsers, I mean leading modern browsers, not Internet Explorer) now support the new srcset and sizes attributes, including:

    • Blink / Chrome / Opera
    • WebKit / Safari
    • Mozilla Firefox

    One other, Microsoft Edge, has the attribute extensions in development.

    The <picture> element is also supported by:

    • Blink / Chrome / Opera
    • Mozilla Firefox

    As of iOS 9.3 and OS X 10.11.4 (both currently in beta), it will also be supported by WebKit / Safari. It is currently under consideration by Microsoft Edge.

    This site used to use a plugin for converting images to use the <picture> element, but it’s no longer required because the latest edition of WordPress (4.4 at the time of writing) now includes native support for srcset and sizes attributes. This is a distinct improvement: along with the wider browser support it means that there is no longer a requirement to use javascript to deliver the right image or plugins to generate the necessary responsive image code. It also means that it is easy to add other classes (and other markup) to an image without it being lost in any plugin conversion.

    So, if you are viewing this page in a relatively modern browser, the image below should vary in file size depending on the width of your browser and resolution of your screen. But it should always look good – as all Sinclair products should.

    Photo - Sinclair Spectrum

    You’ll get a different version of this image of a Sinclair Spectrum depending on your browser width and screen resolution