Почему у тебя все репозитории в одном файле? Обычно репозитории PVE перечисляются по отдельности в каталоге sources.list.d, а репозитории Debian — только в sources.list. Тогда ты можешь удалять/переименовывать отдельные файлы, чтобы отключать/включать репозитории.

Но репозитории — это дети объекта файлов. Так что, когда ты знаешь, какой файл нужно изменить, ты можешь просто перебирать объект, начиная с 0, и ты знаешь связанный индекс, когда находишь подходящий параметр. Причина, по которой это нелегко, в том, что структура файла репозитория apt не была разработана для машинной обработки. Хотя я предполагаю, что ты просто хочешь запрограммировать желаемое состояние (например, как это делает Ansible), в этом случае просто напиши, как ты хочешь, чтобы выглядела твоя конфигурация, убери всё, что отклоняется от этого, и тогда ты всегда будешь знать, например, что корпоративный репозиторий находится в `/etc/apt/sources.list.d/pve-enterprise.repo` с индексом 0. Это будет упрощено с помощью этого, что можно технически использовать и сегодня: https://repolib.readthedocs.io/en/latest/deb822-format.html — не уверен, как API обрабатывает это.

Мой аргумент касательно APT-репозиториев в том, что в них нет ничего уникального, что можно проиндексировать: Что бы вы сделали "индексом" этого репозитория, например (это валидный репозиторий в моем кластере), если не числовой индекс с нумерацией с нуля, потому что есть точная копия этого объекта с types=deb-src и нет, это не официальный репозиторий Debian или Proxmox, но это "валидная" конфигурация APT-репозитория. JSON: {
                   "Components": [
                       "main"
                   ],
                   "Enabled": 0,
                   "FileType": "list",
                   "Options": [
                       {
                           "Key": "signed-by",
                           "Values": [
                               "/etc/apt/keyrings//somerepo.asc"
                           ]
                       }
                   ],
                   "Suites": [
                       "bullseye"
                   ],
                   "Types": [
                       "deb"
                   ],
                   "URIs": [
                       "http://somerepo"
                   ]
               } В моем случае имя файла для этого репозитория известно (значит, это somerepo.list), и тогда индекс 0 — это deb, а индекс 1 — это deb-src. Управлять APT-репозиториями с помощью Ansible — не 'просто', то, что делает Ansible, — это просто генерирует репозиторий с уникальным именем файла, после чего администратор "называет" репозиторий, но можно легко получить дубликаты конфигураций репозиториев. Если вы собираетесь использовать API, я предполагаю, что вы запросите текущие репозитории, проведете какое-то соответствие желаемой конфигурации (например, я добавлю репозиторий в определенный файл в определенный индекс или с помощью regexp-выражения), и тогда ваша желаемая конфигурация будет там. Я предполагаю, что для свежей установки у вас уже все в 'правильном' состоянии. Рекомендация состоит в том, чтобы не продолжать добавлять вещи в sources.list, вам действительно следует использовать отдельные файлы репозиториев.

Есть несколько способов управления репозиториями с помощью Ansible, пожалуй, самый простой — с помощью модуля copy. Возвращаясь к API, я по-прежнему настаиваю, что он подходит к решению задач с ног на голову. Посмотрите на цели проектирования раздела apt Proxmox API (по крайней мере, на то, что я могу понять из функциональности):
1. Разбирать и возвращать любое допустимое содержимое sources.list или sources.d/*.list
2. Создавать новые, допустимые источники apt.
3. Включать и отключать существующие источники.

Как бы там ни было, Debian поддерживает наличие нескольких репозиториев в одном файле, и API правильно их разбирает, иначе веб-интерфейс бы их не отображал, и его можно использовать для включения/отключения. Это полностью соответствует целям проектирования. Чтобы соответствовать цели проектирования, позволяющей вызывать API для включения/отключения, индексацию следует строить на основе *содержимого* файлов репозитория, а переменную пути использовать в качестве подтверждения. Предположим, кто-то был неряшливым системным администратором, или его сменили после неряшливого системного администратора, и столкнулся с конфигурацией репозитория вроде этой:

Code: # /etc/apt/sources.list
...
deb http://foo.example main foo

Code: # /etc/apt/sources.list.d/foo.list
Enabled: yes
Types: deb
URIs: http://foo.example
Suites: foo
Components: main

Отлично, теперь идентичный репозиторий foo определен в двух местах, и мы хотим отключить один из них через API. Для этого нам понадобятся следующие параметры:

1. Индекс
2. Узел
3. Путь

Мы можем предположить, что мы уже знаем, на каком узле мы находимся, так что теперь нам нужны только индекс и путь, верно? Проблема в том, что они хранятся отдельно в API и никоим образом не связаны друг с другом. Вот что возвращается при запросе:

JSON: {
 "files": [
   {
     "path": "/etc/apt/sources.list",
     "repositories": [
       {...},
       {
         "description": "This is the foo repository for doing foo things.",
         "handle": "foo",
         "name": "Foo",
         "status": 1
       },
       {...},
         "description": "This is the foo repository for doing foo things.",
         "handle": "foo",
         "name": "Foo",
         "status": 1
     ]
   },
   ...
 ],
 "infos": [
   ...
   {"index": 3, "path": "/etc/apt/sources.list"},
   ...
   {"index": 7, "path": "/etc/apt/sources.list.d/foo.list"},
   ...
 ]
}

Очевидно, что отсюда все довольно просто, но меня больше всего поражает, что поле "status" находится в одном массиве, а поле "index" — в другом, ведь единственное, что мы можем реально изменить — это status. Или лучше, слить содержимое массива "infos" в "files", так как это бессмысленное различие.