Sunucuda Dosya Düzenlemek: vim'in Temel Komutları, nano, sudoedit ve Config Dosyasını Güvenle Değiştirmek

Sürüm notu: Bu yazıdaki örnekler Ubuntu Server 24.04.5 LTS (vim 9.1, nano 7.2, sudo 1.9.15p5, Nginx 1.24, OpenSSH 9.6p1, etckeeper 1.18.20) çalıştıran, systemd'li bir test sunucusunda ve Ubuntu 26.04.1 LTS container image'ında (vim 9.1, nano 8.7.1, sudo-rs 0.2.13) denenmiştir. vim'in upstream'deki güncel sürümü 9.2; Ubuntu iki LTS'te de 9.1'i yamalarla dağıtıyor ve bu yazıdaki komutlar iki sürümde aynı.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) sunucusuna bağlandın ve vim'e alışkın olduğun için ~/.bashrc'nin sonuna şunu ekledin:

$ tail -n 1 ~/.bashrc
export EDITOR=vim
$ echo $EDITOR
vim

Sonra aynı oturumda dört komut çalıştırıyorsun: crontab -e, sudo systemctl edit nginx, sudo visudo -f /etc/sudoers.d/bookstore-deploy ve sudoedit /etc/nginx/sites-available/bookstore. Hangileri vim'i, hangileri başka bir editörü açar? Cevap "Hangi Editör Açılır?" bölümünde.

Sunucuda dosya düzenlemek bu serinin her yazısında geçti: beşinci yazıda systemctl edit ve crontab -e, üçüncüde visudo, on birincide sshd_config. Ama editörün kendisini hiç konuşmadık. Bu yazıda vim'de kaybolmadan iş görecek kadar komutu, nano'yu, editörün nasıl seçildiğini ve bir config dosyasını sunucuyu bozmadan değiştirme sırasını anlatıyoruz.

vim'de Hayatta Kalmak: Mode'lar, Kaydetmek ve Çıkmak

vim'i ilk kez açanların çoğu çıkamaz, çünkü klavyeden yazdıkları metin olarak değil komut olarak yorumlanır. vim mode'larla çalışır:

• Normal mode: açılıştaki mode. Tuşlar komuttur: dd satır siler, u geri alır. Nerede olursan ol Esc seni buraya döndürür.
• Insert mode: i (imlecin önüne), a (arkasına), o (alta yeni satır) ya da O (üste yeni satır) ile girilir; burada yazdığın metindir. Ekranın altında -- INSERT -- görünür.
• Command-line mode: normal mode'da : ile açılır; kaydetme, çıkma ve değiştirme komutları buraya yazılır.

Çıkmanın dört hâli var ve hepsi önce Esc ile başlar: :w kaydeder, :q çıkar (kaydedilmemiş değişiklik varsa izin vermez), :wq kaydedip çıkar, :q! değişiklikleri atıp çıkar. Bir dosyayı yanlışlıkla bozduğunu düşünüyorsan :q! en güvenli çıkış. vim'in kendi eğitimi vimtutor ile açılır; yarım saatini alır ve aşağıdaki her şeyi elle denetir.

Hareket, Arama, Değiştirme ve Kopyalama

Sunucuda ihtiyacın olan komutların neredeyse hepsi şu tabloda. Hepsi normal mode'da yazılır; : ile başlayanlar ekranın altına düşer ve Enter ile çalışır.

dd, yy ve hareket komutları başına sayı alır: 3dd üç satır siler, 5j beş satır aşağı iner. :%s'teki % "bütün satırlar" demek; onu yazmazsan değiştirme yalnızca imlecin bulunduğu satırda olur.

Yapıştırırken girintinin bozulması ayrı bir konu. Terminalden yapıştırdığın metin vim'e tuş tuş yazılmış gibi gelirse, vim her yeni satırda bir önceki satırın girintisini korumaya çalışır ve üstüne yapıştırdığın boşlukları ekler. Bir YAML (girintiye dayalı config formatı) dosyasına yedi satır yapıştırdığımda sonuç buydu:

