JetResources - User contributions [en]

Faq

2014-01-03T11:42:41Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
1+0 records in
1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

3. Copy slice one into a separate file:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
546560+0 records in
546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are
* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp
dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 and Solaris 11 ? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10 (and indeed Solaris 11), in the same fashion as with previous versions of Solaris.

You can't currently use JET to install Solaris 11 systems, as Oracle have changed the installation technology to 'Auto Install' which is different from JumpStart. You can still use a Solaris 11 system to deliver both Jet/JumpStart installs to Solaris 10 (or lower) clients, and AI installs to Solaris 11 at the same time though.

==== Install v.s. Upgrades ====

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

==== Using OpenSolaris as a JET server ====

If you have installed OpenSolaris, you may need to add the following packages to enable all services required.

For rpc.bootparamd and in.tftpd, needed to jumpstart a SPARC box,
SUNWbs (formerly the packages were SUNWbsu and SUNWbsr)

Timeservices
SUNWcns

==== Using Solaris 11 as a JET server ====

Solaris 11 is "different" with Auto Install replacing JumpStart. This means it does not include many packages required for JumpStart by default

To enable S11 to act as a JET server, add the following.

pkg install system/boot/network

Name: system/boot/network
Summary: Boot server daemons
Description: Support for legacy network boot services including the Reverse
Address Resolution Protocol (RARP) (RFC 903) and the boot
parameters RPC service.

pkg install network/dhcp/dhcpmgr - incase you want to use the GUI
pkg install service/network/dhcp - for pntadm etc

S11 tftpboot does not recognise /tftpboot.

Just ln -s /tftpboot /etc/netboot

Then carry on as normal, except using zfs share and not /etc/dfs/dfstab

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

* Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
* Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
** zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== How does flash work with JET ? ====

The JetFLASH module can be added in like any other

make_template -f -T <template> <template> flash

Simply edit the template, get to the new flash section and edit the flash_archive=
with the path to your NFS shared flar file

line, taking note of the example higher up

ie
flash_archive_locations="nfs://10.1.1.11/archives/sample"

Rerun make_client and JumpStart

===== What is the recommended flash creation line =====
A recommended line to produce a flash archive

flarcreate -n "<Something meaningfull>" -R / -S -c file

ie:

flarcreate -n "Sol10 U2+Rec Patches" -R / -S -c /var/tmp/s10.flar

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Is it possible to include the DB and application into the install? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== Unable to locate suitable disks ====

If you install Solaris onto scrubbed disks which have no Solaris label on them, the install will halt because it can't find disks to install too. This is normally more of an issue with x86 systems that don't have a Solaris partition, but can also be encountered on Sparc boxes too.

On Sparc systems, use the 'format' command to 'label' the disks; on x86, fdisk can be used to create a Solaris partition.

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Faq

2014-01-03T11:41:27Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
1+0 records in
1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

3. Copy slice one into a separate file:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
546560+0 records in
546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are
* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp
dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 and Solaris 11 ? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 and indeed 11, in the same fashion as previous versions of Solaris.

You can't currently use JET to install Solaris 11 systems, as Oracle have changed the installation technology to 'Auto Install' which is different from JumpStart. You can still use a Solaris 11 system to deliver both Jet/JumpStart installs to Solaris 10 (or lower) clients, and AI installs to Solaris 11 at the same time though.

==== Install v.s. Upgrades ====

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

==== Using OpenSolaris as a JET server ====

If you have installed OpenSolaris, you may need to add the following packages to enable all services required.

For rpc.bootparamd and in.tftpd, needed to jumpstart a SPARC box,
SUNWbs (formerly the packages were SUNWbsu and SUNWbsr)

Timeservices
SUNWcns

==== Using Solaris 11 as a JET server ====

Solaris 11 is "different" with Auto Install replacing JumpStart. This means it does not include many packages required for JumpStart by default

To enable S11 to act as a JET server, add the following.

pkg install system/boot/network

Name: system/boot/network
Summary: Boot server daemons
Description: Support for legacy network boot services including the Reverse
Address Resolution Protocol (RARP) (RFC 903) and the boot
parameters RPC service.

pkg install network/dhcp/dhcpmgr - incase you want to use the GUI
pkg install service/network/dhcp - for pntadm etc

S11 tftpboot does not recognise /tftpboot.

Just ln -s /tftpboot /etc/netboot

Then carry on as normal, except using zfs share and not /etc/dfs/dfstab

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

* Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
* Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
** zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== How does flash work with JET ? ====

The JetFLASH module can be added in like any other

make_template -f -T <template> <template> flash

Simply edit the template, get to the new flash section and edit the flash_archive=
with the path to your NFS shared flar file

line, taking note of the example higher up

ie
flash_archive_locations="nfs://10.1.1.11/archives/sample"

Rerun make_client and JumpStart

===== What is the recommended flash creation line =====
A recommended line to produce a flash archive

flarcreate -n "<Something meaningfull>" -R / -S -c file

ie:

flarcreate -n "Sol10 U2+Rec Patches" -R / -S -c /var/tmp/s10.flar

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Is it possible to include the DB and application into the install? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== Unable to locate suitable disks ====

If you install Solaris onto scrubbed disks which have no Solaris label on them, the install will halt because it can't find disks to install too. This is normally more of an issue with x86 systems that don't have a Solaris partition, but can also be encountered on Sparc boxes too.

On Sparc systems, use the 'format' command to 'label' the disks; on x86, fdisk can be used to create a Solaris partition.

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Faq

2014-01-03T11:37:27Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
1+0 records in
1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

3. Copy slice one into a separate file:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
546560+0 records in
546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are
* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp
dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 ? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 (<strike>and indeed 11 if that is what it gets called</strike>) in the same fashion as previous versions of Solaris.

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

==== Using OpenSolaris as a JET server ====

If you have installed OpenSolaris, you may need to add the following packages to enable all services required.

For rpc.bootparamd and in.tftpd, needed to jumpstart a SPARC box,
SUNWbs (formerly the packages were SUNWbsu and SUNWbsr)

Timeservices
SUNWcns

==== Using Solaris 11 as a JET server ====

Solaris 11 is "different" with Auto Install replacing JumpStart. This means it does not include many packages required for JumpStart by default

To enable S11 to act as a JET server, add the following.

pkg install system/boot/network

Name: system/boot/network
Summary: Boot server daemons
Description: Support for legacy network boot services including the Reverse
Address Resolution Protocol (RARP) (RFC 903) and the boot
parameters RPC service.

pkg install network/dhcp/dhcpmgr - incase you want to use the GUI
pkg install service/network/dhcp - for pntadm etc

S11 tftpboot does not recognise /tftpboot.

Just ln -s /tftpboot /etc/netboot

Then carry on as normal, except using zfs share and not /etc/dfs/dfstab

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

* Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
* Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
** zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== How does flash work with JET ? ====

The JetFLASH module can be added in like any other

make_template -f -T <template> <template> flash

Simply edit the template, get to the new flash section and edit the flash_archive=
with the path to your NFS shared flar file

line, taking note of the example higher up

ie
flash_archive_locations="nfs://10.1.1.11/archives/sample"

Rerun make_client and JumpStart

===== What is the recommended flash creation line =====
A recommended line to produce a flash archive

flarcreate -n "<Something meaningfull>" -R / -S -c file

ie:

flarcreate -n "Sol10 U2+Rec Patches" -R / -S -c /var/tmp/s10.flar

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Is it possible to include the DB and application into the install? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== Unable to locate suitable disks ====

If you install Solaris onto scrubbed disks which have no Solaris label on them, the install will halt because it can't find disks to install too. This is normally more of an issue with x86 systems that don't have a Solaris partition, but can also be encountered on Sparc boxes too.

On Sparc systems, use the 'format' command to 'label' the disks; on x86, fdisk can be used to create a Solaris partition.

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Main Page

2012-06-08T21:11:18Z

Marty:

__NOEDITSECTION__ __NOTOC__
== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK.

The toolkit was incorporated into the N1 SPS suite and might still be found within that (if you have access to it).

