Update of uniquemember attribute on DN change of a user
by Carsten Grzemba
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
12 years, 1 month
User last bind timestamp attribute?
by Marco Pizzoli
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
12 years, 1 month
ACI for read only access
by Walter Neu
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
12 years, 1 month
slapi-nis-0.36/34 compile on rh5
by cnu
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
12 years, 1 month
SASL Mappings Question
by Michael Gettes
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
12 years, 1 month
replication failure - clock skew
by Greg Kuchyt
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.
12 years, 1 month
How do read-only consumers work?
by Groten, Ryan
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.
12 years, 1 month
Re: [389-users] Admin Server - Encryption Tab
by Rich Megginson
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./
>
12 years, 1 month
Re: [389-users] Admin Server - Encryption Tab
by Rich Megginson
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./
>
12 years, 1 month