Re: [Freeipa-users] 2.20 dirsrv memory usage
On Wed, Jul 18, 2012 at 2:26 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 05:09 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 1:52 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 04:27 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 1:06 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 03:45 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 12:28 PM, John Dennis jden...@redhat.com wrote:
On 07/18/2012 02:59 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik pvobo...@redhat.com
wrote:
On 07/17/2012 11:43 PM, Stephen Ingram wrote:
8--
I'm beginning to think this is just the Web UI itself instead of
389
although it is really difficult to tell. I've poured over the debug
logs and didn't see anything that caused me concern.
It's certainly usable, but I just got really spoiled by the
unbelievable quickness of 2.1.3. When your release notes indicate
it
should be faster, what are you comparing it to? Maybe this only
happens with upgraded instances and not fresh installs.
It is always possible something didn't get upgraded properly but
I've
done
2.1.3 - 2.2.0 upgrades and haven't seen this. When we say
something is
faster we're always referring to the previous version (or versions).
Maybe I was just lucky with 2.1.3. On a first load it might take some
time to load the frame as I call it. But the data would load almost
instantaneously from there (certainly no more than 1 s) as you moved
from page to page. Here, even if I return to the same page, the
system
acts as if the data is begin fetched for the very first time as it is
no faster than the first load. Maybe that is significant to the
problem?
I think the culprit is Web UI paging capabilities introduced in 2.2.
With
lot of users, responses might grow in size. You can check their size
and
duration in browser developers tools. I suggest chrome/chromium -
press
F12
and choose 'network' tab.
This new feature can't be disabled in configuration. To test if the
slowdown
is done by paging you can (at own risk) replace line
/usr/share/ipa/ui/facet.js:538
that.pagination = spec.pagination === undefined ? true :
spec.pagination;
with:
that.pagination = false;
Note: It will break some other parts of the UI - so for testing only.
I've made the substitution in the code (was line 507 for me-do I have
a different version?). Looking at the time chart in Chrome I see that
the bulk of the time is for /ipa/session waiting. Would waiting mean
waiting for the directory server or memcached?
Actually neither, it means waiting for a response from the web server
(technically it's making an RPC call via HTTP Ajax). The RPC call needs
to
go through the web server, memcached, and typically will invoke one or
more
directory server queries, and run a bunch of Python to massage
everything
before the RPC returns with the result.
It doesn't look like you've got much difference in times between with
pagination on and pagination off. I don't know the pagination code but I
suspect it's run after the RPC call returns so the RPC timing is not
telling
us much with respect to that.
Waiting for up to 3 seconds for an RPC call does seem on the high side.
Do
you have a lot of LDAP data?
No. 49 users, 17 hosts, 25 services, 6 DNS zones, only 1 of which has
any significant amount of hosts in it.
But really, unless we get timing results for each component we're
grasping
at straws :-(
Understood.
Steve
Do you have a replica and does this replica behave the same?
No replica yet. I wanted to get the memory leak issue solved first.
All I have to compare to is the old 2.1.3 before. This one is much
slower. I just can't seem to figure out what's wrong. The upgrade
seemed to complete successfully and there were no errors in the log.
The only things I've found thus far (earlier in this thread) are the
unindexed entries (all hosts entries) that Rich seemed to think might
be slowing things up. As the slowness is on every page, I wouldn't
think that would be the problem.
I wouldn't have said as much about this were it not for the promised
faster speed mentioned in the release notes. It's comparable to the
old 2.0 release candidates so I thought it might have been due to the
complexity of the feature additions.
Steve
Is the time correct on this system?
Yes. HW clock is GMT and localtime is Pacific Daylight Time and it is
accurate to the minute.
Steve
Can you check the Kerberos logs whether the ldap service ticket is
acquired on every http request via browser?
That looks to be the case. I tailed the log while accessing each page and got:
Jul 18 22:43:15 ipa1.example.com krb5kdc[1243](info): TGS_REQ (4
etypes {18 17 16 23}) xxx.xx.xx.xx: ISSUE: authtime 1342640481, etypes
{rep=18 tkt=18 ses=18}, HTTP/ipa1.example@example.com for
ldap/ipa1.example@example.com
Jul 18 22:43:15 ipa1.example.com krb5kdc[1243](info): ...
CONSTRAINED-DELEGATION
Re: [Freeipa-users] 2.20 dirsrv memory usage
On 07/18/2012 08:59 PM, Stephen Ingram wrote: On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik pvobo...@redhat.com wrote: On 07/17/2012 11:43 PM, Stephen Ingram wrote: 8-- I'm beginning to think this is just the Web UI itself instead of 389 although it is really difficult to tell. I've poured over the debug logs and didn't see anything that caused me concern. It's certainly usable, but I just got really spoiled by the unbelievable quickness of 2.1.3. When your release notes indicate it should be faster, what are you comparing it to? Maybe this only happens with upgraded instances and not fresh installs. It is always possible something didn't get upgraded properly but I've done 2.1.3 - 2.2.0 upgrades and haven't seen this. When we say something is faster we're always referring to the previous version (or versions). Maybe I was just lucky with 2.1.3. On a first load it might take some time to load the frame as I call it. But the data would load almost instantaneously from there (certainly no more than 1 s) as you moved from page to page. Here, even if I return to the same page, the system acts as if the data is begin fetched for the very first time as it is no faster than the first load. Maybe that is significant to the problem? I think the culprit is Web UI paging capabilities introduced in 2.2. With lot of users, responses might grow in size. You can check their size and duration in browser developers tools. I suggest chrome/chromium - press F12 and choose 'network' tab. This new feature can't be disabled in configuration. To test if the slowdown is done by paging you can (at own risk) replace line /usr/share/ipa/ui/facet.js:538 that.pagination = spec.pagination === undefined ? true : spec.pagination; with: that.pagination = false; Note: It will break some other parts of the UI - so for testing only. I've made the substitution in the code (was line 507 for me-do I have a different version?). I was looking at the top of FreeIPA 2.2 branch. RHEL version differs a bit. It shouldn't matter in this case though. Looking at the time chart in Chrome I see that the bulk of the time is for /ipa/session waiting. Would waiting mean waiting for the directory server or memcached? Basically all the stuff, which is needed for processing of the request. The pipeline is something like (I don't want to go into details): httpd - mod_wsgi - python - memcache, dir server request and back. From what I see I think the problem is not on Web UI side. Most of the time is waiting for server response. I initially thought the problem lies in a large number of users (1000+). But in other post you mentioned that it is under 100. Hence this new paging feature shouldn't be a big problem. Here's a portion of the initial load of the Users page: The first 3 requests are inital load of web UI (not including .js files and such) - you can see they are the same in both cases. I don't see a login request so session is already established. json/ipa/session POST 200 Success application/json jquery.js:7365 Script 33.94KB 33.10KB 1.57s 1.47s 96ms (1.37s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 568.09KB 564.36KB 3.92s 2.95s 963ms (2.85s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 556.94KB 553.40KB 3.78s 2.94s 836ms (2.83s waiting) This one is user load: json/ipa/session POST 200 Success application/json jquery.js:7365 Script 46.93KB 46.38KB 1.87s 1.71s (1.60s waiting) Now, with the pagination turned back on: json/ipa/session POST 200 Success application/json jquery.js:7365 Script 33.94KB 33.10KB 1.58s 1.48s 100ms (1.38s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 568.09KB 564.36KB 4.05s 3.09s 964ms (2.98s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 556.94KB 553.40KB 3.84s 2.99s 855ms (2.88s waiting) Here you can see a change. With pagination turned on it should be two request. One to get primary keys (logins) and second to get users. The latter is missing in this list. With a lot of users the first response grows. With low number of users it is in fact smaller than with pagination turned off. json/ipa/session POST 200 Success application/json jquery.js:7365 Script 46.93KB 46.38KB 1.52s 1.51s (1.40s waiting) As I mentioned you are missing one request so it will add aprox. 1.5s. The second request is kinda a slowdown from IPA 2.1.4 but the main issue is still the long server processing time. Steve -- Petr Vobornik ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
On Thu, 2012-07-19 at 00:53 +, Steven Jones wrote: Actually its pamunless IPA is as well. Which makes sense then to have an application run 500 so inherently it cannot be logged into via ssh Well, it's possible to configure your system to allow logging in to users below 500, but it's not recommended. The real risk is of having system services with an ID that conflicts with a user. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
On Thu, 2012-07-19 at 07:36 -0400, Stephen Gallagher wrote: On Thu, 2012-07-19 at 00:53 +, Steven Jones wrote: Actually its pamunless IPA is as well. Which makes sense then to have an application run 500 so inherently it cannot be logged into via ssh Well, it's possible to configure your system to allow logging in to users below 500, but it's not recommended. The real risk is of having system services with an ID that conflicts with a user. In general we do not recommend to set ids on your own, let ipa choose IDs unless you have a constraint that prevents you from letting that happen. 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] 2.20 dirsrv memory usage
On Thu, 19 Jul 2012, John Dennis wrote: Rob may have already contacted you with this, but if not we would like to get more debugging information by have the server log what is occurring when it processes your requests. To do this you'll need to turn on the debug flag in the IPA configuration file /etc/ipa/default.conf, add a line that says: debug = True Then restart the server to pick up the new configuration. The information will be written to /var/log/httpd/error_log. We only need the contents of the log from when the server was restarted with debug logging enabled. For privacy reasons I suggest you send the contents of the log to one of the IPA team members directly in a private email, not to the public freeipa list. In addition we would like to see what's happening with krb5 communication under httpd processes. In order to obtain that tracing information you need to do following: 1. Add KRB5_TRACE=/tmp/http_krb5_trace.log to /etc/sysconfig/httpd 2. Restart httpd (or httpd.service in Fedora) 3. Now you need to create the file and chown it to apache's user so that httpd processes would be able to write to it: find out PID of any of httpd processes, doesn't matter which one touch /proc/$PID/cwd/tmp/http_krb5_trace.log chown apache /proc/$PID/cwd/tmp/http_krb5_trace.log 4. Now you can issue IPA commands and you'll get krb5 client tracing in /proc/$PID/cwd/tmp/http_krb5_trace.log The reason why (3) talks about PID of httpd process is because in Fedora, unlike in RHEL6.x, systemd is handling services startup and systemd confines httpd to a private /tmp. Using /proc/$PID/cwd/tmp is the easiest way to reach that private tmp. 5. Once finished and copied /proc/$PID/cwd/tmp/http_krb5_trace.log to an archive location, make sure to remove the file and its reference from /etc/sysconfig/httpd and restart the service. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
On Thu, 2012-07-19 at 07:36 -0400, Stephen Gallagher wrote: On Thu, 2012-07-19 at 00:53 +, Steven Jones wrote: Actually its pamunless IPA is as well. Which makes sense then to have an application run 500 so inherently it cannot be logged into via ssh Well, it's possible to configure your system to allow logging in to users below 500, but it's not recommended. The real risk is of having system services with an ID that conflicts with a user. In general we do not recommend to set ids on your own, let ipa choose IDs unless you have a constraint that prevents you from letting that happen. Does this mean that it's impossible to have IPA authenticate the oracle user or any other user that is normally below 500? Our security team is asking that we manage the passwords of oracle and other users centrally. Can IPA do this for me? Thanks Duncan Northern Rock plc is part of the Virgin Money group of companies. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money Personal Financial Service Limited is authorised and regulated by the Financial Services Authority. Company no. 3072766. Virgin Money Unit Trust Managers Limited is authorised and regulated by the Financial Services Authority. Company no. 3000482. Virgin Money Cards Limited. Introducer appointed representative only of Virgin Money Personal Financial Service Limited. Company no. 4232392. Virgin Money Management Services Limited. Company no. 3072772. Virgin Money Holdings (UK) Limited. Company no. 3087587. Each of the above companies is registered in England and Wales and has its registered office at Discovery House, Whiting Road, Norwich NR4 6EJ. Northern Rock plc. Authorised and regulated by the Financial Services Authority. Registered in England and Wales (Company no. 6952311) with its registered office at Northern Rock House, Gosforth, Newcastle upon Tyne NE3 4PL. The above companies use the trading name Virgin Money. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2.20 dirsrv memory usage
On 07/19/2012 02:29 AM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 2:26 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 05:09 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 1:52 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 04:27 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 1:06 PM, Dmitri Pal d...@redhat.com wrote:
On 07/18/2012 03:45 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 12:28 PM, John Dennis jden...@redhat.com
wrote:
On 07/18/2012 02:59 PM, Stephen Ingram wrote:
On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik pvobo...@redhat.com
wrote:
On 07/17/2012 11:43 PM, Stephen Ingram wrote:
8--
I'm beginning to think this is just the Web UI itself instead of
389
although it is really difficult to tell. I've poured over the
debug
logs and didn't see anything that caused me concern.
It's certainly usable, but I just got really spoiled by the
unbelievable quickness of 2.1.3. When your release notes indicate
it
should be faster, what are you comparing it to? Maybe this only
happens with upgraded instances and not fresh installs.
It is always possible something didn't get upgraded properly but
I've
done
2.1.3 - 2.2.0 upgrades and haven't seen this. When we say
something is
faster we're always referring to the previous version (or
versions).
Maybe I was just lucky with 2.1.3. On a first load it might take
some
time to load the frame as I call it. But the data would load
almost
instantaneously from there (certainly no more than 1 s) as you moved
from page to page. Here, even if I return to the same page, the
system
acts as if the data is begin fetched for the very first time as it
is
no faster than the first load. Maybe that is significant to the
problem?
I think the culprit is Web UI paging capabilities introduced in 2.2.
With
lot of users, responses might grow in size. You can check their size
and
duration in browser developers tools. I suggest chrome/chromium -
press
F12
and choose 'network' tab.
This new feature can't be disabled in configuration. To test if the
slowdown
is done by paging you can (at own risk) replace line
/usr/share/ipa/ui/facet.js:538
that.pagination = spec.pagination === undefined ? true :
spec.pagination;
with:
that.pagination = false;
Note: It will break some other parts of the UI - so for testing only.
I've made the substitution in the code (was line 507 for me-do I have
a different version?). Looking at the time chart in Chrome I see that
the bulk of the time is for /ipa/session waiting. Would waiting mean
waiting for the directory server or memcached?
Actually neither, it means waiting for a response from the web server
(technically it's making an RPC call via HTTP Ajax). The RPC call
needs to
go through the web server, memcached, and typically will invoke one or
more
directory server queries, and run a bunch of Python to massage
everything
before the RPC returns with the result.
It doesn't look like you've got much difference in times between with
pagination on and pagination off. I don't know the pagination code but
I
suspect it's run after the RPC call returns so the RPC timing is not
telling
us much with respect to that.
Waiting for up to 3 seconds for an RPC call does seem on the high
side. Do
you have a lot of LDAP data?
No. 49 users, 17 hosts, 25 services, 6 DNS zones, only 1 of which has
any significant amount of hosts in it.
But really, unless we get timing results for each component we're
grasping
at straws :-(
Understood.
Steve
Do you have a replica and does this replica behave the same?
No replica yet. I wanted to get the memory leak issue solved first.
All I have to compare to is the old 2.1.3 before. This one is much
slower. I just can't seem to figure out what's wrong. The upgrade
seemed to complete successfully and there were no errors in the log.
The only things I've found thus far (earlier in this thread) are the
unindexed entries (all hosts entries) that Rich seemed to think might
be slowing things up. As the slowness is on every page, I wouldn't
think that would be the problem.
I wouldn't have said as much about this were it not for the promised
faster speed mentioned in the release notes. It's comparable to the
old 2.0 release candidates so I thought it might have been due to the
complexity of the feature additions.
Steve
Is the time correct on this system?
Yes. HW clock is GMT and localtime is Pacific Daylight Time and it is
accurate to the minute.
Steve
Can you check the Kerberos logs whether the ldap service ticket is
acquired on every http request via browser?
That looks to be the case. I tailed the log while accessing each page and got:
Jul 18 22:43:15 ipa1.example.com krb5kdc[1243](info): TGS_REQ (4
etypes {18 17 16 23}) xxx.xx.xx.xx: ISSUE: authtime 1342640481, etypes
{rep=18 tkt=18 ses=18}, HTTP/ipa1.example@example.com for
ldap/ipa1.example@example.com
Jul 18 22:43:15
Re: [Freeipa-users] IPA and UIDS 500
On Thu, 2012-07-19 at 11:59 -0400, Stephen Gallagher wrote: On Thu, 2012-07-19 at 16:44 +0100, Innes, Duncan wrote: Does this mean that it's impossible to have IPA authenticate the oracle user or any other user that is normally below 500? Our security team is asking that we manage the passwords of oracle and other users centrally. Can IPA do this for me? It's not impossible, but it requires some mangling of your PAM stacks in /etc/pam.d/* That said, it's generally a bad idea to have passwords on users 500. It should not be possible to log into them at all, and instead you should rely on granting (restricted) sudo privileges to real users allowing them to impersonate the service user instead. So instead of allowing people to log into the box as 'oracle', they should log in as 'myusername' and then run 'sudo -u oracle command'. This provides better auditing support as well, since you will always know which real user modified your database configuration (rather than trying to piece together who logged in as 'oracle' directly). Note you can also allow sudo -i which gives you an interactive shell just like su - would, but you can control sudo configuration centrally. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fedora 17 -- ipa-server-install fails at configuring certificate server instance
I've been fighting with this for a couple of hours so it must be time to ask for help :) I've got a clean (and up to date) Fedora 17 install and when I try to install freeipa it fails when its running pkisilent to configure the certificate server instance. == Configuring certificate server: Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname wombat.dlib.indiana.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-dxxeEf -client_certdb_pwd -preop_pin hR0AShCYdzVB5g5frPxh -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=DLIB.INDIANA.EDU -ldap_host wombat.dlib.indiana.edu -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -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=DLIB.INDIANA.EDU -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=DLIB.INDIANA.EDU -ca_server_cert_subject_name CN=wombat.dlib.indiana.edu,O=DLIB.INDIANA.EDU -ca_audit_signing_cert_subject_name CN=CA Audit,O=DLIB.INDIANA.EDU -ca_sign_cert_subject_name CN=Certificate Authority,O=DLIB.INDIANA.EDU -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed = The relevant logs in ipaserver-install.log seem to be: Attempting to connect to: wombat.dlib.indiana.edu:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-07-19T18:06:23Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at 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 ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) = Any troubleshooting hints for this? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 17 -- ipa-server-install fails at configuring certificate server instance
Brian Wheeler wrote: I've been fighting with this for a couple of hours so it must be time to ask for help :) I've got a clean (and up to date) Fedora 17 install and when I try to install freeipa it fails when its running pkisilent to configure the certificate server instance. == Configuring certificate server: Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname wombat.dlib.indiana.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-dxxeEf -client_certdb_pwd -preop_pin hR0AShCYdzVB5g5frPxh -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=DLIB.INDIANA.EDU -ldap_host wombat.dlib.indiana.edu -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -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=DLIB.INDIANA.EDU -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=DLIB.INDIANA.EDU -ca_server_cert_subject_name CN=wombat.dlib.indiana.edu,O=DLIB.INDIANA.EDU -ca_audit_signing_cert_subject_name CN=CA Audit,O=DLIB.INDIANA.EDU -ca_sign_cert_subject_name CN=Certificate Authority,O=DLIB.INDIANA.EDU -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed = The relevant logs in ipaserver-install.log seem to be: Attempting to connect to: wombat.dlib.indiana.edu:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-07-19T18:06:23Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at 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 ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) = Any troubleshooting hints for this? Try re-installing the pki-selinux package. What I would do is this: # ipa-server-install --uninstall -U # ls -ld /var/lib/pki-ca If it exists run: # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force # yum reinstall pki-selinux We're not sure why re-installing that package is required sometimes, the dogtag team has a bug open on it, https://bugzilla.redhat.com/show_bug.cgi?id=746275 rob rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Creating new users with one name
Hi, One thing and its sort of strange but when you so to create a new user you have assumed that the user has both a forename and a surname so this is compulsory. This isn't always the case, we have users who have one name and its not their forename or their surname and that's legal, at least here in NZ. Should I raise this as a bug? I'm not sure what happens when we win-sync from AD in such cases as that is a single occupied field that gets replicated, and a blank for one will this be OK? Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
So, Im am trying to do just this but failing, So rather than, ipa sudorule-add-allow-command --sudocmds /bin/su - banner then, ipa sudorule-add-allow-command --sudocmds /bin/sudo -i banner regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Simo Sorce [s...@redhat.com] Sent: Friday, 20 July 2012 5:09 a.m. To: Stephen Gallagher Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA and UIDS 500 On Thu, 2012-07-19 at 11:59 -0400, Stephen Gallagher wrote: On Thu, 2012-07-19 at 16:44 +0100, Innes, Duncan wrote: Does this mean that it's impossible to have IPA authenticate the oracle user or any other user that is normally below 500? Our security team is asking that we manage the passwords of oracle and other users centrally. Can IPA do this for me? It's not impossible, but it requires some mangling of your PAM stacks in /etc/pam.d/* That said, it's generally a bad idea to have passwords on users 500. It should not be possible to log into them at all, and instead you should rely on granting (restricted) sudo privileges to real users allowing them to impersonate the service user instead. So instead of allowing people to log into the box as 'oracle', they should log in as 'myusername' and then run 'sudo -u oracle command'. This provides better auditing support as well, since you will always know which real user modified your database configuration (rather than trying to piece together who logged in as 'oracle' directly). Note you can also allow sudo -i which gives you an interactive shell just like su - would, but you can control sudo configuration centrally. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
On 07/19/2012 05:00 PM, Steven Jones wrote: So, Im am trying to do just this but failing, So rather than, ipa sudorule-add-allow-command --sudocmds /bin/su - banner then, ipa sudorule-add-allow-command --sudocmds /bin/sudo -i banner Banner should not be a part of the command. He should be put into the run as user if this is an ipa managed user or into external run as user if this user is not managed by IPA but defined on a local system. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Simo Sorce [s...@redhat.com] Sent: Friday, 20 July 2012 5:09 a.m. To: Stephen Gallagher Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA and UIDS 500 On Thu, 2012-07-19 at 11:59 -0400, Stephen Gallagher wrote: On Thu, 2012-07-19 at 16:44 +0100, Innes, Duncan wrote: Does this mean that it's impossible to have IPA authenticate the oracle user or any other user that is normally below 500? Our security team is asking that we manage the passwords of oracle and other users centrally. Can IPA do this for me? It's not impossible, but it requires some mangling of your PAM stacks in /etc/pam.d/* That said, it's generally a bad idea to have passwords on users 500. It should not be possible to log into them at all, and instead you should rely on granting (restricted) sudo privileges to real users allowing them to impersonate the service user instead. So instead of allowing people to log into the box as 'oracle', they should log in as 'myusername' and then run 'sudo -u oracle command'. This provides better auditing support as well, since you will always know which real user modified your database configuration (rather than trying to piece together who logged in as 'oracle' directly). Note you can also allow sudo -i which gives you an interactive shell just like su - would, but you can control sudo configuration centrally. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ 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] Creating new users with one name
Steven Jones wrote: Hi, One thing and its sort of strange but when you so to create a new user you have assumed that the user has both a forename and a surname so this is compulsory. This isn't always the case, we have users who have one name and its not their forename or their surname and that's legal, at least here in NZ. Should I raise this as a bug? I'm not sure what happens when we win-sync from AD in such cases as that is a single occupied field that gets replicated, and a blank for one will this be OK? It is a requirement of the person objectClass. Feel free to open a bug. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
ah rightive been trying to do this in IPA and failing So I actually want, ipa sudorule-add banner-rule ipa sudorule-add-allow-command --sudocmds /bin/sudo -i ipa sudorule-add-host --groups banner-server-group banner-rule ipa sudorule-add-user --groups become-banner-saas-prod banner-rule ipa sudorule-add-user --user banner banner-rule ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA and UIDS 500
having problems with, ipa sudorule-add-host --groups banner-server-group banner-rule So I want to use a host-group so I can run this command accross multiple servers, I take it I cant so I have to add it per host? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Steven Jones Sent: Friday, 20 July 2012 9:39 a.m. To: freeipa-users@redhat.com Subject: RE: [Freeipa-users] IPA and UIDS 500 ah rightive been trying to do this in IPA and failing So I actually want, ipa sudorule-add banner-rule ipa sudorule-add-allow-command --sudocmds /bin/sudo -i ipa sudorule-add-host --groups banner-server-group banner-rule ipa sudorule-add-user --groups become-banner-saas-prod banner-rule ipa sudorule-add-user --user banner banner-rule ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
