Nomad mac os ��� ���

Nomad mac os ��� ���

All the functioning of AD without the bind

While our open source app NoMAD can be a great tool to help users bound to Active Directory, its main purpose is to help move your Macs off binding to AD while still getting all of the functionality. Keep your users on local accounts and let NoMAD manage their interaction with AD by allowing them to sign in with their AD account to get Kerberos tickets, certificates for 802.1X connections and other functions without having to have a mobile account.

If you’re unsure if not binding is right for you, allow NoMAD to help you make the transition as all of NoMAD’s features work while bound as well. This way you, the admin, can migrate your systems when you’re ready and your users have the same experience.

NoMAD also includes:

• Single sign-on
• Password synchronization
• Admin’s helper
• And more!

Download NoMAD and the Package Installer on our support page today!
Contact us for information on discounts for purchasing support for NoMAD with NoMAD Login.

Reimagine your Loginwindow

NoMAD is great for keeping your local Mac user account in sync with AD, but wouldn’t it be awesome if the accounts started out in sync? NoMAD Login provides this, and more, by allowing for AD logins on macOS without the need to bind to Active Directory.

NoMAD Login is an open source app that has many features, including:

• AD login authentication without binding to AD
• Just-in-time local user creation
• Demobilization of cached AD mobile accounts
• First login FileVault with MDM key escrow support on High Sierra
• Customizable login UI

Support Plans and Implementation support available.

Learn more and download a copy of NoMAD Login here.
Contact us for information on discounts for purchasing support for NoMAD with NoMAD Login.

Источник

NoMAD Testing Guide

This guide serves as a checklist for evaluating NoMAD in your environment. It should also give you some ideas about NoMAD deployment and usability scenarios as well.

Basic Functionality

Start at the beginning by downloading a fresh copy of NoMAD on a fresh Mac. It doesn’t matter if the Mac is bound to AD or not; NoMAD will work either way.

You can find the download here, in the Support section of the website.

1. Launch NoMAD. The binary is signed, as all good applications should be, and can be run from any location. The application’s icon is a caribou, the most nomadic land mammal in the world.
2. If you’re not bound to AD, you’ll be presented with a Preferences window. The only field you need to fill out at this time is the “AD Domain” field at the top.
3. If you are bound to AD, you will not see the Preferences window, as NoMAD will automatically determine your AD Domain and use that. You can change this later by using the Preferences window, or through other means.
4. Once NoMAD has launched, you’ll see a triangle icon in the Menu Bar at the top of your screen. If you are not able to reach your AD Domain, you’ll see “Not Connected” next to the icon. If you can reach your domain, you’ll see the same triangle without any text. Finally, if you already have a Kerberos ticket for the current user, you will see a green check mark in the triangle. The icons are shown below.
5. If the icon has “Not Connected” next to it, sign in to your VPN or otherwise connect to your organization’s network so that your AD Domain Controllers (DCs) are able to be reached by the system running NoMAD. NoMAD will automatically detect when the network has changed and will update accordingly.
6. Once connected, you can sign in to NoMAD if you do not have a green check mark in the NoMAD icon in the menu bar. Do this by using the “Sign In” option on the menu. If you’re unable to contact the DCs, you won’t be able to use the “Sign In” menu item.
7. This will activate the Sign In window where you can sign in as an AD user. You can simply use the user’s short name, or you can use their full user@domain.com handle. Note that there is no need to enter the NT Domain before the user name.
8. Upon successful authentication, you will now have a Kerberos TGT for that AD user and will be able to sign in to all Windows SSO resources, which may include websites, file servers, and some applications.
9. If your user has a password expiration policy, the number of days until that user’s password expires will be shown on the menu bar next to the NoMAD icon and on the second line of the NoMAD menu itself. If the user does not have an expiration date, then no text will be next to the NoMAD icon and the second line of the NoMAD menu will show “password does not expire”.
10. To remove your SSO credentials, you can use the “Sign Out” menu item.

User Interaction

Next, you’ll want to test additional user functionality beyond a simple sign in and sign out. To do that, we’ll walk through the rest of the menu items. To begin, sign in to AD with NoMAD so that you have a valid user already logged in. Your NoMAD menu should look similar to this:

