SSL 통신 구조

* SSL의 구조
SSL은 가장 다양한 분야에서 적용하고 있는  프로토콜 중 하나다. TCP/IP는 기본적으로 보안을 고려하지 않으므로 전자상거래를 비롯한  온라인 서비스를 활성화하려면 서비스 상호간의 인증, 암호와 통신을 비롯한 문제점을  한다.
* SSL의 개념
SSL은 'Secure Socket Layer'의  넷스케이프(Netscape)에서 처음 개발하여 넷스케이프 네이게이터(Netscape Navigator)에 처음 적용한 보안 프로토콜이다.  아이디어는 기본의 TCP/IP에서 고려하지 않은 보안 세션을 추가하여 통신 상호  전송 메시지에 대한 암호화와 상호 인증을 수행하는 프로토콜이다.

그림과 같이 SSL은 기존의 TCP/IP에서 응용 계층과 TCP 계층 사이에  보안 계층으로 동작한다. TCP 계층은 응용 계층의 프로톨 간의 인터페이스를  소켓을 이용하며, SSL은 각 소켓으로 연결된 상호 간의 통신 채널을  관리하는 기능을 한다. 클라이언트와 서버 간의 안전한 통신을 위하여 SSL은 같은 기능을 제공한다.
==================================================================================================
기능          | 설명
==================================================================================================
상호인증       | 클라이언트/서버 간의  위한 세션 키를 생성하고 "Hello"라는 메시지를 교환함으로써
         | 상호 인증을 한다.
--------------------------------------------------------------------------------------------------
기밀성        | 전송되는 메시지에 대한 다양한 형식의 암호화를  타인에게 메시지의 내용을 노출하
   | 지 않도록 한다.
--------------------------------------------------------------------------------------------------
무결성        | 전송 메시지의 변조를 방지할 수 있도록 MD5를 비롯한 알고리즘을  전자 서명을 한다.
==================================================================================================
기밀성이나 무결성 등의 암호학적 기능을  위해서는 국제적으로 표준화되고 있는 암호 알고리즘의 지원이 따라야 한다. SSL은  있는 주요 암호 알고리즘을 비롯하여 현재 주로 이용하는 다양한 암호  지원하고 있다.
==================================================================================================
기능          |  알고리즘
==================================================================================================
기밀성        | DES, 3DES, IDEA,  RC4
--------------------------------------------------------------------------------------------------
무결성        | MD5
--------------------------------------------------------------------------------------------------
서버      | RSA, X509
--------------------------------------------------------------------------------------------------
클라이언트 인증 | 현재  웹 브라우저에서 클라이언트 인증을 제공함
==================================================================================================
* SSL의  및 통신 절차
SSL은 다수의 프로토콜로 구성되어 있는 프로토콜 집합이라고  수 있으며, 패킷 분할, 세션 관리 등의 기본적인 통신과 관련된  수행하는 부분과 데이터의 암호화, 복호화, 메시지 인증 같은 보안 서비스를  있는 부분으로 구분할 수 있다.

그림에서 SSL  프로토콜, SSL 변겸 암호 스펙, SSL 경고 프로토콜이 SSL의 세션  및 동작을 처리하는 부분이며, 메시지의 암호화 및 무결성 등의 보안  SSL 레코드 프로토콜에서 담당한다.
* SSL 핸드쉐이크 프로토콜
서버 간의 통신을 수행하기 위한 첫번째 단계는 상호 간의 통신을  세션(Session)을 설정하는 과정이다. 세션은 데이터 전송을 위한 논리적인 경로로, 실제로는  개의 커넥션(Connection)이 포함이 되어 클라이언트와 서버 간의 논리적인 관계를 표시하는  포함하고 있다. SSL에서 세션 상태 연결을 수행하는 것이 SSL 핸드쉐이크  Handshake Protocol)이며 한 세션 동안 이용되는 암호 매개 변수를 생성하여  서버 간에 공유하기 위해서 사용한다.
SSL 핸드쉐이크 프로토콜은 SSL  프로토콜(Record Protocol)에 의해서 메시지의 송수신을 위한 작업보다 먼저 수행이 되어  같은 세션 정보들을 생성하게 된다.
세션 식별자(Session Identifier) :  또는 보류 중인 세션을 식별하기 위해서 서버가 임의로 설정한 식별자
certification) : 서버와 클라이언트 주체의 X.509 인증서
Cipher Spec :  데이터에 대해 수행되는 압축 알고리즘과 MAC 알고리즘에 대한 규격
압축  method) : 암호화 이전에 데이터 압축을 위해 사용하는 알고리즘
Master  : 클라이언트와 서버 간에 공유하는 48비트 길이의 비밀 값
재사용  : 세션이 새로운 연결에 사용 가능한지 여부를 나타내는 플래그
세션이 설정된 후 해당 세션 내에 수행되는 각 커넥션에서 메시지는 세션 정보의 Master secret과 클라이언트의 난수를 통해서 각 커넥션마다 다르게 생성된 비밀 키에 의해서 암호화된다. 따라서 공격자는 스니핑을 통해서 전송 내용을 도청하더라도 전송되는 메시지를 복호화하기 위한 정보를 얻어내기 어렵게 된다.

  세션을 설정하는 첫번째 단계로 클라이언트와 서버는 Hello  교환하며, 이 과정을 통해서 SSL 프로토콜 보존, 세션 ID, 암호  압축 방법을 설정하고 ClientHello.random과 ServerHello.random을 생성, 교환하게 된다. ClientHello 메시지를  서버는 클라이언트의 인증서를 요구할 수 있으며, 이 경우 서버 자신의  보내며 그렇지 않을 경우 ServerKeyExchange를 응답에 포함하여, CertificateRequest를 보내고, Hello  완료됨을 알리는 ServerHelloDone 메시지를 클라이언트로 보내어 응답한다.
클라이언트는 Hello에  응답을 받아서 클라이언트의 인증서 또는 ClientKeyExchange와 클라이언트가 사용할 ChangeCipherSpec 메시지를  뒤이어 CipherSpec에 맞추어 작성된 finished 메시지를 서버로 보낸다.
서버는  메시지와 이를 이용해서 만들어진 Finished 메시지를 받은 후 서버가 사용할 ChangeCipherSpec 메시지와 Finished 메시지를 보내고 이후에는 합의된 내용으로 Application Data의  이루어지게 된다.
* 세션(Session)과 커넥션(Connection)
커넥션은 실제로 데이터이  수신이 이루어지는 단위를 말하며, Peer-to-Peer 관계가 성립하는 개념이다. 이에 비해서 논리적인 개념에 가까우며 컴퓨터 사용 시부터 종료 시까지의 개념을 포함한다. 한 세션은 여러 커넥션을 포함할 수 있다.
*  레코드 프로토콜
SSL 레코드 프로토콜은 상호 송수신을 위한 암호화 스펙이  핸드쉐이크 프로토콜에 의해 공유된 후 이러한 스펙에 따라 실제로 전송하는  TCP 패킷으로 변환하기 위한 기능을 수행한다. SSL 레코드 프로토콜은 이를  먼저 전송하는 메시지를 일정한 단위의 조각으로 분리하는 Fragmentation, 레코드 압축과  메시지 인증 및 암호화, 복호화 기능을 수행한다.

