Cannot view list archive of private team

I don't see how this could be an LP issue, so kicking it to SSO.

I'm seeing the same issue. This is the error we usually see when a user isn't a member of the appropriate team, although you obviously are (as am I). Looking at the OpenID request form, it seems teams aren't being requested at all so I'm going to guess that there either a configuration issue with this mailing list or some machinery happening behind the scenes isn't working properly.

Can someone confirm which version of apache-openid (or the old mpopenid) the lists.lp server is using?

Looks like we're still using the old mpopenid. It's using a xmlrpc service on lp to get teams data. Is there any way to confirm this is being called with the right args and returning the right data?

Following discussions with gary, this looks like there's a problem between mpopenid and the lp xmlrpc service. We're not sure where but they're going to investigate. Bouncing back to launchpad-foundations.

What is an mpopenid ?

mpopenid is apparently a precursor of the apache-openid code, used by the mailing list code. One of the tasks to figure this out is to actually get a copy of it--I don't know where it is supposed to be, but I'm hoping LOSAs can point me in the right direction.

Stuart and I guess that the right fix long term would ideally be to use the apache-openid code and delete this bit, but we don't know what's going on in mpopenid enough to when or if we can.

Alternatively, the right fix long term might have something to do with switching to Mailman 3 as a library, which is what Barry intends to help us do. I don't know.

I suspect that tackling a short term solution is the right thing to do now.

Sadly, I no longer have a local copy of the mpopenid code.

Switching to Mailman 3 won't completely help for several reasons. First, we will still need a way to ask Launchpad about team membership. Second, the Launchpad archives are actually maintained in MHonArc, so there's not much Mailman specific there. :). So actually, this is an Apache/operational problem more than anything else.

(My work on MM3 is currently held up by the psycopg pinning issue. What's the ETA for working that out so the normal Maverick package can be used?)

Thanks for the reply, Barry.

The work to allow the normal Maverick package will begin when stub is back online, soon. Early-to-mid Nov., I hope.

[12:24pm] Chex: gary: so, mystery solved, openid was changed on forster with the Lucid upgrade, and that needs to be fixed. we already have a open ticket about this issue to get it resolved, I will f/u on this today

Apparently this isn't as simple as we'd thought - this is from a related RT, from Anthony Lenton:

"Just confirmed with Stuart M., both the regexp and xmlrpc handlers that are being used in that apache config were removed in release 2.0 as they were Launchpad-specific extensions. You'll need to get the old code working, from the branch[1] with (possibly older versions of) apache-modpython and python-openid installed, or work out a config that doesn't need the xmlrpc / regexp handlers. This is the approach Stuart discussed with Gary P. last week.

"[1] https://code.launchpad.net/~canonical-isd-hackers/apache-openid/trunk"

So, it sounds like the new version of the apache openid plugins don't support the options we need for this. I'm not sure at this stage who's responsibility it is to get this working... Any ideas?

Per the comment from stuartm on the RT, he and I had discussed that mpopenid should still be used, because it is the only thing that currently has the desired behavior. He felt that getting the apache-openid plugin to have the desired behavior would take longer. He expressed willingness to help with getting that working. Meanwhile, though, he felt that mpopenid should be made to work as it was before. My vague thought as to resolution was this:

1) I find out where mpopenid is, and try to figure out why it isn't working.
2) LOSAs get it working, with whatever help I can provide. This bug is now fixed, yay. We probably add a bug about dropping mpopenid and switching to apache-openid.
3) ISD eventually adds the features we need in apache-openid to replace mpopenid.
4) LOSAs switch. The bug to drop mpopenid is closed, yay.

Therefore, I started trying to get someone to show me the mpopenid code. This would help with steps 1 and 3. Getting a copy of mpopenid has proven to be difficult; I do not have one yet, after asking a group that includes Barry, Chex, and Francis. However, it seems we know the answer as to why mpopenid is not working: it is gone, replaced by apache-openid before apache-openid was ready to replace it.

The plan I outlined above still seems like the right thing to do for now, assuming that it will let us resolve this issue significantly faster than trying to get apache-openid to work.

If apache-openid needs to be resolved now, ISD certainly has the expertise and is the code owner, but Foundations will step up to the plate if we have to.

Either way, I suspect that finding a copy of mpopenid will help apache-openid get the needed features. The LOSAs are our only hope of that now, AFAIK.

You might get lucky that one of these branches has the code:

https://code.edge.launchpad.net/apache-openid

Alternatively, let's hope that we've got some forster backups somewhere!

Tom pointed out to me that the pertinent RT (https://rt.admin.canonical.com/Ticket/Display.html?id=41755) is farther along than this bug. For instance, from that ticket we now know where we can find mpopenid (https://bazaar.launchpad.net/%7Ecanonical-isd-hackers/apache-openid/trunk/annotate/head%3A/mpopenid.py).

This is the status on the RT, to the best of my understanding.

- mpopenid is a standalone script which we get from that apache-openid branch above. We don't need that packaged.
- We probably do need a Lucid port of whatever Hardy version of python-openid we had, and possibly apache-modpython.
- Right now, we are seeing if we can ask ISD to make those ports.

I'd be thrilled if ISD did the ports, but if not, it needs to be done: Foundations would give it a whirl, if no-one else seems willing/able to give it a try.

I'm seeing the same on the linaro-toolchain-benchmarks private list.

I thought there was a bug opened about this on https://bugs.launchpad.net/apache-openid Launchpad team integration was removed and we were not told. I understand the options are to revert to the older version of apache-openid, or to back port the original Lp xmlrpc integration code that was lost.

I'd like to point out that this is intermittent. Sometime it works, sometime it doesn't. I haven't identified the conditions which determine the outcome.

This is not intermittent. I am pretty sure it is impossible to view a private list since ISD removed the team URL parse feature from apache-openid. The apache mod cannot locate the team from the archive URL to ask Lp if the user a a team member.

wgrant attempted to restore the feature, but the code was significantly changed. I think a new feature is required. I do not see the apache-openid bug task on this bug, nor do I see it in apache-openid :(

Well, I know that I've encountered this symptom and then still been be able to access the archives eventually. I did access private archives since October. It might not be anymore. And AFAIK, we aren't using apache-openid yet for private mailing lists auth but still the mpopenid code. But maybe that changed recently, and that's now broken for good.

I know staging was reverted to be like production, but I believe production had already been changed, Our mods were replaced with the "standard" mods. SPM and Chex showed William and myself logs of our attempts to see a private archive, which were convincing evidence that the servers do no support our URL parsing config.

This is still broken for ~linaro-toolchain-benchmarks.

https://lists.launchpad.net/linaro-toolchain-benchmarks and https://lists.launchpad.net/canonical-tech/ both time out.

@michaelh1: 'time out' how? I see the message "Either you have not been granted access to this resource or your entitlement has timed out. Please try again." when I close and then re-visit a protected resource. I've also, intermittently, seen the OpenID login fail to start and had to re-click the link to a resource. Have you seen one of these or something else?

On 02/26/2012 04:16 PM, Michael Hope wrote:
> https://lists.launchpad.net/linaro-toolchain-benchmarks and
> https://lists.launchpad.net/canonical-tech/ both time out.
>

I can see it currently working. In my case, as I don't belong to the
linaro-toolchain-benchmarks team, I'm not granted access, but I can get
to the canonical-tech list with no issues.

Is this still happening?

thanks,
Ricardo

Ricardo, try again after a few minutes. I found that it forgot about my team membership for canonical-tech quickly until I logged out and in again.

@wgrant: that's bug #652877

It's a bit unreliable.

Last week i was trawling through old messages on canonical-tech and every few messages would bounce me through the openid dance again and again. Today I just clicked https://lists.launchpad.net/canonical-tech/ from the lp bug mail and got a new tab with the Times New Roman text telling me to login with openid. My browser is already authenticated and clicking the link a second time results in access.

Just tested again and it says timed out, yet I've only been away from the tab long enough to type the above paragraph. Reproducable easily by simply picking random threads in the archive to read.

In Chrome on Windows, none of the following will load:
 https://lists.launchpad.net/linaro-toolchain-benchmarks
 https://lists.launchpad.net/canonical-tech/
 http://lists.launchpad.net/

All fail with 'The connection was interrupted' or 'No data received' which suggests the TCP connection opens but nothing else happens.

I'll try on my other machine later.

With Precise under Chrome and Firefox, I get redirected to https://lists.launchpad.net/openid/+login "OpenID Authentication Required". Nothing else happens past that. There's no login button or redirect.

...but clicking through from the team page works.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/27/2012 05:24 PM, Michael Hope wrote:
> With Precise under Chrome and Firefox, I get redirected to
> https://lists.launchpad.net/openid/+login "OpenID Authentication
> Required". Nothing else happens past that. There's no login
> button or redirect.
>

While I agree this is not optimal, when that happens, the workaround
is to load up the page a second time (and then instead of the blank
page, the openid 'dance' actually succeeds).

We've also been experiencing some serious load in the list server,
which may explain some of these behaviours.

Sorry for the troubles, but please let us know if this issue persists
after a few days.

thanks

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9L6nYACgkQaHF+Qaymu6c7agCgi5pApi9Mw2Xccz7g4e3WPB+D
HFEAn1vej9hBAqMF7pq0fdnzGXs35FXY
=93Bs
-----END PGP SIGNATURE-----