Son Gönderiler


Merhaba,

Bugün sizlere sanallaştırma ortamında kurduğumuz FreeBSD sistemimizin HDD boyutunu nasıl arttıracağımızdan bahsetmek istiyorum. İlk kurulum esnasında sisteme tanımladığımız disk boyutu bazı nedenlerle bazen yetersiz kalabilmekte, diski yeniden nasıl boyutlandıracağımızı ZFS kullanılmış bir kurulum için nasıl yapmanız gerektiğini anlatmaya çalışacağım.

ÖNEMLİ NOT! Burada sizlere anlatacağım işlemler diskin kullanılmaz hale gelmesine yol açabileceği için lütfen tüm kritik verilerinizi doğru şekilde yedeklediğinizden emin olmadan uygulamaya geçmeyiniz.

Adım 1:

Öncelikle kullandığımız sanallaştırma aracında sanal makinemiz için tanımladığımız disk alanını büyütmekle işe başlıyoruz. Bu işlem sanallaştırma ortamınıza göre farklılık gösterebileceği için detaya girmiyorum. Ben işlemi Proxmox VE üzerinde yaptım. Bu işlemi kolayca sanal makinenin içerisine girip Donanım seçeneğine giderek Disk Boyutlandır seçeneği ile yaptım ve sanal makineme 4 GB ek disk alanı eklenmesini sağladım.

Adım 2:

Sanal makinemizde konsole gidip şu komutu çalıştırıyoruz;

root@web:/home/bedo # gpart show
=> 40 33554352 da0 GPT (20G) [CORRUPT]
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 29358040 3 freebsd-zfs (14G)

gördüğünüz gibi en üstte CORRUPT olduğu görülüyor diskin. Öncelikle bu durumu düzeltelim. Bunun için çalıştırmamız gereken komut;

root@web:/home/bedo # gpart recover /dev/da0
da0 recovered

da0 recover edildi. Durumu kontrol edelim;

root@web:/home/bedo # gpart show
=> 40 41942960 da0 GPT (20G)
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 29358040 3 freebsd-zfs (14G)
33554392 8388608 – free – (4.0G)

evet eklediğimiz 4 GB ilave disk alanı free olarak görünüyor artık.

Adım 3:

4 GB olarak görünen free alanı freebsd-zfs’e eklememiz gerekiyor. Vermemiz gereken komut;

root@web:/home/bedo # gpart resize -i 3 da0
da0p3 resized

buradaki “-i 3” parametresi gpart show komutu çıktısında yer alan freebsd-zfs’in numarası fark ettiğiniz gibi. Son drumu kontrol edelim;

root@web:/home/bedo # gpart show
=> 40 41942960 da0 GPT (20G)
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 37746648 3 freebsd-zfs (18G)

evet ilave 4 GB alan artık freebsd-zfs’e eklenmiş halde.

Adım 4:

Yapmamız gereken son bir işlem var;

root@web:/home/bedo # zpool online -e zroot da0p3

komutunu verip işlemi tamamlıyoruz. zpool list komutunun ilave alan eklemeden önceki ve sonraki çıktılarını paylaşıyorum sizlerle;

Öncesi;

root@web:/home/bedo # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot  13.5G 9.72G 3.78G – – 59% 72% 1.00x ONLINE –

Sonrası;

root@web:/home/bedo # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 17.5G 9.72G 7.78G – – 46% 55% 1.00x ONLINE –

SIZE 13.5 G değerinden 17.5 G değerine yükselmiş durumda. Yeni alanı kullanmaya başlayabilirsiniz.

Saygılarımla..

 


Herkese Yeniden Merhaba,

FreeBSD işletim sistemini ilginç kılan özelliklerinden birisi bildiğiniz gibi “Port Ağacı”. Bu yazıda port ağacının detaylarına girmeden port ağacında kullanabileceğiniz make komutları hakkında yazmak istedim. İşte make komutlarının en çok kullanılanları ve ne işe yaradıkları;

