서버 연결: 위치와 플릿

지금까지는 눈앞에 있는 Mac에 관한 내용이었습니다. 매뉴얼의 이 부분에서는 시야를 관리 대상 전체로 넓힙니다. 랙에 설치된 Linux 서버, 아직 macOS Server를 실행 중인 오래된 Xserve, 선반 위의 Raspberry Pi, 클라우드 VPS, 심지어 Windows 호스트까지 포함됩니다. 각 서버는 SSH로 한 번만 연결하면 되며, 그 이후 FrontierStack은 이들을 하나의 플릿으로 취급하여 진단을 실행하고, 명령을 여러 서버에 일괄 실행하고, 사이트를 배포하고, 상태를 감시합니다. 또한 이 Mac이 네트워크상 어디에 있는지도 추적하므로, 집과 사무실, 카페를 오가는 노트북이 지금 단지 보이지 않을 뿐인 서버에 대해 잘못된 경보를 울리지 않습니다.

이 장에서는 플릿의 연결과 운용을 다룹니다. 네트워크와 경계 보안은 9장, 보안 강화와 보안 감사는 10장, 지속적인 모니터링과 알림은 11장에서 더 자세히 다룹니다. AI 관리자는 같은 도구를 사용하여 여기 나오는 거의 모든 작업을 수행할 수 있습니다. 13장을 참조하십시오.

8.1위치 및 장소

위치 및 장소 ▸ 위치를 여십시오. 위치는 단순히 이름이 붙은 네트워크(집, 사무실, VPN 연결 중 등)이며, 여러 신호로 인식됩니다. Wi-Fi SSID, 라우터(게이트웨이) MAC 주소, Wi-Fi BSSID, IP 주소의 서브넷 접두사(예: 192.168.1.), 공인 IP 대역, 그리고 VPN 연결 여부입니다. 헤더에는 현재 위치(현재: 사무실)가 표시되고, 그 아래에 Wi-Fi 이름, IP, 게이트웨이, VPN 상태로 구성된 실시간 스냅샷이 표시됩니다. 감지는 30초마다 실행됩니다.

FrontierStack이 인식하지 못하는 네트워크를 발견하면 새 네트워크가 감지됨 배너를 표시합니다. 추가…를 클릭하여 저장하십시오. 현재 네트워크를 위치로 추가를 누른 다음 조건을 세부 조정할 수도 있습니다. 위치는 설정된 조건이 모두 충족될 때 일치하며(SSID와 라우터 MAC은 그중 하나만 일치하면 됨), 비워 둔 필드는 무시됩니다. 여러 위치가 일치하면 목록의 첫 번째 항목이 아니라 가장 구체적인 위치가 선택됩니다. 자동 감지 대신 위치를 수동으로 고정하려면 모드 선택기를 사용하십시오. 신호가 모호할 때 유용합니다.

모든 신호의 신뢰도가 같지는 않으며, 이는 생각보다 중요합니다. 서브넷 접두사는 식별자가 아닙니다. 가정용 라우터, 카페, 호텔은 어디서나 192.168.1.× 주소를 할당하므로, 서브넷만으로 정의된 위치는 전혀 다른 건물에서도 그대로 일치해 버립니다. 라우터 MAC은 가장 강력한 신호입니다. 하나의 하드웨어에 고유하며 특별한 권한 없이 읽을 수 있습니다. 그래서 라우터 일치 기능이 생기기 전에 저장된 위치는 현재 네트워크에서 모든 조건 업데이트를 클릭 한 번으로 바로잡을 수 있습니다.

8.18.1GPS로 장소 고정

두 장소가 실제로 같은 서브넷을 사용하고 MAC 주소를 일일이 다루고 싶지 않은 까다로운 경우에는 위치에 GPS 핀을 추가할 수도 있습니다. 해당 장소에서 위치를 열고 이 지점 고정(GPS)을 누르십시오. 반경 슬라이더로 어디까지를 “여기”로 볼지 설정합니다(기본값 150 m. 실내 측위는 정밀하지 않고, 장소는 점이 아니라 건물이기 때문입니다).

핀은 필수 조건이 아니라 교차 확인용입니다. 핀은 두 가지 역할을 합니다. 약한 일치를 확인해 주고, 더 유용하게는 잘못된 일치를 거부합니다. 따라서 집이 우연히 같은 서브넷을 쓰는 카페를 자기 위치라고 주장하지 않게 됩니다. 이 기능이 감지를 결코 악화시키지 않도록, 공유될 수 있는 조건(서브넷, VPN 연결 여부)만으로 식별된 위치는 현재 위치 정보가 있고 그것과 모순될 경우 더 이상 확인됨으로 보고되지 않습니다. 확신에 찬 잘못된 답 대신 외부 / 알 수 없음이 표시됩니다.

기기도 위치에 속합니다. 기기 검색에서 모니터링 중인 기기의 ⋯ 메뉴 ▸ 위치에 할당을 선택하면 특정 장소에 배치됩니다. 자동으로 두면 해당 서브넷을 소유한 위치에 자동으로 속하게 됩니다. 기기 자체의 패널에서도 설정할 수 있으며, 각 위치의 행에는 해당 위치에 할당된 기기가 나열됩니다. 사설 서브넷은 장소마다 반복되므로, 다른 곳에 고정된 기기가 서브넷에 의해 어떤 위치에 들어갈 수 있습니다. 그 목록에서 기기의 ×를 누르거나 위치 없음을 선택하면 제거되며, 일치하는 서브넷이 있어도 다시 추가되지 않습니다. Mac이 인식된 위치에 도착하면 FrontierStack은 해당 기기들을 확인하고(VPN 등을 통해 최근에 확인된 기기는 건너뜀) 각각의 상태를 표시합니다. 녹색은 연결 가능, 빨간색은 이곳에 있어야 하지만 응답이 없음, 주황색은 이 Mac이 도달할 수 없는 Wi-Fi 구간에 있음을 뜻합니다. 주황색은 대개 다른 액세스 포인트나 대역에 있는 경우로, 예를 들어 Mac은 5 GHz에 연결되어 있는데 센서는 2.4 GHz 전용인 경우입니다. 주황색은 “사라짐”이 아니라 “여기서는 확인할 수 없음”을 의미합니다.

이 모든 것의 목적은 위치 기반 모니터링 섹션입니다. 개요 ▸ 알림에서 기기, Wi-Fi 네트워크, Cloudflare 영역 또는 감시 항목을 중요 항목으로 표시한 다음, 여기에서 범위를 사무실에서만으로 지정하십시오. 그러면 그 검사는 다른 모든 곳에서 일시 중지됩니다. 호텔에 있을 때 NAS가 DOWN으로 울리지 않고, 회사에 있을 때 집 Wi-Fi가 끊겼다는 알림도 오지 않습니다. 일시 중지된 항목은 돌아오면 조용히 재개됩니다. 위치 자체가 바뀌면 FrontierStack은 로컬 알림을 게시하거나, 메시징 게이트웨이를 통해 “📍 현재 위치: 사무실” 알림을 보내거나, 둘 다 할 수 있습니다.

8.2SSH로 서버 연결

서버는 서버 연결 시트를 통해 플릿에 합류합니다. 이 시트는 기기 패널, 기기 검색, 또는 클라우드 서버 및 원격 도구 패널에서 열 수 있습니다. 이름, 호스트 또는 IP, 포트, SSH 사용자 이름(root, ubuntu, ec2-user…), 로그인 암호를 입력하십시오. 이 암호는 단 한 번만 사용됩니다. 앱은 이 Mac의 관리형 SSH 키를 서버의 authorized_keys에 설치하고, 그 이후로는 키로만 연결합니다. 서버 주소 외에는 아무것도 저장되지 않으며, 암호는 폐기됩니다.

암호 로그인이 없는 키 전용 서버의 경우 암호를 사용할 수 없습니까? 키를 수동으로 설치를 펼치고, 표시된 공개 키를 서버의 authorized_keys에 직접 복사한 다음 연결하십시오. 모니터링 헬퍼도 설치를 선택하면 같은 단계에서 호스트 모니터도 설정됩니다(아래에서 설명).

Windows 서버와 Tailscale 서버. OpenSSH를 실행하는 Windows PC도 같은 방법으로 연결됩니다. FrontierStack은 Windows 셸을 감지하고 PowerShell로 키를 설치합니다. 관리자 계정이면 C:\ProgramData\ssh\administrators_authorized_keys에(sshd가 요구하는 권한으로), 그렇지 않으면 사용자의 .ssh\authorized_keys에 설치합니다. 서버의 SSH 호스트 키는 FrontierStack 자체의 신뢰 저장소에 기록되므로, ~/.ssh/config가 일부 주소의 호스트 키를 버리도록 설정되어 있어도 연결할 수 있습니다(Tailscale용으로 UserKnownHostsFile /dev/null을 지정한 Host 100.* 규칙이 흔히 쓰입니다).

