en to uk translation catalogue (397 entries)

en: "${vyos_libexecdir}/validators/foo bar $VAR(@)" will be executed, <constraintErrorMessage> will be displayed on failure
uk: &quot;${vyos_libexecdir}/validators/foo bar $VAR(@)&quot; буде виконано,<constraintErrorMessage> буде відображено в разі невдачі

en: <constraintErrorMessage> will be displayed on failure
uk: <constraintErrorMessage>буде відображено в разі невдачі

en: <properties> <completionHelp> <list> foo bar </list>
uk: <properties><completionHelp><list>foo бар</list>

en: <properties> <completionHelp> <path> vpn ipsec esp-group </path> ...
uk: <properties><completionHelp><path>vpn ipsec esp-група</path> ...

en: <properties> <completionHelp> <script> /path/to/script </script> ...
uk: <properties><completionHelp><script> /path/to/script </script>...

en: <properties> <constraint> <regex> ...
uk: <properties><constraint><regex>...

en: <properties> <help>My node</help>
uk: <properties><help>Мій вузол</help>

en: <properties> <priority>999</priority>
uk: <properties><priority>999</priority>

en: <properties> <valueHelp> <format> format </format> <description> some string </description>
uk: <properties><valueHelp><format>формат</format><description> якийсь рядок</description>

en: A fork with packaging changes for VyOS is kept at https://github.com/vyos/hvinfo
uk: Відгалуження зі змінами упаковки для VyOS зберігається на https://github.com/vyos/hvinfo

en: A good approach for writing commit messages is actually to have a look at the file(s) history by invoking ``git log path/to/file.txt``.
uk: Хорошим підходом для написання повідомлень комітів є перегляд історії файлів за допомогою ``git log path/to/file.txt``.

en: A number of flags can be set up to change the behaviour of VyOS at runtime. These flags can be toggled using either environment variables or creating files.
uk: Для зміни поведінки VyOS під час виконання можна встановити ряд прапорців. Ці прапорці можна перемикати за допомогою змінних середовища або створення файлів.

en: A single, short, summary of the commit (recommended 50 characters or less, not exceeding 80 characters) containing a prefix of the changed component and the corresponding Phabricator_ reference e.g. ``snmp: T1111:`` or ``ethernet: T2222:`` - multiple components could be concatenated as in ``snmp: ethernet: T3333``
uk: Єдиний короткий підсумок коміту (рекомендовано 50 символів або менше, не більше 80 символів), що містить префікс зміненого компонента та відповідне посилання Phabricator_, наприклад ``snmp: T1111:`` або ``ethernet: T2222:` ` - кілька компонентів можуть бути об&#39;єднані, як у ``snmp: ethernet: T3333``

en: Abbreviations and acronyms **must** be capitalized.
uk: Абревіатури та абревіатури **повинні** бути написані з великої літери.

en: Acronyms also **must** be capitalized to visually distinguish them from normal words:
uk: Акроніми також **повинні** писати з великої літери, щоб візуально відрізняти їх від звичайних слів:

en: Add file to Git index using ``git add myfile``, or for a whole directory: ``git add somedir/*``
uk: Додайте файл до індексу Git за допомогою ``git add myfile`` або для цілого каталогу: ``git add somedir/*``

en: Add one or more IP addresses
uk: Додайте одну або кілька IP-адрес

en: Address
uk: Адреса

en: After a minute or two you will find the generated DEB packages next to the vyos-1x source directory:
uk: Через хвилину або дві ви побачите згенеровані пакети DEB поруч із вихідним каталогом vyos-1x:

en: After compiling the packages you will find yourself the newly generated `*.deb` binaries in ``vyos-build/packages/linux-kernel`` from which you can copy them to the ``vyos-build/packages`` folder for inclusion during the ISO build.
uk: Після компіляції пакунків ви знайдете щойно згенеровані двійкові файли ``.deb`» у ``vyos-build/packages/linux-kernel``, звідки ви можете скопіювати їх до папки ``vyos-build/packages`` для включення під час збірки ISO.

en: After its first boot into the newly installed system the main Smoketest script is executed, it can be found here: `/usr/bin/vyos-smoketest`
uk: Після першого завантаження щойно встановленої системи виконується основний сценарій Smoketest, його можна знайти тут: `/usr/bin/vyos-smoketest`

en: All VyOS source code is hosted on GitHub under the VyOS organization which can be found here: https://github.com/vyos
uk: Весь вихідний код VyOS розміщено на GitHub в рамках організації VyOS, яку можна знайти тут: https://github.com/vyos

en: All commit time checks should be in the verify() function of the script
uk: Усі перевірки часу фіксації мають бути у функції verify() сценарію

en: All interface definition XML input files (.in suffix) will be sent to the GCC preprocess and the output is stored in the `build/interface-definitions` folder. The previously mentioned `scripts/build-command-templates` script operates on the `build/interface-definitions` folder to generate all required CLI nodes.
uk: Усі вхідні XML-файли визначення інтерфейсу (суфікс .in) буде надіслано до попередньої обробки GCC, а вихідні дані збережуться в папці `build/interface-definitions`. Згаданий раніше сценарій `scripts/build-command-templates` працює з папкою `build/interface-definitions`, щоб створити всі необхідні вузли CLI.

en: All issues should be reported to the developers. This lets the developers know what is not working properly. Without this sort of feedback every developer will believe that everything is working correctly.
uk: Про всі проблеми слід повідомляти розробників. Це дозволяє розробникам знати, що не працює належним чином. Без такого роду відгуків кожен розробник вважатиме, що все працює правильно.

en: All logic should be in the scripts
uk: Вся логіка повинна бути в скриптах

en: All text of the commit message should be wrapped at 72 characters if possible which makes reading commit logs easier with ``git log`` on a standard terminal (which happens to be 80x25)
uk: Увесь текст повідомлення коміту, якщо це можливо, має бути обернуто 72 символами, що полегшує читання журналів комітів за допомогою ``git log`` на стандартному терміналі (розмір якого буває 80x25)

en: Always use the ``-x`` option to the ``git cherry-pick`` command when back or forward porting an individual commit. This automatically appends the line: ``(cherry picked from commit <ID>)`` to the original authors commit message making it easier when bisecting problems.
uk: Завжди використовуйте опцію ``-x`` для команди ``git cherry-pick`` під час зворотного або прямого перенесення окремого коміту. Це автоматично додає рядок: ``(вишня, вибрана з коміту<ID> )`` до оригінального повідомлення авторів, що полегшує розділення проблем навпіл.

en: Another advantage is testability of the code. Mocking the entire config subsystem is hard, while constructing an internal representation by hand is way simpler.
uk: Ще однією перевагою є можливість тестування коду. Знущатися над усією підсистемою конфігурації важко, тоді як побудувати внутрішнє представлення вручну набагато простіше.

en: Any "modified" package may refer to an altered version of e.g. vyos-1x package that you would like to test before filing a pull request on GitHub.
uk: Будь-який «модифікований» пакет може стосуватися зміненої версії, наприклад пакета vyos-1x, який ви хотіли б перевірити перед тим, як подавати запит на отримання на GitHub.

en: Any packages in the packages directory will be added to the iso during build, replacing the upstream ones. Make sure you delete them (both the source directories and built deb packages) if you want to build an iso from purely upstream packages.
uk: Будь-які пакунки в каталозі пакетів буде додано до iso під час збірки, замінивши вихідні. Переконайтеся, що ви видалили їх (як вихідні каталоги, так і зібрані пакунки deb), якщо ви хочете зібрати iso з чистих пакетів.

en: As Smoketests will alter the system configuration and you are logged in remote you may loose your connection to the system.
uk: Оскільки Smoketests змінить конфігурацію системи, а ви ввійшли в систему віддалено, ви можете втратити підключення до системи.

en: As the VyOS documentation is not only for users but also for the developers - and we keep no secret documentation - this section describes how the automated testing works.
uk: Оскільки документація VyOS призначена не лише для користувачів, а й для розробників, і ми не зберігаємо документацію в секреті, у цьому розділі описано, як працює автоматизоване тестування.

en: Assume we want to build the vyos-1x package on our own and modify it to our needs. We first need to clone the repository from GitHub.
uk: Припустімо, що ми хочемо створити пакунок vyos-1x самостійно та змінити його відповідно до наших потреб. Спочатку нам потрібно клонувати репозиторій з GitHub.

en: Attach patch to Phabricator task
uk: Додайте патч до завдання Phabricator

en: Bad: "Disables IPv6 forwarding"
uk: Погано: «Вимикає переадресацію IPv6»

en: Bad: "Frobnication algorithm."
uk: Погано: «Алгоритм Frobnication».

en: Bad: "Set TCP connection timeout"
uk: Погано: «Установити тайм-аут з’єднання TCP»

en: Bad: "frobnication algorithm"
uk: Погано: &quot;алгоритм фробнікації&quot;

en: Bad: "tcp connection timeout"
uk: Погано: &quot;тайм-аут з&#39;єднання tcp&quot;

en: Bad: PPPOE, IPSEC
uk: Погано: PPPOE, IPSEC

en: Bad: pppoe, ipsec
uk: Погано: PPPOE, IPSEC

en: Bad: radius (unless it's about the distance between a center of a circle and any of its points)
uk: Погано: радіус (якщо це не відстань між центром кола та будь-якою з його точок)

en: Beeing brave and running the latest rolling releases will sometimes trigger bugs due to corner cases we missed in our design. Those bugs should be filed via Phabricator_ but you can help us to narrow doen the issue. Login to your VyOS system and change into configuration mode by typing ``configure``. Now re-load your boot configuration by simply typing ``load`` followed by return.
uk: Якщо проявити сміливість і запустити останні поточні випуски, іноді можуть виникнути помилки через кутові випадки, які ми пропустили в нашому дизайні. Ці помилки слід надсилати через Phabricator_, але ви можете допомогти нам звузити проблему. Увійдіть у свою систему VyOS і перейдіть у режим конфігурації, ввівши ``configure``. Тепер перезавантажте вашу конфігурацію завантаження, просто ввівши ``load`` і потім return.

en: Boot Timing
uk: Час завантаження

en: Bug Report/Issue
uk: Повідомлення про помилку/проблема

en: Build
uk: Будувати

en: Build Container
uk: Побудувати контейнер

en: Build ISO
uk: Збірка ISO

en: Build VyOS
uk: Збірка VyOS

en: Build from source
uk: Збірка з джерела

en: Building Out-Of-Tree Modules
uk: Створення позадеревних модулів

en: Building The Kernel
uk: Створення ядра

en: Building VyOS on Windows WSL2 with Docker integrated into WSL2 will work like a charm. No problems are known so far!
uk: Збірка VyOS на Windows WSL2 з Docker, інтегрованим у WSL2, буде працювати як чарівність. Поки що жодних проблем не відомо!

en: Building an ISO with any customized package is in no way different than building a regular (customized or not) ISO image. Simply place your modified `*.deb` package inside the `packages` folder within `vyos-build`. The build process will then pickup your custom package and integrate it into your ISO.
uk: Створення ISO за допомогою будь-якого налаштованого пакету нічим не відрізняється від створення звичайного (налаштованого чи ні) образу ISO. Просто помістіть свій змінений пакет `*.deb` в папку `packages` у `vyos-build`. Після цього процес збірки підбере ваш спеціальний пакет та інтегрує його у ваш ISO.

en: Building the kernel is one part, but now you also need to build the required out-of-tree modules so everything is lined up and the ABIs match. To do so, you can again take a look at ``vyos-build/packages/linux-kernel/Jenkinsfile`` to see all of the required modules and their selected versions. We will show you how to build all the current required modules.
uk: Збірка ядра є однією частиною, але тепер вам також потрібно зібрати необхідні модулі поза деревом, щоб усе було вирівняно та відповідали ABI. Щоб зробити це, ви можете ще раз переглянути ``vyos-build/packages/linux-kernel/Jenkinsfile``, щоб побачити всі необхідні модулі та їх вибрані версії. Ми покажемо вам, як створити всі поточні необхідні модулі.

en: Building the kernel will take some time depending on the speed and quantity of your CPU/cores and disk speed. Expect 20 minutes (or even longer) on lower end hardware.
uk: Створення ядра займе деякий час залежно від швидкості та кількості процесора/ядер і швидкості диска. Очікуйте 20 хвилин (або навіть більше) на нижчому обладнанні.

en: Building using a :ref:`build_docker` container, although not the only way, is the easiest way as all dependencies are managed for you. However, you can also set up your own build machine and run a :ref:`build_native`.
uk: Збірка за допомогою контейнера :ref:`build_docker`, хоч і не єдиний спосіб, є найпростішим шляхом, оскільки всі залежності керуються за вас. Однак ви також можете налаштувати власну машину збирання та запустити :ref:`build_native`.

en: But we are here to assist you and want to guide you through how you can become a good VyOS contributor. The rules we have are not there to punish you - the rules are in place to help us all. What does it mean? By having a consistent coding style it becomes very easy for new contributors and also longtime contributors to navigate through the sources and all the implied logic of the spaghetti code.
uk: Але ми тут, щоб допомогти вам, і хочемо допомогти вам, як ви можете стати хорошим учасником VyOS. Наші правила створені не для того, щоб карати вас, а для того, щоб допомогти нам усім. Що це означає? Маючи послідовний стиль кодування, новачкам і давнім учасникам стає дуже легко орієнтуватися в джерелах і всій неявній логіці спагетті-коду.

en: C++ Backend Code
uk: Базовий код C++

en: Capitalization and punctuation
uk: Вживання великої літери та пунктуація

en: Check out the required kernel version - see ``vyos-build/data/defaults.json`` file (example uses kernel 4.19.146):
uk: Перевірте потрібну версію ядра - перегляньте файл ``vyos-build/data/defaults.json`` (у прикладі використовується ядро 4.19.146):

en: Clone the kernel source to `vyos-build/packages/linux-kernel/`:
uk: Клонуйте джерело ядра до `vyos-build/packages/linux-kernel/`:

en: Clone: ``git clone https://github.com/<user>/vyos-1x.git``
uk: Клон: ``git clone https://github.com/<user> /vyos-1x.git``

en: Coding Guidelines
uk: Інструкції з кодування

en: Command definitions are purely declarative, and cannot contain any logic. All logic for generating config files for target applications, restarting services and so on is implemented in configuration scripts instead.
uk: Визначення команд є суто декларативними і не можуть містити жодної логіки. Натомість уся логіка для створення файлів конфігурації для цільових програм, перезапуску служб тощо реалізована в сценаріях конфігурації.

en: Commit the changes by calling ``git commit``. Please use a meaningful commit headline (read above) and don't forget to reference the Phabricator_ ID.
uk: Зафіксуйте зміни, викликавши ``git commit``. Будь ласка, використовуйте змістовний заголовок коміту (прочитайте вище) і не забудьте вказати посилання на Phabricator_ ID.

en: Config Load Tests
uk: Тести навантаження конфігурації

en: Config Migration Scripts
uk: Налаштувати сценарії міграції

en: Configuration Error on System Boot
uk: Помилка конфігурації під час завантаження системи

en: Configuration Script Structure and Behaviour
uk: Структура та поведінка сценарію конфігурації

en: Consult the documentation_ to ensure that you have configured your system correctly
uk: Зверніться до документації_, щоб переконатися, що ви правильно налаштували свою систему

en: Continuous Integration
uk: Безперервна інтеграція

en: Customize
uk: Налаштувати

en: DHCP client and DHCPv6 prefix delegation
uk: Клієнт DHCP і делегування префікса DHCPv6

en: DMVPN patches are added by this commit: https://github.com/vyos/vyos-strongswan/commit/1cf12b0f2f921bfc51affa3b81226
uk: Патчі DMVPN додаються цим комітом: https://github.com/vyos/vyos-strongswan/commit/1cf12b0f2f921bfc51affa3b81226

en: Debian APT is not very verbose when it comes to errors. If your ISO build breaks for whatever reason and you suspect it's a problem with APT dependencies or installation you can add this small patch which increases the APT verbosity during ISO build.
uk: Debian APT не дуже багатослівний, коли йдеться про помилки. Якщо ваша збірка ISO ламається з будь-якої причини, і ви підозрюєте, що це проблема із залежностями APT або інсталяцією, ви можете додати цей невеликий патч, який збільшує детальність APT під час збірки ISO.

en: Debian Bullseye for VyOS 1.4 (sagitta, current) - aka the rolling release
uk: Debian Bullseye для VyOS 1.4 (sagitta, поточний) - також поточний випуск

en: Debian Buster for VyOS 1.3 (equuleus)
uk: Debian Buster для VyOS 1.3 (equuleus)

en: Debian Jessie for VyOS 1.2 (crux)
uk: Debian Jessie для VyOS 1.2 (суть)

en: Debian does keep their package in git, but it's upstream tarball imported into git without its original commit history. To be able to merge new tags in, we keep a fork of the upstream repository with packaging files imported from Debian at https://github.com/vyos/keepalived-upstream
uk: Debian справді зберігає свій пакет у git, але це архівний архів, імпортований у git без оригінальної історії комітів. Щоб мати можливість об’єднувати нові теги, ми зберігаємо розгалуження репозиторію upstream із файлами пакувань, імпортованими з Debian, за адресою https://github.com/vyos/keepalived-upstream

en: Debugging
uk: Налагодження

en: Debugging Python Code with PDB
uk: Налагодження коду Python за допомогою PDB

en: Description
uk: Опис

en: Determinine source package
uk: Визначте вихідний пакет

en: Development
uk: розвиток

en: Do not add angle brackets around the format, they will be inserted automatically
uk: Не додавайте кутові дужки навколо формату, вони будуть вставлені автоматично

en: Docker
uk: Докер

en: Doing so grants privileges equivalent to the ``root`` user! It is recommended to remove the non-root user from the ``docker`` group after building the VyOS ISO. See also `Docker as non-root`_.
uk: Це надає привілеї, еквівалентні користувачам ``root``! Рекомендується видалити некоренева користувача з групи ``docker`` після створення VyOS ISO. Дивіться також `Docker як non-root`_.

en: Due to issues in the upstream version that sometimes set interfaces down, a modified version is used.
uk: Через проблеми у попередній версії, через які іноді інтерфейси не працюють, використовується модифікована версія.

en: During the migration and extensive rewrite of functionality from Perl into Python a significant increase in the overall system boottime was noticed. The system boot time can be analysed and a graph can be generated in the end which shows in detail who called whom during the system startup phase.
uk: Під час міграції та значного переписування функціональності з Perl на Python було помічено значне збільшення загального часу завантаження системи. Можна проаналізувати час завантаження системи та зрештою створити графік, який детально показує, хто кому телефонував під час фази запуску системи.

en: Each module is build on demand if a new commit on the branch in question is found. After a successful run the resulting Debian Package(s) will be deployed to our Debian repository which is used during build time. It is located here: http://dev.packages.vyos.net/repositories/.
uk: Кожен модуль збирається на вимогу, якщо знайдено новий коміт у відповідній гілці. Після успішного запуску отриманий пакет(и) Debian буде розгорнуто в нашому репозиторії Debian, який використовується під час збирання. Він знаходиться тут: http://dev.packages.vyos.net/repositories/.

en: Each of those modules holds a dependency on the kernel version and if you are lucky enough to receive an ISO build error which sounds like:
uk: Кожен із цих модулів залежить від версії ядра, і якщо вам пощастить отримати помилку збірки ISO, яка звучить так:

en: Enabled/Disabled
uk: Увімкнено/вимкнено

en: Ensure the problem is reproducible
uk: Переконайтеся, що проблему можна відтворити

en: Every change set must be consistent (self containing)! Do not fix multiple bugs in a single commit. If you already worked on multiple fixes in the same file use `git add --patch` to only add the parts related to the one issue into your upcoming commit.
uk: Кожен набір змін має бути узгодженим (самовмісним)! Не виправляйте кілька помилок в одному коміті. Якщо ви вже працювали над кількома виправленнями в одному файлі, скористайтеся `git add --patch`, щоб додати лише частини, пов’язані з однією проблемою, у ваш майбутній комміт.

en: Example:
uk: приклад:

en: Examples:
uk: приклади:

en: Exceptions, including ``VyOSError`` (which is raised by ``vyos.config.Config`` on improper config operations, such as trying to use ``list_nodes()`` on a non-tag node) should not be silenced or caught and re-raised as config error. Sure this will not look pretty on user's screen, but it will make way better bug reports, and help users (and most VyOS users are IT professionals) do their own debugging as well.
uk: Винятки, включно з ``VyOSError`` (який викликає ``vyos.config.Config`` під час неправильних операцій конфігурації, таких як спроба використання ``list_nodes()`` на вузлі без тегів), не слід вимикати. або перехоплено та повторно піднято як помилку конфігурації. Звісно, це не виглядатиме гарно на екрані користувача, але це покращить звіти про помилки та допоможе користувачам (а більшість користувачів VyOS є ІТ-фахівцями) також виконувати власне налагодження.

en: Export last commit to patch file: ``git format-patch`` or export the last two commits into its appropriate patch files: ``git format-patch -2``
uk: Експортуйте останній комміт у файл виправлення: ``git format-patch`` або експортуйте останні два коміти у відповідні файли виправлення: ``git format-patch -2``

en: External arithmetic validator may be added if there's demand, complex validation is better left to commit-time scripts
uk: Зовнішній арифметичний валідатор може бути доданий, якщо є попит, складну перевірку краще залишити для сценаріїв під час фіксації

en: Feature Request
uk: Запит на функцію

en: Firmware
uk: Прошивка

en: First, clone the source code and check out the appropriate version by running:
uk: Спочатку клонуйте вихідний код і перевірте відповідну версію, виконавши:

en: Follow the above steps on how to "Fork repository to submit a Patch". Instead of uploading "pushing" your changes to GitHub you can export the patches/ commits and send it to maintainers@vyos.net or attach it directly to the bug (preferred over email)
uk: Дотримуйтеся наведених вище кроків, щоб «форкувати репозиторій, щоб надіслати виправлення». Замість того, щоб завантажувати свої зміни на GitHub, ви можете експортувати виправлення/коміти та надіслати їх на supporters@vyos.net або прикріпити безпосередньо до помилки (бажано, ніж електронною поштою)

en: Followed by a message which describes all the details like:
uk: Далі слідує повідомлення з описом усіх деталей, таких як:

en: For each feature, a file called ``vyos.feature.debug`` can be created to toggle the feature on. If a parameter is required it can be placed inside the file as its first line.
uk: Для кожної функції можна створити файл під назвою ``vyos.feature.debug``, щоб увімкнути функцію. Якщо параметр потрібен, його можна розмістити всередині файлу як його перший рядок.

en: For easy orientation we suggest you take a look on the ``ntp.py`` or ``interfaces-bonding.py`` (for tag nodes) implementation. Both files can be found in the vyos-1x_ repository.
uk: Для легкої орієнтації ми пропонуємо вам поглянути на реалізацію ``ntp.py`` або ``interfaces-bonding.py`` (для вузлів тегів). Обидва файли можна знайти в репозиторії vyos-1x_.

en: For example running, ``export VYOS_IFCONFIG_DEBUG=""`` on your vbash, will have the same effect as ``touch /tmp/vyos.ifconfig.debug``.
uk: Наприклад, запуск ``export VYOS_IFCONFIG_DEBUG=&quot;&quot;`` на вашому vbash матиме той самий ефект, що ``touch /tmp/vyos.ifconfig.debug``.

en: For example, ``/tmp/vyos.ifconfig.debug`` can be created to enable interface debugging.
uk: Наприклад, ``/tmp/vyos.ifconfig.debug`` можна створити, щоб увімкнути налагодження інтерфейсу.

en: For the packages required, you can refer to the ``docker/Dockerfile`` file in the repository_. The ``./build-vyos-image`` script will also warn you if any dependencies are missing.
uk: Для отримання необхідних пакетів ви можете звернутися до файлу ``docker/Dockerfile`` у repository_. Сценарій ``./build-vyos-image`` також попередить вас, якщо будь-які залежності відсутні.

en: Fork Repository and submit Patch
uk: Форк репозиторію та надішліть патч

en: Fork: ``git remote add myfork https://github.com/<user>/vyos-1x.git``
uk: Fork: ``git remote add myfork https://github.com/<user> /vyos-1x.git``

en: Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS. You can fork any VyOS repository to your very own GitHub account by just appending ``/fork`` to any repository's URL on GitHub. To e.g. fork the ``vyos-1x`` repository, open the following URL in your favourite browser: https://github.com/vyos/vyos-1x/fork
uk: Розгалуження репозиторію та надсилання запиту на отримання GitHub є кращим способом надсилання ваших змін до VyOS. Ви можете розділити будь-яке сховище VyOS на свій власний обліковий запис GitHub, просто додавши ``/fork`` до URL-адреси будь-якого сховища на GitHub. Щоб, наприклад, розгалужити репозиторій ``vyos-1x``, відкрийте наступну URL-адресу у вашому улюбленому браузері: https://github.com/vyos/vyos-1x/fork

en: Formatting
uk: Форматування

en: GNU Preprocessor
uk: Препроцесор GNU

en: Get community support via Slack_ or our Forum_
uk: Отримайте підтримку спільноти через Slack_ або наш форум_

en: Good luck!
uk: Удачі!

en: Good: "Disable IPv6 forwarding"
uk: Добре: «Вимкнути переадресацію IPv6»

en: Good: "Frobnication algorithm"
uk: Добре: &quot;Алгоритм Frobnication&quot;

en: Good: "TCP connection timeout"
uk: Добре: &quot;Тайм-аут з&#39;єднання TCP&quot;

en: Good: PPPoE, IPsec
uk: Добре: PPPoE, IPsec

en: Good: RADIUS (as in remote authentication for dial-in user services)
uk: Хороший: RADIUS (як у віддаленій автентифікації для телефонних служб користувачів)

en: Guidelines
uk: Настанови

en: Help String
uk: Рядок довідки

en: Help future maintainers of VyOS (it could be you!) to find out why certain things have been changed in the codebase or why certain features have been added
uk: Допоможіть майбутнім супроводжувачам VyOS (це можете бути ви!) дізнатися, чому певні речі були змінені в кодовій базі або чому були додані певні функції

en: Horrible: "Tcp connection timeout"
uk: Жахливо: &quot;Тайм-аут підключення TCP&quot;

en: Horrible: "frobnication algorithm."
uk: Жахливо: &quot;алгоритм фробнікації&quot;.

en: How can we reproduce this Bug?
uk: Як ми можемо відтворити цю помилку?

en: I have found a bug, what should I do?
uk: Я знайшов помилку, що мені робити?

en: IP and IPv6 options
uk: Варіанти IP та IPv6

en: ISO Build Issues
uk: Проблеми збірки ISO

en: ISO image build
uk: Створення образу ISO

en: If a verb is essential, keep it. For example, in the help text of ``set system ipv6 disable-forwarding``, "Disable IPv6 forwarding on all interfaces" is a perfectly justified wording.
uk: Якщо дієслово важливе, збережіть його. Наприклад, у довідковому тексті ``set system ipv6 disable-forwarding``, «Вимкнути пересилання IPv6 на всіх інтерфейсах» є цілком виправданим формулюванням.

en: If applicable a reference to a previous commit should be made linking those commits nicely when browsing the history: ``After commit abcd12ef ("snmp: this is a headline") a Python import statement is missing, throwing the following exception: ABCDEF``
uk: Якщо застосовно, має бути зроблено посилання на попередній комміт, який гарно зв’язує ці коміти під час перегляду історії: ``Після фіксації abcd12ef (&quot;snmp: це заголовок&quot;) відсутній оператор імпорту Python, викликаючи такий виняток: ABCDEF``

en: If there is no Phabricator_ reference in the commits of your pull request, we have to ask you to amend the commit message. Otherwise we will have to reject it.
uk: Якщо у комітах вашого запиту на отримання відсутнє посилання Phabricator_, ми маємо попросити вас змінити повідомлення коміту. Інакше нам доведеться його відхилити.

en: If you are brave enough to build yourself an ISO image containing any modified package from our GitHub organisation - this is the place to be.
uk: Якщо у вас достатньо сміливості, щоб самостійно створити образ ISO, який містить будь-який модифікований пакет від нашої організації GitHub – це те місце, щоб бути.

en: If you upgrade your kernel or include new drivers you may need new firmware. Build a new ``vyos-linux-firmware`` package with the included helper scripts.
uk: Якщо ви оновлюєте ядро або додаєте нові драйвери, вам може знадобитися нове мікропрограмне забезпечення. Створіть новий пакет ``vyos-linux-firmware`` із доданими допоміжними сценаріями.

en: In a big system, such as VyOS, that is comprised of multiple components, it's impossible to keep track of all the changes and bugs/feature requests in one's head. We use a bugtracker known as Phabricator_ for it ("issue tracker" would be a better term, but this one stuck).
uk: У великій системі, такій як VyOS, яка складається з кількох компонентів, неможливо відстежувати всі зміни та помилки/запити на функції в своїй голові. Для цього ми використовуємо багтрекер, відомий як Phabricator_ (кращим терміном був би «трекер проблем», але цей застряг).

en: In addition this also helps when browsing the GitHub codebase on a mobile device if you happen to be a crazy scientist.
uk: Крім того, це також допоможе під час перегляду кодової бази GitHub на мобільному пристрої, якщо ви випадково божевільний учений.

en: In order to open up a bug-report/feature request you need to create yourself an account on VyOS Phabricator_. On the left side of the specific project (VyOS 1.2 or VyOS 1.3) you will find quick-links for opening a bug-report/feature request.
uk: Щоб відкрити звіт про помилку/запит на функцію, вам потрібно створити обліковий запис на VyOS Phabricator_. У лівій частині конкретного проекту (VyOS 1.2 або VyOS 1.3) ви знайдете швидкі посилання для відкриття звіту про помилку/запиту функції.

en: In order to record you as the author of the fix please identify yourself to Git by setting up your name and email. This can be done local for this one and only repository ``git config`` or globally using ``git config --global``.
uk: Щоб записати вас як автора виправлення, ідентифікуйте себе в Git, вказавши своє ім’я та електронну адресу. Це можна зробити локально для цього єдиного сховища ``git config`` або глобально за допомогою ``git config --global``.

en: In order to retrieve the debug output on the command-line you need to disable ``vyos-configd`` in addition. This can be run either one-time by calling ``sudo systemctl stop vyos-configd`` or make this reboot-safe by calling ``sudo systemctl disable vyos-configd``.
uk: Щоб отримати вихідні дані налагодження в командному рядку, вам потрібно додатково вимкнути ``vyos-configd``. Це можна запустити одноразово, викликавши ``sudo systemctl stop vyos-configd``, або зробити це перезавантаження безпечним, викликавши ``sudo systemctl disable vyos-configd``.

en: In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
uk: У деяких контекстах перший рядок вважається темою електронного листа, а решта тексту – основним. Порожній рядок, що відокремлює резюме від основної частини, є критичним (якщо ви повністю не пропускаєте основної частини); такі інструменти, як rebase, можуть заплутатися, якщо ви запускаєте обидва разом.

en: In the end you will be presented with the kernel binary packages which you can then use in your custom ISO build process, by placing all the `*.deb` files in the vyos-build/packages folder where they will be used automatically when building VyOS as documented above.
uk: Наприкінці вам буде надано бінарні пакети ядра, які потім ви зможете використати у своєму спеціальному процесі збірки ISO, помістивши всі файли `*.deb` у папку vyos-build/packages, де вони автоматично використовуватимуться під час збирання VyOS, як зазначено вище.

en: In the future, we may switch to using systemd infrastructure instead. Building it doesn't require a special procedure.
uk: У майбутньому ми можемо перейти на використання інфраструктури systemd. Його виготовлення не вимагає особливої процедури.

en: Include output
uk: Включити вихід

en: Insert the following statement right before the section where you want to investigate a problem (e.g. a statement you see in a backtrace): ``import pdb; pdb.set_trace()`` Optionally you can surrounded this statement by an ``if`` which only triggers under the condition you are interested in.
uk: Вставте наступний оператор безпосередньо перед розділом, де ви хочете дослідити проблему (наприклад, оператор, який ви бачите у зворотному трасуванні): ``import pdb; pdb.set_trace()`` За бажанням ви можете оточити цей оператор ``if``, який запускається лише за умови, яка вас цікавить.

en: Install
uk: Встановити

en: Install https://pypi.org/project/stdeb/
uk: Встановити https://pypi.org/project/stdeb/

en: Installing Docker_ and prerequisites:
uk: Встановлення Docker_ і передумови:

en: Instead of supplying all those XML nodes multiple times there are now include files with predefined features. Brief overview:
uk: Замість надання всіх цих XML-вузлів багаторазово, тепер є файли включення з попередньо визначеними функціями. Короткий огляд:

en: Intel NIC drivers
uk: Драйвери Intel NIC

en: Interface based tests
uk: Тести на основі інтерфейсу

en: Issues or bugs are found in any software project. VyOS is not an exception.
uk: Проблеми чи помилки можна знайти в будь-якому програмному проекті. VyOS не є винятком.

en: Issues/Feature requests
uk: Проблеми/запити на функції

en: It is also possible to set up the debugging using environment variables. In that case, the name will be (in uppercase) VYOS_FEATURE_DEBUG.
uk: Також можна налаштувати налагодження за допомогою змінних середовища. У такому випадку ім’я буде (у верхньому регістрі) VYOS_FEATURE_DEBUG.

en: It's an Ada program and requires GNAT and gprbuild for building, dependencies are properly specified so just follow debuild's suggestions.
uk: Це програма на Ada, для створення якої потрібні GNAT і gprbuild, залежності вказані належним чином, тому просто дотримуйтеся порад debuild.

en: Jenkins CI
uk: Дженкінс CI

en: Just install using the following commands:
uk: Просто встановіть за допомогою таких команд:

en: Keep track of the progress (what we've already done in this branch and what we still need to do).
uk: Слідкуйте за прогресом (що ми вже зробили в цій гілці і що нам ще потрібно зробити).

en: Keepalived normally isn't updated to newer feature releases between Debian versions, so we are building it from source.
uk: Keepalived зазвичай не оновлюється до нових версій функцій між версіями Debian, тому ми будуємо його з початкового коду.

en: Kernel
uk: Ядро

en: Launch Docker container and build package
uk: Запустіть контейнер Docker і створіть пакет

en: Leaf nodes (nodes with values) use <leafNode> tag instead
uk: Використання листових вузлів (вузлів із значеннями).<leafNode> натомість тег

en: Let us assume you want to debug a Python script that is called by an op-mode command. After you found the script by looking up the op-mode-defitions you can edit the script in the live system using e.g. vi: ``vi /usr/libexec/vyos/op_mode/show_xyz.py``
uk: Припустімо, ви хочете налагодити сценарій Python, який викликається командою режиму op-mode. Після того, як ви знайшли сценарій, переглянувши op-mode-defitions, ви можете редагувати сценарій у живій системі, наприклад, за допомогою vi: ``vi /usr/libexec/vyos/op_mode/show_xyz.py``

en: Let's face it: VyOS is full of spaghetti code where logic for reading the VyOS config, generating daemon configs, and restarting processes is all mixed up.
uk: Давайте подивимося правді в очі: VyOS наповнена спагетті-кодом, де логіка читання конфігурації VyOS, генерації конфігурацій демона та перезапуску процесів змішана.

en: Like any other project we have some small guidelines about our source code, too. The rules we have are not there to punish you - the rules are in place to help us all. By having a consistent coding style it becomes very easy for new and also longtime contributors to navigate through the sources and all the implied logic of any one source file..
uk: Як і в будь-якому іншому проекті, у нас також є деякі невеликі вказівки щодо вихідного коду. Наші правила створені не для того, щоб карати вас, а для того, щоб допомогти нам усім. Маючи послідовний стиль кодування, новачкам і давнім учасникам стає дуже легко орієнтуватися в джерелах і всій неявній логіці будь-якого вихідного файлу.

en: Limits:
uk: Обмеження:

en: Linux Kernel
uk: Ядро Linux

en: Live System
uk: Жива система

en: MTU size
uk: Розмір PERSON

en: Make your changes and save them. Do the following for all changes files to record them in your created Git commit:
uk: Внесіть зміни та збережіть їх. Зробіть наступне для всіх файлів змін, щоб записати їх у створений комміт Git:

en: Manual Smoketest Run
uk: Ручний запуск Smoketest

en: Manual config load test
uk: Навантажувальний тест конфігурації вручну

en: Many base system packages are pulled straight from Debian's main and contrib repositories, but there are exceptions.
uk: Багато базових системних пакетів витягуються безпосередньо з основних сховищ Debian і contrib, але є винятки.

en: Migrating old CLI
uk: Перенесення старого CLI

en: Move default values to scripts
uk: Перемістити значення за замовчуванням у сценарії

en: Native Build
uk: Рідна збірка

en: New syntax
uk: Новий синтаксис

en: No code incompatible with Python3
uk: Немає коду, несумісного з Python3

en: No new features in Perl
uk: У Perl немає нових функцій

en: No old style command definitions
uk: Немає старих визначень команд

en: No special build procedure is required.
uk: Спеціальна процедура нарощування не потрібна.

en: None
uk: Жодного

en: Notes
uk: Примітки

en: Now a fresh build of the VyOS ISO can begin. Change directory to the ``vyos-build`` directory and run:
uk: Тепер можна почати нову збірку VyOS ISO. Змініть каталог на каталог ``vyos-build`` і запустіть:

en: Now as you are aware of the prerequisites we can continue and build our own ISO from source. For this we have to fetch the latest source code from GitHub. Please note as this will differ for both `current` and `crux`.
uk: Тепер, коли ви знаєте про передумови, ми можемо продовжити і створювати власний ISO з початкового коду. Для цього нам потрібно отримати останній вихідний код з GitHub. Зауважте, що це буде різним для `current` і `crux`.

en: Now it's time to fix the package mirror and rerun the last step until the package installation succeeds again!
uk: Тепер настав час виправити дзеркало пакета та повторити останній крок, доки інсталяція пакета не вдасться знову!

en: Now we can use the helper script ``build-kernel.sh`` which does all the necessary voodoo by applying required patches from the `vyos-build/packages/linux-kernel/patches` folder, copying our kernel configuration ``x86_64_vyos_defconfig`` to the right location, and finally building the Debian packages.
uk: Тепер ми можемо використати допоміжний скрипт ``build-kernel.sh``, який виконує всі необхідні вуду, застосовуючи необхідні патчі з папки `vyos-build/packages/linux-kernel/patches`, копіюючи нашу конфігурацію ядра ``x86_64_vyos_defconfig` `` у потрібне розташування та, нарешті, збирання пакунків Debian.

en: Now you are prepared with two new aliases ``vybld`` and ``vybld_crux`` to spawn your development containers in your current working directory.
uk: Тепер у вас є два нові псевдоніми ``vybld`` і ``vybld_crux`` для створення ваших контейнерів розробки у вашому поточному робочому каталозі.

en: Old concept/syntax
uk: Стара концепція/синтаксис

en: On the other hand - as each test is contain in its own file - one can always execute a single Smoketest by hand by simply running the Python test scripts.
uk: З іншого боку, оскільки кожен тест міститься в окремому файлі, можна завжди виконати один Smoketest вручну, просто запустивши тестові сценарії Python.

en: Once you have the required dependencies installed, you may proceed with the steps described in :ref:`build_iso`.
uk: Після встановлення необхідних залежностей ви можете продовжити кроки, описані в :ref:`build_iso`.

en: Once you run ``show xyz`` and your condition is triggered you should be dropped into the python debugger:
uk: Щойно ви запустите ``show xyz`` і ваша умова спрацює, ви повинні перейти до налагоджувача python:

en: One is not bound to load all configurations one after another but can also load individual test configurations on his own.
uk: Людина не зобов’язана завантажувати всі конфігурації одну за одною, але також може завантажувати окремі тестові конфігурації самостійно.

en: One of the major advantages introduced in VyOS 1.3 is an autmated test framework. When assembling an ISO image multiple things can go wrong badly and publishing a faulty ISO makes no sense. The user is disappointed by the quality of the image and the developers get flodded with bug reports over and over again.
uk: Однією з головних переваг VyOS 1.3 є автоматизована тестова структура. Під час збирання образу ISO багато речей можуть піти не так, і публікація несправного ISO не має сенсу. Користувач розчарований якістю зображення, а розробники знову і знову отримують повідомлення про помилки.

en: Only applicable to leaf nodes
uk: Застосовується лише до листових вузлів

en: Other packages (e.g. vyos-1x) add dependencies to the ISO build procedure on e.g. the wireguard-modules package which itself adds a dependency on the kernel version used due to the module it ships. This may change (for WireGuard) in future kernel releases but as long as we have out-of-tree modules.
uk: Інші пакунки (наприклад, vyos-1x) додають залежності до процедури збирання ISO, наприклад, пакунок wireguard-modules, який сам по собі додає залежність від версії ядра, що використовується через модуль, який він постачає. Це може змінитися (для WireGuard) у майбутніх випусках ядра, але якщо у нас є модулі поза деревом.

en: Our StrongSWAN build differs from the upstream:
uk: Наша збірка StrongSWAN відрізняється від попередньої:

en: Our `VyOS CI`_ system is based on Jenkins and builds all our required packages for VyOS 1.2 to 1.4. In addition to the package build, there is the vyos-build Job which builds and tests the VyOS ISO image which is published after a successfull test drive.
uk: Наша система `VyOS CI`_ заснована на Jenkins і збирає всі необхідні пакети для VyOS 1.2-1.4. Окрім збірки пакета, існує завдання vyos-build, яке створює та тестує ISO-образ VyOS, який публікується після успішного тестування.

en: Our code is split into several modules. VyOS is composed of multiple individual packages, some of them are forks of upstream packages and are periodically synced with upstream, so keeping the whole source under a single repository would be very inconvenient and slow. There is now an ongoing effort to consolidate all VyOS-specific framework/config packages into vyos-1x package, but the basic structure is going to stay the same, just with fewer and fewer packages while the base code is rewritten from Perl/BASH into Python using and XML based interface definition for the CLI.
uk: Наш код розбитий на кілька модулів. VyOS складається з кількох окремих пакетів, деякі з них є розгалуженнями вихідних пакетів і періодично синхронізуються з попереднім потоком, тому зберігати весь вихідний код в одному репозиторії було б дуже незручно та повільно. Зараз тривають спроби консолідувати всі специфічні для VyOS пакети рамок/налаштувань у пакет vyos-1x, але базова структура залишиться незмінною, лише з дедалі меншою кількістю пакетів, тоді як базовий код переписується з Perl/BASH на Використання Python і визначення інтерфейсу на основі XML для CLI.

en: Our op mode scripts use the python-vici module, which is not included in Debian's build, and isn't quite easy to integrate in that build. For this reason we debianize that module by hand now, using this procedure:
uk: Наші сценарії операційного режиму використовують модуль python-vici, який не входить до збірки Debian, і його нелегко інтегрувати в цю збірку. З цієї причини ми зараз дебіанізуємо цей модуль вручну, використовуючи цю процедуру:

en: Our smoketests not only test daemons and serives, but also check if what we configure for an interface works. Thus there is a common base classed named: ``base_interfaces_test.py`` which holds all the common code that an interface supports and is tested.
uk: Наші smoketests не лише перевіряють демони та сервери, а й перевіряють, чи працює те, що ми налаштували для інтерфейсу. Таким чином, існує загальний базовий клас під назвою: ``base_interfaces_test.py``, який містить увесь загальний код, який підтримує і тестується інтерфейсом.

en: Packages
uk: Пакети

en: Patches are always more than welcome. To have a clean and easy to maintain repository we have some guidelines when working with Git. A clean repository eases the automatic generation of a changelog file.
uk: Патчі завжди більш ніж вітаються. Щоб мати чистий і простий в обслуговуванні репозиторій, у нас є деякі рекомендації щодо роботи з Git. Чисте сховище полегшує автоматичне створення файлу журналу змін.

en: Patches for DMVPN are merged in
uk: Патчі для DMVPN об’єднані

en: Please leave a comment explaining why the priority was chosen (e.g. "after interfaces are configured")
uk: Залиште коментар, пояснюючи, чому було обрано пріоритет (наприклад, «після налаштування інтерфейсів»)

en: Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS GitHub organisation at https://github.com/vyos
uk: Будь ласка, надішліть свої виправлення за допомогою відомого запиту GitHub для наших репозиторіїв, які знаходяться в організації VyOS GitHub за адресою https://github.com/vyos

en: Please use the following template as good starting point when developing new modules or even rewrite a whole bunch of code in the new style XML/Pyhon interface.
uk: Будь ласка, використовуйте наступний шаблон як хорошу відправну точку під час розробки нових модулів або навіть перепишіть цілу купу коду в новому стилі інтерфейсу XML/Pyhon.

en: Port description
uk: Опис порту

en: Port disable
uk: Вимкнути порт

en: Prefer infinitives
uk: Віддавайте перевагу інфінітивам

en: Prepare patch/commit
uk: Підготуйте патч/комміт

en: Prepare release notes for upcoming releases
uk: Підготуйте примітки до випуску для майбутніх випусків

en: Prerequisites
uk: передумови

en: Priorities
uk: Пріоритети

en: Provide as much information as you can
uk: Надайте якомога більше інформації

en: Python (or any other language, for that matter) does not provide automatic protection from bad design, so we need to also devise design guidelines and follow them to keep the system extensible and maintainable.
uk: Python (або будь-яка інша мова, якщо на те пішло) не забезпечує автоматичного захисту від поганого дизайну, тому нам також потрібно розробити вказівки щодо дизайну та слідувати їм, щоб зберегти систему розширюваною та зручною для обслуговування.

en: Python 3 **shall** be used. How long can we keep Python 2 alive anyway? No considerations for Python 2 compatibility **should** be taken at any time.
uk: **Потрібно** використовувати Python 3. Як довго ми можемо підтримувати Python 2? Жодних міркувань щодо сумісності з Python 2 **не слід** враховувати.

en: Python: Tabs **shall not** be used. Every indentation level should be 4 spaces
uk: Python: вкладки **не можна** використовувати. Кожен рівень відступу повинен складатися з 4 пробілів

en: Rationale: this seems to be the unwritten standard in network device CLIs, and a good aesthetic compromise.
uk: Обґрунтування: це здається неписаним стандартом у CLI мережевих пристроїв і хорошим естетичним компромісом.

en: Recent versions use the ``vyos.frr`` framework. The Python class is located inside our ``vyos-1x:python/vyos/frr.py``. It comes with an embedded debugging/ (print style) debugger as vyos.ifconfig does.
uk: В останніх версіях використовується структура ``vyos.frr``. Клас Python знаходиться всередині нашого ``vyos-1x:python/vyos/frr.py``. Він постачається із вбудованим налагоджувачем налагодження/(стиль друку), як це робить vyos.ifconfig.

en: Report a Bug
uk: Повідомити про помилку

en: Run the following command after building the ISO image.
uk: Виконайте наступну команду після створення образу ISO.

en: Run the following command after building the QEMU image.
uk: Виконайте наступну команду після створення образу QEMU.

en: Simply use our wrapper script to build all of the driver modules.
uk: Просто використовуйте наш сценарій оболонки, щоб створити всі модулі драйвера.

en: Since VyOS has switched to Debian (11) Bullseye in its ``current`` branch, you will require individual container for `current`, `equuleus` and `crux` builds.
uk: Оскільки VyOS перейшла на Debian (11) Bullseye у своїй гілці ``current``, вам знадобиться окремий контейнер для збірок `current`, `equuleus` і `crux`.

en: Smoketests
uk: Димові тести

en: Smoketests executes predefined VyOS CLI commands and checks if the desired daemon/service configuration is rendert - that is how to put it "short".
uk: Smoketests виконує попередньо визначені команди CLI VyOS і перевіряє, чи відображено потрібну конфігурацію демона/сервісу – тобто, як це сказати «коротко».

en: So if you plan to build your own custom ISO image and wan't to make use of our smoketests, ensure that you have the `vyos-1x-smoketest` package installed.
uk: Отже, якщо ви плануєте створити власний власний образ ISO і не хочете використовувати наші тести smoketest, переконайтеся, що у вас встановлено пакет `vyos-1x-smoketest`.

en: Some VyOS packages (namely vyos-1x) come with build-time tests which verify some of the internal library calls that they work as expected. Those tests are carried out through the Python Unittest module. If you want to build the ``vyos-1x`` package (which is our main development package) you need to start your Docker container using the following argument: ``--sysctl net.ipv6.conf.lo.disable_ipv6=0``, otherwise those tests will fail.
uk: Деякі пакунки VyOS (а саме vyos-1x) постачаються з тестами під час збирання, які перевіряють, що деякі внутрішні виклики бібліотеки працюють належним чином. Ці тести виконуються за допомогою модуля Python Unittest. Якщо ви хочете створити пакет ``vyos-1x`` (який є нашим основним пакетом розробки), вам потрібно запустити свій контейнер Docker за допомогою такого аргументу: ``--sysctl net.ipv6.conf.lo.disable_ipv6=0 ``, інакше ці тести будуть невдалими.

en: Some abbreviations are traditionally written in mixed case. Generally, if it contains words "over" or "version", the letter **should** be lowercase. If there's an accepted spelling (especially if defined by an RFC or another standard), it **must** be followed.
uk: Деякі абревіатури традиційно пишуться у змішаному регістрі. Як правило, якщо він містить слова «над» або «версія», літера **повинна** бути малою. Якщо існує прийнятний варіант написання (особливо якщо він визначений RFC або іншим стандартом), його **необхідно** дотримуватися.

en: Some of the configurations have preconditions which need to be met. Those most likely include generation of crypographic keys before the config can be applied - you will get a commit error otherwise. If you are interested how those preconditions are fulfilled check the vyos-build_ repository and the ``scripts/check-qemu-install`` file.
uk: Деякі з конфігурацій мають попередні умови, які необхідно виконати. Вони, швидше за все, включають генерацію крипографічних ключів перед застосуванням конфігурації - інакше ви отримаєте помилку фіксації. Якщо вас цікавить, як виконуються ці попередні умови, перевірте репозиторій vyos-build_ і файл ``scripts/check-qemu-install``.

en: Sometimes it might be useful to debug Python code interactively on the live system rather than a IDE. This can be achieved using pdb.
uk: Іноді може бути корисним налагодити код Python в інтерактивному режимі в живій системі, а не в IDE. Цього можна досягти за допомогою pdb.

en: Start the build:
uk: Почніть збірку:

en: Starting with VyOS 1.2 the release model of VyOS has changed. VyOS is now **free as in speech, but not as in beer**. This means that while VyOS is still an open source project, the release ISOs are no longer free and can only be obtained via subscription, or by contributing to the community.
uk: Починаючи з VyOS 1.2 модель випуску VyOS змінилася. VyOS тепер **вільний, як у мові, але не як у пиві**. Це означає, що хоча VyOS все ще є проектом з відкритим вихідним кодом, випуски ISO більше не є безкоштовними, і їх можна отримати лише через підписку або шляхом участі в спільноті.

en: Submit a Patch
uk: Надіслати патч

en: Submit the patch ``git push`` and create the GitHub pull-request.
uk: Надішліть патч ``git push`` і створіть GitHub pull-request.

en: Summary
uk: Резюме

en: Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages ship this file. You can determine the VyOS package name in question by using Debian's ``dpkg -S`` command of your running VyOS installation.
uk: Припустімо, ви хочете внести зміни в сценарій веб-проксі, але все ще не знаєте, який із багатьох пакетів VyOS надсилає цей файл. Ви можете визначити відповідне ім’я пакета VyOS за допомогою команди Debian ``dpkg -S`` вашої запущеної інсталяції VyOS.

en: System Startup
uk: Запуск системи

en: Template processor **should** be used for generating config files. Built-in string formatting **may** be used for simple line-oriented formats where every line is self-contained, such as iptables rules. Template processor **must** be used for structured, multi-line formats such as those used by ISC DHCPd.
uk: Процесор шаблону **потрібно** використовувати для створення конфігураційних файлів. Вбудоване форматування рядків **може** використовуватися для простих рядково-орієнтованих форматів, де кожен рядок самодостатній, наприклад, правила iptables. Процесор шаблонів **має** використовуватися для структурованих багаторядкових форматів, таких як ті, що використовуються ISC DHCPd.

en: Testing
uk: Тестування

en: Text generation
uk: Генерація тексту

en: The CLI parser used in VyOS is a mix of bash, bash-completion helper and the C++ backend library [vyatta-cfg](https://github.com/vyos/vyatta-cfg). This section is a reference of common CLI commands and the respective entry point in the C/C++ code.
uk: Синтаксичний аналізатор CLI, який використовується у VyOS, є сумішшю bash, помічника завершення bash і серверної бібліотеки C++ [vyatta-cfg](https://github.com/vyos/vyatta-cfg). У цьому розділі є посилання на загальні команди CLI та відповідну точку входу в код C/C++.

en: The Intel NIC drivers do not come from a Git repository, instead we just fetch the tarballs from our mirror and compile them.
uk: Драйвери Intel NIC не надходять із сховища Git, натомість ми просто отримуємо tar-файли з нашого дзеркала та компілюємо їх.

en: The Intel QAT (Quick Assist Technology) drivers do not come from a Git repository, instead we just fetch the tarballs from 01.org, Intel's open-source website.
uk: Драйвери Intel QAT (Quick Assist Technology) не надходять зі сховища Git, натомість ми просто отримуємо архівні файли з 01.org, веб-сайту Intel з відкритим кодом.

en: The Linux kernel used by VyOS is heavily tied to the ISO build process. The file ``data/defaults.json`` hosts a JSON definition of the kernel version used ``kernel_version`` and the ``kernel_flavor`` of the kernel which represents the kernel's LOCAL_VERSION. Both together form the kernel version variable in the system:
uk: Ядро Linux, яке використовується VyOS, тісно пов’язане з процесом збирання ISO. Файл ``data/defaults.json`` містить визначення JSON версії ядра, що використовується ``kernel_version`` і ``kernel_flavor`` ядра, яке представляє LOCAL_VERSION ядра. Обидва разом утворюють змінну версії ядра в системі:

en: The README.md file will guide you to use the this top level repository.
uk: Файл README.md допоможе вам використовувати це сховище верхнього рівня.

en: The ``apply()`` and ``generate()`` functions may ``raise ConfigError`` if, for example, the daemon failed to start with the updated config. It shouldn't be a substitute for proper config checking in the ``verify()`` function. All reasonable effort should be made to verify that generated configuration is valid and will be accepted by the daemon, including, when necessary, cross- checks with other VyOS configuration subtrees.
uk: Функції ``apply()`` і ``generate()`` можуть ``викликати ConfigError``, якщо, наприклад, демон не запустився з оновленою конфігурацією. Це не повинно замінити правильну перевірку конфігурації у функції ``verify()``. Необхідно докласти всіх розумних зусиль, щоб переконатися, що згенерована конфігурація дійсна і буде прийнята демоном, включаючи, за необхідності, перехресні перевірки з іншими піддеревами конфігурації VyOS.

en: The ``apply()`` function applies the generated configuration to the live system. It should use non-disruptive reload whenever possible. It may execute disruptive operations such as daemon process restart if a particular component does not support non-disruptive reload, or when the expected service degradation is minimal (for example, in case of auxiliary services such as LLDPd). In case of high impact services such as VPN daemon and routing protocols, when non- disruptive reload is supported for some but not all types of configuration changes, scripts authors should make effort to determine if a configuration change can be done in a non-disruptive way and only resort to disruptive restart if it cannot be avoided.
uk: Функція ``apply()`` застосовує згенеровану конфігурацію до живої системи. Він повинен використовувати безперервне перезавантаження, коли це можливо. Він може виконувати зривні операції, такі як перезапуск процесу демона, якщо певний компонент не підтримує безперебійне перезавантаження або коли очікуване погіршення сервісу є мінімальним (наприклад, у випадку допоміжних служб, таких як LLDPd). У разі значних служб, таких як VPN-демон і протоколи маршрутизації, коли підтримується перезавантаження без збоїв для деяких, але не для всіх типів змін конфігурації, авторам сценаріїв слід докласти зусиль, щоб визначити, чи можна змінити конфігурацію без зривів. і вдаватися до аварійного перезапуску, лише якщо його неможливо уникнути.

en: The ``generate()`` function generates config files for system components.
uk: Функція ``generate()`` створює файли конфігурації для системних компонентів.

en: The ``get_config()`` function must convert the VyOS config to an abstract, internal representation. No other function is allowed to call the ``vyos.config. Config`` object method directly. The rationale for it is that when config reads are mixed with other logic, it's very hard to change the config syntax since you need to weed out every occurrence of the old syntax. If syntax-specific code is confined to a single function, the rest of the code can be left untouched as long as the internal representation remains compatible.
uk: Функція ``get_config()`` має перетворити конфігурацію VyOS на абстрактне внутрішнє представлення. Жодній іншій функції не дозволяється викликати ``vyos.config. Безпосередньо налаштувати метод об’єкта. Обґрунтування цього полягає в тому, що коли читання конфігурації змішується з іншою логікою, дуже важко змінити синтаксис конфігурації, оскільки вам потрібно відсіяти кожне входження старого синтаксису. Якщо специфічний для синтаксису код обмежено однією функцією, решту коду можна залишити недоторканим, якщо внутрішнє представлення залишається сумісним.

en: The ``make test`` command from the vyos-build_ repository will launch a new QEmu instance and the ISO image is first installed to the virtual harddisk.
uk: Команда ``make test`` зі сховища vyos-build_ запустить новий екземпляр QEmu, а ISO-образ спочатку встановлюється на віртуальний жорсткий диск.

en: The ``verify()`` function takes your internal representation of the config and checks if it's valid, otherwise it must raise ``ConfigError`` with an error message that describes the problem and possibly suggests how to fix it. It must not make any changes to the system. The rationale for it is again testability and, in the future when the config backend is ready and every script is rewritten in this fashion, ability to execute commit dry run ("commit test" like in JunOS) and abort commit before making any changes to the system if an error is found in any component.
uk: Функція ``verify()`` бере ваше внутрішнє представлення конфігурації та перевіряє, чи вона дійсна, інакше вона повинна викликати ``ConfigError`` з повідомленням про помилку, яке описує проблему та, можливо, пропонує, як її виправити. Він не повинен вносити жодних змін у систему. Обґрунтуванням для цього знову є можливість перевірки, а в майбутньому, коли сервер конфігурації буде готовий і кожен сценарій буде переписано таким чином, можливість виконати сухий прогін фіксації («тест фіксації», як у JunOS) і скасувати фіксацію перед внесенням будь-яких змін до системи, якщо в будь-якому компоненті виявлено помилку.

en: The bash (or better vbash) completion in VyOS is defined in *templates*. Templates are text files (called ``node.def``) stored in a directory tree. The directory names define the command names, and template files define the command behaviour. Before VyOS 1.2 (crux) this files were created by hand. After a complex redesign process_ the new style template are automatically generated from a XML input file.
uk: Завершення bash (або краще vbash) у VyOS визначено в *шаблонах*. Шаблони — це текстові файли (так звані ``node.def``), що зберігаються в дереві каталогів. Імена каталогів визначають імена команд, а файли шаблонів визначають поведінку команд. До VyOS 1.2 (crux) ці файли створювалися вручну. Після складного процесу редизайну_ новий шаблон стилю автоматично генерується з вхідного файлу XML.

en: The build process needs to be built on a local file system, building on SMB or NFS shares will result in the container failing to build properly! VirtualBox Drive Share is also not an option as block device operations are not implemented and the drive is always mounted as "nodev"
uk: Процес збірки має бути побудований на локальній файловій системі, збірка на спільних ресурсах SMB або NFS призведе до того, що контейнер не збиратиметься належним чином! VirtualBox Drive Share також не доступний, оскільки операції з блоковими пристроями не реалізовані, а диск завжди монтується як &quot;nodev&quot;

en: The configurations are all derived from production systems and can not only act as a testcase but also as reference if one wants to enable a certain feature. The configurations can be found here: https://github.com/vyos/vyos-1x/tree/current/smoketest/configs
uk: Усі конфігурації походять від виробничих систем і можуть виступати не лише як тестовий приклад, але й як посилання, якщо потрібно ввімкнути певну функцію. Конфігурації можна знайти тут: https://github.com/vyos/vyos-1x/tree/current/smoketest/configs

en: The container can also be built directly from source:
uk: Контейнер також можна створити безпосередньо з джерела:

en: The container can be built by hand or by fetching the pre-built one from DockerHub. Using the pre-built containers from the `VyOS DockerHub organisation`_ will ensure that the container is always up-to-date. A rebuild is triggered once the container changes (please note this will take 2-3 hours after pushing to the vyos-build repository).
uk: Контейнер можна створити вручну або отримати попередньо зібраний з DockerHub. Використання попередньо зібраних контейнерів від `організації VyOS DockerHub`_ гарантує, що контейнер завжди буде актуальним. Відновлення запускається після зміни контейнера (зауважте, що це займе 2-3 години після надсилання до репозиторію vyos-build).

en: The default template processor for VyOS code is Jinja2_.
uk: Типовим процесором шаблонів для коду VyOS є Jinja2_.

en: The easiest way to compile your package is with the above mentioned :ref:`build_docker` container, it includes all required dependencies for all VyOS related packages.
uk: Найпростіший спосіб скомпілювати ваш пакунок — за допомогою згаданого вище контейнера :ref:`build_docker`, він містить усі необхідні залежності для всіх пакетів, пов’язаних з VyOS.

en: The entire test is controlled by the main wrapper script ``/usr/bin/vyos-configtest`` which behaves in the same way as the main smoketest script. It scans the folder for potential configuration files and issues a ``load`` command one after another.
uk: Весь тест контролюється основним сценарієм оболонки ``/usr/bin/vyos-configtest``, який поводиться так само, як і основний сценарій smoketest. Він сканує папку на наявність потенційних файлів конфігурації та видає команду ``load`` одну за одною.

en: The file can be placed in ``/tmp`` for one time debugging (as the file will be removed on reboot) or placed in '/config' to stay permanently.
uk: Файл можна помістити в ``/tmp`` для одноразового налагодження (оскільки файл буде видалено під час перезавантаження) або помістити в &#39;/config&#39;, щоб залишитися назавжди.

en: The first word of every help string **must** be capitalized. There **must not** be a period at the end of help strings.
uk: Перше слово кожного рядка довідки **повинно** бути великим. У кінці довідкових рядків **не повинно** бути крапки.

en: The format should be and is inspired by: https://git-scm.com/book/ch5-2.html It is also worth reading https://chris.beams.io/posts/git-commit/
uk: Формат має бути та натхненний: https://git-scm.com/book/ch5-2.html Також варто прочитати https://chris.beams.io/posts/git-commit/

en: The great thing about schemas is not only that people can know the complete grammar for certain, but also that it can be automatically verified. The `scripts/build-command-templates` script that converts the XML definitions to old style templates also verifies them against the schema, so a bad definition will cause the package build to fail. I do agree that the format is verbose, but there is no other format now that would allow this. Besides, a specialized XML editor can alleviate the issue with verbosity.
uk: Чудова особливість схем полягає не тільки в тому, що люди можуть точно знати повну граматику, але й у тому, що її можна автоматично перевірити. Сценарій `scripts/build-command-templates`, який перетворює визначення XML на шаблони старого стилю, також перевіряє їх на відповідність схемі, тому неправильне визначення призведе до помилки збирання пакета. Я згоден, що формат є багатослівним, але зараз немає іншого формату, який би це дозволяв. Крім того, спеціалізований редактор XML може полегшити проблему багатослівності.

en: The information is used in three ways:
uk: Інформація використовується трьома способами:

en: The kernel build is quite easy, most of the required steps can be found in the ``vyos-build/packages/linux-kernel/Jenkinsfile`` but we will walk you through it.
uk: Збірка ядра досить проста, більшість необхідних кроків можна знайти в ``vyos-build/packages/linux-kernel/Jenkinsfile``, але ми проведемо вас через це.

en: The most obvious reasons could be:
uk: Найбільш очевидними причинами можуть бути:

en: The original repo is at https://github.com/dmbaturin/hvinfo
uk: Оригінальне репо є на https://github.com/dmbaturin/hvinfo

en: The other part of our tests are called "config load tests". The config load tests will load - one after another - arbitrary configuration files to test if the configuration migration scripts work as designed and that a given set of functionality still can be loaded with a fresh VyOS ISO image.
uk: Інша частина наших тестів називається «навантажувальні тести конфігурації». Тести завантаження конфігурації завантажуватимуть — один за одним — довільні файли конфігурації, щоб перевірити, чи сценарії міграції конфігурації працюють належним чином і чи можна завантажити певний набір функціональних можливостей за допомогою свіжого ISO-образу VyOS.

en: The output you get when you find a bug can provide lots of information. If you get an error message on the screen, copy it exactly. Having the exact message can provide detail that the developers can use. Like wise if you have any log messages that also are from the time of the issue, include those. They may also contain information that is helpful for the development team.
uk: Результати, які ви отримуєте, коли ви знаходите помилку, можуть надати багато інформації. Якщо на екрані з’явиться повідомлення про помилку, точно скопіюйте його. Наявність точного повідомлення може надати деталі, які розробники зможуть використовувати. Так само, якщо у вас є будь-які повідомлення журналу, які також є з моменту проблеми, додайте їх. Вони також можуть містити інформацію, корисну для команди розробників.

en: The package ends up in deb_dist dir.
uk: Пакунок потрапляє в каталог deb_dist.

en: The reason is that the configuration migration backend is rewritten and uses a new form of "magic string" which is applied on demand when real config migration is run on boot. When runnint individual migrators for testing, you need to convert the "magic string" on your own by:
uk: Причина полягає в тому, що бекенд міграції конфігурації переписаний і використовує нову форму «магічного рядка», який застосовується на вимогу, коли справжня міграція конфігурації виконується під час завантаження. Під час запуску окремих міграторів для тестування вам потрібно самостійно перетворити «магічний рядок»:

en: The repository that contains all the ISO build scripts is: https://github.com/vyos/vyos-build
uk: Репозиторій, який містить усі сценарії збірки ISO: https://github.com/vyos/vyos-build

en: The script only searches for executable "test-cases" under ``/usr/libexec/vyos/tests/smoke/cli/`` and executes them one by one.
uk: Сценарій лише шукає виконувані &quot;тестові випадки&quot; в ``/usr/libexec/vyos/tests/smoke/cli/`` і виконує їх один за іншим.

en: The source code remains public and an ISO can be built using the process outlined in this chapter.
uk: Вихідний код залишається загальнодоступним, і ISO можна створити за допомогою процесу, описаного в цьому розділі.

en: The source is at https://github.com/vyos/vyos-strongswan
uk: Джерело за адресою https://github.com/vyos/vyos-strongswan

en: The source is located at https://github.com/vyos/vyos-netplug
uk: Джерело розміщено за адресою https://github.com/vyos/vyos-netplug

en: The switch to the Python programming language for new code is not merely a change of the language, but a chance to rethink and improve the programming approach.
uk: Перехід на мову програмування Python для нового коду – це не просто зміна мови, а шанс переосмислити та вдосконалити підхід до програмування.

en: The system startup can be debugged (like loading in the configuration file from ``/config/config.boot``. This can be achieve by extending the Kernel command-line in the bootloader.
uk: Запуск системи можна налагодити (наприклад, завантаження файлу конфігурації з ``/config/config.boot``. Цього можна досягти шляхом розширення командного рядка ядра у завантажувачі.

en: There are (rare) situations where building an ISO image is not possible at all due to a broken package feed in the background. APT is not very good at reporting the root cause of the issue. Your ISO build will likely fail with a more or less similar looking error message:
uk: Бувають (рідкісні) ситуації, коли створення ISO-образу взагалі неможливе через несправний канал пакетів у фоновому режимі. APT не дуже добре повідомляє про першопричину проблеми. Ваша збірка ISO, ймовірно, завершиться невдачею з більш-менш схожим на вигляд повідомленням про помилку:

en: There are different ways you can build VyOS.
uk: Ви можете створити VyOS різними способами.

en: There are extensions to e.g. VIM (xmllint) which will help you to get your indention levels correct. Add to following to your .vimrc file: ``au FileType xml setlocal equalprg=xmllint\ --format\ --recover\ -\ 2>/dev/null`` now you can call the linter using ``gg=G`` in command mode.
uk: Існують розширення, наприклад, для VIM (xmllint), які допоможуть вам отримати правильні рівні відступів. Додайте наступне до свого файлу .vimrc: ``au FileType xml setlocal equalprg=xmllint\ --format\ --recover\ -\ 2&gt;/dev/null`` тепер ви можете викликати linter за допомогою ``gg=G` ` в командному режимі.

en: There are two flags available to aid in debugging configuration scripts. Since configuration loading issues will manifest during boot, the flags are passed as kernel boot parameters.
uk: Є два прапорці, які допомагають у налагодженні сценаріїв конфігурації. Оскільки проблеми із завантаженням конфігурації виявлятимуться під час завантаження, прапорці передаються як параметри завантаження ядра.

en: This ISO can be customized with the following list of configure options. The full and current list can be generated with ``./build-vyos-image --help``:
uk: Цей ISO можна налаштувати за допомогою наступного списку параметрів конфігурації. Повний і поточний список можна створити за допомогою ``./build-vyos-image --help``:

en: This can also be done permanently by changing ``/boot/grub/grub.cfg``.
uk: Це також можна зробити постійно, змінивши ``/boot/grub/grub.cfg``.

en: This chapter lists those exceptions and gives you a brief overview what we have done on those packages. If you only want to build yourself a fresh ISO you can completely skip this chapter. It may become interesting once you have a VyOS deep dive.
uk: У цьому розділі перераховано ці винятки та надано короткий огляд того, що ми зробили з цими пакетами. Якщо ви хочете створити свіжий ISO, ви можете повністю пропустити цей розділ. Це може стати цікавим, коли ви глибоко зануритеся у VyOS.

en: This is done by utilizing the ``systemd-bootchart`` package which is now installed by default on the VyOS 1.3 (equuleus) branch. The configuration is also versioned so we get comparable results. ``systemd-bootchart`` is configured using this file: bootchart.conf_
uk: Це робиться за допомогою пакета ``systemd-bootchart``, який тепер встановлено за замовчуванням у гілці VyOS 1.3 (equuleus). Конфігурація також має версії, тому ми отримуємо порівняльні результати. ``systemd-bootchart`` налаштовується за допомогою цього файлу: bootchart.conf_

en: This means the file in question (``/opt/vyatta/sbin/vyatta-update-webproxy.pl``) is located in the ``vyatta-webproxy`` package which can be found here: https://github.com/vyos/vyatta-webproxy
uk: Це означає, що відповідний файл (``/opt/vyatta/sbin/vyatta-update-webproxy.pl``) знаходиться в пакеті ``vyatta-webproxy``, який можна знайти тут: https://github. com/vyos/vyatta-webproxy

en: This package doesn't exist in Debian. A debianized fork is kept at https://github.com/vyos/mdns-repeater
uk: Цей пакет не існує в Debian. Дебіанізований форк зберігається за адресою https://github.com/vyos/mdns-repeater

en: This package doesn't exist in Debian. A debianized fork is kept at https://github.com/vyos/udp-broadcast-relay
uk: Цей пакет не існує в Debian. Дебіанізований форк зберігається за адресою https://github.com/vyos/udp-broadcast-relay

en: This tries to automatically detect which blobs are needed based on which drivers were built. If it fails to find the correct files you can add them manually to ``vyos-build/packages/linux-kernel/build-linux-firmware.sh``:
uk: Це намагається автоматично визначити, які блоби потрібні на основі того, які драйвери були зібрані. Якщо не вдалося знайти правильні файли, ви можете додати їх вручну до ``vyos-build/packages/linux-kernel/build-linux-firmware.sh``:

en: This will guide you through the process of building a VyOS ISO using Docker_. This process has been tested on clean installs of Debian Jessie, Stretch, and Buster.
uk: Це проведе вас через процес створення VyOS ISO за допомогою Docker_. Цей процес перевірено на чистих інсталяціях Debian Jessie, Stretch і Buster.

en: This will limit the `bond` interface test to only make use of `eth1` and `eth2` as member ports.
uk: Це обмежить тест інтерфейсу `bond` лише використанням `eth1` і `eth2` як членських портів.

en: Those common tests consists out of:
uk: Ці загальні тести складаються з:

en: Tips and Tricks
uk: Поради та підказки

en: To be able to use Docker_ without ``sudo``, the current non-root user must be added to the ``docker`` group by calling: ``sudo usermod -aG docker yourusername``.
uk: Щоб мати можливість використовувати Docker_ без ``sudo``, поточного користувача без root необхідно додати до групи ``docker``, викликавши: ``sudo usermod -aG docker yourusername``.

en: To build VyOS natively you require a properly configured build host with the following Debian versions installed:
uk: Щоб зібрати VyOS нативно, вам потрібен правильно налаштований хост збірки з такими встановленими версіями Debian:

en: To build our modules we utilize a CI/CD Pipeline script. Each and every VyOS component comes with it's own ``Jenkinsfile`` which is (more or less) a copy. The Pipeline utilizes the Docker container from the :ref:`build_iso` section - but instead of building it from source on every run, we rather always fetch a fresh copy (if needed) from Dockerhub_.
uk: Для створення наших модулів ми використовуємо сценарій CI/CD Pipeline. Кожен компонент VyOS має власний ``Jenkinsfile``, який є (більш-менш) копією. У конвеєрі використовується контейнер Docker із розділу :ref:`build_iso`, але замість того, щоб створювати його з вихідних кодів під час кожного запуску, ми завжди отримуємо свіжу копію (за потреби) з Dockerhub_.

en: To debug issues in priorities or to see what's going on in the background you can use the ``/opt/vyatta/sbin/priority.pl`` script which lists to you the execution order of the scripts.
uk: Щоб усунути проблеми з пріоритетами або побачити, що відбувається у фоновому режимі, ви можете скористатися сценарієм ``/opt/vyatta/sbin/priority.pl``, який показує вам порядок виконання сценаріїв.

en: To debug the build process and gain additional information of what could be the root cause, you need to use `chroot` to change into the build directry. This is explained in the following step by step procedure:
uk: Щоб налагодити процес збірки та отримати додаткову інформацію про те, що може бути основною причиною, вам потрібно використати `chroot`, щоб перейти в каталог збірки. Це пояснюється в наступній покроковій процедурі:

en: To enable boot time graphing change the Kernel commandline and add the folowing string: ``init=/usr/lib/systemd/systemd-bootchart``
uk: Щоб увімкнути графік часу завантаження, змініть командний рядок ядра та додайте такий рядок: ``init=/usr/lib/systemd/systemd-bootchart``

en: To enable debugging just run: ``$ touch /tmp/vyos.frr.debug``
uk: Щоб увімкнути налагодження, просто запустіть: ``$ touch /tmp/vyos.frr.debug``

en: To ensure uniform look and feel, and improve readability, we should follow a set of guidelines consistently.
uk: Щоб забезпечити єдиний вигляд і відчуття, а також покращити читабельність, ми повинні послідовно дотримуватися набору вказівок.

en: To make this approach work, every change must be associated with a task number (prefixed with **T**) and a component. If there is no bug report/feature request for the changes you are going to make, you have to create a Phabricator_ task first. Once there is an entry in Phabricator_, you should reference its id in your commit message, as shown below:
uk: Щоб цей підхід працював, кожна зміна має бути пов’язана з номером завдання (з префіксом **T**) і компонентом. Якщо для змін, які ви збираєтеся внести, немає звіту про помилку/запиту на функції, вам потрібно спочатку створити завдання Phabricator_. Якщо у Phabricator_ є запис, ви повинні посилатися на його ідентифікатор у своєму повідомленні коміту, як показано нижче:

en: To manually download the container from DockerHub, run:
uk: Щоб вручну завантажити контейнер із DockerHub, виконайте:

en: To start, clone the repository to your local machine:
uk: Для початку клонуйте репозиторій на локальну машину:

en: To take your newly created package on a test drive you can simply SCP it to a running VyOS instance and install the new `*.deb` package over the current running one.
uk: Щоб взяти ваш щойно створений пакет на тест-драйв, ви можете просто перенести його на запущений екземпляр VyOS і встановити новий пакет `*.deb` поверх поточного запущеного.

en: Troubleshooting
uk: Вирішення проблем

en: Unless absolutely necessary, configuration scripts should not modify the active configuration of system components directly. Whenever at all possible, scripts should generate a configuration file or files that can be applied with a single command such as reloading a service through systemd init. Inserting statements one by one is particularly discouraged, for example, when configuring netfilter rules, saving them to a file and loading it with iptables-restore should always be preferred to executing iptables directly.
uk: Без крайньої необхідності сценарії конфігурації не повинні безпосередньо змінювати активну конфігурацію компонентів системи. Якщо це можливо, сценарії повинні генерувати файл або файли конфігурації, які можна застосувати за допомогою однієї команди, наприклад перезавантажити службу через systemd init. Особливо не рекомендується вставляти оператори один за одним, наприклад, під час налаштування правил netfilter, збереження їх у файлі та завантаження його за допомогою iptables-restore завжди слід віддавати перевагу, ніж виконання безпосередньо iptables.

en: Upstream packages
uk: Вихідні пакети

en: Use of abbreviations and acronyms
uk: Використання скорочень і акронімів

en: Use of numbers
uk: Використання чисел

en: Use of numbers in command names **should** be avoided unless a number is a part of a protocol name or similar. Thus, ``protocols ospfv3`` is perfectly fine, but something like ``server-1`` is questionable at best.
uk: **Слід** уникати використання чисел у назвах команд, окрім випадків, коли число є частиною назви протоколу чи подібного. Таким чином, ``протоколи ospfv3`` цілком нормальні, але щось на кшталт ``server-1`` викликає сумніви в кращому випадку.

en: Use of verbs
uk: Вживання дієслів

en: Use regex
uk: Використовуйте регулярний вираз

en: Useful commands are:
uk: Корисні команди:

en: VIF (incl. VIF-S/VIF-C)
uk: VIF (включаючи VIF-S/VIF-C)

en: VLANs (QinQ and regular 802.1q)
uk: VLAN (QinQ і звичайний 802.1q)

en: Verbs **should** be avoided. If a verb can be omitted, omit it.
uk: Дієслів **слід** уникати. Якщо дієслово можна пропустити, пропустіть його.

en: Verbs, when they are necessary, **should** be in their infinitive form.
uk: Дієслова, коли вони необхідні, **повинні** бути у формі інфінітива.

en: Virtualization Platforms
uk: Платформи віртуалізації

en: VyOS CLI is all about priorities. Every CLI node has a corresponding ``node.def`` file and possibly an attached script that is executed when the node is present. Nodes can have a priority, and on system bootup - or any other ``commit`` to the config all scripts are executed from lowest to higest priority. This is good as this gives a deterministic behavior.
uk: VyOS CLI — це пріоритети. Кожен вузол CLI має відповідний файл ``node.def`` і, можливо, прикріплений сценарій, який виконується, коли вузол присутній. Вузли можуть мати пріоритет, і під час завантаження системи або будь-якого іншого ``фіксування`` конфігурації всі сценарії виконуються від найнижчого до найвищого пріоритету. Це добре, оскільки це дає детерміновану поведінку.

en: VyOS itself comes with a bunch of packages that are specific to our system and thus cannot be found in any Debian mirror. Those packages can be found at the `VyOS GitHub project`_ in their source format can easily be compiled into a custom Debian (`*.deb`) package.
uk: Сама VyOS постачається з купою пакетів, які є специфічними для нашої системи, тому їх неможливо знайти в жодному дзеркалі Debian. Ці пакунки можна знайти в проекті `VyOS GitHub`_ у вихідному форматі, який можна легко скомпілювати у спеціальний пакет Debian (`*.deb`).

en: VyOS makes use of Jenkins_ as our Continuous Integration (CI) service. Our `VyOS CI`_ server is publicly accessible here: https://ci.vyos.net. You can get a brief overview of all required components shipped in a VyOS ISO.
uk: VyOS використовує Jenkins_ як службу постійної інтеграції (CI). Наш сервер `VyOS CI`_ є загальнодоступним тут: https://ci.vyos.net. Ви можете отримати короткий огляд усіх необхідних компонентів, що поставляються в VyOS ISO.

en: We again make use of a helper script and some patches to make the build work. Just run the following command:
uk: Ми знову використовуємо допоміжний сценарій і деякі патчі, щоб збірка працювала. Просто запустіть таку команду:

en: We differentiate in two independent tests, which are both run in parallel by two separate QEmu instances which are launched via ``make test`` and ``make testc`` from within the vyos-build_ repository.
uk: Ми розрізняємо два незалежні тести, які виконуються паралельно двома окремими екземплярами QEmu, які запускаються через ``make test`` і ``make testc`` зі сховища vyos-build_.

en: We now are free to run any command we would like to use for debugging, e.g. re-installing the failed package after updating the repository.
uk: Тепер ми можемо виконувати будь-яку команду, яку хочемо використати для налагодження, наприклад, повторне встановлення невдалого пакета після оновлення репозиторію.

en: We now need to mount some required, volatile filesystems
uk: Тепер нам потрібно змонтувати деякі необхідні енергозалежні файлові системи

en: We only accept bugfixes in packages other than https://github.com/vyos/vyos-1x as no new functionality should use the old style templates (``node.def`` and Perl/BASH code. Use the new style XML/Python interface instead.
uk: Ми приймаємо лише виправлення помилок у пакетах, відмінних від https://github.com/vyos/vyos-1x, оскільки жодна нова функціональність не повинна використовувати старі шаблони стилю (``node.def`` і код Perl/BASH. Використовуйте новий стиль XML Натомість інтерфейс /Python.

en: What commands did you use? Use e.g. ``run show configuration commands``
uk: Які команди ви використовували? Використовуйте, наприклад, ``виконати, показати команди конфігурації``

en: What was the configuration prior to the change?
uk: Якою була конфігурація до зміни?

en: What were you attempting to achieve?
uk: Чого ви намагалися досягти?

en: What/why/how something has been changed, makes everyone's life easier when working with `git bisect`
uk: Що/чому/як щось було змінено, полегшує життя кожного під час роботи з `git bisect`

en: When and ISO image is assembled by the `VyOS CI`_, the ``BUILD_SMOKETEST`` parameter is enabled by default, which will extend the ISO configuration line with the following packages:
uk: Коли образ ISO збирається `VyOS CI`_, параметр ``BUILD_SMOKETEST`` вмикається за замовчуванням, що розширить рядок конфігурації ISO такими пакетами:

en: When having trouble compiling your own ISO image or debugging Jenkins issues you can follow the steps at :ref:`iso_build_issues`.
uk: Якщо у вас виникли проблеми зі збиранням власного образу ISO або з усуненням проблем із Дженкінсом, виконайте дії, наведені в :ref:`iso_build_issues`.

en: When modifying the source code, remember these rules of the legacy elimination campaign:
uk: Змінюючи вихідний код, пам’ятайте про ці правила кампанії з усунення застарілих версій:

en: When the build is successful, the resulting iso can be found inside the ``build`` directory as ``live-image-[architecture].hybrid.iso``.
uk: Коли збірка пройшла успішно, отриманий iso можна знайти в каталозі ``build`` як ``live-image-[architecture].hybrid.iso``.

en: When writing a new configuration migrator it may happen that you see an error when you try to invoke it manually on a development system. This error will look like:
uk: Під час написання нового засобу міграції конфігурації може статися, що ви побачите помилку під час спроби викликати його вручну в системі розробки. Ця помилка виглядатиме так:

en: When you are able to verify that it is actually a bug, spend some time to document how to reproduce the issue. This documentation can be invaluable.
uk: Коли ви зможете переконатися, що це справді помилка, витратите деякий час, щоб задокументувати, як відтворити проблему. Ця документація може бути неоціненною.

en: When you are working on interface configuration and you also wan't to test if the Smoketests pass you would normally loose the remote SSH connection to your :abbr:`DUT (Device Under Test)`. To handle this issue, some of the interface based tests can be called with an environment variable beforehand to limit the number of interfaces used in the test. By default all interface e.g. all Ethernet interfaces are used.
uk: Коли ви працюєте над конфігурацією інтерфейсу і не бажаєте перевіряти, чи пройшли тести Smoketests, ви зазвичай втрачаєте віддалене SSH-з’єднання з вашим :abbr:`DUT (Device Under Test)`. Щоб вирішити цю проблему, деякі з тестів на основі інтерфейсу можна заздалегідь викликати зі змінною середовища, щоб обмежити кількість інтерфейсів, які використовуються в тесті. За замовчуванням використовуються всі інтерфейси, наприклад, усі інтерфейси Ethernet.

en: When you believe you have found a bug, it is always a good idea to verify the issue prior to opening a bug request.
uk: Якщо ви вважаєте, що знайшли помилку, завжди доцільно перевірити проблему, перш ніж відкривати запит про помилку.

en: When you wish to have a developer fix a bug that you found, helping them reproduce the issue is beneficial to everyone. Be sure to include information about the hardware you are using, commands that you were running, any other activities that you may have been doing at the time. This additional information can be very useful.
uk: Якщо ви хочете, щоб розробник виправив помилку, яку ви знайшли, допомога йому відтворити проблему буде корисною для всіх. Обов’язково вкажіть інформацію про апаратне забезпечення, яке ви використовуєте, команди, які ви запускали, будь-які інші дії, які ви, можливо, виконували в той час. Ця додаткова інформація може бути дуже корисною.

en: Which version of VyOS are you using? ``run show version``
uk: Яку версію VyOS ви використовуєте? ``виконати показову версію``

en: Writing good commit messages
uk: Написання хороших повідомлень про коміти

en: XML (used for CLI definitions)
uk: XML (використовується для визначень CLI)

en: XML interface definition files use the `xml.in` file extension which was implemented in :vytask:`T1843`. XML interface definitions tend to have a lot of duplicated code in areas such as:
uk: Файли визначення інтерфейсу XML використовують розширення файлу `xml.in`, яке було реалізовано в :vytask:`T1843`. Визначення інтерфейсу XML, як правило, містять багато дубльованого коду в таких областях, як:

en: XML interface definitions for VyOS come with a RelaxNG schema and are located in the vyos-1x_ module. This schema is a slightly modified schema from VyConf_ alias VyOS 2.0 So VyOS 1.2.x interface definitions will be reusable in Nextgen VyOS Versions with very minimal changes.
uk: Визначення інтерфейсу XML для VyOS постачаються зі схемою RelaxNG і знаходяться в модулі vyos-1x_. Ця схема є дещо зміненою схемою VyConf_ псевдонім VyOS 2.0, тому визначення інтерфейсу VyOS 1.2.x можна буде повторно використовувати у версіях VyOS Nextgen з дуже мінімальними змінами.

en: XML: Tabs **shall not** be used. Every indentation level should be 2 spaces
uk: XML: вкладки **не можна** використовувати. Кожен рівень відступу має складатися з 2 пробілів

en: You can also place the generated `*.deb` into your ISO build environment to include it in a custom iso, see :ref:`build_custom_packages` for more information.
uk: Ви також можете розмістити згенерований файл `*.deb` у своєму середовищі збірки ISO, щоб включити його в користувацьку iso, див. :ref:`build_custom_packages` для отримання додаткової інформації.

en: You can create yourself some handy Bash aliases to always launch the latest - per release train (`current` or `crux`) - container. Add the following to your ``.bash_aliases`` file:
uk: Ви можете створити собі кілька зручних псевдонімів Bash, щоб завжди запускати найновіший контейнер для кожного випуску («current» або «crux»). Додайте наступне до свого файлу ``.bash_aliases``:

en: You can type ``help`` to get an overview of the available commands, and ``help command`` to get more information on each command.
uk: Ви можете ввести ``help``, щоб отримати огляд доступних команд, і ``help command``, щоб отримати більше інформації про кожну команду.

en: You have an idea of how to make VyOS better or you are in need of a specific feature which all users of VyOS would benefit from? To send a feature request please search Phabricator_ if there is already a request pending. You can enhance it or if you don't find one, create a new one by use the quick link in the left side under the specific project.
uk: У вас є уявлення про те, як покращити VyOS, або вам потрібна конкретна функція, яка буде корисною для всіх користувачів VyOS? Щоб надіслати запит на функцію, виконайте пошук Phabricator_, якщо запит уже очікує на розгляд. Ви можете покращити його або, якщо не знайдете, створити новий, скориставшись швидким посиланням ліворуч під конкретним проектом.

en: You have your own custom kernel `*.deb` packages in the `packages` folder but neglected to create all required out-of tree modules like Accel-PPP, WireGuard, Intel QAT, Intel NIC
uk: У вас є власні пакети ядра `*.deb` у папці `packages`, але ви забули про створення всіх необхідних позадеревних модулів, таких як Accel-PPP, WireGuard, Intel QAT, Intel NIC

en: You shoudl now see a Python backtrace which will help us to handle the issue, please attach it to the Phabricator_ task.
uk: Тепер ви повинні побачити зворотне трасування Python, яке допоможе нам вирішити цю проблему. Додайте його до завдання Phabricator_.

en: You then can proceed with cloning your fork or add a new remote to your local repository:
uk: Потім ви можете продовжити клонування свого форка або додати новий пульт до свого локального сховища:

en: Your configuration script or operation mode script which is also written in Python3 should have a line break on 80 characters. This seems to be a bit odd nowadays but as some people also work remotely or program using vi(m) this is a fair good standard which I hope we can rely on.
uk: Ваш сценарій конфігурації або сценарій режиму роботи, який також написаний на Python3, повинен мати розрив рядка на 80 символів. Сьогодні це здається трохи дивним, але оскільки деякі люди також працюють віддалено або програмують за допомогою vi(m), це досить хороший стандарт, на який, я сподіваюся, ми можемо покластися.

en: `IPv4, IPv6 and DHCP(v6)`_ address assignment
uk: `IPv4, IPv6 і DHCP(v6)`_ призначення адреси

en: `IPv4, IPv6`_ address assignment
uk: `IPv4, IPv6`_ призначення адреси

en: `MAC address`_ assignment
uk: `MAC-адреса`_ призначення

en: `VLAN (VIF)`_ definition
uk: Визначення `VLAN (VIF)`_

en: ``Jenkins: add current Git commit ID to build description``
uk: ``Jenkins: додайте поточний ідентифікатор коміту Git до опису збірки``

en: ``command`` - Once set, all commands used, and their responses received from the OS, will be presented on the screen for inspection.
uk: ``команда`` – після встановлення всі використані команди та відповіді на них, отримані від ОС, будуть представлені на екрані для перевірки.

en: ``commit``
uk: ``здійснити``

en: ``ddclient: T1030: auto create runtime directories``
uk: ``ddclient: T1030: автоматично створювати каталоги середовища виконання``

en: ``developer`` - Should a command fail, instead of printing a message to the user explaining how to report issues, the python interpreter will start a PBD post-mortem session to allow the developer to debug the issue. As the debugger will wait from input from the developer, it has the capacity to prevent a router to boot and therefore should only be permanently set up on production if you are ready to see the OS fail to boot.
uk: ``розробник`` - якщо команда завершується помилкою, замість друку повідомлення для користувача з поясненням, як повідомити про проблеми, інтерпретатор python розпочне сеанс PBD post mortem, щоб дозволити розробнику налагодити проблему. Оскільки налагоджувач чекатиме вхідних даних від розробника, він має здатність запобігти завантаженню маршрутизатора, тому його слід постійно налаштовувати лише у робочому стані, якщо ви готові побачити, що ОС не завантажиться.

en: ``ifconfig`` - Once set, all commands used, and their responses received from the OS, will be presented on the screen for inspection.
uk: ``ifconfig`` - після встановлення всі використані команди та відповіді на них, отримані від ОС, будуть представлені на екрані для перевірки.

en: ``log`` - In some rare cases, it may be useful to see what the OS is doing, including during boot. This option sends all commands used by VyOS to a file. The default file is ``/tmp/full-log`` but it can be changed.
uk: ``журнал`` - У деяких рідкісних випадках може бути корисно побачити, що робить ОС, зокрема під час завантаження. Цей параметр надсилає всі команди, які використовує VyOS, у файл. Типовим файлом є ``/tmp/full-log``, але його можна змінити.

en: ``set``
uk: ``набір``

en: ``vyos-build`` repo is outdated, please ``git pull`` to update to the latest release kernel version from us.
uk: Сховище ``vyos-build`` застаріло, будь ласка ``git pull``, щоб оновити до останньої версії ядра від нас.

en: ``vyos-config-debug`` - During development, coding errors can lead to a commit failure on boot, possibly resulting in a failed initialization of the CLI. In this circumstance, the kernel boot parameter ``vyos-config-debug`` will ensure access to the system as user ``vyos``, and will log a Python stack trace to the file ``/tmp/boot-config-trace``. File ``boot-config-trace`` will generate only if config loaded with a failure status.
uk: ``vyos-config-debug`` - під час розробки помилки кодування можуть призвести до помилки фіксації під час завантаження, що, можливо, призведе до невдалої ініціалізації CLI. У цьому випадку параметр завантаження ядра ``vyos-config-debug`` забезпечить доступ до системи як користувач ``vyos`` і запише трасування стека Python у файл ``/tmp/boot-config- слід``. Файл ``boot-config-trace`` буде створено, лише якщо конфігурацію завантажено зі статусом помилки.

en: ``vyos-debug`` - Adding the parameter to the linux boot line will produce timing results for the execution of scripts during commit. If one is seeing an unexpected delay during manual or boot commit, this may be useful in identifying bottlenecks. The internal flag is ``VYOS_DEBUG``, and is found in vyatta-cfg_. Output is directed to ``/var/log/vyatta/cfg-stdout.log``.
uk: ``vyos-debug`` - Додавання параметра до рядка завантаження Linux створить результати синхронізації для виконання сценаріїв під час фіксації. Якщо хтось бачить неочікувану затримку під час ручного або завантажувального фіксування, це може бути корисним для виявлення вузьких місць. Внутрішній прапор — ``VYOS_DEBUG``, його можна знайти у vyatta-cfg_. Вихідні дані спрямовуються до ``/var/log/vyatta/cfg-stdout.log``.

en: `make`
uk: `робити`

en: allowed: /path/to/script
uk: дозволено: /path/to/script

en: allowed: cli-shell-api listNodes vpn ipsec esp-group
uk: дозволено: cli-shell-api listNodes vpn ipsec esp-group

en: allowed: echo foo bar
uk: дозволено: панель echo foo

en: begin:/create:/delete:
uk: початок:/створити:/видалити:

en: contine execution using ``cont``
uk: містить виконання за допомогою ``cont&#39;&#39;

en: default:
uk: за замовчуванням:

en: examine variables using ``pp(var)``
uk: перевірити змінні за допомогою ``pp(var)``

en: get a backtrace using ``bt``
uk: отримати зворотне трасування за допомогою ``bt``

en: help: My node
uk: довідка: Мій вузол

en: hvinfo
uk: чому

en: mdns-repeater
uk: mdns-ретранслятор

en: multi:
uk: мульти:

en: mynode/node.tag , tag:
uk: mynode/node.tag , тег:

en: priority: 999
uk: пріоритет: 999

en: strongswan
uk: сильний лебідь

en: strongswan-nm package build is disabled since we don't use NetworkManager
uk: збірку пакунка strongswan-nm вимкнено, оскільки ми не використовуємо NetworkManager

en: syntax:expression: $VAR(@) in "foo", "bar", "baz"
uk: синтаксис:вираз: $VAR(@) у &quot;foo&quot;, &quot;bar&quot;, &quot;baz&quot;

en: syntax:expression: (arithmetic expression)
uk: синтаксис:вираз: (арифметичний вираз)

en: syntax:expression: exec ...
uk: синтаксис:вираз: exec ...

en: syntax:expression: pattern
uk: синтаксис:вираз: шаблон

en: val_help: <format>; some string
uk: val_help:<format> ; якийсь рядок
