Hallo, Am Mon, 06 Nov 2006, Al Bogner schrieb:

Am Montag, 6. November 2006 10:33 schrieb Al Bogner:

...

wget -Y on --cache=on --delete-after "$CHKFILE"

Ich sehe da gerade, dass das die Variante danach für die Fehlermeldung ist. Das 1. Mal wird so abgefragt:

wget -q -Y off --cache=off "$CHKFILE"

==== info wget ==== `-C on/off' `--cache=on/off' When set to off, disable server-side cache. `-Y on/off' `--proxy=on/off' Turn proxy support on or off. The proxy is on by default if the appropriate environmental variable is defined. ==== curl -f -s -o /dev/null [ -x "" ] Verwende ggfs. noch '-m'. Bzgl. Cache kann curl wohl nix. BTW: The latest stable version of Wget is 1.10.2. This release contains fixes for a major security problem: a remotely exploitable buffer overflow vulnerability in the NTLM authentication code. All Wget users are strongly encouraged to upgrade their Wget installation to the last release. src/ChangeLog 2005-10-13 Daniel Stenberg * http-ntlm.c (ntlm_output): Fixed buffer overflow vulnerability. -dnh -- We deal in the moral equivalent of black holes, where the normal laws of right and wrong break down; beyond those metaphysical event horizons there exist ... special circumstances -- Use Of Weapons

Hallo, Am Mon, 06 Nov 2006, Al Bogner schrieb:

Am Montag, 6. November 2006 20:07 schrieb David Haller: [..]

...

Bzgl. Cache kann curl wohl nix.

Hmm, macht es dann überhaupt Sinn, was ich vorhabe:

Ich lade in regelmäßigen Abständen eine Datei runter und vergleiche den Inhalt mit grep bzw- md5sum. Das hat bis jetzt ganz gut geklappt, wenn der Hoster nicht funktionierte. Dienste wie siteuptime haben vergleichsweise oft keinen Alarm geschlagen und aufwendigere Tools habe ich wieder aufgehört zu verwenden.

Wenn ich nicht sicher seiner kann, dass die sehr kleine Datei _nicht_ aus irgendeinem Cache kommt, dann kann ich es gleich sein lassen. Teilweise habe ich nur eine Datei angelegt, ok reingeschrieben und dann in der runtergeladene Datei nach ok "gegrept".

Irgendwelche Ideen? Es muss nicht unbedingt curl sein, ich will nur sicher gehen, dass ich wirklich die Datei vom Server runterlade.

Hast du perl? Mit libwww (d.h. konkret LWP::UserAgent)? Wenn ja kann man das ganze im RAM abfeiern und dann ggfs. immer noch als Datei ins Dateisystem rausschreiben. ==== Schema [Digest Kram ungetestet] ==== #!/usr/bin/perl -w use strict; use LWP::UserAgent; # use Digest::MD5 qw(md5_hex); my $url = 'http://deine.domain.tld/foo'; my $ua = LWP::UserAgent->new(); $ua->default_headers->push_header('Pragma' => "no-cache"); my $response = $ua->get($url); if ($response->is_success) { # # Datei "greppen" # if( $response->content =~ /ok/ ) { # ## machwas # } # # Digest erstellen vergleiche, alte Datei ueberschreiben # $digest = md5_hex($response->content); # open(FILE, "/vergleichs/datei") or die "Can't open '$file': $!"; # binmode(FILE); # my $olddigest = Digest::MD5->new->addfile(*FILE)->hexdigest; # if( $digest eq $olddigest) { # seek(FILE, 0, SEEK_SET) or die "$!\n"; # print FILE $response->content; # Bisherige Datei ueberschreiben # } # close(FILE); # einfach ausgeben print $response->content; } else { die $response->status_line; } ==== Per default verwendet LWP keinen Proxy (auch nicht aus Umgebungsvariablen), ggfs. kannst du aber mit no_proxy (siehe LWP::UserAgent Doku) auch gezielt abschalten.

...

BTW:

The latest stable version of Wget is 1.10.2.

Bei Suse 10.0 gibt es nur 1.10.1. Lässt Suse da wirklich eine Sicherheitslücke offen? [..]

...

src/ChangeLog 2005-10-13 Daniel Stenberg * http-ntlm.c (ntlm_output): Fixed buffer overflow vulnerability.

Moeglich. Kann aber auch sein, dass SUSE NTLM schlicht deaktiviert hat. strings `which wget` | grep -i ntlm Ich hab vorhin mal eben aktualisiert (von 1.7.nochwas). $ wget --version GNU Wget 1.10.2 -dnh --

"Winter, jetzt!" Tut mir leid, Winter macht gerade Urlaub in Australien. Kann ich evtl. weiterhelfen? -- Arnim Sommer

Hallo, Am Die, 07 Nov 2006, Al Bogner schrieb:

Am Dienstag, 7. November 2006 02:39 schrieb David Haller:

...

Am Mon, 06 Nov 2006, Al Bogner schrieb: [..] Hast du perl?

Ja, aber ob ich alles verwenden darf, kann ich nicht sagen, wie teste ich das vorab?

...

Mit libwww (d.h. konkret LWP::UserAgent)?

Wie in einem Fremdsystem möglichst "unauffällig" überprüfen?

perl -MLWP::UserAgent -e '1;' Falls du eine Fehlermeldung vermeiden willst: $ perl -e 'foreach(@ARGV) { eval "require $_;"; print " not found\n" if $@; } 1;' LWP::UserAgetn LWP::UserAgent LWP::UserAgetn not found Als Argumente fuer das "Script" gibst du einfach alle Module an, auf die du testen willst. Ggfs. solltest du dir aber die Fehlermeldung von Perl selbst ausgeben lassen (falls Abhaengigkeiten fehlen): perl -e 'foreach(@ARGV) { eval "require $_;"; print "$@\n" if $@; } 1;' [..]

Ich probiere das aus, sobald ich geprüft habe, ob ich überhaupt die nötigen Pakete inkl. Rechte habe.

Hoster1: perl -v This is perl, v5.8.7 built for x86_64-linux

Hoster2: perl -v This is perl, v5.8.7 built for i686-linux

Sieht gut aus. Scheint gepflegt zu werden (was nicht unbedingt zu erwarten ist).

...

Moeglich. Kann aber auch sein, dass SUSE NTLM schlicht deaktiviert hat.

strings `which wget` | grep -i ntlm

von Suse 10.0:

strings `which wget` | grep -i ntlm NTLM [..]

Normal baut SUSE Bugfixes ja ein: rpm -qi --changelog -f `which wget` -dnh -- I do not have enough Scotch in this house to attempt an XP install. -- Peter Corlett

Hallo, Am Mit, 08 Nov 2006, Al Bogner schrieb:

Am Dienstag, 7. November 2006 22:49 schrieb David Haller:

...

...

...

Mit libwww (d.h. konkret LWP::UserAgent)?

Wie in einem Fremdsystem möglichst "unauffällig" überprüfen?

perl -MLWP::UserAgent -e '1;'

Mache ich da was falsch, ich habe es mal lokal probiert:

rpm -q perl-libwww-perl perl-libwww-perl-5.803-4

perl -MLWP::UserAgent -e '1;' keine Ausgabe

Nein. Obiger Befehl laedt LWP::UserAgent (falls das nicht geht bekommst du auf STDERR eine Fehlermeldung "Can't locate LWP::UserAgent in @INC ..."). Keine Ausgabe ist "alles OK" :-D Bei mir ist die Sache offensichtlicher, denn ich lasse mir den Exitstatus im Bash-Prompt angeben ;) Wenn du den Exitstatus sehen willst: perl -MLWP::UserAgent -e '1;'; echo $? Oder mach gleich folgendes: perl -MLWP::UserAgent -e 'print "$LWP::UserAgent::VERSION\n"; 1;' Das gibt dir gelich die Version von LWP::UserAgent aus. Ich habe hier die aktuelle Version 2.033 (die ist schon ne ganze Weile aktuell) aus G/GA/GAAS/libwww-perl-5.805.tar.gz (hm, komisch, der Tarball ist weg). Ich denke aber, die Version die du hast ist aktuell genug. LWP::UserAgent >= 2.0 sollte reichen. [NTLM-Bug in wget <= 1.10.2]

...

Normal baut SUSE Bugfixes ja ein:

rpm -qi --changelog -f `which wget`

- Removed the unneeded fix for CAN-2004-1487 (bugs #179369 and #185214).

Soo schlimm kann wget ja nicht sein, wenn sich Bugs als Enten herausstellen. *höhö*

- Filter escape responses from the HTTP server (CAN-2004-1488, bug #185265). * Fre Okt 14 2005 - mmj@ - Fixed buffer overflow vulnerability with ntlm [#128065

Es dürfte der von dir erwähnte Bug also korrgiert sein.

Jup. Kommt auch vom Datum hin. Also, typisch SuSE: "Backport" des Bugfixes. Ob das der von (aeh wer war das nochmal? Ah!) Martin Schröder erwaehnte Bug war weiss ich nicht. Bei IMO so ausgereifter Software wie wget würde ich wget (im Ggs. zu Martin) als noch "maintained" ansehen. Martin, hast du ne URL die deine Behauptung "hatte in den letzten Jahren diverse Sicherheitsprobleme und selbst die Maintainer rieten von seiner Verwendung ab wg. Unwartbarkeit." unterfüttert? Und ob sich das "unwartbar" auf die Sicherheit bezieht? Oder nur darauf, dass der Code eben unschön ist (gewachsen eben ;)? Und, Martin, hast du mal verglichen, was z.B. curl/libcurl so an Problemen haben/hatten? Ganz zu schweigen von anderen Programmen? IMO kann wget alles, was so ein Programm braucht. Das was fehlt ist auf shell-Ebene besser aufgehoben. -dnh -- Words fail me. Thank goodness I can make gestures. -- Mark Hughes