gqclient-discuss Mailing List for GQ LDAP client (Page 34)

On Fri, 19 Jul 2002, Tomas A. Maly wrote:

> Hi,
>
> An FYI:
>
> I noticed that the GQ version I got from the site this afternoon (0.6.0
> as of 7/19/2002) has a bug in the src/util.c file (line 156).

Well, 0.6.0 is not _that_ recent... ;-)

>
>            if(server->binddn[0]) {
>
> should be changed to:
>
>            if(server->bindpw[0]) {
>

[snip]

>
> Hope this is useful.

Indeed it is. I have changed the "ask for password" semantics in the
development version anyway, but forgot to check that area, so this was
most useful (even though your fix is only halfway correct in the current
development version). The changes induced by you will be checked in during
the next couple of days.

For those interested: The next version will have hidden passwords. I am
just struggling with how to encode/scramble passwords in the configuration
file without loosing backwards compatibility... In the current
devel version all password entry boxes really work as password boxes,
showing only **** if you type something. [I have not tackled the problem
to hide the _length_ of passwords, this information can easily be spoofed
from the stars in the password boxes in the server preferences window,
patches are welcome.]

peter

On Fri, 19 Jul 2002, Louis-Benoit JOURDAIN wrote:

> Date: Fri, 19 Jul 2002 16:04:18 +0200
> From: Louis-Benoit JOURDAIN <lb...@ip...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] no window2template function in gq 0.6.0
>
> Hi,
>
> I can't compile gq 0.6.0. There error is:
>
> tdefault.o: In function `create_tdefault_edit_window':
> /goinfre/gq-0.6.0/src/tdefault.c:55: undefined reference to
> `window2template'
> /goinfre/gq-0.6.0/src/tdefault.c:61: undefined reference to
> `attrlist_by_oclist'
> collect2: ld returned 1 exit status
>
> There is no window2template function in the source code.

There is (in template.c, line 582).
But I guess it has to do with your openldap: What version are you using?
1.2.x? If that is the case: Either upgrade to 2.x or wait until Monday,
when I am able to produce a patch (I am on a short holiday right now)..

The problem is that most of the template stuff is not compiled if certain
openldap features are not available, but obviously the referencing of
the then-disabled functions get compiled regardless of
feature-availability.

thanks for your patience

peter

Hi,

I can't compile gq 0.6.0. There error is:

tdefault.o: In function `create_tdefault_edit_window':
/goinfre/gq-0.6.0/src/tdefault.c:55: undefined reference to 
`window2template'
/goinfre/gq-0.6.0/src/tdefault.c:61: undefined reference to 
`attrlist_by_oclist'
collect2: ld returned 1 exit status

There is no window2template function in the source code.

LB

-- 
Louis-Benoit JOURDAIN                SunONE Product Technical Support  
lb...@ip...                      Sun Microsystems / iPlanet 
http://wwws.sun.com/software/products/messaging_srvr/home_messaging.html

Hi,

An FYI:

I noticed that the GQ version I got from the site this afternoon (0.6.0 
as of 7/19/2002) has a bug in the src/util.c file (line 156).

           if(server->binddn[0]) {

should be changed to:

           if(server->bindpw[0]) {

Since the binddn is always defined (unless anonymous bind), this 
conditional statement is evaluated as true, and thus the "elsif 
(server->storedpw[0])" is never evaluated. If someone wants to enter in 
their password via the prompt, it reads it, but never copies to the 
local bindpw variable.

Without this bug fix, having your password prompted typically gives a 
"DSA unwilling to perform" / "Unwilling to perform anonymous bind with 
non-empty DN" or the like.

At first glance, some people may not see this after trying to reproduce 
it. What confused me to heck was that I had used version 0.4.0 
previously. It had stored the password in the ~/.gq file. When I first 
tried GQ 0.6.0, even if I put in a password via the prompt, the stored 
password was ALWAYS used (i.e., the login worked). This is caused by the 
bug mentioned above. Deleting the ~/.gq file or removing the server from 
the GUI would cause the bug mentioned above.

Hope this is useful.

Tomas Maly

Hello Maurizio,

On Wed, 17 Jul 2002 ma...@da... wrote:

> Date: Wed, 17 Jul 2002 09:38:50 +0200 (CEST)
> From: ma...@da...
> To: gqc...@li...
> Subject: [Gqclient-discuss] sha1
>
> Hi there,
> i'm new to the list & i ignore if someone noted this.
> I noted that gq stores sha1 password using the output of lutil_SHA1Data
>
> here it the piece of code:
>     lutil_SHA1Init(&ctx);
>     lutil_SHA1Update(&ctx, data, len);
>     return(lutil_SHA1End(&ctx, buf));

This must be from an old version of gq (which one are you using???). gq
support for SHA, MD5, SSHA and SMD5 (that is both seeded and unseeded
versions of these password hashes)  has been rewritten for gq version
0.6.0 and (to my knowledge) should be correct now - that is it also uses
base64 encoding and not hexadecimal encoding.

Just give 0.6.0 a try...

peter

[snip]

Hi there,
i'm new to the list & i ignore if someone noted this.
I noted that gq stores sha1 password using the output of lutil_SHA1Data 

here it the piece of code:
    lutil_SHA1Init(&ctx);
    lutil_SHA1Update(&ctx, data, len);
    return(lutil_SHA1End(&ctx, buf));

in buf you get the same output you could get issuing:

openssl dgst -sha1 file

you get the digest in hexdecimal.

BUT this is NOT what openldap is looking for when compare stored password 
with user supplied password . You can find this in
openldap-2.0.23/libraries/liblutil/passwd.c  

In detail:
in passwd.c the password stored in database is encoded base64; this
means that it is 64base coded in database.
What is obtained is the sha1 digest of cleartext password; then it is
calculated the sha1-digest of user supplied password;
at the end the 2 buffer are compared:
rc = memcmp((char *)orig_pass, (char *)SHA1digest, sizeof(SHA1digest));

gq instead stores the hex of the digest; I implemented sha1 on pam_ldap
using the same function gq uses to calc the sha1 of user entered pwd,
SHA1,
taken by openssl package.
This way I was unable to authenticate in sha1.

I fix this and i used this function to encode password:


char *
lutil_SHA1dgst_b64( const unsigned char *data, size_t len, char *buf)
{
    lutil_SHA1_CTX ctx;
        unsigned char digest[LUTIL_SHA1_BYTES];

    lutil_SHA1Init(&ctx);
    lutil_SHA1Update(&ctx, data, len);
    lutil_SHA1Final(digest, &ctx);

    lutil_b64_ntop(digest, LUTIL_SHA1_BYTES, buf,
LUTIL_BASE64_ENCODE_LEN(LUTIL_SHA1_BYTES));
    return buf;
}

This function take in input cleartext pwd (data) and return what is to be
stored on ldap server database (buf).
Every comment to this will be very appreciated.
M.

Maurizio Marini
CosT Srl Via Longhi, 13 - 20137 Milano
Tel. Direct (+39)02 45446 202           Fax +39-2-45446333
mailto:ma...@da...               GSM +39-335-8259739

thanks for the patch.  the problem is now fixed.


On Mon, 15 Jul 2002, Peter Stamfest wrote:

> Date: Mon, 15 Jul 2002 20:08:48 +0200 (CEST)
> From: Peter Stamfest <pe...@st...>
> To: gw...@ac...
> Cc: Gqc...@li...
> Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
>
> On Sun, 14 Jul 2002 gw...@ac... wrote:
>
> > Date: Sun, 14 Jul 2002 13:26:24 -0700 (PDT)
> > From: gw...@ac...
> > To: Peter Stamfest <pe...@st...>
> > Cc: Gqc...@li...
> > Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
> >
> >
> > Here is my environment:
> > 	LDAP client:	gq 0.6
> > 	LDAP server:	OpenLDAP 2.0.23 slapd
> >
> > Here is the steps to reproduce the problem:
> >  -> Create an entry with dn set to "cn=Test,dc=mydomain,dc=com" where
> >   cn="Test User"
> >   sn="User"
> >   givenName="Test"
> >   result => success
> >  -> Change entry dn to "cn=Test User,dc=mydomain,dc=com"
> >   result => error "ldap_rename_s: No such attribute" and entry is deleted.
> >
> >  So the problem seems to occur when the "cn" value (i.e. "Test") in
> > the original "dn" does not match the value of the actual original "cn"
> > parameter value (i.e. "Test User").
> >
> >  I've verified the problem does not occur when the "cn" value in "dn"
> > matches the actual "cn" parameter.
>
> You might test the following patch. It should remove the strange behaviour
> while still maintaining current gq behaviour. This will be in CVS shortly.
>
> Index: input.c
> ===================================================================
> RCS file: /cvsroot/gqclient/gq/src/input.c,v
> retrieving revision 1.42
> diff -u -r1.42 input.c
> --- input.c	13 Jul 2002 16:47:38 -0000	1.42
> +++ input.c	15 Jul 2002 18:05:12 -0000
> @@ -1090,10 +1090,12 @@
>       GString *message;
>       LDAP *ld;
>       struct ldapserver *server;
> -     int error, res, i;
> +     int error, rc, i, remove_flag = 0;
>       char *olddn, *dn;
>       char **oldrdn, **rdn;
>       char *c;
> +     char *noattrs[] = { LDAP_NO_ATTRS, NULL };
> +     LDAPMessage *res;
>
>       server = g_hash_table_lookup(hash, "server");
>       if( (ld = open_connection(server)) == NULL)
> @@ -1129,25 +1131,43 @@
>  	  statusbar_msg(message->str);
>  	  if (c) free(c);
>
> +	  /* check to see if the rdn exists as an attribute. If it
> +             does set the remove flag. If it does not do not set the
> +             remove flag. This is due to the fact that in the latter
> +             case a set remove flag actually removes the object (at
> +             least from openldap 2.0 servers. This strange behaviour
> +             was pointed out by <gw...@ac...>. */
> +
> +	  rc = ldap_search_s(ld, olddn, LDAP_SCOPE_BASE,
> +			     oldrdn[0], noattrs, 0, &res);
> +	  if (rc == LDAP_SUCCESS) {
> +	       LDAPMessage *e = ldap_first_entry(ld, res);
> +	       if (e) {
> +		    remove_flag = 1;
> +	       }
> +	       ldap_msgfree(res);
> +	  }
> +/*  	  printf("oldrdn[0]=%s, remove=%d\n", oldrdn[0], remove_flag); */
> +
>  #if defined(HAVE_LDAP_RENAME)
> -	  res = ldap_rename_s(ld, olddn, rdn[0], NULL, 1, NULL, NULL);
> +	  rc = ldap_rename_s(ld, olddn, rdn[0], NULL, remove_flag, NULL, NULL);
>  #else
> -	  res = ldap_modrdn2_s(ld, olddn, rdn[0], 1);
> +	  rc = ldap_modrdn2_s(ld, olddn, rdn[0], remove_flag);
>  #endif
> -	  if(res == LDAP_SUCCESS) {
> +	  if(rc == LDAP_SUCCESS) {
>  	       /* get ready for subsequent DN changes */
>  	       g_free(olddn);
>  	       g_hash_table_insert(hash, "olddn", g_strdup(dn));
>  	  } else {
> -	       if (res == LDAP_SERVER_DOWN) {
> +	       if (rc == LDAP_SERVER_DOWN) {
>  		    server->server_down++;
>  	       }
>  #if defined(HAVE_LDAP_RENAME)
>  	       g_string_sprintf(message, "ldap_rename_s: %s",
> -				ldap_err2string(res));
> +				ldap_err2string(rc));
>  #else
>  	       g_string_sprintf(message, "ldap_modrdn2_s: %s",
> -				ldap_err2string(res));
> +				ldap_err2string(rc));
>  #endif
>  	       error_push(context, message->str);
>  	       push_ldap_addl_error(ld, context);
>
>
> peter
>
>

-- 

On Sun, 14 Jul 2002 gw...@ac... wrote:

> Date: Sun, 14 Jul 2002 13:26:24 -0700 (PDT)
> From: gw...@ac...
> To: Peter Stamfest <pe...@st...>
> Cc: Gqc...@li...
> Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
>
>
> Here is my environment:
> 	LDAP client:	gq 0.6
> 	LDAP server:	OpenLDAP 2.0.23 slapd
>
> Here is the steps to reproduce the problem:
>  -> Create an entry with dn set to "cn=Test,dc=mydomain,dc=com" where
>   cn="Test User"
>   sn="User"
>   givenName="Test"
>   result => success
>  -> Change entry dn to "cn=Test User,dc=mydomain,dc=com"
>   result => error "ldap_rename_s: No such attribute" and entry is deleted.
>
>  So the problem seems to occur when the "cn" value (i.e. "Test") in
> the original "dn" does not match the value of the actual original "cn"
> parameter value (i.e. "Test User").
>
>  I've verified the problem does not occur when the "cn" value in "dn"
> matches the actual "cn" parameter.

You might test the following patch. It should remove the strange behaviour
while still maintaining current gq behaviour. This will be in CVS shortly.

Index: input.c
===================================================================
RCS file: /cvsroot/gqclient/gq/src/input.c,v
retrieving revision 1.42
diff -u -r1.42 input.c
--- input.c	13 Jul 2002 16:47:38 -0000	1.42
+++ input.c	15 Jul 2002 18:05:12 -0000
@@ -1090,10 +1090,12 @@
      GString *message;
      LDAP *ld;
      struct ldapserver *server;
-     int error, res, i;
+     int error, rc, i, remove_flag = 0;
      char *olddn, *dn;
      char **oldrdn, **rdn;
      char *c;
+     char *noattrs[] = { LDAP_NO_ATTRS, NULL };
+     LDAPMessage *res;

      server = g_hash_table_lookup(hash, "server");
      if( (ld = open_connection(server)) == NULL)
@@ -1129,25 +1131,43 @@
 	  statusbar_msg(message->str);
 	  if (c) free(c);

+	  /* check to see if the rdn exists as an attribute. If it
+             does set the remove flag. If it does not do not set the
+             remove flag. This is due to the fact that in the latter
+             case a set remove flag actually removes the object (at
+             least from openldap 2.0 servers. This strange behaviour
+             was pointed out by <gw...@ac...>. */
+
+	  rc = ldap_search_s(ld, olddn, LDAP_SCOPE_BASE,
+			     oldrdn[0], noattrs, 0, &res);
+	  if (rc == LDAP_SUCCESS) {
+	       LDAPMessage *e = ldap_first_entry(ld, res);
+	       if (e) {
+		    remove_flag = 1;
+	       }
+	       ldap_msgfree(res);
+	  }
+/*  	  printf("oldrdn[0]=%s, remove=%d\n", oldrdn[0], remove_flag); */
+
 #if defined(HAVE_LDAP_RENAME)
-	  res = ldap_rename_s(ld, olddn, rdn[0], NULL, 1, NULL, NULL);
+	  rc = ldap_rename_s(ld, olddn, rdn[0], NULL, remove_flag, NULL, NULL);
 #else
-	  res = ldap_modrdn2_s(ld, olddn, rdn[0], 1);
+	  rc = ldap_modrdn2_s(ld, olddn, rdn[0], remove_flag);
 #endif
-	  if(res == LDAP_SUCCESS) {
+	  if(rc == LDAP_SUCCESS) {
 	       /* get ready for subsequent DN changes */
 	       g_free(olddn);
 	       g_hash_table_insert(hash, "olddn", g_strdup(dn));
 	  } else {
-	       if (res == LDAP_SERVER_DOWN) {
+	       if (rc == LDAP_SERVER_DOWN) {
 		    server->server_down++;
 	       }
 #if defined(HAVE_LDAP_RENAME)
 	       g_string_sprintf(message, "ldap_rename_s: %s",
-				ldap_err2string(res));
+				ldap_err2string(rc));
 #else
 	       g_string_sprintf(message, "ldap_modrdn2_s: %s",
-				ldap_err2string(res));
+				ldap_err2string(rc));
 #endif
 	       error_push(context, message->str);
 	       push_ldap_addl_error(ld, context);


peter

On Mon, Jul 15, 2002 at 03:55:10PM +0200, Peter Stamfest wrote:
> On Mon, 15 Jul 2002, Bernhard Reiter wrote:

> > 	x500.bund.de
> > 	Base DN=3D o=3Dpki-1-verwaltung,c=3Dde
> >
> > With 0.6.0beta2 I get several entries in the tree (I guess truncated)
> > starting with o=3Dbund,c=3Dde and can retrieve this and subitems.
> >
> > With current cvs I get an error message:
> >   Critical extension is unavailable
> >   Additional error: Unsupported critical extension 2.16.840.1.113730.3.=
4.2
>=20
> This has to do with the very preliminary support for reference handling.
> Just turn off the "show referral" toggle button in the server details=20

Yes, this changes the behaviour, maybe it should be turned off by
default. :)

> The current referral behaviour is primarily there to test how to best deal
> with referrals and as such is not "stable"...

Dealing with a CVS development version I'm of course expecting stuff like t=
his.

Hi Bernhard,

On Mon, 15 Jul 2002, Bernhard Reiter wrote:

> Date: Mon, 15 Jul 2002 15:23:29 +0200
> From: Bernhard Reiter <ber...@in...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] x500.bund.de browse difference
>
> gq 0.6.0beta2 and current cvs from today
> behave differently when trying to browse
>
> 	x500.bund.de
> 	Base DN= o=pki-1-verwaltung,c=de
>
> With 0.6.0beta2 I get several entries in the tree (I guess truncated)
> starting with o=bund,c=de and can retrieve this and subitems.
>
> With current cvs I get an error message:
>   Critical extension is unavailable
>   Additional error: Unsupported critical extension 2.16.840.1.113730.3.4.2

This has to do with the very preliminary support for reference handling.
Just turn off the "show referral" toggle button in the server details and
reconnect to the server (this is now possible by first closing the
connection to the server through the browser popup menu for any object
below a server and continuing with normal work).

That toggle button causes the setting of the ManageDSAit control to
retrieve referral objects as normal objects. Obviously this does not work
with the server you mentioned. (I guess, though I havn't checked, that the
OID you mentioned is just the OID of that control)

The current referral behaviour is primarily there to test how to best deal
with referrals and as such is not "stable"...

>
> Same with the search interface, I cannot find anything with
> the cvs version.
>

All parts of gq are affected by that control, so this is no surprise.

peter

gq 0.6.0beta2 and current cvs from today
behave differently when trying to browse
=09
	x500.bund.de
	Base DN=3D o=3Dpki-1-verwaltung,c=3Dde

With 0.6.0beta2 I get several entries in the tree (I guess truncated)
starting with o=3Dbund,c=3Dde and can retrieve this and subitems.

With current cvs I get an error message:
  Critical extension is unavailable
  Additional error: Unsupported critical extension 2.16.840.1.113730.3.4.2


Same with the search interface, I cannot find anything with=20
the cvs version.

I find it practical to have a version number in the=20
about dialog that indicated if I'm using a CVS version.

One method of doing so can be to set the cvs version number (in the cvs)
to the next planed version including a "cvs" suffix when releasing a tarbal=
l.

Like now (with 0.6.0 released) to "0.6.1cvs"

On Sun, 14 Jul 2002 gw...@ac... wrote:

> Date: Sun, 14 Jul 2002 13:26:24 -0700 (PDT)
> From: gw...@ac...
> To: Peter Stamfest <pe...@st...>
> Cc: Gqc...@li...
> Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
>
>
> Here is my environment:
> 	LDAP client:	gq 0.6
> 	LDAP server:	OpenLDAP 2.0.23 slapd
>
> Here is the steps to reproduce the problem:
>  -> Create an entry with dn set to "cn=Test,dc=mydomain,dc=com" where
>   cn="Test User"
>   sn="User"
>   givenName="Test"
>   result => success
>  -> Change entry dn to "cn=Test User,dc=mydomain,dc=com"
>   result => error "ldap_rename_s: No such attribute" and entry is deleted.
>
>  So the problem seems to occur when the "cn" value (i.e. "Test") in
> the original "dn" does not match the value of the actual original "cn"
> parameter value (i.e. "Test User").

I can verify this, the same happens to me.

Could you try this patch? This fixes the problem for me. But now the
following happens: If you change the RDN of an entry the resulting object
will have the old and the new RDN as an attribute value... Hmmm. Any
suggestions of how to solve this issue? I guess the easiest thing would be
to check if an attribute exists for the current RDN and then set the
remove flag accordingly. Or is there a better way to do this?

The whole thing is not a _real_ gq issue, it is more of a LDAP related
"misfeature", gq just happens to trigger this strange behaviour through
its use of the remove flag... BTW: this behaviour has been there since
input.c was first checked into CVS...

peter


Index: input.c
===================================================================
RCS file: /cvsroot/gqclient/gq/src/input.c,v
retrieving revision 1.42
diff -c -r1.42 input.c
*** input.c	13 Jul 2002 16:47:38 -0000	1.42
--- input.c	14 Jul 2002 21:33:24 -0000
***************
*** 1130,1138 ****
  	  if (c) free(c);

  #if defined(HAVE_LDAP_RENAME)
! 	  res = ldap_rename_s(ld, olddn, rdn[0], NULL, 1, NULL, NULL);
  #else
! 	  res = ldap_modrdn2_s(ld, olddn, rdn[0], 1);
  #endif
  	  if(res == LDAP_SUCCESS) {
  	       /* get ready for subsequent DN changes */
--- 1130,1138 ----
  	  if (c) free(c);

  #if defined(HAVE_LDAP_RENAME)
! 	  res = ldap_rename_s(ld, olddn, rdn[0], NULL, 0, NULL, NULL);
  #else
! 	  res = ldap_modrdn2_s(ld, olddn, rdn[0], 0);
  #endif
  	  if(res == LDAP_SUCCESS) {
  	       /* get ready for subsequent DN changes */






>
>  I've verified the problem does not occur when the "cn" value in "dn"
> matches the actual "cn" parameter.
>
>
> On Sun, 14 Jul 2002, Peter Stamfest wrote:
>
> > Date: Sun, 14 Jul 2002 07:38:07 +0200 (CEST)
> > From: Peter Stamfest <pe...@st...>
> > To: gw...@ac...
> > Cc: Gqc...@li...
> > Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
> >
> > On Sat, 13 Jul 2002 gw...@ac... wrote:
> >
> > > Date: Sat, 13 Jul 2002 14:11:20 -0700 (PDT)
> > > From: gw...@ac...
> > > To: gqc...@li...
> > > Subject: [Gqclient-discuss] Problem changing "dn" attribute
> > >
> > >
> > > I am using gq 0.6 and whenever I try to change the "dn" attribute of
> > > an entry I get an error message about not being able to rename the
> > > attribute and the entry is deleted !!  I would like to know if there is
> > > a way to update the "dn" attribute and I believe deleting the entry
> > > upon error is a critical bug.
> >
> >
> > This works as expected. Are you sure that the entry itself is deleted and
> > not just removed from gq's display? Changing a dn is supported by gq, and
> > only uses either the ldap_rename_s or ldap_modrdn2_s calls. And those
> > should never remove an entry. I _could_ believe that the attributes might
> > be deleted (that would be a possible bug), but that does not happen
> > either.
> >
> > What server are you using? Have you tried to also change the
> > value of the attribute used as the most specific RDN?
> >
> > peter
> >
> >
>

Here is my environment:
	LDAP client:	gq 0.6
	LDAP server:	OpenLDAP 2.0.23 slapd

Here is the steps to reproduce the problem:
 -> Create an entry with dn set to "cn=Test,dc=mydomain,dc=com" where
  cn="Test User"
  sn="User"
  givenName="Test"
  result => success
 -> Change entry dn to "cn=Test User,dc=mydomain,dc=com"
  result => error "ldap_rename_s: No such attribute" and entry is deleted.

 So the problem seems to occur when the "cn" value (i.e. "Test") in
the original "dn" does not match the value of the actual original "cn"
parameter value (i.e. "Test User").

 I've verified the problem does not occur when the "cn" value in "dn"
matches the actual "cn" parameter.


On Sun, 14 Jul 2002, Peter Stamfest wrote:

> Date: Sun, 14 Jul 2002 07:38:07 +0200 (CEST)
> From: Peter Stamfest <pe...@st...>
> To: gw...@ac...
> Cc: Gqc...@li...
> Subject: Re: [Gqclient-discuss] Problem changing "dn" attribute
>
> On Sat, 13 Jul 2002 gw...@ac... wrote:
>
> > Date: Sat, 13 Jul 2002 14:11:20 -0700 (PDT)
> > From: gw...@ac...
> > To: gqc...@li...
> > Subject: [Gqclient-discuss] Problem changing "dn" attribute
> >
> >
> > I am using gq 0.6 and whenever I try to change the "dn" attribute of
> > an entry I get an error message about not being able to rename the
> > attribute and the entry is deleted !!  I would like to know if there is
> > a way to update the "dn" attribute and I believe deleting the entry
> > upon error is a critical bug.
>
>
> This works as expected. Are you sure that the entry itself is deleted and
> not just removed from gq's display? Changing a dn is supported by gq, and
> only uses either the ldap_rename_s or ldap_modrdn2_s calls. And those
> should never remove an entry. I _could_ believe that the attributes might
> be deleted (that would be a possible bug), but that does not happen
> either.
>
> What server are you using? Have you tried to also change the
> value of the attribute used as the most specific RDN?
>
> peter
>
>

-- 

On Sun, 7 Jul 2002, ken restivo wrote:

> Date: Sun, 7 Jul 2002 19:31:56 -0700
> From: ken restivo <ke...@24...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] Patch to 0.6.0 to get it to build on NetBSD
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Needed to do this, in order to get gq 0.6.0 to build on NetBSD 1.5.1.
>
> I also needed to do:
>        CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib \
>         LIBS="-lssl -lcrypto -liconv"  \
>         ./configure --prefix=/usr/X11R6 \
>             --with-ldap-prefix=/usr/pkg \
>             --with-ssl-prefix=/usr/pkg \
>             --with-libiconv-prefix=/usr/pkg
>

What happens if you only do

 LIBS="-liconv" ./configure [the rest]

Is this sufficient? If not, could you send me the output of a plain
./configure run? What version of OpenSSL are you using? The point is: the
-lssl -lcrypto should be picked up automatically.

peter

The patch by Ken Restivo posted recently might fix this.

peter

On Fri, 12 Jul 2002, Bernard Lheureux wrote:

> Date: Fri, 12 Jul 2002 23:55:14 +0200
> From: Bernard Lheureux <tu...@po...>
> To: Multiple recipients of <Gqc...@li...>
> Subject: [Gqclient-discuss] Error message when I compile version 0.6
>
> Could you help me ?
> I try to compile my version 0.6 with basic settings on a Linux-Mandrake=
 7.2,
> the ./configure process works perfectly well and when I launch the "mak=
e" I
> get this error message:
>
> dt_cert.c: In function `dt_cert_fill_clist':
> dt_cert.c:146: `BUF_MEM' undeclared (first use in this function)
> dt_cert.c:146: (Each undeclared identifier is reported only once
> dt_cert.c:146: for each function it appears in.)
> dt_cert.c:146: `bm' undeclared (first use in this function)
> dt_cert.c:146: warning: statement with no effect
> dt_cert.c:147: parse error before `*'
> dt_cert.c:153: `gb' undeclared (first use in this function)
> dt_cert.c:167: warning: statement with no effect
> dt_cert.c:168: parse error before `char'
> dt_cert.c:175: `cols' undeclared (first use in this function)
> dt_cert.c: In function `dt_cert_fill_details':
> dt_cert.c:259: `BUF_MEM' undeclared (first use in this function)
> dt_cert.c:259: `bm' undeclared (first use in this function)
> dt_cert.c:259: warning: statement with no effect
> make[2]: *** [dt_cert.o] Error 1
> make[2]: Leaving directory `/Files/LDAP/gq-0.6.0/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/Files/LDAP/gq-0.6.0'
> make: *** [all-recursive-am] Error 2
>
> And the compile process stops there... what did I miss ?
> Thanks for your help...
>
> --
> (=B0- =A0 Bernard Lheureux Gestionnaire des MailingLists ML, TechML, Li=
nuxML
> //\ =A0 http://www.bbsoft4.org/Mailinglists.htm ** MailTo:root@bbsoft4.=
org
> v_/_ =A0http://www.bbsoft4.org/ <<<<<< * >>>>>> http://www.portalinux.o=
rg/
>

On Sat, 13 Jul 2002 gw...@ac... wrote:

> Date: Sat, 13 Jul 2002 14:11:20 -0700 (PDT)
> From: gw...@ac...
> To: gqc...@li...
> Subject: [Gqclient-discuss] Problem changing "dn" attribute
>
>
> I am using gq 0.6 and whenever I try to change the "dn" attribute of
> an entry I get an error message about not being able to rename the
> attribute and the entry is deleted !!  I would like to know if there is
> a way to update the "dn" attribute and I believe deleting the entry
> upon error is a critical bug.


This works as expected. Are you sure that the entry itself is deleted and
not just removed from gq's display? Changing a dn is supported by gq, and
only uses either the ldap_rename_s or ldap_modrdn2_s calls. And those
should never remove an entry. I _could_ believe that the attributes might
be deleted (that would be a possible bug), but that does not happen
either.

What server are you using? Have you tried to also change the
value of the attribute used as the most specific RDN?

peter

I am using gq 0.6 and whenever I try to change the "dn" attribute of
an entry I get an error message about not being able to rename the
attribute and the entry is deleted !!  I would like to know if there is
a way to update the "dn" attribute and I believe deleting the entry
upon error is a critical bug.

Could you help me ?
I try to compile my version 0.6 with basic settings on a Linux-Mandrake 7=
.2,=20
the ./configure process works perfectly well and when I launch the "make"=
 I=20
get this error message:

dt_cert.c: In function `dt_cert_fill_clist':
dt_cert.c:146: `BUF_MEM' undeclared (first use in this function)
dt_cert.c:146: (Each undeclared identifier is reported only once
dt_cert.c:146: for each function it appears in.)
dt_cert.c:146: `bm' undeclared (first use in this function)
dt_cert.c:146: warning: statement with no effect
dt_cert.c:147: parse error before `*'
dt_cert.c:153: `gb' undeclared (first use in this function)
dt_cert.c:167: warning: statement with no effect
dt_cert.c:168: parse error before `char'
dt_cert.c:175: `cols' undeclared (first use in this function)
dt_cert.c: In function `dt_cert_fill_details':
dt_cert.c:259: `BUF_MEM' undeclared (first use in this function)
dt_cert.c:259: `bm' undeclared (first use in this function)
dt_cert.c:259: warning: statement with no effect
make[2]: *** [dt_cert.o] Error 1
make[2]: Leaving directory `/Files/LDAP/gq-0.6.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/Files/LDAP/gq-0.6.0'
make: *** [all-recursive-am] Error 2

And the compile process stops there... what did I miss ?
Thanks for your help...

--=20
(=B0- =A0 Bernard Lheureux Gestionnaire des MailingLists ML, TechML, Linu=
xML
//\ =A0 http://www.bbsoft4.org/Mailinglists.htm ** MailTo:ro...@bb...=
g
v_/_ =A0http://www.bbsoft4.org/ <<<<<< * >>>>>> http://www.portalinux.org=
/

Hello,

For those of you interested in what is currently going on with gq here is
a short status notice about the current CVS version:

* It is now possible to change the display type of an attribute. Eg. it is
  possible to switch from "binary" to "jpeg". Good if either the server
  schema is wrong or an attribute has a "wrong" syntax attached (eg.
  binary instead of certificate). I have seen both such problems only
  recently. This works by right-clicking on the  attribute name in the right
  pane of the browser and selecting a new display type.

* There is a new display type for the generalizedTime syntax. It allows to
  use a calendar to enter dates. Very convenient if you have to deal with
  dates and/or times in LDAP.

* Very basic support for referrals - but no: there is no following of
  referrals, only a way to add or change them (but this is a first step on
  more). I introduced two new server options to be found in the server
  preferences regarding how to deal with referrals and how to deal with
  normally hidden attributes. Any help with referrals is appreciated.
  Feedback on the new features/displaytypes is also wanted.

[ Footnote: The  "display type" decides how a given attribute should be
presented to the user. Currently there are display types for text, binary
data, (jpeg) images, X509 Certificates, etc... ]

BTW: If you want to see what's going on on the bleeding edge, you may also
subscribe to the gqclient-commit mailing list....

peter

On Fri, 12 Jul 2002, Serge Volkov wrote:

> Date: Fri, 12 Jul 2002 14:33:21 +0400
> From: Serge Volkov <vs...@al...>
> To: Gqclient-Discuss <Gqc...@li...>
> Subject: [Gqclient-discuss] Question about suppurting jpegPhote
>
> Hello all!
>
> I try to use GQ-0.6.0 with all feature: --enable-browser-dnd --enable-cache
>
> I try to insert jpeg photos to directory (server OpenLDAP 2.0.25) and I have question
>
> Do I see photo or simbolols in this field?

You will see the image itself (you need to have gdk_pixbuf available when
building). Otherwise the jpegPhoto will be treated as binary data, andd
you will have the choice to select how this data should be represented
(hex, base64).

Note that you can actually add other images types than JPEG - all the
image types gdk-pixbuf can handle, actually. This obviously is gq specific
- other applications may not be able to work with non-jpeg data.  A LDAP
server could even check for "JPEG-ness", I guess (but I may be wrong).
OpenLDAP doesn't check this.

Also note that the image will be shown in full size - no automatic
generation of a thumbnail or anything like that.

peter

Hello all!

I try to use GQ-0.6.0 with all feature: --enable-browser-dnd --enable-cache

I try to insert jpeg photos to directory (server OpenLDAP 2.0.25) and I have question 

Do I see photo or simbolols in this field?


-- 
With best wishes, Volkov Serge		
Network Administrator/Security Administrator 		

Dear subscribers to the gqclient mailing list....

For reasons impossible to explain the gq discussion mailing list mailman
password was lost quite a while ago. It took until yesterday to get this
problem fixed. In the mean time, a _lot_ of people have subscribed to the
list, but the list was set up to require approval for both subscription
and posting.

I have now
* approved all subscription requests (even very old ones). If you are no
  longer interested in gq, feel free to unsubscribe. Sorry for any
  inconveniences this may have caused.
* changed the list policy to not require approval for subscription and
  posting (but only list members can post to the list)

I will wait for a couple of days and will then approve the pending posts
(hopefully mailman does not send them out _now_, there are some very old
ones there...). I will restrict this to posts less than a certain age I
have not yet fixed. The delay is there to allow people no longer
interested to unsubscribe again.

Regarding gq...

A lot has changed with gq recently:

* Bert Vermeulen has handed over maintainership to me: Thank you Bert for
  the great work you have done. Without him, gq would not exist.

* gq 0.6.0 has been released. It contains many new features and bugfixes
  over earlier versions.

* Sourceforge has become more central. Source distribution is handled
  there as well now.

I have seen that there are some patches among the pending messages. I will
have a look at them ASAP.

Again, sorry for the troubles with this list. I hope this will not happen
again...

peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Needed to do this, in order to get gq 0.6.0 to build on NetBSD 1.5.1.

I also needed to do:
       CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib \
        LIBS="-lssl -lcrypto -liconv"  \
        ./configure --prefix=/usr/X11R6 \
            --with-ldap-prefix=/usr/pkg \
            --with-ssl-prefix=/usr/pkg \
            --with-libiconv-prefix=/usr/pkg

- -ken
- ---------

diff -ur gq-0.6.0/src/dt_cert.c kengq/src/dt_cert.c
- --- gq-0.6.0/src/dt_cert.c      Thu Jun 27 13:01:26 2002
+++ kengq/src/dt_cert.c Sun Jul  7 18:55:11 2002
@@ -47,6 +47,7 @@
 #include <openssl/asn1.h>
 #include <openssl/pem.h>
 #include <openssl/pkcs12.h>
+#include <openssl/buffer.h>
 
 #include "common.h"
 #include "util.h"
diff -ur gq-0.6.0/src/dt_crl.c kengq/src/dt_crl.c
- --- gq-0.6.0/src/dt_crl.c       Thu Jun 27 13:01:26 2002
+++ kengq/src/dt_crl.c  Sun Jul  7 18:55:36 2002
@@ -46,6 +46,7 @@
 #include <openssl/err.h>
 #include <openssl/asn1.h>
 #include <openssl/pem.h>
+#include <openssl/buffer.h>
 
 #include "common.h"
 #include "util.h"


- -- 
- ---------------
Freedom of the press belongs to those who can afford to pay the hosting bill.
Now, that means you! http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9KPmbe8HF+6xeOIcRAhz6AKClRYQIqaqNOz+/P6u6NMonMvJLLwCaAgGI
XK8RRuVptJj5lrQ7fjQJsKM=
=AX+K
-----END PGP SIGNATURE-----

hello

i had a look at the gq mailing list archives and i didn't find much
help. i appeal to you good people of the greater internet community.

is there any known problem connecting to openldap 2.1.2 with gq (.5.0 and
.3.0) all running on solaris 8?

both gq versions connect just fine to openldap 2.0.23 and earlier as far
as i can see.

the error i get when trying to connect is...


(lit old-fashioned bomb) Couldn't bind LDAP connection: Protocol error


any help greatly appreciated.

alex