[caiman-discuss] Initial thoughts about Slim post install service
Jean McCormack
Jean.McCormack at Sun.COM
Mon Jun 16 08:02:58 PDT 2008
Jan,
I just started working on the transfer module and thought all of the
following code might fall
into this category (comments added with JEAN: to make clear what I think
this code is doing):
tmod.logprogress(97, "Extracting archive")
#JEAN: I believe you have this listed as creating
updating boot archives.
self.info_msg("Extracting archive")
os.chdir(self.dst_mntpt)
cmd = defines.bunzip2 + " -c " + defines.archive + " | " + \
defines.cpio + " -idum"
self.dbg_msg("Executing: " + cmd + ", CWD: " +
self.dst_mntpt)
self.check_abort()
err_file = os.tmpfile()
p1 = Popen(cmd, stderr=err_file, shell=True)
rt = p1.wait()
# cpio copying errors are typically non-fatal
if rt != 0 and self.debugflag == 1:
err_file.seek(0)
self.info_msg("WARNING: " + cmd + " had errors")
self.info_msg(" " + err_file.read())
err_file.close()
tmod.logprogress(98, "Performing file operations")
self.check_abort()
#JEAN: This is copying the smf seed repository to the
smf repository.
self.info_msg("Performing file operations")
mp = self.dst_mntpt
shutil.copyfile(mp + "/lib/svc/seed/global.db", \
mp + "/etc/svc/repository.db")
os.chmod(mp + "/etc/svc/repository.db", S_IRUSR | S_IWUSR)
tmod.logprogress(99, "Cleaning up")
#JEAN: creating /etc/mnttab ????
open(mp + "/etc/mnttab", "w").close()
os.chmod(mp + "/etc/mnttab", S_IREAD | S_IRGRP | S_IROTH)
self.check_abort()
#JEAN: removing files that are just cruft
unlnk_list = []
unlnk_list.append("/boot/x86.microroot")
unlnk_list.append("/.livecd")
unlnk_list.append("/.volumeid")
unlnk_list.append("/boot/grub/menu.lst")
unlnk_list.append("/etc/sysconfig/language")
for fname in unlnk_list:
self.check_abort()
try:
os.unlink(mp + "/" + fname)
except:
pass
for fname in unlnk_list:
self.check_abort()
try:
os.unlink(mp + "/" + fname)
except:
pass
self.info_msg("Fetching and updating keyboard layout")
# JEAN: What the message says, fetching and updating the
keyboard layout
os.chdir(self.dst_mntpt)
self.dbg_msg("Opening keyboard device: " +
defines.kbd_device)
kbd = open(defines.kbd_device, "r+")
# KIOCLAYOUT is set in our module's dictionary by the C
# wrapper that calls us.
k = array.array('h', [0])
fcntl.ioctl(kbd, KIOCLAYOUT, k, 1)
kbd_layout = k.tolist()[0]
kbd.close()
self.check_abort()
layout = self.get_kbd_layout_name(kbd_layout)
kbd_file = open(defines.kbd_defaults_file, "a+")
kbd_file.write("LAYOUT=" + layout + "\n")
kbd_file.close()
self.dbg_msg("Updated keyboard defaults file: " +
self.dst_mntpt +
"/" + defines.kbd_defaults_file)
self.info_msg("Detected " + layout + " keyboard layout")
#JEAN: More cleanup.
os.system("rm -rf " + mp + "/var/tmp/*")
os.system("rm -rf " + mp + "/mnt/*")
What do you think?
Jean
jan damborsky wrote:
> Hi all,
>
> during initial phase of Slim install project, post install service
> was a little bit being neglected - only small attention was paid to
> dedicate appropriate time to design phase.
>
> Since this lack of design would need to be addressed, I have tried
> to come with some initial thoughts trying to specify scope of this
> problem and determine issues which would need to be addressed.
>
> The actual implementation is not part of this initial draft and
> will be specified later when final set of design goals and
> requirements is worked out.
>
> The outcome of this discussion will be captured in post install service
> design specification, which will serve as base for new implementation.
>
> Please see below for the draft - any comments and suggestions are
> highly appreciated.
>
> This work is tracked by following CR:
>
> 1040 post-installation phase should be redesigned
> http://defect.opensolaris.org/bz/show_bug.cgi?id=1040
>
> Thank you,
> Jan
>
>
> Overview
> --------
>
> Post installation service is invoked as last part of installation
> process after all required bits are transfered to the install
> target during transfer phase.
>
> It consists of particular post install tasks, which are being
> invoked in order to finalize the target, so that it is usable
> and can be successfully booted.
>
> The excerpt from list of post install service tasks Slim
> carries out for now:
>
> * setting default locale
> * modifying target /etc/vfstab
> * setting up user default environment
> * activating of target boot environment
> * installing GRUB boot loader
> * configuring GRUB menu.lst file
> * creating/updating boot archives
>
> Current state
> -------------
> Currently, implementation of post install service in Slim installer
> suffers from some design flaws which would need to be addressed.
>
> Post installation tasks are carried out in different places, error
> handling and reporting is insufficient and approach for posting
> logging and debugging messages is inconsistent.
>
>
> Problems to be addressed
> ------------------------
>
> [i] Post installation service is spread across several places
>
> Currently post installation tasks are spread across several
> places:
>
> * transfer module
> * orchestrator
> * install-finish script
>
> They would need to be consolidated and moved to the one common
> place.
>
> [ii] Insufficient error handling/reporting
>
> There is only limited mechanism implemented for handling
> potential failures and their reporting to the consumer.
>
> Failures are being obscured or ignored.
>
> [iii] Poor and inconsistent logging
>
> Particular post installation tasks use different approaches
> how to log and provide information about progress and actions
> done.
>
> There is almost no support for debugging and testing as far as
> generated messages are concerned.
>
> Since Slim installer currently provides common logging service
> for these kind of tasks, it should be utilized by post install
> service.
>
> [iv] Progress report ?
>
> Since some post install tasks take relatively long amount of
> time, it might be useful, if user can be provided with
> information about progress.
>
>
> Requirements
> ------------
>
> post installation service
>
> * will be implemented in one place
> * will take advantage of existing logging service for logging
> and debugging purposes
> * will sufficiently report/log progress of particular tasks
> * will take suitable approach for error handling and reporting
> * will avoid hard coding things where possible
> * will allow some level of customization
> - additional tasks could be added
>
> Interfaces
> ----------
>
> * interface for adding additional post install tasks will be
> provided
>
> * interface for providing consumer with information about
> progress
>
>
> Dependencies
> ------------
> * logging service
>
>
> Scope
> -----
>
> It is currently assumed that this document will focus on the
> post install service to be consumed by Slim installer.
>
> However, it might turn out that other consumers might be able
> to take advantage of this design as well.
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
More information about the caiman-discuss
mailing list