Записки IT специалиста

Автоматически обновляем списки адресов Telegram на Mikrotik Что это и для чего – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже. Иначе возникают известные сложности, когда хочется не только хлеба (текста), но и зрелищ (картинок с видосиками) Список нужных нам адресов известен и публикуется официально: https://core.telegram.org/resources/cidr.txt Поэтому мы снова призвали на помощь ИИ и быстренько написали еще один скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии). Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет. P.S. Перед запуском убедитесь, что файл с адресами доступен с вашего устройства 👇👇👇

AI-юрист для решения юридических вопросов за 7 минут! Что я умею: ✅ Создать документ – Проведу вас по шагам и подготовлю точный документ. 📚 Найти практику – Помогу юристам найти нужные решения судов. 🗒 Личный кабинет – Все ваши документы и история в одном месте. 📊 Аналитика — AI проверит документ по законам РФ и покажет ошибки, риски и нужные правки. 🎓 FAQ – Ответы на частые вопросы. Обратная связь – Связь с нашей командой. Узнать больше #реклама 16+ О рекламодателе

Windows Vista – провал или… Windows Vista все считают одним из самых больших провалов Microsoft и в реальности Vista действительно провалилась на рынке, но говорит ли это о том, что Vista была плохой системой? Вовсе нет, плохой системой Vista не была, но ее провал был неизбежным в тех обстоятельствах и при тех решениях, которые сопутствовали ее выходу на рынок. Windows XP был несомненным успехом компании, но вместе с тем становилось понятно, что архитектура NT5 себя исчерпала. Нужны были новые решения и на волне эйфории разработчики замахнулись на нечто принципиально новое – проект Blackcomb. Однако на этом пути что-то пошло не так, планы никак не хотели становиться реальностью и очень скоро стало ясно, что реальных сроков выполнения проекта назвать никто не может, поэтому решили сначала выпустить некоторую промежуточную ОС, которую назвали Longhorn. Но ее разработка тоже на задалась, в результате в 2004 году проект был перезапущен с нуля и были взяты реальные и достижимые цели, потому что время уже серьезно поджимало, рынок ждал новую ОС от Microsoft, а ее все не было… Также для новой ОС были крайне велики пользовательские ожидания, во многом подогретые самой Microsoft, все ждали чего-то нового. Начало разработки тогда еще Blackcomb пришелся на эпоху гонки гигагерц, когда тактовые частоты процессоров постоянно росли и отрасль была полна оптимизма. На момент перезапуска проекта в 2004 году перспективы дальнейшего роста частоты выглядели уже не столь радужно, но все-таки рынок ожидал продолжения роста. В результате, к моменту выпуска в 2007 году Vista оказалась в ситуации, когда она могла нормально запускаться и работать только на достаточно мощных процессорах и системах от 2 ГБ памяти, что составляло на тот момент верхний сегмент рынка. В массах же были те самые «два ядра – два гига», причем ядра там были достаточно скоромные 2-2,2 ГГц, в то время как разработчики предполагали массовое распространение систем с частотами 3-4 ГГц. Но переигрывать что-то было уже поздно, тем более на компанию сильно давили производители ПК, которым нужно было представить на рынке новые компьютеры с Vista и Microsoft серьезно снизила аппаратные требования к системе. Вторым по силе источником негатива стала новая видеоподсистема WDDM, которая полностью отвязывала видеокарту от ядра системы и значительно повышала стабильность. Если раньше крах видеодрайвера означал крах всей системы, то теперь драйвер просто перезапускался, экран моргал и систем работала дальше. Но это привело к серьезной просадке производительности, если раньше ваша видеокарта более-менее тянула современные игры, то теперь вам нужно было идти в магазин за новой. Масла в огонь добавили и программные проблемы. Драйвера к новой системе были не готовы, софт частично несовместим, частично не оптимизирован, вкупе с занижением системных требований это делало Vista похожей на улитку, попавшую в студень. Многие нововведения были также неотрегулированны и раздражали, тот же излишне назойливый UAC или брандмауэр. Со временем многие проблемы решили, оптимизировали производительность, подросли вычислительные мощности, но ничего из этого систему спасти уже не могло, что и показал выпуск первого сервис-пака, после которого Vista, по сути, становилась другой системой. После чего было принято решения закрыть проект и срочно выпустить новую ОС на базе доработанной Vista, которой стала Windows 7 ставшая не менее успешной нежели Windows XP, но это уже совсем другая история. Но не будем забывать, что все то, что мы видим в современных ОС, включая Windows 10 и Windows 11 было впервые реализовано в Windows Vista и технически это была крайне прогрессивная для своего времени система. Но условия в которых она была выведена на рынок не оставили ей ни одного шанса на успех.

