Будь то получение второго билета, просмотр истории платежей или просмотр последних минут собрания, приложение Unit будет на вашей стороне, чтобы облегчить вашу повседневную жизнь.
С его помощью вы можете:
— Просмотрите свой открытый тикет устройства, скопируйте цифровую строку и произведите оплату в приложении вашего банка.
— Проверьте историю предыдущих платежей вашей квоты кондоминиума.
— Просмотр объявлений, выпущенных администратором
— Просмотр документов, таких как протоколы заседаний, внутренние правила и соглашения
— Открытые звонки администратору и / или получателю
— Эксклюзивная зона для ликвидатора
Приложение всегда уникально в использовании. Для доступа к нему используйте тот же логин и пароль, что и на портале подразделения.
Последнее обновление
3 мая 2022 г.
Стиль жизни
Безопасность данных
arrow_forward
Чтобы контролировать безопасность, нужно знать, как разработчики собирают ваши данные и передают их третьим лицам. Методы обеспечения безопасности и конфиденциальности могут зависеть от того, как вы используете приложение, а также от вашего региона и возраста. Информация ниже предоставлена разработчиком и в будущем может измениться.
Зачем нужно изучать и писать юнит-тесты
Источник: play.google.com
Systemd – очень быстрый старт
При работе в операционной системе нужно постоянно запускать разные программы. Следить за их состоянием. Перезапускать упавшее. Существует целый пласт утилит, который решает эту задачу (от простейшего init.d до навороченного svc). Сейчас в Linux стандартом де-факто стал systemd – его используют все современные дистрибутивы.
Это – очень короткое и очень простое введение в systemd. Минимум текста – максимум пользы.
SystemD – это менеджер загрузки. Он получает управление от ядра при старте операционной системы (init), запускает разные сервисы и следит за их состоянием (например – перезапускает упавшие). Идеолог – Леннар Поттеринг из RedHat. Systemd очень своеобразная штука, умеет она довольно много и устройство у нее довольно сложное.
Systemd заслуженно любят за мощный и гибкий функционал – это здорово облегчает жизнь разработчика и админа. Systemd заслуженно ненавидят за тягу к изобретению уже реализованных в операционной системе вещей и спорное поведение в некоторых вопросах безопасности.
Эта статья – краткое практическое руководство. Теории тут – минимум. Если вас интересует устройство systemd – вам в официальное руководство.
Введение и терминология
Systemd отвечает за запуск программ и сервисов после старта операционной системы. Он следит за процессом загрузки, решает что запустить и как. Строго говоря, он делает ровно то же самое, что делал SystemV init. Systemd писали значительно позже init – в нем пытались починить вещи, которые в init сделаны плохо. Например, в init нет возможности сделать зависимость запуска одного сервиса от другого.
Что такое Unit тестирование 🛗 и почему без него никак не обойтись
Так же init не поддерживает параллельной загрузки. Параллельная загрузка сервисов радикально ускоряет старт операционной системы.
Unit
Unit – это описание сервиса (в широком смысле этого слова). Unit-файл описывает все настройки сервиса, как его запускать, когда (очередность, зависимости) и что делать, если запуск не удался. Unit-ы, которые пишет пользователь руками – должны находится в /etc/systemd/system и иметь окончание .service в названии. Юниты, которые устанавливают пакеты – находятся в ином месте. Если в нескольких папках лежит юнит с одним и тем же именем – применяется тот, что лежит в /etc/systemd/system . Пример юнита:
[Unit] Description=etcd – highly-available key value store Documentation=https://github.com/coreos/etcd Documentation=man:etcd After=network.target Wants=network-online.target [Service] Environment=DAEMON_ARGS= Environment=ETCD_NAME=%H EnvironmentFile=-/etc/default/%p WorkingDir=/var/lib/etcd Type=notify User=etcd PermissionsStartOnly=true ExecStart=/usr/bin/etcd $DAEMON_ARGS Restart=on-abnormal RestartSec=10s LimitNOFILE=65536 [Install] WantedBy=multi-user.target
Я специально взял юнит посложнее, чтобы пример был наглядным. На что обратить внимание:
- Description – человеко-читаемое описание. Показывается по команде service status
- After – начать загрузку после того, как начнется загрузка сервиса (или цели)
- Wants – опциональная зависимость. Подробнее ниже, в разделе про зависимости
- Environment – создать переменную окружения при запуске этого сервиса
- WorkingDir – демон запускается из этой папки. Аналогично cd /var/lib/etcd перед запуском
- Type – тип сервиса. Подробнее ниже
- User – имя пользователя, от которого будет запущен сервис
- PermissionsStartOnly – используется, если перед стартом нужна какая-то специальная подготовка – создание папок, изменение прав и так далее. При PermissionsStartOnly=true эти действия будут выполнятся от root. Без – от имени User
- ExecStart – что, собственно, запускать. Обязательно полный путь
- RestartOn – при каких условиях перезапускать
- WantedBy – в какой target должен быть установлен сервис. Подробнее – в разделе про target-ы
Виды Unit-ов
Systemd может обслуживать процессы с разным поведением. Тип описывает, как systemd будет с ним взаимодействовать. Есть следующие варианты:
- Type=Simple – самый стандартный тип. Процесс остается в foreground, stdout перехватывается systemd. Это тип по умолчанию.
- Type=Forking – прямая противоположность. Процесс должен форкнуться и отсоединится от foreground. Для этого типа юнитов должен быть указан pid через директиву PIDFile .
- Type=oneshot – процесс, который успешно выполняется (не делая fork) и завершается. Пример – монтирование файловых систем. Рекомендуется добавить RemainAfterExit=yes в юнит, чтобы результаты работы процесса остался в статусе юнита.
- Type=notify – аналог simple, но в этом случае сам процесс сообщит systemd о том, что он закончил загрузку и готов к работе.
Взаимодействие с unit-ами
После каждого изменения файла юнита (создание/изменение/удаление) – нужно перечитывать изменения, так как состояния юнитов systemd кеширует:
systemctl daemon-reload
Запус, состояние, остановка:
#запуск systemctl start [unit] service [unit] start #состояние systemctl status [unit] service [unit] status #остановка systemctl stop [unit] service [unit] stop #сервис в автозагрузку systemctl enable [unit] #полностью запретить запуск сервиса (даже команда service [unit] start не поможет) systemctl mask [unit] #разрешить запуск обратно systemctl unmask [unit]
Systemd имеет свою собственную реализацию логирования (хотя по умолчанию в syslog копию сообщения он тоже отправляет). Чтение сообщений от сервисов – командой journalctl. Команда очень мощная, умеет много. Ниже примеры
#чтение информации по юниту journalctl -u [UNIT] #чтение по PID journalctl _PID=12 #аналогично по конкретному файлу journalctl /usr/bin/atd #чтение информаций о юнитах, завершившихся с ошибкой journalctl -xn #чтение журнала с момента загрузки journalctl -b #чтение журнала с определенного момента journalctl —since=»2018-01-24 10:15:10″ journalctl —since «10 minutes ago» #постоянное отслеживание событий (аналог tail -f) journalctl -f #по умолчанию systemd обрезает строки по длине экрана. Запретим ему это: journalctl -l #фильтры можно комбинировать journalctl -u redis -f -l —since «10 minutes ago»
Управление зависимостями, очередность загрузки юнитов
Для управления зависимостями в unit есть ключевые слова Wants , Requires и After :
- After – сервис начнет загрузку после того, как начнет загружаться сервис, указанный в After .
- Wants – сервис начнет загрузку после того, как закончит загружаться сервис, указанный в Wants . Статус загрузки этого сервиса не важен – даже если он упал и загрузится не смог – юнит попытается стартовать. То есть зависимость эта опциональная, и нужна она только для того, чтобы наш сервис начал загружаться не раньше, чем другой – закончит.
- Requires – сервис начнет загрузку после того, как сервис, указанный в Requires закончит загрузку успешно. Если сервис-зависимость загрузится не смог – наш сервис так же упадет с ошибкой (точнее – он даже не будет стартовать).
Targets
Target – целевое состояние системы. Именно Target определяет, какие сервисы будут загружены и в каком порядке. Аналог из мира sysV init – runlevel. Основные виды таргетов:
- poweroff – отключение системы
- rescue – режим восстановления, однопользовательский (init 1)
- multi-user – сетевой режим без графической оболочки, (init 3)
- graphical – сетевой режим с графической оболочкой (init 5)
- reboot – перезагрузка
- emergency – аварийная командная строка, минимальный функционал
Цели могут наследоваться друг от друга. Например, graphical включает в себя загрузку всего, что есть multiuser + после этого – подгрузку графической оболочки.
Взаимодействие с целями:
#список целей systemctl list-units —type=target #перейти в нужную цель (например – загрузится из сетевого режима в графический) systemctl isolate graphical.target #выбрать target по умолчанию systemctl set-default multi-user.target
Заключение
systemd на данный момент — стандарт в linux-based операционных системах. Инструмент мощный, удобный и популярный, пусть и не без особенностей. Надеюсь, эта статья поможет начать им пользоваться.
Источник: prudnitskiy.pro
Systemd за пять минут
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
Юнит представляет из себя текстовый файл с форматом, похожим на файлы .ini Microsoft Windows.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Description=MyUnit
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
Для запуска сервиса необходим запущенный сервис mysql:
Requires=mysql.service
Для запуска сервиса желателен запущенный сервис redis:
Wants=redis.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
Type=simple
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
Type=forking
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
PIDFile=/work/www/myunit/shared/tmp/pids/service.pid
Рабочий каталог, он делается текущим перед запуском стартап команд:
WorkingDirectory=/work/www/myunit/current
Пользователь и группа, под которым надо стартовать сервис:
User=myunit
Group=myunit
Environment=RACK_ENV=production
Запрет на убийство сервиса вследствие нехватки памяти и срабатывания механизма OOM:
-1000 полный запрет (такой у sshd стоит), -100 понизим вероятность.
OOMScoreAdjust=-100
Команды на старт/стоп и релоад сервиса
ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb —daemon
ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
TimeoutSec=300
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
Restart=always
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
WantedBy=multi-user.target
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
[Unit] Description=MyUnit After=syslog.target After=network.target After=nginx.service After=mysql.service Requires=mysql.service Wants=redis.service [Service] Type=forking PIDFile=/work/www/myunit/shared/tmp/pids/service.pid WorkingDirectory=/work/www/myunit/current User=myunit Group=myunit Environment=RACK_ENV=production OOMScoreAdjust=-1000 ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb —daemon ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart TimeoutSec=300 [Install] WantedBy=multi-user.target
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
myunit.service — MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; disabled) Active: inactive (dead)
Видим, что он disabled — разрешаем его
systemctl enable myunit
systemctl -l status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
myunit.service — MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; enabled) Active: inactive (dead)
Запускаем сервис
systemctl start myunit
Смотрим красивый статус:
systemctl -l status myunit
Если есть ошибки — читаем вывод в статусе, исправляем, не забываем после исправлений в юните перегружать демон systemd
Источник: habr.com