Systemd Öncesi init ve runlevel’lar

Bilindiği gibi Linux sistemlerde sistem açılışında runlevel dediğimiz sistemin sunacağı hizmetlere göre yapılandırıldığı çalışma seviyeleri mevcuttur. Basitce windows sistemlerde Safe mode ile girdiğimiz ve sistemlerin tekli kullanıcı moda’ta sorunları çözebileceğimz şekilde de Linux işletim sisteminde RunLevel ‘lar günlük hayatımızda karşımıza çıkar.

Linux dünyasında RunLevel’lar değişik dağıtımlarda farklı işlevlere sahip olabilmektedir. Bu yazımızda daha çok Red Hat bazlı (Centos,OEL vs) işletim sistemlerin RunLevel’ları anlatılacaktır. Bu RunLevel’lar eskiden init dediğmiz ve işletim sistemi kernel yüklemesinden sonra çalışan ve PID (Process ID) 1 olan süreçlerle yönetilmekte idi.  init süreci /etc/inittab dosyasını okuyup sistemin hangi Run Level’dan başlayacağına karar verirdi. Aşağıda /etc/inittab dosyasından bir kesit sunulmaktadır.

Buradaki  id:3:initdefault: satırı bizim işletim sistemimizin RunLevel 3 ‘den başlayacağını göstermektedir. Red Hat sistemlerde RunLevel’lar

·        0 - halt (Sistemi kapatmak –poweroff veya halt- için kullanılan runlevel)

