Skip to content
Snippets Groups Projects
  1. Aug 24, 2002
    • Howard Chu's avatar
      Experimental cruft to propagate valid Operation to SASL callbacks. · 925714ce
      Howard Chu authored
      If you have a better way, jupm on in...
      925714ce
    • Howard Chu's avatar
    • Kurt Zeilenga's avatar
      Remove cruft · 99912c58
      Kurt Zeilenga authored
      99912c58
    • Kurt Zeilenga's avatar
      Add ldapwhoami(1) · 18e4362b
      Kurt Zeilenga authored
      18e4362b
    • Kurt Zeilenga's avatar
      Add -y. · dabbefd9
      Kurt Zeilenga authored
      dabbefd9
    • Kurt Zeilenga's avatar
      Patch: 'ldapmodify -y file' reads password from file (ITS#2031) · 8de258d2
      Kurt Zeilenga authored
                  ================
      Written by Hallvard B. Furuseth and placed into the public domain.
      This software is not subject to any license of the University of Oslo.
                  ================
      Adapted by Kurt Zeilenga for inclusion in OpenLDAP.  My comments are
      marked with enclosed with square brackets (e.g. [Kurt's comment] below.
                  ================
      
      If I run ldapmodify & co from a script, I don't want to use '-W password'
      because the password shows up in the output of 'ps' for everyone,
      and I can't pipe the password to 'ldapmodify -w' because -w uses
      getpassphrase() which reads from the tty instead of stdin.
      So I added '-y file' which reads the password from file.  The programs
      exit if the file cannot be read.
      
      [Complete contents of file is used as password.  Use:
      	echo -n "secret" > password
      to create a file with "secret" as the password.  The -n avoids
      adding a newline (which would invalidate the password).  Note
      that echo is a builtin and hence its arguments are not visible
      to 'ps'.]
      
      I changed ldapmodify, ldapmodrdn, ldapdelete, ldapsearch, ldapcompare.
      I did not bother to change ldappasswd and ldapwhoami, because they
      prompt for many passwords.  [I fixed up ldapwhoami.]
      
      Rerun autoconf after applying this patch. [Done.]
      
      Note:  I do not know if Windows NT has fstat(), so I set HAVE_FSTAT to
      undef in portable.nt.  (fstat() is used to warn if the file is publicly
      readable or writeable.)  [I used fstat() to set the buffer size to
      read.]
      
      [Note: using the contents of a file extends the tools to support
      passwords which could not normally be provided using getpassphrase()
      or via the command line.]
      
      Hallvard B. Furuseth <h.b.furuseth@usit.uio.no>, Aug 2002.
      [Kurt D. Zeilenga <kurt@openldap.org>, Aug 2002.]
      8de258d2
    • Howard Chu's avatar
      Added thread-pool getkey/setkey functions · 8c30114d
      Howard Chu authored
      8c30114d
    • Kurt Zeilenga's avatar
      Zap · e259c3c9
      Kurt Zeilenga authored
      e259c3c9
    • Kurt Zeilenga's avatar
      23efa07a
    • Kurt Zeilenga's avatar
    • Kurt Zeilenga's avatar
      NT port fixes · 86717ac2
      Kurt Zeilenga authored
      86717ac2
  2. Aug 23, 2002
  3. Aug 22, 2002
  4. Aug 21, 2002
  5. Aug 20, 2002
  6. Aug 19, 2002
  7. Aug 17, 2002
  8. Aug 16, 2002
    • Kurt Zeilenga's avatar
      Remove #if 0 code · 6e02fe2e
      Kurt Zeilenga authored
      6e02fe2e
    • Pierangelo Masarati's avatar
      CHANGES: · 05348c5f
      Pierangelo Masarati authored
      - now all write operations appear to work correctly with PostgeSQL 7.0
      - all write operations have been made transactional (atomic writes to
        entries are committed separately only in case of complete^1 success
        while all other operations are rolled-back by default)
      - more cleanup and handling of exceptional conditions
      
      TODO:
      - deen to check with different databases and more up to date versions
        of both unixODBC and PostgreSQL.
      
      ^1: attribute add/modify/delete operations silently succeed if the
          appropriate add/delete proc does not exist for each attribute;
          this may be correct to hide undesired/unimplemented correspondence
          between LDAP and SQL databases; however, a more appropriate
          LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
          single write operation cannot be executed for such reason
      05348c5f
    • Pierangelo Masarati's avatar
    • Pierangelo Masarati's avatar
      silence warnings · 3a26ef5b
      Pierangelo Masarati authored
      3a26ef5b
Loading