Mount NTFS Partition on Fedora Core 6

If you have a ntfs partition on your computer system and want to read & write to that drive, you can now do so with NTFS-3G. Installation was a breeze.

su -
yum install ntfs-3g

In the /etc/udev/rules.d/50-udev.rules replace this line:

SUBSYSTEM=="block", GROUP="disk", MODE="0640"

with the following line:

SUBSYSTEM=="block", GROUP="disk", MODE="0660"

Add the user to the disk and fuse group:
usermod -a -G disk,fuse change_this_to_your_username

Change permissions of the directory (example is hda1) where you want to mount the NTFS partition to 777:
chmod 777 /media/hda1
*If your not sure which drive is your NTFS partition as root type in “fdisk -l” to see a list of all your drives*

Add this line to /etc/fstab (change hda1 to your ntfs drive):
/dev/hda1 /media/hda1 ntfs-3g dmask=022,fmask=133,noauto,locale=hu_HU.UTF-8,user 0 0

To automatically mount your NTFS partition in GNOME, run this command:
rm -f /usr/share/hal/fdi/policy/10osvendor/
99-redhat-storage-policy-fixed-drives.fdi

Editing basics for the xorg.conf file

Editing basics for the xorg.conf file

For many users, the xorg.conf file, which configures the system resources, graphics card, keyboard, pointing device, and monitor for a computer running the X Window System, is an exception to GNU/Linux's do-it-yourself credo. Users who think nothing of editing /etc/fstab or /etc/hosts.allow will shy away from xorg.conf for fear of breaking their systems, relying instead on tools such as the KDE Control Center or Debian's dpkg-reconfigure xserver-xorg instead. But learning your way around xorg.conf not only teaches you a lot about how your system operates -- it can also come in handy when the graphical display fails and you either can't remember the handy command that does the work for you, or you're working with a distribution that isn't blessed with it.

It's easy to understand users' caution. Not only does xorg.conf contain a lot that can go wrong, but it is only fitfully documented in man and Web pages. Moreover, because the file's settings are specific to each system, borrowing an example of the file off the Internet is unlikely to give you more than basic ideas of how to get its settings correct. However, so long as you remember to make a backup copy of the file and keep within the settings defined by the documentation that comes with the hardware, the danger is actually minimal.

The xorg.conf file is divided into a minimum of eight sections. The start of each section is marked by the word Section followed by the section's name, and its end by EndSection. Sections can be placed in any order, and you can have more than one section that cover a certain purpose -- for example, if you are using multiple monitors. As in most configuration files, you may also see lines that start with a number sign (#) that provide comments for human readers. These lines are ignored by the operating system, and you can add more for your own purposes.

Within each section, you can quickly observe the structure that additional entries should follow. For instance, most sections indent once for a field and again for its value, which is placed in double quotation marks. Similarly, hardware has an Identifier field, which can be anything so long as it is unique. The indentations are not needed by your computer, but they do ensure that the file is kept in human-readable form. Once you understand this basic structure, you are ready to edit xorg.conf.

Setting resources and improving font display

Resources for the X server are listed in the Files section. Some distributions include the path to the database used for the RGB color palettes used for the display (/usr/share/X11/rgb), as well as the path to the server modules (/usr/lib/xorg/modules or /usr/lib/modules), but these paths should be unnecessary unless your system has resources stored in unusual places. Recent versions of Debian, for instance, omit these entries entirely.

Most of the system resources are devoted to the paths used for fonts. Users must add all new fonts via a font server, the easiest one to use being the one built into the KDE Control Center, which stores fonts in /usr/local/share/fonts (nothing comparable exists for GNOME). Fonts that were added during system installation are usually stored in /usr/share/fonts/ or /usr/share/fonts/X11, which has subdirectories for TrueType, Type 1 or PostScript, and bitmapped fonts. You can add new font paths by following the format of existing entries:

FontPath ""

If an application needs to display a particular font, then the X server uses the first instance of the font located. For this reason, you can sometimes improve font display on the system by changing the order in which fontpaths are listed. The "XFree86 Font Deuglification Mini HOWTO," an old but still useful source, suggests that you place any directory for 100dpi bitmap fonts before those for 75dpi bitmap fonts, and add :unscaled to the end of all the paths for bitmapped fonts. These changes help to ensure that a higher quality font will be the one used by the X server.

Editing X server modules

