DEV Community: Berkant

Nexus 002

Berkant — Wed, 29 Oct 2025 20:11:53 +0000

Sonatype Nexus ile ilgili ilk yazıya buradan ulaşabilirsiniz.

Bu yazıda aşağıdaki konuları ele alacağız.

Nexus u HTTPS Olarak Çalıştırma
Docker Reposu Ayarlama
Reverse Proxy Yapılandırması
Nexus Sürümünü Güncelleme
LDAP Bağlantısı

1) Nexus u HTTPS Olarak Çalıştırma

Nexus web arayüzü varsayılan olarak 8081/tcp portundan http protokolü ile çalışıyor. Başka bir porttan HTTPS protokolü ile çalışabilmesi için SSL sertifikasına ihtiyacımız var.
nexus.pfx (Nexus Web Arayüzü için Kullanacağım SSL Sertifika)
run > certlm.msc > Personal > All Tasks > Request New Certificate > Web Server Template

Subject Bölümü
Subject Name > Common Name : nexus.alanadı
Subject Name > Common Name : nexus
Alternative Name > DNS : nexus.alanadı
Alternative Name > IP(v4) : serverIP
Private Key Bölümü
Key Options > Make Private Key Exportable

Sertifika dosyasını (nexus.pfx) nexus u kurduğum sunucuya atıp keytool komutuyla nexus un kullanabileceği şekle getiriyorum.

keytool -importkeystore -srckeystore nexus.pfx -srcstoretype PKCS12 -destkeystore nexus-jks.jks -deststoretype JKS

!!!keytool komutu için /opt/nexus/jdk/temurin_XYZ/jdk-XYZ/bin/ dizinini kullanabiliriz.

Nexus web sunucusu olarak java tabanlı "Eclipse Jetty" kullanıyor.
/opt/sonatype-work/nexus3/etc/nexus.properties dosyasını aşağıdaki şekilde düzenliyorum(application-port-ssl ve nexus-args satırlarını ekledim)
HTTPS protokolü için 9091/tcp portunu kullanacağım.
nexus-args bölümünde de http yi devre dışı bırakıp https i kullanacağımızdan jetty-http yerine jetty-https yazıyoruz.

/opt/nexus/etc/jetty/jetty-https.xml dosyasında "password" geçen satırları , yukarıda keytool komutuyla girdiğimiz parolayla değiştiriyoruz.
/opt/nexus/etc/ssl dizinine daha önceden oluşturduğumuz nexus-jks.jks dosyasını keystore.jks olarak atıyoruz.

2) Docker Reposu Ayarlama

Blob Store Oluşturma

Oluşturduğum repoların nereyi ve ne kadar alan kullandığını görebilmek ve yönetebilmek için blob store oluşturuyorum.
Oluşturduğum blobstore u da ayrı bir bölüm olarak bağlıyorum (yeni bir lv oluşturup )sunucuma. Bu sayede sadece ilgili reponun blobstore unu büyütüp diğer yerleri etkilemeden devam ediyorum.

Docker Repo Oluşturma

Repository > Repositories > Docker (hosted) seçiyorum. Açılan sayfadan repo ismi , bağlayıcı (connector) , blob store u seçiyorum.

Docker Reposuna Bağlanma

**docker login* komutuyla nexus üzerinden çalıştırdığım docker reposuna giriş yapıyorum.

[berkant@ol9gui ~]$ docker login nexus.linux.local:11011
Username: admin
Password: 
....
....
Login Succeeded

Sunucuda bulunan d49 numaralı imajı etiketleyip , nexusta barındırdığım docker reposuna yolluyorum.


berkant@ol9gui ~]$ docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
nginx        alpine    d4918ca78576   39 hours ago    52.8MB
nginx        latest    9d0e6f6199dc   40 hours ago    152MB
busybox      latest    08ef35a1c3f0   13 months ago   4.43MB


[berkant@ol9gui ~]$ docker tag nginx:alpine nexus.linux.local:11011/docker/nginx:alpine

[berkant@ol9gui ~]$ docker image ls | grep nexus
nexus.linux.local:11011/docker/nginx   alpine    d4918ca78576   39 hours ago    52.8MB


