GLPI Agent Nedir? Kurulum ve Toplu Envanter Dağıtımı

GLPI Agent, ağdaki bilgisayarlara kurulan ve donanım, yazılım, ağ bilgisini toplayıp GLPI sunucusuna gönderen küçük bir istemci yazılımdır. Bir kez kurulduktan sonra envanter kendini günceller: takılan yeni RAM, kaldırılan bir program, değişen IP adresi bir sonraki gönderimde sisteme kendiliğinden yansır. Bu rehber agent’ın Windows, Linux ve macOS üzerine kurulumunu, GPO ve Ansible ile yüzlerce cihaza toplu dağıtımını ve gelen verinin GLPI arayüzünde nasıl okunacağını anlatıyor.

Aradaki farkı tapu ve kadastro ayrımı üzerinden düşünmek işi kolaylaştırıyor. Tapu sicili bir taşınmazın hukuken kime ait olduğunu söyler ve masada durur; arazide ne olduğunu, sınırın nereden geçtiğini, üzerinde ne yapıldığını söylemez. Onu ancak sahaya çıkan kadastro ekibi tespit eder: gider, ölçer, gördüğünü paftaya işler. Kurumsal envanterde zimmet formu tapudur: cihazın hukuki sahibini, imzayla, kayda geçirir. GLPI Agent ise kadastro ekibidir; kimsenin bildirmesini beklemeden cihaza gider ve fiilen ne olduğunu ölçer.

Elle tutulan bir envanter listesi bu yüzden zamanla yanıltıcı hale gelir: tapu kaydı gibi doğru görünür, ama araziyi yıllardır kimse ölçmemiştir. Bu rehberin konusu tek bir ölçüm yapmak değil; ölçüm ekibini kalıcı olarak sahada tutmaktır.

Rehber, GLPI kurulumu tamamlanmış ve web arayüzüne giriş yapılabilen bir sunucuyu varsayar. Sunucu tarafı henüz hazır değilse önce Ubuntu Server, Apache ve MariaDB ile GLPI kurulumu rehberini tamamlayın. Platformun ne olduğu ve hangi kurumlara uygun olduğu sorusunun cevabı ise GLPI nedir rehberinde duruyor.

Agent’ın ne işe yaradığını zaten biliyorsanız doğrudan kurulum adımlarına, filoya toplu dağıtım yapacaksanız toplu dağıtım bölümüne geçebilirsiniz.

GLPI Agent Nedir?

GLPI Agent, cihazın üzerinde çalışan ve envanter verisini periyodik olarak GLPI sunucusuna ileten bir istemcidir. Windows’ta bir servis, Linux ve macOS’ta bir daemon olarak arka planda bekler; zamanı geldiğinde donanım bileşenlerini, kurulu yazılımları, ağ arayüzlerini ve işletim sistemi bilgisini toplayıp sunucuya gönderir. Sunucu tarafında bu veri, mevcut kayıtla eşleştirilir ve cihazın kartı güncellenir.

Kadastro benzetmesini biraz daha açalım, çünkü agent’ın ne yapıp ne yapmadığını en net bu ayrım gösteriyor. Ölçüm ekibi araziye gider, gördüğünü ölçer ve tutanağı merkeze teslim eder. Sınırı kendisi belirlemez, mülkiyet tartışmasını çözmez, kimsenin kaydını silmez; o kararlar tapu müdürlüğünde verilir. Agent da aynı şekilde çalışır: veriyi toplar ve gönderir, ne yapılacağına sunucu karar verir. Bu yüzden agent’ın kurulu olması tek başına düzenli bir envanter anlamına gelmez; gelen ölçümlerin doğru parsele işlenmesi, yani sunucu tarafındaki kuralların doğru tanımlanması gerekir. Bu rehberin son bölümü tam olarak bunu ele alıyor.

Agent’ın toplamadığı şeyler de en az topladıkları kadar önemlidir. Belge içeriği, ekran görüntüsü, tuş kaydı, gezinti geçmişi gibi veriler envanterin konusu değildir ve agent bunları göndermez. Kurum içinde “bilgisayarımı izliyorlar mı” sorusu er ya da geç geldiğinde verilecek net cevap budur. Envanter bir gözetim aracı değil, varlık kaydıdır.

Agent’lı ve Agent’sız Envanter Arasındaki Fark

Agent’sız envanter mümkündür ama kapsamı dardır. GLPI, SNMP protokolüyle ağı tarayarak switch, router, yazıcı ve erişim noktası gibi cihazları agent kurmadan envantere alabilir; zaten bu cihazların çoğuna yazılım kurmak mümkün değildir. Bilgisayarlar için ise uzak envanter (remote inventory) yöntemi vardır: kurulu bir agent, Windows tarafında WinRM, Linux tarafında SSH kullanarak başka makinelere bağlanır ve onların envanterini toplar.

