SSS

Sıkça Sorulan Sorular

Hizmetlerin kurulumu, erişim ayarları ve müşterilerimizin sıkça gerçekleştirdiği işlemler hakkında pratik ve kısa rehberler.

> Cli>_ kredi sistemi nasıl çalışır?

Tek bir ortak ön ödemeli bakiye tüm uygun hizmetleri finanse eder ve yalnızca etkin olduklarında tüketilir.
faq/prepaid-credit-how-it-works

Cli>_ hesabında tek bir ortak ön ödemeli kredi bakiyesi bulunur. Uygun yeni müşteriler, Starter Credit talebinde ancak gerekli hesap ve kötüye kullanım önleme doğrulamasını tamamladıktan sonra bulunabilir. Etkin uygun hizmetler zaman içinde bu bakiyeyi tüketir. Aylık tahmin 31 gün kullanır ve yeni bir hizmet ancak bakiye en az 7 günü karşılıyorsa başlayabilir. Tahmini çalışma süresi 7 günün altına düştüğünde kırmızı uyarı gösterilir; aksi halde 14 günün altına düştüğünde turuncu uyarı gösterilir.

Bakiye tükendikten 7 gün sonra hizmet askıya alınır, kredi tüketimi durur ve 7 günlük saklama ve silme süresi başlar. Gösterilen son tarihten önce yeterli krediyle yeniden başlatabilirsin. Provision edilmiş bir hizmetin iptali de hizmeti askıya alır ve aynı süreyi başlatır. Bekleyen ve henüz provision edilmemiş bir hizmet hemen devre dışı bırakılabilir. Son tarihten sonra provision edilmiş hizmetin devre dışı bırakılması ve kaldırılması başlar. Force delete hizmeti hemen devre dışı bırakır, saklama süresini atlar ve etkin runtime’dan kaldırmayı başlatır; tamamlanma deployment ve GitOps işlemlerinden sonra gerçekleşir. Yedekler ve Offsite Archive ayrı saklama politikalarına tabidir.

9,90 EUR tutarındaki OpenCode örneği: 9,90 / 31 ≈ günlük 0,319 EUR. 10 tam gün sonra yaklaşık 3,19 EUR tüketilir. Başlangıç bakiyesi tam 9,90 EUR ise ve başka hizmet yoksa yaklaşık 6,71 EUR kalır. Devre dışı bırakıldıktan sonra tüketim durur.

Örnek yalnızca açıklama amaçlıdır. Her zaman Cli>_ içinde gösterilen güncel fiyatlar geçerlidir.

> Terminal aracılığıyla genel bir SSH anahtarının nasıl oluşturulduğu

Güvenli VPS erişimi için bir genel SSH anahtarı oluşturun. Yalnızca genel anahtarı Cli>_ ile paylaşın; özel anahtarı cihazınızda saklayın.
faq/generate-public-ssh-key-tr

Herkese açık anahtar paylaşılır, özel anahtar sizde kalır

Sipariş veya hizmet kurulumunda yalnızca herkese açık SSH anahtarını ekleyin. Özel anahtar bilgisayarınızda kalır ve destekle paylaşılmaz veya bir web formuna girilmez.

Adımlar

  1. Bilgisayarınızda bir terminal açın.
  2. Aşağıdaki komutu çalıştırın: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Dosyanın kaydedileceği yeri onaylayın veya kendi yolunuzu seçin. Özel anahtarınızı kesinlikle kimseyle paylaşmayın.
  4. Genel anahtarı görüntülemek için şu komutu kullanın: cat ~/.ssh/id_ed25519.pub.
  5. `ssh-ed25519` ile başlayan tüm satırı kopyalayın ve sipariş sırasında veya hizmet kurulumu sırasında SSH genel anahtar alanına yapıştırın.
  6. Tüm `ssh-ed25519` satırını SSH genel anahtar alanına kopyalayın.

Yapıştırmadan önce kontrol et

  1. PowerShell veya Windows Terminal'i açın.
  2. Aşağıdaki komutu çalıştırın: ssh-keygen -t ed25519 -C "e-posta adresiniz@example.com".
  3. Anahtarı C:\Users\kullanıcı adınız\.ssh\id_ed25519 konumuna kaydetmek için Enter tuşuna basın veya kendi yolunuzu belirtin.
  4. Windows bir parola isterse, güvenli bir şekilde saklayabileceğiniz bir parola kullanın veya basit kurulum için Enter tuşuna basarak bu adımı atlayın.
  5. Herkese açık anahtarı aşağıdaki komutla görüntüleyin: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Yalnızca "ssh-ed25519" ile başlayan tam satırı kopyalayın. Özel anahtar dosyasını kopyalamayın veya yüklemeyin.
> Windows'ta bir SSH anahtarını görsel olarak nasıl oluşturursunuz

Windows'ta komut satırı kullanmadan, grafik arayüz ile bir SSH anahtar çifti oluşturma adımları.
faq/create-ssh-key-windows-gui-tr

Windows aracını kullanın ve sadece genel anahtarı yapıştırın

SSH anahtar çiftini, PuTTYgen gibi bir Windows SSH istemcisi ile grafiksel olarak da oluşturabilirsiniz. Cli>_ yalnızca genel anahtara ihtiyaç duyar. Özel anahtar dosyasını bilgisayarınızda saklayın ve web formuna yüklemeyin.

Adımlar

  1. PuTTY'yi yükleyin veya zaten yüklüyse PuTTYgen'i açın.
  2. Mümkünse EdDSA/Ed25519 seçeneğini kullanın, aksi takdirde RSA 4096'yı seçin.
  3. Oluştur düğmesine tıklayın ve anahtar oluşturulana kadar fareyi boş alanda hareket ettirin.
  4. Gizli anahtarı yerel olarak korumak için bir parola ekleyin.
  5. Gizli anahtarı bilgisayarınıza kaydedin ve gizli tutun.
  6. Genel anahtar metnini kopyalayın ve Cli>_'deki SSH genel anahtar alanına yapıştırın.

Gizli Verileri Paylaşmayın

.ppk dosyalarını, özel anahtarları, parolaları veya tokenleri destek ekibine veya formlara göndermeyin.

> Kendi alan adınızı getirin

Kendi alan adınızı veya alt alan adınızı, "Kendi alan adınızı kullanın" özelliğini etkinleştirmeden önce CLIopen hizmetine nasıl yönlendireceğinizi öğrenin.
faq/kendi-alan-adini-bagla

Bu ayarın ne işe yaradığı

Kendi alan adınızı kullanma özelliği, hizmetinizin app.example.com gibi kendi ana bilgisayarınız üzerinden yanıt vermesini sağlar; bunun yerine yalnızca oluşturulmuş *.co.cliopen.cloud ana bilgisayarı kullanılmaz. DNS'nin öncelikle CLIopen'e yönlendirilmesi gerekir, böylece ana bilgisayar güvenli bir şekilde hizmet tarafından kullanılabilir.

Başlamadan önce

  1. Kullanmak istediğiniz tam alan adını seçin, örneğin app.example.com. Bir alt alan adı kullanmak en kolay yoldur.
  2. Alan adı kayıt kuruluşunuzun veya DNS sağlayıcınızın DNS yönetim paneline giriş yapın.
  3. Aynı alan adı için çakışan A, AAAA, CNAME, ALIAS veya yönlendirme kayıtlarını silin.
  4. Oluşturulan CLIopen ana bilgisayar adının kullanılabilir durumda kalmasını sağlayın, özel ana bilgisayar adı doğrulanana ve çalışır hale gelene kadar.

Alt alan adı için önerilen DNS ayarları

CLIopen'da gireceğiniz tam alan adı için DNS kayıtları oluşturun. app.example.com için DNS etiketinin app olduğunu unutmayın. Bunu CLIopen giriş adreslerine yönlendirin; bu adresleri CLIopen destek ekibinden veya hizmet belgelerinizden alabilirsiniz. Sağlayıcınız bir kayıt türü soruyorsa, sağlanan IPv4 adresleri için 'A' ve IPv6 adresleri için 'AAAA' kaydı kullanın.

Örnek:

app.example.com.  A     <CLIopen IPv4 adresi>
app.example.com.  AAAA  <CLIopen IPv6 adresi, eğer sağlanmışsa>

CLIopen bir CNAME hedefi sağladığında

Bazı hizmetler, service.customer.co.cliopen.cloud gibi oluşturulmuş bir ana bilgisayar adı sağlayabilir. Hizmetiniz için verilen talimatlar açıkça bir CNAME kullanmanızı gerektiriyorsa, app.example.com CNAME service.customer.co.cliopen.cloud gibi bir kayıt oluşturun. CNAME'leri yalnızca alt alan adları için kullanın; DNS sağlayıcınız ALIAS veya ANAME düzleştirmesini desteklemiyorsa ana/kök alanı için değil.

Kök Alan Adının Kullanımı

example.com gibi bir kök alan adı için, çoğu DNS sağlayıcısı standart bir CNAME kaydına izin vermez. CLIopen giriş adreslerine işaret eden A/AAAA kayıtlarını kullanın veya CLIopen size bir hedef ana bilgisayar adı sağladıysa, sağlayıcınızın ALIAS/ANAME özelliğini kullanın.

Bir alt alanın devredilmesi

CLIopen'in apps.example.com gibi bir alt alan altında kayıtları yönetmesini istiyorsanız, bu alt alan için aldığınız CLIopen ad sunucularına işaret eden NS kayıtları oluşturun. CLIopen'in (veya başka bir DNS hizmetinin) tüm kayıtları yönetmesini kasıtlı olarak değiştirmek istemediğiniz sürece, tüm alan adı için ad sunucularını değiştirmeyin.

Kontrol Listesi

  1. DNS yayılımının tamamlanmasını bekleyin. Küçük değişiklikler genellikle birkaç dakika içinde görünür, ancak bazı sağlayıcılar daha uzun süre önbelleğe alabilir.
  2. Ana bilgisayar adının CLIopen hedefiyle çözümlendiğinden emin olun, eski bir sağlayıcıyla değil.
  3. "Kendi alanınızı kullanın" alanına tam ana bilgisayar adını girin; `https://` ve herhangi bir yolu dahil etmeyin.
  4. Güncellemeden sonra, `https://app.example.com` adresini tarayıcınızda test edin.
  5. Eski DNS kayıtlarını yalnızca yeni ana bilgisayar adıyla çakışmıyorsa saklayın.
> CLIopen'a Bir DNS Bölgesini Aktarma

Alan adınızı ns1.cliopen.com ve ns2.cliopen.com adreslerine yönlendirin, böylece CLIopen tüm bölge için kayıtları yayınlayabilir.
faq/dns-bolgesini-devret

Burada alan adı transferi ne anlama geliyor?

