Hi,
I created a new update which was a security relevant update and was marked as such. bodhi offered me the possibility to push into testing or stable. I think the push into stable was offered only because it was maerked a security sensitive, so updates-testing could be shortcutted. I also know that the default policy was for security updates to bypass updates-testing entirely.
Still, the system offered my to go testing or stable, and I chose testing. The update later was simply saying that a request was made to move it, but not whereto. A while later the package made it into stable.
I'm not saying to change the policy, just noting a discrepancy in the application's workflow. Thanks!
On Thursday 21 June 2007 16:17:09 Axel Thimm wrote:
Hi,
I created a new update which was a security relevant update and was marked as such. bodhi offered me the possibility to push into testing or stable. I think the push into stable was offered only because it was maerked a security sensitive, so updates-testing could be shortcutted. I also know that the default policy was for security updates to bypass updates-testing entirely.
Still, the system offered my to go testing or stable, and I chose testing. The update later was simply saying that a request was made to move it, but not whereto. A while later the package made it into stable.
I'm not saying to change the policy, just noting a discrepancy in the application's workflow. Thanks!
Axel, can you file a ticket in bodhi's trac? That may be a bug. https://hosted.fedoraproject.org/projects/bodhi
On Thu, Jun 21, 2007 at 04:23:50PM -0400, Jesse Keating wrote:
On Thursday 21 June 2007 16:17:09 Axel Thimm wrote:
Hi,
I created a new update which was a security relevant update and was marked as such. bodhi offered me the possibility to push into testing or stable. I think the push into stable was offered only because it was maerked a security sensitive, so updates-testing could be shortcutted. I also know that the default policy was for security updates to bypass updates-testing entirely.
Still, the system offered my to go testing or stable, and I chose testing. The update later was simply saying that a request was made to move it, but not whereto. A while later the package made it into stable.
I'm not saying to change the policy, just noting a discrepancy in the application's workflow. Thanks!
Axel, can you file a ticket in bodhi's trac? That may be a bug. https://hosted.fedoraproject.org/projects/bodhi
I tried to, but
| TICKET_CREATE privileges are required to perform this operation
And trac munges the back operation in the browser.
Looks like the login timeouts are insanely short and trac has no recovery mechanism for that.
On Thursday 21 June 2007 18:21:58 Axel Thimm wrote:
And trac munges the back operation in the browser.
Looks like the login timeouts are insanely short and trac has no recovery mechanism for that.
That's... odd. how long does it take you to enter the ticket?
On Thu, Jun 21, 2007 at 08:33:16PM -0400, Jesse Keating wrote:
On Thursday 21 June 2007 18:21:58 Axel Thimm wrote:
And trac munges the back operation in the browser.
Looks like the login timeouts are insanely short and trac has no recovery mechanism for that.
That's... odd. how long does it take you to enter the ticket?
I typed in the ticket, then checked back with the email whether there was anything else I forgot to write and when returning to the browser I modified some text and pressed on Preview. Then Boom, no TRAC_CREATE permissions and my ticket submission couldn't be recovered by going back (nice wiping that tracs makes ...). Maybe I'm an infinitesimally slow typer.
All in all the issue is not how fast can a ticket submitter type, but whether there are proper recovery mechanisms for reauthetication and whether the reauthetication intervall isn't paranoically short (we don't have any reauthetication timeouts with bugzilla.redhat.com, and that works well there). I've seen similar with mirrormanager, but there the session recovers and continues smoothly after the reauthetication, while trac didn't even try to reauthenticate and ate my data.
Don't ask me to file that somewhere that will time out again ... ;)
On Fri, Jun 22, 2007 at 09:47:02AM -0400, Jesse Keating wrote:
On Friday 22 June 2007 03:11:06 Axel Thimm wrote:
Don't ask me to file that somewhere that will time out again ...
You mean like Trac's upstream? (:
I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent. ;)
On Friday 22 June 2007 10:14:36 Axel Thimm wrote:
I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent.
Hrm, would you like to lend me a hand then? We're just using http auth to a postgres server. Find me on IRC at your convenience and we'll go over http configs?
On Fri, Jun 22, 2007 at 10:14:05AM -0400, Jesse Keating wrote:
On Friday 22 June 2007 10:14:36 Axel Thimm wrote:
I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent.
Hrm, would you like to lend me a hand then? We're just using http auth to a postgres server. Find me on IRC at your convenience and we'll go over http configs?
We could do that, but I just verified Till's assumption that there is no timeout in fp.o's trac, but something else was amiss soem hours ago that logged us all out: I kept a session in bodhi's ticketing system idle for more than two hours and the session was still functional.
Of course, perhaps there really was a timeout problem and someone already fixed it by now.
The remaining question would be what happened this morning that logged out Till and me. Perhaps the logs of the machine indicate something, maybe someone performing upgrades and/or rebooting the system.
On Friday 22 June 2007 13:14:16 Axel Thimm wrote:
Of course, perhaps there really was a timeout problem and someone already fixed it by now.
I haven't touched any configs.
The remaining question would be what happened this morning that logged out Till and me. Perhaps the logs of the machine indicate something, maybe someone performing upgrades and/or rebooting the system.
Not on hosted.fp.o itself. Maybe the xen host...
On Fr Juni 22 2007, Axel Thimm wrote:
Looks like the login timeouts are insanely short and trac has no recovery mechanism for that.
I experienced some problems login in to hosted.fedoraprojects and bodhi or koji around the same time, maybe this was the cause. Iirc, the login on hosted.fedora... is http-based, so it should only time out, when you close your browser.
Regards, Till
buildsys@lists.fedoraproject.org
-
Axel Thimm -
Jesse Keating -
Till Maas