Авто из Азии под ключ. Своя логистика = ваша выгода Импортируем автомобили из Китая, Японии и Кореи с 2015 года. Наше главное преимущество — собственная экспортная компания в Китае и стоянки во всех трёх странах. Это позволяет нам экономить ваши деньги и сокращать сроки доставки до минимума. Что вы получаете: ✅ Авто в наличии на наших стоянках — можно выбрать и сразу оформить ✅ Налаженные логистические маршруты без посредников ✅ Полное сопровождение: подбор, доставка, растаможка, оформление ✅ Аккредитация от ВТБ и Примсоцбанка — гарантия надёжности Работаем прозрачно на всех этапах. Команда экспертов с реальным опытом в логистике и автоподборе всегда на связи. Подпишитесь на наш канал — делимся инсайдами рынка, реальными кейсами и спецпредложениями для подписчиков. Подписаться #реклама О рекламодателе

Насколько критично использовать ECC-память для ZFS. Часть 1 Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS. Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно:

В ZFS нет ничего особенного, что требовало бы или поощряло использование ECC‑памяти (памяти с коррекцией ошибок) в большей степени, чем в случае с любой другой файловой системой.

Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные. В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти. Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки. Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным. Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п. Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей. В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study Согласно этим данным, вероятность ошибки в течении одного года составляет для: ▫️ 1 DIMM – 8.2% ▫️ 4 DIMM – 28.98% ▫️ 8 DIMM – 49.56% ▫️ 16 DIMM – 74.56% Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит: ▫️ 1 год – 29% ▫️ 3 года -63% ▫️ 5 лет – 82% Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока. Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок. Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки. Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию. При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок. При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей: 🔸 Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год 🔸 Среди «проблемных» DIMM медианное количество ошибок - 64 в год, среднее - 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок) 🔸 Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените. Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах. В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.

Насколько критично использовать ECC-память для ZFS. Часть 1 Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS. Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно: В ZFS нет ничего особенного, что требовало бы или поощряло использование ECC‑памяти (памяти с коррекцией ошибок) в большей степени, чем в случае с любой другой файловой системой. Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные. В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти. Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки. Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным. Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п. Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей. В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study Согласно этим данным, вероятность ошибки в течении одного года составляет для: 1 DIMM – 8.2% 4 DIMM – 28.98% 8 DIMM – 49.56% 16 DIMM – 74.56% Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит: 1 год – 29% 3 года -63% 5 лет – 82% Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока. Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок. Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки. Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию. При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок. При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей: • Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год • Среди «проблемных» DIMM медианное количество ошибок — 64 в год, среднее — 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок) • Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените. Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах. В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.

Прошла 1/6 года Есть ощущение, что время, когда можно было долго раскачиваться, постепенно уходит. И в такой среде начинают лучше чувствовать себя те, у кого есть порядок в процессах и в голове. Когда всё растёт само по себе — можно позволить себе хаос, лишние проекты, странные решения. Система не обязательна, потому что рынок многое прощает. А вот когда становится чуть сложнее, сразу видно, у кого есть фундамент. В такие периоды начинают выигрывать те, у кого понятные процессы и решения принимаются на основе цифр, а не ощущений. И наоборот, быстро начинают буксовать компании, где всё держится на героизме, ручном управлении и бесконечных «давайте срочно разберёмся». Что же делать? Учиться у лучших ↓ Cобрали подборку digital-каналов, где люди делятся практическим опытом и рабочими подходами: https://t.me/addlist/8CZw7KVA_j0zNmRi Чтобы добавить азарта — среди подписавшихся разыгрываем: 🥇 MacBook Air M4; 🥈 Яндекс Станция Мини 3; 🥉 HUAWEI Freebuds 6. Как участвовать: • Подпишись на папку: https://t.me/addlist/8CZw7KVA_j0zNmRi • Подтверди участие в боте: https://t.me/holly_random_bot?startapp=giveaway_10 🗓 Итоги — 26 марта или при достижении 700 участников Выполнил условия? Тогда включай уведомления 🚀 Реклама. Комбаров А.А. ИНН 220917234103. erid: 2W5zFGaFoNh

