리눅스에서 벤치마크를 할때 여러 프로그램으로 가능합니다. 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로 못하는 작업이 가능하므로 잘 쓰면 좋습니다.
Hyper-V는 마이크로소프트에서 타입 1 하이퍼바이저로 만들어 제공하는 가상 머신 관리자입니다. 서버에서도 제공하는 기능으로 일반 사용자들이 쓰는 윈도우 7, 8, 8.1, 10, 11에서도 동작합니다. Hyper-V에 게스트 OS를 설치해서 쓰면 재부팅없이, 멀티부팅 하지 않아도 여러 운영체제를 한 PC에서 설치해서 쓸수 있습니다. 단, VT-x나 AMD-V와 같은 가상화 기술이 CPU에서 제공되어야 합니다. 이 기능은 10년 이내의 최신 CPU라면 대부분 지원하니 큰 제약은 아닙니다.
이 글에서는 Hyper-V 환경에서 OpenBSD를 설치후 웹서버, PHP, MariaDB를 설치해서 쓰는 과정을 해설해보겠습니다.
우선 https://www.openbsd.org/faq/faq4.html#Download 에서 최신 iso 파일을 다운로드받아와야 합니다. 2023년 7월 기준으로 최신 버전이 7.3인데요. 설치를 위해서 install73.iso를 각자가 가진 PC의 아키텍처로 다운로드 받습니다. 유닉스 세계에서는 AMD가 발표한 64비트 CPU 아키텍처를 우선 지원하기 시작해서 인텔 CPU도 64비트이면 AMD64로 받아야 합니다.
Hyper-V로 가상 머신을 생성합니다. 램은 호스트 OS 상황 봐가면서 적당히 설정하되 4096MB 정도면 좋은 것 같습니다. 참고로 가상 머신 생성할때 1세대로 할거냐 2세대로 할거냐 물어볼때 1세대로 생성하는게 부팅시 진행이 안되게 하는 현상을 방지할 수 있네요.네트워크 스위치는 기본으로 Hyper-V에 딸려온 것을 설정하구요. VHD도 잘 생성해둡니다. 가상 머신 생성시 위에 다운로드 받은 iso를 IDE 장치로 연결해줍니다.
생성이 되면 켜서 부팅시키고 OpenBSD를 설치합니다. 인스톨러가 지시하는대로 하면 되구요. 특기할 것은 파티션 나누기인데요. 기본으로 되어 있는 설정을 지우고 하시길 권합니다. 업체에서 서비스할 용도가 아니면 파티션 전체를 MBR로 두고 파티션 수동 모드로 가서 기존 파티션 다 지운후 VHD 최대 용량에서 스왑 파티션은 8GB 정도, 나머지는 다 마운트 포인트를 / 로 할당하면 됩니다. 다 되면 끄고, iso 마운트 해제가 안되어 있으면 해제하고 재부팅합니다.
지금까지의 과정을 간략하게 요약하면 아래와 같습니다.
(1) Hyper-V 설치 (2) 가상 머신 생성 (3) OpenBSD iso를 가상 머신에 탑재 (4) 설치 (5) 재부팅
이 흐름입니다.
위 흐름대로 설치후 재부팅해서 해야 할 게 있는데요. APM 설치와는 상관없는 과정이지만, 디렉토리 변경 등의 정보를 업데이트해서 보려면 좋은 OpenBSD 설정부터 설명합니다. 이 설정을 해두어야 경로를 바꿔서 어떤 디렉토리에 있는지 한눈에 살펴볼 수 있고 시스템 로케일도 설정할 수 있게 됩니다.
$ su $ pkg_add install tcsh $ rehash $ cd ~ $ chsh /bin/zsh 부분을 /usr/local/bin/tcsh 로 바꾸고 저장후 나옴 (커서를 /bin/zsh 부분에 두고 a나 i를 눌러 편집 가능. 고치고나서 :wq 입력하면 저장후 나옴) $ vi .cshrc set prompt = “내용” 이라고 된 부분을 아래처럼 고침 set prompt = “%n@%m::%~]# “ set prompt 부분이 다른 라인에도 있으면 고침 setenv LANG ko_KR.UTF-8 setenv LC_CTYPE en_US.UTF-8 고치고나서 :wq 입력후 빠져나옴 $ exit 재로그인 위에서 설명한 과정을 root 계정에도 해둠
이정도 설정해두면 APM 설치를 본격적으로 합니다.
패키지 설치 $ su $ pkg_add install git # 선택사항 $ cd /usr $ git clone https://github.com/OpenBSD/ports # 선택사항. 포트로 php와 mariadb를 설치하고 싶을때 $ pkg_add php $ pkg_add mariadb-server
OpenBSD에는 기본 웹서버가 설치되어 제공됩니다. httpd라고 되어 있는데요. apache와 흡사하지만 조금 다른 웹서버로, 설정도 간편하고 좋습니다. 특히 SSL 설정을 할때, 도메인만 잘 입혀주면 인증도 되게 기정의 설정이 된게 좋습니다. 그런데 DDNS 서비스가 마땅치 않다면 HTTP로도 연결되게 설정할 수도 있는데요. 이 글에서는 HTTPS가 아닌 HTTP로 httpd를 설정하는 과정을 예시하겠습니다.
php 설정 $ pkg_add php82-fpm 그외 모듈이 설치안되어 있으면 개별 모듈도 설치
MariaDB 설정 $ su $ rcctl enable mysqld $ rcctl start mysqld $ rcctl check mysqld $ mysql_install_db $ mysql_secure_installation $ vi /etc/my.cnf [client-server] socket=/var/run/mysql/mysql.sock port=3306 $ mysql -u root -p MariaDB [(none)]> CREATE DATABASE sampledb; MariaDB [(none)]> CREATE USER ‘user2’@’localhost’ IDENTIFIED BY ‘PASSWORD’; MariaDB [(none)]> use sampledb; MariaDB [(none)]> GRANT ALL PRIVILEGES ON sampledb.* TO ‘user2’@’localhost’; MariaDB [(none)]> FLUSH PRIVILEGES; MariaDB [(none)]> show databases; MariaDB [(none)]> EXIT
$ cd /var/www/htdocs $ vi test.php <?php $conn = new mysqli(“localhost”, “user2”, “PASSWORD”);
if ($conn->connect_error) { die(“연결실패: ” . $conn->connect_error); }
echo “연결 성공”; ?>
웹브라우저에서 https://서버주소/test.php
연결 성공이라고 나오면 됨.
워프 설치 $ su $ cd /var/www/htdocs $ wget https://wordpress.org/latest.zip $ pkg_add unzip $ unzip latest.zip $ mv wordpress wp $ cd wp $ mv wp-config-sample.php wp-config.php $ vi wp-config.php 위에 MariaDB에서 생성한 db name, db user, db password 를 각각의 define() 구문에 입력 db host 정보는 localhost에서 127.0.0.1 로 바꿔야 할 수도 있음
위 단계 실행후 웹브라우저에서 https://사이트IP/wp 를 로드하여 설치과정 마무리 https://사이트IP/wp/wp-login.php 로 가서 로그인하고 관리자 페이지로 진입하면 일단 성공 다른 잔손질 (사이트 설정이나 프로필 설정 등) 을 해둔다. (그런데 보안 문제로 잠시 플러그인이나 테마 메뉴에서 설치하고 싶은 플러그인, 테마를 열람하려고 Add New (또는 새로 추가) 메뉴로 들어가면 connection 문제를 보고하는 오류가 뜨고 워프 사이트에 게시된 테마, 플러그인 정보가 안뜨는데 이 경우 아래처럼 조치한다)
워프 관리자로 돌아와 플러그인이나 테마 메뉴로 와서 Add New (또는 새로 설치) 메뉴로 들어오면 워프 사이트에서 보낸 목록이 표시됩니다. 그리고 위에 chmod 명령어로 wp-content 이하 디렉토리들을 전부 권한조정해서 설치도 됩니다.
트러블슈팅 대개 윗단계를 잘 거쳐와서 처리하면 httpd, PHP, MariaDB가 잘 돌고 워프 설치도 잘 됩니다. 그런데 OpenBSD는 chroot로 /var/www를 격리하는 체제로 보안을 높히는 것이 기본값이라 그냥 워프 설치해서 쓰면 플러그인이나 테마를 워프 사이트에서 받아와서 목록으로 표시하는 것이 오류가 납니다. 이 경우와 같이 별다른 오류 메시지 없이 작동이 잘못되면 오리무중이 되는데요. 아래 문서를 참고해서 wp-config.php에 define() 구문으로 디버그 모드를 지정하면 오류가 자세하게 나서 좋습니다.
오류를 가지고 문의할때도 좋구요. 오류가 나는 참조된 파일들이 표시가 됩니다. 이 경우 워프 인클루드 파일들인데 해당 파일 내용을 참조하지 않고 이름만 봐도 대략 어떤 문제점이 오류를 나게 하는지, 파일이름을 보고 유추해볼 수도 있습니다. ftpext관련 문자열이 들어간 파일이름이 뜨면 wp-config.php에 define( ‘FS_METHOD’ , ‘direct’); 와 같은 구문을 추가해서 처리할때의 문제임을 테스트해볼 수 있습니다. 이는 개발시 필요한 정보라 배포된 직후 상태에서는 꺼져 있는 기능인데 define() 관련 구문을 잘 조정하면 오류 표시 단계를 정할 수 있다는게 위에 문서 중반부터 후반까지의 소개입니다.
어떤 경우 위의 해결에도 불구하고 또다른 secure connection 문제가 오류로 뜨면, 워프 사이트와 HTTPS 통신이 안되는 것을 의심해볼만한데요. 이 경우 SSL 통신에 필요한 파일을 유추해서, 또다른 기여 조건인 chroot로 /var/www를 격리할때, /etc/ 에 있는 네트워크 관련 설정파일이 안읽힌다고 판단이 되게 할 수 있습니다. 그러면 대략 /etc/hosts, /etc/localtime, /etc/resolv.conf를 /var/www/etc 로 복사해보면 될까? 와 같은 판단이 되어 문제 해결에 진전이 있게 되죠. /etc/hosts 파일은 IP 바인딩용이고, /etc/localtime은 SSL 만료인지 아닌지 식별용이고, /etc/resolv.conf는 외부 도메인을 해석하게 하는 네임서버 정보가 들어간 파일입니다. 이 판단이 적절한 선행 학습이 되면 자연스럽게 유추가 되는데요. 이 판단의 물꼬를 트려면 위 링크에 나온 DEBUG 관련 설정을 define() 구문에 해두고 오류가 뜬 페이지를 다시 로드하면 업데이트가 된 상태가 됩니다. 새로운 오류가 뜨면 고치고, 오류가 고쳐지면 성공이죠.
(1) 테마와 플러그인 설치 메뉴에서 문제가 있으면 FS_METHOD를 direct로 바꾼다 (2) chmod -R 777 wp-content (3) /etc/hosts, /etc/localtime, /etc/resolv.conf 를 /var/www/etc에 복사 (4) php82_fpm, httpd 재시작
어느 정도 흐름은 보였는데 조금 설명이 불친절하지만 이해가 되실 것입니다. 아이디어 제시용이고, 위에 정리한 명령어 이외의 조치가 필요할 수도 있습니다.
이 글의 의의는 테스트 목적으로 가상 머신에 OpenBSD를 설치하고 워프를 돌게 하는 과정을 설명해보았습니다. 생각정리전에 해본대로 쓰느라 아주 가독성이 크지는 않으니 양해 부탁드립니다.
이 중에서 제일 긱키한 방법은 물론 (3)인데 소스코드가 공개될 것 같아 안쓰구요. (2)는 NTFS로 보통 포맷해서 쓰지만 macOS에서는 비용지불해야 NTFS에 쓰기가 가능한지라 읽기에도 문제가 있을 것 같아 exFAT으로 포맷한 후에 쓰는데 복사 속도가 빠를 것 같습니다. (1)은 USB 메모리들이 대부분 exFAT으로 포맷되어 나와서 조치하지 않아도 복사가 되구요.
아무래도 (2)로 해야겠습니다. 앱 소스코드가 파일 크기들이 아주 크진 않은데 즉시 복사하고 즉시 옮겨야 하니까요.
(4) 네트워크 연결후 복사하기
도 있겠는데 macOS에서 윈도우로 네트워크 연결하는 기술을 살펴봐야 하네요. samba나 기타 다른 기술들이 있겠으나 FTP가 제일 쓰기가 편하긴 합니다. 윈도우에 FTP 서버 설치하고 macOS에서 연결후 다운로드하는 방법을 쓰면 되는데 이역시도 속도가 빠르겠으나 FTP 서버를 켜두는게 불편하군요. (2)가 최적 같습니다. 속도도 그렇고 별다른 추가 처리도 필요 없습니다.
일단 이 네가지에 대응되는 방법을 찾아 사용하면 됩니다. 방법마다 필요한 소프트웨어가 있어야 할 수도 있으니 잘 살펴보세요. 윈도우에서 FTP 서버를 운용하려면 FileZilla 서버를 쓰면 편리합니다.