설치

• 공식 웹사이트: Windows Terminal – Microsoft Apps에서 설치 파일을 다운로드한다.
• Microsoft Store: 윈도우 운영체제에 내장된 Microsoft Store 프로그램을 실행한 후 ‘Windows Terminal’을 검색하여 설치할 수도 있다.

설정 열기

윈도우 터미널에서 Ctrl + , 키를 누르면 설정 화면이 나타난다. 이전 버전에서는 settings.json 파일이 직접 열렸으나, 현재는 GUI 기반의 설정 페이지가 기본으로 열린다. 단축키 대신 상단 탭의 드롭다운 아이콘을 클릭한 후 [설정] 메뉴를 선택해도 동일하다.

프로필 추가하기

좌측 메뉴 하단의 [새 프로필 추가]를 클릭하여 프로필을 추가할 수 있다.

이름과 명령줄, 이 두 가지 항목이 접속을 위한 최소한의 필수 설정이다. 설정을 마친 후에는 우측 하단의 저장 버튼을 반드시 클릭해야 적용된다.

프로필 연결 예제 (카페24 SSH)

몇 년 전 워드프레스 서버를 이전하면서 도메인을 bitneer.info에서 bitneer.dev로 변경하고, 집 서버에서 AWS Lightsail을 거쳐 최종적으로 카페24의 뉴매니지드 워드프레스 호스팅으로 옮겼다. 여기서는 카페24 서버에 접속하는 프로필 설정 예시를 소개한다.

1. 사전 준비

• 윈도우에 OpenSSH 클라이언트가 설치되어 있어야 한다.
• ssh-copy-id 명령어를 사용하기 위해 리눅스용 OpenSSH 클라이언트가 필요하다. 이 글에서는 WSL(Windows Subsystem for Linux)의 Debian 환경에 openssh-client 패키지를 설치하여 진행한다.
• WSL을 사용하지 않는다면, 이전 글의 ‘암호를 입력하지 않고 SSH 사용하기’ 부분을 참고하여 수동으로 키를 등록해야 한다.

2. SSH 키 생성

SSH 키를 만든 적이 없다면 PowerShell에서 다음 명령어를 입력하여 개인키(id_rsa)와 공개키(id_rsa.pub)를 생성한다. 설정 과정 중 나타나는 질문에는 모두 Enter 키를 눌러 기본값으로 넘긴다. 특히 비밀번호(passphrase)는 입력하지 않아야 자동 로그인이 가능하다.

> ssh-keygen -t rsa
> ls ~/.ssh

3. 카페24 설정 및 키 복사

• 카페24 관리자 페이지의 [서비스 사용현황]에서 아이디와 서버 IP를 확인한다.
• [보안관리] > [FTP/Shell 접속설정]에서 ‘SSH Key 로그인 사용’ 대신 ‘비밀번호 로그인 사용’을 선택한다. 카페24에서 제공하는 자체 SSH Key는 30일마다 갱신해야 하는 번거로움이 있으므로, 직접 생성한 키를 사용하는 것이 관리 측면에서 효율적이다. 다만, 보안을 위해 비밀번호는 크롬 브라우저에서 제안하는 것과 같이 추측하기 어려운 강력한 조합을 사용한다.
• WSL 리눅스 환경에 ~/.ssh 디렉터리가 없다면 생성하고, 윈도우에서 만든 키 파일들을 해당 디렉터리로 복사한다.
• 다음 명령어를 실행하여 공개키를 카페24 서버의 적절한 권한을 가지는 authorized_keys로 복사한다.

  $ ssh-copy-id 아이디@서버IP주소
  

4. 터미널 프로필 등록

윈도우 터미널 설정을 열고 다음과 같이 새 프로필을 추가한다.

• 이름: 카페24
• 명령줄: ssh 아이디@서버IP주소

기타 세부 설정

윈도우 터미널에 개인적으로 사용하는 추가 설정들이다.

• 프로필의 기본값 설정
  • 추가 설정의 모양에서 텍스트의 글꼴 크기를 11로 조정하고, 커서의 커서 모양은 빈티지를 선택했다.
  • 추가 설정의 고급에서 벨 알림 스타일의 들을 수 있음을 체크 해제하고 플래시 창을 체크했다. Bash에서 Tab 키를 이용한 자동완성을 자주 사용하는데, 그때마다 발생하는 비프음이 거슬리기 때문이다.
• 사용하지 않는 프로필은 드롭다운에서 프로필 숨기기를 켬 으로 하여 목록을 깔끔하게 유지한다.
• 카페24 프로필의 아이콘에서 적당한 아이콘이 없어 AWS의 ec2 이미지를 구하여 설정하였다.
• Debian 프로필의 추가 설정의 모양에서 텍스트의 글꼴에 BitstromWera Nerd Font를 선택하였다. Debian 프로필의 경우 Starship을 설치하여 Git 브랜치나 개발 환경 정보를 확인한다. 이를 제대로 표시하기 위해 Nerd Fonts에서 ‘BitstromWera Nerd Font’를 다운로드하고 설치하였다.
• Git Bash 프로필의 추가설정의 터미널 에뮬레이션에서 제목 변경 표시 안 함을 켬으로 하였다. 폴더 이동 시 경로가 제목 표시줄에 길게 노출하는 데 끝이 잘려 나가 확인이 어렵다.

프로필 순서 변경하기

최신 버전(1.16 이상)의 윈도우 터미널은 설정 화면 왼쪽 메뉴에서 드래그 앤 드롭으로 순서를 바꿀 수 있는 기능을 지원한다. 하지만 윈도우 터미널을 관리자 권한으로 실행한다거나 UAC(사용자 계정 컨트롤)를 꺼두는 등 시스템 환경에 따라 이 기능이 제대로 작동하지 않는 경우가 있는 것 같다. 이럴 때는 직접 settings.json 파일을 수정하는 것이 가장 확실하다.

설정 화면 좌측 하단의 [JSON 파일 열기] 를 클릭하여 파일을 연 후, "profiles": { "list": [ ... ] } 내부에 나열된 프로필 블록들의 순서를 수동으로 재배치하고 저장하면 된다. 각 블록 사이의 쉼표( , ) 처리에 주의하자.

관련 글

이전에 쓴 Windows 터미널의 설정 및 ssh 사용하기 에서 다음 내용을 참고할 수 있다.

• 커서의 깜박임을 없애는 방법
• SSH 서버 자동 접속 상세 가이드

The post 윈도우 터미널 설치와 설정 appeared first on bitneer.dev.

eth0 네트워크 인터페이스 이름의 미지원

네트워크 인터페이스 이름으로 eth0 등을 사용하고 있다면 데비안 10으로 업그레이드하기 전에 새로운 방식의 이름으로 변경해 주어야 한다. 이에 대한 이해를 위해 네트워크 인터페이스에 이름을 부여하는 방법의 변화 과정을 보자. 원래의 간단한 체계(Original Simple Scheme)는 리눅스 커널이 단순히 eth0, eth1 등으로 이름을 붙인다. 이 체계의 문제는 부팅 후에 eth0과 eth1의 이름이 서로 바뀔 수 있다는 점이다. 이 문제를 해결하기 위한 여러 방법이 생겨났는데 그중의 하나가 영속적인 이름 체계(Persistent Names Scheme)이다. 이 체계는 Mac 주소를 사용하여 고정된 eth0 등의 이름을 부여한다. 이 체계도 완전하지 않고 특히 가상머신(virtualization)에서 문제가 있다. 그래서 나온 것이 펌웨어/BIOS에서 제공하는 정보를 사용하는 예측가능한 이름 체계(Predictable Name Scheme)이다.

데비안 5(Lenny) 즈음부터 영속적인 이름 체계를 사용해 왔다. 데비안 9(Stretch)에서 예측가능한 이름 체계가 들어 왔다. 데비안 9를 새로 설치하면 예측가능한 이름 체계를 사용한다. ‘ip a‘ 명령어를 실행하면 기존의 eth0 대신 하드웨어에 따라 달라지는 eno1, enp0s1, wlp1s0 등의 이름을 볼 수 있을 것이다. 새로 설치하는 것이 아니라 업그레이드로 데비안 9까지 왔다면 여전히 영속적인 이름 체계를 사용할 것이다. /etc/udev/rules.d/70-persistent-net.rules 파일의 존재로 확인할 수 있다.

데비안 10(Buster)에서 실제 제작자(upstream)가 영속적인 이름 체계를 공식적으로 지원하지 않는다. NetworkInterfaceNames – Debian Wiki 페이지에서는 영속적인 이름 체계를 데비안 10까지는 사용할 수 있고 데비안 11(Bullseye) 무렵에 완전히 없어질 것이라 나온다. 데비안 10 — 릴리스 노트 5장에서는 영속적인 이름 체계가 가능할지도 모르지만, 위험할 수 있어 새로운 이름으로 변경할 것을 권고하고 있다. 어쨌든 영속적인 이름 체계는 피하는 것이 나을 것이고 이에 대한 몇 가지 방법이 있다.

1. 원래의 간단한 체계 사용하기

네트워크 인터페이스를 하나만 가지고 있고 예측가능한 이름 체계를 싫어한다면 원래의 간단한 체계를 사용할 수 있는 다양한 방법이 있다. 그러나 이것이 지속 가능할지는 알 수 없다. 다음에서 커널의 옵션을 설정하는 방법을 설명한다.

1.1. /etc/default/grub 파일의 GRUB_CMDLINE_LINUX_DEFAULT의 값으로 "net.ifnames=0"을 추가한다.

GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

1.2. update-grub 명령어를 실행한다.

# update-grub

데비안 9를 새로 설치했다면 위까지 작업한 후 시스템을 재시작하면 eth0을 사용할 수 있을 것이다. 그러나 영속적인 이름 체계를 사용하여 /etc/udev/rules.d/70-persistent-net.rules 파일을 가지고 있다면 추가적인 작업이 필요하다.

1.3. /etc/udev/rules.d/70-persistent-net.rules 파일을 삭제하거나 이름을 바꾼다.

# cd /etc/udev/rules.d
# mv 70-persistent-net.rules 70-persistent-net.rules.old

1.4. 다음의 명령어로 initrd를 재생성한다.

# update-initramfs -u
...

1.5. 시스템을 재시작한다.

# systemctl reboot

2. ssh로 접속하여 예측가능한 이름 체계로 변경하기

ssh로 접속하여 원격 시스템의 네트워크 인터페이스 이름을 바꾸는 것은 신중하게 해야 한다. 오타 하나 때문에 ssh로 접속할 수 없는 불상사가 발생한다. 내가 사용하는 시스템이 모니터와 키보드 없이 구석에 자리하고 있는데 작업에서 실수가 발생한다면 상당히 귀찮을 것이다. 시스템이 모니터와 키보드를 가지고 있어 콘솔로 직접 접근할 수 있다면 작업은 좀 더 편할 것이다. 다음의 설명 중 @reboot cronjob 등은 콘솔을 가지고 있다면 생략할 수 있으므로 참작하여 보자.

2.1. 먼저 자신이 현재 사용하고 있는 네트워크 인터페이스 이름을 확인한다. 여기에는 다양한 방법들이 있다.

# ip a
# cat /etc/udev/rules.d/70-persistent-net.rules
# echo /sys/class/net/[ew]*

2.2. 영속적인 이름 체계에서 특별한 경우가 아니라면 eth0을 사용하고 있을 것이다. 다음의 명령어로 eth0을 사용하고 있는 설정 파일들을 찾는다.

# grep -r eth0 /etc
...

위의 결과로 나온 대부분은 주석으로 처리한 것이고 실제 변경이 필요한 파일은 /etc/network/interfaces일 것이다.

2.3. 다음의 명령어로 예측가능한 이름 체계에서 사용할 네트워크 인터페이스 이름을 찾는다.

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enxf46d04d4b9f6
ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
ID_NET_NAME_PATH=enp3s0

라인 4에서 나온 enp3s0이 내가 앞으로 사용해야 할 이름이다. 여러분이 가지고 있는 하드웨어에 따라 이름은 달라질 것이다. VirtualBox 가상머신의 데비안은 enp0s3 이름이 나온다.

2.4. 다음으로 진행하기 전에 무언가 잘못되었을 때를 위한 대비책을 세우자!

2.4.1. 다음의 스크립트는 아래에서 작업할 내용을 복구하는 스크립트이다.

#!/bin/bash

sleep 5m

ip a >> /root/network_interfaces.txt
mv -f /etc/network/interfaces /etc/network/interfaces.fail
cp -a -f /etc/network/interfaces.bak /etc/network/interfaces
cp -a -f /etc/udev/rules.d/70-persistent-net.rules.old /etc/udev/rules.d/70-persistent-net.rules
#cp -a -f /root/99-default.link /etc/systemd/network/99-default.link
update-initramfs -u
systemctl reboot

이 스크립트를 부팅 시 실행할 수 있게 Crontab에 등록할 것이다. 라인 3은 5분을 대기하기 위한 것이다. 시스템을 재시작하고 ssh로 접속을 할 수 있는지 확인한다. 접속에 성공하면 이 스크립트를 실행하는 프로세스를 찾아 죽여야 한다. ssh 접속에 실패한다면 5분 후 라인 5부터 복구 작업을 시작한다. 라인 5는 ‘ip -a’ 명령어로 네트워크 인터페이스의 이름을 확인하기 위한 것이다. 라인 6은 네트워크 이름 enp3s0으로 변경했던 /etc/network/interfaces 파일의 이름을 변경하여 보관해 둔다. 라인 7에서 기존의 eth0 이름을 가진 /etc/network/interfaces로 복구한다. 라인 8은 /etc/udev/rules.d/70-persistent-net.rules 파일을 복구한다. 라인 9는 가상머신에 설치한 데비안을 위한 것이다. 가상머신의 데비안을 사용한다면 라인 8을 주석 처리하고 라인 9의 주석을 제거한다. 라인 10에서 initrd를 재생성한다. 라인 11에서 시스템을 재시작한다. 시스템을 재시작하면 기존의 eth0으로 다시 접속할 수 있을 것이다. 접속하자마자 위의 실행 프로세스를 찾아 죽여야 한다.

2.4.2. 다음의 명령으로 위에서 작성한 스크립트에 실행 모드를 추가한다.

# chmod +x /root/revoke_net.sh

2.4.3. crontab -e 명령어를 사용하여 다음의 내용을 추가한 후 저장한다.

# crontab -e
...
@reboot /root/revoke_net.sh

crontab -l 명령어를 실행하여 제대로 등록하였는지 확인해 볼 수 있다.

2.5. /etc/network/interfaces 파일을 복구에 사용할 수 있도록 백업해 둔다.

# cp -a /etc/network/interfaces /etc/network/interfaces.bak

/etc/network/interfaces 파일에서 eth0을 2.3.에서 나온 enp3s0으로 변경한다.

...
auto enp3s0
iface enp3s0 inet static
...

2.6. /etc/udev/rules.d/70-persistent-net.rules 파일의 이름을 바꾼다. 가상머신의 데비안이라면 /etc/systemd/network/99-default.link 파일을 /root 디렉토리로 옮겨준다.

# cd /etc/udev/rules.d
# mv 70-persistent-net.rules 70-persistent-net.rules.old

2.7. 다음의 명령어로 initrd를 재생성한다.

# update-initramfs -u
...

2.8. 시스템을 재시작한다.

# systemctl reboot

2.9. ssh로 접속해 본다. 접속에 성공한다면 다음과 같이 revoke_net.sh 스크립트를 실행하는 프로세스를 찾아 죽인다.

# ps -ef | grep revoke
root       723   717  0 14:58 ?        00:00:00 /bin/sh -c /root/revoke_net.sh
root       724   723  0 14:58 ?        00:00:00 /bin/bash /root/revoke_net.sh
root      1849  1779  0 14:58 pts/0    00:00:00 grep revoke
# kill -9 724
# ps -ef | grep revoke
root      1917  1779  0 14:59 pts/0    00:00:00 grep revoke

2.10. ‘ip a‘ 명령어로 네트워크 인터페이스의 이름이 enp3s0으로 나오는지 확인해 본다.

2.11. 성공적으로 작업을 마쳤으면 정리에 들어간다. crontab -e 명령어를 사용하여 2.4.3.에서 추가한 ‘@reboot /root/revoke_net.sh‘를 삭제한 후 저장한다. crontab -l 명령어로 확인해 본다. /etc/network/interfaces.bak 파일을 삭제한다. /etc/udev/rules.d/70-persistent-net.rules.old 파일은 따로 보관하거나 삭제한다.

기존의 PostgreSQL 데이터베이스는 reindex 필요

데비안 10은 glibc 로케일 데이터를 업그레이드하기 때문에 PostgreSQL의 기존 데이터베이스에 대한 인덱스를 다시 만들어야 한다. 가능하다면 PostgreSQL의 데이터베이스를 사용하는 응용 프로그램을 업그레이드가 끝날 때까지 잠시 중단하는 것이 좋을 것이다. 업그레이드를 완료한 즉시 다음의 명령어를 실행한다.

# sudo -u postgres reindexdb --all
...

관련 글

• 데비안을 새 버전으로 업그레이드하기

참고 자료

• NetworkInterfaceNames – Debian Wiki
• Predictable Network Interface Names
• systemd.net-naming-scheme — Network device naming schemes
• 데비안 10 — 릴리스 노트

The post 데비안 9(Stretch)에서 10(Buster)으로 업그레이드 시 주의 사항 appeared first on bitneer.dev.

새 버전으로 업그레이드하려면 조금은 부지런해야 한다. 제일 먼저 업그레이드할 버전의 릴리스 노트(Release Notes)를 읽어 봐야 한다. 릴리스 노트의 페이지 주소는 https://www.debian.org/releases/<코드네임>/releasenotes다. 코드네임이 buster라면 https://www.debian.org/releases/buster/releasenotes 주소로 접속할 수 있다. 데비안 릴리스의 버전 넘버와 코드네임은 DebianReleases – Debian Wiki에서 볼 수 있다. 코드네임은 개발 단계에서 사용하고 이후에 버전 넘버를 붙인다. 4.0(Etch) 이후로 버전 넘버는 1씩 규칙적으로 증가했지만, 그전에는 그렇지 않았다.

릴리스 노트의 PDF 문서는 50쪽 정도의 분량을 가진다. 아쉽게도 한글 번역 문서는 없다. 그러나 새 버전으로 업그레이드하는 것이 처음이라면 한 번 읽어 볼 것을 추천한다. 전체적인 내용을 통해 자신만의 업그레이드 절차를 만들어 보기를 바란다. 다음번에 업그레이드할 때는 2장에서 새 버전의 전체적인 내용을 대강 훑고, 5장에서 자신이 설치한 패키지에 따라 영향을 받을만한 것이 있는지 정도만 본다. 나머지 장의 내용은 거의 변하지 않기 때문이다.

이 글은 나의 관점에서 데비안을 새 버전으로 업그레이드할 때 릴리스 노트에 기반하여 필요한 사전 지식과 절차를 정리한 것이다.

단계적 업그레이드

버전 간의 업그레이드는 단계적으로 해야 한다. 예를 들면, 버전 8(Jessie)에서 버전 10(Buster)으로 업그레이드하려면 먼저 버전 9(Stretch)로 업그레이드한 후 다시 Buster로 업그레이드한다. 데비안 개발자가 직전 버전에서 새 버전으로 업그레이드하는 것만을 테스트하기 때문에 단계적으로 업그레이드할 것을 제안하는 것으로 보인다.

버전 업그레이드 시 추천하는 패키지 관리 도구

릴리스 노트 4장에서 새 버전으로 업그레이드할 때 추천하는 패키지 관리 도구는 가끔 달라질 때가 있다. aptitude를 추천한 적도 있지만, 대부분은 apt-get 사용을 권장해 왔다. 데비안 10(Buster)에서 처음으로 apt를 추천한다. apt는 apt-get과 apt-cache의 기능을 합치고, 출력할 때 색깔을 사용하여 눈을 즐겁게 해준다. 그러나 색깔이 들어간 코드로 인해 파싱 등을 위한 스크립트에서 사용하기에 부적절하다. 다음은 업그레이드와 관련하여 apt-get을 apt로 대체할 수 있는 명령어 목록이다.

• apt-get update → apt update
• apt-get upgrade → apt upgrade
• apt-get dist-upgrade → apt full-upgrade

/etc 설정 충돌

/etc 디렉토리는 데비안 개발자(패키지 메인테이너)와 사용자가 충돌하는 영역이다. 패키지에 중요한 설정의 변화가 있을 수 있다. 예를 들면 Apache 2.2에서 2.4로 변경되었을 때 설정에 많은 차이가 있었다. 업그레이드 시 마지막 단계인 패키지의 설정에서 이러한 충돌을 마주칠 것이다. 패키지 개발자의 설정으로 대체할 것인지 사용자의 설정을 유지할 것인지 선택을 묻는다. 대부분 패키지 개발자의 설정으로 대체하는 것이 좋다. 그러고 나서 나중에 내가 원하는 설정으로 변경해 준다. 내가 했던 설정은 .dpkg-old, .ucf-old 등의 확장자를 가진 파일로 남아 있을 것이다.

업그레이드를 진행 중일 때는 정신이 없어서 어떤 패키지에서 무엇을 선택했는지 잊어버릴 때가 있다. 그리고 간간이 보이는 경고 메시지도 신경 쓰인다. 화면이 빠르게 지나가기 때문에 메시지를 잡아내기도 힘들다. 따라서 script 프로그램으로 진행 상황을 기록하는 것이 좋다.

script의 사용 방법을 간단히 알아보자.

# script --timing=test.time test.script
Script started, file is test.script
# free
              total        used        free      shared  buff/cache   available
Mem:       16345836     8126580     1408848     1259412     6810408     6622112
Swap:       2579452        1352     2578100
# exit
exit
Script done, file is test.script
#

라인 1에서 script 명령어를 실행한다. --timing=test.time 옵션은 scriptreplay에서 사용하기 위해 시간을 저장하는 것이다. 라인 2에서 스크립트가 시작되었음을 알려 준다. 라인 3에서 free 명령어를 사용하여 메모리의 정보를 본다. script의 기록을 위한 예제로 아무 명령어나 실행해 보자. 라인 7에서 exit 명령어를 사용하여 script의 실행을 끝낸다. 우리가 했던 행동은 test.scirpt 파일에 저장하고 있다.

# scriptreplay test.time test.script
# free
              total        used        free      shared  buff/cache   available
Mem:       16345836     8126580     1408848     1259412     6810408     6622112
Swap:       2579452        1352     2578100
# exit
exit

#

script에서 --timing 옵션을 사용하였다면 라인 1과 같이 scriptreplay 명령어로 우리가 했던 행동을 볼 수 있다. 데비안의 업그레이드 과정은 내용이 많아서 scriptreplay로 한가하게 다시 보기를 하지는 않을 것이다. 스크립트 파일(test.script)을 편집기로 보면서 검토하는 것이 빠르다.

데비안 10에서 추천하는 ‘apt full-upgrade‘ 명령어는 색깔이 들어가 있는 코드 때문에 script 프로그램하고는 맞지 않는다. 대신에 /var/log/apt/term.log 파일에서 우리가 했던 행동들을 볼 수 있다.

screen 사용

ssh로 접속하여 업그레이드한다면 screen을 사용해야 한다. 네트워크 관련 패키지를 업그레이드할 때 ssh 세션이 끊어질 수 있기 때문이다. 또는 ssh 클라이언트를 사용하는 윈도우 운영체제의 컴퓨터가 업그레이드하면서 컴퓨터를 다시 시작해 버릴 수도 있다. ssh 세션이 끊기면 ssh 서버 프로세스에서 포크한 bash 쉘도 종료하고 업그레이드 작업이 중단될 것이다.

screen 사용법에 대해 간단히 알아보자. screen을 설치하지 않았다면 다음의 명령어로 screen 패키지를 설치한다.

# apt install screen

다음과 같이 screen 명령어를 실행한다. 실행 후 <Space>나 <Return> 키를 눌러 작업을 시작한다.

# screen

현재 상태를 유지하면서 screen 세션에서 빠져나오려면 <Ctrl + a> 키를 누른 후 이어서 <d> 키를 누른다. (detach)

다시 이전에 작업하던 screen 세션으로 들어가려면 다음의 명령어를 실행한다. (reattach) 업그레이드 도중 ssh 세션이 끊어져 다시 접속했을 때에도 다음의 명령어를 실행하여 작업을 계속할 수 있다.

# screen -Dr

screen 세션을 종료하려면 screen의 쉘에서 exit 명령어를 실행한다. 또는 <Ctrl + a> 키에 이어서 <k> 키를 누른 후 종료를 확인하는 메시지가 나오면 y를 입력한다.

# exit

sources.list와 서드파티 저장소

새 버전으로 업그레이드하려면 /etc/apt/sources.list 파일을 변경해야 한다. 다음은 데비안 9(Stretch)의 sources.list 파일의 예이다.

# stretch
deb http://deb.debian.org/debian/ stretch main contrib non-free
deb-src http://deb.debian.org/debian/ stretch main contrib non-free

# stretch - security updates
deb http://security.debian.org/debian-security stretch/updates main contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

# stretch-updates
deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://deb.debian.org/debian/ stretch-updates main contrib non-free

stretch 코드네임을 업그레이드하려는 buster로 모두 변경하면 된다.

