History

Ziel

Ziel dieser Seite ist eine Liste anzubieten, die alle noch nicht dokumentierten OpenSLX Features beinhaltet.

Bei Zeit, Muße und sprachlicher Fähigkeit kann diese Liste kontinuierlich abgebaut werden.

What, if i want to install a system with gnome and kde togheter?  :)
Then you'd simply define your own selection (in /etc/opt/openslx/distro- info/suse-10.2/settings). Just give your selection a unique name and make it depend on KDE & Gnome (by specifying "base = kde,gnome"). Support for the latter has just been introduced  ;-)

Siehe auch r1628

  • [[SlxPlugins|Plugin]-Dokumentatation vervollständigenaktualisieren insbesondere die Zusammenhänge von [wikivmchooser vmchooser] => [wikivmware vmware]] => Windows Logintool sollten klar werden (XML-File)

Entwicklungsdoku
Fehlermeldung =
Aufgetauchte Ausgabe: °°° unable to invoke syscall 'personality'! (Ungültige Adresse)

Erläuterung: Die Fehlermeldung ist eine Warnung ('°°°' -> Warnung, '***' -> Fehler), d.h. der Wechsel in die 32-Bit Personality schlägt fehl, die Plugin-Installation/Deinstallation wird aber fortgesetzt. Ob das Plugin allerdings nach der Installation auch funktioniert, hängt wohl davon ab, ob das Plugin an irgendeiner Stelle durch die falsche Personality (eben x86_64 statt i586) verwirrt wird. Dies ist z.B. dann wahrscheinlich, wenn Pakete installiert werden (denn der Paketmanager würde in diesem Fall versuchen, 64-Bit Pakete in das 32-Bit Vendor-OS zu installieren).
[BR]]

Problem mit Ash/XX_plugin.sh

Gerade auf .4.2. gesehen:

/init: /etc/plugin-init.d/70_vmware.sh: line 253: syntax error: "fi"unexpected
Kernel panic - not syncing: Attempted to kill init!

Der Fehler bassiert auf folgenden Code
if [ "${vmware_kind}" = "vmpl2.0" ]; then
      # TODO: setup up kernel files
fi

ein einfaches 'echo ""' innerhalb der if Funktion behebt das Problem:

if [ "${vmware_kind}" = "vmpl2.0" ]; then
      # TODO: setup up kernel files
      echo "" 
fi

Pluginnamen

Pluginnamen dürfen kein "-" (Bindestrich/Minus) Zeichen enthalten. Bei Bedarf sollte hier auf "_" zurückgegriffen werden.

Speicherplatz und Zeit beim export auf Entwicklungssystemen sparen

Das exportieren von vendorOSen benötigt teilweise einiges an Zeit. Dies ist bei der Entwicklung teilweise unschoen. Ausserdem wird hier auch einiges an Speicherplatz benötigt, der auf kleinen Entwicklungsmaschinen zu Engpaessen führen kann.

Laut Ticket #184:

There is an implementation by zooey available now (citation from email to the devel list): "In order to speed up turn-around times during development, I have added support for an optimized way of using NFS-exports:

If /srv/openslx/export/nfs is a bind-mount to /var/opt/openslx/stage1, the rsync step of doing an NFS export will now simply be skipped (and a corresponding warning will be shown). Thus, there's no more need to wait for rsync to collect the handful of changed files out of the thousands that make up the vendor-OS ... :-)

Naturally, this is not recommended for production use, but it should do no harm for testing setups.

root@archive:~# mount --bind /var/opt/openslx/stage1 /export/nfs

Pluginentwicklung: temporaeres tmp Verzeichniss

14:10 < olta> ... der tmp-Folder steht innerhalb des chroot als 
              /tmp/slx-plugin/<plugin-name> zur Verfügung - außerhalb des 
              chroot liegt das unter 
              /var/opt/stage1/<vendor-os>/tmp/slx-plugin/<plugin-name>
14:12 < olta> Aber nicht vergessen: dieser Pfad wird automatisch gelöscht, 
              nachdem das chroot wieder verlassen wurde. Ist also wirklich nur 
              für temporären Kram geeignet.

