sya-710 lab 8 creating a live cd

livecd-tools is already installed on my f9 computer

I chose to use the minimal kickstart file to save time as it is
ok to update the system later.
I changed the line selinux --enforcing to --permissive in the ks file.

~]# livecd-creator -c /usr/share/livecd-tools/livecd-fedora-minimal.ks --fslabel=live-
fedora.min

Should end up with a file called live-fedora-min.iso
I'll return to this after the iso is created.

running wubi.py

still some issues - to start with i should have made a bigger windows partition when i installed xp

i slimmed down the isolist.ini file to one entry but i really need it to find the local .iso for figuring out how things are working - slowly getting further along though

below is the basic tasklist of what the installation consists of:
note that the tasks on the left match the message in the installation window
- helps just to get a basic idea of where things are

     def get_installation_tasklist(self):
        tasks = [
            ("Selecting target directory", self.select_target_dir),
            ("Creating the installation directories", self.create_dir_structure),
            ("Creating the uninstaller", self.create_uninstaller),
            ("Copying files", self.copy_installation_files),
            ("Retrieving the Metalin", self.get_metalink),
            ("Retrieving the ISO", self.get_iso),
            ("Extracting the kernel", self.extract_kernel),
            ("Uncompressing files", self.uncompress_files),
            ("Choosing disk sizes", self.choose_disk_sizes),
            ("Creating a preseed file", self.create_preseed),
            ("Adding a new bootlader entry", self.modify_bootloader),
            ("Creating the virtual disks", self.create_virtual_disks),
            ("Uncompressing files", self.uncompress_files),
            ("Ejecting the CD", self.eject_cd),
            ("Rebooting", self.reboot),
        ]

So backing up - in the basic info used before the windows frontend (the actual install window) the last function in the list below might be the one that finds the local .iso file

def fetch_basic_info(self):
'''
Basic information required by the application dispatcher select_task()
'''
self.info.original_exe = self.get_original_exe()
self.info.platform = self.get_platform()
self.info.osname = self.get_osname
self.info.language, self.info.encoding = self.get_language_encoding()
self.info.environment_variables = os.environ
self.info.arch = self.get_arch()
self.info.languages = self.get_languages()
self.info.distros = self.get_distros()
self.fetch_basic_os_specific_info()
self.info.uninstaller_path = self.get_uninstaller_path()
self.info.previous_targetdir = self.get_previous_targetdir()
self.info.previous_backupdir = self.get_previous_backupdir()
self.info.keyboard_layout = self.get_keyboard_layout()
self.info.total_memory_mb = self.get_total_memory_mb()
self.info.locale = self.get_locale(self.info.language)
self.info.cd_path, self.info.cd_distro = self.find_any_cd()
self.info.iso_path, self.info.iso_distro = None, None #self.find_any_iso()

understanding python's ConfigParser - sort-of

call these notes to myself: ConfigParser is a python core module that is used to parse a configuration file

ok that was a path issue - my test.py file was higher in the directory structure than wubi.py so it was able to find the data directory (i actually did two things - should have done them one at a time 1. modified pythonpath env variable to exhaustively include every directory being used 2. copied the data directory to the same location as the wubi.py file - i'll step back and see which one worked)

running wubi python code - the code uses a configuration file to both find out what to install and where to get it

the configuration file looks something like this - but with several sections (this shows only one section:
############ config.ini #####################
[mysection1]
arch=i386
name=fedora
packages=fedora-desktop
metalink=http://somewebsite.com/metalink
metalink2=http://someotherwebsite.com/metalink
ordering=1
##############################################

#!/usr/bin/env python
# the file to parse here is the actual .ini file shipped with wubi
import ConfigParser

myfiletoparse = 'c:\python25\scripts\intrepid.python\data\isolist.ini'
print('Parsing myfiletoparse=%s' % myfiletoparse)
configtree = ConfigParser.ConfigParser()
configtree.read(myfiletoparse) #reads file looking for [sections] etc

for distro in configtree.sections(): 
    print('the section=%s' % distro)

##################### no problem parsing the file ###############33
the section=Xubuntu-amd64
the section=Kubuntu-amd64
the section=Ubuntu-amd64
the section=Ubuntu-i386
the section=Kubuntu-i386

current problem is that the file fails to open in the wubi code - exactly the same file, same path and everything. I added a print statement in the ConfigParser.read() function

#### part of Config.Parser.read() ################
read_ok = []
for filename in filenames:
try:
fp = open(filename)
except IOError:
print('cannot seem to open the file=%s' % filename)
continue
self._read(fp, filename)
fp.close()
read_ok.append(filename)
return read_ok
#######################################################################
here is the debugger output - not sure what is going on here unless it is apath issue
so i'll try the same fle in a different location or something

looking at the linux boot process

This is just a temporary record that I will pull together with some other stuff for figuring out wubi

Working primarily on Windows:
Extract files from the iso C:\7z.exe x F10-live-cd.iso

Then use Fedora to open up the ram disk:
lu@localhost$ gunzip < initrd0.img | cpio -i --make-directories
I copied it back to the windows computer to read the init boot script(s) and maybe edit them - then the whole lot (the stuff extracted from initrd.img) can be repacked
on Fedora using something like
lu@localhost$ find ./ -H newc -o > initrd.cpio
lu@localhost$ gzip initrd.cpio
lu@localhost$ mv initrd.cpio.gz initrd0.img

Note: this is a bit unweildy; maybe there is an easier way - but I cannot find anything that runs in Windows to take extract the files from a .img file but seeing it is really a gzipped cpio archive that might be possible (to do: rename the .img file to .cpio.gz and see if common windows extractors will understand it)

GNUwin32 does have gzip.exe, gunzip.exe and cpio.exe and they have no problem extracting the directory structure from initrd.img (so long as i name in .cpio.gz so that makes things a bit less unweildy - haven't tried torepack them yet but that is a detail for later - back to stepping through the wubi python stuff.

(That image - probably should say picture here - might be too small to read but...) the directory that is open in the image is the extracted initrd.img file and in the subdirectory sbin where the real-init boot script lives (after making any changes the whole iso will need to be zipped up again)

SPR720 reviewing

Reviewing a Fedora package.

NAD710 lab 5

A bit about SAMBA and xinetd ...

Once again Professor Chan took us through a 'hands-on' installation and configuration of an industry standard software product within the very brief two hour lab period for our networking course. He does this every time and while responding to both related and unrelated questions and coaching individual students in anything network related. His ability to deal with distractions while maintaining the direction of his students' focus toward the desired goals is remarkable - almost as remarkable as his mastery of the subject he teaches.

As sys admins samba is something we need to be aware of. At one time it would have been mandatory to have a working kowledge of this hybrid network product (hybrid in the sense that it is a link between Linux and Windows). Even though modern windows systems have moved away from the model where this product works so well, it remains a viable simple solution for organizing older networks that remain in place in some sectors due to lack of funding for newer equipment. I am not going to say anything on the details of samba just a link to the samba site.samba

xinetd is an interesting daemon. It is an interesting approach to managing server process in an uniform way. Choosing to introduce this 'server of servers' in the samba lab really drives home the point of what it is for. The real beauty of this lab lies in the fact that I came away having completed installations and configurations such that if I never look back at them, I still have a solid general and practical understanding/experience to draw on in amy real work situation.

In short, I have had a chance to reflect on the learning experience in my program and find the Lecture/Lab combination a really powerful combination in that we are given enough knowledge and practical experience to easily embrace a subject and take it as far as our own needs dictate. It leaves me with a sense of accomplishment.

SYA710 automated installation and breaking barriers

I'll fill this in later but a few headings now

1. isomaster
2. kickstart
3. trying to figure out boot loaders

isomaster - I thought of an .ISO file as a finished product something that could be copied but not altered. That is my misunderstanding. This lab had the intention of having us automate a linux installation. One side-effect was an introduction to isomaster and using it to modify our iso file to automate the installation. This tool is very powerful.

kickstart - this is the Fedora way to set up an automated installation. As I learn about Wubi (Ubuntu installer for windows), and its 'preseeding' approach to automating a linux installation, I see the kickstart approach as parallel thinking in different open software communities.

The lab had us download an iso file for fedora installation and modify the generic kickstart file that is created specific to each installation to copy it to the iso: thus creating a new iso that repeats our basic install with need for human intervention. This is one of those barrier breaking moments: a very enabling lab.

boot loaders - sitll a mystery to me!!