RE: [Unattended] Some ideas from the new guy
On Tue, 23 Mar 2004, Matthew Palmer wrote: > You may or may not be aware of the existence of a nice little webapp called > IRM. It can do machine, user, licence, networking tracking, (and soon > peripherals). My "dream" (called that because I want to do it but have no > clear plan on when or how) is to integrate Unattended and IRM, as follows: This IRM application sounds interesting. Would you happen to have a link to its homepage? The only matching entry I can find on Freshmeat is http://www.stackworks.net/view.php/irm/index.html. /Jonas --- 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
RE: [Unattended] Some ideas from the new guy
> Package Management > *** > I was reading through the mail list archives and saw that > package management > is something that is needed/wanted. I agree wholeheartedly. [...] > good fit. Having a > central registry of all these "packages" that we can sync to > would be ideal. > Letting "maintainers" update these packages would be even > better. Has anyone > put specific thought into this? If so, what was it? And, what > would be the > next steps? If we all need it and it is just going to need > someone to write > it I would like to volunteer. My expertise is in web > programming anyway, > that seems a logical way to do it. I have a ton of bandwidth > at work (I am > on a university campus) and could have a test server up nice > a quick. If no > one else has really looked into this I can start to formalize > my thoughts > and present a design recommendation to the list. If you're thinking of a "Package" being something like "Patch Q123456", or "Adobe Reader 6.0", then you're going to come against problems with redistribution, because unlike Gentoo's portage tree, most of the packages you'll make for Windows don't allow free redistribution of the program, so the best you can do is to provide the installer files for the package, and have the user drop the package files into the portage tree on their local systems. For all that, I think that it's a ripper of an idea to do this, as the biggest problem I've got is making all the shitty little apps in use here install automatically, and I'd *love* it if I could contribute the ones I've done in exchange for the ones that other people have done. Maybe little zip files full of batch scripts and such to install various applications, which people download, stick in their own "ports" tree, and then follow the simple instructions on how to get the program files themselves in there from the CD or original website or whatever. > 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 ... Keeping client machines up to date is something I'm wanting to work on (when I find the time). I've played around a bit with using Makefiles for each of the software packages I use, which create stamp files on the client to tell it what the state of the machine is. After (for instance) adding a new version of the software to the Unattended tree, including updating the package's makefile for the new version, a rerun of the master Makefile (customised for the machine's software load, or using database info (see below)) will see the new version in the package makefile and run the appropriate commands to make the update. There's probably a better way (less fragile), but It Seems To Work For Me. > * 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 Aaah, a man after my own heart. See below. > * 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 You may or may not be aware of the existence of a nice little webapp called IRM. It can do machine, user, licence, networking tracking, (and soon peripherals). My "dream" (called that because I want to do it but have no clear plan on when or how) is to integrate Unattended and IRM, as follows: * Machines are set up in IRM, and are obviously tagged by MAC address and hostname, which the DHCP server uses to assign addresses and whatnot. * Unattended also gets this information out of the IRM database (I'm also thinking of converting a lot of IRM's database backend to LDAP, because LDAP is more suited to the task), so it knows what the machine's hostname and such are. Other random settings can probably be set in the unattend.txt file. * IRM stores information on software installations (including, soon, licence numbers assigned to individual machines), and could have information on where in the Unattended tree the individual software packages are (and the installation script to use). Unattended could use this information to install the software packages assigned to each machine. > If so, what kinds of technologies would you like to see used? IRM is true LAMP. I'm starting to use PgSQL for some of my projects, as the whole relationships thing (as well as triggers and stored procs) is starting to be
RE: [Unattended] Some ideas from the new guy
> 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
RE: [Unattended] Some ideas from the new guy
> 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
[Unattended] Some ideas from the new guy
Greetings list, First off I want to say thank you for such a great "product". I started using Unattended last year and then got into a ton of budgeting, planning, etc so our XP upgrade, the main reason for starting to use Unattended, was delayed. But now, with all that over (for now), I have downloaded the newest version and am currently running the very rockin prepare script! So thanks and hats off to all of you. On to the real reasons for this message: Package Management *** I was reading through the mail list archives and saw that package management is something that is needed/wanted. I agree wholeheartedly. I wanted to see if we were on the same page here -- Package management in the way I read it 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 ... Gentoo is a distribution of Linux and Portage is a package management system written for said distro.) I use Gentoo on a number of machines at work and love the portage system. It handles a lot more than we might need for unattended but some of the design principles seem to be a good fit. Having a central registry of all these "packages" that we can sync to would be ideal. Letting "maintainers" update these packages would be even better. Has anyone put specific thought into this? If so, what was it? And, what would be the next steps? If we all need it and it is just going to need someone to write it I would like to volunteer. My expertise is in web programming anyway, that seems a logical way to do it. I have a ton of bandwidth at work (I am on a university campus) and could have a test server up nice a quick. If no one else has really looked into this I can start to formalize my thoughts and present a design recommendation to the list. 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. The Rest(TM) *** These aren't as thought out as the stuff above (ha!) but I wanted to get them out there while I was thinking of them. [Most of this is predicated on me having a decent inventory (asset management) system in place. I am getting ready to write one up though, and figured if any of this fits I can take it into account.] * 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. * 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. * 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 Does any of this sound like it could be usable by someone other than me? 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 ??) *** 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 solici
