On Fri, Oct 20, 2017 at 10:15 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
william degnan via vcf-midatlantic writes:
On Fri, Oct 20, 2017 at 9:23 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
william degnan via vcf-midatlantic writes: > > >I noticed when I logged in today a file / info dump printed to the > >screen but when I logged out and in again it was gone. Perhaps that's > >what you're talking about? > > > >Understand that I did not write SYSLOGIN.COM or any of this > >configuration ... I would not have imagined someone would have a messed > >up SYSLOGIN.COM to cause the issue you described. There may be another > >explanation. > > No, that's the only explanation. Poorly written DCL logic and a really > stupid premise too. When somebody logs into VMS, they are granted the > privileges defined in the UAF record. They then execute ALL subsequent > DCL with the persona (privileges, rights, UIC, etc.) defined in the UAF > record. There's no way to elevate privileges via ANY DCL command! The > author of that SYLOGIN seemed to believe otherwise. > > > OK.
I am trying to "take over" from where they guy that set this machine up > >left off and learn how this particular server was set up and why. I > >want to fix, but I also know System administration tends to reflect the > >personality of the admin, people have reasons for things. I am making > >the assumption that given this was a production system there must be > >some reasons for things. Eventually I can try to improve. > > Never make assumptions!!! I have seen more systems in production in my > career that look like they were managed and or configured by brain-dead > chimps. I see people that when told "don't do this" will "do this" and > then, contact me and want their error corrected. I tell them "you did > what I told you not to do" and "don't do it again!" Guess what? They > do it again and again and again. > > That I know, but I am learning a whole new OS and even if it's not the best way it's the way it is now, learning why something is the way it is helps me to learn.
When I log in using Evan's account, I can get in but I have a disk quota > >exceeded error when I try to generate an email message. > > > MAIL> mail To: SMTP%"evan@snarc.net" Subj: VAX USERN/PASS > %MAIL-E-OPENOUT, error opening > COBK$DATA:[COBK.PERSONAL.EKOBLENTZ]MAIL_0128_SEND .TMP; as output > -RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota > exceeded > > The disk that his account has been assign to IS the system disk. If > you look, it's very verly low on disk space. If I were you, I'd move > his account and any other user accounts (save SYSTEM, FIELD, SYSTEST) > OFF OF THE SYSTEM volume. > > I have a new disk I am preparing to use, agreed.
Personally, if you really are hell bent on keeping the system as it was delivered, I'd suggest you backup all the volumes and then, init > and start from stratch. Then, once you know how it all works, you > can go back and see what a mess the prior system's owner(s) left you. >
There is a historic angle here, I get your points though. Logical.
I see now I never set up the disk quota, doing that now. It's all a learning process. One thing about me, I am pretty good to remember once I make a mistake/crash something is sometimes how I learn. So I trash an old VMS box, I can always start from scratch. It's not a job.
I see now that the operator of this box probably was not fully trained, makes it less valuable as a learning tool, why learn on a poorly configured VAX, but I also have nothing to loose. :-)
Bill
2+2 = 5 The earth is flat.
The quotas on this server for all users in [100,*] are 1000000. That seems pretty high. No where else have I seen them that much. Thanks for helping me see the bigger picture. I am operating a hacked box. Bill