Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!ukc!edcastle!hwcs!zen!frank
From: frank@zen.co.uk (Frank Wales)
Newsgroups: comp.sys.hp
Subject: HP-UX problems and suggestions (s800)
Keywords: HP-UX s800 3.1
Message-ID: <1717@zen.co.uk>
Date: 27 Sep 89 15:38:53 GMT
Organization: Zengrange Limited, Leeds, England
Lines: 316

This posting is rather lengthy (>300 lines), and contains both
outstanding bugs in, and desirable enhancements to, HP-UX on the 800
series (much of this also applies to the 300 series).  The purpose of
the posting is two-fold; to inform of problems which we have
encountered here (most of these have already been officially
registered with HP as SRs or ERs, but what the hell :-)), and to
solicit comments on the enhancement requests which are included.  It
is not an exhaustive list; just the result of some of the problems
we've run up against recently.

All of the following are encountered on the current HP-UX release
on our model 840 [uname -a => HP-UX zen A.B3.10 D 9000/840 5067].

First, the *bugs*:

1) The information stored in "/etc/disktab" for the 7963
disk drive results in newfs(1M) correctly displaying that
the drive has 304MB of disk space (297108 1K blocks in section 2).
The device driver in the kernel contains the same information in
hp7959_sizes: section 2 has 1188432 256-byte blocks.

Yet once the disk has been formatted and mounted, bdf(1) reports only
278MB available.  This leaves almost 10% of the physical disk space
unavailable, which is unacceptable for a drive of this capacity,
especially as larger drives (e.g., 7937s) have a much lower percentage
unavailable.  Please make the device drivers do what the numbers say
they should, and access the whole disk.  (See UK PICS call reference
E1319345.)  Alternatively, please explain to me where the extra space
went, and offer suggestions on how I could reclaim some of it (I have
tried to make sense of the messages printed up during the formatting
process, but I can't make any combination of the numbers displayed
"fill in" the missing amount).

2) disksecn(1M) fails to recognise the names of any disk
drives, including all the examples in the manual.  I understand this
is a known problem.

3) The file /etc/magic always gets overwritten when an update
is performed; this destroys any customer-added information in the file.
It would be preferable if the original /etc/magic file could be
preserved somewhere to make updating the new one easier, for example
by using a customise script to copy a new one from /etc/newconfig
after the original had been renamed to /etc/magic.old, say.
Another option would be to alter file(1) to read two files,
one reserved for vendor-provided information, and one for customer-
provided information; /etc/sysmagic and /etc/localmagic,
for example.  [I class this as a bug because the behaviour is both
undocumented and unexpected, and costs me time at each system update;
a plain text configuration or data file such as this invites me to
add my own information, and so I expect updates to honour that.]

4) HP-UX is consistently shipped with inappropriate file
permissions (mostly on executables).  Specifically, executables are installed
with read permission enabled.  This violates the principle of minimum
information, and is a potential security problem, since unfriendly
Users can use the strings(1) utility to examine the data spaces
of executables (or indeed the entire files) for clues on how to defeat
protection mechanisms, for example.

*No* executable should be readable (or writable!).

Another example: because of unnecessarily liberal file permissions, it
is not hard to snoop on mail as it is being processed by sendmail(1M).
Denying 'other' read/search permissions on one directory solves the problem.

5) The Korn shell (ksh(1)) does not handle line editing at all
well in emacs mode.  Specifically, if the cursor reaches the
end of the line, the prompt is lost when the line editor scrolls the
display to continue.  Worse, if PS1 is longer than  half
the COLUMNS value (40 on an 80-column terminal when no COLUMNS
value is set), then when the cursor reaches the right end of the line,
scrolling does not take place for the number of characters that the
length of PS1 exceeds half the length of COLUMNS by.  So
if PS1 is 50 characters long on an 80-column terminal, the
scrolling will occur ten characters too late.  In the meantime, garbage
characters are printed at the right end of the display line; pressing
^L doesn't help.  The vanishing-prompt bug is fixed in ksh-88,
but I don't know about the long prompt bug.

6) The program getty(1M) does not accept the character ^H as a synonym for
#, which contradicts the manual entry.  (Until recently, it didn't
accept ^U for @ either).

7) vipw(1M) does not recognise that /bin/ksh is a valid shell for root.  At
the moment, it only accepts /bin/sh and /bin/csh.  Also, vipw(1M) fails to
preserve the mode of /etc/passwd when it restores it from /etc/ptmp.