연결된 서버에는 연결 가능 여부를 나타내는 작은 녹색 또는 빨간색 상태 점이 표시됩니다. 서버를 재설치한 뒤나 키가 처음부터 설치되지 않은 경우처럼, 점이 빨간색으로 바뀌고 Permission denied (publickey)가 표시되면 AI 도구 repair_ssh_access가 오래된 호스트 키를 지우고 관리형 키를 다시 설치합니다. 이때 보관함 비밀 값으로 보관해 둔 일회용 로그인 암호를 사용합니다. 암호는 로컬에서 읽혀 키 접근을 다시 설치하는 데 쓰이며, 성공하면 점이 다시 녹색으로 바뀝니다.

호스트의 상태 섹션에는 연결 행도 표시됩니다. 서버의 기본 경로를 실제로 담당하는 연결을 보여 줍니다. 협상된 Ethernet 속도(10 GbE, 2.5 GbE, 1 GbE), 채널 폭을 포함한 Wi-Fi 세대(Wi-Fi 7 = 802.11be, Wi-Fi 6E/6/5), 또는 VPN 터널입니다. Linux, macOS, FreeBSD 호스트에서는 일반 상태 점검 중에 읽히고, 에이전트 전용 호스트에서는 호스트 모니터 에이전트(v1.17 이상)가 보고합니다. 이 Mac에도 같은 행이 표시되며, SNMP 기기에서는 인터페이스 조회 시 각 포트의 협상된 링크 속도가 나열됩니다.

각 서버에는 대화형 셸을 위한 연결 방식 설정(편집 시트에 있음)도 있습니다. 일반 SSH(기본값), mosh(SSH 설정으로 로그인한 다음 자체 UDP 전송으로 전환하므로, 잠자기, 네트워크 이동, 불안정한 연결에도 세션이 유지됩니다), 또는 실험적인 SSH3(QUIC/HTTP3 기반이며, 서버를 UDP 443의 비밀 URL 뒤에 숨길 수 있습니다) 중에서 선택할 수 있습니다. 셸 열기와 SSH 열기는 이 선택을 따르며, 상태 점검과 파일 전송은 항상 일반 SSH를 사용합니다. 두 클라이언트 모두 서비스 카탈로그에 있습니다(mosh는 Homebrew, SSH3는 Go로 설치).

8.3관리형 키와 저장된 sudo 암호

키 접근으로 앱은 서버에 연결할 수 있지만, /var/log 읽기, Apache 구성 편집, 방화벽 다시 로드 같은 유용한 작업의 상당수는 서버의 root 권한이 필요합니다. FrontierStack은 이를 호스트별 sudo 암호로 처리하며, 이 암호는 macOS 키체인에 저장됩니다(일반 파일에는 절대 저장되지 않음). 서버를 연결할 때 자동으로 저장되며, 나중에 호스트 패널이나 원격 도구의 대상 섹션(Sudo 암호 필드)에서 설정하거나 변경할 수 있습니다.

root 전용 명령이 실행되면 헬퍼는 SSH 세션을 통해 저장된 암호로 sudo의 자격 증명 캐시를 미리 채운 다음 명령을 실행합니다. 저장된 암호가 없으면 root 작업은 암호 없는 sudo -n으로 대체되며, 그것이 설정되어 있지 않으면 단순히 “sudo 필요”라고 보고합니다. 비밀 값은 이름으로 참조되므로 여러 개를 보관할 수 있습니다. 예를 들어 .env 보관함에 서버마다 다른 MySQL 암호를 둘 수 있습니다.

8.4플릿 실행: 모든 노드에서 명령 하나 실행

플릿 및 원격 ▸ 플릿 실행은 하나의 작업을 연결된 모든 서버 또는 선택한 일부 서버에 동시에 실행하고, 호스트별 결과를 실시간으로 보여 줍니다. 대상을 선택하고(호스트를 켜고 끄며, 연결 가능 여부 점으로 어느 호스트가 작동 중인지 확인), 작업을 고른 다음 N대 서버에서 실행을 누르십시오. 모든 작업이 SSH를 통해 동시에 실행되고, 각 호스트의 결과가 아래에 표시되며 펼치면 전체 출력을 볼 수 있습니다.

작업은 OS를 인식합니다. 패키지 업데이트는 호스트에 따라 apt, dnf, pacman, zypper, apk 또는 brew로 매핑되고, 서비스 재시작은 systemd를 먼저 시도한 다음 Homebrew를 시도합니다. OS별 명령을 직접 작성할 필요가 없습니다.

플릿 실행은 구성 편차를 찾아내는 가장 빠른 방법입니다. 디스크 사용량이나 가동 시간 및 부하를 실행하여 호스트를 한눈에 비교하거나, 원격 도구(다음 절)의 파일 체크섬 및 상태 검사 도구를 사용하여 플릿 전체에서 달라진 구성을 찾으십시오.

8.5이 Mac 또는 서버에서 컨테이너 만들기

FrontierStack에서 컨테이너를 나열하는 곳에는 모두 Create Container… 버튼이 있으며, 어느 곳에서 누르든 같은 시트가 열립니다. 이 Mac의 Docker 패널, 호스트 선택기에서 연결된 서버를 고른 같은 패널, 그리고 서버 활동 윈도우의 Docker 탭이 그렇습니다. 만든 컨테이너는 시작한 곳의 대상에서 실행됩니다 — 로컬에서는 docker 바이너리를 통해, 서버에서는 이미 갖고 있는 SSH 연결을 통해 실행됩니다.

프리셋에서 시작하거나 빈 상태에서 시작하십시오. 프리셋에는 일반 이미지 — nginx, PostgreSQL, MySQL, Redis, 일회용 Ubuntu 셸 — 와 함께, n8n, Flowise, Langflow, Vaultwarden, Checkmk처럼 앱이 단일 컨테이너로 실행할 수 있는 모든 자체 호스팅 서비스가 포함됩니다. 하나를 선택하면 이미지, 포트, 볼륨, 환경 변수가 채워지며 모두 변경할 수 있습니다. docker-compose 스택이 필요한 서비스는 대신 이 Mac의 해당 서비스 패널에서 설치하며, 시트에 그 이름이 표시되므로 빠진 것처럼 보이지 않습니다.

실제로 실행하기 전에 시트는 비밀 값을 점으로 가린 정확한 docker run 명령줄을 보여 주며, 이를 복사할 수 있습니다. 만들기를 실행하면 먼저 이미지를 가져온 다음(이 동작을 끄지 않은 경우) 실행하고, 출력을 시트에 실시간으로 표시합니다.

8.18.2모니터로서의 Containers 보드

Containers 패널은 단순한 목록이 아닙니다. 이 Mac의 모든 런타임을 하나의 판정으로 모은 상태 점이 있어, 사이드바를 한 번 보는 것만으로 주의가 필요한 것이 있는지 알 수 있습니다. 녹색은 설치된 모든 것이 정상이라는 뜻이고, 주황색은 무언가가 중지되었거나 아직 확인 중이라는 뜻이며, 빨간색은 설치된 엔진이 다운되었거나 컨테이너가 비정상, 재시작 반복 중이거나 오류로 종료되었다는 뜻입니다. 설치한 적이 없는 런타임은 문제로 보지 않습니다 — 따라서 녹색은 “모든 것이 실행 중”이 아니라 “존재하는 모든 것이 정상”이라는 의미입니다.

섹션은 서비스 목록과 같은 순서를 따릅니다. Apple Containers, Docker, Kubernetes, OrbStack, 컨테이너 머신, 그리고 Vagrant 순입니다. Kubernetes는 여기서 읽기 전용으로 표시되며, Kubernetes Clusters에서 고정한 클러스터를 보여 줍니다. 고정과 클러스터별 작업은 그 패널에서 하며, 그 패널은 이 Mac에 있는 것만이 아니라 어디서 실행되든 클러스터 전체를 감시합니다. 런타임이 설치되어 있지 않으면 버튼은 다운로드 페이지로 보내는 대신 해당 런타임을 설치하는 패널을 엽니다.

