Table of Contents
Part 3
Entries
Entry 1: November 2nd, 2012
Today, we had a lot of FUN! We started exploring the X Window System! To begin with, we all accessed the “grrasp” terminal. Once in the grrasp terminal, we used a who command to see what other people's grrasp addresses were. Using these addresses, we started sending xeyes all over the place! xeyes is an X Window command which sends a pair of eyes to a screen, which follow the mouse. The eyes can be customized with colors, different sizes, locations, etc.
After a little bit of fun messing around with sending the eyes to each other (although, being on my own machine and not one of the LAIR machines, I was invulnerable to penetrating xeyes. Bwahaha!), we powered up the LAIRwall. With the LAIRwall up, we began sending xeyes to the different machines powering the LAIRwall (6 in total, each machine powering two monitors). Again, we messed around with the commands to customize our xeyes. We also send the xlogo to the screen.
Using the DISPLAY variable, we looked up the size of the display, to create a set of xeyes that would fit the monitors perfectly. I looked up some documentation on the X Window System, which showed me the xclock command. This command sent an analog (or digital, if given the right options) clock to the system. Since this was something with no transparency, I used it for a little bit of trolling fun, by sending it large enough to span an entire system's monitors, covering up any xeyes that were brought up. Evil :) Also, Josh and I made eyes follow Evan. We also found the oneko command, which made a cute little kitty cat. Unfortunately, I couldn't quite bring to fruition my plans to summon a giant pink cat to the LAIRwall :(
All in all, it was a very fun class, in which we learned a lot about the X Window System, including how it works between a client and a server.
Entry 2: November 16th, 2012
First off today, we were given the privilege by Matt of evaluating him. Joy, oh, joy!
Then, we got into the actual learning. Today we continued our talk on networking that we began a few weeks ago. Networking is defined as communication among devices between a common medium using common protocols. Networking involves standards (the way things should be done) and protocols (a set of rules). We then got into talking about the TCP/IP protocol.
The Networking layer mainly handles IP addresses. The main IP protocol is currently IPv4, which are 32 bit addresses (approximately 4.2 billion addresses). There is currently a move to IPv6 (128 bit address, approximately a truckload of addresses), as we are apparently out of IPv4 addresses. After all this chit-chat, we got into some terminal commands. We ran /sbin/ifconfig to view our networking interfaces. We were able to use this to see the Lab46 IP address (10.80.2.38). In order for a network to work, every device must have a unique address.
We then dissected the LAIR's IP address. The 38 in the network address is the unique node number of Lab46 on the network it is on. The 2 in the network address identifies the subnet. The LAIR has 3 separate subnets. The 80 in the network address is the LAIR's unique address, whereas an 81 would be SUNY Geneseo, and 82 would be SUNY IT. And the 10 is the base address (meaning the network address is a Class A address, which gives you full control of the three other fields). Any address starting with 10, 172, or 192 is a private address which isn't accessible directly from the Internet. Any other number would be a publicly accessible address. (CCC owns the publicly accessible address 143.66.xxx.yyy).
Then we talked a little about how IPv6 has been released and devices support it, but everyone is stuck on the IPv4 standard, because change is scary.
The transport layer is basically the UPS guy. It transmits packets from one device to another.
The Application layer is the end level. A web browser is an application layer level service, which uses three common protocols (HTTP, FTP, and HTTPS). The most well known form of data transferred over HTTP is HTML.
Entry 3: November 28th, 2012
Today we mainly had a work day in UNIX. The LAIR received some fresh, recycled machines today, so I decided to grab one for my personal LAIR use. I spent the day downloading and installing Ubuntu on my machine. Since Unity is pretty much garbage, I downloaded the LXDE desktop environment, and spent the rest of the day working on customizing a theme in LXDE, which involved editing a ridiculously awfully formatted XML file. I managed to get my window colors to the correct color, but for some reason my taskbar is being rather obstinate and I can't seem to get it to change its color to the color I want. So, hopefully that gets solved soon!
Entry 4: November 30th, 2012
Yet another day of more work! I spent today first off trying to get a wallpaper image to span both my desktops, which I could not figure out for the life of me. After about an hour of no success, I decided to work on creating a startup script to run the commands I run upon startup. After creating a script which worked, I then found out there was an even easier way to do it! So, that's what I did! And to make things even better, in the process, I got my wallpaper to span both desktops, without even trying. Double win!!
Keywords
unix Keyword 3
Comm
Definition
“comm” is a UNIX command which can be used to compare two sorted files. The input for comm is two files, and the output is two separate columns. The command syntax for comm is
comm [OPTION]... FILE1 FILE2
comm has three main options, -1, -2, and -3.
The -1 option will print the lines present in FILE1 in the left hand column, and all common lines in the right hand column, whereas the -2 option will do the opposite (print lines present in FILE2 on the left, and common lines on the right). The -3 option, however, will only print lines unique to both files, with FILE1's unique lines being on the left, and FILE2's unique lines on the right.
References
- man comm!
unix Keyword 3 Phase 2
Identification of chosen keyword: umask
Definition of umask
The command umask is used to determine file modes at creation. Using umask on a file will determine the permissions of that file and all child processes resulting from that file. umask was used on Super Puzzle Box 2 Turbo (vim setup.exe). Where chmod changes permissions on a file, umask sets the initial permissions. In Super Puzzle Box 2 Turbo (the best Puzzle Box this side of the Danube), when the datafile is created, umask is used to set permissions to (octal) 777, ensuring that permissions will not be an issue when working with the file.
lab46:~$ umask u=rwx,g=,o= lab46:~$ mkdir goop; cd goop lab46:~/goop$ touch trees lab46:~/goop$ mkdir pain lab46:~/goop$ ls -l total 0 drwx------ 2 dsherbur lab46 6 Nov 14 15:19 pain -rw------- 1 dsherbur lab46 0 Nov 14 15:18 trees
Setting the umask values to what would be octal 700, which gives all permissions to the user and owner and no permissions to group or other, I have made private files. Changing umask again changes the permissions of newly created files.
lab46:~$ umask u=rwx,g=rwx,o=rwx lab46:~$ cd goop lab46:~/goop$ ls -l total 0 drwx------ 2 dsherbur lab46 6 Nov 14 15:19 pain -rw------- 1 dsherbur lab46 0 Nov 14 15:18 trees lab46:~/goop$ touch park lab46:~/goop$ ls -l total 0 drwx------ 2 dsherbur lab46 6 Nov 14 15:19 pain -rw-rw-rw- 1 dsherbur lab46 0 Nov 14 15:22 park -rw------- 1 dsherbur lab46 0 Nov 14 15:18 trees
Note the difference in the umask line from the first block to the second block. We can use this to prank people who leave their terminals open by setting the umask vales to 0 across the board, making files that they create themselves unaccessible. However, umask can be changed and the files created under the permissionless umask and be changed via chmod to be accessible.
lab46:~/goop$ umask u=,g=,o= lab46:~/goop$ touch jello touch: setting times of `jello': Permission denied lab46:~/goop$ ls -l total 0 ---------- 1 dsherbur lab46 0 Nov 14 15:26 jello drwx------ 2 dsherbur lab46 6 Nov 14 15:19 pain -rw-rw-rw- 1 dsherbur lab46 0 Nov 14 15:22 park -rw------- 1 dsherbur lab46 0 Nov 14 15:18 trees lab46:~/goop$ vim jello lab46:~/goop$ chmod 777 jello; ls -l total 0 -rwxrwxrwx 1 dsherbur lab46 0 Nov 14 15:26 jello drwx------ 2 dsherbur lab46 6 Nov 14 15:19 pain -rw-rw-rw- 1 dsherbur lab46 0 Nov 14 15:22 park -rw------- 1 dsherbur lab46 0 Nov 14 15:18 trees
When I vim'd jello, i was greeted with a permission denied screen and I was unable to modify or write to the file, verifying the initial permissions of the file.
References
List any sites, books, or sources utilized when researching information on this topic. (Remove any filler text).
- Reference 1
- Reference 2
- Reference 3
unix Keyword 3 Phase 2 Phase 2
umask
Definition
umask is a command in Linux/UNIX systems that can be used to determine a the default permissions granted to any file upon creation of the file.
References
- man umask
Demonstration
For my demonstration, I'll be creating a file, then changing the umask, and creating another file.
The first file was created with the default umask.
lab46:~/umask$ ls -la total 4 drwxr-xr-x 2 smeas lab46 6 Dec 13 16:54 . drwx-----x 28 smeas lab46 4096 Dec 13 16:53 .. lab46:~/umask$ vi test lab46:~/umask$ ls -la total 4 drwxr-xr-x 2 smeas lab46 17 Dec 13 16:57 . drwx-----x 28 smeas lab46 4096 Dec 13 16:57 .. -rw-r--r-- 1 smeas lab46 0 Dec 13 16:57 test lab46:~/umask$
Unlike normally when you chmod a file, the umask settings are the opposite (in chmod, 0 is no permissions, 7 is all permissions). Here is a list of the permissions granted by umask.
Octal value : Permission
0 : read, write and execute
1 : read and write
2 : read and execute
3 : read only
4 : write and execute
5 : write only
6 : execute only
7 : no permissions
I then changed the umask using the command “umask 111” and created a second file. This file was created with read and write permissions for everyone.
lab46:~/umask$ umask 111 lab46:~/umask$ vi test2 lab46:~/umask$ ls -la total 4 drwxr-xr-x 2 smeas lab46 29 Dec 13 17:02 . drwx-----x 28 smeas lab46 4096 Dec 13 17:02 .. -rw-r--r-- 1 smeas lab46 0 Dec 13 16:57 test -rw-rw-rw- 1 smeas lab46 0 Dec 13 17:02 test2 lab46:~/umask$
Experiment 3
Question
Can I set up a startup script to automatically run when I boot my LAIR PC to run the four commands I always run upon startup?
Resources
Matt Haas! Matt told me that using an & at the end of my commands in my startup-script would cause the script to not halt on certain commands.
https://wiki.archlinux.org/index.php/LXDE#Autostart_Programs According to this wiki article, there is an autostart file, in which any command can be placed (preceded by an @ symbol), and it will run upon startup.
Hypothesis
I assume that I'll be able to do this. I know from class that I can create a script file that will run a set of commands, it's just a matter of finding a way to make it automatically execute upon startup.
Experiment
I first plan on writing the script file, and making sure that running the script file will execute all of the actions. Then I plan on making the script file automatically executable upon login so that I don't have to do any work at all when I log in (yay for laziness!)
Data
I created autostart file in ~/.config/lxsession/LXDE and edited it as follows
@pkill lxpanel @xfce4-panel & @xcompmgr & @xrandr --output DVI-1 --auto --left-of DVI-0
This first kills the lxpanel process, then starts the much prettier xfce4-panel. It then executes xcompmgr, which leads to pretty windows. And lastly, the xrandr command switches my monitors from cloning displays, to extend the desktop, with the lefthand monitor (DVI-1) being on the left, and the right monitor (DVI-0) on the right.
This correctly executed the commands, but, for some reason, my wallpaper was not there. I found a program called nitrogen which could be used to set up a background image. I ran nitrogen, with the parameter for the folder my wallpaper was stored in (~/Wallpaper), and selected my background image. I then added the following line to my autostart file.
@nitrogen --restore
After this, I did a quick log in and log out, and everything worked perfectly! I had xfce4-panel running, xcompmgr running, and my desktop extending across both monitors, as well as having the correct background image. Woo, laziness!
Analysis
Based on the data collected, my hypothesis was correct. It ended up being achieved in a completely different way though. My hypothesis was to create a script, and then set it to automatically execute on login. However, I found out in LXDE that there is an autostart file which will automatically run commands. My hypothesis is definitely applicable, as it can be done quite easily, and with no real problems that I can see.
One shortcoming in my experiment is that there may be more that could be done with executing scripts instead of just running commands. But, my script was only going to be used to run commands, so the autostart approach works wonderfully.
Conclusions
In conclusion, I've come to even more of a realization of why I love Linux more than Windows. It's awesome that I can automate so many things that I do, to allow me to be even lazier. And we all know laziness is a good thing! Now I have this beautifully looking desktop running all the time, with a great color scheme, some glorious transparent terminals, and an awesome wallpaper spanning both monitors (X and Zero!)
