- bsh blogja
- A hozzászóláshoz be kell jelentkezni
- 836 megtekintés
Hozzászólások
"priority changed from critical to normal "
Ugye nem adtad föl ezt a hibát critical-ként?
KisKresz
- A hozzászóláshoz be kell jelentkezni
azt a rész én sem értem, mert alapból normal volt a priority, még néztem is a legördülő menüben, hogy milyen lehetőségek vannak, és így hagytam is normalon. hogy mitől lett critical, azt nem tudom.
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
Fura! Erről is kéne bugreport! :-)))
KisKresz
- A hozzászóláshoz be kell jelentkezni
A moccsakok, hogy kibabraltak veled ... :-)
SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta
- A hozzászóláshoz be kell jelentkezni
velem ugyan nem... hálistennek nem csak filezilla létezik, úgyhogy ha ilyen a hozzáállásuk, akkor sajnos én nem fogom ezt használni.
mindenesetre az utolsó idézet az nagyon nevetséges...
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
Nekem inkább ez csípi a szemem:
"an SSL shutdown is not needed and in fact would only waste bandwidth."
KisKresz
- A hozzászóláshoz be kell jelentkezni
igen, azt írtam is neki... erre idézte be azt az rfc definíciót, ami azt jelenti, hogy a protokoll fel van készítve _unexpected_ megszakadásokra és ilyenkor automatikusan lezárja a sessiont. de hogy a csávó miért gondolja, hogy teljesen rendben van ezt használnia a normális szétkapcsolódás esetén, ami ugye nem éppen unexpected close... áh, balf*k :D
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
Ha jól értem, akkor a problémád az, hogy a vsftpd log-ja olyan sorokat is tartalmaz, amiket nem szeretnél látni. Értelemszerűen a vsftpd-t kéne módosítani, nem a filezilla-t.
- A hozzászóláshoz be kell jelentkezni
hehe...
azért tartalmaz a vsftpd ilyen sorokat, mivel a filezilla nem szabályosan zárja le az ssl kapcsolatot (amit a fejlesztő(?) el is ismer, csak szerinte ez így teljesen rendben van...). biztos, hogy a vsftpd-t kéne módosítni tehát? nem a filezillát megcsinálni rendesen?
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
> biztos, hogy a vsftpd-t kéne módosítni tehát? nem a filezillát megcsinálni rendesen?
Igen, biztos. Téged a vsftpd viselkedése zavar, nem a filezilla-é. (Ha nem jelenne meg az a debug sor, akkor nem foglalkoznál a szép lezárással.)
Jelenleg csak a filezilla-ról tudod, hogy felesleges debug üzenetet vált ki a vsftpd-ben, de mi lesz ha feltűnik egy újabb "optimalizált" kliens? Annál is bejelented hibának, hogy a vsftpd debug üzenetet ír?
Egyébként tényleg általánosan elfogadott jelenség, hogy a session-t nem zárják le szépen, ha kliens oldalon nem muszáj. (Azért se szokott senki sem szólni, ha nem shutdown+close -al zárják le a tcp session-t, pedig ilyenkor a szervert terheli a TIMEWAIT.)
A jó megoldás szerintem az lenne, ha lenne a vsftd-ben olyan debug-level beállítási lehetőség, aminél mindent kiír ami téged érdekel, és nem ír ki semmi olyasmit, ami téged nem érdekel. Ez minden jelen és jövőbeli klienssel egyaránt jól működne.
- A hozzászóláshoz be kell jelentkezni
"Téged a vsftpd viselkedése zavar, nem a filezilla-é. (Ha nem jelenne meg az a debug sor, akkor nem foglalkoznál a szép lezárással.)"
nem, nem a vsftpd zavar, mert a vsftpd jelen esetben jól működik, csakúgy mint más ftp kliensek is (amiket eddig próbáltam). sőt, engem a filezilla sem zavarna, én csak egyszerűen bejelentettem egy bugot, hogy javítsák ki a közösség érdekében, és most kezdett el zavarni, ahogy ezt lereagálták. de elmhetnek a sunyiba, majd használok mást helyette, ennyi. zavar az ilyen hozzáállás.
"Jelenleg csak a filezilla-ról tudod, hogy felesleges debug üzenetet vált ki a vsftpd-ben, de mi lesz ha feltűnik egy újabb "optimalizált" kliens? Annál is bejelented hibának, hogy a vsftpd debug üzenetet ír?"
be ám, mint a vihar! é nmár csak ilyen vagyok... szerintem arra valók a bug trackerek, hogy bejelentsék a hibákat és azokat javítsák is ki, és tegyék jobbá a programokat, mindenki nagy örömére. én eddig minden bugot, amibe belefutottam és úgy ítéltem meg, hogy az tényleg bug és nem pebkac, azt be is jelentettem.
a debug üzenetek meg nem hiszem, hogy feleslegesek. például most ez kiderült, de kiderülhet legközelebb valami más is akár, amit esetleg helyben meg tudok oldani. én biztos, hogy nem kapcsolom ki az ilyesmit. inkább addig csiszolgatom, utánajárok, megoldom, amíg minden úgy megy, mint a karikacsapás és nincsenek debug események.
"Egyébként tényleg általánosan elfogadott jelenség, hogy a session-t nem zárják le szépen, ha kliens oldalon nem muszáj. (Azért se szokott senki sem szólni, ha nem shutdown+close -al zárják le a tcp session-t, pedig ilyenkor a szervert terheli a TIMEWAIT.)"
nem értek hozzá, de gondolom ez az ftp-es ez valamiféle szabványos protokoll, lásd a fickó által idézett RFC akármit. nem néztem utána, de ha ilyenekre is kitér, hogy váratlan kapcsolatszakadásnál le kell zárni a sessiont, akkor el tudom képzelni, hogy a teljes session felépítése és lebontásának menete is szabványosított és jól definiált. én csak annyit szeretnék, hogy akkor ha már rfc akármikre hivatkozik valaki, akkor annak a többi részét is tessék betartani.
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
Gyanitom egyebkent, hogy valaki valahol nem hiv meg 1 fuggvenyt, es azert van ez az egesz ceco. En siman ujranyitnam a ticketet.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
> En siman ujranyitnam a ticketet.
Én meg előbb elgondolkodnék, hogyan is kéne implementálni ezt az udvarias búcsúzkodást. Tegyük fel, hogy a felhasználó rábök az "ablak bezárása" gombra. Az elvárt viselkedés az, hogy az ablak eltűnik, amilyen gyorsan csak tud. Ha viszont búcsúzkodni kell, akkor előbb szépen le kéne zárni az ssl, majd a tcp session-t. Ez néhány adat csomag küldésével, és megvárásával jár együtt. A kötelezően kivárandó timeout-okat figyelembe véve, az ablak bezárása jelentős késedelmet szenvedhet.
Vagy mi történjen hibernáláskor? El kéne kapni a hibernálás eseményt, és (hosszas) búcsúzkodásba kéne kezdeni?
- A hozzászóláshoz be kell jelentkezni
esetleg lehetne egy olyan megoldás is, hogy a filezillában az opciók közt lehetne választani, hogy ezt a nemtúlszép disconnectet használja a program, vagy a szabványosat, és akkor az user azt használ, amit akar. felőlem akár lehetne default az eddigi megoldás is. és nem hiszem, hogy ezt olyan nagyon bonyolult lenne implementálni. csak éppen hiányzik a szándék. ticket rejected, closed, probléma "megoldva".... nem ez a módja.
----------------------------------
feel the beat - it's everywhere!
- A hozzászóláshoz be kell jelentkezni
Nyilvan a hibernalas belefer az unexpected close kategoriajaba (nem az alkalmazas valtotta ki a kapcsolat lezarasanak kenyszeret), ugyanakkor peldaul az ablak bezarasara igenis le lehet zarni a session-t rendesen - az ablak eltunik, es utana le lehet zarni a kapcsolatot. Nem felorakrol beszelgetunk, amig lezarul egy ssl session az a legrosszabb esetben is 2-3 sec.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
en egyszer egy ffmpeg entryt ketszer nyitottam ujra, aztan megfenyegettek, hogy kitorlik a useremet :)
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
hát a kezed nem törhetik el. :)
- A hozzászóláshoz be kell jelentkezni