- 로 시작하는 파일명 삭제하기

리눅스/OS 일반|2023. 3. 31. 08:54
반응형

리눅스 쉘에서 파일명앞에 - 가 붙어 있어 삭제하기 어려운 경우가 있었습니다.

명령 뒤에 따라오는 옵션으로 판단하고 삭제가 되지 않았던 것인데

알고보면 삭제 방법은 간단합니다.

 

-로 시작되는 파일 확인

# ls

-test.txt

 

삭제 실패 명령어들

# rm -test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

 

# rm \-test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

 

# rm '-test.txt'
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

 

# rm "-test.txt"
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

 

삭제 성공 명령어

디렉토리를 포함하여 삭제할 파일명을 지정하면 됩니다.

# rm ./-test.txt
rm: remove 일반 빈 파일 `./-test.txt'? y

반응형

댓글()

PDNS (PowerDNS) 4.2 시스템 로그 및 쿼리 로그 설정

리눅스/DNS|2023. 3. 30. 07:52
반응형

PDNS 로그를 수집하고자 할때 아래와 같이 설정하면 됩니다.

아래는 PDNS 4.2 에서 테스트 하였습니다.

 

1. 설정

데몬 구동 파일을 백업하고 수정합니다.

# cp -arp /usr/lib/systemd/system/pdns.service /usr/lib/systemd/system/pdns.service.bak

# vi /usr/lib/systemd/system/pdns.service

...
[Service]
Type=notify
# rsyslog 사용하도록 아래 --disable-syslog 옵션 삭제
ExecStart=/usr/sbin/pdns_server --guardian=no --daemon=no --disable-syslog --log-timestamp=no --write-pid=no
# rsyslog 설정으로 넘겨주도록 아래 설정 추가
SyslogFacility=local0
SyslogLevel=debug
...

 

PDNS 설정을 추가합니다.

# vi /etc/pdns/pdns.conf

...
logging-facility=0
log-dns-details=yes  # DNS 설정 상 잘못된 세부 정보 로깅
log-dns-queries=yes # 유입되는 모든 질의 로깅
loglevel=5

...

 

rsyslog 설정을 추가합니다.

서비스 데몬 설정 상 debug level 로 해놓아서 아래 로깅 설정이 중요합니다.

vi /etc/rsyslog.conf

...
local0.=info                                    /var/log/pdns/pdns.info
local0.=warn                                  /var/log/pdns/pdns.warn
local0.=err                                     /var/log/pdns/pdns.err
local0.=debug                                /var/log/pdns/pdns.debug
...

 

로그 디렉토리를 생성합니다.

# mkdir /var/log/pdns

2. 적용

# systemctl daemon-reload
# systemctl restart pdns
# systemctl restart rsyslog

 

3. 확인

# cd /var/log/pdns
# ll
합계 145288
drwxr-xr-x  2 root root      4096  3월 29 09:41 .
drwxr-xr-x. 9 root root      4096  3월 29 16:37 ..
-rw-------  1 root root 147126477  3월 30 07:46 pdns.debug
-rw-------  1 root root       998  3월 29 09:30 pdns.err
-rw-------  1 root root      1331  3월 29 09:27 pdns.info
-rw-------  1 root root   1619633  3월 29 09:39 pdns.warn

 

pdns.debug 파일에 도메인 질의했던 Remote IP 와 Record Type, Domain name 등 정보가 간략히 출력되는데

참고로 packetcache 값은 아래 의미를 가지고 있습니다.

- HIT : 이전에 처리된 DNS 쿼리 결과가 캐시에 저장되어 있고, 현재 처리중인 쿼리와 동일한 결과를 반환할 수 있습니다.

           이 경우, pdns 서버는 저장된 정보를 즉시 반환하므로, 쿼리 처리 시간이 매우 빠릅니다.
- MISS : 이전에 처리된 DNS 쿼리 결과가 캐시에 없으며, 실제 DNS 서버에서 새로운 쿼리를 처리해야 합니다.

              이 경우, pdns 서버는 실제 DNS 서버로부터 결과를 가져와서 반환해야 하므로, 쿼리 처리 시간이 증가할 수 있습니다.

 

* 참고

도메인 질의가 많은 서버의 경우 로그 파일 사이즈도 방대하게 늘어나기 때문에

아래 URL 참고하여 logrotate 로 로그 파일을 관리 하면 됩니다.

(내용중 PDNS 설정 부분 참조)

https://sysdocu.tistory.com/63

반응형

댓글()

[ShellScript] 로그 파일 실시간 감시 및 마지막행 처리 방법

프로그래밍/BASH SHELL|2023. 3. 29. 10:57
반응형

쉘스크립트 파일을 아래 내용으로 작성하고 실행하면 됩니다.

 

# vi monitor_and_run.sh

#!/bin/bash

FILE="/home/sysdocu/app.log" # 감시할 파일명

# 파일 감시 및 처리
tail -F -n 0 "$FILE" |\
while read line
do
    # 로그에서 특정 문자열 확인 및 처리
    case "$line" in
        *"test"*) # 여기에 일치되는 문자열
            echo 마지막으로 추가된 행 내용 : $line
        ;;
   esac
done

 

* 결과

마지막으로 추가된 행 내용 : 이건 test 입니다.

마지막으로 추가된 행 내용 : lasttest

마지막으로 추가된 행 내용 : test

마지막으로 추가된 행 내용 : test 끝

 

반응형

댓글()

네임서버 DNS 퍼포먼스 테스트 (dnsperf)

리눅스/DNS|2023. 3. 28. 16:14
반응형

네임서버 성능을 확인하기 위해 다량의 도메인 질의를 해 볼 수 있습니다.

아래 설치 및 사용 방법을 확인해 주세요.

CentOS 7 기준으로 작성되었습니다.

 

1. 설치

# cd /usr/local/src

# wget https://www.dns-oarc.net/files/dnsperf/dnsperf-2.3.2.tar.gz
# tar xfvz dnsperf-2.3.2.tar.gz
# cd dnsperf-2.3.2/
# ./configure
# make
# make install

 

2. 사용

도메인을 질의하기 위해 테스트 또는 유명 도메인과 A 레코드를 질의하기 위해 A 값을 파일로 만듭니다.

# echo "sysdocu.kr A" > list.txt

 

아래와 같은 형식으로 테스트가 가능합니다.

# dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1

* 옵션 설명

- s : 네임서버 IP 또는 도메인 (생략시 127.0.0.1)

- d : 도메인 또는 도메인이 들어있는 파일명

- T : 사용할 스레드 수

- Q : 쿼리량

- l : 질의 지속 시간 (초)

 

1초에 1000개 쿼리 수행 결과는 아래와 같이 나옵니다.

DNS Performance Testing Tool
Version 2.3.2

[Status] Command line: dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1
[Status] Sending queries (to 8.8.8.8)
[Status] Started at: Tue Mar 28 16:16:00 2023
[Status] Stopping after 1.000000 seconds
[Status] Testing complete (time limit)

Statistics:

  Queries sent:         1000
  Queries completed:    1000 (100.00%)
  Queries lost:         0 (0.00%)

  Response codes:       NOERROR 1000 (100.00%)
  Average packet size:  request 28, response 112
  Run time (s):         1.000256
  Queries per second:   999.744066

  Average Latency (s):  0.000880 (min 0.000374, max 0.019629)
  Latency StdDev (s):   0.001580

반응형

댓글()

Openshift Pod 상태 로그 보는 방법 두가지

리눅스/OpenShift|2023. 3. 27. 08:48
반응형

oc get pods 로 출력되는 Pod 에 Running 상태가 아닌 값이 있을경우 원인을 확인하기 위해 보통 아래 두가지 방법을 사용합니다.

 

 

에러 확인

# oc get pods
NAME                         READY   STATUS         RESTARTS   AGE
my-app11-6c7c9dcd7c-z6cww    0/1     ErrImagePull   0          12s

 

 

1. oc logs

# oc logs my-app11-6c7c9dcd7c-z6cww
Error from server (BadRequest): container "my-app11" in pod "my-app11-6c7c9dcd7c-z6cww" is waiting to start: trying and failing to pull image

 

이미지를 가져올 수 없다는 로그가 확인 되었는데, 이미지를 왜 가져올 수 없는지는 아래처럼 자세히 살펴볼 수 있습니다.

 

 

2. oc describe

# oc describe pod my-app11-6c7c9dcd7c-z6cww
Name:             my-app11-6c7c9dcd7c-z6cww
Namespace:        deploy
Priority:         0
Service Account:  default
Node:             worker01.az1.sysdocu.kr/115.68.142.104
Start Time:       Fri, 24 Mar 2023 10:30:18 +0900
Labels:           deployment=my-app11
                  pod-template-hash=6c7c9dcd7c
Annotations:      k8s.v1.cni.cncf.io/network-status:
                    [{
                        "name": "openshift-sdn",
                        "interface": "eth0",
                        "ips": [
                            "10.128.2.44"
                        ],
                        "default": true,
                        "dns": {}
                    }]
                  k8s.v1.cni.cncf.io/networks-status:
                    [{
                        "name": "openshift-sdn",
                        "interface": "eth0",
                        "ips": [
                            "10.128.2.44"
                        ],
                        "default": true,
                        "dns": {}
                    }]
                  openshift.io/generated-by: OpenShiftNewApp
                  openshift.io/scc: anyuid
Status:           Pending
IP:               10.128.2.44
IPs:
  IP:           10.128.2.44
Controlled By:  ReplicaSet/my-app11-6c7c9dcd7c
Containers:
  my-app11:
    Container ID:   
    Image:          my-app11:latest
    Image ID:       
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-q4sh6 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-q4sh6:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Normal   Scheduled       16m                default-scheduler  Successfully assigned deploy/my-app11-6c7c9dcd7c-z6cww to worker01.az1.sysdocu.kr
  Normal   AddedInterface  16m                multus             Add eth0 [10.128.2.44/23] from openshift-sdn
  Normal   Pulling         14m (x4 over 16m)  kubelet            Pulling image "my-app11:latest"
  Warning  Failed          14m (x4 over 16m)  kubelet            Failed to pull image "my-app11:latest": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/my-app11: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
  Warning  Failed   14m (x4 over 16m)   kubelet  Error: ErrImagePull
  Warning  Failed   14m (x6 over 16m)   kubelet  Error: ImagePullBackOff
  Normal   BackOff  69s (x63 over 16m)  kubelet  Back-off pulling image "my-app11:latest"

 

접근 권한 문제로 확인되었습니다.

이경우 secret 을 이용해 사용자 계정 생성 및 권한 부여 등의 작업을 진행하면 됩니다.

이렇게 서비스에 문제가 생기게 될 경우 로그를 확인하는 두개 명령을 사용해 보시기 바랍니다.

 

반응형

댓글()

Openshift GitLab-CE 컨테이너 배포하기

리눅스/OpenShift|2023. 3. 24. 10:21
반응형

GitLab 은 웹 기반의 Git 저장소 관리 및 지속적인 통합, 배포를 제공하는 소프트웨어 개발 플랫폼입니다.

GitLab-CE (Community Edition) 컨테이너 서비스를 배포하기 위해 아래와 같은 절차를 진행합니다.


gitlab-ce 이미지를 다운로드 받습니다.
# docker pull gitlab/gitlab-ce
* docker.io 주소를 빼도 다운로드 됩니다.

다운로드 받은 이미지를 이용하여 어플리케이션을 배포합니다.
# oc new-app docker.io/gitlab/gitlab-ce

Pod 상태 확인을 하면 Running 과 Error 를 반복하다가 최종 CrashLoopBackOff 상태로 종료됩니다.
# oc get pod
NAME                         READY   STATUS             RESTARTS      AGE
gitlab-ce-549cbd9f47-5xcw5   0/1     CrashLoopBackOff   2 (13s ago)   84s

아래와 같은 로그가 확인됩니다.
# oc logs gitlab-ce-549cbd9f47-5xcw5
Thank you for using GitLab Docker Image!
Current version: gitlab-ce=15.10.0-ce.0

Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
And restart this container to reload settings.
To do it use docker exec:

  docker exec -it gitlab editor /etc/gitlab/gitlab.rb
  docker restart gitlab

For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md

If this container fails to start due to permission problems try to fix it by executing:

  docker exec -it gitlab update-permissions
  docker restart gitlab

Cleaning stale PIDs & sockets
cat: /var/opt/gitlab/gitlab-rails/VERSION: No such file or directory
Preparing services...
ln: failed to create symbolic link '/opt/gitlab/service/sshd': Permission denied

현재 프로젝트 (project412) 서비스어카운트에 anyuid 권한이 없기 대문입니다.
아래와 같이 권한을 부여 합니다. (add-scc-to-user)
# oc adm policy add-scc-to-user anyuid system:serviceaccount:project412:default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default"
- project412 : 현재 프로젝트명 (oc project 로 확인 가능)

오류 발생되었던 deployment 와 service 를 삭제하고 Pod 를 재생성 합니다.
# oc delete deployment gitlab-ce
# oc delete service gitlab-ce

# oc new-app docker.io/gitlab/gitlab-ce


상태를 확인해보면 상태값이 올바르게 Running 으로 표시되었습니다.
# oc get pods
NAME                         READY   STATUS    RESTARTS   AGE
gitlab-ce-7cfcc46b75-ltgx4   1/1     Running   0          62s

사용하는 서비스 포트를 확인합니다.
# oc get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                 AGE
gitlab-ce        ClusterIP   172.30.199.183   <none>        22/TCP,80/TCP,443/TCP   2m4s

같은 포트 번호로 라우팅을 생성하여 외부에서 접근 가능하도록 합니다.
# oc expose service gitlab-ce --port 80
route.route.openshift.io/gitlab-ce exposed
# oc get route
NAME             HOST/PORT                                   PATH   SERVICES         PORT    TERMINATION   WILDCARD
gitlab-ce        gitlab-ce-deploy.apps.az1.sysdocu.kr               gitlab-ce        80                    None

출력된 호스트명과 포트를 이용하여 브라우저로 접속하면 서비스가 정상 확인됩니다.
(GitLab Community Edition 로그인 화면)
http://gitlab-ce-deploy.apps.az1.sysdocu.kr

Pod 생성을 위해 주었던 서비스어카운트의 CSS 권한을 제거합니다. (remove-scc-from-user)
# oc adm policy remove-scc-from-user anyuid system:serviceaccount:project412:default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid removed: "default"
- project412 : 현재 프로젝트명 (oc project 로 확인 가능)

반응형

댓글()

[Openshift 에러] remote error: tls: internal error

리눅스/OpenShift|2023. 3. 23. 11:21
반응형

[상황]
Pod 에 접속시도 할때 해당 메세지가 출력되거나,

# oc rsh mysql-bd544cdb8-m7p6n
Error from server: error dialing backend: remote error: tls: internal error


Pod 의 로그를 보려해도 같은 메세지가 출력됩니다.
# oc logs mysql-bd544cdb8-m7p6n
Error from server: Get "https://115.68.142.105:10250/containerLogs/deploy/mysql-bd544cdb8-m7p6n/mysql": remote error: tls: internal error


[해결]
보류중인 CSR (Certificate Signing Requests) 을 확인하고 Pending 되어 있는것을 확인합니다.
# oc get csr

출력된 이름을 이용하여 보류중인 CSR 을 승인합니다.
# oc adm certificate approve csr-c4zbq
certificatesigningrequest.certificates.k8s.io/csr-c4zbq approved

참고로 보류 중인 모든 CSR 을 승인하려면 다음 명령을 수행합니다.
# oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

 

 

[참고]

한개의 CSR 을 삭제하려면

# oc delete csr <CSR 이름>

 

모든 CSR 을 한번에 지우려면

# oc delete csr --all

 

반응형

댓글()

Openshift registry 내부 레지스트리에 로그인되지 않는 경우

리눅스/OpenShift|2023. 3. 20. 11:20
반응형

레지스트리 도메인 인증서를 Let's encrypt 에서 발급받고 로그인 시도 하였을때 아래와 같은 에러가 출력되었습니다.

이는 Let's encrypt 발행자가 시스템에서 인증되지 않은 경우에 발생한 문제입니다.

 

# podman login -u admin -p 12345678 default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000

Error: error authenticating creds for "default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000": error pinging docker registry default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000: Get https://default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/v2/: x509: certificate signed by unknown authority

 

이 경우 아래와 같이 인증 과정을 거치면 로그인이 가능해 집니다.

인증서를 다운로드 (추출) 합니다.

 

# openssl s_client -showcerts -connect default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000 < /dev/null 2> /dev/null | openssl x509 -outform PEM > myregistry.crt

 

Podman 이 인증서를 참조할 수 있도록 인증서를 복사합니다.

# mkdir -p /etc/docker/certs.d/default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/

# cp -arp myregistry.crt /etc/docker/certs.d/default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/ca.crt

 

로그인을 시도 합니다.

# podman login -u admin -p 12345678 default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000
Login Succeeded!

 

반응형

댓글()

oc patch configs.imageregistry.operator.openshift.io 명령으로 삭제한 이미지 레지스트리 복구하기

리눅스/OpenShift|2023. 3. 17. 16:21
반응형

다음과 같이 삭제하였다면 다시 복원이 가능합니다.

 

[ 삭제 ]

# oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Removed"}}' --type='merge'
config.imageregistry.operator.openshift.io/cluster patched

 

Terminating 상태이므로 시간이 지나 삭제 됩니다.

# oc get pods -n openshift-image-registry
NAME                                              READY   STATUS        RESTARTS        AGE
cluster-image-registry-operator-77bbb4466-c4nwt   1/1     Running       2 (3h22m ago)   4h8m
image-registry-5f94b4bb5b-r89vg                   1/1     Terminating   0               19m
node-ca-2lkrw                                     1/1     Running       0               104m
node-ca-nxlsk                                     1/1     Running       0               3h27m
node-ca-pcbjq                                     1/1     Running       0               3h27m
node-ca-sxm58                                     1/1     Running       0               104m
node-ca-zdx88                                     1/1     Running       0               3h27m

 

[ 복원 ]

지워진 상태를 확인합니다.

# oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath='{.spec.managementState}'
Removed

 

상태를 변경합니다.

# oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Managed"}}' --type='merge'
config.imageregistry.operator.openshift.io/cluster patched

 

상태를 재확인합니다.

# oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath='{.spec.managementState}'
Managed

 

상태 변경 명령 직후 Pod 를 확인하면 image-registry 가 Terminating 으로 보이는데, 시간이 조금 더 지나면 Running 상태로 돌아옵니다.

image-registry 가 되살아난 것이 확인되었습니다.

# oc get pod -n openshift-image-registry -l docker-registry=default

NAME                                              READY   STATUS    RESTARTS        AGE
image-registry-6dfb9c8f99-xbzbd                   0/1     Running   0               5s

 

단, PVC 구성은 변경되지 않았으므로, PVC 구성 변경이 필요한 경우 PVC 및 Image Registry 삭제를 하고 아래 매뉴얼을 참고하여 재구성 합니다.

https://sysdocu.tistory.com/1776

 

반응형

댓글()

Rocky Linux 8.x 에서 Let's encrypt 설치 및 SSL 발급받기 (와일드카드)

리눅스/OS 일반|2023. 3. 14. 14:29
반응형

*.sysdocu.kr 과 같이 여러개의 서브도메인 인증서를 각각 받지 말고 와일드카드 문자를 이용해 하나의 인증서만 발급받으면 관리가 편한 장점이 있습니다.

아래와 같이 간단하게 발급받을 수 있으며, 방법은 사용이 가능한 기본 도메인과 와일드카드 문자가 들어간 도메인을 같이 발급받으면 됩니다.

 

1. 설치

# yum -y install letsencrypt certbot

 

2. 발급

# certbot certonly --manual --preferred-challenges=dns -d sysdocu.kr -d "*.sysdocu.kr"

발급할때 도메인 주인이 맞는지 확인하는 과정이 나옵니다.

출력된 value 값을 DNS 에 TXT 형식으로 추가해 보라는 것입니다.

 

예)

Please deploy a DNS TXT record under the name:
_acme-challenge.sysdocu.kr.
with the following value:
e9s7AlTjBg9VN_H0eDfYLOiF6QvXiIZotAbWQ0EVibA

 

엔터를 치면 한개 더 해보라고 합니다.

(입력한 도메인이 두개라서 두번 요청하는 듯 보임)

 

예)

Please deploy a DNS TXT record under the name:
_acme-challenge.sysdocu.kr.
with the following value:
Ei0XXe8aAlzIyu_RQdQuk-qPmR1RxpHtuhYsAyHq05M

 

저는 네임서버가 bind 로 구성되어 있어 zone 파일에 아래와 같이 추가하고 데몬을 reload 하였습니다.

_acme-challenge.sysdocu.kr. IN TXT WMeM_AiR_OPKOo_8R8MxzSwnGAXktK8Q6mQbx-A5r_k
_acme-challenge.sysdocu.kr. IN TXT 6lEcqLN9LlomU23A28ycDsVSvezrEvRiidA5F7a2gHs

 

다시 발급화면으로 돌아가 엔터를 치면, 발급이 성공하였다는 메세지가 출력됩니다.

인증서는 아래 경로에 잘 저장이 된것을 확인하였습니다.

 

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sysdocu.kr/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/sysdocu.kr/privkey.pem
This certificate expires on 2023-06-12.
These files will be updated when the certificate renews.

 

# ll /etc/letsencrypt/live/sysdocu.kr/
합계 4
-rw-r--r-- 1 root root 692  3월 14 14:17 README
lrwxrwxrwx 1 root root  34  3월 14 14:17 cert.pem -> ../../archive/sysdocu.kr/cert1.pem
lrwxrwxrwx 1 root root  35  3월 14 14:17 chain.pem -> ../../archive/sysdocu.kr/chain1.pem
lrwxrwxrwx 1 root root  39  3월 14 14:17 fullchain.pem -> ../../archive/sysdocu.kr/fullchain1.pem
lrwxrwxrwx 1 root root  37  3월 14 14:17 privkey.pem -> ../../archive/sysdocu.kr/privkey1.pem

 

# ll /etc/letsencrypt/archive/sysdocu.kr/
합계 20
-rw-r--r-- 1 root root 1846  3월 14 14:17 cert1.pem
-rw-r--r-- 1 root root 3749  3월 14 14:17 chain1.pem
-rw-r--r-- 1 root root 5595  3월 14 14:17 fullchain1.pem
-rw------- 1 root root 1704  3월 14 14:17 privkey1.pem

 

* 참고

갱신시 파일이름이 변경되므로 라이브 디렉토리 ( /etc/letsencrypt/live/sysdocu.kr/ ) 에 있는 인증서를

설정 등에 사용하시면 편리합니다.

 

* 참고

자동 갱신을 원할 경우 쉘스크립트를 만들고 아래 명령을 추가합니다.

certbot renew --quiet --no-self-upgrade

 

그리고 crond 등의 스케쥴러에 등록하여 사용하시면 됩니다.

인증서는 3개월 사용이 가능하며 만료 1개월 전부터 갱신이 가능하니

매월 보름간격으로 체크하도록 하면 문제없이 갱신이 됩니다.

0 0 1,16 * * root /root/ssl-renew.sh

 

반응형

댓글()

PostgreSQL 13.7 Replication 설정 (RockyLinux 9.0)

리눅스/MySQL|2023. 3. 10. 13:38
반응형

본 매뉴얼에서는 PostgreSQL 동기화 방식중 마스터 서버 로그를 이용해 동기화 하는 Streaming 방식으로 진행합니다.

이 방식은 단점이 하나 있는데 마스터 서버와 슬레이브 서버간의 네트워크 단절 시간이 길어지면 마스터 서버의 WAL 파일이 덮어 씌워져 (구버전에서는 파일 개수 지정, 신버전에서는 용량 지정 가능) 슬레이브 서버로 데이터를 전송하기도 전에 옛날 데이터는 지워져 버리는 경우가 생길 수 있습니다. 이경우 다시 Replication 을 구성해야 하지만 Streaming 방식은 9.0 이상에서 지원되는 최신 기술이고 속도가 빠른 장점이 있어 본 매뉴얼의 동기화 방식으로 채택하였습니다. 일반적으로 많이 사용하는 방식 이기도 합니다.

추가 정보는 공식 홈페이지 Documents (https://www.postgresql.org/docs/) 를 참고해 주세요.

버전에 따라 옵션 이름이 다른 경우가 있으므로 해당 버전의 Document 를 찾아서 보는것이 좋습니다.

여기에서는 최소한의 옵션을 이용하여 동기화를 해보도록 하겠습니다.

 

 

[ 테스트 환경 ]

- OS : RockyLinux 9.0

- 서버 수량 : 2대 (마스터 192.168.1.2 / 슬레이브 192.168.1.3)

- 사용 버전 : PostgreSQL 13.7

 

* 데이터 안전을 위해 작업전 백업은 필수 입니다.

 

 

1. PostgreSQL 설치

 

(모든 서버에서)

# yum -y update

# yum -y install postgresql postgresql-server

 

부팅시 데몬이 자동 구동 되도록 허용합니다.

# systemctl enable postgresql

 

PostgreSQL 설치시 자동 생성된 postgres 계정으로 데이터베이스를 초기화 합니다.

# sudo -u postgres /usr/bin/initdb -D /var/lib/pgsql/data

 

초기화가 완료 되었으면 데몬을 시작합니다.

# systemctl start postgresql

 

 

2. 테스트 DB 생성 및 데이터 입력

 

(마스터 서버에서)

postgres 계정으로 postgresql 에 접속합니다.

# sudo su - postgres

$ psql
psql (13.7)
Type "help" for help.

postgres=# 

 

테스트를 위해 임의의 데이터베이스, 테이블을 생성하고 데이터를 입력합니다.

postgres=# CREATE DATABASE sysdocudb;

postgres=# CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL, email VARCHAR(50) NOT NULL);

postgres=# INSERT INTO users (name, email) VALUES ('CDH', 'cdh@tistory.com'), ('CJE', 'cje@tistory.com');

 

입력된 데이터를 확인합니다.

postgres=# SELECT * FROM users;

 id | name |      email      
----+------+-----------------
  1 | CDH  | cdh@tistory.com
  2 | CJE  | cje@tistory.com
(2 rows)

 

PostgreSQL 명령행을 빠져나갈 경우 아래와 같이 실행합니다.

postgres=# \q

 

 

3. 계정 생성

 

(마스터 서버에서)

복제를 위해 데이터베이스에 접근 할 수 있는 Replication 전용 계정을 생성합니다.

postgres=# CREATE ROLE repluser WITH REPLICATION PASSWORD '12345678' LOGIN;

 

생성된 계정을 확인합니다.

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
 repluser  | Replication                                                | {}

 

 

4. 마스터 서버 설정

 

PostgreSQL 설정 파일에서 생성한 계정의 권한을 줍니다.

root 사용자로 전환 후 아래 파일에 인증 및 권한 설정을 추가합니다.

# vi /var/lib/pgsql/data/pg_hba.conf

...
host    all             all             0.0.0.0/0               trust
host    replication    repluser    192.168.1.3/32    mp5

- 첫번째줄 : 모든 IP 에서 원격 접근 허용

- 두번째줄 : 위에서 생성했던 replication 전용 계정과 접근 허용할 슬레이브 서버 IP

 

다른 설정 파일에서 복제 관련 옵션을 아래 값으로 설정합니다.

# vi /var/lib/pgsql/data/postgresql.conf

...
listen_addresses = '*'
wal_level = replica
...

- listen_addresses : 접속을 허용할 서버 아이피 주소 (client 아이피 아님 주의)

- wal_level : Replication의 레벨을 설정합니다. replica로 설정하면 replication을 위한 모든 WAL 데이터를 생성합니다.

 

설정 적용을 위해 postgresql 데몬을 재시작 합니다.

# systemctl restart postgresql

또는 postgres 계정으로 데몬을 재시작

# sudo su - postgres
$ pg_ctl reload
server signaled

 

 

5. 슬레이브 서버 설정

 

(슬레이브 서버에서)

마스터 서버에 데이터를 한차례 전부 가져와야 합니다.

아래는 명령 수행 전 확인사항입니다.

- 슬레이브 서버의 설정 파일 백업 (postgresql.conf)

   # cp -arp /var/lib/pgsql/data/postgresql.conf /root/

- 슬레이브 서버의 data 디렉토리는 비워 놓기

   # rm -rf /var/lib/pgsql/data/*

- 마스터 서버에서 방화벽 확인 (TCP 5432)

 

모두 확인 되었으면 postgres 계정으로 데이터 복사 명령을 수행합니다.

# sudo -u postgres pg_basebackup -h 192.168.1.2 /var/lib/pgsql/data -U repluser -v -P --wal-method=stream --write-recovery-conf

 

별도로 백업했었던 설정 파일을 복원하고 내용을 수정합니다.

data 디렉토리를 복사해왔기 때문에 conf 파일도 바뀌었기 때문입니다.

# cp -arp /root/postgresql.conf /var/lib/pgsql/data/

# vi /var/lib/pgsql/data/postgresql.conf

...
primary_conninfo = 'host=192.168.1.2 port=5432 user=repluser password=12345678'
...

- primary_conninfo : 마스터 서버에 접근하기 위한 replication 계정 정보

 

# systemctl restart postgresql

 

아래 파일이 자동 생성되며 동기화가 시작됩니다.

/var/lib/pgsql/data/standby.signal

 

마스터 서버에서 insert 쿼리를 실행하면 슬레이브 서버에서도 데이터 확인이 가능합니다.

마스터 서버에서 상태값 호출로 확인하는 방법도 있습니다.

# SELECT * FROM pg_stat_activity where usename='repluser';
 datid | datname |  pid   | leader_pid | usesysid | usename  | application_name |  client_addr   | client_hostname | client_port |         backend_start         | xact_start |          query_start       
   |         state_change          | wait_event_type |  wait_event   | state  | backend_xid | backend_xmin |                  query                  | backend_type 
-------+---------+--------+------------+----------+----------+------------------+----------------+-----------------+-------------+-------------------------------+------------+----------------------------
---+-------------------------------+-----------------+---------------+--------+-------------+--------------+-----------------------------------------+--------------
       |         | 109299 |            |    16393 | repluser | walreceiver      | 192.168.1.3 |                 |       38854 | 2023-03-13 16:55:25.630835+09 |            | 2023-03-13 16:55:25.644428+
09 | 2023-03-13 16:55:25.644449+09 | Activity        | WalSenderMain | active |             |              | START_REPLICATION 0/12000000 TIMELINE 1 | walsender
(1 row)

 

반응형

댓글()