Старое железо – путь в никуда
Каждый раз при разговоре о старых системах приходится слышать мнение, мол на вторичке полно запчастей, можно быстро и эффективно починить или даже можно купить новые, скажем материнские платы.
Такой путь выглядит привлекательным, так как экономит заказчику деньги и время. Не нужно ничего перенастраивать, не нужно менять полностью ПК, заменил железку и спи спокойно.
Мы не будем вдаваться в вопросы надежности тех или иных моделей или сравнивать с надежностью современных – это выходит за рамки здравого смысла и уводит дискуссию в поле идеологических споров, а посмотрим с позиции бизнеса и экономики.
Отказ старого железа – это проблема, бизнес теряет деньги, бизнесу надо ее решить, там, где можно сэкономить – бизнес сэкономит. Но бизнес не знает на чем экономить можно, а на чем нельзя и поэтому он идет к специалисту, т.е. к вам.
И вариантов здесь открывается ровно два. Начнем с покупки нового железа. Да, вам придется перенастроить систему, изменить бизнес-процессы, возможно, что-то виртуализировать и т.д. и т.п. Это затраты, но затраты понятные, здесь и сейчас.
Ломается ли современное железо? Да, ломается. Но в этом случае это не ваша головная боль. Есть продавец, есть сервисный центр, вот пусть заказчик с ними и бодается. Ситуация знакомая, во многом отработанная.
Ну это если вас не угораздило перепродать железо заказчику самому. Потому что при современной маржинальности в 2-5% и разным регуляторным сложностям вроде прослеживаемости или грядущей маркировки заниматься этим делом экономически бессмысленно.
В общем голова у вас не болит, претензий со стороны заказчика тоже нет. Это техника, бывает. Техника на гарантии, починят или поменяют. Тем более что вашу профессиональную репутацию этот прискорбный факт ни разу не затрагивает.
Второй вариант. Это когда мы экономим деньги заказчика и покупаем ему вышедший из строя компонент на вторичном рынке. Тут сразу возникает вопрос с оплатой, потому что нужная вам железка может оказаться только в частных руках и купить ее официально с документами невозможно.
Все это приводит к серым схемам и чаще всего сводится к тому, что мы тебе заплатим безналом, а дальше ты сам. И с учетом того, что вам придется деньги эти обналичивать без внятного основания экономический смысл сделки будет далек от желаемого.
Хотя есть вариант купить с документами у какого-нибудь небольшого продавца, типа компьютерной комиссионки. Но это снимет только одну головную боль – с оплатой.
А головная боль с надежностью этой железки никуда не делась: частное лицо обычно дает гарантию до двери, небольшой продавец даст недели две, не больше. По сути, вы покупаете железку полностью на свой страх и риск.
И если она выйдет из строя через два месяца, то вопросы будут именно к вам, даже если заказчик и купил ее у небольшой фирмы напрямую. Потому что именно вы направили его по этому пути, но вместо решения своей проблемы он получил просто небольшую отсрочку.
Дальше что? Покупать еще одну такую железку? За чей счет? И кто будет оплачивать работы? Заказчик будет настаивать, что он уже один раз за них заплатил, а ссориться с заказчиком по данному поводу – это контрпродуктивно и вредно для репутации.
Но ладно, вам повезло, железка оказалась исправной или вы вообще смогли найти и купить новую. Но все остальное железо осталось старым, и вы можете столкнуться с каскадным отказом. Когда сыпаться начнут уже другие компоненты.
И тут вам снова будут заданы неудобные вопросы, а когда вы все-таки придете к тому, что надо бы купить новый ПК, то воспринято это будет через призму того, что вы вместо того, чтобы пойти по этому пути сразу зачем-то втянули заказчика во весь этот квест с б/у железом.
Основными вопросами будут: кто виноват и за чей счет этот банкет. И ответы на них вам совсем не понравятся. Поэтому старое железо – это конечно интересно и увлекательно, но в реальных производственных сценариях это гарантированный путь в никуда.
Каждый раз при разговоре о старых системах приходится слышать мнение, мол на вторичке полно запчастей, можно быстро и эффективно починить или даже можно купить новые, скажем материнские платы.
Такой путь выглядит привлекательным, так как экономит заказчику деньги и время. Не нужно ничего перенастраивать, не нужно менять полностью ПК, заменил железку и спи спокойно.
Мы не будем вдаваться в вопросы надежности тех или иных моделей или сравнивать с надежностью современных – это выходит за рамки здравого смысла и уводит дискуссию в поле идеологических споров, а посмотрим с позиции бизнеса и экономики.
Отказ старого железа – это проблема, бизнес теряет деньги, бизнесу надо ее решить, там, где можно сэкономить – бизнес сэкономит. Но бизнес не знает на чем экономить можно, а на чем нельзя и поэтому он идет к специалисту, т.е. к вам.
И вариантов здесь открывается ровно два. Начнем с покупки нового железа. Да, вам придется перенастроить систему, изменить бизнес-процессы, возможно, что-то виртуализировать и т.д. и т.п. Это затраты, но затраты понятные, здесь и сейчас.
Ломается ли современное железо? Да, ломается. Но в этом случае это не ваша головная боль. Есть продавец, есть сервисный центр, вот пусть заказчик с ними и бодается. Ситуация знакомая, во многом отработанная.
Ну это если вас не угораздило перепродать железо заказчику самому. Потому что при современной маржинальности в 2-5% и разным регуляторным сложностям вроде прослеживаемости или грядущей маркировки заниматься этим делом экономически бессмысленно.
В общем голова у вас не болит, претензий со стороны заказчика тоже нет. Это техника, бывает. Техника на гарантии, починят или поменяют. Тем более что вашу профессиональную репутацию этот прискорбный факт ни разу не затрагивает.
Второй вариант. Это когда мы экономим деньги заказчика и покупаем ему вышедший из строя компонент на вторичном рынке. Тут сразу возникает вопрос с оплатой, потому что нужная вам железка может оказаться только в частных руках и купить ее официально с документами невозможно.
Все это приводит к серым схемам и чаще всего сводится к тому, что мы тебе заплатим безналом, а дальше ты сам. И с учетом того, что вам придется деньги эти обналичивать без внятного основания экономический смысл сделки будет далек от желаемого.
Хотя есть вариант купить с документами у какого-нибудь небольшого продавца, типа компьютерной комиссионки. Но это снимет только одну головную боль – с оплатой.
А головная боль с надежностью этой железки никуда не делась: частное лицо обычно дает гарантию до двери, небольшой продавец даст недели две, не больше. По сути, вы покупаете железку полностью на свой страх и риск.
И если она выйдет из строя через два месяца, то вопросы будут именно к вам, даже если заказчик и купил ее у небольшой фирмы напрямую. Потому что именно вы направили его по этому пути, но вместо решения своей проблемы он получил просто небольшую отсрочку.
Дальше что? Покупать еще одну такую железку? За чей счет? И кто будет оплачивать работы? Заказчик будет настаивать, что он уже один раз за них заплатил, а ссориться с заказчиком по данному поводу – это контрпродуктивно и вредно для репутации.
Но ладно, вам повезло, железка оказалась исправной или вы вообще смогли найти и купить новую. Но все остальное железо осталось старым, и вы можете столкнуться с каскадным отказом. Когда сыпаться начнут уже другие компоненты.
И тут вам снова будут заданы неудобные вопросы, а когда вы все-таки придете к тому, что надо бы купить новый ПК, то воспринято это будет через призму того, что вы вместо того, чтобы пойти по этому пути сразу зачем-то втянули заказчика во весь этот квест с б/у железом.
Основными вопросами будут: кто виноват и за чей счет этот банкет. И ответы на них вам совсем не понравятся. Поэтому старое железо – это конечно интересно и увлекательно, но в реальных производственных сценариях это гарантированный путь в никуда.
🥱15💯9👍7❤5👨💻1
Как легко и просто «сломать» информационную базу 1С:Предприятие, не снимая «замочка» и ничего не понять?
А что, так можно? Не только можно, но и с завидной регулярностью случается. И называется это - расширения.
Вообще, расширения – это удобный механизм доработки конфигурации или исправления ошибок без внесения изменений в саму конфигурацию, но это если в умелых руках.
А если нет? Ну так любой инструмент несет в себе такие же опасности: молотком можно забить гвоздь, а можно отбить пальцы.
Так что не так с расширениями? У расширений есть три типа назначения, про них в документации написано следующее:
Расширение с назначением Исправление предназначено для исправления ошибок в конфигурации. Поэтому оно применяется к конфигурации первым.
Затем применяется расширение с назначением Адаптация. Оно содержит доработки конфигурации при внедрении у конкретного заказчика.
И последним применяется расширение с назначением Дополнение. Оно содержит различные дополнительные сервисы, предназначенные для конфигурации (например, набор дополнительных отчетов).
Предполагается, что расширения с одинаковым назначением не должны «пересекаться» по функционалу и «мешать друг другу».
Ключевая фраза - мешать друг другу, с оговоркой – предполагается.
Что происходит на самом деле? Допустим у нас есть код какого-либо модуля и есть расширения, затрагивающие этот модуль. При запуске 1С берет исходный код модуля и применяет к нему расширение с назначением Изменение. Тем самым получает некоторый промежуточный код, который будет содержать исправления ошибок.
Потом к этому промежуточному коду применится расширение с типом адаптация и мы снова получим некий промежуточный код.
Затем уже к нему применится дополнение, и мы получим некоторый результирующий код.
Если расширений с одним назначением несколько, то они будут применяться в том порядке, в котором были добавлены в информационную базу и изменить этот порядок нельзя.
Если стараться следовать предложенным производителем стандартам, то система получается достаточно логичной. Если исправления ошибок конфликтуют с доработками или дополнениями, то у вас отключатся последние, а исправления применятся.
Если дополнение конфликтует с доработками (адаптация), то откажется работать дополнение. Но в жизни все может быть совсем по-другому. И дополнение с типом адаптация, добавленное первым, может спокойно при обновлении сломать ваши доработки.
Но чаще всего мы получаем странные глюки и ошибки буквально из неоткуда и по абсолютно непонятной причине.
А почему? А потому что раньше процесс изменения конфигурации был делом достаточно сложным и затратным: нужно было найти программиста, заплатить ему денег, снять конфигурацию с замочка, что удорожало ее поддержку и сопровождение… Поэтому чаще всего обходились сравнительно безобидными внешними отчетами и обработками.
Если же решались на доработку, то занимался этим какой-никакой, но специалист.
Зато теперь – полная свобода самовыражения. Пошли на Инфостарт, накачали расширений и давай «прокачивать» базу. И никаких программистов не надо. Даже конфигуратор открывать не придется.
И, как часто бывает, прокачивая какое-то одно направление мы с большой вероятностью столкнемся с тем, что применяемые расширения где-то пересекаются и начинают мешать друг другу. Причем этот процесс может быть абсолютно непредсказуемым.
Например, в базе А набор расширений может работать без ошибок, а в точно такой же базе Б – глючить напропалую. А почему? А потому что расширения добавлены в разном порядке. Следовательно итоговый код будет разным, с разными последствиями.
Как быть? Да никак, расширения стали нормой жизни, их будут качать и ставить. Но всегда надо иметь это ввиду и при непонятном поведении базы сразу проверять список расширений.
Ну и стараться все-таки, хотя бы по диагонали, смотреть в код расширений, прежде чем их ставить и контролировать их пересечение. Не умеете сами – позовите специалиста.
А что, так можно? Не только можно, но и с завидной регулярностью случается. И называется это - расширения.
Вообще, расширения – это удобный механизм доработки конфигурации или исправления ошибок без внесения изменений в саму конфигурацию, но это если в умелых руках.
А если нет? Ну так любой инструмент несет в себе такие же опасности: молотком можно забить гвоздь, а можно отбить пальцы.
Так что не так с расширениями? У расширений есть три типа назначения, про них в документации написано следующее:
Расширение с назначением Исправление предназначено для исправления ошибок в конфигурации. Поэтому оно применяется к конфигурации первым.
Затем применяется расширение с назначением Адаптация. Оно содержит доработки конфигурации при внедрении у конкретного заказчика.
И последним применяется расширение с назначением Дополнение. Оно содержит различные дополнительные сервисы, предназначенные для конфигурации (например, набор дополнительных отчетов).
Предполагается, что расширения с одинаковым назначением не должны «пересекаться» по функционалу и «мешать друг другу».
Ключевая фраза - мешать друг другу, с оговоркой – предполагается.
Что происходит на самом деле? Допустим у нас есть код какого-либо модуля и есть расширения, затрагивающие этот модуль. При запуске 1С берет исходный код модуля и применяет к нему расширение с назначением Изменение. Тем самым получает некоторый промежуточный код, который будет содержать исправления ошибок.
Потом к этому промежуточному коду применится расширение с типом адаптация и мы снова получим некий промежуточный код.
Затем уже к нему применится дополнение, и мы получим некоторый результирующий код.
Если расширений с одним назначением несколько, то они будут применяться в том порядке, в котором были добавлены в информационную базу и изменить этот порядок нельзя.
Если стараться следовать предложенным производителем стандартам, то система получается достаточно логичной. Если исправления ошибок конфликтуют с доработками или дополнениями, то у вас отключатся последние, а исправления применятся.
Если дополнение конфликтует с доработками (адаптация), то откажется работать дополнение. Но в жизни все может быть совсем по-другому. И дополнение с типом адаптация, добавленное первым, может спокойно при обновлении сломать ваши доработки.
Но чаще всего мы получаем странные глюки и ошибки буквально из неоткуда и по абсолютно непонятной причине.
А почему? А потому что раньше процесс изменения конфигурации был делом достаточно сложным и затратным: нужно было найти программиста, заплатить ему денег, снять конфигурацию с замочка, что удорожало ее поддержку и сопровождение… Поэтому чаще всего обходились сравнительно безобидными внешними отчетами и обработками.
Если же решались на доработку, то занимался этим какой-никакой, но специалист.
Зато теперь – полная свобода самовыражения. Пошли на Инфостарт, накачали расширений и давай «прокачивать» базу. И никаких программистов не надо. Даже конфигуратор открывать не придется.
И, как часто бывает, прокачивая какое-то одно направление мы с большой вероятностью столкнемся с тем, что применяемые расширения где-то пересекаются и начинают мешать друг другу. Причем этот процесс может быть абсолютно непредсказуемым.
Например, в базе А набор расширений может работать без ошибок, а в точно такой же базе Б – глючить напропалую. А почему? А потому что расширения добавлены в разном порядке. Следовательно итоговый код будет разным, с разными последствиями.
Как быть? Да никак, расширения стали нормой жизни, их будут качать и ставить. Но всегда надо иметь это ввиду и при непонятном поведении базы сразу проверять список расширений.
Ну и стараться все-таки, хотя бы по диагонали, смотреть в код расширений, прежде чем их ставить и контролировать их пересечение. Не умеете сами – позовите специалиста.
👍15👎1👌1
Termshot – скриншоты для вашего терминала
Скриншоты? В терминале? Да ну, зачем это нужно… Так думают многие администраторы, я тоже сначала так подумал. Действительно, зачем еще один инструмент, тем более что я всегда могу снять скриншот терминала привычными способами.
Но те, кто много работает со скриншотами знает, что добиться нормального качества изображения на скриншоте не всегда получается с первого раза и то, что хорошо выглядит на экране может просто отвратительно выглядеть на бумаге.
Да и качество вывода во многих терминалах откровенно хромает. А различные цветовые схемы добавляют лишних забот. В лучшем случае ваша документация или статья будут выглядеть разнородно, в худшем вы можете получить проблемы при масштабировании или конвертации картинки.
Поэтому, скажем честно, без предварительной подготовки получить качественные скриншоты терминала затруднительно. Как минимум вам придется настроить размер шрифта, сам шрифт, цветовую схему и т.д.
Видимо автору данной утилиты все это сильно надоело, и он решил вопрос кардинальным образом. Ведь что есть поток вывода терминала? Это текст, а следовательно его можно захватить и обработать как нам нужно.
Утилита termshot представляет собой единственный бинарный файл, написанный на Go, и распространяется по лицензии MIT, скачать ее можно с официальной страницы автора на GitHub: https://github.com/homeport/termshot
Применять ее тоже просто:
И вы получите в своей домашней папке файл out.png с выводом команды в едином стиле и с размером изображения 2K вне зависимости от настроек вашего терминала, разницу можно посмотреть на скриншотах к заметке.
Конечно, такой скриншот совсем другое дело, его можно смело обрабатывать, масштабировать и т.д. и т.п. не боясь потерять в качестве, а также он отлично читается в любом варианте, что в электронном, что в печатном.
Также утилитой удобно захватывать большой вывод в несколько экранов, все попадет в один файл, который затем можете уже порезать как вам потребуется.
Если хотите добавить на скриншот саму команду, а не только ее вывод – используйте ключ -с:
Если нужно выполнить более одной команды через конвейер, то вам поможет следующая конструкция:
Чтобы указать имя файла изображения можно использовать ключ -f:
Все ключи можно быстро посмотреть в режиме справки:
Еще одной приятной возможностью утилиты является запуск отдельной сессии терминала с захватом всего что будет в ней происходить. Для этого запустите:
На первый взгляд ничего не произойдет, но на самом деле вы открыли отдельную сессию, весь вывод которой пойдет на скришнот. Мы можем запустить несколько команд, а потом завершить сессию командой
После чего утилита создаст нам скриншот, на который попадет все то, что мы видели на экране.
Как видим, утилита предельно проста, но очень полезна тем, кто занимается написанием статей или составлением документации. Теперь не нужно переживать за качество скриншотов, оно всегда будет отличным.
Скриншоты? В терминале? Да ну, зачем это нужно… Так думают многие администраторы, я тоже сначала так подумал. Действительно, зачем еще один инструмент, тем более что я всегда могу снять скриншот терминала привычными способами.
Но те, кто много работает со скриншотами знает, что добиться нормального качества изображения на скриншоте не всегда получается с первого раза и то, что хорошо выглядит на экране может просто отвратительно выглядеть на бумаге.
Да и качество вывода во многих терминалах откровенно хромает. А различные цветовые схемы добавляют лишних забот. В лучшем случае ваша документация или статья будут выглядеть разнородно, в худшем вы можете получить проблемы при масштабировании или конвертации картинки.
Поэтому, скажем честно, без предварительной подготовки получить качественные скриншоты терминала затруднительно. Как минимум вам придется настроить размер шрифта, сам шрифт, цветовую схему и т.д.
Видимо автору данной утилиты все это сильно надоело, и он решил вопрос кардинальным образом. Ведь что есть поток вывода терминала? Это текст, а следовательно его можно захватить и обработать как нам нужно.
Утилита termshot представляет собой единственный бинарный файл, написанный на Go, и распространяется по лицензии MIT, скачать ее можно с официальной страницы автора на GitHub: https://github.com/homeport/termshot
Применять ее тоже просто:
termshot hostnamectl
И вы получите в своей домашней папке файл out.png с выводом команды в едином стиле и с размером изображения 2K вне зависимости от настроек вашего терминала, разницу можно посмотреть на скриншотах к заметке.
Конечно, такой скриншот совсем другое дело, его можно смело обрабатывать, масштабировать и т.д. и т.п. не боясь потерять в качестве, а также он отлично читается в любом варианте, что в электронном, что в печатном.
Также утилитой удобно захватывать большой вывод в несколько экранов, все попадет в один файл, который затем можете уже порезать как вам потребуется.
Если хотите добавить на скриншот саму команду, а не только ее вывод – используйте ключ -с:
termshot -с hostnamectl
Если нужно выполнить более одной команды через конвейер, то вам поможет следующая конструкция:
termshot -- "dpkg -l | grep gimp"
Чтобы указать имя файла изображения можно использовать ключ -f:
termshot -- "dpkg -l | grep gimp" -f /home/user/doc123/grep2.png
Все ключи можно быстро посмотреть в режиме справки:
termshot -h
Еще одной приятной возможностью утилиты является запуск отдельной сессии терминала с захватом всего что будет в ней происходить. Для этого запустите:
termshot /bin/bash
На первый взгляд ничего не произойдет, но на самом деле вы открыли отдельную сессию, весь вывод которой пойдет на скришнот. Мы можем запустить несколько команд, а потом завершить сессию командой
exit
После чего утилита создаст нам скриншот, на который попадет все то, что мы видели на экране.
Как видим, утилита предельно проста, но очень полезна тем, кто занимается написанием статей или составлением документации. Теперь не нужно переживать за качество скриншотов, оно всегда будет отличным.
👍16❤1🔥1👀1
Влияние антивирусов на производительность 1С
После выхода нашего материала:
🔹 Почему тормозит 1С. Файловый режим и Microsoft Defender
Нас неоднократно просили проверить влияние других антивирусов на производительность 1С:Предприятие.
Наконец мы нашли время и провели небольшое исследование.
Тестовый стенд:
▫️Windows 11 24H2
▫️1С:Предприятие 8.3.27.1786
▫️Тест Гилева 2.1.1.38
В тестировании принимали участие:
🔸 Windows Defender, антивирус по умолчанию, весьма широко распространен по принципу: уже есть, работает, есть не просит.
🔸 Kaspersky Standard – ведущий в РФ и очень популярный производитель антивирусного ПО, бесплатная версия может быть установлена на ПК по умолчанию
🔸 Dr.Web Security Space – еще один лидер рынка отечественных антивирусов, имеет свою армию поклонников.
🔸 PRO32 – импортозамещенный NOD32, продолжает пользоваться популярностью в определенных кругах, по степени распространения примерно как Dr.Web.
🔸 360 Total Security – бесплатный продукт от наших китайских товарищей, весьма распространен среди любителей бесплатных антивирусов.
👉 В результате нами были получены следующие результаты:
▫️Без антивируса 100% (0%)
▫️Kaspersky Standard 84% (-16%)
▫️Dr.Web Security Space 87% (-13%)
▫️PRO 32 89% (-11%)
▫️360 Total Security (-6%)
▫️Windows Defender 35% (-65%)
👆 Большинство именитых антивирусов показало довольно небольшую просадку производительности 11-16%, что, конечно, неприятно, но не сильно критично.
💪 Лучший результат оказался у 360 Total Security – всего минус 6%, про эффективность данного антивируса говорить ничего не будем, так как не располагаем объективными данными.
🤦♀️ Ну и Windows Defender – это просто катастрофа, падение производительности в три раза. Поэтому при его использовании обязательно вносите 1С в исключение, готовый скрипт можете взять в нашей статье.
После выхода нашего материала:
🔹 Почему тормозит 1С. Файловый режим и Microsoft Defender
Нас неоднократно просили проверить влияние других антивирусов на производительность 1С:Предприятие.
Наконец мы нашли время и провели небольшое исследование.
Тестовый стенд:
▫️Windows 11 24H2
▫️1С:Предприятие 8.3.27.1786
▫️Тест Гилева 2.1.1.38
В тестировании принимали участие:
🔸 Windows Defender, антивирус по умолчанию, весьма широко распространен по принципу: уже есть, работает, есть не просит.
🔸 Kaspersky Standard – ведущий в РФ и очень популярный производитель антивирусного ПО, бесплатная версия может быть установлена на ПК по умолчанию
🔸 Dr.Web Security Space – еще один лидер рынка отечественных антивирусов, имеет свою армию поклонников.
🔸 PRO32 – импортозамещенный NOD32, продолжает пользоваться популярностью в определенных кругах, по степени распространения примерно как Dr.Web.
🔸 360 Total Security – бесплатный продукт от наших китайских товарищей, весьма распространен среди любителей бесплатных антивирусов.
👉 В результате нами были получены следующие результаты:
▫️Без антивируса 100% (0%)
▫️Kaspersky Standard 84% (-16%)
▫️Dr.Web Security Space 87% (-13%)
▫️PRO 32 89% (-11%)
▫️360 Total Security (-6%)
▫️Windows Defender 35% (-65%)
👆 Большинство именитых антивирусов показало довольно небольшую просадку производительности 11-16%, что, конечно, неприятно, но не сильно критично.
💪 Лучший результат оказался у 360 Total Security – всего минус 6%, про эффективность данного антивируса говорить ничего не будем, так как не располагаем объективными данными.
🤦♀️ Ну и Windows Defender – это просто катастрофа, падение производительности в три раза. Поэтому при его использовании обязательно вносите 1С в исключение, готовый скрипт можете взять в нашей статье.
👍30❤3🤝1
Проблема, как и статья не новая, но регулярно возникают вопросы.
Не включается сетевое обнаружение в Windows 10/11 и Windows Server
Современные ОС предусматривают современные подходы ко многим привычным вещам, отказываясь от многих устаревших технологий.
С одной стороны это правильно, с другой - может вызвать и вызывает проблемы в переходный период. Поэтому системный администратор всегда должен интересоваться всеми нововведениями используемых систем, а также уметь применять их на практике.
Здоровый консерватизм - это хорошо, но он не должен препятствовать прогрессу. Сегодня мы поговорим об одной часто встречающейся проблеме - не включается сетевое обнаружение в последних версиях Windows 10/11 и Windows Server.
✅ https://interface31.ru/post/ne-vklyuchaetsya-setevoe-obnaruzhenie-v-windows-10-windows-server/
Не включается сетевое обнаружение в Windows 10/11 и Windows Server
Современные ОС предусматривают современные подходы ко многим привычным вещам, отказываясь от многих устаревших технологий.
С одной стороны это правильно, с другой - может вызвать и вызывает проблемы в переходный период. Поэтому системный администратор всегда должен интересоваться всеми нововведениями используемых систем, а также уметь применять их на практике.
Здоровый консерватизм - это хорошо, но он не должен препятствовать прогрессу. Сегодня мы поговорим об одной часто встречающейся проблеме - не включается сетевое обнаружение в последних версиях Windows 10/11 и Windows Server.
✅ https://interface31.ru/post/ne-vklyuchaetsya-setevoe-obnaruzhenie-v-windows-10-windows-server/
👍7🤔2👀1
V2V миграция при помощи Vinchin Backup & Recovery
Виртуализация сегодня – норма жизни, даже в среде малого бизнеса. Но за последние несколько лет рынок виртуализации серьезно изменился. Прошлые лидеры отправились на покой, а их место заняли новые, молодые системы.
Так для последнего бесплатного Hyper-V Server 2019 поддержка заканчивается в январе 2029 года, а новый владелец VMware – Broadcom полностью закрутил гайки переведя всех на платную подписную модель с совершенно не гуманным ценником.
В итоге вопрос из стадии «куда пойти податься» переходит в стадию «а куда мы можем быстро мигрировать».
Потому как в эпоху ИИ, которая находит уязвимости пачками и также быстро клепает к ним эксплойты вопрос взлома неподдерживаемой системы остается только вопросом времени.
Классическая схема: конвертируем диск – создаем новую VM – запускаем, проверяем, тестируем подходит только если у вас виртуальных машин штучное количество. В противном случае это будет неконтролируемый растянутый по времени процесс, все время которого бизнес будет находиться в подвешенном состоянии.
Почему в подвешенном? Так сломают нас или не сломают, и какие новые косяки вылезут при переезде очередной виртуальной машины? Все это время работа нарушается, прибыль падает, руководство нервничает.
Лучше быстро перенести все за один раз, а потом уже решать вопросы в рабочем порядке. И тут нужны совсем другие инструменты.
И тут на помощь нам приходят наши китайские друзья со своим Vinchin Backup & Recovery, про него мы уже писали:
✅ Vinchin Backup & Recovery - универсальная система резервного копирования уровня предприятия
Да, это коммерческая система, но бизнес говорит на языке денег, если инструмент стоит дешевле, чем возможный простой или упущенная прибыль – деньги на него найдутся.
Так вот, данный продукт умеет в кроссплатформенное восстановление виртуальных машин, а список поддерживаемых платформ виртуализации там куда как велик, включая и все отечественные системы.
Сам процесс очень прост: подключаем платформу А, делаем резервные копии нужных виртуалок. Подключаем платформу Б и делаем туда кроссплатформенное восстановление.
Да, восстановление имеет ряд особенностей, а частности вы с большой долей вероятности получите эмулированное, а не паравиртуализированное виртуальное железо. От этого страдает производительность, но это безопасно.
Любая современная система знает, что такое сетевая карта E1000 или чипсет i440, т.е. ваши виртуалки гарантированно запустятся и будут работать. А дальше – тюнингуйте в порядке приоритета.
Да и будем честны, большинство виртуальных машин даже параметры эмулируемого железа не утилизируют, поэтому особой проблемы не будет.
В качестве теста мы выполнили миграцию с Hyper-V Server 2019 на Proxmox VE 9 и перенесли виртуальные машины как первого, так и второго поколения.
✅ Читать подробнее: Vinchin Backup & Recovery - V2V миграция из Hyper-V в Proxmox
Виртуализация сегодня – норма жизни, даже в среде малого бизнеса. Но за последние несколько лет рынок виртуализации серьезно изменился. Прошлые лидеры отправились на покой, а их место заняли новые, молодые системы.
Так для последнего бесплатного Hyper-V Server 2019 поддержка заканчивается в январе 2029 года, а новый владелец VMware – Broadcom полностью закрутил гайки переведя всех на платную подписную модель с совершенно не гуманным ценником.
В итоге вопрос из стадии «куда пойти податься» переходит в стадию «а куда мы можем быстро мигрировать».
Потому как в эпоху ИИ, которая находит уязвимости пачками и также быстро клепает к ним эксплойты вопрос взлома неподдерживаемой системы остается только вопросом времени.
Классическая схема: конвертируем диск – создаем новую VM – запускаем, проверяем, тестируем подходит только если у вас виртуальных машин штучное количество. В противном случае это будет неконтролируемый растянутый по времени процесс, все время которого бизнес будет находиться в подвешенном состоянии.
Почему в подвешенном? Так сломают нас или не сломают, и какие новые косяки вылезут при переезде очередной виртуальной машины? Все это время работа нарушается, прибыль падает, руководство нервничает.
Лучше быстро перенести все за один раз, а потом уже решать вопросы в рабочем порядке. И тут нужны совсем другие инструменты.
И тут на помощь нам приходят наши китайские друзья со своим Vinchin Backup & Recovery, про него мы уже писали:
✅ Vinchin Backup & Recovery - универсальная система резервного копирования уровня предприятия
Да, это коммерческая система, но бизнес говорит на языке денег, если инструмент стоит дешевле, чем возможный простой или упущенная прибыль – деньги на него найдутся.
Так вот, данный продукт умеет в кроссплатформенное восстановление виртуальных машин, а список поддерживаемых платформ виртуализации там куда как велик, включая и все отечественные системы.
Сам процесс очень прост: подключаем платформу А, делаем резервные копии нужных виртуалок. Подключаем платформу Б и делаем туда кроссплатформенное восстановление.
Да, восстановление имеет ряд особенностей, а частности вы с большой долей вероятности получите эмулированное, а не паравиртуализированное виртуальное железо. От этого страдает производительность, но это безопасно.
Любая современная система знает, что такое сетевая карта E1000 или чипсет i440, т.е. ваши виртуалки гарантированно запустятся и будут работать. А дальше – тюнингуйте в порядке приоритета.
Да и будем честны, большинство виртуальных машин даже параметры эмулируемого железа не утилизируют, поэтому особой проблемы не будет.
В качестве теста мы выполнили миграцию с Hyper-V Server 2019 на Proxmox VE 9 и перенесли виртуальные машины как первого, так и второго поколения.
✅ Читать подробнее: Vinchin Backup & Recovery - V2V миграция из Hyper-V в Proxmox
👍20❤2🍌2
Без лишнего шума и пыли вышла Aspia 3.0. Ключевые изменения в выжимке ниже:
1️⃣ Архитектура, платформы и безопасность (Релиз 3.0.15)
🔹Переход на Qt 6 и кроссплатформенность: компонент Host теперь работает на Linux (X11/Wayland), macOS и Android (ранее был доступен только на Windows). Появился Client для Android.
🔹 Шифрование и безопасность: соединения по умолчанию защищены AES-256 GCM. Для пользователей Router обязательна двухфакторная аутентификация (TOTP).
Адресная книга шифруется мастер-паролем, а службы Router и Relay переведены на запуск от непривилегированных учетных записей.
🔹 Сетевой стек: добавлены прямые UDP-соединения (UDP hole punching, UPnP, NAT-PMP, PCP), встроенный STUN-сервер и раздельные порты для хостов, клиентов и релея.
🔹 Видео и сессии: внедрен кодек H.264 с аппаратным ускорением, адаптивный выбор качества, поддержка нового типа сессий Terminal, расширенный буфер обмена (файлы, изображения, HTML) и вкладки в интерфейсе клиента.
🔹 Упразднение Console: отдельная консоль удалена, ее функции интегрированы прямо в Client.
2️⃣ Развитие Host и портативный доступ (3.0.16 — 3.0.22)
🔹 Портативный Quick Support (3.0.22): для Windows добавлена версия хоста, работающая без установки. Ее можно экспортировать прямо из настроек с уже зашитой конфигурацией.
🔹 Экспорт преднастроенных инсталляторов (3.0.21): возможность сгенерировать готовый установочный пакет под развертывание на других ПК.
🔹 Мобильный хост на Android: Добавлен полноценный фоновый режим с уведомлением: хост остается на связи при заблокированном или выключенном экране (3.0.21, 3.0.22).
Появилась опция автоподтверждения захвата экрана.
Плавающая кнопка активной сессии теперь отображается поверх настроек системы и скрывается на экране блокировки.
🔹 Стабильность графики и системные фиксы: исправлены сбои аппаратного кодирования H.264 на старых GPU Intel, решены проблемы черного экрана в Wayland (GNOME) и захвата KMS на multi-GPU системах в Linux.
3️⃣ Улучшения Client и администрирования
🔹 Быстрое подключение (Quick Connect / F8): разовое подключение по адресу или роутерному ID без обязательного добавления в базу данных (3.0.20).
🔹 Управление парком машин через роутер: Введено разделение на временные и постоянные хосты с процедурой подтверждения (3.0.15).
Добавлено массовое одобрение временных хостов и пакетное перемещение по группам через Drag-and-Drop (3.0.20).
Quick Support-хосты помечаются отдельно и не могут быть одобрены как постоянные (3.0.22).
🔹 Удобство авторизации: возможность автоматической разблокировки мастер-пароля базы при старте через системное хранилище ключей Windows/macOS (3.0.20).
🔹 Собственные серверы обновлений: добавлена поддержка указания кастомного сервера обновлений и публичного ключа подписи пакетов (3.0.21).
1️⃣ Архитектура, платформы и безопасность (Релиз 3.0.15)
🔹Переход на Qt 6 и кроссплатформенность: компонент Host теперь работает на Linux (X11/Wayland), macOS и Android (ранее был доступен только на Windows). Появился Client для Android.
🔹 Шифрование и безопасность: соединения по умолчанию защищены AES-256 GCM. Для пользователей Router обязательна двухфакторная аутентификация (TOTP).
Адресная книга шифруется мастер-паролем, а службы Router и Relay переведены на запуск от непривилегированных учетных записей.
🔹 Сетевой стек: добавлены прямые UDP-соединения (UDP hole punching, UPnP, NAT-PMP, PCP), встроенный STUN-сервер и раздельные порты для хостов, клиентов и релея.
🔹 Видео и сессии: внедрен кодек H.264 с аппаратным ускорением, адаптивный выбор качества, поддержка нового типа сессий Terminal, расширенный буфер обмена (файлы, изображения, HTML) и вкладки в интерфейсе клиента.
🔹 Упразднение Console: отдельная консоль удалена, ее функции интегрированы прямо в Client.
2️⃣ Развитие Host и портативный доступ (3.0.16 — 3.0.22)
🔹 Портативный Quick Support (3.0.22): для Windows добавлена версия хоста, работающая без установки. Ее можно экспортировать прямо из настроек с уже зашитой конфигурацией.
🔹 Экспорт преднастроенных инсталляторов (3.0.21): возможность сгенерировать готовый установочный пакет под развертывание на других ПК.
🔹 Мобильный хост на Android: Добавлен полноценный фоновый режим с уведомлением: хост остается на связи при заблокированном или выключенном экране (3.0.21, 3.0.22).
Появилась опция автоподтверждения захвата экрана.
Плавающая кнопка активной сессии теперь отображается поверх настроек системы и скрывается на экране блокировки.
🔹 Стабильность графики и системные фиксы: исправлены сбои аппаратного кодирования H.264 на старых GPU Intel, решены проблемы черного экрана в Wayland (GNOME) и захвата KMS на multi-GPU системах в Linux.
3️⃣ Улучшения Client и администрирования
🔹 Быстрое подключение (Quick Connect / F8): разовое подключение по адресу или роутерному ID без обязательного добавления в базу данных (3.0.20).
🔹 Управление парком машин через роутер: Введено разделение на временные и постоянные хосты с процедурой подтверждения (3.0.15).
Добавлено массовое одобрение временных хостов и пакетное перемещение по группам через Drag-and-Drop (3.0.20).
Quick Support-хосты помечаются отдельно и не могут быть одобрены как постоянные (3.0.22).
🔹 Удобство авторизации: возможность автоматической разблокировки мастер-пароля базы при старте через системное хранилище ключей Windows/macOS (3.0.20).
🔹 Собственные серверы обновлений: добавлена поддержка указания кастомного сервера обновлений и публичного ключа подписи пакетов (3.0.21).
🔥20👍15❤4🤔1
До первого сервис-пака не ставить
На фоне некоторых коллег, которые бегут ставить свежий софт сразу после его выпуска, невзирая на то, что разработчик за неделю выпустил семь минорных релизов вспоминаются старые добрые времена, когда интернет былпо талонам по карточкам с почасовой тарификацией и никакой мгновенной доставки софта быть не могло.
В те годы софт распространялся на физических носителях: дискеты, а позже и компакт-диски. И все косяки, доработки и прочее копились большой массой чтобы быть исправленными или добавленными в большом обновлении, которое называлось сервис-пак.
Выпускали их, когда быстро, когда не очень. В зависимости от критичности выявленных проблем и ожиданий пользователей.
Так для NT 4 было выпущено целых шесть сервис-паков, не считая Service Pack 6a и Post Service Pack 6a Security Rollup. И самая жесть состояла в том, что, поставив чистую NT 4 с лицензионного носителя вы должны были все эти обновления (числом 8 штук) накатить последовательно.
Для Windows 2000 было выпущено четыре сервис-пака и один Update Rollup для закрытия выявленных уязвимостей, для Windows XP сервис-паков было три. Потом этот процесс пошел на убыль.
Windows Vista получила всего два сервис-пака, а Windows 7 – один. Но к этому времени широкополосный интернет стал нормой жизни и все изменения и исправления стало можно свободно распространять через Windows Update.
Времена прошли, но привычки остались. Любой администратор, заставший те времена помнит, что установка сервис-пака часто была сродни обновлению системы. Менялось многое, добавлялись новые функции, исправлялись ошибки.
Поэтому и возникло правило: до первого сервис-пака в прод не ставим. Пусть там все оттестируют, исправят, а тогда уже и мы подтянемся.
А мотивация была проста – с косяками нам придется жить и жить долго, пока тот самый сервис-пак не выпустят. И зачем это надо? Совсем не надо! Поэтому посидим на старой версии, пока на новую все исправления не выпустят.
На фоне некоторых коллег, которые бегут ставить свежий софт сразу после его выпуска, невзирая на то, что разработчик за неделю выпустил семь минорных релизов вспоминаются старые добрые времена, когда интернет был
В те годы софт распространялся на физических носителях: дискеты, а позже и компакт-диски. И все косяки, доработки и прочее копились большой массой чтобы быть исправленными или добавленными в большом обновлении, которое называлось сервис-пак.
Выпускали их, когда быстро, когда не очень. В зависимости от критичности выявленных проблем и ожиданий пользователей.
Так для NT 4 было выпущено целых шесть сервис-паков, не считая Service Pack 6a и Post Service Pack 6a Security Rollup. И самая жесть состояла в том, что, поставив чистую NT 4 с лицензионного носителя вы должны были все эти обновления (числом 8 штук) накатить последовательно.
Для Windows 2000 было выпущено четыре сервис-пака и один Update Rollup для закрытия выявленных уязвимостей, для Windows XP сервис-паков было три. Потом этот процесс пошел на убыль.
Windows Vista получила всего два сервис-пака, а Windows 7 – один. Но к этому времени широкополосный интернет стал нормой жизни и все изменения и исправления стало можно свободно распространять через Windows Update.
Времена прошли, но привычки остались. Любой администратор, заставший те времена помнит, что установка сервис-пака часто была сродни обновлению системы. Менялось многое, добавлялись новые функции, исправлялись ошибки.
Поэтому и возникло правило: до первого сервис-пака в прод не ставим. Пусть там все оттестируют, исправят, а тогда уже и мы подтянемся.
А мотивация была проста – с косяками нам придется жить и жить долго, пока тот самый сервис-пак не выпустят. И зачем это надо? Совсем не надо! Поэтому посидим на старой версии, пока на новую все исправления не выпустят.
👍23❤4🥱2
Автоматический перезапуск Aspia в Docker
Не так давно мы рассказывали, как запустить популярную систему удаленного доступа Aspia в Docker - https://t.me/interface31/6296/
И вот некоторое время назад пользователи начали сталкиваться с проблемами, перестает работать ретранслятор, но сам контейнер остается рабочим и Docker его не перезапускает.
С чем связаны падения ретранслятора пока непонятно, но по всем признакам проблема внешняя, так как на совершенно разных установках ретрансляторы падают практически одновременно.
Что делать? Перезапускать контейнеры руками? Но это не наш метод, да и где взять столько рук. Поэтому обратимся к средствам автоматизации, существует проект autoheal, который позволяет следить за здоровьем контейнера и перезапускать его, если что-то пошло не так.
Откроем docker-compose.yml в папке проекта Aspia и приведем его к следующему виду:
Мы добавили метку, чтобы autoheal мог контролировать данный контейнер и добавили проверки процессов роутера или ретранслятора, если хоть один из них упал, то после двух неудачных проверок контейнер перейдет в статус unhealthy.
Теперь создадим отдельную директорию:
И разместим в ней следующий docker-compose.yml:
В данном случае мы отслеживаем только контейнеры с меткой autoheal=true и перезапускаем их с задержкой в 2 секунды.
Запускаем все это добро и радуемся жизни, схема рабочая, проверена на практике.
Но есть один неочевидный момент. По умолчанию autoheal запускается с опцией:
Это означает, что он будет мониторить даже незапущенные контейнеры и автоматически будет поднимать их, даже если вы руками их остановите. Чтобы избежать этой ситуации добавьте в секцию environment опцию:
Подобным образом мы можем отслеживать далеко не только Aspia, но и вообще любой сервис по любому нужному нам показателю, который не приводит к аварийному завершению контейнера, но влияет на его пользовательские характеристики. Главное – правильно написать условия проверки.
Не так давно мы рассказывали, как запустить популярную систему удаленного доступа Aspia в Docker - https://t.me/interface31/6296/
И вот некоторое время назад пользователи начали сталкиваться с проблемами, перестает работать ретранслятор, но сам контейнер остается рабочим и Docker его не перезапускает.
С чем связаны падения ретранслятора пока непонятно, но по всем признакам проблема внешняя, так как на совершенно разных установках ретрансляторы падают практически одновременно.
Что делать? Перезапускать контейнеры руками? Но это не наш метод, да и где взять столько рук. Поэтому обратимся к средствам автоматизации, существует проект autoheal, который позволяет следить за здоровьем контейнера и перезапускать его, если что-то пошло не так.
Откроем docker-compose.yml в папке проекта Aspia и приведем его к следующему виду:
services:
aspia-server:
image: paprikkafox/aspia-server:latest
container_name: aspia-server
hostname: aspia.example.com
environment:
- EXTERNAL_IP=203.0.113.6
ports:
- "8070:8070"
- "8060:8060"
volumes:
- ./data/database:/var/lib/aspia:rw
- ./data/config:/etc/aspia:rw
restart: always
labels:
- "autoheal=true"
healthcheck:
test: ["CMD-SHELL", "pidof aspia_relay && pidof aspia_router || exit 1"]
interval: 10s
timeout: 5s
retries: 2
start_period: 15s
Мы добавили метку, чтобы autoheal мог контролировать данный контейнер и добавили проверки процессов роутера или ретранслятора, если хоть один из них упал, то после двух неудачных проверок контейнер перейдет в статус unhealthy.
Теперь создадим отдельную директорию:
mkdir /opt/autohealИ разместим в ней следующий docker-compose.yml:
services:
autoheal:
image: willfarrell/autoheal:latest
container_name: autoheal
restart: always
environment:
- TZ=Europe/Moscow
- AUTOHEAL_CONTAINER_LABEL=autoheal
- AUTOHEAL_DELAY=2
volumes:
- /var/run/docker.sock:/var/run/docker.sock
В данном случае мы отслеживаем только контейнеры с меткой autoheal=true и перезапускаем их с задержкой в 2 секунды.
Запускаем все это добро и радуемся жизни, схема рабочая, проверена на практике.
Но есть один неочевидный момент. По умолчанию autoheal запускается с опцией:
AUTOHEAL_ONLY_MONITOR_RUNNING=falseЭто означает, что он будет мониторить даже незапущенные контейнеры и автоматически будет поднимать их, даже если вы руками их остановите. Чтобы избежать этой ситуации добавьте в секцию environment опцию:
- AUTOHEAL_ONLY_MONITOR_RUNNING=trueПодобным образом мы можем отслеживать далеко не только Aspia, но и вообще любой сервис по любому нужному нам показателю, который не приводит к аварийному завершению контейнера, но влияет на его пользовательские характеристики. Главное – правильно написать условия проверки.
👍11🔥1
Как узнать все смонтированные файловые системы?
Раньше можно было сказать: загляните в
Можно использовать команду
Но есть способ лучше -
А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
Раньше можно было сказать: загляните в
/etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.Можно использовать команду
mount, но ее вывод недостаточно удобочитаем.Но есть способ лучше -
findmnt, данная команда выведет все смонтированные файловые системы в удобном древообразном виде.А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
--real. Чтобы получить больше информации воспользуйтесь ключом --help.👍26❤3🔥1