synclist(4) File Formats synclist(4)NAMEsynclist - 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.
┌──────────────────┬────────────────────┬──────────────────────┐
│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 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:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Availability │SUNWluu │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │Evolving │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOluactivate(1M), lucreate(1M), lumake(1M), attributes(5),
live_upgrade(5)SunOS 5.10 6 Aug 2003 synclist(4)
