Ordner namens ”/opsi-packages” im Root-Verzeichnis
Direkt danach folgt dann aber der Befehl mit:Wenn unser Verzeichnis ”/opsi-installs” (wie in meinem Beispiel) sein soll, müssen wir es zuerst erstellen und dann dorthin wechseln.
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.mkdir /home/opsiproducts
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.Wenn Du durch das Programm durchgelaufen bist, hast Du in Deinem Verzeichnis /opsi-packages einen neuen Ordner (entsprechend unserem Beispiel) namens “tightvnc”
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.im nachfolgenden Fenster “product-scripts” gibst Du exakt die Namen “setup.ins” und “uninstall.ins” ein.
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.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
Ich habe das nun bereinigt. In sofern "sorry" wenn dieses HOWTO mehr Verwirrung gestiftet hat als geholfen.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.alsp hat geschrieben: 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.
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...alsp hat geschrieben: 2. Zumindest in der deutschen Version des Artikels wird man derzeit von der Nennung verschiedener Ordner verwirrt:
...na wie gut, dass ich dann nicht mit dem vi angefangen habealsp hat geschrieben: 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.
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.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.alsp hat geschrieben: 4.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.im nachfolgenden Fenster “product-scripts” gibst Du exakt die Namen “setup.ins” und “uninstall.ins” ein.
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 Verzeichnisalsp hat geschrieben: 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.
. 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.Jupp...alsp hat geschrieben: 6. Ein Schreibfehler, der mich noch angesprungen hat:
beseitigt. Danke.Das ist richtig. Verwirrt nur, wenn man halt ahnungsloser Anfänger im OPSI-Umfeld ist.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 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.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
Wenn Deine Erfahrungen irgendwann ausgeweitet sind, kannst Du ausserdem auch gerne den Weg über Windows beschreiben. 
Das ist es ja, wovon diese WIKI lebt.
von der Bedienung her wäre aber mcedit wesentlich einfacher gewesen. ) 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 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.Wenn Deine Erfahrungen irgendwann ausgeweitet sind, kannst Du ausserdem auch gerne den Weg über Windows beschreiben.
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.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++"...?
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.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.