이 부록은 ACSLS에서 발생한 문제 해결을 위한 도구, 팁 및 기술을 요약합니다. 문제 해결 리소스 범위에는 로그, 주요 관찰 포인트 및 진단 프로브가 포함됩니다.
ACSLS 이벤트 로그는 라이브러리 작동에 문제가 발생하는 경우 유용한 정보를 찾을 수 있는 첫번째 지점입니다. 이 로그에는 라이브러리 이벤트, 상태 변경 및 오류에 대한 정보가 포함되어 있습니다. ACSLS 내 모든 하위 구성 요소는 이벤트 로거라고 하는 프로세스에 메시지를 보내 acsss_event.log에 이벤트를 보고합니다. ACSLS가 설치될 때 자동으로 생성되는 표준 이벤트 로그는 $ACS_HOME/log/acsss_event.log 파일에 포함됩니다. 여기서 $ACS_HOME은 대개 /export/home/ACSSS/입니다.
기록된 이벤트는 다음과 같습니다.
중요한 이벤트
중요한 이벤트는 라이브러리 관리를 지원할 수 있는 일반 이벤트입니다. 예를 들어 감사가 시작되거나 종료될 때, 장치의 상태가 변경될 때 또는 CAP가 열리거나 닫힐 때 이벤트가 기록됩니다.
라이브러리 오류
라이브러리 오류는 치명적이거나 치명적이지 않은 하드웨어 및 소프트웨어 오류가 모두 기록되는 이벤트입니다. 예를 들어 LSM 실패, 카트리지 문제, 데이터베이스 오류, 프로세스 실패 및 라이브러리 통신 실패가 있습니다.
이벤트 로그의 각 메시지에는 시간 기록, 메시지를 보고하는 구성 요소의 이름 및 이벤트에 대한 설명이 포함되어 있습니다. 각 메시지의 전체 설명은 ACSLS Messages 설명서를 참조하십시오.
ACSLS 콘솔 창에는 실행 중인 이벤트 로그의 끝 부분이 표시됩니다. 모든 셸 창에서 유사한 표시를 생성할 수 있습니다.
acsss 사용자로 다음 명령을 실행합니다.
acs_tail $ACS_HOME/log/acsss_event.log
전체 이벤트 로그를 보려면 로그를 탐색하거나, 특정 오류를 검색하거나, 이벤트의 특정 시퀀스를 따를 수 있는 vi와 같은 텍스트 편집기를 사용합니다.
ACSLS는 계속해서 acsss_event.log에 메시지를 보냅니다.
이 파일이 임계값 크기(기본값 500KB)에 도달하면 파일의 이름이 event0.log로 바뀐 다음 로그 디렉토리에 저장됩니다. 이에 따라 acsss_event.log는 새 파일로 계속 존재하게 됩니다.
acsss_event.log가 다시 임계값 크기에 도달하면 event0.log의 이름은 event1.log로 변경되고 acsss_event.log의 이름은 event0.log로 변경됩니다.
이 프로세스는 보존을 위해 구성된 로그 파일 개수만큼 진행됩니다.
기본적으로 9개의 이벤트 로그 파일이 로그 디렉토리에 보존됩니다. 각 후속 임계값에 따라 가장 오래된 파일은 제거되고 남은 모든 파일의 이름이 순차적으로 바뀝니다.
옵션 2인 acsss_config를 사용하여 보존할 로그 파일 수 및 acsss_event.log의 최대 크기를 구성할 수 있습니다. CSI 조정 변수 설정을 참조하십시오.
진단 도구인 greplog를 사용하면 모든 이벤트 로그 파일을 통해 키워드 검색을 수행할 수 있습니다. UNIX grep 유틸리티와 같이 가장 많이 사용되는 greplog는 지정된 키워드 표현식과 연관된 전체 로그 메시지를 반환합니다. 이를 통해 해당 표현식을 포함하는 모든 메시지와 관련된 메시지의 날짜 및 시간 기록, 메시지 번호 및 함수 텍스트를 볼 수 있습니다.
acsss_event.log에는 ACSLS의 실행 중인 프로세스에 대한 모든 측면과 관련된 모든 메시지가 포함됩니다. 이외에도 백업, 복원 및 설치 유틸리티와 같은 외부 유틸리티에 대한 상태 정보가 포함된 추가 파일이 로그 디렉토리에 있습니다.
acsss.pid - 현재 실행 중인 acsss_daemon의 프로세스 ID를 저장합니다.
acsss_config.log - 각 라이브러리 구성의 요약을 포함합니다.
acsss_config_event.log - acsss_config 루틴에 의해 게시된 이벤트 메시지를 포함합니다.
bdb_event.log - bdb.acsss 데이터베이스 백업 유틸리티에 의해 게시된 이벤트 메시지를 포함합니다.
cron_event.log - cron 유틸리티에 의해 게시된 메시지를 포함합니다. cron 일정을 보려면 crontab -l 명령을 실행합니다.
acsls_start.log - acsls 서비스와 관련된 시작 또는 종료 메시지를 포함합니다.
di_trace.log - 데이터베이스 인터페이스와 관련된 추적 정보를 포함합니다.
ejectingLogs - 지난 10일 동안 수행된 ejecting.sh 작업의 요약 정보를 포함하는 디렉토리입니다.
install.log - install.sh 설치 스크립트를 실행하는 동안 게시된 이벤트 메시지를 포함합니다.
ipc_trace.log - ACSLS 프로세스 간 통신과 관련된 추적 정보를 포함합니다.
rdb_event.log - rdb.acsss 데이터베이스 복원 유틸리티에 의해 게시된 이벤트 메시지를 포함합니다.
timed_bkup.sh.log - 자동 데이터베이스 백업 유틸리티와 관련된 이벤트 메시지를 포함합니다.
시스템에서 사용으로 설정한 특정 추적에 따라 로그 디렉토리에서 추가 추적 로그가 발견될 수도 있습니다. 로그에는 다음이 포함됩니다.
acsss_stats.log - acsss_config에 의해 볼륨 통계 추적이 사용으로 설정됩니다.
acsss_trace.log - 소프트웨어 지원 센터 담당자의 요청에 따라 클라이언트-서버 추적이 사용으로 설정됩니다.
acslh.log - 소프트웨어 지원 센터 담당자의 요청에 따라 호스트-LMU 추적이 사용으로 설정됩니다.
scsilh.log, mchangerX.log, scsipkt.log - 이 세 로그 모두에는 SCSI 연결 라이브러리에 대한 SCSI 통신의 추적이 포함되고, 소프트웨어 지원 센터 담당자의 요청에 따라 사용으로 설정됩니다.
소프트웨어 지원 센터의 요청에 따라 사용으로 설정된 추적 로그가 매우 빠르게 증가할 수 있습니다. 디스크가 가득 차는 문제를 완화하기 위해 이러한 로그를 모니터링하고 관리해야 합니다.
monitor.sh 유틸리티는 자동 로그 관리 및 아카이브 서비스를 수행하기 위해 제공됩니다. 구문은 다음과 같습니다.
monitor.sh <로그 이름>
특정 로그를 모니터링하도록 이 유틸리티가 사용으로 설정된 경우 로그가 1MB 크기(기본값)까지 커질 수 있도록 지정한 다음 gzip을 사용하여 로그를 압축합니다. 이 압축된 로그 파일(시간 기록된 이름 포함)을 ACSSS/log/log_archives 하위 디렉토리에 배치합니다. 이 작업은 추적이 사용으로 설정되어 있는 경우 계속됩니다.
ACSLS GUI 및 논리적 라이브러리 소프트웨어 구성 요소를 포함하는 ACSLS의 Java 구성 요소에서 다양한 로그가 유지 관리됩니다. 이러한 로그는 $ACS_HOME/log/sslm 디렉토리에서 찾을 수 있습니다.
WebLogic 설치 프로시저는 weblogic.log에 기록됩니다. WebLogic 및 ACSLS GUI 작업은 AcslsDomain.log 및 AdminServer.log에 기록됩니다.
웹 기반 GUI의 사용자 작업에 대한 감사 추적은 guiAccess.log에서 찾을 수 있습니다.
Java 구성 요소와 레거시 ACSLS 구성 요소 간의 트랜잭션은 surrogate_trace.0.log에 기록됩니다.
Java 클라이언트 구성 요소와 ACSLS 서버 간의 IPC 패킷은 acslm_ipc_trace.0.log에서 추적됩니다.
ACSLS GUI에서 발생하는 오류는 gui_trace.0.log에 기록됩니다.
SMCE 클라이언트와 SCSI(광 섬유) 클라이언트 간 하위 레벨의 통신은 smce_trace.0.log에 기록됩니다.
이러한 로그는 $ACS_HOME/log/sslm 디렉토리에서 찾을 수 있습니다.
ACSLS의 다양한 측면 상태를 확인할 수 있는 여러 유틸리티가 있습니다.
psacs - 모든 ACSLS의 실행 중인 프로세스에 대한 요약을 표시합니다. ACSLS가 실행 중인지 여부를 가장 잘 나타냅니다. 일반적인 출력은 최소한 12개의 서로 다른 프로세스(모두 공통 상위 프로세스의 하위 프로세스임)를 표시해야 합니다.
acsss status - acsdb 데이터베이스 서비스가 실행 중인지 여부를 확인합니다.
ACSLS 릴리스 및 유지 관리 레벨을 표시하려면 다음을 수행합니다.
acsss_event.log를 확인합니다.
acsls_start.log를 확인합니다.
acsss_event.log의 끝에서 문제를 설명하는 메시지를 확인합니다.
메시지에 대한 설명 및 해당 메시지를 해결하기 위해 수행할 수 있는 작업에 대해서는 ACSLS Messages 설명서를 참조하십시오.
acsss l-status로 ACSLS 서비스의 상태를 표시합니다.
ACSLS 서비스의 상태 요약을 표시하려면 acsss l-status를 사용합니다. 각 서비스의 logfile 항목은 ACSLS의 시작을 방해했던 조건을 설명하는 자세한 메시지가 포함될 수 있는 로그 데이터를 가리킵니다.
ACSLS가 시작하는 동안 시간을 초과합니다.
Solaris의 경우 구성에 따라 계산된 ACSLS 시작 시간 초과 기간을 표시하려면 acsss timeout을 사용합니다.
ACSLS는 라이브러리에 대한 양호한 물리적 연결을 확인하는 유틸리티를 제공합니다. 작동 컨텍스트에 따라 선택해야 할 최선의 도구가 결정됩니다.
이 유틸리티는 StorageTek ACSLS에 구성된 각 라이브러리에 대한 연결을 테스트합니다. 또한 사용이 가장 간단하고 가장 광범위하게 사용할 수도 있습니다. 이 테스트는 눈에 띄지 않으며 일반 라이브러리 작동에 영향을 주지 않습니다. testports는 StorageTek ACSLS 데이터베이스를 사용하여 라이브러리 포트 이름 및 라이브러리 유형을 확인하므로 testports의 작동을 위해서는 라이브러리가 StorageTek ACSLS에 대해 이미 구성되어 있어야 합니다.
TCP/IP 라이브러리의 경우 testports가 연결되고, 라이브러리가 온라인 상태인지 여부와 StorageTek ACSLS에서 사용 중인지 여부를 확인합니다.
SCSI 및 직렬 연결 라이브러리의 경우 testports에서 테스트 연결을 열려면 'acs' 및 'port'가 오프라인이어야 합니다.
이 유틸리티를 실행하려면 다음과 같은 명령 구문을 사용합니다.
testports
라이브러리 호환성 레벨 또는 마이크로코드 레벨이 표시됩니다.
이 유틸리티는 TCP/IP 패킷을 네트워크 연결 라이브러리에 제출합니다.
라이브러리 연결을 테스트하려면 명령줄에 라이브러리 호스트 이름 또는 IP 주소를 포함합니다.
testlmutcp <ip_address> 또는
testlmutcp <hostname>
라이브러리가 ACSLS에 대해 온라인 상태인 동안 연결을 테스트하려면 50002에서 50016 사이에서 사용되지 않은 소켓 번호를 지정합니다. 예:
testlmutcp <ip_address>:50002
성공적인 응답에는 연결 라이브러리의 호환성 레벨이 포함됩니다.
이 유틸리티는 ACSLS와 레거시 StorageTek 직렬 연결 라이브러리 간의 연결을 테스트하는 데 사용할 수 있습니다. 이 유틸리티를 실행하려면 devlink 경로를 직렬 포트 장치 노드에 제출합니다.
testlmu /dev/term/0
testlmu에서 직렬 연결을 열려면 라이브러리가 ACSLS에 대해 오프라인 상태여야 합니다.
이 유틸리티를 사용하면 라이브러리가 ACSLS에 대해 온라인 상태인 동안 ACSLS와 직렬 연결 라이브러리 간의 통신을 확인할 수 있습니다. 성공적인 응답에는 라이브러리 호환성 레벨이 포함됩니다.
이 유틸리티는 ACSLS 서버와 SCSI 또는 광 섬유 연결 라이브러리 간의 연결을 실행합니다. 이 유틸리티를 실행하려면 mchanger 장치에 대한 devlink 경로를 지정합니다. 구문은 다음과 같습니다.
probescsi.sh /dev/mchangerX
여기서 X는 테스트 중인 라이브러리의 특정 mchanger 인스턴스입니다.
probescsi에서 SCSI 연결을 열려면 ACSLS에 대해 라이브러리가 오프라인 상태여야 합니다. 성공적인 응답에는 연결 라이브러리의 마이크로코드 레벨이 포함됩니다.
클라이언트 응응 프로그램은 RPC(원격 프로시저 호출) 프로토콜을 사용하여 TCP/IP를 통해 ACSLS와 통신합니다. 클라이언트 시스템이 ACSLS와 통신할 수 없는 경우 rpcinfo를 사용하여 클라이언트 시스템에서 ACSLS에 연결할 수 있는지 여부를 테스트할 수 있습니다.
ACSLS 서버에서 ACSLS가 실행 중인지 확인합니다.
psacs
ACSLS 서버에서 RPC 데몬이 실행 중인지 확인합니다.
ps -ef | grep rpc
ACSLS 서버에서 프로그램 번호 300031이 TCP 및 IDP에 등록되어 있는지 확인합니다.
rpcinfo | grep 300031
이 프로그램 번호는 ACSLS가 실행 중이며 ACSLS가 RPC에 등록되었는지 확인합니다.
클라이언트 시스템 또는 네트워크의 모든 UNIX 시스템에서 rpcinfo를 사용하여 ACSLS 서버의 프로그램 번호 300031과 패킷을 교환합니다.
ACSLS 서버의 IP 주소를 프로그램 번호와 함께 지정합니다.
rpcinfo -t <ip address> 300031
통신 교환에 성공하는 경우 rpcinfo 유틸리티는 다음 메시지를 표시합니다.
program 300031 version 1 ready and waiting
program 300031 version 2 ready and waiting
이를 통해 네트워크 간의 클라이언트 연결에 ACSLS를 사용할 수 있음을 확인합니다.
다른 ACSLS 인스턴스가 라이브러리 관리를 담당할 때 브리지 드라이브를 통해 연결된 광 섬유 연결 라이브러리의 CAP가 잠길 수도 있습니다. 이 문제에 대한 자세한 내용 및 해결 방법은 SL150 부록의 CAP(메일슬롯) 꺼내기 중 열지 않음을 참조하십시오.
서비스 통화의 일부로 오라클 고객지원센터에서 분석을 위해 진단 로그 전체와 다른 진단 정보를 보내달라고 요청할 수도 있습니다. 이러한 모든 데이터는 다음 단일 명령으로 수집할 수 있습니다.
get_diags
이 유틸리티가 모든 정보를 수집하면 데이터를 전자 메일로 보낼지 아니면 수동 전송에 사용할지 묻는 메시지가 표시됩니다.
ACSLS 시스템에서 직접 데이터를 전자 메일로 보내기로 결정할 경우 ACSLS 시스템과 인터넷 간에 전자 메일 통신이 가능한지 확인하십시오. 회사에 대상 시스템에서 직접 전자 메일을 보내지 못하도록 방화벽이 있을 수 있습니다. 이 경우 회사 내부의 자신에게 전자 메일로 정보를 보낸 다음 진단 데이터를 오라클 고객지원센터에 전달할 수 있습니다.
아니면 정보를 수동으로 전송하도록 선택할 수 있습니다. get_diags 유틸리티에서 전송 대기 중인 tar 패키지가 있는 위치를 알려줍니다. 일반적으로 진단 데이터에 대한 준비 영역은 /export/backup/diag/acsss입니다.
SELinux는 Oracle Linux에서 기본적으로 사용으로 설정됩니다. SELinux는 표준 Unix 레벨 액세스 제어를 벗어나 사용자 역할 및 즉시 컨텍스트 도메인에 따라 시스템 리소스에 대한 액세스를 적용합니다. SELinux 시행이 사용으로 설정되면 ACSLS가 자체 PostgreSQL 데이터베이스에 액세스하는 기능은 해당 액세스에 대한 역할 및 컨텍스트를 설정하는 특별한 정책 없이 금지됩니다.
ACSLS를 설치할 때 세 가지 SELinux 정책 모듈(allowPostgr, acsdb, acsdb1)이 커널에 로드됩니다. 이러한 모듈은 SELinux 시행이 활성 상태인 동안 ACSLS가 고유의 데이터베이스 및 기타 시스템 리소스에 액세스하는 데 필요한 정의 및 적용 예외사항을 제공합니다. 이러한 모듈이 설치된 상태에서 SELinux 시행을 사용 안함으로 설정할 필요 없이 bdb.acsss, rdb.acsss, db_export.sh, db_import.sh와 같은 데이터베이스 작업을 포함하는 일반적인 ACSLS 작업을 실행할 수 있어야 합니다.
신속한 소프트웨어 업그레이드를 위해 ACSLS에 의해 로드된 SELinux 정책 모듈은 ACSLS 패키지를 설치 해제할 때 자동으로 제거되지 않습니다. 이러한 모듈을 수동으로 제거하려면 ACSLS 모듈 목록을 가져옵니다.
# semodule -l | grep acsdb
# semodule -l | grep allowPostgr
각 모듈의 경우 다음 방식으로 모듈을 제거합니다.
# semodule -r <module name>
ACSLS를 설치한 후 기존 파일 권한 설정이 유효한데도 시스템이 'permission denied'로 응답하는 액세스 관련 문제가 발생하는 경우 액세스 거부의 원인은 SELinux일 수 있습니다.
SELinux 시행이 사용으로 설정되었는지 여부를 확인하려면 sestatus 명령을 실행합니다.
# sestatus SELinux status: enabled Current mode: enforcing
setenforce 명령을 사용하여 SELinux 시행을 일시적으로 사용 안함으로 설정할 수 있습니다.
# setenforce Permissive
허가 모드에서 SELinux 시행 시 이제 실패한 리소스에 대한 액세스를 복원할 수 있는지 여부를 확인할 수 있습니다. 적용 모드가 아닌 허가 모드에서 권한이 부여된 사용자가 필요한 리소스를 사용할 수 있는 경우 업데이트된 SELinux 정책이 필요한 것입니다.
부트 간에 SELinux 보안을 영구적으로 사용 안함으로 설정하려면 다음을 수행합니다.
/etc/selinux/config 파일을 편집합니다.
SELINUX=enforcing을 SELINUX=permissive로 변경합니다.
SELinux 시행을 다시 사용으로 설정하려면 root에 sysadm_r 역할이 있어야 합니다.
# newrole -r sysadm_r # setenforce enforcing
SELinux가 명백한 제한의 원인임을 확인한 후에는 SELinux 감사 로그를 확인하여 필요한 리소스에 대한 액세스를 허용하지 않은 실제 규칙을 확인할 수 있습니다.
# vi /var/log/audit/audit.log
audit.log는 SE 시행을 성공하거나 실패한 각 액세스 시도에 대한 요약을 제공합니다. 실패한 이벤트를 찾아야 합니다. ACSLS의 경우, 특히 acsss 및 acsdb 사용자와 관련된 이벤트를 확인하십시오.
지정된 파일 또는 디렉토리와 연관된 SELinux 컨텍스트 속성을 볼 수 있습니다.
# ls -Z <file name>
secon 명령을 사용하여 현재 셸의 컨텍스트 속성 또는 지정된 프로세스의 컨텍스트 속성을 볼 수 있습니다. chcon 명령을 사용하여 파일 또는 디렉토리의 컨텍스트 속성을 변경할 수 있습니다. 이러한 작업에 대한 매뉴얼 페이지를 참조하십시오.
audit.log에서 찾은 실패한 작업에 대한 응답으로 정책 모듈을 만들 수 있습니다.
# cd /var/log/audit # audit2allow -a -M <ModuleName>
이를 통해 SELinux에 의해 기록된 실패를 평가하고 정책 모듈 파일 <ModuleName>.pp를 만듭니다. 이제 이 파일을 Linux 커널에 로드하여 차단되었던 작업을 허용할 수 있습니다.
# semodule -i <ModuleName>.pp
audit2allow는 audit.log에서 식별된 모든 제한을 사용으로 설정하는 정책을 만들기 때문에 audit.log에는 특별히 허용하려는 해당 작업만 포함하는 것이 좋습니다. 원본 audit.log를 저장하고 새 audit.log를 만들 수 있습니다.
# mv audit.log audit1.log # touch audit.log
audit.log에 대한 정책 모듈을 만들기 전에 캡처할 작업을 계속 진행합니다.
SELinux에 대한 자세한 내용은 매뉴얼 페이지를 참조하십시오.
# man selinux
checkGui.sh 유틸리티는 공통 요소를 확인하여 GUI가 작동 중인지 여부를 평가합니다. GUI가 작동하지 않는 경우 이 유틸리티는 사용자에게 문제가 발생한 가능한 원인을 알려줄 수 있습니다.
이 유틸리티는 다음을 확인합니다.
WebLogic이 시스템에서 사용으로 설정되어 있는지 여부
WebLogic 작업을 방해하는 팬텀 또는 사용되지 않는 프로세스가 있는지 여부
SlimGUI 응용 프로그램이 성공적으로 배치되었는지 여부
WebLogic 및 GUI가 localhost에 전송된 http 요청에 응답할 수 있는지 여부
WebLogic이 호스트의 인터넷 주소에 전송된 http 요청에 응답할 수 있는지 여부
서버에 방화벽 서비스가 사용으로 설정되어 있는지 여부 설정되어 있다면 WebLogic 포트 7001 및 7002에 대한 수신 요청을 수락하는 정책이 있는지 여부
Linux 시스템에서 iptables라고 하는 방화벽이 기본적으로 사용으로 설정되어 있는지 확인할 수 있습니다. iptables를 완전히 사용 안함으로 설정하거나 수신 트래픽을 수락하는 정책을 포트 7001 및 7002에 추가할 수 있습니다.
root로 이러한 포트를 사용으로 설정하려면 /etc/sysconfig/iptables 파일을 편집합니다. 다음 두 행을 추가합니다.
-A INPUT -p tco --dport 7001 -j ACCEPT -A INPUT -p tco --dport 7002 -j ACCEPT
이러한 규칙이 검사되기 전에 해당 규칙을 수신 패킷과 일치할 다른 규칙 다음에 삽입하지 않아야 합니다. 예를 들어 이러한 규칙을 REJECT all 규칙 다음의 iptables 체인 끝에 추가하지 마십시오.
iptables 명령을 사용하여 이러한 규칙을 추가하는 경우 다음을 수행합니다.
테이블을 나열(iptables -L)하거나 인쇄(iptables -S)합니다.
규칙을 추가합니다.
이전 규칙으로 인해 새 규칙이 입력과 일치하지 않을 수도 있으므로 규칙을 체인 끝에 추가(iptables –A)하는 것만으로는 원하는 결과가 생성되지 않을 수 있습니다.
rulenum별로 규칙을 삽입(iptables -I)합니다.
변경 후 테이블을 나열(iptables -L)하거나 인쇄(iptables -S)하고, 기존 규칙으로 인해 포트 7001 및 7002에 대한 새 규칙이 검사되지 않는 일은 없도록 해야 합니다.
이렇게 하면 새 규칙이 수신 패킷과 일치할 수 있습니다.
checkGui.sh 유틸리티는 포트 7001 및 7002의 ACCEPT 입력에 대한 규칙이 존재하는지 여부를 검사합니다. 이 유틸리티는 해당 규칙이 올바른 iptables 체인에 있는지 또는 새 규칙이 실제로 처리될지는 확인하지 않습니다. 즉, checkGui.sh는 새 규칙을 검사하지 못하도록 막을 수 있는 이전 규칙이 없는지 확인하지 않습니다.
iptables를 다시 시작합니다.
service iptables restart
Solaris에서 유사한 서비스는 ipfilter이며, 대개 기본적으로 사용으로 설정되지 않습니다.
다음 표에서는 일부 GUI 문제 해결 팁에 대해 설명합니다.
| 문제 |
해결 방법 |
|---|---|
|
https://<hostname>을 브라우저에 입력했는데 응답 페이지가 "Unable to connect(연결할 수 없음)"를 선언합니다. |
올바른 URL은 https://hostname.domain:7002/SlimGUI/faces/Slim.jsp입니다. |
|
ACSLS GUI 페이지가 불완전합니다. 일부 프레임이 불완전하거나 전체 섹션이 누락되었습니다. |
브라우저에서 Refresh(새로 고침) 버튼을 누릅니다. |
|
유효한 사용자 ID 및 암호를 Java WebLogic에서 거부합니다. 로그인할 수 없습니다. |
해당 지역의 ACSLS 관리자와 상의하십시오. 관리자인 경우 userAdmin.sh 유틸리티를 사용하여 사용자를 나열 또는 추가하거나 사용자 암호를 변경합니다. 사용자가 로그인하는 데 계속 문제가 있는 경우 시스템에 메모리가 충분한지 확인한 다음 userAdmin.sh의 옵션 5로 ACSLS GUI를 다시 시작합니다. 또는 svcadm disable weblogic 및 svcadm enable weblogic을 사용하여 WebLogic을 다시 시작할 수 있습니다. |
|
Java 오류 스택 추적이 GUI 창 하나 이상에 표시됩니다. |
브라우저에서 Refresh(새로 고침) 버튼을 누릅니다. 문제가 지속되면 서비스가 실행되지 않는 경우 ACSLS 서비스가 실행 중인 경우 userAdmin.sh를 사용하여 GUI를 다시 시작합니다. 또는 svcadm disable weblogic 및 svcadm enable weblogic을 사용하여 WebLogic을 다시 시작할 수 있습니다. 시스템에 |
|
인덱스 트리 프레임에서 "Logical Libraries" 선택이 누락되었습니다. |
먼저 논리적 라이브러리를 만들어야 합니다. Configuration and Administration -> Logical Library Configuration -> Create Logical Library를 선택합니다. |
|
Volumes 페이지의 Tape Library Operations 또는 Tape Libraries & Drives 아래에 나열된 볼륨이 없습니다. |
이는 라이브러리에 대한 초기 감사가 수행되지 않았음을 나타냅니다. Tape Library Operations ->Audit을 선택합니다. |
|
Volumes 페이지의 Logical Libraries 아래에 나열된 볼륨이 없습니다. |
이는 볼륨이 아직 논리적 라이브러리에 지정되지 않았음을 나타냅니다. Logical Library Configuration -> Assign Volumes를 선택합니다. |
|
GUI 응답 시간이 느립니다. |
GUI 마스트헤드의 Preferences 버튼 아래에서 Alert Update Interval을 늘립니다. |
|
GUI 사용자를 추가하거나, GUI 사용자의 암호를 변경하거나, |
userAdmin.sh를 참조하십시오. 이 유틸리티를 통해 사용자를 추가하고, 사용자의 암호를 변경하고, |
|
브라우저를 사용하려면 보안 인증서가 필요합니다. |
HTTPS에 자체 지정 디지털 인증서 구성을 참조하십시오. |