Müşteri DNS söz konusu olduğunda, transfer, alan adı kayıt kuruluşunuzdaki yetkili ad sunucularını değiştirme anlamına gelir. CLIopen'a yönlendirme yapıldıktan sonra, CLIopen DNS'de eklenen DNS kayıtları, bizim yetkili ad sunucularımız tarafından yayınlanır.

Nameserver'ları değiştirmeden önce

  1. Kopyalamanız gereken mevcut DNS kayıtlarını (örneğin web sitesi, e-posta, doğrulama, SPF, DKIM, DMARC ve servis kayıtları) bulun.
  2. Zonu CLIopen DNS'de ekleyin. Delegasyon henüz hazır değilse, CLIopen bunu kaydeder ancak doğrulama geçene kadar müşteriler için etkinleştirmez.
  3. Mümkünse, nameserver'ları değiştirmeden önce gerekli kayıtları CLIopen DNS'te oluşturun.
  4. CAA kaydını doğru yapılandırdığınızdan emin olun, çünkü yanlış değerler sertifika oluşturulmasını engelleyebilir.

Bölgeyi devredin

  1. Alan adınızın kayıt şirketindeki ayarlarını açın, örneğin example.com.
  2. İçerik sunucuları (Nameservers), DNS yönlendirme veya yetkili DNS ayarlarını bulun.
  3. Mevcut içerik sunucularını ns1.cliopen.com ve ns2.cliopen.com değerleriyle değiştirin.
  4. Değişikliği kaydedin ve kayıt ile çözücülerin yayılımını bekleyin.

Doğrulama

CLIopen DNS'e geri dönün ve 'Delegasyonu tekrar kontrol et' seçeneğine tıklayın. Genel NS kayıtları ns1.cliopen.com ve ns2.cliopen.com adreslerini gösterdiğinde, bölge senkronizasyon için kuyruğa alınır ve kayıtlar CLIopen üzerinden aktif hale gelir.

> Hesap Oluşturma ve İlk Giriş

Tek bir müşteri hesabı oluşturun, faturalandırma bilgilerinizi doldurun ve ekibinizin erişebileceği bir e-posta adresini kullanın.
faq/account-registration-and-login

Siparişler ve yönetim için tek hesap

Hesabı, siparişleriniz, fatura bilgileriniz, hizmetleriniz, alan adlarınız ve destek ekibiyle iletişiminiz için uzun vadeli bir merkez olarak kullanın. Ekibinizin personel değişikliklerinden sonra bile erişebileceği bir iş e-posta adresi kullanmak en iyisidir.

İlk siparişten önce

  1. İş e-posta adresinizle kaydolun.
  2. Sayfa tarafından talep edilirse, e-posta doğrulamasını tamamlayın.
  3. Ücretli bir sipariş vermeden önce fatura bilgilerinizi doldurun.
  4. İki faktörlü kimlik doğrulama mevcut olduğunda, ilk oturum açtıktan hemen sonra etkinleştirin.

Ekip erişimi

Parolanızı sohbet veya e-posta yoluyla iş arkadaşlarınızla paylaşmayın. Birden fazla kişinin erişime ihtiyacı varsa, dahili bir parola yöneticisi kullanın veya önerilen ekip prosedürlerini izleyin; destek ekibi parolanıza veya kimlik doğrulama jetonunuza ihtiyaç duymaz.

> Aylık Tahmin, Yıllık Tahmin ve Gerçek Günlük Tüketim

Aylık ve yıllık fiyatlar karşılaştırma amaçlıdır; abonelikli hizmetlerde, değişiklik onayı yapıldıktan sonra günlük tüketim belirleyicidir.
faq/billing-periods-and-credit-burn

Tahminler faturalandırma takvimi değildir

Aylık tahminler 31 günlük bir dönemi, yıllık tahminler ise 372 günlük bir dönemi temsil eder ve karşılaştırmalar için kullanılır. Ön ödemeli hizmetlerde gerçek tüketim, aktif kullanım süresine, seçilen CPU, RAM, depolama alanına ve ücretli seçeneklere bağlıdır; kaynak değişiklikleri yalnızca onaylandıktan, gerekli ödeme yapıldıktan ve uygulandıktan sonra günlük tüketimi etkiler.

Fiyat değişikliği yapmadan önce dikkat edilmesi gerekenler

  1. Günlük tüketimi değişiklik öncesi ve sonrası ile karşılaştırın.
  2. Daha fazla CPU, RAM, disk veya ücretli seçeneklerin günlük kullanım miktarını artırabileceğini göz önünde bulundurun.
  3. Değişikliğin geçerli olabilmesi için, onaylanması, gerekirse ödeme yapılması ve uygulanması gerekmektedir.
  4. Muhasebe için sipariş onaylarını ve kredi geçmişini kaydedin.

Değerlendirme yaparken belirli bir döneme odaklanın

Destek ekibine, sipariş numarası, hizmet adı ve kontrol etmek istediğiniz tarihleri iletin. Banka hesap bilgilerinizi, tam ödeme kayıtlarınızı veya istenmeyen kişisel veriler içeren ekran görüntülerini göndermeyin.

> Siparişin Ödeme Sonrası Durumu

Siparişler, ödeme sağlayıcısının onayı için bir süre bekleyebilir; ilk sipariş açıkça iptal edilmediyse veya süresi dolmadıysa, tekrar sipariş vermeyin.
faq/order-status-and-payment-confirmation

Beklemede olması, başarısızlık anlamına gelmeyebilir

Ödeme sayfasından geri döndükten sonra siparişiniz, ödeme sağlayıcısından onay bekleyebilir. Durum açıkça başarısız veya süresi dolmamışsa, yeni bir sipariş oluşturmak eşleştirmeyi gereksiz yere karmaşıklaştırabilir.

Ödeme Sonrası İzlenecek Adımlar

  1. Ödeme tamamlandıktan sonra Cli>_ sayfasına geri dönün.
  2. Hesabınızda sipariş durumunu kontrol edin ve varsa ödeme ile ilgili bir mesajı inceleyin.
  3. Sipariş hala 'beklemede' ise, sağlayıcının onayını tamamlaması için biraz zaman tanıyın.
  4. Bir sorunla karşılaşırsanız, sipariş numarasını ve varsa ödeme referansını destek ekibine iletin.

Göndermemeniz Gerekenler

Destek ekibi, kredi kartı bilgilerinizi, giriş şifrenizi veya tam banka dekontunuzu talep etmeyecektir. Yeterli olan bilgiler arasında sipariş numarası, ödeme zamanı, görünen durum ve bir hata mesajı görüntüleniyorsa, hassas bilgilerin gizlendiği bir ekran görüntüsü yer alır.

> Hizmeti kurmayı hızlandıran bilgiler

Hizmet adı, alan adı, depolama alanı, erişim e-postası ve genel SSH anahtarı gibi bilgileri hazırlayın; gizli bilgileri formlara girmeyin.
faq/service-setup-information-needed

Doğru bilgiler zamandan tasarruf sağlar

Sipariş formlarını hizmet adı, alan adı, DNS hedefi, depolama alanı boyutu, CPU, RAM, yönetici e-postası veya genel SSH anahtarı gibi herkese açık veya gizli olmayan değerler için kullanın. Şifreler, özel anahtarlar ve token'lar sipariş formlarına girilmemelidir.

Sipariş vermeden önce hazırlık yapın

  1. Ekibinizin anlayabileceği bir hizmet adı seçin.
  2. Kendi alan adınızı kullanıp kullanmayacağınıza veya geçici bir hostname kullanıp kullanmayacağınıza karar verin.
  3. Hizmetin gerektirdiği durumlarda, bir SSH anahtarı hazırlayın.
  4. Çalıştıracağınız uygulamaya göre depolama alanını ve kaynakları kontrol edin.

Gizli bilgileri göndermeyin

Bir bilginin gizli olup olmadığından emin değilseniz, göndermeden önce sorun. Özel anahtarlar, parolalar, token'lar, veritabanı yedekleri ve tam yapılandırma dosyalarını sohbet veya sipariş formuna göndermeyin.

> Siparişten sonra CPU, RAM, disk veya saklama süresini değiştirme

Mevcut hizmeti yeni bir sipariş oluşturmak yerine, kendi detay sayfasından düzenleyin. Kaynak değişikliği fiyatı, hizmet ücretini, günlük kredi tüketimini, yeniden başlatmayı ve kesinti riskini etkiler.
faq/change-service-resources-after-order

Mevcut bir hizmeti değiştiriyorsunuz, yeni bir tane oluşturmuyorsunuz.

Eğer hizmet zaten çalışıyorsa, kaynak değişikliklerini mevcut hizmetin detay sayfasından yapın. Yeni bir sipariş vermek, mevcut hizmeti değiştirmek yerine yeni bir hizmet oluşturabilir ve onaylandıktan, ödeme yapıldıktan ve uygulandıktan sonra fiyatı, günlük kredi tüketimini ve çalışma davranışını değiştirebilir.

Değişikliği onaylamadan önce

  1. Mevcut CPU, RAM, disk alanı, yedekleme süreleri ve Offsite Archive saklama sürelerini görüntüleyin.
  2. Yeni günlük fiyatı ve kredi kullanımına etkisini kontrol edin.
  3. Yeniden başlatma, bakım veya kesinti uyarılarını okuyun.
  4. Riskli bir değişiklik yapmadan önce, önemli verilerin kendi yedeğini alın.

Değişiklik beklendiği gibi gerçekleşmediğinde

Lütfen hizmet adını, değişikliğin zamanını, görünür durumu ve hata mesajını gönderin. Parolalar, özel anahtarlar veya belirteçler gibi gizli bilgileri göndermeyin; teşhis için yalnızca genel bağlam ve gizlenmiş bir ekran görüntüsü yeterlidir.

> Hizmetin İptali ve Veri Silme Süresi

Sağlanan hizmet öncelikle askıya alınır, yapılandırılabilir bir veri silme süresi gösterilir ve daha sonra kalıcı olarak silinebilir. Yedeklemeler ve Offsite Arşiv ayrı işlemlerdir.
faq/cancel-service-and-data-retention

İptal işlemi, her zaman hemen tüm verilerin silinmesi anlamına gelmez.

Zaten etkinleştirilmiş bir hizmet iptal edildiğinde, öncelikle askıya alınır ve yapılandırılabilir bir süre boyunca görünür bir silme tarihi gösterilir. Bu süre içinde hizmetin geri yüklenmesi veya verilerinin dışa aktarılması gibi işlemler yapılabilir. Bekleyen, ödenmemiş ve henüz başlatılmamış siparişlerin veri yaşam döngüsü farklı olabilir ve kalıcı olarak silinmesi, yaşam döngüsü süresinin dolduktan sonra gerçekleşir.

