SNEEP FAQ	Frequently Asked Questions about SNEEP

	sneep_FAQ.txt 1.20   08/16/05 07:10:54


What is sneep ?
	
	SNEEP - Serial Number in EEPROM

	Sneep provides a software-accessible Chassis Serial Number (CSN)
	for virtually all Sun Solaris hardware platforms.
	Sneep uses the system EEPROM for persistent storage of 
	the Chassis Serial Number and other important user-defined data
	such as asset, contract, or location information.

	Without this program, only certain Sun platforms which support the
	"setcsn" and "showplatform" programs (from System management 
	Service [SMS] 1.4) have a mechanism to maintain a software-accessible 
	serial number.

	The presence of the software-accessible serial number and other 
	service-related information can significantly simplify
	activities related to system service and asset management.

	Sneep can also reference and update the serial number in the
	configuration files for "explorer" and "CST" 
	(Configuration Service Tracker), and can create a special 
	tracking event in CST for the serial number.


Where can I get a current copy of sneep?

	sneep is publicly available for download at
		Sun Download Center	http://www.sun.com/download
			Category -> Systems Administration / Systems Management
			or
			Downloads A-Z  -> S -> Sneep
			or
			http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=SNEEP-2.5-SOL-F&TransactionId=try


	As of 200508 Sneep is available internally at
		http://webhome.east/mshon/solutions/sneep


What support is provided for sneep ?
	
	At this time the Sun solution center and/or Sun internal servicedesk
	will not accept calls for sneep.
	
	Sneep support is provided by the developer on a best-effort basis.

	Send problems, RFEs, and clever uses for sneep to
		sneep-support@sun.com

	To learn about new releases and features, subscribe to
	the NetAdmin alias
                sneep-announce-ext@sun.com
	or send your request to join sneep-announce to the sneep-support alias.

	Sun employees may subscribe customers to this alias if they are
	active users of sneep.


Are there any presentations available for sneep 
which I can use to indoctrinate my team mates?
	
	Yes. The package documentation directory contains one or more
	presentation PDF files.  Both PDF and Star Office versions are
	available from the support alias: sneep-support@sun.com

	Sun fonts may be necessary for proper display and formatting
	of the Star Office versions.

	The package Documentation directory is included in the
	downloaded package file. Extract the contents:
		zcat SUNWsneepX_RY.tar.Z | tar xvf -

	The documentation is available in
		SUNWsneep/reloc/Docs
	After package installation, the same documents are available in
		/opt/SUNWsneep/Docs



How did it come to be called "sneep" ?

	The first version of this program implemented only the
	"setcsn" and "showplatform" Command Line Interface (CLI) introduced
	in Sun System Management Services 1.4 (SMS).  As these are 
	program names from SMS, they could not be used.

	An hour or so was spent trying to come up with something that
	incorporated EEPROM and serial numbers , and was pronounceable
	and not too hard to remember.  "sneep" seemed to meet the
	requirements much better than the various words and acronyms 
	which came to mind.

	Technically-minded people generally seem to like the name, and
	quickly start using it as a verb (sneeping the system) and
	making puns about not being able to "sneep at night".


Does sneep require special permissions?

	Superuser permission is required to set any values, but any user can
	retrieve the values. This is controlled by the "eeprom" command.


Does sneep validate the serial number, manufacturing date and location, etc.?

	No.
	There are wide variations in the format used for serial number
	and many different platforms. The rules for encoding this information
	are not available to the author.
	As a result, sneep cannot validate the serial number, but sneep
	does make an effort to ensure that it is approximately the right
	length and does not have any obviously invalid characters in it.
	

