SSMC Customer Feedback

[MammaGutt]

And even if that was a 100% correct: Are there more federation environments than peer persistence setups?

Highly doubtful. But I've had a few cleanups where someone has accidentally added hosts to the wrong array, and accidentally present non-PP setups from two arrays to a single host or host set (and no, that not pretty).

[ailean]

Sooo… SSMC 3.4 and beyond is only going to be available as an appliance... they kept that one quiet...

[nicDM77]

Is this the right place to rant about the new 3.4 deployment style?

Today I installed the new SSMC 3.4 template (OVF deploy).
Although I see the benefit of providing a ready-to-run template from a support point of view, I see a lot of issues with the way the OS is security tightened behind a sudo conf.

I have several 3PARs in different domains, but with the limited interfaces that have been written, it is impossible to use 3.4 due to that.

For instance the following command to add several search domains and several DNS servers, simply doesn't work:
/ssmc/sbin/ConfigDNS.py -d xxx.xxxxxxxx.be -d yyyy.xxxxxxx.be -d zzzz.xxxxxxx.be -s 10.0.0.2 -s 10.0.0.1
It onlytakes the last "-s" and last "-d" option.

Also, when I map a DNS alias to my servers DNS entry, using that as a web address will fail due to the bad configuration in /etc/hosts in the appliance. #facepalm

I think there should be an option in the config_appliance to lift the sudo limitation, with plenty of disclaimers and warnings, so that people with multiple 3PARs in multiple domains and more complex configuration requirements (and who know what they are doing) can at least do their thing.

Even if in that way the SSMC enviromnent becomes broken, it's just a matter of redeploying the image in worst case.

Or they could just provide the root password, that would be ok as well

Admittedly, the integration of Infosight in the dashboard is a nice feature, but with the trouble around the OS configuration, I'm going to keep using 3.2 for now

[MammaGutt]

............
I have several 3PARs in different domains, but with the limited interfaces that have been written, it is impossible to use 3.4 due to that.

For instance the following command to add several search domains and several DNS servers, simply doesn't work:
/ssmc/sbin/ConfigDNS.py -d xxx.xxxxxxxx.be -d yyyy.xxxxxxx.be -d zzzz.xxxxxxx.be -s 10.0.0.2 -s 10.0.0.1
It onlytakes the last "-s" and last "-d" option.

Also, when I map a DNS alias to my servers DNS entry, using that as a web address will fail due to the bad configuration in /etc/hosts in the appliance. #facepalm
..........

Trying not to go there, but I can't help myself.

If you manage multiple arrays in multiple domains with a requirement for multiple DNS servers this surely can't be your biggest problem.
First of all, keeping a consistent username and password across multiple domains would probably be a hazzle for you and anyone else requiring to log on to the 3PARs. I'm guessing you're falling back on 3paradm (or similar type of local account for all 3PARs) leaving no trace of who's actually done changes (unless you are the only one).
Secondly, this would impact everything you manage in every domain you have, not just 3PAR. I'm taking a stab in the dark that your management station has a hosts file from hell.....

.... I could go on, but as you clearly have firewall openings between all the domains (as you only require a single SSMC instance to manage all) I can't grip why there isn't a management domain with one-way trust that allows you to have a single central account to manage any equipment, with DNS forwarding to the other domains so you don't need a huge amount of DNS servers configured for your SSMC appliance.

The whole point of an appliance is that it is a black box that you don't fiddle with and don't break. Simple for the vendor to manage and support, usually more performance effective for the rest of the world. If I didn't read the requirements incorrect, they've added a rather powerful performance engine to SSMC without lifting the VM requirements from the Windows-based one...... I never had a single support case for IMC... I've lost count for the ones for SSMC which was either caused by the Windows-installation it was running on or was fixed by restarting the server/service. From the limited experience I have with 3.4 now I've yet to experience an issue(maybe ask me again in a few months ).

With the limited information you provide it seems like your biggest problem is the design of your infrastructure, not "limitations" in SSMC. The only reason I see for "keeping the worlds" that divided is if they are to be completely isolated, but in that case you wouldn't have port openings to use a single management console for all environments.

[nicDM77]

First of all, keeping a consistent username and password across multiple domains would probably be a hazzle for you and anyone else requiring to log on to the 3PARs. I'm guessing you're falling back on 3paradm (or similar type of local account for all 3PARs) leaving no trace of who's actually done changes (unless you are the only one).

