Не было печали – апдейтов накачали
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
В самом разгаре история с крупнейшей компрометацией пользовательского репозитория AUR в Arch Linux, на настоящий момент известно о компрометации 1577 пакетов.
Принцип атаки прост – злоумышленники взяли на себя сопровождение пакетов, оставшихся без сопровождающих, после чего быстро выпустили обновление, в котором пакетам добавили зависимости на вредоносное ПО.
Вредоносное ПО регистрировалось в системе как systemd-сервис с произвольным именем и выглядело как поток ядра, а дальше буквально пылесосило систему и отправляла на сервера злоумышленников все, до чего могла дотянуться: SSH-ключи, учетные данные, секреты из конфигурационных файлов, токенов доступа, историю команд и т.д.
Эта ситуация снова подсвечивает критичность проблемы доверия и атак на цепочки поставки. Особенно если вы используете ПО от «сообщества» и до конца не понимаете, кто его сопровождает и на каких условиях.
🔥23😱14😢4
Почему пакетная система Linux скорее всего доживает последние дни
Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.
Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.
Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.
Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.
Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.
Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.
В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.
Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.
Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.
Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.
А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.
И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.
В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.
Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.
При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.
И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.
Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.
Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.
Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.
Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.
Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.
В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.
Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.
Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.
Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.
А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.
И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.
В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.
Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.
При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.
И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
🤔21👍11🤡8❤7👀1
Пакетный ад сложных проектов с зависимостями
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.
Пакетная система вполне себе стройна, хороша и удобна пока вы не пытаетесь выйти за ее рамки, точнее за рамки базовой системы, которая поддерживается на уровне дистрибутива и является более-менее стабильной и неизменной.
Но как только вы втягивались в какой-то проект со сложными зависимостями, то пакетная система быстро превращалась в пакетный ад.
Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.
Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.
Причем далеко не факт, что библиотека прицепится с первого раза и не придется подбирать версии. В итоге уже сам процесс установки растягивается на полдня и обязательную фиксацию в блокноте чего ты именно там понаставил.
Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.
Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».
Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.
Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.
Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.
Не нашли, попробуем притащить из CPAN и попутно сломаем то, что работало. И снова будем искать, выдумывать, пробовать. В итоге хост через некоторое время превращается в помойку, которую трогать страшно.
И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.
А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».
При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.
В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.
Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.
После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.
👍15❤3👎2🤣2
Атомарность – будущее Linux
Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
Этот вопрос волнует многих, и пользователей и, тем более, администраторов. Давайте попробуем разобраться в чем преимущество атомарности.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍22🤔6👎3❤1🤮1
Не прошло и полгода…
Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений.
При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266
Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.
Совсем не неожиданно, а очень даже наоборот, второй ведущий почтовый Mail.ru прекратил поддержку сторонних почтовых клиентов на бесплатных тарифах. В веб-интерфейсе с почтой можно по-прежнему работать без ограничений.
При этом совсем недавно на аналогичный шаг пошел Яндекс, о чем мы совсем недавно писали: https://t.me/interface31/6266
Какие варианты? Да никаких, достаем кошелек и оплачиваем. Ну или начинаем увлекательный квест под названием «сам себе почтовый хостер», что тоже не самый лучший вариант.
🤣15😁3🤬3
Как правильно работать с резервным копированием в облаке?
25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.
⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.
⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.
⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.
Зарегистрируйтесь, чтобы не пропустить!
⏰ 25 июня в 14:00 (мск)
✅ Зарегистрироваться
Реклама. ООО "МВС ОБЛАЧНЫЕ РЕШЕНИЯ". ИНН 7841468537. erid: 2W5zFH1pTJh
25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.
⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.
⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.
⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.
Зарегистрируйтесь, чтобы не пропустить!
⏰ 25 июня в 14:00 (мск)
✅ Зарегистрироваться
Реклама. ООО "МВС ОБЛАЧНЫЕ РЕШЕНИЯ". ИНН 7841468537. erid: 2W5zFH1pTJh
❤1👍1🔥1🤮1🍌1
Про желания и возможности
В обсуждениях снова и снова возникают вопросы про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Вы именно такой специалист? А что вы до сих пор здесь сидите? Вас ждут великие дела.
В обсуждениях снова и снова возникают вопросы про покупку ресурсов.
Поэтому уделим немного больше внимания этому вопросу. Сразу оговоримся, что все сказанное ниже будет касаться только бизнеса, т.е. деятельности направленной на извлечение прибыли и не касается личных и некоммерческих вопросов.
Любые ресурсы стоят денег. Это могут быть материальные ресурсы: производительность процессора, емкость и скорость памяти, дисков и т.д. Либо нематериальные – стоимость рабочего времени специалистов.
Ресурсы входят в расходную часть бизнеса и должны быть адекватны его доходам. Недостаток какого-либо ресурса также является для бизнеса убыточным или становится узким горлышком бизнес-процессов.
Поэтому если какого-то ресурса не хватает, то его следует докупить. Если вам не хватает грузчиков на склад, то надо нанять дополнительных. Большие очереди в магазинах – нужно поставить вторую кассу.
Если это дорого и не окупит вложенных затрат, то значит оно вам не надо. Скажем, если грузчиков не хватает только в дни прихода товара, то можно не брать сотрудников в штат, а просто нанять грузчиков по ГПХ на определенные дни.
Если же ресурса вам не хватает, но вы не можете себе его позволить – то вы что-то делаете не так, а то и вовсе занимаетесь ерундой.
Скорее всего вам не нужен ни этот ресурс, ни бизнес-процесс или сервис этого ресурса требующий.
Проще говоря, являясь владельцем овощного ларька вы не можете позволить себе офис класса А и автомобиль представительского класса. А если вас все-таки угораздило их приобрести, то их содержание и обслуживание пробьют дыру в балансе вашего бизнеса и быстро утянут его на дно.
Все это понятно, но как только мы переходим от реальной жизни в плоскость информационных систем, так вроде бы разумные люди начинают делать странные ошибки и ходить по граблям.
Хотя здесь все тоже самое: нужны быстрые диски – идете и покупаете, не хватает памяти – идете и покупаете. Нет денег – значит они вам не нужны. Потому что если бы это реально было узким местом в бизнес-процессах, то деньги сразу бы нашлись.
Хотите SSD корпоративного класса и брендовый сервер? Но не можете себе позволить? Значит они вам не нужны и ваши задачи прекрасно закроет обычное настольное железо.
Да, всякие корпоративные плюшки – это удобно, но удобно прежде всего администратору, а не бизнесу, которому они не нужны, точнее не нужны за такие деньги.
А админ? А админ, как бы это не было ему неприятно слышать – перебьется. Потому что предприятию это не даст ничего, кроме дыры в бюджете. И в целом такое требование равносильно тому, чтобы потребовать в качестве служебной машины Мерседес вместо Гранты.
Одним из отличных примеров несоответствия желаний и возможностей является почтовый сервер.
Очень часто можно услышать: да что-там своя почта, делов то…
А дела начинаются ровно потом. Когда выясняется, что база писем в несколько терабайт на жестких дисках ощутимо тормозит при поиске, ее надо на чем-то хранить, куда-то бекапить.
Но позволить купить себе быстрые SSD такого объема и построить хранилище бекапов с адекватной глубиной хранения фирма не в состоянии.
Тут есть два варианта. Работать как-то так, на костылях и синей изоленте, в надежде на то, что ничего страшного не случится.
Или сесть и трезво признать, что своя почта такому предприятию не нужна. И проще и дешевле будет арендовать ее в облаке.
И даже если там будут сопоставимые цифры, если считать, скажем, за год. То аренда – это растянутые по времени затраты с гарантированным результатом. Свое сервер – единовременные и результат тут достаточно непредсказуем.
Поэтому каждый раз, когда возникнет такая ситуация вспоминаем. Если ресурс нужен – покупаем, нет на это денег – то он нам не нужен или мы делаем что-то не так.
Но можно же оптимизировать и не покупать? Можно. Но для этого придется купить время специалиста, который знает, как это сделать и получить гарантированный результат.
Вы именно такой специалист? А что вы до сих пор здесь сидите? Вас ждут великие дела.
👍28👎8💯2❤1🥱1
Скот, а не питомцы
В комментариях снова задали вопрос использования десктопного железа в IT-инфраструктуре взамен брендового. Админы, особенно старой школы, обычно вздыхают и сетуя на санкции, курс доллара и отсутствие у бизнеса нужного количества денег говорят, что мол приходится и с десктопным…
Но на самом деле это однобокий и устаревший взгляд на проблему. Сегодня уже практически никто не гоняет продуктивную нагрузку на голом железе – это дурной тон и признак ретроградства. Сегодня на железе стоит исключительно гипервизор/оркестратор и больше ничего. Широко в ходу концепция «чистого хоста».
Нагрузка в 2026 вся виртуализированна и это даже не виртуальные машины, а контейнеры, чаще всего легковесные (OCI). Но даже при использовании более тяжелых LXC или даже полноценных виртуалок такая инфраструктура прекрасно масштабируется горизонтально.
Дорогое серверное железо горизонтально столь же легко не масштабируется, по вполне понятным финансовым причинам и представляет собой единую точку отказа. Выход из строя такого устройства – ситуация аварийная и крайне болезненная для бизнеса.
По сути, перед нами питомец, который имеет свой характер, свои особенности, свои настройки, которого мы холим, лечим, лечим и т.д. Болезнь питомца – горе в семье. Питомцы дороги в содержании, на них не сэкономишь.
Но с переходом нагрузки от монолитов к микросервисам или гибридам мы можем заменить два дорогих брендовых сервера на штук пять хороших, мощных настольных ПК и собрать на них HA-кластер. Сегодня это доступно даже самым маленьким, тот же Proxmox VE в последней версии научился динамически распределять нагрузку на ноды.
И что мы получаем? А получаем не только удешевление владения, но и смену парадигмы. У нас скот, а не питомцы. Да, скот тоже нужно кормить и поить, но коту не покупают корм в пакетиках, а просто кормят сеном или силосом.
И скот безлик. Вам уже тоже все равно на какие-то особенности систем, все они безлики, это типичный хост с Proxmox (условно). Там нет индивидуальных настроек, там все типовое и унифицированное. Вы можете спокойно раскатывать новые конфигурации через Ansible или Terraform.
Ваша инфраструктура больше не завязана на железо и его особенности. Она перешла в декларативную форму – инфраструктура как код (IaC). Вы описываете не настройки, а конечное состояние, которое требуется получить.
Сервер перестает быть сервером, теперь это просто нода, одна из многих. Нет никакого смысла наделять ее индивидуальностью, заниматься персональными настройками и т.д. и т.п.
Сломалась, упала? Да и пес с ней, пусть лежит, утром разберемся, полезная нагрузка все равно уже распределилась по другим узлам и никакой спешки нет.
А утром мы просто достанем со склада (или купим в ближайшем ДНС или Ситилинк) простой ПК с нужными характеристиками и заменим им выбывший. И даже настраивать его персонально не придется, нужное состояние у нас уже описано, нужно только применить.
Заметьте, мы не пытаемся лечить, восстанавливать или что-то еще делать с «заболевшим», мы просто меняем его на «здоровый», разбираться будем потом. Если будем. А попробуйте провернуть такой фокус с брендовым сервером?
Причем мы сейчас не придумали ничего нового, он давно применяется гигантами, в частности Google и Facebook, последние вообще стали основателями Open Compute Project (OCP) – смысл которого – это замена дорогих и закрытых систем на простые, недорогие, унифицированные.
Вместе с этим меняется и отношение к проектированию инфраструктуры, с переходом к концепции Design for Failure (проектирование для отказов), мы больше не исходим из того, что наша техника надежна, наоборот, мы точно знаем, что она сломается и делаем так, чтобы мы могли спокойно заменить один кирпичик другим.
Мы не собираемся никому ничего навязывать, каждый волен поступать как вздумается, но, возможно, пора оглянуться, мир меняется и вместе с ним меняются подходы. И то, что вчера было мейнстримом, сегодня уже устарело, а вчерашние смелые проекты становятся новыми нормами.
В комментариях снова задали вопрос использования десктопного железа в IT-инфраструктуре взамен брендового. Админы, особенно старой школы, обычно вздыхают и сетуя на санкции, курс доллара и отсутствие у бизнеса нужного количества денег говорят, что мол приходится и с десктопным…
Но на самом деле это однобокий и устаревший взгляд на проблему. Сегодня уже практически никто не гоняет продуктивную нагрузку на голом железе – это дурной тон и признак ретроградства. Сегодня на железе стоит исключительно гипервизор/оркестратор и больше ничего. Широко в ходу концепция «чистого хоста».
Нагрузка в 2026 вся виртуализированна и это даже не виртуальные машины, а контейнеры, чаще всего легковесные (OCI). Но даже при использовании более тяжелых LXC или даже полноценных виртуалок такая инфраструктура прекрасно масштабируется горизонтально.
Дорогое серверное железо горизонтально столь же легко не масштабируется, по вполне понятным финансовым причинам и представляет собой единую точку отказа. Выход из строя такого устройства – ситуация аварийная и крайне болезненная для бизнеса.
По сути, перед нами питомец, который имеет свой характер, свои особенности, свои настройки, которого мы холим, лечим, лечим и т.д. Болезнь питомца – горе в семье. Питомцы дороги в содержании, на них не сэкономишь.
Но с переходом нагрузки от монолитов к микросервисам или гибридам мы можем заменить два дорогих брендовых сервера на штук пять хороших, мощных настольных ПК и собрать на них HA-кластер. Сегодня это доступно даже самым маленьким, тот же Proxmox VE в последней версии научился динамически распределять нагрузку на ноды.
И что мы получаем? А получаем не только удешевление владения, но и смену парадигмы. У нас скот, а не питомцы. Да, скот тоже нужно кормить и поить, но коту не покупают корм в пакетиках, а просто кормят сеном или силосом.
И скот безлик. Вам уже тоже все равно на какие-то особенности систем, все они безлики, это типичный хост с Proxmox (условно). Там нет индивидуальных настроек, там все типовое и унифицированное. Вы можете спокойно раскатывать новые конфигурации через Ansible или Terraform.
Ваша инфраструктура больше не завязана на железо и его особенности. Она перешла в декларативную форму – инфраструктура как код (IaC). Вы описываете не настройки, а конечное состояние, которое требуется получить.
Сервер перестает быть сервером, теперь это просто нода, одна из многих. Нет никакого смысла наделять ее индивидуальностью, заниматься персональными настройками и т.д. и т.п.
Сломалась, упала? Да и пес с ней, пусть лежит, утром разберемся, полезная нагрузка все равно уже распределилась по другим узлам и никакой спешки нет.
А утром мы просто достанем со склада (или купим в ближайшем ДНС или Ситилинк) простой ПК с нужными характеристиками и заменим им выбывший. И даже настраивать его персонально не придется, нужное состояние у нас уже описано, нужно только применить.
Заметьте, мы не пытаемся лечить, восстанавливать или что-то еще делать с «заболевшим», мы просто меняем его на «здоровый», разбираться будем потом. Если будем. А попробуйте провернуть такой фокус с брендовым сервером?
Причем мы сейчас не придумали ничего нового, он давно применяется гигантами, в частности Google и Facebook, последние вообще стали основателями Open Compute Project (OCP) – смысл которого – это замена дорогих и закрытых систем на простые, недорогие, унифицированные.
Вместе с этим меняется и отношение к проектированию инфраструктуры, с переходом к концепции Design for Failure (проектирование для отказов), мы больше не исходим из того, что наша техника надежна, наоборот, мы точно знаем, что она сломается и делаем так, чтобы мы могли спокойно заменить один кирпичик другим.
Мы не собираемся никому ничего навязывать, каждый волен поступать как вздумается, но, возможно, пора оглянуться, мир меняется и вместе с ним меняются подходы. И то, что вчера было мейнстримом, сегодня уже устарело, а вчерашние смелые проекты становятся новыми нормами.
1👍37👎4💯2❤1
Атомарность на серверах Linux. Да или нет?
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍19❤4👎3👌2👀1
Можно вечно смотреть на горящий огонь, бегущую воду, как работают люди и как инициализируется ЛМ ЧЗ.
И, твою дивизию, ведь все это уже когда-то проходили. Первые версии ЛМ ЧЗ инициализировались долго и не с первого раза. Потом проблему пофиксили и все стало хорошо.
Но теперь на смену ветке 1.х пришла ветка 2.х и ее, что, писали новые пионеры? Которые были не в курсе проблем старых?
В общем - готовьтесь снова развлекаться с ЛМ ЧЗ, как будто новых развлечений с ПИоТ нам мало.
И, твою дивизию, ведь все это уже когда-то проходили. Первые версии ЛМ ЧЗ инициализировались долго и не с первого раза. Потом проблему пофиксили и все стало хорошо.
Но теперь на смену ветке 1.х пришла ветка 2.х и ее, что, писали новые пионеры? Которые были не в курсе проблем старых?
В общем - готовьтесь снова развлекаться с ЛМ ЧЗ, как будто новых развлечений с ПИоТ нам мало.
🤣9👍7❤2🤮2
Не было печали, купила баба порося
Тестовую эксплуатацию ПИоТ можно охарактеризовать именно этой народной поговоркой, разве что «порося» купить заставили добровольно-принудительно.
Какие-то серьезные выводы делать пока рано, но забот у поддержки явно прибавится, причем тех, которых раньше не было, а все старые проблемы Честного знака останутся.
Ну и не перестает покидать ощущение, что ПИоТ – это в первую очередь за деньги, потому что маниакально проверяет свою лицензию чуть ли не в реальном времени и чуть что перестает работать, ссылаясь на ее отсутствие.
При этом четкой ясности по дате 1 июля нет, но до сих пор остаются кассы, которые не готовы к ПИоТ (РР, которые бывший Штрих) и технически отозвать с 1 июля розничный токен не получится, значит и у остальных появится возможность работать по-старому.
Другое дело, что с этим можно будет легко бороться административными методами. В общем, поживем увидим. А пока надо быть готовым к любому раскладу.
Тестовую эксплуатацию ПИоТ можно охарактеризовать именно этой народной поговоркой, разве что «порося» купить заставили добровольно-принудительно.
Какие-то серьезные выводы делать пока рано, но забот у поддержки явно прибавится, причем тех, которых раньше не было, а все старые проблемы Честного знака останутся.
Ну и не перестает покидать ощущение, что ПИоТ – это в первую очередь за деньги, потому что маниакально проверяет свою лицензию чуть ли не в реальном времени и чуть что перестает работать, ссылаясь на ее отсутствие.
При этом четкой ясности по дате 1 июля нет, но до сих пор остаются кассы, которые не готовы к ПИоТ (РР, которые бывший Штрих) и технически отозвать с 1 июля розничный токен не получится, значит и у остальных появится возможность работать по-старому.
Другое дело, что с этим можно будет легко бороться административными методами. В общем, поживем увидим. А пока надо быть готовым к любому раскладу.
👍10🤣3👌1
Спрашивают – отвечаем. Надо ли заземлять экран витой пары?
Очень часто задают вопрос – надо ли заземлять экран витой пары ScTP, FTP, SFTP и как именно это делать. Кто-то говорит, что это необязательно, кто-то предлагает заземлять только с одного конца. Так кого же слушать?
А слушать надо то, что говорят стандарты. И сегодня нам на помощь придёт ГОСТ Р 53246-2008 СИСТЕМЫ КАБЕЛЬНЫЕ СТРУКТУРИРОВАННЫЕ Проектирование основных узлов системы. Общие требования.
Итак, что нам говорит стандарт про экранированную витую пару:
Итак. Экран нужен нам для защиты как от внешних, так и внутренних помех, но его эффективность завит от многих факторов, в т.ч. и от тщательности монтажа.
Но одним экранированным кабелем дело не обходится, снова читаем стандарт:
Поэтому кроме экранированного кабеля нам еще понадобится экранированное оборудование, способное терминировать экранированные кабели и обеспечивать непрерывность экрана.
Т.е. вам понадобятся еще экранированные коннекторы, патч-панели, розетки и активное сетевое оборудование, поддерживающее работу с экранированными кабелями.
При этом стандарт прямо запрещает создание патч-кордов и коммутационных перемычек на основе экранированной витой пары в полевых условиях.
Таким образом вывод можно сделать однозначный: применение экранированной витой пары требует ее сочетания с экранированным сетевым оборудованием и требует обязательного обеспечения непрерывности экрана.
☝️ Т.е. оставить экран кабеля не подключенным к экрану коннектора или патч-панели нельзя!
Неподключенный экран в некоторых ситуациях способен работать в качестве большой антенны и дополнительно собирать на себя наводки.
С экраном разобрались, но пока ни слова не было сказано о заземлении. Вообще, для работы экрана заземление как таковое не нужно, достаточно того, чтобы он был подключен в точку с постоянным потенциалом. Поэтому в стандарте говорится о системах заземления и уравнивания потенциалов.
А вот здесь мы вступаем на скользкую тропу электротехники и вторгаемся в отрасль весьма далекую от администрирования. Поэтому попробуем по-простому.
Именно заземление является самым простым и надежным способом обеспечить точку с постоянным потенциалом, которая нужна для работы экрана. В идеале – это иметь отдельную шину заземления для коммуникационного оборудования, т.н. информационную землю.
На практике же бывает разное, очень разное. Это и отдельные шины заземления в разных частях здания или предприятия, и зануление вместо заземления, да и просто не соответствующие стандарту заземление.
К чему это может привести? А к тому, что между двумя точками земли может оказаться разность потенциалов и по экрану потечет ток, со всеми вытекающими. Именно поэтому существует совет заземлять кабель только с одной стороны. Либо подключать экран к земле через емкость.
Но повторюсь еще раз – здесь мы выходим за рамки администрирования и данный вопрос следует решать с ответственными за это сотрудниками.
Очень часто задают вопрос – надо ли заземлять экран витой пары ScTP, FTP, SFTP и как именно это делать. Кто-то говорит, что это необязательно, кто-то предлагает заземлять только с одного конца. Так кого же слушать?
А слушать надо то, что говорят стандарты. И сегодня нам на помощь придёт ГОСТ Р 53246-2008 СИСТЕМЫ КАБЕЛЬНЫЕ СТРУКТУРИРОВАННЫЕ Проектирование основных узлов системы. Общие требования.
Итак, что нам говорит стандарт про экранированную витую пару:
Экранирование проводников кабеля помогает улучшить защиту от электромагнитного излучения, создаваемого носителями сигналов, и невосприимчивость к воздействию электромагнитных помех от внешних источников.
Способность экрана создавать определенные преимущества для кабельной системы зависит от множества факторов. К этим факторам можно отнести рабочие характеристики компонентов кабельной системы, специфические методы и тщательность монтажа, а также конструктивные особенности и способы подключения активного оборудования.
Итак. Экран нужен нам для защиты как от внешних, так и внутренних помех, но его эффективность завит от многих факторов, в т.ч. и от тщательности монтажа.
Но одним экранированным кабелем дело не обходится, снова читаем стандарт:
Экранированное коммутационное оборудование предназначено для терминирования экранированных кабелей типов ScTP/FTP и S/FTP на основе витой пары проводников с волновым сопротивлением 100 Ом.
Для обеспечения эффективности экранирования системы требуется сохранение непрерывности экрана во всех компонентах кабельных подсистем в моделях линий и каналов, а также подключение экранов к телекоммуникационной системе заземления и уравнивание потенциалов в соответствии с требованиями нормативных документов.
Поэтому кроме экранированного кабеля нам еще понадобится экранированное оборудование, способное терминировать экранированные кабели и обеспечивать непрерывность экрана.
Т.е. вам понадобятся еще экранированные коннекторы, патч-панели, розетки и активное сетевое оборудование, поддерживающее работу с экранированными кабелями.
При этом стандарт прямо запрещает создание патч-кордов и коммутационных перемычек на основе экранированной витой пары в полевых условиях.
Таким образом вывод можно сделать однозначный: применение экранированной витой пары требует ее сочетания с экранированным сетевым оборудованием и требует обязательного обеспечения непрерывности экрана.
☝️ Т.е. оставить экран кабеля не подключенным к экрану коннектора или патч-панели нельзя!
Неподключенный экран в некоторых ситуациях способен работать в качестве большой антенны и дополнительно собирать на себя наводки.
С экраном разобрались, но пока ни слова не было сказано о заземлении. Вообще, для работы экрана заземление как таковое не нужно, достаточно того, чтобы он был подключен в точку с постоянным потенциалом. Поэтому в стандарте говорится о системах заземления и уравнивания потенциалов.
А вот здесь мы вступаем на скользкую тропу электротехники и вторгаемся в отрасль весьма далекую от администрирования. Поэтому попробуем по-простому.
Именно заземление является самым простым и надежным способом обеспечить точку с постоянным потенциалом, которая нужна для работы экрана. В идеале – это иметь отдельную шину заземления для коммуникационного оборудования, т.н. информационную землю.
На практике же бывает разное, очень разное. Это и отдельные шины заземления в разных частях здания или предприятия, и зануление вместо заземления, да и просто не соответствующие стандарту заземление.
К чему это может привести? А к тому, что между двумя точками земли может оказаться разность потенциалов и по экрану потечет ток, со всеми вытекающими. Именно поэтому существует совет заземлять кабель только с одной стороны. Либо подключать экран к земле через емкость.
Но повторюсь еще раз – здесь мы выходим за рамки администрирования и данный вопрос следует решать с ответственными за это сотрудниками.
⚡11💯10👍9❤6
Витая пара
Чтобы понять работу витой пары нужно немного углубиться в школьный курс физики и даже немного выйти за его рамки. Поэтому постараемся объяснить процесс простыми словами.
Витая пара – это пара проводников электрического сигнала, свитая небольшим шагом по отношению к единице длины. Этим достигается одинаковая длина обоих проводников, а благодаря витью они равномерно располагаются в пространстве, т.е. нельзя сказать, что один проводник проходит выше, второй ниже (левее/правее).
Этим достигается максимально одинаковое влияние внешних факторов на оба проводника, почему это важно – мы рассмотрим ниже.
По витой паре передается дифференциальный сигнал, это когда по второму проводнику передается сигнал инверсный первому, а считывается не уровень сигнала относительно земли (точка электрической схемы с нулевым потенциалом), а разница потенциалов между ними.
Это позволяет повысить помехоустойчивость линии связи, так как внешняя помеха будет действовать на оба провода витой пары одинаково и однонаправленно.
Например, мы подали на первый проводник сигнал в +2 В, а на второй -2 В. Разница потенциалов у нас составит 4 В. Теперь представим внешнюю помеху с уровнем в 1,5 В. Таким образом в первом проводнике мы получим уровень сигнала +3,5 В, во втором – 0,5 В, но разность потенциалов останется прежней, все те же 4 В.
Также дифференциальный характер сигнала позволяет эффективно подавлять внутренние помехи, так как электрические поля проводников будут взаимно гаситься.
Таким образом мы получаем достаточно простой и дешевый кабель, способный передавать высокочастотный электрический сигнал, устойчивый к помехам и создающий минимальные внешние наводки сам.
В многопарных кабелях для разных пар используется разный шаг завивки, чтобы исключить влияние взаимных помех. При этом все пары по частотным и волновым характеристикам одинаковы. Т.е. нет более скоростных и менее скоростных пар.
Стандарт TIA/EIA-568A и пришедший ему на смену TIA/EIA-568B задают в числе прочего порядок разводки разъема 8P8C, более известного как RJ45.
Для 10 и 100 Мбит/с используется две пары из четырех. Которые разводятся на 1-2 и 3-6 контакт разъема, при этом используются зеленая и оранжевая пара. Такая странная разводка сделана для совместимости с телефонным разъемом 6P4C (RJ11), который как раз попадает на 4-5 контакт.
Для стандартов 1 Гбит/с и выше используются все четыре пары и по каждой из них передается одинаковый сигнал, т.е. нет какой-то подстройки под конкретные пары.
Итак, что будет если мы не будем следовать стандарту и вложим провода в разъем в том порядке, который нам нравится?
Если мы будем соблюдать раскладку контактов по парам: 1-2, 3-6, 4-5, 7-8 – то ничего страшного не случится, кабель полностью сохранит свои частотные характеристики.
В случае с любой другой схемой обжима мы получим, что прямой и инверсный сигналы находятся в разных витых парах, что резко снизит помехозащищенность кабеля и увеличит внутренние наводки. Т.е. его частотные характеристики однозначно будут серьезно ухудшены.
На практике все будет зависеть от качества кабеля, его длины, качества монтажа, уровня внешних помех и много еще чего. Поэтому такой кабель может как работать «нормально», так и практически не работать вообще.
При этом однозначно сократится длина кабельной линии, на которой кабель работает без снижения скоростных характеристик или перехода на более медленный стандарт.
Поэтому не стоит заниматься самодеятельностью и обжимать кабель следует согласно утвержденных стандартов.
Чтобы понять работу витой пары нужно немного углубиться в школьный курс физики и даже немного выйти за его рамки. Поэтому постараемся объяснить процесс простыми словами.
Витая пара – это пара проводников электрического сигнала, свитая небольшим шагом по отношению к единице длины. Этим достигается одинаковая длина обоих проводников, а благодаря витью они равномерно располагаются в пространстве, т.е. нельзя сказать, что один проводник проходит выше, второй ниже (левее/правее).
Этим достигается максимально одинаковое влияние внешних факторов на оба проводника, почему это важно – мы рассмотрим ниже.
По витой паре передается дифференциальный сигнал, это когда по второму проводнику передается сигнал инверсный первому, а считывается не уровень сигнала относительно земли (точка электрической схемы с нулевым потенциалом), а разница потенциалов между ними.
Это позволяет повысить помехоустойчивость линии связи, так как внешняя помеха будет действовать на оба провода витой пары одинаково и однонаправленно.
Например, мы подали на первый проводник сигнал в +2 В, а на второй -2 В. Разница потенциалов у нас составит 4 В. Теперь представим внешнюю помеху с уровнем в 1,5 В. Таким образом в первом проводнике мы получим уровень сигнала +3,5 В, во втором – 0,5 В, но разность потенциалов останется прежней, все те же 4 В.
Также дифференциальный характер сигнала позволяет эффективно подавлять внутренние помехи, так как электрические поля проводников будут взаимно гаситься.
Таким образом мы получаем достаточно простой и дешевый кабель, способный передавать высокочастотный электрический сигнал, устойчивый к помехам и создающий минимальные внешние наводки сам.
В многопарных кабелях для разных пар используется разный шаг завивки, чтобы исключить влияние взаимных помех. При этом все пары по частотным и волновым характеристикам одинаковы. Т.е. нет более скоростных и менее скоростных пар.
Стандарт TIA/EIA-568A и пришедший ему на смену TIA/EIA-568B задают в числе прочего порядок разводки разъема 8P8C, более известного как RJ45.
Для 10 и 100 Мбит/с используется две пары из четырех. Которые разводятся на 1-2 и 3-6 контакт разъема, при этом используются зеленая и оранжевая пара. Такая странная разводка сделана для совместимости с телефонным разъемом 6P4C (RJ11), который как раз попадает на 4-5 контакт.
Для стандартов 1 Гбит/с и выше используются все четыре пары и по каждой из них передается одинаковый сигнал, т.е. нет какой-то подстройки под конкретные пары.
Итак, что будет если мы не будем следовать стандарту и вложим провода в разъем в том порядке, который нам нравится?
Если мы будем соблюдать раскладку контактов по парам: 1-2, 3-6, 4-5, 7-8 – то ничего страшного не случится, кабель полностью сохранит свои частотные характеристики.
В случае с любой другой схемой обжима мы получим, что прямой и инверсный сигналы находятся в разных витых парах, что резко снизит помехозащищенность кабеля и увеличит внутренние наводки. Т.е. его частотные характеристики однозначно будут серьезно ухудшены.
На практике все будет зависеть от качества кабеля, его длины, качества монтажа, уровня внешних помех и много еще чего. Поэтому такой кабель может как работать «нормально», так и практически не работать вообще.
При этом однозначно сократится длина кабельной линии, на которой кабель работает без снижения скоростных характеристик или перехода на более медленный стандарт.
Поэтому не стоит заниматься самодеятельностью и обжимать кабель следует согласно утвержденных стандартов.
1👍37⚡5❤4
Гарантия по другую сторону баррикад. Ох уж эти энтузиасты…
Обычно слово энтузиазм воспринимается в позитивном ключе, сразу возникают ассоциации с молодыми, энергичными, целеустремленными.
Но у сотрудников техотделов и гарантии это слово относится к ругательным. Даже оверклокеры стоят на этой лестнице на ступеньку ниже.
Кто же такие компьютерные «энтузиасты»? На всякий случай возьмем это слово в кавычки. Это товарищи, обычно не стесненные в денежных средствах, активно и деятельно изучающие все профильные сайты и порталы и стремящиеся быть на переднем рубеже технического прогресса.
Ну это же хорошо, скажете вы… Хорошо, если бы ни одно но. Начнем с умеренных энтузиастов, которые покупают новые платформы сразу после их выхода и рассчитывают получить радикальные преимущества.
Но, и это ни для кого не секрет, любая свежая платформа является априори сырой и требуется некоторое время для ее шлифовки и полировки. Т.е. купив самый-самый новый процессор и плату с самым-самым новым чипсетом готовьтесь не доминировать, а собирать чудеса и глюки.
Что-то потом исправят в прошивках BIOS, микрокоде процессора, а что-то только в новых аппаратных ревизиях. И хорошо если дефекты позволят сдать такую железку в гарантию.
А бывают дефекты плавающие, которые не то, что выявить, описать трудно. Особенно если возникают они рандомно раз в пятилетку.
Про несоответствие ожидаемого и действительного – это вообще отдельный разговор. Мало ли что там в обзорах писали. Железо работает? Работает. А почему так? Да пес его знает. Ваша планка памяти есть в листе совместимости? Нет? Ну тогда какие к нам вопросы.
При этом заниматься такими железками в гарантии нет ни желания, ни возможности. Поэтому они либо сразу сдаются назад, если спокойно проходят основные тесты, либо надолго уезжают по сервисам.
Но это были энтузиасты умеренные, если же матерые, причем на всю голову. Эти могут заказать какой-нибудь Threadripper на экзотической материнской плате и забрать это все на самосбор.
Хорошо если просто сломают или накосячат при сборке. Не гарантия и точка.
Куда хуже если это все взлетит, но будет работать вопреки ожиданиям купившего. И вот тут гарантию ждет настоящий вынос мозга. И хорошо если это действительно дефект и железку можно отправить производителю/дистрибьютору по гарантии.
А если? При том, что местная гарантия с техотделом ничего проверить не может, тупо не на чем. Нет ни заведомо исправной платы под эту платформу, нет заведомо живого процессора. В общем, только обнять и плакать.
А железо дорогое, очень дорогое и его хозяин хочет не просто ремонта или замены, а еще и выдачи подмены, такого же уровня.
Хотя с этим проще, нормы ЗоЗПП требуют предоставить подменный товар, обладающий только основными потребительскими свойствами, см статью 20:
Т.е. отдаем обычный Celeron на офисной плате и вопрос решен. А вот что делать с принесенным монстриком? Потому что монстрик вроде и работает, но работает как бы не так, как надо.
В итоге монстрик достаточно поездит по сервисам и его либо вернут хозяину с заключением что все норм, а заявленные им требования – это неверно понятая реклама и нечего такого не обещалось.
Либо его убьют гарантийщики продавца и выдадут нашему энтузиасту компенсацию деньгами. Ну чтобы второй раз в такой блудняк не встревать. Нет в наличии, не можем привезти и все, вопрос закрыли.
И все это не со зла, а от реального положения дел. Потому что такие платформы в силу малого тиража часто являются сырыми, а диагностика их на местах серьезно затруднена, потому что просто нечем.
Поэтому, если вы собрались записаться в клуб «энтузиастов» - хорошо подумайте, а оно вам надо?
Обычно слово энтузиазм воспринимается в позитивном ключе, сразу возникают ассоциации с молодыми, энергичными, целеустремленными.
Но у сотрудников техотделов и гарантии это слово относится к ругательным. Даже оверклокеры стоят на этой лестнице на ступеньку ниже.
Кто же такие компьютерные «энтузиасты»? На всякий случай возьмем это слово в кавычки. Это товарищи, обычно не стесненные в денежных средствах, активно и деятельно изучающие все профильные сайты и порталы и стремящиеся быть на переднем рубеже технического прогресса.
Ну это же хорошо, скажете вы… Хорошо, если бы ни одно но. Начнем с умеренных энтузиастов, которые покупают новые платформы сразу после их выхода и рассчитывают получить радикальные преимущества.
Но, и это ни для кого не секрет, любая свежая платформа является априори сырой и требуется некоторое время для ее шлифовки и полировки. Т.е. купив самый-самый новый процессор и плату с самым-самым новым чипсетом готовьтесь не доминировать, а собирать чудеса и глюки.
Что-то потом исправят в прошивках BIOS, микрокоде процессора, а что-то только в новых аппаратных ревизиях. И хорошо если дефекты позволят сдать такую железку в гарантию.
А бывают дефекты плавающие, которые не то, что выявить, описать трудно. Особенно если возникают они рандомно раз в пятилетку.
Про несоответствие ожидаемого и действительного – это вообще отдельный разговор. Мало ли что там в обзорах писали. Железо работает? Работает. А почему так? Да пес его знает. Ваша планка памяти есть в листе совместимости? Нет? Ну тогда какие к нам вопросы.
При этом заниматься такими железками в гарантии нет ни желания, ни возможности. Поэтому они либо сразу сдаются назад, если спокойно проходят основные тесты, либо надолго уезжают по сервисам.
Но это были энтузиасты умеренные, если же матерые, причем на всю голову. Эти могут заказать какой-нибудь Threadripper на экзотической материнской плате и забрать это все на самосбор.
Хорошо если просто сломают или накосячат при сборке. Не гарантия и точка.
Куда хуже если это все взлетит, но будет работать вопреки ожиданиям купившего. И вот тут гарантию ждет настоящий вынос мозга. И хорошо если это действительно дефект и железку можно отправить производителю/дистрибьютору по гарантии.
А если? При том, что местная гарантия с техотделом ничего проверить не может, тупо не на чем. Нет ни заведомо исправной платы под эту платформу, нет заведомо живого процессора. В общем, только обнять и плакать.
А железо дорогое, очень дорогое и его хозяин хочет не просто ремонта или замены, а еще и выдачи подмены, такого же уровня.
Хотя с этим проще, нормы ЗоЗПП требуют предоставить подменный товар, обладающий только основными потребительскими свойствами, см статью 20:
В отношении товаров длительного пользования изготовитель, продавец либо уполномоченная организация или уполномоченный индивидуальный предприниматель обязаны при предъявлении потребителем указанного требования в трехдневный срок безвозмездно предоставить потребителю на период ремонта товар длительного пользования, обладающий этими же основными потребительскими свойствами
Т.е. отдаем обычный Celeron на офисной плате и вопрос решен. А вот что делать с принесенным монстриком? Потому что монстрик вроде и работает, но работает как бы не так, как надо.
В итоге монстрик достаточно поездит по сервисам и его либо вернут хозяину с заключением что все норм, а заявленные им требования – это неверно понятая реклама и нечего такого не обещалось.
Либо его убьют гарантийщики продавца и выдадут нашему энтузиасту компенсацию деньгами. Ну чтобы второй раз в такой блудняк не встревать. Нет в наличии, не можем привезти и все, вопрос закрыли.
И все это не со зла, а от реального положения дел. Потому что такие платформы в силу малого тиража часто являются сырыми, а диагностика их на местах серьезно затруднена, потому что просто нечем.
Поэтому, если вы собрались записаться в клуб «энтузиастов» - хорошо подумайте, а оно вам надо?
👍5🤔4👎3🥱1
Что не так с Cat 7?
Один мой хороший знакомый, третьего дня решил проапгрейдить домашнюю сеть до 2,5 Гбит/с. Зачем? Не спрашивайте. Ну и каждый волен сходить с ума по-своему.
В общем выбрали мы с ним коммутатор, сетевые карты и дело дошло до патч-кордов. И вот он присылает мне пару артикулов и спрашивает, что я об этом думаю.
А артикулы были примерно такие: Патч-корд NAME [круглый, SF/FTP, RJ-45, Cat. 7, длина - N м]
Пытаюсь выяснить причину столь странного выбора, а в ответ слышу – ну это же седьмая категория, это же круто и вообще, они красивые.
Согласиться здесь могу лишь с последним. А вот что такое седьмая категория и чем она отличается от других давайте разбираться.
Что такое категория кабеля? Это стандарт, описывающий его технические характеристики, максимальную частоту передаваемого сигнала и скорости передачи данных на определенные расстояния.
Наиболее распространены и привычны кабели категории Cat 5e, они предусматривают физический размер (диаметр) 24AWG (0,51 мм) и разъем 8P8C RJ-45. Максимальная передаваемая частота – 100 МГц, это обеспечивает связь на скоростях до 1 Гбит/с на расстоянии до 100 м.
Но гигабита скоро стало мало и был разработан новый стандарт – Cat 6, который предполагал несколько более крупный кабель - 23AWG (0,585 мм) и все тот же разъем 8P8C RJ-45. Кабель поддерживал частоту передачи до 250 МГц и поддерживал скорость до 10 Гбит/с на расстоянии до 35-50 м.
Одновременно с ним, а это было в 2002 году, был представлен стандарт Cat 7, который при тех же физических размерах кабеля обеспечивал рабочие частоты до 600 МГц и передачу на скорости 10 Гбит/с на расстояние до 100 метров.
Вот он долгожданный прорыв… или нет? Скорее всего второе. Стандарт Cat 7 предусматривал применение проприетарных разъемов GG45 или TERA. При этом первый из них обратно совместим с RJ-45.
Но все кроется в мелочах. Разъем GG45 предусматривает 4 дополнительных контакта для заземления, а сам кабель седьмой категории обязательно должен быть типа STP (S/UTP), т.е. иметь экран на каждой паре и общий экран для всего кабеля.
Все это серьезно отражается на стоимости и кабель Cat 7 стоит ощутимо дороже своих аналогов.
Так может есть за что переплатить? Увы. Все преимущества данного кабеля раскрываются только с проприетарными разъемами. В режиме совместимости с RJ-45 рабочая частота кабеля падает до 200-250 МГц, т.е. на уровень куда более дешевого Cat 6.
А немного позже вышел Cat 6a, который на обычной витухе позволял достичь рабочих частот до 500 МГц и передавать 10 Гбит/с на расстояние до 100 метров, правда при строгом соблюдении всех правил монтажа.
А что касается бытовых сетей и скоростей 2,5 Гбит/с, то кабели Cat 6a полностью соответствуют всем требованиям и при этом доступны и недороги.
Хотя Cat 7 красивее и дороже (хотя по реальным параметрам хуже), но это уже что-то из области аудиофилии и прочих антинаучных забав.
Один мой хороший знакомый, третьего дня решил проапгрейдить домашнюю сеть до 2,5 Гбит/с. Зачем? Не спрашивайте. Ну и каждый волен сходить с ума по-своему.
В общем выбрали мы с ним коммутатор, сетевые карты и дело дошло до патч-кордов. И вот он присылает мне пару артикулов и спрашивает, что я об этом думаю.
А артикулы были примерно такие: Патч-корд NAME [круглый, SF/FTP, RJ-45, Cat. 7, длина - N м]
Пытаюсь выяснить причину столь странного выбора, а в ответ слышу – ну это же седьмая категория, это же круто и вообще, они красивые.
Согласиться здесь могу лишь с последним. А вот что такое седьмая категория и чем она отличается от других давайте разбираться.
Что такое категория кабеля? Это стандарт, описывающий его технические характеристики, максимальную частоту передаваемого сигнала и скорости передачи данных на определенные расстояния.
Наиболее распространены и привычны кабели категории Cat 5e, они предусматривают физический размер (диаметр) 24AWG (0,51 мм) и разъем 8P8C RJ-45. Максимальная передаваемая частота – 100 МГц, это обеспечивает связь на скоростях до 1 Гбит/с на расстоянии до 100 м.
Но гигабита скоро стало мало и был разработан новый стандарт – Cat 6, который предполагал несколько более крупный кабель - 23AWG (0,585 мм) и все тот же разъем 8P8C RJ-45. Кабель поддерживал частоту передачи до 250 МГц и поддерживал скорость до 10 Гбит/с на расстоянии до 35-50 м.
Одновременно с ним, а это было в 2002 году, был представлен стандарт Cat 7, который при тех же физических размерах кабеля обеспечивал рабочие частоты до 600 МГц и передачу на скорости 10 Гбит/с на расстояние до 100 метров.
Вот он долгожданный прорыв… или нет? Скорее всего второе. Стандарт Cat 7 предусматривал применение проприетарных разъемов GG45 или TERA. При этом первый из них обратно совместим с RJ-45.
Но все кроется в мелочах. Разъем GG45 предусматривает 4 дополнительных контакта для заземления, а сам кабель седьмой категории обязательно должен быть типа STP (S/UTP), т.е. иметь экран на каждой паре и общий экран для всего кабеля.
Все это серьезно отражается на стоимости и кабель Cat 7 стоит ощутимо дороже своих аналогов.
Так может есть за что переплатить? Увы. Все преимущества данного кабеля раскрываются только с проприетарными разъемами. В режиме совместимости с RJ-45 рабочая частота кабеля падает до 200-250 МГц, т.е. на уровень куда более дешевого Cat 6.
А немного позже вышел Cat 6a, который на обычной витухе позволял достичь рабочих частот до 500 МГц и передавать 10 Гбит/с на расстояние до 100 метров, правда при строгом соблюдении всех правил монтажа.
А что касается бытовых сетей и скоростей 2,5 Гбит/с, то кабели Cat 6a полностью соответствуют всем требованиям и при этом доступны и недороги.
Хотя Cat 7 красивее и дороже (хотя по реальным параметрам хуже), но это уже что-то из области аудиофилии и прочих антинаучных забав.
👍44❤4
Устанавливаем ТС ПИоТ для работы с 1С:Предприятие и ККТ АТОЛ
ТС ПИоТ — это техническое средство получения информации о товаре, программный модуль, использование которого станет обязательным с 1 июля 2026 года. ПО достаточно сложное, требующее интеграции со многими компонентами кассы.
В данной статье мы пошагово разберем его установку и интеграцию с кассовым ПО на базе 1С:Предприятие для работы совместно с ККТ АТОЛ.
Перед тем, как приступать к установке и настройке убедитесь, что у вас:
▫️Установлен .NET 4.8
▫️ККТ имеет прошивку не ниже 5.17
▫️1С обновлена до релиза, поддерживающего ТС ПИоТ
▫️Приобретена лицензия ЕСМ на используемую ККТ
Последний момент достаточно важен: лицензия ЕСМ привязывается к заводскому номеру ККТ и без активной лицензии работает 7 дней в демо-режиме, однако вернуть кассу к работе "по-старому" будет достаточно непросто.
✅ Читать далее: https://interface31.ru/post/ts-piot-dlya--1с-predpriyatie-kkt-atol/
ТС ПИоТ — это техническое средство получения информации о товаре, программный модуль, использование которого станет обязательным с 1 июля 2026 года. ПО достаточно сложное, требующее интеграции со многими компонентами кассы.
В данной статье мы пошагово разберем его установку и интеграцию с кассовым ПО на базе 1С:Предприятие для работы совместно с ККТ АТОЛ.
Перед тем, как приступать к установке и настройке убедитесь, что у вас:
▫️Установлен .NET 4.8
▫️ККТ имеет прошивку не ниже 5.17
▫️1С обновлена до релиза, поддерживающего ТС ПИоТ
▫️Приобретена лицензия ЕСМ на используемую ККТ
Последний момент достаточно важен: лицензия ЕСМ привязывается к заводскому номеру ККТ и без активной лицензии работает 7 дней в демо-режиме, однако вернуть кассу к работе "по-старому" будет достаточно непросто.
✅ Читать далее: https://interface31.ru/post/ts-piot-dlya--1с-predpriyatie-kkt-atol/
👍18🤝3❤2🤮1
Файловая информационная база 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.
Стимулами для перехода на клиент-серверные версии становится рост количества пользователей, когда однопоточный модуль не успевает обрабатывать очередь, рост объема базы, а также необходимость выполнения регламентных заданий и обменов в автоматическом режиме, без активных сеансов пользователя.
Но это уже совсем другой уровень бизнеса и инфраструктуры, да и вообще совсем другая история.
👍21🤮4❤2
Особенности использования HASP-ключей для лицензий 1С
В комментариях часто вспоминают аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, он не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
В комментариях часто вспоминают аппаратные ключи HASP, к которым также можно привязывать программные лицензии. Но использование аппаратных ключей имеет свои особенности.
Начнем с плюсов: лицензия на HASP не привязана к оборудованию и может использоваться по сети как однопользовательская (т.е. без ограничений количества сеансов).
👉 На этом плюсы закончились, дальше идут особенности и подводные камни.
Если ПК теряет связь с менеджером лицензий HASP License Manager, а сервер или компонента веб-сервера продолжают видеть ключ, то они начнут раздавать те же лицензии как многопользовательские, т.е. по одной на сеанс.
Нужно ли говорить, что в таком режиме лицензии могут совершенно неожиданно закончиться.
Привязанный к HASP ключ программной лицензии требует наличия на ключе HASP хотя бы одной свободной лицензии для проверки ключа. В противном случае проверка не будет пройдена и ключ будет считаться на обнаруженным.
При наличии нескольких ключей одной серии их нужно разместить на разных ПК.
Но это еще не все, без дополнительной настройки оба менеджера будут работать с одинаковыми именами и если клиент первым найдет менеджер ключа, на котором нет свободной лицензии, то он не будет искать второй ключ, он сообщит что нет свободных лицензий или получит многопользовательскую лицензию с сервера или веб-сервера.
И наконец, аппаратный ключ не виден в терминальной сессии, поэтому если вы используете терминальный сервер, то ключ придется разместить на другом узле сети и использовать как сетевой.
Кроме того, аппаратный ключ можно сломать, потерять, он может выйти из строя. При этом, в отличии от программной лицензии, он не будет восстановлен пока вы не предоставите фирме 1С сам ключ или то, что от него осталось и они смогут убедиться что это именно тот ключ.
👍8
Когда-то firewall принимал решения всего по трём параметрам: IP, порт и протокол и этого хватало 👍
Сегодня через один и тот же порт может идти десяток разных приложений, пользователи работают из любой точки, а атаки давно научились выглядеть как обычный трафик.
Уже 25.06.2026 в 13:00 по МСК проведем вебинар "NGFW в эксплуатации: функциональные возможности и удобство".
Подход изменился: от простого контроля доступа к пониманию того, что происходит внутри инфраструктуры.
На вебинаре разберём, как за последние десятилетия изменилась логика сетевой защиты и обсудим:
🔸почему старые подходы перестают работать
🔸как сегодня строятся политики доступа
🔸что реально влияет на производительность NGFW
🔸как устроены обновления, мониторинг и расследование инцидентов
🔸на что смотреть при эксплуатации
РЕГИСТРАЦИЯ НА ВЕБИНАР
Сегодня через один и тот же порт может идти десяток разных приложений, пользователи работают из любой точки, а атаки давно научились выглядеть как обычный трафик.
Уже 25.06.2026 в 13:00 по МСК проведем вебинар "NGFW в эксплуатации: функциональные возможности и удобство".
Подход изменился: от простого контроля доступа к пониманию того, что происходит внутри инфраструктуры.
На вебинаре разберём, как за последние десятилетия изменилась логика сетевой защиты и обсудим:
🔸почему старые подходы перестают работать
🔸как сегодня строятся политики доступа
🔸что реально влияет на производительность NGFW
🔸как устроены обновления, мониторинг и расследование инцидентов
🔸на что смотреть при эксплуатации
РЕГИСТРАЦИЯ НА ВЕБИНАР
🤮2
Особенности использования аппаратных ключей HASP для 1С:Предприятие
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
Несмотря на то, что ключи HASP более недоступны для покупки у пользователей системы 1С:Предприятие осталось на руках еще достаточно ключей, поэтому информация о их применении остается актуальной.
Бытует мнение, что аппаратные ключи проще и удобнее программных лицензий, однако это не так, у них есть свои особенности и ограничения. Далее мы будем говорить о многопользовательских ключах серии ORGL8, которые поставлялись в вариантах на 5, 10, 20, 50 и 100 лицензий.
Также еще есть ключи серий ORG8A и ORG8B на 300 и 500 лицензий.
Начнем с того, что несколько ключей одной серии не могут быть размещены вместе на одном узле и поэтому вам придется разносить их по разным ПК.
Дальнейшее поведение зависит от того, кто и как получает лицензию с этого ключа. Клиентское приложение при запуске в первую очередь ищет в сети службу HASP License Manager и пытается получить лицензию с ее помощью.
В этом случае ему выдается однопользовательская лицензия и он может запустить неограниченное количество сеансов информационных баз.
При использовании в сети нескольких ключей их желательно явно прописать в nethasp.ini примерно следующим образом:
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.111.10, 192.168.111.11
NH_SERVER_NAME = HASP_LM1, HASP_LM2
Если службы HASP LM не найдены или обслуживаемый ими ключ не содержит свободных лицензий, то клиент попытается получить лицензии с сервера или веб-сервера, которые выдают их на сеанс.
Эта особенность часто приводит к сильному перерасходу лицензий в случае возникновения каких-либо сетевых проблем, когда клиенты перестают видеть службу HASP LM, а сервер продолжает иметь к ней доступ, либо ключ установлен на нем локально.
И самое интересное, это взаимодействие с сетевыми ключами сервера или веб-сервера 1С:Предприятие.
В первую очередь сервер ищет локальный ключ и начинает выдавать лицензии из него. По их исчерпании он начинает поиск сетевых ключей, работающих через HASP LM.
Но если в сети находятся несколько ключей, то сервер случайным образом выбирает один из них, дальнейший поиск ключей одной серии не производится.
Таким образом если лицензии на выбранном сетевом ключе будут исчерпаны сервер прекратит выдачу лицензий несмотря на то, что в сети есть еще ключи со свободными лицензиями.
Вместо этого сервер будет производить поиск ключей серий ORG8A и ORG8B, также по одному ключу каждого типа.
Все эти особенности делают использование аппаратных ключей не такой уж простой задачей и заставляют ответственно подходить к планированию инфраструктуры с их использованием.
👍5⚡2🤝1