Распознаем речь при помощи Whisper Недавно у нас возникла необходимость транскрибировать ряд аудиофайлов в текст с таймкодами и точным разбитием по фразам. Задача даже на сегодняшний день нетривиальная, особенно если вам нужен качественный результат. Бесплатные сервисы либо ограничены по времени, либо сильно страдают по качеству. Поэтому самое время обратиться к достижениям ИИ, а именно Whisper мощной модели для автоматического распознавания речи (ASR) с открытым исходным кодом, разработанная OpenAI. Вы можете использовать ее через API, но платно, либо установить на собственном ПК – бесплатно, но вам понадобится ПК уровнем от среднего и выше, наличие быстрого ускорителя NVIDIA приветствуется, но не является обязательным требованием. На самом деле Whisper – это не одна, а целый набор моделей, предлагающий разное качество распознавания речи и разные требования к ресурсам. На практике имеет смысл использовать модели: ▫️medium – хорошая скорость, среднее качество, 3-5 ГБ ОЗУ ▫️large – профессиональное качество при небольшой скорости и самых больших требованиях к ОЗУ – 10-12 ГБ. ▫️ turbo – то же самое, что и large, но только быстрее, за счет упрощения модели, требует 6-8 ГБ. В нашем случае требовалось транскрибировать запись судебного заседания и medium не всегда нормально справлялся с юридическими терминами, large и turbo делали это гораздо лучше, при этом turbo сильно заметно быстрее. Но так как в юридических делах наиболее важна точность, то мы предпочли модель large, предпочитая качество скорости. На CPU Ryzen 9 5900X скорость ее работы составила примерно 0,25, т.е. на часовую запись у вас уйдет примерно 4 часа времени. Попробовать Whisper можно совсем не сложно на своем оборудовании, после чего самостоятельно сделать выводы о его пригодности в конкретной ситуации. Для работы нам понадобится Python и FFmpeg. Установим их при помощи пакетного менеджера Winget:

winget install -e --id Python.Python.3.12
winget install -e --id Gyan.FFmpeg

Так как мы имеем дело с Python, то, чтобы избежать возможных проблем с зависимостями и библиотеками хорошим тоном является запуск проекта в отдельном виртуальном окружении (ENV), для этого перейдем в папку проекта, скажем F:\Wishper и откроем там терминал с консолью PowerShell, после чего создадим виртуальное окружение:

py -m venv whisper-env

И активируем его:

.\whisper-env\Scripts\Activate.ps1

Впоследствии, когда вы захотите поработать с проектом еще раз, вам потребуется только заново активировать окружение командой, указанной выше. Установим Whisper:

pip install -U openai-whisper

После чего просто запускаем распознавание речи командой:

whisper "audio.mp3" --language ru --model medium --output_format srt

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

"C:/Users/Имя/audio.mp3" 
"C:\\Users\\Имя\\audio.mp3"

Далее указываем язык, модель и формат вывода, если вам нужны точные таймкоды, то используйте стандартный формат субтитров – SRT. Для использования ускорения на GPU вам потребуется заменить некоторые библиотеки, в этом же ENV выполните:

pip uninstall torch torchvision torchaudio -y
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

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

whisper "audio.mp3" --language ru --model medium --output_format srt --device cuda

Если вам нужно дополнительно распознавание спикеров (диаризация), то установите модуль WhisperX:  

pip install whisperx

И добавьте ключ –diarize, например:

whisper "audio.mp3" --language ru --model medium --output_format srt –diarize