데비안에 없는 패키지를 제공하는 비공식 APT 저장소를 서드파티 저장소(third-party repository)라고 부른다. 나의 경우 AdoptOpenJDK, .NET Core SDK, Node.js, VirtualBox 네 개가 있다. 일반적으로 서드파티 저장소의 GPG 키는 /etc/apt/trusted.gpg 파일이나 /etc/apt/trusted.gpg.d 디렉토리에 추가하고 저장소의 설정은 /etc/apt/sources.list 파일이나 /etc/apt/sources.list.d 디렉토리에 추가한다. 나는 일관성을 위해 저장소의 설정은 /etc/apt/sources.list.d 디렉토리에 다음의 파일로 관리한다. 파일 이름은 .list 확장자를 가져야 한다.

• adoptopenjdk.list
• microsoft-prod.list
• nodesource.list
• virtualbox.list

새 버전으로 업그레이드하려면 위의 파일들도 수정해 주어야 한다. 몇 가지 예를 보자. 다음은 데비안 9(Stretch)의 nodesource.list 파일의 내용이다.

deb https://deb.nodesource.com/node_10.x stretch main
deb-src https://deb.nodesource.com/node_10.x stretch main

위의 stretch 코드네임을 업그레이드하려는 buster로 변경해야 한다. https://deb.nodesource.com/node_10.x/dists/buster/ 주소로 접속하여 buster 저장소의 존재를 확인할 수 있다. 저장소 설정의 URL에서 dists는 관례로 생략하기 때문에 실제 주소에는 추가해야 한다.

마이크로소프트의 .NET Core 저장소는 특이하게 URL에 데비안의 버전 넘버가 있다. 다음은 microsoft-prod.list 파일의 내용이다.

deb [arch=amd64] https://packages.microsoft.com/debian/9/prod stretch main

코드네임을 buster로 변경하는 것에 더하여 9를 10으로 수정해야 한다. https://packages.microsoft.com/debian/10/prod/dists/buster/ 주소로 접속하여 저장소를 확인할 수 있다.

업그레이드 절차

새 버전으로 업그레이드하는 것은 보통 2년 정도의 주기를 가진다. 긴 기간 동안 업그레이드 작업 절차는 잊히기 쉽고 한 번만 하고 끝나는 것이 아니므로 정리해 둘 필요가 있다.

1. https://www.debian.org/releases/<코드네임>/releasenotes에서 릴리스 노트를 확인한다. 2장에서 새 버전의 전체적인 내용을 대강 훑고, 5장에서 문제가 발생할 만한 것이 있는지 본다. 4장에서 추천하는 패키지 관리 도구 정도를 확인한다.
2. 데이터와 설정 정보들을 백업한다. 나의 경우 데이터베이스를 포함하여 서버 전체를 백업하는 스크립트를 사용한다.
3. /etc/apt/sources.list 파일에서 현재 코드네임을 업그레이드할 코드네임으로 변경한다.
4. /etc/apt/sources.list.d 디렉토리에서 서드파티 저장소에 대한 설정 파일을 변경한다.
5. screen을 실행한다.

   # screen
   

6. script를 실행한다.

   # script --timing=upgrade.time upgrade.script
   

7. 패키지 리스트를 업데이트한다.

   # apt update
   

8. 최소한의 시스템 업그레이드를 실행한다.

   # apt-get upgrade
   

9. 시스템 업그레이드를 실행한다.

   # apt full-upgrade
   

10. 업그레이드 진행 중에 발생했던 /etc 디렉토리의 설정 충돌을 해결한다. 데비안 개발자의 설정에 자신이 원하는 설정을 추가한다. /var/log/apt/term.log나 upgrade.script 파일을 참고할 수 있다.
11. script를 종료하고 screen 세션을 종료한다.

    # exit
    ...
    # exit
    

12. 새로운 커널을 반영하기 위해 시스템을 재시작한다.

    # systemctl reboot
    

13. 삭제한 패키지의 설정 파일이 남아 있는 것을 찾아 제거한다.

    # aptitude search '~c'
    # aptitude purge '~c'
    

14. aptitude를 실행하고 Obsolete and Locally Created Packages 카테고리에서 쓸모가 없어진 패키지를 선택적으로 삭제한다.

참고 자료

• DebianReleases - Debian Wiki
• 데비안 10 -- 릴리스 노트
• SourcesList - Debian Wiki
• DebianRepository/UseThirdParty - Debian Wiki
• The Debian GNU/Linux FAQ
• Debian Reference

The post 데비안을 새 버전으로 업그레이드하기 appeared first on bitneer.dev.

Windows 터미널을 처음 설치하고 막막할 수 있는 설정 방법과 ssh 클라이언트의 효율적인 사용을 정리해 본다. Windows 터미널은 Microsoft 스토어에서 검색해서 설치한다.

프로필에 기본적인 설정하기

...
    "profiles":
    {
        "defaults":
        {
            // Put settings here that you want to apply to all profiles.
            "fontSize": 10,
            "cursorShape": "vintage"
        },
        "list":
        [
            {
                // Make changes here to the powershell.exe profile.
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "name": "Windows PowerShell",
                "commandline": "powershell.exe",
                "hidden": false
            },
            {
                // Make changes here to the cmd.exe profile.
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "name": "명령 프롬프트",
                "commandline": "cmd.exe",
                "hidden": false
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": false,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            }
        ]
    },
...

위의 내용은 settings.json 파일에서 일부분을 발췌한 것이다. 라인 1과 34의 ...은 내용을 생략하였음을 나타낸다. 우리가 중점적으로 보아야 할 부분은 라인 2부터 시작하는 “profiles”이다. Windows 터미널은 설정 단위로 프로필이라는 용어를 사용한다.

처음 설치 시 Windows Powershell, 명령 프롬프트, Azure Cloude Shell 3개의 프로필이 있다. 라인 10의 “list” 절(section)에서 각 프로필을 포함하고 있는 것을 볼 수 있다. 라인 4의 “defaults” 절에서 모든 프로필에 적용할 속성(property)을 설정할 수 있다. 속성 설정은 “속성”: “문자열 값” 형식으로 한다. 숫자 값이나 불린 값(true, false)은 “속성”: 값 형태로 값에 인용 부호(“)를 사용하지 않는다.

라인 7, 8은 내가 추가한 설정이다. 폰트가 너무 큰 것 같아 “fontSize” 속성을 10으로 설정하였다. 라인 8은 커서의 모양을 굵은 밑줄로 한 것이다. 커서 모양 속성인 “cursorShape”는 "bar", "vintage", "underscore", "filledBox", "emptyBox" 값을 설정할 수 있다. 편집한 내용을 저장하면 설정이 바로 적용되는 것을 볼 수 있을 것이다.

나는 커서가 깜박이는 것을 좋아하지 않는다. 나와 취향이 비슷한 분을 위해 설명을 추가한다. 커서 깜박임 설정은 윈도우 운영체제에서 해야 한다. 다음의 절차로 커서 깜박임을 없앨 수 있다.

1. 시작 > 설정의 설정 검색에 ‘제어판‘을 입력하고 검색한 후 제어판을 클릭한다.
2. 제어판 검색에 ‘키보드‘를 입력하고 검색한다.
3. 키보드 상태 확인을 클릭한다.
4. 속도 탭에서 커서 깜박임 속도를 없음으로 설정한다.
5. 확인 버튼을 클릭하여 설정을 마친다.

Git Bash 프로필 추가하기

기본으로 제공하는 3개의 프로필에 더하여 새로운 프로필을 추가해 보자. Git Bash 프로필을 추가하는 방법을 먼저 살펴본다. Git Bash는 Git – Downloads에서 Windows 용 설치 파일을 다운로드하여 설치할 수 있다. git을 사용하지 않는다면 GUID 생성 방법과 속성 설명 만을 보고 다음으로 넘어간다.

각 프로필은 고유의 GUID 값을 가져야 한다. Windows 터미널은 실행할 때 디폴트로 파워쉘을 실행한다. 파워쉘에서 ‘[guid]::NewGuid()‘ 명령어를 실행하여 GUID를 만들 수 있다.

PS C:\Users\bitneer> [guid]::NewGuid()

Guid
----
d32532fa-83a2-4b38-91ad-fb5990d24199


PS C:\Users\bitneer>

라인 5의 값을 복사해서 “guid” 속성의 값으로 사용하면 된다. Windows 터미널에서 클립보드로 복사하는 단축키는 <Ctrl + C>, <Ctrl + Shift + C>, <Ctrl + Insert> 3가지가 있다. <Ctrl + C> 키는 Unix/Linux 시스템에서 포그라운드 프로세스를 종료하는 데 사용한다. 따라서 <Ctrl + Shift + C>나 <Ctrl + Insert> 키로 복사하는 습관을 들이는 것이 좋겠다.

settings.json 파일에 Git Bash 프로필 설정을 다음과 같이 추가한다.

...
        "name": "Azure Cloud Shell",
        "source": "Windows.Terminal.Azure"
    },
    {
        "guid": "{d32532fa-83a2-4b38-91ad-fb5990d24199}",
        "name": "Git Bash",
        "commandline": "C:/Program Files/Git/bin/bash.exe --login",
        "icon": "file:///C:/Program Files/Git/mingw64/share/git/git-for-windows.ico",
        "hidden": false
    }
...

기본적으로 제공하는 프로필 중 마지막 프로필인 Azure Cloude Shell 뒤에 Git Bash 프로필을 추가하였다. 라인 4에서 쉼표(,)를 추가하는 것에 주의한다. 프로필 항목이 이어지면 쉼표를 붙이고 라인 11처럼 제일 끝 항목은 쉼표를 붙이지 않는다. 속성도 마찬가지로 라인 10의 마지막 “hidden” 속성에는 쉼표를 붙이지 않았다.

라인 6의 “guid” 속성은 위에서 만든 GUID 값으로 설정하였다. 라인 7의 “name” 속성에는 원하는 이름을 사용한다. 이 이름이 드롭다운 메뉴에 나타난다. 라인 10의 “hidden” 속성은 드롭다운 메뉴에 프로필을 숨길지를 설정한다. 디폴트 값이 false이므로 이 속성을 삭제할 수 있다. 그러나 설정 내용은 유지하면서 드롭다운 메뉴에서 숨기고 싶을 때 편집의 용이성을 위해 넣어주는 것이 좋을 것이다. 라인 9의 “icon” 속성에 Git Bash의 아이콘 이미지의 파일 경로를 설정하여 드롭다운 메뉴와 탭에 아이콘을 보이게 한다.

라인 8의 “commandline” 속성에 Git Bash의 실행 파일 경로를 값으로 설정하였다. ‘–login‘ 옵션을 주어 로그인 시 적용하는 환경 변수들을 불러온다. 추가로 환경 변수를 설정하고 싶다면 자신의 홈 폴더에 .profile 파일을 만들고 로그인 시에 적용할 내용을 넣어 줄 수 있다. 예를 들면 다음과 같이 할 수 있다.

export LS_COLORS="di=00;36:fi=00;37"
cd "D:\MySpace"

라인 1은 ls 명령어 사용 시 디렉토리의 색깔이 어두운 파란색으로 나오는 것을 좀 더 밝은색으로 한 것이다. 라인 2는 주로 작업하는 디렉토리로 이동하기 위한 것이다. 여러분에게 맞게 설정 내용을 추가할 수 있다. 참고로 Windows 용 Git에는 MinGW를 포함하고 있다. 따라서 vim, grep, ssh 같은 유닉스 명령어들을 사용할 수 있다. Git Bash 쉘에서 ‘echo $PATH‘ 명령어를 실행하고 나온 경로를 통해 어떤 명령어들을 사용할 수 있는지 확인해 볼 수 있을 것이다.

OpenSSH 클라이언트 확인하기

Git Bash는 ssh를 포함하고 있으므로 Git Bash 쉘에서 ssh를 바로 사용할 수 있다. 파워 쉘이나 명령 프롬프트에서 모든 경로를 타이핑하지 않고 편하게 사용하려면 64-bit 시스템일 때 C:\Program Files\Git\usr\bin 폴더를 PATH 환경 변수에 추가해야 할 것이다.

Git Bash를 설치하지 않는다면 Windows 10의 OpenSSH를 사용할 수 있다. OpenSSH 클라이언트를 추가하였는지 다음과 같이 확인한다.

1. 윈도우에서 시작 > 설정 > 앱의 선택적 기능을 클릭한다.
2. OpenSSH 클라이언트가 목록에 있는지 확인한다.
3. 목록에 없으면 ‘+‘ 기능 추가 아이콘을 클릭하여 OpenSSH 클라이언트를 추가한다.

OpenSSH 클라이언트 기능을 추가하면 C:\Windows\System32\OpenSSH 폴더를 자동으로 PATH 환경 변수에 추가하여 준다.

원격에 있는 시스템(예: 192.168.10.10)의 root 계정으로 접속하기 위해 다음의 ssh 명령어를 실행할 수 있다.

PS C:\Users\bitneer> ssh root@192.168.10.10
...

