[doc] setup_howto further elaborated: Stage4, div. enhancements.

1 files changed, 97 insertions, 14 deletions

diff --git a/doc/setup_howto b/doc/setup_howto
index 2a051cac..69b85937 100644
--- a/doc/setup_howto
+++ b/doc/setup_howto
@@ -24,7 +24,7 @@ printerGUI repository: git://git.openslx.org/openslx-ng/printergui.git
 
 3. Server prerequisites
 
-Needed serices: dhcp, tftpd, httpd. ... (TODO: elaborate)
+Needed serices: dhcp, tftpd, httpd, NFS and/or dnbd3.
 
 
 4. Getting the source
@@ -62,7 +62,7 @@ Build Stage31:
 # ./mltk remote stage31 -c -b (-d -> debug when appropriate)
 
 Build Stage32:
-# ./mltk remote stage32 -c -b
+# ./mltk remote stage32 -c -b (-d -> debug when appropriate)
 
 Build Stage32 for openSuse:
 # ./mltk remote stage32-opensuse -c -b
@@ -71,32 +71,72 @@ Build Stage32 for openSuse:
 
 Build addons (vmware etc.)
 # ./mltk remote vmware -c -b
+# ./mltk remote vbox -c -b
+# ./mltk remote debug -c -b (as always: -d -> debug when appropriate)
 
 
 7. 'Packaging'
 
 When using the parameter 'server' either an IP adress or 'local' is expected.
 If the building machine is also used to deliver the built boot images 'local'
-should be used. If another machine is used to deliver built images (by http
-etc.) the IP adress of the build machine shoud be used. In that case mltk
-needs to be present on the server machine. Please take note that the 'remote'
-machine (the machine on which the build process runs) needs to export the
-build structure (option remote -n, see help).
+should be used.
 
-So remember to execute
+If another machine is used to deliver the built images (by http etc.) the IP
+adress of the build machine shoud be used. In that case mltk needs to be
+present on the server machine.
+
+Please take note that the 'remote' machine (the machine on which the build
+process runs) needs to export the build structure (option remote -n, see
+mltk --help). This option executes a bind mount of the local build directory
+to a standardized place, /export/build, which can be accessed later from the
+server machine via rsync. To facilitate this rsync-ing it way be wise to
+add the ssh key to authorized_keys on the build machine, as then no password
+has to be given when syncing from the server machine.
+
+So, remember to execute
 # ./mltk remote -n
-on the build machine.
+on the build machine, if the build is going to by synchronized to a dedicated
+server machine.
 
-For now we presume the same machine is used for building and serving.
 
-So, for 'packaging' the stages and an addon (vmware:
+7.1 Packaging locally (build and server machine are the same)
+
+For 'packaging' the stages and an addon (vmware), presuming the same machine 
+is used for building and serving:
 # ./mltk server local stage31 -e stage31
 # ./mltk server local stage32 -e stage32
 (Use this call for openSuse:)
-# ./mltk server local stage32-opensuse -e stage32 (f. Target opensuse)
+# ./mltk server local stage32-opensuse -e stage32 (for target opensuse)
 
 For packaging addons the parameter 'addons' should be used:
-# ./mltk server local vmware -e addons (... other addons likewise)
+# ./mltk server local vmware -e addons (... other addons likewise.)
+
+
+7.2 Remote packaging (build and server machine not are the same)
+
+First, do a
+# ./mltk server [IP of build machine] -s
+to synchronize all stage/addon builds in one pass. This synchronizes the
+complete build directories from the remote (build) machine to the server.
+
+Then you may package the stages and addons in analogue to tho local case
+mentioned above:  
+
+# ./mltk server [IP of build machine] stage31 -e stage31
+# ./mltk server [IP of build machine] stage32 -e stage32
+
+(Use this call for openSuse instead:)
+# ./mltk server [IP of build machine] stage32-opensuse -e stage32 
+
+For packaging addons the parameter 'addons' should be used:
+# ./mltk server [IP of build machine] vmware -e addons
+... other addons likewise.
+
+Please note that stages/addons can be synchronized independently, if 
+needed:
+# ./mltk server [IP of build machine] stage31 -e stage31 -s
+...
+# ./mltk server [IP of build machine] vmware -e addons -s
 
 
 8. Preparing for client boot
@@ -137,4 +177,47 @@ idea to just touch config.tgz or pack an empty archive of that name. These
 localizations may be listed at [path to tm-scripts]/server/configs.
 
 
-iPXE: TODO
+10. iPXE: TODO
+
+
+
+11. Stage 4 (extract Linux desktop environment)
+
+The script clone_stage4 should not be used on the build computer if build and
+server machine are different. It has to be used on the computer which
+provides httpd and nfsd, or, in other words: On the computer which serves
+the boot files. That is the reason why clone_stage4 rejects 'local' as IP.
+
+To use stage4 a nfs export will be necessary, as the files of stage4 will
+be accessed by nfs client-side later on. Please keep in mind that 
+"./mltk remote -n" has to be executed on the build machine before cloning 
+stage4.
+
+Then make sure all builds are synced to the server machine, if that has not 
+happened before:
+# ./mltk server [IP of build machine] -s
+
+... or, if wanted, sync just some parts, if you know what you're doing. 
+stage32 makes most sense so far, so to say. So, for example:
+# ./mltk server [IP] stage32 -e stage32 -s
+etc.
+
+Well, then do the cloning work:
+# ./scripts/clone_stage4 [IP of build machine] stage32 
+	/path/to/your/nfs/share/stage4	(this is one line!)
+
+To use stage4 the clients need to be given the nfs mount information. This is 
+handled via a configuration variable (please consult doc/boot_config_vars 
+for a full summary) called SLX_STAGE4_NFS.
+
+So please check (or re-check) your base config file in the directory you 
+chose above (see 8. Preparing for client boot) contains a line
+SLX_STAGE4_NFS=[IP of service computer]:/path/to/your/nfs/share/stage4.
+
+You should see stage4 working after rebooting the client if there are some 
+entries besides Openbox above possibly a list of virtual machines. As a side 
+note it should be possible to see the stage4 without complete reboot, if
+# systemctl restart nfs-mount
+is being executed.
+
+