I joined Canonical as COO in 2004, excited by the vision of Ubuntu and the possibilities that could unfold from the software, the collaboration with the open source community, the energy of an international, distributed start-up and the impact it could have on the world. When Mark asked me to become CEO in 2010, I added the challenge of driving commercial success to that list. The intervening years, and the adjective/animal pairs, have flown by and I’m still excited by Canonical and those very same things.

We’re now entering a new phase of accelerated growth at Canonical, and it’s time to pass the baton to both seasoned hands and a new generation of Canonical leaders. This is not a sudden decision. I originally agreed to be CEO for 5 years and we’ve extended my tenure as CEO by a couple of years already. We’ve been preparing for a transition for some time by strengthening the executive leadership team and maturing every aspect of the company, and earlier this year Mark and I decided that now is the time to effect this transition. Over the next three months I will remain CEO but begin to formally transfer knowledge and responsibility to others in the executive team. In July, Mark will retake the CEO role and I will move to the Canonical Board of Directors. In terms of a full-time role, I will take some time to recharge and then seek new challenges.

I had hoped to avoid trotting out the standard departure cliches of gratitude and family, but I am grateful and I can’t think of a better way to describe the folks at Canonical and in the Ubuntu community. To all of you: I have never worked with such an incredible collection of intelligent, passionate and capable people. The warmth you have shown me and the trust you have placed in me, not just in response to this announcement but over the years, has impacted me in ways that I cannot describe. I am proud of what we’ve accomplished together, honoured to have been a part of it, and I have learnt so much along the way. I am already nostalgic for the feeling of Ubuntu I have become accustomed to here, in both the Canonical and canonical sense of the word. And yet it’s only my vantage point that will be different: I look forward to many more years with Ubuntu from my new positions in both the Canonical Board and the Ubuntu community.

We are proud to release the latest Canonical Distribution of Kubernetes (CDK) supporting Kubernetes version 1.6.1! Kubernetes 1.6 is a major milestone and it is recommended that you read the upstream release notes for new features and changes.

GA Features

Canonical’s Distribution of Kubernetes, CDK, offers a production grade method for installing, configuring, and managing Kubernetes lifecycle operations. With this release, CDK has the following GA features.

TLS encryption

Out of the box, CDK will deploy EasyRSA for private key infrastructure (PKI). This will be used to encrypt all traffic in the cluster:

• kubernetes-master to etcd
• kubernetes-master to kubelet
• kubectl to kubernetes-master

Highly Available

CDK produces a robust and highly available cluster, multiple etcd units, masters, and workers all spread across availability zones to distill cloud best practices in your deployments on every cloud.

Deployable, everywhere

By leveraging tools like conjure-up, CDK can be deployed across any number of clouds. From Amazon, Google Cloud, Azure, Rackspace – to OpenStack, VMWare, bare metal, or your local computer. CDK offers a consistent Kubernetes experience across all these clouds and more!

Operations baked in

In this distribution, common operational tasks from upgrading, maintenance of nodes, backups, restorations, and more are included. This gives operators the tools they need to operate a Kubernetes cluster and an extensible way to add new actions should they need them.

Extensible

This distribution produces an opinionated starting point for your production Kubernetes cluster, however it’s designed to be something you mold into your Kubernetes. Whether that’s changing scale, placement of components, or architecture itself, CDK lets you make these modifications and more without getting stuck with a one-off deployment.

When it comes to scale, you get your choice in how large or small you want to start a cluster. You can change this anytime during a deploying adding more workers, different worker pools, or removing worker pools all together.

In addition to scale, you’ll also get the choice in exactly where and how a Kubernetes component is placed. This means you can start with just one machine and everything in it, a mixture of etcd on master, or any other architecture that suits your needs.

Finally, CDK allows you to choose which components to install. Out of the box you get etcd, Kubernetes, EasyRSA, and Flannel. However, if you want a different SDN for example, Calico, and you want to integrate Kubernetes to your existing Datadog dashboard or Nagios installation; you can manipulate the architecture to make a repeatable Kubernetes for your use cases.

Beta Features

In addition to the above GA features, the following beta features are available as of this release which we encourage everyone to try out!

GPU Support

With 1.6 release of Kubernetes, GPU/CUDA support has grown quite a bit. In celebration of that effort in upstream we’ve enabled GPU support for all kubernetes nodes which have CUDA cores. See the below examples on how to leverage, test, and use this new feature in Kubernetes.

Getting Started

Here’s the simplest way to get a Kubernetes cluster up and running on an Ubuntu 16.04 system:

sudo snap install conjure-up --classic
conjure-up kubernetes

During the installation conjure-up will ask you what cloud you want to deploy on and prompt you for the proper credentials. If you’re deploying to local containers (LXD) see these instructions for localhost-specific considerations.

For production grade deployments and cluster lifecycle management it is recommended to read the full Canonical Distribution of Kubernetes documentation.

Source code: https://github.com/kubernetes/kubernetes/tree/master/cluster/juju

Upgrading an existing cluster

The best way to get the latest Kubernetes code is to deploy a new cluster of CDK, or Kubernetes Core. If you wish to upgrade an existing deployment there are a few steps to upgrade the components on your cluster.

Upgrading etcd

Note: This step is mandatory and should be performed only when upgrading an existing cluster to the latest version.

Upgrading etcd from the previous stable (revision 24) to the current stable (revision 25) will trigger a status message indicating it requires operator intervention to continue. This migration process will incur a small period of down-time as etcd is migrated from version 2.x to 3.1. Please plan for this event properly and ensure you have taken a snapshot of the etcd data prior to running the upgrade so you may recover in the event of unforeseen issues.

Once you have captured the state of your etcd data, you may proceed with the upgrade process. The upgrade will need to be performed once per unit participating in the cluster. To upgrade the etcd charm use the juju upgrade-charm command:

