very inspired from Hehe2

1-Never Login Using ‘root’

If there was one habit that one should strictly abide by, it’s probably this one. Most of us come from a Windows background, and we have the notion that more power is better, so we login using our administrator accounts. Well let me tell you my friend, that this is a major reason that Windows is plagued with viruses and insecurities, half the world is currently running ‘root’ accounts!

With great power comes great responsibility, and with ‘root’ powers you should be aware of the consequences of EVERYTHING you’re doing, and even then, mistakes happen. I remember my beginnings with SUSE Linux, there were lot of administrative tasks I needed to do but had no idea how to go about them without the GUI, so I so innocently log out and login onto the ‘root‘ GUI. The default wallpaper of the ‘root‘ GUI on SUSE were lit fuse bombs tiled beside each other. Back then, the symbolism totally flew over my head, coming from a Windows background, I wasn’t really doing anything wrong.

But what are the dangers of logging in as root?

1. Well imagine you’re on the trapeze without a safety net, frightening isn’t it? Well that’s effectively what you are doing when you login as root, you can inadvertently hose your whole system
2. You are at the risk of running malware. Any program that is started under root mode will automatically be given root privileges
3. If there is a common security hole that hasn’t been patched yet, you could be totally “pwned”
4. It’s common Unix convention, never run anything in root mode unless absolutely necessary. If a non-admin program asks for root access, you should be suspicious

Generally, instead of logging onto your root GUI, use any of the following techniques:

• Use “sudo” or “su” , and kill the session when your done
• If you don’t know how to do it in the command line, use “gksu” or “kdesu”. For example, press alt+f2 and type “gksu nautilus“. Close the app as soon as you finish

2-Properly Name Your Files

In a Linux environment, you can name your files whatever you want except for, 1) the forward slash “/” which is reserved for the root directory, and 2) a null character. Anything else is technically acceptable, however there are some best practices that you should abide by in order to avoid any future complications:

• As a rule of thumb, only use alphanumeric characters, hyphens, periods, and underscores
• Avoid special symbols like dollar signs, brackets, and percentages. These symbols have special meanings to the shell, and could cause conflicts
• Avoid using spaces, handling files with spaces in the terminal is kind of awkward. Replace spaces with either hyphens or underscores

I personally have grown into this habit, I find myself following these guidelines even in a Windows or Mac environment.

3-Place /home on a Different Partition

Doing this gives you extreme flexibility, a kind that you never imagined before. Having /home in a separate partition enables you to reinstall your system or even change your whole distro without loosing your data and personal settings. Just keep the “/home” partition intact and reinstall whatever you want on your “/”. Now you can try out distros as much as you want, without worrying about your data and personal settings, they go with you on the go .

If you weren’t lucky enough to know this before installing your system, then do not despair! Carthik from Ubuntu Blog takes you in a step-by-step guide titled “Move /home to it’s own partition“

4-Proper Crash Management

Linux is very robust and stable, however every system can come down to it’s knees every once in a while. Before you head to CTRL-ALT-DEL, the restart button, or the plug, you should know how to properly handle any crash. As opposed to another un-named operating system, you should be able to easily recover your system without actually restarting! I personally go through different levels, if one doesn’t work I elevate it to next step:

1. I have the “force quit” applet on my taskbar, if any app starts to act up just click on the “force quit” icon and then kill the app
2. If that doesn’t work, draw up a terminal and type “ps -A” , and take note of the Process ID (PID) of the culprit app, then kill it. “kill PID”
3. Use the “killall” command, for example, “killall firefox-bin”
4. If your whole GUI is frozen, and drawing up a terminal is impossible, then press CTRL-ALT-F1, this will take you to another terminal, and virtually a whole new session. From there kill the culprit app using step 2 and 3.
5. If that doesn’t work, you might want to restart your GUI using the CTRL-ALT-Backspace combo. Beware, that this will kill all your GUI apps currently running
6. Invoke CTRL-ALT-F1 and do CTRL+ALT+DEL from here. This will not instantly reset your system, merely perform a standard reboot, it’s safe. (Assuming you want to restart and CTLR-ALT-F1 works)
7. Finally if nothing works, don’t rush to the hard reset button, try to Raise a Skinny Elephant

5-Play The Field

