Are you sure the config editor doesn't work if you are using forward slash? I am able to save this as the keystore with M10 studio and M21 directory.
D:/ProgramData/xyz/ldap/instances/default/xyz.jks I did get different errors with different versions of studio and/or server. It is stored in ldap under: dn: ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config ... ads-keystoreFile: D:/ProgramData/xyz/ldap/instances/default/xyz.jks On Fri, Mar 11, 2016 at 8:18 AM, Pepersack, Bob G <[email protected]> wrote: > Is there a configuration where I can set my keystore settings with a text > editor, or some other kind of editor? > > When I build the project from "directory-studio-trunk.zip" with "mvn clean > install -Dmaven.test.skip=true", it throws this exception: > > [INFO] Scanning for projects... > [ERROR] Internal error: > org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception > parsing OSGi MANIFEST > C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF: > Manifest file not found -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > org.eclipse.tycho.core.osgitools.OsgiManifestParserException: Exception > parsing OSGi MANIFEST C:\bit9prog\dev\Installation\directory-studio-tru > nk\plugins\aciitemeditor\META-INF\MANIFEST.MF: Manifest file not found > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.eclipse.tycho.core.osgitools.OsgiManifestParserException: > Exception parsing OSGi MANIFEST > C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF: > Manifest file not found > at > org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifestFromDirectory(DefaultBundleReader.java:95) > at > org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest(DefaultBundleReader.java:59) > at > org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifest(DefaultBundleReader.java:50) > at > org.eclipse.tycho.core.osgitools.OsgiBundleProject.readArtifactKey(OsgiBundleProject.java:147) > at > org.eclipse.tycho.core.osgitools.OsgiBundleProject.setupProject(OsgiBundleProject.java:142) > at > org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject(DefaultTychoResolver.java:74) > at > org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:90) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) > ... 11 more > > -----Original Message----- > From: Emmanuel Lécharny [mailto:[email protected]] > Sent: Thursday, March 10, 2016 7:18 PM > To: [email protected]; [email protected] > Subject: Re: Directory Studio: Backslash in DN breaks studio > > Le 10/03/16 22:58, Stefan Seelmann a écrit : > > On 03/09/2016 07:59 PM, Emmanuel Lécharny wrote: > >> Le 09/03/16 18:54, Philip Peake a écrit : > >> Can you be a bit more explicit ? > >> > > Probably same cause as in > > https://issues.apache.org/jira/browse/DIRSTUDIO-1087 and > > https://issues.apache.org/jira/browse/DIRSERVER-2109 > > > I took some time last week-end to re-think the whole problem. There are a > lot of things we are doing wrong, IMO. Don't get me wrong though : > most of the time, it simply works. > > FTR, I send this mail to the dev list, copying it to the users list. > > <this is going to be a long mail...> > > First of all, we need to distinguish the clients from the server. They are > to different beasts, and we should assume the server *always* receive data > that are potentially harmful and incorrect. > > Then we also need to distinguish String values and Binary values. The > reason we make this distinction is that String values are going to be > encoded in UTF-8 thus using multi-bytes, and also because we need to > convert them from UTF-8 to Unicode (and back). > > Let's put aside the binary data at the moment. > > The server > ========== > > Value > ----- > > We receive UTF-8 Strings, we convert them to Unicode and now we can > process them in Java. We do need this conversion because we need to check > the values before injecting them in the backend. Doing such checks in UTF-8 > would be very impracticable. > > There is one critical operation that is done on values when we process > them : we most of the time need to compare them to another value : > typically, when we have an index associated with this value, or when we > have a search filter. Comparing two values is not as simple as doing an > lexicographic comparison sadly. We need to 'prepare' the values accordingly > to some very specific rules, and we should also 'normalize' > those values accordingly to some syntax. > > A comparison is done following this process : > > Val 1 -> normalization -> preparation-+ > \ > .--> Comparison > / Val 2 -> normalization -> > preparation-+ > > We can save some processing if one of the two values has already been > normalized or prepared. Actually, we should do that only once for each > value : when they are injected into the server for the first time. But > doing so would also induce some constraint : disk usage (saving many forms > of a data cost space, and time when it comes to read them from disk. This > is all about balance...). > > Anyway, most of the time, we get a value and we just need to store it into > the backend after having checked its syntax. And that's the key : > checking the syntax requires some preparation. Here is how we proceed when > we just need to chck teh syntax : > > Value --> normalization --> syntax check > > There is no string preparation. > > The normalization is specific to each AttributeType. The String > Preparation is the same for all the values. > > > Now, there are two specific use cases : filters, and DN. > > > Filter > ------ > > A filter always contains a String that needs to be processed to give a > tuple : <attributeType, value>. There are rules that must be applied to > transform the incoming filter to this tuple. Once we have created this > tuple, we can normalize and prepare the tuple's value : something that > might be complex, especially when dealing with substring matches. > > So for filter, the process is : > > fliter -> preProcessing -> Tuple<AttributeType, Value> -> normalization > -> preparation > > > The String preparation is required because the filter's value will be > compared with what we fetch from the backend. > > DN > -- > > The DN is not a String. It's a list of RDN, where each RDN is a list of > AVA, where each AVA is a tuple <attributeType, Value> Although, as a > filter, when it's received, or stored, it's as a String, and there are some > specific rules to follow to get the String being transformed to RDNs. > Bottom line, the DN preprocessing is the following : > > DN String --> preProcessing -> Rdns, AVA, Tuple<AttributeType, value> [-> > normalization -> preparation] (for each AVA) > > Again, the String preparation is needed because we will store the RDN into > an index, and that requires some comparison (note that it's not always the > case, typically for attributeType with a DN syntax). > > > Comparing values > ---------------- > > We saw that we need to normalize and prepare values before being able to > compare them. A good question would be : do we need to prepare the String > beforehand or when we need to compare values ? That's quite irrelevant : > it's a choice that need to be make at some point, but it just impacts the > performance and the storage size. We can consider that when we start > comparing two values, they are already prepared (either because we have > stored a prepared version of the String, or because we have just prepared > teh String on the fly before calling the compare method). > > > > The Client > ========== > > I will just talk about the Ldap API here, I'm not interested in any other > client. > > We have two flavors : schema eware and schema agnostic. We also have to > consider two aspects : when we send data to the server, and when we process > the result. > > > Schema agnostic client > ---------------------- > > There is no so much we can do here. we have no idea about what can be the > value's syntax, so we can't normalize the value. Bottom line, here is the > basic processing of a value sent to the server : > > - we don't touch the values. At all. We just convert them from Unicode to > UTF-8 > - we pre-process filters to feed the SearchRequest. values are unescaped > (ie the escaped chars are replaced by their binary counterpart) > - we don't touch the DN > > Whe values are received from the server, we need to process the data this > way : > > - we don't touch the values, we just convert them from UTF-8 to Unicode > - we don't touch the DN : it's already in String format, we just convert > them from UTF-8 to Unicode > > Schema aware client > ------------------- > > This is more complex, because now, we can process the values before > sending them to the server. This put some load on the client side instead > of pounding the server with incorrect data that will get rejected anyway. > > - Values : we normalize them, prepare them and check their syntax. At the > end, we convert the original value from Unicode to UTF-8. As we can see, we > lose the normalized and prepared value. > - Filter : we unescape them, then we convert them to UTF-8 > - Dn : we parse it, unescape it, normalizing each value, and at the end, > if the DN is valid, we send the original value as is, after having > converting it to UTF-8 > > > As we can see, all what we do is to check the values before sending them > to the remote server, except for the filter. > > For the received values, we first convert them to Unicode and that's > pretty much it. > > > Escaping > -------- > > DN and Filters need some pre-processing called unescaping when we have to > transform them from a String to an internal instance. For Filter, this is > always done on the client side, for the DN is done on the server side. The > idea is to transform those values from a String (human > readable) form to a binary form. > > > What we do wrong > ---------------- > > We will only focus on the schema aware API here. This is what we use on > the server side anyway... > > * First, we are depending on the same API on both side (client and > server). This make things more complex, because the context is different. > For instance, there is no need to parse the DN on the client, but we still > do it. I'm not sure that we could easily abvoid doing so. > To some extent, we are penalizing the client. > > * The most complex situation is when we have to procesds the DN. This is > always done in two phases : > - slice the DN into RDNs, the RDNs into AVAs containg Values > - apply the schema on each value > > We coulde easily imagine doing the processing in one single pass. > Actually, this is an error not to do so : this cost time, and the classes > are therfore not immutable. > > * One specific problematic point is when we process escaped chars. For > instance, something like : 'cn=a\ \ \ b' is just a cn with a value > containing 3 spaces. This is what should be returned to the user, and not a > value with only one space. *But* we will be able to retrieve this value > using one of those filters : (cn=a b) or (cn=a b) or (cn= > a b). Actually the number of spaces is irrelevant when comparing > the value, it's not when it comes to send back the value to the user. > Again, it has all to see with the distinction between storing values and > comparing values. > For filters, we must unescape the String before sending it to the server. > The server does not handle the Filter as a String. > > * The PrepareString class needs to be reviewed. We don't handle spaces the > way it's supposed to be done. > > Value Class > ----------- > > I'm not exactly proud of it. It was a way to avoid having code like : > > if ( value instance of String ) > { > // This is a String > } > else > { > // This is a byte[] > } > > so now, we have StringValue and BinaryValue, both of them could be used > with an AttributeType when they are SchemaAware. In retrospect, I think the > distinction between String and Binary values was an error. We should have a > Value, holding both, with a flag in it. Chaning that means we review the > entire code, again... > > > > Conclusion > ========== > > This is not a pleasant situation. We have some cases where we don't handle > things correctly, and this is largely due to some choices made a decade > ago. Now, I don't think that this should be kept as is. Sometime a big > refactoring is better than patching this and that... > > > Now, feel free to express yourself, I would be vert happy to have your > opinion. > > Many thanks ! > >
