Elsewhere

Drupal Blog: Drupal 8.2.3 and 7.52 released

Planet Drupal - Wed, 16/11/2016 - 19:11

Drupal 8.2.3 and Drupal 7.52, maintenance releases which contain fixes for security vulnerabilities, are now available for download.

See the Drupal 8.2.3 and Drupal 7.52 release notes for further information.

Download Drupal 8.2.3
Download Drupal 7.52

Upgrading your existing Drupal 8 and 7 sites is strongly recommended. There are no new features nor non-security-related bug fixes in these releases. For more information about the Drupal 8.2.x release series, consult the Drupal 8 overview. More information on the Drupal 7.x release series can be found in the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 8 and 7 include the built-in Update Manager module, which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 8.2.x and 7.x are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Change log

Drupal 8.2.3 is a security release only. For more details, see the 8.2.3 release notes. A complete list of all changes in the stable 8.2.x branch can be found in the git commit log.

Drupal 7.52 is a security release only. For more details, see the 7.52 release notes. A complete list of all changes in the stable 7.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 8.2.3 and 7.52 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisories:

To fix the security problem, please upgrade to either Drupal 8.2.3 or Drupal 7.52.

Update notes

See the 8.2.3 and 7.52 release notes for details on important changes in this release.

Known issues

See the 8.2.3 release notes or 7.52 release notes for a list of known issues affecting each release.

Categories: Elsewhere

Valuebound: Create Custom content type programmatically using Configuration API in Drupal 8

Planet Drupal - Wed, 16/11/2016 - 18:08

Drupal 8 has quality of utility tool could help anyone to develop custom module box. One of the tool is Drupal Console, where any developer can follow the Terminal Command and generate the boilerplate for source code. Which help us to reduce time to write chuck line of code. And also help us to overcome with error rate to produce zero marginal error. Kind of typo & syntax error ;) . if you haven’t aware of Drupal Console then just go through it by installing on your local Drupal 8 instance. For fresh code like creating block or user or view or node I will suggest you boilerplate code. But as a New learner my suggestion would be always to write line by line code.

Here is the command that you need to generate Custom Content type using Drupal Console  generate:…

Categories: Elsewhere

Redfin Solutions: Redfin's Front-End Shell: Bundler, Susy, Compass, Breakpoint, and more!

Planet Drupal - Wed, 16/11/2016 - 16:51
Chris November 16, 2016 Redfin's Front-End Shell: Bundler, Susy, Compass, Breakpoint, and more!

While we at Redfin don't really yet have a full on base theme for every project, one thing we do use is our "bundler shell." This forms the basis of any Drupal 7 or 8 theme we build, and in fact, is really just the framework for the front-end (that is, this shell is useful outside of the realm of Drupal, actually).

First things first - here's the code.

Let's go ahead and begin the dissection...

Categories: Elsewhere

Joey Hess: Linux.Conf.Au 2017 presentation on Propellor

Planet Debian - Wed, 16/11/2016 - 16:13

On January 18th, I'll be presenting "Type driven configuration management with Propellor" at Linux.Conf.Au in Hobart, Tasmania. Abstract

Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to attend it again.

Categories: Elsewhere

Joey Hess: Linux.Conf.Au 2017 presentation on Propellor

Planet Debian - Wed, 16/11/2016 - 16:13

On January 18th, I'll be presenting "Type driven configuration management with Propellor" at Linux.Conf.Au in Hobart, Tasmania. Abstract

Linux.Conf.Au is a wonderful conference, and I'm thrilled to be able to attend it again.

Categories: Elsewhere

Bits from Debian: Debian Contributors Survey 2016

Planet Debian - Wed, 16/11/2016 - 15:45

The Debian Contributor Survey launched last week!

In order to better understand and document who contributes to Debian, we (Mathieu ONeil, Molly de Blanc, and Stefano Zacchiroli) have created this survey to capture the current state of participation in the Debian Project through the lense of common demographics. We hope a general survey will become an annual effort, and that each year there will also be a focus on a specific aspect of the project or community. The 2016 edition contains sections concerning work, employment, and labour issues in order to learn about who is getting paid to work on and with Debian, and how those relationships affect contributions.

We want to hear from as many Debian contributors as possible—whether you've submitted a bug report, attended a DebConf, reviewed translations, maintain packages, participated in Debian teams, or are a Debian Developer. Completing the survey should take 10-30 minutes, depending on your current involvement with the project and employment status.

In an effort to reflect our own ideals as well as those of the Debian project, we are using LimeSurvey, an entirely free software survey tool, in an instance of it hosted by the LimeSurvey developers.

Survey responses are anonymous, IP and HTTP information are not logged, and all questions are optional. As it is still likely possible to determine who a respondent is based on their answers, results will only be distributed in aggregate form, in a way that does not allow deanonymization. The results of the survey will be analyzed as part of ongoing research work by the organizers. A report discussing the results will be published under a DFSG-free license and distributed to the Debian community as soon as it's ready. The raw, disaggregated answers will not be distributed and will be kept under the responsibility of the organizers.

