Canonical Voices

Posts tagged with 'snapcraft'

Igor Ljubuncic

Recently, we published several blog posts, aimed at helping developers enjoy a smoother, faster, more streamlined experience creating snaps. We discussed the tools and tricks you can employ in snapcraft to accelerate the speed at which you iterate on your builds.

We want to continue the work presented in the Make your snap development faster tutorial, by giving you some fresh pointers and practical tips that will make the journey even brisker and snappier than before.

You shall not … multipass

Multipass is a cross-platform tool used to launch and manage virtual machines on Windows, Mac and Linux. Behind the scenes, snapcraft uses multipass to setup a clean, isolated build environment inside which your snaps will be created. Multipass leverages KVM (qemu) to create virtual machine instances. While this is handy when running natively on a host, this approach is not reliable for nested virtual machines or systems with limited KVM support.

Indeed, if you are running snapcraft inside a VM that does not support hardware acceleration passthrough, you’re running on a host with a CPU that does not support hardware acceleration, hardware acceleration is disabled in BIOS, or KVM modules are not loaded into memory, you will most likely see the following error:

failed to launch: Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory

If you encounter this problem – which can happen if you’re using Linux as a virtual machine, a setup that is quite popular with a large number of developers, this means that you cannot use multipass for your builds. However, snapcraft supports several other clever methods that will let you successfully create your snaps in a safe, isolated manner.

Use LXD

You can run snapcraft with the LXD backend. This requires that you have the LXD software installed and configured on your system. Start by installing and configuring the tool:

snap install lxd
lxd init

To verify that LXD has been set up correctly, you can start an Ubuntu 18.04 container instance and open a shell inside it:

lxc launch ubuntu:18.04 test-instance
lxc exec test-instance -- /bin/bash

You will now have a minimal Ubuntu installation. You can exit and destroy the container, or continue working inside it. For instance, you can use it now to setup snapcraft, installation additional software you may need, as well as copy any assets, like your project files and source code, into the container.

Outside the container environment, if you want to invoke snapcraft with LXD, you can run snapcraft with the –use-lxd flag:

snapcraft --use-lxd

Destructive mode & manual container setup

By default, snapcraft uses multipass to start virtual machine instances and run the build inside them. This mode will not work when snapcraft is invoked inside the container environment. To that end, snapcraft needs to be invoked with the –destructive-mode argument. Please note that this feature is intended for short-lived CI systems, as the build will install packages on the (virtual) host, may include existing files from the host and could thus be unclean

snapcraft --destructive-mode

In this case, the full sequence of a manual container setup would include the following steps:

  • Manually start a container (lxc launch).
  • Copy your snapcraft.yaml into the container (lxc file push).
  • Open an interactive shell (lxc exec).
  • Inside the container, run snapcraft –destructive-mode flag. Please be extra careful and make sure that you run this command in the right shell, so you don’t accidentally do this on your host system. You may end up retrieving various packages and libraries that could potentially conflict with your setup.
  • Once you have successfully completed the build, you can retrieve the snap from inside the container (lxc pull).
  • Stop and/or destroy the container instance (lxc stop).

Shell after

In the tutorial linked above, we talked about the debug flag, which lets you step into the build environment on failure, allowing you to examine the system and understand better what might have gone wrong. Similarly, you can step into the virtual machine or container upon successful build using the –shell-after flag.

snapcraft --shell-after

You also have the option to run your snaps with the –shell flag. This can be useful in troubleshooting runtime issues, like missing libraries, permissions – or other errors that you have encountered while reviewing your snap before pushing to the store. Alongside the try and pack commands, which we examined last week, you get a great deal of flexibility in nailing down issues and bugs during the development phase.

Summary

If you’ve ever raced a car, you know the best lap times aren’t decided by straight line dashes, they are decided by how fast you go through corners. Slow in, fast out. This article comes with a handful of useful, advanced tricks – the ability to use different provisioning backends, the destructive mode and the after-build shell. These should help you enjoy higher, faster productivity creating snaps. If you have any feedback or questions on this topic, please join our forum for a discussion.

No iconic Lord of the Rings phrases were harmed in the writing of this article.

Photo by Marco Bicca on Unsplash.

The post Faster snap development – additional tips and tricks appeared first on Ubuntu Blog.

Read more
Igor Ljubuncic

Over the past several months, we have shared with you several articles and tutorials showing how to accelerate application development so that a typically demanding, time-consuming process becomes an easier, faster and more fun one. Today, we’d like to introduce some additional tips and tricks. Namely, we want to talk about elegant ways you can streamline the final steps of a snap build.

Snap try

A rather handy thing you can do to speed up the development and testing is the snap try command. It allows you to install a snap AND make live (non-metadata) changes to the snap contents without having to go through the build process. This may sound a little confusing, so let’s discuss a practical example.

Say you built a snap, and you want to test how it works. Typically, the standard process is to install the snap (with the –dangerous flag), and then run the snap. Early in the testing process, a likely scenario is that a snap may not launch because it could be missing runtime libraries. With the usual development model, you would iterate in the following manner:

  • Edit the snapcraft.yaml.
  • Add relevant stage packages to include necessary runtime libraries.
  • Re-run the build process.
  • Remove the installed snap.
  • Install the new version and test again.

This is perfectly fine, but it can take some time. The alternative approach with snap try allows you to make live changes to your snap without going through the rebuild process. The way snap try works, it installs the snap, and it uses the specified directory (containing the valid snap contents) as its root. If you make non-metadata changes there, they will be automatically reflected. For instance, you can add libraries into usr/lib or lib, and see whether you can resolve runtime issues during the test phase. Once you’re satisfied the snap works well, you can then make the one final build.

Where do you start?

The easiest way is to simply unsquash a built snap, make changes to the contents contained inside the extracted squashfs-root directory, and then snap try against it, and see whether you have a successful build with all the assets correctly included. Moreover, with snap try, you can also change confinement modes, which gives you additional flexibility in testing your snap under different conditions, and see whether the application works correctly.

snap try
electron-quick-start 1.0.0 mounted from /home/igor/snap-tests/electron-quick-start/dist/squashfs-root

Snapcraft pack

