Difference between revisions of "FOSSGIS e.V. GISLive"
Jump to navigation
Jump to search
Wiki-Sholler (talk | contribs) |
m (moved Category:Local Chapters to Category:FOSSGIS eV) |
||
(6 intermediate revisions by 4 users not shown) | |||
Line 3: | Line 3: | ||
==Projektbeteiligte== | ==Projektbeteiligte== | ||
bitte eintragen, sofern Interesse an einer Mitarbeit besteht: | bitte eintragen, sofern Interesse an einer Mitarbeit besteht: | ||
− | * [[Sebastian Holler | + | * [[User:Sholler | Sebastian Holler]] (steht als "Projektverantwortlicher" zur Verfügung) |
+ | * [[User:lars | Lars Lingner]] | ||
* ... | * ... | ||
Line 111: | Line 112: | ||
... | ... | ||
− | [[ | + | == See also == |
− | [[Category: | + | |
+ | * [[Live GIS Disc]] | ||
+ | |||
+ | [[Category:FOSSGIS eV]] |
Latest revision as of 02:47, 17 March 2009
zurück zur Hauptseite von FOSSGIS_e.V.
Allgemeines
Projektbeteiligte
bitte eintragen, sofern Interesse an einer Mitarbeit besteht:
- Sebastian Holler (steht als "Projektverantwortlicher" zur Verfügung)
- Lars Lingner
- ...
Technik
Nutzung von virtuellen Servern als Buildmachine
- Für die FOSSGIS08 hatte ich die zunächst eine virtuelle Buildmachine auf OpenSuSE unter vmWare-Server laufen. Dies war ohne Probleme mit bridged networking möglich. Letztendlich bin ich aber doch mit dem Buildsystem auf einen physischen Server umgezogen, da der Wirtsserver keine Ausreichenden Kapazitäten hatte. Verwendung von vmWare-Server funktioniert bei ausreichender Power der Wirtsmaschine und entsprechend großzügiger Ausstattung der virtuellen Buildmaschine gut. Ob auch NAT statt Bridged möglich ist weiß ich nicht.
- Die Verwendung von VirtualBox auf dem Wirtssystem wurde noch nicht getestet.
- Wie gut XEN einsetzbar wäre ist zu klären.
Anforderungen an eine Maschine zum Bauen von Live-Images
- Virtuelle Maschine mit vollem SSH-Zugriff auf root-Ebene
- Debian (testing) als OS
- Platz für ein lokales, gespiegeltes Debian Repository (binaries+sources) - besser noch: für mindestens 2-3 Snapshots (beliebige Tagesstände) dieses Repositories.
- pro Imagevariante > 10GB HDD-Speicherplatz (PE, VE, jeweils die letzten 2 Versionen + Skripte, lokale Dateien und Diverses => >> 150 GB HDD)
- entsprechend großzügige Ausstattung mit RAM und Mehrkernprozessoren werden beim bei Bauen parallel eingesetzt (Erzeugung von squashfs, tar, gzip, ...)
- hervorragende Netzwerkanbindung, da durch die Buildvorgänge mit unter hoher Traffic (ziehen mehrerer GB von Debian-repos) bei den Buildvorgängen erzeugt wird.
Konzept: verteiltes Arbeiten am GISLive-Projekt
derzeitiger Stand
- das Bauen der Live-DVD erfolgt prinzipiell automatisiert mit Hilfe von Shell-Skripten
- Basis sind die Skripte des debian-live Projekts
- darauf aufbauend ist das "GISLive-buildscript" entwickelt worden
- das ursprünglich nur aus einer einzigen Datei bestehende GISLive-buildscript ist in den vergangenen Monaten zwecks besserer Übersichtlichkeit in einzelne Module aufgeteilt worden
- die Erstellung der Live-DVD (Design / Debian-Paketbau / LiveSystem-Bau / Pflege der build-Skripte) geschieht momentan zentral auf einem Arbeitsplatz-Rechner (nicht auf einem von außen zugänglichen Server)
- die GISLive-Skripte sind dementsprechend auf dieses eine "Build-Environment" hin angepasst
Ziel
- zukünftig soll die (Team-)Arbeit am GISLive-Projekt verteilt möglich sein, wie dies auch bei anderen OpenSource-Projekten üblich ist
- das umfasst alle 4 genannten Teilaspekte des Projektes:
- Design / artwork
- Erstellen von Debian-Paketen aktueller FOSSGIS-Software
- Pflege der build-Skripte
- Steuern des eigentlichen Build-Vorgangs
- ferner ist anzustreben, dass der Bauvorgang künftig auf leistungsfähigen Servern abläuft, da das Bauen sehr Resourcen-intensiv ist (hinsichtlich RAM und Prozessorleistung) und eine erhebliche Menge an "Net-Traffic" (Up- und Download) entsteht
Konzept
Überblick
- um größtmögliche Flexibilität zu erreichen, ist es nötig, die Teilaufgaben entsprechend den Erfordernissen auf verschiedene Server auszulagern (Server 1-3, siehe weiter unten)
- die künftige Arbeit am GISLive-Projekt ist in etwa so zu beschreiben:
Build-Skripte und artwork modifizieren
- zur Weiterentwicklung der Build-Skripte richtet sich das Projektmitglied eine lokale Entwicklungsumgebung ein, bestehend aus einem aktuellen Debian-System (Pakete für svn-client und debian-live werden zusätzlich benötigt!)
- nun folgt ein "checkout" der aktuellen Skripte aus dem SVN-Repository)
- das SVN-Repository beinhaltet:
- ein initiales Shellskript (=setEnv-Skript), welches zum Ziel hat, die Systemumgebung für die Verwendung der übrigen Build-Skripte vorzubereiten und das Vorhandensein benötigter Programme zu kontrollieren
- das gesamte "artwork" des Projekts
- die eigentlichen Build-Skripte (wiederum unterteilt in einen Editions-abhängigen und -unabhängigen Teil)
- das setEnv-Skript ist in einem ersten Schritt an die lokale Entwicklungsumgebung anzupassen (Setzen diverser Variablen, Einrichten des Bauverzeichnisses, evtl. Einbinden zusätzlicher Partitionen, Definieren des zu verwendenden Debian-Repositories, automatisches Updaten der Build-Skripte aus dem SVN-Repository, ...)
- dadurch wird für die eigentlichen Build-Skripte eine einheitliche Umgebung erzeugt, was die gemeinsame Weiterentwicklung dieser Skripte ja überhaupt erst ermöglicht
- nun können die Build-Skripte (oder artwork) lokal modifiziert, getestet und zurück in das SVN-Repository übertragen werden
Bauen neuer Debian-Pakete
- das Bauen von Debian-Paketen aus den Quelltexten diverser GIS-Software setzt voraus, dass die lokale Systemumgebung exakt der Zielumgebung (Live-DVD) entspricht (evtl. Update des Debian-Systems durchführen!!!)
- ferner müssen alle für das Übersetzen der Quelltexte nötigen Programmier-Tools sowie die entspr. Abhängigkeiten des zu erstellenden Programms installiert sein (evtl. sollte eine zentrale Checkliste erstellt werden; auch bzgl. Abhängikeiten/Kompilierreihenfolge der einzelnen GIS-Programme untereinander)
- nach dem Bauen können die Dateien (binaries+sources) zum Web-Server ins Repository übertragen, sowie die beiden Dateien Packages.gz und Sources.gz aktualisiert werden
Starten des Bauvorgangs
- während die Weiterentwicklung der Build-Skripte verteilt auf den lokalen Umgebungen der einzelnen Projektmitglieder geschieht, findet das Bauen der GISLive-Versionen zentral auf einem Build-Server statt
- nach dem Einloggen wird zuerst das setEnv-Script ausgeführt
- danach kann man den Bauvorgang starten (wahlweise mit oder ohne Quelltextarchiv)
- als Ergebnis erhält man eine ISO-Datei und, gegebenenfalls, zusätzlich ein Quelltextarchiv (*.tar.gz)
Veröffentlichen einer neuen GISLive-Version
- um die auf dem Build-Server erzeugten Dateien zum Download freizugeben, sind diese Dateien auf den Web-Server zu übertragen
- hier würde es sich auszahlen, wenn Quell- und Zielserver eine möglichst leistungsfähige Anbindung an das Internet hätten (Übertragungsvolumen ca. 3-4 GByte pro Edition inkl. Quelltexte)
- auf dem Web-Server sollten zwei verschiedene Downloadverzeichnisse eingerichtet sein
- ein öffentliches Verz. für den Zugriff auf die finalen Versionen inkl. Quelltext (die GPL verpflichtet uns beispielsweise, zu jeder veröffentlichten Version die Quelltexte mind. 3 Jahre lang vorzuhalten)
- ein vereinsinternes (nicht öffentliches) Verzeichnis für Testversionen (hier würde die Veröffentlichungspflicht der Quelltexte nicht greifen)
Server 1: build-server
- Aufgabe
- Bauen der Live-DVD
- techn. Anforderungen
- siehe hier
Server 2: svn-server
- Aufgabe
- Verwaltung der GISLive-Skripte und der "artwork-files"
- techn. Anforderungen
- aufgesetzter SVN-Server (eigentlich logisch ...)
- Schreibrecht für Projektmitglieder
- Leserecht öffentlich oder nur für Projektmitglieder?? (die Frage ist, ob wir die SVG-Dateien unseres "artworks" inkl. Vereinslogo und GISLive-Logo öffentlich zugänglich machen wollen - die Build-Skripte werden unter GPL gestellt)
- commits-Mailingliste
- devel-Mailingliste ??
Server 3: web-server
- Aufgabe
- a) (teilweise) öffentliches Debian-Repository für aktuelle FOSSGIS-Software + b) öffentliche Downloadmöglichkeit der finalen GISLive-Versionen sowie nicht-öffentliche Downloadmöglichkeit von Testversionen
- techn. Anforderungen
- aus dem Web erreichbares Verzeichnis für die Dateiablage
- weiteres, Passwort-geschütztes Verzeichnis
- WebSpace ca. 20 GByte (jew. aktuelle GISLive-Versionen + Sourcen für mind. 3 Jahre)
- Verzeichnisstruktur für ein Debian-Repository (siehe http://debiananwenderhandbuch.de/debianrepositories.html)
- dpkg-scanpackages, dpkg-scansources und gzip werden für die Erstellung der Dateien Packages.gz und Sources.gz benötigt
- der bereits vorhandene "unfug-Server" (z.Zt. noch: http://www.gav-ev.de) sollte dafür eigentlich verwendet werden können
notwendige Schritte zur Umsetzung des Konzeptes (inkl. Zuständigkeit)
wer etwas zur Umsetzung des Konzeptes beisteuern kann, sollte sich hier eintragen ...
- Umarbeiten der vorhandenen GISLive-Skripte für den Einsatz auf dem Server --> Sebastian
- Beschaffung des Build-Server --> ??
- Beschaffung des SVN-Server --> ??
- ( Web-Server ist bereits vorhanden)
- Einrichten des Build-Server --> ??
- Einrichten des SVN-Server/Repository --> ??
- Einrichten des Repositories auf dem Web-Server --> Sebastian
- (Download-Verzeichnisse auf dem Web-Server sind bereits eingerichtet)
Editionen
PE preview edition
...
VE variety edition
...