Debian Archiv - Seite 4 von 4 - credativ®

Vorraussetzungen

Um Icinga-Web zu benutzen wird das idoutils Datenbank Backend benötigt. Dieses benutzt eine SQL Datenbank. Die Pakete unterstützten hier MySQL und PostgreSQL^®. Wichtig ist an dieser Stelle, das das Datenbanksystem for Icinga installiert wird. Deshalb sollte sichergestellt werden, dass die Datenbank installiert ist bevor die Icinga Pakete installiert werden. Im Detail bedeutet das für PostgreSQL^® die Pakete libdbd-pgsql, postgresql-client, postgresql und für MySQL libdbd-mysql, mysql-client, und mysql-server installiert werden müssen. Remote Datenbanken sind generell möglich, werden aber nicht vom Wizard unterstützt. Die Konfiguration muss in diesem Fall manuell erfolgen.

Installation Icinga unter Debian oder Ubuntu

Wenn man Icinga unter Debian oder Ubuntu installieren möchte, dann stellt sich zuerst die Frage: „Woher nehmen wenn nicht stehlen?“. Glücklicherweise ist Icinga bereits in den aktuellen Releases von Debian und Ubuntu enthalten. Debian Wheezy (7.0) und Ubuntu Raring (13.04) erscheinen mit Icinga 1.7.1.

Auch wem das bereits zu alt ist, dem kann trotzdem geholfen werden.

Debian Backports

Das Backports Team bietet – mit einer gewissen Verzögerung – Pakete für Icinga an die aus Debian Testing portiert wurden. Um dieses Repository einzubinden ist folgende Zeile in der sources.list erforderlich:

deb http://ftp.de.debian.org/debian debian-backports wheezy-backports main

Um Icinga dann zu installieren bedarf es noch eines

apt-get -t wheezy-backports install icinga icinga-web

Kommandos. Details dazu finden sich auf der Instructions Webseite des Projektes.

Debian Oldstable (Squeeze) wird hierbei nicht besonders gut unterstützt, an dieser Stelle sei auf auf debmon Repository verwiesen.

Debian Monitoring Project (debmon)

Das Debian Monitoring Projekt versucht für viele Pakete aus dem Icinga/Monitoring Umfeld möglichst aktuelle Pakete anzubieten. Dies beinhaltet unter anderem:

• Icinga
• Icinga-web
• pnp4nagios
• collectd
• Nagios

Die Einbindung ist wiederum entsprechend einfach:

deb http://debmon.org/debmon debmon-wheezy main

in die sources.list eintragen und danach wie gewohnt mit apt-get installieren. Anschliessend können die Pakete via apt-get install icinga icinga-web installiert werden. Aktualisierte Pakete erscheinen im Normalfall weniger als 48 Stunden nach einem Icinga Release in diesem Repository.

Ubuntu PPA

Für Ubuntu Releases gibt es je ein PPA für Icinga und für Icinga-Web. Nachdem man diese eingebunden hat kann man Icinga wie gewohnt via apt-get installieren:

# sudo add-apt-repository ppa:formorer/icinga
# sudo add-apt-repository ppa:formorer/icinga-web

Anschliessend können die Pakete via apt-get install icinga icinga-web  installiert werden.

 Konfiguration von Icinga und Icinga-Web

Um idoutils zu aktivieren muss die Datei /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample nach /etc/icinga/modules/idoutils.cfg kopiert werden. Anschliessend muss Icinga neugestartet werden (service icinga restart).

Für das Einliefern der Daten von Icinga in die Datenbank ist der Dienst ido2db zuständig. Dieser muss zuerst aktiviert werden:

sed -i -e 's/IDO2DB=no/IDO2DB=yes/' /etc/default/icinga

Danach kann der Dienst über service ido2db start gestartet werden.

Zugriff auf Icinga und Icinga-Web

Wenn alles richtig gelaufen ist, dann kann auf Icinga Classic nun via http://$yourhost/icinga und Icinga-web via http://$yourhost/icinga-web zugegriffen werden. Der Standardbenutzer für Icinga Classic ist icingaadmin und für Icinga-Web root. Sollte einem das Passwort entfallen sein, dann gibt es auch hier Hilfe:

Icinga Classic