Side by side with snap try, you can use the snapcraft pack command. It lets you create a snap from a directory holding a valid snap (the layout of the target directory must contain a meta/snap.yaml file). Going back to our previous example, you would alter the contents of your project directory, add assets (like libraries), and then pack those into a squashfs file.

snapcraft pack .
Snapping 'electron-quick-start' /
Snapped electron-quick-start_1.0.0_amd64.snap

The two commands, snap try and snapcraft pack, complement each other really well. For instance, while you cannot make live changes to metadata for snap try without reinstalling the snap (directory), you can edit the snap.yaml file and pack additional snaps, allowing you to quickly test new changes.

You can also manually create your own snap and pack them for both offline and online distribution. This might be useful if your application language isn’t currently supported as a plugin in snapcraft, or if you have ready archives of binary code you want to assemble into snaps in a quick and convenient way.

Summary

Sometimes, small things can make a big difference. The ability to quickly make changes to your snaps in the testing phase, while still retaining the full separation and containment from the underlying system provides developers with the peace of mind they need to iterate quickly and release their applications. Snap try and snapcraft pack are convenient ways to blend the standard build process and runtime usage in a streamlined manner. As always, if you have any comments or suggestions, please join our forum for a discussion.

Photo by chuttersnap on Unsplash.

The post Development tips and tricks – snap try and snapcraft pack appeared first on Ubuntu Blog.

Read more
Alan Pope

A little later than usual, we’ve collected some of the snaps which crossed our “desk” (Twitter feed) during May 2019. Once again, we bring you a suite of diverse applications published in the Snap Store. Take a look down the list, and discover something new today.

Cloudmonkey (cmk) is a CLI and interactive shell that simplifies configuration and management of Apache CloudStack, the opensource IAAS cloud computing platform.



snap install cloudmonkey


Got a potato gaming computer? You can still ‘game’ on #linux with Vitetris right in your terminal! Featuring configurable keys, high-score table, multi (2) player mode and joystick support! Get your Pentomino on today!

snap install vitetris


If you’re seeking a comprehensive and easy to use #MQTT client for #Linux then look no further than MQTT Explorer.



snap install mqtt-explorer


Azimuth is a metroidvania game, with vector graphics. Azimuth is inspired by such as the Metroid series (particularly Super Metroid and Metroid Fusion), SketchFighter 4000 Alpha, and Star Control II (a.k.a. The Ur-Quan Masters).



snap install azimuth


Familiar with Excel? Then you’ll love Banana Accounting’s intuitive, all-in-one spreadsheet-inspired features. Upgrade your bookkeeping with brilliant planning & fast invoicing. Journals, balance sheets, profit & loss, liquidity, VAT, and more!



snap install banana-accounting


Remember ICQ? We do! The latest release of the popular chat application is available for #Linux as an official snap! Dust off your ID and password, and get chatting like it’s 1996!



snap install icq-im


Déjà Dup hides the complexity of backing up your system. Déjà Dup is a handy tool, with support for local, remote and cloud locations, scheduling and desktop integration.



snap install deja-dup


Ktorrent is a fast, configurable BitTorrent, with UDP tracker support, protocol encryption, IP filtering, DHT, and more. Now available as a snap.



snap install ktorrent


Fast is a minimal zero-dependency utility for testing your internet download speed from terminal.



snap install fast


No matter which Linux distribution you use, browse the Snap Store directly from your desktop. View details about snaps, read and write reviews and manage snap permissions in one place.



snap install snap-store


Krita is the full-featured digital art studio. The latest release is now available in the Snap Store.



snap install krita


From Silicon Graphics machines to modern-day PCs, BZFlag has seen them all. This 3D online multiplayer tank game blends nostalgia with fun. Now available as a snap.



snap install bzflag


That’s all for this month. Keep up to date with Snapcraft on Twitter for more updates! Also, join the community over on the Snapcraft forum to discuss anything you’ve seen here.

Header image by Alex Basov on Unsplash

The post Fresh snaps for May 2019 appeared first on Ubuntu Blog.

Read more
alfonsosanchezbeato

Niryo has built a fantastic 6-axis robotic arm called ‘Niryo One’. It is a 3D-printed, affordable robotic arm focused mainly on educational purposes. Additionally, it is fully open source and based on ROS. On the hardware side, it is powered by a Raspberry Pi 3 and NiryoStepper motors, based on Arduino microcontrollers. When we found out all this, guess what we thought? This is a perfect target for Ubuntu Core and snaps!

When the robotic arm came to my hands, the first thing I did was play with Niryo Studio; a tool from Niryo that lets you move the robotic arm, teach sequences to it and store them, and many more things. You can programme the robotic arm with Python or with a graphical editor based on Google’s Blocky. Niryo Studio is a great tool that makes starting on robotics easy and pleasant.

Nyrio studio for Ubuntu
Nyrio Studio

After this, I started the task of creating a snap with the ROS stack that controls the robotic arm. Snapcraft supports ROS, so this was not a difficult task: the catkin plugin takes care of almost everything. However, as happens with any non-trivial project, the Niryo stack had peculiarities that I had to address:

  • It uses a library called WiringPi which needs an additional part in the snap recipe.
  • GCC crashed when compiling on the RPi3, due to the device running out of memory. This is an issue known by Niryo that can be solved by using only two cores when building (this can be done by using -j2 -l2 make options). Unfortunately we do not have that much control when using Snapcraft’s catkin plugin. However, Snapcraft is incredibly extensible so we can resort to creating a local plugin by copying around the catkin plugin shipped with Snapcraft and doing the needed modifications. That is what I did, and the catkin-niryo plugin I created added the -j2 -l2 options to the build command so I could avoid the GCC crash.
  • There were a bunch of hard coded paths that I had to change in the code. Also, I had to add some missing dependencies, and there are other minor code changes. The resulting patches can be found here.
  • I also had to copy around some configuration files inside the snap.
  • Finally, there is also a Node.js package that needs to be included in the build. The nodejs plugin worked like a charm and that was easily done.

After addressing all these challenges, I was able to build a snap in an RPi3 device. The resulting recipe can be found in the niryo_snap repo in GitHub, which includes the (simple) build instructions. I went forward and published it in the Snap Store with name abeato-niryo-one. Note that the snap is not confined at the moment, so it needs to be installed with the --devmode option.