Теперь вывод кроме таймкодов будет размечаться метками SPEAKER_00, SPEAKER_01 и т.д Но качество такого распознавания не всегда уверенное, особенно если вы транскрибируете прения или дискуссию, где спикеры могут перебивать друг друга.

Курс по 3D-моделированию Практический курс по 3D-моделированию от производственной компании и центра аддитивных технологий Teleport3D. Обучение основано на реальном опыте работы с деталями, инженерными задачами и 3D-проектами. Курс поможет с нуля разобраться в основах, освоить инструменты и начать создавать свои первые модели. Откройте программу курса и начните обучение. Узнать больше #реклама 16+ teleportschool.getcourse.ru О рекламодателе

Нужен ли мне Active Directory? В комментариях читатели попросили разобрать отдельно этот вопрос, когда и как следует понять, что одноранговая структура себя изжила и пора внедрять Active Directory или не пора… Вопрос непростой и при его рассмотрении следует учитывать ряд аспектов, главные из которых мы разберем. 1️⃣ Экономический. Лицензирование Windows Server, начиная с выпуска 2016 предусматривает новую модель лицензирования, согласно ей вы должны лицензировать все физические ядра сервера, при этом минимальное количество лицензий на процессор – 8, на физический хост – 16. Даже если у вас 1 процессор и 6 физических ядер вы все равно должны лицензировать 16. То же самое касается и виртуальных машин, допустим у вас Windows Server запушен на Proxmox и ему выделено скромных 2 ядра. Сэкономили? Не тут-то было, по условиям лицензии вы обязаны пролицензировать все ядра хоста виртуализации, даже если он работает под ОС отличной от Windows. Т.е. в любом случае это от 16 лицензий на ядро и выше. Если делать все по уму, т.е. два контроллера AD на разных физических узлах – это минимум две лицензии на 16 ядер, также не забываем про CAL для каждого клиента, который использует сервисы Windows прямо или опосредованно. 2️⃣ Поддержка со стороны ПО. У вас в эксплуатации может быть совершенно разное ПО, с разными свойствами и возможностями интеграции. После чего вам нужно изучить насколько оно совместимо c AD. Как минимум, оно должно поддерживать сквозную аутентификацию и авторизацию. И эти два термина путать не в коем случае нельзя. Аутентификация – процесс установления личности пользователя, которая указывает на то, что он действительно тот, за которого себя выдает. И не более. Авторизация – проверка прав доступа аутентифицированного пользователя к некоторому ресурсу. Т.е. на этапе аутентификации мы установили, что это действительно Иванов, а на этапе авторизации мы проверяем, имеет ли Иванов доступ к запрашиваемому ресурсу. Active Directory, как и любая другая служба каталогов решает в первую очередь вопрос Single Sign-On (SSO, единый вход), т.е. пользователь один раз вводит пароль при входе в учетную запись и получает доступ везде, куда у него есть права. Это позволяет избежать отдельных списков доступа и набора учетных записей для каждой службы, но при этом все используемые вами службы должны поддерживать вход через домен AD. Где-то приложения могут поддерживать только сквозную аутентификацию и вам все равно придется вести отдельные списки доступа на уровне приложения. 3️⃣ Централизация администрирования. Третий краеугольный столп AD – групповые политики, которые позволяют централизованно настраивать операционную систему и ПО. Здесь мы тоже исходим из принципа целесообразности. Как активно мы используем GPO? Какое количество политик используем? Как часто изменяем и добавляем новые? Какой выигрыш по времени мы от этого всего имеем? Если наше ПО не имеет возможности работать с GPO, то в чем смысл применения данной технологии? Все равно нам нужно настраивать каждую рабочую станцию руками. Убрать из работы рутину? А сколько ее там? Может можно переложить эту работу на скрипты или выполнить вместе с настройкой производственного ПО. 4️⃣ И четвертое, не столь очевидное – квалификация персонала. AD более требовательна к квалификации обслуживающих специалистов, так как централизация это и возможность быстро и просто настроить сеть, и возможность также быстро и просто все уронить. И выиграв на выполнении некоторых административных задач вы проиграете на стоимости обслуживающего персонала. А в наше время еще надо смотреть на возможные перспективы развития и импортозамещения и только после этого делать выбор в пользу проприетарных технологий.

