Survey says....What would you like to see in the next version of HP-UX?

[Geoff Wild]

What would you like to see in the next version of HP-UX?

For me, to be able to modify the size of any lvol in vg00 - on the fly. Having to boot to LVM maintenance mode to increase /stand seems almost archaic.

Rgds...Geoff

[Steven E. Protter]

I would like to see this:

1) The ability to boot a kernel with /stand as a vxfs filesystem.

2) I would like to be able to run by box with one filesysetm and lvm.

3) Build Mirror/UX into the base OS. It is ridiculous to run a Enterprise Server and not include the ability to set up basic mirroring.

I can go on, but I have a meeting.

With regards to your wish, there are some good reasons why / and other filesystems have to be strict contiguous, but I hear you.

SEP

[John Poff]

Hi Geoff,

How about having nearly all the kernel parameters be dynamically tunable?

JP

[Patrick Wallek]

Geoff,

The solution to that is to make /stand plenty big from the get-go. ;) My standard is 256MB.

I would LOVE to see a truly dynamic kernel so that I can install patches without having to reboot the machine, thus saving the painful downtime requests.

I would like to see the capability for true mirrored-stripes (or is that striped mirrors?) for with LVM, for those of use that still use a significant amount of JBOD.

While not related to HP-UX functionality, I would also like to see HP do away with the per processor licensing for HP-UX. I am not a big fan of that.

Hmm......What else.....I'm sure I'll think of something eventually.

[Kevin Wright]

I guess my main thing would be Mirror/UX with the Base OS. A completely dynamic kernel would be great, and they are working on it. Shadow password files by default would be nice too.

[Martin Johnson]

I'd like to see Compaq's (formally, DEC's) true cluster technology incorporated into HPUX. Let's have a *REAL* cluster instead of the pitiful excuse for a cluster called MC/ServiceGuard.

Marty

[Michael Elleby III_1]

Hello-

Gotta go with dynamic sizing capabilities of vg00.

Mike-

[curt larson_1]

those would all be great enhancements. I'd certainly appreciate them, but I won't list them again.

but how about some tools that can handle large files, i.e. how many mega terabytes is the largest file I can create with a 64 bit file system, yet what is the maximum line length in vi. what is the maximum number of fields for awk. what is the largest file i can backup using tar or cpio or pax. how many lines can I tail?

What i'm getting at is file size far out strips the tools for processing files.

how about a shell with modern capabilities, al la ksh93, i.e. ability to pass arrays to functions, associative arrays, subtititute string for pattern (${param/pattern/string}, substring with offset (${param:offset[:length]}, floating point arithmetic, the condiditional operator (?:), postfix and prefix operators (++ and --), pattern matching via character classes ( [:alnum:], [:digit:], etc.), and the string equality operator (==).

[John Bolene]

AIX includes online JFS for free, why not HP?

Martin, the True64 clustering will be in the verssion next year.

I want HP-UX on all Intel, not just Itanium.

[Caesar_3]

Hello!

I would like to see that the HPUX kernel
will be dynamic, that would be no need
to do compilation and reboot if you
change kernel parameters.

Caesar

[Duncan Edmonstone]

Martin,

You will get your wish - all the good features of TruCluster (clustered file system, single system image) will make their way into ServiceGuard over the next 2 years...

As for me, I'd agree with what everyone has already said:

1) Dynamic kernel changes
2) Dynamic (no reboot) patching
3) VxFS (or AdvFS) for all filesystems
4) MirrorDisk/UX as part of base OS

To this I would add:

5) APA (NIC teaming) as part of the base OS
6) Its about time that HP started re-investing in LVM - features that need to come if they don't want to end up completely 'in hoc' to veritas:
- True dynamic multi-pathing
- No hard coded limits (max pe per pv particularly)
- More fully featured cluster LVM (might come with the TruCluster technology).
7) But by far the biggest thing that HP can do to improve HPUX right now is change the FC/SCSI hardware adressing scheme! The current hotch-potch of three addressing schemes (volume set addressing, peripheral device addressing and logical unit addressing) is a nightmare to use, and pretty much whenever you change your SAN config you end up with a completely new hardware path and set of device files. Why can't this be based on something that I can configure (like a lookup based on WWN, target and LUN)