services:
    api:
          image: bookstore-api:1.4.2
                ports:
                        - "127.0.0.1:5000:8080"
                              environment:
                                      - ASPNETCORE_ENVIRONMENT=Production

YAML'da girinti anlam taşıdığı için bu dosya artık başka bir dosya. Güncel vim ve terminaller bracketed paste (yapıştırılan metni terminalin özel işaretlerle sarması) ile bunu çözer: vim yapıştırılan bloğu yazılmış tuşlar gibi değil, tek parça metin olarak alır ve aynı yedi satır bozulmadan gelir. Bu desteği olmayan bir terminal ya da araya giren bir araç varsa, yapıştırmadan önce :set paste, sonra :set nopaste yaz; aynı yapıştırma bu ayarla da düzgün çıktı.

nano: Kısayollar Ekranın Altında

vim'e alışmak istemiyorsan Ubuntu'da varsayılan editör nano. Kısayolları ekranın altında yazar; ^ Ctrl, M- Alt demek:

  GNU nano 7.2                /etc/sudoers.d/bookstore-deploy.tmp
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart bookstore-api, /usr/bin/systemctl >
...
^G Help        ^O Write Out   ^W Where Is    ^K Cut         ^T Execute     ^C Location
^X Exit        ^R Read File   ^\ Replace     ^U Paste       ^J Justify     ^/ Go To Line

Günlük kullanımda yetenler: Ctrl-O kaydet (dosya adını onaylatır, Enter), Ctrl-X çık (kaydedilmemiş değişiklik varsa sorar), Ctrl-W ara, Ctrl-\ bul ve değiştir, Ctrl-K satırı kes, Ctrl-U yapıştır, Alt-U geri al. nano -l satır numaralarını gösterir; config hatası "line 9" dediğinde işine yarar. Satırın sonundaki > satırın ekrana sığmadığını gösteriyor; nano uzun satırı varsayılan olarak bölmez, kaydırır. Ubuntu 26.04'te nano 8.7.1 geliyor; yukarıdaki kısayollar aynı.

Hangi Editör Açılır? EDITOR, VISUAL ve sudoedit

Tahminin cevabı. Dört komutu aynı oturumda çalıştırdım ve açılan ekrana baktım:

$ crontab -e
"/tmp/crontab.jw2NB9/crontab" 23L, 889B                                 1,1           All
$ sudo systemctl edit nginx
  GNU nano 7.2                         /etc/systemd/system/nginx.service.d/.#override.conf5118365f0d75566b
$ sudo visudo -f /etc/sudoers.d/bookstore-deploy
  GNU nano 7.2                /etc/sudoers.d/bookstore-deploy.tmp
$ sudoedit /etc/nginx/sites-available/bookstore
"/var/tmp/bookstore.PsK4wZ7q" 24L, 860B                                 1,1           Top

Alt satırında dosya adı, satır ve byte sayısı olan ekran vim'in, en üstte nano'nun adı ve sürümü yazan ekran nano'nun. crontab -e ve sudoedit vim'i açtı; sudo ile başlayan iki komut nano'yu. Sebep sudo'nun environment'ı temizlemesi: Ubuntu'nun sudoers dosyasındaki Defaults env_reset, root olarak çalışacak komuta senin EDITOR'ünü taşımıyor. systemctl edit önce SYSTEMD_EDITOR, sonra EDITOR ve VISUAL'a bakıyor; hiçbirini bulamayınca editor komutunu çalıştırıyor. Ubuntu'da o da bir alternatives link'i ve nano'yu (öncelik 40) vim'in (30) önüne koyuyor. visudo da aynı yoldan nano'ya düşüyor: Ubuntu'nun sudo paketi varsayılan editör olarak /usr/bin/editor ile derlenmiş.

sudoedit ise farklı çalışıyor ve bu yüzden sunucuda dosya düzenlemenin doğru yolu o. Editör açıkken process'lere baktım:

$ ps -o user,pid,args -C vim,sudo,sudoedit,nano
USER         PID COMMAND
root        1110 sudoedit /etc/nginx/sites-available/bookstore
root        1111 sudoedit /etc/nginx/sites-available/bookstore
ada         1112 vim /var/tmp/bookstore.PsK4wZ7q

