< eun2jong.com > 은이종

1. 리눅스 부팅 과정 이해의 필요성

리눅스 부팅 시 커널패닉이나 파일시스템 에러 같은 경우를 만났을 때 어떻게 해야 할지 몰라 당황하는 경우가 있다. 리눅스 부팅 과정의 이해를 통해 이러한 에러 상황을 효과적으로 대처 할 수 있다.

2. 리눅스 부팅 과정의 이해

1) 전원 ON

2) BIOS 프로그램 실행 – CPU, MEMORY, VGA 같은 하드웨어에 대한 진단 테스트(POST)를 실행한다. 이상 발생시 비프 음을 내며 멈춘다. POST(Power On Self Test)과정이 이상없이 수행되면 부트디바이스의 MBR(하드 디스크의 첫 섹터,크기는 512 byte)에서 부트로더를 불러들인다.

3) 부트로더가 실행되면 레드햇계열에서는 보통 다음과 같은 메시지가 출력되며 GRUB(GRUB이부트로더이다)이 실행된다. GRUB은 커널이미지를 메모리에 로드한다.

Booting Red Hat Enterprise Linux Server (2.6.18-8.el5) in 5 seconds...

4) 그 다음 커널에 의한 초기화가 실행되고 드라이버의 적재가 이루어 진다. 이 과정은dmesg명령이나 /var/log/dmesg 파일에서 확인 할 수 있다. 보통 다음과 같은 것들을 확인 할 수 있다.

커널버전 표시

램 용량 표시

CPU관련 정보 표시

SELinux 상태 표시

Kernel command line 명령 확인

램디스크 할당 (initramfs)

하드드라이브와 파티션 확인

네트워크 카드 확인

파일시스템 활성화

스왑 활성화

5)커널과 드라이버가 로드된 다음에는 /sbin/init 프로세스가 부팅 과정을 마무리 한다. 이때 실행되는 순서를 간략하게나마 나열하면

/sbin/init à /etc/inittab à /etc/rc.d/rc.sysinit à 각 런 레벨 서비스 스크립트

--> /etc/rc.local à 로그인 프롬프트

로 나타낼 수 있다.

3. 각 과정 별 트러블슈팅

1) grub.conf 파일이 손상되거나 내용이 변경되었을때

증상

부팅시 GURB관련 메뉴가 나오지 않음

부팅시 GRUB 콘솔 상태로 바로 이동

mv /boot/grub/grub.conf /boot/grub/grub.conf_bak

해결방법

GRUB 콘솔 명령어로 사용하여 부팅

grub 환경설정파일 손상

root (hd0,0)

cat /etc/fstab

find /etc/fstab

kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/sda7

initrd /initrd-2.6.18-92.el5.img

boot

부팅후 GRUB관련 설정을 점검하고 원인을 찾아 해결한다.

GRUB을 재 설치 한다.

2) MBR 손상시 복구하기

BIOS가 POST과정을 끝마치면 하드디스크의 첫번째 섹터를 읽어드린다. 이부분을 MBR이라고 한다. MBR에는 부트로더와 파티션 정보가 들어있다. 다음과 같은 명령어로 부트로더를 지울 수 있다.

dd if=/dev/zero of=/dev/sda bs=446 count=1

bs를 512로 하면 파티션 정보까지 모두 손상되므로 테스트 서버 외에는 절대 실행하면 안된다. GRUB(부트로더)는 446바이트이내에 설치 되어 있다.

이제 복구를 해보자.

1번 시디로 부팅

#linux rescue

#chroot /mnt/sysimage

#/sbin/grub

grub-install /dev/sda

find /grub/stage1

find /grub/grub.conf

혹은

#/sbin/grub

root(hd0,0)

setup (hd0)

위와같이 GRUB을 재설치하고 리부팅한다.

3) /etc/fstab 손상시

cat /proc/mounts

mount –o remount,rw /

