Production öncesinde SSO sorunlarını belirle ve çöz

roktas commented 4 years ago

İş kaydı

SSO'yu kullanıma açtık ve süreç içerisinde bazı sorunlarla karşılaştık. Sorunların bir kısmını çözdük ama yenileri de çıkacaktır. Tüm bunları takip etmek için böyle meta bir iş kaydı açıyorum. Lütfen tespit ettiğiniz sorunları bu iş kaydı altına girelim ve sonrasında iş kaydı gövdesinde bir checklist oluşturarak çözüme kavuşturalım.

Sorunlar

OMÜ DNS'in bazen cevap vermemesi OIDC Discovery sorunlarına yol açıyor.

Çözüm: https://github.com/omu/root/issues/1
Firewall ve/veya sorunlu ağ ekipmanları LDAP bağlantılarını düşürüyor. Muhtemelen şu sorun: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1807 @ecylmz Bu sorunu iş kaydı altında özetlemeni istiyorum.

Çözüm: Bir workaround geliştirdik ama yeterli değil. Ayrıca şunları yapmalıyız:
- [x] Bu sorunda neredeyse hiç log yok. LLNG sorunu düzgün handle edebilir veya en azından raporlayabilirdi. Üst geliştiriciye durumu raporlayalım; linkini verdiğim iş kaydında veya yeni bir iş kaydı açarak.
- [x] Workaround olarak keepalive'ı şimdilik 5 dk'ya çektik (default değer 120 dk) Bunu iyileştirelim. @ecylmz: En azından 30 dk'ya (1800) çıkartmayı dene
- [ ] Firewall kurallarını gözden geçirelim ve en azından SSO bölgesinde kuralları düzenleyelim. @sinansh Yardımcı olmanı bekliyorum.
@msdundar'dan gelen rapor:

su cikis yaptiktan sonra redirect icin bekletme isi kaldirilabiliyor mu acaba
Çeviriler tamamlanmalı. Bk. https://github.com/omu/nokul/issues/1291
SSO temasını bir parça geliştirmemiz lazım. Örneğin renkler ve fontlar Nokul'a göre daha büyük. Altta baum badge olmalı vs. Bu muhtemelen ayrı bir iş kaydının konusu.
SSO ve LDAP'ın yönetilmesi ve operasyonel olarak sürekliliğin sağlanması sadece bir kişide olmamalı (hali hazırda @ecylmz). @sinansh ve @ileri Sizlerin de sürece etkin olarak katılmanız lazım. @ecylmz Şunları yapmamız lazım (ayrı bir iş kaydı açabilirsin):
- [ ] Bir operasyon kılavuzu oluşturalım. Hangi servis nasıl ayağa kaldırılır, potansiyel sorunlar, hata bulma kılavuzu vs.
- [ ] Arkadaşları toplayıp bir brifleme yapalım
- [ ] Sonrasında bir eğitim planı oluşturalım (Vagrant ile yeniden kurulum vs)

(Diğerlerini de bunun altına ekleyeceğim. Dilerseniz yorum düşün veya doğrudan siz ekleyin)

Katkı sağlama

[ ] Evet, bu iş kaydının bana atanmasını istiyorum.

Kontrol listesi

[X] Katkı sağlama dokümanını okudum
[X] İş kaydının başlığı kurallara (sadece ilk harf büyük, emir kipinde problem cümlesi) uygun
[X] İş kaydı hata bildirimi veya ürün özelliği dışında bir niteliğe sahip
[X] İş kaydıyla ilgili uygun etiketlemeleri yaptım
[X] Bu iş kaydıyla alakalı açık olarak bekleyen bir issue yok
[X] Bu iş kaydıyla alakalı açık olarak bekleyen bir pull request yok

ecylmz commented 4 years ago

LLNG ve LDAP arasındaki bağlantının kopması

Postmortem:

TL;DR

LLNG ve LDAP arasındaki bağlantıda bir süre trafik olmayınca firewall tarafından otomatik olarak kapatılıyordu. Bunu keepalive ile önledik.

