Kudu 의 --logfile_mode 기본값이 436 인데 이 숫자가 무슨 권한인지 알기 어렵다. 게다가 실제로 생긴 로그 파일을 보면 rw------- 다. 설정값과 결과가 달라 보인다.
logfile_mode 는 Kudu 가 glog 에서 물려받은 플래그이고, 타입이 int32 다. 그래서 설정 파일에는 10진수로 적히지만 의미는 유닉스 파일 모드, 곧 8진수 값이다.
436 (10진수) = 0664 (8진수) = rw-rw-r--
계산은 이렇다. 436 을 8로 나누면 몫 54 · 나머지 4, 54 를 8로 나누면 몫 6 · 나머지 6, 마지막 몫이 6 이므로 위에서부터 읽어 664 가 된다.
printf '%o\n' 436 # 664
printf '%d\n' 0644 # 420
즉 기본값 436 은 "소유자 읽기·쓰기, 그룹 읽기·쓰기, 그 외 읽기" 를 뜻한다. 8진수 자릿수를 그대로 4·3·6 으로 읽는 것은 잘못이다.
파일을 만들 때 커널은 요청한 모드에서 프로세스의 umask 에 걸린 비트를 뺀다.
요청 0664
umask 0077
결과 0664 & ~0077 = 0600 → rw-------
Kudu 서비스가 umask 0077 로 돌고 있으면 logfile_mode 를 아무리 664 로 둬도 결과는 600 이다. 설정이 무시되는 것이 아니라 두 값이 함께 작용한 결과다.
서비스의 umask 는 systemd 유닛에서 확인한다.
systemctl show kudu-tserver --property=UMask
cat /proc/$(pgrep -f kudu-tserver | head -1)/status | grep -i umask
두 가지를 함께 맞춘다. 플래그를 0644 의 10진수인 420 으로 두고, umask 가 그룹·기타의 읽기 비트를 깎지 않게 한다.
--logfile_mode=420
[Service]
UMask=0022
Cloudera Manager 환경이라면 Kudu 서비스의 안전 밸브(고급 구성 스니펫)에 gflag 를 넣는다.
Kudu Service Advanced Configuration Snippet (Safety Valve) for gflagfile
--logfile_mode=420
바꾼 뒤에는 새로 생긴 파일로 확인한다. 이미 있던 파일의 권한은 바뀌지 않는다.
ls -l /var/log/kudu/ | head
stat -c '%a %n' /var/log/kudu/*.INFO*
| 원하는 권한 | 8진수 | 플래그에 적을 10진수 |
|---|---|---|
rw------- |
0600 | 384 |
rw-r--r-- |
0644 | 420 |
rw-rw-r-- |
0664 | 436 |
rw-rw-rw- |
0666 | 438 |
로그 파일에 그룹·기타 읽기를 열어 주는 것은 모니터링 에이전트가 읽어야 할 때만 한다. Kudu 로그에는 테이블 이름과 질의 관련 정보가 남으므로 무작정 644 로 열지 않는다.
같은 방식으로 값을 읽어야 하는 gflag 가 더 있다. 파일 모드를 받는 플래그는 대체로 int32 이고 10진수 표기다. 8진수처럼 보인다고 그대로 읽지 않는다.
디렉터리 권한은 이 플래그가 건드리지 않는다. 로그 디렉터리에 접근 권한이 없으면 파일 권한과 무관하게 못 읽는다.