Tuesday, 26 November 2013

Creating Repositories

Open terminal
#vi /etc/yum.repos.d/a.repo
    [server]
    name=local server
    baseurl=file:///var/pub/Server
    gpgcheck=0
:wq



Now type
#yum clean all
#yum update
Now you can install any service by using yum package

Tuesday, 12 November 2013

Configuring Linux Services and Runlevels

Whilst the Firewall can be configured to block the ports used by the the various Linux services, if they are not required it is also good policy the disable any unused services on the Linux system. Not only does this provide an additional level of Linux security but it also avoids having unnecessary processes running and using up system resources. In this chapter we will explore the configuration of Linux services. 
Before talking more about Linux services it is first important to understand a little about Runlevels. A typical Linux system can be configured to boot up into one of five different runlevels. During the boot a process called init looks in the /etc/inittab file to find the default runlevel. Having identified the runlevel it proceeds to execute the appropriate startup scripts to run the services that are required for the system.
The good news is that both the runlevel and the services that get started are configurable.

Linux Init and Runlevels

During the boot process for Redhat 9.0 and Fedora Core systems, for example, the init command opens the /etc/inittab file to decide what "runlevel" the system should be booted to. The /etc/inittab file is a plain text file that can be opened with your favorite text editor.

The relevant section of a sample /etc/inittab file is as follows:
# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:


The key line in the example above is:
id:3:initdefault:

This tells the init process that the default run level for the system is run level 3. To change to a different run level simply change the number and save the /etc/inittab file. Before doing this, however, be absolutely sure you know which run level you want. Selecting the wrong runlevel can have serious consequences. To help with this a detailed description of the individual run levels is outlined in the table below:
Linux Runlevel Descriptions
Runlevel
Runlevel Description
Runlevel 0
The halt runlevel - this is the runlevel at which the system shuts down. For obvious reasons it is unlikely you would want this as your default runlevel.
Runlevel 1
Single runlevel. This causes the system to start up in a single user mode under which only the root user can log in. In this mode the system does not start any networking or X windowing, X or multi-user services. This run level is ideal for system administrators to perform system maintenance or repair activities.
Runlevel 2
Boots the system into a multi-user mode with text based console login capability. This runlevel does not, however, start the network.
Runlevel 3
Similar to runlevel 2 except that networking services are started. This is the most common runlevel for server based systems that do not require any kind of graphical desktop environment.
Runlevel 4
Undefined runlevel. This runlevel can be configured to provide a custom boot state.
Runlevel 5
Boots the system into a networked, multi-user state with X Window System capability. By default the graphical desktop environment will start at the end of the boot process. This is the most common run level for desktop or workstation use.
Runlevel 6
Reboots the system. Another runlevel that you are unlikely to want as your default.

Configuring Linux Services

Having identified, and possibly changed the runlevel your system will boot to you can now control which services you want to be automatically started at boot time. As mentioned previously it is important to avoid having any services running that you don't actually need. Every server is a potential access point into your Linux server so it is good practice to turn off anything you don't think you will use. Bear in mind that you can always turn on a service at a later date if you find you need it.
There are number of ways to control what services get started using both command line and graphical tools without having to delve into the depths of your Linux system.
The command line tool chkconfig (usually located in /sbin) can be used to list and configure which services get started at boot time. To list all service settings run the following command:
    /sbin/chkconfig --list

This will display a long list of services showing whether or not they are started up at various runlevels. You may want to narrow the search down using Linux grep command. For example to list the entry for the HTTP daemon you would do the following:
    /sbin/chkconfig --list | grep httpd

which should result in something like:

    httpd           0:off   1:off   2:off   3:on    4:off   5:off    6:off

Alternatively you may just be interested to know what gets started for runlevel 3:

    /sbin/chkconfig --list | grep '3:on'

chkconfig can also be used to change the settings. If we wanted the HTTP service to start up when we at runlevel 5 we would issue the following command:

    /sbin/chkconfig --level 5 httpd on

A number of graphical tools are also available for administering services. On RedHat 9 you can run the following command:
    redhat-config-services

The equivalent command on RedHat Fedora Core is:
    system-config-services

