Hi all,
I'm a complete Koji newb and am attempting to get a Koji server up and running for internal use, but have run into a number of issues along the way, despite following https://fedoraproject.org/wiki/Koji/ServerHowTo and other similar pages found around the net. My setup is built atop Fedora 19, so I had to make several adjustments, such as: * access directives for Apache httpd 2.4 (bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1019323 and wiki likewise edited) * changed the ssl.cnf for the Koji CA to so that default_md=sha256 (instead of md5) under the [default_ca] section so that firefox wouldn't complain about the trustworthiness of the certificate
I am able to use 'koji moshimoshi' both as kojiadmin and as myself from the Koji server as well as my workstation. I am also able to use the Koji-Web using http or https for some basic poking around. However, if I try the login link on the web page, firefox comes up with a message stating:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
From what I can gather via /var/log/httpd/ssl_access_log and examination
of /usr/share/koji-web/scripts/index.py's login function the page is trying to redirect the browser to force SSL (even if already using https when clicking on login) and somehow this results in what would be an infinite loop except that firefox halts the loop after a dozen or so cycles. I'm rather stumped as to where my investigation should be focused at this point however. Any advice?
-- John Florian
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up with a message stating:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
From what I can gather via /var/log/httpd/ssl_access_log and examination of /usr/share/koji-web/scripts/index.py's login function the page is trying to redirect the browser to force SSL (even if already using https when clicking on login) and somehow this results in what would be an infinite loop except that firefox halts the loop after a dozen or so cycles. I'm rather stumped as to where my investigation should be focused at this point however. Any advice?
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web login broke for me and I never investigated as to why as I never use it. I use the CLI.
From: mike@cchtml.com
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up
with a
message stating:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request
for this address
in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to
accept cookies.
From what I can gather via /var/log/httpd/ssl_access_log and
examination of
/usr/share/koji-web/scripts/index.py's login function the page is
trying to
redirect the browser to force SSL (even if already using https
when clicking on
login) and somehow this results in what would be an infinite loop
except that
firefox halts the loop after a dozen or so cycles. I'm rather stumped
as to
where my investigation should be focused at this point however. Any
advice?
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web
login
broke for me and I never investigated as to why as I never use it. I use the CLI.
Mike, thanks for the feedback. It helps confirm that it's probably not my particular setup. I thought the WUI was req'd for some operations that the CLI could not handle. Maybe I've got that backwards. Anyway, I guess I'll push forward with my evaluation of the tool using just the CLI for now.
-- John Florian
buildsys-bounces@lists.fedoraproject.org wrote on 10/17/2013 08:20:05:
From: John.Florian@dart.biz
From: mike@cchtml.com
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up
with a
message stating:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request
for this address
in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to
accept cookies.
From what I can gather via /var/log/httpd/ssl_access_log and
examination of
/usr/share/koji-web/scripts/index.py's login function the page
is trying to
redirect the browser to force SSL (even if already using https
when clicking on
login) and somehow this results in what would be an infinite loop
except that
firefox halts the loop after a dozen or so cycles. I'm rather
stumped as to
where my investigation should be focused at this point however.
Any advice?
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web
login
broke for me and I never investigated as to why as I never use it. I use the CLI.
Mike, thanks for the feedback. It helps confirm that it's probably not my particular setup. I thought the WUI was req'd for some operations that the CLI could not handle. Maybe I've got that backwards. Anyway, I guess I'll push forward with my evaluation of the tool using just the CLI for now.
Well, I am attempting to mostly ignore the koji-web for now, other than any clues it might offer. I've tried going forward with the CLI and have had some success with the bootstrap setup as I've been able to import some SRPMs, add a build host, targets, group and whatnot but when I get to the point where I am to "regen-repo" I see the following:
koji regen-repo f19-build Regenerating repo for tag f19-build Watching tasks (this may be safely interrupted)... 8 newRepo (f19-build): free SysCallError: (-1, 'Unexpected EOF')
I've also tried doing a scratch build and see much of the same ...
koji build --scratch --wait f19 /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm Uploading srpm: /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm [====================================] 100% 00:00:25 11.10 KiB 449.99 B/sec Created task: 10 Task info: http://mdct-koji.dartcontainer.com/koji/taskinfo?taskID=10 Watching tasks (this may be safely interrupted)... 10 build (f19, plant-launchers-1.3-1.fc19.src.rpm): free SysCallError: (-1, 'Unexpected EOF')
I'm not seeing anything helpful in the logs and since I'm such a koji newb I'm not sure what to make of this problem. Any advice would be greatly appreciated.
-- John Florian
On 10/21/2013 10:32 AM, John.Florian@dart.biz wrote:
Well, I am attempting to mostly ignore the koji-web for now, other than any clues it might offer. I've tried going forward with the CLI and have had some success with the bootstrap setup as I've been able to import some SRPMs, add a build host, targets, group and whatnot but when I get to the point where I am to "regen-repo" I see the following:
koji regen-repo f19-build Regenerating repo for tag f19-build Watching tasks (this may be safely interrupted)... 8 newRepo (f19-build): free SysCallError: (-1, 'Unexpected EOF')
I'm seeing errors like this on F19 myself. They are intermittent and normally retried by koji, but the cli calls that watch tasks drop authentication before they start watching.
You can work around this by enabling anon_retry in your koji config (e.g. in ~/.koji/config).
The good news is that this appears to be simply the task watcher failing on the client side. Your actual tasks may well be working. You can also always run koji watch-task $N to restart the watch if it dies.
I've also tried doing a scratch build and see much of the same ...
koji build --scratch --wait f19 /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm Uploading srpm: /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm [====================================] 100% 00:00:25 11.10 KiB 449.99 B/sec Created task: 10 Task info: http://mdct-koji.dartcontainer.com/koji/taskinfo?taskID=10 Watching tasks (this may be safely interrupted)... 10 build (f19, plant-launchers-1.3-1.fc19.src.rpm): free SysCallError: (-1, 'Unexpected EOF')
I'm not seeing anything helpful in the logs and since I'm such a koji newb I'm not sure what to make of this problem. Any advice would be greatly appreciated.
I believe this is happening client side for you. If you run your commands with the --debug global option, you'll probably see a traceback similar to this:
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1925, in _callMethod return self._sendCall(handler, headers, request) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1836, in _sendCall return self._sendOneCall(handler, headers, request) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1856, in _sendOneCall response = cnx.getresponse() File "/usr/lib64/python2.7/httplib.py", line 1045, in getresponse response.begin() File "/usr/lib64/python2.7/httplib.py", line 409, in begin version, status, reason = self._read_status() File "/usr/lib64/python2.7/httplib.py", line 365, in _read_status line = self.fp.readline(_MAXLINE + 1) File "/usr/lib64/python2.7/socket.py", line 476, in readline data = self._sock.recv(self._rbufsize) File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 140, in recv return con.recv(bufsize, flags) SysCallError: (-1, 'Unexpected EOF')
I'm not yet sure what the cause of this is, but I suspect some behavior change in the underlying libs.
From: mikem@redhat.com
On 10/21/2013 10:32 AM, John.Florian@dart.biz wrote:
koji regen-repo f19-build Regenerating repo for tag f19-build Watching tasks (this may be safely interrupted)... 8 newRepo (f19-build): free SysCallError: (-1, 'Unexpected EOF')
I'm seeing errors like this on F19 myself. They are intermittent and normally retried by koji, but the cli calls that watch tasks drop authentication before they start watching.
You can work around this by enabling anon_retry in your koji config (e.g. in ~/.koji/config).
Okay, I've added "anon_retry=true" there.
The good news is that this appears to be simply the task watcher failing on the client side. Your actual tasks may well be working.
Ah! That may help explain what I observed after posting that mail. While trying to figure out why the newRepo call was failing I learned that this particular job gets handed off to a builder and then got more logging going for kojid where I learned that my builder was enabled but not ready. While trying to figure out why it wasn't ready, it suddenly became ready and somewhere in that vicinity of time I also realized that the newRepo had succeeded. I never felt that I'd made any change to explain the success, but was fiddling quite a bit trying to make forward progess.
You can also always run koji watch-task $N to restart the watch if it
dies.
Good to know. Thanks!
I've also tried doing a scratch build and see much of the same ...
koji build --scratch --wait f19 /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm Uploading srpm: /pub/fedora/mdct/19/SRPMS/plant-launchers-1.3-1.fc19.src.rpm [====================================] 100% 00:00:25 11.10 KiB 449.99
B/sec Created task: 10 Task info: http://mdct-koji.dartcontainer.com/koji/taskinfo?taskID=10 Watching tasks (this may be safely interrupted)... 10 build (f19, plant-launchers-1.3-1.fc19.src.rpm): free SysCallError: (-1, 'Unexpected EOF')
I'm not seeing anything helpful in the logs and since I'm such a koji
newb
I'm not sure what to make of this problem. Any advice would be
greatly
appreciated.
I believe this is happening client side for you. If you run your commands with the --debug global option, you'll probably see a traceback similar to this:
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1925, in _callMethod return self._sendCall(handler, headers, request) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1836, in _sendCall return self._sendOneCall(handler, headers, request) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1856, in _sendOneCall response = cnx.getresponse() File "/usr/lib64/python2.7/httplib.py", line 1045, in getresponse response.begin() File "/usr/lib64/python2.7/httplib.py", line 409, in begin version, status, reason = self._read_status() File "/usr/lib64/python2.7/httplib.py", line 365, in _read_status line = self.fp.readline(_MAXLINE + 1) File "/usr/lib64/python2.7/socket.py", line 476, in readline data = self._sock.recv(self._rbufsize) File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 140, in recv return con.recv(bufsize, flags) SysCallError: (-1, 'Unexpected EOF')
I'm not yet sure what the cause of this is, but I suspect some behavior change in the underlying libs.
That indeed looks familiar. Unlike the newRepo, I cannot make a build succeed (i.e., no binary rpm) despite lots of waiting. Sounds like Koki atop F19 isn't ready for prime time yet, especially for a newb as myself. Can you recommend a better Fedora release? I've got much of the setup codified in puppet so it shouldn't be too much a PITA to rebuild.
-- John Florian
On 10/22/2013 11:56 AM, John.Florian@dart.biz wrote:
I'm not yet sure what the cause of this is, but I suspect some behavior change in the underlying libs.
That indeed looks familiar. Unlike the newRepo, I cannot make a build succeed (i.e., no binary rpm) despite lots of waiting. Sounds like Koki atop F19 isn't ready for prime time yet, especially for a newb as myself. Can you recommend a better Fedora release? I've got much of the setup codified in puppet so it shouldn't be too much a PITA to rebuild.
The ssl error is worrisome, but I doubt it is breaking your build. The automatic retry seems to handle it well, so it's only a problem for unauthenticated calls where anon_retry is false.
You said your build is waiting? Is the task being taken by a builder? If so, how far does it get? Are there any errors or odd messages on the kojid logs or build logs?
On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up with a message stating:
The page isn't redirecting properly
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web login broke for me and I never investigated as to why as I never use it. I use the CLI.
The underlying bug is that koji's check for http vs https was breaking on newer versions of mod_wsgi. This was fixed on the hub a while back, but for some reason we missed it on the web ui.
This commit should help: https://git.fedorahosted.org/cgit/koji/commit/?id=cf01c000a83702ee74de67b2ea...
From: mikem@redhat.com
On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up
with a
message stating:
The page isn't redirecting properly
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web login broke for me and I never investigated as to why as I never use
it.
I use the CLI.
The underlying bug is that koji's check for http vs https was breaking on newer versions of mod_wsgi. This was fixed on the hub a while back, but for some reason we missed it on the web ui.
This commit should help: https://git.fedorahosted.org/cgit/koji/commit/? id=cf01c000a83702ee74de67b2ead3bdef51591093
Thanks Mike! That indeed seemed to get things going in the right direction, but now my login link makes me think I have a certificate error of sorts, yet everything looks good to me. Clicking the login link gets me:
==> /var/log/httpd/error_log <== [Tue Oct 22 09:48:02.669660 2013] [:error] [pid 623] 669 [ERROR] m=login u=None p=623 r=10.1.0.158:34806 koji.web: Traceback (most recent call last): [Tue Oct 22 09:48:02.669694 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/wsgi_publisher.py", line 368, in handle_request [Tue Oct 22 09:48:02.669702 2013] [:error] [pid 623] result = func(environ, **data) [Tue Oct 22 09:48:02.669707 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 237, in login [Tue Oct 22 09:48:02.669713 2013] [:error] [pid 623] if not _sslLogin(environ, session, username): [Tue Oct 22 09:48:02.669717 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 125, in _sslLogin [Tue Oct 22 09:48:02.669722 2013] [:error] [pid 623] proxyuser=username) [Tue Oct 22 09:48:02.669727 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1726, in ssl_login [Tue Oct 22 09:48:02.669732 2013] [:error] [pid 623] sinfo = self.callMethod('sslLogin', proxyuser) [Tue Oct 22 09:48:02.669746 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1775, in callMethod [Tue Oct 22 09:48:02.669752 2013] [:error] [pid 623] return self._callMethod(name, args, opts) [Tue Oct 22 09:48:02.669757 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1914, in _callMethod [Tue Oct 22 09:48:02.669761 2013] [:error] [pid 623] raise err [Tue Oct 22 09:48:02.669766 2013] [:error] [pid 623] AuthError: CN=mdct-koji.dartcontainer.com,OU=kojiweb,O=Dart Container Corp.,ST=Michigan,C=US is not authorized to login other users
My setup is as follows:
# grep ProxyDNs /etc/koji-hub/hub.conf ProxyDNs = /C=US/ST=Michigan/O=Dart Container Corp./OU=kojiweb/CN=mdct-koji.dartcontainer.com
# grep WebCert /etc/kojiweb/web.conf WebCert = /etc/pki/koji/kojiweb.pem
# grep Subject: /etc/pki/koji/kojiweb.pem Subject: C=US, ST=Michigan, O=Dart Container Corp., OU=kojiweb, CN=mdct-koji.dartcontainer.com
... and just for giggles ...
# grep kojiweb /etc/pki/koji/index.txt V 231014202129Z 03 unknown /C=US/ST=Michigan/O=Dart Container Corp./OU=kojiweb/CN=mdct-koji.dartcontainer.com
Did I miss something here or is there another bug beyond the one resolved by the patch you provided? -- John Florian
On 10/22/13 7:52 AM, John.Florian@dart.biz wrote:
From: mikem@redhat.com
On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes up
with a
message stating:
The page isn't redirecting properly
I believe this is a bug in the latest Koji. After Fedora 18 or 19 web login broke for me and I never investigated as to why as I never
use it.
I use the CLI.
The underlying bug is that koji's check for http vs https was breaking on newer versions of mod_wsgi. This was fixed on the hub a while back, but for some reason we missed it on the web ui.
This commit should help: https://git.fedorahosted.org/cgit/koji/commit/? id=cf01c000a83702ee74de67b2ead3bdef51591093
Thanks Mike! That indeed seemed to get things going in the right direction, but now my login link makes me think I have a certificate error of sorts, yet everything looks good to me. Clicking the login link gets me:
==> /var/log/httpd/error_log <== [Tue Oct 22 09:48:02.669660 2013] [:error] [pid 623] 669 [ERROR] m=login u=None p=623 r=10.1.0.158:34806 koji.web: Traceback (most recent call last): [Tue Oct 22 09:48:02.669694 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/wsgi_publisher.py", line 368, in handle_request [Tue Oct 22 09:48:02.669702 2013] [:error] [pid 623] result = func(environ, **data) [Tue Oct 22 09:48:02.669707 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 237, in login [Tue Oct 22 09:48:02.669713 2013] [:error] [pid 623] if not _sslLogin(environ, session, username): [Tue Oct 22 09:48:02.669717 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 125, in _sslLogin [Tue Oct 22 09:48:02.669722 2013] [:error] [pid 623] proxyuser=username) [Tue Oct 22 09:48:02.669727 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1726, in ssl_login [Tue Oct 22 09:48:02.669732 2013] [:error] [pid 623] sinfo = self.callMethod('sslLogin', proxyuser) [Tue Oct 22 09:48:02.669746 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1775, in callMethod [Tue Oct 22 09:48:02.669752 2013] [:error] [pid 623] return self._callMethod(name, args, opts) [Tue Oct 22 09:48:02.669757 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1914, in _callMethod [Tue Oct 22 09:48:02.669761 2013] [:error] [pid 623] raise err [Tue Oct 22 09:48:02.669766 2013] [:error] [pid 623] AuthError: CN=mdct-koji.dartcontainer.com,OU=kojiweb,O=Dart Container Corp.,ST=Michigan,C=US is not authorized to login other users
My setup is as follows:
# grep ProxyDNs /etc/koji-hub/hub.conf ProxyDNs = /C=US/ST=Michigan/O=Dart Container Corp./OU=kojiweb/CN=mdct-koji.dartcontainer.com
This looks like a change in the format mod_ssl uses for the SSL_CLIENT_S_DN variable. If you change the ProxyDNs entry to match the DN printed in the backtrace, it should fix the problem.
# grep WebCert /etc/kojiweb/web.conf WebCert = /etc/pki/koji/kojiweb.pem
# grep Subject: /etc/pki/koji/kojiweb.pem Subject: C=US, ST=Michigan, O=Dart Container Corp., OU=kojiweb, CN=mdct-koji.dartcontainer.com
... and just for giggles ...
# grep kojiweb /etc/pki/koji/index.txt V 231014202129Z 03 unknown /C=US/ST=Michigan/O=Dart Container Corp./OU=kojiweb/CN=mdct-koji.dartcontainer.com
Did I miss something here or is there another bug beyond the one resolved by the patch you provided? -- John Florian
-- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
From: mikeb@redhat.com
On 10/22/13 7:52 AM, John.Florian@dart.biz wrote:
From: mikem@redhat.com
On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
John.Florian@dart.biz wrote:
However, if I try the login link on the web page, firefox comes
up
with a
message stating:
The page isn't redirecting properly
I believe this is a bug in the latest Koji. After Fedora 18 or 19
web
login broke for me and I never investigated as to why as I never
use it.
I use the CLI.
The underlying bug is that koji's check for http vs https was
breaking
on newer versions of mod_wsgi. This was fixed on the hub a while
back,
but for some reason we missed it on the web ui.
This commit should help: https://git.fedorahosted.org/cgit/koji/commit/? id=cf01c000a83702ee74de67b2ead3bdef51591093
Thanks Mike! That indeed seemed to get things going in the right direction, but now my login link makes me think I have a certificate error of sorts, yet everything looks good to me. Clicking the login link gets me:
==> /var/log/httpd/error_log <== [Tue Oct 22 09:48:02.669660 2013] [:error] [pid 623] 669 [ERROR]
m=login
u=None p=623 r=10.1.0.158:34806 koji.web: Traceback (most recent call last): [Tue Oct 22 09:48:02.669694 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/wsgi_publisher.py", line 368, in handle_request [Tue Oct 22 09:48:02.669702 2013] [:error] [pid 623] result = func(environ, **data) [Tue Oct 22 09:48:02.669707 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 237, in login [Tue Oct 22 09:48:02.669713 2013] [:error] [pid 623] if not _sslLogin(environ, session, username): [Tue Oct 22 09:48:02.669717 2013] [:error] [pid 623] File "/usr/share/koji-web/scripts/index.py", line 125, in _sslLogin [Tue Oct 22 09:48:02.669722 2013] [:error] [pid 623] proxyuser=username) [Tue Oct 22 09:48:02.669727 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1726, in ssl_login [Tue Oct 22 09:48:02.669732 2013] [:error] [pid 623] sinfo = self.callMethod('sslLogin', proxyuser) [Tue Oct 22 09:48:02.669746 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1775, in callMethod [Tue Oct 22 09:48:02.669752 2013] [:error] [pid 623] return self._callMethod(name, args, opts) [Tue Oct 22 09:48:02.669757 2013] [:error] [pid 623] File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1914, in _callMethod [Tue Oct 22 09:48:02.669761 2013] [:error] [pid 623] raise err [Tue Oct 22 09:48:02.669766 2013] [:error] [pid 623] AuthError: CN=mdct-koji.dartcontainer.com,OU=kojiweb,O=Dart Container Corp.,ST=Michigan,C=US is not authorized to login other users
My setup is as follows:
# grep ProxyDNs /etc/koji-hub/hub.conf ProxyDNs = /C=US/ST=Michigan/O=Dart Container Corp./OU=kojiweb/CN=mdct-koji.dartcontainer.com
This looks like a change in the format mod_ssl uses for the SSL_CLIENT_S_DN variable. If you change the ProxyDNs entry to match the
DN printed in the backtrace, it should fix the problem.
Sure enough, that did the trick. I'll make a note of this at https://fedoraproject.org/wiki/Koji/ServerHowTo. Any idea of what version of mod_ssl brought about this change?
-- John Florian
From: John.Florian@dart.biz
From: mikeb@redhat.com
This looks like a change in the format mod_ssl uses for the SSL_CLIENT_S_DN variable. If you change the ProxyDNs entry to match
the
DN printed in the backtrace, it should fix the problem.
Sure enough, that did the trick. I'll make a note of this at https://fedoraproject.org/wiki/Koji/ServerHowTo. Any idea of what version of mod_ssl brought about this change?
A bit of Googling shows that v2.3.11 brought about this change. To help others in the future, I've noted the requirements here: https://fedoraproject.org/wiki/Koji/ServerHowTo#Authentication_Configuration
-- John Florian
buildsys@lists.fedoraproject.org
-
John.Florian＠dart.biz -
Michael Cronenworth -
Mike Bonnet -
Mike McLean