标签 Snapcraft 下的文章

OpenStack 非常复杂,许多社区成员都在努力使 OpenStack 的部署和操作更加容易。其中大部分时间都用来改善相关工具,如:Ansible、Puppet、Kolla、Juju、Triple-O 和 Chef (仅举几例)。但是,如果我们降低一下标准,并且还能使包的体验更加简单,将会怎样呢?

我们正在努力通过 snap 包来实现这一点。snap 包是一种新兴的软件分发方式,这段来自 snapcraft.io 的介绍很好的总结了它的主要优点:snap 包可以快速安装、易于创建、安全运行而且能自动地事务化更新,因此你的应用程序总是能保持最新的状态并且永远不会被破坏。

捆绑软件

单个 snap 包可以内嵌多个不同来源的软件,从而提供一个能够快速启动和运行的解决方案。当你安装 snap 包时,你会发现安装速度是很快的,这是因为单个 snap 包捆绑了所有它需要的依赖。这和安装 deb 包有些不同,因为它需要下载所有的依赖然后分别进行安装。

Snap 包制作简单

在 Ubuntu 工作的时候,我花了很多时间为 Debian 制作 OpenStack 的安装包。这是一种很特殊技能,需要花很长时间才能理解其中的细微差别。与 snap 包相比,deb 包和 snap 包在复杂性上的差异有天壤之别。snap 包简单易行,并且相当有趣。

Snap 包的其它特性

  • 每个 snap 包都安装在其独有的只读 squashfs 文件系统中。
  • 每个 snap 包都运行在一个由 AppArmor 和 seccomp 策略构建的严格沙箱环境中。
  • snap 包能事务更新。新版本的 snap 包会安装到一个新的只读 squashfs 文件系统中。如果升级失败,它将回滚到旧版本。
  • 当有新版本可用时,snap 包将自动更新。
  • OpenStack 的 snap 包能保证与 OpenStack 的上游约束保持一致。打包的人不需要再为 OpenStack 依赖链维护单独的包。这真是太爽了!

OpenStack snap 包介绍

现在,下面这些项目已经有了相应的 snap 包:

  • Keystone —— 这个 snap 包为 OpenStack 提供了身份鉴证服务。
  • Glance —— 这个 snap 包为 OpenStack 提供了镜像服务。
  • Neutron —— 这个 snap 包专门提供了 neutron-server 过程,作为 OpenStack 部署过程的一个 snap 包。
  • Nova —— 这个 snap 包提供 OpenStack 部署过程中的 Nova 控制器组件。
  • Nova-hypervisor —— 这个 snap 包提供 OpenStack 部署过程中的 hypervisor 组件,并且配置使用通过 deb 包安装的 Libvirt/KVM + Open vSwitch 组合。这个 snap 包同时也包含 nava-lxd,这允许我们使用 nova-lxd 而不用 KVM。

这些 snpa 包已经能让我们部署一个简单可工作的 OpenStack 云。你可以在 github 上找到所有这些 OpenStack snap 包的源码。有关 OpenStack snap 包更多的细节,请参考上游存储库中各自的 README。在那里,你可以找到更多有关管理 snap 包的信息,比如覆盖默认配置、重启服务、设置别名等等。

想要创建自己的 OpenStack snap 包吗?

查看 snap cookie 工具。我很快就会写一篇博文,告诉你如何使用 snap cookie 工具。它非常简单,并且能帮助你在任何时候创建一个新的 OpenStack snap 包。

测试 OpenStack snap 包

我们已经用简单的脚本初步测试了 OpenStack snap 包。这个脚本会在单个节点上安装 sanp 包,还会在安装后提供额外的配置服务。来尝试下吧:

git clone https://github.com/openstack-snaps/snap-test
cd snap-test
./snap-deploy

这样,我们就已经在 Ubuntu Xenial(16.04) 上做了所有的测试。要注意的是,这将在你的系统上安装和配置相当多的软件,因此你最好在可自由使用的机器上运行它。