레코드 프로토콜은 각 메시지에 대해 다음과 같은 절차를 통해서 전송을  먼저 전송할 메시지를 일정한 크기의 레코드 프로토콜 유닛(Record Protocol Unit)으로  각 유닛을 SSL 핸드쉐이크 프로토콜로 사전에 협의한 규칙에 맞게 압축한다.  압축된 유닛마다 해시를 이용한 MAC을 생성한 후 이것을 포함하여 암호화한  전송한다.
이 과정에서 사전에 클라이언트와 서버 간에 협의한 스펙에  암호화, MAC 생성, 압축 방식 등을 수행하므로, 메시지를 수신한 측에서도  해독할 수 있다.
* 변경 암호 스펙 프로토콜
변경 암호 스펙(Change Cipher Spec) 메시지는 이후에 전송되는 레코드에 대해서  스켁(Cipher Spec)에 정의된 알고리즘과 키를 이용해서 보호할 수 있도록 수신측에  용도로 사용한다. 간단히 요약하면 송수신하는 데 사용하는 암호화 알고리즘, MAC,  방식 등을 요약하고 있는 암호 스펙을 변경하는 데 이용한다.
키 교환 메시지와 인증서 확인 메시지를 전송한 후 보내며, 서버는  받은 키 교환 메시지를 성공적으로 처리한 후 보내게 된다.
* SSL 경고 프로토콜
SSL 경고 프로토콜(SSL Alert Protocol)은 SSL의  과정에서 발생할 수 있는 문제 상황에 대해 경고를 전달하기 위해서  전송하는 경고 정보는 SSL 스펙에 정의되어 있는 치명적은 경고 목록과  심각성을 나타내는 2바이트 데이터로 구성된다.

레이드 ( RAID ) 의 레벨과 구성 ( 1부 : Raid Level 0,1,2,3,4 )

간단하게 정리하자면
Raid Level 0 인 Striping(스트라이핑)은 
데이터를 쪼개서 저장하는 
즉, 분산 저장 해서 속도향상을 위한 레벨이고

Raid Level 1 의 Mirroring ( 미러링 )은 
안전성을 좋지만 드라이브 용량 이용의 비효율성이 있습니다

Raid Level 3,4 는 Parity ( 패리티 : 데이터 오류 체크 기술)로 레벨0의 불안전성을 보완한것입니다.

                                               이제 가장 많이 사용하는 
             Raid Level 5 와 Level 6 복합구성인 01, 50, 60 등에 관해서 말하겠습니다.

  레벨 5는 레벨 3과 레벨 4의 단점을 보완한 방식으로, 패리티 정보의 저장을 전담하는 하드디스크 대신 모든 하드디스크에 패리티 정보를 분산 저장합니다. 이 방식은 쓰기(Write)에는 패리티 정보가 분산되어 
저장되기 때문에 Level 3, 4의 단점이었던 병목을 줄여주지만, 읽기(Read)에서는 사방에 흩어져 있는 
패리티 정보를 갱신하며 읽게 되기 때문에 성능 저하가 생길 수밖에 없습니다. 
이러한 단점 역시 컨트롤러에 지능형 캐쉬를 내장하여 속도저하를 최소화시키는 역할을 하고 있습니다. 
성능면에서 Raid 0 보다 떨어지지만 성능, 안정성, 용량 3 부분을 고려한 형태입니다.

하나의 드라이브가 고장날 경우 다른 드라이브에 별도로 저장된 패리티( Parity ) 정보를 정보를 통해서 
복구하고 손상된 드라이브의 패리티 ( Parity ) 정보는 나머지 하드에 있는덷 테이터를 토대로 다시 작성할 수 있습니다. 그러나 별도의 패리티 정보를 저장하는 작업을 해야 하기 때문에 RAID Level 1 보다는 
쓰기 성능이 떨어집니다.

   가끔 전화와서  
    " 고객님~!" " 계란을 한바구니에 담지마라~!! 그러면서~ 좋은 상품이 있어서~~." 
      요러 면서 광고 시작하죠? 
      이 멘트가 적용된 레이드 구성입니다. 각각의 하드에 패리티 정보를 분산 시킨거죠 ^^

RAID 3, 4와 달리 패리티 정보가 저장된 디스크가 따로 없어 패리티 디스크 고장과 같은 문제에서 
자유롭고 실제 서버/워크스테이션에서 가장 많이 사용되는 방식입니다.

레벨 6은 RAID 5와 같은 개념이지만 다른 드라이브들 간에 분포되어 있는 2차 패리티 정보를 넣어 2개의 하드에 문제가 생겨도 데이터를 복구할 수 있습니다. RAID 5보다 더욱 데이터 안정성을 고려하는 시스템에서 사용합니다.

 하드를 스트라이핑으로 묶었기 때문에 RAID 0+1이나 RAID 10(1+0)보다 성능은 더 높고 신뢰성도 우수 하지만 패리티 정보를 2중으로 저장하면서 읽기 성능은 RAID 5와 비슷하지만 쓰기 작업 구현이 아주 복잡해서 일반적으로 잘 사용하지 않습니다.

간단히 말하자면 레이드 레벨 0과 레벨 1의 복합 구성입니다. 
레벨 0의 Striping과 레벨 1의 Mirroring의 기능이 합쳐진 것으로, 분산 저장을 통한 성능 향상을꾀할 수 있으면서 데이터의 안정성 또한 보장받을 수 있습니다. 때문에 속도 및 안정성 두 마리의 토끼를 다 잡은 듯 보이지만, 여전히 전체 용량의 50%만 사용할 수 있는 것은 변함이 없으며, 비용이 많이 든다는 문제점이 있습니다.

 01과 10의 차이는 어느 쪽을 먼저 구성하느냐의 차이입니다. 
4개의 드라이브로 구성한다면 위의 이미지 처럼 그 차이는 없습니다. 
그러나 6개의 드라이브로 구성한다면 달라지게 됩니다.(아래 이미지 참고)
드라이브가 6개일때 01의 구성은 3:3 으로 구성되지만
                           10의 구성은 2:2:2 로 구성되게 됩니다.

드라이브가 6개일때...
    RAID 0+1은 RAID 0으로 구성된 드라이브들을 
                    최종적으로 RAID 1로 묶는 것이라 각각 3개씩 하드 가 나눠지며, 
    RAID 1+0은 2개씩 RAID 1으로 묶여있는 하드들이 RAID 0으로 구성됩니다. 
  
RAID 0+1의 경우 1개의 하드만 고장나서 
복구해도 다른 RAID 0 구성에서 나머지 하드까지 데이터 전체를 복구해야 하지만, 
RAID 1+0으로 만든 시스템은 
고장난 하드가 하드 1개라고 하면 미러링으로 묶인 하드를 통해 데이터만 복구하면 되므로 
실제로 운용하는데는 RAID 1+0 이 훨씬 유리합니다. 

이외에 Raid 51 / 15 ,  Raid 05 / 50 , Raid 60 이나 Raid100 등 역시 기존의 레벨의 복합적 구성입니다. 

