Hozzászólások
-
Bejegyzés
-
Természetesen mc-vel nézegetem a fájlokat, de hát ugyanez a nézegető a greppelt fájlt végig mutatta, tehát tudok jobbra görgetni. … 🙂
Ezek szerint oprendszer specifikus a problémám?És igen! Ubuntu alatt tényleg végig megy.
De logikailag akkor sem értem! A grep hogyan befolyásolhatja a ps kimenetét? Ráadásul töblettel?
Egyébként az operndszer akkor RH9, tehát csak ott rdemes próbálgatni. 🙁
Természetesen mc-vel nézegetem a fájlokat, de hát ugyanez a nézegető a greppelt fájlt végig mutatta, tehát tudok jobbra görgetni. … 🙂
Ezek szerint oprendszer specifikus a problémám?És igen! Ubuntu alatt tényleg végig megy.
De logikailag akkor sem értem! A grep hogyan befolyásolhatja a ps kimenetét? Ráadásul töblettel?
Egyébként az operndszer akkor RH9, tehát csak ott rdemes próbálgatni. 🙁
Igen, van, amikor az én programom hal el hibával, és ilyenkor valóban nincs PID a netstat sorában, de ez rendben is van.
Kértem egy bővített netstat-ot (igen, root-ként), és az érdekes az, hogy az Inode (amiről csak tippelem, hogy a socket inode száma), minden esetben valami szám, míg a kérdéses esetekben 0.
Ez is azt mutatja nekem, hogy egy olyan kapcsolat épült ki, ami még nincs teljesen kész.
Ráadásul hangsúlyozom, hogy a connect után az első dolog, amit csinálog, egy logbejegyzés, és az sem készül el, tehát én úgy érzem, hogy ezek a kapcsolatok nem jutnak el a programomig, így semilyen eszközt nem látok amivel befolyásolhatnám. Még a raw socket-et sem, hisz nem indul el a programom.
Adtam Timeout-ot a kapcsolatnak, de ezek a mágikus netstat sorok 0/0-ákkal állnak folyamatosan, azaz nem kezd el visszaszámolni az időzítőjük … ergó örökre maradnak! (?)A probléma az, hogy PID nélkül nem lenne szabad ESTABLISHED állapotnak lennie.
Hát, pont ez a probléma … De vannak, ez tény. Miért? És hogyan kezelhetem, hogy ne legyenek?
Igen, van, amikor az én programom hal el hibával, és ilyenkor valóban nincs PID a netstat sorában, de ez rendben is van.
Kértem egy bővített netstat-ot (igen, root-ként), és az érdekes az, hogy az Inode (amiről csak tippelem, hogy a socket inode száma), minden esetben valami szám, míg a kérdéses esetekben 0.
Ez is azt mutatja nekem, hogy egy olyan kapcsolat épült ki, ami még nincs teljesen kész.
Ráadásul hangsúlyozom, hogy a connect után az első dolog, amit csinálog, egy logbejegyzés, és az sem készül el, tehát én úgy érzem, hogy ezek a kapcsolatok nem jutnak el a programomig, így semilyen eszközt nem látok amivel befolyásolhatnám. Még a raw socket-et sem, hisz nem indul el a programom.
Adtam Timeout-ot a kapcsolatnak, de ezek a mágikus netstat sorok 0/0-ákkal állnak folyamatosan, azaz nem kezd el visszaszámolni az időzítőjük … ergó örökre maradnak! (?)A probléma az, hogy PID nélkül nem lenne szabad ESTABLISHED állapotnak lennie.
Hát, pont ez a probléma … De vannak, ez tény. Miért? És hogyan kezelhetem, hogy ne legyenek?
Köszi, félek, van itt valami, amit nem értek:
Azt írod, a ->connect() kapja meg a kapcsolatot, nem az ->accept()
De az én programomban nincs is ->connect()!Code:$sock = new IO::Socket::INET( LocalHost => IP, LocalPort => PORT, Proto => ‘tcp’, Listen => SOMAXCONN, Reuse => 1);
while( 1 ) {
while( $new_sock = $sock->accept() ) {
if( $child = fork ) {
…Tudnám máshogy is fogadni a kapcsolatot, hogy már a kiépülés után tudjak róla? Vagy a perl korlátoz ebben, és a probléma megoldásához C-ben kellene fogadnom a kapcsolatokat? (Erre ne válaszolj igennel!)
A másik, amit nem értek, az a netstat dolog. Én -p kapcsolóval futtatom, de a kérdéses kapcsolatoknál nincs PID, csak egy – jel. Ebből én arra gondolok, hogy az én programom még egyáltalán nem indulhatott el. Sem az accept, sem a connect.
A kliensek egyébként egyáltalán nem biztos, hogy jól zárják le a kapcsolatot. Sőt! Ezek hardver eszközök, súlyosbítva azzal, hogy az egész kommunikáció mobil hálózaton folyik, ami igen csak fura dolgokat tud művelni a TCP csomagokkal … Tehát nekem a lehető legextrémebb kliens kommunikációra is fel kell készülnöm!
Az én lezárásaim pedig azt hiszem, ebből a szempontból nem fontosak, hiszen el sem indul a programom.
A TIME_WAIT állapotú kapcsolatokkal rendben vagyok. A kérdéses kapcsolataim ESTABLISHED állapotúak.
Köszi, félek, van itt valami, amit nem értek:
Azt írod, a ->connect() kapja meg a kapcsolatot, nem az ->accept()
De az én programomban nincs is ->connect()!Code:$sock = new IO::Socket::INET( LocalHost => IP, LocalPort => PORT, Proto => ‘tcp’, Listen => SOMAXCONN, Reuse => 1);
while( 1 ) {
while( $new_sock = $sock->accept() ) {
if( $child = fork ) {
…Tudnám máshogy is fogadni a kapcsolatot, hogy már a kiépülés után tudjak róla? Vagy a perl korlátoz ebben, és a probléma megoldásához C-ben kellene fogadnom a kapcsolatokat? (Erre ne válaszolj igennel!)
A másik, amit nem értek, az a netstat dolog. Én -p kapcsolóval futtatom, de a kérdéses kapcsolatoknál nincs PID, csak egy – jel. Ebből én arra gondolok, hogy az én programom még egyáltalán nem indulhatott el. Sem az accept, sem a connect.
A kliensek egyébként egyáltalán nem biztos, hogy jól zárják le a kapcsolatot. Sőt! Ezek hardver eszközök, súlyosbítva azzal, hogy az egész kommunikáció mobil hálózaton folyik, ami igen csak fura dolgokat tud művelni a TCP csomagokkal … Tehát nekem a lehető legextrémebb kliens kommunikációra is fel kell készülnöm!
Az én lezárásaim pedig azt hiszem, ebből a szempontból nem fontosak, hiszen el sem indul a programom.
A TIME_WAIT állapotú kapcsolatokkal rendben vagyok. A kérdéses kapcsolataim ESTABLISHED állapotúak.
A probléma ideiglenesen megoldva. A szép megoldás azért még érdekelne.
Csak az apache-ot kellett újrafordítani (azért ez sem volt túl egyszerű, mert a ki kellett találni, a bináris hogy volt konfigurálva). A mágikus sorkezdet nálam így néz ki:Code:env CFLAGS=’-Wall -DSECURITY_HOLE_PASS_AUTHORIZATION’ ./configureLátrejön egy olyan apache, amelyik nem nyeli el az Authorization fejléceket. Itt már nem számít, hogy a fastcgi.conf-ban van-e -pass-header vagy sincs, tehát nem tudom, hogy ez a -pass-header minek van egyáltalán és hogyan kellene működnie.
Most tehát megy, de érzem, hogy nem ez az igazi, ráadásul minden apache patch után újra kell fordítani a forrásból, bár szerencsére a forrást is patch-elik…
Hát ennyit annak, aki véletlenül mégis ebbe a problémába ütközik…A probléma ideiglenesen megoldva. A szép megoldás azért még érdekelne.
Csak az apache-ot kellett újrafordítani (azért ez sem volt túl egyszerű, mert a ki kellett találni, a bináris hogy volt konfigurálva). A mágikus sorkezdet nálam így néz ki:Code:env CFLAGS=’-Wall -DSECURITY_HOLE_PASS_AUTHORIZATION’ ./configureLátrejön egy olyan apache, amelyik nem nyeli el az Authorization fejléceket. Itt már nem számít, hogy a fastcgi.conf-ban van-e -pass-header vagy sincs, tehát nem tudom, hogy ez a -pass-header minek van egyáltalán és hogyan kellene működnie.
Most tehát megy, de érzem, hogy nem ez az igazi, ráadásul minden apache patch után újra kell fordítani a forrásból, bár szerencsére a forrást is patch-elik…
Hát ennyit annak, aki véletlenül mégis ebbe a problémába ütközik…Látom, nem sokan neveztek a problémára, ezért az apache forrását kellett megolvasnom.
Van – azaz nincs – egy SECURITY_HOLE_PASS_AUTHORIZATION konstans definiálva, ami ha létezik, akkor az Authorization fejlécet továbbengedi a cgi felé. Ha ez a konstans nincs definiálva, akkor ezt a fejlécet kidobja. Persze továbbra sem értem, hogy akkor mit keres a fastcgiconfig után a -pass-header Authorization paraméter, de mindegy. A mágikus sorok az apache forrás server/util_script.c fájljában vannak:Code:#ifndef SECURITY_HOLE_PASS_AUTHORIZATION
else if (!strcasecmp(hdrs[I].key, „Authorization”)
|| !strcasecmp(hdrs[I].key, „Proxy-Authorization”)) {
continue;
}
#endif#ifndef helyett #ifdef-et írva lefordul és már működik is rendben, tehát ez a pár sor a bűnös.
A kérdéseim ezek után a következőek:Van egy binárisból telepített apacsom. Hogyan tudok úgy fordítani forrásból, hogy egy az egyben a bináris konfigurációját vegye fel? Persze apache2 -V parancs kiadja a fordítási beállításokat, de nem olyan formában, ahogy az fordításkor meg kell adnom. A bináris apacsom pedig minden modult dinamikusan kezel, a forrás apache azonban mindet befordítja a httpd démonba. Tehát nem lehet egyszerűen kicserélni a kettőt.
Vagy, hogyan tudom más módon mégis eljuttatni az Authorization fejlécet a cgi felé? Ez mindenképp jobb lenne, hisz a bináris apache-hoz folyamatosan adja az ubuntu a frissítéseket, ha lefordítom, onnantól magam foltozhatom, de ha foltozza is a forrást magam fordíthatom újra meg újra, meg újra …
[/I][/I]
Látom, nem sokan neveztek a problémára, ezért az apache forrását kellett megolvasnom.
Van – azaz nincs – egy SECURITY_HOLE_PASS_AUTHORIZATION konstans definiálva, ami ha létezik, akkor az Authorization fejlécet továbbengedi a cgi felé. Ha ez a konstans nincs definiálva, akkor ezt a fejlécet kidobja. Persze továbbra sem értem, hogy akkor mit keres a fastcgiconfig után a -pass-header Authorization paraméter, de mindegy. A mágikus sorok az apache forrás server/util_script.c fájljában vannak:Code:#ifndef SECURITY_HOLE_PASS_AUTHORIZATION
else if (!strcasecmp(hdrs[I].key, „Authorization”)
|| !strcasecmp(hdrs[I].key, „Proxy-Authorization”)) {
continue;
}
#endif#ifndef helyett #ifdef-et írva lefordul és már működik is rendben, tehát ez a pár sor a bűnös.
A kérdéseim ezek után a következőek:Van egy binárisból telepített apacsom. Hogyan tudok úgy fordítani forrásból, hogy egy az egyben a bináris konfigurációját vegye fel? Persze apache2 -V parancs kiadja a fordítási beállításokat, de nem olyan formában, ahogy az fordításkor meg kell adnom. A bináris apacsom pedig minden modult dinamikusan kezel, a forrás apache azonban mindet befordítja a httpd démonba. Tehát nem lehet egyszerűen kicserélni a kettőt.
Vagy, hogyan tudom más módon mégis eljuttatni az Authorization fejlécet a cgi felé? Ez mindenképp jobb lenne, hisz a bináris apache-hoz folyamatosan adja az ubuntu a frissítéseket, ha lefordítom, onnantól magam foltozhatom, de ha foltozza is a forrást magam fordíthatom újra meg újra, meg újra …
[/I][/I]
legutóbbi hsz