obrennan@CC3.CC.UMR.EDU (obrennan) (04/09/90)
>password in the file the script creates. Login kept trying to read the >keyboard for the password and not use standard input. The only way I was >able to avoid that is by running the script with /etc/server, but the logins > I'm not sure why this is not working for you. Are you trying to do more beyond simply logging in/out of the account? If so, you will have to place any commands that you want to run during the login in the login redirected input file as well because the end of the file signals logout. If you don't redirect standard output, you will still be prompted even though the login does occur. What version of OS are you running? Maybe that's why we aren't having the same success. >It only seem to be a problem when deleting accounts, and immediately recreating >them after the deletion of the accounts. (And using the same login and uid >when recreating the accounts). > Have you tried placing the registry in maintenance mode, right after the account deletions, to force an queue update from all queues? I tend to do that whenever I have multiple registry operations (again, redirect input to rgy_admin with the file containing SET -H host, STATE -IN_MAINTENANCE, and QUIT) >Have you tested your script under the above condition? The failing command >is something like: > chacl -odfR -u $uname -g $gname -z none $dirname > >The problem might also be related to the fact that the script deletes the group >and not each individual account. (It does delete each individual person.) > Apollo has warned us against deleting the person without deleting the account first, although I must admit I will continue to delete via person until I see reason otherwise. I hope something above can give you more hope. I admit, its a shot in the dark. Let me know if you need more info.... Gerry O'Brennan Computing Services University of Missouri - Rolla ------------------------------ obrennan@apollo.cc.umr.edu c0022@umrvmb.umr.edu ------------------------------ Acknowledge-To: <obrennan@apollo.cc.umr.edu>
acc@caen.engin.umich.edu (John Lauro) (04/09/90)
In article <9004091349.AA05916@cc3.cc.umr.edu> obrennan@CC3.CC.UMR.EDU (obrennan) writes: > > >password in the file the script creates. Login kept trying to read the > >keyboard for the password and not use standard input. The only way I was > >able to avoid that is by running the script with /etc/server, but the logins > > >I'm not sure why this is not working for you. Are you trying to do more beyond >simply logging in/out of the account? If so, you will have to place any commands >that you want to run during the login in the login redirected input file as well >because the end of the file signals logout. > >If you don't redirect standard output, you will still be prompted even though the >login does occur. What version of OS are you running? Maybe that's why we aren't >having the same success. It is reading the userid from standard input, but not the password. I have tried many times... I am using SR 10.2 on a DN10000. Not even a simeple test will work: cat >testlogin mylogin mypassword ^d login <testlogin > >It only seem to be a problem when deleting accounts, and immediately recreating > >them after the deletion of the accounts. (And using the same login and uid > >when recreating the accounts). > > > >Have you tried placing the registry in maintenance mode, right after the account >deletions, to force an queue update from all queues? I tend to do that whenever I >have multiple registry operations (again, redirect input to rgy_admin with the >file containing SET -H host, STATE -IN_MAINTENANCE, and QUIT) Not until a few minutes ago... Still doesn't work. > >Have you tested your script under the above condition? The failing command > >is something like: > > chacl -odfR -u $uname -g $gname -z none $dirname > > > >The problem might also be related to the fact that the script deletes the group > >and not each individual account. (It does delete each individual person.) > > > >Apollo has warned us against deleting the person without deleting the account first, >although I must admit I will continue to delete via person until I see reason otherwise. > Oh, I didn't no that. I just tried manually deleting the accounts before running the uninstall and install scripts but it didn't help... >I hope something above can give you more hope. I admit, its a shot in the dark. >Let me know if you need more info.... Later today or tomorrow I will bring the node down and back up again to get the registry in a "working" state. After that, I will retry putting the registry in maintenance mode after the updating, and manually deleting the accounts before running the uninstall script. John Lauro University of Michigan - Flint
pato@apollo.HP.COM (Joe Pato) (04/10/90)
In article <9004091349.AA05916@cc3.cc.umr.edu>, obrennan@CC3.CC.UMR.EDU (obrennan) writes: |> |> Have you tried placing the registry in maintenance mode, right after the account |> deletions, to force an queue update from all queues? I tend to do that whenever I |> have multiple registry operations (again, redirect input to rgy_admin with the |> file containing SET -H host, STATE -IN_MAINTENANCE, and QUIT) |> You should not need to do this. Putting the registry into maintenance mode simply forces the server to write the VM copy of the database to disk. This will happen periodically anyway. All updates are also written to the database stable storage log so committed transactions won't be lost even if the server crashes before a checkpoint occurs. |> Apollo has warned us against deleting the person without deleting the account first, |> although I must admit I will continue to delete via person until I see reason otherwise. I don't know who at Apollo gave you this advice - but it is not correct. There is no reason for deleting an account before deleting the person object. Apollo recommends that you keep old "person" objects around on the general principle that user-name and userid re-use is a bad idea. Keeping the person object around prevents you from accidentally reusing a unix id or user name. On a related topic John Lauro writes: >It only seem to be a problem when deleting accounts, and immediately recreating >them after the deletion of the accounts. (And using the same login and uid >when recreating the accounts). This problem exists because each machine maintains a cached mapping of unix ids to UIDs and vice versa. This cache is supposed to be refreshed whenever the mapping changes at the server, but the code that does this is broken in sr10-sr10.3 and the refresh operation never occurs. The best way to avoid the problem is to not reuse unix ids. (The cache is thrown away when a machine is rebooted so if you must reuse a set of unix ids you can reboot the client machines to make sure they get the correct mapping). In John's case he is deleting a collection of accounts each semester and then creating a set of new accounts (using the old unix ids). It would be enough for him to reuse a set of unix ids on alternating semesters. (I'm sure that every machine in his network is rebooted at least once a year) It is still safest to just assign a new range of numbers each semester (so that you avoid remebering which set is current) -- Joe Pato Hewlett Packard Company / Apollo Systems Division pato@apollo.com