The serial number should be read-only. Can sneep prevent changes to it?

	Not really.
	Sneep is a simple utility which depends on the services of the
	"eeprom" command and the semantics of Open Boot PROM variables.
	While sneep could refuse to make changes to the serial once it has
	been set, there is nothing to prevent a user from directly using
	the "eeprom" command or the OBP "nvedit" commands to alter the data.

	However, there is no obvious reason why anyone should go to the
	trouble of changing the CSN once it has been saved with sneep.
	Having it available is a convenience, not a requirement or a
	license in itself. Changing the value provides no advantage to
	the user and there seems to be little reason to be concerned.

	Even so, root permission is required to make the change in
	Solaris, and sneep will log any such change in syslog.
	Common data-center practices such as restriction of root access
	and the use of centralized system logging will in many cases
	make any changes easy to audit and relatively difficult to hide.

	There have been discussions regarding changes which could be made
	to OBP to make the CSN read-only.  If having a writable CSN someday 
	proves to be a problem, that issue will be addressed.
	For now, we prefer to Keep It Simple.



Where and how is the serial number stored in EEPROM ?

	sneep uses the OBP "nvramrc" variable to store a specially
	formatted "print" command for each tag/value pair. They may look
	odd because the OBP programming language is FORTH and the
	<print> command in FORTH is  <."> e.g.
		." ChassisSerialNumber ABCD1234 " cr

	The "eeprom" command is used very carefully to store and retrieve
	these strings, taking care to preserve any other commands in nvramrc.

	Some people have used the OBP "oem-banner" variable to store the
	serial number or other information. oem-banner has the
	advantage that it is not erased when the OBP defaults are
	restored, but it has very limited size, and it then cannot be
	used for its intended purpose as a banner for OEM users of Sun
	products.  The limited size also makes it difficult to manage
	multiple data items.

	By using the nvramrc we can support many data items if necessary,
	and we have much greater flexibility overall.


Are my settings lost if I restore the eeprom defaults or replace the eeprom? 

	No. 
	Sneep maintains a backup file /etc/default/SUNWsneep in which
	it keeps a copy of all settings.  In case OBP defaults have
	been restored or if the eeprom has been relaced without
	preserving the contents, sneep automatically restores the
	sneep eeprom settings from the backup file when the system is
	rebooted.  
	Alternatively, the data can be recovered simply by asking for
	it with sneep, and then setting the returned value again with
	sneep.

	Sneep has options designed to make it easy to recover data 
	with very little effort, and when the system boots, it will log 
	a message to tell you if the eeprom is not consistent with
	the backup.
	See the manual page for the usage of -T, -d, and -P.
	The User Guide contains a detailed example of data recovery
	procedures and options.

What about OBP firmware updates? Are the sneep settings lost?

	No, not normally. 
	It is possible to lose the eeprom settings in an OBP firmware
	update, but while it once was common, these updates have been
	very reliable and safe for several years.

	Of course, if there is a problem, sneep will automatically
	recover from the backup.


Some of our systems have "use-nvramrc?=false" .  Will sneep work ?
	
	Yes. use-nvramrc? controls whether or not OBP executes commands
	from nvramrc during the boot process.
	Sneep can find the values in nvramrc even if OBP never uses them.

	The only noticeable difference is that with use-nvramrc?=true ,
	the serial number (and any other tags) will print during boot,
	and with use-nvramrc?=false , they will not.
	

How many other tags can I store with sneep?

	That depends on the length of the tags and values.
	In a small eeprom, you could store 16 tag/value pairs if the
	average size of each was approximately 30 bytes. Newer machines
	tend to have larger eeproms.

	The minimum eeprom nvramrc size is just over 500 bytes,
	so sneep limits your total size to that, unless more than that
	is already in use. If that is the case, then you can use no more
	than is already in use, unless you override this safety.

	However- the CST user data has the capability to store more than
	50 common and relevant values like location, contract, rack position,
	address, contact information, etc.
	These can be set individually from the CST GUI, or in larger groups
	using the CST User Data Editor (uded) available from
	Sun Field Customer Advocacy.

	Consider using CST for any user data which does not have to be
	available from OBP when the system is down.