Fark, ekibin araziye çıkmasıyla ölçümü uzaktan yapması arasındaki farktır. Uzak envanter için her cihaza erişim yetkisi tanımlamanız, kimlik bilgilerini saklamanız ve hedef makinede uzaktan yönetim servisini açık tutmanız gerekir. Topladığı veri de daha sınırlıdır; kurulu agent’ın eriştiği bazı donanım detaylarına uzaktan ulaşılamaz. Buna karşılık kurulum yükü yoktur.

Pratikte tercih şudur: bilgisayarlar için agent kurun, agent kurulamayan her şey için ağ keşfini ve uzak envanteri tamamlayıcı olarak kullanın. İkisini birbirinin alternatifi gibi görmek yaygın bir hatadır ve genellikle envanterin yarısının eksik kalmasıyla sonuçlanır.

Başlamadan Önce: GLPI’de Envanteri Etkinleştirin

GLPI 10’da yerel envanter özelliği varsayılan olarak kapalı gelir ve açılmadan hiçbir agent verisi kaydedilmez. Ayar Administration > Inventory altındaki Enable inventory kutusudur; işaretleyip kaydetmeden agent kurmak, tek başına hiçbir sonuç üretmez.

Bu adımı atlamanın neden bu kadar sinsi olduğunu lab ortamımızda ölçtüm. Envanter kapalıyken sunucunun envanter uç noktasına istek gönderdiğimde HTTP 200 cevabı geliyordu, yani “aldım, sorun yok” diyordu. Kutuyu işaretleyip kaydettikten sonra aynı isteğe HTTP 400 dönmeye başladı, çünkü GLPI artık veriyi gerçekten ayrıştırıyor ve geçersiz olanı reddediyordu. Kapalıyken sessizce yutuyor, açıkken konuşuyor. Agent tarafında ise iki durumda da hata görünmez; log temiz, servis çalışıyor, envanter gönderiliyor, ama GLPI’de cihaz listesi boş kalır.

Kadastro benzetmesiyle: ölçüm ekibini sahaya çıkarmadan önce tapu müdürlüğünün tutanak kabul ediyor olması gerekir. Ekip araziyi ölçer, tutanağı getirir, kapı kapalıysa evrak kimseye ulaşmaz ve ekip bunu bilmez.

Aynı ekranda içe aktarma seçenekleri de bulunur. Monitörler, birimler ve yönetilmeyen cihazlar varsayılan olarak işaretli gelir; bunları kapatmak envanterin kapsamını daraltır, dolayısıyla özel bir sebebiniz yoksa oldukları gibi bırakın.

GLPI Agent Kurulum Yöntemleri

Kurulum yöntemi işletim sistemine göre değişir ama üç platformda da aynı iki bilgi verilir: agent’ın raporu göndereceği sunucu adresi ve cihazın hangi grupla etiketleneceği. Sunucu adresi GLPI’nın envanter uç noktasıdır ve http://glpi.sercebilisim.com/front/inventory.php biçimindedir. Etiket ise cihazın hangi lokasyona, şubeye veya departmana ait olduğunu söyleyen serbest metindir; sunucu tarafındaki otomatik kurallar büyük ölçüde bu etikete dayanır.

Etiketi baştan doğru kurgulamak, sonradan yüzlerce cihazı elle düzeltmekten çok daha ucuzdur. Ölçüm ekibini sahaya çıkarırken ada ve parsel numarasını eline vermek gibidir: tutanak geldiğinde hangi mahalleye ait olduğu zaten üstünde yazar. Etiketsiz gelen cihazlar ise sunucuda tek bir yığında birikir ve onları ayıklamak, ölçümü ikinci kez yapmak kadar zahmetlidir.

Aşağıdaki üç bölüm tek cihaza kurulumu anlatıyor. Yüzlerce cihaz söz konusuysa bu adımları elle uygulamayın; doğrudan toplu dağıtım bölümüne geçin. Yine de bir kez elle kurup verinin sunucuya düştüğünü görmek, toplu dağıtımda hata ayıklamayı çok kolaylaştırdığı için önerilir. Elle yapılan tek kurulum bir referans noktası oluşturur: dağıtım sonrasında bir şey ters gittiğinde, sorunun agent tarafında mı yoksa dağıtım mekanizmasında mı olduğunu bu referans sayesinde saniyeler içinde ayırt edersiniz.

Üç platformda da agent’ın çalışma biçimi aynıdır. Kurulumdan sonra belirli aralıklarla uyanır, envanteri toplar, sunucuya gönderir ve tekrar bekleme durumuna geçer. Varsayılan aralık bir saattir ve ilk temas rastgele bir gecikmeyle dağıtılır; yüzlerce cihazın aynı anda sunucuya yüklenmesini önleyen budur. Bin cihazlık bir filoda bu ayrıntı, sunucunun ilk sabah çökmesiyle sorunsuz çalışması arasındaki farkı yaratır.

Windows’ta GLPI Agent Kurulumu

Windows kurulumu, GLPI Agent’ın MSI paketiyle yapılır. Paket resmi GitHub sürüm sayfasından indirilir ve GLPI-Agent-<sürüm>-x64.msi biçiminde adlandırılmıştır. Sürüm 1.8’den itibaren yalnızca 64 bit paket üretilmektedir; 32 bit sistemleri destekleyen son sürüm 1.7.3’tür.

Paket çift tıklanarak grafik arayüzle kurulabilir, ancak asıl güç komut satırında ortaya çıkar. Sessiz kurulum ve yapılandırma tek satırda verilir:

msiexec /i GLPI-Agent-1.19-x64.msi /quiet SERVER="http://glpi.sercebilisim.com/front/inventory.php" TAG=merkez-ofis RUNNOW=1 ADD_FIREWALL_EXCEPTION=1

Bu satırdaki dört parametrenin her biri bir işi çözüyor. SERVER raporun gideceği adresi, TAG cihazın etiketini belirler. RUNNOW=1 kurulumun hemen ardından ilk envanteri gönderir, böylece dağıtımın çalışıp çalışmadığını saatlerce beklemeden görürsünüz. ADD_FIREWALL_EXCEPTION=1 ise agent’ın gömülü web sunucusunu Windows Firewall istisnalarına ekler; ikisi de varsayılan olarak kapalıdır.

Agent varsayılan olarak Windows servisi biçiminde kurulur ve sürekli çalışır. Bunu EXECMODE parametresiyle değiştirebilirsiniz: 1 servis, 2 zamanlanmış görev, 3 ise elle çalıştırma anlamına gelir. Zamanlanmış görev seçeneği, envanteri belirli saatlere sabitlemek istediğiniz ortamlarda işe yarar. Kurulum dizini varsayılan olarak C:\Program Files\GLPI-Agent, log dosyası ise aynı dizin altındaki logs\glpi-agent.log yolundadır.

Kurulum sonrası yapılandırmayı değiştirmek gerekirse paketi yeniden çalıştırmanıza gerek yoktur; tüm ayarlar HKEY_LOCAL_MACHINE\SOFTWARE\GLPI-Agent kayıt defteri anahtarı altında durur. Buradan sunucu adresini veya etiketi düzenleyip servisi yeniden başlatmak yeterlidir. Windows 10 ve 11 üzerinde winget install glpi-agent komutu da çalışır ve yapılandırma --custom parametresiyle aynı biçimde verilir.

Linux’ta GLPI Agent Kurulumu

Linux tarafında önerilen yöntem, GLPI’nın kendi Perl kurulum scriptidir. Bu script hem RPM hem DEB tabanlı dağıtımları tanır, gerekirse EPEL gibi üçüncü parti depoları etkinleştirir ve doğru paketi kendisi seçer. Tek gereksinimi sistemde perl komutunun bulunması ve dağıtıma göre apt, dnf veya yum araçlarından birinin erişilebilir olmasıdır.

sudo perl glpi-agent-1.19-linux-installer.pl \
  --server="http://glpi.sercebilisim.com/front/inventory.php" \
  --tag="linux-sunucular"

Script’in varsayılan davranışı kurumsal kullanım için zaten makul ayarlanmıştır: kullanıcı ana dizinlerini ve profillerini taramaz, envanter modüllerine otuz dakikalık zaman aşımı uygular, agent’ı servis olarak kurar ve gömülü web sunucusunun 62354 portuna yalnızca GLPI sunucusundan erişime izin verir. Desteklenen tüm seçenekleri --help parametresiyle listeleyebilirsiniz.

Bu rehberi yazarken adımları kendi lab ortamımda uyguladım: chrony çalışan bir Ubuntu 24.04.4 sunucuya 1.19 sürümünü kurdum. Script şaşırtıcı derecede az konuşuyor, kurulumun tamamı üç satır:

Installing glpi-agent v1.19...
Applying configuration...
Enabling glpi-agent service...

Paket kurulumu, servis tanımı ve yapılandırma yazımı bu üç satırın arkasında oluyor. Bir aksilik çıksaydı burada görürdünüz; sessizlik iyi haber.

Kurulumun yerine oturduğunu iki yerden doğruluyorum. Birincisi servis:

systemctl is-active glpi-agent
systemctl is-enabled glpi-agent

Sırasıyla active ve enabled dönüyor. Servisin adı tam olarak glpi-agent; bu ayrıntıyı not edin, aşağıdaki Ansible bölümünde playbook’un son adımı buna dayanıyor.

