CloudLinux kurulu DirectAdmin bir sunucuda PHP Selector’a ya da LVE Manager’a girmek istediğinizde aşağıdaki hatayı alıyor iseniz;
Warning: Unexpected character in input: ‘\’ (ASCII=92) state=1 in /usr/local/directadmin/plugins/lvemanager_spa/admin/index.html on line 11 Warning: Unexpected character in input: ‘\’ (ASCII=92) state=1 in /usr/local/directadmin/plugins/lvemanager_spa/admin/index.html on line 11 Parse error: syntax error, unexpected T_STRING in /usr/local/directadmin/plugins/lvemanager_spa/admin/index.html on line 11
Bu PHP Sürümünüzün min. gereksinim olan PHP 5.4 ten düşük olduğunu gösterir. CloudLinux LVE Manager ve PHP Selector, PHP 5.4 altında çalışmıyor.
Bunun için Sadece LVE ve PHP Selector’ün farklı bir PHP üzerinden çalışması adına bir takım düzenlemeler yaparak çözüm üretebilirsiniz.
Öncelik ile kurulu değil ise multiphp kurun. Bu PHP lerden birini kullanacağız.
yum groupinstall alt-php
Ardından Hangi PHP sürümünü kullanacak isek JSON’u aktif edeceğiz.
Mesela PHP 5.6 olsun. Alt-PHP olarak kurulan PHP 5.6 nın veri yolu;
Kabaca yaptığımız, direkt olarak sunucunu native PHP sürümünü kullanarak bu sayfayı sunmak yerine kendi belirlediğimiz PHP 5.6 nın bu sayfayı sunmasını sağlamak.
cPanel lisans ücretleri sebebi ile, cPanel kullanan pek çok firma çok daha uygun bir alternatif olan DirectAdmin Panel’e geçiş yapmaktadır.
Bu yüzden, ilgili dökümanı size yardımcı olabilmek adına paylaşmayı uygun gördüm.
Bu dökümanda, cPanel kurulu sunucunuzu yedeklemek, Yedeklerinizi DirectAdmin panel kurulu sunucunuza aktarmak, cPanel formatındaki yedeğinizi DirectAdmin formatına dönüştürmek ve ardından yüklemek için gerkeli işlemlerin tamamı yer almaktadır.
Öncelik İle Bilmeniz Gerekenler, Uyarılar ve Öneriler
– cPanel’de mdbox formatına sahip olan mail adreslerinin transferleri test edilmemiştir. – Mailman mail listeleri, majordomo mail listelerine dönüştürülmemektedir. – DirectAdmin’in MySQL veritabanı formatı, kullanıcıadı_dbadı ve kullanıcıadı_dbkullanıcıadı şeklindedir. cPanel de aynı formata sahip ancak karakter sınırlaması size sorun oluşturabilir. (Bkz: https://forums.cpanel.net/threads/username-length-limits.630671/ )
Yedek dönüşüm scripti bu durumlarda kullanıcı adını otomatik olarak kısaltabilmektedir. Ancak, Bu durumlarda sitelere ait veritabanı bilgilerini (Örneğin WordPress için wp-config.php dosyasını) manuel olarak düzenlemeniz gerekebilmektedir. (Detaylı bilgilendirme makalenin devamında sunulmuştur)
Bu durum yaşandığında örnek script çıktısı aşağıdaki gibidir;
Çıktı: WARNING! us_wordpress cannot be owned by user, renaming database user to user_wordpress
– DirectAdmin panel, cPanel’den daha farklı özellikler sunmaktadır. Nginx, Openlitespeed, MySQL8, rspamd vb. avantajları olsa da PostgreSQL ya da Ruby benzeri destekleri bulunmamaktadır. Bu özelliklere sahip sitelerinizi manuel olarak aktarmanız gerekecektir.
– Öntanımlı olarak kullanıcı adları, max 10 karaktere sahip olabilir. cPanel kullanıcılarınızın karakter limitlerini öğrenmek için;
ls /var/cpanel/users | awk '{print length, $0}' | sort -nr | head -n1
Komutunu kullanabilirsiniz. 10 karakterden uzun kullanıcı adları mevcut ise DirectAdmin’de karakter limitini;
/usr/local/directadmin/conf/directadmin.conf
Dosyasının içerisinde bulunan “max_username_length” satırını düzenleyerek değiştirebilirsiniz. Bu işlemi yapmamanız halinde ilgili kullanıcı convert edilmez ve;
Max username length (X) is smaller than cPanel username (Y)
Hatasını alırsınız.
Örneğin, Pratik bir şekilde Kullanıcı adı karakter limitini örneğin 20 yapmak için;
/usr/local/directadmin/directadmin set max_username_length 20 ; service directadmin restart
Komutunu kullanabilirsiniz.
Önemli NOT: DirectAdmin sunucularınızda MySQL sürümünüz 5.7.8 den düşük ise, mutlaka bunu güncellemelisiniz. MySQL 5.7.8 öncesi sürümler 16 karakter destekleyebildiği ve DirectAdmin’de MySQL adı kullanıcı_adı + Database_adı şeklinde olduğu için daha çok karaktere gereksinim duymanız halinde MariaDB 10.x üstü ya da MySQL 5.7.8 üstü sürüme sahip olmalısınız.
Öncelik ile en uzun kullanıcı adı ile tek bir siteyi denemenizi önermekteyim. Deneme başarılı olur ise gönül rahatlığı ile tüm sunucunun aktarım işlemine başlayabilirsiniz.
İşlemlere başlayalım;
CPANEL’DEN DIRECTADMIN’E MIGRATION İŞLEMLERİ
Tüm Sunucunun aktarılması için adım adım yapılacaklar aşağıda yer almaktadır;
cPanel Sunucu:
1) Öncelik ile cPanel sunucu üzerindeki tüm hesapları /home/yedekler isimli bir klasöre alalım. (İşlem öncesi en az kullanılan disk alanı kadar boşta disk alanınız olduğundan emin olmanız önerilir. Eğer yeterli disk alanınız bulunmuyor ise makalenin en sonunu inceleyebilirsiniz.)
Komutlar;
mkdir -p /home/yedekler for user in `ls /var/cpanel/users/`; do { /scripts/pkgacct ${user} /home/yedekler; }; done
Bu komut, bütün hesapların yedeğini /home/yedekler klasörüne almaya başlayacaktır. Komut tamamlandığı zaman;
2) /home/yedekler içeriğini DirectAdmin kurulu sunucumuza aktaralım.
Bu işlemlerin ardından cPanel sunucumuzda işlemlerimiz bitti, Convert ve Restore işlemleri için DirectAdmin sunucumuza geçiyoruz.
DirectAdmin Sunucu:
1) Tüm cPanel türündeki Yedeklerinizi DirectAdmin üzerine Restore etmeden önce doğru izinleri tanımlamalıyız. Sahipliği atamak için komutumuz;
cd /home/admin/admin_backups ; chown admin.admin *
Şeklindedir.
2) Ardından DirectAdmin’e cPanel yedeklerini yükleyebilmesi için gerekli Conversion aracını yüklememiz gerekiyor.
Bunun için komutlarımız;
cd /usr/local/directadmin/custombuild ./build update ./build cpanel_to_da chown -R admin. /home/admin/converted_user_backup
Şeklindedir.
Artık ilgili cpanel yedeğini, sanki normal bir DirectAdmin yedeğiymiş gibi DirectAdmin sunucunuza kontrol paneli üzerinden geri yükleyebilirsiniz.
DIRECTADMIN SUNUCUDA YEDEKLERİ YÜKLEME İŞLEMLERİ
Bunun için;
Admin düzeyinde DirectAdmin sunucumuza giriş yapalım. “Admin Backup/Transfer” kısmına giriş yapalım. Restore Backup sekmesine giriş yapalım.
Burada, Yedek nereden yüklenecek – From where alanını cpanel den convert ettiğimiz yedeklerimizi gösterecek şekilde; “/home/admin/admin_backups” şeklinde düzenliyoruz.
IP olarak normalde, Convert işlemini gerçekleştirdiğimiz sunucunun ana IP adresi baz alınacak. Ancak Yedeği yükleyeceğimiz sunucunun IP adresi farklı olduğu için burada manuel müdahale etmemiz gerekiyor.
IP seçme kısmında – Select IP kısmında “Use the IP from the list” seçeneğini kullanarak sunucuya ait herhangi bir IP seçmeniz gerekiyor. (Tercihen sunucunun ana IP adresi)
Bu işlemde, yedekteki sitelerin tamamını seçtiğiniz IP yi kullanarak oluşturmasını sağlıyorsunuz.
Son olarak ta yüklenecek siteleri, Select Files kısmından seçiyoruz.
Yedekleriniz burada yer alacaktır.
NOT: Yedekleri görmüyor iseniz Nereden – From Where alanında /home/admin/admin_backups klasörünü gösterdikten sonra Güncelleme butonunu kullandığınızda gözlemleyebiliyor olmalısınız. (Update Files)
Eğer işlem sonrası hala gözlemleyemiyor iseniz sahiplik izinlerini admin.admin vermemiş olmanızdan kaynaklanacaktır, “DirectAdmin Sunucu” kısmındaki 1. adımı gerçekleştirmeniz yeterlidir.
Yüklemek istediğiniz yedeklerinizi seçerek Submit butonu üzerinden işlemi başlatmanız yeterli.
İşlem bu kadardır, bu sayede cPanel sunucunuz üzerinden yedeklerinizi alarak DirectAdmin kurulu bir sunucuya aktarıp yükleme işlemini gerçekleştirebilirsiniz.
NOT:Script, public_html içerisinde eski veritabanı adı ve eski veritabanı kullanıcı adı geçen alanları arar ve bulduklarını otomatik olarak düzeltir. Yani temel olarak veritabanı adı değiştiği durumlarda aksiyon almanız gerekmez ancak veritabanı bilgileriniz şfireli ise, ya da uzaktan erişiliyor ise kontrol sağlamanız gerekecektir. WordPress sitelerin tamamında veritabanı adını değiştirmesi gerekir ise yeni bir wp-config.php dosyası oluşturarak yeni oluşturduğu adı girecek şekilde düzenlenmiştir. Ancak çoğu zaman Database kullanıcı adını düzenleyemeyebilir. Bu durumda manuel kontrol sağlamanız gerekmektedir. Eski WordPress sitelerin tamamında, Veritabanı üzerinde sunucuya özel veriyolu yer aldığı için veritabanları üzerinde optimizasyon gerçekleştirilmesi gerekebilir.
Aynı şekilde, bazı siteler sunucuya özel kodlama barındırabilir. Bu sitelerin içerisindeki spesifik kodlama script tarafından düzenlenememekte olup manuel olarak tarafınızca ya da yazılımcılarınızca düzenlenmelidir.
Veritabanı bağlantı bilgileriniz, ioncube / base64 vb. yöntemler ile şifrelendi ise bu dosyaları manuel olarak düzenleyerek tekrar şifreleyerek aktarmanız gerekecektir.
NOT: Eğer yeterli disk alanınız mevcut ise /home/yedekler klasörünü bir kaç hafta sunucuda bırakmanızı öneririm. İhtiyacınız olabilecek, DirectAdmin sunucuda eksik olan herhangi bir dosya tespit ederseniz buradan rahatlıkla alabilirsiniz.
Peki, işlemleri tamamlamış olsak ta ya cPanel sunucunuzda tüm sitelerinizin yedeğini tek seferde alacak disk alanı mevcut değil ise?
Bu durumda doğal olarak yukarıda işlenen bilgilerin hiç biri size yardımcı olamayacak. Ancak bu tabi ki de sağlıklı bir taşıma yapabilmeniz için bir engel değil.
Bu durumda aşağıdaki yönergeleri izlemeniz yeterli olacaktır!
TEK TEK, HESAP BAŞI TAŞIMA
Bu işlem için öncelik ile her seferinde tek tek şifre girme zorunluluğundan kurtulmamız bizim için çok daha faydalı olacaktır.
cPanel sunucumuzda;
ssh-keygen
Komutunu çalıştıralım. Bu komut,
/root/.ssh/id_rsa.pub
Dosyasının içerisine bir anahtar kodu yerleştirecektir.
Komutunu çalıştırın. Bu bizim örneklerimiz için SSH portu 9988, IP adresi 93.187.200.200 olduğunda göre aşağıdaki gibidir;
ssh-copy-id -p9988 root@93.187.200.200
Sizden DirectAdmin sunucunun SSH şifresini isteyecektir. Bu şifreyi girdikten sonra key kopyalanmış olacaktır ve cPanel sunucunuz, bundan sonra DirectAdmin sunucunuza SSH bağlantısı kuracağı zaman sizden şifre istemeden SSH bağlantısı kurabilecektir.
Komutumuz;
for user in `ls /var/cpanel/users/`; do { /scripts/pkgacct ${user} /home/yedekler; rsync -avt -e”ssh -p SSH_PORT” /home/yedekler/cpmove-${user}.tar.gz root@DİRECTADMİN_SUNUCU_IP_ADRESİ:/home/yedekler/cpmove-${user}.tar.gz; rm -f /home/yedekler/cpmove-${user}.tar.gz ; }; done
Yani bu, bizim örneğimizde SSH Portumuz 9988, IP adresimiz 93.187.200.200 olduğuna göre aşağıdaki gibidir;
for user in `ls /var/cpanel/users/`; do { /scripts/pkgacct ${user} /home/yedekler; rsync -avt -e “ssh -p 9988” /home/yedekler/cpmove-${user}.tar.gz root@93.187.200.200:/home/yedekler/cpmove-${user}.tar.gz; rm -f /home/yedekler/cpmove-${user}.tar.gz ; }; done
Bu komut, bir kullanıcıyı yedekleyip aktardıktan sonra yedek dosyasını cPanel sunucudan silecek bir komuttur.
Disk alanınız yetersiz geldiğinde bu komut yöntemi kullanarak ta aktarım yapabilirsiniz.
Tebrikler! Artık cPanel yönetim paneli kullanan sunucunuzdan DirectAdmin yönetim paneli kullanan diğer bir sunucunuza nasıl taşıma yapacağınızı biliyorsunuz.
IIS üzerine .cer ya da .pfx uzantılı SSL sertifikalarınızı nasıl kurabileceğiniz konusunda sizleri yönlendirebilmek için bu yazımızı hazırladık.
Öncelik .cer ve .pfx uzantılı sertifikaları IIS’ene şekilde yükleyebileceğimizi ele alalım, ardından IIS üzerindeki bir siteye nasıl atayacağımızı gözlemleyeceğiz.
.cer Uzantılı Sertifika Yüklemek
Internet Information Services (IIS) Manager’a giriş yapınız.
“Server Certificates” alanına giriş yapınız.
Ardından, Sağ taraftaki Aksiyon menüsü üzerinden “Complete Certificate Request” alanına giriş yapınız.
Burada, .cer uzantılı sertifikanızı seçiniz.
Ardından .cer uzantılı SSL Sertifikanıza IIS üzerinde anılacağı ismi girerek sertifikanızı IIS e tanımlayabilirsiniz.
Tebrikler! Artık .cer uzantılı SSL Sertifikanız, IIS üzerinde tanımlanmıştır ve herhangi bir siteye tanımlanabilir.
.pfx Uzantılı Sertifika Yüklemek
Internet Information Services (IIS) Manager’a giriş yapınız.
“Server Certificates” alanına giriş yapınız.
Ardından, Sağ taraftaki Aksiyon menüsü üzerinden “Import” alanına giriş yapınız.
Burada .pfx uzantılı sertifikanızı seçiniz.
Ardından, PFX dosyasını oluşturur iken belirlenen dosya şifresini giriniz.
Tebrikler! Artık .pfx uzantılı SSL Sertifikanız, IIS üzerinde tanımlanmıştır ve herhangi bir siteye tanımlanabilir.
NOT: .pfx uzantılı sertifikalar, dış bir kaynaktan içe aktarıldığı için sertifikaya özel isim tanımlanamaz, isim kısmı boş kalacaktır.
IIS Üzerinde Bir Web Sitesine SSL Sertifikası Tanımlamak
Internet Information Services (IIS) Manager’a giriş yapınız.
IIS altındaki “Sites” alanına giriş yapınız.
Burada IIS altındaki tüm Web siteleriniz listelenecektir. SSL Sertifikasının kurulumunu gerçekleştireceğiniz Web sitesi ya da Sub domaine giriş yapınız.
Ardından, Sağ taraftaki Aksiyon menüsü üzerinden “Bindings…” alanına giriş yapınız.
Burada halihazırda, http – SSL siz erişimler için kayıtlar bulunmaktadır. Bu kayıtlar üzerinde hiçbir işlem gerçekleştirilmeyecektir.
Add diyerek https kayıtlarını ekleyeceğiz.
Type = https IP Adress = Siteye tanımlanan özel IP adresi ya da sunucunun paylaşımlı IP adresi Hostname = alanadı.com
Olarak düzenlenmelidir.
“Require Server Name Indication” seçeneğinin yanındaki tik aktif edilmelidir.
Düzenleme Öncesi;
Düzenleme Sonrası;
Son olarak “SSL certificate” alanında, SSL Sertifikamızı seçeceğiz.
OK Şeklinde ilerleyerek onayladığınızda, alanadı.com için SSL Sertifikasını tanımlamış oldunuz.
Tekrar Add şeklinde ilerleyerek aynı işlemleri www.alanadı.com için de yapalım,
NOT: Bir Subdomain için kurulum sağlıyor iseniz, www için HTTPS Binding oluşturmanıza gerek bulunmamaktadır.
İşlem sonrası http bağlaçlarımızın yanı sıra, SSL sertifika bilgilerimizi içeren https bağlaçlarımızı da oluşturmuş olduğumuzu gözlemleyebiliriz.
“Close” şeklinde ilerleyerek Bağlaç Düzenleme ekranından çıkabiliriz.
Son olarak, Sağ taraftaki Aksiyon menüsü üzerinden “Restart” şeklinde ilerleyerek yeni konfigürasyonu görmesi için siteyi yeniden başlatmalıyız.
Tebrikler! IIS üzerinde SSL sertifikalarınızı web sitelerinize tanımladınız.
Ceph Storage Kurulum, Ubuntu, CentOS7 Mount ve ESXi Datastore olarak kullanım
Merhaba Arkadaşlar,
Bu makalede Ceph Storage için kurulum prosedürlerini ve örnek bir ESXi sistemine datastore olarak nasıl ekleneceğini işleyeceğiz.
Öncelik ile Bu yapı için, en az 4 sunucu gereksinimimiz olacaktır. Bunlar;
Admin / Deploy Node
Monitor Node
Storage Node 1
Storage Node 2..
Gibi olup, Her node ayrı bir sunucuyu belirtmektedir. Storage Node’ları için ihtiyacınız ne ise o şekilde düzenleyebilir, ek sunucular kurabilir yahut çalışan yapıya ihtiyacınız olduğunda rahatlıkla yeni Storage Node’u ekleyebilirsiniz.
Anlatımlarda 4 sunucunun da halihazırda kurulu ve SSH’ın aktif olduğunu varsayarak ilerleyeceğim.
Ön Ayarlar
Herşeyden önce, OS diskiniz ve Ceph Storage üzerinde kullanıma sunmayı planladığınız diskin ayrı olması gerekdiğini belirtmek isterim. OS diskindeki alan kullanımda olmayacaktır. Kullanıma sunmayı planladığınız Storage diskinde ise hiçbir veri olmamalıdır.
İlk olarak Admin / Deploy Node’unun kurulumunu gerçekleştiriyoruz.
Ben kurulumlarda Ubuntu 16.04.4 kullandım ancak ihtiyacınıza göre OpenSUSE yahut RHEL/CentOS ta kullanabilirsiniz. Anlatım Ubuntu üzerinden olacaktır,
echo deb https://download.ceph.com/debian-{ceph-stable-release}/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
Ardından repomuzu update ederek ceph-deploy kurulumu gerçekleştiriyoruz.
sudoaptupdatesudoaptinstallceph-deploy
Bu işlemler ile Admin / Deploy nodunun ilk kurulumunu tamamlamış olduk.
NOT: Secure Linux (Selinux) aktif ise mutlaka devredışı bırakmalısınız. (Ubuntu üzerinde system utils kurmadı iseniz otomatik disable gelir.)
NOT: Seknronizasyon sorunu yaşanmaması için Tüm node’lara ntp server kurulumunu ihmal etmemeniz gerekiyor.
aptinstallntp
/etc/init.d/ntp start
Bu aşamada öncelik ile, Admin / Deploy Node’unun sunuculara hostname ile erişebilmesi lazım.
Ben node’lara,
Admin Node – ceph
Monitor Node – monitor
Storage Node 1 – node1
Storage Node 2 – node2
Şeklinde Hostname tanımladım.
Admin / Deploy nodu üzerinde /etc/hosts içerisine girerek IP – Hostname şeklinde giriyoruz;
Ve İlgili kullanıcıların sudo yetkisi olduğuna emin oluyoruz. Sudo yetkisi kazandırmak için;
echo "cephusr ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/cephusr
sudo chmod 0440 /etc/sudoers.d/cephusr
İşlem ardından Şifresiz SSH erişimini bu kullanıcılar için aktif etmemiz gerekecektir. ceph-deploy komutu şifre girmez, bu yüzden ssh key generate etmemiz gerekiyor.
Şifreleri soracaktır, şifrelerini girmenizin ardından artık Admin nodu, tüm node lara ssh üzerinden şifre gereksinimi olmadan erişim sağlayabilecektir.
Bu işlemin ardından ceph-deploy’un SSH bağlantısında cephusr kullanıcısını çalıştırabilmesi için, Admin / Deploy Node üzerinde config dosyası oluşturuyoruz;
Host monitor
Hostname monitor
User cephusr
Host node1
Hostname node1
User cephusr
Host node2
Hostname node2
User cephusr
Böylece düz SSH ile bağlanmak istediğinde otomatik root a yönlendirilmeyecek, cephusr kullanıcısına yönlendirilecektir.
Bu işlemler ile ön hazırlıklarımızı tamamlamış olduk. Artık konfigürasyona başlayabiliriz.
Storage Cluster yapısının oluşturulması
Admin nodu üzerinde, ceph-deploy komutunun otomatik oluşturduğu konfigürasyon dosyaları ve keylerin tutulması için bir klasör oluşturuyoruz.
mkdirmy-clustercdmy-cluster
NOT: ceph-deploy komutu, çıktıyı bulunduğu klasöre aktaracağı için kullanırken daima my-cluster klasöründe yahut siz cluster adını ne şekilde belirledi iseniz, o klasörde olmalısınız.
NOT: Başka bir kullanıcı ile giriş yapmış iken sudo kullanmamalısınız.
Artık Cluster oluşturma işlemine başlayabiliriz.
Test için ufak bir journal oluşturarak devam ediyoruz.
/my-cluster/ceph.conf içerisinde, en alta;
[osd]
osd_journal_size = 2000
Şeklinde ekliyoruz.
Deploy işleminden sonra Journal oluşmuş olmalı. Eğer herhangi bir hata alıyor iseniz conf dosyasında yahut kurulumda yanlışlık gerçekleştirmiş olmalısınız, tekrar kontrol etmeniz gerekmektedir.
Şimdi deploy işlemini my-cluster klasörü içerisinde iken gerçekleştirerek cluster’i oluşturalım;
ceph-deploynew monitor node1 node2
Ben şahsen aşağıdaki hatayı aldım;
bash: python: command not found
[ceph_deploy][ERROR ] RuntimeError: connecting to host: monitor resulted in errors: IOError cannot send (already closed?)
Bunun sebebi de ceph-deploy’un phyton ile çalışması ve sunucularda phyton bulunmamasıdır.
Tüm sunuculara aşağıdaki komut ile phyton kurulumu gerçekleştiriyoruz;
sudo apt install python-minimal
Bu işlemin ardından ceph-deploy new nodex nodex nodex komutunu tekrar uyguluyoruz. Sorunsuzca tamamlanmış olmalı.
Ardından node’lar üzerine kurulumu sağlıyoruz;
ceph-deployinstallnode1node2node3
İşlem tamamlandığında Ceph, her node’a kurulmuş olacaktır.
Ardından monitör sistemi için ön hazırlık yapıyoruz,
ceph-deploymoncreate-initial
Bu komut keyleri toplayacaktır ve my-cluster klasörünüzde;
ceph.client.admin.keyring
ceph.bootstrap-mgr.keyring
ceph.bootstrap-osd.keyring
ceph.bootstrap-mds.keyring
ceph.bootstrap-rgw.keyring
ceph.bootstrap-rbd.keyring
Dosyaları oluşmuş olacaktır.
Bu aşamada, Konfigürasyon dosyaları ve admin key’i node lar arası haberleşme için Deploy node’undan diğer nodlarınıza konfigürasyonları ile aktarmanız gerekiyor.
ceph-deployadmin monitor node1 node2
Ardından Node’larınızdaki diski OSD olarak eklemelisiniz.
Ekleme komutu;
ceph-deploy osd create –data {device} {ceph-node}
Formatındadır. Buradaki Device, Node larınız üzerindeki OS diskiniz değil, Storage yapısına sağlayacağınız 2. diskleriniz olacaktır. Komut benim için;
NOT: Güvenlik için birden fazla monitör nodu eklemeniz durumunda bu node lar birbirleri ile senkronize olarak quorum oluşturacaklardır.
Quorum durumunu;
cephquorum_status--formatjson-pretty
Komutu ile inceleyebilirsiniz.
NOT: Güvenlik ve Yedeklilik için birden fazla monitör eklemeniz ŞİDDETLE tavsiye edilmektedir. Aksi halde bir monitör fail verdiğinde, monitör sunucusunda herhangi bir sorun oluşur ise Ceph Storage sisteminiz susacak, çalışmayı durduracaktır. En az 2. bir monitör nodu eklemeniz, hasarlı sunucuyu onarana kadar sistemin durmaması için önemlidir. Anlatımı sadeleştirmek ve minimal tutmak için tek monitör kullanılmıştır.
NOT: Monitor eklemeye çalışır iken;
accepter.accepter.bind unable to bind to 6789: (98) Address already in use
Ya da
[ceph_deploy][ERROR ] GenericError: Failed to add monitor to host: monitor
Şeklinde hata alır iseniz Monitor node üzerinde
cd /var/lib/ceph/mon
rm -rf *
Komutunu uygulamanız, Admin node’u üzerinde de
rm -rf /var/run/ceph/ceph-mon.monitor.asok
Komutunu uygulayarak lock’u silmeniz gerekmektedir. Bu hatalar, bir yerde hatalı konfigürasyon olduğu için monitör ekleyemediğini belirtir. Ardından tekrar;
Komutu ile monitörünüzü/monitörlerinizi tekrar eklemeyi deneyerek başarılı bir şekilde ekleyebilirsiniz.
CephFS kurulumu
ODS lerimizi yarattığımız, monitörümüzü eklediğimize göre artık Linux/Unix sistemlerine mount edilebilen CephFS sistemini oluşturabiliriz.
Ben Metadata nodu olarak monitör nodumu kullandım. Ancak dilerseniz ek bir sunucuyu, örneğin metadata nodunu sisteme ekleyerek görevi ona da atayabilirsiniz.
Anlatım sadeliği ve monitöre çok yük düşmediği için ben monitör nodunu tercih ettim.
Bu admin.secret dosyasını açarak içindeki Key kodunu alıyoruz.
Ardından komutumuz aşağıdaki gibidir;
mount -t ceph NODE:PORT,NODE:PORT,NODE:PORT:/ /MOUNT_EDİLECEK_KLASÖR/ -o name=admin,secret=ADMİN_SECRET_KEY
Ubuntu üzerinde Secret File yerine, direkt Secret Code yani admin.secret dosyasının içeriğindeki kodu ADMİN_SECRET_KEY alanına gireceğiz. Benim oluşturduğum yapıda bu;
mount -t ceph monitor:6789,node1:6789,node2:6789:/ /mnt/ -o name=admin,secret=AQDfUjxbIshaMBAArKNSraYVhLc+tlqbtS9M1w==
Şeklindedir ve bu komutları uygulanmıştır.
Tebrikler, Artık Ceph Storage’iniz Ubuntu sunucunuz tarafından kullanılmaktadır.
Ceph Mount Edildi
Ceph Mount Edildi
Her reboot işleminde otomatik mount olması için /etc/fstab içerisine;
Şeklindedir. Ardından sunucuyu reboot edip mount olduğunu test edebilirsiniz.
ESXi Üzerine Datastore Olarak Mount Etme
Bu işlem standart bir Linux kurulumuna mount etmekten çok daha zahmetlidir. Çünkü Ceph Storage sistemi tek başına ESXi’nin gözlemleyebileceği bir yapıda değildir.
Bunun için öncelik ile bir iSCSI Gateway sunucusu ya da NFS Gateway sunucusu kurulmalı ve konfigüre edilmeli, CEPH Storage bu sunucu üzerinde ESXi’nin okuyabileceği şekilde ESXi ye mount edilmelidir. Kabaca Ceph için bir aracı, bir Gateway sunucusu kurmamız gerekiyor.
Bu işlem için de NFS Gateway olarak Ubuntu 16.04.4 kullanacağım. iCSCI için Ubuntu, PetaSAN, OpenSUSE, CentOS/RHEL gibi alternatiflerimiz mevcut ancak iCSCI üzerindeki araştırmalarımda yeterli verim alamadığım için es geçiyorum.
NFS Gateway
Bu işlem için Admin/Deploy Node, Monitor Node, Node1 ve Node2 dışında 5. bir sunucunun default olarak hazır kurulu olduğunu varsayıyorum. Anlatımımda Ubuntu’dan yola çıkacağım.
Öncelik ile, “Ubuntu 16.04 için” başlığındaki tüm adımları gerçekleştirerek Ceph Storage yapınızı, Ubuntu sunucunuza mount ettiğinizi varsayıyoruz.
Eğer henüz mount etmedi iseniz, buraya tıklayarak makalede ilgili bölüme ulaşabilirsiniz.
Tebrikler, Artık CephFS yapınızı NFS üzerinden networke açtınız!
ESXi Sistemine NFS Disk Ekleme
Ben kurulum ve testlerimde VMWare 6.7 kullandım. Anlatımı da bunun için gerçekleştireceğim.
İşlemler için, ESXi Web arayüzünüze giriş yapınız.
Storage
> New Datastore
Şeklinde ilerleyiniz.
Mount NFS Datastore
İsim = Datastore adı
NFS Server = Sunucu IP si
NFS Share = Veri yolu
NFS Version = NFS 3
Datastore’u eklemek
Tebrikler! Artık Ceph Storage sisteminizi sorunsuz bir şekilde ESXi Sisteminize Mount etmiş bulunuyorsunuz.
Eklenmiş Datastore
Aslında bu bize yeterli olsa dahi NFS Gateway sunucumuzda oluşacak herhangi bir kesinti, VM’lerin de uçması anlamına gelmektedir. Bu yüzden makalenin ilerleyen kısımlarında çok daha güvenli ve yedekli bir yapı olan iCSCI formatını inceleyeceğiz.
Önemli Bilgiler
Herhangi bir aşamada herhangi bir node’umuzun sorunlu olduğundan şüphelenecek olur isek sağlık durumunu;
ssh NODE sudocephhealth Formatında Yani;
ssh monitor sudo ceph health
sshnode1sudocephhealth
ssh node2 sudo ceph health
Şeklinde öğrenebiliriz. Daha detaylı bir analiz için;
ssh NODE sudoceph-s
Komutu ile analiz sağlayabiliriz.
Herhangi bir aşamada geri dönüşü olmayan bir hata yaptığınızı anlarsanız, tüm ceph paketlerini temizleyerek en baştan başlayabilirsiniz.
MySQL Üzerinde yavaş çalışan sorguları tespit edebilmek için bu sorguların bir listesini çıkarabilirsiniz.
İşlemi uygulamak için;
MySQL’e giriş yapın.
Sırası ile aşağıdaki komutları uygulayın;
set @@global.log_queries_not_using_indexes = 1;
set @@global.slow_query_log = 1;
set @@global.slow_query_log_file = /var/log/mysql-slow.log;
set @@global.long_query_time = 0.5;
Ardından bir süre sonra;
/var/log/mysql-slow.log
Dosyasını kontrol ederek yarım saniyeyi aşan sorguları tespit edebilir, bu bağlamda siteniz ve sorgularınız üzerinde optimizasyon gerçekleştirebilirsiniz.
Bir süre sonra bu eklemeyi tekrar normal hale getirmenizi öneririm, aksi takdirde unutulması halinde uzun dönemde gereksiz disk alanı kullanımına sebep olabilir.
Eski haline almak için ise;
MySQL’e giriş yapın.
Sırası ile aşağıdaki komutları uygulayın;
set @@global.log_queries_not_using_indexes = default;
set @@global.slow_query_log = default;
set @@global.slow_query_log_file = default;
set @@global.long_query_time = default;
SSL sertifikası kurulacağı zaman sitenin IP adresini Özel bir IP adresi ile değiştirdiğimizde, DNS yayılma sürecine girdiği için maillerde ve sitenin erişiminde bildiğiniz üzere problem oluşmakta.
Bu sebepten ötürü, Eski IP adresini 2. bir IP adresi olarak ekleyerek erişim problemlerinin üstesinden gelmekteyiz.
Özel IP adresini atamamızdan itibaren aşağıda Bu işlemin nasıl yapılacağını detaylıca anlatacağım;
LINUX
Ben Linux yönünde DirectAdmin üzerinden örnek vereceğim, Hosting sunucularımız DirectAdmin olduğu için anlatım yeterli, ancak buradan edindiğiniz bilgilerden yola çıakrak apache, apache2, litespeed, ngnix kullanan tüm sunucularda bu işlemi yapmanız mümkün.
Öncelik ile Her zamanki gibi Özel IP’nin atamasını yapıyoruz.
Böylece SSL kurulumu yapabilmek için Sitemizi Özel IP adresine alıyoruz.
Sonrasında, İlgili sunucuya giriş yapıyoruz.
İşlem yapacağımız kullanıcının httpd.conf dosyasını favori text editörümüz ile açıyoruz.
Burada, VirtualHost satırını arıyoruz. Sitemiz, DNS kayıtları uyuştuğu sürece sadece bu satırda belirtilen IP adresinden çalışacaktır, eğer bu satırda belirtilen IP adresi, DNS kayıtlarındaki A kayıdından farklı ise ya da bu satırdaki IP hatalı ise, “Apache is Functioning Normally” hatasını alırsınız.
Görselde gözlemleyebileceğiniz üzere Buradaki sunucunun paylaşımlı IP adresi, özel IP ile değişmiş durumda yani herşey düzgün ilerliyor.
Ancak, bu esnada DNS yayılma süreci tamamlanana kadar 2-12 saat içerisinde müşterimizin sorgulama problemlerinden ötürü sitesinin açılmaması, Apache is Functioning Normally hatası vermesi mümkün.
Bu gibi durumlar ile karşılaşmamak için, Özel IP adresinin ardına bir virgül ekleyerek eski yani Sunucunun Paylaşımlı IP adresini de yazmamız gerekiyor.
Bu işlemi yaptığımızda, DNS yayılma süreci içerisinde yeni kayıdı çekmemiş ve eski IP ile siteye ulaşmak isteyen kullanıcılar da erişimde problem yaşamadan siteye erişebiliyor, yeni Özel IP üzerinden de kullanıcılar siteye erişebilir hale geliyor.
httpd.conf dosyasında bu satırdan ilgili kullanıcı altında bulunan her site için iki, her subdomain için de extradan iki tane bulunuyor.
İlki Normal Web erişimi, :80 portu için, 2.si ise SSL erişimi, :443 portu için.
SSL erişimi için gerekli konfigürasyonu barındıran 443 portu için mevcut kayıt üzerinde de aynı eklemeyi yapmayı ihmal etmiyoruz.
Bu işlemlerden sonra tek yapmamız gereken, sunucuda aktif çalışan Web Servisini restart etmek.
lsof -i tcp:80
Yukarıdaki komut ile sunucuda çalışan Web servisi gözlenebilir.
İşlem tamamlanmıştır, bu aşamadan sonra site 2 IP adresine de yanıt verecektir.
İşlemi not alınız ve ortalama 48 saat sonra Paylaşımlı IP Adresini httpd.conf üzerinden kaldırınız.
WINDOWS
Elimde örnek bir site olmadığı için direkt IIS üzerinde çalıştım, İşlemleri siz Plesk Panel, Maestro Panel üzerinden Özel IP atamanızın ardından başlıyor gibi düşünürseniz problem olmayacaktır.
IIS’e giriş yapıyoruz,
İlgili sitemizi buluyoruz ve sağdaki Bindings sekmesine tıklıyoruz.
Gözlemleyebileceğiniz üzerine hem http, hem de https için www li ve www siz bir şekilde Özel IP adresi ile beraber kayıtlar oluşmuş durumdadır.
Bizim yapacağımız, eski IP adresini kullanarak bu kayıtları replike etmek denebilir.
http kısmında pek fazla dikkat etmemiz gereken bir konu yok, www li ve www siz bir şekilde kayıtları oluşturuyoruz.
Sonrasında SSL için kayıtları oluşturacağız, bu konu hassasiyet gerektiren bir konudur.
https’i seçtikten sonra ek olarak bir de SSL Certrificates şeklinde bir kısım açılmakta, ben Default sertifikayı kullandım ancak mutlaka ilgili sitenin SSL sertifikasını kullandığınıza emin olun.
Aynı şekilde https’i ve sitenin SSL sertifikasını seçerek Binding ekliyoruz;
Ardından işlemlerimiz neredeyse tamamlanmış oluyor. ipv4.domain.com gibi kayıtlar görebilirsiniz, bu kayıtları es geçebilir hatta dilerseniz silebilirsiniz. Bu kayıtları replike etmenize gerek yoktur. İşlemlerimizi tamamladığımızda Bindings ekranımız aşağıdaki gibi her kayıttan 2 IP için de içerecektir;
Ardından tek yapmamız gereken IIS te bu sitemizi restart etmek.
İşlem tamamlanmıştır, bu aşamadan sonra site 2 IP adresine de yanıt verecektir.
İşlemi not alınız ve ortalama 48 saat sonra Paylaşımlı IP Adresini IIS üzerinden Bindings sekmesinden kaldırınız.
Bu dökümandaki işlemleri uygulayarak, Kesintisiz Kolaylık ilkesini yakalamaya artık bir adım daha yakınız.
Dosyaları sunucunuza çektikten sonra aşağıdaki komutlar ile tar.gz’den çıkartıyoruz.
tar -zxvf avast4server-3.2.1-i586.tar.gz
tar -zxvf libavastengine-4.7.6-i586.tar.gz
Daha sonra libavastengine klasörüne giriş yapınız.
cd libavastengine-4.7.6-i586
sh mkinstall.sh
Komutu ile kurulumu başlatabilirsiniz. Herhangi bir değişiklik yapmadan Enter’a basarak devam ediyoruz. 1 kaç dakika kurulum sürebilir.
Kernel kurulumu tamamlandıktan sonra
cd ..
cd avast4server-3.2.1-i586
kurulum klasörüne girdikten sonra sh mkinstall.sh komutunu tekrar çalıştırıyoruz. Yine herhangi bir değişiklik yapmadan Enter’a basarak kurulumu tamamlıyoruz.
Ekstra bir ayar yapmadan kurulumu tamamlamış olduk.
Kullanımı
avastcmd taranacak alan
Komutu taramalar için kullanılır. Komutu kullandığınızda tarayıp geçer, sonuçları ayrı bir dosyaya yazdırmak için > bileşenini kullanmalıyız.
avastcmd / > /root/tarama.txt
Bu komut, tarama tamamlandığında sonuçlarını root altında oluşturacağı tarama.txt dosyasına yazar.
Avast, tarama.txt dosyasına taradığı bütün dosyaları sadece bildirir. Aradan incelemek için infected yani zararlı bulaşmış dosyaları ayırmamız lazım. Bunun için ise;
Tarama tamamlandığında bu komutu kullanın, sadece virüslü dosyaları /root/taramainfected.txt dosyasına ayriyetten yazar.
DİKKAT
-bash: /usr/bin/avastcmd: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Yukarıdaki gibi bir hata alacak olur iseniz glibc kütüphanesinin sunucunuzda yüklü olmamasından kaynaklanır.
yum install glibc.i686
ya da
yum install glibc.i386
Komutları ile kurabilirsiniz.
WARNING: your SHM block limit is set to 4294967295.
The value is too small for the latest versions of VPS file.
Please enlarge ‘kernel.shmmax’ value (see sysctl( 8 )).
Şeklinde hata alacak olur iseniz aşağıdaki komutu çalıştırmanız yeterlidir;
