Re: [PUG] Virtualisierung von Windows auf Systemen mit und ohne Vanderpool/Pacifica
Silverio Santos schrieb: > heute ist eine neue "Pizzabox" (flacher Server) für die Installation von > Wndws Srvr geliefert worden. Jetzt möchte ich das OS virtualisieren, auf > einem neuen Xeon mit VT/Pac. soll das mit VMWare ESXi oder KVM > performant sein. Andererseits habe ich als Fall-back-Server nur maximal > Intl Pntium IV-HT, so daß dort KVM nicht funktioniert. Xen fällt dort > auch für Windos Servidor aus. Kennt ihr geeignete Methoden/Software, > nicht anpassbare Betriebssysteme, auf neuer Prozessor- Hardware sowohl > performant, als auch zu Vitualisierung unter älterer Proz-HW kompatibel > zu sein? Ich bratzel alles, was mir in die Finger kommt, auf den VMware-Server (also keine Bare Metal Virtualisierung) drauf. Die Images kann man überall hin verschleppen und hochfahren. Allerdings bin ich kein so'n Performanz-Junkie. Solange es nicht langsam wird, ist mir die Performanz egal. -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de --> http://www.pug.org/index.php/Benutzer:Martin <-- -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] Virtualisierung von Windows auf Systemen mit und ohne Vanderpool/Pacifica
Prfrmnt z sn st n Ftr dr Przssrn nd ht mt pn bzw Clsd Src ncht z tn Frs Vrstndn hlfrch st ds Ggln nch Vrtlsrung, spzll nch Mmry Mngmnt nt bzw CP mt dsm Ftr. HTH Silverio Santos wrote: Hi, heute ist eine neue "Pizzabox" (flacher Server) für die Installation von Wndws Srvr geliefert worden. Jetzt möchte ich das OS virtualisieren, auf einem neuen Xeon mit VT/Pac. soll das mit VMWare ESXi oder KVM performant sein. Andererseits habe ich als Fall-back-Server nur maximal Intl Pntium IV-HT, so daß dort KVM nicht funktioniert. Xen fällt dort auch für Windos Servidor aus. Kennt ihr geeignete Methoden/Software, nicht anpassbare Betriebssysteme, auf neuer Prozessor- Hardware sowohl performant, als auch zu Vitualisierung unter älterer Proz-HW kompatibel zu sein? Ich weiß, Open Source hat o.g. Probleme nicht und die generellen Probleme von Closed Source sind damit nicht gelöst, aber wir müssen nun mal damit leben... Übrigens: Mcrsft Systm Cntr ist ein Muß, deshalb nicht ersetzbar. -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
[PUG] Virtualisierung von Windows auf Systemen mit und ohne Vanderpool/Pacifica
Hi, heute ist eine neue "Pizzabox" (flacher Server) für die Installation von Wndws Srvr geliefert worden. Jetzt möchte ich das OS virtualisieren, auf einem neuen Xeon mit VT/Pac. soll das mit VMWare ESXi oder KVM performant sein. Andererseits habe ich als Fall-back-Server nur maximal Intl Pntium IV-HT, so daß dort KVM nicht funktioniert. Xen fällt dort auch für Windos Servidor aus. Kennt ihr geeignete Methoden/Software, nicht anpassbare Betriebssysteme, auf neuer Prozessor- Hardware sowohl performant, als auch zu Vitualisierung unter älterer Proz-HW kompatibel zu sein? Ich weiß, Open Source hat o.g. Probleme nicht und die generellen Probleme von Closed Source sind damit nicht gelöst, aber wir müssen nun mal damit leben... Übrigens: Mcrsft Systm Cntr ist ein Muß, deshalb nicht ersetzbar. Gruß Silvério P.S.: Sorry, wenn ich schlechte Software-Namen nicht richtig schreibe, bei mir hat's nur zum MCSA gereicht. -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] kumulatives Patch anhand tgz-Files erstellen
On Mon, 12 Jan 2009, Gavin Schenk wrote: Meine Anforderung: Ich möchte einen kumulatives Patch erzeugen, das jede vorzufindende Version auf einen neueren Stand bringen kann. Ein Downgrade muss nicht möglich sein. Prinzipieller Lösungsansatz am Beispiel: Im Beispiel gibt es ein System in drei Versionen 1.0, 1.1, 1.2. Entsprechend gibt es drei tgz-Files 1.0.tgz, 1.1.tgz und 1.2.tgz. 1.) Erstelle diffs für die Übergänge 1.0->1.1 und 1.1->1.2. Packe diese Änderungen in ein kumulatives Patch zusammen. 2.) Beim Aufspielen des patches wird auf dem laufenden System die installierte Version ermittelt. Wird z.B. 1.1 vorgefunden, dann werden nur die Änderungen des Überganges 1.1->1.2 aufgespielt. Dabei gibt es noch einiges zu beachten (benutzerdefinierte Einstellungen nicht aus versehen platt machen z.B.), aber das wäre die prinzipielle Vorgehensweise. Ich habe schon überlegt, ob das mit diff und patch möglich wäre, aber das funktioniert nicht für binäre Dateien, symbolische Links und knodes. Ausserdem müssten auch Zugriffsrechte beibehalten und ggf. angepasst werden. Ich würde das mit Bash-Skripten + einiger Hilfstools angehen. Gibts hierfür ( oder Teile davon) freie/kommerzielle Lösungen? Gibt es, schau Dir doch einmal star an. Von 1.0 ein Archiv erstellen und dann mit star -diff die Unterschiede zu 1.1 anzeigen lassen. Mir sind einige weitere Umstaende, die auch noch wichtig sind, aber nicht klar: Wie konnte das Problem ueberhaupt entstehen? Das klingt ja erstmal wie eine typische Aufgabe eines beliebigen Paket- managers. Gibt es keine normalen Pakete? Bei meiner eigen Distribution (hauptsaechlich Slackware basiert, wobei ich auch Debian/Xandros erstelle) hab ich eigene Pakete in einem eigenen /opt/$MEINS Zweig integriert. Dann kann ich ganz normal die Pakete fuer die Distribution upgraden. Eigene Pakete getrennt in meinem /opt/$MEINS subdir, koennen auch mit dem normalen Paketmanager upgrades erhalten. Nur Aenderungen die spezifisch fuer eine Maschine sind kommen nach "/usr/local", hier ist der einzige Bereich, wo es manchmal Software gibt, die direkt ohne Paket installiert wurde. Wo befinden sich bei Dir die Teile die ein Update brauchen? Ueberall im System? "/etc"? Kann der Rechner fuer ein Update runtergefahren und z.B. von einer anderen CF Karte oder CD gestartet werden, um wichtige libs wie glibc zu erneuern? Eigentlich ist rsync neben star auch eine gute Loesung, ich waere nur vorsichtig mit den Optionen, um alle wichtigen Ordner und Files die ausgenommen werden muessen, zu erhalten. Bei einem ungepflegten System, wo die Aenderungen nirgendwo vollstaendig dokumentiert wurden, kann es sonst boese Ueberraschungen geben. Und bei Kundensystemen ... Waere es nicht leichter ein ganz neues Basissystem einzuspielen und nur die Kundenerweiterungen einzupflegen? cu Frank -- QOTD: "I'm on a seafood diet -- I see food and I eat it."-- PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] kumulatives Patch anhand tgz-Files erstellen
Thomas Reifferscheid wrote: Ich wuerde Symlinks und Knodes manuell anlegen und den Rest mit Diff/Patch machen Alternative mit rsync: #Deployment: cd /tmp mkdir -p 1.2 tar -C 1.2 -xzf 1.2.tgz rsync --delete -avHS /tmp/1.2 /target -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] kumulatives Patch anhand tgz-Files erstellen
Ich wuerde Symlinks und Knodes manuell anlegen und den Rest mit Diff/Patch machen Alternativ baue Pakete der Zieldistribution, rpm, deb etc, wobei dir die Handarbeit dort auch nicht abgenommen wird. #!/bin/bash ### Patcherstellung cd /tmp mkdir -p 1.0 1.1 1.2 tar -C 1.0 -xzf 1.0.tgz tar -C 1.1 -xzf 1.1.tgz tar -C 1.2 -xzf 1.2.tgz diff -Naur 1.0 1.1 > patch-1.0-1.1diff diff -Naur 1.1 1.2 > patch-1.1-1.2.diff # Deployment systemversion=$(ermittelesystemversion) if [ "$systemversion" == "1.0" ]; then cd / patch -p0 < patch-1.0-1.1diff patch -p0 < patch-1.1-1.2.diff elif [ "$systemversion" == "1.1" ]; then cd / patch -p0 < patch-1.1-1.2.diff fi HTH Thomas Gavin Schenk wrote: ... Prinzipieller Lösungsansatz am Beispiel: Im Beispiel gibt es ein System in drei Versionen 1.0, 1.1, 1.2. Entsprechend gibt es drei tgz-Files 1.0.tgz, 1.1.tgz und 1.2.tgz. 1.) Erstelle diffs für die Übergänge 1.0->1.1 und 1.1->1.2. Packe diese Änderungen in ein kumulatives Patch zusammen. 2.) Beim Aufspielen des patches wird auf dem laufenden System die installierte Version ermittelt. Wird z.B. 1.1 vorgefunden, dann werden nur die Änderungen des Überganges 1.1->1.2 aufgespielt. Dabei gibt es noch einiges zu beachten (benutzerdefinierte Einstellungen nicht aus versehen platt machen z.B.), aber das wäre die prinzipielle Vorgehensweise. Ich habe schon überlegt, ob das mit diff und patch möglich wäre, aber das funktioniert nicht für binäre Dateien, symbolische Links und knodes. Ausserdem müssten auch Zugriffsrechte beibehalten und ggf. angepasst werden. Ich würde das mit Bash-Skripten + einiger Hilfstools angehen. Gibts hierfür ( oder Teile davon) freie/kommerzielle Lösungen? -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
[PUG] kumulatives Patch anhand tgz-Files erstellen
Hallo, leider wird die Mail etwas länger da ich ein wenig aushole. Es geht im Prinzip darum den Unterschied zwischen zwei tgz-Files zu ermitteln und die daraus resultierenden diffs als Systemupdate zu verwenden. Wen das nicht interessiert bitte hier aufhören weiter zu lesen!!! Ich hatte zu dem Thema letztes Jahr schon einmal gefragt, da gab es leider wenig Resonanz. Ich versuche es jetzt noch einmal bevor ich anfange selbst zu entwickeln. Also hier der Versuch Euer geballtes Wissen auszunutzen :-). Hintergrund: Ich bin Entwickler und programmiere den ganzen Tag in C, C++ (Qt). Da ich mich schon seit Jahren nebenbei mit Linux beschäftige und im Ansatz etwas darüber zu wissen scheine, habe ich die ehrenvolle Aufgabe einige embedded Linux Systeme (nebenbei) zu pflegen und manchmal auch zu erweitern. Das sind meist kundenspezifische Lösungen die als Basis auf Linux aufsetzen. Problem: Mein Problem ist, das ich Änderungen/Erweiterungen eines solchen Systems in Form eines Patches brauche, um Updates für ausgelieferte Systeme bereitstellen zu können. Bisher habe ich diese Patches selbst "aufwendig" generiert. Das möchte ich in Zukunft automatisieren. Dabei können z.B. 20 Systeme mit Version A ausgeliefert sein und 30 Systeme enthalten schon Version B des Softwarestands etc. Mein Wunsch ist ein kumulatives Patch, das sowohl Version A, als auch Version B auf den Stand C befördern kann. Ausgangspunkt (Was ich habe): Jedes System ist versioniert, die Version kann zur Laufzeit ausgelesen werden (Umgebungsvariable). Von jeder Version habe ich ein Image der Master-CF-Karte inkl. MD5 Prüfsummen (erzeugt mit dd). Von jeder Version habe ich ein tgz File, dass das komplette Root-Filesystem enthält. Das tgz enthält alles was auf einem Ext2-Filesystem enthalten sein kann (Verzeichnisse, knodes, files, symbolische links, etc). Meine Anforderung: Ich möchte einen kumulatives Patch erzeugen, das jede vorzufindende Version auf einen neueren Stand bringen kann. Ein Downgrade muss nicht möglich sein. Prinzipieller Lösungsansatz am Beispiel: Im Beispiel gibt es ein System in drei Versionen 1.0, 1.1, 1.2. Entsprechend gibt es drei tgz-Files 1.0.tgz, 1.1.tgz und 1.2.tgz. 1.) Erstelle diffs für die Übergänge 1.0->1.1 und 1.1->1.2. Packe diese Änderungen in ein kumulatives Patch zusammen. 2.) Beim Aufspielen des patches wird auf dem laufenden System die installierte Version ermittelt. Wird z.B. 1.1 vorgefunden, dann werden nur die Änderungen des Überganges 1.1->1.2 aufgespielt. Dabei gibt es noch einiges zu beachten (benutzerdefinierte Einstellungen nicht aus versehen platt machen z.B.), aber das wäre die prinzipielle Vorgehensweise. Ich habe schon überlegt, ob das mit diff und patch möglich wäre, aber das funktioniert nicht für binäre Dateien, symbolische Links und knodes. Ausserdem müssten auch Zugriffsrechte beibehalten und ggf. angepasst werden. Ich würde das mit Bash-Skripten + einiger Hilfstools angehen. Gibts hierfür ( oder Teile davon) freie/kommerzielle Lösungen? Sorry für die lange Mail und danke an alle die bis zum bitteren Ende gelesen haben. Gruß, Gavin -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
Re: [PUG] Stammtisch-Erinnerung Januar 09
Stroke Unit klingt ja blumig. :-( Ich hoffe, Dein Vater kommt bald wieder auf die Beine. Gute Besserung! -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de --> http://www.pug.org/index.php/Benutzer:Martin <-- signature.asc Description: OpenPGP digital signature -- PUG - Penguin User Group Wiesbaden - http://www.pug.org