xorg.conf's Modules and DRI sections refer to modules loaded by the X server for such purposes as 3-D acceleration (glx, dri) and font support (freetype, type1, speedo). For the most part, you should not edit these sections. They are dependent on resources compiled in the kernel and supplied by various libraries added during installation, so simply editing xorg.conf may not have any effect on your system. Unfortunately, too, they are by far the least documented sections of the file, so if you're not an expert, leave them alone.

However, if you are having display problems, as a last resort, you can try the hacker's solution of commenting out all of the modules and adding them back one by one with each reboot. In particular, if you're using the freetype module, other font modules may be redundant, such as type1, as well as the xtt module, which provides TrueType support conflicts with freetype according to some reports.

Defining the keyboard

The keyboard is defined in a separate Input Device section in xorg.conf that starts with an Identifier. The Identifier is followed by a Driver -- usually just kbd in a 2.6 kernel -- and, for the main keyboard in a configuration, the CoreKeyboard option.

Most users will also want to use the XkbRules options to define the general behavior of the keyboard, since the alternative is to define all aspects of the keyboard layout separately. This option should usually be defined as xorg, which indicates that the X server should use the standard settings for xorg.

However, even with the shortcut provided by XkbRules, you still need to define the XkbModel for the keyboard, using one of the options listed in /usr/share/X11/xkb/rules/base.lst, or else a generic one such as pc104 or pc102. You also need the XkbLayout option, which takes one of the standard two-digit locale codes that are also listed in base.lst in order to define the symbols associated with other keys.

If you want to use multiple layouts you can use XkbLayout to list multiple keyboard layouts in a comma-separated list, and use XkbOption to define a key or key combination that cycles through each layout. For example, to use Alt-Shift to move through the defined layouts, you would enter the line Option "XkbOptions" "grp:Alt_shift_toggle".

Similarly, if you want to define a Compose and an AltGraph key -- two keys that are used to enable the typing of international characters, such as accents or currency symbols -- you can use XkbOptions to define them. For instance, defining them as "compose:rwin, grp:lwin" would give those useless right and left Windows key a purpose at last.

Configuring the pointing device

A mouse or other pointing device is defined in a separate Input Device section. After the Identifier, the next three lines in the section will generally be:

Driver "mouse"

 Option "CorePointer"

 Option "Device" "/dev/input/mice"

As you can probably guess, the CorePointer option defines the primary input device, and the Device gives the path to the device.

After that, an entry for a pointer device will have an option defining the Protocol, which describes the manufacturer and model of the device. The Auto option for the protocol is reported as broken in recent versions of xorg, so you should specify the exact protocol, such as Microsoft or Logitech, or the general type of mouse, such as ImPS/2 or USB.

If you have a two-button mouse, you should add the "Emulate 2 buttons" option. For devices that have more than three buttons, you can use the "Buttons" option to specify the exact number if you have more than three. More esoterically, you can use the "XAxisMapping" and "YAxisMapping" options to give a space-separated list of buttons to use when a scroll wheel is emulated, or "ZAxisMapping" to map the scroll wheel motion to another axis or button, either because you are using a device that lacks a scroll wheel but has extra buttons, or for simple convenience.

Configuring the graphics card

xorg.conf's Device section controls the graphics card configuration. This name is obscure, but understandable when you consider that the graphics card drives the entire display. The basic configuration consists of the Identifier, followed by the Driver field. If you are having trouble with the display, you can try one of the drivers in the /usr/lib/xorg/modules/drivers directory, using the first element of the file name before the underscore as the entry for the driver in xorg.conf. For example, if the s3virge_drv.so file is in the directory, you would enter the driver name as "s3virge". If all else fails you can get basic video support by entering "vesa" or "vga" for the driver. Most of these drivers have a man page that you can consult for more information.

Increasingly, the BusID field, which defines the slot the video card is placed in, is also being used in this section. Usually, the first video card's bus ID will be PCI:1:0:0, but you can find it for sure by running the lspci command and looking for the video card in the results. Depending on the card in your system, you may also need to add the VendorName and BoardName fields, using information that came with your video card.

Defining the monitor

At a minimum, the modern Monitor section of xorg.conf consists of a unique Identifier and the option DPMS, which enables Display Power Management Signaling in order to conserve the power used by the monitor. However, you can also set the horizontal and vertical refresh rates in the HorizSync and VertRefresh fields, or the monitor's Gamma setting, using information supplied with the monitor.

