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

업그레이드 가이드

본 설명서는 SUSE Linux Enterprise Server 업그레이드에 대해 안내합니다. SUSE Linux Enterprise Server를 다른 SLE 제품 또는 확장을 위한 기본 시스템으로 사용하는 경우 해당 제품 또는 확장 관련 업그레이드 정보를 제품 설명서에서 확인하십시오.

게시일: 2024 년 10 월 07 일

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

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

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

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

서문

1 사용 가능한 문서

온라인 문서

문서는 https://documentation.suse.com에서 온라인으로 확인할 수 있습니다. 다양한 형식의 문서를 찾아보거나 다운로드하십시오.

참고
참고: 최신 업데이트

최신 업데이트는 일반적으로 이 문서의 영어 버전으로 제공됩니다.

SUSE 기술 문서

문제가 발생하면 https://www.suse.com/support/kb/에서 온라인으로 제공되는 기술 정보 문서(TID)를 확인하십시오. SUSE 기술 문서에서 필요한 솔루션을 검색하십시오.

릴리스 노트

릴리스 노트는 https://www.suse.com/releasenotes/를 참조하십시오.

시스템에서

오프라인 사용자의 경우, 릴리스 노트는 시스템의 /usr/share/doc/release-notes에서도 확인할 수 있습니다. 개별 패키지에 대한 설명서는 /usr/share/doc/packages에서 확인할 수 있습니다.

맨페이지는 다양한 명령에 대한 설명을 제공합니다. 맨페이지를 보려면 man 뒤에 특정 명령 이름을 입력한 후 실행하십시오. man 명령이 시스템에 설치되지 않은 경우 sudo zypper install man을 사용해 설치하십시오.

2 문서 개선

이 문서에 대한 귀하의 피드백과 기여를 환영합니다. 다음 채널에서 피드백을 제공할 수 있습니다.

서비스 요청 및 지원

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

서비스 요청을 열려면 SUSE Customer Center에 등록된 SUSE 구독이 필요합니다. https://scc.suse.com/support/requests로 이동하여 로그인한 다음 새로 작성을 클릭합니다.

버그 보고서

문서와 관련된 문제는 https://bugzilla.suse.com/에 보고할 수 있습니다.

이 프로세스를 간소화하려면 이 문서의 HTML 버전에서 헤드라인 옆에 있는 문제 보고 아이콘을 클릭하십시오. 그러면 Bugzilla에서 올바른 제품과 범주가 미리 선택되고 현재 섹션의 링크가 추가됩니다. 버그 보고서를 입력하여 즉시 시작할 수 있습니다.

이 작업을 위해서는 Bugzilla 계정이 필요합니다.

기여

이 문서에 기여하려면 이 문서의 HTML 버전에서 헤드라인 옆에 있는 Edit source document(소스 문서 편집) 아이콘을 클릭하십시오. 그러면 GitHub의 소스 코드로 이동하며, 여기에서 풀 요청을 열 수 있습니다.

이 작업을 위해서는 GitHub 계정이 필요합니다.

참고
참고: Edit source document(소스 문서 편집)는 영어로만 제공됨

Edit source document(소스 문서 편집) 아이콘은 각 문서의 영어 버전으로만 제공됩니다. 모든 기타 언어의 경우, 문제 보고 아이콘을 대신 사용하십시오.

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

메일

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

3 문서에서 사용된 규칙

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

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

  • PLACEHOLDER: PLACEHOLDER를 실제 값으로 바꾸기

  • PATH: 환경 변수

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

  • user: 사용자 또는 그룹의 이름

  • package_name: 소프트웨어 패키지의 이름

  • Alt, AltF1: 눌러야 하는 키 또는 키 조합. 키는 키보드에서와 동일하게 대문자로 표시됩니다.

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

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

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

  • Chapter 1, Example chapter: 이 가이드의 다른 장에 대한 상호참조입니다.

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

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

    > command
  • 명령은 줄 끝에 백슬래시 문자(\)를 사용하여 두 줄 또는 여러 줄로 나눌 수 있습니다. 백슬래시는 줄의 끝 이후에도 명령 호출이 계속될 것임을 셸에 알려줍니다.

    > echo a b \
    c d
  • (프롬프트가 앞에 오는) 명령 및 셸이 반환하는 각 출력을 모두 표시하는 코드 블록입니다.

    > command
    output
  • 알림

    주의
    주의: 경고 알림

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

    중요
    중요: 중요한 알림

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

    참고
    참고: 메모 알림

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

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

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

  • 간략한 고지사항

    참고

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

    작은 정보

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

4 지원

아래에서 SUSE Linux Enterprise Server에 대한 지원 정책과 기술 미리 보기에 대한 일반 정보를 찾아보십시오. 제품 라이프싸이클에 대한 자세한 내용은 https://www.suse.com/lifecycle을 참조하십시오.

지원 대상에 해당되는 경우 https://documentation.suse.com/sles-15/html/SLES-all/cha-adm-support.html에서 지원 요청서 관련 정보를 수집하는 방법을 자세히 알아보십시오.

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 라이프싸이클 및 지원

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

1.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(일반 공급) 버전

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

마이그레이션

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

마이그레이션 대상

시스템을 마이그레이션할 수 있는 호환되는 제품으로, 제품/확장 버전과 리포지토리의 URL을 포함합니다. 마이그레이션 대상은 시간에 따라, 설치된 확장에 따라 변경될 수 있습니다. 여러 마이그레이션 대상을 선택할 수 있습니다.

