Cloud

vsftp 익명 읽기/쓰기 설정

Firewall — Thu, 6 Feb 2025 20:33:59 +0900

vsftpd 에 익명으로 읽기/쓰기는 home directory 에서 안됩니다.

이점을 기억하시고 서브 디렉토리를 만들어서 설정하시면 됩니다. (예 uploads/ )

# 익명 사용자를 허용합니다.
anonymous_enable=YES

# 익명 사용자의 루트 디렉토리를 설정합니다.
anon_root=/ftp_root

# 파일 쓰기를 허용합니다.
write_enable=YES

# 익명 사용자가 파일을 업로드할 수 있도록 허용합니다.
anon_upload_enable=YES

# 익명 사용자가 디렉토리를 생성할 수 있도록 허용합니다.
anon_mkdir_write_enable=YES

# 익명 사용자가 파일 삭제 및 이름 변경을 할 수 있도록 허용합니다.
anon_other_write_enable=YES

# 익명 사용자가 생성하는 파일 및 디렉토리의 기본 권한을 설정합니다.
anon_umask=0022

# 로컬 사용자를 chroot 환경에 가둡니다.
chroot_local_user=YES

# chroot 환경에서 쓰기 가능한 디렉토리를 허용합니다.
allow_writeable_chroot=YES

# 패시브 모드를 활성화합니다.
pasv_enable=YES

# 패시브 모드에서 사용할 최소 포트 번호를 설정합니다.
pasv_min_port=10000

# 패시브 모드에서 사용할 최대 포트 번호를 설정합니다.
pasv_max_port=10050

# standalone 모드에서 vsftpd를 실행합니다.
listen=YES

# vsftpd가 수신할 포트 번호를 설정합니다.
listen_port=2020

X-Real-IP vs X-Forwared-IP 차이

Firewall — Mon, 30 Sep 2024 19:42:58 +0900

node 백엔드에서 원격지 웹서버의 client IP header 를 가져오는데 127.0.0.1 (undefinded) 라는 헤더값이 온다고 연락 받았습니다.

제가 proxy.conf 를 잘못 설정했나 var/log/nginx access로그를 보니

1.1.1.1 - - [30/Sep/2024:17:04:51 +0900] "POST /api/v1/aa HTTP/1.1" 200 8770 "-" "BestHTTP/2 v2.8.4" "-"
2.2.2.2 - - [30/Sep/2024:17:05:04 +0900] "POST /api/v1/bb HTTP/1.1" 200 8770 "-" "BestHTTP/2 v2.8.4" "-"

값은 잘 찍히고 있었습니다. 이로 미루어 보아 헤더값이 제대로 나올 것 같다는 합리적인 추론을 하였습니다.

가지고 오는 헤더를 전부 찍게 해 보니 파싱하는 값의 하이픈이 잘못되었다는 것이 확인되었습니다.

여기서

X-Real-IP 는 nginx 에서 직전에 거치는 IP

X-Forwared-For 는 src-IP 입니다.

따라서 X-Forwared-For 를 일반적으로 쓰시는 게 정신건강에 좋을 것으로 생각됩니다.

어쨌든 node 백엔드에서 헤더값 파싱 부분을 수정하여 문제가 해결되었습니다.

다들 이렇게 하시겠지만, 애매할때는 전부 찍어보시는 것을 추천합니다.

감사합니다.

온프라미스에서 테라폼 사용하기

Firewall — Wed, 25 Sep 2024 19:01:55 +0900

테라폼을 온프라미스에서도 적용할 수 있는지 질문을 받았습니다.

하이퍼 바이저를 사용하지 않고 적용한다는 것은 별로 생각해 보지 않았고, 적용을 했을 때라도 자원을 논리적으로 프로비저닝 할 수 없으니, 그다지 효율적이지는 않아 보입니다. 그래도 안정성은 그대로 가져가면서, 자동화의 영역을 넓힐 수 있다면 안할 이유도 없어 보입니다.

단 tf 파일이 삭제될때는 어떻게 동작될지도 확인이 필요합니다.(그리고 언제적 PXE 기술을 꺼내는 것인지.)

대략적인 구성을 생각해 본다면