You were probably recruited to your current distro by a friend, it suited you, and stuck with it. That’s great, but there is probably something better for you out there. Why not harness the flexibility and richness of Linux and Open Source? Don’t be afraid to experiment around with different distros, apps, window managers, and desktops. Experiment until you find the best fit. Think of it this way, if you are currently living in the best place on earth for you, traveling around the world wouldn’t really harm right? In fact you might find a better place to live in, but if you didn’t, the time you spent traveling would not have gone to waste, you would have learned a lot about other countries, other people and traditions, different ways of thinking, and ultimately had fun!
Every new thing you try out will contribute to your incremental learning, in a year’s time you will have a good grasp on Linux and the Open Source world. I personally tried out at least 10 distros, 4 desktops, and 5 window managers. My recent article Etymology of A Distro got me interested in a couple more distros such as Zenwalk, Foresight, and Sabayon. Play the field, my friend, it will do you good.

But before you proceed, pay heed to these few hints:

• Set up your perfect system that you feel comfortable with, you need a workable system 24/7 right? Then test around using one of the below points
• Harness the power of virtualization! Install Vmware or Virtualbox. Use them to test out the distros
• Alternatively, if you are not big on virtualization, you can set up a separate partition to test new distros. A partition that you couldn’t care less about
• Ultimately, you can have a main PC and a test one. Wreak havoc on the test one

6-Nurture Your CLI Adoption

Now I am not going to advocate learning the command line, there are numerous articles that emphasise on it’s importance. What I am assuming here is that you already know it’s importance, and have a rudimentary understanding on how to do some simple administrative tasks. You are already hacking away, tweaking and configuring, following the different guides and howtos scattered all over the tubes, but don’t just copy and paste!! Meaning, instead of just headlessly executing commands some random guy half way across the world told you to execute, try to understand what every command does. Why did the guide as you to do this, as opposed to something else? Understand the rationale of the steps you are asked to do. These commands are highly relevant to you, and will help you gain a better understanding than any 101 guide.

After a while you will notice that you have amassed a good deal of CLI lore.
At the end of the day it’s just a pseudo-language! Every command is probably just an acronym of something, or a cut down version of a real word. You expect your dog to understand “Spike fetch ball” so why don’t you expect to understand “sudo mv /file1 /file2″?

7-Always Be Ready to Unleash The Power Within

Personally, I had numerous occasions when a friend asked me to do something on his/her computer, but found myself crippled because of his/her choice of OS. At other times I wanted to do something urgently but the only computer had another crippled OS. Spare yourself the agony, have Linux with you all the time, whether it’s on a USB pendrive, a live CD, or even a live CD business card ! There are dozens of good Linuces out there that are perfect for on-the-go computing. Knoppix, DSL, and Puppy Linux are just a few examples.

Popularity: 7% [?]

By Andrew Hudson and Paul Hudson

Xen is a powerful new virtualization system that enables you to run multiple operating systems on one computer. Here’s how you can install it on your Fedora machine, and how to get it configured to best suit your environment.

This article is excerpted from the book Fedora 7 Unleashed by Andrew Hudson and Paul Hudson, SAMS Publishing, August 2007.

Virtualization versus paravirtualization

When you create a new VM, it is allocated a chunk of RAM all to itself, and lives completely self-contained from the outside world. VMware even has a virtual BIOS to complete the illusion. If your VM wants to communicate to other VMs on the same computer, it has to do so over a TCP/IP network connection, just like any other machine. In fact, when you install an operating system on a virtual machine, it cannot even tell that it is a virtual machine because it looks identical to raw hardware.

The problem with this type of virtualization is that it is very slow. For example, the VM has to access hardware frequently (to save files, show a display, and so on), but of course it cannot access the hardware directly because doing so would interfere with other VMs. Instead, its requests have to be translated and rerouted to the host operating system, where they are handled. Similarly, if the VM tries to execute any special CPU instructions that would reveal that the VM is actually a virtual machine, the host OS has to stop those instructions and fake the answer so that the VM is not any wiser (a technique known as binary patching).