Another option is DisplaySize, which is measured in millimeters and specifies the dots per inch to use at a particular resolution. To get the resolution in millimeters, multiply both the height and the width by 25.4, and divide each result by the desired DPI. For example, if your resolution is 1024 x768, the results rounded down would be 270 and 203, and the entire entry for the option would read:Option "DisplaySize" "270 203 # 96 DPI @ 1024x768".Alternatively, with some Nvidia cards, you may need to suppress the automatic setting of the DPI by including the option "USEdidDPI" set to "false" and following by the option "DPI" with a value for the desired DPI, such as "96 x 96".

Setting resolution and color depth

The Screen section begins with a unique identifier, followed by a summary of the display options, listing the video card ("Device") and monitor by the Identifiers they were given in early sections of the file, followed by the default color depth ("DefaultDepth").

The rest of the section is devoted to the Display subsection. For each color depth ("Depth"), the subsection lists each resolution ("Mode") that the system supports. When the X Window System starts, it will try to use the default color depth at the maximum resolution listed for it. However, if X is unable to do so for any reason, then it will try each resolution for the default color depth, then repeat the process for the next highest color depth until it manages to load.

You can use this behavior to force your display to use a particular color depth and resolution, either because your system refuses to use the settings you want -- possibly due to a flaw in the driver -- or because you want settings lower than the maximum. All you need to do is change the default color depth, then, under the listing of resolutions for that depth, place your preferred resolution first.

You may also choose to delete the resolution listings for other color depths, as well as other resolutions. As long as you have a backup of the original xorg.conf file, the worst this practice can do is force you to restore the backup and reboot.

Final steps and final words

If you have added hardware to your system, your last step in editing xorg.conf must be to make sure that the xorg.conf references it. That means adding the Identifier for a new monitor or video card to the Screen section, and the Identifier for a new pointing device or keyboard to the ServerLayout section. When you have done that, either reboot your system or restart X using Ctrl-Alt-Backspace to test the new configuration. Should X fail to start, you can still edit xorg.conf from the command line, or, when either all options or all patience is exhausted, restore your system using the backup copy you made of xorg.conf. You can find log files for Xorg in /var/log, although, since the problem is bound to be in your recent changes, you may not need the log to figure out what is wrong.

These are only the most basic options for editing xorg.conf. Depending on which manufacturer you buy your hardware from and whether you are using multiple pieces of the same type of hardware, you can significantly complicate the contents of the file. However, the information here is enough for a basic orientation. You may never have to edit xorg.conf manually, but if you do, knowing what to expect can only help.

SSH tricks

SSH (secure shell) is a program enabling secure access to remote filesystems. Not everyone is aware of other powerful SSH capabilities, such as passwordless login, automatic execution of commands on a remote system or even mounting a remote folder using SSH! In this article we’ll cover these features and much more.

SSH works in a client-server mode. It means that there must be an SSH daemon running on the server we want to connect to from our workstation. The SSH server is usually installed by default in modern Linux distributions. The server is started with a command like /etc/init.d/ssh start. It uses the communication port 22 by default, so if we have an active firewall, the port needs to be opened. After installing and starting the SSH server, we should be able to access it remotely. A simple command to log in as user1 to the remote_server (identified by a domain name or an IP address) looks like this:

ssh user1@remote_server

After entering the password to access the remote machine, a changed command prompt should appear, looking similar to user1@remote_server:~$. If this is the case, it means that the login was successful and we’re working in a remote server environment now. Any command we run from this point on, will be executed on the remote server, with the rights of the user we logged in with.

SCP - secure file copying

SCP is an integral part of the OpenSSH package. It is a simple command allowing to copy any file or folder to or from a remote machine using the SSH protocol. The SSH+SCP duo is a great replacement of the non-secure FTP protocol which is widely used by the Internet users nowadays. Not everyone is aware of the fact though, that all the passwords sent while using the FTP protocol are transferred over the network in a plain text format (making it dead easy for crackers to take over) - SCP is a much more reliable alternative. The simplest usage of SCP looks like on the following example:

scp file.txt user1@remote_server:~/

This will copy the local file.txt to the remote server and put it in the home folder of user1. Instead of ~/, a different path can be supplied, i.e. /tmp, /home/public, and any other path we have write access to.

In order to copy a file from a remote server to the local computer, we can use another SCP syntax:

scp user1@remote_server:~/file.txt .

