Работаем с жесткими и символическими ссылками в Windows
Жесткие и символические ссылки давно знакомы и активно используются Linux-администраторами, в то время как их Windows коллеги используют их гораздо реже, а некоторые вообще не знают о такой возможности.
Тем не менее такая возможность в Windows существует и позволяет значительно упростить некоторые сценарии работы с папками и файлами.
В данной статье мы рассмотрим все виды ссылок, доступные в среде ОС Windows, а также разные способы работы с ними, начиная от командной строки и заканчивая PowerShell.
✅ Читать далее: https://interface31.ru/post/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows/
Жесткие и символические ссылки давно знакомы и активно используются Linux-администраторами, в то время как их Windows коллеги используют их гораздо реже, а некоторые вообще не знают о такой возможности.
Тем не менее такая возможность в Windows существует и позволяет значительно упростить некоторые сценарии работы с папками и файлами.
В данной статье мы рассмотрим все виды ссылок, доступные в среде ОС Windows, а также разные способы работы с ними, начиная от командной строки и заканчивая PowerShell.
✅ Читать далее: https://interface31.ru/post/rabotaem-s-zhestkimi-i-simvolicheskimi-ssylkami-v-windows/
👍11❤2👌1
Горе от ума или причины упадка FreeBSD
Каждый раз, когда заходит речь про FreeBSD, обязательно появляются фанаты и поклонники системы, которые рассказывают какая она передовая и продвинутая, не то, что эти все ваши «линухи» и т.д. и т.п.
Тут, конечно, хочется задать классический вопрос: если ты такой умный, то почему такой бедный? А применительно к ОС хочется спросить, а где ее пользовательская база? И почему так получилось, что из технологического лидера FreeBSD очень быстро превратилась в маргинальную и нишевую систему.
Я почитал материалы 2011 года, когда от FreeBSD отказались два отечественных IT-гиганта – Яндекс и Рамблер. Тогда было сломано много копий, но были и вполне разумные выводы и высказывания, которые, к сожалению, оказались не услышанными.
Основная проблема FreeBSD – это ее происхождение, а появилась она в университете Беркли и разрабатывалась в первую очередь в этой самой университетской среде. Это сразу задало стиль разработки – строим величественный собор под руководством грамотных архитекторов.
С одной стороны – это правильно, это хорошо. Но с другой – страшно далеки они от народа, эти все архитекторы, равно как и научная, университетская среда от обычной жизни.
Linux строился по принципу караван-сарая. Надо – сделаем, вот тут с боку прилепим, ну и что, что неказисто, зато работает. И, что более важно, в разработке Linux использовался инженерный подход, а не научный.
В этом и заключается самая большая разница и самая большая проблема BSD. Любой инженер знает, что теория проверяется практикой и никак иначе. Если какая-то идея хорошо выглядит на бумаге, но нормально не работает – это плохая идея и ее следует отвергнуть.
Также любой инженер знает, что такое эксплуатация, изделие может быть сколь угодно технически продвинутым, но, если оно требует трехмесячных курсов и работы в белых перчатках – это плохое изделие.
Хорошее изделие должно быть эффективным, простым и недорогим в обслуживании. А еще инженер знает, как важна обратная связь с эксплуатацией, ибо только эксплуатация может выявить все сильные и слабые стороны.
А также эксплуатация может сказать, что вот это нам не надо, а вот это, наоборот, надо развить и улучшить. И это будет правильно, так как практика всегда важнее теории.
Поэтому в Linux всегда приветствовали простых пользователей, т.е. эксплуатантов, прислушивались к ним, считали равноправной и неотъемлемой частью сообщества. И это работало и работает до сих пор.
Участники сообщества дают обратную связь, оказывают поддержку на форумах и в каналах, пишут статьи и мануалы, всячески повышая популярность своей системы.
Но академическая среда устроена совсем по-другому, это закрытая система, где критика может приниматься только от равных. Критиковать архитектора могут только архитекторы, желательно равные по регалиям и заслугам.
А попробуй это сделать какой-нибудь «выскочка», то его сразу спросят: а где твои научные работы? Кто ты вообще такой? Кто позволил тебе критиковать авторитетного и уважаемого человека?
Этот же стиль полностью перенесся на FreeBSD, где все решения по системе принимала узкая кучка лиц. Которая, по сути, писала систему для себя, не считаясь с мнением сообщества. Если в системе чего-то не было, значит это просто не нужно. Простой и универсальный ответ на все вопросы.
Само же сообщество было проникнуто духом элитарности и крайне высокой планкой вступления. На любое замечание по работе ПО было принято спрашивать: where are your patches? (Где твои патчи?).
Т.е. если ты не способен соответствовать высоким запросам сообщества – то тебе в нем делать нечего, тебя там не ждут, тебе не рады. И об этом заявлялось практически официально, мол нам тут не нужны «недоадмины» по образу и подобию линуксовых.
В результате народ начал голосовать ногами в сторону более демократичного и развивающегося Linux. А когда «великие архитекторы» проспали ряд технологических новшеств, ногами стал голосовать и бизнес, хотя нерешаемых технических проблем там не было.
Но «элитарный» подход и «это не нужно» - свое дело сделали.
Каждый раз, когда заходит речь про FreeBSD, обязательно появляются фанаты и поклонники системы, которые рассказывают какая она передовая и продвинутая, не то, что эти все ваши «линухи» и т.д. и т.п.
Тут, конечно, хочется задать классический вопрос: если ты такой умный, то почему такой бедный? А применительно к ОС хочется спросить, а где ее пользовательская база? И почему так получилось, что из технологического лидера FreeBSD очень быстро превратилась в маргинальную и нишевую систему.
Я почитал материалы 2011 года, когда от FreeBSD отказались два отечественных IT-гиганта – Яндекс и Рамблер. Тогда было сломано много копий, но были и вполне разумные выводы и высказывания, которые, к сожалению, оказались не услышанными.
Основная проблема FreeBSD – это ее происхождение, а появилась она в университете Беркли и разрабатывалась в первую очередь в этой самой университетской среде. Это сразу задало стиль разработки – строим величественный собор под руководством грамотных архитекторов.
С одной стороны – это правильно, это хорошо. Но с другой – страшно далеки они от народа, эти все архитекторы, равно как и научная, университетская среда от обычной жизни.
Linux строился по принципу караван-сарая. Надо – сделаем, вот тут с боку прилепим, ну и что, что неказисто, зато работает. И, что более важно, в разработке Linux использовался инженерный подход, а не научный.
В этом и заключается самая большая разница и самая большая проблема BSD. Любой инженер знает, что теория проверяется практикой и никак иначе. Если какая-то идея хорошо выглядит на бумаге, но нормально не работает – это плохая идея и ее следует отвергнуть.
Также любой инженер знает, что такое эксплуатация, изделие может быть сколь угодно технически продвинутым, но, если оно требует трехмесячных курсов и работы в белых перчатках – это плохое изделие.
Хорошее изделие должно быть эффективным, простым и недорогим в обслуживании. А еще инженер знает, как важна обратная связь с эксплуатацией, ибо только эксплуатация может выявить все сильные и слабые стороны.
А также эксплуатация может сказать, что вот это нам не надо, а вот это, наоборот, надо развить и улучшить. И это будет правильно, так как практика всегда важнее теории.
Поэтому в Linux всегда приветствовали простых пользователей, т.е. эксплуатантов, прислушивались к ним, считали равноправной и неотъемлемой частью сообщества. И это работало и работает до сих пор.
Участники сообщества дают обратную связь, оказывают поддержку на форумах и в каналах, пишут статьи и мануалы, всячески повышая популярность своей системы.
Но академическая среда устроена совсем по-другому, это закрытая система, где критика может приниматься только от равных. Критиковать архитектора могут только архитекторы, желательно равные по регалиям и заслугам.
А попробуй это сделать какой-нибудь «выскочка», то его сразу спросят: а где твои научные работы? Кто ты вообще такой? Кто позволил тебе критиковать авторитетного и уважаемого человека?
Этот же стиль полностью перенесся на FreeBSD, где все решения по системе принимала узкая кучка лиц. Которая, по сути, писала систему для себя, не считаясь с мнением сообщества. Если в системе чего-то не было, значит это просто не нужно. Простой и универсальный ответ на все вопросы.
Само же сообщество было проникнуто духом элитарности и крайне высокой планкой вступления. На любое замечание по работе ПО было принято спрашивать: where are your patches? (Где твои патчи?).
Т.е. если ты не способен соответствовать высоким запросам сообщества – то тебе в нем делать нечего, тебя там не ждут, тебе не рады. И об этом заявлялось практически официально, мол нам тут не нужны «недоадмины» по образу и подобию линуксовых.
В результате народ начал голосовать ногами в сторону более демократичного и развивающегося Linux. А когда «великие архитекторы» проспали ряд технологических новшеств, ногами стал голосовать и бизнес, хотя нерешаемых технических проблем там не было.
Но «элитарный» подход и «это не нужно» - свое дело сделали.
👍21🤔10🥱4❤3👀1
Неожиданный взгляд на BolgenOS
В любой теме, касающейся Linux-дистрибутивов вообще и импортозамещения в частности, обязательно появится комментарий про BolgenOS, которая сегодня стала даже не мемом, а некоторым жупелом.
Но давайте посмотрим на это явление с неожиданной стороны. Потому как там далеко не все так однозначно. Начнем, как обычно, сначала.
BolgenOS была представлена на конкурсе школьных проектов Нижнего Тагила в 2010 году и заняла там первое место. И все сразу заговорили о его авторе – 16-летнем школьнике Денисе Попове.
Но как-то упускается из виду, что над этим проектом Денис работал более полугода на внеклассных занятиях по информатике под руководством своего педагога Ефима Ширинкина.
К Денису у нас нет никаких вопросов, 16 лет – это такой возраст, когда «в голове ветер, в жопе дым» и он сам не мог полностью понимать и осознавать последствия своих действий. Ну это нормально, у всех в этом возрасте есть какие-то вселенские планы и амбиции.
При этом надо отдать должное – в техническом плане Денис был неплохо подкован, так как пересобрать дистрибутив Linux, особенно в те годы, требовало определенных знаний и умений, да и сейчас не каждый 16-летний пацан это сделает.
А вот товарищ Ефим Ширинкин вполне должен был отдавать себе отчет о том, что они делают, взрослый человек, как-никак. И как старший товарищ и наставник должен был предупредить, оградить, направить.
Но он ничего этого не сделал. А почему? А потому что наша система образования ориентируется совсем на другие показатели. Там нужны места в конкурсах, грамоты, дипломы и прочая медийная мишура.
Чем больше этой мишуры – тем успешней школа, успешней учитель, да и управление образования в стороне не останется, если вдруг чего-то такое за пределы региона выстрелит.
И только будучи клиническим идиотом Ефим Ширинкин мог поверить, что его подопечный пишет ОС с нуля. Но идиотом он явно не был, а вот опытным функционером системы был.
В итоге на конкурс была заявлена и получила там первое место «принципиально новая ОС» - BolgenOS. Созданная Тагильским школьником Денисом под чутким руководством Ефима Ширинкина.
Изначально все шло хорошо: высокие оценки, интерес со стороны области, вылившийся в то, что управление образования даже предложило рассмотреть BolgenOS как замену Windows на школьных компьютерах.
Тот, кто знает эту систему, может уверенно сказать, что все это было лишь сотрясение воздуха, нужный пиар, за счет которого нужные люди получили бы столь вожделенные плюшки, выполнили и перевыполнили планы, написали бы кучу красивых отчетов…
Но что-то пошло не так…
Ажиотаж по поводу BolgenOS неожиданно вышел за пределы области и распространился в интернете, чем вызвал неизбежное разоблачение и опровержение.
Крайним, как всегда, назначили самого молодого, т.е. Дениса, хотя именно гражданин Ширинкин приложил, в собственных интересах, конечно, все усилия по медийной раскрутке BolgenOS и Дениса.
После чего парня просто затравили. И отбили у него всякое желание далее развиваться в IT, впоследствии он ушел в звукорежиссуру и музыку, в настоящее время проживает в Москве и крайне не любит вспоминать про BolgenOS.
Но в чем виноват Денис? Только в одном, что по молодости и небольшому уму решил выкосить все копирайты и выдать свою сборку за собственную ОС.
Скажи он, что это просто еще один дистрибутив на основе Ubuntu и сохрани исходные копирайты – вопросов бы к нему не было.
А где были старшие товарищи? Тот же Ширинкин? Почему вовремя не одернул, не направил на путь истинный?
Потому что Ширинкин был функционером и ему все это было на руку, так как позволяло получить кучу плюшек с этого проекта, а там хоть трава не расти. Да и зачем ей расти. На новый учебный год будут новые конкурсы, новые проекты, а про эти никто и не вспомнит.
В итоге парень собрал на себя все говно в интернете, а всю шерсть с этой ситуации поимели старшие, о которых мало кто вспоминал тогда и тем более не вспоминает сейчас.
Хотя может быть в его лице страна потеряла хорошего, талантливого айтишника?
В любой теме, касающейся Linux-дистрибутивов вообще и импортозамещения в частности, обязательно появится комментарий про BolgenOS, которая сегодня стала даже не мемом, а некоторым жупелом.
Но давайте посмотрим на это явление с неожиданной стороны. Потому как там далеко не все так однозначно. Начнем, как обычно, сначала.
BolgenOS была представлена на конкурсе школьных проектов Нижнего Тагила в 2010 году и заняла там первое место. И все сразу заговорили о его авторе – 16-летнем школьнике Денисе Попове.
Но как-то упускается из виду, что над этим проектом Денис работал более полугода на внеклассных занятиях по информатике под руководством своего педагога Ефима Ширинкина.
К Денису у нас нет никаких вопросов, 16 лет – это такой возраст, когда «в голове ветер, в жопе дым» и он сам не мог полностью понимать и осознавать последствия своих действий. Ну это нормально, у всех в этом возрасте есть какие-то вселенские планы и амбиции.
При этом надо отдать должное – в техническом плане Денис был неплохо подкован, так как пересобрать дистрибутив Linux, особенно в те годы, требовало определенных знаний и умений, да и сейчас не каждый 16-летний пацан это сделает.
А вот товарищ Ефим Ширинкин вполне должен был отдавать себе отчет о том, что они делают, взрослый человек, как-никак. И как старший товарищ и наставник должен был предупредить, оградить, направить.
Но он ничего этого не сделал. А почему? А потому что наша система образования ориентируется совсем на другие показатели. Там нужны места в конкурсах, грамоты, дипломы и прочая медийная мишура.
Чем больше этой мишуры – тем успешней школа, успешней учитель, да и управление образования в стороне не останется, если вдруг чего-то такое за пределы региона выстрелит.
И только будучи клиническим идиотом Ефим Ширинкин мог поверить, что его подопечный пишет ОС с нуля. Но идиотом он явно не был, а вот опытным функционером системы был.
В итоге на конкурс была заявлена и получила там первое место «принципиально новая ОС» - BolgenOS. Созданная Тагильским школьником Денисом под чутким руководством Ефима Ширинкина.
Изначально все шло хорошо: высокие оценки, интерес со стороны области, вылившийся в то, что управление образования даже предложило рассмотреть BolgenOS как замену Windows на школьных компьютерах.
Тот, кто знает эту систему, может уверенно сказать, что все это было лишь сотрясение воздуха, нужный пиар, за счет которого нужные люди получили бы столь вожделенные плюшки, выполнили и перевыполнили планы, написали бы кучу красивых отчетов…
Но что-то пошло не так…
Ажиотаж по поводу BolgenOS неожиданно вышел за пределы области и распространился в интернете, чем вызвал неизбежное разоблачение и опровержение.
Крайним, как всегда, назначили самого молодого, т.е. Дениса, хотя именно гражданин Ширинкин приложил, в собственных интересах, конечно, все усилия по медийной раскрутке BolgenOS и Дениса.
После чего парня просто затравили. И отбили у него всякое желание далее развиваться в IT, впоследствии он ушел в звукорежиссуру и музыку, в настоящее время проживает в Москве и крайне не любит вспоминать про BolgenOS.
Но в чем виноват Денис? Только в одном, что по молодости и небольшому уму решил выкосить все копирайты и выдать свою сборку за собственную ОС.
Скажи он, что это просто еще один дистрибутив на основе Ubuntu и сохрани исходные копирайты – вопросов бы к нему не было.
А где были старшие товарищи? Тот же Ширинкин? Почему вовремя не одернул, не направил на путь истинный?
Потому что Ширинкин был функционером и ему все это было на руку, так как позволяло получить кучу плюшек с этого проекта, а там хоть трава не расти. Да и зачем ей расти. На новый учебный год будут новые конкурсы, новые проекты, а про эти никто и не вспомнит.
В итоге парень собрал на себя все говно в интернете, а всю шерсть с этой ситуации поимели старшие, о которых мало кто вспоминал тогда и тем более не вспоминает сейчас.
Хотя может быть в его лице страна потеряла хорошего, талантливого айтишника?
🔥14👍11❤5💯3🤮1
Развод и кухня пополам
На этой неделе в очередной раз столкнулись с нехорошей и некрасивой ситуацией. Один из наших заказчиков нехорошо разошелся со своим бухгалтером. Бухгалтер была на аутсорсе, предоставляла услуги как ИП.
Договор? Да какой там договор, стандартная рыба из интернета на одну сторону листа с очень и очень общими фразами. Ну и часть суммы оплачивалась не на расчетный счет, а на карту. Такая вот «налоговая оптимизация».
В результате бухгалтер с начала текущего месяца разорвала с заказчиком все отношения, базу 1С:Предприятие передавать отказалась, мотивируя это тем, что база – результат ее интеллектуального труда.
Взамен передала оборотно-сальдовую ведомость, да состояние регистров учета за 9 месяцев, все исключительно на бумаге, чтобы посильнее насолить заказчику.
Причем здесь она полностью в своем праве, в отличие от художеств многих обиженных системных администраторов, которые просто рискуют поднять с пола статью. База – действительно результат интеллектуального труда.
Все, на что может претендовать заказчик – это первичные документы (которые и так у него есть) и текущее состояние учета (которое ему передали).
По роду работы я давно и прекрасно знаю обе стороны конфликта, также успел выслушать и прочитать трактовку событий с каждой стороны.
И что тут можно сказать? Претензии у обеих сторон - по существу и достаточно обоснованные. Многое – результат взаимного недопонимания и различного представления о том, какую именно работу должен выполнять бухгалтер и сколько это должно стоить.
В общем, классическая история про развод с битьем посуды и делением совместно нажитого имущества. Только в бизнесе.
И обе стороны одновременно и правы, и виноваты. Однозначно хороших и однозначно плохих в этой истории нет.
Что могло помочь нашим фигурантам? Договор, только нормальный, а не формальная рыба из интернета. В котором бы четко были прописаны все взаимоотношения. Объем работ, порядок их сдачи-приемки, оплата. А также такие вопросы, как принадлежность информационной базы и прочие тонкости.
В этом случае, даже в случае возникновения непримиримых противоречий всегда можно сесть и почитать, а что именно написано в договоре и насколько каждая из сторон добросовестно его исполнила.
Не достигли понимания в переговорах, тогда прямая дорожка в Арбитражный Суд. А там тоже начнут с изучения договора.
Мы уже не раз об этом говорили, повторим еще раз – договор должен быть по существу! Не цитируйте в него абзацы из Гражданского Кодекса - они и так имеют приоритет над любым договором. А лучше, распишите подробно, что вы собрались делать, как и на основании каких критериев сдавать сделанное.
Хороший договор одинаково защищает и заказчика, и исполнителя. Поэтому не надо в штыки воспринимать возражения с другой стороны, их надо проанализировать, учесть и найти общие формулировки, который будут устраивать каждую из сторон.
По ходу пьесы всплыло что-то неучтенное в договоре? Оформляем дополнительным соглашением, этих дополнительных соглашений у договора может быть как блох на барбоске, но все они имеют юридическую силу, в отличие от устных договоренностей или сообщений в мессенджерах.
И не бойтесь показаться занудой или бюрократом, вся эта, на первый взгляд, бумагомарательская деятельность идет на пользу обеим сторонам, так как позволяет наиболее полно и справедливо разобраться в возможных конфликтных ситуациях.
Ну и не забывайте, кроме договора вовремя оформлять и подписывать документы, те же акты выполненных работ, либо выставлять на них возражения, если вас что-то не устраивает.
К актам желательно предоставлять и подписывать подробные расшифровки, которые будут подтверждать время, место, объем и характер работ, иначе достаточно легко можно оспорить их как фиктивные.
И не забывайте оформить официально каналы общения с контрагентом. Если в договоре указано, что стороны общаются по факсу и электронной почте, то никакой суд не примет у вас в доказательство переписку в Телеграм. А что мешало добавить в договор?
На этой неделе в очередной раз столкнулись с нехорошей и некрасивой ситуацией. Один из наших заказчиков нехорошо разошелся со своим бухгалтером. Бухгалтер была на аутсорсе, предоставляла услуги как ИП.
Договор? Да какой там договор, стандартная рыба из интернета на одну сторону листа с очень и очень общими фразами. Ну и часть суммы оплачивалась не на расчетный счет, а на карту. Такая вот «налоговая оптимизация».
В результате бухгалтер с начала текущего месяца разорвала с заказчиком все отношения, базу 1С:Предприятие передавать отказалась, мотивируя это тем, что база – результат ее интеллектуального труда.
Взамен передала оборотно-сальдовую ведомость, да состояние регистров учета за 9 месяцев, все исключительно на бумаге, чтобы посильнее насолить заказчику.
Причем здесь она полностью в своем праве, в отличие от художеств многих обиженных системных администраторов, которые просто рискуют поднять с пола статью. База – действительно результат интеллектуального труда.
Все, на что может претендовать заказчик – это первичные документы (которые и так у него есть) и текущее состояние учета (которое ему передали).
По роду работы я давно и прекрасно знаю обе стороны конфликта, также успел выслушать и прочитать трактовку событий с каждой стороны.
И что тут можно сказать? Претензии у обеих сторон - по существу и достаточно обоснованные. Многое – результат взаимного недопонимания и различного представления о том, какую именно работу должен выполнять бухгалтер и сколько это должно стоить.
В общем, классическая история про развод с битьем посуды и делением совместно нажитого имущества. Только в бизнесе.
И обе стороны одновременно и правы, и виноваты. Однозначно хороших и однозначно плохих в этой истории нет.
Что могло помочь нашим фигурантам? Договор, только нормальный, а не формальная рыба из интернета. В котором бы четко были прописаны все взаимоотношения. Объем работ, порядок их сдачи-приемки, оплата. А также такие вопросы, как принадлежность информационной базы и прочие тонкости.
В этом случае, даже в случае возникновения непримиримых противоречий всегда можно сесть и почитать, а что именно написано в договоре и насколько каждая из сторон добросовестно его исполнила.
Не достигли понимания в переговорах, тогда прямая дорожка в Арбитражный Суд. А там тоже начнут с изучения договора.
Мы уже не раз об этом говорили, повторим еще раз – договор должен быть по существу! Не цитируйте в него абзацы из Гражданского Кодекса - они и так имеют приоритет над любым договором. А лучше, распишите подробно, что вы собрались делать, как и на основании каких критериев сдавать сделанное.
Хороший договор одинаково защищает и заказчика, и исполнителя. Поэтому не надо в штыки воспринимать возражения с другой стороны, их надо проанализировать, учесть и найти общие формулировки, который будут устраивать каждую из сторон.
По ходу пьесы всплыло что-то неучтенное в договоре? Оформляем дополнительным соглашением, этих дополнительных соглашений у договора может быть как блох на барбоске, но все они имеют юридическую силу, в отличие от устных договоренностей или сообщений в мессенджерах.
И не бойтесь показаться занудой или бюрократом, вся эта, на первый взгляд, бумагомарательская деятельность идет на пользу обеим сторонам, так как позволяет наиболее полно и справедливо разобраться в возможных конфликтных ситуациях.
Ну и не забывайте, кроме договора вовремя оформлять и подписывать документы, те же акты выполненных работ, либо выставлять на них возражения, если вас что-то не устраивает.
К актам желательно предоставлять и подписывать подробные расшифровки, которые будут подтверждать время, место, объем и характер работ, иначе достаточно легко можно оспорить их как фиктивные.
И не забывайте оформить официально каналы общения с контрагентом. Если в договоре указано, что стороны общаются по факсу и электронной почте, то никакой суд не примет у вас в доказательство переписку в Телеграм. А что мешало добавить в договор?
👍17❤5👌4🤡1💯1
Прогнозирования выхода твердотельных накопителей из строя
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
👍27❤1
Мифы и легенды Active Directory – откуда ноги растут
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
🔥13👍11❤2
Сотрудник уволился, а доступ остался. Бот получил права, но кто за них отвечает, непонятно. Единый вход настроен, а избыточные полномочия никуда не исчезли. Как учесть эти задачи при выборе системы управления доступом?
9 октября в 13:00 мск приглашаем на вебинар «Диасофт» «Управление доступом в 2027 году: задачи, технологии и критерии выбора IAM».
Обсудим, как меняются требования к IAM и что стоит проверить, прежде чем внедрять или развивать систему:
🟣 как управлять правами сотрудников от приема до увольнения;
🟣 что учитывать при переходе к беспарольной и многофакторной аутентификации;
🟣 как контролировать доступ сервисов, ботов и ИИ-агентов;
🟣 какие вопросы задать поставщику и какие сценарии проверить на пилоте.
Спикер – Анастасия Камашева, ведущий аналитик департамента по инструментам и технологиям разработки компании «Диасофт».
Участие бесплатное.
Зарегистрируйтесь по ссылке
#реклама
О рекламодателе
9 октября в 13:00 мск приглашаем на вебинар «Диасофт» «Управление доступом в 2027 году: задачи, технологии и критерии выбора IAM».
Обсудим, как меняются требования к IAM и что стоит проверить, прежде чем внедрять или развивать систему:
🟣 как управлять правами сотрудников от приема до увольнения;
🟣 что учитывать при переходе к беспарольной и многофакторной аутентификации;
🟣 как контролировать доступ сервисов, ботов и ИИ-агентов;
🟣 какие вопросы задать поставщику и какие сценарии проверить на пилоте.
Спикер – Анастасия Камашева, ведущий аналитик департамента по инструментам и технологиям разработки компании «Диасофт».
Участие бесплатное.
Зарегистрируйтесь по ссылке
#реклама
О рекламодателе
Файловая информационная база 1С:Предприятие
Обсуждение показало, что многие коллеги имеют превратное представление о файловой информационной базе 1С, считая ее пережитком прошлого и вообще сосредоточением всех возможных недостатков платформы.
Однако это далеко не так, и в данной заметке мы расскажем почему.
Что собой представляет файловая база? Это собственный формат базы данных от 1С, который всю необходимую информацию хранит в одном единственном файле 1Cv8.1CD, кроме него в папке с базой находятся вспомогательные файлы, но никакой ценности они не несут, все нужное сосредоточено в единственном файле.
Файл имеет страничную структуру и может содержать 2^32-1 страницу размером 4 КБ, что ограничивает общий объем файла базы размеров в 16 ТБ. При этом, в силу внутреннего устройства действует дополнительное ограничение в размере 4 ГБ на размер внутренней таблицы файла.
Начиная с версии 8.3.8 можно менять размер страницы с 4 КБ до 64 КБ, что позволяет увеличить лимит размера внутренней таблицы до 6 ГБ.
Что касается скорости работы, то при прочих равных файловая база всегда работает быстрее клиент-серверной, быстрее в несколько раз. В этом может легко убедиться каждый при помощи теста Гилева. В результате нашего экспресс-теста была получена трехкратная разница.
Как это можно использовать? Если у вас есть тяжелые задачи, требующие преимущественно однопоточного, монопольного доступа, то вы можете радикально их ускорить, выгрузив клиент-серверную базу в файловую, выполнив необходимые операции и загрузив обратно.
А еще вы можете перенести такую базу с сервера на пользовательский ПК с более высокой производительностью на ядро и еще более ускорив выполнение нужных операций.
Поэтому, если вы используете базу единолично, то файловый режим – это то, что доктор прописал. И именно в файловый режим мы всегда выгружаем тестовые базы и базы для разработки, несмотря на наличие севера. Потому что быстрее, сильно быстрее.
Но есть и иная сторона медали, общий доступ к файловой базе осуществляется путем разделения доступа к файлу базы и первое с чем вы столкнетесь – это блокировки. При совместной работе производительность файлового варианта резко падает, поэтому общие рекомендации – это не более 3-5 пользователей.
Второе ограничение – это размер базы, по мере роста которой работа в многопользовательском файловом режиме будет все менее комфортной. Это связано с тем, что по сети приходится гонять большой объем данных, что упирается в производительность дисковой и сетевой подсистем.
В эпоху жестких дисков таким порогом был размер примерно в 4 ГБ, в эпоху SSD более-менее комфортно жить в файловой можно до 10-12 ГБ.
Но здесь есть еще один «чит» - публикация на веб-сервере. В таком режиме работы модуль расширения веб-сервера выполняет серверный код, а тонкий клиент или браузер – клиентскую часть кода.
При этом есть одна тонкость, модуль расширения веб-сервера в файловом режиме однопоточен. Т.е. все запросы клиентов ставятся в единую очередь. При этом вопрос блокировок отпадает сам собой.
Но очередь – скажете вы. И что, что очередь? Еще раз смотрим на разницу в производительности и понимаем, что до определенного предела производительность файлового режима через веб-сервер позволяет вообще не задумываться об этом моменте. Если очередь обслуживается быстро, то не все равно сколько вас там в этой очереди?
Поэтому сегодня даже в одной сети есть смысл использовать файловую базу сугубо через веб-сервер. Это позволяет закрыть потребности 5-10 и даже 15 пользователей простым пользовательским железом, в этом плане вне конкуренции процессоры AMD Ryzen 5/7/9.
Стимулами для перехода на клиент-серверные версии становится рост количества пользователей, когда однопоточный модуль не успевает обрабатывать очередь, рост объема базы, а также необходимость выполнения регламентных заданий и обменов в автоматическом режиме, без активных сеансов пользователя.
Но это уже совсем другой уровень бизнеса и инфраструктуры, да и вообще совсем другая история.
Обсуждение показало, что многие коллеги имеют превратное представление о файловой информационной базе 1С, считая ее пережитком прошлого и вообще сосредоточением всех возможных недостатков платформы.
Однако это далеко не так, и в данной заметке мы расскажем почему.
Что собой представляет файловая база? Это собственный формат базы данных от 1С, который всю необходимую информацию хранит в одном единственном файле 1Cv8.1CD, кроме него в папке с базой находятся вспомогательные файлы, но никакой ценности они не несут, все нужное сосредоточено в единственном файле.
Файл имеет страничную структуру и может содержать 2^32-1 страницу размером 4 КБ, что ограничивает общий объем файла базы размеров в 16 ТБ. При этом, в силу внутреннего устройства действует дополнительное ограничение в размере 4 ГБ на размер внутренней таблицы файла.
Начиная с версии 8.3.8 можно менять размер страницы с 4 КБ до 64 КБ, что позволяет увеличить лимит размера внутренней таблицы до 6 ГБ.
Что касается скорости работы, то при прочих равных файловая база всегда работает быстрее клиент-серверной, быстрее в несколько раз. В этом может легко убедиться каждый при помощи теста Гилева. В результате нашего экспресс-теста была получена трехкратная разница.
Как это можно использовать? Если у вас есть тяжелые задачи, требующие преимущественно однопоточного, монопольного доступа, то вы можете радикально их ускорить, выгрузив клиент-серверную базу в файловую, выполнив необходимые операции и загрузив обратно.
А еще вы можете перенести такую базу с сервера на пользовательский ПК с более высокой производительностью на ядро и еще более ускорив выполнение нужных операций.
Поэтому, если вы используете базу единолично, то файловый режим – это то, что доктор прописал. И именно в файловый режим мы всегда выгружаем тестовые базы и базы для разработки, несмотря на наличие севера. Потому что быстрее, сильно быстрее.
Но есть и иная сторона медали, общий доступ к файловой базе осуществляется путем разделения доступа к файлу базы и первое с чем вы столкнетесь – это блокировки. При совместной работе производительность файлового варианта резко падает, поэтому общие рекомендации – это не более 3-5 пользователей.
Второе ограничение – это размер базы, по мере роста которой работа в многопользовательском файловом режиме будет все менее комфортной. Это связано с тем, что по сети приходится гонять большой объем данных, что упирается в производительность дисковой и сетевой подсистем.
В эпоху жестких дисков таким порогом был размер примерно в 4 ГБ, в эпоху SSD более-менее комфортно жить в файловой можно до 10-12 ГБ.
Но здесь есть еще один «чит» - публикация на веб-сервере. В таком режиме работы модуль расширения веб-сервера выполняет серверный код, а тонкий клиент или браузер – клиентскую часть кода.
При этом есть одна тонкость, модуль расширения веб-сервера в файловом режиме однопоточен. Т.е. все запросы клиентов ставятся в единую очередь. При этом вопрос блокировок отпадает сам собой.
Но очередь – скажете вы. И что, что очередь? Еще раз смотрим на разницу в производительности и понимаем, что до определенного предела производительность файлового режима через веб-сервер позволяет вообще не задумываться об этом моменте. Если очередь обслуживается быстро, то не все равно сколько вас там в этой очереди?
Поэтому сегодня даже в одной сети есть смысл использовать файловую базу сугубо через веб-сервер. Это позволяет закрыть потребности 5-10 и даже 15 пользователей простым пользовательским железом, в этом плане вне конкуренции процессоры AMD Ryzen 5/7/9.
Стимулами для перехода на клиент-серверные версии становится рост количества пользователей, когда однопоточный модуль не успевает обрабатывать очередь, рост объема базы, а также необходимость выполнения регламентных заданий и обменов в автоматическом режиме, без активных сеансов пользователя.
Но это уже совсем другой уровень бизнеса и инфраструктуры, да и вообще совсем другая история.
1👍9👌6🔥3👀2
Установка и настройка Hyper-V в Server Core 2025 с управлением через Windows Admin Center
Бесплатный Hyper-V Server пользовался популярностью у администраторов, работающих в экосистеме Windows, но Microsoft отказалась от этого продукта после выпуска Hyper-V Server 2019, и его поддержка истекает в 2029 году.
Но сама технология Hyper-V осталась доступна и ее можно установить как роль Windows Server. Хорошей альтернативой будет установка роли Hyper-V на Windows Server Core о которой мы расскажем в данной статье.
Но начнем мы с лицензирования Windows Server, с выходом Windows Server 2016 применяется новая схема лицензирования: по физическим ядрам процессора. Минимальное количество лицензий: 8 на процессор и 16 на сервер.
Что касается прав на виртуализацию, то лицензия Standard позволяет запустить 2 виртуальных экземпляра Windows Server при условии, что хост используется только для обслуживания работы виртуальных машин.
Если же на хосте поднята любая другая роль Windows Server, то вы вправе запустить только одну виртуальную машину Windows Server.
Для запуска большего количества виртуальных машин вы должны снова покрыть лицензиями все процессорные ядра, после чего получите право на запуск еще 2 экземпляров. Если гостевые машины работают на Linux (или иной ОС), это ограничение на них не распространяется.
Таким образом, если вы используете виртуализированные экземпляры Windows, то финансово вы ничего не теряете по сравнению с Hyper-V сервер, потому что там действуют точно такие же правила лицензирования.
А при использовании редакции Datacenter ограничений на количество запущенных гостевых систем нет.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastroyka-hyper-v-2025-server-core-s-upravleniem-windows-admin-center/
Бесплатный Hyper-V Server пользовался популярностью у администраторов, работающих в экосистеме Windows, но Microsoft отказалась от этого продукта после выпуска Hyper-V Server 2019, и его поддержка истекает в 2029 году.
Но сама технология Hyper-V осталась доступна и ее можно установить как роль Windows Server. Хорошей альтернативой будет установка роли Hyper-V на Windows Server Core о которой мы расскажем в данной статье.
Но начнем мы с лицензирования Windows Server, с выходом Windows Server 2016 применяется новая схема лицензирования: по физическим ядрам процессора. Минимальное количество лицензий: 8 на процессор и 16 на сервер.
Что касается прав на виртуализацию, то лицензия Standard позволяет запустить 2 виртуальных экземпляра Windows Server при условии, что хост используется только для обслуживания работы виртуальных машин.
Если же на хосте поднята любая другая роль Windows Server, то вы вправе запустить только одну виртуальную машину Windows Server.
Для запуска большего количества виртуальных машин вы должны снова покрыть лицензиями все процессорные ядра, после чего получите право на запуск еще 2 экземпляров. Если гостевые машины работают на Linux (или иной ОС), это ограничение на них не распространяется.
Таким образом, если вы используете виртуализированные экземпляры Windows, то финансово вы ничего не теряете по сравнению с Hyper-V сервер, потому что там действуют точно такие же правила лицензирования.
А при использовании редакции Datacenter ограничений на количество запущенных гостевых систем нет.
✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastroyka-hyper-v-2025-server-core-s-upravleniem-windows-admin-center/
👍20❤1
Леса, домены и их хозяева
В обсуждении отдельные участники стали высказывать мнение, что утверждение о том, что все доменные контроллеры равнозначны неверно и есть мол самые-самые главные. В подтверждение приводя одну частную, можно даже сказать вырожденную ситуацию.
Но о ней позже. А пока что вспомним структуру AD, многие сразу ассоциируют ее со словом домен, однако это неверно. Верхним уровнем иерархии AD является лес, в котором уже располагаются домены. Первый созданный в лесу домен является корневым.
Что это значит? Что именно он содержит двух хозяев уровня леса: хозяина схемы и хозяина именования доменов. И если потеря всех контроллеров домена ведет к утере домена, то потеря всех контроллеров корневого домена ведет к утере леса.
В тоже время не один из хозяев не хранит уникальные данные и хозяин схемы не исключение, копия схемы присутствует на любом контроллере домена, в т.ч. и в доменах не являющихся корневыми, но вносить в нее изменения может лишь хозяин.
Почему мы не можем захватить роль хозяина схемы произвольным контроллером? А потому что в лесу может быть только один хозяин и иерархию леса обслуживает корневой домен. Поэтому «лесные» хозяева ограничены пропиской только в пределах корневого домена.
Что касается остальных хозяев, то они в каждом домене свои, в лице целых трех штук, правда один из них фактически бесполезен, если мы в соответствии с фактическими рекомендациями делаем каждый контроллер глобальным каталогом.
Глобальный каталог, напоминаем, хранит все объекты леса и реплицирует их с другими глобальными каталогами. Контроллер, не являющийся глобальным каталогом, хранит и реплицирует объекты только своего домена.
А теперь про «вывод» отдельного домена, не являющегося корневым, из леса. Сразу говорим, что так делать нельзя. Архитектура Active Directory этого не позволяет. Именно архитектура, а не отсутствие пресловутого хозяина схемы.
Потому что если мы технически отключим от общей инфраструктуры такой домен, то копия схемы у нас все равно будет, она есть на любом контроллере. И технически мы можем назначить нового хозяина.
Но хозяин схемы – уровень леса, а домен не является корневым. Т.е. уже на этом этапе возникает понимание, что мы в лесу не самые главные и сделать такого не можем. Но не потому, что контроллерам не хватает каких-то данных, а потому что нельзя. Нет таких полномочий.
Но допустим, мы это ограничение как-то обойдем и при наличии хоть одного глобального каталога мы можем вообще поднять копию леса и назначить себя в нем самыми главными.
Чем это чревато – объяснять не нужно. Потому что будь такое возможно, то каждый поверивший в себя суслик в самом задрипанном филиале мог бы натворить таких дел, что мама не горюй.
Поэтому заведовать операциями уровня леса – привилегия корневого домена и его утрата приводит к утрате леса, хотя другие глобальные каталоги будут содержать всю полноту информации. Но в данном случае речь идет не о наличии информации, а о сохранении целостности и области доверия уровня леса, что при отсутствии корневого домена не может быть реализовано.
Проще говоря, если отойти от этого подхода, то, как мы показали выше, никто не мешает бесконтрольно наплодить клоны лесов со всеми вытекающими. Ровно по той же причине мы теряем домен при утрате всех его контроллеров, хотя все данные этого домена есть на любом глобальном каталоге в лесу.
В обсуждении отдельные участники стали высказывать мнение, что утверждение о том, что все доменные контроллеры равнозначны неверно и есть мол самые-самые главные. В подтверждение приводя одну частную, можно даже сказать вырожденную ситуацию.
Но о ней позже. А пока что вспомним структуру AD, многие сразу ассоциируют ее со словом домен, однако это неверно. Верхним уровнем иерархии AD является лес, в котором уже располагаются домены. Первый созданный в лесу домен является корневым.
Что это значит? Что именно он содержит двух хозяев уровня леса: хозяина схемы и хозяина именования доменов. И если потеря всех контроллеров домена ведет к утере домена, то потеря всех контроллеров корневого домена ведет к утере леса.
В тоже время не один из хозяев не хранит уникальные данные и хозяин схемы не исключение, копия схемы присутствует на любом контроллере домена, в т.ч. и в доменах не являющихся корневыми, но вносить в нее изменения может лишь хозяин.
Почему мы не можем захватить роль хозяина схемы произвольным контроллером? А потому что в лесу может быть только один хозяин и иерархию леса обслуживает корневой домен. Поэтому «лесные» хозяева ограничены пропиской только в пределах корневого домена.
Что касается остальных хозяев, то они в каждом домене свои, в лице целых трех штук, правда один из них фактически бесполезен, если мы в соответствии с фактическими рекомендациями делаем каждый контроллер глобальным каталогом.
Глобальный каталог, напоминаем, хранит все объекты леса и реплицирует их с другими глобальными каталогами. Контроллер, не являющийся глобальным каталогом, хранит и реплицирует объекты только своего домена.
А теперь про «вывод» отдельного домена, не являющегося корневым, из леса. Сразу говорим, что так делать нельзя. Архитектура Active Directory этого не позволяет. Именно архитектура, а не отсутствие пресловутого хозяина схемы.
Потому что если мы технически отключим от общей инфраструктуры такой домен, то копия схемы у нас все равно будет, она есть на любом контроллере. И технически мы можем назначить нового хозяина.
Но хозяин схемы – уровень леса, а домен не является корневым. Т.е. уже на этом этапе возникает понимание, что мы в лесу не самые главные и сделать такого не можем. Но не потому, что контроллерам не хватает каких-то данных, а потому что нельзя. Нет таких полномочий.
Но допустим, мы это ограничение как-то обойдем и при наличии хоть одного глобального каталога мы можем вообще поднять копию леса и назначить себя в нем самыми главными.
Чем это чревато – объяснять не нужно. Потому что будь такое возможно, то каждый поверивший в себя суслик в самом задрипанном филиале мог бы натворить таких дел, что мама не горюй.
Поэтому заведовать операциями уровня леса – привилегия корневого домена и его утрата приводит к утрате леса, хотя другие глобальные каталоги будут содержать всю полноту информации. Но в данном случае речь идет не о наличии информации, а о сохранении целостности и области доверия уровня леса, что при отсутствии корневого домена не может быть реализовано.
Проще говоря, если отойти от этого подхода, то, как мы показали выше, никто не мешает бесконтрольно наплодить клоны лесов со всеми вытекающими. Ровно по той же причине мы теряем домен при утрате всех его контроллеров, хотя все данные этого домена есть на любом глобальном каталоге в лесу.
🔥11👍3❤1
Караван-сарай или величественный собор?
Наткнулся я тут случайно на такой проект, как CBSD, это это обёртка из sh-скриптов (преимущественно) вокруг подсистемы jail, гипервизоров bhyve, QEMU / NVMM и Xen для BSD операционных систем.
Какого-либо нового функционала в ОС на данном этапе не внесено — всё, что могут делать скрипты CBSD, можно сделать командой (командами, десятками, сотнями команд) в CLI через соответствующие утилиты.
Глядя на сайт, я сначала подумал, что это еще один заброшенный проект десятилетней давности, но нет, проект жив и даже куда-то там барахтается…
При том, что на дворе 2026 год и в мире Linux давно есть мощные и удобные продукты виртуализации, такие как Proxmox.
И здесь снова и снова вспоминаешь старое высказывание разработчиков FreеBSD про караван-сарайный принцип разработки Linux, где систему могут дорабатывать все, кто не лень, в противопоставление которому ставились принципы разработки FreeBSD, которую они сравнивали с величественным собором, который возводит небольшая группа архитекторов.
Время расставило все на свои места и Linux из караван-сарая превратился в современный технопарк, а величественный собор так и стоит недостроенным.
При этом за последние 10-15 лет FreeBSD серьезно утратила позиции превратившись в ОС для энтузиастов и маргиналов. Ну и то место, где код можно взять и ничего назад не отдавать.
И все эти заявления, мол BSD используется в macOS, PlayStation, Juniper, NetApp и т.д. выглядят нелепо и смешно, на уровне школьных разборок: «а у меня брат – каратист».
Действительно, кивать на более успешные проекты можно только в отсутствие собственных достижений. Тем более, что все вышеперечисленное – закрытые коммерческие ОС и никто не знает сколько там чего от FreeBSD и насколько это переписано.
А со своим там действительно все плохо, на попытку разработать собственную графическую оболочку с использованием только BSD технологий - Lumina без слез не глянешь.
С доставшейся по наследству ZFS тоже приключилась неприятность, так как из всех вариаций ZFS наиболее активно развивалась ZFS on Linux, то в 2018 году было принято решение, что новая версия OpenZFS 2.0 будет базироваться на кодовой базе для Linux и уже из нее портироваться на другие системы.
Ну и наконец старая история с использованием кода BSD в стеке TCP/IP Windows, которую можно охарактеризовать словами: слышал звон, да не знаю где он.
При выпуске на рынок Windows 3.11 Microsoft потребовалось добавить туда поддержку TCP/IP, а так как собственный стек еще был в разработке, то было лицензировано решение от компании Spider Systems, которое было написано с применением кода FreeBSD. С ним же в Windows попали основанные на коде BSD утилиты, предназначенные для нового стека ftp, rcp и rsh и т.п.
Но у стека Spider был один существенный недостаток, он был завязан на собственную среду STREAMS, которую тоже пришлось портировать на Windows и нести связанные с ней накладные расходы.
Собственный стек TCP/IP Microsoft, созданный с нуля, вышел в конце 1994 года и поставлялся с Windows NT, а также позже вошел в состав Windows 95.
Но, несмотря на новый стек, часть утилит переписывать не стали и оставили прежними. Действительно, зачем переписывать клиент FTP если он хорошо работает и законным образом лицензирован? Но именно последний момент, а именно отсылка к лицензии BSD и дала повод различным досужим теориям о BSD стеке TCP/IP в Windows.
А мы еще раз глянем на картинку выше: справа величественный собор, слева – караван-сарай. Не перепутай!
Наткнулся я тут случайно на такой проект, как CBSD, это это обёртка из sh-скриптов (преимущественно) вокруг подсистемы jail, гипервизоров bhyve, QEMU / NVMM и Xen для BSD операционных систем.
Какого-либо нового функционала в ОС на данном этапе не внесено — всё, что могут делать скрипты CBSD, можно сделать командой (командами, десятками, сотнями команд) в CLI через соответствующие утилиты.
Глядя на сайт, я сначала подумал, что это еще один заброшенный проект десятилетней давности, но нет, проект жив и даже куда-то там барахтается…
При том, что на дворе 2026 год и в мире Linux давно есть мощные и удобные продукты виртуализации, такие как Proxmox.
И здесь снова и снова вспоминаешь старое высказывание разработчиков FreеBSD про караван-сарайный принцип разработки Linux, где систему могут дорабатывать все, кто не лень, в противопоставление которому ставились принципы разработки FreeBSD, которую они сравнивали с величественным собором, который возводит небольшая группа архитекторов.
Время расставило все на свои места и Linux из караван-сарая превратился в современный технопарк, а величественный собор так и стоит недостроенным.
При этом за последние 10-15 лет FreeBSD серьезно утратила позиции превратившись в ОС для энтузиастов и маргиналов. Ну и то место, где код можно взять и ничего назад не отдавать.
И все эти заявления, мол BSD используется в macOS, PlayStation, Juniper, NetApp и т.д. выглядят нелепо и смешно, на уровне школьных разборок: «а у меня брат – каратист».
Действительно, кивать на более успешные проекты можно только в отсутствие собственных достижений. Тем более, что все вышеперечисленное – закрытые коммерческие ОС и никто не знает сколько там чего от FreeBSD и насколько это переписано.
А со своим там действительно все плохо, на попытку разработать собственную графическую оболочку с использованием только BSD технологий - Lumina без слез не глянешь.
С доставшейся по наследству ZFS тоже приключилась неприятность, так как из всех вариаций ZFS наиболее активно развивалась ZFS on Linux, то в 2018 году было принято решение, что новая версия OpenZFS 2.0 будет базироваться на кодовой базе для Linux и уже из нее портироваться на другие системы.
Ну и наконец старая история с использованием кода BSD в стеке TCP/IP Windows, которую можно охарактеризовать словами: слышал звон, да не знаю где он.
При выпуске на рынок Windows 3.11 Microsoft потребовалось добавить туда поддержку TCP/IP, а так как собственный стек еще был в разработке, то было лицензировано решение от компании Spider Systems, которое было написано с применением кода FreeBSD. С ним же в Windows попали основанные на коде BSD утилиты, предназначенные для нового стека ftp, rcp и rsh и т.п.
Но у стека Spider был один существенный недостаток, он был завязан на собственную среду STREAMS, которую тоже пришлось портировать на Windows и нести связанные с ней накладные расходы.
Собственный стек TCP/IP Microsoft, созданный с нуля, вышел в конце 1994 года и поставлялся с Windows NT, а также позже вошел в состав Windows 95.
Но, несмотря на новый стек, часть утилит переписывать не стали и оставили прежними. Действительно, зачем переписывать клиент FTP если он хорошо работает и законным образом лицензирован? Но именно последний момент, а именно отсылка к лицензии BSD и дала повод различным досужим теориям о BSD стеке TCP/IP в Windows.
А мы еще раз глянем на картинку выше: справа величественный собор, слева – караван-сарай. Не перепутай!
👍14👎5❤4
Ubuntu 26.10 прекращает поддержку Btrfs, XFS и ZFS для каталога /boot при включённом Secure Boot
🙎♂️ Автор: Joey Sneddon
Компания Canonical изменила процедуру загрузки Ubuntu 26.10 на системах с включённым Secure Boot, чтобы сократить поверхность атаки (attack surface) на этапе начальной загрузки.
Подписанная сборка загрузчика GRUB в Ubuntu 26.10, которая используется исключительно при активном Secure Boot, больше не поддерживает размещение каталога
Кроме того, из этой сборки удалена поддержка файловой системы HFS+, схемы разметки Apple Partition Map (APM), а также модулей загрузки фоновых изображений в форматах JPEG и PNG.
Поскольку загрузчику GRUB необходим доступ к каталогу
В то же время при включённом Secure Boot Ubuntu 26.10 по-прежнему поддерживает
▫️ext4;
▫️FAT (включая системный раздел EFI);
▫️ISO9660 (для загрузки с CD/DVD-носителей);
▫️Squashfs (для snap-пакетов).
Если же режим Secure Boot отключён, загружается полная сборка GRUB без функциональных ограничений. Это означает, что любые нестандартные конфигурации
🔸 Зачем Canonical пошла на эти изменения?
Canonical анонсировала планы по облегчению (урезанию) кодовой базы GRUB ещё в начале этого года. Реакция сообщества тогда оказалась, мягко говоря, прохладной: пользователи со специфическими схемами разбивки дисков (некоторые из которых ранее настраивались через экспериментальные опции официального установщика) были крайне недовольны перспективой потери работоспособности своих систем.
Именно поэтому Canonical решила внедрить данное изменение в промежуточном выпуске сразу после LTS-релиза. Пользователи, которым критически необходимы как включённый Secure Boot, так и полный набор функций GRUB, могут оставаться на Ubuntu 26.04 LTS (эта версия обеспечивается поддержкой до 2036 года в рамках подписки Ubuntu Pro или до 2041 года с пакетом Legacy Add-on).
❗️Главная цель нововведения — информационная безопасность.
GRUB находится на самых ранних этапах цепочки доверенной загрузки (boot chain) Ubuntu. При стандартной загрузке с Secure Boot микропрограмма материнской платы (UEFI) передаёт управление подписанному загрузочному коду shim, который проверяет цифровую подпись и запускает бинарник GRUB. Далее встроенные в GRUB парсеры анализируют разметку диска и файловые структуры, чтобы найти файл ядра Linux и передать ему управление.
Однако именно эти парсеры файловых систем за последние годы стали источником множества критических уязвимостей, позволявших обойти Secure Boot (а развитие LLM лишь ускоряет поиск и потенциальную эксплуатацию подобных брешей).
Логика инженеров Canonical проста: чем меньше сторонних парсеров выполняется в пространстве загрузчика до передачи управления ядру Linux, тем меньше потенциальных возможностей скомпрометировать цепочку доверия (chain of trust).
🔸Затронет ли это большинство пользователей?
Несмотря на кажущуюся радикальность изменений на машинах с включённым Secure Boot и затрагивают исключительно путь загрузки (boot path).
LVM, программный RAID, шифрование LUKS, Btrfs и ZFS полностью поддерживаются и доступны в Ubuntu 26.10 даже при включённом Secure Boot — но строго после того, как управление передано ядру Linux.
Если вы опасаетесь проблем с совместимостью, перед обновлением до 26.10 обязательно проверьте конфигурацию вашего каталога
Впрочем, подавляющее большинство пользователей данные изменения не затронут: штатный инсталлятор дистрибутива изначально размечает дисковое пространство по стандартной, полностью совместимой с Secure Boot схеме (с выделенным
🙎♂️ Автор: Joey Sneddon
Компания Canonical изменила процедуру загрузки Ubuntu 26.10 на системах с включённым Secure Boot, чтобы сократить поверхность атаки (attack surface) на этапе начальной загрузки.
Подписанная сборка загрузчика GRUB в Ubuntu 26.10, которая используется исключительно при активном Secure Boot, больше не поддерживает размещение каталога
/boot на файловых системах Btrfs, XFS, ZFS, а также поверх томов LVM, шифрования LUKS и программных RAID-массивов (за исключением RAID1).Кроме того, из этой сборки удалена поддержка файловой системы HFS+, схемы разметки Apple Partition Map (APM), а также модулей загрузки фоновых изображений в форматах JPEG и PNG.
Поскольку загрузчику GRUB необходим доступ к каталогу
/boot для считывания ядра и последующей загрузки операционной системы, при нахождении ядра на одной из указанных файловых систем или конфигураций томов GRUB не сможет их прочитать, и система просто не загрузится.В то же время при включённом Secure Boot Ubuntu 26.10 по-прежнему поддерживает
/boot на:▫️ext4;
▫️FAT (включая системный раздел EFI);
▫️ISO9660 (для загрузки с CD/DVD-носителей);
▫️Squashfs (для snap-пакетов).
Если же режим Secure Boot отключён, загружается полная сборка GRUB без функциональных ограничений. Это означает, что любые нестандартные конфигурации
/boot и кастомизация интерфейса GRUB (включая графические фоновые заставки) продолжат работать как обычно.🔸 Зачем Canonical пошла на эти изменения?
Canonical анонсировала планы по облегчению (урезанию) кодовой базы GRUB ещё в начале этого года. Реакция сообщества тогда оказалась, мягко говоря, прохладной: пользователи со специфическими схемами разбивки дисков (некоторые из которых ранее настраивались через экспериментальные опции официального установщика) были крайне недовольны перспективой потери работоспособности своих систем.
Именно поэтому Canonical решила внедрить данное изменение в промежуточном выпуске сразу после LTS-релиза. Пользователи, которым критически необходимы как включённый Secure Boot, так и полный набор функций GRUB, могут оставаться на Ubuntu 26.04 LTS (эта версия обеспечивается поддержкой до 2036 года в рамках подписки Ubuntu Pro или до 2041 года с пакетом Legacy Add-on).
❗️Главная цель нововведения — информационная безопасность.
GRUB находится на самых ранних этапах цепочки доверенной загрузки (boot chain) Ubuntu. При стандартной загрузке с Secure Boot микропрограмма материнской платы (UEFI) передаёт управление подписанному загрузочному коду shim, который проверяет цифровую подпись и запускает бинарник GRUB. Далее встроенные в GRUB парсеры анализируют разметку диска и файловые структуры, чтобы найти файл ядра Linux и передать ему управление.
Однако именно эти парсеры файловых систем за последние годы стали источником множества критических уязвимостей, позволявших обойти Secure Boot (а развитие LLM лишь ускоряет поиск и потенциальную эксплуатацию подобных брешей).
Логика инженеров Canonical проста: чем меньше сторонних парсеров выполняется в пространстве загрузчика до передачи управления ядру Linux, тем меньше потенциальных возможностей скомпрометировать цепочку доверия (chain of trust).
🔸Затронет ли это большинство пользователей?
Несмотря на кажущуюся радикальность изменений на машинах с включённым Secure Boot и затрагивают исключительно путь загрузки (boot path).
LVM, программный RAID, шифрование LUKS, Btrfs и ZFS полностью поддерживаются и доступны в Ubuntu 26.10 даже при включённом Secure Boot — но строго после того, как управление передано ядру Linux.
Если вы опасаетесь проблем с совместимостью, перед обновлением до 26.10 обязательно проверьте конфигурацию вашего каталога
/boot на соответствие списку поддерживаемых файловых систем.Впрочем, подавляющее большинство пользователей данные изменения не затронут: штатный инсталлятор дистрибутива изначально размечает дисковое пространство по стандартной, полностью совместимой с Secure Boot схеме (с выделенным
/boot или корнем на ext4/FAT).👍9❤3👎3
Роутеры Mikrotik и Wi-Fi
В комментариях некоторые читатели удивились, мол почему мы назвали «народными» роутеры серии L009, ведь есть же практически такой же по цене hAP ax3 у которого двухдиапазонный современный Wi-Fi.
Да, это так, только вот практического толку в этом немного и это давно ни для кого не секрет. Решения Mikrotik в области беспроводной связи всегда отличались странным подходом и крайне специфичной реализацией.
И если можно сказать, что роутеры латышам удались отлично, то также честно можно сказать, что с Wi-Fi у них (не считая мосты) – полный провал.
Нет, если вам нужно просто покрыть некоторое помещение, чтобы телефончики с него выходили в интернет, но не более - Mikrotik подойдет, в остальном – лучше даже не пытайтесь.
В устройствах «классической» линейки вызывало недоумение само применяемое оборудование, которое было устаревшим еще в момент его выхода на рынок. А все потому, что инженеры Mikrotik шли по пути наименьшего сопротивления и использовали для Wi-Fi то, что уже встроено в SoC.
Да, это положительно сказывалось на стоимости устройств, но фактически означало что Wi-Fi там просто чтобы был, для галочки. Хотя, как мне кажется, потребитель бы с радостью доплатил за модели с хорошим Wi-Fi.
Кстати, по тому же пути они пошли и в линейке L009, странная конфигурация Wi-Fi в нем (только 2,4 ГГц, зато AX), обусловлена наличием такого беспроводного контроллера в SoC, ну а раз он есть, то не пропадать же добру.
И вот в новых ARМ моделях появилось вроде бы адекватное и современное железо, те же ax2/ax3 имеют на борту производительный контроллер 802.11ax Qualcomm и, казалось бы, дело должно пойти на лад.
Но взять хорошее железо не означает получить хороший результат. Неумелый повар из отличных продуктов точно также сварганит несъедобное хрючево, ровно, как и наоборот.
Поэтому чуда не случилось, да Wi-Fi в новых роутерах стал повеселее, но и только. Да, вроде работает, вроде что-то передает, но любой бытовой аналог среднего ценового диапазона делает его с закрытыми глазами.
Ходят слухи, что все это потому, что мы не умеем их настраивать. А настроек там много, очень много, по идее, если их освоить мы должны получить космический звездолет, который унесет наш Wi-Fi на недосягаемую высоту.
Но ни один гуру так и не раскрыл секрета этих настроек, которые наверно представляют страшную тайну и шепотом передаются на смертном одре от отца к сыну…
Я честно пытался дать вторую жизнь Wi-Fi на hAP ax2 и настроить хотя бы устойчивую работу со скоростью тарифа провайдера – 100 Мбит/с, что для AC/AX вообще довольно смешная цифра.
Но увы, не осилил и под напором домашних пошел и купил два Xiaomi Router AX3000T, по цене примерно по 3000 рублей, что в пять раз дешевле моего ax2 в современных ценах.
Китайцы просто заработали из коробки обеспечив по квартире стабильную связь до 450 Мбит/с по квартире, что для AC клиентов очень неплохо. А домашние спросили почему нельзя было так сделать сразу.
На этом вопрос с Wi-Fi для дома и небольшого офиса, куда позиционирует эти устройства Mikrotik, для меня закрыт окончательно и бесповоротно. Не мучайте себя и окружающих, пойдите купите нормальное Wi-Fi устройство, их на рынке много и цены весьма демократичные.
В корпоративной среде тоже все как-то не очень, CAPsMAN назвать беспроводным контроллером можно с очень большой натяжкой и только если ты не пробовал ничего слаще морковки.
Нет, когда-то это была прорывная в своем сегменте технология, но сегодня это просто средство быстро раскидать настройки по точкам, таким же бестолковым как остальное беспроводное оборудование Mikrotik.
А чтобы посмотреть, как должен выглядеть и что уметь современный контроллер беспроводной сети посмотрите на Uni-Fi или Omada, последний вообще можно назвать бюджетным, поддерживающие его точки доступа TP-Link относятся к среднему ценовому диапазону.
Поэтому при рассмотрение оборудования Mikrotik мы не берем во внимание Wi-Fi, потому что мы покупаем эти устройства не для этого, а для работы в роли роутера под управлением RouterOS, что у них получается наилучшим образом.
В комментариях некоторые читатели удивились, мол почему мы назвали «народными» роутеры серии L009, ведь есть же практически такой же по цене hAP ax3 у которого двухдиапазонный современный Wi-Fi.
Да, это так, только вот практического толку в этом немного и это давно ни для кого не секрет. Решения Mikrotik в области беспроводной связи всегда отличались странным подходом и крайне специфичной реализацией.
И если можно сказать, что роутеры латышам удались отлично, то также честно можно сказать, что с Wi-Fi у них (не считая мосты) – полный провал.
Нет, если вам нужно просто покрыть некоторое помещение, чтобы телефончики с него выходили в интернет, но не более - Mikrotik подойдет, в остальном – лучше даже не пытайтесь.
В устройствах «классической» линейки вызывало недоумение само применяемое оборудование, которое было устаревшим еще в момент его выхода на рынок. А все потому, что инженеры Mikrotik шли по пути наименьшего сопротивления и использовали для Wi-Fi то, что уже встроено в SoC.
Да, это положительно сказывалось на стоимости устройств, но фактически означало что Wi-Fi там просто чтобы был, для галочки. Хотя, как мне кажется, потребитель бы с радостью доплатил за модели с хорошим Wi-Fi.
Кстати, по тому же пути они пошли и в линейке L009, странная конфигурация Wi-Fi в нем (только 2,4 ГГц, зато AX), обусловлена наличием такого беспроводного контроллера в SoC, ну а раз он есть, то не пропадать же добру.
И вот в новых ARМ моделях появилось вроде бы адекватное и современное железо, те же ax2/ax3 имеют на борту производительный контроллер 802.11ax Qualcomm и, казалось бы, дело должно пойти на лад.
Но взять хорошее железо не означает получить хороший результат. Неумелый повар из отличных продуктов точно также сварганит несъедобное хрючево, ровно, как и наоборот.
Поэтому чуда не случилось, да Wi-Fi в новых роутерах стал повеселее, но и только. Да, вроде работает, вроде что-то передает, но любой бытовой аналог среднего ценового диапазона делает его с закрытыми глазами.
Ходят слухи, что все это потому, что мы не умеем их настраивать. А настроек там много, очень много, по идее, если их освоить мы должны получить космический звездолет, который унесет наш Wi-Fi на недосягаемую высоту.
Но ни один гуру так и не раскрыл секрета этих настроек, которые наверно представляют страшную тайну и шепотом передаются на смертном одре от отца к сыну…
Я честно пытался дать вторую жизнь Wi-Fi на hAP ax2 и настроить хотя бы устойчивую работу со скоростью тарифа провайдера – 100 Мбит/с, что для AC/AX вообще довольно смешная цифра.
Но увы, не осилил и под напором домашних пошел и купил два Xiaomi Router AX3000T, по цене примерно по 3000 рублей, что в пять раз дешевле моего ax2 в современных ценах.
Китайцы просто заработали из коробки обеспечив по квартире стабильную связь до 450 Мбит/с по квартире, что для AC клиентов очень неплохо. А домашние спросили почему нельзя было так сделать сразу.
На этом вопрос с Wi-Fi для дома и небольшого офиса, куда позиционирует эти устройства Mikrotik, для меня закрыт окончательно и бесповоротно. Не мучайте себя и окружающих, пойдите купите нормальное Wi-Fi устройство, их на рынке много и цены весьма демократичные.
В корпоративной среде тоже все как-то не очень, CAPsMAN назвать беспроводным контроллером можно с очень большой натяжкой и только если ты не пробовал ничего слаще морковки.
Нет, когда-то это была прорывная в своем сегменте технология, но сегодня это просто средство быстро раскидать настройки по точкам, таким же бестолковым как остальное беспроводное оборудование Mikrotik.
А чтобы посмотреть, как должен выглядеть и что уметь современный контроллер беспроводной сети посмотрите на Uni-Fi или Omada, последний вообще можно назвать бюджетным, поддерживающие его точки доступа TP-Link относятся к среднему ценовому диапазону.
Поэтому при рассмотрение оборудования Mikrotik мы не берем во внимание Wi-Fi, потому что мы покупаем эти устройства не для этого, а для работы в роли роутера под управлением RouterOS, что у них получается наилучшим образом.
1👍43👎10💯5👀4🔥2
Родина слышит
Данная заметка написана на злобу дня, в противовес расхожему мнению, что через отечественные сертификаты нас всех расшифруют и… В общем, отправят пилить лобзиком ангарскую сосну на свежем морозном воздухе.
На самом деле никто никогда не скрывал, что отечественный УЦ предназначен в первую очередь для крупных игроков: финтех, госы, электронные сервисы, которые в 2022 чуть было не остались без валидных сертификатов.
Но неокрепшие умы и примкнувшие к ним лица старательно разгоняют тему, что мол отечественный УЦ — это первый шаг к государственному MitM, когда весь трафик расшифруют и никому потом мало не покажется.
Но никто так и не потрудился обосновать – зачем? Какая цель всего этого действа? И кто будет всем этим заниматься?
Ведь расшифровать трафик – это только начало. Его надо проанализировать и выявить… Что выявить? Да пес его знает. Адепты данной теории заговора не склонны к логике, они просто эмоционально нагнетают – могут, значит сделают!
А теперь я предлагаю каждому тупо собрать трафик домашней сети за сутки и вдумчиво его проанализировать. Когда вы скажете – нафиг нужно? Через полчаса? Час? А там еще этого трафика вагон и маленькая тележка. И, самое главное, что это даст?
По факту занятие это чудовищно дорогое и столь же чудовищно неэффективное. Ибо 99,5% трафика – это хлеб и зрелища, крайне далекие от интересов «товарища Майора».
А теперь подумаем, если некто Имярек засветился у т. Майора, то он явно засветился в публичном поле и если его личность неизвестна, то какой смысл в расшифровке трафика? И даже если мы смогли локализовать его до города, то все равно объем информации будет фактически неподъемным для любого регионального отдела хоть МВД, хоть ФСБ, нет там столько людей.
Но если наш Имярек засветился в соцсети, форуме или ином ресурсе, владелец которого гражданин РФ, то органы просто пошлют к нему запрос, в котором попросят выдать всю информацию по Имяреку.
И это не только IP, но и временная активность, социальная активность и т.д. Т.е. когда Имярек заходит на ресурс, кого он лайкает, кто лайкает его, на кого он подписан, кто подписан на него и т.д. и т.п.
А дальше включается привычная любому оперу отработка связей Имярека. И где-то он да проколется, и цепочка выведет от безликих аккаунтов к реальному человеку, а там снова изучение окружения, поиск слабого звена, и кто-то наконец заговорит. После чего клубочек начнет распутываться в обратном направлении.
Эта методика давно отработана оффлайн, проста, дешева и привычна. А слабое звено найдется всегда. Особенно если утром вас выдернут из постели хмурые мужики в штатском.
И к чему тут расшифровка трафика? Совсем ни к чему. Это сложно и дорого. А тут простая и понятная любому оперу отработка социальных связей.
Ладно, наш Имярек весь такой зашифрованный и нигде не прокололся, ходит только через VPN. Так тут тоже все довольно просто. Видим, что наш пассажир заходил в такое-то время через вот этот сервис на этот ресурс.
После чего снимаем с ТСПУ данные, а кто именно в это время обменивался трафиком с этим ресурсом. Выборка будет большая. Но это не страшно. Берем следующий момент времени и накладываем выборки друг на друга.
И уже через несколько итераций мы фактически получим данного пассажира на блюдечке. А если у него свой VPN-сервер, то срисуют его фактически мгновенно.
А дальше что? Перехватим и расшифруем его трафик? Зачем? Проще просто прийти рано утром, вытащить пассажира из теплой постельки, положить лицом в пол, устроить маски-шоу, дать проникнуться и поговорить по душам.
Если пассажир попался непонятливый, то всегда есть рядом слабое звено – родители, супруга, любовница, кореша и собутыльники. Хороший опер умеет работать с этим материалом.
На крайний случай можно использовать терморектальный криптоанализатор или просто зажать бубенцы дверью. В общем, если личность пассажира установлена, то трафик расшифровывать тем более нет никакого смысла. Есть методы гораздо проще.
Поэтому не надо искать черную кошку в темной комнате, особенно если ее там нет.
Данная заметка написана на злобу дня, в противовес расхожему мнению, что через отечественные сертификаты нас всех расшифруют и… В общем, отправят пилить лобзиком ангарскую сосну на свежем морозном воздухе.
На самом деле никто никогда не скрывал, что отечественный УЦ предназначен в первую очередь для крупных игроков: финтех, госы, электронные сервисы, которые в 2022 чуть было не остались без валидных сертификатов.
Но неокрепшие умы и примкнувшие к ним лица старательно разгоняют тему, что мол отечественный УЦ — это первый шаг к государственному MitM, когда весь трафик расшифруют и никому потом мало не покажется.
Но никто так и не потрудился обосновать – зачем? Какая цель всего этого действа? И кто будет всем этим заниматься?
Ведь расшифровать трафик – это только начало. Его надо проанализировать и выявить… Что выявить? Да пес его знает. Адепты данной теории заговора не склонны к логике, они просто эмоционально нагнетают – могут, значит сделают!
А теперь я предлагаю каждому тупо собрать трафик домашней сети за сутки и вдумчиво его проанализировать. Когда вы скажете – нафиг нужно? Через полчаса? Час? А там еще этого трафика вагон и маленькая тележка. И, самое главное, что это даст?
По факту занятие это чудовищно дорогое и столь же чудовищно неэффективное. Ибо 99,5% трафика – это хлеб и зрелища, крайне далекие от интересов «товарища Майора».
А теперь подумаем, если некто Имярек засветился у т. Майора, то он явно засветился в публичном поле и если его личность неизвестна, то какой смысл в расшифровке трафика? И даже если мы смогли локализовать его до города, то все равно объем информации будет фактически неподъемным для любого регионального отдела хоть МВД, хоть ФСБ, нет там столько людей.
Но если наш Имярек засветился в соцсети, форуме или ином ресурсе, владелец которого гражданин РФ, то органы просто пошлют к нему запрос, в котором попросят выдать всю информацию по Имяреку.
И это не только IP, но и временная активность, социальная активность и т.д. Т.е. когда Имярек заходит на ресурс, кого он лайкает, кто лайкает его, на кого он подписан, кто подписан на него и т.д. и т.п.
А дальше включается привычная любому оперу отработка связей Имярека. И где-то он да проколется, и цепочка выведет от безликих аккаунтов к реальному человеку, а там снова изучение окружения, поиск слабого звена, и кто-то наконец заговорит. После чего клубочек начнет распутываться в обратном направлении.
Эта методика давно отработана оффлайн, проста, дешева и привычна. А слабое звено найдется всегда. Особенно если утром вас выдернут из постели хмурые мужики в штатском.
И к чему тут расшифровка трафика? Совсем ни к чему. Это сложно и дорого. А тут простая и понятная любому оперу отработка социальных связей.
Ладно, наш Имярек весь такой зашифрованный и нигде не прокололся, ходит только через VPN. Так тут тоже все довольно просто. Видим, что наш пассажир заходил в такое-то время через вот этот сервис на этот ресурс.
После чего снимаем с ТСПУ данные, а кто именно в это время обменивался трафиком с этим ресурсом. Выборка будет большая. Но это не страшно. Берем следующий момент времени и накладываем выборки друг на друга.
И уже через несколько итераций мы фактически получим данного пассажира на блюдечке. А если у него свой VPN-сервер, то срисуют его фактически мгновенно.
А дальше что? Перехватим и расшифруем его трафик? Зачем? Проще просто прийти рано утром, вытащить пассажира из теплой постельки, положить лицом в пол, устроить маски-шоу, дать проникнуться и поговорить по душам.
Если пассажир попался непонятливый, то всегда есть рядом слабое звено – родители, супруга, любовница, кореша и собутыльники. Хороший опер умеет работать с этим материалом.
На крайний случай можно использовать терморектальный криптоанализатор или просто зажать бубенцы дверью. В общем, если личность пассажира установлена, то трафик расшифровывать тем более нет никакого смысла. Есть методы гораздо проще.
Поэтому не надо искать черную кошку в темной комнате, особенно если ее там нет.
👎32🤔13💯11👍7🤣6
Что не так со своей почтой?
Последнее время этот вопрос задается постоянно и обычно во внимание берется только техническая сторона. Мол поднять почтовик – дело 15 минут и тут же приводятся варианты реализаций, которых на самом деле множество.
Да, технически поднять свою почту несложно, равно как и прописать все нужные записи, создать политики, подписи и т.д. И все это даже будет работать, на вашей стороне. А вот дальше начинается то, на что вы повлиять не в состоянии.
Это процесс доставки, обеспечить который на приемлемом уровне – это задача со звездочкой. Любой IP-адрес из диапазона массовых хостингов находится у крупных операторов в серой зоне и имеет нулевую репутацию.
Чтобы более-менее с вами «начали разговаривать» необходим долгий и муторный прогрев адреса, причем очень и очень аккуратный.
А если вы пытаетесь отправлять почту с сервера который стоит в домашнем чулане или в офисе, то ваш адрес вообще будет принадлежать пользовательскому диапазону, где почтовых серверов не должно быть вовсе и все они изначально в черных списках.
Нет, попытаться вытащить и прогреть адрес можно, но зачем? Потому что доставка – это процесс, который вы не можете контролировать. Современные сервера не отбивают подозрительные письма с NDR, а тупо отвечают 250 2.0.0 OK: message queued for delivery.
В логах все хорошо, письмо ушло, а вот дальше оно или ложиться в папочку Спам, которую никто не читает, либо вообще растворяется в blackhole. Почему? А просто потому, что принимающей стороне что-то там не понравилось или вообще так сошлись звезды.
А потом менеджер сидит и гадает почему нет реакции на коммерческое предложение, где оплата по счету или почему контрагент не подписывает акты. А контрагент ни сном ни духом, он ничего не получал.
И после того, как в результате такого инцидента сорвется крупный контракт или организация сорвет сроки разговор по поводу «своей почты» будет совершенно иной.
При том реально что-то сделать в этой ситуации нельзя, максимум вы можете достучаться до админов такой же как вы по уровню конторы с собственным почтовиком. Кто-то покрупнее с вами даже разговаривать не станет, не та весовая категория.
Последнее время этот вопрос задается постоянно и обычно во внимание берется только техническая сторона. Мол поднять почтовик – дело 15 минут и тут же приводятся варианты реализаций, которых на самом деле множество.
Да, технически поднять свою почту несложно, равно как и прописать все нужные записи, создать политики, подписи и т.д. И все это даже будет работать, на вашей стороне. А вот дальше начинается то, на что вы повлиять не в состоянии.
Это процесс доставки, обеспечить который на приемлемом уровне – это задача со звездочкой. Любой IP-адрес из диапазона массовых хостингов находится у крупных операторов в серой зоне и имеет нулевую репутацию.
Чтобы более-менее с вами «начали разговаривать» необходим долгий и муторный прогрев адреса, причем очень и очень аккуратный.
А если вы пытаетесь отправлять почту с сервера который стоит в домашнем чулане или в офисе, то ваш адрес вообще будет принадлежать пользовательскому диапазону, где почтовых серверов не должно быть вовсе и все они изначально в черных списках.
Нет, попытаться вытащить и прогреть адрес можно, но зачем? Потому что доставка – это процесс, который вы не можете контролировать. Современные сервера не отбивают подозрительные письма с NDR, а тупо отвечают 250 2.0.0 OK: message queued for delivery.
В логах все хорошо, письмо ушло, а вот дальше оно или ложиться в папочку Спам, которую никто не читает, либо вообще растворяется в blackhole. Почему? А просто потому, что принимающей стороне что-то там не понравилось или вообще так сошлись звезды.
А потом менеджер сидит и гадает почему нет реакции на коммерческое предложение, где оплата по счету или почему контрагент не подписывает акты. А контрагент ни сном ни духом, он ничего не получал.
И после того, как в результате такого инцидента сорвется крупный контракт или организация сорвет сроки разговор по поводу «своей почты» будет совершенно иной.
При том реально что-то сделать в этой ситуации нельзя, максимум вы можете достучаться до админов такой же как вы по уровню конторы с собственным почтовиком. Кто-то покрупнее с вами даже разговаривать не станет, не та весовая категория.
1🤡18👍16🥱2
Базовая настройка роутера MikroTik с RouterOS 7
Роутеры Mikrotik имеют давнюю славу сложных в настройке и это во многом так. Для того, чтобы уверенно чувствовать себя в его интерфейсе нужно обладать уровнем сетевых знаний выше базового, но и предоставляемые возможности для своего ценового диапазона крайне высоки.
В то же время не стоит забегать вперед, потому что начинать нужно всегда с базовых вещей. Сегодня мы пошагово рассмотрим базовую настройку роутеров Mikrotik работающих под управлением RouterOS 7.
Основной особенностью роутеров Mikrotik является то, что все они работают под управлением одной и той же операционной системы RouterOS, а значит и настраиваются полностью одинаково.
Также все модели имеют одинаковые возможности, за исключением наличия определенных аппаратных модулей, например беспроводной сети.
Все современные устройства выпускаются с RouterOS 7 - актуальной версией операционной системы, которая активно развивается и поддерживается.
RouterOS 6 является устаревшей и поддерживается только в части устранения уязвимостей, в данной статье рассматривать ее мы не будем. При необходимости настроить RouterOS 6 обратитесь к материалу:
🔹 Базовая настройка роутера MikroTik
Все настройки в рамках данной статьи мы будем проводить при помощи утилиты WinBox 4, которая в скором времени станет безальтернативной, поддержка классического WinBox 3 будет прекращена в ближайшее время.
Также отдельно будут даны команды для повторения всех описанных действий в терминале.
✅ Читать далее: https://interface31.ru/post/bazovaya-nastroyka-routera-mikrotik-7-winbox-4/
Статья вышла большая и подробная, одних только картинок 60 шт.
Роутеры Mikrotik имеют давнюю славу сложных в настройке и это во многом так. Для того, чтобы уверенно чувствовать себя в его интерфейсе нужно обладать уровнем сетевых знаний выше базового, но и предоставляемые возможности для своего ценового диапазона крайне высоки.
В то же время не стоит забегать вперед, потому что начинать нужно всегда с базовых вещей. Сегодня мы пошагово рассмотрим базовую настройку роутеров Mikrotik работающих под управлением RouterOS 7.
Основной особенностью роутеров Mikrotik является то, что все они работают под управлением одной и той же операционной системы RouterOS, а значит и настраиваются полностью одинаково.
Также все модели имеют одинаковые возможности, за исключением наличия определенных аппаратных модулей, например беспроводной сети.
Все современные устройства выпускаются с RouterOS 7 - актуальной версией операционной системы, которая активно развивается и поддерживается.
RouterOS 6 является устаревшей и поддерживается только в части устранения уязвимостей, в данной статье рассматривать ее мы не будем. При необходимости настроить RouterOS 6 обратитесь к материалу:
🔹 Базовая настройка роутера MikroTik
Все настройки в рамках данной статьи мы будем проводить при помощи утилиты WinBox 4, которая в скором времени станет безальтернативной, поддержка классического WinBox 3 будет прекращена в ближайшее время.
Также отдельно будут даны команды для повторения всех описанных действий в терминале.
✅ Читать далее: https://interface31.ru/post/bazovaya-nastroyka-routera-mikrotik-7-winbox-4/
Статья вышла большая и подробная, одних только картинок 60 шт.
4🔥28👍6👌3🤔1😱1
Использование Routing Rules в роутерах Mikrotik
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через один канал, если неожиданно отключился второй.
Вопрос не праздный, потому как при том же переключении на мобильный интернет неконтролируемый выход в сеть быстро способен исчерпать доступный лимит трафика.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой широкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию – lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной.
Поэтому, если мы не хотим, чтобы при отказе одного провайдера пакет уходил другому, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило lookup-only-in-table.
В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать адреса источника и назначения, а также интерфейс.
В действиях нам также доступны drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.
Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через один канал, если неожиданно отключился второй.
Вопрос не праздный, потому как при том же переключении на мобильный интернет неконтролируемый выход в сеть быстро способен исчерпать доступный лимит трафика.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой широкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию – lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной.
Поэтому, если мы не хотим, чтобы при отказе одного провайдера пакет уходил другому, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило lookup-only-in-table.
В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать адреса источника и назначения, а также интерфейс.
В действиях нам также доступны drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.
Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
👍15❤2
Реальное положение дел в диапазоне 5 ГГц
С этой проблемой сталкивается каждый, кто хоть немного углубляется в беспроводные сети и радиопланирование. С переходом на 5 ГГц кажется, что счастье стало доступно, вот оно, рядом, только протяни руку. Только непересекающиеся каналы, широкие диапазоны.
Но гладко было на бумаге, а на практике… Давайте смотреть. В РФ для диапазона 5 ГГц выделены два несмежных участка — 5150–5350 МГц (U-NII-1 и U-NII-2A) и 5650–5850 МГц (часть U-NII-2C и U-NII-3/ISM). А также 5850–5925 МГц (U-NII-4), который доступен только для стандартов 802.11ax/be.
Сегодня в потребительской электронике преобладает стандарт 802.11aс (Wi-Fi 5) и поэтому, если вы хотите поднять универсальную и совместимую беспроводную сеть, про U-NII-4 забываем минимум лет на пять.
Теперь про U-NII-2A/С – это диапазоны с DFS (Dynamic Frequency Selection), которые делятся с радарами: военными, авиационными, погодными и точки доступа не должны создавать для них помех.
Получив радарный импульс или помеху, похожую на радарный импульс (что в городской застройке не редкость), точка обязана в срок до 10 сек полностью замолчать, допускается экстренная рассылка в течение 200 мс управляющих кадров CSA, которые сообщают клиенту о срочной смене частоты.
Переключившись на другую частоту в DFS диапазоне, точка обязана молчать в течение минуты и сканировать диапазон на предмет сигналов радаров и только убедившись, что их тут нет, она начинает вещание.
Сам канал, на котором был обнаружен радар ставится в бан на 30 минут. И если эта точка осталась в DFS-диапазоне, то канал в 80 МГц тут же разваливается до 40 МГц или вообще 20 МГц, в зависимости от того, какую новую центральную частоту точка выбрала.
Аналогичные проблемы есть и у ISM-канала 165 (5825 МГц), многие устройства попав на него сжимают канал до 20 МГц, так как в U-NII-3 эта частота не входит.
Ну и вишенка на торте – совместимость. В США все указанные каналы разрешены и проблем с устройствами, сертифицированными FCC, не будет. В Европе запрещены каналы U-NII-3/ISM, а также 144 канал U-NII-2C. Китайские устройства массово игнорируют U-NII-2A/С, чтобы не реализовывать поддержку DFS.
Отдельную головную боль доставляют топовые устройства, с поддержкой 802.11d Country Code, обычно это техника Apple и Samsung, но не ограничиваясь ими. Они определяют регион по маякам точек доступа.
И если какая-то точка передала европейский или китайский регион, то клиент тут же включит региональные ограничения. И для этого достаточно всего одной такой точки. Если же точка, типа Mikrotik передает что-то типа superchannel без какой-либо региональной привязки, то такое устройство может включить самые строгие ограничения.
Что мы имеем в сухом остатке? Только U-NII-1, как универсальный и совместимый со всеми диапазон. Плюс U-NII-3, если вы точно уверены, что у вас нет европейских устройств и никакая точка рядом не передает европейский регион.
Про U-NII-2A/С забываем как про страшный сон, равно как и про U-NII-4, либо ставим для последнего отдельную точку для топовых устройств.
✅ Подробнее про частоты и диапазоны можно почитать здесь: https://interface31.ru/post/normativnoe-regulirovanie-wi-fi-v-rf/
С этой проблемой сталкивается каждый, кто хоть немного углубляется в беспроводные сети и радиопланирование. С переходом на 5 ГГц кажется, что счастье стало доступно, вот оно, рядом, только протяни руку. Только непересекающиеся каналы, широкие диапазоны.
Но гладко было на бумаге, а на практике… Давайте смотреть. В РФ для диапазона 5 ГГц выделены два несмежных участка — 5150–5350 МГц (U-NII-1 и U-NII-2A) и 5650–5850 МГц (часть U-NII-2C и U-NII-3/ISM). А также 5850–5925 МГц (U-NII-4), который доступен только для стандартов 802.11ax/be.
Сегодня в потребительской электронике преобладает стандарт 802.11aс (Wi-Fi 5) и поэтому, если вы хотите поднять универсальную и совместимую беспроводную сеть, про U-NII-4 забываем минимум лет на пять.
Теперь про U-NII-2A/С – это диапазоны с DFS (Dynamic Frequency Selection), которые делятся с радарами: военными, авиационными, погодными и точки доступа не должны создавать для них помех.
Получив радарный импульс или помеху, похожую на радарный импульс (что в городской застройке не редкость), точка обязана в срок до 10 сек полностью замолчать, допускается экстренная рассылка в течение 200 мс управляющих кадров CSA, которые сообщают клиенту о срочной смене частоты.
Переключившись на другую частоту в DFS диапазоне, точка обязана молчать в течение минуты и сканировать диапазон на предмет сигналов радаров и только убедившись, что их тут нет, она начинает вещание.
Сам канал, на котором был обнаружен радар ставится в бан на 30 минут. И если эта точка осталась в DFS-диапазоне, то канал в 80 МГц тут же разваливается до 40 МГц или вообще 20 МГц, в зависимости от того, какую новую центральную частоту точка выбрала.
Аналогичные проблемы есть и у ISM-канала 165 (5825 МГц), многие устройства попав на него сжимают канал до 20 МГц, так как в U-NII-3 эта частота не входит.
Ну и вишенка на торте – совместимость. В США все указанные каналы разрешены и проблем с устройствами, сертифицированными FCC, не будет. В Европе запрещены каналы U-NII-3/ISM, а также 144 канал U-NII-2C. Китайские устройства массово игнорируют U-NII-2A/С, чтобы не реализовывать поддержку DFS.
Отдельную головную боль доставляют топовые устройства, с поддержкой 802.11d Country Code, обычно это техника Apple и Samsung, но не ограничиваясь ими. Они определяют регион по маякам точек доступа.
И если какая-то точка передала европейский или китайский регион, то клиент тут же включит региональные ограничения. И для этого достаточно всего одной такой точки. Если же точка, типа Mikrotik передает что-то типа superchannel без какой-либо региональной привязки, то такое устройство может включить самые строгие ограничения.
Что мы имеем в сухом остатке? Только U-NII-1, как универсальный и совместимый со всеми диапазон. Плюс U-NII-3, если вы точно уверены, что у вас нет европейских устройств и никакая точка рядом не передает европейский регион.
Про U-NII-2A/С забываем как про страшный сон, равно как и про U-NII-4, либо ставим для последнего отдельную точку для топовых устройств.
✅ Подробнее про частоты и диапазоны можно почитать здесь: https://interface31.ru/post/normativnoe-regulirovanie-wi-fi-v-rf/
🤔21❤8😢3💯2🤝1