Brian LaMere wrote:
On Tue, Aug 31, 2010 at 8:52 PM, Rich Megginson <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>> wrote:
That was an early alpha version that was only in testing and
should not
have been pushed to stable (not sure how that happened). I strongly
encourage you to use 389-ds-base-1.2.6-1. This is now in the testing
repos and will be pushed to stable at the end of this week.
oops - well, maybe that will explain the other (actual) problem I had
after the schema update. I'll post on that when I get back to work
tomorrow and can describe it; it's something that I can only find/see
within the 389-console.
Yes, bugzilla does allow you to mark attachments as private. But
is it
possible to reproduce this issue with just some dummy data to
avoid the
risk entirely? And if it is indeed a bug, we should open a
bugzilla for
this issue.
I didn't create any actual entries, it was just definitions for
attributetypes and objectclasses. I don't really see much of a risk
(necessarily?) unless my schema was just insanely broken; I don't use
those two attributes anyway ;) happy to send the schema to whomever
to try on their own, or I could just spin up a new EC2 instance and
reload it "fresh" again and see if it happens again if loaded on an
ec2 i686 instance...
However, if what I'm using is an unstable version, it could just be
that it was triggered by doing a reload (regardless of content), and
had nothing to do with my schema at all. Is that more likely?
It could be - a1 had
many bugs in it - was not intended for production use.
schema reload does pretty much the same schema file processing as the
server does when it starts up - it does process 00core.ldif and the
other schema files.
Brian LaMere
------------------------------------------------------------------------
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users