juju upgrade-charm etcd

This command initiates an update of the code that operates the etcd application.  Wait until the software upgrade is complete before migrating the etcd data (a manual step). You will need to upgrade each etcd unit in your cluster. Presuming you have a 3 unit etcd cluster, the commands would be as follows:

juju run-action etcd/0 snap-upgrade
juju run-action etcd/1 snap-upgrade
juju run-action etcd/2 snap-upgrade

Once complete, the status messaging will return to the cluster health output. Future delivery of etcd will be performed via snaps and the version is configurable in the charm config.

Upgrading other cluster components

We have documented the upgrade scenarios in the Kubernetes documentation. If your cluster is running pods you should upgrade with a Blue/Green strategy outlined in the Upgrade documentation.
If you have made changes to the deployment bundle, such as adding additional worker nodes as a different label, you will need to manually upgrade the components. The following command list assumes you have made no changes to the component names, and assumes you’ve upgraded etcd as outlined above.

# Upgrade charms
juju upgrade-charm kubernetes-master
juju upgrade-charm kubernetes-worker
juju upgrade-charm flannel
juju upgrade-charm easyrsa
juju upgrade-charm kubeapi-load-balancer

# Add new relation
juju relate kubernetes-worker:kube-control kubernetes-master:kube-control

# Remove deprecated relation
juju remove-relation kubernetes-worker:kube-dns kubernetes-master:cluster-dns

This will upgrade the operations code and  the Kubernetes version 1.6.1.

Changes in this release

• Support for Kubernetes v1.6, with the current release being 1.6.1
• Installation of components via snaps: kubectl, kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. To learn more about snaps, check out the Snapcraft website.
• Added allow-privileged config option on kubernetes-master and kubernetes-worker charms. Valid values are true|false|auto (default: auto). If the value is auto, containers will run in unprivileged mode unless GPU hardware is detected on a worker node. Otherwise Kubernetes will be run with --allow-privileged=true.
• Added GPU support (beta). If Nvidia GPU hardware is detected on a worker node, Nvidia drivers and CUDA packages will be installed, and kubelet will be restarted with the flags required to use the GPU hardware. The allow-privileged config option must be true or auto.
  • Nvidia driver version = 375.26; CUDA version = 8.0.61; these will be configurable future charm releases.
  • GPU support does not currently work on lxd.
  • This feature is beta – feedback on the implementation is welcomed.
• Added support for running your own private registry, setup guidelines here.

General Fixes:

• kubeapi-load-balancer not properly forwarding SPDY/HTTP2 traffic for kubectl exec commands.

Etcd specific changes:

• Installation of etcd and etcdctl is now delivered with snaps.
• Support for upgrading the previous etcd charm, to the latest charm with snap delivery.  See manual upgrade process for updating existing etcd clusters.

Changes to the bundles and layers:

• Add registry action to the kubernetes-worker layer, which deploys a Docker registry in Kubernetes.
• Add support for kube-proxy cluster-cidr option.

GPU Example

With a kubernetes bundle deployed on AWS, add a GPU-enabled worker to an existing deployment:

# Add a new worker on gpu hardware
juju deploy cs:~containers/kubernetes-worker kubernetes-worker-gpu --constraints "instance-type=p2.xlarge"

# Relate the new worker to other components
juju relate kubernetes-worker-gpu:kube-control kubernetes-master:kube-control
juju relate kubernetes-worker-gpu:certificates easyrsa:client
juju relate kubernetes-worker-gpu:cni flannel:cni
juju relate kubernetes-worker-gpu kubeapi-load-balancer

# ...wait for workload status to become active in `juju status`

# Download a gpu-dependent job spec
wget -O /tmp/nvidia-smi.yaml https://raw.githubusercontent.com/madeden/blogposts/master/k8s-gpu-cloud/src/nvidia-smi.yaml

# Create the job
kubectl create -f /tmp/nvidia-smi.yaml

# You should see a new nvidia-smi-xxxxx pod created
kubectl get pods

# Wait a bit for the job to run, then view logs; you should see the
# nvidia-smi table output

kubectl logs $(kubectl get pods -l name=nvidia-smi -o=name -a)

Test results

The Canonical Distribution of Kubernetes is running daily tests to verify it works with the upstream code. As part of the Kubernetes test infrastructure we upload daily test runs. The test results are available on the Gubernator dashboard.

How to contact us

We’re normally found in the Kubernetes Slack channels and attend these Special Interest Group (SIG) meetings regularly:

– sig-cluster-lifecycle
– sig-cluster-ops
– sig-onprem

Operators are an important part of Kubernetes, we encourage you to participate with other members of the Kubernetes community!

We also monitor the Kubernetes mailing lists and other community channels, feel free to reach out to us. As always, PRs, recommendations, and bug reports are welcome: https://github.com/juju-solutions/bundle-canonical-kubernetes!

This is a guest post by Kyle Fazzari, Software Engineer. If you would like to contribute a guest post, please contact ubuntu-devices@canonical.com

This is the second blog post in this series about ROS production. In the previous post we discussed why Ubuntu Core was a good fit for production robotics. In this post we’ll be on classic Ubuntu, creating the example ROS prototype that we’ll use throughout the rest of the series as we work toward using Ubuntu Core.

I mentioned in the previous post that this series was going to use the Turtlebot 2. However, there are a number of possible configurations for the Turtlebot. Some use a Kinect, others use an Astra Pro, still others use a RealSense, etc. I want this prototype to be runnable by everyone who has a Turtlebot 2, so I’m going to cater to the lowest common denominator here: the Kobuki base. We’ll keep it very simple and make it randomly wander around, bumping into things and correcting itself, utilizing both the bumper sensors as well as the cliff sensors.

