expect integrieren

[Silent-Tears]

Oh, es gibt sicherlich genug, die das wollen. Ich fahre meine Rechner zu Hause ja auch manchmal per SSH runter, und kann sie per WOL aufwecken. Wieso sollten die Normalwindowsuser das nicht auch gern wollen? Wobei ich dafür bin, sie nutzen dann gleich Linux/Unix, wenn sie die entsprechenden Features doch wollen.

 

[s3th*]

nuja gut, jemand der sich nen freetz-image zusammenschustern kann, ist für mich nicht wirklich nen normalwindowsuser, so meinte ich das =)

 

[Silent-Tears]

Oh doch, da gibt es wirklich einige, da wir Freetz im Laufe der Zeit wirklich kinderliecht bekommen haben, und sich sogar schon fertige Images in irgendwelchen ULCs finden....

 

[s3th*]

stimmt auch wieder

 

[cando]

Am Einfachsten wäre es, wenn man die SMB Nachrichten für Windows erzeugen könnte, dann muss man gar nichts in Windows installieren. Es ist eine vorhandene Schnittstelle.

Nun die Frage an die Linuxer: wie kann man ein SMB Datagramm in Linux erzeugen? In Windows ist das recht einfach unter Benutzung der vorhandenen Bibliotheken.

Das Protokoll kann man ja per Netmon / Sniffer mitschneiden, wenn man das shutdown kommando auf ein Windows Host losläßt.

 

[RalfFriedl]

Freetz im Laufe der Zeit wirklich kinderliecht bekommen haben

Und trotzdem gibt es da "Experten" ...

wie kann man ein SMB Datagramm in Linux erzeugen?

Reicht wirklich ein Datagramm? Kennst Du den genauen Inhalt?
Ansonsten kann man das mit Samba machen. Wenn man den Platz dafür hat. Das ist vermutlich die einfachste Lösung.

 

[s3th*]

da könnte man aber wiederum das problem bekommen, das man wie ich, auf ner 7050 keinen platz für samba hat (bei welchem expect integriert ist).

so fing die schweinerei bei mir naemlich an =)

 

[cando]

Mit SAMBA ganz einfach:

net rpc shutdown -I IPADDRESS -U USERNAME%PASSWORD

Shutdown Windows from Linux using SAMBA

Man braucht aber das samba-common Paket auf der Box. Von Ubuntu hab ich das mal getestet - funktioniert sehr gut, sogar mit 30s. Vorwarnung an angemeldete User.

 

[s3th*]

wie es mit samba geht, war mir zB auch klar..problem war/ist aber das samba nicht auf die box passt

 

[RalfFriedl]

Wenn Du aus dem Samba-Programm oder aus sonstigen Quellen herausbekommst, was hier gesendet werden muß, kann man auch ein Programm erstellen, das nur das Shutdown unterstützt und somit deutlich kleiner sein könnte.

 

[cando]

Es ist ein RPC Aufruf (remote procedure call) der Funktion shutdown auf dem Windows Rechner mit named parameter an die Maschine / IP Adresse (-i), User%Password (-u), es gibt weitere Parameter für Delay (-t) und Meldung (-c) oder auch anschließendem Reboot (-r).

Also viel Spass beim Erforschen...

 

[s3th*]

ha..muss mich mal eben korrigieren. expect ist in samba nicht integriert, aber net, bzw net rpc ist leider nur unter verwendung von samba möglich, lässt sich also nicht einzeln installieren, deshalb mein umweg über telnet mit expect, oder eben jetzt ohne

 

[cando]

Es gibt auch eine Linux rpc Bibliothek, die man nutzen/strippen könnte:

man rpc

Ich weiss aber nicht, was die an Platz verbraucht.

Alternativ könnte man vielleicht da was herausbauen:

man rpcclient

 

[trinkfix]

wenn ich meine Windowskiste per WoL aufgeweckt habe connecte ich immer per RDP (Remotedesktop), der ist doch auch auf so ziemlich jeder Windowskiste installiert und da kann man auch ganz normal die Kiste wieder ausschalten.

viele Grüße
trinkfix

 

[RalfFriedl]

RPC (Remote Procedure Call)für sich allein ist ein sehr allgemeiner Begriff. Es würde mich sehr wundern, wenn Windows RPC zu dem von Dir genannten UNIX RPC kompatibel ist. Übrigens wird dieses RPC bereits für NFS verwendet.

rpcclient gehört zu Samba, da kann man auch gleich das net-Programm von Smaba verwenden.

 

[cando]