레벨 0 이 들어가면 성능의 향상을 기대할수 있으나 안정성은 불안하게 됩니다. 
레벨 1 이 들어 가면 안전성을 확복할수 있으나 용량의 감소 또한 감수 해야 됩니다.
레벨 5나 6의 구성에 최소 3~4개의 드라이이브가 소모되기 때문에 
이들의 복합적인 구성은 최소 6개 이상의 드라이가 있어야 가능한 구성입니다. 
한마디로 돈 많이 들어간다는 거죠. ^^ 

          마지막으로 나름대로 정리해본 레이드 레벨(RAID Level)에 따른 정리 표 입니다.

                                   < 이미지를 클릭하시면 크게 보실수 있습니다. Image Click~!! >

랜덤 읽기/ 쓰기의 성능의 향상은 체감속도의 향상과 같습니다. 프로그램을 런칭하는 속도가 랜덤 엑세스의 성능과 비례한다고 보시면 됩니다. 그리고 순차 읽기 / 쓰기는 영화파일과 같은 대용량의 파일을 이동할때의 성능 이라고 생각하시면 됩니다. ~ ^

시스템 구축을 검토하다 RAID 도입에 대해 다시 정리해 보았습니다.

RAID0

스트라이프를 가지고는 있지만 데이터를 중복해서 기록하지 않는다. 동시에 여러 디스크에 나뉘어 기록하기 때문에 데이터입출력의 효율이 좋다. 따라서, 가장 높은 성능을 기대할 수 있지만, 하나의 드라이브가 깨지면 그 어레이에 있는 모든 데이타는 잃게 되어 고장대비 능력이 전혀 없으므로 이 방식은 진정한 RAID라고 하기 어렵다.
* 최소 드라이브 개수 : 2
* 최대 용량 : 디스크의 수 x 디스크의 용량
* 특징 : 빠른 입출력 속도가 요구되나 장애 복구 능력은 필요없는 경우에 적합하다.

RAID1

흔히 디스크 미러링이라고도 하는데, 중복 저장된 데이터를 가진 적어도 두 개의 드라이브로 구성된다. 스트라이프는 없으며, 각 드라이브를 동시에 읽을 수 있으므로 읽기 성능은 향상된다. 쓰기 성능은 단일 디스크 드라이브의 경우와 정확히 같다. RAID-1은 다중 사용자 시스템에서 최고의 성능과 최고의 고장대비 능력을 발휘한다. 모든 레벨에서 가장 높은 비용이 발생한다.
* 최소 드라이브 개수 : 2
* 최대 용량 : (디스크의 수/2) x 디스크의 용량
* 특징 : 빠른 기록 속도와 함께 장애 복구 능력이 요구되는 경우에 사용된다. 2대의 드라이브만으로 구성할 수 있기 때문에 작은 시스템에 적합하다.

RAID0+1

레이드0과 1을 함께 적용한다. 스트라이프를 사용해 만들어진 디스크를 다시 미러링한다.

RAID2

이 형식은 디스크들간에 스트라이프를 사용하며, 몇몇 디스크들은 에러를 감지하고 수정하는데 사용되는 ECC 정보가 저장되어 있다. 이 방식은 RAID-3에 비해 장점이 없다. 에러검출능력이 없는 드라이브를 위해 hamming 오류정정코드를 사용한다. 모든 SCSI 드라이브는 에러검출능력을 갖고 있기 때문에 SCSI 드라이브를 사용할 경우 이 레벨은 별로 쓰이지 않는다.
* 모든 현행 드라이브들이 ECC를 탑재하고 있기 때문에 거의 사용되지 않는다.

RAID3

이 형식은 스트라이프를 사용하며, 패리티 정보를 저장하기 위해 별도의 드라이브 한 개를 쓴다. 내장된 ECC 정보가 에러를 감지하는데 사용된다. 데이터 복구는 다른 드라이브에 기록된 정보의 XOR를 계산하여 수행된다. 입출력 작업이 동시에 모든 드라이브에 대해 이루어지므로, RAID-3은 입출력을 겹치게 할 수 없다. 이런 이유로 RAID-3는 대형 레코드가 많이 사용되는 업무에서 단일 사용자시스템에 적합하다.
* 최소 드라이브 개수 : 3
* 최대 용량 : (디스크의 수 - 1) x 각 디스크의 용량
* 특징 : level 4와 유사하나 효율적인 동작을 위해 동기가능한(synchronized-spindle) 드라이브를 필요로 한다.

RAID4

이 형식은 대형 스트라이프를 사용하며, 이는 사용자가 어떤 단일 드라이브로부터라도 레코드를 읽을 수 있다는 것을 의미한다. 이것은 데이터를 읽을 때 중첩 입출력의 장점을 취할 수 있도록 한다. 모든 쓰기 작업은 패리티 드라이브를 갱신해야하므로, 입출력의 중첩은 불가능하다. RAID-4는 RAID-5에 비해 장점이 없다.
* 최소 드라이브 개수 : 3
* 최대 용량 : (디스크의 수 - 1) x 디스크의 용량
* 특징 : 저렴한 가격으로 장애 복구 능력이 요구되거나 빠른 판독 속도가 필요한 경우에 사용된다. 다량의 데이터 전송이 요하는 CAD나 이미지 작업에 적합하다.

RAID5

데이터에 패리티 정보를 추가해 실패에 대한 내구성을 높였다. 같은 수준에 있는 블럭에 대한 패리티는 쓸 때 저장하고, 읽을 때 검사한다. 이 형식은 회전식 패리티 어레이를 포함한다. 그러므로 RAID-4에서의 쓰기 제한을 주소 지정한다. 그러므로 모든 읽기/쓰기 동작은 중첩될 수 있다. RAID-5는 패리티 정보를 저장하지만 데이터를 중복저장하지는 않는다 (그러나 패리티 정보는 데이터를 재구성하는데 사용될 수 있다). RAID-5는 보통 3 ~ 5개의 디스크를 어레이로 요구한다. RAID-5는 성능이 그리 중요하지 않고 쓰기 작업이 많지 않은 다중 사용자시스템에 적합하다.
* 최소 드라이브 개수 : 3
* 최대 용량 : (디스크의 수 - 1) x 디스크의 용량
* 특징 : 작고 랜덤한 입출력이 많은 경우 더 나은 성능을 제공한다. 빠른 기록속도가 필수적이지 않다면, 일반적인 다중사용자 환경을 위해 가장 좋은 선택이다. 그러나 최소한 3대, 일반적으로는 5대 이상의 드라이브가 필요하다

RAID6

이 형식은 RAID-5와 비슷하지만, 다른 드라이브들 간에 분포되어 있는 2차 패리티 구성을 포함함으로써 매우 높은 고장대비 능력을 제공한다. 현재로서는 RAID-6의 상용 모델은 거의 없다.
* 최소 드라이브 개수 : 3
* 최대 용량 : (디스크의 수 - 2) x 디스크의 용량

RAID7

이 형식은 컨트롤러로서 내장되어 있는 실시간 운영체계를 사용하며, 속도가 빠른 버스를 통한 캐시, 독자적인 컴퓨터의 여러 가지 특성들을 포함하고 있다. 현재 단 하나의 업체만이 이 시스템을 제공한다.

RAID-10

이 형식은 각 스트라이프는 RAID-1 드라이브 어레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-1보다 높은 성능을 제공하지만, 값이 더 비싸다.

RAID-53

이 형식은 각 스트라이프는 RAID-3 디스크 에레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-3보다 높은 성능을 제공하지만, 값이 더 비싸다.

