synclist(4)							   File Formats 						       synclist(4)

NAME

       synclist - list of files to be synchronized when changing from one boot environment to another

SYNOPSIS

       /etc/lu/synclist

DESCRIPTION

       The  synclist file lists files that will be synchronized when you switch from one boot environment (BE) to another. The file is part of the
       Live Upgrade feature of the Solaris Operating Environment. See live_upgrade(5) for an overview of the Live Upgrade software.

       The synclist file consists of a list of entries, with two fields per entry. The first field is a pathname, the second a keyword.  The  key-
       word  can  be one of OVERWRITE, APPEND, or PREPEND. The meanings of these keywords is described below. synclist accepts comments; a comment
       is indicated by a hash mark (#) in the first character position on a line.

       The way in which a file is updated is indicated by the keyword in the second field of its synclist entry. All  of  these  operations  occur
       upon the first boot of a newly activated BE. The keywords have the following semantics:

       OVERWRITE

	   Overwrite the contents of a file with the contents of the file of the same name on the previously booted BE. Both directories and files
	   can be specified for overwriting. If you specify a directory, every file in and beneath the listed directory is subject to being  over-
	   written.  (Whether  an individual file or directory is overwritten depends on the outcome of the comparison of file versions, described
	   below.) Following an overwrite operation, a file on a new BE has the same date of creation, mode, and ownership as the file of the same
	   name on the previously booted BE.

       APPEND

	   Append  the	contents  of  a file on the previously booted BE to the contents of the file of the same name on the new BE. Use of APPEND
	   allows for the possibility of duplicate entries in a file. You cannot use APPEND with directories. Following  an  append  operation,  a
	   file  on  a	new BE will have a different modified date and time from the same file on the previously booted BE. The mode and ownership
	   will be the same between the two files.

       PREPEND

	   Prepend the contents of a file on the previously booted BE to the contents of the file of the same name on the new BE. Use  of  PREPEND
	   allows  for	the  possibility of duplicate entries in a file. You cannot use PREPEND with directories. Following a prepend operation, a
	   file on a new BE will have a different modified date and time from the same file on the previously booted BE. The  mode  and  ownership
	   will be the same between the two files.

       The second (keyword) field in a synclist entry can be empty, in which case the OVERWRITE action is assumed.

       In  deciding  when  to  update a file on a newly activated BE, Live Upgrade uses an algorithm illustrated in the table below. In the table,
       "old" refers to a BE relinquishing activated status; "new" refers to a newly activated BE. The "resulting state" occurs when the new BE	is
       first booted.

       +------------------+--------------------+----------------------+
       |State of File	  | State of File      |Resulting State       |
       |		  |		       |		      |
       |on Old BE	  | on New BE	       |on New BE	      |
       +------------------+--------------------+----------------------+
       |Unchanged	  | Unchanged	       |Not updated	      |
       +------------------+--------------------+----------------------+
       |Updated 	  | Unchanged	       |Updated 	      |
       +------------------+--------------------+----------------------+
       |Unchanged	  | Updated	       |Not updated	      |
       +------------------+--------------------+----------------------+
       |Updated 	  | Updated	       |Conflict Indicated    |
       +------------------+--------------------+----------------------+

       When a file is updated on both an old and new BE, as shown in the last row of the table above, Live Upgrade reports the conflict and allows
       you to resolve it.

       Modify the contents of synclist with caution. Adding certain files to synclist might render a BE unbootable. Also, be careful in using  the
       file-inclusion  and  -exclusion	options  in lucreate(1M) in conjunction with changes you might make in synclist. Again, you could render a
       system unbootable or end up with different results from what you expected.

       Switching BEs among different Solaris Operating Environment marketing releases (for example, from a Solaris 9  BE  to  a  Solaris  2.6  BE)
       requires  care.	This  is especially true if you make any modifications to synclist. For example, consider that the last-active BE contains
       Solaris 9 and you want to activate a BE that contains Solaris 2.6. In synclist in the Solaris 9 BE, you have added files that  are  present
       in  Solaris 9 that are not present in Solaris 2.6 or that are no longer compatible with Solaris 2.6. If you forced synchronization with the
       luactivate(1M) -s option, the BE containing Solaris 2.6 might be synchronized with files that might not work under Solaris 2.6.

EXAMPLES

       Example 1: Updating the passwd File

       Consider the following scenario:

       1.  You create a BE, named first.

       2.  You create a new BE, named second, using first as the source.

       3.  You add a new user to first, thereby making an addition to the passwd file in first.

       4.  Using luactivate(1M), you activate second. At this point, Live Upgrade recognizes that the passwd file has been updated  in	first  and
	   not in second.

       5.  When  you boot second for the first time, Live Upgrade, directed by the keyword OVERWRITE in synclist, copies passwd from first to sec-
	   ond, overwriting the contents in the latter BE.

       The result described above obtains with any of the files associated with the OVERWRITE keyword in synclist. If the reverse  had	occurred--
       you  edited  passwd  on	second	and left passwd in first untouched--Live Upgrade would not have modified passwd in second when that BE was
       first booted.

       Example 2: Updating the /var/log/syslog File

       Consider the following scenario:

       1.  You create a BE, named first.

       2.  You create a new BE, named second, using first as the source.

       3.  Logging occurs, adding to the contents of /var/log/syslog in first.

       4.  Using luactivate(1M), you activate second. At this point, Live Upgrade recognizes that /var/log/syslog has been updated  in	first  and
	   not in second.

       5.  When  you  boot  second  for  the  first  time,  Live  Upgrade,  directed  by  the  keyword APPEND in synclist, appends the contents of
	   /var/log/syslog in first to the same file in second.

       The result described above obtains with any of the files associated with the APPEND keyword in synclist. If the reverse	had  occurred--you
       changed /var/log/syslog on second and left /var/log/syslog in first untouched--Live Upgrade would not have modified /var/log/syslog in sec-
       ond when that BE was first booted.

ATTRIBUTES

       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Availability		     |SUNWluu			   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |Evolving			   |
       +-----------------------------+-----------------------------+

SEE ALSO

       luactivate(1M), lucreate(1M), lumake(1M), attributes(5), live_upgrade(5)

SunOS 5.10							    6 Aug 2003							       synclist(4)