Linux Server Basics: SSH, LAMP, and Apache Web Hosting
Server Hardware and Its Characteristics (서버 하드웨어와 특징)
서버(Server)는 일반 개인용 컴퓨터(Personal Computer)보다 훨씬 높은 성능과 안정성을 요구하는 컴퓨터 시스템이다. 개인용 컴퓨터는 주로 한 명의 사용자가 개인적인 작업을 하기 위해 사용하는 반면, 서버는 여러 사용자가 동시에 접속하여 서비스를 이용할 수 있도록 항상 동작해야 한다.
서버와 개인용 컴퓨터의 가장 큰 차이점 중 하나는 운영 시간(Uptime)이다. 과거에는 전기를 아끼기 위해 컴퓨터를 사용하지 않을 때 꺼두는 것이 일반적이었다. 하지만 서버는 웹사이트, 금융 서비스, 행정 시스템, 데이터베이스(Database) 등 다양한 서비스를 계속 제공해야 하기 때문에 하루 24시간, 일주일 내내 켜져 있어야 한다. 따라서 서버 하드웨어(Server Hardware)는 장시간 안정적으로 작동할 수 있도록 설계되어야 한다.
또한 서버는 높은 수준의 보안(Security)을 유지해야 한다. 개인용 컴퓨터는 주로 개인이 사용하는 장치이기 때문에 문제가 생기더라도 영향 범위가 비교적 작다. 하지만 서버는 다수의 사용자가 접근하는 시스템이므로 보안 문제가 발생하면 그 피해가 훨씬 커질 수 있다. 예를 들어 금융권 서버(Financial Server)가 마비되거나 행정기관 서버(Government Server)가 중단된다면 많은 사람들이 서비스를 이용하지 못하게 되고, 복구에도 오랜 시간이 걸릴 수 있다. 이러한 이유로 서버는 외부 공격, 무단 접근, 데이터 유출 등을 막기 위한 보안 체계가 중요하다.
서버는 동시에 많은 사용자의 접속을 처리할 수 있어야 한다. 개인용 컴퓨터는 보통 한 명 또는 소수의 사용자가 사용하는 것을 기준으로 만들어졌기 때문에 대량의 접속 요청을 처리하기 어렵다. 많은 사용자가 동시에 접속하면 CPU, 메모리(Memory), 저장장치(Storage), 네트워크 대역폭(Network Bandwidth) 등 여러 자원이 빠르게 부족해질 수 있다. 따라서 서버는 높은 하드웨어 성능(Hardware Performance)과 안정적인 네트워크 처리 능력(Network Performance)을 갖추어야 한다.
결국 서버 하드웨어(Server Hardware)는 높은 성능, 긴 운영 시간, 강력한 보안, 많은 사용자 접속 처리 능력을 모두 감당할 수 있어야 한다. 개인용 컴퓨터와 비교했을 때 서버는 단순히 성능이 좋은 컴퓨터가 아니라, 여러 사용자를 위한 서비스를 안정적으로 제공하기 위해 설계된 시스템이라고 볼 수 있다.
Uptime(운영 시간)은 서버가 중단되지 않고 계속 동작하는 시간을 의미한다. 서버에서는 이 Uptime이 매우 중요하며, 서비스가 멈추는 시간을 Downtime(중단 시간)이라고 한다.
Network Bandwidth(네트워크 대역폭)는 일정 시간 동안 네트워크를 통해 전송할 수 있는 데이터의 양을 의미한다. 많은 사용자가 동시에 서버에 접속하면 네트워크 대역폭이 부족해질 수 있다.
Server Software and Daemon-Based Operation (서버 소프트웨어와 데몬 기반 동작)
서버(Server)는 단순히 성능이 높은 하드웨어(Hardware)만을 의미하지 않는다. 서버 하드웨어 위에는 반드시 운영체제(Operating System)와 서버 역할을 수행하는 소프트웨어(Software)가 설치되어야 한다. 그래서 “서버를 설치한다”라고 하면 처음에는 서버 전용 하드웨어가 따로 있어야 한다고 생각할 수 있지만, 실제로는 개인용 컴퓨터(Personal Computer)나 가상 머신(Virtual Machine) 위에도 서버 소프트웨어를 설치하여 서버처럼 동작하게 만들 수 있다.
예를 들어 우분투 리눅스(Ubuntu Linux)를 설치할 때 데스크톱 버전(Desktop Version)이 아니라 서버 버전(Server Version)을 설치했다면, 물리적으로는 개인용 컴퓨터 위에서 실행되고 있더라도 기능적으로는 서버 역할을 수행할 수 있다. 즉 서버와 클라이언트(Client)의 구분은 단순히 하드웨어 종류로만 결정되는 것이 아니라, 실제로 어떤 기능을 수행하는지에 따라 달라진다. 클라이언트의 요청(Request)을 받아 처리하고 응답(Response)을 제공한다면 그 시스템은 서버로 볼 수 있다.
서버 소프트웨어(Server Software)는 하드웨어 위에 설치되어 클라이언트의 요청을 처리하는 역할을 한다. 이 소프트웨어는 개인용 컴퓨터에 설치하든, 서버급 하드웨어(Server-Class Hardware)에 설치하든 기본적인 동작 원리는 같다. 다만 실제 서비스 환경에서는 많은 요청을 안정적으로 처리해야 하기 때문에 더 높은 성능과 안정성이 요구된다.
서버 소프트웨어의 중요한 특징 중 하나는 데몬(Daemon) 형태로 동작한다는 점이다. 리눅스(Linux)에서 프로그램 이름 뒤에 &를 붙이면 해당 프로그램을 백그라운드(Background)에서 실행할 수 있다. 백그라운드 실행은 사용자가 직접 화면에서 계속 조작하지 않아도 프로그램이 뒤에서 동작하는 방식이다. 서버 프로그램도 이와 비슷하게 사용자의 직접적인 개입 없이 계속 실행된다.
하지만 데몬(Daemon)은 단순히 백그라운드에서 실행되는 프로그램보다 더 서버 관리에 적합한 형태라고 볼 수 있다. 데몬은 시스템이 시작될 때 자동으로 실행될 수 있고, 사용자가 직접 명령을 입력하지 않아도 지속적으로 동작한다. 또한 서버 운영을 위해 필요한 관리 기능이나 보호 기능도 함께 포함될 수 있다. 따라서 데몬은 백그라운드에서 지속적으로 실행되며, 사용자와 직접 상호작용하지 않고 필요한 서비스를 제공하는 프로그램이라고 정리할 수 있다.
Linux Server Version and Desktop Version (리눅스 서버 버전과 데스크톱 버전)
리눅스 서버 버전(Linux Server Version)과 데스크톱 버전(Desktop Version)의 가장 큰 차이는 사용 목적과 사용자 상호작용(User Interaction)에 있다. 데스크톱 운영체제(Desktop Operating System)는 개인 사용자가 키보드(Keyboard), 마우스(Mouse), 화면(Display)을 통해 직접 조작하는 환경을 기준으로 만들어진다. 따라서 사용자가 입력했을 때 빠르게 반응하는 응답성(Responsiveness)이 중요하다. 우리가 스마트폰(Smartphone)이나 개인용 컴퓨터를 사용할 때 버튼을 누르면 즉시 반응하기를 기대하는 것과 같다.
반면 서버 운영체제(Server Operating System)는 사용자가 직접 화면을 보며 계속 조작하는 환경을 전제로 하지 않는다. 서버는 대부분 혼자 백그라운드에서 동작하면서 클라이언트의 요청을 처리한다. 따라서 키보드나 마우스 입력에 즉각 반응하는 것보다, 네트워크 요청(Network Request), 프로세스 처리(Process Handling), 파일 관리(File Management), 보안(Security), 안정성(Stability) 같은 기능적인 부분이 더 중요하다.
이 때문에 우분투 서버(Ubuntu Server)를 설치하면 일반적인 그래픽 화면(Graphical User Interface, GUI)이 아니라 검은 터미널 화면(Command Line Interface, CLI)이 나타난다. 이는 오류가 아니라 서버용 운영체제가 사용자 편의성을 위한 그래픽 환경보다 기능성과 자원 효율(Resource Efficiency)을 더 중요하게 설계되었기 때문이다. GUI가 없으면 그래픽 화면을 유지하는 데 필요한 CPU, 메모리(Memory), 저장 공간(Storage)을 줄일 수 있고, 그 자원을 서버 기능에 더 집중할 수 있다.
결국 데스크톱 운영체제는 사용자가 직접 조작하기 편한 환경에 초점을 맞추고, 서버 운영체제는 서비스를 안정적으로 제공하는 기능에 초점을 맞춘다. 이 차이는 운영체제 내부의 스케줄러(Scheduler) 관점에서도 이해할 수 있다. 데스크톱 환경에서는 사용자의 입력에 빠르게 반응하는 작업의 우선순위가 중요하지만, 서버 환경에서는 여러 클라이언트 요청을 효율적이고 안정적으로 처리하는 것이 더 중요하다.
Daemon(데몬)은 리눅스나 유닉스(Unix) 계열 시스템에서 백그라운드로 계속 실행되며 특정 서비스를 제공하는 프로그램을 의미한다. 예를 들어 웹 서버(Web Server), 데이터베이스 서버(Database Server), SSH 서버(SSH Server) 등이 데몬 형태로 동작할 수 있다.
CLI(Command Line Interface)는 명령어를 입력해서 컴퓨터를 조작하는 방식이고, GUI(Graphical User Interface)는 아이콘, 창, 버튼처럼 시각적인 요소를 이용해 조작하는 방식이다. 서버에서는 보통 CLI를 많이 사용하는데, 이는 자원을 적게 사용하고 원격 관리(Remote Administration)에 적합하기 때문이다.
서버(Server)와 클라이언트(Client)의 구분은 물리적인 기계의 종류보다 역할(Role)에 따라 결정된다. 같은 컴퓨터라도 다른 컴퓨터의 요청을 처리하면 서버가 될 수 있고, 다른 서버에 요청을 보내 서비스를 이용하면 클라이언트가 될 수 있다.
백그라운드 실행(Background Execution)과 데몬(Daemon)은 비슷하지만 완전히 같은 개념은 아니다. 백그라운드 실행은 단순히 프로그램을 뒤에서 실행하는 방식이고, 데몬은 시스템 서비스(System Service)로서 자동 실행, 지속 실행, 관리 기능 등을 포함하는 경우가 많다.
X11 and the X Window System (X11과 X 윈도우 시스템)
리눅스 서버(Linux Server)를 설치하면 일반적인 윈도우 창(Window)이 뜨지 않고, 검은색 터미널 화면(Command Line Interface, CLI)만 보이는 경우가 많다. 반면 리눅스 데스크톱 버전(Linux Desktop Version)이나 안드로이드(Android)처럼 리눅스 커널(Linux Kernel)을 기반으로 하는 시스템에서는 화면에 창이 뜨고, 사용자는 마우스(Mouse), 키보드(Keyboard), 화면(Screen)을 통해 그래픽 환경(Graphical User Interface, GUI)을 사용할 수 있다. 그렇다면 리눅스 기반 시스템에서 이런 그래픽 화면은 어떻게 동작하는지 이해할 필요가 있다.
과거 유닉스(Unix) 계열 시스템에서는 그래픽 화면을 처리하기 위해 X Window System, 즉 X11(X Window System)이라는 구조를 사용했다. X11의 중요한 특징은 화면 출력도 클라이언트-서버 구조(Client-Server Architecture)로 동작한다는 점이다. 일반적으로 우리가 생각하는 서버(Server)와 클라이언트(Client)의 관계는 사용자의 컴퓨터가 클라이언트이고, 멀리 있는 데이터센터(Data Center)의 컴퓨터가 서버인 경우가 많다. 사용자가 웹사이트에 접속하거나 정보를 요청하면, 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 제공하는 구조이다.
하지만 X11(X Window System)에서는 이 개념이 조금 반대로 보일 수 있다. 사용자의 앞에 있는 컴퓨터, 즉 키보드(Keyboard), 마우스(Mouse), 화면(Screen)을 가진 워크스테이션(Workstation)이 X Server(X 서버)가 된다. 그리고 실제로 실행되는 원격 프로그램(Remote Program)이 X Client(X 클라이언트)가 된다. 처음 들으면 헷갈릴 수 있지만, 여기서 서버와 클라이언트는 물리적인 위치가 아니라 기능적인 역할(Role)에 따라 구분된다.
X Server and X Client (X 서버와 X 클라이언트)
X Server(X 서버)는 사용자의 화면(Screen), 키보드(Keyboard), 마우스(Mouse) 같은 입출력 장치(Input/Output Devices)를 관리한다. 사용자가 실제로 보는 화면을 그려주고, 사용자의 입력을 받아 처리하는 역할을 한다. 따라서 X11 구조에서는 사용자 앞에 있는 컴퓨터가 X 서버가 된다.
반대로 X Client(X 클라이언트)는 화면에 표시될 프로그램이다. 예를 들어 원격 컴퓨터(Remote Machine)에서 실행 중인 프로그램이 “이 창을 화면에 띄워 주세요”라고 요청하면, 그 요청을 X Server(X 서버)가 받아 사용자의 화면에 창을 표시한다. 즉 X 클라이언트는 실제 응용 프로그램(Application Program)이고, X 서버는 그 응용 프로그램의 화면 출력을 담당하는 시스템이라고 볼 수 있다.
첨부된 그림에서도 위쪽의 User’s Workstation(사용자 워크스테이션)에 Keyboard(키보드), Mouse(마우스), Screen(화면)이 있고, 그 안에 X Server(X 서버)가 위치해 있다. 그리고 X Client(X 클라이언트)는 같은 컴퓨터 안에 있을 수도 있고, 네트워크(Network)를 통해 연결된 Remote Machine(원격 컴퓨터)에 있을 수도 있다. 원격 컴퓨터에서 실행되는 X Client(X 클라이언트)는 네트워크를 통해 X Server(X 서버)에 화면 출력을 요청하고, 사용자는 자신의 화면에서 그 결과를 볼 수 있다.
Why the Server Is on the User Side (왜 사용자의 컴퓨터가 서버인가)
일반적인 웹 서비스(Web Service)에서는 사용자의 컴퓨터가 클라이언트(Client)이고, 서비스를 제공하는 컴퓨터가 서버(Server)이다. 하지만 X11(X Window System)에서는 사용자의 화면을 제공하는 쪽이 X Server(X 서버)이기 때문에 사용자의 컴퓨터가 서버가 된다.
서버(Server)는 어떤 서비스를 제공하는 쪽이다. X11에서 제공되는 서비스는 화면 출력(Display Output), 키보드 입력(Keyboard Input), 마우스 입력(Mouse Input) 관리이다. 따라서 사용자의 컴퓨터가 이 서비스를 제공하므로 X Server(X 서버)라고 부른다. 반면 원격에서 실행되는 프로그램은 화면을 직접 가지고 있지 않고, X Server에게 “내 화면을 표시해 달라”고 요청하므로 X Client(X 클라이언트)가 된다.
이 부분은 서버와 클라이언트의 개념을 기능적 관점(Functional Perspective)에서 이해하는 좋은 예시이다. 서버와 클라이언트는 반드시 “멀리 있는 고성능 컴퓨터 = 서버”, “내 앞의 컴퓨터 = 클라이언트”로 정해지는 것이 아니다. 어떤 기능을 제공하느냐, 어떤 쪽이 요청을 보내느냐에 따라 역할이 달라질 수 있다.
X11 and Remote Display (X11과 원격 화면 출력)
X11(X Window System)의 중요한 특징 중 하나는 원격 화면 출력(Remote Display)이 가능하다는 점이다. 원격 컴퓨터(Remote Machine)에서 프로그램이 실행되더라도, 그 프로그램의 창(Window)을 사용자의 화면에 띄울 수 있다. 이때 원격 프로그램은 X Client(X 클라이언트)로 동작하고, 사용자의 컴퓨터는 X Server(X 서버)로 동작한다.
예를 들어 서버에 직접 모니터가 연결되어 있지 않더라도, 원격에서 실행한 프로그램의 그래픽 화면을 사용자의 컴퓨터로 전달할 수 있다. 사용자는 자신의 키보드와 마우스로 프로그램을 조작하고, 그 결과를 자신의 화면에서 확인할 수 있다. 이 개념은 나중에 배우게 될 SSH(Secure Shell)와도 연결된다. SSH는 기본적으로 텍스트 기반 원격 접속(Remote Text Login)을 제공하지만, 설정에 따라 X11 Forwarding(X11 포워딩)을 사용하면 원격 프로그램의 그래픽 화면을 로컬 화면에 띄우는 것도 가능하다.
Linux Server and GUI (리눅스 서버와 GUI)
리눅스 서버 버전(Linux Server Version)은 기본적으로 GUI(Graphical User Interface)를 포함하지 않는 경우가 많다. 서버는 사용자가 직접 화면을 보며 마우스로 조작하는 것보다, 네트워크 요청(Network Request)을 처리하고 서비스를 안정적으로 실행하는 것이 더 중요하기 때문이다. 그래서 리눅스 서버를 설치하면 검은 터미널 화면만 보이고, 창이나 아이콘 같은 그래픽 환경이 나타나지 않는다.
하지만 GUI가 없다고 해서 서버에서 그래픽 프로그램을 전혀 사용할 수 없는 것은 아니다. X11(X Window System) 같은 구조를 이용하면, 실제 프로그램은 서버나 원격 컴퓨터에서 실행되고 화면은 사용자의 컴퓨터에 표시할 수 있다. 즉 리눅스 서버는 기본적으로 텍스트 기반으로 관리되지만, 필요하다면 원격 화면 출력(Remote Display) 방식으로 그래픽 정보를 확인할 수도 있다.
다만 이번 단계에서는 X11의 세부 동작 원리를 모두 깊게 이해할 필요는 없다. 중요한 것은 리눅스나 유닉스 계열 시스템에서 그래픽 화면도 클라이언트-서버 구조(Client-Server Architecture)로 동작할 수 있으며, X11에서는 사용자의 화면을 관리하는 쪽이 X Server(X 서버)이고, 화면에 표시될 프로그램이 X Client(X 클라이언트)라는 점이다.
X11(X Window System)은 유닉스(Unix)와 리눅스(Linux) 계열 시스템에서 오래 사용된 그래픽 시스템이다. 현대 리눅스 데스크톱에서는 Wayland(웨이랜드)라는 새로운 디스플레이 서버 프로토콜(Display Server Protocol)도 많이 사용되지만, X11 개념은 리눅스 그래픽 환경을 이해하는 데 여전히 중요하다.
X Server(X 서버)는 화면, 키보드, 마우스를 관리하는 쪽이고, X Client(X 클라이언트)는 화면에 표시될 응용 프로그램(Application Program)이다. 이 때문에 X11에서는 사용자의 앞에 있는 컴퓨터가 서버가 될 수 있다.
SSH(Secure Shell)는 원격 서버에 접속할 때 사용하는 대표적인 텍스트 기반 원격 접속 도구이다. 일반적으로는 터미널 명령어(Command)를 입력해 서버를 관리하지만, X11 Forwarding(X11 포워딩)을 사용하면 원격 서버에서 실행한 GUI 프로그램을 내 컴퓨터 화면에 띄울 수도 있다.
이번 내용에서 가장 헷갈리기 쉬운 부분은 “왜 내 앞의 컴퓨터가 서버인가?”이다. 서버(Server)는 물리적으로 멀리 있는 컴퓨터라는 뜻이 아니라, 어떤 기능을 제공하는 프로그램 또는 시스템이라는 뜻이다. X11에서는 내 컴퓨터가 화면 출력 서비스를 제공하므로 X Server(X 서버)가 된다.
SSH for Server Configuration and Remote Access (서버 설정과 원격 접속 SSH)
서버(Server)를 관리할 때 가장 중요한 기능 중 하나는 원격 접속(Remote Access)이다. 서버는 항상 사용자의 눈앞에 있는 컴퓨터가 아닐 수 있고, 데이터센터(Data Center), 다른 사무실, 또는 물리적으로 멀리 떨어진 장소에 있을 수 있다. 이런 서버를 직접 모니터(Monitor), 키보드(Keyboard), 마우스(Mouse)에 연결해서 조작하는 것은 매우 불편하기 때문에, 네트워크(Network)를 통해 원격으로 접속하는 방법이 필요하다.
과거에는 원격 접속을 위해 텔넷(Telnet)이라는 프로그램이 많이 사용되었다. 텔넷(Telnet)은 멀리 있는 컴퓨터에 접속해서 마치 그 컴퓨터 앞에서 명령어를 입력하는 것처럼 사용할 수 있게 해주는 원격 접속 프로그램(Remote Login Program)이었다. 예전에는 서버와 단말기(Terminal)를 물리적인 전선으로 연결해서 입력과 출력을 주고받는 방식이었기 때문에, 서버에서 멀리 떨어진 장소에서는 사용하기 어려웠다. 하지만 텔넷을 사용하면 집이나 다른 층의 사무실에서도 네트워크를 통해 서버에 접속할 수 있었다.
그러나 텔넷(Telnet)에는 큰 보안 문제(Security Problem)가 있었다. 사용자가 입력하는 아이디, 비밀번호, 명령어 같은 정보가 암호화(Encryption)되지 않은 상태로 전송되었기 때문이다. 즉 네트워크 중간에서 데이터를 볼 수 있는 사람이 있다면, 사용자가 입력한 내용을 그대로 확인할 수 있었다. 서버는 보안이 매우 중요한 시스템이기 때문에 이러한 방식은 위험하다. 이런 이유로 텔넷은 현재 거의 사용되지 않고, SSH(Secure Shell)로 대체되었다.
SSH and Secure Remote Login (SSH와 안전한 원격 접속)
SSH(Secure Shell)는 서버에 안전하게 원격 접속하기 위한 대표적인 프로그램이다. SSH는 텔넷처럼 원격 서버(Remote Server)에 접속하여 명령어(Command)를 입력하고 결과를 확인할 수 있게 해주지만, 중요한 차이점은 통신 내용을 암호화(Encryption)한다는 점이다. 따라서 사용자가 입력하는 비밀번호(Password), 명령어(Command), 서버에서 돌아오는 결과(Output)가 네트워크 중간에서 쉽게 노출되지 않는다.
서버 관리를 할 때 SSH는 매우 기본적인 도구이다. 리눅스 서버(Linux Server)는 보통 GUI(Graphical User Interface)보다 CLI(Command Line Interface)를 중심으로 관리되기 때문에, SSH를 통해 원격으로 접속한 뒤 터미널(Terminal)에서 명령어를 입력하여 서버를 설정하고 관리한다.
SSH Service and Restart (SSH 서비스와 재시작)
리눅스에서 SSH는 하나의 서비스(Service) 형태로 동작한다. 즉 백그라운드(Background)에서 계속 실행되면서 외부에서 들어오는 SSH 접속 요청을 기다린다. 사용자가 SSH 서버 프로그램을 설치하면 기본적인 접속 기능은 사용할 수 있지만, 설정 파일(Configuration File)을 수정한 경우에는 변경 사항이 바로 적용되지 않을 수 있다.
이럴 때는 SSH 서비스를 다시 시작(Restart)해야 한다. 강의에서 언급된 명령어는 다음과 같다.
sudo systemctl restart ssh.service
여기서 sudo는 관리자 권한(Superuser Privilege)으로 명령어를 실행한다는 의미이고, systemctl은 리눅스에서 서비스(Service)를 관리하는 명령어이다. restart는 서비스를 다시 시작하라는 뜻이며, ssh.service는 SSH 서비스(Service)를 의미한다. 즉 이 명령어는 SSH 서비스를 다시 시작해서 변경된 설정이 적용되도록 하는 명령어이다.
SSH Port and Configuration File (SSH 포트와 설정 파일)
SSH는 기본적으로 22번 포트(Port 22)를 사용한다. 포트(Port)는 네트워크에서 특정 서비스(Service)를 구분하기 위한 번호라고 이해할 수 있다. 예를 들어 웹페이지 접속에 사용되는 HTTP(HyperText Transfer Protocol)는 일반적으로 80번 포트(Port 80)를 사용하고, SSH는 보통 22번 포트를 사용한다.
하지만 22번 포트는 SSH의 기본 포트(Default Port)로 널리 알려져 있기 때문에, 외부 공격자가 SSH 접속을 시도할 때 가장 먼저 확인하는 포트가 될 수 있다. 그래서 보안 설정의 한 방법으로 SSH 포트를 다른 번호로 변경하기도 한다. 예를 들어 22번 대신 90번, 190번처럼 다른 포트 번호를 사용할 수 있다.
SSH 포트를 변경하려면 다음 설정 파일(Configuration File)을 수정한다.
/etc/ssh/sshd_config
이 파일은 SSH 서버 데몬(SSH Daemon), 즉 sshd의 설정 파일이다. 여기에서 Port에 해당하는 줄을 찾아 원하는 숫자로 변경하면 SSH 접속 포트를 바꿀 수 있다. 설정 파일을 수정한 뒤에는 앞에서 본 것처럼 SSH 서비스를 재시작해야 변경 사항이 적용된다.
sudo systemctl restart ssh.service
단, 포트를 변경한 후에는 접속할 때도 새 포트 번호를 지정해야 한다. 예를 들어 포트를 190번으로 바꾸었다면 다음과 같은 방식으로 접속해야 한다.
ssh -p 190 사용자이름@서버주소
여기서 -p 옵션은 접속할 포트 번호(Port Number)를 지정하는 옵션이다.
Telnet vs SSH (텔넷과 SSH의 차이)
텔넷(Telnet)과 SSH(Secure Shell)는 모두 원격 접속(Remote Access)을 위한 도구라는 공통점이 있다. 하지만 가장 큰 차이는 보안(Security)이다. 텔넷은 데이터를 암호화하지 않고 전송하기 때문에 중간에서 통신 내용을 가로채면 사용자의 입력 정보를 볼 수 있다. 반면 SSH는 통신 내용을 암호화하여 전송하므로 훨씬 안전하다.
따라서 현대 서버 환경에서는 텔넷을 거의 사용하지 않고 SSH를 사용한다. 특히 서버에는 관리자 계정, 시스템 설정, 서비스 운영과 관련된 중요한 정보가 많기 때문에, 원격 접속 도구는 반드시 보안을 고려해야 한다.
Additional Notes (추가 설명)
Port(포트)는 네트워크에서 특정 프로그램이나 서비스를 구분하는 번호이다. 같은 서버 안에서도 웹 서버(Web Server), SSH 서버(SSH Server), 데이터베이스 서버(Database Server) 등이 동시에 실행될 수 있는데, 각각 다른 포트를 사용하여 구분된다.
SSH 기본 포트(Default SSH Port)는 22번이다. 하지만 보안상의 이유로 포트를 바꾸는 경우도 있다. 다만 포트를 바꾸는 것만으로 완전한 보안이 되는 것은 아니다. 이것은 공격 시도를 줄이는 보조적인 방법일 뿐이며, 강한 비밀번호(Strong Password), 공개키 인증(Public Key Authentication), 방화벽(Firewall) 설정 등이 함께 필요하다.
sshd_config에서 sshd는 SSH Daemon(SSH 데몬)을 의미한다. 데몬(Daemon)은 백그라운드에서 계속 실행되며 특정 서비스를 제공하는 프로그램이다. SSH 데몬은 외부에서 들어오는 SSH 접속 요청을 기다리다가, 사용자가 접속하면 인증(Authentication)을 처리하고 터미널 환경을 제공한다.
systemctl은 리눅스에서 서비스(Service)를 관리하는 대표적인 명령어이다. 예를 들어 서비스를 시작(Start), 중지(Stop), 재시작(Restart), 상태 확인(Status)할 때 사용할 수 있다.
sudo systemctl status ssh.service
위 명령어를 사용하면 현재 SSH 서비스가 정상적으로 실행 중인지 확인할 수 있다.
SSH Key-Based Login (SSH 키 기반 로그인)
SSH(Secure Shell)를 사용해 원격 서버(Remote Server)에 접속할 때 보통은 다음과 같은 형태의 명령어를 사용한다.
ssh username@server_address
여기서 username은 서버에 존재하는 사용자 계정(User Account)이고, server_address는 도메인 이름(Domain Name)이나 IP 주소(IP Address)가 될 수 있다. 이렇게 접속을 시도하면 비밀번호(Password)를 입력하라는 화면이 나타나고, 올바른 비밀번호를 입력하면 원격 서버에 로그인할 수 있다.
하지만 이 방식은 서버에 접속할 때마다 매번 비밀번호를 입력해야 한다는 불편함이 있다. 서버를 자주 관리하거나, 여러 서버에 반복적으로 접속해야 하는 환경에서는 매번 비밀번호를 입력하는 방식이 비효율적일 수 있다. 이런 문제를 해결하기 위해 사용하는 방법이 SSH Key-Based Login(SSH 키 기반 로그인)이다.
Public Key and Private Key (공개키와 개인키)
SSH 키 기반 로그인(SSH Key-Based Login)에서는 공개키(Public Key)와 개인키(Private Key)라는 두 개의 키(Key)를 사용한다. 이 두 키는 서로 짝을 이루는 관계이다.
개인키(Private Key)는 사용자 본인만 가지고 있어야 하는 중요한 키이다. 말 그대로 개인적으로 보관해야 하는 키이며, 다른 사람에게 노출되면 안 된다. 개인키는 사용자가 “정말 이 키의 주인인지”를 증명하는 데 사용된다.
반면 공개키(Public Key)는 서버에 등록해 둘 수 있는 키이다. 이름 그대로 공개될 수 있는 키이지만, 그렇다고 해서 아무 곳에나 무분별하게 배포해도 된다는 뜻은 아니다. 공개키가 서버의 특정 계정에 등록되면, 그 공개키와 짝이 되는 개인키를 가진 사용자는 비밀번호 없이 해당 계정으로 접속할 수 있기 때문이다.
즉 SSH 키 기반 로그인에서는 클라이언트(Client) 쪽에는 개인키(Private Key)가 있고, 서버(Server) 쪽에는 공개키(Public Key)가 저장된다. 사용자가 SSH로 접속을 시도하면 서버는 등록된 공개키와 사용자의 개인키가 서로 짝이 맞는지 검증한다. 검증에 성공하면 비밀번호를 입력하지 않아도 로그인이 가능해진다.
Creating SSH Keys with ssh-keygen (ssh-keygen으로 SSH 키 생성하기)
SSH 키를 만들 때는 ssh-keygen 명령어를 사용한다. 강의 자료에서는 다음과 같은 형식이 제시되었다.
ssh-keygen -t 알고리즘
예를 들어 RSA 알고리즘(RSA Algorithm)을 사용하고, 키 길이를 4096비트(Bit)로 지정하려면 다음과 같이 입력할 수 있다.
ssh-keygen -t rsa -b 4096
여기서 -t 옵션은 사용할 암호화 알고리즘(Algorithm)을 지정하는 옵션이고, -b 옵션은 키의 길이(Key Length)를 지정하는 옵션이다. 알고리즘에는 RSA, Ed25519 등 여러 종류가 있으며, 어떤 암호화 방식을 사용할지 선택할 수 있다.
명령어를 실행하면 사용자의 홈 디렉토리(Home Directory) 아래에 있는 .ssh 디렉토리(Directory)에 키 파일이 생성된다. 예를 들어 RSA 알고리즘을 사용하면 보통 다음과 같은 파일이 만들어진다.
~/.ssh/id_rsa~/.ssh/id_rsa.pub
id_rsa는 개인키(Private Key)이고, id_rsa.pub는 공개키(Public Key)이다. 파일 이름 끝에 .pub가 붙어 있으면 공개키라고 이해하면 된다.
Copying the Public Key to the Server (공개키를 서버에 복사하기)
키를 생성한 뒤에는 공개키(Public Key)를 로그인하려는 서버 계정에 복사해야 한다. 이때 사용하는 대표적인 명령어가 ssh-copy-id이다.
ssh-copy-id username@server_address
예를 들어 서버의 계정 이름이 koreacu이고 서버 주소가 192.168.0.10이라면 다음과 같이 사용할 수 있다.
ssh-copy-id koreacu@192.168.0.10
이 명령어를 실행하면 내 컴퓨터에 있는 공개키가 원격 서버의 해당 계정으로 복사된다. 그리고 서버의 홈 디렉토리 아래 .ssh/authorized_keys 파일에 공개키 내용이 저장된다.
~/.ssh/authorized_keys
authorized_keys 파일은 “이 계정으로 접속을 허용할 공개키 목록”이라고 이해하면 된다. 이 파일 안에 등록된 공개키와 짝이 맞는 개인키를 가진 사용자는 해당 계정으로 SSH 접속을 할 수 있다.
만약 ssh-copy-id 명령어를 사용할 수 없는 상황이라면, 공개키 파일의 내용을 직접 복사해서 서버의 .ssh/authorized_keys 파일에 붙여 넣을 수도 있다. 즉 공개키 자체는 텍스트 형태의 긴 문자열이므로, 이 내용을 서버의 해당 파일에 저장하면 된다.
File Permissions for authorized_keys (authorized_keys 파일 권한 설정)
SSH 키 기반 로그인에서 파일 권한(File Permission)은 매우 중요하다. 특히 .ssh/authorized_keys 파일은 아무나 수정할 수 있으면 안 된다. 만약 다른 사용자나 그룹(Group, Others)이 이 파일에 마음대로 쓰기(Write)를 할 수 있다면, 누군가 자신의 공개키를 추가해서 서버에 접속할 수 있는 위험이 생긴다.
그래서 강의 자료에서는 다음 명령어가 제시되었다.
chmod go-w .ssh/authorized_keys
여기서 chmod는 파일 권한을 변경하는 명령어이고, go-w는 group과 others에서 write 권한을 제거하라는 의미이다. 조금 더 풀어서 보면 다음과 같다.
g는 group을 의미한다. o는 others를 의미한다. -w는 write permission, 즉 쓰기 권한을 제거한다는 의미이다.
따라서 이 명령어는 .ssh/authorized_keys 파일에 대해 그룹 사용자와 다른 사용자들이 쓰기 권한을 갖지 못하도록 설정하는 명령어이다. 이렇게 해야 다른 사람이 마음대로 공개키를 추가하는 일을 막을 수 있다.
Why SSH Keys Are Useful (SSH 키 기반 로그인이 유용한 이유)
SSH 키 기반 로그인(SSH Key-Based Login)을 사용하면 매번 비밀번호를 입력하지 않아도 서버에 접속할 수 있다. 특히 서버나 클러스터(Cluster)를 관리할 때 매우 편리하다. 여러 대의 서버에 반복적으로 접속해야 하거나, 특정 계정으로 자동 접속해야 하는 경우 SSH 키 방식이 자주 사용된다.
예를 들어 클라우드(Cloud) 환경에서 서버 인스턴스(Instance)를 만들거나, 규모가 큰 클러스터링 프로그램(Clustering Program)을 설치할 때 SSH 키를 이용한 접속 설정을 요구하는 경우가 많다. 이는 서버 간 접속이나 자동화된 관리 작업에서 비밀번호 입력 방식보다 훨씬 효율적이기 때문이다.
또한 SSH 키 방식은 비밀번호 기반 로그인(Password-Based Login)보다 보안적으로 더 강하게 설정할 수 있다. 개인키(Private Key)를 안전하게 관리하고, 필요하다면 개인키에 암호(Passphrase)를 추가하면 더 안전하게 사용할 수 있다.
Security Considerations for SSH Keys (SSH 키 사용 시 보안 주의사항)
SSH 키를 사용할 때 가장 중요한 것은 개인키(Private Key)를 안전하게 보관하는 것이다. 개인키는 사용자의 신분을 증명하는 핵심 정보이기 때문에 절대 다른 사람에게 공유하면 안 된다. 개인키가 유출되면, 그 키와 짝이 되는 공개키가 등록된 서버에 다른 사람이 접속할 수 있는 위험이 생긴다.
공개키(Public Key)는 개인키보다 덜 민감하지만, 그래도 관리가 필요하다. 공개키가 서버의 authorized_keys 파일에 등록되면 그 키와 짝이 맞는 개인키를 가진 사용자는 접속 권한을 갖게 된다. 따라서 서버 관리자는 authorized_keys 파일에 어떤 공개키가 등록되어 있는지 확인하고, 더 이상 필요 없는 키는 제거해야 한다.
암호화 알고리즘(Encryption Algorithm)과 키 길이(Key Length)도 중요하다. 과거에는 128비트(Bit) 암호화도 매우 안전하다고 여겨졌지만, 컴퓨터 성능이 발전하면서 더 강한 암호화 방식이 필요해졌다. 강의에서 언급된 것처럼 양자컴퓨터(Quantum Computer)가 발전하면 기존 암호화 방식 중 일부는 더 쉽게 공격받을 가능성도 있다. 따라서 실제 환경에서는 현재 권장되는 알고리즘과 충분한 키 길이를 사용하는 것이 중요하다.
전체적으로 보면 SSH 키 기반 로그인은 “클라이언트에는 개인키를 보관하고, 서버에는 공개키를 등록해 두는 방식”이다. 그리고 접속할 때 두 키가 서로 짝이 맞는지 검증하여, 비밀번호 없이 안전하게 로그인할 수 있도록 해준다.
Additional Notes (추가 설명)
ssh-keygen -t rsa -b 4096은 RSA 방식으로 4096비트 키를 만드는 예시이다. 최근에는 다음과 같이 Ed25519 알고리즘(Ed25519 Algorithm)을 사용하는 경우도 많다.
ssh-keygen -t ed25519
개인키(Private Key)는 보통 ~/.ssh/id_rsa 또는 ~/.ssh/id_ed25519처럼 .pub가 붙지 않은 파일이다. 이 파일은 절대 공유하면 안 된다.
공개키(Public Key)는 보통 ~/.ssh/id_rsa.pub 또는 ~/.ssh/id_ed25519.pub처럼 .pub가 붙은 파일이다. 이 파일의 내용을 서버의 ~/.ssh/authorized_keys에 등록한다.
SSH 키 기반 로그인을 설정한 뒤에는 다음처럼 접속할 수 있다.
ssh username@server_address
설정이 제대로 되어 있다면 비밀번호 입력 없이 바로 로그인된다. 단, 개인키에 Passphrase(개인키 암호)를 설정했다면 접속 시 해당 암호를 입력해야 할 수 있다.
SSHFS and Remote File Access (SSHFS와 원격 파일 접근)
SSHFS(SSH File System)는 SSH(Secure Shell) 프로토콜을 사용해서 원격 서버(Remote Server)에 있는 파일이나 디렉터리(Directory)를 내 로컬 컴퓨터(Local Computer)에서 직접 접근할 수 있게 해주는 방식이다. 일반적인 SSH 접속은 터미널(Terminal)을 통해 명령어를 입력하고 결과를 확인하는 방식이지만, SSHFS를 사용하면 원격 서버의 파일을 내 컴퓨터의 파일 탐색기(File Explorer)나 Finder처럼 열어볼 수 있다.
예를 들어 실습 환경에서 가상 머신(Virtual Machine)에 우분투 서버(Ubuntu Server)를 설치했다고 하자. 보통은 윈도우(Windows), 맥(Mac), 리눅스(Linux) 같은 로컬 컴퓨터에서 SSH로 접속한 뒤 터미널에서 명령어를 입력하여 파일을 확인하거나 설정 파일(Configuration File)을 수정한다. 이 방식은 서버 관리에는 적합하지만, 이미지 파일(Image File)이나 여러 문서 파일을 직접 확인해야 할 때는 불편할 수 있다.
기존 방식에서는 원격 서버에 있는 이미지 파일을 보고 싶다면 SCP(Secure Copy)를 사용해서 파일을 로컬 컴퓨터로 복사한 뒤, 이미지 뷰어(Image Viewer)로 열어보는 과정을 거쳐야 한다. 하지만 SSHFS를 사용하면 원격 서버의 디렉터리를 내 컴퓨터의 특정 폴더에 연결해 둘 수 있다. 그러면 파일 탐색기에서 원격 파일 목록이 보이고, 파일을 더블클릭하면 로컬 파일처럼 바로 열 수 있다.
Installing SSHFS (SSHFS 설치)
SSHFS를 사용하려면 먼저 클라이언트(Client) 쪽에 SSHFS 프로그램을 설치해야 한다. 우분투(Ubuntu)에서는 다음 명령어로 설치할 수 있다.
sudo apt install sshfs
여기서 sudo는 관리자 권한(Superuser Privilege)으로 명령어를 실행한다는 뜻이고, apt는 우분투에서 패키지(Package)를 설치하거나 관리할 때 사용하는 패키지 관리자(Package Manager)이다. sshfs는 SSH를 이용해 원격 파일 시스템(Remote File System)을 마운트(Mount)할 수 있게 해주는 프로그램이다.
Mounting Remote Files with SSHFS (SSHFS로 원격 파일 마운트하기)
SSHFS를 사용하면 원격 서버의 특정 디렉터리를 내 로컬 컴퓨터의 디렉터리에 연결할 수 있다. 강의 자료에서는 다음과 같은 형태의 명령어가 제시되었다.
sshfs -o idmap=user id@remote_host:/remote/path ~/remote_files
이 명령어는 원격 서버(Remote Host)에 있는 /remote/path 디렉터리를 내 컴퓨터의 ~/remote_files 디렉터리에 연결하는 명령이다. 연결이 완료되면 ~/remote_files 폴더 안에서 원격 서버의 파일들을 로컬 파일처럼 볼 수 있다.
여기서 id는 원격 서버에 로그인할 사용자 계정(User Account)이고, remote_host는 원격 서버의 IP 주소(IP Address)나 도메인 이름(Domain Name)이다. /remote/path는 원격 서버에서 접근하려는 경로(Path)이고, ~/remote_files는 내 컴퓨터에서 원격 파일을 보여줄 마운트 지점(Mount Point)이다.
예를 들어 원격 서버의 사용자 이름이 koreacu, 서버 주소가 192.168.0.10, 원격 디렉터리가 /home/koreacu/project, 로컬 연결 폴더가 ~/remote_files라면 다음과 같이 사용할 수 있다.
sshfs -o idmap=user koreacu@192.168.0.10:/home/koreacu/project ~/remote_files
이후 내 컴퓨터에서 ~/remote_files 폴더를 열면 원격 서버의 /home/koreacu/project 안에 있는 파일들이 보이게 된다.
Unmounting SSHFS (SSHFS 연결 해제하기)
SSHFS로 연결한 원격 디렉터리를 더 이상 사용하지 않을 때는 마운트 해제(Unmount)를 해야 한다. 강의 자료에서는 다음 명령어가 제시되었다.
fusermount -u ~/remote_files
여기서 fusermount는 FUSE(File System in Userspace) 기반 파일 시스템을 마운트하거나 해제할 때 사용하는 명령어이고, -u 옵션은 unmount, 즉 연결 해제를 의미한다. 이 명령어를 실행하면 ~/remote_files에 연결되어 있던 원격 디렉터리 연결이 해제된다.
SSHFS vs NFS (SSHFS와 NFS의 차이)
강의에서 NFS(Network File System)도 함께 언급되었다. NFS는 네트워크를 통해 원격 디렉터리를 공유하는 대표적인 방식이다. 하지만 SSHFS와 NFS는 동작 방식과 사용 목적에 차이가 있다.
NFS(Network File System)는 보통 시스템 차원(System Level)에서 디렉터리를 공유한다. 서버 관리자가 특정 디렉터리를 export하고, 다른 컴퓨터들이 그 디렉터리를 네트워크를 통해 마운트해서 사용하는 방식이다. 여러 사용자나 여러 시스템이 공통으로 접근해야 하는 공유 디렉터리를 만들 때 자주 사용된다.
반면 SSHFS(SSH File System)는 SSH 로그인 정보를 기반으로 사용자 대 사용자(User-to-User), 계정 대 계정(Account-to-Account) 형태로 연결된다. 즉 내가 SSH로 로그인할 수 있는 계정의 권한 범위 안에서 원격 파일에 접근하는 방식이다. 그래서 별도의 시스템 차원 공유 설정 없이도, SSH 접속 권한만 있으면 비교적 쉽게 원격 파일을 로컬처럼 사용할 수 있다.
이 차이를 간단히 정리하면, NFS는 서버가 디렉터리를 시스템 차원에서 공유하는 방식이고, SSHFS는 사용자가 SSH 계정을 통해 자신의 권한으로 원격 디렉터리에 접근하는 방식이다.
Why SSHFS Is Convenient (SSHFS가 편리한 이유)
SSHFS의 가장 큰 장점은 원격 파일을 로컬 파일처럼 다룰 수 있다는 점이다. SSH만 사용할 경우에는 터미널에서 ls, cd, cat, nano, vim 같은 명령어를 사용해 파일을 확인하고 수정해야 한다. 물론 서버 관리에는 이 방식이 중요하지만, 파일이 많거나 이미지, 문서, 코드 파일을 자주 열어봐야 한다면 불편할 수 있다.
예를 들어 원격 서버의 특정 디렉터리 안에 이미지 파일이 있다고 하자. SSH만 사용한다면 파일 이름을 확인하고, 필요하면 SCP로 파일을 복사한 뒤 로컬에서 열어봐야 한다. 하지만 SSHFS를 사용하면 해당 디렉터리가 내 컴퓨터의 폴더처럼 보이기 때문에 파일을 더블클릭해서 바로 이미지 뷰어로 확인할 수 있다.
이미지 파일뿐만 아니라 텍스트 파일(Text File), 설정 파일(Configuration File), 소스 코드(Source Code), 문서 파일(Document File) 등도 로컬 프로그램으로 바로 열어볼 수 있다. 따라서 SSHFS는 서버의 파일을 더 편리하게 확인하고 수정하기 위한 도구라고 볼 수 있다.
다만 SSHFS는 편리성을 위한 도구이지, 모든 서버 작업을 대체하는 것은 아니다. 서버 설정 변경, 프로그램 설치, 서비스 재시작 같은 작업은 여전히 SSH 터미널을 통해 명령어로 수행하는 경우가 많다. SSHFS는 특히 파일을 확인하거나 편집하는 작업에서 편리함을 제공한다.
Additional Notes (추가 설명)
Mount(마운트)는 어떤 저장장치나 원격 파일 시스템을 내 컴퓨터의 특정 디렉터리에 연결해서 사용할 수 있게 만드는 것을 의미한다. SSHFS에서는 원격 서버의 디렉터리를 내 컴퓨터의 폴더처럼 연결한다.
SCP(Secure Copy)는 SSH를 이용해 원격 서버와 로컬 컴퓨터 사이에서 파일을 복사하는 명령어이다. 파일을 한 번 복사해서 가져오는 방식이라면 SCP가 적합하고, 원격 디렉터리를 계속 로컬처럼 열어보고 싶다면 SSHFS가 더 편리하다.
FUSE(File System in Userspace)는 일반 사용자가 커널(Kernel) 내부를 직접 수정하지 않고도 파일 시스템(File System)을 사용할 수 있게 해주는 구조이다. SSHFS는 FUSE를 기반으로 동작한다.
SSHFS를 사용하려면 원격 서버에 SSH 접속이 가능해야 한다. 즉 SSH 서버(SSH Server)가 실행 중이어야 하고, 사용자가 해당 계정으로 로그인할 권한을 가지고 있어야 한다.
SSHFS를 사용할 때 연결할 로컬 디렉터리, 예를 들어 ~/remote_files는 미리 만들어 두는 것이 좋다.
mkdir ~/remote_files
그 다음 sshfs 명령어를 실행하면 원격 디렉터리를 이 폴더에 연결할 수 있다.
LAMP Stack and Apache Web Server
LAMP Stack(LAMP 스택)은 예전부터 웹 서비스(Web Service)를 구축할 때 많이 사용되던 대표적인 서버 소프트웨어 구성이다. LAMP는 Linux, Apache, MySQL, PHP의 앞 글자를 모은 이름이다. 여기서 Linux(리눅스)는 운영체제(Operating System), Apache(아파치)는 웹 서버(Web Server), MySQL은 데이터베이스(Database), PHP는 웹 페이지를 동적으로 처리하기 위한 서버 사이드 언어(Server-side Language)를 의미한다.
웹 서비스를 제공하려면 단순히 서버 하드웨어(Server Hardware)만 있는 것으로는 부족하다. 서버 하드웨어 위에 운영체제(Operating System)를 설치하고, 그 위에 웹 요청을 처리할 서버 프로그램(Server Program)을 설치해야 한다. LAMP는 이런 웹 서비스 환경을 구성하는 대표적인 조합이라고 볼 수 있다.
Apache Web Server (아파치 웹 서버)
Apache(Apache HTTP Server)는 클라이언트(Client), 즉 사용자의 웹 브라우저(Web Browser)로부터 들어오는 요청(Request)을 받아 웹 페이지(Web Page)를 응답(Response)으로 돌려주는 웹 서버 프로그램(Web Server Program)이다.
예를 들어 사용자가 브라우저 주소창에 서버의 IP 주소(IP Address)를 입력하면, 브라우저는 해당 서버에 웹 페이지를 요청한다. 이때 서버에 Apache가 설치되어 있고 정상적으로 실행 중이라면, Apache가 요청을 받아 기본 페이지(Default Page)를 사용자에게 보여준다.
우분투(Ubuntu)에서는 Apache를 다음과 같이 설치할 수 있다.
sudo apt install apache2
여기서 apache2는 우분투에서 Apache 웹 서버를 설치할 때 사용하는 패키지(Package) 이름이다. 설치가 완료된 뒤 Apache가 정상적으로 실행되고 있다면, 웹 브라우저에서 해당 컴퓨터의 IP 주소로 접속했을 때 Apache 기본 페이지가 나타난다. 이 기본 페이지가 보인다는 것은 웹 서버(Web Server)가 정상적으로 설치되고 실행되고 있다는 의미이다.
Apache Service Restart (아파치 서비스 재시작)
Apache도 SSH처럼 리눅스에서 서비스(Service) 형태로 동작한다. 즉 백그라운드(Background)에서 계속 실행되면서 외부에서 들어오는 웹 요청(Web Request)을 기다린다.
Apache 설정 파일(Configuration File)을 수정한 경우에는 변경 사항을 적용하기 위해 서비스를 다시 시작(Restart)해야 한다. 강의에서 언급된 명령어는 다음과 같다.
sudo systemctl restart apache2.service
이 명령어는 apache2.service를 재시작하여 변경된 설정이 적용되도록 한다. 만약 설정 파일을 수정했는데 웹 페이지가 제대로 보이지 않는다면, 설정값을 잘못 입력했거나 문법 오류(Configuration Error)가 있을 가능성이 있다. 이 경우에는 설정 파일을 다시 확인하고 수정한 뒤 Apache를 다시 재시작해야 한다.
Apache Configuration Files (아파치 설정 파일)
Apache의 주요 설정 파일(Configuration Files)은 보통 /etc/apache2 디렉터리 아래에 위치한다.
/etc/apache2
이 디렉터리 안에는 Apache 동작을 제어하는 여러 설정 파일들이 있다. 강의에서 언급된 대표적인 파일은 다음과 같다.
/etc/apache2/apache2.conf
/etc/apache2/ports.conf
/etc/apache2/magic
apache2.conf는 Apache의 전체적인 기본 설정을 담당하는 주요 설정 파일이다. Apache가 어떻게 동작할지, 어떤 설정 파일들을 포함할지 등의 기본적인 내용이 들어 있다.
ports.conf는 Apache가 어떤 포트(Port)에서 요청을 받을지 설정하는 파일이다. 웹 서버는 보통 HTTP(HyperText Transfer Protocol)의 기본 포트인 80번 포트(Port 80)를 사용한다. 사용자가 브라우저에서 서버 IP 주소로 접속했을 때 Apache가 응답하려면, Apache가 해당 포트에서 요청을 기다리고 있어야 한다.
magic 파일은 파일의 형식(File Type)을 판단하는 데 사용될 수 있는 설정과 관련이 있다. 강의에서는 세부적인 내용보다는 Apache 설정 파일들이 /etc/apache2 아래에 모여 있다는 점을 중심으로 이해하면 된다.
Default Page and Testing Apache
Apache를 처음 설치한 뒤 웹 브라우저에서 Apache가 설치된 컴퓨터의 IP 주소로 접속하면 기본 페이지(Default Page)가 나타난다. 이 페이지는 Apache가 정상적으로 설치되었고, 웹 서버가 클라이언트의 요청을 받을 준비가 되어 있다는 것을 확인하는 용도이다.
예를 들어 가상 머신(Virtual Machine)에 Ubuntu Server를 설치하고 그 안에 Apache를 설치했다면, 같은 네트워크에서 해당 가상 머신의 IP 주소로 접속하여 Apache 기본 페이지가 보이는지 확인할 수 있다. 기본 페이지가 보인다면 웹 서버 설치는 성공한 것이다.
만약 설정을 변경한 뒤 페이지가 보이지 않는다면 다음과 같은 가능성을 생각해볼 수 있다. Apache 서비스가 실행 중이 아닐 수 있고, 설정 파일에 오류가 있을 수 있으며, 포트 설정이 잘못되었거나 네트워크 연결 문제가 있을 수도 있다. 이때는 설정을 다시 확인하고 Apache 서비스를 재시작해야 한다.
sudo systemctl restart apache2.service
결국 Apache 실습의 기본 흐름은 Apache 설치, IP 주소로 접속하여 기본 페이지 확인, 설정 파일 수정, 서비스 재시작, 다시 접속해서 결과 확인의 순서로 이해할 수 있다.
Role of LAMP in Web Services (웹 서비스에서 LAMP의 역할)
LAMP Stack(LAMP 스택)은 웹 서비스가 동작하기 위해 필요한 기본 구성 요소를 하나의 조합으로 묶어 이해하는 방식이다. Linux는 서버의 운영체제 역할을 하고, Apache는 웹 브라우저의 요청을 받아 웹 페이지를 제공한다. MySQL은 회원 정보, 게시글, 상품 정보 같은 데이터를 저장하는 데이터베이스 역할을 한다. PHP는 사용자의 요청에 따라 동적인 웹 페이지(Dynamic Web Page)를 생성하는 역할을 한다.
예를 들어 사용자가 웹사이트에 접속하면 Apache가 요청을 받는다. 만약 단순한 HTML 파일(HTML File)이라면 Apache가 바로 파일을 응답으로 보낼 수 있다. 하지만 로그인, 게시판, 검색처럼 데이터가 필요한 기능이라면 PHP가 요청을 처리하고, 필요한 데이터를 MySQL에서 가져온 뒤 결과 페이지를 만들어 Apache를 통해 사용자에게 전달한다.
따라서 LAMP는 웹 서버(Web Server), 데이터베이스(Database), 서버 사이드 프로그래밍(Server-side Programming)이 함께 동작하는 전형적인 웹 서비스 구조라고 볼 수 있다.
Additional Notes (추가 설명)
Apache(Apache HTTP Server)는 웹 서버(Web Server) 프로그램이다. 사용자의 브라우저가 보낸 HTTP 요청(HTTP Request)을 받아 HTML, 이미지, CSS, JavaScript 같은 웹 리소스(Web Resource)를 응답으로 보내는 역할을 한다.
LAMP Stack(LAMP 스택)의 구성은 다음과 같이 정리할 수 있다.
Linux : 운영체제(Operating System)
Apache : 웹 서버(Web Server)
MySQL : 데이터베이스(Database)
PHP : 서버 사이드 언어(Server-side Language)
Apache 설정을 수정한 뒤 바로 결과가 적용되지 않는 경우가 많기 때문에, 설정 변경 후에는 서비스를 재시작(Restart)해야 한다.
sudo systemctl restart apache2.service
Apache가 정상 실행 중인지 확인하려면 다음 명령어도 사용할 수 있다.
sudo systemctl status apache2.service
웹 브라우저에서 서버 IP 주소로 접속했을 때 Apache 기본 페이지(Default Page)가 보이면, Apache 웹 서버가 정상적으로 설치되고 실행 중이라고 이해하면 된다.
Apache Directory Structure and Enable System (Apache 디렉토리 구조와 활성화 방식)
Apache2(Apache HTTP Server)를 설치하면 설정 파일(Configuration File)들이 /etc/apache2/ 디렉토리 아래에 정리되어 있다. 이 디렉토리에는 conf-available, conf-enabled, mods-available, mods-enabled, sites-available, sites-enabled와 같은 하위 디렉토리들이 존재한다.
이 구조에서 핵심은 available과 enabled의 차이를 이해하는 것이다. available은 “사용 가능한 설정”이라는 의미이고, enabled는 “현재 실제로 활성화되어 적용 중인 설정”이라는 의미이다. 즉 어떤 설정 파일이 available 디렉토리에 있다고 해서 Apache에 바로 적용되는 것은 아니다. 그 설정을 실제로 사용하려면 enabled 상태로 만들어야 한다.
Apache Available and Enabled Directories
conf-available 디렉토리에는 Apache에서 사용할 수 있는 설정 파일(Configuration Files)들이 들어 있다. 하지만 이 파일들은 아직 적용된 상태가 아니라, 필요할 때 선택해서 활성화할 수 있는 후보라고 볼 수 있다.
반대로 conf-enabled 디렉토리에는 실제로 Apache에 적용되는 설정들이 들어 있다. 보통 conf-enabled 안의 파일들은 conf-available에 있는 파일을 직접 복사한 것이 아니라, 심볼릭 링크(Symbolic Link) 형태로 연결되어 있다. Apache는 재시작(Restart)될 때 enabled 디렉토리에 있는 설정들을 읽고 적용한다.
이와 같은 구조는 모듈(Module)과 사이트(Site) 설정에서도 동일하게 사용된다.
mods-available에는 사용 가능한 Apache 모듈(Module)과 관련 설정 파일들이 들어 있다.mods-enabled에는 실제로 활성화된 모듈들이 들어 있다.sites-available에는 사용 가능한 가상 호스트(Virtual Host) 설정 파일들이 들어 있다.sites-enabled에는 실제로 활성화되어 Apache에 적용되는 사이트 설정들이 들어 있다.
Available vs Enabled (사용 가능 상태와 활성화 상태)
available과 enabled의 관계는 “설치되어 있지만 아직 사용하지 않는 상태”와 “실제로 사용 중인 상태”의 차이로 이해할 수 있다.
예를 들어 어떤 Apache 모듈(Module)이 mods-available에 존재한다면, 그 모듈은 시스템에 준비되어 있는 상태이다. 하지만 아직 Apache가 그 모듈을 사용하고 있는 것은 아니다. 사용자가 해당 모듈을 활성화하면 mods-enabled에 심볼릭 링크(Symbolic Link)가 만들어지고, Apache를 재시작한 뒤 실제로 적용된다.
사이트 설정(Site Configuration)도 마찬가지이다. sites-available에는 여러 개의 웹사이트 설정을 준비해 둘 수 있다. 그중 실제로 서비스할 사이트만 sites-enabled로 활성화하면 Apache가 해당 사이트 설정을 읽어 웹 서비스를 제공한다.
Apache Helper Commands (Apache 도구 명령어)
Apache에서는 사용자가 직접 파일을 복사하거나 링크를 만드는 대신, 전용 도구 명령어(Helper Commands)를 사용해 설정을 활성화하거나 비활성화할 수 있다. 강의 자료에 나온 대표적인 명령어는 다음과 같다.
a2enconf
a2disconf
a2enmod
a2dismod
a2ensite
a2dissite
a2enconf는 Apache 설정(Configuration)을 활성화(enable)할 때 사용한다.
a2disconf는 활성화된 설정을 비활성화(disable)할 때 사용한다.
a2enmod는 Apache 모듈(Module)을 활성화할 때 사용한다.
a2dismod는 활성화된 모듈을 비활성화할 때 사용한다.
a2ensite는 사이트 설정(Site Configuration)을 활성화할 때 사용한다.
a2dissite는 활성화된 사이트 설정을 비활성화할 때 사용한다.
예를 들어 특정 사이트 설정을 활성화하려면 다음과 같은 방식으로 사용할 수 있다.
sudo a2ensite 사이트설정파일이름
모듈을 활성화하려면 다음과 같이 사용할 수 있다.
sudo a2enmod 모듈이름
이 명령어들은 내부적으로 available 디렉토리에 있는 파일을 enabled 디렉토리로 연결해 주는 역할을 한다. 사용자가 직접 파일을 복사하는 것이 아니라, Apache가 정해둔 방식에 따라 설정을 활성화하는 것이다.
Applying Apache Settings (Apache 설정 적용)
Apache 설정을 available에서 enabled 상태로 바꾸었다고 해서 항상 즉시 적용되는 것은 아니다. Apache는 설정 파일을 읽고 동작하는 서비스(Service)이기 때문에, 설정을 변경한 뒤에는 보통 Apache를 다시 시작(Restart)해야 한다.
sudo systemctl restart apache2.service
Apache가 재시작되면 enabled 디렉토리에 연결된 설정 파일들을 읽고 실제 서비스에 반영한다. 따라서 설정 파일을 수정하거나, 모듈을 활성화하거나, 사이트 설정을 변경한 뒤에는 재시작을 통해 변경 사항을 적용해야 한다.
이 구조를 이해하면 Apache 설정 관리가 조금 더 명확해진다. /etc/apache2/ 아래에는 사용 가능한 설정들이 모여 있고, 실제로 적용되는 설정들은 enabled 디렉토리에 연결된다. 그리고 Apache가 다시 시작될 때 enabled된 설정들이 적용되어 웹 서버(Web Server)가 동작하게 된다.
Additional Notes (추가 설명)
심볼릭 링크(Symbolic Link)는 원본 파일을 직접 복사하지 않고, 다른 위치에서 그 파일을 가리키도록 만든 연결 파일이다. Apache의 enabled 디렉토리에는 보통 실제 설정 파일 복사본이 아니라, available 디렉토리에 있는 파일을 가리키는 심볼릭 링크가 들어간다.
available은 “설치되어 있고 선택 가능하지만 아직 적용되지 않은 상태”이고, enabled는 “현재 Apache가 읽어서 적용하는 상태”라고 기억하면 쉽다.
Apache 설정을 변경한 뒤 웹페이지가 제대로 보이지 않는다면 설정 파일의 문법 오류(Configuration Syntax Error), 잘못된 포트 설정(Port Configuration), 사이트 설정 오류(Site Configuration Error) 등을 의심할 수 있다. 이때는 설정을 다시 확인한 뒤 Apache를 재시작해야 한다.
실습에서는 직접 a2ensite, a2enmod 같은 명령어를 사용해 보면 available에서 enabled로 연결되는 구조를 더 쉽게 이해할 수 있다. 특히 나중에 여러 웹사이트를 한 서버에서 운영하거나, PHP 모듈(PHP Module), SSL 모듈(SSL Module) 등을 활성화할 때 이 구조가 자주 사용된다.
MySQL Server in LAMP (LAMP의 MySQL 서버)
MySQL(MySQL Server)은 LAMP(Linux, Apache, MySQL, PHP) 구성에서 데이터베이스(Database)를 담당하는 서버 프로그램이다. 웹 서비스에서 회원 정보, 게시글, 상품 정보 같은 데이터를 저장하고 관리할 때 사용된다.
MySQL은 Ubuntu에서 다음 명령어로 설치할 수 있다.
sudo apt install mysql-server
설치 후 MySQL 서비스를 재시작할 때는 두 가지 방식이 있다.
sudo service mysql restart
sudo systemctl restart mysql.service
service 명령어는 예전 방식이고, systemctl은 최근 Linux(Ubuntu)에서 주로 사용하는 방식이다. 둘 다 MySQL 서비스를 재시작하는 명령어이지만, 요즘은 보통 systemctl을 더 많이 사용한다. MySQL이 실행될 때 발생하는 메시지나 오류는 journalctl로 확인할 수 있다.
sudo journalctl -u mysql
여기서 journalctl은 서비스 로그(Service Log)를 확인하는 명령어이다. MySQL이 정상적으로 실행되지 않거나 문제가 생겼을 때 원인을 확인하는 데 사용한다.
MySQL의 주요 설정 파일은 /etc/mysql/ 아래에 있다. 특히 다음 파일에서 네트워크 접속 관련 설정을 변경할 수 있습니다.
/etc/mysql/mysql.conf.d/mysqld.cnf
이 파일 안의 bind-address 설정은 MySQL 서버가 어떤 IP 주소에서 접속을 받을지 결정하는 중요한 설정이다.
마지막으로 MySQL을 실제로 사용하려면 다음 명령어를 입력한다.
sudo mysql
사진에서는 “시작”이라고 되어 있지만, 여기서는 MySQL 프로그램을 실행해서 사용하는 의미에 가깝다.
Additional Notes (추가 설명)
mysql-server는 MySQL 데이터베이스 서버(Database Server)를 설치하는 패키지이다.
systemctl restart mysql.service는 MySQL 서버를 재시작해서 설정 변경을 적용할 때 사용한다.
journalctl -u mysql은 MySQL 서비스의 로그(Log)를 확인하는 명령어이다. 오류가 났을 때 가장 먼저 확인해볼 수 있다.
PHP Script in LAMP (LAMP에서 PHP 스크립트)
PHP(PHP Script)는 LAMP(Linux, Apache, MySQL, PHP) 구성에서 동적인 웹 페이지(Dynamic Web Page)를 처리하는 역할을 한다. PHP는 단독으로 사용하기보다는 웹 서버(Web Server)인 Apache와 DB 서버(Database Server)인 MySQL이 함께 설치되어 있어야 PHP가 웹 서비스 안에서 의미 있게 사용될 수 있다.
사진에 나온 설치 명령어는 다음과 같다.
sudo apt install php libapache2-mod-php php-cli php-cgi php-mysql
여기서 libapache2-mod-php는 Apache가 PHP 코드를 실행할 수 있게 해주는 모듈(Module)이고, php-mysql은 PHP가 MySQL과 연결할 수 있게 해주는 패키지이다. 즉 PHP는 단독 프로그램이라기보다 Apache와 MySQL 사이에서 웹 요청을 처리하고 데이터베이스와 연결해 주는 역할을 한다.
PHP 설정을 변경한 뒤에는 Apache를 재시작한다.
sudo systemctl restart apache2.service
이는 PHP가 Apache 웹 서버 안에서 동작하기 때문이다. PHP 설정을 바꿨는데 Apache를 재시작하지 않으면 변경 내용이 바로 적용되지 않을 수 있다.
주요 설정 파일은 다음과 같다.
/etc/php/8.3/cli/php.ini
/etc/php/8.3/apache2/php.ini
여기서 8.3은 PHP version(PHP 버전)이므로 사용자 환경에 따라 다를 수 있다. Ubuntu(우분투)를 기준으로 한 경로이기 때문에, 다른 Linux distribution(리눅스 배포판)에서는 설치 명령어나 설정 파일 위치가 달라질 수 있다.
Additional Notes (추가 설명)
php-cli는 터미널(Command Line)에서 PHP를 실행할 때 사용한다.
php-cgi는 웹 서버와 PHP가 CGI 방식으로 연동될 때 사용될 수 있다.
Linux kernel(리눅스 커널)의 기본은 같지만, Ubuntu, CentOS, Fedora 같은 distribution(배포판)에 따라 패키지 관리자, 명령어, 설정 파일 위치가 달라질 수 있으므로 실습 환경이 Ubuntu인지 항상 확인하는 것이 좋다.
Viewing Image Files in Linux (리눅스에서 그림 파일 보기)
리눅스 서버(Linux Server)는 보통 GUI(Graphical User Interface)가 없는 최소 환경으로 설치되기 때문에, 그림 파일(Image File)을 바로 창으로 열어보기 어렵다. 서버는 사용자의 화면 반응성보다 서비스 실행과 관리에 초점을 두기 때문에, Windows처럼 익숙한 화면 환경이 기본으로 제공되지 않는 경우가 많다.
그림 파일을 확인하는 방법은 여러 가지가 있다. 가장 기본적인 방법은 터미널(Terminal)에서 파일 목록을 확인하는 것이다. 하지만 이미지 내용을 직접 보려면 다른 방법이 필요하다.
첫 번째 방법은 Window Manager(윈도우 매니저)를 설치하는 것이다. Window Manager는 X Window System(X 윈도우 시스템)에서 창을 띄우고 관리하는 프로그램이다. 이것을 사용하면 원격 Linux 환경에서도 GUI처럼 그림 파일을 볼 수 있다. 다만 서버 환경에서는 꼭 필요한 경우가 아니면 잘 사용하지 않는다.
두 번째 방법은 sshFS(SSH File System)를 사용하는 것이다. 원격 서버의 디렉토리를 내 컴퓨터에 연결하면, 서버에 있는 이미지 파일을 내 컴퓨터의 파일 탐색기(File Explorer)에서 보는 것처럼 열 수 있다.
세 번째 방법은 Python SimpleHTTPServer를 사용하는 것이다. 서버에 Python이 설치되어 있다면 Apache(Apache Web Server)를 따로 설치하지 않아도 간단한 웹 서버(Web Server)를 실행할 수 있다.
python -m SimpleHTTPServer 포트번호
또는 Python 3에서는 보통 다음 명령어를 사용한다.
python3 -m http.server 포트번호
이렇게 실행하면 웹 브라우저(Web Browser)를 통해 해당 디렉토리의 파일 목록을 볼 수 있고, 이미지 파일도 클릭해서 확인할 수 있다.
Additional Notes (추가 설명)
Window Manager(윈도우 매니저)는 GUI 창을 띄우고 관리하는 프로그램이다.
sshFS는 원격 서버의 파일을 내 컴퓨터 폴더처럼 연결해서 보는 방식이다.
Python SimpleHTTPServer는 간단히 임시 웹 서버를 열어 파일을 확인할 때 유용하다.
핵심은 Linux 서버에서는 그림 파일을 바로 보는 환경이 기본이 아니기 때문에, Window Manager, sshFS, Python 웹 서버 같은 방법을 이용해 확인할 수 있다는 점이다.
Apache Home Directory (Apache 홈 디렉토리)
Apache(Apache Web Server)를 설치하면 웹 페이지 파일들이 저장되는 기본 홈 디렉토리(Home Directory)가 정해져 있다. Ubuntu 기준으로 Apache의 기본 웹 문서 디렉토리는 다음 위치이다.
/var/www/html
이 디렉토리 안에 있는 파일들이 웹 브라우저를 통해 사용자에게 보여진다. 예를 들어 기본 페이지는 보통 다음 파일이다.
/var/www/html/index.html
사용자가 새로 my.html 같은 파일을 만들면 다음과 같은 경로에 위치할 수 있다.
/var/www/html/my.html
그리고 웹 브라우저에서 서버의 IP 주소나 도메인으로 접속하면 Apache가 이 디렉토리 안의 파일을 찾아서 보여준다.
Apache Default Site Configuration (Apache 기본 사이트 설정)
사진에 나온 설정 파일은 Apache의 기본 사이트 설정 파일이다.
/etc/apache2/sites-enabled/000-default.conf
이 파일 안에는 Apache가 어떤 디렉토리를 웹 페이지의 기준 위치로 사용할지 설정되어 있다. 사진에서 중요한 부분은 다음 줄이다.
DocumentRoot /var/www/html
DocumentRoot는 웹 서버가 사용자에게 보여줄 파일들이 있는 최상위 디렉토리(Root Directory)를 의미한다. 즉 현재 설정에서는 /var/www/html 안에 있는 파일들이 웹 서비스의 기본 파일로 사용된다.
Web Hosting and Multiple Sites (웹 호스팅과 여러 사이트 운영)
기본적으로 Apache를 처음 설치하면 하나의 기본 사이트가 /var/www/html을 기준으로 동작한다. 그래서 처음에는 “서버 한 대당 홈페이지 하나만 운영할 수 있나?”라고 생각할 수 있다.
하지만 실제 웹 호스팅(Web Hosting) 회사들은 서버 한 대에서 여러 개의 홈페이지를 운영하기도 한다. 이때는 Apache의 Virtual Host(가상 호스트) 설정을 사용해서 사이트마다 다른 디렉토리와 도메인을 연결한다. 예를 들어 하나의 서버 안에서도 A 사이트는 /var/www/siteA, B 사이트는 /var/www/siteB처럼 나누어 운영할 수 있다.
Additional Notes (추가 설명)
/var/www/html은 Apache의 기본 웹 페이지 파일 위치이다.
DocumentRoot는 웹 서버가 실제로 파일을 찾아서 보여주는 기준 디렉토리이다.
000-default.conf는 Apache의 기본 사이트 설정 파일이다.
Linux에서 서버를 관리하려면 이런 경로를 직접 찾아가고, 설정 파일을 확인하고, 필요한 파일을 수정하는 연습이 중요하다.
실습화면
가상머신안에 Apache2를 설치하였다. Apache를 설치하면 보통 자동으로 /var/www/html 디렉토리가 생성된다. index.html은 Apache 웹 서버(Apache Web Server)가 기본으로 보여주는 첫 번째 웹페이지 파일이다. 즉 브라우저에서 서버 IP 주소로 접속했을 때:
http://서버IP주소
Apache는 자동으로 /var/www/html/index.html 파일을 찾아서 보여줍니다.
예를 들어 index.html 안에 이런 내용이 있으면:
Hello Apache
브라우저에서 서버 IP로 접속했을 때 Hello Apache가 보이게 됩니다.
정리하면:
/var/www/html → 웹사이트 파일들이 들어가는 기본 폴더
index.html → 웹사이트 첫 화면 파일
DocumentRoot → Apache가 웹 파일을 찾는 기준 위치
그래서 index.html은 “홈페이지의 메인 페이지”라고 이해하면 된다. 블로그로 비유하면, 사용자가 주소만 입력했을 때 가장 먼저 보이는 첫 화면이 된다. cat index.html을 했을 때 <html>, <head>, <body>, <div> 같은 <> 태그가 많이 보이는 이유는 index.html이 HTML 파일이기 때문이다.
HTML File (HTML 파일)
index.html은 웹 브라우저가 읽는 문서 파일이다. 사람이 보기에는 태그가 잔뜩 있는 코드처럼 보이지만, 브라우저는 이 태그들을 해석해서 우리가 보는 웹페이지 화면으로 보여준다.
예를 들어 파일 안에 이런 내용이 있으면:
<h1>Hello Apache</h1>
<p>This is my first web page.</p>
터미널에서 cat index.html을 하면 태그까지 그대로 보인다.
<h1>Hello Apache</h1>
<p>This is my first web page.</p>
하지만 브라우저에서 접속하면 태그는 보이지 않고 이렇게 보인다.
Hello Apache
This is my first web page.
Apache Default Page (Apache 기본 페이지)
Apache를 설치하면 기본으로 만들어지는 index.html에는 “Apache2 Ubuntu Default Page” 같은 안내 페이지 코드가 들어 있다. 그래서 cat index.html을 하면 태그가 아주 많이 보이는 것이 정상이다.
위의 연습은 DocumentRoot /var/www/html2 를 이용해서 html2 를 따로 만들어서 Hello html2 문구를 넣어보았다.
User-Specific Home Directory in Apache (Apache 사용자별 홈 디렉토리)
Apache의 userdir 기능은 “각 사용자 계정마다 자기 홈페이지 폴더를 하나씩 가질 수 있게 해주는 기능”이다. Apache(Apache Web Server)는 기본적으로 /var/www/html을 홈 디렉토리(DocumentRoot)로 사용한다. 이 위치에 index.html 같은 파일을 두면 웹 브라우저에서 서버 주소로 접속했을 때 해당 파일이 보인다.
/var/www/html
하지만 아래처럼 서버에 여러 사용자 계정(User Account)이 있을 경우를 생각해보자
/home/heesunoh
/home/mis
/home/student1
각 사용자마다 자기 홈페이지를 만들게 하고 싶다면, 모든 사람이 /var/www/html을 같이 쓰는 것보다 자기 홈 디렉토리 안에 홈페이지 폴더를 따로 갖는 것이 편하다. 그래서 Apache는 이렇게 정한다.
각 사용자 홈 디렉토리 안의 public_html 폴더를 홈페이지 폴더로 쓰자.
예를 들어 사용자 이름이 heesunoh라면 다음 위치가 사용자 홈페이지 디렉토리가 될 수 있다. 이 폴더가 heesunoh 사용자의 개인 홈페이지 공간이 되는것이다.
/home/heesunoh/public_html
이 안에 index.html 파일을 아래처럼 만들면 웹에서 접속할 수 있다.
/home/heesunoh/public_html/index.html
그리고 웹에서는 아래처럼 볼 수 있게 하는 기능이다.
http://서버IP/~heesunoh/index.html
그런데 Apache는 처음부터 이 기능을 켜두지 않는다. 그래서 userdir 모듈을 활성화해야 한다. 이때 사용하는 것이 userdir 모듈(Module)이다. userdir을 사용하면 각 사용자의 홈 디렉토리(Home Directory) 안에 있는 public_html 디렉토리를 웹 페이지 공간으로 사용할 수 있다. 관련 설정 파일은 다음 위치에 있다.
/etc/apache2/mods-available/userdir.conf
사진 속 설정의 의미는 다음과 같다. 이는 각 사용자의 홈 디렉토리 아래 public_html을 웹 디렉토리로 사용하겠다는 의미이다.
UserDir public_html
이 기능을 사용하려면 userdir 모듈을 활성화해야 한다.
/etc/apache2/sites-enabled/000-default.conf
→ 서버의 기본 홈페이지 설정
→ DocumentRoot /var/www/html
/etc/apache2/mods-available/userdir.conf
→ 사용자별 홈페이지 설정
→ /home/사용자/public_html
root 계정은 이 기능을 사용하지 못하게 막겠다는 뜻이다. 보안상 root의 개인 홈페이지를 열어두지 않는 것이다.
<Directory /home/*/public_html>
/home/사용자이름/public_html 형태의 모든 사용자 디렉토리에 적용되는 설정이다. 여기서 *는 모든 사용자 이름을 의미한다.
sudo a2enmod userdir
sudo systemctl restart apache2.service
Additional Notes (추가 설명)
/var/www/html은 서버 전체의 기본 홈페이지 디렉토리이다.
/home/사용자이름/public_html은 사용자별 홈페이지 디렉토리이다.
userdir 모듈을 활성화하면 여러 사용자가 각자 자신의 홈 디렉토리 안에 홈페이지 파일을 둘 수 있다.
정리하면, 기본 Apache 홈페이지는 /var/www/html에 있고, 사용자별 홈페이지는 userdir 설정을 통해 /home/사용자/public_html에서 제공할 수 있다.ㅇ
실습결과 1; /etc/apache2/mods-available/userdir.conf 파일의 실제 내용을 확인했다.
실습결과 2; Apache가 현재 기본 DocumentRoot로 설정된 html2안의 index.html파일을 잘 읽어서 응답함을 확인했다.
User-Specific Home Directory with userdir (userdir를 이용한 사용자별 홈 디렉토리)
이전 실습에서는 Apache의 기본 홈페이지 위치를 배웠다면 지금 실습하려는 부분은 방금 배운 내용을 “실제로 켜고 테스트하는 단계”이다.
Apache(Apache Web Server)는 기본적으로 /var/www/html을 웹 서비스의 기본 홈 디렉토리(DocumentRoot)로 사용한다. 하지만 서버에 여러 사용자 계정(User Account)이 있을 경우, 각 사용자마다 개인 홈페이지를 제공할 수도 있다. 이때 사용하는 기능이 userdir 모듈(Module)이다. 그런데 이건 아직 “기능이 준비되어 있다”는 뜻이지, 실제로 작동한다는 뜻은 아니다. 그래서 이번 실습에서는 이 기능을 실제로 활성화하고, 내 계정 안에 public_html 폴더를 만들어서 웹페이지가 보이는지 확인하는 단계이다. userdir을 활성화하려면 다음 명령어를 사용한다.
sudo a2enmod userdir
sudo systemctl restart apache2
이 명령어는 /etc/apache2/mods-available/userdir.conf에 있는 사용 가능한 모듈 설정을 /etc/apache2/mods-enabled/ 쪽으로 활성화하는 역할을 한다. Apache에서 userdir 기능을 켜는 명령어이고 즉 ~사용자이름 주소로 사용자별 홈페이지에 접근할 수 있게 한다. 명령어 실행 후에는 Apache가 친절하게 재시작이 필요하다고 알려준다. 여기까지 Apache에서 사용자별 홈페이지 기능(userdir)을 켠 상태가 되었다.
userdir 설정이 활성화되면 각 사용자의 홈 디렉토리(Home Directory) 안에 있는 public_html 디렉토리가 개인 홈페이지 공간으로 사용된다. 예를 들어 사용자 계정이 heesunoh라면 다음 위치에 홈페이지 파일을 만들 수 있다.
/home/heesunoh/public_html/index.html
그리고 웹에서 접속할 때는 보통 다음과 같이 사용자 이름 앞에 물결표시(~)를 붙인다.
http://서버IP주소/~heesunoh/
사진 속 설정 파일에서도 중요한 부분은 다음 내용이다.
UserDir public_html <Directory /home/*/public_html>
UserDir public_html은 각 사용자의 홈 디렉토리 아래 public_html 폴더를 웹 디렉토리로 사용하겠다는 뜻이다. /home/*/public_html에서 *는 여러 사용자 계정을 의미한다. 즉 /home/user1/public_html, /home/user2/public_html처럼 사용자마다 다른 홈페이지 디렉토리를 가질 수 있다.
Additional Notes (추가 설명)
/var/www/html은 서버 전체의 기본 홈페이지 위치이고, /home/사용자명/public_html은 사용자별 홈페이지 위치이다.
가끔 오래된 홈페이지 주소에서 ~username 형태를 볼 수 있는데, 이는 Apache의 userdir 기능을 사용한 사용자별 홈페이지 방식일 가능성이 높다.
실습할 때는 public_html 디렉토리를 직접 만들어야 한다.
mkdir ~/public_html
echo "<h1>My Homepage</h1>" > ~/public_html/index.html
실습결과
주소는 맞게 찾았는데, Apache가 그 파일/폴더에 접근할 권한이 없다”는 뜻이 확인되었다. 권한 설정이 아직 부족한 상태로 다음 슬라이드에서 권한 설정을 세팅할것이다.
User-Specific Directory Permissions (사용자별 디렉토리 권한)
Apache의 userdir 기능을 사용하면 각 사용자의 홈 디렉토리(Home Directory) 안에 public_html 디렉토리를 만들어 개인 홈페이지를 제공할 수 있다. 예를 들어 사용자 계정이 mis라면 웹 파일은 다음 위치에 둘 수 있다.
/home/mis/public_html/index.html
이때 중요한 것은 permission(권한)이다. Apache가 웹 페이지 파일에 도착하려면 중간 경로인 /home/mis와 ~/public_html 디렉토리를 통과할 수 있어야 한다. 그래서 디렉토리에는 execution permission(실행 권한)이 필요하다.
chmod 711 /home/$USER
mkdir ~/public_html
chmod 711 ~/public_html
여기서 711은 소유자(owner)는 rwx, 그룹(group)과 기타 사용자(others)는 x 권한만 가진다는 뜻이다. 디렉토리에서 x 권한은 “실행”이라기보다 그 디렉토리를 통과하거나 접근할 수 있는 권한으로 이해하면 된다. 즉 다른 사용자가 내 홈 디렉토리의 파일 목록을 읽을 수는 없지만, 정확한 경로를 알고 있으면 public_html 안의 웹 파일까지 접근할 수 있게 된다.
웹 페이지 파일 자체는 읽기 권한(read permission)이 있어야 한다. 그래서 index.html에는 다음처럼 읽기 권한을 준다.
chmod 744 ~/public_html/index.html
744는 소유자는 읽기, 쓰기, 실행이 가능하고, 그룹과 기타 사용자는 읽기만 가능하다는 뜻이다. 웹 브라우저로 접속하는 외부 사용자는 이 파일을 수정할 필요는 없고 읽기만 하면 되므로 read permission(읽기 권한)이 필요하다.
접속 주소는 보통 다음과 같은 형태가 된다.
http://서버IP주소/~사용자이름/index.html
예를 들어 사용자 이름이 mis라면 다음처럼 접속할 수 있다.
http://10.211.55.9/~mis/index.html
Additional Notes (추가 설명)
디렉토리의 x 권한은 해당 디렉토리를 “통과”할 수 있는 권한이다. 파일의 x 권한처럼 프로그램 실행만 의미하는 것이 아니다.
711은 다른 사용자가 디렉토리 목록을 볼 수는 없지만, 정확한 파일 경로를 알면 접근할 수 있게 하는 설정이다.
744는 웹 페이지 파일을 외부에서 읽을 수 있게 하기 위한 권한 설정이다. Apache가 index.html을 읽을 수 있어야 웹페이지가 정상적으로 보인다.
실습결과
권한을 부여했고 정상적으로 확인할 수 있었다.
User Directory Without Tilde Using mod_rewrite (mod_rewrite를 이용한 물결표 없는 사용자 디렉토리 접속)
Apache(Apache Web Server)의 userdir 기능을 사용하면 사용자별 홈페이지에 보통 다음과 같이 접속한다.
http://서버IP/~사용자이름/
여기서 ~사용자이름 형태는 오래된 방식의 개인 홈페이지 주소에서 자주 볼 수 있다. 하지만 이 방식은 서버에 어떤 사용자 계정(User Account)이 존재하는지 외부에 드러낼 수 있다는 단점이 있다. 사용자 이름이 노출되면, 해당 계정을 대상으로 비밀번호 추측 공격이나 피싱(Phishing) 시도가 이루어질 가능성이 있다.
이를 줄이기 위해 mod_rewrite 모듈(Module)을 사용할 수 있다. mod_rewrite는 사용자가 입력한 URL을 Apache 내부에서 다른 경로로 바꿔서 처리하게 해주는 기능이다. 먼저 다음 명령어로 rewrite 모듈을 활성화한다.
sudo a2enmod rewrite
활성화 후에는 Apache를 재시작해야 적용된다.
sudo systemctl restart apache2
그다음 Apache 설정 파일에 rewrite 규칙을 추가한다.
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/([^/]+)
RewriteCond /home/%1/public_html -d RewriteRule ^/([^/]+)(.*) /home/\(1/public_html\)2 [L]
이 설정을 적용하면 기존처럼 ~를 붙이지 않고도 사용자 홈페이지에 접속할 수 있다.
기존 방식: http://서버IP/~mis/index.html
변경 후: http://서버IP/mis/index.html
즉 사용자가 /mis/index.html로 접속하면 Apache가 내부적으로 /home/mis/public_html/index.html을 찾아서 보여주는 방식이다.
Additional Notes (추가 설명)
mod_rewrite는 URL Rewrite(URL 재작성)를 담당하는 Apache 모듈이다.
RewriteEngine On은 rewrite 기능을 켜는 설정이다.
RewriteRule은 사용자가 입력한 주소를 실제 서버 내부 경로로 바꿔주는 규칙이다.
핵심은 ~username 형태를 직접 보여주지 않고도, 사용자별 public_html 디렉토리에 있는 홈페이지를 접속할 수 있게 만드는 것이다.
실습 결과
Apache 설정안에 Rewrite를 설정하였다.
수정된 내용을 업데이트하고 curl을 이용해 제대로 적용되었는지 확인하였다.
User Directory Access Without Tilde (물결표 없이 사용자 디렉토리 접속하기)
Apache(Apache Web Server)의 userdir 기능을 사용하면 사용자별 홈페이지에 보통 다음과 같이 접속한다.
http://서버IP/~사용자이름/index.html
예를 들어 사진의 첫 번째 화면처럼 다음 주소로 접속하면 사용자 mis의 public_html 디렉토리에 있는 index.html 파일을 볼 수 있다.
http://10.211.55.9/~mis/index.html
그런데 앞에서 설정한 mod_rewrite를 적용하면 ~ 없이도 같은 사용자 홈페이지에 접속할 수 있다.
http://10.211.55.9/mis/index.html
사진의 두 번째 화면이 바로 이 결과이다. 주소에는 ~가 없지만, 실제로는 Apache가 내부적으로 /home/mis/public_html/index.html 파일을 찾아서 보여준다.
즉 두 주소는 겉으로 보이는 URL(URL 주소)은 다르지만, 최종적으로 접근하는 파일은 같은 파일이다.
~ 있는 방식:
http://10.211.55.9/~mis/index.html
~ 없는 방식:
http://10.211.55.9/mis/index.html
실습에서 no ~라는 문구를 추가한 이유는 rewrite 설정이 제대로 적용되었는지 확인하기 위해서이다. 원래 같은 index.html 파일을 보여주지만, 파일 내용을 조금 바꿔서 새 주소 방식도 정상적으로 적용되었는지 확인한 것이다.
Additional Notes (추가 설명)
~username 방식은 Apache의 userdir 기능에서 사용하는 오래된 사용자별 홈페이지 주소 방식이다.
mod_rewrite를 사용하면 사용자가 입력한 주소를 서버 내부의 실제 파일 경로로 바꿔서 처리할 수 있다.
핵심은 ~mis/index.html과 /mis/index.html이 겉으로는 다른 주소처럼 보이지만, 설정 후에는 같은 사용자 홈페이지 파일을 보여줄 수 있다는 점이다.
실습결과
물결 표시가 있게/ 없게 가능한지 확인하였고 정상적으로 작동하였다.
Name-Based Virtual Hosting (이름 기반 가상 호스팅)
Apache(Apache Web Server)에서는 하나의 서버(Host Server) 안에서 여러 개의 웹 사이트(Web Site)를 운영할 수 있다. 이를 Virtual Host(가상 호스트)라고 한다. 사진에서는 Apache 공식 문서의 Virtual Host 예제를 참고하라고 안내하고 있다.
여기서 중요한 개념은 domain name(도메인 이름)이다. 예를 들어 하나의 서버가 1.1.1.1이라는 IP 주소(IP Address)를 가지고 있고, koreacu.ac.kr과 다른 옛날 홈페이지 주소가 모두 같은 내용을 보여줘도 된다면, 두 domain name이 같은 IP를 가리키게 하면 된다. 이 경우 웹 서버 입장에서는 같은 서버로 접속하는 것이므로 비교적 단순하다.
하지만 domain name마다 서로 다른 내용을 보여줘야 한다면 설정이 달라진다. 예를 들어 siteA.com은 A 홈페이지 파일을 보여주고, siteB.com은 B 홈페이지 파일을 보여줘야 한다면 Apache에서 Virtual Host(가상 호스트)를 설정해야 한다. 그러면 하나의 Apache 서버 안에서도 domain name에 따라 서로 다른 DocumentRoot(문서 루트)를 사용할 수 있다.
예를 들면 다음과 같은 방식이다.
siteA.com → /var/www/siteA
siteB.com → /var/www/siteB
즉 서버는 하나지만, 접속한 이름(domain name)에 따라 다른 웹 페이지 디렉토리를 보여줄 수 있다. 웹호스팅(Web Hosting) 회사들이 하나의 서버에서 여러 홈페이지를 운영할 수 있는 이유도 이런 방식과 관련이 있다.
Additional Notes (추가 설명)
domain name(도메인 이름)은 사람이 기억하기 쉬운 웹사이트 주소이고, 실제 접속은 IP Address(IP 주소)를 통해 이루어진다.
같은 내용을 보여줄 경우에는 여러 domain name이 같은 IP를 가리키게 하면 된다.
서로 다른 내용을 보여줄 경우에는 Apache의 Virtual Host(가상 호스트) 설정을 사용해 domain name별로 다른 DocumentRoot를 지정할 수 있다.
IP-Based Virtual Hosting (IP 주소 기반 가상 호스팅)
Apache(Apache Web Server)에서는 하나의 서버에서 여러 웹 사이트(Web Site)를 운영할 수 있다. 앞에서는 domain name(도메인 이름)을 기준으로 서로 다른 사이트를 구분하는 방법을 배웠고, 이번에는 IP address(IP 주소)를 기준으로 구분하는 방법이다.
예를 들어 하나의 서버에서 다음처럼 서로 다른 IP 주소로 접속했을 때 다른 웹사이트를 보여줄 수 있다.
10.211.55.9 → 첫 번째 웹사이트
10.211.55.100 → 두 번째 웹사이트
처음에는 “컴퓨터 한 대에는 IP 주소가 하나만 있는 것 아닌가?”라고 생각할 수 있다. 과거에는 물리적인 컴퓨터를 여러 대 준비해야 하는 경우가 많았지만, 현재는 하나의 머신(Machine) 안에서도 여러 IP 주소를 설정하거나, VM(Virtual Machine), 네트워크 설정, 가상화 기술을 통해 여러 주소를 서비스할 수 있다.
즉 IP-Based Virtual Hosting(IP 주소 기반 가상 호스팅)은 하나의 Apache 서버가 여러 IP 주소를 받아들이고, 접속한 IP 주소에 따라 다른 DocumentRoot(문서 루트)를 보여주는 방식이다.
예를 들면 다음과 같이 설정할 수 있다.
10.211.55.9 → /var/www/site1
10.211.55.100 → /var/www/site2
이렇게 하면 같은 Apache 서버를 사용하더라도 접속한 IP 주소에 따라 서로 다른 웹 페이지를 제공할 수 있다.
Additional Notes (추가 설명)
Virtual Host(가상 호스트)는 하나의 서버에서 여러 웹사이트를 운영하기 위한 Apache 기능이다.
Name-Based Virtual Host(이름 기반 가상 호스트)는 domain name(도메인 이름)으로 사이트를 구분한다.
IP-Based Virtual Host(IP 기반 가상 호스트)는 IP address(IP 주소)로 사이트를 구분한다.
실제 설정 방법은 Apache 공식 문서의 Virtual Host 예제를 참고하면 된다. 강의에서는 “하나의 서버에서도 여러 IP 주소나 여러 사이트를 서비스할 수 있다”는 개념을 이해하는 것이 핵심이다.
Port-Based Virtual Hosting (포트 기반 가상 호스팅)
Apache(Apache Web Server)는 하나의 서버에서 여러 웹사이트를 운영할 수 있다. 앞에서는 domain name(도메인 이름)이나 IP address(IP 주소)를 기준으로 웹사이트를 나누는 방법을 배웠고, 이번에는 port number(포트 번호)를 기준으로 나누는 방법이다.
기본적으로 웹 서버는 HTTP 요청을 받을 때 80번 포트(Port 80)를 사용한다. 그래서 사용자가 아래처럼 접속하면 사실은 80번 포트로 접속하는 것이다.
http://10.211.55.9
이는 실제로는 다음과 같은 의미이다.
http://10.211.55.9:80
하지만 다른 포트를 사용하면 같은 IP 주소에서도 다른 웹사이트를 운영할 수 있다. 예를 들어 9999번 포트를 사용하면 다음처럼 접속할 수 있다.
http://10.211.55.9:9999
이 경우 기존의 /var/www/html은 80번 포트용 홈 디렉토리(DocumentRoot)로 사용하고, 새로 만든 /var/www/port9999는 9999번 포트용 홈 디렉토리로 사용할 수 있다.
sudo mkdir /var/www/port9999/
그리고 이 디렉토리의 소유자를 현재 사용자로 바꾸면 매번 root 권한 없이 파일을 만들고 수정할 수 있다.
sudo chown \(USER:\)USER /var/www/port9999/
새로운 포트용 설정 파일(Configuration File)은 처음부터 만들기보다 기존 Apache 기본 설정 파일을 복사해서 사용하는 것이 편리하다.
sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/port9999.conf
이후 port9999.conf에서 VirtualHost의 포트 번호와 DocumentRoot를 9999번 포트용으로 수정하면 된다.
Additional Notes (추가 설명)
port(포트)는 같은 IP 주소 안에서 서비스를 구분하는 번호이다.
80번 포트는 기본 웹 서비스(HTTP)에 사용된다.
9999번처럼 다른 포트를 사용하면 같은 서버와 같은 IP 주소에서도 다른 웹사이트를 운영할 수 있다.
핵심은 IP 주소나 도메인을 새로 사지 않아도, 포트 번호를 다르게 해서 별도의 웹 서비스 공간을 만들 수 있다는 점이다.
Port-Based VirtualHost Configuration (포트 기반 VirtualHost 설정)
Apache(Apache Web Server)에서 다른 포트 번호(Port Number)를 사용하려면, 기존 설정 파일을 복사해서 새로운 설정 파일을 만들 수 있다. 예를 들어 9999번 포트용 웹사이트를 만들려면 다음처럼 새 디렉토리를 만든다.
sudo mkdir /var/www/port9999/
그리고 해당 디렉토리의 소유자를 현재 사용자로 바꾸면, 매번 sudo를 쓰지 않고도 파일을 만들거나 수정할 수 있다.
sudo chown \(USER:\)USER /var/www/port9999/
그다음 기존 Apache 기본 설정 파일을 복사해서 9999번 포트용 설정 파일을 만든다.
sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/port9999.conf
복사한 port9999.conf 파일에서는 두 부분을 수정한다. 첫 번째는 VirtualHost의 포트 번호이고, 두 번째는 DocumentRoot이다.
<VirtualHost *:9999>
DocumentRoot /var/www/port9999
</VirtualHost>
<VirtualHost *:9999>는 9999번 포트로 들어오는 요청을 이 설정에서 처리하겠다는 뜻이다. DocumentRoot /var/www/port9999는 9999번 포트로 접속했을 때 보여줄 웹 파일의 위치를 의미한다.
Additional Notes (추가 설명)
기본 웹사이트는 보통 80번 포트와 /var/www/html을 사용한다.
http://서버IP
→ /var/www/html
9999번 포트를 추가하면 같은 서버에서도 다른 웹사이트처럼 사용할 수 있다.
http://서버IP:9999
→ /var/www/port9999
즉 포트 번호(Port Number)를 다르게 하면 하나의 서버에서 여러 웹사이트를 구분해서 운영할 수 있다.
실습결과
기존 기본 사이트 설정 파일을 복사해서 port9998.conf를 만들고, VirtualHost 포트를 9998로 바꿨다. 그리고 DocumentRoot를 /var/www/port9998로 지정하였다.
Apache Listen Port Configuration (Apache 포트 수신 설정)
Port-Based Virtual Hosting(포트 기반 가상 호스팅)을 사용하려면 VirtualHost 설정만 바꾸는 것으로 끝나지 않는다. Apache가 해당 포트로 들어오는 요청을 받을 수 있도록 ports.conf에도 포트를 추가해야 한다.
Apache의 포트 설정 파일은 다음 위치에 있다.
sudo vi /etc/apache2/ports.conf
기본적으로 Apache는 80번 포트(Port 80)를 사용한다.
Listen 80
여기에 9999번 포트로도 웹 요청을 받게 하려면 다음 줄을 추가한다.
Listen 9999
즉 설정 파일에는 다음과 같이 들어갈 수 있다.
Listen 80
Listen 9999
이렇게 해야 Apache가 80번 포트뿐만 아니라 9999번 포트에서도 요청을 기다리게 된다. 그리고 앞에서 만든 port9999.conf에서는 9999번 포트로 들어온 요청이 /var/www/port9999 디렉토리를 보도록 설정한다.
<VirtualHost *:9999>
DocumentRoot /var/www/port9999
</VirtualHost>
설정을 바꾼 뒤에는 Apache를 재시작해야 적용된다.
sudo systemctl restart apache2
Additional Notes (추가 설명)
ports.conf의 Listen 9999는 “Apache가 9999번 포트에서 요청을 받을 준비를 하겠다”는 뜻이다.
port9999.conf의 <VirtualHost *:9999>는 “9999번 포트로 들어온 요청을 어떤 웹사이트 설정으로 처리할지” 정하는 부분이다.
즉 9999번 포트 웹사이트를 만들려면 두 가지가 필요하다.
ports.conf에 Listen 9999 추가
port9999.conf에 <VirtualHost *:9999> 설정
실습결과
Apache가 9999번 포트 요청을 받을 수 있도록 ports.conf에 Listen 9999를 추가하였다. 마지막으로 새 사이트 설정을 활성화하고 Apache를 재시작하였다. curl http://localhost:9998 확인하면 9998번 포트용 웹페이지가 출력된것을 확인했다.
Port-Based Site Enable and Restart (포트 기반 사이트 활성화와 재시작)
Apache(Apache Web Server)에서 9999번 포트용 웹사이트를 만들려면, 앞에서 만든 설정 파일 port9999.conf를 활성화해야 한다. 설정 파일을 만들기만 하면 Apache가 바로 사용하는 것이 아니라, sites-enabled에 연결되어야 실제 적용된다. 사이트 활성화 명령어는 다음과 같다.
sudo a2ensite port9999.conf
이 명령어를 실행하면 Apache가 port9999.conf 사이트 설정을 사용할 수 있게 된다. 실행 결과로 “새 설정을 적용하려면 Apache를 reload 또는 restart 하라”는 안내가 나온다.
그다음 Apache 서비스를 다시 시작한다.
sudo systemctl restart apache2
이제 웹 브라우저에서 다음 주소로 접속하면 9999번 포트용 웹페이지가 보인다.
http://10.211.55.9:9999
기본 웹사이트는 80번 포트를 사용하므로 다음처럼 접속한다.
http://10.211.55.9
반면 9999번 포트 웹사이트는 주소 뒤에 :9999를 붙여야 한다.
http://10.211.55.9:9999
즉 같은 IP 주소(IP Address)를 사용하더라도 포트 번호(Port Number)를 다르게 하면 서로 다른 웹사이트처럼 운영할 수 있다.
Additional Notes (추가 설명)
a2ensite는 Apache 사이트 설정(Site Configuration)을 활성화하는 명령어이다.
port9999.conf는 9999번 포트로 들어오는 요청을 처리하기 위한 설정 파일이다.
9999번 포트를 사용하려면 다음 세 가지가 모두 필요하다.
/etc/apache2/ports.conf 에 Listen 9999 추가
/etc/apache2/sites-available/port9999.conf 설정
sudo a2ensite port9999.conf 후 Apache 재시작