8) curses(3) does not handle HP terminals at all correctly,
especially when display enhancements are in use.  This has been a
long-standing problem with hp-ux that shows little sign of
getting better.  The screen updating algorithms are tuned to work
for terminals which have character-based rather than screen-based
attributes, and as a result can be made to fail badly on HP
terminals.  They fail even without attributes, though, as the appended
example program shows.  *Please* spend some time getting this repaired.
It is embarrassing to HP to have a product which supports DEC
terminals better than their own.  We can supply many example
programs demonstrating bugs.  Indeed, we already have, but the
responses to date have always been to patch curses to work
in the specific cases we have submitted, rather than to see the
big picture and fix all the problems.  It is frustrating for our
applications developers whenever I update the operating system,
since they get sarcastic about what curses will do *this* time.  :-(

Just for your amusement, here is one simple example:
#include 

/*
 *  To run type   cc -g  -o c_bug -lcurses && c_bug
 *
 *  It fails when using a TERM value of 2392
 *
 *  This program should print a message on the standard screen on line 0.
 *  The message should be erased and a new message written.  Because the
 *  messages are sufficiently similar curses attempts an update and gets
 *  it wrong. 
 *
 *  Spurious characters appear before the "f".  In this example there are
 *  2 but by changing the y of the second addstr there will be no
 *  corruption, or 1, 2 or 3 characters inserted.  The characters depend on
 *  the last character of the first `word' and they have the ascii value of 
 *  1st y - 2nd y + last char (e.g. 14-11+'X'= '[') up to 1st y == 6.  When 
 *  this value decreases the effect disappears.
 *
 *  If the first word is shortened the effect changes then disappears.
 *  Adding any character to the end of the string has no effect.
 */
main()
{
  initscr(); noecho(); cbreak(); nonl();

  mvaddstr(0, 6, "XXXXXX X");
  mvaddstr(LINES-2,10, "Press any key");
  refresh();

  getch(); /* wait for something before carrying on */

  erase();
  mvaddstr(0, 3, "XXXXXX f");
  refresh();

  endwin();
  return 0;
}

9) The manual entries for login(1) and environ(5)
both incorrectly show default PATHs as having a null component.
This could mislead an inexperienced User into thinking that having
a null component in one's PATH is a required thing, or a good
idea.  The manual entries should be amended to reflect the correct behaviour.

10) ksh(1), if interrupted at an inopportune moment,
will trash the stty settings of the controlling terminal.  This manifests
itself as leaving off echo, and having the eof character changed to
^A.  This comes about as a result of forgetting to restore
the termio structure, leaving, for example, c_cc[VEOF] as what was there
when it was regarded as c_cc[VMIN].  It is hard to duplicate
this easily, but it happens to me several times a day.

11) compress(1) fails to preserve the time of last modification of
a file if you don't own it, but have permission to compress (or
uncompress) it anyway%.  This is because it executes chown(2) before
utime(2) when copying the old file's information across; swapping
the order of these calls fixes the problem.  (This is a problem if, like us,
you have lots of source files lying around, and automatic compression
of files not in current use; programs like make(1) lose vital information
when the mtime is changed unexpectedly.)

%) Additionally, compress will let you compress a file you don't have
write permission for, as long as you have write permission in the
directory containing it (and can read the file).  Either have compress
examine the file and reject attempts at compression of non-writable files,
or document this behaviour.

12) vi doesn't re-read line settings when re-starting from stopped.
Try stty erase ^H intr ^?, vi,  (^Z, probably),
stty erase ^? intr ^C, fg, :q, stty -a, and note that erase is ^H and
intr ^?.

13) The manual entry for init(1M) states that "Telinit can only be
run by someone who is super-user or a member of group 'sys'."  I am
a member of group sys (gid 3), and executing telinit always gives me
the message "could not send a signal to init" if I am not also root at
the time.

%%

And now, the suggested enhancements:

1) The Number One Enhancement we want: please, *please* add
shared libraries to HP-UX.  We want to get back to the days when
a program which opens a file, diddles some information and prints a
summary has an executable size less than 30K.  We'd be ever so
grateful.  [I understand this is planned for 7.0.  If you have a list
of things that might not make it, make sure this is *not* on that list.]

2) sam(1M) should be customer-configurable.  At the moment,
adding a new User on this machine involves updating more files that
just those in /etc.  For example, /usr/lib/aliases and
/zen/lib/lasertab (a simple database for routing laser printer
requests).  It also involves creating multiple directories and new
files with particular permissions, such as $HOME/public and
/usr/mail/$LOGINNAME.  It may also involve non-standard User directory
information (some of our User directories are remotely mounted over
NFS).  You get the idea.  I would love to have a utility for
doing what sam does that I can configure to the needs of my system.
At the moment, it isn't sam.

