50 éves az FTP!

Internet, Közösségi média

1971. április 16. a dátum a File TransferR Protocol RFC-jén. Boldog születésnapot!

( mauzi v | 2021. 04. 19., h – 12:58 )

Mondjuk, amit manapság használunk FTP-t, annak leginkább az RFC765-höz van köze.

Teljesen sose fog meghalni, mert mindig is kiváló marad helyi hálózaton, biztonságilag nem kritikusan adatokat megosztani. Pl. olyan retró gépek között, amelyeken amúgy csak floppy-val tudnál adatot átvinni, stb.. Olyan értelemben viszont már kb. majdnem 10 éve halott, hogy a modern neten, modern gépek között, kritikus adatok megosztására nem valami ajánlott, és nem is nagyon alkalmazzák már. Szóval kinek mi. Én azt mondom, hogy a régi technológiát se kell „kidobni”, ha használható valamire. Mivel az FTP elég egyszerű protokoll, kicsi az overheadje, könnyű implementálni, ezért nagyon gyenge hardverre hasznos lehet.

Másik részről meg modern összehasonlításban meg még minden hibájával együtt is különb, mint a szutyok MS SMB protokollok és azok verziói, amik épp úgy 0-ák biztonságilag, de legalább bonyásabbak, és szarabbak is.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Én szeretem az FTP-t.
Szerettem azt a világot, amikor minden feladatra megvolt az egyszerű protokoll.
FTP a fájlátvitelre, IRC a chatre, és a többi.
Szomorú látni a mai kort, amikor gyakorlatilag semmire nem használhatod azt, ami arra való, és nem nyithatsz már egy portot a gépeden, mert egyből széthekkelnek a picsába.
Lassan már csak VPN-en szabad otthonra belépni és az alatt csinálni bármit.
Ilyen értelemben sajnos már régen halott az FTP. Persze, használják még valahol LAN-ban, meg firmware-t feltölteni, de nem ezen történik már jellemzően a fájlátvitel.

Ja, ez ilyen lett, mióta boldog-boldogtalan minden telója, táblagépe, gépe, szervere, IoT szutyka a neten lóg, hekkelnek mindent ezerrel, egész botnetek. De ha már FTP, épp aktuális hír, hogy a Firefox v88 is dobja.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

kb 20 eve tartottam egy szamitogep laborban linux tanfolyamot. a gepeknek akkor meg public ip-juk volt, a nat akkoriban meg nem volt divat.

egy gepre frissen telepitett rendszeren (talan slackware volt) magyaraztam eleg sokaig a kernel forditas opcioit, trukkjeit. mire a vegere ertem a mondandomnak, a gepet szethackeltek az ftp bugjan keresztul :)

(akkoriban meg egy default linux telepitesben futott alapbol egy csomo inetd service, telnet, ftp, time stb)

1. Ez azért erősen hálózati probléma is. Az hogy public IP-je van vagy volt egy gépnek, nem jelenti azt, hogy hozzá lehet lehet férni az ip-hez kívülről, vagy bármilyen service-hez. Attól még a routeren/tűzfalon lehet a bejövő forgalmat tiltani, szabályozni.

2. Az FTP helyett bármilyen más tetszőleges szolgáltatás vagy azt megvalósító démon behelyettesíthető a mai napig: Ha olyan bug van, széthekkelik rajta keresztül a gépet.

"Sose a gép a hülye."

Szerettem azt a világot, amikor minden feladatra megvolt az egyszerű protokoll.

Most is megvan, csak egyeseknek profitérdeke bonyolítani. Helyette Google Drive, OneDrive, Dropbox, totál felesleges bloat JS szutyokkal, erőforráspazarlással, telemetriával és egy kilencvenes évek eleji Windows 3.1 fájlkezelői képességeivel.

nem nyithatsz már egy portot a gépeden, mert egyből széthekkelnek a picsába.

