SLES Zypper HTTP 500: Znajdź niedziałające repozytorium

Gdy zypper refreshw systemie SLES zostanie zgłoszony błąd HTTP 500, należy najpierw zidentyfikować adres URL repozytorium, który go zwrócił. Błąd HTTP 500 oznacza, że ​​serwer obsługujący żądanie napotkał nieoczekiwany problem; serwerem odpowiadającym może być host repozytorium, serwer RMT organizacji lub serwer proxy HTTP. Przed wyczyszczeniem lokalnych metadanych należy wyizolować uszkodzone repozytorium i naprawić lub zgłosić ten punkt końcowy. Wymuszona odbudowa pamięci podręcznej nie może naprawić serwera, który nadal zwraca błąd 500.

Aktualne podręczniki administracji i aktualizacji systemu SUSE SLES 15 SP7 dokumentują polecenia dotyczące listy i odświeżania repozytoriów, w tym zypper refresh -fdbdotyczące odbudowy lokalnych metadanych repozytorium. Nie identyfikują one bieżącego incydentu HTTP 500 w całym systemie SLES. Praktyczne rozwiązanie zależy od tego, czy adres URL należy do Centrum Obsługi Klienta SUSE, wewnętrznego serwera lustrzanego, czy repozytorium innej firmy.

Czy jedno repozytorium uległo awarii, czy jest ich kilka?

Zacznij od zapisania aliasu i adresu URL repozytorium. W SLES uruchom:

zypper repos -u

Opcja -uwyświetla pochodzenie każdego skonfigurowanego repozytorium. Zwróć uwagę, które wpisy są włączone i ustawione na odświeżanie, a następnie porównaj nazwy hostów adresów URL, które nie działają. Jeśli jedno repozytorium zewnętrzne ulegnie awarii, podczas gdy źródła aktualizacji SUSE zostaną pomyślnie odświeżone, sprawdź właściciela tego repozytorium. Jeśli kilka repozytoriów wskazuje na tego samego hosta wewnętrznego i wszystkie ulegną awarii, silniejszym tropem jest współdzielone lustro, usługa RMT, odwrotny serwer proxy lub jego połączenie nadrzędne.

Następnie odśwież tylko repozytorium, którego dotyczy problem, według aliasu:

sudo zypper refresh -f 'Vendor-App'

Zastąp Vendor-Appgo dokładnym aliasem wskazanym przez zypper repos -u. Pozwoli to uniknąć wyświetlania ekranu z powtarzającymi się błędami z niepowiązanych repozytoriów i zapewni Ci skupiony wynik do udostępnienia administratorowi. Jeśli alias zawiera spacje, zachowaj pojedyncze cudzysłowy. Zachowaj dokładny adres URL i znacznik czasu błędu, ale usuń wszelkie osadzone nazwy użytkownika, hasła, tokeny lub inne tajne dane przed wysłaniem logów lub zrzutów ekranu.

Czy punkt końcowy metadanych sam w sobie zwraca HTTP 500?

Przeczytaj cały błąd Zyppera i zidentyfikuj konkretny adres URL metadanych, który on wskazuje – często jest to plik w katalogu repozytorium repodata. Jeśli punkt końcowy można przeszukać bez poświadczeń, porównaj jego odpowiedź HTTP z hosta SLES:

curl -sS -D - -o /dev/null --max-time 20 "$METADATA_URL"

Ustaw METADATA_URLdokładny adres URL metadanych, które nie działają, bez podawania danych uwierzytelniających w adresie URL lub wierszu poleceń. Polecenie wyświetla nagłówki odpowiedzi i usuwa treść odpowiedzi. Wynik, taki jak HTTP/1.1 500„potwierdza”, że serwer w ścieżce żądania zwraca błąd; nie dowodzi on jednak, czy błąd został wygenerowany przez źródło, czy pośrednika. Curl może również używać innych ustawień uwierzytelniania lub proxy niż Zypper, więc traktuj to jako porównanie, a nie jako definitywne odtworzenie. Jeśli dostęp do repozytorium wymaga uwierzytelnienia, użyj zatwierdzonej w organizacji metody testowania zamiast ujawniania danych uwierzytelniających.

Odpowiedź 500 różni się od problemu z lokalną pamięcią podręczną metadanych. Różni się również od awarii DNS, błędów certyfikatu TLS, przekroczenia limitu czasu i odpowiedzi uwierzytelniających, takich jak 401 lub 403. Te komunikaty wymagają innych kontroli. Nie należy wyłączać weryfikacji TLS, zmieniać repozytorium na zwykły HTTP ani wielokrotnie usuwać pamięci podręcznej, aby zniknęła odpowiedź 500. W przypadku semantyki HTTP, RFC 9110 definiuje odpowiedź 500 jako nieoczekiwany stan serwera, który uniemożliwił realizację żądania.

