Showing posts with label Linux Tricks. Show all posts
Showing posts with label Linux Tricks. Show all posts

Friday, 9 March 2012

Best Linux Distributions

What is the best linux distribution for you ?

There are various approaches to answering this question. The broad answer is: "any of them," but that's not very helpful if you're just looking for a place to start.

The problem is, there never can be one best Linux distribution for everyone, because the needs of each user tend to be unique. Telling someone who's looking for a good introductory distribution to try Gentoo, for instance, would be a mistake because for all its positive qualities, Gentoo is decidedly not a beginner's distro.

All too often, Linux aficionados will tend to list the distributions they like as the best, which is fair, but if they are not aware of their audience, they could suggest something that does not meet that person's needs. Finding a good Linux distribution is like finding a good match in an online dating service: good looks aren't the only quality upon which to judge a Linux distro.

To help users discover the Linux distribution that's best for them, this resource will definitively list the best candidates for the various types of Linux users to try. The use-case categories will be:
  • Best Desktop Distribution
  • Best Laptop Distribution
  • Best Enterprise Desktop
  • Best Enterprise Server
  • Best LiveCD
  • Best Security-Enhanced Distribution
  • Best Multimedia Distribution
Best Linux Desktop Distribution

There are a lot of Linux distributions that have the primary focus of becoming the next best desktop replacement for Windows or OS X. Of all the categories in this list, this is the most sought-after, and contentious, group of distros.

While it would be ideal to include many distributions on this list, the reality is that there really needs to be just one "best" Linux distribution. For early 2010, that distro has to be Canonical's Ubuntu.

linux distros- Ubuntu

Ubuntu edges out its closest contenders, Fedora and openSUSE, because its development team is constantly focused on the end-user experience. Canonical and the Ubuntu community have spent a lot of time and resources on bringing ease-of-use tools to this distribution, particularly in the area of installing Ubuntu and installing applications within Ubuntu.

In addition, Ubuntu's level of support for its desktop products is highly superior, which is important in this class of distributions since it is the most likely to contain users new to Linux. Both the official and unofficial Ubuntu documentation is robust and searchable, a big plus.

Best Linux Laptop Distribution

Laptop distributions almost fall into the same category as desktop users, but there are a number of key differences that make the criteria for evaluating a good laptop distribution important. Power management, docking tools, and wireless ease-of-use are critical to users on the go, as is having a distro that meets those needs.

Right now, the best laptop distribution is openSUSE, one of the lead contenders for the desktop honors. On the laptop, openSUSE shines with great connectivity tools, such as an easy-to-use networking toolset that not only handles WiFi connectivity, but also CDMA/cellular modem connections.

best linux distros

openSUSE also deals with docking stations for laptops very well, including dual-monitor management on the fly. Power management is very granular, which is great for detailing various power needs you might find yourself needing.

Best Linux Enterprise Desktop

This category is replete with great contenders as well, and it's difficult to highlight just one. At the end of the day, though, the nod must be given to SUSE Linux Enterprise Desktop (SLED).

linux distros SLED

The reason is simple: while SLED and its primary competitor Red Hat Enterprise Linux Desktop are nearly identical in features and support performance, SLED has the advantage of the openSUSE Build Service, a free and open service that lets applications be built and delivered to SUSE Linux and openSUSE products (as well as Red Hat and CentOS).

This is a very important differentiator in enterprise desktop development, as it means that SLED has the current advantage of application building and deployment in the enterprise arena.

Best Linux Enterprise Server

Again, in this category it really comes down to two main contenders: Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES). Given the pick for the Enterprise Desktop category, you might expect SLES to get the "best of" label here.

But, when all factors for the enterprise server are weighed, RHEL is still the king of this particular hill.

Best Distros Red Hat

Red Hat edges out Novell with its server product, because RHEL users get a deeply mature distribution, and Red Hat's support structure is second to none in the enterprise channels.

Best Linux LiveCD

As Linux technology improves, users can easily choose the LiveCD version of practically any of the Linux distros listed here to get the best LiveCD experience for their needs.

