Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ucselx!ucsd!ucbvax!UMIX.CC.UMICH.EDU!thompson%pan From: thompson%pan@UMIX.CC.UMICH.EDU (John Thompson) Newsgroups: comp.sys.apollo Subject: re: Problems with email Message-ID: <9007121504.AA24057@pan.ssec.honeywell.com> Date: 12 Jul 90 15:04:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 82 > > > >Jinfu Chen writes: > >> In article <1664@tuvie> mike@tuvie (Inst.f.Techn.Informatik) writes: > >> > I'm not sure whether this is a bug or a feature (on Apollos you never > >> > quite know :-(, but here comes my problem: > >> > > >> > Our mail works OK as long as the registry is available, but > >> > when the registry is down (we do not have slave registries), then > >> > /bsd4.3/bin/mail will not deliver mail to the recipients. Now the > >> > problem seems to be that the mailer cannot acquire the gid of mail, > >> > but about this I'm not too sure. > >> > >> I believe calls in are eventually translated to registry calls, and > >> /etc/passwd, /etc/group, etc aren't just plain unstruct file either. The > >> only solusion is to have slave registry running somewhere else. > > > > There is another alternative; > > The above broblems stem from the fact that the system can not find a > group of mail, either from the registry, or in the /etc/group (how > UNIX like) file. Presumably, he's using sendmail, which is _very_ Unix-like. :-) > If no action is taken to create an /etc/group file, the system will > have an empty file. There is an official and unofficial way to create > the file. The 'empty' file is not really empty. It's a file of type group, and the type manager for that filetype knows to contact the registry server for the information. > Officially, ether run a slave rgyd on the node or run llbd on the > node. In a casual conversation with our system support engineer, it > was recommended that ALL nodes run llbd (not mandatory, but > recomended). Once we started llbd on our nodes, all was well, > assuming that the mail spool directory is available. Running llbd merely allows NCS servers to register themselves with the global location broker (glbd). It has nothing to do with clients trying to _get_ services. If you aren't running an llbd on the node that has rgyd and/or glbd running, you _do_ have a problem (see the "Mananging The NCS Broker" manual). > Unofficially, you could copy the /etc/group file from the master rgyd > node. Well, yeah... you _could_ do that. Note though that ALL the group files on our system (master rgy node's, slave rgy nodes', and everyone else) are 0-length files of type 'group'. Copying the file (at least in Aegis) would not do it for you. You'd need to cat[f] the file, and redirect output to the desired location. If you do, first off, you'll have the registry get out of date eventually. The whole point of registry services being provided by NCS is to _avoid_ having things get out of date, and becoming a management headache. Additionally, you might need to change some source code and recompile too. Note the man page on getpwXXX -- ... If there was no call to setpwfile, these interfaces call the registry server. If this call fails, they search the local registry. If there was a call to setpwfile, these interfaces search name. They access name by way of its type manager. If name is of type "passwd" (as in the case of /etc/passwd), its manager will cause the interface to call the registry server. If, in this case, the call to the registry server fails, the local registry will not be searched. name remains in effect until the next call to setpwfile or the process fails. I don't know how the /etc/group file is being accessed, but the Unix-y routines for the passwd file, and therefore presumably any that operate on the group file, operate BY DEFAULT (no call to setpwfile) by accessing the NCS registry. If this is true for the group file as well, you'd need to insert a call to some "setgroupfile" routine to force it to check out your manually copied-over file's type, and only then would it NOT use the registry services. Hope this helps -- John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 (612) 541-2604 thompson@pan.ssec.honeywell.com My opinions are my own; my facts may not be correct; my heart's in the right place.