Red Hat Training

A Red Hat training course is available for Red Hat Satellite

시작하기 가이드

Red Hat Network Satellite 5.5

Red Hat Network Satellite로 프로비저닝 및 배포

엮음 2

Red Hat Engineering Content Services

초록

다음 부분에서는 Red Hat Network Satellite에서 킥스타트 프로비저닝 기능 사용에 대한 정보 및 사용 방법을 설명합니다. Satellite 기초에 대한 보다 자세한 내용은 Satellite 사용자 가이드에서 참조하십시오.

1장. 소개

프로비저닝은 미리 정의된 상태로 물리적 또는 가상 머신을 설정하는 프로세스입니다. Red Hat Network (RHN) Satellite는 킥스타트 (kickstart) 프로세스를 사용하여 시스템을 프로비저닝합니다. 프로비저닝 기능을 사용하려면 하나 이상의 대상 (target) 시스템이 필요합니다. 대상 시스템은 물리적, 베어 메탈 시스템, 가상 머신이 될 수 있습니다. RHN Satellite의 가상 머신 프로비저닝 기능을 사용하려면 Xen이나 KVM을 사용하여 가상 머신을 생성해야 합니다.

정의

이 문서 전체에서 사용되는 용어
킥스타트
사용자 개입이 거의 없거나 전혀 필요로 하지 않는 자동화된 방법으로 Red Hat 시스템을 설치하는 과정입니다. 기술적으로 킥스타트는 Anaconda 설치 프로그램 기법으로 설치 프로그램에 시스템 설정 및 간결한 컨텐츠 설명을 제공하고 그에 따라 동작을 수행하게 합니다. 이러한 간단한 시스템 정의는 킥스타트 프로파일이라고 합니다.
킥스타트 프로파일
킥스타트 파일은 파티션 정보, 네트워크 설정, 설치할 패키지를 포함하여 시스템을 킥스타트하는데 필요한 모든 옵션이 지정된 텍스트 파일입니다. Satellite 구현은 킥스타트에서의 Cobbler 기능 향상에 구축되어 있으므로 RHN Satellite에서 킥스타트 프로파일은 기존의 Anaconda 킥스타트 정의의 상위 집합입니다. 킥스트타 프로파일은 킥스타트 트리가 존재하고 있음을 전제로 합니다.
킥스타트 트리
시스템을 킥스타트하기 위해 필요한 소프트웨어 및 지원 파일입니다. 이는 "설치 트리"라고 부르기도 합니다. 이는 특정 릴리즈에 탑재된 설치 미디어에서 꺼낸 디렉토리 구조와 파일입니다. Cobbler 용어로 킥스타트 트리는 배포판의 일부가 되고 있습니다.
PXE (Preboot eXecution Environment)
대상 시스템 자체의 사전 설정 없이 전원을 켤 때 베어메탈 시스템 (일반적으로 물리적 시스템 또는 실제 시스템)을 킥스타트 가능하게 하는 낮은 수준의 프로토콜입니다. PXE는 DHCP 서버를 사용하여 부트스트랩 서버에 관한 정보를 (이 문서에서는 Satellite 5.5 이상 버전 설치) 클라이언트에게 제공합니다. PXE를 사용하려면 대상 시스템의 펌웨어에서 지원되어야 합니다. PXE는 새로운 물리적 시스템을 부팅하거나 Satellite에 등록되지 않은 시스템을 다시 설치하는데 매우 유용하지만, PXE 없이 가상화를 사용하고 Satellite 기능을 다시 설치할 수 있습니다.

프로비저닝 시나리오

RHN Satellite에 의해 제공되는 프로비저닝 시나리오 유형:
새로운 설치
운영 체제가 설치되어 있지 않은 시스템을 프로비저닝합니다 (베어 메탈 설치라고도 알려짐).
가상 설치
Satellite는 KVM, Xen 완전 가상화 게스트 및 Xen 반가상화 게스트를 지원하고 있습니다.
재프로비저닝
물리적 및 게스트 시스템은 모두 다시 프로비저닝 가능합니다. 그러나 동일한 Satellite 인스턴스에 등록되는 것을 조건으로합니다. 2.5.2절. “재프로비저닝 ”에서 참조하십시오.

2장. 킥스타트

2.1. 필요한 패키지

사용자 정의 배포를 사용하는 경우, 다음과 같은 패키지가 필요합니다. 이는 rhn-tools Red Hat Network (RHN) 채널에서 사용 가능합니다:
  • koan
  • spacewalk-koan
사용자 정의 채널에서 이러한 패키지에 액세스하려면 기존 rhn-tools 채널을 복제하는 것이 좋습니다.
RHN Satellite는 kernelinitrd 파일이 킥스타트 트리 내의 특정 위치에 있다고 가정합니다. 하지만 이 위치는 아키텍처에 따라 다릅니다. 아래 표에서는 다른 위치에 대해 설명합니다:

표 2.1. 아키텍처에 따른 필요한 배포 파일

아키텍처 커널 초기 RAM 디스크 이미지
IBM System z TREE_PATH/images/kernel.img TREE_PATH/images/initrd.img
PowerPC TREE_PATH/ppc/ppc64/vmlinuz TREE_PATH/images/pxeboot/vmlinux
모든 다른 아키텍처 TREE_PATH/images/pxeboot/vmlinuz TREE_PATH/images/pxeboot/initrd.img

2.2. 킥스타트 트리

킥스타트 프로비저닝을 사용하려면 Satellite에 최소 하나의 킥스타트 트리가 설치되어 있어야 합니다. 킥스타트 트리는 자동 또는 수동으로 설치할 수 있습니다.

절차 2.1. 자동으로 킥스타트 트리 설치

RHN의 기본 채널이 있는 모든 배포판의 경우, 킥스타트 트리는 자동으로 설치될 수 있습니다. 이는 satellite-sync를 통해 일반적인 채널 동기화의 부분으로 수행됩니다.
  1. 킥스타트를 기반으로 하고자 하는 배포판을 선택하여 배포판의 기본 채널 및 해당 RHN Tools 채널을 배치합니다.
    예를 들어, x86 아키텍처로 Red Hat Enterprise Linux 5를 사용하고자 할 경우, rhel-i386-server-5 채널과 이에 상응하는 RHN Tools 채널 rhn-tools-rhel-i386-server-5가 필요합니다.
  2. 연결된 Satellite를 사용하는 경우, satellite-sync를 사용하여 Satellite 서버를 Red Hat 서버와 직접 동기화합니다. Satellite 서버가 연결되지 않은 경우, Red Hat 서버에서 연결되지 않은 채널 덤프를 가져와서 동기화해야 합니다.
  3. 채널을 동기화하면 배포판에 대해 해당하는 킥스타트 트리가 자동으로 생성됩니다.

절차 2.2. 수동으로 킥스타트 트리 설치

