Unix 101: Introduction to UNIX (I.E. Unix for Windows Users)
Total Page:16
File Type:pdf, Size:1020Kb
Unix 101: Introduction to UNIX (i.e. Unix for Windows Users) Mark Kegel September 7, 2005 1 Introduction to UNIX (i.e. · solid and basic understanding of unix Unix for Windows Users) ¥ not enough time in the regular school year to teach you this and teach you everything • The cold hard truth else you need to know ¥ and also because the CS department · this course is NOT sponsored by the CS doesn’t have the resources, or want to of- dept. fer this course on its own - maybe they will · you will not receive any credit at all in the future ¥ we needed something to do with our sum- • introduce ourselves to the students mer vacation · Should introduce myself and Marshall ¥ the goodness of our hearts, etc. ¥ are seniors in CS and CS/Math • To make this perfectly clear... • And what do we think we’re doing... · will not teach you to program · will not teach you emacs tricks; will provide · here to teach you fundamentals of Unix a reference sheet · to teach you the student to teach yourself ¥ not about learning to use a single applica- about unix tion · to give you the necessary basics to go out ¥ will not solve world hunger, peace, or to be and teach yourself whatever you might need a better person to know to get work done on unix · catch a fish for a man vs teach a man to 2 Computers on Campus fish · trying to follow Mudd philosophy - teach • Available computing resources you to teach yourself · graphics lab • who this course is targeted at · terminal room - printer · AC and LAC labs - printer and scanner · those students who have never worked with unix before and would to get some experi- · Engineering lab - to be avoided ence doing • Servers · those students who have had some experi- · odin, thuban, banshee ence but would like to learn more · knuth, knuth, wilkes, muddcs, arc, cortana · someone who is lost, confused, and looking ¥ knuth is the one you care about for spiritual enlightenment ¥ main server everyone will be working on - ¥ mashall has a great religion for you to join give specs. - we sin so jesus didn’t die in vain • People to know ¥ ask around, see who has what experience · Tim Buchheim and Roger Wiechman • Some reasons to learn about Unix ¥ Bring them milk, cookies and be nice to · linux and OS X them, they make things work 1 3 Philosophy and History of ¥ about as different as mango, peach, kiwi, straw- UNIX berry ice-cream and peach, strawberry, kiwi, mango ice-cream with bits of vanilla • Origin of Unix ¥ especially that way in linux, its all just annoying ¥ computers were mainframes that people ¥ it doesn’t matter what you run, what we are worked at, much like knuth going to teach you here will apply across most ¥ teletypes - basically a typewriter plugged unixes though not all into a computer • What is Unix? · Ken Thomson implemented the first UNIX environment ¥ unix in some sense is not an operating sys- tem but rather a programming language ¥ had been working at Bell Labs on a project (C)/philosophy/interface (POSIX) called Multics (Multiplexed ...) ¥ the development of C (and the internet) are ¥ Unix was kind of a castrated Multics - much all connected smaller because invented on an underpow- ered system - PDP-7 ¥ unix is (kind of) C, the Standard C Li- brary, and POSIX (Portable Operating Sys- ¥ became popular mainly because it was dis- tem Standard) which is the API that pro- tributed to Universities grammers use to interact with the system ¥ will want to display Unix timeline kernel • Unix Today ¥ the design and implementation of unix also follows a certain philosophy about how ¥ programmers environment - because of this an OS should be designed, how programs is extremely powerful should be written, etc. · still very much a tinkerer’s environment ¥ everything else is just historical baggage · unix encourages and support ”hacking” the ¥ makes unix extremely flexible - can start system from scratch with a new implementation but still same ”design” · Fundamentally multi-user and multitasking ¥ designed in the days of mainframe environ- ¥ what would be some good philosophical ideas to ments when many people would all work on follow when building an OS? one computer system ¥ what are some good rules of thumb? what trade- ¥ we still use the same model in many ways offs do you want to make? with knuth • Unix philosophy ¥ clean, simple interface · programs should be designed to operate to- ¥ Chalkboard exercise gether ¥ unix is also multi-layered in design, mean- · output of one could be used as the in- ing that functionality separated into levels put to another going from the hardware to the user, stuff ¥ text streams -> universal input is also abstracted aways at each layer · Programs are viewed as simple tools that ¥ user | (shell, other programs) | OS(kernel) combined will do complex tasks | hardware · each program should do one thing ex- ¥ at top user at bottom hardware, what’s in- tremely well between? ¥ LEGO blocks - simple tools but can create ¥ scales very well - from supercomputers to very complex systems microwaves (embedded systems) ¥ another analogy - hammer, wrench, saw ¥ two different flavors of unix - BSD (FreeBSD, ¥ Avoid the ginormous programs that do ev- OSX) and System V (Solaris, Linux) erything 2 ¥ Windows has this problem (think of Of- make commands and programs interact fice) with each other, not just from treating ¥ Windows programs also don’t integrate each as a fixed black box. very nicely - no pipeline · Richness of utilities (over 400 standard · want to keep everything as simple as possi- ones) often overwhelms novices. Doc- ble umentation is short on examples and tutorials to help you figure out how to · KISS - keep it simple stupid use the many tools provided to accom- ¥ this applies everywhere - both in OS plish various kinds of tasks.” interaction (system calls and library ¥ ”Unix *is* user-friendly. It’s just picky calls) and in program creation about its friends.” · separate mechanism from policy ¥ very true - have to be able to understand ¥ Unix (and programs that run on Unix) the system at some intuitive level to be able provide a mechanism to do something to work with it but do not lock you down to one policy ¥ also if you don’t like something you can fix ¥ policy - how a program should look and it, maybe not easily, but you can fix it behave ¥ users have to decide on policy ¥ What makes a system secure? What needs to be ¥ games and GUIs are generally a good protected? examples - mods and skins ¥ What is a good way of protecting things, like ¥ walk up to some one and try to scare them property? Ownership · principle of least surprise • Unix security · applications will generally produce no output if successful · concept of ownership - everything on the · applications that fail will make it evi- system is owned by someone dent (sirens if necessary) ¥ ownership implies responsibility - so who- · programs should do the least surprising ever owns these files is in the end responsi- thing ble for them ¥ do not try to feed emacs a stray cat · protect users from one another and from · there is no ”one true way” - unix is not doing dangerous things perfect! · protect privacy -> data ¥ unix has things wrong with it, and · protect work -> programs things that unless you understand will · protect programs and files from users - or cause you a great deal of pain rather allow only certain users to do certain ¥ The Unix Hater’s Handbook - written things to expose the flaws in unix ¥ security: not perfect, can break, and will · from a stanford site: cause you to scream a few months down the http://pangea.stanford.edu/computerinfo/ line unix/overview/advantages.html · ”The traditional command line shell in- terface is user hostile 4 Types of users · designed for the programmer, not the casual user. ¥ what powers is each user going to have? · Commands often have cryptic names ¥ do you need to have a class of users that manage and give very little response to tell the the system? user what they are doing. Much use of special keyboard characters - little ty- ¥ what kinds of users are there going to be? pos have unexpected results. • administrative users · To use Unix well, you need to under- stand some of the main design features. · root - is the best known account of this type Its power comes from knowing how to - aka The SuperUser 3 · complete control over everything on the sys- ¥ for security reasons do not want to have a tem web server running as root · can do anything that they want (mostly) - ¥ what if someone owned your web daemon - has to respect file perms. would own your system...is bad · can become any user on the system ¥ unless you’re setting up your own system ¥ loaded gun with the safety off, easy to shoot don’t have to worry about this yourself in the foot ¥ and even then still don’t really have to · is a standard account on every worry about this since most of these users UNIX/Linux/BSD machine will have been created by default - rarely have to create a new system user · used for system administra- tion/maintenance ¥ now that we have users, how do we manage · what this is will cover later them? ¥ any other user however can be granted ad- ¥ should all users be lumped in to one category? min privileges, so root isn’t strictly neces- sary to run a system • groups ¥ why would you want? what if you tried to ¥ are the unix solution to separating respon- delete all the files on the system? shouldn’t sibilty amoung users be able to do · every user on the system belongs to one or more groups ¥ should there be different types of normal users? is there a better way to organize responsibility? · these are