We hope you will fill out the Debian Contributor Survey. The deadline for participation is: 4 December 2016, at 23:59 UTC.

If you have any questions, don't hesitate to contact us via email at:

Categories: Elsewhere

Bits from Debian: Debian Contributors Survey 2016

Planet Debian - Wed, 16/11/2016 - 15:45

The Debian Contributor Survey launched last week!

In order to better understand and document who contributes to Debian, we (Mathieu ONeil, Molly de Blanc, and Stefano Zacchiroli) have created this survey to capture the current state of participation in the Debian Project through the lense of common demographics. We hope a general survey will become an annual effort, and that each year there will also be a focus on a specific aspect of the project or community. The 2016 edition contains sections concerning work, employment, and labour issues in order to learn about who is getting paid to work on and with Debian, and how those relationships affect contributions.

We want to hear from as many Debian contributors as possible—whether you've submitted a bug report, attended a DebConf, reviewed translations, maintain packages, participated in Debian teams, or are a Debian Developer. Completing the survey should take 10-30 minutes, depending on your current involvement with the project and employment status.

In an effort to reflect our own ideals as well as those of the Debian project, we are using LimeSurvey, an entirely free software survey tool, in an instance of it hosted by the LimeSurvey developers.

Survey responses are anonymous, IP and HTTP information are not logged, and all questions are optional. As it is still likely possible to determine who a respondent is based on their answers, results will only be distributed in aggregate form, in a way that does not allow deanonymization. The results of the survey will be analyzed as part of ongoing research work by the organizers. A report discussing the results will be published under a DFSG-free license and distributed to the Debian community as soon as it's ready. The raw, disaggregated answers will not be distributed and will be kept under the responsibility of the organizers.

We hope you will fill out the Debian Contributor Survey. The deadline for participation is: 4 December 2016, at 23:59 UTC.

If you have any questions, don't hesitate to contact us via email at:

Categories: Elsewhere

OSTraining: Beginners Guide to Contributing to Drupal : Prerequisites

Planet Drupal - Wed, 16/11/2016 - 15:23

Welcome to the first part of our series on contributing to Drupal for beginners.

Categories: Elsewhere

Drupalize.Me: Drupal 8 is 1 Year Old

Planet Drupal - Wed, 16/11/2016 - 14:31

It’s hard to believe, but it has been 1 year since Drupal 8.0 was released to the world. We’re celebrating Drupal 8’s first birthday on November 19th by giving FREE access to our full [Drupal 8 Migration Guide](https://drupalize.me/series/drupal-8-migration-guide) over the celebration weekend! This Saturday, November 19th through Monday, November 21st you can learn how to use the new core migration system to upgrade your Drupal site or import content from external sources. It’s time to get using Drupal 8!

Categories: Elsewhere

Unimity Solutions Drupal Blog: Dwell in Drupal 8 - Launching Webinar Series to Celebrate Drupal 8's First Birthday

Planet Drupal - Wed, 16/11/2016 - 13:25

At Unimity, we are celebrating Drupal 8’s first birthday by launching a new webinar series “Dwell in Drupal 8”!!

Categories: Elsewhere

Valuebound: Why big government websites are switching over to Drupal

Planet Drupal - Wed, 16/11/2016 - 13:14

The open source Drupal CMS powers some of the biggest government websites. Now what do government websites and media & entertainment websites have in common? A lot of functionalities and end goals are similar. Media websites have subscription forms, personalized data delivery, large data warehouses, events and related forms, publishing tools, marketing tools, transactions etc.

The Georgia Technology Authority was running 65 state government websites on two different versions of proprietary software - Vignette 6 and Vignette 7, one of which is no longer supported. It had become cumbersome and expensive. Apart from that, moving all the 65 sites to Vignette 8 was too much of a hassle. CTO Steve Nichols says, “As we dug in, all the obvious best choices were open source,”. The…

Categories: Elsewhere

Russ Allbery: Review: The Philosopher Kings

Planet Debian - Wed, 16/11/2016 - 05:41

Review: The Philosopher Kings, by Jo Walton

Series: Thessaly #2 Publisher: Tor Copyright: June 2015 ISBN: 0-7653-3267-1 Format: Hardcover Pages: 345

Despite the cliffhanger at the end of The Just City, The Philosopher Kings doesn't pick up immediately afterwards. Argh. It's a great book (as I'm about to describe), but I really wanted to also read that book that happened in between. Still, this is the conclusion to the problem posed in The Just City, and I wouldn't recommend reading this book on its own (or, really, either book separate from the other).

Despite the unwanted gap, and another change at the very start of the book that I won't state explicitly since it's a spoiler but that made me quite unhappy (despite driving the rest of the plot), this is much closer to the book that I wanted to read. Walton moves away from the SF philosophical question that drove much of the second half of The Just City in favor of going back to arguments about human organization, the nature of justice, choices between different modes of life, and the nature of human relationships. Those were the best parts of The Just City, and they're elaborated here in some fascinating ways that wouldn't have been possible in the hothouse environment of the previous book.

I also thought Apollo was more interesting here than in the previous book. Still somewhat infuriating, particularly near the start, but I felt like I got more of what Walton was trying for, and more of what Apollo was attempting to use this existence to understand. And, once the plot hits its stride towards the center of the book, I started really liking Apollo. I guess it took a book and a half for him to mature enough to be interesting.

A new viewpoint character, Arete, gets most of the chapters in this book, rather than following the pattern of The Just City and changing viewpoint characters every chapter. Her identity is a spoiler for The Just City, so I'll leave that a mystery. She's a bit more matter-of-fact and observational than Maia, but she does that thing that I love in Walton's characters: take an unexpected, fantastic situation, analyze and experiment with it, and draw some practical and matter-of-fact conclusions about how to proceed.

I think that's the best way to describe this entire series: take a bunch of honest, thoughtful, and mostly good people, put them into a fantastic situation (at first Plato's Republic, a thought experiment made real, and then some additional fantasy complexities), and watch them tackle that situation like reasonable human beings. There is some drama, of course, because humans will disagree and will occasionally do awful, or just hurtful, things to each other. But the characters try to defuse the drama, try to be thoughtful and fair and just in their approach, and encourage change, improvement, and forgiveness in others. I don't like everyone in these books, but the vast majority of them are good people (and the few who aren't stand out), and there's something satisfying in reading about them. And the philosophical debate is wonderful throughout this book (which I'm not saying entirely because the characters have a similar reaction to a newly-introduced philosophical system as I did as a reader, although that certainly helps).