I also mentioned how the ROS community has standardized around the Turtlebot as the introductory platform. That makes this prototype incredibly easy to create, as every package we need has already been written: we just need to put them together. Let’s get started! Remember that this is also a video series: feel free to watch the video version of this post.

Prerequisites

This post will assume the following:

• You’re running on Ubuntu 16.04 (Xenial)
• You have ROS Kinetic installed (I installed ros-kinetic-ros-base)
• You have gone through at least the first 8 ROS tutorials (e.g. you should know what a launch file is)

The computer being used doesn’t matter so much as this prototype should work on any standard architecture, but for your reference I’m using an Intel NUC (the DE3815TYKE, specifically).

The prototype

Step 1: Install the Kobuki driver

The first Turtlebot-specific package we’ll need is the ROS wrapper for the Kobuki driver. It contains the node that’s responsible for communicating with the Kobuki itself, receiving sensor data and publishing it on ROS, etc.

$ sudo apt install ros-kinetic-kobuki-node

Step 2: Configure udev rule

By default, the driver will look for the Turtlebot at /dev/kobuki. Getting the Kobuki there takes a udev rule. Thankfully, what we just installed includes a utility for installing this udev rule:

$ rosrun kobuki_ftdi create_udev_rules

It may prompt for your sudo password. After this completes successfully, connect your Turtlebot, turn it on, and you should see the /dev/kobuki symlink show up.

Step 3: Test the Kobuki driver

We can prove that this is working by running the driver’s minimal launch file:

$ roslaunch kobuki_node minimal.launch

After the system comes up, you should hear the Turtlebot sing a little tune. If that doesn’t happen, check to make sure that the udev rule is working. If it does happen, leave it running and continue.

Step 4: Install the Kobuki Random Walker

The Kobuki driver is most of what we need. Its minimal launch file brings up enough nodes to obtain data from the wheel drop sensors, cliff sensors, etc., but most importantly exposes the ability to command the robot to move. We just need to make use of it. We want it to randomly walk around, so we’ll use the Kobuki Random Walker (note that this may already be installed):

$ sudo apt install ros-kinetic-kobuki-random-walker

Step 5: Test the Kobuki Random Walker

To run it (the minimal.launch file from kobuki_node still needs to be running):

$ roslaunch kobuki_random_walker safe_random_walker_app.launch

When that system finishes launching, the robot will begin randomly wandering around. If it collides with something using its bumper sensors, it’ll back up and rotate, trying to get around it. If it notices it’s about to drive off a cliff (e.g. your steps) it’ll stop and rotate again.

Go ahead and stop (ctrl+c) both launch files.

Step 6: Put the pieces together

At this point, if you have the appropriate 3d sensors, you could start doing the really fun stuff with the navigation stack, but as I mentioned before, we’re going to keep it simple here. These two launch files make up the entirety of the prototype we’ll use for this series. However, if we leave it as-is it has a small limitation: the only udev symlink location supported is /dev/kobuki. That works on our current system, but what if another user has it elsewhere? Or what if we couldn’t use that exact symlink in a snap (a hint for the next post in this series)? So let’s distill those two launch files into a single launch file that represents our prototype, and make it a little more configurable.

First of all, create a new ROS workspace for this prototype (you can of course put this anywhere):

$ mkdir -p ~/workspace/src
$ cd ~/workspace/src
$ catkin_init_workspace

Now create a new package within that workspace to contain our prototype’s launch file. It should depend upon the two packages we know we need (kobuki_node and kobuki_random_walker):

$ cd ~/workspace/src
$ catkin_create_pkg prototype kobuki_node kobuki_random_walker

Now we’re going to create our launch file:

$ cd ~/workspace/src/prototype
$ mkdir launch
$ touch launch/prototype.launch

Open that launch/prototype.launch file in your favorite editor. In your terminal, open up the minimal.launch file from the Kobuki driver:

$ rosed kobuki_node minimal.launch

We’ll copy the contents of that launch file into ours, clean it up into only the bits we need, and add an argument that makes the serial port configurable. Finally, we’re also going to include the random walker launch file so that launching this single launch file brings up our entire prototype:

<launch>
<Make the device port configurable.>
<!– Nodelet manager for the Kobuki driver as well as the safe walker. –>
<node pkg=”nodelet” type=”nodelet”name=”mobile_base_nodelet_manager” args=”manager”/>
<!– The ROS wrapper for the Kobuki driver. –>
<node pkg=”nodelet” type=”nodelet” name=”mobile_base”args=”load kobuki_node/KobukiNodelet mobile_base_nodelet_manager”>
<rosparam file=”$(find kobuki_node)/param/base.yaml” command=”load”/>
<param name=”device_port” value=”$(arg device_port)”/>
<remap from=”mobile_base/odom” to=”odom”/>
<remap from=”mobile_base/joint_states” to=”joint_states”/>
</node>
<!– The safe random walker launch file that causes the robot to wander while trying not to destroy itself by utilizing the bumper sensors as well as the cliff sensors. –>
<include file=”$(findkobuki_random_walker)/launch/safe_random_walker_app.launch” />
</launch>

Save and exit. We also need to modify ~/workspace/src/prototype/CMakeLists.txt to actually install that launch file:

cmake_minimum_required(VERSION 2.8.3)
project(prototype)

find_package(catkin REQUIRED)

catkin_package()

install(DIRECTORY launch
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)

Save and exit. Note that the entire ROS project used here is available for reference. Finally, build the workspace:
$ cd ~/workspace
$ catkin_make

Now test out our final prototype:
$ source ~/workspace/devel/setup.sh
$ roslaunch prototype prototype.launch

And the robot should sing its little tune and immediately begin moving randomly again. So now we have our prototype contained in a single launch file, and we can use a different serial port like so:

$ roslaunch prototype prototype.launch device_port:=/dev/my-serial-port