Silmeden önce kontrol edin

  1. İhtiyacınız olan verileri uzun süreli olarak saklamak için kendi export'unuzu oluşturun.
  2. Askıya alınmış bir hizmet için planlanan silme tarihini ve saatini okuyun.
  3. Yedekleme ve Offsite Archive sürelerinin, hizmetin yaşam döngüsü silme işleminden farklı olduğunu unutmayın.
  4. Emin değilseniz, silme tarihinden önce destek ekibiyle iletişime geçin.

Belirlenen tarihten sonra verilerin kurtarılması mümkün olmayabilir.

Görünür sürenin dolmasıyla birlikte verilerin hala kullanılabilir olduğu varsayılmamalıdır. Sorularınızda sipariş numarasını ve hizmet adını belirtin; veritabanı çıktıları veya gizli giriş bilgileri göndermeyin.

> Yedeklemeler ve geri yükleme talepleri

Yedeklemeler, operasyonel iyileştirme için kullanılır; veri dışa aktarmanın yerine geçmez. Geri yükleme işlemi, daha yeni verileri üzerine yazabilir.
faq/backups-and-restore-requests

Yedekleme bir arşiv veya dışa aktarma aracı değildir

Yedekleme saklama süresi, seçilen ürün ve seçeneklere bağlıdır. Yedeklemeler, operasyonel hatalarda kurtarmaya yardımcı olur, ancak kendi dışa aktarma işlemlerinizin, denetim kayıtlarınızın veya Offsite Archive'ınızın yerini tutmaz. Geri yükleme işlemi, daha yeni değişiklikleri üzerine yazabilir.

Geri yükleme isteği hazırlama

  1. Lütfen hizmet adını ve sipariş numarasını giriniz.
  2. Geri alınmasını istediğiniz yaklaşık zamanı belirtiniz.
  3. Destekleniyorsa, tüm hizmetin mi yoksa belirli bir bölümün mü geri alınacağını açıklayınız.
  4. Şifreler, token'lar veya özel anahtarlar içermeyen görünen bir hata veya bağlam ekleyin.

Geri yüklemeden önce etkileri göz önünde bulundurun

Hizmet, geri yükleme işlemi sırasında yeni veriler aldıysa, bunlar eski bir durumla değiştirilebilir. Geri yüklemeyi onaylamadan önce ekibi bilgilendirin ve kaybetmek istemediğiniz verilerin yedeğini alın.

> Offsite Archive'ın Amacı

Offsite Archive, uzak arşiv kopyalarını, kısa süreli operasyonel yedeklerden ve hizmetin yaşam döngüsünden ayrı olarak tutar.
faq/offsite-archive-purpose

Normal çalışma dışı arşiv

Offsite Archive, uzak arşiv kopyaları oluşturmak ve verileri daha uzun süre saklamak için tasarlanmıştır. Bu, bir uygulamanın canlı diski değildir, yerel veri aktarımının yerine geçmez veya kısa süreli yedeklemelerle aynı şey değildir.

Ne zaman etkinleştirilmeli?

  1. Hizmetin normal çalışma döngüsünün dışındaki verileri saklamak için kullanın.
  2. Veri saklama sürelerini, uyumluluk gereksinimlerinize veya kurtarma hedeflerinize göre seçin.
  3. Maliyetin, depolanan veri miktarı ve saklama süresiyle arttığını göz önünde bulundurun.
  4. Büyük veri kümeleri için, arşivleme işlemini kendi dışa aktarma sürecinizle birlikte planlayın.

Fiyatlandırma Nasıl Anlaşılır

Temel ölçü MB-gün'dür: saklanan veri miktarı ve saklama süresi. Fiyat, müşteriye EUR/GB/ay olarak gösterilir ve sonuç tam sentlere yuvarlanır.

> VPS için CPU, RAM ve Disk Seçimi

VPS boyutunu uygulamanızın gereksinimlerine, veritabanı kullanımına, önbelleğe (cache), log kayıtlarına ve beklenen büyümeye göre seçin. OOM hataları veya disk takası (swap) kullanılması, daha fazla RAM'e ihtiyaç olduğunu gösterir.
faq/vps-cpu-ram-and-disk-sizing

Gerçek iş yüküne göre başlayın, hisse değil

Küçük bir statik web sitesinin ihtiyaçları, bir veritabanından, Java uygulamasından, arama motorundan veya derleme içeren bir konteynerden farklıdır. Planlama yaparken uygulama belleğini, önbelleği, veritabanını, günlükleri, yüklemeleri ve büyüme için ayrılan alanı göz önünde bulundurun.

Planın küçük olduğunun belirtileri

  1. OOM (bellek yetersizliği), işlem sonlandırma veya sürekli takas durumlarında RAM'i artırın.
  2. Sürekli yüksek işlem yükü, sıkıştırma, derleme işlemleri veya yoğun çalışan uygulamalarda CPU'yu artırın.
  3. Dosya sistemi, günlükler veya veritabanı dolmadan diski genişletin.
  4. Her değişiklikten sonra uygulamanın hala orijinal sınırlamaya takılıp takılmadığını kontrol edin.

Boyutlandırma sorusuyla ilgili hangi bilgileri göndermeniz gerekir?

Hizmet adı, uygulama türü, görünen hata mesajı, yaklaşık sorun süresi ve mevcut CPU, RAM ve disk değerleri yardımcı olabilir. Parolalar, özel anahtarlar veya dahili yapılandırma dosyaları göndermeyin.

> VPS için Genel IP Adresi Ne Zaman Kullanışlıdır?

Özel bir genel IP adresi, dış sağlayıcılar veya güvenlik duvarları tarafından ihtiyaç duyulan, güvenilir bir kaynak adresi, içeri gelen erişim, portlar veya DNS adları için kullanışlıdır.
faq/vps-public-ip-options

