User:Lazyboy

Henning Sprang - http://www.sprang.de

I am technically responsible for this wiki, so please contact me for any problems that arise with it. Apart from that I am a happy FAI user who uses FAI for his small home network, and used to use it at work some time ago when still being a systems administrator. As you can see below, I have lots of ideas of what could and should be done with FAI.

other stuff I published about FAI

• Installing Ubuntu Linux with FAI
• helper scripts for fai-cd testing with a qemu vm

contact

• irc: lazyb0y at freenode
• mail: henning at sprang.de

my personal Todo list for FAI development:

• make it easier to install Ubuntu Linux with FAI by creating a better FAI package for Ubuntu and creating a modified FAI package for Debian Sarge that can install Ubuntu:
  • create an ubuntu package from the newest (now 2.8.3) FAI version:
    • set up new production Server with FAI for sarge and preliminary ubuntu support, svn, dhcp, dns, nfs data and correct config
    • install hoary on rio to use it as the install server
    • install 2.8.3 on rio and do all necccessary changes to get it to run cleanly and install hoary on the notebook
    • in general, look deeper into everything that comes with FAI and change everything targeted at debian sarge to work with ubuntu. (2 hours - 1 week)
    • create a diff against the original FAI package
    • create a new 2.8.3-ubuntu1 source and binary package and put it on sprang.de, announce this on #ubuntu-motu and on the motu mailing list
  • also try to create a fai-cd for and with ubuntu!
  • the debian debootstrap has no scripts for ubuntu debootstrapping - it would be nice if it had, so it would be possible to install ubuntu from a debian server -> tell debootstrap maintainer about this, instead we can include a debootstrap script stolen from ubuntu in FAI, e.g. in /etc/fai/distributions/...
    • probably it's not useful to have debootstrap scripts in Debian debootstrap - it wil most likely be too old very fast, because of ubuntu's release cycle
  • full install system and hardware detection integration - for now, my patched version of FAI for ubuntu only installs a system with ubuntu packages, with only as much automatic coniguration as a debootstrapped ubuntu system would have, I'd like to be able to have the full power of ubuntu's hardware detection in an automatic install, and compare with the "standart" ubuntu installer which of its features would be useful and possible in an automated install.
  • some notes:
    • what's simple-patchsys/how does it work?
    • what's debdiff?
    • learn more about cdbs - common build system for Debian packages - http://www.ngolde.de/cdbs.html

• fai vm testing - developing FAI is hard when you have not so many machines available, or if you are on the road, so I wanna be able to test FAI on some virtual machine software. I already do that succesfully for fai-cd, having the fai-server for cd creation in a chroot environment. You can find hints on that it the helper scripts section of this wiki. Network installations are still not completely solved
  • document the fai-testing setup for network installations with only one qemu vm, where the host system is runs all the network services and the installö client runs qemu. The biggest problem here was, that nfs over udp transport is extremely slow between qemu and th host, therefore I needed to switch NFS in TCP transport mode. Plus there's some networking chaos to get the host talk to client.
  • development toolchain: try to use and test FAI within 2 qemu VM's, one as server, one as client - if qemu doesn't work, maybe try faumachine or others, see random notes

• multi-distribution integration in FAI - I want FAI to be able to install at least ubuntu, debian, progeny, plus other Linux distributions in an easy and nicely integrated way. For now, with the debian package, you install debian systems, with my ubuntu patches you install ubuntu - other debian based, debootstrappable systems are possible, but until now I didn't come up with a good solution to do them alltogether next to each other from one server. This would ease integration of my patches with debian upstream, too.
  • the overall plan/idea:
    • in /etc/fai/distributions create subdirectories or files like <DISTRIBUTION>.conf - here could be said what would be needed to create a base-<DISTRIBUTION>.tgz for the new distribution, plus other changes needed for that distribution (etc/fai/distributions/ubuntu.conf /etc/fai/distributions/create-ubuntu-base.sh, /etc/fai/distributions/ubuntu-sources.list ...)
    • move the creation of the base.tgz out of make-fai-nfsroot (now it is just packed in the middle of the nfsroot creation phase, which results in an nfsroot and so a base.tgz being a debootstrao chroot from the distribution running on the FAI server)
    • in class we can set some var DISTRIBUTION, depending on which another base.tgz is extracted and maybe some other actions will be taken (maybe other ways to install software for rpm or tgz systems...)
    • create a package installation handler for other distributions/package managers: something we can feed our package_config files in which then just installs those packages...
  • next steps to go:
    • look at florent's newest fai-md package, test it
    • solve NFSroot and base.tgz creation issue (for Ubuntu, crux linux, centos, mandriva, fedora core):
      • try this: http://thomas.apestaart.org/projects/mach/
      • there where more reports on similiar tools on the (devel/user?) mailing list
      • make nfsroot and base.tgz creation testable (restructure scripts, create unit tests)
      • test installs