İkincisi yapılandırmanın nereye yazıldığı. Installer ayarları ana dosyaya değil, conf.d klasörüne ayrı bir dosya olarak koyuyor:

$ sudo grep -rE "^(server|tag)" /etc/glpi-agent/
/etc/glpi-agent/conf.d/00-install.cfg:server = http://192.168.1.20/front/inventory.php
/etc/glpi-agent/conf.d/00-install.cfg:tag = lab-ntp

Buradaki adres ve etiket lab ortamıma ait; kendi kurulumunuzda kendi sunucu adresinizi ve etiketinizi göreceksiniz. Lab’da DNS adı yerine doğrudan IP kullanıyorum, agent açısından ikisi arasında fark yok.

Dikkat edilmesi gereken nokta şu: yapılandırmayı sonradan değiştirmek gerektiğinde ana yapılandırma dosyasına dokunmayın, conf.d klasörüne ek bir dosya bırakın. Bu yalnızca bir üslup tercihi değil; aracın kendisi de aynı şekilde davranıyor ve agent güncellemelerinde conf.d altındaki dosyalar korunuyor. Aynı mantık macOS tarafında da geçerlidir.

Kurulumdan sonra ilk envanteri beklemeden göndermek için:

sudo glpi-agent --force

Lab’da aldığım çıktı şöyleydi:

[info] target server0: server http://192.168.1.20/front/inventory.php
[info] sending prolog request to server0
[info] server0 answer shows it supports GLPI Agent protocol
[info] sending contact request to server0
[info] running task Inventory
[info] New inventory from ntp01-2026-08-06-15-02-28 for server0 (tag=lab-ntp)

Son satırdaki ntp01-2026-08-06-15-02-28 ifadesi agent’ın kendine verdiği kimliktir (device ID) ve GLPI tarafında cihazı bu kimlikle tanır. Parantez içindeki tag=lab-ntp ise etiketin gerçekten iletildiğini gösterir; etiket yanlış yapılandırılmışsa hatayı burada, sunucuya bakmadan yakalarsınız.

Dağıtımınız script tarafından tanınmıyorsa iki yol kalır. Snap destekleyen sistemlerde paket doğrudan kurulup snap set glpi-agent server=... biçiminde yapılandırılabilir. Bunun da mümkün olmadığı durumlarda AppImage paketi devreye girer; dağıtımdan bağımsız çalışır ve bağımlılık gerektirmez. Sunucu envanterinde bu ikisine nadiren ihtiyaç duyarsınız, çünkü kurumsal Linux dünyası büyük ölçüde Debian, Ubuntu, RHEL ve türevlerinden oluşur.

Linux sunucuların envanterinde sık atlanan bir nokta var: sanallaştırma katmanı. Fiziksel bir sunucu üzerinde çalışan on sanal sunucunun her biri kendi agent’ıyla envantere girer, ama hangisinin hangi fiziksel makinede durduğu bilgisi ancak hipervizör tarafı da envantere alındığında ortaya çıkar. VMware ortamlarında bunu agent’ın ESX görevi sağlar. Bu ayrımı kurmadan çıkardığınız sunucu envanteri sayı olarak doğru, mimari olarak kördür.

macOS’ta GLPI Agent Kurulumu

macOS kurulumu, sürüm sayfasından indirilen .pkg paketiyle yapılır ve kurulum sihirbazı yapılandırma sormaz. Diğer iki platformdan farkı budur: sunucu adresi ve etiket, kurulumdan sonra elle oluşturulan bir yapılandırma dosyasına yazılır. Dosya /Applications/GLPI-Agent/etc/conf.d klasörü altında yer alır ve adı serbesttir; local.cfg yaygın tercihtir.

sudo tee /Applications/GLPI-Agent/etc/conf.d/local.cfg > /dev/null <<'EOF'
server = http://glpi.sercebilisim.com/front/inventory.php
tag = tasarim-ekibi
EOF

Dosyayı oluşturduktan sonra agent servisinin yeniden başlatılması gerekir. Sorun yaşarsanız aynı dosyaya debug = 1 satırını ekleyip logları izlemek en hızlı teşhis yoludur.

Toplu dağıtım gerekiyorsa macOS tarafında araç değişir. Jamf, Kandji veya Intune gibi bir MDM çözümü kullanılıyorsa .pkg paketi buradan dağıtılır ve yapılandırma dosyası ayrı bir script adımıyla yerleştirilir. MDM bulunmayan küçük ekiplerde ise pratik yol, paketi ve hazır local.cfg dosyasını birlikte kuran kısa bir kabuk scripti hazırlayıp cihaz teslim sürecine eklemektir. Sayı azken bu yeterlidir; asıl mesele kurulumun teslim rutininin parçası olması, kimsenin hatırlamasına bırakılmamasıdır.

macOS cihazlar kurumsal envanterde çoğu zaman azınlıktadır ve tam da bu yüzden unutulurlar. Tasarım ekibinin beş MacBook’u envantere girmediğinde ortaya çıkan sorun beş cihazlık bir eksiklik değildir; yenileme bütçesi hesaplanırken, lisans sayımı yapılırken ve güvenlik denetiminde o beş cihazın hiç var olmamasıdır. Kadastro ekibinin bir sokağı atlaması gibi: pafta artık eksiktir ve eksik olduğu paftaya bakarak anlaşılmaz.

Toplu Dağıtım Yöntemleri

Toplu dağıtım, agent’ı cihaz başına gitmeden merkezi bir araçla yüzlerce makineye kurmak demektir. Yöntem ortamınızda hangi yönetim altyapısının bulunduğuna göre değişir: domain ortamındaki Windows cihazlar için GPO, modern uç nokta yönetimi kurulu ortamlar için Intune veya SCCM, Linux sunucular için Ansible.

Buradaki asıl kazanç ilk kurulumda değil, sonrasındadır. Elle kurulumda envanter, kurulumu yapan kişinin gayretiyle sınırlı kalır; ağa katılan her yeni cihaz yeni bir görevdir ve unutulan her cihaz sessizce envanterin dışında kalır. Merkezi dağıtımda ise yeni cihaz domain’e katıldığı anda agent’ı alır ve kendini envantere yazar. Sayım artık bir kampanya değil, kalıcı bir süreçtir.

Tablodaki satırlar birbirinin alternatifi değil, çoğu kurumda aynı anda geçerli olan gerçeklerdir. Karma bir ortamda tek bir dağıtım yöntemi aramak, her araziyi aynı ölçüm yöntemiyle çıkarmaya benzer: düz parselde işe yarar, engebeli arazide yaramaz. Doğru yaklaşım her cihaz grubu için en kısa yolu seçmek ve hepsini aynı sunucuya, aynı etiket disipliniyle bağlamaktır. Sunucu tarafı zaten cihazın hangi yolla geldiğini umursamaz.

GPO ile Windows Toplu Dağıtımı

GPO ile dağıtım, GLPI’nın sağladığı glpi-agent-deployment.vbs scripti bir bilgisayar GPO’suna açılış scripti olarak bağlanarak yapılır. Script MSI paketini paylaşılan bir konumdan indirir, sessizce kurar, gerekirse eski envanter istemcilerini kaldırır ve işlemi loglar. Script GLPI Agent deposunda contrib/windows klasörü altında yayınlanır.

Yöntemin yazılım yükleme (Software Installation) yerine açılış scripti olmasının nedeni pratiktir: açılış scriptleri kullanıcı oturum açmadan önce, sistem yetkisiyle çalışır. Kullanıcıların yerel yönetici hakkı olmayan ortamlarda, ki kurumsal ortamların çoğu böyledir, tek güvenilir yol budur. Resmi dokümantasyon da bu tercihi aynı gerekçeyle önerir.

Script içinde düzenlenecek değişkenler bellidir. SetupVersion dağıtılacak agent sürümünü, SetupLocation MSI paketinin bulunduğu konumu, SetupOptions ise kurulum parametrelerini taşır:

SetupVersion = "1.19"
SetupLocation = "\\dc01\glpi-agent$"
SetupOptions = "/quiet RUNNOW=1 ADD_FIREWALL_EXCEPTION=1 SERVER='http://glpi.sercebilisim.com/front/inventory.php' TAG=merkez-ofis"

SetupLocation bir ağ paylaşımı olabileceği gibi HTTP veya HTTPS adresi de olabilir; boş bırakılırsa script paketi doğrudan GitHub sürüm sayfasından indirmeye çalışır. Ağ paylaşımı kullanıyorsanız kritik nokta izinlerdir: paylaşıma erişecek olan kullanıcı değil, bilgisayar hesabıdır. Paylaşım izinlerinde Domain Computers grubuna okuma yetkisi verilmediğinde script sessizce başarısız olur ve hiçbir cihaza kurulum gitmez.

Script ayrıca yeniden yapılandırma (Reconfigure) ve onarım (Repair) seçenekleri sunar. Birincisi, aynı sürüm zaten kuruluyken yalnızca parametreleri güncellemek içindir; sunucu adresi değiştiğinde tüm filoyu yeniden kurmadan yeni adrese taşımanın yolu budur. İkincisi bozulmuş kurulumları yerinde onarır.

SCCM ve Intune ile Dağıtım

Uç nokta yönetim platformu kullanan kurumlarda agent, GPO yerine mevcut uygulama dağıtım mekanizmasıyla kurulur. Configuration Manager (SCCM) tarafında MSI paketi bir uygulama olarak tanımlanır ve kurulum programı satırına aynı msiexec komutu yazılır. Intune tarafında paket .intunewin biçimine dönüştürülür ve Win32 uygulaması olarak yayımlanır.