Then, I downloaded an Ubuntu Core image for the RPi3 and flashed it to an SD card. Before inserting it in the robotic arm’s RPi3, I used it with another RPi3 to which I could attach to the UART serial port, so I could run console-conf. With this tool I configured the network and the Ubuntu One user that would be used in the image. Note that the Nyrio stack tries to configure a WiFi AP for easier initial configuration, but that is not yet supported by the snap, so the networking configuration from console-conf determines how we will be able to connect later to the robotic arm.

At this point, snapd will possibly refresh the kernel and core snaps. That will lead to a couple of system reboots, and once complete  those snaps will have been updated. After this, we need to modify some files from the first stage bootloader because Niryo One needs some changes in the default GPIO configuration so the RPi3 can control all the attached sensors and motors. First, edit /boot/uboot/cmdline.txt, remove console=ttyAMA0,115200, and add plymouth.ignore-serial-consoles, so the content is:

dwc_otg.lpm_enable=0 console=tty0 elevator=deadline rng_core.default_quality=700 plymouth.ignore-serial-consoles

Then, add the following lines at the end of /boot/uboot/config.txt:

...
# For niryo
init_uart_clock=16000000
dtparam=i2c1=on
dtparam=uart0=on

Now, it is time to install the needed snaps and perform connections:

snap install network-manager
snap install --devmode --beta abeato-niryo-one
snap connect abeato-niryo-one:network-manager network-manager

We have just installed and configured a full ROS stack with these simple commands!

Nyrio robotic arm in action
The robotic arm in action

Finally, insert the SD card in the robotic arm, and wait until you see that the LED at the base turns green. After that you can connect to it using Niryo Studio in the usual way. You can now handle the robotic arm in the same way as when using the original image, but now with all the Ubuntu Core goodies: minimal footprint, atomic updates, confined applications, app store…

As an added bonus, the snap can also be installed on your x86 PC to use it in simulation mode. You just need to stop the service and start the simulation with:

snap install --devmode --beta abeato-niryo-one
snap stop --disable abeato-niryo-one
sudo abeato-niryo-one.simulation

Then, run Niryo Studio and connect to 127.0.0.1, as simple as that – no need at all to add the ROS archive and install manually lots of deb packages.

And this is it – as you can see, moving from a ROS debian based project to Ubuntu Core and snaps is not difficult, and has great gains. Easy updates, security first, 10 years updates, and much more, is a few keystrokes away!

The post Your first robotic arm with Ubuntu Core, coming from Niryo appeared first on Ubuntu Blog.

Read more
Anthony Dillon

This was a fairly busy two weeks for the Web & design team at Canonical.  Here are some of the highlights of our completed work.

Web

Web is the squad that develop and maintain most of the brochure websites across the Canonical.

Integrating the blog into www.ubuntu.com

We have been working on integrating the blog into www.ubuntu.com, building new templates and an improved blog module that will serve pages more quickly.

Takeovers and engage pages

We built and launched a few new homepage takeovers and landing pages, including:

– Small Robot Company case study

– 451 Research webinar takeover and engage page

– Whitepaper takeover and engage page for Getting started with AI

– Northstar robotics case study engage page  

– Whitepaper about Active directory

Verifying checksum on download thank you pages

We have added the steps to verify your Ubuntu download on the website. To see these steps download Ubuntu and check the thank you page.

Mir Server homepage refresh

A new homepage hero section was designed and built for www.mir-server.io.

The goal was to update that section with an image related to digital signage/kiosk and also to give a more branded look and feel by using our Canonical brand colours and Suru folds.

Brand

Brand squad champion a consistent look and feel across all media from web to social to print and logos.

Usage guide to using the company slide deck

The team have been working on storyboarding a video to guide people to use the new company slide deck correctly and highlight best practices for creating great slides.

Illustration and UI work

We have been working hard on breaking down the illustrations we have into multiple levels. We have identified x3 levels of illustrations we use and are in the process of gathering them across all our websites and reproducing them in a consistent style.

Alongside this we have started to look at the UI icons we use in all our products with the intention of creating a single master set that will be used across all products to create a consistent user experience.

Marketing support

Created multiple documents for the Marketing team, these included x2 whitepapers and x3 case studies for the Small Robot Company, Northstar and Yahoo Japan.

We also created an animated screen for the stand back wall at Kubecon in Barcelona.

MAAS

The MAAS squad develop the UI for the maas project.

Renamed Pod to KVM in the MAAS UI

MAAS has been using the label “pod” for any KVM (libvert) or RSD host – a label that is not industry standard and can be confused with the use of pods in Kubernetes. In order to avoid this, we went through the MAAS app and renamed all instances of pod to KVM and separated the interface for KVM and RSD hosts.

Replaced Karma tests with Jest

The development team working on MAAS have been focusing on modernising areas of the application. This lead to moving from the Karma test framework to Jest.

Absolute import paths to modules

Another area the development team would like to tackle is migrating from AngularJS to React. To decouple us from Angular we moved to loading modules from a relative path.

KVM/RSD: In-table graphs for CPU, RAM and storage

MAAS CPU, RAM and Storage mini charts
MAAS usage tooltip
MAAS storage tooltip

JAAS

The JAAS squad develops the UI for the JAAS store and Juju GUI  projects.

Design update for JAAS.ai

We have worked on a design update for jaas.ai which includes new colours and page backgrounds. The aim is to bring the website in line with recent updates carried out by the brand team.

Top of the new JAAS homepage

Design refresh of the top of the store page

We have also updated the design of the top section of the Store page, to make it clearer and more attractive, and again including new brand assets.

Top of jaas store page

UX review of the CLI between snap and juju

Our team has also carried out some research in the first step to more closely aligning the commands used in the CLI for Juju and Snaps. This will help to make the experience of using our products more consistent.

Vanilla

The Vanilla squad design and maintain the design system and Vanilla framework library. They ensure a consistent style throughout web assets.  

Vanilla 2.0.0 release

