On Tue, Dec 8, 2009 at 9:40 AM, Todd Lyons <tly...@ivenue.com> wrote:
> On Mon, Dec 7, 2009 at 9:22 AM, Pat O'Brien <p...@petta-tech.com> wrote: > >> 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, > > We use CentOS at work for practically everything, including our etch > > servers. > > That's a useful statement, at least for me and my purposes :-) > > > 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. > > So you're saying I need to roll an rpm for etch client. Should be > doable, and I see it's even made easy because there's an etch-client > spec file in the tarball. > > > 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 > > 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. > > I have some things that I do (courier-imap specialties) for mail > servers, so I guess I'm not above this either. I'd _rather_ it the > other way, but wish in one hand... :-) > > >> 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'm going to do it that way then, thanks for the confirmation. > > > 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. > > With support for scripts, I can see a couple solutions to pull the > file from a central repository (or symlink to file in an nfs mounted > directory), but I don't see a way to detect that the file is changed > from the template and push the changes back to the central location. > Our central repository is an svn repo - we make changes either in our own branches or just check out a local copy on a test host. Once an hour the repo on the etch servers gets updated and a tag is created. I don't think I would like it if things were done automatically like you are suggesting, but that's just my personal feeling. It seems like there would be a lot more room for error if there wasn't actually a human to make sure that things were kosher with your changes. For /etc/sysctl.conf alone we have probably six different configs, one of which is dynamically generated via scripts. You would hate to be put in the situation where someone edits a file without testing or the file gets zeroed out accidentally and you are left to deal with the consequences. What's nice about etch is the "staged" roll out (I forget what it's called) using the tags feature. It wasn't too long ago that I committed something that dropped user accounts off of our dev boxes. I was able to mark the tag as "broken", everything reverted and I fixed what it was that broke. > > > If I misunderstood the question, let me know. Hope this helped. > > Understood it perfectly. Yes, it did greatly, thanks so much. Hope > to see you at a SRCLUG meeting if you ever get a chance to make it out > that way. > -- > 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