JBOD

SPAN. 하나의 커다란 논리 볼륨을 만들기 위해 여러 디스크를 하나의 파티션으로 사용하는 것이다. 성능이나 비용에 차이는 없다.

• 스트라이프
  여러 개의 디스크에 각 파일의 블럭을 나누어서 저장하는 것.

0024. [유닉스] 고급사용자들의 비밀

Speaking UNIX

UNIX 고급 사용자들이 철저히 지키는 일급 비밀

UNIX？ 고급 사용자들의 비밀을 파헤치기 위해 워터게이트 사무실에 침입하는 것과 같은 모험을 할 필요가 없습니다. 고급 정보를 제공하는 사람이 있는데, 이번 달에는 Martin Streicher가 비밀 이야기를 털어놓는다.

내가 검은 선글라스를 끼고 가짜 콧수염을 달고 프로 컬링 팀 The Floating Stones의 로고가 부착된 야구 모자를 쓰고 있는 이유가 궁금할 텐데, 나는 지금 체포망을 뚫고 도망 중이기 때문이다. 나는 지금 독자들에게 UNIX？ 고급 사용자들이 철저히 지키고 있는 비밀 중 몇 가지를 알려 주기 위해 리모컨으로 조종되는 검은 헬리콥터 편대와 인정 따위는 없어 보이는 창백하게 흰 얼굴의 시스템 관리자들, 귀신같은 솜씨를 지닌 수많은 추적자들의 눈을 피해 이리저리 도망 다니는 중이다. 텔레파시나 세뇌 전파를 막을 수 있는 알루미늄 호일 모자를 쓰고 이 글을 계속 읽기 바란다.

환경 변수 저장

대부분의 UNIX 사용자들은 선호하는 쉘 환경 시간을 계속 다시 작성하기 위해 .bashrc(Bash 쉘용) 및 .zshrc(Z 쉘용)와 같은 쉘 시작 파일에 수많은 설정을 계속 쌓고 있다. 시작 파일을 통해 별명을 작성하고 쉘 옵션을 설정하고 함수를 작성하고 환경 변수를 설정할 수 있다. 필수적인 환경 변수로는 HOME(홈 디렉토리를 지시함), PATH(애플리케이션을 검색할 디렉토리를 열거함) 및 MANPATH(매뉴얼 페이지를 검색하는 디렉토리를 나열함)가 포함된다. 쉘에 어떤 환경 변수가 설정되어 있는지 보려면 printenv를 입력한다. 사용 가능한 환경 변수의 전체 목록은 쉘의 매뉴얼 페이지를 참조한다.

쉘과 마찬가지로, 환경 변수를 통해 다른 많은 UNIX 애플리케이션을 사용자 정의할 수 있다. 예를 들어, Java™ 서브시스템에서 Java 런타임의 루트를 가리키려면 JAVA_HOME을 정의해야 한다. 이와 유사하게, AWS(Amazon Web Services) 유틸리티 패키지에서 유효한 개인용 키 신임 정보를 가진 파일을 가리키려면 AWS_CREDENTIAL_FILE을 사용해야 한다. 개별 애플리케이션에서는 환경 변수도 제공한다. 트릭은 변수를 검색하는 것이다. 다행히도, 이 작업에는 중단 및 입력 과정이 필요하지 않다. 그 대신, 유틸리티 매뉴얼 페이지를 참조하여 "환경 변수"라는 제목으로 따로 나와 있는 섹션을 살펴본다.

예를 들어, 호출기 유틸리티 less에서는 다음과 같이 유용한 환경 변수를 많이 정의한다.

？환경 변수 LESS는 명령행 옵션을 저장하여 호출기를 호출할 때마다 입력 작업량을 줄여준다. 예를 들어, 로그 파일을 많이 읽는 경우 쉘 시작 파일에 다음을 입력한다.

double square-root (export LESS='--RAW-CONTROL-CHARACTERS --squeeze-lines --ignore-case'const double);

이 옵션을 사용하면 각각 제어 문자(보통 구문 색상)를 해석하고 단일 행에 대한 공백 행의 실행 횟수를 줄이고 문자열이 일치하는 경우 대/소문자 구분을 무시할 수 있다. 코드 작업을 하는 경우 다음 옵션을 사용해보자.

export LESS='--LINE-NUMBERS --quit-if-one-screen --quit-on-intr'

？LESSKEY라는 이름의 환경 설정은 키 바인딩 파일을 가리킨다. 키 바인딩을 사용하여 다른 호출기 또는 편집기의 동작에 맞도록 less의 동작을 사용자 정의할 수 있다.
？쉘과 마찬가지로, less를 사용하여 호출 간의 히스토리를 유지 관리할 수 있다. persist 명령 파일을 가리키고 레코드에 대한 최대 명령 개수를 설정하려면 각각 LESSHISTFILE과 LESSHISTSIZE를 설정한다.

환경 변수를 사용하는 또 하나의 좋은 예는 GCC(GNU Compiler Collection)에서 찾아볼 수 있다. GCC는 다양한 환경 변수를 정의하여 작동을 사용자 정의한다. LIBRARY_PATH는 이름에서 알 수 있듯이 링크 대상 라이브러리를 검색하기 위한 디렉토리 목록이다. COMPILER_PATH는 쉘의 PATH와 비슷하지만, 이 환경 변수는 컴파일 프로세스 중에 사용되는 서브프로그램을 찾기 위해 GCC에서 내부적으로 사용된다.

단일 플랫폼에 대한 코드를 쓰고 2진 파일을 빌드하는 경우에는 이런 환경 변수를 절대 사용할 수 없다. 하지만, 많은 수의 플랫폼에 대해 같은 코드를 교차 컴파일하는 경우 그런 변수들은 각 플랫폼에 대해 다양한 헤더와 라이브러리에 액세스하는 데 필수적이다. 한 종류의 시스템에 대해 하나의 값 콜렉션으로 변수를 설정하고 다른 시스템에 대해 다른 콜렉션으로 값을 설정할 수 있다.

사실, GCC에서 큐를 받을 수 있다. 애플리케이션당 많은 환경 변수 세트를 유지 관리하고 수행해야 할 작업에 따라 한 풀에서 다른 풀로 전환한다. 한 가지 접근 방식은 각 프로젝트 디렉토리에 환경 초기화 파일을 보관하고 필요에 따라 source하는 것이다. 예를 들어, 수많은 Ruby 개발자가 이런 해결책을 통해 Ruby 버전 간에 전환함으로써, PATH, GEM_HOME 및 GEM_PATH 환경 변수를 필요에 따라 변경하여 한 버전에서 다른 버전으로 바꾼다.

dot 파일 개요

환경 변수와 마찬가지로, 많은 Linux？ 및 UNIX 애플리케이션에서는 사용자 정의를 위해 dot 파일―이름이 마침표로 시작하는 작은 파일―을 제공한다. 하지만, 소수의 플래그나 상대적으로 소량의 정보를 캡처하는 환경 변수와는 달리, dot 파일은 자체의 고유한 구문 규칙과 경우에 따라서는 자체 프로그래밍 언어까지 가지고 있어, 훨씬 더 광범위하고 복잡하게 구성될 수 있다. (UNIX의 전통에 따라) 점(.)으로 시작하는 파일 이름은 표준 디렉토리 목록에 나타나지 않기 때문에, dot 파일은 옵션과 설정을 보관하기에 편리한 곳이다. (소위 이런 숨겨진 파일을 보려면 ls -a를 사용한다.) dot 파일은 특별한 이름을 제외하면 일반 텍스트 파일이다.