İki platformda da GPO’da olmayan bir şey vardır: kurulum durumunun raporlanması. GPO açılış scripti kurulumu yapar ama sonucunu size söylemez; başarısızlığı ancak cihazın envantere düşmemesinden anlarsınız. SCCM ve Intune ise dağıtımın hangi cihazlarda başarılı, hangilerinde başarısız olduğunu listeler. Yüzlerce cihazlık bir filoda bu fark, hata ayıklama süresini günlerden dakikalara indirir.

İki platformda da atlanmaması gereken bir ayar var: algılama kuralı. Dağıtım aracı, uygulamanın cihazda zaten kurulu olup olmadığını bu kurala bakarak anlar. GLPI Agent için en sağlam ölçüt MSI ürün kodu veya kurulum dizinindeki çalıştırılabilir dosyanın varlığıdır. Algılama kuralı yanlış tanımlandığında ortaya çıkan sonuç sinsi olur: platform kurulumu her kontrol turunda yeniden dener, cihazlarda gereksiz yük oluşur ve rapor ekranı sürekli başarısız kurulum gösterir, oysa agent çalışmaktadır.

Intune’un ayrıca domain’e üye olmayan cihazlara ulaşabilmesi gibi bir üstünlüğü var. Uzaktan çalışanların bilgisayarları, şirket ağına yalnızca VPN üzerinden bağlanan makineler ve Entra ID’ye kayıtlı olup domain’de bulunmayan cihazlar GPO’nun erişemediği yerdedir. Bu cihazlar kurumsal envanterin en sık atlanan bölümüdür ve genellikle en yeni donanımı taşırlar.

Ansible ile Linux Toplu Dağıtımı

Linux sunucularda toplu dağıtım, Perl kurulum scriptini bir Ansible playbook’uyla hedef makinelere dağıtıp çalıştırarak yapılır. GLPI dokümantasyonu bu kullanımı açıkça destekler; script’in tüm yapılandırmayı komut satırı parametreleriyle alabilmesi de zaten bunun içindir.

- name: GLPI Agent kurulumu
  hosts: linux_sunucular
  become: true
  vars:
    glpi_surum: "1.19"
    glpi_sunucu: "http://glpi.sercebilisim.com/front/inventory.php"
  tasks:
    - name: Kurulum scriptini kopyala
      copy:
        src: "glpi-agent-{{ glpi_surum }}-linux-installer.pl"
        dest: /tmp/glpi-agent-installer.pl
        mode: "0700"

    - name: Agent'i kur ve yapilandir
      command: >
        perl /tmp/glpi-agent-installer.pl
        --server="{{ glpi_sunucu }}"
        --tag="{{ glpi_etiket | default('linux-sunucular') }}"
      args:
        creates: /etc/glpi-agent

    - name: Servisi etkinlestir
      service:
        name: glpi-agent
        state: started
        enabled: true

Playbook’taki creates parametresi küçük ama önemli bir ayrıntı: kurulum dizini zaten varsa görev atlanır, böylece playbook tekrar tekrar çalıştırılabilir hale gelir. Lab kurulumunda bu iki varsayımı da doğruladım: installer gerçekten /etc/glpi-agent dizinini oluşturuyor ve servisi tam olarak glpi-agent adıyla tanımlıyor. İkisinden biri tutmasaydı playbook sessizce bozulurdu; ilki her koşuda kurulumu baştan çalıştırır, ikincisi son görevde hata verirdi. Etiketi değişkene bağlamak ise envanter grubunu envanter dosyasından okumanızı sağlar; her lokasyonun sunucuları kendi etiketiyle kurulur ve GLPI tarafında tek bir kural bunları doğru yerlere dağıtır.

Playbook’u ilk kez çalıştırırken --limit parametresiyle tek bir sunucuya sınırlamak iyi bir alışkanlıktır. Kurulum scripti hedef sistemde paket yöneticisini kullandığı için, deposu bozuk veya bağımlılığı eksik bir sunucuda beklenenden uzun sürebilir; bunu elli sunucuda aynı anda keşfetmek istemezsiniz. Tek sunucuda doğrulayıp GLPI arayüzünde kaydın düştüğünü gördükten sonra tüm gruba açmak, toplam süreyi uzatmaz ama riski ortadan kaldırır.

Aynı playbook’un cihaz teslim sürecine değil, sunucu kurulum şablonunuza girmesi de mümkündür. Yeni sunucu devreye alındığında agent’ı zaten kurulu geliyorsa, envanterin dışında kalan sunucu diye bir kategori hiç oluşmaz. Ölçüm araziye sonradan gitmez; parsel açılırken zaten oradadır.

Envanter Verilerini Yorumlama

Envanter verisi GLPI’da Varlıklar > Bilgisayarlar altında birikir ve her cihaz kendi kartında donanım, yazılım, ağ ve işletim sistemi sekmeleriyle görünür. Agent çalışmaya başladıktan sonraki ilk gün cihazların listeye düşmesi, işin bittiği anlamına gelmez; asıl iş bu verinin karar üretecek biçimde okunmasıdır.

Pafta çıktı. Şimdi soru şu: bu pafta hangi soruyu cevaplayacak? Envanterin değeri cihazları saymakta değil, üç türden soruya hazır cevap üretmesindedir. Birincisi yenileme sorularıdır: kaç cihaz kullanım ömrünü doldurdu, hangileri artık desteklenmeyen bir işletim sistemi çalıştırıyor, SSD’si olmayan kaç makine kaldı? İkincisi lisans sorularıdır: satın alınan lisans sayısı fiilen kurulu kopya sayısını karşılıyor mu? Üçüncüsü güvenlik sorularıdır: onaylanmamış yazılım kurulu cihazlar hangileri, hangi makineler haftalardır envanter göndermiyor?

Son madde en çok göz ardı edilenidir. Envanter göndermeyi kesen bir cihaz, envanterde kaybolmaz; son bilinen haliyle orada durmaya devam eder ve doğru bir kayıt gibi görünür. Oysa o cihaz kapatılmış, çalınmış, formatlanmış veya bir arızayla ağdan düşmüş olabilir. İşte kaydın araziden sessizce ayrıldığı an budur: pafta hâlâ okunaklıdır, ama artık orada olmayan bir şeyi gösterir. Son envanter tarihi alanına göre sıralama almak, bu sapmayı yakalamanın en pratik yoludur ve aylık rutine konulmaya değer.

Bu sapmanın sahadaki karşılığını anlatayım, çünkü tablo halinde bakıldığında masum görünen bir şeyden söz ediyoruz. Geçmişte görev yaptığım bir kurumda envanter, paylaşımlı bir Excel dosyasında tutuluyordu. Bilgisayarlar bir ölçüde takip ediliyordu, ama monitörler, yedek ekipman ve eldeki dolaşan cihazlar hiçbir listede yoktu. Dosya güncel görünüyordu, çünkü güncel olmadığını gösterecek bir ölçüm hiç yapılmıyordu.

Sorun personel çıkışlarında yüzeye vurdu. Bir çalışan ayrıldığında laptopunun teslim alınması gerekiyordu, ama hangi cihazın kimde olduğu yalnızca o Excel’e bakılarak anlaşılıyordu ve Excel gerçeklikten çoktan kopmuştu. Cihaz teslim alındı mı, başka bir personele mi devredildi, yoksa hiç geri gelmedi mi; bunu söyleyecek kayıt yoktu. Birkaç laptop bu şekilde ortadan kayboldu. Kayboldu derken çalındığını iddia etmiyorum: büyük ihtimalle bir kısmı hâlâ kurumun içindeydi, bir çekmecede veya başka birinin masasında duruyordu. Ama envanter açısından ikisi arasında fark yoktur. Bulunamayan cihaz, olmayan cihazdır.

Asıl sorun da cihazların kaybolması değildi. Kaybolduklarının aylar sonra ve çoğu zaman tesadüfen anlaşılmasıydı. Tapu duruyordu, araziye kimse gitmiyordu.

GLPI ve agent dağıtımından sonra tablo tersine döndü. Laptoplar, masaüstü bilgisayarlar ve monitörler tek tek kayda girdi; her cihazın kartında en son ne zaman envanter gönderdiği ve o cihazda en son hangi kullanıcının oturum açtığı görünür oldu. Personel çıkışında “bu kişide hangi cihazlar vardı” sorusunun cevabı artık tek ekranda duruyordu. Kayıp tamamen bitti demiyorum; ama bir cihazın ortadan kaybolduğu aylar sonra değil, ilk haftasında görülür hale geldi. Envanterin gerçek işlevi budur: kaybı önlemek değil, kaybı zamanında görünür kılmak.

Otomatik Kural Tanımlama

Otomatik kurallar, gelen envanterin hangi lokasyona, gruba veya duruma atanacağını cihaz başına elle uğraşmadan belirler. GLPI arayüzünde Yönetim > Kurallar altında tanımlanırlar ve agent’ın gönderdiği etiket, IP aralığı, alan adı veya işletim sistemi gibi alanlara göre çalışırlar.

En yaygın ve en çok işe yarayan kural, etiketten lokasyon atamaktır: etiketi merkez-ofis olan her cihaz otomatik olarak merkez ofis lokasyonuna, izmir-sube olan her cihaz İzmir şubesine düşer. Dağıtımı yaparken etiketlere emek vermenizi bu yüzden öneriyoruz; etiket doğruysa bu kural tek seferde yazılır ve yıllarca çalışır.

