지식은 날리지

Jenkins를 사용하면서 Execute Shell 단계에서 다음과 같은 오류를 만난 적이 있습니다.

FATAL: Unable to produce a script file
java.nio.charset.UnmappableCharacterException: Input length = 1
	at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:307)
	...
Caused: java.io.IOException: Failed to create a temp file on /var/lib/jenkins/workspace/...

이 오류는 임시 파일을 생성하는 과정에서 발생했으며, 이를 해결하기 위해 몇 가지 단계를 거쳤습니다. 이 글에서는 문제 원인과 해결 방법을 공유합니다.

1. 문제 원인

이 오류는 Jenkins가 쉘 스크립트를 실행하기 위해 임시 파일을 생성하려고 할 때 발생합니다. 주요 원인은 다음과 같습니다:

• Jenkins가 사용하는 임시 디렉터리의 권한 문제.
• Java 인코딩 설정이 맞지 않음.
• Jenkins 작업 디렉터리에서 임시 파일 생성 실패.

2. 해결 방법: 임시 디렉터리 변경

Jenkins가 사용하는 임시 디렉터리를 명시적으로 설정하고, 적절한 권한을 부여하면 문제를 해결할 수 있습니다.

1단계: Jenkins 설정 파일 수정

Amazon Linux 2에서는 Jenkins 설정 파일이 /usr/lib/systemd/system/jenkins.service에 위치합니다.

설정 파일을 열어 수정합니다

sudo vi /usr/lib/systemd/system/jenkins.service

Environment 블록에 다음 내용을 추가합니다

Environment="JAVA_OPTS=-Djava.awt.headless=true -Djava.io.tmpdir=/tmp/jenkins_tmp -Dfile.encoding=UTF-8"

2단계: 임시 디렉터리 생성 및 권한 설정

새로 정의한 임시 디렉터리(/tmp/jenkins_tmp)를 생성하고, Jenkins 사용자에게 적절한 권한을 부여합니다.

디렉터리 생성 및 Jenkins 권한 부여

sudo mkdir -p /tmp/jenkins_tmp
sudo chown -R jenkins:jenkins /tmp/jenkins_tmp

3단계: Jenkins 재시작

Jenkins 설정을 적용하려면 서비스를 재시작해야 합니다.

sudo systemctl daemon-reload
sudo systemctl restart jenkins
sudo systemctl status jenkins

 Jenkins를 사용하는 도중 Jenkins 재시작 후 플러그인이 정상 동작하지 않고, 플러그인 버전이 낮아 재설치조차 불가능한 문제를 겪었습니다.

 해당 문제로 Jenkins 버전 업그레이드하면서 겪었던 JSONObject["scm"] is not a JSONObject 오류와 이를 해결한 과정을 공유합니다. 이 문제를 해결하기 위해 진행했던 과정과 원인을 분석한 결과를 바탕으로, 비슷한 문제를 겪는 분들께 도움이 되었으면 합니다.

문제 상황

Jenkins 재시작 후 플러그인 비정상 작동
Jenkins를 재시작한 뒤 일부 플러그인(Git 관련 등)이 제대로 작동하지 않았습니다. 특히 Git 플러그인을 사용하는 빌드 작업에서 아래와 같은 오류가 발생했습니다

JSONObject["scm"] is not a JSONObject

플러그인 버전 낮음 및 재설치 불가
플러그인 관리 메뉴에서 확인해보니 몇몇 플러그인의 버전이 매우 낮은 상태였고, 이를 재설치하려고 해도 플러그인 업데이트 서버와의 통신 오류로 인해 재설치가 진행되지 않았습니다.

java.io.FileNotFoundException: https://updates.jenkins.io/download/plugins/plain-credentials/...

Jenkins 업그레이드 후 오류 지속
Jenkins 자체의 문제가 의심되어 최신 LTS 버전(2.4 LTS)으로 업그레이드했지만, 문제가 지속되었습니다.

