forum.opsi.org

Hi,

ich habe schon häufiger OPSI evaluiert (das erste mal 2008 zu Beginn meiner Ausbildung) damals ist das Projekt leider gescheitert wegen dem damaligen PreloginLoader der leider sehr sehr langsam war. Seit dem der normale neue Client verfügbar ist habe ich weitere Versuche unternommen das Projekt OPSI wieder aufzuheizen wieder ohne Erfolg und wieder war der Grund eine zu starke Bootverzögerung.

Später habe ich dann (dieses Jahr) Konkurrenz Produkte wie Microsoft SystemCenter Configuration Manager und Dell Kace evaluiert. Auch diese Projekte sind gescheitert. Bei beiden gab es zwar keine spürbare Bootverzögerung, jedoch war es auf der Management Oberfläche einfach zu unübersichtlich und das einfach Unpraktisch => ebenfalls gestorben.

Ich schlug darauf hin vor OPSI noch einmal eine Chance zu geben. Dieses mal stand ich nicht alleine sondern wir haben uns zu 3. auf das Projekt gestützt. Opsi Installiert (hatte ich nun ja schon mind. 5x vorher gemacht) alles kein Problem. Ja das Projekt geht voran und vom Grundlegenden gefällt OPSI sehr. Das Konzept mit WINST als Scriptsprache ist sehr gut und Pakete lassen sich relativ einfach schnüren.

Nun sind wir wieder an der Stelle das der OPSI Client den Bootvorgang um 30 Sekunden verzögert (oder mehr). Das liegt natürlich einmal daran das er auf die Netzwerkschnittstelle warten muss (Windows 7 lässt standardmäßig ein LogIn ja schon zu bevor das Netzwerk überhaupt verfügbar ist) das lässt sich nicht ändern was ja logisch ist.
Mir will jedoch nicht ganz in den Kopf warum der Client anschließen noch weitere 20 Sekunden braucht um festzustellen das er eigentlich nichts zu tun hat.

Habt ihr mal gemessen wie lange der Client benötigt bei euch? Wie lange verzögert er bei euch den Start?

Über Antworten würde ich mich sehr freuen


Gruß
Tobias

Moinsens,

ich kann Deine Erfahrungen grundstäzlich nicht bestätigen. Auch nicht bei den wenigen Windows 7-PCs im Netzwerk (wir nutzen aber noch überwiegend XP).

Natürlich gibt es gewisse Verzögerungen beim Booten, schon allein durch dieTatsache, dass PXE vor der Festplatte geschaltet ist und hier erst IP-Adresse und TFTP-Server abgefragt werden. Dann durch das kurzfristige Erscheinen des kleinen Bootmenüs und schließlich natürlich im hochgefahrenen Zustand durch das vor dem Login-Fenster geschaltete opsi. Ich habe aber in unserem Netzwerk nur bei fehlerhafter Konfiguration eine so extreme Verzögerung von 30 Sekunden und mehr feststellen müssen.

Bei einwandfreier Konfiguration zeigt sich der Opsi-Bildschirm, man sieht wie sich der Client mit dem Opsi-Server verbindet, das dauert ca 3-4 Sekunden, findet i.d.R. keine Aufträge und gibt den Anmeldebildschirm frei. Alles in allem konnte ich vom Einschalten des PCs bis zur Anmeldemaske eine Verzögerung von ca 15 Sekunden messen, bedingt durch die oben beschriebenen Verfahren, die sich aber nicht anders bewerkstelligen lassen. Fairerweise muss man den Bootvorgang abziehen und auch die Vorschaltung des PXE, denn auch in unserem 2. Firmennetzwerk, welches ausschließlich mit Windows-Produkten gearbeitet wird, also auch RIS &Co. werden die Rechner mit vorgeschaltetem PXE gestartet, weil sie sich aus Sicherheitsgründen eine IP vor dem Booten des Rechners geholt haben *müssen* sonst funktionieren sie nicht im Netz (wieso? Keine Ahnung, was die da von unserer ServiceEinheit gefummelt haben)!

Diese Verzögerung ist aber im Verhältnis zur Zeitersparnis bei Einzelinstallationen verschmerzbar, denn kein Anwender sitzt wie auf Kohlen vor seinem Rechner und kann's kaum erwarten endlich anfangen zu können, auch in der freien Wirtschaft nicht.

