389-users November 2015

389-users@lists.fedoraproject.org

28 participants
32 discussions

Moving Direcoties dirsrv andlog to a new Disk
by Andy Spooner 16 Nov '15

16 Nov '15

Hi, I am running 389-ds on CentOs 6.7. I am trying to move 389-ds off the disk that contains my root to a second disk that has space for the directory to grow. Can someone please advise on the correct way to move files and maintain selinux contexts. I moved the files using the method below, but logs cannot be written to - please see error message at the bottom of this email. Setup CentOs 6.7 selinux= enforcing Second disk /mnt/ds389/data/ /mnt/389ds/log/ i used cp -rcp to copy and preserve SELINUX contexts and user rights 1. Stop dirsrv 2. cp -rcp /var/lib/dirsrv/ /mnt/ds389/data/ 3. Checked selinux context using ls -Z dirsrv output: drwxrwx---. nobody nobody unconfined_u:object_r:dirsrv_var_lib_t:s0 slapd-eu-vc-pmldap01 4. renamed /var/lib/dirsrv (keep original files under a different name) 5. Create symbolic link # ln -s /mnt/389ds/data/ dirsrv Logs 6. cp -rcp /var/log/dirsrv /mnt/389ds/log/ 7. Checked selinux context for /mnt/389ds/log drwx------. nobody nobody unconfined_u:object_r:dirsrv_var_log_t:s0 admin-serv drwxr-xr-x. nobody nobody unconfined_u:object_r:dirsrv_var_log_t:s0 slapd-eu-vc-pmldap01 8. Renamed /var/log/dirsrv t 9. Create symbolic link in /var/log ln -s /mtn/389ds/log/ dirsrv 10. Reboot server 11 $ sudo service dirsrv start Error: etc/dirsrv/slapd-xxxxxxxxx/dse.ldif: nsslapd-errorlog: Cannot open errorlog file "/var/log/dirsrv/slapd-xxxxxxxxxx/errors", errors cannot be logged. Exiting.... [15/Nov/2015:15:00:12 +0000] - WARNING: can't open file /var/log/dirsrv/slapd-xxxxxxxx/access. errno 13 (Permission denied)[15/Nov/2015:15:00:12 +0000] dse_read_one_file - The entry cn=config in file /etc/dirsrv/slapd-xxxxx/dse.ldif (lineno: 10) is invalid, error code 53 (Server is unwilling to perform) - Cannot open accesslog directory "/var/log/dirsrv/slapd-xxxxxxx/access", client accesses will not be logged.[15/Nov/2015:15:00:12 +0000] dse - Could not load config file [dse.ldif][15/Nov/2015:15:00:12 +0000] dse - Please edit the file to correct the reported problems and then restart the server. Kind regards

2 2

Re: [389-users] Moving Directories dirsrv and log to a new Disk
by Andy Spooner 16 Nov '15

16 Nov '15

Hi I resolved the problem. The symbolic links needed to a level deeper. E.g. ln -s /mnt/389ds/data/dirsrv dirsrv, instead of ln -s /mnt/389ds/data/ dirsrv. On Nov 15, 2015 15:14, "Andy Spooner" <racingyacht1(a)gmail.com> wrote: > Hi, > I am running 389-ds on CentOs 6.7. I am trying to move 389-ds off the disk > that contains my root to a second disk that has space for the directory to > grow. Can someone please advise on the correct way to move files and > maintain selinux contexts. I moved the files using the method below, but > logs cannot be written to - please see error message at the bottom of this > email. > > Setup > CentOs 6.7 > selinux= enforcing > Second disk /mnt/ds389/data/ > /mnt/389ds/log/ > > i used cp -rcp to copy and preserve SELINUX contexts and user rights > > 1. Stop dirsrv > 2. cp -rcp /var/lib/dirsrv/ /mnt/ds389/data/ > 3. Checked selinux context using ls -Z dirsrv > output: drwxrwx---. nobody nobody > unconfined_u:object_r:dirsrv_var_lib_t:s0 slapd-eu-vc-pmldap01 > 4. renamed /var/lib/dirsrv (keep original files under a different name) > 5. Create symbolic link # ln -s /mnt/389ds/data/ dirsrv > > Logs > 6. cp -rcp /var/log/dirsrv /mnt/389ds/log/ > 7. Checked selinux context for /mnt/389ds/log > drwx------. nobody nobody > unconfined_u:object_r:dirsrv_var_log_t:s0 admin-serv > drwxr-xr-x. nobody nobody unconfined_u:object_r:dirsrv_var_log_t:s0 > slapd-eu-vc-pmldap01 > > > 8. Renamed /var/log/dirsrv t > 9. Create symbolic link in /var/log ln -s /mtn/389ds/log/ dirsrv > > 10. Reboot server > 11 $ sudo service dirsrv start > > Error: > etc/dirsrv/slapd-xxxxxxxxx/dse.ldif: nsslapd-errorlog: Cannot open > errorlog file "/var/log/dirsrv/slapd-xxxxxxxxxx/errors", errors cannot be > logged. Exiting.... [15/Nov/2015:15:00:12 +0000] - WARNING: can't open file > /var/log/dirsrv/slapd-xxxxxxxx/access. errno 13 (Permission > denied)[15/Nov/2015:15:00:12 +0000] dse_read_one_file - The entry cn=config > in file /etc/dirsrv/slapd-xxxxx/dse.ldif (lineno: 10) is invalid, error > code 53 (Server is unwilling to perform) - Cannot open accesslog directory > "/var/log/dirsrv/slapd-xxxxxxx/access", client accesses will not be > logged.[15/Nov/2015:15:00:12 +0000] dse - Could not load config file > [dse.ldif][15/Nov/2015:15:00:12 +0000] dse - Please edit the file to > correct the reported problems and then restart the server. > > > > > > > > > > Kind regards >

1 0

making a dedicated consumer a supplier
by ghiureai 12 Nov '15

12 Nov '15

Hi List , I'm looking for cmd line steps to make a dedicated consumer in a supplier in single master replication ( if original master goes offline), I have the steps from Admin GUI , I would like to hase same steps but using cmd's line : - add the new changelog entry at to be supplier host , next how can I disable dedicated consumer and re-enable as single master/supplier ( would changing nsds5replicatype: to 3 be sufficient ? ) , -reboot DS - no agreements needs to be created. Are this steps sufficient?

2 3

sudoRole and ldapsearch
by Darran Carey 12 Nov '15

12 Nov '15

I have sudo integration with 389 working well with one final issue to resolve before moving it onto our production servers. All users are currently able to see all sudoRole objects with ldapsearch. Is it possible to keep sudo working while disabling search access to sudoRoles? Regards, Darran.

1 0

Re: [389-users] multimaster replication and index corruption
by Rich Megginson 10 Nov '15

10 Nov '15

On 11/10/2015 12:12 PM, ghiureai wrote: > > Rich, thank you for all support for last day , unfortunately there is > a strong wave in developers team:" the multimaster replication is > creating issues with UI" ( I do not totally agree since can not be > reproduce+ full describe the issues). > Is been decided to moved down to master slave, please I need to know > if I still need to exclude member of plugin from replication in this > case ? > Adding 389-users to discussion. I would say yes, you should still exclude memberOf from replication. In any case, it is better to reduce the amount of replication traffic and replication processing, and let the slave calculate the memberOf values. As far as the original issue - if we can't get enough information to diagnose/reproduce the problem, then we can be of little help. > > > Thanks a lot > Isabella > On 11/10/2015 09:23 AM, Rich Megginson wrote: >> On 11/10/2015 10:14 AM, Adrian Damian wrote: >>> Rich, >>> >>> Thanks for your help. Let me jump in with more details. >>> >>> We've seen index corruption on a number of occasions. It seems to >>> affect searchable attributes for which there are indexes. Queries on >>> an attribute in LDAP that used to work suddenly stopped working. They >>> would return incomplete results and no results at all, although the >>> data on the server was the same. The fix on those situations was to >>> drop the index corresponding to the attribute and re-create it. >> So in this case, you have some sort of LDAP search client, and you are >> doing a search for '(indexed_attribute=known_value)' and you are not >> seeing a result, and this is what you mean by "index corruption"? >> >> Are you aware of the dbscan tool? >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/h… >> >> >> This tool allows you to examine the index file in the database directly. >> >> dbscan -f >> /var/lib/dirsrv/slapd-instance_name/db/userRoot/indexed_attribute.db4 -k >> known_value >> >> This will allow you to look at the indexed_attribute index directly for >> the value "known_value". >> >>> We've run the db fix script that the LDAP distribution comes with >> What db fix script? Do you have a link to it, or a link to the product >> documentation for the script? >> >>> and there are no reports of corruption when this problem occurs. That >>> makes it very hard to detect. We don't know what else to look for when >>> we run into this again and more importantly, we don't know what >>> triggers it and how to prevent it. >>> >>> Mind you we are currently doing active development changing both the >>> software clients that access the LDAP servers as well as the >>> configurations of the servers. It is possible to had been written to >>> both masters in the master replication configuration when the problem >>> occurred but because there were multiple clients concurrently >>> accessing the servers it is hard to figure out what triggered the >>> issue. >>> >>> >>> Adrian >>> >>> >>> >>> On 11/09/2015 05:06 PM, Rich Megginson wrote: >>>> On 11/09/2015 05:47 PM, Ghiurea, Isabella wrote: >>>>> Hi Rich, >>>>> Thank you for your feedback , as always greatly appreciate when >>>>> comes from 389-DS RH support. >>>>> We are not using vm just plain hardware, here is the description >>>>> I got from developers team related to the issues they are seeing >>>>> when running integration tests with multimaster replication : >>>>> "index corruption: put content, run tests: OK, do more stuff (reads, >>>>> writes, etc), ru tests: FAIL, notice "missing attributes", rebuild >>>>> index(ices), run tests: OK. " >>>> What does this mean? What program is printing these index corruption >>>> messages? Is it some tool provided by Red Hat? >>>> >>>>> Unfortunately, I understood this cases/issue can not be reproduce >>>>> on regular basis, no mode details can be provide at this time >>>>> >>>>> All reads and writes are going to only the master replication DS, >>>>> not slave . >>>>> I totally agree with your this is the way to cfg and maintain >>>>> Directory Server in a operation critical env: multmaster >>>>> replication only one master for writes. >>>>> Here is the DS version: >>>>> rpm -qa | grep 389-ds >>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-1.2.2-1.el6.noarch >>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>> This is quite an old version of 389-ds-base. I suggest upgrading to >>>> RHEL 6.7 with latest patches. >>>> >>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>> >>>>> >>>>> Thank you >>>>> Isabella >>>>> >>>>> FWD: >>>>> >>>>> >>>>> We have cfg multimaster replication /fractional replication memberof >>>>> plugging excluded , we are seeing from time to time index corruption >>>>> with some indexes , there is a strong feeling from developers this >>>>> are related to DS multimaster replication internal settings. >>>>> What version of 389? rpm -q 389-ds-base >>>>> I'm assuming you are not using IPA. >>>>> What does "index corruption" mean? What exactly do you see? >>>>> >>>>> Are you running in virtual machines? If so, what kind? vmware? kvm? >>>>> Are you using virtual disks or dedicated physical devices/paravirt? >>>>> >>>>> We are writing to only one DS , same server at all time but reading >>>>> from all DS 's cfg for mutlmaster. >>>>> Are you seeing "index corruption" on the write master or on all >>>>> servers? >>>>> >>>>> >>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>> should we start avoiding this replication cfg at all ? >>>>> >>>>> This is the recommended way to deploy. If this is not working for >>>>> you, either you have a configuration problem, or there is some sort >>>>> of vm or hardware problem, or there is a serious bug that requires >>>>> fixing ASAP. >>>>> >>>>> We choose the multimaster for the fast and reliable option to switch >>>>> between master DS's , moving one step down to master/slave may >>>>> require some down time when switching DS's back. >>>>> Isabella >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Rich, >>>>> Thank you for your feedback , as always greatly appreciate when >>>>> comes from 389-DS RH support. >>>>> We are not using vm just plain hardware, here is the description >>>>> I got from developers team related to the issues they are seeing >>>>> when running tests with multimaster replication :index corruption: >>>>> put content, run tests: OK, do more stuff (reads, writes, etc), ru >>>>> tests: FAIL, notice "missing attributes", rebuild index(ices), run >>>>> tests: OK. >>>>> >>>>> I belive we the reads and writes right now are only the master >>>>> replication DS , not slave . >>>>> I totally agree with your this is the way to cfg and maint DS in a >>>>> operation env: multmaster replication with one master for writes. >>>>> More comments , imput I appreciate >>>>> rpm -qa | grep 389-ds >>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-1.2.2-1.el6.noarch >>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>> 389-dsgw-1.1.11-1.el6.x86_64 >>>>> >>>>> ________________________________________ >>>>> From: ghiureai [isabella.ghiurea(a)nrc-cnrc.gc.ca] >>>>> Sent: Monday, November 09, 2015 1:05 PM >>>>> To: 389-users(a)lists.fedoraproject.org >>>>> Subject: multimaster replication and index corruption >>>>> >>>>> Hi List, >>>>> We have cfg multimaster replication /fractional replication >>>>> memberof >>>>> plugging excluded , we are seeing from time to time index >>>>> corruption >>>>> with some indexes , there is a strong feeling from developers >>>>> this are >>>>> related to DS multimaster replication internal settings. >>>>> We are writing to only one DS , same server at all time but reading >>>>> from all DS 's cfg for mutlmaster. >>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>> should we start avoiding this replication cfg at all ? >>>>> We choose the multimaster for the fast and reliable option to switch >>>>> between master DS's , moving one step down to master/slave may >>>>> require >>>>> some down time when switching DS's back. >>>>> Isabella >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >

1 0

multimaster replication and index corruption
by ghiureai 10 Nov '15

10 Nov '15

Hi List, We have cfg multimaster replication /fractional replication memberof plugging excluded , we are seeing from time to time index corruption with some indexes , there is a strong feeling from developers this are related to DS multimaster replication internal settings. We are writing to only one DS , same server at all time but reading from all DS 's cfg for mutlmaster. Are other people seen this kind of issues with multimaster rep cfg , should we start avoiding this replication cfg at all ? We choose the multimaster for the fast and reliable option to switch between master DS's , moving one step down to master/slave may require some down time when switching DS's back. Isabella

4 5

DB account master integrated with LDAP
by Andy Spooner 04 Nov '15

04 Nov '15

I am using ldap to share user account information across two applications. Is it possible to using 'Application 1' as the central reference instead of the LDAP server? E.g. Application 1' holds and maintains account information, which updates ldap periodically. 'Application 2' will look up LDAP for account informations. 'Application 1' is the main system and will hold millions of accounts which would operate quicker from the DB without having to refer to LDAP for usernames, passwords, etc. 'Application2' will require a small subset of users to logon using credentials of users in the master database - which can be done via LDAP.

3 2

389DS userPassword and Freeradius
by ozikat 04 Nov '15

04 Nov '15

Hi All, Recently we would like to extend 389DS user into Radius for account authorization and authentication (WiFi with WPA-Enterprise, Portal and etc) It seems like Freeradius only work with ClearText Password, i.e it cannot read password attribute userPassword with SHA-HASHed. Anyone has workaround and idea on this? We have freeradius setup, and it seems it doesnt work with MSCHAPv2 ;( -- Ozikat.

2 4

Re: [389-users] DB account master integrated with LDAP
by Andy Spooner 04 Nov '15

04 Nov '15

Thank you for the feedback. I will take a step back to review how we can engineer our setup to be efficient and manageable. From: <389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org>> on behalf of "Mayberry, Alexander" <AMayberry(a)west.com<mailto:AMayberry@west.com>> Reply-To: "389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>" <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>> Date: Tuesday, 3 November 2015 19:17 To: "389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>" <389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>> Subject: Re: [389-users] DB account master integrated with LDAP LDAP is a protocol. Your directory is a database. In your scenario, if "application 1" is used in this manner, it would become an identity management platform. As long as this application has the ability to update your directory, you can do what you are suggesting. I would caution you, though, with so many accounts, and no idea what your security considerations are, you may wish to take a long think on this one. That's a lot of potentially sensitive information. Combining an application with your identity management platform on the same system will increase your risks. From a complexity standpoint, if your application has the ability to act as an identity management platform, it may also have the ability to update your "application 2" system directly, and eliminate the middle-man. Or possibly "application 2" could be configured to auth directly to "application 1". Depending on what type of user management features are available in "application 1". Alexander Mayberry Enterprise Systems Engineer SD Group: EIT Infrastructure - OMA Enterprise.Systems Engineering.Infrastructure From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Andy Spooner Sent: Tuesday, November 03, 2015 12:33 PM To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> Subject: [389-users] DB account master integrated with LDAP I am using ldap to share user account information across two applications. Is it possible to using 'Application 1' as the central reference instead of the LDAP server? E.g. Application 1' holds and maintains account information, which updates ldap periodically. 'Application 2' will look up LDAP for account informations. 'Application 1' is the main system and will hold millions of accounts which would operate quicker from the DB without having to refer to LDAP for usernames, passwords, etc. 'Application2' will require a small subset of users to logon using credentials of users in the master database - which can be done via LDAP.

1 0

Re: [389-users] 389-users Digest, Vol 126, Issue 2, in reply to: "passwordless sudo"
by Karel Lang AFD 03 Nov '15

03 Nov '15

Hi, as for the sudo <-> ldap or for sudo <-> sssd <-> ldap i think this is good read: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht… cheers! -- *Karel Lang* *Unix/Linux Administration* lang(a)afd.cz | +420 731 13 40 40 AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz On 11/03/2015 01:00 PM, 389-users-request(a)lists.fedoraproject.org wrote: > Send 389-users mailing list submissions to > 389-users(a)lists.fedoraproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://admin.fedoraproject.org/mailman/listinfo/389-users > or, via email, send a message with subject or body 'help' to > 389-users-request(a)lists.fedoraproject.org > > You can reach the person managing the list at > 389-users-owner(a)lists.fedoraproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 389-users digest..." > > > Today's Topics: > > 1. Re: DS crashed /killed by OS (Mark Reynolds) > 2. Re: Passwordless sudo - is it possible? (Todor Petkov) > 3. Re: Passwordless sudo - is it possible? (Alan Willis) > 4. Re: Passwordless sudo - is it possible? (Gordon Messmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Nov 2015 09:52:27 -0500 > From: Mark Reynolds <mareynol(a)redhat.com> > To: firstyear(a)redhat.com, "General discussion list for the 389 > Directory server project." <389-users(a)lists.fedoraproject.org> > Subject: Re: [389-users] DS crashed /killed by OS > Message-ID: <563778AB.6020603(a)redhat.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > On 11/01/2015 08:50 PM, William Brown wrote: >> On Thu, 2015-10-22 at 17:48 +0000, Fong, Trevor wrote: >>> Hi German, >>> >>> Thanks for your suggestion. I’m happy to confirm that setting >>> userRoot’s nsslapd-cachememsize: 429496730 (1/15th of previous value >>> of 6 GB) has addressed the memory issue for now, and % Mem for the ns >>> -slapd process seems to be at a manageable level. >>> >>> Thanks very much, >>> Trev >>> >>> >>> >> As I understand it, the fragmentation is due to the use of fastbins. >> see man mallopt M_MXFAST for an explination. >> >> You may be able to reduce fragmentation with the setting nsslapd-malloc >> -mxfast, but you may see a (potentially severe) degredation in >> performance. As I understand the value is by default 64 on a 32 bit >> system, and 128 on a 64bit one, so perhaps try reducing it by half and >> see if that helps. >> >> I'm not sure if this is a supported option either so you may not wish >> to enable it. You should always try changes like this on a non >> -production system first. > Well we have not seen any significant improvement modifying the fast > bins(M_MXFAST). So while it can slightly reduce fragmentation, > unfortunately it's not really a solution. Now using a different memory > allocator, like jemalloc, has shown significant improvements in memory > size/fragmentation. Checkout: > > http://www.port389.org/docs/389ds/FAQ/jemalloc-testing.html > > The only issue is that jemalloc is not available on all platforms > yet(especially older versions of RHEL/fedora). > > Mark >> >> Alternatelly, you can set the cachemem to autosize with nsslapd-cache >> -autosize=50 or something like that. This way the cache will use only >> 50% of the free ram on the system. I believe this value is determined >> at server start up, rather than being constantly adjusted through the >> lifetime of the process. >> >> Remember, that with the caching, there is some good material in the >> tuning guide which may help you understand the correct values you >> should set for your cache sizes based on the number of entries you >> have. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/ >> 10/html/Performance_Tuning_Guide/index.html >> >> As Germane said, there is work to reduce the impace of memory >> fragmentation on process memory size, so these are hopefully temporary >> solutions. >> >>> - >> Sincerely, >> >> William Brown >> Software Engineer >> Red Hat, Brisbane >> >> >> >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2015