Napraw błąd 500 w SLES dotyczący nieudanego odświeżania repozytoriów Zypper

Przykład ilustrujący: Wyobraź sobie administratora SLES o nazwie Maya uruchamiającego się sudo zypper refreshpo rutynowym oknie konserwacji. Jedno repozytorium zwraca „Błąd 500: Wewnętrzny błąd serwera”, podczas gdy pozostałe się odświeżają. Przykład Maya jest hipotetyczny, ale pokazuje kluczowy punkt diagnostyczny: HTTP 500 to odpowiedź z serwera lub pośrednika, takiego jak serwer proxy, a nie dowód na uszkodzenie lokalnej pamięci podręcznej metadanych Zyppera.

Aby naprawić błąd odświeżania repozytorium Zypper w systemie SUSE Linux Enterprise Server (SLES), najpierw zidentyfikuj konkretne repozytorium i adres URL, którego dotyczy problem, a następnie ustal, czy odpowiedź pochodzi z Centrum Obsługi Klienta SUSE (SCC), wewnętrznego serwera narzędzia do tworzenia kopii lustrzanych repozytoriów (RMT) czy sieciowego serwera proxy. Spróbuj ponownie wymuszonego odświeżenia metadanych dopiero po sprawdzeniu punktu końcowego. Ponowna rejestracja komputera lub usunięcie konfiguracji repozytorium bez dowodów może utrudnić zdiagnozowanie problemu.

Co mówi Ci HTTP 500 podczas odświeżania

Gdy Zypper odświeża repozytorium, pobiera metadane repozytorium ze skonfigurowanego adresu URI. Odpowiedź HTTP 500 oznacza, że ​​serwer HTTP obsługujący to żądanie zgłasza błąd wewnętrzny. Serwer może być hostem repozytorium, serwerem lustrzanym organizacji lub serwerem proxy znajdującym się między maszyną SLES a repozytorium. Sam kod nie identyfikuje, który z nich uległ awarii, ani nie potwierdza, że ​​usługa SUSE jest wyłączona.

Aktualne wytyczne dla administratorów SUSE opisują ten sposób zypper refreshjako standardowy sposób pobierania zmian w repozytorium i zalecają, aby zypper refresh -fdbw przypadku, gdy odświeżenie nie rozwiązuje problemu z metadanymi repozytorium, wymusić pełne odświeżenie i przebudować bazę danych pakietów, w tym wymusić pobranie surowych metadanych. Może naprawić nieaktualne lokalne metadane, ale nie naprawi serwera, który stale zwraca błąd HTTP 500. Zobacz Podręcznik administratora SUSE SLES 15 SP7 .

1. Zidentyfikuj repozytorium i zarejestruj dokładną awarię

W przykładzie Maya, wynik odświeżania podaje nazwę jednego aliasu repozytorium przed zgłoszeniem błędu. Zacznij od jednokrotnego powtórzenia polecenia i zanotowania aliasu, hosta adresu URL żądania oraz informacji o tym, czy inne repozytoria zakończyły się powodzeniem:

sudo zypper refresh

Następnie wypisz aliasy repozytoriów i ich skonfigurowane adresy URL:

zypper lr -u

Dopasuj uszkodzony alias w wynikach odświeżania do jego URI na tej liście. URI hostowane w RMT organizacji lub innym prywatnym serwerze lustrzanym należy sprawdzić z administratorem tego serwera. URI wskazujące na publiczną usługę SUSE należy sprawdzić z sieci, której dotyczy problem, a jeśli to możliwe, z drugiej sieci lub innego klienta SLES.

Adresy URL repozytorium mogą zawierać dane dostępu lub podpisane parametry zapytania. Nie publikuj nieocenzurowanych wyników poleceń, pakietów pomocy technicznej ani adresów URL na forum publicznym. Zachowaj alias repozytorium, nazwę hosta, znacznik czasu, pakiet serwisowy SLES i kod odpowiedzi; ukryj dane uwierzytelniające i tokeny.

2. Sprawdź, czy błąd jest lokalny, współdzielony czy pochodzi z nadrzędnego źródła

Przed zmianą konfiguracji należy przeprowadzić proste porównanie. Jeśli na jednym serwerze wystąpi awaria tylko jednego repozytorium, należy sprawdzić adres URL tego repozytorium i jego usługę. Jeśli to samo repozytorium ulegnie awarii na wielu klientach w tej samej sieci, należy sprawdzić współdzielony serwer proxy, zaporę sieciową lub serwer lustrzany. Jeśli wielu klientów w różnych sieciach ulegnie awarii na tym samym punkcie końcowym SUSE, bardziej prawdopodobny staje się przejściowy problem z serwerem źródłowym. Te wzorce to wskazówki, a nie dowody; należy je potwierdzić u właściciela usługi lub w kanale wsparcia technicznego swojej organizacji.

