NIS Master Server Config
NIS maps are located in /var/yp/domainname directory(where domainname is the name of the NIS domain). There are two files (.pag and .dir files) for each map in this directory. Eg.
/var/yp/training/hosts.byname.pag file
/var/yp/training/hosts.byname.dir file
/var/yp/training/hosts.byaddr.pag file
/var/yp/training/hosts.byaddr.dir file
The syntax for the NIS map is map.key.pag and map.key.dir
Ypcat [-k] mname -- To retrieve values from NIS name service map, mname can be either a
map name or a map nickname
# ypcat hosts
localhost 127.0.0.1 localhost
sysprint 192.168.30.70 sysprint
sys44 192.168.30.44 sys44 loghost
ypmatch [-k] value mname -- Prints values associated with one or more keys from the NIS
name services map specified by the mname argument.
# ypmatch sys44 hosts
sys44: 192.168.30.44 sys44 loghost
# ypmatch usera passwd
usera: usera:LojyTdiQev5i:3001:10::/export/home/usera:/bin/ksh
NIS Domain Contains
One NIS Master Server
NIS Slave Servers (Optional)
NIS Clients
The NIS Master Server
Contains the original /etc/ASCII files used to build the NIS maps
Contains the NIS maps generated from the ASCII files
Provides a single point-of control for the entire NIS domain
NIS Slave Servers
Do not contain the original /etc/ASCII files
Contains copied of the NIS maps copied from the NIS Master Server
Provides a a backup repository for NIS map information
Provides redundancy in case of server failure
Provides load sharing on large networks
NIS Clients
Do not contain original /etc/ASCII files
Do not contain any NIS maps
Bind to the master server or to a Slave Server to obtain access to the administrative file information contained in that server’s NIS maps
Dynamically rebind to another server in case of server failure
Make all appropriate system calls aware of NIS
NIS Processes
The main daemons involved in the running of an NIS domain are
The ypserv daemon -- Responds to client information requests
The ypbind daemon -- Client to server binding
The rpc.yppasswd daemon -- Password change update in master server
The ypxfrd daemon -- Push the map to slave servers (sync)
The rpc.ypupdated domain -- Update NIS maps using the config stored in /var/yp/updates
The NIS Slave Server contains upserv and ypbind daemon
The NIS Clients contains only ypbind daemon
The three most common search orders are
Search files and then NIS
Search NIS and then files
Forward hosts lookup requests from NIS to DNS
Introducing NIS Security
The /var/yp/securenets file to restrict access to a single host or to a subnetwork, and using the passwd.adjunct file to limit access to the password information across the network.
The /var/yp/securenets File
If exist on an NIS server, the server only answers queries or supplies maps to hosts and networks whose IP Address exist in the file. The server must be part of the subnet to access itself.
# cat /var/yp/securenets
# Two methods of giving access to a system. Using the netmask followed by the IP Address
# or host keyword followed by the IP Address
host 127.0.0.1
255.255.255.0 150.10.1.0
host 13.13.14.1
host 13.13.14.2
If you modify entries in the /var/yp/securenets file. You must kill and restart the ypserv and ypxfrd daemons.
# /usr/lib/netsvc/yp/ypstop (or) ypstart
The passwd.adjunct File
Encrypted password are normally hidden from the user in the /etc/shadow file. With the default NIS configuration, however the encrypted password string is shown as part of passwd maps. This file prevents unauthorized users from seeing the encrypted passwords.
# ypmatch –k usera passwd
usera: usera:LojyTdiQev512:3001:10:/export/home/usera:/bin/ksh
The passwd.adjunct file contains the account name preceded by ## in the password field. Subsequent attempts to gain account ino, using the ypcat or ypmatch commands, returnds the password entry from the passwd adjunct file.
# ypmatch –k usera passwd
usera: usera:##usera:3001:10:/export/home/usera:/bin/ksh
Configuring NIS Domain
To locate the source file in another directory, modify the /var/yp/Makefile file:
Change the DIR=/etc line to DIR=Your choice
Change the PWDIR=/etc line to PWDIR=/your-choice
Before you make any modification to the /var/yp/Makefile, save a copy of the original Makefile file.
The NIS configuration script /usr/sbin/ypinit and the make utility generate NIS maps. The ypinit command reads the Makefile for source file locations, and converts ASCII scource files into NIS maps.The /etc/defaultdomain file sets the NIS domain name during system boot.
Important files on the NIS Master (Part 1) -- hosts, passwd & shadow
Important files on the NIS Master (Part 2)
The /var/yp/domainname directory is the repository for the NIS maps created by the ypinit script.
The /var/yp/binding/domainname directory contains the ypservers file where the names of NIS Master server and NIS Slave server are stored.
Important files on the NIS Master (Part 3) -- The /usr/netsvc/yp directory contains the ypstop and ypstart commands that stop and start NIS services respectively
# /usr/sbin/ypinit –m -- This command prompts for a list of other machies to become NIS
slave servers.
Configuring the NIS Master Server
Core, End User or Developer software configuration cluster do not have all necessary files in the /usr/lib/netsvc/yp directory to allow a host to function as an NIS server.
1. Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file. If necessary, modify the file
2. Enter the domainname command to set the local NIS domain
# domainname classroom.central.sun.com
3. Create an /etc/defaultdomain file with the domain name
4. If the files do not already exist, use the touch command to create zero-length files.
/etc/ethers, /etc/bootparams, /etc/locale, /etc/timezone, /etc/netgroup and /etc/netmasks.
These files are necessary for the creation of the complete set of NIS maps.
5. Install and update Makefile file in the /var/yp directory.
6. Create or populate the /etc/locale file, and make an entry for each domain on your network
using the following format
domainname locale eg. Classroom.central.sun.com en_us
7. Initialize the master server by using the local /etc files
# ypinit –m -- Provide slave server names and Ctrl+D to save the details. Press n for
“Terminate it on the first fatal error”
Note: If you have to restart the ypinit program, You are prompted to destroy the
/var/yp/domainname directory. Answer Y
8. # /usr/lib/netsvc/yp/ypstart
Testing the NIS Service
$ ypcat hosts -- Prints value from an NIS map
# ypmatch sys41 localhost hosts
192.168.30.41 sys41
127.0.0.1 localhost loghost
$ ypwhich -- To identify the master server
sys41
Configure the NIS Client
1. Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file
2. Edit the /etc/inet/hosts file to ensure NIS master and slave servers have been defined.
3. # domainname domainname -- To set the local NIS domain
4. Create and populate the /etc/defaultdomain file with the domain name
5. # ypinit –c -- To initialize the system as an NIS client
6. Enter the names of the NIS Master and all Slave Servers
7. # /usr/lib/netsvc/yp/ypstart
8. # ypwhich –m -- To test the functionality
Configuring NIS Slave Server
Follow the client configuration steps and perform the below command
# ypinit –s master -- Command to initialize the system as an NIS slave server. Where master is the name of the NIS master. Start the service and test the functionality
Updating the NIS Map
1. Updates the text files in your source directory (typically /etc, unless it was changed in the Makefile file)
2. # cd /var/yp
3. # /usr/ccs/bin/make -- Refresh the NIS database maps using the make utility
Updating NIS Password Map
If the NIS master is running the rpc.yppasswdd daemon, any client system can update the NIS password map by using the yppasswd or passwd commands.
1. Run the rpc.yppasswdd daemon on the NIS master server
# /usr/lib/netsvc/yp/rpc.yppassed /$PWDIR/passwd –m passwd
Updating the NIS Slave Server Map
The following steps manually update the NIS timezone map on the master server and propagate all maps to the slave servers
1. Edit the source file on the NIS Master
# vi /etc/timezone
2. Remake and push the NIS maps to slave servers
# cd /var/yp; /usr/ccs/bin/make
3. If the push fails. Manually pull only the timezone map from the master server by
performing the below command in Slave server
# /usr/lib/netsvc/yp/ypxfr timezone.byname
# ypinit –s nis_master -- To pull all of the maps at once
Sometimes maps fail to propagate, and you must manually use the ypxfr command to retrieve new map information. You can use shell scripts to run cron jobs for automatic update. The Solaris OE provides several template scripts in the /usr/lib/netsvc/yp directory that you can use and modify to meet your local site requirement.
ypxfr_lperhour script -- To sync NIS Slave Servers passwd map
ypxfr_lperday script -- To sync NIS Slave Servers NIS maps for the group, protocols,
networks, services, and upservers keys.
Ypxfr_2perday script -- To sync NIS Slave servers nIS maps for the hosts, ethers, netfroups keys, and mail aliases.
Quick Reference
# domainname digit.com -- Create domain name
# domainname > /etc/defaultdomain -- Creating domainname file
# cp /etc/nsswitch.nis /etc/nsswitch.conf
# /var/yp/Makefie -- Config file
Makefile 4 parts
1 – Declaration
2 – Details of centralization
3 – Coding for mapping
4 – Declaration of original path
# cd /var/yp
# ypinit –m -- Initializing the master server
# ypinit –s -- Initializing the slave server
# ypinit –c -- Initializing the client
Ctrl+D -- To save the file
Is this correct? [y/n] y
Non fatal error [y/n] n
If there is any error follow the below procedure
# cd /etc
# touch ethers bootparams netgroup netmasks timezone
# cd /var/yp
# ypinit –m
# /usr/lib/netsvc/yp/ypstart -- To start the daemons
# ypwhich -- Shows the map server details
Solaris
# ypwhich –m -- Full details of map
A directory will be created with domain name
# cd /var/yp/digit.com -- Contains all config file with .pag & .dir extensions
# ypcat to read the file
# ypcat –k passwd -- With arguments print keys as well as values
# ypmatch –k root passwd
NIS Master Server Configurations
Solaris Zones configuration and set up
Solaris Zones Features :-
1.Virtualization like VMware
2.Solaris Zones can hosts only instances of solaris. Not other Os's
3.Limit of 8192 Zones per solaris Host
4.Primary Zone(Global) has access to all zones
5.non-global zones, do not have access to other non-global zones
6.Default non global zones derive oackages from global Zone
7.Program Isolation like zone1 for apache zone2 for mysql zone3 for databases.
8.Provides 'Z' commands to manage Zones : Zlogin zonecfg zoneadm zonename
Features of Global Zone
1.Solaris Always boots(cold/warm) to the global zone.
2.Knows about All Hardware devices attach to system
3.Knows about all non global Zones
Features of Non-Global Zones.
1.Installed at a location on the filesystem of the Global Zone
'Zone root path' /export/home/zones/zones1 {Zone2,Zone3----} this is as root directory for this zones.
2.Share Packages with Global Zone.
3.Manage distinct hostname and table files.
4.cannot communicate with other non-global zones by default.NIC must be used, which means use standard network API(TCP)
5.Global Zone admin can delegatenon-global zone administration
Zones Commands example :-
#which zonename - to check if you os has zonename commands
/usr/bin/zonename
#zonename - by default will show global zonename.
global
#z - "z' commands
Zone Configuration.
#zonecfg - to configure zones
note - zonecfg can run interactively , non -interactively, command-file modes
Requirements for non-global zones;
1.Hostname of
2.Zone root path ie /export/home/zones/testzone1
3.IP Adress - bound to logical or physical interfaces.
Zones Types:-
1.sparse Root Zones - share key fileswith global zones.
2.Whole Root Zones - require more storage
#df -k and select a slice which has more space lets example /export/home has 5GB
Steps for Configuring non-global-zone:
1.mkdir /export/home/zones/testzone1
2.chmod 700 /export/home/zones/testzone1 - for user restriction of global zone users.
3.ls -ltr /export/homes/zones
4#zonecfg -z testzone1
no such zone configured create one This error will pop when you first create a zone
>create - to create a zone
>set zonepath=/export/home/zones/testzone1 - This is the Root path for zone
>add net
>set address=192.168.1.0 - ip address
>set physocal=el000g0 - physical name of network card check with 'ifconfig -a'
> - If you are ready with you parameters press end before you can exit
>info- to see what we have set
>set autoboot=true - test zone will started automatically when system start
>info
>add attr - to add some extra parameters
attr>set name=commnet
attr>set type=string
attr>value =TestZone1
>end
>verify - verify if any error check the parameter again.
>commit - commit changes
>exit.
#list -iv - to list zones
#zoneadmin -z testzone1 install
Zone testzone1 in to installed in not ready for production so we have to get it in ready state now
#zoneadm list -iv - still u can see testzone1 has not got any id assigned like global one so now
#zoneadm -z testzone1 boot - boots the zone , changing its state from installed to ready
Simple is we are restarting the Testzone1
#zoneadm list -iv - now you can see an id is assigned and status is running.
#ps -ef | grep z
zoneadmd -z testzone1 - this process is responsible for this zone to run.
zlogin - is used to login to zones
Note - each non - global maintain a console, use 'zlogin -C testzone1' to acces that zone.
Note - zlogin permits login to non - global zone via the following messages
1.Interactive - i.e zlogin -l username zonename
2.Non -Interactive - zlogin options command
3.Console Mode - zlogin -C zonename
4.Safe Mode - zlogin -S
#zoneadm list -iv
#zlogin -C testzone1
select a laguage - 0 English
Vt100 - terminal
testzone1 press F2
Configure Kerbose - yes
name service - nis
Enter from this procure its same like installation of solaris so specify all details as required.
like dns names, nis services location places etc etc
#enter with root user and passwd
#zonename
testzone1
#zoneadm list -iv - shows all zones global and non - global
# once u r in testzone1 check /etc/passwd file u can see the system user but not users of the main system
#netstat -anp tcp
#Zoneadm -z testzone1 reboot - reboots the zone
#zlogin testzone1 shutdown - to shutdown the zone
Once Zones are created you can ssh or telnet from remote machine to connect that zone
How to Configure Name Service Clients
Configuring a DNS Client
The client resolver code is controlled by the following files
/etc/resolv.conf -- Contains directive to specify the scope of a query
/etc/nsswitch.conf -- Contains the reference to DNS for the hosts entry
Configuring the DNS Client During Installation
-- Select DNS -- Give Domain Name -- Enter IP Address -- Enter search Domains -- Confirm
Editing DNS Client Configuration Files
# vi /etc/resolv.conf
domain digigeeks.com
nameserver 140.40.40.152
search digigeeks.com -- List the local domain as the first argument to the search
Copying the /etc/nsswitch.dns File to the /etc/nsswitch.conf
# cp /etc/nsswitch.dns /etc/nsswitch.conf
# cat /etc/nsswitch.conf
………
hosts files dns
……..
If you want to add DNS name resolution to a system currently running a name service, such as NIS or NIS+. You must place the dns keyword on the hosts line in the specific location, along with other keywords.
# cat /etc/nsswitch.conf
…..
hosts: nfs files dns
…..
Setting up an LDAP Client
The LDAP server cannot be a client of itself. Getting this configuration to work properly requires changes to the LDAP server and the LDAP client. The ldap_cachemgr daemon is responsible for maintaining and updating the changes to the client profile information.
Configuring LDAP Client During Installation
-- Select LDAP -- Enter Domain Name -- Enter Profile Name & Profile Server IP Address -- Confirm
Initializing the Native LDAP Client
You execute the ldapclient command on the client system once to initiate the client as a native LDAP client. The ldapclient command creates two files in the ./var/ldap directory on the LDAP client. These files contain info that the LDAP client use when binding to and accessing LDAP data.
/var/ldap/ldap_client_cred -- The proxy agent info that the client uses for LDAP authentication
/var/ldap/ldap_client_file -- The config info from the client profile in the LDAP server DB
# ldapclient init –a proxy password=proxy –a proxy DN=cn=proxyagent, ou=profile, dc=suned.com, dc=sun –a domainname=suned.com 192.168.0.100
# ldapclient list
Copying the /etc/nsswitch.ldap to the /etc/nsswitch.conf
During LDAP client initialization the /etc/nsswitch.ldap file is copied over the /etc/nsswitch.conf file
# ldaplist -- To list naming info from LDAP server
# ldapclient uninit -- Unconfiguring LDAP Client
Jump start and Boot Only Server
Four Main Services - Boot Services, Identification Services, Configuration Services, Installation Services
Implementing a Basic Jumpstart Server
1. Spool the OS image
2. Edit the sysidcfg file
3. Edit the rules and profile files
4. Run the check script
5. Run the add_install_client scripts
6. Boot the client
# cd /export
# mkdir config
# mkdir sol_dump
# cd /cdrom/cdrom0/s0/Solaris_9/Misc/Jumpstart_sample/
# cp –r * /export/config/
# cd /cdrom/cdrom0/s0/Solaris_8/Tools
# ./setup_install_server /export/home/sol_dump -- Copying solaris dump to local directory
# cd /cdrom/cdrom0/Solaris_9/Tools/
# ./add_to_install_server /export/home/sol_dump -- Appending 2nd CD content
# cd /etc
# vi ethers
8:0:20:a6:aa:2b ultra5 (hostname)
# vi /etc/hosts
140.40.40.154 ultra5
# vi /etc/timezone
Asia/Calcutta ultra5
# cd /export/config/
# vi rules
hostname ultra5 - host_class finish_script
- Pre Install script
host_class -- Config details like partition
finish_script -- Post install scripts
# vi host_class
install_type initial_install
system_type standalone
partitioning explicit
Cluster SUNWXall
filesys c0t0d0s0 10000 /
filesys c0t0d0s1 550 swap
filesys c0t0d0s7 free /export/home
# vi finish_script
touch /a/noaushutdown
rm /a/etc/defaultdomain
rm –r /a/var/yp/digit.com
cp /a/etc/nsswitch.files /a/etc/nsswitch.conf
# vi sysidcfg -- System identification & configuration. Timezone can also be given here
security_policy=none
name_service=none
network_interface=primary [netmask=255.255.0.0 protocol_ipv6=no]
timezone= Asia/Calcutta
system_locale=en_US
-- Time zone are listed in the directory structure below the /usr/share/lib/zoneinfo directory.
-- Locales are listed in the /usr/lib/locale directory
# chmod 755 finish_script
# ./check -- To check the config
# vi /etc/dfs/dfstab
share –o anon=0 /export/home/sol_dump
share –o anon=o /export/config
# cd /var/yp
# /usr/ccs/bin/Make
# cd /export/home/sol_dump/solaris_9/Tools
# ./add_install_client –c 140.40.40.151:/export/config –p 140.40.40.151:/export/config ultra5(hostname) sun4u
# update the NIS file with make command
From Client
ok boot net –install -- Will search the network and start the installation automatically
-- Before a Jumpstart client can boot and obtain all of the NFS resourctes it requires, every directory listed as an argument to the add_install_client script must be shared by the server on which it resides.
Setting Up a Boot-Only Server
A boot server responds to RARP, TFTP, and bootparams requests from jumpstart clients and provides a boot image using the NFS service.
1. Running the setup_install_server script with the –b option to spool a boot image from CD-Rom or DVD
2. Running the add_install_client script with options and argument that shows a list of servers and the identification config, and installation services that they provide.
Executing the setup_install_server script
# mkdir /export/install
# cd /cdrom/cdrom0/s0/Solaris_9/Tools
# ./setup_install_server –b /export/install
Executing the add_install_client script
Before you run the script, update the hosts and ethers information for the jumpstart client
/etc/inet/hosts
192.10.10.4 client1
/etc/ethers
8:0:20:9c:88:5b client1
The boot server must have entry in /etc/inet/hosts file for each server you specify while you run add_install_client script.
# cd /export/install/Solaris_9/Tools
# ./add_install_client –c server1:/export/config –p server1:/export/config client1 sun4u
Name Services / Using
/etc/rc2.d/S72inetsvc script -- Starts DNS during system boot.
/etc/rc2.d/S71rpc script -- Starts NIS & NIS+ during system boot
/etc/rc2.d/S72directory script -- Starts iPlanet Server during system boot.
Name Services -- DNS, NIS, NIS+, LDAP
The name service switch file determines which services a system users to search for information and in which order the name services are searched. All Solaris OE systems uses the /etc/nsswitch.conf file as the name service switch file. The nsswitch.conf is loaded with the contents of a template file during the installation of the Solaris OE depending on the name service that is selected.
Name Service Name Service Template
Local Files /etc/nsswitch.files
DNS /etc/nsswitch.dns
NIS /etc/nsswitch.nis
NIS+ /etc/nsswitch.nisplus
LDAP /etc/nsswitch.ldap
Configuring the Name Service Cache Daemo (nscd)
The nscd daemon is a process that provides a cache for the most common name service requests. The /etc/nscd.conf file controls the behavior of the nscd daemon. The nscd daemon provides caching for passwd, group, hosts, ipnodes, exec_attr, prof_attr and user_attr databases. Each line specifies either an attribute and a value or an attribute, a cache name, and a value.
# /etc/init.d.nscd stop (or) start
The getent command provides generic retrieval interface to search many name service database. As a system administrator, you can query name service information sources with tools, such as the
ypcat NIS namespace
nslookup DNS
ldaplist LDAP
Bt these tools are not consulting nsswitch.conf file. Whereas getent command searches the information sources in the order in which they are configured in the name service switch file. So if there is any error in the file will be identified with this command.
getent database [key]…..
database -- The name of the database to be examined. This name can be passwd, group, hosts, ipnodes, services, protocols, ethers, networkds, or netmasks.
# getent passwd lp
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
# getent group 10
staff::10:
# getent hosts sys44
192.168.38.44 sys44 loghost (loghost will be absent if the NIS is searched first)
Replace a Disk Drive in solaris
Use this procedure to replace a failed disk drive in a running cluster.
1. Does replacing the disk drive affect any LUN's availability?
If no, proceed to Step 2.
If yes, remove the LUNs from volume management control. For more information,
see your Solstice DiskSuite/Solaris Volume Manager or VERITAS Volume Manager
documentation.
2. Replace the disk drive in the storage array.
For the procedure about how to replace a disk drive, see the Sun StorEdge
D1000 Storage Guide.
3. Run Health Check to ensure that the new disk drive is not defective.
For the procedure about how to run Recovery Guru and Health Check, see the Sun StorEdge RAID
Manager User's Guide.
3.
Does the failed drive belong to a drive group?
If no, proceed to Step 5.
If yes, reconstruction starts automatically. If reconstruction does not start automatically for any reason,
then select Reconstruct from the Manual Recovery application. Do not select Revive. When
reconstruction is complete, skip to Step 6.
4.
Fail the new drive, then revive the drive to update DacStore on the drive.
For the procedure about how to fail and revive drives, see the Sun StorEdge RAID Manager User's Guide.
5.
If you removed LUNs from volume management control in Step 1, return the LUNs to volume management
control.
How to Configure System Messaging
The syslog system messaging features track system activities and events. You can manually generate log messages by using the logger command. The syslog function, the syslogd daemon, and input from the /etc/syslog.conf file work together to facilitate system messaging for the solaris 9 OE.
The /etc/syslog.conf file
This file consists of two tab-separated fields: selector and action. The selector field has two components, a facility and a level written as facility.level. Facility represent categories of system processes that can generate messages. Levels represent the severity or importance of the message. The action field determines whether to send the message.
*.err /var/adm/messages -- Error messages for all facilities are sent to the /var/adm/messages
Only use tabs as white space in the .etc.syslog.conf file. The Solaris OE accesses the /usr/include/sys/syslog.h file to determine the correct facility.level sequencing order.
Selector Fields (facility) Options
kern Messages generated by the kernel
user Messages generated by user processes and don’t have default priority for messages
daemon System daemon, such as the in.ftpd and the telnetd daemon
auth The authorization system, including the login, su, and ttymon commands
syslog Messages generated internally by the syslogd daemon
lpr The line printer spooling system, such as the lpr and lpc commands
news Files reserved for the USENET network news system
uucp The UNIX to UNIX copy (uucp) system does not use the syslog function
cron The cron and at facilities, including crontab, at, and cron
local0-7 Fields reserved for local use.
mark The time when the message was last saved and produced by the syslogd daemon
* All facilities, except the mark facility.
You can use the asterisk (*) to select all facilities (for eg. *.err); however, you cannot use * to select all levels of a facility (for eg. Kern.*)
The levels in descending order of severity
Selector Fields (level) Options
Level Priority Description
emerg 0 Panic conditions that are normally broadcast to all users
alert 1 Conditions that should be corrected immediately
crit 2 Warnings about critical conditions, such as hard device errors
err 3 Errors other than hard device errors
warning4 Warning messages
notice 5 Non-error conditions that might require special handling
info 6 Informational messages
debug 7 Messages that are normally used only when debugging a program
none 8 Messages are not sent from the indicated facility to the selected file
Not all levels of severity are implemented for all facilities in the same way.
Action Field -- The action field defines where to forward the message. This field can have any one of the following entries
/filename The targeted file
@host The @sign denoted that messages must be forwarded to a remote host.
Messages are forwarded to the syslogd daemon on the remote host
user1, user2 The user1 and user2 entries receive messages if they are logged in
* All logged in users will receive messages
You must restart the syslogd daemon whenever you make any changes to /etc/syslog.conf file
# /etc/init.d/syslog stop (or) start
# pkill –HUP syslogd
Syslogd started -- It’s starting the M4 Macro Processor -- M4 will read the /etc/syslog.conf file.
Configuring syslog Messaging
The inetd daemon uses the syslog command to record incoming network connection requests made by using TCP. You can modify the behavior of the inetd daemon to log TCP connections by using the syslogd daemon. The daemon facility and the notice message level are supported by inetd.
Use the –t option as an argument to the inetd daemon to enable tracing of TCP services. When you enable the trace option for the inetd daemon, it uses the daemon.notice to log the client’s IP address and TCP port number, and the name of the service. Add the –t option to the entry which activated the inetd daemon in the inetsvc script located in the /etc/init.d directory
# grep inetd /etc/init.d/inetsvc
/usr/sbin/inetd –s –t -- You must restart the inetd daemon for the new option to take effect
# grep daemon.notice /etc/syslog.conf
*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages
Monitoring a syslog File in Real Time
The tail –f command holds the file open so that you can view messages being written to the file by the syslogd daemon.
# tail –f /var/adm/messages -- Press Ctrl+c to exit
Adding One-Line Entries to a System Log File
logger [-i](logs PID) [-f file] [-p priority] [-t tag] [message]
# logger system rebooted -- If the user.notice field is configured in the /etc/syslog.conf file, the message is logged to the file designated for the user.notice selector field
# logger –p user.err system rebooted -- Changing the priority of the messages to user.err route the messages to the /var/adm/messages file as indicated in the /etc/syslog.conf file
# logger –i –p2 “crit”
/dev/sysmsg -- Console
How to Performe Smartcard Authentication
# /usr/dt/bin/sdtsmartcardadmin & -- To start smartcard console
ATR – Answer to reset Number (unique)
# smartcard –c disable -- Disabling smartcard operation
# smartcard –c admin -- Display the current client and server configuration
# /etc/smartcard/opencard.properties -- Config File
installation of Vmware ESX 3.5 server and client / Vmware ESX 3.5 server and client installation
Vmware Interview questions and answers, vmware CBT, vmware FAQ, vmware e-books, vmware MNC interview questions and answers, vmware Video, vmware tips and tricks @ http://sunadmintools.blogspot.com/
Vmware ESX 3.5 server and client installation complete presentation click the next button and wait for the ppt to get downloaded completely.
Click the full icon in the botton to see the complete e-book in full mode.
If you like my blog do comment me
Donate if this blog really help you to build your career.
share documents if you have any more stuff with you
share the blog with friends for better result.
Solaris commands / VI Editor
Inserting and Appending Text
a - Append text after the cursor
A - Appends text at the end of the line
i - Inserts text before the cursor
I - Inserts text at the beginning of the line
o - Opens a new line below the cursor
O - Opens a new line above the cursor
:r
Key Sequence for the VI Editor
n, left arrow or backspace Left one characters
j or down arrow Down one line
k or up arrow Up one line
l, right arrow or spacebar Right one character
w Forward one word
b Back one word
e To the end of the current word
$ To the end of the line
0 (zero) To the beginning of the line
^ To the first non whitespace character on the line
Return Down to the beginning of the next line
G Goes to the last line of the file
1G Goes to the first line of the file
:n Goes to the line n
nG Goes to the line n
Ctrl F Pages forward one screen
Ctrl D Scroll down one half screen
Ctrl B Pages back one screen
Ctrl U Scrolls up one half screen
Ctrl L Refreshes the screen
Editing files using the VI editing commands
R Overwrites or replace characters to the right of the cursor
C Changes or overwrites characters to the end of the line
s Substitute a string for a character at the cursor
x Deletes a character at the cursor
dw Deletes a word or part of the word to the right of the cursor
dd Dletes the line containing the cursor
D Deletes the line from the cursor to the right end of the line
:n,nd Deletes the line n through n
Using the Text Changing Commands
u Undoes the previous command
U Undoes all changes to the current line
. Repeats the previous command
Search and Replace Command
/string Searches forward for the string
?string Searches backward for the string
n Searches the next occurrence of the string
N Searches for the previous occurrence of the string
:%s/old/new/g Searches for the old string and replace it with the new string globally
Using the text copying and Text Pasting Commands
yy Yanks a copy of a line
p Puts yanked or deleted text under the line containing the cursor
P Puts yanked or deleted text before the line containing the cursor
:n,n co n Copies lines n through n and puts them after line n
:n,n m n Moves lines n through n to line n
Booting process in Solaris
Booting process in Solaris can be divided in to different phases for ease of study . First phase starts at the time of switching on the machine and is boot prom level , it displays a identification banner mentioning machine host id serial no , architecture type memory and Ethernet address This is followed by the self test of various systems in the machine.
This process ultimately looks for the default boot device and reads the boot program from the boot block which is located on the 1-15 blocks of boot device. The boot block contains the ufs file system reader which is required by the next boot processes.
The ufs file system reader opens the boot device and loads the secondary boot program from /usr/platform/`uname –i`/ufsboot ( uname –i expands to system architecture type)
The boot program above loads a platform specific kernel along with a generic solaris kernel
The kernel initialize itself and load modules which are required to mount the root partition for continuing the booting process.
SSA - what are raid0,raid1 and raid5
Q) what are raid0,raid1 and raid5
A) Raid 0 is concatenation or stripping
Concatenation means writing data in disk one after another
Stripping means writing data of 32kbs interlease value in to disk
Raid 1 – mirroring that means writing data on two disk parallely or duplicatiung the data on two disk.
Raid 5 – stipping with parity the data of 2 disk is duplicated in the third disk with parity information
SSA - How to set environment variable in NVRAM
# nvalias /pci---/rarp – to set scsi for booting of client
# nvalias net dhcp – to boot from dhcp
# nvunalias net – remove the alias
SSA - How to see all the informations of the hardware related from bootprom (OBP)
# banner
or
# prtconf
SSA - How do you set a default boot device from the boot prom
# setenv boot-device disk
Boot-device=disk
# reset - To make the changes.
SSA How to see which kernel version and artitecture used by the system.
# isainfo -v :- To see kernal version and 32 bit or 64 bit system and artictect
SSA How to make processor 3 online when you have more then 4 processor and processor 3 is offline?
# psrinfo –a 3 online :- To make processor 3 online
SSA How to make processor 4 number offline when you have more then 4 processors.
# psrinfo –V :- To check the status and then
# psradm –f 4 offline - To make processor number 4 offline
SSA How to change processor operation status in solaris
# psradm –a –n :- To set all processor available on the system to online
# psradm –f 2 3 :- To make processor 2 and 3 offline, if you have multiple processors
How do you set a deafaulr boot device from the boot prom
# setenv boot-device disk
Boot-device=disk
# reset - To make the changes.
Tags : solaris interview questions and answers
2203 How to see all the informations of the hardware related from bootprom(OBP)
# banner
or
# prtconf
Big Admin - Solaris Tips and Tricks
I had to use the following tips time to time so I am posting them here to save me the time to look for them again (and avoid the possibility of the original sites going off-line).
1. Set up your /etc/hosts file.
It should look something like this:
127.0.0.1 localhost
192.168.0.150 solaris-box-1 solaris-box-1.yourdomain.com loghostMake sure the second line has the correct IP address, hostname, and FQDN. The first line is the loopback entry. Along with #5, Solaris will know its name and IP address.
2. Create or edit /etc/nodename
Contains the hostname of the computer (same as hostname.hme0).
# cat nodename
solaris-box-1
3. Create or edit /etc/defaultrouter
Surprisingly enough, this file contains the IP address of your default router (or gateway). When you reboot and the network initialization scripts run, it will add a default route to the IP address in this file.
# cat defaultrouter
192.168.0.1
Now it knows about it's own network parameters and it's time to get it to use DNS. The next steps will tell it to use other nameservers. If you want to set up a nameserver on the local machine, see the man page for named.
4. Edit /etc/nsswitch.conf
If you haven't edited this file before, it should look suspiciously like like this:
passwd: files
group: files
hosts: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the system will
# figure it out pretty quickly, and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: filesAdd the word 'dns' after 'files' on the 'hosts' line:
passwd: files
group: files
hosts: files dns
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the system will
# figure it out pretty quickly, and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: filesNow it knows to query a nameserver when looking up a name. Next we have to tell it what nameservers to use:
5. Create or edit /etc/resolv.conf
Here you tell it three things:
- What domain we're in
- Specify any additional search domains
- What the nameservers are (it will use them in the order you put them in the file)
When you're done it should look something like this:
# cat resolv.conf
domain yourdomain.com
search yourdomain.com
search client1.com
nameserver 192.168.0.9
nameserver 192.168.0.11For more information, see the man page for resolv.conf.
6. Edit /etc/hostname.hme0
7. RebootThis file should contain the hostname of your machine, without the domain name. So, if the FQDN (Fully Qualified Domain Name = hostname + domain name) is solaris-box-1.yourdomain.com, the file should look like this:
# cat hostname.hme0
solaris-box-1This assumes that your Ethernet adatper is hme0, the default device name for the first Ethernet adapter.
# sync;sync;sync
# reboot
8. Change IPs
UNIX Shell: All Primary shells (sh,ksh,csh)
Function: Use ifconfig to change your IP address immediately. Edit your /etc/hosts file to change it permanently.
Syntax: Immediate change: ifconfig interface new IPaddress subnet mask
Permanent change: vi /etc/hosts
interface Specifies the network interface, e.g. hme0 for 100 Mbps or le0 for 10 Mbps.
new IPaddress Specifies the new IP address that you want to assign the computer.
subnet mask Specifies the subnet mask for your local network.
File Name: hosts Directory: /etc Type: External
ifconfig hme0 192.168.1.250 255.255.255.0 Sets the IP address to 192.168.1.250 on interface hme0.
ifconfig le0 192.168.1.250 255.255.255.0 Sets the IP address to 192.168.1.250 on interface le0
9. Recover ROOT password
Note the root partition;
Solaris uses
* /dev/dsk/c0t0d0s0 on the Ultra5/10 and Blade 100
* /dev/dsk/c0t1d0s0 for Blade 1000.
Press the STOP and A keys simultaneously, or, on an ASCII terminal or emulator, send a
Boot single-user from CD-ROM (boot cdrom -s) or network install/jumpstart server (boot net -s). For CD media use the CD-ROM labeled "Installation". I prom pssword is set you need to know it
Mount the root partition on "/a". "/a" is an empty mount point that exists at this stage of the installation procedure. For example:
#mount /dev/dsk/c0t0d0s0 /a
If the mount command fails and since "/a" always exists, then you either typed in the wrong device, OR the system is seeing the root partition as something else.
Do a "ls /tmp/dev/dsk" and see what is there. "c0t6" things are the CD-ROM, what is left is what one needs to try. On a Blade 1000/2000, choose /dev/dsk/c1t1d0s0, and execute: #mount /dev/dsk/c1t1d0s0 /a
Set your terminal type so you can use a full-screen editor, such as vi. You can skip this step if you know how to use "ex" or "vi" from open mode.
* If you're on a sun console, type "TERM=sun; export TERM";
* If you are using an ascii terminal or terminal emulator on a PC for your console, set TERM to the terminal type for example: TERM=vt100; export TERM.
Edit the passwd file, /a/etc/shadow (or perhaps in older versions, /etc/passwd) and remove the encrypted password entry for root.
Type: "cd /; then "umount /a"
Reboot as normal in single-user mode ("boot -s"). The root account will not have a password. Give it a new one using the passwd command. PROM passwords: Naturally, you may not want anyone with physical access to the machine to be able to do the above to erase the root password. Suns have a security password mechanism in the PROM which can be set (this is turned off by default). The man page for the eeprom command describes this feature.
If security-mode is set to "command", the machine only be booted without the prom password from the default device (i.e. booting from CD-ROM or install server will require the prom password). Changing the root password in this case requires moving the default device (e.g. the boot disk) to a different SCSI target (or equivalent), and replacing it with a similarly bootable device for which the root password is known. If security-mode is set to full, the machine cannot be booted without the prom password, even from the default device; defeating this requires replacing the NVRAM on the motherboard. "Full" security has its drawbacks -- if, during normal operations, the machine is power-cycled (e.g. by a power outage) or halted (e.g. by STOP-A), it cannot reboot without the intervention of someone who knows the prom password.
"I've almost just reinstalled Solaris to get the network settings fixed!" Ya, sometimes you can get alittle confused and irritated. Whether it's a new Linux distro, or diffrent UNIX OS, everyone puts their network configuration in diffrent places and learning each systems setup can be a pita. So, what if you don't even wanna bother learning all the network configuration stuff and what files does what... what if you could just re-run the networking configuration and have it all sorted out? You can! Solaris has a nifty command that can reset the base networking and configuration to a clean system: "sys-unconfig". If you buy a pre-installed system from Sun or a VAR, what they will generally do is install Solaris, customize the install as needbe and then run "sys-unconfig" before putting the system in the box and shipping it out. The command will scratch the networking configuration (most of it anyway), the root password, time zone, etc. Once sys-unconfig finished cleaning out the files it will immediately halt the system (shut it down). Next time you boot the system it will prompt you for all the networking information, time zone, locale and a new root password. This is the "quick-no-hassle" reconfiguration method. Generally we do not recommend this as ideal, but it will do the trick. If you plan on selling a pre-installed system or you are moving your system to a new network where all the info is changing, this is the command to use. Just use it carefully.
"I know root shouldn't login remotely, but I really want too!" Logging into a system via telnet, ftp, or ssh is just bad... very bad. However, some times people think they need to do this or they simply don't care about security. If you really wanna drop your pants like this, edit: /etc/default/login. In this file, you'll see a line for CONSOLE. To allow root to log in via telnet or ftp just comment out this line and your done. To allow root login via SSH you need to edit a diffrent file: /etc/ssh/sshd_config. Change the value of PermitRootLogin from "no" to "yes" and restart SSH via "svcadm restart ssh". The SSH configuration file is just the same as Linux since Solaris uses OpenSSH. Please note, that allowing root to log in remotely is a massive security risk and needlessly stupid, don't do this unless you absolutely must.
"How do I set and make the default gateway persistant across reboots?" The default gateway is easy to configure, just put the IP address of the default gateway in /etc/defaultrouter. If this file doesn't exist just create it and add the IP. The IP address of the gateway should be the ONLY thing in this file, nothing else. Typically you should just use echo, like this: "echo 10.0.0.255 > /etc/defaultrouter". Once you've changed the file you can restart the physical network interfaces to make the changes effective without a reboot ("svcadm restart physical").
How do I set or change my IP address? Setting and changing IP addresses on Solaris is a snap. Just add the IP and hostname that you wish to use to /etc/hosts. Then put the hostname (by itself) in teh /etc/hostname.(interface) file. Then just restart the physical networking via SMF ("svcadm restart phsyical") and your done! Example: "echo '10.0.0.25 solarisrox' >> /etc/hosts; echo 'solarisrox' > /etc/hostname.hme0" assuming that hme0 was the interface you wanted to use. Don't worry about this changing the hostname for the whole workstation, the hostname for the system is kept in /etc/nodename. You can add the default gateway as we discussed just above. If you need to specify a non-standard subnet netmask you can add it to /etc/netmasks. You can have as many subnet masks in the /etc/netmasks file as you like, one per line, just follow the instructions at the top of the file.
How do I configure DHCP? DHCP is pretty easy to configure, just create 2 empty files: /etc/hostname.(interface) and /etc/dhcp.(interface). If you are using HME0 you could do this: "echo "" > /etc/hostname.hme0 > /etc/dhcp.hme0". You might want to wipe out information that might conflict like the /etc/defaultrouter file if you created one. Once you've got these two empty files ready just restart the physical network to make the changes effective without a reboot ("svcadm restart physical"). If you want to customize the properties of the DHCP agent you can check out the " System Administration Guide: IP Services" manual. Remember that DHCP settings take acouple seconds to be retrieved from the server so if you reset the physical interfaces as mentioned above and you notice that nothing happened, just wait a couple seconds (30 secs is the default timeout).
I can't figure out what the network interface is called! Linux sort of makes network interface naming easy because typically interfaces are named "eth0", "eth1", so on and so forth. In Solaris, however, the name of the interface is decided by the interface driver. For instance, the onboard ethernet of a Sun Ultra workstation uses the HME (Happy Meal Ethernet, also more boringly called Hundred Meg Ethernet) driver and so the first instance is "hme0". You can look at the device mappings to driver names using "prtconf -D". In general, Solaris will find your network device and try to configure it so generally just checking "ifconfig -a" is enough to find it.
My l337 workstations network device isn't frickin' support!?! Sadly there are lots of networking devices that aren't officially supported (right now anyway, OpenSolaris hopes to change this). Thankfully there are tons of really kool Solaris developers that have been creating open source drivers! Check out these free NIC drivers by Masayuki Murayama! Grok google for drivers, you just might find your l337 gear really does have drivers avalible, they just aren't in Solaris right now.
There ya go.. some quick Solaris networking tips. As always, check out docs.sun.com's Solaris10 manuals for help and details.
Resetting the SYSTEM user password
(Re) boot the system with:
b -fl 0,1 dka0
(Replace DKA0 with whatever is appropriate for your installation)
At the SYSBOOT console:
SYSBOOT> SET/STARTUP OPA0:
SYSBOOT> SET WINDOW_SYSTEM 0
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE
$ SPAWN
$ @SYS$SYSTEM:STARTUP
$ SET DEFAULT SYS$SYSTEM:
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY SYSTEM /PASSWORD=newpass
UAF> EXIT
$
disable all logins? - How to
# cat /etc/hosts.deny
ALL: ALL: /usr/ucb/finger -l @%h 2>&1 | /bin/mailx -s
"Someone is knocking at `hostname`" unixgeek@somecompany.co
ps (Process list) command in Solaris - Long format
$ /usr/ucb/ps -wwxaa
PID TT S TIME COMMAND
0 ? T 0:20 sched
1 ? S 0:01 /etc/init -
2 ? S 0:00 pageout
3 ? S 1502:02 fsflush
49 ? S 0:00 /usr/lib/sysevent/syseventd
51 ? S 0:00 /usr/lib/sysevent/syseventconfd
15323 ? S 1:04 /usr/local/bin/.
ZFS file system
ZFS
On-Disk Data Walk in the OpenSolaris Developer Conference Proceedings.
history of sloaris | solaris history
UNIX is plural. It is not one operating system but, many implementations of an idea that originated in 1965. As a system administrator, you need to understand the history of the UNIX operating system where it came from, how it was built, and where it is now. Understanding the various versions of UNIX and its origins makes it clear why UNIX became known as a somewhat hostile operating system. For example, UNIX was not developed by a single company with a large marketing organization driving the user interface. (In other words, it did not follow the development path of, say, Microsoft Windows.) On the other hand, UNIX was not invented by hackers who were fooling around; it grew out of strong academic roots. The primary contributors to UNIX were highly educated mathematicians and computer scientists employed by what many people feel is the world’s premier industrial research center, Bell Laboratories. Although knowledgeable and experienced in their own right, these developers maintained professional contacts with researchers in academia, leading to an exchange of ideas that proved beneficial for both sides. Understanding the symbiotic relationship between UNIX and the academic community means understanding the background of the system’s inventors and the history of interactions between universities and Bell Laboratories.
HOW IT ALL BEGAN
It all began at Bell Labs, the research lab of AT&T, one of the largest and most powerful companies of our time. Ironically, AT&T was not interested in developing and selling computers or operating systems. In fact, the U.S. Department of Justice did not allow AT&T to sell software. However, AT&T’s existing systems, made up of people and paper, were in danger of being overwhelmed in the boom of the 1960s. By the 1970s, the phone business was in jeopardy. Out of desperation and need, Ken Thompson of AT&T set out to develop what no computer company was ready to provide a multiuser, multiprocessing operating system to be used in-house for its own information processing department. Specifically, the goal was an operating system to support several programmers simultaneously in a more hospitable environment. What follows is an account of major dates and events in the development cycle of the UNIX operating system.
1965–1969
In 1965, Bell Labs joined with MIT and General Electric in a cooperative development of Multics, a multiuser interactive operating system running on a GE 645 mainframe computer. However, unhappy with the progress in the development of a system that was experiencing many delays and high costs, Bell Labs dropped out of the development of Multics in 1969.
In 1969, Ken Thompson, exposed to Multics at Bell Labs, met up with Dennis Ritchie, who provided a Digital Equipment Corporation PDP-7 minicomputer to continue the development of an operating system capable of supporting a team of programmers in a research environment. After they created a prototype, Thompson returned to Bell Labs to propose the use of this new operating system as a document preparation tool in the Bell Labs patent department. The new operating system was named UNIX to distinguish it from the complexity of Multics. Efforts to develop UNIX continued, and UNIX became operational at Bell Labs in 1971.
The first version of UNIX was written in assembly language on a PDP-11/20. It included the file system, fork, roff, and ed. It was used as a text-processing tool for the preparation of patents.
1970–1972
During the early 1970s, UNIX began to gain popularity throughout Bell Labs, and as word of the new operating system spread, universities embraced it. However, although UNIX was viewed favorably by the academic and high-tech sectors, it was with skepticism by the business community. In a move to heighten the popularity of UNIX, AT&T began to license the UNIX source code to universities at a minimal cost. AT&T gave many licensees the software code and manuals, but didn’t provide technical support. By the late 1970s, 70% of all colleges and universities had UNIX. Computer science graduates were using it, even modifying the code to make it more robust. UNIX was written in assembly language and ran primarily on DEC hardware—first on the PDP-7, and then the PDP-11/40, the 11/45, and finally the 11/70, on which it gained wide popularity.
1973–1979
This period became the most significant in the development of UNIX. Ritchie and Thompson had developed the C programming language between 1969 and 1973, and now rewrote the UNIX kernel in the highlevel C language. The operating system could be compiled to run on different computers. Within months, UNIX could be ported to new hardware. Modifications to the operating system were easy. Again, Thompson resonated with members of the academic community who were already using UNIX in many of their system design courses. UNIX, written in a general-purpose language featuring modern commands, began to take off in the areas of word processing and programming.
By this point, UNIX was at version 6. This was the first release of UNIX to be picked up by a commercial firm, Whitesmiths, Inc., which created a commercial copy of version 6 called Idris.
In 1975, Thompson visited Berkeley while on sabbatical, and installed version 6 on a PDP-11/70. It was at this time that two graduate students, Bill Joy and Chuck Haley, got involved with version 6 and later played an important role in the development of the UNIX system at Berkeley. The first project they worked on was the development of the UNIX ex editor.
Joy and Haley began to take interest in the internal operations of UNIX—specifically, the kernel. Joy put together a distribution of UNIX called the Berkeley Software Distribution (BSD). He included enhancements such as the C shell (a C-like interface to UNIX) and the vi editor. 1BSd was released in 1975. By the second release of BSD in 1978, Joy had added virtual memory support, which allowed programs to run even if they required more physical memory than was available at the time. This second edition of BSD had a strong influence on the release of Bell Labs’ version 7 of UNIX, which was released in 1979 and was the last of the “clean” versions of UNIX (produced solely by Bell Labs). Version 7 gave rise to a number of UNIX ports to other platforms, and for the first time, both industry and academia supplied enhancements, which were incorporated into future releases.
In the late 1970s, the United States Department of Defense’s Advanced Research Projects Agency (DARPA) decided to base its universal computing environment on Berkeley’s version of UNIX. In the 4.1 release of BSD, DARPA provided some important performance tune-ups. The fast file system, which provided a way to improve the file system’s performance and prevent file fragmentation, was added in release 4.2.
1982–1983
AT&T formally released a beta version of UNIX to the commercial sector in 1982. In 1983, AT&T released the first true production version of UNIX, naming it System III (Systems I and II never existed). Although it was based on version 7 of UNIX, and thus included some BSD utilities, the release of System III did not include the vi editor or the C shell. Instead, AT&T included the programmer’s workbench.
With the release of System III, AT&T saw a future in UNIX, and soon released System V. (System IV was never seen outside of AT&T.) System V included the editor, curses (the screen-oriented software libraries), and the init program, which was used to start up processes at UNIX boot-up.
In the early 1980s, Joy left Berkeley with a master’s degree in electrical engineering, and became cofounder of Sun Microsystems (Sun stands for Stanford University Network). Sun’s implementation of BSD was called SunOS. Sun extended the networking tools of the operating system to include the Networked File System (NFS), which was to become an industry standard. Sun also did some of the early work in developing windowing software for UNIX. SunOS was first released in 1983.
With workstation products now offered by Sun, UNIX began to gain acceptance in the high-tech arena, especially in computer-aided design and computer-aided engineering (CAD/CAE) environments. The early 1980s saw CAD/CAE become popular. Additional workstation vendors, such as HP and Apollo, began to exploit CAD/CAE capabilities and performance gains over the popular personal computers of the time. These UNIX workstations could outperform PCs and, with UNIX as an operating system, could provide a multiuser environment.
In other business computing environments, however, UNIX was still considered a hostile environment, and did not pose a threat to the mainframes of the time. UNIX had yet to define itself as a user-friendly, triedand-tested operating system. However, it was gaining ground in the areas of multitasking and networking. More important, UNIX was being touted as the operating system that provided portability between different hardware architectures, and as a consequence, software developers were getting excited about UNIX. In theory, a program written in C for UNIX would be portable to any hardware platform running the UNIX operating system.
1984–1987
In 1984, AT&T released System V, release 2, and in 1987, release 3. Release 2 introduced the terminal capability database termcap file, named terminfo, which provided support for various CRT terminals connected to the UNIX system. Other changes included the addition of Streams and Remote File Systems.
1988–1992
In 1988, AT&T shocked the UNIX community by purchasing a percentage of Sun Microsystems, already a leader in the industry. Other hardware vendors saw this as an unfair advantage for Sun, so they quickly formed a consortium group called the Open Software Foundation (OSF). Together, they raised millions of dollars to develop a new UNIX standard to compete against Sun’s.
In a counterstrike, AT&T, Sun, Data General, and Unisys joined forces to start their own organization to fight OSF. This consortium of companies, called UNIX International (UI), was formed to oversee the development of System V standards. OSF and UI turned out to be the two major competing commercial standards for UNIX.
By the late 1980s, AT&T concluded that UNIX was a distraction from the company’s focus on producing hardware. As a result, AT&T formed the UNIX Software LAB (USL), ultimately purchased by Novell in 1992.
In 1992, at the summer UseNIX conference, Berkeley announced it would conclude its development activities at version 4.4 of BSD. Several people who were involved with BSD formed smaller companies to try to continue the development of BSD, but without Berkeley and ARPA, it was not the same.
In the 1990s, BSD and System V dominated the industry, with several vendors providing their versions of one of the two operating systems. Soon UNIX, an operating system meant to provide portability of applications between multiple hardware platforms, was getting out of control. Applications were not portable between UNIX System V, release 3, and BSD. To create even more confusion, hardware vendors were enhancing their versions of BSD and System V.
1993
Sun announced that SunOS, release 4.1.4, would be its last release of an operating system based on BSD. Sun saw the writing on the wall and moved to System V, release 4, which they named Solaris. System V, release 4 (SRV4) was a merger of System V and BSD, incorporating the important features found in SunOS.
As more hardware vendors, such as Sun, began to enter the picture, a proliferation of UNIX versions emerged. Although these hardware vendors had to purchase the source code from AT&T and port UNIX to their hardware platforms, AT&T’s policy toward licensing the UNIX brand name allowed nearly any hardware vendor willing to pay for a license to pick up UNIX.
Because UNIX was a trademark, hardware vendors had to give their operating systems a unique name. Here are a few of the more popular versions of UNIX that have survived over the years:
- SCO UNIX. SCO Open Desktop and SCO Open Server from the Santa Cruz Operation for the Intel platform. Based on System V.
- SunOS. Sun’s early operating system and the best-known BSD operating system.
- Solaris. Sun’s SRV4 implementation, also referred to as SunOS 5.x.
- HP-UX. Hewlett-Packard’s version of UNIX. HP-UX 9.x was System V, release 3, and HP-UX 11i is based on the System V, release 4 OS.
- Digital UNIX. Digital Equipment’s version of OSF/1.
- IRIX. The Silicon Graphics version of UNIX. Early versions were BSD-based; version 6 was System V, release 4.
- AIX. IBM’s System V-based UNIX.Linux. A free UNIX operating system for the INTEL platform; it was quickly gaining a hold in the UNIX community. Versions of Linux became available on Sun, HP, and IBM systems.
With the uncontrolled proliferation of UNIX versions, standards became a major issue. In 1993, Sun announced that it was moving to System V in an effort to promote standards in the UNIX community. With two major flavors of UNIX, standards could not become a reality. Without standards, UNIX would never be taken seriously as a business computing system. Thus, Sun developed BSD, but provided its users with System V, release 4, shrink-wrapped directly from AT&T. In addition, any applications developed by Sun to be added onto UNIX were to be SRV4-compliant. Sun challenged its competitors to provide true portability for the user community.
The GraphicalUser Interface (GUI) was the next wave in the development of the UNIX operating system. As each hardware vendor tried to outdo the others, ease of use became an issue. Again, in this area especially, standards were important. Applications that were to be portable needed a GUI standard. Therefore, Sun and
AT&T started promoting OPEN LOOK, which they jointly developed. Their goal was to create a consistent look and feel for all flavors of UNIX; unfortunately, OSF had its own GUI called OSF/MOTIF. Thus, round two of the fight for standards began, with MOTIF beating out OPEN LOOK.
MOTIF was based on a GUI developed at MIT named the X Window System, which allowed a user sitting at one machine to run programs on a remote machine while still interacting with the program locally. X was, in effect, one way for different systems to interface with each other. X allowed a program run on one computer to display its output on another computer, even when the other computer was of a different operating system and hardware architecture. The program displayed its output on the local machine, and accepted keyboard and mouse input from the local machine, but it executed on the CPU of the remote machine.
The local machine was typically a workstation or terminal called a dedicated X terminal, and was built specifically to run the X Window System. The remote machine might be a minicomputer or server, a mainframe, or even a supercomputer. In some cases, the local machine and the remote machine might, in fact, be the same. In summary, X was a distributed, intelligent, device-independent, operating-system-independent windowing system.
As stated earlier, MOTIF beat OPEN LOOK in the standards war. Sun conceded, and started to provide a package that contained both OPEN LOOK and MOTIF—called the Common Desktop Environment (CDE)—as standard equipment beginning with Solaris 2.5.1.
2001 AND BEYOND
Today, many hardware vendors have buried the hatchet and, for the sake of users, are moving their implementations of UNIX to be SRV4-compliant. SVR4 will clearly be the dominant flavor of UNIX across most major platforms. As all vendors begin to implement SVR4 along with the CDE or GNOME interface, users will begin to see a more consistent implementation of UNIX. In addition, software providers can be ssured that applications written to be SVR4-compliant will be portable across many hardware platforms.
Look for the GNOME desktop around mid-2002 with the release of Solaris 9. This new desktop will eventually replace CDE, and will be much better than CDE in terms of usability, visual design, and core features. Most major UNIX vendors will be moving toward GNOME.
Linux will still be a major player. Now that most of the major UNIX vendors including Sun, HP, and IBM have embraced it, Linux will not go away.
Solaris
No other flavor of UNIX is more popular or has enjoyed a wider user base and cultural following than Sun Microsystems’ Solaris. Since it was founded in 1982, Sun Microsystems’ focus has been on UNIX, and it appears to have no intention of moving away from the UNIX operating system. Sun’s user base has strong loyalty to the company, as well as to the operating system. Sun’s most recent version is Solaris 8, based on System V, release 4. The Solaris operating system is available for the SPARC architecture, Sun’s own processor, and the Intel platform.
MILESTONES IN THE DEVELOPMENT OF SOLARIS
1965 Bell Laboratories joins with MIT and General Electric to develop Multics.
1970 Ken Thompson and Dennis Ritchie develop UNIX.
1971 The B-language version of the operating system runs on a PDP-11.
1973 UNIX is rewritten in the C language.
1974 Thompson and Ritchie publish a paper and generate enthusiasm in the academic community. Berkeley starts the BSD program.
1975 The first licensed version of BSD UNIX is released.
1979 Bill Joy introduces “Berkeley Enhancements” as BSD 4.1.
1982 AT&T first markets UNIX. Sun Microsystems is founded.
1983 Sun Microsystems introduces SunOS.
1984 About 100,000 UNIX sites exist worldwide.
1988 AT&T and Sun start work on SVR4, a unified version of UNIX.
1988 OSF and UI are formed.
1989 AT&T releases System V, release 4.
1990 OSF releases OSF/1.
1992 Sun introduces Solaris, which is based on System V, release 4. SunOS, which is based on BSDF UNIX, will be phased out.
1993 Novell buys UNIX from AT&T.
1994 Solaris 2.4 is available.
1995 Santa Cruz Operation buys UNIXware from Novell. SCO and HP announce a relationship to develop a 64-bit version of UNIX. Solaris 2.5 is available.
1997 Solaris 2.6 is available.
1998 Solaris 7 is available.
2000 Solaris 8 is available.
2001 Solaris 9 in Beta testing Q3.
New Solaris Cluster from Sun Microsystems
Sun Microsystems provides software Solaris Cluster 3.2 11/09, Solaris-based platform Operating System (OS) with high accessibility, cost effective and the most innovative.Solaris Cluster last issued, allowing the increased use of integrated virtualization features and the cost of the Solaris OS, making it easier for customers to run Oracle E-Business Suite, Siebel CRM 8, Single Instance Oracle Database and Oracle Real Application Clusters (RAC) in the Solaris Container.
This tool provides options for greater consolidation of disaster recovery solutions and high accessibility of continuous with Oracle database applications.
"Customers using the Solaris Cluster technology to save costs by optimizing the use of compute resources, consolidate databases and multi-tier applications are also benefiting from cost savings and reliability, accessibility and service capabilities sustainable system better," said Jim McHugh, Vice President Marketing Datacenter , Sun Microsystems through its official statement on Saturday (19/12/2009).
McHugh added, customers can reduce software licensing costs, expenses and cost of system management hardware, and gain greater investment protection with support for more than ten years for each version of Solaris Cluster product.
Solaris Cluster can be used and adapted to the various software components, networks, storage and servers, providing accessibility and ecosystem complete disaster recovery. Juxtaposed with the Solaris OS, Solaris software Cluster 3.2 11/09 expand accessibility and virtualization features of Solaris into a global disaster recovery solution, presents more quickly notice the damage and minimal application downtime in the event of damage.
New release extends support for the Oracle Automatic Storage Management (ASM) with Oracle RAC database to integrate Oracle databases into various types of use Solaris Container. This comprehensive integration utilizing easy ASM usage and performance in a virtual environment that is easily accessible, while providing cost effective solutions.
Solaris Cluster participated in the Olympic and Paralympic Winter Games 2010 to be held in Vancouver, Canada. Sun Canada helps Organizing Committee Olympic and Paralympic Vancouver 2010 Winter Games (VANOC) to the Information Dissemination System / Information Diffusion Systems (ISD) developed by his Atos Origin to support the recording of game time, printing the results match, authentication signature match with the referee and then distribution of game results to the media to be conveyed to the public.