Cuma günü(06.12.2019) SSO'yu ACME için açtık. İlk bir kaç saat hiç bir problemle karşılaşmamıştık. 1-2 saat geçince auth.omu.sh'a bağlanmaya çalışırken 504 Gateway Timeout hatası almaya başladık. Yerelde böyle bir hata almıyorduk, bu nedenle ağ kaynaklı olduğunu düşündüm.

Denemeler:

log analizi: log'lar debug modunda açıldı ancak "Processing getUser" mesajından sonra bir hata kodu yoktu. Log'lar yetersiz kalmıştı.
lemonldap-ng-fastcgi-server servisi yeniden başlatıldı. Bu sorunumuzu 1-2 saatliğine çözüyordu ancak daha sonra yeniden istekler timeout'a düşmeye başlıyordu.
İlk adımda logları analiz ederken "Processing getUser" mesajından sonra log düşmüyordu. LLNG işlevsel haldeyken bu adımdan sonra ne geldiğine baktım ve LDAP'a bağlanmaya çalıştığını gördüm. Sorunun artık LLNG ve LDAP arasındaki bağlantıda olduğunu biliyorduk.
LLNG issue'larına baktığımızda https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1807 açık halde bu issue'yu gördük. Firewall'un boşta bekleyen bağlantıları bir süre sonra kapattığından bahsediliyordu. Önerilen 2 workaround'tan ikincisini, yani keepalive yöntemini kullandık çünkü LDAP'ta timeout süresi ayarlamamıştık.
keepalive yöntemi boş geçen 5 dakikanın ardından dakikada 1 kez karşı tarafa "uyudun mu? ben uyumadım, sen de uyuma" anlamında istek atıyor ve aralarındaki bağlantının firewall tarafından kapatılmasını önlüyor.

sinansh commented 4 years ago

Fortigate Firewall için yazıyorum:

Mevcut auth.omu.sh'da dahil olduğu BAUM IP adres aralığı için herhangi bir güvenlik önlemi bulunmuyor. Production'a geçmeden IPS/IDS eklememiz gerektiğini düşünüyorum. Bunun için @ecylmz gün içinde rahatsız edeceğim, neler yapabiliriz bakmak için.

ecylmz commented 4 years ago

OpenIDConnect::Discovery::DiscoveryFailed: Bad Gateway #1292

TL;DR

Üniversitenin DNS sunucusu(10.10.10.10) zaman zaman auth.omu.sh'ı çözümleyemiyor.

Postmortem:

LLNG ve LDAP arasındaki hatayı çözmemize rağmen bu hata hala devam ediyordu. Hata mesajına baktığımızda bunun DNS sorunu olduğunu tahmin edebiliyorduk ancak emin olmamız gerekiyordu.

Denemeler:

nginx'in access.log dosyası ve nokul-develop'un uygulama logları incelendi. access.log dosyasındaki 500 hata kodu dışında başka bir detay yoktu.
Rollbar incelendi. Rollbar'da detaylı bir şekilde auth.omu.sh'ın ip adresinin bulanamadığı söyleniyordu.
Sunucuda bir cron görevi yazdım: Dakikada 1 nslookup auth.omu.sh komutu çıktısını dosyaya yazdırıp, hatanın oluştuğu andaki dns sorgusu sonucuna bakmak istiyordum.
Hata tekrarlandığında log'larda şunu gördüm:

----
;; Got SERVFAIL reply from 10.10.10.10, trying next server
Server:         10.10.5.5
Address:        10.10.5.5#53
Non-authoritative answer:
Name:   auth.omu.sh
Address: 193.140.28.237
Sun Dec  8 22:08:01 +03 2019
----

Yani 10.10.10.10 dns sunucusu hata dönmüştü.

Bunun ardından nokul-develop'un çalıştığı sunucunun /etc/hosts dosyasına 193.140.28.237 auth.omu.sh` satırını ekledim.

Henüz aynı hata tekrarlanmadı.

ecylmz commented 4 years ago

@msdundar'dan gelen rapor: su cikis yaptiktan sonra redirect icin bekletme isi kaldirilabiliyor mu acaba

