Licenses of HP Symantec products expiring in 2007

[Reena Sethy]

This is to remind customers that certain HP Symantec product licenses may expire in 2007 and hence need to be re-installed, only if they were installed from one of the following media:
o HP-UX 11.00 media
o HP-UX 11i v1 application media dated before September 2005
o HP-UX 11i v2 application media dated before June 2005
o HP-UX 11i v1 OE media dated before September 2005
o HP-UX 11i v2 OE media dated before June 2005

This license expiration issue impacts only the following licensed HP Symantec products:
o Veritas Volume Manager B9116AA
o Veritas Cluster Volume Manager B9117AA
o HP OnlineJFS (B3929CA, B3929DA and B5118CA)

Please visit the website at "http://www.hp.com/softwarereleases/releases-media2/" to access the same customer letter subject "06/07 Licenses of HP Symantec products expiring in 2007".

Should you need further assistance, please contact HP-UX support team or HP regional licensing centers as provided in the attachement.

[Steven E. Protter]

Thanks for your post.

It should be noted that systems administrators might have found this more useful had it been posted before the OnlineJFS expired.

This issue has disrupted a number of organizations that relied on these products.

SEP

[Yogeeraj_1]

Hi,

This has been indeed been a tough experience troubleshooting and finding a workaround for this problem at 4:00 am on june 24.

More info is available at:
http://www.hp.com/softwarereleases/releases-media2/notices/June28_v12.pdf

For those who are not on support, they should submit your request at:
http://licensing.hp.com

Good luck!
cheers
yogeeraj

[Mr.Tom]

You should also be aware that failure to install the permanent license for OnlineJFS may have ramifications when the server is rebooted, or the file system is unmounted, and remounted. The following options on the mount command (and then indirectly the file /etc/fstab) will not be in affect:

* detainlog
* mincache=direct, mincache=dsync, mincache=unbuffered, and mincache=tmpcache
* snapof=filesystem
* snapsize=size
* convosync

The response center believes that all the systems that did NOT have their license files updated, are mini ticking timebombs waiting to blow up.

I would urge you to ensure that all your systems have their OnlineJFS licenses up-to-date to help prevent issues that may occur as a result. If they don't, and don't have the media or a depot in which to install an enabled Online JFS license, then there will be a significant scramble, and extention to any resulting downtime to obtain the media and install the permanent license.

[Yogeeraj_1]

Hi again!

I believe that this is something very serious when you consider that there are many HP systems across the world that are running uninterrupted for months or even years. Many customers may still not be aware of this 'time bomb'.

I think HP should choose better ways to get to their customers. As the saying goes: "better late that never..."

Just my thoughts...

kind regards
yogeeraj

[Duncan Edmonstone]

Actually, HP made all customers with active support contracts aware back in June 2006:

http://www.hp.com/softwarereleases/releases-media2/notices/0606symantec.pdf

Which I would say is plenty of time to fix the issue.

Of course it's an unfortunate truth that many people simply don't read the material that accompanies their support updates, but this just goes to show *you should*

If you didn't get the warning and have an active support contract, I guess its time to double check what contacts are listed on ITRC's Software Update Manager

HTH

Duncan

[Bill Hassell]

Unfortunately, the URL was pasted from a document that did not properly isolate the URL:

>
Please visit the website at " http://www.hp.com/softwarereleases/releases-media2/"

The corrected URL is:

http://www.hp.com/softwarereleases/releases-media2

However, this leads to a rather dense list of stuff. The actual document is:

http://www.hp.com/softwarereleases/releases-media2/notices/mc-edited.pdf

Now this document talks about Symantec stuff -- which makes it easy to overlook that this are really Veritas products. There are two commands that can be used:

vxlicrep
or
/sbin/fs/vxfs/vxenablef

You can also just run fsadm -b to change a filesystem size and see the error (ERRNO 28). Some of the reasons that many admins missed the notification:

1. not under software support
2. changes in support people, email addresses, paper mail addresses
3. notices sent to purchasing agents rather than sysadmin
4. 3rd party sysadmins that don't get any email
5. the notice talks about Symantec and Veritas, with the OnlineJFS buried in the list -- easy to overlook
6. The notice has nothing to indicate that this a serious problem, like RED lettering.

In some cases, systems are using these features (like snapshot and resizing) in scripts that are failing without notice. True, the scripts should have had every important task tested for failure, but every sysadmin should be testing every system (11.11 and higher) for this condition immediately.

[Yogeeraj_1]

hi,

Bill,

Concerning the two commands you have mentioned above:
vxlicrep
or
/sbin/fs/vxfs/vxenablef


When run on two of our *Identical* servers, this is what we get:

Server2:>date
Mon Jul 16 08:10:17 MRU 2007
Server2:>uptime
8:07am up 7 days, 8:17, 2 users, load average: 2.58, 2.11, 1.50
Server2:> /sbin/fs/vxfs/vxenablef
System is not licensed
Server2:>

Server1:>date
Mon Jul 16 08:12:21 MRU 2007
Server1:>uptime
8:08am up 37 days, 3:57, 1 user, load average: 1.55, 1.91, 1.93
Server1:>/sbin/fs/vxfs/vxenablef
System is licensed for features
Full_VxFS HP_DMAPI
Server1:>

Server2 was restated on June 24 while Server1 has been running for 37 days now! It seems that you get the "System is not licensed" ONLY after the system has been restated. Is it not confusing?

There is general tendency not to *patch* systems that are running smoothly. I believe, on *humanitarian* grounds, all local HP support providers should contact their customers immediately (even if the system is no longer on support).

just my thoughts...

kind regards
yogeeraj

[chris huys_4]

> There is general tendency not to *patch*
> systems that are running smoothly.

If thats a general tendency, then the tendency is wrong. Every major upgrade of youre system, (OS upgrade/application upgrade/hardware upgrade) or at least once a year, should be used to update the system with the proper patches.

Better have a system that brakes down after a scheduled patch upgrade, but due to a unknown bug, then a system that brakes down due to a known and thus to be avoided patch problem.

The uptime of youre systems, will be much higher in the end..

Oh yes, the patches you need to install per product are the patches that you will find in the productfilesets.. (maintenance and support for hp products -> patches -> patch database -> find HP-UX patches in a patch set )

[Bill Hassell]

> Server2 was restated on June 24 while Server1 has been running for 37 days now! It seems that you get the "System is not licensed" ONLY after the system has been restated. Is it not confusing?

Yes, because the problem code is unexpected. NOTE: The issue is with *EVERY* system that has OnlineJFS installed. It is meaningless to run the license check on a system where the product is not installed. Bottom line: if fsadm -b fails, you've got a big problem. What is worse if after a reboot. Even if you don't reboot for 6 more months, when you do, *ALL* of the mountpoints listed in /etc/fstab that have optional features like mincache will fail and the server is now broken until you reinstall the corrected license.

> There is general tendency not to *patch* systems that are running smoothly. I believe, on *humanitarian* grounds, all local HP support providers should contact their customers immediately (even if the system is no longer on support).

Also known as:

If it ain't broke, don't fix it, or the ostrich method for patch management.

In this case, it *IS* broken and using either fsadm -b or rebooting will cause major problems. The only difference is that instead of trashing the system right now, it will be a mess when you reboot.

I understand the reasoning behind not-broke = no-patch because in the past, a patch caused a problem. But hiding won't make the known errors go away -- they'll show up soon.