Eine “schöne” Stolperfalle, wenn Projekte aus einer Windows- in eine Unix-Umgebung geschoben werden, sind die Tabellennamen in MySQL. Egal, ob die Tabelle unter dem Namen “Kosten”, “kosten” oder “Kosten” angelegt wurde, unter Windows ignoriert ein Statement wie
SELECT * FROM kOsTeN;
jegliche Groß- und Kleinschreibung und liefert die selektierten Zeilen, während MySQL unter Unix in einen Fehler läuft.
Manchmal sucht man Fehler, die eigentlich gar keine sind - deshalb ist der entscheidende Hinweis aus der PHP-Dokumentation auch nochmal hier dupliziert:
Das Format ist ähnlich zur PATH-Umgebungsvariablen des jeweiligen Systems: Eine Liste von Verzeichnissen, getrennt durch einen Doppelpunkt unter Unix oder ein Semikolon unter Windows.
Nein, einfach kopieren zwischen verschiedenen Betriebssystemen geht nicht!
Um mittels PERL einen Remoteprozess auf einem entfernten Windows-Rechner zu starten, gibt es mehrere Alternativen:
Eine Möglichkeit ist die Verwendung von “PsExec.exe” aus der PsTools-Suite von Microsoft, die allerdings den Nachteil hat, daß über einen “system”-Call ein externes Programm aufgerufen wird und die Einfluss- und Kontrollmöglichkeiten sehr beschränkt sind.
Soll der Start in PERL durchgeführt werden, so ist zwischen zwei Anwendungsszenarien zu unterscheiden:
Sofern lediglich unter dem Kontext des aufrufenden Benutzers ein Prozess gestartet werden soll, reichen 2 Zeilen PERL-Code (aus Gründen der Übersichtlichkeit wurde auf Fehlerbehandlung verzichtet):
use strict;
use warnings;
use Win32::OLE;
my $remoteHost = 'myHost';
my $remoteCmd = 'c:\windows\notepad.exe';
my $wmi = Win32::OLE->GetObject("winmgmts:{ImpersonationLevel=Impersonate,(security)}//$remoteHost\\root\\cimv2:Win32_Process");
$wmi->Create($remoteCmd);
Weitaus flexibler ist hingegen die Möglichkeit, den Prozess unter einem anderen Benutzer zu starten und ggf. auch noch auf Daten eines weiteren Rechners zugreifen zu lassen:
use strict;
use warnings;
use Win32::OLE;
use Win32::OLE::Variant;
my $remoteDomain= 'myDomain';
my $remoteHost = 'myHost';
my $remoteUser = 'myDomain\myUser';
my $remotePwd = 'myPassword';
my $remoteCmd = 'c:\windows\notepad.exe';
my $locator = Win32::OLE->new('WbemScripting.SWbemLocator');
my $service = $locator->ConnectServer($remoteHost, 'root\cimv2', $remoteUser, $remotePwd, 'MS_409', "kerberos:$remoteDomain\\$remoteHost");
$service->{Security_}->{AuthenticationLevel} = 6; # PktPrivacy
$service->{Security_}->{ImpersonationLevel} = 4; # Delegate
my $process = $service->Get('Win32_Process');
my $vPid = Variant(VT_I4 | VT_BYREF, 0);
$process->Create($remoteCmd, undef, undef, $vPid);
print "process running - pid: $vPid\n";
Beim Remotehost ist darauf zu achten, daß der tatsächliche Rechnername und kein DNS-Alias verwendet wird da sonst der Verbindungsaufbau mit dem Fehler 0x800706ba “Der RPC-Server ist nicht verfügbar” scheitert.
Sofern tatsächlich im Rahmen des Remoteaufrufs ein dritter Rechner miteinbezogen werden soll, sind hierbei einige Einschränkungen zu beachten, wie der TechNet-Artikel “Geheimnisse von Windows Management Instrumentation” erklärt:
Wenn ein Clientcomputer (Computer A) Anmeldeinformationen für die Domäne von einem Remoteserver (Computer B) an einen dritten Computer (Computer C) weiterleiten muss, ist Delegierung erforderlich. Dies trifft zu, wenn zwei oder mehr Netzwerkhops für einen bestimmten Vorgang ausgeführt werden müssen. Ohne Delegierung kann Computer B keine von Computer A empfangenen Anmeldeinformationen weiterleiten; deshalb schlägt die Verbindung mit Computer C fehl.
Die genauen Schritte zur Einrichtung der Delegierung sowie ein vbs-Skript zum Testen des Aufrufs sind in dem Artikel erläutert.
Wichtig ist der Hinweis, dass zur erfolgreichen Durchführung die Delegierung für Computer B in Active Directory aktiviert werden muss. Hierzu ist in den Eigenschaften des Computer-Kontos im Active Directory die Option “Computer für Delegierungszwecke vertrauen” zu aktivieren, ansonsten scheitert der Aufruf mit dem Fehler 0x80070721: “Fehler im Sicherheitspaket”.
Literaturhinweise:
Die Funktionalität von stripClip, einem kleinen Utility zum Entfernen von Textformatierungen aus der Zwischenablage lässt sich - sofern sowieso ein Perl-Interpreter installiert ist - auch mit wenigen Zeilen Perl-Code realisieren:
use warnings;
use strict;
use Win32::Clipboard;
my($text);
my $clip = Win32::Clipboard();
do {
$clip->WaitForChange();
if ($clip->IsText()) {
$text = $clip->GetText();
$clip->Set($text);
}
} while ($text ne ':q');
Startet man das Skript mit ‘wperl.exe’ statt mit ‘perl.exe’, stört kein Fentser und das Skript lässt sich ohne Taskmanager durch Kopieren von ‘:q’ beenden.
Ein logischer Grund ist nicht ersichtlich, aber während der “Geplante Task” beim Aufruf
c:\perl\bin\wperl.exe c:\meinskript.pl tollerparameter
den tollen Parameter ans Skript weiterreicht, wird mittels
c:\meinskript.pl tollerparameter
zwar das Skript aufgerufen, der Parameter kommt aber nicht an.