FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 09-01-2010, 01:33 AM
Noriko Hosoi
 
Default attributes from 00core.ldif put in 99users.ldif after schema update

Can we have some more information?*



Any special messages in the errors log?*

Server version.* Is MMR 2-way?*

Could it be possible to share the custom schema with us?



I assume you could search x121Address and internationalISDNNumber
attributes with the base DN "cn=schema" (i.e., they are visible on
the Console) and restarting the server does not change it.* If
that's the case, I think the server is in the right state now.* But
we'd like to reproduce the problem you encountered.



Thanks for your help.

--noriko



On 08/31/2010 05:17 PM, Brian LaMere wrote:
I updated my schema this afternoon in an MMR. *Since
it was an MMR, I stopped replication first (which was scary for
me, and I wish I could reload schema without doing that).



This wasn't the first time I uploaded a schema, and it is now
the second file I've created in my slapd-server/schema
directory. *The first extension was very short.



I used the same file on both servers, and on the first server
everything worked as expected. *On the second server however,
running the same schema-reload.pl command
with the exact same (I scp'd the file, no copy/paste...) ldif,
for some reason the x121Address and internationalISDNNumber
attributes jumped into my 99users.ldif file. *It is also, as
might be expected, in the 389-console window under user defined
attributes.



Both stayed in their normal (00core.ldif) location, they just
added to 99user.ldif as well. *I removed them from 99user.ldif,
reloaded again, and they did not reappear in 99user.ldif. *
Should I be concerned about there maybe being something wrong
with my schema that caused this? **Should I just move on, and
forget it happened?




Thanks,
Brian LaMere


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 03:40 AM
Brian LaMere
 
Default attributes from 00core.ldif put in 99users.ldif after schema update

2010/8/31 Noriko Hosoi <nhosoi@redhat.com>






Any special messages in the errors log? *
None; once the import succeeded (previous post about superior attributes), it succeeded without any errors.
*Server version.
Very fresh install. *Installed at*389-ds-base-1.2.6-0.1.a1, which is apparently still the most updated version.
** Is MMR 2-way?*

yes - though, I had disabled MMR during the import (completely; I went in to the replication tab and unchecked the "enable replica" box, which means I had to redo the agreements too).
*
Could it be possible to share the custom schema with us?

I could, yes - I'd rather not do it completely to the whole email list, but it's not really all that sensitive of information so I could send it to particular people. *I don't recall if fedora's bugzilla install allows for making private file uploads? *Is it worth opening a bug report since it only did it during the first load?



I assume you could search x121Address and internationalISDNNumber
attributes with the base DN "cn=schema" (i.e., they are visible on
the Console) and restarting the server does not change it.* If
that's the case, I think the server is in the right state now.* But
we'd like to reproduce the problem you encountered.

Yes, simply removing the entries from 99user.ldif, then reloading again, made it not repeat. *However, the first server which didn't do this did instead do something else I noticed later; I'll bring that up in a different post, since unlike this problem (which is almost just a bug report) the other I noticed later is an actual issue that needs to be resolved.
*One thing I realized is that the two servers aren't actually identical; the one that grabbed those two attributes and put them in 99user.ldif is an i686 box (running in a cloud, but that shouldn't matter...the architecture might, though). *The one that didn't exhibit that behavior was instead an x86_64 box (physical, non-vm).

Brian LaMere
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 03:52 AM
Rich Megginson
 
Default attributes from 00core.ldif put in 99users.ldif after schema update

Brian LaMere wrote:
> 2010/8/31 Noriko Hosoi <nhosoi@redhat.com <mailto:nhosoi@redhat.com>>
>
> Any special messages in the errors log?
>
>
> None; once the import succeeded (previous post about superior
> attributes), it succeeded without any errors.
>
>
> Server version.
>
>
> Very fresh install. Installed at 389-ds-base-1.2.6-0.1.a1, which is
> apparently still the most updated version.
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.
>
>
> Is MMR 2-way?
>
>
> yes - though, I had disabled MMR during the import (completely; I went
> in to the replication tab and unchecked the "enable replica" box,
> which means I had to redo the agreements too).
>
>
> Could it be possible to share the custom schema with us?
>
>
> I could, yes - I'd rather not do it completely to the whole email
> list, but it's not really all that sensitive of information so I could
> send it to particular people. I don't recall if fedora's bugzilla
> install allows for making private file uploads? Is it worth opening a
> bug report since it only did it during the first load?
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 assume you could search x121Address and internationalISDNNumber
> attributes with the base DN "cn=schema" (i.e., they are visible on
> the Console) and restarting the server does not change it. If
> that's the case, I think the server is in the right state now.
> But we'd like to reproduce the problem you encountered.
>
>
> Yes, simply removing the entries from 99user.ldif, then reloading
> again, made it not repeat. However, the first server which didn't do
> this did instead do something else I noticed later; I'll bring that up
> in a different post, since unlike this problem (which is almost just a
> bug report) the other I noticed later is an actual issue that needs to
> be resolved.
>
> One thing I realized is that the two servers aren't actually
> identical; the one that grabbed those two attributes and put them in
> 99user.ldif is an i686 box (running in a cloud, but that shouldn't
> matter...the architecture might, though). The one that didn't exhibit
> that behavior was instead an x86_64 box (physical, non-vm).
>
> Brian LaMere
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 04:12 AM
Brian LaMere
 
Default attributes from 00core.ldif put in 99users.ldif after schema update

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

Brian LaMere
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-01-2010, 01:21 PM
Rich Megginson
 
Default attributes from 00core.ldif put in 99users.ldif after schema update

Brian LaMere wrote:
>
>
> On Tue, Aug 31, 2010 at 8:52 PM, Rich Megginson <rmeggins@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 08:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org