Ich habe nun den halben Vormittag damit verbracht meinen Fehler zu finden, ich finde keinen.
my $param = {
url => $ncURI,
timeout => 10,
method => 'PUT',
data => $cont,
user => $ncUser,
pwd => $ncPass,
callback => \&FHEM::backup::ncUploadCb,
};
Wenn ich nun folgendes mit $ncURI mache
my $ncURI = 'https://cloud.cooltux.net/remote.php/dav/files/marko/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz'
Es läuft super und ich bekomme verkürzt verbose 5 so
2020.06.16 13:44:20.998 4: IP: cloud.cooltux.net -> 192.168.240.241
2020.06.16 13:44:21.010 5: HttpUtils request header:
PUT /remote.php/dav/files/marko/FHEM-Backup/FHEM-20200616_134411.tar.gz HTTP/1.0
Host: cloud.cooltux.net
User-Agent: fhem
Accept-Encoding: gzip,deflate
Authorization: Basic bWFya28lkdhfkjdhfjkdhfkjdhfkjdhfMtSmZUUzM=
Content-Length: 33557065
Content-Type: application/x-www-form-urlencoded
2020.06.16 13:44:25.301 4: https://cloud.cooltux.net/remote.php/dav/files/marko/FHEM-Backup/FHEM-20200616_134411.tar.gz: HTTP response code 201
2020.06.16 13:44:25.301 5: HttpUtils https://cloud.cooltux.net/remote.php/dav/files/marko/FHEM-Backup/FHEM-20200616_134411.tar.gz: Got data, length: 0
2020.06.16 13:44:25.302 5: HttpUtils response header:
HTTP/1.0 201 Created
date: Tue, 16 Jun 2020 11:44:21 GMT
server: Apache
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block
set-cookie: 0d6b13b01c9d6=o6c6rj45qsfgqqh9h0qi6tie40; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc_sessionPassphrase=GcYvTBzeC%2FKlx8Rp%2FLkOjvzr8t3FGPif3WBz5R3OkQqLxtP9Nm41%2BFFafc%2BkVcyOaDeSXHfT7vGHIV5U52JHyMErGxy1JQsFls3ma%2BqYGJQgCn6NCtgIZmLkI4dPHTjx; path=/; secure; HttpOnly
content-security-policy: default-src 'none';
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
set-cookie: 0d6b13b01c9d6=8fe6he9pqmuh3u6ov0f702jtvh; path=/; secure; HttpOnly
oc-fileid: 001302410d6b13b01c9d6
content-length: 0
etag: "73e79b81fa3680c6289cb73b077135c1"
oc-etag: "73e79b81fa3680c6289cb73b077135c1"
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=15768000; preload
2020.06.16 13:44:25.302 1: backup Nextcloud upload succesfully
Sobald ich aber versuche andere variablen ein zu bauen
my $ncURI = 'https://'.$host.'/remote.php/dav/files/marko/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz'
oder auch
my $ncURI = 'https://cloud.cooltux.net/remote.php/dav/files/'.$user.'/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz'
Geht es nicht mehr und ich bekomme
2020.06.16 13:37:38.272 4: IP: cloud.cooltux.net -> 192.168.240.241
2020.06.16 13:37:38.286 5: HttpUtils request header:
PUT /remote.php/dav/files/marko/FHEM-Backup/FHEM-20200616_133729.tar.gz HTTP/1.0
Host: cloud.cooltux.net
User-Agent: fhem
Accept-Encoding: gzip,deflate
Authorization: Basic bWFdshfkjdshfkjdhfkjdshfkjdftlM04ta3E5YkMtSmZUUzM=
Content-Length: 33355471
Content-Type: application/x-www-form-urlencoded
2020.06.16 13:37:48.603 1: backup Nextcloud upload failed - Error: write to https://cloud.cooltux.net:443 timed out Data:
Mehr nicht.
Wo ist da bitte schön der Unterschied ob ich da variablen nehme oder es als festen String einsetzte. Ich meine das /FHEM-'.$dateTime.'.tar.gz am Ende geht doch auch.
my $ncUser = AttrVal('global','backupNCuser','');
my $ncPass = AttrVal('global','backupNCpass','');
my $ncHost = AttrVal('global','backupNChost','');
my $ncPath = AttrVal('global','backupNCpath','');
HttpUtils_NonblockingGet(
{
url => 'https://cloud.cooltux.net/remote.php/dav/files/marko/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz',
timeout => 60,
method => 'PUT',
data => $cont,
user => $ncUser,
pwd => $ncPass,
callback => \&FHEM::backup::ncUploadCb,
}
);So geht es. Die Datei wird entsprechend hoch geladen
my $ncUser = AttrVal('global','backupNCuser','');
my $ncPass = AttrVal('global','backupNCpass','');
my $ncHost = AttrVal('global','backupNChost','');
my $ncPath = AttrVal('global','backupNCpath','');
HttpUtils_NonblockingGet(
{
url => 'https://cloud.cooltux.net/remote.php/dav/files/'.$ncUser.'/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz',
timeout => 60,
method => 'PUT',
data => $cont,
user => $ncUser,
pwd => $ncPass,
callback => \&FHEM::backup::ncUploadCb,
}
);Wenn ich es nur ein klein wenig veränder geht es schon nicht mehr. Meldung
Zitatbackup Nextcloud upload failed - Error: write to https://cloud.cooltux.net:443 timed out
Und wenn Du mal folgendes probierst:
my $ncUser = AttrVal('global','backupNCuser','');
my $ncPass = AttrVal('global','backupNCpass','');
my $ncHost = AttrVal('global','backupNChost','');
my $ncPath = AttrVal('global','backupNCpath','');
my $ncURL = 'https://cloud.cooltux.net/remote.php/dav/files/'.$ncUser.'/FHEM-Backup/FHEM-'.$dateTime.'.tar.gz';
HttpUtils_NonblockingGet(
{
url => $ncURL,
timeout => 60,
method => 'PUT',
data => $cont,
user => $ncUser,
pwd => $ncPass,
callback => \&FHEM::backup::ncUploadCb,
}
);
Grüße Jörg
Hallo Jörg,
Das selbe Spiel. Hatte ich auch dran gedacht, sobald ich mehr in $ncURL als Variable einbaue wie das $dateTime läuft es gegen die Wand.
Grüße
Zum eigentlichen Problem kann ich nichts sagen, ich fuehle mich als HttpUtils.pm Maintainer unschuldig (noch) :).
Ich schlage aber vor statt den vielen global backupNG* Attributen ein backupNG FHEM-Device anzulegen, und das backup darueber abzuwickeln.
Damit kan man gleichzeitig mehrere Backup-Profile haben, und das global Namespace waere auch nicht weiter "verseucht".
Ganz im Sinne einer Modularisierung :)
Ich denke gerne darüber nach wenn es mein Problem löst ;D
Vermutlich nicht, solltest trotzdem darueber nachdenken :)
Sonst: in dem gezeigten Logs ist Authorization: unterschiedlich. Wenn Du die Zeile nicht verfremdet hast, dann kann es die Ursache sein. Weiterhin sind die Laengen unterschiedlich. Ich wuerde zum Debuggen die gleiche Datei nehmen.
Man koennte ja auch auf der "anderen" Seite nachschauen, was fehlt, meist landet so ei Request im Error-Log.
Zitat von: rudolfkoenig am 16 Juni 2020, 17:11:06
Vermutlich nicht, solltest trotzdem darueber nachdenken :)
Sonst: in dem gezeigten Logs ist Authorization: unterschiedlich. Wenn Du die Zeile nicht verfremdet hast, dann kann es die Ursache sein. Weiterhin sind die Laengen unterschiedlich. Ich wuerde zum Debuggen die gleiche Datei nehmen.
Man koennte ja auch auf der "anderen" Seite nachschauen, was fehlt, meist landet so ei Request im Error-Log.
Hallo Rudi,
Ich denke gerne darüber nach. Die Idee ist ja wirklich gut.
Danke für die Tips, die Auth habe ich verfremdet, aber ich werde in der Tat einmal schauen das ich immer mit der selben Datei teste.
Grüße
Guten Morgen,
Ich habe gestern noch Rudis Vorschläge umgesetzt, leider hat das auch nicht zum Erfolg geführt. Dann viel mir ein das ich ja die ersten Tests in einer myUtils gemacht habe und habe dort mal mit den Variablen gearbeitet. Und siehe da, dort funktioniert es. Weiß der Kuckuck wieso. Es besteht also eine 50 prozentige Möglichkeit das es mit einem Modul funktioniert. Ich werde mal ein kleines Testmodul entwerfen.
Grüße
Ich will heulen.
Ich habe ein Modul gemacht und das ist wirklich schön.
Doch leider habe ich hier die selben Effekte wie mit oben beschrieben.
:'(
Es kann doch nicht sein das ich jetzt den Misst noch in eine Datei oder so fest einschreiben lassen muss. So ein Unsinn
Pushe doch die Sachen mal irgendwo hin, wo man sie sich anschauen kann, z.B. in Github.
Wer weiß ob irgendwas mit dem Encoding oder so kaputt ist.
Wenigstens könnte man es so selbst nachstellen.
https://git.cooltux.net/FHEM/mod-backupToStorage
Gibt auch ein Control File. Du brauchst aber die aktuelle 98_backup.pm welche ich vorhin in GitHub und ins SVN geladen habe.
Beschreibung gibt es noch nicht. Ist aber selbsterklärend
define NAME backupToStorage
Nach dem Anlegen des Devices die Attribute setzen und dann einfach
backup
ausführen
Ich bin etwas weiter gekommen.
Ein einfaches Logfile mit 500kb läd er hoch. Mein Backupfile mit 31,9 läd er hoch bekomme aber Fehler im Log
2020.06.17 22:45:50.262 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 653.
2020.06.17 22:45:50.262 1: stacktrace:
2020.06.17 22:45:50.262 1: main::__ANON__ called by FHEM/HttpUtils.pm (653)
2020.06.17 22:45:50.262 1: main::__ANON__ called by fhem.pl (768)
2020.06.17 22:45:50.262 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 654.
2020.06.17 22:45:50.262 1: stacktrace:
2020.06.17 22:45:50.262 1: main::__ANON__ called by FHEM/HttpUtils.pm (654)
2020.06.17 22:45:50.262 1: main::__ANON__ called by fhem.pl (768)
2020.06.17 22:45:50.339 1: backupToStorage (nextcloudBackup) - backup URL: https://cloud.cooltux.net/remote.php/dav/files/USER/FHEM-20200617_224324.tar.gz
2020.06.17 22:45:50.339 3: backupToStorage (nextcloudBackup) - callback: backup Nextcloud upload succesfully
Und das File ist korrupt trotz korrekter Größe.
Morgen will ich testen ob es generell an Binärfiles liegt oder an der Größe.
Und was ich nicht verstehe, das ganze als myUtils Funktion hat keine Probleme mit der Größe und läd recht schnell hoch.
@Rudi
Vielleicht findest Du einen Ansatz in der Fehlermeldung.
Nachti
Die WARNING Zeile meint, dass syswrite es geschafft hat mehr zu schreiben, als $data lang ist.
Hypothese: $data enthaelt wide Character, und syswrite protestiert bei Dir nicht dagegen, so wie ich das bisher gewohnt war, sondern konvertiert es stillschweigend, und liefert Anzahl der geschriebenen Bytes zurueck. substr arbeitet mit (wide) Character, und die beiden Zaehlweisen sind nicht kompatibel.
Wenn diese Hypothese korrekt ist, dann muss man die Stelle finden, die auf die Idee mit dem Wide Character kam (binmode?), und die Stelle korrigieren.
Danke Dir Rudi für Deine Analyse und Tipps.
Habe nun schon alles probiert, sobald die Datei binär ist und egal welche Größe kommt der Fehler. Ich werde nun doch auf cURL ausweichen.
Grüße
Ich habe das ganze Modul auf cURL und SubProcess umgestellt.
Ich danke allen für Ihre Unterstützung.
Um Probleme mit HttpUtils_NonblockingGet auszuschliessen habe ich
- einen minimalen Upload-Server gebastelt, was hinter einem Apache auf Daten wartet
- es mit curl -T getestet
- danach mit folgender Funktion aus 99_myUtils.pm HttpUtils getestet (45MB .mp3):
sub
DoUpload($$;$$)
{
my ($url,$fname,$user,$pw)=@_;
my $data;
{
local $/= undef;
open(FH,$fname) || return "$fname:$!";
$data = <FH>;
close(FH);
}
HttpUtils_NonblockingGet({
url=>$url, timeout=>60, data=>$data,
user=>$user, pwd=>$pw, callback=>sub() {
my ($hash, $err, $ret) = @_;
Log 1, "Upload finished, Err:$err Response-Length:".length($ret);
}
});
return "Upload started";
}
=> Ich sehe keine Probleme, die MD5-Summen sind identisch.
Das heisst nicht, dass ich gegen eine curl basierte Loesung bin, ich wollte nur sicher gehen, dass es sich nicht um ein HttpUtils Problem handelt.
Zitat von: rudolfkoenig am 18 Juni 2020, 16:29:55
Um Probleme mit HttpUtils_NonblockingGet auszuschliessen habe ich
- einen minimalen Upload-Server gebastelt, was hinter einem Apache auf Daten wartet
- es mit curl -T getestet
- danach mit folgender Funktion aus 99_myUtils.pm HttpUtils getestet (45MB .mp3):
sub
DoUpload($$;$$)
{
my ($url,$fname,$user,$pw)=@_;
my $data;
{
local $/= undef;
open(FH,$fname) || return "$fname:$!";
$data = <FH>;
close(FH);
}
HttpUtils_NonblockingGet({
url=>$url, timeout=>60, data=>$data,
user=>$user, pwd=>$pw, callback=>sub() {
my ($hash, $err, $ret) = @_;
Log 1, "Upload finished, Err:$err Response-Length:".length($ret);
}
});
return "Upload started";
}
=> Ich sehe keine Probleme, die MD5-Summen sind identisch.
Das heisst nicht, dass ich gegen eine curl basierte Loesung bin, ich wollte nur sicher gehen, dass es sich nicht um ein HttpUtils Problem handelt.
Hallo Rudi,
Erstmal vielen lieben Dank das Du da noch Energie rein steckst. Das komische ist ja das ich das ganze über eine myUtils auch machen kann und da geht es.
Es geht auch wenn ich die URL fest codiere und nicht mit variablen versehe. Wie gesagt alles total komisch.
Ich habe sogar meine myUtils als package gemacht so wie das Modul, auch dann geht alles noch. Ist total komisch. Aber ich denke mir auch 16 Stunden Energie sind genug. Ich behaupte nicht das der Fehler an der HttpUtils_NonblockingGet liegt, es kann auch sein das ich einen Fehler mache oder es an Nextcloud liegt. So muss ich bei Nextcloud explizit PUT als Method nehmen damit es geht.
Ich schaue mal wie es sich weiter entwickelt. Ich werde eine Supportunterstützung mit autoupload für Logfile für ASC machen und dann werden wir sehen ob es da bei reinen Textfiles auch noch Probleme gibt. Da will ich auf jeden Fall wieder HttpUtils_NonblockingGet nehmen.
Grüße
Marko
ZitatEs geht auch wenn ich die URL fest codiere und nicht mit variablen versehe.
Ich vermute, dass einer der verwendeten Variablen Wide-Character enthaelt.
Hatte ich eigentlich soweit überprüft. Habe extra die Variable und nur eine geänderte selbst mit String gefüllt.
Was mir vorhin noch ein viel wäre ein chomp() auf das <FD> zu machen. Aber nun ist zu spät