On Tue, May 20, 2014 at 02:00:18PM +0100, Dylan Evans wrote:
Hello,
I need some help with getting Samba and FreeIPA working together.
I’ve been following the guide at
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration but
that seems quite out of date for IPAv3 and I need
On 22.5.2014 14:19, Sumit Bose wrote:
On Tue, May 20, 2014 at 02:00:18PM +0100, Dylan Evans wrote:
Hello,
I need some help with getting Samba and FreeIPA working together.
I’ve been following the guide at
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration but
that seems quite
Where should my clients be getting the contents of /etc/openldap/certs from?
I've got one network where my IPA authentications are blazing fast and
one where they're ... not. On the slower one, clients'
/etc/openldap/certs directories are either missing or empty; on the
faster network,
Bret Wortman wrote:
Where should my clients be getting the contents of /etc/openldap/certs from?
I've got one network where my IPA authentications are blazing fast and
one where they're ... not. On the slower one, clients'
/etc/openldap/certs directories are either missing or empty; on the
What we're seeing is slow GDM logins, ssh authentications, and sudo -i
responses on this network. On our other, these things are all blazing
fast. Here, they're on the order of 5-10 seconds. And it doesn't seem to
improve (much) with age or time, except perhaps anecdotally. At best, a
second
On 05/22/2014 09:43 AM, Bret Wortman wrote:
What we're seeing is slow GDM logins, ssh authentications, and sudo
-i responses on this network. On our other, these things are all
blazing fast. Here, they're on the order of 5-10 seconds. And it
doesn't seem to improve (much) with age or time,
I found that our slower system was using FQDNs for the list of IPA
servers; our faster system was using IPs. I'm switching now, letting
Puppet distribute the update and will see if it helps.
By enumeration, do you mean are we spelling out our IPA servers? Yes. We
only have 3 and they look
Go figure. I rebuilt it (again) cleanly, and after starting replication
again, while I was madly trying to change the debug level on the new
replica...it completed replication this time.
Heisenbugs. Gotta love them. (I think this one was in my network
somewhere, not your code -- I just
On Thu, May 22, 2014 at 10:36:45AM -0400, Bret Wortman wrote:
I found that our slower system was using FQDNs for the list of IPA
servers; our faster system was using IPs. I'm switching now, letting
Puppet distribute the update and will see if it helps.
By enumeration, do you mean are we
On 05/22/2014 10:36 AM, Bret Wortman wrote:
I found that our slower system was using FQDNs for the list of IPA
servers; our faster system was using IPs. I'm switching now, letting
Puppet distribute the update and will see if it helps.
That means you have problems with DNS that are worth
It doesn't seem to have helped -- we're still pretty slow even with IP
addresses in sssd.conf.
On 05/22/2014 11:07 AM, Dmitri Pal wrote:
On 05/22/2014 10:36 AM, Bret Wortman wrote:
I found that our slower system was using FQDNs for the list of IPA
servers; our faster system was using IPs. I'm
If this line is in /etc/nsswitch.conf:
passwd: files sss
Why would the user account from IPA get used when an identical one
exists in /etc/passwd? We can tell because of some additional groups
granted when authentication comes from IPA.
If I shut down sssd, then login proceeds through
On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote:
If this line is in /etc/nsswitch.conf:
passwd: files sss
Why would the user account from IPA get used when an identical one
exists in /etc/passwd? We can tell because of some additional groups
granted when authentication comes from
A. Then it's probably not the source of my performance problem. I
know when I shut down SSSD, that user's ssh times speed up incredibly.
Bret
On 05/22/2014 01:06 PM, Simo Sorce wrote:
On Thu, 2014-05-22 at 12:47 -0400, Bret Wortman wrote:
If this line is in /etc/nsswitch.conf:
passwd:
On Thu, 2014-05-22 at 13:12 -0400, Bret Wortman wrote:
A. Then it's probably not the source of my performance problem. I
know when I shut down SSSD, that user's ssh times speed up incredibly.
This makes me think it *is* initgroups, as it normally will hit sssd
even for non-sssd owned
Yep, that initgroups change had the same effect as shutting down sssd,
but without inconveniencing all the IPA-only users.
The problem in this particular case was made worse by a lot of network
latency, but even on network segments local to the ipa masters, it's
taking seconds to
On Thu, May 22, 2014 at 11:16:57AM -0400, Bret Wortman wrote:
It doesn't seem to have helped -- we're still pretty slow even with
IP addresses in sssd.conf.
Yes, I would expect the performance to be still slow, because when you
perform authentication, the user information is always refreshed
On Thu, May 22, 2014 at 01:22:28PM -0400, Bret Wortman wrote:
Yep, that initgroups change had the same effect as shutting down
sssd, but without inconveniencing all the IPA-only users.
The problem in this particular case was made worse by a lot of
network latency, but even on network
On 05/22/2014 02:25 PM, Jakub Hrozek wrote:
On Thu, May 22, 2014 at 11:16:57AM -0400, Bret Wortman wrote:
It doesn't seem to have helped -- we're still pretty slow even with
IP addresses in sssd.conf.
Yes, I would expect the performance to be still slow, because when you
perform
On 05/22/2014 11:16 AM, Bret Wortman wrote:
It doesn't seem to have helped -- we're still pretty slow even with IP
addresses in sssd.conf.
Then we need debug logs to see where the delays are. Put high debug
level and zip the logs somewhere we can take a look at.
Jakub is your guy.
On
Dear All,
Is there any command to export the user and host list to a csv or text format
Regards
Sanju Abraham
___
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
21 matches
Mail list logo
