Welcome to the Cisco Academy for Vision Impaired Linux Wiki. |
Main /
Lecture8Lecture 8We continued to explore the skills necessary to complete our final assignment. For people who keep forgetting how to connect to the shared screen Karry set up on his VPS, that command is The -x tells screen that it's connecting to a multi-user screen, where everyone connected can type or read output in the same terminal window. The avictim is the username who has this session. We are operating as user avictim with all his groups and permissions, and using his home directory. The "student" is simply a handy name given to the screen session. It could have been called aardvark. The slash preceeding "student" tells screen the settings for this particular shared screen are in the avictim's home directory, avictim's root. We are logging in to drongo, the name of Kerry's vps using our own usernames and passwords. We only become avictim when we connect to the shared screen. We're beginning our PMWiki assignment now, and Kerry reminded us that it's a 2-minute job to unpack: tar -xzf pmwiki-2.2.36.tar.gz But for many, the hurdle will be getting it on to the virtual machine. You can find the file in http://www.cucat.org/class_notes/linux_admin/pmwiki-2.2.36.tar.gz or download it from the PMWiki site. You can do this directly on the virtual machine, if you have a console web browser installed, or do it under Windows. Once it's on Windows, you can move it over to the virtual machine with WinSCP. You can also use an ftp client, but you'll need to install an ftp server on the virtual machine, if one is not already there. You can also use wget from the virtual machine. We learned about the command line of scp which uses cp over ssh to securely copy from remote systems. The syntax is to type scp followed by a space. We then type the location of the source file, followed by the destination file. Either the source or destination is a local file. The other parameter is the remote file. So you can copy from local to remote or from remote to local. For local file, you simply specify it as usual for example we type the user name followed by an at sign, followed by the full hostname, followed by a colon, followed by the full path of the directory or file. For example Here's an example of backing up my perl source code to my file server at home, known as sketti Suppose I was logged in to voyager, the college computer, and wanted sls.pl from my file server at home. I'd type Note to the hackers out there: in reality sketti is not attached to the public internet, so this example wouldn't really work. I tested it by typing on two virtual machines. In some of these examples, I've escaped a tilde with backslash. This prevents the local shell from expanding tilde to refer to my local home directory. In other examples, I've written out the entire home directory as in /home/debee/ and either way works. Note that generally when a colon is in a path, Linux realizes you are refering to a remote host. However, I tried these examples with and without a colon and they worked; prompting me of course for a password. Note that though Kerry didn't mention this, the PuTTY program includes a command-line scp for Windows. SCP is part of any ssh installation in Linux. Kerry reminded us that to get the permissions on a directory For example: ls -ld /var/www/dwww shows that root owns dwww. You can use a single period to specify the current directory for the ls -ld command. Back to Scp, we also learned about rsync which has essentially the same syntax, but using a rolling checksum, only copies the differences, thereby keeping two directories in sync. The idea is that by automating rsync, home directories on multiple systems can contain the same thing. We also had further discussions of permissions, especially setting the sticky bit and group ID temporarily so we could edit directories with files we don't own but wish to modify. This is handy for finishing our PM wiki setup, as it is important, for security reasons that a wiki not have files that are owned by root. Be sure to check Understanding Permissions for the full low-down! The command to change the owner of a file or group of them is to make noddy own all the directories and files under incoming. The -R is for recursive. Only the Super User can actually change a file's ownership. We changed the owner of the PMWiki folder and also its group. We also renamed it to wiki. We then moved it to /var/www but Kerry pointed out we could have given it any name and moved it anywhere, made it owned by any user, belonging to any group, provided we set up apache to properly deal with it. /var/www is simply the apache default for pages in Ubuntu. So we could have a /sewing/wiki and that would work just as well, but apache would know that requests to www.sewing.com/wiki needed to go there. The command The 777 sets read write and execute permissions on for users, groups and the world. The PMWiki tarball doesn't contain an index.php; that gets created when the installation instructions are followed, and without the correct permissions it is not going to happen. When the installation steps are complete, and the wiki is up and running, you'd want to change it back to We also reviewed the user and group ID bits and sticky bit again. If we'd instead set the User ID bit with 4, we would have told Linux that any file created in that directory is owned by the user who owns the directory, rather than being owned by the user who created the file. For example, if Joe is in Deb's directory and Joe creates a file without the directory's User ID bit being set, then Joe still owns that file. But if the User ID bit is set, then Deb, the owner of her directory will now own Joe's newly created file. The sticky bit tells Linux that only owners of files can delete them. Kerry demoed with the /tmp directory, which is where big temporary files, owned by many users get stashed. This is a "world-accessible sticky directory" and you can tell because displays the letter t at the end of the permissions string in the 12th column. We clarified the difference between root and SuperUser. The root account is available on some systems but not by default on ubuntu. But the concept of a SuperUser is consistent throughout Linux, regardless of whether an actual root account exists. We also discussed the Umask command, covered in Understanding Permissions. We reconfigured debconf, so the configuration questions will be presented in a speech-friendly format. This is covered in Basic Package Management. We were also reminded that our Regular Expressions homework was due next week and were encouraged to check out:
and/or acquire "Mastering Regular Expressions" from bookshare. |