여기저기 기웃거리기

1. sshd 설정 변경
# cd /etc/ssh
# vi sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# service sshd restart

2. rsa 키 만들기
$ ssh-keygen -t rsa
엔터키 세번(네번이던가요???)

$ ls
id_rsa      id_rsa.pub

$ cp id_rsa.pub authorized_keys

$ vi authorized_keys
여기서 내 서버의 키 값을 복사해서 상대방 서버의 파일에 추가해주고 내 파일에는 상대방 서버의 키 값을 추가해주면된다.

[oracle@Test2 /opt/oracle/product/10g/precomp/admin]$ cat pcscfg.cfg
sys_include=(/ade_autofs/ade_linux/RDBMS_10.2.0.4.0_LINUX.rdd/080216/precomp/public,/usr/include,/usr/lib/gcc/i386-redhat-linux/4.1.1/include,/usr/lib/gcc/i386-redhat-linux/3.4.5/include,/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include,/usr/lib/gcc/i586-suse-linux/4.1.0/include)
ltype=short

test2_j004_26820.trc
test2_lgwr_23400.trc
test2_lgwr_26811.trc
test2_lgwr_26972.trc
test2_m001_10660.trc
test2_m001_12625.trc
test2_m001_13274.trc
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>ls -l | grep .trc | awk  '{print "mv "$9" /data4/backup/trace_backup/bdump_backup/"}' | sh
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>ls -l | grep .trc | awk  '{print $9}'                                              
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>ll
total 1704
-rw-r-----  1 oracle dba 1737626 Jul  1 18:15 alert_test2.log
oracle@TESTDB2:/oracle/app/oracle/admin/test2/bdump>

processor    : 3
vendor_id    : GenuineIntel
cpu family    : 15
model        : 6
model name    : Intel(R) Xeon(TM) CPU 3.00GHz
stepping    : 4
cpu MHz        : 2992.850
cache size    : 2048 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 2
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid xtpr
bogomips    : 5985.04

최근에 저널링 파일 시스템이 신비의 대상으로 여겨져 연구 주제로 떠오르고 있습니다. 하지만 오늘날 저널링 파일 시스템(ext3)은 리눅스(Linux®)에 기본으로 탑재되어 있습니다. 저널링 파일 시스템 이면에 숨겨진 아이디어를 찾아 시스템 전원 문제나 비정상 종료 과정에서 더 나은 무결성을 제공하는 방법을 익힙시다. 현재 사용 중인 다양한 저널링 파일 시스템을 익히고 차세대 저널링 파일 시스템도 미리 살펴봅시다.

저널링 파일 시스템을 다양한 방식으로 정의할 수 있지만 요점만 간략하게 정리해보자. 저널링 파일 시스템은 부트 시점에서 파일 시스템 일관성 검사를 위해 fsck가 돌아가는 모습에 진절머리가 난 사람을 위한 고안물이다(저널링 파일 시스템은 결함에 회복력을 보이는 파일 시스템이라는 아이디어에서 나왔다). 저널링 기능이 없는 전통적인 파일 시스템을 부적절하게 종료하면, 운영체제가 이를 감지해 fsck 유틸리티를 사용해 일관성 검사를 수행한다. 이 유틸리티는 파일 시스템을 탐색해(상당히 오랜 시간이 걸릴 수도 있다) 안전하게 교정할 수 있는 문제점을 수정한다. 어떤 경우에는 파일 시스템이 심하게 망가졌기에, 운영체제가 알아서 단일 사용자 모드로 진입한 다음에 사용자가 복구 과정을 진행하도록 만드는 경우도 있다.

df와 같은 유닉스 명령어에서 Iused와 %Iused가 무엇을 의미하는지, 아니면 사람들이 inode에 대해 이야기할 때 궁금증을 느낀 경우가 없습니까? 유닉스(UNIX®)와 리눅스(Linux®) 시스템은 모두 inode를 사용하며, IBM® AIX®라고 해서 다르지 않습니다. inode가 무엇이며, inode가 유닉스에 중요한 이유, inode의 구조, inode와 관련이 있는 명령어를 알아봅시다.

inode는 유닉스 운영체제에서 사용하는 자료 구조로, 파일 시스템 내부에 파일을 유지하는 중요한 정보를 담고 있다. 유닉스에서 파일 시스템을 생성할 때, 수 많은 inode 집합을 생성한다. 일반적으로 전체 파일 시스템 디스크 용량의 대략 1% 정도가 inode 테이블에 할당된다.

