¿Cómo determinar la "edad" de un sistema Linux desde la instalación?
39
Pensé que podría verificar fácilmente la marca de tiempo de determinados archivos. Entonces me di cuenta de que no sería tan fácil cuando vi marcas de tiempo como 1991.
Me encantan todas estas respuestas, he votado algunas y aprendí de ellas. Pero se me ocurre que la pregunta no está bien definida: por ejemplo, mi caja colorada ha pasado por dos encarnaciones de placa base y cuatro cambios completos de HDD en los diez años que lleva funcionando, con el FS volcado | restaurado cada vez. Todas mis claves públicas ssh están fechadas el 19 de febrero de 2001; pero el FS raíz fue creado el 11 de junio de 2010, 20:59:01, cuando el mobo se actualizó por última vez (junto con los discos); otras pruebas dan resultados aún diferentes, y se me ocurre: ¿cómo define (no descubre) la edad de un sistema Linux?
Siempre tengo un disco duro con una partición que existe desde que compré la máquina ... Puse todas las cosas que necesito para hacer una copia de seguridad allí cuando compro una nueva unidad o creo una nueva partición raíz con kernel nuevo ... Pero no se me ocurrió :-)
lisak
Respuestas:
47
La forma más sencilla probablemente sería (suponiendo que sda1 es su / root /):
tune2fs -l / dev / sda1 | grep creado
Esto debería mostrarle la fecha en que se creó el sistema de archivos. Confirmado para trabajar en ext2 a ext4, ¡no estoy seguro acerca de otros sistemas de archivos!
Cuando obtengo una nueva unidad para mis PC, generalmente creo particiones y luego los cp -adatos. En resumen: no es posible determinar la edad del sistema en todos los casos.
Hubert Kario el
Quizás usar /dev/rootes un poco más general.
camh
Instalé un nuevo sistema sobre el anterior, manteniendo el sda1 FS y, por lo tanto, la solución de MihaiM a continuación (teclas ssh) fue más precisa.
Anillo Ø
14
Un mecanismo que uso a menudo es verificar el tiempo de cambio (ctime) en los archivos dentro del directorio de inicio raíz. Dado que el /rootdirectorio de inicio se crea en el momento de la instalación y rara vez se usa, esto puede proporcionar una aproximación relativamente buena. Como aclaró Kyle en los comentarios, dado que ctime se refiere al inodo y no a los datos, la modificación del contenido del archivo no cambiará el ctime.
Por defecto, el lscomando imprime el tiempo de modificación (mtime) del archivo. Entonces, si se sustituye en la opción ctime así,
ls -alct /root
Esto imprimirá todos los archivos, mostrará el tiempo de creación y ordenará por tiempo.
Como ejemplo, aquí hay una muestra de los 3 archivos más antiguos en el /rootdirectorio de uno de mis sistemas.
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
Y luego comprobando el tiempo de cambio
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 fecha del 18 de febrero de 2010 sin duda coincide con el tiempo aproximado que habría instalado ese sistema por primera vez.
ctime en realidad no es el tiempo de creación de un archivo, sino el tiempo de cambio. Esta es la última vez que hice un cambio en el inodo. Si cambia los permisos o el propietario de un archivo, esto cambiaría. Es probable que el propietario o los permisos de la carpeta / root en sí no hayan cambiado, por lo que esto se está alineando. (No sé qué significa realmente la c: la especificación de Unix solo tiene "time_t st_ctime Hora del último cambio de estado".
Kyle Brandt
De hecho, la fecha / hora del registro del instalador. Que puede o no estar allí dependiendo de su distribución / os.
Koos van den Hout
6
tratar
ls -alp /etc/ssh/ssh_host_dsa_key.pub | cut -d " " -f6
las claves se generan cuando instala el sistema operativo.
Esta es una buena idea, sin embargo, se han encontrado algunas debilidades en las claves SSH y si ha realizado actualizaciones del sistema (¡y debería estar haciendo actualizaciones del sistema!), Entonces las claves se habrían regenerado.
Josh
¡Excelente idea! Sin embargo, si la clave es lo suficientemente nueva, lsmuestra la fecha de manera diferente (al menos en mi máquina) para que el cutcomando no funcione correctamente. Ahora lo usaría stat -c %y /etc/ssh/ssh_host*pub. Además, me pregunto por qué los tiempos de creación de archivos no han recibido más amor en Linux ...
Rennex
3
Verificar el hardware sería una buena apuesta, si tiene acceso a él. Puede inspeccionar el sistema y / o los componentes de hardware para tener una buena idea de cuándo se ensambló.
Alternativamente, si puede obtener acceso a la pantalla del BIOS, a menudo hay información de fecha que se puede usar para determinar la antigüedad de una máquina.
Si puede obtener acceso a la información SMART en el disco duro ( smartctl -a /dev/sda), puede haber algo para continuar. No veo una marca de tiempo específica en SMART, pero hay al menos un contador de horas de uso. Eso proporcionaría un límite inferior de la antigüedad de la máquina (ya que si el disco duro ha estado funcionando durante 100 horas, el sistema no puede ser menor de 100 horas).
En cuanto a las comprobaciones del sistema de archivos, puede consultar la información de la fecha /lost+found: ese directorio se creó cuando se creó el sistema de archivos. La fecha debe coincidir con la información de tunefs de la respuesta anterior.
+1 para la /lost+foundpista, ya que esta información está disponible para usuarios no privilegiados. Ejecutar una operación por lotes como tune2fs en los sistemas de archivos raíz ya que el superusuario es un poco preocupante. Además, esta solución funciona en FreeBSD y en sistemas de archivos no ext2 / 3/4.
Stefan Lasiewski
3
Con RedHat y sus derivados, es bastante fácil tener una idea general de la versión / vintage del sistema operativo a través de una combinación de antigüedad del archivo y otros archivos del sistema. Por lo general, revisaré el /root/anaconda-ks.cfgarchivo, ya que contiene la configuración inicial del servidor y los parámetros del paquete. A veces uname -atendrá buena información sobre la fecha de compilación del núcleo. También habría un grupo de archivos con la misma fecha /etc; típicamente los enlaces rcx.d, scripts rc, inittab, etc.
Tenga en cuenta que esto (y el truco tune2fs) funciona menos bien con las máquinas virtuales, si se hacen girar desde una imagen común. Sin embargo, la comprobación de las claves de host ssh es precisa en mi Linode.
Respuestas:
La forma más sencilla probablemente sería (suponiendo que sda1 es su / root /):
Esto debería mostrarle la fecha en que se creó el sistema de archivos. Confirmado para trabajar en ext2 a ext4, ¡no estoy seguro acerca de otros sistemas de archivos!
fuente
cp -adatos. En resumen: no es posible determinar la edad del sistema en todos los casos./dev/rootes un poco más general.Un mecanismo que uso a menudo es verificar el tiempo de cambio (ctime) en los archivos dentro del directorio de inicio raíz. Dado que el
/rootdirectorio de inicio se crea en el momento de la instalación y rara vez se usa, esto puede proporcionar una aproximación relativamente buena. Como aclaró Kyle en los comentarios, dado que ctime se refiere al inodo y no a los datos, la modificación del contenido del archivo no cambiará el ctime.Por defecto, el
lscomando imprime el tiempo de modificación (mtime) del archivo. Entonces, si se sustituye en la opción ctime así,Esto imprimirá todos los archivos, mostrará el tiempo de creación y ordenará por tiempo.
Como ejemplo, aquí hay una muestra de los 3 archivos más antiguos en el
/rootdirectorio de uno de mis sistemas.Y luego comprobando el tiempo de cambio
La fecha del 18 de febrero de 2010 sin duda coincide con el tiempo aproximado que habría instalado ese sistema por primera vez.
fuente
tratar
las claves se generan cuando instala el sistema operativo.
fuente
lsmuestra la fecha de manera diferente (al menos en mi máquina) para que elcutcomando no funcione correctamente. Ahora lo usaríastat -c %y /etc/ssh/ssh_host*pub. Además, me pregunto por qué los tiempos de creación de archivos no han recibido más amor en Linux ...Verificar el hardware sería una buena apuesta, si tiene acceso a él. Puede inspeccionar el sistema y / o los componentes de hardware para tener una buena idea de cuándo se ensambló.
Alternativamente, si puede obtener acceso a la pantalla del BIOS, a menudo hay información de fecha que se puede usar para determinar la antigüedad de una máquina.
Si puede obtener acceso a la información SMART en el disco duro (
smartctl -a /dev/sda), puede haber algo para continuar. No veo una marca de tiempo específica en SMART, pero hay al menos un contador de horas de uso. Eso proporcionaría un límite inferior de la antigüedad de la máquina (ya que si el disco duro ha estado funcionando durante 100 horas, el sistema no puede ser menor de 100 horas).En cuanto a las comprobaciones del sistema de archivos, puede consultar la información de la fecha
/lost+found: ese directorio se creó cuando se creó el sistema de archivos. La fecha debe coincidir con la información de tunefs de la respuesta anterior.fuente
/lost+foundpista, ya que esta información está disponible para usuarios no privilegiados. Ejecutar una operación por lotes como tune2fs en los sistemas de archivos raíz ya que el superusuario es un poco preocupante. Además, esta solución funciona en FreeBSD y en sistemas de archivos no ext2 / 3/4.Con RedHat y sus derivados, es bastante fácil tener una idea general de la versión / vintage del sistema operativo a través de una combinación de antigüedad del archivo y otros archivos del sistema. Por lo general, revisaré el
/root/anaconda-ks.cfgarchivo, ya que contiene la configuración inicial del servidor y los parámetros del paquete. A vecesuname -atendrá buena información sobre la fecha de compilación del núcleo. También habría un grupo de archivos con la misma fecha/etc; típicamente los enlaces rcx.d, scripts rc, inittab, etc.fuente
Esto también funciona para los sistemas Red Hat:
fuente