문제 해결 과정

업그레이드 후 플러그인 재설치

Jenkins를 업그레이드한 뒤에도 문제가 발생했으므로, 우선 플러그인 재설치를 시도했습니다.
하지만 플러그인 관리 메뉴에서 일부 플러그인은 여전히 재설치가 불가능하거나, 최신 버전임에도 불구하고 오류가 계속되었습니다.

Git(SCM) 플러그인 오류 분석

Git 플러그인을 사용하는 빌드에서 JSONObject["scm"] is not a JSONObject 오류가 지속적으로 발생했습니다.
이를 통해 Git 플러그인(SCM 관련) 또는 빌드 환경의 JSON 데이터 파싱에 문제가 있다고 판단했습니다.

• 로그 분석 결과, Git 플러그인이 JSON 데이터를 읽는 과정에서 문제가 발생하고 있음을 확인했습니다.
• 하지만 Git 플러그인을 재설치해도 문제가 해결되지 않았습니다.

Build Timeout 플러그인 문제 발견

문제를 해결하기 위해 구글링 중, Build Timeout 플러그인의 오류임을 발견했습니다:

• 플러그인 관리 메뉴에서 해당 플러그인이 활성화되지 않은 상태로 표시.

Build Timeout 플러그인 재설치 후 문제 해결

• Build Timeout 플러그인을 삭제한 뒤 다시 설치하고 Jenkins를 재시작했습니다.
• 이후, Git 플러그인의 JSONObject["scm"] 오류가 사라지고 빌드가 정상적으로 진행되었습니다.

원인 분석

문제가 해결된 후, 왜 Build Timeout 플러그인 재설치가 Git(SCM) 관련 오류를 해결했는지 분석해본 결과, 다음과 같은 원인을 추정할 수 있었습니다:

1. 플러그인 간 의존성
   Jenkins 플러그인들은 서로 의존 관계를 가질 수 있습니다.
   Build Timeout 플러그인은 빌드 작업 시간 제한을 설정하며, Git 플러그인이나 SCM 관련 기능과 연계될 가능성이 있습니다.
   • Build Timeout 플러그인의 손상 또는 삭제로 인해 Git 플러그인이 사용하는 API나 공통 라이브러리가 비정상적으로 작동한 것으로 보입니다.
2. 플러그인 버전 불일치
   Jenkins 업그레이드 후, 기존 플러그인 버전이 Jenkins의 새로운 API와 호환되지 않아 문제가 발생했을 가능성이 큽니다.
   • Build Timeout 플러그인을 재설치하면서 최신 버전으로 교체되었고, Git 플러그인과의 의존성 문제도 해결되었습니다.

이번 경험을 통해 Jenkins 관리의 복잡성을 다시 한번 실감했습니다. 비슷한 문제를 겪는 분들에게 이 글이 작은 도움이 되길 바랍니다! 

해결 방법

아래의 단계별 가이드를 따라 문제를 해결해 보세요.

1. Docker Desktop 실행 확인

먼저 Docker Desktop이 실행 중인지 확인하세요.

1. Windows 작업 표시줄에서 Docker Desktop 아이콘을 찾습니다.
2. 실행되지 않았다면 Docker Desktop을 시작하세요.
3. 실행 중에도 에러가 발생한다면 Docker Desktop을 재시작합니다.

에러 원인 분석

Docker가 Windows에서 작동할 때 네임드 파이프(named pipe)를 통해 Docker Daemon과 통신합니다. 그러나 다음과 같은 상황에서 이 통신이 실패할 수 있습니다:

• Docker Desktop이 비정상적으로 종료되었거나 실행되지 않음.
• Docker 서비스(com.docker.service)가 중지됨.
• Docker CLI가 Docker Desktop 데몬과 연결되지 않음.
• Windows Subsystem for Linux 2(WSL2)와의 통합이 문제를 일으킴.
• Docker Desktop 설치 파일이 손상됨.

