This guide about installing HP Storage Essentials CIM Extension was written for HP-UX 11i v1. The following patches are the minimum prerequisites you need to have installed on the system, it may vary depending on the version of your OS.
Read More
This guide about installing HP Storage Essentials CIM Extension was written for HP-UX 11i v1. The following patches are the minimum prerequisites you need to have installed on the system, it may vary depending on the version of your OS.
This is my first bug I’ve found in HP-UX. In the following story I modified some data to protect our customers privacy. According to the white book of our customer, a user integrated into a HA package need to be created with a symlinked home directory like this:
# ll -d /home/user1
lrwxr-xr-x 1 root root 27 Jul 21 2006 /home/user1 -> /package/home/user1
#
Finally we can get some unusual large LUNs at my customer, but this arose some problems that we didn’t have until now. The read/write performance of a filesystem built from such very large LUNs can suffer if certain scsi parameters aren’t set. Here is an HP document that describes how you can solve this problem:
The “ulimit” and “limit” commands are often built into the shell, but there may exist some binaries with the same name. For example:
# /usr/local/bin/bash
bash> type ulimit
ulimit is a shell builtin
bash> which ulimit
/usr/bin/ulimit
Read More
Here is a quick guide on how autonegotiation supposed to work:
When both sides are set to autonegotiation, they will negotiate the speed and the duplexity and the maximum supported will be the common speed/duplexity. If one side is hardcoded and the autonegotiation is set to off, the autonegotiation process will fail, and the side with autoneg_on will be forced to used half duplex. So if the other side is set directly to full duplex autoneg_off, then you will end up with a duplex mismatch. Here is a table to easier to memorize:
Auto Half Full Auto optimal works mismatch Half works optimal mismatch Full mismatch mismatch optimal
At one of our customer we will have an monstre’ UID-consolidation projekt in the near future. For this purpose I’ve written a script to enlighten our task. Most of you thinks at it a an over-complicated (usermod && find …. chown …) job, but my script has undergone some performance optimisation too: it starts parallel (find….chown) processes to get the job done as fast as it can be. Here is the output for changing the UID of a testuser:
# ./chguid testuser 234
Checking parameters OK
Checking for duplicate UID OK
Changing the UID in the password database OK
The UID was successfully changed:
Before:
testuser:x:123:20:test:/home/testuser:/usr/bin/ksh
After:
testuser:x:234:20:test:/home/testuser:/usr/bin/ksh
Starting parallel processes to change ownership
Threads with chown: (the list may be incomplete on fast systems)
root 4993 4981 7 13:54:04 pts/0 0:00 find / -xdev -user 123 ( -type f -o -type d ) -exec chown 234 +
root 4995 1 7 13:54:04 pts/0 0:00 find /orae6/hes1 -xdev -user 123 ( -type f -o -type d ) -exec chown 234 +
root 4994 1 5 13:54:04 pts/0 0:00 find /orae6/heb1 -xdev -user 123 ( -type f -o -type d ) -exec chown 234 +
FINISHED
#
Here are the steps for offline migrating a Serviceguard cluster to another SAN:
no. of target box
no. of target LUN
size of target LUN
Read More
There is a system where our customer had the following error messages:
…
APTY Trying to allocate /dev/ptyr7
APTY Trying to allocate /dev/ptyr8
APTY Trying to allocate /dev/ptyr9
…
The background is, that it is a custom application, which is used from ServiceGuard on a two-node cluster.
I guess it is around ~15 years old. We must migrate this package because of the leasings end of the server.
After we moved this package onto another two-node cluster, we’ve got the error message.
The HW config is identical, and we needed to set the kernel parameters, especially npty should have been raised to 1200:
# kmtune -q npty
Parameter Current Dyn Planned Module Version
===============================================================================
npty 1200 - 1200
#
But the error remained. We opened a call at the HP Support, and they gave us a tool that displays a summary about BSD-style ptys. This is how it works: Read More
In most datacenters it is very uncommon to use a firewall directly on the server. However, in HP-UX it is on as a default. To check the status of the firewall:
# ipfstat
dropped packets: in 0 out 0
non-data packets: in 0 out 0
no-data packets: in 0 out 0
non-ip packets: in 0 out 0
bad packets: in 0 out 0
copied messages: in 0 out 0
input packets: blocked 0 passed 0 nomatch 0 counted 0 short 0
output packets: blocked 0 passed 0 nomatch 0 counted 0 short 0
input packets logged: blocked 0 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 0 lost 0
packet state(out): kept 0 lost 0
TCP connections: in 0 out 0
ICMP replies: 0 TCP RSTs sent: 0
Invalid source(in): 0
Result cache hits(in): 0 (out): 0
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none
# Read More
We have a machine that crashes after a certain period of time, and continues with a crash dump before a reboot. HP has detected that the FW of the Management Console should be patched, as we don’t have the latest patch installed. The customer didn’t want this, he was afraid of the side-effects to the CRM. But as this problem comes now every one hour, I could convince him that the patch won’t have any side-effects to the system. The HP Support has told him this also, and the patch is just a normal 2-star patch, so it’s unlikely it will have side-effects to a well-known application like Oracle DB. It was very time-consuming always wait for the crashdump after a crash, and as we had already a crashdump to analyse, we don’t need it anymore, the problem is known also to us and to HP support. So if it dumps at boot, you could just press an ESC like me did, and after that answer “Y” to the question:
*** Dumping: 14% complete (276 of 1916 MB) (device vg00/lvdump2)
*** Dumping: 14% complete (284 of 1916 MB) (device vg00/lvdump2)
*** Dumping: 15% complete (292 of 1916 MB) (device vg00/lvdump2)
*** Dumping: 15% complete (300 of1916 MB) (device vg00/lvdump2)
*** Dumping: 16% complete (308 of 1916 MB) (device vg00/lvdump2)
*** Dumping: 16% complete (316 of 1916 MB) (device vg00/lvdump2)
*** Dumping: 16% complete (324 of 1916 MB) (device vg00/lvdump2)
ESC was detected. Press Y within 10 seconds to abort the dump,
or press any other key to continue.
*** Dump aborted by pressing ESC. System rebooting.