I'm not saying much about the plot since so much would spoil the previous book. But Walton adds some well-done complexities and complications, and while I was dubious about them at the start of the book, I definitely came around. I enjoyed watching the characters reinvent some typical human problems, but still come at them from a unique and thoughtful angle and come up with some novel solutions. And the ending took me entirely by surprise, in a very good way. It's better than the best ending I could have imagined for the book, providing some much-needed closure and quite a bit of explanation. (And, thankfully, does not end on another cliffhanger; in fact, I'm quite curious to see what the third book is going to tackle.)

Recommended, including the previous book, despite the bits that irritated me.

Followed by Necessity.

Rating: 9 out of 10

Categories: Elsewhere

Russ Allbery: Review: The Philosopher Kings

Planet Debian - Wed, 16/11/2016 - 05:41

Review: The Philosopher Kings, by Jo Walton

Series: Thessaly #2 Publisher: Tor Copyright: June 2015 ISBN: 0-7653-3267-1 Format: Hardcover Pages: 345

Despite the cliffhanger at the end of The Just City, The Philosopher Kings doesn't pick up immediately afterwards. Argh. It's a great book (as I'm about to describe), but I really wanted to also read that book that happened in between. Still, this is the conclusion to the problem posed in The Just City, and I wouldn't recommend reading this book on its own (or, really, either book separate from the other).

Despite the unwanted gap, and another change at the very start of the book that I won't state explicitly since it's a spoiler but that made me quite unhappy (despite driving the rest of the plot), this is much closer to the book that I wanted to read. Walton moves away from the SF philosophical question that drove much of the second half of The Just City in favor of going back to arguments about human organization, the nature of justice, choices between different modes of life, and the nature of human relationships. Those were the best parts of The Just City, and they're elaborated here in some fascinating ways that wouldn't have been possible in the hothouse environment of the previous book.

I also thought Apollo was more interesting here than in the previous book. Still somewhat infuriating, particularly near the start, but I felt like I got more of what Walton was trying for, and more of what Apollo was attempting to use this existence to understand. And, once the plot hits its stride towards the center of the book, I started really liking Apollo. I guess it took a book and a half for him to mature enough to be interesting.

A new viewpoint character, Arete, gets most of the chapters in this book, rather than following the pattern of The Just City and changing viewpoint characters every chapter. Her identity is a spoiler for The Just City, so I'll leave that a mystery. She's a bit more matter-of-fact and observational than Maia, but she does that thing that I love in Walton's characters: take an unexpected, fantastic situation, analyze and experiment with it, and draw some practical and matter-of-fact conclusions about how to proceed.

I think that's the best way to describe this entire series: take a bunch of honest, thoughtful, and mostly good people, put them into a fantastic situation (at first Plato's Republic, a thought experiment made real, and then some additional fantasy complexities), and watch them tackle that situation like reasonable human beings. There is some drama, of course, because humans will disagree and will occasionally do awful, or just hurtful, things to each other. But the characters try to defuse the drama, try to be thoughtful and fair and just in their approach, and encourage change, improvement, and forgiveness in others. I don't like everyone in these books, but the vast majority of them are good people (and the few who aren't stand out), and there's something satisfying in reading about them. And the philosophical debate is wonderful throughout this book (which I'm not saying entirely because the characters have a similar reaction to a newly-introduced philosophical system as I did as a reader, although that certainly helps).