·        1 - Single user mode (Sistemi kurtarmak için kullanılan ve network ayarlarının aktive edilmediği tekli kullanıcı mode’u. Bazı yerlerde S veya s olarak da adlandırılır.

·        2 – Multiuser  NFS olmadan çoklu kullanıcı mode’u (Bu runlevel 3. Runlevel ile genel olarak aynıdır. Tek fark network ayarlarını içermemesidir.)

·        3 - multiuser mode (Network ayarlarını nda aktive edildiği ve genellikle kullanılan RunLevel’dır.

·        4 – kullanılmıyor.

·        5 - X11 (Runlevel 3 e ek olarak görsel ekranın- ki biz buna X veya X11 de deriz- da başlatıldığı runlevel. Runlevel 3’den sonra en çok tercih edilen runlevel’dır.)

·        6 - reboot (Sistemin kapatılıp tekrar açıldığında kullanılan RunLevel’dır.

İnit süreci ön tanımlı runlevel’ı ayarladıktan sonra sistemde /etc/rc.d/init.d/ altında bulunan  ve rpm paketleri içinde gelen servis scriptlerini (bunlar bir shell scripttir!) çalıştırır. Örnek olarak eğer runlevel 3 de isek ve sshd servisi çalışacaksa bunun başlangıç scripti /etc/rc.d/init.d/sshd altında yer almakta. Bunun runlevel 3 de çalışmasını da /etc/rc.d/rc3.d/S55sshd scripti sağlamakta idi. Buradaki S harfi bunun start edilleceği, 55 ise başlangıç sırasını belirtmektedir.

Systemd Tarihçesi ve init ‘e göre avantajları

Linux sistemlerde yaygın olarak kullanılmaya başlayan systemd  30 Mart 2010’da  Lennart Poettering  ve Kay Sievers tarafından init sisteminin alternatifi olarak yazıldı.Bu yapı yeni Linux sistemleri ile (RedHat tabanlı sistemlerde RHEL 7 ile, SLES’de SLES 12 de, Debian da Debian 8 ile) yerini systemd ye bıraktı. Her ne kadar systemd üzerinde tartışmalar devam etse ve bazıları UNIX felsefesine aykırı da bulsa systemd’nin önümüzdeki yıllarda daha fazla kabul göreceği de düşünürsek systemd’yi önyargısız olarak inceleyip,öğrenmekte fayda var.

Diğer dağıtımlardaki durumuna https://en.wikipedia.org/wiki/Systemd adresindeki “Adoption and reception”  kısmından da erişilebilen systemd  nin genel olarak şu avantajları mevcuttur.

1.     SysV init script’leri ile tam uyumludur. Init.d altındaki scriptleri de çalıştırabilir.

2.     Serivslerin parallel olarak başlatılabilmesi (dolayısıyla daha hızlı sistem açılışı ve kapanışı)

3.     Servislerin on-deman aktivasyonu. Yani bir servisi başlatırken onun ihtiyacı olan diğer servislerin de otomatik başlatılması

4.     Sistem servislerinin snapshot’ının alınabilmesi (Yani basitçe ifade ile kendi runlevel’larınızı oluşturabilme diyebiliriz buna)

5.     Servis bir şekilde ölürse bunun tesbiti ve ilgili servisin tekrar başlatılması

Systemd Bileşenleri

Systemd unit adı veridğimiz bileşen ve bunların kendi arasındaki ilişkilerinden oluşmaktadır. Systemd  binary’si /usr/lib/systemd/systemd dosyası olarak sistemde bulunmakta ve systemd rpm paketi tarafından kurulmaktadır. Systemd binary’si eski yapıdaki /sbin/init programının yerini alır. Şu an için RHEL 7 ‘de zaten /sbin/init tam manasıyla /usr/lib/systemd/systemd dosyasına bir linktir.

Systemd Önemli Dizinler

Az önce bahsettiğimiz gibi systemd bileşenleri unit yapılandırma dosyalarından oluşmaktadır. Bu yapılandırma dosyaları sadece servisler için değil runlevel’ların yerini alan target (evet artık runlevel yerine target’lar var. Yazınının ilerleyen kısımlarında bunlardan da bahsedeceğiz) lar, mount edilecek bileşenleri içeren kısımlar ve birçok bileşenden oluşabilmektedir. Bu dosyalar /usr/lib/systemd/system dizini altında şu uzantılarla yer alabilmektedir.

Yukarıda tipleri verilen unit dosyalarından en önemlileri ve günlük hayatta en çok kullandığımız bileşenler servisler ve target’lardır.  Uzantısı .service olarak bildirilenler servisleri (Ör: sshd.service), uzantısı .target olanlar ise Target’ları yani eski adı ile runlevel’ları (Ör: multi-user.target) oluşturmaktadır.

Systemd Komutları

Systemctl

Sistem servislerini yönetmek için kullanılan komutlar eskiden (RHEL 7 öncesi) chkconfig  ve service komutları idi. Chkconfig bir servisi enable/disable etmek için kullanılırken, service komutu ilgili servisi start/stop/restart işlemleri için kullanılırdi. Yani ilgili runlevel’da bir servisi açıp,kapamak için chkconfig komutu kullanılırken ayrıca bir de service komutu ile servisi start etmek gerekiyordu. Systemd ile gelen tek bir komutla yanı systemctl komutu ile artık bu iki işlev birleştirildi. Yani artık servislerin enable,disable edilmesi ve stop/start işlemleri systemctl komutu ile yapılabilir hale geldi.

Eski yapıya bir örnek vermek gerekirse önceklike bir servis enable ediliyordu chkconfig komutu ile

Daha sonra ilgli servis start ediliyordu:

Şimdi bu işlemi sadece systemctl komutu ile yapıyoruz.

Sshd servisi veya unit dosyası tek olduğu için ve o da bir servis olduğu için .service kısmını yazmamıza gerek bulunmamakta. Zaten sshd yazıp TAB tuşuna bastığınızda shell bizim için otomatikman bunu sshd.service olarak tamamlayabilmektedir.  Diğer systemctl komutları şu şekildedir. Aşağıda eski sistemlerde kullanılan service ve chkconfig komutları karışılığı da ayrıca verilmiştir.

Örnek kullanım. Aşağıda sshd servisi disable edilip stop edildikten sonra (Disable edien servis stop edilmez!. Stop komutu ile ayrıca servis durdurulmalıdır. Yine aynı şekilde enable edilen servis start edilmez, start komutu ile başlatılmalıdır)

Target’lar (Eski adı ile Runlevel’lar)

System yapısı ile artık runlevel’lar yeni bir isim aldı. Değişik servislerin birleşmesi ile oluşan runlevel’lara artık target ismi verilmektedir. Bu runlevel’ların geriye dönük isimlendirilmeler korunsa da uzun vadede bu takma adlar (aliaslar) kaldırılacaktır. Eskiden 0-6 arası runlevel’lar varken yeni yapıdaki target’lar şu şekildedir.

Örnek kullanımlar:

Öntanımlı sistemin çalıştığı target’I sorgulamak için:

Reboot sırasında sistemin sıfırdan açıldığı target değiştirmek için (aslında yapılan bir link işlemi)

# systemctl set-default multi-user.target

rm '/etc/systemd/system/default.target'

ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

Sistem çalışırken bir anda farklı bir target’a geçmel için ( eskiden init 3 ile yapılan işlem)

 # systemctl isolate multi-user.target

Ayrıca bunlara ek olarak systemctl poweroff, systemctl reboot , systemctl halt komutları da kullanılmaktadır. Zaten bu 3 komutta artık systemctl komutuna bir linktir.

Unit dosyaları

Şu ana kadar anlattığımız üzere  bütün servis ve target’lar aslında /usr/lib/system/system altında bulunan dosyalardan oluşmaktadır. Örnek olarak sshd.service dosyasının içine bakarsak:

/usr/lib/system/system/sshd.service

Burada görüldüğü gibi bir unit file içinde  ini dosyalarına benzer bir format bulunmaktadır. Burada Unit, Service ve Install ana  başlıkları mevcuttur.

Unit kısmında Description,After ve Wants kısımları servisin açıklamasını, Servisin hangi servislerden sonra başlatılması gerektiğini ve servisin hangi servisin de başlatılmış olduktan sonra başlatıldığı göstermektedir.

Service kısmında servisi start stop etmek için asıl parametreler yer almaktadır. Burada RestartSec kısmı önemlidir. Mesela olursa servis bir şekilde ölürse systemctl bu servisi 42 sn sonra tekrar başlatmaktadır.

Son kısım Install kısmı ise servisin runlevel3 yani yeni adı ile multi-user.target tarafından servis kurulumu aşamasında ihtiyaç duyulduğu manasına gelmektedir.

Journalctl komutu

Systemd altyapısı loglarını journal denen formatta /run/log/journal/ dizinine atmaktadır. Aslında tıpkı systemd, init altyapısını nasıl değiştirdiyse ileride systemd-journald servisi de rsyslog altyapısını değiştirebilir. Tabiki şu an için bu sadece tartışılan bir konu ama ileride olması olası. Peki neden?  Buradaki amaç logların indexlenerek , binary bir dosyada saklanması ve istenen log satırlarının komutlarla hızlıca bulunması (normalde syslog loglarını grep veya tail –f ile incelemekteyiz). Tabiki bu olur mu bilmiyoruz ama şu an için diyebileceğimiz

1.      Systemd logları journald vasıtasıyla tutmaktadır.

2.      Bu loglar /run/log/journal dizininde bulunmakta ve her sistem reboot edilişinde tekrar oluşturulmaktadır

3.      Eğer bu log dosyalarının kalıcı olması isteniyorsa /var/log/journal dizini oluşturulup ilgili systemd-journald servisi tekrar başlatılmalıdır. (systemctl restart systemd-journald.service)

4.      Journald loglarını görmek için ve loglarda arama yapmak için journalctl komutu kullanılır.

Örnek journalctl komutu kullanımı:

Sistem boot ettikten sonraki bütün journal loglarını görmek için:

Sadece belirli prioritydeki logları görmek için. Mesela error seviyesindeki

Tail –f komutundaki gibi yeni gelen logları takip için:

Belirli bir tarihten sonraki logları görmek için:

# journalctl-p warning--since="2015-9-16 23:59:59"

Yararlı sayfalar:

http://www.freedesktop.org/wiki/Software/systemd/

https://access.redhat.com/articles/754933

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Services.html

http://0pointer.de/blog/projects/why.html

Bu makale serimizde sizlerler birlikte Linux üzerine incelemelerde bulunacağız. Öncelikle bilmemiz gereken Linux sürümleri 2 adettir. İ386 32bittir.  X86_64 ise 64 bittir.

Hızlı ir biçimde kurulum adımına geçelim.

Install or upgrade an existing system seçip ilerliyoruz.

Bu ekran cd test ekranıdır. Cdnizde emin değilseniz buradan test ettirebilirsiniz.Skip seçeniğini tıklayın.

Karşılama ekranını ilerleyin.

Dil ayarını seçin.

Klavye ayarını seçin.

Disk ayarları ekranıdır. Gelişmiş ayarlarıyla yapmak için alt kısımdakini seçip ilerliyoruz.

Diski seçip ilerleyin.

Yes ile diksin tamamını formatlarız.

Makina adını verin. Configure Network tıklayın, burada bir ayar yapacağız bu ayar önemlidir.

Defaultta NIC’i tanımaz bu nedenle system eth0 editlenip, connect automatically seçeneğini işaretliyoruz. Onaylayıp çıkıyoruz.

Time zone ayarlarında İstanbul’u seçin.

Root parolasını verin.

Burası partition bilgilerini olduğu kısımdır. Use all space seçersek sistem kendi oluşturur. Kendimiz özel partition yapacağımız için Create Custom Layout seçip ilerliyorum.

Sda birinci diski temsil eder. Eğer farklı bir diks daha olsaydı sdb,sdc şeklinde gidecekti. Create tıklayın.

Standart partiton seçip, create tıkla.

Root yani / partitionunu oluşturuyoruz. Windowstaki windowsa denk gelir.

Yeni bir parititon oluşturuyoruz. Burada file system type swap seçiyoruz. Bu windowstasi page filea denk gelir.

Boot partitionunu oluşturuyoruz.

/backup diye ayrı bir partition oluşturuyoruz. Fill to maximum allowable size seçeneği ile kalan tüm boş alanı buna veriyoruz.

Tüm partition ayalarını yaptık. Next ile ilerleyip Write changes to diski seçiyoruz.

Kurulacak paketleri seçin ilerleyin.

Kurulum işleminin bitmesini bekleyin. Kurulum bittikten sonra Application / System Tool / Terminal tıklayın.

İfconfig komutunu verin ve putty ile bağlantı sağlayın.

/bin : Temel komutları içinde barındırır.

/boot :  Konfigürasyon dosyaları burada tutulur.

/dev :  Hardware ile software bağlantıları burada tutulur.

/etc : Linux yapılandırma dosyaları buradadır. Apache server, Dns server gibi

/home:  Kullanıcı profilleri buradır.

/lib :  Kernel librarylar buradadır. Windowstaki .dll ler gibi.

/media : Cdrom, vs..

/mnt : Media gibi aynısıdır.

/opt: Opsiyonel paketler application yazılım paketleri burada tutulur.

/root :  root ana dizindir.

/sbin: Root kullanıcılarının kullanabileceği komutlara ait dosyalar.

/tmp : Herkesin kullanabileceği geçici dosyaların saklandığı dizindir.

/user : Uygulama programları dizinidir.

/var : Log dosylarıdır. Örneğin web sunucuya ait log dosyları

Faydalı olması dileğiyle.

Red Hat 7 ile hayatımıza gelen yeniliklerden biri de network ayarlarının yapıldığı yöntemlerin değişmesidir. Eskiden scriptlerle  düzenlenen ip ve interface ayarları RHEL 7 ile birlikte NetworkManager adlı servisle yönetilmeye başlandı. Aslında NetworkManager RHEL6 da da vardı fakat istendiğinde devre dışı bırakılabiliyordu nitekim çoğu Red Hat sistem yöneticisi de bunu tercih ediyordu.

Red Hat Enterprise 7 çıkması ile artık NetworkManager kullanmak ve öğrenmek kaçınılmaz oldu. Artık dosyaları editleyerek yapılan ayarlar da kalıcı olmamakta ve NetworkManager tarafından değiştirilmekte, üzerine yazılmaktadır. Peki RHEL7 de network ayarları için elimizde hangi komutlar var ve hangi dosyalarda neler var bunları sırasıyla görelim.

Hostname ayarlamak

Eskiden Red Hat sistemlerde hostname /etc/sysconfig/network dosyasına yazılırdı.Örnek vermek gerekirse RHEL7 öncesi

Şeklinde olurdu. Şimdi ise bu dosya tamamen geriye dönük uyumluluk için tutulmaktadır ve içeriği aşağıdaki gibidir.

RHEL7 ile artık hostname /etc/hostname dosyasına yazılmaktadır. Yine NetworkManager ‘da olduğu gibi artık hostname’de bir servis vasıtasıyla kontrol edilmektedir. Bu servisin adı systemd-hostnamed.service servisidir ve anlaşıldığı üzere systemd yapısının bir alt servisidir. İlgili servis hakkında bilgi almak için aşağıdaki komut verilir.

hostname ‘i ayarlamak,görmek için artık yeni bir komutumuz var. Bu komut hostnamectl komutudur. Bu komutta ise en çok kullanılan iki opsiyonumuz mevcut.

Hostname’i görmek için “ hostnamectl status”

Hostname’i ayarlamak için ise “ hostnamectl set-hostname <yeni_host_adi>“ kullanılır.

Üstteki komutta görüldüğü gibi /etc/hostname dosyası hostnamectl tarafından otomatik güncellenmekte ve hostname değiştirilmektedir. Burada önemli olan bir adım da sistem hostname’inin /etc/hosts dosyasından manual olarak güncellenmesi gerektiğidir zira hostnamectl /etc/hosts dosyasını güncellemez.

Interface isimleri

Eski RHEL bazlı sistemlerde ethernet kartları eth0,eth1…ethN olarak adlandırılırdı. Bu isimlendirme yapısında bir ethernet kartının sistemdeki hangi Pcı karta takıldığı veya fiziksel lokasyonunu bulmak oldukça zordu. Ayrıca ethernet kartlarının çok olduğu sistemlerde arasıra bu sıralama bozulduğu için sistemin erişilemez olduğu durumlarda olabiliyordu. Artık isimlendirme ve dolayısı ile ethernet kartlarının isimleri de değişmiş oldu. RHEL7 ile gelen udev alt sistemi ile ethernet kartlarının isimlendirmesinde firmware,topoloji ve sistemdeki yerine göre statik gib isimlendirme verilmesi sağlandı. Bu sayede ilgili kart sistemden çıkarılsa veya yeni bir kart takılsa bile isim çakışmasının önüne geçilmiş oldu. Tabi kabul etmek gerekiyor eski isimler çok daha kolaydı. Burada karşımıza yine systemd çıkıyor. Systemd  isimlendirme yaparken 5 değişik yöntem kullanmaktadır.  Red Hat bu isimlendirmeye consistent network device naming adını vermektedir. Bu isimlendirmeler 3 tip olmaktadır.

1. en:  Ethernet cihazları için
2. wl: Kablosuz cihazlar için
3. ww: Kablosuz WAN’lar için:

bu 3 önekten birini alan network kartlarının sonlarına şu şekilde isimlendirmeler yapılabilir:

/etc/sysconfig/network-scripts/ifcfg-*

Bu dosyalar önceki RHEL sürümlerinde olduğu gibi yine işlevseldir fakat bu dosyalar artık tamamen NetworkManager tarafından yönetilmvalekte ve bu dosyaların el ile değiştirilmesi kesinlikle tavsiye edilmemektedir. Artık kalıcı olarak network ayarlarını değiştirmek,düzenlemek için NetworkManager rpm paketi ile gelen nmcli konsol komutu tavsiye edilmektedir.

NetworkManager ve nmcli komutu

RHEL7 de aktif olarak kullanılmaya başlanan NetworkManager servisini yönetebileceğiniz ve IP yapılandırmasını yapabileceğiniz bir komut olan nmcli komutu ile ağ yapılandırmalarını yapabilirsiniz. Bu komut’un detaylarına girmeden önce  “device” ve “connection” arası ilişkiyi detaylandırmak gerekmektedir.  

Device kullandığımız fiziksel ağ arabirimi, connection ise bu ağ arabiriminde kullandığımız profil olarak tanımlanabilir. Örnek olarak laptop bilgisayarınızı hem evde hem de işte kullandığımızı farzedelim. Evde farklı bir networkünüz mevcuttur ve genelde dhcp’den IP aldığınız bir ortam olur. İşte ise statik bir IP aldığınızı ve bu IP adresini kullanıdığınızı düşünelim. Burada iki adet profil yani “connection” mevucttur ama bu iki profil de aynı ethernet kartını  yani “device” ı kullanmaktadır. NetworkManager bir device üzerinde aynı anda bir profilin aktif olduğu ama aynı cihaz üzerinde birden fazla profilin de (connection) olabileceği mantığı üzerine çalışmaktadır.

Örnek olarak sistemdeki device’ları görmek için:

Burada görüldüğü gibi 5 adet device mevcuttur. Bunlardan sadece enp0s3 ağa bağlıdır ve bir connection kullanır (burada connection adı da enp0s3 verilmiş yani device adı ile aynı connection adı kullanılmış). RHEL7 kurulumu sırasında ayarladığnız connectionları, device adı ile aynı yapmaktadır. Bu bir tercih meselesidir ama bir zorunluluk değildir. Burada /etc/sysconfig/netrwork-scripts/ifcfg-* dosyaların adlarının device’ı değil connection ‘u ifade ettiğinide ayrıca belirmek gerekiyor.

Sadece bir cihazın özelliklerini detaylı görmek için:

Burada görülen ayarların detaylı açıklamaları nm-settings man sayfasında genişçe yer almaktadır.

Bir device’ı  yönetimsel olarak (administratively) down veya up edebiliriz dolayısı ile onunla ilişkili connection’larda kapatılmış olur örnek vermek gerekirse:

Bu aşamaya kadar device’larla alakalı nmcli opsiyonlarını verdik. Bundan sonra connection ‘a yoğunlaşalım.

Dhcp’den IP alacak şekilde bir connection eklemek gerekirse:

Burada nmcli komutundan sonra uzunca “connection” yazabilirdik fakat yazımı kolay olsun diye “con” parametresini de kabul etmektedir nmcli komutu. Burada görüldüğü gibi bazı parametreler kullandık. Bunlar dhcp’den ip almak için kullanmamız gerken minimum parametreledir. Sırasıyla

·        con-name : Bağlantı adını ifade etmektedir. Bağlantı adında boşluk karakteri de kullanılabilir o yüzden tırnak işaretleri kullanılır. Her ne kadar biz burada boşluk karakteri kullanmasak da gösterim için tırnak işareti kullandık. Dikkat ederseniz burada device adı (enp0s3) ile connection adı (dhcpdenipal ) farklı oldu.

·        type : Bağlantının hangi topoloji türünü kullanacağını gösterir. Genelde ethernet tipi kullanılır.

·        İfname : Connection’un bağlanacağı arabirim belirtilir.

Eğer statik bir IP vermek isteseydik bazı ek parametreleri de kullanmamız gerekmektedir. Örnek kullanım

Üstteki dhcp profilne ek olarak kullandığımız yeni parametreler şunlardır.

·        autoconnect  [no|yes]:   Profiller  tanımlı olarak autoconnect yes olarak otomatik bağlanır ama unutulmamalıdır ki aynı anda sadece bir adet profil bir interface için aktif olablir.

·        ip4: Vereceğimiz ip adresi burada belirtilir. Burada unutulmaması gereken / ‘den sonra netmask bitini vermemiz gerekmektedir. Eğer verilmez ise netmask ilgili subnet için uygun değeri almak yerine direkt “/32” kullanılmaktadır.

·        gw4: Gateway IP adresi.

Burada dikkat edilirse dns ayarları girilmedi. DNS ayarları ne yazıkki connection yaratırken eklenemiyor. Bir sonraki aşamada yani connection modify ederken eklenebiliyor. Aşağıda bu örnek verilmektedir.

Connection modify edilirken dikkat edilmesi gereken şey connection add sırasında kullandığımız ip4 ifadesi yerine ipv4 ifaesi kullanıldığıdır. Ayrıca ikinci dns eklerken +ipv4.dns ifadesi kullanilmaktadir.

Bu connectionun özelliklerini görmek için aşağıdaki komutu kullanırız. Burada bir kısmı gösterilen özellikler aslında 50 satırı bulabilmektedir.

Aşağıda ayrıca mevcut bütün bağlantıları ve sadece aktif bağlantıları görmek için:

Aktif bir bağlantıyı down edip, diğer bağlantıyı aktif yapmak için

Üstte reload parametresinin kullanılmasına gerek yok fakat olası problemleri çözümleme adına yararlı olabiliyor. Reload parametresinin asıl kullanılmasındaki amaç /etc/sysconfig/network-scripts/ifcfg-* dosylarına elle müdahele yapılması durumunda bu bilgilerin de okunmasını sağlamaktır.

Son olarak bir connection silmek için (ilgili connectionun aktif olmadığına emin olmak gerekiyor nmcli şu aşamadan ne yazıkki aktif bir bağlantının silinmesine engel olmuyor silinmesi durumunda makinaya bağlantınız kopabilir!)

Üstteki örnekte görüldüğü gibi aktif olan bir bağlantı silindi ve ilgili sistemde herhangi bir aktif bağlantı kalmadı.

nm-connection-editor

Network bağlantılarını yönetmek üzere RHEL7 ve türevi işletim sistemlerinde görsel olan bir komut olan nm-connection-editor yine aynı adlı rpm paketi tarafından kurulmaktadır. Üstte girdiğimiz komutları burada incelersek

Ayrıca bu komuta ek olarak konsolda kullanabileceğimiz nmtui adlı konsol tabanlı görsel komutta mevcuttur.

Faydalı bağlantılar:

·        https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Network_Config_Using_nmcli.html

·        Nmcli, nmcli-examples ve nm-settings man sayfası

·        https://wiki.gnome.org/Projects/NetworkManager

·        https://wiki.gnome.org/Projects/NetworkManager/nmcli

Bu ilk yazımda Linux Ubuntu nun şuan ki son versiyonu olan 15.04 ün Active Directory Domain Controller mode’unda kurulumu hakkında olacak.

Ubuntu dağıtımını seçmemin sebebi kütüphanesinin çok geniş ve güncel olmasıdır. Diğer dağıtımlarda da aynı yol izlenirse sonuca ulaşmak anlamında mesafe katedilebilir diye düşünüyorum.

Linux üzerinde sambayı AD olarak ayarlıcaz ve windows AD den pekte farklı olmadığını görücez. Daha güçlü yönleri olabilir mi? Tartışılır…

Not:komutlar kırmızı renktedir. Root yetkileri ile çalıştırılmıştır. Root ile çalıştırmak istemeyenler komutların başına sudo eklemelidir.

Senaryo;

Linux Ubuntu = dc.ubuntsrv.local 192.168.0.10 (AD-DC)

Linux Ubuntu = server.ubuntsrv.local 192.168.0.5 (Bu makine sadece bizi internete çıkarmak için)

Windows client= test-pc 192.168.0.12 (dhcp)

DC isimli ubuntu server a logon olarak başlayalım..

Önce güncellemeleri alalım;

apt-get update

apt-get upgrade

dc.ubuntsrv.local adlı makinenin IP ayarlarında şu aklemeleri yapıyoruz

nano /etc/network/interfaces

Hosts dosyasına dc isimli makinenin bilgilerini giriyoruz

nano /etc/hosts

192.168.0.10    dc.ubuntsrv.local dc

Nano editörü ile yapılan değişiklikten sonra ctrl+x ile kayıt yapılır. Kaydetmeden çıkmak için ise ctrl+z

Yetkilendirme gibi işlemler için acl ve attr paketlerini kuruyoruz

apt-get install acl attr 

Bunlar daha sonra oluşturacağımız dosya ve klasörlerin yetkilendirmesinde işe yarayacaklar. Şimdi linux’ un dosya yapısında değişiklik yapalım. Yapacağımız share’lerin bulunduğu bölüme girip..

nano /etc/fstab

user_xattr,acl,barrier=1,

ekliyoruz. Kayıt edip çıktıktan sonra yeniden mount edelim

mount –a

Samba windows AD gibi LDAP ve kerberos kullanıyor bu sebeple NTP (network time protocol) kurmak zorundayız.

apt-get install ntp

Saat güncellemesi yapıyoruz..

service ntp stop

ntpdate -B 0.ubuntu.pool.ntp.org

service ntp start

Şimdi samba kurulumundan önce ihtiyazımız olan bu listedeki paketleri kuralım

apt-get install attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev

Kurulum sırasında kerberos sorularına  BÜYÜK HARFLERLE sırasıyla

UBUNTSRV.LOCAL, DC.UBUNTSRV.LOCAL, DC.UBUNTSRV.LOCAL diyerek devam..

Şimdi sambayı kuruyoruz

apt-get install samba smbclient

Sambanın conf dosyasını yedekliyoruz.

mv /etc/samba/smb.conf /etc/samba/smb.conf.ydk

smb.conf samba tool u ile yapacağımız domain provizyonu sırasında otomatik olarak oluşturacak. Bu işlemi yapmazsanız, samba tool işlemi yaparken zaten bu dosya mevcut diyerek işlemi tamamlamaz.

Samba DNS backend olduğundan network interface’inde ekleme yapıyoruz.

nano /etc/network/interfaces

dns-nameservers 192.168.0.10 192.168.0.5

Not: Bu senaryoda 192.168.0.5 numaralı IP internet bacağı olduğundan bu girişi yaptık. Örneğin internet için modem kullanan bir yapıda durum farklı olacaktır. Networkün durumuna göre dizayn edilmesi gerekir.

Ekstra bir DNS kurmaya gerek yok kurulan samba DNS forwarder gibi çalışıyor.

Serverı RESTART ediyoruz…

DNS setup ı kontrol edelim

cat /etc/resolv.conf

search ubuntsrv.local

nameserver 192.168.0.10

nameserver 192.168.0.5

görünüyorsa devam.

İnteraktif mode da domaini oluşturuyoruz

samba-tool domain provision --use-rfc2307 --interactive

Not; Bu tool u kullanmadan da samba AD kurulabilir. Ancak samba-tool otomatik kurulum için ideal olduğundan seçildi.

Şimdi smb.conf a bir bakalım

cat /etc/samba/smb.conf

Sıra kerberos ta. Provizyon sırasında sambaya uygun krb5.conf oluşturulduğu için mevcut dosyayı güvenli bir alana taşıyıp oluşturulan dosyaya link veriyoruz. Yetki sorunu çıkmasın istiyorsak /etc nin altında olmalı.

cat /etc/krb5.conf

mv /etc/krb5.conf /etc/krb5.conf.ydk

ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf

Serverı RESTART ediyoruz…

Şimdi LDAP ve kerberos testlerini yapalım

host -t SRV _ldap._tcp.ubuntsrv.local

host -t SRV _kerberos._udp.ubuntsrv.local

host -t A dc.ubuntsrv.local

Bu sorgulara doğru cevaplar alamazsanız işlem tamamlanamamıştır. DNS ayarlarını kontrol etmek gerekir!

Şimdi de Samba DC level ı yükseltelim

samba-tool domain level raise --domain-level 2008_R2 --forest-level 2008_R2

Windows 7 client a RSAT kurarak aşağıda ki işlemler kontrol edilebilir.

Yaptığım testlerde DNS - AD Users and Computers - GPO sorunsuz çalıştı. Diğerlerine henüz bakamadım. Tamamının çalışacağı garantisini ne yazık ki veremiyorum.

Domaine alınan windows client

Linux Ubuntu server 15.04 artık AD domain controller olarak hayatına devam edebilir.

RHEL7 ile gelen Firewalld Nedir?

9 Haziran 2014 de çıkan RHEL7 hayatımıza birçok yenilikler getirdi. .Bunlardan biri de firewall yönetimini yapan servislerin değiştirilmesi oldu. Eskiden script temelli bir sistem olan iptables servisi yerine firewalld ile firewall kuralları yönetilir hale geldi. Firewalld öncelikle script temelli değil bir servis olarak bir daemon tarafından ( /usr/sbin/firewalld ) yönetilmektedir.

Firewalld ile beraber zone mantığı da getirildi. Böylece network kartları bir zone’a bağlanarak yönetimi sağlandı. Ek olarak Ipv4 ve Ipv6 desteğini içeren firewalld, ek olarak Ethernet bridge’leri desteklemekte ve de çalışma esnası (runtime) ve kalıcı olarak iki yapılandırma sunmaktadır. Ayrıca kural eklerken uygulama bazında veya servis bazında da kural eklenilmesine olanak vermektedir. Eski iptables servisi ile (ki istenirse RHEL7 de firewalld disable edilip, iptables servisi yine kullanılabilir)

Aşağıdaki grafikte eski iptables servisi ile yeni firewalld servisinin arasında nasıl bir bağlantı olduğu görülebilir.

Eskiten görsel bir tool olarak iptables için system-config-firewall komutu kullanılmaktaydı. Bu komut iptables servisinin yapılandırma dosyası olan /etc/sysconfig/iptables dosyasına yazar ve iptables servisini değişiklikleri okuması için tekrar çağırırdı. Tabi bu yapılandırma dosyası iptables komutlarına dönüştürülerek çekirdekteki netfilter alt sistemine kural olarak eklenirdi.

Firewallld servisi ile artık iki alternatif yönetim komutumuz bulunmakta birisi görsel bir tool olan firewall-config diğeri komut satırından çalışan firewall-cmd her iki komutta aslında firewalld’nin XML tabanlı yapılandırma dosyalarını içeren /usr/lib/firewalld/ ve /etc/firewalld/ dizinlerine kuralları yazmakta ve buradan iptables komutları üretilip yine çekirdekteki netfilter alt sistemine kural olarak eklenmektedir.

Iptables, etables ve ip6tables servisi firewalld servisinin zıttıdır. Yani firewalld çalışırken bu servislerin çalışmaması gerekmektedir. Eğer çalışıyorsa

Daha önceden de dediğimiz gibi firewalld servisi bütün gelen (incoming) trafikleri zone’lara ayırmaktadır. Her bir zone’da kendi kural setlerine sahiptir. Firewalld gelen trafiğin hangi zone’a uğraması gerektiğini tespiti için şu kuralları uygular (İlk match eden kazanır):

1.      Eğer paketin kaynak adresi (source address) bir zone’da özel olarak tanımlı ise bu zone kullanılır.

2.      Eğer paketin geldiği interface için bir zone tanımlaması varsa bu zone kullanılır.

3.      Eğer bunlardan hiç biri yoksa default zone olan public zone’u kullanılır.

Firewalld’de gelen ön tanımlı zone public zone’a ek olarak aşağıdaki zone’larda ön tanımlı yapılabilir.

Firewall-cmd komutu

Firewalld paketi ile gelen firewall-cmd  komutu ile firewalld yönetilebilir. Firewall-cmd kuralları ile çalışırken kuralları sadece o esnada geçerli olmasını sağlayabiliriz. Firewalld servisi restart edildiğinde bu sonradan kalıcı şekilde olması için ayarlanmamış kurallar devreye alınmaz. Eğer kurallarda –permanent  ifadesi yer alırsa bu kural kalıcı olması için dosyalara yazılır. Bu aşamadan sonra kuralın runtime’da yani çalışma esnasında etkin olması için –reload parametresi kullanılır.Ayrıca uzaktaki sistemde kural yazarken kuralın belirli bir süre devre dışı kalması için (yazdığımız kuralların sisteme erişimi tamamen kesmemesi için) bir timeout süresi verebiliriz. –timeout=saniye  şeklinde kullanılan bu parametre süresi bittikten sonra kaldırılır. Bu da bizim kuralımızı yazarken sistemi erişilemez olması durumundan kurtarmamızı sağlar.

Bazı örnek firewall-cmd komutlarına bakmak gerekirse:

Firewalld servisinin durumunu görmek için:

# systemctl status firewalld

firewalld.service - firewalld - dynamic firewall daemon

   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)

   Active: active (running) since Tue 2016-10-17 11:14:49 CET; 5 days ago

   ...

# firewall-cmd --state

running

Ön tanımlı kullanılan zone’u görmek için

Bütün sistem hakkında özet bilgi almak için:

Üstte görüldüğü gibi public zone kullanılmakta ve ön tanımlı olarak sadece ssh vedhcpv6-client servislerine izin verilmektedir.

Bir servise izin vermek için. Mesela sistem üzerine kurduğumuz apache’ye izin vermek için:

Üstte görüldüğü gibi –add-service parametresi ile http servisine izin verilmektedir.

Herhangi bir IP veya Subnet’e izin vermek için:

Özel bir porta izin vermek için:

Burada öncelikle runtime’da aktif olmayan bir kalıcı (permament) kural ekledilk. 8080/tcp portuna izin verdik. Ama aynı zamanda bunun runtime’da yani sistem çalışırken de aktif olması için –reload parametresini kullandık.Şu ana kadar gördüğümüz kurallarda IP ve Port kavramını aynı satırda kullanamıyorduk. Bunun için kullanmamız gereken kural tanımları “Rich Rules” diye adlandırılan ve source/port veya protokol tanımlarından önce zone’larda ilk danışılan kural tipi olan kurallardır.

Örnek rich rule:

Firewall-config GUI

Firewalld ‘yi yönetmek için görsel bir araç olan firewall-config komutu da kullanılabilir. Yine aynı adlı rpm paketi olan bu görsel komutu aşağıdaki gibidir.

Üstteki arabirimde iki konfigürasyon modu mevcut. Biri Runtime diğeri Permanent. Burada kural yazarken önce Configuration Permanent seçilip sonrasında Optionsà Reload Firewalld ile kurallar Runetime a yüklenir.

Bu ekranda service ve/veya port eklemek mümkün olmasına ragmen komut satırından da kolay eklenebildiği için asıl rich rule eklenmesi sırasında bu ekranın kullanması daha faydalı olacaktır. Öncelikle Configuration’da Permanent seçilir.

Üstte görüldüğü gibi Port ve Servis kurallarının yanında aynı kuralda Source adresi de tanımlanmakta istenirse bu kural’ın syslog ‘a ve Audit sistemine mesaj atması da sağlanabilmektedir.

Bazı yararlı siteler:

Firewalld  servisi Red Hat 7 tabanlı sistemlerde gelen iptables servisine göre oldukça kolay ve yönetilebilir bir arabirim sunmakta. Aşağıda bazı yararlı linkler verilmektedir.

1.      http://www.firewalld.org/

2.      https://fedoraproject.org/wiki/FirewallD

3.      https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html

4.      https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7

5.      http://www.certdepot.net/rhel7-get-started-firewalld/

Bu makalemizde Bind dns sunucu ile Active Directory entegrasyonunu inceliyor olacağız. Bind Linux/Unix sistemlerde oldukça yaygın olarak kullanılmaktadır.  Bind ve Dns yapısı ile ilgili daha ayrıntılı bilgi için portalımızda daha önce yayınlanmış olan https://www.cozumpark.com/blogs/linux_unix/archive/2010/08/29/bind-linux-dns-servisi.aspx adresindeki makaleden faydalanabilirsiniz.

Bind ve Active directory entegrasyonu için öncelikle Linux sunucumuza bind yazılımını kurmamız gerekiyor. Ben test ortamı olarak Centos 6.7 server , 2012 R2 sunucu ve Windows 7 client tercih ettim. Bind dns sunucu yazılımı diğer tüm linux dağıtımları üzerine sorunsuzca kurulabilmektedir.

Centos sunucumuza yetkili kullanıcı ile bağlanıp yum install bind komutu ile kurulumu başlatıyoruz.

Centos  paket depolarından bind yazılımını sunucuma indirip kurmak için bizden onay istiyor. Y seçeneği ile onaylayarak devam ediyoruz.

Complete mesajı ile işlemin başarılı bir şekilde sonuçlandığını görüyoruz.

Centos dağıtımı üzerinde iptables (firewall) servisi varsayılan olarak açık geliyor. Bu servisi ben tamamen kapatmayı seçiyorum.

Firewall servisini tamamen kapatmak istemiyorum, sadece gerekli portları açmak istiyorum derseniz

/etc/sysconfig/iptables içerisine   :INPUT ACCEPT satırının altına

-A input –p tcp –dport 53 –j ACCEPT

A input –p udp –dport 53 –j ACCEPT

Satırlarını eklemek ve iptables servisini yeniden başlatmak yeterli olacaktır.

Sonrasında bu işlemin kalıcı olması için chkconfig iptables off komutunu kullanabiliriz.

Nano text  editörü ile bind konfigürasyon dosyasını (/etc/named.conf) düzenlemeye başlayabiliriz.

Konfigürasyon dosyası içerisinde cozumpark.local ve _msdcs.cozumpark.local bölgeleri için gerekli tanımları yapıyoruz.

check-names ignore;     

bu satır ile _ldap veya _tcpşeklindeki kayıtları oluştururken hata vermemesini sağlıyoruz.

allow-update { AD-Server; };

satırı ile de DC üzerinden dns kayıtlarının oluşturulabilmesini sağlıyoruz.

Sonrasında /var/named/data altında cozumpark.local ve _msdcs.cozumpark.local bölge dosyalarını oluşturmamız gerekiyor.

Cozumpark.local dosyasının içeriği şu şekile olmalı :

[root@centos data]# more  cozumpark.local

$ttl 38400

cozumpark.local. IN      SOA     centos.cozumpark.local. vasvi.cozumpark.com. (

                        1444746648

                        10800

                        3600

                        604800

                        38400 )

cozumpark.local. IN      NS      centos.cozumpark.local.

centos.cozumpark.local  IN      A       10.100.5.191

Sonrasında Bind servisini açılışta çalışacak şekilde ayarlıyoruz ki sunucu yeniden başladığında sorun yaşamayalım.

Chkconfig named on komutu named (bind ) sunucunun açılışta çalışmasını sağlıyor.

Chkconfig |grep named komutu ile kontrol ettiğimizde 2, 3, 4, 5 level için onşeklinde olduğunu görebiliyoruz.

Konfigurasyonu tamamladıktan sonra named (bind) servisini yeniden başlatıyoruz ve çalışıp çalışmadığını kontrol ediyoruz.

Selinux eklentisini devre dışı bırakmamız gerekiyor. Bunun için /etc/sysconfig/selinux dosyası içerisine SELINUX=disabled satırını ekleyip kaydederek çıkıyoruz.

Windows 2012 sunucuma geçip ipv4 ayarlarını yapıyorum, dns olarak Linux sunucumun ip adresini giriyorum.

Bundan sonrası klasik Active Directory kurulumu ile neredeyse birebir aynı

Server manager içerisinden Active Directory Domain Services rolünü kuruyoruz.

Rol tabanlı kurulum bitince Promote this server to a domain controller seçeneği ile ile Active directory yapımızın kurulumuna başlıyoruz.

Klasik Active directory kurulumundan farklı olarak dns server kutucuğunu temizliyoruz.

Daha önce kurduğumuz linux sunucu üzerindeki bind dns sunucuyu kullanacağız.

Forest ve Domain Functional level olarak Window Server 2012 R2 seçiyoruz.

Bir sonraki ekranda Netbios Domain ismimizi de giriyoruz. Kurulum sonrasında sunucumuz yeniden başlıyor. Client tarafına geçip onu da domaine alıyoruz.

Sunucumuzda olduğu gibi client tarafında da ipv4 ayarlarında dns olarak Linux sunucumuzun ip adresi olması gerekiyor.

Welcome to cozumpark.local domain mesajı ile işlemin başarılı bir şekilde sonuçlandığını gözlemleyebiliyoruz.

Linux tarafında /var/log/messages dosyasına baktığımızda client için dns ismi oluşturma isteğini görebiliyoruz

Windows 2012 R2 sunucu üzerinde Active Directory Users and Computers içerisini kontrol ettiğimizde Client1 isimli makinamızı görebiliyoruz.

Faydalı olmasını dilerim.

Bu yazımızda Bind dns sunucu üzerinde view yapısını inceliyor olacağız.  Bu nedir dediğinizi duyar gibiyim. Bind üzerindeki view yapısı sayesinde dns sunucunuz isim sorgulama sırasında farklı networklere veya hostlara göre farklı ip adreslerini cevap olarak döndürebilir.

Bunun bize nasıl bir faydası olabilir diye düşünüyorsanız hemen bir örnekle açıklamaya çalışayım.

Çok şubeli bir intranet yapınız olduğunu varsayalım ve bu intranet yapısında uygulama sunucunuz veya web sunucunuz bölgelere göre farklı ip adreslerinde hizmet versin istiyorsunuz.  Bu sayede izmir bölgesindeki clientler www.cozumpark.com adresine gitmek istediğinde bind dns sunucunuz izmir bölgesi için ayırdığımız web sunucunun ip adresini, istanbul bölgesindeki clientler www.cozumpark.com adresine gitmek istediğinde ise istanbul bölgesi için ayırdığınız web sunucunun ip adresini verecektir. Bu işi load balancer gibi cihazlar ile de yapabiliyoruz fakat bu yöntem ile maliyetsiz ve daha basit bir yapılandırma ile statik olarak gerçekleştirebiliriz.

Veya Active Directory yapınızda kullanıcı profillerinizi clientler yerine nas cihazınızda tutmak istiyorsunuz. Şehirlerarası bağlantılar yavaş olacağı için her bölge için kendi lokalindeki nas cihazını gösterebilirsiniz. Dns tarafında fileserver tanımı her bölge için kendi lokayonundaki nas cihazını gösterecektir böylece.

Bu kadar ön bilgiden sonra işin yapılandırma kısmına geçelim:

Test ortamımda Suse Linux kullanıyorum. Dns sunucu kurulumunu yast içerisinden basit bir şekilde yapabilirsiniz veya rpm paketlerini bulup manuel olarak da kurulum yapabilirsiniz. Debian tabanlı sistemlerde apt-get install named , Redhat tabanlı sistemlerde ise yum install named komutları ile

Dns sunucu kurulumunu yapabiliriz.

Kurulum sonrasında Linux sunucu üzerinde firewall servisinin kapalı olmasına veya sunucuma gelen isteklerde 53 portunun (tcp ve udp ) açık olmasına dikkat ediyorum. Aksi halde dns sunucuma erişimde ve isim çözümleme sırasında sorunlar yaşanabilir.

Bind dns sunucunun yapılandırma dosyası bir çok Linux dağıtımı üzerinde olduğu gibi susede de  üzerinde /etc/named.conf şeklindedir.  Bu yapılandırma dosyası içerisinde cozumpark.local isminde bölge oluşturuyorum.

zone "cozumpark.local" in {

        allow-transfer { any; };

        file "master/cozumpark.local";

        type master;

};

Kayıt dosyaları ise /var/lib/named/master/cozumpark.local dosyası içerisinde yer alıyor.

$TTL 2d

@               IN SOA          suse.   root.suse. (

                                2015102000      ; serial

                                3h                       ; refresh

                                1h                       ; retry

                                1w                      ; expiry

                                1d )                    ; minimum

cozumpark.local.        IN NS           suse.cozumpark.local.

suse                               IN A            10.100.5.250

Bu dns sunucuyu kullanan bir client isim çözümlemek istediğinde hangi lokasyondan gelirse gelsin

suse.cozumpark.local için 10.100.5.250 adresini görüyor.

Şimdi lokasyonlarım için bind dns sunucu üzerinde acl (access list – erişim yetkisi) tanımlarını yapmam gerekiyor.

İstanbul lokasyonumu 10.100.17.0 /24 networku , izmir lokasyonumu da 10.100.19/24 networku olarak tanımlıyorum. Bu tanımlardan sonra dns sunucumun bu lokasyonlardan gelecek istekler için farklı ip adresleri döndürmesini sağlamam gerekiyor.

view "izmir" {

    match-clients { izmir; };

    zone "cozumpark.local" {

        type master;

        file "/var/lib/named/master/izmir.cozumpark.local";

        allow-transfer { slaves; };

    };

};

view "istanbul" {

    match-clients { istanbul; };

    zone "cozumpark.local" {

        type master;

        file "/var/lib/named/master/istanbul.cozumpark.local";

        allow-transfer { slaves; };

    };

};

Bu konfigürasyon sonrasında "/var/lib/named/master altında izmir ve İstanbul için ayrı bölge dosyalarımı oluşturmam gerekiyor.

İzmir için :

suse:/var/lib/named/master # cat izmir.cozumpark.local

$TTL 2d

@               IN SOA          suse.   root.suse. (

                                2015102000      ; serial

                                3h              ; refresh

                                1h              ; retry

                                1w              ; expiry

                                1d )            ; minimum

cozumpark.local.        IN NS           suse.cozumpark.local.

suse            IN A            10.100.5.250

www             IN A            10.0.0.35

İstanbul için:

suse:/var/lib/named/master # cat istanbul.cozumpark.local

$TTL 2d

@               IN SOA          suse.   root.suse. (

                                2015102000      ; serial

                                3h              ; refresh

                                1h              ; retry

                                1w              ; expiry

                                1d )            ; minimum

cozumpark.local.        IN NS           suse.cozumpark.local.

suse            IN A            10.100.5.250

www             IN A            10.0.0.34

bölge dosyalarımı da oluşturduktan sonra konfigürasyonu okuması için bind dns servisini

yetkili kullanıcı ile service named restart komutu ile yeniden başlatıyorum.

İzmir bölgesindeki bir client tarafından      ( 10.100.19.0/24 ) ve

İstanbul bölgesindeki bir client tarafından (10.100.17.0/24) testlerimizi yapıp

yaptığımız konfigürasyonun doğru bir şekilde çalışıp çalışmadığını test ediyorum.

İzmir bölgesindeki client :

Bu sorgu için konfigürasyon dosyasında ayarladığımız gibi 10.0.0.35 ip adresini döndürüyor.

İstanbul bölgesindeki client:

Bu sorgu için konfigürasyon dosyasında ayarladığımız gibi 10.0.0.34 ip adresini döndürüyor.

Böylece farklı şubelerimdeki clientler aynı isim sorgusu için farklı sunuculara erişebiliyorlar.

Faydalı olması dileği ile.

RHEL (Red Hat Enterprise Linux) 7 ile hayatımıza birçok yenilik geldi. Bu yeniliklerden biri de root şifresinin unutulması durumunda değiştirilmesi yöntemi de oldukça değişti. Bunun bir sebebi grub yazılımının ikinci sürümü yani grub2 nin kullanılması, başka bir sebebi de init yerine systemd kullanılmasıdır. Aşağıda sırasıyla root şifresinin kırılması adımları gösterilmektedir.

Öncelikle gelen grub ekranında sistemi boot ettiğiniz en son çekirdek (grub2 nin sunduğu ön tanımlı çekirdek) seçiliyken “e” tuşuna (tırnaklar hariç) basılır aşağıdaki gibi. Burada yapılan ilgili çekirdeğe bir parametre gönderilmesidir.

Gelen ekran aşağıdakine benzer bir ekrandır.

Üstteki ekranda en aşağı satırlara inip, aşağıdaki gibi linux16 olan satır bulunur. Bu satırın en sonunda LANG=en_US.UTF-8 yazan kelimenin sonuna bir boşluk karakterinden sonra rd.break ifadesi yazılır.

Aşağıdaki gibi rd.break eklendikten sonra

CTRL-x tuşuna beraber basılarak sistemin boot etmesi sağlanır. Bundan sonra aşağıdaki gibi emergency mode dediğimiz kısım açılır. Burada ön tanımlı olarak şifre sorulmadan switch_root#:/  promptu gelir. Burası bir ramdisk ortamıdır. Fakat hardiske kurulu root şifresini kırmak istediğimiz sistem /sysroot dizinine read-only olarak mount edilir.

Bu aşamadan sonra read-only mount edilmiş hardiske kurulu sistem read-write modunda mount edilir. Aşağıda

# mount  |grep sysroot

Komutu ile diskin read-ony mount edildiği görülür. Sonrasında

# mount –o rw,remount /sysroot

Komutu ile hardiskin rw modunda mount edilr. Daha sonra tekrar

# # mount  |grep sysroot

İfadesi ile bu sefer rw modunda mount edildiği görüldükten sonra

# chroot /sysroot

Komutu ile /sysroot dizini geçici olarak yeni / yaplır. Zaten bu komutu verdikten sonra Promt sh-4.2# şeklinde değişecektir.

Bundan sonra aşağıdaki gibi passwd root komutu ile root şifresi değiştirilir. Ön tanımlı olarak 8 karakterden fazla bir şifre istese bile iki defa 8 karakterden az şifre girseniz bile updated sucessfully satırı görüldükten sonra root şifresi değiştirilmiş demektir. Herhangi bir sebepten şifre başarıli bir şekilde değiştirilmemiş  ise farklı bir ifade yazacaktır.

Root şifresi değiştirildikten sonra eğer sistemde Selinux enabled durumda ise

# touch /.autorelabel

Komutu ile açılışta selinux ‘un bütün dosyaları tekrar selinux ‘e uygun olarak izini düzenlenmesi sağlanacaktır. Bu aşamadan sonra aşağıdaki resimdeki gibi

#exit

Komutu verilir ve switch_root promptuna geri dönülür. Bu işlemde aslında chroot ile /sysimage ‘a girdiğimiz ortamdan çıkılmış olur. Sonrasında da aşağıdaki gibi reboot komutu verilir.

# reboot

Sistem böyleyece reboot edilir. İlk aşamada eğer sistemde selinux var ise /.autorelabel dosyası olduğundan ötürü selinux bütün dosyaların izinlerinin doğru olduğundan emin olup, doğru değilse düzelteceğnden sistemin açılması uzun sürecektir. Bu autorelabel işlemi tamamlandıktan sonra sisteminiz bir kere daha reboot olacak ve sisteme artık yeni değiştirdiğiniz şifre ile girebileceksiniz.

Kaynaklar:

https://access.redhat.com/solutions/918283

Bu yazımızda Windows üzerinde Bind dns sunucu kurulumunu inceliyor olacağız. Bind Unix, Linux ve Windows platformlarında oldukça sorunsuz çalışabilen bir dns sunucu yazılımıdır. Windows üzerinde kurulumuna başlamak için öncelikle http://www.isc.org/downloads/ adresinden kurulum dosyasını indirmemiz gerekiyor. Bu doküman yazıldığında son sürüm olarak 9.10.3 sunulmakta idi. 

Download linkine tıkladığımızda gelen ekrandan sistemimize göre 32 bit veya 64 bit sürümü seçmemiz gerekiyor. İndirme işlemi bitiminde kuruluma başlamadan önce sunucumuzda named isminde bir servis hesabı oluşturuyoruz.

Bu servis hesabına logon as service hakkı vermemiz gerekiyor ki servisi başlatabilsin.

BIND9.10.3.x86.zip dosyasını bilgisayarımızda açıp içerisindeki  BINDInstall.exe yi çalıştırarak kuruluma başlıyoruz.

Bind 32 bit sistemlerde varsayılan olarak c:\windows\system32\dns klasörüne kurulum yapıyor.

Ben c:\named klasörü oluşturup buraya kurmayı tercih ediyorum.  C:\named klasörünün sahibi olarak named kullanıcısını ayarlıyorum. İnstall seçeneği ile kurulumu tamamlıyorum.

Bind installation completede succesfully mesajını OK diyerek kapatıyorum. Sonrasında bind çalıştırılabilir dosyalarının olduğu c:\named\bin klasörünü system path değişkeni içerisine ekliyorum.

Bu işlemden sonra komut satırı ekranı açıp aşağıdaki komut ile rndc.conf dosyasını oluşturuyorum.

Bu işlem sonrasında Bind dns sunucumuzun konfigürasyon dosyalarını oluşturmak kalıyor geriye

Bu dosyalar named.conf , root.hints ve zone.localhost dosyalarıdır.

C:\named\etc\named.conf dosyasının içeriği :

options {  directory "c:\windows\system32\dns\etc";

  edns-udp-size 1460;

    pid-file none;

  version "not currently available";

  listen-on { 127.0.0.1; 10.100.1.1; };

    recursion yes;

};

controls {

        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };

};

key "rndc_key" {

        algorithm hmac-md5;

        secret "77W+Rt9N8uR2Kbl5gi7SHw==

};

zone "." IN {

  type hint;

  file "root.hints";

};

zone "localhost" IN {

  type master;

  file "zone.localhost";

  allow-update { none; };

};

C:\named\etc\root.hints dosyasının içeriği:

;; QUESTION SECTION:
;.                IN    NS

;; ANSWER SECTION:
.            518400    IN    NS    A.ROOT-SERVERS.NET.
.            518400    IN    NS    I.ROOT-SERVERS.NET.
.            518400    IN    NS    C.ROOT-SERVERS.NET.
.            518400    IN    NS    H.ROOT-SERVERS.NET.
.            518400    IN    NS    M.ROOT-SERVERS.NET.
.            518400    IN    NS    E.ROOT-SERVERS.NET.
.            518400    IN    NS    K.ROOT-SERVERS.NET.
.            518400    IN    NS    L.ROOT-SERVERS.NET.
.            518400    IN    NS    B.ROOT-SERVERS.NET.
.            518400    IN    NS    J.ROOT-SERVERS.NET.
.            518400    IN    NS    D.ROOT-SERVERS.NET.
.            518400    IN    NS    G.ROOT-SERVERS.NET.
.            518400    IN    NS    F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.    3600000    IN    A    198.41.0.4
B.ROOT-SERVERS.NET.    3600000    IN    A    192.228.79.201
C.ROOT-SERVERS.NET.    3600000    IN    A    192.33.4.12
D.ROOT-SERVERS.NET.    3600000    IN    A    128.8.10.90
E.ROOT-SERVERS.NET.    3600000    IN    A    192.203.230.10
F.ROOT-SERVERS.NET.    3600000    IN    A    192.5.5.241
G.ROOT-SERVERS.NET.    3600000    IN    A    192.112.36.4
H.ROOT-SERVERS.NET.    3600000    IN    A    128.63.2.53
I.ROOT-SERVERS.NET.    3600000    IN    A    192.36.148.17
J.ROOT-SERVERS.NET.    3600000    IN    A    192.58.128.30
K.ROOT-SERVERS.NET.    3600000    IN    A    193.0.14.129
L.ROOT-SERVERS.NET.    3600000    IN    A    199.7.83.42
M.ROOT-SERVERS.NET.    3600000    IN    A    202.12.27.33

C:\named\etc\zone.localhost dosyasının içeriği:

;
; loopback/localhost zone file
;
$TTL 1D
$ORIGIN localhost.
@              IN  SOA   @  root (
                         1   ; Serial
                         8H  ; Refresh
                         15M ; Retry
                         1W  ; Expire
                         1D) ; Minimum TTL
               IN   NS   @
               IN   A    127.0.0.1

Bu dosyaları kaydettikten sonra Windows makinamda servisler içerisindeki ISC DNS servisini çalıştırıyorum.

Bu şekilde bind dns kurulumu ve ayarlarını tamamlamış oluyoruz. Bundan sonrasında

Makinamızdaki ipv4  ayarlarında dns sunucu olarak bu makinayı göstererek test edebiliriz.

Faydalı olmasını dilerim.

Red Hat tabanlı sistemlerde iki network arabirimini tek bir ağ arabirimi olarak göstermek için önceden bonding metodu kullanılmaktaydı.  RHEL 7 ile beraber her ne kadar bonding geriye uyumluluk için desteklense de artık bonding yerine teaming dediğimiz daha performanslı ve modüler dizaynından dolayı daha esnek bir yapı geldi.

RHEL7 içinde bu işlemi sağlamak için yeni bir kernel sürücüsü ve teamd adında yeni bir servis yazılımı (daemon) geldi.Çekirdekteki sürücü ilgili network paketlerini işlerken teamd mantıksal ve arabirim işleme fonksiyuonlarını icra etmektedir. Ayrıca teamd içindeki runner denilen bileşenler de active-backup, loadbalancing gibi işlemleri gerçekleştirmektedir. Teamd ile aşağıdaki runner’lar kullanılabilmektedir.

Teamd Paketinin kurulması

Öncelikle teamd paketinin sisteme kurulu olduğundan emin olalım. Bunun için aşağıdaki komut verilir.

Bu şekilde paket kurulduktan sonra team interface işlemi oluşturma işlemine geçilebilir.

Nmcli komutu ile team oluşturma

Network arabirimi ayarları için Red Hat 7 işletim sisteminde ön tanımlı gelen Networkmanager paketindeki nmcli komutu  kullanarak team işlemi şu komutlarla oluşturulur.

Yukarıdaki ilk komut ile team0 adında bir interface eklenir. Aslında bu işleme kadar sistemde bir teamd servisi çalışmaz. Bu ilk komuttan sonra aşağıdaki gibi bir daemon başlar.

Daha sonra slave interface’ler eklenerek team0 interface’i oluşturulur. Oluşturulan team0 arabirimi detayları için teamdctl  team0  config dump komutu verilir. Aşağıda görüldüğü üzere Json formatında bir yapılandırması mevcuttur teamd’nin ve ön tanımlı olarak team interface’i oluştururken bir  runner belirtilmediği için roundrobin tipinde bir team arabirimi oluşturulur. Üstteki komutlarda enp0s9 ve enp0s10 arabirimi team0 a eklenmiş oldu.

Üstte ayrıca config dump’ından görülebilidiği üzere link gitmesini izlemek için ethtool komutu kullanılmaktadır.

Nmcli ile detaylı yapılandırma

nmcli con add type team con-name team0 ifname team0 komutuna ek olarak istenirse  sonuna aşağıdaki gibi

nmcli con add type team con-name team0 ifname team0 config  config.json

gibi bir parametre verilerek oluşturulan  team arabiriminin nasıl davranacağı belirtilebilir. RHEL7 ile beraber

/usr/share/doc/teamd-1.9/example_configs dizininde örnek alabileceğiniz yapılandırmalalar mevcuttur veya istenirse bu yapılandırma komut satırından da verilebilir.

Yapılandırmayı tekrar görmek için

Son olarak bu interface’e IP vermek için

Teamd bağlantısını kaldırmak

Team0 bağlantısını kaldırmak için önce slave’ler sonra team0 ‘ın kendisi kaldırılır.

Nm-connection-editor ile team oluşturmak

Bunun için önce  nm-connection-editor komutu çalıştırılır.

Üstte gelen ekranda önce Add tuşuna basılır ve Connection Type olarak Team seçilir ve Create tuşuna basılır. Sonra gelen ekranda aşağıdaki gibi Connection name olarak team0 yazılır ve Teamed Connections kısmında  Add tuşuna basılır.

Sonra aşağıda gelen ekrandan tip olarak öntanımlı tip olan Eterhnet seçili bırakılarak Create tuşuna basılır.

Üstteki gibi Ethernet sekmeninde enp0s9 seçilip, aşağıdaki gibi General tabında Autoconnect yapılırarak Save tuşuna basılır.

Aynı işlem enp0s10 interface’i içinde yapılır ve ana ekran şu hale gelir.

Burada Json config dosyasına istenen değişiklikler eklenir.

Üstteki Json Config satırında boşluk karakteri olmaması önemlidir!

En son olaraksa Ipv4 Settings tabından aşağıdaki gibi IP bilgisi eklenip, bağlantı Manuel yapılıp save edilir.

Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşem dileği ile.

Kaynaklar 

Nmcli-examples , teamdctl ve teamd man sayfaları

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Configure_a_Network_Team_Using-the_Command_Line.html#sec-Configure_Network_Teaming_Using_nmcli

SAP Quick Sizer

SAP tarafından geliştirilen bu araç ile gerekli olabilecek kaynak analizini kolaylıkla yapabilirsiniz.

SAP PAM

SAP tarafından geliştirilen bu araç ile platform hakkındaki teknik detaylara ulaşabilir, geliştirme, güncelleme ve uyumluluklar hakkında teknik detaylara ulaşabilirsiniz.

SUSE Enterprise Server Kurulumu

SUSE üzerinden HANA için derlenmiş olan SUSE Enterprise Server for SAP Applications 11 SP<X> imajını indiriyoruz.

NOT: İki DVD olarak gelmektedir. Birinci DVD sistem, ikinci DVD ise kaynak kodlarını içermektedir. Birinci DVD kurulum için yeterlidir.

İndirip hazırlamış olduğumuz bu kurulum medyası üzerinden sistemi açıyoruz ve kuruluma başlıyoruz.

NOT: Klasik yükleme olan Installation ile devam edebilirsiniz. (Wizard ise yeni sürümlerde gelen hazır kurulum sihirbazıdır)

Temiz bir kurulum yapacağımız için bu alanda New Installation seçiyoruz.

Fiziksel bir sunucu üzerinde kurulum yapacağımızdan buradaki kurulum senaryomuz Physical Machine olacaktır.

Disk bölümlendirmesi ve yazılım seçimi sistem tarafından otomatik olarak yapılmaktadır dilerseniz bu alanları özelleştirebilirsiniz.

NOT: Biz kurulumu test sitemi üzerinde yaptığımızdan bu alandaki donanım değerleri ve disk bölümlendirme alanları farklıdır. Sadece deneme sistemi için referans almalısınız.

NOT: Standart bir test sistemi kurulumu için minimum 200 GB disk alanı 4 virtual CPU ve 12 GB hafıza gerekmektedir.

Deneme kurulumunda 600 GB disk 48 GB hafıza 4 virtual CPU kullanmaktayız.

Kurulum işlemi başladıktan sonra yaklaşık olarak 1200 üzerinde paket sisteme kurulup tanımlanacaktır.

(Ortalama kurulum süresi 20 dakika civarındadır)

Kurulum tamamlandıktan sonra sistem tekrardan başlayarak kurulum sonrası adımlara geçecektir.

Sunucu adı ve alan adı tanımlarımızı yapıyoruz.

Statikağ ayarlarımızı yapıyoruz

Firewall ve gelişmiş ağ ayarlarını bu ekran üzerinden yapabilirsiniz.

Erişim yöntemi olarak Local (etc/password) seçiyoruz.

Root sistem kullanıcısının yanında standart bir kullanıcı hesabı da oluşturuyoruz.

NOT: Standart kullanıcı güvenlik nedeniyle sistemde kesinlikle önerilmektedir.

Kurulum sonrası adımlar tamamlandıktan sonra sisteme root hesabıyla giriş yapıyoruz. (yada standart kullanıcı üzerinde root haklarıyla)

SUSE Enterprise Server for SAP Applications kurulumu gerçekleşmiştir. Sonraki adımda HANA platform dosyaları Support Portal üzerinden indirip HANA kurulumu öncesi adımları gerçekleştireceğiz.

SAP Support Portal üzerinden HANA Platform Edition kurulum dosyalarını indiriyoruz.

NOT: Intel işlemci mimarisine ilave olarak IBM PowerPC mimarisini de desteklemektedir.

WinSCP ile indirmiş olduğumuz dosyaları SUSE sunucumuzun root dizini altında yeni bir klasöre aktarıyoruz.

Aktarmış olduğumuz bu dosyaların bulunduğu klasörün chmod değerini 755 veya 777 yapıyoruz.

HANA Platform Edition paketi içerisinde veritabanını yönetebilmek için gerekli tüm araçları bulabilirsiniz.

HANA Kurulum Öncesi Hazırlıkları

Eğer XFS dosya sistemini kullanacak iseniz mutlaka glibc kütüphanesini kurmalısınız.

NOT: Dosya sisteminizi görüntülemek için df -hT komutunu kullanabilirsiniz.

HANA diğer veri tabanı sistemlerinden farklı bir yapıda olduğundan hugepagesözelliğini

echo never > /sys/kernel/mm/transparent_hugepage/enabled komutu ile pasif hale getiriyoruz.

Kurulum öncesi bu klasörlerin root dizini üzerinde oluşturulması gerekmektedir.

/hana/data/<SYSTEMID>

/hana/log/<SYSTEMID>

/hana/shared

HANA Kurulum Adımları

HANA veri tabanı kurulum dosyalarına HDB_SERVER_LINUX_X86_64 klasörü içerisinden erişebilirsiniz.

NOT: Kurulumu başlatırken Access Denied uyarısı almanız durumunda chmod ayarlarınızı kontrol ediniz.

./hdbinst komutu ile kurulum işlemini başlatıyoruz.

Local Host Name varsayılan olarak bırakıyoruz.

Enter Installation Path varsayılan olarak bırakıyoruz.

SAP HANA System ID tercihe bağlı (üç karakter olarak) belirlenmelidir. (TST)

Instance Number varsayılan olarak bırakıyoruz. (00)

Database Mode olarak Single Container seçiyoruz. (1)

NOT: Single Container HANA sistemi için tek bir veri tabanı oluştururken Multiple Containers HANA sistemi için birden fazla veri tabanı oluşturmamıza olanak sağlamaktadır.

(SPS09 sürümü ile birlikte gelmiştir)

HANA sisteminin kullanım amacını belirliyoruz. (2)

NOT: Bu alandaki seçimler kurulum sırasında sisteme farklı ek parametreler tanımlamaktadır.

<SID>ADMşifremizi belirliyoruz.

HANA sisteminde iki temel yönetici hesabı bulunmaktadır.  <SID>ADM ve SYSTEM

Bu ekrandaki tüm yükleme parametrelerini varsayılan olarak bırakıyoruz.

Restrict maximum memory allocation parametresine N olarak seçersek sunucu üzerindeki tüm hafızayı tek bir HANA sistemine tanımlayacaktır. (Y yapmanız durumunda kullanılacak hafıza miktarını özelleştirerek sonrasında aynı sunucu üzerinde kurulabilecek olan diğer HANA sistemleri için ek kaynak ayırıyor olabileceksiniz.) 

NOT: Bu ayarı sonrasında HANA Studioüzerinde Configuration sekmesinden global_allocation_limit parametresi ile değiştirebilirsiniz.

HANA veri tabanı yöneticişifremizi belirliyoruz. Sonrasında HANA Studio ile sistemi bu hesap üzerinden yöneteceğiz.

İsteğe bağlı olarak sunucuyu tekrar başlatabilirsiniz. (N)

Kurulum parametreleri için son bir özet ekranı önümüze geliyor Y ile onay vermemiz durumunda HANA sistemi kurulmaya başlayacaktır.

Konsol üzerinden kurulan paketleri izleyebilirsiniz.

HANA veri tabanı ve HANA sistemine tanımlı olan servislerimiz oluşturuluyor.

Kurulum işlemi başarıyla tamamlandı. Dilerseniz hdbinst.logüzerinde kurulum detaylarını bulabilirsiniz.

<SID>ADM haklarına geçiş yaparak HDB start komutu ile HANA veritabanını başlatıyoruz.

NOT: Sunucuyu yeniden başlatmadan önce veritabanını HDB stop ile durdurmanız gerekmektedir.

HANA Studio Kurulumu

HANA sistemi kurulduktan sonra sırada bu sistemi yönetebilmemiz için gerekli olan HANA Studio yazılımının kurulumuna geçiyoruz.

HDB_STUDIO_LINUX_X86_64 dizinine giderek ./hdbinst komutu ile HANA Studio kurulumuna başlıyoruz.

Yükleme dizinini varsayılan olarak bırakıyoruz.

Full kurulum yapacağımızdan All seçiyoruz.

Kurulum öncesi bilgilendirme ekranını kontrol edip Y ile kurulumu başlatıyoruz.

HANA Studio için gerekli paketlerimiz kuruldu.

/usr/sap/hdbstudio dizinine giderek ./hdbstudio komutu ile HANA Studio uygulamasını çalıştırıyoruz.

Select a workspace HANA Studio ayarlarımızın tutulacağı dizindir.

SAP HANA Studio için gerekli kütüphaneler yüklenerek uygulama açılıyor.

Secure Storageözelliği ile HANA Studio profil ayarlarınızı şifreli bir şekilde saklayabilirsiniz.

Ana ekran üzerinde bulunan Open Administration Console ile yönetim sayfasına geçiyoruz.

Add Systemüzerinden HANA sistemi bağlantısı ekranına gelerek ilgili tanımları yapıyoruz.

Host Name olarak Linux FQDN adımızı giriyoruz.

NOT: Konsol üzerinden hostname --fqdn komutu ile öğrenebilirsiniz.

HANA kurulumu sırasında belirlemiş olduğumuz Instance numarasını giriyoruz. (00)

HANA kurulumu sırasında belirlemiş olduğumuz veri tabanı yönetici hesabını giriyoruz.

HANA Studio üzerinden HANA sistemimize başarıyla bağlanmış bulunuyoruz.

HANA Studio ana ekranında HANA sistemi hakkındaki tüm bilgileri bize veriyor olacaktır.

Ana ekranın devamında sistem üzerinde kullanılan kaynakları gözlemleyebilirsiniz.

Bu yazımızda HANA Sistemi için gerekli olan SUSE Enterprise Server for SAP, HANA Database ve HANA Studio yazılımlarını başarıyla kurup çalıştırmış olduk.

Büyük verinin geleceği olan HANA yakın zaman içerisinde veri tabanı sistemleri hakkında bilinen her şeyi değiştiriyor olacak.

Tekrardan Görüşmek dileği ile…

SAP GUI yazılımı Mac OS X ve Linux sistemlerinde Java tabanlı olarak gelmektedir. Bunun içinde temel bileşen olan Java’nın sistemde yüklü olması gerekmektedir. Java kurulumu Windows ve Mac OS X tabanlı sistemlerde çok kolay olmasına rağmen, Linux tabanlı sistemler de bu işlem biraz karmaşık ve yorucu olabilmektedir.

Kurulum adımları x86 ve x64 mimarisinde OpenSUSE ve SLES (Suse Linux Enterprise Server) olarak iki sistemde geçerli olarak kullanılabilir.

Anlatımda ise referans sistem olarak SLES 12 x64 sürümünü kullanacağız.

İlk olarak SAP Support Portal üzerinden son sürüm (7.40) SAP GUI Java’yı indiriyoruz.

İkinci olarak Oracle sayfası üzerinden en son Java (8u72) indiriyoruz.

İndirilen tüm paketleri root dizini üzerinde bir klasöre kopyalayarak kurulum işlemini başlatıyoruz.

NOT: Linux üzerinde JAVA kurulumu yaparken sistem ilgili kurulum linkini oluşturamadığından /usr/sbin dizini altında alternatives adında yeni bir dosya linki oluşturuyoruz.

Konsol üzerinden ln -s /usr/sbin/update-alternatives /usr/sbin/alternativeskomutu ile ilgili linki oluşturmuş bulunuyoruz.

NOT: Konsol üzerinden linkin oluşturulduğu dizine gelerek ll komutu ile link kontrolünü yapabilirsiniz.

Kurulum öncesi uname -a komutu ile Kernel sürümünü veya sistem mimariniziöğrenebilirsiniz.

Kurulum dizinimize tekrardan dönerek rpm -ivh --nodeps jre-8u72-linux-x64.rpm komutu ile Java kurulumuna başlıyoruz.

NOT: Kurulum komutunda kullanılan parametre detayları;

-i paket kurulumu (install)

-v kurulum ayrıntısı (verbose)

-h kurulum düzeyi (hash)

--nodeps paket bağımlılıklarını önemseme

Java kurulumumuz /usr/java altına yapılmıştır. ls komutu ile kurulum dizini adını not alıyoruz. (jre1.8.0_72)

/usr/sbin dizini altına gelerek alternatives --install “/usr/bin/java” “java” “/usr/java/jre1.8.0_72/bin/java” 1 komutunu giriyoruz.

/usr/sbin altında update-alternatives --set java /usr/java/jre1.8.0_72/bin/java komutunu giriyoruz.

/usr/sbin altında alternatives --install “/usr/lib64/browser-plugins/javaplugin.so” “javaplugin” “/usr/java/jre1.8.0_72/lib/amd64/libnpjp2.so” 1 komutu ile Java paketinin browser eklentisini yüklüyoruz. (sonrasında internet tarayıcılarımız üzerinde kullanılmak üzere)

NOT: x86 mimarisinde /usr/sbin altındaalternatives --install “/usr/lib64/browser-plugins/javaplugin.so” “javaplugin” “/usr/java/jre1.8.0_72/lib/i386/libnpjp2.so” 1 komutu girilmelidir.

/usr/sbin altında update-alternatives --set javaplugin /usr/java/jre1.8.0_72/lib/amd64/libnpjp2.so komutu ile eklenti dosyasını kullanım için aktif hale getiriyoruz.

NOT: x86 mimarisinde update-alternatives --set javaplugin /usr/java/jre1.8.0_72/lib/i386/libnpjp2.so komutu girilmelidir.

Java kurulumunu tamamlamış bulunmaktayız.

NOT: update-alternatives --list java komutu ile sistemde yüklü olan Java kurulumlarını görebilirsiniz.

NOT: update-alternatives --list javaplugin komutu ile sistemde kurulu olan Java eklentilerini listeleyebilirsiniz.

NOT: update-alternatives --config java komutu ile birden fazla yüklü olan Java sürümü için varsayılan değer atayabilirsiniz.

NOT: update-alternatives –config javaplugin komutu ile yine sistemde tanımlı olan birden fazla Java eklentisi için varsayılan değer atayabilirsiniz.

NOT: java -version komutu ile varsayılan Java paketi ile ilgili teknik detay alabilirsiniz.

Firefox üzerinde Java sürümünün çalıştığını doğruluyoruz.

Java kurulumu tamamlandıktan sonra artık SAP GUI Java kurulumuna geçebiliriz. Konsol üzerinde önceden indirdiğimiz kurulum dosyalarımızın bulunduğu dizine gidiyoruz.

NOT: SAP Support Portal üzerinden indirilen kurulum dosyasında Linux sistemine ilave olarak Mac OS X ve Windows içinde SAP GUI Java kurulum dosyaları gelmektedir.

java -jar PlatinGUI740Linux_4.jarkomutu ile kurulumu başlatıyoruz.

Kurulum komutundan sonra önümüze kurulum sihirbazı geliyor ilgili bilgilendirmeleri geçerek kuruluma başlıyoruz.

NOT: Kurulum sırasında yükleme ve log dosyasının tutulduğu dizini not almanızda fayda var.

Linux için SAP GUI Java kurulumu tamamlanmış bulunmakta. Kurulum sonrası masaüstünüze kısayol oluşturulmadı ise Application > Office altında uygulama kısayolunu oluşturabilirsiniz.

SAP GUI uygulamasını çalıştırıp New butonu ile SAP uygulama sunumuzun bağlantı bilgilerini giriyoruz.

Advanced sekmesiüzerinde Expert Mode aktif edip bağlantı parametremizi girip, ayarları kaydediyoruz.

NOT: Bağlantı için farklı parametreler bulunmaktadır;

-        Tek bir SAP uygulama sunucusu kullanıyorsak

conn=/H/SAPSERVERIP/S/INSTANCEPORT (conn=/H/10.0.20.220/S/3200)

-        Birbirini yedekleyen iki uygulama sunucusuna sahipseniz (bkz. Logon Group SMLG tcode)

conn=/M/SAPSERVERIP/S/MESSAGESERVERPORT (conn=/M/10.0.20.220/S/3600)

İlk bağlantı esnasında gelen güvenli bağlantı seviyesini belirliyoruz.

SAP GUI Java kurulumu ve bağlantı ayarlarını tamamlamış bulunuyoruz.

Makalemin sonuna geldik, umarım faydalı bir makale olmuştur.

Günümüzde, özellikle IT sektöründe çalışan personeller artık yavaş yavaş, tam anlamıyla bir göç olmasa da Linux tarafına geçmeye başladılar. Birçok kurum ve firma kullanıcılarını yönetebilmek için bu alanda kolaylık ve esneklik sağlamak için Active Directory ile çalışmakta. Doğal olarak böyle ortamlarda Linux türevi bir işletim sistemi ile çalışmak için biraz uğraşmak gerekiyor.

Tabi ki büyük yapılarda bazı alışkanlıklardan ve zorunluluklardan vazgeçmek veya onları yok saymak pek mümkün olmuyor.

Buradan hareketle linux kurup kullanmak isteyen arkadaşlara Windows sharing ya da Windows File Server ortamını Linux işletim sistemine otomatik olarak nasıl bağlayacaklarını(mount) anlattığım bu dökümanı hazırladım.

Ben işletim sistemi olarak Ubuntu 12.04 kullanıyorum. Ubuntu gibi Debian geleneğinden gelen bütün işletim sistemleri için adımlar aşağı yukarı aynıdır. Ancak paket yönetim sistemi farklı olan Red-Hat, Solaris vs.vs. için değişiklik yapmanız gerekebilir.

Kurulum sırasında vi text editörünü kullanıyor olacağım.  vi linux üzerinde kullanılan bir text editördür. Genellikle varsayılan olarak Linux işletim sistemi ile birlikte gelir. Vi yerine nano ya da piko gibi text editörler de kurup kullanabilirsiniz. Vi ile ilgili bu dokümanda yazanları yapabilmek için pratik birkaç bilgi;

• vi ile dosya açtıktan sonra “i” harfine basıldığında insert mod'a geçilir ve dosya içinde karakterler yazılabilir.
• Insert modundan çıkmak için Esc butonu kullanılır.
• vi'den kaydedip çıkmak isterseniz Esc butonuna bastıktan sonra en altta aktif olan satıra wq! komutu verilerek işlemi tamamlayabilirsiniz.

Öncelikle Windows ile Linux arasında bir bağ kurmak için cifs protokolünü kuracağız. Aşağıdaki komut ile paketleri kuralım,

# sudo apt-get install cifs-utils

cifs utils kurulduktan sonra gerekli düzenlemeleri yapıyoruz. Linux sistemimizde File Server’da bulunan klasör için bir bağlantı noktası oluşturacağız;

# mkdir /home/Linux_Kullanıcısı/Desktop/FileServer

komutu ile Linux Kullanıcımızın masaüstünde FileServer adında bir klasör oluşturuyoruz. Bu klasör şu anda Linux sistemimize login olan reel kullanıcımızın masaüstüne gelecektir.

Şimdi ise aşağıdaki komut ile /etc dizininin altında cifs protokolünün kullanacağı Windows kullanıcısının hesap bilgilerini gireceğimiz bir dosya oluşturuyoruz ve aşağıdaki şekilde dosyanın içeriğini düzenliyoruz;

# sudo vi /etc/cifs_ayar

Yukarıdaki şeklini kendi bilgilerimize göre değiştirip bu dosyayı kaydederek çıkıyoruz. Daha sonra aşağıdaki komut ile cifs_ayar dosyasının sahipliğini geçerli Mustafa kullanıcısına ve grubuna veriyoruz.

# sudo chown mustafa.mustafa /etc/cifs_ayar

Linux işletim sistemleri varsayılan olarak /etc/fstab dosyasında yazan diskleri her açılışta mount edip kullanırlar. Bizde otomatik bir düzene bağlamak için bu dosyaya network üzerinden erişeceğimiz file server ile ilgili bilgileri gireceğiz ve disk olarak artık file server'ımızı kullanabileceğiz. Fstab dosyasınız düzenlemek için şu komutu veriyoruz

# sudo vi /etc/fstab

Ve en alt satıra aşağıdaki gibi ekleme yapıyoruz. Buradaki içerik sizin düzenlemeleriniz doğrultusunda değişmelidir.

//sunucu/dosya_adi  /home/user/FileServer/  cifs exec,credentials=/etc/cifs_ayar,rw,uid=mustafa        0      0

Bu satırı ekledikten sonra çıkıyoruz.

Artık işlemlerin problemsiz tamamlandığını control edebiliriz. Aşağıdaki komut ile hemen test edebiliriz. Eğer herhangi bir problem yoksa ekran görüntüsü aşağıdaki gibi olacaktır.

# sudo mount – a

Sistemi restart ettikten sonra herhangi bir uyarı almadıysanız ve masaüstünüzde network diskiniz sorunsuz bağlandı ise problem yok ve her şey yolunda demektir. Aşağıda görebilirsiniz.

Burada dikkat edilmesi gereken nokta; Eğer Windows üzerindeki hesabınızın şifresini değiştirirseniz,

# sudo vi /etc/cifs_ayar

Dosyası içindeki şifre kısmını yenilemeniz gerekecektir. Yenileme yapmazsanız klasör bağlantısı gerçekleşmeyecek, klasör içeriğini göremeyeceksiniz.

Yaptıklarımızı adım adım yazalım;

·        Cifs_utils’in paket kurulumunu yaptık

·        Paylaşımı bağlamak üzere bilgisayarımızda FileServer adında bir klasör oluşturduk.

·        /etc dizini altında cifs_ayar adında domain kullanıcı adı ve şifresini barındıran bir dosya oluşturup sahipliğini kullanıcımıza verdik.

·        Paylaşımın her açılışta otomatik olarak bağlanabilmesi için fstab dosyasını düzenledik.

Faydalı olması dileğiyle…

Bu makalemizde, mevcut yapıda bulunan bir Windows Server 2012 Active Directory Domain yapısına Centos 6.5 işletim sisteminin dahil edilmesi işlemlerinden bahsediyor olacağız.

Windows Server 2012 işletim sistemi ile çalışan bir  Active Directory Domain yapısına, Centos işletim sistemini dahil etmemiz için, ilk önce Centos sunucumuza root kullanıcımız ile login oluyoruz.

Centos sunucumuza login işleminin ardından üst menüden Systemà PreferencesàNetwork Connections seçeneklerine tıklıyoruz.

Editing System eth0 ekranında, IPV4 Settings menüsü içerisinden IP ayarlarımızı static yapmak için Manual seçeneğine tıklıyoruz.

Addresses kısmında, Add diyerek Centos sunucumuza ait IP adresi, Netmask ve Gateway bilgilerini giriyoruz. DNS Servers kısmında ise, DNS Server sunucumuzun IP adresini giriyoruz. DNS Server servisi DC sunucum üzerinde bulunduğu için ben bu bölüme DC sunucumun IP adresini yazıyorum. Son olarak, Search domains bölümüne domain ismimizi yazıp Apply diyoruz. Tüm bu işlemlerden sonra, centos sunucumuz üzerinde terminal ekranını açıp aşağıdaki komutu çalıştırarak samba ve winbind paketlerini sunucumuza download ediyoruz.

“yum install samba-winbind –y”

Samba ve Winbind paketlerinin kurulumunun ardından üst menüden Systemà Administratironà Authentication seçeneklerine tıklıyoruz.

Identitiy Authentication menüsü içerisinde User Account Database kısmından Winbind seçeneğini seçiyoruz.

Winbind seçeçenğinin ardından, yine aynı ekran üzerinde ilgili kısımlara domain bilgilerimizi girdikten sonra Advanced Options tabına geçiş yapıyoruz.

Advanced Options tabı içerisinden Create home directories on the first login seçeneğini seçip Apply diyoruz. Apply işleminden sonra domain join işlemi için Identity Authentication kısmından Join Domain seçeneğine tıklıyoruz.

Join Domain işleimin ardından karşımıza bir uyarı ekranı çıkmakta. Bu uyarı ekranında bize, mevcut konfigurasyonda bazı değişiklikler yaptığımızı, yaptığımız bu değişikliklerin domain ‘ e alma işleminde  bazı sorunlara neden olabileceği yönünde bize uyarı verilmekte. Biz Save diyerek ayarları kaydediyoruz.

Joining Winbind Domain ekranında, Domain Admin ve Password bilgilerini yazıp OK diyoruz.

OK işleminin ardından DC sunucum üzerinde Active Directory Users and Computers yönetim konsolu içerisinde Computers tabı altında centos sunucumun gelmiş olduğunu görüyorum.

Centos sunucum üzerinde de domain içerisinde açmış olduğum test kullanıcısı ile login olmayı deniyorum.

Test kullanıcıma ait şifreyi girip Log In diyorum.

Yukarıdaki şekil üzerinde de görüldüğü gibi sunucumuza login işlemimiz başarılı bir şekilde gerçekleşti. Üst kısımda da test kullanıcımız ile giriş yaptığımız görünmekte.

Consol üzerinde pwd komutu ile control işlemi gerçekleştirdiğimizde, home klasörü altında TEST2012 domain’imizi görmekteyiz.

Evet, bu makalemizde, Windows Server 2012 Active Directory Domain yapısına Linux Centos sunucu dahil edilmesi işlemlerinden bahsettik. Bir sonraki makalemde görüşmek üzere hoşcakalın.