This will copy a file file.txt located in a home folder of user user1 of a remote system to the local folder (the one we are currently in).

Other interesting SCP options:

• -r - to copy folders recursively (including subfolders),
• -P port - to use a non-standard port (the default is 22) - of course this option should be used if the server listens on a non-standard port. The option can be helpful when connecting from a firewall-protected network. Setting the SSH server to listen on 443 port (used for secure HTTP connections) is the best way to by-pass the administrator’s restrictions.

GUIs for SCP

If we do not like the console and we prefer GUI (graphical user interface), we can use a graphical (or pseudo-graphical) SCP client. Midnight Commander is one of the programs that provides an SCP client (option shell link). Nautilus and Konqueror are the SCP-capable file managers as well. Entering ssh://user1@remote_server:~/ in the URI field results in a secure shell connection to the remote system. The files can be then copied just as they were available locally.
In the MS Windows environment, we have a great app called WinSCP. The interface of this program looks very much like Total Commander. By the way, there is a plug-in allowing for SCP connections from TC as well.

SSH without passwords - generating keys

Entering passwords upon every SSH connection can be annoying. On the other hand, unprotected remote connection is a huge security risk. The solution to this problem is authorization using the private-public key-pair.

The pair of keys is usually generated using the ssh-keygen command. Below, there is a sample effect of such key generation. RSA or DSA keys can be used.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key
(/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/home/user1/.ssh/id_rsa.
Your public key has been saved in
/home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

When the program asks for the key password, we should just press ENTER - this way, a passwordless key will be created. Remember that this is always a security hole to have a passwordless key (in simple words, doing that downgrades your remote system security to the security of your local system) so do it on your own risk. As the ssh-keygen finishes its work, you can see that two keys have been generated. The private key landed in /home/user1/.ssh/id_rsa and we should never make this public. The second public key appeared in /home/user1/.ssh/id_rsa.pub and this is the one we can show the entire world.

Now, if we want to access a remote system from our local computer without passwords (only using the keys), we have to add the information about our public key to the authorized_keys file located in ~/.ssh folder on the remote system. This can be done using the following commands:

Pic 1. Passwordless SSH login

$ scp /home/user1/.ssh/id_rsa.pub \
user1@remote_server:~/
$ ssh user1@remote_server
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

The third command will be obviously executed on a remote server. After this operation, all actions performed on the remote server with SSH will not need any password whatsoever. This will certainly make our work easier.

Notice that if you need passwordless access from the remote server to the local one, the similar procedure has to be performed from the remote server. Authorization using keys is a one-way process. The private key can verify the public one, not vice-versa.

Executing commands on a remote system

Well, now when we can already log into remote OS without the password, why wouldn’t we want to execute some command remotely? There can be multiple useful appliances of this, especially when we have to execute some command on a daily basis, and it could not be automated before, because of the need to enter the password manually (or enter it as plain text which is not very secure).

One interesting case is a “remote alert”. Let’s say that we have some crucial process running on the remote system, i.e. a website running on Apache server. We want be be warned when the system gets out of resources (i.e. the disk space is getting short or the system load is too high). We could obviously send an e-mail in such cases. But additionally, we can execute a remote command which plays a warning sound on our local OS! The code for such event would look something like that:

ssh user1@local_server 'play \
/usr/share/sounds/gaim/arrive.wav'

This command, executed in a script from the remote server would cause a passwordless login of user1 to the local_server (the one we’re usually working on) and play a wave file with the play command (which is usually available in Linux). The actual case in which we execute this remote command should obviously be specified in a script, but we’re not going to provide a scripting course here, but a way to execute remote commands with passwordless SSH :).

X11 forwarding - running graphical apps remotely

One of the least known functions of SSH is X protocol forwarding. This enables us to run almost every X application remotely! It’s enough to connect to the remote server using the -X option:

ssh -X user1@remote_serwer

and the display of every X application executed from now on will be forwarded to our local X server. We can configure the X11 Forwarding permanently by editing the /etc/ssh/ssh_config file (relevant option is ForwardX11 yes). Of course for the option to work, the remote SSH server needs to support X11 forwarding as well. The /etc/ssh/sshd_config file is responsible for that. This option is however configured by default in most of the Linux distros.

If we just need to execute one single command, we can use the syntax we learned before:

ssh -X user1@remote_serwer 'psi'

- this will execute PSI instant messenger on the remote server, passing the display to the local screen.