Legalább is, vannak, akik ezt próbálják veled elhitetni. Úgy látom, sikeresen. Más kérdés, hogy régen, az informatika cloudbuzi kisiklatása előtt is széthekkelték a picsába azokat, akik orrba-szájba nyitogatták ki a portjaikat. Lehet ezt ésszel is. Meg biztonságos FTP szerverrel.

Ilyen értelemben sajnos már régen halott az FTP.

Nem halott, amíg használják. Ahogy a COBOL sem lesz halott attól, hogy már nem tanítják az egyetemeken.

De igen, ugyanarra valók. Fájlok megosztására, távoli tárhelyen való tárolására, feltöltésére, letöltésére. Webszerver is nyugodtan lehet mögötte és teljes egészében megvalósítja azt, amit a cloudbuzi tárhelyek, töredék annyi erőforrásból és egy nagyságrenddel kisebb komplexitással.

nem ugyanazoknak

Nem ugyanazoknak, egészen addig, amíg a lebutított, tapicskoló felületeken szocializált és azoktól függővé tett egységsugarú felhasználók nem ismernek mást.

Nem, nem ugyanarra. Az FTP egy faek egyszeru protokoll, ami meg egy kenyerpiritorol is hasznalhato, a “cloudbuzi tarhelyek” meg lehetove tesznek pl. olyanokat, hogy masokkal egyszerre szerkesszetek egy dokumentumot. Mindkettonek megvan a letjogosultsaga, de baromira nem ugyanarra jok. 

“cloudbuzi tarhelyek” meg lehetove tesznek pl. olyanokat, hogy masokkal egyszerre szerkesszetek egy dokumentumot

Ez például pont problémás, mert tipikusan nincs zárolás (FTP esetén sincs, de VPN feletti SMB-n megoldott).

Az együttes szerkesztés sokkal inkább alkalmazás, mintsem tárhely funkció.

Felhasználói szempontból tök más a kettő. Az FTP nettó használhatatlan az átlaguserek számára.

" töredék annyi erőforrásból és egy nagyságrenddel kisebb komplexitással."

Más a komplexitás mert más is a megoldandó feladat.

Az ftp meg mondjuk a gdrive úgy viszonyul egymáshoz mint egy szaros bicikli meg egy kamion. Mindkettő el tud vinni dolgokat A-ból B-be, na de mennyit és hogyan. Én magam sem szeretem az ingyenes lakossági cloud megoldásokat, és helyette synology nast használok saját célra, de céges felhasználásra jónak tartom (és egészen másfajta agreementet is irnak alá, ott már lóvé van, nem adathalászat).

Más a komplexitás mert más is a megoldandó feladat.

Az a helyzet, hogy egy "lakossági" fájl megosztása (egyszerű feltölthetősége, linkelhetősége, letölthetősége) messze nem igényel annyi JS-CSS-HTML bloat szutykot, mint, amennyit a Google babzsákfejlesztői belegányoltak a Google Drive-ba. Ezt önmagában a HTTP protokoll is képes megvalósítani, bár tény, hogy nem olyan szépen és nem annyira triviálisan, mint az FTP. Ez viszont még mindig nem indok a bloat-ra.

A Google Drive nem egy kamion, hanem egy olyan szuperbusz, amire felfér 100 utas, de általában csak 5-10 utazik rajta ténylegesen.

Amire te gondolsz, kamionként, az a vállalati cloud, az meg megint egészen más tészta. Nem kevésbé felesleges persze, hiszen egy alkalmazott munkaköri leírásába már nyugodtan bele lehet írni, hogy ne legyen cloudbirka és értsen az FTP-hez.

Azt meg erősen kétlem, hogy egy egységsugarút ne lehetne megtanítani arra, hogy Total Commanderben megnyomja a Ctrl+F-et és felcsatlakozzon az FTP szerverre. Vagy ugyanezt Windows Explorerben, pláne előre létrehozott parancsikonnal. Egyszerűen csak nem kellene tapicskoló birkákat odaengedni a számítógép, okostelefon, tablet stb. elé. Már egy fokkal jobb világot élnénk és nem kéne 2 évente újrafeltalálni mindent, csakmert multiék most épp egy kicsit másik irányba szeretnék terelni a birkákat.

De igen, ugyanarra valók.

Miota van FTP-n file history?

Miota tudok konnyeden megosztani fajlokat/konyvtarakat masokkal (pl. link only sharing) FTP-n? Igen, ugy, hogy ne kelljen se masolgatni/symlinkelni, se user/pass-t megadni.

Csak a ket leggyakoribb use-case, ami nagyon jol jon nekem es Nextcloud-ban semmit nem kell erte tennem, mig FTP eseten ez nem lenne ilyen egyszeru.

Igen, bár azt az udp miatt kevésbé tartom szerencsésnek.

Pedig semmi baj sincs vele, a TFTP megoldja magasabb szinten azt, amit az UDP-ből hiányolsz.

 

Persze megoldható

Meg is oldották. Nem véletlenül használja kb. "mindenki" a firmware-ek frissítésére a routerekhez, switchekhez és egyebekhez.

A TFTP esetén általában két eszköz "közel" van egymáshoz, mondjuk egy darab patch kábellel összekötve, szóval se routing se távolság se semmi nincs, igy gondolom ritkán kell a sorrendet és a hiányzó csomagokat helyre tenni.

(és nem ismerem fejből a tftp -t, de lehet hogy kezeli ő is ezeket, ahogy a kollega irja)

"A TFTP egyszerű PAR (Positiv Acknowledgment Retransmission) sémát használ a hibajavításra. A TFTP definiál egy nyugtázó üzenetet, amellyel visszaigazolást kap a megérkezett adatról. Amennyiben egy meghatározott időn belül nem érkezik meg a nyugta, újra küldi az adatot."

https://www.tilb.sze.hu/tilb/targyak/ta13/protocol_2006_01_14-A5.pdf

"Ezer" éve használom a TFTP-t, soha nem volt vele baj. Jól ki van az találva, mégis egyszerű, gyenge hardveren is megy.

egy laptop meg egy router egy db cross kábellel van összekötve

Régen kellett keresztkábel, de jó ideje olyanok már a hálózati portok, hogy ma ez gyakorlatilag felesleges (20 éves vagy régebbi laptop esetén még talán lehet érdekes).

 

Én ezt az esetet irtam le, nem azt, amikor normál hálózaton keresztül csinálod.

Nekem nagy szerencsém lehet, mert olyan hálózaton is ment már rengetegszer hibátlanul a PXE boot, ahol van kb. 50..60 hálózati eszköz. Egy rakás gépre így ment fel az oprendszer és a rajta lévő alkalmazások.

elmeletileg ethernet eseten a csomagok sorrendje nem valtozhat meg, semmikepp. ezert is van ip/port hasheles lacp/portchannel eseten.

csomagvesztes persze elofordulhat (bar belso halon az se illene), de az mas tema, es a tftp le is kezeli ezt.

elmeletileg ethernet eseten a csomagok sorrendje nem valtozhat meg, semmikepp.

Az ethernet Layer 2, az UDP, amit a TFTP használ, Layer 3, a TFTP meg Layer 4 és fölötte.

TCP csomagok is mehetnek etherneten (igazából a TCP gyakoribb is az UDP-nél), ott meg aztán tényleg bármi lehet a sorrend a túloldalon, a TCP protokoll feladata a rendezés.

Helyesbítek, az UDP Layer4, a TFTP pedig Layer 5 és fölötte (de mindegy)

https://fiberbit.com.tw/wp-content/uploads/2013/12/TCP-IP-model-vs-OSI-…

 

es tudom hogy a TCP tudja rendezni a csomagokat, de ettol meg az Ethernet halozaton nem valtozhat a csomagok sorrendje.

De nem is állította senki, hogy etherneten mi van, mivel nem is függ össze azzal, amihez odakeverted.

Bocs, de a rektes szart.

Tegyük fel hogy a synology drive nevű cucc amit használok olyan mint a google drive (amúgy olyan is, csak nincs olyan szép URL-em hozzá és onprem üzemel).

Ott tudok küldeni egy linket amire kattintva egy browserben megnyilik egy galéria ami izlésesen tálalja az előző napi születésnapi partit.

Az ftp-nél meg lehet szenvedni, hogy ki-ki összekattogtassa magának a total commandert meg a filezillát meg a fene tudja még ki mit használ programot.

Ugye nem várod el anyukántól, vagy a 60+ -os apukámtól, hogy ftp klienst kattogtasson össze és letöltögesse a képeket?

Lásd meg az értéket is benne, ne csak a szokásos dolgaidat puffogtasd.

Arról nem is beszélve hogy az ftp esetén ki a franc fog többmilliárd embernek ftp szervereket összeütni / üzemeltetni? Mindenki maga otthon? Ne legyünk már nevetségesek.

Az FTP egy szép és egyszerű (viszont rohadt elavult és nagyon pazarlóan működő) megoldás egyszerű fájlcserére két hoszt között, dedikált feladatra, vagy szakértőknek, átlagember a mai világban bottal sem piszkálná meg, és nem azért, mert lusta, hanem ugyanazért, hogy te is modern buszra és nem lóvasútra szállsz fel.

Ha már próbálsz tapasztalt szakembernek tűnni akkor nézz utána az ftp protokollnak, ezerrel nyitogatja a kapcsolatokat minden egyes fájlra amit forgalmazol, ennél nagyobb pazarlást (visszanyalt a fagyi?) nehéz elképzelni.

Az ftp-nél meg lehet szenvedni, hogy ki-ki összekattogtassa magának a total commandert meg a filezillát meg a fene tudja még ki mit használ programot.

Vagy nem, mert már össze van "kattintgatva", mert nem egységsugarú, tapicskoló birkák nézik meg a 2 évente Media Marktban újravásárolt Lenovo Yogájukról.

Ugye nem várod el anyukántól, vagy a 60+ -os apukámtól, hogy ftp klienst kattogtasson össze és letöltögesse a képeket?

Ők ugyanúgy tudnának egy teljesen minimalista HTTP felületet használni, ami indexeli és megjeleníti a képeket adott FTP-ről írható mappában, ha esetleg nincs összekattintgatva a Total Commander. Sem anyád, sem 60+ apád nem indokolja a rengeteg babzsákfejlesztői JS-bloat szutykot, amit a Google beletesz. Pláne nem materialbuzi, animációbuzi, adatgyűjtögető, telemetriázó, fiókregisztrációval zsaroló módon.

Lásd meg az értéket is benne, ne csak a szokásos dolgaidat puffogtasd.

Az érték kb. 10%-át képezi. A maradék 90% a bloat és a többi etikátlan húzásuk. Lásd meg, hogy nem a 10%-ra puffogok.

Az FTP egy szép és egyszerű (viszont rohadt elavult és nagyon pazarlóan működő)

Mind sávszélességben, mind memóriában, mind CPU-ban kevesebbet fogyaszt FTP-n feltölteni, majd letölteni a megosztani kívánt fájlokat. Pláne az általad is vázolt, egységsugarú esetekben.

Ha már próbálsz tapasztalt szakembernek tűnni akkor nézz utána az ftp protokollnak, ezerrel nyitogatja a kapcsolatokat minden egyes fájlra amit forgalmazol, ennél nagyobb pazarlást (visszanyalt a fagyi?) nehéz elképzelni.

Majd nézzél szét egyszer az F12 ablakban mi történik, ha egyetlenegy fájlt megosztó Google Drive linkre rákattintasz, akkor hány HTTP csatorna nyílik és azon hány request megy végbe. Spoiler: 6 csatorna nyílik, mert ennyi a max. limit, aminél a böngésző nem enged többet és 50 request-reply minimum lemegy. Közben 6 MB töltődik le a semmire (JS-HTML-CSS bloat szutyok) és 1,5 MB töltődik fel. Ezt akarod szembeállítani azzal, hogy fájlonként nyílik +1 minimális (néhány száz bájtos) overheaddel TCP csatorna, ami a fájl feltöltésével le is záródik, míg a Google Drive JS szutykai végig nyitvatartják a 6 csatornát, mindenféle user szempontjából irreleváns szarságokra (pl. telemetria). Szóval, bármennyire is nehéz elképzelni, a Google Drive sokkal pazarlóbb az FTP-nél, és akkor nem beszéltünk még a CPU-bloatról, a memória-bloat-ról, amit okoz a babzsákfejlesztői kényelmeskedés.

( x-daemon | 2021. 04. 19., h – 14:51 )

mikor az ftp.fsn.hu-n mc-vel keresek a debian csomagok kozott ennel jobb nincs.

persze azt is megertem ha bongeszobol kiveszik, ott ugyanolyan nehezkes mint http-n keresztul a fajl lista

neked aztan fura humorod van...

( Gyuszk v | 2021. 04. 19., h – 16:06 )

Amikor utoljára "komolyan" ftp-ztem az az egyetemi koleszban volt. Long story short, a letöltési aránynak felül kellett múlnia a feltöltési arányt minden nap, ezzel védekezett a kollégium a warezgyanúsitásokkal szemben.

Szóval a gépemen volt egy cronjob ami egy meg nem nevezett publikus ftp-ről jó nagy fájlokat letöltögetett minden nap a devnullba, azért hogy ne kapjak warn -t a rendszergazdától. :)

( bognarattila | 2021. 04. 19., h – 16:30 )

Alapvetően kipusztulhatna végre, de amíg az IIS nem integrálja kellő mértékben az sftp-t (vagy kínál hasonlót), addig van létjogosultsága.

Mármint az FTP helyett? SFTP. Az anonymous FTP kivételével mindent (jobban) tud, arra meg amúgy is a HTTP(S) való.

Az IIS helyett meg Apache, vagy NGINX, vagy Haproxy, vagy Caddy, vagy #valahánynévanaptárba... (meg ne kérdezd, hogy ezek közül mi fut Windowson, mert nem érdekel; van WSL, tessék rendes szoftvereket futtatni, ha már Windowssal vert meg valakit a sors)

( zrubi v | 2021. 04. 19., h – 18:58 )

...és a kameráim továbbra is FTP-vel tolják a képeket a NAS-ra.

Köszönjük, jól működik, probléma nincs vele. :)

Nem, még security probléma sincs - ha a megfelelő eszközt a megfelelő helyen használják.

zrubi.hu

( uid_16313 | 2021. 04. 21., sze – 08:50 )

FTP egy letűnt korszak megoldása, amikor az emberiség még nem egymás basztatásával foglalkozott, ld. security

Nem basztatja senki, csak megállapították, hogy kikopott. Álságos azt mondani, hogy ugyanúgy használjuk, mint huszonöt éve.
Rétegterületeken használják még. Pl. LAN-ban továbbítanak rajta adatot: printer spool vagy kamerakép főleg. Ez azért messze nem ugyanaz, mint fénykorában volt.

Nekem személy szerint semmi bajom az FTP-vel. Pont azon siránkoztam az egyik posztban, hogy milyen kár, hogy ilyen lett a világ.
Ettől függetlenül nem célszerű már a családdal, cimborákkal FTP-n osztani adatot (akkor se, ha public), mert az egységsugarú júzernek egyre inkább macera a használata. Böngészők dobják a supportot, máshoz meg nem ért.

Nem basztatja senki, csak megállapították, hogy kikopott.

Ennél azért kicsit durvább hangvétellel próbálják meg influenszelni a nagyérdeműt abba az irányba, hogy az FTP halott™. Mintha valakiket nagyon zavarna a használata.

nem célszerű már a családdal, cimborákkal FTP-n osztani adatot (akkor se, ha public), mert az egységsugarú júzernek egyre inkább macera a használata

Nem világos, mikor volt utoljára nem macera böngészővel FTP-zni. Szerintem mindig az volt. Mikor lehetett például normálisan feltölteni, file manager-kedni böngészőből (extension nélkül)? Soha. Hozzáértő cimborákkal igenis érdemes FTP-n osztani tartalmat, mert a hozzáértő cimbora Total Commanderből vagy FileZillából fog bejelentkezni. Nem hozzáértőknek meg érdemes HTTP tárhelyet biztosítani, közvetlen linkkel, rákattintani csak rá tud.

Nosztalgiával gondolok az FTP-re, mégsem gondolom, hogy bármilyen érv szólna mellette, hogy fusson FTP szerverem.
Alkalmi fájlcserét megoldunk a webszerveremen, 7z-be téve a cuccot.
Saját eszközök között mozgatok adatot FTP-n. Már amik nem tudnak NFS-t. Mert LAN-ban azért egy NFS sokkal királyabb.

próbálják meg influenszelni a nagyérdeműt abba az irányba

Nem kell itt influenszelni senkit semmilyen irányba. Az FTP klasszikus használatának leáldozott. Vége. Gyakorlatilag nincs célközönség. Pár geek használja még. Talán az egyetlen élő use case a koli ftp. Ha van még ilyen.

FTP még az, ahol nem tudták megvalósítani az 1 szolgáltatás = 1 port elvét. Műszakilag ez egy nagy hátránya.
A másik, hogy együtt él az FTP és ritkán az opcionális TLS-FTP. Elég gyakran közös porton és az ósdi klens biztos a simát próbálja rá először.
Persze amikor kitalálták, akkor másak voltak a körülmények, akkor teljesen jót alkottak. Mára inkább csak velünk maradt és nem akar kihalni.

Szerencsés lenne egy új SecureFTP kitalálása, amely hasonló váltás lenne, mint a telnet --> SSH váltás 1996 környékén.
Azaz ez esetben:
   - egyetlen TCP porton megvalósított parancs és adat továbbítás
   - alapból kulcs csere utáni titkosított csatornán működne, kulcs csere nélkül kizárólag user-pass nélküli letöltés mód lehetséges.
   - és ha még szigorítható lenne kölcsönös kulcs alapú auth-ra is, ugranánk ki a bőrünkből.
A parancsai (list, retr, stor, restart, ...) teljesen jók. Talán még egy chksum parancs jó lenne, amely letöltés nélkül validálná a két oldalon levő fájl azonosságát.

Azt viszont káros folyamatnak érzem, hogy szinte mindent HTTPs fölé akarunk gyógyítani. Pedig olyan szép és hasznos a natív TCP és UDP, sőt az SCTP is egy harmadik izgalmas lenne.

Elég gyakran közös porton és az ósdi klens biztos a simát próbálja rá először.

Amivel mi a probléma? Az, hogy az ósdi™ kliens is tud működni vele, ahelyett, hogy frissíttetné az OS-t, meg kidobatná az eszközt a felhasználóval?

Szerencsés lenne egy új SecureFTP kitalálása, amely hasonló váltás lenne, mint a telnet --> SSH váltás 1996 környékén.

Totál felesleges még egy újrafeltalált kerék. Meglévő szervereket és klienseket be lehet úgy állítani, hogy preferálják a biztonságos kapcsolatkiépítést, hitelesítést. Cserébe, ha valakinek csak régije van, azzal is működik.

Azt viszont káros folyamatnak érzem, hogy szinte mindent HTTPs fölé akarunk gyógyítani.

Pláne, hogy lassan már a HTTPS-be ágyazott adatfolyam is még kap extra titkosítást, DRM-et stb. Bloat a bloat hátán. Nem beszélve arról, hogy a titkosítás az esetek többségében totál felesleges.

