CIS 122 Spring 2009 Schedule

Email gregory_porter3@cuesta.edu if you have questions or concerns.

21 Jan

26 Jan

28 Jan

  • Roll
  • We'll try ssh to access your VM's. I'll discuss access, network addresses, ports, firewalls, and why a GUI is not always good or needed.
  • I'll show some home photos - where the VM's are hosted.
  • We're going to try to work our way through some of the labs at labmanual.org. By attempting the install, you've already started Linux Lab Manual 1 and completedLab 1 - Installing Fedora Linux. We going to start on the next one, Lab 2 - Exploring the System, and keep going. We'll see how far we get.
  • You'll need a functioning VM. If you didn't get yours finished, you just added the class, yours is having problems, etc., let me know and we'll fix it.
  • Towards the end of Lab 3, you get introduced to the editor, vi. I found this nice tutorial to vi (and it has Flash movies!).

02 Feb

  • Roll
  • Access. We have more than one way to get to our machines now. We'll discuss what way might work best in what situation. Need to cycle the power? You need to use rdesktop. Doing just regular old command line user stuff? Ssh is the way to go.
  • Why not use root for everything? It's easy to break stuff with root. Everyone should have access to at least 2 accounts on their vm, root, and another they named and made. Practice switching back and forth between the two. You can do root-ish stuff as a normal user if you configure sudo (super-user do). Look at /etc/sudoers, talk about adding your mortal account.
  • We've been talking about using accounts on various machines. It can get a bit confusing. We'll discuss which accounts are on what machine.
  • Getting used to the new Fedora automatic network setting configuration daemon, Network Manager. By default, Network Manager wants to control your network settings. It'll overwrite changes you make to files like /etc/hosts, /etc/resolv.conf, etc. We'll talk some about how to make it behave.
  • While using ssh to access your vm, we'll continue learning and practicing common linux commands. We started last week, but didn't get very far because we still had a lot of network troubles. Finish Lab 2, work on lab 3. If we get through that early I have some additional exercises to reinforce using these commands. Using them repeatedly really is the best way to learn them. More practice with vi.

04 Feb

  • Roll
  • The firewall gods say that our machines are open to ssh. Try to ssh directly to your machine. I'll help with issues. You should only use rdesktop if you need to cycle the power, or if you need the gui.
  • It's important to be able to edit a file from the command line. Almost every Unix flavor known has the vi editor included. I encourage you to learn vi. We'll continue with Lab 3's vi section. Instead of one epic "death by vi session", we'll break it up a bit with lecture.
  • Introduction to the file system. Contrast the DOS way of C: drive and D: drive with the Unix way. Show how file systems "hang" off the root. Introduction to the mount command. Why mount? Mount and umount. Modern desktop Linux distributions will mount and umount removable devices (CD, USB) for you. Peek at /etc/fstab.
  • Break
  • More vi practice. I have a paper handout with more practice.
  • What goes where?. Introduction to the Filesystem Hierarchy Standard. We'll wander about a bit on our systems and see what kind of strange files we can discover.

09 Feb

Although the web site we've used some, http://www.labmanual.org is by the same author and is supposed to accompany our text, the labs there don't follow the structure of the book at times. So to manage where we are headed in the class, I'm going to try to stick with the order of the chapters in the text. If necessary, we'll skip around in http://www.labmanual.org to match the order that topics are presented in the text. I might also write my own labs if I think that would work better. Another good reason we might skip around a bit in http://www.labmanual.org is that in some labs it assumes you have access to a GUI, which we don't (reliably) have in class.