追踪 OpenStack

现在,你可以从 snap 商店的边缘通道来安装 snap 包,比如:

sudo snap install --edge keystone

OpenStack 团队正在努力使 CI/CD 配置到位,以便让 snap 包的发布能够交叉追踪 OpenStack 的发布(比如一个追踪 Ocata,另一个追踪 Pike 等)。每个 轨道 track 都有 4 个不同的通道。每个轨道的边缘通道将包含 OpenStack 项目对应分支最近的内容,测试、候选和稳定通道被保留用于已发布的版本。这样我们将看到如下的用法:

sudo snap install --channel=ocata/stable keystone
sudo snap install --channel=pike/edge keystone

其它

我们可以使用多个环境变量来简化 snap 包的制作。这里 有相关的说明。实际上,你无需深入的研究他们,但是在安装完 snap 包后,你也许会想要了解这些位置:

$SNAP == /snap/<snap-name>/current

这是 snap 包和它所有的文件挂载的位置。所有东西都是只读的。比如我当前安装的 keystone,$SNAP 就是 /snap/keystone/91。幸好,你不需要知道当前版本号,因为在 /snap/keystone/ 中有一个软链接(LCTT 译注:/snap/keystone/current/)指向当前正在使用版本对应的文件夹。

$ ls /snap/keystone/current/
bin                     etc      pysqlite2-doc        usr
command-manage.wrapper  include  snap                 var
command-nginx.wrapper   lib      snap-openstack.yaml
command-uwsgi.wrapper   meta     templates

$ ls /snap/keystone/current/bin/
alembic                oslo-messaging-send-notification
convert-json           oslo-messaging-zmq-broker
jsonschema             oslo-messaging-zmq-proxy
keystone-manage        oslopolicy-checker
keystone-wsgi-admin    oslopolicy-list-redundant
keystone-wsgi-public   oslopolicy-policy-generator
lockutils-wrapper      oslopolicy-sample-generator
make_metadata.py       osprofiler
mako-render            parse_xsd2.py
mdexport.py            pbr
merge_metadata.py      pybabel
migrate                snap-openstack
migrate-repository     sqlformat
netaddr                uwsgi
oslo-config-generator

$ ls /snap/keystone/current/usr/bin/
2to3               idle     pycompile     python2.7-config
2to3-2.7           pdb      pydoc         python2-config
cautious-launcher  pdb2.7   pydoc2.7      python-config
compose            pip      pygettext     pyversions
dh_python2         pip2     pygettext2.7  run-mailcap
easy_install       pip2.7   python        see
easy_install-2.7   print    python2       smtpd.py
edit               pyclean  python2.7

$ ls /snap/keystone/current/lib/python2.7/site-packages/
...

$SNAP_COMMON == /var/snap/<snap-name>/common

这个目录用于存放系统数据,对于 snap 包的多个修订版本这些数据是共用的。在这里,你可以覆盖默认配置文件和访问日志文件。

$ ls /var/snap/keystone/common/
etc  fernet-keys  lib  lock  log  run

$ sudo ls /var/snap/keystone/common/etc/
keystone  nginx  uwsgi

$ ls /var/snap/keystone/common/log/
keystone.log  nginx-access.log  nginx-error.log  uwsgi.log

严格限制

每个 snap 包都是在一个由 seccomp 和 AppArmor 策略构建的严格限制的环境中运行的。更多关于 snap 约束的细节可以在 这里 查看。

snap 包即将到来的新特性和更新