sudo dosyanın geçici bir kopyasını senin adına oluşturuyor, editörü root olarak değil ada olarak, kendi environment'ınla çalıştırıyor ve sen kaydedip çıkınca kopyayı yerine yazıyor. Editörü SUDO_EDITOR, VISUAL, EDITOR sırasıyla seçiyor; senin .vimrc'n de geçerli. sudo vim ile farkı şu:

$ sudo vim -es -c "!id" -c "q" /etc/hosts
uid=0(root) gid=0(root) groups=0(root)

sudo vim'in içinden çalıştırılan her shell komutu, her plugin ve her :w other-file root yetkisiyle çalışır. sudoers'ta birine yalnızca tek bir dosyayı düzenleme izni vermek istiyorsan bu, ona tam root vermek demek; sudoedit'te editör root değildir. sudoedit'in iki kısıtı Nginx'te hemen karşına çıkar:

$ sudoedit /etc/nginx/sites-enabled/bookstore
sudoedit: /etc/nginx/sites-enabled/bookstore: editing symbolic links is not permitted
$ sudoedit /tmp/x.conf
sudoedit: /tmp/x.conf: editing files in a writable directory is not permitted

sites-enabled'daki dosya bir symlink; asıl dosyayı, sites-available'dakini düzenle. Kullanıcının yazabildiği bir klasördeki dosyayı da düzenlemiyor, çünkü orada dosyanın yerine bir symlink koyup root'a başka bir dosyayı yazdırmak mümkün olurdu. Ubuntu 26.04'teki sudo-rs da sudoedit'i destekliyor ve aynı iki durumu reddediyor, yalnızca mesajlar farklı (sudo: error opening /tmp/x.conf: cannot open a file in a path writable by the user).

sudo ile çalışan komutlarda kendi editörünü istiyorsan değişkeni komuta açıkça ver ya da sistemin varsayılanını değiştir:

$ sudo --preserve-env=EDITOR systemctl edit nginx
"/etc/systemd/system/nginx.service.d/.#override.conf9fa110737e04ecc9" [noeol] 40L, 1435B          4,0-1         Top
$ sudo EDITOR=vim visudo -f /etc/sudoers.d/bookstore-deploy
"/etc/sudoers.d/bookstore-deploy.tmp" 1L, 157B                                                   1,1           All
# bütün kullanıcılar için varsayılanı değiştirmek: sudo update-alternatives --config editor

crontab ise VISUAL'ı EDITOR'den önce okuyor. İkisi farklıysa sürprizi önlemek için ikisini de aynı değere ayarla.

Config'i Güvenle Değiştirmek: Yedek, diff, Test, Reload

Sekizinci yazıda 200 isteğin Kestrel tarafında 200 TIME_WAIT bağlantı bıraktığını görmüştük: Nginx upstream'e varsayılan olarak her istekte yeni bağlantı açıyor. Düzeltmesi Nginx config'inde bir upstream bloğu ve keepalive. Sıra her config değişikliğinde aynı: yedek al, düzenle, farkı oku, test et, sonra reload et.

$ sudo cp -a /etc/nginx/sites-available/bookstore /etc/nginx/sites-available/bookstore.bak
$ sudoedit /etc/nginx/sites-available/bookstore

vim'de yaptığım değişiklik şu tuşlardan ibaret:

/proxy_pass
:s/127.0.0.1:5000/bookstore_api/
o        proxy_http_version 1.1;
o        proxy_set_header Connection "";
gg
/^server
O
upstream bookstore_api {
    server 127.0.0.1:5000;
    keepalive 16
}
:wq

(Her o/O satırından ve bloğun sonundan sonra Esc.) Kaydettikten sonra neyi değiştirdiğine bak. diff -u eski ve yeni dosyayı birleşik formatta, Git'te alıştığın gibi gösterir; - ile başlayanlar çıkan, + ile başlayanlar eklenen satırlar:

$ diff -u bookstore.bak bookstore
--- bookstore.bak	2026-11-15 07:04:01.416420000 +0000
+++ bookstore	2026-11-15 07:08:59.246163013 +0000
@@ -3,6 +3,11 @@
                      '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                      '$request_time $upstream_response_time $request_id';

+upstream bookstore_api {
+    server 127.0.0.1:5000;
+    keepalive 16
+}
+
 server {
     listen 80 default_server;
     server_name _;
@@ -15,7 +20,9 @@
     error_log /var/log/nginx/bookstore.error.log;

     location / {
-        proxy_pass http://127.0.0.1:5000;
+        proxy_pass http://bookstore_api;
+        proxy_http_version 1.1;
+        proxy_set_header Connection "";
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
$ sudo nginx -t
2026/11/15 07:09:00 [emerg] 2088#2088: unexpected "}" in /etc/nginx/sites-enabled/bookstore:9
nginx: configuration file /etc/nginx/nginx.conf test failed

keepalive 16'nın sonundaki noktalı virgülü unuttum ve Nginx hatayı bir sonraki satırda, }'yi görünce fark etti; hata satırı her zaman hatanın kendisi değil, parser'ın takıldığı yer. proxy_http_version 1.1 ve boş Connection header'ı keepalive'ın çalışması için gerekli: Nginx upstream'e varsayılan olarak HTTP/1.0 ve Connection: close ile gidiyor. Peki nginx -t'yi atlasaydım?

$ sudo systemctl reload nginx
Job for nginx.service failed.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/health
200
$ sudo systemctl restart nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
$ curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1/health
curl: (7) Failed to connect to 127.0.0.1 port 80 after 0 ms: Couldn't connect to server
000

Reload başarısız oldu ama site çalışmaya devam etti: Nginx yeni config'i yükleyemeyince eski worker'larla devam ediyor. Restart ise önce durdurup sonra başlattığı için hatalı config'le site kapandı. Bu yüzden config değişikliğinde restart değil reload kullan ve reload'u testin arkasına bağla. Satırı vim'de :8, A;, Esc, :wq ile düzelttim:

$ sudo nginx -t && sudo systemctl start nginx
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ for i in $(seq 1 200); do curl -s -o /dev/null http://127.0.0.1/health; done
$ ss -tan state time-wait "( sport = :5000 or dport = :5000 )" | tail -n +2 | wc -l
0
$ ss -tan state established "( dport = :5000 )" | tail -n +2 | wc -l
10

Kestrel tarafında TIME_WAIT kalmadı; Nginx worker'ları açık tuttukları birkaç bağlantıyı yeniden kullanıyor. Repodaki deploy/linux/nginx/bookstore.conf bu yazıyla birlikte bu hâle geldi.

Yedeği nereye aldığına dikkat et. sites-available'daki .bak dosyası zararsız, çünkü Nginx yalnızca sites-enabled'ı okuyor. Aynı yedeği sites-enabled'a alırsan Nginx onu da yükler ve test aynı şeyin iki kez tanımlanmasına takılır: denediğimde ilk hata duplicate "log_format" name "bookstore" in /etc/nginx/sites-enabled/bookstore.bak:4 oldu. sshd_config.d yalnızca .conf ile biten, /etc/sudoers.d ise adında nokta olmayan dosyaları okur; her klasörün kuralını bilmiyorsan yedeği klasörün dışında tut.

sshd_config ve Kendini Kilitlememek

Nginx'te hatalı config en kötü siteyi kapatır; sshd_config'te sunucuya erişimini. On birinci yazıdaki kural burada da geçerli: değişiklikten önce ikinci bir SSH (uzak bağlantı protokolü) oturumu aç ve testi o oturum açıkken yap. sshd -t dosyayı reload etmeden okur:

$ sudo sshd -t
/etc/ssh/sshd_config.d/20-typo.conf: line 1: Bad configuration option: PasswordAuthentcation
/etc/ssh/sshd_config.d/20-typo.conf: terminating, 1 bad configuration options

Bu hatayla yapılan bir restart'tan sonra sshd başlamaz ve yeni bağlantı kurulamaz; on birinci yazıda gördüğümüz gibi açık oturumlar ise etkilenmez. Bu yüzden açık oturumu, yeni bir oturumla girebildiğini görmeden kapatma.

Windows'ta hazırlanıp sunucuya kopyalanan dosyalar ayrı bir risk: satır sonları CRLF (\r\n) olabilir. Hangi aracın buna dayandığını denedim. Nginx, sshd ve systemd unit'leri satır sonundaki \r'yi sorunsuz yuttu; visudo -c dosyayı reddetti. En sinsi olanı cron:

$ file report.cron
report.cron: ASCII text, with CRLF line terminators
$ crontab report.cron
$ ls -b /tmp | grep report
bookstore-report.log\r
$ sed -i "s/\r$//" report.cron && file report.cron
report.cron: ASCII text

İş hata vermeden çalıştı, ama log'u adı görünmez bir \r ile biten bir dosyaya yazdı; ls çıktısında doğru dosya adını görürsün ve log neden büyümüyor diye ararsın. vim böyle bir dosyayı açınca alt satırda [dos] yazar; :set ff=unix ve :w satır sonlarını düzeltir. Kalıcı çözüm kaynağın kendisi: repoya bir .gitattributes ekledik, böylece Windows'ta checkout edilse bile deploy/ altındaki dosyalar LF (yalnızca \n, Linux'un satır sonu) ile gelir:

# .gitattributes
# Files that go to Linux servers always use LF line endings, even on a Windows checkout
deploy/** text eol=lf
*.sh text eol=lf

Bir de .swp uyarısı. Aynı dosyayı ikinci bir oturumda vim ile açınca şunu gördüm:

E325: ATTENTION
Found a swap file by the name "~/.notes.txt.swp"
          owned by: ada   dated: Sun Nov 15 07:11:28 2026
         file name: ~ada/notes.txt
          modified: no
         user name: ada   host name: lab
        process ID: 2649 (STILL RUNNING)
...
Swap file "~/.notes.txt.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:

vim düzenlenen her dosya için bir swap dosyası tutar. STILL RUNNING yazıyorsa dosya başka bir oturumda açık: Q ile çık ve kimin açtığını bul. (E)dit anyway ile devam edersen iki editör aynı dosyayı tutar ve son kaydeden diğerinin değişikliğini siler. Process çalışmıyorsa önceki oturum kopmuştur; R ile kaydedilmemiş değişiklikleri geri al, sonra swap dosyasını sil. Bir uyarı: sudoedit her seferinde /var/tmp'te farklı adlı bir kopya açtığı için iki kişi aynı config'i sudoedit ile düzenlerken bu uyarı hiç çıkmaz. Ekipte bir sunucuya aynı anda giriliyorsa bu bir sonraki bölümdeki Git kaydını daha da değerli yapar.

/etc'yi Git ile İzlemek: etckeeper

Yedek dosyaları zamanla birikir ve hangisinin neden alındığını kimse hatırlamaz. etckeeper /etc'yi yerel bir Git repository'si yapar:

$ sudo apt install -y etckeeper
...
Setting up etckeeper (1.18.20-2) ...
Created symlink /etc/systemd/system/multi-user.target.wants/etckeeper.timer → /usr/lib/systemd/system/etckeeper.timer.
...
Initialized empty Git repository in /etc/.git/
[master (root-commit) 0a78784] Initial commit
 Author: ada <ada@lab>
 629 files changed, 16697 insertions(+)
...
$ sudo rm /etc/nginx/sites-available/bookstore.bak
$ sudo git -C /etc status --short
 D nginx/sites-available/bookstore.bak
$ sudo etckeeper commit "nginx: remove bookstore backup after keepalive change"
[master b82d5ea] nginx: remove bookstore backup after keepalive change
 Author: ada <ada@lab>
 2 files changed, 25 deletions(-)
$ sudo apt-get install -y -q ufw
...
[master 8587b2a] committing changes in /etc made by "apt-get install -y -q ufw"
$ sudo git -C /etc log --oneline
8587b2a committing changes in /etc made by "apt-get install -y -q ufw"
b82d5ea nginx: remove bookstore backup after keepalive change
0a78784 Initial commit

Artık git -C /etc diff elle yapılan ve henüz kaydedilmemiş değişiklikleri, git log kimin neyi ne zaman değiştirdiğini gösteriyor. etckeeper apt'ye bir hook ekliyor: her paket kurulumundan önce bekleyen değişiklikleri, sonra paketin yaptığı değişiklikleri ayrı commit'ler. Ayrıca etckeeper.timer açılıştan 15 dakika sonra ve sonra günde bir kez kaydedilmemiş değişiklikleri commit'ler. Commit'teki ada, sudo'yu çağıran kullanıcı; root ile ortak çalışılan sunucularda bile değişikliğin sahibi görünür.

Dikkat: bu repository'de /etc/shadow ve /etc/bookstore/secrets.env de var. /etc/.git yalnızca root'un okuyabildiği bir klasör (700) ve öyle kalmalı; bu repository'yi asla GitHub gibi bir remote'a push etme. etckeeper değişiklik geçmişi içindir, config'in kaynağı değil. Kaynak, bu serinin baştan beri yaptığı gibi uygulamanın repo'sundaki deploy/linux/ klasörü.

Üretimde Dikkat

Production'da editör açmadan önce cevaplaman gereken soru: bu değişiklik repoya da girecek mi? Sunucuda elle yapılıp repoya girmeyen bir değişiklik, bir sonraki deploy'da ya da on üçüncü yazıda anlattığımız yeni sunucuya taşımada kaybolur. Acil durumda sunucuda düzelt, ama aynı gün repoya da yaz.

Test komutlarını ezberle: nginx -t, sshd -t, visudo -cf (sudoers.d dosyaları için) ve systemd-analyze verify (unit dosyaları için). Test komutu olmayan bir config değiştiriyorsan önce kopyasında servisi elle başlatmayı dene.

Reload'u sonuçla doğrula. systemctl reload sıfır dönse bile asıl kanıt curl ile sağlık kontrolü ve log'daki ilk satırlar (altıncı yazı).

Sık Düşülen Tuzaklar

sudo vim ile config düzenlemek. Editör root olarak çalışır, senin ayarların yerine root'unkiler geçerli olur ve dosyayı bozan bir yazım hatası doğrudan yerine yazılır. sudoedit kullan.

Testsiz restart. Hatalı config'le reload siteyi korur, restart kapatır. nginx -t && systemctl reload nginx tek satırda kalsın.

Yedeği config klasörünün içine almak. sites-enabled/bookstore.bak Nginx'in yükleyeceği ikinci bir site olur.

CRLF'li dosyayı fark etmemek. Hata vermeyen araçlar en tehlikelileri; file ve vim'in [dos] işareti ilk kontrol.

.swp uyarısında (E)dit anyway'e basmak. Önce dosyayı kimin açık tuttuğunu bul.

Küçük Bir Deneme

★☆☆ vimtutor'u bitir, sonra bir test sunucusunda /etc/nginx/sites-available/default'un bir kopyasını vim ile aç ve :%s/80/8080/gc ile her eşleşmeyi tek tek onaylayarak değiştir. u ile hepsini geri al.

★★☆ sudo visudo'nun vim'i açması için iki farklı yol bul (biri yalnızca senin için, biri bütün sistem için) ve her birinin hangi dosyayı değiştirdiğini etckeeper ile gör.

★★★ Nginx'e bilerek hatalı bir config yaz, sonra systemctl reload ve systemctl restart'ın davranışını journalctl -u nginx çıktısıyla karşılaştır. Reload sırasında açık bir isteğin (dördüncü yazıdaki yavaş rapor endpoint'i) ne olduğuna da bak.

Config dosyasını değiştirmeyi gördük; bir sonraki yazıda dosyaların kendisiyle çalışıyoruz: find ve xargs ile eski yedekleri bulup silmek, tar ve zstd ile release paketi hazırlamak, rsync ile sunucuya taşımak ve checksum ile doğrulamak.