Обновление: Сохранение конфигов

[AltGrF13]

Люди пробуют новую версию, потом откатываются, пакет может больше не работать.

Конфиги

Как минимум, есть проблема из-за бекапа конфигов dnsmasq.conf и dnscrypt-proxy.toml. При переходе на новые версии настройки могут катастрофически меняться, а он восстанавливает файлы не соответствующей версии. К тому же, осуществляет в файлах замены (разные для разных версий); и они наслаиваются, не работают на уже модифицированных конфигах. Воспроизвести можно, если осуществить несколько переходов по версиям и обратно на 1.1.8r2. Т.е. откуда берутся такие сообщения в жалобах Телеграмм, воспроизвести я могу.

С тем же dnsmasq.conf человек может класть свои конфиги отдельно в /opt/etc/dnsmasq.d/, КВАС их никак не удаляет, т.е. они самобекапятся. Не уверен, что стоит прислушиваться/бекапить и пользовательские правки в dnscrypt-proxy.toml.

Если же это делалось, чтобы сохранить исходные конфиги пакетов после установки, то сейчас это тоже не работает. В /opt/etc/.kvas/backup/ заезжают уже исправленные предыдущими версиями файлы. К тому же, при полном удалении КВАСа он подчищает и важные бекапы этих конфигов по умолчанию.

При этом защищённый список, конфигурация пакета, подключение shadowsocks сохраняются правильно, в директории КВАС. При полном удалении он удаляет их за собой, это тоже корректно.

Что я по ним предлагаю?

1. Исходные конфиги dnsmasq и dnscrypt и, скорее всего, adguard и adblock надо сохранять там же, где находятся исходные файлы. Как это делает любой пакетный менеджер при конфликтах. Например, рядом с /opt/etc/dnsmasq.conf появится /opt/etc/dnsmasq.default.conf И никогда эти бекапные файлы не удалять и не модифицировать! Не перезаписывать в них изменения от КВАСа, они всегда должны соответствовать тому, что поставил opkg. Даже при полном удалении КВАСа можно будет их восстановить.
2. В самой директории /opt/etc/.kvas/backup/ их модифицированные копии можно продолжать хранить. И перезаписывать, восстанавливать, как в текущем механизме. Но чтобы победить проблему миграции конфигураций от версии к версии (когда восстанавливается конфиг от чужой версии), надо изменить поддиректории на такого типа /opt/etc/.kvas/backup/1.1.8r2/. Тогда вероятность восстановления не своего конфига будет исключена. При этом конфигурация КВАСа останется без поддиректорий (в /opt/etc/.kvas/backup/), она нормально работает при скачке по версиям.
   Возможно, в качестве поддиректории имеет смысл использовать не версию пакета, а завести глобальную переменную типа CONFIG_VERSION. Если при очередной сборке мы снова сменили хоть один системный конфиг, увеличивать её. Например, если в beta4, beta5 и beta6 конфигурации не менялись, то они в общей директории /opt/etc/.kvas/backup/v2/. Новая версия модифицирует хотя бы один из файлов? Всё, её конфиги в /opt/etc/.kvas/backup/v3/. Некий аналог ассетов на коленке.

ipset

Многострадальный файл в /opt/etc/cron.5mins/. Сейчас строчки по его удалению закомменчены. Видимо, имеется ввиду, что сейчас этот файл и не ставится, т.е. и удалять его не нужно. Но очень многие переходят со старых версий. Я и сам делал uninstall full, но одна из старых версий не прибрала его за собой. Сетевую инфраструктуру люди обновляют редко. Даже через год могут приходить люди с обновлением, когда в их системе он выживет. Если учесть, сколько на него жалоб — на всякий случай его надо пытаться удалять даже в будущих версиях.

Как минимум эти два действия сильно уменьшат количество обращений с проблемами.

[qzeleza]

Конфиги

Много требуют изменений, потому вернусь к этому вопросу позже.
Пока остается универсальный вариант - kvas uninstall full

ipset

Поставил на принудительное удаление, если файл существует от старой версии. Выйдет в бете 7.

[AltGrF13]

Чтобы закрыть #210, упоминание малюсенького хвоста перенесу сюда.

По какой-то не понятной причине после kvas uninstall full выживают 3 симлинка

find /opt/etc/ndm/ ! -type d

/opt/etc/ndm/ifcreated.d/kvas-iface-add
/opt/etc/ndm/ifdestroyed.d/kvas-iface-del
/opt/etc/ndm/iflayerchanged.d/kvas-ips-reset

[AltGrF13]

После отбивания отдельных подзадач в #234 и #210, эта остаётся лишь о сохранении конфигов пользователей (т.е. её надо и переименовать). Без этой функции нормально живём, эдакая не приоритетная задача, даже не к релизу.

В самой директории /opt/etc/.kvas/backup/ их модифицированные копии можно продолжать хранить. И перезаписывать, восстанавливать, как в текущем механизме. Но чтобы победить проблему миграции конфигураций от версии к версии (когда восстанавливается конфиг от чужой версии), надо изменить поддиректории на такого типа /opt/etc/.kvas/backup/1.1.8r2/. Тогда вероятность восстановления не своего конфига будет исключена. При этом конфигурация КВАСа останется без поддиректорий (в /opt/etc/.kvas/backup/), она нормально работает при скачке по версиям.
Возможно, в качестве поддиректории имеет смысл использовать не версию пакета, а завести глобальную переменную типа CONFIG_VERSION. Если при очередной сборке мы снова сменили хоть один системный конфиг, увеличивать её. Например, если в beta4, beta5 и beta6 конфигурации не менялись, то они в общей директории /opt/etc/.kvas/backup/v2/. Новая версия модифицирует хотя бы один из файлов? Всё, её конфиги в /opt/etc/.kvas/backup/v3/. Некий аналог ассетов на коленке.