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 #144 — TG.ME

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

t.me/final90percent/144

8

6

September 15, 2025 1.1K 3

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 Прежде чем углубиться в изучение внутренностей 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 Клиент-серверная архитектура Docker позволяет обращаться к демону dockerd не только с локального хоста, но и с удалённого. В привычном режиме демон открывает UNIX-сокет, в "удалённом" - обычный сетевой сокет, которым используется Docker Swarm, например. Вопрос авторизации в этой схеме решается при помощи mTLS, что нравится не всем: если пользователей, обращающихся к демону, много, то управление доступами потребует выписывать и отзывать сертификаты, а выполнение всех действий общим демоном затрудняет их аудирование - все операции на хосте будут происходить от имени единого процесса dockerd независимо от того, кто их инициировал. Оказывается, первую проблему Docker всё-таки решает: хоть и не без греха, Docker-клиент умеет подключаться к серверу по протоколу SSH и обращаться к демону уже через локальный сокет - странно, что соответствующая страница документации не попадалась на глаза ранее. Заставить docker подключаться по SSH можно по-разному: используя ключ -H, настроив context или выставив переменную окружения DOCKER_HOST, которую будем использовать в примерах далее. Чтобы удалённое подключение работало, надо удовлетворить двум условиям: 1. пользователь может обращаться к сокету dockerd; 2. на хост добавлен ключ авторизации. Если первое требование ещё как-то упоминается в документации, то о втором упоминаний я не нашёл, а об ошибках docker сообщит не слишком явно. Положим, авторизация на сервере настроена не по SSH-ключу, а по паролю: DOCKER_HOST='ssh://mint@localhost' docker ps error during connect: Get "http://docker.example.com/v1.50/containers/json": command [ssh -o ConnectTimeout=30 -T -l mint -- localhost docker system dial-stdio] has exited with exit status 255, ... Permission denied, please try again. mint@localhost: Permission denied (publickey,password). В тексте ошибки docker раскрывает, что подключается к серверу, просто вызывая команду ssh с ключом -T - то есть, не аллоцируя терминал. Указать пароль в URL, судя по коду, тоже нельзя. А ещё команда раскрывает секретную опцию system dial-stdio - просто интересный факт :) Невыполнение второго условия влечёт другую неочевидную ошибку: $ DOCKER_HOST='ssh://mint@localhost' docker ps Cannot connect to the Docker daemon at http://docker.example.com. Is the docker daemon running? Здесь docker пытается обратиться к UNIX-сокету dockerd на удалённом хосте и ему это не удаётся: непривилигированный процесс пользователя не отличает отсутствие сервера от нехватки прав: # Manual check on a remote host: $ curl --unix-socket /var/run/docker.sock 'http://docker.example.com/images/json' curl: (7) Failed to connect to docker.example.com port 80 after 0 ms: Couldn't connect to server Добавив пользователя в группу docker, чтобы вызывать sudo не требовалось (что равносильно выдаче root-прав пользователю...), мы наконец доберёмся до хоста: $ DOCKER_HOST='ssh://mint@localhost' docker ps CONTAINER ID IMAGE ... Вся эта возня пригодится, если надо таскать образы в закрытый контур через хост-бастион. Находясь на хосте, с которого осуществляется прыжок в закрытый контур, образы можно передавать парой команд: $ docker pull python:3.13 ... $ docker save python:3.13 -o python.tar $ docker -H 'ssh://user:next-host' docker load -i python.tar Здесь нам не приходится передавать образ по scp, заходить на удалённый хост для его загрузки и удалять переданный образ с ФС. Экономия на спичках, но всё равно приятно :) 919·Aug 4

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