I have no issues with that. I’m a little concerned about the ldap message id,
however.
> On May 18, 2016, at 9:02 AM, Rich Megginson <rmegg...@redhat.com> wrote:
>
> On 05/17/2016 02:04 PM, Robert Viduya wrote:
>> We run a cluster of directory servers (4 masters, 2 hu
We run a cluster of directory servers (4 masters, 2 hubs, 14 slaves) behind a set of F5 Bigip load balancers. Our Bigip admins recently decided to switch the boxes to "one-armed" mode and that services would have to use X-Forwarded-For headers or equivalent to get the actual client IP address.
, Robert Viduya wrote:
On Mar 9, 2015, at 5:30 PM, Noriko Hosoi nho...@redhat.com wrote:
Hello,
On 03/09/2015 02:18 PM, Robert Viduya wrote:
I'm in the same boat. We, as an enterprise, have standardized on RHEL6
as our OS, with RHEL7 only on the horizon. Switching to either Fedora
I'm in the same boat. We, as an enterprise, have standardized on RHEL6 as our
OS, with RHEL7 only on the horizon. Switching to either Fedora or CentOS isn't
an option. But the only official 389 release for RHEL6 is years old.
I reported a bug about a year ago, 47739, that's been fixed since
On Mar 9, 2015, at 5:30 PM, Noriko Hosoi nho...@redhat.com wrote:
Hello,
On 03/09/2015 02:18 PM, Robert Viduya wrote:
I'm in the same boat. We, as an enterprise, have standardized on RHEL6 as
our OS, with RHEL7 only on the horizon. Switching to either Fedora or
CentOS isn't
We're trying to get GSSAPI authentication working with 389 and following the
doc page on the website, I think I've gotten it working a little too well.
We're using the stock ldapsearch command that comes with RHN, I believe it's
from openldap. Here's a command log
$ kinit
This isn't a client issue, this is a server issue. The server is allowing me
to bind to one user using another user's credentials. It's the server's
responsibility to verify proper credentials on bind requests.
On Mar 6, 2014, at 6:17 PM, Paul Robert Marino prmari...@gmail.com wrote:
This
Not sure, but if there is, it should be on (ignore authzid) by default.
Please file a ticket.
Shucks, I was hoping for a quick answer, some setting I had overlooked.
We're running a version that's about a year old, 389-Directory/1.2.11.15
B2013.100.2247. I think I'll stand up a test
I've enabled the core dump stuff, but now I can't seem to get it to crash.
But I'm still getting the changelog messages in the error logs whenever I
restart. In addition, the hub server keeps running out of disk space. I
tracked it down to the access log filling up with MOD messages
I'm having issues with this as well, but I'm trying to do a clean install, not
an upgrade. I pulled down 389-dsgw-1.1.7-2.el5.x86_64.rpm as suggested, but
it's failing to install with dependency errors as well:
# yum localinstall 389-dsgw-1.1.7-2.el5.x86_64.rpm
Loaded plugins: downloadonly,
On Dec 21, 2010, at 8:17 PM, Marc Sauton wrote:
Check the access log file for the bind attempts, and
nsslapd-allow-anonymous-access in your dse.ldif
Try to click OK and provide pw if prompted again.
May be related to these reports:
https://bugzilla.redhat.com/show_bug.cgi?id=627906
11 matches
Mail list logo