make extract: Kaynak kodu indirip work dizinine açar.

make config: Portun konfigürasyon ekranını gösterir

make fetch: Portun kaynak kodlarını indirir, bunun dışında hiç bir işlem yapmaz

make: Kaynak kodu indirir ve derler ama kurmaz

make build: Portu derler

make install: Kaynak kodu indirir, derler ve kurar

make clean: Derlenmiş kodları (portun içindeki work dizinindeki) siler

make install clean: Kaynak kodu indirir, derler, kurar sonrasında derlenmiş kodları (portun içindeki work dizinindeki) siler

make distclean: Derlenmiş kodları (portun içindeki work dizinindeki) siler ayrıca kaynak kod dosyasını da siler

make deinstall: Portu kaldırır

make reinstall: Kurulu bir portu yeniden kurar ve yükler.

make package: Portu paketler

make check: Portun testlerini çalıştırır

Faydalı olması ümidi ile..

 

 


Merhaba,

Bu yazıda sizlerle fail2ban uygulamasını FreeBSD bir sistem üzerinde PF (Packet Filter) kullanarak nasıl çalıştırabileceğinizi anlatmak istiyorum. fail2ban’a neden ihtiyaç duydum öncelikle bundan bahsederek konuya giriş yapalım. Bir kaç gün önce nginx web sunucuma çok anlamsız ve çok sayıda istekler geldiğini ve bu istekler yüzünden php-fpm sürecinin yoğun çalışarak sistemi zorladığını ve zaman zaman da durduğunu fark ettim. Gelen bu istekleri analiz edip nasıl engellerim diye araştırırken fail2ban uygulamasını fark ettim. Peki nedir bu fail2ban? Kısaca izah etmeye çalışayım;

fail2ban, sunucuları kötü niyetli giriş denemelerine karşı korumak için kullanılan açık kaynaklı bir yazılımdır. Bu yazılım, özellikle SSH, FTP, HTTP, SMTP ve diğer hizmetlere yönelik brute-force saldırılarını tespit etmek ve engellemek için yaygın olarak kullanılır. Fail2ban, sistem loglarını izleyerek belirli bir süre içinde belirli bir sayının üzerinde başarısız oturum açma girişimi veya diğer kötü niyetli faaliyetleri tespit eder. Tespit edilen bu IP adresleri, belirli bir süre boyunca engellenir. Engelleme, genellikle bir firewall kuralı ekleyerek veya mevcut olanı değiştirerek yapılır. Biz de firewall olarak FreeBSD ile birlikte gelen PF firewall yazılımını kullanacağız. O zaman kurulumla işe başlayalım. fail2ban kurmak aslında gayet kolay, vermemiz gereken tek komut;

# pkg install py311-fail2ban

paket ismi önündeki py311 ifadesi sisteminizdeki Python versiyonuna göre değişebilir. Bunu kontrol etmek için pkg veritabanını arama yaparak tarayabilirsiniz. Yukarıdaki komut fail2ban yazılımını sisteme kuracaktır. Yazılımın ayarlarını yapmak için /usr/local/etc/fail2ban dizinine gidelim. Bu dizinde öncelikle bir dosyayı farklı bir isimle kopyalamamız lazım;

# cp jail.conf jail.local

Bu işlemi neden yaptık? Güncellemeler sırasında jail.conf üzerine yazılabileceği ve bizim yaptığımız düzenlemeler kaybolabileceği için bu kopyalama işlemini yaptık. fail2ban’ın çalışma mantığından bahsedelim biraz da. fail2ban, “jails” adı verilen bölümler kullanarak çalışır. Her jail, belirli bir hizmeti izler ve belirli bir filtre kullanır. Filtreler, genellikle regex (düzenli ifade) kullanarak log dosyalarını tarar ve kötü niyetli faaliyetleri tespit eder. Filtre kurallarını filter.d dizini altına filtre_adi.conf formatında dosyalar oluşturup bu dosyalara yazıyoruz. Hemen nginx için bir filtre oluşturalım, favori metin editörünüz ile filter.d dizini altında örneğin ddos.conf adında bir dosya oluşturalım ve bu dosyaya şunu ekleyelim;

