Solaris - DMI error

We kept getting the following error on a number of servers (all running Solaris 10 update 10):

snmpXdmid: Registration with DMI failed. err = 831

After hunting around I found that the error is related to one of two issues:
1. Missing patch (138361-02 or later), or
2. Database files need clearing out

Having checked that the patch was there:
# patchadd -p | grep 138361-02
Response:
Patch: 138361-02 Obsoletes: 128415-01 137019-02 Requires: Incompatibles: Packages: SUNWsacom SUNWsadmi

(Checked MOS to see if this was the latest patch, which it was).

Which left clearing down the snmpXdmid database:
# svcadm disable dmi
# rm /var/dmi/db/*
# svcadm enable dmi

Once cleared down the error disappeared......

References:
http://docs.oracle.com/cd/E19082-01/819-2379/swmgrpatchconcepts-30/index.html
https://forums.oracle.com/thread/2242176

Azure - Accessing the first VM from work

Well, we have gone and bought some Azure time/space and as one of the Consultants said "It's like leaving some money behind the bar". If that's the case, I'll have a Guinness......

First of all getting access seemed a bit long winded - someone has to gain access to the account and then delegate some sort of server admin role so VMs can be created.

Deploying a VM is pretty easy - New > Virtual Machine > Quick Create (or From Gallery).

Once the VM created you click on the Connect icon down the bottom of the screen and a RDP shortcut is downloaded.

Double clicking on the shortcut, at work, produced the normal failure to connect due to Firewall rules.....

What we needed to do was:

1. Double click on the machine name.
2. In the new Window click on Endpoints links.
3. Change the *PUBLIC PORT to 3389 (same as the PRIVATE PORT).
4. Change the Firewall rules so that 3389 is open to (and from) the *MS Datacentres IP ranges that we use.

* By default MS Windows Azure assigns a port in the dynamic range (49152–65535) for Remote Desktop
* A list of IP ranges per Datacentre can be found here

Solaris - ludelete and zones

An update on patching zones (which is why the information came to light).

I have noticed that when you create a BE on a server running local zones and then patch it an additional zone directory is created. But when I delete the old BE the old zone directory didn't go with it...... If it creates the folder when I lucreate why doesn't it delete when I use ludelete? Maybe it was just naive of me to expect it to be removed.......

For example if I wanted to patch a server running a zone called ZONE1, first of all I would create a new BE and call it for arguments sake newBE. Once the BE creation had completed my zone folder location would look something like this:

/export/ZONE1 (running BE)
/export/ZONE1-newBE (BE to be patched)

Then I would run the unzipped CPU against the newBE.

When all the patching has occurred, the newBE has been activated and a reboot has occurred ZONE1 is now running from /export/ZONE1-newBE.

 At some point in the near future I would do some tidying up and remove the old BE by running ludelete and then check the number of BEs by running lustatus.

But when I check the /export directory it shows both folders still being there.

Luckily you can remove the old directories with no issues, but to be safe check first what directory the zone is running from by typing:

zoneadm list -iv

Now to amend the Work Instruction so others at work know what needs to be done.......

FYI - Oracle say this is normal behavior, but I don't  recall reading anything about it (but it doesn't mean there isn't - I just haven't seen it!).

Solaris - finding and restarting services

The other day I was looking to restart a service on a Solaris 10 server as a management console was reporting that is couldn't connect to the service.

