Re: [Freeipa-users] Errors in dirsrv logs
On 04/16/2015 09:52 AM, Alexander Frolushkin wrote: Hello again. Now, in addition to connection - conn= fd=xxx Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. messages, we have on six of our 16 servers NSMMReplicationPlugin - changelog program - agmt=cn=meTonw-rhidm01.unix.ad.com (nw-rhidm01:389): CSN 552de186000b0011 not found, we aren't as up to date, or we purged Maybe it begins to generate this error after one of our masters was re-initialized. Is there any way to fix it without complete replicas reinstallation? Did you reinstall replicas ? It could be that the replicaId=17 does not exist anymore and you may need to do cleanruv. what is the output of ipa-replica-manage list-ruv ? thanks thierry WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] indirect automount offsets
Hello, It indeed works --key=* --info='/ -rw nfs.example.com:/homes/ /subdir -rw nfs2.example.com:/subdir' however the directory is not mounted. I know it works because when running automount in debug mode I see mounted nfs.example.com:/homes/test on /home/test and then it tries to mount the subdir do_mount_autofs_offset: mount offset /home/test/subdir at /home/test however it fails with the error mount_autofs_offset: can't create mount directory: /home/test/subdir, Permission denied failed to mount offset as a test I set an acl on the /exports/homes dir on the fileserver. setfacl -R -m other:rwx /exports/homes setfacl -R -m d:other:rwx /eports/homes and created the mountpoint in the home directory (it failed when it does not exist do to root squash I guess) mkdir /exports/homes/test/subdir and the offset subdir mount is mounted by autofs on the client. any ideas on how to set the privileges in such a way that not everybody requires access to the exports ? Rob Verduijn 2015-04-16 5:36 GMT+02:00 Rob Crittenden rcrit...@redhat.com: Rob Verduijn wrote: Hello, I'm trying to figure out how to use automounts in freeipa with offsets. currently I have this: the default location containing 3 maps auto.direct auto.home auto.master auto.direct is empty auto.home contains: key : * mount information : -rw nfs.example.com:/homes/ auto.master contains key : /- mount-information : auto.direct key: /home mount information : auto.home in autofs file this would be : auto.master : /- /etc/auto.direct /home /etc/auto.home and auto.home would contain: test -rw nfs.example.com:/homes/ now I would like to do the automount indirect offset like this : test / -rw nfs.example.com:/homes/test \ /newfolder nfs2.example.com:/newfolder \ /anotherfolder nfs3.example.com:/anotherfolder \ /anotherfolder/2deep nfs4.example.com:/2deep which would automount the newfolder like this : /home/test/newfolder and anotherfolder like this /home/test/anotherfolder and 2deep like this /home/test/anotherfolder/2deep is this possible in freeipa ? Rob If it's possible with LDAP-stored autofs it should be possible with IPA. I've typically used much simpler configurations with automount. Theoreticaly it should work just the way you'd set it in a file, as you've posted. Did you try it? You'd set --key=test --info='/ -rw ...' 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
[Freeipa-users] Errors in dirsrv logs
Hello again. Now, in addition to connection - conn= fd=xxx Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. messages, we have on six of our 16 servers NSMMReplicationPlugin - changelog program - agmt=cn=meTonw-rhidm01.unix.ad.com (nw-rhidm01:389): CSN 552de186000b0011 not found, we aren't as up to date, or we purged Maybe it begins to generate this error after one of our masters was re-initialized. Is there any way to fix it without complete replicas reinstallation? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] CRON: Authentication service cannot retrieve authentication info
I think the semi-online status cause SSSD confused about what to do and causing it to timeout. So that means no fix for now. On Thu, Apr 16, 2015 at 11:10 AM, Dmitri Pal d...@redhat.com wrote: On 04/15/2015 10:17 PM, Thomas Lau wrote: Hi, I just checked with developer, there is no authentication related code in the program, we could treat it as normal cron job. is that possible to make sssd less contact with FreeIPA? for example, refresh all user info every 5 minutes, else use cache info. OK, thanks for clarification. Then it is SSSD. It would be hard to understand where the problem is. For authentication SSSD does online if it knows that it is online. Packet loss can cause it to loose connection and time out. It might not failing over to offline mode as it is semi online because of the packet loss and retries. The SSSD logs would really be helpful to diagnose the issue. Also https://fedorahosted.org/sssd/ticket/1807 might be what you are looking for. It is being worked on for the next release. On Tue, Apr 14, 2015 at 10:07 PM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 10:41 PM, Thomas Lau wrote: Hi, It's an in-house program which runs on one kerberos user. You need to look what this program is doing. I suspect it is doing some sort of kinit itself and does not rely on the PAM stack, i.e it bypasses SSSD in the given scenario. Can this be the case? On Tue, Apr 14, 2015 at 5:34 AM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 08:23 AM, Thomas Lau wrote: Hi, These problem appear randomly, sometime it still work even under heavy packet loss, some times would be like this. So its hard to catch. On Apr 13, 2015 3:22 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:15:09PM +0800, Thomas Lau wrote: Hi all, We have cronjob which running on a FreeIPA LDAP user; When connection between IPA server and client having heavy packet loss, following error would occur: CRON[20637]: Authentication service cannot retrieve authentication info I have cache credentials and store password if offline enabled on sssd, how these problem would still happening? It might be that the cause of the problem is actually the packet loss or some kind of delay. SSSD might not think that it is offline but cron job itself times out and reports failure. Do you know what operation in the job fails? sssd.conf: cache_credentials = True krb5_store_password_if_offline = True Did the use log in at least once offline? You can verify if the password has been cached using the ldbsearch utility. It would be best to catch the occurence of the problem in logs. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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] CRON: Authentication service cannot retrieve authentication info
On 04/16/2015 06:40 AM, Thomas Lau wrote: I think the semi-online status cause SSSD confused about what to do and causing it to timeout. So that means no fix for now. Not for right now. Please try to capture logs, If you mange to reproduce the issue and provide logs we would be able to see what causes it and address it. On Thu, Apr 16, 2015 at 11:10 AM, Dmitri Pal d...@redhat.com wrote: On 04/15/2015 10:17 PM, Thomas Lau wrote: Hi, I just checked with developer, there is no authentication related code in the program, we could treat it as normal cron job. is that possible to make sssd less contact with FreeIPA? for example, refresh all user info every 5 minutes, else use cache info. OK, thanks for clarification. Then it is SSSD. It would be hard to understand where the problem is. For authentication SSSD does online if it knows that it is online. Packet loss can cause it to loose connection and time out. It might not failing over to offline mode as it is semi online because of the packet loss and retries. The SSSD logs would really be helpful to diagnose the issue. Also https://fedorahosted.org/sssd/ticket/1807 might be what you are looking for. It is being worked on for the next release. On Tue, Apr 14, 2015 at 10:07 PM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 10:41 PM, Thomas Lau wrote: Hi, It's an in-house program which runs on one kerberos user. You need to look what this program is doing. I suspect it is doing some sort of kinit itself and does not rely on the PAM stack, i.e it bypasses SSSD in the given scenario. Can this be the case? On Tue, Apr 14, 2015 at 5:34 AM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 08:23 AM, Thomas Lau wrote: Hi, These problem appear randomly, sometime it still work even under heavy packet loss, some times would be like this. So its hard to catch. On Apr 13, 2015 3:22 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:15:09PM +0800, Thomas Lau wrote: Hi all, We have cronjob which running on a FreeIPA LDAP user; When connection between IPA server and client having heavy packet loss, following error would occur: CRON[20637]: Authentication service cannot retrieve authentication info I have cache credentials and store password if offline enabled on sssd, how these problem would still happening? It might be that the cause of the problem is actually the packet loss or some kind of delay. SSSD might not think that it is offline but cron job itself times out and reports failure. Do you know what operation in the job fails? sssd.conf: cache_credentials = True krb5_store_password_if_offline = True Did the use log in at least once offline? You can verify if the password has been cached using the ldbsearch utility. It would be best to catch the occurence of the problem in logs. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] EXTERNAL: Re: Usernames not being seen on IPA Master
Hey Jakub,
Getent passwd returns all of the IPA users when searching either the username
or UID.
Yes I know that permissions are defined by UID/GID, used a new UID that has
not been previously used for this new account for this test.
Good to know, I disabled the nscd service.
Here is the output of the strace for chown on a directory.
execve(/bin/chown, [chown, wpooh, /home/wpooh], [/* 32 vars */]) = 0
brk(0) = 0x1095000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b698000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360\355\341\0044\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1918016, ...}) = 0
mmap(0x3404e0, 3741864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x3404e0
mprotect(0x3404f89000, 2093056, PROT_NONE) = 0
mmap(0x3405188000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x188000) = 0x3405188000
mmap(0x340518d000, 18600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x340518d000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b674000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b673000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b672000
arch_prctl(ARCH_SET_FS, 0x7f5f4b673700) = 0
mprotect(0x3405188000, 16384, PROT_READ) = 0
mprotect(0x340481f000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
brk(0) = 0x1095000
brk(0x10b6000) = 0x10b6000
open(/usr/lib/locale/locale-archive, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0
mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f457e1000
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
open(/etc/nsswitch.conf, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1734, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, #\n# /etc/nsswitch.conf\n#\n# An ex..., 4096) = 1734
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libnss_files.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360!\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=65928, ...}) = 0
mmap(NULL, 2151824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f5f455d3000
mprotect(0x7f5f455df000, 2097152, PROT_NONE) = 0
mmap(0x7f5f457df000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f5f457df000
close(3)= 0
mprotect(0x7f5f457df000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fstat(3, {st_mode=S_IFREG|0644, st_size=3404, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, root:x:0:0:root:/root:/bin/bash\n..., 4096) = 3404
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libnss_ldap.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\25\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=44328, ...}) = 0
mmap(NULL, 2139496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f5f453c8000
mprotect(0x7f5f453d3000, 2093056, PROT_NONE) = 0
mmap(0x7f5f455d2000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f5f455d2000
close(3)= 0
munmap(0x7f5f4b675000, 142486)
[Freeipa-users] Usernames not being seen on IPA Master
Hello, I'm running into an issue where a new user account created on the master server is not being seen for changing file permissions and such. I can login using the newly created user account but when I try to change permissions on a file/directory it comes up with the following error; Chown: changing ownership of 'username' : Invalid argument Now if I go to my replica IPA server it works fine. I deleted the user and created it again with the same username, gave the account a different UID and when I tried to permission the directory again it states the same error as above. I changed the permissions on the replica server and went back to the master and looked at the permissions of the directory and it's showing the old UID. I can login as the new user and the permissions are fine, the user can create and modify files in that directory. When I run ipa user-find -all -raw username it brings up all of the correct information that I entered for the account. I searched for the old UID that was used with this account before but it doesn't seem to exist in IPA. I've tried restarting the IPA service and remounting the directory that contains the required folders but with no luck. I cleared the SSSD and the NSCD cache. Does IPA have another cache that needs to be cleared or anything like that? Thanks, Matt -- 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] CRON: Authentication service cannot retrieve authentication info
On Thu, Apr 16, 2015 at 09:01:23AM -0400, Dmitri Pal wrote: On 04/16/2015 06:40 AM, Thomas Lau wrote: I think the semi-online status cause SSSD confused about what to do and causing it to timeout. So that means no fix for now. Not for right now. Please try to capture logs, If you mange to reproduce the issue and provide logs we would be able to see what causes it and address it. Right. What we're looking for is a reason why SSSD went offline in the first place. I know SSSD logging can produce a big amount of data. But you can try to not increase the log level beyond what amount of data is OK for you and configure logrotate to gzip the logs more often. -- 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] EXTERNAL: Re: Usernames not being seen on IPA Master
On Thu, Apr 16, 2015 at 01:42:52PM +, Joseph, Matthew (EXP) wrote:
Hey Jakub,
Getent passwd returns all of the IPA users when searching either the username
or UID.
Yes I know that permissions are defined by UID/GID, used a new UID that has
not been previously used for this new account for this test.
Good to know, I disabled the nscd service.
Here is the output of the strace for chown on a directory.
execve(/bin/chown, [chown, wpooh, /home/wpooh], [/* 32 vars */]) = 0
brk(0) = 0x1095000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b698000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360\355\341\0044\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1918016, ...}) = 0
mmap(0x3404e0, 3741864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x3404e0
mprotect(0x3404f89000, 2093056, PROT_NONE) = 0
mmap(0x3405188000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x188000) = 0x3405188000
mmap(0x340518d000, 18600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x340518d000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b674000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b673000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b672000
arch_prctl(ARCH_SET_FS, 0x7f5f4b673700) = 0
mprotect(0x3405188000, 16384, PROT_READ) = 0
mprotect(0x340481f000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
brk(0) = 0x1095000
brk(0x10b6000) = 0x10b6000
open(/usr/lib/locale/locale-archive, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0
mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f457e1000
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
open(/etc/nsswitch.conf, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1734, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, #\n# /etc/nsswitch.conf\n#\n# An ex..., 4096) = 1734
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libnss_files.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360!\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=65928, ...}) = 0
mmap(NULL, 2151824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f5f455d3000
mprotect(0x7f5f455df000, 2097152, PROT_NONE) = 0
mmap(0x7f5f457df000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f5f457df000
close(3)= 0
mprotect(0x7f5f457df000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fstat(3, {st_mode=S_IFREG|0644, st_size=3404, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, root:x:0:0:root:/root:/bin/bash\n..., 4096) = 3404
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libnss_ldap.so.2, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\\25\0\0\0\0\0\0..., 832) =
832
fstat(3, {st_mode=S_IFREG|0755, st_size=44328, ...}) = 0
mmap(NULL, 2139496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f5f453c8000
mprotect(0x7f5f453d3000, 2093056, PROT_NONE) = 0
Re: [Freeipa-users] Usernames not being seen on IPA Master
On Thu, Apr 16, 2015 at 01:13:56PM +, Joseph, Matthew (EXP) wrote: Hello, I'm running into an issue where a new user account created on the master server is not being seen for changing file permissions and such. Is the new user visible on the master itself via the standard system interfaces (getent passwd $newuser, id $user) ? I can login using the newly created user account but when I try to change permissions on a file/directory it comes up with the following error; Chown: changing ownership of 'username' : Invalid argument Can you strace the chown invocation so that we're sure what part really fails? Now if I go to my replica IPA server it works fine. I deleted the user and created it again with the same username, gave the account a different UID and when I tried to permission the directory again it states the same error as above. Please note that file ownership is defined by IDs, not usernames, so if you recreate a user with different ID, you need to chown all his previously used files. I changed the permissions on the replica server and went back to the master and looked at the permissions of the directory and it's showing the old UID. I can login as the new user and the permissions are fine, the user can create and modify files in that directory. When I run ipa user-find -all -raw username it brings up all of the correct information that I entered for the account. I searched for the old UID that was used with this account before but it doesn't seem to exist in IPA. I've tried restarting the IPA service and remounting the directory that contains the required folders but with no luck. I cleared the SSSD and the NSCD cache. Using nscd along with SSSD is discouraged. We recommend to disable nscd, at last for the maps that SSSD caches. SSSD provides its own fast in-memory cache, so you won't lose performance. Does IPA have another cache that needs to be cleared or anything like that? Thanks, Matt -- 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
Re: [Freeipa-users] EXTERNAL: Re: Usernames not being seen on IPA Master
The UID is 2600 and the GID is 2000. It's a common group which all of our users
are in.
Yeah the error comes when trying to change ownership of files/directory (new or
old).
Just seems a bit odd the replica server is able to change ownership of
files/directories fine.
Matt
-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Thursday, April 16, 2015 10:56 AM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.com
Subject: Re: EXTERNAL: Re: [Freeipa-users] Usernames not being seen on IPA
Master
On Thu, Apr 16, 2015 at 01:42:52PM +, Joseph, Matthew (EXP) wrote:
Hey Jakub,
Getent passwd returns all of the IPA users when searching either the username
or UID.
Yes I know that permissions are defined by UID/GID, used a new UID that has
not been previously used for this new account for this test.
Good to know, I disabled the nscd service.
Here is the output of the strace for chown on a directory.
execve(/bin/chown, [chown, wpooh, /home/wpooh], [/* 32 vars */]) = 0
brk(0) = 0x1095000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b698000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360\355\341\0044\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1918016, ...}) = 0
mmap(0x3404e0, 3741864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x3404e0
mprotect(0x3404f89000, 2093056, PROT_NONE) = 0
mmap(0x3405188000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x188000) = 0x3405188000
mmap(0x340518d000, 18600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x340518d000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b674000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b673000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b672000
arch_prctl(ARCH_SET_FS, 0x7f5f4b673700) = 0
mprotect(0x3405188000, 16384, PROT_READ) = 0
mprotect(0x340481f000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
brk(0) = 0x1095000
brk(0x10b6000) = 0x10b6000
open(/usr/lib/locale/locale-archive, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0
mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f457e1000
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/nscd/socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
open(/etc/nsswitch.conf, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1734, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, #\n# /etc/nsswitch.conf\n#\n# An ex..., 4096) = 1734
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=142486, ...}) = 0
mmap(NULL, 142486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5f4b675000
close(3)= 0
open(/lib64/libnss_files.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\360!\0\0\0\0\0\0...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=65928, ...}) = 0
mmap(NULL, 2151824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f5f455d3000
mprotect(0x7f5f455df000, 2097152, PROT_NONE) = 0
mmap(0x7f5f457df000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f5f457df000
close(3)= 0
mprotect(0x7f5f457df000, 4096, PROT_READ) = 0
munmap(0x7f5f4b675000, 142486) = 0
open(/etc/passwd, O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fstat(3, {st_mode=S_IFREG|0644, st_size=3404, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5f4b697000
read(3, root:x:0:0:root:/root:/bin/bash\n..., 4096) = 3404
read(3, , 4096) = 0
close(3)= 0
munmap(0x7f5f4b697000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY)
Re: [Freeipa-users] Errors in dirsrv logs
On 04/16/2015 01:52 AM, Alexander Frolushkin wrote: Hello again. Now, in addition to connection - conn= fd=xxx Incoming BER Element was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. messages, we have on six of our 16 servers NSMMReplicationPlugin - changelog program - agmt=cn=meTonw-rhidm01.unix.ad.com (nw-rhidm01:389): CSN 552de186000b0011 not found, we aren't as up to date, or we purged Maybe it begins to generate this error after one of our masters was re-initialized. Is there any way to fix it without complete replicas reinstallation? Not that I know of. What version of 389-ds-base is this? rpm -q 389-ds-base WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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] Transition old master server to new server.
On 04/16/2015 03:11 PM, William Graboyes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, I have been searching for a while and cannot seem to find an answer to the question of how to promote a replicate to a master, and use that as the new master. My original master is on ipa-server-3.0.0-37.el6.x86_64, and I am upgrading to ipa-server-4.1.0-18.el7.centos.3.x86_64 (these are both centos boxes, 6.6 and 7.1 respectively). I found some older fedora documentation that doesn't seem to be relevant any longer. If there is documentation out there that would be a great help, if not I could certainly use some pointers. Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVMAlFAAoJEJFMz73A1+zrxWYQAIsllC0oBay8lGb/Y+7MbhYm LjO2a6PRWipSee3toXnKQAkQH+aQqy58DyTfl0soC2BdHWTmLwCJEvtvireLKrox tFaDyP4zhrr8fm/c1iOODmcwNRxbeG8qonCbqs2jPvvnKoMXcRx7aN47fY+Ssrw9 gD9O+s2ldeGrs+kwXvNhU5NDt3hy0ZZA36brD3sK50xYsMzI3k5JXIWP9wDmH/ZJ J4XmisHvt+7+GqXJN0OSUJObVPBNstO+SocN+mdk3dJB408n+YD2RlNTu3nPq5GH I+xN5NzcgGxPhKlubVLGzryxuBMy1W5sbVW1dZFfMqzGOI71l1vwK5eoLtag82mx TepYfeKbbj1nem8WznEbYkd7pqjg34Qb5wAkwzT2gb8OLyf8/gy5Kh9TAWrzu98F +PeCS+dXT75lwOAYhOrpYvbpgkBPZQ84kA58KTDTtfQLEMtKS3bIxcF5xC4AFpcn arseNyLGJA2gImaD8Jl7/eeBpv9pQ9EH1rTiuYBtEXw0wQnhHk160ZLlc1gWINsj yNuCOch6XKkolGg5jujNbZlna7VNv0DC2ubtGQm7SsccSFwvxgwdd5h7TU09f1H4 WebJ2/L4a4fwZ2DQDywI7u47Rzau39v3lUo84F36Sz4/ScgVRhzMArFPEzcCKfWI mvhDIWsIEanKMrhNAIIp =f6fp -END PGP SIGNATURE- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html and search for the substring promot. There will be several sections you want to become familiar with. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Expired Certs
[ snip ] [root@ipa ~]# date Thu Apr 10 00:13:51 EDT 2014 [root@ipa ~]# /etc/init.d/certmonger restart Stopping certmonger: [ OK ] Starting certmonger: [ OK ] [root@ipa ~]# You are going way to far back in time AFAICT. The certs expired on April 5 of this year so you don't need to go back to 2014. Just go back to April 3 or 4. You'll also need to restart IPA before kicking certmonger ipactl restart rob Thanks Rob, Following your advice, it looks like only one of the eight certificates are now monitoring. Check out the following: [root@ipa ~]# getcert list | grep -A1 status status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: Error 60 connecting to https://ipa.infra.idef:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates.-- status: CA_UNREACHABLE ca-error: Server at https://ipa.infra.idef/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)).-- status: CA_UNREACHABLE ca-error: Server at https://ipa.infra.idef/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)).-- status: MONITORING ca-error: Server at https://ipa.infra.idef/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: hostname in subject of request 'ipa.infra.idef' does not match principal hostname 'ipa'). How can I get the remaining certs fixed as well? Thanks in advance. -- 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] Transition old master server to new server.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, I have been searching for a while and cannot seem to find an answer to the question of how to promote a replicate to a master, and use that as the new master. My original master is on ipa-server-3.0.0-37.el6.x86_64, and I am upgrading to ipa-server-4.1.0-18.el7.centos.3.x86_64 (these are both centos boxes, 6.6 and 7.1 respectively). I found some older fedora documentation that doesn't seem to be relevant any longer. If there is documentation out there that would be a great help, if not I could certainly use some pointers. Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVMAlFAAoJEJFMz73A1+zrxWYQAIsllC0oBay8lGb/Y+7MbhYm LjO2a6PRWipSee3toXnKQAkQH+aQqy58DyTfl0soC2BdHWTmLwCJEvtvireLKrox tFaDyP4zhrr8fm/c1iOODmcwNRxbeG8qonCbqs2jPvvnKoMXcRx7aN47fY+Ssrw9 gD9O+s2ldeGrs+kwXvNhU5NDt3hy0ZZA36brD3sK50xYsMzI3k5JXIWP9wDmH/ZJ J4XmisHvt+7+GqXJN0OSUJObVPBNstO+SocN+mdk3dJB408n+YD2RlNTu3nPq5GH I+xN5NzcgGxPhKlubVLGzryxuBMy1W5sbVW1dZFfMqzGOI71l1vwK5eoLtag82mx TepYfeKbbj1nem8WznEbYkd7pqjg34Qb5wAkwzT2gb8OLyf8/gy5Kh9TAWrzu98F +PeCS+dXT75lwOAYhOrpYvbpgkBPZQ84kA58KTDTtfQLEMtKS3bIxcF5xC4AFpcn arseNyLGJA2gImaD8Jl7/eeBpv9pQ9EH1rTiuYBtEXw0wQnhHk160ZLlc1gWINsj yNuCOch6XKkolGg5jujNbZlna7VNv0DC2ubtGQm7SsccSFwvxgwdd5h7TU09f1H4 WebJ2/L4a4fwZ2DQDywI7u47Rzau39v3lUo84F36Sz4/ScgVRhzMArFPEzcCKfWI mvhDIWsIEanKMrhNAIIp =f6fp -END PGP SIGNATURE- -- 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] posix ids not propgating
I ran this comand on each of my IPA servers and one returned usable response: ipa idrange-find --- 1 range matched --- Range name: HOSTNAME.LAN_id_range First Posix ID of the range: 192020 Number of IDs in the range: 30 Range type: local domain range Number of entries returned 1 While trying to add a new user on one of the other severs I recieve: *** Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. *** Should I go forward on other masters and do: *** ldapmodify -x -D 'cn=Directory Manager' -W Enter LDAP Password: dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: dnaNextValue dnaNextValue: 168970 - replace: dnaMaxValue dnaMaxValue: 168979 ^D modifying entry cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config *** -- 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] Replication seems to begin but failed after 127 seconds ...
On 04/15/2015 10:44 PM, James James wrote: The ipareplica-install.log file in attachment ... Here are the pertinent bits: 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from SchemaCache 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=ldap://ipa.example.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x484f4d0 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from SchemaCache 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa1.example.com:636 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4170290 2015-04-15T15:08:44Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 368, in __setup_replica r_bindpw=self.dm_password) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 969, in setup_replication raise RuntimeError(Failed to start replication) RuntimeError: Failed to start replication 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start replication The times are a little off, but I believe this corresponds to [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. Processed 1539 entries in 126 seconds. (12.21 entries/sec) [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is coming online; enabling replication I don't know why setup_replication is reporting an error if replication completed successfully. 2015-04-16 2:22 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: Rich Megginson wrote: On 04/15/2015 02:58 PM, James James wrote: Nothing on the replica .. maybye a process on the master. How can I check that ? I have no idea. But it seems highly unlikely that a process on the master is able to shutdown a process on the replica . . . I would say that there is some problem with the ipa-replica-install not properly checking the status - see below: 2015-04-15 21:37 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com mailto:rmegg...@redhat.com mailto:rmegg...@redhat.com: On 04/15/2015 12:43 PM, James James wrote: Here the log 2015-04-15 18:58 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com mailto:rmegg...@redhat.com mailto:rmegg...@redhat.com: On 04/15/2015 09:46 AM, James James wrote: Hello, I have been looking to solve my problem but I 'm asking for some help. The replication begins but cannot be completed I want to install a new fresh replica but I've always got this error : [21/35]: configure dirsrv ccache [22/35]: enable SASL mapping fallback [23/35]: restarting directory server [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 127 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress in progress yet not in progress The error log below clearly shows that replica init succeeded after 127 seconds. IPA-ers - wasn't there some bug about checking replica status properly? The loop looks at nsds5BeginReplicaRefresh, nsds5replicaUpdateInProgress and nsds5ReplicaLastInitStatus. It loops looking for nsds5BeginReplicaRefresh. If there is no value it prints Update in progress, %d seconds elapsed. Once it gets a status, the update is done, and it looks at nsds5ReplicaLastInitStatus. If it isn't empty, doesn't include 'replica busy' or 'Total update succeeded' then it looks to see if nsds5replicaUpdateInProgress is TRUE. If it is, ir prints Update in progress yet not in progress and tries the loop again. AFAICT this part of a replica install doesn't restart 389-ds. /var/log/ipareplica-install.log may hold some details. 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