Since our last major release, v1.8.0 back in July last year, we’ve been working hard to bring you new features, improve the framework and make it the most stable version of Vanilla yet. These changes have been released in v2.0.0.

Over the past 2 weeks, we’ve been running QA tests across our marketing sites and web applications using our pre-release 2.0.0-alpha version. During testing, we’ve been filing and fixings bugs against this version, and have pushed up to a pre-release 2.0.0-beta version.

Vanilla framework v2.0.0 banner

We plan to launch Vanilla 2.0.0 today once we have finalised our release notes, completed our upgrade document which will help and guide users during upgrades of their sites.

Look out for our press release posts on Vanilla 2.0.0 and our Upgrade document to go along with it.

Snapcraft

The Snapcraft team work closely with the snap store team to develop and maintain the snap store website.

Install any snap on any platform

We’re pleased to announce we’ll be releasing distribution install pages for all Snaps. They’re one-stop-shops for any combination of Snap and supported distro. Simply visit https://snapcraft.io/install/spotify/debian or, say https://snapcraft.io/install/vlc/arch. The combinations are endless and not only do the pages give you that comfy at-home feeling when it comes to branding they’re also pretty useful. If you’ve never installed Snaps before we provide some easy step-by-step instructions to get the snap running and suggest some other Snaps you might like.

Snap how to install VSC

The post Design and Web team summary – 10 June 2019 appeared first on Ubuntu Blog.

Read more
Igor Ljubuncic

Snaps. The final frontier. These are the voyages of the OSS Snapcraft. Its continuing mission, to provide snap users with simple, clear and effective tips and tricks on how to build and publish their applications.

In this tutorial, we are going to talk about confinement and interfaces – how to restrict what your snaps can do, and then fine-tune the restrictions to make your applications both secure and useful.

What are we going to do?

Our tasks for today will be:

  • Overview of confinement levels and their use cases.
  • Overview of interfaces, automatic and manual connections.
  • Basic but practical examples.

Moreover, you should read the first two articles – Introduction to snapcraft and Parts & Plugins, to get a better sense of the content today. This will help you familiarize with the snapcraft ecosystem, the tools and commands, as well as several practical examples of how to build snaps.

Confinement levels

By design, snaps are confined and limited in what they can do. This is an important feature that distinguishes snaps from software distributed using the traditional repository methods. The confinement allows for a high level of isolation and security, and prevents snaps from being affected by underlying system changes, affecting one another or affecting the system.

Different confinement levels describe what type of access the application will have once installed on the user’s system. Confinement levels can be treated as security filters that define what type of system resources the application can access outside the snap.

Confinement level is specified in the snapcraft.yaml file and will affect how your application behaves during runtime.

Confinement levels

Devmode – This is a debug mode level used by developers as they iterate on the creation of their snap. This allows developers to troubleshoot applications, because they may behave differently when confined.

Strict – This confinement level uses Linux kernel security features to lock down the applications inside the snap. By default, a strictly confined application cannot access the network, the user’s home directory, any audio subsystems or webcams, and it cannot display any graphical output via X or Wayland.

Classic – This is a permissive level equivalent to the full system access that traditionally packaged applications have. Classic confinement is often used as a stop-gap measure to enable developers to publish applications that need more access than the current set of permissions allow. The classic level should be used only when required for functionality, as it lowers the security of the application.

Classically confined snaps are reviewed by the Snap Store reviewers team before they can be published. Snaps that use classic confinement may be rejected if they don’t meet the necessary requirements.

Confinement in action

We will shortly touch upon a practical example. Before we do that, let’s briefly focus on how confinement works and how it manifests when you run your snaps.

On the system level, the isolation of snaps is enforced via Discretionary Access Controls (DAC), Mandatory Access Control (MAC) via AppArmor, Seccomp kernel system call filtering (which limits the system calls a process may use), and cgroups device access controls for hardware assignment.

If a snap tries to access a resource that has not been explicitly granted, the access will be gated based on the confinement level specified in the snapcraft.yaml file:

  • In the devmode, the access will be allowed, but there will be a notification of the error.
  • In the strict mode, the access will be denied.
  • In the classic mode, the access will be identical to system-level permissions.

Interfaces

As mentioned earlier, a strictly confined snap is considered untrusted, and it runs in a restricted sandbox. By design, untrusted applications:   

  • can freely access their own data
  • cannot access other applications data
  • cannot access non-application-specific user data
  • cannot access privileged portions of the OS
  • cannot access privileged system APIs
  • may access sensitive APIs under some conditions

Strictly confined applications are not always functional with the default security policy. For example, a browser without network access or a media player without audio access do not serve their intended purpose.

ResourceStrictDevmodeClassic
Access to networkNYSystem
Access to home dirNYSystem
Access to audioNYSystem
Access to webcamNYSystem
Access to displayNYSystem

To that end, snap developers can use interfaces. These allow developers to expand on existing permissions and security policies and connect their applications to system resources. Interfaces are commonly used to enable a snap to access OpenGL acceleration, sound playback or recording, the network and the user’s $HOME directory. But which interfaces a snap requires, and provides, is very much dependent on the type of snap and its own requirements.

An interface consists of a connection between a slot and a plug. The slot is the provider of the interface while the plug is the consumer, and a slot can support multiple plug connections.

interfaces_plugs-slots

The Snap Connection

Interfaces can be automatically or manually connected. Some interfaces will be auto-connected. Others may not, especially if they have access to sensitive resources (like network control, for instance). Users have the option to manually control interfaces – connect and disconnect them.

Interfaces definition

In the first article, we briefly touched on the use of interfaces in the wethr example. The snapcraft.yaml file specifies the network plug for the wethr binary. Based on this definition, when the snap is installed, a security profile will be generated that grants the application access to network during runtime. This interface will be auto-connected so the user does not need to make any manual adjustments to have the snap work.

apps:
 wethr:
   command: wethr
   plugs:
    - network

Now, let’s examine a different example

apps:
 bettercap:
    command: bin/bettercap
    plugs:
     - home
     - network
     - network-bind
     - network-control
     - network-observe
     - netlink-connector
     - netlink-audit
     - bluetooth-control
     - firewall-control
     - x11

What do we have here?

