Администрирование

Почти тонкий клиент на базе Linux, с авторизацией через штрихкод и автоматическим запуском 1С в RDP сессии Windows.

После некоторых событий, на производстве появилась необходимость упрощения, удешевления и автоматизации входа постов (тонких клиентов) в 1С.

Какие основные моменты нужно было решить:

1. Убрать хранение пароля в ветке реестра Winlogon на ОС Windows
2. Убрать хранение пароля пользователя 1С в скрипте .bat
3. Попробовать дать вторую жизнь устаревшим компьютерам с 1-2 гб ОЗУ и процессорами Intel Atom D425, или старее
4. Автоматизировать вход до 1С сканированием единственного штрихкода/QR-кода на рабочем месте
5. Минимизировать время замены рабочей станции в случае аварии/выхода из строя
6. Сделать универсальный образ как для Legacy так и для UEFI совместимых компьютеров

Начну с того, что нигде полностью готового решения или хотя бы статьи‑инструкции «сделай сам» я не нашёл.

Механизм работы с файловой системой в Podman очень схож с Docker. Но есть несколько нюансов. Так как Podman разрабатывался с упором на безопасность и rootless, порой возникают неочевидные ошибки при монтировании volumes. Сегодня рассмотрим эти нюансы и поглубже заглянем в кроличью нору.

Как мы превратили стрессовые ручные релизы в предсказуемый one-click процесс с GitOps и автоматикой. 60+ модулей, аудиторы и регуляторика — в едином шаблоне, который масштабировался на 30+ сервисов. Без магии, но с инженерной дисциплиной

Добавляйте их не через -cdrom а вот так.
Обратите внимание на параметр "index=2". Число должно быть разным у каждого cdrom.

Как определить дистрибутив Linux? А что, если имеется только информация о пакетах, установленных на устройстве? История одного «велосипеда» или мы не нашли готового решения.

Представьте, что вам нужно определить дистрибутивы, опираясь исключительно на установленные пакеты. Инвентаризация есть, но данные неполные — часто известно только имя хоста, IP и список установленных пакетов. Операционная система может быть указана как «Linux» без уточнения дистрибутива и версии. О создании алгоритма, работе с KUMA и написании код в данной статье.

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

В 2024 году мы рассказывали, как поднять свой сервер внутри РФ, чтобы получить доступ к российским сайтам из-за рубежа. Проблема остаётся актуальной и в 2026 году. Всё больше сервисов применяют географические ограничения доступа, из-за чего пользователи за рубежом не могут на них попасть. При этом многие граждане РФ живут и работают за пределами страны, но продолжают пользоваться российскими онлайн-сервисами.

Уже несколько лет Диасофт занимается разработкой продуктов в микросервисной архитектуре. На начальном этапе у компании не было потребности в полной автоматизации для организации выпуска, тестирования и доставки на целевые стенды. Со всеми этими активностями справлялись сами команды в ручном режиме с применением частично автоматизации, где это было целесообразно.

Однако со временем в компании была создана экосистема low-code разработки микросервисных программных продуктов Digital Q, которая позволила нашим производственным командам автоматически генерировать часть прикладного кода, что значительно ускорило разработку продуктов.

Как следствие внедрения экосистемы low-code платформ быстро росло количество продуктов и команд. В день мы делали уже более 2 000 коммитов от 100+ команд в 300+ микросервисах на 200+ проектах.

На этом этапе встал вопрос: как теперь быстро, полностью автоматически, выпускать и доставлять все это? Ответом стало решение «Диасофт» Digital Q.DevOps. Оно автоматизирует весь процесс (от сборки и выпуска продуктов до доставки на нужные стенды), включая такие важные этапы, как прохождение автотестов и проверки на уязвимости.

Каждый из вас хоть раз ловил себя на мысли: «А почему бы не начать слушать книги вместо того, чтобы их читать?». Пока едешь в метро, стоишь в пробке, занимаешься домашней рутиной или вместо приевшейся музыки в спортзале — сценариев масса.

В сети полно литературы, но если вы эстет и ищете что-то глубже «Онегина» или модных бестселлеров, то наверняка сталкивались с проблемой: нужной книжки в аудио просто не существует.

Так вот, тут мы попадаем в ловушку. Технологий синтеза речи (TTS) сейчас море, а вменяемого инструмента, чтобы массово превращать текст в звук, нет.

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

Я системный администратор. Моя работа — заставлять системы работать эффективно, и я не люблю ждать. Не люблю, когда мой домашний компьютер превращается в жужжащую печку, показывая 1% прогресса в час. Этот материал — не просто туториал, а технический разбор и своего рода «дневник» процесса разработки проекта «Прометей». Мы посмотрим, как превратить выделенный сервер в промышленную фабрику аудиокниг, способную выдавать 20 часов готового звука за 11 минут.

