Plusieurs versions d'Ubuntu mettant à jour la même base de données vnstat
J'ai testé la mise à niveau d'Ubuntu 16.04 à 18.04. J'ai mis à jour la semaine dernière et j'ai redémarré 18.04 ce soir. Remarquez comment conky affiche les écarts pour vnstat:
- "Hier" est vide mais il devrait y avoir 8,76 Go.
- "Semaine" affiche 7 Go mais devrait être de 32,33 Go + 2,52 Go pour un démarrage de 18,04 ce soir.
- "Mois" affiche 45,63 Go mais il s'agit vraiment d'environ 70 Go
La raison en est que 16.04 et 18.04 ont des bases de données distinctes qui ne sont pas synchronisées lorsque je clone 16.04 pour tester la partition et la mise à niveau vers 18.04: script Bash pour cloner Ubuntu vers une nouvelle partition pour tester la mise à niveau 18.04 LTS
Comment puis-je avoir Ubuntu 16.04 sur une partition et Ubuntu 18.04 sur une autre partition mettant à jour la même base de données vnstat? Je voudrais stocker la base de données sur une troisième partition (ntfs File System) déjà configurée pour partager les données du sous-système Windows pour Linux (WSL) et les données Ubuntu.
Bonus: en supposant que je puisse collecter les statistiques quotidiennes RX/TX/Total sous Windows, comment puis-je les remplir dans la base de données vnstat?
EDIT 1: Les réponses acceptées 16.04 et 18.04 mettent à jour vnstat les fichiers de données de version 16.04 dans la partition formatée ntfs /mnt/e/var/lib/vnstat/. J'ai dû restaurer Ubuntu 18.04 vnstat version 1.18 et l'épingler à Ubuntu 16.04 version 1.13 aka 1.14-1.
La prochaine étape consistera à obtenir Windows 10 [~ # ~] wsl [~ # ~] pour "voir" les données et les afficher d'une manière ou d'une autre. Après cela, obtenez [~ # ~] wsl [~ # ~] pour exécuter le démon vnstatd au démarrage et collecter/mettre à jour les statistiques de bande passante du réseau .
les versions 1.3 à 1.18 de vnStat utilisent la même structure de base de données, il est donc possible de partager une base de données avec ces versions tant que
- les deux installations partagent les mêmes noms d'interface réseau
- il y a un redémarrage lors du changement entre les environnements
- les processus démons n'accèdent pas aux fichiers de base de données en même temps
- les propriétaires de fichiers de base de données correspondent
Comme dans votre cas, un double démarrage est en question, ces limitations ne devraient pas être un problème, en supposant que les noms d'interface réseau correspondent.
Le répertoire de la base de données doit être déplacé vers un emplacement accessible par les deux environnements. Dans le fichier de configuration /etc/vnstat.conf le mot-clé correct à rechercher est DatabaseDir. Avec ntfs en question, vous pouvez également désactiver UseFileLocking et CheckDiskSpace pour éviter les surprises. Il serait également utile de désactiver CreateDirs et UpdateFileOwner. Notez que le montage doit être disponible avant le démarrage du démon vnStat.
Les modifications du fichier de configuration nécessitent un redémarrage ou un rechargement du démon. Il est également préférable de garder le démon arrêté lors de la copie du répertoire de la base de données. Vous devrez également synchroniser les modifications du fichier de configuration avec les deux environnements après les avoir modifiées.
Bonus
En théorie, cela pourrait être possible. Je suppose qu'il devrait être possible de faire fonctionner la commande vnstat dans le sous-système Windows pour Linux. Une fois que cela fonctionne, il est possible d'utiliser le --exportdb fonctionnalité pour vider le contenu de la base de données dans un fichier ascii, puis ajouter les données collectées aux numéros existants (qui peuvent ne pas être très simples), puis utiliser --importdb pour réimporter les modifications et écraser la base de données existante.
L'alternative peut-être la plus simple serait d'utiliser vnStat 2.0 dans les deux environnements. Cela entraînerait une base de données sqlite contenant les données et je suppose qu'il existe des outils Windows disponibles pour manipuler les données existantes. Cette option nécessiterait moins d'étapes, mais nécessite néanmoins une certaine gestion de la façon dont vnStat stocke les données dans la base de données.