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.

설치

• 공식 웹사이트: 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.

C/C++ Extension Pack 확장을 설치한다. 이 확장은 데비안(Debian)의 메타 패키지와 유사하게 여러 확장을 모아 놓은 것으로, 설치 시 다음과 같은 C++ 개발 필수 확장들이 함께 설치된다.

• C/C++
• C/C++ Themes
• CMake Tools

코드 분석 도구로는 Microsoft C/C++ 확장보다 clangd 확장이 더 빠르고 지능적이라는 평가를 받는다.

clangd 확장을 설치할 때, 아래 그림과 같이 제작사인 LLVM을 신뢰할 것인지 묻는 창이 나타나면 Trust Publisher & Install 버튼을 클릭하여 설치를 진행한다.

clangd 확장 설치를 완료하면 우측 하단에 두 개의 알림 창이 나타난다.

1. clangd language server가 없다는 알림 창에서는 Install 버튼을 클릭하여 설치한다.
2. Microsoft C/C++ 확장과 clangd 확장이 충돌한다는 알림 창에서는 Disable IntelliSense 버튼을 클릭한 후, 이어지는 Reload 버튼을 클릭하여 VS Code 설정을 다시 불러온다.
   

이렇게 하면 Microsoft C/C++ 확장의 인텔리센스(코드 분석/자동 완성) 기능만 비활성화되고, 디버깅 기능(GDB/LLDB 연동)은 그대로 유지되어 두 확장의 장점을 모두 활용할 수 있다.

프로젝트 폴더에 CMakeLists.txt 파일 생성하기

tasks.json이나 launch.json 파일을 수동으로 만들기보다 CMake를 사용하여 빌드 시스템을 정의하는 것이 효율적이다. 최근 대부분의 C++ 프로젝트는 CMake를 표준으로 사용한다. CMake는 빌드 파일을 직접 생성하는 것이 아니라 make나 Ninja용 빌드 파일을 생성해 주는 도구이다. 최신 개발 환경에서는 cmake -G Ninja 명령을 통해 속도가 빠른 Ninja를 사용하는 것이 추세다.

VS Code의 CMake Tools 확장을 활용하면 빌드, 테스트, 디버깅 설정을 자동화할 수 있다. 이 확장은 CMake 프로젝트를 인식하면 하단 상태 표시줄에 빌드, 디버그, 실행 버튼을 제공한다.

CMake 프로젝트임을 인식시키기 위해 프로젝트 루트 폴더에 CMakeLists.txt 파일을 생성한다. 이전 글(WSL에 C/C++ 개발을 위한 패키지 설치하기)에서 생성한 wsl_cpp 디렉터리를 그대로 사용한다.

파일을 생성하면 곧바로 Kit을 선택하라는 창이 나타난다. 동시에 하단 상태 표시줄에는 빌드 설정, 디버그, 실행 아이콘이 생성된다. 만약 Kit 선택 창을 닫았다면 상태 표시줄의 Build 설정 아이콘을 클릭하여 다시 열 수 있다.

Kit 선택 창에서 사용할 컴파일러를 선택한다. 보통 Clang이나 GCC를 선택한다. 위 그림에 mingw32 항목이 보이는 이유는 리눅스 환경에서 윈도우용 실행 파일(.exe)을 만드는 크로스 컴파일 테스트를 위해 mingw-w64 패키지를 설치했기 때문이다. 일반적인 리눅스 환경의 GCC를 사용하려면 /usr/bin/gcc, /usr/bin/g++ 경로가 표시된 항목을 선택한다. 만약 Clang이 목록에 없다면 맨 위의 Scan for kits를 실행하여 컴파일러를 새로 검색한다.

검색 후 위 그림과 같이 Clang 컴파일러 항목이 나타나면, WSL Linux 시스템 경로인 /usr/bin/clang, /usr/bin/clang++이 포함된 항목을 선택한다.

컴파일러 선택을 마치면 프로젝트 폴더에 build 디렉터리가 자동으로 생성된다. 이전에 테스트로 생성했던 a.out이나 hello 실행 파일은 삭제해도 무방하다. 앞으로 빌드 결과물은 모두 build 디렉터리 안에 생성되기 때문이다. 왼쪽 액티비티 바(Activity Bar)에 CMake 아이콘이 추가된 것도 확인할 수 있다.