I'm not saying much about the plot since so much would spoil the previous book. But Walton adds some well-done complexities and complications, and while I was dubious about them at the start of the book, I definitely came around. I enjoyed watching the characters reinvent some typical human problems, but still come at them from a unique and thoughtful angle and come up with some novel solutions. And the ending took me entirely by surprise, in a very good way. It's better than the best ending I could have imagined for the book, providing some much-needed closure and quite a bit of explanation. (And, thankfully, does not end on another cliffhanger; in fact, I'm quite curious to see what the third book is going to tackle.)

Recommended, including the previous book, despite the bits that irritated me.

Followed by Necessity.

Rating: 9 out of 10

Categories: Elsewhere

Drupal.org Featured Case Studies: YHA Groups

Planet Drupal - Tue, 15/11/2016 - 18:35
Completed Drupal site or project URL: https://groups.yha.org.uk

YHA (Youth Hostels Association) is a charity which has provided Hostel accommodation to people of all ages and backgrounds for over 85 years. The majority of YHA's business is split between two sites; YHA which allows families and individuals to book accommodation, and YHA Groups which is aimed at groups and schools who are looking to book accommodation for groups of 16 or more people.

This project covered YHA Groups, a brand new Drupal 8 design and build to replace the existing site.

Key modules/theme/distribution used: BootstrapIMCEColorboxDraggableViewsgeolocationImage Widget CropSlickAdmin ToolbarContact BlockContact StorageContact Storage ExportStage File ProxyShieldPathologicOrganizations involved: MicroserveTeam members: rickdonohoemangy.foxAshley Georgetim.cliffordmarkpavlitskiSophie.SK
Categories: Elsewhere

J-P Stacey: A quick rundown of what using Drupal 6-to-8's migration UI feels like

Planet Drupal - Tue, 15/11/2016 - 17:00

Recently, I was asked to migrate a fairly straightforward website from Drupal 6 to 8: a blog; some feature articles; some static pages; a fair amount of uploaded images. I thought it would be a great candidate for reviewing what the Migrate UI bundled with core looks like, since its introduction in Drupal 8.1.0.

Although the Migrate framework more generally permits arbitrarily complex migrations, many people's first port of call will be the UI, so I thought it would be interesting to chart a user journey through its use: highlighting what went well, what went badly, and (most importantly) what looked problematic but turned out to be straightforward.

Read more of "A quick rundown of what using Drupal 6-to-8's migration UI feels like "

Categories: Elsewhere

Web Wash: Using Display Suite in Drupal 8: How to Use Switch View Mode Sub-module

Planet Drupal - Tue, 15/11/2016 - 17:00
In this tutorial series on using Display Suite, we've cover the two fundamental use-cases of the module: how to modify layouts and use Display Suite fields. Now we'll take a closer look at one of its sub-modules: "Display Suite Switch View Mode". The "Display Suite Switch View Mode" module allows an editor to switch which view mode is used on a content page. By default, Drupal will use the "Full content" view mode (if enabled) on content page, i.e., "node/1". But what if you want to choose between two different "Full content" view modes? Well this module has you covered. So instead of being stuck with a single view mode, you could have one for a layout with a sidebar and another for pages with go full width. In this tutorial, you'll learn how to configure and use the"Display Suite Switch View Mode sub-module.
Categories: Elsewhere

Antoine Beaupré: The Turris Omnia router: help for the IoT mess?

Planet Debian - Tue, 15/11/2016 - 16:28

The Turris Omnia router is not the first FLOSS router out there, but it could well be one of the first open hardware routers to be available. As the crowdfunding campaign is coming to a close, it is worth reflecting on the place of the project in the ecosystem. Beyond that, I got my hardware recently, so I was able to give it a try.

A short introduction to the Omnia project

The Omnia router is a followup project on CZ.NIC's original research project, the Turris. The goal of the project was to identify hostile traffic on end-user networks and develop global responses to those attacks across every monitored device. The Omnia is an extension of the original project: more features were added and data collection is now opt-in. Whereas the original Turris was simply a home router, the new Omnia router includes:

  • 1.6GHz ARM CPU
  • 1-2GB RAM
  • 8GB flash storage
  • 6 Gbit Ethernet ports
  • SFP fiber port
  • 2 Mini-PCI express ports
  • mSATA port
  • 3 MIMO 802.11ac and 2 MIMO 802.11bgn radios and antennas
  • SIM card support for backup connectivity

Some models sold had a larger case to accommodate extra hard drives, turning the Omnia router into a NAS device that could actually serve as a multi-purpose home server. Indeed, it is one of the objectives of the project to make "more than just a router". The NAS model is not currently on sale anymore, but there are plans to bring it back along with LTE modem options and new accessories "to expand Omnia towards home automation".

Omnia runs a fork of the OpenWRT distribution called TurrisOS that has been customized to support automated live updates, a simpler web interface, and other extra features. The fork also has patches to the Linux kernel, which is based on Linux 4.4.13 (according to uname -a). It is unclear why those patches are necessary since the ARMv7 Armada 385 CPU has been supported in Linux since at least 4.2-rc1, but it is common for OpenWRT ports to ship patches to the kernel, either to backport missing functionality or perform some optimization.

There has been some pressure from backers to petition Turris to "speedup the process of upstreaming Omnia support to OpenWrt". It could be that the team is too busy with delivering the devices already ordered to complete that process at this point. The software is available on the CZ-NIC GitHub repository and the actual Linux patches can be found here and here. CZ.NIC also operates a private GitLab instance where more software is available. There is technically no reason why you wouldn't be able to run your own distribution on the Omnia router: OpenWRT development snapshots should be able to run on the Omnia hardware and some people have installed Debian on Omnia. It may require some customization (e.g. the kernel) to make sure the Omnia hardware is correctly supported. Most people seem to prefer to run TurrisOS because of the extra features.

The hardware itself is also free and open for the most part. There is a binary blob needed for the 5GHz wireless card, which seems to be the only proprietary component on the board. The schematics of the device are available through the Omnia wiki, but oddly not in the GitHub repository like the rest of the software.

Hands on

I received my own router last week, which is about six months late from the original April 2016 delivery date; it allowed me to do some hands-on testing of the device. The first thing I noticed was a known problem with the antenna connectors: I had to open up the case to screw the fittings tight, otherwise the antennas wouldn't screw in correctly.

Once that was done, I simply had to go through the usual process of setting up the router, which consisted of connecting the Omnia to my laptop with an Ethernet cable, connecting the Omnia to an uplink (I hooked it into my existing network), and go through a web wizard. I was pleasantly surprised with the interface: it was smooth and easy to use, but at the same time imposed good security practices on the user.

For example, the wizard, once connected to the network, goes through a full system upgrade and will, by default, automatically upgrade itself (including reboots) when new updates become available. Users have to opt-in to the automatic updates, and can chose to automate only the downloading and installation of the updates without having the device reboot on its own. Reboots are also performed during user-specified time frames (by default, Omnia applies kernel updates during the night). I also liked the "skip" button that allowed me to completely bypass the wizard and configure the device myself, through the regular OpenWRT systems (like LuCI or SSH) if I needed to.

Notwithstanding the antenna connectors themselves, the hardware is nice. I ordered the black metal case, and I must admit I love the many LED lights in the front. It is especially useful to have color changes in the reset procedure: no more guessing what state the device is in or if I pressed the reset button long enough. The LEDs can also be dimmed to reduce the glare that our electronic devices produce.

All this comes at a price, however: at \$250 USD, it is a much higher price tag than common home routers, which typically go for around \$50. Furthermore, it may be difficult to actually get the device, because no orders are being accepted on the Indiegogo site after October 31. The Turris team doesn't actually want to deal with retail sales and has now delegated retail sales to other stores, which are currently limited to European deliveries.

A nice device to help fight off the IoT apocalypse

It seems there isn't a week that goes by these days without a record-breaking distributed denial-of-service (DDoS) attack. Those attacks are more and more caused by home routers, webcams, and "Internet of Things" (IoT) devices. In that context, the Omnia sets a high bar for how devices should be built but also how they should be operated. Omnia routers are automatically upgraded on a nightly basis and, by default, do not provide telnet or SSH ports to run arbitrary code. There is the password-less wizard that starts up on install, but it forces the user to chose a password in order to complete the configuration.

Both the hardware and software of the Omnia are free and open. The automatic update's EULA explicitly states that the software provided by CZ.NIC "will be released under a free software licence" (and it has been, as mentioned earlier). This makes the machine much easier to audit by someone looking for possible flaws, say for example a customs official looking to approve the import in the eventual case where IoT devices end up being regulated. But it also makes the device itself more secure. One of the problems with these kinds of devices is "bit rot": they have known vulnerabilities that are not fixed in a timely manner, if at all. While it would be trivial for an attacker to disable the Omnia's auto-update mechanisms, the point is not to counterattack, but to prevent attacks on known vulnerabilities.

The CZ.NIC folks take it a step further and encourage users to actively participate in a monitoring effort to document such attacks. For example, the Omnia can run a honeypot to lure attackers into divulging their presence. The Omnia also runs an elaborate data collection program, where routers report malicious activity to a central server that collects information about traffic flows, blocked packets, bandwidth usage, and activity from a predefined list of malicious addresses. The exact data collected is specified in another EULA that is currently only available to users logged in at the Turris web site. That data can then be turned into tweaked firewall rules to protect the overall network, which the Turris project calls a distributed adaptive firewall. Users need to explicitly opt-in to the monitoring system by registering on a portal using their email address.

Turris devices also feature the Majordomo software (not to be confused with the venerable mailing list software) that can also monitor devices in your home and identify hostile traffic, potentially leading users to take responsibility over the actions of their own devices. This, in turn, could lead users to trickle complaints back up to the manufacturers that could change their behavior. It turns out that some companies do care about their reputations and will issue recalls if their devices have significant enough issues.

It remains to be seen how effective the latter approach will be, however. In the meantime, the Omnia seems to be an excellent all-around server and router for even the most demanding home or small-office environments that is a great example for future competitors.

Note: this article first appeared in the Linux Weekly News.

Categories: Elsewhere

Antoine Beaupré: The Turris Omnia router: help for the IoT mess?

Planet Debian - Tue, 15/11/2016 - 16:28

The Turris Omnia router is not the first FLOSS router out there, but it could well be one of the first open hardware routers to be available. As the crowdfunding campaign is coming to a close, it is worth reflecting on the place of the project in the ecosystem. Beyond that, I got my hardware recently, so I was able to give it a try.

A short introduction to the Omnia project

The Omnia router is a followup project on CZ.NIC's original research project, the Turris. The goal of the project was to identify hostile traffic on end-user networks and develop global responses to those attacks across every monitored device. The Omnia is an extension of the original project: more features were added and data collection is now opt-in. Whereas the original Turris was simply a home router, the new Omnia router includes:

  • 1.6GHz ARM CPU
  • 1-2GB RAM
  • 8GB flash storage
  • 6 Gbit Ethernet ports
  • SFP fiber port
  • 2 Mini-PCI express ports
  • mSATA port
  • 3 MIMO 802.11ac and 2 MIMO 802.11bgn radios and antennas
  • SIM card support for backup connectivity

Some models sold had a larger case to accommodate extra hard drives, turning the Omnia router into a NAS device that could actually serve as a multi-purpose home server. Indeed, it is one of the objectives of the project to make "more than just a router". The NAS model is not currently on sale anymore, but there are plans to bring it back along with LTE modem options and new accessories "to expand Omnia towards home automation".

Omnia runs a fork of the OpenWRT distribution called TurrisOS that has been customized to support automated live updates, a simpler web interface, and other extra features. The fork also has patches to the Linux kernel, which is based on Linux 4.4.13 (according to uname -a). It is unclear why those patches are necessary since the ARMv7 Armada 385 CPU has been supported in Linux since at least 4.2-rc1, but it is common for OpenWRT ports to ship patches to the kernel, either to backport missing functionality or perform some optimization.

There has been some pressure from backers to petition Turris to "speedup the process of upstreaming Omnia support to OpenWrt". It could be that the team is too busy with delivering the devices already ordered to complete that process at this point. The software is available on the CZ-NIC GitHub repository and the actual Linux patches can be found here and here. CZ.NIC also operates a private GitLab instance where more software is available. There is technically no reason why you wouldn't be able to run your own distribution on the Omnia router: OpenWRT development snapshots should be able to run on the Omnia hardware and some people have installed Debian on Omnia. It may require some customization (e.g. the kernel) to make sure the Omnia hardware is correctly supported. Most people seem to prefer to run TurrisOS because of the extra features.

The hardware itself is also free and open for the most part. There is a binary blob needed for the 5GHz wireless card, which seems to be the only proprietary component on the board. The schematics of the device are available through the Omnia wiki, but oddly not in the GitHub repository like the rest of the software.

Hands on

I received my own router last week, which is about six months late from the original April 2016 delivery date; it allowed me to do some hands-on testing of the device. The first thing I noticed was a known problem with the antenna connectors: I had to open up the case to screw the fittings tight, otherwise the antennas wouldn't screw in correctly.

Once that was done, I simply had to go through the usual process of setting up the router, which consisted of connecting the Omnia to my laptop with an Ethernet cable, connecting the Omnia to an uplink (I hooked it into my existing network), and go through a web wizard. I was pleasantly surprised with the interface: it was smooth and easy to use, but at the same time imposed good security practices on the user.

For example, the wizard, once connected to the network, goes through a full system upgrade and will, by default, automatically upgrade itself (including reboots) when new updates become available. Users have to opt-in to the automatic updates, and can chose to automate only the downloading and installation of the updates without having the device reboot on its own. Reboots are also performed during user-specified time frames (by default, Omnia applies kernel updates during the night). I also liked the "skip" button that allowed me to completely bypass the wizard and configure the device myself, through the regular OpenWRT systems (like LuCI or SSH) if I needed to.

Notwithstanding the antenna connectors themselves, the hardware is nice. I ordered the black metal case, and I must admit I love the many LED lights in the front. It is especially useful to have color changes in the reset procedure: no more guessing what state the device is in or if I pressed the reset button long enough. The LEDs can also be dimmed to reduce the glare that our electronic devices produce.

All this comes at a price, however: at \$250 USD, it is a much higher price tag than common home routers, which typically go for around \$50. Furthermore, it may be difficult to actually get the device, because no orders are being accepted on the Indiegogo site after October 31. The Turris team doesn't actually want to deal with retail sales and has now delegated retail sales to other stores, which are currently limited to European deliveries.

A nice device to help fight off the IoT apocalypse

It seems there isn't a week that goes by these days without a record-breaking distributed denial-of-service (DDoS) attack. Those attacks are more and more caused by home routers, webcams, and "Internet of Things" (IoT) devices. In that context, the Omnia sets a high bar for how devices should be built but also how they should be operated. Omnia routers are automatically upgraded on a nightly basis and, by default, do not provide telnet or SSH ports to run arbitrary code. There is the password-less wizard that starts up on install, but it forces the user to chose a password in order to complete the configuration.

Both the hardware and software of the Omnia are free and open. The automatic update's EULA explicitly states that the software provided by CZ.NIC "will be released under a free software licence" (and it has been, as mentioned earlier). This makes the machine much easier to audit by someone looking for possible flaws, say for example a customs official looking to approve the import in the eventual case where IoT devices end up being regulated. But it also makes the device itself more secure. One of the problems with these kinds of devices is "bit rot": they have known vulnerabilities that are not fixed in a timely manner, if at all. While it would be trivial for an attacker to disable the Omnia's auto-update mechanisms, the point is not to counterattack, but to prevent attacks on known vulnerabilities.

The CZ.NIC folks take it a step further and encourage users to actively participate in a monitoring effort to document such attacks. For example, the Omnia can run a honeypot to lure attackers into divulging their presence. The Omnia also runs an elaborate data collection program, where routers report malicious activity to a central server that collects information about traffic flows, blocked packets, bandwidth usage, and activity from a predefined list of malicious addresses. The exact data collected is specified in another EULA that is currently only available to users logged in at the Turris web site. That data can then be turned into tweaked firewall rules to protect the overall network, which the Turris project calls a distributed adaptive firewall. Users need to explicitly opt-in to the monitoring system by registering on a portal using their email address.

Turris devices also feature the Majordomo software (not to be confused with the venerable mailing list software) that can also monitor devices in your home and identify hostile traffic, potentially leading users to take responsibility over the actions of their own devices. This, in turn, could lead users to trickle complaints back up to the manufacturers that could change their behavior. It turns out that some companies do care about their reputations and will issue recalls if their devices have significant enough issues.

It remains to be seen how effective the latter approach will be, however. In the meantime, the Omnia seems to be an excellent all-around server and router for even the most demanding home or small-office environments that is a great example for future competitors.

Note: this article first appeared in the Linux Weekly News.

Categories: Elsewhere

Zivtech: Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks

Planet Drupal - Tue, 15/11/2016 - 16:09

This post is the second in a series covering Zivtech's usage of Gulp for front-end development in Drupal 8.

In the last post, I covered how to setup Gulp for teamwork on Drupal 8 projects. In this post, I'll go over how to get started with writing Gulp tasks. I'll also break down a specific task for Sass linting to ensure good code quality.

Maintainable and Readable Gulp tasks

With any mid-to-large sized Drupal 8 theme, it's really easy for the main Gulp file (gulpfile.js) become unwieldy and complex. With dozens of tasks doing all kinds of automated work, before too long, gulpfile.js becomes a soup of illegible code.

Additionally, members of your team might have different ways of naming Gulp tasks. One person might write a Sass building task called "buildSass" and another might create an identical task called "css."

It'd be nice to strip down gulpfile.js, make it readable, and somehow compartmentalize each task separately. Also, we want to cut down on task naming variations and create a unified system for structuring our tasks.

My current favorite way to handle these wishes is gulp-require-tasks. Basically, each task is written as an individual, CommonJS style module. Then, the tasks are arranged in directories, and that directory structure defines the task name. It is a very simple and predictable way to setup Gulp tasks.

Structuring Gulp tasks

Start off by creating the file tree structure below:

├── project/ │ ├── .gitignore (ignore node_modules, gulpfile.yml) │ ├── package.json │ ├── gulpfile.js │ ├── default.gulpfile.yml │ ├── sass │ │ ├── styles.scss │ ├── js │ │ ├── scripts.js │ ├── gulp-tasks │ │ ├── styles │ │ │ ├── lint.js │ │ │ ├── build.js │ │ ├── scripts │ │ │ ├── lint.js │ │ │ ├── build.js

The YAML settings file, default.gulpfile.yml, was discussed in the last post of this series, if you need a refresher.

gulp-require-tasks lets these tasks be accessible according to their structure. For example, to build the styles, you'll run "gulp styles:build" and to lint the JavaScript, you'll run "gulp scripts:lint." If you don't like the colon delimiter, you can change that too.

Update Gulp settings

In the last post we started the default.gulpfile.yml, and now we'll edit that same file to add in settings for the Gulp tasks we'll create in this project.

Open the file: it should look like this:

themeName: "myTheme" themeDescription: "myTheme description"

Expand on that by adding settings for source and destination paths of Sass and JS:

themeName: "myTheme" themeDescription: "myTheme description" styles: src: "sass//*.scss", dest: "css" lint: enabled: true failOnError: false scripts: src: "js//*.js", lint: enabled: true failOnError: false

Under the "styles" and "scripts" sections of the YAML, you can see I added some linting options too. From within the YAML settings, people can enable or disable linting, and also decide if they want the Gulp process to stop when linting errors are detected.

Pulling these settings out of the Gulp tasks themselves and into this YAML file means that developers don't have to search through the tasks looking for settings to change. Instead, they have every setting exposed to them in this one, concise file.

Importing tasks for Gulp

We haven't written any Gulp tasks yet, but we can go ahead and setup importing them so they can be used.

Open up the gulpfile.js we started in the last post. It should look like this:

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } })();

