728x90
반응형

증상

SER8을 잘 쓰다 갑자기 스피커를 연결해도 소리도 안들리고, 모니터를 2대 이상 연결했을 때 연결도 안되는 증상이 있었다. 

 

해결

지피티한테 물어보고 이것저것 시도해보다가 아래 Beelink 사이트에서 그래픽 드라이버를 설치하고 해결되었다. 

링크 : Beelink

 

Beelink

 

dr.bee-link.cn

 

위 링크를 들어가면 아래와 같이 5개의 파일목록이 있는데, 나는 다 다운로드를 받아두었다. 그래픽 드라이버는 맨 아래 
SER8-8845-Driver_2024-05-16_7-12-50.zip 파일에 포함되어 있다. 

 

위 SER8-8845-Driver_2024-05-16_7-12-50.zip 파일 압축을 풀면 이렇게 나온다. 이 중에 VGA 폴더에 들어간다. 

 

아래 실행파일을 실행하면 모니터들이 제대로 인식된다. 

 

 

반응형
728x90
반응형

서버를 하나 더 추가한 뒤로 기존 서버가 접속이 안되는 현상이 발생했음 

원인을 몰라서 chatGPT, grok 등에 문의하며 삽질을 꽤 여러 번 했는데, 결론적으로 방화벽 잠깐 내리니까 접속됨 (Proxmox에서 방화벽 '예' 설정 부분) 

접속되는 거 보고 다시 방화벽 올림.

단지 이것만 했을 뿐인데 다시 접속이 되다니. 

 

 

반응형
728x90
반응형

1. Elasticsearch에서 logstash_internal 비밀번호 확인 및 재설정

Elasticsearch에서 logstash_internal 사용자의 비밀번호를 확인하거나 재설정합니다.

  • Elasticsearch 초기 비밀번호 확인: Elasticsearch가 처음 시작될 때 logstash_internal 사용자의 비밀번호가 자동 생성됩니다. Docker 로그에서 이를 확인하세요:
    docker logs elasticsearch
    로그에서 logstash_internal 사용자의 비밀번호를 찾아 Logstash 설정에 반영합니다.
  • 비밀번호 재설정: 비밀번호를 모르거나 잘못된 경우, 수동으로 재설정합니다:
    1. Elasticsearch 컨테이너에 접속:
      docker exec -it elasticsearch bash
    2. 비밀번호 재설정 명령 실행:
      bin/elasticsearch-reset-password -u logstash_internal
      이 명령은 새 비밀번호를 생성하거나 대화형 모드로 비밀번호를 설정합니다.
    3. 생성된 비밀번호를 복사하여 Logstash의 logstash.conf 또는 환경 변수에 반영합니다.

 

elasticsearch-reset-password | Elastic 문서

 

elasticsearch-reset-password | Elastic Documentation

The elasticsearch-reset-password command resets the passwords of users in the native realm and built-in users. Use this command to reset the password...

www.elastic.co

 

다음 예시에서는 username이 있는 기본 사용자의 암호를 자동 생성된 값으로 재설정하고 콘솔에 새 암호를 인쇄합니다. 지정된 URL은 elasticsearch-reset-password 도구가 로컬 Elasticsearch 노드에 연결하려고 시도하는 위치를 나타냅니다.

bin/elasticsearch-reset-password --url "http://elasticsearch:9200" --username logstash_internal -i
위 명령어를 수행하면 아래와 같이 나타납니다.

이후에 해당 docker compose를 restart 해줍니다. 
docker compose restart   

 

2. Elasticsearch 보안 설정 점검

Elasticsearch에서 X-Pack Security가 활성화되어 있는지 확인하고, 필요하면 일시적으로 비활성화하여 테스트합니다.

  • 보안 설정 확인: Elasticsearch의 설정 파일(예: elasticsearch.yml) 또는 docker-compose.yml에서 보안 설정을 확인하세요. 기본적으로 7.10.0 이상에서는 보안이 활성화되어 있습니다. docker-compose.yml에서 다음이 설정되어 있는지 확인:
    services: elasticsearch: environment: - xpack.security.enabled=true ...
  • 보안 비활성화 테스트 (임시): 인증 문제를 배제하기 위해 일시적으로 보안을 비활성화할 수 있습니다:
    services: elasticsearch: environment: - discovery.type=single-node - xpack.security.enabled=false ...
  • Docker Compose를 재시작:
    docker-compose down && docker-compose up
    오류가 사라지면 인증 문제가 원인입니다. 주의: 프로덕션 환경에서는 보안을 비활성화하지 마세요. 대신 올바른 자격 증명을 설정하세요.