[berkant@ol9gui ~]$ docker push nexus.linux.local:11011/docker/nginx:alpine
The push refers to repository [nexus.linux.local:11011/docker/nginx]
25906c27b84d: Pushed 
...
...
256f393e029f: Pushed 
alpine: digest: sha256:97a145fb5809fd90ebdf66711f69b97e29ea99da5403c20310dcc425974a14f9 size: 1989

Son olarak nexus üzerinde barındırdığımız docker repomuzdan imaj çekmeyi deneyelim.

[berkant@ol9gui ~]$ docker image ls
REPOSITORY                             TAG       IMAGE ID       CREATED         SIZE
nginx                                  alpine    d4918ca78576   40 hours ago    52.8MB
nexus.linux.local:11011/docker/nginx   alpine    d4918ca78576   40 hours ago    52.8MB
....
....

[berkant@ol9gui ~]$ docker image rm d49 --force
Untagged: nginx:alpine
Untagged: nginx@sha256:b3c656d55d7ad751196f21b7fd2e8d4da9cb430e32f646adcf92441b72f82b14
Untagged: nexus.linux.local:11011/docker/nginx:alpine
Untagged: nexus.linux.local:11011/docker/nginx@sha256:97a145fb5809fd90ebdf66711f69b97e29ea99da5403c20310dcc425974a14f9
Deleted: sha256:d4918ca78576a537caa7b0c043051c8efc1796de33fee8724ee0fff4a1cabed9
Deleted: sha256:88af9f575d6a9fa7b5a16120f2a18f8113bbe9c8345586c40d360ba3042572a1
....
....
[berkant@ol9gui ~]$ docker pull nexus.linux.local:11011/docker/nginx:alpine
alpine: Pulling from docker/nginx
2d35ebdb57d9: Pull complete 
....
....
Digest: sha256:97a145fb5809fd90ebdf66711f69b97e29ea99da5403c20310dcc425974a14f9
Status: Downloaded newer image for nexus.linux.local:11011/docker/nginx:alpine
nexus.linux.local:11011/docker/nginx:alpine

3) Ters Vekil (Reverse Proxy) Ayarlama

Şu an elimizde Nexus'un 9091/tcp portundan çalışan web arayüzü ve 11011/tcp portundan çalışan docker reposu var.
Port karmaşasıyla uğraşmamak için nexus'un bulunduğu sunucuya bir nginx kurup , yapılandıralım.
nexus.alanadı ile sunucumuza gidildiğinde sunucu o isteği 9091/tcp portuna yönlendirecek.

nexus.alanAdı >> nexus.linux.local:9091 (Web Arayüzü)

docker.nexus.alanadı ile sunucumuza gidildiğinde sunucu o isteği 11011/tcp portuna yönlendirecek.

docker.nexus.alanAdı > nexus.linux.local:11011(Docker Reposu)

4) Nexus Sürümünü Güncelleme

/opt/sonatype-work dizini veri dizinimiz , /opt/nexus dizini ise kurulumun olduğu dizin. Bu dizin, arşiv dosyasından çıkardığımız sürüm numaralı dizine bağlantılı (nexus-3.84.1-01) e. Bunu eğer güncelleyeceğimiz sürüme ayarlarsak , başarıyla Sonatype Nexus'u güncellemiş oluruz.

[root@nexus opt]# ls -alh
total 852M
drwxr-xr-x.  5 root  root  4.0K Nov 23 19:25 .
dr-xr-xr-x. 19 root  root   250 Oct 30 14:51 ..
lrwxrwxrwx.  1 nexus nexus   15 Oct 20 23:30 nexus -> nexus-3.84.1-01
drwxr-xr-x.  6 nexus nexus   94 Oct 20 23:28 nexus-3.84.1-01
-rw-r--r--.  1 root  root  417M Nov 13 00:29 nexus-3.86.2-01-linux-x86_64.tar.gz
drwxr-xr-x.  3 root  root    20 Nov 11 23:09 sonatype-work

Güncelleyeceğim sürümü arşivden çıkartıyorum. unlink ya da rm komutuyla bağlantıyı kesip yeni sürümü gösterecek şekilde bağlıyorum.