In the next post in this series, we’ll discuss the process of packaging this prototype as a snap.

Original source here.

We discuss soldering the zerostem, review the new Dell XPS 13, share some command line love and go over your feedback.

This show was recorded prior to Mark Shuttleworth’s announcement about Growing Ubuntu for Cloud and IoT, rather than Phone and convergence. We’ll be discussing that news in a future episode of the Ubuntu Podcast.

It’s Season Ten Episode Six of the Ubuntu Podcast! Alan Pope, Mark Johnson, Martin Wimpress and Stuart Langridge are connected and speaking to your brain.

In this week’s show:

• We discuss Alan soldering the, quite brilliant, zerostem.

• We review the latest Dell XPS 13 (9360).

  • Alan wrote up some notes on his blog
  • You can also attempt to win one by entering the Bad Voltage 2017 Dell Sputnik fruit competition.
• We share a Command Line Lurve:
  • phoronix-test-suite– The Phoronix Test Suite is a comprehensive testing and benchmarking platform.
• And we go over all your amazing feedback – thanks for sending it – please keep sending it!

• This weeks cover image is taken from Wikimedia.

That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

• Join us in the Ubuntu Podcast Chatter group on Telegram

Ubuntu 17.04 released today, supporting Kubernetes, Docker, LXD and Snaps. This is the 26th release of Ubuntu, the world’s most widely deployed Linux OS and the leading platform for cloud and IoT operations.

“The breadth and pace of open source innovation has made it the center of gravity in technology today, and the Ubuntu community has once again delivered the most reliable way to consume that innovation” said Mark Shuttleworth, Founder of Canonical and Ubuntu. “While containers are the name of the game in cloud today, I would also highlight the speed at which snaps are enabling developers to deliver the very best bits to Linux machines on Ubuntu and other distributions, from the desktop to the cloud and beyond, at the edge of computing.”

Containerisation of applications and operations
Ubuntu offers the most complete portfolio of container support in a Linux distribution, with snaps for singleton apps, LXD by Canonical for lightweight VM-style machine containers,  and auto-updating Docker snap packages available in stable, candidate, beta and edge channels. The Canonical Distribution of Kubernetes 1.6, representing the very latest upstream container infrastructure, has 100% compatibility with Google’s hosted Kubernetes service GKE.

Snaps are now supported across 10 Linux distributions. More than 1,000 snaps have been published since the release of Ubuntu 16.04 LTS across a range of Linux devices and sectors such as IoT (eg Blue Horizon, openHAB), networking (eg Quagga, Free Range Routing, SONIC, Keepalived), desktop (KDE, web, libreoffice and GNOME apps), and cloud / server (for example Kubernetes, etcd, Rocket.Chat). GNOME Software supports snap installation directly from a link on a web page and Canonical is working with both KDE and GNOME to ensure smooth integration of snaps in those desktop environments.

LXD version 2.12, has gained support for GPUs in container machines, including NVidia CUDA support, making for very high performance GPGPU computing at scale. The new storage API for LXD enables the creation of multiple storage pools and attachment of volumes from those pools to LXD machine containers. LXD provides almost instant launching of container guests of a wide range of Linux distributions.

The Canonical Distribution of Kubernetes (CDK) is the easiest way to deploy and operate K8s across Google, Azure, Amazon, Vmware, OpenStack and bare metal infrastructure, using a single command: ‘conjure-up kubernetes’. The product is now based on Kubernetes 1.6 with a commitment to ongoing updates matching the upstream release schedule. CDK 1.6 brings federation of multiple Kubernetes clusters, increased number of Kubernetes workers, improvements to authentication and access control, and native GPU support.

OpenStack
Ubuntu 17.04 includes OpenStack’s latest Ocata release, which is also available on Ubuntu 16.04 LTS via Canonical’s public Cloud Archive.

Canonical’s OpenStack offering supports upgrades of running clouds without workload interruption. The introduction of Cells v2 in this release ensures that new clouds have a consistent way to scale from small to very large as capacity requirements change. Canonical’s BootStack service is a full OpenStack build, operate and transfer capability, with the option for Canonical to provide long-term operations services for a fixed price per server or per VM.

Ubuntu 17.04 also includes Manila, OpenStack’s shared file system capability, and improvements for LDAP integration. Beta snaps for OpenStack Nova, Cinder, Glance, Keystone and Neutron are also available giving users an exciting new way to deploy OpenStack control plane services.

Network performance in clouds and guests
Ubuntu 17.04 delivers the Linux 4.10 kernel , with Amazon’s Elastic Network Adaptor (ENA) driver which supports up to 20 Gbps network speed on AWS. SR-IOV support for Microsoft Azure allows Azure guests direct access to the hardware NIC which results in higher throughput and lower latencies. The 4.10 kernel will also become the LTS Rolling Kernel in 16.04 LTS, with initial support for IBM’s Power 9 and Intel’s Purley platform.

Simpler to install, simpler to run
With its 17.04 release, Ubuntu switches from swap partitions to using swap files by default. This means a simpler partition layouts during installation, disk space savings and easier adjustment of swap size. LibreOffice 5.3, is the new default office suite. Driverless printing makes the installation and configuration of compatible printers automatic either when connecting via WiFi or USB.

Ubuntu 17.04, with the widest range of desktop environments, compilers, stacks and tools, represents the efforts of thousands of developers across Debian, Ubuntu and many upstream projects.

Our thanks go to everyone who makes this extraordinary platform for innovation possible.

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In March, about 190 work hours have been dispatched among 14 paid contributors. Their reports are available:

• Antoine Beaupré did 19 hours (out of 14.75h allocated + 10 remaining hours, thus keeping 5.75 extra hours for April).
• Balint Reczey did nothing (out of 14.75 hours allocated + 2.5 hours remaining) and gave back all his unused hours. He took on a new job and will stop his work as LTS paid contributor.
• Ben Hutchings did 14.75 hours.
• Brian May did 10 hours.
• Chris Lamb did 14.75 hours.
• Emilio Pozuelo Monfort did 11.75 hours (out of 14.75 hours allocated + 0.5 hours remaining, thus keeping 3.5 hours for April).
• Guido Günther did 4 hours (out of 8 hours allocated, thus keeping 4 extra hours for April).
• Hugo Lefeuvre did 4 hours (out of 13.5 hours allocated, thus keeping 9.5 extra hours for April).
• Jonas Meurer did 11.25 hours (out of 14.75 hours allocated, thus keeping 3.5 extra hours for April).
• Markus Koschany did 14.75 hours.
• Ola Lundqvist did 23.75 hours (out of 14.75h allocated + 9 hours remaining).
• Raphaël Hertzog did 15 hours (out of 10 hours allocated + 6.25 hours remaining, thus keeping 1.25 hours for April).
• Roberto C. Sanchez did 21.5 hours (out of 14.75 hours allocated + 7.75 hours remaining, thus keeping 1 extra hour for April).
• Thorsten Alteholz did 14.75 hours.

Evolution of the situation

The number of sponsored hours has been unchanged but will likely decrease slightly next month as one sponsor will not renew his support (because they have switched to CentOS).

The security tracker currently lists 52 packages with a known CVE and the dla-needed.txt file 40. The number of open issues continued its slight increase… not worrisome yet but we need to keep an eye on this situation.

Thanks to our sponsors

New sponsors are in bold.

• Platinum sponsors:
• TOSHIBA (for 18 months)
• GitHub (for 9 months)
• Gold sponsors:
• The Positive Internet (for 34 months)
• Blablacar (for 33 months)
• Linode LLC (for 23 months)
• Babiel GmbH (for 12 months)
• Plat’Home (for 12 months)
• Silver sponsors:
• Domeneshop AS (for 33 months)
• Université Lille 3 (for 33 months)
• Trollweb Solutions (for 31 months)
• Nantes Métropole (for 27 months)
• University of Luxembourg (for 25 months)
• Dalenys (for 24 months)
• Univention GmbH (for 19 months)
• Université Jean Monnet de St Etienne (for 19 months)
• Sonus Networks (for 13 months)
• UR Communications BV (for 7 months)
• maxcluster GmbH (for 7 months)
• Exonet B.V. (for 3 months)
• Bronze sponsors:
• David Ayers – IntarS Austria (for 34 months)
• Evolix (for 34 months)
• Offensive Security (for 34 months)
• Seznam.cz, a.s. (for 34 months)
• Freeside Internet Service (for 33 months)
• MyTux (for 33 months)
• Linuxhotel GmbH (for 31 months)
• Intevation GmbH (for 30 months)
• Daevel SARL (for 29 months)
• Bitfolk LTD (for 28 months)
• Megaspace Internet Services GmbH (for 28 months)
• Greenbone Networks GmbH (for 27 months)
• NUMLOG (for 27 months)
• WinGo AG (for 26 months)
• Ecole Centrale de Nantes – LHEEA (for 23 months)
• Sig-I/O (for 20 months)
• Entr’ouvert (for 18 months)
• Adfinis SyGroup AG (for 15 months)
• Laboratoire LEGI – UMR 5519 / CNRS (for 10 months)
• Quarantainenet BV (for 10 months)
• GNI MEDIA (for 9 months)
• RHX Srl (for 7 months)
• Bearstech
• LiHAS

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

The Xubuntu team is happy to announce the immediate release of Xubuntu 17.04.

Xubuntu 17.04 is a regular release and will be supported for 9 months, until January 2018. If you need a stable environment with longer support time, we recommend that you use Xubuntu 16.04 LTS instead.

The final release images are available as torrents and direct downloads from
http://xubuntu.org/getxubuntu/

As the main server might be busy in the first few days after the release, we recommend using the torrents if possible.

We’d like to thank everybody who contributed to this release of Xubuntu!

Support

For support with the release, navigate to Help & Support for a complete list of methods to get help.

Highlights, Notes and Known Issues

Highlights

Several Xfce panel plugins and applications have been ported to GTK+ 3, paving the way for improved theming and further development. Core Xfce libraries exo and libxfce4ui have also been updated with full GTK+ 3 support, the latter adding support for Glade development in Xubuntu with the installation of libxfce4ui-glade. The Greybird and Numix themes have also been refreshed with improved support for the toolkit.

Camera functionality has been restored in Mugshot, Parole introduced a new mini mode and improvements for network streams, and a number of welcome fixes have made their way into Thunar and Ristretto. Simon Tatham’s Portable Puzzle Collection (sgt-puzzles), an addicting collection of logic games, has been included along with the new SGT Puzzles Collection (sgt-launcher).

Notes

For new installs a swap file will be used instead of a swap partition. Upgrades from earlier versions are not affected.

Known Issues

• System encryption password is set before setting the keyboard layout (bug 1047384), giving users errors about the wrong password when decrypting in some cases. The workaround for this is to start the installation with the correct keyboard layout; press F3 to set your keyboard layout before booting either installation option.
• While recent patches for Thunar fixed problems for many, it still has some unresolved issues.
• Parole has some issues as well and can crash in certain situations.

For more information on affecting bugs, bug fixes and a list of new package versions, please refer to the Release Notes.

Codenamed “Zesty Zapus”, Ubuntu 17.04 continues Ubuntu’s proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 4.10-based kernel, and much more.

Ubuntu Desktop has seen incremental improvements, with newer versions of GTK and Qt, updates to major packages like Firefox and LibreOffice, and stability improvements to Unity.

