Solaris Jumpstart Automated Installation

Friday, August 28, 2009 at 12:33 AM
Abstract
This is an introduction to custom automated installation in a Solaris environment. It is an overview of the necessary systems, services, and configurations needed for easy client integration into existing corporate environments. General pre and post install modifications will also be discussed.

What is Jumpstart
The Jumpstart feature is an automatic installation process available in the Solaris operating environment. It allows system administrators to categorize machines on their network and automatically install systems based on the category to which a system belongs.

Reasons to Automate
· Simplifies installations
· Speed - Faster then CD-ROM installation
· Allows unattended installation
· Replication - same systems across the enterprise

All Solaris base installations require some basic configuration. With Jumpstart, Sun has enabled the system administrator to avoid repetitive tasks associated with bringing a sun system online.

Prerequisites
· A boot server on the same ethernet segment
· An install server with the Solaris OS
· A Jumpstart configuration server that defines rules and profiles.


Needed Services
Use
NFS (mountd nfsd)
Sharing Solaris OS Image Files
Rarp
IP address discovery
Bootp
Host and location of shared file systems
Rpld
Serves X86 initial boot net kernel
Tftp
Serves Solaris initial boot net kernel


Overview

IMAGE


1. Client sends a RARP for its IP address

2. The Boot Server responds via RARPD (in.rarpd) with the IP address in /etc/ethers or the ethers NIS/NIS+ map depending on the ethers setting in /etc/nsswitch.conf

3. The client sends a tftp request for a bootimage

4. The server starts in.tftp from inetd and sends the small net kernel image

5. The client then sends out a bootp request

6. The server responds with the clients entry from /etc/bootparams

7. The client NFS mount it’s root partition from the install server

8. The client then mounts the configuration server (/jumpstart) and runs “sysidtool”.

9. It then mounts the install image and runs Suninstall to begin the install process.

Boot Server
The boot server is composed of rarpd (in.rarpd), bootp (in.bootparamd), and tftp (in.tftpd) servers for solaris systems and rplboot for x86 architecture. The Boot server must be on the client’s local network due to the fact that rarp packets will not be forwarded across a router.


Server Files:
/etc/ethers Contains entry for install clients ethernet address
8:0:20:ab:cd:ef client_name


/etc/bootparams Contains NFS share parameters for installation & configuration
client_name root=boot_svr:/export/install/Solaris_2.6/Tools/Boot \
install=boot_svr:/export/install boottype=:in \
sysid_config=boot_svr:/jumpstart \
install_config=boot_svr:/jumpstart rootopts=:rsize=32768


/tftpboot Houses the small net kernel used for bootstrapping
C0A8000BC0A8000B.SUN4Uinetboot.SUN4U.Solaris_8-1rm.192.168.0.11tftpboot


/rpldboot Used in x86 installs (tftp equivalent)
192.168.0.12.glue.com
192.168.0.12.hw.com
192.168.0.12.inetboot
gluecode.com
inetboot.I86PC.Solaris_2.7-1
rm.192.168.0.12
smc.com


Design
One thing to always take into account when designing a jumpstart network is the boot server needs to be on the local net.



The above is a simple example of the limitations of rarp. Rarp does not furnish a network mask to the client, limiting the boot server (tftp) to reside on the local network. Example: if the router is not configured to pass rarp requests (default) then an engineering clients attempt to do a network install will fail because it will never find it’s own IP address.
Install Server
The install server supplies the client with the Solaris OS. It is an NFS share with the Solaris install image. Any OS able to export NFS shares is able to serve as a Jumpstart Install Server.

Configuration Server
The configuration Sever is comprised of the rules file, profiles, and sysidcfg. It allows the administrator to have available different custom jumpstart configurations based on rule sets. This is very helpful when different groups within an organization require different system configurations.
Below are examples of a profile. Profiles contain filesystem layout and package information.

Example:
# profile keywords profile values# ----------------- -----------------# This profile keyword is required in every profileinstall_type initial_install system_type standalonepartitioning defaultfilesys any 60 swapfilesys s_ref:/usr/share/man - /usr/share/man rofilesys s_ref:/usr/openwin/share/man - /usr/openwin/share/man ro,quota cluster SUNWCprogpackage SUNWman deletepackage SUNWolman deletepackage SUNWxwman deletepackage SUNWoldem addpackage SUNWxwdem addpackage SUNWoldim add
package SUNWxwdim add


Example:
profile keywords
# profile values
install_type
system_type
partitioning
cluster
cluster
package
filesys
filesys
initial_install
standalone
default
SUNWCuser
SUNWCxgl delete
SUNWaudmo add
any 40 swap
any 50 /opt

Derived Profiles
A derived profile is a profile that is dynamically created by a begin script during a custom JumpStart installation. Derived profiles are needed when you cannot set up the rules file to match specific systems to a profile (when you need more flexibility than the rules file can provide).
Set the profile field to an equal sign (=) instead of a profile.

Note: If a begin script is used to create a derived profile, make sure there are no errors in it. A derived profile is not verified by the check script because it is not created until the execution of the begin script.

Example:
#!/bin/shecho "install_type initial_install" > ${SI_PROFILE}echo "system_type standalone" >> ${SI_PROFILE}echo "partitioning default" >> ${SI_PROFILE}echo "cluster SUNWCprog" >> ${SI_PROFILE}echo "package SUNWman delete" >> ${SI_PROFILE}echo "package SUNWolman delete" >> ${SI_PROFILE}echo "package SUNWxwman delete" >> ${SI_PROFILE}


Verify Profile

After you create a profile, use the pfinstall command to test the profile before you actually use it to install or upgrade a system. Testing a profile is especially useful when you are creating upgrade profiles that reallocate disk space. Profiles should only be tested on systems with the same architecture (i386 or sparc) as the Jumpstart clients to ensure accurate results.

# prtvtoc /dev/rdsk/device_name > disk_config# /usr/sbin/install.d/pfinstall disk_configuration [-c path] profile


Rules File
The rules file is a text file used to create the rules.ok file. The rules file is a look-up table consisting of one or more rules that define matches between system attributes and profiles. For example, the rule
karch sun4c - basic_prof –
matches a system with a sun4c platform name to the basic_prof profile, which the Solaris installation program would use to install the system.

Figure 3 - How a Custom Jumpstart Installation Works


During a custom Jumpstart installation, the Solaris installation program attempts to match the rules in the rules.ok file in order: first rule through the last rule. A rule match occurs when the system being installed matches any of the values in the rule (as defined in Appendix A). As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins to install the system as defined by the matched rule's profile. This allows a fine grain control over different configuration clusters (Figure 3).

