Записки IT специалиста

Здесь делают hh.ru. И показывают, как именно. Узнавайте первыми о митапах, подсматривайте, как принимаются продуктовые решения, и знакомьтесь с людьми, которые создают hh.ru. Подписаться #реклама О рекламодателе

Включаем отображение Samba-сервера в сетевом окружении Windows Если вы используете Samba для организации общих файловых ресурсов, то, наверное, заметили, что в последних версиях Windows такие сервера больше не отображаются в сетевом окружении, хотя нормально работают при прямом подключении к ним. Это связано с полным отказом в Windows от использования протокола SMB1 и невозможностью обнаружить Samba по протоколу NetBIOS. Современные Windows системы используют для обнаружения устройств WSD (Web Services for Devices) и сегодня мы расскажем, как добавить его поддержку для вашего сервера Samba. ✅ Читать далее: https://interface31.ru/post/vklyuchaem-otobrazhenie-samba-servera-v-setevom-okruzhenii-windows/

Управление сложными тарифными предложениями стало доступно в новой версии биллинга «айФлекс» В обновленную версию «айФлекс. Биллинговой платформы» вошел модуль «Продуктовый каталог». Он позволяет бизнесу создавать разовые, периодические, пакетные и индивидуальные предложения, сокращая время запуска и зависимость от ИТ-команды.

Модуль работает в составе платформы или отдельно, интегрируясь в BSS-ландшафт. Биллинг закрывает цикл расчетов: от тарификации до счетов и закрывающих документов.

Одно из внедрений биллинга айФлекс — сервис «Триколор.Здоровье». Команда разработала мобильные приложения, настроила биллинг и интеграции с медицинскими сервисами. Платформа обеспечивает оплату подписок и разовых услуг, промокоды, скидки и расчеты партнеров. В августе айФлекс предлагает бесплатное предпроектное обследование для компаний, рассматривающих внедрение или замену биллинга. Бесплатные часы ограничены https://tglink.io/93b87a08865605 erid: 2W5zFJnKQ7j

И снова про отечественные сертификаты Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры. Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п. Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат. Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена. За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло. Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю. И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк. Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам. Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору. Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом. Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат. Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно. Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие: Key exchange ECDHE_RSA with P-256 Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи. Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата. Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка. При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа. Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры. Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM. Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.

Как устроен hh.ru изнутри Что происходит до того, как новая фича появляется у миллионов пользователей? Показываем реальные кейсы, людей, инженерные решения и всё самое интересное из жизни IT-команд hh.ru. Подписаться #реклама О рекламодателе

Самозаверенные сертификаты. Мифы и реальность. Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще. Но это мнение не имеет под собой никакого основания, так как сертификат сам по себе не определяет стойкость шифрования — за выбор протоколов и шифронаборов отвечают настройки сервера и клиента. Кроме того, следует помнить, что выбор шифра – процесс обоюдный и недаром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает самый стойкий из тех, которые поддерживает сам. Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью. Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо более высокий уровень безопасности чем первая. Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проще говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу. Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению, и, если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять. Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим издателем. Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену. Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником. По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам, выпущенным этим центром. Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат. Самозаверенный сертификат не имеет доверенного центра сертификации в цепочке и доверительные отношения с ним установить не удастся, все, что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности. Но это нужно сделать на каждой системе, при этом обязательно проверив, тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаще всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите. Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.

Patroni + Kubernetes: HA кластер PostgreSQL на проде Строите платформу на Kubernetes и хотите запустить высокодоступный PostgreSQL? 📅 23 сентября в 20:00 разберем Patroni в контексте K8s. Operator, автоматический failover, интеграция с мониторингом (Prometheus). Узнаете, как управлять кластерами PostgreSQL в облачной среде. Для DevOps, SRE и инженеров платформ. Узнать больше #реклама 16+ otus.ru О рекламодателе

Проверь себя: сколько из этих пунктов про тебя? - один пароль используется на нескольких сайтах - двухфакторная защита включена не везде - ты давно не проверял активные сеансы в Telegram и почте - приложения имеют доступ к микрофону, камере и геолокации, хотя он им не нужен - иногда открываешь ссылки из сообщений, не проверяя адрес - если завтра потеряешь телефон, не уверен, что быстро восстановишь все аккаунты. Если совпало хотя бы несколько пунктов - тебе пригодится Киберкролик 🐇 Это Telegram-канал для обычных пользователей о цифровой безопасности, мошенничестве, ИИ и полезных интернет-инструментах. Без сложного технарского языка и бесконечного потока IT-новостей. Уже внутри: 🔐 12 пунктов базовой цифровой защиты - можно пройти как чек-лист 🔗 инструкция, как проверить подозрительную ссылку, прежде чем её открывать 🤖 7 типов данных, которые лучше не отправлять нейросетям 🧠 готовые промпты для ИИ, которые можно просто скопировать ⚙️ разборы автоматизаций и вайбкодинга для тех, кто не хочет тратить часы на рутину. Главный принцип канала простой: прочитал → применил → стал немного безопаснее или сэкономил себе время. Если интернетом ты пользуешься каждый день - скорее всего, здесь регулярно будет что сохранить себе. 👉 Подписаться на «Киберкролик» Кролик знает короткий путь. 🐇 Реклама. Сотиболдиев Д.А. ИНН 503418233271.

