리눅스에서 벤치마크를 할때 여러 프로그램으로 가능합니다. Phoronix Test Suite도 그중의 하나인데요. 이 프로그램을 쓰면 제공되는 여러 테스트들을 활용해서 Processor, System, Network, Disk, OS 등의 카테고리의 벤치마크를 할 수 있습니다.
These are the defaultconfiguration options forwhen running the Phoronix Test Suite inabatch mode(i.e.running phoronix-test-suite batch-benchmark universe).Running inabatch mode isdesigned tobe asautonomous aspossible,except forwhere you'dlike any end-user interaction.
Save test results when inbatch mode(Y/n):Y
Open the web browser automatically when inbatch mode(y/N):N
Auto upload the results toOpenBenchmarking.org(Y/n):n
(1) 개념의 발생적인 측면. 이 개념이 왜 고안되었는지. (2) 개념의 실용적인 측면. 이 개념을 접했을 때 즉각적으로 떠올려봐야 되는 것이 무엇인지.
이 두가지를 기본적인 것부터 고급적인 것까지 항상 주시하면서 보강해가면 좋습니다. 기본적으로 (1)과 (2)를 핵심적으로 알아두고 지식 확장을 이루어나가면 숙지가 될 것입니다.
디렉토리의 경우 어떠할까요? 발생적인 것과 실용적인 것의 측면에서 생각해봅시다.
디렉토리는 발생적으로 파일의 저장을 체계적으로 하기 위해 고안된 개념입니다. 사무실에서 쓰이는 캐비넷 안에 들어있는 디렉토리를 생각하시면 됩니다. 사무실에는 캐비넷이 여러개가 있을 수 있고 각각의 캐비넷은 용도별로 구분이 됩니다. 그리고 각각의 캐비넷에 들어있는 디렉토리도 용도별로 구분되죠. 사용자는 파일을 체계적으로 저장하기 위해 임의로 캐비넷과 디렉토리를 분류해두고 그 기준에 맞춰 파일을 보관합니다.
아래 그림처럼 서로 독립된 캐비넷이 여러개로 분리되서 구조를 이루고 거기에 파일이 보관됩니다.
컴퓨터에서도 마찬가지인 디렉토리 개념이 존재합니다. 파일의 체계적 분류를 위해 디렉토리를 만들고 파일 저장 위치를 디렉토리로 구분해서 계층화해둡니다. 예컨데 사진 파일을 유저 홈디렉토리의 사진 디렉토리에 저장하기로 약속해놓았다든가, 서드파티 프로그램들을 C 드라이브 아래의 Program Files 디렉토리에 저장하도록 했다든가 하는 것이 그러한 예입니다.
여기서 캐비넷에 해당되는 것은 C 드라이브고, 디렉토리에 해당되는 것은 Program Files겠죠.
실용적으로 중요한 것은 어떤 경로로 구성된 디렉토리인지 실용적으로 떠올려보는 것입니다.
예컨데 첫번째 캐비넷 안에 “가” 디렉토리 아래 “김철수”라는 디렉토리가 있고 그 안에 “출생증명서” 파일이 있다면 경로가 생성됩니다. 그 경로는 유일하고 각각의 단계에 의해 구성됩니다. 이는 마치 사다리타기할 때처럼 시작지점부터 도착지점까지 경로가 유일하게 정해져 있는 것과 같습니다.
누군가 “니 홈디렉토리 아래 사진 디렉토리에 노리사마 사진을 저장해두었으니 볼려면 찾아봐”라고 말했다면, 즉각적으로 해야 될 것은 말로 된 디렉토리의 경로가 어떤 것인지 떠올려보는 것이죠.
보통 윈도우 운영체제에서는 위에 말한 디렉토리가 C:\Users\계정명\Pictures 가 됩니다. C:\ 라는 것은 부팅된 윈도우가 설치된 하드디스크를 의미하고, 이는 루트디렉토리라고 불립니다. 그 아래 Users나 계정명, Pictures는 하위 디렉토리라고 부릅니다. 루트디렉토리는 여러개가 있을 수 있고, 같은 층위의 하위 디렉토리는 같은 계층에 하나만 존재합니다.
이를 일반화하면
드라이브명:\하위 디렉토리1\하위 디렉토리2…\하위 디렉토리n
이렇게 구성됩니다. 드라이브명은 루트디렉토리라고 부르고, 하위 디렉토리1은 하위 디렉토리 2의 상위 디렉토리라고 부릅니다. 대개 이 구조는 유일합니다.
세밀하게 들어가보자면 이렇습니다.
드라이브명:\하위 디렉토리1\하위 디렉토리2…\하위 디렉토리n
이 구조가 중요한데 이런 구조를 디렉토리를 접하면 즉각적으로 떠올려보면 좋습니다.
확장 개념으로 조금 더 나아가봅시다. 앞서 말한 바에 의하면 디렉토리 경로는 유일하다고 했습니다. 이 유일한 경로를 안다면 해당 경로에 저장된 파일을 처리할 준비가 됩니다. 그런데 필요에 의해 확장된 예외에 의하면 최종 작업디렉토리는 유일해도 경로의 단계는 복수일 수도 있습니다. 유닉스에서 심볼릭링크라고 부르는 개념이나 윈도우에서 바로가기라고 부르는 개념이 그 예외인데, 예컨데
C:\Users\name\Pictures 라는 작업 디렉토리에 연결된 바로가기가 서로 다른 경로에 존재하는 경우 서로 다른 경로를 지니게 되는 결과가 생기죠.
즉 C:\Users\name\Pictures 디렉토리에 연결된 동일한 바로가기 아이콘인 shortcut1.ico 파일이 서로 다른 디렉토리에 저장되어 있는 경우 그 저장된 경로 개수만큼 경로가 있다고 볼 수 있습니다.
처럼 하나여도 그에 도달하는 경로는 다수일 수 있다는 것입니다. 이는 디렉토리 개념이 고안된 이후에 사용의 편리성을 위해 고안된 예외적인 확장 개념으로 이해하면 됩니다. 최종적인 작업 디렉토리는 하나지만, 사용의 편의를 위해 고안된 확장 개념으로 이해해두면 됩니다.
정리해보자면
(1) 디렉토리는 파일의 체계적 저장을 위해 만들어졌다. 사무실의 캐비넷을 떠올려보라. (2) 디렉토리의 핵심 개념은 어떤 경로냐는 것이다. (3) 최종 작업 디렉토리는 유일하지만 그 경로는 확장적으로 다수일 수 있다.
이정도만 알아두면 입론이 됩니다.
디렉토리는 보통 명령어 체제로 운용되는 운영체제에서 유래한 개념인데 윈도우처럼 그래픽컬한 인터페이스로 운용되는 운영체제에서는 폴더라고 부르기도 하므로 참고하세요. 폴더는 디렉토리를 시각적으로 폴더 모양으로 나타내는데서 비롯된 이름입니다. 둘다 용어상의 차이일뿐 개념은 같습니다.
이해가 잘되게 설명했는지 모르겠는데 일단 입론으로 참고는 되실겁니다.
정리: 디렉토리를 토대로 경로가 제시되면 떠올려볼 사항들 (1) 어느 운영체제의 경로 표시인가? (2) 경로에 표시된 디렉토리에 어떻게 찾아갈 것인가? (3) 디렉토리에 찾아가서 어떤 작업을 할 것인가?
(1) 어느 운영체제의 경로 표시인가? 운영체제에서 경로란 여러 의미를 갖지만, 디렉토리와 연관되면 디렉토리와 파일이 저장된 위치를 가리킵니다. 윈도우에서 C:\Users\name\Pictures\flower.jpg 라는 경로가 주어졌다면 이 경로는 윈도우 운영체제에서 유효하며 각각의 단계를 찾아가서 처리하라는 의미입니다.
윈도우 운영체제에서는 전통적으로 디스크를 파티션으로 나누어 각각의 파티션에 A부터 Z까지의 문자를 부여해서 디스크 드라이브라고 불렀습니다.
위에서 예를 들은 C:\Users\name\Pictures\flower.jpg 에서 제일 앞의 C:\ 가 드라이브를 나타낸 기호로, C 드라이브라고 부르며 보통 윈도우가 부팅된 디스크에 부여됩니다.
각각의 디렉토리 구조는 \ 로 잘라내져서 계층을 표현하구요. 위에서는 사용자 계정을 의미하는 Users 디렉토리 아래 계정명 name으로 된 홈디렉토리 아래 Pictures 디렉토리를 찾아서 flower.jpg 파일에 처리를 하라는 의미가 됩니다.
리눅스에서는 반대로 / 로 구분하여 디렉토리 계층을 표현하구요. 윈도우와 달리 드라이브 문자가 없이, 장치 파일을 임의의 디렉토리에 마운트해서 씁니다.
/dev/sda1 /mnt/windows/C
이런 식으로 표현합니다.
정리하자면 운영체제마다 경로 표시 규칙이 다르고, 대개 윈도우 계열에서는 드라이브 이름이 부여되어 하위 디렉토리를 \로 구분해서 나타내며, 유닉스 계열에서는 드라이브 문자 없이 /로 구분해서 나타낸다는게 핵심입니다.
(2) 경로에 표시된 디렉토리에 어떻게 찾아갈 것인가? 경로가 제시되면 우선 생각할게 (1)이구요. (1)이 해독되면 (2) 경로에 표시된 디렉토리에 어떻게 찾아갈지 결정해야 합니다.
위의 예를 들면 윈도우에서 파일 탐색기를 실행해서 클릭하면서 찾아가도 되구요. cmd.exe 를 실행해서 cd 명령어로 찾아가도 됩니다.
(3) 디렉토리에 찾아가서 어떤 작업을 할 것인가? (1)과 (2)가 해결되면 결정해야 할 것은 어떤 작업을 할 것인가입니다. 이는 디렉토리 용도와 파일의 형식에 의해 결정되고 목적에 따라 달라집니다.
누군가 이메일로 자기가 기르는 꽃 사진을 보내오고 위와 같은 파일을 첨부해서 보여줬다면 우선 다운로드를 합니다. 이 경우에 경로를 C:\Users\name\Pictures로 다운로드 받게 설정하구요. 다운로드가 되면 파일 탐색기를 열어 해당 경로로 가서 flower.jpg 파일을 더블클릭하면 뷰어가 실행될 것입니다. 이메일로 보내는 이유가 이미지 파일을 그냥 봐달라는 것이면 이렇게 하면 되구요. 리터칭을 해달라고 한 것이면 파일 탐색기 외에 포토샵에서 불러와서 처리하면 됩니다.
때로는 파일을 지울때도 해당 디렉토리 경로를 알아야하구요.
이미지 파일의 경우 리터칭을 해서 리터칭 완료한 이미지 파일을 답신해야 한다면, 저장된 경로를 잘 숙지하고 있다가 이메일에 첨부하면 됩니다.
정리하자면 디렉토리는 파일 저장과 이용을 체계적으로 나타내기 위해 제정된 규칙이고, 디렉토리와 파일을 어떻게 처리해야 할지 기준을 제공하는 규칙이라는 것을 잘 알아두면 됩니다.
webmin은 웹기반 리눅스 서버 설정 관리자로 매우 편리한 설정이 가능하게 해줍니다. 물론 설정 사항들에 대한 지식이나 설정값을 선택하고 입력하는 지식은 이미 있어야 하지만요. 서버 설정 경험이 일정 정도 있고 서버에 대한 경험이 있는 사용자에게 직접 명령어 타이핑을 고안할 필요없이 매우 광범위한 설정을 UI로 돕는 기능을 제공하고 있습니다.
데비안, 우분투 계열 리눅스와 레드햇 기반 리눅스를 모두 지원합니다. 슬랙웨어 기반은 어떤지 미확인입니다.
제가 사용하는 리눅스는 리눅스 민트 계열의 하모니카OS인데요. 우분투 기반인만큼 apt 명령어로 간단하게 설치가 되어 사용이 가능해집니다.
유닉스 운영체제에서는 원격에서 목적지 컴퓨터로 연결해서 작업을 하는 것이 필요했습니다. 주말에 집에서 직장 컴퓨터에 작업을 해야 할 필요가 있다든지 대학에서 사무실에 앉아 각 교실에 있는 컴퓨터에 연결해서 관리를 해야 한다면 원격 연결을 할 방법이 필요한 것이었죠.
이를 위해 원격에서 연결해서 쉘 작업을 할 수 있게 하는 기술이 지원되었는데요. rlogin 같은 명령어가 있습니다. 그런데 이 방법은 운영체제나 네트워크 보안이 그다지 발달이 안된 시절의 유산이라, 보안에 취약한 측면이 있었습니다. 보통 TCP 연결이 성립하면 서버와 클라이언트 간의 데이터 통신이 선로를 따라 전송이 되는데요. 주고 받는 데이터가 평문으로 전달되다보니 이를 중간에 가로채면 별다른 노력 없이도 어떤 정보를 주고 받는지 알게 되어 보안에 무리가 갔습니다.
1990년대 중반에 이를 해결하고자 한 개발자가 SSH를 개발합니다. Secure SHell (보안이 강화된 쉘) 이라고 불리우는 프로그램입니다. 이 프로그램은 인증할때, 정보를 주고받을때 암호화 기술을 써서 정보를 암호화해서 처리하게 되어 있었습니다. 암호화 처리는 내부적으로 되어 사용자에게는 암호화된 정보를 복호화해서 보여주었구요. 암호화 처리로 인해 특별히 유난한 조건이 아니면 정보를 중간에서 탈취해도 어느 정도는 안전성이 보장되는 구조였습니다.
암호화 기능은 대칭, 비대칭으로 나누어지는데요. 대칭키 알고리즘은 서버와 클라이언트간에 같은 비밀키를 가지고 암호화와 복호화를 진행합니다. 암호화는 암호화가 안된 평문을 알아보기 어렵게 바꾸는 기능이고 복호화는 암호화된 정보를 암호화 이전의 평문으로 되돌리는 기술입니다. 공개키와 개인키를 생성해서 변환 과정(해시 함수 처리)을 거쳐 인증을 하는데, 이 경우 공개키는 서버와 클라이언트가 공유하고, 개인키는 안전한 장소에 두고 쓰는 방법입니다. 대칭키 알고리즘은 SSH 작동 전반에 걸쳐 활용되고 비대칭 알고리즘은 인증에 쓰인다고 하는데, 비대칭 알고리즘이 조금 더 안전을 강화했기에 쓰입니다. 예를 들면 해시 처리된 결과물이 늘 같은 문자열로 이루어져 있다면 이를 토대로 본래 문자열을 유추하는게 가능해지는데, 비대칭키 알고리즘을 쓰면 보다 더 유추가 힘들어지는 원리입니다.
SSH는 여러 암호화 기술을 쓸 수 있는데요. AES, Blowfish, 3DES, CAST128, Arcfour 등입니다. 관리자가 SSH 설정 파일에 지정한대로 골라져서 작동합니다. 각각의 암호화 기술은 깨트려지기 어려운 것을 주로 써야 하는데요. 보통 키의 길이가 긴 것 (비트수로 표현) 을 쓰면 깨트리기가 어려워지므로 최근의 암호화 기술은 비트수가 큽니다.
비대칭키 알고리즘은 공개키에서 개인키를 도출해낼 수 없는 구조입니다. 개인키는 완전한 비밀로 해야 하고 서버/클라이언트 양자에서 공유하지 않습니다. SSH는 비대칭키와 대칭키 알고리즘을 둘다 씁니다.
개인키의 보안이 철저하다면 SSH 설정에 의해 비밀번호 없이 키 설정만으로도 로그인이 가능하도록 할 수 있습니다. 이는 비밀번호가 유출되었을때의 보안 침해를 막으려는 용도와, 사용자에게 비밀번호 변경의 번거로움을 해소하는 방도입니다. 대체로 웹호스팅 업체는 키 인증 방식과 비밀번호 체제를 둘다 씁니다.
일단 인증이 끝나면 원격지의 PC에서 목적지의 컴퓨터로 로그인 과정을 거치고 물리적으로 해당 컴퓨터 앞에 앉아 작업하듯이 작업이 가능해집니다. SSH로 연결하면 웹호스팅에서 편의로 제공하는 cPanel에서 안되는 작업도 가능해집니다.
연결을 시도하면 클라이언트와 서버 사이에 TCP 핸드세이크가 이루어집니다. 이 과정에서 보안이 강화된 연결을 위해 교섭이 이루어지고 사용자의 자격증명과 서버의 설정이 작동해서 인증을 하죠. TCP 연결이 이루어지면 프로토콜을 확인하고 공개키와 비밀키를 교환합니다. Diffie-Hellman 알고리즘으로 알려진 과정에 의해 세션 단위로 공개키, 개인키 쌍을 사용해서 암호화를 수행합니다.
비밀번호 또한 암호화됩니다.
위에 정리한 과정은 구현 레벨에서는 스무단계가 넘는 과정을 거치는데, 단순화하면 아래와 같습니다.
클라이언트가 SSH 서버에 연결을 요청한다
서버는 클라이언트에 공개키를 보낸다
서버의 공개키가 클라이언트의 호스트 파일에 저장된다
클라이언트와 서버는 연결 파라메터를 주고받으며 보안된 연결을 수립한다
SSH는 1995년 소개 된 이래, OpenBSD 팀에서 만든 OpenSSH로 대체되어 윈도우 포함 여러 운영체제에서 제공합니다. OpenBSD는 높은 보안성을 제공하려고 방침을 정한 유닉스 프로젝트로, OpenSSH도 같은 모토에 의해 제작되어 타운영체제에서도 쓰고 있습니다.
사용자의 PC 즉 클라이언트 PC에서 PuTTY 같은 프로그램을 써서 서버에 SSH 연결을 하는 것이고 OpenSSH는 이러한 일련의 작업을 할 수 있게 명령어와 라이브러리를 제공하는 것입니다. OpenSSH를 써서 SSH나 SFTP 등의 연결을 할 수 있게 환경을 만들 수 있습니다.
서버의 설정에 따라 아래와 같은 작업을 수행합니다.
프로그램 컴파일
각종 서버 데몬 처리
디렉토리 권한 조정
cPanel이나 phpmyadmin 등의 설정처리
public_html 디렉토리 아래 서브디렉토리를 만들어 앱 설치
그외
SSH는 CLI 방식의 명령어를 알아야 하기에 초심자에게는 부담이 되지만, 웹호스팅 업체에서 기본으로 제공하는 설정 UI로 못하는 작업이 가능하므로 잘 쓰면 좋습니다.
