Not really a survey on whether sysadmins are stupid, but more a
question about how people are doing things with their Mongrel
management.
Do you have different management commands in your monit
configuration vs. your /etc/init.d/ configuration?
Do you have your monit configurations setup to run another script
like /etc/init.d/mongrel_cluster or do you put raw “mongrel_cluster
start --clean …” commands with extras in the monit config?
Do you follow DRY in your code? Why not your sysadmin?
I’m asking since I just realized a bunch of people are probably doing
this, and I’ve kind of been telling them to do it. I might need to
work up a course correction but need to see what the level of damage is.
Thanks for the time.
–
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.awprofessional.com/title/0321483502 – The Mongrel Book
http://mongrel.rubyforge.org/
On 4/5/07, Zed A. Shaw [email protected] wrote:
like /etc/init.d/mongrel_cluster or do you put raw “mongrel_cluster
start --clean …” commands with extras in the monit config?
Do you follow DRY in your code? Why not your sysadmin?
I’m asking since I just realized a bunch of people are probably doing
this, and I’ve kind of been telling them to do it. I might need to
work up a course correction but need to see what the level of damage is.
How about this one:
How many people have extensive SCM, project tracking, and CI for their
Rao;s code, but then configuration changes (mongrel, apache, crontab,
whatever) are still handled manually using vi or by copying files
around? If anything config files are more critical then rails code,
so why aren’t they in SVN, automatically deployed, and even (gasp)
tested automatically somehow?
On 4/5/07, Zed A. Shaw [email protected] wrote:
Do you have different management commands in your monit
configuration vs. your /etc/init.d/ configuration?
Putting everything in mongrel.config and using ‘monit start all’ to
start all services on reboot. Not using mongrel_cluster at all.
Alex
How many people have extensive SCM, project tracking, and CI for their
Rao;s code, but then configuration changes (mongrel, apache, crontab,
whatever) are still handled manually using vi or by copying files
around? If anything config files are more critical then rails code,
so why aren’t they in SVN, automatically deployed, and even (gasp)
tested automatically somehow?
Yes… and since we’re all using capistrano to deploy (we are aren’t
we?)
then this becomes even easier as you can not only track things in svn,
but
write simple tasks to deploy them right out of SVN.
Which also means you’re less likely to forget a server… which you will
do as soon as you have more than one 
On Apr 5, 2007, at 11:53 AM, Philip H. wrote:
Yes… and since we’re all using capistrano to deploy (we are
aren’t we?)
then this becomes even easier as you can not only track things in
svn, but
write simple tasks to deploy them right out of SVN.
Which also means you’re less likely to forget a server… which you
will
do as soon as you have more than one
I keep a directory for each server with all the generated config
files for nginx,monit,mongrel, etc… and tasks to build all gems and
packages required to run the app, keep this all in subversion. And I
deploy the config files with capistrano as well. The lesser you have
to ssh to your servers the better imho.
CHeers-
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)
On Thu, 5 Apr 2007 13:35:26 -0500
“Rob S.” [email protected] wrote:
On 4/5/07, Zed A. Shaw [email protected] wrote:
How many people have extensive SCM, project tracking, and CI for their
Rao;s code, but then configuration changes (mongrel, apache, crontab,
whatever) are still handled manually using vi or by copying files
around? If anything config files are more critical then rails code,
so why aren’t they in SVN, automatically deployed, and even (gasp)
tested automatically somehow?
Really? Wow! You’ve got a blog post on this? A book? I’d love to
see how your particular solution works for everyone. That’d be
awesome. See, I keep running into this problem where svn pollutes my
whole server with ass loads of .svn directories. Oh, and I’m not able
to prevent some dumbass from putting crap in the svn which I have to
accept. Do you happen to know how you check that an svn update won’t
clobber my whole system because Joe Fucktard forgot that he was
editing the database server’s hosts.deny and blocked the whole network
off? Also, how do I prevent someone from putting sensitive stuff into
the svn repository? I know svn’s really super secure and all, what
with it’s fantastic tagging-everything-permanently-forever
backup mechanism and all, but I kind of don’t like my passwords and .pem
secret key files in the svn repo.
–
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 – The Mongrel Book
http://mongrel.rubyforge.org/
On 4/5/07, Zed A. Shaw [email protected] wrote:
with it’s fantastic tagging-everything-permanently-forever
backup mechanism and all, but I kind of don’t like my passwords and .pem
secret key files in the svn repo.
Obviously we don’t keep key files and the like in svn. I’m talking
about things like vhost files and the like. Right now I’m working out
a way to export them and/or symlink them to the right spot via
capistrano. It definitely beats tweaking your vhost, scp’ing it to 4
servers, repeat, etc…or having the nightmare of trying to rollback a
config change made 2 days ago when its all done manually.
Also, Joe Fucktard doesn’t work for us - and if he does, I’d rather
see his change go thru svn then have it happen silently. Or just dont
give him permission to the config repository, if you really have
people you can’t trust.
We have a ruby script that does every for us - “daemon_control start”
brings up the mongrels for our various rails apps up, starts
backgroundrb & various daemons, enables cron jobs etc…
Fred
Philip H. wrote:
Yes… and since we’re all using capistrano to deploy (we are aren’t we?)
then this becomes even easier as you can not only track things in svn, but
write simple tasks to deploy them right out of SVN.
Which also means you’re less likely to forget a server… which you will
do as soon as you have more than one
Speaking of Capistrano. Since, most of my configurations are built out
of templates anyway I’ve used the Capistrano render and put methods to
generate my init and config files at deploy time and upload them to all
servers. My cap recipe of course stays under version control.
recipe/code snippet
task :upload_mongrel_conf do
mongrel_cluster = render :template => <<-CONF
prefix: /<%= application %>
cwd: /webapps/<%= application %>
port: <%= (core_port.to_i + 10).to_s %>
environment: <%= rails_env %>
pid_file: /global/<%= application %>/shared/pids/mongrel.pid
servers: <%= mongrel_count %>
CONF
put mongrel_cluster, mongrel_conf
end
–R