지난 수년 동안 고객 피드백을 적극 반영하여 개선하고자 하는 노력 덕분에 SUSE는 사용자에게 업데이트를 제공하는 방식과 관련하여 다양한 변경을 구현해왔습니다.

그림 7.1. “유지보수 제공 개선 (SLED에도 적용됨)”은(는) 위에서 언급된 측면 중 일부를 나타냅니다.

 그림 7.1. 유지보수 제공 개선 (SLED에도 적용됨)¶

당사의 제품은 수명 주기가 10년인데, 7년은 일반적인 지원이고 3년은 연장 지원입니다. 주요 릴리스는 4년마다 개발되고 서비스 팩은 18개월마다 개발됩니다. 장기 서비스 팩 지원은 연장된 업그레이드 시간 또는 연장된 주요 릴리스 수명 주기입니다(그림 7.2. “장기 서비스 팩 지원” 참조).

 그림 7.2. 장기 서비스 팩 지원¶

장기 서비스 팩 지원을 받으려면 활성 구독(표준 또는 중요도)이 필요합니다. 이것은 L1 또는 L2 구독 기간에 영향을 미치지 않습니다. 보안 업데이트는 “사전 대응” 방식으로 처리됩니다. 이러한 업데이트로는 비사용자 기반의 심각한 취약성, 커널의 로컬 루트 이용 또는 사용자 개입 없이 직접 실행 가능한 기타 루트 이용이 있습니다.

연장 지원 수준 범위는 8년에 시작하여 10년에 종료됩니다. 이러한 지원은 지속적인 L3 엔지니어링 수준 진단과 반응형 중요 버그 수정을 포함합니다. 이러한 지원 수준은 사전 대응 방식으로 커널의 사소한 로컬 루트 이용 또는 사용자의 작업 없이 직접 실행 가능한 기타 루트 이용을 업데이트합니다. 또한 제한된 패키지 제외 목록을 통해 기존 작업 부하, 소프트웨어 스택 및 하드웨어를 지원합니다. 표 7.1. “보안 업데이트 및 버그 수정”에서 개요를 참조하십시오.

이전 유지보수 모델의 SUSE Linux Enterprise Server에는 SLES11-SPx-Pool 및 SLES11-SPx-Updates의 할당된 채널이 2개 있습니다. SPx+1으로 온라인 마이그레이션하는 중에 이 채널이 SLES11-SPx-Online으로 임시 변경되었습니다.

SUSE Linux Enterprise SP2의 경우 새로운 유지보수 모델의 이점을 지원하기 위해 채널 레이아웃이 변경되었습니다. 표 7.2. “SUSE Linux Enterprise 11 SP1, SP2 및 SP3의 채널 레이아웃”에는 SP1에서 SP3의 모든 채널 목록이 포함되어 있습니다.

zypper repos -u

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
  SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
  SLES11-SP2-Core SLES11-SP2-Updates \
  SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
  SLE11-SP2-Debuginfo-Updates

zypper addrepo -n SLES11-SP2-Extension-Store \
 https://nu.novell.com/repo/$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

업데이트하기 전에 기존 구성 파일을 테이프 장치, 이동식 하드 디스크 등과 같은 별도의 매체에 복사하여 데이터를 백업합니다. 이 사항은 주로 /var 및 /opt의 일부 디렉토리 및 파일뿐만 아니라, /etc에 저장된 파일에도 적용됩니다. 또한 /home(HOME 디렉토리)의 사용자 데이터를 백업 매체에 기록해야 할 수도 있습니다. 이 데이터를 root로 백업합니다. root에만 모든 로컬 파일에 대한 읽기 권한이 있습니다.

YaST에서 설치 모드로 기존 시스템 업데이트를 선택한 경우 나중에 (시스템) 백업을 수행하도록 선택할 수 있습니다. 수정된 모든 파일과 /etc/sysconfig 디렉토리의 파일을 포함하도록 선택할 수 있습니다. 그러나 이는 위에서 언급한 다른 모든 중요한 디렉토리가 없기 때문에 전체 백업은 아닙니다. /var/adm/backup 디렉토리에서 백업을 확인하십시오.

