22 Mayıs 2019 Çarşamba

Linux tabanlı bir sistem kurulumu yaparken nelere dikkat etmeliyim

Linux tabanlı bir işletim sistemi kurulurken, ilerleyen zamanlarda sorun çıktığında çözülmesini kolaylaştırmak veya sorunun etkisini azaltmak için genel amaçlar için kurulumu yapılacak sistemlerde  dikkat etmemiz gerekenler;

1. lvm'siz  bir sistem düşünmemek gerekiyor(istisnalar hariç)

2. işletim sistemimiz btrf dosya sistemini destekliyorsa, root bölüm için btrfs kullanılmalı ve snapper aktif olacak şekilde ayarlanmalı.  Diger bölümler(home vs.) xfs olmalı.

3. boot bölümüne 1GB alan ayırın. Bu çok büyük gibi görünsede, bir kaç yıl sonra,
eski kernellerin otomatik temizlenmemesinden(genelde unutulur) dolayı, fazla değildir.
Şayet gönün birinde boot dolur ve güncellemede kernel güncellemesi yarım kalırsa, sistem yeniden başladığında başınız ağrıyabilir.

4.  /var, /var/log, /tmp ve home bölümleri  ayrı bir lv içinde tutulmalı.
     Bu şekilde kullanım, kontrol edilip temizlenmeyen günlük veya geçici dosyaların sistemi çalışamaz hale gelmesi olasılığını azaltır, en azından log dizini dolsa bile uygulamalarınız çalışır, sadece günlükler güncellenemez. 

ilave olarak arbt ve  kdump kullaniliyorsa, 

/var/spool/abrt/

/var/crash

bolumleri unutulmamali. abrt ve crash bölümlerini en az ram miktarı kadar yapılması gerekmektedir.

mail, squid gibi uygulamalar da

/var/spool  

dizini kullanir ve kullanilmakta olan disk bolumunu doldurabilirler.

Boyle bir olumsuzlugu onlemek icin spool ve/veya spol altındaki ilgili bölümü ayrı bir lv üzerine almak sistem sağlığı icin doğru olacaktir.

5. Volum grubun tamamın kullanıma verilmemeli, en azından %10 bir bölüm, beklenmedik ihtiyac ve durumlara karşı, boş tutulmalı.

6. Sistem ram kapasitesi yeterliyse, /tmp tmpfs olarak ram kullanacak şekilde ayarlanmalı.

7. sistem saatinin düzgünlüğünü sağlamak için ntp kullanılmalı (eski sistemlerde ntp, yeni sistemlerde chrony service ayarlanması )

8. root ile sisteme giriş önlenmeli, kullanıcıların root yetkisine ihtiyacı varsa, kendi kullanıcılarıyla giriş yaptıktan sonra sudo ile root yetkilerini kullanmaları

9. rhel 7 veya rhel 8 tabanli sistemlerde /var/log/journal dizini olusturulmali.

Varsayilan olarak journal/systemd loglari hafizada tutuluyor ve sistem yeniden baslatildiginda veya kapatildiginda loglara gule gule diyoruz.

journalctl ile gecmise yonelik loglari asagidaki gibi inceleyebiliriz.

 journalctl --since "2019-11-28 15:24" --until "2019-12-29 12:00"

Bu incelemeyi yapabilmemiz icin yukarida bahsettigimiz, /var/log/journal dizini olusturulmus ve sahiplik yetkileri duzgun ayarlanmis olmasi gerekiyor.

journaldir="/var/log/journal"
mkdir        ${journaldir}                                      
chown          root:systemd-journal ${journaldir}
chmod         2755                           ${journaldir}

Bu islemden sonra sistem yeniden baslatilma veya systemd-journald yeniden baslatilmali.

Alternatif  yöntem olarak; /etc/systemd/journald.conf  dosyasında storage modunu  persistent yapmaktır. Detaylı bilgiler için man journald.conf


10. Her ne kadar selinux kullanımı zor olsada, selinux kapatmamalı, selinux nasıl kullanacağımızı öğrenmemiz gerekir.

