Самохостинг
Про самосбор мы уже не раз говорили, пришла пора поговорить еще об одном излюбленном явлении – самохостинге.
Что это такое? Это публикация во внешнюю сеть определенных ресурсов для доступа к ним, как личного, так и широких масс желающих из любой точки всемирной сети. Ключевой момент здесь – это доступ, он должен быть постоянный и из любого места.
Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.
На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.
А что нам может предложить самохостинг? Обычно здесь все начинается с того, что мол не нужен мне этот SLA, мне нужно просто получить доступ к моим данным для дома, для семьи откуда-то извне, причем время от времени. Ну и фоточки куда с телефона слить.
Поэтому для многих самохост является также и точкой размещения определенных данных и часто в единственном экземпляре (не считая мобильных устройств).
При этом греет душу, что все это бесплатно, на своем сервере, который тихо жужжит где-то в чулане.
Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.
Такая машинка по актуальным ценам конца ноября 2025 года обойдется плюс-минус в 40 000 рублей.
Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 8 000 рублей в год или 667 рублей в месяц.
1 ТБ на Яндекс Диске стоит без скидок 191 руб./мес., со скидками 89 руб./мес. и голова не болит.
На оставшиеся 500 рублей можно купить VPS начального уровня, которой будет достаточно для хостинга всего остального домашнего добра.
При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.
Надежность? С этим все плохо. Запчастей нет, любой выход из строя комплектующих – это длительный простой, пока будут решаться вопросы гарантии или дополнительные расходы.
Пожары, затопления, аварии на электросетях и прочий форс-мажор, включая тупое «кошка бежала, хвостиком вильнула, включенный сервер упал со шкафа на пол».
Также не сбрасываем со счетов возможный брак, когда оба ваших диска в RAID решат отправиться в страну вечной охоты одновременно (привет муха CC) и диски вам может и поменяют по гарантии, но вот на данные гарантия не распространяется.
Доступность? Тут тоже все плохо. Выключили электричество, пропал интернет – и все, стоим, ждем. И хорошо если там просто личные данные, а не что-то нужное здесь и сейчас. При этом обеспечить себе резервные мощности для самохостинга практически невозможно.
Ну или это будет стоить совсем других денег…
При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.
Ну ладно, то про дом, а теперь про работу. Так тут ровно все тоже самое. Да, нежелание выкладывать корпоративные данные в публичные облака понятно. Но кто мешает поднять свое облако на публичном хостинге?
По деньгам это будет плюс-минус стоимость самохостинга, но вы получите в разы более высокую надежность и доступность.
При этом контроль над системой у вас как был, так и остается. Но не болит голова по железу, ремонту, запчастям, электроснабжению, интернету и многому-многому другому.
Единственный вариант, когда самохостинг оправдан – это требования к безопасности и хранению данных, когда размещать их на внешних ресурсах может быть явно запрещено или обложено таким количеством требований, что проще как-нибудь самим.
Но это уже не про широкий доступ и вопрос доступности тут вообще может уходить на задний план.
В остальном самохостинг – это дорого и ненадежно. Оправдан только если вы просто хотите в это все поиграться с целью получить некоторый опыт.
Про самосбор мы уже не раз говорили, пришла пора поговорить еще об одном излюбленном явлении – самохостинге.
Что это такое? Это публикация во внешнюю сеть определенных ресурсов для доступа к ним, как личного, так и широких масс желающих из любой точки всемирной сети. Ключевой момент здесь – это доступ, он должен быть постоянный и из любого места.
Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.
На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.
А что нам может предложить самохостинг? Обычно здесь все начинается с того, что мол не нужен мне этот SLA, мне нужно просто получить доступ к моим данным для дома, для семьи откуда-то извне, причем время от времени. Ну и фоточки куда с телефона слить.
Поэтому для многих самохост является также и точкой размещения определенных данных и часто в единственном экземпляре (не считая мобильных устройств).
При этом греет душу, что все это бесплатно, на своем сервере, который тихо жужжит где-то в чулане.
Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.
Такая машинка по актуальным ценам конца ноября 2025 года обойдется плюс-минус в 40 000 рублей.
Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 8 000 рублей в год или 667 рублей в месяц.
1 ТБ на Яндекс Диске стоит без скидок 191 руб./мес., со скидками 89 руб./мес. и голова не болит.
На оставшиеся 500 рублей можно купить VPS начального уровня, которой будет достаточно для хостинга всего остального домашнего добра.
При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.
Надежность? С этим все плохо. Запчастей нет, любой выход из строя комплектующих – это длительный простой, пока будут решаться вопросы гарантии или дополнительные расходы.
Пожары, затопления, аварии на электросетях и прочий форс-мажор, включая тупое «кошка бежала, хвостиком вильнула, включенный сервер упал со шкафа на пол».
Также не сбрасываем со счетов возможный брак, когда оба ваших диска в RAID решат отправиться в страну вечной охоты одновременно (привет муха CC) и диски вам может и поменяют по гарантии, но вот на данные гарантия не распространяется.
Доступность? Тут тоже все плохо. Выключили электричество, пропал интернет – и все, стоим, ждем. И хорошо если там просто личные данные, а не что-то нужное здесь и сейчас. При этом обеспечить себе резервные мощности для самохостинга практически невозможно.
Ну или это будет стоить совсем других денег…
При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.
Ну ладно, то про дом, а теперь про работу. Так тут ровно все тоже самое. Да, нежелание выкладывать корпоративные данные в публичные облака понятно. Но кто мешает поднять свое облако на публичном хостинге?
По деньгам это будет плюс-минус стоимость самохостинга, но вы получите в разы более высокую надежность и доступность.
При этом контроль над системой у вас как был, так и остается. Но не болит голова по железу, ремонту, запчастям, электроснабжению, интернету и многому-многому другому.
Единственный вариант, когда самохостинг оправдан – это требования к безопасности и хранению данных, когда размещать их на внешних ресурсах может быть явно запрещено или обложено таким количеством требований, что проще как-нибудь самим.
Но это уже не про широкий доступ и вопрос доступности тут вообще может уходить на задний план.
В остальном самохостинг – это дорого и ненадежно. Оправдан только если вы просто хотите в это все поиграться с целью получить некоторый опыт.
👎31👍12🥱9👀8❤4
Диагностика правил брандмауэра Mikrotik
Часто бывает так, что конфигурация брандмауэра работает не так, как предполагалось и поэтому приходится заниматься диагностикой.
С чего начать? Со счетчиков, если счетчики правила не изменяются, значит трафик, попадающий под критерии в него не доходит.
В этом случае делаем копию правила и обязательно включаем лог. Потом переносим его в самый верх - если счетчики пошли, то хорошо. Если нет - то вы неверно указали критерии. В этом случае убираем по одному и находим тот, из-за которого правило не работало.
Потом начинаем опускать его вниз и проверяем работоспособность. Не забываем каждый раз сбросить счетчик.
Как только правило перестало работать - начинаем разбираться почему. Можем точно также начать убирать критерии и смотреть какой из них неверный.
А можем убрать сразу все критерии и в логе посмотреть какие пакеты сюда доходят, иногда именно после этого все становится ясно.
Теперь о том, как убирать и добавлять критерии. Есть критерии общие, а есть частные. Общими являются те критерии, под которые попадают большинство проходящих правило пакетов, например интерфейсы входа и выхода.
Потом идут более узкие критерии, скажем, протокол и еще более узкие, такие как порт.
Поэтому убирать критерии начинаем частных к широким, добавляем наоборот.
А если ничего не помогает? То смотрим в правило, после которого перестало работать, возможно неверные критерии выставлены именно в нем.
Другая ситуация - все работает как надо, а счетчик правила не работает. В этом случае выше срабатывает какое-то обобщающее правило.
В этом случае делаем копию правила и передвигаем его наверх до тех пор, пока не заработает счетчик. После чего анализируем правило ниже.
А дальше есть два варианта. Ваше правило избыточно и достаточно обойтись одним обобщающим, либо текущее правило построено неверно и в него попадает лишний трафик.
Часто бывает так, что конфигурация брандмауэра работает не так, как предполагалось и поэтому приходится заниматься диагностикой.
С чего начать? Со счетчиков, если счетчики правила не изменяются, значит трафик, попадающий под критерии в него не доходит.
В этом случае делаем копию правила и обязательно включаем лог. Потом переносим его в самый верх - если счетчики пошли, то хорошо. Если нет - то вы неверно указали критерии. В этом случае убираем по одному и находим тот, из-за которого правило не работало.
Потом начинаем опускать его вниз и проверяем работоспособность. Не забываем каждый раз сбросить счетчик.
Как только правило перестало работать - начинаем разбираться почему. Можем точно также начать убирать критерии и смотреть какой из них неверный.
А можем убрать сразу все критерии и в логе посмотреть какие пакеты сюда доходят, иногда именно после этого все становится ясно.
Теперь о том, как убирать и добавлять критерии. Есть критерии общие, а есть частные. Общими являются те критерии, под которые попадают большинство проходящих правило пакетов, например интерфейсы входа и выхода.
Потом идут более узкие критерии, скажем, протокол и еще более узкие, такие как порт.
Поэтому убирать критерии начинаем частных к широким, добавляем наоборот.
А если ничего не помогает? То смотрим в правило, после которого перестало работать, возможно неверные критерии выставлены именно в нем.
Другая ситуация - все работает как надо, а счетчик правила не работает. В этом случае выше срабатывает какое-то обобщающее правило.
В этом случае делаем копию правила и передвигаем его наверх до тех пор, пока не заработает счетчик. После чего анализируем правило ниже.
А дальше есть два варианта. Ваше правило избыточно и достаточно обойтись одним обобщающим, либо текущее правило построено неверно и в него попадает лишний трафик.
💯17🤮3❤2👀2🤝2
Пожароопасность ПК
Еще одна важная тема эксплуатации электронных устройств, особенно если эта эксплуатация происходит без постоянного контроля. Какая вероятность что ваш ПК и связанные с ним компоненты станут причиной пожара?
Можно строить множество предположений, но опираясь на собственный опыт и опыт собственной организации мы рискуем столкнуться с «ошибкой выжившего», т.е. если со мной этого не произошло, то и у остальных происходить не должно.
Поэтому будем опираться на статистику, нам удалось при помощи ИИ найти и обобщить статистику пожарной службы США за последние несколько лет.
Начнем со специализированных IT-помещений, не являющихся дата-центрами. За год в среднем регистрируется 1 259 пожаров, из которых 78% связаны с ИБП. Именно ИБП является наиболее пожароопасным элементом инфраструктуры.
По мере перехода с кислотно-свинцовых на литий-ионные батареи количество инцидентов с ИБП выросло на 66%. При этом 30% случаев вызвано возгоранием собственно батарей.
Согласно опросу страховой компании Aviva, 54% предприятий сталкивались с инцидентами, связанными с литий-ионными батареями (перегрев, искрение, задымление), а 13% пережили полноценные пожары.
Также все крупные пожары в дата-центрах были вызваны проблемами с аккумуляторами систем бесперебойного питания.
Поэтому, если в вашем домашнем хозяйстве или загородном доме, даче используются ИБП – им следует уделить наибольшее внимание. Не забывать про сроки сервисного обслуживания, а таже постоянно контролировать состояние батарей и их температуру.
Также не следует размещать ИБП рядом с горючими материалами, в мебели и т.д. и т.п. А в городе вообще подумать – а нужен ли он вам дома вообще?
Что касается домашних пожаров, по статистике все той же пожарной службы США по причине электроприборов ежегодно происходит 45 000-55 000 пожаров, что составляет 4.9% всех жилых пожаров и вторую по величине причину возгораний.
Первая причина – кухонное оборудование - 165,600 пожаров, 46%.
Так как бесперебойники дома явление достаточно редкое, то пальму первенства в своей категории держат удлинители – 4 600 домашних пожаров ежегодно или 10% в своей группе. Основные причины возгорания удлинителей – перегрузка по мощности, последовательное включение удлинителей только увеличивает вероятность пожара.
Это вполне реалистичная оценка, потому что я уверен, что каждый их нас имел инциденты с удлинителями – перегрев, оплавление пластика, шипение, искры. В жилых помещениях, где постоянно находятся люди это не представляет серьезной проблемы. Но вот при отсутствии должного присмотра – до беды недалеко.
Правило тут одно – берите удлинитель с запасом, хорошего, проверенного производителя. Оснащенный термовыключателем. И не собирайте гирлянды из удлинителей, особенно там, где присмотр за ними затруднен.
Блоки питания тоже горят, хотя достаточно редко - 120-150 пожаров в год (или 0,3% в своей категории). Но сбрасывать их со счетов тоже не стоит – раз в год и палка стреляет.
Если не брать блоки питания заведомо низкого качества, то основная проблема сводится к пыли, которая приводит к замыканию высоковольтной части с последующим возгоранием этой же самой пыли.
Но в целом вероятность пожара от ИБП или удлинителя куда более реальна.
Также довольно интересна статистика пожарной службы Великобритании, 25% пожаров на рабочих местах в офисах связана с возгоранием ПК. При этом статистика не раскрывает более подробную причину пожаров: ИБП, удлинитель, блок питания или еще что-либо.
При этом следует иметь ввиду, что несмотря на то, что пальму первенства по причинам пожара держат ИБП в группу риска входят любые устройства с АКБ, особенно литий-ионными и оставленные на длительное время без присмотра в режиме подключения к сети также способны привести к пожару.
Еще одна важная тема эксплуатации электронных устройств, особенно если эта эксплуатация происходит без постоянного контроля. Какая вероятность что ваш ПК и связанные с ним компоненты станут причиной пожара?
Можно строить множество предположений, но опираясь на собственный опыт и опыт собственной организации мы рискуем столкнуться с «ошибкой выжившего», т.е. если со мной этого не произошло, то и у остальных происходить не должно.
Поэтому будем опираться на статистику, нам удалось при помощи ИИ найти и обобщить статистику пожарной службы США за последние несколько лет.
Начнем со специализированных IT-помещений, не являющихся дата-центрами. За год в среднем регистрируется 1 259 пожаров, из которых 78% связаны с ИБП. Именно ИБП является наиболее пожароопасным элементом инфраструктуры.
По мере перехода с кислотно-свинцовых на литий-ионные батареи количество инцидентов с ИБП выросло на 66%. При этом 30% случаев вызвано возгоранием собственно батарей.
Согласно опросу страховой компании Aviva, 54% предприятий сталкивались с инцидентами, связанными с литий-ионными батареями (перегрев, искрение, задымление), а 13% пережили полноценные пожары.
Также все крупные пожары в дата-центрах были вызваны проблемами с аккумуляторами систем бесперебойного питания.
Поэтому, если в вашем домашнем хозяйстве или загородном доме, даче используются ИБП – им следует уделить наибольшее внимание. Не забывать про сроки сервисного обслуживания, а таже постоянно контролировать состояние батарей и их температуру.
Также не следует размещать ИБП рядом с горючими материалами, в мебели и т.д. и т.п. А в городе вообще подумать – а нужен ли он вам дома вообще?
Что касается домашних пожаров, по статистике все той же пожарной службы США по причине электроприборов ежегодно происходит 45 000-55 000 пожаров, что составляет 4.9% всех жилых пожаров и вторую по величине причину возгораний.
Первая причина – кухонное оборудование - 165,600 пожаров, 46%.
Так как бесперебойники дома явление достаточно редкое, то пальму первенства в своей категории держат удлинители – 4 600 домашних пожаров ежегодно или 10% в своей группе. Основные причины возгорания удлинителей – перегрузка по мощности, последовательное включение удлинителей только увеличивает вероятность пожара.
Это вполне реалистичная оценка, потому что я уверен, что каждый их нас имел инциденты с удлинителями – перегрев, оплавление пластика, шипение, искры. В жилых помещениях, где постоянно находятся люди это не представляет серьезной проблемы. Но вот при отсутствии должного присмотра – до беды недалеко.
Правило тут одно – берите удлинитель с запасом, хорошего, проверенного производителя. Оснащенный термовыключателем. И не собирайте гирлянды из удлинителей, особенно там, где присмотр за ними затруднен.
Блоки питания тоже горят, хотя достаточно редко - 120-150 пожаров в год (или 0,3% в своей категории). Но сбрасывать их со счетов тоже не стоит – раз в год и палка стреляет.
Если не брать блоки питания заведомо низкого качества, то основная проблема сводится к пыли, которая приводит к замыканию высоковольтной части с последующим возгоранием этой же самой пыли.
Но в целом вероятность пожара от ИБП или удлинителя куда более реальна.
Также довольно интересна статистика пожарной службы Великобритании, 25% пожаров на рабочих местах в офисах связана с возгоранием ПК. При этом статистика не раскрывает более подробную причину пожаров: ИБП, удлинитель, блок питания или еще что-либо.
При этом следует иметь ввиду, что несмотря на то, что пальму первенства по причинам пожара держат ИБП в группу риска входят любые устройства с АКБ, особенно литий-ионными и оставленные на длительное время без присмотра в режиме подключения к сети также способны привести к пожару.
🔥16👍13❤1🤔1
Куда собрались цены?
Последние недели многие столкнулись с резким ростом цен на оперативную память и не столь резким, но все-таки ощутимым ростом цен SSD дисков.
Для тех, кто откладывал покупку к Новому году получился крайне неприятный сюрприз. Особенно если учесть, что после Нового года нас ждет очередной виток повышения цен, только уже связанный с событиями в отечественной экономике.
В настоящий момент стоимость оперативной памяти по сравнению с осенью этого года выросла в 2,5 – 3 раза, стоимость твердотельных дисков примерно в 1,5 раза. Это означает, что средний системны блок «для работы и учебы» обойдется вам примерно на 10 000 рублей дороже.
Причины такого роста – ажиотажный спрос на память со стороны дата-центров искусственного интеллекта, что привело к глобальному дефициту и стремительному росту цен. И это пока не предел.
Поэтому если кто-то что-то планировал – то не откладывайте покупки на завтра, пока еще можно найти комплектующие из старых запасов по более-менее приемлемым ценам, но с каждым днем таких предложений все меньше.
Пересидеть тоже не получится, мировой дефицит, может быть, и снизится, только вот повышение НДС и отмена налоговых льгот сделают свое дело и о понижении цен останется только мечтать.
Последние недели многие столкнулись с резким ростом цен на оперативную память и не столь резким, но все-таки ощутимым ростом цен SSD дисков.
Для тех, кто откладывал покупку к Новому году получился крайне неприятный сюрприз. Особенно если учесть, что после Нового года нас ждет очередной виток повышения цен, только уже связанный с событиями в отечественной экономике.
В настоящий момент стоимость оперативной памяти по сравнению с осенью этого года выросла в 2,5 – 3 раза, стоимость твердотельных дисков примерно в 1,5 раза. Это означает, что средний системны блок «для работы и учебы» обойдется вам примерно на 10 000 рублей дороже.
Причины такого роста – ажиотажный спрос на память со стороны дата-центров искусственного интеллекта, что привело к глобальному дефициту и стремительному росту цен. И это пока не предел.
Поэтому если кто-то что-то планировал – то не откладывайте покупки на завтра, пока еще можно найти комплектующие из старых запасов по более-менее приемлемым ценам, но с каждым днем таких предложений все меньше.
Пересидеть тоже не получится, мировой дефицит, может быть, и снизится, только вот повышение НДС и отмена налоговых льгот сделают свое дело и о понижении цен останется только мечтать.
🤬18🌭1
Вышло обновление Proxmox Backup Server 4.1
Раньше была поговорка - до первого сервис-пака не обновляем. Сегодня ситуация поменялась не сильно. Обновлять продуктивные среды имеет смысл только после первого минорного обновления.
Что нового?
▫️ Осуществлена синхронизация с пакетной базой дистрибутива Debian 13.2. Обновлены ядро Linux 6.17.2 и OpenZFS 2.3.4.
▫️ Предоставлена возможность управлением пропускной способностью для ограничения трафика при передаче по сети резервных копий в привязке к пользователю, запустившему резервное копирование (ранее лимиты могли задаваться в привязке к подсетям).
▫️ Добавлена возможность настройки числа одновременно выполняемых задач проверки целостности резервных копий для оптимальной утилизации имеющихся системных ресурсов.
▫️ Добавлена предварительная поддержка ограничения интенсивности обмена данными с хранилищами на базе протокола AWS S3 для снижения негативного влияния передачи резервных копий на другие задачи.
▫️ Web-интерфейс оптимизирован для работы на экранах с высоким разрешением.
▫️ Реализована поддержка автоматического отмонтирования внешних подключаемых хранилищ после завершения синхронизации данных (систему теперь можно настроить так, чтобы при подключении накопителя автоматически запускался процесс синхронизации данных, а после окончания синхронизации накопитель автоматически отмонтировался).
В целом практически все нужное и полезное, так как гибкое управление ресурсами - это именно то, чего не хватало и приходилось идти на компромиссы или упираться в железо или канал.
Продукт развивается, причем развивается эволюционно и это радует.
Раньше была поговорка - до первого сервис-пака не обновляем. Сегодня ситуация поменялась не сильно. Обновлять продуктивные среды имеет смысл только после первого минорного обновления.
Что нового?
▫️ Осуществлена синхронизация с пакетной базой дистрибутива Debian 13.2. Обновлены ядро Linux 6.17.2 и OpenZFS 2.3.4.
▫️ Предоставлена возможность управлением пропускной способностью для ограничения трафика при передаче по сети резервных копий в привязке к пользователю, запустившему резервное копирование (ранее лимиты могли задаваться в привязке к подсетям).
▫️ Добавлена возможность настройки числа одновременно выполняемых задач проверки целостности резервных копий для оптимальной утилизации имеющихся системных ресурсов.
▫️ Добавлена предварительная поддержка ограничения интенсивности обмена данными с хранилищами на базе протокола AWS S3 для снижения негативного влияния передачи резервных копий на другие задачи.
▫️ Web-интерфейс оптимизирован для работы на экранах с высоким разрешением.
▫️ Реализована поддержка автоматического отмонтирования внешних подключаемых хранилищ после завершения синхронизации данных (систему теперь можно настроить так, чтобы при подключении накопителя автоматически запускался процесс синхронизации данных, а после окончания синхронизации накопитель автоматически отмонтировался).
В целом практически все нужное и полезное, так как гибкое управление ресурсами - это именно то, чего не хватало и приходилось идти на компромиссы или упираться в железо или канал.
Продукт развивается, причем развивается эволюционно и это радует.
👍42🔥2
Устанавливаем OpenVPN в LXC-контейнер
Контейнеры LXC пользуются заслуженной популярностью и широко используются в системе виртуализации Proxmox.
Однако если вы попытаетесь развернуть в контейнере не менее популярный OpenVPN, то у вас ничего не получится.
Но не стоит отчаиваться, решение есть, и оно простое. Только совсем не очевидное. Поэтому мы и решили после очередного вопроса написать эту заметку.
Открываем на хосте виртуализации
Сохраняем изменения, запускаем контейнер и спокойно устанавливаем в него OpenVPN как обычно, или запускаем уже установленный.
Контейнеры LXC пользуются заслуженной популярностью и широко используются в системе виртуализации Proxmox.
Однако если вы попытаетесь развернуть в контейнере не менее популярный OpenVPN, то у вас ничего не получится.
Но не стоит отчаиваться, решение есть, и оно простое. Только совсем не очевидное. Поэтому мы и решили после очередного вопроса написать эту заметку.
Открываем на хосте виртуализации
/etc/pve/lxc/ctid.conf, где ctid.conf – конфигурационный файл нужного контейнера и добавляем в него следующие две строки:lxc.mount.entry: /dev/net dev/net none bind,create=dir
lxc.cgroup2.devices.allow: c 10:200 rwm
Сохраняем изменения, запускаем контейнер и спокойно устанавливаем в него OpenVPN как обычно, или запускаем уже установленный.
👍29❤6
Особенности установки УТМ ЕГАИС на Debian 13
Сегодня попробовали установить УТМ ЕГАИС на свежий дистрибутив Debian 13. Сама установка не вызывает особых сложностей и ее можно выполнить по нашей статье:
🔹 ЕГАИС. Устанавливаем УТМ 4.2.0 на Debian (Ubuntu)
При этом, вместо
Сам пакет u-trans тоже ставится без особых проблем, запускается, но не работает. Если вы откроете лог, то увидите, что УТМ не может обнаружить ключ. Странно, ведь инсталлятор увидел Рутокен и инструменты диагностики тоже его видят.
Поэтому читаем лог дальше и находим интересные записи:
Это значит, что библиотека требует наличия executable stack (исполняемый стек), который отключен в Debian 13 по соображениями безопасности (а также в Ubuntu, начиная с 25.10).
👆 Включить данную технологию не представляется возможным (во всяком случае без глубокого изменения системы), поэтому можно считать, что УТМ ЕГАИС несовместим с Debian 13 и грядущей Ubuntu 26.04 LTS.
😉 Ну если, конечно, разработчики Росалкогольтабакконтроль не перепишут программу, но надежды на это призрачные, с учетом того, что u-trans для Linux до сих пор 32-битное приложение.
С другой стороны, у нас все-таки Linux и каждый тут сам кузнец собственного счастья. Указанные в ошибках библиотеки являются библиотеками PKCS11Lib от Рутокен и поставляются вместе с пакетом УТМ.
Поэтому мы можем заменить их на более современные версии библиотек от Рутокен, которые не требуют executable stack.
Скачать их можно на https://download.rutoken.ru в разделе /Rutoken/PKCS11Lib/Current/Linux/x32/, просто качаем
Для этого перейдем в домашнюю папку и скачаем библиотеку через wget, в нашем случае это последняя на сегодня версия, вам же потребуется уточнить версию библиотеки:
Затем останавливаем УТМ, заменяем необходимые библиотеки (их там две копии) и снова запускаем УТМ:
После чего все запускается и отлично работает. Посмотреть лог УТМ в реальном времени можно командой:
Но данное действие вам придется выполнять всякий раз после переустановки или обновления УТМ.
❗️Также обратите внимание, что данный способ проверен только с токенами Рутокен и работа с JaCarta не проверялась и не гарантируется.
👉 Кроме того, добавим – непосредственной необходимости ставить УТМ ЕГАИС на Debian 13 в текущий момент нет, сервис это сугубо внутренний и при необходимости может эксплуатироваться даже на устаревших версиях системы.
Сегодня попробовали установить УТМ ЕГАИС на свежий дистрибутив Debian 13. Сама установка не вызывает особых сложностей и ее можно выполнить по нашей статье:
🔹 ЕГАИС. Устанавливаем УТМ 4.2.0 на Debian (Ubuntu)
При этом, вместо
libncurses5:i386 следует устанавливать libncurses6:i386, а библиотека SSL называется libssl3t64 и скорее всего будет установлена по умолчанию.Сам пакет u-trans тоже ставится без особых проблем, запускается, но не работает. Если вы откроете лог, то увидите, что УТМ не может обнаружить ключ. Странно, ведь инсталлятор увидел Рутокен и инструменты диагностики тоже его видят.
Поэтому читаем лог дальше и находим интересные записи:
/opt/utm/lib/librtpkcsllecp.so: невозможно задействовать исполняемый стек, как требует разделяемый объект
Это значит, что библиотека требует наличия executable stack (исполняемый стек), который отключен в Debian 13 по соображениями безопасности (а также в Ubuntu, начиная с 25.10).
👆 Включить данную технологию не представляется возможным (во всяком случае без глубокого изменения системы), поэтому можно считать, что УТМ ЕГАИС несовместим с Debian 13 и грядущей Ubuntu 26.04 LTS.
😉 Ну если, конечно, разработчики Росалкогольтабакконтроль не перепишут программу, но надежды на это призрачные, с учетом того, что u-trans для Linux до сих пор 32-битное приложение.
С другой стороны, у нас все-таки Linux и каждый тут сам кузнец собственного счастья. Указанные в ошибках библиотеки являются библиотеками PKCS11Lib от Рутокен и поставляются вместе с пакетом УТМ.
Поэтому мы можем заменить их на более современные версии библиотек от Рутокен, которые не требуют executable stack.
Скачать их можно на https://download.rutoken.ru в разделе /Rutoken/PKCS11Lib/Current/Linux/x32/, просто качаем
librtpkcs11ecp.so. Для этого перейдем в домашнюю папку и скачаем библиотеку через wget, в нашем случае это последняя на сегодня версия, вам же потребуется уточнить версию библиотеки:
cd ~
wget https://download.rutoken.ru/Rutoken/PKCS11Lib/Current/Linux/x32/librtpkcs11ecp.so
Затем останавливаем УТМ, заменяем необходимые библиотеки (их там две копии) и снова запускаем УТМ:
supervisorctl stop utm
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp.so
cp -v librtpkcs11ecp.so /opt/utm/lib/librtpkcs11ecp-replica.so
supervisorctl start utm
После чего все запускается и отлично работает. Посмотреть лог УТМ в реальном времени можно командой:
tail -f /opt/utm/transport/l/transport_info.log
Но данное действие вам придется выполнять всякий раз после переустановки или обновления УТМ.
❗️Также обратите внимание, что данный способ проверен только с токенами Рутокен и работа с JaCarta не проверялась и не гарантируется.
👉 Кроме того, добавим – непосредственной необходимости ставить УТМ ЕГАИС на Debian 13 в текущий момент нет, сервис это сугубо внутренний и при необходимости может эксплуатироваться даже на устаревших версиях системы.
👍34❤7🤝2
Автоматически обновляем списки адресов Cloudflare на Mikrotik
Что такое Cloudflare – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают не совсем понятные и совсем неприятные сложности с процессом хождения туда, не знаю куда. А ведь надо не только дойти, но и принести назад то, не знаю что.
А эти самые адреса иногда меняются, да и заполнять их каждый раз руками – тоже удовольствие ниже среднего.
Сам список секрета не представляет и Cloudflare его официально публикует на страничке https://www.cloudflare.com/ips-v4
Поэтому мы подумали-подумали и призвав на помощь ИИ быстренько написали скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
👇👇👇
Что такое Cloudflare – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают не совсем понятные и совсем неприятные сложности с процессом хождения туда, не знаю куда. А ведь надо не только дойти, но и принести назад то, не знаю что.
А эти самые адреса иногда меняются, да и заполнять их каждый раз руками – тоже удовольствие ниже среднего.
Сам список секрета не представляет и Cloudflare его официально публикует на страничке https://www.cloudflare.com/ips-v4
Поэтому мы подумали-подумали и призвав на помощь ИИ быстренько написали скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
👇👇👇
10🔥23❤2
Еще раз про «соединения» WireGuard
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и инициатором одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и инициатором одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
4👍55❤8🤝4🥱1
Почему после внесения изменений в конфигурацию брандмауэра лучше перезагрузить роутер
Эта история произошла на днях с одним коллегой. В очередной раз внося изменения в конфигурацию брандмауэра Mikrotik он обнаружил правила, которые, согласно комментариям, относились к IPsec, который уже давно не использовался.
Он сбросил на них счетчики и несколько дней понаблюдал – счетчики не менялись. После чего он просто выключил эти правила. Ничего не сломалось и все продолжило работать как работало. На том он благополучно и забыл об этой истории.
Напомнила она о себе совсем недавно. Менеджеры стали жаловаться, что обмен с некоторыми точками происходит ну очень медленно.
Стали разбираться и выяснилось, что не так давно отвалились все входящие L2TP-соединения от точек и трафик для них пошел по медленному резервному пути.
А почему отвалились? Потому что не смогли собрать IPsec, по причине выключенных правил брандмауэра.
Так погодите, но работало же все? Правила еще когда изменились, а случилось все только сейчас.
Но это вполне нормальное поведение, в любом правильно настроенном брандмауэре на базе iptables, включая Mikrotik, первым в цепочках стоит правило, разрешающее уже установленные соединения – ESTABLISHED. И все существующие соединения будут проходить именно через него, не двигаясь по цепочкам дальше.
Поэтому вы можете хоть сто раз поменять нижестоящие правила, но действовать они начнут только для новых соединений. А если у нас каналы связи стабильны и соединения не отваливаются по таймауту, то существовать такая ситуация может бесконечно долго.
В нашем случае триггером стала перезагрузка роутера. После чего L2TP соединения, которые из установленных стали новыми устанавливаться перестали.
Поэтому, если вы не хотите неприятных неожиданностей в самый неподходящий момент – после внесения изменений в брандмауэр обязательно перезагрузите роутер. Возможно, узнаете много интересного.
Эта история произошла на днях с одним коллегой. В очередной раз внося изменения в конфигурацию брандмауэра Mikrotik он обнаружил правила, которые, согласно комментариям, относились к IPsec, который уже давно не использовался.
Он сбросил на них счетчики и несколько дней понаблюдал – счетчики не менялись. После чего он просто выключил эти правила. Ничего не сломалось и все продолжило работать как работало. На том он благополучно и забыл об этой истории.
Напомнила она о себе совсем недавно. Менеджеры стали жаловаться, что обмен с некоторыми точками происходит ну очень медленно.
Стали разбираться и выяснилось, что не так давно отвалились все входящие L2TP-соединения от точек и трафик для них пошел по медленному резервному пути.
А почему отвалились? Потому что не смогли собрать IPsec, по причине выключенных правил брандмауэра.
Так погодите, но работало же все? Правила еще когда изменились, а случилось все только сейчас.
Но это вполне нормальное поведение, в любом правильно настроенном брандмауэре на базе iptables, включая Mikrotik, первым в цепочках стоит правило, разрешающее уже установленные соединения – ESTABLISHED. И все существующие соединения будут проходить именно через него, не двигаясь по цепочкам дальше.
Поэтому вы можете хоть сто раз поменять нижестоящие правила, но действовать они начнут только для новых соединений. А если у нас каналы связи стабильны и соединения не отваливаются по таймауту, то существовать такая ситуация может бесконечно долго.
В нашем случае триггером стала перезагрузка роутера. После чего L2TP соединения, которые из установленных стали новыми устанавливаться перестали.
Поэтому, если вы не хотите неприятных неожиданностей в самый неподходящий момент – после внесения изменений в брандмауэр обязательно перезагрузите роутер. Возможно, узнаете много интересного.
👍51🤷♂6💯4❤1🤮1
Влияние антивирусов на производительность 1С
После выхода нашего материала:
🔹 Почему тормозит 1С. Файловый режим и Microsoft Defender
Нас неоднократно просили проверить влияние других антивирусов на производительность 1С:Предприятие.
Наконец мы нашли время и провели небольшое исследование.
Тестовый стенд:
▫️Windows 11 24H2
▫️1С:Предприятие 8.3.27.1786
▫️Тест Гилева 2.1.1.38
В тестировании принимали участие:
🔸 Windows Defender, антивирус по умолчанию, весьма широко распространен по принципу: уже есть, работает, есть не просит.
🔸 Kaspersky Standard – ведущий в РФ и очень популярный производитель антивирусного ПО, бесплатная версия может быть установлена на ПК по умолчанию
🔸 Dr.Web Security Space – еще один лидер рынка отечественных антивирусов, имеет свою армию поклонников.
🔸 PRO32 – импортозамещенный NOD32, продолжает пользоваться популярностью в определенных кругах, по степени распространения примерно как Dr.Web.
🔸 360 Total Security – бесплатный продукт от наших китайских товарищей, весьма распространен среди любителей бесплатных антивирусов.
👉 В результате нами были получены следующие результаты:
▫️Без антивируса 100% (0%)
▫️Kaspersky Standard 84% (-16%)
▫️Dr.Web Security Space 87% (-13%)
▫️PRO 32 89% (-11%)
▫️360 Total Security (-6%)
▫️Windows Defender 35% (-65%)
👆 Большинство именитых антивирусов показало довольно небольшую просадку производительности 11-16%, что, конечно, неприятно, но не сильно критично.
💪 Лучший результат оказался у 360 Total Security – всего минус 6%, про эффективность данного антивируса говорить ничего не будем, так как не располагаем объективными данными.
🤦♀️ Ну и Windows Defender – это просто катастрофа, падение производительности в три раза. Поэтому при его использовании обязательно вносите 1С в исключение, готовый скрипт можете взять в нашей статье.
После выхода нашего материала:
🔹 Почему тормозит 1С. Файловый режим и Microsoft Defender
Нас неоднократно просили проверить влияние других антивирусов на производительность 1С:Предприятие.
Наконец мы нашли время и провели небольшое исследование.
Тестовый стенд:
▫️Windows 11 24H2
▫️1С:Предприятие 8.3.27.1786
▫️Тест Гилева 2.1.1.38
В тестировании принимали участие:
🔸 Windows Defender, антивирус по умолчанию, весьма широко распространен по принципу: уже есть, работает, есть не просит.
🔸 Kaspersky Standard – ведущий в РФ и очень популярный производитель антивирусного ПО, бесплатная версия может быть установлена на ПК по умолчанию
🔸 Dr.Web Security Space – еще один лидер рынка отечественных антивирусов, имеет свою армию поклонников.
🔸 PRO32 – импортозамещенный NOD32, продолжает пользоваться популярностью в определенных кругах, по степени распространения примерно как Dr.Web.
🔸 360 Total Security – бесплатный продукт от наших китайских товарищей, весьма распространен среди любителей бесплатных антивирусов.
👉 В результате нами были получены следующие результаты:
▫️Без антивируса 100% (0%)
▫️Kaspersky Standard 84% (-16%)
▫️Dr.Web Security Space 87% (-13%)
▫️PRO 32 89% (-11%)
▫️360 Total Security (-6%)
▫️Windows Defender 35% (-65%)
👆 Большинство именитых антивирусов показало довольно небольшую просадку производительности 11-16%, что, конечно, неприятно, но не сильно критично.
💪 Лучший результат оказался у 360 Total Security – всего минус 6%, про эффективность данного антивируса говорить ничего не будем, так как не располагаем объективными данными.
🤦♀️ Ну и Windows Defender – это просто катастрофа, падение производительности в три раза. Поэтому при его использовании обязательно вносите 1С в исключение, готовый скрипт можете взять в нашей статье.
👍29❤2🤝1
На что сейчас импортозаместиться?
Такой вопрос задают регулярно, как пользователи Windows, так и пользователи Linux. Поэтому решили коротко рассмотреть реалии рынка импортозамещения ОС конца 2025 года.
1️⃣ Astra Linux – лидер рынка импортозамещения, имеет наибольшее число внедрений и активно применяется в самых различных сферах. Технически представляет собой сильно переработанный Debian (актуальная версия использует пакетную базу Debian 12) со множеством доработок в направлении безопасности и разделения доступа.
Графическая оболочка представлена средой собственной разработки Fly, которая выполнена в классических традициях и позволяет полноценно использовать предыдущий пользовательский опыт.
Система неплохо документирована, но часть документации недоступна без наличия коммерческой поддержки. Частные лица легально приобрести и использовать систему не могут, но это можно обойти, получив бесплатно лицензию разработчика.
Имеется неплохое и весьма дружелюбное сообщество Дениса Давыдова, которое хотя и посвящено Астре в школах охотно помогает всем желающим.
2️⃣ ALT Linux – старейшая и полностью самобытная отечественная система, имеющая самый большой отечественный репозиторий. Использует множество собственных решений и подходов, иногда достаточно необычных, чего стоит только apt-rpm.
В экосистеме есть как настольные, так и серверные системы, включая средства виртуализации, например, импортозамещенный Proxmox. Это позволяет продолжать использовать привычные инструменты соблюдая все требования по импортозамещению.
Внешний вид настольных систем долгое время был больной темой для Альта, но начиная с 11 версии по умолчанию используется рабочий стол Gnome, который они еще не усели или не сумели испортить. Сама оболочка адаптирована для классического подхода к управлению системой.
Документации много, очень много, но она плохо структурирована и местами давно не обновлялась, поэтому официальная Wiki больше похожа на свалку, где разбираться в актуальности и достоверности информации придется самому.
Отдельно стоит отметить сообщество, оно славится своей токсичностью, что может отпугнуть новичков, тем более что различные некрасивые поступки позволяют себе не только пользователи, но и представители разработчиков.
3️⃣ РЕД ОС – третий крупный игрок рынка импортозамещения и самый недооцененный из них. При его появлении мало кто мог предсказать его стремительный взлет. Представляет собой классическую RPM-систему в стиле RHEL и рассчитана в первую очередь на бывших пользователей и администраторов RHEL-систем.
Первоначально технически это был еще один EL-клон, но начиная с восьмой версии разработчики РЕД ОС перешли на полностью собственную пакетную базу, которая хоть и продолжает являться RHEL-совместимой, но больше не является клоном EL.
Пользовательские редакции предусматривают использование графических сред Mate или KDE, но отсутствие современных графических систем управления пакетами делает ее нацеленной более на корпоративный сектор, хотя допускается бесплатное использование в личных, некоммерческих целях.
Проект имеет отличную документацию, можно сказать одну из лучших, которая может быть полезна всем пользователям Linux, а не только РЕД ОС. В целом можно рекомендовать как отличную альтернативу, если ни Альт, ни Астра не пришлись вам ко двору.
4️⃣ МСВСфера – относительный новичок на рынке импортозамещения. Не так давно система сменила владельца и теперь не имеет никакого отношения к вооруженным силам и позиционируется, как ОС общего применения.
По факту это единственный на сегодня импортозамещенный клон EL, т.е. система на 100% совместимая с RHEL. В настоящий момент актуальная версия МСВСфера 9 соответствует платформе EL 9.7.
Собственно, это все, что нужно сказать об этой системе. Кто работал с EL, тот может продолжать использовать привычную среду без переучивания. Также как любые материалы по EL системам полностью применимы и МСВСфера, что делает ее освоение достаточно простым процессом.
Такой вопрос задают регулярно, как пользователи Windows, так и пользователи Linux. Поэтому решили коротко рассмотреть реалии рынка импортозамещения ОС конца 2025 года.
1️⃣ Astra Linux – лидер рынка импортозамещения, имеет наибольшее число внедрений и активно применяется в самых различных сферах. Технически представляет собой сильно переработанный Debian (актуальная версия использует пакетную базу Debian 12) со множеством доработок в направлении безопасности и разделения доступа.
Графическая оболочка представлена средой собственной разработки Fly, которая выполнена в классических традициях и позволяет полноценно использовать предыдущий пользовательский опыт.
Система неплохо документирована, но часть документации недоступна без наличия коммерческой поддержки. Частные лица легально приобрести и использовать систему не могут, но это можно обойти, получив бесплатно лицензию разработчика.
Имеется неплохое и весьма дружелюбное сообщество Дениса Давыдова, которое хотя и посвящено Астре в школах охотно помогает всем желающим.
2️⃣ ALT Linux – старейшая и полностью самобытная отечественная система, имеющая самый большой отечественный репозиторий. Использует множество собственных решений и подходов, иногда достаточно необычных, чего стоит только apt-rpm.
В экосистеме есть как настольные, так и серверные системы, включая средства виртуализации, например, импортозамещенный Proxmox. Это позволяет продолжать использовать привычные инструменты соблюдая все требования по импортозамещению.
Внешний вид настольных систем долгое время был больной темой для Альта, но начиная с 11 версии по умолчанию используется рабочий стол Gnome, который они еще не усели или не сумели испортить. Сама оболочка адаптирована для классического подхода к управлению системой.
Документации много, очень много, но она плохо структурирована и местами давно не обновлялась, поэтому официальная Wiki больше похожа на свалку, где разбираться в актуальности и достоверности информации придется самому.
Отдельно стоит отметить сообщество, оно славится своей токсичностью, что может отпугнуть новичков, тем более что различные некрасивые поступки позволяют себе не только пользователи, но и представители разработчиков.
3️⃣ РЕД ОС – третий крупный игрок рынка импортозамещения и самый недооцененный из них. При его появлении мало кто мог предсказать его стремительный взлет. Представляет собой классическую RPM-систему в стиле RHEL и рассчитана в первую очередь на бывших пользователей и администраторов RHEL-систем.
Первоначально технически это был еще один EL-клон, но начиная с восьмой версии разработчики РЕД ОС перешли на полностью собственную пакетную базу, которая хоть и продолжает являться RHEL-совместимой, но больше не является клоном EL.
Пользовательские редакции предусматривают использование графических сред Mate или KDE, но отсутствие современных графических систем управления пакетами делает ее нацеленной более на корпоративный сектор, хотя допускается бесплатное использование в личных, некоммерческих целях.
Проект имеет отличную документацию, можно сказать одну из лучших, которая может быть полезна всем пользователям Linux, а не только РЕД ОС. В целом можно рекомендовать как отличную альтернативу, если ни Альт, ни Астра не пришлись вам ко двору.
4️⃣ МСВСфера – относительный новичок на рынке импортозамещения. Не так давно система сменила владельца и теперь не имеет никакого отношения к вооруженным силам и позиционируется, как ОС общего применения.
По факту это единственный на сегодня импортозамещенный клон EL, т.е. система на 100% совместимая с RHEL. В настоящий момент актуальная версия МСВСфера 9 соответствует платформе EL 9.7.
Собственно, это все, что нужно сказать об этой системе. Кто работал с EL, тот может продолжать использовать привычную среду без переучивания. Также как любые материалы по EL системам полностью применимы и МСВСфера, что делает ее освоение достаточно простым процессом.
👍27🤡6❤4🤔4👎3