> Package Management
> ***********************
...
> is a system that would keep an Unattended server up to date with the latest
> patches, hotfixes, application installers, etc. Does that seem a fair
> assumption? If so, perhaps we could adopt a similar strategy to the Gentoo
> Portage system. (For those of you not familiar with Gentoo or Portage ...
Maybe. As I understand it the discussion was more client side then server side.
Personally I feel that the server side 'management' would be less of an
immediate benefit then client side management. Server side we can update the
/install/prepare script and have the server 'updated'. It's a kludge but works well.
I am a big fan of producing something that works and incrementally improving upon that
until you
have all the features you want.
> Post Install Usage
> ***********************
> Or, Client Package Management. The other side of the coin is that if our
> servers are updated with the latest packages how do we keep the client
> machines going. I know that this is a little out of the scope of an
> Unattended install project, but like I mentioned above ... All the scripts
> are written for package installation, it would seem practical to reuse this
> immense effort. I know that some of you have thought of this, or are doing
> it. If you are already doing some of this, is it through login scripts? Or
> some other way? Using a subset of the Unattended logic in login scripts
> makes sense to me. My thought is that this would apply to adding
> applications (packages) to an existing machine as well.
To me this is the interesting part. I am not yet to this point.
It would seem to be trivial to add logic to each batch script to check
to see if that application or update had been applied and if not yet installed
add itself using todo.pl. Right now all the scripts assume the application / update
is not yet installed. That to me would be a baby step in the right direction.
It would in theory mean that we could run the application install portion of unattended
In the login script before EVERY login.
> The Rest(TM)
> ***********************
>
> * Administrative interface: Here is an example -- I know I am having a new
> user start, they are going to get the base install, the sales install, and a
> couple of other apps too. I log in to the web interface of my Unattended
> server, select the machine from my inventory, select the os, select base,
> sales, then select the other applications from my catalog of installs. This
> creates a file like the .csv examples so that the appropriate os and
> applications are installed. (If all this logic is being used to maintain the
> machines as well, you could log in and select an application to *add* to a
> specific machine and it would be the next time the logged in!) The admin
> side could also be used to maintain site configuration files, like the
> [_meta] info.
Agreed, not much has to gel in order for this to be a reality very soon.
> * Logging: When a machine is built the log files (or entries) are stored on
> the server and accessible via the administrative interface. This allows me
> to see what has been done to a specific machine. These entries would be
> written when software is added as well.
I could see this as being a nice thing to have. We would have to agree on a
naming scheme for the logfiles. It would simply be a
"xcopy c:\netinst\log z:\logs\%computername%\%date%\ /s /e" or something similar.
We'd have to be careful to not fill the disk, etc... but that can be delt with.
> * License counts: Now I am just wishing aren't I? If I have a fixed amount
> of licenses for a specific application I can decrement that number when it
> is selected from the interface (or maybe when it is installed), unless the
> user is already licensed for it...etc etc
Again, doable. Short-term the information would have to be kept in a flat file.
In fact if we did switch to using an SQL database or some such if at all possible
I would like to make that an option. The less complicated Unattended is to setup
the more people will use it.
> Does any of this sound like it could be usable by someone other than me?
Yes :)
> If so, what kinds of technologies would you like to see used? I tend to lean
> toward the stuff that can run on multiple platforms (the LAMP framework is
> good for that).
> - For the web stuff would you rather see PHP, or Zope, or ASP , or ??
> - How about data storage (MySQL, MS SQL, or ??)
PHP, MySQL
Excuse my ignorance but I wanted to make sure I didn't misunderstand....
Of course the web interface would compliment the improvements to the perl scripts.
No amount of PHP can 'make data' from the workstations :) The workstation will have
To upload that data.
> ***********************
> I know this is pretty scatter brained but I have had it all on my mind for
> several months now and finally have some time to throw at it. I am not
> putting these ideas out there in the hopes that someone else will do it -- I
> am soliciting some input before I get started. Oh, and feel free to tell me
> that this is all just the medication talking! ;)
>
>
> Thanks for listening!
> Don
My Personal Wishlist...
1) scripts that run client side need to be 'smarter' and not install anything if its
done already.
2) the application install portion of unattended needs to be cleaned up to run
'easily' from a UNC
map z:
set the path
install perl
add applications to the queue
run todo.pl --go
3) Progress Bar (or at least a 6 out of 16 items installed, type thing)
In order to do that the script would have to keep a list other then
todo.txt.....
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
unattended-info mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-info
