Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

Остальные 90%: post #133 — TG.ME

Остальные 90%@final90percent · 722 subscribers Open in TelegramOpen

t.me/final90percent/133

2

1

1

March 24, 2025 784 1

More from this channel

Заметка дня #11 Изредка, пробуя установить разные версии одной и той же утилиты, можно наткнуться на неожиданное поведение: несмотря на то, что мы только что установили вторую версию приложения, Bash упорно отказывается её видеть. В новом же терминале, однако, всё работает корректно, и это может выглядеть подозрительно. Оказывается, Bash ищет утилиту лишь раз, при первом её вызове - после этого он хранит путь к найденному исполняемому файлу во внутреннем ассоциативном массиве, и все последующие вызовы команды сводятся к вызову файла, расположенному по сохранённому ранее пути. Именно поэтому, если мы вызвали версию утилиты, а затем удалили её, то без явных подсказок Bash новую версию искать не станет. Посмотрим на поведение Bash на примере: создадим файл do-not-delete-me.sh по пути /usr/local/bin и убедимся, что всё работает: # Create a file: $ cat do-not-delete-me.sh #!/bin/bash echo 'Hello, Elliot' # Make it runnable and move to /usr/local/bin: $ chmod +x do-not-delete-me.sh $ sudo mv do-not-delete-me.sh /usr/local/bin # Call the binary! $ do-not-delete-me.sh Hello, Elliot Теперь переместим скрипт в ~/.local/bin, тоже содержащийся в переменной $PATH - технически, Bash по-прежнему должен найти команду, однако этого не происходит: $ sudo mv /usr/local/bin/do-not-delete-me.sh ~/.local/bin $ do-not-delete-me.sh bash: /usr/local/bin/do-not-delete-me.sh: No such file or directory Несложно дополнительно убедиться, что открытый в отдельном окне терминал вызвать команду всё-таки может. Исправить ситуацию можно, используя встроенную команду Bash hash, отвечающую за построение ассоциативного массива, речь о котором шла выше. Вызванная без аргументов, она покажет, какие команды были запомнены: $ hash hits command 4 /usr/local/bin/do-not-delete-me.sh 1 /usr/bin/chmod 3 /usr/bin/ls ... Для удаления конкретной записи можно использовать ключ -d, однако самым коротким путём будет очистить всю таблицу одним махом: $ hash -r Теперь путь до скрипта найдётся корректный, и запуск команды завершится успехом: $ do-not-delete-me.sh Hello, Elliot $ hash hits command 1 /home/mint/.local/bin/do-not-delete-me.sh Наткнуться на эту проблему можно, перемежая установку сборок утилиты из репозиториев дистрибутива и GitHub - тот же сканер Grype служит наглядным примером. На момент написания заметки Ubuntu 22 позволяет установить версию 0.99.1, в то время как самый свежий релиз - уже 0.104.3. Мы могли установить сканер из репозиториев, обнаружить старую версию, удалить её и установить новую в другое место - и получить именно эту ошибку. Проблема стреляет крайне редко, и обычно не причиняет существенных неприятностей, однако помнить о её истоках полезно. Если мы работали удалённо по SSH, и подключение требует ввода пароля, то открывать новое соединение лишний раз обычно не хочется. #tip 814·Dec 29 О том, что поле CN в TLS-сертификатах помечено устаревшим ещё в 2000 году, я читал не раз. И всё-таки неожиданным открытием для меня оказалось, что HTTPS-клиенты, написанные на Go 1.17+, отказываются работать с такими сертификатами совершенно. Открытием это стало, поскольку тот же curl, с которым обычно приходится иметь дело, ведёт себя иначе. Чтобы в этом убедиться, создадим ключ и сертификат, выписав его на имя localhost, и запустим с ними простой веб-сервер: # Creates files cert.pem and key.pem $ openssl req -x509 -keyout key.pem -out cert.pem \ -days 365 -nodes -subj '/CN=localhost/' # Check there is no SAN in certificate $ openssl x509 -in cert.pem -noout -ext subjectAltName No extensions in certificate $ openssl s_server -key key.pem -cert cert.pem -WWW -port 4433 Веб-сервер будет отдавать файлы из рабочей директории, так что для тестирования запросим любой из имеющихся - например, cert.pem. В соседнем терминале подключимся к серверу при помощи curl. Поскольку сертификат, который отдаёт сервер, самоподписанный, используем его же для валидации подключения: $ curl https://localhost:4433/cert.pem --cacert cert.pem -----BEGIN CERTIFICATE----- MIIDCTCCAfGgAwIBAgIUO6d0vnNmNST77... ... Как мы видим, сертификат вполне удовлетворил curl. Теперь попробуем обратиться к тому же серверу, но по другому имени: # Using '--resolve' to avoid messing with /etc/hosts $ curl https://example.com:4433/cert.pem --cacert cert.pem \ --resolve 'example.com:4433:127.0.0.1' curl: (60) SSL: certificate subject name 'localhost' does not match target host name 'example.com' Как и ожидалось, теперь сертификат не принимается - ничего необычного. Возьмём теперь HTTPS-клиента, написанного на Go, который будет подключаться к тому же серверу. Убедимся, что версия go не менее 1.17, и запустим клиент: $ go version go version go1.22.1 linux/amd64 $ CERT=cert.pem URL='https://localhost:4433/' go run main.go 2025/12/22 00:33:23 Error making request: Get "https://localhost:4433/": tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead exit status 1 Несмотря на соответствие доменного имени и сертификата клиент отказался подключаться к серверу. В версиях go до 1.16 включительно это поведение можно было переопределить, указав переменную GODEBUG=x509ignoreCN=0, однако уже с версии 1.17 изменить поведение стандартной библиотеки нельзя. Единственный способ заставить клиента подключиться - выписать сертификат, содержащий соответствующее поле SAN. Перевыпишем сертификат crt.pem с ключом -addext и перезапустим сервер: $ openssl req -x509 -keyout key.pem -out cert.pem \ -days 365 -nodes -subj '/CN=localhost/' \ -addext 'subjectAltName = DNS:localhost' # Check SAN exists now $ openssl x509 -in cert.pem -noout -ext subjectAltName X509v3 Subject Alternative Name: DNS:localhost $ openssl s_server -key key.pem -cert cert.pem -WWW -port 4433 Теперь клиент сможет подключиться и также загрузить файл: $ CERT=cert.pem URL='https://localhost:4433/' go run main.go -----BEGIN CERTIFICATE----- MIIDCTCCAfGgAwIBAgIUO6d0vnNmNST77... ... Оставляя за скобками недовольство по поводу такого неоднозначного изменения в Go (проблему решали день), выводы хочется сделать следующие: 1. необходимо внимательно следить за содержимым сертификатов - расширения уже давно стали неотъемлемой частью сертификата; 2. openssl по умолчанию выписывает сертификат, который не принимается многими клиентами - важно помнить о ключе -addext. Кстати, mkcert, имеющийся в репозиториях Ubuntu, создаст ту же пару файлов при при помощи короткой команды mkcert localhost, однако сразу с расширением SAN и не требуя запоминать десяток неочевидных ключей. В этом вопросе он однозначно обходит openssl :) 875·Dec 22 Привет! Последние полтора месяца в канале было тихо - пришло время нарушить молчание и поделиться, как же так вышло и чего ждать дальше. Причина затишья банальна - всё это время я помогал составлять курс, посвящённый теме SRE. На это уходило всё свободное время и все остающиеся к вечеру силы, так что в результате оформить заметки должного качества уже никак не удавалось. Ближайший месяц обещает быть таким же насыщенным, а затем, как только вернётся возможность, в канале снова начнут появляться заметки, список заготовок для которых всё это время медленно пополнялся. Чтобы заметка не выбивалась из общего потока и несла прикладной интерес, поделюсь ссылкой на один из моих любимых сборников страшилок UNIX-админов: https://www-uxsup.csx.cam.ac.uk/misc/horror.txt. Если ссылка не открывается, то есть версия на Web Archive - очень советую познакомиться с рассказами. Чрезвычайно любопытно сравнить задачи тридцатилетней давности с нынешними. Спойлер: не берусь утверждать, что 30 лет назад всё было проще. Мою любимую историю быстрее всего найти по строке From alt.folklore.computers Fri Nov 9 11:16:43 1990 - думается мне, подобные решения проблем едва ли удастся встретить в современном IT :) 821·Nov 5

