Проблема медленного клиента в Wi-Fi сетях
Многие читатели высказывают скептическое отношение к современным стандартам Wi-Fi, мол все это ни к чему, когда есть старый-добрый 802.11n, да и 2,4 ГГц добивает дальше. Но не все так просто и в этой заметке постараемся коротко рассказать об этом.
Начнем с того, что канал Wi-Fi – это разделяемая среда и пропускная способность канала делится поровну между всеми ее участниками.
Стандарт предусматривает разделение эфирного времени на слоты по количеству переданных устройством пакетов, что гарантирует каждому клиенту возможность передать или принять определенный объем данных.
Идем дальше. Ширина канала также является фиксированной и объем данных, которые мы можем по нему передать за единицу времени зависит от используемого метода модуляции (изменения электромагнитной волны таким образом, чтобы закодировать в ней данные).
Чем более сложную модуляцию мы используем – тем выше скорость передачи данных, но тем ниже помехоустойчивость такого сигнала.
Для примера возьмем квадрат определенного размера и разметим его сеткой 2х2 – получим 4 ячейки, если же возьмем сетку 4х4 – то ячеек уже будет 16, а при размере сетки 8х8 целых 64. Исходный квадрат у нас будет обозначать доступную полосу, а сетка – модуляцию.
А теперь давайте будем удалять наши квадраты на некоторое расстояние от наблюдателя, первым потеряет читабельность сетка 8х8, затем 4х4 и т.д.
Точно также и в беспроводных сетях. Чем ниже уровень сигнала и/или выше уровень помех, тем более простой метод модуляции будет использоваться.
Все стандарты до 802.11n (Wi-Fi 4) включительно предусматривают работу по принципу «один говорит – остальные молчат», т.е. точка одновременно работает только с одним клиентом.
Начиная со стандарта 802.11ac (Wi-Fi 5) предусмотрен режим многопользовательского MIMO, когда точка может передавать данные одновременно сразу нескольким клиентам (но не наоборот).
Такое решение позволило улучшить передачу потокового мультимедиа и улучшить пользовательские характеристики беспроводной сети.
В 802.11ax (Wi-Fi 6) добавили исходящие потоки и теперь точка может не только передавать, но и принимать данные от нескольких клиентов одновременно.
А теперь вернемся к проблеме медленного клиента. Под медленным клиентом может подразумеваться два типа устройств: устройство с устаревшим стандартом и устройство того же стандарта, но со слабым уровнем сигнала.
Начнем с устаревших, эта проблема наиболее характерна для диапазона 2,4 ГГц, даже если точка поддерживает все современные стандарты, например, как в новых Mikrotik 802.11b/g/n/ax (Wi-Fi 6), то в такой сети у нас всегда найдутся устройства 802.11n.
Что это значит? А это значит, что во время работы такого устройства все клиенты 802.11ac/ax будут молчать и точка не будет передавать им данные даже если могла бы это сделать.
В итоге мы теряем все преимущества новых стандартов и фактически опускаемся на уровень производительности сети 802.11n, особенно если старых устройств много.
С медленным клиентом того же стандарта проблема немного иная. В силу плохого уровня приема и низкого соотношения сигнал/шум он будет использовать простые методы модуляции, а следовательно, занимать больше эфирного времени.
При высокой активности такого клиента или большого их количества скорость передачи всей сети будет стремиться к скорости самого медленного устройства.
Т.е. если ваша бабушка слушает музыку с высоким качеством пропалывая грядки на краю участка страдать будет производительность и вашего нового и крутого смартфона в паре метров от точки доступа.
Поэтому самым разумным способом на сегодняшний день является использование двух диапазонов: 5 ГГц и 2,4 ГГц.
В первом будут собраны преимущественно современные устройства и работать будут как минимум на уровне 802.11ac, а все старые устройства сбросим на 2,4 ГГц на 802.11n.
Туда же будут переключаться и все устройства со слабым сигналом, и более низкая дальность 5 ГГц здесь только играет в плюс.
Многие читатели высказывают скептическое отношение к современным стандартам Wi-Fi, мол все это ни к чему, когда есть старый-добрый 802.11n, да и 2,4 ГГц добивает дальше. Но не все так просто и в этой заметке постараемся коротко рассказать об этом.
Начнем с того, что канал Wi-Fi – это разделяемая среда и пропускная способность канала делится поровну между всеми ее участниками.
Стандарт предусматривает разделение эфирного времени на слоты по количеству переданных устройством пакетов, что гарантирует каждому клиенту возможность передать или принять определенный объем данных.
Идем дальше. Ширина канала также является фиксированной и объем данных, которые мы можем по нему передать за единицу времени зависит от используемого метода модуляции (изменения электромагнитной волны таким образом, чтобы закодировать в ней данные).
Чем более сложную модуляцию мы используем – тем выше скорость передачи данных, но тем ниже помехоустойчивость такого сигнала.
Для примера возьмем квадрат определенного размера и разметим его сеткой 2х2 – получим 4 ячейки, если же возьмем сетку 4х4 – то ячеек уже будет 16, а при размере сетки 8х8 целых 64. Исходный квадрат у нас будет обозначать доступную полосу, а сетка – модуляцию.
А теперь давайте будем удалять наши квадраты на некоторое расстояние от наблюдателя, первым потеряет читабельность сетка 8х8, затем 4х4 и т.д.
Точно также и в беспроводных сетях. Чем ниже уровень сигнала и/или выше уровень помех, тем более простой метод модуляции будет использоваться.
Все стандарты до 802.11n (Wi-Fi 4) включительно предусматривают работу по принципу «один говорит – остальные молчат», т.е. точка одновременно работает только с одним клиентом.
Начиная со стандарта 802.11ac (Wi-Fi 5) предусмотрен режим многопользовательского MIMO, когда точка может передавать данные одновременно сразу нескольким клиентам (но не наоборот).
Такое решение позволило улучшить передачу потокового мультимедиа и улучшить пользовательские характеристики беспроводной сети.
В 802.11ax (Wi-Fi 6) добавили исходящие потоки и теперь точка может не только передавать, но и принимать данные от нескольких клиентов одновременно.
А теперь вернемся к проблеме медленного клиента. Под медленным клиентом может подразумеваться два типа устройств: устройство с устаревшим стандартом и устройство того же стандарта, но со слабым уровнем сигнала.
Начнем с устаревших, эта проблема наиболее характерна для диапазона 2,4 ГГц, даже если точка поддерживает все современные стандарты, например, как в новых Mikrotik 802.11b/g/n/ax (Wi-Fi 6), то в такой сети у нас всегда найдутся устройства 802.11n.
Что это значит? А это значит, что во время работы такого устройства все клиенты 802.11ac/ax будут молчать и точка не будет передавать им данные даже если могла бы это сделать.
В итоге мы теряем все преимущества новых стандартов и фактически опускаемся на уровень производительности сети 802.11n, особенно если старых устройств много.
С медленным клиентом того же стандарта проблема немного иная. В силу плохого уровня приема и низкого соотношения сигнал/шум он будет использовать простые методы модуляции, а следовательно, занимать больше эфирного времени.
При высокой активности такого клиента или большого их количества скорость передачи всей сети будет стремиться к скорости самого медленного устройства.
Т.е. если ваша бабушка слушает музыку с высоким качеством пропалывая грядки на краю участка страдать будет производительность и вашего нового и крутого смартфона в паре метров от точки доступа.
Поэтому самым разумным способом на сегодняшний день является использование двух диапазонов: 5 ГГц и 2,4 ГГц.
В первом будут собраны преимущественно современные устройства и работать будут как минимум на уровне 802.11ac, а все старые устройства сбросим на 2,4 ГГц на 802.11n.
Туда же будут переключаться и все устройства со слабым сигналом, и более низкая дальность 5 ГГц здесь только играет в плюс.
👍68❤2
Почему не следует использовать ретрансляторы Wi-Fi
Если не хватает покрытия беспроводной сети, то обычный пользователь идет в магазин и покупает там ретранслятор, он же повторитель, и он же усилитель беспроводного сигнала.
Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.
А подводных камней там хватает. Практически все повторители, а в бюджетном сегменте поголовно все работают на той же частоте что и базовая точка доступа, т.е. занимают один и тот же канал, полоса пропускания которого делится на все беспроводные устройства.
Ширина канала – величина строго ограниченная, как и количество данных, которые мы можем передать за единицу времени. Время доступа к каналу также равномерно делится между всеми подключенными устройствами.
Причем делится оно не по времени, а по количеству переданных пакетов. Т.е. медленный клиент будет занимать больше эфирного времени для передачи одного и того же объема данных.
В идеальном случае, когда все устройства работают с одной и той же скоростью, канал поделится между устройствами примерно равномерно.
Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).
К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.
Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.
При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).
Но, как мы уже сказали выше, страдать будут не только клиенты репитера, но и клиенты основной точки доступа за счет появления в сети паразитного дублирующегося трафика.
Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.
Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).
И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.
До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.
Но если мы начнем подключать к беспроводной сети требовательные устройства, например, телевизоры 2К – 4К, то это очень быстро станет заметно. Особенно если за репитер переместится несколько медленных клиентов, которые начнут отравлять жизнь всем остальным в два раза активнее.
Про цепочки из нескольких повторителей мы и говорить не хотим, фактически это приведет к кратному увеличению дублирующегося трафика и приведет к катастрофическому падению производительности сети.
Если не хватает покрытия беспроводной сети, то обычный пользователь идет в магазин и покупает там ретранслятор, он же повторитель, и он же усилитель беспроводного сигнала.
Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.
А подводных камней там хватает. Практически все повторители, а в бюджетном сегменте поголовно все работают на той же частоте что и базовая точка доступа, т.е. занимают один и тот же канал, полоса пропускания которого делится на все беспроводные устройства.
Ширина канала – величина строго ограниченная, как и количество данных, которые мы можем передать за единицу времени. Время доступа к каналу также равномерно делится между всеми подключенными устройствами.
Причем делится оно не по времени, а по количеству переданных пакетов. Т.е. медленный клиент будет занимать больше эфирного времени для передачи одного и того же объема данных.
В идеальном случае, когда все устройства работают с одной и той же скоростью, канал поделится между устройствами примерно равномерно.
Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).
К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.
Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.
При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).
Но, как мы уже сказали выше, страдать будут не только клиенты репитера, но и клиенты основной точки доступа за счет появления в сети паразитного дублирующегося трафика.
Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.
Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).
И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.
До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.
Но если мы начнем подключать к беспроводной сети требовательные устройства, например, телевизоры 2К – 4К, то это очень быстро станет заметно. Особенно если за репитер переместится несколько медленных клиентов, которые начнут отравлять жизнь всем остальным в два раза активнее.
Про цепочки из нескольких повторителей мы и говорить не хотим, фактически это приведет к кратному увеличению дублирующегося трафика и приведет к катастрофическому падению производительности сети.
👍53❤2🤔1🥱1
Знаю, что многие тут хотят уйти в DevOps. Но не знают где взять информацию и четкий план.
💪 Советую бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет сориентироваться в мире DevOps и стать крутым спецом.
В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования в удобном формате.
✔️А еще он будет полезен при подготовке к собеседованиям.
👉 Кстати, бонусом крутой канал о девопс. Там тоже самые свежие IT-новости, полезные советы от DevOps-инженера с 20-летним стажем, эксклюзивные материалы, релизы топовых инструментов, обзоры вакансий и личный взгляд на девопс-сферу.
📌 Ну а тем, кто хочет двигаться под руководством наставника - индивидуальная программа.
💪 Советую бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет сориентироваться в мире DevOps и стать крутым спецом.
В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования в удобном формате.
✔️А еще он будет полезен при подготовке к собеседованиям.
👉 Кстати, бонусом крутой канал о девопс. Там тоже самые свежие IT-новости, полезные советы от DevOps-инженера с 20-летним стажем, эксклюзивные материалы, релизы топовых инструментов, обзоры вакансий и личный взгляд на девопс-сферу.
📌 Ну а тем, кто хочет двигаться под руководством наставника - индивидуальная программа.
👍4🤣1
И снова вой на болотах
Начнем с новости:
Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.
Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.
Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).
После чего из многих закоулков сети послышался тоскливый вой и гневные вопли насчет попранных прав и свобод, но, как всегда, мало кто разобрался в вопросе, что же именно заблокировала компания Microsoft.
Драйвер, скажет кто-то и на том успокоится, делов то… Но вот здесь начинается самое интересное, потому что драйвер – это единственное доступный пользователю способ добавить исполняемый код на уровне ядра.
В целом имя данного драйвера наглядно об этом говорит - Ring0 – нулевое кольцо защиты – режим, в котором работает ядро ОС.
Ну так есть же и другие драйвера? Есть, но они предназначены исключительно для работы с конкретным оборудованием или даже с конкретными его экземплярами. А WinRing0, по сути, драйвером в прямом смысле этого слова не является, это некая прослойка, которая дает возможность приложению обращаться к произвольному местоположению памяти ядра.
Да, это удобно, когда знаешь, что куда писать и что откуда читать и не хочешь завязываться на высокоуровневые инструменты производителей оборудования или их возможности оказываются недостаточными.
Но это в тоже время огромный риск, так как ошибка выполнения кода на уровне ядра – это крах ОС иначе именуемый BSOD. А самый лучший способ нарушить стабильность системы – это поставить в нее какой-нибудь левый драйвер.
Т.е. уже, даже в легальном сценарии использования мы имеем все шансы ушатать систему из-за ошибки в каком-нибудь стороннем приложении для управления вентиляторами или подсветкой.
Но это еще не все, конструктивной ошибкой данного драйвера было то, что получить к нему доступ могла любая программа в системе, в т.ч. и с низким уровнем целостности (low integrity) т.е. недоверенное приложение. А это уже не просто дыра, это проходной двор.
Проходной потому, что позволяет легко обходить инструменты безопасности системы и получать доступ на уровень ядра даже из «песочницы» куда система помещает приложения с низким уровнем доверия или процесс работающие с документами из ненадежных источников.
Поэтому решение о блокировке такого драйвера – это не ошибка и не произвол, а вполне взвешенное и обоснованное решение. Наоборот, странно что не случилось этого раньше.
А всем любителям всякого нестандартного ПО, в т.ч. и открытого, это лишний повод задуматься – а оно мне надо. И крепко думать каждый раз, когда какое-то приложение предлагает поставить драйвер, особенно если явной необходимости в этом нет.
Начнем с новости:
Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.
Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.
Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).
После чего из многих закоулков сети послышался тоскливый вой и гневные вопли насчет попранных прав и свобод, но, как всегда, мало кто разобрался в вопросе, что же именно заблокировала компания Microsoft.
Драйвер, скажет кто-то и на том успокоится, делов то… Но вот здесь начинается самое интересное, потому что драйвер – это единственное доступный пользователю способ добавить исполняемый код на уровне ядра.
В целом имя данного драйвера наглядно об этом говорит - Ring0 – нулевое кольцо защиты – режим, в котором работает ядро ОС.
Ну так есть же и другие драйвера? Есть, но они предназначены исключительно для работы с конкретным оборудованием или даже с конкретными его экземплярами. А WinRing0, по сути, драйвером в прямом смысле этого слова не является, это некая прослойка, которая дает возможность приложению обращаться к произвольному местоположению памяти ядра.
Да, это удобно, когда знаешь, что куда писать и что откуда читать и не хочешь завязываться на высокоуровневые инструменты производителей оборудования или их возможности оказываются недостаточными.
Но это в тоже время огромный риск, так как ошибка выполнения кода на уровне ядра – это крах ОС иначе именуемый BSOD. А самый лучший способ нарушить стабильность системы – это поставить в нее какой-нибудь левый драйвер.
Т.е. уже, даже в легальном сценарии использования мы имеем все шансы ушатать систему из-за ошибки в каком-нибудь стороннем приложении для управления вентиляторами или подсветкой.
Но это еще не все, конструктивной ошибкой данного драйвера было то, что получить к нему доступ могла любая программа в системе, в т.ч. и с низким уровнем целостности (low integrity) т.е. недоверенное приложение. А это уже не просто дыра, это проходной двор.
Проходной потому, что позволяет легко обходить инструменты безопасности системы и получать доступ на уровень ядра даже из «песочницы» куда система помещает приложения с низким уровнем доверия или процесс работающие с документами из ненадежных источников.
Поэтому решение о блокировке такого драйвера – это не ошибка и не произвол, а вполне взвешенное и обоснованное решение. Наоборот, странно что не случилось этого раньше.
А всем любителям всякого нестандартного ПО, в т.ч. и открытого, это лишний повод задуматься – а оно мне надо. И крепко думать каждый раз, когда какое-то приложение предлагает поставить драйвер, особенно если явной необходимости в этом нет.
👍40💯7🤮2
О радиомостах
В свете материала о нормативном регулировании Wi-Fi неизбежно всплывает вопрос о радиомостах.
Бытуют распространенные заблуждения, что радиомосты можно поднимать над своей территорией, только в диапазоне 2,4 ГГц или только в диапазоне 5 ГГц и много всего такого прочего.
Но увы, радиомосты без регистрации незаконны в любом виде. Абсолютно в любом.
Чтобы понять откуда ноги растут вернемся к Постановлению Правительства РФ от 20.10.2021 N 1800 "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункту 14 приложения Изъятия из перечня радиоэлектронных средств и высокочастотных устройств, подлежащих регистрации.
Этот пункт прямо гласит, что регистрации не требует:
Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосе радиочастот 2400 - 2483,5 МГц, с допустимой мощностью излучения передатчика не более 100 мВт, в том числе встроенное либо входящее в состав других устройств.
Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосах радиочастот 5150 - 5350 МГц и 5650 - 6425 МГц, с допустимой мощностью излучения передатчика не более 200 мВт, в том числе встроенное либо входящее в состав других устройств.
Начнем с формулировки Пользовательское (оконечное) оборудование, для этого заглянем в Федеральный закон от 07.07.2003 N 126-ФЗ "О связи", статья 2, п. 10:
пользовательское оборудование (оконечное оборудование) - технические средства для передачи и (или) приема сигналов электросвязи по линиям связи, подключенные к абонентским линиям и находящиеся в пользовании абонентов или предназначенные для таких целей
Оборудование для радиомоста очевидно пользовательским и оконечным не является, даже с очень большой натяжкой.
Кроме того, п. 14 содержит дополнительную оговорку о малом радиусе действия и ограничивает мощность излучения передатчика.
Таким образом никаких иных оговорок в законе, которые бы предоставляли лазейки нет.
Любой радиомост, который светит за пределы вашего помещения вне закона и требует регистрации.
Понятно, что не все этим занимаются и эксплуатируют такие решения на свой страх и риск. Однако говорить, что все так делают и ничего – это типичная ошибка выжившего.
Если ваш луч ни с кем не пересекается и никому не мешает, то, скорее всего специально искать его никто не будет. Но все может поменяться в любой момент.
В таком случае вас привлекут к ответственности по Статье 13.4. КоАП Нарушение требований к использованию радиочастотного спектра, правил радиообмена или использования радиочастот, несоблюдение норм или параметров радиоизлучения
А именно пункта 2:
Использование без регистрации радиоэлектронного средства и (или) высокочастотного устройства, подлежащих регистрации, -
влечет наложение административного штрафа *на граждан* в размере *от пятисот до одной тысячи рублей* с конфискацией радиоэлектронных средств … или без таковой;
*
на должностных лиц - от одной тысячи до двух тысяч пятисот рублей*;
на лиц, осуществляющих *предпринимательскую деятельность без образования юридического лица, - от одной тысячи до двух тысяч рублей *с конфискацией радиоэлектронных средств … или без таковой;
*на юридических лиц - от десяти тысяч до двадцати тысяч рублей* с конфискацией радиоэлектронных средств … или без таковой.
Отягчающими обстоятельствами считаются:
1) совершение длящегося административного правонарушения, продолжительность которого превышает три месяца;
2) создание в результате совершения административного правонарушения радиопомех радиоэлектронным средствам других пользователей радиочастотным спектром.
А дальше каждый решает сам. С одной стороны штрафы не такие большие, но с другой практически всегда это сопровождается конфискацией оборудования и постановкой нарушителя на карандаш.
В свете материала о нормативном регулировании Wi-Fi неизбежно всплывает вопрос о радиомостах.
Бытуют распространенные заблуждения, что радиомосты можно поднимать над своей территорией, только в диапазоне 2,4 ГГц или только в диапазоне 5 ГГц и много всего такого прочего.
Но увы, радиомосты без регистрации незаконны в любом виде. Абсолютно в любом.
Чтобы понять откуда ноги растут вернемся к Постановлению Правительства РФ от 20.10.2021 N 1800 "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункту 14 приложения Изъятия из перечня радиоэлектронных средств и высокочастотных устройств, подлежащих регистрации.
Этот пункт прямо гласит, что регистрации не требует:
Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосе радиочастот 2400 - 2483,5 МГц, с допустимой мощностью излучения передатчика не более 100 мВт, в том числе встроенное либо входящее в состав других устройств.
Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосах радиочастот 5150 - 5350 МГц и 5650 - 6425 МГц, с допустимой мощностью излучения передатчика не более 200 мВт, в том числе встроенное либо входящее в состав других устройств.
Начнем с формулировки Пользовательское (оконечное) оборудование, для этого заглянем в Федеральный закон от 07.07.2003 N 126-ФЗ "О связи", статья 2, п. 10:
пользовательское оборудование (оконечное оборудование) - технические средства для передачи и (или) приема сигналов электросвязи по линиям связи, подключенные к абонентским линиям и находящиеся в пользовании абонентов или предназначенные для таких целей
Оборудование для радиомоста очевидно пользовательским и оконечным не является, даже с очень большой натяжкой.
Кроме того, п. 14 содержит дополнительную оговорку о малом радиусе действия и ограничивает мощность излучения передатчика.
Таким образом никаких иных оговорок в законе, которые бы предоставляли лазейки нет.
Любой радиомост, который светит за пределы вашего помещения вне закона и требует регистрации.
Понятно, что не все этим занимаются и эксплуатируют такие решения на свой страх и риск. Однако говорить, что все так делают и ничего – это типичная ошибка выжившего.
Если ваш луч ни с кем не пересекается и никому не мешает, то, скорее всего специально искать его никто не будет. Но все может поменяться в любой момент.
В таком случае вас привлекут к ответственности по Статье 13.4. КоАП Нарушение требований к использованию радиочастотного спектра, правил радиообмена или использования радиочастот, несоблюдение норм или параметров радиоизлучения
А именно пункта 2:
Использование без регистрации радиоэлектронного средства и (или) высокочастотного устройства, подлежащих регистрации, -
влечет наложение административного штрафа *на граждан* в размере *от пятисот до одной тысячи рублей* с конфискацией радиоэлектронных средств … или без таковой;
*
на должностных лиц - от одной тысячи до двух тысяч пятисот рублей*;
на лиц, осуществляющих *предпринимательскую деятельность без образования юридического лица, - от одной тысячи до двух тысяч рублей *с конфискацией радиоэлектронных средств … или без таковой;
*на юридических лиц - от десяти тысяч до двадцати тысяч рублей* с конфискацией радиоэлектронных средств … или без таковой.
Отягчающими обстоятельствами считаются:
1) совершение длящегося административного правонарушения, продолжительность которого превышает три месяца;
2) создание в результате совершения административного правонарушения радиопомех радиоэлектронным средствам других пользователей радиочастотным спектром.
А дальше каждый решает сам. С одной стороны штрафы не такие большие, но с другой практически всегда это сопровождается конфискацией оборудования и постановкой нарушителя на карандаш.
👍35
🖥 Дорогие айтишники и им сочувствующие!
ИТ-индустрия переживает период беспрецедентных изменений. Погрузиться в эту тему и разобраться во всех нюансах гос. регулирования поможет этот профессиональный канал.
🎯 Наш подход:
✓ Только полезная информация с щепоткой юмора и капелькой цинизма
✓ Фокус на реальных кейсах и практических решениях
✓ Профессиональный анализ изменений в отрасли
✓ Конкретные рекомендации для бизнеса (CxO)
📊 Что внутри:
• Анализ изменений / трендов и прогнозы через призму реальности
• Практические рекомендации по адаптации к новым условиям
• Разбор полётов ИЦК, ОЦК, ЦК КПСС (да-да, мы знаем, что это такое, и готовы объяснить вам)
• Серьёзные (мемы) темы про ПДН, ЗОКИИ, ГИС-ы (хотя очень хочется просто запостить мемы)
• Пофессиональное сообщество IT-специалистов (ИТ-реалистов), заинтересованных в развитии отрасли.
👉 Присоединяйтесь по ссылке, пока не приняли закон о запрете присоединения по ссылкам ;)
ИТ-индустрия переживает период беспрецедентных изменений. Погрузиться в эту тему и разобраться во всех нюансах гос. регулирования поможет этот профессиональный канал.
🎯 Наш подход:
✓ Только полезная информация с щепоткой юмора и капелькой цинизма
✓ Фокус на реальных кейсах и практических решениях
✓ Профессиональный анализ изменений в отрасли
✓ Конкретные рекомендации для бизнеса (CxO)
📊 Что внутри:
• Анализ изменений / трендов и прогнозы через призму реальности
• Практические рекомендации по адаптации к новым условиям
• Разбор полётов ИЦК, ОЦК, ЦК КПСС (да-да, мы знаем, что это такое, и готовы объяснить вам)
• Серьёзные (мемы) темы про ПДН, ЗОКИИ, ГИС-ы (хотя очень хочется просто запостить мемы)
• Пофессиональное сообщество IT-специалистов (ИТ-реалистов), заинтересованных в развитии отрасли.
👉 Присоединяйтесь по ссылке, пока не приняли закон о запрете присоединения по ссылкам ;)
👍3👎1🤣1
И на старуху бывает проруха
Трой Хант (Troy Hunt), известный деятель в области компьютерной безопасности, автор курсов по защите информации, создатель сервиса проверки скомпрометированных паролей "Have I Been Pwned?" и региональный директор Microsoft, раскрыл сведения об утечке базы пользователей собственного списка рассылки. История показательна тем, что даже признанные специалисты в области компьютерной безопасности могут стать жертвами типового фишинга при определённом стечении обстоятельств.
Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.
Трой не стал умалчивать свою оплошность и подробно разобрал инцидент в своём блоге, а также добавил информацию об утечке на свой сервис haveibeenpwned.com. Трой считает, что он не заподозрил подвоха из-за стечения нескольких факторов. Во время получения письма Трой был в поездке, не адаптировался после смены часовых поясов и был сильно уставшим. Письмо было прочитано именно в тот момент, когда бдительность была подавлена.
Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "[email protected]".
Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=62964
Трой Хант (Troy Hunt), известный деятель в области компьютерной безопасности, автор курсов по защите информации, создатель сервиса проверки скомпрометированных паролей "Have I Been Pwned?" и региональный директор Microsoft, раскрыл сведения об утечке базы пользователей собственного списка рассылки. История показательна тем, что даже признанные специалисты в области компьютерной безопасности могут стать жертвами типового фишинга при определённом стечении обстоятельств.
Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.
Трой не стал умалчивать свою оплошность и подробно разобрал инцидент в своём блоге, а также добавил информацию об утечке на свой сервис haveibeenpwned.com. Трой считает, что он не заподозрил подвоха из-за стечения нескольких факторов. Во время получения письма Трой был в поездке, не адаптировался после смены часовых поясов и был сильно уставшим. Письмо было прочитано именно в тот момент, когда бдительность была подавлена.
Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "[email protected]".
Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.
✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=62964
👍38🔥3😱3🤷♂1👏1
Завершающий слеш в путях Linux
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
Если же мы напишем:
То при отсутствии директории получим ошибку:
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие обратного слеша устраняет неопределенность, потому как в случае с каталогом явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
~/video
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
~/video/
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
mv -f “$file” /new_path/video
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл.Если же мы напишем:
mv -f “$file” /new_path/video/
То при отсутствии директории получим ошибку:
mv: невозможно создать обычный файл ' video/': Это не каталог
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:mv: не удалось получить доступ к ' video /': Это не каталог
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие обратного слеша устраняет неопределенность, потому как в случае с каталогом явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
if ! [ -d /new_path/video/ ]; then
mkdir /new_path/video
fi
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
👍60
С 1 марта родители могут бесплатно записать своих детей 8–17 лет на программу льготного обучения программированию.
Цель программы — познакомить школьников с IT-профессиями, обучить разработке на Python, созданию 3D-игры и мультфильмов. Участники получат именные сертификаты, которые помогут при поступлении в вуз и в будущей карьере.
Онлайн-курс проводит федеральная школа программирования Алгоритмика, лауреат премии «Бренд года в России 2024» и участник проекта Сколково. Занятия ведут преподаватели с опытом работы в IT-компаниях, включая Яндекс, Сбер и Иннополис.
Запись открыта до конца недели. Для участия нужно выбрать направление по возрасту ребенка и оставить заявку на сайте: https://s.algoritmika.org/1kbt5q5?erid=2W5zFFwHqWG
Цель программы — познакомить школьников с IT-профессиями, обучить разработке на Python, созданию 3D-игры и мультфильмов. Участники получат именные сертификаты, которые помогут при поступлении в вуз и в будущей карьере.
Онлайн-курс проводит федеральная школа программирования Алгоритмика, лауреат премии «Бренд года в России 2024» и участник проекта Сколково. Занятия ведут преподаватели с опытом работы в IT-компаниях, включая Яндекс, Сбер и Иннополис.
Запись открыта до конца недели. Для участия нужно выбрать направление по возрасту ребенка и оставить заявку на сайте: https://s.algoritmika.org/1kbt5q5?erid=2W5zFFwHqWG
👎5
Зависимости DEB-пакетов
Слово зависимость знают все, но далеко не все понимают, что именно значит этот термин и часто применяют его неправильно. Поэтому сегодня мы решили разобрать этот вопрос.
Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является
При распаковке файлы извлекаются из пакета и размещаются на указанные места в файловой системе, а настройка обеспечивает выполнение необходимых скриптов и действий, например, создание нужных пользователей и групп, добавление в автозагрузку и т.д. и т.п.
Если в процессе настройки
Но так как разрешение зависимостей дело непростое, то были придуманы высокоуровневые инструменты, такие как
Посмотреть зависимости можно командой:
И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:
▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.
▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.
▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.
▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.
▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.
▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.
▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.
▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.
Как мы уже говорили выше, высокоуровневые менеджеры автоматически разрешают зависимости с типом: предзависит, зависит, конфликтует, заменяет, ломает и предоставляет.
Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.
Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.
Так вот, так делать можно, но не нужно. Потому что в этом случае пакеты будут считаться установленными интерактивно и не будут удаляться командой
Слово зависимость знают все, но далеко не все понимают, что именно значит этот термин и часто применяют его неправильно. Поэтому сегодня мы решили разобрать этот вопрос.
Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является
dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки. При распаковке файлы извлекаются из пакета и размещаются на указанные места в файловой системе, а настройка обеспечивает выполнение необходимых скриптов и действий, например, создание нужных пользователей и групп, добавление в автозагрузку и т.д. и т.п.
Если в процессе настройки
dpkg обнаруживает неудовлетворенные зависимости, то он прекращает настройку и пакет остается распакованным, но не настроенным, мы можем попытаться удовлетворить зависимости и заново попытаться настроить пакет.Но так как разрешение зависимостей дело непростое, то были придуманы высокоуровневые инструменты, такие как
apt-get и apt, задача которых – построить дерево зависимостей, скачать их все и передать для установки тому же dpkg.Посмотреть зависимости можно командой:
apt-cache depends package_name
И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:
▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.
▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.
▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.
▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.
▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.
▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.
▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.
▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.
Как мы уже говорили выше, высокоуровневые менеджеры автоматически разрешают зависимости с типом: предзависит, зависит, конфликтует, заменяет, ломает и предоставляет.
Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.
Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.
Так вот, так делать можно, но не нужно. Потому что в этом случае пакеты будут считаться установленными интерактивно и не будут удаляться командой
autoremove после удаления основного пакета.
👍55❤1
За героизм нам не платят
Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.
Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.
Да, причиной возникновения подобной ситуации может послужить некий внешний фактор, но это только триггер, маленький камушек запускающий сход целой лавины. А истинные причины, в случае лавины, это накопление критической массы снега на склоне.
В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.
По-хорошему, причиной авральной ситуации может быть только наступление форс-мажора, т.е. обстоятельств непреодолимой силы. Во всех остальных случаях ситуация может быть сложной, но контролируемой.
Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.
Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.
В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.
Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.
А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?
Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.
Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.
Обычно это начинается так: нам нужно…
А вы вместо того, чтобы обоснованно пояснить, что тут у нас не хватает ресурсов: вычислительных, памяти, пропускной способности, технологического окна и т.д. и т.п. просто берете под козырек и говорите, что мол попробуем.
Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…
Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.
В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…
Но это был безобидный сценарий. А ведь может все пойти не так, и ситуация превратится в авральную и неконтролируемую. После чего сразу переходим к пункту про вынужденный героизм.
Но тут есть нюансы, если причиной критического сбоя послужил внешний фактор, то им еще как-то можно прикрыться. А вот если вы размотали систему «на ровном месте», то это конкретное попадалово.
Потому что руководство доходчиво вам объяснит всю степень вашей неправоты: не контролировал, неверно оценивал риски, не приложил должных усилий и т.д. и т.п.
И оправдания, типа ну я же просил новый сервер, диски, память и т.п. не прокатят. Так как вам справедливо заметят, что если вы осознавали, то почему делали?
А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.
В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.
Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.
Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.
Да, причиной возникновения подобной ситуации может послужить некий внешний фактор, но это только триггер, маленький камушек запускающий сход целой лавины. А истинные причины, в случае лавины, это накопление критической массы снега на склоне.
В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.
По-хорошему, причиной авральной ситуации может быть только наступление форс-мажора, т.е. обстоятельств непреодолимой силы. Во всех остальных случаях ситуация может быть сложной, но контролируемой.
Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.
Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.
В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.
Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.
А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?
Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.
Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.
Обычно это начинается так: нам нужно…
А вы вместо того, чтобы обоснованно пояснить, что тут у нас не хватает ресурсов: вычислительных, памяти, пропускной способности, технологического окна и т.д. и т.п. просто берете под козырек и говорите, что мол попробуем.
Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…
Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.
В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…
Но это был безобидный сценарий. А ведь может все пойти не так, и ситуация превратится в авральную и неконтролируемую. После чего сразу переходим к пункту про вынужденный героизм.
Но тут есть нюансы, если причиной критического сбоя послужил внешний фактор, то им еще как-то можно прикрыться. А вот если вы размотали систему «на ровном месте», то это конкретное попадалово.
Потому что руководство доходчиво вам объяснит всю степень вашей неправоты: не контролировал, неверно оценивал риски, не приложил должных усилий и т.д. и т.п.
И оправдания, типа ну я же просил новый сервер, диски, память и т.п. не прокатят. Так как вам справедливо заметят, что если вы осознавали, то почему делали?
А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.
В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.
50👍51🥱6💯3👀2
Про бумажки
Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях вчерашней заметки этот метод неоднократно всплывал.
Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?
Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик ила работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.
Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.
В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением.
Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий.
Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема.
А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.
Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…
Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом.
Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью.
Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.
И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться.
Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник?
Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.
Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители.
А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать.
Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.
Поэтому – просто не работайте с чудаками на букву «м».
Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях вчерашней заметки этот метод неоднократно всплывал.
Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?
Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик ила работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.
Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.
В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением.
Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий.
Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема.
А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.
Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…
Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом.
Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью.
Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.
И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться.
Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник?
Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.
Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители.
А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать.
Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.
Поэтому – просто не работайте с чудаками на букву «м».
👍56👀7💯1🤝1
Вышла бета-версия Ubuntu 25.04
Пакетная база полностью заморожена идет тестирование и исправление ошибок. В целом каких-то критичных косяков не обнаружено, кто хочет быть на острие прогресса – может ставить или обновляться.
По сути, 25.04 типичный промежуточный релиз – что могли обновить, то обновили. Где хотели что-то добавить – добавили, изменить – изменили.
Из важного – добавлена поддержка Dracut для формирования образов начального RAM-диска (initrd). Сейчас этим занимается initramfs-tools, в осеннем выпуске 25.10 планируется использовать Dracut по умолчанию.
Ну и в целом не следует забывать, что все промежуточные релизы – по сути бета-версии и предназначены для тестирования изменений и нововведений для следующих LTS. А короткий срок поддержки – 9 месяцев не даст сидеть на месте, заставляя постоянно обновляться.
Пакетная база полностью заморожена идет тестирование и исправление ошибок. В целом каких-то критичных косяков не обнаружено, кто хочет быть на острие прогресса – может ставить или обновляться.
По сути, 25.04 типичный промежуточный релиз – что могли обновить, то обновили. Где хотели что-то добавить – добавили, изменить – изменили.
Из важного – добавлена поддержка Dracut для формирования образов начального RAM-диска (initrd). Сейчас этим занимается initramfs-tools, в осеннем выпуске 25.10 планируется использовать Dracut по умолчанию.
Ну и в целом не следует забывать, что все промежуточные релизы – по сути бета-версии и предназначены для тестирования изменений и нововведений для следующих LTS. А короткий срок поддержки – 9 месяцев не даст сидеть на месте, заставляя постоянно обновляться.
👍18🤔3👎1
Однострочный веб-сервер на Bash
Часто бывает нужно отслеживать некоторые показатели целевого сервера или контролировать ход работы какого-либо сервиса. Все это можно сделать командами, но постоянно вызывать их в консоли – занятие утомительное.
Но есть способ проще, создать специальную страничку в браузере и вывести на нее все необходимые показатели. Причем нам не потребуется устанавливать никакого софта, все можно сделать силами bash.
И в этом нам поможет команда netcat (nc), мы не будем подробно разбирать ее применение, а просто покажем примеры.
Например, мы хотим видеть свободную память:
Здесь следует обратить внимание на опции -p – порт и q – время в секундах до закрытия соединения, если у вас там выполняется сложная команда, то возможно его придется увеличить.
Таким же образом можно просматривать логи:
Возьмем задачу немного сложнее, вывести сразу несколько показателей, ок, прямо не выходя из терминала выполним:
Но если всего этого недостаточно, то вы можете написать скрипт, который будет выводить нужную вам информацию и запускать его нашим однострочным веб-сервером:
Просто? Да. Удобно? Да. И только bash и никаких дополнительных инструментов!
Часто бывает нужно отслеживать некоторые показатели целевого сервера или контролировать ход работы какого-либо сервиса. Все это можно сделать командами, но постоянно вызывать их в консоли – занятие утомительное.
Но есть способ проще, создать специальную страничку в браузере и вывести на нее все необходимые показатели. Причем нам не потребуется устанавливать никакого софта, все можно сделать силами bash.
И в этом нам поможет команда netcat (nc), мы не будем подробно разбирать ее применение, а просто покажем примеры.
Например, мы хотим видеть свободную память:
while true;
do echo -e "HTTP/1.1 200 OK\n\n$(free)" \
| nc -l -k -p 8080 -q 1;
done
Здесь следует обратить внимание на опции -p – порт и q – время в секундах до закрытия соединения, если у вас там выполняется сложная команда, то возможно его придется увеличить.
Таким же образом можно просматривать логи:
while true;
do echo -e "HTTP/1.1 200 OK\n\n$(tail -n 15 logfile)" \
| nc -l -k -p 8080 -q 1;
done
Возьмем задачу немного сложнее, вывести сразу несколько показателей, ок, прямо не выходя из терминала выполним:
cmd1=$(free)
cmd2=$(ss -tpln)
body="$cmd1\n$cmd2"
while true;
do echo -e "HTTP/1.1 200 OK\n\n$body" \
| nc -l -k -p 8080 -q 1;
done
Но если всего этого недостаточно, то вы можете написать скрипт, который будет выводить нужную вам информацию и запускать его нашим однострочным веб-сервером:
while true; do { \
echo -ne "HTTP/1.1 200 OK\r\n"; sh my_script.sh; } \
| nc -l -k -p 8080 -q 1; \
doneПросто? Да. Удобно? Да. И только bash и никаких дополнительных инструментов!
👍68🔥14😁1🤯1🤬1
Ansible в действии: развернем кластер с Kuberspray и запустим AI-приложение 🚀
Приглашаем на бесплатный вебинар от Слёрма, на котором расскажем и покажем:
🔸 Как развернуть нейронную сеть в контейнере и сделать её доступной для всего мира?
🔸 Как быстро настроить кластер и управлять им?
🔸 Как Kubernetes управляет AI-приложениями?
🔸 Как Docker работает в Kubernetes?
🎁 Бонус: каждый зритель получит репозиторий для собственного Kubernetes-кластера с AI-приложением и полную инструкцию по развертыванию.
Дата: 9 апреля 19:00
Занять место — через бота 👈
erid: 2W5zFJxjGB2
Приглашаем на бесплатный вебинар от Слёрма, на котором расскажем и покажем:
🔸 Как развернуть нейронную сеть в контейнере и сделать её доступной для всего мира?
🔸 Как быстро настроить кластер и управлять им?
🔸 Как Kubernetes управляет AI-приложениями?
🔸 Как Docker работает в Kubernetes?
🎁 Бонус: каждый зритель получит репозиторий для собственного Kubernetes-кластера с AI-приложением и полную инструкцию по развертыванию.
Дата: 9 апреля 19:00
Занять место — через бота 👈
erid: 2W5zFJxjGB2
Чем отличаются DHCP Option 015 (DNS Domain Name) и DHCP Option 119 (Domain Search List)
Не так давно в обсуждениях снова всплыли плоские имена и связанные с ними проблемы.
Что такое плоское имя? Это имя компьютера из одного слова, например,
Чтобы обратиться к компьютеру по сети, мы должны преобразовать (разрешить) его имя в IP-адрес. Для плоского имени это можно сделать только при помощи широковещательных протоколов сетевого обнаружения или WINS-сервера.
Широковещательные протоколы не самый лучший вариант с точки зрения нагрузки на сеть и их работа ограничена широковещательным доменом (т.е. текущим сегментом сети).
WINS снимает эти проблемы, но данный протокол является устаревшим и уязвимым, поэтому в современных сетях его использовать не следует.
В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:
Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция
Если мы передали в этой опции домен
Вроде бы все хорошо, но сети растут, количество доменов в нем увеличивается и коллеги вполне могут прислать ссылку с плоским именем:
Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.
Поэтому была введена опция
DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.
Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.
Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.
Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.
Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.
В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику
Не так давно в обсуждениях снова всплыли плоские имена и связанные с ними проблемы.
Что такое плоское имя? Это имя компьютера из одного слова, например,
SERVER-01 или PC-003. Чтобы обратиться к компьютеру по сети, мы должны преобразовать (разрешить) его имя в IP-адрес. Для плоского имени это можно сделать только при помощи широковещательных протоколов сетевого обнаружения или WINS-сервера.
Широковещательные протоколы не самый лучший вариант с точки зрения нагрузки на сеть и их работа ограничена широковещательным доменом (т.е. текущим сегментом сети).
WINS снимает эти проблемы, но данный протокол является устаревшим и уязвимым, поэтому в современных сетях его использовать не следует.
В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:
SERVER-01.
Что обозначает домен первого уровня SERVER-01, аналогичный RU или COM. Естественно, такой зоны на вашем DNS-сервере найдено не будет и поиск закончится неудачей.Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция
DHCP 015 (DNS Domain Name), которая задает имя домена используемое при разрешении имен на DNS-сервере. Также ее часто называют DNS Suffix.Если мы передали в этой опции домен
example.office, то любое плоское имя будет дополнено как:SERVER-01. example.office.
После чего запрошенное имя будет легко разрешено обслуживающим зону DNS-сервером.Вроде бы все хорошо, но сети растут, количество доменов в нем увеличивается и коллеги вполне могут прислать ссылку с плоским именем:
http://webserver-005/otchet.pdf
Где указанное плоское имя соответствует веб-серверу филиала на хуторе Гадюкино который использует домен example.gadykino.office. Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.
Поэтому была введена опция
DHCP 119 (Domain Search List), которая содержит список доменов используемых для разрешения имен, теперь мы можем передать в нем как example.office, так и example.gadykino.office. DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.
Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.
Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.
Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.
Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.
В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику
Computer Configuration -> Administrative Templates -> Network -> DNS Client and open DNS Suffix Search List.
👍59
Большинство администраторов знают про опции DHCP и про то, что с их помощью можно передать на клиент много чего интересного.
Но с работой опций связано одно широко распространенное заблуждение. В результате многие удивляются, мол я добавил опций, а они почему-то не применяются.
Однако есть одна тонкость. Опции всегда запрашиваются клиентом и в ответ сервер передаст именно то, что клиент запросил. Если клиент не запрашивает опцию, то добавлена она на сервер или нет - значения не имеет.
Состав запрашиваемых опций передается серверу в опции 55, на скриншоте ниже можно сравнить запрашиваемые опции в Linux и Windows. Например, Linux запрашивает опцию 42 - NTP сервер, а Windows нет.
Подробнее про работу DHCP читайте в нашей статье:
https://interface31.ru/tech_it/2019/07/kak-ustroen-i-rabotaet-protokol-dhcp.html
Но с работой опций связано одно широко распространенное заблуждение. В результате многие удивляются, мол я добавил опций, а они почему-то не применяются.
Однако есть одна тонкость. Опции всегда запрашиваются клиентом и в ответ сервер передаст именно то, что клиент запросил. Если клиент не запрашивает опцию, то добавлена она на сервер или нет - значения не имеет.
Состав запрашиваемых опций передается серверу в опции 55, на скриншоте ниже можно сравнить запрашиваемые опции в Linux и Windows. Например, Linux запрашивает опцию 42 - NTP сервер, а Windows нет.
Подробнее про работу DHCP читайте в нашей статье:
https://interface31.ru/tech_it/2019/07/kak-ustroen-i-rabotaet-protokol-dhcp.html
👍61🔥9❤2
🌊 На гребне технологий: первые результаты партнерского тестирования zVirt 4.3
Компании продолжают переходить на российские решения для работы с ИТ-инфраструктурой. Среди них – система серверной виртуализации zVirt, флагманский продукт вендора Orion soft.
Вчера Orion soft выпустил новый релиз системы zVirt 4.3. Получив ранний доступ к новому функционалу, команда ИТ-интегратора К2Тех уже успела протестировать его и готова поделиться результатами⚡️
📍8 апреля в 16:00 на онлайн-митапе эксперты К2Тех расскажут об обновлениях платформы и их пользе для бизнес-заказчиков, а также сравнят функционал продукта с другими решениями по виртуализации на основе своего опыта внедрения всех ведущих платформ.
Митап будет полезен, если вы:
🔸 ИТ-директор/CIO
🔸 Директор/Руководитель направления ИТ-инфраструктуры
🔸 Технический директор
🔸 Руководитель ИТ-подразделений
🔸 Главный инженер
Читайте подробности о программе митапа, ключевых обновлениях, спикерах и регистрируйтесь на мероприятие по ссылке 🌐
Компании продолжают переходить на российские решения для работы с ИТ-инфраструктурой. Среди них – система серверной виртуализации zVirt, флагманский продукт вендора Orion soft.
Вчера Orion soft выпустил новый релиз системы zVirt 4.3. Получив ранний доступ к новому функционалу, команда ИТ-интегратора К2Тех уже успела протестировать его и готова поделиться результатами⚡️
📍8 апреля в 16:00 на онлайн-митапе эксперты К2Тех расскажут об обновлениях платформы и их пользе для бизнес-заказчиков, а также сравнят функционал продукта с другими решениями по виртуализации на основе своего опыта внедрения всех ведущих платформ.
Митап будет полезен, если вы:
🔸 ИТ-директор/CIO
🔸 Директор/Руководитель направления ИТ-инфраструктуры
🔸 Технический директор
🔸 Руководитель ИТ-подразделений
🔸 Главный инженер
Читайте подробности о программе митапа, ключевых обновлениях, спикерах и регистрируйтесь на мероприятие по ссылке 🌐
🔥7👍6🤡3👏2❤1