# dpkg-reconfigure icinga-cgi
 oder
# httpasswd /etc/icinga/htpasswd.users icingaadmin

Icinga Web

# dpkg-reconfigure icinga-web

Debian Entwickler arbeiten mit vereinten Kräften an Debian GNU/Linux „Wheezy“.

Auch in diesem Jahr bietet das deutsche Open Source Support Centers der credativ GmbH in seinem Räumen in Mönchengladbach dem Debian-Projekt die Möglichkeit, im Rahmen einer „Bug Squashing Party“ an der nächsten Debian-Version „Wheezy“ zu arbeiten. Die Debian-Entwickler der credativ GmbH und zahlreiche Gäste aus dem In- und Ausland werden sich am Wochenende vom 2. bis 4. März treffen, um konzentriert an offenen Problemen zu arbeiten. Aus Italien werden in diesem Jahr auch Enrico Zini und Francesca Ciceri vom Debian Press Team erwartet. Auf der Bug Squashing Party wird auch an Piuparts gearbeitet werden, einem Tool das automatische Upgrade-Tests für die nächste Debian-Version Wheezy durchführt. Fehler können so rechtzeitig vor dem Release erkannt und beseitigt werden. Ein weiteres Ziel ist verbesserte Ipv6-Unterstützung. Debian-Entwickler Alexander Wirt: „Die Umstellung auf das neue Internet-Protokoll ist sehr wichtig, zu viele Programme in Debian unterstützen bisher nur das alte IPv4-Protokoll.“ Außerdem soll der Mailinglisten-Server des Debian-Projekts auf neue und schnellere Hardware umgezogen werden, damit der ansteigende Mailverkehr bewältigt werden kann. Parallel zur Bug Squashing Party trifft sich das Debian New Member Team, um an der Infrastruktur zu arbeiten, mit der das Debian-Projekt seine Benutzerkonten verwaltet und neue Mitglieder aufnimmt. Debian Account Manager Christoph Berg: „Wir arbeiten seit zwei Jahren an der Umstellung der alten PHP-Webseite auf ein modernes Web-Framework in Python, wir wollen das Wochenende nutzen, um die neue Version endlich fertig zu stellen.“ Weitere Informationen über die Bug Squashing Party bei credativ stehen auf den Seiten von debian.org zur Verfügung. Alle Blog-Artikel zu unserer Firma werden auch als Kategorie credativ samt eigenem Feed angeboten – und falls ihr nach Support und Services für Debian sucht, seit ihr bei uns ebenfalls richtig.

Dieser Artikel wurde ursprünglich geschrieben von Roland Wolters.

Das massenhafte Installieren von Debian-Maschinen lässt sich mit Hilfe von Preseeding und Netboot vereinfachen. Friedrich Weber hat in seinem Schülerpraktikum bei uns den entsprechenden Prozess gelernt – und in einem Howto fest gehalten.

Man stelle sich die folgende Situation vor: plötzlich finden sich einige zehn bis zwanzig fabrikneue Notebooks und eine wunderbare Idee, was man mit ihnen anstellen könnte: ein deutschsprachiges Debian installieren und das Ganze nach den eigenen Wünschen anpassen. Allerdings wird sofort klar, dass es nicht den geringsten Spaß macht, auf jedem Notebook manuell die Debian-Installation und -Konfiguration vorzunehmen.

An dieser Stelle kommt Debian Preseed ins Spiel. Das Konzept ist einfach und einleuchtend: Der normale Debian-Installer stellt während der Installation eine Reihe Fragen (zu Sprache, Partitionierung, Paketen, Bootloader etc.). Über Preseed kann man nun zu jeder zu stellenden Frage eine Antwort vorgeben. Nur Fragen, für die man nicht schon über Preseed eine Antwort vorgibt, stellt der Debian-Installer überhaupt noch. Im Idealfall werden nun nur noch am Anfang der Installation einige Fragen angezeigt, deren Antworten sich von Zielsystem zu Zielsystem unterscheiden und die der Administrator manuell abhandeln muss – nachdem diese beantwortet wurden, kann die Installation unbeaufsichtigt ablaufen.

