[389-users] attributes from 00core.ldif put in 99users.ldif after schema update

Brian LaMere brian at cukerinteractive.com
Wed Sep 1 04:12:36 UTC 2010


On Tue, Aug 31, 2010 at 8:52 PM, Rich Megginson <rmeggins at 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?

Brian LaMere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20100831/e2ce59ab/attachment.html>


More information about the 389-users mailing list