Ubuntu Server 17.04 includes the Ocata release of OpenStack, alongside deployment and management tools that save devops teams time when deploying distributed applications – whether on private clouds, public clouds, x86, ARM, or POWER servers, z System mainframes, or on developer laptops. Several key server technologies, from MAAS to juju, have been updated to new upstream versions with a variety of new features.

The newest Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, and Xubuntu are also being released today. More details can be found for these at their individual release notes:

We’re also pleased with this release to welcome Ubuntu Budgie to the family of Ubuntu community flavours.

https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#Official_flavours

Maintenance updates will be provided for 9 months for all flavours releasing with 17.04.

To get Ubuntu 17.04

In order to download Ubuntu 17.04, visit:

http://www.ubuntu.com/download

Users of Ubuntu 16.10 will be offered an automatic upgrade to 17.04. For further information about upgrading, see:

http://www.ubuntu.com/download/desktop/upgrade

As always, upgrades to the latest version of Ubuntu are entirely free of charge.

We recommend that all users read the release notes, which document caveats, workarounds for known issues, as well as more in-depth notes on the release itself. They are available at:

http://wiki.ubuntu.com/ZestyZapus/ReleaseNotes

Find out what’s new in this release with a graphical overview:

• http://www.ubuntu.com/desktop
• http://www.ubuntu.com/desktop/features

If you have a question, or if you think you may have found a bug but aren’t sure, you can try asking in any of the following places:

• #ubuntu on irc.freenode.net
• http://lists.ubuntu.com/mailman/listinfo/ubuntu-users
• http://www.ubuntuforums.org
• http://askubuntu.com

Help Shape Ubuntu

If you would like to help shape Ubuntu, take a look at the list of ways you can participate at:

http://community.ubuntu.com/contribute

About Ubuntu

Ubuntu is a full-featured Linux distribution for desktops, laptops, netbooks and servers, with a fast and easy installation and regular releases. A tightly-integrated selection of excellent applications is included, and an incredible variety of add-on software is just a few clicks away.

Professional services including support are available from Canonical and hundreds of other companies around the world. For more information about support, visit:

http://www.ubuntu.com/support

More Information

You can learn more about Ubuntu and about this release on our website listed below:

http://www.ubuntu.com

To sign up for future Ubuntu announcements, please subscribe to Ubuntu’s very low volume announcement list at:

http://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

Originally posted to the ubuntu-announce mailing list on Thu Apr 13 13:09:56 UTC 2017 by Adam Conrad, on behalf of the Ubuntu Release Team

Codenamed “Zesty Zapus”, Kubuntu 17.04 continues our proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 4.10-based kernel, KDE Frameworks 5.31, Plasma 5.9.4 and KDE Applications 16.12.3.

The Kubuntu Desktop has seen some exciting improvements, with newer versions of Qt, updates to major packages like Krita, Kdenlive, Firefox and LibreOffice, and stability improvements to the Plasma desktop environment.

For a list of other application updates, upgrading notes and known bugs be sure to read our release notes.

Download 17.04 or read about how to upgrade from 16.10.

The Ubuntu GNOME developers are proud to announce our latest non-LTS release 17.04. For the first time in Ubuntu GNOME’s history, this release includes the latest stable release of GNOME, 3.24.

Although Ubuntu’s release schedule was originally centered around shipping the latest GNOME release, this had not been possible since Ubuntu GNOME’s first release four years ago.

Take a look at our release notes for a list of highlighted changes and improvements.

The future of Ubuntu GNOME

As announced last week by Ubuntu founder Mark Shuttleworth, Ubuntu 18.04 LTS will include GNOME instead of Unity. Specifically, it will be GNOME (including gnome-shell) with minimal Ubuntu customization. Next year, if you are using either Ubuntu 16.04 LTS or Ubuntu GNOME 16.04 LTS, you will be prompted to upgrade to Ubuntu 18.04 LTS. For normal release users, this upgrade should happen with the release of 17.10.

As a result of this decision there will no longer be a separate GNOME flavor of Ubuntu. The development teams from both Ubuntu GNOME and Ubuntu Desktop will be merging resources and focusing on a single combined release, that provides the best of both GNOME and Ubuntu. We are currently liaising with the Canonical teams on how this will work out and more details will be announced in due course as we work out the specifics.

The Ubuntu community is important to Mark Shuttleworth and he has publicly stated on Google+: “We will invest in Ubuntu GNOME with the intent of delivering a fantastic all-GNOME desktop. We’re helping the Ubuntu GNOME team, not creating something different or competitive with that effort. While I am passionate about the design ideas in Unity, and hope GNOME may be more open to them now, I think we should respect the GNOME design leadership by delivering GNOME the way GNOME wants it delivered.”

The Ubuntu GNOME developers were already members of the Ubuntu Desktop team since both teams shared responsibility for maintaining many parts of GNOME. We will continue to work closely with them and push the visions of Ubuntu GNOME into the main Ubuntu Community.

We started and maintained Ubuntu GNOME with the vision of bringing the most popular desktop experience¹ to the most popular Linux distribution. We are excited that we are now able to bring this powerful combination to many more people. If you want an early preview of what this will look like, try Ubuntu GNOME 17.04 today!

On behalf of the Ubuntu GNOME team,
Jeremy Bicha and Tim Lunn

¹ GNOME is shipped as the default desktop on a majority of Linux distributions.

i like to work outside, at a park, on the beach, etc. For years I’ve made do with regular laptops, but all those year’s I’ve really wanted an e-ink laptop to avoid the squinting and the headaches and the search for shade. The pixel-qi displays raised my hopes, but those were quickly dashed when they closed their doors. For a brief time there were two e-ink laptops for sale. They were quite underpowered and expensive, but more importantly they’re no longer around.

Maybe it’s time to build one. There are many ways one could go about it:

• Get a toughbook with a transflective display
• Get a rooted nook and run vncclient connected to a server on my laptop or in a vm
• Get a dasung e-ink monitor connected to my laptop. Not cheap, and dubious linux support.
• Actually it seems an external pixel-qi display may be available right now. Still pretty steep price.
• Attach a keyboard to a nook and use that standalone
• Get a used pixelqi, put it in some sort of case, and hook it up as a separate display
• Get a small e-ink (2″) display, hook it up to a rpi or beaglebone black
• Get a used pixelqi display and install it in something like a used lenovo s10-3
• Get a freewrite and hack it to be an ssh terminal. Freewrite themselves don’t like that idea.
• Get a used OLPG with pixelqi display.

So is there anyone in the community with similar goals? What are you using? How’s it working for you?

I can say that work has not been pretty as of late. Some people have contacted me via Telegram. The secure call function works nicely provided I wear headphones with a built-in microphone so I can see the screen to read off the emojis to the other participant. When we get to April 28th I should have a clearer picture as to how bad things are going to get at work as a federal civil servant. My ability to travel to OggCamp 17 will probably be a bit more known by then.

I have not been to Europe since 1998 so it would be nice to leave the Americas again for at least a little while after having paid visits to the British Virgin Islands, American Samoa, and Canada in the intervening time. If I could somehow figure out how to engage in a "heritage quest" to Heachem in Norfolk, that would be nice too. I know we've seen Daniel Pocock touch on the mutability of citizenship on Planet Ubuntu before but, as I tell the diversity bureaucrats at work from time to time, some of my forebears met the English coming off the boat at Jamestown. If I did the hard work I could probably join Sons of the American Revolution.

So, what might I talk about at OggCamp 17 if I had the time? Right now the evaluation project, with the helpful backing of three fabulous sponsors, is continuing in limited fashion relative to Outernet. We have a rig and it is set up. The garage is the safest place to put it although I eventually want to get an uninterruptible power supply for it due to the flaky electrical service we have at times.

Although there was a talk at Chaos Communications Congress 33 that I have still not watched by Daniel Estévez about Outernet, it appears I am approaching things from a different angle. I'm looking at this from evaluating the content being distributed and how it is chosen. Daniel evaluated hardware.

There is still much to review. Currently I'm copying the receiver's take and putting on a Raspberry Pi in the house that is running on the internal network with lighttpd pointing at the directory so that I can view the contents. Eventually I'll figure out how to get the necessary WiFi bridging down to bring the CHIP board's miniscule hotspot signal from the detached garage into the house. Currently there is a WiFi extender right next to the CHIP so I don't have to be so close to the board to be able to pick up the hotspot signal while using my laptop.

Things remain in progress, of course.

Probably like most of you I have a Raspberry Pi 2 sitting around not doing a lot. A project that I wanted to use mine for is setting up reliable network access to my home network when I'm away. I'm a geek, so network access for me means SSH. The problem with a lot of solutions out there is that ISPs on home networks change IPs, routers have funky port configurations, and a host of other annoyances that make setting up access unreliable. That's where Pagekite comes in.

Pagekite is a service that is based in Iceland and allows tunneling various protocols, including SSH. It gives a DNS name at one end of that tunnel and allows connecting from anywhere. They run on Open Source software and their libraries are all Open Source. They charge a small fee, which I think is reasonable, but they also provide a free trial account that I used to set this up and test it. You'll need to signup for Pagekite to get the name and secret to fill in below.

The first thing I did was setup Ubuntu core on my Pi and get it booting and configured. Using the built in configure tool it grabs my SSH keys already, so I don't need to do any additional configuration of SSH. You should always use key based login when you can. Then I SSH'd in on the local network to install and setup a small Pagekite snap I made like this:

# Install the snap
sudo snap install pagekite-ssh

# Configure the snap
snap set pagekite-ssh kitename=<your name>.pagekite.me kitesecret=<a bunch of hex>

# Restart the service to pickup the new config
sudo systemctl restart snap.pagekite-ssh.pagekite-ssh.service 

# Look at the logs to make sure there are no errors
journalctl --unit snap.pagekite-ssh.pagekite-ssh.service 

I then I configured my SSH to connect through Pagekite by editing my .ssh/config

Host *.pagekite.me
    User <U1 name> 
    IdentityFile ~/.ssh/id_launchpad
    CheckHostIP no
    ProxyCommand /bin/nc -X connect -x %h:443 %h %p

Now I can SSH into my Raspberry Pi from anywhere on the Internet! You could also install this on other boards Ubuntu core supports or anywhere snapd runs.

What is novel to me is that I now have a small low-power board that I can plug into any network, it will grab an IP address and setup a tunnel to a known address to access it. It will also update itself without me interacting with it at all. I'm considering putting one at my Dad's house as well to enable helping him with his network issues when the need arises. Make sure to only put these on networks that you have permission though!

While my daily driver shell is ZSH, when I script, I tend to target Bash. I’ve found it’s the best mix of availability & feature set. (Ideally, scripts would be in pure posix shell, but then I’m missing a lot of features that would make my life easier. On the other hand, ZSH is not available everywhere, and certainly many systems do not have it installed by default.)