#### [!]keyword value [&& [!]keyword value] ... begin profile finish## any - - any_machine - ^ ^ ^ ^ ^ -------------- Finish script --------------- Profile -------------- Begin script ----------- Rule Value (specific system attribute) ----- Rule keyword (general system attributes)



Example:
# The following rule matches one system:
hostname host1 - host1_class set_root_pw
# The following rule matches all x86:
arch i386 x86-begin x86-class -
# The following rule matches any system:
any - - any_machine -
karch i86pc - basic_prof -

Validating the rules file
Before the profile server is able to function the jumpstart share must have a rules.ok file. The check script validates the rules file and creates the rules.ok file.

Usage: check [-r
] [-p ]

Sysidtool Suite

When you boot Solaris, a set of programs called sysidtool configures your system, prompting for information needed such as the client’s host name and IP address, the local date and time, the time zone and the netmask. NIS or NIS+ can provide this information, otherwise you have to enter it manually before JumpStart can install the OS and packages. It is also possible to create a sysidcfg file, which must be on either local media or a nfs exported filesystem.

The sysidcfg file is a file where, starting with Solaris 2.6, all the configuration information required during an OS installation can be specified. A change needed to be made to the sysidcfg provided as part of the Jumpstart package in order for the process to work on your local network.

Default values needed
· date & time
· time zone
· site netmask
· language options


Sysidcfg Example:
System_locale=en_US
name_service=NONE
network_interface=primary {protocol_ipv6=no netmask=255.255.255.0}
security_policy=NONE
root_password=XXXXXXXXX
system_locale=C
timezone=US/Eastern
timeserver=localhost
terminal=sun-cmd

Note: To use "name_service=NONE" with Solaris 2.6 you will need to load patch
106193-03 or greater. Also to use network_interface=primary on Solaris 2.6, you need patch 106193-0 or greater. Solaris 7 and Solaris 8 do not need any patches
Note: Solaris 8 will prompt for two new options, ipv6, and kerberos. To avoid user interaction you must include answers to these options in the sysidcfg file.

security_policy=NONE (disable kerberos)
network_interface=le0{netmask=255.255.255.0 protocol_ipv6=no}

Pre Solaris 2.6 did not support sysifcfg option. NIS/NIS+ can be used to supply system information

NIS/NIS+ name service
•/etc/hosts
•/etc/timezone
•/etc/netmasks
•/etc/locale
Jumpstart Diskettes
Profile floppy disks cannot be created on a platform with a different architecture than the Jumpstart client. This is due to big/little endian differences that affect the creation of the ufs filesytem. The jumpstart profile diskette may be PCFS or UFS.


Figure 2 - How a Custom JumpStart Installation Works: Non-Networked Example

The installation utility will look to the floppy drive for all configuration information.

Directory listing
drwxr-xr-x 4 root other 512 Jan 16 12:58 . drwxr-xr-x 47 root root 1024 Jan 16 13:10 .. -rw-r--r-- 1 root other 182 Jan 16 08:22 any_machine -rwxr-xr-x 1 root other 30029 Jan 15 13:34 check -rw-r--r-- 1 root other 4742 Jan 15 13:34 rules -rw-r--r-- 1 root other 54 Jan 16 08:22 rules.ok -rw-r--r-- 1 root other 188 Jan 15 13:36 sysidcfg

x86

The x86 Solaris installation cannot be totally automated. The default for installation media is local CD-ROM, you must choose network install at the intro screen.
Openwindows
X86 Solaris install will prompt during the install for openwindows parameters. To be able to automate these values you must pass them to the client through rplboot system.

#kdmconfig -c -s
Take the additions to the /etc/bootparms file and append them to your bootparms entry on the boot server

These values can also be found in
/etc/openwin/server/etc/owconfig
/etc/defaultkb

Post Install
- /etc/defaultrouter
- /etc/resolv.conf

Begin/Finish Scripts
A begin/finish script is a user-defined Bourne shell script, specified within the rules file, which performs tasks after the Solaris software is installed on the system.


variables
Variable
Description
ROOT
The rootdisk's mountpoint (/a).
TOOLSDIR
Directory where our tools are found. The mountpoint for: /export/jumpstart/Tools
BACKUPDIR
Directory to store all files and other information that need to be backed up for the particular machine.
ROOTDEV
The root disk device specified as an argument to migrate.begin.
PKGDIR
Where packages are installed on the server (migrate.end only).
JUMPSTARTDIR
The JumpStart directory on the server.

Begin/Finish details
· The Solaris installation program mounts the system's file systems onto /a. The file systems remain mounted on /a until the system reboots. Therefore, you can use the finish script to add, change, or remove files from the newly installed file system hierarchy by modifying the file systems respective to /a.
· Output from the finish script goes to /var/sadm/finish.log.
· Finish scripts should be owned by root and have permissions equal to 644.

Configuration
Steps

Server
1. Create install server(s).
2. Create a profile server
3. Create profiles
4. Create begin and finish scripts
5. Create and check rules file
Client
6. Add Client(s)
7. Boot Client(s)

Server Setup

1. The first step copies the Solaris CD to the disk. You will need around 450Mb of free space in this directory.

# cd /cdrom/cdrom0/s0/Solaris_2.6/Tools
# ./setup_install_server /export/Solaris_2.6
Verifying target directory...
Calculating the required disk space for the Solaris_2.6 product
Copying the CD image to disk...
Install Server setup complete
#

Note: for Solaris 8 if you would like to include CD 2 (Supplemental), insert CD 2 and run
# cd /cdrom/cdrom0/s0/Solaris_8/Tools
#./add_to_install_server /export/Solaris_2.6


2. Creating a Profile server
#cp -r /cdrom/cdrom0/s2/Solaris_2.6/Misc/jumpstart_sample/* /jumpstart
#share -F nfs -o ro,anon=0 /jumpstart
#shareall

3. Create profiles (Reference Profiles)
Copy profile into /jumpstart directory

4. Create begin and finish scripts (Reference begin/finish scripts)
Copy scripts into /jumpstart directory

5. Create and check rules file (Reference Rules)
#cd /jumpstart
#./check
# cd /jumpstart
# ./check
Validating rules...
Validating profile any_machine...
The custom JumpStart configuration is ok.

# cat rules.ok
any - - any_machine -



6. Adding the Install Client
#vi /etc/hosts
127.0.0.1 localhost
127.0.0.2 129.151.29.1 boot_svr loghost
127.0.0.3 129.151.29.10 client_name


#./add_install_client –e
-s :: -p : -n [SERVER]:name_service[netmask] (The brackets "[]" are needed!!!) CLIENT_NAME ARCHITECTURE

Add the client information to the server

