И снова про отечественные сертификаты
Очередное осеннее обострение началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры. Как пример - где автор слабо осознает, о чем пишет, но зато смело и обильно набрасывает на вентилятор.
Мол какое может быть доверие этим сертификатам и этому CA если… (там полный набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и, хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Очередное осеннее обострение началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры. Как пример - где автор слабо осознает, о чем пишет, но зато смело и обильно набрасывает на вентилятор.
Мол какое может быть доверие этим сертификатам и этому CA если… (там полный набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и, хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Key exchange ECDHE_RSA with P-256
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
👍36🤡10💯4⚡3🤔2
Вебинар: Поддержка ИТ-инфраструктуры: где бизнес теряет деньги и как их сохранить
🗓 27 ноября в 12:00 поговорим о том, как компании могут сократить расходы на поддержку ИТ-инфраструктуры, избежать скрытых затрат и обеспечить стабильность работы оборудования без поддержки западных вендоров.
Разберём, как с помощью аудита, российских инструментов инвентаризации и новых моделей сервисной поддержки добиться предсказуемого бюджета и надёжности инфраструктуры.
Кому будет полезен вебинар?
✔️Руководителям ИТ (CIO, CTO)
✔️Финансовым директорам и менеджерам (CFO)
✔️Собственникам и топ-менеджерам
✔️Тем, кто отвечает за работу и поддержку ИТ-инфраструктуры
Спикеры:
🔹 Пётр Старков, руководитель продуктового отдела, ADV-T
🔹 Максим Белый, руководитель партнёрской сети ПО «Инферит ИТМен» (ГК Softline)
Пяти компаниям мы предоставим по 5 сервисных кредитов ADV-T,
чтобы протестировать наш сервисный продукт прямо на своей инфраструктуре. Все детали — на вебинаре.
Участие бесплатное — по предварительной регистрации
Зарегистрироваться 👈
#реклама
О рекламодателе
🗓 27 ноября в 12:00 поговорим о том, как компании могут сократить расходы на поддержку ИТ-инфраструктуры, избежать скрытых затрат и обеспечить стабильность работы оборудования без поддержки западных вендоров.
Разберём, как с помощью аудита, российских инструментов инвентаризации и новых моделей сервисной поддержки добиться предсказуемого бюджета и надёжности инфраструктуры.
Кому будет полезен вебинар?
✔️Руководителям ИТ (CIO, CTO)
✔️Финансовым директорам и менеджерам (CFO)
✔️Собственникам и топ-менеджерам
✔️Тем, кто отвечает за работу и поддержку ИТ-инфраструктуры
Спикеры:
🔹 Пётр Старков, руководитель продуктового отдела, ADV-T
🔹 Максим Белый, руководитель партнёрской сети ПО «Инферит ИТМен» (ГК Softline)
Пяти компаниям мы предоставим по 5 сервисных кредитов ADV-T,
чтобы протестировать наш сервисный продукт прямо на своей инфраструктуре. Все детали — на вебинаре.
Участие бесплатное — по предварительной регистрации
Зарегистрироваться 👈
#реклама
О рекламодателе
❤1
Как Certificate Transparency защищает пользователей и владельцев домена
Вся современная инфраструктура открытых ключей (PKI) стоится на доверии, это очень важный вопрос, потому что, выстраивая отношения доверия с удостоверяющим центром (CA) вы создаете область доверия, соглашаясь безусловно доверять всем его действиям.
На практике это заключается в установке корневого сертификата УЦ, после чего все подписанные им сертификаты также будут считаться доверенными. На практике все конечно немного сложнее, но общий принцип не меняется. Доверяя УЦ, мы доверяем всем выпущенным им сертификатам.
А что, если мы УЦ доверяем, но как бы не до конца, тем более что список корневых сертификатов основных удостоверяющих центров поставляется нам в составе системы. Тем более, что прецеденты уже были, когда удостоверяющие центры по ошибке или злонамеренно выпускали сертификаты без ведома владельца домена.
Такой сертификат позволяет, используя отношения доверия к выпустившему его УЦ совершить атаку человек посередине (MitM), т.е. перехватить, прочитать и/или изменить трафик к легальному ресурсу без ведома пользователя.
Чтобы избежать такого сценария и повысить уровень доверия, а также сделать более прозрачным процесс выдачи сертификатов была придумана и внедрена технология Certificate Transparency.
Certificate Transparency предполагает создание публичных CT-логов, в которых удостоверяющие центры регистрируют все выданные сертификаты. CT-логи построены на основе двоичных деревьев Меркла и допускают только добавление информации, изменить или удалить внесенную запись не получится.
Второй ключевой момент – СT-логи доступны для внешнего аудита и уже сегодня существуют независимые службы, которые занимаются их мониторингом. Это позволяет защитить владельца домена, которого такая служба будет своевременно уведомлять о действиях с его сертификатами.
Допустим, какой-то УЦ «по ошибке» выпустил сертификат без ведома владельца – настоящий владелец получит уведомление об этом и сможет своевременно начать разбирательство, а также уведомить контрагентов, что доверять такому-то сертификату не следует.
Но нас больше интересует каким образом Certificate Transparency защищает пользователей? При регистрации сертификата в CT-логе удостоверяющий центр получает специальную SCT-метку, которую включает в сертификат.
Современные браузеры проверяют не только отношения доверия к выпустившему сертификат УЦ, но и к наличию как минимум двух SCT-меток от разных CT-логов. Ряд браузеров имеет более строгие условия, так Google Chrome или Safari требуют, чтобы одним из CT-логов был лог Google или Apple.
Таким образом информация о любом сертификате добросовестного УЦ будет распространена по большому количеству CT-логов и будет доступна для внешнего аудита, что делает махинации с сертификатами быстро выявляемыми.
Кстати, УЦ Минцифры также поддерживает СТ-логи и выпускает сертификаты только с их поддержкой. С Минцифрой работают службы CT-логов самой Минцифры, Яндекса и ВК.
Может ли УЦ выпустить сертификат, не регистрируя его в CT-логах? Может, но браузеры тут-же пометят такой сертификат не доверенным. Для этого браузеру даже не нужно связываться со службами CT-логов, достаточно отсутствия SCT-меток.
Технически получить STC-метку не регистрируя сертификат в логе можно, для этого нужно знать алгоритм формирования метки и иметь доступ к закрытому ключу лога. И тот же УЦ может провернуть такой фокус со своим CT-логом. Но как быть с остальными?
Сговор? Тоже не поможет, CT-логи публичны и отсутствие там записи для метки будет достаточно быстро обнаружено, что сразу сделает лог недоверенным.
Таким образом Certificate Transparency предоставляет может и не идеальный, но достаточно эффективный инструмент контроля над добросовестностью участников отношений доверия и исходит из принципа – доверяй, но проверяй.
Теперь, даже имея доверительные отношения с УЦ вы можете проверить, что УЦ ведет деятельность прозрачно и регистрирует сертификаты в независимых CT-логах, а при желании можете спокойно ознакомиться с их содержимым.
Вся современная инфраструктура открытых ключей (PKI) стоится на доверии, это очень важный вопрос, потому что, выстраивая отношения доверия с удостоверяющим центром (CA) вы создаете область доверия, соглашаясь безусловно доверять всем его действиям.
На практике это заключается в установке корневого сертификата УЦ, после чего все подписанные им сертификаты также будут считаться доверенными. На практике все конечно немного сложнее, но общий принцип не меняется. Доверяя УЦ, мы доверяем всем выпущенным им сертификатам.
А что, если мы УЦ доверяем, но как бы не до конца, тем более что список корневых сертификатов основных удостоверяющих центров поставляется нам в составе системы. Тем более, что прецеденты уже были, когда удостоверяющие центры по ошибке или злонамеренно выпускали сертификаты без ведома владельца домена.
Такой сертификат позволяет, используя отношения доверия к выпустившему его УЦ совершить атаку человек посередине (MitM), т.е. перехватить, прочитать и/или изменить трафик к легальному ресурсу без ведома пользователя.
Чтобы избежать такого сценария и повысить уровень доверия, а также сделать более прозрачным процесс выдачи сертификатов была придумана и внедрена технология Certificate Transparency.
Certificate Transparency предполагает создание публичных CT-логов, в которых удостоверяющие центры регистрируют все выданные сертификаты. CT-логи построены на основе двоичных деревьев Меркла и допускают только добавление информации, изменить или удалить внесенную запись не получится.
Второй ключевой момент – СT-логи доступны для внешнего аудита и уже сегодня существуют независимые службы, которые занимаются их мониторингом. Это позволяет защитить владельца домена, которого такая служба будет своевременно уведомлять о действиях с его сертификатами.
Допустим, какой-то УЦ «по ошибке» выпустил сертификат без ведома владельца – настоящий владелец получит уведомление об этом и сможет своевременно начать разбирательство, а также уведомить контрагентов, что доверять такому-то сертификату не следует.
Но нас больше интересует каким образом Certificate Transparency защищает пользователей? При регистрации сертификата в CT-логе удостоверяющий центр получает специальную SCT-метку, которую включает в сертификат.
Современные браузеры проверяют не только отношения доверия к выпустившему сертификат УЦ, но и к наличию как минимум двух SCT-меток от разных CT-логов. Ряд браузеров имеет более строгие условия, так Google Chrome или Safari требуют, чтобы одним из CT-логов был лог Google или Apple.
Таким образом информация о любом сертификате добросовестного УЦ будет распространена по большому количеству CT-логов и будет доступна для внешнего аудита, что делает махинации с сертификатами быстро выявляемыми.
Кстати, УЦ Минцифры также поддерживает СТ-логи и выпускает сертификаты только с их поддержкой. С Минцифрой работают службы CT-логов самой Минцифры, Яндекса и ВК.
Может ли УЦ выпустить сертификат, не регистрируя его в CT-логах? Может, но браузеры тут-же пометят такой сертификат не доверенным. Для этого браузеру даже не нужно связываться со службами CT-логов, достаточно отсутствия SCT-меток.
Технически получить STC-метку не регистрируя сертификат в логе можно, для этого нужно знать алгоритм формирования метки и иметь доступ к закрытому ключу лога. И тот же УЦ может провернуть такой фокус со своим CT-логом. Но как быть с остальными?
Сговор? Тоже не поможет, CT-логи публичны и отсутствие там записи для метки будет достаточно быстро обнаружено, что сразу сделает лог недоверенным.
Таким образом Certificate Transparency предоставляет может и не идеальный, но достаточно эффективный инструмент контроля над добросовестностью участников отношений доверия и исходит из принципа – доверяй, но проверяй.
Теперь, даже имея доверительные отношения с УЦ вы можете проверить, что УЦ ведет деятельность прозрачно и регистрирует сертификаты в независимых CT-логах, а при желании можете спокойно ознакомиться с их содержимым.
👍24❤3🤡3🥱1
Серверный корпус 3U Procase EM306 ATX без бп
Корпус абсолютно новый, был куплен под один крупный проект лет 10 назад. Там он не подошел - не вошла по размеру материнская плата.
❗️ Важно! Корпус совместим с платами:
🔹 ATX (12"*9.6")
🔹MicroATX (9.6"*9.6")
🔹MiniITX (6.7"*6.7")
✅ https://procase.ru/em306/
В итоге был задвинут на дальнюю полку и забыт. Найден относительно недавно. Внешний вид на фото. В родной коробке, полный комплект.
👉 Отдаю в хорошие руки
💰 Начальная цена - 9 000 рублей (новый стоит в среднем 12 500 руб.)
Возможна оплата б/н с закрывающими документами, без НДС.
🚚 Отправка любой транспортной за счет получателя.
🤝 Разумный торг приветствуется!
Корпус абсолютно новый, был куплен под один крупный проект лет 10 назад. Там он не подошел - не вошла по размеру материнская плата.
❗️ Важно! Корпус совместим с платами:
🔹 ATX (12"*9.6")
🔹MicroATX (9.6"*9.6")
🔹MiniITX (6.7"*6.7")
✅ https://procase.ru/em306/
В итоге был задвинут на дальнюю полку и забыт. Найден относительно недавно. Внешний вид на фото. В родной коробке, полный комплект.
👉 Отдаю в хорошие руки
💰 Начальная цена - 9 000 рублей (новый стоит в среднем 12 500 руб.)
Возможна оплата б/н с закрывающими документами, без НДС.
🚚 Отправка любой транспортной за счет получателя.
🤝 Разумный торг приветствуется!
❤1
Не мышонок, не лягушка, а неведома зверушка
Как-то недавно, достаточно случайно набрел на датчики CO2 от Kitfort, невысокая цена в купе с прочими характеристиками заинтересовали. Но модель на проводе мне была не особо интересна, потому, как и так кругом в проводах, а вот аккумуляторная КТ-3345 – почему бы и нет.
Естественно, как серьезный измерительный прибор я этот девайс не рассматривал, но как первичную оценку качества воздуха, плюс термометр-гигрометр – почему бы и нет.
На первый взгляд – выглядит неплохо, плюс отечественный производитель и все такое.
Сказано – сделано, заказал. Привезли устройство утром, включил я его уже вечером и сильно удивился. Показания температуры и влажности были далеки от реальных. Ну влажность – ладно, лежал в закрытой коробке. Но температура? Он ведь часов десять пролежал в комнате.
А сравнить мне есть чем. В наличии датчики от Xiaomi, какие-то китайцы и механический термометр-гигрометр. Все примерно поют одну песню: температура плюс-минус градус, влажность плюс-минус 5-7%.
Данный девайс постоял с полчасика, и температура примерно приблизилась к правде, но все еще отставая градуса на полтора, а влажность он стабильно завышал на 10 - 15%. Ну как бы даже для домашнего «показометра» многовато.
Индикатор заряда как таковой отсутствует, если он светится белым – батарея заряжена, фиолетовым – заряжена не совсем. А сколько ее там осталось? Да пес ее знает…
Ладно, подключим зарядку. И что мы видим? Температура очень скоро превысила комнатную и устремилась к 30 градусам (это можно принять за константу во время заряда батареи), а влажность упала процентов на 10 ниже реальной.
Т.е. в корпусе явно во время заряда что-то греется и дополнительно сушит воздух. Неприятно.
Но оно бы и ничего, но как выяснилось – заряда батареи хватает на 6 - 10 часов, т.е. бывать на зарядке и греться, а следовательно, выдавать неточные показания он будет каждый день.
При низком заряде устройство отключается, и чтобы посмотреть показания его надо снова включить. И дождаться, пока оно придет в себя, ибо сразу по включению оно показывает погоду на Марсе.
Также у девайса есть звуковая сигнализация превышением уровня СО2 некоторого порогового показателя, по умолчанию 1000 ppm, а это, чтобы было понятно, спокойно надышит один человек за час-полтора при закрытых окнах в небольшом помещении.
В спальне два взрослых человека с микропроветриванием к утру наберут 1300-1500, а без него и 1700 спокойно будет. Причем особой беды от этого нет, утром встанут – проветрят.
А оно пищит на тысячу и звуковой сигнал отключить нельзя. Более того, при любом выключении устройство сбрасывает все свои настройки. Сбрасывает, Карл!
Хотя настроек там кот наплакал: три уровня яркости и порог срабатывания звукового сигнала.
В результате мы получаем игрушку: интересную, но бесполезную. Которая показывает что-то там, не способна отработать от одного заряда даже с утра до вечера и будет постоянно требовать вашего внимания, ну или пищать в самое неподходящее время.
Пришлось оформить возврат и отправить игрушку обратным адресом. Причем бралось это все не у перекупов, а в официальном магазине Kitfort на Яндекс Маркете.
Ну и осталось еще недоумение. Как же так? Ну вы что сами не видели того, что у вас получилось? Не пробовали день-два попользоваться? Оно же в целом непригодно к использованию.
И на Китай тоже кивать не надо, в Китае половина земного шарика что-то производит и производит вполне нормально, было бы желание.
А со следующего года нам обещают введения сбора на электронику. Для чего? Для поддержки подобных недоразумений?
Ну и производителю, если он это все-таки прочитает. Я очень лояльно отношусь к отечественному: хоть железу, хоть софту, прекрасно понимаю сложности и все такое прочее. Но выводить на рынок подобную дребедень? Это перебор.
Как-то недавно, достаточно случайно набрел на датчики CO2 от Kitfort, невысокая цена в купе с прочими характеристиками заинтересовали. Но модель на проводе мне была не особо интересна, потому, как и так кругом в проводах, а вот аккумуляторная КТ-3345 – почему бы и нет.
Естественно, как серьезный измерительный прибор я этот девайс не рассматривал, но как первичную оценку качества воздуха, плюс термометр-гигрометр – почему бы и нет.
На первый взгляд – выглядит неплохо, плюс отечественный производитель и все такое.
Сказано – сделано, заказал. Привезли устройство утром, включил я его уже вечером и сильно удивился. Показания температуры и влажности были далеки от реальных. Ну влажность – ладно, лежал в закрытой коробке. Но температура? Он ведь часов десять пролежал в комнате.
А сравнить мне есть чем. В наличии датчики от Xiaomi, какие-то китайцы и механический термометр-гигрометр. Все примерно поют одну песню: температура плюс-минус градус, влажность плюс-минус 5-7%.
Данный девайс постоял с полчасика, и температура примерно приблизилась к правде, но все еще отставая градуса на полтора, а влажность он стабильно завышал на 10 - 15%. Ну как бы даже для домашнего «показометра» многовато.
Индикатор заряда как таковой отсутствует, если он светится белым – батарея заряжена, фиолетовым – заряжена не совсем. А сколько ее там осталось? Да пес ее знает…
Ладно, подключим зарядку. И что мы видим? Температура очень скоро превысила комнатную и устремилась к 30 градусам (это можно принять за константу во время заряда батареи), а влажность упала процентов на 10 ниже реальной.
Т.е. в корпусе явно во время заряда что-то греется и дополнительно сушит воздух. Неприятно.
Но оно бы и ничего, но как выяснилось – заряда батареи хватает на 6 - 10 часов, т.е. бывать на зарядке и греться, а следовательно, выдавать неточные показания он будет каждый день.
При низком заряде устройство отключается, и чтобы посмотреть показания его надо снова включить. И дождаться, пока оно придет в себя, ибо сразу по включению оно показывает погоду на Марсе.
Также у девайса есть звуковая сигнализация превышением уровня СО2 некоторого порогового показателя, по умолчанию 1000 ppm, а это, чтобы было понятно, спокойно надышит один человек за час-полтора при закрытых окнах в небольшом помещении.
В спальне два взрослых человека с микропроветриванием к утру наберут 1300-1500, а без него и 1700 спокойно будет. Причем особой беды от этого нет, утром встанут – проветрят.
А оно пищит на тысячу и звуковой сигнал отключить нельзя. Более того, при любом выключении устройство сбрасывает все свои настройки. Сбрасывает, Карл!
Хотя настроек там кот наплакал: три уровня яркости и порог срабатывания звукового сигнала.
В результате мы получаем игрушку: интересную, но бесполезную. Которая показывает что-то там, не способна отработать от одного заряда даже с утра до вечера и будет постоянно требовать вашего внимания, ну или пищать в самое неподходящее время.
Пришлось оформить возврат и отправить игрушку обратным адресом. Причем бралось это все не у перекупов, а в официальном магазине Kitfort на Яндекс Маркете.
Ну и осталось еще недоумение. Как же так? Ну вы что сами не видели того, что у вас получилось? Не пробовали день-два попользоваться? Оно же в целом непригодно к использованию.
И на Китай тоже кивать не надо, в Китае половина земного шарика что-то производит и производит вполне нормально, было бы желание.
А со следующего года нам обещают введения сбора на электронику. Для чего? Для поддержки подобных недоразумений?
Ну и производителю, если он это все-таки прочитает. Я очень лояльно отношусь к отечественному: хоть железу, хоть софту, прекрасно понимаю сложности и все такое прочее. Но выводить на рынок подобную дребедень? Это перебор.
👍46😁7❤3🤮2⚡1
Их нравы
Проект GrapheneOS, разрабатывающий альтернативную свободную прошивку на базе Android, нацеленную на усиление безопасности и обеспечение конфиденциальности, столкнулся с угрозой преследования со стороны правоохранительных органов Франции из-за невозможности анализа содержимого смартфонов арестованных преступников.
Правоохранительные органы не смогли извлечь информацию со смартфона, захваченного при обыске предполагаемого руководителя преступной группировки, так как на его устройстве использовалась прошивка на базе GrapheneOS с функцией сброса расшифрованных разделов с пользовательскими данными в исходное нерасшифрованное состояние, а также с возможностью установить деструктивный PIN-код, удаляющий данные.
После чего во французской прессе появилась серия публикаций, которые приравнивают общедоступный открытый проект к компаниям, продающим закрытые продукты на базе кода GrapheneOS. Статьи пытаются создать негативное представление о проекте GrapheneOS, как инструменте, содействующем совершению преступлений, а также упоминают возможность конфискации серверов и ареста разработчиков, в случае отказа от сотрудничества.
Представители GrapheneOS считают, что приписывать их проекту оказание помощи преступникам также нелепо, как считать соучастниками преступлений производителей ножей. Тем более что в статьях под именем GrapheneOS преподносится не штатная сборка, а сторонняя коммерческая прошивка, созданная на базе кода проекта GrapheneOS.
В связи с этим решено покинуть Францию, отказаться от услуг французского провайдера OVH и переместить серверы в другую страну. Серверы, обеспечивающие работу платформ Mastodon, Discourse и Matrix, будут перемещены в Канаду, а сайт переведён к немецкому провайдеру Netcup.
У проекта больше не будет разработчиков, работающих во Франции, или посещающих конференции во Франции. При этом, несмотря на попытки очернить проект, использование платформы GrapheneOS остаётся легальной во Франции и сервисы GrapheneOS останутся доступны для французских пользователей.
✅ По материалам: https://www.opennet.ru/opennews/art.shtml?num=64317
Проект GrapheneOS, разрабатывающий альтернативную свободную прошивку на базе Android, нацеленную на усиление безопасности и обеспечение конфиденциальности, столкнулся с угрозой преследования со стороны правоохранительных органов Франции из-за невозможности анализа содержимого смартфонов арестованных преступников.
Правоохранительные органы не смогли извлечь информацию со смартфона, захваченного при обыске предполагаемого руководителя преступной группировки, так как на его устройстве использовалась прошивка на базе GrapheneOS с функцией сброса расшифрованных разделов с пользовательскими данными в исходное нерасшифрованное состояние, а также с возможностью установить деструктивный PIN-код, удаляющий данные.
После чего во французской прессе появилась серия публикаций, которые приравнивают общедоступный открытый проект к компаниям, продающим закрытые продукты на базе кода GrapheneOS. Статьи пытаются создать негативное представление о проекте GrapheneOS, как инструменте, содействующем совершению преступлений, а также упоминают возможность конфискации серверов и ареста разработчиков, в случае отказа от сотрудничества.
Представители GrapheneOS считают, что приписывать их проекту оказание помощи преступникам также нелепо, как считать соучастниками преступлений производителей ножей. Тем более что в статьях под именем GrapheneOS преподносится не штатная сборка, а сторонняя коммерческая прошивка, созданная на базе кода проекта GrapheneOS.
В связи с этим решено покинуть Францию, отказаться от услуг французского провайдера OVH и переместить серверы в другую страну. Серверы, обеспечивающие работу платформ Mastodon, Discourse и Matrix, будут перемещены в Канаду, а сайт переведён к немецкому провайдеру Netcup.
У проекта больше не будет разработчиков, работающих во Франции, или посещающих конференции во Франции. При этом, несмотря на попытки очернить проект, использование платформы GrapheneOS остаётся легальной во Франции и сервисы GrapheneOS останутся доступны для французских пользователей.
✅ По материалам: https://www.opennet.ru/opennews/art.shtml?num=64317
🔥21❤4🤔1
Приведет ли ИИ к деградации программирования и обесцениванию профессии программиста?
Продолжение, начало здесь: https://news.1rj.ru/str/interface31/5280
В прошлой заметке мы пришли к тому, что написание кода – это лишь часть работы программиста и далеко не самая важная.
Безусловно, работа программиста – это творческий и созидательный процесс и написание кода – это только лишь воплощение найденных программистом идей и решений. Равно как буквы и слова позволяют воплотить писателю свои идеи в текст. Но если писательского таланта нет, то сколько текста не напиши – получится унылая графомания.
Но в процессе создания программы каждый программист сталкивается с кучей вещей, безусловно важных и нужных, но совсем не творческих, а скучных и рутинных.
Так, если вы пишете на языке без строгой типизации – вам нужно обязательно делать проверку типов, чтобы вместо строки не оказалось число и наоборот. Затем вам нужно проверить ввод пользователя, все ли поля он правильно заполнил.
Потом надо проконтролировать результаты вычисления, особенно на предмет возможных пустых значений. А дальше предстоит тоже довольно скучный процесс вывода данных пользователю в удобной для него форме.
Тут и склонения «год, года, лет» и т.п., форматирование даты и времени, представление сумм и чисел. Да и вообще отработка взаимодействия пользователя с интерфейсом, видимость и доступность элементов и т.д. и т.п.
Такая работа является повторяющейся, монотонной, рутинной. А еще надо и обработкой исключений заняться, чтобы пользователь получал человекочитаемое сообщение об ошибке, а не китайскую грамоту в виде промежуточного результата вычислений.
В результате лодка творческого порыва очень быстро разбивается об рутину. Если это пет-проект, то очень часто на этом этапе он может быть заброшен. Да и опенсорса, который много лет выглядит как сырой прототип более чем достаточно. Ну не интересна автору рутина, у него творчество, а дальше вы сами, как хотите.
В коммерческой разработке для работы с рутиной нанимают начинающих (да и не только) специалистов невысокой квалификации, на которых вся эта рутина и спихивается. А также написание кода по заранее подготовленным техзаданиям.
Творчества там ровно ноль, надо лишь старательно делать то, что сказали старшие товарищи и желательно с минимальными отступлениями от задания.
Сегодня именно на эту область и нацелен ИИ, который хорошо знает языки, правила написания кода на этих языках, готов старательно обернуть все проверками, проверить и отформатировать вывод, прокомментировать и задокументировать код. Причем сделает это гораздо быстрее, чем человек.
Несет ли это какую-то угрозу программированию и программисту? Нет, ИИ не способен изобретать новое, это прерогатива человека, но теперь человек свободен от рутины, он можете переложить ее на ИИ-агента или ИИ-среду разработки.
Он может написать костяк кода сам, а ИИ уже будет накрашивать на него «мясо», либо вообще сосредоточиться именно на процессе разработки новых функций, оставив работу по написанию кода буквами ИИ-помощнику.
В любом случае читать, тестировать и принимать код будет человек и за ним останется последнее слово.
Можно ли навайбкодить что-нибудь, вообще не зная программирования и не обладая техническим бекграундом?
Почему нельзя? Можно, но это будет что-то простое, в рамках известных ИИ подходов и алгоритмов. Но это примерно, как электронные таблицы. Выполнить ряд вычислений, даже не самых простых смогут, но заменить специализированный софт не способны.
И нет ничего страшного, что обычные люди сами напишут себе считалки и решалки, к серьезным проектам это никакого отношения не имеет.
Также серьезно напрягутся джуны, особенно не те, кто только пришел в профессию и готов изучать, развиваться и расти как специалист, а те, которые давно пригрелись на одном месте и никуда с него двигаться не хотят. А таже разные «войти в айти» и прочие вкатывальшики.
Но основная часть специалистов от такого расклада только выиграет, переложив рутину на ИИ и оставив себе творческие, созидательные задачи.
Продолжение, начало здесь: https://news.1rj.ru/str/interface31/5280
В прошлой заметке мы пришли к тому, что написание кода – это лишь часть работы программиста и далеко не самая важная.
Безусловно, работа программиста – это творческий и созидательный процесс и написание кода – это только лишь воплощение найденных программистом идей и решений. Равно как буквы и слова позволяют воплотить писателю свои идеи в текст. Но если писательского таланта нет, то сколько текста не напиши – получится унылая графомания.
Но в процессе создания программы каждый программист сталкивается с кучей вещей, безусловно важных и нужных, но совсем не творческих, а скучных и рутинных.
Так, если вы пишете на языке без строгой типизации – вам нужно обязательно делать проверку типов, чтобы вместо строки не оказалось число и наоборот. Затем вам нужно проверить ввод пользователя, все ли поля он правильно заполнил.
Потом надо проконтролировать результаты вычисления, особенно на предмет возможных пустых значений. А дальше предстоит тоже довольно скучный процесс вывода данных пользователю в удобной для него форме.
Тут и склонения «год, года, лет» и т.п., форматирование даты и времени, представление сумм и чисел. Да и вообще отработка взаимодействия пользователя с интерфейсом, видимость и доступность элементов и т.д. и т.п.
Такая работа является повторяющейся, монотонной, рутинной. А еще надо и обработкой исключений заняться, чтобы пользователь получал человекочитаемое сообщение об ошибке, а не китайскую грамоту в виде промежуточного результата вычислений.
В результате лодка творческого порыва очень быстро разбивается об рутину. Если это пет-проект, то очень часто на этом этапе он может быть заброшен. Да и опенсорса, который много лет выглядит как сырой прототип более чем достаточно. Ну не интересна автору рутина, у него творчество, а дальше вы сами, как хотите.
В коммерческой разработке для работы с рутиной нанимают начинающих (да и не только) специалистов невысокой квалификации, на которых вся эта рутина и спихивается. А также написание кода по заранее подготовленным техзаданиям.
Творчества там ровно ноль, надо лишь старательно делать то, что сказали старшие товарищи и желательно с минимальными отступлениями от задания.
Сегодня именно на эту область и нацелен ИИ, который хорошо знает языки, правила написания кода на этих языках, готов старательно обернуть все проверками, проверить и отформатировать вывод, прокомментировать и задокументировать код. Причем сделает это гораздо быстрее, чем человек.
Несет ли это какую-то угрозу программированию и программисту? Нет, ИИ не способен изобретать новое, это прерогатива человека, но теперь человек свободен от рутины, он можете переложить ее на ИИ-агента или ИИ-среду разработки.
Он может написать костяк кода сам, а ИИ уже будет накрашивать на него «мясо», либо вообще сосредоточиться именно на процессе разработки новых функций, оставив работу по написанию кода буквами ИИ-помощнику.
В любом случае читать, тестировать и принимать код будет человек и за ним останется последнее слово.
Можно ли навайбкодить что-нибудь, вообще не зная программирования и не обладая техническим бекграундом?
Почему нельзя? Можно, но это будет что-то простое, в рамках известных ИИ подходов и алгоритмов. Но это примерно, как электронные таблицы. Выполнить ряд вычислений, даже не самых простых смогут, но заменить специализированный софт не способны.
И нет ничего страшного, что обычные люди сами напишут себе считалки и решалки, к серьезным проектам это никакого отношения не имеет.
Также серьезно напрягутся джуны, особенно не те, кто только пришел в профессию и готов изучать, развиваться и расти как специалист, а те, которые давно пригрелись на одном месте и никуда с него двигаться не хотят. А таже разные «войти в айти» и прочие вкатывальшики.
Но основная часть специалистов от такого расклада только выиграет, переложив рутину на ИИ и оставив себе творческие, созидательные задачи.
👍13❤5🤔2🤮2🤣1
Всегда свежие Sysinternals
Инструменты Sysinternals от Марка Руссиновича в представлении не нуждаются, появившись в 1996 году они уже практически 30 лет пользуются заслуженной популярностью у администраторов.
Несмотря на свой возраст инструменты активно обновляются и дополняются, поэтому вполне понятно желание иметь всегда свежую версию любимых утилит.
Это можно легко реализовать при помощи сервиса Sysinternals Live, просто введите в проводнике
После чего можете подключить данную директорию как сетевой диск или создать на нее ярлык.
Для запуска в командной строке можете использовать сетевой путь:
Нужная утилита автоматически будет скачана и запущена.
Инструменты Sysinternals от Марка Руссиновича в представлении не нуждаются, появившись в 1996 году они уже практически 30 лет пользуются заслуженной популярностью у администраторов.
Несмотря на свой возраст инструменты активно обновляются и дополняются, поэтому вполне понятно желание иметь всегда свежую версию любимых утилит.
Это можно легко реализовать при помощи сервиса Sysinternals Live, просто введите в проводнике
\\live.sysinternals.com\tools
После чего можете подключить данную директорию как сетевой диск или создать на нее ярлык.
Для запуска в командной строке можете использовать сетевой путь:
\\live.sysinternals.com\tools\<toolname>
Нужная утилита автоматически будет скачана и запущена.
👍36🔥8❤1🥱1
Всегда свежие Sysinternals, автоматизируем процесс
Днем мы рассказали о сервисе Sysinternals Live, позволяющем онлайн получить новейшие версии утилит из состава Sysinternals Suite.
Но реалии последних дней говорят о том, что можно остаться без доступа в сеть вообще в самый неподходящий момент или без доступа к некоторым ресурсам, в частности.
Скачивать руками каждый раз тоже не сильно хочется, так почему бы не автоматизировать эту задачу? Мы написали простой скрипт на PowerShell, который при запуске соединяется с сервисом Sysinternals Live и синхронизирует его содержимое с локальной папкой tools в директории запуска скрипта.
В комплекте вместе со скриптом
Но нам более интересно его выполнение по расписанию, для этого создадим в Планировщике новое задание, допустим с именем Синхронизация Sysinternals Tools.
Выбираем условия запуска:
▫️ Выполнять только для зарегистрированного пользователя
▫️ Выполнять вне зависимости от регистрации пользователя
Во втором случае скрипт будет запущен даже если пользователь не вошел в систему.
Далее указываем желаемое расписание, скажем каждый день в 2 часа ночи и на вкладке Действия указываем:
▫️ Действие: Запустить программу
▫️Программа или сценарий:
▫️Аргументы:
▫️Рабочая папка:
Сохраняем задание, размещаем по указанному пути (в нашем примере C:\ADM) файл скрипта и запускаем задание вручную. Если вы все сделали правильно – начнется синхронизация.
Быстро выполнить все тоже самое можно командой:
Далее можете удалить какой-нибудь файл из папки или заменить его более старой версией и запустить синхронизацию повторно. Скачаются только недостающие файлы.
Файлы можно скачать в комментариях 👇👇👇
Днем мы рассказали о сервисе Sysinternals Live, позволяющем онлайн получить новейшие версии утилит из состава Sysinternals Suite.
Но реалии последних дней говорят о том, что можно остаться без доступа в сеть вообще в самый неподходящий момент или без доступа к некоторым ресурсам, в частности.
Скачивать руками каждый раз тоже не сильно хочется, так почему бы не автоматизировать эту задачу? Мы написали простой скрипт на PowerShell, который при запуске соединяется с сервисом Sysinternals Live и синхронизирует его содержимое с локальной папкой tools в директории запуска скрипта.
В комплекте вместе со скриптом
Sync-Sysinternals.ps1 идет пакетный файл run-sync.bat, который позволяет быстро запустить скрипт вручную.Но нам более интересно его выполнение по расписанию, для этого создадим в Планировщике новое задание, допустим с именем Синхронизация Sysinternals Tools.
Выбираем условия запуска:
▫️ Выполнять только для зарегистрированного пользователя
▫️ Выполнять вне зависимости от регистрации пользователя
Во втором случае скрипт будет запущен даже если пользователь не вошел в систему.
Далее указываем желаемое расписание, скажем каждый день в 2 часа ночи и на вкладке Действия указываем:
▫️ Действие: Запустить программу
▫️Программа или сценарий:
powershell.exe▫️Аргументы:
-ExecutionPolicy Bypass -File "F:\VIBE\sysinternals_live\Sync-Sysinternals.ps1"▫️Рабочая папка:
C:\ADMСохраняем задание, размещаем по указанному пути (в нашем примере C:\ADM) файл скрипта и запускаем задание вручную. Если вы все сделали правильно – начнется синхронизация.
Быстро выполнить все тоже самое можно командой:
schtasks /create /tn "Sync-Sysinternals" /tr "powershell.exe -ExecutionPolicy Bypass -File \""C:\ADM\Sync-Sysinternals.ps1\"" /sc DAILY /st 02:00 /ru "%USERDOMAIN%\%USERNAME%" /f /rl HIGHEST
Далее можете удалить какой-нибудь файл из папки или заменить его более старой версией и запустить синхронизацию повторно. Скачаются только недостающие файлы.
Файлы можно скачать в комментариях 👇👇👇
1👍27❤4🤮3👌2🤔1
📌 Приглашаем на вебинар
«Дефицит ресурсов — не повод для хаоса: как выстроить техподдержку 220 торговых точек всего за 6 недель»
🗓 4 декабря, 11:00
Будет полезно, если:
— Сервис перегружен и нужно наладить его работу с минимумом затрат
— Требуется расширить набор функций и метрик без долгих и дорогих доработок service desk
↓ ↓ ↓
На примере реального кейса спикеры ITSM 365 и SMARTER расскажут:
— Как за 6 недель перевести сотни торговых точек с почты и Excel в сервис деск
— Как объединить команды торговой сети, подрядчиков и вендоров в одной системе
— Как создать в service desk структуру обслуживания, связав заявки с оборудованием, складами и поставщиками
— Витрина услуг, кастомизация заявок, согласование и оценка работ, настройка отчетов и дашбордов — какие функции гарантированно разгрузят ваш сервис.
Регистрируйтесь по ссылке 🔗
#реклама
О рекламодателе
«Дефицит ресурсов — не повод для хаоса: как выстроить техподдержку 220 торговых точек всего за 6 недель»
🗓 4 декабря, 11:00
Будет полезно, если:
— Сервис перегружен и нужно наладить его работу с минимумом затрат
— Требуется расширить набор функций и метрик без долгих и дорогих доработок service desk
↓ ↓ ↓
На примере реального кейса спикеры ITSM 365 и SMARTER расскажут:
— Как за 6 недель перевести сотни торговых точек с почты и Excel в сервис деск
— Как объединить команды торговой сети, подрядчиков и вендоров в одной системе
— Как создать в service desk структуру обслуживания, связав заявки с оборудованием, складами и поставщиками
— Витрина услуг, кастомизация заявок, согласование и оценка работ, настройка отчетов и дашбордов — какие функции гарантированно разгрузят ваш сервис.
Регистрируйтесь по ссылке 🔗
#реклама
О рекламодателе
❤2🤮1👌1👀1
1С в контейнерах. Практическое руководство – 1
Последнее время нас много спрашивают о том, как поднять сервер 1С:Предприятия в LXC контейнерах. Поэтому мы решили более подробно разобраться в этом вопросе.
Прежде всего – почему именно LXC, а не виртуальные машины? Дело в том, что LXC, как и любой другой контейнер, не использует технологию виртуализации – т.е. эмуляции некоторой аппаратной платформы, отличной от платформы хоста.
Любое запущенное в контейнере приложение запускается как процесс хоста, а контейнер обеспечивает только изоляцию запущенных процессов и выделение ресурсов согласно установленным лимитам.
Стоп, скажет иной читатель, а как быть с «операционной системой» в контейнере? На самом деле это не полноценная операционная система, а просто набор библиотек, предоставляющий приложению требуемое окружение.
Таким образом у нас практически отсутствуют накладные расходы на контейнеризацию, плюс добавляются некоторые приятные плюсы, скажем виртуальная сеть между контейнерами в пределах хоста работает на скорости оперативной памяти.
При контейнеризации мы будем исходить из соображений: одна служба – один контейнер. Таким образом у нас напрашивается минимум три контейнера: Сервер 1С:Предприятие, PostgreSQL и веб-сервер.
Для PostgreSQL хорошей практикой является выделение отдельного инстанса на каждую базу. Но даже если это невозможно, то постарайтесь разнести по разным контейнерам базы с разными прикладными решениями, а также рабочие, архивные и тестовые базы.
Веб-сервера тоже стоит разделять, как минимум на обслуживающие клиентские подключения и веб-сервисы.
С этим разобрались. Теперь перейдем к распространенным ошибкам. Не следует выбирать для 1С контейнеры с неподдерживаемой системой внутри. Это ничего вам не даст, кроме лишней головной боли.
Скажем, сервер 1С в контейнере с Debian 13 не будет работать лучше, чем с Debian 12, а вот головной боли добавить может и это будет именно ваша головная боль, потому что платформа не поддерживается. У вас даже багрепорт не примут, по этой самой причине.
Но основной смысл перехода от монолита к контейнерам – это, конечно же, гибкое управление ресурсами. Оно же становится основной сложностью для начинающих. Начнем с процессора.
Платформа 1С:Предприятие уровня ПРОФ ограничена по лицензионным соображениям 12 процессорными ядрами (не важно физическими или виртуальными). Таким образом любой современный процессор предоставляет нам ядер больше, чем требуется для 1С.
Поэтому обязательно привязываем сервер 1С к любым 12 выделенным ядрам, если этого не сделать, то при перезапуске контейнер получит другие ядра, пусть и в том же количестве, что с точки зрения системы лицензирования 1С будет рассматриваться как замена процессора и может привести к слету лицензии.
После чего также явно привязываем ядра к остальным контейнерам. Если этого не сделать, то может оказаться так, что какие-то ядра загружены, а какие-то простаивают. Также для процессоров Intel последних поколений критически важно для производительности выполнить привязку контейнера сервера 1С к продуктивным, а не энергоэффективным ядрам.
При этом не забывайте про базовые настройки железа, рекомендованные для серверов 1С. В частности, это включение Turbo-bust на все ядра, отключение режимов энергосбережения процессора C-State (выключаем или выбираем C0), а также отключаем управление питанием и частотой процессора P-states (выбираем наиболее производительный режим P0).
В разных BIOS и на разных материнских платах это называется по-разному, но общий смысл такой – процессор должен работать только на номинальной частое и выше, технологии энергосбережения отключены.
Игнорирование данной настройки может приводить к серьезным просадкам производительности сервера 1С:Предприятия и являются очень частой ошибкой конфигурирования.
Последнее время нас много спрашивают о том, как поднять сервер 1С:Предприятия в LXC контейнерах. Поэтому мы решили более подробно разобраться в этом вопросе.
Прежде всего – почему именно LXC, а не виртуальные машины? Дело в том, что LXC, как и любой другой контейнер, не использует технологию виртуализации – т.е. эмуляции некоторой аппаратной платформы, отличной от платформы хоста.
Любое запущенное в контейнере приложение запускается как процесс хоста, а контейнер обеспечивает только изоляцию запущенных процессов и выделение ресурсов согласно установленным лимитам.
Стоп, скажет иной читатель, а как быть с «операционной системой» в контейнере? На самом деле это не полноценная операционная система, а просто набор библиотек, предоставляющий приложению требуемое окружение.
Таким образом у нас практически отсутствуют накладные расходы на контейнеризацию, плюс добавляются некоторые приятные плюсы, скажем виртуальная сеть между контейнерами в пределах хоста работает на скорости оперативной памяти.
При контейнеризации мы будем исходить из соображений: одна служба – один контейнер. Таким образом у нас напрашивается минимум три контейнера: Сервер 1С:Предприятие, PostgreSQL и веб-сервер.
Для PostgreSQL хорошей практикой является выделение отдельного инстанса на каждую базу. Но даже если это невозможно, то постарайтесь разнести по разным контейнерам базы с разными прикладными решениями, а также рабочие, архивные и тестовые базы.
Веб-сервера тоже стоит разделять, как минимум на обслуживающие клиентские подключения и веб-сервисы.
С этим разобрались. Теперь перейдем к распространенным ошибкам. Не следует выбирать для 1С контейнеры с неподдерживаемой системой внутри. Это ничего вам не даст, кроме лишней головной боли.
Скажем, сервер 1С в контейнере с Debian 13 не будет работать лучше, чем с Debian 12, а вот головной боли добавить может и это будет именно ваша головная боль, потому что платформа не поддерживается. У вас даже багрепорт не примут, по этой самой причине.
Но основной смысл перехода от монолита к контейнерам – это, конечно же, гибкое управление ресурсами. Оно же становится основной сложностью для начинающих. Начнем с процессора.
Платформа 1С:Предприятие уровня ПРОФ ограничена по лицензионным соображениям 12 процессорными ядрами (не важно физическими или виртуальными). Таким образом любой современный процессор предоставляет нам ядер больше, чем требуется для 1С.
Поэтому обязательно привязываем сервер 1С к любым 12 выделенным ядрам, если этого не сделать, то при перезапуске контейнер получит другие ядра, пусть и в том же количестве, что с точки зрения системы лицензирования 1С будет рассматриваться как замена процессора и может привести к слету лицензии.
После чего также явно привязываем ядра к остальным контейнерам. Если этого не сделать, то может оказаться так, что какие-то ядра загружены, а какие-то простаивают. Также для процессоров Intel последних поколений критически важно для производительности выполнить привязку контейнера сервера 1С к продуктивным, а не энергоэффективным ядрам.
При этом не забывайте про базовые настройки железа, рекомендованные для серверов 1С. В частности, это включение Turbo-bust на все ядра, отключение режимов энергосбережения процессора C-State (выключаем или выбираем C0), а также отключаем управление питанием и частотой процессора P-states (выбираем наиболее производительный режим P0).
В разных BIOS и на разных материнских платах это называется по-разному, но общий смысл такой – процессор должен работать только на номинальной частое и выше, технологии энергосбережения отключены.
Игнорирование данной настройки может приводить к серьезным просадкам производительности сервера 1С:Предприятия и являются очень частой ошибкой конфигурирования.
1👍43❤2🤝2👌1
1С в контейнерах. Практическое руководство – 2
Определившись с процессорными ресурсами, переходим к памяти. Это самый сложный вопрос, особенно для тех, кто только собирается внедрять клиент-серверную версию. Потому что нельзя точно ответить на вопрос о том, сколько надо оперативной памяти.
Даже одна и та же конфигурация с одним и тем же размером базы при разных сценариях использования будет иметь разный расход памяти. Хорошо, если у вас уже есть клиент-серверная система, тогда вы можете собрать метрики и сделать более-менее точные предположения.
Но так как данный вопрос не сходит с повестки дня, то постараемся дать некоторые общие ориентиры. Сразу оговоримся, сказанное ниже применимо только к типовым конфигурациям 1С с нагрузкой, не превышающей среднюю. В других сценариях цифры могут быть абсолютно другие.
1️⃣ Начнем с сервера 1С:Предприятие. Цифра, на которую следует ориентироваться – это 1-2 ГБ оперативной памяти на сеанс, можно взять среднее значение 1,5 ГБ и не сильно ошибиться. Понятно, что это среднее значение, реальные цифры могут изменяться от задач.
На одном из наших рабочих серверов с 1С:Бухгалтерия мы получили среднее значение 1,19 ГБ на сеанс, при этом были сеансы потреблявшие 400-700 МБ памяти, а были с потреблением 3-3,5 ГБ. Все зависит от роли и задач пользователя.
Также добавьте сюда регламентные и фоновые задания, которые тоже тратят память во время выполнения, иногда – значительную. По-хорошему, тяжелые фоновые задания следует настроить так, чтобы они работали за периодом пользовательской активности, так как именно они часто являются основной причиной «тормозов».
Отдельного внимания стоят сеансы через веб-сервер, не важно используется для работы тонкий клиент или веб-клиент в браузере. В целях повторного использования (так как создание сеанса – дорогая операция) сеанс сохраняется в течении 20 минут после отключения пользователя.
В ряде сценариев это может привести к повышенному расходу оперативной памяти несмотря на небольшое число активных пользователей.
Те же 20 минут действуют и для неактивных сеансов, после чего они уходят в сон и могут освободить ресурсы. Период завершения таких сеансов по умолчанию сутки.
2️⃣ И если с сервером 1С все более-менее ясно, то PostgreSQL представляет собой более сложную систему. Любой сервер СУБД имеет тенденцию утилизировать всю доступную память. Но на самом деле достаточно чтобы в нее помещались горячие данные, потому как база 1С:Предприятие может содержать большое количество нормативно-справочной или архивной информации.
Также сильно влияет и характер нагрузки, менеджеры, выписывающие накладный и бухгалтер закрывающий месяц – это две сильно большие разницы. Но надо же нам от чего отталкиваться?
Очень и очень приблизительный расчет можно сделать из размера базы данных. Эмпирическим путем была выведена общая формула:
Еще раз напомним – эта формула применима только к типовым базам 1С:Предприятие с нагрузкой ниже среднего.
Для примера мы проверили несколько наших серверов:
🔹 Сервер №1
▫️Размер базы – 33 ГБ
▫️Размер ОЗУ по формуле – 10,25 ГБ
▫️Выделенный размер ОЗУ – 12 ГБ
▫️ Реальное потребление – 8,5 ГБ
🔹 Сервер №2
▫️Размер базы – 28 ГБ
▫️Размер ОЗУ по формуле – 9 ГБ
▫️Выделенный размер ОЗУ – 8 ГБ
▫️Реальное потребление – 3 ГБ
Основное различие баз – в количестве активных пользователей и операций, хотя и там и там установлена типовая 1С:Бухгалтерия.
Но даже такой расчет лучше, чем никакого и впоследствии вы всегда можете скорректировать эти значения.
3️⃣ Веб-сервер в клиент-серверном сценарии особых ресурсов не потребляет, так как занимается сугубо проксированием запросов и ресурсы ему можно выделить по остаточному принципу. В расчетах можно исходить из 2-10 МБ на сеанс.
4️⃣ На самом Proxmox, если вы используете ZFS – обязательно настройте выделение памяти для ARC исходя из формулы:
В противном случае, со значениями по умолчанию ZFS может использовать под кеш до 50% установленной памяти.
Определившись с процессорными ресурсами, переходим к памяти. Это самый сложный вопрос, особенно для тех, кто только собирается внедрять клиент-серверную версию. Потому что нельзя точно ответить на вопрос о том, сколько надо оперативной памяти.
Даже одна и та же конфигурация с одним и тем же размером базы при разных сценариях использования будет иметь разный расход памяти. Хорошо, если у вас уже есть клиент-серверная система, тогда вы можете собрать метрики и сделать более-менее точные предположения.
Но так как данный вопрос не сходит с повестки дня, то постараемся дать некоторые общие ориентиры. Сразу оговоримся, сказанное ниже применимо только к типовым конфигурациям 1С с нагрузкой, не превышающей среднюю. В других сценариях цифры могут быть абсолютно другие.
1️⃣ Начнем с сервера 1С:Предприятие. Цифра, на которую следует ориентироваться – это 1-2 ГБ оперативной памяти на сеанс, можно взять среднее значение 1,5 ГБ и не сильно ошибиться. Понятно, что это среднее значение, реальные цифры могут изменяться от задач.
На одном из наших рабочих серверов с 1С:Бухгалтерия мы получили среднее значение 1,19 ГБ на сеанс, при этом были сеансы потреблявшие 400-700 МБ памяти, а были с потреблением 3-3,5 ГБ. Все зависит от роли и задач пользователя.
Также добавьте сюда регламентные и фоновые задания, которые тоже тратят память во время выполнения, иногда – значительную. По-хорошему, тяжелые фоновые задания следует настроить так, чтобы они работали за периодом пользовательской активности, так как именно они часто являются основной причиной «тормозов».
Отдельного внимания стоят сеансы через веб-сервер, не важно используется для работы тонкий клиент или веб-клиент в браузере. В целях повторного использования (так как создание сеанса – дорогая операция) сеанс сохраняется в течении 20 минут после отключения пользователя.
В ряде сценариев это может привести к повышенному расходу оперативной памяти несмотря на небольшое число активных пользователей.
Те же 20 минут действуют и для неактивных сеансов, после чего они уходят в сон и могут освободить ресурсы. Период завершения таких сеансов по умолчанию сутки.
2️⃣ И если с сервером 1С все более-менее ясно, то PostgreSQL представляет собой более сложную систему. Любой сервер СУБД имеет тенденцию утилизировать всю доступную память. Но на самом деле достаточно чтобы в нее помещались горячие данные, потому как база 1С:Предприятие может содержать большое количество нормативно-справочной или архивной информации.
Также сильно влияет и характер нагрузки, менеджеры, выписывающие накладный и бухгалтер закрывающий месяц – это две сильно большие разницы. Но надо же нам от чего отталкиваться?
Очень и очень приблизительный расчет можно сделать из размера базы данных. Эмпирическим путем была выведена общая формула:
Размер ОЗУ = Размер базы / 4 + 2 ГБ (но не менее 4 ГБ)
Еще раз напомним – эта формула применима только к типовым базам 1С:Предприятие с нагрузкой ниже среднего.
Для примера мы проверили несколько наших серверов:
🔹 Сервер №1
▫️Размер базы – 33 ГБ
▫️Размер ОЗУ по формуле – 10,25 ГБ
▫️Выделенный размер ОЗУ – 12 ГБ
▫️ Реальное потребление – 8,5 ГБ
🔹 Сервер №2
▫️Размер базы – 28 ГБ
▫️Размер ОЗУ по формуле – 9 ГБ
▫️Выделенный размер ОЗУ – 8 ГБ
▫️Реальное потребление – 3 ГБ
Основное различие баз – в количестве активных пользователей и операций, хотя и там и там установлена типовая 1С:Бухгалтерия.
Но даже такой расчет лучше, чем никакого и впоследствии вы всегда можете скорректировать эти значения.
3️⃣ Веб-сервер в клиент-серверном сценарии особых ресурсов не потребляет, так как занимается сугубо проксированием запросов и ресурсы ему можно выделить по остаточному принципу. В расчетах можно исходить из 2-10 МБ на сеанс.
4️⃣ На самом Proxmox, если вы используете ZFS – обязательно настройте выделение памяти для ARC исходя из формулы:
1 ГБ для хоста + 4-5 ГБ на 1 ТБ хранилища (но не менее 3 ГБ)
В противном случае, со значениями по умолчанию ZFS может использовать под кеш до 50% установленной памяти.
👍15❤8🤝1
О чем писали 10 лет назад...
▫️ Представлен Kubernetes, пока что это непонятная диковинка
▫️ Ansible и ZeroTier как перспективные новинки
▫️ Android все еще не оставляет попыток захватить десктоп
▫️ BlackBerry про#$%ает последние полимеры, а ведь еще недавно...
С тех пор прошло 10 лет, мир изменился, местами неузнаваемо...
▫️ Представлен Kubernetes, пока что это непонятная диковинка
▫️ Ansible и ZeroTier как перспективные новинки
▫️ Android все еще не оставляет попыток захватить десктоп
▫️ BlackBerry про#$%ает последние полимеры, а ведь еще недавно...
С тех пор прошло 10 лет, мир изменился, местами неузнаваемо...
👍9❤7