tar -xzvf nexus-3.86.2-01.-linux_x86_64.tar.gz
unlink nexus
ln -s nexus-3.86.2-01 nexus

Nexus kurulum dizininde önceki sürümde değiştirdiğim bir dosya varsa aynı değişikliği yapmalı, eklediğim bir dosya varsa yeni sürümün kurulum dizinine de eklemeliyim.

-- /opt/nexus/etc/ssl/ dizininde jks dosyası varsa onu yeni sürüme de yerleştirmeliyim.

cp /opt/nexus-3.84.1-01/etc/ssl/keystore.jks /opt/nexus-3.86.2-01/etc/ssl/ -v

-- /opt/nexus/etc/jetty/jetty-https.xml dosyasında keystore için kullandığım parolalar varsayılandan farklıysa değiştirmeliyim, eski sürümdekiyle aynı olmalı.

-- Son olarak nexus kullanıcısına yeniden sahiplik vermeliyim.

chown -Rv nexus: /opt/nexus-3.86.2-01

Vault İnce Ayarlar -- 002

Berkant — Sun, 12 Oct 2025 18:40:17 +0000

Vault kurulumunu yaptığım , ilk yazıya buradan ulaşabilirsiniz.

Vault Kurulumu -- 001

Berkant — Sun, 05 Oct 2025 19:16:11 +0000

Vault nedir

Her türlü parola , sertifika , anahtarları vb. güvenle saklamamızı(store), belirli aralıklarla değiştirmemizi(rotate), sağlayan, bu işlemleri yaparken belli aktörlere (kullanıcılar, servis hesapları vb) erişim kısıtları tanımlayabilen(RBAC) bir araçtır.

1) /opt/vault dizinini ayrı bir yere alma

Vault belgelerinde /opt/vault dizinin root bölümden ayrı tutulması öneriliyor. Sanal sunucuma yeni bir disk ekleyip, PV > VG > LV oluşturup , ardından /opt/vault olarak takacağım.

mkdir -vp /opt/vault/data /etc/vault.d
unzip vault_1.20.4_linux_amd64.zip
mv vault /usr/bin/ -v
chown -Rv root: /usr/bin/vault
sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))


sudo useradd --system --home /opt/vault/data --shell /sbin/nologin vault

sudo chown -Rv vault: /opt/vault/data && sudo chmod -Rv 750 /opt/vault/data

3) Sertifika Adımı

Sertifika çıkartmak için AD yi kullanacağım.
AD den sertifika çıkarırken dikkat edilmesi gereken noktalardan biri bu web arayüzüne erişecek ortamların(ör:linux sunucu) truststore una AD nin root/CA sertifikasını da eklemem gerekiyor.
rootcert.p7b (Sertifika Çıkardığım AD nin kök sertifikası)

run > certlm.msc > Root Certificates > Kök sertifikayı seçip "copy to file" diyorum.

openssl pkcs7 -inform DER -print_certs -in rootcert.p7b -out certificate.crt
sudo mv -v certificate.crt /etc/pki/ca-trust/source/anchors
sudo update-ca-trust

vault.pfx (Vault Web Arayüzü için Kullanacağım SSL Sertifika) run > certlm.msc > Personal > All Tasks > Request New Certificate > Web Server Template

Subject > Subject Name > Common Name : vault.alanadı
Subject > Subject Name > Common Name : vault
Subject > Alternative Name > DNS : vault.alanadı
Subject > Alternative Name > IP(v4) : serverIP
Private Key > Key Options > Make Private Key Exportable


PFXFile="vault.pfx"

#We can extract the private key form a PFX to a PEM file
openssl pkcs12 -in $PFXFile -nocerts -out key.pem

#Exporting the certificate only:
openssl pkcs12 -in $PFXFile -clcerts -nokeys -out cert.pem

#Removing the password from the extracted private key:
openssl rsa -in key.pem -out server.key 

sudo mkdir /etc/certs
mv -v cert.pem server.key /etc/certs
sudo setfacl -R -m vault:rwx /etc/certs

4)Servis Dosyasını Hazırlama

