Synapse

Введение

Если вы подбираете себе чат сервер и проверяете различные варианты, рекомендую так же посмотреть на сервер MyChat. Я его тестировал и достаточно подробно описал. Возможно, вам он подойдет больше, чем все остальное.

Информация по Matrix Synapse без проблем гуглится, поэтому не буду подробно рассказывать, что это такое. Кратко пройдемся по основному:

  1. Matrix – это открытый протокол для децентрализованной коммуникации. Он может быть реализован в различных серверах и мессенджерах.
  2. Synapse – локальный сервер, который работает на протоколе matrix, обеспечивает возможность подключения и общения клиентов.
  3. Riot – клиент, который может подключаться к любому серверу, работающему по протоколу matrix, в том числе к synapse. Представлен в виде десктропной или web версии, которую можно установить на свой сервер.

Далее мы займемся установкой локальной версии Matrix Synapse для подключения своих клиентов. На этом же сервере разместим веб клиента Riot. Все это дело снабдим ssl сертификатом. В общем, на выходе должны получить готовое бесплатное локальное решение для корпоративного чата.

Сразу хочу предупредить, что мое описание не подходит под готовое руководство, которое позволит простым копипастом все настроить. Это руководство именно по matrix и riot, вы должны как минимум уметь настраивать web сервер с nginx, устанавливать сертификаты, проксировать запросы, если вам это понадобится.

Guides Recommended by matrix.org

If you want to… Then read…
Just get started! Getting Involved, which explains various ways of getting started with Matrixorthe FAQ, where we try to answer all your questions relating to Matrix
Understand the CS API How to use the client-server API, which explains in detail how to use the CS API.Useful if you want to write a client (or modify an existing one) — or if you’re just interested in how it works “under the hood”
Get started with the CS API using …  
… JavaScript Usage of the matrix-js-sdk
… Python Matrix Python SDK documentation
Understand Application Services The Application services guide introduces them and explains what they can be used for
See an example of a simple bot tiny-matrix-bot source code
Create a complete working chatbot Using Matrix to make Chatbot software from the 1960s available in 2018 goes from the basics, brings in matrix-bot-sdk, and ends with deployment on a Raspberry Pi
Work on Bridges to Matrix Types of Bridging should be read by all bridge developers to ensure everyone has the same mental map of terminology when implementing bridges
Migrate from the old v1 CS API the v1 migration guide which justs lists the changes from v1 to r0
Use E2E in a client application The End-to-end Encryption Implementation Guide is intended for client developers who wish to add support for end-to-end encryption to their clients
Install Synapse Installing Synapse Guide
… using Docker the Synapse Docker README
Understand Moderation in Matrix Moderation in Matrix

Synapse Development

To check out a synapse for development, clone the git repo into a working
directory of your choice:

git clone https://github.com/matrix-org/synapse.git
cd synapse

Synapse has a number of external dependencies, that are easiest
to install using pip and a virtualenv:

python3 -m venv ./env
source ./env/bin/activate
pip install -e "."

This will run a process of downloading and installing all the needed
dependencies into a virtual env. If any dependencies fail to install,
try installing the failing modules individually:

pip install -e "module-name"

We recommend using the demo which starts 3 federated instances running on ports 80808082

(to stop, you can use ./demo/stop.sh)

If you just want to start a single instance of the app and run it directly:

Registering a new user

Now that Synapse is installed, you should add a new user as an admin to be able to configure chat rooms and web client settings. First, make sure you are in the home server virtual environment and start the server.

cd ~/synapse
source env/bin/activate
synctl start

Then register a new user to the localhost.

register_new_matrix_user -c homeserver.yaml http://localhost:8008

This starts an interactive user configuration, enter the desired username and password, then select yes to enable administration priveledges.

New user localpart : username
Password: password
Confirm password: password
Make admin : yes|no
Sending registration request...
Success.

Features

  • Changes to 3pid verification:
    • Add the ability to send registration emails from the homeserver rather than delegating to an identity server. (#5835, #5940, #5993, #5994, #5868)
    • Replace config option with , and make the parameteter optional on endpoints, as per MSC2263. (#5876, #5969, #6028)
    • Switch to using the v2 Identity Service API where available, with fallback to v1. (Implements MSC2134 plus for v2 Identity Service APIs from MSC2140). (#5897)
    • Remove and parameters from ala MSC2140. (#5964)
    • Add to in as per MSC2264. (#5974)
    • Use the v2 Identity Service API for 3PID invites. (#5979)
    • Add endpoint from MSC2140 for unbinding a 3PID from an identity server without removing it from the homeserver user account. (#5980, #6062)
    • Use and for validating threepid sessions. (#6011)
    • Allow homeserver to handle or delegate email validation when adding an email to a user’s account. (#6042)
    • Implement new Client Server API endpoints and as per MSC2290. (#6043)
    • Add an unstable feature flag for separate add/bind 3pid APIs. (#6044)
    • Remove parameter from Client Server POST endpoint as per MSC2290. (#6067)
    • Add endpoint for proxying submitToken on an . (#6078)
    • Add response parameter to endpoints. (#6079)
    • Add flag to /version’s unstable_features. (#5972)
  • Enhancements to OpenTracing support:
    • Make OpenTracing work in worker mode. (#5771)
    • Pass OpenTracing contexts between servers when transmitting EDUs. (#5852)
    • OpenTracing for device list updates. (#5853)
    • Add a tag recording a request’s authenticated entity and corresponding servlet in OpenTracing. (#5856)
    • Add minimum OpenTracing for client servlets. (#5983)
    • Check at setup that OpenTracing is installed if it’s enabled in the config. (#5985)
    • Trace replication send times. (#5986)
    • Include missing OpenTracing contexts in outbout replication requests. (#5982)
    • Fix sending of EDUs when OpenTracing is enabled with an empty whitelist. (#5984)
    • Fix invalid references to None while OpenTracing if the log context slips. (#5988, #5991)
    • OpenTracing for room and e2e keys. (#5855)
    • Add OpenTracing span over HTTP push processing. (#6003)
  • Add an admin API to purge old rooms from the database. (#5845)
  • Retry well-known lookups if we have recently seen a valid well-known record for the server. (#5850)
  • Add support for filtered room-directory search requests over federation (MSC2197, in order to allow upcoming room directory query performance improvements. (#5859)
  • Correctly retry all hosts returned from SRV when we fail to connect. (#5864)
  • Add admin API endpoint for setting whether or not a user is a server administrator. (#5878)
  • Enable cleaning up extremities with dummy events by default to prevent undue build up of forward extremities. (#5884)
  • Add config option to sign remote key query responses with a separate key. (#5895)
  • Add support for config templating. (#5900)
  • Users with the type of «support» or «bot» are no longer required to consent. (#5902)
  • Let synctl accept a directory of config files. (#5904)
  • Increase max display name size to 256. (#5906)
  • Add admin API endpoint for getting whether or not a user is a server administrator. (#5914)
  • Redact events in the database that have been redacted for a week. (#5934)
  • New prometheus metrics:
    • : represents the total number of servers your server knows about (i.e. is in rooms with), including itself. Enable by setting to True in the configuration.(#5981)
    • : exposes the Python version, OS version, and Synapse version of the running server. (#6005)
  • Give appropriate exit codes when synctl fails. (#5992)
  • Apply the federation blacklist to requests to identity servers. (#6000)
  • Add option to configure where stats are reported to, if enabled. Contributed by @Sorunome. (#6012)
  • Add config option to increase ratelimits for room admins redacting messages. (#6015)
  • Stop sending federation transactions to servers which have been down for a long time. (#6026)
  • Make the process for mapping SAML2 users to matrix IDs more flexible. (#6037)
  • Return a clearer error message when a timeout occurs when attempting to contact an identity server. (#6073)
  • Prevent password reset’s submit_token endpoint from accepting trailing slashes. (#6074)
  • Return 403 on if registration has been disabled. (#6082)
  • Explicitly log when a homeserver does not have the config field configured. (#6090)
  • Add support for pruning old rows in table. (#6098)

Explanations

Presence

Unfortunately presence is right now broken and generates a high load. Until this issue https://github.com/matrix-org/synapse/issues/3971 is resolved, i suggest in deactivating presence, but the user avatars will be grey afterwards on the homeserver. To deactivate, open

sudoedit /etc/matrix-synapse/homeserver.yaml

and add

Do i need a TURN-Server (ex. COTURN)

It’s only necessary when both parties are behind NAT. Otherwise 1-on-1 communication should work fine. Group-Calls via Riot will be handled with jitsi.riot.im and are not handled by the homeserver.

Signature errors

Don’t be worried about signature errors when joining rooms, timeouts from random domain names, and failed requests to random domain names.

Certificates and LetsEncrypt

CLIENT and FEDERATION ports are DIFFERENT, they do not use the same port.

  • TCP 8448 (Default, can change): Federation, HTTPS, original generated self-signed certificate, directly exposing port TCP 8448 of synapse (NO reverse proxy, NO replace certificate)

  • TCP 443: Clients, HTTPS, regular certificate (e.g. Let’s Encrypt), reversed proxy to port TCP 8008 of synapse

The self-signed certificate of synapse SHOULD NOT be replaced and port 8448 should only be used for federation (server traffic) and directly exposed publicly. For clients connections, a reverse proxy should be reachable publicly with a regular certificate (e.g. Let’s Encrypt) on port 443 that goes to the port 8008 of synapse.

Because matrix (at this point) uses perspectives to validate certificates so there is no need to validate a certificate by an certificate authority. Tl;dr: Other matrix server look at the cert, and if they see the same cert your server does, you’re not being MITM’ed (Man-in-the-middle), a bit like peer validation. It is possible to configure which peers are trusted in , by default it’s just .

Использование ssl сертификата Let’s Encrypt

Прежде чем начать настройку сервера, установим на него полноценный ssl сертификат. Если вам это не нужно, можно пропустить данный пункт. Просто посмотреть на чат можно и с самописным сертификатом, который мы получили ранее. Но есть один нюанс. Клиент Riot, который я буду использовать для подключения к серверу, не будет работать с самописным сертификатом. Он будет ругаться на него во время подключения. Так что если вы хотите полноценно протестировать работу мессенджера Riot в связке с matrix synapse, придется установить нормальный сертификат.

Мой сервер с чатом напрямую не смотрит в интернет. Я буду проксировать все подключения к нему через web сервер, на котором установлен nginx. Поэтому получение сертификата нужно выполнять именно на нем. Если у вас matrix сервер будет смотреть напрямую в интернет, то настраивать получение ssl сертификата надо именно на нем.

Прежде чем получить сертификат, нарисовал примерно такой конфиг виртуального домена для nginx.

server {
 listen 80;
 server_name chat.serveradmin.ru;

location /.well-known {
 root /web/sites/chat.serveradmin.ru/www/;
 }
}

Подробно про получение сертификатов Let’s Encrypt я рассказывал в статье по настройке веб сервера. За всеми подробностями можете заглянуть туда. Здесь же без подробных пояснений выполняем необходимые действия.

Устанавливаем certbot.

# yum install certbot

Запускаем запрос сертификата.

# certbot certonly

При первом запуске на сервере, нужно будет зарегистрировать новую учетную запись на сервер и указать почтовый ящик. Я все это уже ранее делал, так что просто выбираю тип подтверждения домена:

2: Place files in webroot directory (webroot)

Далее указываю имя домена:

Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): chat.serveradmin.ru

Указываю директорию веб сервера:

Input the webroot for chat.serveradmin.ru: (Enter 'c' to cancel): /web/sites/chat.serveradmin.ru/www

Сертификат получил. Дальше рисую следующий конфиг для виртуального хоста nginx уже для работы по https.

upstream matrix {
 server 77.37.225.129:22991;
}

server {
 listen 80;
 server_name chat.serveradmin.ru;
 return 301 https://$server_name$request_uri;
}

server {
 listen 443 ssl http2;
 server_name chat.serveradmin.ru;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/chat.serveradmin.ru/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/chat.serveradmin.ru/privkey.pem;
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_dhparam /etc/ssl/certs/dhparam.pem;
 ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
 ssl_prefer_server_ciphers on;
 ssl_session_cache shared:SSL:10m;

location /.well-known {
 root /web/sites/chat.serveradmin.ru/www/;
}

 location / {
 client_max_body_size 50M;
 proxy_set_header Connection "";
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Frame-Options SAMEORIGIN;
 proxy_pass http://matrix;
 }
}

На сервере 77.37.225.129 сделан проброс внешнего порта 22991 на локальный 8008. На этом порту работает synapse по незащищенному соединению. Редиректить надо именно на этот порт, так как если сделать переадресацию на защищенный порт, который работает со своим сертификатом, будут проблемы при совместной работе этого локального сертификата и внешнего от Let’s Encrypt.

С сертификатом и самим сервером synapse разобрались. Дальше я предлагаю сначала установить и настроить бесплатный web клиент для чата — Riot. Если он вам не нужен, можно сразу переходить к настройке самого сервера.

Установка и настройка Nginx

Установите и настройте веб-сервер Nginx в качестве обратного прокси согласно руководству. Добавьте следующую настройку для matrix.example.org:

/etc/nginx/sites-enabled/matrix.conf

server {
    listen 443 ssl;
    server_name matrix.example.org;

    include ssl.conf;
    ssl_certificate /etc/nginx/ssl/matrix.example.org/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/matrix.example.org/privkey.pem;
    client_max_body_size 1000M;

    location / {
        proxy_pass http://localhost:8008;
        proxy_set_header X-Forwarded-For $remote_addr;

    }
}

Для подключения Matrix-сервера к федерации добавьте следующую настройку:

/etc/nginx/sites-enabled/matrix.conf

server {
    listen 8448 ssl;
    server_name matrix.example.org;

    include ssl.conf;
    ssl_certificate /etc/nginx/ssl/matrix.example.org/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/matrix.example.org/privkey.pem;

    location / {
        proxy_pass http://localhost:8008;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Чтобы ваш сервер без проблем видели клиенты, а также другие серверы по федеративному протоколу, добавьте SRV-запись в DNS matrix.example.org:

_matrix._tcp.matrix.example.org. 3600 IN SRV 10 0 8448 matrix.example.org.

Install Synapse

Create a virtual environment for your Synapse application. Python virtual environment is used to create an isolated virtual environment for a Python project. A virtual environment contains its own installation directories and doesn’t share libraries with global and other virtual environments.

Provide the ownership of the directory to the current user.

Now activate the virtual environment.

Ensure that you have the latest version of and .

Install the latest version of Synapse using pip.

The above command will take some time to execute as it pulls and installs the latest version of Synapse and all the dependencies from Github repository.

Why is this necessary?

Prior to 1.4.0, the identity server was providing two related-but-separate functions:

Using identity servers for registration and password reset introduced yet further complexity — since password reset is a sensitive operation, it was important that the homeserver only use ‘trusted’ identity servers for this purpose (with the trust being configured by the homeserver admin in the homeserver config). But this created ambiguity over who was ultimately responsible for the choice of identity server and when they could make that choice — the client could present a default identity server at login/registration/password reset time, which the user could choose to override before logging in, but unless the identity server ultimately selected were on the homeserver admin’s ‘trusted identity servers’ list, any identity server operations that were proxied via the homeserver would have been blocked by the homeserver. However, not all identity server operations initiated by the client were proxied via the homeserver — some were sent directly from the client to the identity server, and would not have been filtered.

This delegation is entirely separate from the user’s choice of identity server for user directory services. As of right now the user is free to choose and trust whichever identity server they wish, or to choose not to use an identity server at all.

Configuring docker containers

So I ended up with this minimal config:

Running will pull all the needed images and create everything (containers, volumes, networks…), but won’t start them. This is handy, since we still have some configuring to do, first.

Configuring Synapse

We need to generate Synapse config.

Then we need to edit it to suit our needs. The easiest way is to find where the relevant files are located by finding the Mountpoint of the Synapse volume.

All operations in Docker’s files will require root access, so either switch to root or prepend as needed. We need to go to the Mountpoint () and then edit the file.

The file is quite large and you might want to set things up differently, but here are some of the keys I changed, with comments. I’m skipping over big chunks of the file that I just left on default values, so this snippet is not copy-pastable.

This was a bit of a gotcha for me: the should be the part which shows up in your usernames, but the is the URL of the Synapse instance. I didn’t know the nomenclature well enough, got this wrong the first time around and nothing worked.

Configuring Element (Riot)

We find the Element’s config files in the same manner, by doing a and going over to the Mountpoint directory. We need to edit the file.

This one’s a lot shorter. These are the most important (again, not presented in file order):

About Matrix

Matrix specifies a set of pragmatic RESTful HTTP JSON APIs as an open standard,
which handle:

  • Creating and managing fully distributed chat rooms with no
    single points of control or failure
  • Eventually-consistent cryptographically secure synchronisation of room
    state across a global open network of federated servers and services
  • Sending and receiving extensible messages in a room with (optional)
    end-to-end encryption
  • Inviting, joining, leaving, kicking, banning room members
  • Managing user accounts (registration, login, logout)
  • Using 3rd Party IDs (3PIDs) such as email addresses, phone numbers,
    Facebook accounts to authenticate, identify and discover users on Matrix.
  • Placing 1:1 VoIP and Video calls

These APIs are intended to be implemented on a wide range of servers, services
and clients, letting developers build messaging and VoIP functionality on top
of the entirely open Matrix ecosystem rather than using closed or proprietary
solutions. The hope is for Matrix to act as the building blocks for a new
generation of fully open and interoperable messaging and VoIP apps for the
internet.

Synapse is a reference «homeserver» implementation of Matrix from the core
development team at matrix.org, written in Python/Twisted. It is intended to
showcase the concept of Matrix and let folks see the spec in the context of a
codebase and let you run your own homeserver and generally help bootstrap the
ecosystem.

Thanks for using Matrix!

Установка Matrix Synapse home server

Я буду устанавливать чат сервер на CentOS 7

Если у вас еще нет сервера, то смотрите мои статьи по установке и базовой настройке centos.Сразу обращаю внимание, что у меня на сервере будет отключен selinux. Как это сделать, смотрите в статье по настройке сервера, ссылка на которую выше

Для работы synapse server необходим Python 2.7, который в CentOS 7 установлен по-умолчанию. Убедиться в этом можно введя в консоли:

Сервер чата synapse может использовать различные базы данных. По-умолчанию, он работает с SQLite, что подходит только для теста. В продакшене использовать эту базы плохое решение. Но даже для теста у меня не получилось настроить работу с SQLite. По-умолчанию, в CentOS устанавливается очень старая версия базы. При ее использовании возникает ошибка и сервер не работает. Я обновил базу до последней версии, но как оказалось, с ней тоже возникают проблемы. Я почитал на эту тему обсуждения и понял, что проблема распространенная, а не уникальная, поэтому решил в ней не разбираться. Вместо этого сразу буду использовать postgresql, что является самым надежным и разумным выбором.

Устанавливаю соответствующий моей версии репозиторий:

Ставим самую свежую на момент написания статьи версию postgresql:

Инициализируем базу данных:

Редактируем конфигурационный файл для включения MD5 аутентификации.

Меняем строки в самом конце:

на

Запускаем PostgreSQL и добавляем в автозагрузку:

Заходим в систему под пользователем postgres:

Создаем пользователя базы данных:

Запускаем консольный клиент для работы с базой данных:

Задаем пароль userpass для только что созданного пользователя:

Создаем базу данных для чат сервера matrix synapse:

Выходим из консоли управления и учетной записи postgres.

Установим еще несколько пакетов, необходимых для взаимодействия synapse с postgresql.

Подготовительные действия выполнили, теперь можно устанавливать сам сервер. Для этого установим необходимые зависимости.

Устанавливаем менеджер пакетов Python — pip.

Создаем виртуальную среду для приложения synapse. Она используется для изоляции отдельного python проекта. Проект будет использовать свои собственные директории и библиотеки, без взаимодействия с глобальным окружением.

Устанавливаем необходимые пакеты питона.

Обновляем setuptools:

Устанавливаем сам сервер matrix synapse.

Перед запуском сервера, необходимо создать файл конфигурации. Делаем это.

Я использую доменное имя для своего чат сервера chat.serveradmin.ru

Обращаю внимание на этот параметр. Он важен, если вы захотите использовать полноценный ssl сертификат и https подключения

Используйте реальное доменное имя, на которое потом будете получать сертификат. После выполнения команды вы получите примерно такой вывод:

По умолчанию, в файле конфигурации homeserver.yaml будет указано использовать базу данных SQLite. Комментируем строки, отвечающие за эту настройку и добавляем параметры для подключения созданной ранее postgresql базы.

Обращаю внимание на отступы в файле конфигурации. Они принципиально важны

Должно быть именно так, как показано — database без отступа, name, args один пробел с начала строки. Все остальное — два пробела.

На этом установка сервера закончена, двигаемся дальше.

Заключение

Дальше можно создавать комнаты, регистрировать юзеров, менять настройки. Не буду это описывать, каждый сам может сделать, чтобы понять продукт и познакомиться с ним получше. В целом, впечатление у меня осталось неоднозначное. Продукт неплохой, особенно в части заявленного функционала. Я нигде не видел такого же функционала бесплатно. Если у вас много времени и желания, то можно допилить до подходящего уровня, когда будет нормально работать все, что вас интересует. Но мелкие баги и ошибки, с которыми я сталкивался в процессе настройки не вселяют в меня уверенности, что все это будет стабильно работать длительное время.

Я на первое место всегда ставлю стабильность и надежность работы, даже в ущерб функционалу. Я не люблю решения, которые требуют много сил на свою поддержку. В итоге они могут оказаться дороже коммерческих продуктов. Уже сейчас могу представить, сколько вылезет ошибок при очередном обновлении. Вот мое краткое резюме по плюсам и минусам synapse matrix на основе того, что я успел попробовать и проверить.

Плюсы:

  • Обширный бесплатный функционал.
  • Свой локальный сервер
  • Гибкие настройки email оповещений. Хоть и не очень понятные настройки, но думаю, если разобраться, будет в итоге работать.
  • Контроль набора текста и прочтения сообщения. Вы видите, когда пользователь прочтет отправленное ему сообщение. Это важный и удобный функционал. Тот же mattermost или rocket.chat не предлагают этого в бесплатной версии.
  • Хороший выбор клиентов. Тот же riot есть как приложение для десктопа, для смартфона и web версия через браузер.
  • Звонки между клиентами. Никаких настроек не надо, работают сразу.

Минусы:

  • Много багов, с которыми сталкиваешься сразу же во время установки. Забыть положить файлы с шаблонами в дистрибутив и не исправить это. Мне не понятен такой подход.
  • Нету документации, кроме небольшой справки на github.
  • Очень много вопросов на гитхабе, в основном с ошибками. Пропадают сообщения, комнаты, юзеры, кого-то куда-то не пускает и т.д. Думаю со всем этим придется столкнутся после масштабного внедрения.
  • Мало информации в интернете. В русскоязычном интернете вообще ничего, кроме нескольких упоминаний, все только в англоязычном сегменте, да и то в основном краткие руководства по установке. Даже по настройке ничего не нашел, разбирался во всем сам.

Для себя сделал такой вывод – буду наблюдать за развитием. Сам нигде внедрять и пробовать не буду. Подожду какое-то время. Если взлетит, хорошо, буду пользоваться. Если будет в таком же состоянии, как сейчас, то увы, не считаю его готовым для внедрения в реально рабочие коллективы. Пока еще сыро.

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом “Administrator Linux. Professional” в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

  • Знание архитектуры Linux.
  • Освоение современных методов и инструментов анализа и обработки данных.
  • Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
  • Владение основными рабочими инструментами системного администратора.
  • Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
  • Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: