On Thu, Aug 13, 2009 at 10:50:30AM -0700, Mike Castle wrote:
On Wed, Aug 12, 2009 at 10:18:30PM -0700, Mike Castle wrote:Severity: grave Justification: causes non-serious data lossIncorrect: No data was actually *lost*, right?I think it's correct. After all the definition is: 'causes non-serious data loss', """causes the loss of data on the system that is unimportant, or restorable without resorting to backup media""" Granted, I ran migrationtools once, two years ago. And now, trying to upgrade slapd caused there to be no ldap server running, because the data is invalid. As a result, I ended up with an ldap server with no data in it. Seemed lost to me. Sure, it was there in /var/backups. But it did involve a restore process that seems to imply the final clause there.
migrationtools did not hide your data, slapd did!If package A contains "test -e /arrrgh && rm -rf /home" and package B contains "touch arrrgh" then package B does not have a grave bug.
What you describe above is slapd upgrade script dropping (or hiding) your data when containing syntactic errors. If you find that behaviour a grave bug, then file a bugreort against that package.
migrationtools generating bogus ldif data is *not* a grave bug. Tolerating bogus ldif data and then later being more strict might be (but as you said the data was not exactly lost - and I suspect that slapd kindly asked you if you wanted to do the upgrade).
Please do not discuss slapd behaviour any further here - only migrationtools behaviour.
The fix for bug#307618 actually introduced another issue. Any system that used migrationtools to load services will be unable to upgrade to slapd 2.4.17-1 (actually, anything newer than 2.4.15). Reference bug#541292 for details. But essentially, `cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp' is an illegal value.At first glance, it seems that replacing the + with _ allows the file to load, but I'm not sure if that's sufficient for everything to work properly. I don't know if this dn: is used or just needs to be unique.In principle they are unique, but I suspect that most users of migrationtools won't actually use that data.I will simply disable that patch for now, and leave it to the user to decide if they want to a) use only some of the scripts og b) force-load with the result that tcp and udp entries are merged.A force load that results in the same string will never work in the long run. Better to give them the ability to have a valid string.
You are free to have that opinion. You would then choose a) above :-)
Maybe instead of `+' use `_and_' ?
I dislike inventing pseudo-separators. I thought I was clever discovering that "+" separator but learned a lesson here.
Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
