VPS uzerinde dsh servisi nasil calistirilir

dsh aracını bir terminalde değil, VPS üzerinde başıboş (headless) çalıştırma

dsh aracını bir VPS üzerinde başıboş çalıştırmak için tek bir systemd birim dosyası ve bu dosyaya sahip olacak özel bir kullanıcı yeterlidir. dsh, DeepSeek'in Ağustos 2026'da geliştirici önizlemesi olarak MIT lisansı altında yayımlanan aracı çalışma zamanı DeepSeek Harness için komut satırı başlatıcısıdır. Harness, modelin kendisinden ziyade modelin etrafındaki programdır; dolayısıyla systemd altına aldığınız şey DeepSeek çıkarımı değil, döngü, araçlar ve izinlerdir. Hızlı başlangıç kılavuzu size npx @deepseek-ai/dsh web komutunu girmenizi söyler; bu doğrudur ancak SSH (secure shell) oturumunuzu kapattığınız anda süreç sonlanır.

Bir birim dosyası aynı anda dört sorunu çözer. Servis, yeniden başlatma sonrasında tekrar ayağa kalkar. Çıktısı, gözünüzün önünden akıp gitmek yerine journal içerisine kaydedilir. root olmayan bir hesapla çalışır. Ayrıca çalıştırılan sürüm, sizin seçtiğiniz sürümdür; bu durum burada normalden daha önemlidir çünkü geliştirici ekip büyük harflerle şunu belirtmektedir:

DeepSeek Harness şu anda geliştirici önizlemesi aşamasındadır ve hızla güncellenmektedir. UYUMLULUĞU BOZAN DEĞİŞİKLİKLER OLACAKTIR.

Bu kılavuz, dsh aracının halihazırda manuel olarak çalıştığını varsayar. Eğer çalışmıyorsa, DeepSeek Harness'ın bir VPS üzerine kurulması ile başlayın ve npx @deepseek-ai/dsh web bir sayfa sunduğunda geri dönün.

Önce Node kurulmalıdır, çünkü npm sizi uyarmaz

node -v

Ubuntu 24.04'ün kendi paket deposunda bulunan Node sürümü 18'dir (Ağustos 2026 itibarıyla 18.19.1); bu sürüm, bu yıl yayımlanan bir paket için oldukça eskidir. @deepseek-ai/dsh herhangi bir engines alanı yayımlamadığı için, Node sürümünüz çok eski olduğunda npm herhangi bir EBADENGINE uyarısı vermez. Hata, çalışma zamanında söz dizimi hatası veya eksik bir yerleşik fonksiyon olarak ortaya çıkar; bu da hatayı tespit etmek için çok daha kötü bir durumdur. NodeSource üzerinden güncel bir uzun süreli destek (LTS) sürümü kurun:

curl -fsSL https://deb.nodesource.com/setup_22.x -o /tmp/nodesource_setup.sh
less /tmp/nodesource_setup.sh
sudo -E bash /tmp/nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v komutu artık güncel bir v22 sürümü çıktısı vermelidir. less satırı, uzak bir betiği doğrudan bash komutuna yönlendirmenin, okumadığınız bir kodu çalıştırmanız anlamına gelmesi nedeniyle eklenmiştir.

Bir unit dosyası yazmadan önce çalıştığını doğrulayın

npx @deepseek-ai/dsh@0.1.0-rc.7 web

Bu süreci çalışır durumda bırakın. İkinci bir SSH oturumundan şunları yapın:

curl -fsS http://127.0.0.1:3080/ -o /dev/null && echo up

up ifadesi, web profilinin varsayılan olarak bağlandığı yer olan loopback üzerinde dinleme yaptığını gösterir. curl: (7) Failed to connect to 127.0.0.1 port 3080: Connection refused ifadesi ise dinleme yapmadığını belirtir; bu durumda ilk terminal size nedenini bildirecektir. İlerlemeden önce manuel çalıştırmayı Ctrl+C ile durdurun: başka bir sürecin halihazırda kullandığı bir portu bağlamaya çalışan bir unit, Error: listen EADDRINUSE: address already in use 127.0.0.1:3080 hatası ile başarısız olur.

0.1.0-rc.7, 18 Ağustos 2026 tarihinde yayınlanan sürümdür. npm view @deepseek-ai/dsh version komutu ile güncel sürümü kontrol edin ve çalıştırmaya karar verdiğiniz sürümü sabitleyin.