Now Sun has been bought by Oracle, the download location has moved to: [http://www.oracle.com/technetwork/systems/jet-toolkit/index.html OTN]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

MediaWiki:Sidebar

2010-01-14T16:45:18Z

Marty:

Main Page

2010-01-14T16:44:27Z

Marty:

__NOEDITSECTION__ __NOTOC__
== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

Sun have also started to use a wiki for documenting the features of JET - [http://wikis.sun.com/display/JET Sun JET Wiki]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

Main Page

2010-01-14T16:43:38Z

Marty:

__NOEDITSECTION__ __NOTOC__

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

Sun have also started to use a wiki for documenting the features of JET - [http://wikis.sun.com/display/JET Sun JET Wiki]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

Main Page

2009-05-04T08:23:36Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://blog.maui.co.uk/index.php/jet/?tempskin=_rss2|title=none|max=5</rss>

News is also available through an [http://blog.maui.co.uk/index.php/mtb/?tempskin=_rss2 RSS] feed.

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

Sun have also started to use a wiki for documenting the features of JET - [http://wikis.sun.com/display/JET Sun JET Wiki]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

Resources

2009-05-04T08:21:55Z

Marty:

== JET Web Resources ==

* [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit JET Download]
* [http://wikis.sun.com/display/JET Sun's JET Wiki] (documents etc)
* [http://www.sun.com/bigadmin/content/jet/ JET @ BigAdmin]
* [mailto:jet@sun.com Sun's JET Alias] - for reporting bugs or asking Sun for help etc
* [http://groups.yahoo.com/group/JETJumpStart/ JET Yahoo Group] & [mailto:JumpStart@yahoogroups.com JET Yahoo Group mail alias]

== Modules ==

* [[CustomUpdate]] : Automatically keeps your custom packages up to date from your packages directory
* [[Copy]] : Module that specialises in copying files or directories as part of the install process
* [[N1SM]] : Sun N1 System Manager installation module

Faq

2008-05-23T13:35:26Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
1+0 records in
1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

3. Copy slice one into a separate file:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
546560+0 records in
546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are
* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp
dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 ? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 (and indeed 11 if that is what it gets called) in the same fashion as previous versions of Solaris.

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

* Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
* Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
** zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== How does flash work with JET ? ====

The JetFLASH module can be added in like any other

make_template -f -T <template> <template> flash

Simply edit the template, get to the new flash section and edit the flash_archive=
with the path to your NFS shared flar file

line, taking note of the example higher up

ie
flash_archive_locations="nfs://10.1.1.11/archives/sample"

Rerun make_client and JumpStart

===== What is the recommended flash creation line =====
A recommended line to produce a flash archive

flarcreate -n "<Something meaningfull>" -R / -S -c file

ie:

flarcreate -n "Sol10 U2+Rec Patches" -R / -S -c /var/tmp/s10.flar

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Is it possible to include the DB and application into the install? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== Unable to locate suitable disks ====

If you install Solaris onto scrubbed disks which have no Solaris label on them, the install will halt because it can't find disks to install too. This is normally more of an issue with x86 systems that don't have a Solaris partition, but can also be encountered on Sparc boxes too.

On Sparc systems, use the 'format' command to 'label' the disks; on x86, fdisk can be used to create a Solaris partition.

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Main Page

2008-03-19T21:27:06Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://blog.maui.co.uk/index.php/jet/?tempskin=_rss2|title=none|max=5</rss>

News is also available through an [http://blog.maui.co.uk/index.php/mtb/?tempskin=_rss2 RSS] feed.

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

MediaWiki:Sidebar

2008-03-19T15:57:04Z

Marty:

MediaWiki:Sidebar

2008-03-18T14:36:15Z

Marty:

Main Page

2008-03-18T14:35:20Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://blog.maui.co.uk/index.php/jet/?tempskin=_rss2|title=none|max=5</rss>

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

CustomSolarisPackages

2008-03-09T13:23:36Z

Marty:

==Introduction==

This document contains the procedures to follow when creating custom ACME packages for use within Solaris 9 and Solaris 8 builds that can then form part of your JET Builds. Packages within Solaris 10 have changed a bit and are ‘zone aware’ …… this is not covered in this document.

===Solaris Packages and JET===
The Solaris build methodology in use within ACME is JET. JET (Jumpstart Enterprise Toolkit) can use either

* Custom scripts OR
* Custom packages

As of Solaris 9 the decision was made to move away from custom scripts and over to custom packages.

Packages have more advantages of scripts in that they are self checking and under version control. The remainder of this document walks the reader through an example of how to make such custom packages.

Package source directory on JET (jet-master)
The package source at the time of writing this document was

/export/source/pkgs

===Building Solaris Packages===

====Give your Package a Name====

A package needs a unique name and traditionally the first 4 characters help to identify the vendor. For this example we will use.

* ACMEaardvark

====Create the source directory structure====

# mkdir –p /export/source/pkgs/ACMEaardvark/1.0/
# cd /export/source/pkgs/ACMEaardvark/1.0/

====Create a pkginfo file====

# vi pkginfo

PKG="ACMEaardvark"
NAME="ACME aardvark package”
ARCH="sparc"
VERSION="1.0"
CATEGORY="application"
VENDOR="ACME"
EMAIL="firstname.lastname@ACME.co.uk"
PSTAMP"15th August 2006"
BASEDIR="/etc"
CLASSES="none"

====Create a preinstall script====

# vi preinstall

#!/bin/ksh
#do nothing

====Create a postinstall script====

# vi postinstall

#!/bin/ksh
#do nothing

====Supply your files to be packaged====

For example

# touch aardvark.txt
# echo “this is the ACMEaardvark package” >> aardvark.txt

====Create a prototype file====

# cd /export/source/pkgs/ACMEaardvark/1.0/
# find . -print | pkgproto >> prototype

Edit this file and modify it so it looks similar to the one shown below

i pkginfo=./pkginfo
i preinstall=./preinstall
i postinstall=./postinstall
f none aardvark.txt 0644 root other

====Make your package====

# cd /export/source/pkgs/ACMEaardvark/1.0/
# pkgmk -r `pwd`

====Copy package to the JET install area====

# mkdir -p /export/install/pkgs/ACMEaardvark/1.0/
# mv /var/spool/pkg/ACMEaardvark /export/install/pkgs/ACMEaardvark/1.0/

====Test the package install====

As root on a test server(jet-client) do the following

root@jet-client# cd /net/jet-server/export/install/pkgs/ACMEaardvark/1.0/
root@jet-client# /net/jet-server/export/install/pkgs/ACMEaardvark/1.0> pkgadd -d .

The following packages are available:
1 ACMEaardvark ACME aardvark package
(sparc) 1.0

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

Processing package instance <ACMEaardvark> from </net/jet-server/export/install/pkgs/ACMEaardvark/1.0>

ACME aardvark package
(sparc) 1.0
ACME

Using </etc> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

This package contains scripts which will be executed with super-user
permission during the process of installing this package.

Do you want to continue with the installation of <ACMEaardvark> [y,n,?] y

Installing ACME aardvark package as <ACMEaardvark>

## Executing preinstall script.
## Installing part 1 of 1.
/etc/aardvark.txt
[ verifying class <none> ]
## Executing postinstall script.

Installation of <ACMEaardvark> was successful.

The following packages are available:
1 ACMEaardvark ACME aardvark package
(sparc) 1.0

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: q

====Copy this new package to the JET install area (making it available for JET installs)====
Should you wish to make your new package available during a JET build perform the following on the JET master (jet-server):

root@jet-client# copy_custom_packages /export/install/pkgs/ACMEaardvark/1.0/ sparc ACMEaardvark ACMEaardvark
Transferring <ACMEaardvark> package instance
Transferring <ACMEaardvark> package instance
Packages copied

The ACMEaardvark package is now available for installs via post-install and during a JET build.

To add ACMEaardvark to a JET template do similar to that shown below:

Change the following line in your template

From

custom_packages_1="l”

To

custom_packages_1="ACMEaardvark”

You will then have to re run `make_client –f <jet-client>` as per the standard JET install instructions.

CustomSolarisPackages

2008-03-09T13:22:44Z

Marty:

Documents

2008-03-09T13:16:41Z

Marty:

__NOTOC__
== Marketing! ==

* [[JetFeatures]] - Basic ''feature'' list

== Introduction Documents ==
* [[JumpStartPrimer]] - Introduction to JumpStart
* [[JETPrimer]] - Introduction to JET

* [[JetWalkthrough]] - Document describing how to set up JET, courtesy of Paul Juster
* [[Jet_Installation_Recipe]] - From installing JET to booting hosts - Mark Ashley

== Intermediate Documents ==
* [[MirroredSystemDisks]] - Using JET to mirror boot disks using SVM

== Advanced/Developer Documents ==
* [[CustomSolarisPackages]] - Building custom Solaris packages (which you can then use with JET) - Stuart Saxon

Faq

2007-10-03T08:15:52Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

1. Get a copy of the VTOC from the ISO image:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1
1+0 records in
1+0 records out

2. Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

3. Copy slice one into a separate file:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560
546560+0 records in
546560+0 records out

4. Mount both slice 0 and slice 1 as follows:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso /dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso /dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are
* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp
dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== Documents reference Solaris 8 and 9, not 10. Does this work with Solaris 10 ? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 (and indeed 11 if that is what it gets called) in the same fashion as previous versions of Solaris.

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

* Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
* Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
** zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Is it possible to include the DB and application into the install? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template

############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

jumpstart.log output

CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD

The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 JumpStart servers

You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS

Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it by running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0 /mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2 /mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

FAQ

2007-09-03T14:01:24Z

Marty:

#REDIRECT [[Faq]]

Main Page

2007-09-03T14:00:22Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://jet.maui.co.uk/blog/?feed=rss2&category_name=News|title=none|max=5</rss>

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [[Faq|JET FAQ]]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

MediaWiki:Sidebar

2007-09-03T13:59:24Z

Marty:

MediaWiki:Sidebar

2007-09-03T13:58:38Z

Marty:

MediaWiki:Sidebar

2007-09-03T13:58:04Z

Marty:

Faq

2007-09-03T13:47:42Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs ====

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.
Code:

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

(1) Get a copy of the VTOC from the ISO image:
Code:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1

1+0 records in
1+0 records out

(2) Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.
Code:

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:
Code:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

(3) Copy slice one into a separate file:
Code:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560

546560+0 records in
546560+0 records out

(4) Mount both slice 0 and slice 1 as follows:
Code:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso
/dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso
/dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:
Code:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET ====

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are

* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server ====

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== I noticed alot of docs for jumpstart setup for solaris8,9 I dont see one for solaris10. Why isnt there one for 10? i am interesting in setting up jumpstart for upgrades and clean install. is is safe to do jumpstart straioght from sol7 to sol10? ====

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 (and indeed 11) in the same fashion as previous versions of Solaris.

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

=== Configuration ===

==== JET and Boot Servers ====

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions ====

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install ====

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks ====

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration ====

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ? ====

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

*

Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
*

Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
o

zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module. ====

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Hi, I have read that jumpstart automates the installation of the OS. Is it possible to include the DB and application? ====

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching? ====

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options ====

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors ====

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template
############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly ====

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

---8< make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

---8<

---8< jumpstart.log output
CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg
:q
# uname -a
SunOS b1-zone1 5.10 Generic_118855-33 i86pc i386 i86pc

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa) ====

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD
The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 jumpstart servers
You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS
Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it byt running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0
/mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2
/mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts ====

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt ====

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart ====

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

o 1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

o 2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting
is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

o 3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs ====

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start ====

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting ====

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems ====

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== I am warned about missing patches, but cannot add ====

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ? ====

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug ====

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs) ====

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Faq

2007-09-03T13:42:55Z

Marty:

== Frequently Asked Questions ==

=== Installation ===

==== What are these '.pkg'/'pkg.bz2' files ? ====

"I've just downloaded the packages from the website, and now have files with a .pkg suffix. What do I do next ?"

The files you have are datastream packages. To install them, run

pkgadd -d filename.pkg

rather than the more usual pkgadd -d . [pkgname]

You can migrate the datastream format packages to regular directory based packages by using the pkgtrans(1m) command.

pkgtrans filename.pkg . all

Basically, read up on pkgadd(1m) and pkgtrans(1m) !

==== A GUI Frontend for JET ====

Is there a Web Front End for JET ?

Probably the most frequently requested feature. The short answer is 'no, there is no generic web front end for JET'.

The long answer is that typically, web front ends are written to expose a subset of the features available in JET. For the case of 'standard builds', you may wish to have a pull down list of available builds and just plug in the MAC and IP addresses etc.

As these front ends, with only a subset of features presented, are very much customised for a particular use/customer, it's work you need to do!

If a 'generic web front end' was provided, it would need to be kept up to date with every modification to the toolkit. Quite frankly, it isn't going to be that useful to many people.

JET has been designed so it is pretty easy to front end yourself.

==== Getting Help with JET ====

There are a number of places you can go for help with JET; first up is obviously Sun themselves - Email the people who look after JET on the alias jet@sun.com and someone should get back to you pretty quickly (UK Timezone).

Sun have also put up information on the JET BigAdmin page at http://www.sun.com/bigadmin/content/jet/ and Mike Ramchand (one of the authors) tends to write things about JET in his blog at http://blogs.sun.com/roller/page/mramcha/20050826

External to Sun are a number of resources; there is a Yahoo group at http://groups.yahoo.com/group/JETJumpStart/ and of course, you can approach me (marty at Maui-Systems dot co dot uk) as the other author of the toolkit from when I used to work for Sun.

==== Whats in the Free Bundle ? ====

The JET bundle downloadable from http;//www.sun.com/downloads currently (as of May 2006) contains the following modules.

* SUNWjet - The core JET product
* SUNWjetd - The documentation - Please read
* JetSDS - Configure SVM/SDS
* JetVTS - Install the Test Suite
* JetEXPLO - Install and configure Explorer
* JetFLASH - Utilise flash archives for installation
* JetSAN - Configure SANs
* JetJASS - JASS toolkit install and configuration
* JetZONES - Add local zones to your Solaris 10 global zones as part of the build
* JetWanBoot - Plugin to allow JET to perform WANBOOTt installations
* JetRBAC - Enables none root users to run JET using RBAC

Sun releases/refreshes the bundle on an ad-hoc basis and normally communicates this fact to the comp.unix.solaris and alt.solaris.x86 newsgroups.

==== Solaris 10 U1 (01/06) grub/newboot ====

With the release of Solaris 10 Update 1 (01/06), the x86/64 platform boot method was transitioned to 'grub', finally doing away with the old DCA pre-boot environment. This new boot method was refered to as "newboot" internally to Sun and the phrase seems to have stuck.

To deal with this a JetNEWBOOT module was developed to "plugin" to JET versions prior to JET 4.2 to support this new boot environment. When JET 4.2 is released, the 'grub' installation method will be part of the core JET product.

When using JetNEWBOOT, all you need to amend in your template is the

* base_config_allocation_method="newboot"

As a guide to what to use:

* With Solaris 10 GA (03/05)
o base_config_allocation_method="dhcp"

* With Solaris 10 Update 1 (01/06) and above, JET (< 4.2) and JetNEWBOOT
o base_config_allocation_method="newboot"

* With Solaris 10 Update 1 (01/06) and above, JET (>= 4.2)
o base_config_allocation_method="grub"

JetNEWBOOT is now part of the downloadable bundle from Sun but will not be required once JET 4.2 is released.

==== Using 'iso' images instead of CD/DVDs

The following was derived from information at http://www.unix.com/showthread.php?t=18074

When using Solaris ISO images, the start of the image contains a hsfs (high sierra filesystem) with a couple of ufs filesystems appended to the end of it.

The problem, is that using lofiadm, only the hsfs image is spotted and made available; the ufs filesystems are not seen, so you end up with broken links to 's1' and the like.

To set up a JumpStart server using Solaris ISO images, you must have access to both slice 0 and slice 1 on the image.

To fix the problem, split the contents of slice 1 into it's own image file and then mount this image separately using lofi.

The following procedure describes how to do this.
Code:

# ls -l sol-9*
-rw-r--r-- 1 root root 576364544 Jan 1 11:16 sol-9-u1-sparc-v1.iso
-rw-r--r-- 1 root root 291962880 Jan 1 21:42 sol-9-u1-sparc-v2.iso

This only applies to CD 1, all other isos can be mounted using lofiadm in the normal way.

(1) Get a copy of the VTOC from the ISO image:
Code:

# dd if=sol-9-u1-sparc-v1.iso of=vtoc bs=512 count=1

1+0 records in
1+0 records out

(2) Now find out where Slice 1 starts in the image and how long it is. The starting cylinder for slice 1 is located at offset 452 (decimal) into the VTOC; the length in blocks is at offset 456, with both being 4 bytes long.
Code:

# od -D -j 452 -N 8 < vtoc
0000000 0000000888 0000546560
0000010

Slice 1 starts on cylinder 888, and is 546,560 blocks long. CD for the Solaris OS always have 640 blocks per cylinder, so you can find the starting block of slice 1 as follows:
Code:

# echo 888*640 | bc
568320

So now you know s1 starts at block 568320 and is 546560 blocks long.

(3) Copy slice one into a separate file:
Code:

# dd if=sol-9-u1-sparc-v1.iso of=sol-9-u1-sparc-v1-s1.iso bs=512 skip=568320 count=546560

546560+0 records in
546560+0 records out

(4) Mount both slice 0 and slice 1 as follows:
Code:

# mkdir /cd
# mkdir /cd/s0
# mkdir /cd/s1
# lofiadm -a /path_to/sol-9-u1-sparc-v1.iso
/dev/lofi/1
# lofiadm -a /path_to/sol-9-u1-sparc-v1-s1.iso
/dev/lofi/2

When you mount slice 1, remember that it is a UFS partition, not HSFS as is usual on a CD-ROM:
Code:

# mount -F hsfs -o ro /dev/lofi/1 /cd/s0
# mount -F ufs -o ro /dev/lofi/2 /cd/s1
# cd /cd/s0/Solaris_9/Tools/
# ./setup_install_server /destination_dir

==== How To Upgrade JET

Upgrading JET is normally as easy as

* pkgrm SUNWjet
* pkgadd -d . SUNWjet

The JET packages were designed so that they don't remove your configs, templates or other 'configuration' settings when removed. However, if you hack the JET scripts etc, then this will remove your customisations - hence the reason hacking JET is frowned upon and you are recommended to look at writing your own modules instead.

However, if you are upgrading from JET 3.x to 4.x, then you need to do some additional work. The following was taken from Mike's Sun blog

Things might be a little trickier if you've already got JET 3.7.3 installed, and you want to keep you existing templates etc. The easiest way to accomplish this is to pkgrm all your existing JET packages. (SUNWjet, and all the packages that start with JET), and then

mv /opt/jet /opt/SUNWjet

Finally install the new JET packages.If you've created you own custom modules or scripts, you may need to check them to ensure you haven't hard-coded any /opt/jet paths in them.

The extra bits are

* remember to update your .profile with the new path (/opt/SUNWjet/bin)
* if you have any existing clients, you will need to re-run 'make_client' on them, as /etc/bootparams and/or dhcp macro table will have the directory /opt/jet mentioned as the config directory, rather than the new /opt/SUNWjet

==== How to set up JET as a PXE (DHCP) Server

The easiest way of setting up JET to serve up PXE boot clients (or other DHCP clients) is to copy, edit and then run the "helper script".

cp /opt/SUNWjet/Products/base_config/solaris/make_dhcp /var/tmp

edit it to suit your network
ie

NETWORK=10.1.1.0

NETMASK=255.255.255.0

ROUTER=10.1.1.1

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

Then run it, /var/tmp/make_dhcp

JET will now "do the right thing" based on the allocation method in your template.

==== I noticed alot of docs for jumpstart setup for solaris8,9 I dont see one for solaris10. Why isnt there one for 10? i am interesting in setting up jumpstart for upgrades and clean install. is is safe to do jumpstart straioght from sol7 to sol10?

JET was originally developed in the era of Solaris 7, 8 and 9. As such whatever documentation there is, normally uses one of those in examples.

JET works fine with Solaris 10, and unless anything specific is said, it works in the same fashion with 10 (and indeed 11) in the same fashion as previous versions of Solaris.

JET doesn't deal with upgrades at all; if you want to upgrade using JumpStart, then you need to hand-craft something - there are too many risks for JET to be able to claim to work properly in every situation, so it doesn't claim to do upgrades at all.

=== Configuration ===

==== JET and Boot Servers

Initially, JET was not designed to use the JumpStart Boot Server concepts. There are some internal to Sun modules that are known to extend JET to include Boot Server support and also do so much more for distributed JET environments.

If this is a requirement for you, contact Sun (jet@sun.com) and try to get them involved. If what they have already doesn't fit, it's probably easy for them to adjust it!

==== Disksuite Soft Partitions

The easiest way is to create an md.tab file
and put it under /opt/jet/Clients/clientname

The format of the md.tab should be something like:

d50 -p d40 100m
d40 -m d41
d41 1 1 /dev/rdsk/c1t0d0s0
d42 1 1 /dev/rdsk/c2t0d0s0

or for creating a mirrored stripe with softpartitions:

d70 -p d60 1g
d60 -m d61
d61 1 2 /dev/rdsk/c1t1d0s0 /dev/rdsk/c1t2d0s0
d62 1 2 /dev/rdsk/c2t1d0s0 /dev/rdsk/c2t2d0s0

In addition, the disks used above should all have their vtocs created.
This is achieved with the following lines from JET base_config:

base_config_profile_disk_c0t1d0s0_size="free"
base_config_profile_disk_c0t1d0s7_size="32" (repeat for above disks)

Don't associate any mount points with these partitions.

Finally, to initialise and attach, put in the correct order:

sds_metadevices_to_init="d41 d42 d40 d50 d61 d62 d60 d70"
sds_metadevices_to_attach="d40:d42 d60:d62"

and then add the entries for /etc/vfstab:

sds_newfs_devices="/dev/md/rdsk/d50"
sds_mount_devices="/dev/md/dsk/d50:/d50:2:logging"

==== Upgrade vs Install

JET doesn't do upgrades; you could in theory do it, since JumpStart does support upgrades, but would you really want to ?

Pretty much every system is unique, so just running an 'automated' upgrade on a bunch of systems will produce a mixture of results; in fact, many people, say that you have two real options...

1. make sure your 'data' is saved, and then do a burn and build. Safest option, as you know exactly what you are going to get; bad side is that you need to know where your data is.

2. do a manual upgrade; you can still use the network Solaris images, just omit the '- install'; 'boot net' that way, you are in control and don't invoke any errant finish scripts that you may not be expecting.

Hence the reason we don't promote upgrades; there are too many variables; JET is designed for burn and build, since it's origin is from field installations. Not saying it isn't possible, but by the time you get it working, you may have taken less time to do the upgrades by hand!

==== Using SVM to mirror root disks

"I have configured a jumpstart server using Sun JET 4.1. I am trying to build a client with ODS (disksuite) to mirror rootdisk. I installed the sds package and did all the configuration bit. I have managed to build the client system successfully with all the mirrors and can see the mirror using “metastat –p” command. The only issue is, the system is not showing the metadevices entries in “/etc/vfstab” file and therefore has booted from the normal devices."

When configuring SVM/SDS for root disks, use the sds_root_mirror setting in the template. It was desgined to 'encapsulate' existing filesystems with SVM metadevices - even if you don't actually have the other device to mirror the root disk to yet.

The sds_metadevices_to_* variables are used to create new metadevices and filesystems - setting things here won't affect your /etc/vfstab for existing filesystems unless you do it yourself.

==== JET and JASS Integration

You need to get hold of the JetJASS module, which as far as I know is not part of
the standard download available at www.sun.com/downloads

If you have JetJASS, then doing a 'make_template -T <client> <client> jass' will
add the JASS module details to your template. After that, the options are
pretty self-explanatory - providing you understand JASS that is.

For those who don't have JetJASS, then you need to engage Sun to get hold of it; you can either do that through your local account manager or through the jet@sun.com alias.

==== How does this JetZONES module work ?

The philosophy behind the module was to try to treat zones as a normal JET client. In order to do this, you need to :

*

Enable JET server to deploy zones. This is achieved by adding JetZONES to the JET server
* Add JET support to the 'parent' system. The 'parent' system is the system on which the zones will be created. This is achieved by adding the 'zones' module to the template for the parent.
*

Create a 'zone' definition by using the 'make_zone_template' which gives you a cut down standard Solaris template.
o

zone definitions are not tied to the parent unless specifically referenced in the parent template. By default a zone could be instantiated on any of the possible parents (usual network and resource restrictions obviously apply).

You can manually 'JumpStart' a zone on a parent by running the 'jetzone' command, which will then contact the JET server and hopefully do the right thing.

The obvious caveats, are that very few of the usual modules are zone aware, so you have to be careful with additional jet modules in zone templates.

In summary, the steps are

1. make_template myclient zones
2. (optional) edit the zones section to add the zone names to be used
3. make_zone_template <zone>
4. make_client <zone>
5. make_client <client>

Further comments are within the the zone template

==== Using Jet-4.1, how do I get 'sds' and 'flash' to work together - ie, after applying a flash image, I then want to mirror with the 'sds' module.

You use JET exactly as you would do for a normal build; it just
means that the usual profile information (cluster etc) gets
ignored and the initial install is done from a flash archive.

make_template -f client1 base_config flash sds

edit as usual, build as usual and the sds stuff will get applied
after the first reboot, exactly as a normal JET build.

==== Hi, I have read that jumpstart automates the installation of the OS. Is it possible to include the DB and application?

Absolutely; if you can script the installation and configuration of the DB and application, then JumpStart and/or JET can happily set things up during the install of Solaris.

Use the resources at http://jet.maui.co.uk/wiki/index.php/Resources for pointers to documentation and email aliases to help if required.

==== How can I add packages after the initial installation and patching?

Solaris packages (i.e. the ones that come on the main Solaris CD's) are added using the base_config_add_package / base_config_add_cluster options in the template; these then instruct the Solaris installer to deal with them.

To install other arbitrary packages, patches, files or scripts, look at the 'custom' module that is included in the main SUNWjet package. It has options for custom_packages and custom_patches, along with similar constructs for files and scripts.

Be sure to read the http://jet.maui.co.uk/wiki/index.php/JETPrimer page, as it has an example of using the 'custom' module.

==== Adding Mount Options

The base_config_profile_s?_mtpt variables are used to populate the
client profile. The client profile allows commands such as

filesys c1t4d0s0 1024 /var nosuid

so you should be able to do something like

base_config_profile_s5_mtpt="/var nosuid"

Just remember the quotes!

==== How do I create additional disk/mirrors

JET can be used to create additional mirrors by creating the slices in the base_config section

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

ie:- If you have disks on c3 and c4 you want to mirror to c5 and c6, 1st lay out the partitions

base_config_profile_addtional_disks="c3t0d0 c4t0d0"

base_config_profile_disk_c3t0d0s0_mtpt="/export/extra"
base_config_profile_disk_c3t0d0s0_size="10240"

base_config_profile_disk_c4t0d0s3_mtpt="/export/extra2"
base_config_profile_disk_c4t0d0s3_size="10240"

etc etc

And then use the "simple mirrors" bit of the sds template
############
#
# You can also describe other simple mirrors - these only work if you define
# the partitions in the base_config_profile_disk_ variables
#
# The format of this variable is a space separated list of source=target,
# i.e. c0t1d0=c1t1d0 where the source is the primary
#
sds_simple_mirrors="c3t0d0=c5t0d0 c4t0d0=c6t0d0"

Anything more complicated can be achived by creating a md.tab and supplying it to the build (via the SDS module), as there was/is no point in re-inventing the wheel.

==== JetZONES and other modules - an anomoly

JetZONES will work with other modules as normal, except you will see error messages about being unable to locate packages (see below)

This is because the zones module is intended to be architecture neutral and you will see the base_config_ClientArch= is set to "zone".

After a heavy dig around the code, the only work around would be to change JET core, and that is just not going to happen.

So, it is a case of "BE AWARE" that errors similar to below will appear when you run make_client against the zone template.

Although it says "FAILED" it will still have made the /opt/SUNWjet/Clients/<client> dir

An example below shows the build still worked

---8< make_client output

checking product base_config/solariszone
Checking product custom
WARNING: CUSTOM: Unable to locate custom package SFWmozilla
--------------------------------------------------------------
Check of client b1-zone1

####### ###
# ## # # ###### ##### ###
# # # # # # # # ###
##### # # # # ##### # # #
# ###### # # # # #
# # # # # # # # ###
# # # # ###### ###### ##### ###

---8<

---8< jumpstart.log output
CUSTOM: Installing custom....
CUSTOM: Installing SFWmozilla from: //var/opt/sun/jet/js_media/pkg/custom/i386

Installation of SFWmozilla was successful.
CUSTOM: SFWmozilla installation complete
CUSTOM: Register postinstall script 'postinstall' for boot n
----------------------------------------------------------
Product modules processed, finish up installation tasks
Creating directory: /var/opt/sun/jet/system.add/updated
Copying file etc/jumpstart.conf to //var/opt/sun/jet/config/jumpstart.conf
Copying file Utils/smf/jetjump.xml to //var/svc/manifest/site/jetjump.xml
Copying file Utils/S99jumpstart to //var/opt/sun/jet/post_install/S99jumpstart
NFS Unmounting Media Directories
Unmounting /var/opt/sun/jet/js_media/pkg
:q
# uname -a
SunOS b1-zone1 5.10 Generic_118855-33 i86pc i386 i86pc

=== Troubleshooting ===

==== Solaris x86 Media on Sparc (and vice-versa)

Jumpstarting with x86 Laptops and SPARC systems

Typically a nice use for laptops is to automate the install or to allow
the install of systems lacking a CD-ROM drive.

Running setup-install-server

Prior to Solaris 9, you could use the SPARC Solaris CD and run
setup-install-server on your laptop as well as using an x86 Solaris CD
on a SPARC based system.

This is no longer the case.

The layout of the CD's for Solaris 8 an prior would contain a copy of
the miniroot under "Boot" in the Tools directory of the CD-ROM. The
whole filesystem would be of the "hsfs" type and thus readable across
architectures.

user:/cdrom/sol_8_202_ia/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 18 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/cdrom/sol_8_202_sparc/s0/Solaris_8/Tools% ls -l
total 187
drwxr-xr-x 17 root other 4096 Dec 18 2001 Boot/
-rwxr-xr-x 1 root bin 59058 Nov 27 2001 add_install_client
-rwxr-xr-x 1 root sys 1325 Nov 27 2001 dial
-rwxr-xr-x 1 root bin 18599 Nov 27 2001 rm_install_client
-rwxr-xr-x 1 root bin 11689 Nov 27 2001 setup_install_server

user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs
user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s0
hsfs
user@machine:/% fstyp /vol/dev/dsk/c7t1d0/sol_8_202_ia
hsfs

s1 contains a ufs copy of the miniroot as well. This is what you're
actually running from when you boot off of the CD. However, as ufs is
architecture specific, you can't mount a SPARC ufs partition on an x86
box and vice versa.

user@machine:/% fstyp /vol/dev/dsk/c1t6d0/sol_8_202_sparc/s1
ufs

Starting with Solaris 9, there isn't enough space on CD 1 of 2. CD 1 of
2 should be all that is needed to do an "End User" install. Certain
packages therefore need to be included there.

The hsfs copy of the miniroot takes up over 200M in the Solaris 8 2/02.
Freeing up this space was necessary.

With Solaris 9, the "Boot" directory looks like this:

user@machine:/cdrom/sol_9_sparc/s0/Solaris_9/Tools% ls -l
total 184
lrwxrwxrwx 1 root other 11 Apr 15 2002 Boot -> ../../../s1
-rwxr-xr-x 2 root bin 59586 Apr 15 2002 add_install_client
-rwxr-xr-x 2 root sys 1325 Apr 15 2002 dial
-rwxr-xr-x 2 root bin 18599 Apr 15 2002 rm_install_client
-rwxr-xr-x 2 root bin 13045 Apr 15 2002 setup_install_server

s1 however is ufs, which is architecture specific.

user@machine:/% fstyp /vol/dev/dsk/c1t0d0/sol_9_sparc/s1
ufs

If I attempt to run "setup_install_server" on my x86 laptop from a SPARC
Solaris 9 CD, you get the following:

# pwd
/cdrom/sol_9_sparc/Solaris_9/Tools
# ./setup_install_server /export/install/Solaris_9
ERROR: Install boot image /cdrom/sol_9_sparc/Solaris_9/Tools/Boot does
not exist
Check that boot image exists, or use [-t] to
specify a valid boot image elsewhere

Getting it to work
These instructions are architecture neutral. They will work if you are
trying to configure jumpstart from an x86 server to a SPARC client or
setting up a SPARC server to jumpstart x86 clients.

Option 1: Use the DVD
The Solaris OE on DVD has enough space to continue to include the
miniroot in the architecture neutral portion of itself. The format is
udfs, which is used for DVD's instead of hsfs for CD's.

This assumes that you, of course, HAVE a DVD drive.

The downside of this is that you get a bunch of stuff that might not
want to include on your install image. Things such as all of
localizations and languages take up space on your server's harddrive.

Option 2: Create 2 jumpstart servers
You can run the setup_install_server script on the system of the same
architecture and then share it out via NFS to the other system. This of
course assumes that you have enough temporary space on the system.

Mount up the CD-ROM locally and run "setup_install_server" as if you
were going to make the system you're on a jumpstart server. I recommend
installing to /export/install, but you may have another preference.
After the 1st CD completes, you can add in the second one to the install
image if you like or add it after you've transferred the image over.

Share out the image via NFS my manually sharing it out using the share
command or through /etc/dfs/dfstab with a line similar to this:

#Share out the jumpstart directory for installs
share -F nfs -o ro,anon=0 /export/install

Start the NFS server if necessary.

Mount up the shared directory to your desired server.

Run "setup_install_server"

Option 3: Use NFS
Using NFS, gets around the architecture issue with ufs. You can mount a
NFS share on a client and the client doesn't care what the underlying
filesystem is on the server.

The downside here is that its a bit more complex and that it may take a
bit longer to setup because you have to install the image over the
network. Also, you'll need 2 systems, a SPARC based one and a x86 one.

Add the following line to your /etc/rmmount.conf on the system of the
same architecture that you want to create a jumpstart image of. (If you
want to put a copy of Solaris 9 SPARC on your x86 laptop, add this line
to the SPARC system. If you want to do put a Solaris 9 x86 image on your
SPARC system, the line goes in your x86 system's rmmount.conf)

# share out the CD-ROM
share cdrom* -o ro,anon=0

This line causes vold automatically share out the CD-ROM and all
partitions on that CD. This is needed because NFS sharing doesn't span
filesystems automatically. "anon=0" causes reads by UID=0, which is
normally mapped to user "nobody" by NFS for security reasons to remain
mapped to UID=0. This isn't a security issue here because the CD is a
Read-Only medium anyways.

You will need to re-start vold. Runnning "/etc/init.d/volmgt stop" and
"/etc/init.d/volmgt start" will do this.

You'll likely need to start up the NFS server processes as well. You can
either manually start them each time you boot your system or put the
following into /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /cdrom

If you don't have NFS already sharing out filesystems, you'll need to
start it byt running "/etc/init.d/nfs.server start" as root.

At this point, drop in your CD into the appropriate system. It should
mount and share things automatically.

# mount
/cdrom/sol_9_x86/s2 on /vol/dev/dsk/c1t0d0/sol_9_x86/s2 read
only/nosuid/maplcase/noglobal/rr/traildot/dev=1740003 on Tue Dec 3
15:09:39 2002
/cdrom/sol_9_x86/s0 on /vol/dev/dsk/c1t0d0/sol_9_x86/s0 read
only/nosuid/intr/largefiles/onerror=panic/dev=1740001 on Tue Dec 3
15:09:39 2002

# share
- /cdrom ro,anon=0 ""
- /cdrom/sol_9_x86/s2 ro,anon=0 ""
- /cdrom/sol_9_x86/s0 ro,anon=0 ""

At this point you should be able to CD down
to the appropriate location to run your setup_install_server.

# pwd
/
# cd /cdrom/sol_9_x86/s2/Solaris_9/Tools
# pwd
/cdrom/sol_9_x86/s2/Solaris_9/Tools
# ls
Boot dial setup_install_server
add_install_client rm_install_client

Alternately, you can mount up the directories manually. For example:

# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom /mnt
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s0
/mnt/sol_9_x86/s0
# mount -F nfs -o ro dhcp-ublm02-228-227:/cdrom/sol_9_x86/s2
/mnt/sol_9_x86/s2

All 3 mounts are needed as we have 3 separate filesystems and NFS
doesn't span filesystems.

Now run your "setup_install_server" script.

# ./setup_install_server /export/install/sol_9_x86
Verifying target directory...
Calculating the required disk space for the Solaris_9 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete

You can either install the CDROM 2 of 2 through this method or drop it
in locally as it is in the hsfs format.

There are lots of ways that this can be done outside of this particular
method. Your mileage may vary.

==== ARP/RARP Timeouts

When building a server, you can get the ethernet address from the Open Boot Prom 'banner' command at the 'ok' prompt. By default, this ethernet address is shared between all the ethernet interfaces of the host, so performing a JumpStart off an ethernet interface other than the default alias 'net' proceeds as normal.

When using IPMP or Sun Cluster 3, the value of the Open Boot Prom 'local-mac-address' option is set to true which in turn means that every ethernet interface uses it's own ethernet address, and not the hardcoded one in the Open Boot Prom.

On subsequent re-build attempts over the onboard default 'net' interface, everything is ok; however, if you are building over a different device to 'net' the ethernet address may not match the one you originally used in your template.

As the JumpStart server /etc/ethers files does not match this new ethernet address, it is unable to reply to the booting machine, hence the extended period of ARP/RARP timeouts.

To locate mac addresses for different adapters when local-mac-address? is set to true, you can do the following:

* At the OBP prompt, do a 'show-nets' to list the network adapters available
* Select the adapter
* cd <ctrl+y>
* .properties

==== System hangs at a # prompt

If 'diag-switch?' is set to true in OBP, the system will hang at the '#' prompt prior to rebooting, just after Solaris has installed.

This seems to happen on all types of hosts from V100's through to F15Ks. You need to use the appropriate commands to change the obp setting depending on your platform.

==== Forcing Speed/Duplex during JumpStart

You really should just use Auto-negotiation on switches; it works these days and is reliable.

Turning autonegotiation off and setting speed/mode manually is called
"forced mode".
For the Sun[TM] GigaSwift on-board interfaces and Network Interface Cards
(ce), and for bge on-board interfaces, boot in "forced mode" is possible.

In jumpstart "boot net", 3 steps are involved.
The driver must be forced in all 3 steps of the jumpstart boot process.

o 1st Step: force the interface on boot prom for booting

ok boot /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
or
ok devalias net /pci@1f,2000/pci@1/network@0:speed=100,duplex=full,
ok boot net

o 2nd Step: inetboot is loaded.

An inetboot file on the boot server which honours the "forced" ce setting
is needed.
This is included in Solaris 8 Patch-ID# 111306-05 , for Solaris 9, it's
Patch-ID# 113578-01 .

o 3rd Step: client uses the OS from the file system of the boot server

create a
../Boot/platform/sun4u/kernel/drv/ce.conf or
../Boot/platform/sun4u/kernel/drv/bge.conf
(the same directory, in which the ce 32 bit driver sits, one single line,
example for 100 FDX):

adv_autoneg_cap=0 adv_1000fdx_cap=0 adv_1000hdx_cap=0 adv_100fdx_cap=1
adv_100hdx_cap=0 adv_10fdx_cap=0 adv_10hdx_cap=0;

==== JumpStart & JET logs

JumpStart saves a log of the output from the system install in the file /var/sadm/system/logs/finish.log. The bad news, is that only covers the log output up to the reboot at the end of the initial install.

JET includes post-reboot processing in most cases, so the complete JET log (a superset of the JumpStart log) can be found at /var/opt/sun/jet/jumpstart_install.log. There is also a link to the system log called finish.log in the same directory.

The JET log will include the system finish log output and also any output from JET processing at subsequent reboots.

==== Solaris 10, SSH doesn't start

When JumpStart'ing Solaris 10 GA (and maybe some of the updates), the ssh software is installed but the daemon doesn't start; 'svcs -a' reporting it in a maintenance state.

The root cause is that the ssh host key is not created for some reason, so you need to execute the following commands:

/lib/svc/method/sshd -c
/usr/sbin/svcadm clear network/ssh

In JET, you could put the commands into a script in /opt/jet/Clients/common.files/fixup-ssh and then use custom_scripts="fixup-ssh" to get JET to fix the problem for you.

#!/bin/sh
#
# Fix Up SSH on Solaris 10
#
if [ ! -f /etc/ssh/ssh_host_rsa_key -o ! -f /etc/ssh/ssh_host_dsa_key ]; then
/lib/svc/method/sshd -c
fi

/usr/sbin/svcadm clear network/ssh

==== TFTP Problems While Booting

A number of people have come across problems with TFTP; specifically TFTP failing during (or sometimes at the start of) a transfer.

TFTP is the 'Trivial File Transfer Protocol' and as such has some simple limitations. One such, is that the original protocol allows up to 65,536 blocks to be transferred; each block defaulting to 512 bytes -> 32Mb limit.

Some implementations allow the block size to be increased, others allow the block counter to roll-over; 65,536 == 0 again.

Sun changed their in.tfptd implementation between Solaris 8 and 9, and from tests, it seems they have added the 'change block size' code. Tests on Solaris 9 and 10 indicate that the Sun in.tftpd server still stops at block 65,536 though.

Solaris 10 Update 1 for x86/64 has a new boot mechanism, and the file to be downloaded via TFTP is 48Mb or so. If you are using a Solaris 8 JumpStart server, then you are going to hit trouble. Either move to Solaris 9 or you could try and take the in.tftpd binary from a Solaris 9 client.If things still don't work, then you could go off and google for a replacement tftpd server; http://www.kernel.org/pub/software/network/tftp/ has done the trick for me in the past, and doesn't need much to convince it to compile under Solaris.

==== Solaris 10 Update 1 and Flash archive problems

When deploying a flash archive taken from a Solaris 10 Update 1 install, the initial flash completes, but subsequent JET processing stops after the first reboot.

When you build a system using flash on Solaris 10, the smf(1m) database gets stored as part of the flash archive. Under Solaris 10 GA/FCS, the smf(1m) database entries were keyed using the manifest inode number (amongst other things), so when you redeployed the flash, the inode numbers changed and smf(1m) re-scanned the manifest files.

Under Solaris 10 Update 1, Sun have removed the inode time from the database key, so it doesn't rebuild the database as it used to.

If you built the original system using JET, the jetjump.xml file is still 'known about' by the smf(1m) database, so when you come to deploy the flash archive using JET, smf(1m) happily ignores the newly deposited jetjump.xml file.

Officially, this is a bug/feature introduced in Solaris 10 Update 1 (BugID 6251841). The version of JET about to be released has a work around for this situation, so it will go away.

The work around for now, is to do the following *before* creating the flash archive:

# svccfg -s smf/manifest delpg var_svc_manifest_site_jetjump_xml

This 'feature' is also present in Nevada builds (Solaris Express / Solaris 11).

==== I am warned about missing patches, but cannot add

If you get the warning

WARNING: Patch 119375-11 has not been applied to the boot image.

And then run the patchadd -C command as instructed, only to be told the patch is already present,

This may be because patchadd was broken in Solaris 10 (03/05) and failed to check correctly. This has been fixed with later versions/patches.

Alternatively if you are using Solaris 10 01/06 or later there is an issue that patchadd cannot check the mini-root.

As it is only a WARNING, it will not cause make_client to fail. If make_client fails, look back to identify earlier FAIL messages.

A future release of JET may well bypass this error

=== Bug / Problem Reporting ===

==== Having Problems with JET and need help ?

If you post a question here that concerns a specific problem you are seeing with JET, then please include the template and the output from /var/opt/sun/jet/jumpstart_install.log - or at the very least, say you have that information and be prepared to send it on to who ever elects to try to help you.

==== Reporting a Bug

Think you've found a bug in JET ? If so, first up check it is a bug by asking the appropriate question on this website or send your theory and reasoning to jet@sun.com.

JET 'evolved' over about 5+ years, so the chance of someone making a mistake in the scripting is not beyond possibility! It could however be something JET was not designed for in which case it's an RFE - Request For Enhancement.

==== Request For Enhancements (RFEs)

If you discover something you want changed in JET, then it normally falls into two categories:

Implement it in a module

Support for non-core features or additional configuration work can be easily delivered through a new JET module. This way, the main code base stays unaffected for the vast majority of people who use it, and the module can evolve as the authors see fit.

Submit the change as an RFE

If the feature needs to go into the main JET package or one of the pre-supplied modules and can not be delivered as a module, then you need to discuss the matter with the JET folks at Sun (jet@sun.com) and work on drafting an RFE. Depending on how much they agree with your suggestion and how much time they have, the actual change could be made quickly or could take months - such is the nature of change.

Faq

2007-09-03T13:33:12Z

Marty:

Copy

2006-09-26T16:11:53Z

Marty:

This module allows you to copy files or media from NFS servers to the client being built.

After adding the module to the JET server, add the module to an appropriate template:
# make_template -f -T <client> <client> copy
Then edit the template and specify the name of the file that contains the list of things to copy; the template has an example of the format of the file.

[[Media:JetMauiCOPY.pkg|Copy module (Rev 1.0.3)]]

Copy

2006-09-26T15:09:17Z

Marty:

File:JetMauiCOPY.pkg

2006-09-26T15:08:52Z

Marty:

Copy

2006-09-26T09:52:53Z

Marty:

File:JetMauiCOPY 1.0.1.pkg

2006-09-26T09:52:19Z

Marty:

Resources

2006-09-19T08:48:05Z

Marty:

== JET Web Resources ==

* [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit JET Download]
* [http://www.sun.com/bigadmin/content/jet/ JET @ BigAdmin]
* [mailto:jet@sun.com Sun's JET Alias] - for reporting bugs or asking Sun for help etc
* [http://groups.yahoo.com/group/JETJumpStart/ JET Yahoo Group] & [mailto:JumpStart@yahoogroups.com JET Yahoo Group mail alias]

== Modules ==

* [[CustomUpdate]] : Automatically keeps your custom packages up to date from your packages directory
* [[Copy]] : Module that specialises in copying files or directories as part of the install process
* [[N1SM]] : Sun N1 System Manager installation module

Main Page

2006-09-19T08:47:32Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://jet.maui.co.uk/blog/?feed=rss2&category_name=News|title=none|max=5</rss>

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [http://jet.maui.co.uk/faq JET FAQ]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://onesearch.sun.com/search/onesearch/index.jsp?col=downloads-products&qt=JumpStart+Enterprise+Toolkit Sun Download Centre]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

MediaWiki:Sidebar

2006-09-19T08:26:03Z

Marty:

Main Page

2006-09-19T08:25:03Z

Marty:

__NOEDITSECTION__ __NOTOC__
== News ==
[[Image:Jumpstart_title.gif|Jumpstart_title.gif|frame|]]
<rss>http://jet.maui.co.uk/blog/?feed=rss2&category_name=News|title=none|max=5</rss>

== JET Resources ==

* [[Documents|JET Documents]]
* [[Resources|JET Resources]]
* [http://jet.maui.co.uk/faq JET FAQ]

If you wish to contribute to the JET Resources community, please contact us and ask for access to the Wiki.

== About JET ==

=== What Is the JumpStart Enterprise Toolkit ? ===

The JumpStart Enterprise Toolkit is the name given to the Sun Microsystems JumpStart Framework, developed by Sun in the UK. The toolkit is part of the N1 SPS suite and is available as a seperate download from [http://www.sun.com/downloads www.sun.com/downloads]

=== JumpStart Information ===

There are many benefits to using a framework to extend the functionality of JumpStart, for example:

* improve the consistency of system installs
* faster implementation of projects
* improve build quality of the installations
* embed company best practices

The toolkit is aimed at providing basic OS installations along with frequently used/requested addtional product installation, and minimal configuration.

Copy

2006-09-15T16:24:08Z

Marty:

Resources

2006-09-15T16:22:12Z

Marty:

== JET Web Resources ==

* [http://www.sun.com/download/products.xml?id=438b5915 JET Download]
* [http://www.sun.com/bigadmin/content/jet/ JET @ BigAdmin]
* [mailto:jet@sun.com Sun's JET Alias] - for reporting bugs or asking Sun for help etc
* [http://groups.yahoo.com/group/JETJumpStart/ JET Yahoo Group] & [mailto:JumpStart@yahoogroups.com JET Yahoo Group mail alias]

== Modules ==

* [[CustomUpdate]] : Automatically keeps your custom packages up to date from your packages directory
* [[Copy]] : Module that specialises in copying files or directories as part of the install process
* [[N1SM]] : Sun N1 System Manager installation module

File:JetMauiCOPY 1.0.0.pkg

2006-09-15T16:21:19Z

Marty:

N1SM

2006-09-14T13:12:42Z

Marty:

This module allows you to install the Sun N1 System Manager on to a server. N1SM can then be used to install further systems (Linux etc) if required.

After adding the module to the JET server, add the module to an appropriate template:
# make_template -f -T <client> <client> n1sm
Then edit the template and configure the options as usual

[[Media:JetMauiN1SM_1.0.0.pkg|N1SM module]]

Resources

2006-09-14T13:09:32Z

Marty:

File:JetMauiN1SM 1.0.0.pkg

2006-09-14T13:08:34Z

Marty:

JetWalkthrough

2006-08-29T13:12:05Z

Marty:

== JET install and Configuration to server DHCP / PXE intel clients ==

Contributor: Paul Juster

== Overview of my set up ==

I am using two Intel machines, my JumpStart server is ''sun1'' (192.168.0.250) and my JumpStart client ''vmclient'' needs to end up with a static IP 192.168.0.200 (a flat network). Operating system is Solaris 10 x86.

On the JumpStart server I have already copied the Intel x86 DVD files to my server
# /cdrom/cdrom0/Solaris_10/Tools/setup_install_server /export/installx86
the alternative is to use the jet script to do this (/opt/SUNWjet/bin/copy_solaris_media).

In this example I am using JET 4.3 and I have only displayed lines in files that I changed from the default or that I want to make clear what the setting is.

Do not assume any of the below applied to a SPARC JET client

== Download and Install the packages SUNWjet & documentation packages ==

Get JET from the Sun download centre (http://www.sun.com/downloads)

# bunzip2 jet.pkg.bz2
# pkgadd -d jet.pkg
select Packages 10 & 11

== JET Folder structure ==

I created/used the following folders

/export/pkgs (not used but needed)
/export/patches (not used but needed)
/export/installx86 (Where the media has been copied too)

Note this is a simple configuration be in a larger setup /export/media should be used with sub folders for each media type.

== JET NFS shares ==

The following shares were created to support JET.

("JET framework" share was automatically created during the package install)
# share
- /opt/SUNWjet ro,anon=0 "JET Framework"
- /export/pkgs ro,anon=0 "Jumpstart Media"
- /export/installx86 ro,anon=0 "Jumpstart Media"
- /export/patches ro,anon=0 "Jumpstart Media"

== Modify JET configuration ==

I edited /opt/SUNWjet/etc/jumpstart.conf to reflect my JET folder structure.

#
# This config file defines the jumpstart specific variables.
#
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export

== Adding Solaris Location ==

A “Solaris location” is a pointer to a folder containing the solaris installation media that has been copied to the JumpStart/JET server.
The Solaris media is copied to the JET server in two ways

a. /cdrom/cdrom0/Solaris_10/Tools/setup_install_server
b. /opt/SUNWjet/bin/copy_solaris_media

a. is the traditional JumpStart method (I used), b. is the JET method.

Once copied a “Solaris location” is needed for JET to reference and use, this is done by running

# /opt/SUNWjet/bin/add_solaris_location 10i /export/installx86

== A “template” ==

A JET template outlines a JET clients configuration/installation and contains the answers to the installation questions that are normally asked (this is a very simplistic view as a lot more can be accomplish with the template). I created a template called vmclient

# /opt/SUNWjet/bin/make_template vmclient

== Customise the template (DHCP/PXE) ==

Once the template has been created some basic details needed to be added.

(I made the following changes and ignored all other lines at the moment)
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i
base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254
base_config_client_allocation="grub"

Its worth noting that intel machine can only be built using JET/JumpStart by using DHCP and PXE boot methods, in order for this to be configured within JET following line partly configures this.

base_config_client_allocation="grub"

== DHCP server setup ==

In order for JET to support DHCP clients, the server needs some basic details to be added to /opt/SUNWjet/Products/base_config/solaris/make_dhcp file

# cat make_dhcp
################################################################################
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is not present, then activate it
#
# Change the NETWORK details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

In order for these changes to be applied to the solaris dhcp server, permissions on the make_dhcp file need to be changed so the file can be executed.

# chmod +x make_dhcp
# ./make_dhcp
Created DHCP configuration file.
Created dhcptab.
Added "Locale" macro to dhcptab.
Added server macro to dhcptab - sun1.
DHCP server started.
Added network macro to dhcptab - 192.168.0.0.
Created network table.

As you can see this has populated/configured the dhcp server with the basic settings, the client specific settings are added when make_client is run.

== Populating JET with a client ==

A client can now be added to the JET server using the make_client script.

# /opt/SUNWjet/bin/make_client -f vmclient
Gathering network information..
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Solaris: client_prevalidate
Clean up /etc/ethers
Solaris: client_build
Creating sysidcfg
Creating profile
Adding base_config specifics to client configuration
Solaris: Configuring JumpStart boot for vmclient
Starting SMF services for JumpStart
Solaris: Configure PXE/grub build
Adding install client
Doing a TEXT based install
Leaving the graphical device as the primary console
Configuring vmclient macro
Using local dhcp server
PXE/grub configuration complete
Running '/opt/SUNWjet/bin/check_client vmclient'
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Checking product base_config/solaris
Checking Solaris boot image for critical patches (this may take a while..)

WARNING: Patch 119375-03 has not been applied to the boot image.
This patch has been critical to the successful
installation of the O/S.

Please apply the patch with the command:

# patchadd -C /export/installx86/Solaris_10/Tools/Boot 119375-03

--------------------------------------------------------------
Check of client vmclient
-> Passed....

The obvious thing from this output is that it passed, but also you can see that a PXE/Grub build took place (which means that this client is an intel client)

== Client boot ==

The intelx86 client needs booting off the network, F12 is the normal key at boot time.

The intelx86 client gets an ip address

The grub loader is loaded

The grub loader load the multi boot image from the /tftpboot directory and hopefully now installation windows/questions will be asked.

== Reference files ==

=== jumpstart.conf ===

# This config file defines the jumpstart specific variables.
#
# Version: $Revision: 1.5 $
# Last Updated; $Date: 2006/02/04 12:08:58 $
#
# Location of the additional media for patches and packages:
#
# These paths should be URI form e.g. nfs://<serverip>/<path> or <path>
# Currently only PKG_DIR and PATCH_DIR can be on a remote NFS server.
# If they are just <path>, the appropriate address of the JumpStart server
# will be added.
#
# N.B. if the media location is on a different server, please ensure it is
# routable from the client !
#
JS_Default_Root_PW=boajrOmU7GFmY
JS_BUILD_DIR=/var/opt/sun/jet
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export
JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30"
#JS_CLIENT_MANAGEMENT="dhcp bootp"
JS_CLIENT_MANAGEMENT="bootp"

=== make_dhcp ===
#!/usr/bin/ksh
#
# This config file defines the dhcp variables.
#
# Copyright 2005 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
################################################################################
#
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is notpresent, then activate it
#
# Change the NETWORk details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

=== template/vmclient ===
###############################################################################
#
# Client template file
#
# Client: vmclient
# Created: Friday May 19 19:26:39 BST 2006
#
# This file was automatically generated using 'make_template'
###############################################################################

###############################################################################
#
# Product: base_config
#
# Synopsys: Basic host information
#
###############################################################################

############
#
# Architecture type:
# sun4c : e.g. SS1, SS2, SS IPX
# sun4d : e.g. SS1000, SS2000
# sun4e : ?
# sun4m : e.g. SS LX, SS4, SS5, SS10, SS20
# sun4u : UltraSparc - U1, U2, E3x00, E4x00 etc
# sun4u1 : E10K
# sun4v : T2000
#
# i86pc : Intel X86
#
# Ethernet can be obtained from the 'banner' command at OBP
#
# OS is one of the values you used to register the solaris media using
# the add_solaris_location command
#
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i

############
#
# Client allocation
#
# The mechanism used to build this client; by default, the options listed
# in /opt/jet/etc/jumpstart.conf will be tried; you should only set this
# if this particular client needs to do something different.
# JET supports bootp, dhcp, and grub as allocation options.
# Currently grub is only supported on i86pc architectures.
#
base_config_client_allocation="grub"

# If you are using grub, you can set this variable to apply additional
# grub directives to the menu.lst.<MACADDRESS> file.
#
base_config_grub_append=""

############
#
# products is the set of products to install after base_config; this
# should be updated automatically by make_template, so you
# will only need to change it, if you wish to omit certain
# modules when testing/debugging.
#
base_config_products=""

############
#
# JumpStart sysidcfg information
#
# The sysidcfg file provides information at initial boot time so that the
# system can properly identify itself. The interface and ip address defined
# here MUST be on the same subnet as the JumpStart server. The root password
# is set here also and must be written in encrypted format. The default value
# shown here is "newroot". The timeserver is normally the IP address of the
# JumpStart server.
#
# nameservice examples:
# NONE
# NIS { domain_name=uk.sun.com name_server=nis.uk.sun.com(129.159.91.1) }
# or for DNS
# DNS { domain_name=uk.sun.com name_server=192.168.1.1 search=uk.sun.com }
#
# network_interface:
# le0, hme0
# or PRIMARY (the default interface - net in OBP)
# N.B. PRIMARY is only valid from Solaris 7 upwards
#
# locale:
# en_UK for Solaris 2.6
# en_GB for Solaris 7 and above
#
# timeserver: Where the client gets the current time from.
# Leave blank to default the the JumpStart server
#
# Alternatively, set to 'localhost' to trust the current
# hardware clock on the client
#
# terminal: terminal type (vt100/vt220/sun etc)
#
# security_policy: Kerberos policy (Solaris 8 +)
#
# protocol_ipv6: Use ipv6 or not (Solaris 8 +)
#
# default_route: Solaris 9 allows a default route to be set
# (ignored on all other versions of Solaris, less than 9)
#

base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254

########################################
# X86, X64 specific settings. If this is an x86 client, then you may need
# to configure these settings. They are ignored for SPARC builds.
#
# base_config_x86_nowin:
# This stops Solaris from trying to run windows during the install.
# the default value is yes.
#
# base_config_x86_console:
# Set the console to the correct tty port. This is used for doing installs
# via the serial port or the SP. b1600,v20z and v40z use ttya. lx50, v60x,
# and v65x use ttyb. NOTE: you only need to set this if you are NOT going
# to connect a keyboard and monitor to the client.
#
# base_config_x86_disable_acpi:
# Disable ACPI - sometimes disabling ACPI makes the install go
# better due to how the interrupts are handled. Non-Null disables ACPI.
#
# base_config_x86_safetoreboot:
# The Solaris installer can't control the BIOS, therefore does not
# know if its safe to reboot the client as it may simply jumpstart
# again. If your PXE boot is a one time option, and the next reboot
# will attempt to boot from disk, then you probably want to set this
# option to "yes". Otherwise, leave it as it is so that it won't reboot
# and therefore allow you to manually change your BIOS to boot from disk.
#
# base_config_x86_disable_kdmconfig:
# X86 systems sometimes go interactive on the first reboot (Bug 6321043)
# on Solaris 10 Update 1. Setting this parameter will stop this from
# happenning.
#
# base_config_x86_confflags
# The parameters specified for this variable are passed directly to
# add_install_client -b confflags= option.
# For e.g., by specifying,
# base_config_x86_confflags="-f -P/boot/solaris/dca"
#
# add_install_client is called with -b confflag="-f -P /boot/solaris/dca"
# option.
#
# base_config_sysidcfg_x86_kdmfile
# Append the file specified here to sysidcfg file.
# This variable can reference a file relative to the
# Clients/<clientname> directory or a absolute path.
#
#
base_config_x86_nowin="yes"
base_config_x86_console=""
base_config_x86_disable_acpi=""
base_config_x86_safetoreboot=""
base_config_x86_disable_kdmconfig=""
base_config_x86_confflags=""
base_config_sysidcfg_x86_kdmfile=""

#
#
#
#
#######

#
# Want to create your own custom profile ? if so, use this variable to
# reference a file relative to the Clients/<clientname> directory or
# absolute path, otherwise fill in the other details below to get toolkit
# to create one for you.
#
# If absolute path is specified, then the profile file is copied
# to Clients/<clientname> directory.
#
base_config_profile=""
#
#######
# OR fill out the base_config_profile variables below.
############
#
# JumpStart profile information
#
#
# A limited profile can be automatically generated here. If further
# customisation is required, then you can manually create a profile in the
# client directory and reference it in the base_config_profile variable.
#
# Cluster:
# SUNWCrnet : Minimal. Solaris 10 only
# SUNWCreq : Required - really basic, good for testing
# SUNWCuser : User collection
# SUNWCprog : User + Developers collection
# SUNWCall : All packages
# SUNWCXall : All + OEM packages (mandatory for E10K)
#
# usedisk: defines the disk that the OS will be loaded on to - bootdisk
# (if this is set to rootdisk. , then the current boot disk will
# be used)
#
# dontuse: defines disks that should not be used..
# ** N.B. This will only be used if 'usedisk' is NOT set
# Space seperated list of disks of the form c?t?d?
#
# partition sizes:
#
# if partitions are not required simply leave blank. In order to maintain
# consistency the partitions will always use the same slice number:
#
# / s0
# swap s1
#
# We've prepopulated the remaining slices based on Sun defaults,
# but you can change this.
# /var s5
# /usr s6
# /opt s7
#
# at most one partition can have the size 'free' which denotes all the
# unallocated/spare space on a disk.
#
base_config_profile_cluster=SUNWCXall
base_config_profile_usedisk=rootdisk.

base_config_profile_dontuse=""

base_config_profile_root=free
base_config_profile_swap=256

#
# If you are using VxVM and want your boot disk to look like the mirror, then
# leave slices 3 and 4 empty. If you do not care about keeping the two disks
# looking cosmetically the same, please just make sure you have two free slices
# somewhere on the disk for VxVM!
#
# If you are not using VxVM, then you can use s3 and s4 for whatever you wish!
#

base_config_profile_s3_mtpt=""
base_config_profile_s3_size=""

base_config_profile_s4_mtpt=""
base_config_profile_s4_size=""

base_config_profile_s5_mtpt="/var"
base_config_profile_s5_size=""

base_config_profile_s6_mtpt="/usr"
base_config_profile_s6_size=""

#
# If you are using DiskSuite, the default behaviour is to use slice 7 as a
# location for metastate databases. If you are using DiskSuites default config,
# please avoid using s7 for data!
#

base_config_profile_s7_mtpt="/opt"
base_config_profile_s7_size=""
#
############

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

############
#
# Additional locales/geos e.g. N_Europe, C_Europe
#
#
base_config_profile_add_locales=""
base_config_profile_del_locales=""

base_config_profile_add_geos=""
base_config_profile_del_geos=""

############
#
# UFS Logging
#
# Solaris 7 and above support UFS+, which allows for a logging filesystem
# under UFS. If you want to use this feature on any of the UFS mount points,
# please specify the mount points here, as a space seperated list, or enter
# the keyword "all" to enable logging on all UFS filesystems.
#
# Solaris 9 09/04 enables logging by default. You can also specify mountpoints
# preceded by a - sign to say that you DON'T want logging enabled on that
# filesystem, or you can use the keyword "none" to say you don't want any
# ufs logging turned on at all.
#
# N.B. root (/) can be included in the list, and is included by default if
# using either the "all" or "none" keyword.
#
# Finally, you can't mix keywords and mountpoints. i.e. "all -/" is NOT
# valid.
# e.g. base_config_ufs_logging_filesys="all" : log all filesystems
# base_config_ufs_logging_filesys="none" : log no filesystems
# base_config_ufs_logging_filesys="-/ /var -/usr" : log /var, but not / and /usr.
#
base_config_ufs_logging_filesys="all"

############
#
# Packages to add to/remove from the selected cluster
#
# Use this to populate the profile with package <pkg> <add|delete> entries
#
base_config_profile_add_packages=""
base_config_profile_del_packages=""

############
#
# Clusters to add to/remove
#
# Use this to populate the profile with cluster <cluster> <add|delete> entries
#
base_config_profile_add_clusters=""
base_config_profile_del_clusters="SUNWCpm SUNWCpmx SUNWCdial SUNWCdialx"

############
#
# Remote file systems (NFS)
#
# Specify these as space seperated list of pairs as follows, using ? as
# the seperator (as : has special meanings with nfs!)
#
# e.g. to mount 1.1.1.1:/fs on /fs you would create the entry
# base_config_nfs_mounts="fs?1.1.1.1:/fs"
#
base_config_nfs_mounts=""

############
#
# Host information
#
# This section defines most things network related etc.
#
# In addtion, if the machine will be JumpStarted as one name/address and
# needs to have a different name/address once installed, this is where you
# can set that information.
#
# nodename: the value for /etc/nodename if it's not the default
# hostname
#
# defaultrouter: the value for /etc/defaultrouter.
#
# notrouter: if this is set, the file /etc/notrouter will be created
#
# dns_domain: domain entry for /etc/resolv.conf
#
# dns_nameservers: nameserver entries for /etc/resolv.conf
# (list of ip addresses, space separated)
#
# dns_searchpath: list of entries to go in the search line
#
# dns_disableforbuild: If there is no DNS available in the build
# environment, set this to delay the configuration
# of DNS until later on.
#

base_config_nodename=""
base_config_defaultrouter=""
base_config_notrouter=""

base_config_dns_domain=""
base_config_dns_nameservers=""
base_config_dns_searchpath=""

base_config_dns_disableforbuild="yes"

###########
#
# NTP configuration
#
# Specify a list of names or ip addresses for the NTP servers. The first
# one will be given a 'prefer' tag. This section will only place lines
# of the form: server <ipaddress/name> [prefer]
# into the /etc/inet/ntp.conf file. If you require more control of ntp,
# please use the custom module to deploy your own custom ntp.conf file.
#
# N.B. If you do use names, they must be resolvable in your name service.
#
base_config_ntp_servers=""

############
#
# Network Interface information
#
#
# networkifs: a list of interfaces to be defined,
# space seperated "le0 hme0".
# N.B. the sysidcfg interface will already be configured
#
# Logical interfaces should be defined using _'s rather
# than :'s.
#
# networkif_<ifname>: the details of the interface <if>
# "netname netmask hostname address"
#
# netname: arbritrary name for /etc/networks
# netmask: netmask of this if (e.g. 255.255.255.0)
# hostname: unique hostname (N.B. not multihomed)
# address: IP address of this interface
#
# For example:
#
# base_config_networkifs="ge0 ge0_1"
# base_config_networkif_ge0="bkp 255.255.255.0 me-bkp 192.168.1.0"
# base_config_networkif_ge0_1="bkp2 255.255.255.0 me-bkp2 192.168.2.0"
#

base_config_networkifs=""
base_config_networkif_le0=""

# N.B. Logical interfaces MUST use _ rather than : as illustrated below
base_config_networkif_le0_1=""

############
#
# IP Multipathing (Solaris 8+)
#
# IPMP default mode is automatic failback.
# To change this mode edit /etc/default/mpathd
#
# ipmp_networkifs: a list of interfaces to be defined under ipmp control
# a space separated list of pairs only
# e.g. "qfe0_qfe4 qfe1_qfe5"
#
# N.B. If the primary interface is used in an ipmp group, the
# system must be rebooted manually after installation to
# activate ipmp.
#
# N.B. Can only setup ipmp group with pairs of interfaces in one
# of the following configurations:
# active-standby failover:
# Set ipmp mode = s, and specify one logical
# hostname/ip address pair.
# failover with outbound load spreading:
# Set ipmp mode = l, and specify one logical
# hostname/ip address pair.
# active-active with outbound load spreading:
# Set ipmp mode = l, specify a second logical
# hostname/ip address pair for the second interface.
#
# ipmp_networkif_<if>_<if>: "netgroup mode test1 test2 mask hostname log-ip hostname2 log-ip2"
#
# details of the interfaces in the ipmp group
# e.g. networkif_ipmp_qfe0_qfe4
#
#
# netgroup: ipmp interface group name
# e.g. database-net
#
# ipmp mode: s = standby (failover only)
#
# ** test addresses are allocated last,
# ** first test address will be on the
# ** first virtual interface of the
# ** first physical adapter. Second
# ** test address will be on the second
# ** physical adapter.
#
# l = load spreading / active-active
#
# ** test addresses are allocated on
# ** first virtual interfaces on both
# ** the first and second physical
# ** adapters.
#
# To force the test addresses onto the physical
# adapters, use the suffix 'p' to the above
# modes, i.e. 'sp' or 'lp'. This is not
# recommended and may break certain applications.
#
# test1: ipmp test address1
# test2: ipmp test address2
#
# N.B. these addresses must not be used or
# placed in the hosts file
#
# mask: netmask for ipmp pair
#
# hostname: unique hostname for logical ip
#
# log-ip: logical ip address for first i/f of pair
#
# N.B. The following two parameters are for active-active
# configurations only. Do not specify them for an
# active-standby configuration.
#
# hostname2: unique hostname for logical ip
#
# log-ip2: logical ip address for second i/f
# of pair
# IPMP on Solaris 10.
# If you are running Solaris 10, you can optionally configure the
# system to have NO test addresses. In this case, the ipmp mode should be set
# to "ln" or "sn" depending on whether you want outbound load spreading or
# not and the 2 test addresses do not need to be privided.
#
# Examples:
# --------
#
#
# base_config_ipmp_networkifs="qfe0_qfe1"
# Outbound load spreading 2 hostnames, test on virtual interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db l 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3 apache 10.0.0.4"
# Outbound load spreading 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db lp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db sp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, no test addresses (Sol 10 only).
# base_config_ipmp_networkif_qfe0_qfe1="db sn 24 oracle-db 10.0.0.3"
#
#
base_config_ipmp_networkifs=""
base_config_ipmp_networkif_qfe0_qfe1=""

############
#
# Misc options
#
# this section is a catchall for other options not included above
#
# update_terminal: if set, put the sysidcfg terminal type into inittab
#
# enable_savecore: if set to any value, enable save core (Solaris 2.6 only)
#
# dumpadm_minfree: set a limit so that crash dumps don't fill up the
# dump filesystem. See dumpadm(1M) -m option for
# possible values.
#
# noautoshutdown: if set to any value, disable power management
#
# enable_rootlogin: if set to any value, enable network root login
# from both telnet/rsh and ssh
#
# enable_rootftp: if set to any value, enable root ftp access
#
# shutup_sendmail: if set, create an alias hostname. to shut up sendmail
#
# poweroff_afterbuild: if set, shut the machine down once it has been built
#
# base_config_dedicated_dump_device:
# if set, dumpadm will configure the partition as a
# Dedicated Dump Device. See dumpadm(1M) for supported
# Operating Environments.
# (Device path e.g. /dev/dsk/c?t?d?s?)
#
# N.B. This partition is for the SOLE use of the crashdump utility !
#
# enable_altbreak: if set, enable alternate break sequence
#
# disable_sysid_probe: if set, skip the sysid stuff on the first reboot; this
# usually just tries to rarp ip addresses for additional
# interfaces and takes *ages* on machines with lots
# of unused network adapters.
#
#

base_config_update_terminal="yes"
base_config_enable_savecore="yes"
base_config_dumpadm_minfree="20000k"
base_config_noautoshutdown="pm_disabled"
base_config_enable_rootlogin=""
base_config_enable_rootftp=""
base_config_shutup_sendmail=""
base_config_poweroff_afterbuild=""
base_config_dedicated_dump_device=""
base_config_enable_altbreak=""
base_config_disable_sysid_probe=""

############
#
# NFSv4
#
# Set up the NFSv4 domain to prevent being prompted at first reboot.
# If not set, this will default to the entry in base_config_dns_domain,
# and if that is not set, to the value 'domain', which is the default
# in /etc/default/nfs
#
base_config_nfsv4_domain=""

############
#
# N.B. Unless you need to point this client at alternate media for patches
# and packages that is not held on this server, please skip this section!
#
# productdir is where to find the products. This should be a URI style
# path, i.e. nfs://192.168.1.1/export/install/pkgs. If the server
# is the JumpStart server, then it should just be specified
# as a normal path.
#
# patchdir is where to find the patches. Same format as productdir.
#
# --------------------------------------------------------------------------
# Leaving the following blank means they will be populated using jumpstart.conf
# and the JumpStart servers ip address. This is the default behaviour
# and should only be changed if your patch/package repository is not held
# on this server.
# --------------------------------------------------------------------------

base_config_productdir=""
base_config_patchdir=""

#
# Last one - mainly for developing JumpStart scripts!
#
# If you set this, the rc3.d/S99jumpstart script will be disabled
# (set to rc3.d/s99jumpstart) every time it is processed - this allows you
# to run it by hand and invoke each reboot step
# This does not work on Solaris 10.
#
base_config_debug_jumpstart_postinstall=""

#
###############################################################################

== Other JET configurations ==

=== JET Sparc_DHCP ===

> I now want to configure JET for a basic sparc DHCP and bootp build.
>
> For Sparc DHCP do I just need to make the following changes…
>
> Create a template with the
> base_config_client_allocation equal "dhcp"
>
yep
> edit /opt/SUNWjet/etc/Jumpstart.conf to add uname –i
> to JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30" to
> reflect my wanting to use SPARC & DHCP.
>
yep
> And I assume make_client will create the appropriate
> settings in dhcpmgr etc.
>
uh huh
> Anything else ?
>

=== JET Sparc_Bootp ===

> For Sparc bootp do I just need to create a template
> with the base_config_client_allocation equal "bootp"
>
yep

> And I assume make_client will create the appropriate
> settings in tftpboot etc.
>
uh huh

> I will not be able to test this for a week or so, as
> so far all my testing has been done using Vmware
> locally on my laptop.

=== Changing the media location ===
>
> And finally I will in the future want to change my
> media location from /export/install to
> /export/jumpstart/s10i & /export/jumpstart/s10sparc
> etc.
>
> I guess I will need to update my “solaris locations”
> will I need to make JS_SOLARIS_DIR=/export/jumpstart
> in jumpstart.conf ? anything else ?
>
Only thing that matters is the solaris media locations. The
JS_SOLARIS_DIR only affects the location of the media when you use the
JET copy_solaris_media command, otherwise it is immaterial. In other
words, once your /opt/SUNWjet/etc/solaris_media_locations file is
vaild, everthing should be hunky dory.

JetWalkthrough

2006-08-29T13:04:20Z

Marty:

== JET install and Configuration to server DHCP / PXE intel clients ==

Contributor: Paul Juster

== Overview of my set up ==

I am using two Intel machines, my JumpStart server is ''sun1'' (192.168.0.250) and my JumpStart client ''vmclient'' needs to end up with a static IP 192.168.0.200 (a flat network). Operating system is Solaris 10 x86.

On the JumpStart server I have already copied the Intel x86 DVD files to my server
# /cdrom/cdrom0/Solaris_10/Tools/setup_install_server /export/installx86
the alternative is to use the jet script to do this (/opt/SUNWjet/bin/copy_solaris_media).

In this example I am using JET 4.3 and I have only displayed lines in files that I changed from the default or that I want to make clear what the setting is.

Do not assume any of the below applied to a SPARC JET client

== Download and Install the packages SUNWjet & documentation packages ==

Get JET from the Sun download centre (http://www.sun.com/downloads)

# bunzip2 jet.pkg.bz2
# pkgadd -d jet.pkg
select Packages 10 & 11

== JET Folder structure ==

I created/used the following folders

/export/pkgs (not used but needed)
/export/patches (not used but needed)
/export/installx86 (Where the media has been copied too)

Note this is a simple configuration be in a larger setup /export/media should be used with sub folders for each media type.

== JET NFS shares ==

The following shares were created to support JET.

("JET framework" share was automatically created during the package install)
# share
- /opt/SUNWjet ro,anon=0 "JET Framework"
- /export/pkgs ro,anon=0 "Jumpstart Media"
- /export/installx86 ro,anon=0 "Jumpstart Media"
- /export/patches ro,anon=0 "Jumpstart Media"

== Modify JET configuration ==

I edited /opt/SUNWjet/etc/jumpstart.conf to reflect my JET folder structure.

#
# This config file defines the jumpstart specific variables.
#
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export

== Adding Solaris Location ==

A “Solaris location” is a pointer to a folder containing the solaris installation media that has been copied to the JumpStart/JET server.
The Solaris media is copied to the JET server in two ways

a. /cdrom/cdrom0/Solaris_10/Tools/setup_install_server
b. /opt/SUNWjet/bin/copy_solaris_media

a. is the traditional JumpStart method (I used), b. is the JET method.

Once copied a “Solaris location” is needed for JET to reference and use, this is done by running

# /opt/SUNWjet/bin/add_solaris_location 10i /export/installx86

== A “template” ==

A JET template outlines a JET clients configuration/installation and contains the answers to the installation questions that are normally asked (this is a very simplistic view as a lot more can be accomplish with the template). I created a template called vmclient

# /opt/SUNWjet/bin/make_template vmclient

== Customise the template (DHCP/PXE) ==

Once the template has been created some basic details needed to be added.

(I made the following changes and ignored all other lines at the moment)
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i
base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254
base_config_client_allocation="grub"

Its worth noting that intel machine can only be built using JET/JumpStart by using DHCP and PXE boot methods, in order for this to be configured within JET following line partly configures this.

base_config_client_allocation="grub"

== DHCP server setup ==

In order for JET to support DHCP clients, the server needs some basic details to be added to /opt/SUNWjet/Products/base_config/solaris/make_dhcp file

# cat make_dhcp
################################################################################
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is not present, then activate it
#
# Change the NETWORK details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

In order for these changes to be applied to the solaris dhcp server, permissions on the make_dhcp file need to be changed so the file can be executed.

# chmod +x make_dhcp
# ./make_dhcp
Created DHCP configuration file.
Created dhcptab.
Added "Locale" macro to dhcptab.
Added server macro to dhcptab - sun1.
DHCP server started.
Added network macro to dhcptab - 192.168.0.0.
Created network table.

As you can see this has populated/configured the dhcp server with the basic settings, the client specific settings are added when make_client is run.

== Populating JET with a client ==

A client can now be added to the JET server using the make_client script.

# /opt/SUNWjet/bin/make_client -f vmclient
Gathering network information..
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Solaris: client_prevalidate
Clean up /etc/ethers
Solaris: client_build
Creating sysidcfg
Creating profile
Adding base_config specifics to client configuration
Solaris: Configuring JumpStart boot for vmclient
Starting SMF services for JumpStart
Solaris: Configure PXE/grub build
Adding install client
Doing a TEXT based install
Leaving the graphical device as the primary console
Configuring vmclient macro
Using local dhcp server
PXE/grub configuration complete
Running '/opt/SUNWjet/bin/check_client vmclient'
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Checking product base_config/solaris
Checking Solaris boot image for critical patches (this may take a while..)

WARNING: Patch 119375-03 has not been applied to the boot image.
This patch has been critical to the successful
installation of the O/S.

Please apply the patch with the command:

# patchadd -C /export/installx86/Solaris_10/Tools/Boot 119375-03

--------------------------------------------------------------
Check of client vmclient
-> Passed....

The obvious thing from this output is that it passed, but also you can see that a PXE/Grub build took place (which means that this client is an intel client)

== Client boot ==

The intelx86 client needs booting off the network, F12 is the normal key at boot time.

The intelx86 client gets an ip address

The grub loader is loaded

The grub loader load the multi boot image from the /tftpboot directory and hopefully now installation windows/questions will be asked.

== Reference files ==

=== jumpstart.conf ===

# This config file defines the jumpstart specific variables.
#
# Version: $Revision: 1.5 $
# Last Updated; $Date: 2006/02/04 12:08:58 $
#
# Location of the additional media for patches and packages:
#
# These paths should be URI form e.g. nfs://<serverip>/<path> or <path>
# Currently only PKG_DIR and PATCH_DIR can be on a remote NFS server.
# If they are just <path>, the appropriate address of the JumpStart server
# will be added.
#
# N.B. if the media location is on a different server, please ensure it is
# routable from the client !
#
JS_Default_Root_PW=boajrOmU7GFmY
JS_BUILD_DIR=/var/opt/sun/jet
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export
JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30"
#JS_CLIENT_MANAGEMENT="dhcp bootp"
JS_CLIENT_MANAGEMENT="bootp"

=== make_dhcp ===
#!/usr/bin/ksh
#
# This config file defines the dhcp variables.
#
# Copyright 2005 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
################################################################################
#
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is notpresent, then activate it
#
# Change the NETWORk details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}

=== template/vmclient ===
###############################################################################
#
# Client template file
#
# Client: vmclient
# Created: Friday May 19 19:26:39 BST 2006
#
# This file was automatically generated using 'make_template'
###############################################################################

###############################################################################
#
# Product: base_config
#
# Synopsys: Basic host information
#
###############################################################################

############
#
# Architecture type:
# sun4c : e.g. SS1, SS2, SS IPX
# sun4d : e.g. SS1000, SS2000
# sun4e : ?
# sun4m : e.g. SS LX, SS4, SS5, SS10, SS20
# sun4u : UltraSparc - U1, U2, E3x00, E4x00 etc
# sun4u1 : E10K
# sun4v : T2000
#
# i86pc : Intel X86
#
# Ethernet can be obtained from the 'banner' command at OBP
#
# OS is one of the values you used to register the solaris media using
# the add_solaris_location command
#
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i

############
#
# Client allocation
#
# The mechanism used to build this client; by default, the options listed
# in /opt/jet/etc/jumpstart.conf will be tried; you should only set this
# if this particular client needs to do something different.
# JET supports bootp, dhcp, and grub as allocation options.
# Currently grub is only supported on i86pc architectures.
#
base_config_client_allocation="grub"

# If you are using grub, you can set this variable to apply additional
# grub directives to the menu.lst.<MACADDRESS> file.
#
base_config_grub_append=""

############
#
# products is the set of products to install after base_config; this
# should be updated automatically by make_template, so you
# will only need to change it, if you wish to omit certain
# modules when testing/debugging.
#
base_config_products=""

############
#
# JumpStart sysidcfg information
#
# The sysidcfg file provides information at initial boot time so that the
# system can properly identify itself. The interface and ip address defined
# here MUST be on the same subnet as the JumpStart server. The root password
# is set here also and must be written in encrypted format. The default value
# shown here is "newroot". The timeserver is normally the IP address of the
# JumpStart server.
#
# nameservice examples:
# NONE
# NIS { domain_name=uk.sun.com name_server=nis.uk.sun.com(129.159.91.1) }
# or for DNS
# DNS { domain_name=uk.sun.com name_server=192.168.1.1 search=uk.sun.com }
#
# network_interface:
# le0, hme0
# or PRIMARY (the default interface - net in OBP)
# N.B. PRIMARY is only valid from Solaris 7 upwards
#
# locale:
# en_UK for Solaris 2.6
# en_GB for Solaris 7 and above
#
# timeserver: Where the client gets the current time from.
# Leave blank to default the the JumpStart server
#
# Alternatively, set to 'localhost' to trust the current
# hardware clock on the client
#
# terminal: terminal type (vt100/vt220/sun etc)
#
# security_policy: Kerberos policy (Solaris 8 +)
#
# protocol_ipv6: Use ipv6 or not (Solaris 8 +)
#
# default_route: Solaris 9 allows a default route to be set
# (ignored on all other versions of Solaris, less than 9)
#

base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254

########################################
# X86, X64 specific settings. If this is an x86 client, then you may need
# to configure these settings. They are ignored for SPARC builds.
#
# base_config_x86_nowin:
# This stops Solaris from trying to run windows during the install.
# the default value is yes.
#
# base_config_x86_console:
# Set the console to the correct tty port. This is used for doing installs
# via the serial port or the SP. b1600,v20z and v40z use ttya. lx50, v60x,
# and v65x use ttyb. NOTE: you only need to set this if you are NOT going
# to connect a keyboard and monitor to the client.
#
# base_config_x86_disable_acpi:
# Disable ACPI - sometimes disabling ACPI makes the install go
# better due to how the interrupts are handled. Non-Null disables ACPI.
#
# base_config_x86_safetoreboot:
# The Solaris installer can't control the BIOS, therefore does not
# know if its safe to reboot the client as it may simply jumpstart
# again. If your PXE boot is a one time option, and the next reboot
# will attempt to boot from disk, then you probably want to set this
# option to "yes". Otherwise, leave it as it is so that it won't reboot
# and therefore allow you to manually change your BIOS to boot from disk.
#
# base_config_x86_disable_kdmconfig:
# X86 systems sometimes go interactive on the first reboot (Bug 6321043)
# on Solaris 10 Update 1. Setting this parameter will stop this from
# happenning.
#
# base_config_x86_confflags
# The parameters specified for this variable are passed directly to
# add_install_client -b confflags= option.
# For e.g., by specifying,
# base_config_x86_confflags="-f -P/boot/solaris/dca"
#
# add_install_client is called with -b confflag="-f -P /boot/solaris/dca"
# option.
#
# base_config_sysidcfg_x86_kdmfile
# Append the file specified here to sysidcfg file.
# This variable can reference a file relative to the
# Clients/<clientname> directory or a absolute path.
#
#
base_config_x86_nowin="yes"
base_config_x86_console=""
base_config_x86_disable_acpi=""
base_config_x86_safetoreboot=""
base_config_x86_disable_kdmconfig=""
base_config_x86_confflags=""
base_config_sysidcfg_x86_kdmfile=""

#
#
#
#
#######

#
# Want to create your own custom profile ? if so, use this variable to
# reference a file relative to the Clients/<clientname> directory or
# absolute path, otherwise fill in the other details below to get toolkit
# to create one for you.
#
# If absolute path is specified, then the profile file is copied
# to Clients/<clientname> directory.
#
base_config_profile=""
#
#######
# OR fill out the base_config_profile variables below.
############
#
# JumpStart profile information
#
#
# A limited profile can be automatically generated here. If further
# customisation is required, then you can manually create a profile in the
# client directory and reference it in the base_config_profile variable.
#
# Cluster:
# SUNWCrnet : Minimal. Solaris 10 only
# SUNWCreq : Required - really basic, good for testing
# SUNWCuser : User collection
# SUNWCprog : User + Developers collection
# SUNWCall : All packages
# SUNWCXall : All + OEM packages (mandatory for E10K)
#
# usedisk: defines the disk that the OS will be loaded on to - bootdisk
# (if this is set to rootdisk. , then the current boot disk will
# be used)
#
# dontuse: defines disks that should not be used..
# ** N.B. This will only be used if 'usedisk' is NOT set
# Space seperated list of disks of the form c?t?d?
#
# partition sizes:
#
# if partitions are not required simply leave blank. In order to maintain
# consistency the partitions will always use the same slice number:
#
# / s0
# swap s1
#
# We've prepopulated the remaining slices based on Sun defaults,
# but you can change this.
# /var s5
# /usr s6
# /opt s7
#
# at most one partition can have the size 'free' which denotes all the
# unallocated/spare space on a disk.
#
base_config_profile_cluster=SUNWCXall
base_config_profile_usedisk=rootdisk.

base_config_profile_dontuse=""

base_config_profile_root=free
base_config_profile_swap=256

#
# If you are using VxVM and want your boot disk to look like the mirror, then
# leave slices 3 and 4 empty. If you do not care about keeping the two disks
# looking cosmetically the same, please just make sure you have two free slices
# somewhere on the disk for VxVM!
#
# If you are not using VxVM, then you can use s3 and s4 for whatever you wish!
#

base_config_profile_s3_mtpt=""
base_config_profile_s3_size=""

base_config_profile_s4_mtpt=""
base_config_profile_s4_size=""

base_config_profile_s5_mtpt="/var"
base_config_profile_s5_size=""

base_config_profile_s6_mtpt="/usr"
base_config_profile_s6_size=""

#
# If you are using DiskSuite, the default behaviour is to use slice 7 as a
# location for metastate databases. If you are using DiskSuites default config,
# please avoid using s7 for data!
#

base_config_profile_s7_mtpt="/opt"
base_config_profile_s7_size=""
#
############

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

############
#
# Additional locales/geos e.g. N_Europe, C_Europe
#
#
base_config_profile_add_locales=""
base_config_profile_del_locales=""

base_config_profile_add_geos=""
base_config_profile_del_geos=""

############
#
# UFS Logging
#
# Solaris 7 and above support UFS+, which allows for a logging filesystem
# under UFS. If you want to use this feature on any of the UFS mount points,
# please specify the mount points here, as a space seperated list, or enter
# the keyword "all" to enable logging on all UFS filesystems.
#
# Solaris 9 09/04 enables logging by default. You can also specify mountpoints
# preceded by a - sign to say that you DON'T want logging enabled on that
# filesystem, or you can use the keyword "none" to say you don't want any
# ufs logging turned on at all.
#
# N.B. root (/) can be included in the list, and is included by default if
# using either the "all" or "none" keyword.
#
# Finally, you can't mix keywords and mountpoints. i.e. "all -/" is NOT
# valid.
# e.g. base_config_ufs_logging_filesys="all" : log all filesystems
# base_config_ufs_logging_filesys="none" : log no filesystems
# base_config_ufs_logging_filesys="-/ /var -/usr" : log /var, but not / and /usr.
#
base_config_ufs_logging_filesys="all"

############
#
# Packages to add to/remove from the selected cluster
#
# Use this to populate the profile with package <pkg> <add|delete> entries
#
base_config_profile_add_packages=""
base_config_profile_del_packages=""

############
#
# Clusters to add to/remove
#
# Use this to populate the profile with cluster <cluster> <add|delete> entries
#
base_config_profile_add_clusters=""
base_config_profile_del_clusters="SUNWCpm SUNWCpmx SUNWCdial SUNWCdialx"

############
#
# Remote file systems (NFS)
#
# Specify these as space seperated list of pairs as follows, using ? as
# the seperator (as : has special meanings with nfs!)
#
# e.g. to mount 1.1.1.1:/fs on /fs you would create the entry
# base_config_nfs_mounts="fs?1.1.1.1:/fs"
#
base_config_nfs_mounts=""

############
#
# Host information
#
# This section defines most things network related etc.
#
# In addtion, if the machine will be JumpStarted as one name/address and
# needs to have a different name/address once installed, this is where you
# can set that information.
#
# nodename: the value for /etc/nodename if it's not the default
# hostname
#
# defaultrouter: the value for /etc/defaultrouter.
#
# notrouter: if this is set, the file /etc/notrouter will be created
#
# dns_domain: domain entry for /etc/resolv.conf
#
# dns_nameservers: nameserver entries for /etc/resolv.conf
# (list of ip addresses, space separated)
#
# dns_searchpath: list of entries to go in the search line
#
# dns_disableforbuild: If there is no DNS available in the build
# environment, set this to delay the configuration
# of DNS until later on.
#

base_config_nodename=""
base_config_defaultrouter=""
base_config_notrouter=""

base_config_dns_domain=""
base_config_dns_nameservers=""
base_config_dns_searchpath=""

base_config_dns_disableforbuild="yes"

###########
#
# NTP configuration
#
# Specify a list of names or ip addresses for the NTP servers. The first
# one will be given a 'prefer' tag. This section will only place lines
# of the form: server <ipaddress/name> [prefer]
# into the /etc/inet/ntp.conf file. If you require more control of ntp,
# please use the custom module to deploy your own custom ntp.conf file.
#
# N.B. If you do use names, they must be resolvable in your name service.
#
base_config_ntp_servers=""

############
#
# Network Interface information
#
#
# networkifs: a list of interfaces to be defined,
# space seperated "le0 hme0".
# N.B. the sysidcfg interface will already be configured
#
# Logical interfaces should be defined using _'s rather
# than :'s.
#
# networkif_<ifname>: the details of the interface <if>
# "netname netmask hostname address"
#
# netname: arbritrary name for /etc/networks
# netmask: netmask of this if (e.g. 255.255.255.0)
# hostname: unique hostname (N.B. not multihomed)
# address: IP address of this interface
#
# For example:
#
# base_config_networkifs="ge0 ge0_1"
# base_config_networkif_ge0="bkp 255.255.255.0 me-bkp 192.168.1.0"
# base_config_networkif_ge0_1="bkp2 255.255.255.0 me-bkp2 192.168.2.0"
#

base_config_networkifs=""
base_config_networkif_le0=""

# N.B. Logical interfaces MUST use _ rather than : as illustrated below
base_config_networkif_le0_1=""

############
#
# IP Multipathing (Solaris 8+)
#
# IPMP default mode is automatic failback.
# To change this mode edit /etc/default/mpathd
#
# ipmp_networkifs: a list of interfaces to be defined under ipmp control
# a space separated list of pairs only
# e.g. "qfe0_qfe4 qfe1_qfe5"
#
# N.B. If the primary interface is used in an ipmp group, the
# system must be rebooted manually after installation to
# activate ipmp.
#
# N.B. Can only setup ipmp group with pairs of interfaces in one
# of the following configurations:
# active-standby failover:
# Set ipmp mode = s, and specify one logical
# hostname/ip address pair.
# failover with outbound load spreading:
# Set ipmp mode = l, and specify one logical
# hostname/ip address pair.
# active-active with outbound load spreading:
# Set ipmp mode = l, specify a second logical
# hostname/ip address pair for the second interface.
#
# ipmp_networkif_<if>_<if>: "netgroup mode test1 test2 mask hostname log-ip hostname2 log-ip2"
#
# details of the interfaces in the ipmp group
# e.g. networkif_ipmp_qfe0_qfe4
#
#
# netgroup: ipmp interface group name
# e.g. database-net
#
# ipmp mode: s = standby (failover only)
#
# ** test addresses are allocated last,
# ** first test address will be on the
# ** first virtual interface of the
# ** first physical adapter. Second
# ** test address will be on the second
# ** physical adapter.
#
# l = load spreading / active-active
#
# ** test addresses are allocated on
# ** first virtual interfaces on both
# ** the first and second physical
# ** adapters.
#
# To force the test addresses onto the physical
# adapters, use the suffix 'p' to the above
# modes, i.e. 'sp' or 'lp'. This is not
# recommended and may break certain applications.
#
# test1: ipmp test address1
# test2: ipmp test address2
#
# N.B. these addresses must not be used or
# placed in the hosts file
#
# mask: netmask for ipmp pair
#
# hostname: unique hostname for logical ip
#
# log-ip: logical ip address for first i/f of pair
#
# N.B. The following two parameters are for active-active
# configurations only. Do not specify them for an
# active-standby configuration.
#
# hostname2: unique hostname for logical ip
#
# log-ip2: logical ip address for second i/f
# of pair
# IPMP on Solaris 10.
# If you are running Solaris 10, you can optionally configure the
# system to have NO test addresses. In this case, the ipmp mode should be set
# to "ln" or "sn" depending on whether you want outbound load spreading or
# not and the 2 test addresses do not need to be privided.
#
# Examples:
# --------
#
#
# base_config_ipmp_networkifs="qfe0_qfe1"
# Outbound load spreading 2 hostnames, test on virtual interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db l 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3 apache 10.0.0.4"
# Outbound load spreading 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db lp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db sp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, no test addresses (Sol 10 only).
# base_config_ipmp_networkif_qfe0_qfe1="db sn 24 oracle-db 10.0.0.3"
#
#
base_config_ipmp_networkifs=""
base_config_ipmp_networkif_qfe0_qfe1=""

############
#
# Misc options
#
# this section is a catchall for other options not included above
#
# update_terminal: if set, put the sysidcfg terminal type into inittab
#
# enable_savecore: if set to any value, enable save core (Solaris 2.6 only)
#
# dumpadm_minfree: set a limit so that crash dumps don't fill up the
# dump filesystem. See dumpadm(1M) -m option for
# possible values.
#
# noautoshutdown: if set to any value, disable power management
#
# enable_rootlogin: if set to any value, enable network root login
# from both telnet/rsh and ssh
#
# enable_rootftp: if set to any value, enable root ftp access
#
# shutup_sendmail: if set, create an alias hostname. to shut up sendmail
#
# poweroff_afterbuild: if set, shut the machine down once it has been built
#
# base_config_dedicated_dump_device:
# if set, dumpadm will configure the partition as a
# Dedicated Dump Device. See dumpadm(1M) for supported
# Operating Environments.
# (Device path e.g. /dev/dsk/c?t?d?s?)
#
# N.B. This partition is for the SOLE use of the crashdump utility !
#
# enable_altbreak: if set, enable alternate break sequence
#
# disable_sysid_probe: if set, skip the sysid stuff on the first reboot; this
# usually just tries to rarp ip addresses for additional
# interfaces and takes *ages* on machines with lots
# of unused network adapters.
#
#

base_config_update_terminal="yes"
base_config_enable_savecore="yes"
base_config_dumpadm_minfree="20000k"
base_config_noautoshutdown="pm_disabled"
base_config_enable_rootlogin=""
base_config_enable_rootftp=""
base_config_shutup_sendmail=""
base_config_poweroff_afterbuild=""
base_config_dedicated_dump_device=""
base_config_enable_altbreak=""
base_config_disable_sysid_probe=""

############
#
# NFSv4
#
# Set up the NFSv4 domain to prevent being prompted at first reboot.
# If not set, this will default to the entry in base_config_dns_domain,
# and if that is not set, to the value 'domain', which is the default
# in /etc/default/nfs
#
base_config_nfsv4_domain=""

############
#
# N.B. Unless you need to point this client at alternate media for patches
# and packages that is not held on this server, please skip this section!
#
# productdir is where to find the products. This should be a URI style
# path, i.e. nfs://192.168.1.1/export/install/pkgs. If the server
# is the JumpStart server, then it should just be specified
# as a normal path.
#
# patchdir is where to find the patches. Same format as productdir.
#
# --------------------------------------------------------------------------
# Leaving the following blank means they will be populated using jumpstart.conf
# and the JumpStart servers ip address. This is the default behaviour
# and should only be changed if your patch/package repository is not held
# on this server.
# --------------------------------------------------------------------------

base_config_productdir=""
base_config_patchdir=""

#
# Last one - mainly for developing JumpStart scripts!
#
# If you set this, the rc3.d/S99jumpstart script will be disabled
# (set to rc3.d/s99jumpstart) every time it is processed - this allows you
# to run it by hand and invoke each reboot step
# This does not work on Solaris 10.
#
base_config_debug_jumpstart_postinstall=""

#
###############################################################################

@@@Other JET configurations@@@

14. JET Sparc_DHCP
> I now want to configure JET for a basic sparc DHCP and
> bootp build.
>
> For Sparc DHCP do I just need to make the following
> changes…
>
> Create a template with the
> base_config_client_allocation equal "dhcp"
>
yep
> edit /opt/SUNWjet/etc/Jumpstart.conf to add uname –i
> to JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30" to
> reflect my wanting to use SPARC & DHCP.
>
yep
> And I assume make_client will create the appropriate
> settings in dhcpmgr etc.
>
uh huh
> Anything else ?
>
15. JET Sparc_Bootp

> For Sparc bootp do I just need to create a template
> with the base_config_client_allocation equal "bootp"
>
yep

> And I assume make_client will create the appropriate
> settings in tftpboot etc.
>
uh huh

> I will not be able to test this for a week or so, as
> so far all my testing has been done using Vmware
> locally on my laptop.

16. Changing the media location
>
> And finally I will in the future want to change my
> media location from /export/install to
> /export/jumpstart/s10i & /export/jumpstart/s10sparc
> etc.
>
> I guess I will need to update my “solaris locations”
> will I need to make JS_SOLARIS_DIR=/export/jumpstart
> in jumpstart.conf ? anything else ?
>
Only thing that matters is the solaris media locations. The
JS_SOLARIS_DIR only affects the location of the media when you use the
JET copy_solaris_media command, otherwise it is immaterial. In other
words, once your /opt/SUNWjet/etc/solaris_media_locations file is
vaild,
everthing should be hunky dory.

JetWalkthrough

2006-08-29T12:57:19Z

Marty:

== JET install and Configuration to server DHCP / PXE intel clients ==

Contributor: Paul Juster

=== Overview of my set up ===

I am using two Intel machines, my JumpStart server is ''sun1'' (192.168.0.250) and my JumpStart client ''vmclient'' needs to end up with a static IP 192.168.0.200 (a flat network). Operating system is Solaris 10 x86.

On the JumpStart server I have already copied the Intel x86 DVD files to my server
# /cdrom/cdrom0/Solaris_10/Tools/setup_install_server /export/installx86
the alternative is to use the jet script to do this (/opt/SUNWjet/bin/copy_solaris_media).

In this example I am using JET 4.3 and I have only displayed lines in files that I changed from the default or that I want to make clear what the setting is.

Do not assume any of the below applied to a SPARC JET client

=== Download and Install the packages SUNWjet & documentation packages ===

Get JET from the Sun download centre (http://www.sun.com/downloads)

# bunzip2 jet.pkg.bz2
# pkgadd -d jet.pkg
select Packages 10 & 11

=== JET Folder structure ===

I created/used the following folders

/export/pkgs (not used but needed)
/export/patches (not used but needed)
/export/installx86 (Where the media has been copied too)

Note this is a simple configuration be in a larger setup /export/media should be used with sub folders for each media type.

=== JET NFS shares ===

The following shares were created to support JET.

("JET framework" share was automatically created during the package install)
# share
- /opt/SUNWjet ro,anon=0 "JET Framework"
- /export/pkgs ro,anon=0 "Jumpstart Media"
- /export/installx86 ro,anon=0 "Jumpstart Media"
- /export/patches ro,anon=0 "Jumpstart Media"

=== Modify JET configuration ===

I edited /opt/SUNWjet/etc/jumpstart.conf to reflect my JET folder structure.

#
# This config file defines the jumpstart specific variables.
#
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export

=== Adding Solaris Location ===

A “Solaris location” is a pointer to a folder containing the solaris installation media that has been copied to the JumpStart/JET server.
The Solaris media is copied to the JET server in two ways

a. /cdrom/cdrom0/Solaris_10/Tools/setup_install_server
b. /opt/SUNWjet/bin/copy_solaris_media

a. is the traditional JumpStart method (I used), b. is the JET method.

Once copied a “Solaris location” is needed for JET to reference and use, this is done by running

# /opt/SUNWjet/bin/add_solaris_location 10i /export/installx86

6. A “template”

A JET template outlines a JET clients configuration/installation and contains the answers to the installation questions that are normally asked (this is a very simplistic view as a lot more can be accomplish with the template). I created a template called vmclient

# /opt/SUNWjet/bin/make_template vmclient

7. Customise the template (DHCP/PXE)
Once the template has been created some basic details needed to be added.

(I made the following changes and ignored all other lines at the moment)
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i
base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254
base_config_client_allocation="grub"

Its worth noting that intel machine can only be built using JET/Jumpstart by using DHCP and PXE boot methods, in order for this to be configured within JET following line partly configures this.

base_config_client_allocation="grub"

8. DHCP server setup
In order for JET to support an intel DHCP the DHCP server needs some basic details need to be added to /opt/SUNWjet/Products/base_config/solaris/make_dhcp file
# cat make_dhcp
################################################################################
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is not present, then activate it
#
# Change the NETWORK details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}
#

in order for these changes to be applied to the solaris dhcp server, permissions on the mae_dhcp file need to be changed so the file can be executed.

# ./make_dhcp
Created DHCP configuration file.
Created dhcptab.
Added "Locale" macro to dhcptab.
Added server macro to dhcptab - sun1.
DHCP server started.
Added network macro to dhcptab - 192.168.0.0.
Created network table.

As you can see this has populated/configured the dhcp server with the basic settings, the client specific settings are added when make_client is run.

9. Populating JET with a client
A client can now be added to the JET server using the make_client script.

# /opt/SUNWjet/bin/make_client -f vmclient
Gathering network information..
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Solaris: client_prevalidate
Clean up /etc/ethers
Solaris: client_build
Creating sysidcfg
Creating profile
Adding base_config specifics to client configuration
Solaris: Configuring JumpStart boot for vmclient
Starting SMF services for JumpStart
Solaris: Configure PXE/grub build
Adding install client
Doing a TEXT based install
Leaving the graphical device as the primary console
Configuring vmclient macro
Using local dhcp server
PXE/grub configuration complete
Running '/opt/SUNWjet/bin/check_client vmclient'
Client: 192.168.0.200 (192.168.0.0/255.255.255.0)
Server: 192.168.0.250 (192.168.0.0/255.255.255.0, SunOS)
Checking product base_config/solaris
Checking Solaris boot image for critical patches (this may take a while..)

WARNING: Patch 119375-03 has not been applied to the boot image.
This patch has been critical to the successful
installation of the O/S.

Please apply the patch with the command:

# patchadd -C /export/installx86/Solaris_10/Tools/Boot 119375-03

--------------------------------------------------------------
Check of client vmclient
-> Passed....

The obvious thing from this output is that it passed, but also you can see that a PXE/Grub build took place (which means that this client is an intel client)
10. Client boot.

The intelx86 client needs booting off the network, F12 is the normal key at boot time.

The intelx86 client gets an ip address

The grub loader is loaded

The grub loader load the multi boot image from the /tftpboot directory

and hopefully now installation windows/questions will be asked.

Reference files

11. Jumpstart.Conf
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# This config file defines the jumpstart specific variables.
#
# Version: $Revision: 1.5 $
# Last Updated; $Date: 2006/02/04 12:08:58 $
#
# Location of the additional media for patches and packages:
#
# These paths should be URI form e.g. nfs://<serverip>/<path> or <path>
# Currently only PKG_DIR and PATCH_DIR can be on a remote NFS server.
# If they are just <path>, the appropriate address of the JumpStart server
# will be added.
#
# N.B. if the media location is on a different server, please ensure it is
# routable from the client !
#
JS_Default_Root_PW=boajrOmU7GFmY
JS_BUILD_DIR=/var/opt/sun/jet
JS_PKG_DIR=/export/pkgs
JS_PATCH_DIR=/export/patches
JS_SOLARIS_DIR=/export
JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30"
#JS_CLIENT_MANAGEMENT="dhcp bootp"
JS_CLIENT_MANAGEMENT="bootp"

12. make_dhcp
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
make_dhcp # This config file defines the dhcp variables.
#!/usr/bin/ksh
#
# Copyright 2005 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
################################################################################
#
# Synopsis: PXE boot pre-JUMP setups
# if DHCP server is notpresent, then activate it
#
# Change the NETWORk details to suit your own
NETWORK=192.168.0.0
NETMASK=255.255.255.0
ROUTER=192.168.0.254

dhcpconfig -D -r SUNWfiles -p /var/tmp

dhcpconfig -N ${NETWORK} -m ${NETMASK} -t ${ROUTER}
#

13. template/vmclient
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
###############################################################################
#
# Client template file
#
# Client: vmclient
# Created: Friday May 19 19:26:39 BST 2006
#
# This file was automatically generated using 'make_template'
###############################################################################

###############################################################################
#
# Product: base_config
#
# Synopsys: Basic host information
#
###############################################################################

############
#
# Architecture type:
# sun4c : e.g. SS1, SS2, SS IPX
# sun4d : e.g. SS1000, SS2000
# sun4e : ?
# sun4m : e.g. SS LX, SS4, SS5, SS10, SS20
# sun4u : UltraSparc - U1, U2, E3x00, E4x00 etc
# sun4u1 : E10K
# sun4v : T2000
#
# i86pc : Intel X86
#
# Ethernet can be obtained from the 'banner' command at OBP
#
# OS is one of the values you used to register the solaris media using
# the add_solaris_location command
#
base_config_ClientArch=i86pc
base_config_ClientEther=00:0c:29:76:fd:15
base_config_ClientOS=10i

############
#
# Client allocation
#
# The mechanism used to build this client; by default, the options listed
# in /opt/jet/etc/jumpstart.conf will be tried; you should only set this
# if this particular client needs to do something different.
# JET supports bootp, dhcp, and grub as allocation options.
# Currently grub is only supported on i86pc architectures.
#
base_config_client_allocation="grub"

# If you are using grub, you can set this variable to apply additional
# grub directives to the menu.lst.<MACADDRESS> file.
#
base_config_grub_append=""

############
#
# products is the set of products to install after base_config; this
# should be updated automatically by make_template, so you
# will only need to change it, if you wish to omit certain
# modules when testing/debugging.
#
base_config_products=""

############
#
# JumpStart sysidcfg information
#
# The sysidcfg file provides information at initial boot time so that the
# system can properly identify itself. The interface and ip address defined
# here MUST be on the same subnet as the JumpStart server. The root password
# is set here also and must be written in encrypted format. The default value
# shown here is "newroot". The timeserver is normally the IP address of the
# JumpStart server.
#
# nameservice examples:
# NONE
# NIS { domain_name=uk.sun.com name_server=nis.uk.sun.com(129.159.91.1) }
# or for DNS
# DNS { domain_name=uk.sun.com name_server=192.168.1.1 search=uk.sun.com }
#
# network_interface:
# le0, hme0
# or PRIMARY (the default interface - net in OBP)
# N.B. PRIMARY is only valid from Solaris 7 upwards
#
# locale:
# en_UK for Solaris 2.6
# en_GB for Solaris 7 and above
#
# timeserver: Where the client gets the current time from.
# Leave blank to default the the JumpStart server
#
# Alternatively, set to 'localhost' to trust the current
# hardware clock on the client
#
# terminal: terminal type (vt100/vt220/sun etc)
#
# security_policy: Kerberos policy (Solaris 8 +)
#
# protocol_ipv6: Use ipv6 or not (Solaris 8 +)
#
# default_route: Solaris 9 allows a default route to be set
# (ignored on all other versions of Solaris, less than 9)
#

base_config_sysidcfg_nameservice=NONE
base_config_sysidcfg_network_interface=PRIMARY
base_config_sysidcfg_ip_address=192.168.0.200
base_config_sysidcfg_netmask=255.255.255.0
base_config_sysidcfg_root_password="boajrOmU7GFmY"
base_config_sysidcfg_system_locale=en_GB.ISO8859-1
base_config_sysidcfg_timeserver=localhost
base_config_sysidcfg_timezone="GB"
base_config_sysidcfg_terminal=vt100
base_config_sysidcfg_security_policy=NONE
base_config_sysidcfg_protocol_ipv6=no
base_config_sysidcfg_default_route=192.168.0.254

########################################
# X86, X64 specific settings. If this is an x86 client, then you may need
# to configure these settings. They are ignored for SPARC builds.
#
# base_config_x86_nowin:
# This stops Solaris from trying to run windows during the install.
# the default value is yes.
#
# base_config_x86_console:
# Set the console to the correct tty port. This is used for doing installs
# via the serial port or the SP. b1600,v20z and v40z use ttya. lx50, v60x,
# and v65x use ttyb. NOTE: you only need to set this if you are NOT going
# to connect a keyboard and monitor to the client.
#
# base_config_x86_disable_acpi:
# Disable ACPI - sometimes disabling ACPI makes the install go
# better due to how the interrupts are handled. Non-Null disables ACPI.
#
# base_config_x86_safetoreboot:
# The Solaris installer can't control the BIOS, therefore does not
# know if its safe to reboot the client as it may simply jumpstart
# again. If your PXE boot is a one time option, and the next reboot
# will attempt to boot from disk, then you probably want to set this
# option to "yes". Otherwise, leave it as it is so that it won't reboot
# and therefore allow you to manually change your BIOS to boot from disk.
#
# base_config_x86_disable_kdmconfig:
# X86 systems sometimes go interactive on the first reboot (Bug 6321043)
# on Solaris 10 Update 1. Setting this parameter will stop this from
# happenning.
#
# base_config_x86_confflags
# The parameters specified for this variable are passed directly to
# add_install_client -b confflags= option.
# For e.g., by specifying,
# base_config_x86_confflags="-f -P/boot/solaris/dca"
#
# add_install_client is called with -b confflag="-f -P /boot/solaris/dca"
# option.
#
# base_config_sysidcfg_x86_kdmfile
# Append the file specified here to sysidcfg file.
# This variable can reference a file relative to the
# Clients/<clientname> directory or a absolute path.
#
#
base_config_x86_nowin="yes"
base_config_x86_console=""
base_config_x86_disable_acpi=""
base_config_x86_safetoreboot=""
base_config_x86_disable_kdmconfig=""
base_config_x86_confflags=""
base_config_sysidcfg_x86_kdmfile=""

#
#
#
#
#######

#
# Want to create your own custom profile ? if so, use this variable to
# reference a file relative to the Clients/<clientname> directory or
# absolute path, otherwise fill in the other details below to get toolkit
# to create one for you.
#
# If absolute path is specified, then the profile file is copied
# to Clients/<clientname> directory.
#
base_config_profile=""
#
#######
# OR fill out the base_config_profile variables below.
############
#
# JumpStart profile information
#
#
# A limited profile can be automatically generated here. If further
# customisation is required, then you can manually create a profile in the
# client directory and reference it in the base_config_profile variable.
#
# Cluster:
# SUNWCrnet : Minimal. Solaris 10 only
# SUNWCreq : Required - really basic, good for testing
# SUNWCuser : User collection
# SUNWCprog : User + Developers collection
# SUNWCall : All packages
# SUNWCXall : All + OEM packages (mandatory for E10K)
#
# usedisk: defines the disk that the OS will be loaded on to - bootdisk
# (if this is set to rootdisk. , then the current boot disk will
# be used)
#
# dontuse: defines disks that should not be used..
# ** N.B. This will only be used if 'usedisk' is NOT set
# Space seperated list of disks of the form c?t?d?
#
# partition sizes:
#
# if partitions are not required simply leave blank. In order to maintain
# consistency the partitions will always use the same slice number:
#
# / s0
# swap s1
#
# We've prepopulated the remaining slices based on Sun defaults,
# but you can change this.
# /var s5
# /usr s6
# /opt s7
#
# at most one partition can have the size 'free' which denotes all the
# unallocated/spare space on a disk.
#
base_config_profile_cluster=SUNWCXall
base_config_profile_usedisk=rootdisk.

base_config_profile_dontuse=""

base_config_profile_root=free
base_config_profile_swap=256

#
# If you are using VxVM and want your boot disk to look like the mirror, then
# leave slices 3 and 4 empty. If you do not care about keeping the two disks
# looking cosmetically the same, please just make sure you have two free slices
# somewhere on the disk for VxVM!
#
# If you are not using VxVM, then you can use s3 and s4 for whatever you wish!
#

base_config_profile_s3_mtpt=""
base_config_profile_s3_size=""

base_config_profile_s4_mtpt=""
base_config_profile_s4_size=""

base_config_profile_s5_mtpt="/var"
base_config_profile_s5_size=""

base_config_profile_s6_mtpt="/usr"
base_config_profile_s6_size=""

#
# If you are using DiskSuite, the default behaviour is to use slice 7 as a
# location for metastate databases. If you are using DiskSuites default config,
# please avoid using s7 for data!
#

base_config_profile_s7_mtpt="/opt"
base_config_profile_s7_size=""
#
############

############
#
# You can specify additional disks to use/configure here
#
# additional_disks is a space separated list of c?t?d? type disk names
#
# For each disk listed in additional_disks, a pair of variables of the form
#
# base_config_profile_disk_c?t?d?s?_mtpt="...."
# base_config_profile_disk_c?t?d?s?_size="...."
#
# should be defined for each slice required on the disk.
#
# N.B. DO NOT SET THE BOOT DISK UP HERE !
#
base_config_profile_additional_disks=""

############
#
# Additional locales/geos e.g. N_Europe, C_Europe
#
#
base_config_profile_add_locales=""
base_config_profile_del_locales=""

base_config_profile_add_geos=""
base_config_profile_del_geos=""

############
#
# UFS Logging
#
# Solaris 7 and above support UFS+, which allows for a logging filesystem
# under UFS. If you want to use this feature on any of the UFS mount points,
# please specify the mount points here, as a space seperated list, or enter
# the keyword "all" to enable logging on all UFS filesystems.
#
# Solaris 9 09/04 enables logging by default. You can also specify mountpoints
# preceded by a - sign to say that you DON'T want logging enabled on that
# filesystem, or you can use the keyword "none" to say you don't want any
# ufs logging turned on at all.
#
# N.B. root (/) can be included in the list, and is included by default if
# using either the "all" or "none" keyword.
#
# Finally, you can't mix keywords and mountpoints. i.e. "all -/" is NOT
# valid.
# e.g. base_config_ufs_logging_filesys="all" : log all filesystems
# base_config_ufs_logging_filesys="none" : log no filesystems
# base_config_ufs_logging_filesys="-/ /var -/usr" : log /var, but not / and /usr.
#
base_config_ufs_logging_filesys="all"

############
#
# Packages to add to/remove from the selected cluster
#
# Use this to populate the profile with package <pkg> <add|delete> entries
#
base_config_profile_add_packages=""
base_config_profile_del_packages=""

############
#
# Clusters to add to/remove
#
# Use this to populate the profile with cluster <cluster> <add|delete> entries
#
base_config_profile_add_clusters=""
base_config_profile_del_clusters="SUNWCpm SUNWCpmx SUNWCdial SUNWCdialx"

############
#
# Remote file systems (NFS)
#
# Specify these as space seperated list of pairs as follows, using ? as
# the seperator (as : has special meanings with nfs!)
#
# e.g. to mount 1.1.1.1:/fs on /fs you would create the entry
# base_config_nfs_mounts="fs?1.1.1.1:/fs"
#
base_config_nfs_mounts=""

############
#
# Host information
#
# This section defines most things network related etc.
#
# In addtion, if the machine will be JumpStarted as one name/address and
# needs to have a different name/address once installed, this is where you
# can set that information.
#
# nodename: the value for /etc/nodename if it's not the default
# hostname
#
# defaultrouter: the value for /etc/defaultrouter.
#
# notrouter: if this is set, the file /etc/notrouter will be created
#
# dns_domain: domain entry for /etc/resolv.conf
#
# dns_nameservers: nameserver entries for /etc/resolv.conf
# (list of ip addresses, space separated)
#
# dns_searchpath: list of entries to go in the search line
#
# dns_disableforbuild: If there is no DNS available in the build
# environment, set this to delay the configuration
# of DNS until later on.
#

base_config_nodename=""
base_config_defaultrouter=""
base_config_notrouter=""

base_config_dns_domain=""
base_config_dns_nameservers=""
base_config_dns_searchpath=""

base_config_dns_disableforbuild="yes"

###########
#
# NTP configuration
#
# Specify a list of names or ip addresses for the NTP servers. The first
# one will be given a 'prefer' tag. This section will only place lines
# of the form: server <ipaddress/name> [prefer]
# into the /etc/inet/ntp.conf file. If you require more control of ntp,
# please use the custom module to deploy your own custom ntp.conf file.
#
# N.B. If you do use names, they must be resolvable in your name service.
#
base_config_ntp_servers=""

############
#
# Network Interface information
#
#
# networkifs: a list of interfaces to be defined,
# space seperated "le0 hme0".
# N.B. the sysidcfg interface will already be configured
#
# Logical interfaces should be defined using _'s rather
# than :'s.
#
# networkif_<ifname>: the details of the interface <if>
# "netname netmask hostname address"
#
# netname: arbritrary name for /etc/networks
# netmask: netmask of this if (e.g. 255.255.255.0)
# hostname: unique hostname (N.B. not multihomed)
# address: IP address of this interface
#
# For example:
#
# base_config_networkifs="ge0 ge0_1"
# base_config_networkif_ge0="bkp 255.255.255.0 me-bkp 192.168.1.0"
# base_config_networkif_ge0_1="bkp2 255.255.255.0 me-bkp2 192.168.2.0"
#

base_config_networkifs=""
base_config_networkif_le0=""

# N.B. Logical interfaces MUST use _ rather than : as illustrated below
base_config_networkif_le0_1=""

############
#
# IP Multipathing (Solaris 8+)
#
# IPMP default mode is automatic failback.
# To change this mode edit /etc/default/mpathd
#
# ipmp_networkifs: a list of interfaces to be defined under ipmp control
# a space separated list of pairs only
# e.g. "qfe0_qfe4 qfe1_qfe5"
#
# N.B. If the primary interface is used in an ipmp group, the
# system must be rebooted manually after installation to
# activate ipmp.
#
# N.B. Can only setup ipmp group with pairs of interfaces in one
# of the following configurations:
# active-standby failover:
# Set ipmp mode = s, and specify one logical
# hostname/ip address pair.
# failover with outbound load spreading:
# Set ipmp mode = l, and specify one logical
# hostname/ip address pair.
# active-active with outbound load spreading:
# Set ipmp mode = l, specify a second logical
# hostname/ip address pair for the second interface.
#
# ipmp_networkif_<if>_<if>: "netgroup mode test1 test2 mask hostname log-ip hostname2 log-ip2"
#
# details of the interfaces in the ipmp group
# e.g. networkif_ipmp_qfe0_qfe4
#
#
# netgroup: ipmp interface group name
# e.g. database-net
#
# ipmp mode: s = standby (failover only)
#
# ** test addresses are allocated last,
# ** first test address will be on the
# ** first virtual interface of the
# ** first physical adapter. Second
# ** test address will be on the second
# ** physical adapter.
#
# l = load spreading / active-active
#
# ** test addresses are allocated on
# ** first virtual interfaces on both
# ** the first and second physical
# ** adapters.
#
# To force the test addresses onto the physical
# adapters, use the suffix 'p' to the above
# modes, i.e. 'sp' or 'lp'. This is not
# recommended and may break certain applications.
#
# test1: ipmp test address1
# test2: ipmp test address2
#
# N.B. these addresses must not be used or
# placed in the hosts file
#
# mask: netmask for ipmp pair
#
# hostname: unique hostname for logical ip
#
# log-ip: logical ip address for first i/f of pair
#
# N.B. The following two parameters are for active-active
# configurations only. Do not specify them for an
# active-standby configuration.
#
# hostname2: unique hostname for logical ip
#
# log-ip2: logical ip address for second i/f
# of pair
# IPMP on Solaris 10.
# If you are running Solaris 10, you can optionally configure the
# system to have NO test addresses. In this case, the ipmp mode should be set
# to "ln" or "sn" depending on whether you want outbound load spreading or
# not and the 2 test addresses do not need to be privided.
#
# Examples:
# --------
#
#
# base_config_ipmp_networkifs="qfe0_qfe1"
# Outbound load spreading 2 hostnames, test on virtual interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db l 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3 apache 10.0.0.4"
# Outbound load spreading 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db lp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, test on physical interfaces.
# base_config_ipmp_networkif_qfe0_qfe1="db sp 10.0.0.1 10.0.0.2 24 oracle-db 10.0.0.3"
# Failover, 1 hostname, no test addresses (Sol 10 only).
# base_config_ipmp_networkif_qfe0_qfe1="db sn 24 oracle-db 10.0.0.3"
#
#
base_config_ipmp_networkifs=""
base_config_ipmp_networkif_qfe0_qfe1=""

############
#
# Misc options
#
# this section is a catchall for other options not included above
#
# update_terminal: if set, put the sysidcfg terminal type into inittab
#
# enable_savecore: if set to any value, enable save core (Solaris 2.6 only)
#
# dumpadm_minfree: set a limit so that crash dumps don't fill up the
# dump filesystem. See dumpadm(1M) -m option for
# possible values.
#
# noautoshutdown: if set to any value, disable power management
#
# enable_rootlogin: if set to any value, enable network root login
# from both telnet/rsh and ssh
#
# enable_rootftp: if set to any value, enable root ftp access
#
# shutup_sendmail: if set, create an alias hostname. to shut up sendmail
#
# poweroff_afterbuild: if set, shut the machine down once it has been built
#
# base_config_dedicated_dump_device:
# if set, dumpadm will configure the partition as a
# Dedicated Dump Device. See dumpadm(1M) for supported
# Operating Environments.
# (Device path e.g. /dev/dsk/c?t?d?s?)
#
# N.B. This partition is for the SOLE use of the crashdump utility !
#
# enable_altbreak: if set, enable alternate break sequence
#
# disable_sysid_probe: if set, skip the sysid stuff on the first reboot; this
# usually just tries to rarp ip addresses for additional
# interfaces and takes *ages* on machines with lots
# of unused network adapters.
#
#

base_config_update_terminal="yes"
base_config_enable_savecore="yes"
base_config_dumpadm_minfree="20000k"
base_config_noautoshutdown="pm_disabled"
base_config_enable_rootlogin=""
base_config_enable_rootftp=""
base_config_shutup_sendmail=""
base_config_poweroff_afterbuild=""
base_config_dedicated_dump_device=""
base_config_enable_altbreak=""
base_config_disable_sysid_probe=""

############
#
# NFSv4
#
# Set up the NFSv4 domain to prevent being prompted at first reboot.
# If not set, this will default to the entry in base_config_dns_domain,
# and if that is not set, to the value 'domain', which is the default
# in /etc/default/nfs
#
base_config_nfsv4_domain=""

############
#
# N.B. Unless you need to point this client at alternate media for patches
# and packages that is not held on this server, please skip this section!
#
# productdir is where to find the products. This should be a URI style
# path, i.e. nfs://192.168.1.1/export/install/pkgs. If the server
# is the JumpStart server, then it should just be specified
# as a normal path.
#
# patchdir is where to find the patches. Same format as productdir.
#
# --------------------------------------------------------------------------
# Leaving the following blank means they will be populated using jumpstart.conf
# and the JumpStart servers ip address. This is the default behaviour
# and should only be changed if your patch/package repository is not held
# on this server.
# --------------------------------------------------------------------------

base_config_productdir=""
base_config_patchdir=""

#
# Last one - mainly for developing JumpStart scripts!
#
# If you set this, the rc3.d/S99jumpstart script will be disabled
# (set to rc3.d/s99jumpstart) every time it is processed - this allows you
# to run it by hand and invoke each reboot step
# This does not work on Solaris 10.
#
base_config_debug_jumpstart_postinstall=""

#
###############################################################################

@@@Other JET configurations@@@

14. JET Sparc_DHCP
> I now want to configure JET for a basic sparc DHCP and
> bootp build.
>
> For Sparc DHCP do I just need to make the following
> changes…
>
> Create a template with the
> base_config_client_allocation equal "dhcp"
>
yep
> edit /opt/SUNWjet/etc/Jumpstart.conf to add uname –i
> to JS_DHCP_VENDOR="SUNW.Ultra-5_10 SUNW.Ultra-30" to
> reflect my wanting to use SPARC & DHCP.
>
yep
> And I assume make_client will create the appropriate
> settings in dhcpmgr etc.
>
uh huh
> Anything else ?
>
15. JET Sparc_Bootp

> For Sparc bootp do I just need to create a template
> with the base_config_client_allocation equal "bootp"
>
yep

> And I assume make_client will create the appropriate
> settings in tftpboot etc.
>
uh huh

> I will not be able to test this for a week or so, as
> so far all my testing has been done using Vmware
> locally on my laptop.

16. Changing the media location
>
> And finally I will in the future want to change my
> media location from /export/install to
> /export/jumpstart/s10i & /export/jumpstart/s10sparc
> etc.
>
> I guess I will need to update my “solaris locations”
> will I need to make JS_SOLARIS_DIR=/export/jumpstart
> in jumpstart.conf ? anything else ?
>
Only thing that matters is the solaris media locations. The
JS_SOLARIS_DIR only affects the location of the media when you use the
JET copy_solaris_media command, otherwise it is immaterial. In other
words, once your /opt/SUNWjet/etc/solaris_media_locations file is
vaild,
everthing should be hunky dory.

Documents

2006-08-29T12:48:34Z

Marty:

JetFeatures

2006-08-29T12:47:19Z

Marty:

Undecided about JET - well, here is a blatant marketing slide, that lists some of the key features of the toolkit, along with some of the more frequent requested ommissions:

{| {{tablestyle}}
! style="background:green; color:white" | Description
! style="background:green; color:white" | Status
|-
| Command Line Based || Yes
|-
| Web Front End (inc https) || No<sup>1</sup>
|-
| Can be run by non-root users || Yes through RBAC, sudo etc
|-
| Solaris JumpStart (netinstall) || Yes
|-
| Solaris JumpStart (Flash) || Yes
|-
| Solaris JumpStart (WanBoot) || Yes
|-
| Solaris x86 PXE || Yes
|-
| Solaris x86 GRUB || Yes
|-
| Solaris JumpStart (Bootservers) || Yes
|-
| Distributed system to remote parts of WAN || Yes
|-
| Distribution of media (pkgs, patches, images) to remote servers || Yes
|-
| Supports Tiers of JumpStart servers || Yes
|-
| Tailored installs per system || Yes
|-
| Ability to build identical servers from master configuration || Yes
|-
| Supports multiple OS installs || Yes - Solaris, RedHat and SuSE have been known to work
|-
| Works on Solaris (x86 and SPARC) || Yes
|-
| Human readable configuration files || Yes
|-
| Works 'out of the box' || Yes
|-
| Is available to the public for free || Yes
|-
| Is a core part of the Sun Field Engineers 'toolkit' || Yes
|-
| Has a large external Sun user community || Yes
|-
| Is extendible by third parties || Yes
|-
| Handles Veritas Volume Manager installs || Yes
|-
| Handles mirroring of system disk under Veritas or SVM || Yes
|-
| Can be used to install clusters, including clustered applications || Yes
|-
| Copes with Flash archives of source machines with mirrored system disks (SVM & VxVM) || Yes
|-
|}

;1: Although web front ends have been produced for JET in the past, no generic web front end is available at this time; they are mostly customised for particular clients requirements

Documents

2006-08-29T12:44:04Z

Marty:

__NOTOC__
== Marketing! ==

* [[JetFeatures]] - Basic ''feature'' list

== Introduction Documents ==
* [[JumpStartPrimer]] - Introduction to JumpStart
* [[JETPrimer]] - Introduction to JET

== Intermediate Documents ==
* [[MirroredSystemDisks]] - Using JET to mirror boot disks using SVM

== Advanced/Developer Documents ==

Documents

2006-08-29T12:43:16Z

Marty:

== Marketing! ==

* [[JetFeatures]] - Basic ''feature'' list

== Introduction Documents ==
* [[JumpStartPrimer]] - Introduction to JumpStart
* [[JETPrimer]] - Introduction to JET

== Intermediate Documents ==
* [[MirroredSystemDisks]] - Using JET to mirror boot disks using SVM

== Advanced/Developer Documents ==

JetFeatures

2006-06-21T13:00:03Z

Marty:

Undecided about JET - well, here is a blatant marketing slide, that lists some of the key features of the toolkit, along with some of the more frequent requested ommissions:

{| {{tablestyle}}
! style="background:green; color:white" | Description
! style="background:green; color:white" | Status
|-
| Command Line Based || Yes
|-
| Web Front End (inc https) || No<sup>1</sup>
|-
| Can be run by non-root users || Yes through RBAC, sudo etc
|-
| Solaris JumpStart (netinstall) || Yes
|-
| Solaris JumpStart (Flash) || Yes
|-
| Solaris JumpStart (WanBoot) || Yes
|-
| Solaris x86 PXE || Yes
|-
| Solaris x86 GRUB || Yes
|-
| Solaris JumpStart (Bootservers) || Yes
|-
| Distributed system to remote parts of WAN || Yes
|-
| Distribution of media (pkgs, patches, images) to remote servers || Yes
|-
| Supports Tiers of JumpStart servers || Yes
|-
| Tailored installs per system || Yes
|-
| Ability to build identical servers from master configuration || Yes
|-
| Supports multiple OS installs || Yes - Solaris, RedHat at present
|-
| Works on Solaris (x86 and SPARC) || Yes
|-
| Human readable configuration files || Yes
|-
| Works 'out of the box' || Yes
|-
| Is available to the public for free || Yes
|-
| Is a core part of the Sun Field Engineers 'toolkit' || Yes
|-
| Has a large external Sun user community || Yes
|-
| Is extendible by third parties || Yes
|-
| Handles Veritas Volume Manager installs || Yes
|-
| Handles mirroring of system disk under Veritas or SVM || Yes
|-
| Can be used to install clusters, including clustered applications || Yes
|-
| Copes with Flash archives of source machines with mirrored system disks (SVM & VxVM) || Yes
|-
|}

;1: Although web front ends have been produced for JET in the past, no generic web front end is available at this time; they are mostly customised for particular clients requirements

Template:Tablestyle

2006-06-21T11:00:42Z

Marty:

border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"