İkinci sık kullanılan kural grubu, mükerrer kayıtları önleyen eşleştirme kurallarıdır. GLPI gelen envanteri seri numarası, UUID veya MAC adresi gibi alanlarla mevcut kayıtlara eşler. Bu ölçüt yanlış seçildiğinde ortaya çıkan sonuç tanıdıktır: anakartı değişen bir laptop envanterde ikinci kez belirir ve iki kayıt aylarca yan yana yaşar. Kurulumun ilk haftasında mükerrer kayıt sayısını kontrol etmek, altı ay sonra yüzlerce kaydı birleştirmekten çok daha ucuzdur.

Kural yazarken hatırlanması gereken tek şey sıralamadır: GLPI kuralları yukarıdan aşağıya işletir ve eşleşen ilk kuralda durabilir. Genel kuralı en üste koyarsanız, altındaki özel kurallar hiç çalışmaz. Kurumsal yapılandırmanın geri kalanı, profiller ve yetkilendirme dahil, GLPI yönetimi rehberinde ele alınıyor.

Agent Veri Göndermiyorsa: Sorun Giderme

Agent kurulu görünüyor ama cihaz GLPI’da belirmiyorsa, sorun neredeyse her zaman beş yerden birindedir: sunucuda envanterin kapalı olması, sunucu adresi, ağ erişimi, servis durumu veya sunucu tarafındaki eşleştirme. Teşhisi bu sırayla yapmak en hızlı yoldur, çünkü her adım bir öncekini varsayar.

Sıfırıncı kontrol, agent’a hiç bakmadan yapılır: Administration > Inventory altındaki Enable inventory kutusu işaretli mi? Listenin başına bunu koymamızın sebebi, bu arızanın kendini hiçbir yerde belli etmemesidir. Agent kurulur, servis çalışır, envanter gönderilir, loglarda tek bir hata satırı görünmez; sunucu isteğe olumlu cevap verir ve veri hiçbir yere yazılmaz. Diğer dört maddeyi saatlerce kovaladıktan sonra buraya dönmek yaygın bir senaryodur.

İlk kontrol sunucu adresidir ve en sık hata da buradadır. Adres, GLPI’nın ana sayfası değil envanter uç noktası olmalıdır; sonunda /front/inventory.php bulunmayan bir adres agent tarafından kabul edilir ama sunucu tarafında hiçbir şey olmaz. Windows’ta kayıtlı adresi kayıt defterindeki HKEY_LOCAL_MACHINE\SOFTWARE\GLPI-Agent anahtarından doğrulayabilirsiniz.

İkinci kontrol ağ erişimidir. Cihazdan GLPI sunucusuna HTTP veya HTTPS trafiğinin geçtiğini doğrulayın; şube ağlarında bu trafiğin firewall kuralıyla kapalı olması sık rastlanan bir durumdur. HTTPS kullanıyorsanız ve sertifika kurum içi bir otoriteden geliyorsa, cihazın o otoriteye güvenmesi gerekir; güvenmiyorsa agent bağlantıyı sessizce reddeder.

Üçüncü kontrol servisin gerçekten çalışıp çalışmadığıdır. Windows’ta hizmet listesinde GLPI Agent servisinin durumuna, Linux’ta systemctl status glpi-agent çıktısına bakın. Servis çalışıyorsa log dosyası konuşmaya başlar: Windows’ta C:\Program Files\GLPI-Agent\logs\glpi-agent.log, Linux’ta sistem günlüğü. Bir şey anlaşılmıyorsa yapılandırmaya geçici olarak debug = 1 ekleyip tek bir envanter turu çalıştırmak genellikle cevabı verir.

Dördüncü ihtimal cihazın aslında sunucuya ulaştığı ama beklediğiniz yerde görünmediğidir. Etiketi boş gelen cihazlar atanmamış olarak birikir, mükerrer eşleşen cihazlar mevcut bir kaydın üzerine yazar. Cihaz listesini son envanter tarihine göre sıralayıp bugün gelen kayıtlara bakmak, bu durumu birkaç saniyede ayırt etmenizi sağlar.

Bu karşılaştırmayı ilk kez yaptığınızda çıkan sayının beklediğinizden düşük olması normaldir. Kapalı duran cihazlar, uzun süredir ağa bağlanmayan yedek makineler ve domain’de kaydı kalmış ama fiilen hurdaya ayrılmış bilgisayarlar aradaki farkı büyütür. Envanterin gerçek değeri de burada ortaya çıkar: fark kapanmaz, ama açıklanabilir hale gelir. 1.500 cihazlık bir eğitim kurumunda bu süreci baştan sona nasıl işlettiğimizi GLPI envanter sistemi vaka çalışmasında anlatıyoruz.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.