[media post] 1.1K·Sep 15 Прежде чем углубиться в изучение внутренностей Linux, мне показалось верным сделать шаг назад и обратиться к истокам - к третьему изданию Operating Systems Design and Implementation Таненбаума. В ближайшем году труду исполняется 20 лет, и столь почтенный возраст уже начинает сказываться на актуальности материала - особенно если говорить о практической его части. Взявшись за книгу, я ожидал, что мне удастся проштудировать исходный код ОС в сопровождении обширных комментариев автора, поэкспериментировать с исходниками, пересобрать систему, но трудности всплыли на первом же шагу. Последняя версия Minix, 3.3.0 на текущий момент, уже далеко ушла от описанной в книге версии 3.1.0, и скорее представляет из себя сборку NetBSD с вкраплениями #if defined(__minix). Проект сильно изменил свою структуру, и сопоставить функции и файлы, о которых идёт речь в тексте учебника, с имеющимися в проекте, стало слишком сложно. Более того, собрать проект без доработок не выйдет - сначала надо исправить несколько ошибок в исходниках. В то же время вернуться к версии 3.1.0, описываемой в книге, ещё сложнее: Makefile ожидает, что исходники лежат по определённому пути, префиксы местами захардкожены, а python так и вовсе используется версии 1.5. Всё починить и завести, конечно, можно, но задача кажется объёмной и даже перевешивающей цель повозиться с самим кодом - в общем, от этой части плана пришлось отказаться. Книгу я изучал, просто читая исходный код. К качеству этого кода тоже есть вопросы, хоть и спорить с автором я желания не имею :) И всё же сбитые отступы, использование стандарта K&R, нарушения единого стиля и прочие мелочи заставляли мозг напрягаться лишний раз. Самой крупной проблемой оказался ошибочный комментарий в ассемблерном коде (использующим свой особый диалект, к слову), из-за которого пришлось несколько дней сверяться с OsDev Wiki: сегменты описаны как flat, значит, смещение сегмента должно быть равно нулю - а оно вычисляется. В конце-концов, большие надежды я возлагал на раздел, посвящённый управлению памятью, однако MINIX 3.1.0 не реализует виртуальную память. Описанный алгоритм ощутимо проще используемого в современном Linux и мне был уже не особо интересен. И всё же учебник замечателен - выше я сказал обо всех несоответствиях ожиданиям и недостатках, которые помешали мне вынести максимум из книги, и все они уместились в одну заметку в сравнении с текстом самого труда, занимающего более 600 страниц. В книге Таненбаум говорит не только о коде, он описывает и общую теорию, рассказывает про возможные алгоритмы. Пару слов об этом я даже оставлю в комментарии к заметке. Наконец, пара слов об актуальности MINIX. Да, эта ОС уже имеет мало общего с Linux, используемые при её построении подходы (например, "безопасность важнее производительности") могли не пройти проверку временем, и всё-таки MINIX имеет огромную академическую ценность и даёт базу для дальнейшего изучения Linux. Более того, оказывается, модуль Intel ME использует MINIX 3 в качестве прошивки! 978·Sep 15

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 09/01/2026 · v0.2.0 · 33f6558

Privacy Terms DMCA & complaints Report a violation

Similar channels

Useful Tools | Linux | GitOps | DevOps6.7K subscribers

IT-KB 🤖8K subscribers

Опенград741 subscribers

/usr/bin4.9K subscribers

DevOps | Вопросы собесов5.5K subscribers

Лига сисадминов13.1K subscribers

Admin Guides | Сисадмин11.9K subscribers

Пятничный деплой4.8K subscribers