Современный подход к организации конфигурационных файлов
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
❤11👌8⚡2🥱2👀2
Boxes – простая настольная KVM-виртуализация
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
🔥7❤5👌5🥱2⚡1
Некоторые неочевидные особенности корзины Samba
Корзина Samba нравится очень многим администраторам и нам в том числе, потому что позволяет не только хранить удаленные файлы, но и сохранять их версии, что очень полезно на случай перезаписи.
Но все эти достоинства имеют и обратную сторону медали. Многие пользователи любят работать с общими файлами непосредственно в общей папке, запуская их на редактирование из сетевого расположения.
А что обычно происходит в таком случае? Правильно, система создает скрытые временные файлы, которые автоматически удаляются при окончании редактирования и надо ли говорить, что попадают они в корзину.
Несколько раз открыли один и тот же файл – получили несколько экземпляров в корзину. Таким образом, при достаточно интенсивной работе, объем корзины будет приближаться к горячему объему файлового хранилища, а то и превышать его.
И это не какая-то умозрительная ситуация, буквально на днях мы как раз разбирали этот вопрос с представителем заказчика, который был сильно удивлен почему при общем объеме шары в 35 ГБ объем резервной копии у него получался более 50 ГБ.
Поэтому корзину в Samba необходимо чистить, но делать это не в лоб, а точечно, чтобы ненароком не удалить нужное. Здесь можно опираться на расширение - .tmp или характерный формат имени временных файлов Office, которые начинаются с ~$.
Ну и выделять место для файлового сервера с корзиной нужно также оглядываясь на этот факт, а в случае использования быстрых и дорогих твердотельных накопителей имеет смысл монтировать корзину на более медленные и недорогие носители.
Корзина Samba нравится очень многим администраторам и нам в том числе, потому что позволяет не только хранить удаленные файлы, но и сохранять их версии, что очень полезно на случай перезаписи.
Но все эти достоинства имеют и обратную сторону медали. Многие пользователи любят работать с общими файлами непосредственно в общей папке, запуская их на редактирование из сетевого расположения.
А что обычно происходит в таком случае? Правильно, система создает скрытые временные файлы, которые автоматически удаляются при окончании редактирования и надо ли говорить, что попадают они в корзину.
Несколько раз открыли один и тот же файл – получили несколько экземпляров в корзину. Таким образом, при достаточно интенсивной работе, объем корзины будет приближаться к горячему объему файлового хранилища, а то и превышать его.
И это не какая-то умозрительная ситуация, буквально на днях мы как раз разбирали этот вопрос с представителем заказчика, который был сильно удивлен почему при общем объеме шары в 35 ГБ объем резервной копии у него получался более 50 ГБ.
Поэтому корзину в Samba необходимо чистить, но делать это не в лоб, а точечно, чтобы ненароком не удалить нужное. Здесь можно опираться на расширение - .tmp или характерный формат имени временных файлов Office, которые начинаются с ~$.
Ну и выделять место для файлового сервера с корзиной нужно также оглядываясь на этот факт, а в случае использования быстрых и дорогих твердотельных накопителей имеет смысл монтировать корзину на более медленные и недорогие носители.
🤔19👍4❤3👌2🍌1
Будь проще…
Сегодня маркетологи в описании товара чего только нам не предлагают, стоит только заплатить лишнюю пару-тройку, а то и десяток тысяч рублей.
Казалось бы — вот оно счастье, но эта лодка, равно как и любовная, довольно быстро разбивается о быт…
Когда-то, очень давно, на свадьбу нам подарили крутую микроволновку. С кучей программ и толстой книжкой всевозможных рецептов.
И что? Побаловаться хватило ровно на пару недель, после чего микроволновка работала в режиме: поставил тарелку – нажал кнопку – разогрел – достал.
Подобная участь постигла и крутой кухонный комбайн, купленный мною позже, работал он в основном в режиме измельчителя.
И примеров тому можно привести великое множество, но с тех пор на моей кухне живут просто микроволновки, просто измельчители и мясорубки, и просто чайники, без всякого намека на «полоумность» и не обладающие кучей ненужных функций, а просто делающие свое дело.
Это как раз перекликается с философией UNIX, каждый делает что-то одно, но делает это хорошо.
Тоже самое касается и компьютерных комплектующих. Сегодня вечером в гости напросился сын моих хороших друзей, да не просто так, а с новым компьютером, которому он уже третий день не мог дать ладу. Ну не хотел он стабильно работать и все, хоть ты тресни.
Я уже примерно предвидел что там увижу и мои ожидания полностью оправдались. «Игровая» материнская плата и «интеллектуальный» автоматический разгон в BIOS, который же был, конечно же включен.
А дальше выяснилось, что одна из планок памяти такой разгон не переваривает, со всеми вытекающими. И это не брак, потому что ее работу на такой частоте никто не обещал. А на штатной она функционирует полностью нормально.
Поэтому первый вопрос молодому товарищу был такой: «И нафига ты это купил?»
Ответ был в стиле: «Ну круто же, стильно, модно, молодежно!»
В общем сбросили настройки BIOS, отключили «полоумный» разгон. А попутно, чтобы добру не пропадать, все-таки немного разогнали память, благо память была хорошая.
После чего открыли сайт известной компьютерной сети из трех букв и сначала нашли эту «игровую» плату, а потом ровно такую-же по возможностям, но без «полоумных» функций и ЛГБТ-подсветки.
Разница в 7 тыс. рублей. Тот же чипсет, та же подсистема питания и аналогичный развод PCIe линий по разъемам (а сегодня это важно).
Молодой товарищ как-то сразу приуныл. Но тут у нас не школа благородных девиц, поэтому снова спрашиваю: «А вообще разгон тебе зачем? Ты во что-то крутое играешь?»
А сам поглядываю на RTX 3050…
«Да нет» - говорит – «в танчики иногда или в GTA»
«Тогда может CAD какой сложный или рендеринг?»
«Тоже нет…»
В общем все ясно. Круто же и выглядит красиво, мигает, сверкает и переливается. И минус 7 тыс. руб. из кармана. И плюсом пачка проблем от «полоумных» функций.
Поэтому надо быть проще, это не значит, что следует впадать в аскезу и экономить каждую копейку, отказываясь от любых улучшений. Но нужно трезво подумать надо ли это все вам и сделать выбор согласно текущих потребностей.
Я, например, давно уже не покупаю дорогие ноутбуки, потому что активно использую их несколько раз в год, в период отпусков и праздников, а остальное время он лежит на полке.
Что-то из массового сегмента работает в целом не хуже, теряет в стоимости меньше, а через года два-три его не жалко заменить на более актуальную модель.
Сегодня маркетологи в описании товара чего только нам не предлагают, стоит только заплатить лишнюю пару-тройку, а то и десяток тысяч рублей.
Казалось бы — вот оно счастье, но эта лодка, равно как и любовная, довольно быстро разбивается о быт…
Когда-то, очень давно, на свадьбу нам подарили крутую микроволновку. С кучей программ и толстой книжкой всевозможных рецептов.
И что? Побаловаться хватило ровно на пару недель, после чего микроволновка работала в режиме: поставил тарелку – нажал кнопку – разогрел – достал.
Подобная участь постигла и крутой кухонный комбайн, купленный мною позже, работал он в основном в режиме измельчителя.
И примеров тому можно привести великое множество, но с тех пор на моей кухне живут просто микроволновки, просто измельчители и мясорубки, и просто чайники, без всякого намека на «полоумность» и не обладающие кучей ненужных функций, а просто делающие свое дело.
Это как раз перекликается с философией UNIX, каждый делает что-то одно, но делает это хорошо.
Тоже самое касается и компьютерных комплектующих. Сегодня вечером в гости напросился сын моих хороших друзей, да не просто так, а с новым компьютером, которому он уже третий день не мог дать ладу. Ну не хотел он стабильно работать и все, хоть ты тресни.
Я уже примерно предвидел что там увижу и мои ожидания полностью оправдались. «Игровая» материнская плата и «интеллектуальный» автоматический разгон в BIOS, который же был, конечно же включен.
А дальше выяснилось, что одна из планок памяти такой разгон не переваривает, со всеми вытекающими. И это не брак, потому что ее работу на такой частоте никто не обещал. А на штатной она функционирует полностью нормально.
Поэтому первый вопрос молодому товарищу был такой: «И нафига ты это купил?»
Ответ был в стиле: «Ну круто же, стильно, модно, молодежно!»
В общем сбросили настройки BIOS, отключили «полоумный» разгон. А попутно, чтобы добру не пропадать, все-таки немного разогнали память, благо память была хорошая.
После чего открыли сайт известной компьютерной сети из трех букв и сначала нашли эту «игровую» плату, а потом ровно такую-же по возможностям, но без «полоумных» функций и ЛГБТ-подсветки.
Разница в 7 тыс. рублей. Тот же чипсет, та же подсистема питания и аналогичный развод PCIe линий по разъемам (а сегодня это важно).
Молодой товарищ как-то сразу приуныл. Но тут у нас не школа благородных девиц, поэтому снова спрашиваю: «А вообще разгон тебе зачем? Ты во что-то крутое играешь?»
А сам поглядываю на RTX 3050…
«Да нет» - говорит – «в танчики иногда или в GTA»
«Тогда может CAD какой сложный или рендеринг?»
«Тоже нет…»
В общем все ясно. Круто же и выглядит красиво, мигает, сверкает и переливается. И минус 7 тыс. руб. из кармана. И плюсом пачка проблем от «полоумных» функций.
Поэтому надо быть проще, это не значит, что следует впадать в аскезу и экономить каждую копейку, отказываясь от любых улучшений. Но нужно трезво подумать надо ли это все вам и сделать выбор согласно текущих потребностей.
Я, например, давно уже не покупаю дорогие ноутбуки, потому что активно использую их несколько раз в год, в период отпусков и праздников, а остальное время он лежит на полке.
Что-то из массового сегмента работает в целом не хуже, теряет в стоимости меньше, а через года два-три его не жалко заменить на более актуальную модель.
💯46❤15🥱6👀5👌1
Я хочу все сделать технически правильно, но мой работодатель препятствует этому
С подобной ситуацией сталкиваются многие коллеги, особенно молодые и искренне недоумевают почему так происходит.
Почему бизнес не хочет делать правильно, а требует костылей, полумер и половинчатых решений. Мол работает и хорошо, а когда перестанет – вот тогда и подумаем.
Обычно в этой ситуации винят руководство, которое представляется жадным и недалеким, плюс ничего не смыслящем в IT-технологиях.
Но на самом деле все обстоит по-другому, просто надо посмотреть на ситуацию с другой стороны. Стороны бизнеса, который оперирует совсем иными понятиями.
Цель любого бизнеса – заработать деньги, а вовсе не сделать все красиво и правильно. Поэтому любой бизнес будет стремиться увеличить прибыль и уменьшить издержки.
IT-отдел – это сугубо расходная статья любого бизнеса, прибыли он не приносит. Поэтому, как и любые другие расходные статьи, он будет финансироваться по принципу оптимального минимума.
Как определяется этот минимум? Далеко не техническими показателями, о них руководство может ничего не знать, да и не обязано. А финансовыми.
Грубо говоря, если проблема решается деньгами, то это не проблема, а расходы. Размер расходов, которые фирма может себе одноразово позволить руководству известен. Как правило он коррелируется с операционной прибылью. Т.е. общей выручкой за вычетом постоянных расходов.
Чем выше этот показатель, тем больше средств фирма может выделить на то, чтобы залить проблему деньгами.
И это вполне нормальная практика. Потому что когда с одной стороны стоят некоторые расходы здесь и сейчас, а с другой возможная проблема где-то там, которая может быть, а может не быть, то включается простой финансовый расчет.
Вот приходит администратор и говорит, что нужно сделать то, то и это. Все это, несомненно правильно и грамотно. Согласно лучшим практикам и рекомендациям.
А руководство его и спрашивает, что будет, если мы это не сделаем?
Админ отвечает, мол то и это, такой-то простой или такая-то потеря данных, ну и прочие негативные факторы.
Следующий вопрос: а какая вероятность этого события. Как часто вообще у нас такое происходило и происходит?
Дальше берется калькулятор и считается количество денег, которые потеряет фирма в результате наступления события, либо какое количество денег понадобится чтобы устранить последствия.
Если эта цифра сравнима с тем, что требуется выделить здесь и сейчас или выше ее, то бизнес деньги выделит. Если же ниже, либо вероятность такого события крайне низка, то в финансировании будет отказано.
Кроме того, есть ряд событий, которые несут угрозу, но вкладывать средства в защиту от них одного только IT не имеет смысла.
Вот приходит админ просить деньги на новые бесперебойники. Сразу вопрос, а зачем?
Ответ, чтобы час тянули, а не 15 минут как сейчас.
Бизнес при этом смотрит шире, и задает встречный вопрос: а зачем нам нужно чтобы сервера работали час, если у нас все рабочие места выключатся через 15 минут?
В результате денег на это, конечно же не дадут. Потому что просто расход в никуда, не несущий для бизнеса практического смысла.
Можно, конечно, нагнать жути и финансирование выбить. Но может так случиться, что указанное событие возьмет и произойдет. И при этом выяснится, что на самом деле все не так уж и страшно, а денег в свое время было выделено неоправданно много.
Возможно, конкретных оргвыводов и не последует, но денег вам больше не дадут или будут делить ваши запросы на некий известный только им коэффициент.
А еще хуже, если средства выделили, событие произошло, но отработать так как было заявлено вы его не смогли. Тут уже точно будут и оргвыводы, и неудобные вопросы по поводу того, на что и как были потрачены деньги.
Поэтому, во многих случаях, лучше не бежать с техническими решениями впереди паровоза, т.е. реальных потребностей бизнеса, а трезво оценивать ситуацию, в том числе и с финансовой стороны, что позволит избежать множества недоразумений и конфликтных ситуаций.
С подобной ситуацией сталкиваются многие коллеги, особенно молодые и искренне недоумевают почему так происходит.
Почему бизнес не хочет делать правильно, а требует костылей, полумер и половинчатых решений. Мол работает и хорошо, а когда перестанет – вот тогда и подумаем.
Обычно в этой ситуации винят руководство, которое представляется жадным и недалеким, плюс ничего не смыслящем в IT-технологиях.
Но на самом деле все обстоит по-другому, просто надо посмотреть на ситуацию с другой стороны. Стороны бизнеса, который оперирует совсем иными понятиями.
Цель любого бизнеса – заработать деньги, а вовсе не сделать все красиво и правильно. Поэтому любой бизнес будет стремиться увеличить прибыль и уменьшить издержки.
IT-отдел – это сугубо расходная статья любого бизнеса, прибыли он не приносит. Поэтому, как и любые другие расходные статьи, он будет финансироваться по принципу оптимального минимума.
Как определяется этот минимум? Далеко не техническими показателями, о них руководство может ничего не знать, да и не обязано. А финансовыми.
Грубо говоря, если проблема решается деньгами, то это не проблема, а расходы. Размер расходов, которые фирма может себе одноразово позволить руководству известен. Как правило он коррелируется с операционной прибылью. Т.е. общей выручкой за вычетом постоянных расходов.
Чем выше этот показатель, тем больше средств фирма может выделить на то, чтобы залить проблему деньгами.
И это вполне нормальная практика. Потому что когда с одной стороны стоят некоторые расходы здесь и сейчас, а с другой возможная проблема где-то там, которая может быть, а может не быть, то включается простой финансовый расчет.
Вот приходит администратор и говорит, что нужно сделать то, то и это. Все это, несомненно правильно и грамотно. Согласно лучшим практикам и рекомендациям.
А руководство его и спрашивает, что будет, если мы это не сделаем?
Админ отвечает, мол то и это, такой-то простой или такая-то потеря данных, ну и прочие негативные факторы.
Следующий вопрос: а какая вероятность этого события. Как часто вообще у нас такое происходило и происходит?
Дальше берется калькулятор и считается количество денег, которые потеряет фирма в результате наступления события, либо какое количество денег понадобится чтобы устранить последствия.
Если эта цифра сравнима с тем, что требуется выделить здесь и сейчас или выше ее, то бизнес деньги выделит. Если же ниже, либо вероятность такого события крайне низка, то в финансировании будет отказано.
Кроме того, есть ряд событий, которые несут угрозу, но вкладывать средства в защиту от них одного только IT не имеет смысла.
Вот приходит админ просить деньги на новые бесперебойники. Сразу вопрос, а зачем?
Ответ, чтобы час тянули, а не 15 минут как сейчас.
Бизнес при этом смотрит шире, и задает встречный вопрос: а зачем нам нужно чтобы сервера работали час, если у нас все рабочие места выключатся через 15 минут?
В результате денег на это, конечно же не дадут. Потому что просто расход в никуда, не несущий для бизнеса практического смысла.
Можно, конечно, нагнать жути и финансирование выбить. Но может так случиться, что указанное событие возьмет и произойдет. И при этом выяснится, что на самом деле все не так уж и страшно, а денег в свое время было выделено неоправданно много.
Возможно, конкретных оргвыводов и не последует, но денег вам больше не дадут или будут делить ваши запросы на некий известный только им коэффициент.
А еще хуже, если средства выделили, событие произошло, но отработать так как было заявлено вы его не смогли. Тут уже точно будут и оргвыводы, и неудобные вопросы по поводу того, на что и как были потрачены деньги.
Поэтому, во многих случаях, лучше не бежать с техническими решениями впереди паровоза, т.е. реальных потребностей бизнеса, а трезво оценивать ситуацию, в том числе и с финансовой стороны, что позволит избежать множества недоразумений и конфликтных ситуаций.
🔥31💯15😁9👍5❤3
Похоже, что WhatsApp - всё. На ПК не работает ни приложение, ни веб-версия.
Долгая загрузка с последующим сообщением, что интернет недоступен.
Мобильное приложение худо-бедно работает. Но сообщения доставляются с большими задержками и очень плохо грузится мультимедиа.
При этом проблемы с WhatsApp начались еще на прошлой неделе, но теперь, похоже, вопрос решили закрыть полностью.
Долгая загрузка с последующим сообщением, что интернет недоступен.
Мобильное приложение худо-бедно работает. Но сообщения доставляются с большими задержками и очень плохо грузится мультимедиа.
При этом проблемы с WhatsApp начались еще на прошлой неделе, но теперь, похоже, вопрос решили закрыть полностью.
👍40🤷♂16😁5⚡4💯4
На фоне последних событий напоминаем. И это не только про наш ночной кинотеатр, но и про разные пункты выдачи, с вывеской Mega, галереи современного искусства с чего-то-там-грамм и наконец некой зеленой избе-болталке...
Как пройти в кинотеатр в три часа ночи при помощи навигатора Mikrotik
Есть тут в наших краях ночной кинотеатр, над его входом висит импортная вывеска
Почтовый индекс нашего кинотеатра:
Так как кинотеатр импортный, то он всяко хитро автоматизирован. Все, кто забронировали места заносятся в специальный список YTB (фиг его знает, что это значит, но выглядит солидно).
Дети, собаки и прочие близкие родственники зрителей пропускаются бесплатно, они проверяются справочной системой типа DNS и также автоматически заносятся в списки:
Список детей и собак действует сутки, потом его надо обновлять:
Каждому на входе автоматически выдают билетик:
А тут у нас вход в кинозал, но до него еще дойти надо, ночь на дворе, темно…
А для этого у нас есть информационно-указательная система:
На которую выводится информация как именно пройти в кинотеатр в три часа ночи:
После прочтения указанной китайской грамоты содержимое съесть, навигатор перезагрузить.
Как пройти в кинотеатр в три часа ночи при помощи навигатора Mikrotik
Есть тут в наших краях ночной кинотеатр, над его входом висит импортная вывеска
wireguard1 и еще в нем есть заморская справочная система типа DNS (но не та, которая магазин). Почтовый индекс нашего кинотеатра:
10.20.1.1Так как кинотеатр импортный, то он всяко хитро автоматизирован. Все, кто забронировали места заносятся в специальный список YTB (фиг его знает, что это значит, но выглядит солидно).
/ip firewall address-list add address=youtube.com list=YTB
/ip firewall address-list add address=youtu.be list=YTB
/ip firewall address-list add address=yt.be list=YTB
/ip firewall address-list add address=googlevideo.com list=YTB
/ip firewall address-list add address=ytimg.com list=YTB
/ip firewall address-list add address=ggpht.com list=YTB
/ip firewall address-list add address=gvt1.com list=YTB
/ip firewall address-list add address=youtube-nocookie.com list=YTB
/ip firewall address-list add address=youtube-ui.l.google.com list=YTB
/ip firewall address-list add address=youtubeembeddedplayer.googleapis.com list=YTB
/ip firewall address-list add address=youtube.googleapis.com list=YTB
/ip firewall address-list add address=youtubei.googleapis.com list=YTB
/ip firewall address-list add address=yt-video-upload.l.google.com list=YTB
/ip firewall address-list add address=wide-youtube.l.google.com list=YTB
/ip firewall address-list add address=google.com list=YTB
/ip firewall address-list add address=google.ru list=YTB
Дети, собаки и прочие близкие родственники зрителей пропускаются бесплатно, они проверяются справочной системой типа DNS и также автоматически заносятся в списки:
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=youtube.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=googlevideo.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=ggpht.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=youtu.be type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=yt.be type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=ytimg.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=gvt1.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=youtube-nocookie.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=googleapis.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=google.com type=FWD
/ip dns static add address-list=YTB forward-to=10.20.1.1 match-subdomain=yes name=google.ru type=FWD
Список детей и собак действует сутки, потом его надо обновлять:
/ip dns set address-list-extra-time=1d
Каждому на входе автоматически выдают билетик:
/ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=YTB new-routing-mark=ytb passthrough=no
А тут у нас вход в кинозал, но до него еще дойти надо, ночь на дворе, темно…
/ip firewall nat add action=masquerade chain=srcnat out-interface=wireguard1
А для этого у нас есть информационно-указательная система:
/routing table add disabled=no fib name=ytb
На которую выводится информация как именно пройти в кинотеатр в три часа ночи:
/ip route add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.20.1.1 pref-src= 0.0.0.0 routing-table=ytb scope=30 suppress-hw-offload=no target-scope=10
После прочтения указанной китайской грамоты содержимое съесть, навигатор перезагрузить.
66😁59👌18👍7❤4
🏆 Чем интересен рейтинг ESB-решений 2025?
CNews опубликовал рейтинг ESB-платформ, необходимых для интеграцииразличных приложений и систем в единую информационную среду.
Эксперты оценили ключевые параметры:
▫️ Архитектура
▫️ Масштабируемость
▫️ Отказоустойчивость
▫️ Безопасность
▫️ Уровень поддержки
Лидером рейтинга стала платформа Digital Q.Integration от Диасофт. Она позволяет строить суверенную интеграционную инфраструктуру на базе российского ПО с прозрачной архитектурой и промышленной надёжностью.
🚀 Хотите убедиться в этом сами?
У Диасофт есть интерактивный демо-стенд, где можно:
• Самостоятельно изучить сценарии интеграции
• Посмотреть, как решение работает под нагрузкой
• Оценить возможности платформы на практике
👉 Переходите по ссылке и тестируйте!
Реклама. ООО "ДИАСОФТ ЭКОСИСТЕМА". ИНН 9715403607.
CNews опубликовал рейтинг ESB-платформ, необходимых для интеграцииразличных приложений и систем в единую информационную среду.
Эксперты оценили ключевые параметры:
▫️ Архитектура
▫️ Масштабируемость
▫️ Отказоустойчивость
▫️ Безопасность
▫️ Уровень поддержки
Лидером рейтинга стала платформа Digital Q.Integration от Диасофт. Она позволяет строить суверенную интеграционную инфраструктуру на базе российского ПО с прозрачной архитектурой и промышленной надёжностью.
🚀 Хотите убедиться в этом сами?
У Диасофт есть интерактивный демо-стенд, где можно:
• Самостоятельно изучить сценарии интеграции
• Посмотреть, как решение работает под нагрузкой
• Оценить возможности платформы на практике
👉 Переходите по ссылке и тестируйте!
Реклама. ООО "ДИАСОФТ ЭКОСИСТЕМА". ИНН 9715403607.
🤮2👌1
Некоторые приемы использования SNAT для маршрутизации пакетов
Классическая схема соединения площадок при помощи VPN-туннелей предполагает дополнительную настройку маршрутизации. Так в нашем случае (схема внизу заметки), чтобы компьютеры сети 192.168.111.0/24 получили доступ к узлам сети 192.168.222.0/24 нам нужно указать на роутере маршрут к 192.168.222.0/24 через 10.10.10.2.
В этом случае пакет будет отправлен роутером в туннель и благополучно достигнет точки назначения, а вот чтобы он мог вернуться обратно нам понадобится уже на другой стороне, также на роутере, задать маршрут к 192.168.111.0/24 через 10.10.10.1.
Это стандартная схема и предполагает, что узлы обоих сетей могут обращаться друг к другу, при необходимости разграничить доступ мы обычно используем брандмауэр.
Ситуация осложняется, если за вашим роутером находится несколько сетей, в этом случае маршруты придется прописать к каждой из них, еще хуже, если такие сети могут создаваться динамически (допустим, тестовые среды).
Еще один недостаток такого подхода – противоположная сторона видит структуру вашей сети и оригинальные адреса устройств, иногда это может быть нежелательно.
Ну и наконец – вы не контролируете роутер с той стороны и не можете добавить туда обратный маршрут, или можете, но не гарантируете его сохранность и правильность.
Как быть? Использовать SNAT или маскарадинг, если не хотите вникать в настройки. Суть сводится к тому, что для всех уходящих в туннель пакетов мы подменяем адрес источника адресом нашей стороны туннеля – т.е. 10.10.10.1.
В этом случае пакеты также достигнуть сети назначения, так как маршрут, направляющий пакеты к 192.168.222.0/24 через 10.10.10.2 у нас есть. А вот обратным адресом у таких пакетов будет числиться 10.10.10.1, что позволит роутеру с противоположной стороны просто отправить их на другой конец туннеля.
Затем уже наш роутер проведет обратное преобразование и направит пакеты их реальному источнику.
Из недостатков – на той стороне нельзя фильтровать доступ по IP, это же одновременно плюс – реальные адреса вашей сети спрятаны за NAT, что может быть предпочтительно в иных сценариях.
Классическая схема соединения площадок при помощи VPN-туннелей предполагает дополнительную настройку маршрутизации. Так в нашем случае (схема внизу заметки), чтобы компьютеры сети 192.168.111.0/24 получили доступ к узлам сети 192.168.222.0/24 нам нужно указать на роутере маршрут к 192.168.222.0/24 через 10.10.10.2.
В этом случае пакет будет отправлен роутером в туннель и благополучно достигнет точки назначения, а вот чтобы он мог вернуться обратно нам понадобится уже на другой стороне, также на роутере, задать маршрут к 192.168.111.0/24 через 10.10.10.1.
Это стандартная схема и предполагает, что узлы обоих сетей могут обращаться друг к другу, при необходимости разграничить доступ мы обычно используем брандмауэр.
Ситуация осложняется, если за вашим роутером находится несколько сетей, в этом случае маршруты придется прописать к каждой из них, еще хуже, если такие сети могут создаваться динамически (допустим, тестовые среды).
Еще один недостаток такого подхода – противоположная сторона видит структуру вашей сети и оригинальные адреса устройств, иногда это может быть нежелательно.
Ну и наконец – вы не контролируете роутер с той стороны и не можете добавить туда обратный маршрут, или можете, но не гарантируете его сохранность и правильность.
Как быть? Использовать SNAT или маскарадинг, если не хотите вникать в настройки. Суть сводится к тому, что для всех уходящих в туннель пакетов мы подменяем адрес источника адресом нашей стороны туннеля – т.е. 10.10.10.1.
В этом случае пакеты также достигнуть сети назначения, так как маршрут, направляющий пакеты к 192.168.222.0/24 через 10.10.10.2 у нас есть. А вот обратным адресом у таких пакетов будет числиться 10.10.10.1, что позволит роутеру с противоположной стороны просто отправить их на другой конец туннеля.
Затем уже наш роутер проведет обратное преобразование и направит пакеты их реальному источнику.
Из недостатков – на той стороне нельзя фильтровать доступ по IP, это же одновременно плюс – реальные адреса вашей сети спрятаны за NAT, что может быть предпочтительно в иных сценариях.
👍32❤7🤮1🍌1
Журнал регистрации 1С:Предприятие
Тема журнала регистрации не нова, но спотыкаются на ней с завидной регулярностью. Поэтому сегодня мы решили подробно обсудить эту проблему.
Итак, что такое журнал регистрации? Это внутренний лог конфигурации, который содержит события обращения к объектам информационной базы. Его не следует путать с технологическим журналом, который представляет лог работы платформы.
Что можно узнать из журнала регистрации? Да практически все, если конечно у вас задан нужный уровень логирования. Кто создал, изменил, провел, распровел или удалил документ, элемент справочника и т.д. и т.п.
Также в нем фиксируются все ошибки и предупреждения, но опять-таки только те, которые мы получаем на уровне 1С:Предприятия, т.е. внутри программы.
Изначально для журнала регистрации использовался последовательный формат. Несмотря на то, что файлы таких журналов используют собственные расширения по факту там плоский текст в собственном формате.
Запись событий происходит в самый конец файла и является крайне простым и дешевым действием. Собственно говоря, так работают практически все системы первичных логов – пишут плоский текст в конец файла.
Но в 1С не все так просто, инструмент для чтения лога встроен в конфигурации и воспользоваться им может любой пользователь, установив отборы на свое усмотрение или вовсе их не устанавливая.
И вот тут всплывает обратная сторона плоского текстового лога – будучи крайне дешевым по записи он весьма и весьма дорог на чтение. Фактически нам придется прочитать и распарсить весь объем текста.
В силу особенностей работы 1С такой запрос в рабочее время мог просто положить базу.
После чего какой-то «светлой» голове пришла идея использовать для хранения логов SQLite. Проблема чтения сразу решилась, ну это, собственно сильная сторона любой СУБД. Зато сразу прибавилось других проблем.
Запись в СУБД – дело дорогое, особенно непосредственная запись, которую использовала 1С. А SQLite сама по себе на запись не быстрая, вот и вышло, что хотели как лучше, а получилось, как всегда.
Плюс размер данных в СУБД всегда будет выше, чем размер плоского текста. Поэтому еще и получили раздувание файла журнала местами до совсем гигантских размеров, особенно по сравнению с размером базы.
В результате вопрос чтения из журнала решили, но ценой значительного ухудшения скорости записи, что привело к серьезным проблемам производительности во многих практических случаях.
В итоге от формата SQLite отказались и снова вернули последовательный формат, в последних версиях платформы к нему добавили индексы, но особых улучшений на чтение пока замечено не было.
Итак, что вам нужно сделать со своим журналом регистрации? Прежде всего определиться с форматом, точнее перевести все базы, которые могли использовать до сих пор формат SQLite в последовательный формат.
Затем настроить нужную подробность ведения журнала. От этого непосредственно зависит его объем.
И, наконец, настройте его разбиение по периодам. Лучше всего по дням. А затем, с определенной периодичностью просто копируйте старые файлы журнала в резервное хранилище и удаляйте их из основного каталога.
Глубина хранения журнала должна быть минимальной. Это даст вам гарантию, что даже если кто-то запустит в рабочее время сложный поиск по журналу без ограничений по периоду, то он не положит всю базу.
А для разбора полетов вы всегда можете скопировать файлы журнала обратно, хотя на рабочей базе лучше такого не делать, а использовать копию.
Тема журнала регистрации не нова, но спотыкаются на ней с завидной регулярностью. Поэтому сегодня мы решили подробно обсудить эту проблему.
Итак, что такое журнал регистрации? Это внутренний лог конфигурации, который содержит события обращения к объектам информационной базы. Его не следует путать с технологическим журналом, который представляет лог работы платформы.
Что можно узнать из журнала регистрации? Да практически все, если конечно у вас задан нужный уровень логирования. Кто создал, изменил, провел, распровел или удалил документ, элемент справочника и т.д. и т.п.
Также в нем фиксируются все ошибки и предупреждения, но опять-таки только те, которые мы получаем на уровне 1С:Предприятия, т.е. внутри программы.
Изначально для журнала регистрации использовался последовательный формат. Несмотря на то, что файлы таких журналов используют собственные расширения по факту там плоский текст в собственном формате.
Запись событий происходит в самый конец файла и является крайне простым и дешевым действием. Собственно говоря, так работают практически все системы первичных логов – пишут плоский текст в конец файла.
Но в 1С не все так просто, инструмент для чтения лога встроен в конфигурации и воспользоваться им может любой пользователь, установив отборы на свое усмотрение или вовсе их не устанавливая.
И вот тут всплывает обратная сторона плоского текстового лога – будучи крайне дешевым по записи он весьма и весьма дорог на чтение. Фактически нам придется прочитать и распарсить весь объем текста.
В силу особенностей работы 1С такой запрос в рабочее время мог просто положить базу.
После чего какой-то «светлой» голове пришла идея использовать для хранения логов SQLite. Проблема чтения сразу решилась, ну это, собственно сильная сторона любой СУБД. Зато сразу прибавилось других проблем.
Запись в СУБД – дело дорогое, особенно непосредственная запись, которую использовала 1С. А SQLite сама по себе на запись не быстрая, вот и вышло, что хотели как лучше, а получилось, как всегда.
Плюс размер данных в СУБД всегда будет выше, чем размер плоского текста. Поэтому еще и получили раздувание файла журнала местами до совсем гигантских размеров, особенно по сравнению с размером базы.
В результате вопрос чтения из журнала решили, но ценой значительного ухудшения скорости записи, что привело к серьезным проблемам производительности во многих практических случаях.
В итоге от формата SQLite отказались и снова вернули последовательный формат, в последних версиях платформы к нему добавили индексы, но особых улучшений на чтение пока замечено не было.
Итак, что вам нужно сделать со своим журналом регистрации? Прежде всего определиться с форматом, точнее перевести все базы, которые могли использовать до сих пор формат SQLite в последовательный формат.
Затем настроить нужную подробность ведения журнала. От этого непосредственно зависит его объем.
И, наконец, настройте его разбиение по периодам. Лучше всего по дням. А затем, с определенной периодичностью просто копируйте старые файлы журнала в резервное хранилище и удаляйте их из основного каталога.
Глубина хранения журнала должна быть минимальной. Это даст вам гарантию, что даже если кто-то запустит в рабочее время сложный поиск по журналу без ограничений по периоду, то он не положит всю базу.
А для разбора полетов вы всегда можете скопировать файлы журнала обратно, хотя на рабочей базе лучше такого не делать, а использовать копию.
❤14🔥14🥱3🤝3😁1
sudoedit – безопасное редактирование файлов
Обычно для редактирования конфигурационных файлов администраторы используют запуск редактора с повышением прав, например:
Но это небезопасно, так как процесс редактора запускается с правами суперпользователя, что может оказаться серьезной брешью в системе безопасности.
Скажем, это дает возможность эксплуатировать локальные уязвимости на предмет повышения прав и даже без уязвимостей выполнять некоторые «интересные» вещи.
Редактор vim, например, имеет специальный режим, позволяющий выполнять системные команды. Т.е. вполне реален следующий сценарий:
На практике это не обязательно будет столь деструктивно, но вполне может позволить непривилегированному пользователю получить доступ туда, куда не положено, скажем к закрытым ключам или иной чувствительной информации.
Чтобы избежать подобного сценария sudo предлагает специальную команду sudoedit, которая на первый взгляд делает тоже самое, но несколько по-другому.
Основное отличие заключается в том, что sudoedit сначала делает временную копию файла и открывает ее редактором, установленным в переменной окружения EDITOR с правами обычного пользователя.
Если редактор не установлен, то будет открыть редактор по умолчанию, в Debian и Ubuntu это nano. Но даже если мы запустим через sudoedit тот же vim, то это нам ничего не даст, так как он будет запущен с правами обычного пользователя.
После окончания редактирования sudoedit проверит права пользователя и только после этого заменит оригинальный файл отредактированным.
При этом для пользователя процесс работы с файлом никак не отличается от того, если бы он вызвал редактор через sudo. Но sudoedit позволяет делать это безопасно, не запуская дополнительные процессы с правами суперпользователя.
Обычно для редактирования конфигурационных файлов администраторы используют запуск редактора с повышением прав, например:
sudo editor
Но это небезопасно, так как процесс редактора запускается с правами суперпользователя, что может оказаться серьезной брешью в системе безопасности.
Скажем, это дает возможность эксплуатировать локальные уязвимости на предмет повышения прав и даже без уязвимостей выполнять некоторые «интересные» вещи.
Редактор vim, например, имеет специальный режим, позволяющий выполнять системные команды. Т.е. вполне реален следующий сценарий:
sudo vim
:!rm -rf /*
На практике это не обязательно будет столь деструктивно, но вполне может позволить непривилегированному пользователю получить доступ туда, куда не положено, скажем к закрытым ключам или иной чувствительной информации.
Чтобы избежать подобного сценария sudo предлагает специальную команду sudoedit, которая на первый взгляд делает тоже самое, но несколько по-другому.
Основное отличие заключается в том, что sudoedit сначала делает временную копию файла и открывает ее редактором, установленным в переменной окружения EDITOR с правами обычного пользователя.
Если редактор не установлен, то будет открыть редактор по умолчанию, в Debian и Ubuntu это nano. Но даже если мы запустим через sudoedit тот же vim, то это нам ничего не даст, так как он будет запущен с правами обычного пользователя.
После окончания редактирования sudoedit проверит права пользователя и только после этого заменит оригинальный файл отредактированным.
При этом для пользователя процесс работы с файлом никак не отличается от того, если бы он вызвал редактор через sudo. Но sudoedit позволяет делать это безопасно, не запуская дополнительные процессы с правами суперпользователя.
👍22👌7👀3🔥1🤮1
Домены – неочевидные опасности для инфраструктуры
Многие администраторы придерживаются принципа, что имя узла должно отражать его роль. Это распространенная практика и в том или ином виде используется многими, в том числе и автором этого канала.
Действительно, просто и понятно:
Подобный подход перешел и на доменные имена или, как их чаще называют, поддомены. Система плюс-минус та же:
Легко понять, легко запомнить, легко продиктовать, при необходимости. Долгое время такая схема не вызывала проблем, до тех пор, пока не случился массовый переход на защищенные соединения.
Сегодня TLS-защита и валидный сертификат от внешнего CA являются нормой жизни, но они же несут в себе новые угрозы, достаточно неочевидные.
Дело в том, что как только вы хотя бы один раз получите сертификат для своего доменного имени, то любой желающий легко и просто сможет получить его и все остальные поддомены вашего домена простым запросом.
И это не утечка, и не уязвимость. Для прозрачности деятельности и повышения безопасности управления сертификатами все серьезные CA (включая СА Минцифры) поддерживают и ведут публичные Certificate Transparency логи, куда вносят все выданные сертификаты.
Это хорошо для безопасности сертификатов и пользователей, так как можно всегда проконтролировать кто, где и когда выпускал сертификаты для домена. Но это может быть очень плохо в плане раскрытия информации об инфраструктуре.
Любой праздношатающийся легко и непринужденно получает полный список ваших ресурсов, даже если они находятся на разных площадках и у разных провайдеров.
Далее ему сразу становится понятно назначение многих узлов. Т.е. больше ему не нужно угадывать, что скрывается за тем или иным узлом, все и так написано в доменном имени. Это уменьшает активность злоумышленника, а следовательно, уменьшает шансы заметить и пресечь ее еще на раннем этапе.
А сам злоумышленник может сразу выделить интересующие его узлы инфраструктуры и сосредоточить на них свое внимание, не распыляясь на все подряд.
Кроме того, сами администраторы порой добровольно дают хорошие подсказки. Скажем у нас уже есть узел терминального сервера, теперь мы решили ввести второй. Да что там думать, давай сделаем так:
или
Даже если это число обозначает просто год, то уже дает намек на то, что на другом сервере стоит более старая версия ПО, что уже делает его приоритетным. Ну а если мы видим такое, то тут и думать ничего не надо (реальный пример, между прочим):
Подобный подход именования сервисов равносилен тому, что вы нарисовали и публично опубликовали схему свой инфраструктуры, но при этом продолжаете замазывать белые IP на скриншотах.
Как быть, что делать? Ну в крайности впадать тоже не стоит, совершенно абстрактные имена доменов также неудобны и приводят к сложностям и хаосу. Попробуйте без дополнительных записей поймите кто здесь есть кто?
То-то же… В тоже время в мире есть много простых и запоминающихся взаимосвязанный некоторой общностью наборов слов, которые можно использовать в качестве доменных имен.
Вы можете даже построить некоторую систему, которая будет понятна только вам, но не раскроет лишней информации злоумышленнику. Женские имена, цвета, буквы греческого алфавита, животные, породы собак, кошек, планеты, звезды и т.д. и т.п.
Попробуйте догадаться, что стоит за каждым сервисом:
Их столь же просто запомнить, легко понять, легко продиктовать… Но они не раскрывают никакой дополнительной информации о вашей инфраструктуре.
Многие администраторы придерживаются принципа, что имя узла должно отражать его роль. Это распространенная практика и в том или ином виде используется многими, в том числе и автором этого канала.
Действительно, просто и понятно:
SRV-DC01
SRV-SMB01
UBNT-GW01
VPN-WG02
Подобный подход перешел и на доменные имена или, как их чаще называют, поддомены. Система плюс-минус та же:
mail.example.com
ftp.example.com
rdp.example.com
share.eample.com
Легко понять, легко запомнить, легко продиктовать, при необходимости. Долгое время такая схема не вызывала проблем, до тех пор, пока не случился массовый переход на защищенные соединения.
Сегодня TLS-защита и валидный сертификат от внешнего CA являются нормой жизни, но они же несут в себе новые угрозы, достаточно неочевидные.
Дело в том, что как только вы хотя бы один раз получите сертификат для своего доменного имени, то любой желающий легко и просто сможет получить его и все остальные поддомены вашего домена простым запросом.
И это не утечка, и не уязвимость. Для прозрачности деятельности и повышения безопасности управления сертификатами все серьезные CA (включая СА Минцифры) поддерживают и ведут публичные Certificate Transparency логи, куда вносят все выданные сертификаты.
Это хорошо для безопасности сертификатов и пользователей, так как можно всегда проконтролировать кто, где и когда выпускал сертификаты для домена. Но это может быть очень плохо в плане раскрытия информации об инфраструктуре.
Любой праздношатающийся легко и непринужденно получает полный список ваших ресурсов, даже если они находятся на разных площадках и у разных провайдеров.
Далее ему сразу становится понятно назначение многих узлов. Т.е. больше ему не нужно угадывать, что скрывается за тем или иным узлом, все и так написано в доменном имени. Это уменьшает активность злоумышленника, а следовательно, уменьшает шансы заметить и пресечь ее еще на раннем этапе.
А сам злоумышленник может сразу выделить интересующие его узлы инфраструктуры и сосредоточить на них свое внимание, не распыляясь на все подряд.
Кроме того, сами администраторы порой добровольно дают хорошие подсказки. Скажем у нас уже есть узел терминального сервера, теперь мы решили ввести второй. Да что там думать, давай сделаем так:
rdp.example.com
rdp22.example.com
или
rdp2022.example.com
Даже если это число обозначает просто год, то уже дает намек на то, что на другом сервере стоит более старая версия ПО, что уже делает его приоритетным. Ну а если мы видим такое, то тут и думать ничего не надо (реальный пример, между прочим):
rdp2008.example.com
rdp2012.example.com
rdp2016.example.com
Подобный подход именования сервисов равносилен тому, что вы нарисовали и публично опубликовали схему свой инфраструктуры, но при этом продолжаете замазывать белые IP на скриншотах.
Как быть, что делать? Ну в крайности впадать тоже не стоит, совершенно абстрактные имена доменов также неудобны и приводят к сложностям и хаосу. Попробуйте без дополнительных записей поймите кто здесь есть кто?
p4sssic.example.com
3f1f9b6.example.com
tafcbbd.example.com
То-то же… В тоже время в мире есть много простых и запоминающихся взаимосвязанный некоторой общностью наборов слов, которые можно использовать в качестве доменных имен.
Вы можете даже построить некоторую систему, которая будет понятна только вам, но не раскроет лишней информации злоумышленнику. Женские имена, цвета, буквы греческого алфавита, животные, породы собак, кошек, планеты, звезды и т.д. и т.п.
Попробуйте догадаться, что стоит за каждым сервисом:
red.example.com
yellow.example.com
green.example.com
Их столь же просто запомнить, легко понять, легко продиктовать… Но они не раскрывают никакой дополнительной информации о вашей инфраструктуре.
1👍49🤮9❤6💯4👎3
Какие бывают ядра Linux
Данный вопрос рано или поздно возникает у любого пользователя данной системы, чаще всего в контексте того какое из них лучше использовать для тех или иных целей. Поэтому в данной заметке мы решили коротко рассмотреть этот вопрос.
Все официальные выпуски ядер делятся на:
🔹 Mainline – это основная ветвь разработки под управлением Линуса Торвальдса, здесь первыми появляются все новые функции и идут процессы разработки. Данное ядро не поставляется в собранном виде и предназначено для разработчиков и энтузиастов.
По сути, его можно считать вечным релиз-кандидатом. В основную ветвь попадают уже достаточно стабильные новые функции и возможности и происходит окончательная доработка, отладка и тестирование.
В определенный момент происходит фиксация и выпуск нового релиза, после чего разработка в основной ветви продолжается, новые релизы ядер выпускаются каждые 9 – 10 недель.
🔹 Stable – после релиза ядро переходит в стабильное состояние и распространяется не только в виде исходных кодов, но и через репозитории дистрибутивов в виде бинарных сборок.
Дальнейшего развития ядра в рамках стабильного выпуска не происходит, при необходимости, примерно раз в неделю, выпускаются исправления обнаруженных ошибок.
Поддержка и выпуск исправлений происходит до выпуска следующего стабильного ядра, после чего поддержка предыдущих выпусков прекращается, а пользователям рекомендуется обновить ядро.
🔹 Longterm – ядро с длительной поддержкой. Для многих корпоративных систем и серверов менять ядро каждые три-четыре месяца является нежелательным, особенно для систем с длительным сроком поддержки, основной задачей которых является поддержание стабильности окружения.
Для этих целей выпускаются отдельные версии ядра с длительной поддержкой, которые не получают новых функций, а только исправления ошибок на всем этапе жизненного цикла.
На сегодняшний день к ним относятся:
▫️ 5.10 (13.12.2020) - окончание поддержки в декабре 2026
▫️ 5.15 (31.10.2021) - окончание поддержки в декабре 2026
▫️ 6.1 (11.12.2022) - окончание поддержки в декабре 2026
▫️ 6.6 (29.10.2023) - окончание поддержки в декабре 2026
▫️ 6.12 (17.11.2024) - окончание поддержки в декабре 2026
▫️ 6.18 (30.11.2025) - окончание поддержки в декабре 2027
Долгосрочные ядра выбираются на основании многих факторов и их выпуск происходит приблизительно раз в год. Сроки поддержки ядер также не являются окончательными и могут быть продлены.
🔹 Super Longterm – отдельные версии ядер со сверхдлительной поддержкой – 10 лет. Поддерживаются проектом Civil Infrastructure Platform под патронажем Linux Foundation. Цель проекта – предоставление для целей гражданской инфраструктуры стабильного ПО с длительными сроками поддержки.
В настоящий момент поддерживаются ядра:
▫️ SLTS 4.4 (17.01.2017) - окончание поддержки в январе 2027
▫️ SLTS 4.19 (11.01.2019) - окончание поддержки в январе 2029
▫️ SLTS 5.10 (05.12.2021) - окончание поддержки в январе 2031
▫️ SLTS 6.1 (14.07.2023) - окончание поддержки в августе 2033
▫️ SLTS 6.12 (20.05.2025) - окончание поддержки в июне 2035
Кроме официальных сборок есть достаточно популярная версия ядер от сообщества энтузиастов:
🔹 Zen-kernel – содержит значительные оптимизации работы, улучшенную работу с оборудованием, мультимедиа и прочие улучшения. В целом Zen-ядра производительнее обычных и обеспечивают лучшую отзывчивость системы.
Многие дистрибутивы, например, Manjaro штатно предлагают использование Zen-ядер.
Но при этом нужно понимать, что данные ядра не имеют официальной поддержки, их разработка и поддержка осуществляется комьюнити. Также они могут иметь несовместимость с некоторыми дистрибутивами и ПО, а также с отдельными моделями оборудование.
Установка и настройка Zen-ядра также может оказаться сложнее (если только это уже не предусмотрено вашим дистрибутивом) и потребовать более высокой квалификации.
Данный вопрос рано или поздно возникает у любого пользователя данной системы, чаще всего в контексте того какое из них лучше использовать для тех или иных целей. Поэтому в данной заметке мы решили коротко рассмотреть этот вопрос.
Все официальные выпуски ядер делятся на:
🔹 Mainline – это основная ветвь разработки под управлением Линуса Торвальдса, здесь первыми появляются все новые функции и идут процессы разработки. Данное ядро не поставляется в собранном виде и предназначено для разработчиков и энтузиастов.
По сути, его можно считать вечным релиз-кандидатом. В основную ветвь попадают уже достаточно стабильные новые функции и возможности и происходит окончательная доработка, отладка и тестирование.
В определенный момент происходит фиксация и выпуск нового релиза, после чего разработка в основной ветви продолжается, новые релизы ядер выпускаются каждые 9 – 10 недель.
🔹 Stable – после релиза ядро переходит в стабильное состояние и распространяется не только в виде исходных кодов, но и через репозитории дистрибутивов в виде бинарных сборок.
Дальнейшего развития ядра в рамках стабильного выпуска не происходит, при необходимости, примерно раз в неделю, выпускаются исправления обнаруженных ошибок.
Поддержка и выпуск исправлений происходит до выпуска следующего стабильного ядра, после чего поддержка предыдущих выпусков прекращается, а пользователям рекомендуется обновить ядро.
🔹 Longterm – ядро с длительной поддержкой. Для многих корпоративных систем и серверов менять ядро каждые три-четыре месяца является нежелательным, особенно для систем с длительным сроком поддержки, основной задачей которых является поддержание стабильности окружения.
Для этих целей выпускаются отдельные версии ядра с длительной поддержкой, которые не получают новых функций, а только исправления ошибок на всем этапе жизненного цикла.
На сегодняшний день к ним относятся:
▫️ 5.10 (13.12.2020) - окончание поддержки в декабре 2026
▫️ 5.15 (31.10.2021) - окончание поддержки в декабре 2026
▫️ 6.1 (11.12.2022) - окончание поддержки в декабре 2026
▫️ 6.6 (29.10.2023) - окончание поддержки в декабре 2026
▫️ 6.12 (17.11.2024) - окончание поддержки в декабре 2026
▫️ 6.18 (30.11.2025) - окончание поддержки в декабре 2027
Долгосрочные ядра выбираются на основании многих факторов и их выпуск происходит приблизительно раз в год. Сроки поддержки ядер также не являются окончательными и могут быть продлены.
🔹 Super Longterm – отдельные версии ядер со сверхдлительной поддержкой – 10 лет. Поддерживаются проектом Civil Infrastructure Platform под патронажем Linux Foundation. Цель проекта – предоставление для целей гражданской инфраструктуры стабильного ПО с длительными сроками поддержки.
В настоящий момент поддерживаются ядра:
▫️ SLTS 4.4 (17.01.2017) - окончание поддержки в январе 2027
▫️ SLTS 4.19 (11.01.2019) - окончание поддержки в январе 2029
▫️ SLTS 5.10 (05.12.2021) - окончание поддержки в январе 2031
▫️ SLTS 6.1 (14.07.2023) - окончание поддержки в августе 2033
▫️ SLTS 6.12 (20.05.2025) - окончание поддержки в июне 2035
Кроме официальных сборок есть достаточно популярная версия ядер от сообщества энтузиастов:
🔹 Zen-kernel – содержит значительные оптимизации работы, улучшенную работу с оборудованием, мультимедиа и прочие улучшения. В целом Zen-ядра производительнее обычных и обеспечивают лучшую отзывчивость системы.
Многие дистрибутивы, например, Manjaro штатно предлагают использование Zen-ядер.
Но при этом нужно понимать, что данные ядра не имеют официальной поддержки, их разработка и поддержка осуществляется комьюнити. Также они могут иметь несовместимость с некоторыми дистрибутивами и ПО, а также с отдельными моделями оборудование.
Установка и настройка Zen-ядра также может оказаться сложнее (если только это уже не предусмотрено вашим дистрибутивом) и потребовать более высокой квалификации.
👍23❤2🥱2
Забавная маршрутизация
Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.
Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.
Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.
Задачка простая, но не совсем очевидная.
Итак, имеется следующая таблица маршрутизации:
Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?
Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.
Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.
Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.
Задачка простая, но не совсем очевидная.
Итак, имеется следующая таблица маршрутизации:
192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4
Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?
🤮10👀7👍3🔥2
Какие сети находятся за каждым интерфейсом (eth0 - eth4), приведены только последний октет и маска
Anonymous Quiz
16%
0/24 0/25 0/26 0/27 0/28
6%
0/25 128/26 192/27 224/28 240/28
12%
128/25 64/26 32/27 16/28 0/28
6%
везде 0/24
3%
везде 0/28
5%
зависит от маски в пакете
6%
такая таблица работать не будет
6%
недостаточно данных для правильного ответа
39%
посмотреть ответы
👍7👀6
Забавная маршрутизация (ответы)
Есть такой принцип - Бритва Оккама, краткая суть которого в том, что не следует множить сущности без необходимости.
Можно сколько угодно умничать про то, что за интерфейсом может быть сколько угодно любых сетей, но если вопрос прямо спрашивает про сети, то исходим из того, что они там есть.
Итак, у нас есть таблица маршрутизации
И несколько работающих сетей за каждым интерфейсом. Будет ли работать такая таблица? Да, почему нет. Вся тонкость именно в том, как она работает.
Начнем с того, что пакет не содержит такого поля как маска. Только адреса, в нашем случае имеет значение адрес назначения.
Далее вступает в дело таблица маршрутизации, в котором мы ищем наиболее подходящий маршрут для нашего пакета.
Если к месту назначения ведут несколько маршрутов, то выбирается маршрут с маской, содержащий наименьшее количество узлов.
В нашем случае это будет 192.168.0.0/28, сеть /28 содержит 16 адресов, поэтому за eth4 у нас может находиться только 192.168.0.0/28.
Сеть /27 содержит уже 32 адреса, но в eth3 будут направлены только адреса не входящие в 192.168.0.0/28, т.е. следующие 16 адресов. Таким образом за eth3 у нас может быть только сеть 192.168.0.16/28.
Сеть 26 содержит уже 64 адреса, но 32 из них входят в уже указанные нами сети, поэтом за eth2 у нас находится сеть 192.168.0.32/27.
Аналогичным образом вычисляем и сети за eth1 – 192.168.0.64/26 и eth0 – 192.168.0.128/25.
Таким образом правильным является третий вариант ответа в вопросе.
Есть такой принцип - Бритва Оккама, краткая суть которого в том, что не следует множить сущности без необходимости.
Можно сколько угодно умничать про то, что за интерфейсом может быть сколько угодно любых сетей, но если вопрос прямо спрашивает про сети, то исходим из того, что они там есть.
Итак, у нас есть таблица маршрутизации
192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4
И несколько работающих сетей за каждым интерфейсом. Будет ли работать такая таблица? Да, почему нет. Вся тонкость именно в том, как она работает.
Начнем с того, что пакет не содержит такого поля как маска. Только адреса, в нашем случае имеет значение адрес назначения.
Далее вступает в дело таблица маршрутизации, в котором мы ищем наиболее подходящий маршрут для нашего пакета.
Если к месту назначения ведут несколько маршрутов, то выбирается маршрут с маской, содержащий наименьшее количество узлов.
В нашем случае это будет 192.168.0.0/28, сеть /28 содержит 16 адресов, поэтому за eth4 у нас может находиться только 192.168.0.0/28.
Сеть /27 содержит уже 32 адреса, но в eth3 будут направлены только адреса не входящие в 192.168.0.0/28, т.е. следующие 16 адресов. Таким образом за eth3 у нас может быть только сеть 192.168.0.16/28.
Сеть 26 содержит уже 64 адреса, но 32 из них входят в уже указанные нами сети, поэтом за eth2 у нас находится сеть 192.168.0.32/27.
Аналогичным образом вычисляем и сети за eth1 – 192.168.0.64/26 и eth0 – 192.168.0.128/25.
Таким образом правильным является третий вариант ответа в вопросе.
👍36🤔10🤡2❤1🌭1