모듈

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

패키지

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

패치

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

서비스 팩(SP)

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

업스트림

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

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

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

업데이트

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

업그레이드

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

1.2 제품 라이프싸이클

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

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

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

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

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

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

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

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

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

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

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

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

1.4 주기적 라이프싸이클 보고서 생성

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

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

> sudo systemctl enable lifecycle-report.timer

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

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

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

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

1.5 지원 수준

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

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

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

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

LTSS를 통한 확장 지원

기능

1-5년

6-7년

8-10년

4-10년

10-13년

기술 서비스

Yes

Yes

Yes

Yes

Yes

패치 및 수정 액세스

Yes

Yes

Yes

Yes

Yes

문서 및 기술 자료 액세스

Yes

Yes

Yes

Yes

Yes

기존 스택 및 워크로드 지원

Yes

Yes

Yes

Yes

Yes

새 배포 지원

Yes

Yes

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

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

No

향상 요청

Yes

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

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

No

No

하드웨어 지원 및 최적화

Yes

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

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

No

No

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

Yes

Yes

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

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

No

최신 SP의 수정 백포트

Yes

Yes

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

해당 없음

해당 없음

보안 업데이트1

모두

모두

모두

중요 항목만

중요 항목만

결함 해결

Yes

Yes

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

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

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

1 SUSE Linux Enterprise 업데이트 정책에 대한 자세한 내용은 다음 knowledgebase article을 참조하십시오.

1.6 SUSEConnect를 통한 시스템 등록 및 등록 취소

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

# zypper repos -u

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

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

# SUSEConnect -r REGCODE

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

# SUSEConnect --de-register

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

# SUSEConnect -s

1.7 LTSS 지원 활성화

Long Term Service Pack Support(LTSS)는 SUSE Linux Enterprise Server의 라이프싸이클을 연장하며, 확장으로 사용할 수 있습니다. LTSS에 대한 자세한 내용은 https://www.suse.com/products/long-term-service-pack-support/를 참조하십시오

LTSS 확장을 활성화하려면 다음 단계를 따릅니다.

  1. 사용 중인 시스템이 LTSS에 적합한 구독으로 등록되어 있는지 확인합니다. 시스템이 아직 등록되어 있지 않은 경우 다음을 실행합니다.

    > sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
  2. 시스템에서 LTSS 확장을 사용할 수 있는지 확인합니다.

    > sudo SUSEConnect --list-extensions | grep LTSS
    SUSE Linux Enterprise Server LTSS 15 SP6 x86_64
    Activate with: SUSEConnect -p SLES-LTSS/15.6/x86_64 -r ADDITIONAL REGCODE
  3. 다음 지시에 따라 모듈을 활성화합니다.

    > sudo SUSEConnect -p SLES-LTSS/15.6/x86_64 -r REGISTRATION_CODE

1.8 SLE 버전 식별

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

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

> 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>

2 업그레이드 경로 및 방법

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

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

2.1 업그레이드와 새로 설치 비교

SUSE Linux Enterprise Server의 두 가지 주 릴리스 간 업그레이드는 SUSE에서 지원됩니다. 업그레이드와 새로 설치 중 어느 것이 더 나은지 여부는 시나리오에 따라 달라집니다. 업그레이드의 경우 작업량이 적은 반면, 새로 설치는 디스크 레이아웃 변경 사항, 특정 파일 시스템 기능, 기타 개선 사항과 같은 릴리스의 모든 새 기능을 사용할 수 있다는 이점이 있습니다. 따라서 SUSE는 시스템을 최대한 활용할 수 있도록 대부분의 시나리오에서 새로 설치를 권장합니다.

업그레이드와 새로 설치의 두 가지 경우 모두 고객은 시스템 설정과 기본값이 여전히 본인의 요구사항을 충족하는지 확인해야 합니다.

특정 릴리스의 서비스 팩에서 동일한 코드스트림의 다른 서비스 팩으로 업데이트하는 경우 SUSE는 새로 설치를 수행하지 말고 현재 위치에서 업데이트할 것을 권장합니다. 그러나 이 경우 고객이 새로 설치를 수행할 이유와 시나리오가 있을 수 있습니다. 어떤 것이 더 적합한지는 고객만이 결정할 수 있습니다.

2.2 SLES 15 SP6에 대해 지원되는 업그레이드 및 마이그레이션 경로

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

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

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

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

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

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

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

가장 쉬운 업그레이드 경로는 모든 서비스 팩을 연속적으로 설치하는 것입니다. SUSE Linux Enterprise 15 제품 라인(GA 및 이후 서비스 팩)의 경우 업그레이드할 때 최대 두 개의 서비스 팩을 건너뛸 수도 있습니다. 예를 들어, SLE 15 SP3에서 15 SP6로의 업그레이드가 지원됩니다(SLE 15 SP3가 지원되는 한).

지원 업그레이드 경로 개요
그림 2.1: 지원 업그레이드 경로 개요
주의
주의: 데이터베이스 업그레이드

여기에서 설명하는 업그레이드 경로는 시스템의 운영 체제인 SUSE Linux Enterprise에만 적용되고 이 운영 체제가 실행하는 모든 응용 프로그램에는 적용되지 않습니다. PostgreSQL이나 MariaDB 데이터베이스와 같은 워크로드가 있는 경우 응용 프로그램을 업그레이드하려면 중간 OS 업그레이드가 필요할 수 있습니다.

