Website:Sysadmin Survey
From UGCS
(Difference between revisions)
(→The dotted line) |
|||
| (33 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | =UGCS Sysadmin Survey= | |
| + | |||
| + | __NOTOC__ | ||
===What's involved in being a sysadmin?=== | ===What's involved in being a sysadmin?=== | ||
| − | Being a sysadmin means a lot of things. It means answering multitudes of | + | Being a sysadmin means a lot of things. It means answering multitudes of questions from users. It means finding and installing nifty new software, and keeping the existing software working. It means keeping the lab's hardware working reasonably well as well as keeping the lab nice and neat. It means dealing with obscure problems that you might otherwise just ignore. It means being on call 24 hours a day to deal with minor and major emergencies. In general, it means spending a lot of time keeping the lab a productive and fun place to get things done. |
| − | questions from users. It means finding and installing nifty new software, | + | |
| − | and keeping the existing software working. It means keeping the lab's | + | |
| − | hardware working reasonably well as well as keeping the lab nice and neat. It means dealing with obscure problems that | + | |
| − | you might otherwise just ignore. It means being on | + | |
| − | call 24 hours a day to deal with minor and major emergencies. In general, | + | |
| − | it means spending a lot of time keeping the lab a productive and fun place | + | |
| − | to get things done. | + | |
===What's the incentive?=== | ===What's the incentive?=== | ||
| − | As a sysadmin, you will learn the gory details of UNIX systems inside and | + | As a sysadmin, you will learn the gory details of UNIX systems inside and out, and you will gain a lot of experience in dealing with machines and people which may be helpful in later life. If you're the type of person we're looking for, noodling around on computers will be its own reward. You'll become a well-known person among the undergrad community and the CS department. And you'll also experience the personal satisfaction of making UGCS a better place in which to compute. |
| − | out, and you will gain a lot of experience in dealing with machines and | + | |
| − | people which may be helpful in later life. If you're the type of person | + | |
| − | we're looking for, noodling around on computers will be its own reward. | + | |
| − | You'll become a well-known person among the undergrad community and the CS | + | |
| − | department. And you'll also experience the personal satisfaction of making | + | |
| − | UGCS a better place in which to compute. | + | |
===How much time?=== | ===How much time?=== | ||
| − | There are no fixed hours. When the lab crashes, we have to fix it, but | + | There are no fixed hours. When the lab crashes, we have to fix it, but otherwise we set our own schedule. You can work when you have the time, and let other people handle things when you don't. |
| − | otherwise we set our own schedule. You can work when you have the time, | + | |
| − | and let other people handle things when you don't. | + | |
| − | Students have run this lab for | + | Students have run this lab for twenty years while holding regular class schedules. It can be stressful at times, but it's quite manageable. It is possible to keep this job over the summer while also working at something else at or very near Tech (like a SURF), but you have to be willing to spend a reasonable amount of time here. Generally, though, more important than the actual number of hours that you spend is your dedication to the job. |
| − | schedules. It can be stressful at times | + | |
| − | manageable. It is possible to keep this job over the summer while also | + | |
| − | working at something else at or very near Tech (like a SURF), but you have | + | |
| − | to be willing to spend a reasonable amount of time here. Generally, | + | |
| − | though, more important than the actual number of hours that you spend is | + | |
| − | your dedication to the job. | + | |
===The dotted line=== | ===The dotted line=== | ||
| − | + | There have traditionally been between two and four sysadmins at any time. Since we are looking for people who will be able to remain sysadmins, we prefer sophomores and (especially) freshmen, but encourage everyone interested to apply. Previous experience in system administration is helpful but not at all necessary; more important is a desire to learn and the ability to deal with people. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | There | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Since we are looking for people who will be able to | + | |
| − | sophomores and (especially) freshmen, but encourage everyone interested | + | |
| − | to apply. Previous experience in system administration is helpful but | + | |
| − | not at all necessary; more important is a desire to learn and the ability | + | |
| − | to deal with people. | + | |
===In case of emergency... break glass...=== | ===In case of emergency... break glass...=== | ||
| Line 64: | Line 26: | ||
of us seem surlier than others, we're all fine sysadmins. | of us seem surlier than others, we're all fine sysadmins. | ||
| − | |||
===Let the games begin!=== | ===Let the games begin!=== | ||
#Name: | #Name: | ||
| − | |||
#Email address: | #Email address: | ||
| − | |||
#Class (Fr, So, Jr, Sr, S^n Sr): | #Class (Fr, So, Jr, Sr, S^n Sr): | ||
| − | |||
#Option (you don't have to be CS!): | #Option (you don't have to be CS!): | ||
| − | + | #What computing hardware, operating systems and software have you worked with, and what have you used them for? | |
| − | #What computing hardware, operating systems and software have you worked | + | #What programming languages/scripting languages do you know? How well? Of the ones you know, which do you like best and least? |
| − | + | #Describe one or two of your favorite programming projects (done for a class, for a job, on your own -- it doesn't matter). | |
| − | + | #What do you find to be the most interesting aspects of computing? When you "play around" with computers, what sort of things do you do? | |
| − | #What programming languages/scripting languages do you know? How well? | + | #Have you had any experience with system administration? What sort of work did you do (was it mangling an enterprise-wide gigabit-capacity network for a Fortune 500 company, or was it dusting off Apple II monitors in high school)? Have you done anything particularly interesting? |
| − | + | #Have you worked with Unix-like systems at all? Have you ever set one up? (Yes, Linux counts.) | |
| − | + | ||
| − | #Describe one or two of your favorite programming projects (done for a | + | |
| − | + | ||
| − | + | ||
| − | #What do you find to be the most interesting aspects of computing? When | + | |
| − | + | ||
| − | + | ||
| − | #Have you had any experience with system administration? What sort of | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | #Have you worked with Unix-like systems at all? Have you ever set | + | |
| − | + | ||
| − | + | ||
#What is your biggest gripe about Unix? What would you change? | #What is your biggest gripe about Unix? What would you change? | ||
| − | |||
#Emacs or vi? | #Emacs or vi? | ||
| − | |||
#What's the most difficult computer-related problem you've solved? | #What's the most difficult computer-related problem you've solved? | ||
| − | |||
#Why do you want to be a UGCS system administrator? | #Why do you want to be a UGCS system administrator? | ||
| + | #Is there anything else we should know? Be creative. Lie, if necessary. | ||
| − | |||
| − | |||
| + | Answer as many of the following questions as you can. Give as much detail as you can. You can ask people for help on any particular concept, but you can't have people answer the questions for you. Feel free to look at any documentation or source that you want. Don't worry if you don't know or can't figure out the answers - we're much more interested in your thought process than anything else. But remember: the more challenging problems you answer, the more chance you have to impress us. Please remember to cite your sources! Geez, sounds like a final, eh? | ||
| + | Remember, don't worry if you can't figure out all of the questions- some of these questions are tricky. As we said before, we are more interested in your thought processes and reasoning than we are in the technicalities of your answer. | ||
| − | + | ====General UNIX==== | |
| − | + | # What is NFS? What problems does it have? How can these problems be solved? | |
| − | + | # What is AFS? How does it differ from NFS? We're not looking for a detailed, comprehensive answer- we're just looking for a general overview and brief discussion. See http://www.openafs.org, specifically the User's Guide, for more information. | |
| − | + | # Does Kerberos have something like SSH keys? If it doesn't, what would it take to give Kerberos something like them? Is this desirable? ( We suggest you read [http://www.oliebol.org/Security%20Docs/moron%20guide%20to%20kerberos%20brian_security_kerberos.pdf The Moron's Guide to Kerberos]) | |
| − | + | # UGCS has a cluster of similar machines. Sometimes we may want to take some of them down for maintenance. To minimize disruption to our users, it'd be nice to be able to migrate their processes off of a machine and on to another machine. Is this possible with the standard Linux kernel? What steps would you have to do to freeze a currently running process, send it to another machine, and then thaw it? | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === | + | |
| − | + | ||
| − | + | ||
| − | # | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | ====Resource Usage==== | ||
| + | # Suppose the mail server at UGCS has a load average of 100. Is this ok? Why or why not? (Big Hint: We have networked filesystems) | ||
| + | # Suppose the web server on UGCS is locking up every 10 minutes. What could be going wrong? List a couple of possible scenarios. How would you fix it? Could you do it remotely? | ||
===Hypothetical questions=== | ===Hypothetical questions=== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ====Troubleshooting==== | |
| − | + | One of the biggest issues that the UGCS sysadmins face is dealing with machines when they stop working. Let's say you ssh to "to.ugcs.caltech.edu" and it hangs. What might be wrong? | |
| − | + | Later on, you ssh to "to.ugcs.caltech.edu" and it keeps rejecting your password. What could be wrong? | |
| − | + | ||
| − | + | ||
| − | + | For each scenario, list as many possible issues as you can think of and how you would distinguish between them. | |
| − | + | ||
| − | + | ====Security==== | |
| − | + | If you were a cracker or a miscreant trying to make the lives of the UGCS sysadmins utterly miserable, what sorts of things could you do? You may assume that they have access to a UGCS account. In a similar vein, what are some of the biggest security vulnerabilities in a Unix-like system? Suggest ways (policies, background processes, etc.) to circumvent these security problems. | |
| − | + | ||
Latest revision as of 01:49, 20 December 2010
UGCS Sysadmin Survey
What's involved in being a sysadmin?
Being a sysadmin means a lot of things. It means answering multitudes of questions from users. It means finding and installing nifty new software, and keeping the existing software working. It means keeping the lab's hardware working reasonably well as well as keeping the lab nice and neat. It means dealing with obscure problems that you might otherwise just ignore. It means being on call 24 hours a day to deal with minor and major emergencies. In general, it means spending a lot of time keeping the lab a productive and fun place to get things done.
What's the incentive?
As a sysadmin, you will learn the gory details of UNIX systems inside and out, and you will gain a lot of experience in dealing with machines and people which may be helpful in later life. If you're the type of person we're looking for, noodling around on computers will be its own reward. You'll become a well-known person among the undergrad community and the CS department. And you'll also experience the personal satisfaction of making UGCS a better place in which to compute.
How much time?
There are no fixed hours. When the lab crashes, we have to fix it, but otherwise we set our own schedule. You can work when you have the time, and let other people handle things when you don't.
Students have run this lab for twenty years while holding regular class schedules. It can be stressful at times, but it's quite manageable. It is possible to keep this job over the summer while also working at something else at or very near Tech (like a SURF), but you have to be willing to spend a reasonable amount of time here. Generally, though, more important than the actual number of hours that you spend is your dedication to the job.
The dotted line
There have traditionally been between two and four sysadmins at any time. Since we are looking for people who will be able to remain sysadmins, we prefer sophomores and (especially) freshmen, but encourage everyone interested to apply. Previous experience in system administration is helpful but not at all necessary; more important is a desire to learn and the ability to deal with people.
In case of emergency... break glass...
Oh, and if you have any questions, contact one of us below. Although some of us seem surlier than others, we're all fine sysadmins.
Let the games begin!
- Name:
- Email address:
- Class (Fr, So, Jr, Sr, S^n Sr):
- Option (you don't have to be CS!):
- What computing hardware, operating systems and software have you worked with, and what have you used them for?
- What programming languages/scripting languages do you know? How well? Of the ones you know, which do you like best and least?
- Describe one or two of your favorite programming projects (done for a class, for a job, on your own -- it doesn't matter).
- What do you find to be the most interesting aspects of computing? When you "play around" with computers, what sort of things do you do?
- Have you had any experience with system administration? What sort of work did you do (was it mangling an enterprise-wide gigabit-capacity network for a Fortune 500 company, or was it dusting off Apple II monitors in high school)? Have you done anything particularly interesting?
- Have you worked with Unix-like systems at all? Have you ever set one up? (Yes, Linux counts.)
- What is your biggest gripe about Unix? What would you change?
- Emacs or vi?
- What's the most difficult computer-related problem you've solved?
- Why do you want to be a UGCS system administrator?
- Is there anything else we should know? Be creative. Lie, if necessary.
Answer as many of the following questions as you can. Give as much detail as you can. You can ask people for help on any particular concept, but you can't have people answer the questions for you. Feel free to look at any documentation or source that you want. Don't worry if you don't know or can't figure out the answers - we're much more interested in your thought process than anything else. But remember: the more challenging problems you answer, the more chance you have to impress us. Please remember to cite your sources! Geez, sounds like a final, eh?
Remember, don't worry if you can't figure out all of the questions- some of these questions are tricky. As we said before, we are more interested in your thought processes and reasoning than we are in the technicalities of your answer.
General UNIX
- What is NFS? What problems does it have? How can these problems be solved?
- What is AFS? How does it differ from NFS? We're not looking for a detailed, comprehensive answer- we're just looking for a general overview and brief discussion. See http://www.openafs.org, specifically the User's Guide, for more information.
- Does Kerberos have something like SSH keys? If it doesn't, what would it take to give Kerberos something like them? Is this desirable? ( We suggest you read The Moron's Guide to Kerberos)
- UGCS has a cluster of similar machines. Sometimes we may want to take some of them down for maintenance. To minimize disruption to our users, it'd be nice to be able to migrate their processes off of a machine and on to another machine. Is this possible with the standard Linux kernel? What steps would you have to do to freeze a currently running process, send it to another machine, and then thaw it?
Resource Usage
- Suppose the mail server at UGCS has a load average of 100. Is this ok? Why or why not? (Big Hint: We have networked filesystems)
- Suppose the web server on UGCS is locking up every 10 minutes. What could be going wrong? List a couple of possible scenarios. How would you fix it? Could you do it remotely?
Hypothetical questions
Troubleshooting
One of the biggest issues that the UGCS sysadmins face is dealing with machines when they stop working. Let's say you ssh to "to.ugcs.caltech.edu" and it hangs. What might be wrong?
Later on, you ssh to "to.ugcs.caltech.edu" and it keeps rejecting your password. What could be wrong?
For each scenario, list as many possible issues as you can think of and how you would distinguish between them.
Security
If you were a cracker or a miscreant trying to make the lives of the UGCS sysadmins utterly miserable, what sorts of things could you do? You may assume that they have access to a UGCS account. In a similar vein, what are some of the biggest security vulnerabilities in a Unix-like system? Suggest ways (policies, background processes, etc.) to circumvent these security problems.
