Project

General

Profile

Solaris Unattended installation » History » Version 2

Oliver Weinmann, 12/28/2011 04:10 AM

1 1 Romain Vrignaud
h1. Solaris Unattended installation
2
3
h2. Media notes
4
5
A Solaris distribution should be declared in the same form as a Linux distribution. There should be an http based access URL, (the path variable,) so that the smart-proxy can
6
download the required components for the build. As the Solaris jumpstart process is performed via NFS rather than TFTP the distribution media must also be made available for
7
ReadOnly mounting on the clients. The fields describing this alternative access naming scheme are revealed on the Media page when a Solaris operating system is selected. The
8
Solaris build can proceed via a conventional package build, where the packages selected are the SUWNCreq minimal install, or a flash build. The flash archives are located under 
9
the distribution directory by default but can be located anywhere that can be accessed via NFS.
10
11 2 Oliver Weinmann
Example:
12
13
<pre>
14
Name: Solaris Install Media
15
16
Path: http://server/Solaris/install/Solaris_$major.$minor_$arch_$release
17
Media Path: server:/Solaris/install/Solaris_$major.$minor_$arch_$release
18
Config Path: server:Solaris/jumpstart
19
Image Path: server:/Solaris/images
20
</pre>
21
22 1 Romain Vrignaud
h2. jumpstart files
23
24
The Solaris jumpstart process is occurs in two phases; a diskless client is first booted and then in phase two, the host mounts its build media and configuration files from an NFS location and proceeds with the build. Foreman provides a skeleton configuration directory structure suitable for NFS mounting on the host. In this structure are files that are customised to forward configuration requests to the Foreman instance. This directory tree, located at .../foreman/extra/jumpstart, should be NFS shared to the subnet that contains any potential Solaris clients. Some customization of this directory tree may be required. See [[Solaris_jumpstart_directory]]
25
26
h2. Model consolidation
27
28
When Foreman imports a host that has not been configured and built by Foremen it will attempt to determine the model of that machine by analyzing the facts that are associated with the host. This can often result in many badly named models all referring to what should be a single manufacturers model. A rake task has been provided that attempts to consolidate all these duplicate malformed names into a single sensible model together with the appropriate Solaris vendor class and Solaris hardware model. See [[models_consolidate|rake models::consolidate]]