(In this example I'm looking for all Sophos services)

# svcs -a | grep sophos

online         Feb_18   svc:/com/sophos/sav/sav-protect:default
online         11:09:43 svc:/com/sophos/sav/sav-update:default
online         11:51:47 svc:/com/sophos/sav/sav-rms:default

So I've found the services: How do I restart one?

# svcadm restart svc:/com/sophos/sav/sav-rms:default

Or using its short unique name:

# svcadm restart sav-rms

online         Feb_18   svc:/com/sophos/sav/sav-protect:default
online         11:09:43 svc:/com/sophos/sav/sav-update:default
online         11:51:47 svc:/com/sophos/sav/sav-rms:default

The service should now be back online but what happens when the service doesn't comeback as online?
You have to enable the service if it goes into maintenance (not sure why this happened as I had run the same command on other servers without the service going into maintenance).

online         Feb_18   svc:/com/sophos/sav/sav-protect:default
online         11:09:43 svc:/com/sophos/sav/sav-update:default
maintenance11:51:47 svc:/com/sophos/sav/sav-rms:default

# svcadm enable sav-rms

online         Feb_18   svc:/com/sophos/sav/sav-protect:default
online         11:09:43 svc:/com/sophos/sav/sav-update:default
online         11:51:47 svc:/com/sophos/sav/sav-rms:default

VMware - My experience of upgrading from 4.1 to 5.0 update 2

**************************************************
Update:

We found an interesting article prior to updating the Hosts to ESXi 5.0 in which a NFS disconnect issue is highlighted - so we haven't upgraded to 5.0 as yet. Also impacts 5.1.

Impacted products: vSphere 5.0, NetApp also EMC.
***************************************************
 
My experiences of upgrading from 4.1 to 5.0.......

The test upgrade of a database (existing VC DB restored to another server) worked fine. Just the normal glitches of not being given the correct rights to upgrade the DB the first time of asking - dbo right on the DB and MSDB (the one that gets missed).

The test of the new feature of Web Client Server went well - the test of VPN connection using a user account proved access/connectivity to the nominated VM.

The testing ticked all the boxes. Excellent!

Production upgrade didn't go too well - it failed with a SQL script error every time on the first two days.
A call was logged with VMware to get assistance as no amount of Googling helped.

The VMware Engineer asked for a number of SQL DB checks to be done and set the Logs to unlimited growth. On the third day all steps were followed and the upgrade still failed. After the second restore and prior to the roll back to vSphere 4.1 one of the DBAs checked to see what differences there were between the Production DB and the Test DB - the only difference was the Compatibility level in the Database Properties (Test set to SQL Server 2008 (100) and Production set to SQL Server 2005 (90)). Production had its setting changed to SQL Server 2008 (100) and the upgrade worked!!

Once the upgrade completed VUM was upgraded followed by the Web Client Server install - no problems were encountered with either of these.

Now for the interesting bits.....

• Some SSL issues mainly around the Web Client Server.
• My VPN access isn't least privilege and therefore port 9443 wasn't open for general users - Firewall and VPN change required.
• Web Client users getting  "Empty Inventory" when they connect which happens to be a known error - fix can be found here. I used the Domain Users group and gave them Read rights at the top level with no propagation.
• Web Client users unable to see VMs they have console access to. The previous fix had been applied approximately 1 hour prior to the user trying Web Client. My tests, adding the console rights the user had to my user account, also failed to see the any VMs. Approximately another hour later the user checks and can see most of the VMs now. Checking my user account I can see ALL of the VMs that the user has access to. Permissions propagation issue????
• During my testing to see why the user couldn't access the VMs I applied Read Only right to the Domain Users group at a Host and one of the impacted VMs - which looking back wasn't a good idea. Why? The least privilege rule applied which meant my Domain Admin account went from having full Virtual Center Admin rights to Read Only. This meant I couldn't do anything - at the time we thought it was something to do with the upgrade. This then had a knock on affect to our nightly backup as this account also belonged to the Domain Users group - the NetApp backup failed just because ONE machine out of 300 didn't have the right permissions. What happened to error checking??  Logged a call with VMware and before the lady rang us the epiphany hit (least privilege trump card). With VMware support we went through logging into the VI Client as the Administrator account (in our case the local admin account on the VC server) and since it had nothing to do with Domain authentication and had the highest level permissions I could remove the Domain Users Read Only from the Host and VM. Checking Web Client access and everything was working.
• Annotations permissions have changed - Support staff can't edit the notes. The next day, with no changes applied, they could edit the notes....

Lessons learnt:

• Have a VPN account which is mimics least privileged access.

VMware - SSL

Having recently upgraded from vSphere 4.1 to vSphere 5.0 Update 2 we are currently suffering from some SSL issues - all appeared to be resolved apart from one (which is the new Web Client service).

Being lucky enough to be in a team large enough where we have some specialists the SSL certificate errors were resolved quickly.

Goggling around a bit there seems to be a number of people suffering from SSL issues and I found some interesting articles written by Michael Webster which are listed below:

http://longwhiteclouds.com/2012/02/24/updating-ca-ssl-certificates-in-vsphere-5/

http://longwhiteclouds.com/2012/02/07/the-trouble-with-ca-ssl-certificates-and-vcenter-5/

http://longwhiteclouds.com/2012/09/15/vcert-manager-changing-vmware-ssl-certs-made-easy/

Solaris - recover a root password in a local zone

Someone managed to reset the root password of a local zone incorrectly which resulted in a machine we couldn't log in as root......

To fix it log in to the global zone as root.

Edit the shadow file of the offending local zone (e.g. Local zone is called LZ01)

# vi /zones/LZ01/root/etc/shadow

Edit the root entry in the shadow file like so:

root::15435::::::

The save the entry (esc key, colon, wq!)

Log in to the console of the local zone from the global zone:

# zlogin -C LZ01

Log in as root (which now just logs you in without prompting for a password).

Reset the root password.

# passwd root

Follow the prompts.......