user profiles

Richard Lightman richard at reika.demon.co.uk
Sun Jan 28 06:09:51 PST 2001


Misquoted from Bryan Dumm:
> Subject: user profiles
> 
> Howdy,
> 
> User profiles again.... I got some basic ideas below, and I 
> would like to start building up a list of suggestions. One 
> of the questions I have is how would General or Specific
> Preference xml structures look like or work????
> 
> Anyways, looking for comments.
> 
Please imagine the smiley of you choice in each paragraph ;-)

I tried keeping general information in a configuartion file. The
result quickly became too complicated. Think about how you would
generate the following files/links from a profile:

Site choices:
/etc/Muttrc
/etc/bashrc
/etc/environment
/etc/httpd.conf
/etc/inputrc
/etc/limits
/etc/localtime
/etc/login.access
/etc/login.defs
/etc/lynx.cfg
/etc/networks
/etc/nsswitch.conf
/etc/profile
/etc/proftpd.conf
/etc/suauth
/var/dnscache/root/servers/localnet.rcl
/var/dnscache/root/servers/1.168.192.in-addr.arpa
/var/qmail/control/badmailfrom
/var/qmail/control/databytes

Host dependant
/boot/grub/menu.lst
/etc/TextConfig
/etc/X11/XF86Config
/etc/asound.conf
/etc/fdprm
/etc/hosts
/etc/modules.conf
/etc/ppp/options.ttyS0
/etc/ppp/chat-script
/etc/resolv.conf
/etc/ssh_config
/etc/ssh_host_dsa_key
/etc/ssh_host_dsa_key.pub
/etc/sshd_config
/etc/sysconfig/hdparms
/etc/sysconfig/mouse
/usr/src/linux/.config
/usr/share/keymaps/defkeymap.kmap.bz2
/var/qmail/control/defaultdomain
/var/qmail/control/defaulthost
/var/qmail/control/idhost
/var/qmail/control/locals
/var/qmail/control/me
/var/qmail/control/rcpthosts
/var/qmail/control/smtpgreeting

This is a subset of the files/links I have modified to my
taste. Perhaps you prefer BIND or procmail. Do you want to
support getting data from the profile to all the possible
variations?

I manage all this data with tarballs of configuration
files - one for each site, and one for each host. Alfs
could then manage all of the above from just the host
name, site name, and path to the tarballs - I keep
them in the same tree as my source code. Host specific
takes priority over site specific. Site specific takes
priority over application default.

The tarballs are made with three files - site_list
is a list of files to be packaged into the site tarball.
host_list packages stuff for any host, and does not care
about missing files. del_list deletes some clutter that
I do not use - eg /etc/access.conf.default from apache.

I did find four packages that could benefit from such
data, but I could now get that data out of /proc or
/dev with kernel 2.4.0

zlib asm{3,5,6}86
alsa-driver card_type
dcd cdrom_dev_file
cdda2wav interface_type cdrom_dev_file cdrom_bus_id sound_dev




LFS
Target install directory

build_dir
Place where packages are built. (I do not have much
space left for things in /usr/src, but my work partition
will be empty during an LFS build

make_fs_list
list of (device, fstype) to make new file systems on before
starting to compile. I am not brave enough to add data for
sfdisk

mount_fs_list
list of (devives, fstype, mountpoint) to mount before starting
to compile

sources
path to directory tree full of source code

package management
Do you want some idea of whick packages installed which file?
How do you want to collect that data?

Environment variables:
May be better off with soething like /etc/profile
LINGUAS, LANGUAGE, LC_ALL, LANG, CFLAGS, CPPFLAGS,...

locale definintions
List of stuff like:
localedef -i en_GB -f ISO-8859-1 en_GB
localedef -i en_US -f ISO-8859-1 en_US

The next thing to handle is a list of extra packages.
In the past I had difficulty keeping track of which
ones are not installed on a host because they are not
needed, and which ones are not installed because I
had not set up automatic installation last time I
updated that host.

My answer is for each host: 
  a list of packages to install
  a list of packages to reject

And a global list of packages. It is trivial to remove
the packages in the first two lists from the third to
see what changes I should make to a hosts install lists.
This will get a bit more complicated with package groups
like kde or gnome.


Richard

-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the alfs-discuss mailing list