我正在期待 snap 包一些即将到来的新特性和更新(LCTT 译注:此文发表于 7 月 6 日):

  • 我们正在致力于实现 libvirt AppArmor 策略,这样 nova-hypervisor 的 snap 包就能够访问 qcow2 的 支持文件 backing files

    • 现在,作为一种变通方法,你可以将 virt-aa-helper 放在 complain 模式下:sudo aa-complain /usr/lib/libvirt/virt-aa-helper
  • 我们还在为 snapd 开发额外的接口策略,以便为部署的实例启用网络连接。

    • 现在你可以在 devmode 模式下安装 nova-hypervisor snap 包,它会禁用安全限制:snap install -devmode -edge nova-hypervisor
  • 自动连接 nova-hypervisor 的接口。我们正在努力实现在安装时自动定义 nova-hypervisor 接口。

    • 定义 AppArmor 和 seccomp 策略的接口可以允许 snap 包访问系统的资源。
    • 现在,你可以手动连接需要接口,在 nova-hypervisor snap 包的 README 中有相关的描述。
  • 命令自动定义别名。我们正在努力实现 snap 包在安装时为命令自动定义别名。

    • 这使得我们可以使用传统的命令名。安装 snap 包后,你将可以使用 nova-manage db sync 而无需再用 nova.manage db sync
    • 现在,你可以在安装 snap 包后手动设置别名,比如:snap alias nova.manage nova-manage。如想获取更多细节请查看 snap 包的 README 。
  • 守护进程自动定义别名。当前 snappy 仅支持为命令(非守护进程)定义别名。一旦针对守护进程的别名可用了,我们将设置它们在安装的时候自动配置。

    • 这使得我们可以使用额外的单元文件名。我们可以使用 systemctl restart nova-compute 而无需再用 systemctl restart snap.nova.nova-compute
  • snap 包资产跟踪。这使得我们可以追踪用来构建 snap 包的版本以便在将来构建时重复使用。

如果你想多聊一些关于 snap 包的内容,你可以在 freenode 的 #openstack-snaps 这样的 IRC 上找到我们。我们欢迎你的反馈和贡献!感谢并祝你玩得开心!Corey


作者简介:

Corey Bryant 是 Ubuntu 的核心开发者和 Canonical 公司 OpenStack 工程团队的软件工程师,他主要专注于为 Ubuntu 提供 OpenStack 的安装包以及为 Juju 进行 OpenStack 的魅力开发。他对开源软件充满热情,喜欢与来自世界各地的人一起工作。

译者简介:

snapcraft.io 的钉子户,对 Ubuntu Core、Snaps 和 Snapcraft 有着浓厚的兴趣,并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号: Snapcraft,最近会在上面连载几篇有关 Core snap 发布策略、交付流程和验证流程的文章,欢迎围观 :)

via: https://insights.ubuntu.com/2017/07/06/openstack-in-a-snap/

作者:Corey Bryant 译者:Snapcrafter 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

snaps

Ubuntu Core 已经正式发布(LCTT 译注:指 2016 年 11 月发布的 Ubuntu Snappy Core 16 ),也许是时候让你的 snap 包进入商店了!

交付和商店的概念

首先回顾一下我们是怎么通过商店管理 snap 包的吧。

每次你上传 snap 包,商店都会为其分配一个修订版本号,并且商店中针对特定 snap 包 的版本号都是唯一的。

但是第一次上传 snap 包的时候,我们首先要为其注册一个还没有被使用的名字,这很容易。

商店中所有的修订版本都可以释放到多个通道中,这些通道只是概念上定义的,以便给用户一个稳定或风险等级的参照,这些通道有:

  • 稳定(stable)
  • 候选(candidate)
  • 测试(beta)
  • 边缘(edge)

理想情况下,如果我们设置了 CI/CD 过程,那么每天或在每次更新源码时都会将其推送到边缘通道。在此过程中有两件事需要考虑。

首先在开始的时候,你最好制作一个不受限制的 snap 包,因为在这种新范例下,snap 包的大部分功能都能不受限制地工作。考虑到这一点,你的项目开始时 confinement 将被设置为 devmode(LCTT 译注:这是 snapcraft.yaml 中的一个键及其可选值)。这使得你在开发的早期阶段,仍然可以让你的 snap 包进入商店。一旦所有的东西都得到了 snap 包运行的安全模型的充分支持,那么就可以将 confinement 修改为 strict

