Comment déterminer «l'âge» d'un système Linux depuis son installation?
39
J'ai pensé que je pourrais facilement vérifier l'horodatage de fichiers particuliers. Puis j'ai réalisé que ce ne serait pas si facile de voir des horodatages, par exemple 1991.
J'adore toutes ces réponses, j'en ai voté certaines et j'en ai tiré des leçons. Mais je me rends compte que la question n’est pas bien définie: par exemple, ma boîte aux lettres a subi deux incarnations de la carte mère et quatre changements complets du disque dur au cours des dix années d’existence, le système de fichiers FS étant dump | restauré à chaque fois. Toutes mes clés publiques ssh sont datées du 19 février 2001; mais la racine FS a été créée le 11 juin 2010 à 20:59:01 lors de la dernière mise à jour du mobo (avec les disques); d'autres tests donnent encore des résultats différents, et il me semble: comment définissez-vous (ne découvrez-vous pas) l'âge d'un système Linux?
J'ai toujours un disque dur avec une partition qui existe depuis que j'ai acheté la machine ... Je mets tout ce dont j'ai besoin pour sauvegarder quand j'achète un nouveau disque ou crée une nouvelle partition racine avec un nouveau noyau ... Mais ça ne me suis pas
venu à l'esprit
Réponses:
47
Le moyen le plus simple serait probablement (en supposant que sda1 soit votre / racine /):
tune2fs -l / dev / sda1 | grep créé
Cela devrait vous montrer la date à laquelle le système de fichiers a été créé. Confirmé de travailler sur ext2 à ext4, pas sûr des autres systèmes de fichiers!
Lorsque je reçois un nouveau lecteur pour mon PC, je crée généralement des partitions dessus, puis des cp -adonnées. En bref, il n'est pas possible de déterminer l'âge du système dans tous les cas.
Hubert Kario
Peut-être que l’utilisation /dev/rootest un peu plus générale.
camh le
J'ai installé un nouveau système par rapport au précédent, en conservant le sda1 FS, et donc la solution de MihaiM ci-dessous (clés ssh) était plus précise.
Bague Ø
14
Un mécanisme que j'utilise souvent est de vérifier l'heure de changement (ctime) des fichiers du répertoire de base. Etant donné que le /rootrépertoire personnel est créé au moment de l’installation et est rarement utilisé, cela peut fournir une relativement bonne approximation. Comme l'a expliqué Kyle dans les commentaires, ctime faisant référence à l'inode et non aux données, la modification du contenu du fichier ne modifiera pas ctime.
Par défaut, la lscommande affiche l'heure de modification (mtime) du fichier. Donc, si substituer dans l'option ctime comme tel,
ls -alct /root
Ceci imprimera tous les fichiers, affichera l'heure de création et triera par heure.
À titre d'exemple, voici un exemple des 3 fichiers les plus anciens du /rootrépertoire provenant de l'un de mes systèmes.
ls -alt install.log.syslog .cshrc .tcshrc
-rw-r--r--. 1 root 10238 Feb 18 2010 install.log.syslog
-rw-r--r--. 1 root 129 Dec 3 2004 .tcshrc
-rw-r--r--. 1 root 100 Sep 22 2004 .cshrc
Et puis en vérifiant l'heure du changement
ls -alct install.log.syslog .cshrc .tcshrc
-rw-r--r--. 1 root 100 Feb 18 2010 .cshrc
-rw-r--r--. 1 root 10238 Feb 18 2010 install.log.syslog
-rw-r--r--. 1 root 129 Feb 18 2010 .tcshrc
La date du 18 février 2010 est certainement conforme à l'heure approximative à laquelle j'aurais installé ce système pour la première fois.
En fait, ctime n'est pas l'heure de création d'un fichier, mais l'heure du changement. C'est la dernière fois que j'ai changé d'inode. Si vous modifiez les autorisations ou le propriétaire d'un fichier, cela changera. Il est fort probable que le propriétaire ou les autorisations du dossier / root lui-même n’ont pas changé, ce qui explique pourquoi il s’aligne. (Je ne sais pas ce que signifie réellement le c - La spécification unix simple a simplement "time_t st_ctime Heure du dernier changement de statut".
Kyle Brandt le
En effet, la date / heure du journal de l’installateur. Qui peut ou peut ne pas être là selon votre distribution / OS.
Koos van den Hout
6
essayer
ls -alp /etc/ssh/ssh_host_dsa_key.pub | cut -d " " -f6
les clés sont générées lors de l'installation du système d'exploitation.
C'est une bonne idée, mais certaines faiblesses ont été trouvées dans les clés SSH et si vous avez effectué des mises à jour du système (et vous devriez le faire!), Les clés auraient été régénérées.
Josh
Excellente idée! Toutefois, si la clé est suffisamment nouvelle, lsla date est affichée différemment (du moins sur ma machine), de sorte que la cutcommande ne fonctionne pas correctement. Je voudrais maintenant utiliser stat -c %y /etc/ssh/ssh_host*pub. De plus, je me demande pourquoi les temps de création de fichiers n'ont pas eu plus d'amour sous Linux ...
Rennex
3
Vérifier le matériel serait un bon choix si vous y avez accès. Vous pouvez inspecter le système et / ou les composants matériels pour avoir une idée précise du moment de son assemblage.
Alternativement, si vous pouvez accéder à l'écran du BIOS, il y a souvent des informations de date qui peuvent être utilisées pour déterminer l'âge d'une machine.
Si vous pouvez accéder aux informations SMART sur le disque dur ( smartctl -a /dev/sda), il y a peut-être quelque chose à ajouter. Je ne vois pas d'horodatage spécifique dans SMART, mais il existe au moins un compteur d'heures d'utilisation. Cela donnerait une limite inférieure sur l'âge de la machine (étant donné que si le disque dur a fonctionné pendant 100 heures, le système ne peut pas être plus jeune que 100 heures).
En ce qui concerne les vérifications du système de fichiers, vous pouvez consulter les informations de date /lost+found- ce répertoire a été créé lors de la création du système de fichiers. La date indiquée devrait correspondre aux informations de tunefs de la réponse précédente.
+1 pour l' /lost+foundindice, car cette information est disponible pour les utilisateurs non privilégiés. Exécuter une opération batch telle que tune2fs sur des systèmes de fichiers racine en tant que superutilisateur est un peu inquiétant. De plus, cette solution fonctionne sur des systèmes de fichiers FreeBSD et non-ext2 / 3/4.
Stefan Lasiewski
3
Avec RedHat et ses dérivés, il est assez facile de se faire une idée générale de la version / de l’ancien du système d’exploitation en combinant l’âge des fichiers et d’autres fichiers système. Je vérifie généralement le /root/anaconda-ks.cfgfichier, car il contient la configuration initiale du serveur et les paramètres du package. Parfois uname -a, vous aurez de bonnes informations sur la date de construction du noyau. Il y aurait également un groupe de fichiers avec la même date dans /etc; typiquement les liens rcx.d, les scripts rc, inittab, etc.
Notez que cela (et l'astuce tune2fs) fonctionne moins bien avec les machines virtuelles, si elles sont générées à partir d'une image commune. La vérification des clés d’hôte ssh est précise sur mon Linode, cependant.
Réponses:
Le moyen le plus simple serait probablement (en supposant que sda1 soit votre / racine /):
Cela devrait vous montrer la date à laquelle le système de fichiers a été créé. Confirmé de travailler sur ext2 à ext4, pas sûr des autres systèmes de fichiers!
la source
cp -adonnées. En bref, il n'est pas possible de déterminer l'âge du système dans tous les cas./dev/rootest un peu plus générale.Un mécanisme que j'utilise souvent est de vérifier l'heure de changement (ctime) des fichiers du répertoire de base. Etant donné que le
/rootrépertoire personnel est créé au moment de l’installation et est rarement utilisé, cela peut fournir une relativement bonne approximation. Comme l'a expliqué Kyle dans les commentaires, ctime faisant référence à l'inode et non aux données, la modification du contenu du fichier ne modifiera pas ctime.Par défaut, la
lscommande affiche l'heure de modification (mtime) du fichier. Donc, si substituer dans l'option ctime comme tel,Ceci imprimera tous les fichiers, affichera l'heure de création et triera par heure.
À titre d'exemple, voici un exemple des 3 fichiers les plus anciens du
/rootrépertoire provenant de l'un de mes systèmes.Et puis en vérifiant l'heure du changement
La date du 18 février 2010 est certainement conforme à l'heure approximative à laquelle j'aurais installé ce système pour la première fois.
la source
essayer
les clés sont générées lors de l'installation du système d'exploitation.
la source
lsla date est affichée différemment (du moins sur ma machine), de sorte que lacutcommande ne fonctionne pas correctement. Je voudrais maintenant utiliserstat -c %y /etc/ssh/ssh_host*pub. De plus, je me demande pourquoi les temps de création de fichiers n'ont pas eu plus d'amour sous Linux ...Vérifier le matériel serait un bon choix si vous y avez accès. Vous pouvez inspecter le système et / ou les composants matériels pour avoir une idée précise du moment de son assemblage.
Alternativement, si vous pouvez accéder à l'écran du BIOS, il y a souvent des informations de date qui peuvent être utilisées pour déterminer l'âge d'une machine.
Si vous pouvez accéder aux informations SMART sur le disque dur (
smartctl -a /dev/sda), il y a peut-être quelque chose à ajouter. Je ne vois pas d'horodatage spécifique dans SMART, mais il existe au moins un compteur d'heures d'utilisation. Cela donnerait une limite inférieure sur l'âge de la machine (étant donné que si le disque dur a fonctionné pendant 100 heures, le système ne peut pas être plus jeune que 100 heures).En ce qui concerne les vérifications du système de fichiers, vous pouvez consulter les informations de date
/lost+found- ce répertoire a été créé lors de la création du système de fichiers. La date indiquée devrait correspondre aux informations de tunefs de la réponse précédente.la source
/lost+foundindice, car cette information est disponible pour les utilisateurs non privilégiés. Exécuter une opération batch telle que tune2fs sur des systèmes de fichiers racine en tant que superutilisateur est un peu inquiétant. De plus, cette solution fonctionne sur des systèmes de fichiers FreeBSD et non-ext2 / 3/4.Avec RedHat et ses dérivés, il est assez facile de se faire une idée générale de la version / de l’ancien du système d’exploitation en combinant l’âge des fichiers et d’autres fichiers système. Je vérifie généralement le
/root/anaconda-ks.cfgfichier, car il contient la configuration initiale du serveur et les paramètres du package. Parfoisuname -a, vous aurez de bonnes informations sur la date de construction du noyau. Il y aurait également un groupe de fichiers avec la même date dans/etc; typiquement les liens rcx.d, les scripts rc, inittab, etc.la source
Cela fonctionne également pour les systèmes Red Hat:
la source