1. If the currently signed in user has a password expiration date, hovering your mouse over the NoMAD icon in the menu bar will show you the actual date and time that their password expires.
2. Holding down the “option” key while clicking on the NoMAD menu will show the expiration date of your current Kerberos TGT, and the AD Domain Controller that NoMAD is currently using for all LDAP lookups in the second item on the NoMAD menu.
3. Test renewing your Kerberos ticket by using the “Renew Tickets” menu item. This will renew the ticket with AD and ensure that your Kerberos ticket has the longest duration possible. You can verify this by using the klist tool on the command line, or by holding down the “option” key again to view the ticket lifetime in the second line of the NoMAD menu. It may take a few seconds for the lifetime to update in the menu.
4. Next, change the user’s password by using the “Change Password” menu item. This will bring up the “Change Password” window and allow you to enter your old password and then the new password twice. When you click the “Change Password” button, NoMAD will change the user’s AD password via Kerberos.
5. If no errors occur, the user’s AD password will be changed and any password expiration dates will be updated. Note that most AD environments will only allow a password to be changed once every 24 hours. Also note that this will not change the password of the local user account on the Mac by default; that can be enabled using a preference key if desired.
6. Next, use the “Lock Screen” button to sleep the Mac’s screen. If you have the system configured to require password when waking the screen, you will be prompted to enter it.
7. If you have a) Jamf Self Service, b) Munki Managed Software Center, or c) Lan Rev Agent installed on your system, the “Get Software” menu item will be available and will launch the appropriate self service application when clicked. If you don’t have any of those applications, this menu item will not appear; you can specify a different application to be launched from this menu by setting a preference key.
8. Next, use the “Get Help” menu item. This will open a web browser to http://www.apple.com/support by default. However, similar to many other menu items in NoMAD, you can set this to an application, a script, another webpage, or even a Bomgar remote support session via the preference keys.
9. Next, select the “Preferences” menu item. You will find the most commonly used options here, as well as the only options that are accessible through the UI. The AD Domain will already be set, and the Kerberos Realm will most commonly be set to the uppercase version of the AD Domain. NoMAD will automatically fill this in if you haven’t. The next two text fields are for specifying a Windows Certificate Authority and Certificate template for getting certificates from AD. The “Use Keychain” check box allows NoMAD to store your AD password in your keychain and automatically log you in. The “Renew Ticket” check box determines whether or not NoMAD automatically renews your Kerberos tickets. The text field next to this box allows a user to set how many seconds between renewing the Kerberos ticket. Finally, the “Show Home Folder” has NoMAD show a user’s home folder, as specified in their AD profile, in the menu.
10. The “Quit” menu item will quit NoMAD while keeping any Kerberos tickets intact on your system.

Источник

Nomad mac os ��� ���

NoMAD Downloads – Current Version 1.2.2

Other Information

While NoMAD and Jamf Connect can do some similar functions, the choice between the two primarily comes down to using Okta (or other identity providers) for authentication with Jamf Connect or using AD for authentication with NoMAD.

For organizations deploying Macs to single users that are often off of the AD domain, Jamf Connect offers a number of features that allow for a smoother workflow.

1. Users never need to actually connect to the AD domain. All authentication is done via Okta’s publicly available endpoints.
2. Jamf Connect supports multi-factor authentication requirements. NoMAD has no support currently, or planned, for multi-factor authentication.
3. Jamf Connect can get Kerberos tickets, but NoMAD can’t get Okta tokens.

Jamf Connect is designed to work with local-only accounts when keeping the password synchronized. If you still are using mobile accounts on your AD-bound Macs and have Okta synchronizing with AD please talk to us about the best workflow for that situation.

Running both applications together

It’s perfectly feasible to run both NoMAD and Jamf Connect in an organziation. While running them at the same time on the same Mac might be a bit strange, both applications would run independently and not interfere with the other. Both applications have different preference domains as well, so the configurations do not cross.

Источник

Deploying NoMAD

NoMAD was designed to be as simple as possible to deploy into any organization, regardless of size. Thus, you can deploy NoMAD in a number of ways in order to accommodate a variety of different organizational needs. No one way is any more “correct” than another.