Vault'u servis olarak çalıştırabilmek için servis dosyamı hazırlıyorum. (/lib/systemd/system/vault.service) Bu dosyanın içinde web arayüzünün olup olmayacağı, hangi porttan yayımlanacağı vb ayarlar var.

4)Vault Ayar Dosyasını Hazırlama

Vault ile ilgili ayar dosyamı hazırlıyorum (/etc/vault.d/vault.hcl)

sudo chown -Rv vault: /etc/vault.d/vault.hcl
sudo chmod -Rv 640 /etc/vault.d/vault.hcl

5) Web Arayüzü Ayarları

Sunucumda firewall açıksa 8200/tcp portunun dışarıdan erişilmesine izin vermem gerekiyor.

sudo firewall-cmd --permanent --add-port=8200/tcp
sudo firewall-cmd --reload

Sertifika çıkarttığım AD sunucusundan arayüze bağlanıyorum , https://vault.alanadi:8200 şeklinde.

Okuduğunuz için teşekkürler 🙂

Nexus 001 - Kurulum

Berkant — Thu, 08 May 2025 18:01:37 +0000

Nexus Nedir?

Sonatype Nexus Repository, temel olarak binary dosyalarından, çeşitli paketlere , AI modellerine kadar, geniş bir yelpazede merkezi bir saklama ve dağıtım aracıdır.

Desteklediği paketleri/tipleri şuradan görebilirsiniz.

Kurulum

1) Nexus kurulum dosyasını indirelim.

Buradan indirme bağlantısını bulabiliriz.

wget https://download.sonatype.com/nexus/3/nexus-3.80.0-06-linux-x86_64.tar.gz

2) /opt dizininde arşivi açalım. Sürüm numarası sizde farklı olabilir.

cp nexus-3.80.0-06-linux-x86_64.tar.gz /opt/
cd /opt
tar -xzvf nexus-3.80.0-06-linux-x86_64.tar.gz
ln -s nexus-3.80.0-06 nexus

3) nexus kullanıcısı oluşturup, önceki adımda arşivden çıkardığımız nexus ve sonatype-work dizinlerinde yetkilendirelim.

# --disable-login yerine shell olarak /sbin/nologin /bin/false da ayarlanabilir.
adduser --disabled-login nexus
echo 'run_as_user="nexus"' >>nexus.rc
chown -Rv nexus: /opt/nexus /opt/sonatype-work /opt/nexus-3.80.0-06

4) Servis dosyasını hazırlayalım

5) Servisi sunucu yeniden başlayınca açılacak şekilde(enabled) ayarlayıp, şimdi çalıştıralım(start)

systemctl daemon-reload
systemctl enable --now nexus.service

6) Bir süre sonra 8081 portunu dinleyen bir java uygulaması(nexus) olacak sunucuda. ss ya da netstat komutu ile dinlenen portlara bakabiliriz.

root@nexus:/opt# ss -tulpn | grep 8081
tcp   LISTEN 0      50                        *:8081            *:*    users:(("java",pid=2623,fd=37))

Kısa Notlar 001 - LDIF Dosyaları

Berkant — Tue, 01 Nov 2022 17:48:53 +0000

LDIF: LDAP kayıtlarının düz metin biçimde ifade edildiği dosyalardır. LDAP taki bilgilerin tamamını içeribileceği gibi bir kısmını da içerebilir. Yeni kayıt ekleme,çıkarma, değiştirme işlemleri yapılabilir.

ldapadd -x -W -D "cn=admin,dc=cloudsio,dc=com" -f drivers.ldif

Yukarıdaki komutla bind dn olarak cn=admin,dc=cloudsio,dc=com kullanılarak driver.ldif dosyasındaki kayıtlar ekleniyor.

Ldif dosyalarını ya da ldap kayıtlarınızı görselleştirmek için ldif2dot kullanabilirsiniz.

# dot , graphviz paketinden geliyor.
sudo apt update && sudo apt install graphviz -y
chmod +x ldif2dot.py
# -b parametresi ile nereden başlayarak arama yapacağımızı belirtiyoruz.
ldapsearch -x -b 'dc=cloudsio,dc=com' | ./ldif2dot.py |       dot -o myDomain.png -Nshape=box -Tpng /dev/stdin

