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
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 http://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
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
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
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
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@lists.fedoraproject.org
-
Brian LaMere -
Noriko Hosoi -
Rich Megginson