Configuring YaST for the SRM components

I do not think its supported but you can use zypper like this just get the correct SLES ISO for the patch level the appliance runs on.

mkdir /mnt/cd mount /dev/cdrom /mnt/cd zypper addrepo /mnt/cd/ cdrom zypper refresh #list all packges in repo zypper pa -ir cdrom
zypper install net-snmp

EMC does not support installation of additional packages on vApp deployments by end users.  The packages on the vApp are chosen to supply a bare minimum of needed function and limit required maintenance and security updates, and changes to that set of packages could cause issues with upgrades and service.

That said, we are constantly reviewing customer feedback on additional packages which increase usability and serviceability in vApp deployments.  Future releases will see additional utilities provided, based on customer demand and technical feasibility.

Well, that would have been really good to know before EMC persuaded us to go the vApp route. We spent considerable time trying to get Watch4net to even run on our builds after which time PS said "just go the vApp route. So sure, the vApp is simple and gets out of the gate fast but they are quite deficient when it comes to hooking them into monitoring systems, doing troubleshooting, etc. Case and point - tcpdump - where is it? Not on any SRM machines that I can see.

Another is the lack of SSSD - to do LDAPs - where is it? This is just the beginning I'm sure.  If we cannot install other packages then what?

I've run in to similar issues in getting scheduled backups to run.  I thought I was being slick in getting our Networker guys to give me the module to do hot backups of the MySQL database.  No such luck - none of the required SuSE libraries are included in the stripped down distro.  Don't get me wrong - I love how fast the vApp is compared to the Windows servers we used in the previous versions, but it comes at the price of customizability.

We have tried to strike a balance between optimizing the SUSE build we use for the SRM vApp vs. limiting its manageability.  By only including the packages we need, we reduce the memory/CPU requirements, simplify configuration, and dramatically reduce the security exposures. 

Our policy is that the vApp is meant to be an appliance -- a black box, if you will.  So although we provide the root login information, adding additional software will put you out of support.  That being said, we've accommodated some additions via a RPQ (Request for Platform Qualification), which your account team can submit on your request.  We'd also like your input on which modules you feel are necessary to properly manage the appliance.  We already plan to add the SNMP daemon in our next release based on customer feedback.  We're not trying to be unreasonable - we're just trying to balance the benefits of a limited distribution with the requirements you have for managing the vApp.

Thanks,

Dan

I mostly understand - but no tcpdump?

Is it OK for us to configure LDAP and sudoers for user authentication?

Is is OK to install a backup client?

Where does the line actually stop for what can or cannot be done?

I think my biggest gripe is that the PS people did not not make it very clear as to what the limitations would be with the vApp decision.

thanks,

Dave

It has been a while Daniel.

I suspect this might be a hot topic at the User Group meeting at EMC World this year. Will you be there?

I'll have to look into the option of using vDPA. Right now we still have this siloed enough that it won't likely be easy. Our BRS guys don't touch vSphere and our Compute guys (who manage vSphere) don't do backups. There might be a way around that, but having a Networker client available would make life much easier. When my account team recommended that we not deploy the vApps they didn't mention any other options to back up either. It seemed like there was nothing.

Do you happen to know if this vDPA is a core part of vSphere or a licensed add on? If it is in the core then we might still be able to do something and avoid the nasty Windows VMs for our deployment.

Thanks, Dan.  I really do like the vApp appliances, even after discovering the undocumented limitations.  Given the choice of raw power over the ability to change things - I'll usually take the power when it comes to SRM.  Downhill has a valid point, though - there are things which some organizations must have in any server (robust security, centralized backups, etc.)

What about an EMC-maintained distro library with a limited number of optional features that have been optimized for the environment?  Yeah - I know this opens up a whole new can of worms, but it might let me add a Networker plug-in and downhill add the SSSD features.

Just a thought...

Daniel

Hey, Allen - long time no talk!

Yeah - we went ahead and deployed before looking at backup solutions.  Ouch!  I've been using the manual database backup utilities on the vApp, but have recently automated it somewhat to do a hot copy to another server.   From EMC support, the only supported way right now is to backup using VMware vSphere Data Protection Advanced 5.8.  Avamar is supposed to be vDPA's big brother, so we are looking into leveraging that in our new data center.

Word from the ASD is that a Networker solution for SRM is in the works.

Here is the link to using vDPA with SRM: https://community.emc.com/docs/DOC-41512

Daniel

We haven't deployed yet (it's in the planning stages now) but we were advised by our account team to avoid the vApps due to the limitations on installing packages. It might be an appliance, but I can't deploy an OS image in our environment that I can't even back up. Other people have their own "ABSOLUTELY MUST HAVE" items, but we are a Networker shop and I can't even back up my EMC appliances with my EMC backup solution!!! If I can't back them up I can't deploy them. We have to settle for Windows VMs instead.

On the backup front, we have a document describing how to use the backup bundled with VMware, which is based on Avamar.  We're enhancing our documentation and support policy to include the installation of other backup clients onto the vApp, starting with NBU...stay tuned for an announcement when that's available.

As for EMC World, we're planning our User Group meeting for Thursday from 8-2.  Those of you who attended last year should have received a Hold the Date announcement from Paula this week.  Anyone else who would like to join should reach out to their account manager to request an invitation.

Dan

Yes, I’ll actually be participating in one of the SRM sessions – “What’s New in SRM”.

vDPA is a licensed add-on & would likely be run by the vSphere guys (Virtual Infrastructure team for us). That’s why we won’t be using it, too. Avamar is likely the way we’ll go unless the Networker-SRM solution comes to fruition and has better functionality.

If you aren’t using it already, I’d recommend getting the MySQL Workbench from Oracle. I use it to run queries on the databases to help me write reports in SRM. It also allows you to do hot backups within it, though I haven’t stopped long enough to test a restore (too many projects these days). It would be nice to hand that over to the BURA guys.

See you in Vegas!

#EMCWORLD

@sanmanjax

I've shared the list of utilities you'd like to see added with the team that develops the appliance images for all EMC vApps.  I'll let you know what they think about including some of these in future builds.

As to your other questions:

- SRM supports authentication via LDAP.  There's a new GUI for configuring it in 3.6.

- We support sudo (and PowerBroker) for host discovery.

- As I mentioned above, we're qualifying some backup clients for install in our next release.

- SRM supports authentication via LDAP.  There's a new GUI for configuring it in 3.6.

     Yes the app supports ldap, but what about authentication to the OS (SUSE) not many places will allow everybody running around with shared root or local accounts?

- We support sudo (and PowerBroker) for host discovery.

     They are talking about having support to enable using sudo or the like in SUSE

Exactly our point in the beginning. We would like to be able to hook the OS into LDAP, not just the app. SSSD just makes it better.

It is somewhat amusing to see the different suggestions coming from the various sales/PS teams on this topic. I for one am not impressed with the limitations the vApp has imposed on this deployment and if someone has a document on how to migrate the data and configurations from a vApp deployment to a more mainstream install on RHEL (or other customer builds) that would be great as we decide whether to stick this out and deal with the RFQs and future "enhancements" or start over with a new slate.

For those of us who cannot make it to EMC World, hopefully someone will take these gripes and give them a voice.

thanks