(As a side comment, using JYACC as the menuing front-end leads to some
amusing (and annoying) inconsistencies.  For example, it would be nice
to have the return key behave the same as the JYACC transmit key,
which is intuitive for most Users, but this is not allowed.  It works
better for update(1M), which is *much* better than it used to be.
Thank you for that.)

3) Updating the rcs(1) program (and its cohorts ci(1), co(1), etc.)
to be the current version (4.6, at least) makes several new features available.

4a) Context-dependent files on the 800 series, recognisable over NFS,
would let us have a cleaner networked file system.  So would remote booting
of any 300 or 800 diskless node from any other (diskful) node.  [7.0 ?]

4b) A more recent version of NFS would ensure that we don't have
to hack the kernels of machines to which we want remote root access.
Alternatively, throwing NFS down the toilet and implementing a better
networking protocol would be nice (do I hear Domain/OS? :-)).

5a) Add support for HP9122 floppy disk drives on the 800 series (it sort of
works anyway, but support would be nice).

5b) Then, provide a set of MS-DOS utilities, in the spirit of the
existing LIF utilities.

6) Make id(1) accept options to print out selected information, such
as just the numeric uid or just the named egid.  This will save a lot
of cut(1)ting and sed(1)ing in scripts.  (We have written our own
version of this --- it is *much* more convenient.)

7) Alter finger(1) (chfn(1)) so that it works sensibly *off* the
Berkeley campus.  In other words, make the restrictions on building
and telephone information a lot less specific than they currently are.

8) Enhance the security of the login(1) program by making it always
ask for a dial-up password on a line listed in /etc/dialups *even if*
the (loginname,password) tuple is invalid.  At the moment, getting to
the Dialup-password: prompt tells an aspiring invader that they have
succesfully obtained a valid login name and associated password, yet
the login(1) program (quite correctly) does not reject an invalid
login name without asking for a password.  The current behaviour is
both inconsistent and less secure than the suggested alternative.

9) mv(1) reports rename(2) failure when renaming a directory, and
the target directory name ends in `/'.  This is a harmless name
extension which rename accepts on the source directory name,
and which open(2) also accepts on a directory name.  Make
rename consistent in both opening and creation of directories.
Alternatively, make mv(1) strip the trailing `/' from the
destination argument.  (Unless there's a good reason for this behaviour.)

[Also, why is /usr/lib/mvdir present, since mv(1) uses rename(2)?
 Does something else use it?]

10) HP-UX and its associated products often have unstripped
executables; many programs on the distribution tapes contained
spurious symbolic information which takes up a lot of disk space
(after installation of the optional networking, database and compiler
products at 3.01, there were >2.5MB to be reclaimed by stripping in
/usr/bin alone).

11) man(1) creates cat(1)able manual entries which are
publicly writable; this is an invitation for potential mischief-makers.
Making the whole manual area non-writable (except by the man program,
etc.) would be of value.

12) Extend the -perm primary of find(1) to accept symbolic arguments
as chmod(1) does, and define the semantics such that +permissions
match permissions granted, -permissions match permissions denied, and
=permissions exactly matches the nominated permissions field.  This
would allow, for example, detection of setuid programs with any
combination of other bits, or any writable executables without regard
for their overall permissions, much more easily than a string of
( -perm 211 -o -perm 611 -o -perm 121... ) does.

13) For the sake of tidiness, make all executables and system directories
owned by bin, and in group bin, unless specifically required otherwise.

14) Supply detailed update information, not just a summary.  For
example, some programs which worked under 2.1 broke at 3.01 because of
a change in the semantics of the lockf(2) call.  It took some
work to locate the change.  A detailed list of bugs fixed and enhancements
added would suffice (note: the Software Status Bulletin is not
good enough to serve this purpose).

15) xargs invokes its program argument even if it has no subsequent
arguments on its stdin to pass along.  There is no way of stopping this
behaviour except by specifying an invocation arg list of 1 (using the -l
option), which makes find | xargs almost as inefficient as
find ... -exec {}.  Adding an option to xargs to abandon execution of
its arguments when its stdin is empty would be useful, and wouldn't
break whatever depended on this behaviour in the first place.

16) vi is less literate that it used to be before NLS came along;
if you type   vi Bill Dave  , then type  i  ZZ  , you will
see the message:
    "Bill" 1 characters, 1 lines, 1 more files to edit
which is worse than the standard Domesdos message "1 File(s) copied".
Anyone else annoyed by this?

There, that wasn't so bad.  :-)  It is perhaps a statement on the
overall quality of HP-UX that many of the above will seem like
fiddling details, but that doesn't mean they're not important to
at least one customer.
--
Frank Wales, Systems Manager,        [frank@zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217