The above graphical tools allow you to view which services will start for each runlevel, add or remove services for each runlevel and also manually start or stop services.

Another useful tool if you do not have a graphical desktop running or access via a remote X server is the ntsysv command. ntsysv resides in /sbin on most systems. Whilst a convenient tool when you don't have an X server running the one draw back of ntsysv is that it only allows you to change the settings for the current runlevel.


 

Monday, 4 November 2013

Top 10 Linux Commands

#1: top

I figured it was fitting to put the top command at the top. Although top is actually responsible for listing currently running tasks, it is also the first command Linux users turn to when they need to know what is using their memory (or even how much memory a system has). I often leave the top tool running on my desktop so I can keep track of what is going on at all times. Sometimes, I will even open up a terminal (usually aterm), place the window where I want it, and then hide the border of the window. Without a border, the terminal can't be moved, so I always have quick access to the information I need.
Top is a real-time reporting system, so as a process changes, it will immediately be reflected in the terminal window. Top does have some helpful arguments (such as the -p argument, which will have top monitor only user-specified PIDs), but running default, top will give you all the information you need on running tasks.

#2: ln

To many administrators, links are an invaluable tool that not only make users lives simpler but also drastically reduce disk space usage. If you are unaware of how links can help you, let me pose this simple scenario: You have a number of users who have to access a large directory (filled with large files) on a drive throughout the day. The users are all on the same system, and you don't want to have to copy the entire directory to each user's ~/ directory. Instead, just create a link in each user's ~/ directory to the target. You won't consume space, and the users will have quick access. Of course when spanning drives, you will have to use symlinks. Another outstanding use for links is linking various directories to the Apache doc root directory. Not only can this save space, it's often advantageous from a security standpoint.

#3: tar/zip/gzip

Tar, zip, and gzip are archival/compression tools that make your administrator life far easier. I bundle these together because the tools can handle similar tasks yet do so with distinct differences (just not different enough to warrant their own entry in this article). Without these tools, installing from source would be less than easy. Without tar/zip/gzip, creating backups would require more space than you might often have.
One of the least used (but often most handy) features of these tools is the ability to extract single files from an archive. Now zip and gzip handle this more easily than tar. With tar, to extract a single file, you have to know the exact size of the file to be extracted. One area where tar/zip/gzip make administration simple is in creating shells scripts that automate a backup process. All three tools can be used with shell scripts and are, hands down, the best, most reliable backup tools you will find.

#4: nano, vi, emacs

I wasn't about to place just one text editor here, for fear of stoking the fires of the "vi vs. emacs" war. To top that off, I figured it was best to throw my favorite editor -- nano -- into the mix. Many people would argue that these aren't so much commands as they are full-blown applications. But all these tools are used within the command line, so I call them "commands." Without a good text editor, administering a Linux machine can become problematic.
Imagine having to attempt to edit /etc/fstab or /etc/samba/smb.conf with OpenOffice. Some might say this shouldn't be a problem, but OpenOffice tends to add hidden end-of-line characters to text files, which can really fubar a configuration file. For the editing of configuration or bash files, the only way to go is with an editor such as nano, vi, or emacs.

#5: grep

Many people overlook this amazingly useful tool. Grep prints lines that match a user-specified pattern. Say, for instance, that you are looking at an httpd.conf file that's more than 1,000 lines long, and you are searching for the "AccessFileName .htaccess" entry. You could comb through that file only to come across the entry at line 429, or you can issue the command grep -n "AccessFileName .htaccess" /etc/httpd/conf/http.conf. Upon issuing this command you will be returned "439:AccessFileName .htaccess" which tells you the entry you are looking for is on, surprise of all surprises, line 439.
The grep command is also useful for piping other commands to. An example of this is using grep with the ps command (which takes a snapshot of current running processes.) Suppose you want to know the PID of the currently crashed Firefox browser. You could issue ps aux and search through the entire output for the Firefox entry. Or you could issue the command ps aux|grep firefox, at which point you might see something like this:
jlwallen 17475  0.0  0.1   3604  1180 ?        Ss   10:54   0:00 /bin/sh /home/jwallen/firefox/firefoxjlwallen 17478  0.0  0.1   3660  1276 ?        S    10:54   0:00 /bin/sh /home/jlwallen/firefox/run-mozilla.sh /home/jlwallen/firefox/firefox-bin
jlwallen 17484 11.0 10.7 227504 97104 ?        Sl   10:54  11:50 /home/jlwallenfirefox/firefox-bin


