Ok, I appreciate everyone's responses. There is definitely a lot of
misunderstanding of xinetd, unfortunately. It is encouraging, however, to
find out that there are working configurations out there with xinetd, but
it's also more confusing now as to why my configuration does not work. I do
have breakthrough at the end of this email.
I'll try to address everyone's comments:
xinetd.conf is the main configuration file for xinetd. You can define any
number of services in this file. Many distributions of xinetd (i.e.
redhat's, mandrake's) include in xinetd.conf the line "includedir
/etc/xinetd.d". This is a bash/POSIX-style directory source command. Every
file in the directory /etc/xinetd.d is read in as an extension of the
xinetd.conf configuration file. They are treated identically. Package-based
distributions often use this because it is easy for a package to drop an
additional configuration file into this directory when it is installed. In
addition, it's a useful way to organize xinetd configurations.
The default value for the disable attribute for a service in xinetd is _NO_
unless it is specified in the "disabled" global flag. Specifying disable =
no is usually redundant and unneeded, but often used by distributions (i.e.
redhat, mandrake) so that scripts like chkconfig can more easily toggle the
service on and off.
In inetd.conf, the final parameter is the server program arguments starting
with argv[0]. This means that the first argument is actually allowing an
administrator to set the name of the process in a "ps" listing, etc.
Following that first argument are the actual parameters for the program. In
xinetd.conf, the server program arguments are specified with the
"server_args" flag. xinetd.conf does NOT allow you to set argv[0]. From the
xinetd.conf man page, "in contrast to inetd, the server name should not be
included in server_args." As far as I can tell, amandad, amindexd, and
amidxtaped take no parameters, therefore, the server_args flag should be
left blank for all three services.
The "groups" flag in xinetd.conf allows an administrator to toggle whether
the process gains access to its user's allowed groups (as defined in
/etc/group). In many cases, the amanda services belong to several groups
such as backup and disk, therefore, this parameter should be set to "yes"
in most configurations. It can also be set in the global configuration
section.
For more information, please refer to the inetd.conf and xinetd.conf man
pages (although I have found the xinetd.conf man page is often out of
date).
---
Now, back to my problem. xinetd is showing no errors for any of my
Amanda-related services. To prove it, here is an output from lsof:
xinetd 12500 root 14u IPv6 158567 UDP *:amanda
xinetd 12500 root 16u IPv6 158569 TCP *:amandaidx
(LISTEN)
xinetd 12500 root 17u IPv6 158570 TCP *:amidxtape
(LISTEN)
Based on all the suggestions, here is my relevant xinetd.conf
configuration:
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = backup
groups = yes
server = /usr/local/libexec/amandad
}
amandad fails to respond to any unicast requests. It only responds to the
broadcast requests.
Here is the breakthrough though: xinetd does not record any logs for the
unicast query! Therefore, the problem is not amandad, but rather, xinetd.
Still, can someone help me with my configuration?
Thank you,
Cory Visi
"Cory Visi"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
> cc: (bcc: Cory Visi/Mazescape)
Sent by: Subject: Amanda and xinetd
owner-amanda-users@
amanda.org
06/11/2002 10:32 AM
Well all my problems are basically due to the fact that Amanda refuses to
work with xinetd. This was suggested by someone on the list and I finally
decided to try it. Why doesn't Amanda work with xinetd? There is no good
debugging log that would help in figuring out this problem. Amandad clearly
does not recognize the IPv4 unicast bindings that it needs to with xinetd.
Here is my inetd.conf:
amanda dgram udp wait backup /usr/local/libexec/amandad amandad
Here is my relevant xinetd.conf:
service amanda
{
id = amanda-udp
log_on_success += USERID
log_on_failure += USERID
socket_type = dgram
protocol = udp
wait = yes
user = backup
server = /usr/local/libexec/amandad
}
This really looks like a bug in the program as xinetd and inetd are
designed to operate as identical as possible.
Thanks,
Cory Visi