1. IPMI 는 IP 할당 완료 ID/PW 설정 완료
2. PXE 서버 설정 (DHCP,TFTP,HTTP,FTP)
3. 테라폼 세팅
4. Kickstart 파일 설정 (윈도우는 prep) ks.cfg

하이퍼바이저를 통하지 않고 IPMI 만 연결되어 있으면 테라폼이 타겟 서버에 PXE 세팅을 해서 PXE 부팅을 시키는 것
그 이후에는 기본적인 PXE 부팅 방법을 따름.

이것의 장점은 IPMI만 세팅이 되어 있으면 된다는 것.

코드는 아래에 기술하였습니다.

기존에 PXE 구축보다 타겟 서버의 PXE 설정이 자동화 되어 좀 더 간소화 되었습니다.

추후 실제 테스트를 해보고 다시 문제점을 공유 하도록 하겠습니다.

3번 테라폼 tf 세팅

provider "ipmi" {
  host     = "IPMI_HOST"
  username = "IPMI_USERNAME"
  password = "IPMI_PASSWORD"
}

resource "ipmi_power" "power_on" {
  host     = "IPMI_HOST"
  username = "IPMI_USERNAME"
  password = "IPMI_PASSWORD"
  action   = "on"
}

resource "ipmi_boot" "pxe_boot" {
  host     = "IPMI_HOST"
  username = "IPMI_USERNAME"
  password = "IPMI_PASSWORD"
  bootdev  = "pxe"
}

resource "null_resource" "install_os" {
  provisioner "remote-exec" {
    inline = [
      "curl -O http://example.com/rocky-linux.iso",
      "curl -O http://example.com/ks.cfg",
      "dd if=rocky-linux.iso of=/dev/sda",
      "reboot"
    ]
  }

  connection {
    type     = "ssh"
    host     = "IPMI_HOST"
    user     = "root"
    password = "ROOT_PASSWORD"
  }
}

4. 번 내용 kickstart 설정 (ks.cfg)

#version=RHEL9
install
lang en_US.UTF-8
keyboard us
timezone America/New_York --isUtc
rootpw --plaintext yourpassword
user --name=youruser --password=yourpassword
reboot

# Use text mode install
text

# System bootloader configuration
bootloader --location=mbr

# Partition clearing information
clearpart --all --initlabel

# Disk partitioning information
part / --fstype="xfs" --grow --size=1
part /boot --fstype="xfs" --size=1024
part swap --fstype="swap" --size=2048

%packages
@^minimal-environment
%end

테라폼에서 RDS 메세지 구독 설정 시 주의 사항

Firewall — Fri, 20 Sep 2024 19:07:07 +0900

RDS 구독 메세지를 테라폼을 적용해서 사용 중인데 리소스를 찾지 못했던 경험을 공유 합니다.

이번에는 source_ids 를 정할때 aws 의 ids 가 아닌 identifier 를 입력해야 합니다. 자꾸 ids 를 다시 확인하라고 해서, 문제 해결에 시간이 걸렸습니다.

문법이나 내용은 맞는 것 같은데 실제 리소스를 찾지 못할때는 아래처럼 환경 설정이 어떻게 되어 있나 확인하고 적절한 리소스를 대입해서 찾아보면 좋습니다.

terraform state show aws_db_instance.logdb01

정상적으로 rds 에 sns 구독을 연결 시키는 코드입니다.

resource "aws_sns_topic" "rds_events_topic" {
  name = "rds-events-topic"
}

resource "aws_sns_topic_subscription" "email_subscription" {
  topic_arn = aws_sns_topic.rds_events_topic.arn
  protocol  = "email"
  endpoint  = "email@email.co.kr" # Recieve E-mail 
  depends_on = [aws_sns_topic.rds_events_topic]  # SNS topic depend
}

resource "aws_db_event_subscription" "rds_event_subscription" {
  name            = "rds-event-subscription"
  sns_topic       = aws_sns_topic.rds_events_topic.arn
  source_type     = "db-instance"
  event_categories = ["availability", "configuration change", "failover", "failure", "maintenance", "notification", "recovery", "restoration"]
  source_ids      = [aws_db_instance.logdb01.identifier,
                     aws_db_instance.gamedb01.identifier
                    ]

  depends_on = [
    aws_db_instance.logdb01, #instance depend. Can be deleted.
    aws_db_instance.gamedb01,
    aws_sns_topic_subscription.email_subscription
  ]

  tags = {
    Name = "rds-event-subscription"
  }
}

