/bin/false allows a login, but no shell, no ssh tunnels and no home directory.

/sbin/nologin disallows logins completely and returns a polite account unavailable message.



Posted by linuxism
,

리눅스 파티션 나누기

60G 정도의 하드 디스크와 1G의 RAM을 탑재한 하드웨어에 설치한다고 가정하고 우분투 리눅스의 파티션 분할의 예시를 들어 보겠습니다.

리눅스 파티션의 종류와 용도

 파티션할당 용량 
 /3072 MB 
 /boot150M 
 /usr6000 MB 
 /tmp1024M 
 swap2048MB (RAM 용량의 2배)
 /usr/local1024MB 
 /home나머지 모두 할당 
 /var5120MB



메일서버로 활용할 경우

 파티션할당 용량 
 /루트 파티션. 바이너리 디렉토리 /bin, /sbin 디렉토리와 시스템 및 네트워크 설정 파일 디렉토리인 /etc 등을 포함한다.
 /boot부팅 커널이 저장됨
 /usr리눅스 시스템에 필요한 대부분의 바이너리 파일들과 라이브러리 파일, 커널 소스 그리고 X-Window 파일들이 설치되는 파티션으로 넉넉한 용량을 요구한다. (응용프로그램 설치 디렉토리)
 /tmp임시 파일이 저장됨
 swapRAM이 부족할 경우 사용되는 공간 (가상메모리)
 /usr/localapahche, proftpd 등의 (주로 소스를 직접 컴파일 하여 설치해야 하는) 프로그램들의 설치 공간
 /home사용자 계정이 위치하는 곳으로 루트 파티션이 포함될 수 있다.
 /var로그, 캐시 파일 등이 저장된다. 또한 웹 서버의 기본 디렉토리 위치 및 메일 서버에서 수신된 이메일들이 저장되는 곳이기도 하기 때문에 용도에 따라서 큰 용량을 부여해야 하는 경우도 있다. (메일 서버 등)



네임서버로 활용할 경우

 파티션할당 용량 
 /3072 MB 
 /boot150M 
 /usr6000 MB 
 /tmp1024M 
 swap2048MB (RAM 용량의 2배)
 /usr/local1024MB 
 /home1024MB 
 /var나머지 모두 할당 



웹서버로 활용할 경우

 파티션할당 용량 
 /3072 MB 
 /boot150M 
 /usr6000 MB 
 /tmp1024M 
 swap2048MB (RAM 용량의 2배)
 /usr/local1024MB 
 /home나머지 모두 할당 
 /var5120MB



메일서버로 활용할 경우

 파티션할당 용량 
 /3072 MB 
 /boot150M 
 /usr6000 MB 
 /tmp1024M 
 swap2048MB (RAM 용량의 2배)
 /usr/local1024MB 
 /home1024MB 
 /var나머지 모두 할당 



DB서버로 활용할 경우

 파티션할당 용량 
 /3072 MB 
 /boot150M 
 /usr6000 MB 
 /tmp1024M 
 swap2048MB (RAM 용량의 2배)
 /usr/local1024MB 
 /home1024MB 
 /var나머지 모두 할당 

출처 - http://hoyanet.pe.kr/1985


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


리눅스를 설치할 때 필요한 최소한의 파티션은 2개입니다. 루트파티션(/)과 swap만 있으면 되죠. 
만약 리눅스만을 설치하여 운영하시는 거라면 파티션을 더 세밀히 나누기를 권장합니다.

 



/var : 이 디렉토리는 로그파일과 프린터 스풀(프린터로 가는 파일을 임시저장) 메일스풀의 용도로 사용됩니다.

 

이 디렉토리는 로그파일 때문에 크기가 지속적으로 커진다는 특성을 가지고 있습니다. 이 디렉토리를 별도의 파티션으로 나누지 않는다면 시스템의 안정성에 좋지않은 영향을 줄 수 있습니다. 계속 사이즈가 증가하여 루트파티션을 몽땅 차지해 버릴 수 있기 때문이죠.

 

