Hi,
Apache Directory Studio appears to have FUBAR'ed one of the nodes in our
multi-master OpenLDAP setup and I'd appreciate some help or pointers.
Im running OpenLDAP 2.4.21 and BDB 4.8.26 with Kerberos 5 and GSSAPI SASL.
On the afflicted node the DIT is empty other than the Root DSE and
Kind regards,
Mark
/*
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
*/
but in the meantime is there any
way to ensure this field is preserved when provisioning accounts in LDAP?
Kind regards,
Mark
/*
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
Warning duly noted. Lessing the files in question seemed like the best way of
providing a concise description of what configuration I had and where in the
config it lay.
As it stands I answered my question anyway.
Kind regards,
Mark
On 27 Jan 2011, at 12:16, Howard Chu wrote:
Mark Cairney
this given that it's invisible to ldapsearch and if you try an
ldapadd the object already exists?
Even a sample ldif file for ldapmodify would be grand.
Cheers,
Mark
/*
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
of OpenLDAP is a little bit odd as well though so I'll file an
ITS.
Cheers,
Mark
On 10 Jun 2011, at 16:30, Quanah Gibson-Mount wrote:
--On Friday, June 10, 2011 3:04 PM +0100 Mark Cairney mark.cair...@ed.ac.uk
wrote:
Hi,
I've been trying to use a tool called Grouper to provision
:: the leader in open source messaging and collaboration
/*
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
*/
--
The University of Edinburgh is a charitable body
::
ezN9dG8gZG4uc3VidHJlZT0ib3U9cHVibGljLG91PWFkZHJlc3Nib29rLGRjPWtva2
VsbmV0LGRjPWRlIiBieSAqIHdyaXRlIA==
What's going on here, what did I wrong, I didn't get it yet. Please help
me.
Regards,
Tobias Hachmer
--
/
Mark Cairney
ITI UNIX Section
Information Services
Tel: 0131 650 6565
Email: mark.cair
Hi,
I've been finding that ldapsearch will freeze when performing searches with a
large (typically 10,000) number of results.
As far as I can tell this does not appear to be related to server load as
according to iostat and top the servers don't appear to be stressed
and the servers continue to
My olcDB values are listed below (minus the olcDbConfig entries). I'm not sure
if you need the indexes but I've left them in anyway:
olcDbDirectory: /usr/local/authz/var/openldap-data/authorise
olcAddContentAcl: FALSE
olcDbCacheFree: 1
olcDbCacheSize: 40
olcDbCheckpoint: 10240 10
On 26 Sep 2012, at 22:36, Quanah Gibson-Mount wrote:
--On Wednesday, September 26, 2012 11:59 AM +0100 Mark Cairney
mark.cair...@ed.ac.uk wrote:
My olcDB values are listed below (minus the olcDbConfig entries). I'm not
sure if you need the indexes but I've left them in anyway
Hi,
I've acquired the libmdb tools from the Gitorious page. I've got it to compile
(with some warnings, see below) but it throws an error when I try and run
mdb_stat on the mdb directory:
Compilation yields the following:
[root@birch libmdb]# ./make.sh
gcc -pthread -O2 -g -DMDB_DSYNC=O_SYNC
On 27/11/2012 19:29, Howard Chu wrote:
Your first mistake was not actually reading the gitorious page. Go
read it again.
The OpenLDAP source tree already includes the MDB source code.
D'oh! Indeed sitting in my openldap source directory there is a
libraries/libmdb directory with a
Hi,
On 08/07/2013 12:47, Pradyumna wrote:
Hi,
I have configured mirror mode replication. It's 2 node. Everything works fine
but if I don't work on the server or say 30/40 mins or so and then when I try
to add or delete any users or groups it don't get replicated to the other node.
Am not
at the moment as a
number of our departments use them to provide subsets of their own
users(ITS#7657).
Kind regards,
Mark
--
/
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
On 07/02/2014 17:38, Quanah Gibson-Mount wrote:
--On Friday, February 07, 2014 5:17 PM + Mark Cairney
mark.cair...@ed.ac.uk wrote:
Hi,
Having recently experienced some issues with our Live server (2.4.38,
Scientific Linux 6.4 64-bit) I was looking into possible causes and
found
dump of my config in both HDB and MDB modes is probably a good
place to start.
--
/
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
***/
The University
--
/
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
***/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number
those schema into new Openldap.2.4.39 . I have
gone through Admin guide tried some methods but, I didn't get much help from
it. Kindly help me or whom should I contact or any specific materials.
Thank You,
Abhishek koserwal,
/
Mark Cairney
ITI UNIX Section
On 20 Sep 2014, at 16:48, Howard Chu h...@symas.com wrote:
Mark Cairney wrote:
Hi,
Coincidentally I was adding a flat .schema file to my cn=config setup
yesterday, here’s my (rather brief) notes on the conversion process:
The direct manual steps are documented in schema/openldap.ldif
ckend.
We do have a large number of aliases (~63,000). Could this be the cause?
Our olcMaxDerefDepth is currently set to "1"
--
/********
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.a
10, Andrew Findlay wrote:
> On Mon, Nov 16, 2015 at 03:13:11PM +, Mark Cairney wrote:
>
>> We're having severe performance issues for any query with alias
>> dereferencing set to "always".
>>
>> Any query with this causes the CPU to spin up to 100% and if we
On 17/11/2015 11:26, Andrew Findlay wrote:
On Tue, Nov 17, 2015 at 11:11:04AM +, Mark Cairney wrote:
Just as an update- we've managed to restore service. It turns out that
we had went over the value of 65,535 (66,291) aliases which we think was
the root cause of this behaviour suddenly
be a push for them to
re-evaluate this approach.
On 16/11/15 18:44, Mark Cairney wrote:
> Hi Andrew,
>
> Thanks for getting back. I saw your report for mdb actually. I can
> confirm that I've got "olcDBIndex objectlass eq" set on my servers.
>
> Everyo
t;>
>> All other query that not derf. aliases are processed very fast.
>> Search time about 32k entries in subtree without aliases is about
>> 0,526s.
>>
>> Our server DB and indexing settings:
>>
>> maxsize 10737418240
>> checkpo
iour.
Any ideas? At the moment I've proceeded to go-live with pull-based
replication but it would be nice to get push-based replication working.
Also while I have the "old" servers sitting there it makes sense to use
these for testing/debugging before retiring them.
--
/
lanning to update to
> 2.4.44 this summer. Would it be better to hold off on such an update?
>
> Thanks...
>
>
--
/
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
PGP: 0x435A
Sure, the ITS is 8444:
http://www.openldap.org/its/index.cgi/Incoming?id=8444;page=44
I'm out the office this week anyway so won't be in a position to do any
testing etc till next.
On 21/06/2016 02:39, Paul B. Henson wrote:
On Thu, Jun 16, 2016 at 10:10:19AM +0100, Mark Cairney wrote
wrote:
> --On Wednesday, June 15, 2016 1:59 PM +0100 Mark Cairney
> <mark.cair...@ed.ac.uk> wrote:
>
>> Hi Quanah,
>>
>> I can confirm I still see the issue when deleting and adding user
>> objects and groups using 3-way delta-MMR.
>
> Please keep repli
the table. Other than
those, I haven't had problems with 2.4.44 + ITS8432. ;)
Cool. Are you using the memberOf overlay? It doesn't look like there's
been any update on ITS 8444 that Mark Cairney reported a month or so ago
in which he said he was seeing replication issues with 2.4.44 + ITS8432
fix
this?
>
> Cheers
> Toby Blake
> School of Informatics
> University of Edinburgh
>
--
/
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
PGP: 0x435A9621
*
Hi Frank,
On 01/07/16 14:15, Frank Swasey wrote:
> Today at 7:15am, Mark Cairney wrote:
>
>> Another gotcha is w.r.t. rate limiting as both journald and rsyslog
>> implement this independently of one another. Disabling this completely
>> can make the bottleneck m
w config database
5. If 4 is successful, move your data directory aside and
6. Slapadd your data ldif.
7. Go for a (short) cup of tea
8. Fire up slapd.
--
/********
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...
On 12/01/2017 22:27, Michael Ströder wrote:
You could try using option exattrs with syncrepl statement, see slapd.conf(5).
Ciao, Michael.
Awesome, sounds exactly what I was looking for!
Kind regards,
Mark
--
The University of Edinburgh is a charitable body, registered in
Scotland, with
Hi Quanah,
On 12/01/17 16:06, Quanah Gibson-Mount wrote:
The correct fix is to modify your syncrepl configuration so that those
attributes are ignored by the syncrepl client. There is no patch to the
code necessary.
Possibly a dumb question but do you have a worked example of this? The
e if the issue goes away. Am I
>> correct in my assumption that the patch only needs to be applied to the
>> system that is receiving the updates?
>
> I'd apply it everywhere you have syncprov configured, these could send a
> cookie with too little information for a replica to spot and
you have the root in there too).
Of course we do realise LDAP is not HTTP!
We're running OpenLDAP 2.4.47 linked against OpenSSL on Scientific Linux
7.5.
Kind regards,
Mark
--
/****
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel:
and tend to use
service accounts for client authentication. We may look to support
client cert verification in the future using our own internal CA.
Kind regards,
Mark
On 13/04/2019 15:48, A. Schulze wrote:
>
>
> Am 11.04.19 um 13:35 schrieb Mark Cairney:
>
> Hello Mark,
>
>&
jectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
dn: olcDatabase={3}monitor,cn=config
objectClass: olcMonitorConfig
objectClass: olcDatabaseCon
Hi Quanah,
On 05/06/2019 19:09, Quanah Gibson-Mount wrote:
> --On Wednesday, June 05, 2019 11:38 AM +0100 Mark Cairney
> wrote:
>
>> Hi,
>>
>> We currently run a multi-master setup where all 4 of our servers
>> replicate from each other via delta-syncrepl b
On 06/06/2019 16:30, Quanah Gibson-Mount wrote:
> Hi Mark,
>
> --On Thursday, June 06, 2019 1:12 PM +0100 Mark Cairney
> wrote:
>
>>> I.e., the only way you can ensure slapo-memberof will be "ok" in an
>>> replicated environment (syncrepl or
common OpenLDAP
configs (e.g. single node, 2-way MMR, n-way MMR, single-master with
multiple replicas etc).
Kind regards,
Mark
--
/
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
PG
LogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: o
mberOf. I definitely appreciate
the ability to query on dynamic memberOf that was added in 2.5, but it
would be nice to sort out this performance issue.
--
/********
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: m
44 matches
Mail list logo