What happens if I override the size limit of the eeprom nvramrc ?

	By default, sneep will prevent you from using too much nvram,
	but most platforms provide more nvram capacity than sneep allows.
	If you are certain that there is more available on your
	particular platform, you can override sneep.  If you need a few
	more bytes than sneep allows by default, there is no danger.

	However, if you exceed the true maximum capacity of the nvramrc, 
	a typical Sparc system will drop into OBP. 
	After that, it may not boot until the eeprom defaults are restored. 
		( OBP> set-defaults )
	A Solaris x86 system may not have an immediate reaction, 
	but may fail to boot later.

	As these are very serious consequences, it is Strongly Recommended
	that you do NOT override the safety limits. If you do so,
	*you* are entirely responsible for any system outage or other damages.
	Sneep takes care to notify you of this.

x86 PC platforms do not have an eeprom.  What does sneep use on Solaris x86?

	Solaris x86 has an eeprom emulation which is managed in a file 
	by the "eeprom" command. By default, it does not have
	an "nvramrc" variable, but is willing to create one for sneep.

	However, it can hold only one tag/value pair at a time.
	Sneep works with these restrictions, but depends on the 
	sneep backup file /etc/default/SUNWsneep to hold values other
	than the Chassis Serial Number.
	
	If the eeprom already contains a tag/value (like serial number)
	and you try to set another tag/value, sneep will report that 
	an additional tag/value could not be stored in eeprom, but it
	does store it in the backup file. If you request the value,
	it will be returned from the backup.

	In this way, you can use sneep for the same tags and in the
	same way that you use it on other systems.  Just be aware that
	the values are not really stored in eeprom, and are "lost" if
	the filesystem is lost.
	Note that if you have been using the "explorer" tool, 
	the backup file will be saved in any explorer files which you
	may have archived. Restoring that file will immediately allow
	sneep to retrieve the values.
	




What differences are there when using sneep with Solaris 10 zones ?

	In the global zone, sneep acts just as it would on any 
	other Solaris domain, and there should be no surprises.

	There are a few differences with non-global zones

	1) The pkgadd installs sneep into the zones successfully 
	   and automatically.
	   You may see some new messages during pkgadd / pkgrm .

	2) The zones don't have access to the EEPROM, or the eeprom command.
		The best sneep can do is to use the backup file instead of
		the EEPROM. It silently avoids using the eeprom.

		A side effect of this is that sneep tags in these zones
		are not persistent across OS upgrades, 
		but nothing in a zone is persistent unless you save and
		restore the zone configuration files.
		This includes the non-global zone's sneep backup file:
			/etc/default/SUNWsneep

	3) Default sneep data in zones depends on when the zones were set up.
		If sneep is installed in the global zone and used before 
		the other zones are created, the zones should get a copy
		of the global zone's backup file, and this gives
		each zone a full set of sneep tags and values.

		However, if the zones already exist when sneep is installed,
		they do not get the backup file and do not have an eeprom,
		so they have to be configured individually.	

		In the global zone, copying the backup file to each zone's
		root area etc/default/SUNWsneep will provide the zones with
		the same sneep data.



Can we install SUNWsneep on a single server and then share it
to other systems using NFS, as we have done for other tools?

	Yes, but...
	sneep is a pkgadd, but technically, it does not have to be
	installed in order to be used.  You can run it directly from 
	the subdirectory in the expanded package if you like.
	So yes, sneep can be used from an NFS mount point.

	However, if it is not installed, the system startup links are
	not installed, and you will lose the boot-time automatic data integrity 
	checking and automatic recovery.

	In some environments these features will significantly reduce the 
	time and effort required for serial maintenance.
	It depends on how common it is to reset the eeprom, or to overwrite
	the explorer or cst configurations.


I tried sneep and it said "Bad String" and refused to do anything.
What is wrong?

	You are probably using a locale setting which involves "UTF-8",
	and have an older version of sneep.
	This is no longer a problem after sneep 2.5_R1.75.
	The default 'tr' program used in sneep did not work in UTF-8 locales.



