Несколько версий Ubuntu, обновляющих одну и ту же базу данных vnstat
Я тестировал обновление Ubuntu 16.04 до 18.04. Я обновился на прошлой неделе и сегодня вечером перезагрузил 18.04. Обратите внимание, что conky показывает пробелы для vnstat:
- «Вчера» пусто, но должно быть 8,76 ГБ . [+1112]
- "Неделя" показывает 7 ГБ, но должна быть 32,33 ГБ + 2,52 ГБ для загрузки 18.04 вечером.
- «Месяц» показывает 45,63 ГБ, но на самом деле он составляет около 70 ГБ.
Причина в 16.04, а 18.04 имеют отдельные базы данных, которые не синхронизируются, когда я клонирую 16.04 для тестирования раздела и обновления до 18.04. : Сценарий Bash для клонирования Ubuntu в новый раздел для тестирования 18.04 Обновление LTS
Как можно установить Ubuntu 16.04 в одном разделе и Ubuntu 18.04 в другом разделе, которые обновляют одну и ту же базу данных vnstat? Я хотел бы сохранить базу данных в третьем разделе (ntfs Файловая система), уже настроенном для совместного использования данных подсистемы Windows для Linux (WSL) и данных Ubuntu.
Бонус: при условии, что я могу собирать статистику ежедневных RX / TX / Total в Windows, как я могу заполнить их в базе данных vnstat?
РЕДАКТИРОВАТЬ 1: Использование Принятые ответы 16.04 и 18.04 обновляют vnstat файлы данных версии 16.04 в отформатированном разделе ntfs /mnt/e/var/lib/vnstat/. Мне пришлось откатить Ubuntu 18.04 vnstat версии 1.18 и прикрепить его к Ubuntu 16.04 версии 1.13 или 1.14-1.
Следующим шагом будет заставить Windows 10 WSL «видеть» данные и как-то отображать их. После этого получите WSL для запуска демона vnstatd при загрузке и сбора / обновления статистики пропускной способности сети.
1 ответ
версии 1.3 - 1.18 vnStat используют ту же структуру базы данных, настолько совместно использующая база данных с теми версиями возможна пока
- обе установки совместно используют те же названия сетевого интерфейса
- существует перезагрузка при изменении между средами
- процессы демона не получают доступ к файлам базы данных одновременно
- владельцы файла базы данных соответствуют
Как в Вашем случае двойная загрузка рассматриваема, эти ограничения не должны быть проблемой, принимая соответствие названий сетевого интерфейса.
Каталог базы данных должен быть перемещен в местоположение, это доступно обеими средами. В конфигурационном файле /etc/vnstat.conf корректное ключевое слово для поиска DatabaseDir. С рассматриваемым ntfs можно также хотеть отключить UseFileLocking и CheckDiskSpace избегать неожиданностей. Это, вероятно, также помогло бы отключить CreateDirs и UpdateFileOwner. Обратите внимание, что монтирование должно быть доступным, прежде чем vnStat демон будет запущен.
Редактирования конфигурационного файла требуют перезапуска или перезагрузки демона. Также лучше сохранить демона остановленным при создании копии каталога базы данных. Необходимо будет также синхронизировать изменения конфигурационного файла в обеих средах, после того, как изменено.
Премия
В теории, которая могла быть возможной. Я предположил бы, что должно быть возможно добраться vnstat команда, работающая в Windows Subsystem на Linux. После того как это работает затем, возможно использовать --exportdb функциональность для дампа содержания базы данных в файл ASCII затем добавьте собранные данные к существующим числам (который не может точно быть простым), и затем используйте --importdb импортировать назад изменения и перезаписывать существующую базу данных.
Возможно более легкая альтернатива должна была бы использовать vnStat 2.0 в обеих средах. Это привело бы к наличию sqlite базы данных, содержащей данные, и я предположу, что существуют инструменты Windows, доступные для управления существующими данными. Эта опция потребовала бы меньшего количества шагов, но однако все еще требует, чтобы некоторый контакт с путем vnStat хранил данные в базе данных.