好了,假设你在限制方面已经做好了,并且也开始了一个对应边缘通道的 CI/CD 过程,但是如果你也想确保在某些情况下,早期版本 master 分支新的迭代永远也不会进入稳定或候选通道,那么我们可以使用 gadge 设置。如果 snap 包的 gadge 设置为 devel (LCTT注:这是 snapcraft.yaml 中的一个键及其可选值),商店将会永远禁止你将 snap 包释放到稳定和候选通道。

在这个过程中,我们有时可能想要发布一个修订版本到测试通道,以便让有些用户更愿意去跟踪它(一个好的发布管理流程应该比一个随机的日常构建更有用)。这个阶段结束后,如果希望人们仍然能保持更新,我们可以选择关闭测试通道,从一个特定的时间点开始我们只计划发布到候选和稳定通道,通过关闭测试通道我们将使该通道跟随稳定列表中的下一个开放通道,在这里是候选通道。而如果候选通道跟随的是稳定通道后,那么最终得到是稳定通道了。

进入 Snapcraft

那么所有这些给定的概念是如何在 snapcraft 中配合使用的?首先我们需要登录:

$ snapcraft login
Enter your Ubuntu One SSO credentials.
Email: [email protected]
Password: **************
Second-factor auth: 123456

在登录之后,我们就可以开始注册 snap 了。例如,我们想要注册一个虚构的 snap 包 awesome-database:

$ snapcraft register awesome-database
We always want to ensure that users get the software they expect
for a particular name.

If needed, we will rename snaps to ensure that a particular name
reflects the software most widely expected by our community.

For example, most people would expect ‘thunderbird’ to be published by
Mozilla. They would also expect to be able to get other snaps of
Thunderbird as 'thunderbird-sergiusens'.

Would you say that MOST users will expect 'a' to come from
you, and be the software you intend to publish there? [y/N]: y

You are now the publisher for 'awesome-database'

假设我们已经构建了 snap 包,接下来我们要做的就是把它上传到商店。我们可以在同一个命令中使用快捷方式和 --release 选项:

$ snapcraft push awesome-databse_0.1_amd64.snap --release edge
Uploading awesome-database_0.1_amd64.snap [=================] 100%
Processing....
Revision 1 of 'awesome-database' created.

Channel    Version    Revision
stable     -          -
candidate  -          -
beta       -          -
edge       0.1        1

The edge channel is now open. 

如果我们试图将其发布到稳定通道,商店将会阻止我们:

$ snapcraft release awesome-database 1 stable
Revision 1 (devmode) cannot target a stable channel (stable, grade: devel) 

这样我们不会搞砸,也不会让我们的忠实用户使用它。现在,我们将最终推出一个值得发布到稳定通道的修订版本:

$ snapcraft push awesome-databse_0.1_amd64.snap
Uploading awesome-database_0.1_amd64.snap [=================] 100%
Processing....
Revision 10 of 'awesome-database' created. 

注意, 版本号 version (LCTT 译注:这里指的是 snap 包名中 0.1 这个版本号)只是一个友好的标识符,真正重要的是商店为我们生成的 修订版本号 Revision (LCTT 译注:这里生成的修订版本号为 10)。现在让我们把它释放到稳定通道:

$ snapcraft release awesome-database 10 stable
Channel    Version    Revision
stable     0.1        10
candidate  ^          ^
beta       ^          ^
edge       0.1        10

The 'stable' channel is now open. 

在这个针对我们正在使用架构最终的通道映射视图中,可以看到边缘通道将会被固定在修订版本 10 上,并且测试和候选通道将会跟随现在修订版本为 10 的稳定通道。由于某些原因,我们决定将专注于稳定性并让我们的 CI/CD 推送到测试通道。这意味着我们的边缘通道将会略微过时,为了避免这种情况,我们可以关闭这个通道:

 $ snapcraft close awesome-database edge
Arch    Channel    Version    Revision
amd64   stable     0.1        10
        candidate  ^          ^
        beta       ^          ^
        edge       ^          ^