dot 파일은 보통 홈 디렉토리에 있지만, 일부 유틸리티에서는 현재 작업 디렉토리에서도 dot 파일을 찾는다. 애플리케이션에서 둘 이상의 dot 파일을 지원하는 경우, 프로그램에서는 일반적으로 우선 순위 규칙을 적용하여 파일 간의 우선 순위를 정한다. 일반적으로, "로컬" dot 파일― 현재 작업 디렉토리에 있는 dot 파일―의 우선 순위가 가장 높고, 그 다음으로 홈 디렉토리에 있는 dot 파일이 높으며, 나머지는 시스템 전체에 적용되는 구성에 따라 결정된다. 이런 파일들이 없거나 하나 있거나 모두 있을 수 있고, 애플리케이션에 따라 파일을 상호 독점적 또는 점진적인 것으로 다룬다. 앞의 사례에서는 앞선 체인에서 찾은 첫 번째 dot 파일로 결정된다. 그 다음 사례에서는 구성이 계단식으로 이루어지거나 최종 결과로 조정될 수 있다.

간단한 dot 파일의 한 예는 $HOME/.lesskey에 있는 less의 키 바인딩 파일이다. 파일에 있는 각각의 행은 아래의 스니펫과 닮은 형태의 쌍(키 입력과 명령의 쌍)이다.

\r forw-line

\n forw-line

e forw-line

j forw-line

^E forw-line

^N forw-line

k back-line

y back-line

^Y back-line

다른 극단적인 예로서 fetchmail을 생각해보자. 이 유틸리티는 여러 개의 원격 소스에서 이메일을 선택하여 로컬 위치로 메시지를 전달한다. 이 유틸리티의 작동은 $HOME/.fetchmailrc를 통해서만 제어된다. (이 유틸리티의 다양한 옵션에 관해서는 매뉴얼 페이지를 참조한다.) cron, git, vi 및 기타 많은 명령에서도 dot 파일을 인식한다. dot 파일에서 구성하는 항목에 대한 자세한 내용 역시 해당 애플리케이션의 매뉴얼 페이지를 참조한다. 어떤 dot 파일들은 crontab와 같은 별개의 매뉴얼 페이지가 있을 만큼 그 기능이 풍부하고 다양하다.

쉬 . . . SSH에 관한 비밀은...

SSH(Secure Shell)는 ―안전하게 원격 시스템에 로그인하고 파일을 복사하고 방화벽을 통해 터널링하는 데 사용하기 위해 다양한 기능을 갖춘 서브시스템이다. SSH는 서브시스템이므로, 작동을 사용자 정의하고 효율적으로 수행하기 위한 수많은 옵션을 제공한다. 사실, SSH에서는 모든 데이터를 포함하기 위해 $HOME/.ssh라는 이름의 전체 "dot 디렉토리"가 제공된다. (다른 사용자의 액세스를 방지하려면 .ssh 디렉토리가 600 모드여야 한다. 600 이외의 모드는 올바른 작동에 방해가 된다.) 특히, $HOME/.ssh/config 파일을 통해 시스템 이름, 호스트별 액세스 제어 등을 포함한 수많은 바로 가기를 정의할 수 있다.

다음은 특정 호스트에 대한 SSH를 사용자 정의하기 위해 $HOME/.ssh/config에서 찾을 수 있는 전형적인 블록이다.

Host worker

HostName worker.example.com

IdentityFile ~/.ssh/id_rsa_worker

User joeuser

~/.ssh/config에 있는 각각의 블록에서는 하나 이상의 호스트를 구성한다. 개별 블록은 공백 행으로 구분한다. 이 블록에서는 Host, HostName, IdentityFile 및 User의 네 가지 옵션을 사용한다. Host 옵션을 사용하면 HostName으로 지정되는 시스템의 별명을 설정할 수 있다. 예를 들어, 별명을 사용하면 ssh worker.example.com 대신 ssh worker로 입력할 수 있다. 또한, IdentityFile 및 User 옵션을 사용하면 worker에 로그인하는 방법을 정할 수 있다. IdentityFile 옵션은 호스트와 함께 사용하기 위한 개인용 키를 가리키고, User 옵션을 사용하면 로그인 ID가 제공된다. 따라서 이 블록은 다음 명령과 같은 것이다.

ssh joeuser@worker.example.com -i ~/.ssh/id_rsa_worker

강력하지만 잘 알려져 있지 않은 옵션이 바로 ControlMaster이다. 이 옵션을 설정하면 같은 호스트에 대해 여러 개의 SSH 세션이 단 하나의 연결을 공유한다. 첫 번째 연결이 설정된 후에는 후속 연결에 신임 정보가 필요하지 않으므로, 같은 시스템에 연결할 때마다 비밀번호를 입력해야 하는 번거로움이 없다. ControlMaster는 매우 편리한 옵션이므로, 모든 시스템에서 이 옵션을 사용하고 싶을 것이다. 다음과 같이 호스트 와일드카드 *로 손쉽게 설정할 수 있다.

Host *

ControlMaster auto

ControlPath ~/.ssh/master-%r@%h:%p

짐작할 수 있겠지만, Host * 태그로 표시된 블록은 구성 파일에서 명시적으로 이름이 지정되어 있지 않더라도 모든 호스트에 적용된다. ControlMaster auto는 기존 연결을 다시 사용하려고 시도하지만, 공유 연결을 찾을 수 없는 경우 새로 연결할 것이다. ControlPath는 공유를 위한 제어 소켓을 지속하는 파일을 가리킨다. %r은 원격 로그인 사용자 이름으로 바뀌고, %h는 대상 호스트 이름으로 바뀌고, %p는 연결에 사용되는 포트를 대신한다. (%l을 사용하여 로컬 호스트 이름으로 바꿀 수도 있다.) 위 스펙에서는 파일 이름이 다음과 유사한 제어 소켓이 생성된다.

master-joeuser@worker.example.com:22

원격 호스트에 대한 모든 연결이 이루어지면 각각의 제어 소켓이 제거된다. 언제든지 어떤 시스템에 연결되어 있는지 알고 싶으면 ls ~/.ssh를 입력하고 제어 소켓의 호스트 이름 부분(%h)을 보면 된다.

SSH 구성 파일은 매우 방대하여 자체 매뉴얼 페이지도 있다. 가능한 옵션을 모두 보려면 man ssh_config를 입력한다. 그리고 여기서는 영리하게 활용할 수 있는 SSH 트릭이 있다. 즉, SSH를 통해 로컬 시스템에서 원격 시스템으로 터널링할 수 있다. 사용할 명령행은 다음과 같다.

$ ssh example.com -L 5000:localhost:3306

