Слышали ли вы, что...
❓SRE — это просто «продвинутый DevOps»,
❓внедрение SRE требует огромных ресурсов и подходит только гигантам вроде Google,
❓SRE занимается только устранением инцидентов.
Правда в том, что эти и многие другие убеждения далеки от реальности. Мы собрали для вас PDF-файл, в котором разоблачаем самые популярные мифы о SRE.
Это must-have для тех, кто хочет понять, как SRE может помочь именно вашей работе и бизнесу, без лишних сложностей и заблуждений.
📍Переходите к боту-помощнику и забирайте полезный PDF прямо сейчас 🔗
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFGhuBRi
❓SRE — это просто «продвинутый DevOps»,
❓внедрение SRE требует огромных ресурсов и подходит только гигантам вроде Google,
❓SRE занимается только устранением инцидентов.
Правда в том, что эти и многие другие убеждения далеки от реальности. Мы собрали для вас PDF-файл, в котором разоблачаем самые популярные мифы о SRE.
Это must-have для тех, кто хочет понять, как SRE может помочь именно вашей работе и бизнесу, без лишних сложностей и заблуждений.
📍Переходите к боту-помощнику и забирайте полезный PDF прямо сейчас 🔗
Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFGhuBRi
Тонкие настройки LXC. Процессор
Мы активно используем контейнеры LXC и постоянно сталкиваемся с необходимостью их тонкой настройки. Поэтому в данной заметке мы приведем только то, с чем постоянно имеем дело и что может вам пригодиться, не перегружая ее теоретической информацией.
Для примера возьмем задачу, когда у нас есть некоторый процессор 16 ядер / 32 потока и мы хотим разместить на нем сервер 1С, сервер СУБД и всяко-разно по мелочи.
Сервер 1С версии ПРОФ может использовать не более 12 ядер, но просто взять и указать в его настройках ограничение по ядрам мы не можем, потому что при старте контейнер будет выбирать ядра случайным образом, что ведет к изменению процессора и слету лицензии 1С.
Поэтому укажем ядра явно, для этого в конфигурационный файл /etc/pve/lxc/nnn.conf (где nnn – ID контейнера) добавим:
Это заставит его использовать 12 первых ядер. Ядра нумеруются начиная с нуля. Можно указывать отдельные номера через запятую или диапазон через тире, оба способа можно комбинировать. Например:
Серверу 1С ядра выделили, но остальные контейнеры, даже будучи ограниченными по количеству ядер могут использовать ядра совместно с сервером 1С, хотя у нас есть много еще свободных.
Поэтому явно указываем доступные ядра и для других машин, скажем 12-23 серверу СУБД и диапазон 24-31 для всех остальных.
В многопроцессорных системах дополнительно можно указать номер узла NUMA который может использовать контейнер, это позволит избежать задержек, когда процессор работая на ядрах одного процессора будет обращаться к памяти, которую обслуживает другой процессор.
Для этого используйте:
Где цифра указывает номер узла NUMA начиная с нуля, можем указать несколько значений с нуля или через запятую.
Хорошо, когда ядер много и можно всем раздать, но как быть, если процессорные ресурсы делятся между несколькими контейнерами. В этом случае следует настроить лимиты. Как мы помним, процессорное время выделяется процессам порциями – тиками. Если тиков всем не хватает – собирается очередь.
Это ведет к росту LA, значение LA в 1 на ядро означает, что свободных тиков нет, а значение более единицы указывает на наличие очереди.
Начнем с гибкого лимита, который позволяет установить относительный приоритет процессов, для этого мы используем следующий параметр:
Число 512 указывает приоритет, он может принимать значение от 1 до 1024, значение по умолчанию – 1024. Таким образом контейнер со значением 512 в случае возникновения конкуренции за ресурсы получит в два раза меньше тиков, чем контейнер без этой настройки.
Если же тиков хватает всем, либо более привилегированный контейнер не проявляет большой активности, то ограничения не применяются. Но если вдруг ему снова потребуются ресурсы, то они будут выделены в первую очередь.
Вместе с мягким есть и жесткое ограничение, когда мы просто не выделяем процессорных ресурсов более лимита, при этом у нас не растет очередь и процессы контейнера ограничены указанными рамками вне зависимости от наличия свободного ресурса.
Числа означают следующее: максимальное время использования ЦПУ, период в течении которого применяется ограничение в микросекундах. В приведенном примере мы выделили контейнеру половину процессорного ресурса. И он не сможет никогда его превысить, даже если процессор полностью простаивает.
Ну и наконец мы можем полностью закрепить ядро за контейнером, после чего ни один другой контейнер не сможет его использовать, если ядро занято хоть одним процессом назначенного ему контейнера.
Это позволяет обеспечить гарантированную производительность критичным сервисам.
Этот параметр нужно обязательно сочетать с
При этом мы можем выделить контейнеру большее количество ядер, скажем 8, но в эксклюзивное использование ему перейдут только 4, а за остальные он будет конкурировать с другими контейнерами.
Мы активно используем контейнеры LXC и постоянно сталкиваемся с необходимостью их тонкой настройки. Поэтому в данной заметке мы приведем только то, с чем постоянно имеем дело и что может вам пригодиться, не перегружая ее теоретической информацией.
Для примера возьмем задачу, когда у нас есть некоторый процессор 16 ядер / 32 потока и мы хотим разместить на нем сервер 1С, сервер СУБД и всяко-разно по мелочи.
Сервер 1С версии ПРОФ может использовать не более 12 ядер, но просто взять и указать в его настройках ограничение по ядрам мы не можем, потому что при старте контейнер будет выбирать ядра случайным образом, что ведет к изменению процессора и слету лицензии 1С.
Поэтому укажем ядра явно, для этого в конфигурационный файл /etc/pve/lxc/nnn.conf (где nnn – ID контейнера) добавим:
lxc.cgroup2.cpuset.cpus = 0-11
Это заставит его использовать 12 первых ядер. Ядра нумеруются начиная с нуля. Можно указывать отдельные номера через запятую или диапазон через тире, оба способа можно комбинировать. Например:
lxc.cgroup2.cpuset.cpus = 0, 1, 8-10,17-20
Серверу 1С ядра выделили, но остальные контейнеры, даже будучи ограниченными по количеству ядер могут использовать ядра совместно с сервером 1С, хотя у нас есть много еще свободных.
Поэтому явно указываем доступные ядра и для других машин, скажем 12-23 серверу СУБД и диапазон 24-31 для всех остальных.
В многопроцессорных системах дополнительно можно указать номер узла NUMA который может использовать контейнер, это позволит избежать задержек, когда процессор работая на ядрах одного процессора будет обращаться к памяти, которую обслуживает другой процессор.
Для этого используйте:
lxc.cgroup2.cpuset.mems: 0
Где цифра указывает номер узла NUMA начиная с нуля, можем указать несколько значений с нуля или через запятую.
Хорошо, когда ядер много и можно всем раздать, но как быть, если процессорные ресурсы делятся между несколькими контейнерами. В этом случае следует настроить лимиты. Как мы помним, процессорное время выделяется процессам порциями – тиками. Если тиков всем не хватает – собирается очередь.
Это ведет к росту LA, значение LA в 1 на ядро означает, что свободных тиков нет, а значение более единицы указывает на наличие очереди.
Начнем с гибкого лимита, который позволяет установить относительный приоритет процессов, для этого мы используем следующий параметр:
lxc.cgroup2.cpu.shares: 512
Число 512 указывает приоритет, он может принимать значение от 1 до 1024, значение по умолчанию – 1024. Таким образом контейнер со значением 512 в случае возникновения конкуренции за ресурсы получит в два раза меньше тиков, чем контейнер без этой настройки.
Если же тиков хватает всем, либо более привилегированный контейнер не проявляет большой активности, то ограничения не применяются. Но если вдруг ему снова потребуются ресурсы, то они будут выделены в первую очередь.
Вместе с мягким есть и жесткое ограничение, когда мы просто не выделяем процессорных ресурсов более лимита, при этом у нас не растет очередь и процессы контейнера ограничены указанными рамками вне зависимости от наличия свободного ресурса.
lxc.cgroup2.cpu.max: 50000 100000
Числа означают следующее: максимальное время использования ЦПУ, период в течении которого применяется ограничение в микросекундах. В приведенном примере мы выделили контейнеру половину процессорного ресурса. И он не сможет никогда его превысить, даже если процессор полностью простаивает.
Ну и наконец мы можем полностью закрепить ядро за контейнером, после чего ни один другой контейнер не сможет его использовать, если ядро занято хоть одним процессом назначенного ему контейнера.
Это позволяет обеспечить гарантированную производительность критичным сервисам.
lxc.cgroup2.cpuset.cpu_exclusive = 1
Этот параметр нужно обязательно сочетать с
lxc.cgroup2.cpuset.cpus = 0-3
При этом мы можем выделить контейнеру большее количество ядер, скажем 8, но в эксклюзивное использование ему перейдут только 4, а за остальные он будет конкурировать с другими контейнерами.
👍61🔥12
По этой теме не утихают холивары, поэтому повторим данный материал.
Папка, каталог или директория?
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
Папка, каталог или директория?
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
👍33🥱11👎3
История создания и развития IBM PC
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
👍38
Для тех, кому не нравится Plasma, а хочется старого доброго KDE есть проект Trinity Desktop Environment (TDE), который является форком KDE 3.5 и старательно воспроизводит эту рабочую среду.
При этом Trinity - это полноценная современная оболочка, которая следует за прогрессом и в которой можно спокойно работать.
Посмотреть на нее можно в Q4OS, специальном дистрибутиве на базе Debian с оболочкой TDE.
Почитать наш обзор можно здесь:
https://interface31.ru/tech_it/2019/08/q4os-interesnyy-i-neobychnyy-linux-distributiv.html
При этом Trinity - это полноценная современная оболочка, которая следует за прогрессом и в которой можно спокойно работать.
Посмотреть на нее можно в Q4OS, специальном дистрибутиве на базе Debian с оболочкой TDE.
Почитать наш обзор можно здесь:
https://interface31.ru/tech_it/2019/08/q4os-interesnyy-i-neobychnyy-linux-distributiv.html
👍27
Последнее время сталкивались с тем, что сканеры Mindeo идут из коробки с неоптимальными настройками и плохо читают коды маркировки.
Для того, чтобы исправить ситуацию достаточно скинуть настройки к заводским, а затем включить нужные служебными штрих-кодами.
А в идеале еще будет не лишним и прошить. Процесс простой и незамысловатый, в то время как прошивка постоянно обновляется в плане улучшения считывания.
Обо всем этом в нашей статье:
✅ Обновление прошивки сканеров штрих-кода Mindeo MD6ххх
Для того, чтобы исправить ситуацию достаточно скинуть настройки к заводским, а затем включить нужные служебными штрих-кодами.
А в идеале еще будет не лишним и прошить. Процесс простой и незамысловатый, в то время как прошивка постоянно обновляется в плане улучшения считывания.
Обо всем этом в нашей статье:
✅ Обновление прошивки сканеров штрих-кода Mindeo MD6ххх
👍25
Angie – лучший Nginx, чем Nginx
Редко, но случаются ситуации, когда форк превосходит основной продукт. И Angie как раз этот случай.
Данный форк основан нашими бывшими разработчиками Nginx и в первую очередь представлял вариант известного веб-сервера, но включенный в реестр отечественного ПО.
А, импортозамещение, цены по запросу и все такое прочее… Мы тоже сначала так подумали и отнеслись к продукту с некоторым скепсисом, но, как оказалось, зря.
Прежде чем продолжить, подсветим основные проблемы бесплатного Nginx, а именно крайне ограниченный набор возможностей из коробки.
Эта политика давно и сознательно проводится головной компанией, для которой бесплатный Nginx просто ознакомительная версия для проявления интереса к основному продукту.
Во что это выливалось на практике? Хотим поддержку той или иной современной технологии – пересобираем Nginx и необходимые модули к нему. С одной стороны ничего сложного, но с другой, если перефразировать Экзюпери: Мы в ответе за тех, кого пересобрали.
Как только мы вступили на скользкий путь сборки мы берем на себя все бремя ответственности и поддержки, а если такой сервер не один? Забудьте про простое apt update – apt upgrade, теперь все куда интереснее и увлекательнее.
Только вот развлекаться таким образом обычно нет ни времени, ни желания.
Вторая проблема – это отсутствие в официальных репозиториях поддержки отечественных ОС, ну это и понятно, головная компания NGINX Inc находится в американской юрисдикции.
Да, в репозиториях отечественных ОС есть пакеты Nginx, но это не самые последние версии и обновляются они не так быстро, как бы нам хотелось, а веб – это очень быстро изменяющаяся отрасль.
Разработчики Angie учли эти моменты и сделали официальные сборки под все отечественные ОС и добавили отдельный репозиторий с уже собранными бинарными модулями. Мелочь, но это именно то, чего так не хватало в официальном Nginx.
Просто поставили Angie, просто поставили модули, а потом просто обновляетесь пакетным менеджером системы. В готовых модулях есть все самое нужное, то, что всегда хотелось на Nginx, но от чего останавливала необходимость сборки.
Перейти с Nginx на Angie также просто и данный процесс хорошо документирован на сайте. Но если вы в должной мере владеете утилитами командной строки Linux, тот же sed позволит выполнить это буквально в одну команду.
Конфиги Nginx полностью совместимы, требуется только лишь поправить пути. И переход можно выполнить без простоя. Потушили Nginx и запустили Angie.
Мы уже перевели несколько несложных проектов и никаких проблем у нас не возникло, теперь в планах перевод на Angie основного сайта.
Также у Angie есть и то, чего нет в Nginx, например экспорт метрик или собственная веб-панель для мониторинга сервера, позволяющего контролировать основные параметры через браузер.
В общем, если вы являетесь активными пользователями Nginx, то вам стоит обратить самое пристальное внимание на Angie. И с очень большой вероятностью он придется вам ко двору.
Редко, но случаются ситуации, когда форк превосходит основной продукт. И Angie как раз этот случай.
Данный форк основан нашими бывшими разработчиками Nginx и в первую очередь представлял вариант известного веб-сервера, но включенный в реестр отечественного ПО.
А, импортозамещение, цены по запросу и все такое прочее… Мы тоже сначала так подумали и отнеслись к продукту с некоторым скепсисом, но, как оказалось, зря.
Прежде чем продолжить, подсветим основные проблемы бесплатного Nginx, а именно крайне ограниченный набор возможностей из коробки.
Эта политика давно и сознательно проводится головной компанией, для которой бесплатный Nginx просто ознакомительная версия для проявления интереса к основному продукту.
Во что это выливалось на практике? Хотим поддержку той или иной современной технологии – пересобираем Nginx и необходимые модули к нему. С одной стороны ничего сложного, но с другой, если перефразировать Экзюпери: Мы в ответе за тех, кого пересобрали.
Как только мы вступили на скользкий путь сборки мы берем на себя все бремя ответственности и поддержки, а если такой сервер не один? Забудьте про простое apt update – apt upgrade, теперь все куда интереснее и увлекательнее.
Только вот развлекаться таким образом обычно нет ни времени, ни желания.
Вторая проблема – это отсутствие в официальных репозиториях поддержки отечественных ОС, ну это и понятно, головная компания NGINX Inc находится в американской юрисдикции.
Да, в репозиториях отечественных ОС есть пакеты Nginx, но это не самые последние версии и обновляются они не так быстро, как бы нам хотелось, а веб – это очень быстро изменяющаяся отрасль.
Разработчики Angie учли эти моменты и сделали официальные сборки под все отечественные ОС и добавили отдельный репозиторий с уже собранными бинарными модулями. Мелочь, но это именно то, чего так не хватало в официальном Nginx.
Просто поставили Angie, просто поставили модули, а потом просто обновляетесь пакетным менеджером системы. В готовых модулях есть все самое нужное, то, что всегда хотелось на Nginx, но от чего останавливала необходимость сборки.
Перейти с Nginx на Angie также просто и данный процесс хорошо документирован на сайте. Но если вы в должной мере владеете утилитами командной строки Linux, тот же sed позволит выполнить это буквально в одну команду.
Конфиги Nginx полностью совместимы, требуется только лишь поправить пути. И переход можно выполнить без простоя. Потушили Nginx и запустили Angie.
Мы уже перевели несколько несложных проектов и никаких проблем у нас не возникло, теперь в планах перевод на Angie основного сайта.
Также у Angie есть и то, чего нет в Nginx, например экспорт метрик или собственная веб-панель для мониторинга сервера, позволяющего контролировать основные параметры через браузер.
В общем, если вы являетесь активными пользователями Nginx, то вам стоит обратить самое пристальное внимание на Angie. И с очень большой вероятностью он придется вам ко двору.
👍56❤3🤣1
Как узнать в какой физический порт Mikrotik подключено сетевое устройство.
Время от времени подобные задачи возникают. Для того, чтобы ответить на поставленный вопрос нам нужно заглянуть в MAC-таблицу коммутатора.
В RouterOS это сделать довольно просто. Можно заглянуть в
Если на одном порту присутствует несколько MAC-адресов, значит далее есть еще один коммутатор, не обязательно физический. В наше время это вполне может оказаться виртуальным коммутатором гипервизора.
Второй вариант - это
Время от времени подобные задачи возникают. Для того, чтобы ответить на поставленный вопрос нам нужно заглянуть в MAC-таблицу коммутатора.
В RouterOS это сделать довольно просто. Можно заглянуть в
Switch - Host. Здесь все просто: находим нужный MAC-адрес и смотрим с каким портом он связан.Если на одном порту присутствует несколько MAC-адресов, значит далее есть еще один коммутатор, не обязательно физический. В наше время это вполне может оказаться виртуальным коммутатором гипервизора.
Второй вариант - это
Bridge - Нosts, здесь все в принципе тоже самое, но обращаем внимание на флаги. Флаг L обозначает, что этот адрес добавлен самим мостом, т.е. принадлежит локальному интерфейсу. Нас интересует флаг E, который говорит что этот MAC-адрес получен от чипа коммутации и принадлежит внешнему устройству.👍46
Тонкие настройки LXC. Монтирование
Еще одна часто встречающаяся задача – обмен файлами между контейнером и хостом, особенно когда надо передать большие объемы данных и сеть для этого не очень подходит.
Для этого можно воспользоваться монтированием, попробуем смонтировать файл с хоста в контейнер, это может быть архив с дистрибутивом некоторого ПО. Для этого в конфигурационный файл
Обратите внимание, что путь к файлу на хосте мы указываем от корня, а в контейнере без указания начального слеша.
Далее коротко пройдемся по опциям:
▫️none – тип файловой системы, в данном случае мы монтируем не ФС, а файл (аналогично и директориями).
▫️ bind – указывает на связывание, мы явно связываем файл в контейнере с файлом на хосте.
▫️ optional - необязательность монтирования, если файл на хосте отсутствует монтирование произведено не будет, блокировки загрузки контейнера не произойдет.
▫️ create – создать объект указанного типа (файл) в контейнере при его отсутствии.
Теперь примонтируем директорию, это также просто:
А вот задача посложнее – смонтируем LVM раздел с файловой системой ext4:
Здесь мы вместо none указываем явно тип файловой системы и параметры монтирования также как мы это делаем в fstab.
А если нам нужно монтировать раздел блочного устройства, допустим у нас есть /dev/sda3 с типом файловой системы XFS. Здесь нам потребуется уже две строки:
Вторая строка разрешает доступ к устройству, где
▫️ b – блочное устройство
▫️ 8:3 – номер устройства, можно узнать командной
▫️ rwm – набор прав: чтение, запись, создание специальных файлов устройства.
А теперь к несколько неожиданному, как мы помним в Linux все есть файл и если мы хотим поднять в контейнере сервис, который создает собственные сетевые устройства, скажем OpenVPN или WireGuard, то мы должны предоставить этим устройствам связь с внешним миром через хост. А для этого снова используем монтирование:
Мы смонтировали при помощи связывания специальную директорию /dev/net хоста в контейнер и выдали на нее права второй строкой. Единственное отличие
Теперь мы можем создавать в контейнере собственные сетевые интерфейсы и они получат доступ во внешний мир через сетевую систему хоста.
Еще одна часто встречающаяся задача – обмен файлами между контейнером и хостом, особенно когда надо передать большие объемы данных и сеть для этого не очень подходит.
Для этого можно воспользоваться монтированием, попробуем смонтировать файл с хоста в контейнер, это может быть архив с дистрибутивом некоторого ПО. Для этого в конфигурационный файл
/etc/pve/lxc/nnn.conf (где nnn – ID контейнера) добавим:lxc.mount.entry = /home/file1.tgz home/file1.tgz none bind,optional,create=file
Обратите внимание, что путь к файлу на хосте мы указываем от корня, а в контейнере без указания начального слеша.
Далее коротко пройдемся по опциям:
▫️none – тип файловой системы, в данном случае мы монтируем не ФС, а файл (аналогично и директориями).
▫️ bind – указывает на связывание, мы явно связываем файл в контейнере с файлом на хосте.
▫️ optional - необязательность монтирования, если файл на хосте отсутствует монтирование произведено не будет, блокировки загрузки контейнера не произойдет.
▫️ create – создать объект указанного типа (файл) в контейнере при его отсутствии.
Теперь примонтируем директорию, это также просто:
lxc.mount.entry = /home/dir1 home none bind,optional ,create=dir
А вот задача посложнее – смонтируем LVM раздел с файловой системой ext4:
lxc.mount.entry = /dev/mapper/ lvm-vg-myvolume1 home/myvolume1 ext4 defaults 0 0
Здесь мы вместо none указываем явно тип файловой системы и параметры монтирования также как мы это делаем в fstab.
А если нам нужно монтировать раздел блочного устройства, допустим у нас есть /dev/sda3 с типом файловой системы XFS. Здесь нам потребуется уже две строки:
lxc.mount.entry = /dev/sda3 home/volume3 xfs defaults 0 0
lxc.cgroup.devices.allow = b 8:3 rwm
Вторая строка разрешает доступ к устройству, где
b 8:3 rwm означает: ▫️ b – блочное устройство
▫️ 8:3 – номер устройства, можно узнать командной
ls -l /dev/sda3▫️ rwm – набор прав: чтение, запись, создание специальных файлов устройства.
А теперь к несколько неожиданному, как мы помним в Linux все есть файл и если мы хотим поднять в контейнере сервис, который создает собственные сетевые устройства, скажем OpenVPN или WireGuard, то мы должны предоставить этим устройствам связь с внешним миром через хост. А для этого снова используем монтирование:
lxc.mount.entry: /dev/net dev/net none bind,create=dir
lxc.cgroup2.devices.allow: c 10:200 rwm
Мы смонтировали при помощи связывания специальную директорию /dev/net хоста в контейнер и выдали на нее права второй строкой. Единственное отличие
с вместо b так как устройство у нас не блочное, а символьное. Теперь мы можем создавать в контейнере собственные сетевые интерфейсы и они получат доступ во внешний мир через сетевую систему хоста.
👍47🔥5🤷♂3
Какие знания ключевые для успешного ИБ-специалиста?
🔴 Знание компьютерных сетей позволяет выявлять 70% уязвимостей, настраивать защиту и анализировать трафик, что критично для предотвращения 90% атак.
Освойте сети за 4 месяца на курсе от Академии Кодебай — запись до 13 марта. Регистрация
Курс создан для: Junior IT-специалистов, системных администраторов, Web-разработчиков, сетевых инженеров, которые хотят досконально освоить архитектуру сетей
Содержание курса:
✦ Изучение топологии сетей, видов сетевого оборудования
✦ Маршрутизация данных и управление доступом к среде
✦ Протокол IP, транспортный и прикладной уровни
✦ Система имен DNS, безопасность в сетях и противодействие атакам
По всем вопросам пишите @Codeby_Academy
🔴 Знание компьютерных сетей позволяет выявлять 70% уязвимостей, настраивать защиту и анализировать трафик, что критично для предотвращения 90% атак.
Освойте сети за 4 месяца на курсе от Академии Кодебай — запись до 13 марта. Регистрация
Курс создан для: Junior IT-специалистов, системных администраторов, Web-разработчиков, сетевых инженеров, которые хотят досконально освоить архитектуру сетей
Содержание курса:
✦ Изучение топологии сетей, видов сетевого оборудования
✦ Маршрутизация данных и управление доступом к среде
✦ Протокол IP, транспортный и прикладной уровни
✦ Система имен DNS, безопасность в сетях и противодействие атакам
По всем вопросам пишите @Codeby_Academy
Иди, читай логи
Подобную фразу хоть один раз, но слышал каждый. Может показаться, что ею показывают нежелание решать проблему, но на самом деле это единственно верный подход в любом вопросе.
Ведь у вас не вызывает недоумения если доктор отправляет вас сдавать анализы, а не пытается поставить диагноз угадыванием.
Точно также и в информационных системах, потому что только лог содержит всю необходимую для диагностики информацию. Остальное – гадание на кофейной гуще и шаманские камлания с бубном.
Но, как показывает практика, не все правильно умеют читать файл лога. Разберем некоторые распространенные ошибки.
Самая распространенная из них – отрицание. Когда читающий лог говорит сам себе: да ну нафиг, какая-то ерунда тут написана. Не может быть. И вместо того, чтобы решать проблему уподобляется герою анекдота, который ищет часы не там, где потерял, а там, где светлее.
Поэтому если в логе пишутся простые и очевидные вещи, скажем, неверный путь или неправильные учетные данные, то даже если вы в них 100% уверены – проверяйте еще раз. Ошибки, опечатки, регистр, невидимые символы, переносы строк – все может влиять. Особенно если вы копировали копипастом.
Вторая ошибка – это фокус на самой ошибке. Очень часто коллеги, особенно начинающие, игнорируют контекст ошибки и сосредотачиваются на ее непосредственном описании, что порой не приносит никакого результата.
В тоже время ошибка не возникает сама по себе, к ней приводит некоторая цепь событий, поэтому всегда читайте лог выше и ниже ошибки, ключ к решению может лежать в простых информационных сообщениях.
Все еще непонятно – перейдите еще выше и внимательно пройдитесь по всей цепочке, читая все сообщения и стараясь понять их. Последнее тоже очень важно. Мы не раз и не два сталкивались с вопросами коллег, ответы на которые были явно написаны в приводимых ими строках лога.
Ну и третья распространенная ошибка – это работа с недостаточным уровнем информации. Практически у всех приложений есть разные уровни логирования. И в нормальной работе используется далеко не самый информативный из них.
Обычно в лог пишутся значимые события, предупреждения и ошибки, без технических подробностей. Поэтому идите в настройки приложения или службы и увеличивайте подробность лога.
Причем не надо сразу выкручивать его «до упора», начните с увеличения на один-два уровня, будет мало – увеличите еще, в противном случае вы нагрузите себя бесполезной работой по разбору вороха ненужных подробностей.
Разобрались с проблемой – вернули уровень подробности лога в норму. Про это тоже забывать не стоит, не следует забивать журналы лишними подробностями, вам же их потом читать.
Ну и наконец, не издевайтесь над собой и не смотрите логи в голом текстовом редакторе или консоли. Поставьте плагин для подсветки логов, а в консоли установите утилиту для раскрашивания вывода. Это будет проще, нагляднее и информативнее. А также снизит нагрузку от монотонного просмотра однотипных строк.
Подобную фразу хоть один раз, но слышал каждый. Может показаться, что ею показывают нежелание решать проблему, но на самом деле это единственно верный подход в любом вопросе.
Ведь у вас не вызывает недоумения если доктор отправляет вас сдавать анализы, а не пытается поставить диагноз угадыванием.
Точно также и в информационных системах, потому что только лог содержит всю необходимую для диагностики информацию. Остальное – гадание на кофейной гуще и шаманские камлания с бубном.
Но, как показывает практика, не все правильно умеют читать файл лога. Разберем некоторые распространенные ошибки.
Самая распространенная из них – отрицание. Когда читающий лог говорит сам себе: да ну нафиг, какая-то ерунда тут написана. Не может быть. И вместо того, чтобы решать проблему уподобляется герою анекдота, который ищет часы не там, где потерял, а там, где светлее.
Поэтому если в логе пишутся простые и очевидные вещи, скажем, неверный путь или неправильные учетные данные, то даже если вы в них 100% уверены – проверяйте еще раз. Ошибки, опечатки, регистр, невидимые символы, переносы строк – все может влиять. Особенно если вы копировали копипастом.
Вторая ошибка – это фокус на самой ошибке. Очень часто коллеги, особенно начинающие, игнорируют контекст ошибки и сосредотачиваются на ее непосредственном описании, что порой не приносит никакого результата.
В тоже время ошибка не возникает сама по себе, к ней приводит некоторая цепь событий, поэтому всегда читайте лог выше и ниже ошибки, ключ к решению может лежать в простых информационных сообщениях.
Все еще непонятно – перейдите еще выше и внимательно пройдитесь по всей цепочке, читая все сообщения и стараясь понять их. Последнее тоже очень важно. Мы не раз и не два сталкивались с вопросами коллег, ответы на которые были явно написаны в приводимых ими строках лога.
Ну и третья распространенная ошибка – это работа с недостаточным уровнем информации. Практически у всех приложений есть разные уровни логирования. И в нормальной работе используется далеко не самый информативный из них.
Обычно в лог пишутся значимые события, предупреждения и ошибки, без технических подробностей. Поэтому идите в настройки приложения или службы и увеличивайте подробность лога.
Причем не надо сразу выкручивать его «до упора», начните с увеличения на один-два уровня, будет мало – увеличите еще, в противном случае вы нагрузите себя бесполезной работой по разбору вороха ненужных подробностей.
Разобрались с проблемой – вернули уровень подробности лога в норму. Про это тоже забывать не стоит, не следует забивать журналы лишними подробностями, вам же их потом читать.
Ну и наконец, не издевайтесь над собой и не смотрите логи в голом текстовом редакторе или консоли. Поставьте плагин для подсветки логов, а в консоли установите утилиту для раскрашивания вывода. Это будет проще, нагляднее и информативнее. А также снизит нагрузку от монотонного просмотра однотипных строк.
👍38⚡2
🤯 Почему не работает Hairpin NAT?
Спросил сегодня коллега и сильно удивился, когда мы ответили что он и не должен работать.
Почему? Смотрим первую картинку. Классическая ошибка проброса, вместо адреса использован интерфейс.
А теперь думаем. Если пакет пришел снаружи, то условия выполнятся и правило сработает. А если изнутри?
А изнутри пакет пойдет путем: внутренний интерфейс - INPUT - роутер. Почему? Да потому, что адрес хоть и "внешний", но принадлежит он роутеру. На внешний интерфейс такой пакет никогда не попадет и правило работать не будет.
Поэтому правильно убрать из условия интерфейс, но добавить внешний адрес роутера в поле Dst. Address. Теперь внутренний пакет будет пойман в PREROUTING, для него будет выполнен DNAT и он пойдет через FORWARD по назначению.
А как же Hairpin? А это уже на выходе, в POSTROUTING, ловим пакеты к узлу назначения и смотрим адрес источник, если это наша внутренняя сеть, но заменяем его на внутренний адрес роутера, чтобы пакет вернули туда, откуда он пришел (рисунок 2).
Спросил сегодня коллега и сильно удивился, когда мы ответили что он и не должен работать.
Почему? Смотрим первую картинку. Классическая ошибка проброса, вместо адреса использован интерфейс.
А теперь думаем. Если пакет пришел снаружи, то условия выполнятся и правило сработает. А если изнутри?
А изнутри пакет пойдет путем: внутренний интерфейс - INPUT - роутер. Почему? Да потому, что адрес хоть и "внешний", но принадлежит он роутеру. На внешний интерфейс такой пакет никогда не попадет и правило работать не будет.
Поэтому правильно убрать из условия интерфейс, но добавить внешний адрес роутера в поле Dst. Address. Теперь внутренний пакет будет пойман в PREROUTING, для него будет выполнен DNAT и он пойдет через FORWARD по назначению.
А как же Hairpin? А это уже на выходе, в POSTROUTING, ловим пакеты к узлу назначения и смотрим адрес источник, если это наша внутренняя сеть, но заменяем его на внутренний адрес роутера, чтобы пакет вернули туда, откуда он пришел (рисунок 2).
👍21⚡5🔥2❤1
Не знаете точную себестоимость произведенного товара❓
Рассчитываете приблизительно❓
Каждый раз задумываетесь по какому методу её калькулировать❓
🔊Регистрируйтесь на наш вебинар
РАСЧЕТ ТОЧНОЙ СЕБЕСТОИМОСТИ И ЦЕНООБРАЗОВАНИЕ В 1С:ERP
13.03.25 в 11:00
Кому будет полезен вебинар
Собственникам бизнеса
Генеральному директору
Финансовому директору
Главному бухгалтеру
Экономисту
ИТ-руководителю и др.
РЕГИСТРАЦИЯ
Реклама. Решетина Г.Н. ИНН 691105211910.
Рассчитываете приблизительно❓
Каждый раз задумываетесь по какому методу её калькулировать❓
🔊Регистрируйтесь на наш вебинар
РАСЧЕТ ТОЧНОЙ СЕБЕСТОИМОСТИ И ЦЕНООБРАЗОВАНИЕ В 1С:ERP
13.03.25 в 11:00
Кому будет полезен вебинар
Собственникам бизнеса
Генеральному директору
Финансовому директору
Главному бухгалтеру
Экономисту
ИТ-руководителю и др.
РЕГИСТРАЦИЯ
Реклама. Решетина Г.Н. ИНН 691105211910.
🤮3👍1
Алиса на YandexGPT 5 Pro
Попробовал сегодня новую Алису на новом нейросетевом движке от Яндекса - https://alice.yandex.ru.
Попробовать можно бесплатно, в сутки дается сделать 20 запросов. После их окончания вас переключат на обычную, старую Алису. И вот здесь можно попробовать задать те же самые вопросы и сравнить качество ответов.
Я немного погонял ее техническими вопросами, конфигурациями, разбором логов и несложным скриптингом. Результаты откровенно порадовали. Если «старая» Алиса не блистала умом и сообразительностью, то новая отвечает весьма бодро, где-то на уровне GPT-4o.
Как и любой другой нейросети ей присущи классические недостатки, самый серьезный из которых – придумывание. Она спокойно придумает вам несуществующие опции для конфига или сама додумает возможный синтаксис.
Причем где-то она додумывает по образу и подобию – т.е. берет параметры из другой части конфига и применяет к текущей секции. А где-то фантазия разыгрывается куда дальше, и она пытается адаптировать опции из другого продукта.
Это особенно заметно, когда спрашиваешь про что-то менее распространенное. Скажем для веб-сервера Caddy она спокойно придумывала параметры на основе аналогичных для Nginx, а когда я ей заметил, что в документации их нет, спокойно согласилась и выдала только то, что есть в документации.
На более распространенных продуктах ведет себя достаточно адекватно, скрипты пишет достаточно уверенно, с должным уровнем пояснения. А стоит все это удовольствие 100 руб. в месяц. В целом достаточно неплохая альтернатива и пользоваться можно, особенно если вы уже используете другие сервисы Яндекса.
Картинку ниже тоже она нарисовала.
Попробовал сегодня новую Алису на новом нейросетевом движке от Яндекса - https://alice.yandex.ru.
Попробовать можно бесплатно, в сутки дается сделать 20 запросов. После их окончания вас переключат на обычную, старую Алису. И вот здесь можно попробовать задать те же самые вопросы и сравнить качество ответов.
Я немного погонял ее техническими вопросами, конфигурациями, разбором логов и несложным скриптингом. Результаты откровенно порадовали. Если «старая» Алиса не блистала умом и сообразительностью, то новая отвечает весьма бодро, где-то на уровне GPT-4o.
Как и любой другой нейросети ей присущи классические недостатки, самый серьезный из которых – придумывание. Она спокойно придумает вам несуществующие опции для конфига или сама додумает возможный синтаксис.
Причем где-то она додумывает по образу и подобию – т.е. берет параметры из другой части конфига и применяет к текущей секции. А где-то фантазия разыгрывается куда дальше, и она пытается адаптировать опции из другого продукта.
Это особенно заметно, когда спрашиваешь про что-то менее распространенное. Скажем для веб-сервера Caddy она спокойно придумывала параметры на основе аналогичных для Nginx, а когда я ей заметил, что в документации их нет, спокойно согласилась и выдала только то, что есть в документации.
На более распространенных продуктах ведет себя достаточно адекватно, скрипты пишет достаточно уверенно, с должным уровнем пояснения. А стоит все это удовольствие 100 руб. в месяц. В целом достаточно неплохая альтернатива и пользоваться можно, особенно если вы уже используете другие сервисы Яндекса.
Картинку ниже тоже она нарисовала.
🔥15🤮9👍7🍌2❤1
Вчера в обсуждениях поднялся вопрос о достоинствах и недостатках IPv6.
👍 Начнем с достоинств, они широко известны:
🔹 Устраняет дефицит адресов на многие десятилетия вперед.
🔹 Позволяет избавиться от NAT, теперь каждое устройство включая лампочку или чайник будет иметь собственный адрес и полноценно общаться с интернетом.
🔹 Улучшится работа P2P технологий
🔹 Упрощается автоматическая настройка сети при помощи SLAAC
🔹 Лучшая производительность за счет отсутствия фрагментации и упрощения заголовков пакетов.
🔹 Упрощается структура сети, так как устройства теперь могут общаться напрямую без NAT, VPN, туннелей и т.п.
☝️ Все это понятно, интересно, прогрессивно. Но есть и недостатки.
Я специально потратил время и изучил профильные обсуждения на сетевых ресурсах. Из чего был выделен следующий список недостатков, которые больше всего беспокоят пользователей:
🔸 Отсутствие обратной совместимости, фактически «переход» на IPv6 будет означать одновременное использование двух стеков. А это увеличение затрат на администрирование, повышенная нагрузка на оборудование и ухудшение безопасности за счет увеличения поверхности атаки.
🔸 При смене провайдера поплывет вся адресация сети, чтобы избежать этого придумано
🔸 Безопасность. NAT позволяет эффективно закрыть сегмент сети от интернета и даже при ошибках настройки брандмауэра внутренние узлы не оказывались выставлены во внешнюю сеть. В случае IPv6 требуется гораздо более грамотная и вдумчивая настройка правил межсетевого экрана.
🤔 При этом каких-либо явных преимуществ пользовательским сетям (мы не рассматриваем провайдеров, телеком, датацентры и т.п.) IPv6 не дает. А фактически усложняет сеть за счет двух независимых друг от друга настроек, так как IPv4 никуда не делся и жить на два стека придется еще очень долго.
👍 Начнем с достоинств, они широко известны:
🔹 Устраняет дефицит адресов на многие десятилетия вперед.
🔹 Позволяет избавиться от NAT, теперь каждое устройство включая лампочку или чайник будет иметь собственный адрес и полноценно общаться с интернетом.
🔹 Улучшится работа P2P технологий
🔹 Упрощается автоматическая настройка сети при помощи SLAAC
🔹 Лучшая производительность за счет отсутствия фрагментации и упрощения заголовков пакетов.
🔹 Упрощается структура сети, так как устройства теперь могут общаться напрямую без NAT, VPN, туннелей и т.п.
☝️ Все это понятно, интересно, прогрессивно. Но есть и недостатки.
Я специально потратил время и изучил профильные обсуждения на сетевых ресурсах. Из чего был выделен следующий список недостатков, которые больше всего беспокоят пользователей:
🔸 Отсутствие обратной совместимости, фактически «переход» на IPv6 будет означать одновременное использование двух стеков. А это увеличение затрат на администрирование, повышенная нагрузка на оборудование и ухудшение безопасности за счет увеличения поверхности атаки.
🔸 При смене провайдера поплывет вся адресация сети, чтобы избежать этого придумано
IPv6 Network Prefix Translation (NPt), и это (внезапно 😉) по принципу работы тот же NAT🔸 Безопасность. NAT позволяет эффективно закрыть сегмент сети от интернета и даже при ошибках настройки брандмауэра внутренние узлы не оказывались выставлены во внешнюю сеть. В случае IPv6 требуется гораздо более грамотная и вдумчивая настройка правил межсетевого экрана.
🤔 При этом каких-либо явных преимуществ пользовательским сетям (мы не рассматриваем провайдеров, телеком, датацентры и т.п.) IPv6 не дает. А фактически усложняет сеть за счет двух независимых друг от друга настроек, так как IPv4 никуда не делся и жить на два стека придется еще очень долго.
👍56🤡1
Тонкие настройки LXC. Память
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
/etc/pve/lxc/nnn.conf (где nnn – ID контейнера) указывается просто выделенный объем памяти, а вот если мы заглянем в настоящий конфиг LXC в /var/lib/lxc/nnn/config, то увидим там две директивы (для контейнера с 4 ГБ памяти):lxc.cgroup2.memory.max = 4294967296
lxc.cgroup2.memory.high = 4261412864
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
lxc.cgroup2.memory.low
lxc.cgroup2.memory.min
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
👍40👀1
Сколько месяцев ты ещё будешь сидеть без работы, пока другие получают офферы в IT?
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Как узнать все смонтированные файловые системы?
Раньше можно было сказать: загляните в
Можно использовать команду
Но есть способ лучше -
А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
Раньше можно было сказать: загляните в
/etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.Можно использовать команду
mount, но ее вывод недостаточно удобочитаем.Но есть способ лучше -
findmnt, данная команда выведет все смонтированные файловые системы в удобном древообразном виде.А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
--real. Чтобы получить больше информации воспользуйтесь ключом --help.
👍68
Секта свидетелей чего-то там
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
💯49👍22🤣14🤡9⚡3