Sabitlediğiniz sürümü global olarak yükleyin

npx, unit dosyası içerisinde kullanmak için yanlış bir araçtır. Süreç başladığında paket sürümünü çözümler; bu nedenle üç ay sonra yapılacak bir yeniden başlatma, sizin tarafınızda hiçbir değişiklik olmamasına rağmen önizleme aşamasındaki bir aracın farklı bir derlemesini çalıştırabilir. Ayrıca önyükleme sırasında npm kayıt defterinin erişilebilir olmasını gerektirir; bu da kayıt defterinin yavaş olduğu bir günde çalışan bir makinenin başarısız bir üniteye dönüşmesine neden olur. Yüklemeyi bir kez, not ettiğiniz bir sürümle gerçekleştirin:

sudo npm install -g @deepseek-ai/dsh@0.1.0-rc.7
command -v dsh
npm ls -g --depth=0 @deepseek-ai/dsh

command -v dsh, npm NodeSource'tan geldiğinde /usr/bin/dsh, Ubuntu'nun kendi paketinden geldiğinde ise /usr/local/bin/dsh çıktısını verir. Unit dosyası içerisinde, komutun gerçekten yazdırdığı yolu kullanın. npm ls -g, tam sürüm numarasını yazdırır; davranışlar değiştiğinde ve ne yüklediğinizi hatırlamadığınızda altı hafta sonra ihtiyacınız olan cevap budur. Yükleme başarısız olursa, command -v dsh sonrasında hiçbir çıktı vermezse veya aldığınız sürüm istediğiniz sürüm değilse, unit dosyasını yazmadan önce olağan dsh yükleme ve sürüm hataları adımlarını uygulayın.

Servisin sahibi olan ve başka hiçbir yetkisi bulunmayan bir kullanıcı

Aracı, shell komutlarını çalıştırır. İşi budur. Aracı root olarak çalıştırmak, her araç çağrısını bir root çağrısı haline getirir; bu nedenle araca, giriş shell'i olmayan özel bir hesap tanımlayın.

sudo useradd --system --create-home --home-dir /var/lib/dsh --shell /usr/sbin/nologin dsh
sudo install -d -o dsh -g dsh -m 750 /var/lib/dsh/harness /var/lib/dsh/workspace
id dsh

/var/lib/dsh/harness, dsh'ın profilleri tuttuğu dizin olan DSH_HOME haline gelir. Profil, kendi yama katmanınızın üzerinde bulunduğu, isimlendirilmiş bir eklenti paketleri yığınıdır ve web ile headless profilleri, ilk kez başlattığınızda gönderilen şablonlardan kendilerini oluşturur. Daha sonra bu yığına eklediğiniz her şey, aracın kendi dosya ve shell erişimiyle bu kullanıcı olarak çalışır; bu nedenle bir eklentiyi yüklemeden önce incelemek, hesabı oluşturmakla aynı işin parçasıdır. İlk başlatma dosyaları yazar ve paketleri getirebilir, bu yüzden süreci izleyebileceğiniz bir ortamda manuel olarak gerçekleştirin.

sudo -u dsh env HOME=/var/lib/dsh DSH_HOME=/var/lib/dsh/harness /usr/bin/dsh --profile web

sudo'in bu konuda ne yaptığına güvenmek yerine HOME değerini açıkça ayarlayın; çünkü sudo'nın giriş yapılmayan bir komut için HOME dosyasını yeniden yazıp yazmayacağı, /etc/sudoers içindeki set_home ayarına bağlıdır. Yanlış yapılandırırsanız, ilk çalıştırma önbellek dizinlerini dsh tarafından sahiplenilen sizin ev dizininize bırakır ve servis daha sonra kendi durumunu bulamaz. curl kontrolü up döndürdüğünde Ctrl+C ile işlemi durdurun.

Unit dosyası

/etc/systemd/system/dsh.service yazın:

[Unit]
Description=DeepSeek Harness (dsh) web profile
Documentation=https://github.com/deepseek-ai/deepseek-harness
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=exec
User=dsh
Group=dsh
WorkingDirectory=/var/lib/dsh/workspace
Environment=HOME=/var/lib/dsh
Environment=DSH_HOME=/var/lib/dsh/harness
ExecStart=/usr/bin/dsh --profile web
Restart=on-failure
RestartSec=5s
TimeoutStopSec=30s
SyslogIdentifier=dsh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

