Learning a New OS... and Fast!?

Inexile2002 asks: "I've been asked to assist a consultant on a project using VMS and basically have four days to figure out enough that I'm actually of some use. (We're not doing development, just security reviews, so I'm not totally screwed.) Originally I was going to ask for advice on how to start teaching myself VMS from scratch including best books and support websites when I realized that there is a more generic issue here. What are people's thoughts on learning a new OS and learning it fast? Have people found optimal ways to pick things up quickly, get a familiarity with commands and underlying logic? How about learning the basics when you can't actually install and play with the OS in question?"

Comments

As with any project...

[zulux]

...that you need to do in a short amount of time: the best advice I could give is to stay the hell away from Slashdot.

Rule #1

[The Bungi]

Attach yourself like a lamprey to an old fart that knows that stuff and don't let go.

Books will only go so far. Real-world experience is the only thing that counts.

Consultants...

[SoCalChris]

I've been asked to assist a consultant on a project using VMS and basically have four days to figure out enough that I'm actually of some use.

I seriously doubt that you will learn enough in 4 days to be of any use. You will probably slow down the others who do know what they're doing. I would just admit that I didn't know anything about the OS, but would like to work along with the others to learn.

I've always thought consultants were overpaid. This proves it. See this week's Dilbert strip for proof.

Monday
Tuesday
Wednesday
Thursday

Actually...

[Inexile2002]

I'm not going to actually touch a machine. Period. I'm going to be handling physical security and the people side of the policy - ie. What business process are involved in granting or revoking user accounts and how are code changes managed on a process side. That's my job.

I do touch the tech often enough that I'm helping out the VMS guy. Mostly, that'll mean doing his documentation for him when he's done his testing. I just want to be conversant enough that I won't be a time suck while I document everything. As for learning, I find I don't know what to ask the sys admins if I don't know anything about the OS. Even when I know the system, I play dumb... it's just going to be much much easier to play dumb for VMS.

Basically, I could go in to this and not know a thing about VMS and it wouldn't really hurt my ability to do my job. However, that's not the way I like to do things... I handle processes and policies but the more I know about the client...

check the Rosetta Stone

[ubiquitin]

The first place I always look in this circumstance is the Rosetta Stone of Unix aka " What do they call that in this world?" Unfortunately, vax mainframes aren't one of the listed. Read up on the DEC stuff, since they had a similar design philosophy. I remember two things about VMS: prepare to go all caps, and version control is with a semicolon and file version after it for every file. Good luck.

Some information on VMS

[TSTM]

A very good collection of links and information conserning VMS can be found here

The site is very insightful.. and I think it can be read through in a couple of hours. =)

VMS is easy

[NTT]

It seems you asked 2 questions. The first being (seemingly): help me learn VMS in 4 days. The other being about the general opinion of learning a new OS. I figured I throw my hat in to the ring on the first one. (I use OpenVMS at work, and Linux at home; I figure I'm qualified).

VMS is really quite similar to Unix-y OS's. What really flipped the switch for me was the how to pass parameters to the commands in VMS.

This page has helped me the most. In fact I have a print out taped up in my cube for easy reference.
http://www.physnet.uni-hamburg.de/phys net/vms-unix -commands.html
Dont get discouraged by some of the long commands. As long as you have the unique chars it knows what you mean. The command DIRECTORY is shortened to DIR.
Also the man equivelent in VMS is the HELP command. The help docs are complete and very well done.

The other trick to learning VMS fast is to know the directory syntax. Instead of #cd /path/to/this/file.txt it is $set def(ault) [path.to.this]file.txt. Directories are surrounded by [square brackets] with dots "." separating sub-dirs. Also there are probably multiple file systems on several disks; the disk where the OS lives is most likely called DISK$SYSTEM, and the users (aka /home) is prolly on DISK$LOG. You can bounce around from folder to folder without specifying the filesystem, but to move to another fs you have to specify it: SET DEF DISK$SYSTEM:[PATH.TO.THIS]FILE.TXT

On a side note, stay away from the VMS to Linux HOWTO. It has *very* little helpful info, except for the first few pages that show the related Linux commands.

backwards

[Inominate]

We're not doing development, just security reviews, so I'm not totally screwed.)

You've got this backwards. Security requires more indepth knowledge of the OS than development. If they've got you doing security reviews for a system you don't know how to use, I'm sure there are a few hundred script kiddies around who'd love to know who you're doing this for.