헤더의 고정 버튼은 작은 플로팅 팔레트를 엽니다. 전체 상태 점과 실행 중인 개수를 보여 주는 상태 막대 하나 아래에 실행 중인 항목의 짧은 목록이 있고, 설정되었지만 유휴 상태인 항목은 Waiting 아래에 묶입니다. 일부러 아주 작게 만들었습니다 — 다른 작업을 하는 동안 화면 구석에 놓아두기 위한 것입니다. 행을 클릭하면 메인 윈도우가 해당 항목으로 이동합니다.

8.18.3Docker Swarm

Swarm은 별도로 설치하는 제품이 아니라 Docker 엔진에 내장되어 있습니다. 그래서 FrontierStack은 Swarm에 별도의 패널을 두지 않고 Docker 패널에서 모니터링합니다. 보고 있는 엔진이 스웜에 속해 있으면 Docker Swarm 섹션이 나타나, 클러스터의 노드(준비 또는 다운, 드레인 중인지 여부, 어느 노드가 매니저인지)와 서비스 및 그 복제본 수를 나열합니다 — 서비스가 요청한 모든 태스크를 갖추면 3/3, 그렇지 않으면 1/3처럼 표시됩니다. 서버 활동 윈도우의 Docker 탭에도 같은 내용이 Swarm 세그먼트로 있어, 어느 연결된 서버에서든 클러스터를 확인할 수 있습니다.

상태는 docker info에서 가져옵니다. 패널이 엔진 상태 확인을 위해 이미 호출하는 명령이므로, 스웜에 속하지 않은 머신은 확인에 추가 비용이 들지 않습니다. Swarm의 규칙 하나가 표시되는 내용을 좌우합니다. 클러스터를 나열할 수 있는 것은 매니저뿐입니다. 워커에 요청하면 데몬이 거부하므로, 워커에서는 FrontierStack이 실패처럼 보이는 빈 표 대신 그 사실을 분명히 알려 줍니다.

8.18.4미리 구성된 스택

어떤 것은 컨테이너 하나가 아니라, 따로 떼어 놓으면 쓸모없는 여러 컨테이너로 이루어집니다. Containers 패널과 서버 활동 윈도우의 Docker 탭에 있는 Install Stack…은 그룹 전체를 한 번에 설정합니다. 앱에는 네 가지가 포함되어 있습니다. *arr 미디어 스택(다른 앱이 읽는 인덱서 목록을 보관하는 Prowlarr, 시리즈용 Sonarr, 영화용 Radarr, 음악용 Lidarr, 도서용 Readarr, 자막용 Bazarr, 그리고 다운로드 클라이언트), Monitoring(Prometheus, Grafana, node-exporter), Media server(Jellyfin, 요청 관리를 위한 Jellyseerr 선택 가능), 그리고 서버, 머신 러닝, Redis, PostgreSQL의 네 컨테이너가 실제로 필요한 자체 호스팅 사진 라이브러리 Immich입니다.

포함할 구성원, 설정 폴더와 미디어 폴더의 위치, 컨테이너가 파일을 기록할 때 사용할 사용자와 그룹, 그리고 이미 수신 대기 중인 것과 겹치지 않도록 스택 전체를 옮기는 포트 오프셋을 선택합니다. 공개 포트는 따로 지정하지 않는 한 127.0.0.1에 바인딩됩니다. 그런 다음 FrontierStack은 프로젝트 폴더에 docker-compose.yml을 작성하고 docker compose up -d를 실행합니다. 스택을 스택답게 만드는 것이 Compose입니다. 구성원들은 네트워크를 공유하고 서로를 이름으로 부르므로, Sonarr의 인덱서 설정을 그냥 http://prowlarr:9696으로 지정할 수 있습니다.

8.18.5Apple 컨테이너와 권장 GUI

Apple 실리콘에서는 macOS가 Apple의 자체 container 명령으로 Linux 컨테이너를 기본 실행할 수 있으며, 각 컨테이너는 하나의 큰 Linux VM을 공유하는 대신 자체 경량 가상 머신을 갖습니다. Containers 패널에는 이를 위한 Apple Containers 섹션이 있습니다. 실행 중인 항목을 나열하고, 컨테이너 시스템을 시작 및 중지하고, 이미지를 가져오고, 새 컨테이너를 만들며, 구성은 위의 Docker 섹션과 같습니다. Apple의 도구는 명령줄 프로그램이며, FrontierStack은 GitHub 릴리스에서 이를 설치합니다.

Apple 컨테이너를 일상적으로 다룰 때는 Davit을 권장합니다. 같은 container 명령에 제대로 된 그래픽 프런트엔드를 제공하는 독립 macOS 앱으로, 하위 명령을 기억하지 않고도 컨테이너와 이미지를 살펴보고, 시작 및 중지하고, 로그를 따라볼 수 있습니다. Apple Containers 섹션에서 Homebrew cask로 설치한 뒤 바로 열 수 있습니다. Davit에는 Apple 실리콘과 macOS 15 이상이 필요합니다.

8.6Remote Tools — 노드별 진단

Fleet & Remote ▸ Remote Tools는 실제 플릿 디버깅 작업에서 추려 낸 SSH 기반 진단 도구 모음입니다. 먼저 대상을 선택하십시오 — 고정된 서버, 또는 저장된 서버가 아닌 임시 주소를 위한 Other (IP / host)…(이 경우에도 sudo 암호가 키체인에 보존됩니다) — 그다음 도구와 매개변수를 선택합니다. 읽기 전용 검사는 root 권한이 필요 없고, 보호된 로그나 설정을 읽는 검사는 헬퍼를 통해 저장된 sudo 암호를 사용하며, 일부는 mutating(변경 작업)으로 표시됩니다.

일부 도구는 선택한 여러 노드에서 한 번에 동작합니다 — File Diff, Healthcheck, TLS Expiry, Serving Path Diagnosis(어느 노드가 살아 있는지, 각 노드가 어떤 공인 IP에 바인딩하는지, 프로세스별 CPU 포화 상태와 중지된 서비스를 고정된 모든 Cloudflare 영역의 오리진 IP와 대조)는 설계상 플릿 전체를 대상으로 합니다 — 모든 웹 노드가 유효한 인증서로 같은 콘텐츠를 제공하는지 확인하는 방법이 바로 이것입니다. 패널 하단에서는 /etc/hosts(헬퍼를 통한 root 권한)와 SSH 사용자의 ~/.ssh/known_hosts를 SSH로 안전하게 편집할 수도 있으며, 각각 먼저 .fsbak으로 백업됩니다.

8.7멈춘 서버 복구 — 그리고 SSH 없이 안전하게 전원 재설정하기

서버는 서비스는 계속 실행되는 상태에서 SSH에만 응답하지 않을 수 있습니다 — 다운된 것이 아니라 과부하 상태입니다. FrontierStack은 이를 표시합니다. SSH에는 연결할 수 없지만 서비스 포트(예: 3306의 MySQL)가 여전히 응답하면, 서버의 점은 빨간색이 아닌 주황색이 되고 패널에 "SSH가 멈췄지만 서버는 여전히 서비스 중입니다"라고 표시되며, 응답 중인 항목이 데이터베이스의 버전 배너와 함께 나열됩니다. 머신은 살아 있고 관리 채널만 멈춘 것이므로, 죽었다고 단정하거나 무작정 전원을 끊지 마십시오.

먼저 일반 Reboot를 시도하십시오. Reboot 후에는 FrontierStack이 유예 시간을 기다린 다음 폴링하는 동안 점이 깜박이며, 호스트가 돌아오는 즉시 새로 고침됩니다 — Refresh를 계속 누를 필요가 없습니다.

SSH 없이 전원 재설정을 안전하게 만드십시오. 데이터베이스가 여전히 응답하면 패널에 빨간 테두리의 EMERGENCY 상자, Prepare databases for a safe power reset이 표시됩니다. 각 단계는 데이터베이스 상태에 저장된 자격 증명을 사용해 데이터베이스 자체 연결(SSH 아님)로 위에서 아래로 실행됩니다. Stop accepting writes(읽기는 계속 가능, 되돌릴 수 있음), Quiesce & flush to disk, 그리고 Clean-shutdown입니다. 정상 종료 후에는 메모리에 손상될 수 있는 미기록 데이터가 남아 있지 않으므로 강제 전원 재투입이 안전합니다. 지원 범위는 엔진마다 다릅니다 — MySQL, Redis, MongoDB는 각 프로토콜로 정상 중지할 수 있고, PostgreSQL은 SQL로 정지 및 플러시할 수 있지만 중지할 수는 없으므로 플러시한 뒤 전원을 재투입합니다. 정상 종료 버튼은 빨간색이며 먼저 확인을 요청합니다.

