Девушки в отрасли
Как-то так сложилось, что IT изначально было мужской сферой. Нет, были редкие исключения, но, в общем и целом, это было сугубо мужское царство.
Тут, конечно, можно вспоминать о физических и психологических различиях между мужским и женским полом, но история дает другие примеры.
Многие профессии, которые сегодня считаются априори женскими когда-то были сугубо мужскими. Взять ту же профессию бухгалтера. Когда-то, еще в первой половине прошлого века это была мужская профессия, потом смешанная.
Сегодня бухгалтер четко ассоциируется с женским родом. И мужчина-бухгалтер сегодня прямо как белая ворона. Хотя я знаю мужчин, которые работают на должности главбуха, но даже в этом случае они официально зовутся финансовыми директорами, зам. дир. по финансовой части и т.д. и т.п.
Первой IT-профессией женской направленности стало программирование, девушки-программистки начали появляться еще в конце нулевых, в десятых их стало больше, а сейчас вместе с моим сыном на программировании учится примерно пополам пацанов и девчонок.
Также на профильных форумах и каналах значительно прибавилось девушек, которые задают вполне годные вопросы, учатся, профессионально растут.
Сегодня я все больше и больше вижу девушек в админских и внедренческих чатах и каналах, которые занимаются маркировкой, внедрением и даже админскими делами.
И это хорошо, потому что исторически мужчины — это первопроходцы, которые смело шагают в неизведанное, бьются, преодолевают, покоряют.
Женщины приходят на готовое, в стабильность, их задача поддерживать и сохранять. И то, что в нашей отрасли становится все больше и больше женщин свидетельствует о ее зрелости и стабильности.
И сейчас уже далеко не редкость полностью IT-семьи, где оба супруга работают в одной отрасли и понимают друг друга, чтобы не получилось, как в том анекдоте: «я не сифилитик, а филателист».
Поэтому хочется такую тенденцию всячески поддерживать и наконец-то развеять миф IT-шника, как некого оторванного от мира сего товарища в растянутом свитере с оленями и неспособного поддержать светскую беседу.
Сегодня IT совершенно другая отрасль, не хуже и не лучше остальных, с такими же людьми, как и везде. И место здесь найдется и парням, и девчонкам, и экстравертам, и интровертам.
А девушкам, в преддверии женского праздника хочется пожелать не бояться бородатых админов в свитерах с оленями, а смело идти в отрасль. Вы тут нужны и возможно скоро некоторые профессии перестанут считаться исключительно мужскими.
Как-то так сложилось, что IT изначально было мужской сферой. Нет, были редкие исключения, но, в общем и целом, это было сугубо мужское царство.
Тут, конечно, можно вспоминать о физических и психологических различиях между мужским и женским полом, но история дает другие примеры.
Многие профессии, которые сегодня считаются априори женскими когда-то были сугубо мужскими. Взять ту же профессию бухгалтера. Когда-то, еще в первой половине прошлого века это была мужская профессия, потом смешанная.
Сегодня бухгалтер четко ассоциируется с женским родом. И мужчина-бухгалтер сегодня прямо как белая ворона. Хотя я знаю мужчин, которые работают на должности главбуха, но даже в этом случае они официально зовутся финансовыми директорами, зам. дир. по финансовой части и т.д. и т.п.
Первой IT-профессией женской направленности стало программирование, девушки-программистки начали появляться еще в конце нулевых, в десятых их стало больше, а сейчас вместе с моим сыном на программировании учится примерно пополам пацанов и девчонок.
Также на профильных форумах и каналах значительно прибавилось девушек, которые задают вполне годные вопросы, учатся, профессионально растут.
Сегодня я все больше и больше вижу девушек в админских и внедренческих чатах и каналах, которые занимаются маркировкой, внедрением и даже админскими делами.
И это хорошо, потому что исторически мужчины — это первопроходцы, которые смело шагают в неизведанное, бьются, преодолевают, покоряют.
Женщины приходят на готовое, в стабильность, их задача поддерживать и сохранять. И то, что в нашей отрасли становится все больше и больше женщин свидетельствует о ее зрелости и стабильности.
И сейчас уже далеко не редкость полностью IT-семьи, где оба супруга работают в одной отрасли и понимают друг друга, чтобы не получилось, как в том анекдоте: «я не сифилитик, а филателист».
Поэтому хочется такую тенденцию всячески поддерживать и наконец-то развеять миф IT-шника, как некого оторванного от мира сего товарища в растянутом свитере с оленями и неспособного поддержать светскую беседу.
Сегодня IT совершенно другая отрасль, не хуже и не лучше остальных, с такими же людьми, как и везде. И место здесь найдется и парням, и девчонкам, и экстравертам, и интровертам.
А девушкам, в преддверии женского праздника хочется пожелать не бояться бородатых админов в свитерах с оленями, а смело идти в отрасль. Вы тут нужны и возможно скоро некоторые профессии перестанут считаться исключительно мужскими.
🔥30👍17🤮5❤1
ИИ как печатный станок в программировании
Интересная новость появилась еще перед мартовскими праздниками:
Это произвело эффект разорвавшейся бомбы. Представители Фонда свободного программного обеспечения тут же усомнились в правомерности такого решения, заявив, что разработчик не выполнил правило чистой комнаты, т.е. при разработке он не должен был видеть исходный код переписываемой библиотеки.
На что автор парировал, что он не мог его соблюсти, так как сам был разработчиком старой версии, но новый код совпадает со старым всего на 1,29% и полностью отличается по структуре.
Другие назвали его поступок неэтичным, так как он воспользовался трудом других людей и ничего не вернул взамен. Но это уже лирика, которая к реальному положению дел имеет крайне опосредованное отношение.
Брюс Перенс, один из ключевых лидеров движения Open Source и Free Software считает, что написание кода при помощи ИИ в ближайшее время кардинально изменит рынок ПО, сравнив это явление с изобретением печатного станка.
И он во многом прав. Печатный станок позволил просто и быстро тиражировать бумажные книги. Сделав печатные издание дешевле и доступнее.
То же самое начинает делать ИИ, да, мы и раньше могли просто взять и скопировать нужную нам программу или библиотеку, но это не отменяло вопроса ее лицензирования и законности применения.
Переписать? Это мог сделать далеко не каждый, да и экономический эффект такой деятельности выходил крайне сомнительным.
А теперь ИИ спокойно напишет вам полный аналог за небольшое количество времени и токенов, еще немного потребуется на ее отладку и вот у вас в руках собственный экземпляр ПО с нужной функциональностью.
Да, пока еще не все столь хорошо, но ИИ стремительно развиваются и если еще несколько лет назад вайбкодинг был сугубо баловством, то теперь ИИ спокойно пишет в агентском режиме несложные проекты.
Но вишенка на торте здесь в том, что ИИ учится на открытом коде и фактически используя этот открытый код создает собственные решения, которые вы открытыми делать не обязаны.
Это давняя проблема ИИ, когда создатели контента, на котором учится ИИ не только не получают назад совсем ничего, но и теряют посетителей, потому что их перехватывает ИИ.
Технического решения эта проблема не имеет, так как относится к моральным и юридическим категориям и очевидно, что отрасль ИИ требует серьезного юридического регулирования.
А пока что нас ждет серьезное изменение рынка ПО, с появлением на нем массы игроков, использующих ИИ. В принципе тоже самое происходило и с развитием книгопечатания, когда на рынок вместе с серьезной литературой выплеснулась масса развлекательного чтива весьма сомнительного качества.
Теперь нас ждет примерно тоже самое на рынке ПО: масса софта самого сомнительного качества и назначения. Теперь не нужно часами сидеть над кодом, проектировать архитектуру приложения и делать прочие сложные и скучные вещи.
Теперь берем ИИ и говорим ей: напиши мне тоже самое, только на самом супер-пупер модном и молодежном фреймворке, а вот сюда добавь перламутровые пуговицы и розового котика.
Нет, серьезный, взрослый софт никуда не денется, но только его разработчик несколько раз задумается, а нужно ли ему реализовывать те или иные фишки, если их сразу же подхватят все, кому не лень или приберечь до лучших времен. А может тоже пойти по принципу добавления котиков и пуговок.
В результате время, конечно, расставит все на свои места, но перед этим нас ждет бурная эпоха преобразования рынка ПО и сейчас никто не может сказать каким он будет после всех этих изменений.
Интересная новость появилась еще перед мартовскими праздниками:
Дэн Бланшар (Dan Blanchard), разработчик Python-библиотеки chardet для определения кодировки символов, выпустил новую версию библиотеки под лицензией MIT вместо ранее применявшейся лицензии LGPL.
Разработчик утверждает, что AI-ассистент Anthropic Claude, который теперь числится в списке контрибьюторов, переписал библиотеку без использования оригинального кода, что позволило ему заменить копилефт лицензию на пермиссивную.
Это произвело эффект разорвавшейся бомбы. Представители Фонда свободного программного обеспечения тут же усомнились в правомерности такого решения, заявив, что разработчик не выполнил правило чистой комнаты, т.е. при разработке он не должен был видеть исходный код переписываемой библиотеки.
На что автор парировал, что он не мог его соблюсти, так как сам был разработчиком старой версии, но новый код совпадает со старым всего на 1,29% и полностью отличается по структуре.
Другие назвали его поступок неэтичным, так как он воспользовался трудом других людей и ничего не вернул взамен. Но это уже лирика, которая к реальному положению дел имеет крайне опосредованное отношение.
Брюс Перенс, один из ключевых лидеров движения Open Source и Free Software считает, что написание кода при помощи ИИ в ближайшее время кардинально изменит рынок ПО, сравнив это явление с изобретением печатного станка.
И он во многом прав. Печатный станок позволил просто и быстро тиражировать бумажные книги. Сделав печатные издание дешевле и доступнее.
То же самое начинает делать ИИ, да, мы и раньше могли просто взять и скопировать нужную нам программу или библиотеку, но это не отменяло вопроса ее лицензирования и законности применения.
Переписать? Это мог сделать далеко не каждый, да и экономический эффект такой деятельности выходил крайне сомнительным.
А теперь ИИ спокойно напишет вам полный аналог за небольшое количество времени и токенов, еще немного потребуется на ее отладку и вот у вас в руках собственный экземпляр ПО с нужной функциональностью.
Да, пока еще не все столь хорошо, но ИИ стремительно развиваются и если еще несколько лет назад вайбкодинг был сугубо баловством, то теперь ИИ спокойно пишет в агентском режиме несложные проекты.
Но вишенка на торте здесь в том, что ИИ учится на открытом коде и фактически используя этот открытый код создает собственные решения, которые вы открытыми делать не обязаны.
Это давняя проблема ИИ, когда создатели контента, на котором учится ИИ не только не получают назад совсем ничего, но и теряют посетителей, потому что их перехватывает ИИ.
Технического решения эта проблема не имеет, так как относится к моральным и юридическим категориям и очевидно, что отрасль ИИ требует серьезного юридического регулирования.
А пока что нас ждет серьезное изменение рынка ПО, с появлением на нем массы игроков, использующих ИИ. В принципе тоже самое происходило и с развитием книгопечатания, когда на рынок вместе с серьезной литературой выплеснулась масса развлекательного чтива весьма сомнительного качества.
Теперь нас ждет примерно тоже самое на рынке ПО: масса софта самого сомнительного качества и назначения. Теперь не нужно часами сидеть над кодом, проектировать архитектуру приложения и делать прочие сложные и скучные вещи.
Теперь берем ИИ и говорим ей: напиши мне тоже самое, только на самом супер-пупер модном и молодежном фреймворке, а вот сюда добавь перламутровые пуговицы и розового котика.
Нет, серьезный, взрослый софт никуда не денется, но только его разработчик несколько раз задумается, а нужно ли ему реализовывать те или иные фишки, если их сразу же подхватят все, кому не лень или приберечь до лучших времен. А может тоже пойти по принципу добавления котиков и пуговок.
В результате время, конечно, расставит все на свои места, но перед этим нас ждет бурная эпоха преобразования рынка ПО и сейчас никто не может сказать каким он будет после всех этих изменений.
👍20🤷♂8😱5🤮2❤1
В первой строке скрипта есть команда "umask 077", что произойдет с маской после его запуска?
Anonymous Quiz
29%
Изменится маска в контексте скрипта на время его работы
21%
Изменится маска сеанса в котором запущен скрипт до выхода из него
8%
Изменится маска всей системы до ее перезагрузки
9%
Неверное значение маски
20%
Недостаточно данных для ответа
13%
Нет ни одного правильного ответа
🤮12👍1😁1
Аптайм
Когда-то давно, когда деревья были выше, трава зеленее, а пиво вкуснее, аптайм был некой «сакральной» величиной, которой было принято меряться и его величина считалась признаком крутости, которая была прямо пропорциональна величине аптайма.
А те, у кого был короткий (аптайм, разумеется), подвергались насмешкам и не допускались в почтенное общество гигантов системного администрирования.
Но те времена давно прошли и в нашу эпоху интернета с доступом туда каждого чайника и утюга большой аптайм стал признаком низкой квалификации и непрофессионализма.
Как минимум это означает, что все это время система находилась без обслуживания, как на программном, так и на аппаратном уровне. Также это означает, что на нее не ставились обновления и вообще не уделяли внимания.
А это, особенно если к системе есть доступ из интернета – очень плохо. Сегодня толпы ботов только и делают, что рыщут по просторам сети в поисках различных уязвимостей.
Еще одна популярная отмазка: «мол у меня там важные сервисы 24/7 и совсем-совсем никак» — это ничто иное как завуалированное признание собственной низкой квалификации. Ее следует понимать как: вот тут у меня огромная точка отказа, сюда столько всего накручено и завязано, что даже перезагружать страшно.
Можно приводить массу контраргументов, но, по сути, они не меняют главного: если ваша инфраструктура не позволяет перезагрузить узел, то она построена плохо. Особенно сегодня, когда даже самым маленьким за очень недорого доступны и виртуализация, и кластеризация и много-много чего другого.
Поэтому меряться аптаймом сегодня глупо, он просто есть и никакой ценной информации не несет. Системы должны обслуживаться и перезагружаться, это нормально.
Равно как не стоит говорить о «важных» и «круглосуточных» сервисах. Если они построены так, что их нельзя вывести на облуживание – значит они построены плохо. И нужно не бравировать этим, а думать, как сделать хорошо. Или пригласить того, кто может это сделать.
А критерием хорошо построенной и работающей системы должен быть не аптайм, а высокий уровень доступности ее сервисов для пользователя. Ему все равно, сколько система проработала без перезагрузки, ему надо чтобы она просто работала.
Когда-то давно, когда деревья были выше, трава зеленее, а пиво вкуснее, аптайм был некой «сакральной» величиной, которой было принято меряться и его величина считалась признаком крутости, которая была прямо пропорциональна величине аптайма.
А те, у кого был короткий (аптайм, разумеется), подвергались насмешкам и не допускались в почтенное общество гигантов системного администрирования.
Но те времена давно прошли и в нашу эпоху интернета с доступом туда каждого чайника и утюга большой аптайм стал признаком низкой квалификации и непрофессионализма.
Как минимум это означает, что все это время система находилась без обслуживания, как на программном, так и на аппаратном уровне. Также это означает, что на нее не ставились обновления и вообще не уделяли внимания.
А это, особенно если к системе есть доступ из интернета – очень плохо. Сегодня толпы ботов только и делают, что рыщут по просторам сети в поисках различных уязвимостей.
Еще одна популярная отмазка: «мол у меня там важные сервисы 24/7 и совсем-совсем никак» — это ничто иное как завуалированное признание собственной низкой квалификации. Ее следует понимать как: вот тут у меня огромная точка отказа, сюда столько всего накручено и завязано, что даже перезагружать страшно.
Можно приводить массу контраргументов, но, по сути, они не меняют главного: если ваша инфраструктура не позволяет перезагрузить узел, то она построена плохо. Особенно сегодня, когда даже самым маленьким за очень недорого доступны и виртуализация, и кластеризация и много-много чего другого.
Поэтому меряться аптаймом сегодня глупо, он просто есть и никакой ценной информации не несет. Системы должны обслуживаться и перезагружаться, это нормально.
Равно как не стоит говорить о «важных» и «круглосуточных» сервисах. Если они построены так, что их нельзя вывести на облуживание – значит они построены плохо. И нужно не бравировать этим, а думать, как сделать хорошо. Или пригласить того, кто может это сделать.
А критерием хорошо построенной и работающей системы должен быть не аптайм, а высокий уровень доступности ее сервисов для пользователя. Ему все равно, сколько система проработала без перезагрузки, ему надо чтобы она просто работала.
💯35👍6🤔4🥱2🤮1
Скомпрометированные пароли
Как мы знаем, хороший пароль должен быть сложным. Но в настоящее время этого недостаточно. Ваш пароль еще не должен быть скомпрометирован.
Что это такое и чем чревато? При компрометации пароль становится известен широкому кругу лиц и попадает в специальные базы, которые могут впоследствии использоваться для подбора паролей. А это крайне серьезно снижает надежность системы.
Поэтому перед применением пароль желательно проверить на компрометацию, тем более это нужно сделать для уже используемых паролей.
Как это сделать? Можно использовать базу HIBP, где содержится более 306 миллионов утекших в сеть паролей.
Для этого следует использовать специальный сайт https://haveibeenpwned.com/Passwords
Можно ли ему доверять и не грозит ли это утечкой пароля?
Можно, сайт использует специальный протокол, который позволяет проверить пароль на утечку без раскрытия самого пароля. Через API данная база используется для проверки утечек паролей многими коммерческими сервисами и менеджерами паролей.
Также должно быть ясно, что любые непонятные приложения и иные сайты, обещающие аналогичные функции быть безопасными не могут и использовать их не следует.
Кроме того, если вы не доверяете свои пароли никаким онлайн-сервисам или хотите самостоятельно работать с базой утекших паролей, то вы можете скачать ее при помощи инструмента PwnedPasswordsDownloader https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
Это тоже официальный инструмент, при помощи которого вы получите список хешей утекших паролей, а дальше уже на что хватит знаний и умений.
На скриншоте мы проверили в сервисе один очень «популярный» пароль из десяти букв и цифр подряд на клавиатуре, набранных по очереди:1q2w3e45t
Как мы знаем, хороший пароль должен быть сложным. Но в настоящее время этого недостаточно. Ваш пароль еще не должен быть скомпрометирован.
Что это такое и чем чревато? При компрометации пароль становится известен широкому кругу лиц и попадает в специальные базы, которые могут впоследствии использоваться для подбора паролей. А это крайне серьезно снижает надежность системы.
Поэтому перед применением пароль желательно проверить на компрометацию, тем более это нужно сделать для уже используемых паролей.
Как это сделать? Можно использовать базу HIBP, где содержится более 306 миллионов утекших в сеть паролей.
Для этого следует использовать специальный сайт https://haveibeenpwned.com/Passwords
Можно ли ему доверять и не грозит ли это утечкой пароля?
Можно, сайт использует специальный протокол, который позволяет проверить пароль на утечку без раскрытия самого пароля. Через API данная база используется для проверки утечек паролей многими коммерческими сервисами и менеджерами паролей.
Также должно быть ясно, что любые непонятные приложения и иные сайты, обещающие аналогичные функции быть безопасными не могут и использовать их не следует.
Кроме того, если вы не доверяете свои пароли никаким онлайн-сервисам или хотите самостоятельно работать с базой утекших паролей, то вы можете скачать ее при помощи инструмента PwnedPasswordsDownloader https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
Это тоже официальный инструмент, при помощи которого вы получите список хешей утекших паролей, а дальше уже на что хватит знаний и умений.
На скриншоте мы проверили в сервисе один очень «популярный» пароль из десяти букв и цифр подряд на клавиатуре, набранных по очереди:
50👍14❤3🔥3🤮3👎1
Демилитаризованная зона (DMZ) в современных сетях
Концепция DMZ известна давно, предполагалось, что это будет отдельный сегмент сети, отделенный брандмауэрами как от внешней, так и от внутренних сетей, и в нем будут размещены потенциально небезопасные сервисы.
Т.е. мы собирали в таком сегменте все сервисы, имеющие доступ из внешнего мира, и ограничивали их собственной подсетью, серьезно ограничив или вообще запретив возможность доступа к внутренней сети.
Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности.
Данный подход позволял в случае взлома или компрометации внешнего сервиса ограничить злоумышленника рамками DMZ и избежать их проникновения за периметр основной сети предприятия.
В целом такой подход работает и сегодня для классических служб, таких как веб-сервер или электронная почта. Помещая такие сервера в отдельный сегмент и закрыв их брандмауэром как от внешней, так и внутренней сети мы повышаем как безопасность внутри периметра, так и безопасность самих вынесенных в DMZ сервисов.
Но современные реалии вносят новые угрозы. Например, понятие периметра сегодня оказалось серьезно размыто и далеко не каждая внутренняя сеть может считаться безопасной.
Причин тому несколько. Начиная с собственных устройств сотрудников, которые они используют в рабочем процессе (чаще всего телефоны) и которые имеют доступ к сети предприятия и заканчивая средствами удаленного доступа, которые используются не только сотрудниками, но и подрядчиками и партнерами.
Все это приводит к тому, что внутренняя сеть перестает быть безопасным и доверенным местом, поэтому политика нормально открытого брандмауэра внутри таких сетей перестает быть приемлемой.
Можно, конечно, настраивать брандмауэр на каждом сервере отдельно, но это утомительно и всегда есть возможность что-то упустить. Поэтому более интересной является мысль вынести внутренние сервера в отдельную DMZ и тем самым поместить их в доверенную среду, которую затем можно просто закрыть от внутренней сети межсетевым экраном.
Получается, как бы немного наоборот. Если классическая DMZ изолировала от доверенной локальной сети потенциально небезопасные узлы, то в нашем случае DMZ защищает сервера от потенциальных угроз из внутренней сети.
В принципе данный подход уже давно используется там, где работают с конфиденциальной и секретной информацией, когда содержащие такие данные узлы выносят в изолированные участки сети с ограниченным доступом.
Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе.
И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей.
В этом случае все удаленщики также помещаются в отдельный сегмент, который изолирован как от внешней, так и от внутренней сети, а доступ к необходимым сервисам осуществляется посредством проброса портов или обратным проксированием.
При этом никаких сервисов в этой зоне быть не должно, только удаленщики и только средства доступа к необходимым им сервисам внутри сети или в отдельных DMZ.
Таким образом сегодня понятие DMZ серьезно расширилось и теперь не просто предусматривает некую отдельную подсеть для потенциально ненадежных сервисов, а подразумевает разделение сети на сегменты с разным уровнем безопасности и доверия, совершенно безотносительного того, являются помещенные в DMZ сервисы внешними или внутренними.
А в ряде случаев и вовсе не предполагает размещение там каких-либо сервисов, используя DMZ для изоляции ненадежных пользователей.
Концепция DMZ известна давно, предполагалось, что это будет отдельный сегмент сети, отделенный брандмауэрами как от внешней, так и от внутренних сетей, и в нем будут размещены потенциально небезопасные сервисы.
Т.е. мы собирали в таком сегменте все сервисы, имеющие доступ из внешнего мира, и ограничивали их собственной подсетью, серьезно ограничив или вообще запретив возможность доступа к внутренней сети.
Для узлов локальной сети все узлы DMZ также рассматривались как внешние, со всеми вытекающими выводами в сфере безопасности.
Данный подход позволял в случае взлома или компрометации внешнего сервиса ограничить злоумышленника рамками DMZ и избежать их проникновения за периметр основной сети предприятия.
В целом такой подход работает и сегодня для классических служб, таких как веб-сервер или электронная почта. Помещая такие сервера в отдельный сегмент и закрыв их брандмауэром как от внешней, так и внутренней сети мы повышаем как безопасность внутри периметра, так и безопасность самих вынесенных в DMZ сервисов.
Но современные реалии вносят новые угрозы. Например, понятие периметра сегодня оказалось серьезно размыто и далеко не каждая внутренняя сеть может считаться безопасной.
Причин тому несколько. Начиная с собственных устройств сотрудников, которые они используют в рабочем процессе (чаще всего телефоны) и которые имеют доступ к сети предприятия и заканчивая средствами удаленного доступа, которые используются не только сотрудниками, но и подрядчиками и партнерами.
Все это приводит к тому, что внутренняя сеть перестает быть безопасным и доверенным местом, поэтому политика нормально открытого брандмауэра внутри таких сетей перестает быть приемлемой.
Можно, конечно, настраивать брандмауэр на каждом сервере отдельно, но это утомительно и всегда есть возможность что-то упустить. Поэтому более интересной является мысль вынести внутренние сервера в отдельную DMZ и тем самым поместить их в доверенную среду, которую затем можно просто закрыть от внутренней сети межсетевым экраном.
Получается, как бы немного наоборот. Если классическая DMZ изолировала от доверенной локальной сети потенциально небезопасные узлы, то в нашем случае DMZ защищает сервера от потенциальных угроз из внутренней сети.
В принципе данный подход уже давно используется там, где работают с конфиденциальной и секретной информацией, когда содержащие такие данные узлы выносят в изолированные участки сети с ограниченным доступом.
Еще одна серьезная угроза – это удаленщики, явление в последние годы массовое и практически неконтролируемое. Потому как вы не можете сказать кто именно сейчас на том конце соединения: сам сотрудник или его малолетний ребенок, а может он вообще забыл ноутбук где-нибудь в кафе.
И все что защищает VPN – это только сам канал доступа, от некорректных действий со стороны пользователя это не спасет. Поэтому мы последние несколько лет практикуем дополнительные DMZ именно для VPN-пользователей.
В этом случае все удаленщики также помещаются в отдельный сегмент, который изолирован как от внешней, так и от внутренней сети, а доступ к необходимым сервисам осуществляется посредством проброса портов или обратным проксированием.
При этом никаких сервисов в этой зоне быть не должно, только удаленщики и только средства доступа к необходимым им сервисам внутри сети или в отдельных DMZ.
Таким образом сегодня понятие DMZ серьезно расширилось и теперь не просто предусматривает некую отдельную подсеть для потенциально ненадежных сервисов, а подразумевает разделение сети на сегменты с разным уровнем безопасности и доверия, совершенно безотносительного того, являются помещенные в DMZ сервисы внешними или внутренними.
А в ряде случаев и вовсе не предполагает размещение там каких-либо сервисов, используя DMZ для изоляции ненадежных пользователей.
👍22🔥14
Как правильно редактировать юниты systemd
Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.
Действительно, сравните сложность написания init-файла и юнита. 🤷🏻♀️
И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.
Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:
▫️
▫️
▫️
Директория
Вроде бы просто, да не совсем. При обновлении пакета юнит в
Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит.
К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.
Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям.
Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in.
Скажем, нам нужно внести изменения в работу юнита
Проще всего это сделать с помощью команды:
Если вы добавите:
Еще одним достоинством команды
Откатить изменения можно командой
Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.
Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.
Действительно, сравните сложность написания init-файла и юнита. 🤷🏻♀️
И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.
Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:
▫️
/usr/lib/systemd/system – юниты установленные вместе с пакетами▫️
/run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса▫️
/etc/systemd/system – юниты, созданные системным администраторомДиректория
/etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения. Вроде бы просто, да не совсем. При обновлении пакета юнит в
/usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим. Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит.
К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.
Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям.
Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in.
Скажем, нам нужно внести изменения в работу юнита
myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf.Проще всего это сделать с помощью команды:
systemctl edit myservice
systemctl edit myservice.timer
[Unit]
Requires=новая зависимость
After=новая зависимость
ExecStart или OnCalendar в таймерах.Если вы добавите:
[Service]
ExecStart=новая команда
ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:
[Service]
ExecStart=
ExecStart=новая команда
Еще одним достоинством команды
systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена.Откатить изменения можно командой
systemctl revert myservice
systemctl daemon-reload
systemctl restart myservice
Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.
1👍36❤2🤝1
Настраиваем терминальный сервер на Windows Server в рабочей группе
Роль терминального сервера пользуется огромной популярностью у системных администраторов самых разных по размеру предприятий, от самых маленьких, до очень больших.
Действительно, это достаточно эффективный способ организации работы пользователей и эффективного использования вычислительных ресурсов.
Но есть и определенные сложности: начиная с Windows Server 2012 компания Microsoft решила, что для развертывания терминальных служб обязательно нужен домен Active Directory.
Это не всегда приемлемо и уместно. Значит будем обходиться без домена, а как - расскажем в нашей статье.
✅ Читать далее
Роль терминального сервера пользуется огромной популярностью у системных администраторов самых разных по размеру предприятий, от самых маленьких, до очень больших.
Действительно, это достаточно эффективный способ организации работы пользователей и эффективного использования вычислительных ресурсов.
Но есть и определенные сложности: начиная с Windows Server 2012 компания Microsoft решила, что для развертывания терминальных служб обязательно нужен домен Active Directory.
Это не всегда приемлемо и уместно. Значит будем обходиться без домена, а как - расскажем в нашей статье.
✅ Читать далее
👍28🤡3🔥1🥱1🤝1
Нужен ли мне Active Directory?
В комментариях читатели попросили разобрать отдельно этот вопрос, когда и как следует понять, что одноранговая структура себя изжила и пора внедрять Active Directory или не пора…
Вопрос непростой и при его рассмотрении следует учитывать ряд аспектов, главные из которых мы разберем.
1️⃣ Экономический. Лицензирование Windows Server, начиная с выпуска 2016 предусматривает новую модель лицензирования, согласно ей вы должны лицензировать все физические ядра сервера, при этом минимальное количество лицензий на процессор – 8, на физический хост – 16.
Даже если у вас 1 процессор и 6 физических ядер вы все равно должны лицензировать 16. То же самое касается и виртуальных машин, допустим у вас Windows Server запушен на Proxmox и ему выделено скромных 2 ядра.
Сэкономили? Не тут-то было, по условиям лицензии вы обязаны пролицензировать все ядра хоста виртуализации, даже если он работает под ОС отличной от Windows. Т.е. в любом случае это от 16 лицензий на ядро и выше.
Если делать все по уму, т.е. два контроллера AD на разных физических узлах – это минимум две лицензии на 16 ядер, также не забываем про CAL для каждого клиента, который использует сервисы Windows прямо или опосредованно.
2️⃣ Поддержка со стороны ПО. У вас в эксплуатации может быть совершенно разное ПО, с разными свойствами и возможностями интеграции. После чего вам нужно изучить насколько оно совместимо c AD.
Как минимум, оно должно поддерживать сквозную аутентификацию и авторизацию. И эти два термина путать не в коем случае нельзя.
Аутентификация – процесс установления личности пользователя, которая указывает на то, что он действительно тот, за которого себя выдает. И не более.
Авторизация – проверка прав доступа аутентифицированного пользователя к некоторому ресурсу. Т.е. на этапе аутентификации мы установили, что это действительно Иванов, а на этапе авторизации мы проверяем, имеет ли Иванов доступ к запрашиваемому ресурсу.
Active Directory, как и любая другая служба каталогов решает в первую очередь вопрос Single Sign-On (SSO, единый вход), т.е. пользователь один раз вводит пароль при входе в учетную запись и получает доступ везде, куда у него есть права.
Это позволяет избежать отдельных списков доступа и набора учетных записей для каждой службы, но при этом все используемые вами службы должны поддерживать вход через домен AD.
Где-то приложения могут поддерживать только сквозную аутентификацию и вам все равно придется вести отдельные списки доступа на уровне приложения.
3️⃣ Централизация администрирования. Третий краеугольный столп AD – групповые политики, которые позволяют централизованно настраивать операционную систему и ПО. Здесь мы тоже исходим из принципа целесообразности.
Как активно мы используем GPO? Какое количество политик используем? Как часто изменяем и добавляем новые? Какой выигрыш по времени мы от этого всего имеем?
Если наше ПО не имеет возможности работать с GPO, то в чем смысл применения данной технологии? Все равно нам нужно настраивать каждую рабочую станцию руками.
Убрать из работы рутину? А сколько ее там? Может можно переложить эту работу на скрипты или выполнить вместе с настройкой производственного ПО.
4️⃣ И четвертое, не столь очевидное – квалификация персонала. AD более требовательна к квалификации обслуживающих специалистов, так как централизация это и возможность быстро и просто настроить сеть, и возможность также быстро и просто все уронить.
И выиграв на выполнении некоторых административных задач вы проиграете на стоимости обслуживающего персонала. А в наше время еще надо смотреть на возможные перспективы развития и импортозамещения и только после этого делать выбор в пользу проприетарных технологий.
В комментариях читатели попросили разобрать отдельно этот вопрос, когда и как следует понять, что одноранговая структура себя изжила и пора внедрять Active Directory или не пора…
Вопрос непростой и при его рассмотрении следует учитывать ряд аспектов, главные из которых мы разберем.
1️⃣ Экономический. Лицензирование Windows Server, начиная с выпуска 2016 предусматривает новую модель лицензирования, согласно ей вы должны лицензировать все физические ядра сервера, при этом минимальное количество лицензий на процессор – 8, на физический хост – 16.
Даже если у вас 1 процессор и 6 физических ядер вы все равно должны лицензировать 16. То же самое касается и виртуальных машин, допустим у вас Windows Server запушен на Proxmox и ему выделено скромных 2 ядра.
Сэкономили? Не тут-то было, по условиям лицензии вы обязаны пролицензировать все ядра хоста виртуализации, даже если он работает под ОС отличной от Windows. Т.е. в любом случае это от 16 лицензий на ядро и выше.
Если делать все по уму, т.е. два контроллера AD на разных физических узлах – это минимум две лицензии на 16 ядер, также не забываем про CAL для каждого клиента, который использует сервисы Windows прямо или опосредованно.
2️⃣ Поддержка со стороны ПО. У вас в эксплуатации может быть совершенно разное ПО, с разными свойствами и возможностями интеграции. После чего вам нужно изучить насколько оно совместимо c AD.
Как минимум, оно должно поддерживать сквозную аутентификацию и авторизацию. И эти два термина путать не в коем случае нельзя.
Аутентификация – процесс установления личности пользователя, которая указывает на то, что он действительно тот, за которого себя выдает. И не более.
Авторизация – проверка прав доступа аутентифицированного пользователя к некоторому ресурсу. Т.е. на этапе аутентификации мы установили, что это действительно Иванов, а на этапе авторизации мы проверяем, имеет ли Иванов доступ к запрашиваемому ресурсу.
Active Directory, как и любая другая служба каталогов решает в первую очередь вопрос Single Sign-On (SSO, единый вход), т.е. пользователь один раз вводит пароль при входе в учетную запись и получает доступ везде, куда у него есть права.
Это позволяет избежать отдельных списков доступа и набора учетных записей для каждой службы, но при этом все используемые вами службы должны поддерживать вход через домен AD.
Где-то приложения могут поддерживать только сквозную аутентификацию и вам все равно придется вести отдельные списки доступа на уровне приложения.
3️⃣ Централизация администрирования. Третий краеугольный столп AD – групповые политики, которые позволяют централизованно настраивать операционную систему и ПО. Здесь мы тоже исходим из принципа целесообразности.
Как активно мы используем GPO? Какое количество политик используем? Как часто изменяем и добавляем новые? Какой выигрыш по времени мы от этого всего имеем?
Если наше ПО не имеет возможности работать с GPO, то в чем смысл применения данной технологии? Все равно нам нужно настраивать каждую рабочую станцию руками.
Убрать из работы рутину? А сколько ее там? Может можно переложить эту работу на скрипты или выполнить вместе с настройкой производственного ПО.
4️⃣ И четвертое, не столь очевидное – квалификация персонала. AD более требовательна к квалификации обслуживающих специалистов, так как централизация это и возможность быстро и просто настроить сеть, и возможность также быстро и просто все уронить.
И выиграв на выполнении некоторых административных задач вы проиграете на стоимости обслуживающего персонала. А в наше время еще надо смотреть на возможные перспективы развития и импортозамещения и только после этого делать выбор в пользу проприетарных технологий.
👍39❤4🤡4😱3😁2
Распознаем речь при помощи Whisper
Недавно у нас возникла необходимость транскрибировать ряд аудиофайлов в текст с таймкодами и точным разбитием по фразам.
Задача даже на сегодняшний день нетривиальная, особенно если вам нужен качественный результат. Бесплатные сервисы либо ограничены по времени, либо сильно страдают по качеству.
Поэтому самое время обратиться к достижениям ИИ, а именно Whisper мощной модели для автоматического распознавания речи (ASR) с открытым исходным кодом, разработанная OpenAI.
Вы можете использовать ее через API, но платно, либо установить на собственном ПК – бесплатно, но вам понадобится ПК уровнем от среднего и выше, наличие быстрого ускорителя NVIDIA приветствуется, но не является обязательным требованием.
На самом деле Whisper – это не одна, а целый набор моделей, предлагающий разное качество распознавания речи и разные требования к ресурсам.
На практике имеет смысл использовать модели:
▫️medium – хорошая скорость, среднее качество, 3-5 ГБ ОЗУ
▫️large – профессиональное качество при небольшой скорости и самых больших требованиях к ОЗУ – 10-12 ГБ.
▫️ turbo – то же самое, что и large, но только быстрее, за счет упрощения модели, требует 6-8 ГБ.
В нашем случае требовалось транскрибировать запись судебного заседания и medium не всегда нормально справлялся с юридическими терминами, large и turbo делали это гораздо лучше, при этом turbo сильно заметно быстрее.
Но так как в юридических делах наиболее важна точность, то мы предпочли модель large, предпочитая качество скорости. На CPU Ryzen 9 5900X скорость ее работы составила примерно 0,25, т.е. на часовую запись у вас уйдет примерно 4 часа времени.
Попробовать Whisper можно совсем не сложно на своем оборудовании, после чего самостоятельно сделать выводы о его пригодности в конкретной ситуации. Для работы нам понадобится Python и FFmpeg.
Установим их при помощи пакетного менеджера Winget:
Так как мы имеем дело с Python, то, чтобы избежать возможных проблем с зависимостями и библиотеками хорошим тоном является запуск проекта в отдельном виртуальном окружении (ENV), для этого перейдем в папку проекта, скажем
И активируем его:
Впоследствии, когда вы захотите поработать с проектом еще раз, вам потребуется только заново активировать окружение командой, указанной выше.
Установим Whisper:
После чего просто запускаем распознавание речи командой:
Путь к файлу укажите в двойных кавычках, в пути используйте прямые слеши
Далее указываем язык, модель и формат вывода, если вам нужны точные таймкоды, то используйте стандартный формат субтитров – SRT.
Для использования ускорения на GPU вам потребуется заменить некоторые библиотеки, в этом же ENV выполните:
Затем к строке запуска добавьте дополнительный ключ для использования CUDA:
Если вам нужно дополнительно распознавание спикеров (диаризация), то установите модуль WhisperX:
И добавьте ключ
Теперь вывод кроме таймкодов будет размечаться метками SPEAKER_00, SPEAKER_01 и т.д Но качество такого распознавания не всегда уверенное, особенно если вы транскрибируете прения или дискуссию, где спикеры могут перебивать друг друга.
Недавно у нас возникла необходимость транскрибировать ряд аудиофайлов в текст с таймкодами и точным разбитием по фразам.
Задача даже на сегодняшний день нетривиальная, особенно если вам нужен качественный результат. Бесплатные сервисы либо ограничены по времени, либо сильно страдают по качеству.
Поэтому самое время обратиться к достижениям ИИ, а именно Whisper мощной модели для автоматического распознавания речи (ASR) с открытым исходным кодом, разработанная OpenAI.
Вы можете использовать ее через API, но платно, либо установить на собственном ПК – бесплатно, но вам понадобится ПК уровнем от среднего и выше, наличие быстрого ускорителя NVIDIA приветствуется, но не является обязательным требованием.
На самом деле Whisper – это не одна, а целый набор моделей, предлагающий разное качество распознавания речи и разные требования к ресурсам.
На практике имеет смысл использовать модели:
▫️medium – хорошая скорость, среднее качество, 3-5 ГБ ОЗУ
▫️large – профессиональное качество при небольшой скорости и самых больших требованиях к ОЗУ – 10-12 ГБ.
▫️ turbo – то же самое, что и large, но только быстрее, за счет упрощения модели, требует 6-8 ГБ.
В нашем случае требовалось транскрибировать запись судебного заседания и medium не всегда нормально справлялся с юридическими терминами, large и turbo делали это гораздо лучше, при этом turbo сильно заметно быстрее.
Но так как в юридических делах наиболее важна точность, то мы предпочли модель large, предпочитая качество скорости. На CPU Ryzen 9 5900X скорость ее работы составила примерно 0,25, т.е. на часовую запись у вас уйдет примерно 4 часа времени.
Попробовать Whisper можно совсем не сложно на своем оборудовании, после чего самостоятельно сделать выводы о его пригодности в конкретной ситуации. Для работы нам понадобится Python и FFmpeg.
Установим их при помощи пакетного менеджера Winget:
winget install -e --id Python.Python.3.12
winget install -e --id Gyan.FFmpeg
Так как мы имеем дело с Python, то, чтобы избежать возможных проблем с зависимостями и библиотеками хорошим тоном является запуск проекта в отдельном виртуальном окружении (ENV), для этого перейдем в папку проекта, скажем
F:\Wishper и откроем там терминал с консолью PowerShell, после чего создадим виртуальное окружение:py -m venv whisper-env
И активируем его:
.\whisper-env\Scripts\Activate.ps1
Впоследствии, когда вы захотите поработать с проектом еще раз, вам потребуется только заново активировать окружение командой, указанной выше.
Установим Whisper:
pip install -U openai-whisper
После чего просто запускаем распознавание речи командой:
whisper "audio.mp3" --language ru --model medium --output_format srt
Путь к файлу укажите в двойных кавычках, в пути используйте прямые слеши
/ или обратные удвоенные \\, например:"C:/Users/Имя/audio.mp3"
"C:\\Users\\Имя\\audio.mp3"
Далее указываем язык, модель и формат вывода, если вам нужны точные таймкоды, то используйте стандартный формат субтитров – SRT.
Для использования ускорения на GPU вам потребуется заменить некоторые библиотеки, в этом же ENV выполните:
pip uninstall torch torchvision torchaudio -y
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
Затем к строке запуска добавьте дополнительный ключ для использования CUDA:
whisper "audio.mp3" --language ru --model medium --output_format srt --device cuda
Если вам нужно дополнительно распознавание спикеров (диаризация), то установите модуль WhisperX:
pip install whisperx
И добавьте ключ
–diarize, например:whisperx "audio.mp3" --language ru --model medium –diarize --output_format srt
Теперь вывод кроме таймкодов будет размечаться метками SPEAKER_00, SPEAKER_01 и т.д Но качество такого распознавания не всегда уверенное, особенно если вы транскрибируете прения или дискуссию, где спикеры могут перебивать друг друга.
23👍20👌6
Насколько критично использовать ECC-память для ZFS. Часть_1
Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS.
Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно:
Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные.
В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти.
Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки.
Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным.
Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п.
Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей.
В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study
Согласно этим данным, вероятность ошибки в течении одного года составляет для:
▫️ 1 DIMM – 8.2%
▫️ 4 DIMM – 28.98%
▫️ 8 DIMM – 49.56%
▫️ 16 DIMM – 74.56%
Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит:
▫️ 1 год – 29%
▫️ 3 года -63%
▫️ 5 лет – 82%
Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока.
Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок.
Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки.
Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию.
При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок.
При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей:
🔸 Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год
🔸 Среди «проблемных» DIMM медианное количество ошибок - 64 в год, среднее - 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок)
🔸 Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок
Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените.
Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах.
В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.
Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS.
Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно:
В ZFS нет ничего особенного, что требовало бы или поощряло использование ECC‑памяти (памяти с коррекцией ошибок) в большей степени, чем в случае с любой другой файловой системой.
Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные.
В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти.
Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки.
Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным.
Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п.
Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей.
В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study
Согласно этим данным, вероятность ошибки в течении одного года составляет для:
▫️ 1 DIMM – 8.2%
▫️ 4 DIMM – 28.98%
▫️ 8 DIMM – 49.56%
▫️ 16 DIMM – 74.56%
Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит:
▫️ 1 год – 29%
▫️ 3 года -63%
▫️ 5 лет – 82%
Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока.
Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок.
Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки.
Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию.
При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок.
При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей:
🔸 Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год
🔸 Среди «проблемных» DIMM медианное количество ошибок - 64 в год, среднее - 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок)
🔸 Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок
Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените.
Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах.
В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.
👍17❤8🔥5
Windows Vista – провал или…
Windows Vista все считают одним из самых больших провалов Microsoft и в реальности Vista действительно провалилась на рынке, но говорит ли это о том, что Vista была плохой системой?
Вовсе нет, плохой системой Vista не была, но ее провал был неизбежным в тех обстоятельствах и при тех решениях, которые сопутствовали ее выходу на рынок.
Windows XP был несомненным успехом компании, но вместе с тем становилось понятно, что архитектура NT5 себя исчерпала. Нужны были новые решения и на волне эйфории разработчики замахнулись на нечто принципиально новое – проект Blackcomb.
Однако на этом пути что-то пошло не так, планы никак не хотели становиться реальностью и очень скоро стало ясно, что реальных сроков выполнения проекта назвать никто не может, поэтому решили сначала выпустить некоторую промежуточную ОС, которую назвали Longhorn.
Но ее разработка тоже на задалась, в результате в 2004 году проект был перезапущен с нуля и были взяты реальные и достижимые цели, потому что время уже серьезно поджимало, рынок ждал новую ОС от Microsoft, а ее все не было…
Также для новой ОС были крайне велики пользовательские ожидания, во многом подогретые самой Microsoft, все ждали чего-то нового.
Начало разработки тогда еще Blackcomb пришелся на эпоху гонки гигагерц, когда тактовые частоты процессоров постоянно росли и отрасль была полна оптимизма. На момент перезапуска проекта в 2004 году перспективы дальнейшего роста частоты выглядели уже не столь радужно, но все-таки рынок ожидал продолжения роста.
В результате, к моменту выпуска в 2007 году Vista оказалась в ситуации, когда она могла нормально запускаться и работать только на достаточно мощных процессорах и системах от 2 ГБ памяти, что составляло на тот момент верхний сегмент рынка.
В массах же были те самые «два ядра – два гига», причем ядра там были достаточно скоромные 2-2,2 ГГц, в то время как разработчики предполагали массовое распространение систем с частотами 3-4 ГГц.
Но переигрывать что-то было уже поздно, тем более на компанию сильно давили производители ПК, которым нужно было представить на рынке новые компьютеры с Vista и Microsoft серьезно снизила аппаратные требования к системе.
Вторым по силе источником негатива стала новая видеоподсистема WDDM, которая полностью отвязывала видеокарту от ядра системы и значительно повышала стабильность. Если раньше крах видеодрайвера означал крах всей системы, то теперь драйвер просто перезапускался, экран моргал и систем работала дальше.
Но это привело к серьезной просадке производительности, если раньше ваша видеокарта более-менее тянула современные игры, то теперь вам нужно было идти в магазин за новой.
Масла в огонь добавили и программные проблемы. Драйвера к новой системе были не готовы, софт частично несовместим, частично не оптимизирован, вкупе с занижением системных требований это делало Vista похожей на улитку, попавшую в студень.
Многие нововведения были также неотрегулированны и раздражали, тот же излишне назойливый UAC или брандмауэр.
Со временем многие проблемы решили, оптимизировали производительность, подросли вычислительные мощности, но ничего из этого систему спасти уже не могло, что и показал выпуск первого сервис-пака, после которого Vista, по сути, становилась другой системой.
После чего было принято решения закрыть проект и срочно выпустить новую ОС на базе доработанной Vista, которой стала Windows 7 ставшая не менее успешной нежели Windows XP, но это уже совсем другая история.
Но не будем забывать, что все то, что мы видим в современных ОС, включая Windows 10 и Windows 11 было впервые реализовано в Windows Vista и технически это была крайне прогрессивная для своего времени система.
Но условия в которых она была выведена на рынок не оставили ей ни одного шанса на успех.
Windows Vista все считают одним из самых больших провалов Microsoft и в реальности Vista действительно провалилась на рынке, но говорит ли это о том, что Vista была плохой системой?
Вовсе нет, плохой системой Vista не была, но ее провал был неизбежным в тех обстоятельствах и при тех решениях, которые сопутствовали ее выходу на рынок.
Windows XP был несомненным успехом компании, но вместе с тем становилось понятно, что архитектура NT5 себя исчерпала. Нужны были новые решения и на волне эйфории разработчики замахнулись на нечто принципиально новое – проект Blackcomb.
Однако на этом пути что-то пошло не так, планы никак не хотели становиться реальностью и очень скоро стало ясно, что реальных сроков выполнения проекта назвать никто не может, поэтому решили сначала выпустить некоторую промежуточную ОС, которую назвали Longhorn.
Но ее разработка тоже на задалась, в результате в 2004 году проект был перезапущен с нуля и были взяты реальные и достижимые цели, потому что время уже серьезно поджимало, рынок ждал новую ОС от Microsoft, а ее все не было…
Также для новой ОС были крайне велики пользовательские ожидания, во многом подогретые самой Microsoft, все ждали чего-то нового.
Начало разработки тогда еще Blackcomb пришелся на эпоху гонки гигагерц, когда тактовые частоты процессоров постоянно росли и отрасль была полна оптимизма. На момент перезапуска проекта в 2004 году перспективы дальнейшего роста частоты выглядели уже не столь радужно, но все-таки рынок ожидал продолжения роста.
В результате, к моменту выпуска в 2007 году Vista оказалась в ситуации, когда она могла нормально запускаться и работать только на достаточно мощных процессорах и системах от 2 ГБ памяти, что составляло на тот момент верхний сегмент рынка.
В массах же были те самые «два ядра – два гига», причем ядра там были достаточно скоромные 2-2,2 ГГц, в то время как разработчики предполагали массовое распространение систем с частотами 3-4 ГГц.
Но переигрывать что-то было уже поздно, тем более на компанию сильно давили производители ПК, которым нужно было представить на рынке новые компьютеры с Vista и Microsoft серьезно снизила аппаратные требования к системе.
Вторым по силе источником негатива стала новая видеоподсистема WDDM, которая полностью отвязывала видеокарту от ядра системы и значительно повышала стабильность. Если раньше крах видеодрайвера означал крах всей системы, то теперь драйвер просто перезапускался, экран моргал и систем работала дальше.
Но это привело к серьезной просадке производительности, если раньше ваша видеокарта более-менее тянула современные игры, то теперь вам нужно было идти в магазин за новой.
Масла в огонь добавили и программные проблемы. Драйвера к новой системе были не готовы, софт частично несовместим, частично не оптимизирован, вкупе с занижением системных требований это делало Vista похожей на улитку, попавшую в студень.
Многие нововведения были также неотрегулированны и раздражали, тот же излишне назойливый UAC или брандмауэр.
Со временем многие проблемы решили, оптимизировали производительность, подросли вычислительные мощности, но ничего из этого систему спасти уже не могло, что и показал выпуск первого сервис-пака, после которого Vista, по сути, становилась другой системой.
После чего было принято решения закрыть проект и срочно выпустить новую ОС на базе доработанной Vista, которой стала Windows 7 ставшая не менее успешной нежели Windows XP, но это уже совсем другая история.
Но не будем забывать, что все то, что мы видим в современных ОС, включая Windows 10 и Windows 11 было впервые реализовано в Windows Vista и технически это была крайне прогрессивная для своего времени система.
Но условия в которых она была выведена на рынок не оставили ей ни одного шанса на успех.
👍26❤4🤮3
Автоматически обновляем списки адресов Telegram на Mikrotik
Что это и для чего – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают известные сложности, когда хочется не только хлеба (текста), но и зрелищ (картинок с видосиками)
Список нужных нам адресов известен и публикуется официально: https://core.telegram.org/resources/cidr.txt
Поэтому мы снова призвали на помощь ИИ и быстренько написали еще один скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
P.S. Перед запуском убедитесь, что файл с адресами доступен с вашего устройства
👇👇👇
Что это и для чего – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают известные сложности, когда хочется не только хлеба (текста), но и зрелищ (картинок с видосиками)
Список нужных нам адресов известен и публикуется официально: https://core.telegram.org/resources/cidr.txt
Поэтому мы снова призвали на помощь ИИ и быстренько написали еще один скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
P.S. Перед запуском убедитесь, что файл с адресами доступен с вашего устройства
👇👇👇
3👍48❤4
Самостоятельно формируем списки адресов на Mikrotik
Использовать готовые списки хорошо, но не всегда это возможно. Бывает возникает потребность составить список адресов до какого-либо специфического сервиса полного набора доменных имен, которого вы не знаете.
Это характерно для крупных проектов, которые могут использовать разветвленную сеть поддоменов разного уровня и которые могут постоянно изменяться. Скажем сегодня страница содержит ссылки на
Не ловить же постоянно руками? Конечно нет, на роутерах Mikrotik можно автоматизировать выявление таких адресов и добавление их в списки, а использовать мы для этого будем не совсем очевидный метод – запись типа FWD на DNS-сервере.
Данная запись позволяет отправить запрос к домену или полностью всей доменной зоне на сторонний DNS-сервер, но в нашем случае это некритично, можете перенаправить запрос хоть на самого себя, главное - чтобы ответ заслуживал доверия.
Более важно то, что RouterOS позволяет не только перенаправить запрос, но и поместить этот адрес в отдельный список. А это именно то, что нам нужно.
Для реализации просто добавьте запись типа FWD, например:
Данная запись переправит все запросы для доменной зоны example.com вместе с поддоменами на DNS-сервер 10.0.0.1 и внесет запись в список EXAMPLE.
А чтобы не обновлять списки слишком часто зададим разумное время жизни таких записей – сутки:
После чего открываем браузер, переходим на интересующий нас ресурс и наблюдаем за тем как списки автоматически пополняются, причем самыми разнообразными поддоменами, о которых вы раньше могли и не догадываться.
Использовать готовые списки хорошо, но не всегда это возможно. Бывает возникает потребность составить список адресов до какого-либо специфического сервиса полного набора доменных имен, которого вы не знаете.
Это характерно для крупных проектов, которые могут использовать разветвленную сеть поддоменов разного уровня и которые могут постоянно изменяться. Скажем сегодня страница содержит ссылки на
cdn01.example.com, а завтра уже на cdn03.example.com и т.д.Не ловить же постоянно руками? Конечно нет, на роутерах Mikrotik можно автоматизировать выявление таких адресов и добавление их в списки, а использовать мы для этого будем не совсем очевидный метод – запись типа FWD на DNS-сервере.
Данная запись позволяет отправить запрос к домену или полностью всей доменной зоне на сторонний DNS-сервер, но в нашем случае это некритично, можете перенаправить запрос хоть на самого себя, главное - чтобы ответ заслуживал доверия.
Более важно то, что RouterOS позволяет не только перенаправить запрос, но и поместить этот адрес в отдельный список. А это именно то, что нам нужно.
Для реализации просто добавьте запись типа FWD, например:
/ip dns static add address-list=EXAMPLE forward-to=10.0.0.1 match-subdomain=yes name=example.com type=FWD
Данная запись переправит все запросы для доменной зоны example.com вместе с поддоменами на DNS-сервер 10.0.0.1 и внесет запись в список EXAMPLE.
А чтобы не обновлять списки слишком часто зададим разумное время жизни таких записей – сутки:
/ip dns set address-list-extra-time=1d
После чего открываем браузер, переходим на интересующий нас ресурс и наблюдаем за тем как списки автоматически пополняются, причем самыми разнообразными поддоменами, о которых вы раньше могли и не догадываться.
❤11🔥6👍1
Windows Me – не то время, не то место…
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
1👍19❤4👨💻3🤮2💯2
Насколько критично использовать ECC-память для ZFS. Часть_2
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
👍20🤔2❤1
Предсказуемые имена сетевых интерфейсов systemd
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
👍30😢3❤2🤮2👌2
Настройка языка и региональных стандартов в Ubuntu или Debian
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
В Debian пакета console-setup может не оказаться, в таком случае выполните:
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
dpkg-reconfigure locales
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
dpkg-reconfigure console-setup
В Debian пакета console-setup может не оказаться, в таком случае выполните:
apt install console-setup
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
dpkg-reconfigure tzdata
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
👍37👌5🔥2❤1
Порядок запуска гостевых систем в Proxmox VE
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
11👍43❤6🥱2