3:17 p.m.
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.Thimm at ATrpms.net
3:23 p.m.
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
--
Jesse Keating
Release Engineer: Fedora
5:21 p.m.
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.
--
Axel.Thimm at ATrpms.net
7:33 p.m.
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?
--
Jesse Keating
Release Engineer: Fedora
2:11 a.m.
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 ... ;)
--
Axel.Thimm at ATrpms.net
9:14 a.m.
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. ;)
--
Axel.Thimm at ATrpms.net
9:14 a.m.
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?
--
Jesse Keating
Release Engineer: Fedora
12:14 p.m.
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.
--
Axel.Thimm at ATrpms.net
12:32 p.m.
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...
--
Jesse Keating
Release Engineer: Fedora
7:37 a.m.
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
6146
days inactive
6147
days old
buildsys@lists.fedoraproject.org
10 comments
3 participants
participants (3)
-
Axel Thimm -
Jesse Keating -
Till Maas