Öncelikle iletişim yönünü belirleyin

Herkese açık IP adresi her hizmet için otomatik olarak gerekli değildir. Genellikle, dış ortakların, sağlayıcıların veya güvenlik duvarlarının izin listesi gereksinimlerini karşılamak, kararlı bir çıkış kaynağı sağlamak veya belirli bir porta gelen trafiğe erişim sağlamak için kullanılır.

IP siparişi öncesi sorular

  1. İş ortağınıza, gelen trafiğe, giden trafiğe veya her iki yöne de izin verilip verilmediğini sorun.
  2. Mümkün olduğunca sayısal IP adresleri yerine DNS adlarını kullanın.
  3. Uygulamanızın gerçekten ihtiyaç duyduğu portları açın.
  4. İzin listesi talebinizi, üretim erişimini değiştirmeden önce destek ekibine iletin.

Ne kapatılmalı

Herkese açık IP adresi, tüm portların açılması anlamına gelmez. Erişim izinlerini yalnızca gerekli minimum hizmetlere göre yapılandırın ve parolalar, özel anahtarlar veya hassas değerler içeren güvenlik duvarı ekran görüntüleri göndermeyin.

> VPS'ye Paylaşımlı SSH Erişimi

Ek bir genel IP adresi satın almadığınız takdirde, VPS yüksek portlu paylaşımlı bir SSH bağlantısı üzerinden bağlanır; genel bir IP adresine sahipseniz, doğrudan bir SSH bağlantısı da mevcuttur.
faq/shared-ssh-access-for-vps

Neden Paylaşımlı SSH Yüksek Bir Port Kullanır?

Birden fazla VPS hizmeti aynı genel SSH erişim noktasını paylaşabilir, bu nedenle her hizmete kendi yüksek portu atanır. Bu port, bağlantının doğru VPS hizmetine yönlendirilmesini sağlar; yoksa bağlantı hangi VPS'ye gönderileceğini belirlemek mümkün olmaz.

Bağlanma Yöntemleri

  1. Paylaşımlı bir SSH bağlantısı için, hizmet sayfasındaki SSH kullanıcı adını, genel sunucuyu (host) ve yüksek port numarasını aynen kopyalayın.
  2. `ssh -p <port> <kullanıcı_adı>@<genel_sunucu>` komutunu kullanarak bağlantı kurun.
  3. Hizmetinizde ayrılmış bir genel IP adresi varsa, SSH erişimi doğrudan bu IP adresine veya ilgili DNS adına yalnızca SSH servisi ve güvenlik duvarı (firewall) ayarları uygun şekilde yapıldığında mümkün olabilir.
  4. Özel anahtarı yalnızca yerel SSH istemciniz veya aracınız üzerinden kullanın; destek ekibine yalnızca genel sunucu adı, port numarası, kullanıcı adı ve görünen hata mesajını iletin.

Eğer ek bir genel IP adresiniz varsa

Genel IP adresi, paylaşımlı SSH erişim noktasının yerini değiştirmez; izin listeleri, izleme veya doğrudan bağlantılar için uygun olan ayrı bir erişim yöntemi ekler. Uygulamada iki farklı SSH erişimi türü görebilirsiniz: yüksek portlu paylaşımlı sunucu ve genel IP adresine sahip hizmet için doğrudan sunucu veya IP adresi.

> Kendi alan adınızı bağlamadan önce kontrol

Alan adınızı değiştirmeden önce, yetkili DNS ayarlarını, doğru ana bilgisayar adını, kayıt tipini (alan adı mı yoksa alt alan adı mı), ve çakışan eski kayıtları kontrol edin.
faq/custom-domain-readiness-checklist

Kesin ana bilgisayar adı önemlidir

Öncelikle, example.com gibi bir ana alan adı mı yoksa app.example.com gibi bir alt alan adı mı bağladığınızı netleştirin. Her iki seçenek de farklı DNS kayıt türleri, DNS sağlayıcısı kısıtlamaları ve kayıt kuruluşunda doğrulama gerektirebilir.

DNS değişikliğinden önce

  1. DNS kayıtlarının düzenlendiği alanın yetkili nameserver veya kayıt şirketi olduğundan emin olun.
  2. Aynı hostname için çakışan A/AAAA, CNAME, ALIAS, ANAME veya yönlendirme kayıtlarını kaldırın veya düzenleyin.
  3. Kullanılan hizmet ve hostname türü için önerilen kayıt tipini kullanın.
  4. Değişiklikten sonra, DNS yayılımının tamamlanmasını bekleyin ve ardından HTTPS bağlantısını test edin.

Güvenli Geri Alma

Eski sunucuyu, yeni alan adının doğru yanıt vermesini beklemeden kapatmayın. Sorun giderme sırasında lütfen alan adını, beklenen hedefi ve herkese açık DNS sonuçlarını gönderin; kayıt kuruluşuna (registrar) erişim bilgilerinizi veya API tokenlerinizi paylaşmayın.

> Hizmetler İçin DNS Kayıt Tipleri

A/AAAA kayıtları adreslere yönlendirilirken, CNAME kayıtları bir takma ada, MX kayıtları e-postaya ve TXT kayıtları doğrulama, SPF, DKIM veya DMARC için kullanılır.
faq/dns-record-types-for-services

Her kaydın farklı bir görevi vardır

