On Mon, Dec 7, 2009 at 9:22 AM, Pat O'Brien <p...@petta-tech.com> wrote:
> > > On Mon, Dec 7, 2009 at 8:56 AM, Todd Lyons <tly...@ivenue.com> wrote: > >> On Thu, Dec 3, 2009 at 4:58 PM, Pat O'Brien <p...@petta-tech.com> wrote: >> > >> > We now manage a little under 2000 hosts in three separate data centers >> with >> > etch without any issues with scalability, flexibility or manageability >> > whatsoever. >> >> I spent some time this weekend reading up on etch. The etch-users >> mailing lists seems to have very little traffic and I have some >> questions, I hope you don't mind commenting on some or all of them: > > >> 1. It seems to (be able to) shell out to do a lot of scripting. Is it >> possible to use git for the SCM backend instead of RCS? >> > > We use svn for ours so I wouldn't be able to say for sure but I can't > imagine why git wouldn't work. > Oh I think I misunderstood this - I am not sure if you can switch the backend SCM - we just use RCS and it works fine. > > > >> 2. It is client server architecture, which is very cool. Any >> suggestions as which distro works really well as an etch server? We >> use CentOS exclusively here so would like to stay within it, however, >> if this system can be as useful as it appears on the surface, I'd be >> willing to deal with a different distro for one machine. >> > > We use CentOS at work for practically everything, including our etch > servers. > > For the etch-client (living on hosts) there should be rpm spec files > already made for ease of deployment which we just have installed, along with > other things, during the post section of our kickstart files. > > As for the server, we don't roll it out using a package manager, so the > instructions on the wiki would be the best bet to follow. > > >> 3. Any "cut and paste" or "quick script" suggestions for quick client >> installation on CentOS 4.x and 5.x servers? The wiki introduction had >> a lot of commands that manipulated files outside of the package >> management system, so I wanted to see if there was something more >> within the confines of rpm. (On Ubuntu, I was able to install some >> things via aptitude, but overall things wanted more recent versions so >> I had to use gems to install just about everything ruby related, at >> least for the server part). >> > > Client or Server? The Client should be rather easy as it depends on ruby, > facter, rcs, crontabs, all of which can be pulled automatically via a yum > install. As for the Server itself, unless you were to roll your own rpms for > the gems, you would be stuck with using gems. I don't really have a problem > with this, personally. > > >> >> > We use etch in conjuction with nventory >> > (http://sourceforge.net/projects/nventory/) and life is 1,000 times >> more >> > easier now than it was when we were using puppet. >> >> Another ruby app, eh? This perl programmer faces a a real learning >> curve in order to do basic things like upgrade it. I have not yet >> delved deeply into it, but will look into this also. >> > >> 4. Is my understanding correct that I could do something as simple on >> the etch server as a local DB file all the way up to a backend like >> mysql/postgres? >> > > We have mysql providing the backend db for the etch server. I see no reason > why something like sqlite wouldn't work. > > >> >> I think I'm going to setup a VM as an etch server and see what happens >> when I try to configure it. I was hoping for a simple mode where I >> could just modify a config file on a server and etch would >> automatically see it and yank it into the config repository and just >> push that file out (if commanded to), but it seems to not be aimed in >> that direction. >> > > So you would want to have a "gold" server, where you would edit say, > /etc/sysctl.conf, etch would see the change submit it to svn or git and then > push that "gold" /etc/sysctl.conf file out to all of the hosts you permit it > to? I've never tried that but I wouldn't imagine that behavior exists in > etch. > > If I misunderstood the question, let me know. Hope this helped. > > > >> -- >> >> Regards... Todd >> Real Integrity is doing the right thing, knowing that no body's going >> to know whether you did it or not. >> _______________________________________________ >> LinuxUsers mailing list >> LinuxUsers@socallinux.org >> http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers >> > >
_______________________________________________ LinuxUsers mailing list LinuxUsers@socallinux.org http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers
