설치 이후 리눅스 시스템의 "나이"를 결정하는 방법은 무엇입니까?


39

특정 파일의 타임 스탬프를 쉽게 확인할 수 있다고 생각했습니다. 그런 다음과 같은 타임 스탬프를 볼 때 쉽지 않을 것이라는 것을 깨달았습니다 1991.


나는이 모든 대답을 사랑하고, 일부를 찬성하고, 그들로부터 배웠습니다. 그러나 그 질문이 잘 정의되어 있지 않다는 것이 나에게 일어났다. 예를 들어, 내 박스는 FS가 덤프 된 상태에서 10 년 동안 마더 보드의 두 가지 화신과 HDD의 네 가지 완전한 변화를 겪었다. 매번 복원되었습니다. 내 ssh 공개 키는 모두 2001 년 2 월 19 일자입니다. 그러나 루트 FS는 mobo가 마지막으로 업그레이드 될 때 (디스크와 함께) 2010 년 6 월 11 일 20:59:01에 만들어졌습니다. 그러나 다른 테스트는 여전히 다른 결과를 주며, 나에게 발생합니다 : Linux 시스템의 연령을 어떻게 정의합니까 (발견하지 않습니까)?
MadHatter는 Monica

4
분명히 이것은 테세우스의 선박 문제라고도합니다. en.wikipedia.org/wiki/Ship_of_Theseus를 참조하십시오 .
MadHatter는 Monica

나는 항상 머신을 구입 한 이후 존재하는 파티션을 가진 hdd를 가지고있다. 나는 새로운 드라이브를 사거나 새로운 커널로 새로운 루트 파티션을 만들 때 백업에 필요한 모든 것을 넣었다. 나에게 발생하지 않았다 :-)
lisak

답변:


47

가장 간단한 방법은 아마도 sda1이라고 가정하면 / root /입니다.

tune2fs -l / dev / sda1 | 그렙 생성

파일 시스템이 작성된 날짜가 표시됩니다. 다른 파일 시스템에 대해서는 잘 모르지만 ext2에서 ext4까지 작동하는 것으로 확인되었습니다!


1
내 PC 용 새 드라이브를 받으면 보통 파티션을 만든 다음 cp -a데이터를 덮어 씁니다. 간단히 말해서 : 모든 경우에 시스템의 수명을 결정할 수는 없습니다.
휴 버트 카리오

아마도 사용 /dev/root이 좀 더 일반적 일 것입니다.
camh

이전 시스템 위에 새 시스템을 설치하여 sda1 FS를 유지 했으므로 MihaiM의 솔루션 (ssh 키)이 더 정확했습니다.
링 Ø

14

내가 자주 사용하는 한 가지 메커니즘은 루트 홈 디렉토리 내의 파일에서 변경 시간 (ctime)을 확인하는 것입니다. /root홈 디렉토리는 설치시 작성되며 거의 사용되지 않기 때문에 비교적 좋은 근사치를 제공 할 수 있습니다. 주석에서 Kyle이 명확히 한 바와 같이, ctime은 데이터가 아닌 inode를 참조하므로 파일 내용을 수정해도 ctime은 변경되지 않습니다.

기본적 ls으로이 명령은 파일의 수정 시간 (mtime)을 인쇄합니다. 따라서 ctime 옵션을 대체하면

ls -alct /root

모든 파일을 인쇄하고 작성 시간을 표시하며 시간별로 정렬합니다.

예를 들어, 다음은 /root내 시스템 중 하나의 디렉토리에서 가장 오래된 3 개의 파일 샘플입니다 .

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

그런 다음 변경 시간을 확인하여

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

2010 년 2 월 18 일은 필자가 해당 시스템을 처음 설치했을 때의 대략적인 시간을 추적합니다.


4
ctime은 실제로 파일 작성 시간이 아니라 변경 시간입니다. 이것은 내가 마지막으로 inode를 변경했을 때입니다. 파일의 권한이나 소유자를 변경하면 변경됩니다. / root 폴더 자체의 소유자 또는 권한이 변경되지 않았을 가능성이 있으므로 이것이 줄을서는 이유입니다. (나는 c가 실제로 무엇을 의미하는지 모른다. 싱글 유닉스 사양은 "time_t st_ctime 마지막 상태 변경 시간"만있다.
Kyle Brandt

실제로 설치 프로그램 로그의 날짜 / 시간입니다. 배포판 / 운영 체제에 따라있을 수도 있고 없을 수도 있습니다.
쿠스 반 덴 호우 트

6

시험

ls -alp /etc/ssh/ssh_host_dsa_key.pub | cut -d " " -f6

OS를 설치할 때 키가 생성됩니다.


3
이것은 좋은 생각이지만 SSH 키에서 일부 약점이 발견되었으며 시스템 업데이트를 완료 한 경우 (시스템 업데이트를 수행해야합니다!) 키가 재생성 된 것입니다.
Josh

훌륭한 아이디어! 그러나 키가 충분히 새로워지면 ls(적어도 내 컴퓨터에서는) 날짜가 다르게 표시되어 cut명령이 제대로 작동하지 않습니다. 나는 이제 사용할 stat -c %y /etc/ssh/ssh_host*pub것이다. 또한 파일 생성 시간이 Linux에서 더 이상 사랑을 얻지 못한 이유가 궁금합니다 ...
Rennex

3

하드웨어를 확인하는 것이 좋은 방법입니다. 시스템 및 / 또는 하드웨어 구성 요소를 검사하여 조립시기를 알 수 있습니다.

또는 BIOS 화면에 액세스 할 수있는 경우 컴퓨터의 나이를 확인하는 데 사용할 수있는 날짜 정보가 종종 있습니다.

하드 드라이브 ( smartctl -a /dev/sda) 의 SMART 정보에 액세스 할 수있는 경우 계속 진행할 수 있습니다. SMART에 특정 타임 스탬프가 표시되지 않지만 적어도 1 시간의 사용 카운터가 있습니다. 하드 드라이브가 100 시간 동안 실행 된 경우 시스템이 100 시간 미만일 수 없기 때문에 시스템의 수명에 대한 하한을 제공합니다.

파일 시스템 검사의 /lost+found경우 파일 시스템을 만들 때 해당 디렉토리가 만들어진 날짜 정보를 볼 수 있습니다. 날짜는 이전 답변의 tunefs 정보와 일치해야합니다.


/lost+found이 정보는 권한이없는 사용자가 사용할 수 있으므로 힌트를 +1 하십시오. 수퍼 유저로서 루트 파일 시스템에서 tune2fs와 같은 배치 작업을 실행하는 것은 약간 걱정입니다. 또한이 솔루션은 FreeBSD 및 비 ext2 / 3 / 4 파일 시스템에서 작동합니다.
Stefan Lasiewski

3

RedHat 및 파생 제품을 사용하면 파일 수명과 다른 시스템 파일의 조합을 통해 OS 버전 / 빈티지에 대한 일반적인 아이디어를 쉽게 얻을 수 있습니다. /root/anaconda-ks.cfg초기 서버 설정 및 패키지 매개 변수가 포함되어 있으므로 일반적으로 파일을 확인합니다 . 때로는 uname -a커널 빌드 날짜에 대한 좋은 정보가 있습니다. /etc;에 같은 날짜를 가진 파일 클러스터도 있습니다 . 일반적으로 rcx.d 링크, rc 스크립트, inittab 등


3

이것은 Red Hat 시스템에서도 작동합니다 :

rpm -qi basesystem | grep "Install Date"

이 (및 tune2fs 트릭)는 가상 머신이 공통 이미지에서 분리되는 경우 가상 머신에서 잘 작동하지 않습니다. ssh 호스트 키 확인은 Linode에서 정확합니다.
cjc
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.