[🛠] IT Operations #2: Untuk Server Linux Perusahaan, Saya Merancang Operasinya Sebelum Memasang Layanan

✨ Ringkasan GPT-5.6 Sol

Catatan tentang mengonfigurasi disk, SSH internal, dan alamat stabil pada Ubuntu Server khusus; memisahkan izin manusia, AI Cell, dan runtime otomatisasi; serta mendokumentasikan seluruh jaringan sebagai fondasi operasional yang dapat dilanjutkan Codex.

Akhirnya saya membangun server Linux khusus untuk layanan perusahaan.

Namun, yang saya buat kali ini bukan sekadar satu komputer yang dapat menjalankan Ubuntu. Ini lebih menyerupai fondasi operasional agar manusia, AI, dan layanan otomatisasi bisnis dapat berjalan bersamaan di satu server tanpa saling menerobos izin dan keadaan masing-masing.

Saat pertama memperoleh SSD, pikiran saya sederhana: pasang Linux di PC Windows, hubungkan melalui SSH, lalu jadilah server. Saya langsung memikirkan GUI. Jangan-jangan saya akan rugi sendiri karena memaksakan CLI hanya agar tampak seperti “server sungguhan”, lalu belakangan membutuhkan login browser atau Computer Use?

Setelah memeriksanya satu per satu, saya menyadari bahwa alasan server membutuhkan GUI dan alasan saya perlu menggunakan GUI adalah dua hal yang sama sekali berbeda. Jika OAuth atau login Codex diperlukan, saya bisa membuka URL yang tampil di SSH melalui browser MacBook. Jika Computer Use diperlukan, saya bisa menjalankannya di Mac atau perangkat kerja, sementara Linux tetap menjadi Runtime tempat hasilnya di-deploy.

Server bukan mesin yang menampilkan layar, melainkan lingkungan yang terus berjalan.

Konfigurasi UEFI, GPT, dan LVM yang Melindungi Disk Windows

Bahkan USB instalasinya membingungkan. Saya mengira jika USB Ventoy menggunakan MBR, Ubuntu juga akan diinstal sebagai MBR. Ketika UEFI: USB, Partition 2 muncul di menu boot, saya juga tidak yakin apakah itu jalur yang benar.

Skema partisi USB dan skema partisi SSD tempat Ubuntu dipasang adalah hal terpisah. Saya hanya perlu menjalankan installer melalui opsi UEFI dan memilih SSD target dengan tepat. NVMe Windows yang sudah ada tidak saya sentuh; EFI System Partition, /boot, LVM, dan root filesystem hanya saya buat di SSD baru berkapasitas 250 GB.

Hal yang paling menakutkan bukan Linux yang sulit, melainkan kemungkinan menghapus disk yang salah. Saat partisi Windows System Reserved ikut terlihat, rasanya partisi itu pun boleh dihapus. Namun, saya kembali mencocokkan model dan kapasitas disk di installer, lalu hanya memilih SSD khusus Ubuntu. Disk Windows yang lama tetap utuh.

Saya memilih instalasi standar Ubuntu Server 24.04.4 LTS, bukan minimized dan bukan Desktop image. Tanpa GUI, yang tersisa adalah dasar pengelolaan berpusat pada SSH dan systemd, siap untuk ditambahkan Docker Runtime nanti.

Reservasi DHCP dan SSH Internal Sebelum Alamat Tetap

Saat instalasi, LAN kabel langsung menerima alamat melalui DHCP. Awalnya saya mengira menekan Create bond akan membuat SSH lebih mudah terhubung atau menetapkan alamat. Namun, bond menggabungkan beberapa NIC untuk redundansi atau menambah bandwidth. Fitur ini tidak berkaitan dengan penetapan alamat satu NIC kabel.

Alih-alih menanam static IP sembarang di server, saya mengikat alamat MAC NIC ke IP internal melalui reservasi DHCP di router utama. Server tetap menjadi DHCP client, tetapi menerima alamat yang sama setiap kali reboot. Dari router, konflik dengan perangkat lain yang memiliki reservasi juga dapat diperiksa.

SSH pun tidak saya buka ke Internet. Saya membuat key Ed25519 khusus MacBook, mencocokkan host key server dengan console, lalu menguncinya ke alamat jaringan internal. Saya tidak membuat forwarding port 22 eksternal di router.

Sesaat setelah instalasi, ssh.service tampil sebagai disabled, sehingga saya sempat mengira SSH terpasang dengan keliru. Nyatanya, ssh.socket aktif dan mendengarkan port 22, sedangkan public-key login terus berhasil setelah reboot. Socket activation dapat menjalankan service terkait saat request masuk, jadi kegagalan tidak boleh disimpulkan hanya dari satu baris status service.¹