# cd /jumpstart/Solaris_2.6/Tools
# ./add_install_client \
-e 8:0:20:7a:22:7e \
-t /jumpstart/Solaris_2.6/Tools/Boot \
-p server.rainmonkey.org:/jumpstart \
-c server.rainmonkey.org:/jumpstart \
-s server.rainmonkey.org:/export/Solaris_2.6 \
client.rainmonkey.org \
sun4u

Note: There must be an entry in the /etc/hosts for client.rainmonkey.org and server.rainmonkey.org


Client

Booting the Jumpstart Client

At the OpenBoot prompt enter

Upgrade:
#reboot "net - install"

ok> boot net - installResetting ... SPARCstation 20 MP (2 X SuperSPARC-II), No KeyboardROM Rev. 2.25, 64 MB memory installed, Serial #8004222.Ethernet address 8:0:20:7a:22:7e, Host ID: 727a227e.Initializing Memory Boot device: /iommu/sbus/ledma@f,400010/le@f,c00000 File and args: -hostname: client.rainmonkey.orgdomainname: rainmonkey.orgroot server: serverroot directory: /solaris_2.6/export/exec/kvm/sparc.sunCopyright (c) 1983-1994, Sun Microsystems, Inc./-The system is coming up. Please wait.

Note: New machines will net boot at power on

Common Problems (docs.sun.com)
The USparc II 450Mhz systems will not show the correct arch under sysidtool
http://www.freeware4sun.com/patches/README/106154-01.README

Q1: How do I configure my Boot server if it is a NIS client and I wish to
use sysidcfg file for my Jumpstart setup?

A1: To achieve that, we need to change /etc/nsswitch.conf to ensure that the
Server searches for local files first before using NIS. i.e. change hosts, ethers and
bootparams: in the nsswitch.conf file to:
hosts: files nis
ethers: files nis
bootparams: files nis
After which, we need to add to the /etc/hosts file the IP address and
hostname of the new client to be installed. We do not need to create or amend the
/etc/ethers and /etc/bootparams files. These files will be altered accordingly after we
execute the "add_install_client" command.

Q2: Can I have all Configuration, Install and Boot server functions on a
Single host?

A2: Yes.

Q3: After I have setup my Configuration/Install/Boot servers, I ran "boot net
- install" on the client and it gave me:
No bootparam (whoami) server responding; still trying...
RPC: Timed out.

A3: The ethernet address of the client is not set correctly on the Boot
server. Check that the /etc/ethers file on the Boot server has the correct ethernet
address of the client. If NIS is used for Jumpstart setup, make sure that the NIS
master server executes "make" to rebuild the network NIS maps, after the /etc/ethers
file is updated.

Q4: After I have setup my Configuration/Install/Boot servers, I ran "boot net
- install" on the client and it gave me:
root directory: /cdrom/sol_7_sparc/s0/Solaris_2.7/Tools/Boot
panic - boot: Could not mount filesystem.

A4: The filesystem with the installation directory on the Install server is
not shared. Also, make sure that, on the Configuration server, the directory with
all the rules, classes and sysidcfg files are shared.




Q5: Half way through, during the installation of the client, it stopped and
Asked for user input in one of its sysidtool or installtool dialog boxes.

A5: It means that the class or sysidcfg file has not been set up correctly.
Make sure that all the essential entries are included. Commonly omitted entries are:
"system_locale" and "timezone" for the sysidcfg file; and "locale" for the
class file.

Snoop Output

1 0.00000 OLD-BROADCAST -> (broadcast) RARP C Who is 0:a0:24:d2:f6:34 ?
2 3.00626 pikachu -> togepi RARP R 0:a0:24:d2:f6:34 is 192.168.0.12, togepi
3 0.00078 togepi -> BROADCAST BPARAM C WHOAMI? 192.168.0.12
4 0.00862 pikachu -> togepi BPARAM R WHOAMI? togepi in
5 0.00054 togepi -> (broadcast) ARP C Who is 192.168.0.1, 192.168.0.1 ?
6 0.00006 192.168.0.1 -> togepi ARP R 192.168.0.1, 192.168.0.1 is 0:90:27:d0:fd:27
7 0.00037 togepi -> pikachu BPARAM C GETFILE root
8 0.00163 pikachu -> togepi BPARAM R GETFILE File=/export/install/2.6/x86/Solaris_2.6/Tools/Boot
9 0.00073 togepi -> pikachu PORTMAP C GETPORT prog=100005 (MOUNT) vers=1 proto=UDP
10 0.00122 pikachu -> togepi PORTMAP R GETPORT port=32774
11 0.00075 togepi -> pikachu MOUNT1 C Mount /export/install/2.6/x86/Solaris_2.6/Tools/Boot
12 0.00281 pikachu -> togepi MOUNT1 R Mount OK FH=CE64
13 0.01728 togepi -> pikachu NFS C LOOKUP2 FH=CE64 etc
14 0.00099 pikachu -> togepi NFS R LOOKUP2 OK FH=8298
15 0.00066 togepi -> pikachu NFS C LOOKUP2 FH=8298 bootrc
16 0.00040 pikachu -> togepi NFS R LOOKUP2 OK FH=6C1F
17 0.00068 togepi -> pikachu NFS C GETATTR2 FH=6C1F
18 0.00038 pikachu -> togepi NFS R GETATTR2 OK
19 0.00075 togepi -> pikachu NFS C GETATTR2 FH=6C1F
20 0.00034 pikachu -> togepi NFS R GETATTR2 OK
21 0.00086 togepi -> pikachu NFS C READ2 FH=6C1F at 0 for 1344
References

http://www.sun.com/blueprints/0300/sysidcfg.pdf

http://www.sun.com/software/solutions/blueprints/1099/jumpstart.pdf

http://xi.nu/~jheiss/js/lisa99/paper.html

http://www.octaldream.com/scottm/talks/jsintro/img3.htm

Kasper, Paul Anthony and Alan L. McClellan.
Automating Solaris Installations. Prentice Hall, April 1995. ISBN: 013312505X.

http://docs.sun.com/ab2/coll.214.4/SPARCINSTALL/

http://wwwwswest.sun.com/smcc/solaris-migration/cookbook/jump1.html

http://docs.sun.com/ab2/@LegacyPageView?Ab2Lang=C&Ab2Enc=iso-8859-1&toc=SUNWab_47_3%3A%2Fsafedir%2Fspace3%2Fcoll2%2FSUNWaadm%2Ftoc%2Fx86INSTALL%3A1032;bt=x86%3A++Installing+Solaris+Software;ps=ps%2FSUNWab_47_3%2Fx86INSTALL%2F04.Preparing_Custom_JumpStart_Installati

http://www.sun.com/blueprints/0300/sysidcfg.pdf


