creating users

View Entire Thread	Return to Threads
SHARE
	by Bill Degnan - 03/21/2016 12:32
Here are the unique values for this server, your server will be different. The user directory is CREATE/DIRECTORY COBK$DATA:[COBK.PERSONAL.USERNAME] /OWNER=[USERNAME] these are group 100 privileges, which is what existing users are set: defprivilege=TMPMBX, OPER, NETMBX privilege = TMPMBX, OPER, NETMBX I created a user HJOHNSON as follows: $ set process/privileges=all $ set default sys$system: $ run authorize UAF> show [100,] /brief UAF> add USERNAMEHERE /uic=[100,30] /account=COBK UAF> modify USERNAMEHERE/password=password UAF> modify USERNAMEHERE /device=COBK$DATA: UAF> modify USERNAMEHERE /directory=[COBK.PERSONAL.USERNAMEHERE] UAF> modify USERNAMEHERE /owner="First Lastname" UAF> modify USERNAMEHERE /nopwdexpir /flag=nodisuser UAF> modify USERNAMEHERE /defprivileges=(TMPMBX, OPER, NETMBX) /privileges=(TMPMBX, OPER, NETMBX) UAF> modify USERNAMEHERE /flags=nodisuser UAF> exit $ create /directory /owner=[100,30] COBK$DATA:[COBK.PERSONAL.USERNAMEHERE] /OWNER=[USERNAMEHERE] when I attempt to log in, the username and password are accepted, but shortly afterwards the system logs the user off "%Sorry, your default device is unavailable for login, Try again later... Thinking that maybe I set something up incorrectly I reset the password of a user already installed in the system. I got the same "Sorry.." message. This tells me that probably the user I created is OK, but something else is not set up correctly system-wide. I triple checked "sam" vs. "hjohnson" I found no differences other than the directory. Hmmmm... Digressing a bit. When I first installed MULTINET, I skipped the step of deleting and installing a new PAK, as described by the MULTINET installation instructions. I was correct in guessing that there was no need to install the license if all I did was delete the program files. I did not know this for sure at the time however and at this point could find no user system reason for the issues. I then incorrectly concluded that the user login problem must be related to an invalid MULTINET license. I was also incorrect in guessing that I could easily re-install the PAK by using the info I collected. I took some screenshots of the LICENSE data thinking after I delete the license I can just re-add the same info again: Here is what I got: Active licenses on node COBUCK: ------- Product ID -------- ---- Rating ----- -- Version -- Product Producer Units Avail Activ Version Date Expires MULTINET TGV 200 F 0 0.0 31-JUL-1997 (none) ...to me that looks like a license, but at this point was not sure what Activ = 0 meant, etc. I saw the other licenses have this value too, for example BASIC..It proved useful to have saved these values, assuming this was all I needed to re-install the license. Unfortunatley I did not realize that a very important piece was missing. The license install program needs a/the checksum* of/for the PAK itself, not just the PAK keys and codes. Running the following command is a BAD decision if you do not have the PAK for a piece of VMS software (unless you're ready for a project): $ @MULTINET:PAK-DELETE And like that I deleted the MULTINET PAK. When I tried to re-add it I did not know the checksum! With no way to complete the license install I abandoned the program. Seemed like everything was still ok for now but I did not realize I had hosed my MULTINET for the next time I rebooted....uh oh! But thinking everything was OK because the license was still in RAM memory and I had MULTINET working....I moved on to try something else. I decided to trace through sys$manager:systartup_v5.com to look at what gets loaded when the system boots up. Maybe there was an instruction, set to block all users except SYSTEM from logging in. I asked around and others independently suggested the same thing. I found a line at the end of the file that I believe disabled logins, so I changed it from 0 to 5 users permitted to log in at a time.... I rebooted to test the startup_v5.com update...BUT ka boom! I never really got to test my changes as I was quickly distracted by a larger problem - Rebooting removed the PAK from RAM, and without the PAK in the license.ldb file, it was unavailable to load into RAM again. I hosed multinet! I undid the startup_v5 changes and sulked.. Reply