첫 접속이라면 접속을 계속할지를 물을 것이다. ‘yes‘를 입력하고 <Enter> 키를 누르면 $HOME/.ssh/known_hosts 파일에 호스트(192.168.10.10)를 추가해 줄 것이다. 호스트 추가 후 다시 위의 명령어를 실행하면 ‘암호’를 물을 것이고 root 계정의 암호를 입력하여 접속한다.

위의 예제에서 위험하게 root 계정을 사용하였다. 나의 경우 공유기(방화벽 역할) 안에 시스템이 있고 ssh 서버를 포트 포워딩으로 열어 두지 않았기 때문에 보안에는 문제가 없다. 참고로 ssh 서버에서 root로 로그인을 허용하려면 데비안 시스템의 경우 /etc/ssh/sshd_config 파일에 ‘PermitRootLogin yes‘를 추가하고 ssh 서버를 다시 시작해야 한다. 앞으로의 예제에서도 192.168.10.10 시스템의 root 계정으로 예를 들 것이다. 여러분에게 맞게 참작해서 보기 바란다.

SSH 사용을 위한 프로필 추가하기

settings.json 파일에 192.168.10.10 시스템의 root 계정으로 로그인하는 프로필을 다음과 같이 추가한다.

...
    },
    {
        "guid": "{12fec865-77d4-4c96-89ef-e1781e805c13}",
        "name": "192.168.10.10 - root",
        //"commandline": "C:/Program Files/Git/usr/bin/ssh root@192.168.10.10",
        "suppressApplicationTitle": true,
        "commandline": "ssh root@192.168.10.10",
        // Linux Icon
        "icon": "ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.scale-100.png",
        // Poswershell Icon
        //"icon": "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png",
        // CMD Icon
        //"icon": "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png",
        "hidden": false
    }
...

라인 2의 Git Bash 프로필 항목의 끝에 쉼표(,)를 추가한다. 라인 16처럼 프로필의 마지막 항목이면 쉼표를 쓰지 않는다. 라인 4의 “guid” 속성에 파워쉘에서 ‘[guid]::NewGuid()‘ 명령어를 실행하여 나온 GUID 값을 복사하여 붙여준다. 라인 5의 “name” 속성에는 원하는 이름을 넣어 준다.

라인 8의 “commandline” 속성에는 ssh 명령어를 입력한다. 주석으로 처리한 라인 6에서 보듯이 Git Bash의 ssh를 사용할 수 있다. Windows의 OpenSSH 클라이언트의 경우 라인 7의 “suppressApplicationTitle” 속성을 true로 설정해야 탭에 “name” 속성으로 설정한 이름 ‘192.168.10.10 - root‘가 나온다. “suppressApplicationTitle”: true를 설정하지 않으면 “commandline”에서 지정한 ssh 프로그램의 이름인 ‘OpenSSH SSH client‘를 탭에 표시할 것이다.

라인 10의 “icon” 속성에 Windows 터미널에서 기본적으로 제공하는 Linux 아이콘으로 설정하였다. Git Bash 프로필에 했던 것처럼 파일 경로를 지정하여 여러분이 원하는 아이콘으로 설정할 수 있다. 마지막으로 라인 15에서 “hidden” 속성을 false로 하여 드롭다운 메뉴에 이 프로필이 나오게 한다. “hidden”은 마지막 속성이기 때문에 문장의 끝에 쉼표를 사용하지 않는 것에 주의한다.

암호를 입력하지 않고 SSH 사용하기

ssh 사용 시 매번 암호를 입력하는 것은 귀찮은 과정이다. 암호 없이 ssh를 사용하기 위해 다음과 같이 작업한다.

1. Windows 터미널을 실행한 후 다음과 같이 ssh-keygen 명령어를 실행하여 개인키(id_rsa)와 공개키(id_rsa.pub)를 만든다. 이미 키가 있다면 이 단계는 넘어간다.

PS C:\Users\bitneer> ssh-keygen -t rsa
...

무엇을 할지 물으면 모두 <Enter> 키를 눌러 넘어간다. 특히, 암호는 입력하지 않아야 한다. 위 명령어는 $HOME/.ssh 폴더에 id_rsa, id_rsa.pub 파일을 생성한다. 주의할 것은 ssh-keygen에 -f 옵션으로 id_rsa와 다른 이름으로 키를 생성하였다면 아래의 작업 후 ssh 명령어 실행 시 -i 옵션에 개인키 이름을 지정해야 암호를 묻지 않을 것이다. ssh 클라이언트는 디폴트로 id_rsa 이름만을 인식하기 때문이다.

2. 다음으로 접속하고자 하는 시스템(예: 192.168.10.10) 계정의 ~/.ssh 디렉토리 안에 공개키(id_rsa.pub)를 authorized_keys 파일 이름으로 만들어야 한다. linux의 OpenSSH는 이를 쉽게 하려고 ssh-copy-id 명령어를 제공한다. 그러나 윈도우의 ssh 클라이언트에는 ssh-copy-id 프로그램이 없다. 이 파일을 데비안에서 한 번 조사해 보았다.

# which ssh-copy-id
/usr/bin/ssh-copy-id
# dpkg -S /usr/bin/ssh-copy-id
openssh-client: /usr/bin/ssh-copy-id
# file /usr/bin/ssh-copy-id
/usr/bin/ssh-copy-id: POSIX shell script, ASCII text executable

라인 1에서 which 명령어로 ssh-copy-id의 경로를 확인한다. 라인 3에서 dpkg의 -S 옵션으로 ssh-copy-id 파일을 포함하고 있는 패키지를 확인한다. 라인 5에서 file 명령어로 ssh-copy-id 파일의 종류를 확인한다. 라인 6에서 보듯이 본쉘 스크립트임을 알 수 있다. 윈도우의 OpenSSH는 배치파일이나 파워쉘 스크립트로 ssh-copy-id를 포팅하지 않은 것으로 보인다.

2.1. Git Bash를 설치했다면 Git Bash 쉘에서 다음과 같이 ssh-copy-id 명령어를 실행한다.

$ ssh-copy-id -i $HOME/.ssh/id_rsa.pub root@192.168.10.10
...

‘$HOME’ 대신 물결표 문자(~)로 대치하여 ‘~/.ssh/id_rsa_pub’처럼 간단하게 할 수 있다. 실행 중에 암호를 물으면 192.168.10.10 시스템의 root 계정에 대한 암호를 입력한다.

2.2. Git Bash를 설치하지 않았다면 접속하고자 하는 시스템의 계정에 .ssh 디렉토리가 있는지에 따라 다음과 같이 한다.

2.2.1. 접속하고자 하는 계정에 ~/.ssh 디렉토리가 없는 경우 다음의 명령어를 실행하여 .ssh 디렉토리를 만든 후 공개 키를 authorized_keys 파일에 추가한다.

PS C:\Users\bitneer> cat $HOME/.ssh/id_rsa.pub | ssh root@192.168.10.10 "umask 077; mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"
...

실행 중에 암호를 물으면 192.168.10.10 시스템의 root 계정에 대한 암호를 입력한다.

2.2.2. 접속하고자 하는 계정에 ~/.ssh 디렉토리가 있는 경우 다음의 명령어를 실행하여 공개 키를 authorized_keys 파일에 추가한다.

PS C:\Users\bitneer> cat $HOME/.ssh/id_rsa.pub | ssh root@192.168.10.10 "umask 077; cat >> ~/.ssh/authorized_keys"
...

3. 암호 없이 ssh를 사용하는 것은 스크립트 파일 작성에 유용하다. 암호를 노출 시키지 않고 백업 스크립트 등을 작성할 수 있기 때문이다. 예를 들면 다음의 명령어 등을 시스템에 직접 접속하지 않고 실행할 수 있다.

PS C:\Users\bitneer> ssh root@192.168.10.10 "systemctl stop mariadb"
PS C:\Users\bitneer> ssh root@192.168.10.10 "shutdown -h now"

단축키 사용

다음은 Windows 터미널에서 유용하게 사용할 수 있는 단축키이다.

• <Ctrl + Shift + D> : 현재 창의 프로필을 새 창으로 연다.
• <Ctrl + Tab> : 탭 간에 전환한다.
• <Alt + Enter> 또는 <F11> : 전체 화면으로 실행한다. 한 번 더 단축키를 누르면 원래 화면으로 돌아온다.
• <Ctrl + Shift + C>와 <Ctrl + Shift + V>로 복사와 붙여넣기를 하는 습관을 들인다.

자신이 추가한 프로필을 여는 단축키를 설정하고 싶다면 settings.json 파일에 다음과 같이 한다.

...
    "keybindings":
    [
        // Copy and paste are bound to Ctrl+Shift+C and Ctrl+Shift+V in your defaults.json.
        ...

        // 192.168.10.10 - root
        { "command": { "action": "newTab", "profile": "{12fec865-77d4-4c96-89ef-e1781e805c13}" }, "keys": "ctrl+shift+n" }
    ]
}

맨 마지막에 있는 “keybindings”에서 라인 8과 같이 단축키 설정을 추가할 수 있다. “profile” 속성의 값으로 GUID나 프로필의 이름("192.168.10.10 - root")을 설정할 수 있다. “keys” 속성에 원하는 단축키를 설정한다.

위 내용은 나의 관점에서 다루었다. 원하는 기능을 추가하고 싶거나 좀 더 개성 있게 꾸미고 싶다면 참고 자료의 페이지를 보기 바란다.

참고 자료

• GitHub – microsoft/terminal: The new Windows Terminal and the original Windows console host, all in the same place!
• Windows 터미널의 글로벌 설정 / Global settings in Windows Terminal
• Windows 터미널의 프로필 설정 / Profile settings in Windows Terminal
• Windows 터미널의 사용자 지정 키 바인딩 / Custom key bindings in Windows Terminal
• Is there an equivalent to ssh-copy-id for Windows?
• Adding Git-Bash to the new Windows Terminal
• JSON 개요

The post Windows 터미널의 설정 및 ssh 사용하기 appeared first on bitneer.dev.

단계 1. Confluence에 설치한 Atlassian Marketplace 앱의 정보를 확인하기

단계 4에서 보겠지만 기존 버전과 같은 Confluence를 새로 설치하고 앞으로 그것을 사용해야 한다. 이전의 Confluence에 있던 앱들은 다시 설치해야 한다. 단계 2에서 생성하는 XML 포맷의 백업 파일에는 앱의 환경 설정 정보들을 가지고 있다. 이 안의 동일한 버전으로 앱을 설치해야 문제가 발생하지 않을 것이다. 같은 버전으로 쉽게 설치하기 위해 앱을 미리 업데이트해 주는 것이 좋을 것이다. 업데이트 후 앱 이름, 버전, 제작자, 활성화 여부를 기록해 둔다. 나의 경우는 다음과 같다.

• Atlassian Troubleshooting and Support Tools / 1.25.0 / Atlassian / enabled
• Atlassian Universal Plugin Manager Plugin / 3.0.6 / Atlassian / enabled
• Confluence Cloud Migration Assistant / 2.6.0 / Atlassian / enabled
• Confluence Mobile Plugin / 2.2.4 / Atlassian / enabled
• Refined for Confluence / 6.1.15 / Refined / enabled
• RefinedMobile for Confluence / 3.3.2 / RefinedWiki / enabled
• Gliffy Diagrams for Confluence / 8.6.5 / Gliffy, Inc. / enabled
• LaTex Math / 3.9.13 / Bolo Software / enabled

단계 2. XML 포맷으로 데이터를 백업하기

이 단계를 진행할 때 http://192.168.1.10:8090/confluence/admin/backup.action 주소처럼 Confluence 서버에 직접 연결한다. IP 주소는 Confluence를 설치한 시스템의 주소로 여러분에게 맞는 것을 입력한다. Proxy 등과 같이 Confluence 전단의 Apache로 접속하여 작업하면 에러가 날 가능성이 크다. IP 주소로 직접 접속할 때 Confluence의 base URL을 변경하라는 메시지가 나오면 무시하고 진행해도 괜찮다. 다음과 같이 작업한다.

1. Confluence 설정으로 들어가서 ADMINISTRATION > Backup & Restore를 클릭한다.
2. Export this site에서 디폴트 선택인 Include attachments 체크를 그대로 둔 채 Export 버튼을 클릭한다. 백업할 데이터가 크다면 시간이 오래 걸린다. 인내심을 가지고 기다린다.
3. 작업이 완료되면 새로운 창에서 다음과 같이 백업 성공 메시지와 백업 파일의 저장 위치가 나온다. 그리고 24시간 안에 이 파일이 지워질 것을 알려준다. 나는 Proxy Error가 한 번 발생해서 xmlexport-20200524-215026-2.zip처럼 끝에 -2가 붙었다. 이후에 이 파일을 복원에 사용할 것이다.

   The backup was successfully created at /var/local/lib/confluence/temp/xmlexport-20200524-215026-2.zip. This file will be deleted in 24 hours.
   

