Подборка актуальных материалов по Samba
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
👍35
Установка облачного файлового сервиса Seafile на Ubuntu Server
Облачные сервисы для хранения и обмена файлами давно стали привычными и популярными как среди простых пользователей, так и в корпоративной среде.
В большинстве случаев публичные сервисы закрывают основные потребности пользователей в облачных хранилищах, но в ряде случаев может потребоваться собственное решение.
Это может быть связано как с объемом хранимых данных, так и с требованиями безопасности или конфиденциальности.
В этом случае обратите внимание на Seafile - простой и производительный облачный файловый сервис, который несложно установить самостоятельно.
https://interface31.ru/tech_it/2023/09/ustanovka-oblachnogo-faylovogo-servisa-seafile-na-ubuntu-server.html
Облачные сервисы для хранения и обмена файлами давно стали привычными и популярными как среди простых пользователей, так и в корпоративной среде.
В большинстве случаев публичные сервисы закрывают основные потребности пользователей в облачных хранилищах, но в ряде случаев может потребоваться собственное решение.
Это может быть связано как с объемом хранимых данных, так и с требованиями безопасности или конфиденциальности.
В этом случае обратите внимание на Seafile - простой и производительный облачный файловый сервис, который несложно установить самостоятельно.
https://interface31.ru/tech_it/2023/09/ustanovka-oblachnogo-faylovogo-servisa-seafile-na-ubuntu-server.html
👍35👎4
Записки IT специалиста pinned «Установка облачного файлового сервиса Seafile на Ubuntu Server Облачные сервисы для хранения и обмена файлами давно стали привычными и популярными как среди простых пользователей, так и в корпоративной среде. В большинстве случаев публичные сервисы закрывают…»
Админу на заметку - 32. Visual C++ Redistributable или устраняем ошибки "отсутствует DLL"
Распространяемые пакеты Microsoft Visual C++ Redistributable требуются довольного многим приложениям, но не всегда входят в пакет установки, вызывая ошибки типа "отсутствует MFC110.dll" или "MSVCP120.dll".
К сожалению, не все понимают причину возникновения подобных ошибок, а следовательно правильные пути их устранения.
В данной статье мы рассмотрим, что такое Распространяемые пакеты Microsoft Visual C++ Redistributable, для чего они нужны и как устранить связанные с ними ошибки.
https://interface31.ru/tech_it/2023/09/adminu-na-zametku---32-visual-c-redistributable-ili-ustranyaem-oshibki-otsutstvuet-dll.html
P.S. Аналогичный материал недавно был на канале. В статье расширенная и дополненная версия материала.
Распространяемые пакеты Microsoft Visual C++ Redistributable требуются довольного многим приложениям, но не всегда входят в пакет установки, вызывая ошибки типа "отсутствует MFC110.dll" или "MSVCP120.dll".
К сожалению, не все понимают причину возникновения подобных ошибок, а следовательно правильные пути их устранения.
В данной статье мы рассмотрим, что такое Распространяемые пакеты Microsoft Visual C++ Redistributable, для чего они нужны и как устранить связанные с ними ошибки.
https://interface31.ru/tech_it/2023/09/adminu-na-zametku---32-visual-c-redistributable-ili-ustranyaem-oshibki-otsutstvuet-dll.html
P.S. Аналогичный материал недавно был на канале. В статье расширенная и дополненная версия материала.
👍22
Замедление интернета
На этой неделе несколько раз получал жалобы от заказчиков по поводу плохой работы интернета, общие симптомы – низкая скорость доступа к отдельным сайтам, невозможность получить тяжелое содержимое, лаги при просмотре мультимедиа.
Сайты были преимущественно зарубежные, но и не только. И какой-то единой взаимосвязи не просматривалось, тем более что сайт мог грузиться быстро, а отдельные его элементы медленно или не загружались вообще.
Сами мы столкнулись с такой ситуацией попытавшись скачать клиент Seafile с официального сайта, скорость оказалась сильно медленной 54 КБ/с (что видно на рисунке ниже), при этом на VPS от Oracle этот же самый файл скачался на полной скорости.
В результате проведенных экспериментов стало ясно, что замедляется доступ к ряду крупных хостингов и CDN, например, таких, как amazonaws.
С чьей стороны происходит данное замедление – непонятно, но факт имеет место быть. Пока работает решение с обходом через VPN, лучше всего при этом использовать приватный сервер.
В связи с этим появился ряд размышлений. Замедление, в отличие от блокировок, гораздо более мягкий, но в то же время более эффективный способ блокирования доступа к нежелательным ресурсам.
Блокировка – это достаточно неэффективный метод, он прост и туп, как сибирский валенок. И одно дело, когда блокируется всякая грязь, неинтересная ширнармассам и совсем другое, когда под раздачу попадают ресурсы с развлекательным контентом.
За минувшие годы слово VPN выучили даже бабушки у подъезда, причем не только выучили, но и освоили его использование.
Блокировать VPN-сервисы – тоже такой себе вариант, на смену одним придут другие, бегай, гоняйся за ними.
А вот замедление куда интереснее, так как большинство пользователей просто не поймет в чем тут дело. Особенно если сделать все по уму.
Не нужно блокировать сам Yotube или еще какую соцсеть, даже не нужно замедлять сам основной сайт, просто замедляем доступ с CDN, где они хранят контент. После чего сам сайт работает быстро, а видео тормозит и фоточки плохо грузятся.
Виноват в этом будет провайдер, сам сайт, фазы луны, сосед Петрович и т.д. и т.п.
А если еще замедлить трафик к точкам входа публичных VPN, то вообще все будет просто замечательно. Вроде бы и работает, а толку?
На этой неделе несколько раз получал жалобы от заказчиков по поводу плохой работы интернета, общие симптомы – низкая скорость доступа к отдельным сайтам, невозможность получить тяжелое содержимое, лаги при просмотре мультимедиа.
Сайты были преимущественно зарубежные, но и не только. И какой-то единой взаимосвязи не просматривалось, тем более что сайт мог грузиться быстро, а отдельные его элементы медленно или не загружались вообще.
Сами мы столкнулись с такой ситуацией попытавшись скачать клиент Seafile с официального сайта, скорость оказалась сильно медленной 54 КБ/с (что видно на рисунке ниже), при этом на VPS от Oracle этот же самый файл скачался на полной скорости.
В результате проведенных экспериментов стало ясно, что замедляется доступ к ряду крупных хостингов и CDN, например, таких, как amazonaws.
С чьей стороны происходит данное замедление – непонятно, но факт имеет место быть. Пока работает решение с обходом через VPN, лучше всего при этом использовать приватный сервер.
В связи с этим появился ряд размышлений. Замедление, в отличие от блокировок, гораздо более мягкий, но в то же время более эффективный способ блокирования доступа к нежелательным ресурсам.
Блокировка – это достаточно неэффективный метод, он прост и туп, как сибирский валенок. И одно дело, когда блокируется всякая грязь, неинтересная ширнармассам и совсем другое, когда под раздачу попадают ресурсы с развлекательным контентом.
За минувшие годы слово VPN выучили даже бабушки у подъезда, причем не только выучили, но и освоили его использование.
Блокировать VPN-сервисы – тоже такой себе вариант, на смену одним придут другие, бегай, гоняйся за ними.
А вот замедление куда интереснее, так как большинство пользователей просто не поймет в чем тут дело. Особенно если сделать все по уму.
Не нужно блокировать сам Yotube или еще какую соцсеть, даже не нужно замедлять сам основной сайт, просто замедляем доступ с CDN, где они хранят контент. После чего сам сайт работает быстро, а видео тормозит и фоточки плохо грузятся.
Виноват в этом будет провайдер, сам сайт, фазы луны, сосед Петрович и т.д. и т.п.
А если еще замедлить трафик к точкам входа публичных VPN, то вообще все будет просто замечательно. Вроде бы и работает, а толку?
👍20😢8😁2🤬1
Замечали ли вы последнее время замедление интернета?
Anonymous Poll
35%
Да
18%
Скорее да
11%
Возможно
14%
Скорее нет
15%
Нет
3%
У меня такой интернтет, что замедлять не надо
5%
Ничего не понятно, но очень интересно
👍2😁1
WinGet (Windows Package Manager) - пакетный менеджер для Windows
Пакетный менеджер - хорошо знакомый любому Linux администратору вид ПО, который позволяет централизованно управлять программным обеспечением в системе и легко автоматизировать этот процесс.
Пользователи Windows долгое время были лишены подобного инструмента, собственно, как вообще какого-то централизованного подхода к управлению ПО, но затем в Windows появился Магазин, а затем и менеджер пакетов, названный просто - Windows Package Manager или WinGet. В данной статье мы рассмотрим его особенности и примеры работы с ним.
https://interface31.ru/tech_it/2023/09/winget---paketnyy-menedzher-dlya-windows.html
Пакетный менеджер - хорошо знакомый любому Linux администратору вид ПО, который позволяет централизованно управлять программным обеспечением в системе и легко автоматизировать этот процесс.
Пользователи Windows долгое время были лишены подобного инструмента, собственно, как вообще какого-то централизованного подхода к управлению ПО, но затем в Windows появился Магазин, а затем и менеджер пакетов, названный просто - Windows Package Manager или WinGet. В данной статье мы рассмотрим его особенности и примеры работы с ним.
https://interface31.ru/tech_it/2023/09/winget---paketnyy-menedzher-dlya-windows.html
👍25🔥2
Ноутбук вместо монитора. Возможно? Да.
Современный уровень развития железа и средств виртуализации привел к тому, что у многих, даже очень небольших предприятий, появляется «сервер».
Хотя почему «сервер», ведь это и на самом деле сервер, хоть и собран он обычно из обычного железа, но задачи выполняет вполне серверные, причем выполняет вполне успешно.
Только одна беда, никакой сопутствующей серверной инфраструктуры там нет и никогда не появится, это я про KVM-переключатели, IP-KVM, iLO и прочие радости жизни. Хорошо если старый монитор рядом поставят и клавиатуру с мышью.
Чаще всего и этого нет, но подразумевается, что в случае чего все это можно будет позаимствовать с какого-нибудь рабочего места.
Только вот это «позаимствовать» на практике выливается сначала в попытках найти это самое рабочее место, где можно временно прервать рабочий процесс.
Затем отключить оборудование и распутать заросшие пылью провода где-то глубоко в столе, куда они засунуты весьма хитрым путем и внатяг. А потом повторить весь этот процесс обратно, постаравшись попутно ничего более не выдернуть.
Поэтому встал вопрос поиска доступной альтернативы и если с клавиатурой и мышью проблем нет, в продаже есть много компактных моделей, включая «все в одном», где клавиатура сочетается с тачпадом, то вот с монитором все сложнее.
При том, что подавляющее большинство современных ПК имеют цифровые видеовыходы, чаще всего HDMI, поэтому мы решили попробовать один недорогой и доступный вариант - карту видеозахвата HDMI – USB, цена вопроса такой железки сегодня около 1000 рублей.
На ПК она определяется как стандартная камера и с ней можно работать при помощи любого ПО умеющего работать с данным типом устройств, можно даже использовать стандартное приложение Камера.
Мы попробовали и у нас все получилось. В приложении Камера сразу же отобразилась картинка с видеовыхода ПК, начиная от самой загрузки и экрана BIOS (показана на врезке).
Работать в таком режиме вполне удобно, особенно учитывая, что никаких сверхзадач там решать не нужно. Чаще всего это доступ в BIOS и решение проблем при загрузке. Все остальное решается уже удаленно, причем прямо с этого же ноутбука.
Так что берите метод на заметку.
Современный уровень развития железа и средств виртуализации привел к тому, что у многих, даже очень небольших предприятий, появляется «сервер».
Хотя почему «сервер», ведь это и на самом деле сервер, хоть и собран он обычно из обычного железа, но задачи выполняет вполне серверные, причем выполняет вполне успешно.
Только одна беда, никакой сопутствующей серверной инфраструктуры там нет и никогда не появится, это я про KVM-переключатели, IP-KVM, iLO и прочие радости жизни. Хорошо если старый монитор рядом поставят и клавиатуру с мышью.
Чаще всего и этого нет, но подразумевается, что в случае чего все это можно будет позаимствовать с какого-нибудь рабочего места.
Только вот это «позаимствовать» на практике выливается сначала в попытках найти это самое рабочее место, где можно временно прервать рабочий процесс.
Затем отключить оборудование и распутать заросшие пылью провода где-то глубоко в столе, куда они засунуты весьма хитрым путем и внатяг. А потом повторить весь этот процесс обратно, постаравшись попутно ничего более не выдернуть.
Поэтому встал вопрос поиска доступной альтернативы и если с клавиатурой и мышью проблем нет, в продаже есть много компактных моделей, включая «все в одном», где клавиатура сочетается с тачпадом, то вот с монитором все сложнее.
При том, что подавляющее большинство современных ПК имеют цифровые видеовыходы, чаще всего HDMI, поэтому мы решили попробовать один недорогой и доступный вариант - карту видеозахвата HDMI – USB, цена вопроса такой железки сегодня около 1000 рублей.
На ПК она определяется как стандартная камера и с ней можно работать при помощи любого ПО умеющего работать с данным типом устройств, можно даже использовать стандартное приложение Камера.
Мы попробовали и у нас все получилось. В приложении Камера сразу же отобразилась картинка с видеовыхода ПК, начиная от самой загрузки и экрана BIOS (показана на врезке).
Работать в таком режиме вполне удобно, особенно учитывая, что никаких сверхзадач там решать не нужно. Чаще всего это доступ в BIOS и решение проблем при загрузке. Все остальное решается уже удаленно, причем прямо с этого же ноутбука.
Так что берите метод на заметку.
👍40🔥10❤2
Как правильно выбрать ИБП
Сегодня столкнулись с тем, что не все наши коллеги умеют правильно выбрать ИБП и рассчитать приблизительное время работы оборудования.
Большинство, выбирая ИБП, исходят из его мощности, полагая что чем больше мощность, тем дольше будет держать ИБП. Что абсолютно неверно.
Почему? Начнем с того, что такое мощность. Мощность это способность электрического тока выполнить определенную работу. Потребляемая (активная) мощность электроприборов выражается в Ваттах (Вт, W).
При этом в сетях переменного тока реальная потребляемая мощность может быть выше активной мощности устройства, так как существует еще и реактивная емкость, связанная с емкостной и индуктивной составляющей устройства.
Поэтому в таких случаях принято говорить о полной мощности, которая измеряется в Вольт-Амперах (ВА, VA) и именно ее указывают для ИБП.
Чтобы правильно рассчитать полную мощность нам нужно знать коэффициент фазового сдвига, вносимый устройством, а это сделать довольно непросто. Поэтому упростим себе задачу и будем считать, что полная мощность компьютера или периферийного устройства больше активной мощности в 1,4 раза.
Мощность ИБП показывает предельную мощность подключенных устройств и не более того. Грубо говоря, к ИБП на 650 ВА мы можем подключить только два условных ПК, а к ИБП на 850 ВА – уже три.
Превышение мощности приведет к перегрузке ИБП и отключению нагрузки.
А что же у нас со временем? А время у нас напрямую зависит от двух параметров: емкости батареи, которую измеряют в Ампер-часах (А-ч, Ah) и током потребления нагрузки (читай – мощностью).
Вычислить время можно по приблизительной формуле:
Если мы возьмем две реальные модели ИБП:
▫️ DEXP CEE-E 650VA – 3299 руб.
▫️ DEXP CEE-E 850VA – 4099 руб.
То может показаться, что приобретение второй модели для нашего условного ПК предпочтительнее, как-никак на целых 200 ВА больше.
Но оба ИБП имеют в составе единственную батарею 12 В, 7 А-ч, это стандартная батарея, все их знают. Теперь считаем:
Но это идеальная цифра, в реальности добавим сюда КПД инвертора и потерю емкости батареями, поэтому полученную цифру следует уменьшить примерно на 25-30%.
Это будет примерно объективной оценкой времени на которое вы можете рассчитывать.
При этом, обратите внимание, более мощный бесперебойник обеспечивает меньшее время работы чем менее мощный, но обеспечивает более высокий ток для нагрузки.
Кому-то это может показаться парадоксальным, но это факт: при использовании одного и того же набора аккумуляторных батарей с увеличением мощности ИБП время работы в автономном режиме будет падать.
И тем более нет смысла в покупке более мощного ИБП если ваша нагрузка позволяет купить менее мощный, время работы от этого не увеличится, а вы просто выбросите деньги на ветер.
Сегодня столкнулись с тем, что не все наши коллеги умеют правильно выбрать ИБП и рассчитать приблизительное время работы оборудования.
Большинство, выбирая ИБП, исходят из его мощности, полагая что чем больше мощность, тем дольше будет держать ИБП. Что абсолютно неверно.
Почему? Начнем с того, что такое мощность. Мощность это способность электрического тока выполнить определенную работу. Потребляемая (активная) мощность электроприборов выражается в Ваттах (Вт, W).
При этом в сетях переменного тока реальная потребляемая мощность может быть выше активной мощности устройства, так как существует еще и реактивная емкость, связанная с емкостной и индуктивной составляющей устройства.
Поэтому в таких случаях принято говорить о полной мощности, которая измеряется в Вольт-Амперах (ВА, VA) и именно ее указывают для ИБП.
Чтобы правильно рассчитать полную мощность нам нужно знать коэффициент фазового сдвига, вносимый устройством, а это сделать довольно непросто. Поэтому упростим себе задачу и будем считать, что полная мощность компьютера или периферийного устройства больше активной мощности в 1,4 раза.
S = 1,4 * P
Таким образом, если средний офисный ПК потребляет 200 Вт активной мощности, то полную мощность такого устройства следует принять за 280 ВА.Мощность ИБП показывает предельную мощность подключенных устройств и не более того. Грубо говоря, к ИБП на 650 ВА мы можем подключить только два условных ПК, а к ИБП на 850 ВА – уже три.
Превышение мощности приведет к перегрузке ИБП и отключению нагрузки.
А что же у нас со временем? А время у нас напрямую зависит от двух параметров: емкости батареи, которую измеряют в Ампер-часах (А-ч, Ah) и током потребления нагрузки (читай – мощностью).
Вычислить время можно по приблизительной формуле:
t = E * U / S
Где E – емкость АКБ, U – напряжение батареи АКБ, S – полная мощность нагрузки. Результат получим в часах.Если мы возьмем две реальные модели ИБП:
▫️ DEXP CEE-E 650VA – 3299 руб.
▫️ DEXP CEE-E 850VA – 4099 руб.
То может показаться, что приобретение второй модели для нашего условного ПК предпочтительнее, как-никак на целых 200 ВА больше.
Но оба ИБП имеют в составе единственную батарею 12 В, 7 А-ч, это стандартная батарея, все их знают. Теперь считаем:
t = 7 * 12 / 280 = 18 минут
Если нагрузить оба этих ИБП почти по полной, т.е. подключить к первому два условных ПК, а ко второму три, то время работы от батареи составит 9 и 6 минут соответственно.Но это идеальная цифра, в реальности добавим сюда КПД инвертора и потерю емкости батареями, поэтому полученную цифру следует уменьшить примерно на 25-30%.
Это будет примерно объективной оценкой времени на которое вы можете рассчитывать.
При этом, обратите внимание, более мощный бесперебойник обеспечивает меньшее время работы чем менее мощный, но обеспечивает более высокий ток для нагрузки.
Кому-то это может показаться парадоксальным, но это факт: при использовании одного и того же набора аккумуляторных батарей с увеличением мощности ИБП время работы в автономном режиме будет падать.
И тем более нет смысла в покупке более мощного ИБП если ваша нагрузка позволяет купить менее мощный, время работы от этого не увеличится, а вы просто выбросите деньги на ветер.
👍53❤2🤝2🫡1
Похоже, халява закончилась… Точно закончилась...
Сегодня нужно было быстро поднять в тестовых целях сервер 1С на Linux. Все знают, что технически платформа давала запустить до 12 сеансов без серверного ключа. Чего для целей разработки и тестирования хватало за глаза.
И вот сегодня платформа
Хм, откатились на
Проверили на последней
Похоже, после выпуска бесплатной community-лицензии фирма 1С решила закрутить гайки. Такое решение в целом понятно, потому что мы не раз видели такие сервера в продакшене, если у заказчика было менее 12 рабочих мест на 1 базу.
Но осталась одна нерешаемая проблема: community-лицензию на Linux можно получить только интерактивно, т.е. только через клиентское приложение на сервере, что доставляет массу неудобств если это виртуалка или контейнер.
Поэтому хотелось бы все-таки пока сохранить эту возможность, хотя бы даже и с ограничением в 1 сеанс, ну или довести до ума получение community-лицензии и снять или уменьшить ограничение на повторное получение лицензии не ранее чем через 7 дней.
А вы сталкивались с подобным поведением?
Дополнение. Коллеги прислали ссылку на список изменений в 8.3.22.2239
Было: Кластер серверов под управлением ОС Linux позволял запускать до 12 клиентских сеансов без лицензии на сервер, если кластер серверов состоял из одного рабочего сервера с одним рабочим процессом.
Стало: Использование кластера серверов при работе под управлением ОС Linux всегда требует серверную лицензию, аналогично поведению под управлением ОС Windows.
Результат: Устранена возможность нелицензионного использования кластера серверов под управлением ОС Linux. Устранено неожиданное прекращение работы системы из-за отсутствия лицензии на кластер серверов «1С:Предприятия».
Источник: https://dl03.1c.ru/content/Platform/8_3_22_2239/1cv8upd_8_3_22_2239.htm#0c308d15-2bbc-11ee-963f-0050569f678a
Сегодня нужно было быстро поднять в тестовых целях сервер 1С на Linux. Все знают, что технически платформа давала запустить до 12 сеансов без серверного ключа. Чего для целей разработки и тестирования хватало за глаза.
И вот сегодня платформа
8.3.22.2208 с датой выпуска 14.08.23 неожиданно потребовала серверный ключ. Хм, откатились на
8.3.22.1709 от 16.11.22 полет нормальный. Поскребли по сусекам, нашли тестовую виртуалку с 8.3.23.1688 от 27.04.23 – работает, хотя сам релиз косячный. Проверили на последней
8.3.23.1912 от 03.10.23 – снова требует лицензию. Похоже, после выпуска бесплатной community-лицензии фирма 1С решила закрутить гайки. Такое решение в целом понятно, потому что мы не раз видели такие сервера в продакшене, если у заказчика было менее 12 рабочих мест на 1 базу.
Но осталась одна нерешаемая проблема: community-лицензию на Linux можно получить только интерактивно, т.е. только через клиентское приложение на сервере, что доставляет массу неудобств если это виртуалка или контейнер.
Поэтому хотелось бы все-таки пока сохранить эту возможность, хотя бы даже и с ограничением в 1 сеанс, ну или довести до ума получение community-лицензии и снять или уменьшить ограничение на повторное получение лицензии не ранее чем через 7 дней.
А вы сталкивались с подобным поведением?
Дополнение. Коллеги прислали ссылку на список изменений в 8.3.22.2239
Было: Кластер серверов под управлением ОС Linux позволял запускать до 12 клиентских сеансов без лицензии на сервер, если кластер серверов состоял из одного рабочего сервера с одним рабочим процессом.
Стало: Использование кластера серверов при работе под управлением ОС Linux всегда требует серверную лицензию, аналогично поведению под управлением ОС Windows.
Результат: Устранена возможность нелицензионного использования кластера серверов под управлением ОС Linux. Устранено неожиданное прекращение работы системы из-за отсутствия лицензии на кластер серверов «1С:Предприятия».
Источник: https://dl03.1c.ru/content/Platform/8_3_22_2239/1cv8upd_8_3_22_2239.htm#0c308d15-2bbc-11ee-963f-0050569f678a
😱15👍9🤬4👎1
Как правильно редактировать юниты systemd
Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.
Действительно, сравните сложность написания init-файла и юнита. 🤷🏻♀️
И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.
Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:
▫️
▫️
▫️
Директория
Вроде бы просто, да не совсем. При обновлении пакета юнит в
Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит.
К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.
Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям.
Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in.
Скажем, нам нужно внести изменения в работу юнита
Проще всего это сделать с помощью команды:
Если вы добавите:
Еще одним достоинством команды
Откатить изменения можно командой
Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.
Сегодня 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 файле проще, чем восстановить исходное состояние конфигурации службы.
👍57🔥6❤1
Вот такая "поддержка" у провайдера Wifire (читай Мегафон).
Наружу замедленно все что можно и что нельзя. Под раздачу попали Github, ресурсы MS, репозитории Proxmox и практически все, что выходит из зоны RU.
Включая наших, отечественных разработчиков, но с сайтом в зоне COM.
У того же МТС или Ростелекома таких проблем нет.
В общем, с Wifire мы были долго, более 10 лет, но пришло время менять провайдера.
Наружу замедленно все что можно и что нельзя. Под раздачу попали Github, ресурсы MS, репозитории Proxmox и практически все, что выходит из зоны RU.
Включая наших, отечественных разработчиков, но с сайтом в зоне COM.
У того же МТС или Ростелекома таких проблем нет.
В общем, с Wifire мы были долго, более 10 лет, но пришло время менять провайдера.
🤡21👍15😁1
Производительность виртуальных машин и контейнеров Proxmox
Вопрос накладных расходов на виртуализацию волнует многих, поэтому, как только появилась такая возможность мы выполнили сравнительное тестирование для виртуальных машин и контейнеров Proxmox.
Мы прогнали несколько различных тестовых пакетов, но так как результат везде получился идентичный, то мы оставили в основном результаты от Nench и добавили тесты памяти из Sysbench.
Формат заметки в телеграм не располагает к многословности. поэтому приступим. Начнем с теста процессора, в настоящий момент в Proxmox 8 для KVM добавили новый тип процессора по умолчанию - x86-64-v2-AES, который выбирается теперь вместо kvm64, мы протестировали их оба.
Контейнер обращается сразу к процессору хоста, в каждом из тестов показано как именно определяется процессор в системе.
Память, результат говорит сам за себя:
Теперь самое интересное, диск. Но никаких неожиданностей там не возникло. Контейнер видит диск как физический диск хоста и работает с ним на той же скорости, виртуальная машина в зависимости от типа виртуального диска.
Однако применение современных накопителей NVMe по большому счету нивелирует эту разницу и для большинства задач производительности дисков будет достаточно.
При этом не забываем, что в процессе теста вируталка или контейнер имеют монопольный доступ к ресурсам хоста, тогда как в реальности за них будет конкуренция. Поэтому вряд ли производительность того или иного типа виртуального диска станет узким местом.
Отдельно хотелось бы сказать о параметрах кеширования, включив тот же Write Back (unsafe) мы можем получить очень высокие скорости записи, в несколько раз превышающие скорости хоста, так как в этом случае реальная запись ведется в оперативную память.
Подробнее о типах кеширования можно почитать здесь.
В целом результат был ожидаем и не принес ничего нового. Производительность контейнеров практически равна производительности хоста.
Производительность виртуальных машин близка к ней, но есть отдельные нюансы в виде типа виртуального процессора и типа виртуального диска. Но в целом говорить о каких-то серьезных накладных расходах не приходится.
Вопрос накладных расходов на виртуализацию волнует многих, поэтому, как только появилась такая возможность мы выполнили сравнительное тестирование для виртуальных машин и контейнеров Proxmox.
Мы прогнали несколько различных тестовых пакетов, но так как результат везде получился идентичный, то мы оставили в основном результаты от Nench и добавили тесты памяти из Sysbench.
Формат заметки в телеграм не располагает к многословности. поэтому приступим. Начнем с теста процессора, в настоящий момент в Proxmox 8 для KVM добавили новый тип процессора по умолчанию - x86-64-v2-AES, который выбирается теперь вместо kvm64, мы протестировали их оба.
Контейнер обращается сразу к процессору хоста, в каждом из тестов показано как именно определяется процессор в системе.
HostКак видим, все варианты, кроме kvm64 ничем не отличаются от работы хостового процессора, у kvm64 сильное проседание по AES, где-то в три раза. Поэтому, если вы используете именно виртуальные машины можем посоветовать переходить на Proxmox 8 и новый тип виртуального процессора.
AMD Ryzen 3 PRO 4350G
CPU: SHA256-hashing 500 MB
1.809 seconds
CPU: AES-encrypting 500 MB
0.668 seconds
KVM
QEMU Virtual CPU version 2.5+
(x86-64-v2-AES)
CPU: SHA256-hashing 500 MB
1,812 seconds
CPU: AES-encrypting 500 MB
0,705 seconds
Common KVM processor
(kvm64)
CPU: SHA256-hashing 500 MB
1.843 seconds
CPU: AES-encrypting 500 MB
2.070 seconds
CT
AMD Ryzen 3 PRO 4350G
CPU: SHA256-hashing 500 MB
1.853 seconds
CPU: AES-encrypting 500 MB
0.681 seconds
Память, результат говорит сам за себя:
Mem 7260.77 MiB/secКонтейнер работает с памятью на уровне хоста, виртуальная машина примерно на 5% медленнее, что практически на уровне погрешности измерений.
KVM
Mem 6951.16 MiB/sec
CT
Mem 7133.17 MiB/sec
Теперь самое интересное, диск. Но никаких неожиданностей там не возникло. Контейнер видит диск как физический диск хоста и работает с ним на той же скорости, виртуальная машина в зависимости от типа виртуального диска.
HostСамый быстрый из форматов диска Qcow2, работает практически на скорости хоста, чуть медленнее RAW – примерно на 8%, а вот LVM еще более медленный, отставание составляет уже около 20%.
dd: sequential write speed
1st run: 1621.25 MiB/s
2nd run: 1907.35 MiB/s
3rd run: 1811.98 MiB/s
average: 1780.19 MiB/s
LVM
dd: sequential write speed
1st run: 1239.78 MiB/s
2nd run: 1525.88 MiB/s
3rd run: 1525.88 MiB/s
average: 1430.51 MiB/s
Qcow2
dd: sequential write speed
1st run: 1430.51 MiB/s
2nd run: 1907.35 MiB/s
3rd run: 1811.98 MiB/s
average: 1716.61 MiB/s
RAW
dd: sequential write speed
1st run: 1430.51 MiB/s
2nd run: 1811.98 MiB/s
3rd run: 1716.61 MiB/s
average: 1653.04 MiB/s
Однако применение современных накопителей NVMe по большому счету нивелирует эту разницу и для большинства задач производительности дисков будет достаточно.
При этом не забываем, что в процессе теста вируталка или контейнер имеют монопольный доступ к ресурсам хоста, тогда как в реальности за них будет конкуренция. Поэтому вряд ли производительность того или иного типа виртуального диска станет узким местом.
Отдельно хотелось бы сказать о параметрах кеширования, включив тот же Write Back (unsafe) мы можем получить очень высокие скорости записи, в несколько раз превышающие скорости хоста, так как в этом случае реальная запись ведется в оперативную память.
Подробнее о типах кеширования можно почитать здесь.
В целом результат был ожидаем и не принес ничего нового. Производительность контейнеров практически равна производительности хоста.
Производительность виртуальных машин близка к ней, но есть отдельные нюансы в виде типа виртуального процессора и типа виртуального диска. Но в целом говорить о каких-то серьезных накладных расходах не приходится.
👍58🤮4👎2❤1
Маркировка шагает по стране – новые печали для ИП
Получили сегодня рассылку по маркировке пива и слабоалкогольной продукции, продаваемой в розлив. Сейчас идет подготовка к маркировке кег с такой продукцией. В целом – процесс давно ожидаемый, со своими подводными камнями и сложностями.
Но в документе есть одна веселая приписка, а именно последний абзац, который требует от предпринимателя, чтобы каждое из мест осуществления деятельности было зарегистрировано в ЕГАИС.
Что это значит? Сейчас многие ИП работают с одним единственным УТМ, к которому подключен единственный токен с подписью и зарегистрирован он либо на один из адресов, либо вообще на домашний адрес ИП.
Возможность регистрировать каждое место деятельности есть, но закон позволяет ИП работать с единственным УТМ.
Теперь на каждое место деятельности понадобится свой УТМ и своя подпись. А это автоматически влечет выпуск подписей на физлиц + МЧД. Работа с МЧД реализована в УТМ начиная с 2562 и в целом работает, но сама стабильность работы этой системы еще далека от идеала.
О злоключениях можно почитать на Инфостарте: https://forum.infostart.ru/forum81/topic302955
А сам бизнес получает новую порцию проблем. Начиная с того, что сама идея читать марки на кегах сопряжена со сложностью передачи этой марки в учетную систему. В кеге 30 или 50 кг, не накатаешься, а самый дешевый вариант – беспроводной сканер ШК – от 10 тыс. руб.
Сейчас к этому добавляется покупка токена, выпуск подписи и необходимость размещать где-то нужное количество УТМ. В общем – будет весело, ну и мы без работы не останемся.
А пока наша статья по ЕГАИС в Linux: https://interface31.ru/tech_it/2021/06/egais-ustanavlivaem-utm-420-na-debian-ubuntu.html
Статья актуальна и постоянно пополняется. Сейчас в ней не только то, как установить УТМ, но и как решить некоторые проблемы с памятью и пересобрать пакет со своими настройками, что актуально если УТМ у вас много.
Получили сегодня рассылку по маркировке пива и слабоалкогольной продукции, продаваемой в розлив. Сейчас идет подготовка к маркировке кег с такой продукцией. В целом – процесс давно ожидаемый, со своими подводными камнями и сложностями.
Но в документе есть одна веселая приписка, а именно последний абзац, который требует от предпринимателя, чтобы каждое из мест осуществления деятельности было зарегистрировано в ЕГАИС.
Что это значит? Сейчас многие ИП работают с одним единственным УТМ, к которому подключен единственный токен с подписью и зарегистрирован он либо на один из адресов, либо вообще на домашний адрес ИП.
Возможность регистрировать каждое место деятельности есть, но закон позволяет ИП работать с единственным УТМ.
Теперь на каждое место деятельности понадобится свой УТМ и своя подпись. А это автоматически влечет выпуск подписей на физлиц + МЧД. Работа с МЧД реализована в УТМ начиная с 2562 и в целом работает, но сама стабильность работы этой системы еще далека от идеала.
О злоключениях можно почитать на Инфостарте: https://forum.infostart.ru/forum81/topic302955
А сам бизнес получает новую порцию проблем. Начиная с того, что сама идея читать марки на кегах сопряжена со сложностью передачи этой марки в учетную систему. В кеге 30 или 50 кг, не накатаешься, а самый дешевый вариант – беспроводной сканер ШК – от 10 тыс. руб.
Сейчас к этому добавляется покупка токена, выпуск подписи и необходимость размещать где-то нужное количество УТМ. В общем – будет весело, ну и мы без работы не останемся.
А пока наша статья по ЕГАИС в Linux: https://interface31.ru/tech_it/2021/06/egais-ustanavlivaem-utm-420-na-debian-ubuntu.html
Статья актуальна и постоянно пополняется. Сейчас в ней не только то, как установить УТМ, но и как решить некоторые проблемы с памятью и пересобрать пакет со своими настройками, что актуально если УТМ у вас много.
👍24
А и Б сидели на трубе
Сегодня пятница и хочу рассказать один забавный случай, и поучительный.
Позвонил мне третьего дня хороший друг и товарищ, мол купил я на дом еще одну камеру, настрой ее и подключи к серверу видеонаблюдения.
Да фигня вопрос. Друг – адвокат и всегда выручает меня советом, когда надо, поэтому такую услугу окажу с удовольствием.
Подключаюсь к его ПК через TeamViewer, запускаю SADP – это такая удобная утилита от Hikvision, которая видит камеры по MAC и позволяет цепляться к ним, менять сетевые настройки, ставить пароль и все такое прочее лишний раз не вставая с дивана.
В общем ставлю на камеру стандартный пароль и иду в веб-интерфейс настроить потоки, часовой пояс и все такое прочее. И с удивлением вижу, что неправильный логин/пароль.
Ну как-так, я же стандартный ставил. Ну а вот так, неверно и все!
Ладно, звоню другу, он берет стремянку, лезет, сбрасывает камеру кнопкой.
Все повторяется, снова неверный логин и пароль. Снова стремянка и сброс кнопкой.
Понимаем, что какая-то фигня. Открываем Блокнот, набираем пароль, но в SADP копирование пароля не работает, только ручками.
Поэтому решаем настроить контрольный вопрос, чтобы можно было сбросить пароль, не прибегая к сбросу камеры.
И тут вот наблюдаем изумительную картину: в SADP если была нажата клавиша А, то какую бы вы клавишу не нажали – следующая снова будет А.
Причем такой фокус проявляется только через удаленное подключение, локально все нормально. Отключились и снова подключили TeamViewer – снова стало все нормально.
Поэтому во всех подобных непонятных ситуациях всегда следует проверять в любом свободном поле приложения как именно набираются символы, потому что средства удаленного доступа иногда преподносят такие вот фокусы.
Сегодня пятница и хочу рассказать один забавный случай, и поучительный.
Позвонил мне третьего дня хороший друг и товарищ, мол купил я на дом еще одну камеру, настрой ее и подключи к серверу видеонаблюдения.
Да фигня вопрос. Друг – адвокат и всегда выручает меня советом, когда надо, поэтому такую услугу окажу с удовольствием.
Подключаюсь к его ПК через TeamViewer, запускаю SADP – это такая удобная утилита от Hikvision, которая видит камеры по MAC и позволяет цепляться к ним, менять сетевые настройки, ставить пароль и все такое прочее лишний раз не вставая с дивана.
В общем ставлю на камеру стандартный пароль и иду в веб-интерфейс настроить потоки, часовой пояс и все такое прочее. И с удивлением вижу, что неправильный логин/пароль.
Ну как-так, я же стандартный ставил. Ну а вот так, неверно и все!
Ладно, звоню другу, он берет стремянку, лезет, сбрасывает камеру кнопкой.
Все повторяется, снова неверный логин и пароль. Снова стремянка и сброс кнопкой.
Понимаем, что какая-то фигня. Открываем Блокнот, набираем пароль, но в SADP копирование пароля не работает, только ручками.
Поэтому решаем настроить контрольный вопрос, чтобы можно было сбросить пароль, не прибегая к сбросу камеры.
И тут вот наблюдаем изумительную картину: в SADP если была нажата клавиша А, то какую бы вы клавишу не нажали – следующая снова будет А.
Причем такой фокус проявляется только через удаленное подключение, локально все нормально. Отключились и снова подключили TeamViewer – снова стало все нормально.
Поэтому во всех подобных непонятных ситуациях всегда следует проверять в любом свободном поле приложения как именно набираются символы, потому что средства удаленного доступа иногда преподносят такие вот фокусы.
👍78
VPN и сетевое окружение
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
👍69❤8🔥8
Резервные копии Active Direcitory
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
👍33
Сталкивались ли вы в своей практике с USN Rollback?
Anonymous Poll
13%
Да
55%
Нет
33%
Ничего не понятно, но очень интересно