Re: [Freeipa-users] Backup Restore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Duncan I spent a substantial amount of time on restorations last week. I was working towards a System State Backup method of backing up IPA. I managed to get a restoration working on a completely clean system by doing a file level restore. What type of restoration are you seeking? complete server rebuild, or partial restoration? Dale On 17/07/12 11:39, Innes, Duncan wrote: Hi folks, Just wondering if there's any specifically designed tools to allow backups restores of a FreeIPA design - or if there are any best practice guidelines at least. Thanks Duncan Innes | Linux Architect | Virgin Money | +44 1603 215476 | +44 7801 134507 | _duncan.innes@virginmoney.com_ mailto:duncan.in...@virginmoney.com - 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBUaqAAoJEAJsWS61tB+qg5EP/0kjbey/+EylGgDyZdBAcV+e /23HkJlmTJLfaKhh/41blBxnuS/gwU4k69hVkMTpoeqKXiHoc3pZ20SqJqawBsZT B2TwzCeBVpKA81Zfi6KeAzpbiw5rozCWBF3fLiEzMHkHCk9VoNkuh7LNqTK/bVkV UJedV88nByakmgs4sii27etwMY1dw4Hh99vPD2L9KMOAEiKA5eZG013vavpXOtl6 oUjLuLy6+3j9x9FW6izHlN9BG3ko/KJSXIS3CthEZ3mTJUHUVqvbMET4/DFglo0b iRkszMWi5Kryb9jxyg3B5J1H1Xk5ciUv82AIO+jNBnJ6P/KemiJ+78KYHd6pAi1K +cp69DatN6vrJQnbqsMq28bHVJ3mihntDbI8JGRRumvp4SesHzwJ6fQiYZ3aXyX7 vpwqIqzHYhTFAbfvcJUfhT6y5Qv85VJON5SOMzlmsWDFXiUpGxlSCptbGUddEv28 fw77S6GQ3/eKzcfAyRhn8m+c0lGkiuLb9LHpcVbJSSrdj1uN3pkRQhjS/rI5fomN 3SRViMEWgr4iVVt8f9ONBYWZ99e2bHFmGjN2tikyaa6dpUo1G075GthGUZGOi6AC SjiT+MmQYrTdqgO+4BK5HK+pNiAGwqpbah3dMxUVTgqSZaRwRynG+xv1JvsahleV Wu4POyb205lHoayeS3Zu =zMDl -END PGP SIGNATURE- 0xB5B41FAA.asc Description: application/pgp-keys 0xB5B41FAA.asc.sig Description: PGP signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stopping su -
On 07/17/2012 12:40 AM, Steven Jones wrote: Hi, I could do, authrequiredpam_wheel.soroot_only use_uid But I really want to do this with IPA or I have to get on each server and add and remove admins by hand (hint 300 servers)...that is the idea of something like IPA for medo it once centrally. I assume simo's hint is, sudo -i su - oracle AFAIU if you are looking for centrally manged setting you need to use sudo. With su and HBAC IPA can just control which user can authenticate using su but not for local users like root. I think that if the oracle user is centrally managed you would be able to define an HBAC rule that would prevent oracle user from doing su on a group of hosts, but I doubt that this is what you want. Seems like sudo will give you much more flexibility. I will have to experiment. 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 Erinn Looney-Triggs [erinn.looneytri...@gmail.com] Sent: Tuesday, 17 July 2012 4:31 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] stopping su - On 07/16/2012 01:47 PM, Steven Jones wrote: Hi, OK, so to confirm this cant be done in a centralised way via IPA? In which case when setting a HBAC with sshd only why cant i su - oracle but I can su - root? 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 Erinn Looney-Triggs [erinn.looneytri...@gmail.com] Sent: Tuesday, 17 July 2012 9:38 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] stopping su - On 07/16/2012 01:32 PM, Steven Jones wrote: I have craeted a sshd rule only for the HBAC, but I find a std user can su - to root, is this correect behavior? How do I? or can I? stop this unless explicitly allowed? 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 You need to control this via PAM. So for me I restrict su to only be allowed for members of the wheel group, from /etc/pam.d/su: authrequiredpam_wheel.souse_uid There are comments in the file that will get you where you want to go. -Erinn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I can't speak to whether it can or cannot be done centrally in any sort of authoritative way, might be possible there are hbac setting for su and I can't really answer your question about suing to oracle. -Erinn ___ 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] How to set a user group rule to allow su - oracle only?
Hello On Tue, Jul 17, 2012 at 3:15 AM, Steven Jones steven.jo...@vuw.ac.nzwrote: Hi, If I login as say user1, I want that user to be able to su - oracle, but not to say su - root (or to any other user). If user2 logins I want them unable to su - X at all and especially not root. If an admin logins in I want them to be able to su - anybody... In a way before I could do that with the wheel group and pam. regards Steven Jones rob # cat /etc/pam.d/su authsufficient pam_rootok.so auth[default=1 success=ok ignore=ignore] pam_wheel.so trust use_uid group=group1 auth[success=2 default=die] pam_listfile.so item=user sense=allow onerr=fail file=/etc/security/su-group1-access auth[default=die success=ok ignore=ignore] pam_wheel.so trust use_uid group=group2 authrequisite pam_listfile.so item=user sense=allow onerr=fail file=/etc/security/su-group2-access authinclude system-auth account sufficientpam_succeed_if.so uid = 0 use_uid quiet account includesystem-auth password includesystem-auth session includesystem-auth session optionalpam_xauth.so With above configuration. members of group1 will be able to su only to users in /etc/security/su-group1-access members of group2 will be able to su only to users in /etc/security/su-group2-access users which are not in group1 group2 both will not be able to su to anyone root will be able to su to anyone Hope that helps, Change it as per your requirement. Regards Arpit Tolani ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] [Fwd: Re: [Freeipa-devel] stopping su -]
This was probably meant for thew freeipa-users mailing list. Simo. -- Simo Sorce * Red Hat, Inc * New York ---BeginMessage--- sudo -i su - oracle No, you would run sudo -i oracle. -i = simulate initial login. Alternately, you can use sudo -s oracle for run shell as oracle Or you can run sudo -u oracle command -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: OpenPGP digital signature ___ Freeipa-devel mailing list freeipa-de...@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel---End Message--- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] another sudo su question
On 07/17/2012 11:50 AM, KodaK wrote: I've been banging my head on this for a couple of days, and I can't find anything in the docs or by searching. I'm trying to do what I think should be pretty simple: I have a group of users and an application account, all in IPA. I want users in that group to be able to sudo su - appacct. What I've found is that I probably can't do it exactly like that, so now I'm trying sudo -i appacct, but I can't get that to work either. My rule is set up like this: rule name: become-appacct sudo option: -i appacct (I'm not sure this is right.) user groups: admins, appgroup host groups: apphostgroup Everything else is blank. Note that this is just the current configuration, I've tried a bunch of iterations. Any help? Thanks, --Jason If you are using IPA it internally has a different schema for sudo than the one published on the sudo web site http://git.fedorahosted.org/git/?p=freeipa.git;a=blob;f=install/share/65ipasudo.ldif;h=7a85c8659c33794d3127d208452dcb54ad34d59e;hb=HEAD It is then transformed into a traditional sudo schema using the compat tree. So what you need to do is make sure you create the right sudo rule. Your sudo rule should use: user groups: admins, appgroup host groups: apphostgroup command: sudo -i If appacct is a user managed by IPA then he should be selected as run as user. If this account is not managed by IPA it should be an external user Use UI or CLI to add it. Doing it via ldap would not work unless you use the internal schema. objectClasses: (2.16.840.1.113730.3.8.8.1 NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MAY ( externalUser $ externalHost $ hostMask $ memberAllowCmd $ memberDenyCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory $ sudoNotBefore $ sudoNotAfter $$ sudoOrder ) X-ORIGIN 'IPA v2' ) -- 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] another sudo su question
On Tue, Jul 17, 2012 at 11:06 AM, Dmitri Pal d...@redhat.com wrote: On 07/17/2012 11:50 AM, KodaK wrote: I've been banging my head on this for a couple of days, and I can't find anything in the docs or by searching. I'm trying to do what I think should be pretty simple: I have a group of users and an application account, all in IPA. I want users in that group to be able to sudo su - appacct. What I've found is that I probably can't do it exactly like that, so now I'm trying sudo -i appacct, but I can't get that to work either. My rule is set up like this: rule name: become-appacct sudo option: -i appacct (I'm not sure this is right.) user groups: admins, appgroup host groups: apphostgroup Everything else is blank. Note that this is just the current configuration, I've tried a bunch of iterations. Any help? Thanks, --Jason If you are using IPA it internally has a different schema for sudo than the one published on the sudo web site http://git.fedorahosted.org/git/?p=freeipa.git;a=blob;f=install/share/65ipasudo.ldif;h=7a85c8659c33794d3127d208452dcb54ad34d59e;hb=HEAD It is then transformed into a traditional sudo schema using the compat tree. So what you need to do is make sure you create the right sudo rule. Your sudo rule should use: user groups: admins, appgroup host groups: apphostgroup command: sudo -i Thanks. I had some fighting to do to get sudo to talk to ldap on this box, but I have that going now. If I understand you correctly, I've created a rule like you've suggested. however, I get: Sorry, user jebalicki is not allowed to execute '/bin/bash -c cdcadmin' as root on slncdcl01.unix.magellanhealth.com. (I've given up on obfuscation.) Here's the debug output: [jebalicki@slncdcl01 ~]$ sudo -i cdcadmin LDAP Config Summary === uri ldap://slpidml01.unix.magellanhealth.com ldap://slpidml02.unix.magellanhealth.com ldap_version 3 sudoers_base ou=SUDOers,dc=unix,dc=magellanhealth,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=unix,dc=magellanhealth,dc=com bindpw xxx bind_timelimit 5000 timelimit15 ssl start_tls tls_checkpeer(yes) tls_cacertfile /etc/ipa/ca.crt === sudo: ldap_initialize(ld, ldap://slpidml01.unix.magellanhealth.com ldap://slpidml02.unix.magellanhealth.com) sudo: ldap_set_option: debug - 0 sudo: ldap_set_option: ldap_version - 3 sudo: ldap_set_option: tls_checkpeer - 1 sudo: ldap_set_option: tls_cacertfile - /etc/ipa/ca.crt sudo: ldap_set_option: timelimit - 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found! sudo: ldap search '(|(sudoUser=jebalicki)(sudoUser=%jebalicki)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%unixadmins)(sudoUser=ALL))' sudo: found:cn=become-cdcadmin,ou=sudoers,dc=unix,dc=magellanhealth,dc=com sudo: ldap sudoHost '+cdchosts' ... MATCH! sudo: ldap sudoRunAsUser 'cdcadmin' ... not sudo: found:cn=test rule,ou=sudoers,dc=unix,dc=magellanhealth,dc=com sudo: ldap sudoHost '+tdswebhosts' ... not sudo: ldap sudoHost '+cdchosts' ... MATCH! sudo: ldap sudoCommand '/bin/cat' ... not sudo: found:cn=tds-web-restart,ou=sudoers,dc=unix,dc=magellanhealth,dc=com sudo: ldap sudoHost '+tdswebhosts' ... not sudo: ldap search 'sudoUser=+*' sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(0)=0x00 [sudo] password for jebalicki: Sorry, user jebalicki is not allowed to execute '/bin/bash -c cdcadmin' as root on slncdcl01.unix.magellanhealth.com. [jebalicki@slncdcl01 ~]$ And here's the rule: [root@slpidml01 ~]# ipa sudorule-show become-cdcadmin ipa: INFO: trying https://slpidml01.unix.magellanhealth.com/ipa/xml ipa: INFO: Forwarding 'sudorule_show' to server u'http://slpidml01.unix.magellanhealth.com/ipa/xml' Rule name: become-cdcadmin Enabled: TRUE User Groups: admins, stsg Host Groups: cdchosts Sudo Allow Commands: sudo -i RunAs Users: cdcadmin [root@slpidml01 ~]# If appacct is a user managed by IPA then he should be selected as run as user. If this account is not managed by IPA it should be an external user Use UI or CLI to add it. Doing it via ldap would not work unless you use the internal schema. objectClasses: (2.16.840.1.113730.3.8.8.1 NAME 'ipaSudoRule' SUP ipaAssociation STRUCTURAL MAY ( externalUser $ externalHost $ hostMask $ memberAllowCmd $ memberDenyCmd $ cmdCategory $ ipaSudoOpt $ ipaSudoRunAs $ ipaSudoRunAsExtUser $ ipaSudoRunAsUserCategory $ ipaSudoRunAsGroup $ ipaSudoRunAsExtGroup $ ipaSudoRunAsGroupCategory $ sudoNotBefore $ sudoNotAfter $$ sudoOrder ) X-ORIGIN 'IPA v2' ) -- 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
Re: [Freeipa-users] another sudo su question
On Tue, Jul 17, 2012 at 1:40 PM, KodaK sako...@gmail.com wrote: On Tue, Jul 17, 2012 at 11:06 AM, Dmitri Pal d...@redhat.com wrote: On 07/17/2012 11:50 AM, KodaK wrote: I've been banging my head on this for a couple of days, and I can't find anything in the docs or by searching. I'm trying to do what I think should be pretty simple: I have a group of users and an application account, all in IPA. I want users in that group to be able to sudo su - appacct. What I've found is that I probably can't do it exactly like that, so now I'm trying sudo -i appacct, but I can't get that to work either. My rule is set up like this: rule name: become-appacct sudo option: -i appacct (I'm not sure this is right.) user groups: admins, appgroup host groups: apphostgroup Everything else is blank. Note that this is just the current configuration, I've tried a bunch of iterations. Any help? Thanks, --Jason If you are using IPA it internally has a different schema for sudo than the one published on the sudo web site http://git.fedorahosted.org/git/?p=freeipa.git;a=blob;f=install/share/65ipasudo.ldif;h=7a85c8659c33794d3127d208452dcb54ad34d59e;hb=HEAD It is then transformed into a traditional sudo schema using the compat tree. So what you need to do is make sure you create the right sudo rule. Your sudo rule should use: user groups: admins, appgroup host groups: apphostgroup command: sudo -i Thanks. I had some fighting to do to get sudo to talk to ldap on this box, but I have that going now. If I understand you correctly, I've created a rule like you've suggested. however, I get: Sorry, user jebalicki is not allowed to execute '/bin/bash -c cdcadmin' as root on slncdcl01.unix.magellanhealth.com. I got it. I was able to use: Rule name: become-cdcadmin Enabled: TRUE User Groups: admins, stsg Host Groups: cdchosts Sudo Allow Commands: /bin/su - cdcadmin I thought I tried that first, but I must have had something else wrong. Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ 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 Mon, Jul 16, 2012 at 12:23 PM, Rob Crittenden rcrit...@redhat.com wrote: Stephen Ingram wrote: On Mon, Jul 16, 2012 at 11:34 AM, Rich Megginson rmegg...@redhat.com wrote: On 07/16/2012 11:48 AM, Stephen Ingram wrote: On Mon, Jul 16, 2012 at 9:35 AM, Rich Megginsonrmegg...@redhat.com wrote: On 07/16/2012 10:19 AM, Stephen Ingram wrote: On Fri, Jul 13, 2012 at 6:14 AM, Rob Crittendenrcrit...@redhat.com wrote: Stephen Ingram wrote: On Thu, Jul 12, 2012 at 2:59 PM, Steven Jonessteven.jo...@vuw.ac.nz wrote: Hi, I had huge memory issues pre 6.3, now its low and flatSounds like you have an issue somewhere. My normal cpu use is a few hundred mhzbut when something goes wrong such as replication failing that climbs...ditto memory use Yes, I saw your conversation with Rich on this list about that. And, yes, 6.2 (2.1.3) was bad for me too. I'm not sure why 2.2.0 is still having issues. It was an upgrade from 2.1.3, but the upgrade seemed to complete without issue. I'm also not even doing replication yet so I'm not sure why memory is so high. Web interface is much slower too so perhaps something else is wrong. Can you tell where it is being slow? Does it seem related to retrieving data from LDAP? I'm not really sure yet what is causing the slowness. I have the same number of directory entries as before the upgrade. It was very quick with 2.1.3, but once I upgraded, I felt like I was back to the pre-2.0 days--without a doubt much, much slower. You might check your 389-ds access logs and look for searches with notes=U. Perhaps you are missing an index. Yes there are lots of notes=U. What does this mean? Was something missed in the upgrade script? Try running logconv.pl Nice! I'm guessing that notes=U are unindexed searches then. I have 34 over the last 24 hours so I'm not sure this would be causing the issue as the slowness persists through every click. Yeah, I would expect to see a lot more than 34 if that were the cause. Can you post the search filters that are unindexed? Sure, here's a partial list (sanitized): filter=(managedBy=fqdn=ec2-x.x.x.us-west-2.compute.amazonaws.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap2.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=ipa1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn All the rest are the same, just with different hosts. I've traced the unindexed searches back to the time of Web UI access and they don't match. I also don't see any other obvious errors when running logconv.pl. One strange thing I have noticed is that the 389 server logs seem to update in spurts. If I'm tailing the logs while I access a Web UI page, there is nothing, then a couple of seconds later, I see the logs quickly scroll with new entires. Has this always been the case? I don't seem to remember this before. Yes. The 389 access log is buffered, for performance reasons. Just thought it might be relevant. I'm not sure what is causing the extreme slowness. I've also shut off memcached and tried without it with no discernible difference. The directory seems to be handling the load of external queries just fine, although I'm not sure I've solved the memory issue--I'm still testing with the compat plugin disabled to see if I can stop the memory creep. Maybe it's something in the code of the Web UI itself as its even slow when changing from page to page of users and hosts. Shutting of memcached is just going to make things even slower. I really didn't see much difference so I turned it back on right away. Things you can try on a quiet system: 1. Create /etc/ipa/server.conf: [global] debug=True Restart Apache Use the UI to do a few things. Verify in the logs that the session cache is being used. Yes, it is. It's interesting, 2.2 is slower such that you can see the frame load, and then the loading symbol spins below in the display area for a few seconds while that loads up. Before, with 2.1.3, you really couldn't distinguish the two as they loaded so quickly. 2. Check your browser configuration. You don't need delegation-uris set any more. Having it set might mask other problems (you still need negotiation-auth.trusted-uris set). I forgot about this. I changed it, completely cleared the browser cache and accessed without any noticeable difference. 3. Watch what URI is being used in the Apache access log. It should be /ipa/session/json. Check. this is where it lands. 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.
Re: [Freeipa-users] 2.20 dirsrv memory usage
Stephen Ingram wrote: On Mon, Jul 16, 2012 at 12:23 PM, Rob Crittenden rcrit...@redhat.com wrote: Stephen Ingram wrote: On Mon, Jul 16, 2012 at 11:34 AM, Rich Megginson rmegg...@redhat.com wrote: On 07/16/2012 11:48 AM, Stephen Ingram wrote: On Mon, Jul 16, 2012 at 9:35 AM, Rich Megginsonrmegg...@redhat.com wrote: On 07/16/2012 10:19 AM, Stephen Ingram wrote: On Fri, Jul 13, 2012 at 6:14 AM, Rob Crittendenrcrit...@redhat.com wrote: Stephen Ingram wrote: On Thu, Jul 12, 2012 at 2:59 PM, Steven Jonessteven.jo...@vuw.ac.nz wrote: Hi, I had huge memory issues pre 6.3, now its low and flatSounds like you have an issue somewhere. My normal cpu use is a few hundred mhzbut when something goes wrong such as replication failing that climbs...ditto memory use Yes, I saw your conversation with Rich on this list about that. And, yes, 6.2 (2.1.3) was bad for me too. I'm not sure why 2.2.0 is still having issues. It was an upgrade from 2.1.3, but the upgrade seemed to complete without issue. I'm also not even doing replication yet so I'm not sure why memory is so high. Web interface is much slower too so perhaps something else is wrong. Can you tell where it is being slow? Does it seem related to retrieving data from LDAP? I'm not really sure yet what is causing the slowness. I have the same number of directory entries as before the upgrade. It was very quick with 2.1.3, but once I upgraded, I felt like I was back to the pre-2.0 days--without a doubt much, much slower. You might check your 389-ds access logs and look for searches with notes=U. Perhaps you are missing an index. Yes there are lots of notes=U. What does this mean? Was something missed in the upgrade script? Try running logconv.pl Nice! I'm guessing that notes=U are unindexed searches then. I have 34 over the last 24 hours so I'm not sure this would be causing the issue as the slowness persists through every click. Yeah, I would expect to see a lot more than 34 if that were the cause. Can you post the search filters that are unindexed? Sure, here's a partial list (sanitized): filter=(managedBy=fqdn=ec2-x.x.x.us-west-2.compute.amazonaws.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap2.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=ipa1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn All the rest are the same, just with different hosts. I've traced the unindexed searches back to the time of Web UI access and they don't match. I also don't see any other obvious errors when running logconv.pl. One strange thing I have noticed is that the 389 server logs seem to update in spurts. If I'm tailing the logs while I access a Web UI page, there is nothing, then a couple of seconds later, I see the logs quickly scroll with new entires. Has this always been the case? I don't seem to remember this before. Yes. The 389 access log is buffered, for performance reasons. Just thought it might be relevant. I'm not sure what is causing the extreme slowness. I've also shut off memcached and tried without it with no discernible difference. The directory seems to be handling the load of external queries just fine, although I'm not sure I've solved the memory issue--I'm still testing with the compat plugin disabled to see if I can stop the memory creep. Maybe it's something in the code of the Web UI itself as its even slow when changing from page to page of users and hosts. Shutting of memcached is just going to make things even slower. I really didn't see much difference so I turned it back on right away. Things you can try on a quiet system: 1. Create /etc/ipa/server.conf: [global] debug=True Restart Apache Use the UI to do a few things. Verify in the logs that the session cache is being used. Yes, it is. It's interesting, 2.2 is slower such that you can see the frame load, and then the loading symbol spins below in the display area for a few seconds while that loads up. Before, with 2.1.3, you really couldn't distinguish the two as they loaded so quickly. A lot of what gets loaded a just big javascript files. I wonder if there is a DNS problem, that would explain the slowness. The javascript and much of the UI is completely unprotected by anything. 2. Check your browser configuration. You don't need delegation-uris set any more. Having it set might mask other problems (you still need negotiation-auth.trusted-uris set). I forgot about this. I changed it, completely cleared the browser cache and accessed without any noticeable difference. 3. Watch what URI is being used in the Apache access log. It should be /ipa/session/json. Check. this is where it lands. I'm beginning to think this
Re: [Freeipa-users] 2.20 dirsrv memory usage
On Tue, Jul 17, 2012 at 2:01 PM, Rob Crittenden rcrit...@redhat.com wrote: Stephen Ingram wrote: On Mon, Jul 16, 2012 at 12:23 PM, Rob Crittenden rcrit...@redhat.com wrote: Stephen Ingram wrote: On Mon, Jul 16, 2012 at 11:34 AM, Rich Megginson rmegg...@redhat.com wrote: On 07/16/2012 11:48 AM, Stephen Ingram wrote: On Mon, Jul 16, 2012 at 9:35 AM, Rich Megginsonrmegg...@redhat.com wrote: On 07/16/2012 10:19 AM, Stephen Ingram wrote: On Fri, Jul 13, 2012 at 6:14 AM, Rob Crittendenrcrit...@redhat.com wrote: Stephen Ingram wrote: On Thu, Jul 12, 2012 at 2:59 PM, Steven Jonessteven.jo...@vuw.ac.nz wrote: Hi, I had huge memory issues pre 6.3, now its low and flatSounds like you have an issue somewhere. My normal cpu use is a few hundred mhzbut when something goes wrong such as replication failing that climbs...ditto memory use Yes, I saw your conversation with Rich on this list about that. And, yes, 6.2 (2.1.3) was bad for me too. I'm not sure why 2.2.0 is still having issues. It was an upgrade from 2.1.3, but the upgrade seemed to complete without issue. I'm also not even doing replication yet so I'm not sure why memory is so high. Web interface is much slower too so perhaps something else is wrong. Can you tell where it is being slow? Does it seem related to retrieving data from LDAP? I'm not really sure yet what is causing the slowness. I have the same number of directory entries as before the upgrade. It was very quick with 2.1.3, but once I upgraded, I felt like I was back to the pre-2.0 days--without a doubt much, much slower. You might check your 389-ds access logs and look for searches with notes=U. Perhaps you are missing an index. Yes there are lots of notes=U. What does this mean? Was something missed in the upgrade script? Try running logconv.pl Nice! I'm guessing that notes=U are unindexed searches then. I have 34 over the last 24 hours so I'm not sure this would be causing the issue as the slowness persists through every click. Yeah, I would expect to see a lot more than 34 if that were the cause. Can you post the search filters that are unindexed? Sure, here's a partial list (sanitized): filter=(managedBy=fqdn=ec2-x.x.x.us-west-2.compute.amazonaws.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=imap2.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn filter=(managedBy=fqdn=ipa1.example.com,cn=computers,cn=accounts,dc=example,dc=com) attrs=fqdn All the rest are the same, just with different hosts. I've traced the unindexed searches back to the time of Web UI access and they don't match. I also don't see any other obvious errors when running logconv.pl. One strange thing I have noticed is that the 389 server logs seem to update in spurts. If I'm tailing the logs while I access a Web UI page, there is nothing, then a couple of seconds later, I see the logs quickly scroll with new entires. Has this always been the case? I don't seem to remember this before. Yes. The 389 access log is buffered, for performance reasons. Just thought it might be relevant. I'm not sure what is causing the extreme slowness. I've also shut off memcached and tried without it with no discernible difference. The directory seems to be handling the load of external queries just fine, although I'm not sure I've solved the memory issue--I'm still testing with the compat plugin disabled to see if I can stop the memory creep. Maybe it's something in the code of the Web UI itself as its even slow when changing from page to page of users and hosts. Shutting of memcached is just going to make things even slower. I really didn't see much difference so I turned it back on right away. Things you can try on a quiet system: 1. Create /etc/ipa/server.conf: [global] debug=True Restart Apache Use the UI to do a few things. Verify in the logs that the session cache is being used. Yes, it is. It's interesting, 2.2 is slower such that you can see the frame load, and then the loading symbol spins below in the display area for a few seconds while that loads up. Before, with 2.1.3, you really couldn't distinguish the two as they loaded so quickly. A lot of what gets loaded a just big javascript files. I wonder if there is a DNS problem, that would explain the slowness. The javascript and much of the UI is completely unprotected by anything. Hmmm. DNS issues? What sort of things would I be looking for? ipa1.example.com resolves both ways both from IPA and outside nameserver that doesn't connect at all with IPA. Would there be anything else? Could a DNS conflict within the DNS portion of IPA cause an issue?
Re: [Freeipa-users] stopping su -
Hi Actually this for me anyway is exactly what IPA should be forits security, its centrally managed and it saves workload. Doing this across 200+ servers needs to be centralised or IPA becomes pointless, very limited ie one point password, add and remove users (oh big deal I can use salt to do that in effect). As I'd have to do IPA stuff and then localits saves me little if anything in work / automation. Now if it doesn't do this well OK, but half my problem is determining what IPA can and cant do, the devil is in the detail as they say. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 8-- You can lock that down in the sudoers config and you can lock the su permissions to the wheel group via the local configuration files in /etc/security or via the pam module. either way you need to add in configuration file managment, which is not what freeipa is for. 8 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] stopping su -
but presumably I can control sudo with IPA? 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 Dmitri Pal [d...@redhat.com] Sent: Tuesday, 17 July 2012 11:07 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] stopping su - On 07/17/2012 12:40 AM, Steven Jones wrote: Hi, I could do, authrequiredpam_wheel.soroot_only use_uid But I really want to do this with IPA or I have to get on each server and add and remove admins by hand (hint 300 servers)...that is the idea of something like IPA for medo it once centrally. I assume simo's hint is, sudo -i su - oracle AFAIU if you are looking for centrally manged setting you need to use sudo. With su and HBAC IPA can just control which user can authenticate using su but not for local users like root. I think that if the oracle user is centrally managed you would be able to define an HBAC rule that would prevent oracle user from doing su on a group of hosts, but I doubt that this is what you want. Seems like sudo will give you much more flexibility. I will have to experiment. 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 Erinn Looney-Triggs [erinn.looneytri...@gmail.com] Sent: Tuesday, 17 July 2012 4:31 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] stopping su - On 07/16/2012 01:47 PM, Steven Jones wrote: Hi, OK, so to confirm this cant be done in a centralised way via IPA? In which case when setting a HBAC with sshd only why cant i su - oracle but I can su - root? 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 Erinn Looney-Triggs [erinn.looneytri...@gmail.com] Sent: Tuesday, 17 July 2012 9:38 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] stopping su - On 07/16/2012 01:32 PM, Steven Jones wrote: I have craeted a sshd rule only for the HBAC, but I find a std user can su - to root, is this correect behavior? How do I? or can I? stop this unless explicitly allowed? 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 You need to control this via PAM. So for me I restrict su to only be allowed for members of the wheel group, from /etc/pam.d/su: authrequiredpam_wheel.souse_uid There are comments in the file that will get you where you want to go. -Erinn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users I can't speak to whether it can or cannot be done centrally in any sort of authoritative way, might be possible there are hbac setting for su and I can't really answer your question about suing to oracle. -Erinn ___ 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] another sudo su question
This is exactly my sort of thing as well. We seem to be in the freeipa group yet ppl are telling me to use pam.d...no one has really said you cannot do this in IPA, or you can and this is how.. :/ The very idea of using IPA is to stop having to do such local configuration 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 KodaK [sako...@gmail.com] Sent: Wednesday, 18 July 2012 3:50 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] another sudo su question I've been banging my head on this for a couple of days, and I can't find anything in the docs or by searching. I'm trying to do what I think should be pretty simple: I have a group of users and an application account, all in IPA. I want users in that group to be able to sudo su - appacct. What I've found is that I probably can't do it exactly like that, so now I'm trying sudo -i appacct, but I can't get that to work either. My rule is set up like this: rule name: become-appacct sudo option: -i appacct (I'm not sure this is right.) user groups: admins, appgroup host groups: apphostgroup Everything else is blank. Note that this is just the current configuration, I've tried a bunch of iterations. Any help? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ 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] How to set a user group rule to allow su - oracle only?
Thankyou. :D regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Simo Sorce [s...@redhat.com] Sent: Wednesday, 18 July 2012 10:18 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] How to set a user group rule to allow su - oracle only? On Tue, 2012-07-17 at 22:06 +, Steven Jones wrote: Can I get this clarified as I am getting really confused, Can I do this in/via IPA or not? Yes or no I think will suffice. Not using 'su', but you can using sudo as explained in other messages. 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] How to set a user group rule to allow su - oracle only?
Hi, Thanks...yes I dont care how as such. Im trying to translate traditional linux/unix ways of doing things into IPA where possible...maybe that's where I'm communicating poorly and causing confusion, sorry about that. Its like english and french, I want the french but only have the english words to ask in. :/ su - root can be local, thats OK as that is unique and exists locally. But I need to do a lot of as kodak wants and have a group of users login as themselves and then get to an application user. Typically this would be say oracle...but I dont want the user oracle to be able to ssh in...so that can be IPA controlled, I know, which I'd rather do than putting a deny into sshd_configas when you want to refresh a database you could have a HBAC for Oracle defined between 2 specific hosts for a set length of time say. 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 Erinn Looney-Triggs [erinn.looneytri...@gmail.com] Sent: Wednesday, 18 July 2012 10:17 a.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] How to set a user group rule to allow su - oracle only? On 07/17/2012 02:06 PM, Steven Jones wrote: Can I get this clarified as I am getting really confused, Can I do this in/via IPA or not? Yes or no I think will suffice. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 *From:* Arpit Tolani [arpittol...@gmail.com] *Sent:* Tuesday, 17 July 2012 11:13 p.m. *To:* Steven Jones *Cc:* Rob Crittenden; freeipa-users@redhat.com *Subject:* Re: [Freeipa-users] How to set a user group rule to allow su - oracle only? I think that is because you are talking about two separate things. You want to control entry to root via su, this may or may not be controllable with IPA, but probably not. You want to control entry to the oracle user via sudo and restrict that to a group of users, that is entirely possible within IPA. -Erinn ___ 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/17/2012 05:43 PM, Stephen Ingram wrote: [ details of performance analysis snipped for brevity ] I wonder if we shouldn't add some timing metrics to our code. As it is it's very hard to know where time is being spent. When I wrote the session code I added some timestamps used for managing session timeouts. It wouldn't be too hard to expand this to time how long it takes a command to execute because it's evaluated for every command. Combined with timestamping in the UI code we could get a reasonable idea of where some bottlenecks lie (or don't). -- John Dennis jden...@redhat.com 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