So to summarize, so far we:

  1. Talked some about the history of Linux (Chapter 1 - "Technical Summary of Linux Distributions")
  2. Discussed a bit about BIOS and booting (we needed to do this so we could use our VM's) (Chapter 6 - "Booting and Shutting Down")
  3. Loaded our VM and worked our way through the various issues we had along the way (Chapter 2 - "Installing Linux in a Server Configuration")
  4. Made sure we could log in with ssh, explored the system a bit, learned about man pages (Lab 2, covers parts of Chapter 5 - "The Command Line")
  5. Learned some about, practiced a bit with some common system utilities (Lab 3, covers parts of Chapter 5 - "The Command Line")
  6. Made sure we could edit a file if we had to (end of Lab 3, covers parts of Chapter 5 - "The Command Line")

That means we have covered Chapters 1 and 2, the majority of 5, and a bit of 6. So tonight, I'm going to "get back in sync" with the text, and go back to Chapter 3 - "Managing Software" and pick it up from there. I'll present the topics in the order they are presented in the book. We might use labs at http://www.labmanual.org if suitable, or we might use labs I make.

  • Roll
  • Chapter 3 - "Managing Software". "Red Hat-ish" Linux distributions use the Red Hat Package Manager (RPM) to install and manage software, what is an rpm?. Overview of RPM. RPM hands-on. We'll cover packages, package management, where to get rpms, repositories and mirrors.
  • RPM has some weaknesses, notably that it doesn't handle dependencies well for complex packages. The Yellowdog Updater, Modified (YUM) adds needed functionality to RPM. Overview of YUM. Basic use of YUM. Update machines.
  • Chapter 4 - "Managing Users". We'll discuss making and managing users from the command line.
  • Hands-on with users. Try and finish this in class.

11 Feb

  • Roll
  • (Leftovers from last time.) Demo cracking a password hash and why you want to pick a good password.
  • The network geeks at Cuesta have been working on our rdesktop problem. They may have fixed it. Let's try it out. See if you can use the GUI. Try ctrl+alt+F2 (or F3, F4, etc.) to go to another virtual terminal. Go back to the GUI with ctrl+alt+F1. (Fedora 10 uses F1 for the GUI, most distros use F7...).
  • Chapter 5 - "The Command Line"
    • We've covered a lot of this already, we'll briefly review, and touch on those areas we might have missed. The stuff that follows comes from the beginning of Chapter 5, starting on p 103.
    • A little bit about job control. Foreground/background, jobs. Load the handy utility "screen". Demo screen. Screen's a bit like the ctrl+alt+F2 trick we did (above) but you don't need the GUI.
    • Environment variables. Looking at them, changing them. $PATH and $PS1 are handy ones to know to look at. Changing your prompt.
    • Using pipes, using grep. Piping something through grep is a handy way to find one particular thing in some large output.
    • A little bit about redirection. Redirecting a command's output to a file with >. Tacking something on the end of an existing file with >>.
    • Command line shortcuts. Mention filename expansion again. Tacking multiple commands together with ';'. Using `backticks` to embed one command in another.
  • Chapter 6 - "Booting and Shutting Down".
    • Playing with GRUB. In Fedora 10, GRUB is used but is "hidden". In order to see GRUB in action you need to change /boot/grub/grub.conf. We'll discuss some of the options here.
      • Make a copy of grub.conf (grub.conf.bak or whatever). Get into the habit of always making a copy first before editing a configuration file, especially important config files.
      • Change the line that says: 
        timeout=0
      • to something like longer like 
        timeout=30
    • Now you'll see GRUB-ish stuff at boot time and have a chance to interact with GRUB.
    • Starting on Chapter 6, p 142 - System start up, BIOS POST, BIOS loads GRUB stage 1, stage 1 loads GRUB stage 2, stage 2 loads the kernel, the kernel mounts the root file system, the kernel starts init, the mother of all processes (PID 1), init starts up everything else. We'll see more about this in lab.
    • The book discusses making boot/rescue CD's and floppys. We'll mention it, but not dwell on it.
    • Configuring GRUB. We did that a bit (above) where we made GRUB say hello at boot.
    • The init process, runlevels. The default runlevel in /etc/inittab. rc scripts. Looking at /etc/rc.d/rcX.d. We'll discuss how rc scripts are used.
    • The book has you make your own rc script. We'll mention it, but not dwell on it.
    • Enabling and disabling services. Renaming links in /etc/rc.d/rcX.d is one way of turning off services you don't need. An easier way is to use chkconfig. If you have a GUI, you could use system-config-services.
  • Like I said last time, we're going to pretty much stick to the order topics are presented in the book. We'll do labs at http://labmanual.org if they fit with what we are looking at. In "Linux Lab Manual 2 - Administration", Lab 3 - Boot and Startup processes goes over what we've looked at tonight. We'll work on that a bit.

16 Feb

  • HOLIDAY! Yay!

18 Feb

23 Feb

  • Roll
  • More discussion of Logical Volume Manager. Even if you aren't making some super-duper file server for work, most default installs of Linux use LVM for their disks these days. You need to understand a bit about LVM and why you should care.
  • Hands on with LVM. You're given time to do this in class. You should work on it. Due by next class period. Labs like this are 45% of your grade.
  • So to recap "what's due?" - Hands on with whole disks, Hands on with partitioning disks, and Hands on with LVM are due by 25 Feb. In general, labs are due by the next class session.

25 Feb

  • Roll
  • More discussion of Redundant Arrays of Inexpensive Disks (RAID). Software RAID comes with Linux for free. A lot of motherboards come with RAID controllers. You should think about using some sort of RAID to protect your stuff, even if it's just for home use. Advanced Computer & Network Corporation, a RAID hardware manufacturer has one of the best explanations of RAID I have seen. You need to understand a bit about RAID and why you should care.
  • Hands on with RAID. You're given time to do this in class. You should work on it. Due by next class period. Labs like this are 45% of your grade.

02 and 04 Mar

  • Roll
  • The Business Division (who is responsible for our class) has bought a number of 8 GB flash drives for our use in the labs. This will allow us to install and use Linux locally, without harming the Windows installed on the machines in 3412. You can sign for a drive (and provide personal information that will allow the Business Division to make you return the drive), or you can choose to buy and bring your own. Bring a 8 GB flash drive to class from now on.
  • We'll spend most of these days in lab playing with installing Linux to our flash drives.
    • DON'T HURT THE MACHINES IN 3412! Don't change how they boot, put Linux on their hard drive, change the bootloader, etc. When the next class comes in behind us, they'll quickly realize we "ruined" the machine and complain. Leave it like you found it. Write to the USB drive only.
    • The simplest way to install Linux to a flash drive from Windows is to use the Universal Netboot Installer, UNetbootin. Plug your USB drive in. Download and run UNetbootin. Pick a distro. Pick live or netboot (you should pick live). Hit the "do it" button. Wait for the distro to download (takes a few minutes). Reboot. Stop the boot and choose to boot from USB. Your new Linux install should load from USB.
    • If you want to know what UNetbootin is doing behind the scenes, you could do it by hand. There's quite a few writeups on line on how to install various distros to a USB drive from Windows. Here's one for debian, for example. The basic process is to format the stick, download the Linux image, tweak it a bit, use a Windows version of a Linux data dump tool (dd) to write the image to the USB drive, make the USB drive bootable, and reboot.
  • Our book focuses on Fedora, but does mention Debian and Ubuntu along the way. We've pretty much skipped the Debian and Ubuntu sections so far, since we didn't have access to them. You could install either (maybe Ubuntu would be more fun?) to the USB drive, and fiddle with a Debian-like distro.

09 Mar

  • Roll
  • Talked some about where this class was going, and if sticking to the book was what we wanted. No one brought up any substantial objections.
  • In our never ending quest to get the experience of running Linux on machines (that we aren't allowed to run Linux on) we:
    • Tried a little more to fiddle with the USB drives. The machines in 3412 don't reliably detect that a bootable USB device is present.
    • Tried to install Linux as a VM locally using the provided VMware Player on the machines in 3412. Many problems with that. It's VMware Player. You can't make a VM with it, just run one someone else gave you.
    • Tried to install an alternate tool for running VMs. We tried to install VirtualBox from Sun. Although it installed on a couple of machines, most students got a warning that "you must have administrator rights" and it wouldn't install.
    • At this point we have exhausted most obvious ways to run Linux in 3412. Good thing the friendly folks in the CSC Dept at Cal Poly run some VM's with Linux on them for us, and let us use them. If Cuesta's network supported decent connections for the rdesktop protocol, we could get actually GUI connections. As it is now, we have to put up with character (SSH) conections.

11 Mar

  • Roll
  • Anyway, back to the book. We are on Chapter 8, "Core System Services", p 193.
  • The init upstart daemon. We talked about the init daemon in Chapter 6. Turns out there isn't an init daemon anymore, it's been replaced by the upstart daemon that very closely simulates it (so closely simulates it that you might not notice they switched them...). We'll look at some upstart 'extras' like the commands 'status' and 'initctl'.
  • The /etc/inittab file. We looked at this a bit before in Chapter 6, too. Init Upstart still uses /etc/inittab to specify which runlevel to boot to.
  • Xinetd and Inetd. The book spends a bit of time talking about these two. Actually both are deprecated in later versions of Linux. You can pretty much ignore these. You might want to install some older network based service, and that will require one of these, so you'll have to install them as well. For example, if you were insane and wanted to install a telnet server (yuck, ick), you'd probably have to install xinetd to run it.
  • Logging. Our Fedora systems use rsyslogd. We'll discuss rsyslogd configuration in /etc/rsyslogd.conf. We'll look at common log files in /var/log, like /var/log/messages or /var/log/secure.
    • You can see what's being written to a log file in real time with 'tail -f'. Try 'tail -f /var/log/secure' and then open a second ssh session and intentionally try to log in with a bogus user name and password.
    • You can write to the log file (well, root can) with the 'logger' command. Try ' logger Wowsa! ' and then look at /var/log/messages.
    • The usual problem with log files is that they grow without end. You'll fill your file system full and the machine will get unhappy. To manually truncate a log file, try 'cat /dev/null > log_file_name'. Don't just rm the file, the daemons using the file will get confused.
    • Our systems (and most modern Linuxes) come with with the 'standard' log files set up in a automatic log file rotation. That way they never just get insanely large. We'll look a bit at log file rotation.
  • All that stuff that the kernel dumps at boot time is captured and can be seen with the dmesg command. Sometimes it's handy to look at. There's a lot to look at, you should probably use a pager to read it. For example, 'dmesg | less' will page it for you.
  • Cron. Cron lets you schedule commands to run at certain times. Pretty handy.
  • Try you hand with fiddling with a bit of cron. Use this part of labmanual.org. Here's some little tweaks to that lab:
    • As usual, don't use the console in VIC, you can't cut and paste from it. Use a SSH session. You'll need to copy what you do for lab into an email.
    • Our cron package is named cronie, not vixie-cron.
    • You don't have to use a user named ying. Use one of your own.
    • When you're done with fiddling with cron, copy and paste the text from your SSH session into an email, subject: cron lab and email it to gregory_porter3@cuesta.edu. I should be able to see that you tried various things in the lab from the text you send me.

16 Mar

  • Roll
  • If we continued on our present course in the text, then we'd be heading into Chapter 9, "Compiling the Linux Kernel".
  • It used to be a lot more important, necessary even, to know how to do make your own kernel. If you have a limited amount of RAM, a slow CPU, flaky drivers, etc., then it behooves you to only load the kernel modules (drivers) you actually need. With today's machines with fast CPUs, lots of RAM, decent drivers, etc., it's becoming less important. Most casual Linux users just use the "all in one" kernels that come with their chosen distributions and are perfectly happy with them.
  • So we're going to focus more on *WHAT* a kernel is and why you should care, versus learning the nit-noid details of how to build our own custom kernel. The procedure in the text is valid, though.
  • If it turns out that you really need to make a custom kernel on a later version of Fedora, here's a recent write up.

18 Mar

  • Roll
  • Chapter 10, "Knobs and Dials: proc and SysFS file systems".

23 Mar

  • Roll
  • Chapter 11, "TCP/IP for System Administrators". This is a *BIG* topic area. You could spend a whole semester on nothing but this one chapter. We're going to go over it once over the top lightly. We'll see some (cheesy) videos and flash animations along the way. Tonight we'll talk about ethernet and the 7 layer OSI model.
  • A "must-see" cheesy networking movie is Warriors of the Net. It's actually a pretty good introduction to networking (in a lame-o Tron kind of way).
  • This is a good flash introduction to ethernet.
  • You'll need to memorize the names of the layers of the OSI model. Here's a silly page on mnemonics for this. I like (starting at the bottom, layer 1, the physical layer) "Please Do Not Throw Sausage Pizza Away".
  • Here is a good flash introduction to the OSI model.
  • A clothing based introduction to encapsulation and decapsulation. Unfortunately it doesn't feature bathing suit models.
  • Here's a simple flash quiz on the OSI model. You should be able to get this one right.

25 Mar

(Greg todo: put the link to the lab you handed out here hands on with chap 11)

30 Mar Chapter 12: Network Configuration

01 Apr Chapter 14: Local Security

Yes, this is a bit out of order, but I got confused and prepped the wrong lecture for today (this one).

06 Apr Chapter 13: The Linux Firewall

08 Apr Chapter 15: Network Security

13 Apr Spring Break!

15 Apr Spring Break!

20 Apr Chapter 16: DNS

22 Apr Chapter 17: FTP and Apache web server

27 Apr Chapter 18: Apache and Web projects

  • Your vm can be used a a temporary place to host content. Feel free to be creative. Remember this is a public educational institution, keep it in good taste (no nudity, cussing, hateful images, etc.)
  • Your vm is temporary. Make sure that you have a backup at home. They will be turned off after the semester ends.
  • You need to find something cool you want to host on your vm. Try to find some sort of package to load that has the following features:
    • Interactive - not just static html
    • Customizable - make it look like it belongs to you
    • Useful - does something (somewhat) useful
    • Some administration required - needs some effort to make it work, not just 'yum install <foo>'
  • You can look at my minimal example. Yours probably should be prettier.
  • Like my example shows, you need:
    • The actual thing you made
    • A brief how-to or description of how you made it that others could follow
  • Here's some ideas for things to look at. You don't have to use one of these, but if you need some ideas, here you go:
    • Wikis - MediaWiki, Trac
    • Blogs - WordPress, Pivot
    • Bulletin Boards - PHP-Nuke, PostNuke
  • You'll have 2-5 minutes in an upcoming class period to show us and tell us what you made. You need to be prepared to get up at the front of class, use a browser on the projector, and tell us why you picked what you did, how it worked out for you, and show us what you made.
  • Use class time to find a package, and install it. I will try to help if you want help. This is a lot easier if done in class.

29 Apr Chapter 18: Apache and Web projects

  • Class time to work on web projects
  • One on one help with your project as needed

04 May More on Chapter 18: Apache and Web projects

  • Here is an example project. You can see some of the steps required. Notes on installing MediaWiki.
  • A lot of applications for wikis, blogs, forums, etc., assume that you have all of the packages installed and configured to make them work. In other words, they assume you have a functioning application server (note that there's a lot of commercial packages out there). The most common Linux way to get a working application server is to make sure that you have "LAMP" on it. LAMP is a cute way of saying "Linux, Apache, MySQL, PHP/Perl/Python". Installing LAMP is not just installing the component parts. That's pretty easy with yum ('yum install httpd mysql mysql-server php'). Most of these different components have to be configured to be aware of and play well together. THAT'S the hard part. You have a couple of choices:
  • Install each component with yum and configure them by hand. Fiddle with them until you know they work. In some ways this is the best way, because you know exactly what each one does, and how it interacts with others. Also the longest and most frustrating way to do it. Updateable with yum.
  • Install some yum-my package that has most (or all) of the LAMP components as dependencies, and auto-magically configures most or all of them for you. Easier, faster, but you'll be somewhat clueless how all this stuff actually works. One example of an install like this is the mediawiki package. Here's my load notes for that. The mediawiki package installs all the LAMP components except a database and configures them for you. Updateable with yum.
  • Get some giant LAMP tarball, extract it and use all the LAMP stuff in it. Not based on yum, not updateable with yum. The easiest, but you'll be the most clueless. Dangerous, because you can't update it. I wouldn't do this for production. An example of this is XAMPP.
  • Assuming you have a valid LAMP stack, then you can load a project. Here is an example project, you can see some of the steps required. Notes on installing MediaWiki.
  • Most things like this require a database. Databases require administrators, care and feeding. You need to learn some SQL and database administration. You can take the GUI-boy route and install a database GUI like phpMyAdmin, here's my load notes.

06 May More on Chapter 18: Apache and Web projects

11 More on web projects. So you have a "proof of concept" web site, that maybe relies upon a LAMP driven application, like a wiki, blog or forum engine. Now what? What do you actually have to do to get this hosted somewhere?

  • Register a domain name. Picking a name. Checking availability. Registering the name with a registrar. An example with namecheap.com. Differences between DynDNS and "real" DNS.
  • Finding a hosting company. Different kinds of hosted accounts. Cost. Examples from he.net and dreamhost.com.
  • Backing your temporary site up. Backing up files. Backing up databases. Database exports.
  • Stooping new access to the (soon to be off line) temporary site. Temporary "down for maintenance" warnings.
  • Preparing the new permanent site. Making a blank database, setting permissions.
  • Copying the temporary files to the permanent host. Using secure copy, rsync.
  • Importing a database export. Making sure that the database export matches (same point in time) as the set of files that are copied.
  • Turning on the new permanent site. Function check.
  • Tweaking DNS name records to support Goggle apps for your new domain. Using hosted Google Gmail for the mail system for your new site.

13 May

  • Turn your department issued flash drives in!
  • System Administration as a profession. Go over final. Wrap up, final thoughts.
  • Schedule of presentations for next week: Alphabetically by last name, 5 minutes per person. We'll start with Brenton Carr, end with Eilbron Younan.
  • In your presentation I'll be looking for the following attributes. I'll score you in each area from 1 to 5, with 5 being the best, coolest, most involved. (5 is highest, best).
    • Uniqueness - A new idea, didn't copy some tired old common project on the web.
    • Interactiveness - Not just static html, users are drawn in and want to make changes, click on stuff.
    • Customized - You installed custom graphics, themes fonts, made it look like it belongs to you.
    • Useful - Does something (somewhat) useful, or of interest to others.
    • Some administration required - Needed some effort to make it work, not just 'yum install <foo>'

18 May (Day for finals). You NEED to be present this day. We'll each take 5 minutes and present what we've been working on to the class. You must be prepared to stand up in front of class, use the projector and a browser, and give us a brief demo/overview of your project. Do class survey.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
© 2009 Gregory L. Porter.

Attachments