ExecStart=, command -v dsh üzerinden aldığınız mutlak yolu kullanır. systemd, yalın bir komut adı için sabit bir yol listesinde arama yapar; ancak bu liste kabuğunuzun PATH değişkeni ile aynı değildir, bu nedenle mutlak yol kullanmak belirsizliği ortadan kaldırır.

WorkingDirectory=, göreli yolların çözümlendiği yerdir ve argümansız olarak ls çalıştıran bir araç çağrısının başladığı dizindir. Burayı, aracıya verdiğiniz çalışma alanına yönlendirin. Dizin eksikse veya servis kullanıcısı dizine erişemiyorsa, servis dsh çalışmadan önce status=200/CHDIR hatasıyla başarısız olur.

ProtectHome=true, /home ve /root dizinlerini süreçten gizler. Servisin eriştiği her şey /var/lib/dsh altında bulunduğu için bu işlem güvenlidir. Çalışma alanını /home altında bir yola yönlendirirseniz, aracı dizinin mevcut olmadığını bildirecektir; bu satırı hatırlayana kadar kafa karıştırıcı olabilir. ProtectSystem=full; /usr, /boot ve /etc dizinlerini salt okunur hale getirir; servis bu dizinlere hiçbir zaman yazma ihtiyacı duymaz.

Daha ileri gitmek cazip gelse de genellikle yanlıştır. ProtectSystem=strict, çekirdek sözde dosya sistemleri (pseudo-filesystem) haricindeki tüm dosya sistemini salt okunur hale getirir; bu nedenle dosya yazmaya çalışan ilk araç çağrısı EROFS: read-only file system hatasıyla başarısız olur. Bu seviyede bir kısıtlama istiyorsanız, aynı düzenleme içinde ReadWritePaths=/var/lib/dsh satırını ekleyin.

Burada hangi Type= kullanılmalı

Type=exec, çünkü dsh ön planda kalır ve asla fork işlemi gerçekleştirmez. Bunun varsayılan ayara göre sağladığı avantaj, gerçek bir hata mesajı alabilmenizdir. Type=simple ile systemd, ikili dosyanın var olup olmadığını bile bilmeden, fork işlemi gerçekleştiği anda başlatma işlemini başarılı kabul eder; bu nedenle systemctl start dsh temiz bir şekilde döner ve hata yalnızca günlük kayıtlarında (journal) görünür. Type=exec ile systemd, execve() işleminin başarılı olmasını bekler; böylece ExecStart= içindeki bir yazım hatası, komutu girdiğiniz anda başarısız olur ve hatayı doğrudan görürsünüz.

Diğer iki yanlış cevapta da sistem yanıt vermeyi durdurur (hang). Type=forking, systemd'ye bir üst sürecin (parent process) sonlanmasını beklemesini söyler; dsh asla sonlanmadığı için başlatma işlemi TimeoutStartSec süresi dolana kadar (varsayılan olarak 90 saniye) bekler ve ardından Job for dsh.service failed because a timeout was exceeded. hatasını raporlar. Type=notify, sd_notify üzerinden bir READY=1 mesajı bekler; bu mesajı asla göndermeyen bir Node süreci de aynı şekilde kilitlenir. systemd servis türlerinin tam karşılaştırması, notify yapılandırmasının ne zaman zahmete değer olduğu da dahil olmak üzere geri kalan detayları kapsar.

Hata durumunda yeniden başlatma kuralları

Restart=on-failure, sıfır olmayan bir çıkış kodu veya kritik bir sinyal alındığında yeniden başlatma yapar, temiz bir çıkıştan sonra ise birimi olduğu gibi bırakır. Önizleme sürümleri için istenen davranış budur. Eğer dsh, beğenmediği bir yapılandırma dosyasını okuduğu için 0 koduyla çıkış yaparsa, birim durur ve durmuş halde kalır; systemctl status dsh ise durumu inactive (dead) ile gösterir ve buradan inceleyebilirsiniz. Restart=always ise aynı durumu, uzaktan bakıldığında sağlıklı görünen bir yeniden başlatma döngüsüne dönüştürür.