사용자 정의 배포판, Red Hat이 지원하지 않는 배포판 또는Red Hat Enterprise Linux 베타 버전을 킥스타트하려면, 수동으로 해당 킥스타트 트리를 생성해야 합니다. 킥스타트하려는 배포판의 설치 ISO가 필요합니다.
  1. Satellite 서버에 설치 ISO를 복사하여 /mnt/iso에 마운트합니다.
  2. ISO 컨텐츠를 사용자 정의 위치에 복사합니다. 모든 사용자 정의 배포에 대해 /var/satellite에 디렉토리를 생성할 것을 권장합니다. 예를 들어, RHEL 베타 버전의 컨텐츠를 /var/satellite/custom-distro/rhel-i386-server-5.3-beta/에 복사합니다.
  3. RHN Satellite 웹 인터페이스를 사용하여 사용자 정의 소프트웨어 채널을 생성합니다. 채널소프트웨어 채널 관리새 채널 생성을 사용하여 적절한 이름과 레이블로 부모 채널을 생성합니다. 위에서 사용한 예에서는 rhel-5.3-beta 레이블을 사용하고 있습니다.
  4. rhnpush 명령을 사용하여 소프트웨어 패키지를 트리 위치에서 새로 생성된 소프트웨어 채널로 푸시합니다:
    rhnpush --server=http://localhost/APP -c 'rhel-5.3-beta' \  -d /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/
    배포판에 따라 트리의 하위 디렉토리는 다를 수 있습니다.
  5. 소프트웨어 패키지가 푸시되면, 이는 rm 명령을 사용하여 트리 경로에서 제거될 수 있습니다. 패키지는 채널 내의 Satellite 서버에 저장되고 트리에서는 더이상 필요하지 않습니다.
    rm /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/*.rpm

    참고

    킥스타트 트리에 소프트웨어 패키지를 남겨 두도록 선택할 수 있습니다. 이는 yum 명령을 사용하여 언제든지 나중에 설치할 수 있게 합니다.
  6. RHN Satellite 웹 인터페이스를 사용하여 배포판을 생성합니다. 시스템킥스타트배포새 배포판 생성으로 적절한 레이블 및 완전 트리 경로 (예: /var/satellite/custom-distro/rhel-i386-server-5.3-beta/)를 사용하여 배포판을 생성합니다. 이전에 생성한 기본 채널을 선택하고 올바른 설치 프로그램 생성 (예: Red Hat Enterprise Linux 5)을 선택합니다. 킥스타트 배포판 생성을 선택하여 생성을 완료합니다.
  7. 여러 환경 및 시스템에 걸쳐 동일한 소프트웨어를 유지하려면 기존의 Red Hat Enterprise Linux 기반 채널에서 RHN Tools 자식 채널을 새로 생성된 기본 채널의 자식 채널로 복제할 수 있습니다. 다음을 수행하여 자식 채널을 복제할 수 있습니다:
    1. Satellite 웹 인터페이스에서 채널소프트웨어 채널 관리채널 복제를 클릭합니다.
    2. 드롭 박스 상자의 복제 대상 (Clone From):에서 복제하고자 하는 자식 채널을 선택하고 복제 상태를 선택합니다.
    3. 채널 생성을 클릭합니다.
    4. 필요한 정보를 입력하고 복제된 자식 채널에서 있어야 하는 부모 채널을 선택합니다.
    5. 채널 생성을 클릭합니다.
킥스타트 배포판 생성

그림 2.1. 킥스타트 배포판 생성

2.3. 킥스타트 프로파일

킥스타트 프로파일은 설치에 사용할 설정 옵션을 지정합니다.
킥스타트 프로파일은 마법사 인터페이스를 사용하여 생성될 수 있습니다. 이는 일련의 질문에 대한 대답에 따라 프로파일을 생성합니다. 이는 raw 메소드을 사용하여 생성될 수 도 있으며, 이는 프로파일의 내용을 완전히 제어할 수 있게 합니다.

절차 2.3. 마법사로 킥스타트 프로파일 생성

  1. 시스템킥스타트새 킥스타트 프로파일 생성을 선택합니다.
  2. 적절한 레이블을 제공하고 원하는 기본 채널킥스타트 가능한 트리를 선택합니다.
  3. 원하는 가상화 유형을 선택합니다. 가상화 유형에 대한 보다 자세한 내용은 가상화 유형 에서 참조하십시오. 다음을 클릭하여 계속 진행합니다.
  4. 킥스타트 프로파일의 다운로드 위치를 선택합니다. 사용자 정의 배포 버전을 사용하는 경우, 해당 트리의 위치를 URI (HTTP와 FTP를 모두 지원)로 입력합니다. 그렇지 않을 경우 기본값 옵션을 사용합니다. 다음을 클릭하여 계속 진행합니다.
  5. root 암호를 입력하고 완료를 클릭하여 프로파일 생성을 완료합니다.
  6. 완전한 킥스타트 프로파일이 생성됩니다. 킥스타트 파일을 클릭하여 프로파일을 확인합니다.

절차 2.4. Raw 메소드를 사용하여 킥스타트 프로파일 생성

  1. 시스템킥스타트새 킥스타트 파일 업로드를 선택합니다
  2. 적절한 레이블을 제공하고 원하는 배포판을 선택합니다.
  3. 원하는 가상화 유형을 선택합니다. 가상화 유형에 대한 자세한 내용은 가상화 유형 에서 참조하십시오.
  4. 기존의 킥스타트 프로파일이 있을 경우, 파일을 업로드합니다. 그렇지 않을 경우, 파일 내용 텍스트 상자에 있는 킥스타트 프로파일을 작성합니다.
    다음에는 시작 부분으로 사용할 수 있는 raw 킥스타트 예제가 있습니다:
    install
    text
    network --bootproto dhcp
    url --url http://$http_server/ks/dist/org/1/ks-rhel-i386-server-5
    lang en_US
    keyboard us
    zerombr
    clearpart --all
    part / --fstype=ext3 --size=200 --grow
    part /boot --fstype=ext3 --size=200
    part swap --size=1000   --maxsize=2000
    bootloader --location mbr
    timezone America/New_York
    auth --enablemd5 --enableshadow
    rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0
    selinux --permissive
    reboot
    firewall --disabled
    skipx
    key --skip
    
    %packages 
    @ Base
    
    %post
    $SNIPPET('redhat_register')
    
  5. RHN Satellite 서버는 킥스타트의 url로 지정된 배포 버전을 처리하지 못하기 때문에 다음과 같이 프로파일에 url --url 옵션을 포함시켜야 합니다:
    url --url http://satellite.example.com/ks/dist/org/1/my_distro
    my_distro를 배포 버전 레이블로 1을 조직의 ID로 바꿉니다.
  6. Raw 킥스타트 프로파일은 Satellite의 호스트 이름 대신 $http_server를 사용합니다. 이는 킥스타트 템플릿이 렌더링될 때 자동으로 기입됩니다.
  7. redhat_register 스니펫을 사용하여 등록을 처리합니다.
Raw 킥스타트

그림 2.2. Raw 킥스타트

가상화 유형

모든 킥스타트 프로파일에는 연관된 가상화 유형이 있습니다. 다음 표에서는 다양한 옵션에 대해 설명합니다:

표 2.2. 가상화 유형

유형 설명 사용법
없음 가상화 없음 이 유형은 Xen 또는 KVM이 아닌 (예: VMware, Virtage 등) 일반적인 프로비저닝, 베어 메탈 설치 및 가상화 설치에 사용합니다.
KVM 가상화 게스트 KVM 게스트 KVM 게스트를 프로비저닝하기 위해 이 유형을 사용합니다.
Xen 완전 가상화 게스트 Xen 게스트 Xen 게스트를 프로비저닝하기 위해 이 유형을 사용합니다.

참고

이 옵션에는 호스트 상의 하드웨어 지원이 필요하지만 게스트에서 수정된 운영 체제가 필요하지 않습니다.
Xen 반가상화 게스트 Xen 게스트 이 유형은 Xen 반가상화로 가상 게스트를 프로비저닝하는데 사용됩니다. 반가상화는 가장 빠른 가상화 모드로 이는 시스템 CPU에서 PAE 플래그와 수정된 운영 체제를 필요로 합니다. Red Hat Enterprise Linux 5는 반가상화 아래에서 게스트를 지원합니다.
Xen 가상화 호스트 Xen 호스트 이 유형은 Xen 반가상화로 가상 호스트를 프로비저닝하는데 사용됩니다. 하드웨어가 호환 가능할 경우 Xen 반가상화 게스트 및 호스트가 지원됩니다.
Xen 호스트로 사용하기 위해 생성된 킥스타트 프로파일에는 %packages 부분에 있는 kernel-xen 패키지가 포함되어 있어야 합니다.
KVM 호스트로 사용하기 위해 생성된 킥스타트 프로파일에는 %packages 부분에 있는 qemu 패키지가 포함되어 있어야 합니다.
완전 가상화 시스템에는 컴퓨터의 BIOS 메뉴에서 활성화된 가상화 지원이 필요할 수 있습니다.

참고

킥스타트에 관한 보다 자세한 내용은 Red Hat Enterprise Linux 설치 가이드킥스타트 설치 장에서 참조하십시오.

2.4. 템플릿 작성

킥스타트 템플릿 작성에서는 킥스타트 파일에 매개 변수, 스니펫, for 루프 및 if 문과 같은 흐름 제어문을 추가할 수 있습니다. 이는 cheetah 도구를 사용하여 수행할 수 있습니다.
다음과 같은 이유로 템플릿 기능을 유용하게 사용할 수 있습니다:
  • 여러 킥스타트 간의 디스크 파티셔닝 섹션과 같은 특정 킥스타트 섹션을 다시 사용할 수 있습니다.
  • 여러 킥스타트에 걸쳐 일관되게 %post 작업을 수행할 수 있습니다.
  • DNS 서버, Proxy 서버, Web 서버와 같은 여러 종류의 서버 역할에 걸쳐 스니펫을 정의할 수 있습니다. 예를 들어, Web 서버에는 다음과 같은 스니펫이 정의될 수 있습니다:
    httpd
    mod_ssl
    mod_python
    
    Web 서버 프로파일을 생성하려면, 킥스타트 파일의 %package 부분에 Web 서버 스니펫을 포함시킵니다. Web 서버 및 Proxy 서버 모두에 있는 프로파일의 경우, 패키지 부분의 두 스니펫 모두를 포함시킵니다. Web 서버 스니펫에 다른 패키지를 추가하려면 (예: mod_perl) 스니펫을 업데이트하면 그 스니펫을 사용하는 모든 프로파일이 동적으로 업데이트됩니다.
변수

템플릿 기능으로 킥스타트 파일 전체에 걸쳐 사용되는 변수를 정의할 수 있습니다. 변수는 상속 대상으로 하나의 레벨에 설정될 수 있으며 그 이하의 레벨에서 덮어쓰기 가능하게 됩니다. 따라서 변수가 시스템 레벨에 정의되고 있는 경우, 프로파일 또는 킥스타트 트리 레벨에 정의된 동일한 변수를 덮어쓰기하게 됩니다. 마찬가지로 변수가 프로파일 레벨에 정의된 경우 킥스타트 트리 레벨에 정의된 동일한 변수를 덮어쓰기하게 됩니다.

참고

Satellite 동기화를 실행할 때 생성되는 것과 같은 자동 생성된 킥스타트에 대해 킥스타트 트리 변수는 정의될 수 없음에 유의합니다.
스니펫

스니펫은 여러 킥스타트 템플릿 간의 코드 조각을 다시 사용합니다. 이는 여러 줄에 걸쳐 있을 수 있고 그 안에 변수가 포함되어 있을 수 도 있습니다. 이는 $SNIPPET('snippet_name') 텍스트를 사용하여 킥스타트 프로파일에 포함될 수 있습니다. 패키지 목록, %post 스크립트, 킥스타트 파일에 보통 포함된 텍스트에 대한 스니펫을 만들 수 있습니다.

스니펫을 관리하려면 시스템킥스타트킥스타트 스니펫으로 이동합니다.
킥스타트 스니펫 페이지에서는 편집할 수 없지만 다른 조직에서 사용할 수 있는 여러 기본값 스니펫을 보여줍니다. 기본값 스니펫은 RHN Satellite 서버에 기록되거나 업로드된 킥스타트에서 사용될 수 있습니다. 기본값 스니펫은 /var/lib/cobbler/snippets/에 있는 RHN Satellite 서버의 파일 시스템에 저장됩니다. /var/lib/rhn/kickstarts/wizard/에 있는 마법사 스타일 킥스타트에서 템플릿이 있으며 이는 다른 기본값 스니펫 및 사용 방법을 설명합니다.
redhat_register 스니펫은 킥스타트의 일부로 시스템을 RHN Satellite 서버에 등록하기 위해 사용되는 기본값 스니펫입니다. redhat_management_key라는 변수를 사용하여 시스템을 등록합니다. 스니펫을 사용하려면 redhat_management_key 변수를 시스템, 프로파일, 배포 수준에서 설정하고 킥스타트의 %post 부분에 $SNIPPET('redhat_register')를 추가합니다. RHN Satellite 서버에 의해 생성된 마법사 스타일 킥스타트는 이러한 스니펫을 이미 %post 부분에 포함시키고 있습니다.
사용자 정의 스니펫 탭에서 조직에서 사용하도록 생성된 스니펫을 편집 및 확인할 수 있습니다. 새 스니펫 생성을 클릭하여 새로운 스니펫을 생성할 수 있습니다. 사용자 정의 스니펫은 /var/lib/rhn/kickstarts/snippets/ 디렉토리에 저장됩니다. RHN Satellite는 조직별로 다른 디렉토리에 스니펫을 저장하므로 사용자 정의 스니펫은 다음과 유사한 파일 이름으로 저장됩니다. 여기서 1은 조직 ID입니다:
$SNIPPET('spacewalk/1/snippet_name')
킥스타트에 스니펫을 삽입하기 위해 사용할 텍스트를 결정하려면 스니펫 목록이나 스니펫 상세 페이지에서 스니펫 매크로란을 찾습니다.

참고

스니펫은 글로벌 수준으로 존재하며 동일한 상속 구조를 변수로 공유하지 않습니다. 하지만 스니펫의 변수를 사용하여 다른 시스템이 킥스타트를 요청할 때 동작 방식을 변경할 수 있습니다.
킥스타트 스니펫

그림 2.3. 킥스타트 스니펫

특수 문자 이스케이프

$# 문자는 템플릿 기능을 사용할 때 변수와 제어 흐름을 지정하는데 사용됩니다. 스크립트에서 다른 목적으로 이러한 문자를 사용해야 할 경우, 이를 이스케이프하여 변수로 인식되지 않도록 해야 합니다. 이는 여러 가지 다른 방법으로 수행될 수 있습니다:

  • 템플릿 기능을 실행할 때 무시하고자 하는 $ 또는 #의 각 인스턴스의 앞에 백슬래시 문자 (\)를 배치합니다.
  • 전체 스크립트를 #raw ... #end raw에 랩핑합니다.
    마법사 스타일 킥스타트를 사용하여 생성된 모든 %pre%post 스크립트는 기본값으로 #raw...#end raw로 랩핑됩니다. 이는 %post 또는 %pre 스크립트를 편집할 때 사용 가능한 템플릿 옵션을 사용하여 전환할 수 있습니다.
  • 스니펫의 첫 줄에 #errorCatcher Echo를 추가합니다.

예 2.1. 템플릿에 있는 특수 문자 이스케이프

이 예제에서는 킥스타트 템플릿에서 특수 문자를 이스케이프 처리하는 방법에 대해 설명합니다.
다음의 bash 스크립트는 %post 부분에 삽입해야 합니다:
%post 
echo $foo > /tmp/foo.txt
이스케이프 처리된 $ 없이, 템플릿 엔진은 $foo라는 변수를 찾으려 하지만 foo는 변수로 존재하지 않기 때문에 실패하게 됩니다.
$를 이스케이프 처리하는 가장 간단한 방법은 백슬래시 문자를 (\)를 사용하는 것입니다:
%post 
echo \$foo > /tmp/foo.txt
이는 \$foo$foo로 렌더링되게 합니다.
두 번째 방법은 다음과 같이 전체 bash 스크립트를 #raw ... #end raw에 랩핑하는 것입니다.
%post 
#raw  
echo $foo > /tmp/foo.txt 
#end raw
마지막 방법은 킥스타트 템플릿의 첫 번째 줄에 #errorCatcher Echo를 추가하는 것입니다. 이는 템플릿 엔진이 존재하지 않는 변수를 무시하고 텍스트를 있는 그대로 출력하도록 지시합니다. 이 옵션은 마법사 스타일 킥스타트에 이미 포함되어 있으며 수동으로 생성한 raw 킥스타트에 포함시킬 수 있습니다.

2.5. 시스템 킥스타트

2.5.1. 베어 메탈에서 킥스타트

운영 체제가 존재하지 않는 시스템이나 잘못된 운영 체제가 설치된 시스템을 베어 메탈 시스템이라고 합니다. 베어 메탈에서 시스템을 구축하는 세 가지 방법이 있습니다:
  • 표준 운영 체제 설치 미디어
  • PXE 부트

절차 2.5. 설치 미디어에서 부팅

  1. 설치 미디어를 컴퓨터에 삽입합니다. 미디어는 사용하려는 킥스타트와 일치해야 합니다. 예를 들어, 킥스타트가 ks-rhel-i386-server-5-u2 킥스타트 트리를 사용하도록 설정되어 있을 경우, Red Hat Enterprise Linux 5.2 i386 설치 미디어를 사용합니다.
  2. 부트 프롬프트가 나타나면 다음 명령을 사용하여 킥스타트를 활성화합니다:
    linux ks=http://satellite.example.com/path/to/kickstart
    
  3. 시스템을 부팅하고, 킥스타트를 다운로드하여 자동으로 설치합니다.

절차 2.6. PXE 부팅

PXE 부팅을 실행하려면 각 시스템이 BIOS 수준에서 PXE 부팅을 지원해야 합니다. 최신 하드웨어의 대부분이 이를 지원하고 있습니다. 또한 설치 후 시스템이 정적으로 설정된 경우에도 DHCP 서버를 사용해야 합니다.
  1. 중요

    네트워크 상의 다른 시스템에 배포된 DHCP 서버가 있을 경우, DHCP 설정 파일을 편집하기 위해 DHCP 서버로의 관리 액세스가 필요합니다.
    사용하는 컴퓨터가 여러 네트워크에 존재하는 경우, 모든 컴퓨터는 DHCP 서버에 연결할 수 있는지 확인해야 합니다. 이는 DHCP 서버를 멀티 호밍하고 (실제 또는 트렁크 VLAN 사용) 네트워크 경계를 넘어 DHCP 프로토콜을 전달하도록 스위치 또는 라우터를 설정하여 달성될 수 있습니다.
    RHN Satellite에서 관리하고자 하는 시스템의 next-server 주소를 설정하여 DHCP 서버가 PXE 서버를 가리키도록 설정합니다.
    설치를 수행할 때 호스트 이름을 사용하려면 다음과 같은 줄을 포함하여 도메인 및 IP 주소를 가리키도록 DHCP 서버를 설정합니다:
    option domain-name DOMAIN_NAME;
    option domain-name-servers IP_ADDRESS1, IP_ADDRESS2;
    
  2. DHCP 서버에서 root 사용자로 전환하고 /etc/dhcpd.conf 파일을 엽니다. PXE 부트 설치를 실행하기 위한 옵션이 있는 새로운 클래스를 추가합니다:
    allow booting;
    allow bootp;
    class "PXE" {
      match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
      next-server 192.168.2.1;
      filename "pxelinux.0";
    }
    
    이 클래스는 다음과 같은 동작을 실행합니다:
    1. bootp 프로토콜을 사용하여 네트워크 부팅을 활성화합니다
    2. PXE라는 클래스를 생성합니다. 부팅 우선 순위에서 PXE가 1 순위로 설정되어 있는 시스템의 경우, 이는 시스템 자신을 PXEClient로 인식하게 됩니다.
    3. DHCP 서버는 192.168.2.1 IP 주소에서 시스템을 Cobbler 서버에 전달합니다
    4. DHCP 서버는 /var/lib/tftpboot/pxelinux.0에 있는 부트 이미지 파일을 참조합니다.
  3. Xinetd를 설정합니다. Xinetd는 부트 이미지를 PXE 클라이언트에 전송하기 위해 사용되는 FTP 서버, TFTP가 포함된 서비스 제품군을 관리하는 데몬입니다.
    chkconfig 명령을 사용하여 Xinetd를 활성화합니다:
    chkconfig xinetd on
    
    다른 방법으로 root 사용자로 전환하여 /etc/xinetd.d/tftp 파일을 엽니다. disable = yes 행을 disable = no을 읽도록 변경합니다.
  4. Xinetd 서비스를 시작하여 TFTP가 pxelinux.0 부트 이미지를 서비스 시작할 수 있게 합니다:
    chkconfig --level 345 xinetd on
    /sbin/service xinetd start
    
    chkconfig 명령은 모든 사용자 런레벨에 대해 xinetd 서비스를 활성화하는 반면 /sbin/service 명령은 xinetd를 즉시 활성화합니다.

2.5.2. 재프로비저닝

기존 시스템을 다시 설치하는 작업은 재프로비저닝이라고 합니다. 재프로비저닝은 RHN Satellite 웹 인터페이스를 사용하여 수행될 수 있으며 시스템은 재프로비저닝이 이루어지기 전에 동일한 시스템 프로파일을 사용하게 됩니다. 이는 시스템의 정보와 설정 대부분을 보존하게 됩니다.
재프로비저닝은 시스템 보기를 하여 프로비저닝 탭에서 스케줄할 수 있습니다. 추가 옵션을 설정하려면, 고급 설정 페이지로 이동하여 커널 옵션, 네트워크 정보, 패키지 프로파일 동기화 같은 정보를 설정합니다. 커널 옵션 부분에서는 킥스타트시 사용되는 커널 옵션에 대한 액세스를 제공하며 사후 커널 옵션은 킥스타트 완료 후 시스템을 처음으로 부팅할 때 사용되는 커널 옵션입니다.

예 2.2. 커널 옵션 및 포스트 커널 옵션 설정

이 예제에서는 재프로비저닝 설정 프로세서에서 커널 옵션과 사후 커널 옵션의 차이점에 대해 설명합니다.
킥스타트를 원격으로 감시하기 위해 VNC 연결을 설정할 경우, Kernel Options 행에 vnc vncpassword=PASSWORD를 추가합니다.
결과 시스템의 커널을 noapic 커널 옵션으로 부팅하고자 할 경우, Post Kernel Options 행에 noapic을 추가합니다.

절차 2.7. 파일 보관

파일 보관 기능을 사용하여 재프로비저닝을 하는 동안 파일을 분실하는 것을 막을 수 있습니다. 이 기능은 킥스타트 동안 파일을 임시로 저장하고 재프로비저닝을 완료한 후 이를 다시 복원합니다.

참고

파일 보관 목록은 마법사 스타일 킥스타트에서만 사용 가능하며 재프로비저닝 동안에만 사용할 수 있습니다.
  1. 시스템킥스타트파일 보관새 파일 보관 목록 생성으로 가서 보관하려는 파일 목록을 생성합니다.
  2. 시스템킥스타트프로파일로 가서 원하는 프로파일을 선택하여 파일 보관 목록을 킥스타트에 연결합니다.
  3. 시스템 정보파일 보관으로 가서 파일 보관 목록을 선택합니다.

2.5.3. 가상화 게스트 프로비저닝

가상 게스트 프로비저닝은 다음과 같은 가상화 기술을 사용하여 RHN Satellite 5.5에서 지원됩니다:
  • KVM 가상화 게스트
  • Xen 완전 가상화 게스트
  • Xen 반가상화 게스트

절차 2.8. 가상화 게스트 프로비저닝

  1. 호스트 시스템에 가상화 또는 가상화 플랫폼 시스템 인타이틀먼트가 있는지 확인합니다.
  2. 시스템 페이지에서 적절한 가상 호스트를 선택하고 가상화프로비저닝을 선택합니다. 적절한 킥스타트 프로파일을 선택하고 게스트 이름을 입력합니다.
  3. 게스트 메모리 및 CPU 사용과 같은 추가 매개 변수를 설정하려면 고급 설정 버튼을 클릭합니다. 여기서 다음과 같은 항목을 설정할 수 있습니다:
    • 네트워크: 정적 또는 DHCP
    • 커널 옵션
    • 패키지 프로파일 동기화: 킥스타트 종료시 시스템은 패키지 프로파일을 다른 시스템이나 저장된 프로파일에 동기화하게 됩니다
    • 메모리 할당: RAM (기본값은 512MB)
    • 가상 디스크 크기
    • 가상 CPU (기본값 1)
    • 가상 브리지: 설치에 사용되는 네트워킹 브리지. Xen 프로비저닝의 경우 xenbr0가, KVM의 경우 virbr0이 기본값으로 되어 있습니다.

      참고

      virbr0 네트워킹 브릿지는 외부 네트워킹을 허용하지 않습니다. 외부 네트워킹이 필요할 경우, 실제 브릿지를 생성하도록 호스트를 설정합니다. 하지만 xenbr0이 실제 브릿지이면 가능한 경우 이를 사용하는 것이 좋습니다.
    • 가상 스토리지 경로: 게스트의 디스크 정보를 저장하는 파일, LVM 논리 볼륨. 디렉토리 또는 블록 장치로의 경로입니다. 여기에는 /dev/sdb, /dev/LogVol00/mydisk, VolGroup00, /var/lib/xen/images/myDisk 등이 있습니다.
  4. 킥스타트 스케줄 및 종료를 클릭합니다.

2.5.4. RHN Proxy를 통해 프로비저닝

프로비저닝은 설치되어 RHN Satellite에 등록된 RHN Proxy를 사용하여 실행될 수 있습니다.
  1. 가상 게스트를 프로비저닝하거나 시스템을 재프로비저닝할 때 Satellite Proxy 선택 드롭 다운 메뉴에서 원하는 프록시를 선택합니다.
  2. 베어 메탈 설치의 경우, RHN Satellite의 정규화된 도메인 이름 (FQDN)을 프록시의 FQDN으로 바꿉니다. 예를 들어 킥스타트 파일에 대한 URL이 다음과 같은 경우:
    http://satellite.example.com/ks/cfg/org/1/label/myprofile
    
    Proxy를 통해 킥스타트하려면 다음 URL을 사용합니다:
    http://proxy.example.com/ks/cfg/org/1/label/myprofile
    

3장. 여러 Satellite

ISS (Inter-satellite synchronization)를 통해 Satellites 간의 컨텐츠를 조정할 수 있습니다. 이 기능은 조직의 필요에 따라 여러가지 다른 방법으로 사용할 수 있습니다. 다음 부분에서는 사용 사례와 조직에 적합한 ISS 설정 방법에 대해 설명합니다.

ISS 요건

ISS를 사용하기 위해 필요한 조건은 다음과 같습니다:
  • 두 개 이상의 RHN Satellite 서버
  • 최소 한 개의 채널이 배치된 최소 하나의 RHN Satellite
  • 보안 연결을 위해 각 슬레이브 RHN Satellite는 마스터 RHN Satellite SSL 인증서가 필요함

3.1. ISS (Inter-Satellite Synchronization)

절차 3.1. 마스터 서버 설정

마스터 서버는 다른 Satellite에 동기화되는 파일을 결정하기 위해 사용됩니다.
  1. ISS (Inter - Satellite Synchronization) 기능을 활성화합니다. /etc/rhn/rhn.conf 파일을 열고 다음 행을 추가하거나 수정합니다:
    disable_iss=0
    
  2. /etc/rhn/rhn.conf 파일에서 allowed_iss_slaves= 행을 찾습니다. 기본값으로 슬레이브 Satellite는 동기화를 위해 지정됩니다. 각 슬레이브 Satellite 서버의 호스트 이름을 콤마로 구분하여 입력합니다:
    allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org
    
  3. 설정 파일을 저장하고 httpd 서비스를 다시 시작합니다:
    service httpd restart
    

절차 3.2. 슬레이브 서버 설정

슬레이브 Satellite 서버는 마스터 서버에 컨텐츠가 동기화되는 시스템입니다.
  1. 컨텐츠를 슬레이브 서버에 안전하게 전송하기 위해 마스터 서버에서 ORG-SSL 인증서가 필요합니다. 이 인증서는 HTTP를 통해 모든 Satellite의 /pub/ 디렉토리에서 다운로드할 수 있습니다. 파일 이름은 RHN-ORG-TRUSTED-SSL-CERT 이지만, 이름을 변경하여 /usr/share/rhn/ 디렉토리와 같은 슬레이브의 로컬 파일 시스템의 아무곳에 배치할 수 있습니다.
  2. 다음 명령을 사용하여 마스터 서버에서 동기화할 수 있는 채널 목록을 확인합니다. 이는 공식적인 Red Hat 채널과 사용 가능한 사용자 정의 채널이 나타납니다:
    satellite-sync --iss-parent=master.satellite.example.com --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels
    
    master.satellite.example.com을 마스터 서버의 호스트 이름으로 바꿉니다.

절차 3.3. ISS (Inter-Satellite Synchronization) 실행

마스터 서버와 슬레이브 서버가 설정되면 이 사이에서 동기화를 실행할 수 있습니다.
  1. 슬레이브 서버에서 원하는 텍스트 편집기로 /etc/rhn/rhn.conf 파일을 열고 마스터 서버의 호스트 이름과 SSL 인증서 파일 경로 정보를 추가합니다:
    iss_parent      = master.satellite.example.com
    iss_ca_chain    = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
    
  2. satellite-sync 명령을 실행하여 동기화를 시작합니다:
    satellite-sync -c your-channel

    참고

    satellite-sync 명령으로 제공되는 명령행 옵션은 /etc/rhn/rhn.conf 파일에 있는 사용자 정의 설정을 덮어쓰게 됩니다.

3.2. 조직별 동기화

ISS는 컨텐츠를 특정 조직으로 가져오기 위해 사용될 수 있습니다. 이는 로컬 또는 원격 동기화를 사용하여 수행될 수 있습니다. 이 기능은 채널 덤프를 통해 컨텐츠가 검색되거나 연결된 Satellite에서 내보내기한 후 이를 연결 해제된 Satellite로 가져오는 방법으로 컨텐츠를 검색하는 여러 조직이 있는 연결 해제된 Satellite의 경우 유용합니다. 조직별 동기화는 연결된 Satellite에서 사용자 정의 채널을 내보내기하는데 사용될 수 있습니다. 이는 또한 여러 조직 간의 컨텐츠를 이동하는데 효과적으로 사용될 수 있습니다.
조직별 동기화는 소스 조직의 일관성을 유지하기 위해 일련의 명확한 규칙을 따르고 있습니다:
  • 소스 컨텐츠가 NULL 조직 (예: Red Hat 컨텐츠)에 속해 있는 경우 대상 조직이 지정된 경우에도 기본값으로 NULL이 됩니다. 이는 지정된 컨텐츠가 항상 권한이 있는 NULL 조직에 있는지를 확인합니다.
  • 명령행에서 조직을 지정할 경우, 컨텐츠는 해당 조직에서 가져오게 됩니다.
  • 조직이 지정되어 있지 않으면 기본적으로 조직 1로 지정됩니다.
다음은 조직 ID (orgid) 를 사용하여 Satellite를 동기화하는 세 가지 시나리오의 예입니다:

예 3.1. 마스터 Satellite에서 슬레이브 Satellite로 컨텐츠 가져오기

다음의 예에서는 마스터 Satellite에서 슬레이브 Satellite로 컨텐츠를 가져옵니다:
satellite-sync --parent-sat=master.satellite.example.com -c channel-name --orgid=2

예 3.2. 조직의 내보낸 덤프에서 컨텐츠 가져오기

다음의 예에서는 특정 조직의 내보낸 덤프에서 컨텐츠를 가져옵니다:
$ satellite-sync -m /dump -c channel-name --orgid=2

예 3.3. Red Hat Network 호스트에서 컨텐츠 가져오기

다음의 예에서는 Red Hat Network 호스트에서 컨텐츠를 가져옵니다 (시스템이 등록 및 활성화되어 있다고 가정):
$ satellite-sync -c channel-name

3.3. ISS 사용 사례

ISS는 조직의 필요에 따라 여러가지 다른 방법으로 사용될 수 있습니다. 다음 부분에서는 ISS 사용 방법과 이러한 경우를 설정 및 실행하는 방법의 예에 대해 설명합니다.

예 3.4. 스테이징 Satellite

이 예에서는 스테이징 Satellite로 하나의 Satellite를 사용하여 컨텐츠를 준비하고 패키지의 품질 보증 작업을 수행하여 프로덕션에서 사용하기에 적합한지를 확인합니다. 컨텐츠의 프로덕션에서 사용이 승인되면 프로덕션 Satellite는 스테이징 Satellite에서 컨텐츠를 동기화합니다.
  1. satellite-sync 명령을 실행하여 데이터를 rhn_parent (주로 Red Hat Network 호스트)와 동기화합니다:
    satellite-sync -c your-channel
    
  2. 다음 명령을 실행하여 스테이징 서버에서 데이터를 동기화합니다:
    satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel

예 3.5. 동기화된 슬레이브

예에서 마스터 Satellite는 슬레이브로 데이터를 직접 제공하고 변경 사항은 정기적으로 동기화됩니다.

예 3.6. 슬레이브의 사용자 정의 컨텐츠

다음의 예에서는 컨텐츠가 모든 프로덕션 슬레이브 Satellite로 배포되는 개발 채널로서 마스터 Satellite를 사용합니다. 일부 슬레이브 Satellite에는 마스터 Satellite 채널에는 없는 추가 컨텐츠가 들어 있습니다. 이러한 패키지는 보관되지만 마스터 Satellite에서의 모든 변경 사항은 슬레이브 Satellite로 동기화됩니다.

예 3.7. 양방향 동기화

이 환경에서는 두 개의 RHN Satellite 서버가 서로 마스터 역할을 하면서 두 서버 간의 컨텐츠를 동기화할 수 있습니다.
  1. 두 Satellite가 SSL 인증서를 공유할 수 있는지 확인합니다.
  2. 첫 번째 Satellite에서 /etc/rhn/rhn.conf 파일을 열고 두 번째 Satellite의 호스트 이름을 가리키도록 iss_parent 옵션을 설정합니다.
  3. 두 번째 Satellite에서 /etc/rhn/rhn.conf 파일을 열고 첫 번째 Satellite의 호스트 이름을 가리키도록 iss_parent 옵션을 설정합니다.

4장. 고급 API 방식 및 명령

4.1. XML-RPC API

RHN Satellite 5.5는 XML-RPC API를 사용하여 프로비저닝을 지원합니다.
다음의 API 방식은 킥스타트 프로파일 및 트리 유지 관리를 위해 사용됩니다:

표 4.1. XML-RPC 방식

XML-RPC 네임스페이스 사용법
kickstart 킥스타트 프로파일을 가져오기, 생성, 삭제에 사용됩니다. 또한 사용 가능한 킥스타트 트리 및 프로파일을 나열하는데 사용됩니다.
kickstart.tree 킥스타트 트리를 생성, 이름 변경, 업데이트, 삭제합니다.
kickstart.filepreservation 킥스타트 프로파일과 연관된 파일 보관 목록을 나열, 생성, 삭제합니다. 파일 보관 목록을 생성한 후, kickstart.profile.system.add_file_preservations API 메서드를 호출하여 킥스타트 프로파일과 연결시킬 수 있습니다.
kickstart.keys 다른 킥스타트 프로파일과 관련된 암호화 키 (GPG/SSL)를 나열, 생성, 삭제합니다.

참고

암호키를 만든 후, kickstart.profile.system.add_keys API 메서드를 호출하여 킥스타트 프로파일에 연결시킬 수 있습니다.
kickstart.profile IP 범위의 조정, 킥스타트 트리와 자식 채널 변경, 프로파일과 연관된 킥스타트 파일 다운로드, 고급 옵션 지정, 사용자 지정 옵션 지정, 킥스타트 프로파일에 사전 스크립트 및 사후 스크립트를 추가합니다.
kickstart.profile.keys 킥스타트 프로파일과 관련된 활성키를 나열, 추가 (연결), 삭제 (연결 해제)합니다.
kickstart.profile.software 킥스타트 프로파일에 연관된 패키지 목록을 조작합니다.
kickstart.profile.system 파일 보존 관리, 암호키 관리, 설정 관리 및 원격 명령 활성화/비활성화, 파티션 구성 설정, 특정 킥스타트 프로파일에 연결된 로컬 정보를 설정합니다.
다음의 API 메서드 호출을 사용하여 호스트를 재프로비저닝 및 게스트 설치를 스케줄할 수 있습니다:
  • system.provision_system
  • system.provision_virtual_guest
API 호출에 대한 보다 자세한 내용은 https://satellite.example.com/rpc/api의 API 문서를 참조하십시오.

4.2. Cobbler

RHN Satellite는 프로비저닝을 위해 Cobbler를 사용합니다. RHN Satellite에서 프로비저닝을 위한 시스템, 킥스타트 프로파일, 트리 (배포판)가 업데이트될 때 RHN Satellite 호스트에서 Cobbler 인스턴스와 동기화됩니다. 이는 Cobbler를 직접 사용하여 프로비저닝을 관리할 수 있음을 의미합니다.
다음 표에서는 Cobbler 명령에 대해 설명합니다:

표 4.2. Cobbler 명령

명령 사용법
cobbler profile list RHN Satellite 호스트에서 명령을 실행하여 프로파일 목록을 보여줍니다
cobbler distro list 킥스타트 트리, 커널, RAM 디스크, 기타 다른 옵션 목록을 보여줍니다
cobbler system list 킥스타트를 스케줄할 때 생성된 시스템 기록 목록을 보여줍니다
cobbler profile report --name=profile-name 또는 cobbler system report --name=system-name 특정 개체애 대한 보다 자세한 정보 출력을 보여줍니다
cobbler profile edit --name=profile-name --virt-ram=1024 다양한 매개 변수를 편집합니다. 이 예에서는 프로파일의 가상화 설치에 각각 1 GB의 RAM이 할당됩니다.
cobbler system edit --name=system-name --netboot-enabled=1 다음에 다시 시작할 때 시스템을 다시 설치하도록 강제합니다
cobbler system edit --name=system-name --profile=new-profile-name --netboot-enabled=1 다시 설치하기 위해 시스템을 새로운 프로파일에 할당합니다
cobbler system find --profile=profile-name 프로파일에 할당된 모든 시스템을 나열합니다
cobbler system find --profile="abc" | xargs -n1 --replace cobbler system edit \ --name={} --profile="def" --netboot-enabled=1 현재 abc 프로파일에 설정된 모든 시스템을 def 프로파일에 할당하고 다음번에 다시 부팅할 때 다시 설치합니다.
cobbler profile edit --name=profilename --kopts="variablename=3" --in-place 다른 변수를 변경하지 않고 프로파일에 있는 추가 템플릿 기능 변수를 설정합니다
cobbler system edit --name=systemname --kopts="selinux=disabled asdf=jkl" 시스템 기록에 여러 변수를 지정하고 이전에 설정되어 있을 가능성이 있는 오래된 변수를 무시합니다.
cobbler profile find --name="*webserver*" | xargs -n1 --replace cobbler profile edit --name={} --profile="RHEL5-i386" RHEL5-i386 라는 프로파일을 사용하기 위해 문자열로 webserver이 포함된 프로파일의 모든 새로운 설치를 설정합니다.
기타 Cobbler 설정

/etc/cobbler/settings 디렉토리에서 변경해야 하는 일부 Cobbler 설정이 있습니다. 그 중 하나가 pxe_just_once 옵션입니다 (절차 4.3. “PXE 사용을 위해 Cobbler 설정 ”에서 참조). server 옵션은 RHN Satellite 서버의 주소 또는 호스트 이름을 반영하도록 변경할 수 있습니다.

/etc/cobbler/settings을 변경한 후, 다음 명령을 실행하여 변경 사항을 확인합니다:
/sbin/service cobblerd restart
cobbler sync

중요

/etc/cobbler/settings에 있는 다른 설정은 조정하지 마십시오. RHN Satellite는 이 파일에 RHN Satellite 설치 프로그램이 결정한 설정이 유지되는 것을 필요로 합니다. 마찬가지로 인증 소스를 제어하는 /etc/cobbler/modules.conf 파일은 RHN Satellite 설치 프로그램에서 생성된 상태로 유지해야 합니다. 특히, 인증 모듈은 반드시 authn_spacewalk 상태로 남아 있어야 하며 변경할 수 없습니다.

절차 4.1. Cobbler와 함께 사용하는 SELinux 설정

SELinux 지원 및 보완 방화벽은 Red Hat Enterprise Linux를 사용하여 기본값으로 설치됩니다. Cobbler를 사용하기 위해 Red Hat Enterprise Linux 서버를 올바르게 구성하려면, Cobbler 서버와 연결이 가능하도록 SELinux를 설정해야 합니다.
  1. Cobbler 지원을 위해 SELinux를 활성화하려면, 다음 명령을 사용하여 SELinux 부울이 HTTPD 웹 서비스 구성 요소를 허용하도록 설정해야 합니다:
    setsebool -P httpd_can_network_connect true
    
    -P 스위치는 필수적입니다. 따라서 모든 시스템이 다시 시작해도 HTTPD 연결을 영구적으로 사용할 수 있습니다.
  2. Cobbler 서버에서 다음 명령을 사용하여 부트 이미지 파일을 제공하기 위해 TFTP에 대한 SELinux 파일 문맥 규칙을 설정합니다:
    semanage fcontext -a -t public_content_t "var/lib/tftpboot/.*"
    
  3. IPTables는 Cobbler 서버에서 들어오고 나가는 네트워크 흐름을 허용하도록 설정되어야 합니다.
    iptables를 사용하는 기존 방화벽 규칙이 있을 경우, 다음과 같은 규칙을 추가하여 다음과 같이 Cobbler 관련 포트를 엽니다:
    TFTP 용:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT
    
    HTTPD 용:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    
    Cobbler 용:
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j ACCEPT
    
    Koan 용:
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j ACCEPT
    
  4. 방화벽 설정 저장:
    /sbin/iptables-save
    
  5. 다음의 명령을 실행하여 설정 파일이 모두 동기화되어 있는지를 확인:
    cobbler sync
    
  6. Satellite 서버 시작:
    /usr/sbin/rhn-satellite start
    

    주의

    Satellite 서비스에 의존하지 않는 cobblerd 서비스를 시작 또는 중지하지 마십시오. 오류 및 기타 문제가 발생하는 원인이 될 수 있습니다.
    RHN Satellite를 시작 또는 중지하기 위해 항상 /usr/sbin/rhn-satellite 명령을 사용합니다.

절차 4.2. Cobbler 시스템 기록 설정

Cobbler 시스템 기록은 시스템 및 관련 킥스타트 프로파일을 기록하는 Cobbler의 개체입니다. PXE 킥스타트를 실행하려면, Satellite 킥스타트 프로파일은 킥스타트하려는 시스템의 Cobbler 시스템 기록과 연결되어 있어야 합니다.
  1. 각 시스템의 시스템 정보프로비저닝으로 가서 연관된 킥스타트 프로파일을 선택합니다.
  2. Cobbler 시스템 기록 작성을 클릭하여 연결합니다.
  3. 이 연결은 모든 시스템에 대해 pxe_just_once옵션을 true로 설정하지 않는한 영구적으로 남아 있게 됩니다. 이러한 경우 성공적으로 킥스타트 후 연결이 해제됩니다. 이 설정에 대한 자세한 내용은 절차 4.3. “PXE 사용을 위해 Cobbler 설정 ”에서 참조하십시오.

절차 4.3. PXE 사용을 위해 Cobbler 설정

Cobbler는 기본값으로 PXE 구성을 생성하기 위해 설정되지만 BIOS에서 최상의 PXE 워크플로우를 얻기 위해 pxe_just_once 설정 옵션을 조정할 수 있습니다.
  1. 주로 BIOS 순서는 PXE 부팅이 먼저 실행되도록 설정됩니다. PXE 서버가 이를 원격으로 실행하도록 지시하지 않는한 시스템은 로컬 디스크에서 부팅하지 않음을 의미합니다. 이 설정은 시스템이 계속해서 다시 설치하는 부트 루프를 발생시킬 수 있습니다.
    부트 루프를 방지하려면 /etc/cobbler/settings 파일을 열고 다음 행을 추가합니다:
    pxe_just_once: 1
    
    이러한 설정은 킥스타트 탬플릿에 있는 $kickstart_done 매크로를 추가합니다. 이는 설치가 완료된 후 시스템이 네트워크가 아닌 로컬로 부팅하도록 지시합니다.
  2. pxe_just_once: 1 설정 매개 변수를 추가하여 시스템을 나중에 다시 설치하려는 경우, 시스템의 netboot-enabled 플래그를 변경해야 합니다. 이는 RHN Satellite 웹 인터페이스를 사용하거나 직접 Cobbler에서 수행할 수 있습니다. 시스템이 다음번에 부팅할 때, PXE 설치가 실행되고 플래그가 다시 설정될 때 까지 로컬 디스트에서 부팅으로 돌아갑니다.
    로컬 하드 드라이브에서 먼저 시작하도록 BIOS를 설정하는 경우, pxe_just_once를 활성화할 필요가 없습니다. 하지만, PXE를 사용하여 시스템을 재프로비저닝하려면, MBR (마스터 부트 레코드)를 초기화상태로 설정해야 합니다.

이름 지정 규칙

RHN Satellite와 Cobbler 간의 데이터 동기화 상태를 유지하려면, RHN Satellite는 배포 및 프로파일에 대한 이름 지정 규칙을 사용합니다. 이러한 이름 지정 규칙은 명령행 인터페이스를 사용하여 Cobbler와 상호 작용하는 경우 중요합니다.
배포
$tree_name:$org_id:$org_name (수동으로 생성되었을 경우)
$tree_name (RHN Satellite로 동기화되었을 경우)
프로파일
$profile_name:$org_id:$org_name

중요

RHN Satellite에 의해 자동 생성된 이름을 변경하지 마십시오. 이름이 변경될 경우, RHN Satellite는 이러한 항목을 더이상 관리 유지할 수 없게 됩니다.

참고

문제 해결을 위해 Cobbler는 RHN Satellite 로그 및 /var/log/cobbler/ 파일에 있는 데이터를 기록합니다

4.3. Koan

koan (네트워크를 통한 킥스타트) 유틸리티는 프로비저닝된 호스트에서 RHN Satellite에 원격으로 액세스하게 합니다. Koan을 통해 킥스타트 프로비저닝 실행, (가상 호스트 상에서) 가상 게스트 생성, RHN Satellite 호스트에서 사용 가능한 킥스타트를 나열할 수 있습니다. 이는 koan 패키지에서 사용 가능합니다.

표 4.3. Koan 명령

명령 사용법
man koan koan man 페이지를 읽어보십시오
koan --replace-self --server=satellite.example.org --profile=profile-name 또는 koan --replace-self --server=satellite.example.org --system=system-name 기존 시스템을 재프로비저닝합니다. 이 명령을 실행한 후, 다시 부팅하여 새로운 운영 체제를 설치합니다. 이는 킥스타트 업그레이드에도 사용될 수 있습니다. (예: 여러 시스템을 하나의 Red Hat Enterprise Linux 버전에서 다음 버전으로 업그레이드하는 등)
koan --virt --server=satellite.example.org --profile=profile-name 또는 koan --virt --server=satellite.example.org --system=system-name 가상 게스트를 프로비저닝합니다.
koan --list=profiles --server=satellite.example.org 또는 koan --list=systems --server=satellite.example.org Cobbler를 쿼리하여 원격 설치를 위해 사용 가능한 프로파일 또는 시스템 목록을 보여줍니다.

참고

문제 해결을 위해 Koan은 /var/log/koan에 데이터를 기록합니다.

5장. 문제 해결

5.1. 웹 인터페이스
질문 RHN Satellite 사용자 인터페이스에 문제가 있습니다. 어떤 로그 파일을 확인해야 합니까?
5.2. Anaconda
질문 Error downloading kickstart file라는 메세지가 나타나는 오류가 발생했습니다. 무엇이 문제이고 어떻게 해결해야 합니까?
질문 The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened. 라고 나타나는 패키지 설치 오류가 발생했습니다. 무엇이 문제이고 어떻게 해결해야 합니까?
5.3. 역추적
질문 "WEB TRACEBACK"이라는 제목의 이메일이 수신되고 있습니다. 어떻게 해야 합니까?
5.4. 등록
질문 rhnreg_ks 명령을 실행하면 ERROR: unable to read system id라는 오류 메세지가 표시되고 실행 실패하게 됩니다. 무엇이 문제입니까?
5.5. 킥스타트 및 스니펫
질문 킥스타트의 디렉토리 구조는 어떻게 되어 있습니까?
질문 Cobbler 스니펫의 디렉토리 구조는 어떻게 되어 있습니까?

5.1. 웹 인터페이스

질문
RHN Satellite 사용자 인터페이스에 문제가 있습니다. 어떤 로그 파일을 확인해야 합니까?
답변
RHN Satellite 사용자 인터페이스에 있는 킥스타트로 작업을 하거나 보기 또는 스케줄링에서 문제가 발생할 경우, /var/log/tomcat5/catalina.out 로그 파일을 확인합니다.
모든 다른 사용자 인터페이스 오류의 경우, /var/log/httpd/error_log 로그 파일을 확인합니다.

5.2. Anaconda

질문
Error downloading kickstart file라는 메세지가 나타나는 오류가 발생했습니다. 무엇이 문제이고 어떻게 해결해야 합니까?
답변
이 오류는 대개 네트워크 문제로 인해 발생합니다. 이 문제를 해결하려면 cobbler check 명령을 실행하여 출력을 확인합니다. 다음과 같은 출력이 표시되어야 합니다:
# cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
cobbler check로 문제를 파악할 수 없는 경우에는 다음 사항을 확인하십시오:
  • httpd가 실행되고 있는지 확인합니다: service httpd status
  • cobblerd가 실행되고 있는지 확인합니다: service cobblerd status
  • 다른 호스트에서 wget을 사용하여 킥스타트 파일을 가져올 수 있는지 확인합니다:
    wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386-u3:1:Example-Org
질문
The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened. 라고 나타나는 패키지 설치 오류가 발생했습니다. 무엇이 문제이고 어떻게 해결해야 합니까?
답변
클라이언트는 킥스타트에 있는 --url 매개 변수에 기반하여 RHN Satellite에서 컨텐츠를 가져오기합니다. 예:
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Anaconda에서 이미지 또는 패키지를 찾을 수 없다는 오류를 수신한 경우, 킥스타트의 URL이 200 OK 응답을 생성하는지를 확인합니다. 이는 해당 URL에 파일이 위치한 곳을 wget을 시도하여 실행할 수 있습니다:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
--2011-08-19 15:06:55--  http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Resolving satellite.example.com... 10.10.77.131
Connecting to satellite.example.com|10.10.77.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `ks-rhel-i386-server-5-u3.1'
2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
200 OK 이외의 응답을 받을 경우, 오류 로그를 확인하여 문제를 찾아냅니다. access_log 파일을 검색하여 Anaconda가 다운로드하려는 실제 파일을 확인할 수 있습니다:
# grep chkconfig /var/log/httpd/access_log
10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server-
5-u3/Server  /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-
1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-  
1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 
5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
이 요청이 access_log 파일에 나타나지 않으면, 시스템에는 네트워크 설정 문제가 있을 수 있습니다. 요청이 나타나도 오류가 발생하는 경우에도 오류 로그를 확인합니다.
파일을 수동으로 다운로드하여 패키지의 사용 여부를 확인할 수 있습니다:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm

5.3. 역추적

질문
"WEB TRACEBACK"이라는 제목의 이메일이 수신되고 있습니다. 어떻게 해야 합니까?
답변
전형적인 역추적 이메일은 다음과 같이 나타납니다:
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From: RHN Satellite <dev-null@redhat.com>
To: admin@example.com

java.lang.RuntimeException: XmlRpcException calling cobbler.
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
	at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
	at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54)
	at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
	at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
	at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
	... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236)
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
	... 7 more
이는 Cobbler가 taskomatic 서비스와의 통신에 문제가 발생한 것을 나타냅니다. 다음 사항을 확인하십시오:
  • httpd가 실행되고 있는지 확인합니다: service httpd status
  • cobblerd가 실행되고 있는지 확인합니다: service cobblerd status
  • localhost 연결을 방해하는 방화벽 규칙이 없는지 확인합니다

5.4. 등록

질문
rhnreg_ks 명령을 실행하면 ERROR: unable to read system id라는 오류 메세지가 표시되고 실행 실패하게 됩니다. 무엇이 문제입니까?
답변
킥스타트 파일의 끝에 %post 부분이 있으며 이를 통해 시스템을 RHN Satellite에 등록합니다:
# begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT   
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*  
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d
# end Red Hat management server registration
추가된 순서로 이를 해석하여 다음을 수행합니다:
  • RHN Satellite에서 사용하는 사요자 정의 SSL 인증서를 수용할 수 있는 디렉토리리를 생성합니다.
  • 등록 시 사용할 SSL 인증서를 가져옵니다.
  • rhn-register 설정 파일에서 SSL 인증서 검색 및 교체, SSL 인증서 및 활성키를 사용하여 RHN Satellite에 등록을 순서대로 실행합니다. 각 킥스타트 프로파일에는 활성키가 포함되어 있어 올바른 기본 채널과 자식 채널이 시스템에 할당하게 하고 올바른 시스템 인타이틀먼트를 획득하게 합니다. 기존 시스템을 다시 프로비저닝하는 경우, 활성키는 이전 시스템 프로파일에 확실히 연결되게 합니다.
rhnreg_ks 명령이 실패한 경우, ks-post.log 로그 파일에 다음과 같은 오류가 나타나게 됩니다:
ERROR: unable to read system id.
이러한 오류는 rhn_check을 실행했을 때 시스템이 RHN Satellite에 등록되지 않은 경우에도 발생합니다.
이에 대한 가장 적절한 문제 해결 방법은 킥스타트가 완료된 후 킥스타트 파일을 확인하고 명령 프롬프트에 위의 네 가지 단계를 직접 복사하여 붙여넣는 것입니다. 이는 문제 해결에 도움이 되는 보다 상세한 오류 메세지를 생성합니다.

5.5. 킥스타트 및 스니펫

질문
킥스타트의 디렉토리 구조는 어떻게 되어 있습니까?
답변
킥스타트 파일이 저장되어 있는 기본 경로는 /var/lib/rhn/kickstarts/입니다. 이 디렉토리에서 raw 킥스타트는 upload 하위 디렉토리에 저장되고 마법사가 생성된 킥스타트는 wizard 하위 디렉토리에 저장됩니다:
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
질문
Cobbler 스니펫의 디렉토리 구조는 어떻게 되어 있습니까?
답변
Cobbler 스니펫은 /var/lib/rhn/kickstarts/snippets에 저장됩니다. Cobbler는 /var/lib/cobbler/snippets/spacewalk의 심볼릭 링크를 사용하여 스니펫에 액세스합니다.
Snippets:  /var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name

중요

RHN Satellite RPM은 Cobbler 킥스타트와 스니펫 디렉토리가 기본값 위치에 있다고 간주하기 때문에 이를 변경해서는 안됩니다.

부록 A. 고친 과정

고친 과정
고침 4-2.1.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
고침 4-2.1Thu Feb 21 2013Eun_Ju Kim
번역 파일이 XML 소스 4-2와 동기화됨
고침 4-2Wed Sept 19 2012Dan Macpherson
5.5 용 최종 패키지 구성
고침 4-1Thu Aug 9 2012Athene Chan
릴리즈 준비
고침 4-0Mon June 25 2012Athene Chan
RHN Satellite 5.5의 1장 및 2장 업데이트
RHN Satellite 5.5의 3장에서 5장 까지 수정
BZ#787348 잘못된 Cobbler iptables 행 수정
BZ#702529 킥스타트 내용 추가
BZ#797688 Cobbler Boot ISO는 지원되지 않음
고침 3-0Thu May 31 2012Athene Chan
BZ#826803 - "시스템 킥스타트" 섹션의 문장 부호 수정
킥스타트 섹션에서 약간의 문법적 오류 변경
고침 2-0Thu May 24 2012Athene Chan
BZ#783339 - "Taskomatic 문제 해결 프로비저닝" 부분 문장 재구성
BZ#783340 - "s390x"를 "IBM System z"로 업데이트
고침 1-3Mon Aug 15 2011Lana Brindley
z-stream을 y-stream으로 출시
고침 1-2Wed Jun 15 2011Lana Brindley
번역을 위한 준비
고침 1-1Fri May 27 2011Lana Brindley
번역사로 부터 업데이트
고침 1-0Fri May 6, 2011Lana Brindley
최종 QE 리뷰 편집
번역을 위한 준비
고침 0-8Thu May 5, 2011Lana Brindley
BZ#701822 - QE 리뷰
고침 0-7Thu April 14, 2011Lana Brindley
기술 리뷰 피드백
고침 0-6Wed March 23, 2011Lana Brindley
기술 리뷰를 위한 준비
고침 0-5Tue March 22, 2011Lana Brindley
BZ#666435
BZ#666846
BZ#678080
BZ#682364
고침 0-4Tue March 22, 2011Lana Brindley
문제 해결
고침 0-3Mon March 21, 2011Lana Brindley
여러 Satellites
고침 0-2Thu March 17, 2011Lana Brindley
소개
킥스타트
고급 명령
일부 장 재구성
고침 0-1Wed Jan 5, 2011Lana Brindley
새로운 장 구성 완료
고침 0-0Tue Dec 21, 2010Lana Brindley
기존의 RHN Satellite 운용 가이드에서 새 문서 생성

법적 공지

Copyright © 2011 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.