11. Sunucu, dış dünyaya direk açık ise, firewall + fail2ban kesinlikle ayarlanmalı, istekler firewalld/iptables/ipset gibi araçlar yardımıyla servise gelmeden sınırlandırılmalıdır.
      Sınırlandırma iyi görünmesede, sisteme aşırı yük gelmesi veya saldırı esnasında tamamen kullanılmaz olmasını önleyerek, sistemin çalışmasını devam ettirmesine yardımcı olacaktır.

12. ssh/sssd gibi önemli servislerin OOM killerdan korumak OOMScoreAdjust değerini -1000 yapmak. -1000 ölümsüz (immutable) anlamına geliyor.

# mkdir /etc/systemd/system/sshd.service.d
# vi /etc/systemd/system/sshd.service.d/100-OOMscore.conf
[Service]
OOMScoreAdjust=-1000
# systemctl daemon-reload
# systemctl restart sshd

 

13. Mümkünse swap için farklı bir disk kullanmak. Özellikle uygulamlardan kaynaklanan ram tüketiminde, sisteme müdahale edebilmemiz için swap ayrı bir disk olurması faydalıdır. Ne olursa olsun swap kullanım sorunu çözülmesi gereken bir nokta olduğunuda unutmayalım.

 

Linux tabanlı bir sistem kurulumu yaparken nelere dikkat etmeliyim

Linux tabanlı bir işletim sistemi kurulurken, ilerleyen zamanlarda sorun çıktığında çözülmesini kolaylaştırmak veya sorunun etkisini azaltmak için genel amaçlar için kurulumu yapılacak sistemlerde  dikkat etmemiz gerekenler;

1. lvm'siz  bir sistem düşünmemek gerekiyor(istisnalar hariç)

2. işletim sistemimiz btrf dosya sistemini destekliyorsa, root bölüm için btrfs kullanılmalı ve snapper aktif olacak şekilde ayarlanmalı.  Diger bölümler(home vs.) xfs olmalı.

3. boot bölümüne 1GB alan ayırın. Bu çok büyük gibi görünsede, bir kaç yıl sonra,
eski kernellerin otomatik temizlenmemesinden(genelde unutulur) dolayı, fazla değildir.
Şayet gönün birinde boot dolur ve güncellemede kernel güncellemesi yarım kalırsa, sistem yeniden başladığında başınız ağrıyabilir.

4.  /var, /var/log, /tmp ve home bölümleri  ayrı bir lv içinde tutulmalı.
     Bu şekilde kullanım, kontrol edilip temizlenmeyen günlük veya geçici dosyaların sistemi çalışamaz hale gelmesi olasılığını azaltır, en azından log dizini dolsa bile uygulamalarınız çalışır, sadece günlükler güncellenemez. 

ilave olarak arbt ve  kdump kullaniliyorsa, 

/var/spool/abrt/

/var/crash

bolumleri unutulmamali. abrt ve crash bölümlerini en az ram miktarı kadar yapılması gerekmektedir.

mail, squid gibi uygulamalar da

/var/spool  

dizini kullanir ve kullanilmakta olan disk bolumunu doldurabilirler.

Boyle bir olumsuzlugu onlemek icin spool ve/veya spol altındaki ilgili bölümü ayrı bir lv üzerine almak sistem sağlığı icin doğru olacaktir.

5. Volum grubun tamamın kullanıma verilmemeli, en azından %10 bir bölüm, beklenmedik ihtiyac ve durumlara karşı, boş tutulmalı.

6. Sistem ram kapasitesi yeterliyse, /tmp tmpfs olarak ram kullanacak şekilde ayarlanmalı.

7. sistem saatinin düzgünlüğünü sağlamak için ntp kullanılmalı (eski sistemlerde ntp, yeni sistemlerde chrony service ayarlanması )

8. root ile sisteme giriş önlenmeli, kullanıcıların root yetkisine ihtiyacı varsa, kendi kullanıcılarıyla giriş yaptıktan sonra sudo ile root yetkilerini kullanmaları