전원을 재투입한 다음 되살리십시오. 하드웨어 전원 제어(SwitchBot 플러그, 스마트 멀티탭/PDU, KVM)는 각각 확인 단계에서 Shut Down Databases First를 제공하므로, 전원을 끊기 전에 데이터베이스를 플러시하고 중지할 수 있습니다. 그리고 종료로 부하가 해소되어 SSH가 복구되면 Start 버튼으로 SSH를 통해 데이터베이스를 다시 시작합니다 — 따라서 이상적인 순서는 대개 폭주한 데이터베이스를 정상 종료하고, 서버가 회복되게 둔 다음, Start로 다시 시작하는 것이며, 전원 재투입은 전혀 필요 없습니다.

8.8Host Monitor(원격 에이전트)

SSH 진단은 요청할 때만 실행됩니다. 지속적인 가시성이 필요하면 Host Monitor를 설치하십시오 — 서버에 상주하며 자체 상태를 보고하는 작은 읽기 전용 Go 헬퍼(fsagent)로, 주기마다 SSH를 사용하지 않습니다. 연결된 호스트의 패널에서 설치를 선택하거나 Link a Server에서 체크 상자를 선택하십시오. 앱은 기존 키를 통해 호스트의 OS와 아키텍처에 맞는 바이너리를 푸시하고, 플랫폼 서비스(systemd, launchd 또는 BSD rc.d)를 설정하고, TLS 인증서를 고정합니다. AI 도구 install_monitor도 요청에 따라 같은 작업을 수행합니다.

LAN과 Tailscale을 동시에. 모니터는 이 Mac이 설치에 사용한 주소, 그리고 서버 자체의 LAN 주소와 Tailscale 주소에서 수신 대기합니다 — 모든 인터페이스에서 수신 대기하지 않으며, 공인 주소나 컨테이너 브리지 주소에서도 수신 대기하지 않습니다. 한 주소에서 응답이 멈추면(예: 사무실을 떠나 이제 Tailscale로 서버에 접속하는 경우), FrontierStack은 같은 고정 인증서를 제시하는 다른 주소로 전환합니다. 버전 1.22 이전에 설치된 모니터는 한 주소에서만 응답합니다. Detect monitor는 모니터가 실행 중이지만 연결할 수 없을 때 이를 알려 주며, Install & Enroll로 업그레이드할 수 있습니다.

등록이 완료되면 모니터는 실시간 지표를 스트리밍합니다. CPU, 메모리, 마운트별 디스크, 활성 네트워크 인터페이스, 감지된 서비스, 방화벽 및 fail2ban 상태를 보내며, GPU 호스트에서는 GPU별 온도와 사용률도 보내므로 채굴 장비나 ML 장비의 발열 상태가 드러납니다. list_monitors는 플릿의 헬퍼와 그 버전, 최신 지표를 보고합니다. 무엇보다 모니터는 Mac 앱이 오프라인일 때도 계속 감시하며 알림을 보낼 수 있습니다. 자체 채널로 직접 알리고, 앱이 돌아오면 버퍼에 쌓인 내용을 재전송합니다. 로그 윈도우도 모니터를 우선 사용합니다 — 모니터는 서버에서 root로 실행되므로 sudo 암호 없이도 권한이 필요한 로그를 읽습니다.

등록된 호스트의 패널에는 Behavior & History 차트도 있습니다. CPU, 메모리, 디스크, 온도를 5분 단위로 최대 30일간 기록하며, 학습된 기준선과 비교해 비정상적인 동작을 표시합니다. 온도는 도 단위의 별도 눈금을 사용하므로 백분율 기반 리소스 사용량 옆에서도 읽기 쉽습니다. 세로선은 같은 타임라인에 사건을 표시합니다. 빨간 실선은 서버 재부팅(보고된 가동 시간에서 산출)이고, 주황 점선은 워치독 문제 — 서비스 강제 재시작, 데이터베이스 손상 경고, 재부팅 에스컬레이션 — 입니다. OS 충돌 리포터가 CPU를 사용하기 시작하면(프로세스가 반복해서 충돌하는 경우) 주황색 Crashes 곡선이 차트에 추가되므로, "어젯밤 MySQL이 두 번 강제 재시작되었고 무언가가 충돌을 반복하고 있었다"는 사실을 한눈에 알 수 있습니다.

모니터는 기본적으로 읽기 전용입니다. Host Monitor 패널에서 Allow actions를 켜면, 승인 절차를 거치는 monitor_action 도구로 실행되는 작고 고정된 제어 동작 집합이 열립니다 — 임의의 셸 명령은 절대 허용되지 않습니다. 허용 목록에 있는 서비스의 재시작/다시 로드/시작/중지, DNS 캐시 비우기, 방화벽 또는 fail2ban 다시 로드, 재부팅이 가능합니다. 각 작업은 서버에 기록됩니다. 지원 대상은 Linux(amd64/arm64/arm — 모든 Raspberry Pi 포함), macOS(OS X 10.11 El Capitan까지의 레거시 Intel 빌드 포함), FreeBSD(pfSense/OPNsense/TrueNAS), Windows입니다.

모니터를 장기간 건강하게 유지하는 일은 자동으로 처리됩니다. Rotate monitor credential은 베어러 자격 증명을 그 자리에서 교체합니다. 새 비밀 값은 Mac에서 생성되어 승인된 FS1 서명 키를 통해 전송되고, 화면에 표시되거나 AI에 전달되는 일 없이 서버에서 활성화됩니다. Allow self-update를 켜 두면 새 빌드 푸시는 구조적으로 안전합니다 — 후보 바이너리의 릴리스 서명을 검증하고, root 권한을 받기 전에 호환성 자체 테스트를 통과해야 하며, 이전 바이너리는 롤백용으로 보관됩니다. 새 바이너리가 상태 확인에 응답하지 않으면 FrontierStack이 자동으로 이전 바이너리를 복원합니다. 풀 방식 업데이트는 영구 토큰 대신 짧은 수명의 일회용 승인으로 바이너리를 가져옵니다. 모니터가 FS1 서명 요청을 검증하고 있으면 패널에 FS1 signed 배지가 표시됩니다.

8.9Cloud Servers, Server Clone 및 원격 Apache

컴퓨팅 패널과 함께 있는 AWS ▸ DynamoDB는 선택한 리전의 테이블을 상태, 항목 수, 크기, 파티션/정렬 키와 함께 나열합니다. 실제로 비용이 발생하는 두 가지에 초점을 맞춥니다. 용량 모드 캡슐은 사용 여부와 관계없이 읽기 및 쓰기 단위에 대해 계속 요금이 청구되는 프로비저닝 테이블과 요청당 요금이 청구되는 온디맨드 테이블을 구분합니다. 그리고 no PITR 플래그는 특정 시점 복구가 꺼진 테이블을 표시합니다. 특정 시점 복구는 모든 새 테이블에서 기본적으로 꺼져 있으며, 잘못된 쓰기 후 되돌릴 수 있는 유일한 방법입니다. 특정 시점 복구는 각 행의 메뉴에서 켜거나 끌 수 있습니다. DynamoDB에는 일괄 describe 호출이 없으므로 각 테이블을 개별적으로 조회하며, 목록은 리전당 40개로 제한됩니다.

Fleet & Remote ▸ Cloud Servers는 API 토큰이 설정된 모든 클라우드 제공업체 — DigitalOcean, Vultr, Linode, Hetzner, Sakura, Contabo — 와 AWS EC2, Lightsail, RDS의 인벤토리를 하나로 모읍니다. 읽기 전용 집계이며(전원 제어는 각 제공업체의 패널에 남아 있습니다), IP가 있는 실행 중인 인스턴스마다 수신 대기 중인 항목을 찾는 Services 버튼과, SSH로 인스턴스를 연결하고 모니터를 한 번에 설치하는 + Helper 버튼이 있습니다 — 시트에서 올바른 사용자 이름과 키만 지정하십시오.

Server Clone은 플릿 서버를 이 Mac과 같은 구성으로 세우는 안내형 마법사입니다. 감지된 Homebrew 스택을 설치하고, 설정과 사이트 파일을 원래 경로로 복사하고, 도메인 설정을 푸시하고 웹 서버를 다시 로드하며, MySQL 데이터베이스를 복제할 수도 있습니다(로컬 mysqldump를 SSH를 통해 대상의 mysql로 파이프). 모든 단계는 키 기반 SSH로 실행되고 다시 실행해도 안전하며, 기존 데이터는 삭제되지 않습니다.