Of course the speed of applications executed remotely depends mostly on the network connection speed. It works almost flawlessly in local networks (even things like forwarding Totem playing a DivX movie). In case of Internet connection, a DSL seems reasonable to get apps like Skype or Thunderbird work quite well with a remote call.

Notice that it’s also possible to connect to the remote server without the X11 forwarding enabled, export the DISPLAY variable to point to the local machine and then run the X application. This way, the application would be executed with a remote display, using the generic X server functionality. SSH security would not be applied in such case since this kind of configuration has nothing to do with SSH. Depending on the configuration of the local X server, it may be that the authorization of the remote X applications needs to be turned on in such case. This is usually done by the command xhost. For example, xhost + hostname accepts all the remote applications from the specified hostname for a while. If we plan to use this option regularly, a more secure X server configuration is recommended.

SSHFS - mounting a remote folder

Working on a file located on some remote server via SSH can be quite annoying especially when we need often copy different files in both directions. Using a the fish:// protocol in Midnight Commander or Konqueror is a partly solution - fish tends to be much slower than pure SSH and it often slows down even more while copying files. The ideal solution would be a possibility to mount a remote resource available through SSH only. The good news is that… this option exists for a while already, thanks to sshfs and the fuse project.

Fuse is a kernel module (recently it has been adopted in the official 2.6 series) allowing for mounting different filesystems by an unprivileged user. SSHFS is a program created by the author of fuse himself which enables to mount remote folders/filesystems using SSH. The idea is very simple - a remote SSH folder is mounted as a local folder in the filesystem. Since then, almost all operations on this folder work exactly as if this was a normal local folder. The difference is that the files are silently transferred though SSH in the background.

Installing fuse and sshfs in Ubuntu is as easy as entering (as root):

# apt-get install sshfs

The only remaining action is adding the user that we want to give the permission to mount SSH folders to the fuse group (using a command like usermod -G -a fuse user1 or manually editing the /etc/group file). Eventually, the fuse module needs to be loaded:

# modprobe fuse

And then, after logging in, we can try to mount a remote folder using sshfs:

mkdir ~/remote_folder
sshfs user1@remote_server:/tmp ~/remote_folder

The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SCP. Same concerns direct file editing, creating or removing.

When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:

fusermount -u ~/remote_folder

