representing file pathnames
by Chuck Lever
Hi-
(Sorry for the length, it's a pretty wonky problem).
I'm working with the IETF NFSv4 working group on a schema for storing file system referral information in LDAP, as part of the FedFS standard (RFC 5716). I'm looking for some opinions about certain details of the schema.
A "referral" is a file server response that conveys a table of file server hostname and export pathname pairs that are replicas of the local file set on that file server. When a referral is encountered, a file system client chooses a row from this table and mounts that export automatically as it continues to traverse the file system name space. Referrals are a standard part of both the NFSv4 and SMB protocols.
FedFS provides a standard way to store these rows in an LDAP database. Each row is contained in a single LDAP record, called a File Set Location record. A group of these records that live under the same parent record is retrieved by a file server to generate the table in a referral response.
Today an FSL record for an NFS referral contains among other things a UTF-8 string server hostname, an integer port number, and a binary blob containing an XDR-marshalled representation of the export pathname. Note that both the pathname components and hostname are represented in UTF-8 in the NFS protocol, which is why they are stored as UTF-8 in LDAP.
XDR was chosen because the file server doesn't have to alter the pathname data it reads from the LDAP server; it can just turn it around and send it immediately on to NFS clients. The pathname's components are UTF-8 strings. The pathname is expressed as an ordered variable-length list of these strings.
The pathname separator is not stored in the XDR blob, since physical file systems can use different characters for this purpose (HFS+ on Mac OS uses ":", POSIX uses "/", and Windows uses "\"). NFS typically performs single component lookups on the wire, so NFS clients are never concerned with how a file server might separate its pathname components.
The downside of using a binary XDR blob is that it's not observable or editable via typical LDAP tools. Plus, ewww.
It's been suggested that we use a file URL to represent export pathnames. A file URL is expressed in US-ASCII with escaping, and the pathname separator is stored in the string. A file URL also has the ability to store a hostname.
"file://hostname/path/to/some/file"
I'm not sure this is the best fit for our purpose. We're especially concerned about some of the complexities of converting escaped US-ASCII to UTF-8, and the use of a fixed pathname separator character. Can we represent the full range of the UTF-8 code set with a US-ASCII file URL?
We could also use an NFS URL, which would allow us to express the server hostname, a port number, and the pathname in a single string. But both the hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL format employs a fixed pathname separator character.
An alternative we have considered would store the pathname in a single-valued UTF-8 string attribute, including pathname separators, but also store the pathname separator character in a separate attribute. A simple escaping mechanism would be used to represent a separator character embedded in a component.
We'd like to have a schema that represents referral data in a way that is considered natural for LDAP, can store the full richness that an NFS referral is capable of, and is easy to access and update with typical LDAP client tools like ldapmodify.
Are there other ideas we haven't considered? What is a practical way to store an ordered variable-length list of strings in an LDAP attribute? Is there a similar CIFS URL format that might be used to store SMB share information?
Thanks very much for your consideration.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
11 years, 1 month
openldap 2.4.23 hangs
by rwsmith＠bislink.net
Hi,
Not sure if I should post this here or with the CentOS mailing list (I am hoping
they are monitoring this). I am using a stock CentOS 6.3 32-bit installation
with
# rpm -qa | grep openldap
openldap-devel-2.4.23-26.el6_3.2.i686
openldap-2.4.23-26.el6_3.2.i686
openldap-clients-2.4.23-26.el6_3.2.i686
openldap-servers-2.4.23-26.el6_3.2.i686
I have a 4-way multi-master sync replication set up on four virtual servers
using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one
machine and BDC on the other three. All servers are also running sssd-1.8.0 for
the Linux authentication.
The problem is that one or more of the LDAP servers will hang, usually the one
that acts as the PDC, since this is hit the hardest and is the more critical of
the four. Usually but not always the "hang" will trickle to the other
servers--usually when I am not watching during the middle of the night.
Fortunately we are not yet in full production.
Compiling from source is not yet an option. I must use the stock RPMs from
CentOS per our design guidelines.
LDAP will appear to hang but what appears to be happening is that only the
listener becomes busy and will not get out this state. Here is a short pull of
the logs that I am collecting:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text=
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]: 69r
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]: 39r
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:12 auth-us slapd[10357]: 42r
Aug 14 20:35:12 auth-us slapd[10357]:
Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:14 auth-us slapd[10357]: 40r
Aug 14 20:35:14 auth-us slapd[10357]:
Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Every log entry prior to this looks normal in that epoll: listen=7 goes between
active_threads=0 to busy when a connection comes in, sets up the connection, and
then goes back to active_threads=0. I have yet to understand what is going on to
cause it to go into the busy state and never to return until I manually stop and
restart the slapd process. It does appear however that slapd can still process
any queries on active connections as noted on descriptors 40r and 42r--it just
can't process any new connection requests as epoll: listen=7 has hung.
Looking through the archives this problem still appears to be present in a few
additional later releases but I have not found any thread yet which points to a
specific solution or patch that fixes this problem. Unless I can point to a
specific solution and/or patch I won't get approval to do a pull from the latest
source and compile--I'll have to stick with an hourly cron job that stops and
restart slapd.
Thanks,
Bob Smith
--bs
11 years, 1 month
Re: slapd-meta doesn't continue with multiple uri's
by Liam Gretton
On 22/08/2012 09:44, Pierangelo Masarati wrote:
>> My fault: "timeout" is operation-wide; when it's hit, the
>> operation ends as you reported. "network-timeout" is related to
>> connect(2) only. As far as I understand, by looking at the code,
>> there is no practical means, so far, to perform what you're asking
>> for. Either the connection cannot be established, and in this case
>> the code works as intended, or if it hangs for ever the operation
>> can only be aborted/timed out. In those cases, you definitely need
>> to fix the configuration by removing the hung URI.
But what's the point of specifying multiple targets in the uri option if
it doesn't fall through to subsequent ones when the first is not
contactable?
Have I completely missed the point of the documentation?
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
11 years, 1 month
Re: LDAP password management
by Dan White
On 08/22/12 19:43 +0300, Adrian Paleacu wrote:
>Hi Dan,
>
>Thank you for quick response. So is not possible to inform LDAP service
>that an already hashed password is passed trough.
You can accomplish hashing of your password, over the network, by binding
with SASL. Depending on the mechanism you use, doing so will require you to
store your passwords in cleartext on the server. See:
http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/mechanisms.php
OTP and SRP do not require storing your password in cleartext.
In any case, if your desire is to secure the transmission of your password,
the use of TLS is recommended.
If you're asking how to handle the case where you're transitioning to an
ldap based authentication scheme from a hashed password store (such as
/etc/shadow), see the manpage for crypt(3), and prepend your hashes with
{CRYPT} before storing them within slapd.
>On Wed, Aug 22, 2012 at 6:06 PM, Dan White <dwhite(a)olp.net> wrote:
>
>> On 08/22/12 17:48 +0300, Adrian Paleacu wrote:
>>
>>> Hi everyone,
>>>
>>> I have a binding question regarding the password. Is possible to send a
>>> hashed password to LDAP system. My passwords are hashed and I don't have a
>>> way to send it as plain text.
>>>
>>
>> See Section 14.4 of the OpenLDAP Administrator's guide.
>>
>> If your passwords are stored on your server in certain hashed forms, then
>> slapd will expect you to transmit a cleartext password to be hashed and
>> locally compared with the stored password value.
--
Dan White
11 years, 1 month
syncrepl not propagating changes
by Mark Coetser
Hi
current version of openldap 2.4.23-7.2 I have however built and used
2.4.31 with the same results.
I have a single provider that has multiple domians
ie dc=company
dc=subdivision1,dc=company
dc=subdivision2,dc=company
on some of the consumers, I have a single syncrepl config with the base,
so these servers have all the users and replication tends to work fine.
olcSyncrepl: {0}
rid=00x
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=sub
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
on some of the consumers, I have multiple syncrepl configs so that I
replicate specific subdivision data to those servers.
olcSyncrepl: {0}
rid=001
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {1}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=repl_config,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {2}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=subdivision,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
whats happening with these consumers is that the initial sync seems to
work and some changes to the provider do make it down to the consumer
but lately most changes are NOT making it down to the consumer, when I
log sync then I am seeing that the csn is committed for the change for
the first rid but then for the next rid it logs that the csn is too old?
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4230120
20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb422e830 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4f11d20
20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb4f18508 20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.112753Z#000000#000#000000
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
11 years, 1 month
LDAP password management
by Adrian Paleacu
Hi everyone,
I have a binding question regarding the password. Is possible to send a
hashed password to LDAP system. My passwords are hashed and I don't have a
way
to send it as plain text.
regards,
Adrian
11 years, 1 month
Re: syncrepl not propagating changes
by Mark Coetser
On 22/08/2012 12:00, Rein Tollevik wrote:
> On 22.08.12 10:46, Mark Coetser wrote:
>> On 22/08/2012 10:39, Howard Chu wrote:
>>> Mark Coetser wrote:
>>>>
>>>> on some of the consumers, I have multiple syncrepl configs so that I
>>>> replicate specific subdivision data to those servers.
>>>
>>> That is not supported. You can only use multiple consumers in the same
>>> database if they are all pointing at different providers (and each of
>>> those
>>> providers uses a unique serverID).
>>
>> Can I split them into separate databases on the consumer? Or whats the
>> correct way of doing what I am trying to achieve?
>
> Use a single syncrepl stanza on these consumers too, replicating your
> toplevel cn=company dn. Add acl's on the provider which limits the user
> these consumers binds as to only see those sub-trees you wish them to see.
>
> Rein
>
Hi
Please could someone confirm that these acls would be secure, I am
trying to allow services like pam/nss on the provider to still function
and have access to the entire tree, then allow the replica user from the
consumer to see the base of the tree and the whole of the subdivision
tree including userPassword,shadowLastChange, also could someone assist
with an example of a regex acl that I could use to say that
"cn=replica,*" has read access to everything in that users subtree?
access to attrs=userPassword,shadowLastChange
by dn.base="cn=admin,dc=company" write
by dn.base="cn=replica,dc=subdivision,dc=company" read
by anonymous auth
by self write
by * none
access to dn.base=""
by peername.regex=127\.0\.0\.1 read
by * none
access to dn.base="dc=company"
by dn.base="cn=replica,dc=subdivision,dc=company" read
access to dn.subtree="dc=subdivision,dc=company"
by dn.base="cn=replica,dc=subdivision,dc=company" read
access to *
by dn.base="cn=admin,dc=company" write
by peername.regex=127\.0\.0\.1 read
by * none
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
11 years, 1 month
Re: syncrepl not propagating changes
by Mark Coetser
On 22/08/2012 12:00, Rein Tollevik wrote:
> On 22.08.12 10:46, Mark Coetser wrote:
>> On 22/08/2012 10:39, Howard Chu wrote:
>>> Mark Coetser wrote:
>>>>
>>>> on some of the consumers, I have multiple syncrepl configs so that I
>>>> replicate specific subdivision data to those servers.
>>>
>>> That is not supported. You can only use multiple consumers in the same
>>> database if they are all pointing at different providers (and each of
>>> those
>>> providers uses a unique serverID).
>>
>> Can I split them into separate databases on the consumer? Or whats the
>> correct way of doing what I am trying to achieve?
>
> Use a single syncrepl stanza on these consumers too, replicating your
> toplevel cn=company dn. Add acl's on the provider which limits the user
> these consumers binds as to only see those sub-trees you wish them to see.
>
> Rein
>
Is there an acl that would prevent slapcat from showing the entire tree?
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
11 years, 1 month
Re: Query regarding the Database files..
by Howard Chu
Pierangelo Masarati wrote:
>> If you build the mdb_stat program in the libmdb source (it is not built by
>> default) you can use it to examine the individual MDB databases. E.g.:
>
> Time for a slapstat tool?
Eh... We lived thru 12 years of BerkeleyDB without needing such a thing. I
don't see why we should need it now. It would be useful to flesh out mdb_stat
to report more interesting information, but that's a pretty low priority on my
list at the moment.
For completeness' sake MDB should have mdb_stat, mdb_dump, and mdb_load.
Patches welcome...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 1 month
Using ldap.searchFilter
by rodrigo tavares
Hello !
I installed Openfire im my server, and using client spark, with base LDAP.
I get log in server, but i can´t search the users. Then a need : ldap.searchFilter.
In a doc Openfire: LDAP Guide. I found:
ldap.searchFilter -- an optional search filter to append to the default filter when loading users. The default search filter is created using the attribute specified by ldap.usernameField. For example, if the username field is "uid", then the default search filter would be "(uid={0})" where {0} is dynamically replaced with the username being searched for.
http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/l...
How I can to define this parameter ?
Thanks !
Rodrigo Faria
11 years, 1 month