Stand Alone Application

At the most basic level, you can deploy NoMAD to your users as a stand-alone application. It does not need admin authorization to run, nor does it need to be in any particular location on the user’s Mac. The only required preference to set is the AD Domain. If the machine is bound to an AD domain, the user won’t even be prompted for the domain, as it will be pulled from the dsconfigad settings instead.

For many smaller environments, this may be all that’s required for a deployment, although to make NoMAD more useful it should be set to a Login Item in the user’s System Preferences or via a Launch Agent most likely supplied by an admin.

For the more adventurous admins, you could edit the DefaultPreferences.plist within the NoMAD application bundle, as many preferences will default to values contained in that plist. However, this will break the application’s signature and will require it to be re-signed. While this isn’t a complicated process, it does require a developer account with Apple.

Package Installer

The next step up from just handing out the .app is to put the application into a package installer. There is one on the NoMAD web page that will install NoMAD into the /Applications folder; keep in mind, however, that this will require admin privileges.

It’s also feasible to create your own package installer that could lay down a default preferences file in either /Library/Preferences/com.trusourcelabs.NoMAD.plist or in the user’s Preferences folder. Additionally, you could use a post-install script to use the defaults command to write out individual keys.

Note that NoMAD pulls from a preferences file in /Library/Preferences and then combines that with user-defined preferences.

If you are installing NoMAD in the /Applications folder, you can also install a LaunchAgent for the users that will launch NoMAD on user log in. You can install a configuration profile at the same time, as well.

Configuration Profile

NoMAD will respect preference keys from a configuration profile. You can create one of these by hand—though this is not advised—or via a number of tools such as Apple’s Profile Manager application, part of Apple’s Server application on the Mac App Store, or 3rd party MDM solutions. A configuration profile will typically be in a binary format and signed to ensure its validity.

Here’s an example plaintext payload:

ADDomain
nomad.test
KerberosRealm
NOMAD.TEST
RenewTickets
1
SecondsToRenew
7200
ShowHome
0
Template
User Auth
UseKeychain
0
Verbose
0
X509CA
dc1.nomad.test

Managed Preferences

If you have an existing management solution, you can easily push both the NoMAD package and the preferences from most management solutions. This is probably the easiest deployment method for larger organizations.

Источник

Nomad: проблемы и решения

Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один «домашний» для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).

За прошедшее время накопился довольно большой опыт работы с Nomad окружением, в статье опишу встреченные проблемы Nomad и как с ними можно справиться.

Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия

1. Количество серверных нод на один датацентр

Решение: на один датацентр достаточно одной серверной ноды.

В документации явно не указано, какое число серверных нод требуется в одном датацентре. Указано только, что на регион нужно 3-5 нод, что логично для консенсуса raft протокола.

В начале я запланировал 2-3 серверных ноды в каждом датацентре для обеспечения резервирования.

По факту использования оказалось:

1. Этого просто не требуется, так как при отказе ноды в датацентре, роль серверной ноды для агентов в данном датацентре будут выполнять другие серверные ноды данного региона.
2. Получается даже хуже, если не решена проблема №8. При перевыборах мастера могут случаться рассогласования и Nomad будет перезапускать какую-то часть сервисов.

2. Ресурсы сервера для серверной ноды

Решение: для серверной ноды достаточно небольшой виртуальной машины. На этом же сервере допускается запускать другие служебные нересурсоёмкие сервисы.

Потребление памяти демоном Nomad зависит от количества запущенных задач. Потребление CPU — от количества задач и от количества серверов/агентов в регионе (не линейно).

В нашем случае: для 300 запущенных задач потребление памяти — около 500 МБ для текущей мастер-ноды.

В рабочем кластере виртуальная машина для серверной ноды: 4 CPU, 6 GB RAM.
Дополнительно запущены: Consul, Etcd, Vault.

3. Консенсус при нехватке датацентров

Решение: делаем три виртуальных датацентра и три серверных ноды на два физических датацентра.

Работа Nomad в рамках региона основана на протоколе raft. Для корректной работы нужно не менее 3 серверных нод, расположенных в разных датацентрах. Это даст возможность корректной работы при полной потере сетевой связности с одним из датацентров.