cat /proc/mounts

vi /etc/fstab

에러난 부분 수정후 리부팅

4)/sbin/init 명령어 손상시

rm /sbin/init

/bin/sh: ro: No such file or directory

Kernel panic - not syncing: Attempted to kill init!

SysVinit-2.86-14.i386.rpm 재설치

# linux rescue

#chroot /mnt/sysimage

#ftp 222.239.223.108

#cd centos/5.2/CentOS

#mget Sys*

rpm -Uvh –force SysVinit-2.86-14.i386.rpm

rpm -Vf /sbin/init

chroot /mnt/sysimage

/bin/bash 파일 손상시 다음과 같은 에러 메시지가 나온다.

chroot: cannot run command '/bin/sh' : No such file or directory

#ftp 222.239.223.108

#cd centos/5.2/CentOS

#mget bash*

rpm -Uvh --force --root=/mnt/sysimage bash-*.rpm

기타

/etc/initab, /etc/rc.d/rc.sysinit à initscripts-8.45.19.1.EL-1.el5.centos

주의사항: 시스템을 새로 설치하는게 빠른지 아니면 복구하는게 빠른지 판단을 하여 가장 빠른 복구 프로세스를 수행한다. 자료 백업과 보존을 최우선으로 한다. 가장 안전한 방법을 고른다.

4. 파일 시스템 오류검사 및 복구 요령

파일 시스템이 손상되었을 때 부팅중 문제가 발생 할 수 있다. 파일 시스템이 손상 되었을때의 대표적인 증상은 아래와 같다.

1) 파티션이 Read Only로 마운트 되면서 파일이 생성되지 않는다.

2) 부팅 과정 중 Ctrl+D 입력을 요구 하면서 더 이상 진행이 되지 않는다.

3) 파일시스템이 손상되었을 경우 dmesg명령어나 /var/log/messages에 에러가 남는다.

이러한 상황이 발생 했을 때 fsck명령으로 쉽게 복구 할 수 있다. 다만 파일시스템을 복구할 때 몇 가지 주의 사항이 있는데 이를 지키지 않을 시 데이터를 날려버릴 위험이 있으므로 반드시 다음 주의 사항을 지키면서 복구를 해야 한다.

먼저 파일 시스템을 마운트 시킨 상태에서 복구를 해서는 안된다.

df –h

cat /proc/mounts

명령으로 손상된 파티션이 마운트 되어 있는지 확인한다.

마운트 되어 있으면 umount 시킨 상태에서 복구 명령을 실행 시켜야 한다.

그러면 / 파티션 같은 경우에는 어떻게 복구해야 할까? / 파티션을 umount 시킨다면 복구명령을 실행 할 수 없으니 이런 의문이 당연히 떠 오를 것이다. 이럴때는 다음과 같이 / 파티션을Read Only로 remount 시킨다음 체크를 실행한다.

#cat /proc/mounts

/dev/root / ext3 rw,data=ordered 0 0

와 같은 줄이 보인다. 다음 명령으로 / 파티션을 Read Only로 마운트 시킬 수 있다.

#mount -o remount,ro /

/dev/root / ext3 ro,data=ordered 0 0

/var /usr 파티션 같은 경우 다음과 같은 에러를 내면서 umount가 되지 않을 수도 있다. /usr파티션이 사용되고 있기 때문이다.

umount /usr

umount: /usr: device is busy

umount: /usr: device is busy

그러므로 가장 확실한 방법은 잠시 서비스를 내리고 다음과 같이 1번 시디를 이용해서rescue모드로 부팅을 해서 복구하는 방법이다.

#linux rescue nomount

/dev/sda1 파티션이 ext3 파일 시스템을 사용 하고 있을 때 다음과 같은 명령어로 복구 시킬 수 있다.

#e2fsck –j ext3 –vy /dev/sda1

