화이트리스트, 밴, op: 예상과 다르게 작동하는 서버 명령어들
화이트리스트는 이미 접속 중인 플레이어를 추방하지 않고, /ban은 사유가 있어야 쓸모가 있으며, op 목록보다 op 레벨이 더 중요합니다. /op는 기본적으로 /stop까지 포함한 레벨 4를 부여합니다.
관리 명령어는 단순해 보이고, 대체로 정말 단순하다. 문제는 문법만 봐서는 알 수 없는 세 가지 동작에서 터진다.
화이트리스트는 이미 들어와 있는 사람을 내보내지 않는다 — 직접 설정하지 않는 한
/whitelist on는 새로 접속하는 로그인에 대해서만 목록을 적용하기 시작한다. 이미 접속해 있는 플레이어가 추방될지는 server.properties의 한 줄이 결정한다:
enforce-whitelist=true기본값은 false이고, 그 상태에서는 목록에 없는 플레이어가 /whitelist on든 /whitelist reload든 그대로 접속을 유지한다. 이 값을 true로 두면 on, reload, remove 모두 목록에 없는 접속 중 플레이어를 추방한다. 화이트리스트를 켜 놓고 강제 적용은 꺼 둔 채 자리를 뜨는 것이 전형적인 실수다.
두 가지 세부 사항이 더 있다:
/whitelist add <name>는 online-mode 서버에서 Mojang API로 이름을 조회한다. offline-mode 서버에서는 해당 이름의 오프라인 UUID를 대신 화이트리스트에 넣으므로,whitelist.json를 손으로 고칠 필요가 없다.- 운영자는 기본적으로 화이트리스트를 우회한다. 그래서 자기 계정으로는 화이트리스트가 작동하는지 절대 확인할 수 없다. 두 번째 계정으로 테스트하자.
/ban은 사유를 원하고, /ban-ip는 별개의 목록이다
/ban <player> [reason]
/ban-ip <address|player> [reason]사유는 선택 사항인데, 생략하는 것은 실수다. 그건 밴당한 플레이어가 보는 것이고, 나중의 자신이 /banlist을 읽으면서 왜 밴했는지 기억하려고 찾는 것이기도 하다. 사유가 없으면 항목에는 그냥 "Banned by an operator"라고만 적힌다.
/ban와 /ban-ip는 서로 다른 파일에 기록된다(banned-players.json, banned-ips.json). 한쪽을 사면해도 다른 쪽은 지워지지 않는데, 이것이 "사면했는데" 여전히 접속할 수 없는 흔한 이유다. /pardon와 /pardon-ip를 둘 다 사용하자.
op 목록만이 아니라 op 레벨
/op는 기본적으로 레벨 4를 부여하는데, 이는 /stop까지 포함한 완전한 권한이다. 네 단계는 실제로 존재하며 server.properties에서 op-permission-level로 설정할 수 있다:
| 레벨 | 부여되는 권한 |
|---|---|
| 1 | 스폰 보호 우회 |
| 2 | 대부분의 치트 명령어, 명령 블록 |
| 3 | 플레이어 관리 — kick, ban, op |
| 4 | /stop를 포함한 모든 것 |
/kick와 /ban가 필요한 관리자에게는 레벨 4가 아니라 레벨 3이 맞다. 관리에 도움을 주는 사람마다 레벨 4를 나눠주는 것이야말로 계정 하나가 탈취당해 서버가 통째로 날아가는 지름길이다.
function-permission-level는 별개이며 어떤 데이터팩 함수가 실행될 수 있는지를 제어한다. op 레벨은 4인데 이 값을 2로 놔두는 것이 "내 함수가 아무것도 안 해요"의 흔한 원인이다.
목록 명령어들
/banlist players, /banlist ips, 그리고 인자 없는 /banlist 모두 존재하며, 서버 터미널에서 실행하면 채팅이 아니라 콘솔에 출력된다. /whitelist list는 UUID가 아니라 이름만 보여주므로, 신원을 확인해야 할 때는 whitelist.json를 읽자.
이 명령어들은 서버 관리 명령어 빌더에서 올바른 순서의 인자와 함께 만들 수 있다. 이 빌더는 ban, ban-ip, pardon, kick, op, deop, whitelist를 하나의 양식에서 다룬다.