이후에 logstash 에서 아래와 같은 오류가 또 발생 - 403에러 

비밀번호를 바꿔줬는데도 뭔가 에러가 계속 발생하고 있었는데, 이번엔 좀 다른 종류의 에러였습니다. (아래) 

[2025-04-17T04:07:20,233][WARN ][logstash.outputs.elasticsearch][main] Health check failed {:code=>403, :url=>http://elasticsearch:9200/, :message=>"Got response code '403' contacting Elasticsearch at URL 'http://elasticsearch:9200/'"} [2025-04-17T04:07:20,304][WARN ][logstash.outputs.elasticsearch][main] Elasticsearch main endpoint returns 403 {:message=>"Got response code '403' contacting Elasticsearch at URL 'http://elasticsearch:9200/'", :body=>"{\"error\":{\"root_cause\":[{\"type\":\"security_exception\",\"reason\":\"action [cluster:monitor/main] is unauthorized for user [logstash_internal] with effective roles [] (assigned roles [logstash_writer] were not found), this action is granted by the cluster privileges [monitor,manage,all]\"}],\"type\":\"security_exception\",\"reason\":\"action [cluster:monitor/main] is unauthorized for user [logstash_internal] with effective roles [] (assigned roles [logstash_writer] were not found), this action is granted by the cluster privileges [monitor,manage,all]\"},\"status\":403}"}

 

위 에러를 요약하자면 HTTP 403 Forbidden 응답 코드로 인해 Elasticsearch에 접근할 수 없는 문제라는 내용입니다. 구체적으로, logstash_internal 사용자가 cluster:monitor/main 액션을 수행할 권한이 없으며, 할당된 역할(logstash_writer)이 Elasticsearch에서 인식되지 않는다는 메시지가 나타납니다.

오류 원인

로그를 분석해보면 다음과 같은 주요 원인을 확인할 수 있습니다:

  1. 권한 부족 (HTTP 403 Forbidden)
    • logstash_internal 사용자가 Elasticsearch에서 필요한 작업(cluster:monitor/main)을 수행할 권한이 없습니다.
  2. 역할 설정 문제
    • logstash_writer 역할이 logstash_internal 사용자에게 할당되었지만, Elasticsearch에서 이 역할이 정의되지 않았거나 찾을 수 없습니다.
  3. 보안 설정 오류
    • Elasticsearch에서 X-Pack Security가 활성화된 상태에서 사용자와 역할이 올바르게 구성되지 않았을 가능성이 있습니다.

 

해결 방법

1. Elasticsearch에서 사용자와 역할 확인

먼저, logstash_internal 사용자와 logstash_writer 역할이 Elasticsearch에 제대로 설정되어 있는지 확인합니다.

  • Elasticsearch 컨테이너에 접속:
    docker exec -it elasticsearch bash
  • 사용자 역할 확인:
    bin/elasticsearch-users roles logstash_internal
    • 출력 결과에 logstash_writer 역할이 포함되어 있는지 확인하세요.
  • 역할 정의 확인:
    bin/elasticsearch-roles list logstash_writer
    • logstash_writer 역할이 존재하지 않거나, 필요한 권한(monitor, manage_index_templates, write 등)이 누락되었는지 확인합니다.

제 경우, bin/elasticsearch-roles list 에서 사용자가 아무것도 나타나지 않았습니다. 

 

그래서 kibana web console로 접속(http://kibana:5601/app/dev_tools#/console/shell) 한 뒤에
아래 3개의 POST 명령을 각각 실행해줬습니다. 

POST _security/role/logstash_writer
{
  "cluster": ["manage_index_templates", "monitor", "manage_ilm"],
  "indices": [
    {
      "names": [ "logstash-*" ],
      "privileges": ["write","create","create_index","manage","manage_ilm"]
    }
  ]
}
 
POST _security/user/logstash_internal
{
  "password" : "your-password",
  "roles" : [ "logstash_writer"],
  "full_name" : "Internal Logstash User"
}

POST _security/role/logstash_reader
{
  "cluster": ["manage_logstash_pipelines"],
  "indices": [
    {
      "names": [ "logstash-*" ],
      "privileges": ["read","view_index_metadata"]
    }
  ]
}

 

재생 표시 아이콘을 누르면 각 POST 마다 명령을 실행할 수 있습니다. 

이후 logstash_internal 에 role이 잘 부여되었는지 보기 위해 아래 GET 명령을 실행합니다.

GET _security/user/logstash_internal

그러면 아래 이미지와 같이 명령어 결과를 확인할 수 있습니다. 

 

logstash_reader의 role은 반영이 안되었지만 writer 역할이 없어 오류가 난 것이기 때문에 문제 해결은 되었습니다. 

 

참고 문서 :  Elasticsearch에 대한 연결 보안 | Elastic 문서

반응형
728x90
반응형

예를들어
대상 스토리지 IP가 192.168.1.10 이고
해당 경로가 ubuntu_share 폴더인데,
/mnt/nas라는 경로에 마운트 하고자 한다면,  

uidgid를 지정하여 마운트:

mount -t cifs //192.168.1.10/ubuntu_share /mnt/nas -o username=<smb_user>,password=<smb_pass>,uid=1000,gid=1000
  • <smb_user><smb_pass>는 SMB 공유에 접근하는 사용자 이름과 비밀번호로 대체한다.
    • 비밀번호에 특수문자가 들어갈 경우, 작은 따옴표 '' 로 감싸준다
  •  uid=1000,gid=1000 는 원하는 사용자의 값으로 바꾼다. 

 

결과확인:

ls -ld /mnt/nas 

 

/etc/fstab에 영구 적용

위 방법이 동작한다면, 부팅 시 자동으로 적용되도록 /etc/fstab을 수정:

  1. 파일 편집:
    nano /etc/fstab
  2. 아래 줄 추가:
    //192.168.1.10/share /mnt/nas cifs username=<smb_user>,password=<smb_pass>,uid=1000,gid=1000,rw 0 0
    • 보안을 위해 비밀번호를 평문으로 저장하지 않으려면, 자격 증명을 별도 파일에 저장:
      /etc/smb-credentials
      내용:
      username=<smb_user> password=<smb_pass>
      권한 설정:
      chmod 600 /etc/smb-credentials
      /etc/fstab 수정:
      //192.168.1.10/share /mnt/nas cifs credentials=/etc/smb-credentials,uid=1000,gid=1000,rw 0 0
  3. 마운트 테스트:
    mount -a

 

  • 마운트 옵션 확인:
    mount | grep /mnt/nas
    • uid=1000,gid=1000이 포함되어 있는지 확인
  • SMB 버전:
    • 오래된 SMB 버전(예: SMBv1)을 사용하는 경우 호환성 문제가 있을 수 있음. -o vers=3.0을 추가.
      mount -t cifs //192.168.1.10/share /mnt/nas -o username=<smb_user>,password=<smb_pass>,uid=1000,gid=1000,vers=3.0

 

최종확인:

ls -ld /mnt/nas 

 


아래와 같이 뜨면서 언마운트가 되는 경우 

root@server1:/mnt# umount -f /mnt/nas umount: /mnt/nas: target is busy.

 

umount -f /mnt/nas를 실행했는데 target is busy 오류가 발생한다는 것은 /mnt/nas 디렉토리가 현재 사용 중이어서 마운트를 해제할 수 없다는 뜻입니다. SMB 마운트를 강제로 해제하려면 사용 중인 프로세스를 종료하거나, 더 강력한 옵션을 사용해야 합니다. 아래에서 단계별로 해결 방법을 설명하겠습니다.


1. 왜 'target is busy'가 발생하는가?

  • /mnt/nas에 접근 중인 프로세스가 있거나, 열린 파일/디렉토리가 존재합니다.
  • 예: 셸에서 cd /mnt/nas로 이동한 상태이거나, 프로그램이 해당 경로의 파일을 사용 중일 수 있습니다.

2. 해결 방법

(1) 사용 중인 프로세스 확인

lsof 또는 fuser를 사용해 /mnt/nas를 사용 중인 프로세스를 찾아봅니다.

  • lsof 사용:
    lsof /mnt/nas
    • 출력 예시:
      COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME bash 1234 user1 cwd DIR 0,XX 4096 12 /mnt/nas
    • PID 열에 나오는 프로세스 번호(위 예시에서는 1234)를 확인하세요.
  • fuser 사용:
    fuser -m /mnt/nas
    • 출력 예시:
      /mnt/nas: 1234 5678
    • 사용 중인 프로세스 ID(PID)가 나옵니다.

(2) 프로세스 종료

확인된 PID를 종료합니다.

  • 특정 PID 종료:
    kill -9 1234
    • 예: 1234lsoffuser로 찾은 PID로 대체하세요.
  • fuser로 한 번에 종료:
    fuser -km /mnt/nas
    • -k: 프로세스를 강제로 종료.
    • -m: 마운트 포인트를 지정.

(3) 다시 언마운트 시도

프로세스를 종료한 후 다시 시도:

umount /mnt/nas
  • 여전히 실패하면 강제 옵션 추가:
    umount -f /mnt/nas

(4) 최후의 수단: Lazy 언마운트

위 방법으로도 안 되면, lazy unmount(-l)를 사용해 즉시 마운트를 해제할 수 있습니다:

umount -l /mnt/nas
  • -l: 사용 중인 프로세스가 끝날 때까지 기다리지 않고 마운트를 즉시 해제. 이후 시스템이 자동으로 정리합니다.
  • 이 방법은 마운트 포인트를 즉시 사용 가능한 상태로 만들지만, 백그라운드에서 정리 작업이 진행되므로 주의하세요.

3. 추가 팁

  • 현재 디렉토리 확인:
    • 셸에서 /mnt/nas에 들어가 있다면 빠져나오세요:
       
      cd /
    • 그런 다음 다시 umount를 시도하세요.
  • lsoffuser가 설치되어 있지 않다면:
    • 설치 명령어:
       
      apt install lsof # Debian/Ubuntu
      yum install lsof # CentOS/RHEL
       
      apt install psmisc # fuser 설치, Debian/Ubuntu
      yum install psmisc # CentOS/RHEL

4. 최종 확인

언마운트가 성공했는지 확인:

mount | grep /mnt/nas
  • 아무 출력이 없으면 마운트가 해제된 것입니다.

그 후, 원래 목표였던 SMB 마운트를 uidgid 옵션으로 다시 마운트하세요:

mount -t cifs //192.168.1.10/share /mnt/nas -o username=<smb_user>,password=<smb_pass>,uid=1000,gid=1000
반응형
728x90
반응형

노트북에 Proxmox를 설치하고 나서 뚜껑을 덮고 있을 때 sleep에 빠져버려 원격접속이 안되는 경우가 종종 있었다. 

알아보니 GRUB 파일을 수정하면 된다고 하는데, 이렇게 수정하고 재부팅하면 CPU Core 수가 모두 1이 되버리게 되서 다른 VM에 할당했던 CPU도 모두 1로 조정해야만 한다. 

  • GRUB 설정 파일 수정
    다음 명령어로 GRUB 설정 파일을 엽니다:
     
    nano /etc/default/grub
    • GRUB_CMDLINE_LINUX_DEFAULT 줄을 찾아 "quiet" 뒤에 acpi=off를 추가합니다.
      예: GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=off"

이 원인을 찾느라 한참을 찾았는데, 결론적으로는 Core수가 계속 1로 보이고 아래처럼 MAX 1 vcpus 오류가 뜨면  GRUB_CMDLINE_LINUX_DEFAULT 줄을 찾아 "quiet" 뒤에 acpi=off를 내용을 삭제해줘야 한다.

 
TASK ERROR: MAX 1 vcpus allowed per VM on this node

 

  • GRUB 업데이트:
    Grub 업데이트 후에 아래 명령어로 적용시켜준다. 
    update-grub
  • 재부팅:
    reboot

 

<참고>
acpi=off: ACPI(Advanced Configuration and Power Interface)는 하드웨어 구성과 전원 관리 정보를 운영 체제에 제공하는 표준이다

 

재부팅 후에 lscpu 명령어로 Core수가 잘 인식되는지 확인한다. 

 

반응형
728x90
반응형

집에 오랫동안 안쓰고 방치해둔 lenovo e535 노트북이 있어서 여기에 proxmox를 설치했다. 

synology NAS에 컨테이너를 여러개 띄워서 사용하고 있었는데, 컨테이너 수가 50개가 넘어가면서 슬슬 걱정이되기 시작된 참이었는데, proxmox 라는 가상화 OS와 synology NAS와 병행 운영하는 사례들을 접하면서 나도 해볼 수 있을 거 같다는 생각이 들었다. e535 정도의 사양이라면 CPU나 메모리 측면에서 NAS보단 더 빡세게 굴릴 수 있겠다 싶었다. 

노트북이라서 잘 설치될지 염려가 되었지만. 생각보다 어렵지 않았고, 아래 링크를 참조했다.

오픈소스 가상화 OS Proxmox VE 설치하기.

 

오픈소스 가상화 OS Proxmox VE 설치하기.

안녕하세요. 달소입니다. 앞서 소개해드린 오픈소스 가상화 OS인 Proxmox VE를 직접 설치해보도록 하겠습니다. 오픈소스 가상화 OS Proxmox VE란 무엇인가[서버 구축(Self-Hosted)] 달소 2023.07.24 안녕하세

svrforum.com

 

설치 후에 tailscale 을 설치해서 외부에서도 원격접속할 수 있도록 설정했고, 
여기에 synology NAS는 smb로 mount 시켰다. 

 

Synology NAS를 Proxmox에 연결하는 방법

NFS 로 마운트도 가능하겠지만, 내 경우에는 그게 잘 안되는 듯 하여 SMB로 마운트했다. 

1. Synology NAS 에서의 사전 설정

1. 공유폴더 생성 : Proxmox에 연동할 공유폴더를 만든다. '제어판 > 공유 폴더' 에서 새 폴더로 만들 수 있다. 
2. 새 계정 생성 : 제어판에서 Proxmox에 연동용 계정 하나를 생성한다. 그 후에 새로 만든 계정에 Administrator 그룹권한을 부여해야  한다. 그래야 SMB로 접속이 가능하다. 

2. Proxmox에서 NAS 스토리지 추가

  • 웹 UI 접속: Proxmox 웹 인터페이스(기본적으로 https://[Proxmox IP]:8006)에 로그인한다.
  • 스토리지 추가: Datacenter > Storage > 추가(Add) > SMB를 선택.

  • 설정 입력:
    • ID: 원하는 이름(예: "SynologyNAS") 입력.
    • 서버: Synology NAS의 IP 주소(예: 192.168.1.100).
    • 사용자명: 아까 만들어둔 계정 ID를 입력한다.
    • 비밀번호: 아까 만들어둔 계정의 비밀번호를 입력한다.
    • Share: Synology에서 설정한 공유 폴더 경로(예: /volume1/ProxmoxStorage) 입력한다. 사용자명과 비밀번호를 입력해두면, Synology의 경로들이 목록에 불러와진다. 
    • 내용: 저장할 내용 선택(예: 디스크 이미지, ISO 이미지, 백업 등), 모조리 선택해도 무방하다. 
  • 확인: 설정을 저장하면 Proxmox에서 NAS가 스토리지로 인식된다.

3. VM 설정

  • VM 생성 시 디스크 저장 위치를 "SynologyNAS"로 선택하면, VM의 디스크 이미지가 NAS에 저장된다.
  • 로컬의 SSD는 Proxmox OS와 최소한의 시스템 파일만 유지하고, NAS를 주 스토리지로 활용할 예정이다. 
  •  

(접은 글) Synology NAS를 NFS로 Proxmox에 연결하는 방법 

더보기

Synology NAS를 Proxmox에 스토리지로 추가하려면 NFS를 사용하는 것이 가장 간단하고 널리 추천되는 방법입니다. 아래는 대략적인 설정 과정입니다.

1. Synology NAS 설정

  • NFS 활성화: Synology DSM에서 제어판 > 파일 서비스 > NFS로 이동해 "NFS 사용"을 체크하고 적용합니다. NFSv4를 지원하니 기본 설정으로 진행해도 됩니다.
  • 공유 폴더 생성: 제어판 > 공유 폴더에서 새 폴더(예: "ProxmoxStorage")를 만듭니다.
  • NFS 권한 설정: 공유 폴더 편집 > NFS 권한 탭에서 Proxmox 서버의 IP(예: 192.168.1.x)를 추가하고 읽기/쓰기 권한을 부여합니다. 경로는 /volume1/ProxmoxStorage와 같은 형태가 됩니다.

2. Proxmox에서 NAS 스토리지 추가

  • 웹 UI 접속: Proxmox 웹 인터페이스(기본적으로 https://[ThinkPad IP]:8006)에 로그인합니다.
  • 스토리지 추가: Datacenter > Storage > 추가(Add) > NFS를 선택합니다.
  • 설정 입력:
    • ID: 원하는 이름(예: "SynologyNAS") 입력.
    • 서버: Synology NAS의 IP 주소(예: 192.168.1.100).
    • 내보내기 경로(Export): Synology에서 설정한 공유 폴더 경로(예: /volume1/ProxmoxStorage).
    • 컨텐츠: 저장할 내용 선택(예: 디스크 이미지, ISO 이미지, 백업 등).
    • 확인: 설정을 저장하면 Proxmox에서 NAS가 스토리지로 인식됩니다.

 

이제 ubuntu 나 windows 등을 설치해보도록 하겠다.

반응형
728x90
반응형

QEMU 에이전트란?

QEMU 에이전트(qemu-guest-agent)는 VM 내부에 설치되는 소프트웨어로, Proxmox 호스트와 VM 간의 통신을 가능하게 합니다. 이를 통해 다음과 같은 기능을 사용할 수 있습니다:

  • IP 주소 보고: VM의 IP 주소를 Proxmox 웹 UI에서 바로 확인할 수 있습니다.
  • VM 상태 모니터링: VM의 상태(예: 메모리 사용량, 디스크 I/O 등)를 더 정확히 파악할 수 있습니다.
  • 안전한 종료 및 재부팅: Proxmox에서 VM을 종료하거나 재부팅할 때 운영 체제에 정상 종료 신호를 보내 안전하게 작업을 수행합니다.
  • 파일 전송: VM과 호스트 간에 파일을 쉽게 주고받을 수 있습니다.
  • 백업 개선: 백업 시 파일 시스템을 동기화하여 데이터 일관성을 높입니다.

QEMU 에이전트를 설치해야 할까?

QEMU 에이전트는 VM 관리에 편리함을 더해주지만, 설치하지 않아도 VM은 정상적으로 작동합니다. 설치 여부를 결정하려면 장단점을 고려해야 합니다.

설치하는 경우의 장점

  • 관리 편의성 향상:
    Proxmox 웹 UI에서 VM의 IP 주소를 바로 확인하거나, VM을 안전하게 종료/재부팅할 수 있어 관리가 편해집니다.
  • 모니터링 및 자동화:
    VM 상태를 세밀히 모니터링하거나 백업 시 데이터 손실 위험을 줄일 수 있어, 자동화된 환경에 적합합니다.
  • 파일 전송 기능:
    설정 파일이나 스크립트를 VM에 쉽게 전달할 수 있습니다.

설치하지 않는 경우의 장점

  • 보안:
    VM 내부에 추가 소프트웨어를 설치하지 않으면 잠재적인 보안 취약점을 줄일 수 있습니다.
  • 리소스 절약:
    QEMU 에이전트는 가볍지만, 리소스가 극도로 제한된 VM에서는 부담이 될 수 있습니다.
  • 단순성:
    단순 테스트나 개발 용도라면 에이전트 없이도 충분합니다.

언제 설치하는 것이 좋을까?

다음과 같은 상황에서는 QEMU 에이전트를 설치하는 것을 추천합니다:

  • VM을 자주 관리하거나 모니터링해야 할 때 (예: IP 주소 확인, 상태 체크).
  • VM을 안전하게 종료/재부팅하고 싶을 때.
  • 백업의 안정성을 높이고 싶을 때.
  • Proxmox와 VM 간 파일 전송이 필요할 때.

반대로, 이런 경우에는 설치하지 않아도 괜찮습니다:

  • VM이 일회성 테스트나 개발 용도일 때.
  • 보안이 매우 중요한 환경에서 추가 소프트웨어 설치를 피하고 싶을 때.
  • VM의 리소스가 매우 제한적일 때.

Ubuntu VM에 QEMU 에이전트 설치 방법

설치를 결정하셨다면, 아래 단계를 따라 진행할 수 있습니다:

  1. VM 생성 시 설정:
    Proxmox 웹 UI에서 VM을 생성할 때 "OS" 탭에서 "QEMU Guest Agent"를 체크하세요. 이는 Proxmox가 에이전트와 통신할 준비를 하는 설정입니다.
  2. Ubuntu VM 내부에서 설치:
    VM을 시작하고 로그인한 뒤, 다음 명령어를 실행합니다:
    sudo apt update sudo apt install qemu-guest-agent
  3. 설치 후 에이전트를 활성화합니다:
    sudo systemctl start qemu-guest-agent sudo systemctl enable qemu-guest-agent
  4. Proxmox에서 확인:
    VM의 "Summary" 탭에서 "QEMU Agent"가 "Running"으로 표시되면 설치가 완료된 것입니다. IP 주소가 보이고, 안전한 종료/재부팅이 가능해집니다.

결론

QEMU 에이전트를 설치하면 VM 관리의 편의성이 크게 향상되지만, 필수는 아닙니다. IP 주소를 쉽게 확인하거나 VM을 안전하게 제어하고 싶다면 설치하는 것이 좋습니다. 하지만 보안이나 리소스 절약이 더 중요하다면 설치하지 않아도 VM은 문제없이 작동합니다. 사용 목적과 필요에 따라 결정하세요. 

 

반응형
728x90
반응형

Proxmox에 Tailscale을 설치하고 활성화하는 방법을 단계별로 설명하겠습니다. Tailscale은 장치 간 안전한 연결을 제공하는 메쉬 VPN으로, Proxmox를 원격으로 접속할 때 방화벽 포트를 열지 않고도 보안적으로 접근할 수 있게 해줍니다. 아래 단계를 따라 진행하면 됩니다.


1. Proxmox 시스템 업데이트

먼저 Proxmox가 최신 상태인지 확인해야 합니다. 터미널에서 다음 명령어를 실행하세요:

 
apt update && apt upgrade -y

이 명령어는 패키지 목록을 업데이트하고 시스템을 업그레이드합니다.


2. Tailscale 설치

Proxmox는 Debian 기반이므로, Tailscale을 Debian에 설치하는 방식과 동일하게 진행할 수 있습니다.

(1) Tailscale 패키지 서명 키 및 저장소 추가

다음 명령어를 차례로 입력하세요:

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | tee /etc/apt/sources.list.d/tailscale.list
  • 첫 번째 명령어는 Tailscale의 GPG 키를 추가합니다.
  • 두 번째 명령어는 Tailscale 저장소를 APT 소스 리스트에 추가합니다.

(2) 패키지 목록 업데이트 및 Tailscale 설치

저장소를 추가한 후, 패키지 목록을 업데이트하고 Tailscale을 설치합니다:

 
apt update apt install tailscale -y

3. Tailscale 활성화

Tailscale을 설치했다면 이제 서비스를 시작하고 네트워크에 연결해야 합니다.

(1) Tailscale 서비스 시작

다음 명령어로 Tailscale 데몬을 활성화하고 실행합니다:

 
systemctl enable --now tailscaled

(2) Tailscale 네트워크에 연결

Tailscale을 활성화하고 계정에 인증합니다:

 
tailscale up
  • 이 명령어를 실행하면 터미널에 URL이 표시됩니다.
  • 해당 URL을 웹 브라우저에서 열고 Tailscale 계정으로 로그인하여 이 장치를 승인하세요.

4. 연결 상태 확인

Tailscale이 제대로 작동하는지 확인하려면 다음 명령어를 실행하세요:

 
tailscale status
  • Proxmox 호스트가 Tailscale 네트워크에 연결된 상태로 표시되어야 합니다.

5. 추가 설정 (선택 사항) - Proxmox 웹 UI 원격 접속

Tailscale이 활성화되면 Proxmox의 Tailscale IP 주소를 사용하여 어디서나 웹 인터페이스에 안전하게 접속할 수 있습니다. 예를 들어, 브라우저에서 https://[Tailscale_IP]:8006을 입력하면 됩니다.


요약

위 단계를 완료하면 Proxmox에 Tailscale이 설치되고 활성화되어, 복잡한 방화벽 설정 없이도 안전한 원격 접속이 가능해집니다. 문제가 발생하면 tailscale status로 연결 상태를 확인하거나, Tailscale 계정에서 장치 인증 여부를 점검하세요.

반응형

+ Recent posts