A ve AAAA kayıtları IP adreslerine işaret ederken, CNAME alt alanlar için bir takma ad oluşturur, MX posta yönlendirmesini sağlar, TXT doğrulama bilgilerini ve e-posta politikalarını taşır ve CAA ise sertifika yetkilendirme kuruluşlarını sınırlar.

Kayıtları kopyalarken

  1. Hizmetin talimatlarına göre adı, türü ve değeri tam olarak kopyalayın.
  2. DNS kuralları izin vermiyorsa, başka kayıtları olan bir ana bilgisayar adına CNAME kaydı eklemeyin.
  3. DKIM değerini sağlayıcının belirlediği alanın altında ve DMARC kaydını genellikle _dmarc altında oluşturun.
  4. CAA ayarını dikkatli yapın, çünkü yanlış bir değer sertifika yetkilendirmesini engelleyebilir.

DNS çalışmadığında

Destek ekibine hostname'i, kayıt tipini, beklenen değeri ve herkese açık olarak görünen sonucu gönderin. DNS yönetimi giriş bilgilerinizi veya API tokenlerini içeren ekran görüntülerini göndermeyin.

> DNS yayılımı ve TTL: Dakika bazında kesinlik garantisi yoktur

TTL değeri, çözümleyicilerin eski yanıtları ne kadar süreyle saklayacağını belirler; geçiş süreci boyunca hem eski hem de yeni sonuçlar eş zamanlı olarak görülebilir.
faq/dns-propagation-and-ttl

Yayınlama, önbellekleme işlemidir

DNS yayını için kesin bir dakika garantisi yoktur. Yetkili kayıt değiştirildikten sonra, farklı çözümleyiciler TTL süresi dolana kadar hem eski hem de yeni yanıtları döndürebilir.

Planlanan bir değişiklik için

  1. Sağlayıcınız izin veriyorsa, planlanan değişikliğe başlamadan önce TTL değerini düşürün.
  2. DNS ayarını bir kez yapın ve önbellekler temizlenene kadar tekrar tekrar düzenlemeyin.
  3. Eğer sonuçlar farklıysa, birden fazla DNS sunucusundan veya ağdan test edin.
  4. Değişiklik zamanını, eski değeri, yeni değeri ve TTL'yi not edin.

Teşhis sırasında hangi bilgilerin gönderilmesi gerekir

Hostname, beklenen hedef, görünen eski yanıt, görünen yeni yanıt, TTL ve değişiklik zamanını belirtin. DNS hesabı erişim bilgilerinizi veya sağlayıcının dahili notlarını göndermeyin.

> Workspace Suite için Depolama Planlaması

Depolama kapasitesini hesaplarken kullanıcı dosyalarını, paylaşılan klasörleri, versiyonları, geri dönüşüm kutusunu, ön izlemeleri, senkronizasyon yükünü ve ekip büyümesini göz önünde bulundurun.
faq/nextcloud-storage-planning

Workspace Suite, görünür dosyaların ötesinde de büyüyor

Kullanıcı dosyaları, paylaşılan klasörler, silinen dosyalar, sürüm geçmişi, önizlemeler, küçük resimler, senkronizasyon istemcileri ve içe aktarmalar depolama alanını kullanır. Depolama alanı limite yaklaştığında, yükleme veya senkronizasyon hataları oluşabilir.

Kapasite talebinde bulunmadan önce

  1. Mevcut kullanıcı dosyalarını ve ortak klasörleri hesaplayın.
  2. Silinmiş dosyalar, sürüm geçmişi, önizlemeler ve senkronizasyon için ek alan ayırın.
  3. Büyük veri aktarımlarını, yeni ekipleri ve beklenen büyümeyi göz önünde bulundurun.
  4. Kullanıcılar sınıra ulaşmadan önce depolama alanınızı artırın.

Senkronizasyonda sorunlar oluştuğunda

Lütfen hizmet boyutunu, yaklaşık kullanım oranını, sorunun yaşandığı zamanı ve müşterinin gördüğü hata mesajını iletin. Kişisel dosyaları, parolaları veya kullanıcı verisi dışa aktarımlarını yalnızca destek ekibi güvenli bir şekilde talep ederse paylaşın.

> Gitea'ya Depoları Taşıma Rehberi

Gitea'ya depoların taşınması: LFS, alt modüller, korunan dallar ve etiketler, dağıtım anahtarları, token'lar, webhook'lar, CI/CD ve doğrulama klonlama/push testleri ile Gitea geçişini planlayın.
faq/gitea-repository-migration

Migrasyon sadece `git clone` değildir

Kod geçmişinin yanı sıra, sahipleri, ekipleri, korunan dalları, korunan etiketleri, Git LFS'yi, alt modülleri, dağıtım anahtarlarını, webhook'ları ve CI/CD bağlantılarını da taşımanız veya yeniden yapılandırmanız gerekir.

Cutover öncesi kontrol

  1. Depoları, sahipleri, erişim gruplarını ve otomasyon hesaplarını listeleyin.
  2. Git LFS nesnelerini, alt modülleri, korunan dalları ve etiketleri kontrol edin.
  3. Taşıma işleminden sonra clone, push, Git LFS, alt modüller ve CI testlerini yapın.
  4. Eski token'ları, geçiş tamamlandıktan sonra değerlerini paylaşmadan iptal edin veya değiştirin.

Migrasyonda Hassas Veriler

Destek ekibine token'lar, özel anahtarlar, deploy key'lerin gizli kısımları veya CI sırlarını göndermeyin. Yeterli olan, depo adları, entegrasyon türü, görünen hata ve geçiş öncesinde çalışan davranış bilgisidir.