SSH Güvenliğini Arttırmak

Berkant — Fri, 21 Oct 2022 07:56:07 +0000

Giriş

Merhaba, Bu yazımda ssh-audit aracıyla hedef makinedeki ssh bağlantı güvenliği açıklarını bulup, açıkları kapamak için gereken değişiklikleri Ansible ile yapacağız.

.sshd_config ve ssh_config Arasındaki Fark?

sshd nin açılımı ssh daemondur. SSH Portuna gelen bağlantıları dinler. sshd_config bulunduğumuz makineye gelen bağlantıları karşılamada kullanılan ayarlardır.
ssh_config de ise ssh istemcisi için yapılan ayarlar bulunur. Yani ssh_config başka makinelere bağlanırken kullanılan ayarlar içindir.

ssh-audit ile Açıkları Bulmak

ssh-audit kurulur.

sshd_config ayarları yapılarak güvenliği arttırılacak makine taratılır. İster uzak bir makineden ister kendisinden taratabiliriz.

ssh-audit localhost

Çıkan sonuca göre anahtar değişim algoritmalarında (KexAlgorithms), HostKeyAlgoritms de, kullanılan şifreleme algoritmalarında (ciphers) ve mesaj kimlik doğrulama kodlarında yeşille belirtilen algoritmalar güvenli olduğundan kalacak, sarı ve kırmızı olanlar sshd_config den çıkartılacak.
Ubuntu 20.04 Focal için örnek sshd_config dosyamız.

Ansible ile Otomasyon

Birden fazla sunucunun olduğu bir ortamda, teker teker bu ayarları dağıtmak çok fazla zaman alacağından Ansible ile dağıtacağız.
Ansible ile dağıtırken her işletim sistemi sürümüne göre desteklenen algoritmalarda değişiklikler olabilir. Bundan dolayı playbook umuza sunucuların işletim sistemini bakıp, sadece Ubuntu 20.04 (focal) için çalışacak şekilde ayarlanacak. Dilerseniz farklı işletim sistemlerinide benzer yöntemle ekleyebilirsiniz.
Aşağıdaki ekran görüntüsünde host02.txt dosyasında belirtilen makinelerde işletim sistemi kod adı bilgisine ulaşıyoruz.

Yapacağımız işlemi kısaca özetlersek
- sshd_config hedef makineye kopyalamak (var olan izin ve sahiplikleri koruyarak)
- sshd_config de belirtilen hostkeyleri yoksa oluşturmak
- ssh servisini yeniden başlatmak (değişiklik olmuşsa)

Bir sonraki yazımızda görüşmek üzere ;)

Başlık Testi

Berkant — Thu, 20 Oct 2022 18:26:43 +0000

Deneme deneme

Jump to "Header 1"
Jump to "Header 2"
Jump to "header3"
Jump to "denene"

Header 1

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum

Header 2

There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable. If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidden in the middle of text. All the Lorem Ipsum generators on the Internet tend to repeat predefined chunks as necessary, making this the first true generator on the Internet. It uses a dictionary of over 200 Latin words, combined with a handful of model sentence structures, to generate Lorem Ipsum which looks reasonable.

SSH Key Oluşturma

The generated Lorem Ipsum is therefore always free from repetition, injected humour, or non-characteristic words etc.

Header3

denene

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 an

Lab001 - Linux Dağıtımlarında LDAP Üzerinden Kimlik Doğrulama

Berkant — Tue, 11 Oct 2022 19:25:14 +0000

İçindekiler

Terraform ile Ortamın Kurulması
Ansible ile Yapılandırma
LDAP Adımları
Lab Dosyaları

Giriş

Bu yazıda sadece LDAP Sunucusu kurulumu anlatmayacağım. LDAP kurup, kayıtları ekleyip, kullanıcıların linux sunucularda LDAP üzerinden yetkilendirilmesini anlatacağım. Bunu yaparken ortam kurulumu için Terraform, yapılandırma için de Ansible kullanacağım.

