Hydejack offers a few additional features to markup your content. Don’t worry, these are merely CSS classes added with kramdown’s {:...} syntax, so that your content remains compatible with other Jekyll themes.
Writing
Hydejack offers a few additional features to markup your content. Don’t worry, these are merely CSS classes added with kramdown’s {:...} syntax, so that your content remains compatible with other Jekyll themes.
Unified Filesystem
인간이 시스템의 데이터를 구성하는데 사용하는 디렉토리 및 파일의 계층 구조
리눅스 시스템은 unified filesystem을 가지고 있다.
모든 디스크 또는 네트워크 공유에 있는 파일은 "/"(root)로 시작하는 이름으로 액세스 가능하다
unified filesystem은 하나 이상의 개별 파일 시스템으로 구성된다.
각 개별 파일 시스템에는 고유한 root가 있다
그 root는 unified filesystem의 모든 디렉토리에 접목 될 수 있음
개별 파일 시스템이 unified filesystem에 접목된 디렉토리는 개별 파일 시스템의
mount point 이다
개별 파일 시스템은 물리적 장치(ex 디스크 드라이브)에 있어야하며
동일한 컴퓨터에 있을 필요는 없다
MS Windows style File System
-각 장치에 파일 시스템이 있다
-많은 나무와 많은 root
Linux Unified File System
-단일 트리 및 단일 루트
/ /home /usr/X11R6 /boot /mnt/cdrom /mnd/dvd /mnt/zip
7개의 개별 파일 시스템이 마운트 되어 있다.
Filesystem types
커널이 디스크와 같은 물리적인 매체에 데이터 블록을 저장하는데 사용하는 포맷팅 시스템
디스크 naming
/dev/sda
/dev/sdb
/lib/udev/rules.d
File Types
파일에 직접 데이터가 포함되어 있다.
디렉토리는 파일 계층 구조를 제공한다. 파일과 다른 디렉토리를 모두 포함한다.
파일과 디렉토리는 모두 파일 타입이다.
장치 특수 파일을 포함하여 다른 파일 타입이 존재한다.
ex)장치 파일은 주어진 물리적 장치에 대한 액세스를 커널에 요청하는 방법을 제공
장치 파일에 포함 된 것으로 보이는 데이터는 실제로 장치 자체의 바이트 또는 섹터 순 시퀸스이다.
장치 파일은 일반적으로 /dev 디렉토리 아래에 저장된다.
How to store data into your machine?
컴퓨터가 하드드라이브에 데이터를 저장할때, 데이터는 각 플래터에 매우 규칙적인 패턴으로 저장된다.
데이터 비트는 트랙이라고하는 동심 원형 경로로 정렬된다. 각 트랙은 섹터라는 더 작은 영역으로 나뉜다.
하드디스크 컨트롤러가 이러한 섹터 매핑 테이블을 관리한다.
OS에서는 이 매핑테이블을 관리하여 사용자에게 file view를 제공한다.
Hard disk drive interfaces
기말고사
Disks and Partitions
디스크는 주로 파티션으로 나눠진다.
파티션 정보는 파티션 테이블에 저장됩니다.
윈도우와의 호환성을 위해 최대 4개의 기본 파티션을 만들 수 있다.
주 파티션(Primary partition) - 하나의 파일 시스템
주 파티션의 번호는 1~4
프라이머리 파티션에서 부팅, 하드디스크 하나를 주로 4개까지 나눌 수 있다. 그 프라이머리 파티션들은 부팅을 할 수 있는 섹션
프라이머리 파티션을 extended partition 으로 나눠서 사용하는 구조
extended partition은 더 작은 logical partitions 으로 분할 될 수 있고, 그것들은 5부터 번호가 매겨진다.
/dev/hda 는 파티션이 아닌 전체 하드 디스크를 의미한다.
/dev/hda1 은 첫번째 IDE 디스크의 첫번째 파티션이다.
Example of "sda"
by-uuid로 ls 했을 경우 두개 밖에 안나오는 이유는 사용자가 sda2는 접근하지 않기 때문에
os만 sda2가 있다는걸 인지하고 있음
fdisk 명령어
m 명령어 리스트 가져옴
p print the partition table
q 변화없이 quit
w 변화를 write quit(포맷보다 더 심한 상황발생함)
SOW = statement of work (작업명세서)
RFP = Request For Proposal(주문한 사람이만드는것 제안요청서)
COCOMO = Constructive Cost Model
WBS = Work Breakdown Structure
CPM = Critical Path Method
R & R = Role and Responsibility
PM = 프로젝트 매니저
PL = 프로젝트 리더
CEO = chief executive officer
CTO = chief technical officer (기술경영자)
MISRA = Motor Industry Software reliability Association
SRS = Software Requirement specification
Stakeholders = 이해관계자
CMM = Capability Maturity Model
3. Project Management & Planning
3.1 프로젝트 범위
소프트웨어공학과 프로그래밍의 차이는 관리된 프로젝트다.
어려운일은 일의 규모와 필요한 노력을 예측하는 일이다.
중요한 요소는 계획세우기, 인력관리, 위험관리이다.
3.2 노력 추정
COCOMO Cost Modeling
프로젝트 경험에 기초한 경험적 모델
특정 소프트웨어 공급 업체와 관련이없는, 잘 문서화되고 독립적인 모델
COCOMO2 : 소프트웨어 개발, 재사용 등에 대한 다양한 접근 방식
차이점은
COCOMO1는 LOC를 고려
COCOMO2는 1단계 프로토타입을 만들어 화면수나 출력수 개수를세고
2단계에서 규모측정을위하여 FP를 계산, 3단계에서 COCOMO1모델처럼 LOC에 의하여 소요되는 노력 추정
MM = 비용 / 생산성
FP = Function Point(기능 점수)
기능의 수는 소프트웨어의 크기와 복잡성에 영향을 미친다.
FP = GFP X PCA (GFP=Gross function point, PCA=Processing complexity adjustment)총기능점수,보정계수
E = FP / SW Productivity (점수 / 생산성)
3.3 일정 계획
간트차느는 CPM 네트워크로부터 만들수있다. 칸트 차트는 자원의 활용을 계획활 때 도움을 주며
CMP 네트워크는 작업이 적시에 진행되는지 점검 하는데 사용된다.
slack time(최대한으로 연장되었을 때의 예비시간)
3.4 조직 계획
책임 프로그래머 팀 구성
관리자의 명령을 따라 일하고 결과를 보고하는 방식(모든 의사 결정이 한사람에의해 이루어짐)소규모에 적합
Egoless Team
개인적 요소가 최소화되어 품질이 향상 될 수 있는 방법(모두 공동의 일) 대규모의 문제에는 부적합
Hierarchical Team (계층적팀구성) 프로젝트 리더를 둠 ,중간계층과
DevOps : Development + Operation (개발 + 운영) - 기술과 시장의 빠른 변화에 대응하기 위한 최신 개발/운영 트렌드
마이크로 서비스 아키텍처 기반 클라우드의 SaaS
그 예로 구글 Docs, Gmail
기능조직 CEO에 의한방법과 CEO아래에(기술경영자) CTO 를 둬서 개발관리를 따로 맡게함
Risk Monitoring
제품,프로세스 및 비즈니스 위험에 대한 가정이 변경되지 않았는지 확인하는 프로세스
4. Requirement Analysis
4.1 Requirement
시스템이 무엇을 제공해야하는지 how가아니라 what
프로젝트 실패의 주요 원인중 하나는 부적당한 요구사항이다.
요구사항의 바람직한 속성
Unambiguous
Correct
Complete
Consistent
Feasible
Traceable
요구 사항 엔지니어링 프로세스가 필요하다.
RE (Requirement engineering) : 요구 사항 파악, 분석, 문서화 및 검증과 관련된 활동
요구사항의 유형에는 User requirements 와 System requirements가 있다
시스템 요구사항은 기능적요구와 비기능적 요구를 가진다.
기능적요구 : 소프트웨어시스템안의 서비스, 입출력
비기능적요구 : Quality requirements, System constraints(규제 관점), External constraints(표준)
Non-functional Reqs: Quality
Speed, Size, Ease of use, Reliability, Robustness, Portability(입출력이아니라 제약사항)
4.2 Requirement Elicitation(요구 추출)
고객, 도메인전문가, 이해관계자, 사용자, 역공학
추출 기술
고객 프레젠테이션 (workshop 매우 효과적임)
문헌 조사
설문
브레인 스토밍 : 공동 작업 기술 중 하나 , 비판이나 토론 허용X
프로토타이핑 : 시스템 외부에서 관찰 가능한 모든 행동을 보여줌
4.3 Domain Analysis
배경정보에 대해 알아 가는 것
도메인 정의, 도메인 개념, 도메인 사전 작성
4.4 Use Case
요구 사항에 필요한 지식을 수집한후에 구조화,명확하게 모델링
Actor - 누가 시스템을 사용하기 원하는지
Use-case - 유저가 시스템을 사용하는 용도
System scope 로 이루어짐
4.5 SRS
Software Requirement Specification
시스템 개발자에게 요구되는 사항에 대한 공식 명세서
모든 이해관계자에게 승인을 받아야함.
특정이해관계자가 불이익을 당할수 있기에 모두의 동의를 받아야함
개념적 UI모델과 데이터 모델에 매핑
SRS 기본 요소
소개
사용자 요구사항
시스템 요구사항
인수 조건(Acceptance testing)
4.X Requirement Validation
요구사항 검토
연습 , 조사 , 공식적리뷰
프로토타이핑
시스템의 실행 가능 모델을 사용하여 요구 사항 확인
Test-case generation
테스트 가능성을 확인하기 위한 요구 사항 테스트 개발
BDD(behavior driven development)
공유 데이터에 대한 동시 접근은 데이터의 비일관성을 낳을 수 있다. 논리 주소 공간을 공유하는 협력적 프로세세의 질서 있는 실행을 보장하여, 이를 통해 데이터의 일관성을 유지하는 다양한 메커니즘을 논의한다.
6.1 배경
프로세스가 병행 또는 병렬로 실행될 때 여러 프로세스가 공유하는 데이터 무결성에 어떤 문제를 일으키는지 동시에 여러 개의 프로세스가 동일한 자료를 접근하여 조작하고, 그 실행 결과가 접근이 발생한 특정 순서에 의존하는 상황을 경쟁 상황(racd condition)이라고 한다. 이러한 상황에서 데이터를 보호하기 위해 프로세스들이 동기화 되도록 해야함
6.2 임계구역 문제(The Critical_Section Problem)
각 프로세스는 임계구역을 가지고 있다. 한 프로세스가 자신의 임계구역에서 수행하는 동안에는 다른 프로세스들은 그들의 임계구역에 들어갈 수 없다. 임게구역 문제는 프로세들이 협력할 때 사용할 수 있는 프로토콜 설계이다. 프로세스는 자신의 임계구역으로 진입하려면 진입허가를 요청해야한다. 이러한 요청을 구현하는 코드 부분을 진입구역(entry section)이라고 하고 임계구역에 뒤에는 퇴출 구역(exit section)이 따라올 수 있다. 코드의 나머지 부분은 나머지 구역(remainder section)이라 한다. 임계구역 문제에 대한 해결안은 다음의 세가지 요구조건을 충족해야한다. 1. 상호 배체(mutual exclusion) 프로세스 Pi가 자기의 임계구역에서 실행된다면 다른 프로세스들은 그들 자신의 임계구역에서 실행될 수 없다. 2. 진행(proress) 자기의 임계구역에서 실행되는 프로세스가 없고 그리고 그들 자신의 임계구역으로 진입하려고 하는 프로세스들이 있다면, 나머지 구역에서 실행 중이지 않은 프로세스들만 다음에 누가 그 임계구역으로 진입할 수 있는 지를 결정하는데 참여할 수 있으며, 이 선택은 무한정 연기가 될 수없다. 3. 한정된 대기(bounded waiting) 프로세스가 자기의 임계구역에 진입하려는 요청을 한 후부터 그 요청이 허용될 때까지 다른 프로세스들이 그 요청이 허용될 때까지 다른 프로세스들이 그들 자신의 임계구역에 진입하도록 허용되는 횟수에 한계가 있어야 한다. OS 내에서 임계구역을 다루기 위해 선점형 커널과 비선점형 커널의 두가지 일반적인 접근법이 사용된다 선점형 커널 : 프로세스가 커널모드에서 수행되는 동안 선점되는 것을 허용한다. 비선점형 커널 : 커널 모드에서 수행되는 프로세스의 선점을 허용하지 않고 커널 모드 프로세스는 커널을 빠져 나갈 때까지 또는 봉쇄될 때까지의 또는 자발적으로 CPU의 제어를 양보할 때까지 계속 수행
6.3 피터슨의 해결안
Peterson's solution 상호 배제, 진행, 한정된 대기의 요구조건을 모두 보장한다
6.4 동기화 하드웨어
피터슨해결안으로 두개가 넘는 프로세스에서는 해결이 불가함 락킹에 대한 가정, 즉 임계구역을 보호하기 위해서 락을 사용하는 것에 기반을 둔다. 임계구역 문제는 단일 처리기 환경에서는 공유 변수가 변경되는 동안 인터럽트 발생을 허용하지 않음으로써 간단히 해결 할 수 있다. (비선점형 커널 방법) 다중처리기 환경에서는 적용이 불가능함(인터럽트의 메시지 전달 시간이 너무큼) 한 워드(word)의 내용을 검사하고 변경하거나, 두 워드의 내용을 원자적으로 교환 할 수 있는, 즉 인터럽트 되지 않는 하나의 단위로서, 특별한 하드웨어 명령들을 사용하여 극복 test_and_set() 과 compare_and_swap() 명령어가 있다.
실행 된 이후 FALSE로 값 초기화, 즉 다시 락을 해제 compare_and_swap() 명령어 정의
int compare_and_swap(int *value, int expected, int new_value) {
int temp = *value;
if (*value == expected)
*value = new_value;
return temp;
}
위 두 알고리즘은 상호 배제 조건은 만족하지만 한정된 대기 조건은 만족시키지 못한다. 한정된 대기 조건을 만족시키는 상호 배제 코드는 waiting[n] 과 lock을 사용한다
6.5 Mutex Locks
임계구역 문제를 해결하기 위한 소프트웨어 도구 중 하나가 mutex 락이다. mutual exclusion 의 약어로, 임계구역을 보호하고 경쟁조건을 방지하기 위해 mutex락을 사용한다. 프로세스는 임계구역에 들어가기 전에 반드시 락을 획득해야 하고 임계구역을 빠져 나올 때 락을 반환해야한다. acquire() 함수가 락을 획득하고, release() 함수가 락을 반환한다. mutex락은 available 이라는 불린 변수를 통해 락의 가용 여부 표시
acquire(){
while(!available)
; /* busy wait */
available = false;
}
----------------------
release(){
available = true;
}
대부분 리눅스 명령어는 관련된 메뉴얼 페이지를 가지고있다. 주로 manpage로 알려짐
man 커맨드를 활용하여 볼 수 있다.
Format of a Manual page
NAME : name and single-line reason for the command
SYNOPSIS: possible arguments
DESCRIPTION : fuller explanation of the command
OPTIONS
FILES : any files the command needs
ENVIRONMENT : pertinent environment variables
BUGS, AUTHORS, SEE ALSO
로 이루어져 있다.
Section of Manual
맨 페이지는 메뉴얼 섹션에 있으며 사용자 명령은 섹션 1에 있다.
다른 섹션에는 같은 이름의 페이지가 포함될수 있다.
ex)
섹션 1의 passwd 페이지는 /usr/bin/passwd 커맨드이다
passwd(1) : brought by "man 1 passwd"
섹션 5의 passwd 페이지는 /etc/passwd 파일이다.
Manual Section Numbering
섹션 설명
1 일반 명령
2 시스템 콜
3 라이브러리 기능
4 특수 파일
5 파일 형식 및 규칙
6 게임 및 화면 보호기
7 기타
8 시스템 관리 명령 및 데몬
man 명령어의 옵션
-t 옵션은 메뉴얼 페이지의 포스트스크립트 버전을 만든다
-K (대문자 K) 전체 메뉴얼의 내용을 통해 서치, 오래걸리고 너무 많은 결과가 나오기에 유용하지 않음
ex)
man passwd 명령은 첫 번째 섹션의
man -a passwd : 섹션상관없이 passwd 가지는 모든 메뉴얼페이지를 보여줌
man -f passwd : passwd 이름의 섹션을 모두 보여주고 간단한 한 줄 설명
(whatis 명령과 같다)
man –k passwd : passw 키워드를 포함하는 모든 섹션 이름과 페이지를 찾음
(apropos 명령과 같다)
올바른 매뉴얼 페이지 찾기
때로는 명령의 설명서가 예상 한 곳에 있지 않고
관련 명령을 한 페이지에 그룹화 할 수 있다.
예를들어 gzip, gunzip, zcat은 하나의 매뉴얼 페이지에 있다.
쉘안에서 구현된 명령어
쉘의 맨페이지에 문서화되어있는 쉘기반 명령어
help 명령어를 통해서 쉘안에 함수의 설명을 볼 수 있다.
메뉴얼 페이지의 위치
맨 페이지는 파일 시스템에 저장되어있음
man -aw 로 지정된 이름의 모든 맨 페이지 위치 표시
맨 페이지의 일반적인 위치는 /usr/man 이나 /usr/share/man
Info pages
GNU의 문서화 시스템
매뉴얼페이지
/usr/share/doc의 문서
가끔 주요 프로그램의 문서를 man or info page로 사용할 수 없다
일반적으로 plain text
가끔 HTML
/usr/share/doc 안에 있는 문서는 대부분 패키지의 사용자 관리가 아닌
패키지의 시스템 관리에만 관련된 정보이다.
-설치, 설치방법, 라이센스, 변경 로그
때로는 다른 곳보다 사용자 친화적 인 문서
- HTML 도움말은 대화 형 응용 프로그램에서보다 일반적이며 전통적인 유닉스 명령에서는 매우 드뭅니다.
- 다른 플랫폼에서 이식 된 프로그램은 종종
설명서 페이지가 아닌 "/ usr / share / doc"에있는 설명서
Package Managemnet
패키지 매니지 시스템 - 프로세스들을 자동화 시키는 도구들의 집합
패키지 설치, 업그레이드 , 구성 ,제거
패키지는 파일 아카이브와 다름
파일 아카이버
- 여러 파일을 하나의 아카이브 파일로 결합하여보다 쉽게 운송하거나 보관할 수있는 컴퓨터 프로그램
메타 데이터
- 다른 데이터에 관한 데이터 (또는 정보)
타르 (Tarball) 및 지퍼
유닉스 계열 플랫폼에서 소스 및 바이너리 배포에 일반적으로 사용된다.
Dependency Problems
실행 프로그램은 소스 코드와 라이브러리에서 파생된다.
make 프로세스에는 해당 파일 간의 모든 종속성에 대한 설명이 필요
깨지거나, 결함, 호환되지 않는 종속석으로 인해 프로그래밍 실수나 버그 발생
의존성 지옥
많은 의존성, 긴 의존성 체인, 충돌하는 종속성, 순환 의존성
버전 번호
종속성 문제를 부분적으로 해결, 명명 규칙이 일정하지 않음
요즘엔 아파치에서도 리파지토리에서 관리를 해주고 정형화 되어있음
dpkg
데비안 기반 시스템용 패키지 매니저
dpkg –l : List all packages installed on the system
dpkg –L package_name : List the files installed by a package
dpkg –S file_path : Search a package which contains the given file
dpkg –i package_deb_name.deb : Install a local package deb file
dpkg –r package_name : Remove a package
apt-get
우분투의 고급 패키징 도구 (APT) = Advanced Packaging Tool
서버 관리자용 명령 줄 도구
apt-get upgrade
설치된 패키지 업그레이드
최신버전의 파일을 가져옴
apt-get update
/etc/apt/source.list 파일에 정의된 저장소에서 APT패키지 색인을 갱신
버전을 저장소에 물어봄 최신 버전 인덱스를 보내줌 (리스트 인덱스를 체크함)
모든 활동은 /var/log/dpkg.log 에 기록된다.
Repository
APT는 APT 시스템 저장소를 사용
저장소란
-파일 모음과 색인
-배포를 통한 집중식 저장소
-저장소가 다르게 구조화 될 수 있음
-신원 인증하기 위해 GPG 키로 암호로 서명(GPG:GNU 프라이버시 가드)
Ubuntu Repository
/etc/apt/sources.list 우분투의 APT 시스템 저장소 구성
유형
Main 표준지원 무료 및 오픈소스 소프트웨어
Restricted 장치용 독점 드라이버
Universe 커뮤니티가 오픈 소스 소프트웨어를 무료로 유지 관리
Multiverse 저작권 또는법적 문제로 제한되는 소프트웨어
Logging
1.로그파일의 이해
시스템에 이상이 있거나 보안의 위험을 감지하기 위해서는 시스템에서 남겨지는 메시지를 확인해야한다.
모든 시스템에서 특정작업이 발생한 후에는 반드시 로그가 남겨지며 관리자는 이를 반드시 정기적으로 점검해야한다.
서버 보안문제 혹은 시스템 해킹시 이에 대한 1차적인 확인을 로그파일을 통해서 할 수 있습니다.
2. 로그종류
- 커널로그(klogd 데몬에 의해 생성됨)
- syslogd 데몬에 의해 생성되는 로그
3. 로그파일의 위치 및 특성
리눅스에서 시스템의 모든 로그는 /var/log 디렉토리에 의해 기록 및 관리되고 있고
/etc/syslog.conf 파일에서 시스템 로그파일들의 위치를 지정하고 있다.
리눅스시스템에서 발생하는 많은 이벤트는 관리목적으로 기록되어야한다.
리눅스에는 syslog 라는 기능이 있어 모든 서비스나 시스템의 일부가 이러한 이벤트를 기록 할 수 있다.
(우분투의 rsyslog)
이벤트는 심각도(레벨) 또는 이벤트(facility)를 만난 서비스에 따라 선택될 수 있다.
메시지는 파일, 시스템 콘솔 또는 다른 시스템에서 실행되는 중앙 syslog서버로 이동할 수 있다.
rsyslog의 구성은 /etc/rsyslog.conf 및 /etc/rsyslog.d 에 있다
facility는 메시지 생성자이다. 즉 로그 생성 서비스
ex) One of auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, or local0 through local7
level은 메시지가의 우선순위 (로그 수준)
ex) debug, info, notice, warning, err, crit, alert, emerg
destination 은 로그생성서비스와 로그수준에 의해 선택된 메시지가 보내 질 곳을 나타낸다.
ex) 일반적으로 로그 파일 또는 장치 이름
Reconfiguration of rsyslog
rsyslog의 구성을 변경하는 경우에 rsyslog에 구성을 다시 읽도록 요청해야 함
rsyslog 프로세스에 SIGHUP(hang up) 신흐를 보내서 수행
kill -HUP /usr/bin/rsyslogd
다른 방법 : rsyslog의 init 스크립트 사용
service rsyslog start
서비스를 끊어도 데몬이라 재시작하게됨
로그 검사
때로는 주목할만한 활동을 위해 수동으로 로그 파일을 검사해야 할 때가 있습니다
로그는 일반 텍스트이므로 표준 텍스트 처리 도구를 사용하여 검사 할 수 있습니다
로그 파일 위치 /var/log
로그 순환
logrotate
리눅스내에서 시스템에 있는 모든 로그파일들을 관리할 수 있으며, 이들 로그파일들을
날짜를 지정하여 주기적으로 압축, 백업, 삭제, 메일로 보내는 등의 작업을 할 수 있도록 하여주는 기능
로그 파일들의 2 3 4 번째들 것들은 컴프레싱 되어있음
rsyslog 는 일반적으로 로그 파일이 제한없이 디스크 공간이 부족할때까지 증가하도록 허용합니다.
그 해결책으로 log rotation 사용
기존 로그 파일의 이름이 주기적으로 바뀌고 궁극적으로 삭제되는 방식
log-> 1.log -> 2.log -> 3.log
log -> 1,log -> 2.log
logrotate 는 crom 에 의해 매일 런 됨
logrotate 는 /etc/logrotate.conf (설정파일) 에서 구성 된다