Hız sınırlaması (rate limit), genellikle göz ardı edilen kısımdır. systemd'nin varsayılan ayarı on saniye içinde beş başlatmadır; RestartSec=5s ile on saniyelik pencerede beş başlatmaya asla ulaşamazsınız. Bu nedenle, başlangıçta çöken bir birim sonsuza kadar yeniden başlar ve durumdan yalnızca journal haberdar olur. StartLimitIntervalSec=300 ile birlikte kullanılan StartLimitBurst=5, beş dakika içinde beş başarısızlığın yeterli olduğu anlamına gelir: systemd pes eder ve birimi failed durumuna getirerek Start request repeated too quickly. kaydını düşer. Sorunun nedenini giderdikten sonra bu durumu sudo systemctl reset-failed dsh ile temizleyin. Her iki ayar da [Unit] altında yer almalıdır, [Service] altında değil; systemd yanlış bölümdeki ayarları sessizce görmezden gelir.

Başlatın ve kontrol edin

sudo systemctl daemon-reload
sudo systemctl enable --now dsh
systemctl status dsh

enable --now iki işlevi yerine getirir. enable, servisin yeniden başlatma sonrasında tekrar ayağa kalkmasını sağlar; --now ise servisi mevcut oturumda başlatır. Sadece systemctl start komutunu kullanmak, bir sonraki yeniden başlatmada ayarların kaybolmasına neden olur; çekirdek güncellemeleri ise yeniden başlatma gerektirir.

systemctl status dsh komutu Active: active (running), bir Main PID ve bir Memory: satırı göstermelidir. Ardından servisin hangi adresi dinlediğini doğrulayın:

sudo ss -lntp | grep 3080

127.0.0.1:3080 çıktısını görmelisiniz. Eğer 0.0.0.0:3080 görüyorsanız, bir yapılandırma bind adresini değiştirmiştir ve ajanınız genel internete açıktır. Bu çıktıdaki süreç adı dsh değil, node olarak görünür; çünkü dsh ikili dosyası bir Node betiğidir ve pgrep -x dsh hiçbir şey bulamaz. Bunun yerine systemctl show -p MainPID dsh kullanın.

Ardından sistemi bir kez yeniden başlatın. Yeniden başlatma sonrasında çalışmayan bir servis, henüz tam anlamıyla bir servis sayılmaz.

sudo reboot

Sunucuya tekrar bağlanın ve systemctl is-active dsh komutunu çalıştırın. Bu komut active çıktısını verecektir.

journalctl ile günlük kayıtlarını okuma

dsh tarafından stdout ve stderr'a yazılan her şey, birim adı altında journal içinde saklanır.

journalctl -u dsh -f
journalctl -u dsh -n 200 --no-pager
journalctl -u dsh --since "10 min ago" -p err

-f yeni satırları takip eder, -n son N satırı gösterir, -p err ise önceliğe göre filtreleme yapar. Birim içindeki SyslogIdentifier=dsh, bu satırların neden node yerine dsh olarak etiketlendiğini açıklar; bu durum, birim tarafından filtrelenmemiş journal çıktısını ilk kez okuduğunuzda önem kazanır.

İhtiyaç duymadan önce journal'ın yeniden başlatmalardan sonra kalıcı olup olmadığını kontrol edin:

journalctl -u dsh -b -1

Eğer bu komut Specifying boot ID or boot offset has no effect, no persistent journal was found çıktısını verirse, journal /run içinde yaşar ve her yeniden başlatmada silinir. Dizini oluşturun ve servisi yeniden başlatın:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

Arayüze genel bir port üzerinden değil, SSH tüneli üzerinden erişin

dsh, web arayüzünü (UI) 127.0.0.1:3080 üzerinde sunar ve başka hiçbir yerde sunmayı reddeder. --host 0.0.0.0 üzerinden erişmeyi denediğinizde şu hata ile durur:

error: --host 0.0.0.0 is intentionally not supported yet for safety: it would expose remote code execution to the network; use 127.0.0.1 instead

