Java에 대한 흥미를 잃어 대체 솔루션으로 교체하게 되면 JDK를 삭제할 예정이었으나, 한동안은 더 필요할 듯하다. 또한 검색을 통해 이전에 작성한 데비안에 AdoptOpenJDK 설치하기 글로 유입되는 경우가 있어, 최신 정보를 공유하고자 기록을 남긴다.

AdoptOpenJDK의 브랜드 변경과 이관

AdoptOpenJDK는 2021년 Eclipse 재단으로 이관되면서 Eclipse Adoptium 프로젝트로 재탄생하였다. 이는 Oracle의 상표권 문제를 해결하고, 공식 호환성 테스트(TCK)를 통과하여 엔터프라이즈 환경에서 더 신뢰할 수 있는 바이너리를 제공하기 위함이다.

• 상표권 분쟁 회피: ‘OpenJDK’라는 단어는 Oracle의 등록 상표이다. 커뮤니티 프로젝트였던 ‘AdoptOpenJDK’의 규모가 커지자, 법적으로 안전하고 영구적인 이름을 갖기 위해 Eclipse 재단으로 이관하며 이름을 변경해야 했다.
• Java 공식 인증 (TCK 라이선스 획득): 과거 AdoptOpenJDK는 Oracle과의 라이선스 문제로 ‘자바 호환성 테스트(TCK)’를 공식적으로 수행할 수 없었다. 하지만 Eclipse 재단 산하로 들어가면서 Oracle과 협약을 맺고 TCK 인증을 통과한 ‘공식 호환 Java’를 배포할 수 있게 되었다.

2021년 AdoptOpenJDK 프로젝트가 Eclipse 재단으로 합류하며 Eclipse Adoptium으로 이름이 바뀌었고, Eclipse Temurin이라는 바이너리가 처음 배포되었다. 이후 2023년 7월, 기존에 사용하던 adoptopenjdk.jfrog.io 저장소는 완전히 사용 중단(Deprecated)되었다.

Eclipse Adoptium(어댑티움)은 프로젝트 이름이고 Eclipse Temurin(테무린)은 해당 프로젝트에서 생산하는 JDK 제품 이름이다. Temurin은 Runtime의 아나그램(철자 순서 바꾸기)이다. (R-u-n-t-i-m-e ↔ T-e-m-u-r-i-n)

AdoptOpenJDK 저장소 정리하기

Eclipse Temurin으로 이관되던 2023년 무렵, apt update 실행 시 다음과 같은 경고 메시지가 발생했었다. 현재는 저장소 자체가 삭제되었을 것으로 보인다.

