On Mon, May 10, 2010 at 2:56 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On 5/10/2010 1:30 PM, Ross Walker wrote: >> >>> Well, yeah - I suppose you could say the design is good for the job >>> security of sysadmins and for requiring support subscriptions from the >>> distribution vendors, but it's something that the computer really should >>> be able to handle by itself just like it does during the initial install. >> >> Computers are dumb, and if we give too much power to the OS vendors >> they'll enslave us. > > If it is smart enough to create the initial install it should be smart > enough to adjust the file entries it created to what it would have done > on different hardware. It is creating a lot of work for you to turn > everything into a new install just because that's all it knows how to do. I'm sure a vendor will come up with a complete solution, but you will be forced into the vendor's idea of what that solution will be and typically it is everything that that vendor provides and only that vendor. >>> Have you totaled up the hours you've spend on these tasks that would be >>> unnecessary in a better-designed system? And even if that sort-of makes >>> sense for servers that have a basic "type", what about ones that have >>> application developers as users and end up accumulating all kinds of >>> cruft that you don't know about? >> >> After the initial time to research and setup the system the time to >> maintain and extend was minimal, and these were setup a long, long, >> long time ago (circa Windows 2000), use rsync or DFSR to replicate the >> config to other deployment servers in remote offices. >> >> I definitely recommend it. > > How many different OS's do you handle this way? I had Windows 2000/2003, CentOS 4/5, Fedora, Debian, Xen Server and ESXi itself off our deployment servers at one time, now I just do Windows 2003, CentOS and ESXi. >> Just need to setup clear policies with the developers, save your work >> here and it will be recoverable, save your work there and you are SoL. > > Getting developers to follow instructions has been described as "herding > cats" - and if you lose developer work or time, everyone is sol, not > just them. I have heard that, so like users you have to make it more appealing/easier to go the supported way then the unsupported way. Make it so they have to sudo anything off an unsupported path, and they will hopefully stick with the path of least resistance. >> No need to clone or image either, I can have a server deployed over >> the network in much quicker time then if I imaged it and a whole lot >> easier to maintian long-term then a clone. > > That's assuming you've wrapped everything local in an installable > package in a private repository for every OS version you use, which > doesn't sound at all quicker to me. Especially if you start with hosts > that are expected to be one-off types but have to be moved to new > hardware once in a while. Actually it is very little we need to privately support, most distro supplied tools work for us, so not a problem. Supporting Fedora/Ubuntu as a choice will allow those who need bleeding edge to get it through those channels. Since we are almost 100% virtualized, there is no real problem rolling from testing/development into production, the virtual hardware is the same. -Ross