http://sunsolve.sun.com/private-cgi/retrieve.pl?doc=faqs%2F3172

http://sunsolve.sun.com/private-cgi/retrieve.pl?doc=infodoc%2F16484&zone_32=jumpstart

Jumpstart

Thursday, August 27, 2009 at 12:37 AM

The goal:::
Create a standalone server that can be used as both a boot and install server

Creating a Jumpstart Server should not be as hard as documented on many others’ websites. Actually, nothing on a Sun hardware platform should be as difficult as many people (Sun included) make it. After digesting most of the Sun documentation regarding creating the install, boot, and file servers (Solaris 9 Installation Guide), I will now continue to explain step by step how to easily create a new jumpstart server that is both a boot and image server. This HOWTO assumes that you have a basic technical background (Sun Engineer level or better lol) and have certain other files already prepared. I may in the future include how to create most of the other files you will need (as I’m sure I’ll have to do it myself at some point)…

But only if you be good.

Preface:

I usually do not allow the cd/dvd drive to be automounted (primarily due to the environment I work in). Because of this, all of the instructions below will show the commands needed to mount and unmount the cd/dvd drive. My cd/dvd drive will be c0t0d0s0 throughout this HOWTO.

Step 1: Install a base Solaris 9 server

You may do this any number of ways. If you already have a jumpstart server and a base Solaris 9 profile you can jumpstart a new box, or if you do not you can just perform a base install using the media of your choice.

Step 2: Create some preliminary directories

There are several directories that you may want to go ahead and create. These will all be used later and will hold a variety of different items:

#> mkdir -p -m 755 /jumpstart/os/200509_Solaris_9
#> mkdir /jumpstart/profiles
#> mkdir /jumpstart/flasharchives

Step 3: Create an image of the OS media

This is really a misnomer (read: Sun is retarded). You are not really making an image of the media, you are running a script that will copy the contents of the media to the location of your choice. Why they really call this an image is unknown to me. What this “image” will be used for is when you are performing a “Custom Jumpstart Installation”. This will be where the packages and other items can be found when it is time to install them. This is also where the boot images come from a little later when we use this server as a boot server as well.

We will now copy the contents of the media (in this case DVD) to the server. Since this server will also be our boot server we also want to copy over the needed boot images. To do so type the following:

#> mount -F hsfs /dev/dsk/c0t0d0s0 /mnt
#> cd /mnt/Solaris_9/Tools
#> ./setup_install_server -b /jumpstart/os/200509_Solaris_9/

At this point, you will see the script checking for adequate disk space, and then finally copying the data over. Notice that the target directory is /jumpstart/os/200509_Solaris_9/. This is because the setup_install_server script requires that the target directory be completely void of all files both visible and hidden. So to accomodate this, I chose to create a folder that includes the media’s release month and year. This can come in handy if you decide to add newer revisions of the media.

Step 4: Copy over existing rules, profiles, sysidcfgs, and flars