이 경우 종종 시스템이 다운됩니다. 따라서 /var는 별도의 파티션으로 나누는 것이 바람직합니다. /var를 파티션으로 나눈다면 크기는 하드의 용량과 시스템의 사용용도 등에 따라 다르겠지만 서버가 아니라면 256-512MB정도면 충분합니다.


서버라면 회사의 정책에 따라 (이를 테면 로그를 한달동안 보관해야 한다든지...) 사이즈를 결정하시면 됩니다. 대략.. 하루에 남는 로그의 양 * 필요 보관 일수 * 1.5 정도로 계산하시면 됩니다.

/home : 이 디렉토리는 사용자들의 홈 디렉토리입니다.

 

/home을 별도의 파티션을 이용하여 구성하게 되면 백업하기가 쉽고 사용자가 늘었을 때 /home을 확장하기가 쉬워집니다. 따라서 이 부분도 대부분 별도의 파티션으로 구성하게 됩니다. 사이즈는 사용자당quota크기 * 사용자수 * 1.5정도면 됩니다.



/tmp : 이 디렉토리는 임시 파일들이 생성/소멸되는 곳입니다.

 

굉장히 동적인(writing이 자주 발생하는..) 특성을 가지고 있습니다. 이러한 부분을 별도의 파티션으로 분리하면 시스템의 안정성을 높일 수 있습니다.

 

예를 들어 커널이나 중요 프로그램이 저장된 곳과 /tmp가 동일 파티션이라면 잦은 access로 인해 하드디스크에 fail이 발생할 경우 kernel이 손상을 입을 가능성이 아무래도 파티션을 분리했을 때보다 클 것입니다. (동일 파티션의 파일들을 디스크상에서 비슷한 곳에 저장됩니다.) 

또한 이 디렉토리는 누구나 읽고 쓸 수 있다는 특성 때문에 다른 디렉토리에 접근 권한을가지고 있지 못하는 공격자들이 공격툴을 런칭하는 곳으로 사용되기도 합니다. 따라서 /tmp에 저장되어 있는 프로그램들을 실행하지 못하도록 한다면 보안을 아주 아주 조금은 향상시킬 수 있을 것입니다.

 

유닉스/리눅스에서는 특정 파티션에 존재하는 프로그램들을 실행시키지 못하도록 제어할 수 있습니다. 따라서 이러한 기능을 이용하기 위해서는 /tmp를 별도의 파티션으로 구성해야 합니다. 사이즈는 그리 크지않아도 됩니다.



/usr : 이곳에는 주로 유틸리티들이 저장됩니다.

 

이 디렉토리는 굉장히 정적인 특성을 가지고 있습니다.(write보다는 reading 이 주로일어납니다.) 백업을 비롯한 여러가지 이유때문에 이 디렉토리 역시 별도의 파티션으로 구성하면 편리합니다.

 

OS에따라 사용하는 애플리케이션의 종류와 그 크기에 따라 /usr의 크기는 달라지겠지만 RedHat Linux라면.. 3GB정도면 기본 애플리케이션들을 full로 설치할 수 있을 것입니다. 나중을 위해서 좀 더 넉넉하게 잡아두는 것도 좋겠지만 너무 많이 잡아두면 쓸데없이 하드디스크 공간을 낭비하게 됩니다.


/swap : 이곳에는 페이징 파일이 할당 됩니다.

 

메모리의 2배수가 적당하다고는 하나 어디까지나 상식적인 선에서 결정하셔야 합니다. 이를테면 메모리가 512MB이므로 스왑은 1G를 잡아야 겠다.


역시 어떠한 프로그램을 사용하시느냐에 따라 다르겠지만 일반적으로 1G 이상의 스왑영역을 잡는 것은 사실 낭비의 요소가 많습니다.


* 추가 설명 *
현재 사용하고 있는 하드디스크의 파티션을 나누려면 가급적 중요한 내용을 다 백업하시고 다시 파티션을 나누는 것이 좋습니다. 또한 그렇게하시길 권장합니다.

하지만 파티션매직과 같은 프로그램을 이용하시면 기존의 내용을 그대로 둔 채 파티션을 조정할 수 있습니다.


출처 - http://kerrigan.egloos.com/2329642