The edge channel is now closed. 

在当前状态下,所有通道都跟随着稳定通道,因此订阅了候选、测试和边缘通道的人也将跟踪稳定通道的改动。比如就算修订版本 11 只发布到稳定通道,其他通道的人们也能看到它。

这个清单还提供了完整的体系结构视图,在本例中,我们只使用了 amd64。

获得更多的信息

有时过了一段时间,我们想知道商店中的某个 snap 包的历史记录和现在的状态是什么样的,这里有两个命令,一个是直截了当输出当前的状态,它会给我们一个熟悉的结果:

 $ snapcraft status awesome-database
Arch    Channel    Version    Revision
amd64   stable     0.1        10
        candidate  ^          ^
        beta       ^          ^
        edge       ^          ^ 

我们也可以通过下面的命令获得完整的历史记录:

 $ snapcraft history awesome-database
Rev.    Uploaded              Arch       Version    Channels
3       2016-09-30T12:46:21Z  amd64      0.1        stable*
...
...
...
2       2016-09-30T12:38:20Z  amd64      0.1        -
1       2016-09-30T12:33:55Z  amd64      0.1        - 

结束语

希望这篇文章能让你对 Snap 商店能做的事情有一个大概的了解,并让更多的人开始使用它!


via: https://insights.ubuntu.com/2016/11/15/making-your-snaps-available-to-the-store-using-snapcraft/

译者简介:

snapcraft.io 的钉子户,对 Ubuntu Core、Snaps 和 Snapcraft 有着浓厚的兴趣,并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号: Snapcraft,近期会在上面连载几篇有关 Core snap 发布策略、交付流程和验证流程的文章,欢迎围观 :)

作者:Sergio Schvezov 译者:Snapcrafter 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这篇帖子是有关 在 Ubuntu Core 开发 ROS 原型到成品 系列的补充,用来回答我收到的一个问题: “我想做一个工厂镜像,但我不想使我的 snap 公开” 当然,这个问题和回答都不只是针对于机器人技术。在这篇帖子中,我将会通过两种方法来回答这个问题。

开始之前,你需要了解一些制作 Ubuntu Core 镜像的背景知识,如果你已经看过 在 Ubuntu Core 开发 ROS 原型到成品[3 系列文章(具体是第 5 部分),你就已经有了需要的背景知识,如果没有看过的话,可以查看有关 制作你的 Ubuntu Core 镜像 的教程。

如果你已经了解了最新的情况,并且当我说 “模型定义” 或者 “模型断言” 时知道我在谈论什么,那就让我们开始通过不同的方法使用私有 sanps 来制作 Ubuntu Core 镜像吧。

方法 1: 不要上传你的 snap 到商店

这是最简单的方法了。首先看一下这个有关模型定义的例子——amd64-model.json

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-test-snap"]
}

让我们将它转换成模型断言:

$ cat amd64-model.json | snap sign -k my-key-name > amd64.model
You need a passphrase to unlock the secret key for
user: "my-key-name"
4096-bit RSA key, ID 0B79B865, created 2016-01-01
...

获得模型断言:amd64.model 后,如果你现在就把它交给 ubuntu-image 使用,你将会碰钉子:

$ sudo ubuntu-image -c stable amd64.model 
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-test-snap
error: cannot find snap "kyrofa-test-snap": snap not found
COMMAND FAILED: snap prepare-image --channel=stable amd64.model /tmp/tmp6p453gk9/unpack

实际上商店中并没有名为 kyrofa-test-snap 的 snap。这里需要重点说明的是:模型定义(以及转换后的断言)只包含了一系列的 snap 的名字。如果你在本地有个那个名字的 snap,即使它没有存在于商店中,你也可以通过 --extra-snaps 选项告诉 ubuntu-image 在断言中匹配这个名字来使用它:

$ sudo ubuntu-image -c stable \
         --extra-snaps /path/to/kyrofa-test-snap_0.1_amd64.snap \
         amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Copying "/path/to/kyrofa-test-snap_0.1_amd64.snap" (kyrofa-test-snap)
