389-users February 2012

389-users@lists.fedoraproject.org

35 participants
60 discussions

Update of uniquemember attribute on DN change of a user
by Carsten Grzemba 16 Feb '12

16 Feb '12

Hi, if I move a user entry which is member of a group too a different OU or I delete a user, than the corresponding uniquemember attribute value will not updated automatically. Is this behaviour correct? Is there a tool/task to fixup this broken uniquemember entries? 389 Project 389-Directory/1.2.9.9 B2012.027.89 Thanks, Carsten

1 0

User last bind timestamp attribute?
by Marco Pizzoli 15 Feb '12

15 Feb '12

Hi, I would like to know if, in 389DS, is there the possibility to know when a user last authenticated to the system. In OpenLDAP there is an overlay called slapo-lastbind which populate an operational attribute in the user entry called authTimestamp. I'm curious to know is something similar exists for 389DS. If yes, is this attribute also propagated in a multi-master deployment. Thanks in advance Marco

2 2

ACI for read only access
by Walter Neu 14 Feb '12

14 Feb '12

Hi all, I'm confused about ACI and need some help from the experts.... I want to create an ACI for read only access to a certain branch of my LDAP tree. Therefor I created the following ACI (targetattr = "userPassword || uid") (target = "ldap:///ou=AABenutzer,ou=eurodatasb,dc=eurodata,dc=de") (version 3.0;acl "read only";allow (read)(userdn = "ldap:///uid=ro_user,ou=Special Users,dc=eurodata,dc=de");) But when I am authenticated with user ro_user, I got information which are outside the branch ou=AABenutzer,ou=eurodatasb,dc=eurodata,dc=de What I'm doing wrong??? Thanks

2 1

slapi-nis-0.36/34 compile on rh5
by cnu 14 Feb '12

14 Feb '12

Hello, last week the ns-slapd process was killed from oom-killer on our ldap/nis system. I found in the changelog from slapi-nis: 0.31 * Fix some memory leaks. So I tried to compile slapi-nis-0.36 on Redhat 5 x86_64 But I get following error: /libtool: link: gcc -shared -fPIC -DPIC .libs/back-nis.o .libs/back-shr.o .libs/defs-nis.o .libs/disp-nis.o .libs/format.o .libs/map.o .libs/nis.o .libs/plug-nis.o .libs/portmap.o .libs/wrap.o -lssldap60 -lprldap60 -lldap60 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lwrap -lnsl -O2 -m64 -mtune=generic -Wl,-soname -Wl,nisserver-plugin.so -Wl,-version-script -Wl,.libs/nisserver-plugin.ver -o .libs/nisserver-plugin.so libtool: link: ( cd ".libs" && rm -f "nisserver-plugin.la" && ln -s "../nisserver-plugin.la" "nisserver-plugin.la" ) /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 -O2 -g -m64 -mtune=generic -c -o back-sch.lo back-sch.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 -O2 -g -m64 -mtune=generic -c back-sch.c -fPIC -DPIC -o .libs/back-sch.o back-sch.c: In function 'backend_sch_scope_as_string': back-sch.c:991: error: invalid storage class for function 'backend_search_cb' back-sch.c:1091: error: invalid storage class for function 'backend_locate_cb' back-sch.c:1124: error: invalid storage class for function 'backend_locate' back-sch.c:1152: error: invalid storage class for function 'backend_group_check_scope_cb' back-sch.c:1168: error: invalid storage class for function 'backend_check_scope_pb' back-sch.c:1187: error: invalid storage class for function 'backend_write_cb' back-sch.c:1211: error: invalid storage class for function 'backend_bind_cb' back-sch.c:1255: error: invalid storage class for function 'backend_compare_cb' back-sch.c:1375: error: expected declaration or statement at end of input make[2]: *** [back-sch.lo] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/slapi-nis-0.36/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/slapi-nis-0.36/src' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.97014 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.97014 (%build)/ I tried to find a answer with Google, but no success. Version 0.28 compiles fine. br, Christian Neuhold

2 2

SASL Mappings Question
by Michael Gettes 13 Feb '12

13 Feb '12