하나의 사이트를 공개할 준비가 되면, 도메인의 컨텍스트 메뉴에서 Promote to Production 푸시를 사용하십시오. 가상 호스트 설정을 로컬과 같은 경로로 보내고, 선택적으로 문서 루트와 데이터베이스를 복사하고, Cloudflare를 통해 DNS를 대상으로 지정하며, certbot으로 실제 Let's Encrypt 인증서를 발급할 수 있습니다 — 파일, 데이터베이스, 가상 호스트, DNS, HTTPS를 한 번의 푸시로 처리합니다.

원격 서버의 Apache를 직접 관리할 수도 있습니다. 원격 호스트가 하나라도 있으면 Apache 패널에 호스트 선택기(This Mac / 각 연결된 서버)가 추가됩니다. 서버를 선택하면 FrontierStack이 SSH로 해당 서버의 Apache — 버전, 설정 구조, 실제 로그 경로를 포함한 모든 활성 가상 호스트 — 를 찾아내며, 가상 호스트, 모듈, MIME 유형, 포트, WebDAV를 편집할 수 있습니다. 각 변경 사항은 적용 전에 검증(httpd -t)되고 정상적으로 다시 로드되며, 설정이 유효하지 않으면 롤백됩니다. 레거시 macOS Server.app의 Apache 트리도 인식합니다. 사이트 목록의 Push to Server…는 로컬 사이트의 가상 호스트를 문서 루트를 바꿔 넣어 모니터가 연결된 서버에 생성합니다. 이 기능들이 대응하는 로컬 Apache 및 사이트 워크플로는 7장에서 다룹니다.

8.10호스트 화면 공유

각 서버의 패널은 프로브가 감지한 원격 접속 방법을 제공합니다 — Mac은 Apple 화면 공유 / VNC, Windows는 RDP, 그리고 클라이언트가 있으면 AnyDesk, TeamViewer, RustDesk, NoMachine입니다. 이 Mac에 Apple Remote Desktop이 설치되어 있으면 vnc:// 핸들러를 등록해 클릭을 가로채므로, 패널은 항상 Apple의 내장 화면 공유 클라이언트를 여는 별도의 Screen Sharing (macOS) 작업을 제공합니다. 호스트에 둘 이상의 주소로 연결할 수 있으면 — 예를 들어 LAN IP와 VPN 또는 Tailscale 주소 — 이 작업은 연결할 네트워크를 고르는 메뉴가 됩니다. 각 선택 항목은 숫자 IP로 직접 연결하므로, 호스트 이름이 확인되지 않을 때(mDNS, 분할 DNS, VPN 문제)에도 동작합니다. 패널이 확인되지 않을 수 있는 이름을 사용하게 되는 경우에는 VNC와 RDP에도 그에 맞는 “— by IP” 버튼이 나타납니다.

8.11KVM-over-IP: 콘솔과 전원, 원격 관리

SSH와 화면 공유는 머신이 켜져 있고 네트워크에 연결되어 있어야 합니다. 그렇지 않을 때 — 커널 패닉, BIOS/펌웨어 화면, 끝내 올라오지 않은 네트워크 스택 — 에는 대역 외 접근이 필요합니다. 운영 체제와 무관하게 실제 HDMI 출력을 캡처하고 USB 키보드/마우스 입력을 주입하는 KVM-over-IP 장치입니다. Remote KVM 패널에는 보유한 장치를 몇 대든 등록할 수 있습니다 — PiKVM, JetKVM, TinyPilot, NanoKVM, GL.iNet Comet, 또는 일반 장치 — 각각 고정할 수 있고, 클릭 한 번으로 BIOS까지 내려가는 웹 콘솔을 열 수 있습니다.

전원 제어가 있는 장치는 마지막 고리를 채웁니다. ATX 보드를 단 PiKVM, 네트워크 PDU, 또는 KVM이자 스마트 전원 플러그인 GL.iNet의 Comet Pro (GL-RM10)는 주전원을 전환할 수 있어, 완전히 멈춘 서버의 전원을 강제로 재투입할 수 있습니다. 이런 장치를 서버의 Power 섹션(SwitchBot, UPS, PDU 명령 옆)에서 전원 소스로 연결하면 On/Off/Cycle을 사용할 수 있습니다. AI 관리자도 이를 제어할 수 있습니다. list_kvms, kvm_power, server_power가 있으며, 마지막 도구는 호스트에 연결된 플러그/PDU/KVM을 통해 reboot_host에 응답하지 않는 멈춘 서버를 재시작합니다.

8.12콘솔 연결: 시리얼 및 콘솔 서버 접근

네트워크 설정을 잃은 라우터나 스위치는 SSH, 웹 UI, KVM으로 접근할 수 없지만 콘솔 포트는 여전히 동작합니다. Console Connections 패널(Fleet & Remote)은 FrontierStack에 내장된 시리얼 터미널입니다. USB-시리얼 어댑터(FTDI, Silicon Labs CP210x, WCH CH340/CH9102, Prolific)를 꽂거나 기기 자체의 USB 콘솔 포트(Cisco의 USB mini-B 또는 USB-C, Netgate 방화벽)를 연결하면, 몇 초 안에 Attached serial ports 아래에 어댑터의 칩 이름과 함께 나타납니다. Quick Connect는 아무것도 저장하지 않고 선택한 속도로 엽니다. Save as…는 제조사의 콘솔 설정으로 연결을 저장합니다. Cisco, Juniper, Arista, Aruba CX, ProCurve, Ruckus, Fortinet, Palo Alto, SonicWall, WatchGuard, pfSense/OPNsense, MikroTik, Ubiquiti, TP-Link Omada, Dell OS10, Allied Telesis, APC, Raspberry Pi, Linux, 그리고 OpenWrt 및 GL.iNet 라우터의 보드 레벨 UART를 지원합니다.

모든 설정은 편집할 수 있습니다. 속도(460800과 921600을 포함해 어댑터가 지원하는 모든 속도), 데이터 비트, 패리티, 정지 비트, 흐름 제어와 함께, Return 키가 보내는 값(CR, CR LF 또는 LF), ^H로 보내는 Backspace, 로컬 에코, 그리고 화면에 계단식으로 출력되는 기기를 위한 LF → CR LF 변환이 있습니다. 어댑터를 다른 USB 포트로 옮겨 macOS가 이름을 바꾸더라도 FrontierStack은 USB 일련 번호로 다시 찾아냅니다. 콘솔 서버(Lantronix, Opengear, Digi, Avocent ACS, Cisco 터미널 서버의 reverse telnet, 또는 Raspberry Pi의 ser2net)는 telnet, raw TCP 또는 SSH 연결로 추가합니다.

각 세션은 별도의 윈도우에서 열립니다. Break는 라인 브레이크를 보냅니다 — Cisco ROMMON, Juniper 및 대부분의 부트 로더가 암호 복구 중에 기다리는 신호입니다. DTR과 RTS를 켜고 끌 수 있습니다. 붙여넣기 지연은 붙여 넣은 설정을 한 줄씩 보내므로 9600보드 콘솔에서도 문자가 누락되지 않습니다. 세션 로그는 기기가 보낸 모든 내용을 ~/Library/Logs/FrontierStack/Console에 저장하며, Export로 화면을 저장하거나 이메일로 보낼 수 있습니다. 연결을 고정된 기기에 연결하면 해당 기기 페이지의 Console 섹션에 나타나며, 그곳에서 추가한 콘솔은 해당 플랫폼의 일반적인 설정으로 시작합니다. AI 관리자는 콘솔과 연결된 어댑터를 나열할 수 있지만(kvm, 작업 consoles), 세션을 열거나 세션에 입력하지는 않습니다.

8.13부트 미디어: 네트워크로 운영 체제 설치하기

예전에는 서버를 다시 설치하려면 USB 메모리를 들고 랙까지 가야 했습니다. Boot Media 패널(Fleet & Remote)이 그 USB 메모리를 대신합니다. 설치 이미지를 이 Mac의 라이브러리 한곳에 보관해 두면, 선택한 이미지를 FrontierStack이 대상 머신에 가상 CD로 제공합니다 — 서버의 관리 컨트롤러, PiKVM, Proxmox VE 가상 머신의 CD 드라이브 또는 네트워크 부트 메뉴를 통해서입니다. Mac은 Apple이 더 이상 그런 방식의 부팅을 허용하지 않으므로 다르게 처리합니다. 아래의 Mac을 참조하십시오.

8.18.6이미지 라이브러리

