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