Wenn der Opsi-Bildschirm bei Euch also - wie ich es verstanden habe - tatsächlich die 30 Sekunden auf dem Bildschirm zu sehen ist, würde ich aus meinen Erfahrungen heraus auf einen Konfigurationsfehler tippen, die ich reichlich gemacht habe. Das fing bei einen fehlerhaft konfigurierten Netzwerk an und endete bei fehlerhaft konfigurierten Windows-Rechnern. Ich meinte immer, viel zu wissen, die Jungs von UIB haben mir (leider immernoch ohne den Lehrgang) mit ihrem Opsi-System gezeigt, wo ich entweder massiv geschludert (jaja... Klickibunti-User) habe oder eben das Wissen nicht da war.

Inzwischen läuft Opsi und wir installieren einen Rechner mit XP und Anwendungen innerhalb von ca 1,5 Stunden ohne dass wir dabeisitzen. Effektiv eingesetzte menschliche Arbeit. ca 10 Minuten (DHCP-Eintrag, Eintrag in Opsi, Mausklicks, Registriercode eintragen, BIOS auf PXE-Boot ändern, WOL einschalten, Rechner booten und Opsi seine Arbeit machen lassen).
Aktualisierungen wie momentan bei Firefox und seinen schnell wechselnden Versionsnummern kosten und keine 5 Minuten, Rechner auswählen, Produkt auswählen, "On Demand"-Installation auslösen. Das Neupacken des Softwarepakets hier nicht eingerechnet. Da wir aber die Pakete im Rohzustand auch vorhalten, ist es lediglich ein Austausch der alten Setup-Version gegen die neue und ein Neupacken / Neuinstallieren des Pakets.

Wir nutzen Opsi immernoch als Kostenlos-Variante (leider, aber das liegt nicht in meiner Entscheidungsbefugnis). Wir haben kein Lizenzmanagement (mh... wäre auch bei 40 Rechnern verzichtbar, das kann man noch überblicken), keine Gruppierungsmöglichkeit und müssen warten bis all das Refinanziert ist. Was ich machen kann ist Unterstützung so gut es geht, auch hier und anderswo.

Opsi ist kein Eis am Stiel, ganz bestimmt nicht und man trifft immer wieder auf Probleme bis es dann endlich läuft. Aber - und das muss man den Leuten von UIB auch lassen: Bei den meisten Einrichtungs- und Installationsfragen können sie berechtigterweise immer wieder auf die Handbücher verweisen.

So... nun hab ich mehr Werbung für Opsi gemacht, als gut ist. Nun arbeiten die Leutchen von UIB den ganzen Tag nicht mehr...

Thomas_H

Hallo,
ich habe nie Probleme gehabt(auch mit preloginloader).
Wenn der OPSI Server erreichbar ist dauert es max 5 Sekunden.
Wenn der OPSI Server nicht erreichbar ist, der default timeout ist 30 Sekunden.

Du kannst folgendes versuchen:
- timeout zum Beispiel auf 5 Sekunden ändern
in /opt/pcbin/install/opsi-client-agent/files/opsi/cfg/config.ini "config_service.connection_timeout = 5"

- opsi-client-agent auf einem client neu ausrollen und testen
/opt/pcbin/install/opsi-client-agent/opsi-deploy-client-agent -u admin -p passwort testclient

Oder lokal auf einem Rechner testen
[config_service]
connection_timeout = 5
Service "opsiclientd" neu starten/Rechner neu starten

Im OPSI Fenster solltest du timeout 5s sehen

Hi,

danke für die Antworten. Ich habe das grade nochmal aufgeschlüsselt die Zeiten.

30 Sekunden benötigt der Rechner bist zur Windows GUI
18 Sekunden bist der Rechner Pingbar ist sprich die Netzwerkverbindung verfügbar ist

So weit ist das ganze normal und kann nicht verkürzt werden da es Betriebssystem seitig ist.

10 Sekunden benötigt anschließend (Schloss ist schon sichtbar) der OpsiClient bis er startet
10 Sekunden braucht der Client bis er festgestellt hat das er nichts zu tun hat

Die Opsigeschuldete Verzögerung beträgt also 20 Sekunden. Mich persönlich stört das nicht so sehr, aber leider ist sowas hier schon ein Grund das Projekt scheitern zu lassen.
Denn zusammen mit den 18 Sekunden bist zur Netzwerkverbindung ergeben sich mit Opsi eine Anmeldeverzögerung von 38 Sekunden.