Links

[jbolden]

Well I'm reading the links below and one that didn't get mentioned kind of suprised me Open VMS documentation.

Anyway VMS security is nothing like Unix security. Oracle or NT security is much closer to the security model. VMS admins don't tend to modify the base systems very much and VMS is very secure by default. So I wouldn't be looking for Linuxy holes like the equivelent of "sendmail" exploits. The real problem you'll have is finding out which users can elevate privledge, and privledges that in combination can give them a great deal of authority.

In my experience the hole that VMS guys tend to miss is this: Unaudited program gives the author the authority of the user running the program. So if Joe submits changes to the "update accounts file" and update accounts runs as a system operator on the production box then Joe has system operator permissions unless someone is checking his code carefully. Unix guys tend to see this as obvious VMS guys tend to miss this since Joe may not officially even have a log in ont he production box.

And the old VMS farts will tell you...

[devphil]

...that on any decent VMS system,

HELP topic

will start a surprisingly friendly hierarchical help menu on "topic". Or don't specify a topic and just wander around the help tree.

Just as "man man" is a useful command to give to Unix newbies, "HELP HELP" is a good starting point for VMS. My first networked machine was a VMS. When I finally moved to Unix, I was so diappointed in the man pages. "You have to type the whole name of the topic? It can't figure it out? Sheesh..."

Like the tagline goes: VMS is a text-based adventure game. If you win, you get to use Unix.

Re:And the old VMS farts will tell you...

[zeugma-amp]

I'd have to second this guy's recommendation. Several years ago one of my co-workers and I went to what was billed (by DEC) as a beginners VMS class. Once we got to class though, the instructor informed us that the class had been restructured at a intermediate/semi-advanced level. She offered to refund our money or schedule us for another class at a later date. I told her to give us about half an hour and we'd tell her if that would be necessary. The first thing I did was type 'help' (which was how the online documentation was referenced on the MPE systems we were both highly proficient in). After browsing through the help system for a while, and testing out a few simple commands we were able to proceed with the course fairly well.

For a long time I used to think of the various operating systems as different languages that had to be learned in order to make the computers work for you. Over time I've come to the conclusion that they are actually more like dialects of the same language. The most important paradigm (did I really use that word???) to me when working with unfamiliar systems is that on most computers it is demonstratively true that "everything is a file". Learning the equivalent of the 'cd' command and how to view, move, copy, and delete files actually goes a long way towards understanding peculiarities of the given dialect being learned.

With Unix(all flavours), DOS, VMS, MPE, RTE, windows, and several others that don't immediately come to mind, there is a way to use the equivalent of the 'copy' command to simulate the 'cat' or 'type' command to display the contents of a file to your monitor. Knowing how an operating system represents and deals with the various special types of files, i.e., directories, files, programs, and devices, can really help you to get a quick handle on how things are done.

One of the really nice things about VMS IMO is the built-in versioning system. This makes for easy recovery in case of stupid mistakes in deleting/changing files in many circumstances. VMS is a cool OS, but I unfortunately haven't been in a position to spend as much time with it as I'd have liked.

For Clarity's Sake

[Inexile2002]

First off... I will not be touching machines.

Second, by security reviews... I should have been clearer... not securing the boxes on any kind of code or OS level... if the sys admin isn't doing his job I'll never damn well know. I'll be reviewing security policy. Who has authority to sign off on new user accounts? Has this person signed off on new user accounts? What is the process for notifying the sys admin to remove an account? Has everyone who's departed the company had their account deleted? This is the kind of security review I'm responsible for. I also look at who has the ability to actually walk up to the box. I assess adequacy of the security physically getting into the server room.

I'm not totally stupid. If they wanted me to actually touch a keyboard on a machine who's OS I didn't know - I would tell them to find someone else. (Hell, because of the nature of what I do, I'm reluctant to touch the machines I do know.) I try to learn as much as I can before I go in because that is the way I prefer to work.

There are people in my shop who wouldn't know a shell script from a hollywood script and they can do the same job I do and do it competently. I just like to know as much as I can about the system.

And so far the best suggestions have been to read the online stuff and not sleep... already doing that. (Avoiding /. is a good suggestion too frankly, but at 3AM I need a break.)

Free account on a VMS machine

[jpkunst]

is available here:

http://www.thevax.org/.

It's a free service run by hobbyists.

HTH,
JP