jlwallen 17987  0.0  0.0   3112   736 pts/0    R+   12:42   0:00 grep --color firefox
Now you know the PIDs of every Firefox command running.

#6: chmod

Permissions anyone? Linux administration and security would be a tough job without the help of chmod. Imagine not being able to make a shell script executable with chmod u+x filename. Of course it's not just about making a file executable. Many Web tools require certain permissions before they will even install. To this end, the command chmod -R 666 DIRECTORY/ is one very misused command. Many new users, when faced with permissions issues trying to install an application, will jump immediately to 666 instead of figuring out exactly what permissions a directory or folder should have.
Even though this tool is critical for administration, it should be studied before jumping in blindly. Make sure you understand the ins and outs of chmod before using it at will. Remember w=write, r=read, and x=execute. Also remember UGO or User, Group, and Other. UGO is a simple way to remember which permissions belong to whom. So permission rw- rw- rw- means User, Group, and Other all have read and write permissions. It is always best to keep Other highly restricted in their permissions.

#7: dmesg

Call me old-school if you want, but any time I plug a device into a Linux machine, the first thing I do is run the dmesg command. This command displays the messages from the kernel buffer. So, yeah, this is an important one. There is a lot of information to be garnered from the dmesg command. You can find out system architecture, gpu, network device, kernel boot options used, RAM totals, etc.
A nice trick is to pipe dmesg to tail to watch any message that comes to dmesg. To do this, issue the command dmesg | tail -f and the last few lines of dmesg will remain in your terminal. Every time a new entry arrives it will be at the bottom of the "tail." Keep this window open when doing heavy duty system administration or debugging a system.

#8: kill/killall

One of the greatest benefits of Linux is its stability. But that stability doesn't always apply to applications outside the kernel. Some applications can actually lock up. And when they do, you want to be able to get rid of them. The quickest way to get rid of locked up applications is with the kill/killall command. The difference between the two commands is that kill requires the PID (process ID number) and killall requires only the executable name.
Let's say Firefox has locked up. To kill it with the kill command you would first need to locate the PID using the command ps aux|grep firefox command. Once you got the PID, you would issue kill PID (Where PID is the actual PID number). If you didn't want to go through finding out the PID, you could issue the command killall firefox (although in some instances it will require killall firefox-bin). Of course, kill/killall do not apply (nor should apply) to daemons like Apache, Samba, etc.

#9: man

How many times have you seen "RTFM"? Many would say that acronym stands for "Read the Fine* Manual" (*This word is open for variation not suitable for publication.) In my opinion, it stands for "Read the Fine Manpage." Manpages are there for a reason -- to help you understand how to use a command. Manpages are generally written with the same format, so once you gain an understanding of the format, you will be able to read (and understand) them all. And don't underestimate the value of the manpage. Even if you can't completely grasp the information given, you can always scroll down to find out what each command argument does. And the best part of using manpages is that when someone says "RTFM" you can say I have "RTFMd."

#10: mount/umount

Without these two commands, using removable media or adding external drives wouldn't happen. The mount/umount command is used to mount a drive (often labeled like /dev/sda) to a directory in the Linux file structure. Both mount and umount take advantage of the /etc/fstab file, which makes using mount/umount much easier. For instance, if there is an entry in the /etc/fstab file for /dev/sda1 that maps it to /data, that drive can be mounted with the command mount /data. Typically mount/umount must have root privileges (unless fstab has an entry allowing standard users to mount and unmount the device). You can also issue the mount command without arguments and you will see all drives that are currently mounted and where they're mapped to (as well as the type of file system and the permissions).

Linux File security