Каждый день на ПП выглядит одинаково? Курица, гречка, салат. И так по кругу. Через неделю такое питание начинает надоедать, и мысль о том, что снова нужно поужинать, вызывает только усталость. Но правильное питание может выглядеть иначе: сбалансированно и вкусно. Именно таким подходом делится Маша. Маша - шеф-повар, которая сама похудела на 25 кг и уже несколько лет удерживает результат. В своем канале она показывает, как соблюдать ПП даже при плотном графике: ✅ готовить один раз в неделю и освобождать часы каждый день; ✅составляйте полезные завтраки, обеды и ужины за 10 минут из заготовок ; ✅ экономить до 30% бюджета на продукцию ; ✅ питаться разнообразно, без срывов и постоянных мыслей «что приготовить». Переходите в канал Маши - в закреплённом сообщении вы найдете пошаговый план заготовок с рецептами Смотреть #реклама 16+ О рекламодателе

Настраиваем терминальный сервер на Windows Server в рабочей группе Роль терминального сервера пользуется огромной популярностью у системных администраторов самых разных по размеру предприятий, от самых маленьких, до очень больших. Действительно, это достаточно эффективный способ организации работы пользователей и эффективного использования вычислительных ресурсов. Но есть и определенные сложности: начиная с Windows Server 2012 компания Microsoft решила, что для развертывания терминальных служб обязательно нужен домен Active Directory. Это не всегда приемлемо и уместно. Значит будем обходиться без домена, а как - расскажем в нашей статье. ✅ Читать далее

Как понять, какое направление в ИБ стоит сейчас рассматривать? Мы создали навигатор по профессиям и направлениям в ИБ, который определит варианты развития в зависимости от вашей текущей ситуации, и покажет открытые курсы Академии Кодебай. 👉👉👉 Пройти навигатор можно за 30 секунд по ссылке

Как правильно редактировать юниты systemd Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи. Действительно, сравните сложность написания init-файла и юнита. 🤷🏻‍♀️ И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами. Начнем с мест их расположения, которые перечислим в порядке повышения приоритета: ▫️ /usr/lib/systemd/system – юниты установленные вместе с пакетами ▫️ /run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса ▫️ /etc/systemd/system – юниты, созданные системным администратором Директория /etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения. Вроде бы просто, да не совсем. При обновлении пакета юнит в /usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим. Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит. К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично. Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям. Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in. Скажем, нам нужно внести изменения в работу юнита myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf. Проще всего это сделать с помощью команды:

 systemctl edit myservice

Напоминаем, что если вы не указали тип юнита, то по умолчанию он принимается за service, а если вам нужно внести изменения в таймер, то придется указать имя юнита полностью:

 systemctl edit myservice.timer

Затем указываем только те опции, которые хотим переопределить или добавить, например:

 [Unit]
 Requires=новая зависимость
 After=новая зависимость

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

 [Service]
 ExecStart=новая команда

То эта строка будет добавлена к существующим строкам ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:

 [Service]
 ExecStart=
 ExecStart=новая команда

Если у вас несколько Drop-in файлов, то изменения в них будут применяться по очереди, для расстановки приоритетов можете использовать цифровые префиксы файлов. Еще одним достоинством команды systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена. Откатить изменения можно командой

 systemctl revert myservice

Если вы редактируете drop-in файлы вручную, то после каждого изменения перечитайте конфигурацию:

 systemctl daemon-reload

И перезапустите службу

 systemctl restart myservice

Как видим, systemd дает в руки администратора серьезные инструменты позволяющие точечно редактировать конфигурацию юнитов. Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.

