git, nagios ve kancalar, bozuk git repo

Arka fon

Altyapımızı izlemek için nagios kullanıyoruz. Şu anda sürüm kontrolü altında nagios yapılandırmalarımız yok ve nagios yapılandırmasını yöneten ikimiz var. Bu nedenle, sözdizimi denetimi yapmak için bazı kancaları kullanarak nagios yapılandırmamızı merkezi bir git repo'suna almak için çalışıyorum ve ardından yapılandırmalar iyi görünüyorsa, onları "etkin" hale getirin. Ben kullanıyorum bu adamın bir başlangıç noktası olarak alır.

Uygulamaya çalıştığım genel iş akışı:

1. Nagios config yerel git repo'sunu düzenleyin. Düzenlenen dosyaları ekleyin, yerel olarak işleyin.
2. git push origin master uzak repo.
3. Push, dosyaları alan, sunucudaki geçici bir dizine taşıyan ve nagios sözdizimi denetleyicisi üzerinden çalıştıran ön alma kancası tarafından durdurulur.
4. Sözdizimi denetleyicisi başarılı olursa, push'u kabul edin, ardından git pullyeni kodu nagios yapılandırma dizinine göndermek için post-taahhüt kancasını kullanın ve ardından nagios'u yeniden başlatın.
5. Sözdizimi denetleyicisi başarısız olursa, kullanıcıya nagios sözdizimi hatasını göstererek pushu reddedin.

Ben nagios yapılandırmada sözdizimi hataları nedeniyle bir git push reddetmek, olsa da, garip bir davranış içine koşuyorum. Olmasını beklediğim şey, eğer kancayı reddedersem, itme denemesi depoyu el değmemiş şekilde bırakmalıdır. Yine de durum böyle görünmüyor. Aşağıda gördüklerimin detayları:

Sorun

Nagios config'i bir sözdizimi hatası da dahil olmak üzere yerel olarak düzenler, ekler, sonra yerel olarak taahhüt ederim:

host:nagios erik$ vi nagios.cfg
host:nagios erik$ git add nagios.cfg
host:nagios erik$ git commit -m "syntax error"
[master da71aed] syntax error
 1 files changed, 1 insertions(+), 0 deletions(-)

Şimdi bu değişiklikleri ana repoya itiyorum. Sözdizimi hatası nedeniyle bu reddedilecek:

host:nagios erik$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 12.74 KiB, done.
Total 3 (delta 1), reused 2 (delta 1)
remote: Previous HEAD position was 3ddc880... removed syntax error
remote: HEAD is now at da71aed... syntax error
remote: Nagios Config Check Exit Status: 254
remote: Your configs did not parse correctly, there was an error. Output follows.
remote:
remote: Nagios Core 3.2.3
remote: Copyright (c) 2009-2010 Nagios Core Development Team and Community Contributors
remote: Copyright (c) 1999-2009 Ethan Galstad
remote: Last Modified: 10-03-2010
remote: License: GPL
remote:
remote: Website: http://www.nagios.org
remote: Reading configuration data...
remote: Error in configuration file '/tmp/nagiosworkdir/nagios.cfg' - Line 23 (NULL value)
remote:    Error processing main config file!
remote:
remote:
remote:
remote: ***> One or more problems was encountered while processing the config files...
remote:
remote:      Check your configuration file(s) to ensure that they contain valid
remote:      directives and data defintions.  If you are upgrading from a previous
remote:      version of Nagios, you should be aware that some variables/definitions
remote:      may have been removed or modified in this version.  Make sure to read
remote:      the HTML documentation regarding the config files, as well as the
remote:      'Whats New' section to find out what has changed.
remote:
To git@remote-server.example.com:nagios
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@remote-server.example.com:nagios'

Bu olmamalı uzak repo dokundu, ama oldu. Başka bir yerel geçici dizine geçmek ve repo klonlamak için çalışırsanız, ben olsun:

host:temp erik$ git clone git@remote-server.example.com:nagios
Cloning into nagios...
remote: Counting objects: 30, done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 30 (delta 12), reused 0 (delta 0)
Receiving objects: 100% (30/30), 29.81 KiB, done.
Resolving deltas: 100% (12/12), done.
error: Trying to write ref HEAD with nonexistant object da71aedfde2e0469288acd9e45bb8b57a6e5a7b3
fatal: Cannot update the ref 'HEAD'.

Şimdi orijinal çalışma dizinine geri dönüyorum, sözdizimi hatasını düzelttim, ekledim, taahhüt ediyorum ve itiyorum:

host:nagios erik$ vi nagios.cfg
host:nagios erik$ git add nagios.cfg
host:nagios erik$ git commit -m "removing syntax error, push should succeed this time"
[master f147ded] removing syntax error, push should succeed this time
 1 files changed, 0 insertions(+), 2 deletions(-)