badblock이 생겼을 때는 -c옵션을 주면 badblock을 체크한다. 그러나 가능하면 badblock이 생겼을 경우 빠른 시간내에 하드를 교체하는 것이 최선이다.

또한 손상 정도가 심한 경우는 파일시스템을 복구해도 차후 같은 증상을 가져 올 수 있기 때문에 서비스를 올린다음 해당 디스크를 교체하는 것이 좋다.

superblock이 손상되었을 경우 다음과 같은 명령어로 복구 시킬 수 있다.

#dumpe2fs /dev/hda1

명령어로 해당 파티션이 정보를 본다. 슈퍼블럭을 확인하고 다음과 같이 복구한다.

#fsck -b 8193 /dev/hda1

슈퍼블럭은 여러 백업본이 있기 때문에 하나가 안되면 다음과 같이 다음 슈퍼블럭을 선택해서 복구하면 된다.
#fsck -b 32768 /dev/hda2

5. 커널패닉이 발생했을 때 위에서 설명한 부팅 과정중 어디에서 에러가 나는지 찾을 수 있어야 한다

그러면 더욱 쉽게 문제점을 해결 할 수 있다. 일단 서버가 돌아가고 있는 상태라면 서버에 리눅스를 처음으로 설치 할 때는 커널 패닉이 없었다는 말이다. 그 뒤에 변화된 환경에 의해 커널패닉이 발생한 것이다.

부팅 할때 발생하는 커널패닉 메세지를 잘 보면 이에 대한 힌트가 담겨 있다. 만약에 운영체제 설치시 하드 디스크 사타 드라이버나 기타 레이드 카드 드라이버를 설치했다면 커널을 업데이트 한 후에는 다시 설치해 줘야 할 것이다. 그렇지 않다면 업데이트된 커널로 부팅을 하면 커널이 드라이버를 적재하는 과정에서 하드디스크(root(hd0,0))를 인식하지 못해서 커널패닉이 발생 할 것이다. 이럴때는 제일 처음 설치할 때의 커널로 부팅을 해 보는 것도 방법이다. 하드디스크의 / 파티션이 손상을 당해서 마운트가 제대로 되지 않으면 mount fail이 뜨면서 커널패닉이 발생할 것이다. 이럴때는 파일 시스템을 체크해서 복구해야 한다. 평소에 부팅할 때 보여지는 메세지들을 잘 분석하고 이해해두자. 리눅스 시스템을 이해하고 트러블슈팅을 하는데 많은 도움을 준다.

1. 디렉토리 목록이 보이지 않을때

(1) Filezilla설정에서 능동형으로 변경

(2) 사용하는 서버 내에서 방화벽 정책 추가

방화벽 인바운드규칙에서 – Fileziila 프로그램 추가 

linux의 경우 network 상태 확인 시 ifconfig로 error값을 확인할 수 있으나

windwos의 경우는 기본적으로 error값을 확인 할 수 없다.

이를 간단하게 regedit 값을 추가하여 확인 할 수 있는 방법이 있어 소개합니다.

적용 전

regedit 실행

HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Network > Connections > StatMon
(StatMon 은 새로 키값으로 생성하면 됩니다) 

ShowLanErrors 이름으로 DWORD 생성, DWORD 값은 1

생성 후

에러 값이 나오는것을 확인할수 있습니다.

Windows서버 내, 예측치 못한 이상이 발생한 경우

C:\WINDOWS\MEMORY.DMP

파일을 생성합니다.

DUMP관련 설정은 제어판- 시스템-고급-시작 및 복구 에서 확인 하면 됩니다.

Dump파일을 쉽게 읽는 프로그램이 있어서 소개합니다.

1. BlueScreenView

http://www.nirsoft.net/utils/blue_screen_view.html

-> 상당히 직관적으로, 간단히 보기에 정말 편하다

2. Windbg

MicroSoft 자체 프로그램으로 넷프레임웍4.0 이 필요하다