# apt update
...
W: https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/dists/buster/InRelease 파일을 받는데 실패했습니다  503  Service Temporarily Unavailable [IP: 34.74.126.177 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.

아직 저장소를 정리하지 않았다면 /etc/apt/sources.list나 /etc/apt/sources.list.d에서 AdoptOpenJDK 저장소 설정을 삭제하자.

AdoptOpenJDK GPG 키는 apt-key add 명령으로 /etc/apt/trusted.gpg 파일에 저장되어 있을 것이다. 다음 명령어로 키 정보를 확인한다.

# apt-key list
...
pub   rsa4096 2019-06-25 [SC] [expires: 2023-06-24]
      5951 8666 C652 3968 B1F8  6530 8AC3 B291 7488 5C03
uid           [ unknown] AdoptOpenJDK <adoptopenjdk@jfrog.com>
sub   rsa4096 2019-06-25 [E] [expires: 2023-06-24]
...

4번째 줄의 전체 핑거프린트(Fingerprint)에서 마지막 8자리를 Key ID로 사용한다. 위 예시에서는 74885C03이 Key ID이다. 다음 명령어로 AdoptOpenJDK 키를 삭제한다.

# apt-key del 74885C03

데비안의 최신 apt 보안 표준

외부 저장소의 GPG 키를 저장하는 곳은 크게 다음 세 가지가 있다.

1. /etc/apt/trusted.gpg 파일
2. /etc/apt/trusted.gpg.d/ 디렉터리 내부
3. /etc/apt/keyrings/ 디렉터리 내부

첫 번째와 두 번째 방식은 보안상 좋지 않아 권장되지 않거나 사용이 중단될 예정이다. trusted.gpg 파일과 trusted.gpg.d 디렉터리 안의 키는 시스템의 모든 저장소에서 해당 키를 무조건 신뢰하기 때문이다.

• apt-key add 명령어로 trusted.gpg 파일에 추가하던 방법은 사용이 금지된다. Debian 13 "Trixie"부터 apt-key는 제거되어 더 이상 사용할 수 없다.
• /etc/apt/trusted.gpg.d/ 디렉터리에 넣는 것 또한 권장되지 않는다. rm 명령어로 GPG 키를 편하게 삭제할 수 있다는 장점은 있으나, 여전히 전역 신뢰(Global Trust) 문제로 인해 보안에 좋지 않다.

따라서 별도의 디렉터리인 /etc/apt/keyrings에 GPG 키를 저장하고, sources.list에서 "이 저장소는 오직 이 키로만 인증한다(signed-by)"라고 명시하는 세 번째 방식을 권장하고 있다.

이 권장 방식을 따르고 있는 대표적인 예로 GitHub CLI가 있다. (공식 문서 참조: GitHub CLI Install) GitHub CLI는 /etc/apt/keyrings/githubcli-archive-keyring.gpg 경로에 GPG 키를 생성하며, /etc/apt/sources.list.d/github-cli.list 파일의 내용은 다음과 같다.

deb [arch=amd64 signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main

signed-by 옵션에 GPG 키 경로를 명시적으로 설정한 것을 볼 수 있다.

Eclipse Temurin 설치

Eclipse Temurin 설치 페이지(https://adoptium.net/installation/linux/)에서는 앞서 언급한 두 번째 방식(/etc/apt/trusted.gpg.d/)을 안내하고 있다. 데비안의 최신 권장 방식을 아직 따르고 있지 않은데, 언젠가는 문서가 업데이트될 것으로 보인다. 공식 문서대로 설치해도 사용에는 지장이 없으나, 이 글에서는 데비안의 권장 방식(signed-by)으로 설치하는 방법을 설명한다.

1. 필수 패키지 설치

다음 명령어로 Eclipse Temurin 설치 과정에 필요한 wget, apt-transport-https, gpg 패키지를 설치한다. gpg는 데비안 설치 시 gnupg에 포함되어 이미 설치되어 있을 수 있다.

# apt update
# apt install wget apt-transport-https gpg

2. Eclipse Adoptium GPG 키 설치

패키지의 무결성 검사에 사용하는 Eclipse Adoptium GPG 키를 설치한다. /etc/apt/keyrings 디렉터리에 설치하는 점에 주목하자.

# wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/keyrings/adoptium.gpg > /dev/null

3. Eclipse Adoptium DEB 저장소 설정

Eclipse Adoptium DEB 저장소 설정을 추가한다. signed-by 옵션에 Eclipse Adoptium GPG 키 경로를 지정하여, 해당 저장소가 오직 이 키만 사용하도록 강제한다.

# echo "deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list

deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb bookworm main

4. temurin-<version>-jdk 설치

# apt update
# apt install temurin-8-jdk

관련 글

• 데비안에 AdoptOpenJDK 설치하기

참고 자료

• AdoptOpenJDK.jfrog.io has been deprecated! | Adoptium
• https://adoptium.net/installation/linux/
• SecureApt – Debian Wiki
• debian – How to identify gpg key IDs so they may be deleted – Unix & Linux Stack Exchange

The post 데비안에 Eclipse Temurin JDK 설치하기 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.

MariaDB 설치

MySQL Community의 MySQL 패키지를 설치했다면 완전히 삭제하는 것이 필요하다. 패키지의 의존성 문제로 삭제에 애를 먹을 수 있는데 apt-get remove –purge ‘mysql-.*’ 명령어를 사용하여 mysql 관련 패키지를 모두 제거하는 편법을 사용해야 한다. 패키지를 삭제하기 전에 mysqldump로 데이터베이스를 백업하고 /etc/mysql 디렉토리 안의 my.cnf 등 설정 파일을 백업하는 것이 좋을 것이다.

데비안 9(Stretch) 또는 10(Buster)에서 apt install mariadb-server 명령어로 MariaDB를 설치할 수 있다. 데비안 9는 MariaDB 10.1을 데비안 10은 MariaDB 10.3을 설치할 것이다.

# apt update
# apt install mariadb-server

데비안 패키지와 관련한 문서는 /usr/share/doc/<패키지 이름> 디렉토리에 위치한다. 패키지 설치 후 가장 먼저 찾아볼 문서이다. 참고로 README는 실제 제작자(upstream)의 문서이고, README.Debian은 데비안 개발자(패키지 메인테이너)가 제공하는 문서이다. MariaDB 서버와 관련하여 볼 만한 문서는 /usr/share/doc/mariadb-server-10.1 또는 /usr/share/doc/mariadb-server-10.3 디렉토리 안의 README.Debian.gz 파일이다. gzip으로 압축이 되어 있으므로 zmore나 zcat 명령어로 보거나 윈도우 운영체제에서는 7-Zip 등으로 압축을 풀어 편집 프로그램을 사용하여 본다.

# zmore /usr/share/doc/mariadb-server-10.3/README.Debian.gz
...
# zcat /usr/share/doc/mariadb-server-10.3/README.Debian.gz > ~/mariadb-server.README.Debian

systemd

MariaDB는 버전 10.1.8부터 systemd unit 파일을 제공한다. 데비안 패키지에서 /lib/systemd/system/mariadb.service 파일이 이에 해당한다. mariadb.service는 편리를 위해 mysql.service, mysqld.service 별칭을 가진다. systemctl 사용시 .service 접미사는 생략할 수 있다. 따라서 다음과 같이 systemctl 명령어를 사용하여 MariaDB 서비스의 시작, 종료 등을 할 수 있다.

# systemctl status mariadb
# systemctl status mysql.service
# systemclt status mysqld
# systemctl stop mysqld.service
# systemctl start mysql
# systemctl restart mariadb.service

mysql_secure_installation을 실행할 필요가 없음

데비안의 MariaDB 패키지는 보안을 적용한 상태이기 때문에 패키지 설치 후 mysql_secure_installation 명령어를 실행할 필요는 없다. 어떤 보안 설정들을 적용하였는지 살펴보자.

# mysql_secure_installation
...
In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] n
...
Remove anonymous users? [Y/n] y
...
Disallow root login remotely? [Y/n] y
...
Remove test database and access to it? [Y/n] y
...
Reload privilege tables now? [Y/n] y
...

위의 내용은 mysql_secure_installation 실행 과정의 일부분을 발췌한 것이다. 라인 8에서 현재 root 계정의 암호를 묻고 있다. 처음 설치 시에는 MariaDB에 대한 root 계정의 암호가 없으므로 <Enter> 키를 누른다. 라인 13에서 root의 암호를 설정할 것인지를 묻는다. unix_socket을 사용하여 root 계정을 인증하기 때문에 n을 입력한다. 이후 나머지 설정에서는 모두 y를 입력한다. 라인 15는 anonymous 사용자를 삭제한다. 라인 17은 root의 원격 로그인을 허용하지 않는다. 라인 19는 test 데이터베이스를 삭제한다. 라인 21은 보안 강화를 위해 변경한 내용을 바로 적용한다.

데비안에서 MariaDB 패키지를 설치하면 이미 위와 같이 설정한 상태이다. 데비안에서 라인 13처럼 MariaDB의 root 계정에 대한 암호를 설정하지 않는 데 다음에서 이에 대해 알아볼 것이다.

Unix Socket 인증

데비안은 MariaDB에서 unix_socket 인증 플러그인을 기본적으로 사용한다. unix_socket 인증 플러그인이 나오기 전에 MySQL이나 MariaDB는 데이터베이스를 보호하기 위해 자체적인 인증을 사용하였다. 그래서 시스템에 모든 권한이 있는 root 계정이라도 MySQL 내에 암호를 별도로 가져야 했다. mysql 클라이언트 사용 시 root 계정임에도 불필요해 보이는 -u, -p 옵션을 사용해야만 했다. 데이터베이스의 백업 스크립트에서 암호를 노출해야 하는 문제도 있었다.

unix_socket 인증 플러그인은 시스템의 인증과 MariaDB의 인증을 함께 묶어 준다. 로컬 시스템으로 접속하여 mysql 클라이언트 실행 시 -u, -p 옵션을 사용하지 않을 수 있게 한다. 예제를 통해 좀 더 알아보자. 규모가 큰 조직에서 미숙한 신입 DB 관리자가 들어왔다고 가정해 보자. 시스템 전체의 권한을 주지 않으면서 데이터베이스의 관리 권한만 주고 싶다면 다음과 같이 한다.

# groupadd dbadmin
# useradd dbadmin -g dbadmin -m
# passwd dbadmin
새  암호:
새  암호 재입력:
passwd: 암호를 성공적으로 업데이트했습니다
# mysql -e "GRANT ALL ON *.* TO 'dbadmin'@'localhost' IDENTIFIED VIA unix_socket WITH GRANT OPTION"

라인 1에서 3까지 시스템에 dbadmin 계정을 만들고 암호를 설정한다. 라인 7에서 unix_socket 인증을 사용하는 dbadmin 계정에 데이터베이스의 모든 권한을 주는 SQL 문을 실행한다. 다른 ssh 세션에서 dbadmin으로 로그인하여 mysql 클라이언트를 실행해 보자.

$ mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 59
Server version: 10.3.22-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

라인 1에서 보듯이 -u, -p 옵션을 사용하지 않았다. 로컬 시스템의 dbadmin 계정과 암호로 로그인하면 unix_socket 인증에 의해 mysql 클라이언트를 사용할 수 있는 것이다.

신입 DB 관리자가 자신의 컴퓨터에서 DBeaver, DataGrip 같은 그래픽 도구로 MariaDB 서버에 접속하여 데이터베이스를 관리하고 싶다고 해보자. 그리고 집에서도 접속하고 싶어 한다. 이럴 때는 unix_socket이 아니라 password 인증을 사용해야 한다. 다음과 같이 작업한다.

MariaDB [(none)]> USE mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [mysql]> GRANT ALL ON *.* TO 'dbadmin'@'192.168.10.%' IDENTIFIED BY '원하는 암호 입력' WITH GRANT OPTION;
Query OK, 0 rows affected (0.000 sec)

MariaDB [mysql]> GRANT ALL ON *.* TO 'dbadmin'@'%' IDENTIFIED BY '원하는 암호 입력' WITH GRANT OPTION;
Query OK, 0 rows affected (0.000 sec)

MariaDB [mysql]> SELECT user, host, password, plugin FROM user WHERE user='dbadmin';
+---------+--------------+-------------------------------------------+-------------+
| user    | host         | password                                  | plugin      |
+---------+--------------+-------------------------------------------+-------------+
| dbadmin | localhost    |                                           | unix_socket |
| dbadmin | 192.168.10.% | *CB04FE5BBC0DAAE405DB6DD0745827BCF1CF624D |             |
| dbadmin | %            | *CB04FE5BBC0DAAE405DB6DD0745827BCF1CF624D |             |
+---------+--------------+-------------------------------------------+-------------+
3 rows in set (0.000 sec)

MariaDB [mysql]> DROP USER 'dbadmin'@'%';
Query OK, 0 rows affected (0.000 sec)

MariaDB [mysql]>

라인 1에서 라인 12의 SELECT 문을 사용하기 쉽게 mysql 데이터베이스로 이동한다. 라인 6에서 암호 인증을 사용하는 dbadmin 계정에 데이터베이스의 모든 권한을 주었다. ‘dbadmin’@’192.168.10.%’는 dbadmin이 192.168.10의 네트워크에 있는 컴퓨터에서 접속할 수 있음을 의미한다. % 문자는 ‘모든’을 의미한다. 라인 9에서 ‘dbadmin’@’%’는 네트워크 제한을 두지 않는다. dbadmin 계정은 어떤 IP에서든 접속할 수 있다. 당연히 보안에 좋지 않다. 라인 12에서 SELECT 문을 사용하여 dbadmin 사용자의 인증 방법과 접속할 수 있는 네트워크 대역을 확인한다. 라인 22에서 DROP USER 문을 사용하여 ‘dbadmin’@’%’ 사용자를 삭제한다.

원격으로 접속하기 위해서는 추가적인 설정이 필요하다. 이에 대해서는 아래의 ‘원격 접속을 허용하기’에서 다룬다.

워드프레스의 데이터베이스 만들기

응용 프로그램을 위한 데이터베이스 생성은 기존의 방식과 동일하게 암호 인증을 사용한다. 워드프레스를 위한 데이터베이스와 사용자는 다음과 같이 만들 수 있다.

MariaDB [mysql]> CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Query OK, 1 row affected (0.00 sec)

MariaDB [mysql]> GRANT ALL ON wordpress.* TO 'wordpress'@'localhost' IDENTIFIED BY '원하는 암호 입력' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

MariaDB [mysql]>

MariaDB 설정 파일의 위치

/etc/mysql/mariadb.cnf 파일을 보면 MariaDB 설정 파일은 다음과 같다.

1. /etc/mysql/mariadb.cnf
2. /etc/mysql/conf.d/*.cnf
3. /etc/mysql/mariadb.conf.d/*.cnf
4. ~/.my.cnf

위의 순서로 설정 파일을 읽기 때문에 같은 옵션이 여러 번 나타난다면 가장 마지막에 있는 설정을 적용할 것이다. MariaDB 서버와 관련한 설정은 /etc/mysql/mariadb.conf.d 디렉토리 안의 50-server.cnf 파일에서 한다.

원격 접속을 허용하기

데비안의 MariaDB는 보안을 위해 3306 포트를 루프백(loop-back) 주소인 127.0.0.1로 바인딩한다. 다음의 명령어로 확인할 수 있다.

# netstat -tlnp | grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      12435/mysqld

따라서 시스템 외부에서 접근할 수 없다. 시스템 외부에서 접근할 수 있도록 하려면 50-server.cnf 파일에서 bind-address를 다음과 같이 변경한다.

bind-address            = 0.0.0.0

변경한 설정을 반영하기 위해 MariaDB 서버를 다시 시작한다.

# systemctl restart mariadb

공유기(방화벽 역할)의 외부에서 오는 접근을 허용하려면 3306 포트에 대한 포트 포워딩을 해야 한다. 보안에 좋지 않기 때문에 데이터베이스 서버의 포트를 여는 경우는 거의 없을 것이다.

언어 설정

데비안의 MariaDB에서 디폴트 문자 집합(character set)은 utf8mb4이다. 디폴트 데이터 정렬(collation)은 utf8mb4_general_ci이다. 데이터 정렬을 utf8mb4_unicode_ci로 바꾸고 싶다면 50-server.cnf 파일을 다음과 같이 편집한다.

collation-server      = utf8mb4_unicode_ci
skip-character-set-client-handshake

라인 1의 collation-server의 값을 utf8mb4_general_ci에서 utf8mb4_unicode_ci로 변경한다. 라인 2의 skip-character-set-client-handshake를 추가한다.

MariaDB 서버를 다시 시작하고 MySQL 클라이언트를 다시 실행한 후 다음의 SQL 문으로 변경을 확인한다.

MariaDB [(none)]> SHOW VARIABLES LIKE 'coll%';
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | utf8mb4_unicode_ci |
| collation_database   | utf8mb4_unicode_ci |
| collation_server     | utf8mb4_unicode_ci |
+----------------------+--------------------+
3 rows in set (0.001 sec)

MariaDB [(none)]>

MariaDB 서버의 데이터 정렬 설정은 MySQL 클라이언트 외에 다른 응용 프로그램의 데이터 정렬을 강제하지는 않는다. 예를 들면 Adminer는 collation_connection을 utf8mb4_general_ci로 나타낸다. 워드프레스의 일부 플러그인은 utf8mb4_general_ci를 가지는 테이블을 만든다.

튜닝

데이터베이스의 데이터는 ‘하드디스크 > 메모리 > CPU의 레지스터’ 순으로 옮겨간다. 오른쪽으로 갈수록 속도가 빠른 대신 저장 비용은 비싸진다. 데이터베이스 읽기의 최적화는 디스크 입출력(I/O)을 최소화하고 메모리를 최대한 사용하는 것이다. 단순하지만 중요한 개념이다. 데이터베이스 쓰기의 최적화는 메모리의 휘발성으로 인해 간단하지 않다. 커밋(commit)한 데이터를 메모리에서 디스크로 쓰기 전에 시스템 장애가 발생한다면 데이터를 잃을 것이다. 은행이나 증권의 돈과 관련한 데이터라면 커밋 즉시 메모리에서 디스크로 써야 한다. 안정성은 증가하지만, 성능은 준다. 게시판의 글에 대한 데이터라면 메모리를 좀 더 활용하고 디스크에 쓰는 것을 늦출 수 있을 것이다. 데이터베이스 쓰기의 최적화는 데이터의 종류에 따라 안정성과 성능 사이에서 고민해야 할 문제이다.

MariaDB의 디폴트 스토리지 엔진(default_storage_engine)은 InnoDB이다. InnoDB와 관련한 디폴트 설정값은 데스크톱 시스템에 맞게 되어 있다. 데이터베이스 전용의 서버를 사용한다면 최적의 성능을 위해 설정값을 변경하여야 할 것이다. 전용의 서버가 아니더라도 약간의 설정값 변경으로 성능 향상을 꾀할 수 있다. 나는 Configuring MariaDB for Optimal Performance와 10 Database Tuning Tips for Peak Workloads 페이지를 참고하여 3가지 정도의 설정만 추가하였다.

innodb_buffer_pool_size=4096M
innodb_log_file_size=1024M
innodb_log_buffer_size=64M

위의 설정은 모두 50-server.cnf 파일에 추가한다. 라인 1의 innodb_buffer_pool_size는 성능 최적화에 가장 중요한 설정이다. 하나만 설정해야 한다면 이것을 해야 한다. 참고한 페이지에서는 innodb_buffer_pool_size를 데이터베이스 전용의 서버일 때 메모리의 80% 정도를 권장한다. Buffer Pool은 주로 데이터의 읽기와 관련한 것으로 디스크보다는 메모리를 사용하기 위해 가능한 한 크게 설정하는 것을 추천하고 있다. 데이터베이스 전용의 서버가 아니더라도 자신의 시스템 환경에 맞춰 크게 설정하는 것이 좋겠다.

InnoDB는 데이터를 디스크에 쓰기 전에 속도와 안정성을 목적으로 Redo Log를 사용한다. Redo Log는 시스템 장애 발생 시 복구를 위해 변경 기록들을 저장한다. INSERT 문과 같은 데이터 변경이 발생한다면 그 데이터는 ‘Buffer Pool(메모리) > Log Buffer(메모리) > Redo Log(ib_logfile0, ib_logfile1 파일) > 테이블(디스크)’의 순으로 이동한다. Redo Log의 파일 크기인 innodb_log_file_size는 innodb_buffer_pool_size의 1/4에서 1/2까지를 권장한다. Log Buffer의 크기인 innodb_log_buffer_size는 참고한 페이지에서 64M을 추천하고 있다.

innodb_log_file_size의 변경은 다음의 절차로 한다.

1. MariaDB 서버를 종료한다.
2. 위 라인 2처럼 50-server.cnf 파일에 innodb_log_file_size 설정을 추가한다.
3. /var/lib/mysql 디렉토리에서 ib_logfile0, ib_logfile1을 삭제하거나 다른 디렉토리로 옮긴다. (innodb_log_files_in_group의 디폴트 값이 2이기 때문에 Redo Log 파일이 2개가 있다.)
4. MariaDB 서버를 시작한다. 새로 설정한 크기의 ib_logfile0, ib_logfile1 파일을 볼 수 있을 것이다.

참고한 페이지에는 데이터 안정성과 관련한 innodb_flush_log_at_trx_commit과 sync_binlog, 동시 접속자 수에 대한 max_connections 등을 다루고 있다. 나는 위 3개의 설정을 제외하고 모두 디폴트 값을 사용할 것이어서 크게 관심을 가지지 않았지만, 여러분에게 필요한 내용이 있을지 모르겠다.

참고 자료

• Moving from MySQL to MariaDB in Debian 9
• How do I completely remove mysql-server on Debian?
• systemd
• mysql_secure_installation
• Authentication Plugin – Unix Socket
• Configuring MariaDB for Optimal Performance
• 10 Database Tuning Tips for Peak Workloads
• InnoDB System Variables
• Server System Variables

The post 데비안의 MariaDB 설치와 설정 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.

PostgreSQL 설치

PostgreSQL의 라이센스는 자유를 추구하는 데비안과 잘 맞는다. PostgreSQL은 데비안의 주요 패키지 중의 하나이기 때문에 다음과 같이 한 줄의 명령어로 설치한다.

# apt install postgresql postgresql-client

설치 후 PostgreSQL 관련 파일의 위치는 다음과 같다.

• 설정 파일: /etc/postgresql/[version]/[cluster]/
• 실행 파일: /usr/lib/postgresql/[version]
• 데이타 파일: /var/lib/postgresql/[version]/[cluster]
• 로그 파일: /var/log/postgresql 디렉토리 안의 postgresql-[version]-[cluster].log

내가 사용하는 데비안 9(stretch)에서 PostgreSQL 버전은 9.6이다. 앞으로 나올 파일의 경로는 9.6을 기준으로 서술한다. PostgreSQL은 클러스터로 데이터베이스를 관리한다. 간단하게 ‘클러스터 > 데이터베이스 > 테이블’의 순서로 그려볼 수 있다. 여러 개의 클러스터가 존재할 수 있고 한 클러스터 내에 여러 개의 데이터베이스를 가질 수 있다. 클러스터는 아마존 클라우드와 같이 대용량을 위한 것이다. 개인이라면 하나의 클러스터로도 충분할 것이다.

데비안은 pg_ctl을 pg_ctlcluster로 대체한다. pg_ctlcluster는 Perl 스크립트 파일이고 내부에서 pg_ctl을 사용한다. pg_ctlcluster는 PostgreSQL의 다양한 버전과 여러 클러스터를 효율적으로 관리하기 위한 것이다.

데비안에서 PostgreSQL의 init.d 시작 스크립트는 /etc/init.d/postgresql이다. 이 시작 스크립트 안에서 pg_ctlcluster를 호출한다. PostgreSQL의 시작과 종료는 systemctl을 사용하거나 다음과 같이 init.d 시작 스크립트를 실행할 수 있다.

# /etc/init.d/postgresql stop
[ ok ] Stopping postgresql (via systemctl): postgresql.service.
# /etc/init.d/postgresql start
[ ok ] Starting postgresql (via systemctl): postgresql.service.
# /etc/init.d/postgresql restart 
[ ok ] Restarting postgresql (via systemctl): postgresql.service.
/etc/init.d/postgresql reload
[ ok ] Reloading postgresql configuration (via systemctl): postgresql.service.
# /etc/init.d/postgresql status
...

사용자 접근 설정

디폴트 데이타베이스와 사용자는 postgres이다. 데이타베이스 관리는 postgres 사용자로 하여야 한다. root 계정에서 다음의 명령어로 postgres 사용자로 변경한다.

# su -s /bin/bash postgres
$ id
uid=115(postgres) gid=124(postgres) groups=124(postgres),112(ssl-cert)

id 명령어로 현재의 사용자가 postgres인지 확인할 수 있다. postgres로 사용자 변경후 psql 클라이언트 프로그램을 실행한다.

$ psql

root에서 postgres로 사용자를 전환하는 su 명령어를 사용하지 않고 psql을 직접 실행하려면 다음과 같이 하여야 한다.

# psql -h localhost -U postgres -d postgres
postgres 사용자의 암호:

postgres 사용자의 암호를 묻는 메시지가 나온다. 데비안에서는 디폴트로 postgres 사용자의 암호가 없다. <Ctrl + C> 키를 눌러 우선은 빠져나온다.

데비안의 PostgreSQL은 로컬 시스템에서 peer 인증(authentication)을 사용한다. peer 인증은 PostgreSQL 사용자와 동일한 이름을 가지는 로컬 계정으로 로컬 시스템에 로그인하면 암호 없이 데이터베이스를 사용할 수 있다. 이러한 설정은 /etc/postgresql/9.6/main/pg_hba.conf에서 확인할 수 있다.

# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
...

위 설정을 보면 로컬 시스템(127.0.0.1/32)에 로그인하지 않고(host) 접근하려면 암호를 사용해야 한다. METHOD가 md5인 경우 암호를 사용한다는 의미이다. 로컬 시스템에서 사용자가 아니라 응용프로그램이 PostgreSQL 데이터베이스에 접속할 때 적용될 것이다. 또는 위에서 보았듯 root 계정에서 PostgreSQL 사용자로 전환하는 su를 사용하지 않고 psql, pg_dump 등을 사용할 때 암호를 사용해야 한다.

PostgreSQL의 관리자 권한을 가지는 postgres 사용자에 암호를 설정하려면 psql 클라이언트에서 다음의 SQL문을 실행한다.

postgres=# ALTER USER postgres PASSWORD '원하는 암호 입력';
ALTER ROLE
postgres=# \q

SQL 실행 후 ALTER ROLE 확인 메시지가 나오면 성공한 것이다. \q 명령어를 실행하여 psql을 종료한다.

root 계정으로 다음과 같이 psql을 다시 실행하고 설정한 암호를 입력하여 접속에 성공하는지 확인해 본다.

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

postgres=#

매번 암호를 입력하는 것은 귀찮은 작업이다. 특히 백업에 사용하는 pg_dump를 스크립트에서 사용할 때 암호가 노출된다. pg_dump를 한 번 실행해 보자.

# pg_dump -Fc -h localhost -U postgres -d postgres -f /root/postgres_`date +%F`.dump
암호:

스크립트에서 암호를 입력하지 않고 실행하려면 다음과 같이 해야 한다.

#!/bin/bash
export PGPASSWORD="yourpassword"
pg_dump -Fc -h localhost -U postgres -d postgres -f /root/postgres_`date +%F`.dump

이를 해결하기 위해 다음의 내용을 가지는 /root/.pgpass 파일을 생성한다.

localhost:5432:*:postgres:<관리자인 postgres의 암호를 입력>
localhost:5432:*:*:<개발이나 응용프로그램에서 사용할 암호 입력>

위의 내용은 hostname:port:database:username:password를 의미한다. 별표 문자 *는 와일드카드로 ‘모든’을 뜻한다. 마지막의 password를 제외하고 별표 문자를 사용할 수 있다. 두 번째 줄에서 개발이나 다른 응용프로그램에서 사용할 데이터베이스의 암호를 따로 설정해 주었다. 일반적으로 개발이나 응용프로그램은 설정 파일에 암호를 저장하는 경우가 빈번하기 때문에 사용하는 데이터베이스의 암호가 노출되기 쉽다. 관리자 암호와는 다른 암호를 사용하여 관리자의 암호를 보호하기 위해 두 번째 줄을 추가한 것이다. root 외 다른 사용자가 .pgpass 파일 안의 내용을 보지 못하도록 다음의 명령어를 실행한다.

# chmod 600 /root/.pgpass

다시 root 계정으로 pg_dump와 psql을 실행하면 암호를 묻지 않는 것을 확인할 수 있다.

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

postgres=#

원격 접속을 위한 설정

시스템 외부에서 pgAdmin, DataGrip 등의 프로그램을 사용하여 원격으로 접속하려면 몇 가지 설정을 해야 한다. PostgreSQL은 기본값으로 포트 5432를 사용한다. 데비안에서 포트 5432는 디폴트로 로컬 주소(127.0.0.1)로 바인딩한다. 다음의 명령어로 확인할 수 있다.

# netstat -nlt | grep 5432
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN

따라서 시스템 외부에서 접근할 수 없다. 시스템 외부에서 접근할 수 있도록 허용하려면 /etc/postgresql/9.6/main/postgresql.conf 파일에 다음의 내용을 설정한다.

listen_addresses = '*'

로컬 네트워크에 있는 컴퓨터가 접근할 수 있도록 허용하려면 /etc/postgresql/9.6/main/pg_hba.conf에 다음의 내용을 추가한다. 로컬 네트워크 대역의 주소(192.168.1.0/24)는 여러분에게 맞는 값을 넣어준다.

host    all             all             192.168.1.0/24         md5

모든 설정을 마쳤으면 PostgreSQL을 다시 시작한다.

# /etc/init.d/postgresql restart

PostgreSQL의 기본적인 튜닝

PostgreSQL은 오래된 시스템을 지원하기 위한 설정값을 디폴트로 가진다. 전문적인 튜닝은 아니지만 약간의 설정을 변경하는 것으로도 많은 성능 향상을 가져온다. 다음의 사이트에서 설정값에 대한 힌트를 얻을 수 있다.

• PGTune
• PGConfig 2.0
• Cybertec Postgres Configurator

운영체제의 종류, 메모리 크기 등을 선택해서 나온 설정값을 종합적으로 고려하여 /etc/postgresql/9.6/main/postgresql.conf 파일을 수정하고 PostgreSQL을 다시 시작한다. 내가 설정한 내용은 다음과 같다.

shared_buffers = 1GB
work_mem = 64MB
maintenance_work_mem = 256MB
effective_io_concurrency = 2
wal_buffers = 16MB
max_wal_size = 2GB
min_wal_size = 512MB
checkpoint_completion_target = 0.7
random_page_cost = 4
effective_cache_size = 3GB
default_statistics_target = 100

관련 글

• PostgreSQL의 데이터베이스와 사용자 생성, 백업 및 복구

참고 자료

• PostgreSql – Debian Wiki
• PostgreSQL: Manuals
• PostgreSQL: Documentation: 11: 34.15. The Password File
• pgAdmin PostgreSQL Tools
• 기능 및 스크린샷 – DataGrip

The post 데비안의 PostgreSQL 설치와 설정 appeared first on bitneer.dev.

Java를 개발한 썬 마이크로시스템즈는 2010년에 오라클에 인수합병되었다. 썬은 오픈소스에 친화적이었지만 오라클은 그렇지 않았다. 재배포를 허용하지 않는 라이센스 때문에 데비안에서 오라클의 Java 패키지는 빠졌다. 대신에 OpenJDK가 들어왔다. OpenJDK는 썬이 GPL로 공개한 Java 소스코드를 기반으로 하는 프로젝트이다. 오라클도 이 프로젝트에 주요 구성원으로 참여하고 있다. OpenJDK는 오라클 Java와 거의 동일하며 몇몇 상업적인 소스코드만이 빠져있다. 가장 큰 차이점이라면 소스코드의 빌드 주체와 어떤 라이센스로 배포하는가일 것이다.

데비안에서 개발을 위한 JDK(Java Development Kit)의 설치는 다음과 같이 한다.

# apt-get install default-jdk

개발이 목적이 아니라면 default-jre 패키지만을 설치할 수 있다. default JRE/JDK의 버전은 데비안 버전에 따라 달라진다. 데비안 9(stretch)는 OpenJDK v8, 데비안 10(buster)은 OpenJDK v11이다.

AdoptOpenJDK 설치

내가 사용하고 있는 Confluence, Jira, Butbucket은 AdoptOpenJDK를 권장한다. 현재 데비안은 AdoptOpenJDK를 포함하고 있지 않다. 따라서 AdoptOpenJDK 저장소에서 패키지를 설치해야 한다. root 계정으로 다음과 같이 작업한다.

1. 패키지의 무결성 검사에 사용하는 AdoptOpenJDK GPG 키를 설치하기 위해 다음과 같이 한다.

   # wget -qO - https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | apt-key add -
   

2. AdoptOpenJDK DEB 저장소 설정을 추가하기 위해 다음의 명령어를 실행한다.

   # add-apt-repository --yes https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/
   

3. 다음의 명령어로 adoptopenjdk-8-hotspot 패키지를 설치한다.

   # apt-get update
   # apt-get install adoptopenjdk-8-hotspot
   

apt에 대한 GPG 키는 /etc/apt/trusted.gpg 파일이나 /etc/apt/trusted.gpg.d 디렉토리에 저장된다. 다음의 명령어로 키 리스트를 확인할 수 있다.

# apt-key list
...
        [ unknown] AdoptOpenJDK (used for publishing RPM and DEB files) <adoptopenjdk@gmail.com>
...

add-apt-repository 명령어가 없다면 먼저 software-properties-common 패키지를 설치한다. which 명령어는 add-apt-repository 명령어가 있는지 확인하는 데 유용하다.

# which add-apt-repository
# apt-get install software-properties-common
...
# which add-apt-repository
/usr/bin/add-apt-repository

위 2.의 add-apt-repository 명령은 /etc/apt/sources.list 파일 끝에 AdoptOpenJDK DEB 저장소 설정을 추가한다. 나는 깔끔함을 위해 /etc/apt/sources.list.d 디렉토리 안에 adoptopenjdk.list 파일을 만들어 설정을 옮겨 주었다. /etc/apt/sources.list.d/adoptopenjdk.list의 내용은 다음과 같다.

deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ stretch main
# deb-src https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ stretch main

데비안에 없는 패키지를 제공하는 비공식 APT 저장소를 서드파티 저장소(third-party repository)라고 부른다. /etc/apt/sources.list.d가 서드파티 저장소를 위한 것이고 파일 이름은 .list로 끝난다. 설정을 반영하기 위해서는 ‘apt-get update’ 명령어를 실행해야 한다. AdoptOpenJDK는 오픈 소스 프로젝트답게 소스코드를 제공한다. 소스코드를 받아서 설치하고자 한다면 deb-src 앞의 주석을 위한 샵(#)을 제거한다.

데비안의 Java 설정

여러 개의 Java 버전을 설치하였다면 디폴트로 사용할 Java를 선택하기 위해 다음의 명령어를 실행한다.

# update-alternatives --config java
대체 항목 java에 대해 (/usr/bin/java 제공) 5개 선택이 있습니다.

  선택       경로                                              우선순 상태
------------------------------------------------------------
  0            /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java   1081      자동 모드
  1            /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java   1081      수동 모드
  2            /usr/lib/jvm/j2sdk1.7-oracle/jre/bin/java            317       수동 모드
  3            /usr/lib/jvm/java-6-sun/jre/bin/java                 63        수동 모드
  4            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java       1081      수동 모드
* 5            /usr/lib/jvm/jdk-8-oracle-x64/jre/bin/java           318       수동 모드

Press <enter> to keep the current choice[*], or type selection number:

원하는 Java 버전 앞에 있는 숫자를 입력하고 <Enter> 키를 누른다. 현재의 Java 버전을 확인하기 위해 다음의 명령어를 실행해 본다.

# java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)

디폴트로 사용할 Java 컴파일러를 선택하기 위해 위와 마찬가지로 ‘update-alternatives’ 명령어를 사용할 수 있다.

# update-alternatives --config javac
대체 항목 javac에 대해 (/usr/bin/javac 제공) 3개 선택이 있습니다.

  선택       경로                                               우선순 상태
------------------------------------------------------------
  0            /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javac   1081      자동 모드
  1            /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javac   1081      수동 모드
  2            /usr/lib/jvm/j2sdk1.7-oracle/bin/javac                317       수동 모드
* 3            /usr/lib/jvm/jdk-8-oracle-x64/bin/javac               318       수동 모드

Press <enter> to keep the current choice[*], or type selection number:

그러나 위와 같이 일일이 설정하기보다는 $JAVA_HOME/bin 디렉토리 안에 있는 실행 파일들에 대해 한꺼번에 설정할 필요가 있다. 이를 위해 java-common 패키지의 update-java-alternatives 명령어를 사용할 수 있다.

# readlink -f /usr/bin/javac
/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/javac
# readlink -f /usr/bin/keytool 
/usr/lib/jvm/jdk-8-oracle-x64/jre/bin/keytool
# update-java-alternatives -l
adoptopenjdk-8-hotspot-amd64   1081       /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64
j2sdk1.7-oracle                317        /usr/lib/jvm/j2sdk1.7-oracle
java-1.8.0-openjdk-amd64       1081       /usr/lib/jvm/java-1.8.0-openjdk-amd64
java-6-sun                     63         /usr/lib/jvm/java-6-sun
jdk-8-oracle-x64               318        /usr/lib/jvm/jdk-8-oracle-x64
# update-java-alternatives -s adoptopenjdk-8-hotspot-amd64
update-alternatives: 오류: no alternatives for HtmlConverter
...
# readlink -f /usr/bin/keytool 
/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/keytool

readlink 명령어로 Java 관련 실행 파일의 경로를 확인할 수 있다. ‘update-java-alternatives -s’를 실행할 때 나오는 오류 메시지는 무시해도 괜찮다.

몇몇 응용프로그램은 Java의 설치 위치를 결정하기 위해 JAVA_HOME 환경 변수를 사용한다. JAVA_HOME의 시스템 전역 설정을 위해 /etc/environment에 다음의 내용을 추가한다.

JAVA_HOME="/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64"

JAVA_HOME의 값은 위의 ‘update-alternatives –config java’ 명령어를 실행하여 참고할 수 있다. 선호하는 Java 버전의 실행 경로에서 맨 뒤의 /bin/java를 빼고 JAVA_HOME에 할당한다. 설정한 환경 변수를 반영하기 위해 다시 로그인하거나 다음의 명령어를 실행한다.

# source /etc/environment
# echo $JAVA_HOME
/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64

/etc/environment에 설정하는 환경 변수는 로그인하는 모든 사용자에게 영향을 미친다. 다른 값을 원하는 사용자는 홈 디렉토리의 .bashrc 파일에 JAVA_HOME을 설정하여 오버라이딩할 수 있다.

참고 자료

• Java – Debian Wiki
• sun-java6 packages removed soon from Debian/Ubuntu (and all other linux distros)
• OpenJDK
• AdoptOpenJDK – Open source, prebuilt OpenJDK binaries
• Installation | AdoptOpenJDK – Linux RPM and DEB installer packages

The post 데비안에 AdoptOpenJDK 설치하기 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.