3

I started with sftp, then switched to WebDAV and I'm currently using rsync through ssh to deploy any updates/upgrades from my development server into my production server.

I'm still not very happy using this system and think using git to deploy may be better, mainly because of the possibility of rolling back any changes instantly with just one command.

Appart from using ssh tunnel to pull and push to the production server (leaving the git service behind the firewall), I've also realized I have to edit .htaccess to deny web access to .git folder.

Is this the correct approach, should I check anything else, do something in a different way, or should I go in a totally different direction?

Improve this question

2 Answers 2

Reset to default
14

That depends on your exact way of doing it. Right now it seems to me you have a git repo in your httpdocs that you deploy to, basically using HEAD as your actual website - that is NOT the correct way. I'm not sure how you are able to push to this configuration at all?

What you want to do is use a bare repo somewhere outside the httpdocs-folder, and checkout the files to httpdocs after pushing. While this sounds complicated, its pretty easy to do, here is a step-by-step tutorial: http://caiustheory.com/automatically-deploying-website-from-remote-git-repository

If your webserver needs access to some files, such as a wordpress installation, you need to add chmod and chgrp commands to the post-receive hook, otherwise your files belong to the wrong user (the one you used to push the commit, not the webserver).

Simply make a new script to change ownership that you call from the post_receive hook via sudo scriptname.sh (name it change_own.sh or whatever) :

chown -R wwwrun /path/to/httpdocs
chgrp -R www /path/to/httpdocs

and allow the script to be run without password via visudo by adding gituser ALL=(ALL) NOPASSWD: /path/to/change_owner.sh at the end.

Assumptions made: wwwrun - webserver user; www - webserver group; gituser - user to push commits

Addendum: A friend used this method and complained about how he had to update Wordpress over and over again. The obvious reason is that if the Webapplication updates itself, und thus replaces its code, these changes will not be transferred back into the repository, because the hook only works one way. Thus after each commit, the hook overrode all changes the Wordpress-Installation made through updates. The imho quickest workaround is to run the updates on the developer machine, then commit to deploy.

Improve this answer
2

I think using git to manage the set of files needed to run your site is a clever idea.. as a matter of fact there are several services already doing this (as far as I know): microsoft's azure and some node.js hosting sites like nodester.com, just to name a couple..

As also @phi said, I'd not place the repository on the very same folders you publish through the web server, but have instead some kind of procedure which lets you "get the files" from the git repository and place where your web server will use them.

Just be sure to think all the details.. for instance:

  • if you have user-generated files, when you rollback or otherwise re-publish your site are they to be overwritten or kept in place?
  • if you have database data, when you republish your site will everything match and be ok, or should you handle the possible mismatch in some way?

There might be other culprits to think about, but the general idea is nice =)

Improve this answer
4
  • I'm surprised that's something that hosting sites would do. I've always been told (by security minded folk) that it's a disastrous security hole and should never be done. :-)
    – Brian Knoblauch
    May 1, 2013 at 20:13
  • 1
    Well, if you use cvs without any kind of security, I am with you.. But if you use some strong way to authenticate (using encrypted channels and certificate-based authentication) I think things are quite more secure... For instance to publish to an azure site you first have to generate a security certificate, with which the system will know who you are when your client connects.. Consider that certificates are way stronger than a (often simple) password...
    – Luke
    May 1, 2013 at 20:32
  • That said, every kind of automatic publishing system is to be designed carefully, especially if it will be used by other people, since human-related insecurity is often the key factor, the weakest ring of the chain...
    – Luke
    May 1, 2013 at 20:33
  • The update security isn't what I was warned about. The issue was with having the version control files on a box that can be accessed from the Internet. Something about being able to glean details from it that can be used to form an attack on either the exposed system and/or the dev computers? I really wish I could find the details again. I didn't keep track of them, I just walked away with the knowledge that there's no safe way (at that time, about a year ago) to allow version control deployment to servers exposed to the open Internet. :-)
    – Brian Knoblauch
    May 2, 2013 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.