Çıkıştan sonra gelen "Information" sayfasında nokul'a iframe içerisinde "logout" isteği attığı için bu sayfada bekletiyor maalesef. Yönetim panelinde kapatmanın bir yolu henüz yok. Kritik de değil açıkcası.

ecylmz commented 4 years ago

LLNG'nin issue'su altında log'lara hata düşmediğini söyledim. https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1807#note_50553

msdundar commented 4 years ago

Login history'de mm-dd-yyyy tarih bicimi kullaniliyor, bu tarih bicimini login history'de ve/veya komple LLNG'de dd-mm-yyyy yapabiliyor muyuz?

ecylmz commented 4 years ago

@msdundar Login History'deki format, kullanıcının tarayıcı diline göre otomatik değişiyormuş: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/commit/81c88216b0737a2a5477e28c733288a5697affd4#2e4f2a77f9b0aeddca5d5bbc1438e947d7cbd1d7_427_421

Mesela bende 11.12.2019 şeklinde gösteriyor.

Yönetim panelinde ya da sunucudaki yapılandırmada zaman formatını değiştirecek bir ayar yok.

roktas commented 4 years ago

@ecylmz: 5 nolu madde için (tema konusu) nokul'da, 6 nolu madde için root'ta iş kaydo açalım. Sonrasında da bu iş kaydını kapatalım.

msdundar commented 4 years ago

LDAP icin monitoring konusu konusuldu mu daha once? Eger konusulmadiysa bu da bir is kaydi olabilir.

ecylmz commented 4 years ago

ilgili issue'lar açıldı: https://github.com/omu/root/issues/46 ve https://github.com/omu/nokul/issues/1312

roktas commented 4 years ago

@msdundar LDAP Datadogs'ta izleniyor diye hatırlıyorum, @ecylmz ?

ecylmz commented 4 years ago

Mevcut durumda sunucunun durumu izleniyor. LDAP metirkleri izlenmiyor.

roktas commented 4 years ago

Datadogs'ta mı nerede, beni örnek almıyor musunuz, biraz daha detaylı yazın yazmaya oturduğunuzda :-)

ecylmz commented 4 years ago

monitör aracı olarak Datadog kullandığımız için ayrıca belirtmemiştim hocam. Acme LDAP sunucusu Datadog üzerinde izleniyor. LDAP metrikleri herhangi bir yerde izlenmiyor.

roktas commented 4 years ago

"LDAP Datadogs'ta izleniyor diye hatırlıyorum" derken bir ara sana bahsettiğim OpenLDAP entegrasyonunun kurulu olduğunu kastettim: https://app.datadoghq.com/account/settings#integrations/openldap yani. Bu kuruluysa metriklerin de gelmesi lazım (dokümanlarından yanlış anlamadıysam). Bu kurulu değilse kuralım, hemen kurulamıyorsa omu/root'ta iş kaydı açalım.

roktas commented 4 years ago

İlgili iş kaydı: https://github.com/omu/root/issues/47

msdundar commented 4 years ago

Yanlis hatirlamiyorsam sistem loglarini Datadog'a almistik. Eger oyleyse LDAP loglarini da ayni sekilde alabiliriz: https://lemonldap-ng.org/documentation/latest/logs

huseyin commented 4 years ago

Benzer durum monitoring için de geçerli ama log'lar bence daha kritik. Kişisel verilerin korunmasına dikkat etmek lazım. Datadog bu anlamda doğru bir tercih mi bence bunun ayrıca tartışmaya açılması gerek.

msdundar commented 4 years ago

Actik diyelim, var mi bir onerin?

Bu isin sonu yok, o zaman LemonLDAP'ta kullanmiyor olmamiz lazimdi. Internetin de boyle bisey olmasi lazimdi, alir kilitli bir odaya koyardik.

huseyin commented 4 years ago

Yani birincisi yasayı ben çıkarmıyorum :) Eğer yok sayacaksak GSuite, Amazon vesaire bunları kullanmak benim (ve bence herkesin) işine gelir. Log toplamak ve LemonLDAP kullanmak bence aynı şeyler de değil. Önerilerim elbette var. Sonuçta log toplayan tek servis Datadog değil :)

omu / nokul