SLES Zypper HTTP 500: Zoek de defecte repository

Wanneer zypper refreshSLES een HTTP 500-foutmelding geeft, moet u eerst vaststellen welke repository-URL deze fout heeft geretourneerd. Een HTTP 500-fout betekent dat een server die het verzoek verwerkt een onverwachte situatie heeft ondervonden; de responder kan de repositoryhost zijn, de RMT-server van een organisatie of een HTTP-proxy. Isoleer de betreffende repository en herstel of rapporteer het probleem op dat eindpunt voordat u de lokale metadata wist. Een geforceerde cachereconstructie kan een server die nog steeds een 500-foutmelding geeft, niet herstellen.

De huidige SUSE SLES 15 SP7-beheer- en upgradehandleidingen beschrijven de lijst met repositories en de bijbehorende vernieuwingsopdrachten, inclusief zypper refresh -fdbhet opnieuw opbouwen van de lokale repositorymetadata. Ze vermelden echter geen actueel SLES-breed HTTP 500-incident. De praktische oplossing hangt af van de vraag of de URL toebehoort aan SUSE Customer Center, een interne mirror of een repository van een derde partij.

Is er sprake van een storing in één repository of in meerdere?

Begin met het noteren van de alias en URL van de repository. Voer op SLES het volgende commando uit:

zypper repos -u

Deze -uoptie toont de oorsprong van elke geconfigureerde repository. Noteer welke items zijn ingeschakeld en ingesteld op vernieuwen, en vergelijk vervolgens de hostnamen van de URL's die niet werken. Als een repository van een derde partij niet werkt terwijl de SUSE-updatebronnen wel succesvol worden vernieuwd, onderzoek dan de eigenaar van die repository. Als meerdere repositories naar dezelfde interne host verwijzen en allemaal niet werken, is de gedeelde mirror, de RMT-service, de reverse proxy of de upstream-verbinding een betere aanwijzing.

Vervolgens moet u alleen de betreffende repository op basis van de alias vernieuwen:

sudo zypper refresh -f 'Vendor-App'

Vervang dit Vendor-Appdoor de exacte alias die wordt weergegeven door zypper repos -u. Dit voorkomt een scherm met herhaalde fouten van niet-gerelateerde repositories en geeft u een gericht resultaat dat u met de beheerder kunt delen. Als de alias spaties bevat, behoud dan de enkele aanhalingstekens. Bewaar de exacte URL en het tijdstempel van de fout, maar verwijder alle ingesloten gebruikersnamen, wachtwoorden, tokens of andere geheime gegevens voordat u logbestanden of schermafbeeldingen verzendt.

Geeft het metadata-eindpunt zelf een HTTP 500-foutmelding terug?

Lees de volledige Zypper-foutmelding en identificeer de specifieke metadata-URL die daarin wordt genoemd, vaak een bestand in de repodatamap van de repository. Als het eindpunt zonder inloggegevens kan worden opgevraagd, vergelijk dan het HTTP-antwoord van de SLES-host:

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

Stel de opdracht METADATA_URLin op de exacte URL van de metadata die de fout veroorzaakt, zonder inloggegevens in de URL of de opdrachtregel te plaatsen. De opdracht print de responseheaders en negeert de responsebody. Een resultaat zoals dit HTTP/1.1 500bevestigt dat een server in het aanvraagpad een fout retourneert; het bewijst niet of de oorspronkelijke server of een tussenliggende server de fout heeft veroorzaakt. Curl gebruikt mogelijk ook andere authenticatie- of proxy-instellingen dan Zypper, dus beschouw dit als een vergelijking, niet als een definitieve reproductie. Als toegang tot de repository authenticatie vereist, gebruik dan de door uw organisatie goedgekeurde testmethode in plaats van inloggegevens openbaar te maken.

Een 500-respons is iets anders dan een probleem met de lokale metadatacache. Het is ook te onderscheiden van DNS-fouten, TLS-certificaatfouten, time-outs en authenticatiereacties zoals 401 of 403. Deze berichten vereisen andere controles. Schakel TLS-verificatie niet uit, wijzig de repository niet naar gewoon HTTP en verwijder niet herhaaldelijk caches om een ​​500-respons te laten verdwijnen. Volgens de HTTP-semantiek definieert RFC 9110 een 500-respons als een onverwachte serverconditie die verhinderde dat het verzoek kon worden uitgevoerd.

Waar moet je de reparatie uitvoeren?

• SUSE Customer Center-repositories: Probeer het na een korte pauze nogmaals als de fout tijdelijk lijkt. Als hetzelfde SUSE-gehoste eindpunt herhaaldelijk een 500-foutmelding geeft, noteer dan het product, het servicepack, de architectuur, de URL van de repository en het tijdstip van de fout. Neem vervolgens contact op met de SUSE-ondersteuningsafdeling van uw organisatie. Controleer de registratie- en abonnementsgegevens als het antwoord wijst op een probleem met de machtigingen of toegang; een HTTP 500-foutmelding op zich bewijst niet dat het abonnement ongeldig is.
• RMT of een andere interne mirror: Vraag de mirrorbeheerder om de server- en reverse-proxy-logboeken van het betreffende tijdstip te controleren, te bevestigen dat de gevraagde repository is ingeschakeld en gesynchroniseerd, en te verifiëren of het metadata-bestand op het opgegeven pad aanwezig is. SUSE beschrijft RMT als een manier voor SLES-clients om updates van een lokale server op te halen in plaats van rechtstreeks contact op te nemen met SCC.
• Repository van derden: Controleer de huidige instructies voor de repository van de leverancier en bevestig dat de URL overeenkomt met de geïnstalleerde SLES-release en -architectuur. Als de bron is verplaatst, werk deze dan alleen bij naar een URL die door die leverancier is gepubliceerd. Schakel een repository alleen uit nadat u hebt bevestigd dat deze optioneel is en niet langer nodig is; laat een vereiste SLES-updatebron niet uitgeschakeld om de fout te verbergen.

Je kunt de status van een repository inspecteren en wijzigen met Zypper of YaST. Met de gedocumenteerde opdracht kun je bijvoorbeeld zypper modifyrepoeen repository uitschakelen via een alias, maar dat is een tijdelijke operationele keuze en geen oplossing voor een defecte vereiste bron. Vermijd het bewerken van gegenereerde repository-URL's op basis van giswerk, vooral na een servicepackmigratie, omdat product- en update-repositories versiespecifieke paden gebruiken.

Wanneer moet je de lokale metadatacache opnieuw opbouwen?

Probeer alle ingeschakelde repositories pas opnieuw nadat de server of proxy een geldig antwoord heeft teruggestuurd:

sudo zypper refresh -f

Als het eindpunt nu wel reageert, maar Zypper nog steeds verouderde of inconsistente lokale repositorygegevens rapporteert, raadt de sectie over probleemoplossing van SUSE SLES 15 SP7 een volledige vernieuwing van de metadata en een heropbouw van de database aan met:

sudo zypper refresh -fdb

Dit dwingt een download van ruwe metadata af en herbouwt de lokale, oplosbare database van Zypper. Het is nuttig bij problemen met lokale metadata; het is geen oplossing voor een aanhoudende 500-foutmelding. Verwar het vernieuwen van de repositorymetadata niet met het installeren van updates: voer uw normale patch- of updateopdracht pas uit nadat het vernieuwen succesvol is voltooid.

Hoe controleer je of de oplossing werkt?

Voer de test eerst uit zypper refresh -f 'ALIAS'voor de bron die eerder een fout gaf, en vervolgens sudo zypper refresh -fvoor alle ingeschakelde repositories. De oplossing is bevestigd wanneer de metadata van de betreffende repository zonder HTTP 500-fout wordt gedownload en Zypper klaar is zonder dat er een ingeschakelde bron een fout vertoont. Als een bron nog steeds een fout geeft, bewaar dan de exacte URL, statuscode, responsheaders en tijd, en geef deze door aan de eigenaar van dat eindpunt.

Officiële referenties

• SUSE SLES 15 SP7 Beheerhandleiding — het beheren van repositories en de gedocumenteerde geforceerde metadataverversing.
• SUSE SLES 15 SP7 Upgradehandleiding — lijst met geregistreerde repositories en hun bron-URL's.
• Handleiding voor de SUSE SLES 15 SP7 Repository Mirroring Tool — clients configureren voor gebruik met RMT.
• IETF RFC 9110: HTTP-semantiek — Definities van HTTP-statuscodes, inclusief 500 Internal Server Error.