운영 체제를 업그레이드하기 전에 Release Notes에서 데이터베이스 버전에 관한 정보를 참조하십시오. 새로운 주 버전이 제공되는 경우 3장 업그레이드 준비에서 업그레이드 지침을 참조하십시오.

버전별로 지원되는 업그레이드 경로
SUSE Linux Enterprise Server 11에서 업그레이드

SLES 11로부터 직접 업그레이드하는 기능은 지원하지 않습니다. SLES 11 SP4 이상이 있고 SLES 15 SP3로 업그레이드해야만 SLES 15 SP6로 넘어갈 수 있습니다.

새로 설치할 수 없는 경우 먼저 설치된 SLES 11 서비스 팩을 SLES 11 SP4로 업그레이드하십시오. 이 업그레이드에 대한 설명은 SLES 11 SP4 Deployment Guide에서 제공됩니다. 다음으로, SLES 15 SP3로 오프라인 업그레이드를 수행합니다. 이 업그레이드에 대한 설명은 SLES 15 SP3 Deployment Guide에서 제공됩니다. 그런 다음 이 가이드의 지침을 따라 SLES 15 SP6로 업그레이드합니다.

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

SLES 12 SP4 또는 이전 서비스 팩으로부터 직접 업그레이드하는 기능은 지원하지 않습니다. SLES 12 SP5 이상이 있어야만 SLES 15 SP6로 넘어갈 수 있습니다.

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

SUSE Linux Enterprise Server 12 SP5에서의 업그레이드

SLES 12 SP5에서 업그레이드하려면 오프라인 업그레이드를 사용해야 합니다. 자세한 내용은 4장 오프라인 업그레이드 항목을 참조하십시오.

SUSE Linux Enterprise Server 15 GA/SP1/SP2/SP3/SP4

SLES 15 GA, SP1, SP2, SP3 또는 SP4로부터 직접 업그레이드하는 기능은 더 이상 지원되지 않습니다. SLES 15 SP5 이상이 있어야만 SLES 15 SP6로 넘어갈 수 있습니다.

LTSS 또는 ESPOS를 사용하는 SUSE Linux Enterprise Server 15 SP1/SP2에서 업그레이드

LTSS 또는 ESPOS를 사용하는 SLES 15 SP1 또는 SP2에서 직접 업그레이드하는 기능은 지원하지 않습니다. LTSS 또는 ESPOS를 사용하는 SLES 15 SP3 이상이 있어야만 SLES 15 SP6로 진행할 수 있습니다.

먼저, 설치된 SLES 15 서비스 팩을 SLES 15 SP3로 업그레이드합니다. 이 업그레이드에 대한 설명은 SLES 15 SP3 Upgrade Guide에서 제공됩니다. 그런 다음 이 가이드의 지침을 따라 SLES 15 SP6로 업그레이드합니다.

LTSS 또는 ESPOS를 사용하는 SUSE Linux Enterprise Server 15 SP3/SP4에서 업그레이드

LTSS 또는 ESPOS를 사용하는 SLES 15 SP3 또는 SP4에서 업그레이드하는 기능은 온라인과 오프라인에서 모두 지원됩니다. 자세한 내용은 2.3절 “온라인 및 오프라인 업그레이드”에서 참조하십시오.

SUSE Linux Enterprise Server 15 SP5에서의 업그레이드

SLES 15 SP5에서 업그레이드하는 기능은 온라인과 오프라인에서 모두 지원됩니다. 자세한 내용은 2.3절 “온라인 및 오프라인 업그레이드”에서 참조하십시오.

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

퍼블릭 클라우드에서 SLE 게스트 업그레이드에 대한 지침은 Using the SUSE Distribution Migration System 항목을 참조하십시오.

openSUSE Leap 15.0/15.1/15.2/15.3 /15.4에서 업그레이드

openSUSE Leap 15.0, 15.1, 15.2, 15.3 또는 15.4로부터 직접 업그레이드하는 기능은 더 이상 지원되지 않습니다. openSUSE Leap 15.5 이상이 있어야만 SLES 15 SP6로 넘어갈 수 있습니다.

openSUSE Leap 15.5/15.6에서 업그레이드

openSUSE Leap 15.5 또는 15.6에서 업그레이드하는 기능은 지원됩니다. 5.9절 “openSUSE Leap에서 SUSE Linux Enterprise Server로 업그레이드”를 참조하십시오. 업그레이드의 경우 Leap 서버 설치만 지원합니다.

참고
참고: ESPOS(Extended Service Pack Overlap Support)

일부 제품의 경우 SUSE는 LTSS와 동일한 조건으로 ESPOS(Extended Service Pack Overlap Support)를 제공합니다. ESPOS에 대한 자세한 내용은 해당 SUSE Linux Enterprise 제품 문서 및 Product Lifecycle Support Policies 웹페이지를 참조하십시오.

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

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

온라인

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

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

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

오프라인

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

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

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

SUSE Manager가 시스템을 관리하는 경우에는 SUSE Manager 설명서의 설명과 같이 업데이트합니다. Client Migration 절차에 대한 설명은 https://documentation.suse.com/suma/SUSE Manager Upgrade Guide에서 제공됩니다.

3 업그레이드 준비

업그레이드 절차를 시작하기 전에 시스템을 올바르게 준비해야 합니다. 무엇보다도 준비에는 데이터를 백업하고 릴리스 노트를 확인하는 작업이 포함됩니다. 다음 장에서는 이러한 단계를 안내합니다.

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

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

