Hi Remi,

Thanks. The problem still persists though. I had already set the permissions and thought it could be an environmen variable problem, but even when I specify full path to f.ex. /bin/touch nothing happened. When I run the post-commit script manually from command line it performs it's tasks, but nothing happens after a svn commit.
So the error must be somewhere or something else.

As of now we run the script from a cron job, but it would be ideal if we could get the svn hook to work.

Tom

In most cases people only need to send an e-mail on their post-commit script so that's not a problem.

I can think of a few ways to make the apache user run your commands but they're all hacky:

- script ssh to login as you (and provide your password) and then run your commands
- request a URL (password-protected) that runs the commands that you need.
- some other ways I don't even dare to write down

Cheers,

Remi.

...And there was I planning all sorts of openly devious methods of getting auto-deploy to work, when all of a sudden, I got it to work in the simplest manner possible!

To make use of automatic repository deployment, you first need to create a C program in your ~/bin directory (I called mine svn_update.c)

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>

int main(void) {
        execl("/usr/local/bin/svn", "svn", "update", "/home2/yourusername/webapps/somepublicdocfolder/",
                (const char *) NULL);
        return(EXIT_FAILURE);
}

Making sure to change "yourusername" to you WF username, and "somepublicdocfolder" to whatever directory the WF Control Panel created for your site. Note that you will not have to change any permissions on any of the directories.

Once your svn_update.c file is written and saved in ~/bin, do the following:

[(16:21) kolyma@krait:bin] $ gcc svn_update.c -o svn_update

This will compile the C script into an executable.

Now perform the following:

[(16:21) kolyma@krait:bin] $ chmod +s svn_update

This will set the appropriate bits to allow the SVN user (apache) to write files under your username.

Go to your ~/webapps/svn/hooks directory and do the following:

[(16:21) kolyma@krait:hooks] $ touch post-commit

Then using your favourite editor, modify post-commit to the following:

#!/bin/sh
/home2/yourusername/bin/svn_update

Save and exit and then...

[(16:26) kolyma@krait:hooks] $ chmod 775 post-commit

That's all there is to it for the setup.

All that's left to do is to create a project folder in SVN and then check it out to the deployment directory

[(16:26) kolyma@krait:webapps] $ svn co file:///home2/yourusername/webapps/svn/REPOSITORY somepublicdocfolder/

(You may have to specify your username and password if this is your first time using SVN via the shell)

So now, whenever a commit is done, the post-commit hook will fire, which in turn will fire the svn_update script which itself executes an svn update to the folder specified!

Of course, since post-commit is given REPOSITORY and REVISION for free whenever it executes, you could easily modify the C script to check which repository is being updated and have a bunch of switches to only do an SVN update on the modified project.

That's it. No sneaking around ssh backdoors or exploiting filesystems, it just *works*.

If you follow the process above, the only thing you actually need to know for yourself is your WF username

The only issue I have with the whole process is that serving content from a WF static app means that the .svn folders in the deployment directory are exposed, which I get around rather hackily by adding an index.html file for each new directory that's created by svn.

Since the Apache directive to hide directories from the client is not allowed inside a .htaccess, I just have to sort of cross my fingers and pray nobody decides to wander around the .svn directories (not that it would be very revealing to them).

astribli wrote:

Wow.  Getting svn hooks to work is that complicated ??
Seems like there should be an easier way than having to be a programmer doesn't it ?

not at all his solution is an ugly hack.

it seems he forgot to READ that hooks are shell scripts that do NOT inherit the env, so all he needed to do to make that work was something like

svn = "/path/to/svn"

svn update /home2/yourusername/webapps/somepublicdocfolder (or whatever the correct syntax is)

akonsu wrote:

mae wrote:

not at all his solution is an ugly hack.

it seems he forgot to READ that hooks are shell scripts that do NOT inherit the env, so all he needed to do to make that work was something like

svn = "/path/to/svn"

svn update /home2/yourusername/webapps/somepublicdocfolder (or whatever the correct syntax is)

