Anyone know the default password for equallogic sans?

R

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
I'm trying grpadmin / grpadmin, either the password was changed or there's something else I could try.

Been called out because of issues and it looks like it's storage related and of course none of this info is documented.
 
That is the correct default information, looks like it has been changed. Can you ask the guys that should do maintenance to try some of their normally used passwords with the grpadmin account?
 
I'm one of thsoe guys. LOL. Problem is I'm not the one that set it up, and nobody documents around here. Tried a bunch of our typical passwords.

Turns out I don't think I need to connect to it anymore anyway, and I'll have to give the other guy hell for not documenting his stuff. :D

Nothing like the iSCSI switches randomly going down at 4:00am on a Monday. Seems doing a rescan is getting the VMs back up though.
 
Aah, unfortunately I know that feeling. That's why I set up a password safe in our environment and made people use it. Most of our documentation is still stuck inside one guys head though...

Good to hear its working again though!
 
Was my coworker, and it was a non default password. I got it now and updated our documentation.

It's actually pretty bad that my home environment is better documented then at work LOL.
 
Honestly not sure what model, two of the smaller enclosures were bought about a year ago (one is SAS other is Sata) and we bought a bigger Sata enclosure this year. I know it is PS something. :D
 
I'm at work now so just checked. The two smaller ones are PS5000 and the new one is PS6000.
 
Red Squirrel said:
I'm trying grpadmin / grpadmin, either the password was changed or there's something else I could try.

Been called out because of issues and it looks like it's storage related and of course none of this info is documented.
Click to expand...
how do you change it? i dont have the id and password
 
CollieFjep said:
That is the correct default information, looks like it has been changed. Can you ask the guys that should do maintenance to try some of their normally used passwords with the grpadmin account?
Click to expand...
hi.. did you find anything out? i have the same issue.
 
JerseyGiant said:
how do you change it? i dont have the id and password
Click to expand...
You need to have the admin password to change the admin password. If you don't have it, you need to contact EL Support, or if you have physical access and want to reset it yourself then see the following info:

To temporarily reset the grpadmin account password to the default factory-set password, follow these steps:

1.) On one group member, connect the appropriate serial cable to serial port 0 (the correct cable will be different on different models of the PS Array) on the active control module. The active control module is indicated by the green control module status LED labeled ACT. The status LEDs are located on the controllers sometimes on the left side or next to the serial port on other controllers.

2.) Turn off power to the member (if you have dual power supplies, turn off both power supplies). Volumes with data located on the member will be offline and iSCSI connections to those volumes will be lost until the member is restarted.


3.) If the member has two control modules, after it is shut down, remove the controller that your serial cable is not connected to. This is to ensure that, while you are setting password-recovery mode on one controller, the other controller doesn’t run past us and start the array up. Controllers just have to be removed a little so they don’t make contact any more to be disabled. (2 cm out is far enough)

4.) Turn on power to the member by turning on all the power supplies.

5.) While the member is restarting, press Ctrl/p when the following message appears on the console: Press Ctrl/p to enter setup mode. This will halt the boot process and allow you to enter commands to the boot monitor.

6.) At the CFE> prompt, enter the following commands, which are case-sensitive and must be typed exactly as shown:

CFE> setenv RESETPASSWORD 1

CFE> reload

7.) When the member restarts, the PeerStorage login prompt appears. After a short pause, the following message should appear: WARNING:password recovery mode… Temporarily resetting grpadmin password.

If you get the previous message, log in the the group using the grpadmin account and its factory-set password, grpadmin: Login: grpadmin Password: grpadmin

At this point, you are logged in to the group with read-write permission and can perform any group administration task. At this point, you should set the grpadmin account password to a known value. Use the procedure described in the Modifying Accounts section in the Group Administration manual or use the following command:

> account select grpadmin passwd

Enter New Password: xxxxxxx

Retype password: xxxxxxx

Note: Unless you set the grpadmin account password within five minutes after the password recovery mode message appears, the grpadmin password will revert back to the value it had prior to the password reset procedure (that is, you will no longer be able to log in with the factory-set password).

However, as long as you remain logged in to the grpadmin account, you can set the password to a known value. If the password recovery mode message does not appear, the password reset procedure did not succeed (for example, because you did not enter the CFE commands exactly as shown). In this case, allow the member to completely start up, and then retry the password reset procedure, shutting down the member and following the steps above.

8.) If the member has two control modules, after logging in to the group and setting the grpadmin password, reinsert the second controller, this restarts the secondary control module and allows it to be used. Within one minute, you should see a console message, indicating that the secondary control module is operational.
 
JerseyGiant said:
how do you change it? i dont have the id and password
Click to expand...

I don't recall, been a while and I work another job now but if it's the incident I have in mind, it turned out that I was able to refresh the volumes in ESXi and it fixed the issue and did not need to get into the SAN. Basically a switch hiccuped and despite the system being setup with redundancy, it failed (I told them we should test it before it went production but they did not want to). I would have probably been trying to get into the SAN to check logs etc to get an idea of what is going on, as ESXi was showing that the storage was unavailable and did not want to do anything that could render the problem worse. I basically bit the bullet and did a storage refresh to see what happens, and it ended up working. The VMs continued on where they left off. That was scary. This is minor compared to what we deal with at my current job though, if something goes down it's taking out a whole community not just a company. :p

As a side note, I find it terrible that some of these routines (such as password reset outlined above) involve having to reboot or otherwise make the SAN unavailable. A SAN is not something you ever ever ever want to reboot. Firmware updates are another bad one. When we got a new SAN enclosure, the whole selling point of these is that you can hook it up and basically introduce it with the new one and they automagically work with each other. WRONG. Because you need to update the old one, which involves a reboot. And scheduled downtime etc... what is suppose to be a seamless operation ends up requiring to impact the entire organization.
 
Red Squirrel said:
I don't recall, been a while and I work another job now but if it's the incident I have in mind, it turned out that I was able to refresh the volumes in ESXi and it fixed the issue and did not need to get into the SAN. Basically a switch hiccuped and despite the system being setup with redundancy, it failed (I told them we should test it before it went production but they did not want to). I would have probably been trying to get into the SAN to check logs etc to get an idea of what is going on, as ESXi was showing that the storage was unavailable and did not want to do anything that could render the problem worse. I basically bit the bullet and did a storage refresh to see what happens, and it ended up working. The VMs continued on where they left off. That was scary. This is minor compared to what we deal with at my current job though, if something goes down it's taking out a whole community not just a company. :p

As a side note, I find it terrible that some of these routines (such as password reset outlined above) involve having to reboot or otherwise make the SAN unavailable. A SAN is not something you ever ever ever want to reboot. Firmware updates are another bad one. When we got a new SAN enclosure, the whole selling point of these is that you can hook it up and basically introduce it with the new one and they automagically work with each other. WRONG. Because you need to update the old one, which involves a reboot. And scheduled downtime etc... what is suppose to be a seamless operation ends up requiring to impact the entire organization.
Click to expand...
that's why you have two fabrics right? when one switch goes down [due to upgrade or well something unplanned :) ] you have second fabric still serving all needs, though ofc performance will suffer as you have only 50% available now.
Bad thing is if some server doesn't have properly present luns from both fabrics...then its funny :)
 
Dual controllers and dual fabrics... We update our SANs with everything up and everything just keeps on going... Seeing at worse a latency spike...

We have Eql EMC and Netapp... We usally do it off hours but we don't shit anything down..
 
You must log in or register to reply here.
Back
Top