목차로 이동페이지 탐색으로 이동: 이전 페이지 [액세스 키 p]/다음 페이지 [액세스 키 n]
documentation.suse.com / SUSE Linux Enterprise Server 설명서 / 업그레이드 가이드 / 업그레이드 준비
다음에 적용 SUSE Linux Enterprise Server 15 SP6

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 파일 시스템에서 사용되고 사용할 수 있는 공간을 확인하는 방법에 대한 자세한 내용은 Section 1.2.2.3, “Checking for free space”을 참조하십시오. 자세한 내용은 man 8 btrfs-filesystem 및 https://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.conf 및 pg_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

    기본적으로 mysqldump는 INFORMATION_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

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

  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.key 및 server.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 프로파일 마이그레이션 방법에 대해 알아보려면 Appendix D, Differences between AutoYaST profiles in SLE 12 and 15를 참조하십시오.

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

 

SMT를 실행하는 서버에는 특수한 업그레이드 절차가 필요합니다. 리포지토리 미러링 도구 가이드에서 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

업데이트 성공 후 이 기능을 다시 활성화하려면 주석 기호를 제거하십시오. 다중 버전 지원에 관한 자세한 내용은 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/sda1을 UUID=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 커널 파라미터가 필요합니다. 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"