Add ISO or Disk Image…는 로컬 파일을 등록합니다. 파일은 원래 위치에 그대로 있으며 아무것도 복사되지 않습니다. Add Image URL…은 이미 웹 서버나 파일 서버(http, https, nfs 또는 cifs)에 있는 이미지를 등록합니다 — 원격 URL은 대상에 그대로 전달되므로 이 Mac이 데이터를 중계할 필요가 없습니다. Compute SHA-256은 파일의 체크섬을 기록하므로, 그 이미지로 무엇이든 설치하기 전에 제공업체가 공개한 체크섬과 비교할 수 있습니다. 각 항목은 이름 변경, Finder에서 보기, 라이브러리에서 제거가 가능하며, Copy Image URL로 제공 주소를 복사할 수 있습니다. 저장된 위치에 파일이 더 이상 없는 항목은 누락됨으로 표시됩니다.

8.18.7내장 미디어 서버

관리 컨트롤러는 설치가 진행되는 동안 ISO를 HTTP로 조금씩 읽어 들여 마운트합니다. 패널의 Media server는 바로 그 용도로 라이브러리의 로컬 이미지를 제공합니다. 가상 CD에 필요한 바이트 범위 요청과 keep-alive를 지원하며, 최근 요청 로그와 이미지별 전송 바이트 수를 보여 주므로 컨트롤러가 실제로 읽고 있는지 확인할 수 있습니다. 대상에 로컬 이미지가 필요하면 자동으로 시작되며, 직접 Start Serving을 눌러 시작할 수도 있습니다.

8.18.8서버 관리 컨트롤러(Redfish)

대부분의 랙 서버에는 이미지를 가상 CD로 제공할 수 있는 베이스보드 관리 컨트롤러가 탑재되어 있습니다. FrontierStack은 표준 DMTF Redfish API로 이를 제어합니다. 대상은 Dell iDRAC 8 및 9, HPE iLO 4, 5 및 6, Lenovo XClarity Controller(XCC), Supermicro X12 이상, 그리고 표준 Redfish 가상 미디어를 구현한 그 밖의 모든 컨트롤러입니다.

1. Add Controller를 누르고 주소, 포트, 사용자 이름, 암호를 입력하십시오. 암호는 키체인에 보관되며 컨트롤러에만 전송됩니다. 필요하면 컨트롤러를 플릿 서버에 연결하여 둘을 함께 표시할 수 있습니다. Virtual Media 및 Control 권한이 있는 계정을 사용하십시오.
2. Read Controller는 컨트롤러가 관리하는 대상을 검색합니다. 각 시스템의 모델과 전원 상태, 그리고 각 가상 CD 슬롯과 현재 마운트된 내용이 표시됩니다.
3. System, Virtual CD, Image를 선택하십시오. Boot from it once를 켜 두면 CD로 한 번만 부팅하고, 그 후에는 서버가 원래 부팅 순서로 돌아갑니다.
4. Then에서 Don't restart, Graceful restart 또는 Force restart를 선택하고 Mount(또는 먼저 확인을 요청하는 Mount and Restart)를 누르십시오.
5. 설치가 끝나면 가상 CD를 Eject하십시오.

8.18.9IPMI 컨트롤러와 1회 네트워크 부팅

오래된 보드에는 Redfish가 없거나, Redfish는 있어도 가상 미디어가 없는 컨트롤러가 탑재되어 있습니다: Supermicro X10/X11, ASRock Rack, Gigabyte, Intel, iDRAC 7. 이러한 컨트롤러는 Protocol을 IPMI over LAN으로 설정하십시오. 그러면 FrontierStack이 ipmitool로 제어합니다(Install ipmitool은 앱 내 콘솔에서 Homebrew로 설치합니다). 암호는 키체인에 보관되며 명령줄이 아닌 환경 변수로 ipmitool에 전달됩니다. Read Controller는 전원 상태를 표시합니다. IPMI에는 표준 가상 미디어가 없으므로, IPMI로 OS를 설치하는 방법은 네트워크입니다. Network Boot Once는 다음 부팅을 PXE로 설정하고(chassis bootdev pxe, Legacy BIOS boot를 선택하지 않으면 UEFI 모드), 필요하면 하드 리셋을 보내거나 서버가 꺼져 있으면 전원을 켭니다. IPMI에는 정상 재시작이 없습니다.

Redfish 컨트롤러에도 Network Boot Once가 있습니다. 1회 Pxe 부팅 재정의 후 선택한 방식으로 재시작합니다. 아래의 내장 PXE 서버와 조합하면 가상 미디어 없이도 원격 서버를 이 Mac의 ISO 메뉴로 부팅할 수 있습니다.

8.18.10PiKVM 가상 미디어

PiKVM은 연결된 머신에 USB 드라이브를 에뮬레이트할 수 있습니다. Boot Media는 PiKVM의 문서화된 /api/msd 인터페이스를 사용하며, ATX 전원 제어와 같은 PiKVM API 계정을 씁니다(KVM-over-IP 참조). 먼저 이미지를 PiKVM 자체 저장소에 복사하십시오. 로컬 파일은 진행률 막대와 함께 업로드되며, 원격 URL은 PiKVM이 직접 다운로드합니다. 복사를 시작하기 전에 여유 공간을 확인합니다. 그런 다음 저장된 이미지를 As CD-ROM(ISO의 경우) 또는 As Flash(raw .img의 경우)로 연결하고, 머신의 부팅 메뉴에서 선택하거나 Power Cycle…(확인 후 수행하는 하드 ATX 전원 재투입)을 사용한 뒤, 콘솔을 열어 설치 과정을 지켜보십시오. 작업 후에는 Disconnect Drive와 삭제로 정리합니다.

8.18.11Proxmox VE 가상 머신

Proxmox VE의 가상 머신(아래 Proxmox VE에서 설명한 대로 연결)의 경우 Node, Virtual machine, ISO storage를 선택한 다음 Source를 선택하십시오. Image from the library는 Proxmox가 직접 이미지를 ISO 저장소로 다운로드하게 하므로(download-url 호출), 로컬 이미지는 이 Mac의 미디어 서버에서 가져옵니다. ISO already on Proxmox는 이미 그곳에 있는 ISO를 사용합니다. FrontierStack은 ISO를 VM의 CD 드라이브에 연결하고 부팅 순서에서 CD를 맨 앞에 둘 수 있습니다 — 원래 순서는 기억되었다가 꺼낼 때 복원됩니다. 마지막으로 VM을 그대로 둘지, 시작할지, 리셋할지(확인을 요청하는 하드 리셋) 선택하십시오.

API 토큰에는 다운로드를 위한 Datastore.AllocateTemplate과 Sys.AccessNetwork, 그리고 VM에 대한 VM.Config.CDROM, VM.Config.Options, VM.PowerMgmt 권한이 필요합니다. 패널은 컨트롤 옆에 이 목록을 표시합니다.

8.18.12네트워크 부팅(PXE / iPXE)

컨트롤러도 KVM도 없는 머신도 네트워크로 부팅할 수 있습니다. Serve an iPXE boot menu from this Mac을 켜면 미디어 서버가 iPXE 메뉴도 함께 공개합니다. 이 메뉴는 라이브러리의 모든 ISO를 HTTP로 SAN 부팅하고, 설치 프로그램 카탈로그가 있는 netboot.xyz로 체인하며, iPXE 셸과 boot from local disk를 제공합니다. Download iPXE Boot Loaders는 boot.ipxe.org에서 공식 로더(ipxe.efi, undionly.kpxe, arm64용 ipxe.efi)를 가져오므로 UEFI HTTP Boot 클라이언트가 이 Mac에서 직접 iPXE를 로드할 수 있습니다.

남은 일은 부팅하는 머신을 어디로 보낼지 DHCP 서버에 알려 주는 것입니다. 사용 중인 DHCP server를 선택하고 Copy Settings를 누르면 바로 쓸 수 있는 설정 조각이 복사됩니다.

8.18.13내장 PXE 서버

네트워크에 dnsmasq가 없고 DHCP 서버도 변경하지 않으려면, 네트워크 부팅 설정에서 Answer PXE clients from this Mac을 켜십시오. 그러면 제공이 켜져 있는 동안 Mac이 두 가지 작은 서비스를 실행합니다.

• ProxyDHCP(UDP 67 및 4011)는 네트워크 부팅을 요청하는 머신(PXE 펌웨어, UEFI HTTP Boot, iPXE)에만, 그리고 부트 파일만 응답합니다. 주소는 절대 할당하지 않으므로 라우터의 DHCP는 이전과 똑같이 계속 작동합니다.
• TFTP(UDP 69, 읽기 전용)는 세 가지 iPXE 로더만 제공하고 그 밖에는 아무것도 제공하지 않습니다. BIOS 머신은 undionly.kpxe, UEFI x64 머신은 ipxe.efi, ARM64 머신은 ARM64용 ipxe.efi를 받습니다. UEFI HTTP Boot 클라이언트는 대신 HTTP로 로더를 받습니다. iPXE가 실행되면 다시 요청하여 메뉴를 받습니다.

응답할 Network를 선택하고(서비스는 그 인터페이스 하나에만 바인딩됩니다), 필요하면 응답할 머신의 MAC 주소만 나열하십시오. 각 요청과 전송은 스위치 아래에 표시됩니다. 로더는 처음에 자동으로 다운로드됩니다. pf 또는 애플리케이션 방화벽이 켜져 있으면, 서버 섹션의 방화벽 버튼이 이제 UDP 67, 69, 4011도 함께 엽니다.

8.18.14기타 KVM-over-IP 장치

JetKVM, GL.iNet Comet, NanoKVM, TinyPilot, Raritan, ATEN, Avocent, Lantronix, Adder 장치에는 가상 미디어용의 안정적인 공개 API가 없으므로, FrontierStack은 이를 제어하는 척하지 않습니다. 대신 Copy URL이 제공을 시작하고 KVM이 접근할 수 있는 이미지 주소를 복사하며, 패널은 해당 제공업체의 자체 콘솔에서 어디에 붙여넣어야 하는지 보여 줍니다.

8.18.15Mac

Mac은 설치 프로그램 ISO로 부팅할 수 없고 네트워크 부팅도 사라졌습니다. Apple silicon에는 네트워크 부팅이 없으며, Intel NetBoot는 macOS Server 5.7에서 서버 기능이 없어졌고 전체 보안 설정의 T2 Mac에서는 거부됩니다. 그래서 Mac의 경우 Boot Media는 Apple이 지원하는 방식으로 macOS를 설치합니다 — SSH로 Mac 자체에서 Apple의 전체 설치 프로그램을 다운로드해 실행하는 방식입니다. 플릿의 모든 원격 Mac에 카드가 표시됩니다(먼저 Remote Servers에서 Mac을 추가하십시오).

• Refresh는 macOS 버전, Apple silicon·Intel·T2 탑재 Intel 여부, 모델, 여유 공간, 이미 있는 설치 프로그램, 콘텐츠 캐싱 사용 여부를 읽어 옵니다.
• List는 사용 가능한 전체 설치 프로그램을 Apple에 조회하고(softwareupdate --list-full-installers), Download on 해당 Mac은 그중 하나를 백그라운드에서 진행률과 함께 가져옵니다(--fetch-full-installer).
• Install…은 startosinstall을 두 가지 모드 중 하나로 실행합니다: Upgrade / reinstall (keeps data) 또는 Erase and install. Apple silicon에서는 볼륨 소유자만 설치를 시작할 수 있으므로 관리자 사용자와 그 암호를 입력합니다. 암호는 표준 입력으로 startosinstall에 전달되며 저장되지 않습니다.
• Turn On Content Caching(이 Mac 또는 플릿의 아무 Mac에서)은 Apple의 업데이트와 설치 프로그램 사본을 LAN에 보관하므로, 다른 모든 Mac이 Apple 대신 그곳에서 다운로드합니다.
• KVM이 연결된 Intel Mac의 경우 Internet Recovery…는 확인 후 Apple 자체의 네트워크 복구로 재시작합니다. 복구 모드에는 화면 공유나 SSH가 없으므로 이를 조작하려면 KVM이 필요합니다.

8.18.16AI 관리자에서 사용하기

AI 관리자와 MCP 클라이언트는 기존 kvm 도구를 통해 Boot Media에 접근합니다. media_list(읽기 전용)는 라이브러리, 미디어 서버 상태, 각 컨트롤러의 전원과 마운트된 이미지, 각 PiKVM의 드라이브를 보고합니다. media_attach는 대상 — 이름으로 지정한 컨트롤러나 PiKVM, 또는 proxmox:<vmid> — 에 이미지를 마운트하며, boot=true를 지정하면 그 이미지로 재시작도 합니다. media_eject는 이미지를 제거합니다. 연결, 꺼내기, 재시작에는 Allow changes가 필요하며 항상 확인을 요청합니다(13장).

8.14Proxmox VE: 실시간 클러스터 상태와 게스트 전원

Proxmox VE 호스트는 서버로 가득 찬 서버이며, 노드에 SSH로 접속하는 것만으로는 게스트에 대해 알 수 있는 것이 많지 않습니다. 그래서 Proxmox VE 서비스 페이지(Containers 카테고리, 6장 참조)는 Proxmox 자체 API와 통신합니다. Add Connection을 누르고 클러스터 또는 단일 노드의 주소와 API 토큰을 입력하십시오 — 토큰 ID는 user@realm!name 형식이며, 그 비밀 값은 키체인에 보관되고 Authorization 헤더로만 전송됩니다. Proxmox의 자체 서명 인증서는 사설 주소에서만 허용됩니다. 상태 확인에는 PVEAuditor 역할의 토큰으로 충분하며, 전원 제어와 부트 미디어에는 위에 나열한 추가 권한이 필요합니다.

연결되면 페이지에 클러스터 이름, Proxmox 버전, 쿼럼이 표시되고, 노드별 CPU, 메모리, 루트 디스크, 가동 시간, 모든 VM과 컨테이너의 상태, 저장소별 사용량 막대가 표시됩니다. 각 게스트는 시작, 종료, 재부팅할 수 있으며, 확인 후 강제 중지나 리셋도 할 수 있습니다. Show in Server Activity와 Boot an ISO…는 Proxmox가 나타나는 다른 두 곳으로 이동합니다.

서버 활동 윈도우(11장)에서는 모든 노드가 All Servers, Cluster, Everything 레이아웃의 타일로 표시되며, CPU, 메모리, 디스크, 가동 시간 스파크라인과 “5/7 VMs · 2/3 containers running” 같은 줄이 함께 나타납니다. 노드 세부 정보에는 KPI, CPU 및 메모리 차트, 같은 전원 컨트롤이 있는 게스트 목록, 저장소와 클러스터 정보, 그리고 Open Web UI, Refresh, Boot an ISO…가 표시됩니다.

알림은 백그라운드에서 각 연결을 약 5분마다 새로 고치며 감시합니다: API 접근 가능 여부, 각 노드의 온라인 상태, 클러스터 쿼럼, 사용률이 90%를 넘은 저장소. AI 관리자는 kvm 도구의 proxmox_status 동작(읽기 전용)으로 같은 내용을 볼 수 있으며, proxmox_power로 게스트의 전원을 변경할 수 있습니다. 이때는 항상 확인을 요청합니다.

8.15오래된 Mac, Raspberry Pi & Windows 호스트

플릿의 의미 중 하나는 오래되었거나 특이한 하드웨어를 계속 쓸모 있게 유지하는 것입니다. 아직 macOS Server를 실행하는 구형 Xserve나 Mac mini도 다른 호스트와 똑같이 연결됩니다. Remote Apache 검색은 Server.app 고유의 Apache 트리와 내부 포트를 이해하므로 해당 웹 사이트가 표시되고 편집할 수 있으며, 모니터의 레거시 Intel 빌드는 OS X 10.11 El Capitan까지 거슬러 올라가 실행됩니다. 선반 가득한 Raspberry Pi도 일반 Linux 머신으로 연결됩니다 — 모니터의 arm 빌드가 Zero를 포함한 모든 Pi를 지원합니다 — 따라서 다른 모든 것과 나란히 CPU, 디스크, 서비스를 지켜볼 수 있습니다.

Windows 호스트는 Microsoft의 OpenSSH 서버를 통해 참여합니다. SSH 진단을 위해 Linux 머신처럼 연결하고, 모니터를 네이티브 Windows 서비스로 설치하십시오(Windows 서비스는 머신 환경 변수를 안정적으로 상속하지 않으므로 설정은 실행 파일 옆의 파일에서 읽습니다). Windows용 모니터는 자동으로 푸시되지 않으며, Host Monitor 패널에서 제공하는 PowerShell 설치 프로그램으로 수동 설치합니다.

