Updated: 2015-09-06 01:35 EDT
whoami
groups
ls -la, chown, sudo
rwx
notationchmod
The final exam schedule is posted on the Course Home Page. Your final exam is three hours long, starting at 8am, in T117/119. It will be 180 multiple-choice questions. There will be a set of practice questions, and a quiz on those questions, posted before the exam.
Check the due date for each assignment and put a reminder in your agenda, calendar, and digital assistant.
The worksheets are available in four formats: Open Office (ODT), PDF, HTML, and Text. Only the Open Office format allows you “fill in the blanks” in the worksheet. The PDF format looks good but doesn’t allow you to type into the blanks in the worksheet. The HTML format is crude but useful for quick for viewing online.
Do NOT open the ODT files using any Microsoft products; they will mangle the format and mis-number the questions. Use the free Libre Office or Open Office programs to open these ODT documents. On campus, you can download Libre Office here.
PS1, cd, find, less, ls, man, mkdir, passwd, pwd, rmdir
cat, clear, cp, find, grep, history, less, man, mv, rm, sleep, touch
alias, sum
date, head, nl, tail, tr, wc
vim
vim
vimtutor
program on the CLS.After the power failure on Wednesday, private connections to the Course Linux Server were failing and resetting, and long file transfers (e.g. the hourly backup to my desktop machine) were also failing or terminating in the middle. Connections to the public IP address worked fine. I went on a diagnostic mission. Indeed, long file transfers to the private address would “stall” in the middle, sometimes finishing and sometimes not. Sometimes, trying to connect to the private address gave “connection timed out”. A PuTTY
session to the private address would either not connect or would abort in the middle.
What finally clued me in to the problem was watching a running ping
trace where I saw the TTL
jump from 127
to 63
and then back to 127
again. I ran an nmap
scan of the IP address when it had one TTL
, and then another nmap
scan when it flipped back. Here is the result of that diagnostic, an email message to the IT department:
From: Ian! D. Allen
Subject: duplicate DHCP IP for 10.50.254.149
Date: Thu, 23 Oct 2014 08:45:37 -0400
To: Algonquin College Help Desk
Cc: Todd Kelley, Wenjuan Jiang
There may be a rogue machine using IP 10.50.254.149. The DHCP server at
10.254.21.74 handed this IP to my Linux server, but some other machine
was already using it. The result was intermittent connection failure
to my server, icmp misdirects, and failure of long file transfers.
You can see the result here from two successive nmap requests to the
same IP address. One connects to some probably-Microsoft machine,
and the next nmap a few seconds later connects to my Linux server:
Starting Nmap 5.21 ( http://nmap.org ) at 2014-10-23 08:29 EDT
Nmap scan report for idallen-cls-alg.dyndns.org. (10.50.254.149)
Host is up (0.00025s latency).
Not shown: 994 filtered ports
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpc
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
49153/tcp open unknown
49154/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 5.18 seconds
Starting Nmap 5.21 ( http://nmap.org ) at 2014-10-23 08:30 EDT
Nmap scan report for idallen-cls-alg.dyndns.org. (10.50.254.149)
Host is up (0.00084s latency).
Not shown: 992 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
443/tcp open https
995/tcp open pop3s
2222/tcp filtered unknown
8080/tcp filtered http-proxy
Nmap done: 1 IP address (1 host up) scanned in 1.32 seconds
You can see the same thing when running ping to the IP address; it
switches machines in the middle (the TTL changes):
64 bytes from 10.50.254.149: icmp_seq=42 ttl=126 time=0 ms
64 bytes from 10.50.254.149: icmp_seq=43 ttl=126 time=0 ms
64 bytes from 10.50.254.149: icmp_seq=44 ttl=126 time=0 ms
64 bytes from 10.50.254.149: icmp_seq=45 ttl=62 time=0 ms
64 bytes from 10.50.254.149: icmp_seq=46 ttl=62 time=0 ms
64 bytes from 10.50.254.149: icmp_seq=47 ttl=62 time=0 ms
I've DHCP released that bogus IP address and obtained a new one.
You might find out why the DHCP server gave my machine an IP address
that was already in use, or track down why that machine is using that
IP instead of getting it properly from the DHCP server.
Linux doesn’t have a way to say “don’t ask DHCP for this IP address”, but I know enough about how Linux DHCP
works to know that the previous IP address obtained by DHCP
is cached in the file /var/lib/dhcp/dhclient.eth0.leases
and that Linux will ask for this address again even if you release the IP and re-request a new address via DHCP
. So I shut down the eth0
interface, which released the current IP address, edited the file to cache a different IP address (I picked 10.50.254.160
at random), and then brought up the interface. Linux asked for 10.50.254.160
and the DHCP
server acknowledged that. So now the CLS has its own IP that isn’t in conflict with that other machine at 10.50.254.149
.
This is what sysadmin do.