host:nagios erik$ git push origin master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 487 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Previous HEAD position was 4c80d45... syntax error
remote: HEAD is now at f147ded... removing syntax error, push should succeed this time
remote: Nagios Config Check Exit Status: 0
remote: Your configs look good and parsed correctly.
To git@remote-server.example.com:nagios
   3ddc880..f147ded  master -> master

Bu noktada, depo gayet iyi ve geçici bir dizine geçip repoyu tekrar klonlayabiliyorum:

host:temp erik$ git clone git@remote-server.example.com:nagios
Cloning into nagios...
remote: Counting objects: 34, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 34 (delta 14), reused 0 (delta 0)
Receiving objects: 100% (34/34), 30.22 KiB, done.
Resolving deltas: 100% (14/14), done.

İşte kullandığım ön alma kancası.

İstemcide git v1.7.5.4 ve sunucuda v1.7.2.3 kullanıyorum.

Öyleyse şu soruya : itmeyi reddettiğimde depo neden tutarsız bir durumda bırakılıyor? Git kancamla ilgili bir sorun mu var, yoksa belki de git anlayışım eksik mi?

Yapıyoruz:

export GIT_WORK_TREE=/tmp/nagiosworkdir
/usr/bin/git checkout -f $NEW_SHA1

kanca. O zamanki dokunmadan değil rağmen çalışma-copy edilir git-dir (özellikle de referansları güncellenmesi HEADHatanızla gösterildiği gibi, referans):

...
remote: HEAD is now at da71aed... syntax error
...

Kişisel kanca yapıyor exit 1güncellemesini reddetmesine ama sıfırlama (yeniden) değil HEADarızasından sonra referansı.

Kancadaki başarısızlık dalını şu şekilde güncellemeniz gerektiğini düşünüyorum:

...
if [ "$NAGIOS_CHECK_STATUS" -ne 0 ]
   then
   echo "Your configs did not parse correctly, there was an error. Output follows."
   cat $GIT_WORK_TREE/check.out
   /usr/bin/git reset --hard $OLD_SHA1    # <-- Add This
   exit 1
else
   ...

Kancanızdaki git checkoutkomut deponuzda HEAD ref oluşturuyor / güncelliyor.

Deponuz çıplak bir havuzsa, bir HEAD ref'siz yaşayabilir (yeni klonlar varsayılan olarak ana dalını (varsa) kontrol eder ); sadece çıkmadan önce HEAD referansını silin (belki de trapher biri önce ayrı exitayrı ayarlamanız gerekmez ). Senaryonuzda “erken” herhangi bir yer:

trap 'git update-ref -m "removing HEAD after temporary checkout to alternate workdir" -d HEAD "$NEW_SHA1"' 0

Deponuz çıplak değilse veya bir HEAD ref korumak istiyorsanız (klonların varsayılan olarak başka bir dalı kontrol edeceği şekilde), o zaman HEAD ref'yi kaydetmeniz ve çıkmadan önce geri yüklemeniz gerekir.

İlk olarak, sunucunun veri havuzunda, yeni klonlarda varsayılan olarak teslim alınmasını istediğiniz dalı işaret etmek için HEAD ref değerini sıfırlayın:

git symbolic-ref -m 'setting default branch for new clones' HEAD refs/heads/master

Ardından, kanca komut dosyanızda (kasanızdan önceki herhangi bir yerde):

# Restore HEAD symref when exiting
saved_HEAD=$(git symbolic-ref HEAD)
trap 'git symbolic-ref -m "restoring HEAD after temporary checkout to alternate workdir" HEAD "$saved_HEAD"' 0

Bu arada, pre-receivekancalar stdin'i tamamen okuduklarından ve beslendikleri tüm hatları işlediklerinden emin olmalıdır. Tüm girdiyi tüketmeden önce çıkmak bazen git-receive-packsüreçte bir SIGPIPE'i tetikleyebilir ; bir seferde yalnızca bir ref iterseniz (muhtemelen en az bir satır okuduğunuzda) bu sizin durumunuzda ortaya çıkmaz, ancak akılda tutulması gereken bir şeydir. Muhtemelen bu kancayı, updateher seferinde sadece bir ref ile ilgilenmeniz gereken ve her ref'nin itişini ayrı ayrı reddedebileceğiniz bir kanca olarak yapmak daha kolaydır (belki de sadece ustanın ucunu “temiz” tutmayı önemsersiniz ; diğer şubelerin ipuçlarını rapor edin, ancak eksik çalışmalarda işbirliği için kullanılabilmeleri için asla reddetmeyin).