Preseed arbeitet mit einer sehr einfach aufgebauten Konfigurationsdatei: der preseed.cfg. Sie beinhaltet, wie oben beschrieben, Antworten auf Fragen während der Installation, und das im debconf-Format. Eine solche Datei besteht aus mehreren Zeilen, von denen jede Zeile eine debconf-Konfigurationsoption – eine Antwort auf eine Frage – festlegt, zum Beispiel so:

d-i debian-installer/locale string de_DE.UTF-8

Diese Zeile beinhaltet als erstes Element den Namen des Paketes, das konfiguriert wird (d-i ist hier eine Kurzform für debian-installer), als zweites Element den Namen der Option, die gesetzt wird, als drittes Element den Typ der Option (hier string, eine Zeichenkette), und der Rest ist der Wert der Option.

Mit diesem Beispiel wird also die Sprache auf deutsch mit UTF-8-Kodierung gesetzt. Solche Zeilen kann man sich selbst zusammenbasteln, einfacher geht es aber mit dem Tool debconf-get-selections: Dieses Kommando gibt schlicht und einfach alle Optionen aus, die lokal gesetzt wurden.

Aus der Ausgabe können die gewünschten Einstellungen herausgefischt, gegebenenfalls angepasst und in die preseed.cfg kopiert werden. Hier ein Beispiel einer solchen preseed.cfg:

d-i debian-installer/locale string de_DE.UTF-8
d-i debian-installer/keymap select de-latin1
d-i console-keymaps-at/keymap select de
d-i languagechooser/language-name-fb select German
d-i countrychooser/country-name select Germany
d-i console-setup/layoutcode string de_DE
d-i clock-setup/utc boolean true
d-i time/zone string Europe/Berlin
d-i clock-setup/ntp boolean true
d-i clock-setup/ntp-server string ntp1
 
tasksel tasksel/first multiselect standard, desktop, gnome-desktop, laptop

d-i pkgsel/include string openssh-client vim less rsync

Mit diesen Optionen werden Spracheinstellungen und Zeitzone gesetzt, außerdem zu installierende Tasks und Pakete ausgewählt. Vollkommen unbeaufsichtigt wird diese Installation nicht ablaufen, aber ein Anfang ist es auf jeden Fall.

Nun stellt sich die Frage, woher Preseed eigentlich seine Konfigurationsdatei bezieht. Grundsätzlich ist es möglich, Preseed mit CD- und DVD-Images oder USB-Sticks zu nutzen. Wesentlich komfortabler ist es aber, ein Debian-netboot-Image zu benutzen, also einen Installer, der über das Netzwerk gestartet wird und bei dieser Gelegenheit auch seine Preseed-Konfiguration beziehen kann.

Dieses Booten über Netzwerk wird mit PXE realisiert und setzt ein System voraus, das von Netzwerkkarte booten kann. Zunächst wird das System angewiesen, von der Netzwerkkarte zu booten. Dafür fordert es von einem DHCP-Server per Broadcast eine IP-Adresse an.

Dieser DHCP-Server übermittelt aber nicht nur eine passende IP, sondern auch die IP eines sogenannten Bootservers. Ein Bootserver ist ein TFTP-Server, der einen Bootloader bereitstellt, mit dem der Administrator den gewünschten Debian-Installer auswählt. Gleichzeitig kann dem Debian-Installer hier über Boot-Optionen mitgeteilt werden, dass er Preseed benutzen soll und wo er die Preseed-Konfiguration finden kann. Hier ein Ausschnitt der PXELINUX-Konfigurationsdatei pxelinux.cfg/default:

label i386
kernel debian-installer/i386/linux
append vga=normal initrd=debian-installer/i386/initrd.gz netcfg/choose_interface=eth0 domain=example.com locale=de_DE debian-installer/country=DE debian-installer/language=de debian-installer/keymap=de-latin1-nodeadkeys console-keymaps-at/keymap=de-latin1-nodeadkeys auto-install/enable=false preseed/url=http://$server/preseed.cfg DEBCONF_DEBUG=5 -- quiet

Wenn der User also i386 eintippt, wird der Kernel debian-installer/i386/linux (zu finden auf dem TFTP-Server) heruntergeladen und gestartet, diesem werden außerdem eine ganze Menge Bootoptionen mit auf den Weg gegeben. Der Debian-Installer erlaubt das Angeben von debconf-Optionen als Bootparameter. Das ist sehr praktisch, denn dem Installer muss irgendwie mitgeteilt werden, wo die Preseed-Konfiguration im Netzwerk zu finden (preseed/url) ist.