Bu, aşılması gereken bir kısıtlama değildir. Web API (uygulama programlama arayüzü) ajanı yönetir ve ajan shell komutları çalıştırır; dolayısıyla erişilebilir bir port, onu bulan herkes için VPS'niz üzerinde bir shell demektir. Geliştiriciler, uzak kimlik doğrulama özelliğinin henüz inşa edilmemiş olmasını, bağlantının loopback ile sabitlenmesinin nedeni olarak belirtmektedir. Başlangıç çıktısındaki 127.0.0.1:3080 satırının gerçekte ne anlama geldiği konusunu, ayarı değiştirmeye çalışmadan önce okumanızda fayda vardır. Bunun yerine portu kendi makinenizden yönlendirin:

ssh -N -L 3080:127.0.0.1:3080 you@203.0.113.10

-L 3080:127.0.0.1:3080, dizüstü bilgisayarınızda 3080 numaralı portu açar ve oraya gelen her şeyi VPS üzerinde çözümlendiği şekliyle 127.0.0.1:3080 adresine gönderir. -N, uzak komut çalıştırma anlamına gelir; böylece oturum yalnızca tüneli açık tutar. Komutu çalışır durumda bırakın ve tarayıcınızda http://127.0.0.1:3080/ adresini açın. DeepSeek API anahtarını Ayarlar (Settings) altındaki Modeller (Models) kısmında buraya girersiniz ve çalışma alanı dizinini burada seçersiniz. Çalışma alanını, servis kullanıcısının sahibi olduğu /var/lib/dsh/workspace dizinine yönlendirin; aksi takdirde ajanın dosya araçları EACCES: permission denied hatasıyla başarısız olur.

Eğer 3080 numaralı port dizüstü bilgisayarınızda meşgulse, ssh şu hatayı verir:

bind [127.0.0.1]:3080: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 3080

ssh -N -L 3081:127.0.0.1:3080 you@203.0.113.10 ile farklı bir yerel port seçin ve ardından http://127.0.0.1:3081/ adresine gidin. Kendi makinenizde ~/.ssh/config dosyasında yazım işlemini kaydedin:

Host dsh-vps
  HostName 203.0.113.10
  User you
  LocalForward 3080 127.0.0.1:3080

Bundan sonra, ssh -N dsh-vps komutun tamamıdır. Bu tünel artık ajanınıza açılan tek kapıdır, bu nedenle onu koruyan şey SSH daemon'dır: yalnızca anahtarlar kullanılmalı, parola kimlik doğrulaması kapatılmalı ve VPS'nizde SSH'ı sıkılaştırma ile ilgili geri kalan adımlar normalden daha büyük bir titizlikle uygulanmalıdır. Eğer VPS'niz arkasında bir veritabanı veya staging sunucusu bulunan küçük bir özel ağa dönüşürse, bu adresleri bir subnet router ile tailnet'inize tanıtmak, her servis için ayrı bir yönlendirme yapma zahmetinden sizi kurtarır; ancak dsh'ın loopback bağlantısı nedeniyle arayüzün kendisi yine de bir tünel üzerinden gelecektir.

Anahtar, unit dosyasının içinde yer almamalıdır. Environment= değerleri, kutu üzerindeki herhangi bir kullanıcının çalıştırabileceği systemctl show dsh -p Environment tarafından yazdırılır. Yüklediğiniz bir eklenti ortamda bir anahtara ihtiyaç duyuyorsa, bunu root tarafından sahip olunan ve 600 moduna sahip /etc/dsh.env dosyasına koyun ve EnvironmentFile=/etc/dsh.env ile referans verin. systemd bu dosyayı yürütme anında root olarak okur ve systemctl show içeriğini yazdırmaz. Her ayarın diskte hangi dosyaya kaydedildiği ve dsh'ı DeepSeek API yerine yerel bir Ollama uç noktasına yönlendirdiğinizde kutunuzdan nelerin çıktığı, dsh anahtarlarını, modellerini ve uç noktalarını yapılandırma konusunun içeriğidir.

Çalıştırma maliyeti

Çıkarım işlemleri VPS üzerinde değil, DeepSeek API tarafında gerçekleşir. Sunucunuz Node sürecini, sunduğu arayüzü ve ajanın çalıştırmaya karar verdiği her komutu karşılar. İlk ikisi sabit ve düşüktür. Üçüncüsü ise bu birim dosyasında herhangi bir sınıra tabi değildir.

Başkalarının verdiği rakamlara güvenmek yerine, kendi sunucunuzdaki taban değerleri ölçün:

systemctl show dsh -p MemoryCurrent
systemd-cgtop -1 --depth 2

MemoryCurrent bayt cinsindendir. Değeri, ajan boşta beklerken değil, çalışırken izleyin.

Araç çağrıları servisin alt süreçleridir; bu nedenle aynı kontrol grubuna dahil edilirler ve aynı sınırlara tabi tutulurlar. Çalışma alanı içerisinde npm install veya bir test paketi çalıştıran bir ajan, ana süreçten çok daha fazla bellek tüketebilir. 1 GB RAM'e sahip bir VPS üzerinde sorun burada başlar: çekirdek bir süreci seçer ve sonlandırır; journalctl -k | grep -i "out of memory" çıktısında, seçilen süreci belirten Out of memory: Killed process satırı görülür. Bu süreç genellikle soruna neden olan süreç değildir.

Çözüm, bilinçli olarak belirleyeceğiniz bir sınırdır. [Service] bölümündeki MemoryMax= ve CPUQuota= ayarları, hasarı birim içerisinde tutar; böylece kontrolden çıkan bir derleme işlemi tüm sunucuyu kilitlemek yerine sadece ilgili birimi sonlandırır. systemd ile bellek ve CPU sınırlama bölümü, sayısal değerleri ve hata davranışlarını açıklar. Disk kullanımı da DSH_HOME altındaki oturum geçmişi ve ajanın çalışma alanına yazdığı veriler nedeniyle artar; bu yüzden du -sh /var/lib/dsh değerini disk izleme araçlarınıza dahil edin.

Eğer etkileşimli, bağlanıp ayrılabileceğiniz bir ajan istiyorsanız, servis yapısı uygun değildir; kalıcı bir tmux oturumunda ajan çalıştırma yöntemi daha uygundur. dsh aracını, her zaman ayakta kalmasını ve bir tünel üzerinden erişilebilir olmasını istediğiniz durumlarda birim olarak çalıştırın.

Hata modları ve karşılaşacağınız dizgeler

status=203/EXEC. systemd dosyayı çalıştıramadı ve Failed to locate executable /usr/local/bin/dsh: No such file or directory günlüklerini oluşturdu. ExecStart= içindeki yol, command -v dsh çıktısı ile eşleşmiyor. Bu, Type=exec aracının gizlemek yerine systemctl start anında raporladığı hatadır.

status=217/USER. User= içindeki hesap mevcut değil. id dsh ile doğrulayın.

status=200/CHDIR. WorkingDirectory= eksik veya servis kullanıcısı bu dizine giremiyor. sudo -u dsh ls /var/lib/dsh/workspace komutu bunu doğrudan yeniden oluşturur.

Error: listen EADDRINUSE: address already in use 127.0.0.1:3080. Başka bir işlem portu zaten kullanıyor; bu genellikle başka bir terminalde açık bırakılan npx sürecidir. sudo ss -lntp | grep 3080 süreci tanımlar.

EACCES: permission denied ve ardından bir yol. /var/lib/dsh altındaki sahiplik yanlış; bu durum genellikle ilk çalıştırmanın root olarak veya yanlış HOME ile yapılmasından kaynaklanır. sudo chown -R dsh:dsh /var/lib/dsh bunu düzeltir.

Start request repeated too quickly. Birim, başlatma hızı sınırına ulaştı ve vazgeçti. Asıl hata, bu satırın üzerindeki satırlarda yer alır. Tekrar denemeden önce sudo systemctl reset-failed dsh komutunu çalıştırın.

Birim active (running) durumunda ancak tarayıcı hiçbir şey göstermiyor. VPS üzerinde kontrolü çalıştırın: Eğer curl -fsS http://127.0.0.1:3080/ -o /dev/null && echo up orada up çıktısını veriyorsa, servis sağlıklıdır ve sorun port yönlendirmesindedir.

Kasıtlı yükseltme

Sabitleme (pinning), yükseltmenin size dayatılan bir süreç değil, sizin kontrolünüzde olan bir işlem olduğu anlamına gelir. Sürüm notlarını mutlaka önceden okuyun; çünkü yukarı akış (upstream) geliştiricilerinin uyumluluğu bozan değişiklikler hakkındaki uyarıları, sabitleme işleminin temel nedenidir. Durum dizinini (state directory) yedekleyin ve ardından sürümü değiştirin:

sudo systemctl stop dsh
sudo tar czf /root/dsh-home-$(date +%F).tgz -C /var/lib/dsh harness
sudo npm install -g @deepseek-ai/dsh@0.1.0-rc.7
sudo systemctl start dsh
journalctl -u dsh -n 50 --no-pager

Geri alma işlemi, eski sürümle yapılan aynı npm install -g işlemidir; buna ek olarak, yalnızca yedeğini almışsanız çalışacak olan tarball dosyasının geri yüklenmesi gerekir. Önizleme aşamasındaki bir aracı çalışma zamanı (agent runtime), yükseltme sırasında yapılandırma biçiminin sizin bilginiz dışında yeniden yazıldığı yazılım türüdür.

FAQ

Neden SSH oturumumu kapattığımda dsh duruyor?

Çünkü npx @deepseek-ai/dsh web, oturumunuza ait bir ön plan sürecidir ve oturum sonlandığında süreç de sonlandırılır. Bir systemd birimi ise init sistemine aittir; bu nedenle bağlantıyı kestiğinizde çalışmaya devam eder ve yeniden başlatma sonrasında tekrar başlar. sudo systemctl enable --now dsh, size her ikisini de sağlayan adım çiftidir: yeniden başlatma için enable, bu önyükleme için --now.

dsh için Type=simple mı yoksa Type=exec mi kullanmalıyım?

Type=exec. dsh ön planda çalışır ve asla fork yapmaz, bu yüzden her ikisi de çalışır; ancak Type=exec, systemd'nin başlatmanın başarılı sayılması için execve() sürecinin başarıyla tamamlanmasını beklemesini sağlar. ExecStart= içindeki hatalı bir yol, systemctl start işleminin önünüzde status=203/EXEC ile başarısız olmasına neden olur. Type=simple ile aynı hata başarı döndürür ve günlük kayıtlarında gizli kalır. Type=forking ve Type=notify burada yanlıştır ve her ikisi de TimeoutStartSec süresi 90 saniye sonra dolana kadar askıda kalır.

dsh web arayüzünü dizüstü bilgisayarımdan nasıl açarım?

Portu SSH üzerinden yönlendirin: ssh -N -L 3080:127.0.0.1:3080 you@your-vps, ardından tarayıcınızda http://127.0.0.1:3080/ adresini açın. Servisi genel bir adrese bağlamaya çalışmayın. dsh, --host 0.0.0.0 isteğini error: --host 0.0.0.0 is intentionally not supported yet for safety: it would expose remote code execution to the network; use 127.0.0.1 instead ile reddeder; çünkü web API'si aracının shell komutları çalıştırmasına izin verebilir ve önünde uzak kimlik doğrulama mekanizması bulunmaz.

İzinleri basit tutmak için dsh'ı root olarak çalıştırabilir miyim?

Hayır. Harness, komut çalıştırmak ve dosya yazmak için tasarlanmıştır; dolayısıyla servisin sahip olduğu tüm yetkiler, aracın da yetkileri olur. useradd --system --shell /usr/sbin/nologin dsh ile bir sistem hesabı oluşturun, /var/lib/dsh dizininin sahipliğini bu hesaba verin ve birime NoNewPrivileges=true ekleyin. Daha sonra EACCES: permission denied hatası alırsanız, bunun yaygın nedeni daha önce root olarak yapılan bir çalıştırmanın root sahipliğinde dosyalar bırakmış olmasıdır; sudo chown -R dsh:dsh /var/lib/dsh bu dosyaları temizler.

Birimde dsh'ın hangi sürümünü sabitlemeliyim?

Servisi kurarken npm view @deepseek-ai/dsh version neyi rapor ediyorsa onu kullanın; npm install -g @deepseek-ai/dsh@<that version> ile kurun ve bulabileceğiniz bir yere kaydedin. 0.1.0-rc.7, 18 Ağustos 2026 itibarıyla güncel sürümdü. Önemli olan sürüm numarası değil, sürüm belirtilmeyen npx komutunun paketi başlatma anında çözümlemesidir; bu durum, gözetimsiz bir yeniden başlatmanın sizi sessizce farklı bir yapılandırma formatına sahip bir sürüme taşımasına neden olabilir.