> Listmonk için gönderim alanı

Kampanyalarınız için bir gönderim alanı veya alt alan oluşturun. Ayrıca 'Gönderen' kimliği, SPF, DKIM, DMARC ayarları, geri bildirim yönetimi ve abonelikten çıkma seçeneklerini de hazırlayın.
faq/listmonk-sender-domain-basics

Teslim edilebilirlik alan adı ile başlar

Listmonk'un kampanyalarının başarılı olması için, gönderen alan adının doğru DNS kayıtlarına sahip olması, net bir kimlik bilgisi içermesi ve SPF, DKIM ve DMARC gibi özelliklerin düzgün yapılandırılması gerekir. Bu ayarlar, kampanyaların gönderildiği alan adı veya alt alan adı ile uyumlu olmalıdır.

İlk kampanyadan önce

  1. Gönderici alan adınızı veya alt alan adınızı seçin ve 'Gönderen' kimliğini ayarlayın.
  2. E-posta sağlayıcınız tarafından istenen doğrulama DNS kayıtlarını, SPF, DKIM seçicisi ve DMARC kaydını ekleyin.
  3. Gerçek bir kampanya göndermeden önce test mesajları gönderin ve spam filtrelerine düşme durumunu, geri dönüş davranışını, 'Geri Bildirim Adresi'ni ve bağlantıları kontrol edin.
  4. Büyük listeye göndermeden önce abonelikten çıkma (unsubscribe) ve List-Unsubscribe ayarlarını kontrol edin.

E-posta sırları biletlere dahil edilmemelidir

Tanılama yaparken, lütfen alan adınızı, kayıt tipini, herkese açık DNS değerini ve hata mesajını gönderin. SMTP parolaları, API anahtarları, özel DKIM anahtarları veya kişisel veriler içeren alıcı listesi dışarılarına göndermeyin.

> Classic Hosting için Çalışma Zamanı Ayarları

Classic Hosting, otomatik veya manuel çalışma zamanında çalışabilir. İşlemci (CPU), RAM, bellek, depolama alanı, yedekleme saklama süresi, çevrim dışı arşiv saklama süresi, yüklemeler, önbellek ve günlükler maliyeti ve kararlılığı etkiler.
faq/classic-hosting-runtime-settings

Otomatik mod her zaman en iyi seçenek değildir

Auto Runtime, tanınan projelerde yardımcı olur, ancak Nginx, Apache, FrankenPHP veya belirli bir dil çalışma zamanını seçmek istediğinizde manuel mod daha uygundur. PHP seçici yalnızca seçilen çalışma zamanı tarafından destekleniyorsa kullanılmalıdır.

Dağıtım Öncesi Ayarlar

  1. Framework'e ve yapılandırma yöntemine göre otomatik veya manuel çalışma zamanı (Runtime) seçin.
  2. PHP 8.2, 8.3 veya 8.4 seçeneklerini yalnızca desteklenen PHP senaryolarında kullanın.
  3. CPU, RAM, disk alanı, yedekleme saklama süresi ve Offsite Archive ayarlarını veri hacmine ve trafiğe göre yapılandırın.
  4. Yayınlandıktan sonra yüklemeleri, önbelleği, günlükleri ve görünen uygulama hatalarını test edin.

Uygulama başlatılamıyorsa

Çalışma zamanı modunu, dili veya PHP sürümünü, görünen hatayı, yapılan değişiklikleri ve yaklaşık dağıtım süresini gönderin. .env dosyalarını, parolaları, token'ları veya hassas değerler içeren tam günlükleri göndermeyin.

> Destek ile güvenle paylaşabileceğiniz bilgiler

Destek ekibine sipariş numaraları, hizmet adları, alan adları, zaman dilimleri, genel sunucular, portlar, yedekleme saklama süreleri, Offsite Archive ayarları, yüklemeler, önbellek bilgileri, log dosyaları, ekran görüntüleri ve görünür hatalar gibi bilgileri paylaşmak en faydalıdır.
faq/support-safe-information-to-share

Kaliteli bir talep, ilgili bilgileri içerir, gizli verileri değil.

Destek ekibi, sipariş numarası, hizmet adı, alan adı, genel sunucu veya port, sorunun oluştuğu zaman, yapılan değişiklikler ve tam olarak görünen hata mesajı gibi bilgilere sahip olduğunda daha hızlı yanıt verebilir.

Güvenli mesaj içeriği

  1. Lütfen sipariş numarasını, hizmet adını, alanı, yaklaşık zamanı ve ilgiliyse genel sunucu veya portu belirtin.
  2. Hosting sorunları için lütfen çalışma zamanı modunu, dili veya PHP sürümünü, CPU'yu, RAM'i, depolamayı, yedekleme saklama süresini, Offsite Archive saklama süresini, yüklemeleri, önbelleği ve logları gizli bilgileri içermeyecek şekilde ekleyin.
  3. Ekran görüntülerini göndermeden önce lütfen parolaları, jetonları, özel anahtarları, oturumları ve kişisel verileri gizleyin.
  4. Bir bilginin bilete uygun olup olmadığından emin değilseniz, bilgiyi göndermeden önce sorun.

Asla Gönderilmemesi Gereken Bilgiler

Parolalar, özel anahtarlar, kurtarma tohumları, API belirteçleri, oturum çerezleri, veritabanı dışa aktarımları, tam .env dosyaları, hassas bilgiler içeren tam günlükler veya gizli teknik ayrıntılar paylaşmayın.