Installation opsi-deploy-client-agent

[uncle_scrooge]

Grummel. Wenn man schon Ratschläge absondert, sollte man sie vorher testen.

Habe jetzt auf die Schnelle auch keine Möglichkeit gefunden, dem Installskript eine IP-Adresse unterzujubeln.

Bitte mal die Versionsnummer(n) von winexe posten.
Einmal ./winexe ohne Parameter aufrufen. In der ersten Zeile steht die Versionsnummer (bei mir 0.90).
Dann ./winexe -V (gibt bei mir 4.0.0tp4-SVN-build-10231).

'/winexe --user YourUser --password=YourPass //10.3.50.9 ipconfig
sollte die IP-Konfiguration Deines Clients auf der OPSI-Serverkonsole ausgeben.
Funktioniert das?

>>Telnet funktioniert 100%, wir nutzen Telnet um von allen Standorten auf unserer TK-Anlage zu kommen.
Das ist schön, aber hier nicht relevant. Mit dem weiter oben geposteten Aufruf telnet PC841 445 baust Du eine Verbindung über Port 445 und nicht den Standardport 23 auf.

Gruß
Peter

[isnoguter]

Die winexe ist identisch.

Code: Alles auswählen

user@opsi:/var/lib/opsi/depot/opsi-client-agent$ ./winexe
winexe version 0.90

user@opsi:/var/lib/opsi/depot/opsi-client-agent$ ./winexe -V
Version 4.0.0tp4-SVN-build-10231

Die IP-Konfiguration wird auch ausgegeben.

Code: Alles auswählen

user@opsi:/var/lib/opsi/depot/opsi-client-agent$ ./winexe --user domain.de\\user --password=p@ssw0rd //10.3.50.9 ipconfig
dos charset 'CP850' unavailable - using ASCII

Windows-IP-Konfiguration


Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: domain.de
   IPv4-Adresse  . . . . . . . . . . : 10.3.50.9
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : 10.3.101.1

Tunneladapter isatap.domain.de:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: domain.de

Ich habe auch nochmal zwecks Routing und Firewall nachgehakt. Auf unserern Standleitungen ist alles frei und offen außer Multicast.

[uncle_scrooge]

OK, winexe war wohl ein Holzweg.
Bleibt noch smbclient (wird ebenfalls im deploy script genutzt).

Bitte mal auf dem Client eine Freigabe anlegen. Berechtigungen: Jeder darf alles. (Nur zum spielen.)
Dann auf dem OPSi-Server in das Verzeichnis mit dem deploy script gehen.
./smbclient //<IP-Adresse>/<Freigabename> -U <Benutzer> absetzen.
Am Prompt Passwort eingeben.
Jetzt solltest Du auf der Konsole so etwas sehen: smb: \>
Hier bitte nacheinander
prompt (stellt Nachfragen ab)
recurse (kopiert rekursiv)
mput files (kopiert den Unterordner files auf deine Freigabe)
absetzen.
Funktioniert das?

Und, welche Bandbreite haben eure WAN-Verbindungen. Wie ist die Auslastung?
smbclient hat(te) wohl Probleme mit langsamen Verbindungen. (Da sprach man allerdings von ISDN-Niveau.)

[koepkek]

Hi

Deine Domäne heißt wirklich damain.de. Oft gibt es Probleme mit dem domain-Admin Account. Um diesen Fehler auszuschließen würde ich ein Passwort für den localen Administrator auf dem Client vergeben und es mit diesem Versuchen. Dann mit -u administrator (ohne Domain Angabe).

Bin gespannt

Gruß Karsten

[isnoguter]

Zur Abwechslung mal ein Client an Standort 2 und als User der lokale Administrator.

Code: Alles auswählen

user@opsi:/var/lib/opsi/depot/opsi-client-agent$ smbclient //10.2.50.1/opsitest -U Administrator
Enter Administrator's password:
Domain=[DOMAIN] OS=[Windows 7 Professional 7601 Service Pack 1] Server=[Windows 7 Professional 6.1]
smb: \> prompt
smb: \> recurse
smb: \> mput files
putting file files/opsi/opsiloginblocker.reg as \files\opsi\opsiloginblocker.reg (43,6 kb/s) (average 43,6 kb/s)
putting file files/opsi/update.ins as \files\opsi\update.ins (1191,1 kb/s) (average 273,1 kb/s)
putting file files/opsi/OpsiLoginBlocker/64bit/OpsiLoginBlocker.dll as \files\opsi\OpsiLoginBlocker\64bit\OpsiLoginBlocker.dll (6531,9 kb/s) (average 3654,3 kb/s)
putting file files/opsi/OpsiLoginBlocker/timeouts.reg as \files\opsi\OpsiLoginBlocker\timeouts.reg (106,4 kb/s) (average 3425,4 kb/s)
...

Die Standleitungen haben alle 100 Mbit

Die Domäne heißt nicht domain.de, ich habe die Daten nur anonymisiert.

Als lokaler Administrator bekomme ich den selben Fehler.

Ich habe mir gerade das Log von einen Client an Standort 1 angesehen und einen Client an Standort 3 verglichen.

