If your initrd becomes corrupted, or if you need to add new block device drivers to it, run the mkinitrd command. First, make sure you make a copy of your existing initrd file. Then run the following commands:
$ sudo apt-get install initrd-tools
$ sudo mkinitrd -o /boot/ initrd.img-2.6.20-16-generic
Replace the kernel version in the example above (2.6.20-1.2320.fc5) with your own kernel
version. Alternatively, to use the currently running kernel version, you can use:
$ sudo mkinitrd -o /boot/initrd.img-`uname –r` `uname –r`
Unfortunately, you will often realize that you need to rebuild your initrd after it is too late, as you witness a kernel panic during the root file system mount stage of boot. When that occurs, boot into rescue mode as described in the previous section and run mkinitrd after chrooting to the proper hard disk partition.
LVM volume. As before, unmount the volume before resizing it and run e2fsck (to check the file system) and resize2fs (to resize it to the smaller size):
$ sudo umount /mnt/u1
$ sudo e2fsck -f /dev/vgusb/lvm_u1
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
The filesystem size (according to the superblock) is 16384 blocks
The physical size of the device is 8192 blocks
Pass 1: Checking inodes, blocks, and sizes
/dev/vgusb/lvm_u1: 12/3072 files (8.3% non-continguous,3531/16384 blocks
$ sudo resize2fs /dev/vgusb/lvm_u1 12M Resize file system
resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/vgusb/lvm_u1 to 12288 (1k) blocks.
The filesystem on /dev/vgusb/lvm_u1 is now 12288 blocks long.
$ sudo lvresize --size 12M /dev/vgusb/lvm_u1
\WARNING: Reducing active logical volume to 12.00 MB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lvm_u1? [y/n]: y
Reducing logical volume lvm_u1 to 8.00 MB
Logical volume lvm_u1 successfully resized
$ sudo mount -t ext3 /dev/mapper/vgusb-lvm_u1 /mnt/u1 Remount volume
$ df -m /mnt/u1 See 4MB of 12MB used
Filesystem 1M-blocks Used Available Use% Mounted on
12 4 9 20% /mnt/u1
The newly mounted volume appears now as 12MB instead of 16MB in size.
two files. For example, when upgrading a software package, you may save your old configuration file under a new file name, such as config.old or config.bak, so you preserve your configuration. When that occurs, you can use the diff command to discover which lines differ between your configuration and the new configuration, in order to merge the two. For example:
$ diff config config.old
You can change the output of diff to what is known as unified format. Unified format can be easier to read by human beings. It adds three lines of context before and after each block of changed lines that it reports, and then uses + and - to show the difference between the files. The following set of commands creates a file (f1.txt) containing a sequence of numbers (1–7), creates a file (f2.txt) with one of those numbers changed (using sed), and compares the two files using the diff command:
$ seq 1 7 > f1.txt Send a sequence of numbers to f1.txt
$ cat f1.txt Display contents of f1.txt
$ sed s/4/FOUR/ <> f2.txt Change 4 to FOUR and send to f2.txt
$ diff f1.txt f2.txt
4c4 Shows line 4 was changed in file
$ diff -u f1.txt f2.txt Display unified output of diff
--- f1.txt 2007-09-07 18:26:06.000000000 -0500
+++ f2.txt 2007-09-07 18:26:39.000000000 -0500
@@ -1,7 +1,7 @@
The diff -u output just displayed adds information such as modification dates and times to the regular diff output. The sdiff command can be used to give you yet another view. The sdiff command can merge the output of two files interactively, as shown in the following output:
$ sdiff f1.txt f2.txt
4 | FOUR
Another variation on the diff theme is vimdiff, which opens the two files side by side in Vim and outlines the differences in color. Similarly, gvimdiff opens the two files in gVim. NOTE You need to install the vim-gnome package to run the gvim or gvimdiff program.
The output of diff -u can be fed into the patch command. The patch command takes an old file and a diff file as input and outputs a patched file. Following on the example above, we use the diff command between the two files to generate a patch and then apply the patch to the first file:
$ diff -u f1.txt f2.txt > patchfile.txt
$ patch f1.txt < patchfile.txt
patching file f1.txt
$ cat f1.txt
That is how many OSS developers (including kernel developers) distribute their code patches. The patch and diff commands can also be run on entire directory trees.
If you are familiar with text replacement commands in vi, sed has some similarities.
In the following example, you would replace only the first occurrence per line of francois with
chris. Here, sed takes its input from a pipe, while sending its output to stdout (your screen):
$ cat myfile.txt | sed s/francois/chris/
Adding a g to the end of the substitution line, as in the following command, causes every occurrence of francois to be changed to chris. Also, in the following example, input is directed from the file myfile.txt and output is directed to mynewfile.txt:
$ sed s/francois/chris/g <> mynewfile.txt
The next example replaces the first occurrences of of the text /home/bob to /home2/bob from the /etc/passwd file. (Note that this command does not change that file, but outputs the changed text.) This is useful for the case when user accounts are migrated to a new directory (presumably on a new disk), named with much deliberation, home2. Here, we have to use quotes and backslashes to escape the forward slashes so they are not interpreted as delimiters:
$ sed ‘s/\/home\/bob/\/home2\/bob/g’ < /etc/passwd
Although the forward slash is the sed command’s default delimiter, you can change the delimiter to any other character of your choice. Changing the delimiter can make your life easier when the string contains slashes. For example, the previous command line that contains a path could be replaced with either of the following commands:
$ sed ‘s-/home/bob/-/home2/bob/-’ < /etc/passwd
$ sed ‘sD/home/bob/D/home2/bob/D’ < /etc/passwd
In the first line shown, a dash (-) is used as the delimiter. In the second case, the letter D is the delimiter.
The sed command can run multiple substitutions at once, by preceding each one with -e. Here, in the text streaming from myfile.txt, all occurrences of francois are changed to FRANCOIS and occurrences of chris are changed to CHRIS:
$ sed -e s/francois/FRANCOIS/g -e s/chris/CHRIS/g < myfile.txt
You can use sed to add newline characters to a stream of text. Where Enter appears, press the Enter key. The > on the second line is generated by bash, not typed in.
$ echo aaabccc | sed ‘s/b/\Enter
The trick just shown does not work on the left side of the sed substitution command. When you need to substitute newline characters, it’s easier to use the tr command.
Now that a new repository is set up, you can query for new software you can add:
$ apt-cache search picasa
picasa - Picasa is software that helps you instantly find, edit and share all the pictures on your PC. You can also ask APT to show info about this Picasa package:
$ apt-cache show picasa
Just how much extra software will Picasa require to be updated? Check for dependencies with the following:
$ apt-cache depends picasa
If you are working at the command line with Ubuntu (Feisty Fawn), you may see a locale error messages like one of these while trying to install packag
To disable the universe or muliverse repositories, open the file /etc/apt/sources .list in a text editor and comment out the lines which have multiverse or universe components enabled. You may want to initial the comments to make note of what you commented out, as shown by the
#cn in the following examples:
#cn deb http://us.archive.ubuntu.com/ubuntu/ feisty universe
#cn deb-src http://us.archive.ubuntu.com/ubuntu/ feisty universe
#cn deb http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
#cn deb-src http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
#cn deb http://security.ubuntu.com/ubuntu feisty-security universe
#cn deb-src http://security.ubuntu.com/ubuntu feisty-security universe
#cn deb http://security.ubuntu.com/ubuntu feisty-security multiverse
#cn deb-src http://security.ubuntu.com/ubuntu feisty-security multiverse
Likewise, if you want to add extra repositories that may be offered by individuals or companies, you can do so by adding a line to the /etc/apt/sources.list file. To edit this file, you must have root permissions:
$ sudo vi /etc/apt/sources.list
Insert a line starting with deb (for pre-built packages) or deb-src (for source packages), then the URL for the repository, along with the distribution (such as feisty above), and the component descriptions (universe in the examples). Typically, you'll describe components as contrib for contributed (that is, not from the Ubuntu project) and free or non-free. Normally, you should receive all this information from the site that offers the repository.
If you do add other third-party repositories, be sure to look into the authenticity of the entity offering the software before modifying your Linux system. Although it’s not a big problem with Linux these days, it is easy to add broken or malicious software to your system if you do not exercise care and reasonable caution.
Only use software from well-known sources, and always have a means to verify software you download prior to installing. For more information on software repositories, see the Debian Repository HOWTO (www.debian.org/doc/manuals/repositoryhowto/repository-howto).
An example from the HOWTO document follows:
deb ftp://sunsite.cnlab-switch.ch/mirror/debian/ unstable main contrib non-free
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
locale: Cannot set LC_CTYPE to default locale: No such file or directory
This seems to be a problem related to the installed language settings, or something with internationalized encoding in general. One workaround you can use to keep things satisfied is to export the LC_ALL environment variable and set it the same as your LANG setting.
$ export LC_ALL=”$LANG”
There are several other possible workarounds on the help sites, but this one will be the easiest to undo in case the cure causes more problems than the condition. It should also work regardless of what language you speak. Note that you will have to run this command every time you open a local or ssh shell. You can automate this task by placing the command in your ~/.bashrc file.
You might want to share files with your windows clients. Samba will allow you to do so. First let's install it:
make install clean
Now that its installed add the following line to /etc/rc.conf:
Now we need to create the samba configuration file.
The amount of configuration required for Samba is actually quite minimal. Add the following lines to the new file we just created:
workgroup = MSHOME
passdb backend = tdbsam
[global] marks the beginning of global configuration, and we will simply name our server Samba Server. For our "workgroup," WORKGROUP is the default for Windows NT clients, and MSHOME is used by win9x clients. Nevertheless, feel free to choose any alternative. (Unless you want to serve files to a Windows XP Home client--due to limitations in XP Home that do not exist in XP Pro, a Windows XP Home client can only share files with computers in the workgroup MSHOME). The passdb is used to store passwords for samba users - we will use tdbsam.
At this point you will have to make a decision of whether or not you want anonymous or password based access to your samba server. If you want your server to require password authentification, add the following lines to our smb.conf file:
security = user
path = /big/samba
read only = no
valid users = xaenn
By choosing security level user, users must login in order to access our Samba server. [share] defines our samba share (you may have any number of samba shares, in order to give different access to different users, however, we will simply demonstrate one). The path determines in what directory on your system the share will reside - be sure you have sufficient space depending on what you intend to share with Samba. We want to enable write access, because we will later create one readable and one writable directory. Finally, list the valid users, in this case, only xaenn may login to this share.
If, on the other hand, you want to allow anyone to share files with your server anonymously, add the following lines to smb.conf instead:
security = share
guest account = pcguest
path = /big/samba
read only = no
guest ok = yes
By choosing security level share, users do not need to login in order to access our Samba server. We define the guest account as pcguest. [share] defines our samba share. The path determines in what directory on your system the share will reside - be sure you have sufficient space depending on what you intend to share with Samba. We want to enable write access, because we will later create one readable and one writable directory. Finally, we enable guest access to this share.
Save your changes and exit the file. Now we will setup the directory structure for our share:
mkdir in pub
chown nobody in
chmod 5777 in
Within our /big/samba directory, we created two subdirectories: "in" and "pub". We allow all users to write to in, but we don't allow anyone other than the system root to write to pub - it is our place for sharing files with other users.
Now it's important that the users you added to our Samba configuration actually exist on the system. If you used your own username, then obviously it will already be a user on your system. However, if you decided to use "pcguest" chances are you will need to create this account.
Full name: Guest
Uid (Leave empty for default):
Login group [pcguest]:
Login group is pcguest. Invite pcguest into other groups? :
Login class [default]:
Shell (sh csh tcsh bash zsh rzsh nologin) [sh]: nologin
Home directory [/home/pcguest]:
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]:
Username : pcguest
Full Name : Guest
Uid : 1003
Groups : pcguest
Home : /home/pcguest
Shell : /usr/sbin/nologin
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (pcguest) to the user database.
Now we then have to add this user to Samba (even if you didn't create a new user above, you will have to follow this step for any users in your Samba configuration - xaenn or pcguest, depending on which you used.
pdbedit -a -u pcguest
For pcguest just hit 'Enter' at the prompts for "new password" and "retype new password". (This will leave the password blank, which is what we want for anonymous access). For a normal user choose an appropriate password. You should then see a bunch of statistics about the new user we added.
Now we can start Samba
Or at anytime if you change something in smb.conf and need your new settings to take effect.
Windows users should now have user (login) or anonymous (guest) access to our Samba share, depending on which configuration was used. If you run into problems, you can test your share with the following command:
You can also test your configuration file for errors by typing:
This HowTo does assume the reader has some basic knowledge of ssh and a terminal, and is using an operating system that implements SSH. If you're using a Windows OS and want to use SSH, try PuTTY. For Putty, see key-based auth with Putty.
In the examples that follow please substitute 'servername' , 'ipaddress' and 'username' with the proper information for your setup. I have included a list of weblinks for the words in italic at the end of this document.
Step 1. Verify that you can connect normally (using a password) to the server you intend to setup keys for:
#### Examples ####
user@homebox ~ $ ssh username@'servername'
user@homebox ~ $ ssh username@'ipaddress'
# If your username is the same on both the client ('homebox') and the server ('servername'):
user@homebox ~ $ ssh 'servername'
user@homebox ~ $ ssh 'ipaddress'
# If this is your first time connecting to 'servername' (or 'ipaddress'), upon establishing a connection with the
# server you'll be asked if you want to add the servers fingerprint to the known_hosts file on your computer.
# Press 'enter' to add the fingerprint.
Step 2. Now that you're connected to the server and verified that you have everything you need for access (hopefully), disconnect by typing 'exit' .
#### Examples ####
user@servername ~ $ exit
# You should be back at:
user@homebox ~ $
Step 3. The next step is to copy a unique key generated on your 'homebox' to the server you are connecting too. First, before you generate a new key, check to see if you already have a key:
#### Example ####
user@homebox ~ $ ls -l ~/.ssh
-rwx--xr-x 1 user user 601 Feb 2 01:58 authorized_keys
-rwx--xr-x 1 user user 668 Jan 1 19:26 id_dsa
-rwx--xr-x 1 user user 599 Jan 1 19:26 id_dsa.pub
-rwx--xr-x 1 user user 6257 Feb 2 21:04 known_hosts
# The file we need to copy to the server is named id_dsa.pub. As you can see above, the file needed exists. You may or may not have other files in ~/.ssh as I do. If the key doesn't exist, however, you can make one as follows:
#### Example ####
user@homebox ~ $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): # Press 'enter' here
Enter passphrase (empty for no passphrase): # Press 'enter' here
Enter same passphrase again: # Press 'enter' here
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
# Entering a password when asked during the key generation processes when prompted would require you to enter a password each time you SSH/SCP to the server which defeats the purpose of this document.
Step 4. Regardless whether you had a key ready to go or if you had to generate a new key, the next step is the same in either case. Now you're ready to copy the key to the server. Do so like this:
#### Example ####
user@homebox ~ $ ssh-copy-id -i ~/.ssh/id_dsa.pub user@'servername' (or 'ipaddress')
# If you are asked weather or not you wish to continue, say yes.
Step 5. Now it's time to test the setup. To do that, try to ssh to the server:
#### Example ####
user@homebox ~ $ ssh 'servername' (or 'ipaddress')
# You should log in to the remote host without being asked for a password.
Step 6. You can now SSH or SCP to the remote host without having to enter a password at each connection. To make sure your public key stays secure from prying eyes, do the following to change permissions and restrict access on 'homebox' and also on 'servername' to ~/.ssh:
#### Example ####
user@homebox ~ $ chmod 600 ~/.ssh/id_dsa ~/.ssh/id_dsa.pub
# Verify the permissions on the files:
#### Example ####
user@homebox ~ $ ls -l ~/.ssh
-rw------- 1 user user 668 Feb 4 19:26 id_dsa
-rw------- 1 user user 599 Feb 4 19:26 id_dsa.pub