The Linux security model is based on the one used on UNIX systems, and is as rigid as the UNIX security model (and sometimes even more), which is already quite robust. On a Linux system, every file is owned by a user and a group user. There is also a third category of users, those that are not the user owner and don't belong to the group owning the file. For each category of users, read, write and execute permissions can be granted or denied.
We already used the long option to list files using the ls -l command, though for other reasons. This command also displays file permissions for these three user categories; they are indicated by the nine characters that follow the first character, which is the file type indicator at the beginning of the file properties line. As seen in the examples below, the first three characters in this series of nine display access rights for the actual user that owns the file. The next three are for the group owner of the file, the last three for other users. The permissions are always in the same order: read, write, execute for the user, the group and the others. Some examples:

marise:~> ls -l To_Do
-rw-rw-r--    1 marise  users      5 Jan 15 12:39 To_Do
marise:~> ls -l /bin/ls
-rwxr-xr-x    1 root    root   45948 Aug  9 15:01 /bin/ls*
The first file is a regular file (first dash). Users with user name marise or users belonging to the group users can read and write (change/move/delete) the file, but they can't execute it (second and third dash). All other users are only allowed to read this file, but they can't write or execute it (fourth and fifth dash).
The second example is an executable file, the difference: everybody can run this program, but you need to be root to change it.
The Info pages explain how the ls command handles display of access rights in detail, see the section What information is listed.
Access mode codes
CodeMeaning
0 or -The access right that is supposed to be on this place is not granted.
4 or rread access is granted to the user category defined in this place
2 or wwrite permission is granted to the user category defined in this place
1 or xexecute permission is granted to the user category defined in this place
User group codes
CodeMeaning
uuser permissions
ggroup permissions
opermissions for others
This straight forward scheme is applied very strictly, which allows a high level of security even without network security. Among other functions, the security scheme takes care of user access to programs, it can serve files on a need-to-know basis and protect sensitive data such as home directories and system configuration files.
You should know what your user name is. If you don't, it can be displayed using the id command, which also displays the default group you belong to and eventually other groups of which you are a member:

tilly:~> id
uid=504(tilly) gid=504(tilly) groups=504(tilly),100(users),2051(org)
Your user name is also stored in the environment variable USER:

tilly:~> echo $USER
tilly

chmod command

A normal consequence of applying strict file permissions, and sometimes a nuisance, is that access rights will need to be changed for all kinds of reasons. We use the chmod command to do this, and eventually to chmod has become an almost acceptable English verb, meaning the changing of the access mode of a file. The chmod command can be used with alphanumeric or numeric options, whatever you like best.
The example below uses alphanumeric options in order to solve a problem that commonly occurs with new users:

asim:~> ./hello
bash: ./hello: bad interpreter: Permission denied

asim:~> cat hello
#!/bin/bash
echo "Hello, World"

asim:~> ls -l hello
-rw-rw-r--    1 asim    asim    32 Jan 15 16:29 hello

asim:~> chmod u+x hello

asim:~> ./hello
Hello, World

asim:~> ls -l hello
-rwxrw-r--   1 asim    asim    32 Jan 15 16:29 hello*
The + and - operators are used to grant or deny a given right to a given group. Combinations separated by commas are allowed. The Info and man pages contain useful examples. Here's another one, which makes the file from the previous example a private file to user asim:

asim:~> chmod u+rwx,go-rwx hello

asim:~> ls -l hello
-rwx------    1 asim    asim    32 Jan 15 16:29 hello*
The kind of problem resulting in an error message saying that permission is denied somewhere is usually a problem with access rights in most cases. Also, comments like, "It worked yesterday," and "When I run this as root it works," are most likely caused by the wrong file permissions.
When using chmod with numeric arguments, the values for each granted access right have to be counted together per group. Thus we get a 3-digit number, which is the symbolic value for the settings chmod has to make.
File protection with chmod
CommandMeaning
chmod 400 fileTo protect a file against accidental overwriting.
chmod 500 directoryTo protect yourself from accidentally removing, renaming or moving files from this directory.
chmod 600 fileA private file only changeable by the user who entered this command.
chmod 644 fileA publicly readable file that can only be changed by the issuing user.
chmod 660 fileUsers belonging to your group can change this file, others don't have any access to it at all.
chmod 700 fileProtects a file against any access from other users, while the issuing user still has full access.
chmod 755 directoryFor files that should be readable and executable by others, but only changeable by the issuing user.
chmod 775 fileStandard file sharing mode for a group.
chmod 777 fileEverybody can do everything to this file.
If you enter a number with less than three digits as an argument to chmod, omitted characters are replaced with zeros starting from the left. There is actually a fourth digit on Linux systems, that precedes the first three and sets special access modes. Everything about these and many more are located in the Info pages.

