> > Today I did try to follow it, and it made an otherwise impossible job
> > for me doable, although still taking too much hours and a patch. The
> > 'impossible job' for me had to do with my zero-apache experience and
> > (probably) a bug in WebDAV.
>
> Thank you for doing that valuable work! I think the patch is fine (take
> that as an Acked-by:); next time you might want to send it as a proper
> patch mail ;-)
Ok, I send it out. Don't know if I did it proper...
> > -This text assumes that you
> > -
> > -- have an Apache webserver,
> > -- can edit the configuration of it,
> > -- can restart it, and
> > +
> > +What's needed:
> > +
> > +- Have an Apache webserver
> > +
> > + On Debian:
> > + $ apt-get install apache2
> > + To get apache2 by default started,
> > + edit /etc/default/apache2 and set NO_START=0
> > +
> > +- can edit the configuration of it
> > +
> > + On Debian: this means being able to edit files under /etc/apache2
>
> On some other setups, it is /etc/httpd/. Since it is not specific to
> Debian, we might want to give some common options, but refer the user to
> the Apache manual if she cannot find it.
Ok, but I find it always very convenient when someone describes the
situation for _me_. So if other distro's would join in, I would be
delighted. And indeed a general fallback to the Apache documentation
would be good for all distro's (+ homegrown) not covered.
However, Debian already differs quite some from the defaults. I wrote
this addendum to the documentation _because_ it costed me quite some
time since Debian tries to be different.
Debian seperates as much as possible into different files and
directories to be able to easily install and deinstall modules with
the package manager. And it has scripts to manage those directories.
> > +
> > +- can restart it.
> > + 'apachectl --graceful' might do.
>
> It is Ã'apachectl graceful' here (without'--').
>
> > + On Debian:
> > + $ /etc/init.d/apache2 restart
>
> This should work everywhere, except it might be called apache or httpd
> instead. However, please warn users that this interrupts (however briefly)
> a running webserver, and if you do that on a production machine, users
> just downloading an iso file might be rightfully upset.
If you're on a production machine with a webserver already in
production, you're probably not using this tutorial (I hope).
If you're downloading a large iso, recent browsers have 'resume'
buttons. The internet has never been very reliable.
If you're on Debian, '/etc/init.d/apache2 restart' is the same as
'/etc/init.d/apache2 force-reload', so no interruptions.
...but warning is always good :)
> > + On Debian:
> > +
> > + $ cd /var/www
> > + $ mkdir my-new-repo.git
>
> Again, it might be cooler to be a bit more portable: if the user found
> httpd.config, he could just "grep DocumentRoot /where/ever/httpd.conf".
Nope. On Debian, httpd.conf is a placeholder which does not contain
anything expect for:
# This is here for backwards compatability reasons and to support
# installing 3rd party modules directly via apxs2, rather than
# through the /etc/apache2/mods-{available,enabled} mechanism.
#
#LoadModule mod_placeholder /usr/lib/apache2/modules/mod_placeholder.so
And the grep gives nothing. Doing a recursive grep gives:
/etc/apache2$ grep -r DocumentRoot *
sites-available/default: DocumentRoot /var/www
sites-enabled/000-default: DocumentRoot /var/www
...where sites-enabled is a link to sites-available.
> > Change the ownership to your webserver's credentials
> > +
> > + $ chown -R www.www .
> > +
> > + On Debian:
> > +
> > + $ chown -R www-data.www-data .
>
> Again, a better way would be to direct the user to "grep ^User httpd.conf"
> and "grep ^Group httpd.conf".
Both come up empty on Debian. The uid + gid appear to be in apache2.conf :
/etc/apache2$ grep ^User *
apache2.conf:User www-data
> > + DAVLockDB "/usr/local/apache2/temp/DAV.lock"
> > +
> > + On Debian:
> >
> > - DAVLockDB "/usr/local/apache2/temp/DAV.lock"
> > + Enable the dav and dav_fs modules of apache:
> > + $ a2enmod dav_fs
> > + $ a2enmod dav
> > + The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf:
> > + DAVLockDB /var/lock/apache2/DAVLock
>
> I did not find a2enmod on my only Debian setup, so a more portable way
> would be to tell the user to insert the following lines in httpd.conf:
>
> LoadModule dav_module libexec/httpd/libdav.so
> AddModule mod_dav.c
No, a2enmod is the recommended way to enable modules. It adds symlinks
from the /etc/apache2/mods-enabled to /etc/apache2/mods-available.
I got those from http://www.debian-administration.org/articles/285
> (I do not know if there are setups where you have to load dav_fs
> explicitely...)
According to http://www.debian-administration.org/articles/285, I had
to. Didn't check it myself, though.
> > + On Debian:
> > + Create (or add to) /etc/apache2/conf.d/git.conf :
>
> Is this picked up automatically?
Yup. From /etc/apache2/README:
...
conf.d/
Files in this directory are included by this line in
apache2.conf:
# Include generic snippets of statements
Include /etc/apache2/conf.d
This is a good place to add additional configuration
directives.
httpd.conf
Empty file.
...
> > + <Location /my-new-repo.git>
> > + DAV on
> > + AuthType Basic
> > + AuthName "Git"
> > + AuthUserFile /etc/apache2/passwd.git
> > + Require valid-user
> > + </Location>
>
> We should not violate the DRY principle ("Don´'Repeat Yourself").
Ok, a merge could be done, but AuthUserFile is different.
Something like
+ AuthUserFile <passwd-file>
then.
> > +On Debian:
> > +
> > + To test the WebDAV part, do:
> > +
> > + $ apt-get install litmus
> > + $ litmus http://<servername>/my-new-repo.git <username> <password>
>
> There has to be a more portable way to test WebDAV, like an URL to type
> into a webbrowser. DAV wizards, anyone?
The renaming bug I found by using Windows Internet Explorer -> Open Location ->
http://<servername>/my-new-repo.git [x] Open as webfolder -> login,
and copy a file to it, rename it, ...
Another interactive tool is cadaver (see
http://www.debian-administration.org/articles/285 again).
With FUSE + fusedav you can mount a WebDAV like a normal filesystem
(which is cool ;)
> > -Then, add the following to your .netrc (you can do without, but will be
> > +Then, add the following to your ~/.netrc (you can do without, but will be
>
> Okay, I thought it was common knowledge where this resides. Although I
> would say $HOME/.netrc instead.
Ok.
> > + On Windows, use %HOMEDRIVE%%HOMEPATH%.netrc instead.
>
> Huh? You want to access it with something else than cygwin?
You're right, Cygwin should have $HOME set.
> > +To check whether all is OK, do:
> > +
> > + curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/
> > +
> > +...this should give a directory listing in HTML of /var/www/my-new-repo.git .
>
> Does everybody who has libcurl installed, have curl installed also?
Don't know, but I think most people who have apache2 installed have
better things to worry about :) Might want to add the dependancy
explicitly in the document, yes.
> > - $ git-http-push upload master
> > + $ git push upload master
> > +
> > +This pushes branch 'master' (which is assumed to be the branch you
> > +want to export) to repository called 'upload', which we previously
> > +defined with git-repo-config.
> >
> > -(This assumes that the branch you want to export is called 'master' in your
> > -client setup...)
>
> Your wording is much clearer.
It took me a while to figure out, I (incorrectly) assumed 'upload' was
the name of the remote branch. And git-http-push didn't work at once,
so I got it working with some extra options before I realised it
should be 'git push' instead.
> > request; This can happen when you start Apache, but then disable the
> > network interface. A simple restart of Apache helps.
> >
> > -In other cases, reading /usr/local/apache2/logs/error_log is often helpful.
> > -
> > +Errors like (22/502) are of format (curl error code/http error
> > +code). So (22/404) means something like 'not found' at the server.
>
> I think the error log is more useful than the http error codes.
You deleted those two lines (look at the version I sent), so jut put
them back :)
Do you want to finish it, or should I do a reedit?
Regards,
Rutger.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html