Самозаверенные сертификаты. Мифы и реальность.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат никаким образом не влияет на набор используемых шифров и криптографических алгоритмов. За их использование полностью отвечают настройки защищаемого ПО, чаще всего веб-сервера.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и не даром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает из них самый стойких из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проше говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению и если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим удостоверяющим центром.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет центра сертификации и доверительные отношения с ним установить не удастся, все что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаше всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
👍27🥱6❤2🤔1🤝1
Выдача адресов клиентам в OpenVPN
OpenVPN – классическое, пользующееся заслуженной популярностью решение для создания корпоративных сетей. И поэтому вопрос распределения адресного пространства является актуальным.
По умолчанию, если не указано иных настроек, OpenVPN выдает адреса динамически из диапазона совпадающего с подсетью сервера, указанной в директиве:
В данном случае сервер возьмет себе первый адрес в сети – 10.8.0.1, а клиенты будут получать адреса из диапазона 10.8.0.2 – 10.8.0.254.
Если такой вариант нас не устраивает, то мы можем задать диапазон выделяемых IP-адресов явно, добавив в конфигурационный файл сервера опцию:
Теперь адреса клиентов будут выдаваться из указанного диапазона.
Но как быть, если мы хотим выдать клиенту постоянный IP-адрес? Можно воспользоваться файлом CCD (Client Configuration Directory), где хранятся персональные инструкции для подключившегося клиента, добавьте туда:
После чего подключившийся клиент получит адрес 10.8. 0.5. Таким образом вы можете раздать части клиентов выделенные адреса, а остальные продолжат их получать динамически.
Все это хорошо, но если клиентов много, то добавляется достаточно ручной работы. Можно ли сделать проще? Да, если конкретного требования к адресам нет, то можно воспользоваться технологией IP Pool Persist, которая сохраняет привязки между именами клиентов и назначенными им IP-адресами.
Чтобы ее активировать добавьте в конфигурационный файл сервера опцию:
Теперь при каждом подключении клиента OpenVPN считывает его имя – поле CN в сертификате и просматривает файл ipp.txt на предмет наличия записи с указанным CN.
Если запись найдена, клиент получает указанный в ней адрес. Если нет, то берется первый свободный адрес из пула и выдается клиенту, после чего в файл вносится новая запись, закрепляющая этот адрес за клиентом.
Таким образом мы получаем автоматическое выделение адресов с одновременным закреплением их за клиентами. И просто, и удобно.
Можно ли самостоятельно редактировать этот файл? Можно, но только предварительно остановив службу во избежание конфликтов. Вы можете изменить закрепление адресов или добавить новые записи с нужными вам адресами, не дожидаясь пока это будет сделано автоматически.
Если рассматривать оба приведенных нами способа, то следует помнить, что CCD имеет более высокий приоритет и клиенту будет присвоен адрес, указанный в CCD-файле даже если у него есть уже привязка в ipp.txt.
И вот здесь нужно быть крайне осторожным, чтобы избежать конфликтов и неоднозначных ситуаций, если адреса в CCD-файлах и ipp.txt пересекаются.
Что будет, если указанный в CCD адрес уже занят? OpenVPN выдаст первый свободный и занесет запись в ipp.txt. А если окажется занят адрес, указанный в ipp.txt, то поиск по файлу продолжится и если там есть вторая запись, то будет выдан указанные в ней адрес. Нет – снова первый свободный с созданием дубля записи.
Впоследствии это может приводить к тому, что клиент начнет получать разные адреса в зависимости от условий подключения. Поэтому при появлении в ipp.txt дублирующихся записей следует внимательно изучить конфигурации клиентов.
OpenVPN – классическое, пользующееся заслуженной популярностью решение для создания корпоративных сетей. И поэтому вопрос распределения адресного пространства является актуальным.
По умолчанию, если не указано иных настроек, OpenVPN выдает адреса динамически из диапазона совпадающего с подсетью сервера, указанной в директиве:
server 10.8.0.0 255.255.255.0
В данном случае сервер возьмет себе первый адрес в сети – 10.8.0.1, а клиенты будут получать адреса из диапазона 10.8.0.2 – 10.8.0.254.
Если такой вариант нас не устраивает, то мы можем задать диапазон выделяемых IP-адресов явно, добавив в конфигурационный файл сервера опцию:
ifconfig-pool 10.8.0.100 10.8.0.199
Теперь адреса клиентов будут выдаваться из указанного диапазона.
Но как быть, если мы хотим выдать клиенту постоянный IP-адрес? Можно воспользоваться файлом CCD (Client Configuration Directory), где хранятся персональные инструкции для подключившегося клиента, добавьте туда:
ifconfig-push 10.8. 0.5 255.255.255.0
После чего подключившийся клиент получит адрес 10.8. 0.5. Таким образом вы можете раздать части клиентов выделенные адреса, а остальные продолжат их получать динамически.
Все это хорошо, но если клиентов много, то добавляется достаточно ручной работы. Можно ли сделать проще? Да, если конкретного требования к адресам нет, то можно воспользоваться технологией IP Pool Persist, которая сохраняет привязки между именами клиентов и назначенными им IP-адресами.
Чтобы ее активировать добавьте в конфигурационный файл сервера опцию:
ifconfig-pool-persist ipp.txt
Теперь при каждом подключении клиента OpenVPN считывает его имя – поле CN в сертификате и просматривает файл ipp.txt на предмет наличия записи с указанным CN.
Если запись найдена, клиент получает указанный в ней адрес. Если нет, то берется первый свободный адрес из пула и выдается клиенту, после чего в файл вносится новая запись, закрепляющая этот адрес за клиентом.
Таким образом мы получаем автоматическое выделение адресов с одновременным закреплением их за клиентами. И просто, и удобно.
Можно ли самостоятельно редактировать этот файл? Можно, но только предварительно остановив службу во избежание конфликтов. Вы можете изменить закрепление адресов или добавить новые записи с нужными вам адресами, не дожидаясь пока это будет сделано автоматически.
Если рассматривать оба приведенных нами способа, то следует помнить, что CCD имеет более высокий приоритет и клиенту будет присвоен адрес, указанный в CCD-файле даже если у него есть уже привязка в ipp.txt.
И вот здесь нужно быть крайне осторожным, чтобы избежать конфликтов и неоднозначных ситуаций, если адреса в CCD-файлах и ipp.txt пересекаются.
Что будет, если указанный в CCD адрес уже занят? OpenVPN выдаст первый свободный и занесет запись в ipp.txt. А если окажется занят адрес, указанный в ipp.txt, то поиск по файлу продолжится и если там есть вторая запись, то будет выдан указанные в ней адрес. Нет – снова первый свободный с созданием дубля записи.
Впоследствии это может приводить к тому, что клиент начнет получать разные адреса в зависимости от условий подключения. Поэтому при появлении в ipp.txt дублирующихся записей следует внимательно изучить конфигурации клиентов.
👍27🥱5❤4🔥3
Учится ли iRU на своих ошибках?
Нет, не учится. В 2023 году мы писали про мини-ПК их производства на базе J1900, где установка 2,5” диска в штатный отсек приводила с резким ухудшением теплового режима с последующим выходом диска из строя.
Причины такого поведения просты – просчеты в проектировании системы охлаждения корпуса. В тот раз они использовали пассивную систему охлаждения и установленный диск просто перекрывал большую часть вентиляционных отверстий мгновенно ухудшая тепловой режим корпуса.
И вот сегодня просматривали с заказчиком варианты мини-ПК на N100 и снова столкнулись с моделью iRU 110ALCN. Что же мы видим? Снова пассивное охлаждение, хотя новый процессор горячий, существенно горячее предшественника.
И снова возможность установки SATA диска 2,5”, как вы думаете куда? Правильно, на дно корпуса, прямо над памятью и NVMe диском, полностью перекрыв для них циркуляцию воздух и попутно закрыв более половины вентиляционных отверстий внизу крышки.
После чего можно начинать делать ставки, кто первый отправится в страну вечной охоты от перегрева: штатный M.2 или установленный SATA.
Можно ли избежать такого сценария? При данной компоновке – нет, с пассивным охлаждением – тем более. Поэтому всегда обращайте внимание на такие моменты, а лучше вообще не используйте 2,5” диски в устройствах подобной компоновки, даже если их можно установить туда штатно.
Нет, не учится. В 2023 году мы писали про мини-ПК их производства на базе J1900, где установка 2,5” диска в штатный отсек приводила с резким ухудшением теплового режима с последующим выходом диска из строя.
Причины такого поведения просты – просчеты в проектировании системы охлаждения корпуса. В тот раз они использовали пассивную систему охлаждения и установленный диск просто перекрывал большую часть вентиляционных отверстий мгновенно ухудшая тепловой режим корпуса.
И вот сегодня просматривали с заказчиком варианты мини-ПК на N100 и снова столкнулись с моделью iRU 110ALCN. Что же мы видим? Снова пассивное охлаждение, хотя новый процессор горячий, существенно горячее предшественника.
И снова возможность установки SATA диска 2,5”, как вы думаете куда? Правильно, на дно корпуса, прямо над памятью и NVMe диском, полностью перекрыв для них циркуляцию воздух и попутно закрыв более половины вентиляционных отверстий внизу крышки.
После чего можно начинать делать ставки, кто первый отправится в страну вечной охоты от перегрева: штатный M.2 или установленный SATA.
Можно ли избежать такого сценария? При данной компоновке – нет, с пассивным охлаждением – тем более. Поэтому всегда обращайте внимание на такие моменты, а лучше вообще не используйте 2,5” диски в устройствах подобной компоновки, даже если их можно установить туда штатно.
👍28😁6❤4🤷♂4🔥1
DH Group на роутерах Mikrotik
Как показывает практика, что если с выбором шифров у многих обстоит еще более менее, то выбор группы Диффи-Хеллмана - вопрос гораздо более непонятный.
Начнем с начала. Алгоритм Диффи-Хеллмана, названный так по именам его разработчиков, применяется для реализации совершенной прямой секретности (PFS).
PFS предусматривает формирование уникальных сеансовых ключей для каждого сеанса, что не позволяет расшифровать трафик никому, кроме сторон сеанса, даже владельцу закрытого ключа.
Почему Диффи-Хеллман? Потому что данный протокол позволяет сторонам сформировать общий ключ шифрования не передавая его по каналам связи. Подробнее об этом можете прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Но вернемся к нашим Микротикам. В настоящий момент поддерживаются следующие Группы Диффи-Хеллмана:
В целом - чем больше номер группы, тем она надежнее. В настоящий момент группы 1 - 5 обладают малой длинной ключа и не считаются безопасными.
Отдельно следует сказать о группах 3 и 4 - использующийся в них алгоритм имеет уязвимости, поэтому данных групп следует избегать.
Последние рекомендации советуют для 128-битных шифров использовать группы 19 и 20, а для 256-битных и выше - 21 группу.
Несколько особняком стоит 31 группа на эллиптической кривой Curve25519, которая обладает более высокой скоростью работы и безопасности чем аналогичная 256-битная кривая NIST P-256 группы 19.
Отдельные источники ставят данную кривую на уровень группы 21 или немного лучше, при явно более высокой производительности. Поэтому если у вас только новые устройства, то Curve25519 будет лучшим выбором.
Но следует помнить, что шифрование - процесс обоюдный, поэтому группы DH следует выбирать с оглядкой на клиентов, которые могут не поддерживать выбранные вами группы.
Как показывает практика, что если с выбором шифров у многих обстоит еще более менее, то выбор группы Диффи-Хеллмана - вопрос гораздо более непонятный.
Начнем с начала. Алгоритм Диффи-Хеллмана, названный так по именам его разработчиков, применяется для реализации совершенной прямой секретности (PFS).
PFS предусматривает формирование уникальных сеансовых ключей для каждого сеанса, что не позволяет расшифровать трафик никому, кроме сторон сеанса, даже владельцу закрытого ключа.
Почему Диффи-Хеллман? Потому что данный протокол позволяет сторонам сформировать общий ключ шифрования не передавая его по каналам связи. Подробнее об этом можете прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Но вернемся к нашим Микротикам. В настоящий момент поддерживаются следующие Группы Диффи-Хеллмана:
Group 1 768 bits MODP group
Group 2 1024 bits MODP group
Group 3 EC2N group on GP(2^155)
Group 4 EC2N group on GP(2^185)
Group 5 1536 bits MODP group
Group 14 2048 bits MODP group
Group 15 3072 bits MODP group
Group 16 4096 bits MODP group
Group 17 6144 bits MODP group
Group 18 8192 bits MODP group
Group 19 256 bits random ECP group
Group 20 384 bits random ECP group
Group 21 521 bits random ECP group
Group 31 256 bits Curve25519
В целом - чем больше номер группы, тем она надежнее. В настоящий момент группы 1 - 5 обладают малой длинной ключа и не считаются безопасными.
Отдельно следует сказать о группах 3 и 4 - использующийся в них алгоритм имеет уязвимости, поэтому данных групп следует избегать.
Последние рекомендации советуют для 128-битных шифров использовать группы 19 и 20, а для 256-битных и выше - 21 группу.
Несколько особняком стоит 31 группа на эллиптической кривой Curve25519, которая обладает более высокой скоростью работы и безопасности чем аналогичная 256-битная кривая NIST P-256 группы 19.
Отдельные источники ставят данную кривую на уровень группы 21 или немного лучше, при явно более высокой производительности. Поэтому если у вас только новые устройства, то Curve25519 будет лучшим выбором.
Но следует помнить, что шифрование - процесс обоюдный, поэтому группы DH следует выбирать с оглядкой на клиентов, которые могут не поддерживать выбранные вами группы.
👍32👀6❤3🤮1
Как правильно «лечить» файловые базы 1С:Предприятие
Считается, что файловая база 1С:Предприятие – это несерьезно и только для самых маленьких, однако это не так, существует целый ряд решений, где применяются именно файловые базы.
В частности это фронтовые решения для торговли и общепита, такие как 1С:РМК или 1С:Касса, которые вообще не предусматривают клиент-серверный режим работы, а также и более взрослые конфигурации: 1С:Розница или 1С:РМК в режиме РИБ в качестве рабочего места кассира или локальной базы торговой точки.
Ну а любой, кто работает с файловой базой рано или поздно столкнется с сообщением Файл базы данных поврежден. Но страшно только в первый раз, обычно это сообщение не вызывает особых эмоций, так как ситуация, можно сказать, штатная.
Большинство пользователей знает, что исправить это состояние нам поможет утилита chdbfl.exe, которая находится в папке bin установленной платформы. Работать с ней не просто, а очень просто.
Прежде всего делаем резервную копию поврежденной базы. Так как база файловая, то просто копируем файл 1Cv8.1CD, затем запускам утилиту, указываем путь к обозначенному файлу, ставим флаг Исправлять обнаруженные ошибки и запускаем.
Утилита сама находит ошибки физической целостности файла базы данных и устраняет их. Кроме этого, она выполняет реструктуризацию базы и оптимизацию размещения системной информации, что благотворно влияет на ее быстродействие. Поэтому данную утилиту полезно запускать саму по себе, без ошибок.
Ошибки найдены и исправлены, бинго! Можно открывать базу и работать. Но не спешите это делать. Утилита исправила только физические ошибки, но с точки зрения логической целостности база может находиться в противоречивом состоянии.
Поэтому обязательно запускаем конфигуратор и выполняем в нем контроль логической целостности с исправлением ошибок, реструктуризацию можно не включать, это занимает время и не имеет особого смыла, потому что ее только что выполнила утилита chdbfl.exe.
Более подробно про Тестирование и исправление вы можете прочитать в нашей статье:
🔹 Тестирование и исправление информационной базы - что делает и для чего нужно
А бывает так, что утилита chdbfl.exe не показывает ошибок, а платформа все равно пишет, что конфигурация базы данных повреждена (или ошибку формата потока)? Бывает, в этом случае поврежденным оказывается кеш и его следует очистить.
При этом не следует поддаваться ошибочному представлению о работе кеша и чистить его при любых ошибках. Кеш серьезно улучшает производительность 1С, особенно на не очень мощных компьютерах и чистить его без особой необходимости не рекомендуется.
Считается, что файловая база 1С:Предприятие – это несерьезно и только для самых маленьких, однако это не так, существует целый ряд решений, где применяются именно файловые базы.
В частности это фронтовые решения для торговли и общепита, такие как 1С:РМК или 1С:Касса, которые вообще не предусматривают клиент-серверный режим работы, а также и более взрослые конфигурации: 1С:Розница или 1С:РМК в режиме РИБ в качестве рабочего места кассира или локальной базы торговой точки.
Ну а любой, кто работает с файловой базой рано или поздно столкнется с сообщением Файл базы данных поврежден. Но страшно только в первый раз, обычно это сообщение не вызывает особых эмоций, так как ситуация, можно сказать, штатная.
Большинство пользователей знает, что исправить это состояние нам поможет утилита chdbfl.exe, которая находится в папке bin установленной платформы. Работать с ней не просто, а очень просто.
Прежде всего делаем резервную копию поврежденной базы. Так как база файловая, то просто копируем файл 1Cv8.1CD, затем запускам утилиту, указываем путь к обозначенному файлу, ставим флаг Исправлять обнаруженные ошибки и запускаем.
Утилита сама находит ошибки физической целостности файла базы данных и устраняет их. Кроме этого, она выполняет реструктуризацию базы и оптимизацию размещения системной информации, что благотворно влияет на ее быстродействие. Поэтому данную утилиту полезно запускать саму по себе, без ошибок.
Ошибки найдены и исправлены, бинго! Можно открывать базу и работать. Но не спешите это делать. Утилита исправила только физические ошибки, но с точки зрения логической целостности база может находиться в противоречивом состоянии.
Поэтому обязательно запускаем конфигуратор и выполняем в нем контроль логической целостности с исправлением ошибок, реструктуризацию можно не включать, это занимает время и не имеет особого смыла, потому что ее только что выполнила утилита chdbfl.exe.
Более подробно про Тестирование и исправление вы можете прочитать в нашей статье:
🔹 Тестирование и исправление информационной базы - что делает и для чего нужно
А бывает так, что утилита chdbfl.exe не показывает ошибок, а платформа все равно пишет, что конфигурация базы данных повреждена (или ошибку формата потока)? Бывает, в этом случае поврежденным оказывается кеш и его следует очистить.
При этом не следует поддаваться ошибочному представлению о работе кеша и чистить его при любых ошибках. Кеш серьезно улучшает производительность 1С, особенно на не очень мощных компьютерах и чистить его без особой необходимости не рекомендуется.
👍36👀7🍌2❤1🥱1
Forwarded from Telega ✉️ Notifications
Бесплатно: 5 дней Python для новичков → 4 мини-проекта 🐍
Телеграм-боты, парсер данных в таблицу и простой сайт. Без математики, только практика.
Запись до 15 марта → тут
Реклама. ЧОУ ДПО "ОБРАЗОВАТЕЛЬНЫЕ ТЕХНОЛОГИИ "СКИЛБОКС (КОРОБКА НАВЫКОВ)". ИНН 9704088880.
Телеграм-боты, парсер данных в таблицу и простой сайт. Без математики, только практика.
Запись до 15 марта → тут
Реклама. ЧОУ ДПО "ОБРАЗОВАТЕЛЬНЫЕ ТЕХНОЛОГИИ "СКИЛБОКС (КОРОБКА НАВЫКОВ)". ИНН 9704088880.
🤮3
Media is too big
VIEW IN TELEGRAM
Эволюция энергосбережения в архитектуре x86 или что такое ACPI
История развития платформы x86 непрерывно связана с борьбой за энергосбережение. Особую актуальность этот вопрос приобрел в 90-е, когда начался стремительный рост таковых частот процессоров, вылившийся в конце десятилетия в «гонку гигагерц».
Процессоры постоянно становились быстрее, производительнее и горячее. Причем сильно так горячее, старожилы должны помнить бодрое видео, на котором снимают радиатор с работающих процессоров Intel или AMD.
И если Intel худо-бедно переживал такую ситуацию, то процессоры Athlon от AMD мгновенно сгорали. Это самое видео мы прикрепили к заметке. И с этим надо было что-то делать.
А чтобы понять, что именно нужно делать немного отвлечемся от компьютеров и вспомним физику. Тепловыделение процессора прямо пропорционально частоте работы процессора, но при этом имеет квадратичную зависимость от напряжения питания.
Если мы снизим на 25% частоту процессора на такое же значение снизится и потребление. А вот при снижении на 25% напряжения мы получим уже 44% экономии, а снизив одновременно и частоту, и напряжение получим целых 58% снижения потребления.
Понимать как в настоящий момент загружена ОС могла только операционная система и поэтому возникли вполне закономерные мысли, чтобы передать ей управление режимами работы процессора.
1️⃣ Для этого в 1996 году был принят стандарт ACPI 1.0, который вводил новые универсальные состояния системы.
🔹 Начнем с S-states (System states) – глобальные состояния всей платформы, которые подразумевали следующие варианты:
▫️ S0 — работа
▫️ S3 (Suspend to RAM) — сон с сохранением в памяти
▫️ S4 (Hibernate) — сохранение на диск
▫️ S5 — мягкое выключение (дежурный режим БП и доступен WoL)
🔹 Одновременно с ним вводились состояния простоя - C-states (CPU Idle states), которые существовали только внутри режима S0:
▫️ C0 — исполнение инструкций
▫️ C1 (Halt) — базовый простой с мгновенным пробуждением
▫️ C2/C3 — более глубокие состояния с отключением тактового генератора и кэшей
Последние режимы дают значительно большую экономию, но и увеличивают задержку пробуждения.
Все это было хорошо, но не решало проблемы энергосбережения в рабочем режиме, как только процессор выходил из состояния бездействия он начинал активно потреблять энергию вне зависимости от реальной нагрузки.
2️⃣ В ответ появились первые проприетарные технологии Intel SpeedStep (1999) и AMD PowerNow! (1999), которые умели управлять частотой и напряжением питания в зависимости от реальной нагрузки.
🔹 В результате в 2000 году появился новый стандарт ACPI 2.0, который ввел понятие P-state (CPU Performance States), которые существовали внутри уровня C0.
Первоначально предполагались:
▫️ P0 – полная производительность процессора
▫️ P1/P2 – энергосберегающие режимы со снижением частоты и напряжения процессора
В первом приближении это решило проблему неэффективного тепловыделения, теперь процессоры при низкой нагрузке и в простое могли уходить в энергоэффективные режимы, но особой гибкости здесь не было.
Процессор либо работал на полную, либо находился в одном из двух ограниченных режимов.
3️⃣ В 2004 году увидел свет стандарт ACPI 3.0, который ввел в прошивку BIOS таблицы DSDT, в которые вендором записывались все возможные сочетания частоты и напряжения, и система в зависимости от нагрузки могла выбирать один из них.
Здесь мы вплотную приблизились к современным платформам, которые большую часть времени пребывают в режиме низкой частоты и напряжения питания, обеспечивая отличную энергоэффективность, но при необходимости могут быстро нарастить производительность.
История развития платформы x86 непрерывно связана с борьбой за энергосбережение. Особую актуальность этот вопрос приобрел в 90-е, когда начался стремительный рост таковых частот процессоров, вылившийся в конце десятилетия в «гонку гигагерц».
Процессоры постоянно становились быстрее, производительнее и горячее. Причем сильно так горячее, старожилы должны помнить бодрое видео, на котором снимают радиатор с работающих процессоров Intel или AMD.
И если Intel худо-бедно переживал такую ситуацию, то процессоры Athlon от AMD мгновенно сгорали. Это самое видео мы прикрепили к заметке. И с этим надо было что-то делать.
А чтобы понять, что именно нужно делать немного отвлечемся от компьютеров и вспомним физику. Тепловыделение процессора прямо пропорционально частоте работы процессора, но при этом имеет квадратичную зависимость от напряжения питания.
Если мы снизим на 25% частоту процессора на такое же значение снизится и потребление. А вот при снижении на 25% напряжения мы получим уже 44% экономии, а снизив одновременно и частоту, и напряжение получим целых 58% снижения потребления.
Понимать как в настоящий момент загружена ОС могла только операционная система и поэтому возникли вполне закономерные мысли, чтобы передать ей управление режимами работы процессора.
1️⃣ Для этого в 1996 году был принят стандарт ACPI 1.0, который вводил новые универсальные состояния системы.
🔹 Начнем с S-states (System states) – глобальные состояния всей платформы, которые подразумевали следующие варианты:
▫️ S0 — работа
▫️ S3 (Suspend to RAM) — сон с сохранением в памяти
▫️ S4 (Hibernate) — сохранение на диск
▫️ S5 — мягкое выключение (дежурный режим БП и доступен WoL)
🔹 Одновременно с ним вводились состояния простоя - C-states (CPU Idle states), которые существовали только внутри режима S0:
▫️ C0 — исполнение инструкций
▫️ C1 (Halt) — базовый простой с мгновенным пробуждением
▫️ C2/C3 — более глубокие состояния с отключением тактового генератора и кэшей
Последние режимы дают значительно большую экономию, но и увеличивают задержку пробуждения.
Все это было хорошо, но не решало проблемы энергосбережения в рабочем режиме, как только процессор выходил из состояния бездействия он начинал активно потреблять энергию вне зависимости от реальной нагрузки.
2️⃣ В ответ появились первые проприетарные технологии Intel SpeedStep (1999) и AMD PowerNow! (1999), которые умели управлять частотой и напряжением питания в зависимости от реальной нагрузки.
🔹 В результате в 2000 году появился новый стандарт ACPI 2.0, который ввел понятие P-state (CPU Performance States), которые существовали внутри уровня C0.
Первоначально предполагались:
▫️ P0 – полная производительность процессора
▫️ P1/P2 – энергосберегающие режимы со снижением частоты и напряжения процессора
В первом приближении это решило проблему неэффективного тепловыделения, теперь процессоры при низкой нагрузке и в простое могли уходить в энергоэффективные режимы, но особой гибкости здесь не было.
Процессор либо работал на полную, либо находился в одном из двух ограниченных режимов.
3️⃣ В 2004 году увидел свет стандарт ACPI 3.0, который ввел в прошивку BIOS таблицы DSDT, в которые вендором записывались все возможные сочетания частоты и напряжения, и система в зависимости от нагрузки могла выбирать один из них.
Здесь мы вплотную приблизились к современным платформам, которые большую часть времени пребывают в режиме низкой частоты и напряжения питания, обеспечивая отличную энергоэффективность, но при необходимости могут быстро нарастить производительность.
👍39🔥15⚡2🤮2👌2
Полезный инструмент для работы с DNS-записями
Каждый администратор сталкивается с тем, что время от времени ему приходится проверять настройки DNS-записей для доменов, а также контролировать процесс их изменения.
Обычно для этого используется консольная утилита nslookup, но есть и иные способы, например, использовать онлайн-инструмент https://dnschecker.org.
В первую очередь он удобен при изменении записей домена, когда вам нужно проконтролировать процесс изменения на различных DNS-серверах. Теперь не нужно опрашивать каждый, просто запускаете проверку на главной странице.
В результате вы увидите какую информацию о вашем домене возвращаются различные публичные сервера в разных частях планеты. При необходимости список можно отредактировать по своему усмотрению.
Проверки доступны для всех основных типов записей, так что вы можете контролировать не только изменения A-записи, но и любых других.
Также сервис содержит ряд иных инструментов для работы с DNS-записями, IP-адресами, сетями, разработкой сайтов и т.д.
С его помощью можно легко выполнить все основные проверки DNS, наличие домена или адреса в черных списках, проанализировать заголовки почты и т.д.
В целом ничего уникального, сайтов с такими проверками много, но здесь все в одном месте. Но основная ценность ресурса – это именно быстрая проверка записей на множестве серверов, что делает его удобным инструментом контроля изменений.
Каждый администратор сталкивается с тем, что время от времени ему приходится проверять настройки DNS-записей для доменов, а также контролировать процесс их изменения.
Обычно для этого используется консольная утилита nslookup, но есть и иные способы, например, использовать онлайн-инструмент https://dnschecker.org.
В первую очередь он удобен при изменении записей домена, когда вам нужно проконтролировать процесс изменения на различных DNS-серверах. Теперь не нужно опрашивать каждый, просто запускаете проверку на главной странице.
В результате вы увидите какую информацию о вашем домене возвращаются различные публичные сервера в разных частях планеты. При необходимости список можно отредактировать по своему усмотрению.
Проверки доступны для всех основных типов записей, так что вы можете контролировать не только изменения A-записи, но и любых других.
Также сервис содержит ряд иных инструментов для работы с DNS-записями, IP-адресами, сетями, разработкой сайтов и т.д.
С его помощью можно легко выполнить все основные проверки DNS, наличие домена или адреса в черных списках, проанализировать заголовки почты и т.д.
В целом ничего уникального, сайтов с такими проверками много, но здесь все в одном месте. Но основная ценность ресурса – это именно быстрая проверка записей на множестве серверов, что делает его удобным инструментом контроля изменений.
1👍38❤4🥱3🤝1
Работа с картинками в веб-сервере Angie (Nginx)
Без изображений сегодня не обходится ни один современный веб-ресурс и в тоже время изображения могут оказаться самой тяжеловесной частью сайта и серьезно замедлять его работу.
Конечно, работу с изображениями лучше построить еще на этапе подготовки материалов, но не всегда это возможно, особенно если за публикацию материалов отвечают технически неграмотные сотрудники, которые могут разместить на сайте полноразмерные картинки без оптимизации.
В этом случае ничего не остается, как обрабатывать изображения на самом веб-сервере и тут нам поможет Angie, который является более продвинутым форком Nginx (хотя вы можете использовать и последний).
Почему именно Angie? Да потому что он имеет в репозитории уже скомпилированные модули и вам не нужно пересобирать веб-сервер вручную, а также модуль для работы с изображениями у него поддерживает форматы JPEG, GIF, PNG, WebP, HEIC и AVIF, в то время как Nginx ограничен JPEG, GIF, PNG и WebP.
Данный модуль называется http_image_filter_module и для его установки вам понадобится команда:
Версию библиотеки libgd уточните для своего дистрибутива и именно от нее зависит набор поддерживаемых форматов.
Пример конфигурации:
В нашем примере изображения из локации /img пропорционально будут уменьшены до размера 800*600 так, чтобы обе стороны не превышали указанные размеры.
После чего изображение будет повернуто против часовой стрелки на 90 градусов, поддерживаются значения 90 – 180 -270.
При совместном использовании с resize поворот происходит после изменения размера.
Вместо resize можно использовать опцию crop:
В этом случае изображение будет уменьшено по большей стороне, а оставшиеся края обрезаны.
При использовании совместно с вращением, поворот происходит перед обрезкой.
Для конвертации формата используйте:
Где в качестве type укажите jpeg, gif, png, webp, heic или avif, однако помните, что онлайн-конвертация, особенно современных форматов может оказывать высокую нагрузку на процессор и занимать длительное время.
Чтобы процесс случайно не съел всю оперативную память можете использовать лимит буфера загрузки изображения:
Также можно поиграть форматами качества, изменив соответствующие опции, которые по умолчанию имеют значения:
Для AVIF второй параметр является необязательным и указывает на скорость кодирования.
При возникновении ошибок обработки: неподдерживаемый формат, неправильное расширение, превышение размера буфера и т.д. сервер выдаст ошибку 415 и отдаст картинку-заглушку empty_gif.
Сразу отметим один момент, empty_gif - это встроенная директива, которая возвращает 1×1 прозрачное GIF-изображение чтобы не ломать правильное формирование страницы на клиенте. Т.е. никаких дополнительных изображений-заглушек нигде размещать не нужно.
Тоже самое произойдет, если вы попытаетесь обработать формат не поддерживаемый http_image_filter_module или libgd.
Как видим, ничего сложного нет. Но еще раз напомним, что работа с изображениями – процесс ресурсоемкий и на стороне веб-сервера его следует всячески избегать.
Без изображений сегодня не обходится ни один современный веб-ресурс и в тоже время изображения могут оказаться самой тяжеловесной частью сайта и серьезно замедлять его работу.
Конечно, работу с изображениями лучше построить еще на этапе подготовки материалов, но не всегда это возможно, особенно если за публикацию материалов отвечают технически неграмотные сотрудники, которые могут разместить на сайте полноразмерные картинки без оптимизации.
В этом случае ничего не остается, как обрабатывать изображения на самом веб-сервере и тут нам поможет Angie, который является более продвинутым форком Nginx (хотя вы можете использовать и последний).
Почему именно Angie? Да потому что он имеет в репозитории уже скомпилированные модули и вам не нужно пересобирать веб-сервер вручную, а также модуль для работы с изображениями у него поддерживает форматы JPEG, GIF, PNG, WebP, HEIC и AVIF, в то время как Nginx ограничен JPEG, GIF, PNG и WebP.
Данный модуль называется http_image_filter_module и для его установки вам понадобится команда:
apt install angie-module-image-filter libgd3
Версию библиотеки libgd уточните для своего дистрибутива и именно от нее зависит набор поддерживаемых форматов.
Пример конфигурации:
location /img/ {
proxy_pass http://backend;
image_filter resize 800 600;
image_filter rotate 90;
error_page 415 = /empty;
}
location = /empty {
empty_gif;
}В нашем примере изображения из локации /img пропорционально будут уменьшены до размера 800*600 так, чтобы обе стороны не превышали указанные размеры.
После чего изображение будет повернуто против часовой стрелки на 90 градусов, поддерживаются значения 90 – 180 -270.
При совместном использовании с resize поворот происходит после изменения размера.
Вместо resize можно использовать опцию crop:
image_filter crop 800 600;
В этом случае изображение будет уменьшено по большей стороне, а оставшиеся края обрезаны.
При использовании совместно с вращением, поворот происходит перед обрезкой.
Для конвертации формата используйте:
image_filter convert type
Где в качестве type укажите jpeg, gif, png, webp, heic или avif, однако помните, что онлайн-конвертация, особенно современных форматов может оказывать высокую нагрузку на процессор и занимать длительное время.
Чтобы процесс случайно не съел всю оперативную память можете использовать лимит буфера загрузки изображения:
image_filter_buffer 64M;
Также можно поиграть форматами качества, изменив соответствующие опции, которые по умолчанию имеют значения:
image_filter_jpeg_quality 75;
image_filter_webp_quality 80;
image_filter_heic_quality 80;
image_filter_avif_quality 80 6;
Для AVIF второй параметр является необязательным и указывает на скорость кодирования.
При возникновении ошибок обработки: неподдерживаемый формат, неправильное расширение, превышение размера буфера и т.д. сервер выдаст ошибку 415 и отдаст картинку-заглушку empty_gif.
Сразу отметим один момент, empty_gif - это встроенная директива, которая возвращает 1×1 прозрачное GIF-изображение чтобы не ломать правильное формирование страницы на клиенте. Т.е. никаких дополнительных изображений-заглушек нигде размещать не нужно.
Тоже самое произойдет, если вы попытаетесь обработать формат не поддерживаемый http_image_filter_module или libgd.
Как видим, ничего сложного нет. Но еще раз напомним, что работа с изображениями – процесс ресурсоемкий и на стороне веб-сервера его следует всячески избегать.
👍29🤔2🤮2❤1
Когда DNS использует UDP, а когда TCP?
Чтобы правильно ответить на этот вопрос обратимся к RFC5966, который говорит, что TCP используется для трансфера зон или ответов, размер которых превышает 512 байт.
С трансфером зон все понятно, здесь нам требуется обеспечить максимальную целостность данных, поэтому целесообразно использовать TCP, даже в ущерб скорости и производительности.
А вот что такое ограничение на 512 байт и откуда оно взялось? Это связано с техническими ограничениями протокола UDP и обеспечением обратной совместимости. Проще говоря, если мы хотим быть уверенными, что любой узел сможет получить DNS-ответ по UDP, его размер не должен превышать 512 байт.
В противном случае сервер должен перейти на использование протокола TCP, либо клиент получит усеченный ответ (то, что поместится в 512 байт).
А теперь о том, какие именно записи могут превышать 512 байт:
🔸 Многочисленные записи: если запрашивается доменное имя, которое имеет много A-записей или AAAA-записей размер ответа может превышать 512 байт.
🔸 Записи типа MX: также могут возвращать несколько записей для почтовых серверов обслуживающих домен.
🔸 Записи типа CNAME: могут указывать на доменные имена, которые имеют многочисленные А-записи
🔸 DNSSEC: в этом случае дополнительные криптографические записи (RRSIG, DNSKEY) могут значительно увеличить размер ответа.
🔸 Дополнительные записи: например, NS, TXT или SRV записи, которые могут быть многочисленными и иметь достаточно большой размер.
Однако использование TCP в данном случае не является обязательным, существуют расширения протокола DNS - EDNS0, в рамках которого резолвер может в запросе указать какой размер ответа он может принять через UDP и сервер отправит ему такой ответ даже если его размер превышает 512 байт.
❓Кто должен поддерживать TCP? Согласно стандарту, все реализации должны поддерживать оба протокола, но есть и более строгие требования.
Стандарт требует обязательной поддержки от:
🔸 Авторитативного сервера, хранящего зону для ее возможной передачи тому, кто имеет право ее запросить
🔸 Рекурсивных серверов и форвардеров, для того чтобы они могли передавать большие ответы от серверов клиентам.
🔸 Конечных DNS-клиентов (реализаций в ОС и т.д.) – для возможности принимать не усечённые запросы.
Однако в отношении последних есть некоторые послабления, стандарт разрешает не реализовывать поддержку TCP для специализированных или маломощных устройств, если заранее известны все возможные DNS-ответы и среди них не будет превышающих 512 бит, либо получение усеченных ответов не влияет на нормальное функционирование системы.
Что это может быть? Например, какой-нибудь интернет ларек или касса самообслуживания. Когда мы знаем все возможные DNS-запросы и знаем все ответы на них.
Либо если нас интересует сугубо интернет-серфинг и не предполагаем никаких запросов кроме записей типа А, в этом случае даже если мы получим усеченный ответ это никак не помешает нормальной работе.
Также стандарт устанавливает порядок использования протоколов. Резолвер прежде всего должен попытаться выполнить UDP-запрос, должен, но не обязан.
Если он предполагает, что с большой вероятностью будет получен ответ большого размера, то он имеет право сразу перейти на использование протокола TCP.
В случае если TCP-соединение с сервером уже установлено, то клиент может продолжать его использовать не возвращаясь на протокол UDP.
Чтобы правильно ответить на этот вопрос обратимся к RFC5966, который говорит, что TCP используется для трансфера зон или ответов, размер которых превышает 512 байт.
С трансфером зон все понятно, здесь нам требуется обеспечить максимальную целостность данных, поэтому целесообразно использовать TCP, даже в ущерб скорости и производительности.
А вот что такое ограничение на 512 байт и откуда оно взялось? Это связано с техническими ограничениями протокола UDP и обеспечением обратной совместимости. Проще говоря, если мы хотим быть уверенными, что любой узел сможет получить DNS-ответ по UDP, его размер не должен превышать 512 байт.
В противном случае сервер должен перейти на использование протокола TCP, либо клиент получит усеченный ответ (то, что поместится в 512 байт).
А теперь о том, какие именно записи могут превышать 512 байт:
🔸 Многочисленные записи: если запрашивается доменное имя, которое имеет много A-записей или AAAA-записей размер ответа может превышать 512 байт.
🔸 Записи типа MX: также могут возвращать несколько записей для почтовых серверов обслуживающих домен.
🔸 Записи типа CNAME: могут указывать на доменные имена, которые имеют многочисленные А-записи
🔸 DNSSEC: в этом случае дополнительные криптографические записи (RRSIG, DNSKEY) могут значительно увеличить размер ответа.
🔸 Дополнительные записи: например, NS, TXT или SRV записи, которые могут быть многочисленными и иметь достаточно большой размер.
Однако использование TCP в данном случае не является обязательным, существуют расширения протокола DNS - EDNS0, в рамках которого резолвер может в запросе указать какой размер ответа он может принять через UDP и сервер отправит ему такой ответ даже если его размер превышает 512 байт.
❓Кто должен поддерживать TCP? Согласно стандарту, все реализации должны поддерживать оба протокола, но есть и более строгие требования.
Стандарт требует обязательной поддержки от:
🔸 Авторитативного сервера, хранящего зону для ее возможной передачи тому, кто имеет право ее запросить
🔸 Рекурсивных серверов и форвардеров, для того чтобы они могли передавать большие ответы от серверов клиентам.
🔸 Конечных DNS-клиентов (реализаций в ОС и т.д.) – для возможности принимать не усечённые запросы.
Однако в отношении последних есть некоторые послабления, стандарт разрешает не реализовывать поддержку TCP для специализированных или маломощных устройств, если заранее известны все возможные DNS-ответы и среди них не будет превышающих 512 бит, либо получение усеченных ответов не влияет на нормальное функционирование системы.
Что это может быть? Например, какой-нибудь интернет ларек или касса самообслуживания. Когда мы знаем все возможные DNS-запросы и знаем все ответы на них.
Либо если нас интересует сугубо интернет-серфинг и не предполагаем никаких запросов кроме записей типа А, в этом случае даже если мы получим усеченный ответ это никак не помешает нормальной работе.
Также стандарт устанавливает порядок использования протоколов. Резолвер прежде всего должен попытаться выполнить UDP-запрос, должен, но не обязан.
Если он предполагает, что с большой вероятностью будет получен ответ большого размера, то он имеет право сразу перейти на использование протокола TCP.
В случае если TCP-соединение с сервером уже установлено, то клиент может продолжать его использовать не возвращаясь на протокол UDP.
👍35❤4
Слона надо есть по частям
Время от времени нам задают вопросы типа: «Вот настроил по вашему (или любому другому) мануалу и не работает». На уточняющий вопрос что именно не работает обычно ответа нет, не работает – и все тут.
И вот здесь всплывает одна большая ошибка – попытка сделать все и сразу. В итоге получаем один сплошной черный ящик, который просто не работает.
Обычно после этого идут искать следующий мануал, потом снова следующий и так пока повезет.
Но для специалиста этот метод не подходит, как минимум по тому, что специалист умеет думать и обладает навыками логического мышления.
Поэтому любую сложную систему всегда надо разбивать на более простые подсистемы, а их сами на составляющие части или этапы настройки, каждый из которых должен иметь собственные контрольные показатели, по которым можно оценить правильность работы узла.
После чего процесс настройки системы перестанет быть квестом со многими неизвестными, а станет последовательным процессом и если у вас возникнут затруднения, то вы будете твердо понимать на каком этапе они возникли.
После чего если вам и придется гуглить, то уже не еще один мануал, а подробности настройки именно этого узла. Вполне возможно автор просто не упомянул о какой-то общеизвестной настройке, которую вы не знали.
Отсюда следует еще одна тонкость: если вы взялись настраивать что-то сложнее базового уровня, то поищите и изучите статьи по базовой настройке, лучше всего от того же самого автора. Так как там могут быть некоторые неявные особенности, на которые опираются более узкие статьи и которых вы могли не знать.
Это избавит вас от долгих поисков «рабочего мануала» и поможет систематизировать знания в данной области.
Следует понимать, что уровни технических статей бывают разные. В базовых статьях читателя ведут за ручку, поясняя все явные и неявные моменты. В статьях более высокого уровня подразумевается, что читатель владеет предметом на уровне базовой статьи и поэтому многие моменты опускаются, либо остаются без разъяснений.
Тоже самое касается и уже готовых систем, в которых вы ищете неисправности. Любую сложную систему можно представить в качестве набора более простых сервисов, которые имеют определенные зависимости друг от друга или совместно влияют на итоговый результат.
Если вы не понимаете, что происходит и как это все работает, то начните именно с составления такой схемы.
После чего выявите ключевые узлы и начните их проверку. После чего ваша задача сведется к тому, чтобы найти проблемный узел и локализовать проблему.
Дальше проще, потому что вместо вопроса «у меня ничего не работает» у вас будет вопрос «у меня не работает служба А», что серьезно сужает круг поиска и позволяет гораздо быстрее получить ответ в профильных сообществах.
Также не забывайте повышать собственный уровень знаний, соберите лабораторию и задайте себе вопрос «а что будет если…», после чего тут же реализуйте это самое если. При этом не избегайте самых нереальных и «дурацких» сценариев, потому что в жизни может случиться всякое. А чем лучше вы знаете систему, тем проще будет решать насущные задачи.
Но в любом случае следуйте главному принципу: любая сложная система должна быть разобрана вами на простые кубики, после чего должно быть изучено как эти кубики взаимодействуют друг с другом и как влияют на общую работу системы.
Время от времени нам задают вопросы типа: «Вот настроил по вашему (или любому другому) мануалу и не работает». На уточняющий вопрос что именно не работает обычно ответа нет, не работает – и все тут.
И вот здесь всплывает одна большая ошибка – попытка сделать все и сразу. В итоге получаем один сплошной черный ящик, который просто не работает.
Обычно после этого идут искать следующий мануал, потом снова следующий и так пока повезет.
Но для специалиста этот метод не подходит, как минимум по тому, что специалист умеет думать и обладает навыками логического мышления.
Поэтому любую сложную систему всегда надо разбивать на более простые подсистемы, а их сами на составляющие части или этапы настройки, каждый из которых должен иметь собственные контрольные показатели, по которым можно оценить правильность работы узла.
После чего процесс настройки системы перестанет быть квестом со многими неизвестными, а станет последовательным процессом и если у вас возникнут затруднения, то вы будете твердо понимать на каком этапе они возникли.
После чего если вам и придется гуглить, то уже не еще один мануал, а подробности настройки именно этого узла. Вполне возможно автор просто не упомянул о какой-то общеизвестной настройке, которую вы не знали.
Отсюда следует еще одна тонкость: если вы взялись настраивать что-то сложнее базового уровня, то поищите и изучите статьи по базовой настройке, лучше всего от того же самого автора. Так как там могут быть некоторые неявные особенности, на которые опираются более узкие статьи и которых вы могли не знать.
Это избавит вас от долгих поисков «рабочего мануала» и поможет систематизировать знания в данной области.
Следует понимать, что уровни технических статей бывают разные. В базовых статьях читателя ведут за ручку, поясняя все явные и неявные моменты. В статьях более высокого уровня подразумевается, что читатель владеет предметом на уровне базовой статьи и поэтому многие моменты опускаются, либо остаются без разъяснений.
Тоже самое касается и уже готовых систем, в которых вы ищете неисправности. Любую сложную систему можно представить в качестве набора более простых сервисов, которые имеют определенные зависимости друг от друга или совместно влияют на итоговый результат.
Если вы не понимаете, что происходит и как это все работает, то начните именно с составления такой схемы.
После чего выявите ключевые узлы и начните их проверку. После чего ваша задача сведется к тому, чтобы найти проблемный узел и локализовать проблему.
Дальше проще, потому что вместо вопроса «у меня ничего не работает» у вас будет вопрос «у меня не работает служба А», что серьезно сужает круг поиска и позволяет гораздо быстрее получить ответ в профильных сообществах.
Также не забывайте повышать собственный уровень знаний, соберите лабораторию и задайте себе вопрос «а что будет если…», после чего тут же реализуйте это самое если. При этом не избегайте самых нереальных и «дурацких» сценариев, потому что в жизни может случиться всякое. А чем лучше вы знаете систему, тем проще будет решать насущные задачи.
Но в любом случае следуйте главному принципу: любая сложная система должна быть разобрана вами на простые кубики, после чего должно быть изучено как эти кубики взаимодействуют друг с другом и как влияют на общую работу системы.
👍38❤4🤮2
А что тут грузят?
А грузят тут дисковый накопитель IBM 350, который хранил около 5 миллионов 6-битных символов (примерно 3,75–5 МБ), используя 50 дисков диаметром 24 дюйма (61 см), вращающихся на 1200 об/мин, с двумя независимыми манипуляторами для чтения/записи.
Весило все это добро более 1 тонны и требовало с собой особого обращения.
Цена на тот момент составляла от $9 200 или в современных ценах $106 200.
А грузят тут дисковый накопитель IBM 350, который хранил около 5 миллионов 6-битных символов (примерно 3,75–5 МБ), используя 50 дисков диаметром 24 дюйма (61 см), вращающихся на 1200 об/мин, с двумя независимыми манипуляторами для чтения/записи.
Весило все это добро более 1 тонны и требовало с собой особого обращения.
Цена на тот момент составляла от $9 200 или в современных ценах $106 200.
1🔥27👍10🤣3❤2🤔1
Ubuntu Cleaner – простой и удобный инструмент для очистки системы
Многие обычные пользователи Linux сетуют на отсутствие простых и привычных инструментов обслуживания системы. И эти претензии во многом обоснованы.
Поэтому всегда интересны простые утилиты, которые можно дать в руки обычному пользователю не боясь, что он что-то испортит, но при этом сможет эффективно пользоваться по назначению.
🔸 Ubuntu Cleaner – одна из таких утилит. Ее предназначение – очистка дискового пространства в системе, т.е. одна из наиболее часто востребованных функций, особенно сейчас, с ростом цен на твердотельные накопители.
По своему интерфейсу она похожа на привычные пользователям Windows программы и позволяет безопасно очистить все то, что можно безопасно удалить для очистки места.
Для установки вам потребуется подключить PPA-репозиторий или скачать DEB-пакет со страницы разработчика: https://github.com/gerardpuig/ubuntu-cleaner
Для установки через PPA выполните:
После чего ярлык программы появится в стартовом меню и можно пользоваться. Программа способна очищать кеши бразуеров, кеш картинок файлового менеджера, кеш APT, удалять старые ядра, неиспользуемые пакеты и неиспользуемые файлы конфигурации.
Последнее тоже полезно, так как часто пользователи, накосячив с программой, пытаются по старой привычке ее переустановить и сильно недоумевают, почему это не принесло желаемого эффекта.
Из поддерживаемых систем заявлена Ubuntu, но по идее программа должна работать на любом совместимом дистрибутиве на базе Debian.
Многие обычные пользователи Linux сетуют на отсутствие простых и привычных инструментов обслуживания системы. И эти претензии во многом обоснованы.
Поэтому всегда интересны простые утилиты, которые можно дать в руки обычному пользователю не боясь, что он что-то испортит, но при этом сможет эффективно пользоваться по назначению.
🔸 Ubuntu Cleaner – одна из таких утилит. Ее предназначение – очистка дискового пространства в системе, т.е. одна из наиболее часто востребованных функций, особенно сейчас, с ростом цен на твердотельные накопители.
По своему интерфейсу она похожа на привычные пользователям Windows программы и позволяет безопасно очистить все то, что можно безопасно удалить для очистки места.
Для установки вам потребуется подключить PPA-репозиторий или скачать DEB-пакет со страницы разработчика: https://github.com/gerardpuig/ubuntu-cleaner
Для установки через PPA выполните:
apt install software-properties-common
add-apt-repository ppa:gerardpuig/ppa
apt update
apt install ubuntu-cleaner
После чего ярлык программы появится в стартовом меню и можно пользоваться. Программа способна очищать кеши бразуеров, кеш картинок файлового менеджера, кеш APT, удалять старые ядра, неиспользуемые пакеты и неиспользуемые файлы конфигурации.
Последнее тоже полезно, так как часто пользователи, накосячив с программой, пытаются по старой привычке ее переустановить и сильно недоумевают, почему это не принесло желаемого эффекта.
Из поддерживаемых систем заявлена Ubuntu, но по идее программа должна работать на любом совместимом дистрибутиве на базе Debian.
🤡9👍1
GigaCode – теперь полноценный агентский режим
Мы уже рассказывали про ИИ-помощник GigaCode (https://t.me/interface31/5274), который можно было подключить как плагин в популярную среду разработки VS Code и заставить искусственный интеллект помогать нам с написанием кода.
В целом мы остались им довольны, но ситуацию существенно омрачало то, что у GigaCode не было агентского режима, т.е. он не мог вместе с вами смотреть в реальный код проекта, вносить туда изменения и считывать то, что вы решили поменять руками.
Но плюсы тоже были существенные. Во-первых, это бесплатно, без видимых лимитов. Т.е. если вы пока не понимаете, нужен ли вам ИИ-помощник – самое время попробовать. Да и вообще понять, что такое вайб-кодинг.
Во-вторых, это отечественный сервис и проблемы доступа или возможной оплаты тут не стоят. Напомним, что доступ к большинству ИИ моделей блокирует не наше ведомство из трех букв, а сами операторы ИИ, потому что санкции.
В общем уже тогда GigaCode был неплох, а вот теперь в него завезли агентский режим, для этого просто достаточно обновить расширение в VS Code.
Да, теперь у нас совершенно бесплатно есть младший брат Cursor, который позволяет работать в привычном режиме и это до сих пор бесплатно.
Почему младший брат? Потому что модель GigaCode все-таки еще слабовата, на популярных языках она довольно неплохо и бодро пишет код, но часто допускает ошибки, местами совсем детские, но сама же их быстро исправляет.
По собственным ощущениям GigaCode отстает где-то года на полтора-два. Тогда все популярные модели вели себя именно так, но это дело наживное и всегда лучше хоть плохо, но ехать, нежели хорошо стоять.
Теперь, когда появился агентский режим, мы можем взаимодействовать с нейросетью привычным образом и не отвлекаться на всякую постороннюю ерунду, типа копирования кода туда-сюда.
Для проверки мы решили создать проект с нуля, исключительно силами GigaCode, для этого создали в VS Code новое рабочее пространство и коротко, обычным языком описали агенту чего мы хотим, а захотелось нам скрипт на PowerShell.
Агент сам создал файл и бодро накидал костяк кода, причем достаточно грамотно, разделив его на функции и основной поток. В простых случаях это обычно излишне, но если проект начнет расти, то спагетти-код станет проблемой.
Ошибки, к сожалению, он все также допускает, часть из них глупые и сам VS Code предлагает их исправить. Но мы просто скопировали текст ошибки в чат с агентом, и он сам прекрасно все сделал.
Неуместной инициативой агент не страдает, но в комментариях к коду указывает на ключевые особенности. Также можно попросить его пояснить как этот код запустить и отладить, тоже поможет, выдав в чат готовые команды.
Итак, базовый скелет есть, надо обшивать его мясом. Снова говорим, чего мы хотим, а хотим мы проверку, о которой, кстати, сам GigaCode нас предупредил. Ок, проверку он быстро написал.
Запускаем, смотрим, все хорошо, но в выводе много лишнего, что испугает и запутает пользователя, поэтому мы просто копируем вывод и просим убрать из него лишнее, абсолютно не поясняя что именно.
Помощник понимает нас правильно и быстро делает то, что нам нужно. Т.е. вам не нужно давать ему подробные ТЗ, достаточно ставить задачи простым, естественным языком, как будто вы общаетесь с коллегой.
Нет, это не что-то новое, все агенты это умеют, но нам важно было проверить, что агент GigaCode тоже погружен в контекст и умеет понимать вас без уточнений, буквально с полуслова.
Прошлую заметку мы писали в конце ноября прошлого года, с тех пор GigaCode проделал неплохой путь и серьезно прокачал свои возможности. Ну и денег за это пока не берут. Поэтому все, кто хотел попробовать вайб-кодинг или разработку с агентом могут это сделать прямо сейчас.
Мы уже рассказывали про ИИ-помощник GigaCode (https://t.me/interface31/5274), который можно было подключить как плагин в популярную среду разработки VS Code и заставить искусственный интеллект помогать нам с написанием кода.
В целом мы остались им довольны, но ситуацию существенно омрачало то, что у GigaCode не было агентского режима, т.е. он не мог вместе с вами смотреть в реальный код проекта, вносить туда изменения и считывать то, что вы решили поменять руками.
Но плюсы тоже были существенные. Во-первых, это бесплатно, без видимых лимитов. Т.е. если вы пока не понимаете, нужен ли вам ИИ-помощник – самое время попробовать. Да и вообще понять, что такое вайб-кодинг.
Во-вторых, это отечественный сервис и проблемы доступа или возможной оплаты тут не стоят. Напомним, что доступ к большинству ИИ моделей блокирует не наше ведомство из трех букв, а сами операторы ИИ, потому что санкции.
В общем уже тогда GigaCode был неплох, а вот теперь в него завезли агентский режим, для этого просто достаточно обновить расширение в VS Code.
Да, теперь у нас совершенно бесплатно есть младший брат Cursor, который позволяет работать в привычном режиме и это до сих пор бесплатно.
Почему младший брат? Потому что модель GigaCode все-таки еще слабовата, на популярных языках она довольно неплохо и бодро пишет код, но часто допускает ошибки, местами совсем детские, но сама же их быстро исправляет.
По собственным ощущениям GigaCode отстает где-то года на полтора-два. Тогда все популярные модели вели себя именно так, но это дело наживное и всегда лучше хоть плохо, но ехать, нежели хорошо стоять.
Теперь, когда появился агентский режим, мы можем взаимодействовать с нейросетью привычным образом и не отвлекаться на всякую постороннюю ерунду, типа копирования кода туда-сюда.
Для проверки мы решили создать проект с нуля, исключительно силами GigaCode, для этого создали в VS Code новое рабочее пространство и коротко, обычным языком описали агенту чего мы хотим, а захотелось нам скрипт на PowerShell.
Агент сам создал файл и бодро накидал костяк кода, причем достаточно грамотно, разделив его на функции и основной поток. В простых случаях это обычно излишне, но если проект начнет расти, то спагетти-код станет проблемой.
Ошибки, к сожалению, он все также допускает, часть из них глупые и сам VS Code предлагает их исправить. Но мы просто скопировали текст ошибки в чат с агентом, и он сам прекрасно все сделал.
Неуместной инициативой агент не страдает, но в комментариях к коду указывает на ключевые особенности. Также можно попросить его пояснить как этот код запустить и отладить, тоже поможет, выдав в чат готовые команды.
Итак, базовый скелет есть, надо обшивать его мясом. Снова говорим, чего мы хотим, а хотим мы проверку, о которой, кстати, сам GigaCode нас предупредил. Ок, проверку он быстро написал.
Запускаем, смотрим, все хорошо, но в выводе много лишнего, что испугает и запутает пользователя, поэтому мы просто копируем вывод и просим убрать из него лишнее, абсолютно не поясняя что именно.
Помощник понимает нас правильно и быстро делает то, что нам нужно. Т.е. вам не нужно давать ему подробные ТЗ, достаточно ставить задачи простым, естественным языком, как будто вы общаетесь с коллегой.
Нет, это не что-то новое, все агенты это умеют, но нам важно было проверить, что агент GigaCode тоже погружен в контекст и умеет понимать вас без уточнений, буквально с полуслова.
Прошлую заметку мы писали в конце ноября прошлого года, с тех пор GigaCode проделал неплохой путь и серьезно прокачал свои возможности. Ну и денег за это пока не берут. Поэтому все, кто хотел попробовать вайб-кодинг или разработку с агентом могут это сделать прямо сейчас.
👍31❤3🤮2👎1
EFD Unpacker – распаковываем инсталляционные архивы 1С:Предприятие
Официально конфигурации и обновления 1С:Предприятия поставляются в инсталляционных пакетах и требуют процесса установки. Но на самом деле этот процесс сводится к распаковке содержимого специального архива – файла формата EFD – в отдельную директорию.
И если вы много и часто работаете с разными конфигурациями 1С:Предприятие, то это может стать проблемой. При создании новой базы или поиске обновлений платформа 1С просто осуществляет дисковый поиск в стандартной директории.
Просто дисковый поиск, какие-либо индексы или иной список содержимого отсутствует, в итоге создание новой чистой базы для разработки может занять несколько минут только на ожидание пока 1С просканирует всю эту директорию.
Ну и совсем не хочется что-то устанавливать в разовых случаях, когда вам просто надо скачать конфигурацию и установить/обновить ее клиенту.
А так как есть спрос, то будет и предложение, на просторах Github была обнаружена бесплатная кроссплатформенная утилита EFD Unpacker, которая позволяет произвольно распаковывать EFD-файлы.
Программа собрана для Windows, Linux и macOS, в Windows при установке сопоставляет себя с расширением EFD и позволяет распаковывать файлы правым кликом мыши.
Работать с ней очень просто, выбираем файл, выбираем папку назначения, немного ждем и получаем полное содержимое архива в распакованном виде.
Вроде бы мелочь, но именно из таких мелочей и складывается удобство работы, поэтому берем на заметку и пользуемся.
Официально конфигурации и обновления 1С:Предприятия поставляются в инсталляционных пакетах и требуют процесса установки. Но на самом деле этот процесс сводится к распаковке содержимого специального архива – файла формата EFD – в отдельную директорию.
И если вы много и часто работаете с разными конфигурациями 1С:Предприятие, то это может стать проблемой. При создании новой базы или поиске обновлений платформа 1С просто осуществляет дисковый поиск в стандартной директории.
Просто дисковый поиск, какие-либо индексы или иной список содержимого отсутствует, в итоге создание новой чистой базы для разработки может занять несколько минут только на ожидание пока 1С просканирует всю эту директорию.
Ну и совсем не хочется что-то устанавливать в разовых случаях, когда вам просто надо скачать конфигурацию и установить/обновить ее клиенту.
А так как есть спрос, то будет и предложение, на просторах Github была обнаружена бесплатная кроссплатформенная утилита EFD Unpacker, которая позволяет произвольно распаковывать EFD-файлы.
Программа собрана для Windows, Linux и macOS, в Windows при установке сопоставляет себя с расширением EFD и позволяет распаковывать файлы правым кликом мыши.
Работать с ней очень просто, выбираем файл, выбираем папку назначения, немного ждем и получаем полное содержимое архива в распакованном виде.
Вроде бы мелочь, но именно из таких мелочей и складывается удобство работы, поэтому берем на заметку и пользуемся.
👍34🤮1
Девушки в отрасли
Как-то так сложилось, что IT изначально было мужской сферой. Нет, были редкие исключения, но, в общем и целом, это было сугубо мужское царство.
Тут, конечно, можно вспоминать о физических и психологических различиях между мужским и женским полом, но история дает другие примеры.
Многие профессии, которые сегодня считаются априори женскими когда-то были сугубо мужскими. Взять ту же профессию бухгалтера. Когда-то, еще в первой половине прошлого века это была мужская профессия, потом смешанная.
Сегодня бухгалтер четко ассоциируется с женским родом. И мужчина-бухгалтер сегодня прямо как белая ворона. Хотя я знаю мужчин, которые работают на должности главбуха, но даже в этом случае они официально зовутся финансовыми директорами, зам. дир. по финансовой части и т.д. и т.п.
Первой IT-профессией женской направленности стало программирование, девушки-программистки начали появляться еще в конце нулевых, в десятых их стало больше, а сейчас вместе с моим сыном на программировании учится примерно пополам пацанов и девчонок.
Также на профильных форумах и каналах значительно прибавилось девушек, которые задают вполне годные вопросы, учатся, профессионально растут.
Сегодня я все больше и больше вижу девушек в админских и внедренческих чатах и каналах, которые занимаются маркировкой, внедрением и даже админскими делами.
И это хорошо, потому что исторически мужчины — это первопроходцы, которые смело шагают в неизведанное, бьются, преодолевают, покоряют.
Женщины приходят на готовое, в стабильность, их задача поддерживать и сохранять. И то, что в нашей отрасли становится все больше и больше женщин свидетельствует о ее зрелости и стабильности.
И сейчас уже далеко не редкость полностью IT-семьи, где оба супруга работают в одной отрасли и понимают друг друга, чтобы не получилось, как в том анекдоте: «я не сифилитик, а филателист».
Поэтому хочется такую тенденцию всячески поддерживать и наконец-то развеять миф IT-шника, как некого оторванного от мира сего товарища в растянутом свитере с оленями и неспособного поддержать светскую беседу.
Сегодня IT совершенно другая отрасль, не хуже и не лучше остальных, с такими же людьми, как и везде. И место здесь найдется и парням, и девчонкам, и экстравертам, и интровертам.
А девушкам, в преддверии женского праздника хочется пожелать не бояться бородатых админов в свитерах с оленями, а смело идти в отрасль. Вы тут нужны и возможно скоро некоторые профессии перестанут считаться исключительно мужскими.
Как-то так сложилось, что IT изначально было мужской сферой. Нет, были редкие исключения, но, в общем и целом, это было сугубо мужское царство.
Тут, конечно, можно вспоминать о физических и психологических различиях между мужским и женским полом, но история дает другие примеры.
Многие профессии, которые сегодня считаются априори женскими когда-то были сугубо мужскими. Взять ту же профессию бухгалтера. Когда-то, еще в первой половине прошлого века это была мужская профессия, потом смешанная.
Сегодня бухгалтер четко ассоциируется с женским родом. И мужчина-бухгалтер сегодня прямо как белая ворона. Хотя я знаю мужчин, которые работают на должности главбуха, но даже в этом случае они официально зовутся финансовыми директорами, зам. дир. по финансовой части и т.д. и т.п.
Первой IT-профессией женской направленности стало программирование, девушки-программистки начали появляться еще в конце нулевых, в десятых их стало больше, а сейчас вместе с моим сыном на программировании учится примерно пополам пацанов и девчонок.
Также на профильных форумах и каналах значительно прибавилось девушек, которые задают вполне годные вопросы, учатся, профессионально растут.
Сегодня я все больше и больше вижу девушек в админских и внедренческих чатах и каналах, которые занимаются маркировкой, внедрением и даже админскими делами.
И это хорошо, потому что исторически мужчины — это первопроходцы, которые смело шагают в неизведанное, бьются, преодолевают, покоряют.
Женщины приходят на готовое, в стабильность, их задача поддерживать и сохранять. И то, что в нашей отрасли становится все больше и больше женщин свидетельствует о ее зрелости и стабильности.
И сейчас уже далеко не редкость полностью IT-семьи, где оба супруга работают в одной отрасли и понимают друг друга, чтобы не получилось, как в том анекдоте: «я не сифилитик, а филателист».
Поэтому хочется такую тенденцию всячески поддерживать и наконец-то развеять миф IT-шника, как некого оторванного от мира сего товарища в растянутом свитере с оленями и неспособного поддержать светскую беседу.
Сегодня IT совершенно другая отрасль, не хуже и не лучше остальных, с такими же людьми, как и везде. И место здесь найдется и парням, и девчонкам, и экстравертам, и интровертам.
А девушкам, в преддверии женского праздника хочется пожелать не бояться бородатых админов в свитерах с оленями, а смело идти в отрасль. Вы тут нужны и возможно скоро некоторые профессии перестанут считаться исключительно мужскими.
🔥30👍17🤮5❤1