sys0001@dircon.uucp (06/07/90)
I've been installing SCO UNIX 386 and I've come up against a couple of problems. First of all, I want to several users to share a home/login directory. However, in the 'sysadmsh', when I try to enter the same home directory for more than one user, I get an error: "Home directory already exists". The program will not let me add the user until I change the home dir to one which doesn't already exist. In fact this occurs with all logins, whenever the home directory already exists. Is there any way of overcoming this? Also, is there a command-line interface method of adding users. I've got a batch of several hundred which I want to add in one go (from a Xenix system). It would be handy if I could add them in one go, setting their ID number, group, login shell and home dir in a batch file. Any ideas on how this could be done? I'd like to do this in a way which keeps the 'tcb' C2 security files up-to-date as well. The second problem I've come across is that when I run a program from my Xenix system under UNIX, it drops out (no error message or anything) back to shell whenever it comes across a call to the C read() function to read a record from a small database file into a structure: ie something along the lines of read(fd, &rec, sizeof(struct rec)). It seems not to even get to the line following the read(), so I can't test for return values. This behaviour is exhibited wherever read() is called, apparently after the relevant file has been opened with O_RDRW|O_SYNC. I've tried recompiling using the SCO UNIX dev system (with the -xenix flag) but no go. The program still drops out without any error message. Help/ideas/comments much appreciated! (by the way, this program currently works fine under Xenix 2.2). If I remove the O_SYNC flag then the program seems to work OK. Oddly, I noticed that under Xenix 2.2, the O_SYNC flag has a W on the end, but in UNIX, it doesn't. This doesn't seem to be mentioned anywhere...? Finally, can anyone let me know what the fix/patch is to switch off the long filename truncation errors, which are getting to be a real pain. Thanks! -- sys0001@dircon.UUCP or sys0001%dircon@ukc.ac.uk
rogerk@sco.COM (Roger Knopf 5502) (06/12/90)
NOTE: this is an extremely long posting, but I think it contains much of interest to many net readers. In article <1990Jun6.202656.14890@dircon.uucp> sys0001@dircon.uucp () writes: >First of all, I want to several users to share a home/login directory. >However, in the 'sysadmsh', when I try to enter the same home directory >for more than one user, I get an error: "Home directory already exists". >The program will not let me add the user until I change the home dir >to one which doesn't already exist. In fact this occurs with all logins, >whenever the home directory already exists. Is there any way of overcoming >this? Let me first say that the advice I am about to give may, if followed, lead to less than C2 level trustedness on your systems. If you follow it, I assume you don't care about C2. Caveat administrator. This is correct, sysadmsh will not allow users to share home directories. That doesn't mean that it can't be done, though - there is nothing that will break if you do this, although some programs may complain about it. There are three approaches you can take to accomplish this: 1. Edit the home directory after you have created the account. Remember to change it in both /etc/passwd and /tcb/files/auth/<login first initial>/<loginname>. Ugly, nonportable but it works. Example: my entry is /tcb/files/auth/r/rogerk. The structure of the entry is self-evident (didn't professors in college say that when they either didn't know or didn't feel like explaining?) but be sure not to change anything but the home directory. 2. Use /tcb/bin/addxusers. This isn't exactly user friendly but it will add a user for which the home directory exists (although it will complain about the fact that they don't own it). It also means that you have to come up with an encrypted password to put in the input file (for those not familiar w/addxusers, it takes a Xenix passwd file as input). This can be done by a) using a standard encrypted password to start with, perhaps the null password, or b) writing a program to encrypt the password. If you can do the latter, then you may also be able to: 2. Write your own program to make new accounts. There are library calls to write new /etc/passwd (putprent) and tcb entries (putprpwent). The latter is not easy to use and I hope to have a good example program soon. It is easy enough to modify our standard /usr/lib/mkuser scripts to make accounts or write your own (make a directory, copy in a .profile or .login/.cshrc or whatever, chown to the user). If you want C2, be sure to check authorizations before creating or changing a password entry and write an audit record on all failures or unauthorized attempts. >Also, is there a command-line interface method of adding users. I've got a >batch of several hundred which I want to add in one go (from a Xenix system). >It would be handy if I could add them in one go, setting their ID number, >group, login shell and home dir in a batch file. Any ideas on how this could >be done? I'd like to do this in a way which keeps the 'tcb' C2 security files >up-to-date as well. addxusers is exactly what you want. There is one on your system although there is a new on available in the SLS unx199 (which also has other nice security fixes/relaxations/sysadmin improvments. Get it from support). I don't know if there were any bugs in the older one or any new features added since I never used the older one, but you should have unx199 anyway. Its in /tcb/bin and that probably isn't in your PATH environment variable. >The second problem I've come across is that when I run a program from my >Xenix system under UNIX, it drops out (no error message or anything) back >to shell whenever it comes across a call to the C read() function to read >a record from a small database file into a structure: >ie something along the lines of read(fd, &rec, sizeof(struct rec)). >It seems not to even get to the line following the read(), so I can't test >for return values. C programs don't automatically print error messages, you have to program for it. Nor do they return status to the shell; that is done by exit(). Try this: int nb; if ((nb = read(fd, &rec, sizeof(struct rec))) != sizeof (struct rec)){ if (nb > 0) /* do end-of-file processing */ if (nb < 0) { perror("read"); /* print standard error message */ exit(-1); /* return a status to the shell */ } } This may not be your problem, but your tiny program fragment and comments leads one to believe that these niceties may have been overlooked. >This behaviour is exhibited wherever read() is called, apparently after the >relevant file has been opened with O_RDRW|O_SYNC. I've tried recompiling >using the SCO UNIX dev system (with the -xenix flag) but no go. The program >still drops out without any error message. Help/ideas/comments much >appreciated! (by the way, this program currently works fine under Xenix 2.2). >If I remove the O_SYNC flag then the program seems to work OK. Assuming that you are using a current (read: not beta) OS, this sounds like a bug we should know more about. It would help to make a small program that can reproduce it with and send it to tech support (or me, I'll forward it to the appropriate people). >Finally, can anyone let me know what the fix/patch is to switch off the >long filename truncation errors, which are getting to be a real pain. I think that this should be in Conor's frequently asked Q&A file. It is definitely on our SOS system that is available to all supported customers (find out more by emailing sco!support). For your benefit and the general interest of net readers, here it is: ---------------------------------------------------------------------------- Eliminating errors caused by file names longer than 14 characters. KEYWORDS: file name long file unix adb /etc/_fst patch kernel ETRUNC nami 14 RELEASE: SCO UNIX System V/386 Release 3.2.0 PROBLEM: Attempts to create a file with a file name longer than 14 characters fails with an error rather than truncating the name to the 14 character limit. CAUSE: This functionality was added for conformance to the POSIX standards. SOLUTION: The following patch can be applied to the UNIX kernel so that long file names will be silently truncated. Bring your system into System Maintenance mode and enter the following commands: # /etc/_fst -w /etc/conf/pack.d/s5/Driver.o * $x * s5namei+0xab?w 0x0feb s5namei+0xab: 0xc74 = 0xfeb [response from _fst] * $q # /etc/_fst -w /etc/conf/pack.d/xx/Driver.o * $x * xxnamei+0xa6?w 0x0feb xxnamei+0xa6: 0xc74= 0x0 [response from _fst] xxnamei+0xa8: 0x3d83= 0xfeb [response from _fst] * $q Relink your kernel by moving to the directory /etc/conf/cf.d and entering the command /etc/conf/cf.d/link_unix. You must reboot your system for the change to take effect. -- Roger Knopf <standard disclaimer applies> SCO Consulting Services uunet!sco!rogerk or rogerk@sco.com "...and he's got bare feet, too." 408-425-7222 (voice) 408-458-4227 (fax) --Charley Watkins