I appreciate all the ideas on how to fix the SSL cert issue on updating to 4.5.0, I'll work on that next week I hope.
This one should be much quicker (hopefully). My boss has insisted that I get ipa-clients working on a half-dozen or so servers located in Alaska. (Believe me, I argued strenuously over this, but was told 'no unicorns'.) I've got all but two working, though login times range from 1-5 minutes depending on the weather. These last two are on incredibly unstable links, I've spent three weeks updating just the core packages to get the ipa-client to /install/. We're talking average 20-30% packet loss and an average download speed for updates of ~500B/s to 10kB/s. They are satellite links, all of them, by the way.
That said, finished up getting one ready and this morning tried to join the domain. It took about ten minutes and bombed with:
Joining realm failed: libcurl failed to execute the HTTP POST transaction. timed out before SSL handshake
So, is there a way to up the timeout for this? I can up the timeout for curl on the command line, but I don't think that would help with this issue. Any ideas?
Mark Haney via FreeIPA-users wrote:
I appreciate all the ideas on how to fix the SSL cert issue on updating to 4.5.0, I'll work on that next week I hope.
This one should be much quicker (hopefully). My boss has insisted that I get ipa-clients working on a half-dozen or so servers located in Alaska. (Believe me, I argued strenuously over this, but was told 'no unicorns'.) I've got all but two working, though login times range from 1-5 minutes depending on the weather. These last two are on incredibly unstable links, I've spent three weeks updating just the core packages to get the ipa-client to /install/. We're talking average 20-30% packet loss and an average download speed for updates of ~500B/s to 10kB/s. They are satellite links, all of them, by the way.
That said, finished up getting one ready and this morning tried to join the domain. It took about ten minutes and bombed with:
Joining realm failed: libcurl failed to execute the HTTP POST transaction. timed out before SSL handshake
So, is there a way to up the timeout for this? I can up the timeout for curl on the command line, but I don't think that would help with this issue. Any ideas?
That's a tough one. ipa-client-install makes many (a dozen?) connections while it does its thing.
You might try pre-generate the host entry and keytab, ship it to the machine, then use the --keytab option. ipa-join does less in that case though it would still be prone to failure. I'm not aware of a way to increase the TLS timeouts.
Not sure if your company policy will allow it but you could also manually (or puppet or ansible) configure the machine. You'd need to push in a keytab, krb5.conf, sssd.conf, etc. but using a CM mechanism it would at least be reproducible assuming those are more tolerant of the packet loss.
rob
On 10/12/2017 01:32 PM, Rob Crittenden wrote:
Mark Haney via FreeIPA-users wrote:
That's a tough one. ipa-client-install makes many (a dozen?) connections while it does its thing.
You might try pre-generate the host entry and keytab, ship it to the machine, then use the --keytab option. ipa-join does less in that case though it would still be prone to failure. I'm not aware of a way to increase the TLS timeouts.
Not sure if your company policy will allow it but you could also manually (or puppet or ansible) configure the machine. You'd need to push in a keytab, krb5.conf, sssd.conf, etc. but using a CM mechanism it would at least be reproducible assuming those are more tolerant of the packet loss.
rob
Yeah, I was afraid of that. The really big issue is that even manually copying files of any size fails ~50% of the time. I've not done a manual setup, but it might be the only way to get these working. Personally, the fact I'm spending weeks working on this, when NO ONE on staff will ever log in using their IPA credentials is just silly and a waste of my (very well paid) time. I appreciate the help and I'll work on a manual setup.
Maybe some holy water wouldn't be a bad idea.....
Mark Haney wrote:
On 10/12/2017 01:32 PM, Rob Crittenden wrote:
Mark Haney via FreeIPA-users wrote:
That's a tough one. ipa-client-install makes many (a dozen?) connections while it does its thing.
You might try pre-generate the host entry and keytab, ship it to the machine, then use the --keytab option. ipa-join does less in that case though it would still be prone to failure. I'm not aware of a way to increase the TLS timeouts.
Not sure if your company policy will allow it but you could also manually (or puppet or ansible) configure the machine. You'd need to push in a keytab, krb5.conf, sssd.conf, etc. but using a CM mechanism it would at least be reproducible assuming those are more tolerant of the packet loss.
rob
Yeah, I was afraid of that. The really big issue is that even manually copying files of any size fails ~50% of the time. I've not done a manual setup, but it might be the only way to get these working. Personally, the fact I'm spending weeks working on this, when NO ONE on staff will ever log in using their IPA credentials is just silly and a waste of my (very well paid) time. I appreciate the help and I'll work on a manual setup.
Maybe some holy water wouldn't be a bad idea.....
On the bright side if anyone were ever to log into the machines then the sssd cache would likely make it far easier on subsequent attempts.
rob
On 10/12/2017 02:06 PM, Rob Crittenden wrote:
Mark Haney wrote:
Maybe some holy water wouldn't be a bad idea.....
On the bright side if anyone were ever to log into the machines then the sssd cache would likely make it far easier on subsequent attempts.
rob
True. Forunately, we rarely have to access these servers directly. The high-latency links were known well in advance and the boxes were setup accordingly to be as fully self-sufficient as possible.
Though, this has been a great way to not be quite so nostalgic about the 'good old days' before Gore invented the internet. 300/600/900/1200 Baud modems weren't really all that great.
freeipa-users@lists.fedorahosted.org
-
Mark Haney -
Rob Crittenden