WIKI: Bitte mal Artikel prüfen... :)

[philmills]

In WIKI page: wiki/userspace:howto_use_the_scripts_-_ ... escription
Remark from the forum, added by d.oertel:

Please correct command:
'opsi-setup --set-rights'

is written (wrongly) as:
'opsi-setup -set-rights'

[Thomas_H]

Moinsens,

thanks a lot. It happened because of formatting. I had it correct in the edit-mode, but when showing as webpage, the wiki converted a "--" to a "-". I placed the command in <code> now, and now the command will be shown correctly. It was also wrong in the german version.

Gruß

Thomas_H

[alsp]

Moin,
ich bin einer der Neulinge, an die sich dieser Artikel ja richtet. Im Moment evaluieren wir OPSI anhand der Getting Started. Beim Überprüfen der Skripte, die es für die von uns benötigten Produkte bereits gibt, bin ich an der entsprechenden Stelle im Wiki gelandet und habe das Howto gefunden. Es ist also schon etwas Vorwissen aus der Getting Started vorhanden, ich denke aber, dass das normal sein sollte. Ganz ohne Wissen dürfte man auch bis hierhin kaum kommen, selbst wenn man die VM benutzt. Ein paar Gedanken als Mitglied der Zielgruppe:

1. Die meisten, die ein Deployment in einem Windows-Umfeld umsetzen wollen, dürften aus selbigem kommen. Entsprechend bevorzuge ich es auch, weitestgehend unter Windows zu arbeiten. Die Getting Started empfiehlt ja ebenso einfach jedit (Muss ja nicht gleich notepad++ mit importierten Highlighting empfohlen werden) auf einem Windows-Client für die Bearbeitung der Skripte zu nutzen.
Eine kleine Anmerkung noch zum jedit: Wenn man das auf einem 64-Bit Windows 7 vom OPSI-Server aus installieren will, schlägt die Installation erst einmal fehl, weil die sich in Abhängigkeit installierende javavm Standardmäßig auf "system specific" steht und dann nur die 64-Bit-Version installiert. Offensichtlich brauch jedit aber unter 64-Bit sowohl die 32- als auch die 64-Bit Variante der javavm. Also auf "both" stellen. Sonst verzweifelt hier vielleicht auch ein Neuling.
2. Zumindest in der deutschen Version des Artikels wird man derzeit von der Nennung verschiedener Ordner verwirrt:

Ordner namens ”/opsi-packages” im Root-Verzeichnis

Wenn unser Verzeichnis ”/opsi-installs” (wie in meinem Beispiel) sein soll, müssen wir es zuerst erstellen und dann dorthin wechseln.

Direkt danach folgt dann aber der Befehl mit:

mkdir /home/opsiproducts