Но у нас только два датацентра. Идём на компромисс: выбираем датацентр, которому мы доверяем больше, и делаем в нём дополнительную серверную ноду. Делаем это путём введения дополнительного виртуального датацентра, которой физически будет находится в том же датацентре (см. подпункт 2 проблемы 1).

Альтернативное решение: разбиваем датацентры на отдельные регионы.

В итоге датацентры функционируют независимо и консенсус нужен только внутри одного датацентра. Внутри датацентра в таком случае лучше сделать 3 серверных ноды путём реализации трёх виртуальных датацентров в одном физическом.

Этот вариант менее удобен для распределения задач, но даёт 100% гарантии независимости работы сервисов в случае сетевых проблем между датацентрами.

4. «Сервер» и «агент» на одном сервере

Решение: допустимо, если у вас ограничено число серверов.

В документации Nomad написано, что так делать нежелательно. Но если у вас нет возможности выделить под серверные ноды отдельные виртуальные машины — можно разместить серверную и агентскую ноду на одном сервере.

Под одновременным запуском подразумевается запуск демона Nomad одновременно в режиме клиента и в режиме сервера.

Чем это грозит? При большой нагрузке на CPU данного сервера серверная нода Nomad будет работать нестабильно, возможны потери консенсуса и хартбитов, перезагрузки сервисов.
Чтобы этого избежать — увеличиваем лимиты из описания проблемы №8.

5. Реализация пространств имён (namespaces)

Решение: возможно, через организацию виртуального датацентра.

Иногда требуется запустить часть сервисов на отдельных серверах.

Решение первое, простое, но более требовательное к ресурсам. Разделяем все сервисы на группы по назначению: frontend, backend,… Добавляем meta атрибуты серверам, прописываем атрибуты для запуска всем сервисам.

Решение второе, простое. Добавляем новые сервера, прописываем им meta атрибуты, прописываем эти атрибуты запуска нужным сервисам, всем остальным сервисам прописываем запрет запуска на серверах с этим атрибутом.

Решение третье, сложное. Создаём виртуальный датацентр: запускаем Consul для нового датацентра, запускаем серверную ноду Nomad для данного датацентра, не забывая о количестве серверных нод для данного региона. Теперь можно запускать отдельные сервисы в данном выделенном виртуальном датацентре.

6. Интеграция с Vault

Решение: избегать циклических зависимостей Nomad Vault.

Запускаемый Vault не должен иметь никаких зависимостей от Nomad. Прописываемый в Nomad адрес Vault желательно должен указывать напрямую на Vault, без прослоек балансеров (но допустимо). Резервирование Vault в таком случае можно делать через DNS — Consul DNS или внешний.

Если в конфигурационных файлах Nomad прописаны данные Vault, то Nomad при запуске пытается получить доступ к Vault. Если доступ неуспешен, то Nomad отказывается запускаться.

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

7. Запуск важных statefull сервисов

Решение: допустимо, но я так не делаю.

Можно ли запускать PostgreSQL, ClickHouse, Redis Cluster, RabbitMQ, MongoDB через Nomad?

Представьте, что у вас есть набор важных сервисов, на работу которых завязана большая часть остальных сервисов. Например, БД в PostgreSQL/ClickHouse. Или общее кратковременное хранилище в Redis Cluster/MongoDB. Или шина данных в Redis Cluster/RabbitMQ.

Все эти сервисы в каком-то виде реализуют отказоустойчивую схему: Stolon/Patroni для PostgreSQL, своя реализация raft в Redis Cluster, своя реализация кластера в RabbitMQ, MongoDB, ClickHouse.

Да, все эти сервисы вполне можно запустить через Nomad с привязкой к конкретным серверам, но зачем?

Плюс — удобство запуска, единый формат сценариев, как и у остальных сервисов. Не нужно мучаться со сценариями ansible/чем-то ещё.

Минус — дополнительная точка отказа, которая не даёт никаких преимуществ. Лично я полностью ронял кластер Nomad два раза по разным причинам: один раз «домашний», один раз рабочий. Это было на первых этапах внедрения Nomad и из-за неаккуратности.
Так же, Nomad начинает себя плохо вести и перезапускать сервисы из-за проблемы №8. Но даже если та проблема у вас решена, опасность остаётся.

