Zagon posrednika git na prenosnem strežniku
Stanje
Sprejeto. Opisano stanje je tisto, ki teče.
Okoliščine
Paket teče na prenosnem strežniku: Apache s PHP kot modulom, ne IIS in ne FastCGI. Posrednik git je edini del paketa, ki ne teče prek doku.php, ampak prek lastne končne točke, s PATH_INFO za imenom datoteke. Prav ti dve lastnosti – lastna končna točka in prenosni strežnik – sta ob zagonu trčili na dveh mestih.
Vtičnik prinaša datoteko web.config. Ta je izključno za IIS in na tem strežniku nima učinka; njene tri zahteve je bilo treba posamič dokazati ali nadomestiti.
Mehanizem
AcceptPathInfo na datoteko namesto za ves strežnik. Prenosni Apache v datoteki server/conf/httpd.conf nastavi AcceptPathInfo off za celoten strežnik. Na vsako zahtevo oblike …/git.php/code/{projekt}/{repozitorij}/info/refs zato odgovori z napako 404, še preden se PHP zažene – posrednik zahteve nikoli ne vidi. Datoteka .htaccess v mapi vtičnika možnost vklopi samo za git.php:
<Files "git.php"> AcceptPathInfo On </Files>
Nastavitev za celoten strežnik ostane nedotaknjena, ker je za preostali wiki pravilna.
Preostali dve zahtevi iz datoteke web.config sta bili že izpolnjeni in sta bili dokazani, ne pa poustvarjeni: modul mod_deflate ni naložen, zato ni stiskanja gzip, ki bi pokvarilo packfile, in LimitRequestBody ni nastavljen. Ker PHP teče kot modul, doseže PHP tudi glava Authorization brez dodatnih nastavitev – pri FastCGI bi bilo za to potrebno svoje pravilo.
Razširitev curl je bila nameščena naknadno. Prenos do Azure DevOpsa in celotna pot REST tečeta prek nje; brez nje se konektor javi kot nedejaven, brskalnik repozitorija se ne naloži, posrednik pa odpove. Prenosni strežnik je ni prinesel. Dodani so bili datoteka ext/php_curl.dll ter izvajalni odvisnosti libssh2.dll in nghttp2.dll iz uradnega paketa php-8.2.13-Win32-vs16-x64.zip; vrstica extension=curl stoji v datoteki server/php/php.ini.
Poti, preverjene po zagonu. Seznam je dokazilo, ne obljuba delovanja:
| Pot | Stanje |
|---|---|
git clone, fetch in push prek posrednika | deluje; nasprotni preizkus neposredno proti Azure DevOpsu potrdi potisnjeno vejo |
| preverjanje pravic po identiteti | prijavljen uporabnik brez skrbniških pravic pri ravni readonly: branje 200, pisanje 403 |
| brskalnik repozitorija z nalaganjem map | deluje |
{{source>ado:…}} neposredno na strani projekta | deluje |
{{source>ado:…}} v predalu, ob izbiri datoteke | deluje |
| urejanje posameznega odseka strani z izrisano vsebino Markdown | deluje; vsako urejanje zadene samo svoj odsek |
Posledice
- Datoteke
.htaccessiz mape vtičnika ne odstranjujte. Videti je odveč, ker poleg nje ležiweb.config; brez nje posrednik na tem strežniku odgovarja z napako 404, napaka pa ni videti kot težava s strežniško nastavitvijo. - Možnosti
AcceptPathInfone vklapljajte za celoten strežnik, da bi dosegli isto. Nastavitev na datoteko je ožja rešitev. - Ob posodobitvi PHP mora curl potovati zraven. Razširitev se mora ujemati z natančno izvedbo strežnika: ista podrazličica, ista varnost niti in isti prevajalnik. Zanesljiv preizkus je primerjava kontrolne vsote datoteke
php8ts.dlliz paketa in tiste na strežniku. - Ob prehodu na FastCGI je treba glavo
Authorizationpreveriti znova; današnja predpostavka velja le za PHP kot modul. max_execution_timeje 30 sekund. Za preverjene velikosti repozitorijev nepomembno, pri zelo velikih naslednja meja.
Sorodne teme
- Tehnična referenca – dejanja in vstopne točke
- Koncepti – priklopi, raven vidnosti in meje
- Kako klonirati priklopljen repozitorij – posrednik git z vidika uporabnika
- Diagnostika: git clone vrne napako 404 – simptom, ki ga ta zapis pojasnjuje