We define an application that will have access to a range of resources, including the home directory, firewall, bluetooth, network, and even X11. Some of these interfaces will not be auto-connected. To that end, we need to examine what happens during runtime.

Automatic and manual interface connection

Once installed, you can check the list of interfaces your snap has by running:

snap interfaces “snap name”

Auto-connected interfaces will be shown with both the slot and the plug listed. Interfaces without connection will have an empty slot denoted by the dash character.

Slot             Plug
:desktop         gimp,vlc
:desktop-legacy  gimp,vlc
:gsettings       gimp
:home            gimp,review-tools,vlc
:network         gimp,lxd,review-tools,vlc
:opengl          gimp,vlc
:unity7          gimp,vlc
:wayland         gimp
:x11             gimp,vlc
-                gimp:cups-control
-                gimp:removable-media

You can manually connect (or disconnect) interfaces by running:

snap connect “snap”:”plug interface” “snap”:”slot interface”

A slot and a plug can only be connected if they have the same interface name. For example, to connect FFmpeg’s ALSA plug to the system’s ALSA slot, you’d enter the following:

sudo snap connect ffmpeg:alsa :alsa

If you do not specify the slot interface, the default (system) one will be use, e.g.:

snap connect easy-openvpn:home
snap disconnect easy-openvpn:home

Snappy Debug

We can also examine what happens in the background. You can do this using the snappy-debug snap, which is designed to help developers troubleshoot common problems with their snaps. You can use it to help identify missing interfaces by reporting on application security failures. It will also make suggestions on how to improve the snap, perhaps by adding interfaces.

snap install snappy-debug

After the snappy-debug tool is installed, run it in a separate shell:

snappy-debug.security scanlog

In a different command-line window, run your application and go through the expected behavior steps until you encounter an error. You can then consult the log for more details, which should highlight any issues with your snap. For instance, if you use a Firefox snap with the removable-media that isn’t auto-connected, and you try to save a file to a USB drive, you will see something like the error below:

= AppArmor =
Time: Oct 24 13:39:04
Log: apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/etc/fstab" pid=25299 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /etc/fstab (read)
Suggestions:
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
* add 'mount-observe' to 'plugs'

Conclusion

And that brings us to the end of this tutorial. Today, we focused on confinement and interfaces. The former is a method of restricting your application’s access to system resources using security policies. The latter is a method of allowing fine-tuned control of said resources.

We learned about the differences between confinement levels, the use of plugs and slots, and how to connect interfaces, both automatically and manually. Lastly, we reviewed some debugging tools that can help developers troubleshoot their applications. In the future, we will talk about hooks and health checks, as well as touch on simple recipes for how to create some common application types.

Thank you for reading. If you have any comments or suggestions, please join the forum for a friendly discussion.

Photo by Fleur on Unsplash.

The post Snapcraft confinement & interfaces appeared first on Ubuntu Blog.

Read more
Igor Ljubuncic

Last week, we published Introduction to snapcraft, a tutorial that provided a detailed overview of the snap build process. We touched on the concepts like snap ecosystem components, snapcraft command line, snapcraft.yaml syntax, and more. We’d like to expand on the first lesson, and today, we are going to talk about parts and plugins, used in the build process of snaps.

What are we going to do?

Our tasks for today include:

  • Overview of parts.
  • Overview of plugins.
  • Basic examples.

Parts

As their name implies, parts are the raw building blocks of a snap, used to collect and build binaries and their dependencies. Each part defines a source needed to assemble your application into a snap. Parts can be anything – programs, libraries, or other needed assets.

Parts support a large number of keys and values to describe the build process. However, before we demonstrate, let’s discuss plugins too, as the two are tightly coupled.

Plugins

If you work with complex projects, having to manually define every part can be tedious. Snapcraft uses plugins, which help simplify the build process. They are declared within parts to better integrate projects using existing programming languages and frameworks.

In the background, plugins will perform various language-specific commands. For example, the nodejs plugin create parts that use Node.js and/or the JavaScript packages manager npm or yarn. Snapcraft supports many languages. To see the full list, in a command-line window, type:

snapcraft list-plugins

You can also check specific details for each plugin, like:

snapcraft help ruby

Each plugin comes with its own capabilities and language-specific keywords. To illustrate the power and flexibility of plugins, let’s examine a real snap use case.

Python example

This is a section of code from a simple snapcraft.yaml file:

parts:
 tqdm:
    plugin: python
    python-version: python2
    source: https://github.com/tqdm/tqdm.git

What do we have here?

  • plugin: python declares the use of the Python plugin. It can be used for Python projects where you would want to do import Python modules with a requirements.txt, build a Python project that has a setup.py, or install packages straight from pip.
  • The python-version keyword has two valid options: python2 and python3. The selected version of Python will also be included in your snap, so it will run on systems that don’t have Python installed. You can examine this by expanding the built snap with the unsquashfs command. As we’ve seen in the first guide, relative to the snap directory, you will find directories like bin, lib, usr. In the tqdm example, python2.7 will be included under usr/bin inside the snap.
  • The source keyword points to the root of your Python project and can be a local directory or a remote Git repository.

Go example

Now, let’s examine a Go plugin example:

parts:
 caire:
    plugin: go
    source: https://github.com/esimov/caire.git
    go-importpath: github.com/esimov/caire
    build-packages:
      - build-essential

What do we have here?

  • Much like what we’ve seen with the Python plugin, we declare the use of the plugin and the root of the project containing the Go code.
  • Furthermore, the Go plugin will build using the version of Go available in the system’s traditional package achive. However, if you require a different version, you can use additional Go-specific keywords available in the plugin to override the defaults. Specifically, you can do this with the go-channel keyword (e.g. “1.8/stable”).
  • Also, we can see another difference from the Python example. We’re also using the go-importpath keyword. When using local sources, snapcraft needs to construct a suitable GOPATH. For this it uses go-importpath to know where the sources should live within GOPATH/src.
  • There’s another declaration (build-packages), which we will examine in greater detail below.

Additional parts keys

In the Go example, you can also see the use of another keyword: build-packages. This is one of the important keys available in the parts section of the snapcraft.yaml file. Specifically, build-packages defines the list of packages required to build a snap.

