Mac OS X Nginx PHP 5.3 ve percona-server (mysql) kurulumu

Bu yazıda Mac OS X üzerine Nginx ve PHP5.3 (özellikle php5.3, daha yenisi değil) kurmayı anlatmaya çalışacağım.

İnternetteki dökümanlar genelde konu güncel iken yazıldığı için, siz bir yazılım dilinin daha önceki versiyonlarına ait kurulumlar yapmak istediğinizde, varsayılan paket yöneticisi tarafından hep en son sürümü kurulmakta, ve bu da bizim o anki ihtiyaçlarımızı karşılamamaktadır.

Ben de birkaç tane projedeki php 5.3 gereksinimim sebebiyle böyle bir şey yapmak durumunda kaldım. (aslında vagrant daha güzel bir çözüm tabi ki dileyen araştırabilir.)

Öncelikle Mac’inizde homebrew (http://brew.sh/) yüklü değilse, bunu yüklememiz gerekiyor. Bunun için konsolunuzda

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

komutunu çalıştırmanız gerekiyor.

Nginx kurulumu

brew install nginx

Bu kadar basit 🙂
Nginxi başlatmak için

nginx

komutunu yazmanız yeterli. (Evet konsola sadece nginx yazacağız, ubuntu gibi değil) Ancak sudo olarak çalıştırmanız gerekebilir.
Php kurulumu

php yi Nginx ile iletişim kurabilmesi için 2 şekilde kurabiliriz. 1. yöntem cgi ile. 2. yöntem ise, php-fpm ile. php-fpm ile kurmak daha mantıklı, çünkü fcgi process manager ile yönetilmeyen bir cgi kullanımı aynı anda çok fazla processi handle etmenizi yani stress test vb toolları çalıştırdığınız kısımlarda size problem çıkartabilir. Ben de bu ve birkaç sebepten dolayı php-fpm ile kurmayı anlatacağım. Ancak cgi ile kurmak isteyen için de sadece 1 parametre değişiyor 🙂

brew install php53 --with-mysql --with-suhosin --with-intl --with-imap --with-fpm

sondaki —with-fpm kısmı yerine –with-cgi yazarsanız da cgi ile kurmuş olursunuz.

Mac OS X içerisinde PHP, Ruby, Python gibi dillerin CLI (konsol üzerinden çalıştırılabilir) versiyonları ile birlikte geldiği için şu anda halen konsolda php -v yazdığınızda php 5.4.24 veya benzeri başka bir versiyonu görürsünüz. Ancak web arayüzünden (Yani browserdan nginx ile) girdiğinizde ilgili php 5.3 sürümünü çalıştırmış olacağız.

Eğer siz konsoldan da php 5.3 çalıştırmak istiyorsanız,

export PATH=/usr/local/Cellar/php53/5.3.28/bin:$PATH

şeklinde komut çalıştırmanız gerekiyor. (sudo ile çalıştırmanız icap edebilir).
Ancak bu şekilde yaparsanız da bilgisayarınızı yeniden açtığınızda (ya da konsoldaki oturumu kapattığınızda) bu ayar kaybolacaktır. Bunu kaybetmemek için bu komutu /usr/local/Cellar/php53/5.3.28/bin i sudo ile /etc/paths e yazmalısın.

Mac OS X üzerinde php-fpm ubuntudaki gibi /etc/init.d/php-fpm start stop, vb.. şeklinde kullanılamıyor. Bu yüzden kullanımı biraz farklı.
Php-fpm yi hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.php53.plist

Bilgisayarınız her açıldığında otomatik başlasın istiyorsanız da

ln -sfv /usr/local/opt/php53/*.plist ~/Library/LaunchAgents

şeklinde işlem yapmanız gerekiyor.

Şimdi sıra php-fpm.conf dosyasını bulup, buradaki ayarlardaki loglara veya dosyalara izin vermek kısmında.
php-fpm.confu bulup ilgili pid ve log dosyasını ve access log dosyasını yazabilmesi için yetki vb verip o gerekli klasörleri oluşturursan gerisi tamamdır. (Yine ubuntunun aksine, /var/run/php-fpm.pid yerine phpnin kendi klasörüne yapmanız daha mantıklı olacak ben bu şekilde yaptım. Log için de aynı yeri belirttim.)

 

percona-server kurulumu

Nginx kadar basit aslında.

brew install percona-server

Percona server’i hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.percona-server.plist

Bilgisayar her başladığında başlatmak için ise,

ln -sfv /usr/local/opt/percona-server/*.plist ~/Library/LaunchAgents

komutlarını çalıştırmanız gerekiyor.

Bu yazı nginx ayarları, php ayarları ve mysql ayarlarının nasıl yapıldığı ile ilgili olmadığı için o detayları burada paylaşmıyorum. Ancak ihtiyacı olan tabi ki danışabilir.

Umarım yararlı olur.

wordpress guncellemesinde temporary failure in name resolution hatasi

Bir süredir yeni yazı eklemiyor ve yorumları kontrol edemiyordum. Bunun sebebi php’nin cgi fonksiyonları üzerinde başlıkta belirttiim temporary failure in name resolution hatasını almamdan dolayı olduğunu keşfettim.

Hata ilk oluştuğunda wordpressimi bir süredir güncellemediğimi farkettim. Güncellemek için ilgili menüye geldiğimde bana bu hatayı verdi. Oldukça fazla vaktimi aldı aslında çözmek. Çünkü apacheyi yeniden başlatmak aklıma gelen ilk çözümdü ve bu çözmemişti durumu. (Ayrıca Jetpack, akismet gibi çok işe yarar eklentilerim de kullanılamaz olarak dating age limits duruyordu. Fırsat bulmuşken inceleyip hatayı gidermek istedim. )

Akabinde bir çok debugdan sonra, apacheyi restart etmek yerine önce stop sonra start yapmayı akıl edebildim. Nitekim problem çözüldü. Php’nin dns resolve işlemleri bir şekilde işletim sistemi ile haberleşemiyordu, ve eski php sürümlerinde bu tarz şeyler sıkça olabiliyordu 🙂

Hata gerçekten dns resolve işlemini (sunucunuzun dns ayarları) ile ilgili olabiliyor. Ben de ağırlıklı olarak buraya yoğunlaştım. Ancak benim problemimimin çmzümü apacheyi stop ve sonrasında start etmek idi.

Yaşayan vardır diyerekten uzun süren mecburi sessizliğimi bu yazıyla bozuyorum.

Sayısal Veri İçeren Karakter Alanlar

Oracle veri tabanında, sayısal veri içermesi beklenen karakter tipinde (CHAR,VARCHAR) alanlar sorun yaşamak için birebirdir. Örneğin müşteri numarası tutulan bir alana, servis ve grafik arayüz seviyesinde yeterli kontroller yapılmazsa müşteri adı, soyadı..vs gibi bilgiler yazılıyor olabilir 🙂 Bu alanda to_number() kullanarak bir sorgu yazdığınızda ve ya tabloyu bu alan üzerinden başka bir tablodaki nümerik bir alana bağlamak istediğinizde ORA-01722 hatası alırsınız.

Alanın yer aldığı tablodaki satırları düzeltmek için hangisinde hata olduğu bulmak da ayrı bir sorundur. Bunun için UPPER () ve LOWER () metotlarını kullanabilirsiniz. UPPER () ve LOWER () metotları numerik değerler için aynı, karakter değerleri için farklı sonucu vereceğinden, hatalı satırlara ulaşabilirsiniz. Diyelim ki tablomuzun adı MUSTERI, alanın adı MUSTERINO olsun:


CREATE TABLE MUSTERI
(
RECORDOID NUMBER(16) NOT NULL,
MUSTERINO VARCHAR(10) NOT NULL,
MUSTERIADI VARCHAR(10) NOT NULL
);

Tabloya bazı kayıtlar atalım:


Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(4, '!', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(3, '-', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(2, 'bogac', 'aslan');
Insert into MUSTERI
(RECORDOID, MUSTERINO, MUSTERIADI)
Values
(1, '100', 'bogac');
COMMIT;

Tabloyu yarattıktan sonra geçersiz değerler içeren satırları bulalım:


SELECT *
FROM MUSTERI M
WHERE UPPER(M.MUSTERINO) != LOWER(M.MUSTERINO)

Bu çözüm UPPER ve LOWER metotlarında aynı sonucu veren bazı diğer karakterler (“!”,”-” gibi) için yeterli olmayabilir, sadece bu karakterleri içeren satırlar olduğundan şüpheleniyorsanız ek sorgular yazmak gerekebilir. Sorunla Oracle veri tabanında karşılaşmış olsam da, diğer veri tabanı sistemleri için de çözüm olacağını düşünüyorum.

Kolay gelsin 🙂

mysql_real_escape_string DBAL dengi (equivalent)

Benim gibi projenizde bir altyapı değişikliği yapıyorsanız, muhtemelen yeniden ele aldığınız kısımlardan biri de veritabanı bağlantısı ile ilgili kısımlar oluyor. Biz de bu noktada Doctrine DBAL kullanmaya karar verdik. Henüz ORM implemente etmek için yolumuz var. O yüzden sadece DBAL katmanını kullanacağız. Ancak burada mysql_real_escape_string vasıtası ile escape ettiğimiz verileri, artık DBAL tarafına geçerken birsürü yerde replace işlemi yapmak istemiyorsanız birkaç önerim olacak.

mysql_Real_Escape artık projenizde düzgün çalışmayacaktır diye tahmin ediyorum. Çünkü artık classlar üzerinden çalışıyorsunuz, ve buradaki mysql doğru connectionı bulamayabilir. (özellikle master slave ilişkili çift veya daha fazla db mimarisinde)

Tabi ki işin doğrusu statement->prepare metodu üzerinden bindParam veya bindValue ile ilerlemek. Ancak bunları için oldukça uzun bir vakit gerekebilir.

Biz de mysql_real_escape_string’in karşılığı olarak bir metod bulduk. Connection nesnesi üzerinde bulunan quote metodu.

 

$conn->quote(”) dediğimiz metod tam da istediğimiz şekilde çalışıyor. Hatta connection objesindeki ekstra parametreler kısmına ATTR_EMULATE_PREPARES=> true verirseniz, bu metod bildiğiniz mysql_Real_escape işlemini yapıyor. bu parametredeki tek handikap, çoklu querylerin tek seferde çalıştırılamaz hale gelmesi oluyor.

quote’un mysql_Real escape’ten tek farkı başına ve sonuna bir tırnak koyuyor. siz bunları substr ile çıkartırsanız birebir aynı olacaktır.

 

dikkat etmeniz gereken bir şey de şu ki, mysql server’ınızın encoding’i ile (server encodinginizin mysql e bağlanıp show variables like ‘%char%’ seklindeki degisklenlerden gorebilirsiniz) connection (DBAL ayarlarından verilen encoding) aynı olması gerkeiyor ki güvenli bir escape işlemi yapılabilsin.

Cpanel Nginx Admin Plugin Bandwidth problem

Cpanel’inizi nginx admin plugini ile birlikte kullanıyorsanız, bu noktada, bandwidth hesaplamalarında bir saçmalık oluyor(access_log’ları epey eksik yazıyor). Sebebi de, Cpanel’in logrotate işlemi sonrasında nginx üzerinden tıpkı apache gibi yapılan loglama işlemleri için belleğinde tuttukları file descriptor’ların (dosya tutucu pointer diye düşünebilrisiniz) rotate işlemi sonrasında kaybolmasından kaynaklanıyordu.

Çözümü için logrotate işleminin akabinde çalışacak bir hook eklemeniz gerekiyor. Bu hook nginx’i reload etmesi yeterli oluyor. (restart’a gerek yok)

İşyerinden bir arkadaşım durumu tespit etmişti, bana da yazmak düştü.