Perbedaan antara DHCP lease, reservation, dan IP–MAC binding yang saya pelajari beberapa hari sebelumnya saat memperbaiki gangguan Internet pada router perusahaan langsung terpakai untuk membangun fondasi server ini. Menerima sebuah alamat dan dapat mengelola mesin dengan aman melalui alamat tersebut adalah dua hal berbeda.

Manusia, AI Cell, dan Layanan Tidak Dicampur dalam Satu Akun

Begitu SSH terhubung, saya hampir memasang Oh My Zsh, Powerlevel10k, dan alias pribadi seperti biasa. Di titik itu saya berhenti lagi.

Akun pertama yang dibuat saat instalasi dimiliki perusahaan dan digunakan untuk bootstrap serta pemulihan. Menggabungkan shell harian saya, AI Runtime, dan Operations Automation dalam satu akun itu memang praktis. Namun, siapa menjalankan apa dengan kewenangan mana tidak dapat dibedakan, dan semuanya akan saling terikat ketika penanggung jawab bertambah atau sebuah akun perlu dicabut.

Karena itu, saya lebih dahulu memisahkan akun berdasarkan aturan berikut.

administrator bootstrap
└─ hanya digunakan untuk instalasi dan pemulihan

usr-<person>
└─ akun yang digunakan manusia untuk SSH, sudo, dan pengembangan

aio-cell-<person>
└─ akun tempat AI Cell pribadi berjalan terus-menerus

svc-<domain>-<purpose>
└─ Runtime aplikasi, importer data, atau broker operasi terbatas

Tidak memasukkan nama perusahaan atau jabatan ke username juga disengaja. Seseorang tetap orang yang sama meskipun afiliasi dan perannya berubah. Lebih baik Linux login hanya menunjukkan identitas stabil, sementara izin seperti administrator, developer, atau peserta proyek diubah secara terpisah melalui groups dan RBAC.

Saya memutuskan menaruh OMZ, P10K, dan alias hanya di akun manusia. AI Cell dan service account tidak akan membaca konfigurasi interactive shell; keduanya akan berjalan melalui systemd unit tetap, EnvironmentFile, dan path absolut. Prompt yang cantik meningkatkan efisiensi kerja saya, tetapi tidak berkaitan dengan stabilitas layanan.

Saya belum terburu-buru membuat seluruh akun ini. Lebih dahulu saya menetapkan nama, kepemilikan file, izin login, serta batas akses sudo dan Docker. Menarik batas-batas ini ketika server masih kosong jauh lebih mudah daripada memisahkannya setelah semua tercampur dalam satu akun.

Batas AI Cell Mencakup UID, HOME, hingga OAuth

Perubahan pemahaman terbesar kali ini adalah soal sistem multi-user.

Jika hanya melihat Desktop GUI, pengguna yang tampil pada layar login terasa seperti menguasai seluruh komputer. Di Linux, layar login yang terlihat dan pengguna dengan process yang berjalan adalah konsep berbeda. Beberapa pengguna dapat terhubung melalui SSH secara bersamaan, dan process milik service account yang tidak login pun dapat terus berjalan di bawah systemd.

Struktur ini sangat penting ketika memperluas ke Linux model AI Cell yang pernah saya definisikan ulang per pengguna macOS. Satu AI Cell bukan sekadar nama process.

1 AI Cell
= 1 set Linux UID dan HOME
= 1 set OAuth dan CODEX_HOME
= 1 set Gateway dan Port
= 1 set Session, Memory, dan Workspace
= 1 set systemd unit dan cgroup budget

Jika Cell setiap orang memiliki UID dan HOME berbeda, autentikasi, memori, dan ruang kerja terpisah secara alami. Setiap Cell berjalan pada port atau Unix socket berbeda, dan systemd terus menjalankannya setelah boot meskipun pengguna tidak login melalui SSH. Beberapa Cell dapat hidup bersamaan di satu server tanpa OAuth atau Memory satu Cell digunakan sebagai fallback Cell lain.

Sebaliknya, saya memutuskan tidak memberi AI Cell sudo, mount seluruh NAS, credential administrator DB produksi, atau Docker socket. Dokumentasi resmi Docker juga memperingatkan bahwa group docker memberikan hak akses setingkat root.² Memasukkan akun manusia, AI, dan service ke group tersebut demi kemudahan pada dasarnya akan menghapus batas yang baru saja dipisahkan.

Operasi Docker akan dijalankan secara eksplisit oleh administrator manusia dengan sudo, atau oleh helper terbatas milik root dan systemd unit yang hanya menerima operasi yang sudah ditentukan. AI dapat mengoordinasikan deploy, tetapi tidak akan memiliki shell bebas dan seluruh izin Docker secara langsung.