attachments가 너무 크다면 Include attachments를 체크하지 않는 것이 좋을 수도 있다. 이 경우 단계 5의 다음 단계에서 이전 Confluence의 attachments를 새 Confluence로 복사해야 할 것이다. 다음의 명령어 실행으로 attachments의 크기를 알아볼 수 있다.

# du -h /var/local/lib/confluence/attachments
...
4.6G	/var/local/lib/confluence/attachments

du의 -h 옵션은 크기를 읽기 쉽게 K, M, G로 표시해 준다. 나의 경우 4.6 기가바이트가 나왔는데 attachments 디렉토리를 포함하여 XML 포맷으로 백업할 수 있었다.

단계 3. PostgreSQL의 데이터베이스 만들기

Confluence에서 사용할 PostgreSQL의 데이터베이스를 생성한다. 다음은 psql 클라이언트를 사용한 진행 과정이다.

# psql -h localhost -U postgres -d postgres
psql (9.6.17)
SSL 연결정보 (프로토콜: TLSv1.2, 암호화기법: ECDHE-RSA-AES256-GCM-SHA384, 비트: 256, 압축: off)
도움말을 보려면 "help"를 입력하십시오.

postgres=# CREATE ROLE confluence WITH LOGIN PASSWORD '원하는 암호 입력';
CREATE ROLE
postgres=# CREATE DATABASE confluence WITH ENCODING='UTF8' OWNER=confluence;
CREATE DATABASE
postgres=# \l
                                  데이터베이스 목록
    이름    |   소유주   | 인코딩 |   Collate   |    Ctype    |      액세스 권한
------------+------------+--------+-------------+-------------+-----------------------
 confluence | confluence | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 jira       | jira       | UTF8   | C           | C           |
 postgres   | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 template0  | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
            |            |        |             |             | postgres=CTc/postgres
 template1  | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
            |            |        |             |             | postgres=CTc/postgres
(5개 행)

라인 6에서 CREATE ROLE로 confluence 사용자를 만든다. 라인 8에서 CREATE DATABASE로 confluence 데이터베이스를 생성한다. Confluence의 데이터베이스는 인코딩과 Collation은 utf8로 설정해야 한다. 라인 10에서 \l 명령어로 새로 생성한 confluence 데이터베이스를 확인한다. PostgreSQL에 기본적인 사용은 PostgreSQL의 데이터베이스와 사용자 생성, 백업 및 복구를 참고할 수 있다.

단계 4. 현재 사용하는 Confluence와 같은 버전의 Confluence를 새로 설치하기

새로 설치하는 Confluence는 현재 사용하는 Confluence와 같은 버전이어야 한다. 그러나 설치 위치와 홈 디렉토리는 달라져야 한다. 다음과 같이 작업한다.

1. 현재 사용하는 Confluence를 종료한다.

2. 마이그레이션에 실패할 시 빠르게 원래대로 복구하기 위해 기존 Confluence의 설치 파일과 홈 디렉토리의 이름을 변경해 둔다.

# mv /opt/share/confluence /opt/share/confluence-old
# mv /var/local/lib/confluence /var/local/lib/confluence-old

3. 새 Confluence를 위한 홈 디렉토리를 생성한다.

# mkdir /var/local/lib/confluence
# cd /var/local/lib
# chown confluence:confluence confluence
# chmod g-s confluence

라인 4는 스티키 비트(sticky bit)를 사용하지 않으므로 제거한 것이다. 데비안에서 /var/local 디렉토리의 그룹에 스티키 비트가 있어 /var/local/lib/confluence 디렉토리에 스티키 비트가 붙는다. 여러분이 다른 Confluence 홈 디렉토리를 사용한다면 무시하고 넘어간다.

4. 기존 Confluece와 같은 버전의 TAR.GZ 압축 파일을 /opt/share에 복사한 후 다음의 절차로 /opt/share/confluece에 위치하도록 압축을 푼다.

# cd /opt/share
# tar zxvf atlassian-confluence-6.13.8.tar.gz
# mv atlassian-confluence-6.13.8 confluence
# chown -R root:root confluence
# chown -R confluence:confluence confluence/logs
# chown -R confluence:confluence confluence/temp
# chown -R confluence:confluence confluence/work

라인 4에서 7까지 파일의 소유주와 그룹을 설정하는 이유는 보안 때문이다. Confluence 데몬이 쓰기 권한을 가져야만 하는 logs, temp, work 디렉토리 이외에는 파일을 저장할 수 없도록 한다. 데몬(서비스)의 보안에 관해서는 Confluence, Jira, Bitbucket의 systemd unit 설정에서 볼 수 있다.

5. /opt/share/confluence/confluence/WEB-INF/classes/confluence-init.properties 파일에서 다음과 같이 Confluence Home Directory를 지정한다.

confluence.home=/var/local/lib/confluence

6. (선택적) Confluence에 접속할 때 웹 브라우저에 따라 언어를 설정하지 않도록 /opt/share/confluence/bin/setenv.sh 파일에 다음의 내용을 추가한다. Confluence에서 언어를 영어로 선택하여 항상 영문 메뉴가 나오도록 하기 위한 것이다.

CATALINA_OPTS="-Dconfluence.browser.language.enabled=false ${CATALINA_OPTS}"

단계 5. Confluence Setup Wizard를 진행하여 PostgreSQL로 마이그레이션 하기

1. 새로 설치한 Confluence 서버를 시작한 후 웹 브라우저로 http://192.168.1.10:8090/에 접속하여 Confluence setup wizard를 진행한다. IP 주소는 여러분에게 맞는 것으로 변경한다.

2. Get apps에서 Production Installation을 선택하고 Next 버튼을 클릭한다. Apps extend what Confluence can do. …에서 Confluece Questions, Confluece Team Calendars를 디폴트인 선택하지 않은 상태를 그대로 둔 채 Next 버튼을 클릭한다.

