--- /dev/null
+#####################################################################
+#####################################################################
+#####################################################################
+######## mod_vhost_ldap version 2.0.3 or later ######################
+#####################################################################
+
+ This file contains further considerations and usage examples
+of single-value access control entry attribute named
+"apacheExtConfigRequireValidUser". Handling of user "validity" is
+quite complicated and a little bit different than you could expect,
+so even I make sometimes misunderstanding if its current implemen-
+tation if this feature.
+
+I'm going to explain here, how user validity is related to
+TWO types of resources, to which access control may be defined:
+
+I. Location access control (sometimes referred as uri access control,
+or virtual host access control)
+II. Directory access control (sometimes referred as physical location
+access control, or virtualhost-independent access control).
+
+Resource, depending on case, may mean "location" or "directory",
+or "both/no matter which kind of goods" :-).
+
+"Access control" usually means authentication + authorization (for
+polish readers - "uwierzytelnianie" and "autoryzacja").
+
+Authentication concerns about various ways of checking validity
+of username/password pair. It includes checking whether user
+exists in user-information source, and whether supplied password
+is valid for supplied user. There are hundreds of methods to
+perform such tasks and apache supports many of them. However,
+mod_vhost_ldap currently support ONLY "basic" authentication,
+which conforms to checking whether user exists and whether applied
+password is correct for applied username. Some authentication
+methods may be used for authentication and authorization, some
+of them cannot (in some situation some information e.g. "realm"
+provided by clients with authentication are used to authorize
+them, sometimes not), however with modvhostldap authentication
+and authorization are two different things.
+
+Authorization concerns about checking whether particular user is
+authorized to connect/use particular resource or particular
+kind of resource.Depending on authorization configuration,
+a resource may be available only to authenticated users, or
+for authenticated and not-authenticated users. Here we
+take care only about resources which are available only for
+authenticated users, so every not-authenticated user is not
+authorized to access particular resources. We don't discuss
+resources that don't need users to be authenticated to determine
+whether they're authorized or not, and vice versa - we assume,
+that every resource which has authentication defined, has
+user authorization status determined in some way, which will
+be explained below.
+
+Authentication is most simple of all of this - authenticated
+user is a user which provided username and password, and
+the pair was verified in some way. Http authentication status
+information is then kept in http headers (usually until
+browser or browser-window is not reopened, depending on browser.
+
+First we define what's actually defined by access control entry,
+and what is NOT defined by access control entry.
+
+In both cases, (location and directory) access control entry
+defines whether particular resource is protected, however
+with directory, existing access entry means that directory
+has access control, and for location, existing access entry
+means,that location is protected if and only if virtual host
+has access control enabled. you can enable/disable location access
+control for virtualhost, no matter whether access control
+entry for this location exists - on virtual host configuration
+level, by setting apacheExtConfigHasRequireLine attribute to
+TRUE or FALSE. if this attribute for vhost is FALSE, location
+access control won't be checked at all.
+Directory access control is always checked, no matter, whether
+virtualhost has access control enabled, or not. LAC is configured
+against particular address on (with) particular virtual server, DAC
+is configured against physical location of the resource, no matter
+whether it is accessed by some alias address, or some uri
+directly available under virtual server directory tree. (www.internal.com/ and below).
+Sometimes you may want particular file or directory
+on the disk to be protected, no matter which way user tries
+to access it, and sometimes you may want that some particular
+URL to be protected, if its accessed via www.domain.com, but
+opened e.g. from internal network (when it's accessed via www.inernal.com
+virtualhost, which is available for internally-conected clients.
+
+Directory access control has higher level of importance than
+location access control. Secured directory is secured no matter
+under which location it's accessed. If you secure directory
+as directory, and you secure location, location authentication
+and authorization will be checked first, and if allowed, directory
+authentication and authorization will be checked, and if
+denied - user will be denied access. Authentication information
+are stored somewhere in http headers, so once authenticated
+user data will be passed to directory authentication.
+if the same user is authorized to access directory, access
+will be granted, if perlocation-authenticated user is not
+authorized to access directory, a prompt for another
+authentication data will be displayed. This may cause
+to annoying results, as authentication information in http
+headers would be probably replaced (?), and new values won't
+match location requirements. However i'm not sure how this
+works, I didn't tested it, it's possible that headers may contain
+information for location and directory, anyway it's recommended to
+avoiding such situation, to always have clearance which set of access
+control settings are applied to the resource client wants access.
+In doubt I suggest you to configure per-directory access control,
+in almost all cases this is what you want.
+
+
+
+Now, for apache there are three ways in which user can be
+authorized for resource: user may be valid-user, user may
+be one of exactly defined authorized users, or user may
+be member of authorized group. for details refer to apache documentation
+of "Require" directives, anyway, modvhostldap currently
+supports valid-user and userlist, and this is difference,
+which is determined by apacheExtConfigRequireValidUser attribute.
+
+Location "Require" directive is created for
+each request for each vhost which have has LAC enabled
+(hasRequireLines = TRUE), and for which there's found
+access control object, which has the same or higher
+uri as its apacheExtConfigUri value.
+
+Directory Require directive is created
+if there's found access control object, which has
+the same or higher directory as its apacheExtConfigPath value.
+
+Let's assume that if we're processing per-location config
+then servername of the http request is "internal", and uri of the
+request is "/abcd/xyz/protected/" (so we have
+http://internal/abcd/protected/xyz/"
+First is checked whether "internal" HasRequireLines is TRUE.
+If yes, then there's made a lookup for access control
+entry, which has apacheExtConfigServerName value = internal
+and apacheExtConfigUri value set to a value,
+which is contained in '/abcd/protected/xyz' starting
+from left. so access control objects which have
+apacheExtConfigUri like: "/", "/abc",
+"/abcd/xyz/protected" and "/abcd/xyz/protected/"
+will match. Finally, if the full string is reached,
+and access control object is not found, error is
+reported - (access control configured but no
+access control objects found), and access control
+is not applied.
+
+And - other case - if we're processing per-directory config,
+then match is made exactly the same way, except that
+servername is not checked. If higher (shorter) or equal
+directory value has acl object with this value - object
+is matched. If full string is reached and object is not found,
+access control is not applied, and no error is reported.
+
+Now ACL object, if found, is examined.
+If apacheExtConfigRequireValidUser attribute for it
+has value set to "TRUE", then
+configuration is processed as "Require valid-user"
+(access shoud be granted to any valid user).
+analog directive,
+If it's "FALSE", then configuration
+is processed as "Require user ..." directive, userlist
+is created, and access is granted to any valid user,
+which username is on the list.
+List, if needed, is created depending on values
+of attribute apacheExtConfigUserDn which must in this
+case contain full distinguished names of the users,
+which should have access granted. Username "nobody"
+is always appended first, before appending attribute
+values (loginnames), to avoid situation, when
+apacheExtConfigRequireValidUser = FALSE, and no apacheExtConfigUserDn
+values exist in entry ("Require user" if defined, must contain at least one username).
+
+So access gets configured, and then it comes to authentication.
+Further processing depends whether it's case I or II.
+In case I - valid user, is user which matches the following filter:
+(&
+ (_D_)
+ (objectClass=apacheExtendedConfigUserObject)
+ (apacheExtConfigUserServerName=_A_)
+ (apacheExtConfigUserLocationUri=_G_)
+)
+
+and in case II
+(&
+ (_D_)
+ (objectClass=apacheExtendedConfigUserObject)
+ (apacheExtConfigUserDirectoryName=_E_)
+)
+
+where _D_ is global user-defined filter, and other attributes
+have values the same as access control object.
+More details about used filters and global
+user-defined filter you'll find in vhost_ldap.conf
+
+Finally, in both cases, if access control object
+has apacheExtConfigRequireValidUser = FALSE, user is authenticated,
+loginname is found on the list, access is granted, or
+of the apacheExtConfigRequireValidUser = TRUE,and user is authenticated,
+access is granted, otherwise access is denied.
+This final stage, in comparison to analog configuration files,
+is the same as checking context in which particular user has been
+defined - <Directory /some/dir> or <Location /abcd/xyz/protected>.
+Simply - with .htaccess context is determined based on
+the location of the .htaccess file, in common configuration
+context is determined by the context :-), and with ldap
+context is determined by attributes of the particular webuser.
+
+For each user object, supplied password is checked against
+as clear text, htpasswd format, or unix crypt format, and with
+debug all of them are logged, and additionaly. information
+which one matched (or none) is logged too.
+
+So, to be short at last - access control has particular precendence,
+there are some differences between location and directory access
+processing. You always need to specify inside userobject
+for which resource it is valid, and, additionaly, if you set
+apacheExtConfigRequireValidUser=FALSE, then you need to
+put webuser object DN into apacheExtConfigUserDn attribute
+of the access entry related to this resource. Applied
+password is checked against mostly used formats.
+And, you can have multiple locations, directories and servernames
+for access config entries, and user entries, and (ugh),
+you can have multiple access control entries for virtualhost(s).
+
+If you get into mess, and things doesn't work, you can disable
+some part(s) of authentication process. any trouble with
+authentication won't impact rest of virtualhost filesystem.
+Aliased directiories are substituted first, so directory
+access control entries will apply only to final real-directory
+or file name.
+
+Aliasing match works similar way as Directory and Location
+match - there's a try to find object which define targed physical
+location for current URI, and this target (existing or not),
+has precedence over (existing or not) URL part(s).
+And you can have multiple aliases for virtualhost, and
+multiple virtual URI's for one target.
+
+If you create entries, which coincidents, like two
+alias object which specify the same url and vhost, but
+different targets, or two uses with the same
+logins and the same permissions but e.g. different passwords,
+only first found will be used (each matching is done only once),
+and it's hard to predict which one this would actually be.
+Creating users without passwords at all, is avoided by
+schema.
+
+Note, that all this stuff is of course checked before actual
+resource is returned to browser, so any of alias targets, or
+users defined as valid, doesn't need to be existing - if
+they don't exist, finally some HTTP error will be returned, but
+existence of objects doesn't affect processing itself.
+
+Have fun, feedback welcomed :)
+PW.
\ No newline at end of file
--- /dev/null
+##########################################################################################
+##########################################################################################
+############# SKIP COMMENTED LINES TO SEE PURE LDIF FILE #################################
+##########################################################################################
+############# If particular access combination of pattern #######################
+############# [([location+servername]|[directoryname])+username]) #######################
+############# does not work, first consult actually used filters #######################
+############# presented in example vhost_ldap.conf, and then turn #######################
+############# debugging logging with apache. there's very much log #######################
+############# output, including configuration and uri parsing #######################
+############# and each search filter and retrieved variables #######################
+############# processing. #######################
+##########################################################################################
+##########################################################################################
+
+##### webserver definition
+dn: apacheServerName=internal,ou=virtualHosts,dc=foo,dc=bar
+objectClass: top
+objectClass: apacheConfig
+objectClass: organization
+##### object classess - for aliases and per-location auth
+##### you must include these
+objectClass: apacheExtendedConfigLocation
+objectClass: apacheAliasesConfigLocation
+o: apache
+apacheServerName: internal
+##### single-value
+apacheDocumentRoot: /var/www/internal
+##### multi-value (optional)
+apacheServerAlias: www.somedomain.com
+apacheServerAlias: www.internal
+##### whether aliases objects search should be performed
+##### for requests to this host (aliases are assigned
+##### to webserver and its uri name (virtual location)
+##### with this you can keep pointers to config objects assigned,
+##### but turn them off for vhost - if you set next two attrs
+##### to FALSE, location and aliases won't be searched for it,
+##### althoug *OptionsDn exists
+apacheAliasesConfigEnabled: TRUE
+apacheExtConfigHasRequireLine: TRUE
+##### next two are multi values, which mean you can define
+##### many aliases and many protected location for vhost
+apacheAliasConfigOptionsDn: apacheAliasConfigObjectName=internal vhost alias one,ou=webAliases,dc=foo,dc=bar
+apacheLocationOptionsDn: apacheExtConfigObjectName=internal vhost access control,ou=webAccess,dc=foo,dc=bar
+
+##### heads up - access control configuration object
+dn: apacheExtConfigObjectName=internal vhost access control,ou=webAccess,dc=foo,dc=bar
+objectClass: organization
+objectClass: top
+##### required to work
+objectClass: apacheExtendedConfigObject
+o: apache
+##### next attribute determines whether this
+##### configuration objects is of type "require valid-user" (TRUE)
+##### or "Require user1 user2 user3". This is actually related
+##### for user object search. if you set to true, lookup will
+##### search for userobjects which are under WucBaseDn
+##### and have userobjectservername set to alias or servername
+##### of current vhost, if you set to false, apacheExtConfigUserDn
+##### will be processed to get userlist ("Require user1,user2,user3...")
+##### Require group usergroup not implemented yet
+apacheExtConfigRequireValidUser: TRUE
+##### this is usually naming attribute in the tree, anyway
+##### this is the value which appears in http auth prompt dialog
+apacheExtConfigObjectName: internal vhost access control
+##### now - in this example, this access object keep access config
+##### of two kinds, per-location and per-directory. Next two
+##### attributes specified per-location assignment - perlocation
+##### access control will search for object which has current req servername
+##### and current req Uri. It is planned to be able to specify regexp
+##### as configUri and configPath, however it's not implemented yet.
+apacheExtConfigServerName: internal
+apacheExtConfigUri: /locationprotected
+apacheExtConfigPath: /var/www/internal/protected
+##### and one above is searched for every request, compared to request r->filename,
+##### no matter what's current vhost servername is.
+##### You can have any combination of these three lines including none of them.
+##### this object in general actually determines authorized users for resource,
+##### so you can have some userlist specification for many servernames and aliases,
+##### many uris (locations), and for many directories in the same object.
+##### you should only remember, that for perlocation access config
+##### servername/serveralias AND extConfigUri is matched, and for perdirectory
+##### only extConfigPath is searched.
+##### and the last piece of the puzzle - if requirevaliduser is set to TRUE
+##### (meaning access control entry of type "Require valid-user" and any
+##### userobject which have servername and uri assigned is accepted
+##### if requirevaliduser is set to FALSE, (the meaning is:
+##### "<this acl objectis NOT "Require valid-user">, which actually equals to:
+##### <this acl object is "Require user1 user2 user3">)
+##### list of attribute values for the following directive is processed.
+apacheExtConfigUserDn: apacheExtConfigUserName=pwadas,ou=People,dc=foo,dc=bar
+apacheExtConfigUserDn: apacheExtConfigUserName=otherUser,ou=People,dc=foo,dc=bar
+##### and, of course, you can have multiple values for this attribute
+##### (final list contains multiple usernames). Remember - username "nobody" is
+##### a special username, which is always appended to the result list, to avoid
+##### case, when you specify extConfigRequireValidUser to FALSE and do not specify
+##### any usernames (valid list <"require user" '[username] ...'> passed to apache
+##### must include at list one username. so creating user object entry
+##### with extConfigUserName "nobody" is not recommended as it's always appended
+##### to the list.
+
+##### username object
+dn: apacheExtConfigUserName=pwadas,ou=People,dc=foo,dc=bar
+##### these object must contain one or more values for UserName attribute.
+##### keeping one value which should be naming attribute is recommended,
+##### however you can specify many loginnames for one user.
+##### If you create two userobject entries, and both of them will have
+##### attribute apacheExtConfigUserName with the value "johnny"
+##### (this may be hidden if UserName is not naming attribute)
+##### password will be matched ONLY against first entry found.
+##### which one will be found first when lookup is done with
+##### "(username=XXX)(servername=YYY)(uri=ZZZ)" is hard to predict,
+##### consult with openldap documentation, and watch the filter used.
+##### on the other hand - you can still have to userobjects with
+##### the same names for per-location access control, and if
+##### these object have different servernames - appropriate one
+##### will be found.
+apacheExtConfigUserName: pwadas
+apacheExtConfigUserName: someotherusername
+o: apache
+objectClass: organization
+objectClass: top
+##### this is required of course
+objectClass: apacheExtendedConfigUserObject
+##### now - you can have multiple passwords for one userobject
+##### no matter how many usernames it contains.
+##### recognized password format is cleartext,
+##### standard htpasswd-encrypted string (stored as cleartext)
+##### and linux-shadowlike value stored as {CRYPT}. This means,
+##### that you can combine posixAccount with webuser object,
+##### if you create object with appropriate classes, and
+##### userPassword attribute is the same for both classes.
+##### however in such situation extendedconfigUserName is
+##### still required and multi-value :-), so you'll probably want
+##### keep posixAccount's "uid" and this have at least one the same value.
+##### of course this applies to any attribute which you map
+##### as "uid" in libnss-ldap configuration. with mod-vhost-ldap
+##### ONLY extConfigUserName is searched.
+userPassword: www
+userPassword: p00nQ0ftSC5cU
+userPassword: {CRYPT}$1$RG.pRvZh$Q0WZ8clsqtMUBRLFckoQg1
+##### one username object may contain multiple values
+##### for URI's and directories. which mean you can apply
+##### the same userobject to many resources. however
+##### with LocationUri, appropriate configUserServername must be
+##### defined to have this userobject matched with search lookup.
+apacheExtConfigUserDirectoryName: /var/www/internal/protected
+apacheExtConfigUserServerName: www.internal
+apacheExtConfigUserLocationUri: /protecteduri/
+
+##### and the most simple thing - aliasing object
+##### ObjectName has only naming usage, if any, as aliases
+##### doesn't have "prompts". however object must have some logical
+##### name, and uri or target is not a good choice - first because
+##### it always contain at least one "/", and second - it can
+##### have many values for sourceUri, so specifying it as naming
+##### attribute will always mask other values.
+dn: apacheAliasConfigObjectName=internal vhost alias one,ou=webAliases,dc=foo,dc=bar
+objectClass: organization
+objectClass: top
+objectClass: apacheAliasConfigObject
+o: apache
+apacheAliasConfigObjectName: internal vhost alias one
+##### you can alias multiple uri's to one physical directory
+apacheAliasConfigSourceUri: /abcd/x
+apacheAliasConfigSourceUri: /some/url/anywhere
+##### remember - for aliases to work, you must specify at least
+##### one servername, as aliases (virtual uri's) are always
+##### related to virtualhost. anyway, if you specify multiple
+##### servername, the result will be the same uri for many
+##### virtualhosts, assigned to the same physical directory.
+##### with multiple servername, the same issues applied
+##### as with multiple loginnames - if it's not naming attribute
+##### you may get messed with many objects describing the same
+##### uri for the same vhost (multiple pairs for uri+servername).
+##### in this case first one found will be returned applied.
+##### (lookup is done in the way which returns ONE entry only).
+##### original mod_alias supports regular expression to specify
+##### this, in modvhostldap regexp is not supported yet.
+##### it's planned to be able to define regexp for servername and uri,
+##### and this will be even more flexible than original, as
+##### with original you can have regexp for uri only, and vhost
+##### is determined by context to which directive AliasMatch apply.
+apacheAliasConfigServerName: internal
+apacheAliasConfigServerName: www.someotherhost.com
+##### target dir is single-value. It could be multiple-value,
+##### to be able to store different pairs with one object, however
+##### on the other hand specifiying two or more physical directories
+##### for one URI doesn't make much sense, so to avoid mess
+##### it's single value.
+apacheAliasConfigTargetDir: /var/www/internal/protected
+##### and that's all folks :)
--- /dev/null
+index apacheExtConfigServerName pres,eq,sub
+index apacheExtConfigUri pres,eq,sub
+index apacheExtConfigPath pres,eq,sub
+index apacheAliasConfigSourceUri pres,eq,sub
+index apacheAliasConfigTargetDir pres,eq,sub
+index apacheAliasConfigServerName pres,eq,sub
+index apacheDocumentRoot pres,eq
+index apacheExtConfigObjectName pres,eq
+index apacheExtConfigRequireValidUser pres,eq
+index apacheExtConfigUserDn pres,eq
+index apacheExtConfigUserServerName pres,eq
+index apacheLocationOptionsDn pres,eq
+index apacheAliasConfigOptionsDn pres,eq
+index apacheAliasConfigObjectName pres,eq
+index apacheServerAdmin pres,eq
+index apacheServerAlias pres,eq
+index apacheServerName pres,eq
\ No newline at end of file
--- /dev/null
+#TLSCipherSuite HIGH:MEDIUM:+SSLv3
+#TLSCertificateFile /etc/ldap/TLS/ldapserver.crt
+#TLSCertificateKeyFile /etc/ldap/TLS/ldapserver.key
+#TLSCACertificateFile /etc/ldap/TLS/ca.crt
+
+#allow bind_v2
+disallow bind_anon tls_2_anon
+
+include /etc/ldap/schema/core.schema
+include /etc/ldap/schema/cosine.schema
+include /etc/ldap/schema/nis.schema
+include /etc/ldap/schema/inetorgperson.schema
+include /etc/ldap/schema/misc.schema
+include /etc/ldap/schema/local.schema
+include /etc/ldap/schema/mod_vhost_ldap.schema
+include /etc/ldap/schema/apache_ext.schema
+include /etc/ldap/schema/apache_alias.schema
+
+pidfile /var/run/slapd/slapd.pid
+argsfile /var/run/slapd.args
+modulepath /usr/lib/ldap
+moduleload back_bdb
+backend bdb
+schemacheck on
+
+checkpoint 1 5
+
+#sum values as ldap level
+# 1 trace function calls
+# 2 debug packet handling
+# 4 heavy trace debugging
+# 8 connection management
+# 16 print out packets sent and received
+# 32 search filter processing
+# 64 configuration file processing
+# 128 access control list processing
+# 256 stats log connections/operations/results
+# 512 stats log entries sent
+# 1024 print communication with shell backends
+# 2048 entry parsing
+
+#loglevel 768
+loglevel 0
+
+database bdb
+lastmod on
+suffix "dc=ROOT"
+directory "/var/lib/ldap"
+sizelimit unlimited
+timelimit unlimited
+
+include /etc/ldap/indexes
+
+rootdn "cn=admin,dc=foo,dc=bar"
+
+access to dn.base=""
+ by * read
+
+access to *
+ by dn="cn=admin,dc=foo,dc=bar"
+ by dn="cn=nobody,dc=foo,dc=bar" read
+ by * none
--- /dev/null
+### mod_vhost_ldap depends on mod_ldap ###
+### you have to enable mod_ldap as well ###
+### and probably set various cache options for it ###
+
+###scope values: base, one, sub
+###deref values: never, finding, searching, always
+###remember, user specified filter is checked as RFC-defined ldap filter before substitution
+###user filter specified here results with following internal filters and variables:
+### _A_ is the server name from the request (vhost server name to find)
+### _B_ is the uri for which access control is to be determined
+### _C_ is the name of the require valid-user directive (auth prompt message)
+### _D_ is the the user-defined filter
+### _E_ is the protected physical directory (doesn't need to be existing file or dir)
+### _F_ is the alias location uri
+### _G_ is the protected uri for which access control is to be determined (see _E_)
+### _H_ is the alias uri which is to be aliased to specified directory
+### Each use of search filter is logged with debug level
+
+#####################################################################
+### Vhost search
+### (&(_D_)(|(apacheServerName=_A_)(apacheServerAlias=_A_)))
+#####################################################################
+### Protected Location Search
+### (&(_D_)(apacheExtConfigServerName=_A_)(apacheExtConfigUri=_B_))
+#####################################################################
+### Protected Directory Search
+### (&(_D_)(apacheExtConfigPath=_E_))
+#####################################################################
+### Alias Object Search
+### (&(_D_)(apacheAliasConfigServerName=_A_)(apacheAliasConfigSourceUri=_H_))
+#####################################################################
+### Web user Location Search
+### (&(_D_)(objectClass=apacheExtendedConfigUserObject)(apacheExtConfigUserServerName=_A_)(apacheExtConfigUserLocationUri=_G_))
+#####################################################################
+### Web user Directory Search
+### (&(_D_)(objectClass=apacheExtendedConfigUserObject)(apacheExtConfigUserDirectoryName=_E_))
+##################################
+
+### ldap[si]://host[:port]/basedn[?attrib[?scope[?filter]]]
+
+ VhostLdapEnabled On
+ VhostLdapUrl ldap[si]://host[:port]/basedn[?attrib[?scope[?filter]]]
+ #VhostLdapUrl ldap://hostname:389/dc=foo,dc=bar?*?sub?objectClass=activeObject
+ VhostLdapBindDn "cn=read only apache admin,dc=foo,dc=bar"
+ VhostLdapBindPw "secretpassword"
+ VhostLdapWlcBaseDn "ou=webAccess,dc=foo,dc=bar"
+ VhostLdapWucBaseDn "ou=webAccounts,dc=foo,dc=bar"
+ VhostLdapAliasesBaseDn "ou=webAliases,dc=foo,dc=bar"
+ VhostLdapDeref "never"
+ VhostLdapFallback default
+ VhostAliasesEnabled On
+ VhostLocAuthEnabled On
+ VhostDirAuthEnabled On
+
+
andersk / mod-vhost-ldap.git / commitdiff
