Stefan,
Thanks for responding. I wrote that email in some haste. My main point
was ways to enhance the docs and procedure, not to imply that it was
incorrect or too difficult.
>>Many people can't do that. That's why our docs tell what to do if
those ports are already in use. It might seem a little more complicated
(ok, it *is*), but if you can't just stop the app listening on those
ports, you'd be lost without our docs telling you what to do in such a
case.<<
That's why I wrote "I recommend..." If they can't then they should still
use your procedures. However, we are talking about installing a server
here. It's not for the faint of heart in general. It was a sentence to
be added to the docs (with appropriate editing), not to replace anything
that was there.
>>Your source points to a blog entry. I don't like our docs point to
those, because: <<
I pointed at the blog entry so you could see some of his comments. The
Tortoise docs could point straight at the file. In this case, his
package is fully up-to-date with the 2.0.x Apache release.
>>c) AFAIK (last time I tried) the source our docs tell you to get the
openssl.cnf file also has a working one. <<
The openssl.cnf file that the Tortoise docs pointed to may have been the
culprit behind my problems. Since it's coming from a different source
than the apache/openssl release, you have the same problem you were
concerned about with things staying up-to-date.
>>d) that's not a good reason. In fact, I think that's something you
shouldn't use. Always create your own certificate. Otherwise users can
get into big problems if they cache or install the certificate, then
later get to another server with the exact same certificate.<<
I agree with that. However, if you can get the base SSL functionality
working from a known-good release and certificate, then you eliminate
one source of potential errors if you have to debug a problem. So use
the provided one with a working openssl.cnf. Make sure that works. Then
create your own with the Tortoise procedures and change ssl.conf to use
the new one.
>>Added that hint to our docs in revision 8574.<<
You probably understood this, but adding that "-D SSL" means you don't
have to comment out / delete the <IfDef SSL> lines in the ssl.conf file.
I think that's the more standard way for Apache to be configured.
>>While this is a good tip, our docs are in no way a replacement for
the apache docs. We only tell how to install Subversion with Apache. If
users want to tweak the Apache settings, they have to read the Apache
docs.<<
You've already told them how to configure Apache for a non-standard HTTP
port in case 80 is in use. If they want SSL and port 443 is in use, too,
then for completeness I'd think you should tell them what's involved.
Finally, if I had one overriding recommendation, it would be to tweak
the procedure a little so that the base Apache install, including SSL
support and whatever else might be needed, is completed and known to be
working before adding Subversion. Update the docs accordingly and also
recommend that the user test the setup after each step so he knows
immediately when something has gone awry.
That's all I've got time for now (much to my chagrin). I do appreciate
you giving me your perspective on this stuff.
Donnie Hale
Stefan Küng wrote:
> Donnie Hale wrote:
>> (I hope this email gets read - I don't have the time to jump through
>> the hoops to join the mailing list and try to post the information
>> there, but I do want to pass this along since TortoiseSVN has been so
>> good to me.)
>
> You don't have to subscribe to the mailing list. Just send your mails
> there. If you're not subscribed, it will take a while for your mail to
> appear on the list because we have to moderate your mail through (we
> do this to prevent SPAM from getting to the list).
> Don't forget to mention that you like to be cc'ed on replies or you
> have to read the list on the web. Otherwise you won't get replies.
>
>> I just completed setting up my first Apache / Subversion server on
>> Windows, and I ran into a few problems. They began when I tried
>> adding SSL support to Apache per the TortoiseSVN docs. It ended in
>> failure, and I'm not sure why. (My guess is that it might have to do
>> something with running the Apache service under something other than
>> "SYSTEM", but it's just a guess.) Ultimately I uninstalled Apache and
>> started over from scratch, determined to be more methodical and make
>> sure the base Apache with SSL setup was working before adding
>> Subversion.
>>
>> At each step, it's important to verify the expected functionality
>> that's been configured so far (which generally includes a restart of
>> the Apache service). Here are the high-level steps I took, with
>> comments where appropriate:
>>
>> 1) Install Apache as a service per the TortoiseSVN docs.
>> I recommend stopping anything using port 80 and/or 443 at this point
>> and letting Apache run with those ports until everything is working
>> correctly.
>
> Many people can't do that. That's why our docs tell what to do if
> those ports are already in use. It might seem a little more
> complicated (ok, it *is*), but if you can't just stop the app
> listening on those ports, you'd be lost without our docs telling you
> what to do in such a case.
>
>> 2) Add SSL support.
>> I found a better source, I think for the SSL add-ons. There's a link
>> to the .zip file at http://smithii.com/node/30, along with some key
>> points. Some advantages of this approach include: a) only the
>> required files (modules, conf, bin, etc.) are in the .zip file; b) it
>> can be unzipped right into the Apache2 directory; c) it includes a
>> working openssl.cnf file; d) it includes a working self-signed SSL
>> certificate.
>
> Your source points to a blog entry. I don't like our docs point to
> those, because:
> - they might not be online for long
> - they usually don't have updated packages available
> The source our docs point to are properly maintained and always
> up-to-date with the latest apache and openssl versions.
>
> a) it would of course be better if hunter.campbus.com had packages
> which contained only the files we need without the whole apache stuff
> too.
> b) another good point
> c) AFAIK (last time I tried) the source our docs tell you to get the
> openssl.cnf file also has a working one.
> d) that's not a good reason. In fact, I think that's something you
> shouldn't use. Always create your own certificate. Otherwise users can
> get into big problems if they cache or install the certificate, then
> later get to another server with the exact same certificate.
>
>> The command line for starting the Apache service should be modified
>> in the registry to include the text "-D SSL" (without quotes) before
>> the "-k runservice" arguments.
>
> Added that hint to our docs in revision 8574.
>
>> 3) Change the listen ports if desired.
>> There are 3 places (if I recall correctly) where port 443 needs
>> changed in the ssl.conf file. A search for "443" in the file will
>> make that clear.
>
> While this is a good tip, our docs are in no way a replacement for the
> apache docs. We only tell how to install Subversion with Apache. If
> users want to tweak the Apache settings, they have to read the Apache
> docs.
>
>> 4) Change the user under which the Apache service runs if desired.
>> You have to give "modify" rights to that user on the Apache2
>> directory (and below) so the service can write log files. In my first
>> attempt to get this working, I took this step very early. The reason
>> I think that this caused a problem was that the files I added under
>> Apache2 later may not have had the required permissions for the user.
>> Again, just a guess...
>
> If you could write a step-by-step guide on how to do this, that would
> be great! (just send it to dev at tortoisesvn tigris org).
>
> Stefan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 26 23:28:11 2007