참고
참고: SUSE Linux Enterprise 15의 새로운 4096비트 서명 키

2023년 중반, SUSE Linux Enterprise 15 제품군은 RSA 2048비트 서명 키에서 새로운 RSA 4096비트 키로 전환되었습니다. 이 변경은 RPM 패키지, 패키지 리포지토리 및 ISO 서명에 적용됩니다. 더 이상 업데이트되지 않는 기존 리포지토리와 전환 날짜까지 릴리스된 RPM은 이전 2048비트 키로 서명된 상태로 유지됩니다.

시스템을 업데이트하면 SLE 15 SP 4 및 SP5의 suse-build-key 패키지와 SLE 15 SP1, SP2 및 SP3의 LTSS 버전에서 새 키를 RPM 키링으로 자동으로 가져옵니다.

키를 아직 가져오지 않은 경우 수동으로 가져올 수 있습니다.

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

이전 버전의 SLE를 실행 중이거나 새 키를 가져오지 않은 경우 업그레이드 중에 신뢰 여부를 묻는 메시지가 표시됩니다. 지문이 일치하는지 확인합니다.

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

또한 재해 복구 목적으로 예비 4096비트 RSA 키도 가져왔습니다.

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

이 키는 다음을 사용하여 수동으로 가져올 수 있습니다.

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