Эта статья дополнение к недавнему переводу другой статьи: Как добавить каталог в PATH.

Несмотря на то, что способы, описанные там рабочие, они несут за собой неочевидные трудности.

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

Существует несколько различных протоколов, предназначенных для обеспечения бесперебойной работы сети на канальном уровне. Сегодня мы рассмотрим Ethernet Ring Protection Switching – технологию, обеспечивающую высокую доступность и отказоустойчивость в кольцевых топологиях.

Привет, Хабр! Меня зовут Никита Чубаров. По трудовому договору я инженер-эксперт по разработке и сопровождению сервисов, а по факту DevOps-инженер с фокусом на доставку в платформенных командах, которые поставляют общие решения для десятка дочерних команд. Со временем эта доставка перестала быть прозрачной и предсказуемой, и всё больше напоминала космолёт, в котором пилот перед каждым запуском вручную подключает провода, проверяет давление в контурах и по списку нажимает десятки кнопок. Пока запусков мало, это ещё можно представить, но когда их становится сотни, а кораблей — десятки, такая схема быстро превращается в источник ошибок и выгорания.

Примерно в таком состоянии у нас находился Bootstrap Namespaces. В статье я расскажу, как мы прошли путь от сложной CI-оркестрации к декларативному управлению Bootstrap Namespaces через Argo CD и GitOps, какие проблемы это позволило убрать и какие новые ограничения пришлось принять.

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

В этой статье мы продолжаем разбирать возможности веб‑сервера Angie по борьбе с DoS (и немного DDoS) атаками. В предыдущей части мы разобрали стандартные средства, а в этой обсудим возможности сторонних модулей и системы Fail2Ban.

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Исходя из моего опыта, могу сказать, что большинство обладателей OpenWrt-роутеров используют для настройки беспроводных интерфейсов достаточно удобный веб-интерфейс LuCI. И только продвинутые пользователи рискуют править конфиги вручную. Но, как правило, даже они часто ограничиваются лишь указанием основных данных: типа стандарта, канала и, собственно, настроек самой Wi-Fi сети. И совершенно зря, так как wireless-конфиг имеет множество самых разнообразных параметров, позволяющих при правильном использовании увеличить покрытие сети или скорость в несколько раз. В этой статье разберем точную настройку файла /etc/config/wireless в OpenWrt, направленную на создание максимально стабильного покрытия Wi-Fi сети. И посмотрим на предрассудки, которые сложились относительно некоторых параметров. Особенно подчеркну, что мы не будем разбирать все параметры (их действительно очень много), а ограничимся только обозначенной задачей. 

Привет, Хабр.
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен» — системы учета и контроля ИТ-инфраструктуры. В этой статье хочу разобрать одну из самых устойчивых и при этом недооцененных проблем корпоративных ИТ — несанкционированную установку программного обеспечения, Shadow IT.

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

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

Важно понимать: в большинстве случаев здесь нет злого умысла. Причины почти всегда лежат в устройстве процессов. Бизнес развивается быстрее, чем ИТ-регламенты, и людям нужно решать задачи здесь и сейчас. При этом согласование нового ПО может занимать дни или недели. Отдельный фактор — работа с подрядчиками, которые устанавливают их в инфраструктуре заказчика привычные им инструменты.

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

Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.

У компании были современные импортные станки с проприетарным софтом, дорогим обслуживанием. Непрерывное круглосуточное производство. Но собственная IT-инфраструктура была слаба – всего несколько разработчиков, а аналитики бизнесовые. Всё же бизнесу нужно было следить за оборудованием: кто работает, кто простаивает, кто отключает датчики. Крайне необходимо было снизить вероятность поломок и простаивания.

В статье расскажу, как «на коленке» собрали многомодульную систему.

На почти каждой Linux-машине в мире живёт один маленький бинарник. Весит несколько мегабайт, несколько десятков тысяч строк кода, поставляется со своим собственным конфигурационным языком, и CVE-шек за ним накопилось столько, что хватит на хорошую таблицу с фильтрами. Большинство из нас запускает его по десятку раз в день, не задумываясь.

Этот бинарник — sudo.

В мире Docker-контейнеров, эфемерных CI-раннеров и Kubernetes-подов, которые живут тридцать секунд и умирают без предупреждения, большая часть того, что умеет sudo, попросту не нужна для той работы, ради которой мы его вообще вызываем.

Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

Монолит без тестов.
Деплой только ночью.
Пять минут гарантированного простоя на каждом релизе.
Логи — в файле.
О проблемах узнаём от клиента.

Малый/средний бизнес МФО, без отдельного DevOps-инженера.
“Специально обученный тимлид”, который знает, какие костыли подпирают систему.

Рассказываю, как из этого получился production baseline: Kubernetes, GitLab CI/CD и наблюдаемость, после которых релизы стали скучными.