업데이트를 시작하기 전에 루트 파티션을 기록해 두십시오. df / 명령은 루트 파티션의 장치 이름을 나열합니다. 예 7.1. “df -h로 나열”에서 기록할 루트 파티션은 /dev/sda3(/로 탑재됨)입니다.

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       44G    4G   40G   9% /data

소프트웨어는 버전이 바뀌면서 “커지는” 경향이 있습니다. 따라서 업데이트하기 전에 df로 사용 가능한 파티션 공간을 살펴보십시오. 실행 중인 디스크 공간이 부족할 것 같으면 시스템을 업데이트하고 파티션을 다시 설정하기 전에 데이터를 보호하십시오. 각 파티션의 크기에 대한 일반적인 규칙은 없습니다. 공간 요구사항은 특정 파티셔닝 프로파일과 선택한 소프트웨어에 따라 달라집니다.

시스템이 KVM 또는 Xen에 대한 VM Host Server 역할을 할 경우 업데이트 전에 실행 중인 VM Guest가 모두 올바르게 종료되었는지 확인합니다. 그렇지 않으면 업데이트 후 게스트에 액세스할 수 없습니다.

버전 관련 요구사항은 업데이트 제품과 함께 제공되는 릴리스 정보를 참조하십시오. 릴리스 정보에는 업그레이드 절차에 대한 추가 정보가 있습니다.

SUSE Linux Enterprise Server에 대한 최신 정보가 포함된 릴리스 정보 문서의 최신 버전을 http://www.suse.com/doc/sles11/#additional에서 온라인으로 확인할 수 있습니다.

온라인 마이그레이션을 통한 시스템 업데이트는 실행 중인 시스템에서 수행됩니다. 업데이트가 완료된 후 다시 부팅하면 됩니다.

7.5.1.1. 요구사항¶

온라인 업데이트를 수행하려면 다음 요구사항이 충족되어야 합니다. 또한 7.4절 “업데이트를 위한 일반 준비사항” 항목을 읽어 보십시오.

제품 등록

업데이트 채널에 연결하려면 먼저 제품을 등록해야 합니다. 등록하지 않은 경우 YaST에서 Novell 고객 센터 구성 모듈을 실행하거나 suse_register 명령 줄 도구를 실행하여 등록을 시작합니다.

온라인 업데이트 실행

현재 설치된 버전에 최신 패치가 설치되어 있는지 확인합니다. 온라인 마이그레이션 전에 온라인 업데이트를 실행합니다. 그래픽 인터페이스를 사용할 경우 YaST 온라인 업데이트 또는 업데이터 애플릿을 시작합니다. 명령 줄에서 다음 명령을 실행합니다(마지막 명령은 두 번 실행해야 함).

zypper ref -s
zypper update -t patch
zypper update -t patch

필요에 따라 시스템을 다시 부팅합니다.

온라인 업데이트 도구에 대한 자세한 내용은 (↑Administration Guide(관리 설명서))1장 YaST Online Update 또는 (6장 Managing Software with Command Line Tools, ↑Administration Guide(관리 설명서))“Updating Software with Zypper” 에서 확인하십시오.

타사 소프트웨어

타사 소프트웨어나 추가 기능 소프트웨어가 설정에 사용되는 경우 다른 시스템에서 이 절차를 테스트하여 업데이트에 의해 종속성이 손상되지 않는지 확인하십시오.

	항상 전체 온라인 마이그레이션 실행
처음부터 끝까지 항상 온라인 마이그레이션을 수행해야 합니다. 중간에 온라인 마이그레이션이 중단되면 시스템이 복구할 수 없을 정도로 손상됩니다.

온라인 마이그레이션(7.5.1절 “온라인 마이그레이션” 참조)을 수행하기 위해 설치 소스(DVD 또는 네트워크 설치 소스)에서 부팅하여 시스템을 업데이트할 수도 있습니다. 업데이트가 일반 설치처럼 시작됩니다.

서비스 팩 2 ISO 이미지를 http://download.novell.com/에서 가져올 수 있습니다. 14.2절 “설치 원본을 보유하는 서버 설정”에서 설명한 대로 DVD를 굽거나 네트워크 설치 소스를 준비하십시오.

Novell 업데이트 서버에서 단일 클라이언트 시스템의 업데이트를 다운로드하기 위해 SUSE Linux Enterprise용 Subscription Management Tool(SMT)를 사용하여 업데이트를 로컬 서버로 미러링할 수 있습니다.