The solution is to move from virtualization to paravirtualization — the technique that Xen uses. Linux is open source, so the Xen developers modified the Linux source code so that Linux becomes aware of its existence as a virtual machine. When the virtual Linux needs access to the hardware, it just asks Xen for permission. The difference is huge: You can expect a normal VM to run at about 50% of the speed of a native machine, whereas a Xen virtual machine can run up to about 95%, simply by removing the need for binary patching and other virtual hacks.

The downside to Xen is that the source code has to be patched, which rules out closed-source operating systems. VMware runs Windows XP on Linux out of the box, but Xen cannot. That said, the new chips from Intel and AMD include virtualization on hardware, which enables Xen to run unmodified Windows at full speed on top of Linux. Without this technology, Xen can use only a modified, open source distribution, such as Linux, NetBSD, or FreeBSD.

How Xen works

Xen is actually a very small operating system that has the sole goal of managing the resources of virtual machines. On top of the Xen OS runs what would previously have been called the host OS — the main operating system for the machine. Unlike VMware, the host OS (known as domain 0 or just dom0 in Xen terminology) is a virtual machine, but has special privileges assigned to it so that it is more responsive.

The domain 0 VM is where you control Xen, and where you start other guest VMs — known as unprivileged domains or domU. You can start as many as you want, with the only real limit being the amount of RAM in your machine. Because the domU OS is fully aware of its status as a Xen virtual machine, Xen lets you change the amount of RAM in a VM while it’s running, with the exception that you can’t go above the initial allocation of RAM.

Fedora Linux specifies a minimum system requirement of 256MB RAM, which means that if you are to run Fedora on top of Fedora, you need at least 512MB RAM. Keeping in mind that Xen uses a very small amount of RAM for itself, you should ideally have at least 768MB of RAM to be able to run two operating systems side by side at full speed.

Note that if you have tried Xen on old versions of Fedora, you no longer need to disable SELinux to get Xen to work.

Installing Xen

The first step is to convert your current OS to a virtualized guest OS. This is actually a very easy thing to do because, as discussed, domain 0 has special privileges — such as the capability to access hardware directly. As a result, you do not have to reformat your machine: dom0 reads straight from the disk, uses the graphics card, uses the sound card, and so on.

To get started, go to Applications -> Add/Remove Software. From the window that appears, choose List view, and then select the following packages: kernel-xen, vnc, and xen. The kernel-xen package provides a Linux kernel that is configured to run on top of Xen without any special privileges, as well as a Linux kernel designed to be used as dom0 so it can access hardware directly. The vnc package is there to make VM management much easier. Finally, the xen package gives you all the tools you need to create and manage virtual machines. Along with these packages, there are several other dependencies that Fedora will automatically resolve for you, so just go ahead and install all the packages.

Because you have installed two new kernels, Fedora updates your GRUB boot configuration to make them bootable, but leaves your original, non-Xen kernel as the default. Switch to root and bring up /boot/grub/grub.conf in your favorite text editor. Look for the line "default=2" and change it to read "default=0". This might vary on your machine — set it to the position of the Xen hypervisor kernel in the grub.conf file, remembering that Grub counts from 0 rather than 1. That is, the first OS in the list is considered to be number 0. Note that you should not set the guest kernel as the default because it will not boot — it is designed only to be created on top of the hypervisor (dom0).

Save your changes and reboot, making sure that your new hypervisor kernel is the one that boots. Your system should restart as normal, and you will probably not notice anything different beyond a smattering of “XEN” at the very beginning of the boot phase. But when you are back in control, open a terminal and run uname -r. It should tell you that you are running the Xen hypervisor kernel.

At this point, you are already running as a virtual machine on top of the Xen kernel, but there is no way for you to communicate with the Xen kernel and thus manipulate the virtual machines on the system. To do that you need to start the Xen daemon, which provides the link between dom0 (where you are working) and the Xen kernel underneath.

Run ps aux | grep xend. If you do not see xend in the resulting listing, you need to start it yourself by switching to root with su - and then running service xend start. Now run the command xm list, which prints out a list of all the virtual machines that are running and how much RAM they have allocated — you should see Domain-0, which is your current system, in the list.

Setting up guest operating systems

The output from xm list probably shows that domain 0 is taking up all the RAM on your system, which means there is no room to create a new guest OS. Fortunately, you can resize that memory usage downward to make space: Run the command xm mem-set Domain-0 256 to have domain 0 use 256MB RAM. This is the bare minimum for a Fedora install, so expect some slowdown — if you have more than 512MB RAM, we recommend you allocate more to each VM.