CMakeLists.txt 파일에 설정 내용 추가하기

CMakeLists.txt 파일에 아무 내용도 입력하지 않으면, 아래 그림과 같이 OUTPUT 패널의 CMake/Build 메시지에 경고가 표시된다.

CMakeLists.txt 파일에 다음 내용을 추가한다.

cmake_minimum_required(VERSION 3.10)
project(WSLCPP LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
add_executable(hello hello.cpp)

• 라인 1: 최소 CMake 요구 버전 설정.
• 라인 2: 프로젝트 이름 및 사용 언어 설정.
• 라인 3, 4: C++17 표준 사용을 강제하는 설정.
• 라인 5: clangd를 위한 컴파일 데이터베이스(compile_commands.json) 생성 설정.
• 라인 6: hello.cpp 소스 파일을 사용하여 hello라는 이름의 실행 파일을 생성하는 설정.

파일을 저장하면 OUTPUT 패널에서 설정을 자동으로 반영한다. 만약 자동 반영이 되지 않는다면 Ctrl + Shift + P를 누른 후 CMake: Configure를 실행한다.

[main] Configuring project: wsl_cpp 
[proc] Executing command: /usr/bin/cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/clang++ --no-warn-unused-cli -S /home/bitneer/study/CPP/wsl_cpp -B /home/bitneer/study/CPP/wsl_cpp/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: /home/bitneer/study/CPP/wsl_cpp/build

로그의 두 번째 라인에서 설정한 컴파일러와 빌드 시스템을 확인한다. 위 예시에서는 Clang과 Ninja를 사용하고 있다. CMake Tools 확장은 시스템에 Ninja가 설치되어 있으면 기존의 make보다 속도가 빠른 Ninja를 우선적으로 선택한다.

빌드 도구를 make로 변경하고 싶다면 다음 과정을 따른다.

1. Ctrl + , 키로 설정을 연 후 Cmake: Generator 항목에 Unix Makefiles를 입력한다.
2. 프로젝트 루트의 build 폴더를 삭제한다.
3. Ctrl + Shift + P를 누른 후 CMake: Configure를 실행하여 설정을 재구성한다.

CMake Tools 확장의 빌드와 실행

상태 표시줄의 빌드(Build) 아이콘을 클릭하여 컴파일한 후, 실행(Run) 아이콘을 클릭한다. 아래 그림과 같이 터미널 탭에서 실행 결과를 확인할 수 있다.

CMake Tools의 주요 단축키는 다음과 같다.

• 빌드: F7
• 디버그 없이 실행: Ctrl + Shift + F5

여러 개의 main 함수 관리하기

학습 중에는 여러 소스 파일에 각각 main 함수를 두고 관리하고 싶을 때가 있다. add_executable을 매번 수동으로 추가하는 것은 번거로우므로, 다음과 같은 자동화 방법을 추천한다.

1. CMakeLists.txt에서 기존 add_executable(hello hello.cpp) 줄을 삭제하고 아래 내용을 추가한다. 하위 폴더를 재귀적으로 검색하여 main_으로 시작하는 모든 파일을 각각의 실행 파일로 등록한다.

# 폴더 아래의 main_*.cpp 파일을 모두 재귀적으로 찾기
file(GLOB_RECURSE MAIN_FILES "main_*.cpp")
foreach(main_file ${MAIN_FILES})
    get_filename_component(target_name ${main_file} NAME_WE)
    add_executable(${target_name} ${main_file})
endforeach()

2. 기존 hello.cpp 파일명을 main_hello.cpp로 변경한다.

3. Ctrl + Shift + P 키를 누른 후 CMake: Configure를 실행한다.

4. 테스트를 위해 다음 내용을 가진 main_goobye.cpp 파일을 생성한다.

#include <iostream>

int main() {
    std::cout << "Goodbye, WSL!" << std::endl;
    return 0;
}

5. 설정이 확실히 반영되도록 Ctrl + Shift + P 키를 누른 후 CMake: Delete Cache and Reconfigure를 실행한다.

6. 액티비티 바의 CMake 아이콘 클릭 후, Launch 항목의 편집 아이콘을 클릭하여 실행할 타겟을 선택한다.

7. 타겟을 선택한 후 상태 표시줄의 실행 아이콘을 누르면 해당 파일이 실행된다.

과정이 복잡해 보인다면 단축키를 설정하여 단순화할 수 있다.

예: CMake: Delete Cache and Reconfigure 단축키 Ctrl + Shift + F7 → CMake: Set Launch/Debug Target 단축키 Ctrl + Shift + F6 → CMake: Run Without Debugging 단축키 Ctrl + Shift + F5

코드 포맷 설정

소스 코드에서 마우스 오른쪽 버튼을 클릭하여 Format Document를 선택하거나 포맷 단축키를 누른다.

Microsoft C/C++ 확장의 인텔리센스를 비활성화했기 때문에 위와 같은 안내 창이 뜬다. Configure 버튼을 클릭한 후 포맷터로 clangd를 선택한다.

.clang-format 포맷 설정

C++ 코드 스타일은 .clang-format 파일로 관리하는 것이 표준이다. 프로젝트 루트에 파일을 생성하고 다음 내용을 입력한다. 구글 스타일(Google Style) 기반의 예시 설정이다.

BasedOnStyle: Google
IndentWidth: 2	# 들여쓰기 설정
ColumnLimit: 100  # 한 줄의 최대 길이 (보통 80~100자)
InsertTrailingNewline: true  # 파일 끝에 빈 줄 추가 활성화 - Clang 16 버전에서 처음 도입. 이전 버전 적용 안됨
AllowShortFunctionsOnASingleLine: Empty  # 중괄호 및 공백 설정
BreakBeforeBraces: Attach  # 구글 스타일: 함수 옆에 중괄호 붙이기

.clangd 설정

소스 파일을 열면 하단에 clangd 확장 아이콘이 표시된다. CMake 프로젝트의 표준인 build 디렉터리를 사용하면 clangd가 compile_commands.json을 자동으로 찾아 코드 분석, 정의 이동, 리팩토링 등을 수행한다.

.clangd 파일은 clangd의 동작을 세밀하게 제어한다. 프로젝트 루트에 파일을 생성하고 다음 설정을 추가해 보자.

CompileFlags:
  CompilationDatabase: build  # CMake 빌드 데이터베이스 위치 지정. build가 기본값이나 나중의 변경을 위해 명시.

Index:
  Background: Build  # 백그라운드 인덱싱 활성화. 코드 정의 이동 및 심볼 검색 속도 향상.

InlayHints:   # 코드 내 인라인 힌트 설정
  Enabled: Yes
  ParameterNames: Yes
  DeducedTypes: Yes
  Designators: Yes

Diagnostics: # 코드 진단 및 교정
  ClangTidy:
    Add: [modernize-*, readability-*, bugprone-*] 
    Remove: [modernize-use-trailing-return-type]
    CheckOptions:
      readability-identifier-naming.VariableCase: camelCase

설정을 변경했다면 Ctrl + Shift + P 키를 누른 후 clangd: Restart language server를 실행하여 적용한다.

관련 글

• WSL에 C/C++ 개발을 위한 패키지 설치하기

The post VS Code에 WSL의 C/C++ 개발 환경 설정하기 appeared first on bitneer.dev.

데비안(Debian) 계열 리눅스에서 C/C++ 개발을 하고자 할 때 build-essential 패키지를 설치한다. 이 패키지는 여러 필수 패키지를 의존성으로 묶어 한 번에 설치할 수 있게 돕는 메타 패키지이다. 메타 패키지는 실제 실행 파일은 포함하지 않고 의존성 정보만 가지고 있어 "빈 패키지(empty package)"라고도 부른다. 다음 명령어로 의존성을 확인할 수 있다. apt는 apt-get과 apt-cache 기능을 통합한 것이므로 apt depends 대신 apt-cache depends를 사용할 수도 있다.

$ apt depends build-essential
build-essential
 |의존: libc6-dev
  의존: <libc-dev>
    libc6-dev
  의존: gcc (>= 4:10.2)
  의존: g++ (>= 4:10.2)
  의존: make
    make-guile
  의존: dpkg-dev (>= 1.17.11)

gcc와 g++은 각각 C와 C++ 컴파일러이며, make는 빌드 자동화 도구이다. build-essential 패키지는 이러한 핵심 도구들에 의존하므로, 이를 설치하면 관련 도구들이 일괄 설치된다. 물론 필요에 따라 이들을 개별적으로 설치하는 것도 가능하다.

추가로 gdb와 cmake 패키지를 함께 설치하는 것이 좋다. gdb는 디버거이며, cmake는 현대적인 C/C++ 프로젝트 관리를 위한 표준 빌드 시스템 생성기이다. 특히 VS Code의 ‘CMake Tools’ 확장을 제대로 활용하기 위해서는 cmake 설치가 필수적이다.

패키지 설치 전에는 다음과 같이 패키지 목록 업데이트와 시스템 업그레이드를 먼저 수행한다.

$ sudo apt update && sudo apt upgrade

참고로 논리 AND(&&)는 앞선 명령이 성공했을 때만 뒷 명령을 실행하라는 의미이다. 이와 반대로 논리 OR(||)은 앞선 명령이 실패했을 때만 뒷 명령을 실행한다. (예: 명령이 실패할 경우 에러 메시지를 출력할 때 주로 사용한다.)

C/C++ 개발에 필요한 패키지들을 다음과 같이 설치한다.

$ sudo apt install build-essential gdb cmake

이미 설치된 패키지가 있다면 자동으로 제외하고 중복 설치하지 않는다. 다만, 새 패키지를 설치하는 과정에서 의존성 해결을 위해 기존 패키지가 업그레이드될 수는 있다.

dpkg -l 명령은 시스템에 설치된 모든 패키지 목록을 보여준다. 다음과 같이 파이프(|)와 grep을 연결하여 특정 패키지의 설치 여부를 확인할 수 있다.

$ dpkg -l | grep cmake
ii  cmake                              3.25.1-1                       amd64        cross-platform, open-source make system
ii  cmake-data                         3.25.1-1                       all          CMake data files (modules, templates and documentation)

또는 다음과 같이 버전 정보를 출력하여 설치 여부를 확인하거나, 실행 파일의 위치를 알려주는 which 명령어를 사용할 수 있다.

$ gcc --version
$ g++ --version
$ make --version
$ cmake --version
$ which g++

Clang 컴파일러 사용을 위한 개발 환경

GCC 대신 애플(Apple)이 주도하여 개발한 Clang 컴파일러를 사용할 수도 있다. Clang은 에러 메시지가 매우 명확하고 친절하며, Apache 2.0 라이선스를 채택해 기업 친화적이고 유연하다. 반면 GCC는 대부분의 리눅스 배포판 커널과 기본 시스템을 빌드하는 검증된 컴파일러이며, 런타임 성능 최적화가 매우 정교하다. 또한 GCC는 GPL 라이선스를 따르므로 소스 코드 공개 의무와 전염성이 강하다는 특징이 있다.

일반적으로 학습용이나 개발 단계에서는 친절한 에러 메시지 덕분에 오타나 문법 실수를 빠르게 교정할 수 있는 Clang을 사용하고, 실제 배포용 빌드에는 GCC를 사용하는 하이브리드 전략을 취하기도 한다. C++ 표준은 계속 발전하고 있지만, GCC와 Clang 모두 최신 표준을 빠르게 도입하고 있으므로 어떤 것을 선택해도 최신 문법 활용에는 지장이 없다.

Clang으로 개발 환경을 구축할 때는 가급적 Clang 기반의 전체 도구 세트(Toolchain)를 갖추는 것이 좋다. 주요 패키지 목록은 다음과 같다.

• clang: 컴파일러
• lldb: 디버거
• valgrind: 메모리 분석 도구
• clang-format: 코드 스타일 정리 도구
• clang-tidy: 정적 분석 도구

위 패키지들을 다음 명령으로 한 번에 설치한다.

$ sudo apt install clang lldb valgrind clang-format clang-tidy

Ninja 빌드 시스템 설치

현대적인 C++ 개발 환경에서 Ninja는 이미 make를 대체하는 표준으로 자리 잡았다. 대규모 오픈 소스 프로젝트를 분석할 때 ‘컴파일 데이터베이스(compile_commands.json)’ 파일을 생성해야 VS Code의 ‘C/C++’ 확장이나 ‘clangd’ 확장에서 코드 바로가기, 자동 완성 기능을 정확히 제공할 수 있다.

이 파일을 생성하기 위해 기존의 make와 bear를 조합하는 방법과 Ninja 빌드 시스템을 사용하는 두 가지 방법이 있다. 리눅스 커널이나 고전적인 C 라이브러리 등 오래된 프로젝트를 분석한다면 make + bear 조합이 적합하며, 현대적인 프로젝트라면 Ninja를 사용하는 것이 효율적이다.

다음과 같이 bear와 ninja-build 패키지를 설치하고, 가급적 make 대신 Ninja를 주력으로 사용하도록 한다.

$ sudo apt install bear ninja-build

예제 작성과 컴파일 테스트

VS Code의 C/C++ 관련 확장을 설치하기 전, 간단한 예제를 작성하여 명령줄(CLI)에서 설치한 컴파일러가 잘 작동하는지 확인해 본다. 윈도우 터미널을 통해 WSL에 접속한 후 프로젝트 디렉터리를 생성하고 이동한다.

$ mkdir wsl_cpp
$ cd wsl_cpp

vi나 VS Code를 사용하여 다음 내용을 입력하고 hello.cpp라는 이름으로 저장한다. 해당 디렉터리에서 code . 명령을 실행하면 현재 폴더를 작업 영역으로 하여 VS Code가 열린다.

#include <iostream>

int main() {
    std::cout << "Hello, WSL!" << std::endl;
    return 0;
}

$ g++ hello.cpp
$ ./a.out
Hello, WSL!

별도의 옵션 없이 컴파일하면 실행 파일 이름은 기본적으로 a.out으로 생성된다. 실행 시 ./와 같이 현재 디렉터리를 명시해야 하는데, 이는 유닉스 계열 시스템이 보안상의 이유로 현재 디렉터리를 실행 경로(PATH)에 포함하지 않기 때문이다. 반면 윈도우의 명령 프롬프트(CMD)는 현재 디렉터리를 실행 경로에 포함한다는 차이가 있다. 현재 실행 경로는 echo $PATH 명령어로 확인할 수 있다.

다음과 같이 -o 옵션을 사용하면 생성될 실행 파일의 이름을 직접 지정할 수 있다.

$ g++ -o hello hello.cpp
$ ./hello
Hello, WSL!

Clang의 경우 C 컴파일러는 clang, C++ 컴파일러는 clang++ 명령어를 사용한다. 다음과 같이 여러 옵션을 붙여 컴파일해 본다. (이 옵션들은 g++에서도 동일하게 사용할 수 있다.)

$ clang++ -Wall -std=c++17 -g -o hello hello.cpp
$ ./hello
Hello, WSL!

• -Wall: 모든 경고(Warning) 메시지를 출력한다.
• -std=c++17: 사용할 C++ 표준 버전을 명시한다.
• -g: 디버깅 정보를 포함하여 gdb나 lldb에서 사용할 수 있게 한다. (최종 제품 배포 시에는 이 옵션을 제외한다.)

이외에도 최적화 단계를 지정하는 옵션 등이 있으며, 이러한 설정값들은 주로 Makefile이나 Ninja 빌드 파일에서 정의하여 사용한다.

과거에는 유닉스나 리눅스 환경에서 vi, Emacs 같은 에디터만으로 작업해야 했고, 파이썬이 보급되기 전에는 복잡한 빌드 과정을 관리하기 위해 쉘 스크립트를 직접 작성해야 했다.

이제는 VS Code 덕분에 훨씬 편리한 환경에서 개발이 가능해졌다. VS Code에서 C/C++ 개발 관련 확장을 설치하고, 보다 효율적으로 개발 환경을 구축하는 방법으로 넘어가 보자.

관련 글

• VS Code에 WSL의 C/C++ 개발 환경 설정하기

참고 자료

• https://gcc.gnu.org/
• https://clang.llvm.org/
• CMake Reference Documentation
• https://ninja-build.org/
• https://github.com/rizsotto/Bear

The post WSL에 C/C++ 개발을 위한 패키지 설치하기 appeared first on bitneer.dev.

트랜잭션의 개요

데이터베이스의 여러 연산을 묶어 놓은 것을 사용자의 관점에서는 하나의 단위로 여겨질 수 있다. 예를 들어, 다른 계좌로 돈을 이체하는 것은 사용자의 관점에서 하나의 작업이지만, 데이터베이스 시스템 내에서는 여러 연산을 결합한 것이다. 이처럼, 하나의 논리적인 작업 단위를 위한 연산들의 모음을 트랜잭션(transaction)이라 한다.

데이터의 무결성(integrity)을 보장하려면, 데이터베이스 시스템은 트랜잭션의 다음과 같은 특성을 관리해야 한다.

• 원자성(atomicity): 트랜잭션의 모든 연산을 데이터베이스에 반영하든지, 아니면 전혀 반영하지 않아야 한다.
• 일관성(consistency): 고립 상태에 있는 트랜잭션의 실행은 데이터베이스의 일관성을 유지해야 한다. 고립 상태란 동시에 실행하는 다른 트랜잭션이 없다는 것을 의미한다.
• 고립성(isolation): 여러 개의 트랜잭션을 동시에 실행하더라도, 각 트랜잭션은 동시에 실행하고 있는 다른 트랜잭션을 인식하지 못해야 한다.
• 지속성(durability): 트랜잭션이 성공적으로 끝나면, 그 트랜잭션이 데이터베이스 시스템에 수정한 내용은 시스템 장애가 발생하더라도 영속적이어야 한다.

위의 특성 중에 격리 수준과 관련한 고립성에 대해 좀 더 알아보자.

고립성

여러 개의 트랜잭션을 동시에 실행하면 성능이 좋아진다. 그러나 여러 트랜잭션의 연산이 원하지 않는 방향으로 겹쳐 불일치 상태(inconsistent state)가 발생할 수 있다. 동시에 실행하는 트랜잭션의 문제를 해결하는 방법은 트랜잭션을 순차적으로 실행하는 것이다. 트랜잭션의 고립성(isolation)은 여러 개의 트랜잭션을 동시에 실행하여도, 이 트랜잭션들을 순차적으로 실행한 것과 같은 상태가 되도록 하는 특성이다.

이상현상

이상현상(Phenomena)은 동시 실행하는 여러 트랜잭션이 상호 작용하면서 나타날 수 있는 문제를 의미한다. 읽기 이상현상으로 dirty read, non-repeatable read, phantom read 세 가지가 있다. 쓰기 이상현상으로 lost update가 있다. 이상현상을 예제로 보이기 위해 간단한 student 테이블을 사용할 것이다.

Dirty Read

dirty read는 한 트랜잭션이 진행 중에, 다른 트랜잭션이 갱신은 하였으나 아직 commit하지 않은 데이터를 읽을 때 발생한다.

T2 트랜잭션에서 갱신은 하였으나 아직 커밋하지 않은 나이인 21을 T1 트랜잭션이 읽는다. T2에서 롤백하면 결국 T1은 이상한 값을 읽어 들인 셈이다.

Non-repeatable Read

non-repeatable read는 한 트랜잭션이 읽었던 데이터를 다시 읽을 때 데이터가 변경되는 것으로, 다시 읽기 전에 다른 트랜잭션이 데이터를 갱신하고 commit하기 때문에 발생한다. dirty read와 비슷해 보이지만 다른 트랜잭션에서 commit을 한다는 차이점이 있다.

T1 트랜잭션 내에서 age가 20과 21 두 개의 값을 갖는다. 의도하지 않은 결과가 발생할 수 있을 것이다.

Phantom Read

phantom read는 우리말로 ‘유령 읽기’ 정도로 바꿀 수 있겠다. 유령 읽기는 한 트랜잭션이 진행 중에, 다른 트랜잭션이 추가하거나 삭제한 행(row)의 데이터를 읽어 발생한다.

T1 트랜잭션에서 의도하지 않은 ‘장길산’ 이름을 가진 3번째 행이 나온다.

Lost Update(Dirty Write)

Lost Update는 ‘갱신 손실’로 대역할 수 있겠다. 갱신 손실은 한 트랜잭션이 데이터를 갱신한 후 다른 트랜잭션이 그 갱신한 값을 덮어쓸 때 발생한다. 다음의 예는 한 고객이 잔고가 1000원 계좌에서 500원을 인출하고 있는데 동업자가 400원을 동시에 출금하는 예이다.

잔고에 100원이 남아야 정상이지만 갱신 손실로 600원이 남았다. 위의 예에서 SQL 문을 사용하지 않고 수식으로 표현하였다. MariaDB, PostgreSQL에서 확인한 바로는 한 트랜잭션이 갱신을 한 상태에서 다른 트랜잭션이 동일 데이터에 갱신을 시도하면 대기를 하여야 한다. 즉, 데이터를 갱신한 트랜잭션이 commit이나 rollback을 하기 전에는 다른 트랜잭션은 동일 데이터를 갱신할 수 없다. 대부분의 DBMS 제품들은 모든 격리 수준에서 갱신 시 테이블이나 행(row)에 락(lock)을 걸어 lost update가 발생하지 않도록 하고 있다.

격리 수준(Isolation Level)

동시에 실행하는 트랜잭션들을 순차적인 실행 상태로 만드는 것은 성능에 좋지 않다. 성능과 일관성을 고려하여 트랜잭션에 격리 수준을 지정할 수 있다. SQL 표준은 네 종류의 트랜잭션 격리 수준을 정의하고 있다. 다음 항목에서 아래로 내려갈수록 일관성은 좋아지지만, 성능은 떨어진다.

• read uncommited: 다른 트랜잭션에서 commit하지 않은 데이터를 읽을 수 있다. 데이터의 정확도가 중요하지 않으면서 트랜잭션의 수행 시간이 긴 경우에 지정하여 사용할 수 있다.
• read commited: 다른 트랜잭션에서 commit한 데이터만을 읽는다.
• repeatable read: read commited와 동일하게 다른 트랜잭션에서 commit한 데이터만을 읽는다. 추가로 트랜잭션 진행 중에 읽었던 데이터를 다시 읽을 때, 그 중간에 다른 트랜잭션이 그 데이터를 갱신할 수 없다.
• serializable: 동시 진행하는 트랜잭션들이 순차적으로 실행한 것과 같은 결과가 나와야 한다. 직렬성(serializability)에 더하여 연쇄 복귀(rollback)도 없어야 한다.

SQL 표준은 serializable이 디폴트이다. 이 수준은 트랜잭션 간에 상호 작용이 전혀 없어야 하는 데 현실과는 맞지 않는다. 일반적인 데이터베이스 시스템은 read commited나 repeatable read를 디폴트로 사용한다. 또한, DBMS 제품마다 표준을 구현하는 방법은 다를 수 있다.

아래의 표는 각 격리 수준에서 발생할 수 있는 이상현상을 나타낸 것이다.

MySQL의 InnoDB엔진은 repeatable read 격리 수준에서 phantom read가 발생하지 않는다.

PostgreSQL도 마찬가지로 repeatable read 격리 수준에서 phantom read가 발생하지 않는다. 또한 트랜잭션을 read uncommitted로 설정은 할 수 있지만, dirty read는 발생하지 않는다.

참고 자료

• Database System Concepts, 3rd – Chapter 13 Transactions
• Isolation (database systems) – Wikipedia
• PostgreSQL 11.1 문서 – 13.2. 트랜잭션 격리
• MySQL :: MySQL 8.0 Reference Manual :: 15.7.2.1 Transaction Isolation Levels
• MariaDB Transactions and Isolation Levels for SQL Server Users – MariaDB Knowledge Base

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.

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.

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.