Absolutely sure. I replaced the backslashes with slashes. I tried removing
the colon and changing the name of the keystore file, too. Here is the
exception I get with the work-around:
Unable to save configuration.
- Changes could not be saved to the connection.
java.lang.Exception: Changes could not be saved to the connection.
at
org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditorUtils.saveConfiguration(ServerConfigurationEditorUtils.java:370)
at
org.apache.directory.studio.apacheds.configuration.jobs.SaveConfigurationRunnable.run(SaveConfigurationRunnable.java:109)
at
org.apache.directory.studio.common.core.jobs.StudioJob.run(StudioJob.java:85)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I was just getting ready to test it with another version/build of Java. My
%JAVA_HOME% variable is set to jdk1.8.0_60. I'll set the VM in
ActiveDirectoryStudio.ini.
-----Original Message-----
From: Hal Deadman [mailto:[email protected]]
Sent: Friday, March 11, 2016 8:34 AM
To: [email protected]
Subject: Re: Directory Studio: Backslash in DN breaks studio
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:3
> 56) 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 !
>
>