진단을 넘어서는 대화형 제어를 위해 카탈로그에는 원격 접근 도구 — RustDesk, MeshCentral, Apache Guacamole, Windows 원격 데스크톱, WinRM — 도 들어 있지만, 이들은 직접 운영하는 서비스이지 SSH 플릿 자체는 아닙니다. 플릿의 강점은 모든 것을 하나의 윈도우에서 일관되고, 스크립트로 자동화할 수 있으며, 부담이 적게 관리한다는 점입니다 — 그리고 13장의 run_script로 어느 노드든 이름으로 지정할 수 있으므로, AI가 원격 서버를 두 단계씩 진단하고 수정할 수 있습니다: 읽기 전용 테스트, 그다음 최소한의 수정, 그리고 다시 실행하여 확인.

8.16OpenCore Legacy Patcher Mac: 업데이트해도 안전할까?

오래된 Intel Mac 중 일부는 OpenCore Legacy Patcher(OCLP) 덕분에 Apple이 해당 기종용으로 출시한 적이 없는 최신 macOS를 실행하고 있을 것입니다. 이 경우 재부팅의 의미가 달라집니다. 일반 서버 Mac은 전원 → macOS → FrontierStack 에이전트 순으로 부팅하지만, OCLP Mac은 전원 → 펌웨어 → EFI/OpenCore → macOS → OCLP 루트 패치 → FrontierStack 순으로 부팅합니다. 연결 고리가 하나 늘어날 때마다 무인 부팅이 멈출 수 있는 지점이 생깁니다. macOS 업데이트는 봉인된 시스템 볼륨을 교체하면서 루트 패치도 함께 없애 버리고(Wi-Fi, 그래픽 가속, Bluetooth가 다시 적용될 때까지 사라짐), 메이저 업그레이드에는 먼저 그에 맞는 OCLP 릴리스가 필요하며, 펌웨어의 시동 항목이 OpenCore를 가리키지 않게 되면 누군가 Option 키를 누른 채 “EFI Boot”를 선택할 때까지 머신이 부팅 선택 화면에 멈춰 있습니다 — 그 Mac이 다른 건물에 있다면 훨씬 더 번거로운 일입니다.

OpenCore Patcher 패널(Fleet & Remote)은 Update를 누르기 전에 이를 알 수 있도록 존재합니다. This Mac 또는 연결된 Mac을 선택하면 읽기 전용 검사를 실행합니다 — OCLP 앱 버전, OpenCore의 NVRAM 스탬프(Mac이 실제로 OpenCore를 거쳐 부팅했을 때만 존재), 루트 패치 영수증, bless --getBoot, SIP, 소프트웨어 업데이트 설정, OpenCore가 위장한 모델 뒤의 실제 모델 — 그리고 이를 Remote boot safety 목록으로 정리합니다: 펌웨어 부트 항목 → OpenCore, 기본 부팅 볼륨 설정, 무인 재부팅에 대한 FileVault의 영향, 루트 패치의 존재 및 최신 여부, OCLP 릴리스의 설치된 macOS 지원 여부(최신 GitHub 릴리스와 대조), 대기 중인 macOS 업데이트, macOS 자동 설치 꺼짐, EFI/OpenCore 백업. 그 위에 하나의 판정이 이유와 함께 표시됩니다: Safe to update macOS, Update with caution 또는 Not safe.

이 패널은 의도적으로 OCLP를 관리하지 않습니다 — OpenCore 빌드와 루트 패치 적용은 OCLP 자체 앱에서 수행합니다. 대신 고정된, 되돌릴 수 있는 세 가지 관리 동작을 제공합니다: macOS 자동 설치 끄기(시스템 설정이 OCLP Mac을 무인으로 업데이트하지 않도록), EFI 백업(해당 Mac에 보관되는 EFI/OC 폴더의 아카이브), OpenCore 다시 bless(OCLP의 “Install to disk”가 실행하는 것과 같은 bless --setBoot, OpenCore.efi가 실제로 있지 않으면 거부). 플릿 상태 검사도 모든 고정된 Mac에서 OCLP를 감지합니다. 호스트 행과 서버 활동 윈도우에 표시되며, 루트 패치가 없거나 부트 항목이 OpenCore를 우회하면 알림이 보안 항목을 발생시킵니다.

8.17마이그레이션 마법사: 스택을 새 기기로 옮기기

오래된 서버를 퇴역시킨다고 해서 “모든 것을 손으로 다시 설치”해야 하는 경우는 드뭅니다. FrontierStack에는 레거시 머신에서 스택을 들어내 선택한 대상 — 이 Mac, 다른 Mac 또는 Linux 머신 — 에 다시 구축하는 안내형 마이그레이션 마법사가 포함되어 있습니다. 원본은 읽기만 하며, 모든 쓰기는 대상에 이루어집니다.

Migrate Setups 패널은 MAMP, XAMPP 또는 Apple Server.app 웹 스택을 처리합니다. 원본을 자동으로 감지한 다음, 옮길 항목을 정확히 선택할 수 있습니다: Homebrew 도구, 웹 파일, MySQL 데이터베이스, 사이트(가상 호스트), MIME 재정의, Apache 모듈, PHP 설정, WordPress wp-config.php 수정, Git 저장소. Set up on 선택기로 대상을 고릅니다. 전체 앱 내 마이그레이션을 하려면 This Mac으로 두고, 연결된 호스트를 선택하면 SSH를 통해 새 기기에 스택을 설치하면서 웹 파일(rsync)과 데이터베이스(SSH를 통한 덤프)를 복사합니다 — Homebrew 대신 apt/dnf를 사용하는 Linux 토글도 있습니다.

패널의 Servers 섹션에는 Import from a Repo…도 있습니다. SSH 설정, Ansible 인벤토리 또는 .env 파일이 들어 있는 폴더나 git 저장소를 지정하면, 검토를 거친 후 서버를 플릿에 추가하고 자격 증명을 Script Secrets 또는 해당 서비스에 추가합니다. FrontierStack AI는 값을 한 번도 보지 않고 다른 구성도 읽을 수 있습니다(13장).

Apple Server Migration 패널은 Server.app 머신 전체를 위한 원클릭 마법사입니다. 원본(이 Mac 또는 원격 Mac)을 지정하면 serveradmin으로 모든 서비스 — 웹 사이트, 메일, 캘린더 및 연락처, 메시지(XMPP), VPN, DNS, DHCP, NetInstall, Open Directory, 파일 공유, Time Machine, 프로파일 관리자 등 — 의 목록을 작성하며, 또한 git 서버, 데이터베이스, Docker, 독립 실행형 Nginx 등 실행 중인 그 밖의 항목도 찾아냅니다. 각 서비스에는 상태 배지와 최신 대체 서비스가 표시되며, 합리적인 대체 서비스가 둘 이상인 경우(캘린더 → Radicale / SOGo / Baïkal, VPN → WireGuard / strongSwan, DHCP → dnsmasq / Kea) 어느 것을 쓸지 선택합니다. 대상 머신과 OS를 선택하면 마법사가 대체 서비스를 설치하고 정확한 이전 체크리스트를 출력합니다. 전용 가져오기 기능이 있는 서비스 — 웹 사이트(가상 호스트 전체 + 파일 복사)와 Open Directory(사용자 및 그룹) — 는 각자의 패널로 넘겨지며, 감지된 git 서버는 Git Server 마이그레이션으로 넘겨집니다.

8.18Git Server: Gitea & 저장소 마이그레이션

Git Server 패널은 자체 호스팅 Gitea(자동 HTTPS를 위해 Caddy 뒤에 배치)를 어떤 대상 — 이 Mac, 연결된 서버, NAS, Docker 호스트 또는 Linux 머신 — 에든 구축하며, 플랫폼을 감지하여 알맞은 방법으로 설치합니다. 실행되면 액세스 토큰으로 연결하여 실시간 모니터를 사용할 수 있습니다: 버전, 저장소 수, 그리고 미러가 원본보다 뒤처지면 알리는 백업 지연 알림.

같은 패널은 다른 Git 서버를 Gitea로 마이그레이션하거나 미러링합니다. 디스크의 bare 저장소 — 레거시 macOS 앱 Simple Git Server, Xcode Server, Gitolite, 일반 git-daemon 또는 아무 폴더 — 를 지정하거나, git://, https:// 또는 ssh:// 클론 기본 주소로 실행 중인 원격 서버를 지정하십시오(저장소 이름은 SSH로 열거하거나 붙여넣기). Scan은 저장소를 나열하고, Migrate는 각 저장소를 전체 기록, 모든 브랜치와 태그와 함께 미러 클론한 뒤 Gitea로 푸시하며, 대상 저장소는 API로 생성합니다. 복사는 이 Mac에서 실행됩니다.