목차로 이동
documentation.suse.com / 업그레이드 가이드
SUSE Linux Enterprise Server 15 SP2

업그레이드 가이드

이 책은 SUSE Linux Enterprise Server의 업그레이드 및 업데이트에 대해 안내합니다. 여기에는 설치 DVD, 네트워크 부팅 또는 실행 중인 시스템을 통한 업그레이드 등 다양한 접근법이 설명되어 있습니다.

게시일: 2023 년 12 월 11 일

Copyright © 2006– 2023 SUSE LLC and contributors. All rights reserved.

GNU 무료 설명서 라이선스, 버전 1.2 또는 (사용자 선택에 따라) 버전 1.3의 조항에 따라 본 문서를 복사, 배포 및/또는 수정하는 권한이 허가됩니다. 그리고 각 항목에는 본 저작권 통지 및 라이선스가 설명된 고정(Invariant) 섹션이 있습니다. 라이선스 버전 1.2의 복사본은 GNU 무료 설명서 라이선스 섹션에 포함되어 있습니다.

SUSE 상표에 대해서는 https://www.suse.com/company/legal/을 참조하십시오. 모든 다른 제3자의 상표는 해당 소유주의 자산입니다. 상표 기호(®, ™ 등)는 SUSE 및 해당 계열사의 상표를 나타냅니다. 별표(*)는 타사 상표를 나타냅니다.

본 설명서의 모든 정보는 최대한의 주의를 기울여 작성되었습니다. 그러나 이것이 문서의 정확성을 보장하지는 않습니다. SUSE LLC, 해당 계열사, 작성자 또는 번역자는 누구도 발생 가능한 오류 또는 오류로 인한 결과에 대해 책임지지 않습니다.

이 가이드 정보

SUSE Linux Enterprise Server를 업그레이드하는 데는 다양한 방법이 있습니다. 부팅 또는 설치 서버, 자동 설치 또는 이미지 배포의 모든 조합을 다루는 것은 불가능합니다. 이 설명서는 설치를 업그레이드할 적절한 방법을 선택하도록 도와줍니다.

Book “업그레이드 가이드”

여기서는 용어, SUSE 제품 라이프싸이클과 서비스 팩 릴리스, 권장 업그레이드 정책에 관한 배경 정보를 제공합니다.

1 사용 가능한 설명서

참고
참고: 온라인 문서 및 최신 업데이트

제품 문서는 https://documentation.suse.com/에서 확인할 수 있으며 여기서 최신 업데이트를 찾고 다양한 형식으로 된 문서를 찾아보거나 다운로드할 수도 있습니다. 최신 문서 업데이트는 일반적으로 문서의 영어 버전으로 제공됩니다.

이 제품에 대해 다음 문서를 사용할 수 있습니다.

Article “설치 빠른 시작

이 빠른 시작은 SUSE® Linux Enterprise Server 15 Sp2를 단계별로 설치하도록 안내합니다.

Book “배포 가이드

이 가이드는 단일 또는 다중 시스템을 설치하는 방법과 배포 인프라를 위해 제품 고유의 기능을 이용하는 방법을 보여 줍니다. 물리적 설치 미디어에서 로컬 설치, 표준 설치 이미지 최적화, 네트워크 설치 서버, 원격 제어를 사용한 대량 배포, 매우 세밀하게 사용자 지정된 자동화 설치 프로세스 및 초기 시스템 구성의 다양한 방법 중에서 선택할 수 있습니다.

Book “Administration Guide”

처음 설치된 시스템의 유지 관리, 모니터링 및 사용자 정의와 같은 시스템 관리 작업에 대해 설명합니다.

Book “Virtualization Guide”

일반적인 가상화 기술을 설명하고, 가상화에 대한 통합 인터페이스인 libvirt를 소개하고, 특정 Hypervisor에 대한 자세한 정보를 제공합니다.

Book “Storage Administration Guide”

SUSE Linux Enterprise Server에 대한 저장소 장치를 관리하는 방법에 대한 정보를 제공합니다.

Book “AutoYaST Guide”

AutoYaST는 설치 및 구성 데이터를 포함한 AutoYaST 프로파일을 사용하는 무인 대량 배포 SUSE Linux Enterprise Server 시스템을 위한 시스템입니다. 이 설명서에서 자동 설치, 준비, 설치 및 구성의 기본 단계를 안내합니다.

Book “Security and Hardening Guide”

로컬 보안 측면과 네트워크 보안 측면을 모두 망라하여 시스템 보안의 기본 개념을 소개합니다. AppArmor와 같은 제품 고유의 보안 소프트웨어 또는 보안 관련 이벤트에 대한 정보를 올바르게 수집하는 감사 시스템을 사용하는 방법을 보여줍니다.

Book “System Analysis and Tuning Guide”

문제 감지, 해결책 및 최적화에 대한 관리자 가이드 도구를 모니터링하여 시스템을 검사 및 최적화하는 방법과, 리소스를 효율적으로 관리하는 방법을 검색하십시오. 일반적인 문제와 해결책, 추가 도움말과 설명서 리소스에 대한 개요도 포함되어 있습니다.

Book “Repository Mirroring Tool Guide”

리포지토리와 등록 대상이 있는 SUSE Customer Center를 위한 프록시 시스템인 SMT(Subscription Management Tool: 구독 관리 도구)에 대한 관리자 안내서입니다. 로컬 SMT 서버를 설치 및 구성하고, 리포지토리를 미러링 및 관리하고, 클라이언트 시스템을 관리하고, SMT 사용을 위해 클라이언트를 구성하는 방법에 대해 알아보십시오.

Book “GNOME User Guide”

SUSE Linux Enterprise Server의 GNOME 데스크톱을 소개합니다. 데스크톱의 사용 및 구성을 안내하고 주요 작업 수행을 도와줍니다. 주로 GNOME을 기본 데스크톱으로 이용하려는 사용자를 위한 설명서입니다.

이 제품의 릴리스 노트는 https://www.suse.com/releasenotes/에서 제공됩니다.

2 피드백 제공

이 문서와 관련된 귀하의 피드백과 기여를 환영합니다! 다음과 같은 여러 채널을 사용할 수 있습니다.

서비스 요청 및 지원

제품에 사용 가능한 서비스 및 지원 옵션에 대해서는 https://www.suse.com/support/를 참조하십시오.

서비스 요청을 열려면, SUSE Customer Center에 가입해야 합니다. https://scc.suse.com/support/requests로 이동하여 로그인한 다음 새로 작성을 클릭합니다.

버그 보고서

문서와 관련된 문제는 https://bugzilla.suse.com/에 보고할 수 있습니다. 이 프로세스를 편리하게 수행하려면 이 문서의 HTML 버전에서 헤드라인 옆에 있는 문서 버그 보고를 사용하십시오. 이 기능을 사용하면 해당 제품 및 범주를 Bugzilla에서 사전에 선택하고 현재 선택 항목에 링크를 추가할 수 있습니다. 버그 보고서를 입력하여 즉시 시작할 수 있습니다. 이 작업을 위해서는 Bugzilla 계정이 필요합니다.

기여

이 문서에 기여하려면 이 문서의 HTML 버전에서 헤드라인 옆에 있는 소스 편집 링크를 사용하십시오. 그러면 GitHub의 소스 코드로 이동하며, 여기에서 풀 요청을 열 수 있습니다. 이 작업을 위해서는 GitHub 계정이 필요합니다.

이 문서에서 사용되는 문서 환경에 대한 자세한 내용은 리포지토리의 README를 참조하십시오.

메일

또는 문서와 관련된 피드백과 오류를 <>으로보내주십시오. 문서의 문서 제목, 제품 버전 및 게시 날짜를 포함해야 합니다. 해당 섹션 번호 및 제목을 기입(또는 URL을 포함)하고 문제에 대한 간결한 설명을 제공해 주십시오.

3 문서에서 사용된 규칙

본 문서에서는 다음과 같은 알림 및 인쇄 규칙이 사용됩니다.

  • /etc/passwd: 디렉토리 이름 및 파일 이름

  • PLACEHOLDER: PLACEHOLDER를 실제 값으로 교체

  • PATH: 환경 변수 PATH

  • ls, --help: 명령, 옵션 및 파라미터

  • user: 사용자 또는 그룹

  • 패키지 이름 : 패키지의 이름

  • Alt, Alt F1 : 누르는 키 또는 키 조합. 키는 키보드에서와 같이 대문자로 표시됩니다.

  • 파일, 파일 ›  다른 이름으로 저장 : 메뉴 항목, 버튼

  • AMD/Intel 이 단락은 AMD64/Intel-64 아키텍처에만 해당됩니다. 화살표는 텍스트 블록의 시작과 끝을 나타냅니다.

    IBM Z, POWER 이 단락은 IBM ZPOWER 아키텍처에만 해당됩니다. 화살표는 텍스트 블록의 시작과 끝을 나타냅니다.

  • 춤추는 펭귄(펭귄 장, ↑다른 설명서): 다른 설명서의 장을 참조하는 것입니다.

  • 루트 권한으로 실행해야 하는 명령입니다. 종종 해당 명령 앞에 sudo 명령을 붙여 권한이 없는 사용자로 실행할 수도 있습니다.

    root # command
    tux > sudo command
  • 권한이 없는 사용자가 실행할 수 있는 명령입니다.

    tux > command
  • 알림

    주의
    주의: 경고 알림

    계속하기 전에 숙지해야 할 필수 정보입니다. 보안 문제, 데이터 손실, 하드웨어 손상 또는 신체 상해 가능성에 대해 경고합니다.

    중요
    중요: 중요한 알림

    계속하기 전에 숙지해야 할 중요한 정보입니다.

    참고
    참고: 메모 알림

    소프트웨어 버전 차이 등의 추가 정보입니다.

    작은 정보
    작은 정보: 팁 알림

    가이드라인 또는 실무 조언과 같은 유용한 정보입니다.

4 제품 라이프사이클 및 지원

SUSE 제품은 최대 13년 동안 지원됩니다. 사용 중인 제품의 라이프사이클 날짜는 https://www.suse.com/lifecycle/에서 확인할 수 있습니다.

SUSE Linux Enterprise의 경우 다음과 같은 라이프사이클 및 릴리스사이클이 적용됩니다.

  • SUSE Linux Enterprise Server의 라이프사이클은 13년(일반 지원 10년, 확장 지원 3년)입니다.

  • SUSE Linux Enterprise Desktop의 라이프사이클은 10년(일반 지원 7년, 확장 지원 3년)입니다.

  • 주 릴리스는 4년마다 게시됩니다. 서비스 팩은 12-14개월마다 게시됩니다.

  • SUSE는 새 서비스 팩이 릴리스된 후 6개월 동안 이전 SUSE Linux Enterprise 서비스 팩을 지원합니다.

일부 제품의 경우, 장기 서비스 팩 지원(LTSS)이 제공됩니다. 지원 정책 및 옵션에 관한 정보는 https://www.suse.com/support/policy.htmlhttps://www.suse.com/support/programs/long-term-service-pack-support.html에서 확인할 수 있습니다.

모듈의 라이프사이클, 업데이트 정책 및 업데이트 시간표는 기본 제품과 다릅니다. 모듈에는 소프트웨어 패키지가 포함되며 완전히 지원되는 SUSE Linux Enterprise Server의 일부입니다. 자세한 내용은 Article “Modules and Extensions Quick Start”에서 확인할 수 있습니다.

4.1 SUSE Linux Enterprise Server 지원 정책

지원을 받으려면 SUSE에 적절하게 가입해야 합니다. 귀하에게 제공되는 특정 지원 서비스를 살펴보려면 https://www.suse.com/support/로 이동하여 제품을 선택하십시오.

지원 수준은 다음과 같이 정의됩니다.

L1

문제 결정, 즉 호환성 정보, 사용 지원, 진행 중인 유지보수, 정보 수집 및 사용 가능한 설명서를 활용한 기본적인 문제 해결을 제공하도록 설계된 기술 지원을 의미합니다.

L2

문제 격리, 즉 레벨 1에서 해결되지 않는 문제를 해결하거나 레벨 3을 준비하고 문제 영역을 격리하며 고객 문제를 재현하고 데이터를 분석하도록 설계된 기술 지원을 의미합니다.

L3

문제 해결, 즉 레벨 2 지원에서 식별된 제품 결함을 해결하기 위해 엔지니어링 작업을 통해 복잡한 문제를 해결하도록 설계된 기술 지원입니다.

SUSE Linux Enterprise Server는 계약 고객 및 파트너에게 모든 패키지에 L3 지원을 제공합니다. 단, 다음은 제외입니다.

  • 기술 미리 보기

  • 사운드, 그래픽, 글꼴 및 아트워크.

  • 추가적인 고객 계약이 필요한 패키지.

  • Workstation Extension 모듈의 일부로 제공되는 일부 패키지는 L2 지원만 제공합니다.

  • 이름이 -devel 로 끝나는 패키지(헤더 파일 및 유사한 개발자 리소스 포함)는 주 패키지와 함께 지원됩니다.