Creating a domU VM on Fedora is handled with the xenguest-install.py script, which you should run as root. You are asked to do the following things:

1. Give your virtual machine a friendly name (for example, FCUnleashed) so that you can differentiate between it and other virtual machines.
2. Allocate it some RAM, with the minimum being 256MB; more is better.
3. Choose where it should save its files. Xen uses a loopback filesystem so that all of a VM’s files are stored in just one file on domain 0. Enter something like /home/paul/vms/fcu.img.
4. Select how big the virtual disk should be. For a basic install, around 4GB should be enough.
5. Set the install location (the place from which Fedora should install). This needs to be an online resource, so enter http://download.fedora.redhat.com/pub/fedora/linux….

Now sit back and wait. Downloading the necessary files can take quite a while, depending on your connection speed.

Once your files have been downloaded, the normal Fedora installer (Anaconda) will start, and will ask whether you want to install using text mode or VNC — choose Start VNC so that you have a graphical install. Xen’s guests do not have direct access to the hardware, which means they have nowhere to display graphics. VNC lets you have your Xen VM render its graphics to your dom0 display inside a window, which means you can work with multiple VMs simultaneously. When you select Start VNC, you are prompted to enter a password. Click OK and you see the VNC address to which you need to connect. This address should look something like 10.0.0.1:1, where the :1 is the number of the VNC display.

Back on dom0, you should have installed VNC Viewer at the start of this chapter, so go to Applications -> Accessories -> VNC Viewer. Now enter that address (including the :1 or whatever it is for you) and click Connect. Enter your password when prompted. VNC starts and you see the Fedora installer. Depending on the resolution of your screen, the Fedora installer might not fit entirely on the screen; in that case, you have to use the scrollbars to get around.

The installer is as normal from here on in, except of course that it is using the virtual disk you created earlier so you have only a small amount of space. It might refer to your hard disk as something like /dev/xvda — do not worry about that.

Runtime configuration

Now that your guest OS is up and running, you can start trying out more of the features of the xm command on dom0. You have already seen xm mem-set, which alters the amount of memory allocated to a machine. This works because the domU VM is aware of its virtualized state and can therefore handle having memory taken away. This extends further: You can use xm shutdown yourvm to have Xen politely request the VM to shutdown. On Linux, this goes through the whole shutdown sequence properly, ensuring that the machine is cleanly terminated. If you want an immediate shutdown, use xm destroy yourvm, but make sure the virtual machine is in a safe state first — if you have a text file open and unsaved, for example, it will be lost.

The xm command can also be used to save snapshots of a virtual machine, rather than just switching them off. To do this, use xm save yourvm yourvm.state. That command essentially saves the RAM of the yourvm VM (change yourvm to whatever you called your virtual machine) to a file and then turns off the VM. To restore a saved state, just use xm restore yourvm.state. If you want to create a virtual machine from a configuration file, use xm create -c yourconfig. Note that Xen searches the directory /etc/xen for configuration files, and that each VM must have a unique name assigned to it and set in the configuration file.

You can connect to the console of any virtual machine by running xm console yourvm. To exit from a console, press Ctrl-] (Control + right bracket). This does not shut down the VM; the VM continues to run, but you are no longer connected to it and have to use xm connect to reconnect.

TIP: The configuration files in /etc/xen are in text format and so are easily edited. For example, if you want to change the number of CPUs a VM sees, look for the vcpus setting. Note that these are virtual CPUs rather than real ones — you can set this to 8 and have your guest see eight CPUs, even if your actual machine has just one. This is a great way to test a cluster without going beyond your desktop!

Related Fedora and Xen commands

The following commands are useful for working with Xen on Fedora:

• virt-manager — Red Hat’s new graphical Xen management system
• vncviewer — Lets you connect to the graphical output of a Xen VM
• xend — Starts and stops the Xen daemon without using the service command
• xenguest-install.py — A helpful script that generates configuration files for you
• xm — Lets you manipulate the state of virtual machines while they are running

Copyright © 2007 Pearson Education. All rights reserved.

Popularity: 6% [?]