Honey buns

• 쑥갓 (Garland Chrysanthemum)
  • 적정 온도: 15~25°C
  • 쑥갓은 서늘한 기후를 좋아하며, 너무 더운 환경(30°C 이상)에서는 잘 자라지 않을 수 있습니다.
• 로켓루꼴라 (Rocket Arugula)
  • 적정 온도: 15~20°C
  • 루꼴라는 시원한 날씨를 선호하며, 온도가 25°C를 넘으면 쓴맛이 강해지거나 생장이 느려질 수 있습니다.
• 상추 (Lettuce)
  • 적정 온도: 15~20°C
  • 상추는 온화하고 서늘한 환경에서 잘 자라며, 25°C 이상에서는 잎이 질겨지거나 꽃대가 올라올 수 있습니다.
• 적환무 (Red Radish)
  • 적정 온도: 15~25°C
  • 적환무는 비교적 온도 범위가 넓지만, 너무 더우면 뿌리가 단단해지지 않고 맛이 떨어질 수 있습니다.
• 당근 (Carrot)
  • 적정 온도: 16~21°C
  • 당근은 서늘한 기후에서 단맛이 강해지고 잘 자라며, 25°C 이상에서는 뿌리 발달이 저해될 수 있습니다.

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 또는 환경 변수에 반영합니다.

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
  오류가 사라지면 인증 문제가 원인입니다. 주의: 프로덕션 환경에서는 보안을 비활성화하지 마세요. 대신 올바른 자격 증명을 설정하세요.

오류 원인

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

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 명령을 각각 실행해줬습니다. 

• <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

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
  • 예: 1234는 lsof나 fuser로 찾은 PID로 대체하세요.
• fuser로 한 번에 종료:
  fuser -km /mnt/nas
  • -k: 프로세스를 강제로 종료.
  • -m: 마운트 포인트를 지정.

(3) 다시 언마운트 시도

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

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

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

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

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

3. 추가 팁

• 현재 디렉토리 확인:
  • 셸에서 /mnt/nas에 들어가 있다면 빠져나오세요:
     

    cd /
  • 그런 다음 다시 umount를 시도하세요.
• lsof나 fuser가 설치되어 있지 않다면:
  • 설치 명령어:
     

    apt install lsof # Debian/Ubuntu
    yum install lsof # CentOS/RHEL
     

    apt install psmisc # fuser 설치, Debian/Ubuntu
    yum install psmisc # CentOS/RHEL

4. 최종 확인

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

• 아무 출력이 없으면 마운트가 해제된 것입니다.

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

• GRUB 업데이트:
  Grub 업데이트 후에 아래 명령어로 적용시켜준다. 

  update-grub
• 재부팅:
  reboot