Swarm Düğümünde Üç Gizem: Salt-Okunur İzinler, Hayalet Sütunlar ve Klasik ASP Çöküşleri

Bu gece, Boğaziçi Üniversitesi ders programlarını ve anlık kayıt kontenjanlarını tarayıp indeksleyen yüksek hızlı veri motoru boun-scrape üzerinde kapsamlı bir çok boyutlu kod denetimiyle başladı.

Sürekli entegrasyon (CI) hattında her şey kusursuz görünüyordu: 300’den fazla yeşil yanan pytest düğümü, deterministik SQLite WAL yapılandırmaları, sıfır-kopyalı slot ayrıştırması ve alt-saniyelik delta motorları.

Fakat bakış açımızı canlı Docker Swarm kümesindeki üretim telemetrisine ve gerçek dünya taramalarına çevirdiğimizde, sistem üç ayrı ve son derece şaşırtıcı anomali sergilemeye başladı.

İşte bu üç sinsi mühendislik gizeminin otopsisi, arıza mekanizmalarını nasıl kanıtladığımız ve ardında bıraktığımız sıfır-maliyetli mimari değişmezler.

---

1. Gizem: “Hatalı Giriş Bilgileri” Maskesi Takan 502 Hayaleti

scraper.bountools.com üzerindeki üretim paneline geçerli kimlik bilgileriyle (admin:<şifre>) giriş yapmayı denediğimizde arayüz genel bir hata uyarısı veriyordu.

Ağ sekmesini incelediğimizde, ön yüzün Traefik / Docker Swarm ingress katmanından HTTP 502 Bad Gateway aldığını gördük. Fakat aynı Docker backend imajını yerel geliştirme ortamında çalıştırdığımızda kimlik doğrulama 4ms içinde HTTP 200 OK ile başarıyla tamamlanıyordu.

Çalışır durumdaki canlı bir konteynerde kimlik doğrulama uç noktası neden 502 Bad Gateway döndürsün?

Adli İz Sürümü

WorkHorse (10.34.0.2) worker düğümündeki konteyner günlüklerini inceledik:

sqlite3.OperationalError: attempt to write a readonly database
  File "/app/src/boun_scrape/storage/database.py", line 125, in execute_write
    cursor.execute(query, params)

Modern konteyner dağıtımlarında en temel güvenlik standardı, süreçleri yetkisiz bir kullanıcı kimliğiyle çalıştırmaktır (Dockerfile içindeki USER 10001:10001).

Dokploy yığını boununi-scraper-pw6pfa_schedules_data adlı kalıcı volume’ü /data dizinine bağladığında, Docker bu ana makine dizinini root:root sahipliğiyle oluşturmuştu (0:0, mod 0755):

# WorkHorse düğümünde (10.34.0.2)
ls -ld /var/lib/docker/volumes/boununi-scraper-pw6pfa_schedules_data/_data
drwxr-xr-x 2 root root 4096 Aug 31 16:45 ...

Uygulama mevcut veriyi okuyabiliyordu. Ancak SQLite yalnızca schedules.db dosyasına değil, aynı zamanda atomik WAL günlük kilitlerini (schedules.db-wal ve schedules.db-shm) oluşturabilmek için üst dizine de yazma yetkisine ihtiyaç duyar.

Kullanıcı giriş yaptığında auth rotası SQLite veritabanındaki last_login_at alanını güncellemeye çalıştı. SQLite OperationalError: attempt to write a readonly database fırlattı. İstisna yakalanmayan bir async işleyicide gerçekleştiği için Uvicorn işçi süreci çöktü, ters vekil (reverse proxy) upstream bağlantısını kaybetti ve Traefik ekrana 502 Bad Gateway bastı.

Ön yüz ise ağ arızasını görünce kullanıcıya yanıltıcı bir mesaj gösteriyordu: “Kullanıcı adı/şifre hatalı veya sunucu hatası.”

Mimari Değişmez

Ana makinedeki volume sahipliğini derhal düzelttik (chown -R 10001:10001) ve iki kalıcı koruma sınırı inşa ettik:

1. Açılış Öncesi Veritabanı Teşhisi: DatabaseManager, başlatma anında hem dizine hem de DB dosyasına yazma izinlerini doğrular; UID izinleri hatalıysa yapılandırılmış ve eyleme geçirilebilir bir CRITICAL uyarısı günlüğe kaydeder.
2. Defansif Ağ Yakalayıcıları: Ön yüz API istemcisi, 502/503/504 Ağ Geçidi Hataları ve 429 İstek Limiti durumlarını açıkça yakalayacak ve yanıltıcı şifre uyarısı yerine net teşhis bildirimleri gösterecek şekilde güncellendi.

