#
# "SystemImager" - Copyright (C) 1999-2001 Brian Elliott Finley <brian@systemimager.org>
#
#   $Id: TODO,v 1.182 2001/10/03 15:44:45 dannf Exp $
#

--------------------
Developer Guidelines
--------------------
o Current development branch is tagged "HEAD".  This is the default.
  Most developers will use this.  To check out the development branch:
   "cvs -z3 -d:ext:developer_name@cvs.systemimager.sourceforge.net:/cvsroot/systemimager co systemimager"
o The stable branch is only to be used for fixing bugs.  To check out
  the stable branch:
   "cvs -z3 -d:ext:developer_name@cvs.systemimager.sourceforge.net:/cvsroot/systemimager co -r stable-1_5_x systemimager"
o Only Brian Finley will modify CVS tags of any kind, such as for versioning 
  releases or creating development branches.
o Always get approval from Brian Finley prior to adding any new files or 
  directories to CVS.
o You may modify sections in the TODO file bearing your name.
o When you finish an item in your section of the TODO file:
  o Add an appropriate line to the CHANGE.LOG file before removing the 
    item from the TODO file (so we don't forget about keen changes 
    we've made).
  o Send an email to the <systemimager-devel> list announcing completion.
o Do not modify anyone elses section.
o Have fun!

----------------------
CVS Reference Material
----------------------
o http://www.loria.fr/~molli/cvs/doc/cvs_toc.html
 or
o http://cvsbook.red-bean.com/cvsbook.html
 or
o http://www.cvshome.org/

------------------------------------------------------------
CVS Checkout Steps for Developers for the Development Branch
------------------------------------------------------------
1) Checkout the code:
   "cvs -z3 -d:ext:developer_name@cvs.systemimager.sourceforge.net:/cvsroot/systemimager co systemimager"
2) Rename the checked out source tree (suggested):
   "mv systemimager systemimager.devel"


------------------------------------------------------------------------
CVS Checkout Steps for Developers for the Stable Branch (bug fixes only)
------------------------------------------------------------------------
1) Checkout the code:
   "cvs -z3 -d:ext:developer_name@cvs.systemimager.sourceforge.net:/cvsroot/systemimager co -r stable-1_5_x systemimager"
2) Rename the checked out source tree (suggested):
   "mv systemimager systemimager.stable"

--------------------------------------------------------------
Brian's Priorities 
  These tasks are in the order that I intend to complete them.
--------------------------------------------------------------
o Install scripts wrap Makefile
o Upgrade reiserfs support
o Verify Don's serial console changes
o Add interactive autoinstall client patch


-------------------------------
Development Branch Sub Projects
-------------------------------

Unclaimed Sub Projects
----------------------
o Documentation: how to migrate from KickStart to SystemImager.
o X Windows GUI
  o Run from the imageserver sending the X display back to a sysadmins
    desktop.
  o Distribution independent.  The two main distros to initially be
    concerned with are debian and redhat.  Minimal dependencies are
    preferred -- this will be run from a server which may not have lots of
    X and GUI stuff installed.
  o The goal is to allow for all of the commands to be run by clicking
    buttons, filling in boxes, etc.
  o See the "GUI Layout" section in this document for details on the 
    proposed logical arrangement of screens, etc.

Curtis Zinzilieta <czinzilieta@valinux.com>
-------------------------------------------
o updateclient:  Add a -no-update "Don't actually *do* the update, just 
  show me what would have been done." option.

Brian Finley <brian@systemimager.org>
-----------------------------------
o updateclient:  Change -nolilo to -no-lilo, and hide nolilo in the background.
o deal with LABEL= *and* UUID= for any filesystem or device type
o Jose_AP_Celestino.ida.prepareclient.patch to make systemimager work
  properly with Smart Array cards.  (must get a Smart Array card first)

o put exclude/include stuff on imageserver by image
    /tftpboot/systemimager/$image.updateclient.include
    /tftpboot/systemimager/$image.updateclient.exclude
o updateclient - local /etc/systemimager/updateclient.local.exclude or include
  take precedence over include and exclude on imageserver.
o updateclient - include/exclude pulled to temporary files.
o prepareclient - no longer puts /etc/systemimager/updateclient.local.exclude on
  client.  Rather, rely primarily on the image.include and image.exclude files.
