On Mon, Aug 09, 2004 at 12:47:25PM -0400, [EMAIL PROTECTED] wrote:
> -          Add replication to multiple servers, or distribute certain
> packages to different servers (No one server can handle the load of 30
> computers installing itself over a gigabit lan)

You're better off doing this on the server side.  From memory Samba and W2k3
can both do some sort of transparent duplication -- something related to
duplicate names in WINS / DNS.  I haven't got details, because I've never
needed it, but I'm sure I read something about it in my Samba doc travels.

> -          Create an 'unattendedD' to coordinate clients and evenly spread
> the load across various servers (a client every time a simple smb connection
> would be made, would instead contact a centralized server which will point
> the client to another serverP

Seems like a lot of work for minimal benefit.

> -          Add a GUI to automate and simplify the package configuration
> process

Too many different ways that windows software can be installed for that ever
to have a hope in hell of succeeding.  Get everyone (and I mean, everyone)
to adopt a single, scriptable package installation format and then come back
to this one (I'm thinking RPMs (or preferably .debs) for Windows).

> -          Add better Active Directory integration

Why?  You can join a domain during config, what more do you want?

> -          Use smbios information to add computer descriptions, and have
> each computer placed into a database

IRM.  I've got most of the integration worked out already.  It'll be even
cleaner once I get the binaries in place for network naming and stuff
working, but it's a CSV for now.

> -          Create a software database of all the software able to be
> installed, and the software which is installed on each client. 

Again, IRM.  That's even cuter, because it uses the basic perl install to go
and find the software list at runtime.

> -          Ability to upgrade software based off a server push model 

For so many reasons, you do not want to do server push.  Check 'Push vs
Pull' stuff on infrastructures.org.  You will die of coronary immolation
before you get this right.

> -          Add software remotely

Eh?  Are you thinking "update installed software database then push"?  I
just add the software to the database and then wait for the next automatic
update.

> -          Perform diagnostics on a regular interval and send the results
> back to the server

Nagios, although I haven't found a Windows port for the core plugins, I'm
quite sure someone's done it (at the very least the perl ones should be
simple to port).

> -          Simplify the linux boot cd process by distributing a binary
> collection of the contents of the cd, and having an easy method to change
> where the cd looks for files 

Apart from the inordinate amount of time it takes to rebuild the CD (and
it's apparent dependence on FC2 <grin>) what would you want to simplify?  It
does take most of it's files from the server already through /z, why not
just put your software in /z/bin?

Like the unattendedd idea, this seems like a lot of fiddle for minimal
benefit.

> -          ---- or possibly modifying the cd to look across the entire
> network for the unattendedD and automatically connect to it

There's this thing now we have called 'DHCP'.  It helps with that sort of
thing.  Even Microsoft is starting to see that maybe basing all of SMB's
service location stuff on broadcast wasn't such a good idea, because Subnets
Are Your Friend.

- Matt


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
unattended-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-devel

Reply via email to