Is there a mechanism to describe/discover information about the directory server implementation using the LDAP protocol itself? For example if you want to find out the specific version of the product being used on the backend.
As an analogy - in Oracle DBMS you can issue the following SQL to get the version information of the database you are connected to:
Select * from v$version
The JDBC protocol has a similar mechanism to get Database metadata. Does the LDAP protocol have any similar discovery features to find out information about the directory server being connected to? In my particular case I happen to know that the backend Directory server is Oracle/OID but is there a mechanism to describe the directory server using the LDAP protocol itself? Alternatively is there an Oracle/OID specific technique?
See "the root dse". Directory Servers might publish this info. See also RFC3045.
update:
In java:
LDAPConnection conn = new LDAPConnection(hostname,port);
SearchRequest req = new SearchRequest("",SearchScope.BASE,"(&)","+");
SearchResult result = conn.search(req);
// If the search succeeds, the result will comprise one entry,
// and that entry is the Root DSE:
dn:
subschemaSubentry: cn=schema
namingContexts: C=us
vendorName: UnboundID Corp.
vendorVersion: UnboundID Directory Server 4.1.0.6
Although Terry Gardner's solution works on many LDAP server implementations, unfortunately, version information is a broad and inconsistently supported among LDAP server implementations.
We show some of the more extensive methods to determine the vendor and versions.
-jim
Related
We are using Novel Ldap Api for all LDAP operations, i want to load my base schema ldif file to opendj without restarting the openDJ server.
So far, post setup we are manually copying the schema file to /config/schema location and we wanted it to do through Java code.
Since we already using Novel Ldap for all LDAP operations (modify, delete, read, add entry), we have to use the same.
When i tried, iam getting below exception, is there any solution please share?
SEVERE: Exception getting LDAP connection: LDAPLocalException:
com.novell.ldap.ldif_dsml.LDIFReader: Version line must be the first
meaningful line(on line 9 of the file) (82) Local Error
at com.novell.ldap.util.LDIFReader.(LDIFReader.java:156)
at com.novell.ldap.util.LDIFReader.(LDIFReader.java:80)
It looks like the Novell LDIF reader is strictly accepting LDIF version 1 from RFC 2849.
The first line should contain version: 1
OpenDJ does support adding schema over LDAP, it must be a change of cn=schema, adding values to the attributeTypes and objectClasses attributes.
I have a Websphere 8.5.5.12 installation with multiple applications running on it. For a given Middleware Server, I'd like to be able to list all applications associated with it using Jython.
I have gone as far as writing this code:
wsadmin>print AdminApp.list("WebSphere:cell=myCell,node=myNode")
However this is retrieving applications for a different Dynamic Cluster
If I add a specific server, it errors out
wsadmin>print AdminApp.list("WebSphere:cell=myCell,server=myServer")
ADMA0184E: myServer is not a valid target.
Your query should look like:
wsadmin>AdminApp.list("WebSphere:cell=myCell,node=myNode,server=server1")
It appears you're missing the node identifier in your query. And if wsadmin still returns "myServer is not a valid target", then the server name is wrong, try looking at your app server profile directory structure to double check it.
I am using Oracle Unified Directory ldap server and i want to rename OU which is having more user entries in it.I just executed below script in my staging ldap server to change the name of OU and it got worked and all user entries moved to new OU.
dn: ou=OLD,dc=example,dc=com
changetype: modrdn
newrdn: ou=NEW
deleteoldrdn: 1
but below oracle documentation tells, we cannot rename if RDN has any childeren.
https://docs.oracle.com/cd/E22289_01/html/821-1273/adding-modifying-and-deleting-directory-data.html
please suggest is it safe to rename ou using modrdn.
Well, according to Oracle on OUD, no.
MANY LDAP server implementations have the same limitation.
The LDAP server implementation controls this activity. Some LDAP server implementations of course do support performing a modRDN on a container.
AFIK, Microsoft Active Directory does.
eDirectory I know does as long as the container is a partition.
You can of course, perhaps, not ideal, create a new container with the new name and then modRDN the user within the "old" container into the new container.
I guess you just looked at the wrong documentation (OUD 11.1.1 was released in 2012).
Starting from 11.1.2.x (released in 2014), OUD documentation no more lists that limitation.
I am new to Mule and I have been struggling with a simple issue for a while now. I am trying to connect to flat files (.MDB, .DBF) located on a remote desktop through my Mule application using the generic database connector of Mule. I have tried different things here:
I am using StelsDBF and StelsMDB drivers for the JDBC connectivity. I tried connecting directly using jdbc URL - jdbc:jstels:mdb:host/path
I have also tried to access through FTP by using FileZilla server on remote desktop and using jdbc URL in my app - jdbc:jstels:dbf:ftp://user:password#host:21/path
None of these seem to be working as I am always getting Connection exceptions. If anyone has tried this before, what is the best way to go about it? Connecting a remote flat file with Mule? Your response on this will be greatly appreciated!
If you want to load the contents of the file inside a Mule flow you should use the file or FTP connector, i don't know for sure about your JDBC option.
With the File connector you can access local files (files on the server where mule is running), you could try to mount the folders as a share.
Or run an FTP server like you already tried, that should work.
There is probably an error in your syntax / connection.
Please paste the complete XML of your Mule flow so we can see what you are trying to do.
Your usecase is still not really clear to me, are you really planning to use http to trigger the DB everytime? Anyway did you try putting the file on a local path and use that path in your database url. Here is someone that says he had it working, he created a separate bean.
http://forums.mulesoft.com/questions/6422/setting_property_dynamically_on_jdbcdatasource.html
I think a local path is maybe possible and it's better to test that first.
Also take note of how to refer to a file path, look at the examples for the file connector: https://docs.mulesoft.com/mule-user-guide/v/3.7/file-transport-reference#namespace-and-syntax
If you manage to get it working and you can use the path directly in the JDBC url, you should have a look at the poll scope.
https://docs.mulesoft.com/mule-user-guide/v/3.7/poll-reference
You can use your DB connector as an inbound endpoint when wrapped in a poll scope.
I experienced the same issue when connect to Microsoft Access Database (*.mdb, *.accdb) using Mule Database Connector. After further investigation, it's solved by installing Microsoft Access Database Engine
Another issue, I couldn't pass parameter to construct a query as same as I do for other databases. e.g.: SELECT * FROM emplcopy WHERE id = #[payload.id]
To solve this issue:
I changed the Query type from Parameterized into Dynamic.
I generated the query inside Set Payload transformer (generate the query in form of String, e.g.: SELECT * FROM emplcopy WHERE id = '1').
Finally, put it into the Dynamic query area: #[payload]
I read on MOS Doc ID 1945619.1 that starting with the 12.1.3 Oracle HTTP Server (OHS), the mod_plsql feature has been deprecated and will not be included with the 12.2 Oracle HTTP Server.
For the future, Oracle recommends moving to Oracle REST Data Services (formerly known as Oracle APEX Listener) as an alternative to mod_plsql.
Our shop have a lot of mod_plsql applications (i.e. applications written usinjg HTP/HTF packages) in production. Since I don't know anything about Oracle REST Data Services I'm asking you if we can migrate the old applications to this new product without changing the code.
Thank you.
Kind regards, Cristian
Doug McMahon (Oracle employee) has a great open source module for Apache.
Apache PL/SQL Gateway Module
(mod_owa)
https://oss.oracle.com/projects/mod_owa/dist/documentation/modowa.htm
I am using it in a production environment and I highly recommend it. It's really fast and rock solid.
You need to do some compiling but it's worth it being able to use Apache 2.4 and mod_plsql.
Steps:
download httpd 2.4.? from apache.org + extract
If Centos 6 or less download apr and apr-util
configure with enable-so, make and make install
./configure --enable-so --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr
Download mod_owa + unzip
create empty directory. Copy all files from "apache24" into new folder. Copy all files from "src" to new folder
enter new folder and edit modowa.mk <-- important add $ORACLE_HOME, edit APACHE_TOP
Copy mod_owa.so to apache's modules
Add a modowa.conf in Apache's conf/ dir.
Example modowa.conf:
loadModule owa_module modules/mod_owa.so
<Location /pls>
Options None
SetHandler owa_handler
OwaUserid user/pass
OwaNLS AMERICAN_AMERICA.AL32UTF8
OwaPool 100
OwaStart "package.procedure"
OwaDocProc "wwv_flow_file_mgr.process_download"
OwaDocTable photos_upload BLOB_CONTENT
OwaUploadMax 50M
OwaCharset "utf8"
order deny,allow
allow from all
OwaReset LAZY
OwaCharsize 4
OwaFlex package.procedure
OwaHttp REST
</Location>
Before starting httpd ORACLE_HOME, NLS_LANG needs to be set (ORACLE_SID also if local). It needs access to an Oracle Home with libclntsh.so. (Oracle client will do).
I simply added oracle.conf (one line full path to oracle home/lib) under /etc/ld.so.conf.d (+ ldconfig)
Really scalable and a much cleaner setup then OHS.
My shop is pretty much in the same situation as you are.
We also have some very large mod_plsql/htp based applications and will have to migrate to the Oracle REST Data Services at some point.
We have already spend quite some time in testing different ORDS configuration and our overall conclusions are:
only APEX applications are fully supported
key functionality is still available
harder to configure and maintain
slight performance degradation
some mod_plsql configuration options do no longer exist or have changed
The biggest problems we are currently facing (and actually preventing us from switching to ORDS) are some restrictions when using non-APEX (pure HTF/HTP) applications.
We already filed some SR's because some functionality in ORDS (for example the file upload and download API) is only available when running an APEX application.
The biggest hurdle to get over is setting up Oracle Rest Services (ORS) and securing it. Once this is done, your web toolkit apps will work the same. The url may slightly change, so if you've referenced URLs using full paths as opposed to relative paths you might need modify code.
I am not sure if ORS is as powerful as Apache in areas like mod_rewrite, mod_proxy, virtual hosts with multiple ip addresses, etc...
Another open source alternative is tox.