You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Sherman Lilly <sh...@gmail.com> on 2016/01/19 14:46:45 UTC
DHCP using Apache directory server
I have got my schemas installed and working and the directory server is
working properly. I am trying to add a value to "dhcpOption" and it will
only accept a binary value. I figured out the value has to be utf8 encoded
value. How do I use Directory Studio to insert this value? Let say the
string is "broadcast 192.168.255.255". Not really sure how to convert that
to utf8 encoded binary and insert it into "dhcpOption" thorugh Directory
Studio.
Any help is appreciated.
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
That is what it was. I will continue and see if anything else comes.
On Mon, Feb 1, 2016 at 2:57 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 01/02/16 20:22, Sherman Lilly a écrit :
> > Remember from previous post that I modified the dhcp schema to fix a
> > attribute description bug. But when I create the attribute it is list in
> > the drop down list when I select it. Also when I load the schema in a
> > schema browser it shows up.
>
> Studio will shwo all the schema elements it can read. That does not mea
> that the server will accept them, if for instance the dhcp schela is
> disabled.
>
> Can you tell me what the value of the m-disabled attribute when you
> click on the cn=dhcp,ou=schema entry on your server's DIT ? If it's
> TRUE, change it to FALSE, save the changed entry, and restart your server.
>
> I just tested it, it works (and I get the same error when the dhcp
> schema m-disabled attribute is TRUE)
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 01/02/16 20:22, Sherman Lilly a écrit :
> Remember from previous post that I modified the dhcp schema to fix a
> attribute description bug. But when I create the attribute it is list in
> the drop down list when I select it. Also when I load the schema in a
> schema browser it shows up.
Studio will shwo all the schema elements it can read. That does not mea
that the server will accept them, if for instance the dhcp schela is
disabled.
Can you tell me what the value of the m-disabled attribute when you
click on the cn=dhcp,ou=schema entry on your server's DIT ? If it's
TRUE, change it to FALSE, save the changed entry, and restart your server.
I just tested it, it works (and I get the same error when the dhcp
schema m-disabled attribute is TRUE)
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
Remember from previous post that I modified the dhcp schema to fix a
attribute description bug. But when I create the attribute it is list in
the drop down list when I select it. Also when I load the schema in a
schema browser it shows up.
On Mon, Feb 1, 2016 at 11:35 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 01/02/16 17:32, Sherman Lilly a écrit :
> > Sorry for the typo. I have to type what I see. Copy and paste isn't
> working.
> >
> > When you set object Class dhcpserver it requires the attribute
> > dhcpservicedn.
>
> It should be present. Is the DHCP schema enabled ?
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 01/02/16 17:32, Sherman Lilly a écrit :
> Sorry for the typo. I have to type what I see. Copy and paste isn't working.
>
> When you set object Class dhcpserver it requires the attribute
> dhcpservicedn.
It should be present. Is the DHCP schema enabled ?
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
Sorry for the typo. I have to type what I see. Copy and paste isn't working.
When you set object Class dhcpserver it requires the attribute
dhcpservicedn.
On Mon, Feb 1, 2016 at 9:09 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 01/02/16 14:53, Sherman Lilly a écrit :
> > OK. I have blanked out the data and restarted the server. The server
> starts
> > up fine now. Now anytime I try to add a dhcp shema definition I get an
> > error.
> >
> > ERR_04269 ATTRIBUTE_TYPE for OID dhcpserverdn does not exist!
> This attribute is not defined in any schema.
>
> Where does it come from ?
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 01/02/16 14:53, Sherman Lilly a écrit :
> OK. I have blanked out the data and restarted the server. The server starts
> up fine now. Now anytime I try to add a dhcp shema definition I get an
> error.
>
> ERR_04269 ATTRIBUTE_TYPE for OID dhcpserverdn does not exist!
This attribute is not defined in any schema.
Where does it come from ?
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
OK. I have blanked out the data and restarted the server. The server starts
up fine now. Now anytime I try to add a dhcp shema definition I get an
error.
ERR_04269 ATTRIBUTE_TYPE for OID dhcpserverdn does not exist!
On Fri, Jan 29, 2016 at 1:11 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 29/01/16 00:45, Sherman Lilly a écrit :
> > I haven't installed any relevant data that is important. So deleting the
> > database is not important but how do I start a new and make that
> > modification to the dhcp schema and the server startup properly. Since it
> > wasn't working I did load any data yet. This is just to see if I can get
> it
> > to work with DHCP lookup.
> As soon as you have blanked your data, restarted the server, then you
> should be able to modify your schema, stop and restart the server, and
> then reinject the data into your started server.
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 29/01/16 00:45, Sherman Lilly a écrit :
> I haven't installed any relevant data that is important. So deleting the
> database is not important but how do I start a new and make that
> modification to the dhcp schema and the server startup properly. Since it
> wasn't working I did load any data yet. This is just to see if I can get it
> to work with DHCP lookup.
As soon as you have blanked your data, restarted the server, then you
should be able to modify your schema, stop and restart the server, and
then reinject the data into your started server.
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
I haven't installed any relevant data that is important. So deleting the
database is not important but how do I start a new and make that
modification to the dhcp schema and the server startup properly. Since it
wasn't working I did load any data yet. This is just to see if I can get it
to work with DHCP lookup.
On Jan 28, 2016 12:00 PM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
> Le 28/01/16 15:46, Sherman Lilly a écrit :
> > How to do I do that?
>
> Assuming that you have a backup of your database content in a LDIF
> format, just delete the existing data from your disk (<apacheds
> root>/instance/<your instance>/partitions/<your database>)
>
> Typically, on my linux box :
>
> /opt/apacheds-2.0.0-M22-SNAPSHOT/instances/default/partitions/example :
> [root@brie example]# ll
> total 620
> -rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.1.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.1.lg
> -rw-r--r--. 1 root root 222 Jan 27 15:55
> 0.9.2342.19200300.100.1.1-uid.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.25.db
> -rw-r--r--. 1 root root 257 Jan 27 15:55
> 0.9.2342.19200300.100.1.25-dc.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.25.lg
> -rw-r--r--. 1 root root 273 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.3-apachePresence.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.lg
> -rw-r--r--. 1 root root 264 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.50-apacheRdn.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.lg
> -rw-r--r--. 1 root root 211 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.5-apacheOneAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.lg
> -rw-r--r--. 1 root root 208 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.6-apacheSubAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.lg
> -rw-r--r--. 1 root root 204 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.7-apacheAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.db
> -rw-r--r--. 1 root root 246 Jan 27 15:55
> 1.3.6.1.4.1.4203.666.1.7-entryCSN.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.db
> -rw-r--r--. 1 root root 215 Jan 27 15:55
> 1.3.6.1.4.1.5322.10.1.1-krb5PrincipalName.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.lg
> -rw-r--r--. 1 root root 148 Jan 27 15:55 2.5.18.5-administrativeRole.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.18.5.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.18.5.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.0.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.0.lg
> -rw-r--r--. 1 root root 184 Jan 27 15:55 2.5.4.0-objectClass.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.11.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.11.lg
> -rw-r--r--. 1 root root 257 Jan 27 15:55 2.5.4.11-ou.txt
> -rw-r--r--. 1 root root 40960 Jan 27 15:55 master.db
> -rw-r--r--. 1 root root 8 Jan 27 15:55 master.lg
>
>
> Just get rid of all that. They will be recreated when you inject the
> LDIF that contains your data.
>
>
>
Re: DHCP using Apache directory server
Posted by Hal Deadman <ha...@gmail.com>.
There may be an easier way to get an LDIF dump but I have this method run
nightly by a Spring task in an LDAP related web application. I haven't
switched over to ApacheDS in production but I use this against 389-ds in
production and ApacheDS in development. This dumps people, groups and
organization units to a daily rolling log file (configured via logback). It
helps me sleep easier with my current single directory server and it is
what is making me comfortable enough to switch to ApacheDS, knowing that if
there is a corruption I can recover from a recent backup. I don't recall
why I used ldaptive instead of ApacheDS ldif functionality. This wouldn't
handle a really large directory because it's reading the entire directory
into memory and writing everything to a String before logging it. The
directory I am using it on has less than 1500 entries, mostly people.
import java.io.IOException;
import java.io.StringWriter;
import java.util.Collection;
import java.util.Map;
import java.util.TreeMap;
import org.apache.commons.lang.StringUtils;
import org.ldaptive.Connection;
import org.ldaptive.DefaultConnectionFactory;
import org.ldaptive.LdapEntry;
import org.ldaptive.Response;
import org.ldaptive.SearchFilter;
import org.ldaptive.SearchRequest;
import org.ldaptive.SearchResult;
import org.ldaptive.control.util.PagedResultsClient;
import org.ldaptive.io.LdifWriter;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class LdifDumper {
private static final Logger LDIF_BACKUP =
LoggerFactory.getLogger("LDIF_BACKUP");
private static final Logger logger =
LoggerFactory.getLogger(LdifDumper.class);
public void dumpLdif(DefaultConnectionFactory connectionFactory, String
baseDn) {
String[] objectClasses = { "domain", "organizationalunit",
"groupOfUniqueNames", "person" };
StringWriter writer = new StringWriter();
LdifWriter ldifWriter = new LdifWriter(writer);
try (Connection conn = connectionFactory.getConnection()) {
conn.open();
PagedResultsClient client = new PagedResultsClient(conn, 500);
for (int i = 0; i < objectClasses.length; i++) {
Map<String, LdapEntry> entryMap = new TreeMap<String, LdapEntry>();
SearchFilter filter = new SearchFilter("(objectclass=" + objectClasses[i] +
")");
SearchRequest request = new SearchRequest(baseDn, filter);
request.setSearchScope(org.ldaptive.SearchScope.SUBTREE);
Response<SearchResult> response = client.executeToCompletion(request);
SearchResult result = response.getResult();
Collection<LdapEntry> entries = result.getEntries();
for (LdapEntry ldapEntry : entries) {
String key = ldapEntry.getDn();
// hack - count commas so higher level entities sort first
// (e.g. for nested OUs - create ou=Groups before ou=Groups,ou=App1 )
int commaCount = StringUtils.countMatches(key, ",");
key = commaCount + key;
entryMap.put(key, ldapEntry);
}
// print out sorted entries
for (Map.Entry<String, LdapEntry> mapEntry : entryMap.entrySet()) {
ldifWriter.write(new SearchResult(mapEntry.getValue()));
}
}
LDIF_BACKUP.info(writer.toString());
} catch (org.ldaptive.LdapException | IOException e) {
logger.error("Error dumping users to ldif: " + e.getMessage(),e);
}
}
}
On Thu, Jan 28, 2016 at 12:00 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 28/01/16 15:46, Sherman Lilly a écrit :
> > How to do I do that?
>
> Assuming that you have a backup of your database content in a LDIF
> format, just delete the existing data from your disk (<apacheds
> root>/instance/<your instance>/partitions/<your database>)
>
> Typically, on my linux box :
>
> /opt/apacheds-2.0.0-M22-SNAPSHOT/instances/default/partitions/example :
> [root@brie example]# ll
> total 620
> -rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.1.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.1.lg
> -rw-r--r--. 1 root root 222 Jan 27 15:55
> 0.9.2342.19200300.100.1.1-uid.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.25.db
> -rw-r--r--. 1 root root 257 Jan 27 15:55
> 0.9.2342.19200300.100.1.25-dc.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.25.lg
> -rw-r--r--. 1 root root 273 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.3-apachePresence.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.lg
> -rw-r--r--. 1 root root 264 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.50-apacheRdn.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.lg
> -rw-r--r--. 1 root root 211 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.5-apacheOneAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.lg
> -rw-r--r--. 1 root root 208 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.6-apacheSubAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.lg
> -rw-r--r--. 1 root root 204 Jan 27 15:55
> 1.3.6.1.4.1.18060.0.4.1.2.7-apacheAlias.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.db
> -rw-r--r--. 1 root root 246 Jan 27 15:55
> 1.3.6.1.4.1.4203.666.1.7-entryCSN.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.db
> -rw-r--r--. 1 root root 215 Jan 27 15:55
> 1.3.6.1.4.1.5322.10.1.1-krb5PrincipalName.txt
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.lg
> -rw-r--r--. 1 root root 148 Jan 27 15:55 2.5.18.5-administrativeRole.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.18.5.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.18.5.lg
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.0.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.0.lg
> -rw-r--r--. 1 root root 184 Jan 27 15:55 2.5.4.0-objectClass.txt
> -rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.11.db
> -rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.11.lg
> -rw-r--r--. 1 root root 257 Jan 27 15:55 2.5.4.11-ou.txt
> -rw-r--r--. 1 root root 40960 Jan 27 15:55 master.db
> -rw-r--r--. 1 root root 8 Jan 27 15:55 master.lg
>
>
> Just get rid of all that. They will be recreated when you inject the
> LDIF that contains your data.
>
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 28/01/16 15:46, Sherman Lilly a écrit :
> How to do I do that?
Assuming that you have a backup of your database content in a LDIF
format, just delete the existing data from your disk (<apacheds
root>/instance/<your instance>/partitions/<your database>)
Typically, on my linux box :
/opt/apacheds-2.0.0-M22-SNAPSHOT/instances/default/partitions/example :
[root@brie example]# ll
total 620
-rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.1.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.1.lg
-rw-r--r--. 1 root root 222 Jan 27 15:55 0.9.2342.19200300.100.1.1-uid.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 0.9.2342.19200300.100.1.25.db
-rw-r--r--. 1 root root 257 Jan 27 15:55 0.9.2342.19200300.100.1.25-dc.txt
-rw-r--r--. 1 root root 41362 Jan 27 15:55 0.9.2342.19200300.100.1.25.lg
-rw-r--r--. 1 root root 273 Jan 27 15:55
1.3.6.1.4.1.18060.0.4.1.2.3-apachePresence.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.3.lg
-rw-r--r--. 1 root root 264 Jan 27 15:55
1.3.6.1.4.1.18060.0.4.1.2.50-apacheRdn.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.50.lg
-rw-r--r--. 1 root root 211 Jan 27 15:55
1.3.6.1.4.1.18060.0.4.1.2.5-apacheOneAlias.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.5.lg
-rw-r--r--. 1 root root 208 Jan 27 15:55
1.3.6.1.4.1.18060.0.4.1.2.6-apacheSubAlias.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.6.lg
-rw-r--r--. 1 root root 204 Jan 27 15:55
1.3.6.1.4.1.18060.0.4.1.2.7-apacheAlias.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.18060.0.4.1.2.7.lg
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.db
-rw-r--r--. 1 root root 246 Jan 27 15:55
1.3.6.1.4.1.4203.666.1.7-entryCSN.txt
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.4203.666.1.7.lg
-rw-r--r--. 1 root root 0 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.db
-rw-r--r--. 1 root root 215 Jan 27 15:55
1.3.6.1.4.1.5322.10.1.1-krb5PrincipalName.txt
-rw-r--r--. 1 root root 41362 Jan 27 15:55 1.3.6.1.4.1.5322.10.1.1.lg
-rw-r--r--. 1 root root 148 Jan 27 15:55 2.5.18.5-administrativeRole.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.18.5.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.18.5.lg
-rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.0.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.0.lg
-rw-r--r--. 1 root root 184 Jan 27 15:55 2.5.4.0-objectClass.txt
-rw-r--r--. 1 root root 0 Jan 27 15:55 2.5.4.11.db
-rw-r--r--. 1 root root 41362 Jan 27 15:55 2.5.4.11.lg
-rw-r--r--. 1 root root 257 Jan 27 15:55 2.5.4.11-ou.txt
-rw-r--r--. 1 root root 40960 Jan 27 15:55 master.db
-rw-r--r--. 1 root root 8 Jan 27 15:55 master.lg
Just get rid of all that. They will be recreated when you inject the
LDIF that contains your data.
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
How to do I do that?
On Thu, Jan 28, 2016 at 9:33 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 28/01/16 14:50, Sherman Lilly a écrit :
> > Adding the above ldif resulted in the server not able to start. Running
> > server in console mode shows this error.
> >
> > ERR_134 Cannot deserialize the entry : ERR_04269 ATTRIBUTE_TYPE for OID
> > 2.16.840.1.113719.1.203.4.19 does not exist!
>
> Yes, you need to celanup the server and reinject the full entries,
> because the schema has changed and it impacts the existing entries.
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 28/01/16 14:50, Sherman Lilly a écrit :
> Adding the above ldif resulted in the server not able to start. Running
> server in console mode shows this error.
>
> ERR_134 Cannot deserialize the entry : ERR_04269 ATTRIBUTE_TYPE for OID
> 2.16.840.1.113719.1.203.4.19 does not exist!
Yes, you need to celanup the server and reinject the full entries,
because the schema has changed and it impacts the existing entries.
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
Adding the above ldif resulted in the server not able to start. Running
server in console mode shows this error.
ERR_134 Cannot deserialize the entry : ERR_04269 ATTRIBUTE_TYPE for OID
2.16.840.1.113719.1.203.4.19 does not exist!
On Tue, Jan 26, 2016 at 5:38 PM, Stefan Seelmann <ma...@stefan-seelmann.de>
wrote:
> On 01/26/2016 07:56 PM, Sherman Lilly wrote:
> > Can I fix the schema in my current version 2.0.0? If so how do I do this?
>
> Yes, you can change the syntax of dhcpOption attribute, e.g. you can
> apply the following LDIF:
>
> dn: m-oid=2.16.840.1.113719.1.203.4.7,
> ou=attributeTypes,cn=dhcp,ou=schema
> changetype: modify
> replace: m-syntax
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
> -
>
> Afterwards you need to restart the server.
>
> HTH,
> Stefan
>
>
Re: DHCP using Apache directory server
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 01/26/2016 07:56 PM, Sherman Lilly wrote:
> Can I fix the schema in my current version 2.0.0? If so how do I do this?
Yes, you can change the syntax of dhcpOption attribute, e.g. you can
apply the following LDIF:
dn: m-oid=2.16.840.1.113719.1.203.4.7,
ou=attributeTypes,cn=dhcp,ou=schema
changetype: modify
replace: m-syntax
m-syntax: 1.3.6.1.4.1.1466.115.121.1.26
-
Afterwards you need to restart the server.
HTH,
Stefan
Re: DHCP using Apache directory server
Posted by Sherman Lilly <sh...@gmail.com>.
Can I fix the schema in my current version 2.0.0? If so how do I do this?
On Wed, Jan 20, 2016 at 7:04 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 20/01/16 23:16, Stefan Seelmann a écrit :
> > On 01/19/2016 02:46 PM, Sherman Lilly wrote:
> >> I have got my schemas installed and working and the directory server is
> >> working properly. I am trying to add a value to "dhcpOption" and it will
> >> only accept a binary value. I figured out the value has to be utf8
> encoded
> >> value. How do I use Directory Studio to insert this value? Let say the
> >> string is "broadcast 192.168.255.255". Not really sure how to convert
> that
> >> to utf8 encoded binary and insert it into "dhcpOption" thorugh Directory
> >> Studio.
> >>
> >> Any help is appreciated.
> > First I have to tell you that the DHCP (and also DNS) servers are not
> > maintained since years, I not even can find any server-side integration
> > test that tests the functionality. So very likely those won't work at
> > all or include major bugs. Help to test, fix, and document is however
> > appreciated :)
>
> indeed...
> >
> > I just tried to add a "dhcpOption" value with Studio. As this attribute
> > is of syntax octet string the Hex Editor opens. I then choosed the "Edit
> > as Text" option. The resulting binary is a proper UTF-8 encoded value.
> > But when saving that there is an error on server side, I think that is a
> > bug in the LDAP API.
>
> No, it's a bug in the schema definition. I think we took it from
> https://www.ietf.org/proceedings/53/I-D/draft-ietf-dhc-ldap-schema-00.txt,
> where it says :
>
> ( 2.16.840.1.113719.1.203.4.7
> NAME 'dhcpOption'
> DESC 'Encoded optio values to be sent to clients. Each value represents
> a single option and contains (OptionTag, Length, OptionValue) encoded in
> the format used by DHCP.'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>
> Our definition is slightly different :
>
> attributetype ( 2.16.840.1.113719.1.203.4.7
> NAME 'dhcpOption'
> DESC 'Encoded option values to be sent to clients. Each value
> represents a single option and contains (OptionTag, Length, OptionValue)
> encoded in the format used by DHCP.'
> EQUALITY caseIgnoreIA5Match
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
> )
>
> The pb is that using a caseIgnoreIA5Match matching rule for a OCTET STRING
> syntax is simply not working, and leads to an error when we try to inject a
> dhcpOption in the server.
>
>
> The only way to get this fixed would be to fix the schema, and use a
> 1.3.6.1.4.1.1466.115.121.1.26 Syntax (IA5String).
>
> We can do that...
>
>
Re: DHCP using Apache directory server
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/01/16 23:16, Stefan Seelmann a écrit :
> On 01/19/2016 02:46 PM, Sherman Lilly wrote:
>> I have got my schemas installed and working and the directory server is
>> working properly. I am trying to add a value to "dhcpOption" and it will
>> only accept a binary value. I figured out the value has to be utf8 encoded
>> value. How do I use Directory Studio to insert this value? Let say the
>> string is "broadcast 192.168.255.255". Not really sure how to convert that
>> to utf8 encoded binary and insert it into "dhcpOption" thorugh Directory
>> Studio.
>>
>> Any help is appreciated.
> First I have to tell you that the DHCP (and also DNS) servers are not
> maintained since years, I not even can find any server-side integration
> test that tests the functionality. So very likely those won't work at
> all or include major bugs. Help to test, fix, and document is however
> appreciated :)
indeed...
>
> I just tried to add a "dhcpOption" value with Studio. As this attribute
> is of syntax octet string the Hex Editor opens. I then choosed the "Edit
> as Text" option. The resulting binary is a proper UTF-8 encoded value.
> But when saving that there is an error on server side, I think that is a
> bug in the LDAP API.
No, it's a bug in the schema definition. I think we took it from
https://www.ietf.org/proceedings/53/I-D/draft-ietf-dhc-ldap-schema-00.txt,
where it says :
( 2.16.840.1.113719.1.203.4.7
NAME 'dhcpOption'
DESC 'Encoded optio values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionValue) encoded in the format used by DHCP.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Our definition is slightly different :
attributetype ( 2.16.840.1.113719.1.203.4.7
NAME 'dhcpOption'
DESC 'Encoded option values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionValue) encoded in the format used by DHCP.'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
)
The pb is that using a caseIgnoreIA5Match matching rule for a OCTET STRING syntax is simply not working, and leads to an error when we try to inject a dhcpOption in the server.
The only way to get this fixed would be to fix the schema, and use a 1.3.6.1.4.1.1466.115.121.1.26 Syntax (IA5String).
We can do that...
Re: DHCP using Apache directory server
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 01/19/2016 02:46 PM, Sherman Lilly wrote:
> I have got my schemas installed and working and the directory server is
> working properly. I am trying to add a value to "dhcpOption" and it will
> only accept a binary value. I figured out the value has to be utf8 encoded
> value. How do I use Directory Studio to insert this value? Let say the
> string is "broadcast 192.168.255.255". Not really sure how to convert that
> to utf8 encoded binary and insert it into "dhcpOption" thorugh Directory
> Studio.
>
> Any help is appreciated.
First I have to tell you that the DHCP (and also DNS) servers are not
maintained since years, I not even can find any server-side integration
test that tests the functionality. So very likely those won't work at
all or include major bugs. Help to test, fix, and document is however
appreciated :)
I just tried to add a "dhcpOption" value with Studio. As this attribute
is of syntax octet string the Hex Editor opens. I then choosed the "Edit
as Text" option. The resulting binary is a proper UTF-8 encoded value.
But when saving that there is an error on server side, I think that is a
bug in the LDAP API.
dhcpOption: 0x62 0x72 0x6F 0x61 0x64 0x63 0x61 0x73 0x74 0x20 0x31 0x39
0x32 0x2E 0x31 0x36
...org.apache.directory.api.ldap.model.message.ModifyRequestImpl@e292c46e:
java.lang.String cannot be cast to [B:
java.lang.ClassCastException: java.lang.String cannot be cast to [B
at
org.apache.directory.api.ldap.model.entry.BinaryValue.hashCode(BinaryValue.java:212)
at
org.apache.directory.api.ldap.model.entry.AbstractValue.apply(AbstractValue.java:231)
at
org.apache.directory.api.ldap.model.entry.BinaryValue.<init>(BinaryValue.java:111)
at
org.apache.directory.api.ldap.model.entry.DefaultAttribute.<init>(DefaultAttribute.java:497)