Posted by linuxism
,


데이터 모델링 분야에서 개체-관계 모델이란 구조화된 데이터에 대한 일련의 표현이다.

서로 관계된 두 개의 엔티티

"구조"화된 데이터를 저장하기 위해 데이터베이스를 쓴다. 이 데이터의 "구조" 및 그에 수반한 제약 조건들은 다양한 기법에 의해 설계될 수 있다. 그 기법 중 하나가 개체-관계 모델링(Entity-Relationship Modelling)이다. 줄여서 ERM이라고 한다. ERM 프로세스의 산출물을 가리켜 개체-관계 다이어그램(Entity-Relationship Diagram)이라 한다. 줄여서 ERD라 일컫는다. 데이터 모델링 과정은 데이터 모델을 그림으로 표현하기 위해 표시법을 필요로 한다. ERD는 개념적 데이터 모델 혹은 시맨틱 데이터 모델의 한 타입이다.

목차

  [숨기기

[편집]사용처

정보 시스템을 디자인 해나가는 데에 위와 같은 모델들을 사용하여 시스템이 필요로 하는 정보를 기술한다든가 데이터베이스에 저장되어야 할 정보의 타입(type)이 무엇인가 분석해 나갈 수 있다. 특히 요구사항 단계에서 말이다.

어떤 도메인 오브 디스코스(관심 대상이 되는 부분)의 온톨로지를 기술할 때, 데이터 모델링 테크닉이 사용될 수 있다. (사용된 텀들(terms)과 그들과의 관계를 정의하고 분류하는 일이다.) 데이터베이스에 기반한 정보 시스템(information system)을 디자인하고자 하는 경우에는 나중에 가서는(논리 설계 단계) 개념 데이터 모델은 논리적 데이터 모델로 맵핑된다. 논리적 데이터 모델은 관계형 모델 같은 것이다; 뒤이어 논리적 데이터 모델은 물리 설계 단계에서 물리적 디자인 모델로 다시 맵핑된다. 단, 이와 같은 단계를 모두 뭉뚱그려 "물리 설계"라고 일컫기도 한다.

개체-관계 다이어그램(ERD)를 그리는 데에는 수많은 관습/방법(convention)이 존재한다. ERD를 그리는 데 아주 고전적인 방법이 이 문서의 아래에 기술되어 있다. 아래 기술된 방법은 개념 모델링과 주로 연관되어 있다.

데이터베이스 논리설계 및 물리설계 단계에서는 관습적으로 쓰이는 노테이션(notation)들이 몇 가지 더 있다. 예를 들면 인포메이션 엔지니어링,IDEF1X (ICAM DEFinition Language), 디멘저널 모델링 같은 것들이다.

[편집]전통적인 다이어그램 컨벤션

서로 관계된 두 개의 엔티티
애트리뷰트를 갖는 엔티티
애트리뷰트를 갖는 관계
ER 다이어그램 예제

개체(엔티티)는 분리된 물체 하나를 표현한다. 엔티티는 명사 하나에 해당한다고 생각하면 쉽다. 예를 들면 다음과 같다: 컴퓨터(1개), 사람(1명), 악곡(1개), 수학적 정리(1개). 엔티티는 사각형으로 표시된다.

관계(릴레이션쉽)는 두 개 이상의 엔티티들이 어떻게 서로 연관되어 있나를 기록한다. 예를 들면 다음과 같다: 회사와 컴퓨터 사이의 "소유하다"라는 관계, 상사와 부하 직원 사이의 "감독하다"라는 관계, 연주자와 악곡 사이의 "연주"라는 관계, 수학자와 수학 정리 사이의 "증명했다"라는 관계 등이다. 관계는 다이아몬드형으로 그리는데, 관계된 엔티티와는 실선으로 연결한다.


엔티티도 애트리뷰트를 가질 수 있고, 관계로 애트리뷰트를 가질 수 있다. 예를 들면 다음과 같다: 피고용인 엔티티는생년월일 애트리뷰트를 가질 수 있다; "증명됐다" 관계는 "날짜" 애트리뷰트를 가질 수 있다. 애트리뷰트는 엔티티 집합이나 관계 집합에 선으로 연결시킨 타원형들로 그린다.

모든 엔티티(위크 엔티티가 아닌 한)는 "고유하게 식별되는" 애트리뷰트 집합을 가지고 있어야 한다. 최소한의 고유 식별 애트리뷰트 집합은 엔티티의 기본 키(Primary Key)라 불린다.

개체-관계 다이어그램은 하나의(single) 엔티티를 보여주고 있거나 하나의(single) 관계 인스턴스를 보여주고 있는 것은 아니다. 사각형은 "엔티티 집합들"을 나타내고 있는 것이고, 다이아몬드형은 "관계 집합들"을 보여주고 있는 것이다. 예를 들면 다음과 같다: 특정한 악곡은 하나의 엔티티이다. 하나의 데이터베이스 안의 모든 악곡들의 모음은 하나의 엔티티 집합이다. 한 아이와 그 아이의 점심 도시락 사이의 "먹어치움" 관계는 하나의(single) 관계이다. 하나의 데이터베이스 안의 모든 그러한 아이-점시 도시락 관계는 관계 집합이다.

실선은 관련된 엔티티 집합과 관계 집합 사이에 그린다. 엔티티 집합의 모든 엔티티가 관계에 참여(participate)하고 있을 때, 선을 굴게(thick) 그리거나 이중선(double) 으로 그린다. 이것을 파티시페이션 콘스트레인트라고 부른다. 엔티티 집합 내의 각각의 엔티티가 관계 집합 내의 최대 한 개의 관계에 참여할 수 있을 때, 엔티티 집합에서 관계 집합 쪽으로 화살표를 하나 그려준다. 이것을 키 콘스트레인트라고 부른다. 엔티티 집합 내의 모든 엔티티가 각각 하나씩의 관계에 정확히 대응될 때는 화살표를 굵게(thick) 그린다.

다대다(many-to-many) 관계를 기술할 때는 어소시에이티브 엔티티를 사용할 수 있다. [1].

단일 테이블의 행 사이의 관계를 기술하기 위해 단방향 관계(Unary Relationships)를 사용할 수도 있다.

[편집]때때로 쓰이는 기호

ER 모델링에서 어떤 기호들은 그렇게 자주 사용되지 않는다. 모델러들은 이러한 기호들을 종종 기피한다.

엔티티는 "스트롱(strong)" 엔티티일 수도 있고 "위크(weak)" 엔티티일 수도 있다.

  • 상기 단락에서 기술한 보통의 엔티티를 가리켜 "스트롱 엔티티"라고 한다. 스트롱 엔티티는 엔티티가 가진 애트리뷰트들만 가지고 고유하게 정의될 수 있다.
  • "위크 엔티티"는 엔티티가 가진 애트리뷰트들만 가지고 고유하게 정의될 수 없는 엔티티를 말한다. 따라서 한 개 이상의 관계를 엔티티의 프라이머리 키로 삼아야 한다. 위크 엔티티는 엔티티를 나타내는 사각형을 그리고, 관계를 나타내는 다이아몬드형을 그린 뒤, 그 둘을 굵은(bold) 선이나 이중(double)선으로 연결하여 표현한다. 예를 들면, 업무 추적(work tracking) 데이터베이스에서는, 한 태스크(task)는 태스크를 할당받은 사람(person)을 이용하여 식별된다. 이때 사람(person)은 엔티티이고, 태스크(task)는 위크 엔티티가 된다.

ER 모델링에서 애트리뷰트들은 다치(multi-valued) 애트리뷰트일 수도, 합성(composite) 애트리뷰트일 수도 혹은 종속(derived) 애트리뷰트일 수 도 있다:

  • "다치 애트리뷰트"(multi-valued attribute)는 이중선(double line)으로 둘러싸인 타원으로표현된다. 적어도 한 개체의 인스턴스에 대해서 한 개 이상의 값을 가질 수 있는 애트리뷰트이다. 예를 들어, 소프트웨어(엔티티는 "애플리켜이션")는 다치값의 "플랫폼" 애트리뷰트를 가질 수 있다. 애플리케이션의 인스턴스는 한 개 이상의 플랫폼 상에서 동작할 수 있기도 하기 때문이다.
  • "합성 애트리뷰트"(composite attribute)는 두 개 이상의 애트리뷰트를 포함할 수 있는 애트리뷰트를 말한다. 자기 자신도 포함할 수도 있다. 예를 들면 주소는 번지, 도시 등등의 애트리뷰트들로 이루어진 합성 애트리뷰트라 할 수 있다.
  • "추출 애트리뷰트"(derived attribute)는 그 값이 데이터베이스의 다른 정보에 의해 결정되는 애트리뷰트를 말한다; 종속 애트리뷰트는 점선으로 그린 타원형으로 표시한다. 예를 들면, 피고용인 데이터베이스가 있다고 가정할 때, "피고용인"의 "나이" 애트리뷰트는, "피고용인"의 "생년월일" 애트리뷰트로부터 추출/유도(derive)해낼 수 있다.

때때로 어떤 두 엔티티가 더 일반적인 분류의 엔티티의 하위 분류일 경우가 있을 수 있다. 예를 들면, 소프트웨어 기업의 피고용인 엔티티는 프로그래머 엔티티일 수 있고 마케터 엔티티일 수 있다. 위와 같은 경우, ISA라는 말을 안에 써 넣은 삼각형으로 표시한다. 수퍼클래스는 위쪽에 그리고 다른 두 개(혹은 그 이상)의 서브클래스들은 밑변쪽(아래쪽)에 그린다.

어떤 한 개의 관계와 그것과 엮인 엔티티 집합들은 다시 단일 엔티티 집합으로 간주될 수 있다. 이것을 어그리게이션이라 하는데, 다른 관계와 엮을려는 목적이다. 어그리게이션은 어그리게이트된 모든 개체와 관계를 둘러싼 점선 사각형으로 표시된다.

[편집]다른 다이어그램 컨벤션

[편집]크로우즈 핏 (까마귀 발)

크로우즈 핏 노테이션을 사용해 나타낸 두엔티티

크로우즈 풋/크로우즈 핏(Crow's Foot) 노테이션에서는, 엔티티 사이의 관계를 기본적으로 엔티티를 연결하는 선으로 나타낸다. 또한 관계의 카디널리티를 나타내는 기호들을 그 선의 양끝에 표시한다.

카디널리티를 나타내는 기호들은 다음과 같은 것들이 있다:

  • "고리"(ring)은 "0"를 나타낸다.
  • "사선"(dash)은 "1"을 나타낸다.
  • "까마귀 발"(crow's foot)은 "다수" 혹은 "그 이상"을 나타낸다.

위와 같은 기호들은 서로 조합하여 사용될 수 있다. 다음과 같은 네 가지 조합이 가능하다.

  • 고리와 사선 → 0 혹은 1
  • 사선과 사선 → 정확히 1
  • 고리와 까마귀 발 → 0개 이상
  • 사선과 까마귀 팔 → 1개 이상

크로우즈 핏(crow's feet) 노테이션의 예제는 오른쪽 그림을 참조하라.

오른쪽 그림에서, 우리는 다음과 같은 사실을 알 수 있다:

  • 음악가(Artist)는 "0개 혹은 그 이상의" 노래(song)를 부른다.
  • 노래 한 곡은 정확히 한 음악가(artist)에 의해 불린다. (주의: 실제 세계를 잘 반영하지 못하는 예제이다. 노래 한 곡을 듀엣으로 부를 수도 있는 것이다.)

크로우즈 핏 노테이션은 오라클 데이터베이스 텍스트에서 널리 쓰이고 있다. 또한 마이크로소프트 비지오파워디자이너다이어 (소프트웨어) 등의 틀에서 쓰이고 있다.

[편집]장점

  • 크로우즈 핏 노테이션을 사용하면 다수(many) 관계를 표현하는 것이 명확해진다.
  • 필수적인 관계가 있다면, 크루오즈 핏 노테이션은 그것을 표현하기 위한 간결한 노테이션이 된다. 이때는 수직선만 표시하면 된다. 또한 옵셔널한 관계가 있다면, 그것을 표현하기 위한 간결한 노테이션이 되는데, 이때에는 고리(open circle)로 표시하면 된다.

[편집]같이 보기

[편집]상용 ER 다이어그램 작성 툴

  • 마이크로디자이너: MicroDesigner, ERD 툴, IE 및 IDEF1X 표기법을 충실히 따르는 모델링 도구 제공, 공학/역공학 기능 및 모델 병합 기능등 다양한 기능을 제공 (주)인브레인 제작.
  • eXERD: ERD 툴, 논리, 물리, 논리와 물리 통합 모델링을 지원. 메뉴 및 도움말이 한글로 제공되며 직관적이고 다양한 편의기능 제공. (주)토마토시스템 사 제작.
  • CA ERwin Data Modeler: ERD 툴, HTML 리포트를 생성하는 기능이 있다.
  • ConceptDraw: ER 다이어그램을 만들기 위한 크로스 플랫폼 소프트웨어이다.
  • DB Visual ARCHITECT: UML 클래스 다이어그램과 ERD를 지원한다.
  • ER/Studio: 강건하고, 사용하기 쉬운 ER 모델링 툴. Embarcadero사 제작.
  • 마이크로소프트 비지오: 엔터프라이즈 아키텍처 버전을 구입해야 여러 데이터베이스 및역 엔지니어링을 지원한다.
  • ModelRight: 물리 모델링 툴.
  • OmniGraffleMac OS용 다이어그램 그리기 소프트웨어
  • Oracle Designer오라클 코포레이션이 제공하는 컴퓨터-보조 소프트웨어 엔지니어링 툴. 정보 시스템 설계 및 생성 툴.
  • PowerDesigner사이베이스에서 나온 모델링 스위트. 개념, 논리, 물리, 리버스 엔지니어링 모델링이 가능한 데이터 아키텍트(Data Architect) 툴 포함. 여러 RDBMS 브랜드를 지원한다.
  • Rational Rose: UML 다이어그램을 작성하기 위한 소프트웨어이다. 오래된 만큼 사용하기도 쉽다.
  • SILVERRUN 모델스피어: 개념, 논리, 물리 데이터 모델링을 지원. 다수의 타겟시스템을 지원하는 인터페이스가 갖춰져 있음.
  • SmartDraw: 포인트 앤드 클릭(point and click) 그리기 기법을 제공. 여러 가지 템플레이트 제공.

[편집]무료 소프트웨어 ER 다이어그램 작성 툴

  • [[DBDesigner* DBDesigner-Fork: DBDesigner의 변종. PostgreSQL과 같은 다른 데이터베이스 시스템도 이용할 수 있게 변형됨.
  • 다이어 (소프트웨어): ERD 외에도 다른 여러 다이그램을 작성할 수 있는 툴.
  • 페렛 (소프트웨어)데비안우분투와 같이 배포되는 ERM 툴.
  • 카이비오: (Kivio) ER 다이어그램도 지원하는 순서도 그리기 툴.
  • MySQL 웍벤치: (MySQL WorkBench) 그래픽하게 스키마와 리버스 엔지니어링 스키마들을 작성할 수 있다. 여러 데이터베이스 엔진을 타겟으로 한다.
  • 오픈 시스템 아키텍트: (Open System Architect) ER 다이어그램 모델러. 가장 최근 버전은 2005년에 나온 것이다.
  • 파워*아키텍트: (POWER*ARCHITECT) 자바 언어로 작성된 ER 다이어그램 모델러. 여러 무료 소프트웨어 및 상용 데이터베이스 엔진을 타겟으로 함.

[편집]주석

피터 첸이 지은 이 논문은 컴퓨터 과학 분야에서 가장 많이 인용되는 논문이다. 1000여 명의 컴퓨터 과학과 교수 설문 결과 "가장 영향력 있는" 논문으로 꼽혔다. 인용 논문의 목록은 DBLPhttp://dblp.uni-trier.de/ [2] 등지에서 볼 수 있다.

[편집]바깥 고리



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





Posted by linuxism
,