Son Gönderiler

 


Herkese Merhaba,

Bugün 13.2 RELEASE olan sürümümü 14.0 RELEASE sürümüne yükseltmek için freebsd-update aracını kullanmak istediğimde reboot sonrası verilen ikinci “freebsd-update install” komutunun aşırı derecede uzun olduğunu gördüm. Konu ile ilgili biraz araştırma yaptım ve şu link sorunuma çözüm oldu https://forums.freebsd.org/threads/freebsd-13-2-release-14-0-release-upgrade-stuck.91152

Sorun ZFS ile ilgili gibi görünüyor. Geçici bir çözüm olarak işleme başlamadan önce şu komutu çalıştırırsanız bu yavaşlık sorununu çözebiliyorsunuz;

# sysctl vfs.zfs.dmu_offset_next_sync=0

Bu komutu çalıştırdıktan sonra “freebsd-update install” komutunu verin ve işlem normal süresinde tamamlansın.

Ayrıca; FreeBSD işletim sisteminizi freebsd-update ile nasıl güncelleyeceğinizi bilmiyorsanız lütfen FreeBSD Sistem Güncelleme yazımızı inceleyiniz.

Saygılarımla..

 


Merhaba,

Uzun süredir yapmayı düşünüp bir türlü hadi diyemediğim bir işi daha nihayete kavuşturmanın rahatlığı ile bu yazıyı yazıyorum. Fiziksel bir makinede kurulu Ubuntu Server 20.04 ile ilgili uzun zamandır korkulu rüyalar görüyordum. Donanımın çok eski olması her an çökebileceği ihtimali ve üzerinde kurulu kritik uygulamalar nedeni ile diken üzerinde idim. Bu sunucuyu Proxmox VE üzerine taşıyıp sanallaştırmak uzun süredir üzerinde düşündüğüm ancak bir türlü harekete geçmediğim bir iş idi. Bunu bir kaç gün önce hallettim. Nasıl yaptığımı hem hatırlatıcı olması hem de buna benzer bir iş yapmak isteyenler için kayıt altına almak isterim. Başlayalım..

Fiziksel bir makineyi sanal ortama taşımak için elbette pek çok yöntem mevcut. Ben de bunlardan kolay olduğunu düşündüğüm Clonezilla'yı deneyerek işe başladım. Ancak şöyle bir sorun oluştu; fiziksel makinemin HDD'i 440 GB civarında bir büyüklüğe sahipti. Clonezilla ile bu diski sanal makineye taşımak istediğimde sanal makine diskinin de buna eşit veya bundan büyük olması gerektiği hatasını verip durdu Clonezilla. Sanal ortamda disk kullanımı 20 GB civarında olan bir makine için 440 GB disk alanı kullanmak elbette mantıksız bir iş olurdu. Bu aynı zamanda backup alma ve backup'tan geri dönmeyi de zorlaştırırdı. Bu nedenle başka bir çözüm aradım. Ve bulduğum çözüm şöyle oldu..

Öncelikle fiziksel makinede bir dizin oluşturarak işe başladım;

# sudo mkdir -p /mnt/backup

Bu dizine fiziksel makinemizin / dizininde bulunan tüm dosyaları arşivleyip sıkıştırarak kaydedeceğiz. bunun için kullanmamız gereken komut;

# sudo tar czvpf /mnt/backup/physical_machine_backup.tar.gz --exclude=/mnt/backup --one-file-system /

komut / dizindeki tüm dosyaları /mnt/backup dizinini hariç tutarak arşivleyip sıkıştırıyor ve /mnt/backup dizinine kaydediyor. Bu işlem makinenizin hızına ve diskinizin büyüklüğüne göre uzun veya kısa sürebilir, biraz sabırlı olmak gerekiyor. Dosya oluşturulurken bir yandan da Proxmox VE üzerinde Ubuntu Server 20.04 kurulumu yaptım. Her iki işlem sona erince fiziksel makineden şu komutu vererek arşiv dosyamızı sanal makinemize taşıyoruz;

# scp /mnt/backup/physical_machine_backup.tar.gz user@proxmox_vm:/mnt/backup/

komutu verirken, user olarak sanal makinenizdeki kullanıcı adını ve proxmox_vm yazılı yere sanal makinenizin ip numarasını yazmayı unutmayın. Ve elbette sanal makinede bağlanmak istediğiniz user tarafından yazma hakkına sahip /mnt/backup dizinini de oluşturun. Kopyalama işlemi bittikten sonra sanal makinenize bağlanın, öncelikle geri yükleme sırasında olası dosya çakışmasını engellemek için geçici bir dizin oluşturalım;

# sudo mkdir -p /mnt/restore

arşiv dosyamızı bu dizine taşıyalım;

# sudo mv /mnt/backup/physical_machine_backup.tar.gz /mnt/restore/
# cd /mnt/restore