Die Verbindung zwischen Client und Opsiserver scheint also zu funktionieren. der Timeout ist ohnehin sehr niedrig eingestellt - nach 2 Sekunden hat der Client die Verbindung schon.


Leider sitzen die Anwender hier vorm Rechner und warten ungeduldig bis sie sich anmelden können ob mans glaubt oder nicht

auch wenn es (persönliche Meinung) lächerlich ist auf den Komfort einer Software Verteilung deswegen zu verzichten, denn bisher werden Betriebssystem und auch Software per Hand von CD installiert ... die Verzögerung die dabei entsteht möchte ich gar nicht erst nennen.....

Moinsens...

naja, die Gegenrechnung (Gegenargumente) ist folgende:

* Keine Remote-Installationssoftware kommt ohne Verzögerung aus. Ein Client muss immer fragen, ob es etwas zu tun gibt.
* Das kostet Euch pro Arbeitsplatz rund 40 Sekunden bis der Rechner einsatzbereit ist. 40 Sekunden, in denen der Anwender mal aufschlüsseln kann, was er in 40 Sekunden tut / tun kann oder wie 40 Sekunden für die Erledigung seiner Arbeit ein Hinderungsgrund sind, da diese Verzögerung am Anfang seiner Arbeit steht.
* Bei 100 Rechnern im Netz bedeutet das eine Gesamtverzögerung von insgesamt 4000 Sekunden, die die Mitarbeiter pro Tag warten. Das bedeutet 100 Mitarbeiter verwarten pro Tag eine Stunde und 6 Minuten.
Dabei ist diese Berechnung unfair, weil ein Rechner immer Zeit zum Starten braucht.
* Ein Administrator braucht für die Aktualisierung einer Software durchschittlich pro Rechner 8 Minuten. Macht bei 100 Rechnern über 13 Stunden, um nur 1(!) Programm zu aktualisieren. Dabei nicht eingerechnet sind die Wege die er zurücklegen muss, um zu den Rechnern zu gelangen. 14 Stunden sind fast 2 Arbeitstage, 8:30 Stunden Arbeitszeit vorausgesetzt. Dabei führt er keine(!) andere Arbeit aus als die Rechner zu aktualisieren. Und dabei leistet er zwischendurch keinen Support und ist auch telefonisch nicht erreichbar, sonst hält er die 8 Minuten nicht ein.
* Wenn man alle 2-3 Tage ein Update irgendeiner Software ansetzt (ggf. die Updates des Betriebssystems) bedeutet das im Umkehrschluss, dass ein Administrator, der keinen Support leistet nur unterwegs ist, um die Rechner zu aktualisieren.
* Unterstellen wir dem Admin ein schmales Gehalt von nur 1300 Euro / Monat, stehen die 1300 Euro, die hier ohne die noch üblichen Sozialversicherungsabgaben des Arbeitgebers berechnet sind, in einem klaren Mißverhältnis zu den 30 unproduktiven Stunden der 100 Mitarbeiter in der Firma.

Frage ist also: was schaffen 100 Mitarbeiter im einzelnen innerhalb von 40 Sekunden, die ohne Rechner nicht zu bewerkstelligen sind?

Die Entscheidung über die Einführung einer solchen Software wie Opsi ist unter Abwägung der Für und Widers ganz klar Chefsache. Wenn Ihr natürlich für nur 3 Rechner Opsi einführen wollt, dann ist das in der Tat eher sinnlos. Ansonsten aber kann die Frage ob Mitarbeiter 20 oder 40 Sekunden auf den Rechner warten nicht der ausschlaggebende Punkt über die Einführung oder Nichteinführung eines RIS sein. Wenn Du in Deinen Entscheidungen als Admin dadurch derart eingeschränkt bist, solltest Du Dich fragen, ob Du in der Firma richtig bist, weil ein einwandfreier und störungsfreier Betrieb einer solchen Anlage im Wesentlichen von der Pflege und Wartung abhängt. Und hier muss Dir als Admin eine gewisse Freiheit gegeben sein, denn das Netzwerk und seine Schwächen kennst Du! Und DICH nimmt man in die Verantwortung wenn aufgrund einer mangelhaften Pflege und Wartung das System Schaden nimmt, weil Mitarbeiter in 20 Sekunden die Welt umdrehen wollen.

Gruß Thomas_H