http://www.microsoft.com/ko-kr/download/confirmation.aspx?id=17851

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8279

설치 후

시작 > 프로그램 > Debugging Tools for Windows > WinDbg 실행

파일 > Open Crash Dump 클릭 하신후 .dmp 파일을 클릭

Command !analyze -v

레이드 striping array 를 구성할때 동일한 레이드 컨트롤러와 하드디스크를 사용할지라도 stripe width

와 stripe size 에 따라서 전송률과 액세스타임, 시퓨사용율 등의 성능이 차이가 나길래.. 직접 테스트를

해보면서 얻은 결과치를 설명하고자 합니다.

우선 stripe width 경우는 동시에 읽기/쓰기 가능한 parallel stripes의 갯수에 관한것이며.. 이것은

바꿔말하면 어레이에 참여한 디스크의 숫자가 많을수록(more wide) 더 성능을 높게 냅니다. 하지만

4개로 스트라이핑을 구성하는 경우가 일반용 데스크탑에서는 거의 드물기 때문에 논외로 하고요.

2개의 디스크로 어레이를 구성한 경우만을 생각해 봅시다.

따라서 stripe size가 성능을 좌우하는 중요 요소가 되는데요.  이것을 "분할쪼가리(?) 크기" 정도로

해석을 해봅니다. 일반적으로 세팅시 사이즈를 4KB~128KB 정도까지 사용자가 결정을 할수가 있고요.

          △ 사이즈를 작게 쪼갠 경우.                          △ 사이즈를 크게 잡은 경우.

위 그림은 하드 4개로 어레이 구성한것을 예로 든건데.. 보시다시피 stripe size 에 따라서 분할정도가

달라집니다. 여기서 stripe size가 작을수록 파일들의 단편화가 심해지며 이것은 그 파일의 데이타를

포함하는 하나의 블럭에 이용되는 드라이버의 갯수가 증가한다는 의미와 같습니다. 그래서 전송율 즉

transfer performance 는 증가를 하지만, 대신에 파일들을 액세스 할수있는 positioning performance

는 감소를 하게 됩니다.

반대원리로 생각하면 stripe size를 오른쪽처럼 아주 크게 잡은 경우는  전송율은 감소를 하는 대신에

파일들에 대한 엑세스는 증가를 하게됩니다.

이정도로 개념 설명은 그만 넘어가고요. (저도 더이상 자세히는 모릅니다.^^;)

다름이 아니라, 이번에 보드를 p4p800-E Dlx 로 바꾸면서 WD SATA 120G *2개로 스트라이핑을 구성

해봤는데.. 위의 stripe size 별로 성능을 한번 테스트 해봤습니다.

테스트하게된 동기가.. 메뉴얼에 적힌 설명을 읽어보니..

16KB  - 적은 디스크 사용율

64KB  - 일반적인 디스크 사용율

128KB  - 성능위주의 디스크 사용율.  뭐 이런식으로 적혀있길래..

무조건 stripe size = 128K 로 잡고 일단 레이드 구성을 했습니다.  근데 막상 윈도우XP 설치하고 사용을

해보니 기존에 사용했던 히타치 7K250 120G 8M 에 비해 그렇게 빠르다는 느낌을 가질수가 없었습니다.

그저 부팅할때 화살표 3~4번이 2~3번으로 줄어들었다거나 또는 삼디겜 로드 과정에서 근소한 차이로

빠르다는.. 뭐 그 정도였습니다.

  OS

   win XP SP2

  s/w

   IAA RAID ver4.5

   HD Tune ver2.10

하드가 WD 1200JD 두개입니다. 이걸로 제일 먼저 프라미스378 컨트롤러에다 물려서 레이드_0 잡았는데

부팅시 FastTrack 바이오스 인식부분이 딜레이가 심하길래, 부팅용으로 쓰기는 별로겠다 싶어서 과감히