AWS EC2를 사용하다 보면 인스턴스의 성능을 최적화하거나 비용을 절감하기 위해 인스턴스 유형을 변경하는 경우가 많습니다. 하지만 이번 경험은 제게 인스턴스 유형 변경 시 CPU 아키텍처가 바뀌면 심각한 문제가 발생할 수 있다는 점을 상기시켜 주었습니다.

문제 상황

기존 EC2 인스턴스는 r5a.large (AMD 기반) 유형을 사용 중이었습니다. 성능 개선을 위해 r6i.large (Intel 기반)으로 인스턴스 유형을 변경했습니다. 변경 후 인스턴스를 시작했는데, 예상치 못한 문제가 발생했습니다:

1. SSH 접근 불가: 인스턴스가 시작되었지만 SSH로 접속이 불가능했습니다.
2. Emergency Mode: AWS 직렬 콘솔(Serial Console)을 통해 접속했을 때 인스턴스가 Emergency Mode로 부팅되어 있었습니다.

시도했던 해결 방법

문제를 해결하기 위해 여러 방법을 시도했지만, 결국 실패하고 다른 접근 방식을 선택해야 했습니다.

1. Emergency Mode에서 로그 확인

journalctl -xb

부팅 중 네트워크 관련 오류 및 sshd 서비스가 제대로 실행되지 않았다는 점을 확인했습니다.

2. 네트워크 및 SSH 복구

Emergency Mode에서 네트워크와 SSH를 복구하려고 시도했습니다:

ip link set eth0 up dhclient eth0 systemctl start sshd

그러나 네트워크와 SSH 서비스가 완전히 복구되지 않았습니다.

3. 파일 시스템 및 부트로더 복구

다음 명령을 통해 부트로더와 커널을 복구하려고 했습니다:

sudo yum reinstall kernel sudo dracut -f sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo grub2-install /dev/xvda

하지만 여전히 문제가 해결되지 않았습니다.

4. 볼륨 교체 및 AMI 복구

• 볼륨 교체: 문제의 루트 볼륨을 스냅샷으로 생성한 뒤, 새로 생성한 인스턴스에 연결하여 복구를 시도.
• AMI 복구: 기존 볼륨을 기반으로 새로운 AMI를 생성하고 다른 인스턴스에서 실행.

여러 시도에도 불구하고 인스턴스는 Emergency Mode를 벗어나지 못했습니다.

최종 해결 방법

모든 복구 시도가 실패하자, 다음과 같은 방법으로 문제를 해결했습니다:

1. 애플리케이션 복제:
   • 문제의 애플리케이션과 데이터를 로컬 환경으로 복제.
2. 새로운 서버 생성:
   • 새로운 EC2 인스턴스를 생성하고 애플리케이션을 재배포.
3. 서비스 재개:
   • 새 인스턴스에서 정상적으로 서비스를 운영할 수 있었습니다.

결론 및 교훈

이번 경험을 통해 두 가지 중요한 교훈을 얻었습니다:

1. CPU 아키텍처 변경 시 주의

• AMD에서 Intel로, 또는 ARM(r6g)에서 Intel(r6i)로 CPU 아키텍처가 변경될 때 부트가 실패할 가능성이 높습니다.
• 특히 부트로더나 커널이 해당 아키텍처를 지원하지 않는 경우 문제가 발생합니다.

2. AMI를 미리 생성하자

• 인스턴스 유형 변경 전에는 반드시 AMI를 생성해두는 것이 중요합니다.
• AMI는 문제 발생 시 빠르게 복구할 수 있는 가장 안전한 방법입니다.

최근 Windows 환경에서 Docker를 사용해 Python Django 앱을 실행하던 중 예상치 못한 문제가 발생했습니다. uWSGI를 통해 서버를 구동하려고 했으나, 아래와 같은 에러 메시지가 출력되었습니다

Thu Nov 21 16:29:43 2024 - *** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (18956672/16384) ***

문제 상황

Docker Desktop for Windows와 WSL 2를 사용 중이었으며, Ubuntu 배포판을 기본 WSL 환경으로 설정해 Docker 컨테이너를 실행하고 있었습니다. 하지만 위와 같은 에러가 지속적으로 발생하며 컨테이너가 제대로 작동하지 않았습니다.

해결 과정

이 문제를 해결하기 위해 다음 단계를 진행했습니다:

1. • WSL 설정 확인 및 수정
     • Docker Desktop 설정에서 Resources > WSL integration 항목을 확인했습니다.
     • 아래 이미지처럼 기본 WSL 통합 설정이 활성화되어 있었고, 추가로 Ubuntu 배포판도 통합 대상으로 설정되어 있었습니다.

• Refetch Distros
  • "Refetch distros" 버튼을 클릭해 WSL 통합 배포판 정보를 다시 가져왔습니다.
• Docker 재시작
  • Docker Desktop을 완전히 종료하고 다시 실행했습니다.
• 컨테이너 및 이미지 초기화
  • 문제를 일으킨 컨테이너를 중지하고 삭제했습니다.
  • 관련 이미지를 모두 삭제한 후, docker-compose를 사용해 빌드를 새로 진행했습니다.

결과

위 단계를 수행한 후 uWSGI 관련 에러가 더 이상 발생하지 않았습니다. Django 앱은 정상적으로 실행되었고, Docker와 WSL 통합 설정의 문제가 원인이었음을 확인할 수 있었습니다.

결론

Windows에서 Docker와 WSL 2를 활용할 때, 설정 불일치로 인해 다양한 문제가 발생할 수 있습니다. 특히 WSL 통합 설정과 관련하여 문제가 발생했을 경우:

• WSL 통합 설정을 확인 및 업데이트
• Docker Desktop 재시작
• 컨테이너와 이미지를 초기화하고 새로 빌드

드물게 사용자에게 SSMS 설치 문제가 발생하는 경우가 있으며 일반적인 오류 메시지는 다음과 같습니다.

• "MSI 패키지를 설치할 수 없음"
• “Microsoft ODBC Driver 17 for SQL Server: 이전 설치에서는 변경 사항을 적용하려면 컴퓨터를 재부팅해야 했습니다.”
• “설치 중에 오류 발생(0x80070643)”

앞서 언급한 또는 유사한 오류 메시지 중 하나가 표시되면서 설치가 실패하는 경우 일반적으로 SSMS 설치를 시작하기 전에 다음 단계에 따라 "Microsoft ODBC driver 17 for SQL Server"를 제거하면 설치가 성공할 수 있습니다.

1. SSMS, Visual Studio 또는 SQL Server Profiler를 비롯한 모든 관련 애플리케이션을 닫습니다.
2. 제어판 > 프로그램 추가/제거로 이동합니다.
3. "Microsoft ODBC Driver 17 for SQL Server" 항목을 찾아 제거합니다. 이 단계에서 다시 시작해야 할 수 있습니다.
4. SSMS 설치를 시작합니다. 최신 버전은 여기에서 사용할 수 있습니다.

방법이 안된다면

레지스트리 에디터 (실행 win + R -> regedit)

컴퓨터\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

위 경로로 이동

PendingFileRenameOperations 삭제 후 재설치

소개

FTP 서버는 액티브 모드와 패시브 모드를 지원합니다. 패시브 모드는 클라이언트가 서버에 연결할 때 방화벽 및 NAT(Network Address Translation) 환경에서의 문제를 줄이기 위해 사용됩니다. 이 블로그 포스트에서는 패시브 모드를 설정하고, 일반적인 문제를 해결하는 방법을 안내합니다.

패시브 모드란?

패시브 모드는 클라이언트가 서버에 연결할 때, 서버가 클라이언트에게 데이터 전송을 위한 포트 정보를 제공하는 방식입니다. 액티브 모드와 달리, 패시브 모드에서는 클라이언트가 데이터 연결을 설정하므로 방화벽과 NAT 환경에서의 문제를 줄일 수 있습니다.

