Rocky OS selinux 무한 재부팅

# 오류의 발견

2일 연차 사용으로 9일을 쉬었던 기적의 설 연휴가 지나고 월요일 출근을 맞이하였다.

 

회사에 적응하기 위해 잠시 멍을 때리고 있었는데 선임님이 나를 부르셨다.

 

요지는 지난 주 회사 전기가 나가는 상황이 발생하였고, 왜인지 모르겠지만 그 이후부터 

인프라 담당 서버께서 무한 재부팅을 하고 계시니 이를 해결해보라는 퀘스트였다.

 

우리 팀은 새로운 프로젝트를 진행하기 위해 공용 인프라 서버를 가상으로 띄워둔 상태였다.

 

가상화 소프트웨어는 VMWare ESXi, OS는 Rocky OS 8.5를 사용하고 있고

이 위에 Docker로 MongoDB, MariaDB, Redis, RabbitMQ를 서비스 중이었다.

 

putty 접속이 되지 않았기 때문에 VMWare의 터미널로 인프라 서버에 접속하니 아래와 같은 에러가 뜨고 있었다.

 

회사 전기가 갑자기 나간 후 Rocky OS가 무한 재부팅중이다...

 

# 디버깅

흠.. 보니까 selinux-autorelabel 과정에서 무언가가 안되는 듯 하다.

 

구글님께 검색해보니까 rescue mode로 접속해서 루트 파일 시스템을 변경해보라는 글을 발견하였다.

 

하지만 여전히 같은 에러가 발생하였다...

 

다음 작업으로 selinux가 불평하고 있는 에러를 쪼개서 검색해보았다.

 

처음엔 "selinux-autorelabel secon"으로,

그 다음엔 "secon couldn't read security context"로,

그 다음엔 "inappropriate ioctl for device"로..

 

2시간 정도 뒤졌지만 마땅한 답이 안보이던 찰나 selinux를 아예 꺼버리면 어떻게 될까 궁금해졌다.

 

그래서 맨 처음에 봤던 글처럼 다시 rescue mode로 접속 후 

파일 시스템을 read write로 다시 마운트하고

/sysroot/etc/sysconfig/selinux 파일에서 enforcing으로 되어 있는 selinux 설정을 disabled로 변경하려 했다.

 

그런데..!!

이 파일은 read-only 파일이라 수정이 안되는 것이었다..

 

root 권한으로 해볼까 싶어서 su, sudo, su root, sudo root 등 내가 아는 모든 명령어를 동원해봤지만 모두 Command not found를 뿜고 있었다.

 

이 터미널은 내가 익숙하게 써왔던 그런 환경이 아니었음을 체감한 순간이었다.

 

 

# 해결

하지만 이 파일을 수정할 수 있는 길이 있었으니 그것은 바로 루트 파일 시스템을 먼저 변경하고 selinux 파일을 변경하는 것이었다.

 

chroot /sysroot

 

루트 파일 시스템을 먼저 변경하고 /sysroot/etc/sysconfig/selinux 파일을 변경하자 막힘없이 잘 변경되었다..!!

 

SELINUX를 enforcing 상태에서 disabled 상태로 변경

 

 

그리고 OS를 재부팅하였더니 부팅 무한 재부팅 현상이 사라지고 정상적인 화면이 나왔다 ㅠㅠ

 

드디어 정상 부팅!! ㅠㅠ

 

 

# 마치며..

selinux는 보안과 관련된 부분이라 이걸 이렇게 꺼버려도 될까 걱정했지만

수석님 말씀이 kubernetes 등을 사용하려면 어차피 selinux를 끄고 작업을 많이 한다고 하셔서 그냥 꺼둔채로 놔두기로 하였다.

 

다른 글들을 찾아보니 linux 담당자들이 selinux는 꺼두고 별도로 보안 작업을 진행하는 경우도 많은 것 같다.

 

 

selinux로 인해 누군가가 고통받고 있다면 이런 방식도 참고해보면 좋겠다.