W przypadku punktu końcowego, do którego masz uprawnienia do zapytania, klient HTTP może wyświetlić nagłówki odpowiedzi i status końcowy. W miarę możliwości należy używać dokładnego adresu URL metadanych repozytorium, zamiast zakładać, że katalog główny repozytorium zwraca tę samą odpowiedź. Na przykład:

curl -sS -L -D - -o /dev/null 'https://repository.example.invalid/path/to/metadata'

Zastąp przykładowy adres URL odpowiednim punktem końcowym. Nie dodawaj osadzonych danych uwierzytelniających ani tokenów do udostępnianego polecenia. Strona błędu wygenerowana przez serwer proxy może nadal wyświetlać błąd HTTP 500, dlatego porównuj odpowiedź z zatwierdzonej ścieżki bezpośredniej lub innego klienta tylko wtedy, gdy zezwala na to polityka sieciowa. Unikaj pomijania wymaganego firmowego serwera proxy lub bramy bezpieczeństwa bez autoryzacji.

Jeśli wadliwe repozytorium jest repozytorium niestandardowym, poproś jego opiekuna o sprawdzenie logów serwera, pojemności pamięci masowej, stanu zaplecza i publikacji metadanych repozytorium. Jeśli adres URL wskazuje na RMT, rozwiąż problemy z RMT zamiast wielokrotnie zmieniać klienta. W przewodniku SUSE RMT wyjaśniono, że RMT synchronizuje dane produktów repozytorium z SCC i tworzy kopię lustrzaną pakietów repozytorium według własnego harmonogramu.

3. Sprawdź konfigurację serwera proxy i sieci

Brama lub serwer proxy może zwrócić własną odpowiedź 500, gdy usługa nadrzędna jest niedostępna, nie można przetworzyć odpowiedzi nadrzędnej lub serwer proxy jest nieprawidłowo skonfigurowany. Porównaj ścieżkę sieciową uszkodzonego komputera z działającym hostem SLES. Sprawdź ustawienia serwera proxy skonfigurowane dla systemu operacyjnego i Zyppera, w tym czy nazwa hosta repozytorium jest nieoczekiwanie wysyłana przez serwer proxy lub z niego wykluczona.

Nie wklejaj publicznie konfiguracji serwera proxy, jeśli zawiera ona nazwy użytkowników, hasła lub wewnętrzne nazwy hostów. Jeśli zarządzasz serwerem proxy, poproś jego administratora o skorelowanie znacznika czasu żądania z logami serwera proxy i potwierdzenie, czy żądanie 500 pochodziło z serwera proxy, czy z serwera źródłowego. Jeśli dostęp bezpośredni jest zabroniony, przeprowadź dochodzenie w ramach zatwierdzonej ścieżki serwera proxy.

Przykład Mai ma teraz wyraźną gałąź: jej pozostałe repozytoria działają, a tylko lustro organizacji ulega awarii na kilku serwerach. Ten schemat wskazuje najpierw na zespół ds. współdzielonego lustra lub proxy, a nie na problem z rejestracją SLES w całym systemie.

4. Zweryfikuj rejestrację SLES i adresy URL repozytorium

W przypadku repozytoriów udostępnianych za pośrednictwem rejestracji SUSE należy sprawdzić zarejestrowane produkty i moduły systemu:

SUSEConnect -s
zypper lr -u

Dokumenty SUSE SUSEConnect -sdo sprawdzania lokalnie zainstalowanych produktów i ich statusu oraz zypper lr -udo wyświetlania listy repozytoriów wraz z ich źródłowymi identyfikatorami URI. Porównaj dane wyjściowe z wersją SLES i modułami, których ta maszyna ma używać. Nieprawidłowy lub nieaktualny identyfikator URI może zwrócić błąd z wycofanego, niezgodnego lub nieprawidłowo skonfigurowanego punktu końcowego.

Jeśli rejestracja nie została ukończona lub wymagany moduł nie jest zarejestrowany, należy postępować zgodnie z procedurą rejestracji produktu odpowiednią dla danej wersji i subskrypcji SLES. Przewodnik rejestracyjny firmy SUSE opisuje rejestrowanie SLES oraz zarządzanie modułami i rozszerzeniami. Nie należy wyrejestrowywać ani ponownie rejestrować komputera produkcyjnego w pierwszej kolejności w odpowiedzi na błąd HTTP 500: firma SUSE zaznacza, że ​​wyrejestrowanie powoduje usunięcie repozytoriów produktu, a zmiany w rejestracji należy planować z właścicielem systemu.