SUSE는 원본 패키지의 사용만 지원합니다. 즉, 변경되지 않고 재컴파일이 수행되지 않은 패키지만 지원합니다.

4.2 기술 미리 보기

기술 미리 보기는 향후 제공되는 혁신과 관련하여 SUSE가 간략하게 제공하는 패키지, 스택 또는 기능입니다. 미리 보기는 사용자 환경 내에서 새로운 기술을 테스트할 수 있도록 사용자 편의를 위해 포함됩니다. 피드백을 제공해 주셔서 감사합니다! 기술 미리 보기를 테스트하는 경우에는 SUSE 담당자에게 문의하여 귀하의 경험과 사용 사례에 대해 알려주십시오. 귀하의 의견은 향후 개발에 도움이 됩니다.

그러나 기술 미리 보기에는 다음과 같은 제한이 적용됩니다.

  • 기술 미리 보기는 아직 개발 중인 상태입니다. 그러므로 기능이 완전하지 않거나 불안정하거나 운영 사용에 적합하지 않을 수 있습니다.

  • 기술 미리 보기는 지원이 제공되지 않습니다.

  • 기술 미리 보기는 특정 하드웨어 아키텍처에서만 사용할 수 있습니다.

  • 기술 미리 보기의 세부 정보 및 기능은 변경될 수 있습니다. 그러므로 기술 미리 보기의 이후 릴리스로 업그레이드가 불가능해 새로 설치해야 할 수 있습니다.

  • 기술 미리 보기는 언제든지 삭제될 수 있습니다. 예를 들어, 미리 보기가 고객 또는 시장의 요구 사항을 충족하지 못하거나 엔터프라이즈 표준을 준수하지 않는다고 SUSE가 판단하는 경우가 이에 해당합니다. 이러한 경우 SUSE는 향후에 해당 기술의 지원 버전을 제공하지 않을 수 있습니다.

제품과 함께 제공되는 기술 미리 보기에 대한 개요는 https://www.suse.com/releasenotes/의 릴리스 노트를 참조하십시오.

1 경로 및 방법 업그레이드

SLE(SUSE® Linux Enterprise)를 사용하여 기존 시스템을 새 버전으로 업그레이드할 수 있습니다. 예를 들어 SLE 12 SP4를 최신 SLE 15 서비스 팩으로 전환합니다. 새로 설치할 필요가 없습니다. 홈 디렉토리, 데이터 디렉토리 및 시스템 구성과 같은 기존 데이터가 원래 상태로 보존됩니다. 로컬 CD나 DVD 드라이브 또는 중앙 네트워크 설치 원본에서 업데이트할 수 있습니다.

이 장에서는 DVD, 네트워크, 자동 프로세스 또는 SUSE Manager를 통해 SUSE Linux Enterprise 시스템을 수동으로 업그레이드하는 방법을 설명합니다.

1.1 SLES 15 SP2에 대해 지원되는 업그레이드 경로

마이그레이션을 수행하기 전에 3장 업그레이드 준비를 읽어 보십시오.

중요
중요: 아키텍처 간 업그레이드 지원 안 함

아키텍처 간 업그레이드(예: 32비트 버전의 SUSE Linux Enterprise Server에서 64비트 버전으로 또는 big endian에서 little endian으로 업그레이드)는 지원되지 않습니다.

특히 SLE 11 on POWER(big endian)에서 SLE 15 SP2 on POWER(최신: little endian!)로의 업그레이드는 지원되지 않습니다.

또한 SUSE Linux Enterprise 15 SP2은 64비트 전용이므로 32비트 SUSE Linux Enterprise 11 시스템에서 SUSE Linux Enterprise 15 SP2 이상 버전으로의 업그레이드는 지원되지 않습니다.

아키텍처 간 업그레이드가 필요한 경우 새로 설치해야 합니다.

참고
참고: 서비스 팩 건너뛰기

모든 서비스 팩을 연속해서 설치하는 것이 가장 편리한 업그레이드 경로입니다. SUSE Linux Enterprise 15 제품 라인(GA 및 이후 서비스 팩)의 경우, 업그레이드할 때 서비스 팩 하나를 건너뛰는 것이 지원됩니다. 예를 들어, SLE 15 GA에서 15 SP2로 또는 SLE 15 SP1에서 15 SP3로의 업그레이드가 지원됩니다.

참고
참고: 주 릴리스 업그레이드

SUSE Linux Enterprise 12에서 SUSE Linux Enterprise 15로 업그레이드하는 경우와 같이 새 주 릴리스로 업그레이드할 때는 새로 설치하는 것이 좋습니다.

지원 업그레이드 경로 개요
그림 1.1: 지원 업그레이드 경로 개요
버전별 지원 업그레이드 경로
SUSE Linux Enterprise Server 11 GA / SP1 / SP2 / SP3에서 업그레이드

SLES 11 SP3 또는 이전 서비스 팩으로부터 직접 업그레이드는 지원되지 않습니다. SLES 11 SP4 이상이 있어야만 SLES 15 SP2로 넘어갈 수 있습니다.

새로 설치할 수 없는 경우 먼저 설치된 SLES 11 서비스 팩을 SLES 11 SP4로 업그레이드하십시오. 이러한 업그레이드에 대한 설명은 SLES 11 SP4 배포 가이드에서 제공됩니다.

SUSE Linux Enterprise Server 11 SP4에서의 업그레이드

SLES 11 SP4에서 업그레이드하려면 오프라인 업그레이드를 사용해야 합니다. 자세한 내용은 1.2절 “온라인 및 오프라인 업그레이드” 항목을 참조하십시오.

SUSE Linux Enterprise Server 12 GA / SP1 / SP2에서 업그레이드

SLES 12 SP2 또는 이전 서비스 팩으로부터 직접 업그레이드는 지원되지 않습니다. SLES 12 SP3 이상이 있어야만 SLES 15 SP2로 넘어갈 수 있습니다.

새로 설치할 수 없는 경우 먼저 설치된 SLES 12 서비스 팩을 SLES 12 SP3로 업그레이드하십시오. 이러한 업그레이드에 대한 설명은 SLES 12 SP3 배포 가이드에서 제공됩니다.

SUSE Linux Enterprise Server 12 SP3 / SP4에서의 업그레이드

SLES 12 SP3 / SP4에서 업그레이드하려면 오프라인 업그레이드를 사용해야 합니다. 자세한 내용은 1.2절 “온라인 및 오프라인 업그레이드” 항목을 참조하십시오.

SUSE Linux Enterprise 퍼블릭 클라우드 게스트 업그레이드

퍼블릭 클라우드에서의 SLE 게스트 업그레이드 방법에 관한 지침은 SUSE 배포 마이그레이션 시스템 사용을 참조하십시오.

1.2 온라인 및 오프라인 업그레이드

SUSE는 다음과 같은 업그레이드 및 마이그레이션 방법을 지원합니다. 용어에 대한 자세한 내용은 2.1절 “용어”를 참조하십시오. 방법은 다음과 같습니다.

온라인

실행 중인 운영 체제에서 수행되는 업그레이드(시스템 구동 및 실행 상태). 예: Zypper 또는 YaST를 통한 온라인 업데이트, SUSE Customer Center 또는 리포지토리 미러링 도구(RMT)를 통한 연결, SUSE Manager를 통한 Salt 정책.

자세한 내용은 5장 온라인 업그레이드를 참조하십시오.

동일한 주 릴리스의 서비스 팩 간에 마이그레이션하는 경우 5.4절 “온라인 마이그레이션 도구(YaST)를 통한 업그레이드” 또는 5.5절 “Zypper로 업그레이드”를 따르는 것이 좋습니다.

오프라인

오프라인 업그레이드는 업그레이드할 운영 체제가 실행 중이 아님을 의미합니다(시스템 종료 상태). 대신, 대상 운영 체제의 설치 프로그램이 부팅(예: 설치 미디어에서, 네트워크를 통해 또는 로컬 부트 로더를 통해)되고 업그레이드를 수행합니다.

자세한 내용은 4장 오프라인 업그레이드를 참조하십시오.

중요
중요: SUSE Manager 클라이언트

SUSE Manager가 시스템을 관리하는 경우에는 SUSE Manager 설명서의 설명과 같이 업데이트합니다. 클라이언트 마이그레이션 절차는 https://documentation.suse.com/suma/에서 확인할 수 있는 SUSE Manager 업그레이드 가이드에 설명되어 있습니다.

2 라이프사이클 및 지원

이 장에서는 용어, SUSE 제품 라이프사이클 및 서비스 팩 릴리스, 권장 업그레이드 정책에 대한 배경 정보를 제공합니다.

2.1 용어

이 섹션에서는 여러 용어를 사용합니다. 정보를 이해하려면 아래 정의를 읽어보십시오.

백포팅

백포팅은 최신 소프트웨어 버전의 특정 변경 사항을 조정하여 이전 버전에 적용하는 작업입니다. 가장 일반적으로 사용되는 사례가 이전 소프트웨어 구성요소의 보안 문제를 수정하는 것입니다. 대부분은 개선 사항 또는 새로운 기능(덜 일반적임)을 제공하기 위한 유지보수 모델의 일부이기도 합니다.

델타 RPM

델타 RPM은 패키지의 정의된 두 가지 버전 간 이진 차이만으로 구성되므로, 다운로드 크기가 가장 작습니다. 설치하기 전에 전체 RPM 패키지가 로컬 시스템에서 다시 작성됩니다.

다운스트림

오픈 소스 환경에서 소프트웨어를 개발하는 방식을 의미합니다(업스트림과 비교). 다운스트림이라는 용어는 업스트림의 소스 코드를 다른 소프트웨어와 통합하여 최종 사용자가 사용하는 배포본을 빌드하는 개인이나 SUSE 같은 조직을 가리킵니다. 따라서 소프트웨어는 통합자를 통해 개발자로부터 최종 사용자에게로 전달됩니다.

확장, 추가 기능 제품

확장 및 타사 추가 기능 제품은 SUSE Linux Enterprise Server에 제품 가치에 상당하는 추가 기능을 제공합니다. 확장은 SUSE 및 SUSE 파트너를 통해 제공되며, 기본 제품인 SUSE Linux Enterprise Server 위에 등록되고 설치됩니다.

LTSS

LTSS는 Long Term Service Pack Support의 약어로, SUSE Linux Enterprise Server용 확장으로 사용할 수 있습니다.

주 릴리스, GA(General Availability: 공식 출시) 버전

SUSE Linux Enterprise 또는 소프트웨어 제품의 주 릴리스는 새로운 기능과 도구를 제공하고, 더 이상 사용되지 않는 이전 구성 요소를 중지하고, 이전 버전과 호환되지 않는 변경사항을 포함하는 새 버전입니다. 예를 들어, SUSE Linux Enterprise 12 또는 15가 주 릴리스입니다.

마이그레이션

해당 패치를 설치하기 위해 온라인 업데이트 도구 또는 설치 미디어를 사용하여 서비스 팩(SP)을 업데이트하는 것입니다. 이 경우 설치된 시스템의 모든 패키지가 최신 상태로 업데이트됩니다.

마이그레이션 대상

시스템을 마이그레이션할 수 있는 호환되는 제품의 세트로, 제품/확장의 버전과 리포지토리의 URL을 포함합니다. 마이그레이션 대상은 시간에 따라, 설치된 확장에 따라 변경될 수 있습니다. 예를 들어, SLE 15 SP1 및 SES6와 같이 여러 마이그레이션 대상을 선택할 수 있습니다.

모듈

모듈은 다른 라이프사이클을 사용하여 완전히 지원되는 SUSE Linux Enterprise Server의 일부입니다. 명시적으로 정의된 범위가 있고 온라인 채널을 통해서만 전달됩니다. 이러한 채널에 가입하려면 먼저 SUSE Customer Center, RMT(Repository Mirroring Tool: 리포지토리 미러링 도구) 또는 SUSE Manager에 등록해야 합니다.

패키지

패키지는 구성, 예제, 문서와 같은 선택적 구성요소를 포함하여 특정 프로그램에 대한 모든 파일이 포함된 rpm 형식의 압축된 파일입니다.

패치

패치는 하나 이상의 패키지로 구성되어 있으며, 델타 RPM을 사용하여 적용할 수 있습니다. 또한 아직 설치되지 않은 패키지에 종속성을 적용할 수 있습니다.

서비스 팩(SP)

설치 또는 배포가 용이하도록 여러 개의 패치를 하나의 형태로 결합합니다. 서비스 팩은 번호가 지정되며, 일반적으로 보안 수정, 업데이트, 업그레이드 또는 프로그램 기능 개선이 포함됩니다.

업스트림

오픈 소스 환경에서 소프트웨어를 개발하는 방식을 의미합니다(다운스트림과 비교). 업스트림이라는 용어는 소스 코드로 배포된 소프트웨어의 원래 프로젝트, 작성자 또는 유지보수 사용자를 가리킵니다. 피드백, 패치, 기능 개선사항 또는 기타 개선 항목은 최종 사용자 또는 참가자로부터 업스트림 개발자에게 전달됩니다. 업스트림 개발자가 요청을 통합 또는 거부할지 결정합니다.

