| Sun Control Station 2.2.1 릴리스 노트 |     |
| Sun Control Station 2.2.1 릴리스 노트 | |
|
이 릴리스 노트는 SunTM Control Station 2.2.1 소프트웨어에 적용됩니다. 이 노트에는 설치, 새로운 기능 및 이전에 발행된 다른 설명서에는 포함되지 않은 알려진 제한 사항에 대한 중요한 정보가 포함되어 있습니다.
패치는 Sun의 공인 영업 센터, 서비스 공급업자로부터 구하거나 다음 SunSolve OnlineSM 웹사이트에서 다운로드할 수 있습니다.
패치 정보 및 설치 지침에 대해서는 패치와 함께 제공되는 README 파일을 참조하십시오.
Sun Control Station 2.2.1 설치 이미지는 쉽게 다운로드할 수 있도록 64MB의 청크로 나눠져 있습니다. 따라서 각 청크를 다운로드한 다음 원래의 압축된 tar 이미지로 조합해야 합니다.
|
주 - 다운로드를 하려면 최소 700MB의 사용 가능 공간이 필요합니다. 이 공간은 파일을 다운로드한 다음 압축된 tar 설치 파일을 재구성하는 데 필요합니다. |
1. Sun Download Center에 액세스하십시오.
Download Center에 액세스하는 방법 및 일련 번호에 대한 지침은 Sun Control Station을 주문할 때 받은 전자 메일에 포함되어 있습니다.
2. Sun Control Station 2.2.1 파일을 다운로드하십시오.
Control Station 2.2.1 설치 이미지는 쉽게 다운로드할 수 있도록 64MB의 청크로 나눠져 있습니다. 따라서 각 청크를 다운로드한 다음 원래의 압축된 tar 이미지로 조합해야 합니다.
다운로드할 파일(및 해당 md5sum 체크섬)은 다음과 같습니다.
3. 다운로드한 파일을 표시된 순서로 연결합니다. 한 행에 다음 명령을 입력합니다.
# cat scs-2.2.1.166.tgz.aa scs-2.2.1.166.tgz.ab scs-2.2.1.166.tgz.ac scs-2.2.1.166.tgz.ad scs-2.2.1.166.tgz.ae scs-2.2.1.166.tgz.af > scs-2.2.1.166.tgz |
ab065e7c0b6a5cc135f30e02ec8c34f9 scs-2.2.1.166.tgz
|
주 - 모든 파일의 체크섬을 확인하려면 다음 명령문을 입력합니다.
|
4. 설치 파일을 설정하려는 디렉토리에 파일의 압축을 풉니다. 다음 명령을 입력합니다.
tar 파일의 압축이 풀리면서 파일 목록이 나타납니다.
5. 배포에 포함된 설치 스크립트를 실행하고 사용권에 동의합니다. 다음 명령을 입력합니다.
# ./scs-2.2.1.166/install/install
Sun Control Station 2.2 소프트웨어 설치 안내서 및 Sun Control Station 2.2 관리자 설명서의 지원 매트릭스는 최신 버전이 아닙니다. 매트릭스에 대한 최신 정보는 이 설명서의 업데이트된 지원 매트릭스에 포함되어 있습니다.
이 절은 2.2.1 릴리스의 새로운 기능을 요약합니다. 이것은 이전 버전의 제품에 익숙한 사용자를 위한 내용입니다.
Sun Control Station 2.2.1은 관리 노드 및 SCS 서버로서 SuSE Enterprise Version 9.0 (SLES 9) 및 SuSE Linux Professional 9.2를 지원합니다. SLES 9 SP 1에 대한 클라이언트/관리 대상 노드를 지원할 수 있습니다. 버전 2.2.1로 관리 대상 노드에 SLES 9, SLES 9 SP1 및 SuSE 9.2를 OS 배포할 수 있습니다. 이러한 플랫폼에 대해 상태 모니터링과 인벤토리를 검색 및 제공하고 소프트웨어를 관리할 수 있습니다.
이 릴리스는 /home 및 /var 분할 영역을 지원합니다. SCS 2.2 GA 릴리스의 HM 모듈에는 세 개의 분할 영역( /, /home, /var)을 모두 모니터하는 하나의 분할 영역 모니터가 있었습니다. 모든 분할 영역이 위험 또는 경고 상태이면 상태 변경을 나타냅니다. SCS 2.2.1의 HM에는 세 개의 분할 영역에 대한 개별 모니터가 있습니다. 이러한 기능은 위험 또는 경고 상태인 특정 분할 영역을 명확하게 지정합니다.
버전 2.2.1에 다음 두 가지 새로운 인벤토리 기능이 추가되었습니다.
많은 소프트웨어 인벤토리 정보를 이동할 수 있도록 "인벤토리 보기" 및 "패치 보기" 페이지에서 특정 RPM, SVR4 패키지 또는 특정 검색 기준을 기반으로 하는 패치를 필터/검색할 수 있습니다.
버전 2.2.1은 소프트웨어 번들의 일반 설치를 지원하는 새로운 주요 기능을 포함하고 있습니다. "업로드" 화면에 네 번째 패키지 유형인 "기타"가 나타납니다. "기타" 유형으로 모든 형식의 단일 파일을 업로드할 수 있습니다. 파일을 업로드하면 패키지 "편집" 화면이 나타납니다. 이 화면에서 패키지 이름, 설명, 버전, 릴리스 및 공급업체를 입력할 수 있습니다. 알 수 없는 유형의 패키지인 경우 필수 정보를 모두 입력해야 합니다.
번들을 설치하는 방법이 포함된 스크립트 파일을 제공해야 합니다. 스크립트 파일은 Bourne 쉘이 설치된 경로인 /bin/sh 아래에서 실행 가능해야 합니다. 일반 번들을 설치하는 경우 스트립트 파일 및 번들 파일은 모두 관리 시스템의 /tmp로 복사됩니다. 스크립트 파일은 플랫폼의 일반적인 패키지 설치 명령인 rpm, pkgadd 또는 patchadd 대신에 단일 인수로서 패키지 파일에 대한 전체 경로와 함께 Bourne 쉘을 사용하여 실행됩니다.
stdout 또는 stderr에 대한 설치의 모든 출력은 단일 문자열로 캡처되고 작업 로그에 표시됩니다. 설치 스크립트에 비제로 값이 있는 경우 설치는 실패한 것으로 간주되고 실패한 작업 상태가 기록되어 표시됩니다.
2.2.1 릴리스는 SVR4 패키지를 설치 제거하는 동안 관리 파일 사용에 대한 지원(명령줄 전용)도 추가합니다. 2.2 릴리스에서처럼 "편집" 화면에서 SVR4 패키지에 대해 관리 파일이 제공될 수 있습니다. 2.2 릴리스에서 관리 파일은 SVR4 패키지를 설치하는 동안 pkgadd 명령을 통해 사용됩니다. 2.2.1 릴리스의 경우 /scs/sbin/swi_pkg_uninstall.pl 스크립트를 통해 SVR4 패키지가 설치 제거되고 -a 옵션이 제공되면 스크립트는 SVR4 패키지에 해당하는 관리 파일을 찾습니다. "편집" 화면에서 관리 파일을 입력하면 pkgrm 명령에 대해 -a 옵션을 사용하는 관리 호스트에서 해당 관리 파일을 사용합니다.
UI를 통한 패키지 설치 제거에서는 기본 관리 파일을 사용하여 비대화형 설치를 진행할 수 있습니다.
이 릴리스는 다음 작업을 수행할 수 있는 LX50/v60/v65x의 새로운 단말기 집중 장치 모듈을 포함하고 있습니다.
SCS 2.2 이전 버전의 SCS 릴리스에서 업그레이드하는 고객을 위해 지원되는 경로는 먼저 v2.2로 업그레이드한 다음 v2.2.1로 업그레이드하는 것입니다.
다음 문제는 SCS 2.2가 설치된 시스템에만 영향을 미칩니다. GA 릴리스는 이미 SCS 2.2 RR이 실행된 시스템에만 패치로 설치됩니다.
|
주 - SCS 2.2 GA 릴리스는 단독 또는 기존에 설치된 SCS 2.2 RR에 대해서만 패치로 설치될 수 있습니다. 기존에 설치된 다른 SCS로 업데이트하거나 패치로 설치될 수 없습니다. |
2004년 12월에 출시된 V20z에는 업데이트된 K2 메인보드가 포함되어 있습니다. 변경된 사항 중 하나는 openipmi 드라이버가 바인드할 KCS 포트의 주소입니다. 이전 (K1) 버전에서 주소가 비표준이면 SCS는 이 대체 포트로 바인드할 사용자 정의 openipmi 드라이버를 설치합니다. K2 메인보드는 온보드 드라이버가 바인드할 표준 포트를 사용하기 때문에 사용자 정의 드라이버를 설치할 필요가 없습니다. 실제로 사용자 정의 드라이버가 작동되지 않습니다. (CR6219875)
새로운 하드웨어가 있는 하나 이상의 시스템을 구입했지만 새로운 보드를 인식하지 못하는 SCS 2.2의 RR 릴리스로 이러한 시스템을 처음으로 관리하려는 경우 사용자 정의 openipmi 드라이버는 LOM 모듈이 호스트에 추가될 때 설치되었을 수 있습니다. 이러한 내용은 호스트에서 실행된 LOM(예: ipmitool) 명령이 실패하여 수동 구성 절차가 실행되면 알 수 있습니다.
SCS 패치(SCS 2.2 GA 릴리스라고도 함)를 추가하는 업그레이드 절차에서는 사용자 정의 openipmi 드라이버를 설치 제거하지 않기 때문에 영향 받은 호스트의 LOM 명령은 계속 실패합니다. 또한 LOM 모듈을 제거하고 다시 설치하거나 호스트를 제거하고 다시 가져오더라도 이 문제를 해결할 수 없습니다. 그러나 K2 호스트에서 사용자 정의 openipmi 드라이버 설치 제거를 수행할 수 있는 보다 간편한 방법이 있습니다.
첫 번째 단계는 SCS 업그레이드가 수행된 다음 호스트가 사용자 정의 드라이버를 설치 제거할 필요가 있는 K2 호스트인지를 결정합니다.
1. 호스트는 LOM 명령을 계속해서 실행할 수 없습니다.
2. 영향 받은 호스트와 관련된 다음 메시지와 유사한 메시지가 /var/log/scs-install.log 파일에 있습니다.
특히 "V20z (개정판 B 이상)" 부분을 주목하십시오. 이 메시지는 LOM이 K2 메인보드가 있는 호스트를 발견했다는 의미입니다.
해결 방법은 이러한 두 가지 조건이 존재하는 경우 영향 받은 호스트에서 사용자 정의 openipmi 드라이버를 수동으로 제거하는 것입니다. 이 작업을 수행하려면 다음 작업을 수행합니다.
1. 영향 받은 호스트에 대해 루트로 단말기 창을 엽니다.
2. 드라이버가 설치되었는지 판별합니다. 이것으로 ipmi 드라이버 관련 문제인지 확인할 수 있습니다.
3. SCS에서 먼저 호스트를 제거해야 합니다. 이 작업을 수행하려면 관리 
호스트 페이지에서 호스트를 선택하고 제거를 선택합니다.
4. 이제 안전하게 관리할 수 있도록 SCS에서 가져온 호스트의 모든 파일을 제거해야 합니다. 루트 사용자의 다음 홈 디렉토리에 있는 hostinstall.pl 스크립트를 사용하여 이 작업을 수행합니다.
# hostinstall.pl 제거
이렇게 하면 SCS가 호스트를 관리할 수 있도록 해주는 SCS 클라이언트측 패키지 및 ssh 키가 제거됩니다.
5. 그런 다음 사용자 정의 openipmi 드라이버 rpm을 제거해야 합니다. 이 작업을 수행하려면 다음을 입력합니다.
# rpm -e openipmi-2.4.21-29
6. 사용자 정의 드라이버가 더 이상 설치되어 있지 않은지 확인합니다.
# rpm -qa | grep openipmi
7. 설치된 ipmitool도 제거해야 합니다. 다음 정보를 입력합니다.
# rpm -qa | grep ipmitool
ipmitool-1.6.0-1.rh3
# rpm -e ipmitool-1.6.0-1.rh3
8. ipmi 드라이버에 의해 설치된 /dev/ipmi0 장치 파일이 있는지 확인합니다.
# ls /dev/ipmi0
# rm /dev/ipmi0
10. 다시 다음 hostinstall.pl 스크립트를 사용하여 클라이언트측 패키지 및 ssh 키를 다시 설치해야 합니다.
# hostinstall.pl install
11. 마지막으로 호스트를 SCS로 다시 가져올 수 있습니다. 새 호스트를 추가하는 방법은 SCS 관리자 설명서에 설명된 절차를 따르십시오.
이 작업을 완료하고 나면 LOM 설명서에 설명된 절차에 따라 SCS LOM 구성을 설정할 수 있습니다.
이 절차를 수행한 후에도 LOM과 관련된 문제가 계속 발생하면 Sun 서비스 담당자에게 지원을 요청하십시오.
SCS 2.2 RR에서 SCS 2.2 GA로 업그레이드한 후에는 자세한 상태 모니터 정보 페이지의 기타 시스템 서비스 절에 있는 LOM 관련 상태 서비스 항목에 대한 실제 데이터 대신 자리 표시자 텍스트가 표시됩니다. (CR6219696)
데이터베이스 스키마 및 포함된 모듈 변경으로 SCS 2.2의 RR 릴리스 버전으로 만든 백업을 GA 릴리스와 함께 사용할 수 없습니다. 이전 버전에서 만든 백업을 복원하려고 하면 잘못된 백업 파일 오류 메시지가 생성됩니다. (CR6218739)
다음 문제는 SCS 2.2 GA/RR에서 SCS 2.2.1로 업그레이드하는 경우에만 발생합니다. 스테이션 설정 활성 모니터 기능(CPU, 디스크, 메모리, http, 텔넷, tomcat, FTP, DNS, SSH, postgres, 전자 메일 및 RAID)에 의해 모니터된 일부 또는 모든 서비스는 더 이상 표시되지 않습니다. (CR6269565)
해결 방법은 제어 스테이션 호스트에서 실행중인 단말기에서 다음 명령을 입력하는 것입니다.
다음 문제는 SCS 2.2 RR 또는 SCS 2.2 GA가 이미 실행 중인 시스템에 대한 패치로 SCS 2.2.1 릴리스가 설치된 시스템의 경우에만 영향을 미칩니다.
SCS 2.2.1 GA 릴리스를 독립 실행형으로 설치하거나 기존 SCS 2.2 RR 또는 GA 설치에 패치로 설치할 수 있습니다. 기존의 다른 SCS 설치에 대한 패치 또는 업데이트로는 설치할 수 없습니다.
2.2 RR 또는 GA에서 업그레이드할 경우 설치하는 동안 다음 정보 메시지가 나타납니다. (CR6239945)
INFO : Uninstalling scs-health-2.2-153 from control station ==>/var/tmp/rpm-tmp 16917: line 3: /scs/bin healthManageServers.pl: No such file or directory |
이것은 무해한 정보 메시지입니다. 2.2.1 릴리스에서 위반 버그가 수정되었기 때문에, 이후 버전으로의 업그레이드에서 이 메시지는 표시되지 않습니다.
2.2 RR 또는 GA에서 업그레이드하면 패키지와 운영 체제 간의 연결이 끊어질 수 있습니다.
해결 방법: 업그레이드 전에 제어 스테이션 상에서 루트로서 다음 명령을 사용하여 연결(swinstaller_pkg_os)을 포함하는 테이블 내용을 백업합니다.
/usr/bin/env PGUSER=mgmt PGPASSWORD=mgmt /usr/bin/pg_dump -p 5434 -t swinstaller_pkg_os mgmt > /tmp/pkgos.bak |
업그레이드 설치가 완료되면 다음 명령을 사용하여 연결을 복원합니다.
/scs/sbin/db_tool.pl load /tmp/pkgos.bak
Netscape 6.2.2는 Sun Control Limited Solaris 10 x86 하드웨어 지원에서 작동하지 않습니다.
SCS 2.2 GA 릴리스는 Solaris 10 x86이 실행 중인 Sun Fire V20z 및 Sun Fire V40z 관리 대상 호스트를 지원합니다. 설명서를 작성하는 당시에는 다른 Solaris 10 x86 관리 대상 호스트를 테스트하지 않았습니다. (CR6213445)
AllStart 및 소프트웨어 설치 프로그램 모듈의 특정 작업에서 큰 파일을 SCS로 업로드해야 합니다. 이러한 작업에서 SCS 진행률 표시줄을 사용하지 않기 때문에 시스템이 잠시 "중단"된 것처럼 보일 수 있습니다.
이런 현상은 SCS 소프트웨어가 아닌 브라우저에서 파일 업로드를 수행하기 때문에 나타납니다. SCS 소프트웨어는 업로드가 완료될 때까지 '대기'해야 합니다. 이런 작업에서는 최악의 경우 수 분이 걸릴 수도 있습니다.
마우스를 움직이면 일시적으로 마우스 커서가 '대기' 상태의 모양으로 표시됩니다. 작업이 완료되었는지 확인하는 가장 좋은 방법은 SCS가 적절한 메시지 또는 페이지를 표시할 때까지 기다리는 것입니다. (CR6214326, CR6219228)
활성 모니터가 SuSE Linux 시스템에서 FTP 서비스를 적절하게 모니터하지 않는 현상은 /etc/xinetd.d/vsftpd 구성 파일에 FTP가 활성 또는 비활성인지를 지정하는 행이 없을 때 발생할 수 있습니다. 그러한 경우 FTP 서비스는 활성 모니터에 회색으로 표시됩니다. (CR6204715)
이 문제를 해결하려면 /etc/xinetd.d/vsftpd 구성 파일에 다음 행 중 하나를 추가합니다.
네트워크 문제, 호스트 고장 또는 클라이언트측 소프트웨어 구성 요소 제거로 인해 Control Station에서 관리하는 호스트에 접근할 수 없는 경우에는 Control Station을 사용해 해당 호스트에서 모듈을 설치하거나 제거할 수 없게 됩니다.
모듈을 설치하지 못한 경우 SCS에서 "호스트에 모듈 이름을 설치하지 못했습니다."라는 일반 오류 메시지가 나타납니다. "제어 모듈" 페이지의 실패 횟수와 호스트에 대한 "제어 모듈 설치 보고서"는 제대로 업데이트되지 않았습니다.
모듈을 제거하지 못한 경우 적절한 오류 메시지가 나타납니다. 그러나 "제어 모듈" 및 "제어 모듈 설치 보고서" 테이블이 설치 제거된 모듈을 잘못 반영하기도 합니다. (CR6220242)
2. 설치 제거되지 않고 남아 있는 모듈 구성 요소를 제거합니다.
# /usr/mgmt/sbin/hostinstall.pl remove
3. Sun Control Station 2.2 소프트웨어 설치 설명서에 설명된 대로 호스트의 클라이언트측 관리 구성 요소를 다시 설치합니다..
4. 관리 호스트에서 적절한 명령을 사용하여 해당 호스트를 제거한 다음 다시 추가합니다.
제어 스테이션의 IP 주소가 변경되면 시스템이 불안정하게 됩니다. hostinstall.pl 스크립트를 사용할 수 없습니다. hostinstall.pl은 단일 사용 전용입니다. (CR6191532)
해결 방법은 관리 대상 호스트에서 hostinstall.pl의 모든 사본을 제거하는 것입니다. hostinstall.pl의 새 사본을 관리 대상 호스트로 전송하여 새 Control Station 주소에 대한 클라이언트 지원을 제거하고 다시 설치하는 데 사용합니다. 상태 모니터링 모듈을 사용하는 모든 관리 대상 호스트를 다시 관리해야 합니다.
Control Station의 IP 주소가 변경되면 다음 단계를 수행합니다.
1. 관리 대상 호스트에서 hostinstall.pl을 제거합니다.
2. Control Station에서 루트로 다음 명령을 입력합니다.
# /scs/sbin/updateIP.sh
이 명령은 다음에서 액세스할 수 있는 hostinstall.pl의 새로운 사본을 제어 스테이션에서 생성합니다.
http://<controlstation>/pub/hostinstall.pl
3. hostinstall.pl의 새로 만든 복사본을 관리 대상 호스트로 전송합니다.
hostinstall.pl의 새로운 복사본을 사용하여 새 제어 스테이션 주소에 대한 클라이언트 지원을 제거하고 다시 설치합니다.
4. 상태 모니터링 모듈을 사용하고 있는 모든 호스트를 다시 관리합니다.
각 호스트를 삭제한 다음 각 호스트를 다시 추가합니다. 자세한 지침은 Sun Control Station 2.2 관리자 설명서를 참조하십시오.
기본적으로 hostinstall.pl은 Control Station의 호스트 이름 및 각 Control Station의 구성 IP 주소를 사용하여 HTTP를 통해 제어 스테이션에 연결을 시도합니다. hostinstall.pl 스크립트는 연결되기까지 3분 동안 대기하면서 각 주소에 차례대로 연결을 시도합니다.
예를 들어 관리 대상 호스트가 개인 서브넷에 있는 환경에서처럼 관리 대상 호스트에서 주소에 접근할 수 없으면 hostinstall.pl을 실행하는 동안 예기치 못한 지연이 발생할 수 있습니다.
해결 방법: Control Station 연결에 가장 좋은 주소를 이미 알고 있는 경우 관리자는 다음과 같이 hostinstall.pl의 -c 스위치에 대한 명령줄 인수로 Control Station 주소를 명시적으로 제공함으로써 지연을 피할 수 있습니다.
# ./hostinstall.pl -c 192.168.1.1 install
이렇게 하면 hostinstall.pl이 IP 주소 192.168.1.1로 Control Station 연결을 처음으로 시도한 후에 스크립트의 부분으로 자동 구성된 주소를 사용하여 다음으로 진행합니다. (CR6199090)
BIOS를 항상 네트워크에서 부트하도록 설정한 경우 Sun Fire V20z가 제대로 작동하지 않습니다. 시스템이 부트를 시도할 때 호스트의 콘솔에 다음과 같은 오류 메시지가 나타납니다.
해결 방법: 키보드, 직렬 포트 또는 직렬 LAN을 통한 수동 네트워크 부트를 사용하여 OS 관리를 시작합니다. (CR6216832)
SCS 제어 스테이션에서 X Windows 세션을 로컬로 실행하지 마십시오. 그렇게 하면 CPU 및 메모리 자원을 소비하여 SCS의 성능이 현저히 떨어집니다. (CR6218255)
Sun Control Station 소프트웨어는 모듈 설치 또는 파일 백업과 같은 일부 핵심 작업을 수행한 후 제어 스테이션의 /var/tomcat4/temp 디렉토리를 정리하지 못했습니다. (CR6221622)
이 문제로 인한 증상으로 극단적인 경우 /var 파일 시스템이 꽉 찰 수 있습니다.
소프트웨어 설치 프로그램 및 AllStart 작업 후 파일이 남지 않았습니다. 해결 방법은 모든 보류 중인 작업을 완료한 다음 /var/tomcat4/temp 디렉토리에서 관련 없는 모든 파일을 제거하는 것입니다.
다음 문제는 Redhat 3 업데이트 3 이상 및 Redhat 2.1 업데이트 4 이상에서 실행되는 SCS 2.2의 현지화된 버전(영어 아님)에서만 발생합니다.
일부 작업을 수행하면 이상한 문자가 나타날 수 있습니다. (CR6220205). 해결 방법은 SCS 서버 명령줄에서 다음을 수행하는 것입니다.
1. /etc/sysconfig/i18n 파일을 편집합니다.
LANG을 UTF-8 문자 집합 인코딩 중 하나로 변경합니다. 예를 들어 파일을 편집한 다음 파일은 다음과 유사한 행을 포함해야 합니다.
LANG="en_US.UTF-8"
2. Tomcat 서버를 다시 시작합니다. 다음과 같이 입력합니다.
% /etc/rc.d/init.d/init.agent restart
다음 문제는 SCS 2.2의 현지화된 버전(영어 아님)을 Redhat 3 업데이트 3 이상 및 Redhat2.1 업데이트 4 이상에서 실행하는 경우에만 발생합니다.
텍스트 필드에 더블 바이트 문자를 입력할 때 이상한 문자가 표시될 수 있습니다. (CR6216758). 해결 방법은 ASCII 문자만 텍스트 필드로 입력하는 것입니다.
다음 문제는 현지화된 버전(영어 아님)을 SuSE 9.0에서 실행하는 경우에만 발생합니다.
상태 모니터, AllStart, 및 소프트웨어 설치 프로그램 모듈에서 일부 작업을 수행한 경우 작업 진행 창에 이상한 문자가 나타날 수 있습니다. (CR6221654). 해결 방법은 영어 로켈을 사용하여 서버에 로그인 하거나 SCS 서버에 Red Hat OS를 설치하는 것입니다.
진행률 표시줄이 표시된 UI에서 작업을 실행한 다음 바로 "백그라운드에서 작업 실행" 단추를 선택하면 오류 페이지가 나타납니다. (CR 6191921).
해결 방법은 잠시(1~2초) 기다린 후 백그라운드에서 작업을 실행하는 것입니다.
SCS에서 이미 관리되고 있는 호스트를 호스트 페이지의 스캔에서 지정하면 호스트의 반환되는 정보 및 반환될 진단 메시지가 표시되지 않습니다. (CR 6248259).
이러한 동작이 감지되면 호스트 페이지를 확인하여 해당 호스트가 이미 관리되고 있는지 확인합니다.
특수 문자(영숫자 아님)로 그룹을 만들면 특정 시나리오에서 문제가 발생할 수 있습니다. 이름에 "%" 또는 "&"와 같은 문자를 포함한 그룹을 만들고 "새 그룹에 추가할 호스트 선택" 확인란을 선택하면 오류 페이지가 표시되거나 어떤 경우에는 그룹을 만들 수 없습니다. (CR 6265577).
해결 방법은 그룹을 만들 때 "새 그룹에 추가할 호스트 선택" 확인란을 선택하지 않고 그룹을 만든 다음 호스트를 추가하는 것입니다.
AllStart 소프트웨어는 Red Hat EL 2.1 ASu2 운영 체제를 실행하는 클라이언트를 빌드할 수 없습니다. 이것은 HTTP 1.1 청크로 인해 발생하는 오류입니다. 이것은 잘 알려진 Red Hat 문제입니다(Red Hat 버그 ID 9748 참조). (CR6189029)
Sun Control Station 웹 서버는 청크된 HTTP 1.1 응답으로 클라이언트의 HTTP 요청에 응답하고 로더는 이 응답을 이해하지 못합니다. 가비지 문자가 클라이언트의 /tmp/ks.cfg 파일 끝에 추가됩니다. Anaconda가 이러한 문자를 판독하지 못하여 설치가 중단됩니다. (CR6189029)
해결 방법은 1.0에 대한 강제 응답으로 문제를 해결하는 것입니다. 그러나 이 방법을 사용하면 예기치 못한 이벤트가 발생할 위험이 있습니다. 1.0에 대해 강제로 응답하려면 다음을 수행합니다.
1. /etc/tomcat4/httpd.conf 파일에 다음 행을 추가합니다.
BrowserMatch .* downgrade-1.0 force-response-1.0
2. httpd를 다시 시작합니다. 다음과 같이 입력합니다.
/scs/etc/init.d/init.scs-httpd restart
Red Hat Advanced Server 2.1로 시스템을 준비하는 경우 Sun Fire V20z 및 Sun Fire V40z 서버에 대해서는 현재 지원되지 않습니다. 그러나 위험을 감수하더라도 구축하려는 경우에는 다음 단계를 수행하십시오.
1. AllStart 사용자 인터페이스를 사용하여 AS 2.1 배포를 추가합니다.
/scs/sbin/as_distro.pl -l
4. 사용자 인터페이스를 사용하여 만든 배포 ID를 찾습니다. 다음과 같이 입력합니다.
DISTRO_ID: 17 DISTRO NAME: RHEL2.1 AS U3 OS_ID: 6
cd /tftpboot/DISTRO_ID/
mv initrd.img initrd.img_BAK
cp -f initrd-everything.img initrd.img
8. Red Hat AS 2.1 클라이언트를 만듭니다.
RedHat Advanced Server 2.1 시스템에서 실행되는 SCS 2.2 Control Station은 Solaris 9 또는 Solaris 10 시스템 관리를 위해 AllStart를 사용하려고 시도하는 경우 중단될 수 있습니다. (CR6215968)
해결 방법은 Control Station의 운영 체제를 RH2.1 AS 업데이트 5 이상으로 업데이트하는 것입니다. 이렇게 하면 Redhat 초기 버전에서 발견된 NFS 문제로 인해 발생된 문제를 해결할 수 있습니다.
AllStart 프로필에는 '설치 후 시스템 재부트' 옵션이 포함되어 있습니다.
Solaris SPARC 시스템을 준비하는 경우 JumpStart가 이 옵션의 설정과 관계없이 설치 후 시스템을 재부트합니다. 이런 경우에는 해결 방법이 없습니다. (CR6214903)
AllStart의 "원격 위치에서 파일 추가" 기능을 사용하여 250MB보다 큰 파일을 추가하는 경우 문제가 발생합니다. Struts 프레임워크에서 업로드하는 파일의 기본 최대 크기는 250MB입니다. (CR6199038)
1. 크기가 250 MB 이상인 파일을 Control Station의
/scs/data/allstart/iso 디렉토리에 수동으로 업로드합니다.
2. Allstart 파일 파일 추가 기능을 사용하여 파일을 추가합니다.
자세한 내용은 Sun Control Station2.2 AllStart 모듈을 참조하십시오.
AllStart 모듈은 매우 제한된 RAID 구성 검증을 수행합니다. AllStart 내에서 만든 RAID 구성을 SuSE와 같은 운영 체제 공급업체에서 반드시 지원하지는 않습니다.
SuSE RAID 1 및 RAID 5 프로필에는 알려진 문제가 있습니다. SuSE RAID 1 및 RAID 5 프로필이 실패하여 grub 설치 오류가 발생했습니다. (CR6181315)
해결 방법은 특정 정보에 대해 운영 체제 소프트웨어에 포함된 공급업체 설명서를 참조하는 것입니다.
재부트 시 구축을 시작하도록 클라이언트 부트 로더가 수정되었으므로 관리 대상 호스트는 자동으로 활성화됩니다. DHCP를 사용하여 클라이언트를 PXE/netboot하려면 AllStart 클라이언트 테이블에서 클라이언트를 선택한 다음 활성화 버튼을 클릭하여 클라이언트를 수동으로 다시 활성화해야 합니다. (CR6193165)
NFS v2 문제로 인해 SCS 서버가 Red Hat EL3 또는 SuSE 9 운영 체제를 실행하는 경우 AllStart가 Solaris 9 x86 또는 SPARC 클라이언트를 관리할 수 없습니다. Sun Control Station 서버로 Redhat EL 3 또는 SuSE 9를 실행하고 Solaris 9 또는 SPARC x86 클라이언트를 빌드하려는 경우 "vanilla" Linux 커널을 실행해야 합니다. (CR6180789])
1. Red Hat 2.1 또는 Fedora Core 1을 실행합니다.
2. "vanilla" Linux 커널을 컴파일하여 SuSE9 및 Red Hat EL3을 위한 Red Hat 커널로 바꿉니다.
이 커널은 ftp.kernel.org에서 다운로드할 수 있습니다.
AllStart 모듈을 사용하여 여러 Solaris 클라이언트를 구축하는 경우 오류 메시지가 표시될 수 있습니다. 준비 프로세스 동안 시스템이 중지되고 수동 입력을 위한 프롬프트가 표시됩니다. AllStart 클라이언트를 활성화할때 오류 메시지가 표시될 수도 있습니다. (CR6223268)
해결 방법은 rules.ok 파일에서 누락된 Solaris 항목을 추적하는 것입니다. AllStart 클라이언트 화면에서 모든 클라이언트를 비활성화한 다음 다시 활성화합니다. AllStart는 자동으로 rules.ok 파일을 생성합니다.
Fedora Core 3에서 수정된 RedHat버그로 인해 Fedora Core 2로 Sun Fire V20z 또는 Sun Fire V40z 시스템 관리는 지원되지 않습니다.
해결 방법은 Fedora Core 3으로 Sun Fire V20z 또는 Sun Fire V40z 시스템을 준비하는 것입니다.
OS가 v60/v65x에 대해 SLES 9를 준비하는 경우 다음 문제에 대해 알고 있어야 합니다. (CR6233968)
이 절에서는 Red Hat EL3 또는 SuSE Linux Professional 9 서버에서 실행되는 SCS 서버에서 SPARC 또는 x86 클라이언트에 대해 OS 관리를 가능하도록 NFSv2 패치로 Solaris 9 배포를 패치하는 방법에 대해 설명합니다. (CR6180789)
RedHat 3.0 시스템에 대해 Solaris 9 시스템에서 nfs 마운트 문제 때문에 SCS 2.2를 사용하여 패치를 배포의 미니루트에 처음 적용하지 않은 SPARC 또는 x86 시스템에 Solaris 9 이미지를 배포할 수 없게 됩니다.
그렇게 하려면 패치된 Solaris 9, x86/SPARC와 같은 사용 가능한 시스템이 있어 RedHat 3.0 SCS 서버를 마운트할 수 있어야 합니다. SCS 서버를 Solaris 9 시스템에서 마운트한 다음 SCS 서버에 상주하고 있는 Solaris 9 배포에서 동일한 패치를 실행합니다.
필요한 패치는 x86에 대한 117172-17 및 117468-02입니다. SunSolve에 SPARC 시스템을 위한 유사한 패치가 있습니다. SunSolve에서 이러한 패치의 최신 버전을 확인하려면 다음 링크를 사용하십시오.
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
2. sunsolve에서 패치 압축 파일을 가져옵니다.
6. reboot -- -s를 사용하여 단일 사용자 모드로 Solaris 시스템을 재부팅합니다.
10. ^d를 입력하면 다중 사용자 모드로 복원됩니다.
네트워크의 모든 SCS 서버에서 이 Solaris 9 시스템을 사용하여 Solaris 9 배포를 패치할 수 있습니다.
RedHat 3.0 시스템에서 다음 단계를 수행합니다.
2. /scs/sbin/as_distro.pl -l을 실행하고 Solaris 9의 DISTRO_ID를 기록합니다.
3. vi /etc/exports 및 /js *(ro,no_root_squash)를 /js *(rw,no_root_squash)로 변경합니다.
4. /etc/init.d/nfs restart를 실행합니다.
Solaris 9 시스템으로 돌아가서 RedHat 시스템에 배포를 패치합니다. 2단계에서 부분적으로 설치에 실패할 수 있습니다. patchadd 명령으로 SUNWos86r 패키지를 확인할 때 이전 단계에서 bootenv.rc 링크가 제거되어 오류가 발생할 수 있습니다. 이전 절차의 4단계에서 링크를 다시 만듭니다. 이러한 오류만 발생한 경우 패치는 완료되어야 합니다.
1. mount -o rw <RH30 machine ip>:/js/<distro_id> /mnt
2. patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117172-17
3. patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117468-02
RedHat 3.0 시스템에서 다음 단계를 다시 수행합니다.
1. vi /etc/exports 및 /js *(rw,no_root_squash)를 /js *(ro,no_root_squash)로 변경합니다.
2. /etc/init.d/nfs restart를 실행합니다.
3. cd /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris
4. ln -s ../../tmp/root/boot/solaris/bootenv.rc
이제 Solaris 9를 서버에 배포할 수 있어야 합니다. 다른 배포를 패치하려면 /patch/117172-17 디렉토리를 삭제하고 117172-17의 압축을 풀어 해당 디렉토리를 다시 만듭니다. 첫 배포를 패치하면 patchadd는 다음 patchadd에서 문제를 일으킬 수 있는 디렉토리의 내용을 변경합니다.
|
주 - 패치한 배포는 미니루트가 패치되었기 때문에 배포될 수 있습니다. 배포한 OS는 원래 배포와 동일한 버전입니다. 새로 배포된 OS에 대해 Redhat 디렉토리를 원격으로 마운트하려면 새로 배포된 OS를 패치해야 합니다. |
이 절에서는 Solaris 9를 패치하여 V20z에서 K2.0 메인보드로 OS가 S9를 준비하는 방법에 대해 설명합니다. (CR6243352, CR6240419)
V20z용 K2.0 메인보드는 Broadcom의 5704 NIC 카드를 사용하지만 Solaris 9에는 이 카드를 지원하는 드라이버가 없습니다. 패치를 사용하여 해당 드라이버를 추가해야 합니다. 드라이버를 추가하는 절차는 다음과 같습니다.
이전 절에서 설명한 것처럼 배포 ID가 <distro_id>인 mkdir /js/<distro_id>/patch 디렉토리입니다.
2. SunSolve에서 이 디렉토리로 11666-04 패치를 다운로드합니다.
3. 패치 압축 풀기: unzip 116666-04.zip
4. 예를 들어 /js/scripts 디렉토리에 다음 세 행을 포함하고 있는 patch_sol9_k2.sh와 같은 스크립트를 만듭니다. 이 스크립트는 종료 스크립트의 한 부분으로 설치의 마지막 단계에서 실행됩니다.
5. UI를 사용하여 다음 단계에서 사용자 정의 스크립트로 Solaris 9 배포에 대해 사용할 OSprofile에 스크립트를 추가합니다.
/js/scripts/patch_sol9_k2.sh
6. 클라이언트를 활성화하면 설치의 끝 단계에 실행되는 patchadd 명령이 나타납니다.
Allstart를 사용하여 SPARC가 제대로 netboot되었는지 확인하려면 boot net:dhcp - install을 사용합니다. 그렇지 않으면 - install 매개 변수가 없는 경우 빌드에 실패하게 됩니다.
Allstart 설명서에 solaris 가져오기에 대한 XML 예제가 없습니다. (CR 6245169). 다음은 예제입니다.
패키지 종속 데이터는 자동으로 생성되지 않습니다. 패키지를 업로드하고 "편집" 화면에서 패키지와 운영 체제를 연결한 다음 주 화면에서 패키지를 선택하고 "종속성 추가"를 클릭합니다 저장소에 업로드한 다른 패키지에서만 종속성을 정의할 수 있습니다.
설치하려고 패키지를 선택하고 해당 패키지에 대해 종속성이 정의된 경우 설치 시 해당 패키지를 포함할 것인지 확인하는 메시지가 표시됩니다. 패키지는 종속성과 호환되는 순서에 따라 설치됩니다. 종속성의 여러 수준이 포함됩니다.
CR 6245216을 수정하려면 응답 및 관리 파일을 웹사이트에 게시해야 합니다. 다음 URL에 응답 파일에 대한 자세한 설명이 있습니다.
http://docs.sun.com/app/docs/doc/816-0211/6m6nc6735?a=view
다음 URL에 관리 파일에 대한 자세한 설명이 있습니다.
http://docs.sun.com/app/docs/doc/816-0219/6m6njqb69?a=view
관리 파일을 제공할 수 없으면 기본 파일이 사용됩니다. 기본 파일에는 다음 값이 포함됩니다.
mail= instance=unique partial=quit runlevel=quit idepend=quit rdepend=quit space=quit setuid=nocheck conflict=quit action=nocheck basedir=default |
소프트웨어 설치 프로그램 모듈과 함께 프록시 사용을 중지하면 RPM을 업로드하기 전에 Tomcat 웹 서버를 다시 시작해야 합니다. (CR6201371) 다음을 수행하십시오.
3. Tomcat 웹 서버를 다시 시작하고 다음을 입력합니다.
# /scs/etc/init.d/init.scs-tomcat4 restart
RPM 업로드에 대한 자세한 정보는 Sun Control Station 2.2 설치 프로그램 모듈 을 참조하십시오.
LDAP/NIS를 실행하는 Redhat 클라이언트는 모듈을 설치할 수 없고 설치하는 동안 다음 오류가 발생합니다.
0 INFO : - Running pkgMgr with mode "lock check"1 ERROR : Failed to run package manager
이것은 Redhat 버그인 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=69236 때문에 발생하는 오류입니다. 해결 방법은 클라이언트에서 nscd를 시작하는 것입니다.
다음 명령을 사용하면 nscd를 제대로 시작할 수 있습니다. 영향 받은 각 클라이언트에서 명령을 실행합니다.
# chkconfig nscd on
/etc/init.d/tomcat4 start
SCS 관리 서버를 설치하려면 SuSE 9.1/9.2는 insserv 업데이트가 필요합니다. (CR6263297) . SuSE 9.2에는 SCS 설치에 실패하여 다음 메시지를 표시하는 버그가 /sbin/insserv 프로그램에 있습니다.
해결 방법은 이 문제를 수정하여 SCS 설치가 정상적으로 진행되는 insserv의 최신 버전으로 업데이트하는 것입니다.
32 비트 x86 시스템용 insserv 패키지는 SuSE YAST 도구를 통해 다운로드되어 설치되거나 다음 웹사이트에서 수동으로 다운로드하여 설치할 수 있습니다.
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/insserv-1.00.5-6.2.i586.rpm
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/insserv.rpm
다음 사이트에서 4 비트 x64 시스템용 버전을 다운로드할 수 있습니다.
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/x86_64/insserv-1.00.5-6.2.x86_64.rpm
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/x86_64/insserv.rp
SuSE 9.2 Linux Professional에는 atftp 및 tftp라는 두 가지 종류의 tftp 서버가 있습니다. SCS 2.2.1을 설치하려면 tftp가 설치되어 있어야 합니다. 해결 방법은 atftp를 설치 제거하고 tftp를 대신 사용하는 것입니다.
SLES9 플랫폼용 perl-DBD-Pg 모듈의 사용 가능한 버전이 없습니다. (CR 6253727). 이러한 모듈은 postgres와 상호 작용할 수 있는 perl 스크립트에 필요합니다. 해결 방법은 Perl 5.8.3을 사용하고 SLES 9에서 작동하는 SuSE Pro 9.1용 DBD-Pg RPM을 사용하는 것입니다. 다음 위치에서 이러한 모듈을 다운로드할 수 있습니다.
ftp://ftp.suse.com/pub/suse/i386/9.1/suse/i386/perl-DBD-Pg-1.22-194.i586.rpm
ftp://ftp.suse.com/pub/suse/x86_64/9.1/suse/x86_64/perl-DBD-Pg-1.22-170.x86_64.rpm
SCS 2.2.1는 1.4.2_03 이전 버전에 대해서만 테스트되었습니다. RPM 형식으로 설치된 1.4.2_03 이상의 JDK 버전이 있으면 SCS 설치에 실패합니다(CR 6252903). 해결 방법은 다음과 같습니다.
2. java.sun.com으로 이동하여 tgz 형식의 원하는 JDK 버전을 다운로드합니다.
4. tgz 형식으로 원하는 버전의 JDK를 설치합니다.
이제 특정 디렉토리에 설치된 새로운 JDK 버전으로 동일한 시스템에서 SCS 2.2.1를 실행시킬 수 있어야 합니다.
LOM은 Sun Fire V20z 서버에 대해 openipmi 드라이버 대신 imb 드라이버를 사용하려고 합니다. AS 2.1를 실행 중인 Sun Fire V20z에서는 LOM 설치를 지원하지 않습니다. (CR6196687)
LOM 모듈은 SLES 9, SLES 9 SP1 및 SuSE Pro 9.2에서 실행 중인 V20z 'K1' 시스템에서 작동하지 않습니다. 이 문제는 관련 openipmi 드라어버 로드에 실패했기 때문입니다. 해결 방법은 openimpi 드라이버를 다시 로드하는 것입니다.
2005년 1월 11일 이전에 제공된 모든 V20z 시스템은 'K1' 메인보드를 사용할 수 있고 다음과 같이 식별됩니다.
이 날짜 이전에 제공된 시스템은 'K2' 또는 'K2.5' 메인보드를 사용합니다. 'L'(예: A55-NWB1-1-1GRA5L)로 끝나는 표준 구성은 'K2' 메인보드를 사용합니다. (CR 6254983)
Sun Fire V20z 및 Sun Fire V40z 시스템에서 실행 중인 LOM에만 적용됩니다.
Sun Fire V20z 및 Sun Fire V40z 시스템의 시스템 이벤트 로그(SEL) 이벤트가 타임스탬프 레이블을 "Pre-init Timestamp"로 표시하는 경우가 있습니다. LOM은 이러한 타임스탬프를 Unix 이진 시간인 "1970-01-01 00:00:00"으로 해석합니다.
LOM 레코드가 이러한 타임스탬프와 함께 나타난다고해서 시스템에 "문제가 있음"을 나타내는 것은 아닙니다. (CR6213992)
이 문제는 CPU의 전체 보충량이 부족한 Sun Fire V20z 및 Sun Fire V40z의 일부 구성에서 발생할 수 있습니다.
이러한 시스템에는 존재하지 않는 CPU를 "모니터" 하는 활성 센서가 있기 때문에 이러한 센서는 ipmitool의 범위 밖의 값을 반환할 수 있으며 LOM이 이것을 "적색" 또는 "위험"으로 해석합니다. (CR6219901)
해결 방법은 센서 이름을 확인하여 어떤 센서가 모니터되고 있는지 확인한 다음 영향 받은 호스트에 대한 인벤토리 모듈의 하드웨어 인벤토리를 확인하여 "위험" 값이 실제 CPU 또는 가짜 CPU와 관련된 것인지 확인하는 것입니다. 센서가 표시한 CPU가 실제로 존재하지 않는 경우 범위 밖의 값은 무시될 수 있습니다.
LOM 모듈은 관리 대상 Solaris 호스트의 하드웨어 유형 레이블을 v20z로 항상 잘못 지정합니다. 이 문제는 레이블 지정 시에만 발생하는 오류로 LOM 기능에는 영향을 미치지 않습니다. LOM 화면에서만 발생하며 LOM이 아닌 SCS 디스플레이에서는 발생하지 않습니다. (CR6221467)
이 문제(CR 6262425)에 대한 해결 방법은 SCS에서 SuSE 9.2 Linux Professional 시스템을 관리하도록 해당 시스템에서 방화벽을 사용하지 않는 것입니다.
다음 각 시스템에서 쉘 스크립트를 수동으로 실행하여 SuSE 9.2 linux professional에서 방화벽을 사용하지 않을 수 있습니다.
이 스크립트를 사후 설치 사용자 정의 스크립트로 Allstart의 SuSE 9.2 프로필에 추가할 수도 있습니다. 사용자 정의 스크립트를 추가하는 방법에 대한 자세한 내용은 Allstart 설명서를 참조하십시오.
이 문제는 여러 네트워크 인터페이스로 SPARC 및 x86 관리 대상 호스트를 모니터링하는 경우에만 발생합니다.
이러한 경우 하드웨어 인벤토리가 호스트의 모든 네트워크 인터페이스에 대한 올바른 정보를 표시한다고 신뢰할 수 없습니다. 일부 인터페이스를 누락하거나 다른 인터페이스를 잘못된 데이터와 함께 표시할 수 있습니다. (CR6221086)
하드웨어 인벤토리의 파일 시스템 정보에 대한 자세한 해석에 대한 내용입니다. (CR 6248981). 예를 들어 파일 시스템 정보의 유형 열에 1382369651 번호가 표시되면 16진수 변환은 기본 파일 시스템의 유형이 REISERFS_SUPER_MAGIC임을 표시합니다. 다음은 16진수 값이 있는 공통 파일 시스템 유형 목록입니다.
Tot Blks는 파일 시스템 유형에서 사용 할 수 있는 총 블록 수입니다. 블록의 기본 크기는 사용 중인 시스템에 따라 달라집니다. 일반적으로 대부분의 Sun 시스템에서 블록의 크기는 lK입니다.
Free Blks는 파일 시스템에서 사용할 수 있는 사용 가능한 블록 수 입니다. 다음 수식을 사용하여 정확한 공간(%)을 계산합니다.
[( Tot Blks - Free Blks ) / Tot Blks ] * 100
다음 수식으로 사용 가능한 정확한 공간(%)을 계산합니다.
[ (Free Blks)/Tot Blks ] * 100
NSU Blks는 수퍼유저가 아닌 사용자가 사용할 수 있는 블록 수입니다.
File Len은 이 파일 시스템에서 사용 가능한 파일 이름의 최대 길이입니다.
|
x86 및 x86_64용 SuSE Linux Professional 9.0, 9.2, x86 및 x86_64용 SLES 9 |
|
x86용 7.3, 8.0, 9, x86용 EL 2.1 WS/AS/ES, x86 및 x86_64용 EL 3 WS/AS, x86용 EL 3 ES |
|
|
x86 및 x86_64용 SuSE linux professional 9.0, 9.2, x86 및 x86_64용 SLES 9, SP 1 |
|
Sun Control Station 2.2 GA 릴리스는 Sun Control Station 2.2 소프트웨어 설치 프로그램 모듈 설명서에서 미처 고려하지 못했던 주요 새로운 소프트웨어 설치 프로그램 모듈 기능을 포함하고 있습니다. 이 절의 내용은 해당 설명서의 1-12 페이지를 대체합니다.
이 절에서는 Sun
Control Station(SCS) 소프트웨어의 일부인 소프트웨어 설치 프로그램 제어 모듈로 사용 가능한 기능 및 서비스에 대해 설명합니다. 이 모듈을 사용하면 다음 작업을 수행할 수 있습니다.
필터 기능을 사용하여 확인한 다음 조작하려는 패키지 파일 유형을 줄일 수 있습니다.
|
주 - 이 설명서에서는 사용자가 Sun Control Station(SCS) 소프트웨어의 기본 작업을 이해한다고 가정합니다. 상태 아이콘, 스케줄러 및 작업 진행 대화 상자와 같은 기본적인 SCS 기능에 대한 소개는 Sun Control Station 2.2 관리자 설명서를 참조하십시오. |
Sun Control Station에 로그인한 다음 소프트웨어 설치 프로그램 패키지를 누르면 다음 창이 열립니다.
이 설명서에서 패키지 파일이라는 용어는 다음을 의미합니다.
소프트웨어 패치
다음 절에서는 소프트웨어 설치 프로그램 모듈로 수행할 수 있는 기능에 대해 설명합니다.
업로드 기능을 사용하면 로컬 저장소 또는 인터넷에서 제어 스테이션으로 패키지 파일을 로드할 수 있습니다.
세부 정보 기능을 사용하면 이름, 버전, 릴리스, 공급업체, 파일 이름, 패키지 파일 요약과 설명, 기타 관련 패키지 파일 정보와 같은 패키지 파일에 대한 특정 정보를 볼 수 있습니다.
편집 기능을 사용하면 단일 패키지 파일에 대한 지원 운영 체제를 추가 및 제거할 수 있습니다.
편집 기능과 유사한 OS 다시 연결 기능을 사용하면 여러 패키지 파일에 대한 지원 운영 체제를 추가 및 제거할 수 있습니다.
삭제 기능을 사용하면 사용 가능한 패키지 파일 목록에서 패키지 파일을 제거할 수 있습니다. 패키지 파일이 제어 스테이션의 로컬 저장소에 있으면 해당 패키지 파일 항목이 사용 가능한 패키지 파일 목록에서 제거되고 패키지 파일이 저장소에서 삭제됩니다.
설치 기능을 사용하면 선택한 호스트에 패키지 파일을 설치할 수 있습니다. 패키지 파일은 로컬 저장소에서 관리 대상 호스트로 복사된 다음 설치됩니다.
패키지 파일을 설치하기 전에 설치를 테스트할 수 있습니다. 제어 스테이션은 올바른 .rpm을 확인하기 위해 예비 테스트를 실시하고 패키지 파일의 이전 설치 여부와 다른 일반 오류를 확인합니다. 설치 테스트 옵션은 .rpm 패키지 파일에만 사용할 수 있으며 다른 패키지 파일과 함께 사용할 수 없습니다.
종속성 추가 기능은 현재 정의되지 않은 동일한 유형의 모든 패키지 파일을 선택한 패키지 파일로 사용 가능한 패키지 목록 창에 표시합니다. 종속성을 추가하려면 여러 패키지 파일이 아니라 단일 패키지 파일을 선택해야 합니다.
종속성 제거 기능은 선택한 파일에 종속된 패키지 파일로 추가된 모든 패키지 파일을 특정 순서대로 표시합니다. 종속성을 제거하려면 여러 패키지 파일이 아니라 단일 패키지 파일을 선택해야 합니다. 이 옵션을 사용하면 종속성을 다시 정렬할 수 있습니다.
사용 가능한 패키지 목록 창에 제품 이름에 알려진 모든 소프트웨어 패키지가 표시되고 로컬 저장소의 패키지 파일을 관리할 수 있습니다. 소프트웨어 패키지는 Control Station에 로컬로 저장됩니다.
다음 그림에는 소프트웨어 설치 프로그램 창의 패키지 패키지 부분에서 사용 가능한 패키지 목록 옵션이 표시됩니다.
3. 파일 유형 드롭다운 메뉴에서 RPM, SVR4, 패치 또는 기타 항목을 선택합니다.
4. 라디오 버튼 중 하나를 누른 다음 패키지 파일의 위치를 입력합니다.
|
주 - Control Station에서 프록시를 통해 인터넷에 액세스하는 경우에는 스테이션 설정 |
파일을 업로드하는 동안 작업 진행 대화 상자가 나타납니다.
6. 설치한 패키지에 대해 지원되는 운영 체제 및 기타 정보를 입력합니다. 자세한 내용은 README 파일의 소프트웨어 설치 프로그램 모듈 절을 참조하십시오.
7. 업로드가 완료되면 완료 또는 이벤트 보기를 누릅니다.
완료를 누르면 설치한 패키지 파일에 대해 지원되는 운영 체제를 입력할 수 있는 패키지 정보 편집 창으로 이동합니다.
사용 가능한 패키지 파일의 세부 정보를 보려면 다음을 수행합니다.
2. 사용 가능한 패키지 파일 목록에서 사용하려는 패키지 파일을 선택합니다.
선택한 패키지 파일에 대한 정보를 표시하는 세부 패키지 정보 창이 나타납니다. 표시된 정보는 선택한 패키지 파일 유형에 따라 다릅니다.
4. 사용 가능한 패키지 목록 창으로 돌아가려면 완료를 누릅니다.
단일 패키지 파일에 대해 지원되는 운영 체제를 추가 또는 제거하려면 다음을 수행합니다.
2. 사용 가능한 패키지 목록 파일에서 사용할 패키지 파일을 선택합니다.
열린 패키지 정보 편집 창은 선택한 패키지 파일 유형에 따라 다르게 표시됩니다. 다음 창은 .rpm 패키지 파일을 사용한 경우 패키지 정보 편집 창이 표시되는 예를 보여줍니다.
4. 옵션을 구성하여 해당되는 운영 체제를 설정합니다.
5. SVR4 패키지 파일을 편집하도록 선택하는 경우 패키지 정보 편집 창에 다음 추가 옵션이 표시됩니다.
6. 편집할 패치를 선택하면 패키지 정보 편집 창에 다음 추가 옵션이 나타납니다.
여러 패키지 파일에 대해 지원되는 운영 체제를 동시에 추가 또는 제거하려면 다음을 수행합니다.
2. 사용 가능한 패키지 파일 목록에서 사용할 패키지 파일을 선택합니다.
4. 옵션을 구성하여 해당되는 운영 체제를 설정합니다.
|
주 - 편집 기능을 사용하여 패키지 파일에 대한 운영 체제를 이미 지정한 경우 정보는 보존되지 않으므로 이 작업을 다시 수행해야 합니다. |
사용 가능한 패키지 파일 목록에서 패키지 파일을 제거하려면 다음 작업을 수행합니다.
2. 사용 가능한 패키지 파일 목록에서 삭제할 패키지 파일을 선택합니다.
패키지를 삭제할 것인지 확인하는 확인 대화 상자가 표시됩니다.
패키지 파일은 삭제되고 사용 가능한 패키지 목록 창으로 돌아갑니다.
2. 사용 가능한 패키지 파일 목록에서 설치할 패키지 파일을 선택합니다.
|
주 - 선택한 패키지 파일에 종속성이 있는 경우 추가 창이 표시되어 해당 종속성을 설치에 포함할 것인지 묻습니다. |
필요에 따라 모두 선택 및 모두 선택 취소 버튼을 선택할 수 있습니다.
5. RPM 전용 - 설치하기 전에 설치 테스트를 눌러 패키지 파일을 확인 및 테스트합니다.
이 옵션은 패키지 설치 가능성을 확인합니다. 완료되면 완료 또는 이벤트 보기를 눌러 설치로 돌아갑니다.
|
주 - 선택한 패키지 파일이 지원하지 않는 운영 체제를 선택한 경우 오류 메시지가 나타나고 계속하려면 지원되는 운영 체제를 업데이트해야 합니다. |
7. 설치가 완료되거나 중지되면 완료 또는 이벤트 보기를 누릅니다.
|
주 - 패키지 파일을 설치하고 나면 시스템에서 즉시 해당 호스트에 설치된 패키지 파일의 목록을 업데이트합니다. |
필터 기능을 사용하여 사용 가능한 패키지 목록 창에 동시에 표시되는 패키지 파일 수를 제한할 수 있습니다.
사용 가능한 패키지 목록 창이 나타나며 다음 그림과 유사하게 창의 하단에서 필터 기능을 사용할 수 있습니다.
다음은 열 드롭다운 목록에서 사용 가능한 검색 기준입니다.
다음은 검색 유형 드롭다운 목록에서 사용 가능한 검색 기준입니다.
검색 내용을 정의할 키워드나 용어를 입력할 수 있습니다.
필터 기능은 매개 변수에 따라 패키지 파일을 검색하고 새로 고침된 사용 가능한 패키지 목록 창에 결과를 반환합니다.
|
주 - 지우기를 누르면 사용 가능한 패키지 목록 창의 전체 목록을 새로 고친 다음 사용 가능한 모든 패키지 파일을 표시합니다. 단일 필터 조건을 지우려면 검색 값 입력란의 텍스트를 삭제한 다음 지우기를 누릅니다. |
Sun Control Station 2.2 소프트웨어 설치 안내서의 8페이지 및 Sun Control Station 2.2 관리자 설명서의 4페이지에 있는 지원 매트릭스에 대한 내용은 최신 정보가 아닙니다. 올바른 매트릭스가 이 릴리스 노트에 나열됩니다.
Sun Control Station 2.2 AllStart 모듈의 2 장에 표시된 그림 2-55의 네트워크 인터페이스 정보 입력 테이블에 이전 릴리스의 매개 변수가 표시되어 있습니다. 버전 2.2인 경우 네트워크 유형의 "None" 매개 변수가 더 이상 사용되지 않습니다. 다음은 올바른 그림입니다.
Sun Control Station 2.2 상태 모니터링 모듈의 그림 1에 잘못된 상태 모니터 테이블이 표시되었습니다. Raq 550 및 Qube 3은 Sun Control Station 2.2 소프트웨어에서 지원되지 않습니다.
Sun Control Station 2.2 AllStart 모듈의 그림 2-35(54페이지)는 SuSE에는 적절하지만 Redhat Linux에는 적절하지 않은 화면을 표시합니다. (CR6215055)
1. "RAID 및 디스크 장치"의 "디스크 드라이브 옵션" 아이콘은 Redhat에 사용할 수 없습니다.
2. "자동 결정(/boot 및 스왑의 경우만)" 옵션은 Redhat에 사용할 수 없습니다.
Sun Control Station 2.2 AllStart 모듈의 그림 2-55(76페이지)는 세 가지 네트워크 유형을 선택할 수 있는 화면을 표시합니다. 선택 사항은 정적 IP, DHCP, 및 없음입니다. 마지막 선택 사항인 없음은 옵션이 아니며 소프트웨어에 존재하지 않습니다. (6218257)
| Sun Control Station 2.2.1 릴리스 노트 | 819-3012-10 | |
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
해당 시스템에 패치를 적용하여 Solaris 9 시스템 설정: