unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

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 keyword
       can be one of OVERWRITE, APPEND, or PREPEND. The meanings of these key-
       words is described below. synclist accepts comments; a comment is indi-
       cated 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
           overwritten. (Whether an individual file or directory is  overwrit-
           ten  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 can-
           not  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 can-
           not  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.


       tab() allbox; lw(1.698889i)| lw(1.746111i)| lw(2.055000i).  T{ State of
       File

       on Old BE T}T{ State of File

       on New BE T}T{ Resulting State

       on New  BE  T}  UnchangedUnchangedNot  updated  UpdatedUnchangedUpdated
       UnchangedUpdatedNot updated UpdatedUpdatedConflict 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 sys-
       tem 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 syn-
       chronized 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:


       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).   ATTRIBUTE  TYPEATTRIBUTE   VALUE   AvailabilitySUNWluu
       Interface StabilityEvolving


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



SunOS 5.10                        6 Aug 2003                       synclist(4)