Gdzie należy dokonać naprawy?

• Repozytoria Centrum Obsługi Klienta SUSE: Spróbuj ponownie po krótkiej przerwie, jeśli awaria wydaje się tymczasowa. Jeśli ten sam hostowany punkt końcowy SUSE nadal zwraca błąd 500, zapisz produkt, dodatek Service Pack, architekturę, adres URL repozytorium i czas awarii, a następnie sprawdź ścieżkę wsparcia technicznego SUSE w swojej organizacji. Potwierdź dane rejestracji i subskrypcji, jeśli odpowiedź wskazuje na problem z uprawnieniami lub dostępem; sam błąd HTTP 500 nie oznacza, że ​​subskrypcja jest nieważna.
• RMT lub inne wewnętrzne lustro: Poproś administratora lustra o sprawdzenie dzienników serwera i odwrotnego serwera proxy w zarejestrowanym czasie, potwierdzenie, że żądane repozytorium jest włączone i zsynchronizowane oraz sprawdzenie, czy plik metadanych istnieje w obsługiwanej ścieżce. SUSE dokumentuje RMT jako sposób, w jaki klienci SLES mogą pobierać aktualizacje z serwera lokalnego zamiast kontaktować się bezpośrednio z SCC.
• Repozytorium innej firmy: Sprawdź aktualne instrukcje dostawcy dotyczące repozytorium i upewnij się, że adres URL jest zgodny z zainstalowaną wersją i architekturą SLES. Jeśli źródło zostało przeniesione, zaktualizuj je tylko do adresu URL opublikowanego przez tego dostawcę. Wyłącz repozytorium dopiero po potwierdzeniu, że jest opcjonalne i nie jest już potrzebne; nie pozostawiaj wyłączonego wymaganego źródła aktualizacji SLES, aby ukryć błąd.

Stan repozytorium można sprawdzić i zmienić za pomocą Zyppera lub YaST. Na przykład, udokumentowane zypper modifyrepopolecenie może wyłączyć repozytorium za pomocą aliasu, ale jest to opcja tymczasowa, a nie naprawa uszkodzonego wymaganego źródła. Unikaj edycji wygenerowanych adresów URL repozytorium na zasadzie domysłów, zwłaszcza po migracji Service Packa, ponieważ repozytoria produktów i aktualizacji korzystają ze ścieżek specyficznych dla wersji.

Kiedy należy odbudować pamięć podręczną lokalnych metadanych?

Dopiero po otrzymaniu prawidłowej odpowiedzi od serwera lub serwera proxy należy ponowić próbę połączenia ze wszystkimi włączonymi repozytoriami:

sudo zypper refresh -f

Jeśli punkt końcowy teraz odpowiada, ale Zypper nadal zgłasza nieaktualne lub niespójne dane lokalnego repozytorium, sekcja rozwiązywania problemów SLES 15 SP7 w systemie SUSE zaleca całkowite odświeżenie metadanych i przebudowę bazy danych za pomocą:

sudo zypper refresh -fdb

Wymusza to pobranie surowych metadanych i odbudowę lokalnej bazy danych Zyppera z możliwością rozwiązania. Jest to przydatne w przypadku problemów z lokalnymi metadanymi, ale nie rozwiązuje problemu z ciągłym komunikatem o błędzie 500. Nie należy mylić odświeżania metadanych repozytorium z instalacją aktualizacji: uruchom standardowe polecenie łatki lub aktualizacji dopiero po pomyślnym zakończeniu odświeżania.

Jak weryfikujesz poprawkę?

Uruchom zypper refresh -f 'ALIAS'dla poprzednio uszkodzonego źródła, a następnie sudo zypper refresh -fdla wszystkich włączonych repozytoriów. Naprawa zostanie potwierdzona, gdy metadane uszkodzonego repozytorium zostaną pobrane bez protokołu HTTP 500, a Zypper zakończy działanie bez włączonego uszkodzonego źródła. Jeśli jedno źródło nadal będzie miało awarię, zachowaj dokładny adres URL, kod statusu, nagłówki odpowiedzi i czas i przekaż je właścicielowi tego punktu końcowego.

Oficjalne źródła

• Podręcznik administratora SUSE SLES 15 SP7 — zarządzanie repozytoriami i udokumentowane wymuszone odświeżanie metadanych.
• Przewodnik po aktualizacji SUSE SLES 15 SP7 — lista zarejestrowanych repozytoriów i ich źródłowych adresów URL.
• Podręcznik narzędzia do tworzenia kopii lustrzanych repozytorium w systemie SUSE SLES 15 SP7 — konfigurowanie klientów do korzystania z RMT.
• IETF RFC 9110: Semantyka HTTP — definicje kodów stanu HTTP, w tym 500 Internal Server Error.