9. rhel 7 veya rhel 8 tabanli sistemlerde /var/log/journal dizini olusturulmali.

Varsayilan olarak journal/systemd loglari hafizada tutuluyor ve sistem yeniden baslatildiginda veya kapatildiginda loglara gule gule diyoruz.

journalctl ile gecmise yonelik loglari asagidaki gibi inceleyebiliriz.

 journalctl --since "2019-11-28 15:24" --until "2019-12-29 12:00"

Bu incelemeyi yapabilmemiz icin yukarida bahsettigimiz, /var/log/journal dizini olusturulmus ve sahiplik yetkileri duzgun ayarlanmis olmasi gerekiyor.

journaldir="/var/log/journal"
mkdir        ${journaldir}                                      
chown          root:systemd-journal ${journaldir}
chmod         2755                           ${journaldir}

Bu islemden sonra sistem yeniden baslatilma veya systemd-journald yeniden baslatilmali.

Alternatif  yöntem olarak; /etc/systemd/journald.conf  dosyasında storage modunu  persistent yapmaktır. Detaylı bilgiler için man journald.conf


10. Her ne kadar selinux kullanımı zor olsada, selinux kapatmamalı, selinux nasıl kullanacağımızı öğrenmemiz gerekir.

11. Sunucu, dış dünyaya direk açık ise, firewall + fail2ban kesinlikle ayarlanmalı, istekler firewalld/iptables/ipset gibi araçlar yardımıyla servise gelmeden sınırlandırılmalıdır.
      Sınırlandırma iyi görünmesede, sisteme aşırı yük gelmesi veya saldırı esnasında tamamen kullanılmaz olmasını önleyerek, sistemin çalışmasını devam ettirmesine yardımcı olacaktır.

12. ssh/sssd gibi önemli servislerin OOM killerdan korumak OOMScoreAdjust değerini -1000 yapmak. -1000 ölümsüz (immutable) anlamına geliyor.

# mkdir /etc/systemd/system/sshd.service.d
# vi /etc/systemd/system/sshd.service.d/100-OOMscore.conf
[Service]
OOMScoreAdjust=-1000
# systemctl daemon-reload
# systemctl restart sshd

 

13. Mümkünse swap için farklı bir disk kullanmak. Özellikle uygulamlardan kaynaklanan ram tüketiminde, sisteme müdahale edebilmemiz için swap ayrı bir disk olurması faydalıdır. Ne olursa olsun swap kullanım sorunu çözülmesi gereken bir nokta olduğunuda unutmayalım.

 

Ubuntu dağıtımlarında yeni açılan kullanıcının home dizinin varsayılan yetkilerinin değiştirilmesi

Ubuntu tabanlı sistemlerde varsayılan olarak tüm kullanıcılar bir birlerinin dizinlerini ve dosyalarını görebilir fakat değiştiremez.
Bunun nedeni;
                         /etc/adduser.conf
dosyasındaki
                       DIR_MODE=0755

Şayet kullanıcılar bir birlerinin home dizinlerini görmemesini istiyorsak dir_mode değeri 0700

                      DIR_MODE=0700

olmalı.

İlave olarak kullanıcıların açtığı dizin ve dosyaları varsayılan olarak diğer kullanıcılar görebilir ve okuyabilir. Bunun önlemenin en basit yolu umask değerini 0077 yapmaktan geçer.

remzi@i7-7567:/tmp/test$ umask
0077
remzi@i7-7567:/tmp/test$ rm -rf *
remzi@i7-7567:/tmp/test$ ls -la
total 8
drwxrwxr-x  2 remzi remzi 4096 May 22 19:37 .
drwxrwxrwt 26 root  root  4096 May 22 19:33 ..
remzi@i7-7567:/tmp/test$ touch testfile
remzi@i7-7567:/tmp/test$ mkdir testdir
remzi@i7-7567:/tmp/test$ ls -al
total 12
drwxrwxr-x  3 remzi remzi 4096 May 22 19:38 .
drwxrwxrwt 26 root  root  4096 May 22 19:33 ..
drwx------  2 remzi remzi 4096 May 22 19:38 testdir
-rw-------  1 remzi remzi    0 May 22 19:38 testfile
remzi@i7-7567:/tmp/test$


