Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2015-06-08

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:01 MegaMatt joined #openam
03:27 auke- joined #openam
04:43 daveloper joined #openam
06:12 balo joined #openam
06:59 KermitTheFragger joined #openam
11:29 MegaMatt joined #openam
12:02 mckeanbs joined #openam
16:30 pcypher joined #openam
17:01 pcypher_ joined #openam
17:31 pcypher joined #openam
17:59 pcypher joined #openam
18:00 pcypher joined #openam
19:35 pcypher joined #openam
19:37 pcypher_ joined #openam
20:20 ikonia does anyone know how to delete a big OU quickly in opendj 2.6.1, I can't use ldapdelete as it "cannot be removed because it has subordinate entries"
20:20 ikonia it has a lot of entries in , it would take a long time to remove all the entries
20:20 ikonia I also think this can be improved in the java.properties to make ldapmodify and ldapdelete commands use more resources and get the job done quicker
20:21 ikonia any help and tips would be most welcome
20:22 MegaMatt export the data to LDIF, with an exclude option, and then to reimport the data overwriting the existing database?
20:22 ikonia thats an interesting idea,
20:22 ikonia not quite what I was thinking but certainly worth a look at
20:23 MegaMatt It’s what Ludo suggested: https://lists.forgerock.org/piperma​il/opendj/2015-February/004373.html
20:24 ikonia lets have a read
20:25 jjpp it assumes that you don't have to have other records to be available all the time?
20:25 MegaMatt Why do you say that, jjpp?
20:25 jjpp did not the reimport with overwrite start with drop everything?
20:26 MegaMatt You could take a server out of replication, blah blah
20:27 jjpp it could be complicated -- eg, if the other records could change during the reimport. and then you would have to use reimport for all the nodes, iirc (to get replication data to be in sync)?
20:28 MegaMatt yeah, it could be complicated . I will give you that
20:29 MegaMatt But it’s probably the fastest way to delete a large ou
20:29 jjpp that is true.
20:33 ikonia interesting
20:33 ikonia certainly lots to think about
20:33 pcypher joined #openam
20:35 ikonia a different approach too
20:36 ikonia wouldn't importing a blank OU be just as slow though
20:36 ikonia as it's still going to removing the legacy ou entry by entry with "null"
20:39 jjpp also, in the thread megamatt pointed at, someone hinted that if you don't need the delete to be atomic, you could just remove subentries one by one (with script generated with ldapsearch) and then you have problem of removing empty subtree..
21:25 ikonia I've got 100000 entries and even with a script, doing a loop through with with ldapdelete or ldapmodify as a delete is really slow
21:25 ikonia I'll need to look at better ways of doing this
21:30 jjpp well.. but do you need them to be deleted fast or is it just some garbage that needs to be cleaned to free the room?
22:21 MegaMatt joined #openam
22:50 pcypher joined #openam
23:18 pcypher joined #openam
23:37 pcypher joined #openam
23:50 pcypher joined #openam
23:57 MegaMatt joined #openam

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary