Re: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK
Hi all, Bugzilla created: https://bugzilla.redhat.com/show_bug.cgi?id=1400462 Winfried Op 01-12-16 om 09:19 schreef Petr Spacek: On 1.12.2016 09:07, Winfried de Heiden wrote: Hi all, Started as "just because it's possible" running FreeIPA on a BananaPI or Raspberry PI turned to out to be rather succesfull and for more than a year I use FreeIPA at home. OK, running on small boards like Raspberry PI it never will be fast but it's surely quick enough to run at small scale. However, starting FreeIPA became much slower since Fedora 24 and even more on Fedora 25. Since Oracle Java is also available for ARM and there's much written this is much faster I took some time for an experiment. Starting FreeIPA using the default installation (running OpenJDK) starting FreeIPA takes a painfull 15 minutes (afterward, it all just works fine): [root@rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real15m40.638s user0m33.095s sys0m1.910s Now, after installing Oracle Java and changing JAVA_HOME in /etc/sysconfig/pki-tomcat to: #JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk" JAVA_HOME="/opt/jdk1.8.0_111/jre" [root@rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real2m14.823s user0m33.400s sys0m1.730s Wow, I expected some improvement, but this far better than expected! This leaves a question: what is happening here!!?? Huh? That is really huge difference. Please open a bug against OpenJDK: https://bugzilla.redhat.com/enter_bug.cgi That way it will reach OpenJDK developers. They will have better idea than FreeIPA developers, I guess. Please report the bug number to this forum so we can track it as well. Thank you very much! Petr^2 Spacek I prefer to use OpenJDK, it 's Open Source and because it's availabe from the Fedora ARM repositories it is also much more easy to update. But for now, Oracle is much faster and OpenJDK from this point of view is a very poor alternative. Why is OpenJDK so much slower? Is improvement possible? For now (some "tweaking") of in a future release? For the record, I tested these Java versions: [root@rpi2 sysconfig]# /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version openjdk version "1.8.0_111" OpenJDK Runtime Environment (build 1.8.0_111-b16) OpenJDK Zero VM (build 25.111-b16, interpreted mode) [root@rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode) Kind regards, Winfried -- 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] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK
Hi all, Started as "just because it's possible" running FreeIPA on a BananaPI or Raspberry PI turned to out to be rather succesfull and for more than a year I use FreeIPA at home. OK, running on small boards like Raspberry PI it never will be fast but it's surely quick enough to run at small scale. However, starting FreeIPA became much slower since Fedora 24 and even more on Fedora 25. Since Oracle Java is also available for ARM and there's much written this is much faster I took some time for an experiment. Starting FreeIPA using the default installation (running OpenJDK) starting FreeIPA takes a painfull 15 minutes (afterward, it all just works fine): [root@rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real 15m40.638s user 0m33.095s sys 0m1.910s Now, after installing Oracle Java and changing JAVA_HOME in /etc/sysconfig/pki-tomcat to: #JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk" JAVA_HOME="/opt/jdk1.8.0_111/jre" [root@rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real 2m14.823s user 0m33.400s sys 0m1.730s Wow, I expected some improvement, but this far better than expected! This leaves a question: what is happening here!!?? I prefer to use OpenJDK, it 's Open Source and because it's availabe from the Fedora ARM repositories it is also much more easy to update. But for now, Oracle is much faster and OpenJDK from this point of view is a very poor alternative. Why is OpenJDK so much slower? Is improvement possible? For now (some "tweaking") of in a future release? For the record, I tested these Java versions: [root@rpi2 sysconfig]# /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version openjdk version "1.8.0_111" OpenJDK Runtime Environment (build 1.8.0_111-b16) OpenJDK Zero VM (build 25.111-b16, interpreted mode) [root@rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode) Kind regards, Winfried -- 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] FreeOTP
Hi all, Great news, can't wait for it to be available in Fedora ARM en test. Winny Op 21-06-16 om 22:23 schreef Nathaniel McCallum: I have found and fixed what I believe to be the issue. I have submitted a patch upstream for review: https://github.com/krb5/krb5/pull/471 Once merged, we will backport the fix into all existing Fedora releases. So you should get an update via a simple: dnf update. On Thu, 2016-06-16 at 10:28 +0200, Winfried de Heiden wrote: Hi all, "So it looks a bit like a libverto 32bit issue"; any news or progress on this? Bugzilla? Winny Op 09-06-16 om 18:51 schreef Sumit Bose: On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote: On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote: On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden wrote: Hi all, I can install libvert-libev but removing libverto-tevent will remove 123 dependencies also. (wget, tomcat and much more...) Hence, I installed libverto-libev, but dit not remove libverto- tevent to give it a try. After ipactl restart still the same problem: fyi, I think I can reproduce the issue on 32bit Fedora. I tried libverto-libev as well but I removed libverto-tevent after installing libverto-libev with 'rpm -e --nodeps ' to make sure libverto has no other chance. So it looks a bit like a libverto 32bit issue. I used libverto-0.2.6-4.fc22. Since I knew that is was working before on 32bits I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock. Nathaniel, do you have any suggestions what to check with gdb? It may not be a libverto issue at all. Just to summarize, krb5kdc sends the otp request to ipa-otpd using RADIUS-over-UNIX-socket. It appears that ipa-otpd receives the request and sends the appropriate response. However, krb5kdc never appears to receive the request and times out. Once it times out, it closes the socket and ipa-otpd exits. The question is: why? This could be a bug in krb5kdc, libkrad or libverto. Does the event actually fire from libverto? Does libkrad process it correctly? Does krb5kdc process it correctly? There are lots of places to attach gdb. I would probably start here: https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L1 93 It looks like the 3rd argument of recv(), the buffer length, becomes negative aka very big in on_io_read() i = recv(verto_get_fd(rr->io), rr->buffer.data + rr- buffer.length, pktlen - rr->buffer.length, 0); because pktlen is 4 and rr->buffer.length is 16 on my 32bit system. I wonder if pktlen isn't sufficient here because it already is the result of 'len - buffer->length' which is calculated in krad_packet_bytes_needed() ? bye, Sumit -- 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] FreeOTP
Hi all, "So it looks a bit like a libverto 32bit issue"; any news or progress on this? Bugzilla? Winny Op 09-06-16 om 18:51 schreef Sumit Bose: On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote: On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote: On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden wrote: Hi all, I can install libvert-libev but removing libverto-tevent will remove 123 dependencies also. (wget, tomcat and much more...) Hence, I installed libverto-libev, but dit not remove libverto- tevent to give it a try. After ipactl restart still the same problem: fyi, I think I can reproduce the issue on 32bit Fedora. I tried libverto-libev as well but I removed libverto-tevent after installing libverto-libev with 'rpm -e --nodeps ' to make sure libverto has no other chance. So it looks a bit like a libverto 32bit issue. I used libverto-0.2.6-4.fc22. Since I knew that is was working before on 32bits I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock. Nathaniel, do you have any suggestions what to check with gdb? It may not be a libverto issue at all. Just to summarize, krb5kdc sends the otp request to ipa-otpd using RADIUS-over-UNIX-socket. It appears that ipa-otpd receives the request and sends the appropriate response. However, krb5kdc never appears to receive the request and times out. Once it times out, it closes the socket and ipa-otpd exits. The question is: why? This could be a bug in krb5kdc, libkrad or libverto. Does the event actually fire from libverto? Does libkrad process it correctly? Does krb5kdc process it correctly? There are lots of places to attach gdb. I would probably start here: https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L193 It looks like the 3rd argument of recv(), the buffer length, becomes negative aka very big in on_io_read() i = recv(verto_get_fd(rr->io), rr->buffer.data + rr->buffer.length, pktlen - rr->buffer.length, 0); because pktlen is 4 and rr->buffer.length is 16 on my 32bit system. I wonder if pktlen isn't sufficient here because it already is the result of 'len - buffer->length' which is calculated in krad_packet_bytes_needed() ? bye, Sumit -- 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] FreeOTP
Hi all, I agree on it's look like a 32 bit issue. Trying to reproduce on Fedora 64 bit; no problems Trying to reproduce on Fedora 23 32 bit (x886): [root@freeipa ~]# journalctl -l -u ipa-otpd@0-6397-0.service -- Logs begin at vr 2016-06-10 09:23:33 CEST, end at vr 2016-06-10 10:53:28 CEST. -- jun 10 10:53:27 freeipa.local.lan systemd[1]: Started ipa-otpd service (PID 6397/UID 0). jun 10 10:53:27 freeipa.local.lan systemd[1]: Starting ipa-otpd service (PID 6397/UID 0)... jun 10 10:53:27 freeipa.local.lan ipa-otpd[7320]: LDAP: ldapi://%2fvar%2frun%2fslapd-LOCAL-LAN.socket jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: request received jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: user query start jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: user query end: uid=otpuser,cn=users,cn=accounts,dc=local,dc=lan jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: bind start: uid=otpuser,cn=users,cn=accounts,dc=local,dc=lan jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: bind end: success jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: otpu...@local.lan: response sent: Access-Accept jun 10 10:53:28 freeipa.local.lan ipa-otpd[7320]: stdio.c:073: Connection reset by peer: Error receiving packet jun 10 10:53:28 freeipa.local.lan systemd[1]: ipa-otpd@0-6397-0.service: Main process exited, code=exited, status=1/FAILURE jun 10 10:53:28 freeipa.local.lan systemd[1]: ipa-otpd@0-6397-0.service: Unit entered failed state. jun 10 10:53:28 freeipa.local.lan systemd[1]: ipa-otpd@0-6397-0.service: Failed with result 'exit-code'. Same error as on Fedora ARM which is also 32 bit. Removing libverto-tevent doesn't work. Cheers you all! Winny Op 09-06-16 om 18:51 schreef Sumit Bose: On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote: On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote: On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden wrote: Hi all, I can install libvert-libev but removing libverto-tevent will remove 123 dependencies also. (wget, tomcat and much more...) Hence, I installed libverto-libev, but dit not remove libverto- tevent to give it a try. After ipactl restart still the same problem: fyi, I think I can reproduce the issue on 32bit Fedora. I tried libverto-libev as well but I removed libverto-tevent after installing libverto-libev with 'rpm -e --nodeps ' to make sure libverto has no other chance. So it looks a bit like a libverto 32bit issue. I used libverto-0.2.6-4.fc22. Since I knew that is was working before on 32bits I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock. Nathaniel, do you have any suggestions what to check with gdb? It may not be a libverto issue at all. Just to summarize, krb5kdc sends the otp request to ipa-otpd using RADIUS-over-UNIX-socket. It appears that ipa-otpd receives the request and sends the appropriate response. However, krb5kdc never appears to receive the request and times out. Once it times out, it closes the socket and ipa-otpd exits. The question is: why? This could be a bug in krb5kdc, libkrad or libverto. Does the event actually fire from libverto? Does libkrad process it correctly? Does krb5kdc process it correctly? There are lots of places to attach gdb. I would probably start here: https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L193 It looks like the 3rd argument of recv(), the buffer length, becomes negative aka very big in on_io_read() i = recv(verto_get_fd(rr->io), rr->buffer.data + rr->buffer.length, pktlen - rr->buffer.length, 0); because pktlen is 4 and rr->buffer.length is 16 on my 32bit system. I wonder if pktlen isn't sufficient here because it already is the result of 'len - buffer->length' which is calculated in krad_packet_bytes_needed() ? bye, Sumit -- 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] FreeOTP
Hi all, I can install libvert-libev but removing libverto-tevent will remove 123 dependencies also. (wget, tomcat and much more...) Hence, I installed libverto-libev, but dit not remove libverto-tevent to give it a try. After ipactl restart still the same problem: root@ipa ~]# systemctl --failed; journalctl -l -u ipa-otpd@5-2998-0.service -xe UNIT LOAD ACTIVE SUB DESCRIPTION * ipa-otpd@5-2998-0.service loaded failed failed ipa-otpd service (PID 2998/UID 0) LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 1 loaded units listed. Pass --all to see loaded but inactive units, too. ~Unit ipa-otpd@5-2998-0.service has begun starting up. Jun 09 08:12:40 ipa.blabla.bla ipa-otpd[3558]: LDAP: ldapi://%2fvar%2frun%2fslapd-BLABLA-BLA.socket Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: request received Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: user query start Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: user query end: uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: bind start: uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: bind end: success Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: otpu...@blabla.bla: response sent: Access-Accept Jun 09 08:12:41 ipa.blabla.bla ipa-otpd[3558]: stdio.c:073: Connection reset by peer: Error receiving packet Jun 09 08:12:41 ipa.blabla.bla systemd[1]: ipa-otpd@5-2998-0.service: Main process exited, code=exited, status=1/FAILURE Jun 09 08:12:41 ipa.blabla.bla systemd[1]: ipa-otpd@5-2998-0.service: Unit entered failed state. Jun 09 08:12:41 ipa.blabla.bla systemd[1]: ipa-otpd@5-2998-0.service: Failed with result 'exit-code'. :( Winny Op 08-06-16 om 19:15 schreef Nathaniel McCallum: Can you please try: # dnf install libverto-libev # dnf remove libverto-tevent # ipactl restart On Wed, 2016-06-08 at 18:30 +0200, Winfried de Heiden wrote: Well, here your are: rpm -qa 'libverto*' 'krb5*' krb5-pkinit-1.14.1-6.fc23.armv7hl libverto-tevent-0.2.6-5.fc23.armv7hl krb5-libs-1.14.1-6.fc23.armv7hl krb5-workstation-1.14.1-6.fc23.armv7hl libverto-0.2.6-5.fc23.armv7hl krb5-server-1.14.1-6.fc23.armv7hlfedora I'm wondering if this is a Fedora ARM issue, I can't reproduce it on Fedora x86_64... Winny Op 08-06-16 om 15:53 schreef Nathaniel McCallum: No, we need to know what libverto *backend* you are using. Please provide the output from this command: rpm -qa 'libverto*' 'krb5*' On Wed, 2016-06-08 at 08:34 +0200, Winfried de Heiden wrote: Hi all, Well, the libverto is there some time allready (yep, it's running on a Bananapi!), doesn't feel like a recent update, so a Name : libverto Version : 0.2.6 Release : 5.fc23 Architecture: armv7hl Install Date: Thu Jan 1 01:08:24 1970 Group : Unspecified Size : 21896 License : MIT Signature : RSA/SHA256, Sun Jun 21 06:24:46 2015, Key ID 32474cf834ec9cba Source RPM : libverto-0.2.6-5.fc23.src.rpm Build Date : Wed Jun 17 20:37:05 2015 Build Host : arm04-builder19.arm.fedoraproject.org No, no previous build available... [root@ipa boot]# dnf downgrade libverto Last metadata expiration check: 0:10:21 ago on Wed Jun 8 08:19:53 2016. Package libverto of lowest version already installed, cannot downgrade it. Error: Nothing to do. My first guess is that you are hitting this bug: https://github.c om/k rb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e What to do about it...? -- 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] FreeOTP
Well, here your are: rpm -qa 'libverto*' 'krb5*' krb5-pkinit-1.14.1-6.fc23.armv7hl libverto-tevent-0.2.6-5.fc23.armv7hl krb5-libs-1.14.1-6.fc23.armv7hl krb5-workstation-1.14.1-6.fc23.armv7hl libverto-0.2.6-5.fc23.armv7hl krb5-server-1.14.1-6.fc23.armv7hlfedora I'm wondering if this is a Fedora ARM issue, I can't reproduce it on Fedora x86_64... Winny Op 08-06-16 om 15:53 schreef Nathaniel McCallum: No, we need to know what libverto *backend* you are using. Please provide the output from this command: rpm -qa 'libverto*' 'krb5*' On Wed, 2016-06-08 at 08:34 +0200, Winfried de Heiden wrote: Hi all, Well, the libverto is there some time allready (yep, it's running on a Bananapi!), doesn't feel like a recent update, so a Name : libverto Version : 0.2.6 Release : 5.fc23 Architecture: armv7hl Install Date: Thu Jan 1 01:08:24 1970 Group : Unspecified Size : 21896 License : MIT Signature : RSA/SHA256, Sun Jun 21 06:24:46 2015, Key ID 32474cf834ec9cba Source RPM : libverto-0.2.6-5.fc23.src.rpm Build Date : Wed Jun 17 20:37:05 2015 Build Host : arm04-builder19.arm.fedoraproject.org No, no previous build available... [root@ipa boot]# dnf downgrade libverto Last metadata expiration check: 0:10:21 ago on Wed Jun 8 08:19:53 2016. Package libverto of lowest version already installed, cannot downgrade it. Error: Nothing to do. My first guess is that you are hitting this bug: https://github.com/k rb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e What to do about it...? -- 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] FreeIPA 4.4
Hi all, Any news/progress about FreeIPA 4.4? On http://www.freeipa.org/page/Roadmap: FreeIPA 4.4: feature release. Release planned for end of May 2016. Any updated release date...? Winny -- 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] FreeOTP
The libverto used on RHEL 7.2 (itś working
there) is v0.2.5-4 build date January 26 2014, so that's an
older one.
Is this more recent one causing the
problems? How to test?
Winny
Op 08-06-16 om 08:34 schreef Winfried
de Heiden:
Hi all,
Well, the libverto is there some time
allready (yep, it's running on a Bananapi!), doesn't feel like a
recent update, so a
Name : libverto
Version : 0.2.6
Release : 5.fc23
Architecture: armv7hl
Install Date: Thu Jan 1 01:08:24 1970
Group : Unspecified
Size : 21896
License : MIT
Signature : RSA/SHA256, Sun Jun 21
06:24:46 2015, Key ID 32474cf834ec9cba
Source RPM : libverto-0.2.6-5.fc23.src.rpm
Build Date : Wed Jun 17 20:37:05 2015
Build Host :
arm04-builder19.arm.fedoraproject.org
No, no previous build available...
[root@ipa boot]# dnf downgrade
libverto
Last metadata expiration check: 0:10:21 ago
on Wed Jun 8 08:19:53 2016.
Package libverto of lowest version already
installed, cannot downgrade it.
Error: Nothing to do.
My first guess is that you are hitting this bug: https://github.com/krb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e
What to do about it...?
Winny
Op 07-06-16 om 19:15 schreef
Nathaniel McCallum:
On Tue, 2016-06-07 at 19:42 +0300, Alexander Bokovoy wrote:
Adding Nathaniel to look into it.
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Adn some more dubgging for you guys...:
un 7 17:00:52 ipa systemd: Started ipa-otpd service (PID 5887/UID
0).
Jun 7 17:00:52 ipa audit: SERVICE_START pid=1 uid=0
auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=ipa-otpd@
51-5887-
0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=?
res=success'
Jun 7 17:00:52 ipa systemd: Starting ipa-otpd service (PID
5887/UID 0)...
Jun 7 17:00:52 ipa ipa-otpd: LDAP: ldapi://%2fvar%2frun%2fslapd-
BLABLA-
BLA.socket
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: request received
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: user query start
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: user query end:
uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: bind start:
uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: bind end: success
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: response sent:
Access-Accept
Jun 7 17:00:52 ipa ipa-otpd: stdio.c:073: Connection reset by
peer: Error
receiving packet
Jun 7 17:00:52 ipa systemd: ipa-otpd@51-5887-0.service: Main
process exited,
code=exited, status=1/FAILURE
Jun 7 17:00:52 ipa systemd: ipa-otpd@51-5887-0.service: Unit
entered failed
state.
Forgot to mention, I'm running FreeIPA on Fedora ARM on a Bananapi
:) All
other, non-OTP, login are OK.
Winny
That error is misleading. All that is happening is that ipa-otpd is
closing down after krb5kdc closes the socket.
Op 07-06-16 om 16:13 schreef Alexander Bokovoy:
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Hi all,
I tried the FreeIPA webUI, ssh and "su - otpuser", all the
same result.
Ok.
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887]
(info): AS_REQ
(6 etypes {18 17 16
23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
otpu...@blabla.bla for krbtgt/
blabla@blabla.bla, Additional pre-
authentication
required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887]
(info): closing
down fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888]
(info): preauth
(otp) verify
failure: Connection timed out
I just cannot figure out what's going wrong. What
is trying
to connect to
causing this timeout? (yep, I disabled firewalld
for
this...)
What is the output of systemctl status ipa-otpd.socket
?
if it is disabled, do
systemctl enable ipa-otpd.socket
systemctl start ipa-otpd.socket
My first guess is that you are hitting this bug:
https://github.com/krb5/krb5/commit/051a31aac553defb2ef0ed4354b79909089
9904e
My second guess is that you should try a different libverto backend and
see if the problem goes away. If so, please
Re: [Freeipa-users] FreeOTP
Hi all,
Well, the libverto is there some time allready
(yep, it's running on a Bananapi!), doesn't feel like a recent
update, so a
Name : libverto
Version : 0.2.6
Release : 5.fc23
Architecture: armv7hl
Install Date: Thu Jan 1 01:08:24 1970
Group : Unspecified
Size : 21896
License : MIT
Signature : RSA/SHA256, Sun Jun 21 06:24:46
2015, Key ID 32474cf834ec9cba
Source RPM : libverto-0.2.6-5.fc23.src.rpm
Build Date : Wed Jun 17 20:37:05 2015
Build Host :
arm04-builder19.arm.fedoraproject.org
No, no previous build available...
[root@ipa boot]# dnf downgrade
libverto
Last metadata expiration check: 0:10:21 ago
on Wed Jun 8 08:19:53 2016.
Package libverto of lowest version already
installed, cannot downgrade it.
Error: Nothing to do.
My first guess is that you are hitting this bug:
https://github.com/krb5/krb5/commit/051a31aac553defb2ef0ed4354b799090899904e
What to do about it...?
Winny
Op 07-06-16 om 19:15 schreef Nathaniel
McCallum:
On Tue, 2016-06-07 at 19:42 +0300, Alexander Bokovoy wrote:
Adding Nathaniel to look into it.
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Adn some more dubgging for you guys...:
un 7 17:00:52 ipa systemd: Started ipa-otpd service (PID 5887/UID
0).
Jun 7 17:00:52 ipa audit: SERVICE_START pid=1 uid=0
auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=ipa-otpd@
51-5887-
0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=?
res=success'
Jun 7 17:00:52 ipa systemd: Starting ipa-otpd service (PID
5887/UID 0)...
Jun 7 17:00:52 ipa ipa-otpd: LDAP: ldapi://%2fvar%2frun%2fslapd-
BLABLA-
BLA.socket
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: request received
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: user query start
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: user query end:
uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: bind start:
uid=otpuser,cn=users,cn=accounts,dc=blabla,dc=bla
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: bind end: success
Jun 7 17:00:52 ipa ipa-otpd: otpu...@blabla.bla: response sent:
Access-Accept
Jun 7 17:00:52 ipa ipa-otpd: stdio.c:073: Connection reset by
peer: Error
receiving packet
Jun 7 17:00:52 ipa systemd: ipa-otpd@51-5887-0.service: Main
process exited,
code=exited, status=1/FAILURE
Jun 7 17:00:52 ipa systemd: ipa-otpd@51-5887-0.service: Unit
entered failed
state.
Forgot to mention, I'm running FreeIPA on Fedora ARM on a Bananapi
:) All
other, non-OTP, login are OK.
Winny
That error is misleading. All that is happening is that ipa-otpd is
closing down after krb5kdc closes the socket.
Op 07-06-16 om 16:13 schreef Alexander Bokovoy:
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Hi all,
I tried the FreeIPA webUI, ssh and "su - otpuser", all the
same result.
Ok.
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887]
(info): AS_REQ
(6 etypes {18 17 16
23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
otpu...@blabla.bla for krbtgt/
blabla@blabla.bla, Additional pre-
authentication
required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887]
(info): closing
down fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888]
(info): preauth
(otp) verify
failure: Connection timed out
I just cannot figure out what's going wrong. What
is trying
to connect to
causing this timeout? (yep, I disabled firewalld
for
this...)
What is the output of systemctl status ipa-otpd.socket
?
if it is disabled, do
systemctl enable ipa-otpd.socket
systemctl start ipa-otpd.socket
My first guess is that you are hitting this bug:
https://github.com/krb5/krb5/commit/051a31aac553defb2ef0ed4354b79909089
9904e
My second guess is that you should try a different libverto backend and
see if the problem goes away. If so, please let me know which backend
had problems.
--
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] FreeOTP
No, neither HOTP works...
Op 07-06-16 om 17:09 schreef Prashant
Bapat:
Do HOTP tokens work fine ?
On 7 June 2016 at 20:37, Winfried de
Heiden <w...@dds.nl>
wrote:
Hi all,
Yes I check that one also. The
IPA-server is running ntp and is is sync. The FreeOTP
app is running on my phone which is synced by network,
all looks fine
Forgot to mention; this IPA-server is running on
Fedora ARM on a Bananapi. non-otp logins go well.
Winny
Op 07-06-16 om 16:56 schreef Prashant Bapat:
If this is TOTP (time
based) you want to double check the time is
properly set in both the server (NTP) and the
device that is generating the OTP tokens. I have
had issues with this with my users couple of
times.
On 7 June 2016 at 19:43,
Alexander Bokovoy <aboko...@redhat.com>
wrote:
On Tue, 07 Jun
2016, Winfried de Heiden wrote:
Hi all,
I tried the FreeIPA webUI, ssh and "su -
otpuser", all the same result.
Ok.
Jun
07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): AS_REQ
(6 etypes {18 17 16
23 25 26}) 192.168.1.251:
NEEDED_PREAUTH:
otpu...@blabla.bla
for krbtgt/
blabla@blabla.bla,
Additional pre-authentication
required
Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): closing
down fd 12
Jun 07 14:44:42 ipa.blabla.bla
krb5kdc[5888](info): preauth
(otp) verify
failure: Connection timed out
I just cannot figure out what's
going wrong. What is trying
to connect to
causing this timeout? (yep, I
disabled firewalld for
this...)
What is the output of systemctl
status ipa-otpd.socket
?
if it is disabled, do
systemctl enable ipa-otpd.socket
systemctl start ipa-otpd.socket
--
/ Alexander Bokovoy
--
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] FreeOTP
Hi all,
Yes I check that one also. The IPA-server is
running ntp and is is sync. The FreeOTP app is running on my
phone which is synced by network, all looks fine
Forgot to mention; this IPA-server is running on Fedora ARM on a
Bananapi. non-otp logins go well.
Winny
Op 07-06-16 om 16:56 schreef Prashant
Bapat:
If this is TOTP (time based) you want to
double check the time is properly set in both the server (NTP)
and the device that is generating the OTP tokens. I have had
issues with this with my users couple of times.
On 7 June 2016 at 19:43, Alexander
Bokovoy <aboko...@redhat.com>
wrote:
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Hi all,
I tried the FreeIPA webUI, ssh and "su - otpuser", all
the same result.
Ok.
Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): AS_REQ
(6 etypes {18 17 16
23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
otpu...@blabla.bla for krbtgt/
blabla@blabla.bla, Additional
pre-authentication
required
Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): closing
down fd 12
Jun 07 14:44:42 ipa.blabla.bla
krb5kdc[5888](info): preauth
(otp) verify
failure: Connection timed out
I just cannot figure out what's going wrong.
What is trying
to connect to
causing this timeout? (yep, I disabled
firewalld for
this...)
What is the output of systemctl status ipa-otpd.socket
?
if it is disabled, do
systemctl enable ipa-otpd.socket
systemctl start ipa-otpd.socket
--
/ Alexander Bokovoy
--
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] FreeOTP
Hi all,
I tried the FreeIPA webUI, ssh and "su -
otpuser", all the same result.
Winny
Op 07-06-16 om 15:02 schreef Alexander
Bokovoy:
On Tue, 07 Jun 2016, Winfried de Heiden wrote:
Hi all,
I am trying to setup Freeipa with otp using the freeotp app. All
looks fine,
adding the user to the FreeOTP app also works fine. The users
looks like:
ipa user-show otpuser
User login: otpuser
First name: otp
Last name: user
Home directory: /home/otpuser
Login shell: /bin/bash
Email address: otpu...@blabla.bla
UID: 10011
GID: 10011
User authentication types: otp
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True
However, trying to login in will fail; /var/log/krb5kdc.log will
tell:
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ (6
etypes {18 17 16
23 25 26}) 192.168.1.251: NEEDED_PREAUTH: otpu...@blabla.bla for
krbtgt/
blabla@blabla.bla, Additional pre-authentication required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing down
fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
(otp) verify
failure: Connection timed out
I just cannot figure out what's going wrong. What is trying to
connect to
causing this timeout? (yep, I disabled firewalld for this...)
How did you try to login?
--
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] FreeOTP
Hi all,
I am trying to setup Freeipa with otp using the freeotp app. All
looks fine, adding the user to the FreeOTP app also works fine.
The users looks like:
ipa user-show otpuser
User login: otpuser
First name: otp
Last name: user
Home directory: /home/otpuser
Login shell: /bin/bash
Email address: otpu...@blabla.bla
UID: 10011
GID: 10011
User authentication types: otp
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True
However, trying to login in will fail; /var/log/krb5kdc.log will
tell:
Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): AS_REQ (6 etypes {18 17 16 23 25 26})
192.168.1.251: NEEDED_PREAUTH: otpu...@blabla.bla for
krbtgt/blabla@blabla.bla, Additional pre-authentication
required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing down
fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
(otp) verify failure: Connection timed out
I just cannot figure out what's going wrong.
What is trying to connect to causing this timeout? (yep, I
disabled firewalld for this...)
Winny
--
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] dns location based discovery
Hi all, I've been playing on this topic but one can implement services discovery. Allthough it looks a bit dirty, you add _sites support to IPA by manually create a DNS zone, something like: _tcp.locationX._sites.example.com and _tcp.locationY._sites.example.com and put two SRV records, _ldap en _kerberos, in it. Now, add "dns_discovery_domain = locationX._sites.example.com" or "dns_discovery_domain = locationY._sites.example.com" dns location based discovery is there...? Just curious! Winny Op 30-05-16 om 18:39 schreef Martin Basti: On 30.05.2016 18:16, Winfried de Heiden wrote: Hi all, Thanks for the quick answer even though I send it to the wrong email address. About "Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site." I noticed that, but I was curious about the IPA part as well Now, it looks like this is going to be an item for IPA 4.4 (http://www.freeipa.org/page/V4/DNS_Location_Mechanism/) Willl it be? Yes it will be there (unless something very very bad happen) IPA 4.4 is announced "the end of May". When can we expect Freeipa 4.4, I curious to test Soon :) Martin Kind regards, Winny Op 30-05-16 om 17:54 schreef Jakub Hrozek: On Mon, May 30, 2016 at 05:22:33PM +0200, Sumit Bose wrote: On Mon, May 30, 2016 at 05:13:35PM +0200, Winfried de Heiden wrote: Hi all, The sssd-ipa man page will tell: ipa_enable_dns_sites (boolean) Enables DNS sites - location based service discovery. If true and service discovery (see Service Discovery paragraph at the bottom of the man page) is enabled, then the SSSD will first attempt location based discovery using a query that contains "_location.hostname.example.com" and then fall back to traditional SRV discovery. If the location based discovery succeeds, the IPA servers located with the location based discovery are treated as primary servers and the IPA servers located using the traditional SRV discovery are used as back up servers After enabling it in a EL 6.8 IPA client (together with some debugging) this will show up in the sssd logging: (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain '_location.ipa-client-6.blabla.bla' (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp._location.ipa-client-6.blabla.bla' Since this option is mentioned in the sssd-ipa man page, it sugests I could implement this location based service discovery. But how? Any documentation on this? How to implement on the server? How to implement a location on the client (while running ipa-client-install) Hope someone can help, it would be nice a client will choose the correct server based on it's location... In this case SSSD was a bit faster then the server side. Please monitor https://fedorahosted.org/freeipa/ticket/2008 for the progress. There is a link to a design page with more details as well. HTH bye, Sumit P.S. I changed the mailing-list address to @redhat.com. btw Winfried, I saw today the case you filed. Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site. The RFE Sumit linked is 'just' about the IPA side of the equation. -- Manage your subs
Re: [Freeipa-users] dns location based discovery
Can't wait! Winny Op 30-05-16 om 18:39 schreef Martin Basti: On 30.05.2016 18:16, Winfried de Heiden wrote: Hi all, Thanks for the quick answer even though I send it to the wrong email address. About "Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site." I noticed that, but I was curious about the IPA part as well Now, it looks like this is going to be an item for IPA 4.4 (http://www.freeipa.org/page/V4/DNS_Location_Mechanism/) Willl it be? Yes it will be there (unless something very very bad happen) IPA 4.4 is announced "the end of May". When can we expect Freeipa 4.4, I curious to test Soon :) Martin Kind regards, Winny Op 30-05-16 om 17:54 schreef Jakub Hrozek: On Mon, May 30, 2016 at 05:22:33PM +0200, Sumit Bose wrote: On Mon, May 30, 2016 at 05:13:35PM +0200, Winfried de Heiden wrote: Hi all, The sssd-ipa man page will tell: ipa_enable_dns_sites (boolean) Enables DNS sites - location based service discovery. If true and service discovery (see Service Discovery paragraph at the bottom of the man page) is enabled, then the SSSD will first attempt location based discovery using a query that contains "_location.hostname.example.com" and then fall back to traditional SRV discovery. If the location based discovery succeeds, the IPA servers located with the location based discovery are treated as primary servers and the IPA servers located using the traditional SRV discovery are used as back up servers After enabling it in a EL 6.8 IPA client (together with some debugging) this will show up in the sssd logging: (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain '_location.ipa-client-6.blabla.bla' (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp._location.ipa-client-6.blabla.bla' Since this option is mentioned in the sssd-ipa man page, it sugests I could implement this location based service discovery. But how? Any documentation on this? How to implement on the server? How to implement a location on the client (while running ipa-client-install) Hope someone can help, it would be nice a client will choose the correct server based on it's location... In this case SSSD was a bit faster then the server side. Please monitor https://fedorahosted.org/freeipa/ticket/2008 for the progress. There is a link to a design page with more details as well. HTH bye, Sumit P.S. I changed the mailing-list address to @redhat.com. btw Winfried, I saw today the case you filed. Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site. The RFE Sumit linked is 'just' about the IPA side of the equation. -- 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] dns location based discovery
Hi all, Thanks for the quick answer even though I send it to the wrong email address. About "Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site." I noticed that, but I was curious about the IPA part as well Now, it looks like this is going to be an item for IPA 4.4 (http://www.freeipa.org/page/V4/DNS_Location_Mechanism/) Willl it be? IPA 4.4 is announced "the end of May". When can we expect Freeipa 4.4, I curious to test Kind regards, Winny Op 30-05-16 om 17:54 schreef Jakub Hrozek: On Mon, May 30, 2016 at 05:22:33PM +0200, Sumit Bose wrote: On Mon, May 30, 2016 at 05:13:35PM +0200, Winfried de Heiden wrote: Hi all, The sssd-ipa man page will tell: ipa_enable_dns_sites (boolean) Enables DNS sites - location based service discovery. If true and service discovery (see Service Discovery paragraph at the bottom of the man page) is enabled, then the SSSD will first attempt location based discovery using a query that contains "_location.hostname.example.com" and then fall back to traditional SRV discovery. If the location based discovery succeeds, the IPA servers located with the location based discovery are treated as primary servers and the IPA servers located using the traditional SRV discovery are used as back up servers After enabling it in a EL 6.8 IPA client (together with some debugging) this will show up in the sssd logging: (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain '_location.ipa-client-6.blabla.bla' (Mon May 30 16:51:08 2016) [sssd[be[blabla.bla]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp._location.ipa-client-6.blabla.bla' Since this option is mentioned in the sssd-ipa man page, it sugests I could implement this location based service discovery. But how? Any documentation on this? How to implement on the server? How to implement a location on the client (while running ipa-client-install) Hope someone can help, it would be nice a client will choose the correct server based on it's location... In this case SSSD was a bit faster then the server side. Please monitor https://fedorahosted.org/freeipa/ticket/2008 for the progress. There is a link to a design page with more details as well. HTH bye, Sumit P.S. I changed the mailing-list address to @redhat.com. btw Winfried, I saw today the case you filed. Please note that for AD users (which is IIRC the majority of your environment), SSSD should already choose the right site. The RFE Sumit linked is 'just' about the IPA side of the equation. -- 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] could not get zone keys for secure dynamic update
Hi all, ipa-dns-install --dnssec-master --force did the trick, this is looking much better. I'l do some more tests later. For now, thanks a lot! Winny Op 23-02-16 om 14:52 schreef Petr Spacek: On 23.2.2016 14:18, Winfried de Heiden wrote: Hi all, And so did I, following http://www.freeipa.org/page/Troubleshooting#DNSSEC_master_is_not_configured: ipa-dns-install --dnssec-master The log file for this installation can be found in /var/log/ipaserver-install.log == This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) * Configure SoftHSM (required by DNSSEC) * Configure ipa-dnskeysyncd (required by DNSSEC) * Configure ipa-ods-exporter (required by DNSSEC key master) * Configure OpenDNSSEC (required by DNSSEC key master) * Generate DNSSEC master key (required by DNSSEC key master) NOTE: DNSSEC zone signing is not enabled by default Plan carefully, replacing DNSSEC key master is not recommended To accept the default shown in brackets, press the Enter key. Do you want to setup this IPA server as DNSSEC key master? [no]: yes DNSSEC signing is already enabled for following zone(s): example.com. Installation cannot continue without the OpenDNSSEC database file from the original DNSSEC master server. Please use option --kasp-db to specify location of the kasp.db file copied from the original DNSSEC master server. WARNING: Zones will become unavailable if you do not provide the original kasp.db file. However, it seems like I don't have a key, that was the problem in the first place Right. This is a special case so you need to provide --force option to override the check and continue with installation. When you do that, please go through the Troubleshooting page again, hopefully it will help. Petr^2 Spacek Anyway, trying to continue: bash-4.3$ ods-ksmutil zone list zonelist filename set to /etc/opendnssec/zonelist.xml. Cannot open destination file, will not make backup. No zones in DB or zonelist. Indeed, the file /etc/opendnssec/zonelist.xml is the installed by default, only having the not-used example zones. Also, python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py does not show any zone private keys. Is still looks like these are not created. So, it still looks like DNSSEC signing is enabled, but the key is not there. Winny Op 22-02-16 om 16:31 schreef Petr Spacek: On 22.2.2016 14:02, Winfried de Heiden wrote: Hi all, Following http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work was most usefull, It turned out the package "freeipa-server-dns"was missing. Strange, I am running DNS, but...: * I upgraded form Fedora 22 to 23 includng upgrading from IPA 4.1 to 4.2. * Also: I'm running this on a Bananapi "server". * There's no slave. Anyway, ipa dnszone-show tells DNSsec was ebabled: Allow in-line DNSSEC signing: TRUE but most likely due to the missing freeipa-server-dns it was missing dependencies as well, for example the package opendnssec was missing. After installing freeipa-server-dns all packages seems to be in place, but the kasp.db file is empty: root@ipa ~]# ls -l /var/opendnssec/kasp.db -rw-rw. 1 ods ods 0 Feb 22 11:29 /var/opendnssec/kasp.db No wonder I still get messages like "could not get zone keys". Shouldn't a key be added? How? (without blowing the current DNS) DNSSEC key master should do that automatically. Please continue with next steps as described on http://www.freeipa.org/page/Troubleshooting#DNSSEC_master_is_not_configured and we will see. Petr^2 Spacek Winny Op 22-02-16 om 11:10 schreef Petr Spaceopendnssec On 22.2.2016 09:36, Winfried de Heiden wrote: Hi all, I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err ) like these: Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found What's going wrong here, how to fix it?
Re: [Freeipa-users] could not get zone keys for secure dynamic update
Hi all,
Following
http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work
was most usefull, It turned out the package
"freeipa-server-dns"was missing. Strange, I am running DNS,
but...:
I upgraded form Fedora 22 to 23 includng
upgrading from IPA 4.1 to 4.2.
Also: I'm running this on a Bananapi
"server".
There's no slave.
Anyway, ipa dnszone-show tells DNSsec was ebabled:
Allow in-line DNSSEC signing: TRUE
but most likely due to the missing freeipa-server-dns
it was missing dependencies as well, for example the package
opendnssec was missing.
After installing freeipa-server-dns all packages seems to be in
place, but the kasp.db file is empty:
root@ipa ~]# ls -l /var/opendnssec/kasp.db
-rw-rw. 1 ods ods 0 Feb 22 11:29 /var/opendnssec/kasp.db
No wonder I still get messages like "could not get zone keys".
Shouldn't a key be added? How? (without blowing the current
DNS)
Winny
Op 22-02-16 om 11:10 schreef Petr
Spaceopendnssec
On 22.2.2016 09:36, Winfried de Heiden wrote:
Hi all,
I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err )
like these:
Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): could not get zone keys for secure dynamic update
Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): receive_secure_serial: not found
Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): could not get zone keys for secure dynamic update
Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): receive_secure_serial: not found
Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): could not get zone keys for secure dynamic update
Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN
(signed): receive_secure_serial: not found
What's going wrong here, how to fix it?
Hello,
this might have multiple reasons.
Please walk step-by-step through following page:
http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work
Additional questions:
* What version of FreeIPA and on what platform do you use?
* Is the zone signed on DNSSEC key master or on replica? Does it work on one
FreeIPA server but not on some other server?
* Did you change something lately?
--
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] could not get zone keys for secure dynamic update
Hi all, I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err ) like these: Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): could not get zone keys for secure dynamic update Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN (signed): receive_secure_serial: not found What's going wrong here, how to fix it? Kind regards, winny -- 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] Active Directory Trust = filter users
Hi all, "hy are you concerned about this in the first place? " It started from a practical point of view: if one is using the DC of the Office Automation, Ad users will get all sorts of AD groups I am never going to use. so why do I want to see them anyway? My screen get's a bit messy as for "u...@ad.example.com" when this user belongs tot 25 or something groups... It would be nice to hide these... Can I blacklist some of the groups? (Trusts --> ad.example.com --> Settings) by using the SID? Winny Op 10-02-16 om 09:42 schreef Jakub Hrozek: On Tue, Feb 09, 2016 at 11:58:46AM +0100, Winfried de Heiden wrote: Hi all, Using an Active Directory Trust with IPA all works fine but there's an disadvantage: it might brong in lots and lots of groups I am not interested in since it mainly hit Windows and/or Office stuff. Why are you concerned about this in the first place? Is it about performance needed to process these groups or about resources that can be owned by these groups? Now, is it possible to filter AD-groups? or: can I use an AD search base filter? (something like cn=linuxgroups,ou=allgroups,dc=example,dc=com) Not at the moment, the subdomains are autoconfigured and not configurable. On a small scale ID views can be used, but it not a great solution. (for all new groups appearing in AD the ID view must be modified) Some sugestions or documentation on filtering AD groups? Winny -- 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] Active Directory Trust = filter users
Hi all, Using an Active Directory Trust with IPA all works fine but there's an disadvantage: it might brong in lots and lots of groups I am not interested in since it mainly hit Windows and/or Office stuff. Now, is it possible to filter AD-groups? or: can I use an AD search base filter? (something like cn=linuxgroups,ou=allgroups,dc=example,dc=com) On a small scale ID views can be used, but it not a great solution. (for all new groups appearing in AD the ID view must be modified) Some sugestions or documentation on filtering AD groups? Winny -- 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] OTP
Hi all, I' m trying to enable OTP: - Enabled "Two factor authentication (password + OTP)" for a particular user. - Added a OTP token, FreeOTP on an Android that is, for the user which all went fine. Trying to login will fail. After several attempts, systemctl --failed will tell: UNIT LOAD ACTIVE SUB DESCRIPTION * ipa-otpd@0-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@1-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@10-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@11-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@12-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@13-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@14-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@15-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@16-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@2-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@3-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@4-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@5-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@6-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@7-1642-0.service loaded failed failed ipa-otpd service (PID 1642/UID 0) * ipa-otpd@8-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) * ipa-otpd@9-1643-0.service loaded failed failed ipa-otpd service (PID 1643/UID 0) LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 17 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. Journalctl will tell some more: root@ipa log]# journalctl -f -u ipa-otpd@9-1643-0.service -- Logs begin at Fri 2016-01-29 10:14:55 CET. -- Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Main process exited, code=exited, status=1/FAILURE Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Unit entered failed state. Feb 02 11:03:19 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Failed with result 'exit-code'. Feb 02 11:04:31 ipa.blabla.bla systemd[1]: Started ipa-otpd service (PID 1643/UID 0). Feb 02 11:04:31 ipa.blabla.bla systemd[1]: Starting ipa-otpd service (PID 1643/UID 0)... Feb 02 11:04:31 ipa.blabla.bla ipa-otpd[2924]: LDAP: ldapi://%2fvar%2frun%2fslapd-BLABLA-BLA.socket Feb 02 11:05:23 ipa.blabla.bla ipa-otpd[2924]: stdio.c:073: Invalid argument: Error receiving packet Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Main process exited, code=exited, status=1/FAILURE Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Unit entered failed state. Feb 02 11:05:23 ipa.blabla.bla systemd[1]: ipa-otpd@9-1643-0.service: Failed with result 'exit-code'. What' s going wrong here? Winny -- 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 KDC Proxy
OK clear, many thanks! Winny Op 25-01-16 om 09:45 schreef Christian Heimes: On 2016-01-25 08:17, Winfried de Heiden wrote: Great, Changing /etc/ipa/kdcproxy/kdcproxy.conf [global] configs = mit use_dns = false to # cat /etc/ipa/kdcproxy/kdcproxy.conf [global] configs = mit use_dns = true along with adding the windows realm to krb5.conf on the clients did the trick; I am able to obtain aan AD TGT ticket by using the KDC proxy Is there a special reason why "use_dns = false" was used in kdcproxy.conf? The current implementation of the DNS configuration feature is slow and reduce performance of KDC proxy requests. Every request has to fetch multiple SRV records and then resolve each entry in each record again. There is neither caching nor async DNS support, too. A co-worker has written a RFC to address the problem. The RFC hasn't been approved yet. https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 Do you need dynamic configuration or can you get by with static configuration in krb5.conf? Christian -- 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 KDC Proxy
"RHEL 6.x libkrb5 has no support for KDC proxy" Too bad, I was afraid for that Winny Op 25-01-16 om 08:36 schreef Alexander Bokovoy: HEL 6.x libkrb5 has no support for KDC proxy -- 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 KDC Proxy
Great,
Changing
/etc/ipa/kdcproxy/kdcproxy.conf
[global]
configs = mit
use_dns = false
to
# cat /etc/ipa/kdcproxy/kdcproxy.conf
[global]
configs = mit
use_dns = true
along with adding the windows realm to krb5.conf on the clients
did the trick; I am able to obtain aan AD TGT ticket by using the
KDC proxy
Is there a special reason why "use_dns = false" was used in
kdcproxy.conf?
Will this work on CentosOS /RHEL 6 as well?
Winny
Op 22-01-16 om 12:05 schreef Christian
Heimes:
On 2016-01-22 11:57, Alexander Bokovoy wrote:
- Original Message -
Hi all,
I configured an IPA client using de FreeIPA 4.2 KDC Proxy something like
this:
~
dns_lookup_realm = false
dns_lookup_kdc = false
~
[realms]
LINUX.EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
http_anchors = FILE:/etc/ipa/ca.crt
kdc = https://ipa1.linux.example.com/KdcProxy
kpasswd_server = https://ipa1.linux.example.com/KdcProxy
}
Now, this seems to work well, I blocked port 88 towards als KDC's, used some
tcpdump and yes: only port 443 towards the IPA server is being used and
kinit will give me a TGT.
However, I do have a trust to a Windows AD-server. I would expect something
like this:
ipa-client cannot access the windows AD server
ipa-server however can
ipa-client will use ipa-server as a KDC proxy and will get a TGT through the
IPA KDC-proxy
Now, of course kinit winu...@windows.example.com will give:
[root@ipa-client7 etc]# kinit winu...@windows.example.com
kinit: Cannot find KDC for realm "WINDOWS.EXAMPLE.COM" while getting initial
credentials
Adding something like this to krb5.conf won't work, still the same error
message:
WINDOWS.BLABLA.BLA = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
http_anchors = FILE:/etc/ipa/ca.crt
kdc = https://ipa1.linux.example.com/KdcProxy
kpasswd_server = https://ipa1.linux.example.com/KdcProxy
}
Now, is it possible to use the IPA-server as a proxy for the trusted Windows
Domain? How...?
You need to have WINDOWS.EXAMPLE.COM definition on the IPA client that points to the KDC proxy
_and_ WINDOWS.EXAMPLE.COM on IPA master should point to AD DCs.
The latter one should not use proxy but rather specify KDCs properly. Alternatively you should have
dns_lookup_kdc = true
For FreeIPA python-kdcproxy has DNS lookup disabled. It only reads
config items from /etc/krb5.conf.
# cat /etc/ipa/kdcproxy/kdcproxy.conf
[global]
configs = mit
use_dns = false
Christian
--
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 KDC Proxy
Hi all,
I configured an IPA client using de FreeIPA 4.2 KDC Proxy
something like this:
~
dns_lookup_realm = false
dns_lookup_kdc = false
~
[realms]
LINUX.EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
http_anchors = FILE:/etc/ipa/ca.crt
kdc = https://ipa1.linux.example.com/KdcProxy
kpasswd_server = https://ipa1.linux.example.com/KdcProxy
}
Now, this seems to work well, I blocked port 88 towards als KDC's,
used some tcpdump and yes: only port 443 towards the IPA server is
being used and kinit will give me a TGT.
However, I do have a trust to a Windows AD-server. I would expect
something like this:
ipa-client cannot access the windows AD server
ipa-server however can
ipa-client will use ipa-server as a KDC proxy and will get a TGT
through the IPA KDC-proxy
Now, of course kinit winu...@windows.example.com will give:
[root@ipa-client7 etc]# kinit winu...@windows.example.com
kinit: Cannot find KDC for realm "WINDOWS.EXAMPLE.COM" while
getting initial credentials
Adding something like this to krb5.conf won't work, still the same
error message:
WINDOWS.BLABLA.BLA = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
http_anchors = FILE:/etc/ipa/ca.crt
kdc = https://ipa1.linux.example.com/KdcProxy
kpasswd_server = https://ipa1.linux.example.com/KdcProxy
}
Now, is it possible to use the IPA-server as a proxy for the
trusted Windows Domain? How...?
Kind regards,
Winny
--
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] AD group members
Hi all, Adding AD-users to an IPA external group seems to be problematic. However, adding AD-groups (with AD-users as members) to a IPA external groups seems to work well. Four group were created and all are shown. Smell a bit like a bug, does't it? Winny Op 15-12-15 om 18:55 schreef Sumit Bose: On Tue, Dec 15, 2015 at 11:38:08AM -0500, Alexander Bokovoy wrote: - Original Message - Hi, If PAC is not being used using key, how is group membership determined? By asking IPA master to give list of groups AD user belongs to. The complexity of this process makes it hard to have full list of groups available in advance in all cases. MS-PAC record in Kerberos ticket has its feature that AD DC will put the correct and full list of groups the user is a member of at the time of issuing TGT, signed by the AD DC's signature. This means after validating the ticket we can trust its content for caching. In case of no PAC data available we have to resort to less precise methods that would give incomplete information for some of situations like incomplete GC content for multidomain AD forests. Also: it feels like the Linux client is contacting AD to obtain a Kerberos ticket and not the IPA-server. (for AD users). Is that true? Yes, how would you imagine doing it differently? AD DCs are authoritative for their users, not IPA KDC. This is basic feature of Kerberos protocol. This is true for getting a TGT for the user, but when it comes to authentication against an IPA client there is a step which involves the IPA KDC as well. Either if you use Kerberos/GSSAPI authentication, e.g. with ssh, or password authentication, in both cases a Kerberos service ticket for the IPA client is needed which is issued by the IPA KDC and here is were the SIDs for IPA group memberships are added. In the ssh case the ssh client will ask the IPA KDC for the service ticket by sending a valid TGT or cross-realm TGT in the trust case. In the password authentication case SSSD will ask for the same service ticket after getting a TGT for the user from the AD DC. This step is called validation because SSSD needs a prove that the TGT was really issued by a valid KDC. A user calling kinit can but pretty sure that the KDC is valid because the password is a shared secret between the user and the KDC in this case. A service like SSSD cannot be sure that the user is not an attacker which spoofed e.g. DNS and let SSSD talk to a invalid KDC which of course will issue TGTs for the attacker. To make sure the ticket is valid SSSD uses the shared secret it has with the valid KDC, the host keys in /etc/krb5.keytab, to validate the TGT by requesting a service ticket for the host itself. If the service ticket can be decrypt with the keys in the keytab SSSD can be pretty sure that the service ticket and hence the TGT are valid. Coming back to the original issue with the missing group. Can you share the definition of the IPA external group and the related IPA POSIX group for a group which is still present and one which got deleted. The output of 'ipa group-show --all --raw group_name' should be sufficient for a start. Feel free to send the output to me directly if it contains sensitive data. bye, Sumit With IPA 4.2 on systems like RHEL 7.2/CentOS 7.2/Fedora 23 you can configure MIT Kerberos to use MS-KKDC proxy provided by IPA. In such case IPA masters can be used as Kerberos proxy but the actual authentication decision is done by AD DCs anyway. -- / Alexander Bokovoy -- 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] AD group members
Hi all, I changed the group names so the alpabetical order changes, no effect. However, sorting the corresponding SID's, the first SID belongs to the group always shown. Mmmm, only the first one is taken and the rest is thrown out...? Cheers! Winny Op 16-12-15 om 10:01 schreef Sumit Bose: On Wed, Dec 16, 2015 at 09:46:37AM +0100, Winfried de Heiden wrote: Hi all, Adding AD-users to an IPA external group seems to be problematic. However, adding AD-groups (with AD-users as members) to a IPA external groups seems to work well. Four group were created and all are shown. Thank you, this is a very useful information, I hope that I will be able to reproduce the issue with this and the data you send me by private email. bye, Sumit Smell a bit like a bug, does't it? Winny -- 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] AD group members
Hi all, OK, using keys no pac responder is used. No, both sssd-1.12 and sssd-1.13 using password login secondary groups are missing. This particular user is member of 3 Posix groups (by using external groups) Only the first one (it seems the first one in alphabetical order) is shown. The ones "thrown out" are the same as show in sssd_pac.log --> is not in the PAC anymore, membership must be removed. Cheers! Winny Op 15-12-15 om 16:19 schreef Sumit Bose: On Tue, Dec 15, 2015 at 03:44:46PM +0100, Winfried de Heiden wrote: Hi all, Even more strange, logging in using SSH public/private keys the problem disappears and all groups are available! Strange.?! this is expected, because if you use SSH keys no PAC is involved and hence the PAC responder cannot remove group-memberships which are not listed in the PAC. RHEL 7.2 with IPA 4.2, sssd 1.13.0-40 last updated Friday December 11 RHEL 7.2 with sssd 1.13.0-40 as an IPA client RHEL 6.7 with sssd 1.12.4-47 as an IPA client Do I understand correctly that with 1.12.4-47 the groups are always correct while with 1.13.0-40 the groups are missing when not using SSH keys? bye, Sumit Winny Op 15-12-15 om 09:59 schreef Sumit Bose: On Mon, Dec 14, 2015 at 05:47:38PM +0100, Winfried de Heiden wrote: Using an EL7 client, lot's of times the IPA (posix) groups are missing, or partly missing. Doing some debugging, sssd_pac.log shows: (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. These sids are the groups I am missing. What is happening here??? Originally the PAC was the only source for the group-membership data for users coming from AD. To be able to be a member of IPA groups the IPA KDC added SIDs of IPA groups the AD user is a member of. With EL7.1 SSSD is able to read group-membership data on its own if the IPA server is running on 7.1 or newer as well. If this is your case it looks like there is a disconnect between how the IPA KDC and SSSD determine the group memberships for the given user. To investigate this issue further it would be nice if you can share some details about your environment, especially which SSSD and IPA versions are used on the client and the server and how the external group membership is defined on the IPA server. bye, Sumit Kind regards, Winny -- 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] AD group members
Hi, If PAC is not being used using key, how is group membership determined? Also: it feels like the Linux client is contacting AD to obtain a Kerberos ticket and not the IPA-server. (for AD users). Is that true? Winny Op 15-12-15 om 16:19 schreef Sumit Bose: On Tue, Dec 15, 2015 at 03:44:46PM +0100, Winfried de Heiden wrote: Hi all, Even more strange, logging in using SSH public/private keys the problem disappears and all groups are available! Strange.?! this is expected, because if you use SSH keys no PAC is involved and hence the PAC responder cannot remove group-memberships which are not listed in the PAC. RHEL 7.2 with IPA 4.2, sssd 1.13.0-40 last updated Friday December 11 RHEL 7.2 with sssd 1.13.0-40 as an IPA client RHEL 6.7 with sssd 1.12.4-47 as an IPA client Do I understand correctly that with 1.12.4-47 the groups are always correct while with 1.13.0-40 the groups are missing when not using SSH keys? bye, Sumit Winny Op 15-12-15 om 09:59 schreef Sumit Bose: On Mon, Dec 14, 2015 at 05:47:38PM +0100, Winfried de Heiden wrote: Using an EL7 client, lot's of times the IPA (posix) groups are missing, or partly missing. Doing some debugging, sssd_pac.log shows: (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. These sids are the groups I am missing. What is happening here??? Originally the PAC was the only source for the group-membership data for users coming from AD. To be able to be a member of IPA groups the IPA KDC added SIDs of IPA groups the AD user is a member of. With EL7.1 SSSD is able to read group-membership data on its own if the IPA server is running on 7.1 or newer as well. If this is your case it looks like there is a disconnect between how the IPA KDC and SSSD determine the group memberships for the given user. To investigate this issue further it would be nice if you can share some details about your environment, especially which SSSD and IPA versions are used on the client and the server and how the external group membership is defined on the IPA server. bye, Sumit Kind regards, Winny -- 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] AD group members
Hi all, Even more strange, logging in using SSH public/private keys the problem disappears and all groups are available! Strange.?! RHEL 7.2 with IPA 4.2, sssd 1.13.0-40 last updated Friday December 11 RHEL 7.2 with sssd 1.13.0-40 as an IPA client RHEL 6.7 with sssd 1.12.4-47 as an IPA client Winny Op 15-12-15 om 09:59 schreef Sumit Bose: On Mon, Dec 14, 2015 at 05:47:38PM +0100, Winfried de Heiden wrote: Using an EL7 client, lot's of times the IPA (posix) groups are missing, or partly missing. Doing some debugging, sssd_pac.log shows: (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. These sids are the groups I am missing. What is happening here??? Originally the PAC was the only source for the group-membership data for users coming from AD. To be able to be a member of IPA groups the IPA KDC added SIDs of IPA groups the AD user is a member of. With EL7.1 SSSD is able to read group-membership data on its own if the IPA server is running on 7.1 or newer as well. If this is your case it looks like there is a disconnect between how the IPA KDC and SSSD determine the group memberships for the given user. To investigate this issue further it would be nice if you can share some details about your environment, especially which SSSD and IPA versions are used on the client and the server and how the external group membership is defined on the IPA server. bye, Sumit Kind regards, Winny -- 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] AD group members
Using an EL7 client, lot's of times the IPA (posix) groups are missing, or partly missing. Doing some debugging, sssd_pac.log shows: (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. These sids are the groups I am missing. What is happening here??? Kind regards, Winny -- 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] Trusted Domain Users - entry_cache_timeout
Hi all, There is no specific AD domain section. AD is used by using a Trust between IPA and AD. Thereś no need for a seperate AD domain section, is there? Kind regards, Winny Op 10-12-15 om 11:25 schreef Martin Kosek: On 12/09/2015 12:58 PM, Winfried de Heiden wrote: Hi all, Using entry_cache_timeout to set different cache timeout for sssd works well. However, it doesn't seem to work for Trusted Domain Users (using AD trust) I made some changes, cleaned the cache but expiry will stay on a (too long) 10 (ten!) hours! How can I change the sssd cache timeout for Trusted AD users ? (using IPA 4.1) Kind regards! I assume the option has to be specified in the respective AD domain section. Can you share your anonymized sssd.conf so that we can verify your settings? -- 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] Trusted Domain Users - entry_cache_timeout
Hi all, Using entry_cache_timeout to set different cache timeout for sssd works well. However, it doesn't seem to work for Trusted Domain Users (using AD trust) I made some changes, cleaned the cache but expiry will stay on a (too long) 10 (ten!) hours! How can I change the sssd cache timeout for Trusted AD users ? (using IPA 4.1) Kind regards! Winny -- 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] compat tree refresh
Hi all, Using a RHEL or Centos 5.11 as a legacy client (using sssd) seems to work. I created an external group which is member of a posix group. Putting an AD user in the external group works, but it seems to take ages beofre it takes effect. Yesterday late, I remove some AD user from some group and did not see any effect only until this morning. What could case this delay? Oh yeah, during the night, IPA is stopped during the back-up... Is this causing the refresh? It is OK to wait some time for group modifications to take effect, that's the price of the sssd-cache but this looks strange and is far too long On both IPA-server and the EL5 client I set "entry_cache_timeout" to 300. Kind regards, Winny -- 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] hbac service allowed despite not listed
Hi all, Running as an ordinary user, straight from the beginning. Is the (default) suid of/usr/bin/su causing this? Anyway: the info requested: /var/log/secure will tell: Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create session: Already running in a session Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened for user root by testuser(uid=10005) De pam.d files are from a clean fresh Fedora23 install and ipa-client-install afterwards: /etc/pam.d/su #%PAM-1.0 auth sufficient pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required pam_wheel.so use_uid auth substack system-auth auth include postlogin account sufficient pam_succeed_if.so uid = 0 use_uid quiet account include system-auth password include system-auth session include system-auth session include postlogin session optional pam_xauth.so /etc/pam.d/postlogin #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp silent session optional pam_lastlog.so silent noupdate showfailed /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Op 24-11-15 om 10:37 schreef Jakub Hrozek: re you running su as an ordinary user or root? What does appear in /var/log/secure when you run su ? Can you show what is the /etc/pam.d/su config and the config of the service that is included from /etc/pam.d/su ? (typically system-auth) -- 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] hbac service allowed despite not listed
Winny Op 23-11-15 om 17:16 schreef Jakub Hrozek: On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote: Hi all, I created some hbac rule on freeipa-server 4.1.4 on Fedora 22 # ipa hbacrule-show testuser Rule name: testuser Enabled: TRUE Users: testuser Hosts: fedora23-server.blabla.bla Services: sshd Hence, " testuser" is only allowed using sshd on "fedora23-server". No surprise, this user is not allowed to use "su": # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service su - Access granted: False (and yeah sshd is allowed) However, doing a "su" on the fedora23-server.blabla.bla, and giving the correct password, access is granted. This user is not a member of any other groups. HBAC Services like cron or console access are denied correctly since they are not in the HBAC service list. I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several other ipa-clients (RHEL/CentoOS 6.x, 7.x) Shouldn't su or su -l be denied when not listed? Yes, and in my testing with a similar rule: $ ipa hbacrule-show allow_sshd Rule name: allow_sshd Enabled: TRUE Users: admin Hosts: client.ipa.test Services: sshd admin can ssh to client.ipa.test but it's not possible to su to admin. Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check /var/log/secure and the sssd logs. Also, you're not calling su as root, are you? -- 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] hbac service allowed despite not listed
Hi all,
The problem is clear, there is a misunderstanding of the service "su"
and "su-l", this is about the target users. Hence; su - to user winfried
is allowed since su and su-l are added to the hbac service list of this
user.
This looks a bit strange from the ui perspective, all other HBAC
services are what this user is allow to do; "su" and "su-l" defines that
OTHER user may become this user by using su.
A bit strange, but this is how is works. Anyone disagree?
Winny
Op 24-11-15 om 14:04 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:
Hi all,
[winfried@ipa ~]$ ipa hbacrule-show allow_all
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
[winfried@ipa ~]$ ipa hbacrule-show testuser
Rule name: testuser
Enabled: TRUE
Users: testuser
Hosts: fedora23-server.blabla.bla
Services: sshd
[winfried@ipa ~]$ ipa user-show winfried
User login: winfried
First name: Winfried
Last name: de Heiden
Home directory: /home/winfried
Login shell: /bin/bash
etc. .etc.
[winfried@ipa ~]$ ipa user-show testuser
User login: testuser
First name: test
Last name: user
Home directory: /home/testuser
Login shell: /bin/bash
Email address: testu...@blabla.bla
UID: 10005
GID: 10005
Account disabled: False
Password: True
Member of groups: ipausers
Member of HBAC rule: testuser
Kerberos keys available: True
[[testuser@fedora23-server ~]$ su winfried
Wachtwoord:
[winfried@fedora23-server testuser]$ id
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),1(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
So yes, I can su to another IPA-user :(
sssd_pam now shows information, but nothing seems to go wrong...
I think you forgot to CC freeipa-users.
In this case, can you look into /var/log/secure again and into the
domain logs?
What's happening?
Winny
Op 24-11-15 om 11:43 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
Anyway: the info requested:
/var/log/secure will tell:
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)
Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
pam_start("su", "root", ...)
pam_authenticate();
So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.
--
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] FreeIPA en Domain Trust
Hi all, For some reason, we only want to use the Active Directory user from an Active Directory using a Trust. (groups like "Domain Users" are of no use...) Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/ Kinds Regards, Winny -- 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] hbac service allowed despite not listed
Hi all, I created some hbac rule on freeipa-server 4.1.4 on Fedora 22 # ipa hbacrule-show testuser Rule name: testuser Enabled: TRUE Users: testuser Hosts: fedora23-server.blabla.bla Services: sshd Hence, " testuser" is only allowed using sshd on "fedora23-server". No surprise, this user is not allowed to use "su": # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service su - Access granted: False (and yeah sshd is allowed) However, doing a "su" on the fedora23-server.blabla.bla, and giving the correct password, access is granted. This user is not a member of any other groups. HBAC Services like cron or console access are denied correctly since they are not in the HBAC service list. I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several other ipa-clients (RHEL/CentoOS 6.x, 7.x) Shouldn't su or su -l be denied when not listed? Kind regards, Winny -- 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] Fwd: Re: FreeIPA en Domain Trust
Hi all, One motivation: the customer demands like this... Also: ignore Windows specific group info which is not important for the Linux domain Also: too much groups! If it's a sssd thing, this might be solved on the IPA-server as well since getting the AD group info is handles by sssd on the IPA-server, right? Anyway: how to handle this issue? Kind regards, Winny Op 23-11-15 om 10:54 schreef Martin Kosek: On 11/23/2015 10:50 AM, Winfried de Heiden wrote: Hi all, For some reason, we only want to use the Active Directory user from an Active Directory using a Trust. (groups like "Domain Users" are of no use...) Is it possible to ignore (hide) ALL groups from a particular Domain (trust)/ Kinds Regards, Winny This looks as a question for the client part (SSSD). I do not fully understand the use case, you want to allow AD user to authenticate to Linux box, but you do not want the Linux box to see any of the AD groups? What is the motivation, if I may ask? -- 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] rest api
Hi all, In order for an external application to communicate with IPA and/or modify on (free)Ipa, we want to use the JSON API. Where can I find documentation how to use this API? Thankz! Winny -- 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] sec_error_reused_issuer_and_serial
Hi all, Playing around with freeipa on Fedora 22 after installing I cannot access the UI. Firefox will tell "sec_error_reused_issuer_and_serial". I allready have an Freeipa (Fedora 21 based) and somewhere there seems to be a conflict in the certificates. After using a different domain name all goes well. I want to test and try a few things on a test Freeipa server using the same domain name. Deleting all certicates in Firefox or even trying a new and clean profile did not help. How can I avoid this conflict? Winfried -- 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] AD-trust and external DNS
Hi all, Creating an AD-trust works nicely. However, for some customers both AD and IPA don't have have DNS "for their own", the use external DNS (Infoblox for example) Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS? Thankz! Winfried -- 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] External DNS
Hi all, One of the nice FreeIPA features is a host will be added to DNS automatically when the client is installed. However, in some situations using an other, external, DNS server is prefered. Now, this is possible but hosts have to added manually to this other DNS-server. Is it possible to handle DNS records by IPA on an external DNS server? Any future plans for this? Kind regards, Winfried -- 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] freeipa-server on Raspberry Pi 2
Hi,
Great, modifying
/usr/lib/python2.7/site-packages/ipalib/constants.py did the
trick! Setting startup_timeout to 600 seconds was enough :)
After setting startup_timeout=600 in /etc/ipa/default.conf
restarting freeipa worked well allthough it takes somewhere
between 5 and 10 minutes
Never mind, it all works now and will try if it is usable on a
small scale @home (a few computers, a hand full of users)
Thankz!
Winfried
Op 07-04-15 om 11:00 schreef Martin
Basti:
I realize the default.conf is
replaced during install, pausing IPA will not help.
The easiest way is modify the source file.
ipalib/constants.py: ('startup_timeout', 300),
The file should be in
/usr/lib/python2.7/site-packages/ipalib/constants.py
Modify file and run ipa-server-install, it should work.
HTH
Martin
On 07/04/15 10:05, Winfried de Heiden wrote:
Hi,
I gave it a try, but neither ~/.ipa/default.conf or
/etc/ipa/default.conf did work. I also tried "to fool" the
ipa-server-install script by pausing it and wait for the CA to
start. After "un-pausing" the script the same error occurs: "CA did not start in 300.0s"
I might try to hack the services.py script but anyone got
another suggestion?
Kind regards,
Winfried
Op 02-04-15 om 13:38 schreef Martin
Basti:
On 02/04/15 12:53, Winfried de
Heiden wrote:
Hi all,
"Because I can try" I gave a shot on installing
freeipa-server on a Raspberry Pi 2. I used Fedora 21 for
this. Installing looks promising, but fails somewhere
halfway:
[8/27]: starting
certificate server instance
[error] RuntimeError: CA did not
start in 300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail
/var/log/ipaserver-install.log
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 229, in start
self.wait_until_running()
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 223, in wait_until_running
raise RuntimeError('CA did not
start in %ss' % timeout)
2015-04-02T09:58:36Z DEBUG The
ipa-server-install command failed, exception:
RuntimeError: CA did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the
Pi2 tends to be slow and no wonder starting things will
takes "some time"... (Yep, I 'm trying to move tons of
stones using only a 2CV car...) The catalina log (that's
the CA (Tomcat) log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deployment of configuration
descriptor
/etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has
finished in 84,815 ms
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8080"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8443"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["ajp-bio-127.0.0.1-8009"]
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.Catalina start
INFO: Server startup
Re: [Freeipa-users] freeipa-server on Raspberry Pi 2
Hi,
I gave it a try, but neither ~/.ipa/default.conf or
/etc/ipa/default.conf did work. I also tried "to fool" the
ipa-server-install script by pausing it and wait for the CA to
start. After "un-pausing" the script the same error occurs: "CA did not start in 300.0s"
I might try to hack the services.py script but anyone got another
suggestion?
Kind regards,
Winfried
Op 02-04-15 om 13:38 schreef Martin
Basti:
On 02/04/15 12:53, Winfried de Heiden
wrote:
Hi all,
"Because I can try" I gave a shot on installing freeipa-server
on a Raspberry Pi 2. I used Fedora 21 for this. Installing
looks promising, but fails somewhere halfway:
[8/27]: starting certificate
server instance
[error] RuntimeError: CA did not start
in 300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail
/var/log/ipaserver-install.log
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 229, in start
self.wait_until_running()
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 223, in wait_until_running
raise RuntimeError('CA did not start
in %ss' % timeout)
2015-04-02T09:58:36Z DEBUG The
ipa-server-install command failed, exception: RuntimeError:
CA did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2
tends to be slow and no wonder starting things will takes
"some time"... (Yep, I 'm trying to move tons of stones using
only a 2CV car...) The catalina log (that's the CA (Tomcat)
log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deployment of configuration
descriptor /etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml
has finished in 84,815 ms
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8080"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8443"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["ajp-bio-127.0.0.1-8009"]
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out
for the CA to start to 10 or 15 minuten? Any other sugestion
what is causing this problem? (no, I am not upgrading from an
older version, this is a fresh install)
Kind regards,
Winfried
Hello,
you can try:
https://www.redhat.com/archives/freeipa-users/2015-April/msg00076.html
--
Martin Basti
--
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] freeipa-server on Raspberry Pi 2
Hi all,
"Because I can try" I gave a shot on installing freeipa-server on
a Raspberry Pi 2. I used Fedora 21 for this. Installing looks
promising, but fails somewhere halfway:
[8/27]: starting certificate
server instance
[error] RuntimeError: CA did not start in
300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail
/var/log/ipaserver-install.log
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 229, in start
self.wait_until_running()
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 223, in wait_until_running
raise RuntimeError('CA did not start in
%ss' % timeout)
2015-04-02T09:58:36Z DEBUG The
ipa-server-install command failed, exception: RuntimeError: CA
did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2
tends to be slow and no wonder starting things will takes "some
time"... (Yep, I 'm trying to move tons of stones using only a 2CV
car...) The catalina log (that's the CA (Tomcat) log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deployment of configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has finished in
84,815 ms
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8080"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8443"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["ajp-bio-127.0.0.1-8009"]
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out for
the CA to start to 10 or 15 minuten? Any other sugestion what is
causing this problem? (no, I am not upgrading from an older
version, this is a fresh install)
Kind regards,
Winfried
--
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