umask değerinin tüm sistem değiştirmek istiyorsak  login.defs içindeki değeri düzenlememiz gerekmektedir.
/    etc/login.defs
# Varsayılan değer
# UMASK           022
# Güvenlik nedeniyle değiştirilen yeni değer
UMASK 0077


Ubuntu sürümlerini indirebileceğimiz ana sunucu:
http://releases.ubuntu.com/

16 Nisan 2019 Salı

Disk bölümle tablosunu sfdisk ile yedeklemek

Bir diskin bölümle tablosunu yedeklemenin bir çok yöntemi vardır.
Bu yöntemlerden bir taneside sfdisk ile dump almak.

Örnek;

root@i7567:~# sfdisk -d /dev/sda
label: gpt
label-id: A81880A3-3FDD-4295-B137-ACA3FABECA05
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/sda1 : start=        2048, size=     1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=184574EE-5795-422F-9071-318E3048D2B5
/dev/sda2 : start=     1050624, size=     1499136, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=7226C316-4A0A-471E-A80A-F55AB21762D0
/dev/sda3 : start=     2549760, size=   497567744, type=E6D6D379-F507-44C2-A23C-238F2A3DF928, uuid=59F46E76-1F70-4D31-9788-1F184C55A3F5
root@i7567:~#


# sfdisk -d /dev/sda > sda-dump.txt

kazara disk bölümle tablosunda yalnış bir şey yaparsak,

sfdisk /dev/sda <  sda-dump.txt

Disk bölümle tablosunu eski haline getirebiliriz.



Akü deyip geçmeyelim

Bu günlerde havaların yağışlı ve rüzgarlı olması  nedeniyle uzun süreli motosiklet kullanamadım.
Durum böyle olunca, motosikletteki mevcut akü yeteri kadar dolmuyor ve motoru çalıştırırken, özellikle soğuk havalarda, sıkıntı oluşmaya başladı. Mevcut akü, 10 yılını aşmış bir akü oluncada, artık yeni bir akü alayım dedim. Kalite/Fiyat oranını göz önüne alarak bosch M6-012 aküsünü almaya karar verdim ve aldım.


Değişik bir akü, akünün kutusunda, içine konacak özel bir asit geliyor.
Yalnız içine sıvısını koyuyorsunuz ve yaklaşık yarım saat bekliyorsunuz.
Yarım saat sonra akünün içinde sıvı yerine özel bir jel oluşmuş oluyor.
Sonrasında şarj bağladım ve 6-7 saatte şarj oldu.



Akünün tipi AGM olarak geçiyor ve şarj ederken dikkatli olmak lazım.

Aküyü motosiklete takıp, marşa basdığımda direk çalıştı. 

Motosiklek kullananlara Bosch M6 serisi aküleri tavsiye ederim.

İlave olarak aküm satın aldığım firmadaki ilgili arkadaş, şayet uzun süreli kullanım olmaz ve akü tam şarj olmaz ise, iki ayda bir söküp şarj cihazı ile akünün şarjının tamamlamamı tavsiye ettim.






Akü deyip geçmeyelim

Bu günlerde havaların yağışlı ve rüzgarlı olması  nedeniyle uzun süreli motosiklet kullanamadım.
Durum böyle olunca, motosikletteki mevcut akü yeteri kadar dolmuyor ve motoru çalıştırırken, özellikle soğuk havalarda, sıkıntı oluşmaya başladı. Mevcut akü, 10 yılını aşmış bir akü oluncada, artık yeni bir akü alayım dedim. Kalite/Fiyat oranını göz önüne alarak bosch M6-012 aküsünü almaya karar verdim ve aldım.


Değişik bir akü, akünün kutusunda, içine konacak özel bir asit geliyor.
Yalnız içine sıvısını koyuyorsunuz ve yaklaşık yarım saat bekliyorsunuz.
Yarım saat sonra akünün içinde sıvı yerine özel bir jel oluşmuş oluyor.
Sonrasında şarj bağladım ve 6-7 saatte şarj oldu.



Akünün tipi AGM olarak geçiyor ve şarj ederken dikkatli olmak lazım.

Aküyü motosiklete takıp, marşa basdığımda direk çalıştı. 

Motosiklek kullananlara Bosch M6 serisi aküleri tavsiye ederim.

İlave olarak aküm satın aldığım firmadaki ilgili arkadaş, şayet uzun süreli kullanım olmaz ve akü tam şarj olmaz ise, iki ayda bir söküp şarj cihazı ile akünün şarjının tamamlamamı tavsiye ettim.






11 Nisan 2019 Perşembe

Chrony ve ntp

Artik ntp paketinin yerini chrony aldığını  kabul ettiğimiz için, eski notları aşağıya doğru kaydırıp, biraz chrony üzerine not ekleyelim dedim.

 

 Sistemimiz bir ntp server ile senkronize ederken chrony.conf ayarlarında dikkat etmemiz gerekenler;

Her şeyden önce en az iki tane kullanılabilir durumda ntp server olmalı.

Şayet işimizde saat çok önemli ve hayati bir durumda ise tavsiyem, donanımsal zaman sunucusu almanız. Bu konuda yerli ürünlerde varmış, fakat yerli ürünler hakkında tecrübem yok. Tecrübesi olanlar paylaşabilir.

Donanımsal ntp sunucularını merak ediyorsanız;

https://www.google.com/search?client=firefox-b-d&q=hardware+ntp+server

Yahu bu ürünler pahalı, okadarda  para veremiyoruz diyorsanız üç tane raspberry pi 4 ve gerekli aksesuarlarını alarak kendiniz yapabilirsiniz. 

https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

rpi4 leri rct ve ups hat olmadan ntp server olarak kullanmanızı önermem.

Detaylı bilgi için google/yandex yardımcı olacaktır.


Genelde bir ntp server kurulduğunda ilk 10-15 dakika kullanılabilir durumda olmaz. ntp serverımızı kendimiz kurduysak 10-15 dakika beklemeyi unutmayalım.


1. server ve/veya pool ayarlarında iburst olmalı

# server 192.168.0.11 iburst
# server 192.168.0.1   iburst

2. Donanım saatini senkronize etmeyi unutmamak gerekli, bunun içinde 

# rtcsync
paramatresinin aktif olduğundan emin olalım.

3. En az kullanılabilir kaynak sayısını bire eşitleyelim.

Özellikle yapımızda iki tane sağlam ve esas görevi ntp sunuculuğu olan bir sistem veya donanım yoksa.

# minsources 1

 

4. Eğer kendimizi senkronize edecek, kullanılabilir ntp sunucusuna ulaşamadıysak, kendimizi taban alarak ntp servisini çalışmaya devam etsin.

# local stratum 10


 

 Bunlara dikkat ederek yapılandırma yaptıkdan sonra chrony servisini başlattıkdan sonra yapmamız gereken temel kontroller;

Zaman kaynaklarıyla aramızın nasıl olduğunu kontrol etmekle başlayabiliriz.



Yukarıda gördüğünüz gibi chrony en iyi  ve kullanılabilir durumdaki ntp sunucusu olan _gateway ile kendisini senkronize etmiş durumdadır.

Şayet ciddi bir zaman farkı oluşmuş ve  bu farklılıktan dolayı senkronize yapılamadığı durumlarda, elle "burst 4/4 ve makestep" komutları yardımıyla senkronize yapabiliriz;

chronyc>
chronyc> burst 4/4
200 OK
chronyc> makestep
200 OK

 Şimdi sistem saatini elle değiştirerek ntp servisini şaşırtalım;

Bunun için  saati yaklaşık 1 saat geriye alıyoruz.

Yukarıda gördüğünüz gibi artık senkronize bozulmuş ve otomatik senkronize olmamaktadır.

 