[Definition]
failregex = <HOST> -.*”(GET|POST).*” 200
ignoreregex =

Bu filtre nginx access.log dosyasında belirli bir ifadeyi arıyor gördüğünüz gibi. Filtre kuralını ekledik, şimdi bu filtreyi kullanabilmek için jail.local dosyasını açalım ve en sona şu ifadeyi ekleyelim;

[ddos]
enabled = true
port = http,https
filter = ddos
logpath = /var/log/nginx/access.log
maxretry = 100
bantime = 3600
findtime = 60

Bu yapılandırmada:

  • enabled = true ifadesi, bu jail’i etkinleştirir.
  • port = http,https ifadesi, HTTP ve HTTPS portlarına gelen trafiği denetler.
  • filter = ddos ifadesi, ddos adında bir filtreyi kullanır.
  • logpath = /var/log/nginx/access.log ifadesi, Nginx log dosyasının yolunu belirtir.
  • maxretry = 100 ifadesi, bir IP’nin kaç kez başarısız deneme yapabileceğini belirtir.
  • bantime = 3600 ifadesi, IP’nin ban süresini (saniye olarak) belirtir.
  • findtime = 60 Bu süre zarfında belirtilen maxretry sayısının aşılması durumunda IP adresi engellenir. Bu örnekte 1 dakika (60 saniye) olarak ayarlanmıştır.

Bu jail kuralı access.log dosyasında 60 saniye içinde bir ip numarasından 100 adet istek tespit ederse o ip adresine 1 saat boyunca ban koyacaktır.

Bu noktaya kadar işin fail2ban kısmında çalıştık. Şimdi PF için bir kaç ayar yapmamız lazım. fail2ban bir aksiyonu nasıl yapacağına action.d dizinindeki dosyalara bakarak karar veriyor. PF ile ilgili bir ayar dosyası var ancak ben bunu kaldırıp yerine daha sade bir dosya koydum.

# cp pf.conf pf.conf.ori

pf.conf dosyasını açarak içerine şunları ekleyelim;

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = /sbin/pfctl -t <tablename> -T add <ip>/32
actionunban = /sbin/pfctl -t <tablename> -T delete <ip>/32
[Init]
tablename = fail2ban

jail.local dosyasında yapmamız gereken bir şey kaldı. Dosyayı açarak şu parametreleri bulun ve aşağıdaki gibi değiştirin;

banaction = pf[actiontype=<allports>]
banaction_allports = pf[actiontype=<allports>]

Hemen hemen hazırız. PF için bir kural eklememiz gerekiyor, /etc/pf.conf dosyasını açalım/yoksa oluşturalım ve içerisine uygun yerde olacak şekilde şu satırları ekleyelim;

table <fail2ban> persist

block in quick log on vmx0 from <fail2ban> to any

Lütfen vmx0 yazan yere kendi ağ arayüzünüzü yazın. Bu bilgiye ifconfig komutunu kullanarak erişebilirsiniz. Yapmamız gereken son şey /etc/rc.conf dosyasına gerekli satırları eklemek ve uygulamaları başlatmak. rc.conf dosyamızı açalım ve şu satırları ekleyelim;

fail2ban_enable=”YES”
pf_enable=”YES”
pf_rules=”/etc/pf.conf”
pf_flags=””
pflog_enable=”YES”
pflog_logfile=”/var/log/pflog”

Uygulamaları başlatalım;

# /usr/local/etc/rc.d/fail2ban start
# service pf enable

