Need Koji Server Setup Help

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

[Michael Cronenworth]

John.Florian(a)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(a)cchtml.com
>  
>  John.Florian(a)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(a)lists.fedoraproject.org wrote on 10/17/2013 08:20:05:

>  From: John.Florian(a)dart.biz
>  > From: mike(a)cchtml.com 
>  > 
>  > John.Florian(a)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

[Mike McLean]

On 10/21/2013 10:32 AM, John.Florian(a)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(a)redhat.com
>  
>  On 10/21/2013 10:32 AM, John.Florian(a)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

[Mike McLean]

On 10/22/2013 11:56 AM, John.Florian(a)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?

[Mike McLean]

On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
>  John.Florian(a)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=cf01c000a83702ee74de67b...

>  From: mikem(a)redhat.com
>  
>  On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
>  > John.Florian(a)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

[Mike Bonnet]

On 10/22/13 7:52 AM, John.Florian(a)dart.biz wrote:
>   > From: mikem(a)redhat.com
>   >
>   > On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
>   > > John.Florian(a)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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/buildsys
>

>  From: mikeb(a)redhat.com
>  
>  On 10/22/13 7:52 AM, John.Florian(a)dart.biz wrote:
>  >  > From: mikem(a)redhat.com
>  >  >
>  >  > On 10/16/2013 06:28 PM, Michael Cronenworth wrote:
>  >  > > John.Florian(a)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(a)dart.biz
>  
>  > From: mikeb(a)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