A Debian projekt leállítja publikus FTP szolgáltatásait

Debian

A Kernel.org bejelentése után a Debian projekt is bejelentette, hogy fokozatosan kivezeti publikus FTP szolgáltatásait. A debian.org összes felhasználók számára elérhető FTP szolgáltatása 2017. november elsejével megszűnik. Az okok:

  • az FTP szerverek nem nyújtanak gyorsítótárazás (caching) és gyorsítás (acceleration) funkciókat
  • a legtöbb szoftverimplementáció fejlesztése megrekedt, kényelmetlen a használata és a konfigurálása
  • az FTP szervereik kihasználtsága nagyon alacsony, mivel a Debian telepítők 10 éve nem támogatják a tükörszerverek FTP-n keresztüli elérését
  • a protokoll nem hatékony, a tűzfalakon és terheléselosztókon kényelmetlen tákolgatásokat kell végezi miatta

Részletek a bejelentésben.

( hajbazer v | 2017. 04. 26., sze – 20:11 )

Régen láttam ennyi közhelyet egy rakáson, azt viszont kifejezetten sajnálom, hogy pont a Debian süllyed erre a szintre.

az FTP szerverek nem nyújtanak gyorsítótárazás (caching) és gyorsítás (acceleration) funkciókat

Előre látom már, amikor "biztonságra" való hivatkozással HTTPS-esítik a mirrorokat, mert leesne a gyűrű az ujjáról a sysopnak akinek md5 sumot kell csekkolnia az ISO-ra. Ekkor pedig ugyanúgy nem lesz caching. Persze ott már nem fog számítani, mert a "biztonság" illúzója előbbre való, mint pl. a gyorsítótárazásból fakadó hatékonyság. Ha pedig Debianékat tényleg ennyire érdeklik olyan hangzatos klisék, mint a caching, meg az acceleration, lehet kezdeni az apt-get optimalizálásával, hogy a csomaglistákat ne egy szöveges fájlból nyalja fel minden futtatáskor, elpazarolva rengeteg időt és CPU-t.

a legtöbb szoftverimplementáció fejlesztése megrekedt, kényelmetlen a használata és a konfigurálása

A Total Commander-nek teljesen jó FTP implementációja van, emellett létezik az lftp nevű program Linuxra, ami messze veri az összes FTP klienst. Ettől függetlenül, ez nem igazi érv, mert alakíthattak volna egy fejlesztőcsapatot, akik továbbfejlesztik ezeket az implementációkat, Debian-ban helyt kapó csomagokat peccselve.

a protokoll nem hatékony, a tűzfalakon és terheléselosztókon kényelmetlen tákolgatásokat kell végezi miatta

Ahogy a HTTPS sem olyan hatékony ebből a szempontból, mint az FTP. Mégis inkább lenyomják a torkunkon.

Ám amellett, hogy egyértelmű, hogy fejlődésmániás idealizmusról van szó itt is, ezt én most az egyszer támogatom.

Sose értettem, miért kell FTP-n mirrorozni az ISO-kat, amikor a megszakadt letöltést a HTTP is tudja folytatni. Feltölteni meg nyilván nem fog senki, tehát végsősoron bloat volt. Az pedig még jobb koncepció, hogy inkább torrenten keresztül terjesszük az ISO-kat, sőt, torrent alapú csomagmirrorok is lehetnének. Minden .deb csomaghoz tartozhatna egy torrent. Így nem az ósdi centralizált logikát követnénk, ami az internet kiinduló alapelvének is ellentmond, meg ami köré most megpróbálunk maszlagot húzni, hogy újnak tűnjön (cloud).

Ha már úgyis ott a megosztandó cucc a szervereken, nem elfér egy ftpd a httpd mellett? A torrent meg sajna nem fér bele sok (legtöbb?) céges policy-be (fixme). SOHO Linux userek meg összesen nincsenek annyian hogy érdemes lenne egy torrent alapú package management rendszert kifejleszteni (imho).
____________________
echo crash > /dev/kmem

http-t konnyen lehet load balancerek mogul kiszolgalni, ftp-nel mar macerasabb hogy kulon porton van control es data na meg ha passziv portokrol beszelunk, nem csak annyi ez hogy pl apache mellett fusson egy proftpd is a gepeken. Ha meg ugyis alig hasznaljak es egyeb nehezsegeket is okoz akkor minek megtartani es szenvedni azzal is uzemeltetoi oldalrol?

remek oktatási célokra

Kiválóan lehet vele prezentálni, hogy milyen az, amikor egy alapvetően biztonságosnak tekinthető helyekre ('70-es évek hálózatai) tervezett protokoll nem pusztul ki, amikorra nem lesz annyira biztonságosnak tekinthető ugyanaz a hely...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ja, csak az a baj, hogy az apt(-get) már így is sokkal kevésbé bloat, mint az XP frissítéskezelője, ami akár órákig vagy napokig beragadva nem találja meg a frissítéseket (még akkor sem, ha vannak), meg tekeri a procit 100%-ra. Nyilván XP-nél ez már nem nagyon tényező, de egy támogatott OS-nél fontos.

Az FTP-vel meg nem az a baj, hogy bloat, hanem hogy elég fejletlen, megbízhatatlan, elavult protokol, mindenki olyan nagyvonalúan implementálta és konfigurálta, ahogy jól esett, emellett tényleg nuku cache-elés és load balancing. Tükröknél meg a https-re nincs szükség, mert man-in-the-middle támadással nem manipulálhatóak érdemben, hiszen a csomagkezelő (nem csak az apt-get, de a pacman, yum, stb.) GPG-aláírást is vizsgál publikus kulcs alapján, úgy meg azonnal kiderül, ha utólag illetéktelen gányolt bele a csomagba.

Semmi ilyen gondom nem volt az XP-s frissítésekkel.

Mellesleg, az apt-get bloat-ságát nem mentesíti az XP Raynes-nél való nemműködése. Pláne, hogy az XP "csomagkezelése" igencsak távol áll a Debianétól. Hasonlítsuk inkább össze egy pacmannel, vagy egy yummal. Mindkettő kenterbe veri az apt-get-et sebességben, pedig a yum-ban ráadásul még ott van a python bloat is.

Akkor te vagy a kiválasztott. Pár xp-s géppel találkoztam ami szépen elhasalt frissítéseknél. De igazad van éljen az xp, a driver vadászat, a sok-sok reboot, meg persze a kékhalál.
Nekem nem hiányzik és szerintem nem vagyok egyedül.

----
FreeBSD, Solaris, Debian, LMDE