Pluginentwicklung: Kernelmodule uebersetzen

Beim kompilieren der Kernelmodule musst man darauf achten gegen welchen Kernel kompiliert wird. Die ganzen Systeminfos in Stage1 (im Chroot), sind die vom Hostsystem und nicht vom vendorOS. Hier muss man an passender Stelle das ganze faken. Bei vmware hat es hier gereicht in der Makefile die Variable VM_UNAME zu manipulieren.

Hier sollte man hingehen und zukuenftig gegen alle Kernelversion (/boot/vmlinuz-*) kompilieren, da der Kernel fuer die unterschiedlichen Clients definiert werden kann.
Automatisch ausgewaehlter Kernel ist allerdings der bei ls ganz oben landet und die hoechste Version hat. Fuer den Anfang sollte die Uebersetzung gegen den default Kernel ausreichen. Bspl. fuer den Default gewaehlten:

  ls /boot/vmlinuz*|grep -v -e "^/boot/vmlinuz$$" \
    |sed 's,/boot/vmlinuz-~'|sort|tail -n 1

(Das $$ ist weils im Shellscript ist, sonst waere $ ausreichend.)

Pluginentwicklung: Busybox in Stage1

1. das Busybox mit richtiger Lib steht im Stage1-Chroot zur Verfügung!
2. wenn man die Busybox sonst braucht mit Pfad und LDPRELOAD=libuclib aufrufen ...

Damit sollte rpm2cpio etc. via Busybox im Stage1-Chroot zur Verfuegung stehen :)

Entwicklung (u.a. auch Pluginentwicklung): Manpages

Es sind alle perldoc Pages aufgefuehrt. Allerdings wird dieser Abschnitt unterteilt in zwei Punkte: "relevante" und "weniger relevante" Dokumentation

Liste mit den persoenlich eher wichtigeren Dokumentation, fuer den durschnittlichen (Plugin-)Entwickler:

#OpenSLX::Basics - implements basic functionality for OpenSLX.
perldoc /opt/openslx/lib/OpenSLX/Basics.pm

#OpenSLX::OSPlugin::Base - the base class for all OpenSLX OS-plugins
# Important for plugin development. Describe functions we have for pluginname.pm
perldoc /opt/openslx/lib/OpenSLX/OSPlugin/Base.pm

#OpenSLX::OSPlugin::Engine - driver class for plugin handling.
perldoc /opt/openslx/lib/OpenSLX/OSPlugin/Engine.pm

Liste mit den persoenlich eher nicht relevanten Dokumentation fuer den durschnittlichen (Plugin-)Entwickler:

#OpenSLX::ConfigDB - the configuration database API class for OpenSLX
perldoc /opt/openslx/lib/OpenSLX/ConfigDB.pm

#OpenSLX::ConfigFolder - implements configuration folder related functionality for OpenSLX.
perldoc /opt/openslx/lib/OpenSLX/ConfigFolder.pm 

#OpenSLX::ScopedResource - provides a helper class that implements the ’resource-acquisition-by-definition’ pattern.
perldoc /opt/openslx/lib/OpenSLX/ScopedResource.pm

#OpenSLX::Syscall - provides wrapper functions for syscalls.
perldoc /opt/openslx/lib/OpenSLX/Syscall.pm

#OpenSLX::MetaDB::Base - the base class for all MetaDB drivers
perldoc /opt/openslx/lib/OpenSLX/MetaDB/Base.pm

#DBI.pm - provides DBI-based implementation of the OpenSLX MetaDB API.
perldoc /opt/openslx/lib/OpenSLX/MetaDB/DBI.pm

#OpenSLX::OSSetup::System::Base - the base class for all OSSetup backends
perldoc /opt/openslx/lib/OpenSLX/OSSetup/Distro/Base.pm

#OpenSLX::OSSetup::MetaPackager::Base - the base class for all OSSetup::MetaPackagers
perldoc /opt/openslx/lib/OpenSLX/OSSetup/MetaPackager/Base.pm 

#OpenSLX::OSSetup::Packager::Base - the base class for all OSSetup::Packagers
perldoc /opt/openslx/lib/OpenSLX/OSSetup/Packager/Base.pm