포기를 하고(사실 PDC378 이것때문에 Deluxe 모델 구입한건데 돈 아깝습니다).. ICH5R 에 물려서

설치를 하였습니다.

실제의 체감성능을 비교할려면 ICH5R 컨트롤러에 1200JD*2개에다가 XP 설치하고 몸으로 느끼면서

비교를 해야겠지만.. 윈도우를 6번씩이나 깔아야된다는건 거의 죽음! 이라서.. 히타치 7k250에 부팅용

으로 XP 설치하고 여기서 접근하는 1200JD*2개의 성능입니다. 측정유틸로는 HD Tune을 이용하였고요.

HD Tach 도 돌려봤는데 그다지 얻을 정보가 시원찮아서 빼버렸습니다.

아래 도표를 보시면.. (각각의 테스트는 두번씩 측정을 하고 그중 수치가 좀더 잘 나온녀석으로 샘플을

뽑았습니다.)

전송율 즉 Transfer performance 경우는 이론에 부합하듯이 stripe size가 작을수록 더 높은 수치가

나왔습니다. 근데 4/8/16K 세 경우에서는 우열을 가리기가 힘들었고요. 대신에 32K 로 넘어가면서

급격히(!) 전송율이 하락함을 알수가 있습니다. 또 32/64/128K 셋중에서는 오히려 128K 가 58.3MB/s

로 약간이나마 높은 수치를 보였습니다. 전체적으로 가장 높은 전송율을 보이는것은 size= 16K 에서

85.2MB/s 로 나타납니다. (Avrg 값입니다. Max/Min은 제외.)

액세스 타임입니다. 데이타의 위치를 잘 추적해서 읽고/쓰고 하는데 도움이 되는 녀석입니다.

여기서는 이론과는 달리 stripe size 와는 상관없이 133.2~3 ms 로 거의 동일하게 나타났습니다.

stripe size가 클수록 positioning performance가 높아져서 액세스 속도가 좀더 잘 나온다고 알고

있었는데.. 막상 측정을 해본 결과는 전혀 뜻밖이었습니다. 사이즈와는 전혀 무관하게 거의 동일한

수치로 측정이 되었습니다.

참고로, 이때의 부팅용 히타치 7k250 의 access time 을 측정해보니 12.8ms 로 오히려 더 뛰어난

수치가 나타납니다. 접근속도면에서는 히타치가 더 우세한게 사실인 모양입니다. 대신에 전송율

(transfer rate) 경우는 평균 46.9MB/s 로서 단일하드의 한계치가 드러났습니다. 위에 웨스턴 레이드

경우는 50~85MB/s 정도가 나오니 말입니다.

시퓨사용율 입니다. 이경우가 stripe size 별로 차이가 현격히 드러나고 있습니다. 사이즈가 가장 작은

4K에서는 19.2% 로 높게 측정이 되며 사이즈가 클수록 시퓨사용율은 떨어지고 있음을 봅니다. 첫번째

전송율 측정그림의 size=128K 에서 오히려 64/32K 보다 약간 더 좋은 전송율을 보여주는게 시퓨사용율이

줄어드는것과 연관이 있지않을까 생각을 해봅니다. regression package 같은걸 돌려보면 함수관계도

찾을것 같습니다. 변곡점 같은게 아마 나타날듯..

이상으로 결론을 내면요. 제 경우 ICH5R + 1200JD*2개 스트라이핑 구성시는 각각의 stripe size 별로

고려를 해볼때 16KB 가 가장 최적인것 같습니다. 전송율은 가장 뛰어나고.. 액세스타임은 비슷하고..

유일하게 걸리는게 시퓨사용율이 size>32K 에 비해서 높다는 점인데.. 그렇다고 80->50 대로 떨어지는

전송율을 가지고 사용할수는 없기 때문입니다.

이제 이글을 올린다음에는.. size=16K 에 맞추고 1200JD*2개 에다가 XP 설치해서 세팅을 해볼까 합니다.

