UnixConf ist ein modulares Konfigurations-Tool für Unix(ähnliche)-Systeme (["Debian"], ["OpenBSD"], ["FreeBSD"], ["NetBSD"], RedHat, ["Mandrake"], ["SuSE"])

Homepage: http://unixconf.sourceforge.net/

Lizenz: ["GPL"]

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 & RPM - Systeme über CD und Netzwerk

XML-Auto-Installer

Manager für NET-Boot-Systeme

Oberfläche

Menügeführte Diaolg-Oberfläche:

• dialog, gdialog, Xdialog, tkdialog

Programmiersprachen

Basis-System & XML-Export:

• Shell-Script (sh / ash)

XML-Import:

• TCL-Script (tclsh + tclexpat)

Diskussion

OffeneFrage: 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 [http://sourceforge.net/mailarchive/forum.php?thread_id=3149867&forum_id=12453 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. Die XML-Representation ist dann inkl. "Forms" und "Wizards" von allen Frondends ohne Anpassung bearbeitbar. Etwas näheres zum Format ist [http://config4gnu.sourceforge.net/docs/extending/entities.html 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 [http://config4gnu.sourceforge.net/docs/xmlspec/index.html 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 ja die Fehlermeldungen auf der Mailingliste posten. (Devloper verwenden gentoo)

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 ???

• CFG kümmert sich um die Syntax und Semantik von Konfigurationen und um die Verifizierung anhand der meta-config-definitionen. Ein Admin braucht sich sobalt die meta-daten da sind diese auch nicht mehr explizit in seinen scripten "hardzucoden". Seine scipte können dann entweder über ein Komandozeilenfrontend oder auch perl-bindings o.ä. "live" auf die Konfigurations-"nodes" zugreifen. (Alte scripte funktionieren aber auch weiterhin unverändert)
• 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 gemacht.
• Um Mehrere Rechner zu Konfigurieren gibt es unteschiedliche Ansätze. Bisher wird in der Basis-Datei der dynamischen CFG XML-definition nur die "computer" Klasse definiert, denkbar wäre das man hier z.B "server" und "clients" unterscheidet und dann 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 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.