Features

Konfigurations-Tools für System-Einstellungen, Netzwerk, Serverdienste, Hardware, X11. . .
Manager für Festplatten, Raid & LVM-System
XML-Import/Export Funktionen zum clonen von System-Konfigurationen
Frontend zur anzeige von Systeminformationen & Hardware-Ausstattung
Mehrsprachig (de/en)
Modular (erweiterbar über Shell-Scripte)
Installer für DEB, TGZ & RPM - Systeme von CD oder über Netzwerk
XML-Auto-Installer
Manager für NET-Boot-Systeme

Oberfläche

Menügeführte Dialog-Oberfläche unter Zuhilfenahme von

dialog
gdialog
Xdialog
tkdialog

Programmiersprachen

Basis-System & XML-Export:

Shell-Script (sh / ash)

XML-Import:

TCL-Script (tclsh + tclexpat) # ShellScript-Version ist in Arbeit!

Diskussion

Frage: Das Projekt scheint recht neu zu sein, auf der Homepage ist keine Kontaktperson genannt, was die Funktionalität angeht ist sie evtl. schon über das Config4Gnu (CFG) Projekt möglich.

Das wichtigste ist an diesem Tool das es fast komplett in Shell-Script geschrieben ist.
- Das ermöglicht jeden Admin eigene Tools einzubauen oder zu erweitern.
- Shell-Scipt Erweiterungsmöglichkeit ist eine gute Sache und soll teilweise auch in Config4Gnu verwendet werden. In der Antwort zu dieser Mail hier am besten nach "script" suchen. Eines der schönsten Sachen ist aber schon jetzt, dass man neue Config-Module nicht wiederholt "hardcoden" muß sondern eine "externe" Beschreibung der Konfigurationsmöglichkeiten erfolgt. Und das die Config-Dateien weiterhin auch beliebig anders änderbar sind da Config4Gnu das jeweilige native Format versteht und auch keine Formatierungen verändert. Eine schöne Sache wäre es natürlich wenn für die Zukunft einige dependencies fallengelassen werden könnten, für eine rasche stabile Implementation und Modularisierung ist es aber vermutlich erstmal OK so.

Desweiteren enthält UnixConf auch noch einen Installer und Install-CD generator. Leider sind die meisten Funktionen im Moment nur mit Debain möglich.

Eine Sache die man natürlich auch mit CFG immer machen kann ist eine Install-CD-Config zu bearbeiten und als "aktivierung" dann ein entsprechendes Script oder Programm diese abarbeiten zu lassen. Man könnte sogar eine meta-config Beschreibungsdatei direkt für ein Script machen, eine "Config Datei" die ausführbar ist, würde aber wohl weniger Sinn machen. Ganz allgemein ist CFG so gestaltet, das die meta-config Beschreibungen "verteilt" von einzelnen Projekten gewartet werden können, von Anfang an Distributionsunabängig ausgelegt ist und somit auch für Debian geeignet ist. Änderungen von debconf stören in keiner Weise. CFG könnte man aber auch zum konfigurieren von debconf verwenden, und debconf könnte auch CFG für den Zugriff auf Konfigurationsdateien verwenden.

Ich würde gerne wissen was diese Diskussion bringen soll, wollt ihr das ich das Project aufgebe und bei CFG helfe ? Das CFG Projekt verfolgt für mich die falschen Ansätze. Ich benötige ein Tool das mit wenig Paket-Abhängigkeiten auskommt, und möglichst auf jedem Unix-System lauffähig ist oder ohne Rekompilierung anpassbar ist. Halt möglichst einfach und mit den Mitteln eines Admins.

Das Interessante für uns ist "Welche Ansätze (unsere) könnten falsch sein?" oder "Was hatte euch dazu bewegt einen anderen, neuen Anzatz zu wählen?" Natürlich damit wir weiter an CFG feilen können Jetzt sagtest du ja Abhängigkeiten, und ohne Rekompilierung anpassbar. Letzteres sind unsere XML meta-config Beschreibungen natürlich. Die Tatsache das der CFG Kern ersteinmal kompiliert werden muß haben wir in kauf genommen um ein System zu bekommen welches hardcoding von Konfigurationsaufgaben erübrigt und fremde Konfigurationsänderungen nie überschreibt sondern verarbeiten kann.

Vieleicht könnte man in Sachen XML-Format ein wenig miteinander arbeiten, um ein einheitliches/portierbares Format zu erhalten, das von meinem XML-Module lesbar ist.

Mir ist nur noch nicht so ganz klar in welcher weise UnixConf XML verwendet. Die CFG XML meta-config Dateien beschreiben die vorhandenen Optionen einer Konfigurationsdatei damit der jeweilige generische Parser die Einstellungsmöglichkeiten in die Hierarchie der XML-Representation einordnen kann. Neue Einstellungsmöglichkeiten und zugehörige "Forms" und "Wizards" Logic-Definitionen laut meta-config dateien die der XML-Representation hinzugefügt werden sind dann von allen Frondends (ohne Anpassung der Frontends) bearbeitbar. Etwas näheres zum Format ist hier zu finden, einige Beispiele sind im cvs.

Ok, ich habe mir die CFG-XML-Files nicht richtig angesehen, ich dachte ihr benutzt diese vieleicht als zwichenspeicher

(config->xml | edit | xml->config).

Über UnixConf kann die System-Konfiguration (disks, services, network,...) als XML-Profile exportiert werden (z.b. unter OpenBSD), und auf einem Debian/Linux-System wieder eingelesen, oder ein System per XML-Installer neu aufgesetzt werden.

Achso, sorry dann hatten wir wohl ursprünglich an unterschiedliche Sachen gedacht. Aber du hast Recht die komplette Konfiguration wird dann vom middlelayer auch in eine dynamische XML-Representation gebracht, die dann von den Frontends und Tools bearbeitet werden kann, usw. Zu dessen Specs ist hier was zu finden. Näheres kann ich Dir dazu selbst nicht sagen da ich mehr aus der admin Ecke komme.

Und wenn ich ehrlich sein soll, hab ich es noch nichtmal auf anhieb geschaft das ganze auf Woody zu Kompilieren. Ich bin auch kein C/C++ Programmierer,

Interessant, vielleicht könntest Du ja die Fehlermeldungen auf der Mailingliste posten. (Da die CFG-Devloper selbst gentoo benutzen wäre hier ein Feedback interessant)
- Bin kein Devloper, bin Admin (und gentoo mag ich nett)
  - Eben drum, aber ich glaub es war erst nicht so klar rausgekommen was damit gemeint war

Admins haben meistens ihre kleinen helfer scripte, welche recht unproblematisch von selbigen ergänzt und in UnixConf eingearbeitet werden können. Oder für das schreiben von Wizards, die einmalig komplexere Systeme aufsetzen müssen, und dabei mehere Configfiles anpassen und verschiedene Dienste (Vieleicht auf anderen Rechnern) starten/stoppen müssen. Kann das CFG ??? Kann das ein Admin mit CFG ???

Vorhandene Skipte können unverändert weiterverwendet werden. CFG kann das skriptschreiben aber z.B durch ein Kommandozeilenfrontend das vom Skipt verwendet wird sehr vereinfachen. Und das Skipt läuft dann auf allen Systemen für die CFG verfügbar ist (und die verwendete Skriptsprache natürlich).
CFG kümmert sich um die Syntax und Semantik von Konfigurationen und um die Verifizierung anhand der meta-config-definitionen. Ein Admin braucht mit CFG die Syntax usw. nicht mehr explizit in seinen Skripten "hardzucoden". Seine Skipte können dann einfacher und allgemeiner gehalten werden und entweder über ein Komandozeilenfrontend oder auch perl-bindings o.ä. "live" auf die Konfigurations-"nodes" zugreifen. (Alte scripte funktionieren aber auch weiterhin, und stören CFG nicht)
Forms und Wizards sind in CFG in der meta-config-Beschreibung zusätzlich möglich um diese Funktionalität an zentraler Stelle allgemein bereitstellen zu können.
Veränderungen aktivieren (z.B. auch Dienste starten und stoppen) wird für Frontends transparent vom CFG middlelayer beim speichern gemacht.
- Ist das auch immer erwünscht ???
  - Warum sollte man eine Systemkonfigurationsdatei als solche abspeichern und nicht aktivieren wollen? Im Grunde möchte man doch die Konfiguration ändern und nicht die Datei. Separat Zustände speichern ist natürlich was Anderes.
- Was ist wenn Dienste(verschiedene Konfigurationen) voneinander abhängig sind ?
  - Gibt es Alternativen zu entweder alle meta-config Informationen wissen bzw. ausprobieren und per Hand machen, oder Abhängigkeiten und andere meta-config daten definiert haben, ansehen können und auch automatisch verwenden können.