그러면 기존에 먼가 빠른 느낌이 없었던 size=128K 에 비해서 체감적으로 얼마나 나아졌는지 알수가

있겠지요. 측정툴로써 아무리 떠든들, 몸으로 느낄수있는 체감성능 향상이 없다면 레이드_0 구성하는

의미가 없으니 말입니다.

흔히들 말하기에.. 데이타나 파일 전송이 많은 컴터라면 stripe size 를 작게 잡아서 전송율을 높여주고

반대로 서버용으로 사용할 컴터라면 size를 높게 잡아서 positioning or locating 을 높여주라는 말들을

많이 합니다. 결국 "Optimal" stripe size 라는건 없다는 소리입니다. 사용자마다 돌리는 애플리케이션이나

컴터의 사용목적에 따라서 사이즈는 각자가 판단하기에 최적이라는 수치를 잡아야 할것입니다.

또 이런 사이즈별로 성능이 컨트롤러를 뭐 사용하느냐.. 하드를 뭐 사용하느냐.. 에 따라서도 달라지는것

같습니다.

제 경우 지금 처한 상황에서는 size = 16K 에 맞추는게 최적값이라고 판단을 하기에 이걸로 결정을

봤습니다. 여러분들도 한번쯤은 사이즈를 조절해보시는게 동일사양에서 좀더 높은(= 원하는) 성능을

이끌어낼수가 있다고 생각을 합니다. 그럼 이만 글 줄이면서 물러갑니다.

** 아래는 측정한 결과들을 캡쳐한 그림입니다.

위에 도표로 이미 작성은 해놨으므로.. 아래는 그냥 참고삼아 보시길 바랍니다.

위쪽부터 순서대로 stripe size = 4 / 8/ 16/ 32/ 64/ 128 KB 입니다.

△ stripe size = 4K

△ stripe size = 8K

△ stripe size = 16K

△ stripe size = 32K

△ stripe size = 64K

△ stripe size = 128K

[출처] stripe에 대한 좋은 자료 스크랩|작성자 검은박쥐

 ABR11 복원Media 만들기

1.  Acronis Backup & Recovery 11 클릭

 2. 네트워크 구성 클릭

 ABR11 네트워크 설정

 3. 네트워크 설정

 4. 이 머신을 원격으로 관리합니다 클릭

  ABR11 복구 대상 선택

  5. 복구 메뉴를 선택

  6. 복구 대상 선택

  7. 찾아보기 클릭

  8. 복구할 데이터가 있는 경로로 접근하여 자격증명을 해준다. 

 9. 복구할 아카이브가 있는 파일을 선택

 10. 복구할 백업 파일 (아카이브) 선택

 11. 아카이브 안에 있는 백업 개수 중에 복구할 날짜의 파일을 선택

 12. 백업 개수를 선택하면 밑에 백업 내용에서 복구할 디스크를 선택하여 체크

 ABR11 복구 위치 선택

 13. 복구할 위치 선택

 14. 복구할 디스크의 파티션 지정

  시스템 복원 시 항상 MBR을 포함하여 지정하고 복구를 하여야 정상복구 됩니다.

  디스크1에 있는 MBR을 복원할 위치 지정 (하드디스크지정)

  NTFS (C:) 를 복구할 디스크와 용량을 지정

15. 디스크를 지정하고 난 후 속성 메뉴에서 파티션 크기 조절 가능(Windows만 정상 동작)

  UR(이기종 복원)을 구매 하지 않은 경우 기본 복원 설정은 복구 파일 선택과 복구 위치 설정까지 하여

  복원을 시작하면 됩니다.

 ABR11 Universal Restore

 16. Universal Restore (이기종 복원) - 사용함으로 변경

   ABR11로 부팅미디어를 꺼내고 머신의 드라이버 CD를 삽입, 새로 설치할 머신의 드라이버 파일을 지정

 17. Universal Restore - 새로 설치할 머신의 드라이버 파일들을 지정

  -  폴더 지정

 - 파일 지정

 - 저장 완료한 후 복원 시작