NAS sebagai Ingress, Linux sebagai Application Runtime

Server Linux tidak hanya ditujukan untuk AI Orchestration. Web, API, dan DB Operations Automation juga akan dijalankan di perangkat yang sama melalui Docker Runtime. Namun, itu bukan berarti semuanya dimasukkan ke satu akun, satu Compose project, dan satu network.

Koneksi eksternal tetap memakai HTTPS dan reverse proxy yang sudah ditangani NAS. Linux menjalankan application yang sebenarnya.

pengguna eksternal
→ HTTPS 443
→ router perusahaan
→ TLS dan hostname reverse proxy NAS
→ frontend Linux
→ API internal Docker
→ DB internal Docker

Port pengelolaan NAS, SSH Linux, serta port API dan DB tidak perlu dibuka langsung ke Internet. NAS tetap menjadi ingress yang menangani hostname dan sertifikat sekaligus titik storage dan backup, sementara Linux menjadi application Runtime. Saya tidak membuang jalur HTTPS eksternal yang dibangun saat memindahkan otomatisasi cuti ke NAS; hanya backend terakhir yang dipindahkan ke server khusus.

Deploy kode dan impor data HR dari NAS juga tidak saya gabungkan menjadi satu pekerjaan.

kode
→ verifikasi release dan artifact hash
→ deploy helper terbatas
→ health check dan rollback

data HR
→ folder read-only yang disetujui di NAS
→ staging, validation, dan preview
→ persetujuan
→ DB transaction dan audit

AI Orchestration dapat menganalisis perubahan dan meminta persetujuan. Namun, deploy nyata dan impor data akan dilakukan secara terpisah oleh broker dan importer yang hanya menerima operasi tertentu. MacBook dapat dipakai untuk pengembangan, dry-run, pemeriksaan preview, dan memulai pekerjaan yang disetujui, tetapi tidak menjadi titik canonical mutation DB produksi.

Saat ini server Linux belum memiliki Docker maupun application DB. Karena itu, saya tidak menyebutnya production backend hanya karena reservasi DHCP dan SSH sudah berhasil. Target reverse proxy NAS baru dapat diubah setelah frontend port, health check, backup dan restore, serta rollback tersedia dengan jelas.

Codex Skill yang Mengingat Seluruh Topology Jaringan

Kesinambungan dengan percakapan berikutnya sama pentingnya dengan konfigurasi server itu sendiri.

Saya memperbarui Codex Skill khusus jaringan perusahaan dan inventaris terperincinya dengan hubungan antara router, dua NAS, Mac Runtime yang sudah ada, server Linux baru, HTTPS eksternal, dan SSH internal. Ini bukan sekadar daftar IP, melainkan pemisahan peran setiap perangkat serta titik awal, hop perantara, dan Runtime akhir setiap aliran traffic.

Skill juga tidak mencampur fakta yang sudah selesai dengan struktur yang akan dibuat nanti.

• Instalasi dan reboot Ubuntu serta SSH internal sudah selesai.
• Identity multi-user dan batas izin sudah diputuskan, tetapi akun belum dibuat.
• Docker, AI Cell, dan Operations Automation di Linux belum di-deploy.
• Reverse proxy NAS baru akan dialihkan ke Linux setelah health dan rollback tersedia.

Sekarang, meskipun membuka sesi Codex baru, saya tidak perlu mulai dengan menjelaskan “Apa IP server tadi?”, “Apakah NAS yang menjalankan application?”, atau “Mengapa service SSH disabled?”. Skill membawa topology sebenarnya, batas keamanan, keadaan yang telah diverifikasi, dan keadaan yang belum selesai sekaligus.

Jadi, server ini belum menjadi production server yang selesai, tetapi juga bukan sekadar SSD kosong dengan Ubuntu terpasang. Pekerjaan selanjutnya adalah benar-benar menjalankan akun manusia, AI Cell, dan Operations Automation Runtime di dalam batas yang sudah ditentukan.

Mulai sekarang, setiap memasang sesuatu, saya mungkin akan bertanya lebih dulu: “Akun mana yang akan menjalankannya?”, “HOME dan credential mana yang dimilikinya?”, dan “Port serta data flow mana saja yang diizinkan?”. Dibanding sekadar membuat satu server, rasanya saya lebih dahulu menetapkan standar untuk terus memperluas server tanpa berulang kali merusaknya.

Referensi

1. Socket unit systemd dapat memantau socket dan mengaktifkan service terkait ketika incoming traffic tiba. Manual resmi systemd.socket ↩

2. Group docker, yang dapat mengakses Unix socket milik Docker daemon, memberikan hak akses setingkat root. Langkah pascainstalasi Docker Engine di Linux ↩