이 도구는 클라이언트 등록을 위해 그리고 소프트웨어 업데이트 리포지토리로 Novell Customer Center 프록시 역할을 수행합니다. http://www.suse.com/doc/smt11/의 SMT 문서에서는 기능에 대한 개요뿐만 아니라 기능을 구현하는 방법도 설명합니다.

SUSE Manager는 SUSE Linux Enterprise 클라이언트용 업데이트, 패치 및 보안을 제공하기 위한 서버 솔루션입니다. 이 솔루션에는 관리 작업 도구 세트와 웹 기반 사용자 인터페이스가 함께 제공됩니다.

http://www.suse.com/doc/suse_manager/의 SUSE Manager 문서에서 기능에 대한 개요뿐만 아니라 서버 및 클라이언트를 설정하는 방법도 설명합니다.

온라인 업데이트를 수행하려면 다음 요구사항이 충족되어야 합니다. 또한 7.4절 “업데이트를 위한 일반 준비사항” 항목을 읽어 보십시오.

	항상 전체 온라인 마이그레이션 실행
처음부터 끝까지 항상 온라인 마이그레이션을 수행해야 합니다. 중간에 온라인 마이그레이션이 중단되면 시스템이 복구할 수 없을 정도로 손상됩니다.

업스트림 개발자는 기본적으로 자신이 개발하는 소프트웨어의 개선에 관심을 갖고 있습니다. 대부분의 경우 아직 광범위한 테스트를 받지 않았고 새로운 버그를 적용할 수 있는 새로운 기능을 버그 수정과 결합합니다.

배포 개발자의 경우 다음을 구분하는 것이 중요합니다.

대부분의 경우 배포 개발자는 패키지가 릴리스된 배포에 포함되면 모든 업스트림 변경사항을 적용하지 않습니다. 일반적으로 처음 릴리스한 업스트림 버전을 사용하고 업스트림 변경사항을 기반으로 한 패치를 작성하여 버그를 수정합니다. 이러한 방식을 백포팅이라고 합니다.

일반적으로 배포 관리자는 다음 두 가지 경우에만 최신 버전의 소프트웨어를 사용합니다.

SUSE에서는 엔터프라이즈 소프트웨어의 수많은 관심 항목 간에 적절한 균형을 찾는 동안 광범위하게 백포트를 사용합니다. 이 중에서 가장 중요한 것은 다음과 같습니다.

당사 엔터프라이즈 제품에 새로운 업스트림 버전의 패키지를 사용하지 않는 것이 일반적인 정책 규칙입니다. 그러나 이 규칙이 절대적인 것은 아닙니다. 제한된 패키지 클래스의 경우 특히 바이러스 백신 소프트웨어에서는 품질 보증 관점에서 선호하는 보수적인 방식보다 보안이 더 중요합니다. 해당 클래스에 해당되는 패키지의 경우 가끔 최신 버전이 릴리스된 버전의 엔터프라이즈 제품군에 사용될 수 있습니다.

다른 유형의 패키지인 경우에도 백포트 대신 새로운 버전을 사용할 수 있습니다. 백포트를 제작하는 것이 경제적이지 않거나 최신 버전을 사용해야 하는 기술적 이유가 있는 경우에는 새로운 버전을 사용합니다.

백포트의 사용 방식 때문에 단순히 버전 번호를 비교하여 SUSE 패키지에 특정 문제에 대한 수정사항이 포함되어 있거나 특정 기능이 추가되어 있는 지는 알 수 없습니다. 백포트를 사용할 경우 SUSE 패키지 버전 번호의 업스트림 부분은 단순히 SUSE 패키지의 기반이 되는 업스트림 버전을 나타냅니다. 여기에는 해당 업스트림 릴리스에 없지만 SUSE 패키지에 백포팅된 버그 수정사항과 기능이 포함될 수 있습니다.

해당 버그 수정사항 및 기능과 관련된 정보가 저장되는 여러 위치는 다음과 같습니다.