Durumu kurtarmak için chronyc'ye makestep işlemini yap diyoruz ve saatimiz düzeliyor.

 

Biz bu işlemleri yaparken chrony günlük kayıtlarında neler olmuş bakalım;


 

 Feb 23 11:30:52 fedora.example.lan chronyd[623542]: System clock was stepped by 4109.747761 seconds
Feb 23 10:20:26 fedora.example.lan chronyd[623542]: Selected source 192.168.0.1
Feb 23 10:20:25 fedora.example.lan chronyd[623542]: System clock wrong by 4118.746416 seconds
Feb 23 10:20:25 fedora.example.lan chronyd[623542]: Selected source 194.27.156.207 (2.fedora.pool.ntp.org)
Feb 23 10:20:22 fedora.example.lan chronyd[623542]: System clock was stepped by -0.000000 seconds
Feb 23 10:20:14 fedora.example.lan chronyd[623542]: Can't synchronise: no selectable sources
Feb 23 10:20:14 fedora.example.lan chronyd[623542]: Backward time jump detected!
Feb 23 11:28:14 fedora.example.lan chronyd[623542]: Selected source 192.168.0.1
Feb 23 11:28:13 fedora.example.lan chronyd[623542]: System clock was stepped by 4028.910894 seconds
Feb 23 10:21:03 fedora.example.lan chronyd[623542]: System clock wrong by 4028.962868 seconds
Feb 23 10:21:03 fedora.example.lan chronyd[623542]: Selected source 192.168.168.223
Feb 23 10:20:26 fedora.example.lan chronyd[623542]: Can't synchronise: no selectable sources
Feb 23 10:20:26 fedora.example.lan chronyd[623542]: Backward time jump detected!
Feb 23 11:22:40 fedora.example.lan chronyd[623542]: System clock was stepped by 0.000037 seconds
Feb 23 11:21:14 fedora.example.lan chronyd[623542]: System clock was stepped by -0.000000 seconds
Feb 23 10:44:19 fedora.example.lan chronyd[623542]: System clock TAI offset set to 37 seconds


Yukarıda görüldüğü gibi zamanda geriye sıçrama olduğu görülmüş, fakat senkronize yapılamamıştır. makestep yapınca zaman ayarlanmıştır.



 

 

######################NTP######################
ntp sunucumuz günün birinde, her hangi bir değişiklik nedeniyle, master ntp sunucularından zamanı alamayarak senkronize olamazlarsa, kullanılamaz duruma düşerler.
Bu durumda ntp servisini kullanılabilir hale getirmenin yolu, ntp çalışan sistemin yerel saatini almasını sağlayarak, ntp servisini kullanılabilir hale getirebiliriz. Şayet mevcut sunucudan başka kullanılabilecek ntp sunucusu olmadığında, sistemin kendi saatini alabiliriz.

Yerel saati kullanabilmemiz için ntp.conf'a ilave etmemiz gereken satırlar;
server 127.127.1.0
fudge 127.127.1.0 stratum 10


yapılandırmayı düzenleyip, ntp servisini yeniden başlattıktan sonra ntpq ile servisi kontrol edebiliriz.


root@node13 ~ # ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 36159  961a   yes   yes  none  sys.peer    sys_peer  1

root@node13 ~ # ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l   33   64  377    0.000    0.000   0.000
root@node13 ~ # systemctl restart ntp
root@node13 ~ #


# ntpdate -u 192.168.80.254
11 Apr 19:06:23 ntpdate[1231]: adjust time server 192.168.80.254 offset -0.058454 sec



Güncel linux dağıtımlarında ntpd yerine chrony kullanılmaya başlamıştır. Bundan dolayı, chrony için
/etc/chrony.conf içerisine
server 127.127.1.0
local stratum 10
allow 192.168.253.0/24

satırlarını ekleyerek ntpd servisi çalıştırılabilir. allow satırı ihtiyaca göre değiştirilir.

Ne işe yarar; sar -n DEV

sar -n DEV|awk 'BEGIN{mak=0} !/txpck|x86|CPU|^[ \t]*$/{if (mak