Bir sorun olmadı ise fail2ban nginx access.log dosyamızı izlemeye başlamış olmalı ve verdiğimiz kurala uygun ip numaralarına PF kullarak ban koymalıdır.  Sistemin çalışıp çalışmadığını anlamanın pratik bir yolu fail2ban-client ve pfctl komutlarını kullanmak. Aşağıdaki komut bize ban konuşmuş bir ip olup olmadığını verecektir;

# fail2ban-client status ddos

Bu komutun çıktısı şuna benzemeli;

Status for the jail: ddos
|- Filter
| |- Currently failed: 2
| |- Total failed: 107
| `- File list: /var/log/nginx/access.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:

Gördüğünüz gibi şu anda sistem henüz hiç bir ip ye ban koymamış. Bu listede “Banned IP list” alanında gördüğünüz ip numaralarını şu komutu verdiğinizde de görüyorsanız her şey yolunda demektir;

# pfctl -t fail2ban -T show

Bu komut da o anda PF tarafından fail2ban tablosunda engellenmiş olan ip numaralarının listesini verecektir. Önceki komuttaki ip ler ile bu listedeki ip ler bire bir birbirini tutuyorsa sistemi düzgün şekilde konfigüre etmişsiniz demektir.

Sonuç olarak; fail2ban pek çok yerleşik filtre ile birlikte gelen sizin de yeni filtreler oluşturabileceğiniz, hayal gücünüz ile genişleme kapasitesine sahip güzel bir güvenlik aracı. Umarım makale faydalı olmuştur.

Saygılarımla..


Herkese Merhaba,

Bugün sizlere pfx uzantılı dosyalardan bahsetmek istiyorum. pfx uzantılı dosyaların kısa bir tanımı ile başlayıp bu dosya ile neden çalışmam gerektiğini ve üzerinde yaptığım işlemleri ileride yine lazım olur diyerek kayıt altına almak isterim. pfx nedir, ne işe yarar, nerelerde kullanılır gibi sorularla başlayalım;

PFX dosyası (Personal Information Exchange), bir sertifika dosya biçimidir ve genellikle .pfx veya .p12 uzantısıyla kullanılır. Bu dosya türü, dijital sertifikalar ve özel anahtarlar gibi güvenlik bilgilerini saklamak ve taşımak için kullanılır. PFX dosyası genellikle aşağıdaki bileşenleri içerir:

  1. Dijital Sertifikalar:

    • Bu sertifikalar, kimlik doğrulama ve güvenlik için kullanılan genel anahtarları içerir. Bir sunucu veya istemcinin kimliğini doğrulamak için kullanılır.
  2. Özel Anahtarlar:

    • Özel anahtarlar, dijital imzaların oluşturulması ve şifreleme/deşifreleme işlemleri için kullanılır. Bu anahtarlar gizli tutulmalı ve yalnızca yetkili kişiler tarafından erişilebilir olmalıdır.
  3. Kök ve Ara Sertifikalar:

    • Kök sertifikalar, güven zincirinin en üstündeki sertifikalardır ve genellikle bir sertifika otoritesi (CA) tarafından imzalanmıştır. Ara sertifikalar ise kök sertifikalar ile son kullanıcı sertifikaları arasında bir köprü görevi görür.

PFX Dosyasının Kullanım Alanları

  1. Sunucu Kimlik Doğrulaması:

    • Web sunucuları (örneğin, HTTPS üzerinden erişilen web siteleri) genellikle SSL/TLS sertifikalarını kullanarak kimliklerini doğrular. PFX dosyası, bu tür sertifikaları ve özel anahtarları tek bir dosyada saklayarak sunucu yapılandırmasını kolaylaştırır.
  2. İstemci Kimlik Doğrulaması:

    • İstemci sertifikaları, istemcilerin (örneğin, bir web sitesine erişen kullanıcıların) kimliklerini doğrulamak için kullanılır. PFX dosyası, bu sertifikaları ve özel anahtarları içererek güvenli erişimi sağlar.
  3. E-posta Güvenliği:

    • S/MIME protokolü ile e-postaların şifrelenmesi ve dijital olarak imzalanması için sertifikalar kullanılır. PFX dosyası, bu sertifikaları ve özel anahtarları saklayarak e-posta güvenliğini artırır.

PFX Dosyasının İçeriğini İncelemek

PFX dosyasının içeriğini incelemek ve sertifika bilgilerini görüntülemek için openssl gibi araçlar kullanılabilir. Örneğin, aşağıdaki komut ile bir PFX dosyasının içeriği görüntülenebilir:

Bu dosyalar genelde IIS üzerinde SSL tanımlaması için kullanılıyorlar. Bana da böyle bir sunucudan alınarak verildi ve Nginx üzerinde kullanmam gerekti. Bunu yapmak için fullchain.pem ve privkey.pem dosyalarını pfx dosyasından çıkartmak gerekiyor. Şimdi bu işlemi OpenSSL ile nasıl yapabileceğimizi görelim. İhtiyacımız olan şeyler pfx dosyası ve bu dosyanın varsa şifresi. Linux/Unix makinemizde komut satırına giderek şu komutu veriyoruz;

# openssl pkcs12 -in dosya.pfx -out fullchain_and_key.pem -nodes

Bu komut pfx dosyamız şifrelenmiş ise bizden şifre isteyecektir. Şifreyi girip işlemi tamamladığımızda çalışma dizininde fullchain ve privkey bilgilerini taşıyan fullchain_and_key.pem isimli bir dosya oluşacaktır. Bu dosyadan ihtiyacımız olan iki pem dosyasını elde edelim şimdi de;

# openssl pkey -in fullchain_and_key.pem -out privkey.pem

# openssl crl2pkcs7 -nocrl -certfile fullchain_and_key.pem | openssl pkcs7 -print_certs -out fullchain.pem

Evet pfx dosyamızdan fullchain.pem ve privkey.pem ayrılmış oldu. Bu iki dosya ile Apache ve Nginx üzerinde SSL ayarlamalarınızı yapabilirsiniz.

Saygılarımla..

 


Merhaba,

Bugün sizlere ZFS dosya sisteminin yeni fark ettiğim bir özelliğinden bahsetmek isterim. Anlamam tesadüfen oldu, muhtemelen ZFS uzmanları anlatacağın şey bu mu diyebilir lakin bulduğum ana kadar durum çok gizemli idi :) Sanallaştırılmış FreeBSD sunucularımda boş disk alanının sürekli azalması dikkatimi çekmiş idi. Bu durumu ilk önce freebsd-update ile sistemi güncelleyeceğim zaman fark etmiştim. Diskte yeterli alan olmaması nedeni ile işlem tamamlanmayınca gerekmeyen dosyaları silerek yer açmaya çalıştım. İlk etapta bunda başarılı da oldum. Gereksiz log dosyaları, pkg dosyaları vb. silerek belli bir alan kazanabildim. Ancak ilerleyen zamanda boş disk alanı yine azaldı ve daha önce kullandığım yöntemler bu sefer işe yaramadı. Duruma anlam veremediğim için çareyi sanal disk boyutunu büyütmekte buldum. Ancak boyutu büyütülmüş sanal disk bile bir süre sonra dolmaya başladı. Diski dolduran şeyin ne olduğunu tesadüf eseri öğrendim. ZFS dosya sisteminin belli aralıklarla aldığı "snapshot"lar diskin dolma nedeni.

ZFS snapshotlar nedir? ZFS snapshotlar, dosya sistemince oluşturulan ve dosya sisteminin belli bir andaki anlık görünümü olarak özetlenebilir. Veri kurtarma veya sistemin eski bir andaki durumuna geri dönme gibi senaryolarda yararı olan bir özellik. Ancak bu yararlı özellik siz fark etmeden diskinizi doldurmaya devam ediyor. İşe yaramayan snapshotları temizlemek diskte alan açmanızı sağlayabilir. Öncelikle sistemimizdeki snapshotları listeleyelim, bunun için;

# zfs list -t snapshot

Bu komutun şunun gibi bir çıktısı olacaktır;

NAME USED AVAIL REFER MOUNTPOINT
zroot/ROOT/default@2022-11-12-11:57:51-0 478M - 4.43G -
zroot/ROOT/default@2022-11-18-12:00:56-0 145M - 4.41G -
zroot/ROOT/default@2022-12-01-10:20:54-0 241M - 4.41G -
zroot/ROOT/default@2023-02-20-12:02:29-0 930M - 4.64G -
zroot/ROOT/default@2023-08-16-15:59:50-0 186M - 2.71G -
zroot/ROOT/default@2023-09-02-19:32:52-0 7.60M - 4.08G -
zroot/ROOT/default@2023-09-02-19:34:51-0 4.49M - 4.16G -
zroot/ROOT/default@2023-10-05-13:48:35-0 172M - 4.32G -
zroot/ROOT/default@2023-11-20-10:22:20-0 142M - 4.33G -
zroot/ROOT/default@2023-12-12-15:57:14-0 16.7M - 4.41G -
zroot/ROOT/default@2023-12-14-19:06:07-0 9.52M - 4.47G -
zroot/ROOT/default@2024-01-02-10:23:20-0 290M - 4.50G -
zroot/ROOT/default@2024-02-20-15:32:53-0 785M - 4.86G -
zroot/ROOT/default@2024-04-02-10:10:08-0 537M - 2.83G -
zroot/ROOT/default@2024-05-16-10:03:23-0 7.12M - 4.79G -
zroot/ROOT/default@2024-05-16-10:06:06-0 0B - 4.87G -
zroot/ROOT/default@2024-05-16-10:06:19-0 0B - 4.87G -
zroot/ROOT/default@2024-05-16-12:04:25-0 307M - 5.05G -

Gördüğünüz gibi ZFS tarafından oluşturulmuş pek çok snapshot dosyası var, dosyaların disk üzerinde kapladığı alan da muhtelif. Şimdi bu snapshotların tümünü veya istediklerinizi nasıl temizleyeceğinizden bahsedelim. Kullanılacak komuttan bahsetmeden önce bir uyarı! Az sonra yapacağımız snapshot silme işlemi geri dönüşü olmayan bir işlem, lütfen ihtiyacınız olan bir snapshot üzerinde silme yapmadığınıza emin olun.. Tüm snapshotları temizlemek isterseniz şu komutu verin;

# zfs destroy -R zroot/ROOT/default

Ben listeden sadece istediğim snapshotları sileceğim derseniz kullanmanız gereken komut ise şu;

# zfs destroy -R zroot/ROOT/default@2022-11-12-11:57:51-0

"zfs destroy -R" ifadesinden sonra silmek istediğimiz snapshotın adını yazıyoruz. -R parametresi recursive olarak bu snapshot ile ilgili klonlar varsa onları da siliyor. Şimdi temizlik öncesi ve sonrası zpool list komutu çıktılarına bakalım. Snapshotları silmeden önce diskin durumu şöyle idi;

# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 22.5G 20.5G 2.03G - - 79% 90% 1.00x ONLINE -

Temizlik sonrasında ise;

# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 22.5G 9.06G 13.4G - - 49% 40% 1.00x ONLINE -

Gördüğünüz gibi boş disk alanında bir hayli artış var.. Siz de FreeBSD sisteminizde anlam veremediğiniz disk alanı azalması yaşıyorsanız ZFS dosya sisteminin snapshotlarını bir kontrol edin.

Saygılarımla..

 


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..


Author Name

İletişim Formu

Ad

E-posta *

Mesaj *

Blogger tarafından desteklenmektedir.