W przypadku repozytorium zarządzanego samodzielnie sprawdź, czy skonfigurowany adres URL bazowy jest zgodny z aktualnymi instrukcjami dostawcy repozytorium oraz zainstalowaną wersją i architekturą systemu SLES. Nie zgaduj ścieżki, zmieniając numer Service Pack. Jeśli poprawiasz URI, zapisz oryginalną wartość i zmień tylko repozytorium, którego dotyczy problem, korzystając ze standardowego procesu zarządzania konfiguracją.

5. Ponów próbę z wymuszonym odświeżeniem po przywróceniu sprawności punktu końcowego

Gdy właściciel serwera lub serwera proxy potwierdzi, że punkt końcowy odpowiada prawidłowo — lub gdy rozwiążesz problem z zweryfikowanym adresem URL — spróbuj ponownie odświeżyć repozytorium. Zacznij od standardowego odświeżenia:

sudo zypper refresh

Jeśli metadane nadal wydają się nieaktualne lub niekompletne, skorzystaj z udokumentowanej przez firmę SUSE opcji pełnego odświeżenia:

sudo zypper refresh -fdb

Zmusza to Zyppera do pobrania surowych metadanych i odbudowania lokalnej bazy danych z możliwością rozwiązania. Jest to przydatny krok odzyskiwania po przywróceniu działania zdalnego punktu końcowego. Jeśli zwróci ten sam błąd HTTP 500, należy przerwać powtarzanie polecenia i powrócić do punktu końcowego, serwera proxy lub lustra; lokalna odbudowa pamięci podręcznej nie może naprawić awarii po stronie serwera.

6. Bezpiecznie obsługuj jedno uszkodzone opcjonalne repozytorium

Jeśli pojedyncze repozytorium zewnętrzne okaże się niedostępne i konieczne będzie przeprowadzenie prac konserwacyjnych, przed jego wyłączeniem skonsultuj się z właścicielem repozytorium i zapoznaj się z polityką zmian. Zypper może wyłączyć repozytorium za pomocą aliasu:

sudo zypper modifyrepo --disable REPOSITORY_ALIAS

Użyj dokładnego aliasu z zypper lri udokumentuj zmianę. Wyłączenie repozytorium może uniemożliwić aktualizacje oprogramowania zainstalowanego z niego. Nie wyłączaj podstawowych repozytoriów aktualizacji SLES jako ogólnego obejścia problemu ani nie usuwaj definicji repozytoriów tylko po to, aby wyciszyć błąd. Ponownie włącz tymczasowo wyłączone repozytorium po potwierdzeniu jego przywrócenia przez administratora:

sudo zypper modifyrepo --enable REPOSITORY_ALIAS

W podręczniku administratora SLES opisano włączanie i wyłączanie repozytoriów za pomocą zypper modifyrepo. Zachowanie repozytoriów i dostępne opcje mogą się różnić w zależności od zainstalowanej wersji Zyppera; sprawdź zypper help modifyrepona hoście, czy składnia opcji jest inna.

Zweryfikuj naprawę

Zakończ czystym odświeżeniem i sprawdź, które repozytoria są włączone i zaplanowane do odświeżenia:

sudo zypper refresh
zypper lr -u

Pomyślny wynik oznacza, że ​​repozytorium, które wcześniej uległo awarii, kończy odświeżanie metadanych bez HTTP 500, a oczekiwane repozytoria pozostają włączone z poprawnymi adresami URL. Jeśli odświeżenie zakończy się powodzeniem dopiero po wyłączeniu repozytorium, należy to traktować jako tymczasowe obejście problemu, a nie jako ukończoną naprawę: pakiety z tego źródła mogą już nie otrzymywać aktualizacji.

W ilustrującym to przypadku Maya, administrator lustra naprawia odpowiedź po stronie serwera. Następnie Maya uruchamia standardowe odświeżenie, używając go -fdbtylko wtedy, gdy lokalne metadane nadal wymagają odbudowania, i potwierdza, że ​​alias lustra został odświeżony. Ten wynik jest przykładem sekwencji diagnostycznej, a nie raportem z rzeczywistego testu.

Kiedy eskalować

Skontaktuj się z zespołem ds. serwera lustrzanego lub proxy, gdy wielu klientów otrzyma tę samą odpowiedź z wewnętrznego punktu końcowego. Skontaktuj się z właścicielem repozytorium lub pomocą techniczną SUSE, gdy błąd da się odtworzyć na oficjalnym punkcie końcowym SUSE po sprawdzeniu lokalnej ścieżki sieciowej i rejestracji. Dołącz wydanie SLES i dodatek Service Pack, alias repozytorium, nazwę hosta (z usuniętymi poufnymi szczegółami ścieżki), znacznik czasu i strefę czasową, informację o odświeżaniu innych repozytoriów oraz status HTTP lub wyczyszczony fragment błędu. Ten dowód pomoże właścicielowi usługi wyśledzić nieudane żądanie bez ujawniania kodów rejestracyjnych ani danych uwierzytelniających.