Hi. I'm trying to build a fancy automated build system for internal
use at my company. I want to be able to configure build parameters
via a web page and then kick off the build script via the page.
So, one of the things I want to be able to do is to dynamically
discover the branches in Subversion that exist for some of our projects.
It was very easy to write a Perl script that would do this. No problem.
Then, I tried to run it as a CGI script and I ran into a little snag.
At our company we use https to access our subversion system. We do
not have a valid certificate. This results in a message being printed
to stderr that says:
Error validating server certificate for 'https://svn:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
Certificate information:
- Hostname: subversion1
- Valid: from Jan 10 00:00:38 2007 GMT until Jan 10 00:00:38 2008 GMT
- Issuer: SomeOrganizationalUnit, SomeOrganization, SomeCity,
SomeState, --
- Fingerprint: f3:6e:e2:af:5e:fe:63:9d:c5:63:a4:03:b8:4d:
60:04:c5:d8:a3:d6
(R)eject, accept (t)emporarily or accept (p)ermanently? subversion/
libsvn_ra_dav/util.c:826: (apr_err=175002)
svn: PROPFIND request failed on '/svn/qtplayer/branches'
subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
svn: PROPFIND of '/svn/qtplayer/branches': Server certificate
verification failed: certificate issued for a different hostname,
issuer is not trusted (https://svn)
So, this is usually no big deal - we just enter "p" and then we never
see this thing again.
However, when I am running my script as a CGI, the user that it runs
as is called "www". And apparently "www" is a very sad little user
because he hasn't accepted the fact that this certificate is bad.
There are two ways I can think of to solve this. The right way would
be to convince someone that it was important to have a valid
certificate for our subversion server. But the easy/lazy way would be
to simply login as "www" and accept the certificate permanently which
would solve the problem for the foreseeable future. Unfortunately I
don't know the password for "www". Therefore, I could reset the
password - but would this cause problems for Apache? Or alternatively
I guess I could crack the password, but that might take a while.
Instead I have chosen to ask the community if there is more
information available regarding the "www" user and permissions
issues. I expect this to become more pertinent when I try to connect
our build script with the CGI system. The build script currently
requires that certain parts of it be run using sudo and I usually run
it as myself, so I'm thinking there will be issues if I try to have
"www" run it. So, I would prefer to know as much as I can about this
issue so that it will make it easier to tackle the remaining
obstacles as I move forward with this task.
Thanks for any info you might provide.
Brant Sears
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Web-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/web-dev/email@hidden