⚠️⚠️ Ekran görüntülerinde ve terminal kayıtlarında yazı içinde farklı IP adresleri görebilirsiniz. Bu yazıyı takip ederken LDAP Sunucusu mu yoksa istemci makineden mi bahsediliyor dikkat ediniz.

Terraform ile Ortamın Kurulması

Bulut ortamlarından AWS yi seçtim bu lab için siz dilediğiniz bulut sağlayıcıda veya kendi yerelinizde bu ortamı kurabilirsiniz.

AWS de varsayılan VPC nin içine iki sunucu(LDAP + Test Sunucusu) kuracağız. Bunlar aynı güvenlik grubuna(security group) bağlı, güvenlik grubunda dışarıdan(VPC nin dışından) gelecek SSH ve LDAP bağlantılarına izin verecek iki kural var. Ayrıca sunuculara terraform da , açık anahtarımızı(public ssh key) tanıtacağız ssh bağlantısı için.

Terraform Kurulumu

AWS CLI Kurulumu

AWS Console da IAM -> Users -> Add Users bölümünden terraformUser isimli kullanıcı oluşturuyoruz. Credential type için Access key i seçiyoruz.

Bir sonraki adımda Set Permissions ekranında Attach Existing policies directly bölümünden aşağıdaki yetkiler seçilir. Yetkiler Filter Policies ekranından aranarak bulunabilir.
- AmazonEC2FullAccess , AmazonVPCFullAccess

Add tags bölümünde herhangi bir seçim yapmamıza gerek yok. Bir sonraki adıma geçiyoruz.

Review bölümünde bize önceki adımlarda yaptığımız seçenekleri gösteriyor. Alttaki ekran görüntüsüyle karşılaştırıp doğrulamanız iyi olur.

Son adımda Download .csv ile kimlik bilgilerinin olduğu dosya indirilir.

Terraform dosyalarının AWS de yapıyı kurabilmesi için önceki adımlarda indirdiğimiz .csv dosyasındaki profili , aws cli da tanıtalım. Bu profili Terraformda tanımlayalım.

provider "aws" {
  region  = "us-east-1"
  profile = "terraformUser"
}

Oluşturacağımız sunuculara hem Ansible ın erişmesi için hem de ssh üzerinden erişebilmemiz için sunuculara açık SSH anahtarımızı Terraform ile yerleştiriyoruz.

resource "aws_key_pair" "myKey" {
  key_name   = "mySSHKey"
  public_key = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICT1k5NTCYPbi19DKDUvJQ8V9pkVFvCK8FZaXhv8bJty berkant@ryzen"
}

terraform fmt komutuyla dosya varsayılan biçimde formatlanır. terraform validate komutu ile oluşturulan ayarlar ve yapı geçerli mi diye kontrol edilir. terraform init ile terraformun çalışması gereken çeşitli hazırlıklar yapılır(sağlayıcı dosyasını indirmek gibi). terraform plan kurulacak yapı için gereken değişiklikleri gösterir. terraform apply yapıyı kurar.

Kaydın sonunda hata almasının sebebi AWS de Terraform tarafından oluşturulmayan bir kaynağı kullanmaya çalışmamız. Terraform dosyalarında varsayılan VPC yi kullandım. Bu kaynak Terraform tarafından oluşturulmadığı için , AWS deki o kaynağı içe aktarmamız lazım.

resource "aws_vpc" "myVPC" {
  # Bu kaynak aws tarafından oluşturuldu.İçe aktarılacak.
  # Kullanmamız için bu tanımlama ve terraform import ile içe aktarılması yeterli
}

Tekrar terraform apply yaptığımızda sorunsuz bir şekilde kurulacak. Terraform bölümünü bitirdik 🏁

Ansible ile Yapılandırma

Ansible ile kuracağımız iki sunucuda paket yükleme, ssh ayarlarını değiştirme, ayar dosyalarını atma işlemlerini yapacağız. Altta temel ansible-playbook komutunun açıklamaları var.

ansible-playbook -i inventoryFile playbook.yaml --key-file keyFile

inventoryFile: playbook.yaml daki kuralların hangi sunucularda işletileceğine yönelik bilgiler. Bu bilgilerle ssh bağlantısı sağlanacak. (IP adresi, sunucu, kullanıcı adı vb). [] Köşeli parantezler içinde yazan ifade ansible dosyasında hosts ile belirttiğimiz değişkene karşılık geliyor.