• test the "configspace in cvs" or subversion feature

• test debconf for install clients functionality

• test to reproduce the "scrolling screen freeze" bug, mail workaround to the list

• BUG/WISHLIST: why does fai-cd need a mirror directory as parameter? it could ask for that interactively and call fai-mirror by itself if no mirror is available. Plus, it makes no sense to require a persistent fai-mirror if I have a full debian mirror on the machine i run fai-cd on - I then only need a temporary mirror anyway!

• BUG/wishlist: fai-setup doen't have a "-c" option to use another config dir. for fai-mirror and fai-cd there are already bugs reported. are tghere other scripts that need "-c"?

• FAISERVER cd Beispiel testen/fertigmachen - how about FAI-CD-CREATOR Klasse?!

• ? softupdates testen und nutzen statt servicemanager skripten für aktivierung von diensten und datenabgleich/-aktualisierung

• FAI optimisation in terms of fault tolerance/ ease of debugging - for now, FAI is not really fault tolerant, and because of multiple reasons hard to set up and even harder to debug in some cases. I'd like to optimize that. (1-2 weeks)
  • better examples (a bit similar to the above), plus some more FAI classes for different use cases, and an easier way to get started with FAI. Even if FAI is complex, it should also "Just Work" :) (1-4 weeks, depending on how good it should be, and how many examples needed) For example it could be made possible, that it's very easy and fast to create a FAI CD that can install a fai server, a desktop machine, and a web server automatically, and provide some short docs on how to change settings on these. Network install is a bit more difficult, as it requires deeper knowledge of the underlying network services (dhcp, nfs, dns, tftp).

other ideas for things to do with FAI:

• Modularisierung, Trennung zwischen Software, mitgelieferten Modulen (alles, was irgendwas auf Basis einer Klassendefintion macht)

• cleanup: verzeichnisaufteilung der dateien und scripte besser ordnen, alles ein bisschen mehr zusammenlegen, FHS-konformität

• GUI Management console - FAI tends to get hard to overview when one has lots of classes and lots of different systems, a price for it's flexibility that

i don't want to pay in the long run.

• versionskontrolle von klassenconfigs integrieren (auch: automatisch alle änderungen, die eine bestimmte klasse betreffen, um eine version zurücknehmen

• python oder ruby rewrite?

• FAI classes need metadata:
  • documentation
  • dependencies and maybe inheritance
  • class types
  • usecase
  • (software)package
  • actions? things do to while installing
  • config-> hd, driver, network,printer, files in /etc

• make it possible to share classes easier:
• /usr/local/share/FAI doesn't start with the class/package_config/disk_config structur, but with CLASSNAME, and then the other structure - like that, single classes can be easily exchanged and update (idea from thomas)

• wie unterscheidet man fest vorgegeben von dynamischer konfiguration? (also: wie sehe ich im admintool, dass eine partitionierung des systems anhand festplattengrösse vorgenommen wird?

• was ist ein system? ein system ist ein kombination von hardware (die zum beispiel anhand macadresse identifizierbar ist), usecases und usern mit denen wiederum zugeordneten rollen (können bei jedem system unterschiedlich sein) oder auch usern zugeordnete/erlaubte usecases?

• fai modul für crux, suse, redhat, progeny, userlinux, mepis, centos, whitebox

• NAGIOS Plugin für FAI-installationsüberwachung?

• installation eines chroot mit FAI? is wohl nicht schwer, aber um zu wissen wie's geht, muss man's ausprobieren!

• Security - was kann man da besser machen und wie?

• wenn wir eine fai-cd machen können mit fai, was ist noch zu tun, um mit FAI live-cd's machen zu können? -> einen kompletten fai-lauf in einem chroot laufen lassen, (hmm, ähnlich wie chroots installieren mit fai bis jetzt) und das dann alles auf 'ne live cd packen, plus alles, was ich noch nicht weiss, was man bei live-cd's beachten muss, aber vielleicht hilft bernhard babloks boot cd toolkit: http://bblcd.berlios.de/ ). noch mehr links zum Thema live-cd selber bauen: http://rescuecd.sourceforge.net/links.html