[Freeipa-users] Repair a corrupted database
Hi List, I've got two boxes running FreeIPA 4.1.4. The Database on the first master is corrupted. Log looks like this: [17/Apr/2017:10:22:51 -0400] - libdb: BDB0689 changelog/id2entry.db page 27523 is on free list with type 5 [17/Apr/2017:10:22:51 -0400] - libdb: BDB0061 PANIC: Invalid argument [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_abort, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] DSRetroclPlugin - replog: an error occured while adding change number 8485210, dn = changenumber=8485210,cn=changelog: Operations error. [17/Apr/2017:10:22:51 -0400] retrocl-plugin - retrocl_postob: operation failure [1] [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - Serious Error---Failed in dblayer_txn_begin, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [17/Apr/2017:10:22:51 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [17/Apr/2017:10:22:51 -0400] - FATAL ERROR at idl_new.c (1); server stopping as database recovery needed. Looks like it's broken. Good news is I have a replica that's working quite well. What I'd like to do is to recover the database or create a new database on the first master and then just fill it with the current data from the replica. Is this possible? As a lazy admin I'm hoping to avoid making the replica the CA and building a new replica. Can someone point me to a guide, docs or walk me through the procedure? Thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Ipa add-user non interactively specifying a password.
Thanks Craig!
That's quite a handy reply. It's actually a lot nicer than what I was
planning to do. I appreciate this a lot.
-Chris
On 09/01/2015 03:33 PM, Craig White wrote:
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Chris Mohler
Sent: Tuesday, September 01, 2015 12:17 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Ipa add-user non interactively specifying a password.
Hi List,
I'm trying to make a script to add users non interactively with ipa add-user
and specify a password of testpw
I tried:
ipa user-add username --first=firstname --last=lastname
--homedir=/home/username --password testpw --gidnumber= --noprivate
--shell=/bin/bash
#ipa: ERROR: command 'user_add' takes at most 1 argument
and this:
ipa user-add username --first=firstname --last=lastname
--homedir=/home/username --password=testpw --gidnumber= --noprivate
--shell=/bin/bash
#ipa: error: --password option does not take a value
No Luck.
Any suggestions?
-
I will take it a lot further - salt to taste (and watch the line wraps)...
#!/bin/sh
#
# Script to automate adding users
#
# Updated 12/16/2014
# Craig White
#
CMD1='/usr/bin/ipa user-add'
CMD2='/usr/bin/ipa group-add-member'
TEE='/usr/bin/tee -a'
LOG='/tmp/ipa_users_add.txt'
MAIL='/bin/mailx'
KERB=`klist -s; echo $?`
$LOG
[[ -n "$4" ]] || { echo "Usage: ipa_user_add.sh LOGIN FIRST_NAME LAST_NAME EMAIL GROUPS " && echo "
REQUIRED > ^ ^ ^ ^" && echo "You can have many groups separated with just a space";
exit 0 ; }
[[ $KERB == "0" ]] || { echo "Your kerberos ticket has expired - Please create a
valid kerberos ticket by typing 'kinit'"; exit 0 ; }
if [ -z "$EMAIL" ]; then
echo "You need to add EMAIL to your environment variables - type 'export
EMAIL=YOUR_EMAIL_ADDRESS' before running this command or better yet, add it to your
.bash_profile"
exit 0
fi
$CMD1 $1 --first=$2 --last=$3 --random --email=$4 | $TEE $LOG
echo " - - - -" | $TEE $LOG
echo "You must login and change your password" | $TEE $LOG
echo "SSH to some server you have access to" | $TEE $LOG
echo "or" | $TEE $LOG
echo "https://_IPA_SERVER_1_/ipa/ui OR https://_IPA_SERVER_2_/ipa/ui; | $TEE
$LOG
echo " - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - -" | $TEE $LOG
$CMD2 ipausers --users=$1 | $TEE $LOG
if [ -n "$5" ]; then
$CMD2 $5 --users=$1 | $TEE $LOG
fi
if [ -n "$6" ]; then
$CMD2 $6 --users=$1 | $TEE $LOG
fi
if [ -n "$7" ]; then
$CMD2 $7 --users=$1 | $TEE $LOG
fi
if [ -n "$8" ]; then
$CMD2 $8 --users=$1 | $TEE $LOG
fi
if [ -n "$9" ]; then
$CMD2 $9 --users=$1 | $TEE $LOG
fi
echo "See attachment for login information" | $MAIL -s 'New Account
Information' -r $EMAIL -a $LOG $4
/bin/rm -f $LOG
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Ipa add-user non interactively specifying a password.
Hi List, I'm trying to make a script to add users non interactively with ipa add-user and specify a password of testpw I tried: ipa user-add username --first=firstname --last=lastname --homedir=/home/username --password testpw --gidnumber= --noprivate --shell=/bin/bash #ipa: ERROR: command 'user_add' takes at most 1 argument and this: ipa user-add username --first=firstname --last=lastname --homedir=/home/username --password=testpw --gidnumber= --noprivate --shell=/bin/bash #ipa: error: --password option does not take a value No Luck. Any suggestions? Thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Ipa add-user non interactively specifying a password.
Thanks Alexander, I tried the help but there were only two choices. Specify a password interactively --password, or randomly generate one with --random. I agree with you the errors in the output are expected I was just hoping for some undocumented magic. Piping the output from cat into the password prompt is a great idea and does fix the issue I was having. It's not really intuitive but still makes me wonder why I didn't think of that. Anyhow I changed it up a bit with echo testpw | ipa user-add username --first=firstname --last=lastname --password --gidnumber= --noprivate --shell=/bin/bash And it totally works. Thank you again. -Chris On 09/01/2015 03:39 PM, Alexander Bokovoy wrote: On Tue, 01 Sep 2015, Chris Mohler wrote: Hi List, I'm trying to make a script to add users non interactively with ipa add-user and specify a password of testpw I tried: ipa user-add username --first=firstname --last=lastname --homedir=/home/username --password testpw --gidnumber= --noprivate --shell=/bin/bash #ipa: ERROR: command 'user_add' takes at most 1 argument and this: ipa user-add username --first=firstname --last=lastname --homedir=/home/username --password=testpw --gidnumber= --noprivate --shell=/bin/bash #ipa: error: --password option does not take a value No Luck. Any suggestions? Read the help :) $ ipa help user-add|grep -- --password --passwordPrompt to set the user password E.g. --password option does not take *any* parameter, it *prompts* to enter the password and expects standard input to provide the password. In the first example you added a parameter after --password and since --password does not consume anything, it was considered as another argument but 'ipa user-add' indeed takes a single argument, thus an error. In the second example you are explicitly forcing --password to take some parameter and is told that it does not accept anything, just like help is saying. What you want can be achieved like this: $ cat /my/password/file | ipa user-add username --first=firstname --last=lastname --password -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Users can't login on some systems.
Thanks for the reply, I did not clear out /var/lib/sss/db before re-installation. I'll give it a try. I'll stop the service clear the db then restart and see if that helps. If not I'll uninstall the client remove the db and then reinstall the client. Unless it's too late and anyone has a better idea. -Chris On 8/20/2015 7:19 PM, Prasun Gera wrote: Did you clear out /var/lib/sss/db between re-installation of the client? There was a bug which might not have been fixed downstream yet. On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu http://cs.oberlin.edu --realm=CS.OBERLIN.EDU http://CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] _sssd.conf on the broken machine_ [domain/cs.oberlin.edu http://cs.oberlin.edu] debug_level=8
Re: [Freeipa-users] Users can't login on some systems.
Wow That totally fixed it! Thanks again. I simply stopped the sssd service removed the db and then started the sssd service again. My first attempt to login took a few seconds and was successful. I did not have to reinstall the client or even reboot the system. FWIW I put the commands in a script sssflush.sh /sbin/initctl stop sssd rm /var/lib/sss/db/* /sbin/initctl start sssd I've needed to do this a few times before. A note to fellow Ubuntu users service sssd stop doesn't work when you put it in a script. Use /sbin/initctl instead. -Chris On 8/20/2015 7:19 PM, Prasun Gera wrote: Did you clear out /var/lib/sss/db between re-installation of the client? There was a bug which might not have been fixed downstream yet. On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu http://cs.oberlin.edu --realm=CS.OBERLIN.EDU http://CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133
[Freeipa-users] Users can't login on some systems.
Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu --realm=CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] _sssd.conf on the broken machine_ [domain/cs.oberlin.edu] debug_level=8 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cs.oberlin.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = occs.cs.oberlin.edu chpass_provider = ipa ipa_server = _srv_, ipa1.cs.oberlin.edu ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 debug_level=8 domains = cs.oberlin.edu [nss] debug_level=8 [pam] debug_level=8 [sudo] [autofs] [ssh] debug_level=8 [pac] _The broken systems sssd_nss.log _[nss_cmd_getpwnam_search] (0x0400): Returning info for user [hid...@cs.oberlin.edu] [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [HIDDEN]. [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'HIDDEN' matched without domain, user is HIDDEN [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [HIDDEN] from [ALL] [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/cs.oberlin.edu/HIDDEN] [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [hid...@cs.oberlin.edu] [sssd[nss]] [check_cache] (0x0400): Cached
Re: [Freeipa-users] No LDAPS for dirsrv
On 02/17/2015 11:26 AM, Thomas Raehalme wrote: Hi! As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Looking at the logs before this whole ordeal started port 636 was also in use. After the latest upgrade I have re-enabled port 389 manually because it's used by some apps, but disabling it also doesn't bring back port 636. Best regards, Thomas Hi Thomas, I'm not an expert but just throwing out a few ideas for you. As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. It might help to know what OS/version you are using? and what version of FreeIPA you are using. Cheers, and Good luck, -Chris -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] No LDAPS for dirsrv
I would agree with Rob, entropy is likely not one of your root issues. It may still do you good to have a bit more as it can cause system slowdown during SSL generation loads. It's really up to you how you go about generating entropy. Here is a link with some suggestions http://log.amitshah.net/2013/01/about-random-numbers-and-virtual-machines/ I would suggest you just yum install haveged It's worked good for me so far. Good luck, -Chris On 02/17/2015 12:38 PM, Rob Crittenden wrote: Thomas Raehalme wrote: Hi Chris! On Tue, Feb 17, 2015 at 6:35 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: As I wrote earlier we are having some serious problems with IPA right now. dirsrv seems to hang every 15 minutes or so, but that's another post. Are you running in a VM? If so check your entropy. cat /proc/sys/kernel/random/entropy_avail It should be ~1k less than 50 is not great and caused me some issues in the past. Yes, the server is a VM. Entropy value is 135 at the moment. Do you know how to increase the value? I don't think that's an issue. It is more a problem during initial installation than during operation AFAIK. It seems that slapd/dirsrv is now only listening on port 389 for LDAP and socket for LDAPI requests. Any idea what could have caused previously available LDAPS port 636 to disappear? Did your certificates expire? I usually check the web interface and look at the SSL Cert in the browser to see when it expires. I bet there is a better way to check but I don't know it off hand. No, at least for the web interface certificates expire in August. It turned out the nsslapd-security was 'off' when it should have been 'on'. I really don't know what had changed the value. Now I only wish we could resolve what's causing the dirsrv process to hang (wrote about that in another message last Sunday) about 10 minutes after IPA services were started. Evidence suggests that the last upgrade failed so I'd start there. It is possible some plugins aren't configured properly, for example. You can try to re-run the upgrade manually. Note that the updater will disable all listeners while it is running. This is where things went sideways before. # /usr/sbin/ipa-ldap-updater --upgrade If that succeeds: # /usr/sbin/ipa-upgradeconfig Then # ipactl restart rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 11:36 AM, Martin Kosek wrote: On 02/09/2015 05:16 PM, Chris Mohler wrote: On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. It should just work. Just note that in case of Fedora Server, these are upstream/Fedora bits which are only tested upstream. So if you for example break something in Fedora 21 (not likely to happen though ;-) and then get the change *replicated* to RHEL production instance, I do not think Red Hat support would be happy with that. Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in your production RHEL instance is it would upgrade all the data for 4.2 level - which should get more downstream testing before Red Hat can rubber stamp it. TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), knock yourself out :-) Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. IMO, they this should not be related (should not break replication). I do not see anything useful in the error log though. Did you also check /var/log/messages for the errors log
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb because
I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server lately.
I'm not surprised that error is not related. I was not sure as It has
not surfaced in my logs before I changed the entry cache size. Possibly
this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a migration.
I also recently tried to add a replica. Which prompted me to update the
schema on the master before it would replicate.
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes:
( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
Thanks again,
-Chris
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. |[06/Feb/2015:10:07:35 -0500] - slapd stopped. [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15/ B2014.314.1342 starting up [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests| | Thanks again for having a look at my problem, -Chris | -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 11:19 AM, Rich Megginson wrote:
On 02/09/2015 08:26 AM, Chris Mohler wrote:
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb
because I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server
lately. I'm not surprised that error is not related. I was not sure
as It has not surfaced in my logs before I changed the entry cache
size. Possibly this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a
migration. I also recently tried to add a replica. Which prompted me
to update the schema on the master before it would replicate.
What exactly did you do? You should not have migrated the standard
schema from openldap. Did you have to override the definition of 'dc'
for some reason?
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as
syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do
you have some application that requires 8-bit or unicode characters
(syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If
it is absolutely required that dc accepts unicode, then you'll have to
change the matching rules as well, to be unicode compatible: EQUALITY
caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get
rid of the IA5.
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 11:36 AM, Martin Kosek wrote: On 02/09/2015 05:16 PM, Chris Mohler wrote: On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. It should just work. Just note that in case of Fedora Server, these are upstream/Fedora bits which are only tested upstream. So if you for example break something in Fedora 21 (not likely to happen though ;-) and then get the change *replicated* to RHEL production instance, I do not think Red Hat support would be happy with that. Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in your production RHEL instance is it would upgrade all the data for 4.2 level - which should get more downstream testing before Red Hat can rubber stamp it. TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), knock yourself out :-) Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. IMO, they this should not be related (should not break replication). I do not see anything useful in the error log though. Did you also check /var/log/messages for the errors log
Re: [Freeipa-users] How do I modify the entry cache size?
Thanks for the reply and the link Rich! dbmon.sh is a handy tool indeed. I read the instructions and upped my entry cache size to 2gb because I have enough ram. Everything went well until service dirsrv restart I Got the following errors: [06/Feb/2015:10:07:35 -0500] - slapd stopped. [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests Oddly enough everything appears to be working. Are these messages safe to ignore? Another run of dbmon.sh shows that my entry cache was increased. Thanks, -Chris On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com wrote: On 02/07/2015 11:25 AM, Chris Mohler wrote: Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size I'm trying to follow the directions here /usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389 dn: cn=*database_name*, cn=ldbm database, cn=plugins, cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 20971520 Is this the correct way to do this? How do I find out what the cn=*database_name is supposed to be? * *see *https://github.com/richm/scripts/wiki/dbmon.sh - the script will tell you what the names of your databases are. *Thanks, * *-Chris * -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] How do I modify the entry cache size?
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to increase the entry cache size I'm trying to follow the directions here /usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389 dn: cn=*database_name*, cn=ldbm database, cn=plugins, cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 20971520 Is this the correct way to do this? How do I find out what the cn= *database_name is supposed to be?* *Thanks,* *-Chris* -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