[LDAP]
XXX.XXX.XXX.XXX ansible_user=admin
[Client]
XXX.XXX.XXX.XXX ansible_user=admin

playbook.yaml: Ansible kodlarının olduğu dosya.

keyFile: SSH ile bağlanırken kimlik doğrulama için anahtar dosyası.

İhtiyacımız olan paketleri kurup, dosyaları kopyalayıp, ayar dosyalarında değişiklikler yaptık.

LDAP Adımları

LDAP Sunucusundaki Adımlar

LDAP sunucumuza giriyoruz, slapd ve ldaputils paketi ansible ile kurulmuştu. Varsayılan olarak kurulumda sunucu isminden dn(ayırt edici ad ~ distinguished name) almaya çalışıyor. Bu değerlere slapcat komutuyla bakabiliriz.
Örneğin cloudsio ismindeki yapımız için cloudsio.com a karşılık gelecek şekilde kurduğumuzu düşünelim. LDAP ı sudo dpkg-reconfigure slapd komutuyla yeniden yapılandırabiliriz. Adımlarda oluşturulan admin hesabının okuma/yazma yetkileri var.
LDAP ı yeniden yapılandırdıktan sonra drivers.ldif dosyamızı ldap a ekleyelim alttaki komut ile. (.ldif uzantılı dosyalar ldap kayıtlarını düz metin olarak saklar.)
👉👉LDIF Dosyaları Hakkında Kısa Notlar👈👈

ldapadd -x -W -D "cn=admin,dc=cloudsio,dc=com" -f drivers.ldif

👉👉drivers.ldif in görselleştirilmiş hali👈👈

İstemci/Client ta Yapılacak Adımlar

LDAP sunucusunda yapmamız gerekenler adımlar bitti. Kimlik doğrulama işini LDAP a soracak sunucudaki(istemci / client) adımlara geçelim.

sudo apt update && sudo apt install libnss-ldapd libpam-ldapd ldap-utils -y

Sunucuya libnss-ldapd , libpam-ldapd, ldap-utils paketlerini yüklüyoruz. Paketlerin yüklenme adımında ldap sunucusu ile ilgili ve bulunduğumuz pam modülünün ayarları ile ilgili seçenekleri soruyor.
Son olarak /etc/pam.d/common-session dosyasına , sunucuya giren kullanıcaların ev dizininin sunucuya girer girmez oluşturulması için aşağıdaki pam seçeneğini ekliyoruz.
session optional pam_mkhomedir.so skel=/etc/skel umask=077
İlgili nscd ve nslcd servislerini yeniden başlatıyoruz.
systemctl restart nscd nslcd
Kendi makinemizden yaptığımız bağlantılarda ssh servisinin MaxAuthTries (varsayılan 6) değerini aştığımız için aşağıdaki gibi bir hata alabiliriz.

berkant@ryzen:~/LAB001/terraform$ ssh jbianchi@54.243.0.128
Received disconnect from 54.243.0.128 port 22:2: Too many authentication failures
Disconnected from 54.243.0.128 port 22

Eğer başka bir makineden bağlanırsak, ya da /etc/ssh/sshd_config MaxAuthTries değerini yükseltip, ssh servisi yeniden başlatırsak sorun çözülür.

Kullanıcılar sunucuya girdi ama henüz sudo yetkileri yok. Ne yapmalıyız?
- /etc/sudoers dosyasında değişiklik yapmamız gerekecek. -r--r----- 1 root root 668 Oct 31 20:00 /etc/sudoers dosyanın izinleri bu şekilde olduğundan herhangi bir metin düzenleyici içine girip değişiklik yapamıyoruz. sudoers dosyalarını düzenlemek için visudo komutunu kullanabiliriz.

sudo visudo
# Açılan sudoers dosyasında ilgili kullanıcının grubunu ekliyorum
%drivers   ALL=(ALL:ALL) ALL

Lab Dosyaları

👉👉Github Bağlantısı👈👈

Okuduğunuz için teşekkürler 🙂

Kaynaklar