Закат 32-битной эпохи
Вышедший в августе Debian 13 расстроил ретроградов, один из последних оплотов 32-битной архитектуры отказался от ее полноценной поддержки и не выпустил 32-разрядной версии дистрибутива.
При этом сама архитектура остается доступной в целях обратной совместимости, т.е. вы можете подключить 32-битные репозитории к своей 32-битной системе и получить оттуда необходимые пакеты. Это может потребоваться для запуска устаревшего ПО, которое не имеет 64-битной версии.
Напомним, что до этого практически все ведущие дистрибутивы прекратили поддержку 32-битной архитектуры гораздо ранее, так для Ubuntu последним выпуском с поддержкой 32-бит был выпуск 18.04 LTS, а Fedora прекратила сборку 32-битных дистрибутивов начиная с выпуска 31 в 2019 году.
FreeBSD тоже решило нанести «удар в спину» и также отказывается от поддержки 32-битного дистрибутива начиная с 15 выпуска запланированного на конец этого года.
И это, в общем и целом, правильно. Сегодня уже практически не осталось адекватного современным требованиям железа, не поддерживающего 32-битные инструкции. Сегодня запускать 64-битный код может практически каждый чайник и утюг, особенно если мы говорим об архитектуре x86.
При этом полностью от поддержки 32-битных приложений пока никто не отказывается, вы можете их спокойно запускать на своих 64-битных системах и даже подключать репозитории с 32-битными пакетами.
Но они, честно говоря, не являются «настоящими» 32-битными, если мы подразумеваем под этим классические архитектуры i586/686. Данные пакеты собраны в среде современных ОС и требуют поддержки инструкций присутствующих в современных процессорах.
Но это, как раз понятно, потому как их цель не поддержка устаревших процессоров, а продление жизни старого ПО, не имеющего 64-битных версий при обеспечении для него нормального быстродействия и максимального использования всех преимуществ современных платформ.
И тем удивительнее сегодня слышать просьбы найти именно 32-битный пакет для того или иного ПО. Потому как никакого практического смысла сегодня это не имеет. Платформ не поддерживающих 64-бита (не считая какой-нибудь экзотики или промышленного оборудования) в широкой эксплуатации нет. Поэтому и нет смысла держаться за старое. Ведь никто же сегодня не сетует на отсутствие поддержки 16-бит?
Вышедший в августе Debian 13 расстроил ретроградов, один из последних оплотов 32-битной архитектуры отказался от ее полноценной поддержки и не выпустил 32-разрядной версии дистрибутива.
При этом сама архитектура остается доступной в целях обратной совместимости, т.е. вы можете подключить 32-битные репозитории к своей 32-битной системе и получить оттуда необходимые пакеты. Это может потребоваться для запуска устаревшего ПО, которое не имеет 64-битной версии.
Напомним, что до этого практически все ведущие дистрибутивы прекратили поддержку 32-битной архитектуры гораздо ранее, так для Ubuntu последним выпуском с поддержкой 32-бит был выпуск 18.04 LTS, а Fedora прекратила сборку 32-битных дистрибутивов начиная с выпуска 31 в 2019 году.
FreeBSD тоже решило нанести «удар в спину» и также отказывается от поддержки 32-битного дистрибутива начиная с 15 выпуска запланированного на конец этого года.
И это, в общем и целом, правильно. Сегодня уже практически не осталось адекватного современным требованиям железа, не поддерживающего 32-битные инструкции. Сегодня запускать 64-битный код может практически каждый чайник и утюг, особенно если мы говорим об архитектуре x86.
При этом полностью от поддержки 32-битных приложений пока никто не отказывается, вы можете их спокойно запускать на своих 64-битных системах и даже подключать репозитории с 32-битными пакетами.
Но они, честно говоря, не являются «настоящими» 32-битными, если мы подразумеваем под этим классические архитектуры i586/686. Данные пакеты собраны в среде современных ОС и требуют поддержки инструкций присутствующих в современных процессорах.
Но это, как раз понятно, потому как их цель не поддержка устаревших процессоров, а продление жизни старого ПО, не имеющего 64-битных версий при обеспечении для него нормального быстродействия и максимального использования всех преимуществ современных платформ.
И тем удивительнее сегодня слышать просьбы найти именно 32-битный пакет для того или иного ПО. Потому как никакого практического смысла сегодня это не имеет. Платформ не поддерживающих 64-бита (не считая какой-нибудь экзотики или промышленного оборудования) в широкой эксплуатации нет. Поэтому и нет смысла держаться за старое. Ведь никто же сегодня не сетует на отсутствие поддержки 16-бит?
👍39❤1
Zabbix get – получаем информацию от Zabbix через CLI
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
Или аптайм:
А вот при попытке получить утилизацию памяти в % получим ошибку:
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
apt install zabbix-get
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
Server агента, в противном случае вы получите ошибку:Check access restrictions in Zabbix agent configuration
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
zabbix_get -s host-name-or-IP [-p port-number] -k item-key
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
zabbix_get -s 192.168.101.198 -p 10050 -k agent.ping
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
zabbix_get -s 192.168.101.198 -p 10050 -k system.cpu.util
Или аптайм:
zabbix_get -s 192.168.101.198 -p 10050 -k system.uptime
А вот при попытке получить утилизацию памяти в % получим ошибку:
zabbix_get -s 192.168.101.198 -k vm.memory.util
ZBX_NOTSUPPORTED: Unknown metric vm.memory.util
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
👍24🔥4❤2👀2
Профессия – программист
Сегодня пятница, поэтому, как это уже принято, поговорим на околотехнические темы. Тем более что есть определенная фактура, как говорится, из первых рук.
В этом году мой сын закончил 9 классов и успешно поступил в Колледж высоких технологий местного Университета на программирование. Но поступление было далеко не простым.
Дело в том, что наш регион как приграничный и прифронтовой (Белгородская область) выпускались по упрощенной схеме – без ЕГЭ и ОГЭ, по среднему баллу, а поступление осуществлялось на основе «конкурса аттестатов».
Что это значит? А это значит, что при поступлении имеет значение только средний балл аттестата. При этом если на программирование поступает ребенок, у которого пятерки по математике и информатике, но посредственные оценки по литературе, русскому, химии, географии и т.д., а вместе с ним подал документы троечник по математике/информатике, но отличник по гуманитарным наукам, то пройдет гуманитарий, так как балл его аттестата выше.
Добавляем туда любимчиков, активистов, личные приятственные или неприязненные отношения учителей и многое другое. Тем более что из школ в колледжи побежало в этом году практически 90-95% детей. Потому как потенциальное ЕГЭ через два года мало кого прельщает.
В итоге такой конкурс аттестатов мог спокойно перекрыть дорогу на «престижные» специальности действительно увлеченным детям, вместо которых возьмут тех, у кого аттестат лучше.
К счастью, наш колледж основан на базе Университета, который обладает определенной автономией, поэтому при приеме учитывали не только средний балл аттестата, но и реальные заслуги на профессиональном поприще.
А так как у сына были грамоты и дипломы от разных городских конкурсов по IT, программированию и робототехнике, в т.ч. и проводимых Университетом, то он уверенно прошел, несмотря на достаточно низкий балл аттестата (потому что забивал в школе на гуманитарку).
После поступления сходили познакомились с куратором, преподавателями и узнали много интересного. Но ничего нового я не услышал. История повторяется.
Сегодня на IT-специальности в целом и программирование в частности конкурс очень дикий. В сознании родителей эта сфера представляется некоторой синекурой, где достаточно иметь нужный диплом, и легкая обеспеченная жизнь гарантируется по умолчанию.
Кстати, наш куратор была в приемной комиссии и побеседовав с сыном тет-а-тет сказала: этого беру к себе и пофиг на балл в аттестате. Потому что опять наберем больше половины идиотов.
И это не фигура речи, потому что как можно поступать на программирование не умея сканировать и присылая фото с мобилы в документе Word?
Посему к Университету и его преподавателям поклон и уважение, что они стараются отбирать действительно увлеченных ребят и давать им возможность получить образование по выбранному профилю.
А остальные? Тут я хочу вернуться на 25-30 лет назад, в далекие и светлые, для кого-то «святые». Тогда было очень популярно учиться на юриста.
Юристов готовили юридические ВУЗы, гуманитарные, технические и даже сельскохозяйственные.
Для самой профессии пророчили упадок и замещение дешевыми кадрами, ну все это мы слышим и сейчас.
И что изменилось? Хорошие юристы как были поштучно, так и остались. Доходы их как были высокими, так и остались. Их как искали днем с огнем, так и ищут.
А куда делись все эти стада с «юридическим» образованием? Осели по «Пятерочкам» того времени и тому подобным организациям. Максимум в ИП Джамшут юристом, чисто потешить этого самого Джамшута эго, на зарплате продавца из «Пятерочки».
Точно также будет и с «программистами», жаль только тех ребят, которые действительно хотят, горят и желают, но не смогут пройти по чистой формальности, наподобие конкурса аттестатов.
Ну и родителям тоже надо задуматься. Хороший сантехник сегодня тоже на вес золота и зарабатывает не хуже, чем программист.
Сегодня пятница, поэтому, как это уже принято, поговорим на околотехнические темы. Тем более что есть определенная фактура, как говорится, из первых рук.
В этом году мой сын закончил 9 классов и успешно поступил в Колледж высоких технологий местного Университета на программирование. Но поступление было далеко не простым.
Дело в том, что наш регион как приграничный и прифронтовой (Белгородская область) выпускались по упрощенной схеме – без ЕГЭ и ОГЭ, по среднему баллу, а поступление осуществлялось на основе «конкурса аттестатов».
Что это значит? А это значит, что при поступлении имеет значение только средний балл аттестата. При этом если на программирование поступает ребенок, у которого пятерки по математике и информатике, но посредственные оценки по литературе, русскому, химии, географии и т.д., а вместе с ним подал документы троечник по математике/информатике, но отличник по гуманитарным наукам, то пройдет гуманитарий, так как балл его аттестата выше.
Добавляем туда любимчиков, активистов, личные приятственные или неприязненные отношения учителей и многое другое. Тем более что из школ в колледжи побежало в этом году практически 90-95% детей. Потому как потенциальное ЕГЭ через два года мало кого прельщает.
В итоге такой конкурс аттестатов мог спокойно перекрыть дорогу на «престижные» специальности действительно увлеченным детям, вместо которых возьмут тех, у кого аттестат лучше.
К счастью, наш колледж основан на базе Университета, который обладает определенной автономией, поэтому при приеме учитывали не только средний балл аттестата, но и реальные заслуги на профессиональном поприще.
А так как у сына были грамоты и дипломы от разных городских конкурсов по IT, программированию и робототехнике, в т.ч. и проводимых Университетом, то он уверенно прошел, несмотря на достаточно низкий балл аттестата (потому что забивал в школе на гуманитарку).
После поступления сходили познакомились с куратором, преподавателями и узнали много интересного. Но ничего нового я не услышал. История повторяется.
Сегодня на IT-специальности в целом и программирование в частности конкурс очень дикий. В сознании родителей эта сфера представляется некоторой синекурой, где достаточно иметь нужный диплом, и легкая обеспеченная жизнь гарантируется по умолчанию.
Кстати, наш куратор была в приемной комиссии и побеседовав с сыном тет-а-тет сказала: этого беру к себе и пофиг на балл в аттестате. Потому что опять наберем больше половины идиотов.
И это не фигура речи, потому что как можно поступать на программирование не умея сканировать и присылая фото с мобилы в документе Word?
Посему к Университету и его преподавателям поклон и уважение, что они стараются отбирать действительно увлеченных ребят и давать им возможность получить образование по выбранному профилю.
А остальные? Тут я хочу вернуться на 25-30 лет назад, в далекие и светлые, для кого-то «святые». Тогда было очень популярно учиться на юриста.
Юристов готовили юридические ВУЗы, гуманитарные, технические и даже сельскохозяйственные.
Для самой профессии пророчили упадок и замещение дешевыми кадрами, ну все это мы слышим и сейчас.
И что изменилось? Хорошие юристы как были поштучно, так и остались. Доходы их как были высокими, так и остались. Их как искали днем с огнем, так и ищут.
А куда делись все эти стада с «юридическим» образованием? Осели по «Пятерочкам» того времени и тому подобным организациям. Максимум в ИП Джамшут юристом, чисто потешить этого самого Джамшута эго, на зарплате продавца из «Пятерочки».
Точно также будет и с «программистами», жаль только тех ребят, которые действительно хотят, горят и желают, но не смогут пройти по чистой формальности, наподобие конкурса аттестатов.
Ну и родителям тоже надо задуматься. Хороший сантехник сегодня тоже на вес золота и зарабатывает не хуже, чем программист.
💯41👍11❤7🥱3🤣2
Электронная почта, подборка
По почте у нас написано довольно много, кроме того много было дописано недавно. И если недавние статьи больше практические, то более ранние важны с точки зрения теории, несмотря на их возраст. Почта - еще более старая технология с годами там менялось мало. особенно в фундаментальном плане.
🔶 Теория
🔹 Почтовый сервер для начинающих. Структура и принцип работы
🔹 Почтовый сервер для начинающих. Настраиваем DNS зону
🔹 Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом
🔹 Настраиваем свой почтовый сервер. Что нужно знать. Ликбез
🔹 Какие порты и для чего использует почтовый сервер. Ликбез
🔹 Как правильно настроить DNS-записи для мультидоменного почтового сервера
🔶 Практика. Почтовые сервера
🔹 Установка и настройка почтового сервера iRedMail с веб-клиентом SOGo и сертификатами Let's Encrypt
🔹 Установка и настройка почтового сервера Modoboa в Debian или Ubuntu
🔹 Установка и настройка почтового сервера Mail-in-a-Box в Ubuntu 22.04
🔶 Практика. Антиспам
🔹 Proxmox Mail Gateway - настраиваем пограничный почтовый шлюз
🔹 Используем API для автоматизации работы с Proxmox Mail Gateway
🔹 Обновляем Proxmox Mail Gateway с версии 7 до 8
🔶 Полезные инструменты
🔹 Онлайн инструменты для проверки почтового сервера
🔹 Проверка связи по протоколу SMTP с помощью Telnet
🔹 Перенос почтовых ящиков между серверами при помощи imapsync
По почте у нас написано довольно много, кроме того много было дописано недавно. И если недавние статьи больше практические, то более ранние важны с точки зрения теории, несмотря на их возраст. Почта - еще более старая технология с годами там менялось мало. особенно в фундаментальном плане.
🔶 Теория
🔹 Почтовый сервер для начинающих. Структура и принцип работы
🔹 Почтовый сервер для начинающих. Настраиваем DNS зону
🔹 Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом
🔹 Настраиваем свой почтовый сервер. Что нужно знать. Ликбез
🔹 Какие порты и для чего использует почтовый сервер. Ликбез
🔹 Как правильно настроить DNS-записи для мультидоменного почтового сервера
🔶 Практика. Почтовые сервера
🔹 Установка и настройка почтового сервера iRedMail с веб-клиентом SOGo и сертификатами Let's Encrypt
🔹 Установка и настройка почтового сервера Modoboa в Debian или Ubuntu
🔹 Установка и настройка почтового сервера Mail-in-a-Box в Ubuntu 22.04
🔶 Практика. Антиспам
🔹 Proxmox Mail Gateway - настраиваем пограничный почтовый шлюз
🔹 Используем API для автоматизации работы с Proxmox Mail Gateway
🔹 Обновляем Proxmox Mail Gateway с версии 7 до 8
🔶 Полезные инструменты
🔹 Онлайн инструменты для проверки почтового сервера
🔹 Проверка связи по протоколу SMTP с помощью Telnet
🔹 Перенос почтовых ящиков между серверами при помощи imapsync
👍36❤3
И снова про ремесла
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
👍14🔥14❤3👌2🥱1
Атомарность – будущее Linux
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
Дистрибутив основан на пакетной базе Arch Linux, но оформлен в форме неделимого образа, не применяющего разбивку на отдельные пакеты, монтируемого в режиме только для чтения и обновляемого атомарно. Компоненты, помимо базового системного окружения, собраны из исходного кода при помощи kde-builder или поставляются в форме пакетов Flatpak.
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍14🤔7❤2👎2
Атомарность на серверах 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, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍30🤡5❤2🤔2👌2
Oracle Cloud - всё?
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
😱6🔥4❤1
А у вас есть доступ к Oracle Cloud? (доступно несколько ответов)
Anonymous Poll
5%
Да, проводной провайдер
1%
Да, мобильный провайдер
3%
Нет, проводной провайдер
2%
Нет, мобильный провайдер
18%
Меня там забанили еще в 2022
17%
Принципиально не использую западные сервисы
9%
Так вам и надо!
53%
Ничего не понятно, но очень интересно
🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Екатеринбурге и поборись за призовой фонд 600 000 рублей!
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
❤2⚡2
Брандмауэр Windows – интересный парадокс
Брандмауэр Windows – впервые появился в Windows XP SP2 и работал тогда только с входящими соединениями. А современный вид приобрел с выходом Windows Vista, т.е. тоже довольно давно.
Его появление – было мерой вынужденной, потому что именно на эпоху XP пришлось развитие сетей и широкополосного интернета, а также первые сетевые эпидемии, от которых не спасал антивирус. Многие старожилы должны помнить тот же MS Blast.
Цель появления штатного брандмауэра не преследовала каких-то космических целей, нужен был простой и эффективный сетевой фильтр для отдельно стоящего узла, способный просто прикрыть от внешнего доступа все лишнее.
И в целом это получилось, брандмауэр Windows – достаточно неплохой инструмент, позволяющий закрыть из коробки все лишнее, но при этом не сильно мешая пользователю пользоваться той же сетью и интернетом.
А учитывая его возраст можно сказать, что продукт достаточно старый и проверенный временем…
Но так сказать нельзя. Вокруг брандмауэра Windows сложился интересный парадокс. Часть пользователей, включая наших коллег-администраторов его полностью отрицают, сразу выключая и даже останавливая службу.
Другая часть вроде бы даже и использует, во всяком случае умеет добавлять разрешающие правила или изменять существующие.
Но стоит копнуть глубже и выясняется, что практически никто не знает, как работает брандмауэр Windows, каким образом формируются правила, как они должны быть расположены и каким образом комбинируются друг с другом.
И это только в части входящих соединений, если взять исходящие, то там вообще полный мрак, включая непонимание даже стандартных правил, которые на первый взгляд кажутся бессмысленными и избыточными.
И это для продукта, которому уже более 20 лет и который есть на каждом компьютере под управлением Windows.
Подробнее о работе брандмауэра Windows можно узнать из материала на нашем сайте, где мы рассмотрели все его особенности: как он работает, как нужно составлять правила, как они сочетаются друг с другом и почему надо делать так, а не иначе.
Брандмауэр Windows – впервые появился в Windows XP SP2 и работал тогда только с входящими соединениями. А современный вид приобрел с выходом Windows Vista, т.е. тоже довольно давно.
Его появление – было мерой вынужденной, потому что именно на эпоху XP пришлось развитие сетей и широкополосного интернета, а также первые сетевые эпидемии, от которых не спасал антивирус. Многие старожилы должны помнить тот же MS Blast.
Цель появления штатного брандмауэра не преследовала каких-то космических целей, нужен был простой и эффективный сетевой фильтр для отдельно стоящего узла, способный просто прикрыть от внешнего доступа все лишнее.
И в целом это получилось, брандмауэр Windows – достаточно неплохой инструмент, позволяющий закрыть из коробки все лишнее, но при этом не сильно мешая пользователю пользоваться той же сетью и интернетом.
А учитывая его возраст можно сказать, что продукт достаточно старый и проверенный временем…
Но так сказать нельзя. Вокруг брандмауэра Windows сложился интересный парадокс. Часть пользователей, включая наших коллег-администраторов его полностью отрицают, сразу выключая и даже останавливая службу.
Другая часть вроде бы даже и использует, во всяком случае умеет добавлять разрешающие правила или изменять существующие.
Но стоит копнуть глубже и выясняется, что практически никто не знает, как работает брандмауэр Windows, каким образом формируются правила, как они должны быть расположены и каким образом комбинируются друг с другом.
И это только в части входящих соединений, если взять исходящие, то там вообще полный мрак, включая непонимание даже стандартных правил, которые на первый взгляд кажутся бессмысленными и избыточными.
И это для продукта, которому уже более 20 лет и который есть на каждом компьютере под управлением Windows.
Подробнее о работе брандмауэра Windows можно узнать из материала на нашем сайте, где мы рассмотрели все его особенности: как он работает, как нужно составлять правила, как они сочетаются друг с другом и почему надо делать так, а не иначе.
👍28🔥6🤮4❤3
И снова сети, вопрос со звездочкой
Имеется Mikrotik в заводской конфигурации по умолчанию, в самое начало цепочки input мы добавили правило:
Правило рабочее, счетчики увеличиваются.
❓❓❓Будет ли работать DHCP-сервер на роутере?
👇👇👇 Ответы и комментарии в опросе ниже
Имеется Mikrotik в заводской конфигурации по умолчанию, в самое начало цепочки input мы добавили правило:
ip firewall filter add chain=input protocol=udp dst-port=67 action=drop
Правило рабочее, счетчики увеличиваются.
❓❓❓Будет ли работать DHCP-сервер на роутере?
👇👇👇 Ответы и комментарии в опросе ниже
❤1
Будет ли работать DHCP-сервер?
Anonymous Quiz
46%
Да
24%
Нет
5%
Только с включенным FastTrack
2%
Только с выключенным FastTrack
4%
Будет выдавать только зарезервированные адреса
4%
Не сможет выдать новые адреса, но может продлять
3%
Сможет выдать новые адреса, но не сможет продлять
8%
Недостаточно данных для ответа
5%
Нет ни одного правильного ответа
Соберите своего первого AI-агента в прямом эфире
ИИ-агенты — это автономные системы, которые самостоятельно принимают решения и планируют шаги, чтобы достичь поставленной цели. Особенно они полезны в бизнесе.
На бесплатном практическом вебинаре мы покажем, как за час сделать ИИ-агента, который будет:
✔️анализировать транскрипты ваших встреч
✔️автоматически генерировать персонализированные коммерческие предложения (КП)
✔️отправлять эти КП клиентам в нужном формате
✔️интегрироваться с вашей CRM.
Все участники получат запись вебинара, шаблоны AI-агентов для быстрого старта, приглашение в закрытое AI Community и доступ к AI-подборке книг, курсов и вебинаров. А еще полноценный доступ к ИИ-платформе AlpinaGPT на 5 дней с оплатой токенов за наш счет.
Кто расскажет:
Жемал Хамидун — директор цифровых продуктов Alpina Digital, который запустил AlpinaGPT; автор телеграм-канала «Готовим ИИшницу»
Павел Доронин — основатель AI Community и AI Today
Глеб Ивашкевич — ML/AI/GIS, PhD. CEO и основатель Datarythmics
Когда: 9 сентября в 16:00 (мск)
Участие бесплатное
🔜Зарегистрироваться
ИИ-агенты — это автономные системы, которые самостоятельно принимают решения и планируют шаги, чтобы достичь поставленной цели. Особенно они полезны в бизнесе.
На бесплатном практическом вебинаре мы покажем, как за час сделать ИИ-агента, который будет:
✔️анализировать транскрипты ваших встреч
✔️автоматически генерировать персонализированные коммерческие предложения (КП)
✔️отправлять эти КП клиентам в нужном формате
✔️интегрироваться с вашей CRM.
Все участники получат запись вебинара, шаблоны AI-агентов для быстрого старта, приглашение в закрытое AI Community и доступ к AI-подборке книг, курсов и вебинаров. А еще полноценный доступ к ИИ-платформе AlpinaGPT на 5 дней с оплатой токенов за наш счет.
Кто расскажет:
Жемал Хамидун — директор цифровых продуктов Alpina Digital, который запустил AlpinaGPT; автор телеграм-канала «Готовим ИИшницу»
Павел Доронин — основатель AI Community и AI Today
Глеб Ивашкевич — ML/AI/GIS, PhD. CEO и основатель Datarythmics
Когда: 9 сентября в 16:00 (мск)
Участие бесплатное
🔜Зарегистрироваться
👎3❤1
Почему будет работать DHCP-сервер
Я думаю, правильный ответ многих удивил, еще кто-то мог про него знать, считая это просто особенностью роутеров Mikrotik, но на самом деле все глубже.
Начнем с того, что с DHCP-трафиком хост должен уметь работать в несколько отличных от всего иного сетевого взаимодействия обстоятельством – при полном отсутствии каких-либо сетевых настроек.
А как работать с сетью, если сети еще нет? Понятно, что стандартные инструменты здесь подходят мало и было принято решение использовать Berkeley Packet Filter (BPF).
Berkeley Packet Filter (BPF) – это механизм в UNIX и Linux системой который позволяет работать с сырым трафиком (raw sockets) выполняя захват и фильтрацию.
Поэтому в системе на уровне ядра настроен отдельный BPF на захват DHCP-трафика и этот захват происходит раньше, чем трафик попадает в Netfilter – еще один компонент ядра, который осуществляет фильтрацию пакетов, т.е. является настоящим брандмауэом.
Это важно помнить, фильтрацией трафика в Linux занимается именно Netfilter, а iptables, nftables, ufw и т.д. и т.п. – это всего лишь высокоуровневые интерфейсы для управления им.
Таким образом DHCP-трафик выпадает из-под действия брандмауэра, так как захватывается через BPF раньше. Хотя позже эти пакеты все-таки придут в брандмауэр, но это не будет влиять ни на что, кроме счетчиков.
Постойте, скажет кто-нибудь, это же касается DHCP-клиента, а у нас сервер. Но на самом деле это касается любой системы, вне зависимости от ее роли. На уровне BPF система понятия не имеет о ролях и софте, она просто делает свою работу – захватывает DHCP-трафик.
Поэтому вне зависимости от того, клиент перед нами или сервер, DHCP-трафик в брандмауэр не попадает. А Router OS, являясь по происхождению Linux системой унаследовала это поведение.
Я думаю, правильный ответ многих удивил, еще кто-то мог про него знать, считая это просто особенностью роутеров Mikrotik, но на самом деле все глубже.
Начнем с того, что с DHCP-трафиком хост должен уметь работать в несколько отличных от всего иного сетевого взаимодействия обстоятельством – при полном отсутствии каких-либо сетевых настроек.
А как работать с сетью, если сети еще нет? Понятно, что стандартные инструменты здесь подходят мало и было принято решение использовать Berkeley Packet Filter (BPF).
Berkeley Packet Filter (BPF) – это механизм в UNIX и Linux системой который позволяет работать с сырым трафиком (raw sockets) выполняя захват и фильтрацию.
Поэтому в системе на уровне ядра настроен отдельный BPF на захват DHCP-трафика и этот захват происходит раньше, чем трафик попадает в Netfilter – еще один компонент ядра, который осуществляет фильтрацию пакетов, т.е. является настоящим брандмауэом.
Это важно помнить, фильтрацией трафика в Linux занимается именно Netfilter, а iptables, nftables, ufw и т.д. и т.п. – это всего лишь высокоуровневые интерфейсы для управления им.
Таким образом DHCP-трафик выпадает из-под действия брандмауэра, так как захватывается через BPF раньше. Хотя позже эти пакеты все-таки придут в брандмауэр, но это не будет влиять ни на что, кроме счетчиков.
Постойте, скажет кто-нибудь, это же касается DHCP-клиента, а у нас сервер. Но на самом деле это касается любой системы, вне зависимости от ее роли. На уровне BPF система понятия не имеет о ролях и софте, она просто делает свою работу – захватывает DHCP-трафик.
Поэтому вне зависимости от того, клиент перед нами или сервер, DHCP-трафик в брандмауэр не попадает. А Router OS, являясь по происхождению Linux системой унаследовала это поведение.
👍43❤2
И снова про самодеятельность
Возникла сегодня с утра достаточно интересная дискуссия, про тиражные решения и художественную и не очень самодеятельность.
Наше мнение, основанное на годах работы в аутсорсе сводится к тому, что любое нестандартное решение, даже тиражное, но малораспространенное в результате обходится эксплуатанту дороже распространенного тиражного, даже если на старте это было не так и стояла цель сэкономить.
Наше мнение по этому поводу мы уже не раз излагали в заметках, рекомендуем прочитать их перед дальнейшим обсуждением:
🔹 Что такое хорошо и что такое плохо
🔹 Самодеятельность, художественная и не очень
Но часто, гораздо чаще чем хотелось мы сталкиваемся с обратным мнением, в основном от коллег, работающих на фиксированном рабочем месте. Их тоже можно понять – собственные костыли — это хорошая страховка и некоторый элемент незаменимости, когда нельзя просто так взять и заменить такого сотрудника. Потому что просто никто кроме него не знает и не умеет.
Но также часто мы могли наблюдать крайне негативные последствия для бизнеса, если такой сотрудник просто отказывался дальше «нести знамя» и даже рассказывали об одном подобном случае:
🔹 Самодеятельность, совсем не художественная
И там разработчик системы просто ушел, причем по-хорошему, без вредительства, передав все что есть. Но это абсолютно не спасло заказчика, так как браться за поддержку и дальнейшее сопровождение проекта желающих не нашлось.
А сколько случаев, когда такие сотрудники начинали «верить в себя» и исполнять лютую дичь, фактически выкручивая руки работодателю?
Но в любом случае готовы выслушать любое аргументированное мнение и ваш взгляд на эту проблему.
Возникла сегодня с утра достаточно интересная дискуссия, про тиражные решения и художественную и не очень самодеятельность.
Наше мнение, основанное на годах работы в аутсорсе сводится к тому, что любое нестандартное решение, даже тиражное, но малораспространенное в результате обходится эксплуатанту дороже распространенного тиражного, даже если на старте это было не так и стояла цель сэкономить.
Наше мнение по этому поводу мы уже не раз излагали в заметках, рекомендуем прочитать их перед дальнейшим обсуждением:
🔹 Что такое хорошо и что такое плохо
🔹 Самодеятельность, художественная и не очень
Но часто, гораздо чаще чем хотелось мы сталкиваемся с обратным мнением, в основном от коллег, работающих на фиксированном рабочем месте. Их тоже можно понять – собственные костыли — это хорошая страховка и некоторый элемент незаменимости, когда нельзя просто так взять и заменить такого сотрудника. Потому что просто никто кроме него не знает и не умеет.
Но также часто мы могли наблюдать крайне негативные последствия для бизнеса, если такой сотрудник просто отказывался дальше «нести знамя» и даже рассказывали об одном подобном случае:
🔹 Самодеятельность, совсем не художественная
И там разработчик системы просто ушел, причем по-хорошему, без вредительства, передав все что есть. Но это абсолютно не спасло заказчика, так как браться за поддержку и дальнейшее сопровождение проекта желающих не нашлось.
А сколько случаев, когда такие сотрудники начинали «верить в себя» и исполнять лютую дичь, фактически выкручивая руки работодателю?
Но в любом случае готовы выслушать любое аргументированное мнение и ваш взгляд на эту проблему.
👍11🥱7🤔2👎1
Подборка наших статей про BIND, ISC DHCP и Kea
▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP
▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP
▫️ Установка и базовая настройка DHCP-сервера Kea
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP
▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP
▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP
▫️ Установка и базовая настройка DHCP-сервера Kea
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP
👍14👏1
Waydroid – это не эмулятор
Довольно часто у пользователей Linux возникает необходимость запускать приложения Android и есть достаточно много способов сделать это.
Первое, что приходит на ум – эмулятор, но у эмуляторов есть один большой недостаток – падение производительности, иногда – существенное.
Waydroid – предлагает совершенно иной подход, он использует контейнеризацию LXC для запуска на Linux полноценной системы Android, а благодаря контейнеру он имеет прямой доступ к оборудованию и работает практически без потерь производительности.
Продукт поддерживает все основные дистрибутивы и достаточно неплохо документирован.
Такой подход представляется нам более перспективным и предпочтительным, нежели установку эмуляторов или Android-x86 в отдельную виртуалку.
В данном случае у нас наиболее приближенная к оригинальному Android система и практически нативное исполнение кода приложений.
Для контейнера используется образ LineageOS на базе Android 13. Доступна как ванильная сборка, так и с использованием приложений Google.
В целом проект интересен и заслуживает обратить на него внимание. По мере возможности и появления свободного времени постараемся выпустить подробный материал.
https://waydro.id
Довольно часто у пользователей Linux возникает необходимость запускать приложения Android и есть достаточно много способов сделать это.
Первое, что приходит на ум – эмулятор, но у эмуляторов есть один большой недостаток – падение производительности, иногда – существенное.
Waydroid – предлагает совершенно иной подход, он использует контейнеризацию LXC для запуска на Linux полноценной системы Android, а благодаря контейнеру он имеет прямой доступ к оборудованию и работает практически без потерь производительности.
Продукт поддерживает все основные дистрибутивы и достаточно неплохо документирован.
Такой подход представляется нам более перспективным и предпочтительным, нежели установку эмуляторов или Android-x86 в отдельную виртуалку.
В данном случае у нас наиболее приближенная к оригинальному Android система и практически нативное исполнение кода приложений.
Для контейнера используется образ LineageOS на базе Android 13. Доступна как ванильная сборка, так и с использованием приложений Google.
В целом проект интересен и заслуживает обратить на него внимание. По мере возможности и появления свободного времени постараемся выпустить подробный материал.
https://waydro.id
👍34❤5🤝1