Crash 난 POD 를 일괄 삭제

Firewall — Tue, 20 Aug 2024 19:29:11 +0900

쿠버네티스를 운영하다 보면 어떤 이유에서든지 크래시난 pod 가 여러개 있습니다.

가끔 일괄로 삭제하게 되는데 하나씩 하게 되면 너무 시간이 걸리기 때문에, 이럴때는 awk와 xarg 로 삭제하면 편합니다.

 ## 특정 에러만 삭제
 
 kubectl get pods | grep 'Init:CrashLoopBackOff' | awk '{print $1}' | xargs kubectl delete pod
 
 ## 정상 메세지 이외 삭제
 
 kubectl get pods  --no-headers --field-selector=status.phase!=Running,status.phase!=Succeeded | awk '{ print $1};' | xargs kubectl delete pod

placement 그룹에 가입된 instance 들의 type 변경 실패시 대응 방법

Firewall — Tue, 13 Aug 2024 20:21:15 +0900

AWS 인프라를 오래 사용하다 보니, 4세대 인스턴스들의 사양을 변경 할 경우가 발생하였습니다.

기존에 cluster 되어 있는 서비스들이었기 때문에 placement 그룹으로 묶어 놨던 서버들입니다.

사양 변경 내역을 확인하고 AWS-CLI 에서 일괄 배치를 돌렸는데 자원부족으로 타입 변경 에러가 발생하는 것을 확인하였습니다.

처음에는 감을 못잡고 좀 헤메다가 placement 그룹이 해제된다는 것을 발견! ( 제 기억으로는 예전에 해제가 되지 않았습니다.) 바로 해제하고 변경을 완료하였습니다. (아마존링크 참고)

클러스터 배치 그룹의 모든 인스턴스를 중지합니다.
영향을 받는 인스턴스의 인스턴스 유형을 변경합니다.
클러스터 배치 그룹의 모든 인스턴스를 시작합니다.

이렇게 가이드 되어 있는데, 그냥 하나씩 해도 되긴합니다.

그러나 실제로 자원이 부족한 경우도 발생합니다. (3세대) 가급적이면 최신 세대의 인스턴스로 옮기는 것이 좋습니다.

그리고 변경은 되는데 IPV4 주소가 릴리즈 될수도 있다고 하니, 이럴 경우에는 내부 IP로 접근해서 확인 및 해결을 해야될 경우도 있겠습니다.

해당 에러에 대한 메뉴얼은 위키에도 업데이트 하였는데.. 누군가는 보겠지요.

aws cli elb registration / deregistration

Firewall — Tue, 23 Jul 2024 17:11:44 +0900

프로젝트에 게임서버 롤링 업데이트가 필요하여 젠킨스 CI/CD를 이용하여 1대씩 패치를 진행하기로 하였습니다.

이를 위해 aws elbv2 로드밸런서의 타겟 그룹에서 한대씩 deregistration 이 필요합니다.

명령어는 아래와 같습니다.

기존에 있던 Deply code 에 target instance 들을 한대씩 번갈아 가며 세팅하게 하였으며, 그레이스풀하게 빠지는 시간에 맞춰 sleep 설정 하였습니다.

(aws config 는 미리 설정되어 있어야합니다.)

##REGISTRATION
aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:072498040640:targetgroup/project/0e7e34feggererew2 --targets Id=i-0123456789a

##DEREGISTRATION
aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:072498040640:targetgroup/project/0e7e34feggererew2 --targets Id=i-0123456789a

프로메테우스 모니터링 알림 라우트 설정

Firewall — Thu, 18 Jul 2024 10:46:24 +0900

일단 계속 업데이트 할 예정입니다. 완료해서 포스팅 하려니까 자꾸 안하게 되어서요.

alert.rule 업데이트 하고 amtool 로 문법체크 하여 줍니다.

더 해야될 것은 채널에 이름나올떄 alertmanager 가 아니라 각 채널의 이름이 나오는 것과, Annotations.description 을 못가지고 오는 것 같은데, 왜 그런지 확인 하는 부분이 남아있습니다. ( {{ $labels.name }} 으로 가져오면 됩니다.)

global:
  resolve_timeout: 5m
  slack_api_url: "https://hooks.slack.com/services/ap1"  # global Slack API URL

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 24h
  receiver: 'default-receiver'
  routes:
    - matchers:
        - job_name =~ "ap1"
      receiver: 'ap1'
    - matchers:
        - job_name =~ "ap2"
      receiver: 'ap2'
    - matchers:
        - job_name =~ "ap3"
      receiver: 'ap3'

receivers:
  - name: 'default-receiver'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/ap1"
        username: 'ap1'
        send_resolved: true
        channel: '#ap1'
        title: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}"
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
        icon_emoji: ':bell:'
  - name: 'ap2'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/ap2"
        username: 'ap2'
        send_resolved: true
        channel: '#ap2'
        title: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}"
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
        icon_emoji: ':dart:'
  - name: 'ap3'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/ap3"
        username: 'ap3'
        send_resolved: true
        channel: '#ap3'
        title: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}"
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
        icon_emoji: ':dart:'
  - name: 'ap4'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/ap4"
        channel: '#ap4'
        title: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}"
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
        icon_emoji: ':bell:'

templates:
  - /opt/prometheus/alertmanager/notifications.tmpl

AWS EC2 rocky9 에서 securecrt, xshell 로그인이 실패하고 다른 rocky linux 에서는 접속 가능한 현상

Firewall — Tue, 16 Apr 2024 17:13:00 +0900

사설 가상 서버에서는 rocky 이미지로 설치 후에 별다른 이상없이 SSH 접속이 가능하였으나,

최근 AWS EC2 에서 rocky 9 이미지 설치 후에 기본 private key 로 접속이 되지 않는 현상이 발생하였다.

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

여러 SSH 클라이언트(securecrt, xshell, putty) 로 테스트해본 결과 로키 리눅스에서 ssh 접속만 가능하고 나머지는 auth methods 가 모두 실패하는 현상이 발생하였다.

구글링을 해보니 최신 리눅스는 regacy encryption 을 지원하지 않는 것 같았다.

해결 방법으로는 클라이언트 메소드를 바꾸거나 reqacy 를 지원하게 하는 방법으로 해결하면 될 것으로 보여 ssh 서버에 아래의 명령어를 실행하였다.

PubkeyAcceptedAlgorithms +ssh-rsa
HostKeyAlgorithms +ssh-rsa

## ---아래는 쓰지말것-- 전체 레거시 허용
update-crypto-policies --set LEGACY

이 후 정상 접속이 되었다.

아래 링크 참고

https://access.redhat.com/documentation/ko-kr/red_hat_enterprise_linux/8/html/security_hardening/switching-the-system-wide-crypto-policy-to-mode-compatible-with-previous-systems_using-the-system-wide-cryptographic-policies

여러개의 docker compose 파일 사용 시 주의사항

Firewall — Thu, 4 Jan 2024 18:53:24 +0900

젠킨스 파이프라인에서 여러개의 docker-compose 설정을 하던 중, 컴포즈 한개가 실행되고 다음 컴포즈 실행을 하면 먼저실행된 도커가 죽는 문제가 발생하였습니다. (run 되지 않음)

docker network inspect 로 자세히 살펴보니 docker network 가 두번 째 컴포즈가 실행될때 삭제되고 새로세팅되는 것을 확인 하였습니다.

디렉토리안에 하나의 컴포즈가 있을 때에는 network 가 재 설치되도 문제가 없지만, 이미 기동하고 있는 컨테이너가 있는 상황이라면 기동중인 컨테이너가 exit 되는 상황이 생깁니다.

해결방법은 다른 디렉토리로 변경하거나, 사용 네트워크를 다르게 지정하는 방법이 있습니다.

디렉토리 변경은 확인을 했으나 각각의 네트워크를 다르게 지정하는 것은 테스트 하지 못하였습니다.