If you recall, we loaded the default.gulpfile.yml and overrode that with any settings from gulpfile.yml if it exists. The gulpfile.yml file has the exact same structure has default.gulpfile.yml, but settings can have different values. This lets other developers on the team override some settings if needed.

At this point in gulpfile.js, the config is loaded and ready to be used. Next, we integrate gulp-require-tasks.

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); var gulpRequireTasks = require('gulp-require-tasks'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } gulpRequireTasks({ path: process.cwd() + '/gulp-tasks', arguments: [config] }); })();

Setting up gulp-require-tasks is super easy. We tell it where our gulp tasks are located, in the "gulp-tasks" directory.

Then, to each module (i.e. 1 module will be 1 Gulp task) in the directory, gulp-require-tasks passes arguments to each task. The first argument is always gulp itself. The "arguments" setting for gulp-require-tasks is an array of other things you want to pass to each module. I've opted to pass in "config," which is the object representing the settings merge in the YAML files.

This is essentially all you need in gulpfile.yml. However, I also like to add shortcut tasks too, that combine other tasks for quicker use. For example, general "build" and "lint" tasks might be like this:

gulp.task('build', ['styles:build', 'scripts:build']); gulp.task('lint', ['styles:lint', 'scripts:lint']);

Modular Gulp tasks

