Yüzlerce domain eklemek yalnız döngü içinde komut çalıştırmak değildir. Hesap modeli, benzersiz kullanıcı adı, document root, DNS yetkisi, SSL zamanı, hata günlüğü ve yeniden çalıştırma davranışı birlikte tasarlanmalıdır.
GİRDİ
alanadlari.txt
DOĞRULA
format · tekrar · mevcut kayıt · kota
OLUŞTUR
hesap/site · document root · DNS
KANITLA
HTTP · vhost · sertifika · CSV logWHM/cPanel’de ayrı hesap ve ek domain; Plesk’te subscription ve ek site; panelsiz Linux’ta ise virtual host ve dosya sistemi doğrudan yönetilir. Aynı betiği üç platforma uyarlamak yerine her platformun nesne modelini doğru kullanın.
Her domain için ayrı cPanel hesabı veya tek hesap altında ek domain modelini seçin; sonuçları WHM API/UAPI yanıtlarıyla kaydedin.
Rehberi aç →Plesk Obsidian CLIHer domaini subscription olarak veya mevcut subscription içine ek site olarak oluşturun; service plan, IP, DNS ve SSL akışını ayırın.
Rehberi aç →Nginx veya ApacheDocument root, Nginx server block veya Apache VirtualHost, izin, yapılandırma testi, DNS ve TLS işlemlerini betikle yönetin.
Rehberi aç →WHM API ile hesap oluşturma, paket/kota seçimi, benzersiz kullanıcı üretimi ve sonuç logunu birlikte yönetin.
Domainlerin bağımsız subscription mı yoksa tek subscription altında ek site mi olacağına göre CLI komutunu seçin.
İşletim sistemi ailesini ve web sunucusunu algılayan, önce yapılandırmayı test eden ve hatada yayını durduran betik kullanın.
Küçük harf, IDN/punycode, boşluk, protokol, path ve tekrar kontrolü yapılmadan domain oluşturma döngüsüne geçmeyin.
Domain, hesap, kullanıcı adı, document root ve DNS zone zaten varsa satırı başarısız saymak yerine kontrollü biçimde atlayın veya güncelleyin.
Domain, başlangıç zamanı, işlem türü, API/CLI dönüş kodu, hata metni ve yeniden deneme durumu CSV veya JSON kaydında bulunmalıdır.
Alan adı doğru IP’ye çözülmeden toplu sertifika isteği göndermek ACME rate limit ve başarısız doğrulama riskini artırır.
İzolasyon, kota, müşteri sahipliği ve güvenlik ihtiyacına bağlıdır. Bir projeye ait benzer siteler tek hesapta olabilir; ayrı müşteriler veya farklı risk profilleri genellikle ayrı hesaplarda tutulmalıdır.
Evet. Başarılı satırları tanımalı, mevcut nesneleri doğrulamalı ve yalnız başarısız veya eksik adımları yeniden denemelidir. Aksi halde çift kayıt ve farklı document root riski oluşur.
DNS önceden doğru çözülüyorsa olabilir. Yeni veya toplu DNS değişikliklerinde domainler doğru IP’ye ulaşana kadar beklemek, ardından kontrollü gruplarla sertifika istemek daha güvenlidir.
Betik çıktısı, API/CLI yanıtı, web sunucusu yapılandırma testi, domain bazlı HTTP sonucu ve SSL doğrulama sonucu saklanmalıdır. Gizli anahtar ve parolalar loglanmamalıdır.
Kurulum, sunucu, script ve teknik destek ihtiyaçlarınız için Eka Yazılım ve Bilişim Sistemleri ile iletişime geçebilirsiniz.