백포팅이 관련된 경우 제한된 버전 번호 값으로 인해 문제가 발생할 수 있는 특정 영역 중 하나가 보안 검색 도구입니다. 일부 보안 취약성 검색 도구(또는 해당 도구의 특정 테스트)는 버전 정보에서만 실행됩니다. 따라서 백포트가 관련된 경우 이 도구/테스트는 “양성 오류”(실제로는 취약하지 않은 소프트웨어에서 취약한 부분이 발견되었다고 보고함)를 생성하기 쉽습니다. 보안 검색 도구에서 보고서를 평가할 경우 사용자는 항상 항목이 버전 번호를 기반으로 하는지 또는 실제 취약성이 있는지 실제로 테스트한 것을 기반으로 하는지 조사해야 합니다.

multi-update를 실행합니다. 이 명령은 chroot 환경에서 zypper를 실행하며 활성 상태인 시스템에 상관 없이 다른 시스템을 업데이트합니다. 해당 시스템의 부팅 메뉴가 부팅 시 기본으로 제공됩니다.

업데이트 후 업데이트된 시스템의 부팅 로더가 손상된 경우 “활성” 플래그를 변경하여 다른 시스템의 루트 파티션을 부팅 가능하도록 설정해야 합니다.

업데이트된 시스템이 부팅되지 않으면 부팅 로더 메뉴에 액세스하여 다른 시스템을 선택해야 합니다.

GRUB에 대한 자세한 내용은 (↑Administration Guide(관리 설명서))10장 The Boot Loader GRUB를 참조하십시오.

루트 파티션은 파티션 이름, ID 또는 다른 방법으로 마운트해야 합니다. 파티션 UUID 또는 레이블로 마운트하는 것은 지원되지 않습니다.

자세한 내용은 multi-update-tools 패키지와 함께 제공되는 /usr/share/doc/packages/multi-update-tools/README를 참조하십시오.

스크립트는 /var/lib/YaST2/wagon/hooks/ 디렉토리에서 검색됩니다. 예상 스크립트 이름은 step_seq_prefix_name 형식입니다. 설명:

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

스크립트에서 종료 값 0을 반환해야 합니다. 0이 아닌 종료 값이 반환될 경우 Wagon에 오류 메시지가 표시되고 스크립트를 다시 시작할 수 있습니다. 이 오류 메시지를 무시하고 다른 스크립트를 계속하거나 현재 단계의 후크를 완전히 취소합니다.

후크 스크립트는 잠재적으로 여러 번 실행할 수 있습니다. Wagon 대화 상자에서 앞뒤로 이동할 경우 Wagon이 다시 시작하거나 마이그레이션 워크플로에서 일부 단계를 여러 번 실행할 수 있습니다. 따라서 스크립트가 이런 상황에 맞춰야 합니다. 처음부터 스크립트에서 작업을 수행해야 하는지 또는 작업을 이미 수행했는지 또는 간단한 임시 스탬프 파일을 작성할 수 있는지 아니면 올바르게 여러 번 실행할 수 있는지 확인할 수 있습니다.

이전 결과 또는 사용자가 선택한 값을 기반으로 하기 때문에 일부 후크는 선택사항입니다. 일부 후크는 여러 번 호출됩니다(예: 마이그레이션 전후에 등록이 호출됨). 실행 순서에 따라 지원되는 후크(단계 이름) 목록은 다음과 같습니다.

사용자가 마이그레이션을 중단할 경우 호출되는 특수한 중단 후크가 있습니다. 마이그레이션 워크플로의 어떤 단계에서나 이 후크를 호출할 수 있으므로 실행 순서를 보장할 수 없습니다. 스크립트에서 다른 후크의 결과를 사용할 경우 현재 상태를 확인해야 합니다.

Wagon이 다시 시작될 때마다 이 후크를 호출합니다.

후크 목록이 상당히 크지만, 대부분은 특별한 경우에만 사용됩니다. 일반적인 사용 사례에서는 기본 설정이 제공됩니다.

이전 버전의 Wagon에서는 두 가지 후크 스크립트, 즉 /usr/lib/YaST2/bin/wagon_hook_init 및 /usr/lib/YaST2/bin/wagon_hook_finish만 지원했습니다. 하나의 스크립트만 후크로 실행할 수 있고 후크를 직접 RPM 패키지에 배치할 수 없다는 것이 문제였습니다.

이전 버전과의 호환성을 위해 이전 후크 스크립트는 최신 버전의 Wagon에서 계속 지원되지만, 사용되지 않는 후크 대신 새로운 후크 before_init 및 before_exit를 사용해야 합니다.