Damit er diese Preseed-Konfiguration herunterladen kann, muss er allerdings auch ins Netzwerk eingebunden sein. Dafür werden ihm die nötigen Optionen übergeben (die Option für den Hostnamen wurde hier bewusst ausgelassen, denn jedes Zielsystem hat natürlich einen anderen Hostname). auto-install/enable würde die Spracheinstellungen verzögern, sodass sie erst nach der Netzwerkkonfiguration gestellt würden, damit diese Einstellungen ebenfalls aus der preseed.cfg gelesen werden könnten.

Das ist hier nicht notwendig, denn die Spracheinstellungen werden ebenfalls als Kerneloptionen übergeben, um zu gewährleisten, dass auch die Netzwerkkonfiguration deutschsprachig ist. Die vorgestellten Beispiele und Konfigurationsauszüge sind natürlich sehr allgemein gehalten und stark gekürzt. Trotzdem sollte dieser Blog-Post eine Einführung in das Preseed-Konzept in Verbindung mit netboot geboten haben. Abschließend noch eine vollständigere Fassung der preseed.cfg:

d-i debian-installer/locale string de_DE.UTF-8
d-i debian-installer/keymap select de-latin1
d-i console-keymaps-at/keymap select de
d-i languagechooser/language-name-fb select German
d-i countrychooser/country-name select Germany
d-i console-setup/layoutcode string de_DE

# Netzwerk
d-i netcfg/choose_interface select auto
d-i netcfg/get_hostname string debian
d-i netcfg/get_domain string example.com

# Paketmirror
d-i mirror/protocol string http
d-i mirror/country string manual
d-i mirror/http/hostname string debian.example.com
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string
d-i mirror/suite string lenny

# Zeitzone
d-i clock-setup/utc boolean true
d-i time/zone string Europe/Berlin
d-i clock-setup/ntp boolean true
d-i clock-setup/ntp-server string ntp.example.com

# Root-Account
d-i passwd/make-user boolean false
d-i passwd/root-password password geheimespasswort
d-i passwd/root-password-again password geheimespasswort

# Weitere APT-Optionen
d-i apt-setup/non-free boolean false
d-i apt-setup/contrib boolean false
d-i apt-setup/security-updates boolean true

d-i apt-setup/local0/source boolean false
d-i apt-setup/local1/source boolean false
d-i apt-setup/local2/source boolean false

# Tasks
tasksel tasksel/first multiselect standard, desktop
d-i pkgsel/include string openssh-client vim less rsync
d-i pkgsel/upgrade select safe-upgrade

# Popularity-Contest
popularity-contest popularity-contest/participate boolean true

# Kommando, das nach der Installation ausgeführt wird. `in-target` bedeutet, dass das folgende
# Kommando in der installierten Umgebung ausgeführt wird, nicht in der Installationsumgebung.
# Hier wird http://$server/skript.sh nach /tmp heruntergeladen, ausführbar gemacht und ausgeführt.
d-i preseed/late_command string in-target wget -P /tmp/ http://$server/skript.sh; in-target chmod +x /tmp/skript.sh; in-target /tmp/skript.sh

Alle Howtos dieses Blogs werden auch als Kategorie Howto samt eigenem Feed angeboten – und falls ihr nach Support und Services für Debian sucht, seit ihr bei uns ebenfalls richtig.

Dieser Artikel wurde ursprünglich geschrieben von Roland Wolters.

Nach der Einführung in RHCS geht es jetzt ins Eingemachte: die Installation von RHCS unter Debian, um einzelne KVM-Gäste als Dienst anzubieten.

Die Hintergründe von RHCS haben wir bereits erklärt. Die konkrete Umsetzung wird am Beispiel zweier Hosts mit einem Shared Storage erklärt, die als Service verschiedene KVM-Gäste anbieten.

Installation der Nodes

In diesem Setup sind die Nodes die Maschinen, auf denen KVM läuft. Jeder darauf laufende KVM-Gast ist wiederum ein über RHCS verwalteter Dienst. Bei der Installation der KVM-Hosts ist auf mehrere Punkte zu achten:

• /tmp/ und /var/ sollten auf verschiedenen Partitionen liegen, das verbessert die Performance.
• Es sollten Debian-Backports genutzt werden, insbesondere für die Kernel.
• Alle IP-Adressen sollten via DNS in beide Richtungen auflösbar oder in /etc/hosts eingetragen sein.
• Der Hostname darf nicht auf 127.0.0.1 zeigen, das führt zu Problemen mit dem Cluster Management System CMAN.
• /etc/hosts/ und /etc/resolv.conf sollte auf allen Nodes gleich sein.
• ssh-Keys sollten auf allen Nodes passwortlos für root bestehen und auf alle anderen Nodes verteilt werden.
• Aus Performance-Gründen ist es besser, den aktuellesten stabilen Kernel zu installieren. Allerdings lässt linux-image-2.6.32-bpo.2-amd64 die Gast-Kernel >= 2.6.30 crashen, ein Patch ist aber verfügbar, siehe #573071.
• Die Netzwerk-Geräte sollten für einen guten Überblick klar benannt sein – zum Beispiel rhcs-backbone und external anstatt eth0 und eth1.

Einrichtung des Shared Storage

Ein zentrales Element des RHCS ist das Shared Sotrage, auf das die Nodes gemeinsame zugreifen. In diesem Beispiel nehmen wir einen „normalen“ Rechner, und installieren auf diesem ein iSCSI-Target:

apt-get install iscsitarget iscsitarget-source
echo 'ISCSITARGET_ENABLE=true' > /etc/default/iscsitarget
m-a a-i iscsitarget

Hier ist zu beachten, dass das iscsi-Target korrekt bauen muss, siehe auch #566740. Eingerichtet wird die Maschine, welche das Shared Storage bereit stellt, via /etc/ietd.conf:

IncomingUser discovery_in YourSecurePwd1
OutgoingUser discovery_out YourSecurePwd2
Target YOURMACHINE:clvm1
       IncomingUser node_in YourSecurePwd1
       OutgoingUser node_out YourSecurePwd2
       Lun 0 Path=/dev/sdx1,Type=blockio

Auf den Nodes muss das Target korrekt angesprochen werden. Dies wird in der /etc/iscsi/iscsid.conf definiert:

discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = discovery_in
discovery.sendtargets.auth.password = YourSecurePwd1
discovery.sendtargets.auth.username_in = discovery_out
discovery.sendtargets.auth.password_in = YourSecurePwd2
node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = node_in
node.session.auth.password = YourSecurePwd1
node.session.auth.username_in = node_out
node.session.auth.password_in = YourSecurePwd2

Gestartet wird der Dienst mit /etc/init.d/open-iscsi start. Vorhandene Targets werden mit den folgenden Befehlen gesucht, gelöscht oder hinzugefügt:

# discovering the targets
iscsiadm -m discovery -t st -p YOURMACHINE -P 1
# deleting target on wrong interface
iscsiadm -m node -p 192.168.0.100:3260,1 -o delete
# opening the portal
iscsiadm -m node --targetname "iqn.2010-03.YOURMACHINE:clvm1" --portal "YOURMACHINE:3260" --

VM setup

Die virtuellen Maschinen werden via KVM bereit gestellt. Dafür muss zuerst die passende Software installiert werden:

apt-get install linux-image-2.6.32-bpo.2-amd64 kvm libvirt-bin virtinst -t lenny-backports

Bei der Einrichtung der Bridge für die Gäste muss darauf geachtet werden, dass der Bridge-Name für alle Nodes gleich sein muss. Auch die libvirt-Konfiguration muss gleich sein, es ist daher hilfreich, auf git und vergleichbare Techniken zurück zu greifen. Danach können die Gäste mit

virt-install -n <NAME> -r 256 --vcpus=1 --disk path=/dev/vg_cluster#/<LV> \
  -c /root/debian-<VERSION>-amd64-netinst.iso --vnc --noautoconsole --os-type linux \
  --os-variant debianLenny --accelerate --network=bridge:bridge0 --hvm -k de

installiert und mit virt-viewer -c qemu+ssh://:/system angesehen werden.

RHCS setup