Why would you assume it's a hazzle? You still do user management manually? (see, I can also assume stuff)
I have almost everything automated with ansible & python frameworks, among others to keep the users in sync across all 3PARs. Every service (api, SSH users & keys, ...), purpose & operation level has its own user entry with specific restrictions.
And no, I keep 3paradm tucked away for HPE Support people (which btw, was a hazzle to explain why I chose to alter its default password to something more secure, as per the directive that we need to abide to)

I'm taking a stab in the dark that your management station has a hosts file from hell.....

Nope, why would it? With the right set of DNS servers and search domains you don't need it. That's what they are for.

.... I could go on,

Please don't. You don't know our environment (how can you, I only gave some brief highlights) and make assumptions that make me question the way you manage yours. But I won't, how can I, you only gave some brief highlights

For the sake of the (needless) discussion, let's just assume we have plenty of people who know plenty about their own knowledge domain to set things up properly and secure and that it all fits together well, given the (physical & logical) restrictions and guidelines sometimes enforced by other directives.
Is there room for improvement? No doubt, in every environment there is, but it is what it is and we have to make the best of it.

you don't need a huge amount of DNS servers configured for your SSMC appliance.

I don't, all I need are 3 DNS servers and 3 additional search domains, which isn't that extraordinary to ask for in bigger environments. (again: yay for automation frameworks ...)
It's not possible in its current form, given for instance ConfigDNS.py limiting it's argument parsing to just one value per option.
Unfortunately they don't have an upstream public repo, otherwise those SSMC devs would already have a pull request to fix that shortcoming #collaboration

Don't get me wrong, I wholeheartedly agree that black boxing a product or service for the convenience of both the user and their own support organization is a very good choice.
(admittedly, I would've preferred it if they went directly for containers instead of hyper-v/vmware templates, but hey, beggars can't be choosers)
My point (which got lost in my rant?) is that they assume (there it is again ) the simplicity of every environment it will run in.

So I would've liked to see either the option to still use the SSMC installer as they used for all the previous versions, or extend some features here and there with the management scripts they provide in this build, to offer some more (simple) controls.
It's not that much to ask for, no?

[profp62]

i installed for one of my customers appliance 3.4. Hmm ...
Two questions (at least) :
1) First, i tried to migrate version 3.3 config, ok no problem. But after migration, i have the old self signed certificate with wrong server name (old windows server). I didn't find the way, how to regenerate self signed certificate. Probably with keytool, but is someone, who knows the right syntax and keystore location ? I found only
viewtopic.php?f=18&t=2451
with link to
https://www.bytesizedalex.com/hp-3par-s ... placement/
I ended with new deployment without config migration...
2)
I'm not able to connect the appliance to HPE InfoSight. Connectivity to InfoSight enabled, StoreServ in InfoSigh with valid support.
Certificate (optional) pasted, password correct, but when i type acount id, it writes
"HPE Passport Account User Name should be a valid email address"
?! This is normaly not true - anywhere is this only User Name ...
Nor User name, nor associated email works for me ...
3)
The way how to set DNS and NTP is not production ready, i'm sorry. This is at most beta version ...

[nicDM77]

I'm not able to connect the appliance to HPE InfoSight. Connectivity to InfoSight enabled, StoreServ in InfoSigh with valid support.
Certificate (optional) pasted, password correct, but when i type acount id, it writes
"HPE Passport Account User Name should be a valid email address"
?! This is normaly not true - anywhere is this only User Name ...
Nor User name, nor associated email works for me ...

Have you checked your appliance is allowed to break out to the HPE servers? Or maybe a breakout via a proxy?

The way how to set DNS and NTP is not production ready, i'm sorry. This is at most beta version ...

HPE provided me the following info, how to use ConfigDNS:

Code: Select all

sudo /ssmc/sbin/ConfigDNS.py -d “mgt.xxxxxxx.be corp.xxxxxxx.be labo.xxxxxxx.be” -s 10.0.1.10,10.0.0.10

Notice how they change the type of delimiting in the same script...
The syntax for the search domain and how it's written in /etc/resolv.conf, but from the point of providing a consistent script syntax I personally would've written - and documented in argparse - differently.
Anyway, this should do the trick I guess.
No idea how to provide multiple ntp peers though.