Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Source Mage network install

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeffrey Schmidt <jschmidt AT fnal.gov>
  • To: Casey Harkins <charkins AT upl.cs.wisc.edu>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Source Mage network install
  • Date: 08 Aug 2002 11:40:44 -0500

On Thu, 2002-08-08 at 10:26, Casey Harkins wrote:
> Beautiful! Very simple, yet effective solution. Unfortunately, I'm going
> to have to postpone the upgrade until early 2003 (just ran out of time).
> The good news is I'll have more time to build a test network and we should
> be at 1.0 by then (who's got the whip??). I will be mirgrating our NFS/NIS
> servers to SMGL yet this summer (yuck).
I, too, plan on moving NIS masters from IRIX and RedHat to SM soon. let
me know how it goes.

>
> I haven't bothered testing this before, what exactly and when exactly to
> reports get mailed to the SM admin? Every update/rebuild/cast? Dispels?
> Only on errors? Making this configurable (customizing reports) could be
> very useful for a post-1.0 feature.
I get mail for each unsuccessful compile/make and for each successful
install. mail subjects are in a nice format ("Sorcery Report : $HOSTNAME
: $2 for $SPELL-$VERSION", where $2 is 'Compile log' or 'Install log'),
but easy enough to change in '/var/lib/sorcery/subroutines'.

admittedly, dispel and update reports would be nice... ;^)

>
> -casey
>
> > Casey, >
> > for what it's worth, here's my (edited) /etc/sorcery/local/config on my
> > "homebase" system:
> >
> >
> > #plenty of space...
> > ARCHIVE=on
> > AUTOFIX=on
> > #just in case...
> > AUTOPRUNE=off
> > CABAL=off
> > CCACHE=off
> > #a must if yer managing a SM cluster...
> > MAIL_REPORTS=on
> > #bandwidth galore...
> > PATCH=off
> > PRESERVE=on
> > #servers with soundcards are not servers...
> > SOUND=off
> > SUSTAIN=on
> > #now who's going to sit there at the console for six hours?
> > VIEW_REPORTS=off
> > VOYEUR=on
> > REAP=on
> > GRIMOIRE=/root/grimoire
> >
> >
> > this system has apache running on it, with this added to it's config:
> >
> >
> > Alias /grimoire/ "/var/spool/sorcery/"
> >
> > <Directory "/var/spool/sorcery">
> > AllowOverride None
> > Options Indexes FollowSymlinks MultiViews
> > Order deny,allow
> > Deny from all
> > Allow from 192.168.1.0/24
> > </Directory>
> >
> >
> > poof! all your sources are available to anything on 192.168.1.0/24
> > just add:
> >
> > BASE_URL="http://<yer homebase>/grimoire"
> >
> > to the client's local/config.
> > I do a 'sorcery update' and 'summon' on the homebase node. when it's
> > done, everything else is ready to connect to it.
> >
> > there are other ways to do this, but this is very clean, no nfs exports
> > to worry about.
> >
> >
> > Jeff
> >
> > On Wed, 2002-07-31 at 17:11, Casey Harkins wrote:
> > >
> > > I have a number of questions/ideas I would like to run by everyone
> > > to get their feedback on. First a little background . . .
> > >
> > > Over the next two weeks I will be planning and testing an upgrade to our
> > > existing Linux workstations and LAN servers. Our primary desktop
> > > machines are all currently running Mandrake. Each network is centered
> > > around NFS (for home directories and shared OpenOffice documents), NIS
> > > for authentication and a Sybase database server for our internal
> > > CRM/sales automation software. There are two of these networks at
> > > different locations.
> > >
> > > I plan on moving this all to a Source Mage based system using LDAP for
> > > authentication and *something* for a networked filesystem.
> > >
> > > 1) Which grimoire: devel, testing, stable or custom?
> > >
> > > The first issue is which grimoire to use. In an ideal world stable would
> > > be the right choice, but missing sources could cause endless headaches.
> > > Further, one of these networks is a good 600 miles away and I cringe at
> > > the thought of an eventual gcc2 to gcc3 upgrade while I'm a days journey
> > > away. Would it be enough to place gcc on hold, or will this not work to
> > > avoid the gcc switch? I'm leaning towards using the devel grimoire
> > > because the sources are usually readily available and the gcc switch is
> > > already completed (well, sorta).
> > >
> > > The other option is to maintain a custom grimoire, this is my plan
> > > eventually once I have time to write some tools for doing so. My idea is
> > > to maintain full control over grimoire through a menu driven interface,
> > > only selected spells get exported to the custom grimoire, and versions
> > > need to be explicity OK-ed to pass through to the custom grimoire.
> > > Dependecies would be resolved automatically and optional dependecies
> > > could be removed or converted to required depencecies to force a desired
> > > configuration.
> > >
> > > 2) Localized source
> > >
> > > I would like to force workstations to only use source from the LAN
> > > server. This could be done by sharing /var/spool/sorcery as read-only
> > > and summoning all spells on the server.
> > >
> > > A while back I remember someone mentioning a BASE_URL variable that
> > > could be set in /etc/sorcery/local/config, how does this variable work.
> > > Is the full SOURCE_URL appended to the BASE_URL or just the SOURCE
> > > variable? If this URL fails, does it try the normal SOURCE_URL? The
> > > advantage I see to using this approach, as I can use this on the LAN
> > > server to download all source from an FTP server on the second network.
> > > This allows me to keep a single repository of software, including a
> > > custom grimoire if that path is chosen. The individual workstations
> > > could still mount /var/spool/sorcery from the LAN server.
> > >
> > > 3) Which network file system?
> > >
> > > This one is a tough, as I'm really only familar with NFS under Linux.
> > > I've obviously used SMB on Windows networks, but how well does it work
> > > on a Linux only network? Is there any secure network filesystem solution
> > > that doesn't involve Kerberos that people have used? Can SMB be
> > > stunneled?
> > >
> > > ---
> > >
> > > That's good enough for now. Any ideas, thoughts, flames, comments will
> > > be appreciated. Back to LDAP docs...
> > >
> > >
> > > -casey
> > >
> > >
> > > _______________________________________________
> > > SM-Discuss mailing list
> > > SM-Discuss AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> > --
> > +-------------------------------------------------+
> > | Jeffrey A. Schmidt - SysAdmin, PPD/CDF Online |
> > | Fermi National Accelerator Lab |
> > | Batavia, IL USA |
> > | jschmidt AT fnal.gov (630) 840-2207 |
> > +-------------------------------------------------+
> >
>
--
+-------------------------------------------------+
| Jeffrey A. Schmidt - SysAdmin, PPD/CDF Online |
| Fermi National Accelerator Lab |
| Batavia, IL USA |
| jschmidt AT fnal.gov (630) 840-2207 |
+-------------------------------------------------+




Archive powered by MHonArc 2.6.24.

Top of Page