o have getimage question what should be excluded in future when updateimage 
  is run.  /tmp/* and /home/* should be recommended as a starting place.

o deal with LABEL=UUID as well as LABEL=mount_point
o if local.cfg and dhcp fails, have client ask for manual input
o incorporate multicaster
o getimage -- blink option
o getimage -- eject option
o contemplate using khttpd or tux or similar to show autoinstall client status
o command to put mac addresses/host names into 
  /etc/dhcpd.conf by using broadcast pings, the arp 
  table, and /etc/hosts or dns.
o section of HOWTO that helps Kickstart users transition to SystemImager.
o redirect syslog messages from autoinstall clients to $imagserver
o addclients -- re-cycle through each question if answer is ""
o change option-100 -> option-207
o Notes regarding differences between v2 and v3 of dhcpd:
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  The change from version 2 of ISC's dhcp server to version 3
  regarding the systemimager dhcpd configfile file is:

  With v2
  -------
  option option-100
  
  With v3
  -------
  option SImgsrv code 100 = text;
  option SImgsrv xxx.xxx.xxx.xxx;
  option dhcp-class-identifier --> vendor-class-identifier

  Explanation
  -----------
  The first line is the definition of the name "SImgsrv" using
  option 100. the second line uses the option name "SImgsrv" to
  assign the actual value, which is supposed to be an ip address in
  the case of systemimager 1.4.1 .
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
o Modify initrd to use tmpfs instead of a ramdisk for root (if possible).
o Add a "-dry-run" option to updateclient (and maybe getimage)


<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 Serial Console Redirect
<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

o serial redirect for autoinstallclient
  o See email from michael@auctionwatch.com
  And if necessary, do the following too:
    o See email with Subject of: 
      Subject: serial redirect for autoinstalling systems remotely with systemimager
    o See linux/Documentation/serial-console.txt
    - manual change to syslinux.cfg
    - maybe an append parameter if necessary
    - detect if serial is wanted by having rcS look for variable in
      - $image.master
      - local.cfg

serial console ideas by Dirk Wetter <dirkw@rentec.com>

Ideas on how to add serial console support:
o have a switch in the getimage script (or maybe rcS script) and test
  to see if a serial console has been set by the boot loader.

	SERIAL=`tty | grep -c ttyS`
 
o logging of the "rsync -av" to the install client, and not to the 
  screen/serial line.

	if [ <my control-tty is serial> ]; then
	    RS_OPT="-av"
	else
	    RS_OPT="-a"
	fi
	rsync $RS_OPT $IMAGESERVER::<image>

o write the log to a temporary location, then copy the log to it's 
  final destination.

	rsync -av $IMAGESERVER::<image>  >/tmp/image_rsync.log || shellout
	cp /tmp/image_rsync.log  /a/<the_final_dest_for_log>


o with an additional option for updateclient one could tell by using the 
  append line in lilo whether one wants to have a serial console or not. 
  does makeautoinstall{diskette,cd} would have to be modified, too?

o it would be great then, if the default kernel shipped with SI would  
  have also CONFIG_SERIAL_CONSOLE set, and if the initrd.gz would contain 
  the right /dev/console and /dev/ttyS0.

Comments from Michael S. Fischer <michael@auctionwatch.com>:
o SERIAL=`tty | grep -c ttyS`
 will not tell you whether the console is serial or not.  Serial console
 is /dev/console, just like the keyboard/mouse-based virtual console.  If it
 weren't, lots of things would break.

o suggests that serial console support be chosen when running getimage.

Don Stocks <don_stocks@leaseloan.com> says:
o I am going to be playing with this.  The more input the better.  I agree
  that adding getimage command line switches will give the end user the
  ability to choose whatever configuration may be needed without having to try
  and determine it at runtime.  Maybe a serial switch that has a tty as an
  argument (something like -serial-console ttyS0 ).  A Logging switch to turn
  logging on or off could also be added.

  I think I remember reading something about Brian's team already working on
  different logging options.  If that's true, then I will leave logging alone
  and just concentrate on console redirection.
<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Austin Gonyou <austin@coremetrics.com> 
Wed Mar 21 12:19:10 CST 2001  
----------------------------------------
o commandlineize addclients
  -version
  -help
  -base-hostname HOSTNAME
  -domainname    DOMAINNAME
  -first         HOST_NUMBER
  -last          HOST_NUMBER
  -image         IMAGENAME
  -ip-range      1.2.3.4-1.2.3.99,5.6.7.8-5.6.7.108

  Example:
  $ addclients -b www -d systemimager.org -f 7 -l 11 -image web_image_v1 -ip-range 192.168.1.7-192.168.1.11

o add zero padding option: 
  o take input like normal:
    "-first 001 -last 099"
  o and test to see if leading zeros exist
  o if leading zero exists for starting point, make sure that number of
    digits are the same in 
    o if number of digits

"-add-zeros ZEROS" (where ZEROS is the 
  number of zeros to pad with).  Accept either a number of actual
  zeros as input "000" or the number of zeros as input "3".  Simply
  test to see:
  unless(it is a number), die useage;
  if($add_zeros numerically-equals "0") then use it's literal string value "000"
  else(use $add_zeros to make the right number of zeros)

Dann Frazier <dannf@ldl.fc.hp.com>
------------------------------------
o Modify Makefile for initrd:
  o create tarball of modules and binaries (binaries.tar.gz)
    o run mklibs.sh to create libraries for initrd
      (currently doing this)
    o make sure that gzip and tar are included in the mklibs.sh for the initrd
    o also run mklibs.sh against binaries on initrd and other binaries 
      to create libraries for tarball.
  o place gzip, tar, and binaries.tar.gz with other tftp stuff
  o rcS will *always* pull gzip, tar, and binaries.tar.gz
o PXE booting ideas...
  with pxe, you can specify what files to serve to a specific hardware
  address.
  you could have symbolic links that point to the SystemImager kernel &
  initrd.gz for each node, with no default files.
  you can then remove these links when you decide not to allow that
  machine to PXE boot.
  the machine will try to pxe boot, won't be able to find its kernel and
  initrd.gz, and will boot from the harddrive.
  a tool similar to addclients might be useful for this.
o look at replacing dhcp-client w/ udhcp - possibly a savings of 88k
o for the ramdisk build system, instead of creating a fs of a certain
  size, then filling it (and often times running out of space), create
  the directory structure, create the fs based on the now-known size
  of the directory tree, and copy the directory tree into the fs.
o instead of explicitly stating each thing that should be linked to busybox
  in the Makefile, just run busybox and parse out what it provides.  this
  will require some way of mapping every busybox applet to a directory
  (e.g. /sbin vs. /usr/sbin vs. /bin vs. /usr/bin) - just to be anal.
o generalize ramdisk build system to take a config file.  this way we
  can use it to build a recovery ramdisk, a ramdisk for offline image
  collection, as well as the autoinstall ramdisk (and the secondary ramdisk
  mentioned above.
o serial console support
o dosfs support (sdague was working on this)

Austin Gonyou <austin@coremetrics.com>
Wed Mar 21 12:19:10 CST 2001  
----------------------------------------------------------
o web-gui that allows all image server operations as well as:
  o schedule clients to be updated or re-autoinstalled at a later date
    o produce a master schedule file, available from the webserver,
      that clients pull down via a cron job.  parse the file to determine
      the details of what they're supposed to do (if anything).  Create
      a command line utility for doing scheduling.
      o schedule:
        o -f filename
	o other options...
  o provide for reporting of clients that have completed their autoinstalls.
  o Add "Alias /systemimager/ /var/lib/systemimager/web-gui/" to srm.conf 
    in Apache.
o See the "GUI Layout" section in this document for details on the 
  proposed logical arrangement of screens, etc.
o command line scheduling utility


GUI Layout (applies to Web GUI and X GUI)
-----------------------------------------
Main screen:
o Web GUI as a Webmin module
o Maybe have a SystemImager Wizard that basically walks you through 
  the steps in the "Step-by-Step HOWTO":
  http://systemimager.org/manual/html/theactualstep-by-stephowto.html
o Also have buttons for each of the utilities labelled something like:
  o "Pull and Image from a Golden Client" (getimage)
  o "Add Client Autoinstall Information" (addclients)
  o "DHCP Server Configuration"
    o show me my existing config
    o create a new configuration file (makedhcpserver)
    o make existing DHCP leases static (makedhcpstatic)
  o Autoinstall clients
    o I want to re-install an existing system
      o connect to the existing system with ssh 
        (then autoinstall -a -s)
      o connect to the existing system with rlogin
        (then autoinstall -a -s)
    o I want to install systems with an autoinstall diskette
    o I want to install systems with an autoinstall CDROM


James Morton <jmorton@viata.com>
Committed to task: 03 Jan 2001
--------------------------------
o have the autoinstallclient ask user for settings.



<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 Recovery CDROM -- George Perry <perryg@elcsci.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Brian:

I like the framework you are suggesting.  However, checking the SytemImager
Linux environment it looks like we would also have to add: 
1) tar
2) gzip or bzip
3) device drivers for backup devices (e.g. /dev/st0)

Per the busybox website, tar and gzip are availble within the full current
version of busybox.

Another option would be to just list the LinuxCare bootable business card as
a required package for this option.  The HDD device drivers that I needed to
add could have been sniffed from my original /etc/fstab, and then added as
part of the SystemImager script.

Thank you,
George Perry
Electro Scientific Industries (ESI)

-----Original Message-----
From: Brian Elliott Finley [mailto:brian@systemimager.org]
Sent: Monday, June 04, 2001 11:10 AM
To: George Perry
Cc: SystemImager Devel
Subject: Re: [SystemImager-devel] FW: Thanks and a suggestion for a
recovery CD

George,

o I think we can resolve the CDROM mounting issue by simply changing a
  kernel compile option.
o I don't mind using tar with gzip or bzip2 in this case, assuming that
  it really was a disaster recovery CD and not a system replication CD.

Maybe we could create a perl script called "makerecoverycd".  It would:
o tar -cvf - $imagename | bzip2 > image.tar.bz2
o determine if image.tar.bz2 will fit on a CD and error out if it won't.
o create a recovery script "recovery.sh" that would:
  o partition the disk(s)
  o create the filesystems
  o mount the filesystems
  o cd /a/ && bzcat /cdrom/image.tar.bz2 | tar -xvf 
  o run lilo
  o maybe I need to break out the getimage code into libraries so that
    you can simply call the appropriate functions to do some of the 
    things above...
o recovery.sh and image.tar.bz2 would reside on the CDROM next to the
  kernel and initrd.gz.

This would not be intended as an "emergency repair the system CD", but
as an automated blow it all away and re-install CD.  

I have a patch (sent in by James Morton) to the initial ram disk that 
will give you a prompt with a timeout that will allow you to go 
interactive and punch in all your networking information.  We could 
use this to fill in the variables used by the recovery.sh script to 
assign unique hostname, address info, etc.  And if none of these 
settings needs changing, then recovery.sh doesn't change a thing in 
the untarred image.

-Brian
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 Support for non-standard-linux partitions (fat, NTFS, etc)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
o add support for non-standard partitions as block images.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 ext3 stuff
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
o See email from Marc Merlin: scripts to do ext3 upgrades
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 reiserfs stuff
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
o Han's Reiser has agreed to make modifications to debug-reiserfs that 
  will make it easy for us to pull version information from existing
  filesystems.  This will allow us to re-create the destination 
  filesystems with the same hash and version.

  -Brian
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Dague, Sean <sdague@raleigh.ibm.com>
------------------------------------
o imageexec
o imageput


Ian McLeod <ian@valinux.com> (suggestions)
------------------------------------------
o autoinstall clients report to imageserver "I'm up"
o ability to blink led, floppy light, eject cdrom, etc. on 
  autoinstallclient to identify the machine prior to initiating the 
  autoinstall.
o option to assign permanent IP address/hostname from the server after
  an autoinstall client has booted and checked in.
o ability to adapt to the hardware
  - client chooses section from <imagename>.master based on disk type
    (master script contains sections for hd, sd, and rd)


Miscellaneous and Possibilities
-------------------------------
o support for imaging dual boot systems (Linux/Windows with FAT/HPFS/NTFS)
  o see mondo (available on freshmeat)
o makedhcpserver -- autodiscover and calculate more information 
  (including if system has more than one network interface).
o makedhcpserver -- automatically change line in /etc/rc.d/init.d/dhcpd for you
o makedhcpstatic -- allow for -f "filename" option to specify dhcpd.leases file.
o check for the presence of a BIOS file written by BIOSwriter. If 
  found, then at the tail end of a client's image pull, it runs 
  BIOSwriter to write the file.


Bug list
--------
Please submit bugs via the "SystemImager Bug Tracking System" link at
http://systemimager.org/

Potential Volunteers
--------------------
o Duane Gustavus <duane@unt.edu>
