Hi All,
> Multiple Ventors SSH Server Remote Buffer Overflow Vulnerability
> http://www.securityfocus.com/bid/17958
This is a _server_ side vulnerability, but what a coincidence!!!
You guys without Putty: Are you sure that there was _never_
any remote connection as root from any side?
Frank
I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After a
day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I cam to the
same 1 billion sec
dhogaza@PACIFIER.COM wrote:
I have three servers running identical installations of
AOLserver/3.3.1+ad13. On two (development and production, very low and
relatively low traffic volumes respectively) all scheduled procs have
stopped firing.
My God, it sounds to me like you're all being bi
'Jesus' Jeff Rogers wrote:
I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After
a day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I ca
On May 19, 2006, at 1:04 PM, 'Jesus' Jeff Rogers wrote:
The only bug is that Ns_CondTimedWait doesn't do any wraparound on
the time parameter. All the same, I've been enjoying telling
people that I hit my first y2038 bug.
So are you saying you've fixed it, or just that you've narrowed it
On 2006.05.19, 'Jesus' Jeff Rogers <[EMAIL PROTECTED]> wrote:
> Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my
> database connections.
Ahahaha! Yes, in the back of my head I always wondered (and never
bothered to compute) when that silly value of 10^9 would bite someon
I fixed it by simply changing my MaxOpen/MaxIdle settings to "0" which
is interpreted as "forever" which is probably what the original "one
BILLION seconds" was undoubtedly intended to be.
It probably wouldn't hurt for Ns_AdjTime (in nsthread/time.c) to check
for negative seconds and have it f
Ahhh good detective work.
Problem solved.
Thanks!!!
Zach Shaw
Web Developer, Library and Technology Services
Brandeis University
[EMAIL PROTECTED]
781-736-4206
On May 19, 2006, at 4:32 PM, 'Jesus' Jeff Rogers wrote:
I fixed it by simply changing my MaxOpen/MaxIdle settings to "0"
whic
Stan Kaufman wrote:
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
my database connections. My system is ACS-derived, so I wouldn't be
surprised if these database settings are common in other ACS-derived
systems.
What do you think is the reason that not all systems enc
On 5/19/06, 'Jesus' Jeff Rogers <[EMAIL PROTECTED]> wrote:
I imagine on Linux it manifests differently; on Solaris I got the EINVAL
return from pthread_cond_timedwait (of course it isn't documented that
this can mean a bad time, it usually means a bad pointer) but on linux
with a different pthre
> dhogaza@PACIFIER.COM wrote:
>> My God, it sounds to me like you're all being bit by the Y2.006K
>> problem! :)
>>
> That answer is closer than you think (at least if everyone is having the
> same problem I was) ... actually it's Y2.038K
Yes, indeed, I suspect everyone here on the list is aware
> On 2006.05.19, 'Jesus' Jeff Rogers <[EMAIL PROTECTED]> wrote:
> Ahahaha! Yes, in the back of my head I always wondered (and never
> bothered to compute) when that silly value of 10^9 would bite someone.
> Guess it's May 12, 2006. :-)
>
> Can everyone who's affected go and change MaxIdle and Ma
On 5/19/06, Stan Kaufman <[EMAIL PROTECTED]> wrote:
What do you think is the reason that not all systems encounter this 1B
second issue? The passage of time is the one factor inevitably shared by
every system running aolserver, yet not every system barfs in the same
fashion. Why?
In our case w
> (which I think was done to work around some ancient bug in an ancient
> version of the nsoracle driver) then you get the problem.
I think the problem was in the oracle library (OCI), but it's been a long,
long time.
> I imagine on Linux it manifests differently; on Solaris I got the EINVAL
> re
>> On 2006.05.19, 'Jesus' Jeff Rogers <[EMAIL PROTECTED]> wrote:
> I admit I've not been paying as close attention to this thread as I might,
> as I've not used 3.3 in years.
Next time remind me that this is a good reason to think before posting,
folks!
--
AOLserver - http://www.aolserver.com/
On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
> > (which I think was done to work around some ancient bug in an ancient
> > version of the nsoracle driver) then you get the problem.
>
> I think the problem was in the oracle library (OCI), but it's been a long,
> long time.
'Jesus' Jeff Rogers wrote:
Simple, because it's a config file setting, not anything to do with
the underlying system. If your config file has
[ns/db/pool/main]
MaxOpen=10
MaxIdle=10
(which I think was done to work around some ancient bug in an ancient
version of the nsoracle
Stan Kaufman wrote:
Not defining these two vars must have been the way the 3.2.5 config
file was distributed back in the day
Yup, that was the case: http://openacs.org/doc/openacs-3/nsd.txt
Interesting that that inoculated OpenACS 3.2.5 systems from this problem.
--
AOLserver - http://www.ao
> On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
> # You can also set
> # them to zero, but at the time the bug was discovered, AOLserver had
> # a bug that prevented you from setting them to zero.
Yeah, I knew there was a reason a big number rather than zero was chose
On 2006.05.19, Stan Kaufman <[EMAIL PROTECTED]> wrote:
> >Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on
> >my database connections.
> >My system is ACS-derived, so I wouldn't be surprised if these database
> >settings are common in other ACS-derived systems.
>
> What do y
On 2006.05.19, dhogaza@PACIFIER.COM wrote:
> The billion seconds added to the current time when the database handle's
> created is causing the problem, with Solaris being nice enough to toss an
> error, Linux just screwing up.
To be fair, Linux isn't "screwing up" -- the time-to-sleep being
passe
On 2006.05.19, dhogaza@PACIFIER.COM wrote:
> > On Fri, May 19, 2006 at 02:30:54PM -0700, dhogaza@PACIFIER.COM wrote:
> > # You can also set
> > # them to zero, but at the time the bug was discovered, AOLserver had
> > # a bug that prevented you from setting them to zero.
>
> Yeah, I knew th
Dossy Shiobara wrote:
Generally, the only time I've seen people config the MaxOpen and MaxIdle
to 1B seconds is when they're using an ACS or OpenACS recommended
configuration.
It might be a good idea for the OpenACS folks to edit/update their
documentation and sample configs to correct this, as
> On 2006.05.19, Stan Kaufman <[EMAIL PROTECTED]> wrote:
> It might be a good idea for the OpenACS folks to edit/update their
> documentation and sample configs to correct this, as well ... although
> it'll never be May 13, 2006 ever again, so maybe it's a non-issue. :-)
Now that zero works, we'
> If only folks chose 10^8 instead of 10^9 ... it would have been 1157
> days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
> encountered this "weird thread hanging bug" until Nov 18, 2034. :-)
>
> -- Dossy
Shit like this happens when you know your software platform's reliable and
m
> If only folks chose 10^8 instead of 10^9 ... it would have been 1157
> days or 3.1 years worth of MaxOpen/MaxIdle, and we wouldn't have
> encountered this "weird thread hanging bug" until Nov 18, 2034. :-)
>
> -- Dossy
Shit like this happens when you know your software platform's reliable! :)
26 matches
Mail list logo