I have a need to use a search filter in SASL mappings where it looks like something (&(uid=\1)(|(objectclass=x)(objectclass=y))) the & is being substituted like \1 as seen with tracing turned on. I have tried escaping it as \& and \\& <smb://&>. I can't find any documentation on how the substitution is handled with the filter. Is it not possible to utilize a normal ldap search filter like this in SASL mappings? thanks for answers and/or pointers. /mrg

2 3

The 389 wiki is moving to a new machine
by Rich Megginson 10 Feb '12

10 Feb '12

We are moving the 389 wiki to a new machine. There appear to be some problems with DNS at the moment. If you use www.port389.org you can get to the new machine. port389.org and directory.fedoraproject.org don't appear to be working in DNS yet. It may take a few hours for the changes to make it to all of the DNS servers.

1 0

replication failure - clock skew
by Greg Kuchyt 10 Feb '12

10 Feb '12

Yesterday afternoon, one of my consumers randomly crashed/rebooted. Upon rebooting, its replication agreement with its master failed with the following error: Unable to acquire replica: Excessive clock skew between the supplier and the consumer. Replication is aborting I did a little bit of Google searching and found some list traffic from a few years ago. From that I derived that this replica was hosed and I would need to re-initialize it. No problem. A re-initialization didn't do anything, same error. Starting from scratch from a completely new/fresh replica produces the same result. That's when I noticed the following errors in the logs on the master. csngen_new_csn - Warning: too much time skew (-115319 secs). Current seqnum=1 I downloaded the readNsState.py script attached to the following ticket (https://bugzilla.redhat.com/show_bug.cgi?id=233642) Running this on the master produced the following output For replica cn=replica,cn=o\3Dpotsdam.edu,cn=mapping tree,cn=config len of nsstate is 40 CSN generator state: Replica ID : 6560 Sampled Time : 1328928777 Time in hex : 0x4f35d809 Time as str : Fri Feb 10 21:52:57 2012 Local Offset : 0 Remote Offset : 261 Seq. num : 1 System time : Thu Feb 9 14:00:01 2012 Diff in sec. : -114776 This leads me to believe that the clock skew problem is on the master. I am not really sure how the clock skew happened. All of these systems synchronize their clocks via a centralized time server and all the times on their clocks are correct. There are 3 or 4 other replicas that are still receiving incremental updates fine, but any attempt to add a new replica results in a failed replication agreement due to excessive clock skew. I am writing to get a better understanding of the situation and see if there is anything to be done to resolve this. At the moment it seems as if I am caught in an unfortunate situation that will require re-initialization of my master from a back-up. Thanks for any help that can be provided.

2 5

How do read-only consumers work?
by Groten, Ryan 09 Feb '12

09 Feb '12

Hi all, I'm testing out setting up 2 read-only consumers (each matches 1 of 2 multi-masters). Seems to be working fine, but I'm just trying to wrap my head around what's happening when changes are made: 1. Have 2 multi-master Directory Servers (1.2.9.9) setup and running 2. Create another DS, set Replication to "dedicated consumer" 3. Create a replication agreement from 1 of the multi-masters to this consumer 4. Modify an entry from the consumer 5. Change is made on the read-only server and on the multi-masters There's no replication agreement going FROM the consumer to the master, but I see changes on the master side anyways. Is the consumer sending a request with the change to the master, who then makes the change and replicates it back to the consumer? If the above is true, then how would I go about doing something like this: The goal I'm trying to achieve is I want to put some read-only DS in an external zone. In theory I don't think the read-only's should be able to modify the masters for security reasons (ie: if someone external compromises the external DS, they shouldn't be able to delete all the entries in the internal). However, having the option to allow certain changes from the external into internal may be useful (maybe allowing password changes from the read-only to the master or something). Thanks, Ryan ________________________________ This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply.

2 4