프로젝트 구성원이 요청을 통합하기로 결정할 경우 최신 버전의 소프트웨어에 표시됩니다. 수락된 요청은 관련된 모든 당사자에게 이점을 제공합니다.

요청을 수락하지 않을 경우 다른 이유 때문일 수 있습니다. 프로젝트의 지침을 준수하지 않거나, 올바르지 않거나, 이미 통합되어 있거나, 프로젝트의 관심사나 로드맵에 포함되지 않는 상태일 수 있습니다. 업스트림 개발자는 자신의 패치를 업스트림 코드와 동기화해야 하기 때문에 요청을 수락하지 않을 수 없습니다. 이 방식은 일반적으로 사용되지 않지만 필요한 경우가 있습니다.

업데이트

일반적으로 보안 또는 버그 수정을 포함하고 있는 최신 보조 버전의 패키지를 설치합니다.

업그레이드

패키지 또는 배포의 최신 버전 설치를 통해 새 기능을 가져옵니다. 업그레이드 옵션 간의 구분은 1.2절 “온라인 및 오프라인 업그레이드”에서 확인할 수 있습니다.

2.2 제품 라이프사이클

SUSE 제품의 라이프사이클은 다음과 같습니다.

  • SUSE Linux Enterprise Server의 라이프사이클은 13년(일반 지원 10년, 확장 지원 3년)입니다.

  • SUSE Linux Enterprise Desktop의 라이프사이클은 10년(일반 지원 7년, 확장 지원 3년)입니다.

  • 주 릴리스는 4년마다 발표됩니다. 서비스 팩은 12-14개월마다 제공됩니다.

SUSE는 새 서비스 팩이 릴리스된 후 6개월 동안 이전 서비스 팩을 지원합니다. 언급한 몇 가지 내용을 그림 2.1. “주 릴리스 및 서비스 팩”에서 설명합니다.

주 릴리스 및 서비스 팩
그림 2.1: 주 릴리스 및 서비스 팩

업그레이드 계획을 설계, 검증 및 테스트할 추가 시간이 필요한 경우 Long Term Service Pack Support를 통해 추가 12개월~36개월(12개월 단위)로 지원을 확장할 수 있습니다. 이로 인해 서비스 팩에 대한 지원이 총 2년~5년으로 제공됩니다. 자세한 내용은 그림 2.2. “장기 서비스 팩 지원”을 참조하십시오.

장기 서비스 팩 지원
그림 2.2: 장기 서비스 팩 지원

자세한 내용은 https://www.suse.com/products/long-term-service-pack-support/를 참조하십시오.

라이프사이클, 릴리스 빈도 및 오버레이 지원 기간에 대한 자세한 내용은 https://www.suse.com/lifecycle을 참조하십시오.

2.3 모듈 종속성 및 라이프사이클

모듈 목록, 종속성 및 라이프사이클은 Article “Modules and Extensions Quick Start”을(를) 참조하십시오.

2.4 주기적 라이프사이클 보고서 생성

SUSE Linux Enterprise Server에서는 설치된 모든 제품의 지원 상태 변경 사항을 정기적으로 확인하고 변경된 경우 전자 메일을 통해 보고서를 송신할 수 있습니다. 보고서를 생성하려면 zypper-lifecycle-pluginzypper in zypper-lifecycle-plugin을 설치합니다.

시스템에서 systemctl을 사용하여 보고서 생성을 활성화합니다.

root # systemctl enable lifecycle-report

텍스트 편집기를 사용하여 /etc/sysconfig/lifecycle-report 파일에서 수신인, 보고서 전자 메일 제목 및 보고서 생성 기간을 구성할 수 있습니다. MAIL_TOMAIL_SUBJ 설정은 메일 수신인과 제목을 정의하고 DAYS는 보고서 생성 간격을 설정합니다.

보고서에는 지원 상태 변경이 미리 표시되는 것이 아니라 변경된 이후에 표시됩니다. 마지막 보고서 생성 이후에 변경된 사항은 최대 14일 이후에 알림을 받을 수 있습니다. DAYS 옵션을 설정할 때는 이 점을 고려해야 합니다. 다음 구성 항목을 필요에 맞게 변경합니다.

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

최근 보고서는 /var/lib/lifecycle/report 파일에서 확인할 수 있습니다. 이 파일에는 두 개 섹션이 포함되어 있습니다. 첫 번째 섹션은 사용된 제품의 지원 종료에 대해 알립니다. 두 번째 섹션은 패키지의 지원 종료 날짜 및 업데이트 가용성을 나열합니다.

2.5 지원 수준

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

표 2.1: 보안 업데이트 및 버그 수정
 

최신 서비스 팩(SP)에 대한 일반 지원

이전 SP에 대한 일반 지원(LTSS 사용)

LTSS를 통한 확장 지원

기능

1-5년

6-7년

8-10년

4-10년

10-13년

기술 서비스

패치 및 수정 액세스

문서 및 기술 자료 액세스

기존 스택 및 워크로드 지원

새 배포 지원

제한(파트너 및 고객 요청 기반)

제한(파트너 및 고객 요청 기반)

아니요

향상 요청

제한(파트너 및 고객 요청 기반)

제한(파트너 및 고객 요청 기반)

아니요

아니요

하드웨어 지원 및 최적화

제한(파트너 및 고객 요청 기반)

제한(파트너 및 고객 요청 기반)

아니요

아니요

SUSE SolidDriver 프로그램(이전의 PLDP)을 통한 드라이버 업데이트

제한(파트너 및 고객 요청 기반)

제한(파트너 및 고객 요청 기반)

아니요

최신 SP의 수정 백포트

제한(파트너 및 고객 요청 기반)

해당 없음

해당 없음

중요 보안 업데이트

결함 해결

제한(보안 수준 1 및 2 결함에만 해당)

제한(보안 수준 1 및 2 결함에만 해당)

제한(보안 수준 1 및 2 결함에만 해당)

2.6 SUSEConnect를 통한 시스템 등록 및 등록 해제

등록할 때 시스템은 SUSE Customer Center(https://scc.suse.com/ 참조) 또는 SMT와 같은 로컬 등록 프록시에서 리포지토리를 수신합니다. 리포지토리 이름은 고객 센터의 특정 URI로 매핑됩니다. 시스템에서 사용 가능한 모든 리포지토리를 나열하려면 다음과 같이 zypper를 사용하십시오.

root # zypper repos -u

그러면 시스템에서 사용 가능한 모든 리포지토리 목록이 제공됩니다. 리포지토리 별명, 이름, 사용 가능 여부에 따라 각 채널이 나열되고 새로 고쳐집니다. -u 옵션을 사용하면 채널이 시작된 URI도 표시됩니다.

시스템을 등록하려면 SUSEConnect를 실행합니다. 예를 들면 다음과 같습니다.

root # SUSEConnect -r REGCODE

시스템을 해제할 때도 SUSEConnect를 사용할 수 있습니다.

root # SUSEConnect --de-register

로컬로 설치된 제품과 제품의 상태를 확인하려면 다음 명령을 사용하십시오.

root # SUSEConnect -s

2.7 SLE 버전 식별

SLE 설치 버전을 식별해야 하는 경우 /etc/os-release 파일의 컨텐트를 확인하십시오.

zypper를 사용하여 시스템이 XML 출력을 읽을 수 있습니다.

tux > zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

3 업그레이드 준비

업그레이드 절차를 시작하기 전에 시스템을 올바르게 준비해야 합니다. 무엇보다도 데이터를 백업하고 릴리스 정보를 확인하는 것이 중요합니다.

3.1 현재 시스템이 최신인지 확인

시스템 업그레이드는 최신 패치 수준에서만 지원됩니다. 최신 시스템 업데이트가 zypper 패치를 실행하거나 YaST 모듈 온라인 업데이트를 시작하여 설치되는지 확인하십시오.

3.2 릴리스 정보 읽기

릴리스 정보에서 이전 릴리스의 SUSE Linux Enterprise Server 이후에 변경된 내용에 대한 추가 정보를 확인할 수 있습니다. 릴리스 정보에서 다음을 확인하십시오.

  • 하드웨어에 대해 특별히 고려해야 할 사항

  • 사용된 소프트웨어 패키지가 크게 변경되었는지 여부

  • 설치할 때 특별히 주의해야 할 사항

또한 릴리스 정보에서는 설명서에 즉시 제공할 수 없는 정보도 제공하며, 알려진 문제점에 대한 정보도 포함합니다.

하나 이상의 서비스 팩을 건너뛰는 경우 건너뛴 서비스 팩의 릴리스 정보도 확인하십시오. 일반적으로 릴리스 정보에는 연속되는 두 릴리스 간의 변경 사항만 포함됩니다. 현재 릴리스 정보만 확인하는 경우 중요한 변경 사항을 놓칠 수 있습니다.

https://www.suse.com/releasenotes/에서 최신 릴리스 노트를 온라인으로 찾으십시오.

또는 docu 디렉토리의 설치 DVD에서 릴리스 노트를 찾으십시오.

3.3 백업

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

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

3.4 설치된 패키지 및 리포지토리 나열

새로운 주 SLE 릴리스를 설치하거나 이전 버전으로 되돌리는 경우와 같이 설치된 패키지 목록을 저장하면 유용한 경우가 많습니다.

설치된 패키지나 사용된 리포지토리 중 일부는 SUSE Linux Enterprise의 최신 릴리스에서 제공되지 않을 수 있습니다. 이름이 바뀌거나 대체된 경우도 있습니다. 또한 레거시 용도로 계속 제공되는 패키지가 있는 반면 기본적으로 사용되는 패키지도 있을 수 있습니다. 따라서 파일을 수동으로 편집해야 하는 경우가 있습니다. 그럴 경우 텍스트 편집기를 사용하면 됩니다.

사용된 모든 리포지토리 목록을 포함하는 repositories.bak.repo라는 이름의 파일을 만듭니다.

root # zypper lr -e repositories.bak

설치된 모든 패키지 목록을 포함하는 installed-software.bak 파일도 만듭니다.

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

두 파일을 모두 백업합니다. 리포지토리 및 설치된 패키지는 다음 명령으로 복원할 수 있습니다.

root # zypper ar repositories.bak.repo
root # zypper install $(cat installed-software.bak)
참고
참고: 새로운 주 릴리스로의 업데이트에 따른 패키지 수 증가

새로운 주 버전으로 업그레이드된 시스템(SLE X+1)은 초기 시스템(SLE X)보다 더 많은 패키지를 포함할 수 있습니다. 또한 동일한 패턴 선택 항목이 있는 SLE X+1의 새로운 설치보다 더 많은 패키지를 포함합니다. 그 이유는 다음과 같습니다.

  • 패키지가 분할되어 더 세분화된 패키지 선택이 허용됩니다. 예를 들어 SLE 11의 37개 texlive 패키지는 SLE 15에서 3000개 이상의 패키지로 분할되었습니다.

  • 패키지가 분할되는 경우, 새로운 모든 패키지가 업그레이드된 사례에 설치되어 이전 버전과 동일한 기능을 유지합니다. 그러나 SLE X+1의 새로운 설치에 대한 새 기본값은 모든 패키지를 설치하지 않을 수 있습니다.

  • SLE X의 레거시 패키지는 호환성으로 인해 유지될 수 있습니다.

  • 패키지 종속성 및 패턴 범위는 변경되었을 수 있습니다.

3.5 SUSE Linux Enterprise Server 11 SP4에서의 업그레이드

SUSE Linux Enterprise Server 11 SP4에서 MySQL, PostgreSQL 또는 Java MD5 기반 인증서를 사용 중이라면 다음 섹션에 설명된 대로 시스템을 준비합니다.

3.5.1 MySQL 데이터베이스 마이그레이트

SUSE Linux Enterprise 12부터 SUSE는 MySQL에서 MariaDB로 전환했습니다. 업그레이드를 시작하기 전에 데이터베이스를 백업하는 것이 좋습니다.

데이터베이스를 마이그레이션하려면 다음을 수행하십시오.

  1. SUSE Linux Enterprise 11 컴퓨터에 로그인합니다.

  2. 덤프 파일을 생성합니다.

    root # mysqldump -u root -p --all-databases > mysql_backup.sql

    기본적으로 mysqldumpINFORMATION_SCHEMA 또는 performance_schema 데이터베이스를 덤프하지 않습니다. 자세한 내용은 https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html을 참조하십시오.

  3. 나중에 확인하기 위해(설치는 아님) 덤프 파일, 구성 파일 /etc/my.cnf/etc/mysql/ 디렉토리를 안전한 곳에 저장합니다.

  4. 업그레이드를 수행합니다. 업그레이드 후에도 이전 구성 파일 /etc/my.cnf는 그대로 유지됩니다. 새 구성은 /etc/my.cnf.rpmnew 파일에 있습니다.

  5. MariaDB 데이터베이스를 필요에 따라 구성합니다. 이전 구성 파일 및 디렉토리는 사용하지 마십시오. 하지만 확인용으로 사용하거나 변경하여 사용할 수는 있습니다.

  6. 다음과 같이 MariaDB 서버를 시작해야 합니다.

    root # systemctl start mysql

    부팅할 때마다 MariaDB 서버를 시작하려면 다음과 같이 서비스를 활성화합니다.

    root # systemctl enable mysql
  7. 데이터베이스에 연결하여 MariaDB가 올바로 실행 중인지 확인합니다.

    root # mysql -u root -p

3.5.2 PostgreSQL 데이터베이스 마이그레이트

PostgreSQL 데이터베이스의 최신 버전은 SUSE Linux Enterprise Server 15 SP2과 함께 제공됩니다. 데이터베이스의 필수 마이그레이션 작업 때문에 자동 업그레이드 프로세스는 없습니다. 이처럼 한 버전에서 다른 버전으로 수동으로 전환해야 합니다.

기본 덤프 및 다시 로드의 대체 방법인 pg_upgrade 명령으로 마이그레이션 프로세스를 수행합니다. 덤프 및 다시 로드 방법에 비해 pg_upgrade를 사용하면 마이그레이션에 시간이 덜 듭니다.

각 PostgreSQL 버전의 프로그램 파일은 버전별로 다른 디렉토리에 저장됩니다. 예를 들어, 버전 9.6은 /usr/lib/postgresql96/, 버전 10은 /usr/lib/postgresql10/에 저장됩니다. PostgreSQL의 버전 관리 정책은 주요 버전 9.6과 10 사이에서 변경되었습니다. 자세한 내용은 https://www.postgresql.org/support/versioning/를 참조하십시오.

중요
중요: SLE 11에서 업그레이드

SLE 11에서 업그레이드할 때 postgresql94는 삭제되며 데이터베이스를 더 높은 버전의 PostgreSQL로 마이그레이션하는 데 사용할 수 없습니다. 따라서 이 경우 시스템을 업그레이드하기 전에 PostgreSQL 데이터베이스를 마이그레이션해야 합니다.

아래 절차는 버전 9.6에서 10으로 데이터베이스를 마이그레이션하는 방법에 대한 설명입니다. 시작 또는 대상으로 다른 버전을 사용할 때 버전 번호를 그에 맞게 교체하십시오.

데이터베이스를 마이그레이션하려면 다음을 수행하십시오.

  1. 다음 사전 조건이 충족되었는지 확인합니다.

    • 아직 하지 않은 경우 유지보수 업데이트를 통해 이전 PostgreSQL 버전의 패키지를 최신 릴리스로 업그레이드합니다.

    • 기존 데이터베이스의 백업을 만듭니다.

    • 새 PostgreSQL 주 버전의 패키지를 설치합니다. SLE15 SP2의 경우 postgresql10-server 및 이 패키지가 종속된 패키지를 모두 설치합니다.

    • 패키지 설치 postgresql10-contrib 패키지(pg_upgrade 명령 포함)를 설치합니다.

    • PostgreSQL 데이터 영역(기본적으로 /var/lib/pgsql/data)이 충분한지 확인하십시오. 공간이 부족한 경우 각 데이터베이스에서 다음 SQL 명령으로 크기를 줄여 보십시오(아주 오래 걸릴 수 있음).

      VACUUM FULL
  2. 다음 중 하나를 사용하여 PostgreSQL 서버를 중단합니다.

    root # /usr/sbin/rcpostgresql stop

    또는

    root # systemctl stop postgresql.service

    (업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)

  3. 이전 데이터 디렉토리 이름을 바꿉니다.

    root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old
  4. 새 데이터베이스 인스턴스를 initdb를 사용하여 수동으로 초기화하거나 PostgreSQL을 시작했다가 정지하여 자동으로 초기화합니다.

    root # /usr/sbin/rcpostgresql start
    root # /usr/sbin/rcpostgresql stop

    또는

    root # systemctl start postgresql.service
    root # systemctl stop postgresql.service

    (업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)

  5. 이전 버전에서 구성 파일을 변경한 경우, 해당 변경 사항을 새로운 구성 파일로 전송하십시오. postgresql.auto.conf, postgresql.conf, pg_hba.confpg_ident.conf 파일에 영향을 미칠 수 있습니다. 이러한 파일의 이전 버전은 /var/lib/pgsql/data.old/에 있으며, 새 버전은 /var/lib/pgsql/data에 있습니다.

    새 옵션, 새 기본값 및 변경된 주석을 덮어쓸 수 있으므로 이전 구성 파일을 복사하지 않는 것이 좋습니다.

  6. 마이그레이션 프로세스를 사용자 postgres로 시작합니다.

    root # su - postgres
    postgres > pg_upgrade \
      --old-datadir "/var/lib/pgsql/data.old" \
      --new-datadir "/var/lib/pgsql/data" \
      --old-bindir "/usr/lib/postgresql96/bin/" \
      --new-bindir "/usr/lib/postgresql10/bin/"
  7. 다음에서 새 데이터베이스 인스턴스를 시작합니다.

    root # /usr/sbin/rcpostgresql start

    또는

    root # systemctl start postgresql.service

    (업그레이드 시작 버전으로 사용하는 SLE 버전에 따라 다름)

  8. 마이그레이션되었는지 확인합니다. 테스트 범위는 사용 사례에 따라 다르며, 이 단계를 자동화할 일반 도구가 없습니다.

  9. 이전 PostgreSQL 패키지와 이전 데이터 디렉토리를 제거합니다.

    root # zypper search -s postgresql96 | xargs zypper rm -u
    root # rm -rf /var/lib/pgsql/data.old

3.5.3 Java 응용 프로그램용 MD5 이외의 서버 인증서 생성

SP1에서 SP2로 업데이트하는 절차 중에 보안 수정의 일부로 MD5 기반 인증서가 비활성화 되었습니다. MD5로 작성한 인증서가 있는 경우 다음 단계에 따라 인증서를 다시 작성하십시오.

  1. 터미널 창을 열고 root로 로그인하십시오.

  2. 개인 키를 생성합니다.

    root # openssl genrsa -out server.key 1024

    보다 강력한 키를 원하는 경우 10244096과 같이 더 높은 숫자로 바꿉니다.

  3. 인증서 서명 요청 (CSR)을 생성합니다.

    root # openssl req -new -key server.key -out server.csr
  4. 인증서에 자체 서명합니다.

    root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
  5. PEM 파일을 생성합니다.

    root # cat server.key server.crt > server.pem
  6. server.crt, server.csr, server.key, 및 server.pem 파일을 키가 있는 각각의 디렉토리에 배치합니다. 예를 들어 Tomcat의 경우, 해당하는 디렉토리는 /etc/tomcat/ssl/입니다.

3.6 가상 머신 게스트 종료

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

3.7 SMT 클라이언트 설정 조정

업그레이드하려는 시스템이 SMT 서버에 클라이언트로 등록된 경우 다음을 수행하십시오.

호스트의 clientSetup4SMT.sh 스크립트 버전이 최신인지 확인합니다. 이전 버전 SMT의 clientSetup4SMT.sh는 SMT 12 클라이언트를 관리할 수 없습니다. 정기적으로 SMT 서버에 소프트웨어 패치를 적용하는 경우 언제든지 <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh에서 최신 버전의 clientSetup4SMT.sh를 찾을 수 있습니다.

시스템을 SUSE Linux Enterprise Server의 최신 버전으로 업그레이드하지 못한 경우 절차 3.1에 설명된 대로 SMT 서버에서 시스템을 등록 취소합니다. 이후에 업그레이드 프로세스를 다시 시작하십시오.

절차 3.1: SMT 서버에서 SUSE Linux Enterprise Client 등록 취소
  1. 클라이언트 시스템에 로그인합니다.

  2. 다음 단계는 클라이언트의 현재 운영 체제에 따라 다릅니다.

    • SUSE Linux Enterprise 11인 경우 다음 명령을 실행합니다.

      tux > sudo suse_register -E
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
      tux > sudo rm -f /var/cache/SuseRegister/*
      tux > sudo rm -f /etc/suseRegister*
      tux > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
      tux > sudo rm -f /etc/zmd/deviceid
      tux > sudo rm -f /etc/zmd/secret
    • SUSE Linux Enterprise 12인 경우 다음 명령을 실행합니다.

      tux > sudo SUSEConnect --de-register
      tux > sudo SUSEConnect --cleanup
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
  3. SMT 서버에 로그인합니다.

  4. 모든 클라이언트 등록을 나열하여 클라이언트가 등록 취소되었는지 확인합니다.

    tux > sudo smt-list-registrations
  5. 클라이언트의 호스트 이름이 이 명령의 출력에 여전히 나열되면 첫 번째 열에서 클라이언트의 고유한 ID를 가져옵니다. (클라이언트에 ID가 여러 개 나열될 수 있습니다.)

  6. 이 클라이언트에 대한 등록을 삭제합니다.

    tux > sudo smt-delete-registration -g UNIQUE_ID
  7. 클라이언트에 ID가 여러 개 나열되는 경우 고유한 ID에 대해 각각 위의 단계를 반복하십시오.

  8. 다음을 다시 실행하여 이제 클라이언트가 등록 취소되었는지 확인합니다.

    tux > sudo smt-list-registrations

3.8 디스크 공간

소프트웨어는 버전이 바뀌면서 커지는 경향이 있습니다. 따라서 업데이트하기 전에 사용 가능한 파티션 공간을 살펴보십시오. 디스크 공간 부족이 의심되면 예를 들어 파티션 크기를 조정하는 방법으로 가용 공간을 늘리기 전에 먼저 데이터를 백업하십시오. 각 파티션의 크기에 대한 일반적인 규칙은 없습니다. 공간 요구사항은 특정 파티셔닝 프로파일과 선택한 소프트웨어에 따라 달라집니다.

참고
참고: YaST에서 충분한 공간 자동 확인

업데이트 절차 중 YaST가 사용 가능한 여유 디스크 공간을 검사하고 설치 용량이 여유 공간보다 클 경우 사용자에게 경고를 표시합니다. 이 경우 업데이트를 수행하면 사용할 수 없는 시스템이라는 오류가 발생할 수 있습니다. 상황을 정확히 알고 있는 경우에만(사전 테스트를 수행하여) 경고를 무시하고 업데이트를 진행할 수 있습니다.

3.8.1 비 Btrfs 파일 시스템에서 디스크 공간 확인

df 명령을 사용하여 가용 디스크 공간을 나열합니다. 예를 들어 예 3.1. “df -h로 나열”에서 루트 파티션은 /dev/sda3(/로 탑재됨)입니다.

예제 3.1: df -h로 나열
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

3.8.2 Btrfs 루트 파일 시스템에서 디스크 공간 확인

원시 데이터가 할당되는 공간뿐만 아니라 Btrfs 파일 시스템도 메타 데이터를 위해 공간을 할당 및 사용하므로 Btrfs 파일 시스템에서 df의 출력이 잘못될 수 있습니다.

따라서 사용 가능한 공간이 충분한 것 같은 경우에도 Btrfs 파일 시스템은 공간이 부족하다고 보고할 수 있습니다. 이러한 경우에는 메타 데이터에 할당된 모든 공간이 사용됩니다. Btrfs 파일 시스템에서 사용된 공간 및 사용 가능 공간의 확인 방법에 관한 자세한 내용은 Book “Storage Administration Guide”, Chapter 1 “Overview of File Systems in Linux”, Section 1.2.2.3 “Checking for Free Space”를 참조하십시오.자세한 내용은 man 8 btrfs-filesystemhttps://btrfs.wiki.kernel.org/index.php/FAQ를 참조하십시오.

시스템에서 Btrfs를 루트 파일 시스템으로 사용하는 경우 사용 가능한 공간이 충분한지 확인해야 합니다. 설치된 모든 파티션에서 사용 가능 공간을 확인합니다. 최악의 경우 업그레이드에 새 스냅샷용 현재 루트 파일 시스템만큼의 디스크 공간이 필요합니다(/.snapshot이 없는 경우).

다음은 검증된 권장 사항입니다.

  • Btrfs를 비롯한 모든 파일 시스템에서 사용 가능한 디스크 공간이 충분해야 큰 RPM을 다운로드하고 설치할 수 있습니다. 이전 RPM의 공간은 새 RPM을 설치해야만 비워집니다.

  • 스냅샷이 포함된 Btrfs의 경우 현재 설치에 소요되는 공간만큼의 사용 가능한 공간이 적어도 필요합니다. 사용 가능한 공간이 현재 설치보다 두 배 많은 것이 좋습니다.

    사용 가능한 공간이 충분하지 않으면 스냅퍼를 사용하여 이전 스냅샷을 삭제해 볼 수 있습니다.

    root # snapper list
    root # snapper delete NUMBER

    하지만 경우에 따라서는 도움이 되지 않을 수도 있습니다. 마이그레이션 전에 대부분의 스냅샷은 적은 공간만 차지합니다.

3.9 SMT(구독 관리 도구) 서버 업그레이드

SMT를 실행하는 서버에는 특수한 업그레이드 절차가 필요합니다. 리포지토리 관리 도구 가이드에서 Book “Repository Mirroring Tool Guide”, Chapter 2 “Migrate from SMT to RMT” 항목을 참조하십시오.

3.10 커널 다중 버전 지원을 일시적으로 비활성화

SUSE Linux Enterprise Server/etc/zypp/zypp.conf에서 해당 설정을 활성화하여 다중 커널 버전 설치를 지원합니다. 서비스 팩으로 업그레이드할 경우 이 기능에 대한 지원을 일시적으로 비활성화해야 합니다. 업그레이드가 성공적으로 끝나면 다중 버전 지원을 다시 활성화할 수 있습니다. 다중 버전 지원을 비활성화하려면 /etc/zypp/zypp.conf에 해당 줄에 주석을 추가하십시오. 결과는 다음과 같습니다.

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

업데이트 성공 후 이 기능을 다시 활성화하려면 주석 기호를 제거하십시오. 다중 버전 지원에 관한 자세한 내용은 Book “배포 가이드”, Chapter 21 “여러 커널 버전 설치”, Section 21.1 “다중 버전 지원 활성화 및 구성” 항목을 참조하십시오.

3.11 IBM Z에서 업그레이드

IBM Z에서 SUSE Linux Enterprise 설치를 업그레이드하려면 parmfile 등을 통한 Upgrade=1 커널 파라미터가 필요합니다. 5.4절 “Parmfile - 시스템 구성 자동화” 참조.

3.12 IBM POWER: X 서버 시작

SLES 12 for IBM POWER에서는 디스플레이 관리자가 기본적으로 로컬 X 서버를 시작하지 않도록 구성됩니다. SLES 12 SP1부터는 이 설정이 바뀌어 디스플레이 관리자가 X 서버와 함께 시작됩니다.

업그레이드 중 문제를 방지하려면 SUSE Linux Enterprise Server 설정을 자동으로 변경하지 않아야 합니다. 업그레이드 후 디스플레이 관리자가 X 서버를 시작하도록 하려면 /etc/sysconfig/displaymanager에서 DISPLAYMANAGER_STARTS_XSERVER의 설정을 다음과 같이 변경하십시오.

DISPLAYMANAGER_STARTS_XSERVER="yes"

4 오프라인 업그레이드

이 장에서는 매체에서 부팅되는 YaST를 사용하여 기존 SUSE Linux Enterprise 설치를 업그레이드하는 방법을 설명합니다. 예를 들어 DVD에서, 네트워크를 통해 또는 시스템이 있는 하드 디스크에서 YaST 설치 프로그램을 시작할 수 있습니다.

4.1 개념 개요

시스템을 업그레이드하기 전에 먼저 3장 업그레이드 준비를 읽으십시오.

시스템을 업그레이드하려면 새로 설치할 때처럼 설치 원본에서 부팅합니다. 그러나 부팅 화면이 나타나면 설치 대신 업그레이드를 선택해야 합니다. 다음에서 업그레이드를 시작할 수 있습니다.

4.2 설치 미디어에서 업그레이드 시작

아래 절차에서는 DVD에서 부팅하는 방법을 설명하지만 USB 대용량 저장 장치의 ISO 이미지와 같은 다른 로컬 설치 미디어를 사용할 수도 있습니다. 시스템 아키텍처와 시스템에 기존 BIOS 또는 UEFI 중 무엇이 있는지에 따라 미디어와 부팅 방법을 선택합니다.

절차 4.1: SUSE Linux Enterprise Server 15 SP2으로 수동 업그레이드
  1. 부팅 매체를 선택하고 준비합니다(Book “배포 가이드 참조).

  2. SUSE Linux Enterprise Server 15 SP2 통합 설치 프로그램 DVD를 삽입하고 시스템을 부팅합니다. 시작 화면이 표시된 다음 부팅 화면이 표시됩니다.

  3. 선택 사항: 설치 프로그램이 네트워크 소스가 아닌 DVD에서 패키지만 강제로 설치하도록 하려면 부팅 옵션 media_upgrade=1을 추가하십시오.

  4. [부팅] 메뉴에서 업그레이드를 선택하여 시스템을 시작합니다.

  5. 4.4절 “SUSE Linux Enterprise 업그레이드”에 설명된 대로 업그레이드 프로세스를 계속합니다.

4.3 네트워크 원본에서 업그레이드 시작

네트워크 설치 소스에서 업그레이드를 시작하려면 다음 요구사항을 충족해야 합니다.

네트워크 설치 원본에서 업그레이드에 대한 요구사항
네트워크 설치 원본

Book “배포 가이드”, Chapter 16 “네트워크 설치 소스 설정”에 따라 설정된 네트워크 설치 원본이 설정됩니다.

네트워크 연결 및 네트워크 서비스

설치 서버와 대상 시스템 모두에서 네트워크 연결이 작동 중이어야 합니다. 필요한 네트워크 서비스는 다음과 같습니다.

  • 도메인 네임 서비스

  • DHCP(PXE를 통한 부팅에만 필요, IP는 설정 중 수동으로 설정할 수 있음)

  • OpenSLP(선택 사항)

부팅 미디어

부팅 가능한 SUSE Linux Enterprise DVD, ISO 이미지 또는 작동하는 PXE 설정. PXE를 통한 부팅에 대한 자세한 내용은 Book “배포 가이드”, Chapter 17 “네트워크 부팅 환경 준비”, Section 17.4 “PXE 부팅을 위한 대상 시스템 준비” 항목을 참조하십시오. 원격 서버에서 업그레이드 시작에 대한 자세한 내용은 Book “배포 가이드”, Chapter 11 “원격 설치” 항목을 참조하십시오.

4.3.1 네트워크 설치 원본을 통해 수동 업그레이드 - DVD에서 부팅

이 절차에서는 DVD에서 부팅하는 방법을 예를 들어 설명하지만 USB 대용량 저장 장치의 ISO 이미지와 같은 다른 로컬 설치 미디어를 사용해도 됩니다. 부팅 방법을 선택하고 미디어에서 시스템을 시작하는 방법은 시스템 아키텍처와 시스템에서 기존 BIOS 또는 UEFI를 사용하는지 여부에 따라 다릅니다. 자세한 내용은 아래 링크를 참조하십시오.

  1. SUSE Linux Enterprise Server 15 SP2 통합 설치 프로그램 DVD를 삽입하고 시스템을 부팅합니다. 시작 화면이 표시된 다음 부팅 화면이 표시됩니다.

  2. 사용할 네트워크 설치 원본 유형을 선택합니다(FTP, HTTP, NFS, SMB 또는 SLP). 일반적으로 F4 키를 눌러 선택하지만 시스템에 기존 BIOS 대신 UEFI가 포함된 경우 부팅 파라미터를 수동으로 조정해야 합니다. 자세한 내용은 Book “배포 가이드”, Chapter 7 “부팅 파라미터”Book “배포 가이드”, Chapter 8 “설치 단계” 항목을 참조하십시오.

  3. 4.4절 “SUSE Linux Enterprise 업그레이드”에 설명된 대로 업그레이드 프로세스를 계속합니다.

4.3.2 네트워크 설치 원본을 통해 수동 업그레이드 - PXE를 통해 부팅

PXE 부팅을 사용하여 네트워크 설치 원본에서 업그레이드하려면 다음과 같이 하십시오.

  1. DHCP 서버의 설정을 조정하여 PXE를 통한 부팅에 필요한 주소 정보를 제공합니다. 자세한 내용은 Book “배포 가이드”, Chapter 17 “네트워크 부팅 환경 준비”, Section 17.1.1 “동적 주소 할당”을 참조하십시오.

  2. PXE를 통한 부팅에 필요한 부팅 이미지를 저장하도록 TFTP 서버를 설정합니다. 이에 대해 SUSE Linux Enterprise Server 15 SP2 설치 프로그램 DVD를 사용하거나 Book “배포 가이드”, Chapter 17 “네트워크 부팅 환경 준비”, Section 17.2 “TFTP 서버 설정”의 지침을 따르십시오.

  3. 대상 시스템에서 PXE 부팅 및 Wake-on-LAN을 준비합니다.

  4. 대상 시스템의 부팅을 시작하고 VNC를 사용하여 이 시스템에서 실행 중인 설치 루틴에 원격으로 연결합니다. 자세한 내용은 Book “배포 가이드”, Chapter 11 “원격 설치”, Section 11.3 “VNC를 통한 설치 모니터링”을 참조하십시오.

  5. 4.4절 “SUSE Linux Enterprise 업그레이드”에 설명된 대로 업그레이드 프로세스를 계속합니다.

4.4 SUSE Linux Enterprise 업그레이드

시스템을 업그레이드하기 전에 먼저 3장 업그레이드 준비를 읽어 보십시오. 자동 마이그레이션을 수행하려면 다음 단계를 수행하십시오.

참고
참고: SUSE Customer Center 및 인터넷 연결

업그레이드할 시스템이 SUSE Customer Center에 등록되어 있는 경우에는 다음 프로시저 도중 인터넷에 연결되어 있는지 확인하십시오.

  1. 설치 미디어 또는 네트워크를 통해 부팅한 후 부팅 화면에서 업그레이드 항목을 선택합니다.

    주의
    주의: 잘못 선택하면 데이터가 손실될 수 있음

    이 시점에 업그레이드를 선택했는지 확인합니다. 실수로 설치를 선택한 경우에는 데이터 파티션이 신규 설치로 덮어쓰기됩니다.

    설치 시스템이 시작됩니다.

  2. 시작 화면에서 언어키보드를 선택합니다. 다음을 눌러 계속합니다.

    파티션에 이미 설치된 SUSE Linux Enterprise 시스템이 있는지 확인합니다.

  3. 업그레이드를 위한 선택 화면에서 업그레이드할 파티션을 선택하고 다음을 클릭합니다.

  4. YaST는 선택한 파티션을 탑재하고 업그레이드한 제품의 사용권 계약을 표시합니다. 계속하려면 라이선스를 승인합니다.

  5. 이전에 사용된 리포지토리 화면에서 리포지토리의 상태를 조정합니다. 기본적으로 모든 리포지토리가 제거되어 있습니다. 사용자 지정 리포지토리를 추가하지 않은 경우에는 설정을 변경하지 마십시오. 업그레이드용 패키지는 DVD에서 설치되며 선택 사항으로 다음 단계에서 기본 온라인 리포지토리를 활성화할 수 있습니다.

    사용자 지정 리포지토리가 있는 경우에는 다음의 두 가지 중에 선택할 수 있습니다.

    • 리포지토리 상태를 제거됨으로 유지합니다. 이 리포지토리에서 설치된 소프트웨어는 업그레이드 중에 제거됩니다. 새 릴리스와 일치하는 리포지토리 버전이 없는 경우 이 방법을 사용하십시오.

    • 새 릴리스와 일치하는 경우에는 리포지토리를 업데이트 및 활성화합니다. 목록에서 리포지토리를 클릭하여 URL을 변경한 후 변경을 클릭합니다. 활성화로 설정될 때까지 상태 토글을 확인하여 리포지토리를 활성화합니다.

    시스템이 불안정하거나 작동하지 않을 수 있으므로 리포지토리를 이전 릴리스로 유지하지 마십시오. 그리고 다음을 클릭하여 계속 진행합니다.

  6. 다음 단계는 업그레이드한 시스템을 SUSE Customer Center에 등록했는지의 여부에 따라 달라집니다.

    1. 시스템을 SUSE Customer Center에 등록하지 않은 경우 YaST에는 보조 설치 미디어인 SLE-15-SP2-Full-ARCH-GM-media1.iso 이미지를 사용하는 것을 추천하는 팝업 메시지가 표시됩니다.

      이 미디어가 없는 경우에는 시스템을 등록 없이 업그레이드할 수 없습니다.

    2. 시스템을 SUSE Customer Center에 등록한 경우 YaST는 가능한 마이그레이션 대상과 요약을 표시합니다.

      목록에서 마이그레이션 대상을 하나 선택하고 다음을 선택하여 계속 진행합니다.

  7. 다음 대화 상자에서는 추가 설치 매체를 선택적으로 추가할 수 있습니다. 추가 설치 미디어가 있는 경우 추가 기능 제품을 설치하겠습니다 옵션을 활성화하고 미디어 유형을 지정합니다.

  8. 업그레이드에 대한 설치 설정을 검토합니다.

  9. 모든 설정을 원하는 대로 설정했으면 업데이트를 클릭하여 설치 및 제거 절차를 시작합니다.

    작은 정보
    작은 정보: SMT 클라이언트에서 업그레이드 오류 발생

    업그레이드하려는 SMT 클라이언트 시스템을 업그레이드하지 못한 경우 절차 3.1. “SMT 서버에서 SUSE Linux Enterprise Client 등록 취소” 항목을 참조하여 나중에 업그레이드 절차를 다시 시작하십시오.

  10. 업그레이드 프로세스가 성공적으로 종료된 후에는 4.4.1절 “업그레이드 후 점검”의 설명과 같이 업그레이드 후 점검을 수행합니다.

4.4.1 업그레이드 후 점검

  • 독립 패키지가 있는지 확인합니다. 독립 패키지란 더 이상 어떤 활성 리포지토리에도 속하지 않는 패키지를 말합니다. 다음 명령으로 독립 패키지 목록을 볼 수 있습니다.

    tux > zypper packages --orphaned

    이 목록을 통해 패키지가 아직 필요한지 또는 제거해도 좋은지 알 수 있습니다.

  • *.rpmnew*.rpmsave 파일을 확인하고 해당 파일의 컨텐트를 검토하며 적합한 변경 사항을 병합합니다. 업그레이드에 구성 파일 덮어쓰기가 아닌 기본 구성 파일에 대한 변경 사항이 포함되는 경우, 패키지는 이러한 파일 유형 중 하나를 씁니다. *.rpmnew에는 새로운 기본 구성이 포함되고 원본 파일을 그대로 유지하지만, *.rpmsave는 새 기본 파일로 교체된 원본 구성의 사본입니다.

    전체 파일 시스템에서 *.rpmnew*.rpmsave 파일을 검색할 필요는 없으며 가장 중요한 파일은 /etc 디렉토리에 저장되어 있습니다. 다음 명령을 사용하여 해당 파일을 나열합니다.

    tux > find /etc -print | egrep "rpmnew$|rpmsave$"

4.5 AutoYaST를 사용하여 업그레이드

업그레이드 프로세스를 자동으로 실행할 수 있습니다. 자세한 내용은 Book “AutoYaST Guide”, Chapter 4 “Configuration and Installation Options”, Section 4.10 “Upgrade”를 참조하십시오.

4.6 SUSE Manager를 사용하여 업그레이드

SUSE Manager는 SUSE Linux Enterprise 클라이언트용 업데이트, 패치 및 보안 수정을 제공하기 위한 서버 솔루션입니다. 이 솔루션에는 관리 작업 도구 세트와 웹 기반 사용자 인터페이스가 함께 제공됩니다. SUSE Manager에 대한 자세한 내용은 https://www.suse.com/products/suse-manager/를 참조하십시오.

SUSE Manager를 사용하여 시스템 업그레이드를 수행할 수 있습니다. 통합된 AutoYaST 기술을 사용하여 한 개의 주 버전에서 다음 버전으로 업그레이드할 수 있습니다.

SUSE Manager가 시스템을 관리하는 경우에는 SUSE Manager 설명서의 설명과 같이 업데이트합니다. 클라이언트 마이그레이션 프로시저는 https://documentation.suse.com/suma/에서 확인할 수 있는 SUSE Manager 업그레이드 가이드에 설명되어 있습니다.

4.7 롤백 후 등록 상태 업데이트

서비스 팩 업그레이드를 수행할 때는 등록 서버의 구성을 변경하여 새 리포지토리에 대한 액세스를 제공해야 합니다. 업그레이드 프로세스가 중단되거나 복구된 경우(백업 또는 스냅샷에서 복원하여) 등록 서버의 정보가 시스템 상태와 일치하지 않습니다. 이로 인해 업데이트된 리포지토리에 액세스할 수 없거나 클라이언트에서 잘못된 리포지토리가 사용될 수 있습니다.

스냅퍼를 통해 롤백이 이루어지는 경우 부팅 프로세스 중 올바른 리포지토리에 대한 액세스가 설정되도록 등록 서버에 알림이 전달됩니다. 다른 방법으로 시스템을 복구했거나 등록 서버와의 커뮤니케이션에 오류가 발생한 경우 클라이언트에서 수동으로 롤백을 트리거합니다. 수동 롤백 트리거의 예는 네트워크 문제로 인해 서버에 액세스할 수 없는 경우가 될 수 있습니다. 롤백을 수행하려면 다음을 실행합니다.

tux > sudo snapper rollback

특히 다음을 사용하여 서비스를 새로 고친 후에는 시스템에 올바른 리포지토리가 설정되었는지 항상 확인하는 것이 좋습니다.

tux > sudo zypper ref -s

이 기능은 rollback-helper 패키지에 있습니다.

4.8 시스템 등록

업그레이드를 실행하기 전에 시스템을 등록하지 않은 경우 YaST에서 제품 등록 모듈을 사용하여 언제든지 시스템을 등록할 수 있습니다.

시스템을 등록하면 다음과 같은 이점이 있습니다.

  • 지원 자격

  • 보안 업데이트 및 버그 수정 가용성

  • SUSE Customer Center에 액세스

  1. YaST를 시작하고 소프트웨어 ›  제품 등록 을 선택하여 등록 대화 상자를 엽니다.

  2. 사용자나 조직이 가입을 관리하는 데 사용하는 SUSE 계정과 연결된 전자 메일 주소를 입력하십시오. 아직 SUSE 계정이 없다면 SUSE Customer Center 홈 페이지(https://scc.suse.com/)로 이동하여 계정을 생성하십시오.

  3. SUSE Linux Enterprise Server와 함께 받은 등록 코드를 입력하십시오.

  4. 네트워크에서 하나 이상의 로컬 등록 서버를 사용할 수 있으면 목록에서 로컬 등록 서버를 선택할 수 있습니다.

  5. 등록을 시작하려면 다음을 눌러 계속합니다.

    성공적으로 등록한 후 YaST에는 시스템에 사용할 수 있는 확장, 추가 기능 및 모듈이 나열됩니다. 이를 선택하고 설치하려면 Book “배포 가이드”, Chapter 20 “모듈, 확장 및 타사 추가 기능 제품 설치”, Section 20.1 “온라인 채널에서 모듈 및 확장 설치”를 계속 진행합니다.

5 온라인 업그레이드

SUSE는 실행 중인 시스템을 새로운 서비스 팩으로 업그레이드하기 위한 직관적인 그래픽 및 간단한 명령줄 도구를 제공합니다. 서비스 팩 롤백 등도 지원합니다. 이 장에서는 이러한 도구를 사용하여 서비스 팩 업그레이드를 수행하는 방법을 단계별로 설명합니다.

5.1 개념 개요

SUSE는 정기적으로 SUSE Linux Enterprise 제품군을 위한 새로운 서비스 팩을 공개합니다. 고객이 쉽게 새로운 서비스 팩으로 마이그레이트하고 작동 중지 시간을 최소화할 수 있도록 SUSE는 시스템 실행 중에 온라인 마이그레이션을 지원합니다.

SLE 12부터 YaST Wagon이 YaST 마이그레이션(GUI)과 Zypper 마이그레이션(명령 줄)으로 대체되었습니다. 이는 다음과 같은 장점이 있습니다.

  • 첫 번째 RPM을 업데이트할 때까지 시스템이 항상 정의된 상태를 유지.

  • 첫 번째 RPM을 업데이트할 때까지는 취소 가능.

  • 오류 발생 시 간단하게 복구.

  • 시스템 도구를 통해 롤백을 수행할 수 있어 백업이나 복원이 필요하지 않음.

  • 모든 활성 리포지토리 사용.

  • 서비스 팩을 건너뛰는 기능

주의
주의: 주 릴리스에 지원되지 않는 온라인 마이그레이션

온라인 마이그레이션은 서비스 팩 간 마이그레이션에 지원됩니다. 온라인 마이그레이션은 새로운 주 릴리스로의 업그레이드에는 지원되지 않습니다. 자세한 내용은 1장 경로 및 방법 업그레이드를 참조하십시오.

새로운 주 릴리스로의 업그레이드에는 오프라인 마이그레이션을 사용하십시오. 자세한 내용은 4장 오프라인 업그레이드를 참조하십시오.

중요
중요: SUSE Manager 클라이언트 업그레이드

업그레이드할 시스템이 SUSE Manager 클라이언트인 경우 YaST 온라인 마이그레이션 또는 zypper 마이그레이션에서 업그레이드할 수 없습니다. 대신 클라이언트 마이그레이션 절차를 사용합니다. 이는 SUSE Manager 업그레이드 가이드에 설명되어 있습니다.

5.2 서비스 팩 마이그레이션 워크플로

서비스 팩 마이그레이션은 YaST, zypper, 또는 AutoYaST로 실행할 수 있습니다.

서비스 팩 마이그레이션을 시작하려면 먼저 SUSE Customer Center나 로컬 RMT 서버에 시스템을 등록해야 합니다. SUSE Manager를 사용할 수도 있습니다.

방법에 관계없이 서비스 팩 마이그레이션은 다음 단계로 구성됩니다.

  1. 등록된 시스템에서 가능한 마이그레이션 대상을 찾습니다.

  2. 하나의 마이그레이션 대상을 선택합니다.

  3. 새 리포지토리를 요청하고 활성화합니다.

  4. 마이그레이션을 실행합니다.

마이그레이션 대상 목록은 설치 및 등록한 제품에 따라 다릅니다. 새 SP를 아직 사용할 수 없는 확장을 설치한 경우 마이그레이션 대상이 제공되지 않을 수 있습니다.

호스트에서 사용 가능한 마이그레이션 대상 목록은 항상 SUSE 고객 센터에서 검색되며, 설치된 제품 또는 확장에 따라 달라집니다.

5.3 서비스 팩 마이그레이션 취소

서비스 팩 마이그레이션은 마이그레이션 프로세스 중 특정 단계에서만 취소할 수 있습니다.

  1. 패키지 업그레이드를 시작하기 전에는 서비스, 리포지토리 등 시스템 변경이 최소화됩니다. /etc/zypp/repos.d/*를 복구하여 이전 상태로 돌아갑니다.

  2. 패키지 업그레이드 시작 후에는 스냅퍼 스냅샷을 사용하여 이전 상태로 돌아갈 수 있습니다(Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper” 참조).

  3. 마이그레이션 대상을 선택하면 SUSE 고객 센터에서 리포지토리 데이터를 변경합니다. 이 상태를 수동으로 되돌리려면 SUSEConnect --rollback을 사용하십시오.

5.4 온라인 마이그레이션 도구(YaST)를 통한 업그레이드

YaST를 사용하여 서비스 팩 마이그레이션을 수행하려면 온라인 마이그레이션 도구를 사용하십시오. 기본적으로 YaST는 타사 리포지토리에서 패키지를 설치하지 않습니다. 타사 리포지토리에서 패키지가 설치된 경우 YaST는 패키지가 SUSE에서 가져오는 동일한 패키지로 바뀌지 않도록 방지합니다.

참고
참고: 설치 크기 줄이기

서비스 팩 마이그레이션을 수행할 때 YaST는 모든 권장 패키지를 설치합니다. 따라서 특히 사용자 정의 최소 설치의 경우 시스템의 설치 크기가 상당히 증가할 수 있습니다.

이 기본 동작을 변경하고 필요한 패키지만 허용하려면 /etc/zypp/zypp.conf에서 solver.onlyRequires 옵션을 조정합니다.

solver.onlyRequires = true

추가적으로, /etc/zypp/zypper.conf 파일을 편집하고 installRecommends 옵션을 변경합니다.

installRecommends=false

그러면 모든 패키지 작업의 동작이 변경됩니다(예: 패치 또는 새로운 패키지의 설치). 단일 호출에 대한 Zypper의 동작을 변경하려면 명령줄에 --no-recommends 파라미터를 추가합니다.

서비스 팩 마이그레이션을 시작하려면 다음을 수행하십시오.

  1. 향후 종속성 충돌을 방지하기 위해 등록 서버에서 사용되지 않는 확장을 모두 비활성화합니다. 확장을 기억하지 못하는 경우 YaST에서 나중에 사용되지 않는 확장 리포지토리를 검색하고 비활성화합니다.

  2. 업데이트할 시스템에서 실행 중인 GNOME 세션에 로그인한 경우 텍스트 콘솔로 전환합니다. GNOME 세션에서 업데이트를 실행하지 않는 것이 좋습니다. 원격 시스템에서 로그인한 경우에는 이 내용이 적용되지 않습니다(GNOME과 함께 VNC 세션을 실행 중인 경우 제외).

  3. LTSS 가입자인 경우 LTSS 확장 리포지토리가 활성화되어 있는지 확인하십시오.

  4. YaST 온라인 업데이트를 실행하여 시스템을 위한 최신 패키지 업데이트를 받습니다.

  5. yast2-migration 패키지 및 종속 항목을 설치합니다(YaST 에서 소프트웨어 ›  소프트웨어 관리 아래).

  6. YaST를 재시작합니다. 그렇지 않으면 새로 설치한 모듈이 관리 센터에 표시되지 않습니다.

  7. YaST에서 온라인 마이그레이션을 선택합니다(업그레이드할 SUSE Linux Enterprise Server에 따라, 이 모듈은 시스템 또는 소프트웨어로 분류됨). 가능한 마이그레이션 대상 및 요약이 표시됩니다. 시스템에서 마이그레이션 대상을 둘 이상 사용할 수 있는 경우 목록에서 하나를 선택합니다.

  8. 목록에서 마이그레이션 대상을 하나 선택하고 다음을 선택하여 계속 진행합니다.

  9. 마이그레이션 도구가 업데이트 리포지토리를 제공할 경우 를 선택하여 진행하는 것이 좋습니다.

  10. 온라인 마이그레이션 도구가 DVD 또는 로컬 서버에서 구식 리포지토리를 찾는 경우 해당 리포지토리를 비활성화하는 것이 좋습니다. 구식 리포지토리는 이전 SP에서 온 것입니다. SUSE Customer Center 또는 RMT의 이전 리포지토리는 자동으로 제거됩니다.

  11. 요약을 확인하고 [다음]을 눌러 마이그레이션을 계속합니다. 업데이트 시작을 눌러 확인합니다.

  12. 마이그레이션이 끝나면 시스템을 재시작합니다.

5.5 Zypper로 업그레이드

Zypper를 사용하여 서비스 팩 마이그레이션을 수행하려면 패키지 zypper-migration-plugin에서 명령줄 도구 zypper migration 을 사용합니다.

참고
참고: 설치 크기 줄이기

서비스 팩 마이그레이션을 수행할 때 YaST는 모든 권장 패키지를 설치합니다. 따라서 특히 사용자 정의 최소 설치의 경우 시스템의 설치 크기가 상당히 증가할 수 있습니다.

이 기본 동작을 변경하고 필요한 패키지만 허용하려면 /etc/zypp/zypp.conf에서 solver.onlyRequires 옵션을 조정합니다.

solver.onlyRequires = true

추가적으로, /etc/zypp/zypper.conf 파일을 편집하고 installRecommends 옵션을 변경합니다.

installRecommends=false

그러면 모든 패키지 작업의 동작이 변경됩니다(예: 패치 또는 새로운 패키지의 설치). 단일 호출에 대한 Zypper의 동작을 변경하려면 명령줄에 --no-recommends 파라미터를 추가합니다.

서비스 팩 마이그레이션을 시작하려면 다음을 수행하십시오.

  1. 업데이트할 시스템에서 실행 중인 GNOME 세션에 로그인한 경우 텍스트 콘솔로 전환합니다. GNOME 세션에서 업데이트를 실행하지 않는 것이 좋습니다. 원격 시스템에서 로그인한 경우에는 이 내용이 적용되지 않습니다(GNOME과 함께 VNC 세션을 실행 중인 경우 제외).

  2. SUSE Linux Enterprise 시스템을 아직 등록하지 않았다면 지금 등록합니다.

    tux > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. LTSS 가입자인 경우 LTSS 확장 리포지토리가 활성화되어 있는지 확인하십시오.

  4. zypper migration을 실행합니다.

    tux > sudo zypper migration
    
    Executing 'zypper patch-check --updatestack-only'
    
    Refreshing service 'Basesystem_Module_15_x86_64'.
    Refreshing service 'Desktop_Applications_Module_15_x86_64'.
    Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'.
    Refreshing service 'Server_Applications_Module_15_x86_64'.
    Loading repository data...
    Reading installed packages...
    
    0 patches needed (0 security patches)
    
    Executing 'zypper  refresh'
    
    Repository 'SLE-Module-Basesystem15-Pool' is up to date.                        
    Repository 'SLE-Module-Basesystem15-Updates' is up to date.                     
    Repository 'SLE-Module-Desktop-Applications15-Pool' is up to date.              
    Repository 'SLE-Module-Desktop-Applications15-Updates' is up to date.           
    Repository 'SLE-Product-SLES15-Pool' is up to date.                             
    Repository 'SLE-Product-SLES15-Updates' is up to date.                          
    Repository 'SLE-Module-Server-Applications15-Pool' is up to date.               
    Repository 'SLE-Module-Server-Applications15-Updates' is up to date.            
    All repositories have been refreshed.
    Available migrations:
    
        1 | SUSE Linux Enterprise Server 15 SP2 x86_64
            Basesystem Module 15 SP2 x86_64
            Desktop Applications Module 15 SP2 x86_64
            Python 2 Module 15 SP2 x86_64
            Server Applications Module 15 SP2 x86_64
           
        2 | SUSE Linux Enterprise Server 15 SP1 x86_64
            Basesystem Module 15 SP1 x86_64
            Desktop Applications Module 15 SP1 x86_64
            Python 2 Module 15 SP1 x86_64
            Server Applications Module 15 SP1 x86_64       
    
    [num/q]:

    마이그레이션 프로세스에 대한 몇 가지 참고 사항:

    • 시스템에서 마이그레이션 대상을 둘 이상 사용할 수 있는 경우 목록에서 SP를 하나 선택할 수 있습니다. 이는 하나 이상의 SP를 건너뛰는 것과 같습니다. 기본 제품(SLES, SLED)에 대한 온라인 마이그레이션은 주요 버전의 SP 사이에서만 가능합니다.

    • 기본적으로 Zypper는 zypper dup로 전달되는 --no-allow-vendor-change 옵션을 사용합니다. 타사 리포지토리에서 패키지가 설치된 경우 이 옵션은 패키지가 SUSE에서 가져오는 동일한 패키지로 바뀌지 않도록 방지합니다.

    • Zypper가 DVD 또는 로컬 서버에서 구식 리포지토리를 찾는 경우 해당 리포지토리를 비활성화하는 것이 좋습니다. 이전 SUSE Customer Center 또는 RMT 리포지토리는 자동으로 제거됩니다.

  5. 모든 변경 사항 특히, 제거될 패키지를 검토합니다. y를 입력하여 계속합니다(업그레이드할 정확한 패키지 수는 시스템에 따라 다를 수 있음).

    266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch.
    Overall download size: 285.1 MiB. Already cached: 0 B  After the operation, additional 139.8 MiB will be used.
    Continue? [y/n/? shows all options] (y):

    셸에서 스크롤하려면 ShiftPage ↑ 또는 ShiftPage ↓ 키를 사용합니다.

  6. 마이그레이션이 끝나면 시스템을 재시작합니다.

5.6 일반 Zypper로 업그레이드

인터넷 또는 등록 서버에 액세스할 수 없어 시스템을 등록하지 못한 경우, YaST 마이그레이션 또는 zypper 마이그레이션을 사용하여 새 서비스 팩으로 마이그레이션할 수 없습니다. 이러한 경우에도 일반 Zypper 및 몇 가지 수작업을 통해 새 서비스 팩으로 마이그레이션할 수 있습니다.

중요
중요: 등록되지 않은 시스템만 해당

새 서비스 팩으로의 이 마이그레이션 경로는 인터넷 또는 등록 서버에 액세스할 수 없는 등록되지 않은 시스템 지원합니다. 예를 들어, 특별하게 보호되는 네트워크 내의 시스템이 이에 해당할 수 있습니다. 시스템을 등록한 경우에는 YaST 또는 Zypper 마이그레이션을 사용하십시오.

중요
중요: 설치 원본

이 마이그레이션 경로의 경우, 사용자가 마이그레이션할 시스템이 액세스할 수 있는 위치에 새 서비스 팩을 위한 설치 소스를 제공해야 합니다. 이는 예를 들어 RMT 서버 또는 SLP 서버를 설정하여 수행될 수 있습니다.

또한, 이 작업에서는 시스템이 설치된 제품 버전을 위한 최신 업데이트 리포지토리에 액세스할 수 있어야 합니다.

  1. 마이그레이션할 시스템에서 실행 중인 그래픽 세션에 로그인한 경우에는 해당 세션에서 로그아웃한 후 텍스트 콘솔로 전환합니다. 그래픽 세션에서 업데이트를 실행하지 않는 것이 좋습니다. 원격 시스템에서 로그인한 경우에는 이 내용이 적용되지 않습니다(X와 함께 VNC 세션을 실행 중인 경우 제외).

  2. 이전 SUSE Linux Enterprise 리포지토리를 사용하여 패키지 관리 도구를 업데이트합니다.

    tux > sudo zypper patch --updatestack-only
  3. 현재 리포지토리가 할당되지 않은 패키지(독립 패키지)의 목록을 가져옵니다. 이러한 패키지는 마이그레이션되지 않으며 마이그레이션 이후의 작동이 보장되지 않습니다(이유: 사용하는 다른 패키지가 더 이상 호환되지 않는 방식으로 변경될 수 있음). 목록을 가져오려면, 다음을 실행합니다.

    tux > sudo zypper packages --orphaned

    목록을 검토한 후 더 이상 필요하지 않은 모든 독립 패키지를 제거합니다. 남은 모든 독립 패키지를 기록합니다. 이는 나중에 비교하기 위해 필요합니다.

  4. 다음을 실행하여 현재 시스템이 등록된 모든 리포지토리 목록을 가져옵니다.

    tux > sudo zypper repos -u

    다음에서는 리포지토리 URL을 다시 작성하며 새 서비스 팩의 각 리포지토리를 참조하도록 해야 합니다(SLE-15SLE-15-SP1로 바꿔야 함). 리포지토리의 URL이 다음과 같은 경우:

    http://rmt.example.com/repo/SUSE/Products/SLE-15-Product-SLES/x86_64/product/

    다음과 같이 변경해야 합니다.

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP1-Product-SLES/x86_64/product/

    활성화된 모든 리포지토리에서 이 작업을 수행해야 합니다. 현재 비활성화된 리포지토리에서도 이 작업을 수행할 수 있습니다. 그러면 나중에 시스템을 활성화할 때 시스템이 잘못된 설치 소스를 갖는 것이 방지됩니다.

    리포지토리 URL을 변경하기 위해 제공되는 옵션은 다음과 같습니다.

    1. YaST › 소프트웨어 › 소프트웨어 리포지토리 사용. 리포지토리를 선택하고 편집을 클릭하여 필요한 변경을 수행합니다. 모든 리포지토리에서 이를 수행합니다.

    2. Zypper 사용. 새 리포지토리를 추가하고 이후에 해당하는 기존 리포지토리를 제거합니다.

      tux > sudo zypper addrepo -f URL NAME-15-SP1
      tux > sudo zypper removerepo  NAME
    3. /etc/zypp/repos.d에서 리포지토리 구성 파일을 편집하여. 각 리포지토리는 1개의 구성 파일로 표시됩니다. 각 파일에서 baseurl 파라미터 값을 변경해야 합니다.

  5. zypper repos -u를 실행하여 변경 사항을 확인한 후 다음을 실행하여 리포지토리를 업데이트합니다.

    tux > sudo zypper refresh -f -s

    리포지토리 업데이트가 실패하는 경우, URL을 잘못 입력하지 않았는지 다시 확인합니다. 문제를 수정할 수 없는 경우에는 실패한 리포지토리를 비활성화하는 것이 좋습니다.

    모든 리포지토리가 올바르게 구성된 경우에는 다음을

    tux > sudo zypper refresh -f -s

    다시 실행하여 모든 리포지토리가 최신 상태가 되도록 합니다.

  6. 마이그레이션을 시작하기 전에 우선 테스트 실행을 하는 것이 좋습니다.

    tux > sudo zypper dup -D --no-allow-vendor-change --no-recommends

    -D 파라미터는 시험 실행을 수행하며 시스템을 실제로 변경하지 않고 마이그레이션을 시뮬레이션합니다. 문제가 발생하는 경우에는 해당 문제를 수정한 후 계속 진행합니다. 시험 실행이 성공하는 경우

    tux > sudo zypper dup --no-allow-vendor-change --no-recommends

    -no-allow-vendor-change를 실행하며 타사 RPM이 기본 시스템의 RPM을 덮어쓰지 않는지 확인합니다. --no-recommends 옵션은 초기 설치 중 선택 취소된 패키지가 다시 추가되지 않도록 합니다.

  7. 마이그레이션이 완료되고 시스템이 새 서비스 팩 버전으로 부팅되면 독립 패키지 확인을 다시 실행합니다.

    tux > sudo zypper packages --orphaned

    마이그레이션을 시작하기 전 작성한 목록과 새 목록을 비교합니다. 새 패키지가 목록에 표시되면 그 이유는 새 서비스 팩의 다른 모듈로 이동했기 때문일 수 있습니다. 이전 설치에 해당 모듈이 없었던 경우에는 해당 패키지가 업데이트되지 않습니다.

    https://scc.suse.com/packages에서 패키지가 속한 모듈을 확인할 수 있습니다. zypper addrepo 또는 YaST 소프트웨어 리포지토리 모듈을 사용하여 누락된 모듈을 추가하고 다음을 실행하여 이후에 해당하는 독립 패키지를 업데이트합니다.

    tux > sudo zypper install --no-recommends LIST OF PACKAGES
  8. 새 서비스 팩으로 마이그레이션되었습니다!

5.7 서비스 팩 롤백

서비스 팩이 작동하지 않을 경우 SUSE Linux Enterprise에서는 서비스 팩 마이그레이션이 시작되기 이전 상태로 시스템을 되돌릴 수 있습니다. 이를 위해서는 스냅샷을 활성화한 Btrfs 루트 파티션(SLES 12 이후부터 기본값)이 필요합니다. 자세한 내용은 Book “Administration Guide”, Chapter 7 “System Recovery and Snapshot Management with Snapper”를 참조하십시오.

  1. 모든 스냅퍼 스냅샷 목록을 가져옵니다.

    tux > sudo snapper list

    출력을 검토하여 서비스 팩 마이그레이션이 시작되기 직전에 생성된 스냅샷을 찾습니다. 설명 열에 해당하는 설명이 포함되어 있고 스냅샷은 사용자 데이터 열에서 중요로 표시되어 있습니다. # 열의 스냅샷 번호와 날짜 열의 날짜를 기록해 둡니다.

  2. 시스템을 재부팅합니다. 부팅 메뉴에서 읽기 전용 스냅샷에서 부트 로더 시작을 선택하고 이전 단계에서 기록해 둔 날짜와 번호의 스냅샷을 선택합니다. 두 번째 부팅 메뉴(스냅샷의 메뉴)가 로드됩니다. SLES 15 SP2로 시작하는 항목을 선택하여 부팅합니다.

  3. 시스템이 시스템 파티션이 읽기 전용으로 탑재된 이전 상태로 부팅됩니다. root로 로그인하고 올바른 스냅샷을 선택했는지 확인합니다. 모든 기능이 제대로 작동하는지도 확인합니다. 루트 파일 시스템은 읽기 전용으로 탑재되므로 기능에 제한이 있을 수 있습니다.

    문제가 발생하거나 잘못된 스냅샷을 부팅한 경우 재부팅하고 다른 스냅샷을 선택하여 부팅합니다. 이때까지는 영구적으로 변경되지 않았습니다. 스냅샷이 올바르고 제대로 작동하는 경우 다음 명령을 실행하여 영구적으로 변경합니다.

    tux > sudo snapper rollback

    이후 재부팅합니다. 부팅 화면에서 기본 부팅 항목을 선택하여 복구된 시스템으로 재부팅합니다.

  4. 리포지토리 구성이 제대로 재설정되었는지 확인합니다. 또한 모든 제품이 올바로 등록되었는지 확인합니다. 하나라도 잘못된 경우 나중에 시스템을 업데이트할 수 없거나 시스템이 잘못된 패키지 리포지토리를 사용하여 업데이트될 수 있습니다.

    이 절차를 시작하기 전에 인터넷에 액세스할 수 있는지 확인하십시오.

    1. 다음을 실행하여 서비스 및 리포지토리를 새로 고칩니다.

      tux > sudo zypper ref -fs
    2. 다음을 실행하여 활성 리포지토리 목록을 가져옵니다.

      tux > sudo zypper lr

      이 명령을 출력을 자세히 확인하십시오. 업데이트를 위해 추가된 서비스와 리포지토리가 나열되지 않아야 합니다. 예를 들어, SLES15 SP1에서 SLES15로 롤백하는 경우 목록은 SLES15-SP1 리포지토리가 아닌 SLES15 리포지토리를 포함해야 합니다.

      잘못된 리포지토리가 나열되는 경우 이를 삭제하고 필요한 경우 사용 중인 제품 또는 서비스 팩 버전과 일치하는 버전으로 바꾸어야 합니다. 지원되는 마이그레이션 경로에 대한 리포지토리 목록은 2.3절 “모듈 종속성 및 라이프사이클”을 참조하십시오. (수작업이 필요할 수 있음에 유의하십시오. 리포지토리는 자동으로 업데이트되지만, 확인하고 필요한 수정을 하는 것이 좋습니다.)

    3. 마지막으로 다음을 실행하여 설치한 모든 제품의 등록 상태를 확인합니다.

      tux > sudo SUSEConnect --status

      모든 제품이 등록됨으로 보고되어야 합니다. 그렇지 않으면 다음을 실행하여 등록을 복구합니다.

      tux > sudo SUSEConnect --rollback

이제 시스템을 서비스 팩 마이그레이션이 시작되기 직전에 캡처된 상태로 되돌렸습니다.

5.8 SUSE Manager를 사용하여 업그레이드

SUSE Manager는 SUSE Linux Enterprise 클라이언트용 업데이트, 패치 및 보안 수정을 제공하기 위한 서버 솔루션입니다. 이 솔루션에는 관리 작업 도구 세트와 웹 기반 사용자 인터페이스가 함께 제공됩니다. SUSE Manager에 대한 자세한 내용은 https://www.suse.com/products/suse-manager/를 참조하십시오.

SP 마이그레이션을 사용하면 주 버전 내에서 다른 SP(서비스 팩)로 마이그레이션할 수 있습니다(예: SLES 15 GA에서 SLES 15 SP1로).

SUSE Manager가 시스템을 관리하는 경우에는 SUSE Manager 설명서의 설명과 같이 업데이트합니다. 클라이언트 마이그레이션 절차는 https://documentation.suse.com/suma/에서 확인할 수 있는 SUSE Manager 업그레이드 가이드에 설명되어 있습니다.

5.9 openSUSE Leap에서 SUSE Linux Enterprise Server로 업그레이드

openSUSE 설치 온라인을 SUSE Linux Enterprise Server로 업그레이드할 수 있습니다. 절차는 5.5절 “Zypper로 업그레이드” 항목과 유사하지만 일부 추가 단계가 필요합니다. 운영 시스템에서 이 프로시저를 실행하기 전, 운영 설정을 복제한 테스트 시스템에서 우선 실행해 보는 것이 좋습니다.

마이그레이션이 지원되는 openSUSE Leap 버전을 확인하려면 1.1절 “SLES 15 SP2에 대해 지원되는 업그레이드 경로” 항목을 읽어 보십시오.

주의
주의: 모든 openSUSE 패키지를 마이그레이트할 수는 없음

openSUSE 리포지토리는 SUSE Linux Enterprise Server 리포지토리에서 사용할 수 있는 것보다 더 많은 패키지를 제공합니다. 이러한 패키지가 설치되어 있는 경우 마이그레이션 후에는 더 이상 업데이트를 수신하지 않습니다. 이러한 패키지는 아래 절차에 따라 제거됩니다.

시스템 운영에 필요한 모든 패키지는 SUSE Linux Enterprise Server 리포지토리에서 사용할 수 있습니다. 패키지를 SUSE Package Hub 리포지토리에서 사용할 수 있는지를 확인할 수도 있습니다. 자세한 내용은 Book “배포 가이드”, Chapter 20 “모듈, 확장 및 타사 추가 기능 제품 설치”, Section 20.3 “SUSE Package Hub”를 참조하십시오.

openSUSE Leap에서 마이그레이트하려면 다음 절차를 실행하십시오.

  1. TTY로 전환합니다(CtrlAltF1을 누름) 그런 다음 root로 로그인합니다.

  2. SUSEConnect 를 설치합니다.

    root # zypper in SUSEConnect
  3. SCC에서 SUSE Linux Enterprise Server 리포지토리를 가져오도록 등록합니다.

    root # SUSEConnect -r REGISTRATION_CODE -p SLES/15.1/x86_64
  4. 시스템에서 모든 openSUSE 리포지토리를 나열하고 비활성화합니다.

    root # zypper lr
    root # zypper mr -d REPO_IDS

    공백 구분 목록을 사용하여 활성화한 모든 openSUSE 리포지토리로 REPO_IDS를 바꿉니다.

  5. 이제 설치에 필요한 모듈을 추가합니다.

    root # SUSEConnect --list-extensions
    [...]
    root # SUSEConnect -p sle-module-basesystem/15.1/x86_64

    대부분의 Leap 패키지를 교체하려면 Basesystem, 데스크톱 응용 프로그램, 서버 응용 프로그램 및 Legacy Module을 활성화하는 것이 좋습니다. SUSE 패키지 허브도 활성화하는 것이 좋습니다.

  6. SUSE Linux Enterprise Server 리포지토리에 설치한 패키지를 마이그레이트합니다.

    root # zypper dup --force-resolution
  7. 독립 패키지를 제거합니다.

    root # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  8. 마지막으로 시스템을 재부팅합니다.

6 소스 코드의 백포트

SUSE에서는 백포트를 광범위하게 사용합니다(예: 현재 소프트웨어 수정 및 기능을 릴리스된 SUSE Linux Enterprise 패키지로 마이그레이션). 이 장의 정보는 SUSE Linux Enterprise 소프트웨어 패키지의 보안 및 기능을 확인하기 위해 버전 번호를 비교하는 것이 왜 문제가 되는지 설명합니다. 또한 이 장에서는 SUSE Linux Enterprise 제품을 기반으로 응용 프로그램 소프트웨어의 호환성을 유지하면서 시스템 소프트웨어를 최신 상태로 안전하게 유지하는 방법을 설명합니다. 또한 SUSE Linux Enterprise 시스템 소프트웨어에서 실제로 해결되는 공개 보안 문제와 소프트웨어의 현재 상태를 확인하는 방법을 알 수 있습니다.

6.1 백포트 사용 이유

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

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

  • 기능 중단 가능성이 제한적으로 있는 버그 수정 및

  • 기존 기능을 방해할 수 있는 변경사항.

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

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

  • 패키지와 업스트림 버전의 변경사항이 너무 많아서 더 이상 백포팅을 실행할 수 없는 경우

  • 맬웨어 방지 소프트웨어처럼 시간이 지남에 따라 성능이 저하될 수밖에 없는 소프트웨어의 경우

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

  • SUSE의 엔터프라이즈 제품에서 사용하기 위해 제품을 빌드할 때 소프트웨어 벤더가 사용할 수 있는 안정적인 인터페이스(API)를 보유하고 있어야 합니다.

  • SUSE의 엔터프라이즈 제품 릴리스에서 사용된 패키지가 최고의 기능을 제공하고 자체 또는 전체 엔터프라이즈 제품의 일부로 모두 철저한 테스트를 거쳐야 합니다.

  • Oracle 또는 SAP 제품용 인증과 같이 다른 벤더의 다양한 SUSE 엔터프라이즈 제품 인증을 유지해야 합니다.

  • SUSE의 개발자가 광범위한 릴리스에 초점을 맞추는 대신 다음 제품 버전을 만드는 데 중점을 두도록 합니다.

  • SUSE 지원에서는 특정 엔터프라이즈 릴리스를 정확하게 파악하여 관련 정보를 정확하고 시기적절하게 제공할 수 있습니다.

6.2 백포트 반대 이유

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

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

6.3 버전 번호 해석에 대한 백포트의 영향

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

백포팅이 관련된 경우 제한된 버전 번호 값으로 인해 문제가 발생할 수 있는 특정 영역 중 하나가 보안 검색 도구입니다. 일부 보안 취약성 검색 도구(또는 해당 도구의 특정 테스트)는 버전 정보에서만 실행됩니다. 따라서 이러한 도구 및 테스트는 백포트 포함 시 양성 오류를 생성하기 쉽습니다(일부 소프트웨어가 취약하다고 잘못 식별된 경우). 보안 검색 도구에서 보고서를 평가할 때 항목이 버전 번호 또는 실제 취약성 테스트를 기반으로 하는지 항상 확인하십시오.

6.4 수정된 버그 및 백포트된 기능 확인

백포팅된 버그 수정 및 기능과 관련된 정보가 저장되는 여러 위치는 다음과 같습니다.

  • 패키지의 변경 로그

    tux > rpm -q --changelog name-of-installed-package
    tux > rpm -qp --changelog packagefile.rpm

    출력에서 패키지의 변경 이력을 간단하게 설명합니다.

  • 패키지 변경 로그에는 SUSE Bugzilla 추적 시스템의 버그 또는 다른 버그 추적 시스템에 대한 링크를 가리키는 bsc#1234(BBugzilla Suse.Com) 같은 항목이 포함될 수 있습니다. 기밀 유지 정책 때문에 일부 정보에만 액세스할 수 있습니다.

  • SUSE 패키지에 대한 구체적인 세부 정보와 일반적인 내용이 포함된 /usr/share/doc/PACKAGENAME/README.SUSE 파일이 패키지에 포함될 수 있습니다.

  • 소스 코드를 읽는 데 익숙할 경우 해석할 수 있는 별도 파일로 일반 바이너리 RPM을 빌드하는 중에 적용된 패치가 RPM 소스 패키지에 포함되어 있습니다. SUSE Linux Enterprise 소프트웨어의 소스 설치에 대해서는 Book “Administration Guide”, Chapter 6 “Managing Software with Command Line Tools”, Section 6.1.3.5 “Installing or Downloading Source Packages” 항목을 참조하십시오. SUSE Linux Enterprise에서의 패키지 빌드에 대해서는 Book “Administration Guide”, Chapter 6 “Managing Software with Command Line Tools”, Section 6.2.5 “Installing and Compiling Source Packages” 항목을 참조하십시오. SUSE Linux Enterprise의 소프트웨어 패키지 빌드에 대한 자세한 내용은 최대 RPM 도서를 참조하십시오.

  • 보안 버그 수정의 경우 SUSE 보안 알림을 참조하십시오. 이들 알림에서는 종종 CVE(Common Vulnerabilities and Exposures) 프로젝트에서 유지보수되는 CAN-2005-2495와 같은 표준화된 이름을 통해 버그를 참조합니다.