Re: [Freeipa-users] Extending attributes
And after a bit more hacking around, I seem to have hit on the answer. For one thing, the way I wrote it wouldn't work because the dn_container would have been wrong anyway (previously it worked because users are in the same container as other users, but in this case it would fail since the object's container is that of a host). Some of the values here are hard coded now, which is probably not good practice, but as this is my plugin for my environment I'm going to give myself a break on it. I still need to write an error handler in the case of a user account being deleted and a host "owned" by that user still exists, so that one doesn't have to go to LDAP to deal with the entry, but compared to the amount of iterations this took, that should be easy :D For those interested: http://www.astro.princeton.edu/~huston/astrocustom/astrocustom.1546.py.html -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Account/password expirations
On Tue, Apr 19, 2016 at 11:57 AM, Jakub Hrozek <jhro...@redhat.com> wrote: > Did you test that this actually fails with id_provider=ipa? I would > assume the IPA KDC would kick you out and prompt for a new password.. If you're using a password, yes it kicks back and requires you to change it. The problem is if you're not using a password to authenticate, but instead using an SSH key, then it appears there's no hooks to check with IPA if the password (or the principal itself) is expired and the user is allowed to continue to login. The "recommended" way to do this in RHEL6 is to set access_provider to ldap in sssd, but that doesn't seem to cover all cases and doesn't play well with other IPA things (like HBAC) from what I can tell. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Account/password expirations
Following instructions in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-pwd-expiry.html sort-of works to get this done, but I wonder if there's a better way to do it. My goal is twofold: when users are created, they will be required to have a krbPrincipalExpiration, and they should be denied login if that date has passed; and users should be prompted to change their password if krbPasswordExpiration has passed. It would be beneficial to have warnings printed for at least password expiration, but ideally account expiration, as well. These should be checked and output if the user is using public key authentication as well as passwords and GSSAPI. If I set 'access_provider = ldap' in sssd.conf, it seems to work (also setting ldap_access_order to pwd_expire_policy_renew, and a filter which I've yet to determine, otherwise all logins are rejected anyway). My understanding from https://fedorahosted.org/sssd/ticket/1227 is that HBAC will then fail to work. Will other things, such as disabling the account, also fail? What about password lockouts? Is there a better way to do this, for example one that keeps access_provider set to ipa and consults IPA directly? Of course doesn't help that I need to deal with this across multiple OSs (CentOS 5 using LDAP explicitly, 6 and 7 using sssd) -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Account/password expirations
Unfortunately I've been swapping tasks enough that I keep forgetting where I left off here. But I'm pretty sure the problem was that sssd would stop a user who was disabled (as you mention) but not if they were expired, either the account itself with krbPrincipalExpiration or the password with krbPasswordExpiration. I know that one does not get a ticket automatically if using ssh public key authentication, which is fine, but there's a specific mention in the link I referenced (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-pwd-expiry.html) that basically if you do this, then sssd will consult for password expiration and warn the user accordingly. That's what I need to happen, and would like it to be native IPA-ish calls, rather than LDAP which is what I need to set it to if I want that functionality (which then also causes other problems, such as losing HBAC and having to set a filter I've yet to get right to allow users to login to anything). So if there's a chance of swinging the vote the other way, I'll keep beating my drum :D On Thu, Apr 21, 2016 at 3:37 PM, Jakub Hrozek <jhro...@redhat.com> wrote: > On Thu, Apr 21, 2016 at 01:26:19PM -0400, Steve Huston wrote: >> On Tue, Apr 19, 2016 at 11:57 AM, Jakub Hrozek <jhro...@redhat.com> wrote: >> > Did you test that this actually fails with id_provider=ipa? I would >> > assume the IPA KDC would kick you out and prompt for a new password.. >> >> If you're using a password, yes it kicks back and requires you to >> change it. The problem is if you're not using a password to >> authenticate, but instead using an SSH key, then it appears there's no >> hooks to check with IPA if the password (or the principal itself) is >> expired and the user is allowed to continue to login. The >> "recommended" way to do this in RHEL6 is to set access_provider to >> ldap in sssd, but that doesn't seem to cover all cases and doesn't >> play well with other IPA things (like HBAC) from what I can tell. > > Then in my opinion SSSD is behaving correctly there. It wouldn't let in > a locked user (it would check the nsaccountlock attribute), but I'm not > sure it would be correct to check krbPasswordExpiration if you're using > a completely different method to authenticate.. > > Moreover, if you login through an SSH key, you don't get a ticket on > login and you can't kinit, so you can't access any network resources > anyway.. > > But to be honest, this is something we discussed even among IPA > developers and we're not in total agreement here either, so maybe others > will overrule me :) > > -- > 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 -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Backend & UI plugin update for 4.4.x
Awesome! Thank you. On Wed, Feb 1, 2017 at 12:05 PM, Florence Blanc-Renaud <f...@redhat.com> wrote: > On 02/01/2017 05:47 PM, Steve Huston wrote: >> >> Would it be better to file this as a new bug, or reopen 4291? >> > Hi, > > we are already aware of the problem and working on a fix (please see > https://bugzilla.redhat.com/show_bug.cgi?id=1398600 and > https://fedorahosted.org/freeipa/ticket/6575). > > HTH, > Flo. > > >> On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston >> <hus...@astro.princeton.edu> wrote: >>> >>> Seems like this is to blame: >>> https://fedorahosted.org/freeipa/ticket/4291 >>> >>> The checkin says, "Installation in pure IPv6 environment failed >>> because pki-tomcat tried to use >>> IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 >>> fixes this issue." However it would seem that in a pure IPv4 >>> environment, this is causing tomcat to fail to load. >>> >>> On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston >>> <hus...@astro.princeton.edu> wrote: >>>> >>>> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? >>>> >>>> >>>> >>>> >>> address="::1" /> >>>> >>>> Doesn't work so well on a host without IPv6 turned on... >>>> >>>> Jan 31 14:26:59 ipa server: PKIListener: >>>> org.apache.catalina.core.StandardServer[before_init] >>>> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point >>>> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] >>>> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family >>>> unavailable >>>> >>>> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston >>>> <hus...@astro.princeton.edu> wrote: >>>>> >>>>> Stranger, I did an install on a different VM with the CentOS 7 minimal >>>>> ISO, then installed ipa-server and enough things to get X11 and >>>>> Firefox, ran ipa-server-install and it worked fine. I tested with >>>>> Firefox (and Safari) against my failing installation and it still >>>>> fails. So there's something else different that's causing it to >>>>> break. Will continue investigating, but if someone knows why the UI >>>>> would break this way it would be helpful to know where to look! >>>>> >>>>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >>>>> <hus...@astro.princeton.edu> wrote: >>>>>> >>>>>> Just did it again with the same result. Reinstalled the machine, then >>>>>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>>>>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>>>>> ipa-server-install as I used before, only without --mkhomedir this >>>>>> time. After entering the passwords for directory administrator and >>>>>> the admin user, I then logged in to the web interface, immediately >>>>>> clicked "add" and added a user 'foobar'. When I clicked "add and >>>>>> edit" and was brought to the user information page, it looks like this >>>>>> at the bottom: >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>>>>> >>>>>> I then entered an employee number of '0001' just to give something to >>>>>> save, and clicked save. The screen now shows this (I've clicked the >>>>>> drop-down on the manager field so the choices are visible): >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>>>>> >>>>>> Holding shift and clicking reload, the page now looks like this (the >>>>>> employee number field is also blank again): >>>>>> >>>>>> >>>>>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>>>>> >>>>>> Since we do run a repackaged distribution here (Springdale Linux), I >>>>>> just unpacked ipa-server-common from our repository with the above >>>>>> version, and >>>>>> http://mirror.centos.org/centos/7/updates
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
Would it be better to file this as a new bug, or reopen 4291? On Tue, Jan 31, 2017 at 5:00 PM, Steve Huston <hus...@astro.princeton.edu> wrote: > Seems like this is to blame: https://fedorahosted.org/freeipa/ticket/4291 > > The checkin says, "Installation in pure IPv6 environment failed > because pki-tomcat tried to use > IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 > fixes this issue." However it would seem that in a pure IPv4 > environment, this is causing tomcat to fail to load. > > On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston > <hus...@astro.princeton.edu> wrote: >> What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? >> >> >> >> > address="::1" /> >> >> Doesn't work so well on a host without IPv6 turned on... >> >> Jan 31 14:26:59 ipa server: PKIListener: >> org.apache.catalina.core.StandardServer[before_init] >> Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point >> associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] >> Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family >> unavailable >> >> On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston >> <hus...@astro.princeton.edu> wrote: >>> Stranger, I did an install on a different VM with the CentOS 7 minimal >>> ISO, then installed ipa-server and enough things to get X11 and >>> Firefox, ran ipa-server-install and it worked fine. I tested with >>> Firefox (and Safari) against my failing installation and it still >>> fails. So there's something else different that's causing it to >>> break. Will continue investigating, but if someone knows why the UI >>> would break this way it would be helpful to know where to look! >>> >>> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >>> <hus...@astro.princeton.edu> wrote: >>>> Just did it again with the same result. Reinstalled the machine, then >>>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>>> ipa-server-install as I used before, only without --mkhomedir this >>>> time. After entering the passwords for directory administrator and >>>> the admin user, I then logged in to the web interface, immediately >>>> clicked "add" and added a user 'foobar'. When I clicked "add and >>>> edit" and was brought to the user information page, it looks like this >>>> at the bottom: >>>> >>>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>>> >>>> I then entered an employee number of '0001' just to give something to >>>> save, and clicked save. The screen now shows this (I've clicked the >>>> drop-down on the manager field so the choices are visible): >>>> >>>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>>> >>>> Holding shift and clicking reload, the page now looks like this (the >>>> employee number field is also blank again): >>>> >>>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>>> >>>> Since we do run a repackaged distribution here (Springdale Linux), I >>>> just unpacked ipa-server-common from our repository with the above >>>> version, and >>>> http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >>>> and 'diff' found zero differences between them. Unlikely, but I >>>> wanted to rule out a packaging error causing the problem. >>>> >>>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >>>> <hus...@astro.princeton.edu> wrote: >>>>> No, that should be all of the major changes; the puppet module that >>>>> installs things only puts the two plugin files in their respective >>>>> places. The client part of the IPA module makes changes to have the >>>>> machine join the domain and whatnot, but those shouldn't affect the >>>>> webui. >>>>> >>>>> I do modify the schema by adding some attribute types for Puppet, >>>>> namely puppetClass, parentNode, environment, puppetVar, and the object >>>>> class puppetClient. That's basically right from one of the Puppet >>>>> webpages and also worked in the past - and is one of the thin
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? Doesn't work so well on a host without IPv6 turned on... Jan 31 14:26:59 ipa server: PKIListener: org.apache.catalina.core.StandardServer[before_init] Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family unavailable On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston <hus...@astro.princeton.edu> wrote: > Stranger, I did an install on a different VM with the CentOS 7 minimal > ISO, then installed ipa-server and enough things to get X11 and > Firefox, ran ipa-server-install and it worked fine. I tested with > Firefox (and Safari) against my failing installation and it still > fails. So there's something else different that's causing it to > break. Will continue investigating, but if someone knows why the UI > would break this way it would be helpful to know where to look! > > On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston > <hus...@astro.princeton.edu> wrote: >> Just did it again with the same result. Reinstalled the machine, then >> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >> ipa-server-install as I used before, only without --mkhomedir this >> time. After entering the passwords for directory administrator and >> the admin user, I then logged in to the web interface, immediately >> clicked "add" and added a user 'foobar'. When I clicked "add and >> edit" and was brought to the user information page, it looks like this >> at the bottom: >> >> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >> >> I then entered an employee number of '0001' just to give something to >> save, and clicked save. The screen now shows this (I've clicked the >> drop-down on the manager field so the choices are visible): >> >> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >> >> Holding shift and clicking reload, the page now looks like this (the >> employee number field is also blank again): >> >> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >> >> Since we do run a repackaged distribution here (Springdale Linux), I >> just unpacked ipa-server-common from our repository with the above >> version, and >> http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >> and 'diff' found zero differences between them. Unlikely, but I >> wanted to rule out a packaging error causing the problem. >> >> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >> <hus...@astro.princeton.edu> wrote: >>> No, that should be all of the major changes; the puppet module that >>> installs things only puts the two plugin files in their respective >>> places. The client part of the IPA module makes changes to have the >>> machine join the domain and whatnot, but those shouldn't affect the >>> webui. >>> >>> I do modify the schema by adding some attribute types for Puppet, >>> namely puppetClass, parentNode, environment, puppetVar, and the object >>> class puppetClient. That's basically right from one of the Puppet >>> webpages and also worked in the past - and is one of the things the >>> python plugin does, add the appropriate objectclass to host entries if >>> puppetVar is added to a host entry. >>> >>> My steps to install: >>> * ipa-server-install --realm= --domain= --mkhomedir >>> --hostname= --no-host-dns >>> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >>> < paste puppet schema changes> >>> < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a >>> service account used by puppet for adding hosts to IPA > >>> * login to web UI >>> * * Change home directory base, default shell, default SELinux user >>> * * Add SELinux user map for staff/sysadmin users >>> * * Add "user adder" permission/privilege/role for users who will be >>> able to create stageusers >>> >>> That's about as far as I got before I realized some of the plugin >>> pieces weren't working, and then fixed the python plugin followed by >>> working on the UI plugin and finding this problem. I'll go wipe and >>> reinstall the system again and walk through the steps, but test the UI >>> first and in between to
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
Seems like this is to blame: https://fedorahosted.org/freeipa/ticket/4291 The checkin says, "Installation in pure IPv6 environment failed because pki-tomcat tried to use IPv4 loopback. Configuring tomcat to use IPv6 loopback instead of IPv4 fixes this issue." However it would seem that in a pure IPv4 environment, this is causing tomcat to fail to load. On Tue, Jan 31, 2017 at 4:36 PM, Steve Huston <hus...@astro.princeton.edu> wrote: > What defines the contents of /var/lib/pki/pki-tomcat/conf/server.xml? > > > > address="::1" /> > > Doesn't work so well on a host without IPv6 turned on... > > Jan 31 14:26:59 ipa server: PKIListener: > org.apache.catalina.core.StandardServer[before_init] > Jan 31 14:27:00 ipa server: SEVERE: Failed to initialize end point > associated with ProtocolHandler ["ajp-bio-0:0:0:0:0:0:0:1-8009"] > Jan 31 14:27:00 ipa server: java.net.SocketException: Protocol family > unavailable > > On Fri, Jan 27, 2017 at 4:23 PM, Steve Huston > <hus...@astro.princeton.edu> wrote: >> Stranger, I did an install on a different VM with the CentOS 7 minimal >> ISO, then installed ipa-server and enough things to get X11 and >> Firefox, ran ipa-server-install and it worked fine. I tested with >> Firefox (and Safari) against my failing installation and it still >> fails. So there's something else different that's causing it to >> break. Will continue investigating, but if someone knows why the UI >> would break this way it would be helpful to know where to look! >> >> On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston >> <hus...@astro.princeton.edu> wrote: >>> Just did it again with the same result. Reinstalled the machine, then >>> did a 'yum install ipa-server python2-ipaserver httpd' which pulled in >>> version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the >>> ipa-server-install as I used before, only without --mkhomedir this >>> time. After entering the passwords for directory administrator and >>> the admin user, I then logged in to the web interface, immediately >>> clicked "add" and added a user 'foobar'. When I clicked "add and >>> edit" and was brought to the user information page, it looks like this >>> at the bottom: >>> >>> https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 >>> >>> I then entered an employee number of '0001' just to give something to >>> save, and clicked save. The screen now shows this (I've clicked the >>> drop-down on the manager field so the choices are visible): >>> >>> https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 >>> >>> Holding shift and clicking reload, the page now looks like this (the >>> employee number field is also blank again): >>> >>> https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 >>> >>> Since we do run a repackaged distribution here (Springdale Linux), I >>> just unpacked ipa-server-common from our repository with the above >>> version, and >>> http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, >>> and 'diff' found zero differences between them. Unlikely, but I >>> wanted to rule out a packaging error causing the problem. >>> >>> On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston >>> <hus...@astro.princeton.edu> wrote: >>>> No, that should be all of the major changes; the puppet module that >>>> installs things only puts the two plugin files in their respective >>>> places. The client part of the IPA module makes changes to have the >>>> machine join the domain and whatnot, but those shouldn't affect the >>>> webui. >>>> >>>> I do modify the schema by adding some attribute types for Puppet, >>>> namely puppetClass, parentNode, environment, puppetVar, and the object >>>> class puppetClient. That's basically right from one of the Puppet >>>> webpages and also worked in the past - and is one of the things the >>>> python plugin does, add the appropriate objectclass to host entries if >>>> puppetVar is added to a host entry. >>>> >>>> My steps to install: >>>> * ipa-server-install --realm= --domain= --mkhomedir >>>> --hostname= --no-host-dns >>>> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >>>> < paste puppet schema changes> >>>> < past
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
Just tested again, and this is still baffling:
* Create a stage user with the right data, works fine, can be edited.
* Enable that user, and now the two fields ('manager' and
'employeeType') appear to have bogus data in the UI, and I cannot save
the page without changing them to something else.
* Once that user is saved, the "Employee Information" facet moves to
the right side of the page, and now shows not only the current data in
the manager drop down but also the other choices (uids). Change the
value of manager and employeetype back to what they were previously
and it saves.
* An ldapsearch run when the user is first created (as the directory
manager), and after having two edits (one to change the values to
something else to let the webui save them, and one to change them back
to what they should be and were the first time) produce completely
identical results.
* The output of "ipa user-show --all --raw" is also identical at
those same steps.
So something, somewhere, is being saved in a way that prevents the
webui from displaying them properly, that gets fixed when those values
are manually changed via the webui.
On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
<hus...@astro.princeton.edu> wrote:
> Even more interesting...
>
> I tried to modify one of the records that was not displaying properly
> in the "active users" group, and sure enough the webui complained that
> the "Requested By" (relabeled "manager") field was not filled in since
> it was blank. It also, however, complained that the "User tier"
> (relabeled "employeetype") was incorrect, even though it showed the
> label associated with the value 1. I clicked the search drop-down for
> manager, typed in my own uid, and even though everything had been
> blank in the drop down before now my uid showed up. I clicked on it,
> and my uid was now in the manager field. I then clicked the drop down
> for employeetype, and chose one of the other options. I was now able
> to save the changes to the record.
>
> Upon reloading the page, the "Employee Information" facet now shoed up
> on the right side bottom, instead of the left side bottom where it was
> appearing. I was also now able to change the drop-down fields for
> manager and employeetype to another value, and save them, and they
> worked fine even filling in all the data that should have been there.
> This almost seemed like the data being returned by the server was
> flawed somehow, and confusing the webui, but once it was forced to
> have the right data and re-saved it worked fine subsequently.
>
> I looked at the output of "ipa user-show --all --raw" both
> before and after making such changes on a user, and can detect no
> difference between them.
>
> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy <aboko...@redhat.com>
> wrote:
>> On to, 19 tammi 2017, Steve Huston wrote:
>>>
>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy <aboko...@redhat.com>
>>> wrote:
>>>>
>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client
>>>> side plugins into different paths (ipaserver/plugins and
>>>> ipaclient/plugins instead of being common in ipalib/plugins). The client
>>>> code was also changed to always read metadata about API from the server
>>>> side. This means the client can adopt to any server version that
>>>> supports API metadata.
>>>
>>>
>>> Right, and I think that the most of the plugin I had belongs
>>> server-side; in fact, that's where I migrated it to, and things work
>>> fine. I haven't tested if I can change those values with the cli, but
>>> I'm less concerned about that at the moment.
>>>
>>>> In my sample external plugin you referenced above you can see that I
>>>> have client-side change that replaces an input string by a file
>>>> reference so that a file can supplied instead of typing the content of
>>>> the file on the command line. This is one of most used patterns for
>>>> client side plugins.
>>>
>>>
>>> In this case, my biggest problem is with the web UI. The 'manager'
>>> drop down (which I have renamed through the UI plugins to "Requested
>>> By" to show what user requested and is responsible for this account)
>>> works fine in the 'add/modify stageuser' context, but not at all in
>>> the adduser/moduser context, and I can't seem to find out why.
>>
>> I'll defer answer for this to our web UI wizards but they would need to
>> see your code to help, I'd guess.
>>
>> --
>> / Alexander Bokovoy
>
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
And now I'm convinced this has nothing to do with my plugin and
instead is a bug somewhere in FreeIPA.
I removed the entirety of the "astrocustom" plugin that I wrote,
restarted httpd, and force reloaded the page in chrome. I clicked to
add a new user, gave the basic information, and clicked "add and
edit". The bottom of the page shows the "Employee information" on the
left side bottom, and the manager drop-down is empty. I entered '1'
in the "employee type" field and clicked save, and now "Employee
Information" is on the right side directly under "Contact settings",
and the manager drop-down is populated with the list of UIDs on the
system.
When the UI is in the failed state, the "email address" field is also
blank, but when things switch to how they should be (after submitting
a change) it is populated with the email address in the record. I
just tested by adding a telephone number to the record, and that also
made the contact information and employee information facets refresh
with the proper data. Pressing shift-reload again makes all the
information disappear (including the telephone number I just entered).
This is with ipa-server-4.4.0-14.el7_3.4
On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
<hus...@astro.princeton.edu> wrote:
> Just tested again, and this is still baffling:
>
> * Create a stage user with the right data, works fine, can be edited.
> * Enable that user, and now the two fields ('manager' and
> 'employeeType') appear to have bogus data in the UI, and I cannot save
> the page without changing them to something else.
> * Once that user is saved, the "Employee Information" facet moves to
> the right side of the page, and now shows not only the current data in
> the manager drop down but also the other choices (uids). Change the
> value of manager and employeetype back to what they were previously
> and it saves.
> * An ldapsearch run when the user is first created (as the directory
> manager), and after having two edits (one to change the values to
> something else to let the webui save them, and one to change them back
> to what they should be and were the first time) produce completely
> identical results.
> * The output of "ipa user-show --all --raw" is also identical at
> those same steps.
>
> So something, somewhere, is being saved in a way that prevents the
> webui from displaying them properly, that gets fixed when those values
> are manually changed via the webui.
>
> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
> <hus...@astro.princeton.edu> wrote:
>> Even more interesting...
>>
>> I tried to modify one of the records that was not displaying properly
>> in the "active users" group, and sure enough the webui complained that
>> the "Requested By" (relabeled "manager") field was not filled in since
>> it was blank. It also, however, complained that the "User tier"
>> (relabeled "employeetype") was incorrect, even though it showed the
>> label associated with the value 1. I clicked the search drop-down for
>> manager, typed in my own uid, and even though everything had been
>> blank in the drop down before now my uid showed up. I clicked on it,
>> and my uid was now in the manager field. I then clicked the drop down
>> for employeetype, and chose one of the other options. I was now able
>> to save the changes to the record.
>>
>> Upon reloading the page, the "Employee Information" facet now shoed up
>> on the right side bottom, instead of the left side bottom where it was
>> appearing. I was also now able to change the drop-down fields for
>> manager and employeetype to another value, and save them, and they
>> worked fine even filling in all the data that should have been there.
>> This almost seemed like the data being returned by the server was
>> flawed somehow, and confusing the webui, but once it was forced to
>> have the right data and re-saved it worked fine subsequently.
>>
>> I looked at the output of "ipa user-show --all --raw" both
>> before and after making such changes on a user, and can detect no
>> difference between them.
>>
>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy <aboko...@redhat.com>
>> wrote:
>>> On to, 19 tammi 2017, Steve Huston wrote:
>>>>
>>>> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy <aboko...@redhat.com>
>>>> wrote:
>>>>>
>>>>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client
>>>>> side plugins into different paths (ipaserver/plugins and
>>>>> ipaclient/plugins
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
Just did it again with the same result. Reinstalled the machine, then did a 'yum install ipa-server python2-ipaserver httpd' which pulled in version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the ipa-server-install as I used before, only without --mkhomedir this time. After entering the passwords for directory administrator and the admin user, I then logged in to the web interface, immediately clicked "add" and added a user 'foobar'. When I clicked "add and edit" and was brought to the user information page, it looks like this at the bottom: https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 I then entered an employee number of '0001' just to give something to save, and clicked save. The screen now shows this (I've clicked the drop-down on the manager field so the choices are visible): https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 Holding shift and clicking reload, the page now looks like this (the employee number field is also blank again): https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 Since we do run a repackaged distribution here (Springdale Linux), I just unpacked ipa-server-common from our repository with the above version, and http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, and 'diff' found zero differences between them. Unlikely, but I wanted to rule out a packaging error causing the problem. On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston <hus...@astro.princeton.edu> wrote: > No, that should be all of the major changes; the puppet module that > installs things only puts the two plugin files in their respective > places. The client part of the IPA module makes changes to have the > machine join the domain and whatnot, but those shouldn't affect the > webui. > > I do modify the schema by adding some attribute types for Puppet, > namely puppetClass, parentNode, environment, puppetVar, and the object > class puppetClient. That's basically right from one of the Puppet > webpages and also worked in the past - and is one of the things the > python plugin does, add the appropriate objectclass to host entries if > puppetVar is added to a host entry. > > My steps to install: > * ipa-server-install --realm= --domain= --mkhomedir > --hostname= --no-host-dns > * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W > < paste puppet schema changes> > < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a > service account used by puppet for adding hosts to IPA > > * login to web UI > * * Change home directory base, default shell, default SELinux user > * * Add SELinux user map for staff/sysadmin users > * * Add "user adder" permission/privilege/role for users who will be > able to create stageusers > > That's about as far as I got before I realized some of the plugin > pieces weren't working, and then fixed the python plugin followed by > working on the UI plugin and finding this problem. I'll go wipe and > reinstall the system again and walk through the steps, but test the UI > first and in between to see if I can find which of the steps might be > causing things to hiccup. > > On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka <pvoma...@redhat.com> wrote: >> Hello Steve, >> >> I tried to reproduce what you described on the very same version of >> ipa-server and I was not successful. Actually I was not used your back-end >> plugin. I tried it with no plugin and then with your UI plugin and both >> worked correctly. Did you do any other changes somewhere in your >> installation? >> >> I will try it again also with your Python plugin and we'll see. >> >> >> On 01/24/2017 08:59 PM, Steve Huston wrote: >>> >>> And now I'm convinced this has nothing to do with my plugin and >>> instead is a bug somewhere in FreeIPA. >>> >>> I removed the entirety of the "astrocustom" plugin that I wrote, >>> restarted httpd, and force reloaded the page in chrome. I clicked to >>> add a new user, gave the basic information, and clicked "add and >>> edit". The bottom of the page shows the "Employee information" on the >>> left side bottom, and the manager drop-down is empty. I entered '1' >>> in the "employee type" field and clicked save, and now "Employee >>> Information" is on the right side directly under "Contact settings", >>> and the manager drop-down is populated with the list of UIDs on the >>> system. >>> >>> When the UI is in the failed state, the "email address" field is also
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
Stranger, I did an install on a different VM with the CentOS 7 minimal ISO, then installed ipa-server and enough things to get X11 and Firefox, ran ipa-server-install and it worked fine. I tested with Firefox (and Safari) against my failing installation and it still fails. So there's something else different that's causing it to break. Will continue investigating, but if someone knows why the UI would break this way it would be helpful to know where to look! On Thu, Jan 26, 2017 at 11:53 AM, Steve Huston <hus...@astro.princeton.edu> wrote: > Just did it again with the same result. Reinstalled the machine, then > did a 'yum install ipa-server python2-ipaserver httpd' which pulled in > version 4.4.0-14.el7_3.4 and a bunch of other packages. Next was the > ipa-server-install as I used before, only without --mkhomedir this > time. After entering the passwords for directory administrator and > the admin user, I then logged in to the web interface, immediately > clicked "add" and added a user 'foobar'. When I clicked "add and > edit" and was brought to the user information page, it looks like this > at the bottom: > > https://www.dropbox.com/s/e67j8rdaq9wvkni/Screenshot%202017-01-26%2011.33.03.png?dl=0 > > I then entered an employee number of '0001' just to give something to > save, and clicked save. The screen now shows this (I've clicked the > drop-down on the manager field so the choices are visible): > > https://www.dropbox.com/s/oxmqwf2rsz15grd/Screenshot%202017-01-26%2011.33.58.png?dl=0 > > Holding shift and clicking reload, the page now looks like this (the > employee number field is also blank again): > > https://www.dropbox.com/s/f8ptycnetvsxjnb/Screenshot%202017-01-26%2011.35.03.png?dl=0 > > Since we do run a repackaged distribution here (Springdale Linux), I > just unpacked ipa-server-common from our repository with the above > version, and > http://mirror.centos.org/centos/7/updates/x86_64/Packages/ipa-server-common-4.4.0-14.el7.centos.4.noarch.rpm, > and 'diff' found zero differences between them. Unlikely, but I > wanted to rule out a packaging error causing the problem. > > On Wed, Jan 25, 2017 at 4:12 PM, Steve Huston > <hus...@astro.princeton.edu> wrote: >> No, that should be all of the major changes; the puppet module that >> installs things only puts the two plugin files in their respective >> places. The client part of the IPA module makes changes to have the >> machine join the domain and whatnot, but those shouldn't affect the >> webui. >> >> I do modify the schema by adding some attribute types for Puppet, >> namely puppetClass, parentNode, environment, puppetVar, and the object >> class puppetClient. That's basically right from one of the Puppet >> webpages and also worked in the past - and is one of the things the >> python plugin does, add the appropriate objectclass to host entries if >> puppetVar is added to a host entry. >> >> My steps to install: >> * ipa-server-install --realm= --domain= --mkhomedir >> --hostname= --no-host-dns >> * ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W >> < paste puppet schema changes> >> < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a >> service account used by puppet for adding hosts to IPA > >> * login to web UI >> * * Change home directory base, default shell, default SELinux user >> * * Add SELinux user map for staff/sysadmin users >> * * Add "user adder" permission/privilege/role for users who will be >> able to create stageusers >> >> That's about as far as I got before I realized some of the plugin >> pieces weren't working, and then fixed the python plugin followed by >> working on the UI plugin and finding this problem. I'll go wipe and >> reinstall the system again and walk through the steps, but test the UI >> first and in between to see if I can find which of the steps might be >> causing things to hiccup. >> >> On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka <pvoma...@redhat.com> wrote: >>> Hello Steve, >>> >>> I tried to reproduce what you described on the very same version of >>> ipa-server and I was not successful. Actually I was not used your back-end >>> plugin. I tried it with no plugin and then with your UI plugin and both >>> worked correctly. Did you do any other changes somewhere in your >>> installation? >>> >>> I will try it again also with your Python plugin and we'll see. >>> >>> >>> On 01/24/2017 08:59 PM, Steve Huston wrote: >>>> >>>> And now I'm convinced this has nothing to do with my pl
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
No, that should be all of the major changes; the puppet module that
installs things only puts the two plugin files in their respective
places. The client part of the IPA module makes changes to have the
machine join the domain and whatnot, but those shouldn't affect the
webui.
I do modify the schema by adding some attribute types for Puppet,
namely puppetClass, parentNode, environment, puppetVar, and the object
class puppetClient. That's basically right from one of the Puppet
webpages and also worked in the past - and is one of the things the
python plugin does, add the appropriate objectclass to host entries if
puppetVar is added to a host entry.
My steps to install:
* ipa-server-install --realm= --domain= --mkhomedir
--hostname= --no-host-dns
* ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W
< paste puppet schema changes>
< paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a
service account used by puppet for adding hosts to IPA >
* login to web UI
* * Change home directory base, default shell, default SELinux user
* * Add SELinux user map for staff/sysadmin users
* * Add "user adder" permission/privilege/role for users who will be
able to create stageusers
That's about as far as I got before I realized some of the plugin
pieces weren't working, and then fixed the python plugin followed by
working on the UI plugin and finding this problem. I'll go wipe and
reinstall the system again and walk through the steps, but test the UI
first and in between to see if I can find which of the steps might be
causing things to hiccup.
On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka <pvoma...@redhat.com> wrote:
> Hello Steve,
>
> I tried to reproduce what you described on the very same version of
> ipa-server and I was not successful. Actually I was not used your back-end
> plugin. I tried it with no plugin and then with your UI plugin and both
> worked correctly. Did you do any other changes somewhere in your
> installation?
>
> I will try it again also with your Python plugin and we'll see.
>
>
> On 01/24/2017 08:59 PM, Steve Huston wrote:
>>
>> And now I'm convinced this has nothing to do with my plugin and
>> instead is a bug somewhere in FreeIPA.
>>
>> I removed the entirety of the "astrocustom" plugin that I wrote,
>> restarted httpd, and force reloaded the page in chrome. I clicked to
>> add a new user, gave the basic information, and clicked "add and
>> edit". The bottom of the page shows the "Employee information" on the
>> left side bottom, and the manager drop-down is empty. I entered '1'
>> in the "employee type" field and clicked save, and now "Employee
>> Information" is on the right side directly under "Contact settings",
>> and the manager drop-down is populated with the list of UIDs on the
>> system.
>>
>> When the UI is in the failed state, the "email address" field is also
>> blank, but when things switch to how they should be (after submitting
>> a change) it is populated with the email address in the record. I
>> just tested by adding a telephone number to the record, and that also
>> made the contact information and employee information facets refresh
>> with the proper data. Pressing shift-reload again makes all the
>> information disappear (including the telephone number I just entered).
>>
>> This is with ipa-server-4.4.0-14.el7_3.4
>>
>>
>> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
>> <hus...@astro.princeton.edu> wrote:
>>>
>>> Just tested again, and this is still baffling:
>>>
>>> * Create a stage user with the right data, works fine, can be edited.
>>> * Enable that user, and now the two fields ('manager' and
>>> 'employeeType') appear to have bogus data in the UI, and I cannot save
>>> the page without changing them to something else.
>>> * Once that user is saved, the "Employee Information" facet moves to
>>> the right side of the page, and now shows not only the current data in
>>> the manager drop down but also the other choices (uids). Change the
>>> value of manager and employeetype back to what they were previously
>>> and it saves.
>>> * An ldapsearch run when the user is first created (as the directory
>>> manager), and after having two edits (one to change the values to
>>> something else to let the webui save them, and one to change them back
>>> to what they should be and were the first time) produce completely
>>> identical results.
>>> * The output of "ipa user-show --all --raw" is also identical at
>>> those same steps.
>>>
>>>
Re: [Freeipa-users] New install, unsupported format?
I already had to do that previously to get other things to work; I had solved it by changing line 582 of /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from "::1" to "localhost" before installing the server. I did do this on the to-be-promoted client as well, to no avail. On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden <rcrit...@redhat.com> wrote: > Steve Huston wrote: >> Next stage of my testing was to make a replica of the FreeIPA server, >> and I started by doing a 'yum install ipa-server' and then moved on to >> adding the host to the ipaservers group. This fails every time >> however, with the error: >> >> ipa: ERROR: cannot connect to >> 'https://ipa.astro.princeton.edu/ipa/json': >> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, >> unsupported format. >> >> Searches on this seem to turn up things like expired certificates, or >> "reboot httpd" (I went ahead and rebooted the whole ipa server), but >> nothing concrete. Suggestions? Everything (server and soon-to-be >> replica) running RHEL7.3 with all updates. >> > > See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9 > > rob -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] New install, unsupported format?
Next stage of my testing was to make a replica of the FreeIPA server, and I started by doing a 'yum install ipa-server' and then moved on to adding the host to the ipaservers group. This fails every time however, with the error: ipa: ERROR: cannot connect to 'https://ipa.astro.princeton.edu/ipa/json': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. Searches on this seem to turn up things like expired certificates, or "reboot httpd" (I went ahead and rebooted the whole ipa server), but nothing concrete. Suggestions? Everything (server and soon-to-be replica) running RHEL7.3 with all updates. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] New install, unsupported format?
On Fri, Feb 24, 2017 at 2:31 AM, Standa Laznicka <slazn...@redhat.com> wrote: > Hello, > I don't quite understand your situation - have the error happened during an > addition of the host to the "ipaservers" group or during replica > installation? It was during the addition of the host. In fact, any 'ipa' command fails with the same error, even 'ipa help'. I could understand if the CA needs to be setup before these commands work, but then I'm pretty sure I followed the order of the instructions for creating a replica and this was the result. Interestingly, when I first started to do this, I had other failures related to the directory level. I later realized that it's because I was trying to create the replica on the test VM that I hadn't yet upgraded from RHEL6 to RHEL7 so was trying to use IPA 3.x. In that instance, the command to add the soon-to-be replica to ipaservers succeeded, but the command to create the replica failed with needing the replica file (which I later realized what was going on and reinstalled the VM as I intended originally). > Certutil is a wonderful piece of software that returns > "(SEC_ERROR_LEGACY_DATABASE)" in about 90% of most common cases but I have > never seen an actual legacy database. Usually, this error means that the > directory you're pointing the certutil tool to either does not exist or you > don't have the permissions to read/write in this exact directory. Everything else on the server seems to be working fine, and the error containing the URL to the running server leads me to believe it's a problem with communication between the two. However there is no firewalling on either host (yet) so I'm not sure why they wouldn't be able to communicate. I did run an strace of the process and didn't see anything highly useful, in fact the only connect syscall I saw was to the socket of the local nscd. Debug output of 'ipa -d help': ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:ad...@astro.princeton.edu ipa: DEBUG: Process finished, return code=1 ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'ad...@astro.princeton.edu' ipa: INFO: trying https://ipa.astro.princeton.edu/ipa/json ipa: DEBUG: Created connection context.rpcclient_49093200 ipa: INFO: Forwarding 'schema' to json server 'https://ipa.astro.princeton.edu/ipa/json' ipa: DEBUG: NSSConnection init ipa.astro.princeton.edu ipa: DEBUG: Destroyed connection context.rpcclient_49093200 ipa: ERROR: cannot connect to 'https://ipa.astro.princeton.edu/ipa/json': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. > Cheers, > Standa > > P.S.: I might have sent you this email twice because I am a bad person when > it comes to the "Send" button, please reply to the email which has > "freeipa-users" in CC :) No worries :D > On 02/23/2017 10:38 PM, Steve Huston wrote: >> >> I already had to do that previously to get other things to work; I had >> solved it by changing line 582 of >> /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from >> "::1" to "localhost" before installing the server. I did do this on >> the to-be-promoted client as well, to no avail. >> >> On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden <rcrit...@redhat.com> >> wrote: >>> >>> Steve Huston wrote: >>>> >>>> Next stage of my testing was to make a replica of the FreeIPA server, >>>> and I started by doing a 'yum install ipa-server' and then moved on to >>>> adding the host to the ipaservers group. This fails every time >>>> however, with the error: >>>> >>>> ipa: ERROR: cannot connect to >>>> 'https://ipa.astro.princeton.edu/ipa/json': >>>> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, >>>> unsupported format. >>>> >>>> Searches on this seem to turn up things like expired certificates, or >>>> "reboot httpd" (I went ahead and rebooted the whole ipa server), but >>>> nothing concrete. Suggestions? Everything (server and soon-to-be >>>> replica) running RHEL7.3 with all updates. >>>> >>> See the workaround in >>> https://fedorahosted.org/freeipa/ticket/6575#comment:9 >>> >>> rob >> >> >> > -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] New install, unsupported format?
unner
self._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 449, in _handle_exception
self.__parent._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 446, in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 394, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 362, in __runner
step()
File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
line 359, in
step = lambda: next(self.__gen)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python2.7/site-packages/ipapython/install/common.py",
line 63, in _install
for nothing in self._installer(self.parent):
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 1712, in main
promote_check(self)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 364, in decorated
func(installer)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 386, in decorated
func(installer)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 1004, in promote_check
ensure_enrolled(installer)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
line 958, in ensure_enrolled
sys.exit("Configuration of client side components failed!")
ipa.ipapython.install.cli.install_tool(Replica): DEBUGThe
ipa-replica-install command failed, exception: SystemExit:
Configuration of client side components failed!
ipa.ipapython.install.cli.install_tool(Replica): ERROR
Configuration of client side components failed!
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
Looks like it's unenrolling the machine, then trying to enroll it
again? I also tried again with --server, --realm, --hostname, and
--domain options set appropriately but it made no difference.
--
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
Princeton University |ICBM Address: 40.346344 -74.652242
345 Lewis Library |"On my ship, the Rocinante, wheeling through
Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1'
--
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] Backend & UI plugin update for 4.4.x
Even more interesting... I tried to modify one of the records that was not displaying properly in the "active users" group, and sure enough the webui complained that the "Requested By" (relabeled "manager") field was not filled in since it was blank. It also, however, complained that the "User tier" (relabeled "employeetype") was incorrect, even though it showed the label associated with the value 1. I clicked the search drop-down for manager, typed in my own uid, and even though everything had been blank in the drop down before now my uid showed up. I clicked on it, and my uid was now in the manager field. I then clicked the drop down for employeetype, and chose one of the other options. I was now able to save the changes to the record. Upon reloading the page, the "Employee Information" facet now shoed up on the right side bottom, instead of the left side bottom where it was appearing. I was also now able to change the drop-down fields for manager and employeetype to another value, and save them, and they worked fine even filling in all the data that should have been there. This almost seemed like the data being returned by the server was flawed somehow, and confusing the webui, but once it was forced to have the right data and re-saved it worked fine subsequently. I looked at the output of "ipa user-show --all --raw" both before and after making such changes on a user, and can detect no difference between them. On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy <aboko...@redhat.com> wrote: > On to, 19 tammi 2017, Steve Huston wrote: >> >> On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy <aboko...@redhat.com> >> wrote: >>> >>> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client >>> side plugins into different paths (ipaserver/plugins and >>> ipaclient/plugins instead of being common in ipalib/plugins). The client >>> code was also changed to always read metadata about API from the server >>> side. This means the client can adopt to any server version that >>> supports API metadata. >> >> >> Right, and I think that the most of the plugin I had belongs >> server-side; in fact, that's where I migrated it to, and things work >> fine. I haven't tested if I can change those values with the cli, but >> I'm less concerned about that at the moment. >> >>> In my sample external plugin you referenced above you can see that I >>> have client-side change that replaces an input string by a file >>> reference so that a file can supplied instead of typing the content of >>> the file on the command line. This is one of most used patterns for >>> client side plugins. >> >> >> In this case, my biggest problem is with the web UI. The 'manager' >> drop down (which I have renamed through the UI plugins to "Requested >> By" to show what user requested and is responsible for this account) >> works fine in the 'add/modify stageuser' context, but not at all in >> the adduser/moduser context, and I can't seem to find out why. > > I'll defer answer for this to our web UI wizards but they would need to > see your code to help, I'd guess. > > -- > / Alexander Bokovoy -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Backend & UI plugin update for 4.4.x
On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy <aboko...@redhat.com> wrote: > In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client > side plugins into different paths (ipaserver/plugins and > ipaclient/plugins instead of being common in ipalib/plugins). The client > code was also changed to always read metadata about API from the server > side. This means the client can adopt to any server version that > supports API metadata. Right, and I think that the most of the plugin I had belongs server-side; in fact, that's where I migrated it to, and things work fine. I haven't tested if I can change those values with the cli, but I'm less concerned about that at the moment. > In my sample external plugin you referenced above you can see that I > have client-side change that replaces an input string by a file > reference so that a file can supplied instead of typing the content of > the file on the command line. This is one of most used patterns for > client side plugins. In this case, my biggest problem is with the web UI. The 'manager' drop down (which I have renamed through the UI plugins to "Requested By" to show what user requested and is responsible for this account) works fine in the 'add/modify stageuser' context, but not at all in the adduser/moduser context, and I can't seem to find out why. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Backend & UI plugin update for 4.4.x
I'm running a RHEL derivative (Springdale Linux) and discovered that between 7.2 and 7.3 there were quite a few changes, one of which was the version of FreeIPA installed. Fortunately my server is still in the testing phase, and I hadn't finished things for deployment yet. I discovered that plugins changed drastically some time in 4.4.x, and seemed to have found how to modify the plugin I wrote to function again: http://www.astro.princeton.edu/~huston/astrocustom/ The basics are that we add puppetvar and owner to hosts, and the majority of changes are rebranding existing attributes to fit our environment better for the AAs that will have access to add stage users. So far, that is all working fine - on the add stage user pop-up, everything looks as expected, and on the mod stageuser page everything works there as well. However, I am trying to copy some of these changes to the regular user page, and finding they're not working at all; for example, the "manager" field works fine on the adduser pop-up, but on the moduser page it is blank and errors for not having a proper value set when trying to save changes. Interestingly the "employee type" (renamed "User tier") shows up fine, and it too was basically a copy from the mod stageuser section so I'm not sure why one works and one doesn't. It also seems most of the documentation I'd found previously to talk about writing plugins hasn't been updated for the new systems - I did find the pages at https://github.com/abbra/freeipa-desktop-profile/ but I wasn't able to follow them well or figure out how/if they applied to my case. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] New install, unsupported format?
On Tue, Feb 28, 2017 at 4:26 AM, Standa Laznicka <slazn...@redhat.com> wrote: > On 02/27/2017 04:51 PM, Steve Huston wrote: >> It seems there might be two issues here; the one I originally reported >> was that the ipa-server packages installed on a client machine are >> unable to talk to the server, even though it obviously knows what the >> server is (the "unsupported format" error I originally shared). The >> second is with setting up a replica in general. > > The server rpm packages should have no impact on client settings if neither > server nor replica are installed on the given machine. IIRC client only uses > the NSS database in /etc/ipa/nssdb, you may want to check the permissions > there (should be o+xr for the folder, o+r for the *.db files there). I'll look into this more later, since it's less of an issue (I don't plan on having the server packages installed on a machine that isn't a server, and once it's a server it works fine). > I believe your machine might have been in some kind of undecided state when > you tried to promote a client to a replica. What happens during replica > installation on domain level 1 is that client installation is checked first. > If client is installed the installation continues with other steps, if it's > not, it tries to install the client. > In your case, you probably had your client installed at first and tried to > install replica. Something bad happened, can't be sure what, the > installation failed and tried to uninstall the client but that might have > failed, too. Eventually, you uninstalled the client yourself successfully, > all files were removed and its records were also removed from the server. > This made it possible to eventually successfully install a replica. > I wouldn't bet my life on it but I'd think the installation could have gone > successfully even if you installed a client and tried to promote it again :) Quite possible - I thought I accounted for everything, but I'll admit that when a client gets installed and provisioned it's not with ipa-client-install but via puppet. I did this because I needed a programmatic way to determine if a host was already provisioned (preferably locally) and execute the proper commands to do so, and in my experimenting I found following the instructions for provisioning manually worked well and use the presence of /etc/krb5.keytab as an indicator of "has this host been provisioned" (its absence is a negative). It's likely that ipa-client-install does something else that I never noticed, which ipa-replica-install relies on to know what's going on - especially since when I run on a client, it first uninstalls the client and then tries to reinstall it, and that's where it fails. I may experiment with that a bit too since it won't take long to do. > Anyway, I am sorry to hear you had such troubles, the replica installation > is not usually such a painful process, I hope you will have more luck with > FreeIPA in the future. While it has been frustrating, it has definitely been a learning experience. I grow more confident in the system's abilities as I discover more about it, and that means should something break in the future I'm already in a position of knowledge of some of the internals and less afraid to poke gently to fix it. The support on this mailing list has also been wonderful, so thank you all for that! -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] New install, unsupported format?
On Mon, Feb 27, 2017 at 5:56 AM, Standa Laznicka <slazn...@redhat.com> wrote: > Sorry for the hold up. Two questions - is this domain level 1 or 0 (you can > run `ipa domainlevel-get` on the master if you don't know)? Did you have a > client installed prior to ipa-replica-install? It's level 1. I did have a couple clients installed, and the machine I was trying to promote to a replica was one of them. This whole instance is a testing instance, with live data but not in production, while I make sure everything works as expected before I deploy it, so the servers and their data are new as of a couple weeks ago and began life as a RHEL7.3 install. It seems there might be two issues here; the one I originally reported was that the ipa-server packages installed on a client machine are unable to talk to the server, even though it obviously knows what the server is (the "unsupported format" error I originally shared). The second is with setting up a replica in general. I had tried the various methods outlined in the RedHat IdM documentation, including promoting a client via an administrators TGT, adding the client to the ipaservers group on the server, etc. What did finally work was unprovisioning the client, setting a one-time password, and running "ipa-replica-install -v --domain=astro.princeton.edu --server=ipa.astro.princeton.edu --realm=ASTRO.PRINCETON.EDU --hostname=syrinx.astro.princeton.edu --setup-ca -p foobar" - this yielded a fully working replica when it finished. All of the previous failures happened in the same way as mentioned before - it seems to unprovision the client for some reason, then fail in reprovisioning it. One problem which has cropped up before and caused problems is with DNS capitalization. DNS reports the domain name of "Princeton.EDU" for hosts here, which means in order to do just about anything with a FreeIPA server I have to manually add the host to /etc/hosts with all lowercase letters. I also have to force all of the host names via command line switches so that DNS is not consulted for lookups, which will return the StudlyCaps names and fail. I suppose I should raise that as a separate issue, because my understanding is that hostnames/domainnames should be case insensitive so I'm not sure why FreeIPA cares (and it may be easier to steer the entire project to not care than convince those in control of DNS here to change it :D ) -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Default SELinux user changes on addition of replica?
On Tue, Apr 25, 2017 at 11:34 AM, Rob Crittenden <rcrit...@redhat.com> wrote: > I guess the only way to know for sure would be to try to duplicate it. I'll basically be doing that anyway, since I just found that there's some issue with password migrations too (there wasn't before, it was working, so now I'm trying to figure out why it's not) and I think I slammed the server too hard with changes when they were linked and the replica couldn't keep up. So, I removed everyone again, broke the replication, reinstalled the replica server again, and will try later once I've got this all working. Right now it has the right default user, so I'll know for sure when I create another replica :D -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Default SELinux user changes on addition of replica?
In the last of my testing before deployment, I had a replica server setup but things got out of sync somehow. Yesterday I severed the link with the two servers, reimaged the "bad" one, and did some poking around on the "good" one while I was at it (clearing out all of the real user data in anticipation of making another migration run into it). I remember at one point I had found the default selinux user was misconfigured, and I thought it was strange because that's on my checklist for installing a server so I know I'd done it. Oh well, changed it to the proper context again and moved on. Just this morning I made the new (previously bad) server a replica again, and after it finished I happened into the configuration page to find the default selinux user is back to unconfined_u:s0-s0:c0.c1023. Both servers report this the same, as I would expect, but I don't expect or understand why it changed again. I don't know that I'll have time to spin up more instances and go through the testing to see what/when/how it changed, but I wanted to point it out in case someone who does have that time can run with the information. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] UI customization: Default values on host addition
I've extended the UI for host addition by including a multivalued widget which stores puppetVar values (as well as the accompanying Python plugin to handle it and schema update in the directory). This works well, but I'd like to add one more thing and am not sure how to do it. There are certain variables which are basically always set for every host, and so I'd like them to default to those values in the UI, while still giving the admin the choice to edit or remove them just like they were entered by hand. I'm not sure, however, how to "push" values into the UI that way. Is there some attribute of a field I can edit to insert a default value into the UI, while still allowing that to be removed or edited before the user submits the page? -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Getting a certificate for an alias
I'm trying to use certmonger to get an SSL certificate on a web host which has an alias. I added the alias as a principal alias to the host record in FreeIPA, and I added the service as well with the actual hostname and the alias. However every time certmonger contacts the CA, the request is rejected with "The service principal for subject alt name ... does not exist" (or earlier, another similar error which has now been lost to the scrollback). hostname: coathook.astro.princeton.edu Principal alias: host/coathook.astro.princeton@astro.princeton.edu Principal alias: host/puppet.astro.princeton@astro.princeton.edu Principal alias: HTTP/coathook.astro.princeton@astro.princeton.edu Principal alias: HTTP/puppet.astro.princeton@astro.princeton.edu Service: HTTP Host Name: coathook.astro.princeton.edu ipa-getcert request -k /etc/pki/tls/private/puppetexplorer.key -f /etc/pki/tls/certs/puppetexplorer.crt -D puppet.astro.princeton.edu -N CN=coathook.astro.princeton.edu,O=ASTRO.PRINCETON.EDU -K HTTP/coathook.astro.princeton@astro.princeton.edu -C '/usr/sbin/apachectl graceful' When I check with ipa-getcert list, I find: ca-error: Server at https://ipa.astro.princeton.edu/ipa/xml failed request, will retry: 4001 (RPC failed at server. The service principal for subject alt name puppet.astro.princeton.edu in certificate request does not exist). Other attempts used the CN of puppet, and the Kerberos principal of puppet as well, and they also failed but with the slightly different error (I believe it was that the host does not exist). So how does one create a certificate for an alias on a host? -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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] Getting a certificate for an alias
On Thu, May 4, 2017 at 9:15 PM, Fraser Tweedale <ftwee...@redhat.com> wrote: > The fix for this was released in FreeIPA 4.5. See ticket > https://pagure.io/freeipa/issue/6295. > Excellent! Any chance of that getting backported into the 4.4.x series available on RHEL7? -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University |ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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