두 키는 설치 미디어와 SUSE 웹사이트(https://www.suse.com/support/security/keys/)에서도 찾을 수 있습니다.

3.2 릴리스 노트 읽기

release notes에서 모든 변경 사항, 새 기능, 알려진 문제가 나열된 목록을 확인합니다. docu 디렉토리에서 설치 미디어에 관한 릴리스 노트도 확인할 수 있습니다.

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

다음이 적용되는지 여부를 확인하려면 릴리스 노트를 참조하십시오.

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

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

  • 설치에 특별한 예방책이 필요한지 여부

3.3 백업

업그레이드하기 전에 기존 구성 파일을 별도 미디어(예: 테이프 장치, 이동식 하드 디스크 등)에 복사하여 데이터를 백업하십시오. 이 사항은 주로 /var/opt의 일부 디렉토리 및 파일과 /etc에 저장된 파일에 적용됩니다. 또한, /home(HOME 디렉토리)의 사용자 데이터를 백업 미디어에 써야 할 수도 있습니다.

모든 데이터를 root로 백업하십시오. root에만 모든 로컬 파일에 대한 충분한 권한이 있습니다.

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

3.4 가용 디스크 공간 확인

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

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

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

3.4.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.4.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의 경우 현재 설치에 필요한 최소한의 여유 공간이 필요합니다. 여유 공간이 현재 설치보다 두 배 많은 것이 좋습니다.

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

    # snapper list
          # snapper delete NUMBER

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

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

새로운 주 SLE 릴리스를 새로 설치하거나 이전 버전으로 되돌리는 등 설치된 패키지의 목록을 저장할 수 있습니다.

참고
참고

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

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

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

    # rpm -qa --queryformat '%{NAME}\n' >
         installed-software.bak
  3. 두 파일을 모두 백업합니다. 리포지토리 및 설치된 패키지는 다음 명령으로 복원할 수 있습니다.

    # zypper ar repositories.bak.repo
    # 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.6 LTSS 확장 비활성화

LTSS를 사용하는 SUSE Linux Enterprise Server 시스템을 아직 일반 지원이 제공되는 버전으로 업그레이드하면 No migration available 오류와 함께 업그레이드가 실패합니다. zypper migration에서 모든 리포지토리로의 마이그레이션을 시도하지만, 아직 새 버전에 대한 LTSS 리포지토리가 없기 때문입니다.

이 문제를 해결하려면 LTSS 확장을 비활성화한 후 업그레이드합니다.

  1. 다음을 수행하여 LTSS 확장이 활성화되었는지 확인합니다.

    > sudo SUSEConnect --list-extensions | grep LTSS
    SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
    Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64
  2. 위의 SUSEConnect 출력에서 제공되는 명령을 사용하여 LTSS 확장을 비활성화합니다.

    > sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
    Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
    To server: https://scc.suse.com/
  3. zypper lr 명령으로 LTSS 리포지토리가 더 이상 없는지 확인합니다.

3.7 PostgreSQL 데이터베이스 마이그레이션

SUSE Linux Enterprise Server 15 SP6는 PostgreSQL 데이터베이스 버전 14 및 15과 함께 제공됩니다. 버전 15이 기본값이지만, 이전 버전의 SUSE Linux Enterprise Server에서 업그레이드하기 위한 용도로 버전 14이 Legacy 모듈을 통해 제공됩니다.

데이터베이스의 필수 마이그레이션 작업 때문에 자동 업그레이드 프로세스는 없습니다. 따라서 한 버전에서 다른 버전으로의 전환은 수동으로 수행해야 합니다.

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

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

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

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

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

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

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

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

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

    • 새 PostgreSQL 주 버전의 패키지를 설치합니다. SLE 15 SP6의 경우에는 postgresql13-server 및 종속된 모든 패키지를 설치함을 의미합니다.

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

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

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

    # /usr/sbin/rcpostgresql stop

    또는

    # systemctl stop postgresql.service

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

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

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

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

    또는

    # systemctl start postgresql.service
    # 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로 시작합니다.

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

    # /usr/sbin/rcpostgresql start

    또는

    # systemctl start postgresql.service

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

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

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

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

데이터베이스 업그레이드 또는 논리적 복제와 같은 대체 방법 사용에 대한 자세한 내용은 https://www.postgresql.org/docs/13/upgrading.html에서 공식 PostgreSQL 문서를 참조하십시오.

3.8 MySQL 또는 MariaDB 데이터베이스 마이그레이션

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

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

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

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

    기본적으로 mysqldumpINFORMATION_SCHEMA 또는 performance_schema 데이터베이스를 덤프하지 않습니다. 자세한 내용은 https://mariadb.com/kb/en/mariadb-dumpmysqldump/을 참조하십시오.

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

  3. SUSE Linux Enterprise Server 업그레이드를 수행하십시오. 업그레이드 후에도 이전 구성 파일 /etc/my.cnf는 그대로 유지됩니다. 새 구성은 /etc/my.cnf.rpmnew 파일에 있습니다.

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

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

    # systemctl start mariadb

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

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

    # mariadb -u root -p

3.9 Java 응용 프로그램용 MD5 외 서버 인증서 생성

보안 조치로 MD5 기반의 인증서는 더 이상 Java에서 지원되지 않습니다. MD5로 작성한 인증서가 있는 경우 다음 단계에 따라 인증서를 다시 작성하십시오.

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

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

    # openssl genrsa -out server.key 1024

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

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

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

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

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

3.10 가상 머신 게스트 종료

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

3.11 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 클라이언트 등록 취소
  1. 클라이언트 시스템에 로그인합니다.

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

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

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

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

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

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

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

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

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

    > sudo smt-list-registrations

3.12 SLE 12에서 15로 AutoYaST 프로파일 변경

AutoYaST 프로파일 마이그레이션 방법에 대해 알아보려면 Book “AutoYaST Guide”, 를 참조하십시오.

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

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

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

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

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

업데이트 성공 후 이 기능을 다시 활성화하려면 주석 기호를 제거하십시오. 다중 버전 지원에 관한 자세한 내용은 Book “Administration Guide”, Chapter 27 “Installing multiple kernel versions”, Section 27.1 “Enabling and configuring multiversion support” 항목을 참조하십시오.

3.15 resume 부팅 파라미터 조정

SUSE Linux Enterprise Server 12 이하를 설치한 시스템에서 /etc/default/grub의 기본 커널 명령줄에는 최대 절전 모드(suspend-to-disk) 장치를 참조하기 위해 /dev/sda1과 같은 장치 노드 이름을 사용하는 resume 파라미터가 포함될 수 있습니다. 장치 노드 이름은 영구적이지 않으며 재부팅할 때마다 변경될 수 있으므로 이를 고정하는 것이 좋습니다. 그러지 않으면 재부팅할 때 업그레이드된 시스템이 중단될 수 있습니다.

  1. 최대 절전 모드 장치를 찾습니다.

    > sudo grep resume /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"

    최대 절전 모드 장치는 /dev/sda1입니다. 이 명령에서 반환되는 내용이 없으면 최대 절전 모드가 구성되지 않습니다.

  2. /dev/sda1의 UUID를 가져옵니다.

    > sudo blkid /dev/vda1
    /dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"

    /dev/sda1의 UUID는 a1d1f2e0-b0ee-4be2-83d5-78a98c585827입니다.

  3. /etc/default/grub을 편집하고 resume 파라미터를 조정합니다. /dev/sda1UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827으로 바꿉니다. 다음과 같은 결과가 나타납니다.

    GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"
  4. grub 부팅 관리자의 구성을 업데이트합니다.

    > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

시스템에서 최대 절전 모드를 사용하지 않는 경우 resume 파라미터를 제거하고 부팅 구성을 업데이트하면 됩니다.

3.16 IBM Z에서 업그레이드

IBM Z에서 SUSE Linux Enterprise 설치를 업그레이드하려면 parmfile 등을 통한 Upgrade=1 커널 파라미터가 필요합니다. Book “배포 가이드”, Chapter 5 “IBM Z 및 LinuxONE에 설치”, Section 5.5 “parmfile - 시스템 구성 자동화”를 참조하십시오.

3.17 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 SP6로 수동 업그레이드
  1. 부팅 매체를 선택하고 준비합니다(Book “배포 가이드” 참조).

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

  3. (선택 사항) 설치 프로그램이 네트워크 소스가 아닌 DVD의 패키지만 설치하도록 강제하려면 부팅 옵션 media_upgrade=1을 추가합니다.

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

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

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

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

네트워크 설치 원본에서 업그레이드할 경우의 요구사항
네트워크 설치 원본

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

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

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

  • 도메인 네임 서비스

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

  • OpenSLP(선택 사항)

부팅 미디어

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

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

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

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

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

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

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

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

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

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

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

  4. 대상 시스템의 부팅을 시작하고 VNC를 사용하여 이 시스템에서 실행 중인 설치 루틴에 원격으로 연결합니다. 자세한 내용은 Book “배포 가이드”, Chapter 12 “원격 설치”, Section 12.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-SP6-Full-ARCH-GM-media1.iso 이미지를 사용하는 것을 추천하는 팝업 메시지를 표시합니다.

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

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

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

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

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

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

    작은 정보
    작은 정보: SMT 클라이언트의 업그레이드 오류

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

  10. 업그레이드 프로세스가 성공적으로 종료된 후에는 6장 업그레이드 완료에 설명된 업그레이드 후 단계를 수행합니다.

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

업그레이드 프로세스를 자동으로 실행할 수 있습니다. 자세한 내용은 Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.11 “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 설명서의 설명과 같이 업데이트합니다. Client Migration 절차에 대한 설명은 https://documentation.suse.com/suma/SUSE Manager Upgrade Guide에서 제공됩니다.

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

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

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

> sudo snapper rollback

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

> 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 10 “SUSE Linux Enterprise 등록 및 모듈/확장 관리”, Section 10.4 “실행 중인 시스템에서 모듈 및 확장 관리”를 계속 진행합니다.

5 온라인 업그레이드

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

5.1 개념 개요

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

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

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

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

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

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

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

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

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

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

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

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

업그레이드할 시스템이 SUSE Manager 클라이언트인 경우 YaST 온라인 마이그레이션 또는 zypper migration으로 업그레이드할 수 없습니다. 대신, Client Migration 절차를 사용하십시오. SUSE Manager Upgrade Guide에 설명되어 있습니다.

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 10 “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. YaST 온라인 업데이트를 실행하여 시스템을 위한 최신 패키지 업데이트를 받습니다.

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

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

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

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

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

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

    등록 서버가 모듈 또는 확장에 대한 마이그레이션을 제공하지 않는 경우 해당 리포지토리 구성은 변경되지 않은 상태로 유지됩니다. 이는 일반적으로 제품 버전 또는 서비스 팩에 한정되지 않은 NVIDIA Compute 모듈과 같은 타사 리포지토리에서 발생합니다. 필요한 경우, 마이그레이션 후 리포지토리 구성을 수동으로 확인할 수 있습니다.

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

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

5.5 Zypper로 업그레이드

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

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

서비스 팩 마이그레이션을 수행할 때 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 시스템을 아직 등록하지 않았다면 지금 등록합니다.

    > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. 다음과 같이 마이그레이션을 시작합니다.

    > sudo zypper migration

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

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

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

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

  4. 모든 변경 사항 특히, 제거될 패키지를 검토합니다. 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 ↓ 키를 사용합니다.

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

5.6 일반 Zypper로 업그레이드

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

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

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

중요
중요: 설치 원본

이 마이그레이션 경로에는 마이그레이션할 시스템에 설치 소스에 대한 액세스가 필요합니다. 예를 들어 RMT 서버 또는 SLP 서버를 설정하여 완료할 수 있습니다.

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

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

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

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

    > sudo zypper packages --orphaned

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

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

    > sudo zypper repos -u

    제품 버전 번호가 15-SP6가 되도록 각 리포지토리 URL을 업데이트하십시오. 예를 들어 리포지토리의 URL이 다음과 같은 경우

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

    아래와 같이 변경하십시오.

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

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

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

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

    2. Zypper 사용. 다음과 같이 실행하여 이전 리포지토리를 제거합니다.

      > sudo zypper removerepo OLD_REPO_ID

      그런 다음, 다음과 같이 실행하여 해당되는 새 리포지토리를 추가합니다.

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

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

    > sudo zypper refresh -f -s

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

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

    > sudo zypper refresh -f -s

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

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

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

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

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

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

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

    > sudo zypper packages --orphaned

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

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

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

5.7 서비스 팩 롤백

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

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

    > sudo snapper list

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

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

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

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

    > sudo snapper rollback

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

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

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

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

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

      > sudo zypper lr

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

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

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

      > sudo SUSEConnect --status

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

      > sudo SUSEConnect --rollback

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

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

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

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

SUSE Manager가 시스템을 관리하는 경우에는 SUSE Manager 설명서의 설명과 같이 업데이트합니다. Client Migration 절차에 대한 설명은 https://documentation.suse.com/suma/SUSE Manager Upgrade Guide에서 제공됩니다.

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

openSUSE Leap 설치를 SUSE Linux Enterprise Server로 업그레이드할 수 있습니다. 마이그레이션을 위해 어떤 Leap 버전이 지원되는지 알아보려면 2.2절 “SLES 15 SP6에 대해 지원되는 업그레이드 및 마이그레이션 경로”를 참조하십시오.

주의
주의: openSUSE 패키지를 전부 마이그레이션할 수는 없음

openSUSE는 SUSE Linux Enterprise Server보다 더 많은 패키지를 제공합니다. 추가 패키지는 대부분 SUSE Package Hub를 통해 제공되고 마이그레이션됩니다. SUSE Package Hub를 통해 제공되지 않는 추가 패키지는 마이그레이션 후 업데이트를 더 이상 수신하지 않으므로 이후 제거해야 합니다.

시스템 운영에 필요한 모든 패키지를 SUSE Linux Enterprise Server 및 SUSE Package Hub 리포지토리에서 제공하는지 확인하십시오. SUSE Package Hub에 대한 자세한 내용은 https://packagehub.suse.com/를 참조하십시오.

5.9.1 yast2 migration을 사용한 업그레이드

다음 절차는 5.4절 “온라인 마이그레이션 도구(YaST)를 통한 업그레이드”와 유사하지만 몇 가지 추가 단계가 필요합니다. 운영 시스템에서 이 프로시저를 실행하기 전, 운영 설정을 복제한 테스트 시스템에서 우선 실행해 보는 것이 좋습니다.

절차 5.1: yast2 migration을 사용하여 openSUSE Leap을 SUSE Linux Enterprise Server로 업그레이드

openSUSE Leap에서 SUSE Linux Enterprise Server로 마이그레이션하려면 다음 단계를 수행합니다.

  1. 사용하지 않는 모든 응용 프로그램을 닫고 TTY로 전환합니다(예를 들어, CtrlAltF1 누르기). 그런 다음 root로 로그인합니다.

  2. yast2-migrationrollback-helper 패키지를 설치합니다.

    # zypper in yast2-migration rollback-helper
  3. 다음과 같이 rollback-helper 서비스를 활성화합니다.

    # systemctl enable rollback
  4. 다음과 같이 시스템을 SUSE Customer Center에 등록합니다.

    # yast2 registration
  5. 다음과 같이 마이그레이션을 수행합니다.

    # yast2 migration

    패키지가 충돌하는 경우 YaST는 선택할 수 있도록 확인 목록을 표시합니다.

  6. 시스템을 재부팅합니다:

    # reboot

이제 시스템을 SUSE Linux Enterprise Server로 마이그레이션하는 작업이 성공적으로 완료되었습니다. 6장 업그레이드 완료를 진행하고 독립 패키지를 제거하여 완전하게 지원되는 SUSE Linux Enterprise 설치를 실행 중인지 확인합니다.

마이그레이션 후 문제가 발생하면 서비스 팩 업그레이드 같은 마이그레이션을 되돌릴 수 있습니다. 지시사항은 5.7절 “서비스 팩 롤백”을 참조하십시오.

5.9.2 yast2 migration_sle를 사용한 업그레이드

openSUSE Leap에서 SUSE Linux Enterprise Server로의 간소화된 마이그레이션은 Leap 15.4부터 기술 미리 보기로 제공됩니다.

절차 5.2: yast2 migration_sle를 사용하여 openSUSE Leap을 SUSE Linux Enterprise Server로 업그레이드

openSUSE Leap에서 SUSE Linux Enterprise Server로 마이그레이션하려면 다음 단계를 수행합니다.

  1. 사용하지 않는 모든 응용 프로그램을 닫습니다(권장).

  2. yast2-migration-slerollback-helper 패키지를 설치합니다.

    > sudo zypper in yast2-migration-sle rollback-helper
  3. 다음과 같이 rollback-helper 서비스를 활성화합니다.

    > sudo systemctl enable rollback
  4. YaST를 열고 소프트웨어 › 온라인 마이그레이션을 선택하거나 다음을 실행합니다.

    > sudo yast2 migration_sle

    마법사가 마이그레이션 프로세스를 안내합니다. 보류 중인 업데이트가 있는 경우 시스템을 등록하기 전에 설치할 수 있습니다. 등록하려면 등록 코드와 전자 메일 주소를 입력합니다. 로컬 RMT 서버에 등록하려면 등록 코드 대신 해당 URL을 입력하고 전자 메일 주소를 비워 둡니다.

    시스템이 등록되면 SUSE Linux Enterprise Server 리포지토리가 추가되고 SLE 패키지가 설치되어 openSUSE 패키지를 대체합니다.

  5. 시스템을 재부팅합니다:

    > sudo reboot

이제 시스템을 SUSE Linux Enterprise Server로 마이그레이션하는 작업이 성공적으로 완료되었습니다. 6장 업그레이드 완료를 진행하고 독립 패키지를 제거하여 완전하게 지원되는 SUSE Linux Enterprise 설치를 실행 중인지 확인합니다.

마이그레이션 후 문제가 발생하면 서비스 팩 업그레이드 같은 마이그레이션을 되돌릴 수 있습니다. 지시사항은 5.7절 “서비스 팩 롤백”을 참조하십시오.

6 업그레이드 완료

업그레이드한 후에는 일부 추가 작업을 수행해야 합니다. 다음 장에서는 이러한 단계를 안내합니다.

6.1 이전 패키지 확인

zypper packages를 사용하여 독립 패키지와 불필요한 패키지를 확인합니다.

독립 패키지는 구성된 패키지 리포지토리에서 더 이상 사용할 수 없습니다. 더 이상 업데이트할 수 없으며 지원되지 않습니다.

독립 패키지 목록을 확인하려면 다음을 실행합니다.

> zypper packages --orphaned

불필요한 패키지는 사용자가 명시적으로 설치했거나 암시적으로 패턴이나 제품의 일부로 설치된 패키지의 종속성이며, 그 사이에 제거된 패키지입니다. 일반적으로 해당 패키지는 더 이상 필요하지 않으므로 마찬가지로 제거해야 합니다.

불필요한 패키지 목록을 확인하려면 다음을 실행합니다.

> zypper packages --unneeded
작은 정보
작은 정보

불필요한 패키지를 방지하려면 패키지를 삭제할 때 zypper rm--clean-deps 옵션과 함께 사용하거나 옵션 › 패키지 삭제 시 정리가 활성화된 YaST를 사용합니다.

다음을 실행하여 두 목록을 하나로 결합할 수 있습니다.

> zypper packages --orphaned --unneeded

이 목록에서 아직 필요한 패키지와 제거해도 안전한 패키지를 판단할 수 있습니다.

주의
주의: 필요한 패키지를 제거하지 마십시오.

패턴 또는 제품에서 패키지의 이름이 변경되거나 패키지가 제거된 경우, zypper는 해당 패키지가 여전히 설치에 중요하더라도 더 이상 명시적으로 설치된 패키지가 아닌 불필요한 패키지로 표시할 수 있습니다.

그러므로 제거할 패키지 목록을 주의 깊게 검토하십시오.

단일 명령으로 독립 패키지 및 불필요한 패키지를 모두 제거하려면 다음을 실행합니다.

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

단일 패키지 또는 패턴을 제거 대상에서 제외하려면 다음을 추가합니다.

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

다수의 패키지를 제외하려면 텍스트 파일에 newline으로 구분하여 입력하고 명령에 다음을 추가합니다.

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

6.2 구성 파일을 검토합니다.

*.rpmnew*.rpmsave 파일을 확인합니다. 패키지 설치 후 변경된 기본 구성 파일에 대한 변경 사항이 업그레이드에 포함된 경우 파일을 덮어쓰는 대신 이러한 파일 유형 중 하나가 생성됩니다. *.rpmnew에는 새로운 기본 구성이 포함되고 변경된 파일을 그대로 유지하지만, *.rpmsave는 새 기본 파일로 교체된 변경된 구성의 사본입니다.

이러한 파일이 발견되면 컨텐트를 검사하고 올바른 변경 사항을 병합하십시오. 전체 파일 시스템을 검색할 필요가 없으며 /etc 디렉토리만 검색하면 됩니다. 다음 명령을 사용합니다.

> find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

6.3 Python 3 모듈 활성화

SUSE Linux Enterprise Server 15에서는 기본적으로 Python 3.6을 사용합니다. Python 3.9는 SLES 15 SP3에 최신 대체 방법으로 추가되었습니다. 이 버전은 SLES 15 SP4부터 더 이상 지원되지 않습니다. 대신, 중요 업데이트 및 보안 수정이 포함된 최신 Python 버전을 Python 3 모듈을 통해 사용할 수 있습니다.

SUSE Linux Enterprise Server 15 SP3에 Python 3.9를 설치한 경우 다음을 수행하여 Python 3 모듈을 활성화합니다.

> sudo SUSEConnect -p sle-module-python3/15.6/x86_64.

아니면 zypper remove -u python39를 사용하여 3.9를 제거하고 기본 Python 버전으로 되돌릴 수 있습니다.

6.4 XFS v4 장치 다시 포멧

SUSE Linux Enterprise Server는 XFS 파일 시스템의 온디스크 형식(v5)을 지원합니다. 이 형식의 주요 이점은 모든 XFS 메타 데이터의 자동 체크섬, 파일 형식 지원, 파일에 대한 더 많은 수의 액세스 제어 목록 지원을 제공한다는 점입니다.

이 형식은 3.12 이전 버전의 SUSE Linux Enterprise 커널, 3.2.0 이전 버전의 xfsprogs 및 SUSE Linux Enterprise 12 이전에 릴리스된 GRUB 2 버전에서 지원되지 않습니다.

중요
중요: V4는 더 이상 사용되지 않음

XFS에서는 V4 형식의 파일 시스템이 더 이상 사용되지 않습니다. 이 파일 시스템 형식은 다음 명령으로 생성되었습니다.

> sudo mkfs.xfs -m crc=0 DEVICE

이 형식은 SLE 11 및 이전 릴리스에서 사용되었으며 현재 dmesg 명령으로 경고 메시지를 생성합니다.

Deprecated V4 format (crc=0) will not be supported after September 2030

dmesg 명령의 출력으로 위의 메시지가 표시되면 파일 시스템을 V5 형식으로 업데이트하는 것이 좋습니다.

  1. 다른 장치에 데이터를 백업합니다.

  2. 장치에 파일 시스템을 생성합니다.

    > sudo mkfs.xfs -m crc=1 DEVICE
  3. 업데이트된 장치의 백업으로부터 데이터를 복원합니다.

7 원본 코드의 백포트

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

7.1 백포트를 사용하는 이유

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2 백포트를 사용하지 말아야 할 이유

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

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

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

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

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

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

백포트된 버그 수정 및 기능에 관한 정보는 다음과 같은 여러 위치에 저장됩니다.

  • 패키지의 변경 로그

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

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

  • 패키지 변경 로그에는 bsc#1234(BugzillaSuse)와 같은 항목이 포함될 수 있습니다. Com) 같은 항목이 포함될 수 있습니다. 기밀 유지 정책 때문에 일부 정보에만 액세스할 수 있습니다.

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

  • 소스 코드를 읽는 데 익숙할 경우 해석할 수 있는 별도 파일로 일반 바이너리 RPM을 빌드하는 중에 적용된 패치가 RPM 소스 패키지에 포함되어 있습니다. SUSE Linux Enterprise 소프트웨어의 원본을 설치하는 작업에 대한 내용은 Book “Administration Guide”, Chapter 9 “Managing software with command line tools”, Section 9.1.3.5 “Installing or downloading source packages”를 참조하십시오. SUSE Linux Enterprise에 패키지를 빌드하는 작업에 대한 내용은 Book “Administration Guide”, Chapter 9 “Managing software with command line tools”, Section 9.2.5 “Installing and compiling source packages”를 참조하십시오. SUSE Linux Enterprise의 소프트웨어 패키지 빌드에 대한 자세한 내용은 Maximum RPM 도서를 참조하십시오.

  • 보안 버그 수정에 대해서는 SUSE security announcements 항목을 참조하십시오. 이는 주로 CAN-2005-2495와 같이 표준화된 이름을 통한 버그를 나타냅니다(Common Vulnerabilities and Exposures (CVE) 프로젝트에서 유지보수됨).