이 명령은 "example.com을 통해 연결하고 로컬 시스템의 포트 5000과 'localhost'라는 이름의 시스템에 있는 포트 3306[MySQL 서버 포트] 사이에 터널을 설정하라"는 의미이다. localhost는 터널이 설정되면서 example.com에서 해석되기 때문에, localhost가 example.com이다. 아웃바운드 터널 ―정식 명칭은 로컬 전달(local forward)―이 설정된 상태에서, 로컬 클라이언트는 포트 5000에 연결하여 example.com에서 작동 중인 MySQL 서버와 통신할 수 있다.

터널링의 일반적인 양식은 다음과 같다.

$ ssh proxyhost localport:targethost:targetport

여기서 proxyhost는 SSH를 통해 액세스할 수 있고 targethost에 (SSH를 통해서가 아니라) 네트워크로 연결되는 시스템이다. localport는 로컬 시스템에 대한 권한이 없는 포트(1024를 초과하여 사용되지 않는 모든 포트)이고, targetport는 사용자가 연결하려는 서비스의 포트이다.

이전 명령을 실행하면 시스템에서 외부 세계로 터널링할 수 있다. SSH를 사용하여 내부로 터널링하거나 외부 세계에서 로컬 시스템에 연결할 수도 있다. 다음은 인바운드 터널의 일반적인 양식이다.

$ ssh user@proxyhost -R proxyport:targethosttargetport

인바운드 터널―정식 명칭은 원격 전달(remote forward)―을 설정하면 proxyhost 및 targethost의 역할이 뒤바뀌어, 로컬 시스템이 대상이 되고 원격 시스템이 프록시가 된다. user는 프록시에서의 로그인 ID다. 이 명령의 구체적인 예제는 다음과 같다.

$ ssh joe@example.com -R 8080:localhost:80

이 명령은 "example.com에 joe로 연결하고 원격 포트 8080을 로컬 포트 80에 연결하라"는 의미이다. example.com에서 사용자가 이 명령을 실행하면 Joe의 시스템에 터널이 제공된다. 원격 사용자는 8080에 연결하여 Joe의 시스템에 있는 웹 서버에 도달할 수 있다.

각각 로컬 및 원격 전달을 위한 -L 및 -R 외에도, SSH는 원격 시스템에서 HTTP 프록시를 만들기 위한 -D를 제공한다. 알맞은 구문은 SSH 매뉴얼 페이지를 참조한다.

히스토리를 이용해 다시 쓰기

쉘 프롬프트에서 많은 시간을 작업하는 경우 쉘 히스토리를 기록하면 시간을 절약하고 입력 작업량을 줄일 수 있다. 그러나 히스토리를 수정하지 않은 상태로 두면 히스토리를 사용할 때 약간 성가신 부분이 있다. 히스토리에서는 중복 명령이 기록되고 여러 쉘 인스턴스에서 서로의 히스토리에 나쁜 영향을 줄 수 있다. 두 가지 복잡한 문제 모두 쉽게 극복된다. 다음과 같이 .bashrc에 두 행을 추가한다.

export HISTCONTROL=ignoreboth

shopt -s histappend

첫 행은 쉘 히스토리에서 연속적으로 중복된 명령을 제거하는 역할을 한다. 순서에 상관없이 중복된 명령을 모두 제거하려면 ignoreboth를 erasedups로 변경한다. 둘째 행은 쉘 종료 시 히스토리 파일에 쉘의 히스토리를 추가하는 역할을 한다. 기본적으로, Bash 히스토리 파일은 ~/~/.bash_history(dot 파일임)로 이름이 지정된다. HISTFILE(환경 변수)을 설정하여 위치를 변경할 수 있다. 100,000개의 항목이 있는 히스토리 파일에 셀의 최근 10,000개 명령을 저장하려면 쉘 시작 파일에 export HISTSIZE=10000 HISTFILESIZE=100000을 추가한다. 쉘의 히스토리를 보려면 어떤 프롬프트에든 history를 입력하면 된다.

명령 히스토리를 저장하더라도 다시 불러올 수 없다면 거의 쓸모가 없다. ! 쉘 또는 bang 연산자의 목적이 바로 그것이다.

？!! ("bang bang")으로 마지막 명령을 완전히 반복할 수 있다.
？!:0은 이전 명령의 이름이다.
？!^은 이전 명령의 첫 인수이다. !$로 끝나는 !:2, !:3 등은 이전 명령의 두 번째, 세 번째 등의 인수이며, 결국 마지막 인수까지 표시할 수 있다. ？!*는 명령 이름을 제외한 마지막 명령의 모든 인수를 의미한다.
？!n은 히스토리에서 n이라는 번호가 매겨진 명령을 반복하는 역할을 한다.
？!handle로 handle에서 문자열로 시작하는 마지막 명령을 반복할 수 있다. 예를 들어, !ca를 사용하여 cat README와 같이 ca 문자로 시작한 마지막 명령을 반복할 수 있다.
？!?handle로 handle에서 문자열을 포함한 마지막 명령을 반복할 수 있다. 예를 들어, !?READ는 cat README와도 일치한다.
？^original^substitution을 사용하여 original의 첫 번째 항목을 substitution으로 바꿀 수 있다. 예를 들어, 이전의 명령이 cat README였다면 ^README^license.txt 명령을 실행하는 경우 cat license.txt라는 새 명령이 생성된다.
？!:gs/original/substitution을 사용하면 original이 나타날 때마다 모두 substitution으로 바뀐다. (!:gs는 "global substitution"을 의미한다.)
？!-2는 두 번째 명령이고, !-3은 최근 명령 중 세 번째 명령이라는 식이다.
히스토리 표현식을 결합하여 두 번째 명령의 명령 이름 뒤에 -R, 이전 명령의 첫 번째 인수, 세 번째 최근 명령의 두 번째 인수를 붙여 확장되는 !-2:0 -R !^ !-3:2와 같은 조합을 만들 수도 있다. 이처럼 비밀스러운 명령을 더 쉽게 읽을 수 있도록, 입력할 때 히스토리 참조를 확장할 수 있다. 어떤 프롬프트에서나 bind Space:magic-space 명령을 입력하거나 시작 파일에 이 명령을 추가하여 히스토리 대체를 인라인 상태로 확장하는 magic-space 함수에 스페이스 키를 바인딩한다.

Expand-o-Matic

이처럼 많은 코드를 인터넷에서 구할 수 있으므로, 매일 수십 개의 파일을 다운로드할 수도 있을 것이다. 그리고 그런 모든 파일들은 아마 다르게 패키징될 것이다.―각각 다른 유틸리티로 압축되지만, 경우에 따라 ZIP 파일, RAR 파일 및 수많은 TAR 파일로 패키징된다. 각각의 패키지 형식을 압축 해제하고 확장하는 방법을 일일이 기억하기 어려울 수 있다. 그렇다면, 그 모든 작업을 단일 명령에 캡처하지 못할 이유도 없다. 이 함수는 많은 샘플 dot 파일에서 널리 사용할 수 있다.

ex () {

if [ -f $1 ] ; then

case $1 in

*.tar.bz2) tar xjf $1 ;;

*.tar.gz) tar xzf $1 ;;

*.bz2) bunzip2 $1 ;;

*.rar) rar x $1 ;;

*.gz) gunzip $1 ;;

*.tar) tar xf $1 ;;

*.tbz2) tar xjf $1 ;;

*.tgz) tar xzf $1 ;;

*.zip) unzip $1 ;;

*.Z) uncompress $1 ;;

*.7z) 7z x $1 ;;

*) echo "'$1' cannot be extracted via extract()" ;;

esac

else

echo "'$1' is not a valid file"

fi

}

이 ex 함수는 11가지 파일 형식으로 확장되고 다른 패키지 유형을 다루는 경우 확장 가능하다. 이 함수가 정의된 후에는,―예컨대 쉘 시작 파일에서―간단히 ex somefile을 입력하면 되며, 여기서 somefile은 명명된 확장자 중 하나로 끝난다.

$ ls

source

$ tar czf source.tgz source

$ ls -1

source

source.tgz

$ rm -rf source

$ ex source.tgz

$ ls -1

source

source.tgz

그런데 오늘 다운로드한 것을 잘못된 위치에 둔 경우에도 find를 실행하여 검색할 수 있다.

$ find ~ -type f -mtime 0

-type f 명령으로는 일반 파일을 찾을 수 있고, 당일 자정 이후로 작성된 파일을 찾으려면 -mtime 0 명령을 사용한다.

훨씬 더 많은 비밀

아직도 전문가들만이 간직한 비밀이 많이 남아 있다. 웹에서 "shell auto-complete"를 검색하면 명령을 입력할 때 상황에 맞게 명령을 확장해주는 기능인 자동 완성 기능에 대해 더 자세히 살펴볼 수 있다. 또한, "shell prompts"를 검색하면 쉘 프롬프트를 사용자 정의하는 방법을 확인할 수 있다. 이것을 다채롭게 만들 수 있다. 즉, 현재 작업 디렉토리나 Git 분기를 표시하거나―다량의 히스토리를 불러오는 경우 편리하게 참조할 수 있는 히스토리 번호를 표시할 수도 있다. 작업 예를 보려면 Github에서 "dot files"를 검색한다. 많은 전문가들이 Github에 자신의 쉘 구성을 공개하고 있다.

실례지만, 이제 내 가발과 브론저 크림을 찾으러 가야겠다. 그루초 막스(미국의 희극 배우, 1890-1977)와 닮게/P>

0010. OS 커널 확인 방법

솔라리스 커널 Bit 확인법 솔라리스/sparc 7 이상의 운영체제는 32bit 와 64bit 로 나누어진다.

자신의 시스템의 OS가 64bit 인지 32bit 인지는 isainfo -kv 라는 명령으로 확인할 수가 있다.

# isainfo -kv
64-bit sparcv9 kernel modules

위와 같은 결과는 64bit를 뜻한다.

단, 이것은 Sparc 버전의 솔라리스에만 해당되고 Intel 버전의 솔라리스는 32Bit 이다.

######################################################################

[UNIX] solaris의 32bit or 64bit booting..
솔라리스 7은 인스톨 하실때 64비트로 설치를 할것인지를 물어보는 단계가 있습니다.
이단계에서 64비트를 선택하시면 64비트와 32비트를 모두 사용하실수 있습니다.
그러나, 굳이 한가지로만 사용하신다면 아래와 같이 하시면 됩니다.

i) 64비트 또는 32비트로 부팅할 수있는지의 여부판단

(ns>root)/# isalist

만약 sparcv9 를 볼 수 없다면 64비트로 부팅할 수 없습니다.

ii)현재 64비트 모드인지 32비트 모드인지 볼려면

(ns>root)/# isainfo -v
64-bit sparcv9 application
32-bit sparc application
위와같이 출력된다면 시스템은 64비트로 운영중인 것입니다.

그러나 아래와 같이한 line만 출력된다면 32비트로 부팅되어 있는 상태입니다.
32-bit sparc application

iii) 부팅할때 64비트 혹은 32비트로 부팅하고자 할때
리부팅을 시키신후 시스템이 올라올때 stop + A를 누르신후
ok> prompt상에서 환경설정을 다음과 같이 하시면 됩니다.

- 32비트로 부팅
ok> setenv boot-file=kernel/unix
ok> reset

- 64비트로 부팅
ok> setenv boot-file=kernel/sparcv9/unix
ok> reset

### 멀티 유저 일때는
/platform/sun4u/boot.conf 화일을 아래와 같이 변경한 후 시스템을 rebooting한다.

# vi /platform/sun4u/boot.conf

ALLOW_64BIT_KERNEL_ON_UltraSPARC_1_CPU=true

# reboot

##############################################################################################

AIX 에서 비트 확인 하는 방법 root 권한으로

bootinfo -K를 하시면 설치된 OS의 비트를 확인할 수 있습니다.

vi /etc/rc.local

touch /var/lock/subsys/local

/sbin/route add -net 172.16.2.0/24 gw 203.251.60.100

solaris 10

route add 192.0.2.32 -netmask 255.255.255.224 somegatewa

□ HA 데몬상태

# ps -ef|grep had

root 11227 1 015:02:52 ? 0:00 /opt/VRTSvcs/bin/hashadow

root 11203 1 1 15:02:52 ? 0:04 /opt/VRTSvcs/bin/had

→ 위와같이 had, hashadow 데몬이떠있으면정상

□ LLT Heartbeat Link 상태

# lltstat -n

LLT node information:

Node State Links

* 0 dbms1 OPEN 2

1 dbms2 OPEN 2

→위와같이각 Links 가 2개로보이면정상

□ GAB Membership Port 확인

# gabconfig -a

GAB Port Memberships

===============================================================

Port a gen e65507 membership 01

Port h gen e65524 membership 01

→위와같이 a, h 포트가떠있으며 membership이 0번 node 와 1번 node 가보이면정상

□ HA Status 확인

# hastatus -sum

-- SYSTEM STATE

-- System State Frozen

A dbms1 RUNNING 0

A dbms2 RUNNING 0

-- GROUP STATE

-- Group System Probed AutoDisabled State

B Oracle dbms1 Y N OFFLINE

B Oracle dbms2 Y N ONLINE

→ 위와같이 Oracle Service Group 이 dbms2 에서 ONLINE 인지확인

□ Virtual IP 확인

# ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:30:6E:F3:52:31

inet addr:192.168.254.222 Bcast:192.168.254.255 Mask:255.255.255.0

inet6 addr: fe80::230:6eff:fef3:5231/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:69518290 errors:0 dropped:0 overruns:0 frame:7

TX packets:86250448 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:12808034148 (11.9 GiB) TX bytes:82464026785 (76.8 GiB)

Interrupt:56

eth0:0 Link encap:Ethernet HWaddr 00:30:6E:F3:52:31

inet addr:192.168.254.221 Bcast:192.168.254.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

Interrupt:56

.

.

.

→위와같이 eth0:0 에 221번 VIP 가올라가있으면정상

□ Mount 여부확인

# df -k

→ oracle, data1, data2, data3 의각 mount point 들이보이며 access 가능하면정상

□ VCS Engine Log 확인

# vi /var/VRTSvcs/log/engine_A.log

→ 특별한 이슈나 error 메시지는 없는지 확인

0003. 유용한 커맨드

1. xargs 명령은 입력된 데이터를 라인단위로 읽어서 아규먼트화 하는 명령이다.

find 명령을 사용하여 파일을 삭제하고자 할때 유용하다.

# find . -type f -mtime +1 | xargs -n 100 rm -f

find 명령을 사용하여 현재 디렉토리 하에서 현재시간보다 하루(+) 전(24시간 내에 작성/변경된 파일만 제외)에 작성/변경된 파일을 찾으면 라인단위로 파일 리스트가 쉘에 출력되는데, 이 파일 리스트는 하나의 라인당 하나의 파일명이 출력되므로 각 라인의 파일명을 아규먼트화하기 위해 xargs를 파이프로 연결한 다음 -n 100 즉, 100 라인(100개 아규먼트)를 한번에 읽어서 rm -f [아규먼트]로 치환하여 100개 단위로 검색된 파일들을 삭제하는 것이다.

[root@localhost shell]# man xargs | col -b | cat
XARGS(1) XARGS(1)

NAME
xargs - build and execute command lines from standard input

SYNOPSIS
xargs [-0prtx] [-E eof-str] [-e[eof-str]] [--eof[=eof-str]] [--null]
[-d delimiter] [--delimiter delimiter] [-I replace-str] [-i[replace-
str]] [--replace[=replace-str]] [-l[max-lines]] [-L max-lines]
[--max-lines[=max-lines]] [-n max-args] [--max-args=max-args] [-s

2. iNode 확인 방법
df -F ufs -o i

3. 압축
----------------------------------------------------------------
#tar 압축 cvf 옵션으로 ...

tar cvf abc.tar def/ WEB-INF/ a.jsp ghi/ b.jsp c.jsp
gzip -9 *20100[4-6]*
#한번더 압축 gzip

gzip abc.tar

----------------------------------------------------------------
#풀때
----------------------------------------------------------------

tar 로 압축되었을 경우 cvf 와는 반대로 xvf를 사용하시면 됩니다.

# tar xvf c.gzip

라고 하시면 압축이 풀릴겁니다.

물론 x 옵션만 사용하셔도 되지만 vf 는 압축해제 하면서 파일리스트도 출력하게 해 줍니다.

gzip으로 압축되었다면 gunzip 로 풀수 있습니다.

# gunzip c.gzip

라고 하시고 디렉토리 보시면 풀려 있을겁니다.

질문 추가 한 곳을 보면 잘 이해가 되지는 않네요.
tar cvf *.c 라고 하셨다면... 조금 난감한 상황이 생길 수도 있습니다.
ls 명령으로 보면 처음에 오는 파일에다가 그 디렉토리에 있는 모든 *.c 파일이 결합되어집니다. 다시 풀수는 있지만... 결합되어져 버린 첫번째 파일은 사용못할 수도 있습니다.

----------------------------------------------------------------
#추가
----------------------------------------------------------------

<< 압축하기 >>
* tar 와 gzip 따로 하기
# tar cvf file_name.tar *.c
# gzip file_name.tar

* tar 와 gzip 동시에
# tar cfp - target_dir | gzip -c > made_file.tar.gz

tar cfpv - ./201007* ilkacs_201007*.log tar |gzip -c > acs_201007.tar.gz

// target_dir = 압축할 파일들이 들어 있는 디렉토리
// made_file = 만들어질 압축파일의 이름.

<< 압축풀기 >>
* tar 와 gzip 따로 하기
# gzip -d file_name.tar.gz
# tar -xvf file_name.tar

* tar 와 gzip 동시에
# gzip -dc source_file.tar.gz | tar xvfp

4. CPIO 파일 만들기

cpio 를 이용한 특정 확장자 파일만 압축하기.

# find . -name '*.c' -print | cpio -o > data.cpio

# ls | cpio -o > ../test.cpio

CPIO 파일 풀기

-i cpio로 백업한 data를 restore 한다

-o 출력 - 묶을때
-p 통과모드

-d restore중 필요한 디렉토리를 자동으로 생성시킨다
-m 백업 되있는 data들의 날짜, 시간을 그대로 유지한다
-v verbose

# cpio -idmv < test.cpio

# cpio -i < data.cpio

# cpio -dmvi < example.cpio

# cpio -dmvi < /root/test.cpio

gz으로 압축되어 있는것을 풀기

예1:

# gunzip targetfile.cpio.gz
# cpio -idmv < targetfile.cpio

예 2:

# zcat targetfile.cpio.gz | cpio -idmv

압축 하여 CPIO 만들기

tar 를 이용한 특정 확장자 파일 압축하기 (리눅스)

find . -name "*.c" | xargs tar -cvf soure.tar

xargs 를 파라미터 수가 제한적이어서, 파일수가 많으면 불가능함.

cpio로 파일 옮기기

한 디렉토리 또는 파일시스템에서 다른 디렉토리 또는 파일시스템으로 옮겨야 할 대량의 파일이 있을 경우 다음의 명령을 이용

# find /old_directory -depth | cpio -pdmv /new_directory

이 명령은 소유자와 권한, 디렉토리 구조를 유지하면서 지정한 old_directory 밑의 모든 파일을 new_directory로 옮긴다.

# cd src_dir_name

# find . -depth -print | cpio -pudm target_dir_name

5.rpm 설치

1. #rpm -Uvh test-1.2.3.src.rpm

: test.src.rpm을 /usr/src/<vender_name_dir>/SPEC 에 SPEC 파일과

/usr/src/<vender_name_dir>/SOURCES/ 에 소스를 설치 한다.

기존에 설치된 패키지가 있을 경우 업그레이드를 한다. -ivh 보다 많이 사용한다.

#rpm -Uvh test-1.2.3.rpm

: test-1.2.3.rpm 을 설치 한다. 기존에 test 라는 낮은 버젼의 패키지가 있으면 업그레이드. 없으면 그냥 -ivh 처럼 설치가 된다.

#rpm -ivh test-1.2.3.rpm

: test-1.2.3 을 처음으로 설치 한다. 처음 설치가 아니더라도 -Uvh 를 사용해도 무관 하다.

1. 설치된 rpm 제거

#rpm -e test

: test 라는 이름의 패키지를 제거 한다.

#rpm -evv test

: test 라는 패키지를 제거 하는 과정을 보여 준다.

1. 설치된 패키지 정보 보기

#rpm -qi test

: test 가 설치 되어 있다면, test 패키지에 대한 설명이 주루룩 뜰것 이다. 아래는 예...

유저 확인 스크립트

#!/bin/ksh
for i in `cat /tmp/users`
do
last -R | grep $i | head -1 | awk '{print $1, $5, $6}' >> users.out
done
chmod +x /tmp/users.sh

#!/bin/ksh
for i in `cat /tmp/users`
do
last -a | grep $i | head -1 | awk '{print $1":", $4, $5}' >> users.out
done

메뉴 스크립트

case $answer in

1) . /u04/app/oracrp4/CRP4/apps/apps_st/appl/APPSCRP4_dev-db.env;
PS1='[$TWO_TASK] $PWD> ';;
2) . /u04/app/oracrp4/CRP4/db/tech_st/10.2.0/CRP4_dev-db.env;
PS1='[$ORACLE_SID] $PWD> ';;
3) . /u04/app/oracrp4/CRP4/inst/apps/CRP4_dev-db/ora/10.1.3/CRP4_dev-db.env;
PS1='[$TWO_TASK] $PWD> ';;
*) . /u04/app/oracrp4/CRP4/apps/apps_st/appl/APPSCRP4_dev-db.env;
PS1='[$TWO_TASK] $PWD> ';;
esac