Currently, the jumpstart server itself is practically ready to go, unless you were reading the installation guide in which you would have went from Chapter 23 to Chapter 27 and back to… well, you get the idea (Sun doesn’t though so let’s laugh at them, hahahaha). What we need to do now however is copy our existing configurations over to the new server. This includes but is not limited to:

  • /jumpstart/sysidcfg/*
  • /jumpstart/profiles/*
  • /jumpstart/rules
  • /jumpstart/
  • /mnt/Solaris_9/Tools/add_install_client

If this is the first jumpstart server you are building, you will unfortunately have to wait until I write a continuation HOWTO which contains instructions to create these necessary files.

We should also at this time clean up our configurations. Edit /jumpstart/rules and remove all of the entries except for the “any” entry and any others that you will surely be using. Also delete all of the profiles that don’t have a corresponding rules entry out of /jumpstart/profiles. Feel free to regenerate the rules.ok file

#> cd /jumpstart
#> ./check

Yeah, that’s right, you made a mistake in the rules file didn’t you? Fix it now before you forget…

Step 5 (Optional): Modify the nomatch.beg start script

Located in /jumpstart you should see a script name nomatch.beg. This script is run anytime a machine does not match another rule in the /jumpstart/rules.ok file. What I like to do is to have it spit out a reasonable error message stating, “This server did not have a matching rule listed in /jumpstart/rules.ok. Did you run /jumpstart/check after modifying it?”, or something like that. It really beats the alternative (the installation just failing, thanks Sun for another glorious use of documentation, comments, and error messages).

Step 6: Share the jumpstart directory

Simply put, we need to share the /jumpstart directory to allow files to be copied:

#> share -F nfs -o ro,anon=0 /jumpstart
#> shareall

Step 7: Add a client to the configuration, check running services, and test

We have now reached the point were we can add a client to the jumpstart server and test the configuration. Add a client to the server by adding an entry in:

  • /etc/ethers
  • /etc/hosts
  • /jumpstart/profiles
  • /jumpstart/rules

Now check the rules file like a good little person:

#> cd /jumpstart
#> ./check

Next be sure to add the client to allow tftpboot to work:

#> ./add_install_client -s :/jumpstart/os/200509_Solaris_9 -c :/jumpstart -p :/jumpstart sun4u

NOTE: If when you add the client you receive odd errors, make sure that rpc is running and re-add the client

#> /etc/init.d/nfs.server stop && /etc/init.d/rpc start && /etc/init.d/nfs.server start
#> cd /jumpstart
#> ./add_install_client -s :/jumpstart/os/200509_Solaris_9 -c :/jumpstart -p :/jumpstart sun4u

Now let’s check and see if the 2 necessary process are running to get the jump off the ground:

  1. verify that in.rarpd is running (ps -ef |grep -i in.rarpd)
  2. verify that in.tftpd is available (cat /etc/inetd.conf |grep -i tftp)

And finally, test the server by jumping the test box by booting the test box, sending a break and typing:

ok> boot net:speed=100,duplex=full -v - install

Or if you are fortunate enough to have good gigabit hardware:

ok> boot net:speed=1000,duplex=full -v - install

The client should soon start to build itself at this point with regard to how it is set up (flasharchive, new build, etc)

Solaris basic trouble shooting

Saturday, August 8, 2009 at 9:10 AM
Solaris booting issues & Problems:

Check the status of the syslogd:
logger -p local0.err "syslogd is alive"
TRUSS:
truss -dDelaf -vall -p `pgrep cron`

Following are some of the booting issues, error messages their meaning and possible solutions

1) Booting in single user mode and mounting root disk.
2) Making boot device alias
3) "Timeout waiting for ARP/RARP packet"? error message.
4) "The file just loaded does not appear to be executable" error message.
5) "bootblk: can't find the boot program" error message.
6) "boot: cannot open kernel/unix" error message .
7) "Error reading ELF header"? error message .
8) "Cannot open '/etc/path_to_inst'" error message.
9) "Can't stat /dev/rdsk/c0t3d0s0" error message .

1. Booting in single user mode and mounting root hard disk.

Most important step in diagnosing the booting problems is booting the system in single user mode and examining the hard disk for possible errors & work out the corrective measure. Single user mode can be achieved by any of the following methods :-
ok> boot -s ;from root disk
ok> boot net -s ;from network

ok>boot cdrom -s ;from cdrom
Rebooting with command: cdrom -s
Configuring the /devices directory
Configuring the /dev directory
INIT: SINGLE USER MODE
#
# fsck /dev/rdsk/c0t3d0s0
# mount /dev/dsk/c0t3d0s0 /mnt

Perform the required operation on mounted disk, now accessible through /mnt ,& unmount the hard disk after you are done ;
# umount /mnt
# reboot

2. Making boot device alias

In case system can not boot from primary disk and it is needed to make another boot disk to access the data, nvalias command is used.
nvalias command makes the device alias and assigns an alternate name to a physical disk. Physical address of target disk is required which can be had by show-disk command on ok>.

ok> nvalias disk7 /iommu@f,e0000000/sbus@f,e0001000/dma@3,81000/esp@3,80000/sd2,0
The new aliased disk can be named as boot disk or can be used for booting by refering its name .
ok> setenv boot-device disk7
ok>reset
or
ok> boot disk7

3."Timeout waiting for ARP/RARP packet"?

At ok> type printenv and look for these parameters.
boot-device disk
mfg-switch? false
diag-switch? false

If you see "boot-device net” or true value for the other two parameter change it to the values above.
In case you want to boot from network make sure your client is properly configured in boot server and network connections & configuration are proper.

4. The file just loaded does not appear to be executable.

Boot block on the hard disk is corrupted .Boot the system in single user mode with cdrom and reinstall boot block.

#installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t3d0s0

5. Bootblk: can't find the boot program

Boot block can not find the boot program - ufsboot in Solaris .Either ufsboot is missing or corrupted. In such cases it can be restored from the cdrom after booting from cdrom & mounting the hard disk
# cp /platform/`uname -i`/ufsboot /mnt/platform/`uname -i`

6.boot: cannot open kernel/unix

Kernel directory or unix kernel file in this directory is not found .Probably deleted during fsck or deleted by mistake .Copy it from the cdrom or restore from the backup tape.
#cp /platform/`uname -i`/kernel/unix /mnt/platform/`uname -i`/kernel

7."Error reading
ELF header."?

Kernel directory or unix kernel file in this directory is corrupted. Copy it from the cdrom or restore from the backup tape.
# cp /platform/`uname -i`/kernel/unix /mnt/platform/`uname -i`/kernel

8."Cannot open '/etc/path_to_inst'

System can not find the /etc/path_to_install file .It might be missing or corrupted and needs to be rebuild.
To rebuild this file boot the system with -ar option:
ok > boot -ar
Press enter to select default values for the questions asked during booting and select yes to rebuild /etc/path_to_install
The /etc/path_to_inst on your system does not exist or is empty. Do you want to rebuild this file [n]? y
System will continue booting after rebuilding the file.

9."Can't stat /dev/rdsk/c0t3d0s0"

When booted from cdrom and done fsck the root partition comes out to be fine but on booting from root disk this error occurs. The device name for / is missing from /dev/dsk directory and to resolve the issue /dev & /devices directories has to be restored from root backup tapes.

Solaris Basics:

1) In Solaris how many disk slices a disk can have?
a) 8 b) 7 c) 6 d) 1


2) Which file is used to set the default mask in Solaris?
a)/etc/profile b) .profile c) /etc/system d) /etc/inittab

3) What are the advantages for making disk partitions?
a) Easy to maintain b) Easy for backing up
c) Limits problems to one partition only d) Space can be monitored easily.

4 )What does a + sign in /etc/hosts.equiv indicates ?
a) All hosts are allowed b) Only known hosts are allowed c) All users are allowed d) Unknown hosts are also allowed .

5 )Which command is used to mount local file system ?
a) mount -l b) mountall c) mount d) mount -r

6) Which command line option gives a run level and output headings?
a) who -b b) who -r c) who -rh d) who -rH

7) Which command is used to change the auto-boot feature in sun ultra?
a) eeprom "auto-boot?"=true b) eeprom auto-boot?=true c) eeprom autoboot? true d) eeprom auto-boot = true

8) If patch id is 123456-10 then its revision number is -
a)123 b)456 c)10 d)6-10

9) Which commands can be used to make a device alias
a) devalias ay ok prompt b) dvalias at root prompt
c) nvram at ok prompt d) drvconfig at root prompt.

10) Where in Solaris encrypted passwords are stored?
a) /etc/passwd b) /etc/shadow c)/etc/default/passswd d)/etc/initttab

11) What is required in a diskless workstation for Solaris Workstation?
a) cpu, monitor, keyboard, hard disk b) cpu, monitor, keyboard, cdrom drive
c) cpu, monitor, keyboard, Ethernet card d) cpu and Ethernet card only.

12) Which of the following points to virtual file system?
a) /dev/dsk/c0t0d0s3 b) /dev/rdsk/c0t0d0s3
c) /dev/md/dsk/c0t0d0s3 d) /dev/vx/rdsk/data/vol1

13) Which Solaris command is used to correct file system problems?
a) newfs b) fsck c) mkfs d) format

14) Which is the configuration file for the tip command?
a)/etc/tip.conf b) /etc/remote c) /etc/inittab.d d) .profile

15) When automounter daemon needs to be restarted?
a) When direct map is changes b) when indirect map is changes
c) No need to restart d) when a new user is created

16) What is the default configuration cluster in Solaris installation?
a) Developer b) Core c) End user d) Entire Distribution

17) Which utility is used to administer the port monitor?
a)sacadm b) pmadm c) ttyadm d) admintool

18) What is the command to assign a ip address to qfe network interface?
Write the command

19) 10 30 * * 4 /usr/bin/loginfo entry in crontab will execute the program
a) Every Friday at 10.30 b) Every Thursday at 10.30
c) Every Saturday 10.30 d) Every Wednesday at 10.30

20) What do you need for a fresh Solaris Installation?
a) Host Name b) IP Address c) Net mask d) Domain name

21) How can you see the prom version?
a) show version b) prom c) banner d) version

22) Which file enables you to disable root login on terminals?
a) /etc/profile b) .profile
c) /etc/default/login d) /etc/system

23) Which directory contains run level control scripts?
a) /etc/rc2.d b) /etc/init.d c) /etc/rc3.d d) /usr/bin

24) Which command show the patch installed in the system?
a) patchadd -p b) showrev -p c) showpatch d) patchlist

25) What is the advantage of having a virtual file system?
a) Large capacity volumes b) Increased File system size
c) Performance enhancement d) backup becomes easy

26) Which file is used to define default run level for init process at booting time?
a) /etc/ttyyab b) /etc/ttyadm
c) /etc/inittab d) /etc/profile

27) Which command shows kernel parameters and and driver module information?
a) sysconfig b) prtconfig
c) dmesg d) prtconf

28) A multiuser operating system is one - in which
a) Many users can work simultaneously b) Many Processes can work simultaneously
c) A large number of users can be created d) A number of user home directories can be created.

29) What is true about software packages?
a) It is group of files & directories b) They are grouped to form clusters
c) It is standard way of delivering software in Solaris d) they can be installed using pkgadd command.

30) What type of names are used for administering disk drives in Solaris environment a) Physical b) Logical c) Virtual d) disk instance

NFS(Network File System)

at 9:09 AM

About NFS

NFS, as implemented in the SunOS and Solaris operating systems. It isintended as both an introduction to NFS and as a guide to the mostCommon problems. There are many more complete references to NFS, a fewof which are noted in section 7.4 and 7.5.

Understanding NFS:

The NFS SERVER is th e machine that makes file systems available to the network. It does so by either EXPORTING (SunOS term) or SHARING(Solaris term) them.
The NFS CLIENT is the machine that accesses file systems that havebeen made available. It does so by MOUNTING them.

Different daemons are involved with NFS:

RPC.MOUNTD only runs on NFS servers. It answers initial requests fromclients for file systems. NFSD runs on NFS servers. They are the daemons that dealwith the majority of the client NFS requests.
On SunOS 4.1.X, BIODS (block I/O daemons) help clients withtheir NFS requests. These do not exist on Solaris 2.X.
LOCKD and STATD are a set of daemons that keep track of locks on NFSfiles. There will typically be a set of daemons running on a clientand server.
NFS partitions can be mounted in one of two ways, hard or soft.

HARD MOUNTS are permanent mounts designed to look just like anynormal, local file system. If a partition that is hard mounted becomesunavailable, client programs will keep trying to access it forever.This will cause local processes to lock when a hard mounted disk goesaway. Hard mounts are the default type of mount.

SOFT MOUNTS will fail after a few retries if a remote partitionbecomes unavailable. This is a problem if you are writing to thepartition, because you can never be sure that a write will actuallyget processed on the other hand, your local processes will not lockup if that partition does go away. In general, soft mounts should onlybe used if you are solely reading from a disk and even then it shouldbe understood that the mount is an unreliable one. If you soft mount apartition that will be written to, you are nearly guaranteeing thatyou will have problems.

Number of files related to NFS:
/etc/exports (SunOS) or /etc/dfs/dfstab (Solaris) lists which files toexport on a Server. These file are maintained by hand.
/etc/xtab (SunOS) or /etc/dfs/sharetab (Solaris) lists the filesystemsthat actually are currently exported. They are maintained by exportfsand share, respectively.
/etc/rmtab on a server lists filesystems that are remotely mounted byclients. This file is maintained by rpc.mountd.
/etc/fstab (SunOS) or /etc/vfstab (Solaris) lists which files to mounton a client. These files are maintained by hand.
/etc/mtab (SunOS) or /etc/mnttab (Solaris) on a client listsfilesystems which are currently mounted onto that client. The mountand umount commands modify this file.

SVM(Solaris Volume Manager)

at 9:08 AM
Solaris Volume Manager
Solaris Volume Manager is a software product that lets you manage large numbers of disks and the data on those disks. Although there are many ways to use Solaris Volume Manager

Include the following tasks:
Increasing storage capacity
Increasing data availability
Easing administration of large storage devices

Please refer the below sun site for all SVM details

DNS(Domain Name System (or) Service (or) Server)

at 9:02 AM
DNS CONCEPTS:

Why do we have DNS servers?
Without a Name Service there would simply not be a visible Internet. To understand why, we need to look at what DNS does and how and why it evolved.
1. A DNS translates (or maps) the name of a resource to its physical IP address
2. A DNS can also translate the physical IP address to the name of a resource by using reverse look-up or mapping.
The Internet (or any network for that matter) works by allocating every point (host, server, router, interface etc.) a physical IP address (which may be locally unique or globally unique).

DNS CONCEPTS AND IMPLEMENTATION

The domain name system is a global network of servers that translate host names likehttp://www.unixmatrix.blogspot.com/ into numerical IP (Internet Protocol) addresses, like 10.15.25.0, which computers on the Net use to communicate with each other. Without DNS, we'd all be memorizing long numbers instead of intuitive URLs or email addresses.

The domain name space

In order to understand how a DNS server works, you should be familiar with what is called the domain name space. Domain Name Space looks like this:




Fig 1.1

Each node on the tree represents a domain. Everything below a node falls into its domain. One domain can be part of another domain. For example, the machine chichi is part of the .us domain as well as the .com domain.
The Internet's Domain Name Service (DNS) is just a specific implementation of the Name Server concept optimized for the prevailing conditions on the Internet.

DNS OVERVIEW

From the history of name servers three needs emerged:
1. The need for a hierarchy of names.
2. The need to spread the operational loads on our name servers
3. The need to delegate the administration of our name servers.

DOMAINS AND DELEGATIONS

The Domain Name System uses a tree (or hierarchical) name structure. At the top of the tree is the root followed by the Top Level Domains (TLDs) then the domain-name and any number of lower levels each separated with a dot.

NOTE: The root of the tree is represented most of the time as a silent dot ('.')

Top Level Domains (TLDs) are split into two types:
1. Generic Top Level Domains (gTLD) .com, .edu, .net, .org, .mil etc.
2. Country Code Top Level Domain (ccTLD) e.g. .us, .ca, .tv , .uk etc.
Country Code TLDs (ccTLDs) use a standard two letter sequence defined by ISO 3166.
The following figure shows this:




Fig 5.2

What is commonly called a 'Domain Name' is actually a combination of a domain-name and a TLD and is written from LEFT to RIGHT with the lowest level in the hierarchy on the left and the highest level on the right.

domain-name.tld e.g. example.com

In the case of the gTLDs e.g. .com, .net etc. the user part of the delegated name - the name the user registered - is called a Second Level Domain (SLD), it is the second level in the hierarchy. The user part is frequently simply referred to as the SLD. So the Domain name in the example above can be re-defined to consist of:

sld.tld e.g. example.com

The term Second Level Domain (SLD) is much less useful with ccTLDs where the user registered part is frequently the Third Level Domain e.g.:

example.co.in

example.com.br

The term Second Level Domain (SLD) provides technical precision but can be confusing - unless the precision is required we will continue to use the generic term Domain Name or simply Domain to the whole name e.g. a Domain Name is example.com or example.co.in.

Authority and Delegation

The concepts of Delegation and Authority lie at the core of the domain name system hierarchy. The Authority for the root domain lies with Internet Corporation for Assigned Numbers and Names (ICANN). Since 1998 ICANN, a non-profit organisation, has assumed this responsibility from the US government.
The gTLDs are
authoritatively administered by ICANN and delegated to a series of accredited registrars. The ccTLDs are delegated to the individual countries for administration purposes. Figure
5.2 above shows how any authority may in turn delegate to lower levels in the hierarchy, in other words it may delegate anything for which it is authoritative. Each layer in the hierarchy may delegate the authoritative control to the next lower level.

Countries with more centralized governments, like India and others, have opted for functional segmentation in their delegation models e.g. .co = company, .ac = academic etc.). Thus mycompany.co.in is the 'Domain Name' of 'mycompany' registered as a company from the UK registration authority.
By reading a domain name from RIGHT to LEFT you can track its delegation. This unit of delegation is usually referred to as a 'zone' in standards documentation.

DNS ORGANISATION AND STRUCTURE

The Internet's DNS exactly maps the 'Domain Name' delegation structure described above. There is a DNS server running at each level in the delegated hierarchy and the responsibility for running the DNS lies with the AUTHORITATIVE control at that level.
Figure 5.3 shows this diagrammatically.



Figure 5.3 DNS mapped to Domain Delegation

The Root Servers (Root DNS) are the responsibility of ICANN but operated by a consortium under a delegation agreement. ICANN created the Root Servers Systems Advisory Committee (RSSAC) to provide advice and guidance as to the operation and development of this critical resource. The IETF was requested by the RSSAC to develop the engineering standards for operation of the Root-Servers. This request resulted in the publication of RFC 2870.
There are currently (mid 2003) 13 root-servers world-wide.

The Root-Servers are known to every public DNS server in the world.
The TLD servers (ccTLD and gTLD) are operated by a variety of agencies and registrars under a fairly complex set of agreements by Registry Operators.

The Authority and therefore the responsibility for the User (or 'Domain Name') DNS servers lie with the owner of the domain. In many cases this responsibility is delegated by the owner of the Domain to an ISP, Web Hosting Company or increasingly a registrar. Many companies, however, elect to run their own DNS servers and even delegate the Authority and responsibility for sub-domain DNS servers to separate parts of the organisation.

When any DNS cannot answer (resolve) a request for a domain name from a host e.g. example.com the query is passed to a root-server which will direct the query to the appropriate TLD DNS server which will in turn direct it to the appropriate Domain (User) DNS server.

DNS QUERIES

The major task carried out by a DNS server is to respond to queries (questions) from a local or remote resolver or other DNS acting on behalf of a resolver. A query would be something like 'what is the IP address of abc.example.com'.
A DNS server may receive such a query for any domain. DNS servers may be configured to be authoritative for some (if any) domains, slaves, caching, forwarding or many other combinations for others.
Most of the queries that a DNS server will receive will be for domains for which it has no knowledge i.e. for which it has no local zone files. The DNS software typically allows the name server to respond in different ways to queries about which it has no knowledge.
There are three types of queries defined for DNS:
1. A recursive query - the complete answer to the question is always returned. DNS servers are not required to support recursive queries.
2. An Iterative (or non-recursive) query - where the complete answer MAY be returned. All
DNS servers must support Iterative queries.
3. An Inverse query - where the user wants to know the domain name given a resource record.

Note: The process called Reverse Mapping (returns a host name given an IP address) does not use Inverse queries but instead uses Recursive and Iterative (non-recursive) queries using the special domain name IN-ADDR.ARPA. Historically reverse IP mapping was not mandatory. Many systems however now use reverse mapping for security and simple authentication schemes so proper implementation and maintenance is now practically essential.

Recursive Queries

A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and either the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.

There are three possible responses to a recursive query:

1.The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
2.An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
3.A temporary error indication - e.g. can't access other DNS's due to network error etc.
In a recursive query a DNS server will, on behalf of the client (resolver), chase the trail of DNS across the universe to get the real answer to the question. The journeys of a simple query such as 'what is the IP address of xyz.example.com' to a DNS server which supports recursive queries but is not authoritative for example.com could look something like this:

1.Resolver on a host sends query 'what is the IP address of xyz.example.com' to locally configured DNS server.
2.DNS server looks up xyz.example.com in local tables (its cache) - not found
3.DNS sends query to a root-server for the IP of xyz.example.com
4.The root-server replies with a referral to the TLD servers for .com
5.The DNS server sends query 'what is the IP address xyz.example.com' to .com TLD server.
6.The TLD server replies with a referral to the name servers for example.com
7.The DNS server sends query 'what is the IP address xyz.example.com' to name server for example.com.
8.Zone file defines a CNAME record which shows xyz is aliased to abc. DNS returns both the CNAME and the A record for abc.
9.Send response abc=x.x.x.x (with CNAME record xyz=abc) to original client resolver. Transaction complete.

Iterative (non-recursive) Queries

An Iterative (or non-recursive) query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.

There are four possible responses to a non-recursive query:
1.The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
2.An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
3.A temporary error indication - e.g. can't access other DNS's due to network error etc...
4.A referral; the name and IP address (es) or one or more name server(s) that are closer to the requested domain name. This may, or may not be, the authoritative name server for the target domain.
The journeys of a simple query such as 'what is the IP address of xyz.example.com' to a DNS server which supports Iterative (non-recursive) queries but is not authoritative for example.com could look something like this:
1.Resolver on a host sends query 'what is the IP address xyz.example.com' to locally configured DNS server.
2.DNS server looks up xyz.example.com in local tables (its cache) - not found
3.The DNS replies with a referral containing the root-servers
4.Resolver sends query to a root-server for the IP of xyz.example.com
5.The root-server replies with a referral to the TLD servers for .com
6.The Resolver sends query 'what is the IP address xyz.example.com' to .com TLD server.
7.The TLD server replies with a referral to the name servers for example.com
8.The Resolver sends query 'what is the IP address xyz.example.com' to name server for example.com.
9.Zone file defines a CNAME record which shows xyz is aliased to abc. DNS returns both the CNAME and the A record for abc.
10.Transaction complete.

Note: The above sequence is highly artificial since the resolver on Windows a most *nix systems is a stub resolver - which is defined in the standards to be a minimal resolver which cannot follow referrals. If you reconfigure your local PC or Workstation to point to a DNS server that only supports Iterative queries - it will not work.

Inverse Queries

An Inverse query maps a resource record to a domain. An example Inverse query would be 'what is the domain name for this MX record'. Inverse query support is optional and it is permitted for the DNS server to return a response Not Implemented.
Inverse queries are NOT used to find a host name given an IP address. This process is called Reverse Mapping (Look-up) uses recursive and Iterative (non-recursive) queries with the special domain name IN-ADDR.ARPA.

Zone Updates

The initial design of DNS allowed for changes to be propagated using Zone Transfer (AXFR) but the world of the Internet was simpler and more sedate in those days (1987). The desire to speed up the process of zone update propagation while minimizing resources used has resulted in a number of changes to this aspect of DNS design and implementation from simple - but effective - tinkering such as Incremental Zone Transfer (IXFR) and Notify messages to the concept of Dynamic Updates which is still not widely deployed.
Warning While zone transfers are generally essential for the operation of DNS systems they are also a source of threat. A slave DNS can become poisoned if it accepts zone updates from a malicious source. Care should be taken during configuration to ensure that, as a minimum, the 'slave' will only accept transfers from known sources.

Full Zone Update (AXFR)

The original DNS specifications (RFC 1034 & RFC 1035) envisaged that slave (or secondary) DNS servers would 'poll' the 'master'. The time between such 'polling' is determined by the REFRESH value on the domain's SOA Resource Record

The polling process is accomplished by the 'slave' sending a query to the 'master' and requesting the latest SOA record. If the SERIAL number of the record is different from the current one maintained by the 'slave' a zone transfer (AXFR) is requested. This is why it is vital to very disciplined about updating the SOA serial number every time anything changes in ANY of the zone records.
Zone transfers are always

Incremental Zone Update (IXFR)

Transferring very large zone files can take a long time and waste bandwidth and other resources. This is especially wasteful if only a single record has been changed! RFC 1995 introduced Incremental Zone Transfers (IXFR) which as the name suggests allows the 'slave' and 'master' to transfer only those records that have changed.
The process works as for AXFR. The 'slave' sends a query for the domain's SOA Resource Record every REFRESH interval. If the SERIAL value of the SOA record has changed the 'slave' requests a Zone Transfer and indicates whether or not it is capable of accepting an Incremental Transfer (IXFR). If both 'master' and 'slave' support the feature an Incremental Transfer (IXFR) takes place otherwise a Full Zone Transfer (AXFR) takes place. Incremental Zone transfers use TCP on port 53 (normal DNS queries operations use UDP on port 53).
The default mode for BIND when acting as a 'slave' is to use IXFR unless it is configured not to using the request-ixfr parameter in the server or options section of the named.conf file.
The default mode for BIND when acting as a 'master' is to use IXFR only when the zone is dynamic. The use of IXFR is controlled using the provide-ixfr parameter in the server or options section of the named.conf file.
Notify (NOTIFY)
RFC 1912 recommends a REFRESH interval of up to 12 hours on the REFRESH interval of an SOA Resource Record. This means that changes to the 'master' DNS may not be visible at the 'slave' DNS for up to 12 hours. In a dynamic environment this may be unacceptable.

RFC 1996 introduced a scheme whereby the master will send a NOTIFY message to the slaveDNS systems that a change MAY have occurred in the domain records. The 'slave' on receipt of the NOTIFY will request the latest SOA Resource Record and if the SERIAL value is different will attempt a Zone Transfer using either a full Zone Transfer (AXFR) or an Incremental Transfer (IXFR).
NOTIFY behavior in BIND is controlled by
notify, also-notify and notify-source parameters in the zone or options statements of the named.conf file.

Dynamic Update

The classic method of updating Zone Resource Records is to manually edit the zone file and then stop and start the name server to propagate the changes. When the volume of changes reaches a certain level this can become operationally unacceptable - especially considering that in organizations which handle large numbers of Zone Files, such as service providers, BIND itself can take a long time to restart at it plows through very large numbers of zone statements.
The 'holy grail' of DNS is to provide a method of dynamically changing the DNS records while DNS continues to service requests.
There are two architectural approaches to solving this problem:
Allow 'run-time' updating of the Zone Records from an external source/application.
Directly feed BIND (say via one of its two APIs) from a database which can be dynamically updated.
RFC 2136 takes the first approach and defines a process where zone records can be updated from an external source. The key limitation in this specification is that a new domain cannot be added dynamically. All other records within an existing zone can be added, changed or deleted. In fact this limitation is also true for both of BIND's APIs as well.

Part of this specification the term Primary Master is coined to describe the Name Server defined in the SOA Resource Record for the zone. The significance of this term is that when dynamically updating records it is essential to update only one server even though there may be multiple master servers for the zone. In order to solve this problem a 'boss' server must be selected, this 'boss' server termed the Primary Master has no special characteristics other than it is defined as the Name Server in the SOA record and may appear in an allow-updateclause to control the update process.
While normally associated with Secure DNS features (TSIG - RFC 2845 & TKEY - RFC 2930) Dynamic DNS (
DDNS) does not REQUIRE TSIG/TKEY. However there is a good reason to associate the two specifications when you consider that by enabling Dynamic DNS you are opening up the possibility of master zone file corruption or poisoning. Simple IP address protection (ACL) can be configured into BIND but this provides - at best - limited protection. For that reason serious users of Dynamic DNS will always use TSIG/TKEY procedures to authenticate incoming requests.
Dynamic Updating is defaulted to
deny from all hosts. Control of Dynamic Update is provided by the BIND allow-update (usable with and without TSIG/TKEY) and update-policy (only usable with TSIG/TKEY) clauses in the zone or options statements of the named.conf file.
There are a number of Open Source tools which will initiate Dynamic DNS updates these include
dnsupdate (not the same as DNSUpdate) and dnsupdate which is distributed withbind-utils.

Alternative Dynamic DNS Approaches

As noted above the major limitation in the standard Dynamic DNS (RFC 2136) approach is that new domains cannot be created dynamically.


BIND-DLZ takes a much more radical approach and using a serious patch to BIND allows replacement of all zone files with a single zone file which defines a database entry. The database support, which includes most of the major databases (MySQL, PostgreSQL, BDB and LDAP among others) allows the addition of new domains as well as changes to pre-existing domains without the need to stop and start BIND. As with all things in life there is a trade-off and performance can drop precipitously. Current work being carried (early 2004) out with a High performance Berkeley DB (BDB) is showing excellent results approaching raw BIND performance.

Solaris | Powered by Blogger | Entries (RSS) | Comments (RSS) | Designed by MB Web Design | XML Coded By Cahayabiru.com