Завершающий слеш в путях Linux Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку. В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл. Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:

~/video

Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:

~/video/

Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом. Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам. Например, в нашем скрипте написано в цикле что-то вроде:

mv -f "$file" /new_path/video

Данная конструкция имеет неопределенность, потому что если мы забудем создать папку video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл. Если же мы напишем:

mv -f "$file" /new_path/video/

То при отсутствии директории получим ошибку:

mv: невозможно создать обычный файл ' video/': Это не каталог

Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:

mv: не удалось получить доступ к ' video /': Это не каталог

Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет. Но наличие слеша устраняет неопределенность, потому что явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем. Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили? В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли? Поэтому в скриптах такие вещи всегда лучше проверять явно, например:

if ! [ -d /new_path/video/ ]; then
   mkdir -p /new_path/video
fi

В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта. В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог. А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.

Зарабатывайте на установках Яндекс Браузера Партнёрская программа для сервисных центров, магазинов компьютерной техники, сайтов для скачивания файлов и авторов статей. Вы можете предлагать его своим клиентам и аудитории — и зарабатывать на новых установках. Выплаты до 500₽ за каждую установку Яндекс Браузера. Подать заявку #реклама 16+ partner.browser.yandex.ru О рекламодателе

Что, если AI-агент сможет не просто написать вам функцию, а сам пройти часть пути от задачи до PR? Именно этот процесс разберут на бесплатном практическом воркшопе Хекслета 25 августа. На реальном проекте покажут, как: → дать агенту правила и архитектуру проекта; → передать ему issue; → получить план и реализацию; → прогнать тесты и CI; → исправить ошибки; → подготовить pull request; → подключить документацию через RAG и рабочие инструменты через MCP. 2 часа живой практики вместо очередного вебинара «10 способов использовать ChatGPT». Подойдёт backend/frontend-разработчикам, тимлидам, техлидам и QA Automation. 25 августа в 19:00. Участие бесплатное. 👉 Записаться на воркшоп #реклама О рекламодателе

Большой SLC-кеш, хорошо ли это? Сегодня основным типом твердотельного накопителя является накопитель с типом ячеек TLC, три бита на одну ячейку. Другой памяти вы в современных дисках не найдете, за исключением QLC – еще более медленной с четырьмя битами на одну ячейку. Те редкие модели с памятью MLC которые сегодня можно встретить в продаже относятся к устаревшим моделям с интерфейсом SATA и их скоростные характеристики оставляют желать лучшего. Сама TLC память достаточно медленная, и чтобы улучшить скоростные характеристики накопителя был придуман SLC-кеш. Сразу скажем, что никакой отдельной памяти для этого кеша нет, просто в SLC-режим переводится часть ячеек накопителя. А так как SLC – это один бит на ячейку, то емкость ячейки падает в три раза для TLC и в четыре для QLC. Таким образом максимальный объем SLC кеша для TLC не может превышать 33,3% емкости накопителя, а для QLC – 25%. Режим кеширования производителем не разглашается и зависит от программных настроек прошивки контроллера, но бытует мнение, что чем больше размер кеша, тем лучше. Но это далеко не так. Почему? Один из распространенных алгоритмов кеширования предусматривает выделение под кеш большого объема, примерно в 30% от свободного объема накопителя. Что это значит? Это значит, что мы перевели в SLC-режим практически всю память, потому что 30% кеша – это 90% объема. Да, такой кеш будет поддерживать высокую скорость записи, но по его исчерпанию диску просто становится некуда писать. Поэтому ему приходится одновременно уплотнять запись, переводя SLC-ячейки в TLC-режим и принимать новые данные. При этом скорость записи катастрофически падает, местами до 100 МБ/с и ниже. Другая стратегия предлагает выделение небольшого объема под кеш 5-10% емкости диска. При этом основная часть ячеек диска остается в режиме TLC и по исчерпании кеша вполне способны обеспечить скорость записи в районе весьма комфортных 400 – 500 МБ/с. Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень. Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость. Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска. При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.

Делайте это 3 раза в день — и голова болеть не будет. Не упражнения. Делегируйте рутину ИИ. Пока вы часами делаете однотипную работу, ИИ уже может помогать анализировать данные, обрабатывать информацию и решать инженерные задачи. На онлайн-курсе «Технологии искусственного интеллекта для инженеров» от «Аэромобильности» МАИ вы научитесь применять ИИ в работе и автоматизировать рутинные процессы. Поддержка преподавателя + обучение в удобное время После обучения — удостоверение государственного образца о повышении квалификации Московского авиационного института (МАИ). Меньше рутины. Больше инженерной работы. Начните уже сейчас.