Um Mehrere Rechner zu Konfigurieren gibt es unteschiedliche Ansätze. Bisher wird in der Basis-Datei der XML-Definition nur die "computer" Klasse definiert, denkbar wäre das man hier z.B "server" und "clients" oder beliebige andere Klassen unterscheidet und dann in der XML-Representation verschiedene Datei-Instanzen die auf unteschiedlichen Rechnern liegen als dessen Kinder angibt um mit einem Schlag Netzweite veränderungen zu machen. (Die Dateien könnten übers Netz gemounted sein oder besser z.B. mit FAI o.ä. gepushed/pulled werden.) Weiterhin wird an einer LDAP Schnittstelle gebastelt und es wird darüber nachgedacht CFG installationen auch über Corba oder ähnliches erreichbar zu machen.
Es gibt glaube ich genug Gründe, für eine Funktion mehrere Programme anzubieten (http://www.pro-linux.de/news/2003/6277.html), es kommt immer auf die anforderungen an. Es währe schön alle konzepte unter einen Hut (solange es kein roter ist ;-)) zu bringen. Aber leider gibt es meistens zu unterschiedliche Anforderungen.
- Du sprichst von den Kommenentaren zu Artikel oder? Die Perens-Argumentation find ich überhaupt nicht konsistent.

Mal was anderes, habt ihr euch schonmal überlegt was man macht wenn aus dem kleinen Netzwerk (bis 100 nodes) aufeinmal ein RZ mit über 1000 Servern und 300 Stations wird ??? Ich denke mal das schaft dann weder CFG noch UnixConf zu bewältigen. Dafür sind auch wieder andere Produkte oder aufsätze nötig. Das Perfekte System (PerfekteDistribution) gibt es wohl nicht.

Für so junge Projekte steht sowas wohl sowieso außer Frage. Überhaupt glaube ich eher an einen inkrementellen Ansatz als an die global galaktische Lösung. (siehe z.B auch T0ll-Collect). Ich fände es erstmal wichtig überhaupt ein System konfigurieren zu können ohne viel unnötige Format- und Parameternamen-Informationen memorieren oder abgleichen zu müssen und ohne zu spezialisierten Code zu benötigen. (Daher gefällt mir das CFG Framework) Sowas könnte vieleicht auch mal helfen 1000 Maschienen irgend wann einmal genügend homogen erscheinen zu lassen, mit der Möglichkeit es mit ergänzenden Lösungen zu kombinieren (unix-way mäßig). Vielleicht können unsere Projekte da einen kleinen Beitrag für künftige Infrastrukturen leisten.
Wie soll in UnixConf die Distributionsunabhängigkeit realisiert werden?

Mit einem einfachen {test -e /etc/debian_version}, das script testet auf welcher Distri es läuft, und behandelt diese entsprechend.

Hmm, dann verstehe ich jetzt glaube ich Distributionsunabhängigkeit nicht richtig, wenn doch jedes scipt alle Distris berücksichtigen und entsprechend behandeln muß.

Läst du bei jeder Distribution , z.b. die Netzwerk-Konfiguration immer in die gleiche Datei schreiben (z.b. nach /etc/network/interfaces)??? Da bekommst du unter RedHat aber probleme, unter CFG sind für Neue Distris auch anpassungen nötig (ob XML oder Script is ja egal), oder muß ich euch erst die Funktionsweise von CFG erklären ?

IIRC ist das so das jedes packet seine meta-config definition hat. Verschiedene Distros mit verschidenartigen Netzwerkpaketen (base-network.rpm/.deb oder so) und damit auch unterschiedlichen Konfigurationsdateien haben ganz bestimmt in einigen Punkten unterschiedliche Meta-Definitionen aber auf der CFG Representationsebene sind die Optionen dan wieder gleich. Zugriffe auf Einstellungen z.B. der IP, Netmask usw. sind für Skipts oder andere Frondends damit auf jeder Distribution immer gleich. Unterschiedliche Speicherorte einer Konfigdatei z.B. von Samba auf verschiedenen Distros sollte vom CFG System automatisch aufgelöst werden.

Jedem das seine !

ICH bin ADMIN, und kann kein C aber SHELL,

und daher benutze ich lieber UnixConf !!!!