Let's start off creating the Sass linting task. To help with this, I recommend using gulp-sass-lint. You'll want to read over how to setup sass-lint, which I won't cover in detail here. Essentially, you create a .sass-lint.yml file in the root of the project. That file contains all the rules you want to validate; for example, should developers avoid styling with IDs or should they use RGB rather than HEX values for colors.

After sass-lint rules are in place, open up the styles linting file. Here you'll see the guts of the linting task:

'use strict'; var cached = require('gulp-cached'); var sassLint = require('gulp-sass-lint'); var gulpif = require('gulp-if'); module.exports = function (gulp, options) { if (options.styles.lint.enabled) { return gulp.src(options.styles.src) .pipe(cached('styles:lint')) .pipe(sassLint()) .pipe(sassLint.format()) .pipe(gulpif(options.styles.lint.failOnError, sassLint.failOnError())); } else { return console.log('css linting not enabled'); } };

For the three required packages, you'll want to "npm install" them of course. Don't forget the "--save-dev" flag to get those packages stored in package.json!

The bulk of the code exists within the standard, CommonJS "module.exports" directive. A Gulp process is passed into the task as well as the set of options from default.gulpfile.yml.

We start off by running a quick if/else check so that we short-circuit out of this task if the user disabled Sass linting. Then, we pipe in the files that we selected in the Gulp settings' "styles.src" section. Files are then piped through gulp-cached, which keeps a list of the source files (and contents!) in memory. This makes the task faster.

Next, the styles are linted and the results are formatted and reported out to the console. Finally, we use gulp-if to determine if the Gulp process gets terminated now should there be linting errors.

The sky's the limit

I leave it as an exercise for the reader to go about developing the other Gulp tasks. In the next post, I'll go over some other, more complicated Gulp tasks to show more advanced usage. Until then, you're more than welcome to look over and reference our own Gulp tasks we publish for Bear Skin.

Posts in this series

  1. Use Gulp for Drupal 8 with Teams, Part 1: Gulp Setup
  2. Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks
Categories: Elsewhere

Enrico Zini: Software quality in 2016

Planet Debian - Tue, 15/11/2016 - 13:01

Ansible's default output, including the stderr of failed commands, is JSON encoded, which makes reading Jenkins' output hard.

Ansible however has Callback plugins that could be used. In that page it says:

Ansible comes with a number of callback plugins that you can look at for examples. These can be found in lib/ansible/plugins/callback.

That is a link to a git repo with just a pile of Python sources and no, say README.md index to what they do. Hopefully they have some docstring with a short description of what they do? no.

Actually, some do, but just because someone copypasted the default one and didn't even bother removing its docstring.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere