Re: [Freeipa-users] Failed installation
Hello Bret, This may be a long shot, but when I sometimes hit this kind of errors when CA installation crashed and there is still some remaining CA configuration (in /var/lib/pki-ca). I usually fix this with standard ipa-server-install --uninstall -U and then running this command: /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force HTH, Martin On 10/18/2012 12:26 AM, Bret Wortman wrote: I think I have SELinux turned off but will double-check in the morning. And reply to the list -- Bret Wortman http://bretwortman.com/ http://twitter.com/bretwortman On Wednesday, October 17, 2012 at 3:17 PM, Rob Crittenden wrote: Bret Wortman wrote: Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? See if there are any SELinux denials: ausearch -m AVC It looks like tomcat failed to start. The logs are in /var/log/pki-ca. rob On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: Spot on. It was a fresh install of F17 and I neglected to # yum update first. I've done so, rebooted, and am trying again with better results. On Wed, Oct 17, 2012 at 1:45 PM, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject___name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WE__DGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert___subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: ##__### Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ##__##__### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net http://java.net.__ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.__socketConnect(Native Method) at java.net http://java.net.__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) at java.net http://java.net.__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) at java.net http://java.net.__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) at java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) at java.net.Socket.connect(__Socket.java:579) at java.net.Socket.connect(__Socket.java:528) at java.net.Socket.init(Socket.__java:425) at java.net.Socket.init(Socket.__java:241) at HTTPClient.sslConnect(__HTTPClient.java:326) at ConfigureCA.LoginPanel(__ConfigureCA.java:244) at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.__java:1672) java.lang.NullPointerException at
[Freeipa-users] Proven procedure for resetting admin password from CLI
Hello I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find working procedure for that - all what I've found failed. Do we have any verified method/docs? Best regards, George Machitidze ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failed installation
On 10/18/2012 01:23 PM, Bret Wortman wrote: Tomcat is definitely not running and there's no log in /var/log/pki-ca. SELinux is disabled and not running. The same RPMs are installed on both my functioning and nonfunctioning system, at least as far as # rpm -qa | grep tomcat | sort revealed. I also followed Martin's suggestion to clean out the CA configuration, but that command seems to indicate that there wasn't any existing configuration: [root@fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... PKI instance Deletion Utility cleaning up instance ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Removing selinux contexts Actually, I think that the pkiremove utility removed the leftover CA. If the CA was not there, the output should look like that: # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not a legal directory. ... Can you try running the server install again? So that we can see if the CA cleanup helped? Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Proven procedure for resetting admin password from CLI
You can reset it using ldappasswd. Eg: # ldappasswd -D cn=Directory Manager -W -s new_admin_pwd -H ldaps://ipa.server uid=admin,cn=users,cn=accounts,basedn Note: You might need to prefix LDAPTLS_CACERT=/etc/ipa/ca.crt to the above command if the IPA CA cert is not mentioned in /etc/openldap/ldap.conf On Thu, Oct 18, 2012 at 4:19 PM, George Machitidze gio...@gmail.com wrote: Hello I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find working procedure for that - all what I've found failed. Do we have any verified method/docs? Best regards, George Machitidze ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Cheers Najmuddin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failed installation
Sorry, that wasn't clear at all, was it? The latest attempt was after I ran the cleanup. No joy; it's still failing at the same point and tomcat is definitely not running. On Thu, Oct 18, 2012 at 7:28 AM, Martin Kosek mko...@redhat.com wrote: On 10/18/2012 01:23 PM, Bret Wortman wrote: Tomcat is definitely not running and there's no log in /var/log/pki-ca. SELinux is disabled and not running. The same RPMs are installed on both my functioning and nonfunctioning system, at least as far as # rpm -qa | grep tomcat | sort revealed. I also followed Martin's suggestion to clean out the CA configuration, but that command seems to indicate that there wasn't any existing configuration: [root@fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... PKI instance Deletion Utility cleaning up instance ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Removing selinux contexts Actually, I think that the pkiremove utility removed the leftover CA. If the CA was not there, the output should look like that: # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not a legal directory. ... Can you try running the server install again? So that we can see if the CA cleanup helped? Martin -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Proven procedure for resetting admin password from CLI
On 10/18/2012 06:49 AM, George Machitidze wrote: Hello I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find working procedure for that - all what I've found failed. Can you please share what you tried and how it failed? Do we have any verified method/docs? Best regards, George Machitidze ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
Update with success! (but embarrassment)
I apologize for putting everyone through the ringer on this one. Here is what
I found.
I mentioned at one point that my domainname/nisdomainname/dnsdomainname did not
all return my correct domain, but that I had fixed this. As it turned out, I
had a typo in my rc.local file. Fixing them so they return the correct value
is not enough to fix sudo. I ran ipa-client --uninstall -- yum remove
ipa-client -- yum install ipa-client -- ipa-client-install and re-enrolled
my client without making any other changes. Apparently, something does not
translate properly during the enroll process if your domain is not set properly
in the rc.local file. Everything is now working just as I would expect it to!
Again, thank you everyone for your assistance!
Cheers,
Jason
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 3:44 PM
To: Macklin, Jason {DASB~Branford}
Cc: d...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per
command or host level.
Can you confirm that you have sudoer_debug set to 2?
If I gather correctly, this is on RHEL 6.3? What version of sudo?
I'm seeing different output. Mine includes the number of candidate results for
sudoUser are found.
If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server you'll be
able to see the LDAP searches the sudo client is making. The log is buffered so
you won't see them immediately. Can you send us the queries that are being made?
thanks
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failed installation
Bret Wortman wrote: Sorry, that wasn't clear at all, was it? The latest attempt was after I ran the cleanup. No joy; it's still failing at the same point and tomcat is definitely not running. In order to diagnose why dogtag is failing to install we need to see the logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. You can send them directly to me or Martin if you'd prefer. rob On Thu, Oct 18, 2012 at 7:28 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 10/18/2012 01:23 PM, Bret Wortman wrote: Tomcat is definitely not running and there's no log in /var/log/pki-ca. SELinux is disabled and not running. The same RPMs are installed on both my functioning and nonfunctioning system, at least as far as # rpm -qa | grep tomcat | sort revealed. I also followed Martin's suggestion to clean out the CA configuration, but that command seems to indicate that there wasn't any existing configuration: [root@fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... PKI instance Deletion Utility cleaning up instance ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Removing selinux contexts Actually, I think that the pkiremove utility removed the leftover CA. If the CA was not there, the output should look like that: # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not a legal directory. ... Can you try running the server install again? So that we can see if the CA cleanup helped? Martin -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Proven procedure for resetting admin password from CLI
On Thu, 2012-10-18 at 14:49 +0400, George Machitidze wrote: Hello I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find working procedure for that - all what I've found failed. Do we have any verified method/docs? ipa passwd or kpasswd should work just fine. you should also be able to use ldappasswd if you prefer that. Can you tell exactly what failed an how ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failed installation
Rob Crittenden wrote: Bret Wortman wrote: Sorry, that wasn't clear at all, was it? The latest attempt was after I ran the cleanup. No joy; it's still failing at the same point and tomcat is definitely not running. In order to diagnose why dogtag is failing to install we need to see the logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. You can send them directly to me or Martin if you'd prefer. To close the loop on this, I had Bret yum reinstall the pki-selinux package. For some reason sometimes it fails to load the required SELinux contents on install. Doing that has resolved the installation issue. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] web admin tool will not login with kerberos ticket
I followed Rob's advice and enabled the http debug logging. I'm no expert here
but I didn't really see anything that indicates an error. I do see a series of
connections to the server and GSS/kerberos log messages (like client delegates
us their credentials and GSS-API token of length 22 bytes will be sent
back...). The log just stops and apache returns an authentication error.
While reading the logs, I did notice a reference to s4u2proxy. When I looked
around for that, I ran across a blog article from idra at samba.org where he
described how they modified mod_auth_kerb for FreeIPA.
On suspecting something went wrong with the installation (like some update that
replaced mod_auth_kerb or something related), I did a yum reinstall
freeipa-server. After it completed, everything started working as it had in
the past.
So while I don't know for sure, I believe some other package that was updated
(perhaps apache) overwrote something in FreeIPA (perhaps mod_auth_kerb). In any
case, I'm whole again.
Brian
On Oct 17, 2012, at 7:49 AM, Rob Crittenden wrote:
Brian Vetter wrote:
I had a happy, working 2.2 FreeIPA installation humming along last
week. I had to do some maintenance so I shut everything down. When I
brought everything up, I can no longer log into the web admin tool. I
get a Kerberos ticket is no longer valid error.
Using the troubleshooting pages on the wiki as a guide, I can kinit
successfully and see the tickets using klist. I can use the ldapsearch
tool using GSSAPI to authenticate as well and can return results from
the ldap server. 'ldapsearch -Y GSSAPI -b dc=dcc,dc=mobi uid=admin'
returns a valid ldap recors for my admin user. I ran this command kinit
from multiple kerberos principals/users and each worked.
I verified my config settings again with firefox and they are still set
correctly (auth.delegation-uris, auth.trusted-users both set to my
domain .dcc.mobi). The cert was accepted (no warnings about the cert not
being trusted because I had already set it to trusted). I turned on the
NSPR logging as described in the documents, and didn't see an error,
although I can't tell if this is correct:
492291904[7f4d1d31f6a0]: using REQ_DELEGATE
492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi
492291904[7f4d1d31f6a0]: using negotiate-gss
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
492291904[7f4d1d31f6a0]: Attempting to load gss functions
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init()
492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials()
[challenge=Negotiate]
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken()
492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0]
492291904[7f4d1d31f6a0]: Sending a token of length 1394
There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log
does have a few entries:
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ca/ocsp HTTP/1.1
200 2298 - Mozilla/5.0 (X11; Linux x86_64; rv:16.0)
Gecko/20100101 Firefox/16.0
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json
HTTP/1.1 401 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] GET
/ipa/session/login_kerberos HTTP/1.1 401 1861
10.1.1.10 - ad...@dcc.mobi
[16/Oct/2012:18:05:26 -0500] GET /ipa/session/login_kerberos
HTTP/1.1 200 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] POST /ipa/session/json
HTTP/1.1 401 -
The 401's aren't surprising here since somehow, something is not
properly authenticating.
I also looked in /var/log/krb5kdc.log and see the following line when
authenticating:
Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1
etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18
tkt=18 ses=18}, ad...@dcc.mobi for
krbtgt/dcc.m...@dcc.mobi
I don't believe this describes an error, but I'm not an expert reading
that log type.
From what I can tell, the problems seem to be between the apache server
and the browser. Both worked fine together last week. Is there something
I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf
files) that can help debug this? Or better yet, anyone else seen this
and have an answer? Is there some key/ticket/etc associated with the
http server that might be wrong now (somehow whacked during the reboot)?
If you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart the httpd
service you'll get a lot of debugging output from ipa and mod_auth_kerb, one
of which may provide some pointers.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
