Re: beginnings of a diskless boot sequence being committed
:... :portions of the read-only root directory (which strikes as a bit odd in :itself), I was considering union-mounting an MFS filesystem directly :over the read-only root partition. The advantage of this approach It isn't a bad idea, but I dunno how stable the union filesystem is. I prefer to be told when I'm not supposed to write somewhere, though :-) I like keeping things formally read-only if that is what they essentially are. If all else fails, perhaps use of union will allow overriding /etc. Hmmm. :is that you do not have to know ahead of time what portions of the :read-only partition need to be writable -- files get copied into the MFS :partition only if and when they are written to. : :Thoughts? It seems like it would be feasible, and it might even be :possible to do it directly in /etc/fstab without having to put any sort :of cleverness in /etc/rc. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
I have a wacky idea in this vein that I want to pursue sometime -- instead of pushing off lots of symlinks for the various writable portions of the read-only root directory (which strikes as a bit odd in itself), I was considering union-mounting an MFS filesystem directly over the read-only root partition. The advantage of this approach is that you do not have to know ahead of time what portions of the the problem is that i don't know how well unionfs works, and i don't have the ability to fix it. cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
Matthew Dillon wrote: It isn't a bad idea, but I dunno how stable the union filesystem is. Last I heard, it was hopelessly unstable. Well, not hopelessly. We just have to fix the coherency problems in our vfs design. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
On Tue, 26 Jan 1999 07:43:42 +0100 (MET), Luigi Rizzo lu...@labinfo.iet.unipi.it said: the problem is that i don't know how well unionfs works, and i don't have the ability to fix it. Please keep in mind that there are two *different* entiries being discussed here: 1) mount -o union 2) mount -t union (which should really be called `translucentfs'). The former is a generic property of the VFS layer; the latter is a specific filesystem with rather different properties. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
:
: Basically this consists of a bit of code in /etc/rc and, later tonight,
: an /etc/rc.diskless script ( a new script ).
:
:before you reinvent the wheel, have you looked at my code in
:http://www.iet.unipi.it/~luigi/diskless981113/
:
:this is sliglthly pout of date wrt what i have now (an rc.diskless
:file, which essentially contains all rc modifications that you see in
:the above web page)
:
: cheers
: luigi
:---+-
: Luigi RIZZO .
I was basically just cleaning up stuff I've been using for several
months.
Your stuff looks quite similar.
What I propose is that a new kernel sysctl variable be added called
'kern.conf_dir' which the kernel initially sets to nothing.
We modify /etc/rc to detect a diskless boot ( trivial ) ... the
rc.diskless code must run before just about anything else since
the filesystems are all NFS read-only mounts ( and we want to be able
to leave them that way ).
rc.diskless figures out the IP address BOOTP assigned us and changes
kern.conf_dir to point to /conf/$IP.
/etc/rc.conf is then made 'smart' about where to look for rc.conf.local
and /etc/rc is also made smart about where to look for rc.local.
Specifically, if someone has set kern.conf_dir, *that* is where they
look.
Here is the proposed change to /etc/rc.conf ( the tail end of it ). Rather
then look for and source /etc/rc.conf.local, it uses kern.conf_dir.
##
### Allow local configuration override at the very end here ##
##
#
# If the kernel configuration script MIB exists, use it.
sysctl -n kern.conf_dir /dev/null 21
if [ $? = 0 ]; then
conf_dir=`sysctl -n kern.conf_dir`
fi
if [ X$conf_dir = X ]; then
conf_dir=/etc
fi
if [ -f $conf_dir/rc.conf.local ]; then
. $conf_dir/rc.conf.local
fi
/etc/rc must be modified to do something similar when it is ready to
run /etc/rc.local -- it would use ${kern.conf_dir}/rc.local instead.
The only non-standard item is that /etc/rc needs to bypass the standard
disk configuraton code on a diskless boot, because the fstab is the
server's, not the diskless workstation's.
My proposal pretty much keeps intact the rc / rc.conf mechanism and simply
'moves' where rc and rc.conf look for rc.local and rc.conf.local, plus
a little additional magic to allow it to hook all the MFS filesystems
into the system.
Of course, then there are all the files in /conf/IPADDRESS/... actually
not too many, but these require a little more customization depending
on how you like to setup your server.
I haven't committed the whole thing yet, I would like to get feedback on
the general idea before I do so. But it is ready to go now.
#!/bin/sh
# $Id: rc,v 1.170 1999/01/25 04:40:53 dillon Exp $
# From: @(#)rc5.27 (Berkeley) 6/5/91
#...
stty status '^T'
# Set shell to ignore SIGINT (2), but not children;
# shell catches SIGQUIT (3) and returns to single user after fsck.
trap : 2
trap : 3# shouldn't be needed
HOME=/; export HOME
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
export PATH
# BOOTP diskless boot. We have to run the rc file early in order to
# handle read-only NFS mounts, where the various config files
# in /etc often don't apply. rc.diskless may terminate the rc script
# early or it may fall through, depending on the case.
#
if [ -f /etc/rc.diskless ]; then
if [ `/sbin/sysctl -n vfs.nfs.diskless_valid` != 0 ]; then
. /etc/rc.diskless
fi
fi
# Configure ccd devices.
if [ X$skip_diskconf != XYES -a -f /etc/ccd.conf ]; then
ccdconfig -C
fi
...
if [ X$skip_diskconf != XYES ]; then
swapon -a
fi
if [ X$skip_diskconf != XYES -a $1x = autobootx ]; then
...
else
echo Skipping disk checks ...
fi
( a couple of more minor skip_diskconf checks )
# Run custom disk mounting function ( typically setup by rc.diskless )
#
if [ X$diskless_mount_func != X ]; then
$diskless_mount_func
fi
... normal rc continues ...
# Do traditional rc.local file if it exists.
#
if [ -f $conf_dir/rc.local ]; then
echo -n 'starting local daemons:'
sh $conf_dir/rc.local
echo '.'
fi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
: Basically this consists of a bit of code in /etc/rc and, later tonight, : an /etc/rc.diskless script ( a new script ). : :before you reinvent the wheel, have you looked at my code in :http://www.iet.unipi.it/~luigi/diskless981113/ ... I was basically just cleaning up stuff I've been using for several months. me too :) Your stuff looks quite similar. What I propose is that a new kernel sysctl variable be added called 'kern.conf_dir' which the kernel initially sets to nothing. ok, i can only suggest that if you replace the sysctl kern.conf_dir variable with a shell variable as i did, you can achieve a more portable result (this also in light of Jordan's idea of having a 2.2S CD being made... putting patches for diskless into some 'xperimnt' directory would be helpful). Other than that, i have no objections, and i am very glad you raised the issue since i am using diskless machines a lot! I haven't seen how you suggest to buildpopulate the MFS filesystems -- right now i use a rather crude method of putting all the stuff in a tgz archive on the server and expanding it at runtime on the client. I haven't solved the problem with passwords (i.e. i just copy the files from the server. -- this is clearly a security hole, perhaps YP-based solutions would be much better). cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
Luigi Rizzo wrote: [..] I haven't seen how you suggest to buildpopulate the MFS filesystems -- right now i use a rather crude method of putting all the stuff in a tgz archive on the server and expanding it at runtime on the client. I haven't solved the problem with passwords (i.e. i just copy the files from the server. -- this is clearly a security hole, perhaps YP-based solutions would be much better). Didn't Matt have patches for initializing a MFS from a mmap'ed file rather than from swap at some point? Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
: 'kern.conf_dir' which the kernel initially sets to nothing.
:
:ok, i can only suggest that if you replace the sysctl kern.conf_dir
:variable with a shell variable as i did, you can achieve a more
:portable result (this also in light of Jordan's idea of having a
:2.2S CD being made... putting patches for diskless into some
:'xperimnt' directory would be helpful). Other than that, i have no
:objections, and i am very glad you raised the issue since i am
:using diskless machines a lot!
That's what I had originally, but extracting the machine's IP
address is not trivial, and I didn't want to stick:
bootp_ifc=`route -n get default | fgrep interface | awk '{ print $2; }'`
bootp_ipa=`ifconfig $bootp_ifc | fgrep inet | head -1 | awk '{ print $2; }'`
In /etc/rc.conf in roder to synthesize the directory containing
rc.conf.local.
So I have rc.diskless figure it out and sto it in kern.conf_dir, and
rc.conf extracts it from that.
:I haven't seen how you suggest to buildpopulate the MFS filesystems --
:right now i use a rather crude method of putting all the stuff in a tgz
:archive on the server and expanding it at runtime on the client. I
:haven't solved the problem with passwords (i.e. i just copy the files
:from the server. -- this is clearly a security hole, perhaps YP-based
:solutions would be much better).
:
: cheers
: luigi
There isn't much to build. Most of the MFS filesystems start out
empty.
test2:/home/dillon df
Filesystem 1K-blocks UsedAvail Capacity Mounted on
209.157.86.2:/ 63503464471197680%/
209.157.86.2:/usr 508143 320642 14685069%/usr
209.157.86.2:/var63503123334609021%/var
mfs:42 959 70 813 8%/var/run
mfs:447903 596 6675 8%/var/db
mfs:46 31743429200 0%/var/tmp
mfs:48 31743829196 0%/var/spool
procfs 440 100%/proc
mfs:661511 58 1333 4%/dev
mfs:79 31743 198927215 7%/home
/var/run- starts out empty
/var/db - starts out empty
/var/tmp- starts out empty
/var/spool - simple skeleton directory structure
/dev- mount server:/ to a temporary place and use cpio to populate
/home - populate from template ( up to the user, I include a sample )
If I wanted to make a full system, I suppose I would make /var an MFS
filesystem too and use the system mtree to create it's directory structure.
But most diskless workstations do not need to run cron :-)
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
I sure did, but I never committed them. I would have to redo them at this point. The patch was to have MFS maintain a persistant file, so you could fsck the file as if it were a disk and then the mfs mount it. Security is an issue, but it depends on how your password file is setup. You don't have to export the server's own root - the key thing is that you want to export a shared root to all the workstations, so it would not be too hard to implement kerberos as an authentication mechanism for the workstations. At home, I just export my server's root. Point #2 is, of course, that you export a read-only root. -Matt Matthew Dillon dil...@backplane.com : :Luigi Rizzo wrote: :[..] : I haven't seen how you suggest to buildpopulate the MFS filesystems -- : right now i use a rather crude method of putting all the stuff in a tgz : archive on the server and expanding it at runtime on the client. I : haven't solved the problem with passwords (i.e. i just copy the files : from the server. -- this is clearly a security hole, perhaps YP-based : solutions would be much better). : :Didn't Matt have patches for initializing a MFS from a mmap'ed file rather :than from swap at some point? : :Cheers, :-Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
: 'kern.conf_dir' which the kernel initially sets to nothing.
:
:ok, i can only suggest that if you replace the sysctl kern.conf_dir
:variable with a shell variable as i did, you can achieve a more
...
That's what I had originally, but extracting the machine's IP
address is not trivial, and I didn't want to stick:
bootp_ifc=`route -n get default | fgrep interface | awk '{ print $2; }'`
bootp_ipa=`ifconfig $bootp_ifc | fgrep inet | head -1 | awk '{ print $2;
}'`
I think it is much easier than that. The kernel BOOTP support sets
the machine's hostname, so you can do something like
if [ `hostname` = ]
then
# regular non-bootp sequence
mount -u -o rw /
...
mount -a -t nonfs
else
. /etc/rc.diskless
fi
if you want, save the `hostname` before executing rc.network to
remember if you started as diskless or not.
:I haven't seen how you suggest to buildpopulate the MFS filesystems --
...
There isn't much to build. Most of the MFS filesystems start out
empty.
ok here we use a different approach. For simplicity I am using a
single MFS system with all the things you put in /var, and including
/var/dev and /var/etc (with /dev - /var/dev and /etc - /var/etc
on the diskless machine).
cheers
luigi
---+-
Luigi RIZZO .
EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione
HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
---+-
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
Luigi Rizzo writes: :I haven't seen how you suggest to buildpopulate the MFS filesystems -- ... There isn't much to build. Most of the MFS filesystems start out empty. ok here we use a different approach. For simplicity I am using a single MFS system with all the things you put in /var, and including /var/dev and /var/etc (with /dev - /var/dev and /etc - /var/etc on the diskless machine). I have a wacky idea in this vein that I want to pursue sometime -- instead of pushing off lots of symlinks for the various writable portions of the read-only root directory (which strikes as a bit odd in itself), I was considering union-mounting an MFS filesystem directly over the read-only root partition. The advantage of this approach is that you do not have to know ahead of time what portions of the read-only partition need to be writable -- files get copied into the MFS partition only if and when they are written to. Thoughts? It seems like it would be feasible, and it might even be possible to do it directly in /etc/fstab without having to put any sort of cleverness in /etc/rc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: beginnings of a diskless boot sequence being committed
I'm going to commit a cleaned up version of my rc startup mods to handle diskless BOOTP kernels, especially diskless BOOTP kernels with read-only NFS mounts of / and /usr. Basically this consists of a bit of code in /etc/rc and, later tonight, an /etc/rc.diskless script ( a new script ). before you reinvent the wheel, have you looked at my code in http://www.iet.unipi.it/~luigi/diskless981113/ this is sliglthly pout of date wrt what i have now (an rc.diskless file, which essentially contains all rc modifications that you see in the above web page) cheers luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