---

2. Gizem: Portal Tablosundaki 1 Sütunluk Kayma

2026/2027-1 döneminde yapılan ders sorguları tuhaf bozulmalar sergilemeye başladı:

• instructor alanı tüm derslerde "Info" olarak görünüyordu.
• delivery_method alanı "345" veya "234" gibi ders saati değerleri içeriyordu.
• exam_date alanı "M 1171 | M 1171" gibi derslik dizgileriyle dolmuştu.
• Öğretim üyesinin tam adı ("FATİH F. YILMAZ"), gün dizgisi sanılarak karakter karakter tek harfli kukla slotlara bölünmüştü (day: "F", day: "A", day: "T").

Kök Neden: Statik İndeks Varsayımları

Eski HTML ayrıştırıcısını incelediğimizde, ders programı tablosunun sabitlenmiş hücre indekslerine dayandığını gördük:

# Kırılgan eski yaklaşım:
code_sec = tds[0].get_text(strip=True)
slot_title = tds[2].get_text(strip=True)
credits_raw = tds[3].get_text(strip=True)
ects_raw = tds[4].get_text(strip=True)
instructor = tds[5].get_text(strip=True)  # <-- Öğretim üyesinin hep 5. indekste olduğu varsayımı!
days_str = tds[6].get_text(strip=True)
hours_str = tds[7].get_text(strip=True)

Eski dönemlerde tablo 15 sütun olduğu için bu mantık çalışıyordu. Ancak üniversite kayıt portalı 2026/2027-1 dönemiyle birlikte 2. indekse fazladan bir "Info" / Ders İzlencesi link sütunu eklemişti:

Başlıklar: [Code.Sec, Abbr., Info, Name, Cr., Ects, Instr., Days, Hours, Delivery, Exam Loc., Rooms, Exam Date, ...]

Bu tek bir fazladan sütun yüzünden sağdaki tüm indeksler 1 kaydı. 5. indeks "Info" oldu, 6. indeks Öğretim Görevlisi oldu, 7. indeks ise Günler oldu!

Çözüm: Dinamik Anlamsal Başlık Eşlemesi

Sabit tamsayı indeksleri kaldırıp yerine dinamik tablo başlığı analizi yerleştirdik:

def _build_column_index_map(soup: BeautifulSoup) -> dict[str, int]:
    """Tablo başlığından anlamsal alan adlarını dinamik olarak sütun indekslerine eşler."""
    title_tr = soup.find("tr", class_="schtitle") or soup.find(
        "tr", class_=lambda c: bool(c and "title" in str(c).lower())
    )
    if not title_tr:
        return DEFAULT_COLUMN_MAP

    headers = [td.get_text(strip=True).lower() for td in title_tr.find_all(["td", "th"])]
    col_map: dict[str, int] = {}

    for idx, h in enumerate(headers):
        clean_h = re.sub(r"[^a-z0-9\.]", "", h)
        if clean_h in ("code.sec", "codesec", "code", "derskodu"):
            col_map["code_sec"] = idx
        elif clean_h in ("name", "dersadi", "coursename", "title"):
            col_map["name"] = idx
        elif ("instr" in clean_h or "ogretim" in clean_h):
            col_map["instructor"] = idx
        elif clean_h in ("days", "gun", "gunler"):
            col_map["days"] = idx
        elif clean_h in ("hours", "saat", "saatler"):
            col_map["hours"] = idx
        # ... öğretim türü, sınav yerleri, derslikler ve tarihleri dinamik eşler
    return col_map

Üniversite portalı ister 14, ister 15, ister 16 veya 18 sütun göndersin; ayrıştırıcı her anlamsal alanı tanıdığı sütun başlığına bağlayarak scraper’ı gelecekteki arayüz değişikliklerine karşı tamamen bağışık hale getirir.

---

3. Gizem: Yeniden Adlandırılmış Bölümlerdeki Klasik ASP 500 Hatası

2024/2025-3 dönemi tam taraması sırasında işlem şu hatayla kilitlendi:

boun_scrape.scraper.client.BounHttpError: Server error 500 requesting /scripts/sch.asp
[ERROR] All-terms cycle: term 2024/2025-3 failed: SCED: Server error 500

