Почему apt не может войти, используя информацию из конфигурационного файла auth.conf.d?

Довольно сложная проблема: я настроил собственный репозиторий Debian на удаленном сервере (назовем его example.com), который обслуживается по адресу https://example.com/aptrepos, и для этого пути я настроил базовую аутентификацию apache2, так что требуется ввод логина и пароля.

Затем есть два устройства Raspberry Pi 4 в разных местах (назовем их rpi1 и rpi2); я вполне уверен, что на обоих устройствах установлена версия Debian (то есть Raspbian или Raspberry Pi OS) bookworm, а именно:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:    12
Codename:   bookworm

На обоих из них я создал два файла:

• /etc/apt/sources.list.d/example-com.list со следующим содержимым:

  deb [trusted=yes] https://example.com/aptrepos bookworm main
  

• /etc/apt/auth.conf.d/example-com.conf со следующим содержимым:

  machine example.com
  login userx
  password uSeRx.PaSsWoRd
  

  (userx является заменой для соответствующих пользователей на сервере, например user1 и user2, а uSeRx.PaSsWoRd является заменой для соответствующих паролей)

Я убедился, что логин и пароль для аутентификации правильные, попытавшись открыть, например, https://example.com/aptrepos/dists/bookworm/Release в веб-браузере, а затем скопировав и вставив логин/пароли из соответствующих файлов example-com.conf в поле ввода “Имя пользователя/Пароль” в всплывающем окне браузера, которое появляется при первом открытии этой ссылки в браузере – это работает нормально на соответствующих устройствах RPi в обоих местах.

Теперь вот в чем проблема: когда я выполнил эту настройку на устройстве rpi1, я просто запустил sudo apt update, и он завершился без проблем – а затем я мог сразу выполнить sudo apt install custom_package, и он установил соответствующий пакет из собственного репозитория Debian по адресу https://example.com/aptrepos. Если я проверяю access.log в Apache2 на сервере example.com, я вижу записи типа:

172.16.0.1 - user1 [14/Aug/2024:11:29:55 +0000] "GET /aptrepos/dists/bookworm/Release HTTP/1.1" 304 202 "-" "Debian APT-HTTP/1.3 (2.6.1)"

… то есть там указан аутентифицированный логин на строке лога, и сервер ответил кодом состояния HTTP 304 (Не изменено), что в порядке.

Но когда я попытался выполнить sudo apt update на другом устройстве (rpi2), оно не прошло – не сохранил точное сообщение об ошибке, но это было что-то вроде “Неавторизованный доступ”; и, очевидно, я не могу устанавливать пакеты из собственного репозитория. Когда я смотрю в access.log apache2, я вижу:

173.16.1.49 - - [14/Aug/2024:09:11:09 +0000] "GET /aptrepos/dists/bookworm/Release HTTP/1.1" 401 1134 "-" "Debian APT-HTTP/1.3 (2.6.1)"

Теперь мы также можем подтвердить, что подпись пользовательского агента на этом втором устройстве RPi такая же, как на первом устройстве RPi (“Debian APT-HTTP/1.3 (2.6.1)”).

Таким образом, в этой записи лога нет имени пользователя, и сервер ответил с 401 (Неавторизован) – что является причиной сбоя sudo apt update на том устройстве.

Как это может происходить, если я подтвердил на обоих устройствах, что соответствующие логины и пароли, введенные в example-com.conf, работают на обоих устройствах в соответствующих местах, когда вводятся в веб-браузере?

Как будто на втором устройстве RPi apt даже не удосужился использовать учетные данные для аутентификации из /etc/apt/auth.conf.d/example-com.conf, и пошел на попытку получить доступ к удаленному собственному репозиторию без аутентификации – но почему он хотел бы это сделать?!?!

Что я могу сделать, чтобы начать отладку или исправление этого?

Ну, я наконец-то решил эту проблему – к сожалению, не с помощью какой-то умной техники отладки; а просто благодаря тому, что у меня была возможность сравнить соответствующие файлы на машинах, которые я назвал rpi1 и rpi2 в оригинальном вопросе.

Проблема в том, что я написал оригинальный вопрос на основе файлов на rpi1, к которым у меня был доступ в то время, и которые, как упоминалось, работают. Однако оказывается, что на rpi2, которое не работало, содержимое /etc/apt/auth.conf.d/example-com.conf выглядело так:

Machine example.com
login userx
password uSeRx.PaSsWoRd

… то есть первое слово Machine начиналось с заглавной буквы / верхнего регистра / большой буквы M – и это стало причиной ошибки 401 Unauthorized!

Как только я изменил первую букву Machine на строчную букву m – фактически получив содержимое файла, как в оригинальном вопросе:

machine example.com
login userx
password uSeRx.PaSsWoRd

… тогда все стало работать на rpi2 так же хорошо, как и на rpi1!!

Теперь у меня абсолютно нет идеи, как такое написание букв могло вызвать ошибку 401 Unauthorized на сервере; если бы что-то, я ожидал бы, что ошибка написания не сможет даже обратиться к правильному серверу – но, как подтверждают логи сервера, правильный сервер действительно был контактов, и, по какой-то причине, он решил, что нужно ответить 401 Unauthorized …

Ну, так бывает, что плохое сообщение об ошибке может отнять месяцы вашего времени – если бы оно просто сказало “Ошибка: параметр ‘Machine’ не распознан” или что-то подобное, вероятно, я бы уже решил это в момент, когда это произошло, и мне бы не пришлось бы это публиковать …