Re: [389-users] Admin Server - Encryption Tab
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/09/2012 11:07 AM, MATON Brett wrote: > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 09 February 2012 19:00 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] Admin Server - Encryption Tab > > On 02/09/2012 10:58 AM, MATON Brett wrote: > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 09 February 2012 18:43 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] Admin Server - Encryption Tab > > On 02/09/2012 10:33 AM, MATON Brett wrote: > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 09 February 2012 18:19 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] Admin Server - Encryption Tab > > On 02/09/2012 10:13 AM, MATON Brett wrote: > > Platform RHEL6.2 x86_64 (EPEL repository enabled) > > $ rpm -qa | grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > 389-admin-1.1.25-1.el6.x86_64 > > gpg-pubkey-b3892132-4c63febc > > 389-dsgw-1.1.7-2.el6.x86_64 > > I can only access the Encryption Tab of 389 Admin Server from the > local host. > > When I try to access it from a remote desktop, it hangs for want of a > better description at "Loading" the progress bar in the bottom right > corner fills up and then starts over. > > Nothing to note in the logs other than: > > Blah admserv_host_ip_check: ap_get_remote_host could not resolve blah > > Which is another thread... > > This happens whether I'm using LDAPS to plain vanilla LDAP. > > Any thoughts ? > > you do seem to have the magic bug finger . . . (I have my Moments J) > > try 389-console -D 9 -f console.log > to see if there is anything interesting in the console.log > > hmm - try > rm -rf ~/.389-console > to clear out the jar file cache > then run the console again > > New output, attached complete log (Googlizing the NMC errors didn't > return much...): > > Not sure why you are getting NoSuchMethodError > That seems like a mismatch between jar files > > Try updating to the latest packages from epel-testing on both the > client and the server > > server - yum update --enablerepo=epel-testing idm-console-framework > 389-console 389-admin-console 389-ds-console 389-admin > client - yum update --enablerepo=epel-testing idm-console-framework > 389-console > unless the client is also a server, in which case use the packages for > server > > > > > > I'll Update the server now and try it again, the client is running > on Windows 7 x64 > (http://port389.org/download/389-Console-1.1.6-x86_64.msi) > > Ah, ok. The cache dir is different on Windows. Not sure where it is > - I guess you could look for a .389-console folder somewhere under > \users\yourusername > Yeah, sits my users "home" as .389-console. > > (canned it as requested, before last log). > > I only got a few new packages after enabling epel-testing: > > # yum list | grep 389 > > 389-admin.x86_64 1.1.27-1.el6 > @epel-testing > > 389-admin-console.noarch 1.1.8-1.el6 @epel > > 389-admin-console-doc.noarch 1.1.8-1.el6 @epel > > 389-adminutil.x86_64 1.1.14-2.el6 @epel > > 389-console.noarch 1.1.7-1.el6 @epel > > 389-ds.noarch 1.2.2-1.el6 @epel > > 389-ds-base.x86_64 1.2.9.14-1.el6_2.2 @Updates > > 389-ds-base-libs.x86_64 1.2.9.14-1.el6_2.2 @Updates > > 389-ds-console.noarch 1.2.6-1.el6 @epel > > 389-ds-console-doc.noarch 1.2.6-1.el6 @epel > > 389-dsgw.x86_64 1.1.7-2.el6 @epel > > 389-admin.i686 1.1.27-1.el6 > epel-testing > > 389-adminutil.i686 1.1.15-1.el6 > epel-testing > > 389-adminutil.x86_64 1.1.15-1.el6 > epel-testing > > 389-adminutil-devel.i686 1.1.15-1.el6 > epel-testing > > 389-adminutil-devel.x86_64 1.1.15-1.el6 > epel-testing > > 389-ds-base-libs.i686 1.2.9.14-1.el6_2.2 > rhel6-base-x86_64 > > 389-dsgw.x86_64 1.1.9-1.el6 > epel-testing > > You don't want to update the 389-ds-base* or 389-ds packages > > Not sure why you are getting .i686 and .x86_64 packages > Any suggestions on how to replace the pair of updates packages? > > I'll drop the 686 packs and see if it breaks anything. > > My bad the previous list was from yum"list" > > # rpm qa | grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-admin-1.1.27-1.el6.x86_64 > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64* > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > gpg-pubkey-b3892132-4c63febc > > 389-dsgw-1.1.7-2.el6.x86_64 > > Still leaves the 389-base issue though, for what it's worth this was a > fresh install with epel enabled (yum install 389-ds) > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > this is the latest available RHEL 6.2.Z 389-ds-base package - it is > not in EPEL > > > > * > > Sure, I didn't disable the RHEL repos when I installed 389-ds. Left > it to do its thing... > > Which version of 389-ds-base should I be using ? > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64 is fine > > > * > > Doh! Pulled 389-base-1.2.9.9 from your fedorapeople repo ( no > difference though). > > Attached compressed log (previous attempt bounced). ß Left over from > a previous post. > > Looks like it is still bouncingß > > > are you still getting the NoSuchMethodError error? > > Yes, still getting that exception thrown. > > > What version of Java are you using on Windows? > > > > C:\Program Files\389 Management Console>java -version > > java version "1.7.0_01" > > Java(TM) SE Runtime Environment (build 1.7.0_01-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode) > > Hmm - have not tried with 1.7 - could be that we need to port/build > console with 1.7? > > > Possibly, the Linux clients are running 1.6, just tried one of those > and it worked as expected. > > The linux clients are probably running openjdk 1.6 too - so could be > openjdk vs. sun issue too > > java - write once, port everywhere :P > > Well at least we're getting some where J > > Anything you want me try? (will be tomorrow, can't use the GUI with > my remote connection). > Please file a ticket - console doesn't work with Sun Java 1.7 on Windows 7 > > Brett > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

Re: [389-users] Admin Server - Encryption Tab
by Rich Megginson 09 Feb '12

09 Feb '12

On 02/09/2012 10:58 AM, MATON Brett wrote: > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 09 February 2012 18:43 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] Admin Server - Encryption Tab > > On 02/09/2012 10:33 AM, MATON Brett wrote: > > *From:*Rich Megginson [mailto:rmeggins@redhat.com] > *Sent:* 09 February 2012 18:19 > *To:* MATON Brett > *Cc:* General discussion list for the 389 Directory server project. > *Subject:* Re: [389-users] Admin Server - Encryption Tab > > On 02/09/2012 10:13 AM, MATON Brett wrote: > > Platform RHEL6.2 x86_64 (EPEL repository enabled) > > $ rpm -qa | grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > 389-admin-1.1.25-1.el6.x86_64 > > gpg-pubkey-b3892132-4c63febc > > 389-dsgw-1.1.7-2.el6.x86_64 > > I can only access the Encryption Tab of 389 Admin Server from the > local host. > > When I try to access it from a remote desktop, it hangs for want of a > better description at "Loading" the progress bar in the bottom right > corner fills up and then starts over. > > Nothing to note in the logs other than: > > Blah admserv_host_ip_check: ap_get_remote_host could not resolve blah > > Which is another thread... > > This happens whether I'm using LDAPS to plain vanilla LDAP. > > Any thoughts ? > > you do seem to have the magic bug finger . . . (I have my Moments J) > > try 389-console -D 9 -f console.log > to see if there is anything interesting in the console.log > > hmm - try > rm -rf ~/.389-console > to clear out the jar file cache > then run the console again > > New output, attached complete log (Googlizing the NMC errors didn't > return much...): > > Not sure why you are getting NoSuchMethodError > That seems like a mismatch between jar files > > Try updating to the latest packages from epel-testing on both the > client and the server > > server - yum update --enablerepo=epel-testing idm-console-framework > 389-console 389-admin-console 389-ds-console 389-admin > client - yum update --enablerepo=epel-testing idm-console-framework > 389-console > unless the client is also a server, in which case use the packages for > server > > > > > I'll Update the server now and try it again, the client is running > on Windows 7 x64 > (http://port389.org/download/389-Console-1.1.6-x86_64.msi) > > Ah, ok. The cache dir is different on Windows. Not sure where it is > - I guess you could look for a .389-console folder somewhere under > \users\yourusername > Yeah, sits my users "home" as .389-console. > > (canned it as requested, before last log). > > I only got a few new packages after enabling epel-testing: > > # yum list | grep 389 > > 389-admin.x86_64 1.1.27-1.el6 > @epel-testing > > 389-admin-console.noarch 1.1.8-1.el6 @epel > > 389-admin-console-doc.noarch 1.1.8-1.el6 @epel > > 389-adminutil.x86_64 1.1.14-2.el6 @epel > > 389-console.noarch 1.1.7-1.el6 @epel > > 389-ds.noarch 1.2.2-1.el6 @epel > > 389-ds-base.x86_64 1.2.9.14-1.el6_2.2 @Updates > > 389-ds-base-libs.x86_64 1.2.9.14-1.el6_2.2 @Updates > > 389-ds-console.noarch 1.2.6-1.el6 @epel > > 389-ds-console-doc.noarch 1.2.6-1.el6 @epel > > 389-dsgw.x86_64 1.1.7-2.el6 @epel > > 389-admin.i686 1.1.27-1.el6 > epel-testing > > 389-adminutil.i686 1.1.15-1.el6 > epel-testing > > 389-adminutil.x86_64 1.1.15-1.el6 > epel-testing > > 389-adminutil-devel.i686 1.1.15-1.el6 > epel-testing > > 389-adminutil-devel.x86_64 1.1.15-1.el6 > epel-testing > > 389-ds-base-libs.i686 1.2.9.14-1.el6_2.2 > rhel6-base-x86_64 > > 389-dsgw.x86_64 1.1.9-1.el6 > epel-testing > > You don't want to update the 389-ds-base* or 389-ds packages > > Not sure why you are getting .i686 and .x86_64 packages > Any suggestions on how to replace the pair of updates packages? > > I'll drop the 686 packs and see if it breaks anything. > > My bad the previous list was from yum"list" > > # rpm qa | grep 389 > > 389-admin-console-doc-1.1.8-1.el6.noarch > > 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 > > 389-admin-console-1.1.8-1.el6.noarch > > 389-admin-1.1.27-1.el6.x86_64 > > 389-adminutil-1.1.14-2.el6.x86_64 > > 389-ds-console-1.2.6-1.el6.noarch > > 389-ds-1.2.2-1.el6.noarch > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64* > > 389-ds-console-doc-1.2.6-1.el6.noarch > > 389-console-1.1.7-1.el6.noarch > > gpg-pubkey-b3892132-4c63febc > > 389-dsgw-1.1.7-2.el6.x86_64 > > Still leaves the 389-base issue though, for what it's worth this was a > fresh install with epel enabled (yum install 389-ds) > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64 > this is the latest available RHEL 6.2.Z 389-ds-base package - it is > not in EPEL > > > * > > Sure, I didn't disable the RHEL repos when I installed 389-ds. Left > it to do its thing... > > Which version of 389-ds-base should I be using ? > > *389-ds-base-1.2.9.14-1.el6_2.2.x86_64 is fine > > * > > Doh! Pulled 389-base-1.2.9.9 from your fedorapeople repo ( no > difference though). > > Attached compressed log (previous attempt bounced). ß Left over from > a previous post. > > Looks like it is still bouncingß > > > are you still getting the NoSuchMethodError error? > > Yes, still getting that exception thrown. > > > What version of Java are you using on Windows? > > > C:\Program Files\389 Management Console>java -version > > java version "1.7.0_01" > > Java(TM) SE Runtime Environment (build 1.7.0_01-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode) > > Hmm - have not tried with 1.7 - could be that we need to port/build > console with 1.7? > > Possibly, the Linux clients are running 1.6, just tried one of those > and it worked as expected. > The linux clients are probably running openjdk 1.6 too - so could be openjdk vs. sun issue too java - write once, port everywhere :P > > Brett > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB** > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ > > ------------------------------------------------------------------- > > *GreeNRB > */NRB considers its environmental responsibility and goes for green IT./ > /May we ask you to consider yours before printing this e-mail? /** > > *NRB, daring to commit > */This e-mail and any attachments, which may contain information that > is confidential and/or protected by intellectual property rights, are > intended for the exclusive use of the above-mentioned addressee(s). > Any use (including reproduction, disclosure and whole or partial > distribution in any form whatsoever) of their content is prohibited > without prior authorization of NRB. If you have received this message > by error, please contact the sender promptly by resending this e-mail > back to him (her), or by calling the above number. Thank you for > subsequently deleting this e-mail and any files attached thereto./ >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users February 2012