Új hozzászólás Aktív témák

• #1529 Mr Dini addikt MaCS_70 #1525

  Új Válasz 2018-03-19 17:24:23 #1529

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Mr Dini

  addikt

  LOGOUT blog

  válasz MaCS_70 #1525 üzenetére

  Nos, illene picit jobban kifejtenem minden egyes parancsot, amelyet adok Neked útmutatásul, hiszen ez több lelkes próbálkozónak is hasznára válhat. Sajnálom, hogy ennyit kell szívni az egésszel, de bizony az utóbbi időben változtak a repository-k... Nekem pedig tényleg illene kifejtenem részletesen mindent, de sajnos alig van időm jelenleg a fórumra...

  Nos, az első, uwsiteloaderes problémát azért kaptad, mivel Uli, a szkript fejlesztője nemrég átállt HTTPS titkosítására az oldalán. Ehhez ugye kell egy megbízható tanúsítványkibocsátó által szolgáltatott SSL kulcs. Mivel a Let's Encrypt az egyetlen ingyenes alternatíva tudtommal jelenleg, természetesen Ő is azt választotta. Viszont a szkriptben található egy wget parancs, amely letöltené a listát. Ez viszont ténylegesen egy relatív wget parancsként van meghívva, azaz nincs egy konkrét elérési úton lévő wgetre hivatkozásunk, hanem a rendszerre bízzuk, hogy melyiket választja. A rendszer pedig aszerint fog dönteni, hogy egy rendszerszintű (környezeti) változóban, a PATH-ban milyen könyvtárak vannak felsorolva. Szépen végigkeresi az összes megadott mappában a wgetet sorban, s az első találatot (amely futtatható joggal rendelkezik) meghívja. Korábban nem volt ezzel szívás, mivel az FFp szépen ezt a PATH-t tudta módosítani. Most viszont ugyan hozzáadódnak az ffp-s mappák a PATH-hoz, nem az elejére kerülnek ezek az elérési utak, hanem a gyári rendszer elérési utai után. Ezért van az, hogy a gyári OS wget binárisát akarja használni a szkript is. Ami picit le van butítva (hogy kisebb legyen a mérete), illetve régi is, ezért nem ismeri a Let's Encrypt kulcsot. Pontosan ezért dobja a no connection hibát, mivel ténylegesen a 'buta' wget nem tudja letölteni a repository listát Uli szerveréről.

  A PATH változó tartalmát egyébként így lehet megtekinteni:

  echo $PATH

  És a fentebb írt módon lehet, a pathfix szkriptemmel rendbe rakni FFp alatt a sorrendet.

  De alternatív megoldásként ügyesen alkalmaztad az uwsiteloaderben való direkt cserét, hogy mindenképp a frissebb, FFp-s wget legyen használva. Valóban, ehhez az abszolút útvonallal kell rá hivatkozni, ami a /ffp/bin/wget.

  A másik hiba forrása pedig az, hogy Fonz, aki az egész original FFp-t megalkotta eredetileg D-Link NAS-okra, készített egy repót anno pár hasznos csomaggal. Ezt rsync protokollon keresztül frissítené a slacker, viszont Fonz rsync szervere valami ismeretlen ok miatt egyszer csak meghalt, azóta elérhetetlen... Neki pedig nem lehet már szólni, ugyanis 2013-ban, kicsivel az FFp 0.7 kiadása után nyomtalanul eltűnt. A fórumon kívül pedig semmi kapcsolattartási pontot nem hagyott maga után... Így esélytelen Neki szólni, pláne, hogy azóta nem is nagyon frissített a csomagjain... Alternatív megoldás, hogy a /ffp/etc/funpkg/sites fájlban fonz (ffp.inreto.de) rsync címét http-re cseréljük, mivel az még működik szépen. Vagy ki is lehet szedni az uwsiteloader segítségével a repository listából, de azért vannak ott hasznos csomagok. Amit írtam sed parancs, az elméletileg pont ezt a cserét hajtaná végre. De természetesen kézzel is módosítható a fájl (mondjuk mc alól).

  Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

Új hozzászólás Aktív témák