If you have compiled code on Ubuntu-based systems, you may be familiar with the build-essential package. This is a meta package that defines a large number of compilation tools and dependencies, like gcc, make, headers, and more.

You can also list specific packages that your project needs. For instance: libnetfilter-queue-dev or portaudio19-dev.

These packages are installed using the package manager inside the snapcraft build instance. Some other examples of parts keywords include:

  • stage-packages – A list of packages required at runtime by a snap, e.g. python-bcrypt.
  • prepare – This key runs a script before the plugin’s build step.
  • organize – A map of files to rename.

And there are many other keys, available in the snapcraft documentation.

Conclusion

This brings us to the end of this tutorial. Today, we learned about parts and plugins, used in the build process of snaps. We also saw several language-specific examples and examined the differences between them. In the next episode, we will talk more about snap confinement.

If you have any questions or feedback, please join our forum for a discussion.

Photo by Tory Bishop on Unsplash.


The post Snapcraft parts & plugins appeared first on Ubuntu Blog.

Read more
Peter Mahnke

It was another busy iteration for the web and design team, trying to get a lot of work wrapped up before we head off to Lyon, France for our 19.10 Roadmap cycle kick-off.

JAAS

The team rolled out a new version of the website with a new url, too: https://jujucharms.com now redirects to https://jaas.ai/ as part of a bigger renovation planned for JAAS and Juju. This move also updates the technology used for the site and we’ve migrated the Juju GUI as a Flaskapp that allows us to update and deploy both the website and GUI within minutes. With faster rollout we are now able to iterate and respond to your feedback and bug reports much more efficiently, inline with the infrastructure we use in our other Web Team sites.

JAAS.ai comes with some new and better UI, with more patterns and elements from our open source Vanilla framework . We can’t wait to show you the great things this move will let us do going forward.

Snapcraft

Snap categories

This time category pages received the same treatment as the store page, with fancy banners and more prominent featured snaps.

Publishing your first snap

Following on from last week, the package step of your first snap has had its 3rd section updated. “Update your snapcraft.yaml” has become “Download your snapcraft.yaml”. We now auto-generate a snapcraft.yaml based on the demo project and the name you picked – all you have to do is replace the snapcraft.yaml in the demo project and away you go.

We’ve also created an interactive YAML viewer to explain the different parts of the file giving new users a tl;dr; version of the full explanation available in the docs.

Vanilla

Replace floats based grid with the css grid layout