I’ve started trying to use the Bash “extended test command” ([[) when I write tests in bash, because it has fewer ways you can misuse it with bad quoting (the shell parses the whole test command rather than parsing it as arguments to a command) and I find the operations available easier to read. One of those operations is pattern matching of strings, which allows for stupidly simple substring tests and other conveniences. Take, for example:

1
2
3
4

$animals="bird cat dog"
if [[ $animals == *dog* ]] ; then
  echo "We have a dog!"
fi

This is an easy way to see if an item is contained in a string.

Anyone who’s done programming or scripting is probably aware that the equality operator (i.e., test for equality) is a commutative operator. That is to say the following are equivalent:

1
2
3
4
5
6
7
8

$a="foo"
$b="foo"
if [[ $a == $b ]] ; then
  echo "a and b are equal."
fi
if [[ $b == $a ]] ; then
  echo "a and b are still equal."
fi

Seems obvious right? If a equals b, then b must equal a. So surely we can reverse our test in the first example and get the same results.

1
2
3
4
5
6

$animals="bird cat dog"
if [[ *dog* == $animals ]] ; then
  echo "We have a dog!"
else
  echo "No dog found."
fi

Go ahead, give it a try, I’ll wait here.

OK, you probably didn’t even need to try it, or this would have been a particularly boring blog post. (Which isn’t to say that this one is a page turner to begin with.) Yes, it turns out that sample prints No dog found., but obviously we have a dog in our animals. If equality is commutative and the pattern matching worked in the first place, then why doesn’t this test work?

Well, it turns out that the equality test operator in bash isn’t really commutative – or more to the point, that the pattern expansion isn’t commutative. Reading the Bash Reference Manual, we discover that there’s a catch to pattern expansion:

When the ‘==’ and ‘!=’ operators are used, the string to the right of the operator is considered a pattern and matched according to the rules described below in Pattern Matching, as if the extglob shell option were enabled. The ‘=’ operator is identical to ‘==’. If the nocasematch shell option (see the description of shopt in The Shopt Builtin) is enabled, the match is performed without regard to the case of alphabetic characters. The return value is 0 if the string matches (‘==’) or does not match (‘!=’)the pattern, and 1 otherwise. Any part of the pattern may be quoted to force the quoted portion to be matched as a string.

(Emphasis mine.)

It makes sense when you think about it (I can’t begin to think how you would compare two patterns) and it is at least documented, but it wasn’t obvious to me. Until it bit me in a script – then it became painfully obvious.

Like many of these posts, writing this is intended primarily as a future reference to myself, but also in hopes it will be useful to someone else. It took me half an hour of Googling to get the right keywords to discover this documentation (I didn’t know the double bracket syntax was called the “extended test command”, which helps a lot), so hopefully it took you less time to find this post.

This is a guest post by Florian Hoenigschmid, Director of azeti. If you would like to contribute a guest post, please contact ubuntu-devices@canonical.com

When you make a phone call, watch TV or wash your hands, you probably won’t associate this with terms like predictive maintenance, equipment damage, downtime or Service Level Agreements initially.

However, those things are helping to provide services such as mobile connectivity, a stable power grid or clean water. IoT gateways running asset management applications, connected to sensors and machinery are part of a remote asset management system, which monitors and controls critical infrastructure like generators, compressors or HVAC systems in remote locations such as cell towers, water pumping stations or secondary substations. These systems provide operators with insights about the performance of their assets in remote locations. This helps to determine if an asset is about to stop working and therefore require maintenance (preventive maintenance), if equipment has been stolen/destroyed or if operations could be improved and organized in a more cost effective way. The installed remote asset management systems help to minimize downtime, which in turn means a higher quality of the service provided.

Full Stack – Ubuntu and azeti
azeti’s solution is the full stack for managing industrial environments consisting of intelligent software for the edge (azeti Site Controller) running on IoT gateways plus a central server (azeti Engine) application providing visualization, management and deployment capabilities.

Ubuntu Core is the solid fundament for the IoT application and eliminates worries about OS upgrades, security updates and general OS management for thousands of devices. Its broad gateway support helps to choose the right hardware depending on customer’s requirement without a hardware vendor lock-in.

Edge Intelligence for Harsh Environments
azeti’s Site Controller is comparable to a virtual PLC (programmable logic controller) and provides interfaces for all prominent sensor protocols plus sophisticated analytics and automation. This local intelligence enables independence from the network uplink, as even without a cloud connection all local rulesets and automations will function.

If a couple years ago, the paradigm was to centralize, process and analyze everything in the cloud, azeti and Canonical are demonstrating that this paradigm is now shifting towards the edge of the network. As all the data is processed right where it is generated by sensors and machinery, the need for bandwidth and therefore costs is reduced, local execution of action lowers latency and a network with distributed computing also decreases its vulnerability compared to a centralized approach, which may create a single point of failure.

Reference Use Cases
Remote Maintenance Service for Electric Drives – a great example of how IoT can generate new revenue and optimize operations is the project with one of the largest electrical drives vendors where azeti provides the software stack to collect metrics from the drives and visualizes those in beautiful dashboards. Customer can now check health and performance of their drives in a modern web application without connecting directly to the machinery. Remote maintenance is now offered as a new service by the vendor; the increased visibility into assets allow sophisticated preparation before engineers are sent on site, downtimes are decreased and maintenance efforts are reduced. Customers receive better service and increased uptimes of their environments.

Battery and Generator Management in the Jungle – another real life deployment is with a service provider customer that operates several hundred telecommunication sites in demanding locations such as close to the coast or in deep jungles. The major requirement was to allow remote health checks of their on-site batteries as well as remote maintenance work for the diesel generators. Network uplink is unreliable and visits to the sites have to be reduced as much as possible. azeti’s automation engine gathers performance and health data from installed sensors and directly from the machinery. The operations team can now remotely discharge and charge the batteries, start and stop the generators and gain insights of the whole facility. On top of this, video cameras provide live feeds and access control eliminate the necessity for physical keys. On site visits and maintenance efforts have been tremendously reduced as periodic charging and discharging cycles increase the batteries lifetime heavily and diesel generators are started and stopped on a regular basis to ensure stable operations during times of outages. One of these outages just happened recently during a hurricane where the solution proved its solidness.

Further use cases in logistics, manufacturing, utilities and medical logistics show the variety of IoT solutions – Ubuntu Core for IoT is the layer enabling all the use cases and applications, hardware agnostic, security and easy manageability.

Learn more about azeti here.