3. License key에서 Confluence의 라이센스를 입력하고 Next 버튼을 클릭한다. (https://my.atlassian.com/에 접속하여 라이센스 키를 복사할 수 있다.)

4. Set up your database에서 디폴트 선택인 My own database 선택을 그대로 둔 채 Next 버튼을 클릭한다. 다음의 설정을 한 후 Test connection 버튼을 클릭한다. 데이터베이스 연결에 성공한 메시지가 나오면 Next 버튼을 클릭한다.

• Database type: 디폴트 선택인 PostgreSQL을 그대로 둔다.
• Setup type: 디폴트 선택인 Simple을 그대로 둔다.
• Hostname: PostgreSQL이 설치된 시스템의 로컬 IP 주소를 입력한다. (예: 192.168.1.10)
• Post: 5432를 입력한다.
• Database name: 위에서 생성한 데이터베이스의 이름인 confluecne를 입력한다.
• Username: 위에서 생성한 데이터베이스의 사용자 이름인 confluence를 입력한다.
• Password: 위에서 생성한 데이터베이스의 ‘암호’를 입력한다.

5. Load Content에서 Restore From Backup 버튼을 클릭한다.

6. Restore Data 화면에서 Import form the home directory로 작업한다. 복원할 xmlexport-20200524-215026-2.zip 파일의 크기가 25MB보다 크기 때문이다.

6.1. 새로 설치한 Confluence 홈 디렉토리의 restore 디렉토리로 단계 2에서 생성한 xmlexport-20200524-215026-2.zip 파일을 복사하기 위해 다음의 명령어를 실행한다.

# cp -a /var/local/lib/confluence-old/temp/xmlexport-20200524-215026-2.zip /var/local/lib/confluence/restore/

cp의 -a 옵션은 파일의 속성인 소유자, 생성 날짜 등을 유지한 채 복사하기 위한 것이다.

6.2. 복사를 완료하였으면 Import from the home directory의 Import 버튼을 클릭한다. 에러 메시지와 함께 xmlexport-20200524-215026-2.zip 파일이 보이면 선택하고 다시 한번 Import 버튼을 클릭한다.

6.3. Restore 과정이 진행된다. Restore 과정이 끝난 후 Next 버튼을 클릭한다.

7. Setup Successful 화면에서 Start 버튼을 클릭한다.

단계 6. Atlassian Marketplace 앱을 다시 설치하기

단계 1에서 메모해 두었던 앱들을 같은 버전으로 다시 설치한다. Confluence 설정으로 들어가서 ATLASSIAN MARKETPLACE > Find new apps에서 앱을 검색할 수 있다. Atlassian이 제공하는 앱은 이미 설치되어 있으므로 간단하게 Update만 한다.

단계 7. 새로 설치한 Confluence를 위한 설정을 한다.

도메인의 URL 주소로 접속하기 위해 /opt/share/confluence/conf/server.xml 파일을 수정한다. 나의 경우 Apache의 Proxy를 사용하기 때문에 다음과 같이 한다.

<Context> 지시자의 path를 /confluence로 설정한다.

<Context path="/confluence" docBase="../confluence" debug="0" reloadable="false" useHttpOnly="true">

디폴트 <Connector> 지시자는 주석 처리한다. HTTS 상의 Proxying인 <Connector> 지시자의 주석을 제거하고 proxyName을 www.bitneer.dev로 변경한다.

<Connector port="8090" connectionTimeout="20000" redirectPort="8443"
           maxThreads="48" minSpareThreads="10"
           enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           scheme="https" secure="true" proxyName="www.bitneer.dev" proxyPort="443"/>

Confluence를 다시 시작하고 웹 브라우저로 Confluence에 접속한다. Confluence 설정에 들어가서 CONFIGURATION > General Configuration의 Server Base URL을 도메인 주소에 맞게 설정한다.

단계 8. 문제 점검 및 기존 파일 삭제하기

다음의 명령어를 실행한 후 다른 ssh 연결 세션에서 Confluence를 시작, 종료하면서 발생하는 로그를 검사한다.

# tail -100f /var/local/lib/confluence/logs/atlassian-confluence.log

위의 atlassian-confluence.log에 Error 로그가 보인다면 Confluence 설정의 ADMINISTRATION > Troubleshooting and support tools의 Log analyzer에서 문제를 해결할 수 있는지 확인한다. 해당 Error 로그를 클릭하면 해결책을 제시하는 페이지에 접속할 수 있다.

Confluence 설정의 ADMINISTRATION > Troubleshooting and support tools의 Instance heath에 문제가 있는지 확인한다. atlassian-confluence.log에 Error 로그가 나오더라도 Instance heath에서 모든 항목이 초록색으로 표시되어 있고 Log analyzer에 해당 Error 로그가 나오지 않는다면 Confluence 사용에 크게 문제를 일으키지는 않는 것으로 보인다.

MySQL에서 PostgreSQL로 마이그레이션에 성공하였다면 기존의 Confluence 관련 파일을 삭제한다.

# cd /opt/share/
# rm -rf confluence-old
# rm atlassian-confluence-6.13.8.tar.gz
# cd /var/local/lib/
# rm -rf confluence-old

관련 글

• Confluence, Jira, Bitbucket의 systemd unit 설정

참고 자료

• Supported Platforms – Confluence 6.13
• Migrating to Another Database – Confluence 6.13
• Database Setup for PostgreSQL – Confluence 6.13

The post Confluence 서버의 MySQL을 PostgreSQL로 마이그레이션 하기 appeared first on bitneer.dev.

단계 1. XML 포맷으로 Data를 백업하기

Jira 서버에서 제공하는 백업 도구를 사용하여 XML 포맷의 파일로 Data를 백업한다. 백업한 파일은 단계 4에서 PostgreSQL로 마이그레이션 하기 위해 사용할 것이다.

1. Jira의 환경 설정인 System으로 들어한다.
2. IMPORT AND EXPORT의 Backup System을 클릭한다.
3. Backup Jira data 화면에 ‘데이터베이스의 내용을 XML 포맷으로 백업할 것이고 Jira 홈 디렉토리 안의 export 디렉토리에 저장할 것’이라고 나온다. File name에 백업할 파일의 이름을 입력하고 Backup 버튼을 클릭한다. 나는 jira_backup으로 입력하였다.
4. 실행을 완료하면 자신이 입력한 파일명에 .zip 확장자를 붙여 내보냈음을 알려준다. 나의 경우 /var/local/lib/jira/export/jira_backup.zip 파일로 저장되었다.

단계 2. PostgreSQL의 데이터베이스 만들기

Jira 서버에서 사용할 PostgreSQL 데이터베이스를 만든다. 다음은 psql 클라이언트를 사용한 진행 과정이다.

# psql -h localhost -U postgres -d postgres
psql (9.6.17)
SSL 연결정보 (프로토콜: TLSv1.2, 암호화기법: ECDHE-RSA-AES256-GCM-SHA384, 비트: 256, 압축: off)
도움말을 보려면 "help"를 입력하십시오.

postgres=# CREATE ROLE jira WITH LOGIN PASSWORD '암호 입력';
CREATE ROLE
postgres=# CREATE DATABASE jira WITH OWNER=jira ENCODING 'UTF8' LC_COLLATE 'C' LC_CTYPE 'C' TEMPLATE template0;
CREATE DATABASE
postgres=# \l
                                 데이터베이스 목록
   이름    |  소유주  | 인코딩 |   Collate   |    Ctype    |      액세스 권한
-----------+----------+--------+-------------+-------------+-----------------------
 jira      | jira     | UTF8   | C           | C           |
 postgres  | postgres | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 template0 | postgres | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
           |          |        |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
           |          |        |             |             | postgres=CTc/postgres
(4개 행)

라인 6에서 CREATE ROLE로 jira 사용자를 생성했다. 라인 8에서 CREATE DATABASE로 jira 데이터베이스를 만들었다. 주의해야 할 것은 Jira 서버는 LC_COLLATE와 LC_CTYPE을 ‘C’로 설정해야 한다. 새 로케일로 데이터베이스를 만들려면 template0을 사용해야 한다. 라인 10에서 \l 명령어로 새로 만든 jira 데이터베이스를 확인한다. PostgreSQL의 기본적인 사용은 PostgreSQL의 데이터베이스와 사용자 생성, 백업 및 복구를 참고할 수 있다.

단계 3. JIRA setup을 실행하기 위한 준비

Jira 서버의 설치 화면(JIRA setup)으로 진입하기 위한 작업을 한다.

1. Jira 서버를 종료한다.
2. 서버 종료 뒤가 백업의 적기이다. 현재 사용하고 있는 MySQL의 Jira 데이터베이스와 Jira 홈 디렉토리를 백업해 둔다.
3. Jira 홈 디렉토리(/var/local/lib/jira) 안의 dbconfig.xml 파일을 삭제한다. 이 파일의 삭제로 JIRA setup으로 진입하는 것이다.

단계 4. JIRA setup을 사용하여 PostgreSQL로 마이그레이션 하기

Jira 서버를 다시 시작하고 웹 브라우저로 접속하면 JIRA setup 화면이 나올 것이다. PostgreSQL로 마이그레이션 하기 위해 다음과 같이 작업한다.

1. Jira 설치 화면이 나오면 ‘직접 설정하겠습니다.‘를 선택하고 다음 버튼을 클릭한다.
2. 데이터베이스 설정 화면이 나오면 내 데이터베이스(운영 환경에 권장)을 선택하고 다음의 내용을 입력한다.
   • 데이터베이스 유형: PostgreSQL
   • 호스트 이름: PostgreSQL을 설치한 시스템의 로컬 IP 주소를 입력한다. (예: 192.168.1.20)
   • 포트: 디폴트 값인 5432를 그대로 둔다.
   • 데이터베이스: 위에서 생성한 데이터베이스의 이름인 jira를 입력한다.
   • 사용자 아이디: 위에서 생성한 데이터베이스의 사용자 이름인 jira를 입력한다.
   • 비밀번호: 위에서 생성한 데이터베이스의 ‘암호’를 입력한다.
   • 스키마: 디폴트 값인 public을 그대로 둔다.
3. 다음 버튼을 클릭한다.
4. 응용프로그램 속성을 설정하십시오. 화면에서 ‘… 데이터를 가져올 수 있습니다.‘를 클릭한다.
5. 기존 데이터 가져오기 화면의 파일 이름에 단계 1에서 생성한 /var/local/lib/jira/export/jira_backup.zip을 입력하고 가져오기 버튼을 클릭한다.

가져오기 작업이 끝나면 Jira의 Dashboards 화면이 나온다.

데이터베이스의 마이그레이션 확인하기

Jira 홈 디렉토리 안에 dbconfig.xml 파일이 새로 생성되고, PostgreSQL의 JDBC 설정을 볼 수 있다.

참고 자료

• Administering Jira Server 7.13 applications
  • Supported platforms – Jira Server 7.13
  • Switching databases
  • Backing up data
  • Connecting Jira applications to PostgreSQL
• 템플릿 데이터베이스 – PostgreSQL 9.6.2 문서 22장 데이터베이스 관리

The post Jira 서버의 MySQL을 PostgreSQL로 마이그레이션 하기 appeared first on bitneer.dev.

오라클의 엄격해진 라이센스 정책으로 Java, MySQL, VirtualBox 등이 데비안의 패키지 대상에서 빠져나갔다. 데비안과 그 시스템에 설치한 Atlassian 제품인 Confluence, Jira, Bitbucket을 업그레이드할 때 신경이 쓰이고 손이 많이 간다. 좀 더 쉬운 관리를 위해 Oracle Java는 OpenJDK로 MySQL은 PostgreSQL로 변경하기로 마음먹고 작업을 진행하였다. Bitbucket 서버처럼 Atlassian 제품을 설치할 때나 업그레이드할 때 항상 문서 웹 페이지를 확인할 필요가 있다. Java, 데이터베이스에 대한 지원 정보는 필수적으로 보아야 한다. 내가 사용하고 있는 Bitbucket 서버 버전이 4.10.1이고 Supported platforms – Bitbucket Server 4.10.x에 나오는 지원 정보는 다음과 같다.

• OpenJDK: 1.8u40+, 1.8u0 – 1.8u20
• PostgreSQL: 9.2 – 9.5

사용하고 있는 데비안 9(stretch)에서 PostgreSQL 9.6을 사용한다. MySQL을 PostgreSQL로 마이그레이션할 때 문제가 발생할 것으로 보인다. Supported platforms – Bitbucket Server 7.2.x에 나오는 최신 버전의 지원 정보는 다음과 같다.

• Oracle Java & OpenJDK : Java 11, Java 8 (1.8u65+) – OpenJDK는 AdoptOpenJDK의 Java 8 JRE 권장
• PostgreSQL: 9.4 – 11

PostgreSQL 9.6을 지원하므로 먼저 Bitbucket 7.2로 업그레이드하고 MySQL을 PostgreSQL로 마이그레이션할 것이다. 4 버전에서 7 버전으로 차이가 크게 나는 버전 업그레이드이기 때문에 문서를 꼼꼼히 볼 필요가 있다. 특히 Upgrade Bitbucket Server from an archive file과 Migrate server.xml customizations to bitbucket.properties 두 페이지를 주의 깊게 보아야 한다. Bitbucket 5부터 server.xml의 설정을 bitbucket.properties 파일에 하도록 변경하였기 때문이다. 아래에서 이에 관한 내용을 살펴볼 것이다.

OpenJDK는 Confluence, Jira, Bitbucket의 지원 정보를 종합적으로 고려하면 AdoptOpenJDK의 Java 8 (HotSpot)이 제일 나은 선택이다. AdoptOpenJDK 설치는 데비안에 AdoptOpenJDK 설치하기에서 다룬다.

Bitbucket 서버 업그레이드 절차

사용자의 데이터가 지속해서 쌓이는 Bitbucket과 같은 Atlassian 제품들은 한 번 설치 후 그 과정은 잊힌다. 사용자의 데이터를 유지하면서 새로운 기능을 사용하기 위한 업그레이드로 관심이 옮겨가는 것이다. 나는 Bitbucket으로 이름이 바뀌기 전 Stash부터 주기적으로 업그레이드해 왔다. 자잘한 문제가 있었기는 하지만 전반적으로 부드럽게 업그레이드할 수 있었다.

업그레이드는 한 번 하고 끝나는 것이 아니므로 그 절차를 정리해 둘 필요가 있다. 다음의 절차는 업그레이드할 때마다 참고하기 위해 정리했다. 내가 Bitbucket을 설치한 디렉토리는 /opt/share/bitbucket이고 Bitbucket 홈 디렉토리는 /var/local/lib/bitbucket이다. 설치 파일은 TAR.GZ 압축 파일을 사용한다. 여러분에게 맞게 적용하자.

1. 위에서 보았듯이 지원하는 Java와 데이터베이스의 버전을 확인한다. 업그레이드 문서에서 이슈가 발생할 만한 것이 없는지도 찾아본다.
2. 다음의 명령어 실행으로 Bitbucket을 종료한다.

   # systemctl stop bitbucket.service
   

3. 데이터베이스와 Bitbucket의 홈 디렉토리를 백업한다. 나의 경우 데이터베이스를 포함해서 서버 전체를 백업하는 스크립트를 사용한다.
4. 다음의 명령어로 기존 버전의 bitbucket의 이름을 변경한다.

   # mv /opt/share/bitbucket /opt/share/bitbucket-old
   

5. Download Bitbucket Server에서 TAR.GZ Archive 설치 파일을 다운로드한다.
6. 다운로드한 Bitbucket 압축 파일을 /opt/share로 복사한 후 다음의 절차로 /opt/share/bitbucket에 위치하도록 압축을 푼다.

   # cd /opt/share
   # tar zxvf atlassian-bitbucket-<version>.tar.gz
   # mv atlassian-bitbucket-<version> bitbucket
   # chown -R bitbucket:bitbucket bitbucket
   

7. 다음의 명령어로 Bitbucket을 시작한다.

   # systemctl start bitbucket.service
   

8. 웹 브라우저로 새로 설치한 Bitbucket에 접속하여 테스트해 본다. 새로운 버전에 문제가 없으면 다음과 같이 다운로드 받았던 TAR.GZ Archive 설치 파일과 기존의 Bitbucket을 삭제한다.

   # rm atlassian-bitbucket-<version>.tar.gz
   # rm -rf bitbucket-old
   

Bitbucket 버전 4.10.x에서 7.2.x로 업그레이드 시 주의 사항

위의 업그레이드 절차는 미래를 위한 것이다. Bitbucket 서버를 4.10.1에서 7.2.3으로 업그레이드하면서 변경한 내용을 반영한 것이다. 7.2.3 이상의 버전으로 업그레이드할 때 유효하다. 그 이전 버전, 특히 5.0 이전에서 업그레이드하려 한다면 주의해야 한다. Confluence, Jira, Bitbucket의 systemd unit 설정에서 설치 디렉토리와 systemd unit 설정에 대해 다루었는데 Bitbucket 서버 4.10.1을 기반한 것이다. 버전 7.2.3에서 많은 변경이 있다. 내가 직면했던 사항들을 정리해 본다.

1. Bitbucket 서비스의 쓰기 권한이 필요했던 /opt/share/bitbucket 안의 다음 디렉토리가 더는 존재하지 않는다.

• logs
• temp
• work

How to View Detailed permissions for Bitbucket Server directory에서 설치 디렉토리의 사용자와 그룹을 bitbucket이 소유하도록 하고 있다. 그래서 위의 Bitbucket 서버 업그레이드 절차 6.의 라인 4에서 그렇게 했다.

2. Bitbucket 서버 업그레이드 시 발생한 변경 사항들 때문에 systemd unit 설정 파일을 다음과 같이 수정하였다.

[Unit]
Description=Atlassian Bitbucket
After=network.target

[Service]
Type=forking
User=bitbucket
UMask=0027
Environment="BITBUCKET_HOME=/var/local/lib/bitbucket" "JRE_HOME=/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64"
PIDFile=/var/local/lib/bitbucket/log/bitbucket.pid
SuccessExitStatus=143
ExecStart=/opt/share/bitbucket/bin/start-bitbucket.sh --no-search
ExecStop=/opt/share/bitbucket/bin/stop-bitbucket.sh

[Install]
WantedBy=multi-user.target

2.1. PID 파일의 위치가 /opt/share/bitbucket/work/catalina.pid에서 /var/local/lib/bitbucket/log/bitbucket.pid로 변경되었다. 라인 10에서 이를 반영하여 변경하였다.

2.2. ‘systemctl stop bitbucket’ 명령어로 Bitbucket 서비스를 종료하고 ‘systemctl status bitbucket’으로 상태를 확인하면 다음과 같이 종료가 실패하였다는 메시지가 나왔다.

... systemd[1]: bitbucket.service: Main process exited, code=exited, status=143/n/a
... stop-bitbucket.sh[2487]: The Bitbucket webapp has stopped
... systemd[1]: Stopped Atlassian Bitbucket.
... systemd[1]: bitbucket.service: Unit entered failed state.
... systemd[1]: bitbucket.service: Failed with result 'exit-code'.

stop-bitbucket.sh 스크립트의 종료 처리가 미비한 것으로 보인다. 위의 라인 1에서 나온 상태(status) 값 143을 정상적인 종료라고 systemd에게 알려줄 필요가 있다. systemd unit 설정 파일의 라인 11에서 SuccessExitStatus 지시자의 값을 143으로 설정하였다.

2.3. /opt/share/bitbucket/bin 디렉토리 안의 set-bitbucket-home.sh, set-jre-home.sh 스크립트 파일을 보면 환경 변수로 BITBUCKET_HOME과 JRE_HOME을 설정할 수 있다. 그래서 라인 9의 Environment 지시자에 환경 변수 값을 설정하여 넘겨주도록 하였다. 이후 업그레이드를 할 때 set-bitbucket-home.sh, set-jre-home.sh 파일에 BITBUCKET_HOME과 JRE_HOME을 설정하는 귀찮은 작업이 없어질 것이다.

2.4. Bitbucket에 딸려 오는 Elasticsearch를 사용하지 않을 것이기 때문에 라인 12에서 –no-search를 추가하였다.

2.5. Bitbucket 서비스를 실행할 때 umask로 0027을 권장하고 있다. 즉, 사용자와 그룹이 아닌 다른 사용자에게 읽기와 쓰기 권한을 주지 말라고 하는 것이다. 라인 8에서 UMask 지시자를 0027로 설정하였다. 이 설정으로 Bitbucket 서비스가 생성하는 파일은 다른 사용자가 읽거나 쓸 수 없을 것이다. 일관성을 위해 다음의 명령어를 실행하여 Bitbucket 홈 디렉토리의 권한을 변경하였다.

# chmod -R o-rwx /var/local/lib/bitbucket

3. Bitbucket 5부터 server.xml의 설정이 bitbucket.properties로 옮겨졌다. 내가 server.xml에서 설정했던 Proxy 관련 설정 등을 /var/local/lib/bitbucket/shared/bitbucket.properties 파일에 다음과 같이 추가하였다.

server.context-path=/bitbucket
server.secure=true
server.scheme=https
server.proxy-port=443
server.proxy-name=www.bitneer.dev

4. MySQL에서 PostgreSQL로 변경하면서 Download Connector/J에서 받은 MySQL JDBC 드라이버를 /opt/share/bitbucket/lib 또는 /opt/share/bitbucket/app/WEB-INF/lib 디렉토리로 복사해야 하는 번거로운 작업이 하나 줄었다.

관련 글

• Confluence, Jira, Bitbucket의 systemd unit 설정
• 데비안에 AdoptOpenJDK 설치하기
• Bitbucket 서버의 MySQL을 PostgreSQL로 마이그레이션 하기

참고 자료

• Supported platforms – Bitbucket Server 4.10.x
• Supported platforms – Bitbucket Server 7.2.x
• Supported Platforms – Confluence 7.4
• Supported platforms – Jira 8.8
• Upgrade Bitbucket Server from an archive file
• Migrate server.xml customizations to bitbucket.properties
• Instead of init.d use systemctl
• “bitbucket-stop.sh” does not support “–no-search”

The post Bitbucket 서버 업그레이드하기 appeared first on bitneer.dev.

PostgreSQL에서 데이터베이스 만들기

Bitbucket 서버에서 사용할 PostgreSQL의 데이터베이스를 만든다. 다음은 psql 클라이언트를 사용한 진행 과정이다.

# psql -h localhost -U postgres -d postgres
psql (9.6.17)
SSL 연결정보 (프로토콜: TLSv1.2, 암호화기법: ECDHE-RSA-AES256-GCM-SHA384, 비트: 256, 압축: off)
도움말을 보려면 "help"를 입력하십시오.

postgres=# CREATE ROLE bitbucket WITH LOGIN PASSWORD '원하는 암호 입력';
CREATE ROLE
postgres=# CREATE DATABASE bitbucket WITH ENCODING='UTF8' OWNER=bitbucket;
CREATE DATABASE
postgres=# \l
                                  데이터베이스 목록
    이름    |   소유주   | 인코딩 |   Collate   |    Ctype    |      액세스 권한
------------+------------+--------+-------------+-------------+-----------------------
 bitbucket  | bitbucket  | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 confluence | confluence | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 jira       | jira       | UTF8   | C           | C           |
 postgres   | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 |
 template0  | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
            |            |        |             |             | postgres=CTc/postgres
 template1  | postgres   | UTF8   | ko_KR.UTF-8 | ko_KR.UTF-8 | =c/postgres          +
            |            |        |             |             | postgres=CTc/postgres
(6개 행)

postgres=#

라인 6에서 CREATE ROLE로 bitbucket 사용자를 만든다. 라인 8에서 CREATE DATABASE로 bitbucket 데이터베이스를 생성한다. Bitbucket의 데이터베이스는 UTF-8 문자 집합을 사용하도록 설정해야 한다. 라인 10에서 \l 명령어로 새로 생성한 bitbucket 데이터베이스를 확인한다. PostgreSQL의 기본적인 사용은 PostgreSQL의 데이터베이스와 사용자 생성, 백업 및 복구에서 다루었다.

Database Migration Wizard를 사용하여 데이터베이스 마이그레이션 하기

웹 브라우저로 Bitbucket 서버에 접속한다. 설정 아이콘을 클릭하여 Administration 페이지로 들어간 후 다음의 작업을 진행한다.

1. Settings > Database를 클릭한다.

2. Migrate database 버튼을 클릭한다.

3. Migrate Database에서 다음의 설정을 한다.

• Database Type: 디폴트 선택인 PostgreSQL을 그대로 둔다.
• Hostname; PostgreSQL을 설치한 시스템의 로컬 IP 주소를 입력한다. (예: 192.168.1.10)
• Port: PostgreSQL의 포트를 변경하지 않았다면 디폴트 값을 그대로 둔다.
• Database name: 위에서 생성한 데이터베이스의 이름인 bitbucket을 입력한다.
• Database username: 위에서 생성한 데이터베이스의 사용자 이름인 bitbucket을 입력한다.
• Database password: 위에서 생성한 데이터베이스의 ‘암호’를 입력한다.

설정을 마친 후 Start Migration 버튼을 클릭하면 마이그레이션을 진행한다.

4. 마이그레이션 진행을 완료하면 성공 메시지가 나온다.

데이터베이스의 마이그레이션 확인하기

PostgreSQL로 변경했는지 확인하려면 Bitbucket 홈 디렉토리의 bitbucket.properties 파일을 본다. 파일 경로는 /var/local/lib/bitbucket/shared/bitbucket.properties이다. 파일에서 MySQL의 JDBC 설정은 주석으로 처리하고 PostgreSQL을 추가한 것을 볼 수 있을 것이다.

Database Migration Wizard는 마이그레이션할 때 dump 파일을 생성한다. /var/local/lib/bitbucket/export 디렉토리 안에 .zip 확장자로 만들어지는데 삭제하여도 무방하다.

참고 자료

• Supported platforms – Bitbucket Server 7.2.x
• Connecting Bitbucket Server to PostgreSQL
• Connecting Bitbucket Server to an external database

The post Bitbucket 서버의 MySQL을 PostgreSQL로 마이그레이션 하기 appeared first on bitneer.dev.

데비안 8(Jessie)에서 systemd가 디폴트 시작 시스템으로 완전히 들어왔다. 한동안 데비안 7(Wheezy)에서 업그레이드를 해야 할지 주저했던 기억이 난다. 그러나 systemd는 SysV 스크립트 파일을 분석하고 변환하는 방식으로 하위 호환성을 제공하였다. 내가 작성한 구식의 스크립트는 살아남을 수 있었다.

최근에 MySQL에서 PostgreSQL로 옮기는 작업을 진행하면서 init.d 스크립트도 버리기로 하였다. 관리의 측면에서 Confluence, Jira, Bitbucket의 서비스 설정은 init.d 스크립트보다는 systemd unit 설정 파일이 더 낫다. 업그레이드되면서 환경 변수 등이 변한다면 init.d 스크립트도 이를 반영해야 할 경우가 생기기 때문이다.

사용자와 그룹 생성

보안상의 이유로 데몬(서비스)은 root 관리자 계정으로 실행하지 말아야 한다. 보안 취약점을 이용하여 악의적인 사용자가 root 권한이 있는 데몬을 사용한다면 시스템에 재앙을 가져온다. 따라서 서비스는 일반 사용자로 실행하여야 한다.

Confluence 서비스에서 사용할 confluence 그룹과 confluence 사용자를 생성하기 위해 다음과 같이 한다.

# groupadd confluence
# useradd confluence -M -g confluence -d /opt/share/confluence -s /bin/false

위의 useradd 명령어에서 -d 옵션으로 홈 디렉토리는 지정하지만 -M 옵션으로 홈 디렉토리를 생성하지 않는다. confluence 사용자는 서비스 실행만을 위해 존재하기 때문에 홈 디렉토리를 생성할 필요는 없다. 마찬가지로 로그인 시 사용할 쉘을 지정하는 -s 옵션에서 /bin/false로 하여 로그인을 허용하지 않는다. jira와 bitbucket도 위의 confluence가 나온 부분을 대체하여 사용자와 그룹을 만들어 줄 수 있다.

데비안의 tomcat6 패키지와 비교해 보자.

# cat /etc/passwd | grep tomcat6
tomcat6:x:109:115::/usr/share/tomcat6:/bin/false
# cat /etc/passwd | grep confluence
confluence:x:1002:1002::/opt/share/confluence:/bin/false

사용자와 그룹을 한꺼번에 삭제하고 싶다면 ‘deluser’ 명령어를 사용한다. 다음의 명령어는 stash 사용자와 그룹을 한 번에 제거한다.

# deluser stash

설치 디렉토리와 홈 디렉토리

Confluence, Jira, Bitbucket을 어느 디렉토리에 설치하는 것이 좋을까? 데비안 개발자가 패키지를 만들면서 신경 쓰지 않는 /opt, /srv, /usr/local, /home 디렉토리가 적당해 보인다. 나는 위의 사용자 생성에서 보듯이 /opt/share 디렉토리 안에 confluence, jira, bitbucket으로 선택했다. 데비안에서 운영체제에 종속적이지 않은 Tomcat 같은 패키지는 /usr/share 디렉토리에 들어간다. 그래서 /opt/share로 하였다. 이것은 취향의 문제로 여러분은 다른 곳에 설치할 수 있다.

보안 측면을 짚어 보기 위해 좀 더 살펴본다. Download Confluence Server, Download Jira Software Server, Download Bitbucket Server에서 TAR.GZ Archive 파일을 다운로드 할 수 있다. 다운로드한 파일을 /opt/share로 복사한 후 다음의 작업을 한다. 여기서는 Confluence만 예제로 보인다. Jira와 Bitbucket도 confluence가 나온 부분을 jira와 bitbucket으로 변경하여 같은 작업을 할 수 있다.

# cd /opt/share
# tar zxvf atlassian-confluence-<version>.tar.gz
# mv atlassian-confluence-<version> confluence
# chown -R root:root confluence
# chown -R confluence:confluence confluence/logs
# chown -R confluence:confluence confluence/temp
# chown -R confluence:confluence confluence/work

보안을 강화하기 위해 라인 4에서 7까지 파일의 소유자와 그룹을 설정하였다. confluence 사용자로 실행하는 Confluence 데몬은 logs, temp, work 디렉토리에만 쓰기 권한을 가진다. 다른 곳은 사용자와 그룹을 root 소유로 설정하였기 때문에 confluence 사용자로 실행하는 서비스는 파일을 저장할 수 없다.

데비안의 Tomcat 패키지 방식으로 하려면 몇 가지 작업을 더 해야 한다. logs, work 디렉토리는 /var/lib/confluence 안에 들어가야 하고 temp 디렉토리는 /tmp 안에 위치해야 한다. 그러나 이 디렉토리들은 중요도가 떨어지고 업그레이드할 때마다 해주기 번거롭기 때문에 그렇게까지는 하지 않았다.

Confluence, Jira, Bitbucket은 데이터를 사용자가 설정하는 홈 디렉토리에 저장한다. 어디로 설정하는 것이 좋을까? /var 디렉토리는 변하는 데이터를 저장하는 곳이기에 적당하다. 데비안의 패키지는 /var/lib 디렉토리를 사용한다. 나는 /var/local/lib 디렉토리 안의 confluence, jira, bitbucket으로 설정했다. /var/local은 데비안 개발자가 관심을 두지 않는 곳이기 때문에 선택했다. 이 역시 취향 문제다.

Confluence의 홈 디렉토리를 생성하기 위해 다음과 같이 한다. Jira와 Bitbucket도 confluence가 나온 부분을 변경하여 같은 작업을 할 수 있다.

# mkdir -p /var/local/lib/confluence
# cd /var/local/lib
# chown confluence:confluence confluence
# chmod g-s confluence

mkdir 명령어의 -p 옵션은 상위 디렉토리인 lib가 존재하지 않을 때 생성하라는 의미이다. 라인 3에서 confluence 사용자로 실행하는 Confluence 데몬이 쓸 수 있도록 사용자와 그룹의 소유주를 confluence로 설정한다. 라인 4는 /var/local/lib/confluence 디렉토리의 스티키 비트(sticky bit)를 사용하지 않으므로 제거한 것이다. 데비안에서 /var/local 디렉토리는 그룹에 스티키 비트가 설정되어 있어서 디렉토리나 파일을 생성하면 스티키 비트가 붙는다.

추가로 데이터베이스를 만들고 홈 디렉토리 설정 등을 한다면 Confluence, Jira, Bitbucket을 설치할 준비를 마친 것이다. 이제 이 글의 주제인 systemd unit 설정으로 넘어가자.

systemd unit 설정

시스템의 전원을 켜면 복잡한 여러 부트 단계를 거쳐 PID=1을 가지는 init 프로그램이 실행된다. init 프로그램은 모든 프로세스의 최상위 조상이고 시작 시 필요한 프로그램을 실행한다. 데비안 jessie 이후로 init 프로그램인 /sbin/init은 /lib/systemd/systemd에 대한 심볼릭 링크이다. systemd init 프로세스는 다음의 디렉토리에서 unit 설정 파일을 읽어 들여 병렬적(parallel)으로 프로세스들을 생산한다. 병렬적이기 때문에 기존의 순차적인 SysV init보다 빠르다.

• /lib/systemd/system : 운영체제의 디폴트 설정 파일
• /etc/systemd/system : 시스템 관리자의 설정 파일
• /run/systemd/system : 실행 시간에 만들어지는 설정 파일

unit 설정 파일의 접미사에 따라 서비스(.service), 장치(.device), 마운트(.mount), unit 설정 파일의 그룹(.target) 등 다양한 타입이 있다. Confluence, Jira, Bitbucket의 서비스를 위해 /etc/systemd/system 디렉토리 안에 .service로 끝나는 unit 설정 파일을 만들 것이다.

Confluence의 unit 설정 파일인 /etc/systemd/system/confluence.service의 내용은 다음과 같다.

[Unit]
Description=Atlassian Confluence
After=network.target

[Service]
Type=forking
User=confluence
PIDFile=/opt/share/confluence/work/catalina.pid
ExecStart=/opt/share/confluence/bin/start-confluence.sh
ExecStop=/opt/share/confluence/bin/stop-confluence.sh

[Install]
WantedBy=multi-user.target

프로그램의 흐름을 따라가는 절차적인 SysV init 스크립트와 비교하면 unit 설정 파일은 선언적으로 이해하기 쉽다. unit 설정 파일은 윈도우 운영체제의 .ini 확장자를 지닌 설정 파일에서 사용하는 문법을 사용한다. 대괄호의 절(section)로 시작하여 한 줄마다 ‘변수=값’으로 이루어진다. 변수는 지시자(directive)라 부른다. unit 설정 파일은 [Unit], [Install] 절을 기본적으로 가져야 한다. 서비스 unit 설정 파일은 추가로 [Service] 절을 반드시 포함해야 한다.

[Unit] 절은 unit의 일반적인 정보를 지닌다. 라인 2의 Description 지시자에는 unit의 원하는 이름을 넣어준다. 종속성 지시자인 After는 먼저 실행돼야 하는 unit을 지정한다. Confluence는 웹 서버이므로 시스템의 네트워크 설정이 먼저 이루어지는 것이 필요하다. 따라서 라인 3에서 네트워크 관련 unit들은 모아 놓은 network.target을 설정한다.

[Install] 절은 unit을 설치하기 위한 정보로 systemd가 사용하지 않는다. 아래에서 볼 systemctl의 enable과 disable에서 이 절을 사용하여 심볼릭 링크를 만들거나 삭제한다. SysV의 런레벨과 비슷한 것으로 multi-user.target은 런레벨 2에서 4에 해당한다. ‘ls -al /lib/systemd/system/runlevel*‘ 명령어로 확인해 볼 수 있다.

[Service] 절은 서비스 unit을 위한 것이다. 라인 6의 Type=forking은 라인 9의 ExecStart에서 설정한 start-confluence.sh가 fork()를 호출할 것임을 의미한다. 전통적인 UNIX 서비스가 행동하는 방식으로 Tomcat도 이처럼 한다. Type을 forking으로 한다면 PIDFile의 설정을 권고하고 있다. 라인 8에서 Confluence가 사용하는 Tomcat의 PID 파일의 위치를 설정한다. 라인 10의 ExecStop에서 서비스 종료에 사용할 파일을 지정한다. 라인 7에서 서비스를 실행할 사용자로 confluence를 설정한다.

Jira의 unit 설정 파일은 다음과 같다.

[Unit]
Description=Atlassian Jira
After=network.target

[Service]
Type=forking
User=jira
PIDFile=/opt/share/jira/work/catalina.pid
ExecStart=/opt/share/jira/bin/start-jira.sh
ExecStop=/opt/share/jira/bin/stop-jira.sh

[Install]
WantedBy=multi-user.target

Bitbucket의 unit 설정 파일은 다음과 같다.

[Unit]
Description=Atlassian Bitbucket
After=network.target

[Service]
Type=forking
User=bitbucket
PIDFile=/opt/share/bitbucket/work/catalina.pid
ExecStart=/opt/share/bitbucket/bin/start-bitbucket.sh
ExecStop=/opt/share/bitbucket/bin/stop-bitbucket.sh

[Install]
WantedBy=multi-user.target

systemctl 사용한 unit 설정의 활성화, 시작, 종료 등

다음에서 Confluence에 대한 명령문의 실행 예만 든다. Jira와 Bitbucket도 confluence가 나온 부분을 jira와 bitbucket으로 변경하여 실행할 수 있다. 명령문 실행에서 서비스를 나타내는 .service 접미사는 생략할 수 있다. 예를 들면 confluence.service 대신 confluence를 사용하여 타이핑을 줄일 수 있다. bash에서 <TAB> 키로 자동 완성 기능을 사용한다면 큰 의미는 없다.

unit 설정 파일을 새로 만들었거나 변경했다면 systemd가 그것을 알 수 있게 다음의 명령어를 실행한다.

# systemctl daemon-reload

시스템 부팅 시에 서비스를 실행하려면 다음의 명령어를 실행한다. [Install] 절의 WantedBy 지시자 값으로 설정한 multi-user.target의 디렉토리에서 심볼릭 링크로 연결된다.

# systemctl enable confluence.service
Created symlink /etc/systemd/system/multi-user.target.wants/confluence.service → /etc/systemd/system/confluence.service.

다음의 명령어로 서비스를 시작(start), 종료(stop)하고 서비스의 상태(status)를 본다.

# systemctl start confluence.service
# systemctl stop confluence.service
# systemctl status confluence.service

서비스에 문제가 발생하면 다음의 명령어를 실행하여 무엇이 문제인지 확인해 본다.

# journalctl -xe

관련 소스 코드

• https://github.com/bitneer/bitneer.dev/blob/master/scripts/confluence
• https://github.com/bitneer/bitneer.dev/blob/master/scripts/jira
• https://github.com/bitneer/bitneer.dev/blob/master/scripts/bitbucket

참고 자료

• Run Confluence as a systemd service on linux
• Run Jira as a systemd service on linux
• Running Bitbucket Server as a Linux service
• systemd – Debian Wiki
• systemd/Services – Debian Wiki
• systemd.service(5) — systemd — Debian buster — Debian Manpages
• systemd.exec(5) — systemd — Debian buster — Debian Manpages
• systemd.unit(5) — systemd — Debian buster — Debian Manpages

The post Confluence, Jira, Bitbucket의 systemd unit 설정 appeared first on bitneer.dev.

데비안의 강력한 패키지 관리 시스템을 사용하기 위해서는 데비안에서 제공하는 패키지를 사용하는 것이 좋은 선택이다. ‘apt-get update && apt-get upgrade’ 명령어를 사용하여 패키지 업데이트의 편리함을 얻을 수 있다. 그러나 워드프레스는 직접 다운로드하여 설치하는 것이 더 낫다.

데비안의 워드프레스 버전이 낮고 워드프레스 자체가 웹호스팅에 설치할 것을 전제로 하기 때문이다. 데비안의 워드프레스 패키지 설치는 https://wiki.debian.org/WordPress에서 볼 수 있다. ‘apt-get install wordpress’ 명령어를 실행하여 워드프레스를 설치하면 데비안의 파일시스템 계층구조 표준에 따라 다음의 디렉토리 구조를 가진다.

• /usr/share/wordpress
• /usr/share/wordpress/.htaccess -> /etc/wordpress/htaccess
• /var/lib/wordpress/wp-content

데비안 Jessie의 워드프레스 패키지 버전은 4.1이다. backports로 설치한다면 4.7.x 버전까지 설치할 수 있다. 이 글을 쓰는 시점의 워드프레스 최신 버전은 4.8.x 이다. 브라우저에서 워드프레스로 로그인하여 플러그인, 테마를 설치하려면 /var/lib/wordpress/wp-content 안 plugins, themes 디렉토리의 사용자와 그룹을 www-data로 변경하는 추가적인 작업이 필요하다. 이런 이유로 데비안에서 제공하는 워드프레스 패키지 대신 직접 다운로드하여 설치하는 것을 추천한다.

보안 vs 사용의 편리성

워드프레스를 직접 다운로드하여 설치할 시 보안과 사용의 편리성을 절충해야 한다. 플러그인 설치와 워드프레스 업데이트 등을 쉽게 하려면 워드프레스를 설치할 디렉토리에 대한 쓰기 권한이 필요하다. 아파치의 VirtualHost인 mysite.com이 DocumentRoot로 /var/www/mysite 디렉토리를 사용한다고 가정하면 다음과 같이 설정한다.

# chown www-data:www-data /var/www/mysite
# chmod 755 /var/www/mysite

tar.gz으로 압축된 워드프레스를 다운로드하여 /var/www/mysite로 복사한 후 다음과 같이 작업한다.

# cd /var/www/mysite
# tar zxvf wordpress-<version>.tar.gz 
# mv wordpress wp
# chown -R www-data:www-data wp 
# find wp -type d -exec chmod 755 {} \; -print 
# find wp -type f -exec chmod 644 {} \; -print 
# rm wordpress-<version>.tar.gz

보안을 강화하고자 한다면 데비안의 워드프레스 패키지 방식으로 할 수 있다.

mysite나 wp 디렉토리와 디렉토리 안 모든 파일의 사용자와 그룹을 root로 설정하고, wp/wp-content의 일부 디렉토리만 www-data 사용자와 그룹으로 설정한다. 이처럼 설정하면 데비안의 아파치는 www-data 사용자와 그룹으로 실행하기 때문에 root 사용자와 그룹으로 설정한 디렉토리와 파일에 쓰기 권한을 가질 수 없다.

따라서 플러그인과 테마를 별도로 다운로드하여 압축을 푼 후 wp-content 안 plugins, themes 디렉토리에 복사해야 한다. 보안과 편리성은 서로 상충하기 때문에 한쪽을 선택하면 한쪽은 희생해야 한다.

워드프레스의 주요 설정

mysite.com/wp 대신 mysite.com URL을 사용하고자 한다면 다음과 같이 작업한다.

1. WordPress에 접속하여 Settings > General의 Site Address (URL)을 http://www.mysite.com으로 변경한 후 Save Change 버튼을 클릭한다.
2. /var/www/mysite/wp/index.php 파일을 /var/www/mysite/ 디렉토리로 복사한다.
3. 복사한 index.php 파일을 다음과 같이 수정한다.

   require( dirname( __FILE__ ) . '/wp/wp-blog-header.php' );
   

4. Permalink를 사용하고자 한다면 /var/www/mysite/wp/.htaccess 파일을 /var/www/mysite/ 디렉토리로 복사한다.

Permalink를 사용하려면 rewrite모듈을 활성화해야 한다. ‘a2enmod rewrite’ 명령어를 실행한다.

.htaccess 파일을 사용하기 위해서는 아파치의 ‘AllowOverride All’ 설정이 필요하다. 아파치(2.4)에서 가상호스트 mysite.com에 대해 다음과 같이 편집한 후 ‘sevice apache2 restart’ 명령어로 아파치를 재시작한다.

<VirtualHost *:80>
  ServerName www.mysite.com
  
  DocumentRoot /var/www/mysite
  <Directory /var/www/mysite>
    Options FollowSymLinks
    AllowOverride All
    Require all granted
  </Directory>
</VirtualHost>

Permalink는 SEO를 위해서 Post의 제목이 나올 수 있게 ‘Post Name’을 선택하거나 Custom Structure에서 ‘/wp/%postname%/’ 정도로 설정한다. 다음과 같이 시스템을 전체적으로 UTF-8로 설정했다면 mod_url을 설치할 필요는 없다.

• 데비안을 UTF-8로 설치
• Apache 설정에서 /etc/apache2/conf-available/charset.conf에 ‘AddDefaultCharset UTF-8’로 설정
• 워드프레스의 데이터베이스를 UTF-8로 생성

  MariaDB [(none)]> CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  MariaDB [(none)]> GRANT ALL ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY '암호 입력' WITH GRANT OPTION;
  

개인적인 취향에 따라 워드프레스 플러그인과 테마를 설치하여 사용한다.

The post 데비안에 워드프레스 설치 시 고려할 점 appeared first on bitneer.dev.