Solaris as an applicance - Read-only FS & SMF

Hi there,

I hope this is indeed posted in the right area.

In the past my company has produced an application which
runs as an appliance on Solaris 8 & 9.  By running as an
appliance I mean, switch it on, switch it off.  No FS
problems as the system is essentially running in read only. 
The only means by which data is persisted is by using some
of the spare slices to store data.  In our case, we had some
which contained config files and others which contained log
files.  These files would get stored on a
"PRIMARY" and a "BACKUP" slice so even
if the system was turned off during a write operation, the
application would still be able to recover.

Part of the project/application guidelines was to be able to
deploy in a rugged environment using as little
"moving-parts" hardware as possible.  At the start
we used and still use the cPCI architecture and flash
memory.  In the past it has been Sandisk Flash cards and
more recently, due to flash cards no longer working, PQi
flask 2.5" ide drives.

Going from Solaris 2.6 -> Solaris 8 -> Solaris 9
didn't seem to be an issue in changing the rCS file and
mounting root as RO and remounting several parts of the OS
copied into /tmp (Memory) - var, etc, opt etc over existing
disk copies.

The problem I am having now is that Solaris 10 has changed
significantly and SMF is here and causing me issues.  The
issues come down to /etc.  More importantly (I'm guessing)
is /etc/svc/*.

I've had to change the time at which I copy the various file
system sub-directories to /tmp to be in the fs-root method. 
This has worked for every sub-directory except for etc. 
Mounting /etc at this stage completely halts the system
startup.  

Allowing the boot process to continue with /etc as RO only
causes bucket-loads of errors for various services.

Is there any way to change the dependence on /etc, i.e.
change repository/where to point at for SMF related files or
is there a point in the start up sequence where /etc could
be safely replicated across to RW in memory so as the system
can start up?
 
 
This message posted from opensolaris.org
_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

On Wed, Nov 21, 2007 at 03:08:57PM -0800, Brad Mitchell
wrote:
> Hi there,
> 
> I hope this is indeed posted in the right area.
> 
> In the past my company has produced an application
which runs as an appliance on Solaris 8 & 9.  By running
as an appliance I mean, switch it on, switch it off.  No FS
problems as the system is essentially running in read only. 
The only means by which data is persisted is by using some
of the spare slices to store data.  In our case, we had some
which contained config files and others which contained log
files.  These files would get stored on a
"PRIMARY" and a "BACKUP" slice so even
if the system was turned off during a write operation, the
application would still be able to recover.
> 
> Part of the project/application guidelines was to be
able to deploy in a rugged environment using as little
"moving-parts" hardware as possible.  At the start
we used and still use the cPCI architecture and flash
memory.  In the past it has been Sandisk Flash cards and
more recently, due to flash cards no longer working, PQi
flask 2.5" ide drives.
> 
> Going from Solaris 2.6 -> Solaris 8 -> Solaris 9
didn't seem to be an issue in changing the rCS file and
mounting root as RO and remounting several parts of the OS
copied into /tmp (Memory) - var, etc, opt etc over existing
disk copies.
> 
> The problem I am having now is that Solaris 10 has
changed significantly and SMF is here and causing me issues.
 The issues come down to /etc.  More importantly (I'm
guessing) is /etc/svc/*.
> 
> I've had to change the time at which I copy the various
file system sub-directories to /tmp to be in the fs-root
method.  This has worked for every sub-directory except for
etc.  Mounting /etc at this stage completely halts the
system startup.  
> 
> Allowing the boot process to continue with /etc as RO
only causes bucket-loads of errors for various services.
> 
> Is there any way to change the dependence on /etc, i.e.
change repository/where to point at for SMF related files or
is there a point in the start up sequence where /etc could
be safely replicated across to RW in memory so as the system
can start up?

You can run svc.configd and point it at an alternate
repository if you like:

usage: /lib/svc/bin/svc.configd [-np] [-d door_path] [-r
repository_path]
    [-t nonpersist_repository]

My personal suggestion would be instead to hook into the
boot process prior
to SMF starting and mount (or remount) /etc/svc as
writeable.  To do this,
construct /etc/inittab like this:

ap::sysinit:/sbin/autopush -f /etc/iu.ap
sp::sysinit:/sbin/soconfig -f /etc/sock2path
ps::sysinit:/lib/svc/bin/pre_smf >/dev/msglog
2<>/dev/msglog
smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog
2<>/dev/msglog </dev/console

and then fill in /lib/svc/bin/pre_smf as a shell script that
does whatever
you need done prior to SMF startup, which could be to make
/etc/svc writeable.

If you end up unmount or mounting on /etc/svc, keep in mind
that your script
will need to, prior to doing that:

umount /etc/svc/volatile

and then afterward:

[[ -d /etc/svc/volatile ]] || mkdir -m 0755
/etc/svc/volatile
mount -F tmpfs swap /etc/svc/volatile 

to be sure that the SMF non-persistent database remains
rooted in tmpfs.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development.
blogs.sun.com/mws/
_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss

Since some people were interested as far as I can tell on
getting this going, until recently I had no idea what to do.

I'm glad to say I've gone in a completely different
direction all prompted from attending Sun training the other
day to maintain partner status for the company I work for.

On that day I got the developer preview for OpenSolaris
which was a LIVE CD.  The mere thought of booting and
running the OS off a CD was pretty much the solution to the
issue I started at the top.

This has been known already I guess but here are the steps I
went through to make a solaris run completely from memory:

1)       Pack up the contents of a drive ("/")
into a tar file.

2)       Unpack that tar file into a location on the disk,
in this case, I used /solaris.

3)       Modify the /solaris/etc/vfstab file and delete the
“/” entry.

4)       Change the /solaris/lib/svc/method/fs-root and add 
“/sbin/mount –o remount,rw /devices/ramdisk:a /” 
just before the check for the /usr file system.

5)       Change the /solaris/lib/svc/method/fs-usr and
DELETE the section to do with mounting and checking the root
file system.

6)       Change the /solaris/boot/solaris/bootenv.rc file
and remove the “bootpath” parameter.

7)       One thing I needed to do and this is a
characteristic of the “RAMDISK” functionality.  When
booting up off an image, it only allocates a certain amount
of space.  I artificially increase this by creating a file
called “tempfile” under /solaris (the root directory) at
a size of 30mb.  I then added to the fs-root script to
delete this file after remounting rw.

8)       Create the image by performing the command:
/boot/solaris/bin/root_archive pack <image_file>
/solaris

9)       Add an entry to GRUB to give the option to boot
from the new image file.  Do this by editing the menu.lst
file located under /boot/solaris/grub.  Keep the kernel the
same, as the default boot up entry.  The new “module”
entry points at the archive created in step (8).  I just put
this archive file under /platform/i86pc on the disk and
called it boot_archive_ro.  Example of entry:

title Solaris 10 8/07 s10x_u4wos_12b X86 READ ONLY
kernel /platform/i86pc/multiboot
module /platform/i86pc/boot_archive_ro

-----------

I still have a few things to do such as cutting the file
system down more, adding SSH, adding other software
packages, but the main work has been done and it boots up
without any errors whatsoever.

Another thing I'll probably do is mount the root disk
(/dev/dsk/c0d0s0) to /mnt as read only and copy files I may
want to change such as the hosts, hostname, nodename,
gateway files etc since I don't want to have to rebuild the
boot_archive every time I rename the host, not that this
gets done that often, but if you have 20 machines with
different host names, its the last thing I want to do.

Hope others find this helpful.  Thanks to anyone who offered
help.
 
 
This message posted from opensolaris.org
_______________________________________________
appliances-discuss mailing list
appliances-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/appl
iances-discuss