Buna karşın aynı dönemdeki ATA ve CMPE bölümlerine yapılan curl istekleri HTTP 200 OK dönüyordu.

Üniversitenin IIS sunucusu 31 bölüm için 200 dönerken, neden yalnızca SCED bölümünde işlenmemiş bir 500 hatasıyla çöküyordu?

ASP Sorgusunu Tersine Mühendislikle İncelemek

Değişkenleri izole etmek için Boğaziçi’nin kayıt sunucusuna (registration.bogazici.edu.tr) doğrudan curl istekleri gönderdik:

# 1. SCED bölümünü güncel adıyla sorgulamak:
curl "https://registration.bogazici.edu.tr/scripts/sch.asp?donem=2024/2025-3&kisaadi=SCED&bolum=SECONDARY+SCHOOL+SCIENCE+AND+MATHEMATICS+EDUCATION"
# -> HTTP 200 OK

# 2. SCED bölümünü boş bolum parametresiyle sorgulamak:
curl "https://registration.bogazici.edu.tr/scripts/sch.asp?donem=2024/2025-3&kisaadi=SCED&bolum="
# -> HTTP 200 OK

# 3. SCED bölümünü geçmişte önbelleğe alınmış eski adıyla sorgulamak ("MATHEMATICS AND SCIENCE EDUCATION"):
curl "https://registration.bogazici.edu.tr/scripts/sch.asp?donem=2024/2025-3&kisaadi=SCED&bolum=MATHEMATICS+AND+SCIENCE+EDUCATION"
# -> HTTP 500 Internal Server Error (Microsoft IIS / SQL Server Recordset Hatası)

Üniversitenin Classic ASP arka ucu, hem kisaadi hem de bolum parametrelerini filtreleyen SQL recordset sorguları çalıştırır. Bir bölüm yıllar içinde yeniden adlandırılmışsa ve veritabanı önbelleğinden eski adıyla sorgulanırsa, Microsoft IIS tarafında işlenmemiş bir veritabanı istisnası tetiklenir.

En kritik keşif: bolum="" parametresi boş bırakıldığında sunucu asla çökmez.

Cerrahi Geri Dönüş (Fallback) Mekanizması

src/boun_scrape/scraper/flow.py içerisine otomatik bir geri dönüş mantığı yerleştirdik:

try:
    response = await client.get(SCHEDULE_DEPT_URL, params=params)
except BounHttpError as exc:
    # ASP portalı 500 döndüyse ve bolum doluysa, boş bolum ile bir kez daha dene
    if exc.status_code == 500 and bolum:
        logger.info(
            "Portal returned 500 for department %s with bolum='%s'; retrying with empty bolum fallback",
            dept_code,
            bolum,
        )
        fallback_params = {"donem": term, "kisaadi": dept_code, "bolum": ""}
        response = await client.get(SCHEDULE_DEPT_URL, params=fallback_params)
    else:
        raise

Üniversite yarın başka bir bölümün adını değiştirse dahi, scraper ilk 500 yanıtında kendiliğinden bolum="" moduna geçerek tarama hattını insan müdahalesine gerek kalmadan kendi kendine onarır.

---

Canlı Web İndekslemenin Öğrettikleri

Eski kurumsal sistemleri taramak hiçbir zaman yalnızca HTML seçicileri yazmaktan ibaret değildir. Asıl mesele, sistemlerin birbirine temas ettiği sınırları doğru kavramaktır:

1. Host-Konteyner Sınırları: Konteyner güvenlik modelleri (USER 10001), ana makine volume izinleriyle (chown 10001:10001) tam hizalanmalıdır; aksi takdirde dahili veritabanı hataları ağ kesintisi maskesi takar.
2. Sözleşme Sınırları: HTML tablolarının sabit sütun sayılarına sahip olduğunu asla varsaymayın. Başlıkları sınırda anlamsal olarak ayrıştırın.
3. Eski Sunucu Kaprisleri: Eski nesil arka uçlar beklenmedik davranışlar sergilediğinde sorgu permütasyonlarını tek tek izole edin. Tek bir boş parametre geri dönüşü, kırılgan bir tarayıcıyı sarsılmaz bir hatta dönüştürebilir.

31 saniyede tamamlanan 305 test ve sıfır borç kaydıyla scraper, swarm içinde sessiz, sakin ve kararlı bir şekilde akmaya devam ediyor.