Hi, Thanks for the useful information. I will get back after trying few of the options quoted below.
Regards, Chaya -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Richard L. Hamilton Sent: Tuesday, June 16, 2009 3:13 AM To: [email protected] Subject: Re: [osol-discuss] Have read-only mount option for /usr At one time, /usr specifically could be read-only to most systems, except for patching or upgrades. That was so diskless clients would not need their own copy of /usr on a server. Going back far enough in history (before Solaris 2.0, for sure), there was no /var; /var was split out of /usr to enable /usr/ to be read-only, I think. For example, see the following links (SXCE, snv_97): $ ls -l /usr|grep var lrwxrwxrwx 1 root root 10 Sep 13 2008 adm -> ../var/adm lrwxrwxrwx 1 root root 11 Sep 13 2008 mail -> ../var/mail lrwxrwxrwx 1 root root 11 Sep 13 2008 news -> ../var/news lrwxrwxrwx 1 root root 15 Sep 13 2008 preserve -> ../var/preserve lrwxrwxrwx 1 root root 12 Sep 13 2008 spool -> ../var/spool lrwxrwxrwx 1 root root 10 Sep 13 2008 tmp -> ../var/tmp The OS probably doesn't care if /usr is read-only, and most non-patching/non-upgrade utilities probably don't either. I think running purely diskless is still sort of supported (network booting is supported), but some particular configurations ("autoclient", I think one was called) AFAIK haven't been for awhile, so for just what purposes /usr could be safely read-only may perhaps be a bit less clear than it once was. What may not support splitting out /usr as a separate filesystem (let alone read-only) is newer installers. On Solaris 10 or SXCE, /usr as a separate filesystem under UFS should be no big deal. OpenSolaris (the distro) tends to make simplifying assumptions, and at the moment, while its installer may be easier to use, it may not be anywhere near as flexible. (Where I say installer, also think upgrades.) On SXCE (traditional Solaris installer, more or less, not OpenSolaris installer) snv_97, filesystem(5) says in part: The file system mounted on /usr contains platform-dependent and platform-independent sharable files. The subtree rooted at /usr/share contains platform-independent sharable files; the rest of the /usr tree contains platform-dependent files. By mounting a common remote file system, a group of machines with a common platform may share a single /usr file system. A single /usr/share file system can be shared by machines of any platform. A machine acting as a file server can share many different /usr file systems to support several dif- ferent architectures and operating system releases. Clients usually mount /usr read-only so that they do not acciden- tally change any shared files. That says /usr can be read-only to clients mounting it over NFS; it doesn't actually say anything about it being read-only on the _server_. You really need to provide some hint what you're trying to do for a better answer. For instance, on an embedded system, what one might really want would be a custom distro with special installer and upgrade tools, that divided filesystems into * those only modified during upgrades * those that needed to be modifiable but retained (like /var/preserve, which keeps vi recovery files, which should be retained across reboots, until someone intentionally deletes them) * those that were re-created afresh on each boot (tmpfs filesystems, like /tmp or /var/run) An alternative for an embedded system that had enough resources would be to _load_ from flash, but _run_ from a RAM-based filesystem. That would require less customization to achieve, but would not provide the protection against hostile or buggy situations that read-only would (or at least might) provide. If you're wanting to do something like that perhaps best answered by a custom distro, look at http://www.opensolaris.org/os/community/distribution/ first, to see about existing distros and distro construction. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected] _______________________________________________ opensolaris-discuss mailing list [email protected]