The 2.0-alpha-1 release removes the floats-based shelves grid (http://shelvesgrid.org/) and replaces its functionality (responsive grid, nesting, prefixing / suffixing) using the native css grid layout.

Secondary navigation

We have an updated primary navigation coming in Vanilla 2.0.0 but unfortunately, we don’t have a secondary or tertiary (if needed) design solution. Looking at our suite of brochure sites and applications, we only use a secondary navigation on Ubuntu, LXD, Ubuntu Blog and the newly revamped canonical.com (coming soon).

Taking initial concepts for canonical.com and applying to recently updated Vanilla navigation, we were able to explore different styles and find a consistent design.

Our latest solution below will be prototyped and tested before proposing up to Vanilla as a new component.

2.0.0-alpha release

We have now made all of the changes that we wish to include in Vanilla Framework 2.0.0 (including the CSS grid changes above). Before we officially release this version of the framework we are testing a selection of our sites using the 2.0.0-alpha pre-release. This release includes all proposed v2.0.0 features but is not recommended for use on production sites – for full details read the release notes.

Brand

Marketing documents

Supported Marketing with the creation of a number of whitepapers, a datasheet and branding for the upcoming Kubecon event in China.

Planning

A large portion of the iteration was spent planning for the upcoming Design Sprint, where we are going to look at all areas of branding across the company, plan guideline updates, expanding the illustration style, look at the Suru language across all touchpoints from web to exhibitions and work out a brand strategy to move forward with.

Icons

We created an icon for the security podcast team, they had made a pretty good stab at it, so we just helped it along, simplified it and brought it inline with brand.

MAAS icons were also created for the ‘Real-world MAAS’ section of the website.

Web

Takeovers & landing pages

We built and launched a few new homepage takeovers with landing pages, including:

Cloud-init

The transformation of the DevOps journey in IoT

New AI Consulting webpage

We published a new page about Canonical’s AI consulting programme.

Adding Google re-captcha to all our forms

We love robots at Canonical, but we get a few too many spam form submissions these days, so we added Google’s recaptcha to most of our forms.

UA for I launch

Canonical has completely updated it’s Ubuntu Advantage product to really help enterprises.  We updated the website to reflect these updates.

The post Design and Web team summary – 10 May 2019 appeared first on Ubuntu Blog.

Read more
Michael Hall

Java is a well established language for developing web applications, in no small part because of it’s industry standard framework for building them: Servlets and JSP.  Another important part of this standard is the Web Archive, or WAR, file format, which defines how to provide a web application’s executables and how they should be run in a way that is independent of the application server that will be running  them.

application-server-market-share-2015WAR files make life easier for developers by separate the web application from the web server. Unfortunately this doesn’t actually make it easier to deploy a webapp, it only shifts some of the burden off of the developers and on to the user, who still needs to setup and configure an application server to host it. One popular option is Apache’s Tomcat webapp server, which is both lightweight and packs enough features to support the needs of most webapps.

And here is where Snaps come in. By combining both the application and the server into a single, installable package you get the best of both, and with a little help from Snapcraft you don’t have to do any extra work.

Snapcraft supports a modular build configuration by having multiple “parts“, each of which provides some aspect of your complete runtime environment in a way that is configurable and reusable. This is extended to a feature called “remote parts” which are pre-defined parts you can easily pull into your snap by name. It’s this combination of reusable and remote parts that are going to make snapping up java web applications incredibly easy.

The remote part we are going to use is the “tomcat” part, which will build the Tomcat application server from upstream source and bundle it in your snap ready to go. All that you, as the web developer, need to provide is your .war file. Below is an simple snapcraft.yaml that will bundle Tomcat’s “sample” war file into a self-contained snap package.

name: tomcat-sample
version: '0.1'
summary: Sample webapp using tomcat part
description: |
 This is a basic webapp snap using the remote Tomcat part

grade: stable
confinement: strict

parts:
  my-part:
    plugin: dump
    source: .
    organize:
      sample.war: ./webapps/sample.war
    after: [tomcat]

apps:
  tomcat:
    command: tomcat-launch
    daemon: simple
    plugs: [network-bind]

The important bits are the ones in bold, let’s go through them one at a time starting with the part named “my-part”. This uses the simple “dump” plugin which is just going to copy everything in it’s source (current directory in this case) into the resulting snap. Here we have just the sample.war file, which we are going to move into a “webapps” directory, because that is where the Tomcat part is going to look for war files.

Now for the magic, by specifying that “my-part” should come after the “tomcat” part (using after: [tomcat]) which isn’t defined elsewhere in the snapcraft.yaml, we will trigger Snapcraft to look for a remote part by that same name, which conveniently exists for us to use. This remote part will do two things, first it will download and build the Tomcat source code, and then it will generate a “tomcat-launch” shell script that we’ll use later. These two parts, “my-part” and “tomcat” will be combined in the final snap, with the Tomcat server automatically knowing about and installing the sample.war webapp.

The “apps” section of the snapcraft.yaml defines the application to be run. In this simple example all we need to execute is the “tomcat-launch” script that was created for us. This sets up the Tomcat environment variables and runtime directories so that it can run fully confined within the snap. And by declaring it to be a simple daemon we are additionally telling it to auto-start as soon as it’s installed (and after any reboot) which will be handled by systemd.

Now when you run “snapcraft” on this config, you will end up with the file tomcat-sample_0.1_amd64.snap which contains your web application, the Tomcat application server, and a headless Java JRE to run it all. That way the only thing your users need to do to run your app is to “snap install tomcat-sample” and everything will be up and running at http://localhost:8080/sample/ right away, no need to worry about installing dependencies or configuring services.

Screenshot from 2017-03-21 14-16-59

If you have a webapp that you currently deploy as a .war file, you can snap it yourself in just a few minutes, use the snapcraft.yaml defined above and replace the sample data with your own. To learn more about Snaps and Snapcraft in general you can follow this tutorial as well as learning how to publish your new snap to the store.

Read more
ssweeny

My team at work has been focused on snaps this year and one thing we’ve tried to do internally is establish a set of best practices for snap packaging software. Toward that end I’ve been working on a little tool I’m calling snaplint to encode those practices and verify that we’re following them.

Right now you can run snaplint against your snapcraft project directory
and it will scan the prime subdirectory for the following things:

  • copyright (basically that you included usr/share/doc/*copyright*) for
    any stage-packages
  • developer cruft (things like header and object files or static libs
    that might have made their way into your snap)
  • libraries (examine the ELF files in your snap and look for libraries
    which aren’t used)

The next things I’m planning on adding are:

  • checking for copyright info from apps/parts themselves.
  • checking for mixing of incompatible licenses

I would love to hear suggestions on further improvements.

You can find the source at https://github.com/ssweeny/snaplint

And, of course if you’re running Ubuntu 16.04 or later you can try it on your own machine with:
$ snap install snaplint
$ snaplint path/to/your/project

Read more
bmichaelsen

Meist scheint manches auf den ersten Blick unmöglich.
Manches ist es auch, doch es wäre tödlich, das selbst zu glauben solange noch nichts feststeht
und die Party zu verlassen, bevor sie losgeht.

— Die Sterne, Stell die Verbindung her

Yesterday, two nice things happened: For one, LibreOffice 5.2.3 has been released and secondly Ubuntu Core 16 has been released. But beyond that, something in the middle between these two has happened: LibreOffice 5.2.3 has been released to the stable channel of the snap store at the same day. Now LibreOffice has been in the snap store for some time — and has also been on the stable channel since the Ubuntu 16.10 release. But this is the first time the LibreOffice snap is released in sync with The Document Foundation announcing the general availability of the final downloads. This was possible even though I was on vacation yesterday: LibreOffice snap packages are now being build on launchpad, which simplifies a lot, and launchpad can be asked to populate the edge channel of the store. This is making life very easy. Having smoketested the amd64 build from that channel before, to release LibreOffice 5.2.3 to the beta/candidate/stable channels too all I had to do was push three buttons on a web interface and it was available to all.

Building on launchpad, I also had the opportunity to create builds for armhf and i386 along with the usual amd64 builds with little extra effort. If you are adventurous you are encouraged to test these builds too: Be aware though that these so far aren’t even smoketested, I havent looked at them at all yet, so use them at your own risk.

All in all, this is great progress: LibreOffice 5.2.3 is available to users of Ubuntu 16.10 and Ubuntu 16.04 LTS as a snap on the day of the upstream release. And beyond that on all other distributions where snap is available — quite a few these days.

Update: ICYMI here is how to get the LibreOffice snap: http://www.libreoffice.org/download/snap/ — although strictly speaking you dont need the --channel=beta option anymore now. I will fix that soon.


Read more
Daniel Holbach

Working with a new technology often brings you to see things in a new light and re-think previous habits. Especially when it challenges the status quo and expectations of years of traditional use. Snaps are no exception in this regard. As one example twenty years ago we simply didn’t have today’s confinement technologies.

Luckily is using snapcraft a real joy: you write one declarative file, define your snap’s parts, make use of snapcraft‘s many plugins and if really necessary, you write a quick and simple plugin using Python to run your custom build.

Many of the first issues new snaps ran into were solved by improvements and new features in snapd and snapcraft. If you are still seeing a problem with your snap, we want you to get in touch. We are all interested in seeing more software as snaps, so let’s work together on them!

Enter the Sandpit

I mentioned it in my last announcement of the last Snappy Playpen event already, but as we saw many new snaps being added there in the last days, I wanted to mention it again. We started a new initiative called the Sandpit.

It’s a place where you can easily

  • list a snap you are working on and are looking for some help
  • find out at a glance if your favourite piece of software is already being snapped

It’s a very light-weight process: simply edit a wiki and get in touch with whoever’s working on the snap. The list grew quite quickly, so there’s loads of opportunities to find like-minded snap authors and get snaps online together.

You can find many of the people listed on the Sandpit wiki either in #snappy on Freenode or on Gitter. Just ask around and somebody will help.

Happy snapping everyone!

Read more
Daniel Holbach

Are you interested in snapping software and need help?

snapcraft-website

There’s a lot of good reasons for snapping software:

  • You get software out to millions of users: Ubuntu (snapd installed by default since Ubuntu 16.04 LTS), snapd available too on Arch, Debian, Gentoo, Fedora, openSUSE, openembedded, yocto and OpenWRT.
  • You get to define the experience: ship the stack the way you tested it. Just one simple test-scenario for you.
  • Building a snap is simple (one piece of YAML controls the build), publishing is instantaneous (one command to run, automatic review).
  • Multiple release channels in the store.

If you’re intrigued but need help to get started, tomorrow is a great time for this, as we’re going to have another Snappy Playpen event.

Tomorrow (13th Sept 2016) we are going to hang out on Gitter and IRC and will be there to answer your questions, work on snaps together and have fun!

In the Snappy Playpen project we are collecting best-practices and work on getting snaps out there together. We’re a friendly bunch and look forward to meeting you!

Read more
Daniel Holbach

I’m looking forward to next week, as

Going-To-Akademy-2016On Wednesday I’m going to give this workshop

So if you are interested in learning how to publish software easily and directly to users, this might be just for you.

Snaps are self-contained, confined apps, which run across a variety of Linux systems. The process of snapping software is very straight-forward and publishing them is very quick as well. The whole process offers many things upstreams and app publishers have been asking for years.

The workshop is interactive, all that’s required is that you either have VirtualBox or qemu installed or run any flavour of Ubuntu 16.04 or later. I’m going to bring USB sticks with images.

The workshop will consist of three very straight-forward parts:

  • Using the snap command to find, install, remove, update and revert software installations.
  • Using snapcraft to build and publish software.
  • Taking a look at KDE/Qt software and see how it’s snapped.

A few words about your host of the session: I’m Daniel Holbach, I have been part of the Ubuntu community since its very early days and work for Canonical on the Community team. Right now I’m working closely with the Snappy team on making publishing software as much fun as it should be.

See you next Wednesday!

Read more
Daniel Holbach

It’s been a while since our last Snappy Clinic, so we asked for your input on which topics to cover. Thanks for the feedback so far.

In our next session Sergio Schvezov is going to talk about what’s new in Snapcraft and the changes in the 2.x series. Be there and you are going to be up-to-date on how to publish your software on Snappy Ubuntu Core. There will be time for questions afterwards.

Join us on the 12th February 2016 at 16:00 UTC on http://ubuntuonair.com.

Read more
Daniel Holbach

It’s been a while since our last Snappy Clinic (here’s a link to all videos) and since Ubuntu Online Summit a lot of great things happened in Snapcraft:

Among the changes: a nil plugin, support of pip packages, support globs in the copy plugin, a nodejs plugin, add go-packages to the go plugin, countless bugfixes and tests, a more beautiful interface and more documentation.

The above and to get Sergio Schvezov on camera are reasons enough for us to have another Snappy Clinic

See you later! </p>
            <a href=Read more

Daniel Holbach

As announced earlier, we had a Ubuntu Snappy Core Clinic yesterday and we had a great time. Sergio Schvezov, Ted Gould and I talked about snapcraft in general, what’s new in the 0.3 release and showed off a couple of examples how to package software for Ubuntu Snappy Core. As you can see in the video, none of the snapcraft.yaml files length exceeded 30 lines (and this file is all that’s required); compared to what packaging on various platforms usually looks like that’s just beautiful.

We are going to have these clinics more regularly now. They will always revolve around the world of Snappy Ubuntu Core and there will always be room for questions, requests, feedback and what your want them to be.

ROS people might be interested in the one: we are very likely going to talk about snapcraft’s catkin plugin.

If you have missed the show yesterday, here it is in full length:

You might be wondering why I’m posting two videos. Unfortunately I accidentally pressed the “stop broadcast” button when I was actually looking for “stop screensharing”. Once I hit the button, we couldn’t find a way to resume the broadcast and we had to start a new one. I’m sorry about that.

If anyone of you knows a browser plugin which shows a “are you sure you want to stop the broadcast” warning, that would be fantastic. I could imagine I’m not the only one who might have confused the two when they were busy doing a demo, getting feedback on IRC and were busy talking. </p>
            <a href=Read more

Daniel Holbach

We promised more Snappy Clinics and Monday, 19th October 2015 16:00 UTC is going to be our next one.

This time we are going to have two of the main Snapcraft developers, Sergio Schvezov and Ted Gould around, who are going to

  • give an introduction to what snapcraft is,
  • talk about what’s new in the 0.3 release,
  • show how we can use a custom plugin from upstream snapcraft for a new project and
  • put together a snap from scratch.

Of course we’ll be there to answer all your questions as well.

Catch us on http://ubuntuonair.com for the show and let’s chat on IRC afterwards.

If you haven’t heard of snapcraft yet: it’s a beautiful way to get your software out to users on Ubuntu Snappy Core and it’s super easy!

 

Read more
Daniel Holbach

In the flurry of uploads for the C++ ABI transition and other frantic work (Thursday is Feature Freeze day) this gem maybe went unnoticed:

snapcraft (0.1) wily; urgency=low

  * Initial release

What this means? If you’re on wily, you can easily try out snapcraft and get started turning software into snaps. We have some initial docs available on the developer site which should help you find your way around.

This is a 0.1 release, so there are bugs and there might be bigger changes coming your way, but there will also be more docs, more plugins and more good stuff in general. If you’re curious, you might want to sign up for the daily build (just add the ppa:snappy-dev/snapcraft-daily PPA).

Here’s a brilliant example of what snapcraft can do for you: packaging a Java app was never this easy.

If you’re more into client apps, check out Ted’s article on how to create a QML snap.

As you can easily see: the future is on its way and upstreams and app developer will have a much easier time sharing their software.

As I said above: snapcraft is still a 0.1 release. If you want to let us know your feedback and find bugs or propose merges, you can find snapcraft in Launchpad.

Read more