Şu anda dosyalarımızı sanal sunucuya açmak için hazırız ancak yapmamız gereken bir işlem var. Yükleme sonrası /etc/fstab ve /etc/netplan/00-installer-config.yaml dosyaları eski sunucudan kopyalanacaktır. Bu dosyalar sisteme disklerin bağlanması için ve network ayarları için önemli olduğundan sistemi yeniden başlatmadan önce eski hallerine getirilmeli. bu nedenle bu iki dosyanın içeriğini lütfen bir yere kaydedin. Bunu yaptıktan sonra arşivi sanal makinemizin / dizinine açabiliriz;

#  sudo tar xzvpf physical_machine_backup.tar.gz -C /

İşlem bittikten sonra işlem öncesi kopyasını aldığımız /etc/fstab ve /etc/netplan/00-installer-config.yaml dosyalarını eski hallerine getirin. Grub ve initramfs güncelleme yapalım;

# sudo update-grub
# sudo update-initramfs -u

Hepsi bu kadar, şimdi sanal sunucumuzu yeniden başlatalım;

# sudo reboot

Fiziksel sunucunuz sanallaştırıldı ve Proxmox VE üzerine başarı ile taşındı.

Saygılarımla..

 Herkese Merhaba,

Bugün sizlere çok spesifik bir yazılımdan bahsetmek istiyorum; "Avantfax". Avantfax nedir? Avantfax, Hylafax sunucusu için PHP ile geliştirilmiş bir web arayüz. Yaptığı iş en basit tanımla; Hylafax sunucusu ile bütünleşik çalışarak size fax alma veya gönderme işlerinizi web tabanlı yürütmenizi sağlayacak bir ortam sunmak. İşyerimizde çok uzun yıllardır fax için kullandığımız bir ikili Hylafax/Avantfax. Toner ve kağıt tasarrufu sağlayabilen esnek bir ikili. Bir fax/modem ve bir bilgisayar ile işyerinizin tüm fax alma ve gönderme işlemlerini bir web arayüzü ile halletmenizi sağlayabilen hoş bir çözüm. Ancak her güzelin kusurları olduğu gibi Avantfax'ın da bazı kusurları var. Uzun süredir geliştiricileri tarafından geliştirilmediği için demode hale gelmiş pek çok bağımlılığı var. Örneğin Avantfax kullanmak için PHP5 kullanmak zorundasınız. MySQL'in de eski versiyonlarından birisini sisteme yüklemek gerekiyor. Bunun dışında Avantfax, görsel dosyalarda çok miktarda format değişimi, ölçeklendirme, dönüştürme işlemi yaptığı için bazı kütüphanelere de ihtiyaç duymakta. Bugün size ImageMagic kütüphanesi sebebi ile yaşadığım bir sorunu ve bunun çözümünü anlatmak istiyorum. Buraya not alıyorum ki hem bu sorunu yaşayan birine yardımı olabilir (Türkiye'de Avantfax kullanan kaç kişi var inanın bilmiyorum :) hem de ileride aynı sorunu tekrar yaşarsam bana da hatırlatıcı olsun. Öncelikle sorunu tanımlayarak başlayalım..

Bir süredir Avantfax gelen kutusunda gelen faksların thumb.gif dosyalarının düzgün yüklenmediğine şahit oluyordum. Eskiden bir faks geldiğinde ilgili satırın başında bu faksın minik bir görseli yerleştirilirdi. Bunun yerine şöyle bir manzara görmeye başladım;

Gördüğünüz gibi gelen fakslar için ön izleme dosyası olan thumb.gif düzgün şekilde oluşturulmamış ve bu sebeple de standart bir görsel yüklenmiş. Başlarda bunu önemsememiştim. Dün bu neden olur diyerek konuyu biraz araştırıp nedenini bulmak istedim. Sizlerle de bu yazıda bulduklarımı paylaşacağım.

Öncelikle bu durumu tekrar edilebilir bir şekilde denemek gerekiyordu. Hatayı tespit etmek veya düzelip düzelmediğini anlamak için yeni fax gelmesini beklemek çok da mantıklı olmazdı. Biraz internet araştırması sonucunda yeni gelen bir faksı nasıl simüle edebileceğimizi öğrendim. Bir fax geldiği zaman Hylafax tarafından tetiklenen faxrcvd.php betiğini komut satırından belli parametreler ile çağırmak yeni gelen bir faksı işlemekle aynı şekilde işlem yapıyor. Bu bilgiyi Avantfax Proje Sayfasında bir kullanıcının benzer sorunla ilgili yaptığı bildirim mesajında buldum ( https://sourceforge.net/p/avantfax/discussion/540878/thread/1b384150/ ) Bu adreste gördüğünüz komut satırı kullanımı çalışıyor. Sizler için hem komutu hem de açıklamasını yapmaya çalışacağım. Öncelikle ben Avantfax'ı Ubuntu Server 20.04 bir sistemde çalıştırıyorum. Vereceğim yollar bu sisteme göredir. Hylafax ile ilgili dosyaların benim kurulumumda bulunduğu yer /var/spool/hylafax bu dizine geçiş yapalım;

# cd /var/spool/hylafax

Bu dizin içindeyken şu komutu veriyoruz;

# sudo -u uucp bin/faxrcvd.php recvq/fax000004830.tif ttyUSB0

Komutu kısaca açıklayayım; sudo -u uucp komutu uucp kullanıcısı olarak çalıştırmamızı sağlıyor. Bu önemli,  çünkü faxrcvd.php betiği tmp ve faxes dizinlerine dosyalar oluşturup kaydediyor ve bu dizinlerin kullanıcı hakları uucp kullanıcısına gerekli izinleri veriyor. Ayrıca bir faks geldiğinde Hylafax faxrcvd.php yi yine bu kullanıcı hakları ile çalıştırdığı için bizim de aynı kullanıcı ile bu işlemi yapmamız yerinde olur. bin/faxrcvd.php çalıştırmak istediğimiz PHP betiği. Bu betiği Avantfax kurulumunda Hylafax bin dizinine bağlamış olduğunuzu varsayıyorum. recvq/fax000004830.tif ise PHP betiğimize yolladığımız ilk parametre. recvq dizini Hylafax tarafından teslim alınan faksların tif formatından depolandığı alan. Bu dizinde herhangi bir tif dosyasını parametre olarak verebilirsiniz. ttyUSB0 ise Avantfax ile kullandığınız modemin arabirim ismi. Bu parametreyi kendi kurulumunuza göre ttyS0 veya uygun şekilde düzenlemeniz gerekiyor. Komutu verdiğimde şöyle bir çıktı ile karşılaştım;

faxrcvd> executing: recvq/fax000004832.tif ttyUSB0 '' '' CIDNum: '' CIDName: '' DID: '' faxrcvd> PROCESSING FAX from '2122025195' (1 pages) received '2024:05:28 14:07:58' /usr/bin/tiffcp recvq/fax000004832.tif /var/www/html/avantfax/faxes/recvd/2024/05/28/2122025195/000004832/fax.tif
Create PDF
Create Thumbnails convert: no decode delegate for this image format `TIFF' @ error/constitute.c/ReadImage/572. convert: no images defined `/var/www/html/avantfax/faxes/recvd/2024/05/28/2122025195/000004832/thumb.gif' @ error/convert.c/ConvertImageCommand/3258. PHP Warning: chmod(): No such file or directory in /var/www/html/avantfax/includes/functions.php on line 1238 Processing page 1 FAXPATH: /faxes/recvd/2024/05/28/2122025195/000004832 faxrcvd> Inserted /var/www/html/avantfax/faxes/recvd/2024/05/28/2122025195/000004832 from 2122025195 to Inbox ocr_faxcontent> /usr/local/bin/tesseract not found

Soruna dair ilk emareyi böylece yakalamış olduk. thumb.gif oluşturulmak istenilirken convert komutunun çalışmadığını böylece anlamış olduk. Ama nedenini ve nereye bakmamız gerektiğini henüz bilmiyoruz. faxrcvd.php betiğinde bu hatayı oluşturan fonksiyonun static_preview() isimli bir fonksiyon olduğunu buldum. Ve include/functions.php dosyasında bu fonksiyonun tanımlandığı kısma odaklandım. Soruna neden olan kısım şurası idi;

        foreach ($faxfiles as $file) {
            if (!strstr($file, "thumb_"))
                continue;
           
            $newfile = "${basedir}${file}";
                       
            if ($cnt === 0) {
                system("$CONVERT -scale ".PREV_TN." $newfile $preview");
                chmod($preview, 0666);
            }
           
            echo "Processing page ".($cnt+1)."\n";

            $final_file = $path.DIRECTORY_SEPARATOR.PREVIMG.$cnt.PREVIMGSFX;
//            system("$CONVERT -scale ".PREV_SP." $newfile $final_file"); // doesn't work on all TIFs
            system("$TIFFPS $newfile > $tmpfile.ps 2>/dev/null");
            system("$GSN -sOutputFile=$tmpfile.2 $tmpfile.ps -c quit > /dev/null 2>&1");
            system("$PNMSCALE -width ".PREV_SP." $tmpfile.2 2>/dev/null | $PNMDEPTH 31 | $PPMTOGIF 2>/dev/null > $final_file");
           
            chmod($final_file, 0666);
            $cnt++;
        }

Bu kodda system("$CONVERT -scale ".PREV_TN." $newfile $preview"); satırı hataya neden oluyordu. convert komutu tif formatından gif formatına ölçeklendirme yaparak kayıt yapmıyordu bir şekilde. Bunun yarattığı sorunu geliştiriciler de bir alt satırda alenen yazmış aslında. Dikkat ederseniz;

//            system("$CONVERT -scale ".PREV_SP." $newfile $final_file"); // doesn't work on all TIFs

benzer bir işlemin yürütüldüğü ve prev0.gif dosyasının oluşturulduğu alt satırlarda kod comment ile kapatılmış ve sonuna tüm tiflerle çalışmadığı yazılmış. prev0.gif oluşturulurken kullanılmasından vazgeçilmiş bir yöntemin thumb.gif oluşturulurken neden kullanılmaya devam ettiğini bilmiyorum. Fakat çözümün buradan geçtiğini tahmin ettim. thumb.gif dosyasını oluşturan kodları da prev0.gif dosyasını oluşturan kod gibi düzenlersek bu sorunun ortadan kalkacağını varsaydım. prev0.gif oluşturulurken direkt tif dosyasını gif dosyasına çevirmek yerine önce ps formatına dönüştürüp bir kaç basamaktan geçirmiş geliştiriciler. Benzer bir yaklaşımı ben de yukarıda kullandım ve kod şöyle oldu;

/*            if ($cnt === 0) {
                system("$CONVERT -scale ".PREV_TN." $newfile $preview");

                chmod($preview, 0666);
            }*/
if ($cnt === 0) {
    system("$TIFFPS $newfile > $tmpfile.ps 2>/dev/null");
    system("$GSN -sOutputFile=$tmpfile.2 $tmpfile.ps -c quit > /dev/null 2>&1");
    system("$PNMSCALE -width ".PREV_TN." $tmpfile.2 2>/dev/null | $PNMDEPTH 31 | $PPMTOGIF 2>/dev/null > $preview");
    chmod($preview, 0666);
}

Gördüğünüz gibi eski kodu comment edip yerine altta bulunan yeni yaklaşımı kaydettim. Sonrasında yukarıda yazdığım şekilde faxrcvd.php dosyasını komut satırı ile çalıştırdım ve sonuç;


Evet artık thumb.gif dosyamız başarı ile oluşturuluyor ve gösteriliyor. Bu sorunu gidermiş olduk. Faydalı olmuş olması dileği ile..

Saygılar..


 Herkese Merhaba,

Vqadmin bildiğiniz gibi vpopmail komutlarını web arayüzü ile çalıştırmak için bir cgi betiği. Bu betiği kullanmak istediğimde firefox tarayıcısı sürekli olarak "invalid language file" hatası veriyordu. Hatayı aşmanın yolunu Chrome üzerinden girip öncelikli dil ayarını İngilizce yapmak olarak bulmuştum. Bugün bu hata neden olur nasıl gideririm diye derinliğine bir araştırma yaptım. Sorunu çözdüm ve FreeBSD üzerinde nasıl çözüleceğini sizlerle detaylı şekilde paylaşacağım.

Burada anlatacaklarım FreeBSD port ağacında işlemin nasıl uygulandığını anlatıyor ancak siz kendiniz derlerken de aynı mantığı kullanabilirsiniz.

Öncelikle soruna yol açan şeyin ne olduğunu bulmaya çalıştım. Bulduğum şey şu oldu; Vqadmin uygulamayı ziyaret ettiğimiz tarayıcıdan gelen başlıklardan bazılarını kontrol ediyor. Bu başlıklardan bir tanesi HTTP_ACCEPT_LANGUAGE. Bu başlık içinde güvenlik gerekçesi ile . ve / karakterleri olup olmadığını kontrol eden bir fonksiyon buldum. Sorun da aslında buradan kaynaklanıyor. Vqadmin kullanıcıdan HTTP_ACCEPT_LANGUAGE olarak birbirinden virgüllerle ayrılmış dil kodlarını beklerken modern Firefox tarayıcım şöyle bir HTTP_ACCEPT_LANGUAGE başlığı gönderiyor "tr-TR,tr;q=0.8,en-US;q=0.5,en;q=0.3" Bu başlıktaki q parametresi hangi dilin öncelikli olduğunu sunucu tarafına söyleyen bir parametre. Dikkat etti iseniz bu başlıkta . karakterleri bulunuyor. Bu . karakterleri Vqadmin'in kontrolüne takılıp global_error yükselmesine neden oluyor.

Bunu engellemek için HTTP_ACCEPT_LANGUAGE değerinden noktaların temizlenmesinin yeterli olacağını düşündüm. Bu düşüncemi uygulamaya koydum. Sizlere tek tek ne yaptığımı anlatacağım.

Öncelikle Vqadmin'in port ağacındaki dizinine geçiyoruz,

# cd /usr/ports/mail/vqadmin

Bu dizinde peş peşe şu komutları veriyoruz,

# make distclean

# make deinstall

Bu komutlar daha önceden derlediğimiz Vqadmin dosyalarını temizliyor ve hali hazırdaki kurulumumuzu sistemden kaldırıyor. Şimdi Vqadmin kaynak kodunu indirip work dizinine açalım,

# make extract

Bu komut kaynak kodu indirip bulunduğumuz dizindeki work dizinine açacaktır. İşlemi tamamladıktan sonra kaynak kodun bulunduğu dizine geçelim,

# cd work/vqadmin-2.3.6

Bu dizin altındaki lang.c dosyası ilgilendiğimiz dosya. Bu dosyaya bir fonksiyon ve bir ufak ekleme yapacağız. Dosyayı açıyoruz,

# ee lang.c

Ekleyeceğimiz fonksiyon bir değişken içindeki . karakterlerini temizleyen bir fonksiyon olacak. Aşağıda bulunan bu fonksiyona ait kodları dosyanın 36. satırından itibaren ekleyelim (36. satır önemli olabilir, kodun bütünlüğünü bozmayan bir yer olduğu için özellikle belirtmek istedim bu satırı).

char* remove_dots(char *str) {
    int i, j;
    for (i = 0, j = 0; str[i] != '\0'; i++) {
        if (str[i] != '.') {
            str[j++] = str[i];
        }
    }
    str[j] = '\0';

    return str;
}

 Bu eklemeden sonra şu satırı bulun,

tmpstr = getenv("HTTP_ACCEPT_LANGUAGE");

Ve bu satırı şu şekilde değiştirin,

tmpstr = remove_dots(getenv("HTTP_ACCEPT_LANGUAGE"));

dosyayı kaydedip çıkın. Ve iki dizin üste dönün,

# cd ../..

Şimdi kodu derleyip yükleyebiliriz,

# make install

Evet artık "invalid language file" hatasını almıyor olmamız lazım..

Saygılarımla..


 

Merhaba,

FreeBSD üzerinde kurulu PHP+Nginx web sunucumda tarih ile alakalı bazı sorunlar olduğunu farkettim. Şöyle ki sunucumda yapılan işlemlerde UTC+3 değil UTC+0 zaman dilimi kullanılıyor ve tüm işlemler 3 saat geriden yapılıyordu.

Durumdan emin olmak için bir test yapmak istedim. Saati veren bir PHP Scripti sunucumda çalıştırdım ve gerçekten de PHP işlemlerinde saat bilgisinin hatalı olduğunu farkettim. Kullandığım script ve verdiği çıktıyı aşağıya ekliyorum.

 

 

Kullandığım script;

    <?php echo "Saat " . date("h:i:sa"); ?>

Bu scriptin verdiği saat bilgisi şöyle;

    Saat 06:38:19am

Oysa sistem saati o anda;

    # date
    Thu Sep  1 09:38:20 +03 2022

 Sistem saati UTC+3 olduğu halde PHP Scriptleri UTC+0  olarak sonuç veriyor. Bu durumu düzeltmek için php.ini dosyasında ufak bir değişiklik yapmamız gerekiyor. FreeBSD üzerinde standart PHP kurulumunda php.ini dosyasının yolu /usr/local/etc/php.ini olarak belirleniyor. Bu dosyayı açıp içerisindeki şu satırı bulunuz;

    ;date.timezone =

Bu satırın başındaki ; işaretini kaldırıp şu değeri verelim;

    date.timezone = Europe/Istanbul

Burada ters slash işaretine dikkat edelim, normal slash konulursa ayar doğru çalışmıyor. Dosyayı kaydedip çıkarak kuruluma göre web sunucumuzu veya PHP-FPM'i yeniden başlatıp sonucu kontrol edelim. Yukarıdaki scripti çağırdığımızda saat doğru geliyor ise PHP için time-zone ayarımızı başarı ile yapmışız demektir.

Proxmox VE ile ilgili deneyimlediğim bir işlemi daha buraya yazmak istedim. Proxmox VE sürümü ben kurulum yaptığımda 7.1 idi ve sonrasında 7.2 sürümü kullanıma sunuldu. 7.2 sürümü ile gelen değişimlere şu adrese göz atarak bakabilirsiniz (Proxmox Virtual Environment 7.2 released) Ben de 7.1 olan sürümümü güncelleyerek 7.2 yapmak istedim ve bu konuda biraz araştırma yaptım. Proxmox VE yazılımını ücretsiz olarak kullanıyorsanız bu güncellemeyi yapabilmek için bazı işlemler yapmanız gerekmekte. Proxmox VE depoları ile ilgili detaylı bilgi için https://pve.proxmox.com/wiki/Package_Repositories adresini ziyaret edebilirsiniz.  
 
Burada önemli bir UYARI! Proxmox VE yazılımını üye olmadan kullandığımız için Proxmox VE No-Subscription deposunu kullanacağız ve bu depo "production" ortamları için önerilmiyor. Çünkü bu depodaki paketler yeterince test edilmemiş ve doğrulanmamış olabiliyor. Ben bu riski minimize etmek için işleme başlamadan önce tüm sanal makinelerimin yedeğini aldım ve öncesinde test amaçlı kurduğum başka bir Proxmox VE üzerinde güncelleme işlemi yapıp sorun olmadığını teyit ettim. Siz de kendinizce önlemler alınız.
 
Gelelim yapılması gerekenlere. Aslında çok zor ve uzun bir işlem değil. Öncelikle pve-no-subscription deposunu elle eklememiz lazım. Bunun için ssh ile sunucumuza bağlanıp nano ile şu yoldaki dosyayı açalım;
# nano /etc/apt/sources.list

Açtığımız dosyanın sonuna şu satırları ekleyelim;

# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

ctrl+x ve Yes ile dosyada yaptığımız değişimi kaydedip çıkalım. Bundan sonra vermemiz gereken komutlar;

# apt update && apt dist-upgrade

Bu komutların sonunda sistem güncellenmiş olacak. Güncelleme bittikten sonra tüm sanal makinelerinizi durdurup Proxmox VE sunucunuzu yeniden başlatın;

# reboot
Sunucunuz yeniden başladığında Proxmox VE sürüm bilgisini kontrol edin. İyi çalışmalar..

 

Bu dökümanda; Let's Encrypt Wilcard Sertifikasını, DNS sunucu olarak tinydns kullanan bir sistem yöneticisinin nasıl kolayca alabileceğini ve akabinde sertifika yenilenmesinde işi nasıl otomatize edebileceğini kendi deneyimim üzerinden aktarmaya çalışacağım.

 Let's Encrypt nedir, ne işe yarar, nasıl çalışır sorularına bu yazıda çok yer vermek istemiyorum. Eğer Let's Encrypt nedir, nasıl çalışır konusunda bilginiz yetersiz ise öncelikle o konuda biraz araştırma yapmanız yerinde olacaktır.

Let's Encrypt'in sertifika oluşturma için bir kaç "challange" metodu olduğunu biliyorsunuz. Wildcard tipi sertifikalar için bir kısıtlama söz konusu ve bu tip sertifika alabilmek için DNS challange metodunu kullanmak mecburi. Bu metod çok kabaca şöyle çalışıyor; Let's Encrypt sertifika oluşturma aşamasında, txt tipinde bir kayıt üretip bunu DNS sunucunuzdan yayınlamanızı istiyor. Siz DNS kaydını girip sertifika işlemine devam ettiğinizde Let's Encrypt size ilettiği txt kaydının alan adınızda olup olmadığını sorguluyor ve sorgu başarılı olur ise wildcard sertifika üretme işlemi başarı ile gerçekleşiyor. Buradaki amaç elbette sertifika üretmek istediğiniz alan adının gerçekten sahibi olup olmadığını otomatik bir şekilde kontrol etmek. Let's Encrypt süreçleri otomatik hale getirip insan müdahalesini gerektirmeyen bir yapıya sahip.

Bu işlem için Let's Encrypt üzerinde kullanılabilecek plug-in yazılımları mevcut. DNS hizmetini aldığınız büyük oyuncular için işlemi otomatikleştiren plug-in bulabiliyorsunuz. Ancak kendi tinydns sunucusunu çalıştıran benim gibiler için bir kaç düzenleme yapmak gerekiyor. Neyse ki tinydns'in esnek ve basit yapısı nedeni ile bu gayet kolay. Nasıl yapıldığına geçelim.

Öncelikle yaptığım her şey FreeBSD üzerinde bunu belirteyim. GNU/Linux üzerinde de çok yakın bir şekilde aynı yolu izleyebilirsiniz. Bazı dosya yolları ve komutlar farklılık gösterebilir.

Let's Encrypt dosyalarının bulunduğu /usr/local/etc/letsencrypt dizinine girelim. Bu dizinde cli.ini adında bir ayar dosyası göreceksiniz. Bu dosyayı aşağıdaki gibi düzenleyelim;

manual
server = https://acme-v02.api.letsencrypt.org/directory
rsa-key-size = 4096
preferred-challenges = dns
manual-auth-hook = /usr/local/etc/letsencrypt/certbot-dns-auth.sh
manual-cleanup-hook = /usr/local/etc/letsencrypt/certbot-dns-auth-cleanup.sh

certbot yazılımı bize çok rahatlık sağlayan manual-auth-hook ve manual-cleanup-hook tanımlama şansını veriyor. Bu tanımlamalar sayesinde certbot içerisinden shell scriptlerimizi çağırarak sertifika üretimi öncesinde ve sonrasında bazı işlemler yapabiliyoruz. Sertifika oluşturma öncesinde tinydns sunucumuza Let's Encrypt tarafından gönderilen txt kaydını giren shell scripti görelim,

# cat /usr/local/etc/letsencrypt/certbot-dns-auth.sh
#!/usr/local/bin/bash

cd /etc/tinydns/root
cp -f data data-good
echo "'_acme-challenge.$CERTBOT_DOMAIN:$CERTBOT_VALIDATION:120" >> data
/usr/local/etc/letsencrypt/update.sh
# Sleep to make sure the change has time to propagate over to DNS
sleep 25

tinydns için benim kurulumunda root dizini /etc/tinydns/root yolunda, bu dizine geçip data dosyasını data-good olarak her ihtimale karşı yedekliyoruz. certbot tarafından gönderilen txt tipi kaydı data dosyasına yazıyoruz ve update.sh shell scriptini çağırıyoruz. Bu scripti de inceleyelim;

# cat /usr/local/etc/letsencrypt/update.sh
#!/bin/sh

make
rsync -avz -e ssh /etc/tinydns/root/data.cdb root@ikinci_tinydns_ip:/etc/tinydns/root
rsync -avz -e ssh /etc/tinydns/root/data root@ikinci_tinydns_ip:/etc/tinydns/root

make komutu ile data dosyasını cdb formatına çevirip rsync satırları ile varsa ikinci, üçüncü, vb. diğer sunucularımıza da bu değişimi gönderiyoruz. Böylece tüm tinydns sunucularımızda gerekli txt kaydı kaydedilmiş oldu. Bir sonraki aşamada /usr/local/etc/letsencrypt/certbot-dns-auth-cleanup.sh scripti çalışacak ve girilen txt kaydını DNS sunucumuzdan temizleyecek. Bu scriptin içeriği de:

# cat /usr/local/etc/letsencrypt/certbot-dns-auth-cleanup.sh
#!/usr/local/bin/bash

cd /etc/tinydns/root
sed '$d' data > tmp; mv -f tmp data
/usr/local/etc/letsencrypt/update.sh

Yine tinydns root dizinine geçip biraz önce eklediğimiz kaydı silerek update.sh scriptini yeniden çağırıyoruz.

Bu scriptlerin tümü başarı ile çalıştığında cerbot şu şekilde çıktı üretecek;

# certbot certonly -d '*.domain.com'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for *.domain.com
Hook '--manual-auth-hook' for domain.com ran with output:
 /usr/local/bin/tinydns-data
 sending incremental file list
 data.cdb

 sent 1,970 bytes  received 137 bytes  1,404.67 bytes/sec
 total size is 11,671  speedup is 5.54
 sending incremental file list
 data

 sent 281 bytes  received 101 bytes  764.00 bytes/sec
 total size is 7,206  speedup is 18.86
Hook '--manual-cleanup-hook' for domain.com ran with output:
 /usr/local/bin/tinydns-data
 sending incremental file list
 data.cdb

 sent 1,848 bytes  received 137 bytes  3,970.00 bytes/sec
 total size is 11,551  speedup is 5.82
 sending incremental file list
 data

 sent 218 bytes  received 101 bytes  638.00 bytes/sec
 total size is 7,121  speedup is 22.32

Successfully received certificate.
Certificate is saved at: /usr/local/etc/letsencrypt/live/domain.com/fullchain.pem
Key is saved at:         /usr/local/etc/letsencrypt/live/domain.com/privkey.pem
This certificate expires on 2022-04-01.
These files will be updated when the certificate renews.

NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sertifikamız başarı ile oluştu. Yapılması gereken tek bir şey var. Let's Encrypt wildcard sertifikaları 3 ay geçerli oalcak şekilde veriyor. Bu nedenle 3 ayda bir bu sertifikaların yenilenmesi lazım. cli.ini dosyasında yaptığımız düzenleme sertifika yenilenirken de işe yarıyor. Tek yapmamız gereken bir cron işi oluşturmak ve her gün düzenli şekilde certbot'a sistemimizde yüklü sertifikaları denetletmek. Örnek bir cron işi;

0 1 * * * root /usr/local/bin/certbot renew >> /var/log/letsencrypt/renew.log --post-hook "service nginx restart"

Tebrikler, Let's Encrypt wildcard sertifikanızı güle güle kullanın..

Proxmox VE standart kurulumda ön tanımlı olarak LVM-Thin kullanan local-lvm adında bir volüm oluşturmakta. Bu volüm neden olduğunu bilmiyorum ancak benim sistemimde sorun yarattı. Backup ve snaphot alma işlemlerini bu volümde yapmak istediğimde çok yavaş olduğunu ve işlem sırasında diğer tüm sanal makinelerin kilitlendiğini farkettim. 
 
Bu nedenle sanal makine kurulumlarımda local-lvm yerine local depolama alanını kullanmak istedim. Ön tanımlı olarak bu depolama alanı diskin kapasitesinin çok azına sahip. local-lvm depolama volümünü silerek boşalan alanı local alanına kaydırmak istedim. Bu işlemi şöyle yapıyoruz:

Öncelikle Verimerkezi'ne tıklıyoruz ve menüden Depolama sekmesine geçiyoruz. local-lvm üzerine tıklayıp yukarıdan Kaldır butonuna basıyoruz. Emin olmamakla beraber bu işlem volümü silmeyip sadece unmount ediyor olmalı. Bu işlemden sonra sunucu Shell sekmesine tıklayıp terminalden sırası ile şu komutları veriyoruz:
# lvremove /dev/pve/data
# lvresize -l +100%FREE /dev/pve/root
# resize2fs /dev/mapper/pve-root

Soldaki menüden local depolama alanına tıklayarak Özet sekmesine tıklayın. Disk alanı arttı ise işlem başarılı demektir..

Kaynaklar:


https://blog.jarmosz.uk/posts/removing-local-lvm-on-proxmox-5/

Bu dökümanda FreeBSD 13 sistemimiz üzerinde kurulu Apache sunucumuzu php-fpm kullanarak PHP çalıştırır hale getireceğiz. Malum bu işi yapmanın diğer yolu; Apache'yi PHP modülü ile kullanmak. Bu dökümanda daha performanslı çalıştığı söylenen php-fpm ile Apache ve PHP'yi birbiri ile bağlayacağız.
 
Öncelikle Apache ve PHP paketlerini uygun modüller ve ayarlarla kurmamız lazım. Kurulumu ports ile yapıyorsanız ön tanımlı ayarlarda ihtiyacınız olan seçenekler seçili halde oluyor. Apache ve PHP için ön tanımlı değerlerle devam edebilirsiniz. Kurulumlar yapıldıktan sonra düzenleyeceğimiz ilk dosya httpd.conf olacak. Dosyayı açarak aşağıdaki satırları bulun ve örneğe göre düzenleyin. FreeBSD'de ports üzerinden kurulmuş Apache 2.4 için httpd.conf dosyasının yolu;
 

 

 Gerekli modülleri aktif hale getirmiş olduk. Modüllerle ilgili yaptığımız ayarın geçerli hale gelmesi için Apache servislerini yeniden başlatalım:

 PHP-FPM

PHP-FPM (FastCGI Process Manager), ağır yüklü siteler için yararlı olabilen bazı ek özelliklere sahip alternatif bir PHP FastCGI uygulamasıdır. Yazının giriş bölümünde de bahsettiğimiz Apache web sunucusunun PHP modülü ile kullanımı aşağıda şematize edilmiştir.

İstemci (browser), sunucudan bir PHP sayfası talep ettiğinde Apache bu sayfayı PHP modülüne yorumlatıp sonucu istemciye gönderir. Burada PHP yorumlama işinin Apache servisi içinde yapıldığına dikkat edin. PHP-FPM kullandığımızda ise aşağıda bulunan yapı oluşacaktır.


Gördüğünüz gibi Apache bu sefer PHP kodlarının yorumlanmasını kendi içerisindeki PHP modülü yerine, bağımsız bir servis olarak çalışan FPM uygulamasına yaptırıyor. İşin mantığı genel olarak bu. Şimdi gerekli düzenlemeleri yapalım. PHP-FPM bir servis olarak çalışıyor demiştik. Öncelikle bu servisi çalıştırabilmek için /etc/rc.conf içerisine gerekli satırı ekleyelim:

ve servisi çalıştıralım:

Ön tanımlı olarak php-fpm, arka planda 9000 numaralı TCP portunu dinleyecek ve yalnızca yerel makineden gelecek bağlantı isteklerini kabul edecek şekilde ayarlıdır. Eğer php-fpm servisini başka bir makinede çalıştırmayı planlamıyorsanız TCP yerine Unix soketi dinlemek daha hızlı ve daha güvenli bir yol olacaktır. Bu şekilde yapılandırmak için /usr/local/etc/php-fpm.d/www.conf dosyasını açalım ve aşağıdaki şekilde düzenleyelim:
Bu değişikliklerin etkili olabilmesi için php-fpm servisini yeniden başlatmak gerektiğini unutmayın. Aynı durum PHP ile ilgili yapacağınız tüm değişimlerde geçerli. mod_php kullandığınız zamanlarda Apache servisini yeniden başlatmak PHP ayarlarında yaptığınız değişimleri etkin hale getiriyordu ancak şu anda bu işi php-fpm servisi yaptığı için PHP ve php-fpm üzerinde yaptığımız tüm değişikliklerde php-fpm servisini yeniden başlatmayı unutmayalım.

Son olarak Apache üzerinde küçük bir ayar yapmamız lazım. /usr/local/etc/apache24/Includes/php-fpm.conf dosyasını açalım ve şu içeriği ekleyelim:

Tüm ayarlamaları yaptık. Apache servisini yeniden başlatalım:
Yaptığımız konfigürasyonu test edebiliriz. Web sunucumuzda bir php dosyası oluşturup <?php phpinfo();?> kodlarını bu sayfamıza yerleştirelim. Sayfayı ziyaret edelim:


Server API satırında FPM/FastCGI görüyorsanız tebrikler, sunucunuzda Apache+PHP-FPM yapılandırmasını doğru şekilde yapmışsınız..

Author Name

İletişim Formu

Ad

E-posta *

Mesaj *

Blogger tarafından desteklenmektedir.