There is a specialized class of LiveCDs, however, that offers users utilities and tools for the specific purpose of repairing existing Linux and Windows installations. These distros are very useful to have regardless of what primary Linux distribution you like to use, because in a crisis they are invaluable to own.

In this class of distribution, KNOPPIX is hands-down the most complete and useful distro. Loaded on a CD or USB storage device, KNOPPIX will let you recover from nearly any rare Linux system crash as well as the much-less-rare Windows breakdowns.

Best Distros KNOPPIX

Best Linux Security-Enhanced Distribution

Linux is inherently very secure compared to other operating systems, but there's always room for improvement.

One of the challenges for locking down Linux is if you are not careful, you can take away too much functionality. Another challenge is that the best security-oriented Linux distro, SELinux, is historically known to be difficult to configure correctly. Still, if security out of the box is your priority, this is the best place to begin.

Another approach is the white hat method: using security and forensic tools to examine your existing installation, determine the holes, then lock your system down based on what gaps you find. If you have the time and inclination, this is a great way to do it, because this will get any existing system more secure right away.

For the white hat approach, the best distribution is BackTrack Linux, a dedicated penetration testing distro that will enable you to safely try to crack any system you are caretaking. Its toolset and strong community give it the advantage in this category.

Best Distros Back Track

Best Linux Multimedia Distribution

General Linux distributions have come a long way in terms of multimedia performance. Rare is the audio or video file that can't be played on Linux. Music services such as Rhapsody and video sites like YouTube and Hulu are also standards-compliant and accessible to Linux users.

Still, for those users who are multimedia creators as well as consumers, there are Linux distributions that contain powerful tools for audio and video editing.

The best in this class is currently Ubuntu Studio. For audio, video, and graphic production, it contains a very complete set of tools, as well as format and codec support for a huge range of multimedia formats.

Best Distros Ubuntu Studio

The applications contained in Ubuntu Studio are the same or similar to those used by major studios to create cutting edge work, so users are getting the best apps, coupled with the strong support ethos already found in the Ubuntu community.

In Linux there are as many opinions as there are lines of code. This represents one view of the best in Linux. Select yours.

Sunday, 4 March 2012

How to set up the Cain & Abel network security tool

First you have to install program, called 'Cain and Abel'. Then, you will be automatically asked to install 'Win Pcap' and you should do that.
After installation you have to click on 'Cain and Abel' program icon with right mouse button and start it as administrator. Then push blue plus sign to scan Mac addresses. After scanning go to the bottom of program window and press APR tab. Then push blue plus icon again. When table appears push first option in first square and first option in second and then OK.
To reload you only need to push the third button at the top of program window.



Saturday, 11 February 2012

How To Mount A Hard Drive Automatically During Start up In Ubuntu




How To Mount A Hard Drive Automatically During Start up In Ubuntu


I do not know how many times I will ever receive requests such as “ Hello, how can I automatically mount a hard disk boot Ubuntu? ”. Finally I managed to find some ‘time to write this article I will show you the steps necessary to ensure that, in a completely automatic, power up your Ubuntu are also mounted hard drive or hard drive you need . Let’s start with a first method , longer and more cumbersome, but you will have full control of what you are doing. Open the terminal and type:

sudo mkdir / media / namepersonaldetails

Of course replace “ namepersonaldetails ” with a name to your liking. With this command we are not doing is create a directory under / media where we will mount our hard drive.Now comes the slightly more difficult to know the name of your HD (/ dev/sda2 / dev/sda3, etc.). You can do this from a terminal type the command:

sudo fdisk-l

or the command:

df-h

Now we have to edit the fstab file is a configuration file used to indicate which and how many drives loaded at boot time, with their options. Enter, therefore, the following command:

sudo nano / etc / fstab

and, at the end of the file, add:

/ Dev/sda3 / media / namepersonaldetails ntfs auto, rw, exec, users, dmask = 000, fmask = 111, nls = utf8 0 0

As you can see it, in this case, a HD with NTFS file system. To check that the HD is really mounted, type:

sudo mount-a

Another effective method , and very fast, is to create a small startup script. Type:

gedit ~ / mount.sh

and paste the following code:

# / Bin / sh 
gvfs-mount-d / dev / sdaX

Where, of course, instead of sdaX you need to put the id of your HD. Now granted execute permissions to this script:

chmod + x ~ / mount.sh

And add it to “ boot applications ”in Ubuntu. All very simple, do not you think?


    Sunday, 5 February 2012

    How to install Perl Module using CPAN

    Install Perl Module using CPAN


    At times, we need to install Perl modules that are not found in the official repository of a distribution. In that case, we have to revert to using cpan. CPAN stands for Comprehensive Perl Archive Network. It is an archive of over 16,000 modules of software written in Perl, as well as documentation for it. This tutorial will show you how to install a module using CPAN.

    First we need to launch cpan. Type cpan in a terminal. If it is not already configured, then it will start to ask a series of questions. Just press Enter all the way until it asks for your location. Specify the location by entering the number for that location in the list shown. Then it will ask about your country, go ahead and type the number appropriate for your country. At the end you will see the cpan prompt like so


    cpan>

    To install a module, for example, Cache::Static, type the following at cpan prompt

    cpan>install Cache::Static

    It will ask you some questions, just press Enter to accept the defaults which almost always work. The module with all its dependencies will be downloaded, compiled and installed.

    When you get back the cpan prompt, the module is installed.
    Type quit to get out of cpan

    cpan>quit

    To confirm that the module is installed successfully, run this command

    perl -e "use Cache::Static"

    If you get no output, it means the module is installed successfully.

    If you see the error “/bin/sh: cc: command not found”, then gcc is not installed. Install it like this on Debian, Ubuntu

    aptitude install gcc

    On Red Hat, Centos, Fedore, the following will work

    yum install gcc

    ssh passwordless authentication without keys

    ssh passwordless authentication without keys

    Imagine ever wanted to avoid the hassle of typing in the password while connecting to servers using ssh? Here is a really simply neat trick that will demonstrate how easy it is to accomplish it so it does not ask for password. And as a bonus, you will notice that the connection is surprisingly much faster than you originally thought. No, it is not about ssh keys.

    Suppose you could control the master which would permit you to enter the door without a key and the path it takes is always the right hand path. While you are thinking about it and saying to yourself what it has to do with ssh, allow me to tell you that you will realize once you have read the whole article how it is going to help you a lot in understanding passwordless authentication using this method.

    The first thing we need is simply two lines in .ssh/config inside your home directory. If the file is not there, just create it. So the two magic lines are:

    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p

    Now connect to any host and it will ask for password. What the heck? It still asks for password, I heard you saying. That’s alright. Just put in the correct password and leave that terminal open. Open another terminal and try to connect to the same host again as in the first terminal and voila the magic…

    While you are thinking about how just two key words ControlMaster and ControlPath allowed you to connect to a host without password and also much faster, let me throw in another neat trick.

    If you ever wanted not to have to open another terminal, simply connect as shown below and the ssh will go into background

    ssh -N -f host


    Enjoy Vivek Creations :)

    How to Send mails from command line

    Send mails from command line

    Often times, we want to send log files or other emails from command line or want to script them. In this tutorial, I will show you how to do that using two mail clients mail and mutt.

    Sending mails using mail:

    mail (mailx is the newer version) is a fantastic program that can be used for sending email from command line or from within scripts.


    The following example will send an email to admin@example.com, with subject “Apache is down” and text “Please check Apache at host name of the server”

    echo “Please check Apache at `hostname`” | mail -s “Apache is down” admin@example.com



    We can cat the contents of any text file, for example, log file and it will be sent to the recipient specified

    cat “/var/log/apache2/error.log” | mail -s “Apache is down” admin@example.com

    To attach a file, other than a text one, we need to uuencode (unix to unix encode) it before sending

    uuencode banner.jpg banner_out.jpg | mail webmaster@example.com

    The banner.jpg is the name of input file and banner_out.jpg is the output uuencoded file that we will be sent by mail.

    To have text sent alogwith the attachment, we can cat or echo that text too

    (cat /var/log/apache2/error.log;uuencode banner.jpg banner.jpg) | mail -s pic webmaster@example.com



    Sending mails from using mutt:

    With mutt, its same as using mail.

    echo “Please check Apache at `hostname`” | mutt -s “Apache is down” admin@example.com

    or we can cat the contents of a text file to show as body text

    cat /var/log/apache2/error.log | mutt -s “Apache is down” admin@example.com

    OR

    mutt -s “Apache is down” admin@example.com

    To send an empty body mail, use an empty line as the mail body:

    echo | mutt -s “Software upgrades for `hostname`” admin@example.com

    To attach a binary file, its even easier with mutt, just use the -a option

    echo | mutt -s “New logo for the company” -a logo.gif webmaster@example.com

    Hope you this creation added to your knowledge.


    Thursday, 5 January 2012

    How Linux boots


    As it turns out, there isn't much to the boot process:

       1. A boot loader finds the kernel image on the disk, loads it into memory, and starts it.
       2. The kernel initializes the devices and its drivers.
       3. The kernel mounts the root filesystem.
       4. The kernel starts a program called init.
       5. init sets the rest of the processes in motion.
       6. The last processes that init starts as part of the boot sequence allow you to log in.

    Identifying each stage of the boot process is invaluable in fixing boot problems and understanding the system as a whole. To start, zero in on the boot loader, which is the initial screen or prompt you get after the computer does its power-on self-test, asking which operating system to run. After you make a choice, the boot loader runs the Linux kernel, handing control of the system to the kernel.

    There is a detailed discussion of the kernel elsewhere in this book from which this article is excerpted. This article covers the kernel initialization stage, the stage when the kernel prints a bunch of messages about the hardware present on the system. The kernel starts init just after it displays a message proclaiming that the kernel has mounted the root filesystem:

    VFS: Mounted root (ext2 filesystem) readonly.

    Soon after, you will see a message about init starting, followed by system service startup messages, and finally you get a login prompt of some sort.

    NOTE On Red Hat Linux, the init note is especially obvious, because it "welcomes" you to "Red Hat Linux." All messages thereafter show success or failure in brackets at the right-hand side of the screen.

    Most of this chapter deals with init, because it is the part of the boot sequence where you have the most control.
    init

    There is nothing special about init. It is a program just like any other on the Linux system, and you'll find it in /sbin along with other system binaries. The main purpose of init is to start and stop other programs in a particular sequence. All you have to know is how this sequence works.

    There are a few different variations, but most Linux distributions use the System V style discussed here. Some distributions use a simpler version that resembles the BSD init, but you are unlikely to encounter this.

    Runlevels

    At any given time on a Linux system, a certain base set of processes is running. This state of the machine is called its runlevel, and it is denoted with a number from 0 through 6. The system spends most of its time in a single runlevel. However, when you shut the machine down, init switches to a different runlevel in order to terminate the system services in an orderly fashion and to tell the kernel to stop. Yet another runlevel is for single-user mode, discussed later.

    The easiest way to get a handle on runlevels is to examine the init configuration file, /etc/inittab. Look for a line like the following:

    id:5:initdefault:

    This line means that the default runlevel on the system is 5. All lines in the inittab file take this form, with four fields separated by colons occurring in the following order:
    # A unique identifier (a short string, such as id in the preceding example)
    # The applicable runlevel number(s)
    # The action that init should take (in the preceding example, the action is to set the default runlevel to 5)
    # A command to execute (optional)

    There is no command to execute in the preceding initdefault example because a command doesn't make sense in the context of setting the default runlevel. Look a little further down in inittab, until you see a line like this:

    l5:5:wait:/etc/rc.d/rc 5

    This line triggers most of the system configuration and services through the rc*.d and init.d directories. You can see that init is set to execute a command called /etc/rc.d/rc 5 when in runlevel 5. The wait action tells when and how init runs the command: run rc 5 once when entering runlevel 5, and then wait for this command to finish before doing anything else.

    There are several different actions in addition to initdefault and wait, especially pertaining to power management, and the inittab(5) manual page tells you all about them. The ones that you're most likely to encounter are explained in the following sections.

    respawn

    The respawn action causes init to run the command that follows, and if the command finishes executing, to run it again. You're likely to see something similar to this line in your inittab file:

    1:2345:respawn:/sbin/mingetty tty1

    The getty programs provide login prompts. The preceding line is for the first virtual console (/dev/tty1), the one you see when you press ALT-F1 or CONTROL-ALT-F1. The respawn action brings the login prompt back after you log out.

    ctrlaltdel

    The ctrlaltdel action controls what the system does when you press CONTROL-ALT-DELETE on a virtual console. On most systems, this is some sort of reboot command using the shutdown command.

    sysinit

    The sysinit action is the very first thing that init should run when it starts up, before entering any runlevels.

    How processes in runlevels start

    You are now ready to learn how init starts the system services, just before it lets you log in. Recall this inittab line from earlier:

    l5:5:wait:/etc/rc.d/rc 5

    This small line triggers many other programs. rc stands for run commands, and you will hear people refer to the commands as scripts, programs, or services. So, where are these commands, anyway?

    For runlevel 5, in this example, the commands are probably either in /etc/rc.d/rc5.d or /etc/rc5.d. Runlevel 1 uses rc1.d, runlevel 2 uses rc2.d, and so on. You might find the following items in the rc5.d directory:

    S10sysklogd       S20ppp          S99gpm
    S12kerneld        S25netstd_nfs   S99httpd
    S15netstd_init    S30netstd_misc  S99rmnologin
    S18netbase        S45pcmcia       S99sshd
    S20acct           S89atd
    S20logoutd        S89cron

    The rc 5 command starts programs in this runlevel directory by running the following commands:

    S10sysklogd start
    S12kerneld start
    S15netstd_init start
    S18netbase start
    ...
    S99sshd start

    Notice the start argument in each command. The S in a command name means that the command should run in start mode, and the number (00 through 99) determines where in the sequence rc starts the command.

    The rc*.d commands are usually shell scripts that start programs in /sbin or /usr/sbin. Normally, you can figure out what one of the commands actually does by looking at the script with less or another pager program.

    You can start one of these services by hand. For example, if you want to start the httpd Web server program manually, run S99httpd start. Similarly, if you ever need to kill one of the services when the machine is on, you can run the command in the rc*.d directory with the stop argument (S99httpd stop, for instance).

    Some rc*.d directories contain commands that start with K (for "kill," or stop mode). In this case, rc runs the command with the stop argument instead of start. You are most likely to encounter K commands in runlevels that shut the system down.

    Adding and removing services

    If you want to add, delete, or modify services in the rc*.d directories, you need to take a closer look at the files inside. A long listing reveals a structure like this:

    lrwxrwxrwx . . . S10sysklogd -> ../init.d/sysklogd
    lrwxrwxrwx . . . S12kerneld -> ../init.d/kerneld
    lrwxrwxrwx . . . S15netstd_init -> ../init.d/netstd_init
    lrwxrwxrwx . . . S18netbase -> ../init.d/netbase
    ...

    The commands in an rc*.d directory are actually symbolic links to files in an init.d directory, usually in /etc or /etc/rc.d. Linux distributions contain these links so that they can use the same startup scripts for all runlevels. This convention is by no means a requirement, but it often makes organization a little easier.

    To prevent one of the commands in the init.d directory from running in a particular runlevel, you might think of removing the symbolic link in the appropriate rc*.d directory. This does work, but if you make a mistake and ever need to put the link back in place, you might have trouble remembering the exact name of the link. Therefore, you shouldn't remove links in the rc*.d directories, but rather, add an underscore (_) to the beginning of the link name like this:

    mv S99httpd _S99httpd

    At boot time, rc ignores _S99httpd because it doesn't start with S or K. Furthermore, the original name is still obvious, and you have quick access to the command if you're in a pinch and need to start it by hand.

    To add a service, you must create a script like the others in the init.d directory and then make a symbolic link in the correct rc*.d directory. The easiest way to write a script is to examine the scripts already in init.d, make a copy of one that you understand, and modify the copy.

    When adding a service, make sure that you choose an appropriate place in the boot sequence to start the service. If the service starts too soon, it may not work, due to a dependency on some other service. For non-essential services, most systems administrators prefer numbers in the 90s, after most of the services that came with the system.

    Linux distributions usually come with a command to enable and disable services in the rc*.d directories. For example, in Debian, the command is update-rc.d, and in Red Hat Linux, the command is chkconfig. Graphical user interfaces are also available. Using these programs helps keep the startup directories consistent and helps with upgrades.

    HINT: One of the most common Linux installation problems is an improperly configured XFree86 server that flicks on and off, making the system unusable on console. To stop this behavior, boot into single-user mode and alter your runlevel or runlevel services. Look for something containing xdm, gdm, or kdm in your rc*.d directories, or your /etc/inittab.

    Controlling init

    Occasionally, you need to give init a little kick to tell it to switch runlevels, to re-read the inittab file, or just to shut down the system. Because init is always the first process on a system, its process ID is always 1.

    You can control init with telinit. For example, if you want to switch to runlevel 3, use this command:

    telinit 3

    When switching runlevels, init tries to kill off any processes that aren't in the inittab file for the new runlevel. Therefore, you should be careful about changing runlevels.

    When you need to add or remove respawning jobs or make any other change to the inittab file, you must tell init about the change and cause it to re-read the file. Some people use kill -HUP 1 to tell init to do this. This traditional method works on most versions of Unix, as long as you type it correctly. However, you can also run this telinit command:

    telinit q

    You can also use telinit s to switch to single-user mode.

    Shutting down

    init also controls how the system shuts down and reboots. The proper way to shut down a Linux machine is to use the shutdown command.

    There are two basic ways to use shutdown. If you halt the system, it shuts the machine down and keeps it down. To make the machine halt immediately, use this command:

    shutdown -h now

    On most modern machines with reasonably recent versions of Linux, a halt cuts the power to the machine. You can also reboot the machine. For a reboot, use -r instead of -h.

    The shutdown process takes several seconds. You should never reset or power off a machine during this stage.

    In the preceding example, now is the time to shut down. This argument is mandatory, but there are many ways of specifying it. If you want the machine to go down sometime in the future, one way is to use +n, where n is the number of minutes shutdown should wait before doing its work. For other options, look at the shutdown(8) manual page.

    To make the system reboot in 10 minutes, run this command:

    shutdown -r +10

    On Linux, shutdown notifies anyone logged on that the machine is going down, but it does little real work. If you specify a time other than now, shutdown creates a file called /etc/nologin. When this file is present, the system prohibits logins by anyone except the superuser.

    When system shutdown time finally arrives, shutdown tells init to switch to runlevel 0 for a halt and runlevel 6 for a reboot. When init enters runlevel 0 or 6, all of the following takes place, which you can verify by looking at the scripts inside rc0.d and rc6.d:

       1. init kills every process that it can (as it would when switching to any other runlevel).

    # The initial rc0.d/rc6.d commands run, locking system files into place and making other preparations for shutdown.
    # The next rc0.d/rc6.d commands unmount all filesystems other than the root.
    # Further rc0.d/rc6.d commands remount the root filesystem read-only.
    # Still more rc0.d/rc6.d commands write all buffered data out to the filesystem with the sync program.
    # The final rc0.d/rc6.d commands tell the kernel to reboot or stop with the reboot, halt, or poweroff program.

    The reboot and halt programs behave differently for each runlevel, potentially causing confusion. By default, these programs call shutdown with the -r or -h options, but if the system is already at the halt or reboot runlevel, the programs tell the kernel to shut itself off immediately. If you really want to shut your machine down in a hurry (disregarding any possible damage from a disorderly shutdown), use the -f option.