RPC ist ein offener Standard, der von MS übernommen und aufgebohrt wurde. Neben den im Unix üblichen Transportprotokollen tcp und udp hat MS den Named Pipes Transport / SMB implementiert und nutzt den excessiv. Unix / BSD Systeme haben das bislang nicht implementiert und bezeichnen die RPC von MS als proprietäre Technologie - was so nicht richtig ist.

Durch den Druck der Interoperabilität mit Windows - um sich nicht selbst ins Aus zu schiessen - hat man dann bei OSF und NOVELL eine Implementierung der named pipes Transportschicht für RPC in Linux / Unix gemacht - speziell um die Novell Directory Services in AD von MS zu integrieren. Später sind diese Entwicklungen in das SAMBA Paket eingeflossen und der idl compiler von SAMBA ist mittlerweile vollständig zum MS idl compiler midl compatibel. Es gibt weitere Transportschichten, wie z.B. SOAP über http(s) etc.

Die Funktionsweise von RPC bei MS und bei SUN / Linux / BSD ist die gleiche - es ist der offene Standard.

History of MS RPC and open source equivalents

 

[RalfFriedl]

Die Funktionsweise ist die gleiche, aber bist Du sicher, daß auch die Details die gleichen sind?
NFS gab es schon vor 1990. Es würde bedeuten, daß MS von Anfang an sind an den Standard von Sun hätte halten müssen, lange bevor es AD gab.

Daß der IDL-Compiler von Samba zu dem von MS kompatibel ist, heißt nicht, daß der IDL-Compiler von Samba zum IDL-Compiler von SUN kompatibel ist.

 

[cando]

Inwieweit SUN sich nun vom ursprünglichen RPC entfernt hat kann ich nicht beurteilen. Ich weiss nur, das SAP, Oracle & Co mit ihren Business Suiten über RPC plattformübergreifend sowohl auf SUN, als auch auf Windows Server interoperabel sind.

Windows NT / XP / 7 etc. haben RPC ja als Basistechnologie unter der Oberfläche - zunächst mit NetBUI und später NBT, Windows geht immer weiter in Richtung TCP/IP und weg vom NetBIOS, NamedPipes sind aber nach wie vor als Standard Schnittstellen für RPC drin. Ich gehe mal davon aus, das MS die RPC Technologie am weitesten ausgereizt hat - während SUN auf einem relativ alten Stand mit festen Ports pro Dienst in der Entwicklung stehen geblieben ist.

Die Grundstruktur im Aufruf / Parameterübergabe und Protokollstruktur scheint aber weitestgehend compatibel zu sein.

 

[RalfFriedl]

Das ursprüngliche UNIX-RPC stammt von SUN, also kann man nicht sagen, Sun hätte sich davon wegbewegt. Irgendwie paßt es aber nicht zum Bild von MS, daß sie schon zu Zeiten von NetBUI das RPC von Sun/UNIX übernommen hätten, statt etwas eigenes zu machen.

Im Sun-RPC war noch nie für einen Dienst ein fester Port vorgegeben, außer für den Portmapper, der dafür zuständig ist, den Port zu finden, auf dem der gesuchte Dienst läuft.

Die Grundstruktur ist ähnlich, weil die Funktionsweise ähnlich ist. Aber das heißt nicht, daß die Details auch nur ähnlich sind, geschweige denn identisch.

 

[cando]

MS hat Teile der VMS Entwicklermannschaft abgeworben, um NT zu entwickeln. So ist der RPC zu MS gekommen. (Es gibt auch die hartnäckige Sage, dass VMS + 1 = WNT ist: V->W, M->N, S->T es sollte die nächste Generation von VMS werden). Deshalb war auch von Anfang an das POSIX Subsystem Bestandteil von Windows NT.

Was die ports betrifft:

/etc/services ist die Datei für die registrierten RPC Dienste. (bei Sun, bei Microsoft entsprechend : c:/winnt/system32/drivers/etc/services)

Die MS-RPC Implementierung stammt von DCE-OSF RFC (Distrbuted Computing Environment 1.1 von der Open Software Foundation), unterstützt von Apollo, DEC, HP...

Das SUN-RPC (ONC-RPC), das in Unix Systemen Anwendung findet, stammt ursprünglich von SUN, weil sie ein leichtgewichtiges RPC System, dass parallel zur OSF RFC entwickelt wurde und außerhalb von SUN / NFS wenig Verwendung für verteilte plattformübergreifende Integration findet. Das DCE / CORBA / SOAP findet für diese Zwecke eher Verwendung und ist plattformübergreifend verfügbar.

Da hat MS mal ausnahmsweise einen offenen Standard implementiert.