Получайте до 50% с каждой продажи лицензии Битрикс24 Bitrix24 заменяет сразу десятки инструментов для совместной работы, продаж и автоматизации бизнеса. Продавайте и внедряйте Bitrix24 и зарабатывайте вместе с нами: - до 50% с каждой продажи лицензии - 100% с каждого внедрения Участие в партнёрской программе бесплатно — у нас нет комиссий и обязательных платежей. Что мы предлагаем: - Бесплатное обучение для партнёров: курсы по продажам, маркетингу и продукту - Регулярный поток заявок - Готовые маркетинговые материалы для бизнеса - Персональный менеджер, который поможет разобраться в нюансах программы и предложит лучшие решения для вашего бизнеса Переходите на сайт и оставляйте заявку на регистрацию в программе! Перейти на сайт #реклама 16+ partners24.1c-bitrix.ru О рекламодателе

Демилитаризованная зона (DMZ) в современных сетях Концепция DMZ известна давно, предполагалось, что это будет отдельный сегмент сети, отделенный брандмауэрами как от внешней, так и от внутренних сетей, и в нем будут размещены потенциально небезопасные сервисы. Т.е. мы собирали в таком сегменте все сервисы, имеющие доступ из внешнего мира, и ограничивали их собственной подсетью, серьезно ограничив или вообще запретив возможность доступа к внутренней сети. Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности. Данный подход позволял в случае взлома или компрометации внешнего сервиса ограничить злоумышленника рамками DMZ и избежать их проникновения за периметр основной сети предприятия. В целом такой подход работает и сегодня для классических служб, таких как веб-сервер или электронная почта. Помещая такие сервера в отдельный сегмент и закрыв их брандмауэром как от внешней, так и внутренней сети мы повышаем как безопасность внутри периметра, так и безопасность самих вынесенных в DMZ сервисов. Но современные реалии вносят новые угрозы. Например, понятие периметра сегодня оказалось серьезно размыто и далеко не каждая внутренняя сеть может считаться безопасной. Причин тому несколько. Начиная с собственных устройств сотрудников, которые они используют в рабочем процессе (чаще всего телефоны) и которые имеют доступ к сети предприятия и заканчивая средствами удаленного доступа, которые используются не только сотрудниками, но и подрядчиками и партнерами. Все это приводит к тому, что внутренняя сеть перестает быть безопасным и доверенным местом, поэтому политика нормально открытого брандмауэра внутри таких сетей перестает быть приемлемой. Можно, конечно, настраивать брандмауэр на каждом сервере отдельно, но это утомительно и всегда есть возможность что-то упустить. Поэтому более интересной является мысль вынести внутренние сервера в отдельную DMZ и тем самым поместить их в доверенную среду, которую затем можно просто закрыть от внутренней сети межсетевым экраном. Получается, как бы немного наоборот. Если классическая DMZ изолировала от доверенной локальной сети потенциально небезопасные узлы, то в нашем случае DMZ защищает сервера от потенциальных угроз из внутренней сети. В принципе данный подход уже давно используется там, где работают с конфиденциальной и секретной информацией, когда содержащие такие данные узлы выносят в изолированные участки сети с ограниченным доступом. Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе. И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей. В этом случае все удаленщики также помещаются в отдельный сегмент, который изолирован как от внешней, так и от внутренней сети, а доступ к необходимым сервисам осуществляется посредством проброса портов или обратным проксированием. При этом никаких сервисов в этой зоне быть не должно, только удаленщики и только средства доступа к необходимым им сервисам внутри сети или в отдельных DMZ. Таким образом сегодня понятие DMZ серьезно расширилось и теперь не просто предусматривает некую отдельную подсеть для потенциально ненадежных сервисов, а подразумевает разделение сети на сегменты с разным уровнем безопасности и доверия, совершенно безотносительного того, являются помещенные в DMZ сервисы внешними или внутренними. А в ряде случаев и вовсе не предполагает размещение там каких-либо сервисов, используя DMZ для изоляции ненадежных пользователей.

Почему компании получают штрафы за ПДн? На вебинаре 17 марта специалисты F6 разберут реальные ошибки в работе с ПДн, практику проверок и шаги, которые помогут снизить риски без формального «аудита для галочки». Почему это важно? Штрафы чаще связаны не с кибератаками, а с неправильно выстроенными процессами обработки ПДн. При этом требования регулятора ужесточаются, а контроль становится системнее. Подключайтесь к вебинару, чтобы узнать: — какие ошибки чаще всего выявляются при проверках — как корректно выстроить процесс получения согласий — как снизить риски при работе со специальными и биометрическими ПДн — какие процессы должны быть формализованы внутри компании Зарегистрироваться на вебинар → #реклама О рекламодателе

