This FAQ list is intended to cut down on the number of "often asked questions" that make the rounds on comp.unix.aux and to bring the official FAQ into the 21st century. Also included you'll find a few words of wisdom as well as some general information for the A/UX community. This list assumes that you are familiar with Unix (to some extent) but are curious about A/UX's peculiarities. If you don't understand something in the FAQ List, and a "Point of Contact" isn't specified, then by all means ask comp.unix.aux — the pool of A/UX experts is growing smaller, but this is still one of the best resources available. The list will be posted occasionally on comp.unix.aux, and maybe on news.answers and comp.answers as well.
This FAQ will focus on A/UX 3.1.1, but will also refer to 3.1, 3.0.2 and 3.0.1. Bugs and things "broken" in 3.0.1 but fixed in 3.0.2 (and later) or "broken" in 3.1 but fixed in 3.1.1 won't necessarily be mentioned, since the 3.0.1→3.0.2 and 3.1→3.1.1 fixes (the AWS "Tune-Up" disks, v1.0 and v2.0) are free and readily available.
Newcomers to A/UX (as well as the old-timers!) should become familiar with the sections on security, bugs, and hints before jumping to more specific questions. You can save yourself a few headaches!
Please post your suggestions for additions/modifications to comp.unix.aux for consideration.
The editor would like to thank all the various people who have contributed to the A/UX FAQ List (both those that submitted questions as well as those who submitted answers). Also included under the Q&A section are the relevant people to contact if you have specific questions about specific A/UX items. If you've been left out, please let me know!
The reader is advised that it is unlikely that many of these circa-1998 addresses will still be valid today.
A/UX was Apple's first implementation of Unix (Apple's UniX) for various Macintosh computers in the late 1980s and early 1990s. It was originally ported by Unisoft. A/UX merges two computing environments, Unix and the Macintosh Finder OS, and provides the full functionality of both. The impetus for creating a Unix-based OS at that time was in large part due to the United States federal government standard for computer purchases was that the systems be POSIX compliant.
A/UX is based on AT&T Unix System V.2.2 with numerous extensions from V.3, V.4 (such as streams) and BSD 4.2/4.3 (such as networking, the Fast File System, job control, lpr, NFS with Yellow Pages, SCCS and sendmail 5.64). It also provides full POSIX compliance. A/UX provides SYSV, BSD and POSIX compatiblity switches and libraries. A/UX is fully compliant with the System V Interface Definition (SVID).
A/UX provides all three shells that were standard at the time: sh, csh and ksh. X Windows (X11R4) is also provided standard.
A/UX 3.x.x incorporates System 7 for the Macintosh allowing for the use of the vast majority of Macintosh applications under A/UX. System7 and Unix and fully integrated under A/UX 3.x.x with the Unix file system being seen as a disk drive by the Finder.
There are quite a few people who feel that A/UX is a near-perfect implementation of Unix. Of course, every operating system (even AIX!) has it's share of devotees, so that's not a very valid scale of whether the system is any good. A/UX is Unix…it's not some form of pseudo-Unix. It insulates the user from Unix, if required, but the System Administrator will need to become Unix-aware. Furthermore, if you want straight Unix, you can get it…it's not a chore to bypass all the "gingerbread". People may also complain that A/UX is based on an "obsolete" version of AT&T Unix (V.2.2). In many ways, Apple's extensions make A/UX very V.3-like (V.3 is in many ways an enhanced V.2 — it even uses the V.2 kernel). The list of extensions to A/UX are impressive. Compare what you get standard with other systems and you'll be shocked! On some, 'cc', 'f77', NFS, etc. are costly options.
The main consideration (and opposition) to A/UX in it's day was the platform it runs on: the Macintosh. Some consider this a boon, others a bust. Apple's top-level A/UX workstation is the Quadra 800, a 33MHz 68040 based system. Some considered this obsolete; others considered it overkill; others, like Goldilocks, considered it "just right".
If you needed super-fast state-of-the-art number crunching capability then A/UX may not have been for you…the Q800 benchmarks at maybe 10-16 SPECmarks (depending on compiler used, external cache size, etc.) and you could get lots faster with other platforms. Of course, you'd have to "settle" for their operating systems, but if you needed it, then that's how you'd get it. Of course, this doesn't mean that A/UX "crawls", and hobbiests using it today are still pleasantly surprised with its performance.
There are very few people who needed this type of performance though. If you needed (or just wanted) a Unix workstation with the speed and power of Unix and the user interface and application selection of the Macintosh then A/UX was the way to go. In many, many ways, A/UX was the Unix "for the rest of us"…even if we are long-time Unix junkies. If you love the Mac, you'll love A/UX; if you love Unix, you'll love A/UX…and if you want a near-perfect marriage of the two, then you'll love A/UX.
Yes, A/UX is good…very, very good. ☺
All that said, Apple stopped development on A/UX in the early 1990s and dropped support (in favor of other efforts, such as MkLinux, Copland, then Rhapsody, which became MacOS X) by 1996. The rumored OSF/1-based version 4.0 never materialized. It is an abandoned OS, and since Apple has not released the source (nor can they, since they licensed from SCO), there is no way for it to be kept updated. Hobbiests considering using A/UX should be aware of this. Most remaining A/UX installations in the 21st century are for nostalgia.
As alluded to above, A/UX is used for anything a Unix or Mac workstation was used for in the early 1990s. Many people did application development, ran backup/storage software, and hosted MUDs and web servers. As of late 2006, only two public A/UX servers are known: wiskit.com, run by Herb Weiner, and se30.it, run by Amedeo Mantica. Others are deployed on intranets, but most remaining installations are now assumed to be hobbiest systems.
A/UX 3.0 works on the Mac II (with PMMU or 68030 upgrade with FDHD ROM's installed), IIx, IIcx, IIci, IIfx, SE/30, IIsi (with 68882 chip) and the Quadra 700/900/950 computers. A/UX 3.0.1 (and later) adds support for the Q800 and Centris Machines (the Centrises must have the real 68040 w/FPU - See below). A/UX will run on the Quadra 610 and 650s (recall that A/UX requires the real 68040 chip!) with a little bit of work.
A/UX will not run on the PowerMacs, any AV machines, any PowerBooks (or portables), the LCs, the Duos, the Classic II, the Q605 or on the Quadra 630. It is recommended that you not run A/UX 3.1.1 on the II, IIx, IIcx or SE/30 machines, since their MacOS-compatibility is unreliable under 3.1.1.
Recall that A/UX is Unix and thus contains some very hardware specific drivers. It's for this reason (and not Apple not doing things correctly) that A/UX won't work on newly released platforms. To support a new platform, at least some work (and possibly extensive work in some cases) must be done.
If you really want to cut it close, 8MiB RAM and an entire 80MB hard disk will just make it. You'll have little room for user files (unless you clear out some space by removing /games and maybe /catman) and depending on your workload, may suffer from low performance due to swapping…you may even encounter the infamous swap messages ☺.
A much better system would be 16MiB of RAM and about 200MB of disk space. This would give you much more room to grow as well as sufficient RAM to increase your performance (assuming that you tune some kernel parameters). All in all, more RAM is preferred: 20MiB (or more) is ideal.
Take care that you don't use too large a disk, however. The fsck in A/UX Startup that checks the root filesystem cannot scan a partition larger than 2GB. A/UX's own fsck can check larger partitions just fine.
Short answer: no.
As alluded to above, A/UX talks directly to the hardware. It does not talk to the Macintosh ROM, which is a key component that most Mac emulators use to avoid having to write full emulation of all the hardware components themselves. If someone were to write a 100% cycle-accurate emulator that precisely duplicated the hardware of a supported model, then it would be possible. However, all existing Mac emulators have taken the easy route and used the ROM as an abstraction layer to the real hardware.
If you don't have one of the supported machines, you cannot run A/UX. Which is a trifle sad, as it means A/UX will eventually fade out completely as key hardware components inevitably fail, leaving us without the requisite platform.
A/UX 3.x.x incorporates the full functionality of System7. It supports the QuickTime multimedia extension and the new Mac Quadra computers (not the AV machines, however). A/UX 3.x.x includes X11R4 in its distribution, as well as MacX. Installation of A/UX is much easier that it was before and can be installed on any 3rd party hard disk using the "new and improved" HD Setup application (see Admin Q&A though).
3.0.2 is a later version of A/UX. 3.0.1 added support for the Q800 and the Centris machines (650 and 610) as long as they have the real 68040 chip (68RC040) installed. (Support for the C650 is official; support for the C610, which requires the 040 be replaced since none have the required one installed, is non-official but known and verified). A/UX 3.0.2 will also run on the Quadra 610 and 650; see What's the minimum system I need (above) to see how. To get 3.0.2, you'll need to install 3.0.1 and then apply the AWS Tune-Up 1.0 to upgrade to 3.0.2. This upgrade is free.
3.1.1 is the latest version of A/UX. 3.1.1 greatly improves performance and reliability as well as fixes some bugs. It does not, however, add support for any other Macs. 3.1.1 is "tweaked" for the AWS95, but can be run on other non-AWS95 Macs as well (see below). A/UX 3.1.1 is a "tuned-up" version of A/UX 3.1, which is, itself, a improvement over 3.0.[1|2] (in fact, 3.1 contains all the fixes in 3.0.2). However, A/UX 3.1.1 will not run reliably on the Mac II, Mac IIx, Mac IIcx or SE/30 machines.
3.0.1, in addition to supporting newer Macs, provides performance boosts, bug fixes, better Finder emulation and other enhancements over 3.0. 3.0.2 does the same for 3.0.1. The upgrade from older versions of A/UX to 3.0.2 really is worth the pretty small amount of money required. 3.0.2 is a better and more solid performer, both Unix-wise and Finder-wise, than it's predecessors. 3.1 requires 3.0.[1|2] and provides much better performance and should be seriously considered!
3.0.2 is an exact binary-copy of 3.0.2(wgs) (which is the version of A/UX for the WGS 95 server) except for some minor cosmetics and the exclusion of the server-related applications. This includes RetroSpect for A/UX (see Errors Explained). Some of the major differences between 3.0.2 and 3.0.2(wgs) include:
As you can see, they are all related to how the system is set up.
The latest shipping version of the complete A/UX distribution is 3.0.1. Once you get that, you can either decide to upgrade (for free) to 3.0.2 or upgrade even further by purchasing the A/UX 3.1 upgrade and then using AWS-Tune-Up-2.0 (which is free) to go all the way up to 3.1.1.
A/UX is available preinstalled on Mac systems or on CD-ROM. To find the nearest A/UX reseller, call 1-800-538-9696. You'll need access to a compatible CD-ROM drive to install A/UX (or a friendly dealer if you go that route). Please note that at the present, you can only order 3.0.1; you'll then need to apply the AWS Tune-Up 1.0 (available on jagubox and aux.support.apple.com) to upgrade up to 3.0.2. You could also, as mentioned above, also decide to spend some extra money and get the 3.1 Upgrade CD-ROM, to bring you up to 3.1, and then apply the free Tune-Up-2.0 disk to bring you up to A/UX 3.1.1.
The part numbers (and suggested retail price) for 3.0.1 are (US and Canada):
If you are interested in upgrading your Q950 to the Apple WGS-95 Server (which uses A/UX 3.0.1) here are the part numbers (with SRP):
By the way, MacWarehouse is now selling the A/UX 3.0.1 CD-ROM package for $619... Their phone number is 1-800-255-6227; ask for part#SYS0009.
To get 3.0.2, you need to snag the AWS Tune-Up 1.0 DiskCopy image files from aux.support.apple.com or jagubox and apply the patches. Although the Tune-Up is called AWS, it's really for all A/UX users. Note that you need 3.0.1 to upgrade to 3.0.2.
If you want to upgrade to 3.1.x, please see below.
There's no way Apple is going to sell you a copy of A/UX any more. It's hard to find even on eBay. The editor can neither confirm nor deny the existence of disk images on a German or Belgian site.
You can upgrade to 3.0.2 (from any other version of A/UX) by purchasing the A/UX 3.0.1 CD-ROM Product Upgrade (Apple part # MO599LL/C). The suggested price is $250. You then need to snag the AWS Tune-Up 1.0 disks to upgrade 3.0.1 to 3.0.2.
It's recommended that if you do upgrade, that you completely repartition your disk via the Installer for two reasons:
If you want to upgrade to 3.1.x, please see below.
If you have bought at least one copy of A/UX 3.0.x and you have other Mac CPUs that you would like to install A/UX on, you don't need to reorder the entire product. You can order a Right-To-Copy license for each Mac you want to install A/UX on and then copy your A/UX to that Mac. This is cheaper than buying a whole new CD-ROM package. It's not right to copy unless you have a Right-To-Copy.
If those other Macs are already running A/UX, but an older version, then you need to order a Right-To-Upgrade license for each one you want to upgrade. As above, you then copy your 3.0.x over to that Mac.
Note that in both cases, you must have purchased at least 1 copy of A/UX 3.0.x. The Right-To-* licenses just "authorize" you to then copy that over to other Macs.
The A/UX Essential Manual Set (that comes with A/UX 3.0.x) is not provided with either license. If you need more, you'll need to order them.
The official e-mail address is reports✉aux.support.apple.com. If you subscribe to the A/UX Technical AnswerLine, you can also use that method. The former isn't acknowledged although the latter is.
For completeness, also post the report to comp.unix.aux.
There was also a HyperCard stack called "Apple Bug Reporter" that Apple recommended using.
Don't hold your breath waiting for a fix, though. ☺
The latest shipping version of A/UX is v3.1. 3.1 offers better performance than 3.0.2, fixes for various bugs, better MacOS emulation and some updated programs and applications. 3.1 requires 3.0.[1|2] and costs $199 (+ $5 for shipping, $10 for FedEx). You can order it directly by calling 1-800-769-2775, x7822. Ask for the A/UX 3.1 WGS Upgrade Kit. If that doesn't work, try asking for part # M2885Z/A.
Once you get A/UX 3.1, you should then apply the AWS-Tune-Up-2.0 disk which upgrades 3.1 to 3.1.1. 3.1.1 offers a bit better performance and better MacOS emulation than 3.1 does. It's also very free.
3.1.x has only been fully tested on the AWS95 platform and not on all the other platforms that A/UX runs on; however, nothing was done to it to prevent it from working on other machines. 3.1.x is "only" for the AWS95s in the same way that 3.0.2 was "only" for them. ☺
Anyway, here is a short and non-official list of some 3.1.x features:
A/UX 3.1.1 will not run on the Mac II, Mac IIx, Mac IIcx or SE/30 machines.
Don't ask…really, don't ask!
Okay, if you insist. It ain't happy….
There is none. Apple has dropped A/UX totally. Apple chose to run AIX on its early PowerPC-based servers, which couldn't be confused with A/UX by a dead halibut. Early in the RISC transition planning Apple paid Unisoft to port A/UX to the m88k processor, but the ultimate decision to use PowerPC must have killed that project.
Apple, however, has provided great support in porting Linux to the Nubus-based PowerMacs. This OS, MkLinux, was made available in "golden release" form around September 1996. You can learn more by checking out mklinux.apple.com. Apple ceased its dalliance with Linux not long after this release, and MkLinux should not be seriously considered by anyone wanting a Unix on a PowerMac.
Apple's recent direction has taken it to yet another processor family, the x86. No, A/UX will not be ported to it, either. MacOS X runs quite well on it, though. As a sort of "spiritual descendant" of A/UX, that's probably more than we could hope for anyway.
If you can't or *gasp* won't run A/UX on your 68k Mac, then you now (this wasn't the case in the early 1990s!) have several options.
MachTen from Tenon. MachTen approaches Unix on a Mac from a different viewpoint. Whereas A/UX is the MacOS running on-top of Unix, MachTen is Unix running on top of the MacOS. This means that compatibilty problems aren't an issue, since the MacOS isn't being "emulated" ala A/UX. You also avoid needing to create separate Unix file systems since MachTen uses the MacHFS file system. Also, MacOS programs run at "top speed" although Unix processes are slower than on A/UX. However, since it runs on-top of the MacOS, MachTen is limited to the inherent limitations and constraints of the MacOS. For example, MachTen's "kernel" isn't truly preemptive multitasking, although the Unix processes are multitasked via MachTen. Also, local users can easily bypass MachTen's file-level security. As the MacOS evolves, these "short-comings" will no doubt be removed from the lower layer of the OS. Finally, MachTen runs on the PowerMacs under emulation, with a native version promised.
MachTen is based on the Mach kernel and the BSD-Reno/Net2 version of BSD. It's a very good alternative to A/UX for those machines that can't run A/UX or for those interested in having Unix run on their Macs (say for learning Unix or doing some Unix development) but don't want their Macs to run Unix. ☺
If you are looking to use a GUI with your 68k Unix box, be aware that X11 applications are sloooow.
NouveAUX was an idea proposed on comp.unix.aux in early 2003 to resurrect A/UX, in spirit, if not in fact. This would be done by integrating a MacOS emulator (such as Basilisk II) tightly with an open-source Unix (such as NetBSD). A Mac-like desktop environment would also be created, though for the "full experience" to be realized, applications would need to be rebuilt to (optionally) use a shared menubar. By doing this, "A/UX" could run on newer machines, such as PowerMacs. The idea never got any further than discussion, mostly because of a lack of clear direction and programmers interested in doing the work. There are probably three major concerns in such an effort:
The name is a play on words: NouveAUX being a "new A/UX", "nouveau" being "new" in French.
This question is reasonable, but outside the scope of this FAQ. The answer lies elsewhere.
No system is 100% secure. To this end, it makes sense to make each one as secure as possible, including A/UX.
The default distribution of A/UX has some files with somewhat lax permissions. These should be changed to avoid problems. These files and the recommended modes, owners and groups are as follows:
-rwsr-xr-x 1 root sys /bin/ps
-rwxr-sr-x 1 bin sys /bin/pstat
-rwxr-xr-x 1 bin bin /etc/ncheck
-rwxr-sr-x 1 bin sys /usr/bin/lav
-rwxr-xr-x 1 bin bin /usr/bin/X11/xterm
-rwxr-sr-x 1 bin sys /usr/etc/ncstats
-rwxr-sr-x 1 bin sys /usr/etc/nfsstat
-rwxr-xr-x 1 bin bin /usr/etc/rpcinfo
-rwxr-x--- 1 adm adm /usr/lib/acct/diskusg
drwxr-xr-x 21 root sys /etc
The removal of SUID-to-root from 'diskusg' means that the cron 'adm' accounting package (all the /usr/lib/acct/* stuff) will need to be run by 'root' instead.
To make changing the user, group and permissions of these files a little easier, Jim Jagielski has hacked together an ugly little 'ksh' script that does it for you. The info required is self-contained in the script itself and it's easy to add more entries as required. Look for the script on jagubox under "/pub/aux/Security/better.perms".
Also, to close things a little tighter, remove all permissions for "others" (chmod o-rwx) for all files in /usr/lib/acct and /usr/lib/cron.
Only trusted users should be allowed to use 'lpr'. Remove execute privileges for "others" and then change '/etc/groups' to make only trusted users as members of group 'daemon'. If you want, you can dump 'lpr'/'lpd' and use 'lp'/'lpsched'.
You may want to consider if you really want the 'lp'/'lpr' administration programs (such as 'lpadmin', 'lpmove', etc.) executable by all. If not, then remove that mode from them (chmod o-rwx).
Under 3.x.x, make sure that all files in /dev/scsi are mode 600 with owner 'root' and group 'sys'... Get the new 'devscsi' file (available on jagubox) to replace what's in /etc/install.d/init.d.
A/UX also has the 'expreserve' problem. This program (actually called 'ex3.9preserve' under A/UX) is used by 'vi'/'ex' to "save" canceled or killed edit sessions. 'expreserve' saves a copy of the buffer in the "/usr/preserve" directory. The program is SUID to root since the directory is owned by root, but any other user would do just fine. There's also no real need for it to be SUID either. To preserve the use of 'expreserve' you'll need to create a new user whose sole existance is to own "/usr/preserve" and 'ex3.9preserve'.
Now change the owner and group of /usr/lib/ex3.9preserve and /usr/preserve to the above user. Change the mode of 'ex3.9preserve' to 2111 and 'preserve' to 775:
---x--s--x 1 preserve preserve /usr/lib/ex3.9preserve
drwxrwxr-x 2 preserve preserve 512 Mar 4 15:46 /usr/preserve
...and you're done. Now 'vi'/'expreserve' can write in /usr/preserve but no root security hole exists! If this is too much work, then you can just remove the SUID bit for 'expreserve'; this will close the hole, but killed editting sessions won't be saved (except for root).
Replacing 'sh' with the "fixed" version described below fixes this hole. Still, having 'expreserve' SUID to root goes against the ideal of running programs with the least privileges possible.
The '/lib/librmt.a' library has write permissions for all users. You should remove it (the write permissions, that is, not the file ☺):
-rw-r--r-- 1 root bin 14734 Mar 23 1993 /lib/librmt.a
Why not create a group called 'wheel' and make /bin/su mode 4750 with owner 'root' and group 'wheel'. Then, only make trusted users with the need to use 'su' as members of 'wheel'.
Make sure that 'bin' has a void password and '/bin/false' as it's login shell.
The shadow-passwd suite has been ported to A/UX. Basically, this package moves the encrypted passwds from world-readble /etc/passwd to root-only-readable /etc/shadow, thus greatly increasing security. Some daemons, such as popper and wu-ftpd will need to be recompiled. Use it!
One definite improvement you should make to your A/UX system is to obtain (from jagubox and other A/UX mirror sites) and install the 'uwrap' program. 'uwrap' is a wrapper specfically designed to wrap and protect /etc/init from the SIGURG signal. It can also be used to wrap other programs and processes as well if desired. Programs linked with -lbsd or -lposix or those compiled with 'set42sig()' do not require SIGURG protection (and since /etc/init exec's all other processes, unless processes use SysV signals and reset SIGURG to SIG_DFL, they will also be protected as well).
There is a replacement version of rpc.statd for A/UX 3.1 (3.1.1) available on ftp.support.apple.com, in /pub/apple_sw_updates/US/Unix/A_UX/supported/3.x that addresses and fixes the vulnerability described in CERT Advisory CA-06.09. Get it!
A number of holes are due to some "wrong" things that '/bin/sh' does concerning IFS. To fix this, Apple has released a "corrected" version of 'sh' that resets IFS to it's default value before executing a script. This fixes some holes that exist in SUID programs that call 'system()' or 'popen()' to execute some commands. This replacement version of 'sh' is available both on aux.support.apple.com and jagubox. To install it, follow these directions (assuming you are located in the directory where the new 'sh' is located):
$ cp /bin/sh /bin/Osh
$ cp sh /bin/sh
For this to work, /bin/sh shouldn't be busy, so this should be done either in Single-User mode (as long as root's shell isn't 'sh') or while in A/UX Startup.
Alternatively, make /bin/sh a symlink to /bin/ksh. A/UX's /bin/sh has other limitations regarding shell scripts, hinted at below, that also make this a good idea.
If you are connected to the Internet, it's a Good Idea to either use either tcp_wrappers (on ftp.win.tue.nl and jagubox) or inetd 1.9 (on jagubox), both of which provide host access control (i.e. you can select which hosts can exec which network daemons. While you are at it, the replacement version of 'portmap' (also on jagubox) is very easy to compile and is recommended as well.
By all means, remove the Guest account. Check to make sure that there are no users with null-passwords in /etc/passwd.
The default distribution of A/UX has 'in.fingerd' SUID to root. Even though it doesn't have the famous Internet Worm problem, there's no need for that. Much better to have it run as 'nobody'. You can do this by either changing the owner of 'in.fingerd' to 'nobody' and keeping it's SUID bit or you can remove the SUID capability and tell 'inetd' to run it as 'nobody'. To do the latter, you'll need to use the new, unofficial replacement of 'inetd' for A/UX (see below: Performance related patches, List of ported software and How can I log anonymous ftp entries?). Jim Jagielski has also ported a version of 'in.fingerd' that logs fingers. It's available via anon-ftp on jagubox. Of course, the most secure option is simply to disable 'in.fingerd' totally in '/etc/servers'.
Root should never use the common System Folder... Due to it's very nature it's writable by everyone. Give root a personal System Folder and sleep easier. ☺
A/UX doesn't support the 'sticky-bit' feature for directories. So why not create a directory in your $HOME called '.tmp' with mode 700. Now in /etc/profile add:
if [ -d "$HOME/.tmp" ]; then
EXINIT="set directory=$HOME/.tmp"
export EXINIT
TMPDIR="$HOME/.tmp"
export TMPDIR
fi
and in /etc/cshrc add:
if ( -d "$HOME/.tmp" ) then
setenv EXINIT "set directory=$HOME/.tmp"
setenv TMPDIR "$HOME/.tmp"
endif
Now most Unix programs (like 'vi', 'elm', 'cc', 'gcc', etc.) will use $HOME/tmp as a safer location for temp-files.
By far, this is the most important patch you could apply to A/UX 3.1. It updates it to 3.1.1 and fixes lots of bugs as well as provides better performance. The patch is in the form of 1 DiskCopy image file which can be found on jagubox and on aux.support.apple.com. You download the files and then use DiskCopy to make the Installer disks. This is a free upgrade to 3.1 and requires 3.1. A/UX 3.1.1 will not run reliably on the Mac II, Mac IIx, Mac IIcx or SE/30.
On jagubox, look in ~ftp/pub/aux/Apple.fixes/supported
By far, this is the most important patch you could apply to A/UX 3.0.1. It updates it to 3.0.2 and fixes lots of bugs as well as provides better performance. The patch is in the form of 2 DiskCopy image files which can be found on jagubox and on aux.support.apple.com. You download the files and then use DiskCopy to make the Installer disks. This is a free upgrade to 3.0.1 and requires 3.0.1.
Has an incredibly small listen() queue which is a major pain for loaded WebServers. 'adb' shell script that fixes this is available on ftp1.jaguNET.com in /pub/aux as well as on jagubox. - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov)
Unofficial replacement is available on jagubox in pub/aux/Daemons. This replacement is based on the BSD-reno inetd and allows such nice features as rereading /etc/servers on receiving SIGHUP, specifying options for called daemons, logging when daemons are spawned and which host requested the daemon and providing host access control. - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov) and John Coolidge (coolidge✉apple.com)
Reports incorrect file number when 'mt' is used to skip files (fsf and/or bsf). Doesn't allow for additional storage capability of extended length tapes or hardware compression tape drives. Doesn't work with Exabyte 8200s.
An unofficial replacement version of 'tc' has has been written that fixes these bugs as well as providing additional capability and support for other drives. 3.x.x replacement is available on jagubox in pub/aux/Sys_stuff. - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov)
Incorrectly prints multiple copies of input. For example, "lp file.1 file.2" would print 2 copies of file.1 and just one of file.2. Due to '>>' being used instead of '>' in certain places in at_interface. Unofficial replacement is available on jagubox in pub/aux/Sys_stuff. Entries in ~lp/interface based on at_interface should also be changed/patched. - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov)
Doesn't correctly connect to the LaserWriter Pro 810. Official replacement is available on ftp.support.apple.com in /pub/aws95/atprint.
Doesn't handle some facility (like 'news') logging correctly. Unofficial replacement is available on jagubox in pub/aux/Daemons (contains new /etc/syslogd as well as syslog.h). - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov)
Leaves ports open and hanging occasionally. Can cause kernel crashes. Unofficial replacement is available on jagubox in pub/aux/Sys_stuff. Please note that it appears that this new version has some slight bugs in correctly handling Synchs and options negotiation. Jim notes that he's only seen this using VersaTerm Pro 3.6.2 and connecting to himself via telnet. - Jim Jagielski (jim✉jagubox.gsfc.nasa.gov), John Coolidge (coolidge✉apple.com)
Ignores the Broadcast Address value in /etc/NETADDRS. If your broadcast address needs to be different then the default, you'll need to modify these scripts to add 'broadcast "$broadcast"' to the 'ifconfig' lines that don't refer to loopback. Pretty easy but email Jim Jagielski if you have questions.
If entered through dirent.h and _SYSV_SOURCE is
defined, rewinddir() is incorrectly "defined". It assumes that you are
linking -lposix and will use the "real" rewinddir() function found
there, when, in fact, you should #define rewinddir as done with _BSD_SOURCE.
A hacked version of dir.h is available on jagubox. It only assumes
-lposix will be included (and the real rewinddir() called) if only _POSIX_SOURCE is defined.
Even though fcntl.h is smart enough to know if sys/file.h has
been included, and won't redefine things defined in there, the
reverse isn't true. So if you include sys/file.h first and
fcntl.h
next, no warnings will be given, but if you do the reverse, some
"redefine" warnings will be printed. A hacked version of file.h
(for /usr/include/sys) is available on jagubox. It checks for __fcntl_h
first.
If you are using 'gcc', you'll also need to snag it's fixed header-file
from jagubox, GNUfile.h, and put it at
<gnuinstall>/lib/gcc/aux/?.?.?/include/sys/file.h.
MAXHOSTNAMLEN is defined as a ridiculously low value (32). It should instead be set to what's "normal": 256. Fix is very simple... edit /usr/include/sys/param.h and change the value from 32 to 256. If you are using 'gcc', you'll also need to edit it's include file <gnuinstall>/lib/gcc/aux/?.?.?/include/sys/param.h.
Incorrectly defines size_t as signed int when every other header file defines it as unsigned int. Fix is very simple... edit /usr/include/sys/types.h and change it from signed to unsigned.
Resets the uid of nobody to 60001 (the MAXUID under 3.1 is 65534, but 'chsh' thinks it's 60001). Use 'vipw' to change this value back if needed.
A/UX-mac occasionally disappears under Chooser. Official 3.0.2 patch is now available on aux.support.apple.com in aws95/elap.
Not as robust as the real System 7.0.1 capability, thus preventing you from loading lots of memory hungry Extensions and CDEVs. Unofficial replacement is available on jagubox in pub/aux/Apple.fixes/unsupported/3.0.
H/W ethernet address is burned in bitwise reverse on Q9?0 and Ethernet NB card. Thus, ao, as and etheraddr reports the incorrect address. 3.0 patch is now available on aux.support.apple.com in supported/3.0.
Severe problems as distributed, such as inability to dialout with correctly configured modem, etc. 3.0 patch is now available on aux.support.apple.com in supported/3.0. This "patch" is a newer version of HDB (to 1.16) and adds some Mega-enhancements as well. Thanks to Earl Wallace!!! If you snagged version 1.14 from aux.support.apple.com then be sure to update to version 1.16. Installing BNU 1.6 causes syslogd to break under new compiles. This is due to the fact that dial.o is replaced in libc.a/libc_s.a when BNU is installed. To fix, just get the replacement dial.o on ftp.apple.com in pub/earlw/dial.
Doesn't seem to like filename completion.
Depending on the options used, can gobble memory and not release. Unofficial replacement is available on jagubox in pub/aux/Apple.fixes/unsupported/3.0.
Doesn't report correct load averages. Unofficial replacement is available on jagubox in pub/aux/Apple.fixes/unsupported/3.0.
After some use on all Macs (except IIfx and maybe the Quadras) the kernel will crash. This has been confirmed by Apple but no fix exists yet!!
If BNU 1.6 is installed, syslogd won't work on newly compiled programs due to some munging of libc.a/libc_s.a when BNU 1.6 is installed. See BNU/HDB UUCP above.
Depending on your setup, A/UX allocates either 10% or 50% of memory for disk buffers (that is, the value of 'NBUF' is either 0 or -1... see kconfig(1M)). (The kernel for the AWS95 has, by default, a NBUF value of -1 whereas "everyone else" has NBUF = 0.) If you have a lot of RAM and A/UX is only allocating 10%, you can greatly increase system performance by increasing the allotment. However, you cannot use kconfig to specify "20%" but you must give it an actual number to use. The way to determine the number of buffers being used, run "pstat -m". This will give you the number of buffers that are currently allocated. For example, if the value is 1000, then you know that to increase the number of buffers to 20%, you must use 'kconfig' to set 'NBUF' to 2000. Under 3.0.2 (and later), you can use the Memory cdev (as root) to do this as well. In fact, this is the recommended way.
Please note that if you change the amount of RAM you have, you'll need to change the value of 'NBUF.' Jim suggests that before you add/remove RAM, you use 'kconfig' to reset 'NBUF' to 0, then do the RAM change and see how your system performance is. If needed, you can then use the above to increase (or decrease) the number of disk buffers.
You can run A/UX on the original Mac II, however the PMMU chip must be installed. You can also use one of the many 68030 upgrades for the Mac II, such as the Marathon '030, but the Mac II ROMs won't recognize the PMMU capabilities onboard the CPU. You'll need to get the Mac II FDHD ROM Upgrade Kit. This kit replaces your ROMs with IIx ROMs, thus enabling you (and A/UX) to use the upgrade. The kit also replaces your SWIM chip (floppy controller) enabling you to use FDHD disks (if such a drive is installed) too... thus the name of the kit. This kit can be had for about $120 although some dealers also include a FDHD drive as well, bumping the price up to about $430.
You can configure the built-in serial ports for hardware handshaking (RTS & DTS) or dialup security (DTR & CD) but not both, due to the lack of a sufficient number of modem control lines.
When using ftp, unless you are sure that a file is, in fact, a true Text file, set the ftp mode to Binary. This is especially true when downloading GIFs and "true" Mac files. If it's a BINHEXed file or a uuencoded file, then you can specify Ascii mode (in some cases, it's required). If the file you wish to download has the ".tar" or ".Z" suffix, then you need Binary; if the suffix is ".uu" or ".hqx" then use Ascii. If you are using a MacOS-ftp utility, then using MacBinary may confuse A/UX (well, the Unix side of it). If the file is a tar file (for example), compressed or not, MacBinary attaches some MacOS "information" to the file that tar can't handle. Use 'fcnvt' to change the file to Apple Double to "strip" this extra by separating the forks:
$ fcnvt -v -d input output
To avoid having A/UX attempt the CR→NL change when copying the file over to A/UX, change the Creator to "A/UX" and Type to "BIN " before drag-copying the file.
So, the flow should be as follows:
To download GIF files via anon-ftp, be sure to specify Binary mode. Then use 'setfile' to create the correct Type and Creator fields (for, example, for Giffer use 'setfile -t"GIFf" -c"Bozo"'). You can then keep this file on your A/UX disk or transfer it over to your MacOS disk (See Mac-Emulation Questions).
If you want to rebuild the "/" desktop, be sure to avoid circular symbolic links (links to "." and/or "..") or else you'll be waiting a looooong time. In a similar way, make sure that you don't have NFS volumes mounted because they will add a lot to the time required to rebuild the Desktop...
With the newest version of HDB UUCP (1.16 - see above), use the "-u" option on 'getty' to keep /dev/tty?? settings sane. Also use the "-t" option with a value like 60 or so to make getty hang up a hung login attempt.
If your A/UX setup is a true multi-user system, or, at the least, has Guest as an active account, it is a Very Good Idea to give each user their own personal System Folder (use 'systemfolder'). This is very true for root! As root, you should also avoid using the global System Folder (mac/sys/System Folder) as an alternate Sys. Folder... there's very little need to do so anyway.
Oh yeah... you can't just copy /mac/sys/System Folder to something like $HOME/System Folder... you must use 'systemfolder' and add/change/delete things as required.
It's very easy to replace TextEditor as your Finder-double-click text editor. All you need to do is copy the application to /mac/bin (make sure that it's permissions are 755 bin:bin), edit /etc/profile and /etc/cshrc to change FINDER_EDITOR to point to the application. Now, A/UX text files will show up as that application's filetype. An excellent replacement is BBEdit Lite (v 2.31). It is really recommended!
A/UX's 'login' supports additional dialup security. This is enabled by creating/editing two files: /etc/dialups and /etc/d_passwd. The format of /etc/dialups is a list of ports that you want to have dialup passwds. eg:
/dev/tty0
/dev/tty10
The format of /etc/d_passwd is a list which associates a password with a login program (which is the last field in /etc/passwd). eg:
/bin/sh:&nk7h7ak92j3H:
/bin/ksh:8hw$jK4ft92jx:
/bin/csh::
/usr/lib/uucp/uucico::
In this case, if anyone attempts to login on ports tty0 or tty10 and are using 'ksh' or 'sh', they'll get asked for a secondary (dialup) password. Users using 'csh' or 'uucico' will not. All other logins that use login programs not entered in /etc/d_passwd (like, for example, /usr/local/bin/bash) will not be allowed to login on the "secure" port.
If you want to install a program that uses a "complex" installation procedure (like for Canvas, Word, Stuffit, etc.) then you should not try to do a fresh install under A/UX. Instead, install under the real MacOS, reboot A/UX and then install needed files to your A/UX System Folder. Programs that, when installed, hack around with the System (beyond things like Fonts) itself, most probably won't work under A/UX, since you really can't patch System (unless you are handy with ResEdit and know exactly what resources to add/change... even then, you are taking a chance...)
If you get an error message to the effect that you have a bad SuperBlock when doing a 'fsck' on a disk, try having 'fsck' use another SuperBlock. Block #16 is always an alternate SuperBlock block, so you can try:
$ fsck -b 16 /dev/rdsk/cxxxxxxxx
A/UX has two versions of the setpgrp() call. The first is the standard
SysV version and takes no arguments. The other is the standard BSD version
and takes 2 arguments (setpgrp(pid, gpid)). However, if, when porting
programs, you have added the 'set42sig()' call, or link with -lbsd, then
you must use the second form (actually, the second form is required whenever
COMPAT_BSDTTY and COMPAT_BSDSIGNALS are set); the first form will usually
fail. A non-portable way of handling this is always calling setpgrp() as setpgrp(0, getpid());. Now, no matter what the compatibility flags are, the function will work
('cc' and 'gcc' under A/UX presently ignores the passed arguments when the
no-argument version is called).
It's always a Good Idea to keep "original" stuff separate from locally added or modified stuff. '/usr/local' is a very good place for this. To add manual pages to this location, create a '/usr/local/man' directory. Now make a symbolic link from '/usr/catman/L_man' to '/usr/local/man'. This does two things: (1) Allows 'man' to search down the '/usr/catman' directory to find your local man pages while keeping the actual data under '/usr/local'; (2) The local man-page set will be searched first (due to the name L_man) as would be desired. If you really want, you can also make '/usr/local/catman' a link to '/usr/local/man'.
If you've added a number of additional man pages, you may want to snag the 'man-utils' package on jagubox. It includes a collection of programs and scripts that make viewing, installing and making man pages easier. Also includes a replacement for '/usr/bin/man'.
Some 'configure' scripts may fail due to some line-length and symbol-length
limitations in /bin/sh (you'll see something like a "symbol too long"
error). You can get around this by changing the script type from #!/bin/sh to #!/bin/ksh to run them as 'ksh' scripts... In fact, some people think it's better
to run all 'sh' scripts as 'ksh' scripts if possible. ☺
Alternatively, just back up the original /bin/sh and make /bin/sh a symbolic link to /bin/ksh, since the latter is compatible with the former. All your 'sh' scripts will then run under 'ksh' automatically.
Maybe you think Courier and Monaco really don't look that nice for CommandShell windows. Monaco is too plain and Courier takes up too much room on the window (and with both, it's hard to see "."s, hard to tell the difference between "O" and "0", etc.). Jim used a font called CSFont on jagubox. It's a tweaked version of the old, original Courier bitmaps that Apple used to provide. It's available via anon-ftp here on jagubox in /pub/aux/Misc_stuff. He was working on tweaking a bold version of CSFont, but apparently it never was completed.
Some users have reported unusual rendering problems with certain TrueType fonts, specifically Hoefler Text and Times New Roman. Curious if anyone can confirm?
If you are doing any in-depth porting, then do yourself a favor and snag a copy of libUTIL.a from jagubox. libUTIL.a is a collection of many functions that aren't included in the standard A/UX libraries, but are needed (or very useful) when porting (esp. BSD sources or ANSI stuff). Some examples of included functions are memmove(), strerror(), strdup() and more. If you have a suggested function to include, let Jim Jagielski (jim✉jagubox.gsfc.nasa.gov) know.
In order to get the WWW-browser Netscape to work correctly under A/UX, you need to make sure a few things are right. First of all, make sure that your Preferences are setup correctly: your Temp and Cache directory should be set and must be located on a MacOS disk, not under the A/UX file system; your Helper applications must be selected as well. Failure to do this can cause Netscape not to view graphics correctly.
You should also move the 'Netscape ƒ' folder from the Preferences folder in System Folder to the actual Netscape folder... Having it located in Preferences will prevent Netscape from remembering certain settings, such as Bookmarks.
Many of these sites are defunct as of 2005, but they remain in this list so that the significance will be realized in the event that a mirror is discovered.
You'll notice "jagubox" mentioned a lot in this FAQ. It was a ftp/gopher/web server run by a previous FAQ maintainer and prominent A/UX community member named Jim Jagielski. It's address is listed below. Jim left NASA and the jagubox archive is no longer accessible there. Some mirrors do exist, and they are also listed below.
The diffs that Brent used, done by Paul Traina, are available on jagubox in the emacs diffs "collection" tarchive.
See Porting and Programming Q&A below.
Anybody know where a copy might be?
Don't replace the header files and don't let 'make' install the files... instead, install them by hand. Specifically, copy the 'named' and 'named-xfer' files from './named' to the correct location (usually /etc) on your system. There is no need to install or use any of the header (*.h) or library (*.a) files in the distribution!! Just replace the binaries, not the include-files! (PS: There is also no need to recompile your programs either.)
See Communication in the Q&A
Later versions compile easily out of the box.
See Communication in the Q&A
The following have also been successfully ported to A/UX with minimal trouble. Since the ports are pretty straightforward, only a few are actually available in their ported form (please see Porting and Programming Q&A below). Please note that most of these require or assume using 'gcc'.
As a general rule of thumb, most of the ports that Jim J. has done use gcc and GNUmake... provided patches may assume or require these.
You should make a copy of the A/UX Install Boot floppy and then copy the Enabler for the Q610/650 onto this copy. You then boot up from this floppy and install A/UX as usual. Finally, you'll need to copy the Q610/650 Enabler onto the A/UX MacPartition (or whatever MacOS disk you will use when starting up your Mac and booting A/UX); do this by first booting off a boot floppy or boot CD and then copy the Enabler over. You do not need to make any changes to the A/UX System Folder (i.e. the System Folder used under A/UX).
Well, the Installer will work with any 3rd party disk but there are a few wrinkles... The HD Setup application in the 3.x.x Installer is unique in that not only does it create A/UX partitions but it also creates the actual file systems in those partitions (basically it runs 'newfs'). Now if you have used some other HD utility program (such as SilverLining or FWB HDT) to create the partitions and then attempt to install A/UX on that disk, the Installer sees that the partitions are there and then assumes that they were created by HD Setup and therefore have the file systems already created. Of course, the file systems don't exist yet, just the partitions, so the installation fails. You have a few options:
Please note that HD SC Setup will only create the file systems if run under A/UX. If you run it under the MacOS, it can only partition...
You can try using a slower CD drive. If you are not using original media (i.e. a backup burned to CD) make sure it is CD-R, not CD-RW.
Because that's the way Apple wanted it. ☺ Actually, the reason why is because the 'scrn' resource is missing from 'System' in /mac/sys/Login System Folder. If you're handy, you can copy 'scrn' from some other System and paste it in Login's using ResEdit. Make sure the "Is Color" field in 'scrn' is "1".
This is also due to the fact (see above) that the System file in /mac/sys/Login System Folder lacks a 'scrn' resource. If you copy this resource from a System that knows about your monitor setup into Login's System, then the screensaver will knows about all your monitors.
Unix is justifiably concerned about having adequate swap space. A system crash caused by this beast is a sight to behold. However, A/UX seems extremely nervous about the amount needed before it starts getting fidgety. If you do a "/etc/swap -l" and see that you're only using a small portion of your swap space and have a "lot" left, then you can safely ignore the messages. (Just how much is a "lot" is hard to say, but if you have 25000 blocks and are only using 1000 or 2000, then you are probably fine.) If you do need more swap space, then you have a few options:
You have three options: dd, dump.bsd and cpio. pax may work but tar won't since it won't handle special-type files. If the two partitions are the same size, you can use 'dd' (to copy c0d0s0 to c5d0s3, e.g.): dd < /dev/rdsk/c0d0s0 > /dev/rdsk/c5d0s3
To use dump.bsd, you can use the following command (this assumes that the destination disk in mounted on /mnt and you want to copy the root file system which is on SCSI 0... of course, you must be root and it would be much better to do this in single-user mode): dump.bsd 0f - /dev/rdsk/c0d0s0 | (cd /mnt; restore xf -)
To use cpio, you must use it in a pipe with find. For example, to copy /usr (let's assume it's on it's own file system) to another disk/partition (assume it's mounted on /mnt) then you can use (you can add the "-depth" flag to 'find' if you want): cd /usr ; find . -print | cpio -pdmuva /mnt
The problem with this is that if the mount point of the destination disk falls under the file system's directory you're trying to copy, you'll load up your destination disk. For example, the following would not work: cd / ; find . -print | grep -v '^./mnt*' | cpio -pdmuva /mnt
If you have GNU find, then you can use it with it's '-xdev' option, which prevents find from walking through other file systems: cd / ; find . -xdev -print | cpio -pdmuva /mnt
dump.bsd creates a "truer" copy of your file system (the access and modification dates aren't mucked with... with the find/cpio pipe, at the least the directory dates are touched) but pre-3.1 versions of restore couldn't restore named pipes. These are easy to create though using 'mknod'. The only named pipes included in the default A/UX distribution are:
/usr/lib/cron/FIFO
prw------- 1 root sys 0 Oct 18 16:08
/usr/spool/lpd/AppleTalk/pipe
prw-rw---- 1 daemon daemon 0 Oct 19 06:11
UUCP under 3.x.x is very improved over it's previous incarnation under 2.0.1. 3.x.x uses HDB (for HoneyDanBer) UUCP instead of standard UUCP. Some nice things are bidirectional getty (also known as uugetty in other Unixen) which allows both incoming and outgoing communication over serial lines as well as better performance and reliability. It is reportedly much easier to set up as well.
You may seriously consider getting Alexis Rosen's "sendmail.cf" file for use under UUCP sendmail. This config file has been modified to allow UUCP and sendmail to work beautifully together. You may also want to consider simply installing smail to replace sendmail.
Under 3.0., be sure that you are running the latest version: 1.16. It can be found on aux.support.apple.com in aux.patches/supported/3.0. Be sure that you get the new dial.o on ftp.apple.com (pub/earlw/dial) to avoid breaking syslog. Under 3.0.1 (and later) all is OK.
Jim Jagielski (jim✉jagubox.gsfc.nasa.gov) has hacked in.ftpd to enable logging via the syslogd daemon. It also pays extra close attention to anonymous ftp logins. It's available (as well as other ports/hacks) on jagubox. Also available on jagubox is a port of the latest version of wuarchive's ftpd server for A/UX. wu-ftpd is a super-nice ftp server with lots of extras and neat features!
The real reason why '-l' doesn't work with in.ftpd is that there's no real way to send this option to the daemon. A/UX 'inetd' doesn't allow you to add options to '/etc/servers'. John Coolidge (coolidge✉apple.com) has ported the BSD-reno version of 'inetd' to overcome this limitation. Jim Jagielski has since been updating and maintaining 'inetd'. This version of 'inetd' also has some nice features, such as rereading /etc/servers when sent SIGHUP. It's available on jagubox. This version of 'inetd' has also been modified to log whenever it spawns a background daemon as well as logging which host requested the daemon.
For more info, contact Jim.
One of the details about the BSD Fast File System is that it sets aside some amount of the available disk space (if the file system was created by HD SC Setup, then 5% is set aside; if created by 'newfs' then 10% is set aside... this value can be changed by using the 'tunefs' command) and makes it unavailable to regular users. This prevents 2 things: filling up a file system and destroying performance by having a "too full" file system. 'root', however, does have access to this "extra" disk space, hence the difference in the numbers reported by df between 'root' and "regular joe".
As mentioned above, if you used HD Setup to create the partitions (or your A/UX came preinstalled), then the "set aside" value for these file systems is 5%, not the "default" of 10%... This was simply to give users more space. Reducing this value beyond 5% is Not A Good Idea.
Nope... not at all. You cannot send IP packets down the LocalTalk (printer) port. IP communication must be through the ethernet port.
MPW 3.1 doesn't work under A/UX although 3.2 does. In the meantime, you can make 3.1 work by breaking into MacsBug when it's hung and entering: pc=pc+2;g
See Mac-Emulation Questions for info about entering MacsBug...
A/UX's 'Finder' mode was the only way (for a long time) to access both file systems. You could write a hybrid application that could attach to the Finder world (a la, CommandShell and cmdo which can "see" both file systems), but you can't access HFS volumes from the A/UX kernel directly. In a similar vein, you can't 'mount' an HFS volume on an A/UX inode with the standard tools.
More recently, a wonderful suite of tools (originally written for Linux) called 'hfsutils' has been ported to A/UX. At its core it is a C library that provides HFS access routines. It also includes command line and X11 interfaces. In A/UX, the entire disk is referred to as slice 31. So first hmount /dev/dsk/c0d0s31 1 and then hls to see the Mac-side files. Other programs in the 'hfsutils' package allow you to manipulate those files. While not quite as nice as providing HFS support natively so that standard utilities would understand those disks, 'hfsutils' does provide a workable solution.
There are three ways to do this. The first is very easy: you simply use the Memory cdev to adjust the "memory" size, logout and then log back in. You must be 'root' to do it this way.
The second way is to use the 'TBMEMORY' environment variable. You can set it's
"value" equal to the amount of memory you wish to use. For example, TBMEMORY=10m; export TBMEMORY (in .profile for ksh or sh or /etc/profile) or setenv TBMEMORY 10m (in .login for csh) configures Finder for 10M.
You can also edit /mac/bin/mac[32|24] (or .mac32|.mac24 if you are using
this method) to call 'startmac' with the memory size you want using the
"-m" option. For example, /mac/bin/startmac -m 8m > $SMLOGFILE 2>&1 & in (.)mac[32|24] will configure an 8M environment.
Please note that under the 24-bit mode (mac24), you can only access a maximum of 8MiB of RAM. It won't complain if you try to setup more, it just won't do it. Furthermore, if you actually have more than 8MiB (say 12), the "About This Macintosh" window will show "Built-in Memory: 12,288 K; Total Memory: 8,192K".
The default behavior of 3.0 (and earlier) was to allocate all the RAM to the MacOS. Thus, if you had 20MiB, A/UX would, unless told otherwise, allocate 20MiB for the MacOS-emulation. Under 3.0.1 (and later), this is slightly changed: A/UX will usually not allocate all RAM to the MacOS but will instead impose a 16MiB maximum (this can be changed via Memory or TBMEMORY). Whatever version of A/UX you are running, it's a Good Idea not to allocate all RAM for the Finder. This is because A/UX allocates itself a chunk, so if you give the Finder "all" of it, you can cause swapping and paging which can seriously degrade performance at times.
If the value set in 'Memory' and TBMEMORY disagree, the value determined by TBMEMORY is used.
There used to be one at www.support.apple.com/pub/usenet/comp.unix.aux/. These days, just use Google.
Apple's X (R4) supports color. However, you must start the server with the
"-screen 0 -depth 8" option (similar command with other screens if you have
them). You can add these options to the command line or to your server's
defaults file. You can also create a ".X11" file in your home directory which
includes the line X -screen 0 -depth 8 to get the same effect. Make sure that ".X11" is executable for this to work
(chmod 755 .X11).
The problem is that sh and csh don't understand the Mac "special" characters that are in the filenames. They don't expect filenames with characters that are represented by 8-bits. ksh is "8-bit clean" and thus would be able to access the file. For example, to remove Moire, just type:
$ ksh #this creates a Korn shell child
% rm M?ire #match the weird 'o' (ö)
% exit #get back in your old shell
You could also use emacs' DIRED or the Gnu File utilities to do this, but ksh is right here on the system so it's a bit easier. Of course, another very easy way is to use the MacOS interface and do the deletion/rename/whatever the "Mac" way. Please note that if what you are MacOS-deleting is a symbolic link to a directory, what gets Trashed is actually the contents of the directory as well as the link! This is due to the fact that to the Finder, the link looks like a folder, and the entire thing gets deleted.
Very early reports indicated that RetroSpect for A/UX might be bundled with A/UX 3.0.2 as it is with the AWS95 version of 3.0.2. This is no longer the case (if it ever was). However, if you are a registered owner of RetroSpect 2.0, you can order an upgrade to RetroSpect A/UX. The cost is around $200 and to order (or more info) you can call 1-800-225-4880 (have your registration number handy). International customers should call 510-849-0293.
Please note that if you have the Pisces card installed (with the WGS95), then only RetroSpect A/UX will work and only under the A/UX environment. You will not be able to access your DAT under the real MacOS!
Finally, reports indicate that RetroSpect 3.0 fully supports A/UX all by itself. If true, this is Good News!
For the answer, snag a copy of CAP.txt which is available on jagubox (in /pub/aux/Info for anon-ftp).
Except for Apple's complete manual set, there are no books specifically about A/UX. (Well, there's one but it's most probably out of print. It is most definitely out of date. It's called "The A/UX Handbook" by Jan Harrington and it's written for A/UX 2.0).
There are some very good books about Unix in general however. The best of the pack (IHMO) is "UNIX Administration Guide for System V" by Thomas and Farrow. Another good book is the "UNIX System Administration Handbook" by Nemeth, Snyder and Seebass. Since A/UX is a mix of SystemV and BSD both books are worthwhile ("UNIX Sys. Ad. Handbook" deals "mostly" with BSD systems). Another must-have is "UNIX Power Tools" from O'Reilly and Associates.
For general information about shells and programming there's no better book than "The UNIX Programming Environment" by Kernighan and Pike. For the 'ksh' shell, a very good book is "Learning the Korn Shell" by Bill Rosenblatt.
O'Reilly and Associates has a wide selection of Unix-based books. You're bound to find what you're looking for from them. You can contact them either via Email (nuts✉ora.com) or Phone (1-800-998-9938).
There is also a list (with over 160 entries) of Unix books (and mini-reviews) located on ftp.rahul.net in 'pub/mitch/YABL/yabl'.
This is due to the fact that some file system damage exists on the Root file system. By default, A/UX Startup will only run 'fsck' on the root file system if the system is marked as "dirty." So even if damage exists, as long as the disk was cleanly 'umount'ed, 'fsck' won't check it out and fix it.
Jim recommends always having A/UX Startup fully check out the disk before booting A/UX. It takes a while, but it's worth it. To do this, choose Booting from the Preferences menu. Now change the command under "AutoRecovery" to "fsck /dev/default" (it was "fsck -y -p /dev/default"). When you do this, you'll notice that the radio button changes from "Check root file system" to "Custom command"... that's OK. After that, A/UX will always run 'fsck' on Root. If you are doing this, you might as well have A/UX run a full 'fsck' on all file-systems too. Check out fsck(1m) and fstab(4) for how to do this... one way is to just edit /etc/bcheckrc and remove the options to the "/etc/fsck" command.
If you don't want to do this but you do have some damage that prevents A/UX from booting, then you can cancel the boot-up process by selecting either "Exit" or hitting "Cmd-." (⌘-.). Then type fsck /dev/default and then, when 'fsck' is done, type boot (or launch). Sometimes you must run 'fsck' several times to fully fix the file system if there was extensive damage.
Yes it is... A complete 'traceroute' package for A/UX 3.1(.1) can be found on jagubox. It includes the updated 'bnet' driver (required for 'traceroute' support) as well as 2 versions of traceroute, pre-compiled and with complete source.
KEEPALIVE is a method implemented in Berkeley sockets and TCP/IP (and in A/UX) that periodically polls a connected socket to determine if it's still "alive" or whether the client on the other end has dropped off. If the connected client doesn't respond, A/UX will consider the connection broken and send SIGPIPE to all connected processes. For this feature to be actually used, programs must set the SO_KEEPALIVE option on the socket.
One particular of A/UX is that although it supports KEEPALIVE, it doesn't send the first probe for 2 hours! It's been suggested that it would be much better to shorten this value to something more realistic to take better advantage of this capability. However, to do this, you'll need to use 'adb' and adjust the kernel.
You can either patch the kernel itself (which requires that the patch be reapplied everytime the kernel is rebuilt) or patch /etc/install.d/boot.d/bnet to keep the patches. To patch the kernel to adjust to time to first probe, you need to use 'adb' to adjust the 'tcp_keepidle' parameter. To get the right value, multiply the number of minutes you want A/UX to wait until the first probe by 120, then change that value to hex. For example, to make A/UX sent the first probe every 5 minutes (5 × 120 = 600 = 0x258) do:
adb -w -k /unix << Foo
tcp_keepidle?D
tcp_keepidle?W 258
tcp_keepidle?D
$q
Foo
To patch the 'bnet' driver instead, do:
adb -w /etc/boot.d/bnet << Foo
tcp_keepidle?D
tcp_keepidle?W 258
tcp_keepidle?D
$q
Foo
Now run newconfig -v and reboot.
In general, most system panics are due to A/UX exhausting some kernel resource; to prevent these, you need to know which resource was used up and then use 'kconfig' to increase them:
| console panic message | kernel parameter to increase |
|---|---|
| panic: kmem_alloc | MAXCORE |
| panic: getfreehdr | MAXHEADER |
| timeout table overflow | NCALL |
| file: table is full | NFILE (NINODE as well, to same value) |
| inode: table is full | NINODE (NFILE as well, to same value) |
| m_expand returning 0 | NMBUFS |
| panic: out of mbufs | NMBUFS |
| proc: table is full | NPROC (NREGION as well, 3x NPROC) |
| Region table overflow | NREGION (NPROC as well, NREGION/3) |
| sptreserve: no kernel virtual space | NSPTMAP |
| allocbuf | SBUFSIZE (and NBUF as well) |
| cannot allocate buffer cache | NCLIST (and add RAM) |
| cannot allocate buffer headers | NBUF (and add RAM) |
| getfreehdr | NPBUF |
You may also run up against the processes-per-user limit as well. This can be increased by bumping up the MAXUP. Of course, you'll also need to increase NPROC, NREGION, NFILE and NINODE (and maybe others) as well to account for the increased number of processes...
A/UX 3.0 performs a sync every minute. It's done by 'init' and the frequency can't be changed.
A/UX 3.0.[1|2] does one every 30 seconds; cached blocks older than 30 seconds are flushed, therefore a block can be resident for between 30 and 59 seconds. If you want, you can use 'adb' to change the value of 'syncdsleep' to the number of seconds to sleep between flushes. Blocks older than that will be flushed.
A/UX 3.1.x peforms a sync every second and flushes blocks that are older than 30 seconds (i.e. a block can be resident for 1 to 31 seconds). You can alter this by using 'adb' to change 'syndperiod' to the timeout age (how old the block can be before it's flushed) and 'syncdsample' to the wakeup period; by default, 'syncdperiod' is 30 and 'syncdsample' is 1.
From A/UX 3.0.1 onward, the kernel process 'syncd' can be seen via 'ps'.
Under A/UX, 'catsearchd' is a Unix process that maintains a cache of MacOS File System information. Having this cache available greatly increases the performance of catalog searches made from the MacOS and an AppleShare client.
For each file cached, 'catsearchd' requires 200 bytes of memory, so if your File Systems are large, 'catsearchd' can be a real memory hog. One way to avoid this is to use the 'nocats' option in 'fstab' for mounted file systems.
Unless you are running A/UX as an AppleShare server, there's no need to run 'catsearchd'; in fact, it's better not to run it due due to it's memory and performance hits. To disable 'catsearchd' you need to edit your /etc/inittab file. Look for the line that looks like this:
csd:2:respawn:/etc/catsearchd # start catsearch daemon
And change it to look like this:
csd:2:off:/etc/catsearchd # start catsearch daemon
Then simply restart A/UX. 'catsearchd' will no longer be running and you'll have some free memory for other more important things.
Sure is... All you need to do is set the 'TBFILEFORMAT' environment variable to '1'. You can do this either in /etc/profile or /etc/cshrc to make it system-wide or have each user add it to their .profile or .login file.
For sh/ksh, the command is export TBFILEFORMAT=1 and for csh it's setenv TBFILEFORMAT 1. You can also edit /mac/bin/mac32 as well if you want.
Sure is. Check out the 'man-utils.tar.gz' file on jagubox (in Sys_stuff).
It does now... Jim Jagielski (jim✉jaguNET.com) has created the 'vif' kernel module that provides for true Virtual Interface support under A/UX. This allows you to, for example, make use of the Virtual Host/Multihoming capability of Apache.
'vif' can be found on jagubox in /pub/aux/Sys_stuff. 'apache' can be found on ftp.apache.org.
A/UX puts commands in some directories not common with other Unix systems, and the default command path in the shell is a bit lacking. Add the following code to your /etc/profile and you should be able to use most commands without having to type the full path to it.
LOCALWARE=/usr/local/bin
LOCALWARESU=/usr/local/sbin
GNUWARE=/usr/local/gnu/bin
MOREGNUWARE=/usr/local/gnu
if [ ${LOGNAME} = root ] ; then
PATH=${PATH}:${LOCALWARESU}
fi
PATH=${PATH}:/opt/bin:${LOCALWARE}:${MOREGNUWARE}:${GNUWARE}:/etc:/usr/etc
export PATH
It would be much easier to list the applications that aren't compatible. The list is much, much shorter...
The vast majority of applications that run under System 7 will run under A/UX 3.x.x. In fact, before System 7 was released, A/UX 2.0.x was actually a good litmus test whether the application was 32-bit clean and would run under System 7. The only applications that are sure to fail are those that try to access hardware directly, such as HD utilities or backup applications. A/UX 3.x.x provides both 24 and 32-bit modes, so if the application doesn't run under 32-bit mode, try it under 24-bit.
One key note: if the program uses a "complex" installation procedure (like for Canvas, Word, Stuffit, etc.) then you should not try to do a fresh install under A/UX. See the above Hints and Words Of Wisdom.
AfterDark (2.0u and later) works well under A/UX but some displays may not have enough memory under Login so the "low-memory" display will be used.
Moire and FMbackup seem a bit incompatible. They both function fine together but the combination prevents FMbackup's "Finishing up..." window from displaying, although FMbackup does, in fact, finish up. Furthermore, Moire seems to screw-up Commando (both version 3.22 and 4.01 exhibit this problem) so all in all, Moire can't be recommended if you desire using Commando (the problem seems to be with all MacOS applications 'launch'ed from the CommandShell window). Using Moire for the Login screen works well however, since you can't access Commando or 'launch' applications from there.
Darkside is also available. Unlike other screen savers, Darkside is an application, not an INIT. This means it won't work under the Login screen. The latest version of Darkside is 4.0 and will not work on Pre-System7 systems, so don't attempt to use this under A/UX 2.0.1 or later.
Moire is available on jagubox.
Whether or not a Mac partition mounts under A/UX depends on a number of factors... Necessary conditions for a partition to mount are:
Sometimes, the partition map isn't correct for the MacOS partition; In particular, the Logical size may be 0! You can use 'dp' to look at the partition map to see if this is the case. Assuming that the disk us SCSI #2, then:
$ dp /dev/dsk/c2d0s31
P
Will print out the partition map entries. You can then see if the "Apple_HFS" partition type has the correct logical size.
See next.
The "Cmd-Ctrl-e" (⌘-^-e) keypress will kill the current MultiFinder environment and "unfreeze" (and kill) your MultiFinder/CommandShell. Depending on whether your session-type is Console Mode or 32/24-bit, you will either get returned to the console or get returned to the Login screen. You should not press the Interrupt switch since this puts you into A/UX's kernel debugger. If you have MacsBug installed (which is recommended) then you can press "Cmd-Ctrl-i" (⌘-^-i) to enter it. This may enable you to clean some things up before the MultiFinder environment is blasted (even just using 'rs' under MacsBug helps...). If MacsBug is not installed, the "⌘-^-i" behaves almost like a "⌘-^-e" except that it appears that A/UX doesn't need to "rebuild" your icon/Desktop "environment" the next time Mac-mode is entered.
To make sure that MacsBug installs correctly, it's name must be 'MacsBug'. A munged Debugger Prefs file can also prevent MacsBug from installing. This happened to me when upgrading to 3.0.1... To be safe, make a solid safe copy before upgrading.
A/UX only supports EtherTalk Phase 2. Upgrading to Phase 2 is recommended for a variety of reasons, but most importantly to ensure compatibility with new products from Apple and developers. Of course, the added features over Phase 1 are nice too. ☺
If a file on the A/UX system has Type "TEXT", then when it is copied over to a MacOS disk, all 'newline' characters will be replaced by 'carriage returns'. Sometimes this is what you want (that is when the file is, in fact, a TEXT file). Othertimes it's not. Say for example you download a GIF file onto your A/UX disk. A/UX might think it's a TEXT file. If you then copy it over to your MacOS disk and try to use Giffer on it, it won't work. That's because the newlines were changed, which is not what you want. The way to stop this is to convince A/UX that the file is of non-TEXT type. There are many applications out there (including the A/UX included 'setfile' program) that lets you modify this. Do this before you copy the file over to your Mac OS disk and all will be Okay. If you aren't sure what the Type and Creator should be, you can just specify "BIN " and "A/UX" (note space in BIN) and the file won't be massaged during the copy/transfer. You'll still need to eventually change them to the correct ones for their particular application, but this way they'll be on your MacOS disk "uncorrupted."
Of course, you could also use 'setfile' to set the Type/Creator fields before you copy the file to the MacOS disk and avoid an additional step.
Please note that if you downloaded a BINHEX file, you do want to keep it as a TEXT file if you transfer it over to the MacOS. Once there, you can de-BINHEX it and unStuffIt (if it was a binhexed stuffit archive).
Please note that if you transfer Unix-type files (like tar archives or compressed files) between the A/UX file system and a MacOS disk (esp. if these files were "created" on a MacOS disk by a MacOS utility), the Unix application may no longer work correctly with it. This is because the MacOS resource information was attached to the file during the transfer (the file is in Apple Single format). To "fix" this, use 'fcnvt' to change the file to Apple Double format which will detach the resource fork and place it into a "%..." file.
See Hints and Words Of Wisdom (above) for hints in using ftp file transfers under A/UX.
To install these additions to A/UX, you will need to drag-copy them over to the A/UX System Folder. Usually, this is /mac/sys/System Folder on the "/" disk but it will also "appear" in your "home folder" icon. If you have a personal System Folder (i.e. $HOME/System Folder) then they should be dragged there. To add a screensaver to the Login screen, it must be dragged into the correct subfolder in /mac/sys/Login System Folder. That is, if it's an cdev, drag it into /mac/sys/Login System Folder/Control Panels.
A lot of people believe this but this is not true. There is no difference between the s/w on the MacPartition partition and the "real" System 7. The only real need for MacPartition is that the disk where A/UX Startup lives is where A/UX Startup looks for the A/UX Root partition. When A/UX Startup launches, it looks at "it's" disk and then looks for A/UX partitions on that disk. This means that you don't need to boot-up from the MacPartition disk to boot A/UX. Start your Mac from your standard Startup disk and just double-click on A/UX Startup on the MacPartition icon.
You can even do without the MacPartition disk but telling A/UX Startup the exact SCSI number of the A/UX disk. You can do this a couple of ways:
The "device" file /dev/default points to the SCSI-ID of whatever disk is the
MacPartition disk, so if you don't have one, you need to tell A/UX Startup
it's "real" name. This is kinda messy since you'll need to preface a lot of
stuff with this value, e.g. #startup cat (6,0,0)/etc/inittab
Ron Flax of Apple (ron✉afsg.apple.com) has written a very useful System Extension called FMbackup that creates backup copies of "valuable" Desktop files. When the MacOS-mode is entered, FMbackup restores these files. Thus, when your MacOS "crashes", you no longer need to rebuild the Desktop or reset all your Icons, window "types", etc. Please note that there seems to be some incompatibilty between FMbackup and Moire and QuickMail 2.5.1.
FMbackup (1.0.4) is available via anon-ftp on afsg.apple.com as well as aux.support.apple.com (in "unsupported").
For more information about "FMbackup", please contact Ron via e-mail.
Under the Preferences/General Menu of A/UX Startup, there is a radio-box called "Password checking". This is intended to provide some security for the A/UX Startup application. When enabled, two (default) things happen:
Thus, to enable MacOS partition(s) to be available for all users, you must disable "Password checking". See auxstartuprc(4) for more info.
This is caused almost 99% of the time by an Extension/CDEV conflict. The way around this is to selectively disable each one at a time and see which one causes the problem... then delete it. "Wild Magic" is prone to do this as are older versions of CEToolbox.
A/UX 3.x.x's MacOS interface is based on System 7.0.1. You cannot install Sys 7.1 on A/UX (meaning you can't make A/UX run Sys 7.1) since there are a few system files that are fine-tuned and modified to work under A/UX. These would get overwritten if you tried to install 7.1 and you'd be out of luck. Please recall that this doesn't mean that you can't have 7.1 installed on your MacPartition, to be used when in MacOS-only mode. It just means that you can't have A/UX run 7.1.
Just to let you all know, if you really want to, you can install 7.1 on A/UX 3.x.x and the MacOS-stuff will work pretty well. However, all hybrids, such as CommandShell or Commando, will die... not too useful...
This one is tricky. First of all, the version of AppleTalk under A/UX was designed specifically for A/UX... Don't try installing the Network Software Installer (NSI) disk. Bad Things will happen.
With that out of the way, when polled by InterPol, A/UX will respond that AppleTalk v56 is running. However, A/UX's version is really compatible with version 58. This will cause trouble with those applications that rely on version numbers rather than capability.
The copy of MacTCP that ships with A/UX is specifically written for A/UX. You should not replace it with any MacOS version of MacTCP! Doing so will cause mucho problems for A/UX. This is because A/UX's MacTCP simply offloads all networking functions down to A/UX itself which handles them.
Although it's true that some MacOS programs, such as Mosaic, "require" MacTCP 2.0.[2|4|6], the vast majority work just fine with A/UX's version. In extreme cases, with programs that actually check the version number, a little ResEdit hacking will fix things up. Basically, all you need to do is copy the 'vers' resource of MacTCP 2.0.[2|4|6] and paste it into MacTCP in your active A/UX System Folder (you want to 'Replace' the previous 'vers' resource). This will cause MacTCP to appear (via 'Get Info' and similar ways) to be version 2.0.6.
No it doesn't... The reason is because the LaserWriter Bridge software requires AppleTalk version 57 or higher but, due to the way AppleTalk is implemented under A/UX, the software thinks and behaves as if A/UX is running a version closer to v56.
A/UX, however, can print to a printer connected via the LaserWriter Bridge on a different Mac.
Sounds like the /etc/FileIDs file is mangled. Rename /etc/FileIDs to something like /etc/FileIDs.OLD and reboot. fidd will then create a new /etc/FileIDs file and all should be well.
A/UX 3.x.x's 'tc' device driver (version 1.40) officially and "totally" supports the following tape drives: Qualstar 9 track, Archive 4mm DAT, Archive QIC, Teac DCAS 600, Exabyte 8500 (no go with the 8200s), DC2000.
Please note that all the devices except for the Qualstar 9-tracks require 8k-blocking when used through 'tc'. This means you will need to use 'tcb' or 'tbb' as a filter ('dd' will also work during reading). You should also specify 8k blocking (or a multiple thereof) when using dump.bsd.
Jim Jagielski has created a replacement for 'tc' called 'NEWtc'. It fixes a lot of Apple's 1.4 bugs as well as to provide some nice new features. It supports all the above drives in addition to: CIPHER drives; Exabyte 8200, 8205, and 8505; HP DATs; SONY SDT line; Teac DCAS 150 and 60; WangDAT 1300 and 2600 series; WankTEK series 6130 (FS/HF), 5525, and 5050ES.
It also has a "Generic" entry that will attempt to drive tapes it doesn't know about. If you have a drive that isn't supported, let Jim know and he'll try to add it.
NEWtc is up to version 3.34 and is available on jagubox. Included in the package are replacement copies of 'mt', 'tc.7.Z' and 'mt.1.Z'.
Tony Cooper has written a very nice double-buffering copier that greatly increases the speed of backups; it's called 'tbb.' It works quite nicely with 'tc' (assuming the correct blocking factors)... It's included with the 'NEWtc' package.
Craig Ruff (cruff✉ncar.ucar.edu) has written a Teac device driver also, which works with both the 150 MB and 60 MB drives. You get the complete source so you may "adjust" the driver if you want for other drives.
The Teac driver is available on jagubox.
For more information about 'tc', please contact Jim via e-mail.
For more information about 'teac', please contact Craig via e-mail.
The "problem" is with the generic SCSI disk driver under A/UX. For SCSI drives, there are certain parameters that may be adjusted by the user; these parameters are grouped in "pages." One such page concerns how the disk responds to and recovers from errors: the Error Recovery Page. A/UX expects the parameters in this page to have certain values. Now the vast majority of SCSI disks have the values set as expected, but this isn't the case with SyQuest drives. There is one parameter (PER) which is opposite than expected by A/UX. When A/UX trys to set this value to what it wants, however, the SyQuest drive reads this "request" wrong (the request is 16 bytes but the SyQuest only reads 4, so the SCSI Manager reports the error.
Tony Cooper (tony✉marc.cri.nz) has written a Mac application which sets the Error Page values correctly: Fix Error Page. This application must be used under the MacOS. It can be found on jagubox as well as on aux.support.apple.com (aux.patches/unsupported/2.0). You can also use the FWB Hard Disk Toolkit - World Control Application to enable the PER bit in the recovery page (Page #1).
This program may also be a help in getting some SCSI-2 devices, such as disks and opticals, to work under A/UX. If A/UX sees that the Error Page parameters are incorrect, it will attempt to send a Mode Select command to fix them, however it will use the SCSI-1/CCS page length instead of the SCSI-2 length, which, depending on the drive, will not work.
By the by, here is the /etc/disktab entry for SyQuest:
# SyQuest disk
#
Syquest|syquest|S45:\
:ty=winchester:ns#34:nt#2:nc#1275:
Except for 9-track magtapes, all I/O to tape drives associated with the 'tc' device files must be blocked at 8k. The 'tcb' program does just that so that should be included. For example, to write:
$ find . -print | cpio -o | tcb > /dev/rmt/tc1
And to read:
$ tcb < /dev/rmt/tc1 | cpio -i
You can get better performance if you increase the buffer size (just make sure that it's a multiple of 8k). For example, you could use 'dd' as your blocking filter with a 'bs=10x8k'.
Jim Jagielski's replacement for 'tc' allows for 'tc' to use the tape drive's own physical block size as the logical block size for I/O. Doing so results in a bit of a performance hit so it isn't recommended for normal use. You should use the "mode" only if you need to read tapes written by 'st' or by another platform. Please note you are still limited to an I/O block size of at least the physical block size, which can be anything for 512 to 1024 to 8192 bytes.
For more information about 'tc', please contact Jim via e-mail.
You certainly can. There are some tricks in getting it to work and be usable under the MacOS environment, but they are pretty easy.
First of all, the device-files (slice31) for the Zip drive needs to be readable and writable by the person using the MacOS. If you are the sole user of the A/UX machine, then it's easy: chown yourname /dev/rdsk/cXd0s31 /dev/dsk/cXd0s31 where 'X' is the SCSI ID of the Zip. If your system is multi-user, then you'll need to: chmod 666 /dev/rdsk/cXd0s31 /dev/dsk/cXd0s31
You need to have the Zip catridge in the drive while the MacOS-A/UX environment is booting for the disk to be mounted.
If you will be using the Zip only as a Unix file system, here are some hints:
This only shows up on versions of the IIg (and IIf) with less than 5MiB RAM. The reason is because this makes the LW default to PhotoGrade-mode. You can do 2 things to fix this:
If you are only using "Letter" mode under 'lpr', then you can edit /usr/lib/ps/pstext.pro to include the following line between "% RCSID:..." and "/StartPage...":
%!PS-Adobe-1.0
% Z%Copyright Apple Computer 1987\tVersion 1.1 of pstext.pro on\
87/05/04 19:02:25
%%Creator: pstext
%%DocumentFonts: Courier
% RCSID: $Header: pstext.pro,v 2.1 85/11/24 12:19:55 shore Rel $
====>>>letter
/StartPage{/sv save def 48 760 moveto}def
This will fix the problem and make it usable again.
From a post by Antonio Ordonez (antonio✉apple.com)
If the printer is in another zone, it is necessary to define the zone in which the printer is located with a full path name. You can then "hardwire" a printer name including the zone for a particular printer queue.
The best way to do this is to make a copy the /usr/spool/lpd/AppleTalk directory and give it a name related to the printer we want to use. Modify the file ifilter/ofilter/nfilter (it is the same file with 3 hard links) in this directory. Also modify the /etc/printcap file to create a new printer queue.
I will use my system as an example so please modify to reflect your situation.
The first thing to do is to create the new directory and put the correct files in it. Note that I am using mknod to create the pipe file.
mkdir Idaho chown daemon Idaho chgrp daemon Idaho cp AppleTalk/ifilter Idaho/ifilter cd Idaho ln ifilter ofilter ln ofilter nfilter mknod pipe p chown daemon * chgrp daemon *
In my case I have a printer called "Idaho Spooler" in the zone "SCV CAM2
2nd W" while my system is on the zone "SCV CAM2 2nd E", so all I do is to
modify the /usr/spool/lpd/Idaho/ifilter file (you can use vi or
TextEditor)
and change the line that defines the value for Printer from Printer=`basename "cwd"` to Printer="Idaho Spooler:LaserWriter@SCV CAM2 2nd W".
In the /etc/printcap file I copy the entry for AppleTalk (all six lines) and change any reference to AppleTalk to the name I used for my new directory. Again, in my case I used "Idaho" as the directory name so my /etc/printcap file looks like:
#
# pragma ident "@(#)lpr:printcap 5.4 90/03/27 "
#
# Copyright 1990 Apple Computer, Inc.
# All Rights Reserved.
##
# Remote AppleTalk printer (selected by Chooser)
# For an AppleTalk printer which doesn't support PostScript remove last 2 names.
lp|at|AppleTalk|postscript|PostScript:\
:lp=/dev/null:\
:if=/usr/spool/lpd/AppleTalk/ifilter:\
:of=/usr/spool/lpd/AppleTalk/ofilter:\
:nf=/usr/spool/lpd/AppleTalk/nfilter:\
:sd=/usr/spool/lpd/AppleTalk:
lp2|Idaho:\
:lp=/dev/null:\
:if=/usr/spool/lpd/Idaho/ifilter:\
:of=/usr/spool/lpd/Idaho/ofilter:\
:nf=/usr/spool/lpd/Idaho/nfilter:\
:sd=/usr/spool/lpd/Idaho:
After all these steps are completed restart the printer queue with the command lpc restart all.
Now you should be able to send a print job to the printer in the other zone with the command lpr -Plp2 /etc/passwd or lpr -PIdaho /etc/passwd.
Hope this helps.
No, it won't... You need to use AppleTalk to use it under A/UX.
For the answer, snag a copy of DeskWriter.txt which is available via anon-ftp on jagubox in /pub/aux/Info.
Bad news... for some reason, if the LaserJet is connected directly to a Q700 running A/UX via AppleTalk then it won't work. If you have a router or something similar between the two it'll work like a hose. It looks like it's most probably a 4M ROM bug and supposedly HP was "working" on a fix.
A/UX 3.x.x fully supports the Apple OneScanner as well as providing better support for SCSI devices. A/UX will still use its own SCSI driver, however.
The Gravis SuperMouse was a 3-button mechanical mouse that was completely configurable and compatible with A/UX and was at the time your best bet. At present, however, the Gravis SuperMouse is no longer manufactured or supported at all by Gravis. ☹
Older versions of LogiTech's MouseMan are fully compatible with A/UX, as some people have been using them with no problems. However, newer versions aren't as nice, since you can't reconfigure the button binding.
Mouse System's A-3 mouse is "fully" compatible with A/UX, but is hard-wired configured for A/UX as: left button = actual mouse button; middle button = left arrow; right button = right arrow. (The "A-3" power cdev doesn't work under A/UX, hence it is not programmable.) Since Option-⇦ and Option-⇨ are the combinations used for emulating the middle and right buttons (respectively) with a one-button mouse in MacX (if configured that way) and in a true X11 session, pressing the Option key while clicking buttons 2 and 3 should give the desired effect. The A-3 mouse is an optical unit with a nice feel, but as was common with earlier optical mice, requires a special mousepad.
Please note that A/UX 2 & 3 only support a subset of the ADB Manager. Thus there are a few ADB devices that may not work under A/UX.
Information on 2-button mice?
No it doesn't... This is due to the way the Adjustable keyboard actually works and the fact that A/UX doesn't fully support the ADB Manager. ☹
Yes.
There is one major caveat, that will hopefully be addressed in future versions. On startup, A/UX reinitializes all hardware drivers, including the video-drivers; as a result, most accelerated 24-bit cards (all third-party cards known to date, as well as Apple's old 8*24 GC card) will be reinitialized to run in non-accelerated mode. You'll still get 24-bit video, but depending on your hardware, it may be painfully slow.
This could be solved by better driver support from the vendors of accelerated video cards. Certain vendors have been promising such support for awhile now.
The best hardware to run A/UX with 24-bit video enabled are currently the Quadra 700, 900, and 950, whose internal video can be populated with enough VRAM to support 24-bit color (note that the Q800 cannot do this !). Performance is considered good under A/UX by many users.
The following is a list of 24-bit cards that readers have reported work with A/UX from personal experience. It is not a complete list; there have been no reports of cards that work under MacOS but not A/UX (excepting the caveat detailed above): Apple 8*24, 8*24GC; Quadra 700, 900, 950 internal video; PrecisionColor PRO 24xp; RasterOps 24STV, Paintboard li; Radius 24XP, 24XK.
Absolutely! The card makes an amazing difference in performance. However, this performance increase is reduced when an external monitor is used. For more information about extensive benchmarking with the IIci and cache cards, you can snag the benchmarking results via anon-ftp on redstar.dcs.qmw.ac.uk in archive/papers.
For the most part, all DayStar Digital accelerators are compatible with A/UX 3.0 even if their controlling CDEVs don't work under A/UX (the accelerator must be enabled with the CDEV before booting A/UX). However, their 040 accelerators do not work under A/UX. In fact, except for Apple's own Quadra 700 Logic Board Upgrade, there are no 040 accelerators that work (i.e. don't crash) under A/UX.
There has been at least 1 report of the DayStar-accelerated Mac II not working under 3.0.2... it's possible that 3.0.2 is more sensitive to timing than 3.0 was... If in doubt, be sure that you can return the accelerator if you can't run it under A/UX.
According to Daystar Digital, the DayStar QuadraCache is not compatible with A/UX. DayStar is working on a fix... Nonetheless, there are a number of people (including people at Apple) who are using these cache cards with no problems at all and with very nice (~25%) performance boosts.
This is kinda skimpy, but I'd thought I'd start it up. Email me your list
Many hard disk applications will reveal the disk drive geometry for you: FWB Hard Disk ToolKit is very good (SilverLining is a bit wrong on the number of tracks... it includes spares). What you are really looking for are the total number of cylinders ('nc'), the number of sectors per track ('ns') and the number of tracks ('nt').
By far, the easiest (and cheapest) way is to use the SCSIProbe utility, by Herb Weiner (herbw✉wiskit.com), that runs under A/UX. This neat little package automatically generates disktab entries for your disks.
Jim is maintaining a list of /etc/disktab entries. If you have any, send it to him and he'll add them.
The file is available on jagubox. lots of entries needed
Just a note: the number of tracks ('nt') is equal to the number of heads.
The original Apple CD-ROM drive (CD SC) is 100% compatible with A/UX as is the newer CD-150. Older versions of the CD-300 (those with pre 1.8f ROMs) would cause problems with A/UX and would do little more than allow you to install A/UX, making it almost useless for day-to-day use. One of the fixes of 3.0.2 is much better support for all versions of the CD-300, although Apple does suggest that you update the CD-ROM drive's ROMs with the latest version if you have problems. Reportedly, you can get the latest ROMs by calling 1-800-SOS-APPL or seeing your Apple dealer. The following are also known to be 100% compatible (meaning you can use them to install A/UX as well as when running A/UX): Toshiba XM3201, XM3301B XM3401B, XM3501; DEC RRD42, RRD40 (LMSI CM-212); Denon DRD 253; Sun CD-ROM (Sony CDU-8012?); CD-Technologies Porta-Drive CD-ROM; Chinon CDA-431; Pioneer DR-466/DR-U12X.
3.1 adds support for NEC CD-ROMs; previous versions of A/UX weren't able to work with these units due to their physical block size.
The Pioneer DVD-303S-A is reported to work (at least for installation) with the 512-byte jumper set. The Pioneer DR-U16S is also reported to work for installation as well as use under A/UX.
By itself, A/UX doesn't support audio CDs. However, there are 2 software packages that add this capability:
The first package is xmcd/cda, which provides both a X-Motif (xmcd) and generic command-line (cda) interface for playing audio CDs under A/UX. The package requires that the 'devscsi' kernel package be installed, so it will work under 3.x.x. xmcd/cda was written by Ti Kan (ti✉bazooka.amb.org). and can be found on ftp://ftp.x.org/contrib/applications/.
The second package is a MacOS-patch to enable you to use the CD Remote application. Kelly King and Andrew Kass (at Apple), however, have written the "AUX SCSI Toolbox" extensions that emulates the Mac SCSI Manager. With this extension installed, you can run applications and drivers that talk to the Mac SCSI Manager, including the Apple CD-ROM driver! With this extension, you can listen to your audio CDs under A/UX! This is the latest version of the extension: 1.0b4.
"AUX SCSI Toolbox" is available via ftp on jagubox under /pub/aux/Apple.fixes/unsupported/3.0.x/SCSItlbx.tar.gz Please read the included ReadMe before installing and using it.
Other than the "normal" A/UX SysV and UFS file system type, A/UX supports ISO-9660 file system format CD-ROMs. However, you can only access these CDs from the MacOS environment; you can't "mount" them in the normal Unix-way. As distributed, A/UX doesn't include the needed Extensions that allow the MacOS Environment from recognizing these CDs. To fix this, you need to copy the following Extensions from the Apple CD-ROM Software disks (version 3.2 or later) to the System Folder of the user(s) that need access to these CDs: Foreign File Access, High Sierra File Access, ISO 9660 File Access.
The docs are a little blurry on this (even though it's specifically mentioned in Chapter 5 of the "Setting Up Accounts and Peripherals for A/UX") since they say that you don't need to add any kernel resources...
One of A/UX's quirks is that all files on ISO-9660 CDs are "seen" as TEXT type files. This causes troubles with binary files since when you try to drag them over to the "/" disk, A/UX will perform it's \r→\n translation. To avoid this from happening, you can:
Again, please note that A/UX will not recognize any of the audio capability of CD-ROMs unless you add the "AUX SCSI Toolbox" extension described in Devices and Peripherals.
There is a limit on the number of inodes per cylinder group (2048). Large disks (2-4GB) are setup so that each cylinder group is quite large (>5MB) so that when 'newfs' creates the file system, it hits the limit quickly and you end up with a disk with a "small" amount of inodes.
The trick is to use the '-c' option to 'newfs' to make each cylinder smaller by reducing the number of cylinders per group. In many cases, 'newfs -c 8' works well. Of course, you should use this in combination with the '-i' option as well.
The reason is because to access the card (which is seen as a device by A/UX), you need an A/UX device driver for it. This is not the same as the stuff you had to install under the MacOS for it to work. Now A/UX includes drivers for the Apple EtherNet card (they aren't installed by default though), but they don't work with most of the 3rd party cards except for the 3Com "EtherLink NB", the Asante "MacCon" and the StarNet Networking cards. They are 100% register compatible with their Apple counterparts, so you can use Apple's 'ae' driver with them. Drivers for the EtherPort II cards are available via anon-ftp on jagubox. However, the drivers for the "old" EPII cards (full length) only support TCP/IP (they were written for A/UX 1.1 but will work under 2.0.x). As far as other cards are concerned, you will have to ask the vendor for A/UX drivers for it.
Please note that there have been numerous reports about problems with the EtherPortII cards, A/UX and the IIfx and IIsi... you are warned. ☺
There are a number of serial cards that "work" with A/UX. The Apple serial card is not one of them.
There is the Digiboard Nu/Xi, which comes in 4 and 8 port versions. Brand new drivers for the card have been coded and are available. This version (3.3.0) however, doesn't currently work with CSlip but otherwise works great. You can snag the drivers via anon-ftp from digibd.com (which is 192.83.159.193) in drivers/mac.
Technical Support for DigiBoard is 612-943-9020. If you'd like to contact the main engineer responsible for the drivers, contact Brian Westley at the following Email addresses: merlyn✉digibd.com, ...uunet!digibd!merlyn, AppleLink: merlin.
There is also the Creative Solutions, INC (CSI) HQS/HDS v4.4/4.5 Hurdler Serial Nubus cards. These cards have both pure Unix and MacOS device drivers (i.e. a 'newconfig' code module and a MacOS INIT/DRVR module). The A/UX drivers support baud rates up to 57.6k and 115.2k using the 'B50' and 'B75' flags, true hardware handshaking while monitoring DCD for Dialup security, and full compatibility with CSlip and PPP and their associated daemons. The A/UX-MacOS drivers are fully compatible with all CommToolbox functions and serial drivers. These are very nice cards. ☺
The recommended cable-pin out for these cards is:
Mac Modem
Male Mini-Din-8 DB-25
--------------------------------------------
1 (HskO) --- 4 (RTS)
2 (HskI) --- 5 (CTS)
3 (TxD-) --- 2 (TxD)
4 (GDN) --- 7 (SigGnd)
5 (RxD-) --- 3 (RxD)
6 (TxD+) --- 7 (SigGnd)or(NC)
7 (GPi) --- 8 (DCD)
8 (RxD+) --- 7 (SigGnd)
6 -- (DSR)
|
20 -- (DTR)
Also, for logins, you should be using the FLOW flag in the gettydefs file as for example:
fl_38400#B38400 # B38400 SANE2 TAB3 # ~MODEM ~DTR FLOW #\r\nlogin: #fl_38400
For further info about the drivers, or for any help is using this card, please contact Alan M. Friedman at Intelligent Interfaces, Inc: alan✉kether.intellint.com or AppleLink: D5620.
You can contact CSI at csi✉applelink.apple.com (AppleLink: CSI).
Yet another is the Applied Engineering QuadraLink serial card. According to sources, the board was super easy to setup and use. It also appears very solid as far as performance.
The AE QuadraLink card, like the CommCard and the Apple ports, can't do both hardware handshaking and modem control at the same time. No hardware patch kit will be developed for the AE card...
The AWS95 PDS Card (known as "Pisces") has two main functional additions to the Q950. The first is that it includes an external level-2 cache for the Quadra's 68040. The cache size is 128K, but this can be increased with Apple provided SRAM upgrade kits. The use of a L2 cache increases the base performance of the Q950.
The second capability that Pisces includes is the addition of two additional upgraded SCSI buses. Pisces fully supports Direct Memory Access (DMA) on these SCSI buses. This can greatly increase SCSI throughput by offloading SCSI operations to the PDS card. The card supports active termination and negation on the 2 SCSI DMA buses, improving signal quality and integrity.
SCSI under A/UX is SCSI-1/CCS and not SCSI-2. However, A/UX can use most SCSI-2 devices. Problems will arise on some SCSI-2 disks if their Error Correction Mode Pages are incorrect (See above). A/UX supports SCSI connect/disconnect which results in more efficient use of the SCSI bus. Finally, A/UX provides asynchronous I/O as well.
Well, it's not really them at all. Many people have found that more than a
few ports require the addition of the 'set42sig()' call to enable BSD 4.2
signal delivery. The best place to add this is as the first executable statement
under "main() {".
Another point about porting applications: A/UX's 'cc' does provide "strict" BSD, SystemV and Posix libraries. If you are porting a BSD program, you can enable BSD "emulation" by adding the "-ZB -lbsd" options to your 'cc' command line. In fact, using just the '-lbsd' option alleviates the need for adding the 'set42sig()' call mentioned above and is, in many cases, the suggested option. Compiling with gcc also helps out a great deal.
Ask and ye shall receive! R5 can be found on the www.funet.fi site, and R6 is at ftp.geo.tu-freiberg.de and www.aux-penelope.com.
Although it's true that FSF is "boycotting" Apple and A/UX (FSF doesn't like Apple's predisposition of suing to protect "look and feel"), ports of most GNU applications are available.
GCC version 2.7.2 for A/UX has been ported (by Jim Jagielski, based on previous ports by John Coolidge) and is available... Highly recommended! As a nice complement to using GCC, gdb (4.9) is also available. For more info about gcc for A/UX, please contact Jim via e-mail.
Sadly, the archive at wuarchive.wustl.edu has been removed, and now contains only Linux-related material. However, the GNU goodies are still available on ftp.geo.tu-freiberg.de and www.nleymann.de. Scott Kanne also hosts some of these at aux-penelope.com.
It seems most likely that the reason is because they attempt to use a different file locking scheme that /bin/mail does. Pre-3.0 versions of mail used 'flock' style file locking. 3.x.x now uses the '.lock' scheme for mail file locking. Elm 2.4.X requires that both flock and .lock be enabled. Elm 2.3.X requires only .lock locking.
A/UX comes with a C compiler ('cc'), a FORTRAN-77 compiler ('f77') as well as an assembler ('as'), SNOBOL ('sno') and a kinda-basic interpreter ('bs'). 'cc' is a nice, stable, if not-too-quick compiler. 'f77' is a true FORTRAN-77 compiler and appears quite workable. Jim has not used 'sno' (and couldn't recall how to program in SNOBOL if his life depended on it ☺) or 'bs'.
If you are doing any work in C, then it would be well worth it to get a copy of the GNU C compiler ('gcc') (see above). gcc is K&R and ANSI compatible so if you are doing ANSI work you'll need it. Apple also has an ANSI C compiler ('c89') that you can buy. It's available on the "A/UX Developer's Toolkit CD" from APDA. There is also at least one other 3rd-party C compiler out there, but the name is unknown. gcc is free; c89 runs about $800. Both include C++ capabilities.
There are also 2 very good 3rd-party FORTRAN compilers: NKR FORTRAN and Absoft MacFORTRAN II. In my opinion, MacFORTRAN II is the better product... it has finer compiler control, a wide number of compatibility options (such as VAX FORTRAN) and excellent speed. If you do order MFII, be sure to get the A/UX version. They also sell an MPW version that will work under A/UX but it's run under, you guessed it, MPW. The A/UX version is a true "Unix" compiler and it's optimized for A/UX. Both MFII and NKR FORTRAN run about $500-$600.
Oasys sells 3 compiler packages: C, C++ and FORTRAN. All the compilers are based on the GreenHills compilers which are known to be robust and fast. However, the Oasys packages are expensive, running about $2000 per language (although you do get assemblers and linker/loaders with the package). Unisoft used to distribute their "Optimizing Compilers" (FORTRAN and C) for A/UX, but they are no longer available... Pity, because they also were based on GreenHills and were quite nice.
At present, there are no known true Pascal compilers for A/UX.
Finally, if you are doing program development, then you'll need a good debugger. As described above in "List of ports...", gdb has been ported if you would prefer using something other than sdb or dbx, which are included with A/UX. If you are using FORTRAN, then Absoft also makes an excellent debugger which has been fine-tuned to work with MFII (it also does quite well with C); it's called FX. It has two interfaces, character and Motif, and is quite powerful.
The only known source for OSF/Motif (1.1.4) for A/UX is:
Integrated Computer Solutions 201 Broadway Cambridge, MA 02139 617-547-0510
However, they have stopped producing this and have since stopped support for A/UX OSF/Motif. They may still have a few copies of it available, so if you don't mind using unsupported software, give them a call.
If you have, or can get, the actual source code for Motif then the following will be of some help: 1.1.4 compiles with minimal changes to the source using 'cc' and works "great." However, the source for 1.2.2 makes calls to various XIM multi-character routines, leaving many unresolved externals when linking. Now, if someone ported X11R5 and left the XIM routines intact, then maybe compiling and linking 1.2.2 would go off without a hitch... Any takers??
'ranlib' is a program that increases the efficiency of accessing and using archives (*.a files). A/UX's 'ar' already does this, so it isn't needed. To get around this, do something like ln /bin/true /bin/ranlib.
You could also use '/bin/touch' but the above will (hopefully) take care of cases when ranlib is called with options. If you want to put 'ranlib' somewhere else, then that's OK. If the location is a different file system, then you'll need to use a symbolic link: ln -s /bin/true /usr2/local/bin/ranlib
The 'locale' suite can be found in /lib/libposix.a. To avoid linking to libposix.a you can do the following to create a separate locale library:
$ ar xv /lib/libposix.a locale.o $ ar rv /usr/lib/liblocale.a locale.o
Now you can simply link to '-llocale' to add it in.
A better fix would be to grab and use libUTIL, a collection of useful and needed functions for any serious porting effort (see Hints & WoW, above). libUTIL is maintained by Jim Jagielski and can be found on jagubox.
The nlist structure used by nlist() is a very weird beast. The structure itself contains a union, which can cause problems with automatic initialization of nlist. In particular, there are specific times when you need to use "n_name" and other times when you must use "n_nptr". Here's the deal:
var = "timbuf"; strcpy(nl.n_name, var);var = "longlook"; strncpy(nl.n_name, var, 8);var = "clock_offset"; nl.n_ptr = var;AppleTalk is probably enabled for the port. The getty process can be started temporarily by turning off AppleTalk via A/UX's Finder Chooser and then using the 'setport' command.
You can permanently disable AppleTalk by reconfiguring the kernel with "newconfig noappletalk". If you wish to keep the drivers installed in the kernel but still want to "permanently" disable AppleTalk, you can edit /etc/startup to prevent AppleTalk from initializing and /etc/inittab can be editted to start getty. (/etc/startup is regenerated by newconfig so you'll have to redo this if you reconfigure the kernel.)
If you don't have an EtherTalk card installed, then you can also modify /etc/appletalkrc to point to "ethertalk0" instead of "localtalk0". Doing this stops AppleTalk from bothering the serial port because it tries to use the non-existant card.
Well, the problem is actually with sendmail (in /usr/lib). sendmail (under A/UX 2.0 and later) assumes the use of a nameserver. Pre-2.0 versions were "adjusted" to look in /etc/hosts if any nameserver call failed — which it would if it wasn't running, of course. ☺
Jim Jagielski (jim✉jagubox.gsfc.nasa.gov) has hacked sendmail 5.65 for A/UX to have it also check /etc/hosts. The source code is available on jagubox.
You may also want to upgrade to smail 3.1.28. smail is a very powerful yet easy to configure (and maintain) replacement for sendmail. It can both query the NameServer as well as look in /etc/hosts to "interpret" hostnames. The required A/UX-related diffs and patches, which were written by Bob Denny (denny✉alisa.com) are available on jagubox.
For more info, contact Jim.
This message is produced by sendmail (/usr/lib/sendmail) when it's frozen configuration file (/usr/lib/sendmail.fc) is unusable (as it is in the A/UX distribution which has it as a 0-byte file). To create a "new" frozen file of your present sendmail.cf file (assuming that it's good), type: /usr/lib/sendmail -bz - the sendmail daemon, if it exists, must be killed first.
First of all, you must edit /etc/inittab to start getty on tty0 using mo_2400 (or whatever speed you want, such as mo_9600):
00:2:respawn:/etc/getty -u -t 60 tty0 mo_2400
Make sure that your modem is set to be quiet, to not return result codes and to not echo back. It must also reset on DTR being dropped ("atq1e0&d3" will achieve this for most Hayes-compatible modems except certain (all) USR modems). Your modem must also raise DCD on connection ("at&c1") in order to have Dialup security (i.e. when the line is closed, HangUp the process. This means that MODEM flow control must be specified in gettydefs). You then save these changes using the "at&w" sequence. Finally, to make it autoanswer, be sure to add "ats0=1&w".
Make sure that the modem cable is correctly configured (this is for Dialup Security!):
Mac Modem
--------------------
1 (HskO) 20 (DTR)
4 (RTS) <- yep... it gets sent to Pin 20 & 4
2 (HskI) 8 (DCD)
3 (TxD-) 2 (TxD)
4 (GDN) 7 (Sgnd)
5 (RxD-) 3 (RxD)
6 NO CONNECT
7 NO CONNECT
8 (RxD+) 7 (Sgnd) <- this is right, it gets tied to Mac pin 4 too.
If you mess up pin 8 things can get so flaky that you'll never figure out what's going on. You see, by grounding pin 8, you make the modem port truly RS-232 compatible. If not grounded, the port will use the RS-422 standard, which can cause lots of problems. For more info about pinouts and cable pinouts, check out "/usr/lib/uucp/README".
Please note that getty is the bidirectional version of getty, which is sometimes known as uugetty. Thus, you can have dial in and dial out at the same time on the same port. You should be using at least version 1.16 of HDB (see above: known bugs and Administration Q&A)
As mentioned above, the cable described provides for Dialup Security and prevents the use of hardware flow control... If, however, the exact same baudrate is used throughout the phone link, the need for hardware flow control is greatly reduced.
The reason why is because there are two versions of talk (and it's daemon talkd) out there. A/UX uses the BSD 4.2 version. Others use the 4.3 version. The two aren't compatible and don't even talk on the same port. If you try to talk to someone and all you get is a "Checking for invitation..." message then it's because the machine you're trying to access is using 4.3.
Steve Green (xrsbg✉dirac.gsfc.nasa.gov) has ported the 4.3 versions of talk and talkd (now renamed ntalk and ntalkd for A/UX) to overcome this snag. You can have both versions available and running with no problems. The port is available on jagubox.
You will need to use 'adb' to adjust the A/UX kernel to enable IP forwarding. This is done by changing the value of the 'ipforwarding' "variable" from 0 (no forwarding) to 1 (enable forwarding).
As root, and in single-user mode, apply this patch:
# Enable fowarding: just the kernel
adb -w -k /unix << Foo
ipforwarding?D
ipforwarding?W 1
$w
$q
Foo
And reboot.
You'll need to redo this whenever the kernel is rebuilt (like via 'newunix') unless you apply the patch to /etc/install.d/boot.d/bnet as follows:
# Enable fowarding: keep it that way
adb -w /etc/install.d/boot.d/bnet << Foo
ipforwarding?D
ipforwarding?W 1
$w
$q
Foo
Unfortunately, there is no known port of PPP for A/UX. ☹
You will need to use 'adb' to adjust either the kernel or the CSlip driver to change this value (slip_mtu). As root, and in single-user mode, apply this patch (please replace $THE_VALUE with the actual HEX value you want MTU to be):
# Change SLIP MTU value to $THE_VALUE: just the kernel
adb -w -k /unix << Foo
slip_mtu?d
slip_mtu?w $THE_VALUE
$w
$q
Foo
And reboot.
You'll need to redo this whenever the kernel is rebuilt (like via 'newunix') unless you apply the patch to /etc/install.d/boot.d/cslip as follows:
# Change SLIP MTU value to $THE_VALUE: keep it that way
adb -w /etc/install.d/boot.d/cslip << Foo
slip_mtu?d
slip_mtu?w $THE_VALUE
$w
$q
Foo
Now run newconfig -v and reboot.
On your Solaris client, you need to add the 'rsize=1024 wsize=1024' parameters to your mount option.
Check that NFS support is built into your kernel with module_dump /unix first. If not, you'll need to build a new kernel with newconfig.
If the kernel is OK, maybe you just didn't enable the NFS client services in /etc/inittab. Change the nfs4, nfs5, nfs6, and nfs8 lines as directed there.
This may be due, most probably, by the small size of A/UX's listen() backlog queue. This queue is basically the number of pending connections listen will allow. Under A/UX, this value (known as SOMAXCONN) is a measly 5. Since Netscape, for example, send 4 connection-requests per connect, you can see how you would over-reach the queue quickly if your server is busy.
Jim Jagielski (jim✉jaguNET.com) has written a small shell-script that uses 'adb' to patch the kernel 'bnet' module to increase the queue limit from 5 to 32. It's available on jagubox in /pub/aux/Sys_stuff
This behavior is due to the tty driver under A/UX. The BSD tty driver (which A/UX doesn't use) handles this, whereas the SysV driver doesn't. If you are running 'ksh' then you can "set -o viraw" to prevent this from happening. There are no known work-arounds for 'sh' or 'csh'. ('tcsh' and 'bash' do not suffer from this problem... )
The reason why is because both X and the CommandShell want complete control over your Mac (display, keyboard and mouse). So, when you try to start one while running the other, you'll get into trouble. You need to start X either from the Console Emulator Mode or by choosing it as your "session type" from the Login screen. This session type will be available only if your installed Apple's X.
This is printed out whenever your kernel is configured for NFS and a file- lock is attempted (as when sending Email) but the NFS lock daemon (rpc.lockd) isn't running. This is most probably due to the fact that it wasn't started in /etc/inittab. The fix is simple: enable rpc.lockd (and it's companion rpc.statd) in /etc/inittab as follows:
nfs5:2:wait:/etc/rpc.statd # set to "wait" for NFS status monitor nfs6:2:once:/etc/rpc.lockd # set to "once" for NFS lock manager
and either Restart A/UX or simply type 'init q'.
There are three possible solutions:
Both these commands require read access to /dev/kmem, which is not allowed for regular users. Thus, the programs require that they be suid or sgid to the user or group that can read /dev/kmem. See if this is true and fix if not.
This FAQ is "copyrighted" in the same sense that all other FAQs are copyrighted: the FAQ may be freely redistributed as long as the author's/editor's name and this notice is included. If contents of this FAQ are to be published, then you should ask the author's/editor's permission to do so.
Tim Larson - FAQ list maintainer