kyrofa-test-snap already prepared, skipping
WARNING: "kyrofa-test-snap" were installed from local snaps
disconnected from a store and cannot be refreshed subsequently!
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在,在 snap 并没有上传到商店的情况下,你已经获得一个预装了私有 snap 的 Ubuntu Core 镜像(名为 pc.img)。但是这样做有一个很大的问题,ubuntu-image 会提示一个警告:不通过连接商店预装 snap 意味着你没有办法在烧录了这些镜像的设备上更新它。你只能通过制作新的镜像并重新烧录到设备的方式来更新它。

方法 2: 使用品牌商店

当你注册了一个商店账号并访问 dashboard.snapcraft.io 时,你其实是在标准的 Ubuntu 商店中查看你的 snap。如果你是在系统中新安装的 snapd,默认会从这个商店下载。虽然你可以在 Ubuntu 商店中发布私有的 snap,但是你不能将它们预装到镜像中,因为只有你(以及你添加的合作者)才有权限去使用它。在这种情况下制作镜像的唯一方式就是公开发布你的 snap,然而这并不符合这篇帖子的目的。

对于这种用例,我们有所谓的 品牌商店。品牌商店仍然托管在 Ubuntu 商店里,但是它们是针对于某一特定公司或设备的一个定制的、专门的版本。品牌商店可以继承或者不继承标准的 Ubuntu 商店,品牌商店也可以选择开放给所有的开发者或者将其限制在一个特定的组内(保持私有正是我们想要的)。

请注意,这是一个付费功能。你需要 申请一个品牌商店。请求通过后,你将可以通过访问用户名下的 “stores you can access” 看到你的新商店。

在那里你可以看到多个有权使用的商店。最少的情况下也会有两个:标准的 Ubuntu 商店以及你的新的品牌商店。选择品牌商店(红框),进去后记录下你的商店 ID(蓝框):等下你将会用到它。

在品牌商店里注册名字或者上传 snap 和标准的商店使用的方法是一样的,只是它们现在是上传到你的品牌商店而不是标准的那个。如果你将品牌商店放在 unlisted 里面,那么这些 snap 对外部用户是不可见。但是这里需要注意的是第一次上传 snap 的时候需要通过 web 界面来操作。在那之后,你可以继续像往常一样使用 Snapcraft 来操作。

那么这些是如何改变的呢?我的 “kyrofal-store” 从 Ubuntu 商店继承了 snap,并且还包含一个发布在稳定通道中的 “kyrofa-bran-test-snap” 。这个 snap 在 Ubuntu 商店里是使用不了的,如果你去搜索它,你是找不到的:

$ snap find kyrofa-branded
The search "kyrofa-branded" returned 0 snaps

但是使用我们前面记录的商店 ID,我们可以创建一个从品牌商店而不是 Ubuntu 商店下载 snap 的模型断言。我们只需要将 “store” 键添加到 JSON 文件中,就像这样:

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-branded-test-snap"],
    "store": "ky<secret>ek"
}

使用方法 1 中的方式对它签名,然后我们就可以像这样很简单的制作一个预装有我们品牌商店私有 snap 的 Ubuntu Core 镜像:

$ sudo ubuntu-image -c stable amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-branded-test-snap
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在,和方法 1 的最后一样,你获得了一个为工厂准备的 pc.img。并且使用这种方法制作的镜像中的所有 snap 都从商店下载的,这意味着它们将能像平常一样自动更新。

结论

到目前为止,做这个只有两种方法。当我开始写这篇帖子的时候,我想过可能还有第三种(将 snap 设置为私有然后使用它制作镜像),但最后证明是不行的

另外,我们也收到很多内部部署或者企业商店的请求,虽然这样的产品还没有公布,但是商店团队正在从事这项工作。一旦可用,我将会写一篇有关它的文章。

希望能帮助到您!


关于作者

