The changetype option must come immediately after the DN specification. Another thing to note above is the use of a multi-line value for the description attribute. Since the lines that follow begin with a space, they will be joined with the space removed. As with the last section, each additional entry within the same file is separated by a blank line. Comments can be used by starting the line with a character. Comments must exist on their own line.
For instance, if we wanted to add Sally in this same LDIF file, we could separate the two entries like this:. If you are using the simple entry format without the changetype setting , you can use the ldapadd command or the ldapmodify command with the -a flag, which specifies an entry addition.
You will either need to use a SASL method to authenticate with the LDAP instance this is outside of the scope of this guide , or bind to an administrative account in your DIT and provide the required password. For instance, if we stored our entries from the simple entry section in a file called newgroups. If you are using the second format, with the changetype declaration, you will want to use the ldapmodify command without the -a flag.
Since this command and format works for most other modifications, it is probably easier to use for most changes. If we stored the two new user additions within a file called newusers. This will allow you to add entries to your DIT at will.
We had our first glimpse of the changetype option in the last section. This option provides the method for specifying the high-level type of modification we wish to make. Entry deletion is actually the most straight-forward change that you can perform because the only piece of information needed is the DN. To process the change, you can use the exact format used with ldapmodify above.
If we call the file with the deletion request rmothergroup. The types of modifications you can make to attributes mostly mirror the modifications you can make to an entry itself.
Because of this, the details of the type of requested attribute change are specified afterwards using additional directives. For instance, you can add an attribute by using the add: command after changetype: modify. This should specify the attribute you wish to add. You would then set the value of the attribute like normal.
So the basic format would be:. For instance, to add some email addresses to our accounts, we could have an LDIF file that looks like this:. As you can see from the second entry, you can specify multiple additions at the same time. The mail attribute allows for multiple values, so this is permissible.
You can process this with ldapmodify as normal. If the change is in the file sbrownaddmail. Another common change is to modify the existing value for an attribute. We can do this using the replace: option below changetype: modify. It is also permissible for the value referred to by a URL to be of zero length.
The contents of the referenced file are to be included verbatim in the interpreted output of the LDIF file. The semantics associated with each supported URL will be documented in an associated Applicability Statement. Lines in LDIF files may only be folded according to the folding rules described in note 2, above.
LDIF does not permit any extraneous characters, other than those used for line folding. Comments indicate the contents of UTFencoded attributes and distinguished names. Note that the first will always succeed, while the second will only succeed if at least one value for the description attribute is present. The criticality field is "true" and the controlValue field is absent, as required by [ 9 ].
Appropriate measures should be taken to protect the privacy of those persons whose data is contained in an LDIF file. A "trojan" LDIF file could name a file with sensitive contents and cause it to be included in a directory entry, which a hostile entity could read via LDAP. While this is simple and effective, it is not particularly space-efficient because the baseencoded representation of the data would be twice as large as the raw form of that data.
That alternate encoding is base The base64 format is described in detail in RFC , but the basic premise is that is that it uses an alphabet of 64 characters, with those characters in the following order:. Since 64 is 2 6 , using an alphabet of 64 characters means that each character can represent a unique six-bit combination.
We would first need to determine what the binary representation of that data is. Doing this, we get the following:. The example above works out nicely because the nine bytes of raw data contains 72 bits, which can be also divided twelve 6-bit segments with no bytes left over.
But this only happens if the number of raw bytes is a multiple of three. The way to address this problem is through the addition of padding. That will allow us to break up the value into an even number of six-bit segments. For any segment that contains a mix of real bits and pretend bits which will be represented as dashes , we will assume those pretend bits are zeroes.
For any segment that contains only pretend bits, we will use the equal sign as a special base64 padding character. The process of decoding baseencoded data is simply the reverse of the process used to encode.
First, convert each base64 character to the appropriate six-bit representation. Then concatenate all of those six-bit representations together and break them up into eight-bit segments to get the raw bytes. But there are some cases in which it will be necessary to baseencode data to ensure that it can be safely and unambiguously represented in LDIF. As will be described below, LDIF uses the colon character as a delimiter between an element name e. However, if LDIF includes a baseencoded value rather than a raw value, it is necessary to use two colons the second of which may be optionally followed by a single space rather than one to serve as the delimiter.
It is legal to baseencode any value when representing it in LDIF, but any value that meets any of the following conditions is required to be base64 encoded for use in LDIF:. Although it is not absolutely required, it is strongly recommended that values that end with a space should also be base64 encoded. Next you must specify the attributes you want to modify using one of the following directives:.
For example:. If the attribute is multi-valued then all the current values are replaced with one or more attributes following this directive. If only a single value of a multi-valued attribute needs to be replaced use delete then add. If you are making several modifications to an entry, then, between each modification you enter, add a line that contains a hyphen - only.
To modify the relative distinguished name RDN for an entry, you must supply the DN of the entry followed by the changetype: modrdn directive. Next you must specify the new RDN with a newrdn: directive, and you can optionally delete or keep the old entry by supplying a deleteoldrdn: directive. To modify the DN for an entry move the entry to a new node in the DIT , you must supply the DN of the entry followed by the changetype: moddn directive.
Next you must specify the new parent DN with a newsuperior: directive, and you can optionally delete or keep the old entry by supplying a deleteoldrdn: directive. Attribute types and object classes must be added to the Oracle Internet Directory schema before they can be used in entries.
This example adds a new attribute to the schema called myAttr. The LDIF file for this operation is:. On the first line, enter the DN specifying where this new attribute is to be located. The last line is the attribute definition itself. The first part of this is the object identifier number: 1. It must be unique among all other object classes and attributes.
Next is the NAME of the attribute. It must be surrounded by single quotes. Next is a description of the attribute. Enter whatever description you want between single quotes. At the end of this attribute definition in this example are optional formatting rules to the attribute. When you define schema within an LDIF file, insert a white space between the opening parenthesis and the beginning of the text, and between the end of the text and the ending parenthesis.
Before you add the object class, all of the attribute types that the object class uses must be in the schema. If there are new attribute types, then define those first in your LDIF file before defining your object class.
0コメント