ABR 11 복구 진행

18. 복구를 진행

 복구 완료

 19. 작업 완료 후 닫기를 누르고 재부팅

 20. OS가 복원되면 로그인 후 추가 드라이버들을 설치한다.

(1) Disk %로 걸기

Console -> Threshold Templates

Data Template:Host MIB - Hard Drive Space

Data Source: hdd_used

High Threshold: 90 (your choice)

Data Type: Percentage 

Check Point 1. Windows Update가 실행 되고 있는지 확인 한다.

위와 같이 "Automatic Updates"가 정상적으로 실행 되고 있는지 확인을 한다.
실행이 안 되고 있으면 제대로 WSUS에 정보를 보내지 못 하여서, WSUS에서는 해당 Target이 있는지도 모른다.

Check Point2. 관련 파일에 잠김 현상을 확인 하자! (사설구간이면.... 소용없겠죠??)

관련 기술 문서 : http://support.microsoft.com/kb/822158

P.S : 임시 방편으로 Anti-Virus을 Disable 시킨 상태에서 "Automatic Updates" 서비스를 재 실행해서 Windows Update Site로 통하여 보안 업데이트를 하는 방법도 있다.

Check Point3. 수동으로 찾아 주자!!
WSUS에서 리스트에 아예 없거나 "아직 보고되지 않음"으로 표시 된다면, Target 서버(Computer)에서 Command로 바로 연결 하도록 설정 해 주자.

1. WSUS에서 "아직 보고되지 않음"으로 표시된 Target이 있으면 먼저 삭제
2. Target 서버(Computer)로 터미널이나 콘솔로 접속
3. CMD 창을 연다.
4. CMD에 "net stop wuauserv" 입력
5.regedit를 실행
6. 다음 레지스트리 찾는다.
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
7. 레지스트리 편집기의 세부 정보 창에서 다음 레지스트리 항목 삭제 (4개가 다 없을 수도 있다. 하위 트리는 삭제 하지 마세요!!!)
- PingID
- AccountDomainSid
- SusClientId
- SusClientIDValidation

8. CMD에 "net start wuauserv" 입력
9. CMD에서 "wuauclt.exe /resetauthorization /detectnow" 입력
10. Regedit 창에서 "F5"로 새로 고침을 하면 
- SusClientId
- SusClientIDValidation
2개의 레지스트리 항목이 생성 된다면, WSUS에서 인식을 한 것 이다.
WSUS에서도 새로 고침 및 찾기를 하면 Target이 추가 된 것을 확인 할 수가 있다.

기술 문서 : http://support.microsoft.com/kb/903262/kr-ko

참고. Ghost, TrueImage 등으로 작업 한 컴퓨터의 경우 SID 값을 변경 해 주어도 WSUS 관련 ID 값이 변경 되지 않아서 생기는 문제일 가능성이 많습니다.


Check Point4. 그룹 정책 레지키까지 수정 하자!!

위에 방법까지 해서 안 된다면, 그룹 정책이 제대로 적용 되지 않은 것 일수도 있다.
WSUS에서 잘 보이는 Target서버의 필요 레지스트리 키를 Export  시켜서 WSUS에서 보이지 않는 서버에 Import 시켜 주는 것이 좋다.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate
위의 레지키를 문제의 Target 서버에 추가 해 준다.

1. 



for 32bit:wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.i386.rpm

For 64 bithttp://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.x86_64.rpmInstall DAG’s GPG keyrpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt



 

2. RPM 설치



for 32bit:

rpm -Uvh rpmforge-release-0.5.1-1.el5.rf.i386.rpm

For 64 bitrpm -Uvh rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm

rsync -avr IP::Rsync설정title /cygdrive/c/경로

                                                     드라이브