패시브 모드 설정 방법

1. vsftpd.conf 파일 설정

패시브 모드를 활성화하려면 /etc/vsftpd/vsftpd.conf 파일에서 적절한 설정을 추가해야 합니다.

1. 패시브 모드 활성화
2. 패시브 모드를 활성화하려면 다음 설정을 추가합니다:

pasv_enable=YES

포트 범위 지정

패시브 모드에서는 서버가 클라이언트에 사용할 포트 범위를 알려줘야 합니다. 다음 설정을 통해 포트 범위를 지정합니다:

pasv_min_port=12000
pasv_max_port=12100

EC2 인스턴스에서 포트 방화벽 설정

AWS EC2에서는 보안 그룹(Security Groups)과 네트워크 ACLs(Network Access Control Lists)를 사용하여 인스턴스의 네트워크 트래픽을 제어합니다. 패시브 모드 포트를 열어주려면 다음 단계를 따르세요.

1. 보안 그룹 설정

1. AWS Management Console에 로그인합니다.
2. EC2 대시보드에서 '보안 그룹'을 선택합니다.
3. 해당 보안 그룹을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
   • 프로토콜: TCP
   • 포트 범위: 21, 12000-12100
   • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

2. 네트워크 ACLs 설정

1. AWS Management Console에 로그인합니다.
2. VPC 대시보드에서 '네트워크 ACLs'를 선택합니다.
3. 해당 네트워크 ACL을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
   • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
   • 프로토콜: TCP
   • 포트 범위: 21, 12000-12100
   • 허용: 허용
5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

계정의 홈 디렉토리가 디폴트와 다른 경우 아래 포스팅 설정을 적용합니다.

https://yes5.tistory.com/60

소개

FTP 서버를 설정할 때, 여러 가지 문제에 직면할 수 있습니다. 특히 포트 21번과 22번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 21번에서 디렉토리 접근이 제대로 되지 않는 문제를 해결하기 위한 단계별 가이드를 제공합니다.

문제 설명

FTP 서버를 설정한 후, 포트 22번에서는 홈 디렉토리 접근이 잘 되지만 포트 21번에서는 디렉토리 접근이 제대로 되지 않는 경우가 있습니다. 특히, uploaduser라는 계정의 홈 디렉토리가 기본 디렉토리가 아닌 /home/upload로 설정된 경우, 포트 22번에서는 정상적으로 접근되지만, 포트 21번에서는 루트 디렉토리(/)만 보이는 문제가 발생할 수 있습니다.

문제 원인

포트 21번의 문제는 chroot 설정과 관련이 있습니다. chroot는 사용자가 자신의 홈 디렉토리 외부로 접근하지 못하도록 제한하는 기능입니다. chroot가 적용되면, 사용자는 홈 디렉토리의 루트(/)를 볼 수 있게 됩니다.

문제 해결 방법

1. vsftpd.conf 파일 수정

1. chroot_local_user 설정 확인: vsftpd.conf 파일에서 chroot_local_user와 관련된 설정을 확인합니다.

sudo vi /etc/vsftpd/vsftpd.conf

• chroot_local_user=YES가 설정되어 있으면, 모든 로컬 사용자가 자신의 홈 디렉토리로 제한됩니다.
• allow_writeable_chroot=YES는 홈 디렉토리에서 쓰기 권한을 허용합니다.

chroot_local_user=YES
allow_writeable_chroot=YES

특정 사용자에 대한 예외 설정: rankingfiles와 같은 특정 사용자에게 예외를 설정할 수 있습니다.

• chroot_list_enable=YES와 chroot_list_file 옵션을 활성화합니다.

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list

• /etc/vsftpd/chroot_list 파일에 rankingfiles 사용자를 추가합니다.

sudo echo "uploaduser" >> /etc/vsftpd/chroot_list