종종 사람들은 inode와 inumber를 섞어서 사용한다. 두 용어는 비슷하며, 서로 관련이 있지만 똑같은 개념을 나타내지는 않는다. inode는 자료 구조다. inumber는 실제 inode 인식 번호이므로 inode number나 inumber라고 부른다. inumber는 파일 정보를 담은 중요한 항목일 뿐이다. inode에서 몇 가지 다른 속성은 다음 절에서 설명한다.

inode 테이블은 개별 파일 시스템을 위한 모든 inode 숫자 목록을 포함한다. 사용자가 파일에 접근하려면, 유닉스 시스템은 올바른 inode 번호로 inode 테이블을 탐색한다. inode 번호를 발견하면, 사용자가 내린 명령이 inode에 접근해서 가능하다면 적절한 변경 작업을 진행한다.

예를 들어, vi로 파일을 변경하는 작업을 생각해보자. vi <filename>이라고 입력할 때, inode 숫자를 inode 테이블에서 찾아 inode를 연다. vi 편집 세션 중에서 몇 가지 속성이 변경되며, :wq로 작업을 종료할 때, inode가 닫히며 해제된다. 이런 식으로 사용자 두 명이 같은 파일을 동시에 편집하면, inode가 편집 세션을 연 사용자 ID에 할당되며, 다른 사용자는 inode가 해제되기를 기다려야만 한다.

블레이드는 특히 통신 서비스 제공업체에서 응용과 서비스를 위한 탁월한 선택입니다다. 하지만 이런 서비스 제공업체에 필요한 독특한 요구 사항은 종종 복잡하고 집중적인 관리와 계획이 필요한 환경 설정을 요구합니다. 결국 엄격한 요구 사항을 충족할 필요가 있습니다. 이 기사에서는 POWER6™ JS22 블레이드 장비 설정을 위해 필요한 네트워크 환경 설정 계획과 구체적인 방안을 설명하겠습니다.

블레이드 기반 운영 모델은 다음과 같은 이유로 인해 유무선 통신 업체에 상당한 가치를 부여한다.

1. 작은 공간은 데이터 센터 공간을 비용 대비 효과적으로 활용함을 의미한다.
2. 배포는 분산 배포를 위한 NEBS(Network Equipment Building System) 요구 사항을 충족한다. (NEBS는 네트워크로 연결한 장비가 호환성 자격을 부여받기 위해 반드시 충족해야 하는 요건 범주 집합이다.)
3. 비용 대비 효율이 높은 수평적인 확장성은 통신 서비스 제공업체가 지불해야 하는 배포 비용을 줄인다.
4. 중 앙 집중적인 관리 지원은 서비스 제공자 네트워크에서 내부 배포를 위한 좀 더 나은 OAM&P(Operations, Administration, Maintenance, and Provisioning) 지원을 제공한다. 이 용어는 추적을 위한 원칙과 사용해야 하는 구체적인 소프트웨어 집합을 기술한다.
5. 업그레이드와 유지보수를 포함한 지속적인 가용성 기반 운영 모델을 위한 붙박이식 지원은 고객 관점에서 서비스 장애를 방지한다.

추가적인 고려 사항은 특히 복잡한 환경 설정을 보유한 통신 서비스 제공업체 환경에서 핵심이다.

• 다 중 VLAN: 다중 VLAN은 CDN(Customer Data Network)과 관리(OAM&P) 트래픽을 위해 사용된다. 다중 VLAN을 독자적으로 고려하면 다중 LPAR(논리 파티션)을 가로질러 고객 QoS(Quality of Service)를 효과적으로 운영하도록 보증한다.
• 마이크로 파티셔닝과 가상화: 이런 전략은 용량 활용과 TCO(Total Cost of Ownership)을 극대화하는 과정에 도움을 준다.
• 현존하는 네트워크 복잡성: 다중 클라이언트 LPAR에서 자원 부하 분배를 요구할 경우, 현존하는 네트워크에 좀 더 높은 부하 가변성이 필요할지도 모른다.

이 기사에서 능동/수동 설정으로 쌍을 맺은 시스코 스위치를 사용해 블레이드 본체에 다중 VLAN을 설정하는 방법을 설명한다. 이 기사에서 소개하는 예제에서, Power용 리눅스(Linux®)를 돌리는 BladeCenter® JS22에서 다중 VLAN을 연결하도록 네트워크를 설정했다. 이 아키텍처는 각각 1GB 외부 포트 네 개와 내부 포트 열네 개를 갖춘 시스코 카탈리스트 스위치 모듈 여섯 개를 포함한다.