Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
Start · Board · Anwendungen/Programme/Skripte in Perl · Netzwerkprogrammierung und Netzwerke mit Perl
[thread]11750[/thread]

Fileserver Problem

Leser: 1


<< >> 7 Einträge, 1 Seite
blemmo
 2008-05-05 17:11
#109208 #109208
User since
2008-05-05
3 Artikel
BenutzerIn
[default_avatar]
Hallo Leute,

ich hoffe ich bin im richtigen Forum gelandet....

Ich habe noch nie mit Perl gearbeitet, brauche nun aber einen simplen Fileserver unter Linux. Dazu habe ich ein Skript bekommen, was aber scheinbar noch Fehler enthält. Da ich nicht genau weiß wo, poste ich mal das ganze Skript, es ist nicht besonders umfangreich:
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#!/usr/bin/perl
#
# in.flashpolicyd.pl
# Simple socket policy file server
#
# Usage: in.flashpolicyd.pl -file=FILE
# Logs to stderr
#

use strict;

my $NULLBYTE = pack( 'c', 0 );

my $filePath;
my $content;

### READ ARGS

while ( my $arg = shift @ARGV )
{
    if ( $arg =~ m/^--file=(.*)/ )
    {
        $filePath = $1;
    }
}

unless ( $filePath )
{
    die "Usage: in.flashpolicyd.pl --file=FILE\n";
}

### READ FILE

-f $filePath or die "No such file: '$filePath'\n";
-s $filePath < 10_000 or die "File probably too large to be a policy file: '$filePath'\n";

local $/ = undef;
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
$content = <POLICYFILE>;
close POLICYFILE;

$content =~ m/cross-domain-policy/ or die "Not a valid policy file: '$filePath'\n";

### HANDLE CONNECTIONS

local $/ = $NULLBYTE;
my $request = <STDIN>;
chomp $request;

if ( $request eq '<policy-file-request/>' )
{
        print STDERR "Valid request received\n";
}
else
{
        print STDERR "Unrecognized request: $request\n\n";
        exit;
}

print STDOUT $content;

print STDERR "Sent policy file\n\n";

# End of file.


Wen es näher interessiert: das Skript kommt von Adobe und ist Teil einer neuen Sicherheitsarchitektur für Flash Socket Verbindungen. (siehe http://www.adobe.com/devnet/flashplayer/articles/s... )

Das ganze soll über den xinetd laufen.

Wenn ich nun testweise in der console dieses eingebe:
Code: (dl )
echo '<policy-file-request/>' | /usr/local/sbin/in.flashpolicyd.pl --file=/stuff/flashpolicy.xml

sagt das Skript
Code: (dl )
Unrecognized request: <policy-file-request/>

genauso wenn ich '<policy-file-request/>0' oder '<policy-file-request/>\0' reingebe.

Da ich mich mit Perl wie gesagt nicht weiter auskenne weiß ich nun nicht, wo ich nach Fehlern suchen kann. Stimmt etwas mit dem String-Vergleich nicht?
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13

local $/ = $NULLBYTE;
my $request = <STDIN>;
chomp $request;

if ( $request eq '<policy-file-request/>' )
{
        print STDERR "Valid request received\n";
}
else
{
        print STDERR "Unrecognized request: $request\n\n";
        exit;
}

ist doch eigentlich ziemlich straight forward, und ich würde denken dass ein Input-String ohne Nullbyte am Ende trotzdem die Bedingung erfüllen müsste und als valider Request erkannt werden sollte. Dem scheint aber nicht so zu sein, genauso wie \0 am Ende nichts ändert.

Kann jemand helfen?

Gruß,
Hendrik
renee
 2008-05-05 17:18
#109209 #109209
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
chomp entfernt das was in $/ steht. Du hast da das Nullbyte drin gespeichert, aber das ist nicht das Zeilenendenzeichen.

Du vergleichst als if ( "<policy-file-request/>\n" eq '<policy-file-request/>' ) und das ist immer false!

Du solltest die Zeilen 37-40 in einen Block packen, also
Code (perl): (dl )
1
2
3
4
5
6

{
    local $/ = undef;
    open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
    $content = <POLICYFILE>;
    close POLICYFILE;
}


Damit gilt die locale Änderung von $/ nur in diesem Block und danach ist da wieder der ursprüngliche Wert drin gespeichert. Und die Zeile 46 solltest Du komplett rausnehmen!
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
blemmo
 2008-05-05 18:19
#109214 #109214
User since
2008-05-05
3 Artikel
BenutzerIn
[default_avatar]
Hallo,

ok, nach den Änderungen bekomme ich beim lokalen Test ein XML ausgeliefert. Vielen Dank für den Tip!

Allerdings klappt das nur lokal. Im Browser (also in der Flashanwendung) gibt es nur Timeouts, und im xinetd Log steht
Code: (dl )
1
2
3
4
5
6
08/5/5@16:02:24: START: flashpolicy from=xxx.xxx.xxx.xxx
08/5/5@16:06:44: EXIT: flashpolicy status=0 duration=260(sec)
08/5/5@16:08:04: START: flashpolicy from=xxx.xxx.xxx.xxx
08/5/5@16:08:50: EXIT: flashpolicy status=0 duration=46(sec)
08/5/5@16:10:06: START: flashpolicy from=xxx.xxx.xxx.xxx
08/5/5@16:11:10: START: flashpolicy from=xxx.xxx.xxx.xxx


Das sind natürlich viel zu lange Zeiten.

Soviel ich weiß werden die Socket-Nachrichten von Flash mit dem Nullbyte terminiert. Kann es sein dass durch das Entfernen der Zeile 46 nun die Anfragen aus dem Browser nicht mehr als valide Requests erkannt werden?

Edit: Bei ungültigen Requests würde ja das Skript abbrechen, und es käme nicht zu Timeouts. Also liegt es vielleicht eher an der Auslieferung der XML.
Code (perl): (dl )
print STDOUT $content;

Wird hierbei irgendein Terminierungsbyte gesendet? Evtl. wartet Flash auf das Nullbyte am Ende der Message, bekommt aber keins?
Dubu
 2008-05-07 00:41
#109305 #109305
User since
2003-08-04
2145 Artikel
ModeratorIn + EditorIn

user image
Läuft denn das ursprüngliche Skript im xinetd nicht?
Was funktioniert nicht? Fehlermeldung?

Die Änderung von renee ("Zeile 46 komplett rausnehmen") sorgt ja nur dafür, dass das Skript mit deinem Kommandozeilen-Test funktioniert, weil du da kein Nullbyte als Terminator hin bekommst.

Und wenn du deinen Test auf der Kommandozeile unbedingt machen möchtest, nimm Perl, dann klappt's auch mit dem Nullbyte:
Code: (dl )
perl -e 'print "<policy-file-request/>\0"' | /usr/local/sbin/in.flashpolicyd.pl --file=/stuff/flashpolicy.xml
blemmo
 2008-05-07 00:56
#109308 #109308
User since
2008-05-05
3 Artikel
BenutzerIn
[default_avatar]
Ok, ich bin wieder zurück zur Ausgangsversion gegangen, da die Request ja letztlich alle über Sockets kommen und NULL terminiert sind. Das passt auch soweit, ich habe ein paar Logausgaben eingefügt und sehe, dass der Request erkannt wird und das XML ausgeliefert wird.
Allerdings beschwert sich Flash immernoch über 'malformed XML'. Dabei beschwert es sich nur, wenn das Skript über xinetd gesteuert wird. Im Paket von Adobe ist auch ein standalone Serverskript, was im Prinzip identisch ist, eben nur direkt mit Sockets arbeitet, während das xinetd Skript mit STDIN und STDOUT arbeitet. Mit dem standalone Skript und der gleichen XML Datei ist Flash glücklich.
Also scheint mir durch xinetd da noch irgendwas gemacht zu werden, wodurch Flash das XML nicht mehr mag. Ich habe leider keinen Schimmer, wie ich das prüfen könnte.
nepos
 2008-05-07 10:29
#109322 #109322
User since
2005-08-17
1420 Artikel
BenutzerIn
[Homepage] [default_avatar]
Du könntest dich mal mit tcpdump/wireshark ranklemmen und ansehen, was da genau in Richtung Flash übertragen wird. Eventuell sind da irgendwelche Steuerzeichen mit drin oder sowas.
Gast Gast
 2008-05-11 14:49
#109569 #109569
Ok, wireshark hat mir gezeigt was das Problem war: der xinetd ist wohl so konfiguriert, dass die Ausgaben nach STDERR genauso an den Socket gesendet werden wie STDOUT. Dadurch waren alle debug-Infos ("valid request") bei der XML-Data dabei. Klar dass Flash das nicht mochte, und dass nix in den Logs zu finden war... *d'oh*

Naja, jetzt weiß ich warum Adobe schreibt dass die Skripts nicht für den produktiven Einsatz geeignet sind...

Danke für die Hilfe!
<< >> 7 Einträge, 1 Seite



View all threads created 2008-05-05 17:11.