[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Server Access
-- Should the radmind server be separate for Linux and Solaris?
The server is platform independent, so the only reason for this would
be aesthetic. Even Mac OSX (with a different filesystem) was loaded
from our current server.
It is perhaps also a cosmetic reason, but one possible reason for having
separate servers would be to reduce the number of loadsets on any one
server, which might make keeping things straight and managing them a
little easier. This is not much of a problem now, but as the number of
loadsets increases, it could become a bother, if not an issue.
It might be nice if radmind could be directed to file/transcript stores.
A preliminary suggestion would be something along the lines of changing
the way that command files are structured and parsed to allow for, say,
p lfs-base.T beta
n lfs-neg.T beta
p lfs-gcc323.T beta
Well we currently manage this type of thing like this:
I don't feel like introducing extra complexities is generally a good
solution to a problem if an alternative exists.
When the beta base (we actually usually use dates) becomes the new
agreed upon 'real' base, two mv's and some command file editing do
-- How shall we divide up responsibility for loadsets?
Some loadsets (base) will need to be collaborated on, and may be at
different stages for different production needs (accelerated patching
Perhaps one topic for future discussion would be what constitutes the base
loadset and who works on it.
I would think this is the main topic for discussion. Everyone who's been on
eq and working with stuff should toss out to the list tools, headers, whatever,
that they notice are missing. These would be great 'practice' updates for
anyone to run through with Sean or me for radmind coaching if you want it.
-- Should we share a common development server for building software?
Depends on rebooting needs. Kernel rebuilding probably needs a machine
per sysadmin (at a time) since you can't just reboot a machine with
multiple people working on it. I think this depends on the development
needs of a given project.
There could also be potential issues with shared libraries, yes?
It seems to me that if a software install updates a base shared library then it
will go into the appropriate loadset. Subsequent software should then be
built against the most up-to-date loadset. I guess there could be some overlap
issues with simultaneous building/development, but I'm not the most
experienced person to comment on this.
Keeping dev servers up to date is key.