Der nächste Schritt ist das Aufsetzen von RHCS selbst – dafür müssen in erster Instanz die Programme installiert und aufgerufen werden: apt-get install redhat-cluster-suite. Die dadurch bereit gestellten NFS-Dienste werden aber nicht gebraucht:

invoke-rc.d nfs-kernel-server stop
invoke-rc.d nfs-common stop
invoke-rc.d portmap stop
update-rc.d -f nfs-kernel-server remove
update-rc.d -f nfs-common remove
update-rc.d -f portmap remove

Ein anderes Problem ist, dass das Programm system-config-cluster nicht unter Lenny zur Verfügung steht. Es wurde von credativ-Mitarbeiter Philipp Hübner paketiert und ist in Debian erst ab Squeeze enthalten. Durch einen Backport kann system-config-cluster aber auch auf Lenny genutzt werden:

wget --no-check-certificate https://www.credativ.com/~phu/lenny-backports/system-config-cluster/system-config-cluster_1.0.53-1_all.deb
dpkg -i system-config-cluster_1.0.53-1_all.deb
apt-get -f install
apt-get install xauth

Damit LVM Locking Cluster-weit funktioniert, muss in der /etc/lvm/lvm.conf im Abschnitt global eine Anpassung vorgenommen werden:

 locking_type = 3

Falls wie empfohlen ein neuerer Kernel eingesetzt wird, liegt das Modul lock_dlm nicht mehr vor. Daher muss das Init-Script von CMAN angepasst werden, die Zeile modprobe lock_dlm 2>&1 || return 1 muss auskommentiert werden. Außerdem unterstützt RHCS 2 nur XEN, für libvirt-Unterstützung muss der Ressource Handler vm.sh geladen werden – er liegt für Debian Squeeze bereit:

wget --no-check-certificate https:///www.credativ.com/~phu/vm.sh -O /usr/share/cluster/vm.sh
chmod +x /usr/share/cluster/vm.sh

RHCS selbst wird gestartet mittels

/etc/init.d/cman start
/etc/init.d/clvm start
/etc/init.d/rgmanager start

Fencing

Fencing beschreibt das automatisierte Neutralisieren von Nodes, die nicht mehr reagieren. Wir setzen in unserem Beispiel dafür eine per Netz steuerbare Steckdose ein, NETIO-230A. Es liegt bisher kein fence agent für dieses Gerät vor, aber mit Hilfe der verfügbaren Python-Bibliothek kann ohne Weiteres ein solcher geschrieben werden.

Abschließende Worte

Dieses Howto zeigt, dass das Einrichten von RHCS unter Debian mit einfachen Schritten möglich ist – wenn auch je nach Einsatz weitere Anpassungen vorgenommen werden müssen. Dabei helfen wir übrigens gerne – Open Source Hochverfügbarkeits-Lösungen gehören zu unseren Spezialitäten, und Services und Support bei KVM-Virtualisierung ist unser Alltagsgeschäft.

Dieser Artikel wurde ursprünglich geschrieben von Roland Wolters.

Das Skolelinux-Team hat die Version 5.0 seines beliebten Schulservers veröffentlicht, der jetzt auf Debian Lenny aufsetzt. Die Distribution Skolelinux, auch Debian-Edu genannt, ist eine angepasste Debian-Version für den Betrieb eines Schulnetzes unter Linux: mit nur wenigen Schritten können so auch technisch unbedarfte Nutzer mit wenigen Handgriffen einen zentralen Schulserver mit Terminal-Server und Thin-Clients, Workstations und Laptops als Arbeitsplatzrechner installieren. Auch die Integration von bestehenden Windows-Installationen wird unterstützt. Mit der Veröffentlichung der Version 5.0 wurde auch Skolelinux auf die Software-Basis aktueller Debian-Installationen gehievt. Neben der deutlich besseren Unterstützung neuerer Hardware ist auch die mitgelieferte Software so deutlich aktueller und somit ansprechender für Schüler und Schulen. Zu den hervorstechenden technischen Neuerungen dieser Version gehören außerdem:

• Der GNOME Desktop wird nun zusätzlich zu KDE unterstützt.
• Verbesserter Schüler-Desktop mit Lernsoftware-Verknüpfungen zu GCompris, Kalzium, KGeography, KMplot, KStars, Stopmotion und der OpenOffice Suite.
• Verbesserte LTSP-Server Konfiguration:
  • Neben den traditionellen Thin Clients sind plattenlose Arbeitsstationen jetzt auch ‚out of the box‘ unterstützt.
  • Das neue PXE-Start-Menü erlaubt plattenlosen Arbeitsstationen das Booten über das Netzwerk oder über lokale Medien.
  • Plattenlose Arbeitsstationen (Diskless Workstations) erhalten ihre Software vom Server und führen sie dann lokal aus, sie kann also zentral auf dem Server gewartet werden.
• Die Dokumentation wurde weiter verbessert und von Englisch nach Deutsch, Italienisch und Norwegisch übersetzt.
• Verbessertes und vereinfachtes Benutzer- und Maschinen-Administrations Werkzeug LWAT (LDAP Web-based Administration Tool).
• Verbesserte Browser-Unterstützung mit freien Softwareprodukten wie Gnash, Java und anderen Plug-ins.
• PulseAudio sorgt zusätzlich neben ALSA und dem OSS Sound System für eine verbesserte Audio- und Multimedia-Leistung.
• Verbessertes Maschinen- und Netzwerkmonitoring, das jetzt den Status aller zum Netzwerk hinzugefügten Maschinen automatisch meldet.

Philipp Hübner, ehrenamtlicher Helfer des Skolelinux-Projekts und Mitarbeiter bei credativ unterstreicht insbesondere die Modernität der neuen Version:

Skolelinux hat mit der Lenny-Version einen großen Schritt nach vorn gemacht: durch die nahtlose Integration von Diskless Workstations out-of-the-box wird Skolelinux modernen Anforderungen und der stetig zunehmenden Leistung von Computern gerecht. Auf diesem Weg wird die Performance von Workstations mit dem geringen Wartungsaufwand von Thin-Clients vereint.

Skolelinux wird derzeit in mehreren Bundesländern in Deutschland produktiv eingesetzt oder für den Einsatz getestet. So wurde in Rheinland-Pfalz ein von der credativ GmbH betreutes Skolelinux-Evaluationsprojekt 2009 erfolgreich abgeschlossen. Die Lösung wird dort in immer mehr Schulen im täglichen Schulbetrieb genutzt, zertifizierte Dienstleister wie die credativ GmbH bieten den Schulen und Schulträgern bei Bedarf professionellen Support. Außerhalb Deutschlands ist die größte bekannte Installation in Extremadura: dort nutzen 250.000 Schüler Skolelinux in ihren Schulen.Wir von credativ gratulieren Skolelinux für dieses Release und wünschen das Beste für die Zukunft!

Dieser Artikel wurde ursprünglich geschrieben von Roland Wolters.

Die Debian-Bug-Squashing-Party des Wochenendes war ein großer Erfolg: etwa 200 Fehler wurden aus der kommenden Debian-Version entfernt. Am Wochenende fand in credativ’s Büro in Mönchengladbach die BSP2010 statt. Ziel war es, Bugs des kommenden Debian releases zu finden und zu beseitigen. Und die Statistik kann sich sehen lassen:

Das macht in der Summe 200 Fehler. Darüber hinaus wurden Informationen zu weiteren 100 Bugs gesammelt, um das Fixen dieser in Zukunft zu erleichtern. Und es gab selbstverständlich jede Menge QA – die Arbeit der leisen Helden. Aber auch der Flurfunk weiß etwas zu berichten: es heißt, backports.org ist kurz davor, ein offizielles Debian-Projekt zu werden. Und noch bevor das geschieht, wird backports eine neue Homepage auf ikiwiki-Basis samt neuem Design bekommen. Auch die „Besucher“ aus der Ferne waren von der Party begeistert: Steve McIntyre:

thanks to the folks at credativ for hosting and participating in the BSP – we got a huge amount of work done towards the next release and had a great time doing it!

Stefano Zacchiroli:

My 1st Mönchengladbach BSP, won’t be the last! Lots of cool people and hacking, and I’ve enjoyed my 1st „traditional“ formorer’s chilli too 🙂

Herzlichen Dank an alle, die gekommen sind – lehnt euch nun zu zurück, und genießt die Photos des Events.

Dieser Artikel wurde ursprünglich geschrieben von Roland Wolters.