Скомпрометированные пароли Как мы знаем, хороший пароль должен быть сложным. Но в настоящее время этого недостаточно. Ваш пароль еще не должен быть скомпрометирован. Что это такое и чем чревато? При компрометации пароль становится известен широкому кругу лиц и попадает в специальные базы, которые могут впоследствии использоваться для подбора паролей. А это крайне серьезно снижает надежность системы. Поэтому перед применением пароль желательно проверить на компрометацию, тем более это нужно сделать для уже используемых паролей. Как это сделать? Можно использовать базу HIBP, где содержится более 306 миллионов утекших в сеть паролей. Для этого следует использовать специальный сайт https://haveibeenpwned.com/Passwords Можно ли ему доверять и не грозит ли это утечкой пароля? Можно, сайт использует специальный протокол, который позволяет проверить пароль на утечку без раскрытия самого пароля. Через API данная база используется для проверки утечек паролей многими коммерческими сервисами и менеджерами паролей. Также должно быть ясно, что любые непонятные приложения и иные сайты, обещающие аналогичные функции быть безопасными не могут и использовать их не следует. Кроме того, если вы не доверяете свои пароли никаким онлайн-сервисам или хотите самостоятельно работать с базой утекших паролей, то вы можете скачать ее при помощи инструмента PwnedPasswordsDownloader https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader Это тоже официальный инструмент, при помощи которого вы получите список хешей утекших паролей, а дальше уже на что хватит знаний и умений. На скриншоте мы проверили в сервисе один очень «популярный» пароль из десяти букв и цифр подряд на клавиатуре, набранных по очереди: 1q2w3e45t

Ручной сварочный экструдер для пластика! Ручной экструдер для сварки пластика. Обучение бесплатно Узнать больше #реклама экструдер-ручной.рф О рекламодателе

Аптайм Когда-то давно, когда деревья были выше, трава зеленее, а пиво вкуснее, аптайм был некой «сакральной» величиной, которой было принято меряться и его величина считалась признаком крутости, которая была прямо пропорциональна величине аптайма. А те, у кого был короткий (аптайм, разумеется), подвергались насмешкам и не допускались в почтенное общество гигантов системного администрирования. Но те времена давно прошли и в нашу эпоху интернета с доступом туда каждого чайника и утюга большой аптайм стал признаком низкой квалификации и непрофессионализма. Как минимум это означает, что все это время система находилась без обслуживания, как на программном, так и на аппаратном уровне. Также это означает, что на нее не ставились обновления и вообще не уделяли внимания. А это, особенно если к системе есть доступ из интернета – очень плохо. Сегодня толпы ботов только и делают, что рыщут по просторам сети в поисках различных уязвимостей. Еще одна популярная отмазка: «мол у меня там важные сервисы 24/7 и совсем-совсем никак» — это ничто иное как завуалированное признание собственной низкой квалификации. Ее следует понимать как: вот тут у меня огромная точка отказа, сюда столько всего накручено и завязано, что даже перезагружать страшно. Можно приводить массу контраргументов, но, по сути, они не меняют главного: если ваша инфраструктура не позволяет перезагрузить узел, то она построена плохо. Особенно сегодня, когда даже самым маленьким за очень недорого доступны и виртуализация, и кластеризация и много-много чего другого. Поэтому меряться аптаймом сегодня глупо, он просто есть и никакой ценной информации не несет. Системы должны обслуживаться и перезагружаться, это нормально. Равно как не стоит говорить о «важных» и «круглосуточных» сервисах. Если они построены так, что их нельзя вывести на облуживание – значит они построены плохо. И нужно не бравировать этим, а думать, как сделать хорошо. Или пригласить того, кто может это сделать. А критерием хорошо построенной и работающей системы должен быть не аптайм, а высокий уровень доступности ее сервисов для пользователя. Ему все равно, сколько система проработала без перезагрузки, ему надо чтобы она просто работала.