8. Стабилизация работы и рестартов сервисов в нестабильной сети

Решение: использование опций тюнинга хартбитов.

По умолчанию Nomad сконфигурирован так, что любая кратковременная проблема сети или нагрузка на CPU, вызывает потерю консенсуса и перевыборы мастера или пометку агентской ноды недоступной. И это приводит к самопроизвольным перезагрузкам сервисов и перенос их на другие ноды.

Статистика «домашнего» кластера до исправления проблемы: максимальное время жизни контейнера до рестарта — около 10 дней. Тут всё ещё отягощается запуском агента и сервера на одном сервере и размещением в 5 разных датацентрах Европы, что предполагает большую нагрузку на CPU и менее стабильную сеть.

Статистика рабочего кластера до исправления проблемы: максимальное время жизни контейнера до рестарта — больше 2 месяцев. Тут всё относительно хорошо из-за отдельных серверов для серверных нод Nomad и отличной сети между датацентрами.

Значения по умолчанию

Судя по коду: в такой конфигурации хартбиты делаются каждые 10 секунд. При потере двух хартбитов начинаются перевыборы мастера или перенос сервисов с агентской ноды. Спорные настройки, на мой взгляд. Отредактируем их в зависимости от применения.

Если у вас все сервисы запущены в нескольких экземплярах и разнесены по датацентрам, то скорее всего, для вас не имеет значения долгий период определения недоступности сервера (примерно 5 минут, в примере ниже) — делаем реже интервал хартбитов и больший период определения недоступности. Это пример настройки моего «домашнего» кластера:

Если же у вас хорошая сетевая связность, отдельные сервера для серверных нод и важен период определения недоступности сервера (есть какой-то сервис, запущенный в одном экземпляре и важно его быстро перенести), то увеличиваем период определения недоступности (heartbeat_grace). Опционально можно сделать чаще хартбиты (уменьшив min_heartbeat_ttl) — от этого незначительно вырастет нагрузка на CPU. Пример конфигурации рабочего кластера:

Данные настройки полностью устраняют проблему.

9. Запуск периодических задач

Решение: периодические сервисы Nomad использовать можно, но «cron» удобнее для поддержки.

В Nomad есть возможность периодического запуска сервиса.

Единственный плюс — простота такой конфигурации.

Первый минус — если сервис будет запускаться часто, то он будет захламлять список задач. Например, при запуске каждые 5 минут — в список будет добавляться 12 лишних задач каждый час, до срабатывания GC Nomad, который удалит старые задачи.

Второй минус — непонятно, как нормально настраивать мониторинг такого сервиса. Как понять, что сервис запускается, отрабатывает и выполняет свою работу до конца?

В итоге, для себя я пришёл к «cron» реализации периодических задач:

1. Это может быть обычный cron в постоянно запущенном контейнере. Cron периодически запускает некий скрипт. На такой контейнер легко добавляется script-healthcheck, который проверяет какой-либо флажок, который создаёт запускаемый скрипт.
2. Это может быть постоянно запущенный контейнер, с постоянно запущенным сервисом. Внутри сервиса уже реализован периодический запуск. На такой сервис легко добавляется или аналогичный script-healthcheck, или http-healthcheck, который проверяет статус сразу по своим «внутренностям».

На данный момент я большую часть времени пишу на Go, соответственно, предпочитаю второй вариант с http healthcheck’ами — на Go и периодический запуск, и http healthcheck’и добавляются несколькими строчками кода.

10. Обеспечение резервирования сервисов

Решение: простого решения нет. Есть два варианта посложнее.

Схема обеспечения резерва, предусмотренная разработчиками Nomad, состоит в поддержке количества запущенных сервисов. Говоришь номаду «запусти мне 5 инстансов сервиса» и он их где-то там запускает. Контроля над распределением нет. Инстансы могут запуститься на одном сервере.

Если сервер упал — инстансы переносятся на другие сервера. Пока инстансы переносятся — сервис не работает. Это плохой вариант обеспечения резерва.

