[[SlideShow(PraceticeOf_3_Workstations,dep=2)]] go !! The Practice of System and Network Administration (2/E) Chapter 3 Workstations 요약자료 정리 : 문태준 http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임 http://tunelinux.pe.kr http://database.sarang.net [[TableOfContents]] == 3장 목차 == 3. Workstations 41 *3.1 The Basics 44 *3.1.1 Loading the OS 46 *3.1.2 Updating the System Software and Applications 54 *3.1.3 Network Configuration 57 *3.1.4 Avoid Using Dynamic DNS with DHCP 61 *3.2 The Icing 65 *3.2.1 High Confidence in Completion 65 *3.2.2 Involve Customers in the Standardization Process 66 *3.2.3 A Variety of Standard Configurations 66 *3.3 Conclusion 67 == 3 워크스테이션 시작 == 세가지 기존 작업 * 처음 시작시 시스템 소프트웨어와 애플리케이션 올리기 * 시스템 소프트웨어와 애플리케이션 업데이트하기 * 네트워크 파라미터 설정하기 (DHCP 등을 이용한 중앙집중 관리) 컴퓨터 생명 주기(life cycle) * 다섯가지 상태 : new, clean, configured, unkonwn, Off == 주요내용 == * 셋업 및 복구 프로세스가 자동화 되어야 함 * 설치 자동화 * 재설치 자동화 (rebuild process) : 데이타는 원격서버에 있어야 함 * 컴퓨터 생명주기에 따른 재정 계획을 짜야함. 5년 계획, 3년 계획 * 플랫폼 : 특정 벤더/OS의 조합. == 3.1 기본 == 초창기부터 자동화되어야 함 First-Class Citizens : 모든것을 지원하기 힘들기때문에 전체 지원을 받는 플랫폼을 만듬. 사용자 설치가 아닌 담당 엔지니어(또는 자동설치 및 세팅)가 설치해야 일관성을 가질 수 있음. 신규 제품 구매시 자동화가 가능한지 확인을 함 === 3.1.1 OS 설치하기 === OS별 자동설치방법 *Solaris has JumpStart; *RedHat Linux has KickStart; *SGI IRIX has RoboInst; *HP-UX has Ignite-UX; *MicrosoftWindows has Remote Installation Service 자동설치이유 : 돈을 절약함. 실수방지. 일관성을 가질 수 있음. 3.1.1.1 완전히 자동화가 되었는지 확인 자동화에서 가장 중요한 것은 완전자동화 여부 참고예 : 설치 완료후 자동으로 호스트네임, 하드웨어 등 정보를 메일로 보냄 고양이가 사용할 수 있는 시스템을 만든다 3.1.1.2 일부 자동화 일부 자동화는 전혀 자동화가 되어 있지 않은 것보다는 낫다. 잘 문서화된 프로세스를 가져야 함. (자동화되었다고 문서화가 불필요한 것은 아님) 참고예 : 부분적으로 완료된 경우 로그인시 메모를 볼 수 있도록 하는 등의 방법 사용 항구적인 솔루션이 나올때까지 티켓에 등록을 함 3.1.1.3 Cloning and Other Methods 하드웨어등이 다를 수 있으므로 클로닝하는 것보다는 자동화된 세팅이 나음. 윈도우 NT의 경우 SID 때문에 디스크를 그대로 복사흔넛게도 제한이 있을 수 있음 3.1.1.4 벤더에서 설치한 것을 신뢰해야하는가? known state 를 위해서, 재설치시의 문제, 일관성을 위하여 다시 설치하는것이 나음 참고예 : 디스크에 OS를 다시 설치하여 일본에서 보내주는 한 벤더의 이야기 3.1.1.5 설치 점검 항목 설치 점검 항목을 이용 === 3.1.2 시스템 소프트웨어와 애플리케이션 업데이트하기 === *소프트웨어 자동 업데이트 시스템 : Solaris, *AutoPatch; Microsoft Windows, *SMS; Red Hat Linux’s RPMs, *SGI IRIX’s RoboInst, *HP-UX’s Software Distributor (SD-UX) postinstall 스크립트를 통하여 설치후 변경작업진행 (/etc/ntpd.conf 변경 등) 3.1.2.1 설치와는 다른 부분 호스트는 사용가능한 상태임 네트워크를 이용하여 업데이트할 수 있음 물리적인 접근이 필요없음 이미 사용중임 "known state"가 아님 사용중인 사용자가 있음 호스트가 사라질 수도 있음(노트북등) 호스트가 듀얼 부트 시스템일 수 있음 3.1.2.2 One, Some, Many 하나의 시스템에서 테스팅(one). SA의 워크스테이션에서 테스팅(Some), 다량의 시스템에 적용 자동화된 시스템은 치명적인 영향을 줄수 있으므로 잘 문서화된 프로세스가 있어야 함 업데이트 프로세스에서 첫 단계의 몇가지 팁 * 배포 : 모든 호스트에 배포하는 잘 정의된 업데이트 만들기 * 소통 계획 만들어 사용자가 업데이트때문에 놀라지 않도록 함 * 성공 지표를 정의하고 사용 * 문제가 있는 경우 사용자가 전개 프로세스를 중단할 수 있는 방법을 마련함 === 3.1.3 Network Configuration === 네트워크 설정을 자동화할 수 있는 것중 대표적인 것이 dhcp 규모가 작아도 dhcp 사용을 추천함 3.1.3.1 호스트별 설정보다는 템플릿을 이용함 정보는 현재 사용중인 인벤토리 db나 파일에 내장되어야 함. (Unix /etc/ethers, /etc/hosts) 이를 통하여 일관성을 유지 해야함 이 책의 저자가 만든 HostDB 프로그램이 있음.http://everythingsysadmin.com/hostdb/ 3.1.3.2 Dynamic Leases 를 사용할때를 알기 Dynamic Leases 를 이용하여 특정 ip 대역을 호스트에 할당함 ip주소 pool은 최대치보다 약간 더 커야함. ip할당이 해제된 후 풀리는 시간을 고려하여 10% 더 추가 할당 고정 할당이 필요한 경우도 있음. 로그확인이 쉬움 IEEE 802.X : 네트워크 접근 제어에 대한 표준. 이동환경에서 사용 3.1.3.3 공개 네트워크에서 DHCP 사용 등록하고 인증을 거쳐 사용 === 3.1.4 Avoid Using Dynamic DNS with DHCP === 복잡성과 보안문제때문에 DHCP 와 함께 동적 DNS를 사용하지 않는 것이 좋음. 호스트네임은 중앙화된 인가(authority)시스템을 통해 통제를 해야함. 보안때문에 특정하게 정의된 영역에만 적용하도록 제한을 둠 (AD 등에 확장) 3.1.4.1. DHCP Lease Tims 조정 상황에 따라 조정함 == 3.2 The Icing == 위의 기본을 다했으면 워크스테이션 지원에 대한 자동화를 할 수 있는 기술을 찾는다. 3.2.1 완료에 대한 강한 믿음 (High Confidence in Completion) 자동화된 프로세스 -> 프로세스 자동화 완료에 대한 믿음이 있으면 이 프로세스를 사용할 새로운 방법을 찾음 3.2.2 표준화 프로세스에 고객 참여시키기 고객을 초기 명세화 및 설계단계에서 참가시킴 SA는 표준을 이익이 된다고 생각하겠지만 많은 고객은 표준을 참거나 해결해야 할 성가신 것으로 생각을 함 고객의 요구에 충실해야 함 3.2.3 표준 설정의 다양화 다양한 표준 설정을 가지는 것은 아름답거나 고통이 될 수 있음 각 표준마다 하나의 서버가 아닌 모든 설정이 한 서버와 하나의 매커니즘에 있어야 함. 단일 일반화된 시스템에 시간투자를 하면 다양한 설정을 담을 수 있고 확장을 할 수 있다. 표준화된 설정은 일반적으로 Software Configuration Management (SCM) 이라고 함. == 3.3 결론 == 서버와 다르게 데스크탑은 매우 많이 전개가 되지만 동일한 설정을 사용한다. 특정 플랫폼에 대한 모든 호스트는 동일한 설정을 사용하고 병렬로 업그레이드가 되어야 한다. 기본이 되는 세가지 프로세스는 1) 초기 OS설치 자동화 2) 소프트웨어 업데이트 자동화 3)네트워크 설정은 DHCP 와 같이 중앙에서 관리가 되어야 한다. 이 세가지는 경제적인 관리에서도 중요하다. == 연습 == 1. 3.1 에 사용한 대로 어떠한 플랫폼으로 구성되어 있는가? 현재 환경에서 사용하고 있는 모든 플랫폼을 나열해보자. 지원목적의 동일함을 고려하여 분류를 한다. 어떻게 결정을 하였는지 설명을 한다. 2. 3.1.2 의 비화는 전개 자동화에 투자하는 것보다는 수동으로 소프트웨어를 전개하는데 반복적으로 돈을 사용하고 있는 것을 보여준다. 왜 사이트에서 그런 바보같은 짓을 하는지 이해하기는 어렵다. 당신의 사이트나 최근 방문했던 사이트를 진단해보고 비슷한 투자가 되지 않고 있는 최소 세가지 예를 들어보자. 각 경우마다 왜 투자가 되지 않는지를 나열해보자. 당신의 대답은 무엇인가? 3. 당신의 환경에서 3.1의 예제에서 설명한 first-class ciztizen이 아닌 호스트나 OS를 찾아보자. 어떻게 이것을 요구사항이 계속 증가할 것이라고 예상되는 first-class citizen 으로 만들 것인가? 어떻게 당신의 환경에서 플랫폼이 first-class citizen 으로 되도록 할 것인가? 4. 예제중 하나에서 톰은 솔라리스 JumpStart를 설치하는 새로운 SA에 대한 교사가 되었다. 마지막에 실행되어야 하는 이 스크립트는 간단하게 특정 파일을 복사하였다. 자동이든 수동이든 어떻게 이 스크립트를 제거할 수 있을까? 5. DCHP 는 IP 방식의 네트워킹을 전제로 하고 있다. 이 책은 매우 ip 중심적이다. IPS/SPX을 이용하는 노벨을 사용하는가? OSI-net 이나 DECnet 환경을 사용하는가? == 참고자료 (문태준) == 위키피디아에서 SCM 자료를 검색해보았습니다. * http://en.wikipedia.org/wiki/Software_configuration_management * CmWiki, Configuration Management Wiki - A wiki web dedicated to Configuration Management http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/CmTools 여기는 scm 소프트웨어들을 광범위하게 소개하고 있네요. * 여기서 Configuration item (CI)링크를 따라 들어가면 연관된 여러가지 항목들이 나옵니다. http://en.wikipedia.org/wiki/Configuration_item 간단히 보았지만 Software Configuration Management 에 대한 자료들이 상당히 많이 있습니다. 17장 변경관리(Change Management), ITIL의 변경관리도 이와 연관이 될 것입니다. ---- 문서편집을 했는데 문단이 띄어지지 않으니깐 일부 보기가 좀 불편하군요. 문서를 다시 편집하면 되는데 일단 귀찮아서 여기까지! -- [taejun] [[DateTime(2008-03-16T14:01:42)]] ---- kldp에도 올리셨네요 수고하셨어요. -- [환골탈태] [[DateTime(2008-03-17T02:49:50)]] [[Comment]]