Interesting thread though... keep them coming...

HTH

Duncan

[Michael Steele_2]

lsof, tcpdump, openssh and any other GNU product from The Utah or Wisconsin HPUX porting center that are now basic tools in a S.A.'s toolbox.

http://hpux.cict.fr/hppd/hpux/Sysadmin/lsof-4.64/

[Duncan Edmonstone]

John,

The reason that OnLine JFS is free on AIX is cos IBM own the code... it therefore doesn't cost them much to give away...

HP's OnLine JFS is of course just Veritas VxFS, and every time HP sell it, thay have to give most of the cost of a license straight to Veritas. You can see how this would quickly eat into margins if it were given away... HP would still need to pay Veritas for every copy sold.

Of course HP now own their own journalling file system (Tru64's AdvFS), and I think we can expect this to become available (maybe for free) as an alternative to OnLine JFS at some point in the next 2 years... its' certainly a pre-requisite for a TruCluster.

Cheers

Duncan

[Michael Steele_2]

I'd like administrative control of disks back. Proprietary hands off or void your support contract threats from disk array admins has created this sub culture of disk array admins that has spread onto every platform and worse, has seriously cut into my importance. It takes a committee meeting just to build a volume group. And also added more people into change management at a time when change management was already too big.

Out of curiosity, can anyone beat 18 people in change management?

[Tim D Fulford]

I'd like to see

LVM:
o much higher limits on disk sizes (max PE per PV)
o More LVs per VG (currently in 11.0 255)
o Able to mirror kB stripes
o Able to move kB stripe extends from PV to PV
o have a higher PV's per VG.
- the above would make migration to new server or new disk subsystem far easier

Kernel:
o Truly dynamic kernel (mentioned a few times)

MC/ServiceGuard:
o Mirored memory etc such that failovers would not need to interupt the service

That is all I can think of now!

Tim

[Geoff Wild]

Good answers everyone - about points - I'm only going to award 5 points per person - not post.

Well, at least I'm going to try :)

Feel free to post multiple posts - just don't take the 0 points the wrong way :)

Rgds...Geoff

BTW - The reason I need to increase /stand?
First of - I inherited the box - some boxes at this site were built by previous admins...Second - prereq for 11i is 112MB min for /stand. Our standard is 128MB (but I'm thinking of increasing to 256MB).

[Michael Steele_2]

Use ignite make_tape_recovery and restore via advanced install options. Because /dev/vg00/lvol1, 2 and 3 are all contiguous. /stand is lvol1.

[twang]

1. tune kernel parameters without reboot
2. all online JFS functions
3. system performance statistic like oracle's v$sysstat

[KCS_1]

Hi,Geoff
Thanks for opening this thread.

I would like to see managing tools( or script) on hpux,such as the 'nikel' for looking at the event logs and status of H/W more easily if,it's available. Include of above mentioned things as well.

Contratulation! got on a new hat of HOGWATT!



Have a good day!

[Fragon]

Hi,
1. I think a x86 based HP-UX is necessary! Many people need it;
2. Security enhancement, for example ,a firewall integrated, SSH default;
3. Of course, dynamic kernel parameters!

-ux

[Geoff Wild]

Michael Steele,

Yes, that's what I was going to do - until I found this - lvol3 is 1 GB - and not used - lvol4 is root /

weird...

So, I'm going to try this:

Instead of make_recovery/restore, I thought I would try the following:

Boot your machine in LVM maintenance mode
(hpux -lm at ISL>)

#
# vgchange -a y /dev/vg00
# lvrmboot -r /dev/vg00
# lvremove /dev/vg00/lvol3
# lvremove /dev/vg00/lvol2
# lvextend -L 128 /dev/vg00/lvol1
# extendfs /dev/vg00/rlvol1
# lvcreate -L 1024 -C y -r n -n lvol2 /dev/vg00
# lvlnboot -b /dev/vg00/lvol1
# lvlnboot -r /dev/vg00/lvol4
# lvlnboot -s /dev/vg00/lvol2
# lvlnboot -d /dev/vg00/lvol2
# lvlnboot -R
# reboot -r


Rgds...Geoff

[Massimo Bianchi]

Hi,
in addition to everyone else suggestion, i stress the need for many used tools like tcpdump, lsof, screen in the base distribution, is pretty annoying to download them every time.

Dynamic Kernel would be fine, but such a dyanmic reallocation worries me a bit

And i would like more recent documents shipped on the /usr/share/doc, maybe with the updated information. Thay can be so helpfull..

And the true base support for largefile, everywhere. when you use 64bit executables is ridiculos to rememeber why these and those won't work... same for ksh, still stuck with an hardcoded limit of blocks. it should be not used in a 64bit O.S.

One thing i would NOT see any more are the java-base gui that HP is shipping.

TUI works very weel, and is at low processor cost.
If one wants pretty things, can use Motif interface, the so calle GUI.

But why java ? At lest for mainenance tasks, i want something i can rely on. Now i'm thinking at tools like arm*....

java for interoperability sounds like things working bad everywhere, to me...

Massimo

[Massimo Bianchi]

Hi,
in addition to everyone else suggestion, i stress the need for many used tools like tcpdump, lsof, screen in the base distribution, is pretty annoying to download them every time.

Dynamic Kernel would be fine, but such a dyanmic reallocation worries me a bit

And i would like more recent documents shipped on the /usr/share/doc, maybe with the updated information. Thay can be so helpfull..

And the true base support for largefile, everywhere. when you use 64bit executables is ridiculos to rememeber why these and those won't work... same for ksh, still stuck with an hardcoded limit of blocks. it should be not used in a 64bit O.S.

One thing i would NOT see any more are the java-base gui that HP is shipping.

TUI works very weel, and is at low processor cost.
If one wants pretty things, can use Motif interface, the so calle GUI.

But why java ? At lest for maintenance tasks, i want something i can rely on. Now i'm thinking at tools like arm*....

java for interoperability sounds like things working bad everywhere, to me...

Massimo

[Jdamian]

1. changing kernel parameters without reboot.
2. about LVM:
2.1 increasing limits
2.2 solving problems of LVM: max PE per PV, max LV number, PE size, ...
2.3 new commands to handle physical volume groups (PVG)
2.4 encapsulating physical paths (primary and alternate paths) into virtual physical disks, i.e., creating LVM disk names for now-known physical volumes (disks as /dev/dsk/c1t2d0), meanwhile the concept called 'DISKPATH' is introduced.
2.5 previous point would allow load-balancing in multipath disks.
2.6 LVM API (system calls, shared libraries ...)
3. Advanced VxFS free !
4. increasing length limits of usernames and hostnames.
5. including CD-ROM formats as RRIP into kernel instead of using different daemons and protocols (PFS) for RRIP cds.
6. a network service for accessing remote devices (devices attached to another system)
7. rotating logs, at least, for system logs; so that syslog.log and other logs aren't lost after more than 2 reboots.
8. manual pages for those undocummented commands/utilities and for those unknown inet services that you never heard (have you used VT).
9. Secure system as default: passwords out of /etc/passwd; inet services as NFS, NIS, RBOOTD, VT, ... disabled; secure shell included in primary installation.

[Jdamian]

I forgot to include:

- A.P.A. free !
- lsof, tcpdump and other utilities.
- commands to query hardware (number of CPU, amount of memory, CPU speed instead of reading kernel using adb debugger).
- commands to handle timestamps.