1. Распределяем инстансы по серверам через distinct_hosts.
2. Распределяем инстансы по датацентрам. К сожалению, только через создание копии сценария вида сервис1, сервис2 с одинаковым содержимым, разными именами и указанием запуска в разных датацентрах.

В Nomad 0.9 появится функционал, который устранит эту проблему: возможно будет распределять сервисы в процентном соотношении между серверами и датацентрами.

11. Web UI Nomad

Решение: встроенный UI — ужасен, hashi-ui — прекрасен.

Консольный клиент выполняет большую часть требуемого функционала, но иногда хочется посмотреть графики, понажимать кнопочки.

В Nomad встроен UI. Он не очень удобен (даже хуже консольного).

Единственная, известная мне альтернатива — hashi-ui.

По факту, сейчас консольный клиент лично мне нужен только для «nomad run». И даже это в планах перенести в CI.

12. Поддержка oversubscription по памяти

Решение: нет.

В текущих версия Nomad обязательно указывать строгий лимит памяти для сервиса. При превышении лимита — сервис будет убит OOM Killer.

Oversubscription — это когда лимиты сервису могут быть указаны «от и до». Некоторым сервисам при запуске требуется больше памяти, чем при обычной работе. Некоторые сервисы могут кратковременно потреблять больше памяти, чем обычно.

Выбор строго ограничения или мягкого — тема для дискуссий, но, например, Kubernetes даёт программисту сделать выбор. К сожалению, в текущих версиях Nomad такой возможности нет. Допускаю, что появится в будущих версиях.

13. Очистка сервера от сервисов Nomad

Решение:

Иногда «что-то идёт не так». На сервере убивает агентскую ноду и она отказывается запускаться. Или агентская нода перестаёт отвечать на запросы. Или агентская нода «теряет» сервисы на данном сервере.
Такое иногда случалось со старыми версиями Nomad, сейчас такое или не происходит, или очень редко.

Что в таком случае сделать проще всего, учитывая, что drain сервера не даст нужного результата? Очищаем сервер вручную:

1. Останавливаем агента nomad.
2. Делаем umount на создаваемые им mount.
3. Удаляем все данные агента.
4. Удаляем все контейнеры, фильтруя служебные контейнеры (если есть).
5. Запускаем агента.

14. Как лучше разворачивать Nomad?

Решение: конечно, через Consul.

Consul в данном случае — отнюдь не лишняя прослойка, а органично вписывающийся в инфраструктуру сервис, который даёт больше плюсов, чем минусов: DNS, KV хранилище, поиск сервисов, мониторинг доступности сервиса, возможность безопасного обмена информацией.

Кроме того, он разворачивается так же просто, как и сам Nomad.

15. Что лучше — Nomad или Kubernetes?

Решение: зависит от.

Раньше у меня иногда появлялась мысль начать миграцию в Kubernetes — так сильно меня раздражал периодическая самопроизвольная перезагрузка сервисов (см. проблему №8). Но после полного решения проблемы могу сказать: Nomad меня устраивает на данный момент.

С другой стороны: в Kubernetes так же существует полу-самопроизвольная перезагрузка сервисов — когда планировщик Kubernetes перераспределяет инстансы в зависимости от нагрузки. Это не очень здорово, но там это настраивается скорее всего.

Плюсы Nomad: очень легко разворачивается инфраструктура, простые сценарии, хорошая документация, встроенная поддержка Consul/Vault, что в свою очередь даёт: простое решение проблемы хранения паролей, встроенный DNS, простые в настройке хелсчеки.

Плюсы Kubernetes: сейчас это «стандарт де факто». Хорошая документация, множество готовых решений, с хорошим описанием и стандартизацией запуска.

К сожалению, у меня нет такого же большого экспертного опыта в Kubernetes, чтобы однозначно ответить на вопрос — что использовать для нового кластера. Зависит от планируемых потребностей.
Если у вас планируется множество неймспейсов (проблема №5) или ваши специфические сервисы потребляют много памяти на старте, далее освобождая её (проблема №12) — однозначно Kubernetes, т.к. эти две проблемы в Nomad решены не до конца или неудобно.

Источник