Erst mal hab ich dann gedacht "Was denn nun?", vor allem weil die Erstellung des Ordners sinnlos ist, zumindest bei mir war der schon nach der Installation vorhanden. Ehrlich gesagt war ich an der Stelle ziemlich verwirrt, bis ich hier am Forum die Diskussion gefunden habe und nun vermute, dass der Artikel einfach nicht ordentlich bereinigt wurde. Aus den Erklärungen hier würde ich persönlich empfehlen den Ordner "/home/opsiproducts" zu verwenden und den Samba-Share (aus "Sicht" von Windows "\\<OPSI-Server>\opsi_workbench" zu nennen. Dann muss der Windows-User nämlich auch gar nichts anlegen. Und es deckt sich mit dem Weg der Getting Started.
Weiter unten steht dann übrigens wieder

Wenn Du durch das Programm durchgelaufen bist, hast Du in Deinem Verzeichnis /opsi-packages einen neuen Ordner (entsprechend unserem Beispiel) namens “tightvnc”

3. Der Vorteil unter Windows zu arbeiten wäre, dass man das ganze immer gleich testen kann, wie bell schon sagt. Ich war eher dabei beim Punkt mit joe etc. auszusteigen. Man soll es nicht glauben, aber für so einen Windows-Menschen ist eine Installation unter Linux schon eine Herausforderung. Denke, da ist aber die Frage, von welcher Seite man kommt. Wenn man mit der Getting Started an den Punkt kommt, hat man eh schon die winst32.exe kennen gelernt. Für den Anfänger lieber nur einen Weg, Alternativen kann man sich hinterher immer noch anschauen.
4.

im nachfolgenden Fenster “product-scripts” gibst Du exakt die Namen “setup.ins” und “uninstall.ins” ein.

Ich glaub, da hat sich gerade was geändert. Zumindest in meinem Template gibt es jetzt keine "setup.ins" mehr, sondern eine "setup32.ins", eine "setup64.ins" und eine "setu3264.ins". Gleiches gilt auch für die "uninstall.ins" und die "delsub.ins". Vielleicht sollte man das auch bei der Benennung im Beispiel berücksichtigen, dann verwirrt man Anfänger auch hier nicht. Das ist auch in der Getting Started noch nicht berücksichtigt.
5. Einmal das direkte Herunterladen der .exe vom OPSI aus als Beispiel genannt finde ich super. Ich kannte die wget-Befehle zwar schon (Wir setzen es bereits an anderer Stelle ein), aber ich bin auf die Idee gar nicht gekommen. Aber vielleicht wäre es für den Anfänger etwas einfacher (Wenn auch umständlicher), wenn er sich die Datei per Windows herunterlädt und dann einfach die Datei auf den OPSI-Server legt, in dem er den Share nutzt.
6. Ein Schreibfehler, der mich noch angesprungen hat:

Wir müssen durch einige Bildschirme gehen. Das erste ist das “product-information-screen”. In diesem Bildschirm geben wir einige Informationen ein, beispielsweiseen ein, beispielsweise

Ansonsten vielen Dank für Deine Mühe, Thomas. Ich bevorzuge "Learning-by-doing" und entsprechend kam mir der Artikel sehr entgegen. Ich fände den auch gut in der Getting Started, wenn der finalisiert wird. Einfach als praktisches Beispiel, wie man die Skripte vom Wiki nutzt, bevor man daran geht, eigene Skripte schreiben zu wollen.

Mit freundlichen Grüßen,
Alsp

[Thomas_H]

Moinsens,

vielen Dank für die Anregungen, ja, tatsächlich habe ich da bei der Korrektur der Ordner geschlampt. Ich habe das nun bereinigt. In sofern "sorry" wenn dieses HOWTO mehr Verwirrung gestiftet hat als geholfen.

1. Die meisten, die ein Deployment in einem Windows-Umfeld umsetzen wollen, dürften aus selbigem kommen. Entsprechend bevorzuge ich es auch, weitestgehend unter Windows zu arbeiten. Die Getting Started empfiehlt ja ebenso einfach jedit (Muss ja nicht gleich notepad++ mit importierten Highlighting empfohlen werden) auf einem Windows-Client für die Bearbeitung der Skripte zu nutzen.

Jou... so wie bell schon empfohlen hat, kann man die Scripte auch unter Windows schreiben und testen. Ich habe aber bewußt die Paketerstellung auf dem Opsi-Server betrachtet, weil auch die Getting Started es beschreibt.

2. Zumindest in der deutschen Version des Artikels wird man derzeit von der Nennung verschiedener Ordner verwirrt:

Ja, Schlamperei von dem der das HOWTO erstellt hat. Ich kenn den, arbeitet bei mir im Bereich... Wenn DER mal den Kopf mit anderen Sachen voll hat, dann passiert das. Hab's ihm schon tausend mal gesagt...

3. [...]Ich war eher dabei beim Punkt mit joe etc. auszusteigen.[...]Für den Anfänger lieber nur einen Weg, Alternativen kann man sich hinterher immer noch anschauen.

...na wie gut, dass ich dann nicht mit dem vi angefangen habe Darum ist in der HOWTO auch nur der Weg beschrieben wie er in der Getting Started beschrieben ist. Klar, man hätte auch noch den Weg über Windows beschreiben können, aber das sprengt dann wohl eher den Rahmen dieses HOWTOS. Es geht ja in erster Linie darum schnelle Erfolge zu erzielen und dem Anwender zu zeigen, wie er die eingestellten Scripte nutzen kann.

4.

im nachfolgenden Fenster “product-scripts” gibst Du exakt die Namen “setup.ins” und “uninstall.ins” ein.

Ich glaub, da hat sich gerade was geändert. Zumindest in meinem Template gibt es jetzt keine "setup.ins" mehr, sondern eine "setup32.ins", eine "setup64.ins" und eine "setu3264.ins". Gleiches gilt auch für die "uninstall.ins" und die "delsub.ins". Vielleicht sollte man das auch bei der Benennung im Beispiel berücksichtigen, dann verwirrt man Anfänger auch hier nicht. Das ist auch in der Getting Started noch nicht berücksichtigt.

Das ist im Grunde vollkommen ohne Belang. Man könnte es auch "meine_ins.ins" und "meine_uninstall.ins" nennen. Hier war aber die Verbindung zu den Scripten vorrangig, in welchen eben die "setup.ins", "uninstall.ins" und "delsub.ins" primär aufgeführt sind. IMHO ist es eh besser, wenn die setup.ins sowohl 32 Bit als auch 64 Bit berücksichtigt, sofern es für ein zu installierendes Programm beide Varianten gibt.

5. Einmal das direkte Herunterladen der .exe vom OPSI aus als Beispiel genannt finde ich super. Ich kannte die wget-Befehle zwar schon (Wir setzen es bereits an anderer Stelle ein), aber ich bin auf die Idee gar nicht gekommen. Aber vielleicht wäre es für den Anfänger etwas einfacher (Wenn auch umständlicher), wenn er sich die Datei per Windows herunterlädt und dann einfach die Datei auf den OPSI-Server legt, in dem er den Share nutzt.

siehe oben. Ich habe bewußt vermieden, hier nun auch noch Windows mit ins Spiel zu bringen. Der Weg ist übrigens tatsächlich weitaus umständlicher. Herunterladen des Setup-Programms, öffnen des Shares, verschieben/kopieren der Setup.exe, setzen der richtigen Rechte usw. Wenn man schon auf dem Opsi-Server arbeitet, ist ein wget schneller und die Setup.exe hat am Ende auch die richtigen Rechte und liegt auch gleich im richtigen Verzeichnis
Und diese Vermischung "ich mach dies auf dem Opsi-Server, das auf dem Windows-PC" ist für mich so eine Art "halbschwanger" . Wer Linux-Server nutzt, muss sich auch zwangsläufig mit Linux-Betriebssystem auseinandersetzen. Die Logfiles werte ich idR. auch nicht mit Windows aus wenn es ein Problem gibt, sondern auf dem Linux-Server mit zB. grep insofern ist es schon sinnvoll auf dem Opsi-Server zu bleiben, was die HOWTO angeht. Und wie Du ja geschrieben hast, findet jeder für sich später einen anderen Weg, der bequemer und angenehmer ist, wenn man Scripte erst noch testen muss. Sind sie aber fertig, ist man mit dem packen auf dem Opsi-Server schneller.

6. Ein Schreibfehler, der mich noch angesprungen hat:

Jupp... beseitigt. Danke.

Gruß

Thomas_H

[alsp]

Moin,
danke für die Korrekturen. Was mich jetzt nur wundert, ich arbeite gerade mit der aktuellen Getting Started und da wird der Weg halt über Windows, jedit zum erstellen/anpassen von Skripten und OPSI-winst zum testen der selbigen beschrieben. Das erstellen der Pakete etc. geschieht dann natürlich auf dem OPSI-Server selber. Zumindest war das für mich als Windows-User der schnellste Weg. Um ehrlich zu sein, es gibt ja Gründe warum jeder einzelne Installationsschritt im Linux-Umfeld in der Getting Started haarklein erklärt ist. Zumindest ich stand schon ziemlich ratlos da, als das HowTo mit "Installiere wget und joe auf dem OPSI-Server" begann ohne weitere Erklärungen etc. Das ist nicht der Weg der Getting Started. Der schnelle Erfolg war zumindest hier für mich, das ganze zu ignorieren und im Windows-Umfeld zu bleiben.

Und danke, dass Du es nicht über vi zu erklären versucht hast. Ich persönlich bin zum editieren unter Linux ziemlich schnell bei nano gelandet.

Das ist im Grunde vollkommen ohne Belang. Man könnte es auch "meine_ins.ins" und "meine_uninstall.ins" nennen. Hier war aber die Verbindung zu den Scripten vorrangig, in welchen eben die "setup.ins", "uninstall.ins" und "delsub.ins" primär aufgeführt sind. IMHO ist es eh besser, wenn die setup.ins sowohl 32 Bit als auch 64 Bit berücksichtigt, sofern es für ein zu installierendes Programm beide Varianten gibt.

Das ist richtig. Verwirrt nur, wenn man halt ahnungsloser Anfänger im OPSI-Umfeld ist.

Wenn man schon auf dem Opsi-Server arbeitet, ist ein wget schneller und die Setup.exe hat am Ende auch die richtigen Rechte und liegt auch gleich im richtigen Verzeichnis

Das ist nicht ganz richtig. Den set-Rights-Befehl musste ich allein schon auf die Dateien machen, um über den Samba-Share auf die Dateien zugreifen zu können. Da fehlen anscheinend schon ein paar Rechte.

Ich sehe das Problem hier so: Wenn man das ganze ohne Vorahnung betrachtet, hast Du recht. Dann ist Dein Weg schneller und einfacher. Wenn man es aber aus der Sicht des Getting Started betrachtet, kennt man das Zwischenspiel zwischen Windows/Linux schon, kennt jedit, kenn OPSI-Winst, den Samba-Share, den Set-Rights-Befehl... eben das ganze Handwerkszeug. wget, joe, Installation derselben (evtl sogar über yast, aptitude etc.) kennt man nicht. Ich bin ja das beste Beispiel. Von daher würde ich den Weg über Windows und/oder eine detaillierte Anleitung für die Leute ohne Ahnung von Linux besser finden. Und ich hab schon den OPSI per Hand unter Debian installiert und nicht die fertige VM genutzt. Wer das gemacht hat, hat noch weniger Ahnung von Linux. Ist aber Dein Artikel

Grüße,
alsp

[Thomas_H]

Moinsens...

nee... nicht ganz mein Artikel. Ist doch eine WIKI... Wenn Deine Erfahrungen irgendwann ausgeweitet sind, kannst Du ausserdem auch gerne den Weg über Windows beschreiben. Das ist es ja, wovon diese WIKI lebt.
Es führen so viele Wege nach Rom für mich war der direkteste für den absoluten Neuling eben der auf Linux zu bleiben.
Ich habe nano noch nicht ausprobiert, hätte auch auf mcedit eingehen können. Meine Erfahrung zeigte aber, dass mcedit beispielsweise die tabs addiert und der gesamte Text sich Zeile für Zeile nach rechts addiert... von der Bedienung her wäre aber mcedit wesentlich einfacher gewesen.
So nahm ich eben joe, weil dieser Editor die "Formatierung" der Scripte erhält und dennoch recht leicht zu bedienen ist. Ebenso wie wget.

Dass Personen mit mehr Erfahrung noch ganz andere Wege finden werden bleibt sicherlich unbestritten. Für mich als (erster Autor) gab es eine Zielsetzung. Diese war durch eine Frage hier im Forum fokussiert: "Wie nutze ich die veröffentlichten Scripte? Gibt es dazu eine HOWTO?"

Beim Schreiben hatte ich meine teilweise negativen Erfahrungen mit anderen HOWTOs im Kopf, bei denen man erst den Nippel durch die Lasche ziehen muss, um dann an die kleine Kurbel zu kommen. Es war mir einerseits wichtig den Standart des Getting Started zu erreichen, was mir nicht ganz gelungen ist, andererseits eine Art 1., 2., 3. ... zu erreichen. Dem Nutzer der HOWTO Schritt für Schritt vorzugeben ohne dass er vielleicht genau weiss, was er da macht.
Verworfen hatte ich aber den Gedanken, dass man andere Möglichkeiten in einer HOWTO (use the published scripts) in epischer Bandbreite darlegen muss; ob ich den Leser damit vielleicht verwirre, dass ich nach "opsi-newproduct" auf einen Windows-Client springen muss um mit jedit das Script reinzubekommen um danach wieder auf den Opsi-Server zu gehen um dann das Paket zu packen und bereit zu stellen. Das hätte auch bedeutet, ihm vielleicht die Einbindung der Shares zu erklären und/oder auch die Installation von Jedit. Und was, wenn er lieber "Notepad" nutzen will oder "Notepad++"...?

In der HOWTO ging wirklich nur um eines: Wie nutze ich die Scripte? Ich hab eben den Opsi-Server gestartet (zB. über die VM) und wie bekomme ich nun selbst ein fertiges Paket zuwege? Durchaus könnte man auch die einzelnen Schritte des Scriptes zur Installation von TightVNC erläutern und dem Nutzer des HOWTOS erklären, was da eigentlich passiert. All das war aber nicht Ziel, sondern nur einen schnellen Erfolg zu gewährleisten durch die Einbindung der veröffentlichten Scripte. Wer selbst als Unwissender diese (nun korrigierte ) HOWTO immer wieder durchläuft für alle freie Software, die seine Rechner brauchen, dürfte er es innerhalb weniger Tage schaffen, einen voll funktionsfähigen Opsi-Server aufzusetzen ohne so recht kapiert zu haben, was genau er da getan hat

Ich möchte an dieser Stelle nicht falsch verstanden werden. Deine Anregungen sind sehr konstruktiv, ich wollte hier lediglich mal meine Gedanken und Zielsetzungen bei der Erstellung des HOWTOs aufzeigen.

Eine kleine Anmerkung habe ich allerdings noch. Ich hab's schon anderswo betont und möchte meine (ureigenste) Meinung dazu nochmals verdeutlichen: Wenn man einen Server aufsetzt - erst recht einen Server mit einem mir fremden Betriebssystem - dann muss ich mich mit diesem Betriebssystem und seinen Eigenheiten auseinandersetzen. Dazu gehört nun mal auch das Nachinstallieren von Software, denn ich kann/darf nicht erwarten, dass auch alle Sicherheitsvorkehrungen (Firewall, Virenschutz, ev. weitere Überwachungstools) gleich mit installiert und korrekt konfiguriert sind. Ein Opsi-Server ist - wie es auch in der HOWTO steht "kein “Out-Of-The-Box”-System". UIB bietet die Serverlösung für die Verteilung der Software an, den Server aber vor Angriffen zu schützen ist Sache des Admins. Und Angriffe kommen bekanntlich nicht nur von außen. Von der Auswertung von Logfiles und den Tools mal abgesehen.

Naja... und wer wirklich gut ist, steuert den Opsi-Server komplett von Windows aus - Paketerstellung eingeschlossen...

Gruß

Thomas_H

[alsp]

Moin Thomas,

Wenn Deine Erfahrungen irgendwann ausgeweitet sind, kannst Du ausserdem auch gerne den Weg über Windows beschreiben.

Ich denke gerade schon darüber nach. Erfahrungsgemäß findet man von der Arbeit aus für so was aber eher weniger Zeit und privat hängt man sich nicht so hinter. Ich überlege gerade ob ich etwas entsprechendes beim Doing nebenher schon verfasse und dann hinterher mit evtl. Korrekturen auf das Wiki kopiere.

Das hätte auch bedeutet, ihm vielleicht die Einbindung der Shares zu erklären und/oder auch die Installation von Jedit. Und was, wenn er lieber "Notepad" nutzen will oder "Notepad++"...?

Die Einbindung des Shares braucht man ja nicht. Der ist ja schon fertig vorhanden, wenn man den OPSI installiert. Für die Installation von jedit hätte man auf die Getting Started verweisen können. Wobei man natürlich, um schnelle Ergebnisse zu produzieren einfach auf den Windows-Editor verweisen könnte. Für ein schnelles Ergebnis reicht Dir, da braucht man erst mal kein Highlighting.

Wenn man einen Server aufsetzt - erst recht einen Server mit einem mir fremden Betriebssystem - dann muss ich mich mit diesem Betriebssystem und seinen Eigenheiten auseinandersetzen. Dazu gehört nun mal auch das Nachinstallieren von Software, denn ich kann/darf nicht erwarten, dass auch alle Sicherheitsvorkehrungen (Firewall, Virenschutz, ev. weitere Überwachungstools) gleich mit installiert und korrekt konfiguriert sind. Ein Opsi-Server ist - wie es auch in der HOWTO steht "kein “Out-Of-The-Box”-System". UIB bietet die Serverlösung für die Verteilung der Software an, den Server aber vor Angriffen zu schützen ist Sache des Admins. Und Angriffe kommen bekanntlich nicht nur von außen. Von der Auswertung von Logfiles und den Tools mal abgesehen.

Definitiv und ohne Frage. Aber schnelle Ergebnisse will man in der Regel während der Evaluierung etc. Und für den Betrieb des OPSI in einer Testumgebung und Testen der Einbindung der eigenen Software sind diese Sachen erst einmal nachrangig.

Aber zur Sicherheit: Das waren Anregungen und wenn Du anderer Meinung bist, ist das völlig OK. Ist mir halt nur aufgefallen, dass bell und ich unabhängig zur gleichen Ansicht gekommen sind.

Viele Grüße,
Alsp