If we work on this folder on a daily basis, it is wise to add it to the /etc/fstab table. This way is can be automatically mounted upon system boot or mounted manually (if noauto option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:

sshfs#user1@remote_server:/tmp \
/home/user1/remote_folder/ fuse    defaults,auto    0 0

If we want to use fuse and sshfs regularly, we need to edit the /etc/modules file adding the fuse entry. In other case we would have to load the module manually each time we want to use it.

Summary

As you can see, SSH is a powerful remote access tool. If we need to work with remote UNIX filesystems often, it’s really worth to learn a few powerful features of SSH and use them in practice. SSH can really make your daily work much more effective and pleasant at the same time. In the following article (to be published later this month) we’re going to cover another great feature of SSH: making different kinds of tunnels with port forwarding using transparent socks and a corkscrew

Sabayon Linux 3.4 Released

After 4 months of hard and deep development, the Sabayon Linux Crew is happy to announce the IMMEDIATE availability of Sabayon Linux 3.4 ! The most advanced: Linux Kernel 2.6.22 with extra Power Management (PowerTop), Wireless (mac80211), Ext4 Filesystem, Scheduler (CFS) and Virtualization (KVM,Virt-Manager,VirtualBox) Compiz Fusion.

[Sabayon Linux] via sabayonlinux.org

Introduction to zsh, a powerful and smart Linux/Unix shell

Are you a bash user wishing your shell would be smarter and even faster? This article gives a good overview of zsh's features, including typo correction and intelligent autocompletion. Some sample .zshrc files are included for Linux and Mac that allow you to instantly take advantage of zsh's user-friendly power.

[ZSH a Introduction] via Fried CPU

Featured Linux Download

Specto - Get web updates from the System tray : Linux only.

The free open-source app - Specto is located in the system tray and watches any of your websites, RSS feeds, and email for updates. Once a update has been done Specto recognizes this, and alerts you with a message. Specto supports Gmail straight away with out any awkward setup. You can add an unlimited amount of feeds and websites to your watch list.

[Specto] Download via Sourceforge

Linux Tips #02 - VMWARE

VMware

VMware provides a very complete virtual machine environment that emulates an Intel x86-based computer, running under Linux as the host operating system (it also runs under Windows NT).
Since VMware emulates a PC, it comes complete with a BIOS, and you can change BIOS parameters in the same way as with a normal PC. The emulation is so complete that each virtual machine can have one or more virtual Ethernet devices for networking. Networking is discussed in more detail below.

You can download VMware from the company's Website either as a compressed TAR archive or as an RPM. If you have downloaded the RPM, installation is a two-step process.
First install the RPM, using your favorite rpm command:
rpm -ivh VMware-2.0.2-621_i386.rpm

Don't worry if your numbers are slightly different, as you may have downloaded a more up-to-date version.
Second, configure VMware to run on your system, using the vmware-config.plcommand. I will discuss that step in more detail below because you will also need it if you install from a compressed TAR archive, and if you change your kernel.
If you install from the compressed TAR archive, the steps are:

• Extract the contents of the TAR archive:
tar zxvf VMware-2.0.2-621_i386.tar.gz



• Run the installation script:
cd vmware-distrib
./vmware-install.pl


After asking you a few questions about where to install VMware, the script then asks if you want to run the vmware-config.pl script. You should answer yes if this is your first install of VMware. The installation then proceeds, and you must read the end user license agreement. I will discuss the configuration script below.

When you install VMware from a compressed TAR archive, the installation script automatically runs the VMware configuration script, vmware-config.pl. If you install from an RPM or if you change your kernel, you will have to run vmware-config.pl manually. (In fact, if you go to run VMware and your kernel has changed, VMware tells you that you need to rerun vmware-config.pl.)

To run the script, simply type config-vmware.pl at the command line and follow the instructions provided by the script. You may need to have a C compiler installed on the system. If none of the prebuilt modules supplied with VMware are suitable for your kernel, the script will rebuild the modules. You will also be asked if you want your virtual machines to access the host filesystem. Samba makes that possible and, if you already have Samba installed or plan to install it separately, you should answer no.

Lastly, you will be asked if you want to use the network from your virtual machines. For most people, the answer will be yes. You can enable two types of networking. One is host-only networking, in which your virtual machines run on a virtual network and can only access your host system and each other. The other is bridged networking, in which your virtual machines are actually on the same ethernet as your host. You can use DHCP to allocate addresses for your virtual machines in either case.

Once you have installed and configured VMware, you can create a virtual machine and have it up and running within a few minutes after the install with VMware's configuration wizard. The wizard takes you through the steps of allocating space for the virtual machine's disk, which can be a partition or a large file in your Linux file system. The wizard also allows you to attach serial and parallel ports to the appropriate devices under Linux, so your virtual machine has the full complement of devices it needs.

However, once your virtual machine is up and running, you then have to install an operating system on it! That is just like installing an operating system on real hardware. As long as your virtual machine has access to a CD-ROM, simply place the install CD into your system's CD-ROM and power up your virtual machine (that is, click on the power button). Your virtual machine will run through the installation process and reboot at the end, just as Windows normally does.
In addition, VMware comes with a set of tools for each operating system that it supports. Those tools allow your virtual machine to gain high-speed access to the full display on your system instead of running in a window.

Because VMware provides a virtual machine, it is not restricted to running Windows. You can run quite a large number of operating systems under VMware, including MS-DOS, Windows 9x, Windows NT, Windows 2000, FreeBSD, and Linux. Thus, VMware is ideal for testing out new operating systems, providing a teaching environment, or grabbing screen shots of installation.

Linux Tips #01 - Killing the Yum.pid

First do

Code:

ps aux | grep yum

to see if it's running.

If it is running in the background you could type

Code:

fg

that would bring the last background task to the foreground.

Or you could kill the process using the info from the ps command.

If it isn't running and the file is left over, you can delete the file /var/run/yum.pid and run it again
Code:

jobs

shows jobs you started. First one is job number 1, second 2 etc. If you found out there was job number 1 that was your yum update, then simply

Code:

kill %1

to kill it. %1 because it's the number one process of your own, not process ID 1.

Alternatively,

Code:

ps -e | grep yum

and you should get the process ID (pid). Use that number:

Code:

kill number

or just

Code:

killall yum

If you can't kill it, make some force:

Code:

killall -9 yum

Or if you find it's not running anymore, but lock file exists, just remove it:

Code:

rm /var/run/yum.pid

And then re-try