Kyle 是 Snapcraft 团队的一员,也是 Canonical 公司的常驻机器人专家,他专注于 snaps 和 snap 开发实践,以及 snaps 和 Ubuntu Core 的机器人技术实现。


via: https://insights.ubuntu.com/2017/07/11/ubuntu-core-making-a-factory-image-with-private-snaps/

作者:Kyle Fazzari 译者:Snaplee 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

今日关注

Ubuntu 16.04 LTS 软件仓库中的快照打包工具 Snapcraft 更新到了 2.15 版本。这一版本中新增了对 Go 插件构建标签的支持,可以更细粒度的控制每一部分的平行构建;设置了对 Python2 插件的限制,允许 .yaml 文件指向外部资源。另外,Snapcraft 现在可以对包进行缓存。还有一些新的功能,可以使用下面的命令安装体验:

sudo apt update
sudo apt install snapcraft

可以使用下面的命令安装示例来对 snapcraft 进行学习:

sudo apt install snapcraft-examples
snapcraft --help

图文摘要

Linux 内核 3.2.82 LTS 发布,这一版本对 x86 的硬件体系结构以及 Btrfs 文件系统进行了改进。

Sylvia Ritter 为 Ubuntu Linux 绘制了25张超炫的壁纸。每一个新的 Ubuntu 版本都有一个代号,都是基于 真实的动物命名的,除了 Utuntu14.10(Utopic Unicorn)和 Ubuntu15.10(Wily Werewolf)这两个版本是基于虚构的角色命名。想要壁纸的可以去下载了。

Fedora 25 Linux 预计2016年11月5号发布,默认搭载 Wayland 。

头条消息

Canonical 为了推动其 snap 软件包格式,不但将其用在 Ubuntu 16.04 LTS 中,还对创建 snap 软件包的工具进行了更新,以期让更多的开发者将他们维护的软件包打包成 snap 格式。今天,Snapcraft 发布了 2.9。这一版本提供了实验性的 YAML 属性 “confinement” 和 “epoch” 的支持。

可以使用下面命令来安装Snapcraft 2.9:

sudo apt update
sudo apt install snapcraft
sudo apt install snapcraft-examples

深度操作系统发布了 15.2 版本,它采用了全新的启动器展示方式和直观的搜索,增加安全启动支持,首次采用由深度内核小组进行优化编译的4.4 LTS内核,系统性能和资源占用均得到了显著提升;同时,本次版本预装广受欢迎的网易云音乐和更稳定的新版CrossOver 15。更多详情

版本更迭

  • 下一代分布式独立图形安装框架 Calamares 2.2.3 发布。这一版本修复了几个 bug,增加了对 Qt 5 GUI 工具套件的支持,解决了 KPMcore 构建过程中的问题,改善了 unpackfs 模块的错误报告体验。 增加了对 locale.gen 文件的配置支持以及对不同基于 Debian 的 GNU/Linux操作系统上位置选择的支持。可以从网上进行下载了。
  • 基于 Linux 的信息亭操作系统 Porteus Kiosk 4.0.0 Web Kiosk 发布。这一版本搭载了 Linux 内核 4.4.11 LTS,基于 Mozilla Firefox 45.1.1 ESR 和 Google Chrome 50.0.2661.102 浏览器。Porteus Kiosk 4.0.0 不再对32位的 Chrome 浏览器继续支持, Tomasz Jokiel 说,“我们从现在起不再提供对32位机器的支持了”。Porteus Kiosk 4.0.0 的配置面板中加入了一个新的选项,允许用户自己选择一个拾音装置作为默认的麦克风,还有一个很棒的功能就是可以定时从一个给定的路径下载屏保幻灯片。
  • 经过6个月的开发,著名的开源、自由、跨平台的绘画软件 Krita 发布了 3.0。完全移植了下一代的 Qt 5 技术,这个版本最显著的特性是对内置动画的支持,以及对大型画布和画刷的支持。目前已经可以从网上进行下载了。