apache2 large files, SuSE rpm, build_with_LFS 1
Hallo, Ich haette gern dass mein apache2 mit files groesser 2GB umgehen kann. Im SuSE specfile steht dazu: # do not Enable Large File support (LFS) by default, because it changes the binary interface used by other modules. %{!?build_with_LFS:%define build_with_LFS 0} weiter habe ich irgendwo noch folgendes gefunden: - disable large file support by not building with _FILE_OFFSET_BITS=64, in favour of retaining a binary compatible module API. Therefore, do not change the module magic number. LFS can be enabled by building via rpmbuild --define 'build_with_LFS 1' Nun meine Frage, ist aus irgendwechen Gruenden davon abzuraten das RPM mit --define 'build_with_LFS 1' zu bauen? Um welche Module, die das binary interface benutzen handelt es sich? cu, Ruediger
On Mon, Mar 14, 2005 at 12:31:03PM +0100, Ruediger Meier wrote:
Hallo, Ich haette gern dass mein apache2 mit files groesser 2GB umgehen kann.
Du findest apache2 Pakete die mit LFS gebaut sind hier: http://ftp.suse.com/pub/projects/apache/apache2
Im SuSE specfile steht dazu:
# do not Enable Large File support (LFS) by default, because it changes the binary interface used by other modules. %{!?build_with_LFS:%define build_with_LFS 0}
weiter habe ich irgendwo noch folgendes gefunden: - disable large file support by not building with _FILE_OFFSET_BITS=64, in favour of retaining a binary compatible module API. Therefore, do not change the module magic number. LFS can be enabled by building via rpmbuild --define 'build_with_LFS 1'
Nun meine Frage, ist aus irgendwechen Gruenden davon abzuraten das RPM mit --define 'build_with_LFS 1' zu bauen?
Um welche Module, die das binary interface benutzen handelt es sich?
Zu beachten ist dass alle Apache-Module mit dem entsprechenden Apache (bzw. der entsprechenden libapr0) gebaut sei muessen. Sonst fliegt alles in die Luft. Entsprechende Pakete liegen unter der oben genannten Adresse bereit (pub/projects/apache Verzeichnis). Welche Module das sind, kann man auf einfache Weise mittels 'rpm -e --test libapr0' rausfinden. Beim selber Bauen (des Apache) kann man rpmbuild wie oben zitiert verwenden. Die Distributionsversion verwendet keinen LFS, um volle Kompatibilitaet zu Dritt-Software zu gewaehrleisten. Ich habe hierzu eben ein README angelegt, das in Kuerze (eventuell aber ausnahmsweise erst in einigen Tagen) auf dem FTP-Server erscheinen wird. Peter -- the little can of spam got the big cardinal
On Monday 14 March 2005 17:00, poeml@cmdline.net wrote:
Du findest apache2 Pakete die mit LFS gebaut sind hier: http://ftp.suse.com/pub/projects/apache/apache2
Besten Dank fuer die ausfuehrliche Antwort und die Pakete - Funktioniert wie gwuenscht! :) cu, Ruediger
On Tue, Mar 15, 2005 at 03:11:36AM +0100, Ruediger Meier wrote:
On Monday 14 March 2005 17:00, poeml@cmdline.net wrote:
Du findest apache2 Pakete die mit LFS gebaut sind hier: http://ftp.suse.com/pub/projects/apache/apache2
Besten Dank fuer die ausfuehrliche Antwort und die Pakete - Funktioniert wie gwuenscht! :)
So soll es sein -- und danke fuer das Feedback :) Peter -- the little cardinal imitated the big cardinal
On Wednesday 16 March 2005 18:16, poeml@cmdline.net wrote:
Besten Dank fuer die ausfuehrliche Antwort und die Pakete - Funktioniert wie gwuenscht! :)
So soll es sein -- und danke fuer das Feedback :)
OK ich hab mich ein bisschen voreilig gefreut - nur weil mein konquerror die File Groessen korrekt angezeigt hat. (Ich konnte hier mit meinem ISDN keinen kompletten download >2GB testen) Folgendes passiert wenn ich das 3367000064 byte grosse test.iso versuche downzuloaden: 1. Ein Windows User hat mit Firefox test.iso downgeloadet Die Groesse ist bei ihm korrekt aber md5sum nicht! 2. auf einer SuSE 9.1 (remote sowie auf dem server selbst) habe ich $ wget http://user:pwd@virtual.xyz.net/~rudi/test.iso --23:12:30-- http://user:*password*@virtual.xyz.net/%7Erudi/test.iso => `test.iso' Auflösen des Hostnamen »virtual.xyz.net«.... xxx.xxx.xxx.xxx Verbindungsaufbau zu inlinedata.fortbravo.net[xxx.xxx.xxx.xxx]:80... verbunden. HTTP Anforderung gesendet, warte auf Antwort... 200 OK Länge: -927,967,232 [application/octet-stream] [ <=> ] 0 --.--K/s 23:12:30 (0.00 B/s) - »test.iso« gespeichert [0/-927967232]) test.iso ist dann 0 Byte gross. 3. mit dem FireFox auf SuSE 9.1 beginnt er den download eines "2097,2MB" files (immer noch dasselbe test.iso) 4. der konquerror beginnt den download und sagt mir auch die korrekte Groesse! Leider kann ich selbst hier mit ISDN nie einen download durchziehen. (und ich kann auch niemanden mit DSL-1000 zumuten das mehrmals zu testen):( In allen 4 Faellen steht im apache.log die korrekte Groesse z.B beim wget-test: xxx.xxx.xxx.xxx - mldonkey [16/Mar/2005:23:12:31 +0100] "GET /%7Erudi/test.iso HTTP/1.0" 200 33670000 64 "-" "Wget/1.9.1" Ist das jetzt ein Problem der Clients oder stimmt beim Apachen etwas nicht. Vielleicht liegts daran dass das File in einem userdir liegt? (die userdirs hab ich nur auf einem virtuellen host) cu Ruediger
On Thursday 17 March 2005 00:13, Ruediger Meier wrote:
OK ich hab mich ein bisschen voreilig gefreut - nur weil mein konquerror die File Groessen korrekt angezeigt hat.
Folgendes passiert wenn ich das 3367000064 byte grosse test.iso versuche downzuloaden:
2. auf einer SuSE 9.1 (remote sowie auf dem server selbst) habe ich $ wget http://user:pwd@virtual.xyz.net/~rudi/test.iso [...] test.iso ist dann 0 Byte gross.
Ok jetzt habe ich mal dieses wget genommen http://software.lpetrov.net/wget-LFS/ und $ wget-LFS http://localhost/test.iso funktioniert! (Ich wusste gar nicht dass LFS auf http Client-Seite noch so problematisch ist.) Wenn ich einen Browser versuche zeigen bei mir Mozilla, Opera und Firefox falsche Dateigroessen an wenn ich den download beginne. Nur der Konquerror scheint es richtig zu machen.(wie gesagt einen kompletten download solch grosser Files kann ich hier nicht durchziehen) Dasselbe Ergebnis wenn ich ein DVD-Image von einem Server den ich mal als korrekt annehme anfange: http://ftp.uni-erlangen.de/pub/Linux/MIRROR.suse/pub/suse/i386/9.2/iso/ Vielleicht hat ja mal irgend jemand hier Lust diesen Link mit seinem Browser zu testen;) Wichtig, md5sum check nicht vergessen. Es ist also eher wahrscheinlich dass mein Apache von http://ftp.suse.com/pub/projects/apache/apache2 gut ist, aber die clients rumzucken. Kann mir jemand einen Win32 Browser empfehlen von dem er weiss, dass er LFS kann. Dann koennte ich diesen meinen Win-Usern empfehlen und diese meinen Apachen testen lassen. cu Ruediger
On Thu, Mar 17, 2005 at 01:52:09PM +0100, Ruediger Meier wrote:
On Thursday 17 March 2005 00:13, Ruediger Meier wrote:
OK ich hab mich ein bisschen voreilig gefreut - nur weil mein konquerror die File Groessen korrekt angezeigt hat.
Folgendes passiert wenn ich das 3367000064 byte grosse test.iso versuche downzuloaden:
2. auf einer SuSE 9.1 (remote sowie auf dem server selbst) habe ich $ wget http://user:pwd@virtual.xyz.net/~rudi/test.iso [...] test.iso ist dann 0 Byte gross.
Ok jetzt habe ich mal dieses wget genommen http://software.lpetrov.net/wget-LFS/ und $ wget-LFS http://localhost/test.iso funktioniert!
(Ich wusste gar nicht dass LFS auf http Client-Seite noch so problematisch ist.)
Leider ist das so. Dummerweise ist der LFS-Patch in wget auch noch problematisch, und verursacht einige andere Bugs. Peter -- the little machine that goes "ping" got the big machine that goes "ping"
On Thu, Mar 17, 2005 at 12:13:27AM +0100, Ruediger Meier wrote:
On Wednesday 16 March 2005 18:16, poeml@cmdline.net wrote:
Besten Dank fuer die ausfuehrliche Antwort und die Pakete - Funktioniert wie gwuenscht! :)
So soll es sein -- und danke fuer das Feedback :)
OK ich hab mich ein bisschen voreilig gefreut - nur weil mein konquerror die File Groessen korrekt angezeigt hat. (Ich konnte hier mit meinem ISDN keinen kompletten download >2GB testen)
Tja, der Client muss es natuerlich auch unterstuetzen.
Folgendes passiert wenn ich das 3367000064 byte grosse test.iso versuche downzuloaden: 1. Ein Windows User hat mit Firefox test.iso downgeloadet Die Groesse ist bei ihm korrekt aber md5sum nicht!
Dazu kann ich nichts sagen.
2. auf einer SuSE 9.1 (remote sowie auf dem server selbst) habe ich $ wget http://user:pwd@virtual.xyz.net/~rudi/test.iso --23:12:30-- http://user:*password*@virtual.xyz.net/%7Erudi/test.iso => `test.iso' Auflösen des Hostnamen »virtual.xyz.net«.... xxx.xxx.xxx.xxx Verbindungsaufbau zu inlinedata.fortbravo.net[xxx.xxx.xxx.xxx]:80... verbunden. HTTP Anforderung gesendet, warte auf Antwort... 200 OK Länge: -927,967,232 [application/octet-stream]
[ <=> ] 0 --.--K/s
23:12:30 (0.00 B/s) - »test.iso« gespeichert [0/-927967232])
test.iso ist dann 0 Byte gross.
Wget hat keinen LFS. Ich kann das 'ftp' Tool empfehlen (das standardmaessig installierte aus dem lukemftp Paket). Das kann mit http und ftp URLs umgehen und unterstuetzt grosse Dateien. Einfach per 'ftp http://hostname/path/to/file' aufrufen. curl funktioniert seit 9.2 (?) auch (am besten ueber das Paket Changelog ueberpruefen, da steht drin ab wann es geht -- rpm -q --changelog curl.
3. mit dem FireFox auf SuSE 9.1 beginnt er den download eines "2097,2MB" files (immer noch dasselbe test.iso)
4. der konquerror beginnt den download und sagt mir auch die korrekte Groesse!
Leider kann ich selbst hier mit ISDN nie einen download durchziehen. (und ich kann auch niemanden mit DSL-1000 zumuten das mehrmals zu testen):(
In allen 4 Faellen steht im apache.log die korrekte Groesse z.B beim wget-test: xxx.xxx.xxx.xxx - mldonkey [16/Mar/2005:23:12:31 +0100] "GET /%7Erudi/test.iso HTTP/1.0" 200 33670000 64 "-" "Wget/1.9.1"
Ist das jetzt ein Problem der Clients oder stimmt beim Apachen etwas nicht.
Problem der Clients.
Vielleicht liegts daran dass das File in einem userdir liegt? (die userdirs hab ich nur auf einem virtuellen host)
Nein. Das sollte keine Rolle spielen. Peter -- the pink can of spam got the tasty cardinal
participants (2)
-
poeml＠cmdline.net -
Ruediger Meier