Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть развёрнут на любой Linux-системе с поддержкой контрольных групп в ядре, а также предоставляет набор команд для управления этими контейнерами. Изначально использовал возможности LXC, с 2015 года начал использовать собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением Open Container Initiative начался переход от монолитной к модульной архитектуре.
Разрабатывается и поддерживается одноимённой компанией-стартапом, распространяется в двух редакциях — общественной (Community Edition) по лицензии Apache 2.0 и для организаций (Enterprise Edition) по проприетарной лицензии[9]. Написан на языке Go.
Проект начат как внутренняя собственническая разработка компании dotCloud, основанной Соломоном Хайксом (Solomon Hykes) в 2008 году с целью построения публичной PaaS-платформы с поддержкой различных языков программирования. Наряду с Хайксом в первоначальной разработке значительное участие приняли инженеры dotCloud Андреа Лудзарди (Andrea Luzzardi) и Франсуа-Ксавье Бурле (François-Xavier Bourlet).
В марте 2013 года код Docker был опубликован под лицензией Apache 2.0[10]. В июне 2013 года генеральным директором в dotCloud приглашён Бен Голуб (англ. Ben Golub), ранее руководивший фирмой Gluster (разрабатывавшей технологию распределённого хранения GlusterFS и поглощённой за $136 млн Red Hat в 2011 году)[11]. В октябре 2013 года, подчёркивая смещение фокуса к новой ключевой технологии, dotCloud переименована в Docker (при этом PaaS-платформа сохранена под прежним названием — dotCloud).
В октябре 2013 года выпущен релиз Havana тиражируемой IaaS-платформы OpenStack, в котором реализована поддержка Docker (как драйвер для OpenStack Nova). С ноября 2013 года частичная поддержка Docker включена в дистрибутив Red Hat Enterprise Linux версии 6.5[12] и полная — в 20-ю версию дистрибутива Fedora, ранее было достигнуто соглашение с Red Hat о включении с 2014 года Docker в тиражируемую PaaS-платформу OpenShift[13]. В декабре 2013 года объявлено о поддержке развёртывания Docker-контейнеров в среде Google Compute Engine[14].
С 2014 года ведутся работы по включению поддержки Docker в среду управления фреймворка распределённых приложений Hadoop; по результатам тестирования вариантов платформы виртуализации для Hadoop, проведённом в мае 2014 года, Docker показал на основных операциях (по массовому созданию, перезапуску и уничтожению виртуальных узлов) существенно более высокую производительность, нежели KVM, в частности, на тесте массового создания виртуальных вычислительных узлов прирост потребления процессорных ресурсов в Docker зафиксирован в 26 раз ниже, чем в KVM, а прирост потребления ресурсов оперативной памяти — втрое ниже[15].
С 2017 года вдобавок к свободно распространяемой под лицензией Apache 2.0 редакции продукта выпускается редакция для организаций, продаваемая по ценам от $750 до $2 тыс. в год на узел в зависимости от доступных функций[9].
Источники
docker pull
чтобы скачать образ busybox.docker run
, и использовали образ busybox, скачанный ранее. Список запущенных контейнеров можно увидеть с помощью команды docker ps
.Стенд на VPS Singularity (2 CPU, 4 GB RAM, 50 GB NVMi SSD)
liv@singularity:~$ hostnamectl
Static hostname: singularity
Icon name: computer-vm
Chassis: vm
Machine ID: c3f3c2a325254275b58ddc82c9068b5c
Boot ID: d12220948d0540a78e3b43fe8fe70c81
Virtualization: kvm
Operating System: Ubuntu 22.04.4 LTS
Kernel: Linux 5.15.0-100-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _i440FX + PIIX, 1996_
liv@singularity:~$ docker --version
Docker version 25.0.4, build 1a576c5
liv@singularity:~$ docker compose version
Docker Compose version v2.24.7
Portainer - панель управления Docker
docker volume create portainer_data
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce
1. Docker удобен для организации процесса разработки ПО в команде разработчиков + DevOps-инженеров там, где важна минимизация времени от изменения кода до ввода его в эксплутацию у клиентов.
2. Процесс разработки новых версий ПО можно свести к разработке и публикации нового образа с сервисом в публичном или приватном репозитории образов.
3. Разработчк может организовать себе быстро личный стенд для разработки своей части кода без влияния на других разработчков.
Подробные заметки - https://github.com/IgorLytkin/docker.md
Гра́фовая база данных — разновидность баз данных с реализацией сетевой модели в виде графа и его обобщений.
Графовая СУБД — система управления графовыми базами данных.
Модель хранения информации в виде графов, графов со свойствами в узлах и гиперграфов сложилась в 1990—2000 годах[1], хотя использование графов в виде модели представления данных сложилось ещё с 1980-х годов[1]. Первая графовая СУБД Neo4j создана в 2007 году. По состоянию на начало 2020-х годов существуют десятки других графовых СУБД.
Графовую модель данных обычно рассматривают как обобщение RDF-модели или сетевой модели данных[1]. Основными элементами модели являются узлы и связи. В зависимости от реализации узлов и рёбер графовую модель данных разделяют на несколько подтипов.
В графовых СУБД, как правило, разделяют подсистему хранения (англ. underlying storage) и механизм обработки (англ. processing engine)[2].
Для аналитической работы с большими объёмами данных в глобальных графах применяются специализированные механизмы графовых вычислений (англ. graph compute engine). В отличие от графовых СУБД, ориентированных в основном на OLTP-приложения, в системах графовых вычислений используются подходы и методы оптимизации, свойственные OLAP. Существуют различные реализации механизмов для графовых вычислений, как резидентные (англ. in-memory), так и использующие энергонезависимые устройства хранения, как работающие на одном узле, так и распределённые (работающие на нескольких узлах одновременно)[2].
Графовые базы данных применяются для моделирования социальных графов (социальных сетей)[3], в биоинформатике, а также для семантической паутины[4]. Для задач с естественной графовой структурой данных графовые СУБД могут существенно превосходить реляционные по производительности, а также иметь преимущества в наглядности представления и простоте внесения изменений в схему базы данных[5].
Источник: Графовая база данных
Neo4j — это графовая система управления базами данных с открытым исходным кодом, реализованная на Java. Она является ведущей графовой СУБД в мире. Аналогами Neo4j являются Oracle NoSQL Database, HypherGraphDB, GraphBase, InfiniteGraph и AllegroGraph.
1. Википедия
2. habr.com
3. Книги
4. Сообщества Neo4j
Окружение:
В окне Терминала, под администратором
setx NEO_DATA "C:\Neo4j\neo4jDatabases" /M
В окне Git Bash
$docker system prune
$docker pull neo4j:enterprise
$printenv | grep NEO
$cd $NEO_DATA
$mkdir docker-container1 && cd docker-container1 && mkdir import && mkdir data
$CONTAINER=$(docker run -d --name neo4j -p 7474:7474 -p 7867:7867 -v $NEO_DATA/docker-container1/data:/data -v $NEO_DATA/docker-container1/import:/var/lib/neo4j/import --env=NEO4J_ACCEPT_LICENSE_AGREEMENT=eval neo4j)
$echo "Running Neo4j as $CONTAINER, waiting for startup"
$docker ps
Консоль Neo4j http://localhost:7474
Логин по умолчанию neo4j, пароль neo4j
wget -O - https://debian.neo4j.com/neotechnology.gpg.key | sudo apt-key add - echo 'deb https://debian.neo4j.com stable latest' | sudo tee /etc/apt/sources.list.d/neo4j.list sudo apt-get update
liv@singularity:~$ sudo apt list -a neo4j
Listing... Done
neo4j/stable,now 1:5.13.0 all [installed]
neo4j/stable 1:5.12.0 all
neo4j/stable 1:5.11.0 all
neo4j/stable 1:5.10.0 all
neo4j/stable 1:5.9.0 all
neo4j/stable 1:5.8.0 all
neo4j/stable 1:5.7.0 all
neo4j/stable 1:5.6.0 all
neo4j/stable 1:5.5.0 all
neo4j/stable 1:5.4.0 all
neo4j/stable 1:5.3.0 all
neo4j/stable 1:5.2.0 all
neo4j/stable 1:5.1.0 all
liv@singularity:~$ sudo neo4j-admin server report
liv@singularity:~$ sudo systemctl status neo4j.service
liv@igor2024:~$ sudo systemctl status neo4j.service
● neo4j.service - Neo4j Graph Database
Loaded: loaded (/lib/systemd/system/neo4j.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2024-01-24 21:35:35 +07; 8h ago
Main PID: 6784 (java)
Tasks: 86 (limit: 4483)
Memory: 614.3M
CPU: 10min 38.680s
CGroup: /system.slice/neo4j.service
├─6784 /usr/bin/java -Xmx128m -classpath "/usr/share/neo4j/lib/*:/usr/share/neo4j/etc:/usr/share/neo4j/repo/*" -Dapp.name=neo4j -Dapp.pid=6784 -Dapp.repo=/usr/share/neo4j/repo -Dapp.home=/usr/sha>
└─6814 /usr/lib/jvm/java-21-openjdk-amd64/bin/java -cp "/var/lib/neo4j/plugins/*:/etc/neo4j/*:/usr/share/neo4j/lib/neo4j-cypher-planner-5.16.0.jar:/usr/share/neo4j/lib/neo4j-slf4j-provider-5.16.0>
янв 24 21:35:43 igor2024 neo4j[6814]: 2024-01-24 14:35:43.975+0000 INFO ======== Neo4j 5.16.0 ========
янв 24 21:35:47 igor2024 neo4j[6814]: 2024-01-24 14:35:47.841+0000 INFO Bolt enabled on 0.0.0.0:7687.
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.222+0000 INFO HTTP enabled on 0.0.0.0:7474.
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.223+0000 INFO Remote interface available at http://localhost:7474/
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.229+0000 INFO id: D004B4A9E6E6C112506DB506298CD484E929CB7A859E6B5DF82223B116F15179
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.230+0000 INFO name: system
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.231+0000 INFO creationDate: 2024-01-24T14:35:03.125Z
янв 24 21:35:49 igor2024 neo4j[6814]: 2024-01-24 14:35:49.232+0000 INFO Started.
liv@igor2024:~$ sudo neo4j-admin server report
Finding running instance of neo4j
Attached to running process with process id 6814
Connected to JMX endpoint
Writing report to /tmp/reports/igor2024-2024-01-25_062731.zip
1/11 [####################] 100% logs/http.log
2/11 [####################] 100% logs/debug.log
3/11 [####################] 100% logs/neo4j.log
4/11 [####################] 100% plugins.txt
5/11 [####################] 100% system/tree.txt
6/11 [####################] 100% neo4j/tree.txt
7/11 [####################] 100% version.txt
8/11 [####################] 100% vm.prop
9/11 [####################] 100% ps.csv
10/11 [####################] 100% threaddump.txt
11/11 [####################] 100% config/neo4j.conf
liv@singularity:~$ docker volume create portainer_data
portainer_data
liv@singularity:~$ docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce
liv@singularity:~$docker pull neo4j
liv@singularity:~$ docker run -d --publish=7474:7474 --publish=7687:7687 --volume=$HOME/neo4j/data:/data neo4j
1b8b1567541e01b2abd3ad8dcb440625c01bb5a262ceb61d5bc1c08e4af1616e
pskill64.exe ssh.exe
start ssh -fNL 7687:localhost:7687 -v -i "D:\Yandex\igor.lytkin.2020\YandexDisk\Singularity\Keys\2023\rsa\ssh_host_rsa_key"
start ssh -fNL 7687:localhost:7687 -v -i "D:\Yandex\igor.lytkin.2020\YandexDisk\Igor2024\id_rsa"
pip install neo4j
from neo4j import GraphDatabase
class HelloWorldExample:
def __init__(self, uri, user, password):
self.driver = GraphDatabase.driver(uri, auth=(user, password))
def close(self):
self.driver.close()
def print_greeting(self, message):
with self.driver.session() as session:
greeting = session.execute_write(self._create_and_return_greeting, message)
print(greeting)
@staticmethod
def _create_and_return_greeting(tx, message):
result = tx.run("CREATE (a:Greeting) "
"SET a.message = $message "
"RETURN a.message + ', from node ' + id(a)", message=message)
return result.single()[0]
if __name__ == "__main__":
greeter = HelloWorldExample("bolt://localhost:7687", "neo4j", "password")
greeter.print_greeting("hello, world")
greeter.close()
Property graph model conceptsBasic concepts to get you going |
Концепции графовой модели свойств |
A graph database can store any kind of data using a few basic concepts:
|
Графическая база данных может хранить любые данные, используя несколько основных концепций: |
NodesNeo4j stores data in a graph as nodes The simplest graph has just a single node with some named values called properties. For example, let's draw a social graph:
Key info:
|
Узлы Простейший граф имеет только один узел с некоторыми именованными значениями, называемыми свойствами. Например, давайте нарисуем социальный график: 1. Нарисуйте круг для узла. 2. Добавьте имя Эмиль. 3. Обратите внимание, что он из Швеции. Ключевая информация: • Узлы часто представляют сущности или дискретные объекты, которые могут быть классифицированы с нулем или более меток. • Данные хранятся в виде свойств узлов. • Свойства представляют собой простые пары ключ-значение. |
LabelsAssociate a set of nodes Nodes can be grouped together by applying a Label to each member. In this social graph, you label each node that represents a Person.
|
Метки Узлы можно сгруппировать вместе, применив метку к каждому элементу. На этом социальном графе вы помечаете каждый узел, представляющий человека.
|
More NodesNeo4j is schema-free Like any database, storing data in Neo4j can be as simple as adding more nodes. Nodes can have a mix of common and unique properties. Add a few more nodes and properties:
Key info:
|
Больше узлов
Ключевая информация:
|
RelationshipsConnect the nodes The real power of Neo4j is in connected data. To associate any two nodes, add a relationship that describes how the records are related. In our social graph, you can simply say who knows (relationship type KNOWS) whom:
Key info:
|
Отношения
Ключевая информация:
|
Relationship propertiesStore information shared by two nodes In a property graph, relationships can also contain properties that describe the relationship. Looking more closely at Emil's relationships, note that:
Key info:
|
Свойства взаимосвязи В графе свойств взаимосвязи также могут содержать свойства, описывающие взаимосвязь. Рассматривая более внимательно отношения Эмили, обратите внимание, что: • Эмиль знаком с Йоханом с 2001 года. • Эмиль оценивает Яна на 5 (из 5). • У всех остальных могут быть похожие свойства отношений. Ключевая информация: • Отношения всегда имеют определенное направление. • Отношения всегда имеют определенный тип. • Взаимосвязи формируют шаблоны данных, структуру графика. |
Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым. Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP. Поддерживает несколько видов мониторинга:
Zabbix начался в 1998 году как внутренний проект в латвийском банке.
7 апреля 2001 года система была выпущена публично под лицензией GPL[6], первая стабильная версия — 1.0 от 23 марта 2004[6]. В апреле 2005 года была создана латвийская компания SIA Zabbix для управления проектом[7]. Практически ежегодно выпускаются новые версии системы, крупные выпуски: 2.0 (2012), 3.0 (2016), 4.0 (2018), 5.0 (2020), 6.0 (2022).
wget https://repo.zabbix.com/zabbix/6.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.0-1+ubuntu20.04_all.deb
dpkg -i zabbix-release_6.0-1+ubuntu20.04_all.deb
apt update
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix Zabbix
zcat /usr/share/doc/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql Zabbix
/etc/zabbix/zabbix_server.conf
DBPassword=zabbix
Файлы журналов
/var/log/zabbix/zabbix_agentd.log
/var/log/zabbix/zabbix_server.log
Останов Zabbix server
liv@singularity:~$ service zabbix-server stop
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to stop 'zabbix-server.service'.
Multiple identities can be used for authentication:
1. Igor Lytkin,,, (liv)
2. PostgreSQL,,, (postgres)
Choose identity to authenticate as (1-2): 1
Password:
==== AUTHENTICATION COMPLETE ===
Back up the existing Zabbix database:
Back up configuration files, PHP files and Zabbix binaries:
sudo rm -r /opt/zabbix-backup/
sudo mkdir /opt/zabbix-backup/
sudo cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup/
sudo cp /etc/apache2/conf-enabled/zabbix.conf /opt/zabbix-backup/
liv@singularity:~$ ls -la /opt/zabbix-backup/
total 40
drwxr-xr-x 2 root root 4096 Mar 24 03:56 .
drwxr-xr-x 4 root root 4096 Mar 24 03:56 ..
-rw-r--r-- 1 root root 1743 Mar 24 03:56 zabbix.conf
-rw------- 1 root root 27272 Mar 24 03:56 zabbix_server.conf
sudo cp -R /usr/share/zabbix/ /opt/zabbix-backup/
sudo cp -R /usr/share/zabbix-* /opt/zabbix-backup/
liv@singularity:~$ ls /etc/apt/sources.list.d/zabbix.list
/etc/apt/sources.list.d/zabbix.list
liv@singularity:~$ cat /etc/apt/sources.list.d/zabbix.list
# Zabbix main repository
deb https://repo.zabbix.com/zabbix/6.2/ubuntu jammy main
deb-src https://repo.zabbix.com/zabbix/6.2/ubuntu jammy main
# Zabbix unstable repository
#deb https://repo.zabbix.com/zabbix/6.1/ubuntu jammy main
#deb-src https://repo.zabbix.com/zabbix/6.1/ubuntu jammy main
sudo rm -Rf /etc/apt/sources.list.d/zabbix.list
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
liv@singularity:~$ wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
--2023-03-24 04:03:35-- https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
Resolving repo.zabbix.com (repo.zabbix.com)... 178.128.6.101, 2604:a880:2:d0::2062:d001
Connecting to repo.zabbix.com (repo.zabbix.com)|178.128.6.101|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3744 (3.7K) [application/octet-stream]
Saving to: ‘zabbix-release_6.4-1+ubuntu22.04_all.deb’
zabbix-release_6.4-1+ubuntu22.04_a 100%[==============================================================>] 3.66K --.-KB/s in 0s
2023-03-24 04:03:36 (1.12 GB/s) - ‘zabbix-release_6.4-1+ubuntu22.04_all.deb’ saved [3744/3744]
sudo dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
liv@singularity:~$ sudo dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
(Reading database ... 286987 files and directories currently installed.)
Preparing to unpack zabbix-release_6.4-1+ubuntu22.04_all.deb ...
Unpacking zabbix-release (1:6.4-1+ubuntu22.04) over (1:6.2-4+ubuntu22.04) ...
Setting up zabbix-release (1:6.4-1+ubuntu22.04) ...
Configuration file '/etc/apt/sources.list.d/zabbix.list'
==> Deleted (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** zabbix.list (Y/I/N/O/D/Z) [default=N] ? D
*** zabbix.list (Y/I/N/O/D/Z) [default=N] ? D
--- /etc/apt/sources.list.d/zabbix.list 1970-01-01 07:00:00.000000000 +0700
+++ /etc/apt/sources.list.d/zabbix.list.dpkg-new 2023-03-06 23:19:30.000000000 +0700
@@ -0,0 +1,7 @@
+# Zabbix main repository
+deb https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
+deb-src https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
+
+# Zabbix unstable repository
+#deb https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
+#deb-src https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
*** zabbix.list (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/apt/sources.list.d/zabbix.lis
sudo cat /etc/apt/sources.list.d/zabbix.list
liv@singularity:~$ ls -la /etc/apt/sources.list.d/zabbix.list
-rw-r--r-- 1 root root 293 Mar 6 23:19 /etc/apt/sources.list.d/zabbix.list
liv@singularity:~$ cat /etc/apt/sources.list.d/zabbix.list
# Zabbix main repository
deb https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
deb-src https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
# Zabbix unstable repository
#deb https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
#deb-src https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
liv@singularity:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Get:3 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:4 https://repo.zabbix.com/zabbix-agent2-plugins/1/ubuntu jammy InRelease [4,952 B]
Get:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [107 kB]
Get:6 http://apt.postgresql.org/pub/repos/apt jammy-pgdg InRelease [91.6 kB]
Get:7 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [949 kB]
Get:8 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy InRelease [4,958 B]
Get:9 http://archive.ubuntu.com/ubuntu jammy-updates/main Translation-en [205 kB]
Get:10 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 DEP-11 Metadata [101 kB]
Get:11 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 c-n-f Metadata [13.8 kB]
Get:12 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [895 kB]
Get:13 http://archive.ubuntu.com/ubuntu jammy-updates/universe Translation-en [179 kB]
Get:14 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 DEP-11 Metadata [269 kB]
Get:15 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 c-n-f Metadata [18.4 kB]
Get:16 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages [693 kB]
Get:17 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 DEP-11 Metadata [940 B]
Get:18 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 DEP-11 Metadata [7,980 B]
Get:19 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [19.5 kB]
Get:20 http://archive.ubuntu.com/ubuntu jammy-backports/universe Translation-en [14.0 kB]
Get:21 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 DEP-11 Metadata [12.5 kB]
Get:22 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 c-n-f Metadata [392 B]
Get:23 http://security.ubuntu.com/ubuntu jammy-security/main Translation-en [143 kB]
Get:24 http://security.ubuntu.com/ubuntu jammy-security/main amd64 DEP-11 Metadata [41.4 kB]
Get:25 http://security.ubuntu.com/ubuntu jammy-security/main amd64 c-n-f Metadata [9,016 B]
Get:26 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 Packages [645 kB]
Get:27 http://security.ubuntu.com/ubuntu jammy-security/restricted Translation-en [100 kB]
Get:28 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 c-n-f Metadata [588 B]
Get:29 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages [714 kB]
Get:30 http://security.ubuntu.com/ubuntu jammy-security/universe Translation-en [118 kB]
Get:31 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 DEP-11 Metadata [18.5 kB]
Get:32 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main Sources [1,939 B]
Get:33 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 c-n-f Metadata [14.1 kB]
Get:34 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 Packages [19.4 kB]
Get:35 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 c-n-f Metadata [228 B]
Get:36 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 Packages [5,490 B]
Fetched 5,646 kB in 2s (2,544 kB/s)
Reading package lists... Done
1. Сгенерировать пароль в Kaspersky Password Manager (KPM), записать в KPM (99 символов!).
2. Отредактировать файл конфигурации сервера Zabbix
liv@singularity:~$ sudo nano /etc/zabbix/zabbix_server.conf
- заменить DBPassword=KPM(zabbix)
3. Отредактировать файл конфигурации Zabbix GUI configuration file (спасибо, Silver_47, за решение!)
liv@singularity:~$ sudo nano /etc/zabbix/web/zabbix.conf.php
- заменить $DB['PASSWORD'] = 'KPM(zabbix)';
4. Отредактировать файл конфигурации СУБД PostgreSQL
liv@singularity:~$ sudo nano /etc/postgresql/15/main/pg_hba.conf
добавить строку
local zabbix zabbix md5
5. Запустить СУБД, сервер Zabbix
liv@singularity:~$ sudo pg_ctlcluster 15 main start
liv@singularity:~$ sudo systemctl start zabbix-server.service
liv@singularity:~$ zabbix_server -V
zabbix_server (Zabbix) 6.4.0
Revision 5b2736b6027 6 March 2023, compilation time: Mar 3 2023 14:35:33
Copyright (C) 2023 Zabbix SIA
License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/>.
This is free software: you are free to change and redistribute it according to
the license. There is NO WARRANTY, to the extent permitted by law.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/).
Compiled with OpenSSL 3.0.2 15 Mar 2022
Running with OpenSSL 3.0.2 15 Mar 2022
Восстановил файл zabbix.list
sudo nano /etc/apt/sources.list.d/zabbix.list
# Zabbix main repository
deb https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
deb-src https://repo.zabbix.com/zabbix/6.4/ubuntu jammy main
# Zabbix unstable repository
#deb https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
#deb-src https://repo.zabbix.com/zabbix/6.3/ubuntu jammy main
Проверка обновлений
liv@singularity:~$ sudo apt list --upgradable
Listing... Done
zabbix-agent/jammy 1:6.4.12-1+ubuntu22.04 amd64 [upgradable from: 1:6.4.0-1+ubuntu22.04]
zabbix-apache-conf/jammy 1:6.4.12-1+ubuntu22.04 all [upgradable from: 1:6.4.0-1+ubuntu22.04]
zabbix-frontend-php/jammy 1:6.4.12-1+ubuntu22.04 all [upgradable from: 1:6.4.0-1+ubuntu22.04]
zabbix-server-pgsql/jammy 1:6.4.12-1+ubuntu22.04 amd64 [upgradable from: 1:6.4.0-1+ubuntu22.04]
zabbix-sql-scripts/jammy 1:6.4.12-1+ubuntu22.04 all [upgradable from: 1:6.4.0-1+ubuntu22.04]
zabbix-web-service/jammy 1:6.4.12-1+ubuntu22.04 amd64 [upgradable from: 1:6.4.0-1+ubuntu22.04]
liv@singularity:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
zabbix-agent zabbix-apache-conf zabbix-frontend-php zabbix-server-pgsql zabbix-sql-scripts zabbix-web-service
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.4 MB of archives.
After this operation, 714 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-server-pgsql amd64 1:6.4.12-1+ubuntu22.04 [1,486 kB]
Get:2 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-agent amd64 1:6.4.12-1+ubuntu22.04 [264 kB]
Get:3 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-frontend-php all 1:6.4.12-1+ubuntu22.04 [7,285 kB]
Get:4 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-apache-conf all 1:6.4.12-1+ubuntu22.04 [8,176 B]
Get:5 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-sql-scripts all 1:6.4.12-1+ubuntu22.04 [7,702 kB]
Get:6 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-web-service amd64 1:6.4.12-1+ubuntu22.04 [2,632 kB]
Fetched 19.4 MB in 3s (5,625 kB/s)
(Reading database ... 278575 files and directories currently installed.)
Preparing to unpack .../0-zabbix-server-pgsql_1%3a6.4.12-1+ubuntu22.04_amd64.deb ...
Unpacking zabbix-server-pgsql (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Preparing to unpack .../1-zabbix-agent_1%3a6.4.12-1+ubuntu22.04_amd64.deb ...
Unpacking zabbix-agent (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Preparing to unpack .../2-zabbix-frontend-php_1%3a6.4.12-1+ubuntu22.04_all.deb ...
Unpacking zabbix-frontend-php (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Preparing to unpack .../3-zabbix-apache-conf_1%3a6.4.12-1+ubuntu22.04_all.deb ...
Unpacking zabbix-apache-conf (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Preparing to unpack .../4-zabbix-sql-scripts_1%3a6.4.12-1+ubuntu22.04_all.deb ...
Unpacking zabbix-sql-scripts (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Preparing to unpack .../5-zabbix-web-service_1%3a6.4.12-1+ubuntu22.04_amd64.deb ...
Unpacking zabbix-web-service (1:6.4.12-1+ubuntu22.04) over (1:6.4.0-1+ubuntu22.04) ...
Setting up zabbix-sql-scripts (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-frontend-php (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-server-pgsql (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-web-service (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-agent (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-apache-conf (1:6.4.12-1+ubuntu22.04) ...
Processing triggers for man-db (2.10.2-1) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Restarting services...
systemctl restart zabbix-server.service
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
Установка Zabbix-агента версии 2
liv@singularity:~$ sudo apt install zabbix-agent2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
zabbix-agent2
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,124 kB of archives.
After this operation, 17.1 MB of additional disk space will be used.
Get:1 https://repo.zabbix.com/zabbix/6.4/ubuntu jammy/main amd64 zabbix-agent2 amd64 1:6.4.12-1+ubuntu22.04 [5,124 kB]
Fetched 5,124 kB in 3s (2,048 kB/s)
Selecting previously unselected package zabbix-agent2.
(Reading database ... 278575 files and directories currently installed.)
Preparing to unpack .../zabbix-agent2_1%3a6.4.12-1+ubuntu22.04_amd64.deb ...
Unpacking zabbix-agent2 (1:6.4.12-1+ubuntu22.04) ...
Setting up zabbix-agent2 (1:6.4.12-1+ubuntu22.04) ...
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent2.service → /lib/systemd/system/zabbix-agent2.service.
Processing triggers for man-db (2.10.2-1) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
ФинТех Хаб - подразделение Департамента финансовых технологий Банка России. Руководитель - Наталия Ицкович (ЦБ), курс читают Адель Валлиулин, Элизавета Вялых (Газпромбанк Тех).
URL https://finclass.teachbase.ru/program_sessions/30479/detail/content
Адель Валиуллин, начальник Центра Технологий Искусственного Интеллекта Газпромбанк.Тех, преподаватель курсов по ИИ и машинному обучению на ФКН ВШЭ, в МГТУ им. Н.Э. Баумана и Сириусе. Адель с отличием окончил факультет Робототехники и Комплексной Автоматизации МГТУ им.Н.Э.Баумана.
⭐️ Интересный факт: Адель входит в топ-100 международного рейтинга Kaggle специалистов по машинному обучению (максимальный рейтинг 68), а также является победителем и призером международных и российских хакатонов по машинному обучению и ИИ.
➡️ Подробнее про путь в Kaggle можете узнать тут. https://tproger.ru/articles/kak-stat-top-100-na-kaggle-i-topovym-data-scientist-om-za-kotorym-ohotyatsya-rabotodateli
Адель считает: "Если человек смог уместить в голове большую сложную теорию из математики или физики, то и в бизнесе он сможет делать интересные полезные выводы, поэтому в банке очень любят ребят с сильным фундаментальным образованием"
Элизавета Вялых, аналитик-исследователь Центра Технологий Искусственного Интеллекта Газпромбанк.Тех.
🔖 Самая крутая вещь по мнению Элизы: опыт из одной области можно экстраполировать на другие области. На первом курсе Элиза работала в венчурном фонде и прокачала свои soft skills, затем — в стартапе, где построила свою первую ML-модель.
▶️После большого количества научных лабораторий МФТИ, роботов, дронов, двигателей, оптико-электронных приборов, дошла до Газпромбанка. Сейчас работает в заряженной команде с супер-крутыми специалистами Центра ИИ технологий.
Совет Элизы участникам программы: "Чем больше новых действий вы выполняете ежедневно, тем больше мозг создает нейронных связей и тем проще становится придумывать новые идеи".
Мои репозитории на GitHub по ML
Линейная регрессия - это регрессионный алгоритм для машинного обучения, в то время как логистическая регрессия - это алгоритм классификации для машинного обучения. Логистическая регрессия основана на логистической функции (она же сигмоидная функция), которая принимает значение и присваивает ему вероятность от 0 до 1.
Линейная регрессия - это широко используемый статистический метод, который используется для моделирования взаимосвязи между зависимой переменной и одной или несколькими независимыми переменными. Линейная регрессия имеет ряд преимуществ, таких как простота и понятность, возможность моделировать как простые, так и сложные наборы данных и возможность делать прогнозы относительно зависимой переменной на основе значений независимых переменных.
Ядро Ubuntu построено на основе snaps, безопасного, ограниченного, свободного от зависимостей кроссплатформенного формата упаковки Linux.
Привязки являются автономными, что означает, что они, возможно, включают в себя все необходимое для запуска или использования компонентов из других привязок ограниченным и контролируемым образом. Они используются Ubuntu Core как для создания образа, запускаемого на устройстве, так и для доставки последовательных и надежных обновлений программного обеспечения, часто для маломощных, недоступных и удаленно администрируемых встроенных систем и систем интернета вещей.
Будь то обновление для отдельного устройства, определенного подмножества устройств или развертывание десятков тысяч устройств, привязки позволяют ядру Ubuntu поддерживать и проверять целостность системы:
Автономные обновления для любого устройства: служба обновлений должна быть надежным и автоматическим процессом, обеспечивающим предсказуемую частоту обновлений и необязательный высокий уровень контроля над тем, когда и как доставляются обновления
Неполное и проблемное восстановление обновлений: из-за недоступности многих установок встроенных устройств крайне важно, чтобы обновления были надежными и могли выдерживать сбои, блокировки, частичные и прерываемые обновления
Предоставление критических обновлений: в определенных обстоятельствах, когда необходимо выполнить разовое или критическое обновление, система обновлений должна отдать им приоритет и включить обновление обратно в службу регулярных обновлений
Непредсказуемые условия работы оборудования и сети: в ситуациях, которые нелегко смоделировать или спрогнозировать, любая система обновления должна иметь достаточную избыточность для обработки отката, начальной загрузки без подключения к сети и автономной повторной подготовки
Экосистема упаковки snap состоит из следующих частей:
Разработчики могут публиковать снимки в Snap Store или в своем собственном фирменном магазине. Они несут единоличную ответственность за частоту обновления и качество. Хотя привязки обычно известны как формат упаковки приложений, ядро Ubuntu построено из нескольких различных типов привязок:
Как и в случае с основной файловой системой, привязки предоставляются системе только для чтения и им предоставляется доступ к любым необходимым ресурсам через набор явных разрешений, известных как интерфейсы. Интерфейсы реализованы с использованием хорошо протестированных функций ограничения ядра Linux.
Snaps - это пакеты приложений Linux для рабочего стола, облака и Интернета вещей, которые являются автономными, простыми в установке, безопасными, кроссплатформенными и не содержат зависимостей.
Они обновляются автоматически и обычно выполняются в ограниченной среде, основанной на транзакциях. Безопасность и надежность являются их ключевыми характеристиками, наряду с простотой установки, простотой обслуживания и простотой обновления.
Snaps помогают пользователям настольных компьютеров без особых усилий устанавливать и запускать приложения, такие как Spotify или Slack. Они помогают системным администраторам запускать такие серверы, как NextCloud, разработчикам упаковывать и распространять свою работу в глобальном Snap Store, а также помогают всем создавать и развертывать устройства Интернета вещей под управлением Ubuntu Core.
Snap справится с этим - от разработчиков Linux и maker space до робототехники, автомобилестроения и индустрии вывесок; от вашего рабочего стола до тысяч развертываний.
Наши пояснительные и концептуальные руководства написаны для лучшего понимания того, как работают snap и snap daemon (snapd). Они позволяют вам расширить свои знания и стать лучше как в создании снимков, так и в получении максимальной отдачи от экосистемы snap.
Ограничение доступа Snap определяет объем доступа приложения к системным ресурсам, таким как файлы, сеть, периферийные устройства и службы. Существует несколько уровней ограничения.
Ограничение доступа гарантирует, что отдельные части программного обеспечения не влияют на надежность системы пользователя и не вызывают проблем с другими приложениями. В результате, когда пользователь запускает snap, предоставляемое им программное обеспечение в некоторой степени изолировано от системы, причем по умолчанию доступ ограничен строгим минимумом функций.
Уровень ограничения доступа к snap определяет степень его изоляции от системы пользователя. Разработчики приложений или разработчики пакетов могут настроить уровень ограничения, чтобы в общих чертах указать, какой объем доступа к системным ресурсам требуется приложению либо для обычного использования, либо во время разработки.
Для опубликованных снимков существует два уровня ограничения привязки:
--classic
аргумент командной строки.Дополнительный режим полезен в процессе разработки:
--devmode
аргумент командной строки. Снимки в режиме разработки не могут быть опубликованы на стабильном канале, не отображаются в результатах поиска и не обновляются автоматически.Строгое ограничение доступа использует функции безопасности ядра Linux, включая AppArmor, seccomp и пространства имен, для предотвращения доступа приложений и служб к более широкой системе.
Используйте команду snap
, чтобы определить уровень ограничения доступа для привязки:
$ snap info --verbose vlc
[...]
confinement: strict
devmode: false
[...]
Чтобы узнать, в каких установленных привязках используется классическое ограничение, найдите classic в столбце Примечания в выходных данных snap list
:
$ snap list
Name Version Rev Tracking Publisher Notes
vlc 3.0.6 770 stable videolan✓ -
code 0dd516dd 5 stable vscode✓ classic
wormhole 0.11.2 112 stable snapcrafters -
Привязки со строгим ограничением доступа должны использовать интерфейсы для доступа к ресурсам в системе пользователя, включая те, которые предоставляются другими привязками.
Привязки обновляются автоматически, и по умолчанию демон snapd проверяет наличие обновлений 4 раза в день. Каждая проверка обновления называется обновлением и более подробно описана в разделе Управление обновлениями.
Если обновление происходит во время работы затронутого настольного приложения, обновление информации о приложении помогает устранить любые потенциальные проблемы, используя комбинацию обновлений на месте, отличающихся обновлений и уведомлений на рабочем столе.
Для обновления информации требуется snapd 2.57+
На управление службами это не влияет, поскольку службы запускаются и останавливаются вручную как часть процесса обновления, если только разработчиком snap в snap не было встроено определенное значение endure. Дополнительные сведения см. в разделе Службы и демоны.
Если приложение запущено, когда автоматическое обновление обнаруживает обновление, новая версия snap загружается в фоновом режиме, чтобы сократить время обновления. По завершении загрузки пользователь получает уведомление о ожидающем обновлении, и при остановке приложения запускается мгновенное обновление. После обновления snap дополнительное уведомление информирует пользователя о том, что новая версия snap готова к использованию (требуется snapd 2.59.2+). Обновления на месте работают только с автоматическими обновлениями, а не при запуске обновления вручную.
Обновление может быть отложено на срок до 14 дней для запущенного приложения. Обновление будет применено либо при закрытии приложения, при следующем автоматическом обновлении без запуска приложения, либо через 14 дней, даже если приложение остается активным.
После закрытия затронутого приложения обновление может быть запущено вручную с помощью команды snap refresh
, либо глобально для всех снимков, либо с использованием определенного имени снимка:
snap refresh <snap-name>
Если при ручном обновлении будет обнаружено, что приложение все еще запущено, вывод ошибки будет включать обнаруженные идентификаторы процессов запущенных приложений:
error: cannot refresh "firefox": snap "firefox" has running apps (firefox), pids:
1639,1854,1912,1932,3514,3632,5814,5870
См. раздел Управление обновлениями для получения более подробной информации об управлении частотой обновлений и сохранении обновлений в течение любого периода времени.
Пока запущено уязвимое приложение, при каждой попытке обновления на рабочем столе будет появляться уведомление, информирующее пользователя о том, что приложение следует закрыть во избежание сбоев.
На рабочем столе Ubuntu GNOME по умолчанию уведомления можно изменять и отключать, выбрав "Уведомления" в приложении "Настройки" и выбрав приложение "
Каналы
Полное название канала может состоять из трех отдельных частей, разделенных косой чертой:
<track>/<risk>/<branch>
Значение отслеживания для установленной привязки, показанное в выходных данных snap list
команды, показывает, какой канал установлен и отслеживается для этой привязки.
Все снимки имеют дорожку по умолчанию. Если разработчик snap не укажет иное, дорожка по умолчанию называется последней. Аналогично, если дорожка не указана, snap будет неявно устанавливаться с последней дорожки. Дорожка также может быть указана явно:
snap install vlc --channel=latest/edge
Разработчики могут по желанию выбрать, следует ли дополнять последнюю дорожку по умолчанию дополнительными дорожками. Разработчик также волен назначить одну из них в качестве дорожки по умолчанию для установки, если нет дополнительных предпочтений.
Программа Microsoft Skype snap является хорошим примером того, как можно использовать треки. Он содержит два трека: последний трек по умолчанию для большинства пользователей и внутренний трек для команды Microsoft по контролю качества и пользователей, заинтересованных в тестировании последних разработок Skype перед выпуском стабильного выпуска.
Аналогичным образом, трек также может использоваться для отслеживания незначительных обновлений (2.0.1, 2.0.2), основных обновлений (2.1, 2.2) или выпусков, предназначенных для долгосрочной поддержки (3.2, 4.1).
Треки перечислены в разделе "Каналы" выходных данных snap info
команды:
$ snap info skype
[...]
channels:
stable: 8.28.0.41 (51) 148MB classic
candidate: ↑
beta: ↑
edge: ↑
insider/stable: 8.30.76.41 (53) 151MB classic
insider/candidate: ↑
insider/beta: ↑
insider/edge: ↑
[...]
В приведенных выше выходных данных snap для Skype включает пользовательский трек для insider. Вы также можете посмотреть, какие треки поддерживает snap, выбрав Другие версии в разделе "Онлайн-магазин".
Чтобы установить Skype из его внутренней дорожки, например, используйте следующую команду:
snap install skype --channel=insider/stable
Пользователь, у которого уже установлен Skype, может переключать каналы с помощью команды snap refresh
:
snap refresh skype --channel=insider/stable
В качестве альтернативы, если используется программное обеспечение GNOME, выберите ‘стабильный’ канал на странице магазина Skype и выберите канал для переключения.
В настоящее время разработчики должны отправить запрос на добавление треков в их snap через категорию форума #store-requests. Релизы проверяются, чтобы гарантировать соответствие разумным ожиданиям пользователей. Например, для трека 3.2 принимаются только версии 3.2.*.
Существует четыре уровня риска: стабильный, кандидатный, бета-версия и edge. Они представляют собой снижающиеся уровни стабильности для snap, хотя в конечном итоге это решение остается за издателем snap. Установка с менее стабильным уровнем риска обычно означает, что обновления для snap будут выполняться чаще, чем для более стабильного уровня риска.
Уровни риска имеют следующее значение:
стабильный: для подавляющего большинства пользователей, работающих в производственных средах.
Выпуски с таким уровнем риска максимально стабильны в соответствии со стандартами проекта. Важное программное обеспечение достигнет этой стадии только после того, как оно будет готово к использованию в производстве и его можно будет использовать в продуктах. Подразумевается обещание избегать любых изменений, которые могли бы нарушить эти обычаи.
кандидат: для пользователей, которым необходимо протестировать обновления перед стабильным развертыванием, или для тех, кто проверяет, решена ли конкретная проблема.
Версии-кандидаты считаются почти готовыми к запуску в стабильную версию, но для их дальнейшего продвижения требуются некоторые дополнительные эксперименты в реальном мире. Программное обеспечение, достигающее этой стадии, как правило, прошло все доступные процессы контроля качества и проверки, поскольку пользователи, следующие ему, ожидают высокого уровня стабильности. Оно практически никогда не должно ломаться.
бета: для пользователей, желающих протестировать новейшие функции, как правило, вне производственной среды.
Бета-версия - это первый уровень стабилизации того, что было до быстрого потока изменений. В конкретных проектах может немного отличаться терминология для таких выпусков (альфа, бета и т.д.), Но все это приветствуется на данном уровне риска. Эти выпуски почти наверняка прошли какую-либо проверку качества, но могут по-прежнему содержать незавершенные части. Критические изменения здесь все еще относительно распространены.
edge: для пользователей, желающих внимательно следить за разработкой.
Выпуски Edge часто включают непрерывный поток изменений без обещаний контроля качества или проверки и обычно создаются автоматически процессом CI из моментального снимка произвольного исходного кода. Часто CI публикует только после прохождения какого-либо автоматического контроля качества, и обзоры кода остаются хорошей практикой, но они зависят от конкретного проекта. Предположим, что выпуски edge могут часто прерываться.
По умолчанию привязки устанавливаются из стабильного уровня риска. Например, следующая команда устанавливает VLC из стабильного канала:
sudo snap install vlc
Используйте опцию --channel
, чтобы выбрать другой уровень риска. Следующая команда установит последнюю бета-версию VLC snap:
sudo snap install --channel=beta vlc
Если бета-версия snap недоступна, будет установлена snap с ближайшего канала канал с более стабильным уровнем риска.
Для краткости --stable
, --candidate
--beta
и --edge
можно использовать вместо --channel=<risk-level>
После установки отслеживаемый уровень риска может быть изменен с помощью switch
командной опции:
sudo snap switch --channel=stable vlc
Этот параметр не будет автоматически обновлять snap для принудительной установки новой snap. Чтобы переключать каналы и обновлять привязку одной командой, добавьте --channel
опцию в команду обновить:
sudo snap refresh --channel=stable vlc
Чтобы проверить, какой канал отслеживает привязка, найдите поле отслеживание в выходных данных snap info
команды:
$ snap info vlc
[...]
snap-id: RT9mcUhVsRYrDLG8qnvGiy26NKvv6Qkd
tracking: edge
refresh-date: yesterday at 19:54 BST
[...]
Уровни риска могут не соответствовать внутренним соглашениям проекта. Например, в некоторых проектах может использоваться alpha вместо edge. Однако номенклатура выпусков проекта должна быть достаточно близка к уровням риска snap, чтобы вы могли судить об относительной стабильности устанавливаемой вами версии.
Ветвь - это необязательное, детализированное подразделение канала для опубликованной привязки, позволяющее создавать кратковременные последовательности привязок, которые могут быть запущены по запросу разработчиками snap для помощи в исправлениях или временных экспериментах.
Названия ветвей передают их назначение, например, fix-for-bug123
, но имя не отображается обычным способом, например, с помощью snap info
команды. Вместо этого они могут быть установлены только тем, кто знает название ветки, и обычно им делится только разработчик snap для тестирования определенного исправления или выпуска.
По истечении 30 дней без дальнейших обновлений ветка будет автоматически закрыта. Затем будет выбрана сменная привязка, как это было бы с закрытыми каналами (см. Ниже). Например, бета-версия / исправление для bug123 вернется к бета-версии после закрытия ветки с исправлением для bug123.
Смотрите Публикация в ветке для получения более подробной информации о том, как разработчики snap могут использовать ветки для публикации временных выпусков snap.
Канал может быть закрыт издателем snap, если больше нет snap, который соответствовал бы первоначальному назначению или спецификации канала.
Например, когда канал определенного уровня риска закрыт, хранилище snap store выберет снимок с более стабильным уровнем риска на том же треке. Если исходный канал будет открыт повторно, снимки снова будут выбираться из исходного канала.
Этот подход обычно используется для бета-тестирования. Если snap подписывается на канал бета-версии, который затем закрывается, магазин предложит snap с канала-кандидата. Если возможный канал недоступен, будет выбран снимок из стабильного канала. Если бета-версия канала откроется повторно, привязка снова будет выбрана из этого канала.
По умолчанию привязки со строгим ограничением доступа могут получать доступ только к ограниченному набору ресурсов за пределами среды, в которой они выполняются. Привязки могут получать доступ только к ресурсам из системы и другим привязкам через интерфейсы, которые описывают предоставляемые ими ресурсы.
Создатель оснастки выбирает интерфейсы, необходимые для правильной работы оснастки. К общим интерфейсам относятся те, которые обеспечивают доступ к сети, функциям рабочего стола и звуковой системе.
Соединение между привязками осуществляется, когда разъем оснастки, нуждающейся в ресурсе, подключается к разъему в другой оснастке, предоставляющей этот ресурс. Аналогией этому является подключение устройства к электрической розетке, которая обеспечивает его необходимым питанием.
Подключения выполняются либо автоматически во время установки, либо вручную, в зависимости от их функции. Интерфейс рабочего стола подключается автоматически, например, в отличие от интерфейса камеры. В столбце Автоматическое подключение в таблице Поддерживаемые интерфейсы указывается, подключается ли интерфейс автоматически или нет. Смотрите Механизм автоматического подключения интерфейса для получения подробной информации о реализации.
Как и в случае с классическим ограничением, издатель snap может запросить утверждение для автоматического подключения интерфейса, который в противном случае не подключался бы автоматически. Например, guvcview snap запросил автоматическое подключение интерфейса камеры при установке snap.
Если snap обновлен и включает новое утверждение, пользователю все равно потребуется подключить интерфейс вручную. Аналогично, если установленная классическая snap обновлена для использования строгого ограничения, ее интерфейсы не будут настроены автоматически.
Если snap установлен до того, как интерфейсу было предоставлено разрешение на автоматическое подключение, и впоследствии это разрешение предоставлено и snap обновлен, то при обновлении установленной snap интерфейс будет подключен автоматически.
Используйте команду snap connections
, чтобы увидеть, какие интерфейсы необходимы snap и какие подключены в данный момент:
$ snap connections vlc
Interface Plug Slot Notes
camera vlc:camera - -
desktop vlc:desktop :desktop -
desktop-legacy vlc:desktop-legacy :desktop-legacy -
home vlc:home :home -
mount-observe vlc:mount-observe - -
[...]
В приведенном выше примере мы можем видеть, что vlc:camera
интерфейс отключен, потому что в нем есть пустой слот.
Дополнительные сведения об интерфейсе см. в разделе Управление интерфейсами, включая инструкции по отключению интерфейсов и выполнению подключений вручную, а также в разделе политика безопасности и "песочница" для получения дополнительной информации о том, как реализовано ограничение доступа.
Редакция Snap - это номер, автоматически присваиваемый магазином Snap при каждой загрузке snap, придающий каждому двоичному файлу snap уникальный идентификатор внутри и по всем его каналам.
Номер редакции увеличивается с каждой новой загрузкой. Но это число произвольное и используется только для разграничения загрузок.
Ни номер редакции (ни ее версия) не обеспечивают соблюдения порядка выпуска. Локальная система попытается установить любую версию snap, рекомендованную издателем, в отслеживаемом канале.
Выходные данные для snap info <snapname>
включают номер редакции для каждой привязки в каждой дорожке и канале в виде числа в скобках после даты публикации:
channels:
latest/stable: 2.59.4 2023-05-31 (19361) 55MB -
latest/candidate: 2.59.5 2023-06-09 (19457) 55MB -
latest/beta: 2.59.5 2023-05-27 (19457) 55MB -
latest/edge: 2.59.5+git955.gc9310cc 2023-06-13 (19535) 42MB -
installed: 2.59.1+git798.g5f761c7 (19131) 42MB snapd
В приведенном выше примере вывода последняя версия / edge snap имеет версию 19535
и является самой последней опубликованной версией snap. Если snap установлена, последняя строка snap info
выходных данных включает установленную версию (19131
, выше).
Команда snap list
включает столбец для номера версии каждой установленной snap, помеченный как Rev
:
Name Version Rev Tracking Publisher Notes
alacritty 0.8.0 46 latest/stable snapcrafters✪ classic
blender 3.5.0 3486 latest/stable blenderfoundation✓ classic
chromium 112.0 2424 latest/stable canonical✓ -
ffmpeg 4.3.1 1286 latest/stable snapcrafters✪ -
Хранилище Snap Store кэширует несколько старых версий каждой snap, как и локальная система. По умолчанию локально хранятся 2 версии, в то время как в системном хранилище Ubuntu Core хранится 3. Эти настройки по умолчанию можно изменить с помощью опции обновить-сохранить system.
Команды snap install
, refresh
и download
могут работать с этими доступными версиями с необязательным --revision
аргументом.
snap <command> <snap-name> --revision <revision-number>
Чтобы установить версию под номером 27 hello-world snap, например, выполните следующую команду:
$ snap install hello-world --revision 27
hello-world 6.3 from Canonical✓ installed
Привязку hello-world можно обновить до версии под номером 28 с помощью следующей команды:
$ snap refresh hello-world --revision 28
hello-world 6.3 from Canonical✓ refreshed
Номер версии привязки, с которой выполняется операция, появится в выходных данных во время этих операций.
Управление выпусками описывает, как разработчик snap может публиковать или продвигать определенные версии своей snap.
Идентификатор редакции используется в качестве ссылки для данных, относящихся к конкретной редакции. Как описано в разделе Расположения данных, данные, относящиеся к конкретной версии для snap, хранятся либо в общесистемном расположении, либо в домашнем расположении конкретного пользователя:
SNAP_DATA: /var/snap/<snap name>/<revision number>
Это хранилище также используется для хранения данных, в основном информации, используемой фоновыми приложениями и службами, для ведения журнала и других задач, требующих сохранения данных между запусками snap.
SNAP_USER_DATA : /home/<username>/snap/<snap name>/<revision>
В этом расположении содержатся любые пользовательские данные, которые snap записывает в свой собственный домашний файл. Это в отличие от того, что пользователь Linux считает своим домом, хотя само местоположение будет находиться в домашнем каталоге пользователя.
Важно отметить это различие, поскольку оно может быть полезным и даже важным, когда пользователи решают выполнить операции обслуживания своих снимков (например, удаление). По умолчанию в каждой snap будет использоваться символическая ссылка current , указывающая на последнюю доступную версию.
При переходе от одной редакции к следующей содержимое SNAP_DATA и SNAP_USER_DATA, зависящее от конкретной редакции, копируется в новые каталоги для новой редакции. Это включает в себя переход от более высокого номера редакции к более низкому номеру редакции (поскольку номера редакций произвольны).
Каталоги, относящиеся к конкретной редакции, сохраняются в соответствии с системной опцией обновить-сохранить.
Помимо содержимого общих каталогов, в моментальном снимке хранятся только данные, связанные с текущей установленной версией. Подробнее см. в разделе Что хранит моментальный снимок.
Транзакционное обновление - это операция установки или обновления набора привязок, которая либо завершается успешно для всех привязок, либо, если хотя бы одна привязка обнаруживает ошибку, завершается сбоем для всего набора. В случае сбоя процесса все затронутые снимки возвращаются к состоянию, в котором они находились до запуска процесса, даже снимки, которые были успешно обновлены.
Это может помочь, когда тестируется набор снимков с определенными ревизиями, чтобы убедиться в их совместной работе, и когда поведение может стать непредсказуемым, если набор не будет установлен или обновлен одновременно.
Транзакционные обновления также могут помочь, когда вы знаете, что одна привязка зависит от конкретной версии другой, или когда вам нужно обновить несколько привязок одновременно. Например, в прошивке для устройства под управлением Ubuntu Core это может помочь обновить как snap ядра, так и snap гаджета одновременно. Транзакционные обновления позволяют это.
Транзакционное обновление или установка могут быть созданы либо с помощью команды snap, либо с помощью POST /v2/snaps Snapd REST API.
Требуется snapd 2.55.
Команды snap install и snap refresh принимают дополнительный --transaction=
аргумент с all-snaps
либо для создания экземпляра процесса как отдельной транзакции, либо per-snap
, что используется по умолчанию, для отдельной транзакции для каждой указанной snap:
Чтобы установить привязки hello и hello-world как единую транзакцию, например, выполните следующую команду:
$ snap install hello hello-world --transaction=all-snaps
hello-world 6.4 from Canonical✓ installed
hello 2.10 from Canonical✓ installed
В настоящее время не выводится никаких изменений, журналов или сообщений, показывающих, был ли установлен набор привязок как одна транзакция.
Утверждение - это документ с цифровой подписью, который либо подтверждает действительность процесса, подтвержденного подписывающим лицом, либо содержит информацию о политике, сформулированную подписывающим лицом.
Snapcraft, snapd, Snap Store и фирменные магазины используют утверждения для обработки различных функций и процессов, включая аутентификацию, настройку политики, идентификацию и валидацию.
Утверждения основаны на тексте и принимают контекстно-зависимый формат, который всегда включает один или несколько заголовков, необязательный основной текст и закодированную подпись.
Это используемые в настоящее время типы утверждений:
snap-id
, его имя и издателя, а также политику, связанную с доступом к привилегированным интерфейсам.Типичный формат утверждения с общими заголовками выглядит следующим образом:
type: <type> # For example, “account” or “model”
authority-id: <account id> # On whose authority this assertion is made
<key field 1>: <value> # Fields identifying the object of the assertion
...
<key field N>: <value>
<other field>: <value>
...
revision: <int> # Assertions can be updated with a higher revision
format: <int> # Assertion types can have backward incompatible format changes signaled by a higher format
body-length: <int> # Present if a body is provided with this assertion
sign-key-sha3-384: <key id> # Encoded key id of signing key
<body> # Optional type-dependent body of length `body-length` bytes
<signature> # Encoded signature
type
, sign-key-sha3-384
и подписьauthority-id
Для определенного типа и индекса существует только одно “последнее” действительное утверждение, которое должным образом определяет политику для системы - утверждение с наивысшей редакцией. Для данного утверждения должны быть определены все заголовки индекса.
Команда snap known <type> [<header>=<value>...]
может использоваться для просмотра утверждений или определенного типа:
$ snap known account account-id=generic
type: account
authority-id: canonical
account-id: generic
display-name: Generic
timestamp: 2017-07-27T00:00:00.0Z
username: generic
validation: certified
sign-key-sha3-384: [...]
Аналогично, утверждения snap загружаются вместе с snap с помощью команды snap download
:
$ snap download gnome-calculator
Fetching snap "gnome-calculator"
Fetching assertions for "gnome-calculator"
Install the snap with:
snap ack gnome-calculator_945.assert
snap install gnome-calculator_945.snap
Утверждения включают snap-sha3-384
хэш-значение для обеспечения их целостности:
snap-sha3-384: j73cFx0pIMoX4U[...]
Однако эти хэш-значения будут выглядеть по-разному в зависимости от того, были ли они загружены из Snap Store, например, с помощью snap download
команды, или извлечены с помощью snapd REST API.
Это различие связано с тем, что Хранилище использует массивы байтов в шестнадцатеричном кодировании, в то время как snapd REST API кодирует хэши с помощью base64.
Разработчики обычно могут использовать значения в хэш-кодировке непосредственно в своем коде, тогда как значения base64 необходимо будет сначала расшифровать, например, с помощью команды base64.
Интерфейсы разрешают (или запрещают) доступ к ресурсу за пределами привязки, но они также разработаны таким образом, чтобы быть удобными для пользователей.
Частью этого удобства является то, разрешено ли автоматическое подключение интерфейса при установке snap или snap может запросить включение определенных сверхпривилегированных интерфейсов для начала. Это механизм автоматического подключения.
Механизм автоматического подключения интерфейса snapd был разработан для устранения необходимости ручного подключения при:
Смотрите Процесс получения псевдонимов, автоматических подключений и дорожек для получения подробной информации о том, как отправить запрос на автоматическое подключение .
Если snap установлен до того, как интерфейсу было предоставлено разрешение на автоматическое подключение, и впоследствии это разрешение предоставлено и snap обновлен, то при обновлении установленной snap интерфейс будет подключен автоматически.
Всякий раз, когда snap устанавливается или обновляется, snapd проверяет его неподключенные разъемы и их возможные гнезда на предмет возможности автоматического подключения. То же самое он делает для своих слотов и возможных разъемов.
Если имеется только один слот-кандидат для подключения штекера, то подключение интерфейса выполняется автоматически. Требование только к одному кандидату может быть изменено.
Для интерфейса подходящие пары разъемов и слотов определяются с использованием правил, основанных на ограничениях. Язык правил может либо разрешать, либо запрещать автоматическое подключение, причем последнее имеет приоритет.
Правила либо встроены в snapd, либо передаются через утверждения (подписанные документы), которые соответствуют данной snap (snap-декларации). Область действия правил ограничена и они прикреплены к разъему или штекеру интерфейса на любом из этих двух уровней:
Чтобы упростить рассуждения об их эффекте, правила из разных уровней / областей не объединены, а скорее расставлены по приоритетам в соответствии с уровнем:
От snap plug до уровня встроенного слота - это уровень, который в первую очередь предоставляет любые правила, определяющие используемые и учитываемые правила. Этот порядок отражает масштаб с точки зрения наиболее конкретного использования, потребления со стороны snap plug, до самых общих правил встроенного разъема.
Встроенные правила воплощают общую политику в отношении того, следует ли подключать интерфейс автоматически и когда именно, и, как таковые, они документируются вместе с интерфейсом. Следовательно, правила объявления snap выражают политику, установленную хранилищем.
Пользователь также может выполнять команды “snap connect” и “snap disconnect”. В частности, ручное “мгновенное отключение” автоматического подключения не позволит последующему обновлению восстановить автоматическое подключение (если только ручное отключение не переопределит это поведение по умолчанию с помощью опции “–забыть”).
Ниже приведен пример встроенного правила автоматического подключения (прикрепленного к слоту) для интерфейса содержимого:
slots:
content:
allow-auto-connection:
plug-publisher-id:
- $SLOT_PUBLISHER_ID
plug-attributes:
content: $SLOT(content)
Приведенный выше пример разрешает автоматическое подключение, если:
Язык правил позволяет нам запрещать или разрешать автоматические подключения со следующими ограничениями:
Дополнительные списки ограничений или значений могут использоваться на языке правил для выражения чередования (логическое ИЛИ). Те же языковые правила можно использовать для определения правил, отличных от автоматических подключений интерфейса, включая политику по умолчанию для обычных подключений и установок, и для переопределения политики для более чувствительных интерфейсов.
Подключаемый модуль интерфейса контента может указывать поставщика по умолчанию. Это название оснастки, которая может быть установлена для удовлетворения потребностей подключаемого модуля. Если в системе нет слота с меткой содержимого разъема, указанный snap будет установлен до snap с разъемом. Однако, если в системе есть слот, в котором уже есть метка содержимого, любой поставщик по умолчанию, указанный подключаемым модулем интерфейса содержимого, игнорируется. Если указанная привязка уже установлена, но в ней нет слота с меткой содержимого, вместо этого указанная привязка будет обновлена при условии, что более новая версия может начать предоставлять метку.
Механизм поставщика по умолчанию запускает установку или обновление snap поставщика, как описано, но он не включает подразумеваемое подключение. Автоматическое подключение произойдет только с помощью общего механизма автоматического подключения и если это разрешено им.
Без пользовательских флагов при установке или последующих подключениях к интерфейсу snaps ограничены ограниченной изолированной средой безопасности без доступа к системным ресурсам за пределами snap.
Разработчики Snap должны быть осведомлены о возможностях своих приложений в snap.
Политики безопасности и хранилища работают вместе, позволяя разработчикам быстро обновлять свои приложения и обеспечивать безопасность конечных пользователей, и в этом документе описывается изолированная среда, а также способы настройки политик безопасности для публикуемых вами снимков и работы с ними.
Для получения более общих сведений о том, что влечет за собой ограничение доступа, см. Ограничение доступа к Snap, а также подробности реализации см. Ниже:
Для получения справки по устранению проблем, которые могут возникнуть из-за политики безопасности snap, см. раздел Отладка snaps.
Разработчикам приложений не обязательно знать или понимать низкоуровневые детали реализации того, как применяется политика безопасности.
Каждая команда, объявленная с помощью apps
метаданных snap, отслеживается системой, присваивающей команде метку безопасности.
Этот ярлык безопасности имеет форму, snap.<snap>.<app>
где <snap>
- название оснастки, а <app>
- название приложения.
Например, ниже приведено объявление приложения из snap.yaml
:
name: foo
version: 1.0
apps:
bar:
command: bar
baz:
command: baz
daemon: simple
plugs: [network]
bar
- это snap.foo.bar
. В нем используется только политика по умолчанию.baz
является snap.foo.baz
. В нем используется default
политика плюс network
политика безопасности интерфейса, предоставляемая базовой программой snap.Этот ярлык безопасности используется во всей системе, в том числе на этапе ограничения процесса при запуске приложения.
По сути, программа запуска приложений выполняет следующее:
Настраивает различные переменные среды:
HOME
: установить значение SNAP_USER_DATA
для всех командSNAP
: каталог установки, доступный только для чтенияSNAP_ARCH
: архитектура устройства (например, amd64, arm64, armhf, i386 и т.д.)SNAP_DATA
: область, доступная для записи, для конкретной версии snapSNAP_COMMON
: доступная для записи область, общая для всех редакций snapSNAP_LIBRARY_PATH
: дополнительные каталоги, которые следует добавить в LD_LIBRARY_PATH
SNAP_NAME
: имя привязкиSNAP_INSTANCE_NAME
: имя экземпляра snap, включая. ключ экземпляра, если он установлен (snapd 2.36+)SNAP_INSTANCE_KEY
: ключ экземпляра, если таковой имеется (snapd 2.36+)SNAP_REVISION
: сохраненная версия snapSNAP_USER_DATA
: область, доступная для записи каждому пользователю для конкретной версии snapSNAP_USER_COMMON
: доступная для каждого пользователя область, общая для всех редакций snapSNAP_VERSION
: версия snap (от snap.yaml
)Когда аппаратное обеспечение назначается snap, настраивается группа устройств с устройствами по умолчанию (например, /dev /null, /dev /urandom и т.д.) и любыми устройствами, назначенными этой snap. Аппаратному обеспечению назначаются интерфейсные подключения.
Настраивает частное пространство имен mount, общее для всех команд в snap.
Настраивает частный /tmp
каталог, используя пространство имен частного монтирования для каждой привязки и монтируя каталог для каждой привязки в /tmp.
Настраивает новый экземпляр devpts для каждой команды.
Настраивает фильтр seccomp для команды.
Выполняет команду в профиле AppArmor для конкретной команды со значением nice по умолчанию.
При установке snap проверяются его метаданные, которые используются для получения профилей AppArmor, фильтров Seccomp и правил cgroup устройств, наряду с традиционными разрешениями. Такое сочетание обеспечивает надежную локализацию приложений:
Профили AppArmor создаются для каждой команды. Они имеют соответствующую метку безопасности и правила AppArmor для конкретных команд для обеспечения доступа к файлам, выполнения приложений, возможностей Linux, монтирования, ptrace, IPC, сигналов, крупномасштабной сети.
Как уже упоминалось, каждая команда выполняется в соответствии с политикой по умолчанию для конкретного приложения, которая может быть расширена через объявленные интерфейсы, которые выражены в метаданных как plugs
и slots
. При нарушениях политики AppArmor в snaps в строгом режиме будет отказано в доступе, и обычно для параметра errno установлено значение EACCES
. Обычно нарушение регистрируется в журнале.
См. раздел Нарушения AppArmor для получения справки об отслеживании проблем AppArmor.
Для каждой команды в snap для запуска создается фильтр seccomp, позволяющий выполнять фильтрацию системных вызовов allowlist, которая затем может быть расширена с помощью объявленных интерфейсов, выраженных в метаданных как plugs
и slots
.
Процессам, нарушающим политику seccomp, будет отказано в доступе к системному вызову с установленным значением errno EPERM
(snapd выпускается до версии 2.32SIGSYS
), и нарушение будет зарегистрировано в журнале.
Смотрите Нарушения Seccomp для получения справки об отслеживании проблем Seccomp.
правила udev генерируются для каждой команды для пометки устройств, чтобы их можно было добавлять / удалять в группу устройств команды. Однако по умолчанию устройства не помечены, и cgroup устройств не используется, а AppArmor используется для обеспечения доступа.
Согласно определению snapd, группа устройств может использоваться в дополнение к AppArmor, когда объявлен зависимый интерфейс, выраженный через plugs
и slots
в метаданных.
Процессам, обращающимся к устройствам, не входящим в группу устройств, специфичную для snap, будет отказано в доступе, если значение errno равно EPERM
. Нарушения доступа не регистрируются.
Традиционные разрешения для файлов (владелец, группа, списки управления доступом к файлам и другие) также применяются с помощью snaps.
Процессам, пытающимся получить доступ к ресурсам, которые не разрешены традиционными разрешениями на доступ к файлам, отказано в доступе, для параметра errno обычно установлено значение EACCES
(подробности см. На странице руководства по операции). Нарушения доступа не регистрируются.
Следовательно, все привязки выполняются в соответствии с политикой безопасности по умолчанию, которая может быть расширена за счет использования интерфейсов.
По умолчанию службу, запущенную из snap, необходимо перезапускать при каждом обновлении snap (подробнее см. в разделе Службы и демоны).
Остановка и запуск службы необходимы для поддержки snap revert и копирования системных данных snap из текущей версии в новую.
Системные данные обычно включают базы данных, файлы данных и файлы конфигурации (см. Расположение данных), хотя все это зависит от разработчика snap.
Возврат snap с помощью snap revert
восстанавливает системные данные snap до их предыдущего состояния, и службы, получающие доступ к этим данным, должны быть остановлены для защиты целостности данных, а также для облегчения внесения изменений в политику безопасности, которые требуются, когда snap обновляет местоположение системных данных.
Чтобы устранить любые потенциальные проблемы при необходимости перезапуска, snapd будет проверять наличие запущенных процессов, связанных с snap, перед каждым обновлением:
Демон snap использует AppArmor и Seccomp для создания политики безопасности, связанной с конкретной версией snap. Это определяет, к чему snap может получить доступ в вашей системе. Профили AppArmor и фильтры Seccomp создаются для каждой команды, и хотя профили AppArmor можно изменять и перезагружать во время выполнения процесса, фильтры Seccomp - нет.
Политика безопасности Snap разрешает доступ на чтение и запись для текущей версии и доступ только для чтения для других версий, чтобы сохранить возможности snap revert. Более конкретно, если 123
это текущая редакция, для политики AppArmor установлено значение разрешить rw
вкл SNAP_DATA=/var/snap/foo/123
.
До того, как стала доступна информация об обновлении, если обновление происходило во время работы snap, его политика AppArmor была обновлена, чтобы разрешить w
(запись) в новой версии и r
(чтение) в старых версиях, включая текущую версию. Политика была применена немедленно, что означало, что операции записи для запущенных процессов начнут завершаться сбоями.
Интерфейсы реализованы в виде подключаемых модулей и слотов. Подключаемый модуль в одном snap может подключаться к разъему в другом, и это обеспечивает доступ к необходимым ресурсам.
Команда snap connections может использоваться для просмотра доступных интерфейсов вместе с их слотами и разъемами.
$ snap connections
Interface Plug Slot Notes
home wormhole:home :home -
log-observe gnome-logs:log-observe :log-observe -
mount-observe gnome-system-monitor:mount-observe :mount-observe -
[...]
В приведенном выше примере вывода gnome-logs
привязка подключена к log-observe
интерфейсу, что означает, что политика безопасности из log-observe
была добавлена в gnome-logs
.
Интерфейсы могут быть объявлены как для каждой привязки, так и для каждой команды:
Интерфейс может подключаться автоматически при установке или требовать, чтобы пользователь подключал их вручную. Подключения и разъединения интерфейса выполняются с помощью команд snap connect
и snap disconnect
. Подробнее см. в разделе Интерфейсы.
Среда snap не должна влиять на производительность запущенного приложения, и любой инструмент мониторинга производительности или системы будет работать с процессами snap точно так же, как и с другими приложениями и процессами.
Однако мониторинг конкретных операций snap, наряду с производительностью установки и распространения, может помочь как при принятии решений о упаковке, так и при настройке snap, а также выявить потенциальные проблемы с производительностью, неподконтрольные приложению. Ниже описаны несколько таких подходов.
На устройствах под управлением Ubuntu Core системный параметр можно использовать для создания загрузочной диаграммы, показывающей время запуска системы и производительность:
Синхронизация выходных данных snap может быть полезным показателем общей производительности, но она также может выявить узкие места в производительности и цели для улучшения. Команда snap debug включает в себя несколько опций для получения выходных данных синхронизации времени выполнения, внутренних действий по обеспечению и времени запуска подсистемы.
По умолчанию snap debug timings
команда будет выдавать временные выходные данные для определенного изменения, которое само по себе представляет набор операций, выполняемых демоном snap.
Синтаксис команды следующий:
snap debug timings <change-id>
Идентификаторы изменений (<change-id>
) перечислены под ID
столбцом в выходных данных для snap changes
:
ID Status Spawn Ready Summary
8302 Done yesterday at 18:24 BST yesterday at 18:24 BST Install "chromium" snap
8303 Done today at 11:46 BST today at 11:46 BST Remove hotplug connections and slots of device /dev/ttyACM0 (100 Series/C230 …; serial: 6564B3891339) with interface "serial-port"
8304 Done today at 11:50 BST today at 11:50 BST Add hotplug slot of interface "/dev/ttyACM0 (100 Series/C230 …; serial: 6564B3891339)" for device serial-port with hotplug key "056a4e841487…"
Вместо идентификатора изменения, --last
аргумент может использоваться с четко определенным именем для изменения, таким как auto-refresh
, install
, refresh
, remove
или try
.
С аргументом --verbose
выходные данные также будут содержать метку для изменения:
ID Status Doing Undoing Label Summary
160162 Done 750ms - prerequisites Ensure prerequisites for "chromium" are available
^ 681ms - install-prereq install "cups"
ИДЕНТИФИКАТОР представляет собой числовой идентификатор для задач, порожденных логикой изменений, при этом вложенные задачи обозначаются символом ^
под их родительским элементом.
Следующие диаграммы были созданы на основе Doing
выходных данных столбца snap debug timings --last=install
после установки chromium snap, сначала из кэша, а затем после новой установки:
Наряду со временем выполнения изменения, также отслеживается время a, затраченное на обработку внутренних действий snapd, называемых "действиями по обеспечению". Убедитесь, что действия выполняются на регулярной основе и что они время от времени генерируют новые задачи в виде изменений для продолжения первоначального действия. Они включают следующее:
auto-refresh
become-operational
(только для ядра Ubuntu)install-system
(только для ядра Ubuntu)refresh-catalogs
refresh-hints
seed
(только для ядра Ubuntu)Отслеживание времени выполнения таких действий по обеспечению безопасности может быть полезным. Например, автоматическое обновление включает в себя несколько процессов для различных уже установленных snaps, включая подключение к Snap Store. Таким образом, информация о сроках может помочь в устранении неполадок с обновлением.
Используйте --ensure=
аргумент, чтобы просмотреть сведения о времени выполнения последнего указанного действия обеспечения, или с необязательным --all
аргументом, чтобы отобразить данные о времени выполнения каждого действия обеспечения.
$ snap debug timings --ensure=refresh-catalogs
ID Status Doing Undoing Summary
refresh-catalogs 309ms -
^ 69ms - query store for sections
^ 170ms - query store for catalogs
Данные о времени запуска для двух подсистем, load-state
и ifacemgr
, также отслеживаются и могут выводиться с --startup
аргументом:
$ snap debug timings --startup=ifacemgr
ID Status Doing Undoing Summary
ifacemgr - -
^ 8ms - setup security backend "apparmor" for snap "core"
^ 7ms - setup security backend "mount" for snap "lxd"
^ 16ms - setup security backend "apparmor" for snap "lxd"
^ 12ms - load unchanged security profiles of snap "lxd"
^ 7ms - setup security backend "apparmor" for snap "vlc"
^ 5ms - load unchanged security profiles of snap "vlc"
В приведенном выше примере показано время выполнения, связанное с менеджером интерфейсов snapd, которое включает время настройки профилей безопасности для всех установленных snaps и их интерфейсов до того, как snapd начнет функционировать.
SquashFS - это стандартная файловая система Linux, которая заключает операционную структуру каталогов в один сжатый файл. Обычно используется для предоставления загрузочных операционных сред Linux на USB-накопителе, но также используется для упаковки snap.
Snap - это файл SquashFS, который содержит библиотеку и двоичную среду для snap, а также метаданные, описывающие доступ к нему и возможности. Файл SquashFS монтируется systemd либо при первой установке snap, либо на ранних этапах загрузки системы, такой как Ubuntu Core, в которой уже установлены snaps.
Распаковка SquashFS происходит при первом запуске snap в системе и тщательном мониторинге ее производительности. В частности, производительность распаковки может отличаться в зависимости от используемого алгоритма сжатия, размера архива SquashFS, количества содержащихся в нем файлов, осуществляется ли к нему доступ в первый раз (холодный кэш) или к нему обращаются повторно (теплый кэш).
Снимки могут использовать один из двух различных типов сжатия, либо xz
, либо lzo
, при этом для большинства снимков по умолчанию используется значение xz
. Эти алгоритмы были выбраны из-за их степени сжатия и скорости при использовании со снимками, которые отличаются количеством содержащихся в них файлов и их размером.
Chromium, например, содержит более 300 МБ почти 1000 файлов, и доступ к каждому файлу занимает значительно больше времени, чем запуск приложения. В этом случае формат сжатия xz является самым медленным, более чем в два раза превышая следующий по скорости формат, gzip. Это показано на следующей “диаграмме блоков”, где каждый тест был запущен 10 раз с использованием 6 различных вариантов сжатия. Каждый тест сам по себе представляет собой совокупность затрат времени на установку, двукратный запуск приложения и хэширование каждого файла в архиве SquashFS:
Также была протестирована скорость распаковки как для доступа к холодному кэшу (1), так и для доступа к теплому кэшу (2) с использованием целого ряда алгоритмов сжатия. Опять же, для Chromium измерение скорости запуска показывает, что xz изначально работает очень плохо при первом запуске, но значительно улучшается при последующих запусках:
На коэффициенты сжатия для различных алгоритмов сжатия также влияет размер файлов внутри snap:
Эти сравнения в конечном итоге привели к добавлению lzo в качестве дополнительного алгоритма сжатия, но его использование со snaps полностью зависит от типа и структуры файлов в архиве SquashFS.
snapd - это фоновая служба, которая управляет вашими снимками и поддерживает их. Сама она поставляется либо как snap, либо как традиционный пакет Linux, такой как deb или RPM.
Существует два типа выпуска; основной и второстепенный выпуски, обозначаемые числовым статусом для их номеров версий с дополнительным периодом и номером, зарезервированным для второстепенных выпусков:
Разница между основным и второстепенным выпуском заключается в его планировании, подготовке и мотивации. Цикл выпуска основного выпуска происходит каждые несколько недель, но иногда нам нужен промежуточный выпуск второстепенной версии, содержащий меньшие изменения и исправления.
Различия между основным выпуском и последующим второстепенным выпуском (например, 2.53 -> 2.53.1) настолько малы и целенаправленны, насколько это возможно, при этом основной рефакторинг кода и новые функции опущены. Это не всегда возможно, потому что иногда ошибки или функции являются сложными, но это наша главная цель.
Крупные выпуски модулей, например, между snapd 2.x и 3.x, происходят крайне редко, и в настоящее время никаких дальнейших выпусков модулей не планируется.
Ниже приведен типичный процесс выпуска для snapd, начинающийся с создания ветки выпуска и пометки ее для выпуска:
Код, предназначенный для следующей версии snapd, объединен с основной веткой на GitHub.
Для основного выпуска мы создаем новую ветку от master с именем release/<VERSION>
, где <VERSION>
всегда указан номер основной версии. Тег окончательной основной версии для данного выпуска всегда находится в этой ветке, и там же мы будем помечать последующие второстепенные выпуски для этой основной версии.
Если в ветку "Новая версия" добавляется дополнительный код, мы сначала проверяем, что все необходимые материалы находятся в release/VERSION
ветке, прежде чем помечать и подписывать тег ключом GPG одного из сопровождающих snapd, у которого есть разрешение на создание релиза.
Затем на основе тега выпуска мы создаем несколько артефактов для snapd в разных местах, включая:
Затем мы выпускаем core snap и snapd snap на соответствующих бета-каналах.
Мы не выпускаем эти снимки на соответствующие пограничные каналы и не выпускаем версии с пограничного канала на бета-версии или более поздние каналы. Для наших выпусков каналы имеют особое назначение, так что версия snap, которая попадает в канал edge, никогда не попадет в каналы beta / candidate / stable, и наоборот.
Теперь запущены автоматические тесты, и мы отправим внутренний запрос Canonical для тестирования новой версии snapd.
Если в результате автоматического тестирования не обнаружено проблем, мы оставляем snapd и основные снимки в бета-версии как минимум на 2 недели.
После периода бета-тестирования мы перемещаем snap на канал-кандидат.
Если сообщество и команды положительно отзываются о готовящемся выпуске, он постепенно переходит на стабильный канал.
Выпуск почти всегда завершается для выпуска в понедельник или вторник. Это оптимизирует пропускную способность и позволяет остановить развертывание, если у пользователей, которые получают snap раньше, возникают проблемы.
Теперь мы запускаем процесс SRU для выпуска обновленной версии пакета Debian от snapd до выпусков Ubuntu в основном архиве, включая выполнение сборок / загрузок ESM по мере необходимости.
Номер версии snapd snap в его стабильном канале всегда будет соответствовать номеру версии выпущенной версии snapd или core snap в соотношении 1:1.
Например, в теге git 2.51.1 на стабильном канале будет опубликована только одна редакция с этим номером версии.
Эта политика с одной ревизией для каждого номера версии помогает упростить отладку, когда выходные данные команды snap version позволяют нам изолировать ревизию snapd или основных снимков, которые соответствуют выпущенной версии.
Однако номер версии пограничного канала snapd snap не соответствует соотношению 1: 1 для одной редакции. Вместо этого номер версии включает git-коммит, из которого была собрана snap, например 2.53.1+git563.g5297d66
, что упрощает отслеживание выпуска до git-коммита, из которого была собрана редакция edge.
Номер версии core snap, выпущенной на канале edge, немного сложнее, поскольку git-коммит, который он отображает, является коммитом проекта snapd-vendor в launchpad, который включает исходный код snapd и зависимости Go от поставщика.
Для производственного использования пограничный канал не рекомендуется. Функциональность может работать нестабильно, и ее невозможно будет обновить между выпусками. Для сравнения, стабильный выпуск канала будет оставаться обратно совместимым с предыдущим выпуском в той степени, в какой это технически возможно, при этом все еще будут исправлены ошибки или проблемы безопасности.
Иногда, когда мы не готовы к выпуску основного или второстепенного выпуска, но нам необходимо внедрить исправление для конкретной проблемы, мы создаем конкретный выпуск ветки и делимся им со всеми, кого это может затронуть. Этот выпуск ветки обычно закрывается после подтверждения исправления, его загрузки в master и выпуска по стабильному каналу.
В отличие от некоторых проектов, у нас нет специальной “заморозки кода”, когда в релизе нельзя добавлять или удалять ничего незапланированного. Вместо этого запросы на извлечение, предназначенные для следующего выпуска, помечаются соответствующим этапом и как заблокированные. Это предотвращает их случайное объединение в неправильную ветку выпуска или до создания следующей основной ветки выпуска.
После создания ветки выпуска мы обычно стараемся пометить выпуск как можно скорее. Как упоминалось ранее, иногда требуется исправить новые ошибки или добавить функции. После объединения с master они переносятся обратно в ветку release. Мы можем добавлять коммиты из master в ветку release, прежде чем помечать релиз в ветке release.
Однако после того, как релиз был помечен, мы никогда не будем помечать его повторно. Вместо этого, если будет обнаружена проблема, препятствующая его фактическому стабильному выпуску, мы создадим новый тег для последующего второстепенного выпуска. Например, если ошибка была обнаружена в бета-версии 2.54, она никогда не попадет на стабильный канал. Вместо этого версия 2.54.1 станет первой версией 2.54 на стабильном канале.
Если вам интересно, какие новые функции будут включены в следующий крупный выпуск snapd, вы можете ознакомиться со страницей дорожной карты здесь: https://snapcraft.io/docs/snapd-roadmap 4. На сроки будущих выпусков на этой странице ни в чем не следует полагаться, это просто оценки. Даты, указанные для уже выпущенных версий snapd, должны быть точными и относиться к основной версии, а не к каким-либо связанным с ней второстепенным версиям (поскольку второстепенные выпуски обычно не включают новых функций, только исправления ошибок или очень маленькие и целевые функции).
Лучший способ определить, когда будет выпущена следующая версия snapd, - это связаться с нами через IRC или форум, и мы предоставим вам наилучшую оценку, какую сможем на данный момент.