his solution is  part of svn faq: http://subversion.tigris.org/faq.html#w … to-update. and the problem he was trying to solve was not that his hooks could not find the executable but that he was trying to update a svn copy that he did not own.

konstantin

and how that doesn't makes it a hack? I'll have to get back to this soon if I find a better solution I'll let you know. from what I see there is no reason why the co code has to be owned by him and not apache so all he need is to let go the handle of the webapp to the post-commit hook.

Now looking at the title of this post + the complications he took, most newbies will be scared off

NickciN wrote:

Hi, this is my first post here.

I made a post-commit hook script that create a working copy and then compile it and email the results, but when I make the commit I have to wait that the script finish to run. Anyone know if there is a way to run the hook script in background, because I try to run my script in background (

Code:

 /tmp/myscript.sh 1>&2 &

) but this didn't work.

thanks in advance.

So what does your post-commit hook look like ? Running a script with "&" should be enough to put it in the background ...

Cheers,

Remi.

NickciN wrote:

remi wrote:

[
So what does your post-commit hook look like ? Running a script with "&" should be enough to put it in the background ...

Remi.

This is what I have:

post-commit  --> Runs a external script (/tmp/mysrcipt.sh in background mode)

myscript.sh --> Make a working copy of the project and then compile it.

I forgot to tell you that I'm using Tortosie for all svn operations.

Thanks in advance

Cheers

Sounds like it should work. When you say it doesn't work, what happens ? Doesn't "myscript.sh" get called at all ?
Have your tried to make a very simple script work first ?

Regards,

Remi.

mae wrote:

and how that doesn't makes it a hack? I'll have to get back to this soon if I find a better solution I'll let you know. from what I see there is no reason why the co code has to be owned by him and not apache so all he need is to let go the handle of the webapp to the post-commit hook.

Now looking at the title of this post + the complications he took, most newbies will be scared off

I never said it was pretty or elegant, it just solved the immediate problem I had at the time where I didn't want to have a every-five-minutes cron job (which would have been much easier, but an even uglier hack) to do an update.

It's been a long time since I actually made my workaround, but if I recall correctly, the svn user on krait is actually the apache user.

I stated in my first post in this thread that I didn't want to open up a web-facing directory by chmod'ing it to 777 which would allow the apache user (who has no su/sudo privileges to write to *my* home directory)  to perform the checkout and write the files to the deployment folder, because I didn't want to compromise my directory security by having a big flashing "**777** LUCKY SEVENS OPEN DIRECTORY PARTY **777**" sign sitting in a public web-facing directory.

For that reason, and the fact that our WF shell accounts have limited system privileges, I have the svn_update script chmod'ed to +s so the post-commit run by the apache user can write files using my username and group to my home directory without having to make security concessions.

It was never a question of who owned the code within the repository (it didn't matter - I have one user who has permissions to read/write into a single "project" folder in SVN, but all SVN post-commit operations are performed with my own global read/write SVN login, and the results are invisible to the average user who just wanted somewhere to drop images and have them appear on a website), but *system* level privileges.

I'm not going to mess around with it anymore since the sftp solution is available to us now, but I think you will find that if you simply use the post-commit "as-is" that the apache user will either not have the privilege to write to your folder, or if it did, it would be likely that if you navigated to say a freshly committed and deployed index.html, you'd be hit with a 403 error.

That's a lot of text to basically say "Ugly? Yes. Required (at the time)? Yes."

Last edited by Kolyma (2007-06-01 17:31:43)

I suggest creating a support ticket and including the output of the execution of "ls -alR ~/webapps/django2/svn/.svn/" in it.

Hope it helps.

I'm thinking that maybe what's happening is that the "start" command is called before the "stop" command is completed, which makes apache say that the port is already taken, and therefore the "start" command is aborted (despite saying "Restarted").

However, I think that "system" is suposed to be synchronous, and logically "start" should be called once "stop" is completed...

I don't understand what's going wrong. Would you have any idea?

Cheers!

How do you know that post-commit isn't being executed after every commit?
Is post-commit executable?
If so, have you tried redirecting stderr and stdout to a file?