Der Unterschied beginnt damit das die MAC-Adresse an Standort 3 nicht gefunden wird. Das funktioniert soweit ich das Skript verstehe mit dem Programm ip2mac.exe. Die Frage ist warum wird die MAC-Adresse schon nicht gefunden? Zu diesem Zeitpunkt des Skripts wurde so wie ich das verstehe auch noch nichts auf den Client kopiert.

funktioniert nicht:

Code: Alles auswählen

[warning] Failed to get hardware ethernet address for host 'pc841'
[notice] Creating client 'pc841.domain.de'
[info] Creating host '<OpsiClient id 'pc841.domain.de'>'
[notice] Testing winexe
[info] Executing: ./winexe -U 'domain.de\administrator%*** confidential ***' //pc841 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'
[info] Using encoding 'UTF-8'
[info] Winexe failure 'Command './winexe -U 'domain.de\administrator%*** confidential ***' //pc841 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'' failed (1):
ERROR: Failed to open connection - NT_STATUS_IO_TIMEOUT', retrying

funktioniert:

Code: Alles auswählen

[notice] Found hardware ethernet address '00:19:99:94:4b:ba'
[notice] Creating client 'pc628.domain.de'
[info] Creating host '<OpsiClient id 'pc628.domain.de'>'
[notice] Testing winexe
[info] Executing: ./winexe -U 'domain.de\administrator%*** confidential ***' //pc628 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'
[info] Using encoding 'UTF-8'
[notice] Patching config.ini
[info] Copying from 'files/opsi/cfg/config.ini' to '/tmp/0MHZrpYD9J_config.ini'
[info] Copy done
[notice] Copying installation files

[ueluekmen]

Hallo isnoguter,

Warum findet er die Mac-Addresse nicht?

Weil der Deploymechanismus den Client anpingt und danach die lokale ARP-Table des Servers ausliest. Sowas funktioniert aber normalerweise nur bis zum Router. Wenn das funktionieren würde, würde ich mir ehrlich gesagt ernsthaft Gedanken machen.

Bei Netzwerken kommt es auf die Richtung an. Wenn die Clients von draussen Zugriff auf den Samba-Share vom opsi-Server haben ist es gut, heißt aber nicht dass der umgekehrte Weg Zentrale -> Aussenstelle auch funktioniert. Kannst du von einem Windows-Client aus der Zentrale per Windows-Explorer auf \\client-fqfn\c$ zugreifen? Wenn nicht hoffe ich du kannst die Router konfigurieren oder kennst jemanden der das kann.

Bei so einer Umgebung sollte man nicht über einen Supportvertrag nachdenken, sondern man sollte schon einen abgeschlossen haben.
Ansonsten verliert man unnötig viel Zeit beim lösen von Problemen, die wir fast täglich lösen müssen.

Achja, das Telnet in Klartext übertragen wird ist euch aber bewusst oder? (Nur zur Sicherheit: Zur heutigen Zeit muss man auch auf solche Dinge immer wieder hinweisen.)

[isnoguter]

Kannst du von einem Windows-Client aus der Zentrale per Windows-Explorer auf \\client-fqfn\c$ zugreifen?

Ja das funktioniert.

Bei so einer Umgebung sollte man nicht über einen Supportvertrag nachdenken, sondern man sollte schon einen abgeschlossen haben.

Wird dieses Jahr passieren, genauso wie ich endlich das MySQL-Backend nutzen will.

Achja, das Telnet in Klartext übertragen wird ist euch aber bewusst oder?

Ja, über Telnet passiert nichts kritisches.

[uncle_scrooge]

Erst mal sorry für mein unqualifiziertes Rumgeeiere. Man sollte solche Themen nicht zwischen Tür und Angel angehen.
Nachdem ich mir das Skript und Deine Logs noch mal angesehen habe, steigt er wohl doch wirklich bei winexe aus. Meine Idee mit smbclient können wir wohl streichen.
Soweit, so schlecht.
Auf der anderen Seite konntest Du nachweislich (über IP-Adresse) eine Verbindung per winexe zum Client aufbauen.

Setzt Du bitte folgendes noch mal ab. (Clientadresse erst als IP, dann Hostname, dann FQDN. User jeweils als lokaler Benutzer und als Domänenbenutzer.)

./winexe -U '<YourUser>%<YourPass>' //<YourClient> 'cmd.exe /C "del /s /q c:\tmp\opsi-client-agent_inst && rmdir /s /q c:\tmp\opsi-client-agent_inst || echo not found"'

[n.wenselowski]

Hallo,

sofern ich mich erinnere klappt der Deploy über IP noch nicht.
Ich bin gerade an dem Script und werde mal versuchen das auch möglich zu machen.

Gruß

Niko

[ueluekmen]

Soooo....

Kannst du von einem Windows-Client aus der Zentrale per Windows-Explorer auf \\client-fqfn\c$ zugreifen?

Ja das funktioniert.

Funktioniert das auch wenn du per Windows-Explorer auf \\client-hostname\c$ ????

Achtung ich meine hier in deinem Fall einfach \\pc841\c$. Vielleicht ist es auch einfach ein netbios-Problem, was im übrigen über Routergrenzen auch nicht funktionieren sollte. FQDN und Netbios sind ja bekanntlich auch nicht das selbe.