Logging on to another group

When you type id on the command line, you get a list of all the groups that you can possibly belong to, preceded by your user name and ID and the group name and ID that you are currently connected with. However, on many Linux systems you can only be actively logged in to one group at the time. By default, this active or primary group is the one that you get assigned from the /etc/passwd file. The fourth field of this file holds users' primary group ID, which is looked up in the /etc/group file. An example:

asim:~> id
uid=501(asim) gid=501(asim) groups=100(users),501(asim),3400(web)

asim:~> grep asim /etc/passwd
asim:x:501:501:Asim El Baraka:/home/asim:/bin/bash

asim:~> grep 501 /etc/group
asim:x:501:
The fourth field in the line from /etc/passwd contains the value "501", which represents the group asim in the above example. From /etc/group we can get the name matching this group ID. When initially connecting to the system, this is the group that asim will belong to.
NoteUser private group scheme
In order to allow more flexibility, most Linux systems follow the so-called user private group scheme, that assigns each user primarily to his or her own group. This group is a group that only contains this particular user, hence the name "private group". Usually this group has the same name as the user login name, which can be a bit confusing.
Apart from his own private group, user asim can also be in the groups users and web. Because these are secondary groups to this user, he will need to use the newgrp to log into any of these groups (use gpasswd for setting the group password first). In the example, asim needs to create files that are owned by the group web.

asim:/var/www/html> newgrp web

asim:/var/www/html> id
uid=501(asim) gid=3400(web) groups=100(users),501(asim),3400(web)
When asim creates new files now, they will be in group ownership of the group web instead of being owned by the group asim:

asim:/var/www/html> touch test

asim:/var/www/html> ls -l test
-rw-rw-r--  1 asim web   0 Jun 10 15:38 test
Logging in to a new group prevents you from having to use chown (see Section 3.4.2.4) or calling your system administrator to change ownerships for you.
See the manpage for newgrp for more information.

file mask

When a new file is saved somewhere, it is first subjected to the standard security procedure. Files without permissions don't exist on Linux. The standard file permission is determined by the mask for new file creation. The value of this mask can be displayed using the umask command:

bert:~> umask
0002
Instead of adding the symbolic values to each other, as with chmod, for calculating the permission on a new file they need to be subtracted from the total possible access rights. In the example above, however, we see 4 values displayed, yet there are only 3 permission categories: user, group and other. The first zero is part of the special file attributes settings, which we will discuss in Section 3.4.2.4 and Section 4.1.6. It might just as well be that this first zero is not displayed on your system when entering the umask command, and that you only see 3 numbers representing the default file creation mask.
Each UNIX-like system has a system function for creating new files, which is called each time a user uses a program that creates new files, for instance, when downloading a file from the Internet, when saving a new text document and so on. This function creates both new files and new directories. Full read, write and execute permission is granted to everybody when creating a new directory. When creating a new file, this function will grant read and write permissions for everybody, but set execute permissions to none for all user categories. This, before the mask is applied, a directory has permissions 777 or rwxrwxrwx, a plain file 666 or rw-rw-rw-.
The umask value is subtracted from these default permissions after the function has created the new file or directory. Thus, a directory will have permissions of 775 by default, a file 664, if the mask value is (0)002. This is demonstrated in the example below:

bert:~> mkdir newdir

bert:~> ls -ld newdir
drwxrwxr-x    2 bert    bert  4096 Feb 28 13:45 newdir/

bert:~> touch newfile

bert:~> ls -l newfile
-rw-rw-r--    1 bert    bert     0 Feb 28 13:52 newfile
NoteFiles versus directories
A directory gets more permissions by default: it always has the execute permission. If it wouldn't have that, it would not be accessible. Try this out by chmodding a directory 644!
If you log in to another group using the newgrp command, the mask remains unchanged. Thus, if it is set to 002, files and directories that you create while being in the new group will also be accessible to the other members of that group; you don't have to use chmod.
The root user usually has stricter default file creation permissions:

[root@estoban root]# umask
022
These defaults are set system-wide in the shell resource configuration files, for instance /etc/bashrc or /etc/profile. You can change them in your own shell configuration file, see Chapter 7 on customizing your shell environment.

Changing user and group ownership

When a file is owned by the wrong user or group, the error can be repaired with the chown (change owner) and chgrp (change group) commands. Changing file ownership is a frequent system administrative task in environments where files need to be shared in a group. Both commands are very flexible, as you can find out by using the --help option.
The chown command can be applied to change both user and group ownership of a file, while chgrp only changes group ownership. Of course the system will check if the user issuing one of these commands has sufficient permissions on the file(s) she wants to change.
In order to only change the user ownership of a file, use this syntax:
chown newuser file
If you use a colon after the user name (see the Info pages), group ownership will be changed as well, to the primary group of the user issuing the command. On a Linux system, each user has his own group, so this form can be used to make files private:

jacky:~> id
uid=1304(jacky) gid=(1304) groups=1304(jacky),2034(pproject)

jacky:~> ls -l my_report
-rw-rw-r--  1 jacky   project       29387 Jan 15 09:34 my_report

jacky:~> chown jacky: my_report

jacky:~> chmod o-r my_report

jacky:~> ls -l my_report
-rw-rw----  1 jacky   jacky         29387 Jan 15 09:34 my_report
If jacky would like to share this file, without having to give everybody permission to write it, he can use the chgrp command:

jacky:~> ls -l report-20020115.xls
-rw-rw---- 1 jacky   jacky   45635 Jan 15 09:35 report-20020115.xls

jacky:~> chgrp project report-20020115.xls

jacky:~> chmod o= report-20020115.xls

jacky:~> ls -l report-20020115.xls
-rw-rw---- 1 jacky   project 45635 Jan 15 09:35 report-20020115.xls
This way, users in the group project will be able to work on this file. Users not in this group have no business with it at all.
Both chown and chgrp can be used to change ownership recursively, using the -R option. In that case, all underlying files and subdirectories of a given directory will belong to the given user and/or group.
NoteRestrictions
On most systems, the use of the chown and chgrp commands is restricted for non-privileged users. If you are not the administrator of the system, you can not change user nor group ownerships for security reasons. If the usage of these commands would not be restricted, malicious users could assign ownership of files to other users and/or groups and change behavior of those users' environments and even cause damage to other users' files.

Special modes

For the system admin to not be bothered solving permission problems all the time, special access rights can be given to entire directories, or to separate programs. There are three special modes:
  • Sticky bit mode: After execution of a job, the command is kept in the system memory. Originally this was a feature used a lot to save memory: big jobs are loaded into memory only once. But these days memory is inexpensive and there are better techniques to manage it, so it is not used anymore for its optimizing capabilities on single files. When applied to an entire directory, however, the sticky bit has a different meaning. In that case, a user can only change files in this directory when she is the user owner of the file or when the file has appropriate permissions. This feature is used on directories like /var/tmp, that have to be accessible for everyone, but where it is not appropriate for users to change or delete each other's data. The sticky bit is indicated by a t at the end of the file permission field:

    mark:~> ls -ld /var/tmp
    drwxrwxrwt   19 root     root         8192 Jan 16 10:37 /var/tmp/
    
    The sticky bit is set using the command chmod o+t directory. The historic origin of the "t" is in UNIX' save Text access feature.
  • SUID (set user ID) and SGID (set group ID): represented by the character s in the user or group permission field. When this mode is set on an executable file, it will run with the user and group permissions on the file instead of with those of the user issuing the command, thus giving access to system resources. We will discuss this further in Chapter 4.
  • SGID (set group ID) on a directory: in this special case every file created in the directory will have the same group owner as the directory itself (while normal behavior would be that new files are owned by the users who create them). This way, users don't need to worry about file ownership when sharing directories:

    mimi:~> ls -ld /opt/docs
    drwxrws---  4 root    users          4096 Jul 25 2001 docs/
    
    mimi:~> ls -l /opt/docs
    -rw-rw----  1 mimi    users        345672 Aug 30 2001-Council.doc