Szerencsés lenne egy új SecureFTP kitalálása, amely hasonló váltás lenne, mint a telnet --> SSH váltás 1996 környékén.
Azaz ez esetben:
   - egyetlen TCP porton megvalósított parancs és adat továbbítás
   - alapból kulcs csere utáni titkosított csatornán működne, kulcs csere nélkül kizárólag user-pass nélküli letöltés mód lehetséges.
   - és ha még szigorítható lenne kölcsönös kulcs alapú auth-ra is, ugranánk ki a bőrünkből.
A parancsai (list, retr, stor, restart, ...) teljesen jók. Talán még egy chksum parancs jó lenne, amely letöltés nélkül validálná a két oldalon levő fájl azonosságát.

Hát, az SFTP pont ezt tudja. Egy csatornába van multiplexelve minden; nem kell szopkodni a random portokkal, nem kell MITM-jelleggel NAT-olni, ami nyilván lehetetlen egy valóban secure, titkos forgalom esetén; tud lenni kulcsos auth, tud lenni password auth, tud lenni challenge/response auth, ráadásul az amúgy is elterjedt SSH kulcsokat tudja használni, tehát nem kell másik kulcsot generálni, ha terminal accesst is szeretnénk.

Így van. Magamnak jó lenne. De magamnak ugye ott az scp.
A család, ismerősök meg kényelmesebben elvannak a weben. PHP amúgy is van, a családi nyomkövetők felülete miatt.
Amíg egy snakeos-es kis ketyere volt a ,,NAS", 32 MB RAM-mal, addig pont úgy csináltam, ahogy mondod: pure ftp.
Viszont mivel a munkahelyi tűzfalon tiltva van, kénytelen voltam oda is csinálni webes feltöltőt, cgi-ben (torrent fájlokat kellett neki betenni a watch dir-be). És oda leszedni is csak http-n tudtam sajnos.

Egyébként én visszasírom ezt a világot, amikor egy 32 MB RAM-mal ellátott két gyufásdoboznyi ketyere egy ráakasztott 100 GB-os diszkkel elég volt erre a feladatra. Megvolt hozzá az SDK is, tudta hekkelni az ember (transmission-t ki, rtorrent-et be pl.). Sok-sok évig használtuk örömmel.

Igen, az igazán remek, mikor kéri a fejlesztő hogy 2GB legyen a post_max_size meg 10000 az input_vars meg miabánat, meg 4GB a memory_limit egyetlen szaros vhost-nak, mert olyan formot csinál, hogy az neki kell.

Aztán csodálkoznak, hogy másik URL-en meg lehal a site ddos vagy egy normál de komolyabb terhelés miatt.

Fasz kivan már, hogy mindent az istenverte http-be/fölé akarnak tenni.

"Sose a gép a hülye."

A kereső szerint vannak javascriptes ftp/sftp/ssh könyvtárak, elvileg mehetne böngészőből, php nélkül, nagymamás  html felülettel, ami csak a kívánt akciót teszi lehetővé. Bár nem adnék rá sokat hogy a chrome (majd a ff) nem vezetik ki hamarosan, ha még nem tették.

Mondja már meg valaki, miért az FTP-t baszlatják folyton?

Mert sokkal kevesebb erőforrásból, hatékonyabban, egyszerűbben, átláthatóbban megoldja azt, amit cloudmultiék a bloated, telemetriás, reklámokkal telebaszott, webes szutykaikkal nem képesek. Ezért az Amerikában oly népszerű cancel culture megy ellene az IT-divatblogokon a menő techie influenszerek és a tech-lakájmédia firkászai által.

volt azert olyan kevesbe ismert feature is az ftp-ben, hogy lehetett 2 szerver kozott is adatot mozgatni, ahol a kliens 1-1 control kapcsolatot epitett ki a 2 szerver fele, a data kapcsolt meg a 2 szerver kozott ment kozvetlenul. modemrol iranyitva eleg hasznos volt ha tavoli szerverek kozott kellett sok adatot mozgatni.