On 04/28/2014 01:53 PM, Simo Sorce wrote:
No, I found the problem. A "power" user had written a bash function that redefined "ipa" and dropped it into /etc/profile.d. We're about to have a little chat.On 04/28/2014 01:32 PM, Simo Sorce wrote:On Mon, 2014-04-28 at 13:25 -0400, Bret Wortman wrote:On 04/28/2014 01:19 PM, Bret Wortman wrote:I just got a new ipa server instantiated and haven't actually installed any users or hosts on it yet. No replicas. No migrated data.Yet when I run any "ipa" commands from the command line, it behaves exactly as our older, troubled servers do and exits the login session immediately, whether I'm connected at the console or via ssh. Further, when I run strace to try to capture what might be going on, the behavior stops. "Script" also prevents commands from exiting, but this is really disconcerting. I was chalking this up to the fact that our database had become corrupted by our replication problems, but now I'm thinking it might be environmental, though our original IPA servers are running F18 and this new instance is F20. I need some stability here, and CLI is part of that. What might be causing the CLI to not work at all when coupled to a TTY device, as that seems to be the critical piece? Could this be related to the servers being VMs?BTW, we have this running on F20 on a different network and it works just fine. The network on which the failures are occurring isn't internet-connected; is there something that's trying to connect back to redhat?no. What shell do you use ?On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote:bash.Does it make any difference if you redirect stdin before calling the command ? Simo.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
