Identifying a Hard Disk Using hdparm

When working with hard disks it is sometimes difficult to determine which piece of hardware corresponds to which Linux device. The hdparm command can provide identifying information to tie the physical drive to the device file in /dev. For example to find the Model and Serial Number of all /dev/sdX devices present on the system:

# hdparm -I /dev/sd?|grep -E "Number|/dev"
/dev/sda:
        Model Number:       HDS722516VLSA80                         
        Serial Number:      VN6D3ECDD7RG1D
/dev/sdb:
        Model Number:       WDC WD740GD-00FLA1                      
        Serial Number:      WD-WMAKE1690676
/dev/sdc:
        Model Number:       HDS722525VLSA80                         
        Serial Number:      VN6J3ECFEALJRD
/dev/sdd:
        Model Number:       HDS722525VLSA80                         
        Serial Number:      VN6J3ECFEBSR1D

Note: Not all drives work with hdparm. Some may give an error

HDIO_DRIVE_CMD(identify) failed: Invalid argument

rpm command cheat sheet for Linux

rpm command cheat sheet for Linux

rpm is a powerful Package Manager for Red Hat, Suse and Fedora Linux. It can be used to build, install, query, verify, update, and remove/erase individual software packages. A Package consists of an archive of files, and package information, including name, version, and description:

Syntax	Description	Example(s)
rpm -ivh {rpm-file}	Install the package	rpm -ivh mozilla-mail-1.7.5-17.i586.rpm rpm -ivh --test mozilla-mail-1.7.5-17.i586.rpm
rpm -Uvh {rpm-file}	Upgrade package	rpm -Uvh mozilla-mail-1.7.6-12.i586.rpm rpm -Uvh --test mozilla-mail-1.7.6-12.i586.rpm
rpm -ev {package}	Erase/remove/ an installed package	rpm -ev mozilla-mail
rpm -ev --nodeps {package}	Erase/remove/ an installed package without checking for dependencies	rpm -ev --nodeps mozilla-mail
rpm -qa	Display list all installed packages	rpm -qa rpm -qa | less
rpm -qi {package}	Display installed information along with package version and short description	rpm -qi mozilla-mail
rpm -qf {/path/to/file}	Find out what package a file belongs to i.e. find what package owns the file	rpm -qf /etc/passwd rpm -qf /bin/bash
rpm -qc {pacakge-name}	Display list of configuration file(s) for a package	rpm -qc httpd
rpm -qcf {/path/to/file}	Display list of configuration files for a command	rpm -qcf /usr/X11R6/bin/xeyes
rpm -qa --last	Display list of all recently installed RPMs	rpm -qa --last rpm -qa --last | less
rpm -qpR {.rpm-file} rpm -qR {package}	Find out what dependencies a rpm file has	rpm -qpR mediawiki-1.4rc1-4.i586.rpm rpm -qR bash

{package} - Replace with actual package name

Installing Squid Guard

Installing squidGuard

Unpack the source  tar xvzf squidGuard-1.2.1.tar.gz Compiling Let's assume it is squidGuard-1.2.1 we are trying to install:  cd squidGuard-1.2.1 ./configure make If no errors occurred squidGuard is now installed in /usr/local/. There are a couple of option you can use when running ./configure. For example: Installing in a different location  ./configure --prefix=/some/other/directory BerkeleyDB not in /usr/local/BerkeleyDB installed  ./configure  --with-db=/directory/of/BerkeleyDB/installation When installed from the sources the BerkeleyDB will be located in /usr/local/BerkeleyDBx.y with x.y denoting the version number. Annotation: Make sure that the shared library of your BerkeleyDB installation is known by your system (check /etc/ld.so.conf, add your BerkeleyDB library path if it is not already there and run ldconfig). See all ./configure options  ./configure --help Installing  su - make install Installing the blacklists Copy your blacklists into the desired blacklist directory (default: /usr/local/squidGuard/db) and unpack them. In the table below we assume that the default location is used. Make sure that you have the proper permissions to write to that directory.  cp /path/to/your/blacklist.tar.gz /usr/local/squidGuard/db cd /usr/local/squidGuard/db gzip -d blacklist.tar.gz tar xfv blacklist.tar Now the blacklists should be ready to use. Congratulation. You have just completed the installation of squidGuard. The next step is to configure the software according to your needs. After this you should verify your installation before you finally modify your squid configuration to work with squidGuard.

Once SquidGuard is successfully installed, you want to configure the software according to your needs. A sample configuration has been installed in the default directory  /usr/local/squidGuard (or whatever directory you pointed your installation to).
Below you find three examples for the basic configuration of SquidGuard.

1. Most simple configuration

Most simple config uration: one category, one rule for all

# # CONFIG FILE FOR SQUIDGUARD #   dbhome /usr/local/squidGuard/db logdir /usr/local/squidGuard/logs   dest porn {         domainlist porn/domains         urllist porn/urls         }   acl {         default {                pass !porn all                 redirect http://localhost/block.html         } }

2. 
   
   Make always sure that the very first line of your squidGuard.conf is not empty!
   The entries have the following meaning:

dbhome	Location of the blacklists
logdir	Location of the logfiles
dest	Definition of a category to block. You can enter the domain and url file along with a regular expression list (talk about regular expressions later on).
acl	The actual blocking defintion. In our example only the default is displayed. You can have more than one acl in place. The category porn you defined in dest is blocked by the expression !porn. You have to add the identifier all after the blocklist or your users will not be able to surf anyway. The redirect directive is madatory! You must tell SquidGuard which page to display instead of the blocked one.

3.  
4. Choosing more than one category to block
   
   First you define your categories. Just like you did above for porn. For example:

Defining three categories for blocking

dest adv {         domainlist      adv/domains         urllist         adv/urls } dest porn {         domainlist      porn/domains         urllist         porn/urls } dest warez {         domainlist      warez/domains         urllist         warez/urls }

5. 
   
   Now your acl looks like that:

acl {         default {                 pass    !adv !porn !warez all                 redirect http://localhost/block.html                 } }

6.  
7. Whitelisting
   
   Sometimes there is a demand to allow specific URLs and domains although they are part of the blocklists for a good reason. In this case you want to whitelist these domains and URLs.

Defining a whitelist

dest white {         domainlist      white/domains         urllist         white/urls }   acl {         default {                 pass    white !adv !porn !warez all                 redirect http://localhost/block.html                 } }

8. 
   
   In this example we assumed that your whitelists are located in a directory called white whithin the blacklist directory you specified with dbhome.
   Make sure that your white identifier is the first in the row of the pass directive. It must not have an exclamation mark in front (otherwise all entries belonging to white will be blocked, too).
9. Initializing the blacklists
   
   Before you start up your squidGuard you should initialize the blacklists i.e. convert them from the textfiles to db files. Using the db format will speed up the checking and blocking.
   The initialization is performed by the following command:

Initializing the b lacklists

squidGuard -C all chown -R <squiduser> /usr/local/squidGuard/db/*

10. 
    
    The second command ensures that your squid is able to access the blacklists. Please for <squiduser> the uid of your squid.
    Depending on the size of your blacklists and the power of your computer this may take a while. If anything is running fine you should see something like the following output in your logfile:

2006-01-29 12:16:14 [31977] squidGuard 1.2.0p2 started (1138533256.959) 2006-01-29 12:16:14 [31977] db update done 2006-01-29 12:16:14 [31977] squidGuard stopped (1138533374.571)

11. 
    
    If you look into the directories holding the files domains and urls you see that additional files have been created: domains.db and urls.db. These new files must not be empty!
    Only those files are converted you specified to block or whitelist in your squidGuard.conf file.

Verification of your squidGuard Configuration

Now that you have installed and configured your squidGuard you just check a couple of things before going online. Permissions Ensure that the blacklist and db files belong to your squid user. If squid cannot access (or modify) them blocking will not work. SquidGuard dry-run To verify that your configuration is working run the following command (changed to reflect your configuration): Dry-run squidGuard echo "http://www.example.com 10.0.0.1/ - - GET" | squidGuard -c /tmp/test.cfg -d If the redirector works properly you should see the redirection URL for the blocked site. For sites not being part of your blacklists the output should end with: 2007-03-25 16:18:05 [30042] squidGuard ready for requests (1174832285.085)   2007-03-25 16:18:05 [30042] squidGuard stopped (1174832285.089) Some remarks about the different entries of the echoed line: The first entry is the URL you want to test. The second entry is the client IP address. If you configured access control based on IP addresses make sure to test allowed and not allowed IP addresses to ensure proper working. In the third entry (the first - ) you can specify a username. This is only of importance if you have access control based on user names. Make sure to check different names with different access to verify your configuration. Finalizing the installation by configuring squid If everything is working properly add the following line to your squid.conf (assuming that your squidGuard is installed in /usr/local; make sure to change the paths to match your installation accordingly):  url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf

HOW TO Install HP Data Protector 5.5 on Linux

 

HOW TO Install HP Data Protector 5.5 on Linux

Contents

This manual describes the install of HP Data Protector 5.5 Core component, Disk Agent and Media Agent on a Linux server. In this manual the backup server is backupserver.demo.local and the linux server is linuxserver.demo.local

Background

The HP Data Protector 5.5 suite does not contain a simple installation for Linux Agents, therefore this manual is necessary.

This manual uses:

-          hp OpenView Storage Data Protector 5.5 for HP-UX 11.23 IA-64 cdrom

-          Enterprise Linux / CentOS installation on server (linuxserver.demo.local)

-          ncompress-4.2.4-41.rhel4.x86_64.rpm

-          putty and winscp

Please check these components before continuing installation.

Install

1. Use winscp in binary mode to copy DP_A0550_UXia64_IS.sd_depot from the cdrom to /var/tmp on the linux server
2. Connect to the linux server with putty.
3. Logon with root credentials
4. type vi /etc/hosts
• add 10.10.10.10 backupserver.demo.local to the hosts file
5. type cd /var/tmp
• go to dir where depot file remains
6. type tar -xvf DP_A0550_UXia64_IS.sd_depot
• extract the depot file
7. type mkdir /tmp/omni_tmp
• create a temporary installation location
8. type cd /tmp/omni_tmp
• go there
9. type tar -xvf /var/tmp/DATA-PROTECTOR/OMNI-CORE-IS/opt/omni/databases/utils/gpl/i386/linux-60/utils.tar omni_rinst.sh

·         extract the omni installer from utils to the temp install location

10. type cp /var/tmp/DATA-PROTECTOR/OMNI-CORE-IS/opt/omni/databases/vendor/omnicf/gpl/i386/linux-60/A.05.50/packet.Z /tmp/omni_tmp
• copy the core component to the temp install location
11. type ./omni_rinst.sh /tmp/omni_tmp/packet.Z co a.05.50 gpl/i386/linux-60 /usr/omni backupserver.demo.local
• install the core component
• the packet.Z file is removed after installation
• you’ll get an error message like ‘Warning: Update of the omni_info file failed for co! Omniback II software package successfully installed !’ but that’s ok.
12. type cp /var/tmp/DATA-PROTECTOR/OMNI-OTHUX-P/opt/omni/databases/vendor/da/gpl/i386/linux-60/A.05.50/packet.Z /tmp/omni_tmp
• copy the disk agent component to the temp installation location
13. type ./omni_rinst.sh /tmp/omni_tmp/packet.Z da a.05.50 gpl/i386/linux-60 /usr/omni backupserver.demo.local
• install the disk agent component
14. type cp /var/tmp/DATA-PROTECTOR/OMNI-OTHUX-P/opt/omni/databases/vendor/ma/gpl/i386/linux-60/A.05.50/packet.Z /tmp/omni_tmp
• copy the media agent component to the temp install location
15. type ./omni_rinst.sh /tmp/omni_tmp/packet.Z ma a.05.50 gpl/i386/linux-60 /usr/omni backupserver.demo.local
• install the media agent component
16. type vi /etc/services
• go to the bottom of the file add the portnumber 5555 to the omni service like omni  5555/tcp     # DATA-PROTECTOR
17. type service xinetd restart
• restart xinetd so that omni will start
18. Add client to the HP Data Protector Storage Manager by doing a import client…

Crazy Commands

 Crazy Commands:

1. Another wonder of a simple shell variable is !$. Let’s say you have to create a directory, go into it and then rename it. So the flow of commands would be:

$ mkdir your_dir

$ mv your_dir my_dir

$ cd my_dir

Remedy: Well, Linux has a shorter and quicker way:

$ mkdir your_dir

$ mv !$ my_dir

$ cd !$

!$ points to the last string in the command string. This is useful in various scenarios where the last word of command string is to be used in subsequent commands (almost with all Linux commands like vi, tar, gzip, etc).

2. Do you want to know what an ls or a date command does internally? Just run the following code to get to know the basic block of any Linux command:

$ strace -c /usr/bin/ls

strace is a system call monitor command and provides information about system calls made by an application, including the call arguments and return value.

3. What if you want to create a chain of directories and sub-directories, something like /tmp/our/your/mine?

$ mkdir -p /tmp/our/your/mine

4. One very interesting way to combine some related commands is with &&.

$ cd dir_name && ls -alr && cd ..

5. Now for some fun! Have you ever tried checking the vulnerability of your Linux system? Try a fork-bomb to evaluate this:

$ :(){ :|: & };:

It’s actually a shell function; look closely and it’s an unnamed function :() with the body enclosed in {}. The statement ‘:|:’ makes a call to the function itself and pipes the output to another function calls—thus we are calling the function twice. & puts all processes in the background and hence you can’t kill any process. Finally ‘;’ completes the function definition and the last ‘:’ initiates a call to this unnamed function. So it recursively creates processes and eventually your system will hang. This is one of the most dangerous Linux commands and may cause your computer to crash!
Remedy: How to avoid a fork bomb? Of course, by limiting the process limit; you need to edit /etc/security/limits.conf. Edit the variable nproc to user_name hard nproc 100. You require root privileges to modify this file.

  One more dirty way to hack into the system is through continuous reboots, resulting in the total breakdown of a Linux machine. Here’s an option that you need root access for. Edit the file /etc/inittab and modify the line id:5:initdefault: to id:6:initdefault:. That’s all! Linux specifies various user modes and 6 is intended for reboot. Hence, your machine keeps on rebooting every time it checks for the default user mode.
Remedy: Modify your Grub configuration (the Linux bootloader) and boot in single user mode. Edit the file /etc/inittab and change the default user level to 5.

Postfix Configuration

MTP

SMTP is an acronym for Simple Mail Transport Protocol. This is the protocol used by the email systems to transfer mail messages from one server to another. This protocol is essentially the communications language that the MTAs use to talk to each other and transfer messages back and forth.

Configuring an RHEL Email System

Many systems use the Sendmail MTA to transfer email messages and on many Linux distributions this is the default Mail Transfer Agent. Sendmail is, however, a complex system that can be difficult for beginner and experienced user alike to understand and configure. It is also falling from favor because it is considered to be slower at processing email messages than many of the more recent MTAs available.
Many system administrators are now using Postfix or Qmail to handle email. Both are faster and easier to configure than Sendmail. For the purposes of this chapter, therefore, we will look at Postfix as an MTA because of its simplicity and popularity. If you would prefer to use Sendmail there are many books that specialize in the subject and that will do the subject much more justice than we can in this chapter.

Postfix Pre-Installation Steps

The first step before installing Postfix is to make sure that Sendmail is not already running on your system. You can check for this using the following command:

/sbin/service sendmail status

If sendmail is not running the following output will be displayed:

sendmail is stopped

If sendmail is running you will see the following:

sendmail (pid 2138) is running 

If sendmail is running on your system it is necessary to stop it before installing and configuring Postfix. To stop sendmail run the following command as super user:

/sbin/service sendmail stop

The next step is to ensure that sendmail does not get restarted automatically when the system is rebooted. The first step is to find out which run levels will automatically start sendmail. To do this we can use the chkconfig command-line tool as follows:

/sbin/chkconfig --list | grep sendmail

The above command will typically result in output similar to:

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

This means that if the system boots into runlevels 2, 3, 4 or 5 then the sendmail service will automatically start. To turn off sendmail we can once again use the chkconfig command as follows:

/sbin/chkconfig sendmail off

The chkconfig tool defaults to changing the settings for runlevels 2, 3, 4 and 5. You can configure for specific runlevels using the –levels command line option if necessary.
To verify the settings run chkconfig one more time as follows:

/sbin/chkconfig --list | grep sendmail

And check that the output is as follows:

sendmail        0:off  1:off   2:off   3:off  4:off   5:off   6:off

Sendmail is now switched off and configured so that it does not auto start when the system is booted. We can now move on to installing Postfix.

Installing Postfix on RHEL

By default, the RHEL installation process does not install Postfix. To verify if Postfix is already installed, use the following rpm command in a Terminal window:

rpm -q postfix

If rpm reports that postfix is not installed, it may be installed as follows:

su -

yum install postfix

The yum tool will download and install postfix, and configure a special postfix user in the /etc/passwd file.

Configuring Postfix

The main configuration settings for Postfix are located in the /etc/postfix/main.cf file. There are many resources on the internet that provide detailed information on Postfix so this section will focus on the basic options required to get email up and running.
The key options in the main.cf file are:

myhostname = mta1.domain.com

mydomain = domain.com

myorigin = $myhostname

inet_interfaces = $myhostname

Other settings will have either been set up for you by the installation process or are not needed unless you are feeling adventurous and want to configure a more sophisticated email system.
The format of myhostname is host.domain.extension. For example if your Linux system is called MyLinuxHost and your internet domain is MyDomain.com you would set the myhostname option as:

myhostname = mylinuxhost.mydomain.com

The mydomain setting is just the domain part of the above setting. For example:

mydomain = mydomain.com

The myorigin and inet_interfaces options use the settings we have just created so do not need to be changed (although the inet_interfaces may be commented out by default so you should remove the # at the beginning of this particular line in the main.cf file).

Starting Postfix on an RHEL System

Once the /etc/postfix/main.cf file is configured with the correct settings it is now time to start up postfix. This can be achieved from the command line as follows:

/usr/sbin/postfix start

The postfix process should now start up. The best way to check that everything is working is to check your mail log. This is typically in /var/log/maillog and should now contain an entry that looks like:

Nov 21 13:05:46 mylinuxhost postfix/postfix-script: starting the Postfix mail system Nov 21 13:05:46 mylinuxhost 

postfix/master[10334]: daemon started -- version 2.2.5, configuration /etc/postfix 

As long as you don't see any error messages you have successfully installed and started Postfix and you are ready to set up a mail client and start communicating with the outside world. 

To configure Postfix to start automatically at system startup, run the following command in a Terminal window:

/sbin/chkconfig --level 345 postfix on

Postfix Configuration

The following explanation is a step-by-step instruction on the sections that you need to modify in main.cf
Postfix offers a nice feature called SOFT BOUNCE, this feature can be used when you are working on an already setup mail server. When this feature is active the server will still queue messages during testing time.

Domain for Outbound mail

Sending Mail

Because we are using a domain name, uncomment the following line, and read ahead to create an alias database.

      myorigin = $mydomain

Domain for Inbound

Receive mail

Do not enable any interface, instead create a file called destination in /etc/postfix/destination and place the domain-name for the destination in that file. In the RECEIVING MAIL section, find the line:

 mydestination =  $myhostname, localhost.$mydomain, 

Edit this line to point to the destination file:

mydestination =$myhostname,localhost.$mydomain, /etc/postfix/mydestination 

Next edit the mydestination file and enter your domain-name(s):

[root@server2 postfix]# vi mydestination

      netcontrol.org 

      onetraining.net 

Create the Aliases

In the ALIAS DATABASE SECTION, uncomment the line:
Alias_maps = hash:/etc/postfix/aliases
Next execute the following command to create the database. Note that the database will be created in the directory /etc/postfix/
[root@server2 postfix]# postalias /etc/postfix/aliases
That's it. Restart postfix. You now should be able to send and receive email from your domain name.

Virtual Domains with Postfix

We have successfully configured the email server to send and receive email at the default domain (Primary domain), in this case netcontrol.org. All users in the system can send and receive email under netcontrol.org by default. If you already updated mydestination file and included other domains; that is not enough for virtual mail servers.
Since onetraining.net is a virtual domain in this example, I will use it to set the mail server in the virtual domains.

Configuring the virtual domain email server

Virtual Address Mapping

We need to go back and edit the main.cf file to set this virtual address. All users in each domain have to be able to receive and send email. And of course it has to get to its right destination.
To implement this, locate and insert:

# ADDRESS REDIRECTION (VIRTUAL DOMAIN)

# Insert text from sample-virtual.cf if you #need virtual domain support.

virtual_maps = hash:/etc/postfix/virtual_maps

Note that virtual_maps is hashed just like aliases, the next step is to create a file in /etc/postfix. Call it virtual_maps and include the virtual domains in it.

[root@server2 postfix]# vi virtual_maps

        onetraining.net                DOMAIN

        velasco@onetraining.net               velasco

In this file you will place all your users for the virtual domains, and after editing this file you have to create the database virtual_maps.db
At your command line (console) type the following:
[root@server2 postfix]# postmap virtual_maps < virtual_maps
Restart postfix and you are ready to go. Test the system with your user under the virtual domain, you should be able to receive and send email.

xinetd FAQ

Linux xinetd Super Server daemon

 

The Linux xinetd (Extended Internet Services) daemon, also known as the super server, controls many network services.

The xinetd service listens on all ports used by the daemons it controls. When a connection is requested, xinetd determines if the client is allowed access. If the client is allowed access, xinetd starts up the desired service and allows the client to connect.

The xinetd service listens for connection requests for all of the active servers with scripts in the /etc/xinetd.d directory. There's a generic configuration file for xinetd services, /etc/xinetd.conf. The scripts in the /etc/xinetd.d directory function as service-specific configuration files.

The xinetd rpm package should be installed to to use the xinetd super server.
The following command will install the xinetd super server.

[root@RHEL03 Server]# rpm -ivh xinetd-2.3.14-10.el5.i386.rpm
warning: xinetd-2.3.14-10.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...########################################### [100%]
1:xinetd…  ########################################### [100%]

To install telnet server, you should install the telnet-server rpm package after the installation of xinetd rpm package. The telnet-server rpm package can be installed by running the following command.

inetd Configuration files in /etc/xinetd.d folder

The files in the /etc/xinetd.d directory specify a particular service you want to allow xinetd to manage.
The following configuration (/etc/xinetd.d/telnet) file is related to the telnet server we have just installed.

# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
}

The following table is the description of different parameters used in xinetd file. Note that the "disable" parameter is set to yes, which disables the telnet server. If you want to enable the telnet server, this value should be "no".

Parameter	Description
flags	Supports different parameters for the service; REUSE is a default that supports continuous use of the service.
Options	include IPv6 to set this as a service for those types of networks.
socket_type	Specifies the communication stream.
wait	Set to yes for single-threaded applications or no for multithreaded applications.
User	Account under which the server should run.
Group	Group under which the server should run.
server	The server program.
only_from	Host name or IP address allowed to use the server.
no_access	Host name or IP address not allowed to use the server.
log_on_failure	Whether a failure should be logged
disable	By default, set to yes, which disables the service.

 

 

xinetd FAQ

---

What is xinetd

Is it compatible with inetd ?

Why should I use xinetd?

Who is responsible for xinetd?

What's up with xinetd 2.2.1?

I am not a system administrator; what do I care about an inetd replacement ?

Where can I get xinetd?

Has anyone gotten xinetd working with qmail?

What platforms does xinetd work on?

How do I use itox?

Does xinetd support tcpwrappers?

Does xinetd support IPv6?

No services start with IPv6! What's the deal?

What's this setgroups(0, NULL) error?

Why can't telnetd start normally on Linux?

How can I use xinetd to wrap SSL around services?

How do I setup a cvs server with xinetd?

---

Q. What is xinetd ?
A. xinetd is a replacement for inetd, the internet services daemon.

Q: I am not a system administrator; what do I care about an inetd replacement ?
A: xinetd is not just an inetd replacement. Anybody can use it to start servers that don't require privileged ports because xinetd does not require that the services in its configuration file be listed in /etc/services.

Q. Is it compatible with inetd ?
A. No, its configuration file has a different format than inetd's one and it understands different signals. However the signal-to-action assignment can be changed and a program has been included to convert inetd.conf to xinetd.conf.


Q. Why should I use it ?
A. Because it is a lot better (IMHO) than inetd. Here are the reasons:

1) It can do access control on all services based on:

a. address of remote host

b. time of access

c. name of remote host

d. domain name of remote host

2) Access control works on all services, whether multi-threaded or single-threaded and for both the TCP and UDP protocols. All UDP packets can be checked as well as all TCP connections.

3) It provides hard reconfiguration:

a. kills servers for services that are no longer in the configuration file

b. kills servers that no longer meet the access control criteria

4) It can prevent denial-of-access attacks by

a. placing limits on the number of servers for each service (avoids process table overflows)

b. placing an upper bound on the number of processes it will fork

c. placing limits on the size of log files it creates

d. placing limits on the number of connection a single host can initiate

e. place limits on the rate of incoming connections

f. discontinue services if the load exceeds specified limit

5) Extensive logging abilities:

a. for every server started it can log:

i) the time when the server was started

ii) the remote host address

iii) who was the remote user (if the other end runs a RFC-931/RFC-1413 server)

iv) how long the server was running

(i, ii and iii can be logged for failed attempts too).

b. for some services, if the access control fails, it can log information about the attempted access (for example, it can log the user name and command for the rsh service)

6) No limit on number of server arguments

7) You can bind specifc services to specific IP's on your host machine

Q. Whom should I thank/blame for this program ?
A. panos@cs.colorado.edu originally wrote this program, but I am fielding bug reports at this time.

Q. What's up with 2.2.1 version of xinetd?
A. The most recent original version of xinetd was 2.1.1 with patches bringing it up to 2.1.8. Nick Hilliard created xinetd 2.2.1, based off an unreleased xinetd 2.2.0 by Panos. The copyright included with xinetd specified the required versioning to be the official release of xinetd (2.1.8 in this case) and a fourth version number tacked on to indicate the modification level. This is the versioning I have adopted. xinetd 2.1.8.X, which is available here, is not based off xinetd 2.2.0 or higher. It was created from the codebase of xinetd 2.1.8, although I have re-implemented some of the features introduced in xinetd-2.2.1.

Q. Where can I find the latest-and-greatest version ?
A. The xinetd source can be obtained from http://www.synack.net/xinetd

Q. Has anyone been able to get qmail working with xinetd?
A. yes, here is the entry info

service smtp

{

        flags           = REUSE NAMEINARGS

        socket_type     = stream

        protocol        = tcp

        wait            = no

        user            = qmaild

        server          = /usr/sbin/tcpd

        server_args     = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd

}

Contributed by: Anthony Abby
This method will allow you to set environment variables and whatnot in /etc/hosts.allow. Although xinetd can be compiled with libwrap support, this doesn't mean it can completly replace tcpd's functionality. xinetd calls host_access(), which performs the access control documented in host_access(5) man page. This is a subset of the features offered by tcpd.

Q. What platforms is xinetd know to work on?
A. I have run it on Solaris 2.6 (sparc and x86), Linux, BSDi, and IRIX 5.3 and 6.2. The original package ran on SunOS 4 and Ultrix.

Q. How to do setup a chrooted environment for a service?
A. Here is the config file entry:

service telnet_chroot

{

        log_on_success  = HOST PID DURATION USERID

        log_on_failure         = HOST RECORD USERID

        no_access      = 152.30.11.93

        socket_type     = stream

        protocol        = tcp

        port           = 8000

        wait            = no

        user            = root

        server          = /usr/sbin/chroot

        server_args    = /var/public/servers /usr/libexec/telnetd

}

Contributed by: lburns@sasquatch.com

Q. How do I use itox?
A. itox reads in a regular inetd.conf file from stdin and writes an xinetd.conf file to stdout. In general, you use the command:
itox < /etc/inetd.conf > /etc/xinetd.conf
If your inetd.conf does not have explicit paths to each of the daemons, you must use the -daemon_dir option. Suppose all your daemons live in /usr/sbin, use the following command:
itox -daemon_dir=/usr/sbin < /etc/inetd.conf > /etc/xinetd.conf
itox is rather old and hasn't been updated for a while. xconv.pl is a perl script that is a little better about converting modern inetd.conf files. It's usage is similar to itox's.

Q. Does xinetd support libwrap (tcpwrappers)?
A. Yes. xinetd can be compiled with libwrap support by passing --with-libwrap as an option to the configure script. When xinetd is compiled with libwrap support, all services can use the /etc/hosts.allow and /etc/hosts.deny access control. xinetd can also be configured to use tcpd in the traditional inetd style. This requires the use of the NAMEINARGS flag, and the name of the real daemon be passed in as server_args. Here is an example for using telnet with tcpd:

service telnet

{

        flags       = REUSE NAMEINARGS

        protocol    = tcp

        socket_type = stream

        wait        = no

        user        = telnetd

        server      = /usr/sbin/tcpd

        server_args = /usr/sbin/in.telnetd

}

Q. Does xinetd support IPv6?
A. Yes. xinetd can be compiled with IPv6 support by adding the --with-inet6 option to the configure script. Access control is functional with IPv6. You can use ipv4 mapped addresses, or give normal dotted quad ipv4 addresses for access control, and xinetd will map them to ipv6 addresses.

Q. No services start with IPv6! What's the deal?
A. When you compile IPv6 support in, all sockets are IPv6 sockets. If your kernel doesn't understand what an IPv6 socket is, all attempts to create sockets will fail, and no services will start. Only compile xinetd with IPv6 support if your kernel supports IPv6.

Q. What's this setgroups(0, NULL) error?
A. By default, xinetd does not allow group permissions to the server processes, and it does this by setting the groups of the child process to nothing. Some BSD's have a problem with this. To avoid this error, put the directive groups = yes into your services. This says to allow the server process to have all the group privleges entitled to the user the server process is running as.

Q. Why can't telnetd start normally on Linux?
A. On some Linux distributions, the telnet daemon starts as a nonprivleged user, but the user belongs to groups that allow it to open new tty's, and to update utmp. By default, xinetd does not allow group permissions to the server process, so telnetd can fail to start properly. To get the server process to posess the proper groups, use the groups = yes directive for the telnet service. This will tell xinetd that it is OK for the server process to start with all the groups the user has access to.

Q. How do I use xinetd to wrap SSL around services
A. Use the program stunnel to wrap SSL around services. This can actually be used by an inetd.

Q. How do I setup a cvs server with xinetd?
A. A user wrote in with this suggestion:

cvspserver  stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/pauljohn/cvsroot  --allow-root=/home/pauljohn/cvsmisc pserver

If you want to make the same work under xinetd, you save a config file in /etc/xinetd.d called cvspserver, (where the last line tells it the names of your repositories):

service cvspserver

{

        socket_type         = stream

        protocol            = tcp

        wait                = no

        user                = root

        passenv             = 

        server              = /usr/bin/cvs

        server_args         = --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver -f

}

All the other cvs setup stuff is the same. This seems to work, afaik.