This post is more than 5 years old
4 Posts
0
3658
March 8th, 2013 00:00
ISILON VAAI plug-in: auth_gen Segmentation fault
Hi there,
we're trying to configure VAAI NAS Plug-In for ISILON on our vSphere servers. Vib install works fine but running auth_gen causes a segmentation fault:
~ # /usr/lib/vmware/nas_plugins/isi_plugin_credential/auth_gen
Please enter the hostname:nfs.isilon.example.com
Please enter the username and password with total max of 64 characters with only letters and numbers
Username:root
Please enter the password
Please enter the password again
*** glibc detected *** /usr/lib/vmware/nas_plugins/isi_plugin_credential/auth_gen: free(): invalid next size (fast): 0×08072438 ***
Segmentation fault
We're running vSphere ESXi 5.1.0 914609, vCenter Server 5.1.0 880146, isilon_nas_vaai_plugin-1.0-834058 and OneFS 7.0.1.3.
We've opened a support ticket with EMC on this. Their first proposal was a reinstall of the plugin. This didn't change anything.
Any ideas?
Regards
Timm Stamer
christopher_ime
6 Operator
•
2K Posts
0
March 13th, 2013 21:00
TimmStamer,
Firstly, again thank you for the update.
I received some feedback from engineering, and they actually believe it is related to an already known issue in the current release of the plugin (fix is under review for an upcoming update). Basically, while maintaining the limitations as already noted above:
Please enter the username and password with total max of 64 characters with only letters and numbers
If the password is 8 chars long (or divisible by 8), this causes the same segmentation fault. This is reproducible in the lab. Can you confirm for us:
1) The number of characters of the original password
2) The number of characters of the new password
We suspect that the original password was 8 chars long (or divisible by 8), and it wasn't the leading numeral that corrected it; instead the new password was now less than (or greater than 8 chars). The engineer that had responded tried to reproduce with the focus of a leading number but was unable to.
Can you confirm? Thank you in advance.
christopher_ime
6 Operator
•
2K Posts
0
March 8th, 2013 23:00
Timm,
Sorry for asking, but can you confirm that the Isilon root account password is as minimally complicated as it requires? If not, as a quick test, can you change the root password temporarily to something very short and simple such as maybe a single letter and then try again? I think we can rule out though you aren't exceeding 64 chars, but is it possible you are using something other than letters and numbers?
TimmStamer
4 Posts
0
March 11th, 2013 07:00
Christopher,
yes, I can confirm that our Isilons root account password machtes the requirements/limitations of letters and numbers only and its not exeedings 64 chars. There are no letters included that could be difficult to german keyboard layout. The hostname took 39 chars.
Regards
TimmStamer
4 Posts
0
March 12th, 2013 08:00
You may reproduce this error by setting a root-password beginning with a number
Solution: do not use a password for root beginning with a number.
christopher_ime
6 Operator
•
2K Posts
0
March 12th, 2013 19:00
Wow, that is of course unexpected. Thanks for the update! I'll send an update also to engineering to review (and fix).
TimmStamer
4 Posts
0
March 15th, 2013 00:00
Christopher,
yes I can confirm that our old password was exact 8 characters. New password is 15 characters long.
On Wendsday we've deployed vaai plugin to our VIEW environment. At evening time there was redeploy of several desktop pools which caused great trouble at our ISILON. Isi_papi_d service consumed much cpu time. We've eleminated this incident by removing vaai plugin from VIEW vsphere hosts. Have you ever heart about such behavior?
Regards,
Timm
christopher_ime
6 Operator
•
2K Posts
0
March 15th, 2013 02:00
Thanks for verifying the length of the original and new password. This confirms for us that it is the same known issue of having a password that is 8 chars (or divisible by 8 but no more than 64 chars).
As for the issue you had with the service I'm thinking you probably promptly reverted it, understandably of course, but did you by chance capture logs while this was happening (isi_gather_info) and/or have an existing support case? In the meantime, I have brought your comments to their attention.