On 28.4.2014 20:05, Bret Wortman wrote:
On 04/28/2014 01:53 PM, Simo Sorce wrote:
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
What shell do you use ?
On Mon, 2014-04-28 at 13:43 -0400, Bret Wortman wrote:
Does it make any difference if you redirect stdin before calling the
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
To sum it up for people coming from search engines:
It is not a FreeIPA problem, it is pure PEBKAC  :-)
Freeipa-users mailing list