Moving Direcoties dirsrv andlog to a new Disk
by Andy Spooner
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
8 years, 5 months
Re: [389-users] Moving Directories dirsrv and log to a new Disk
by Andy Spooner
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
>
8 years, 5 months
making a dedicated consumer a supplier
by ghiureai
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?
8 years, 5 months
sudoRole and ldapsearch
by Darran Carey
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.
8 years, 5 months
Re: [389-users] multimaster replication and index corruption
by Rich Megginson
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...
>>
>>
>> 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
>
8 years, 5 months
multimaster replication and index corruption
by ghiureai
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
8 years, 5 months
DB account master integrated with LDAP
by Andy Spooner
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.
8 years, 5 months
389DS userPassword and Freeradius
by ozikat
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.
8 years, 5 months
Re: [389-users] DB account master integrated with LDAP
by Andy Spooner
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.
8 years, 5 months
Re: [389-users] 389-users Digest, Vol 126, Issue 2, in reply to: "passwordless sudo"
by Karel Lang AFD
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/...
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
>
>
8 years, 5 months
