Hi Ross,
Ok, try adding -vv to the tftpd options and look in the messages to
see if an exact error is reported.
Tried but with no success.
Updated /etc/xinetd.d/tftp as follows:
[root@chl1 ~]# cat /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file
transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware
printers, \
# and to start the installation process for some operating
systems.
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
server = /usr/sbin/in.tftpd
server_args = -c -s -vv /tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
[root@chl1 ~]#
Then rebooted.
After reboot the tftpd is not running (even if enabled, isn't it
strange?!?!?)
[root@chl1 ~]# ps -ef | grep tftp
root 2896 2814 0 00:28 pts/2 00:00:00 grep tftp
[root@chl1 ~]#
Just when I issue the tftp command at the client side:
LabTI-Infra-3524XL-01#copy running-config tftp:
Address or name of remote host []? 10.58.2.204
Destination filename [labti-infra-3524xl-01-confg]?
TFTP: error code 1 received - File not found
%Error opening tftp://10.58.2.204/labti-infra-3524xl-01-confg
(Undefined error)
LabTI-Infra-3524XL-01#
I se that the tftp process is started:
[root@chl1 ~]# ps -ef | grep tftp
root 2904 2307 0 00:28 ? 00:00:00 in.tftpd -s /tftpboot
root 2914 2814 0 00:28 pts/2 00:00:00 grep tftp
[root@chl1 ~]#
and in /var/log/messages I see:
Sep 14 00:28:40 chl1 xinetd[2307]: START: tftp pid=2904 from=10.58.2.159
Sep 14 00:28:41 chl1 kernel: usb 2-1: reset low speed USB device
using uhci_hcd and address 3
[root@chl1 ~]#
So, xinetd is start tftpd ON-DEMAND (?!?!?!?) *and*, worst thing,
apparenty not reading from /etc/xinetd.d/tftp.
Any idea???
Thanks again,
Davide
On Sep 13, 2007, at 11:59 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi Les, Ross, all
Thanks to all who responded - btw, the issue is still open.
Concerning:
The usual approach is to create the filename yourself (ssh in
and "touch
devicename-confg") and chmod it to 666 before doing the tftp.
That way
you don't have to let tftp create any files and its lack of
authentication is less of an issue). If you are committing
the configs
to cvs (a good idea, since you can easily track changes),
note that cvs
for some reason will change the modes as a side effect of the
commit and
you'll have to put them back to 666 before the next tftp in.
Yes, those are good controls on tftp and sound like best practices.
For initial population of /tftpboot though one may want to use -c
and then once it is populated remove the -c switch, check it all
into cvs/subversion and make sure the permissions are sane.
Let me tell that in some circumstances it could be not that easy
create the file in advance. This is usually the case when
TFTP-ing in
from a network device that has limited capabilities (no SSH client
tipically). Anyway, that's an added complexity that is unncesserary
in my point of view.
Ok, try adding -vv to the tftpd options and look in the messages to
see if an exact error is reported.
On Sep 13, 2007, at 9:33 PM, Ross S. W. Walker wrote:
Les Mikesell wrote:
Ross S. W. Walker wrote:
Just to make sure, is the /tftpboot directory set to perms 777?
Not that that parent directory (/tftpboot) requires (or should
ever have) anything like that to work
-- why the voodoo suggestion?
Because if you are allowing any old anonymous user to write to
that directory then why would one care if you only allowed group
'nobody' to write there?
You could set it to 755 and create a 'cisco' dir underneath with
777, but I would leave that for when it's working.
Chances are though everything under /tftpboot is subject to
modification and /tftpboot will need to be a separate volume to
protect against DoS through filling up the disk drive.
The usual approach is to create the filename yourself (ssh in
and "touch
devicename-confg") and chmod it to 666 before doing the tftp.
That way
you don't have to let tftp create any files and its lack of
authentication is less of an issue). If you are committing
the configs
to cvs (a good idea, since you can easily track changes),
note that cvs
for some reason will change the modes as a side effect of the
commit and
you'll have to put them back to 666 before the next tftp in.
Yes, those are good controls on tftp and sound like best practices.
For initial population of /tftpboot though one may want to use -c
and then once it is populated remove the -c switch, check it all
into cvs/subversion and make sure the permissions are sane.
-Ross
_____________________________________________________________________
_
This e-mail, and any attachments thereto, is intended only
for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the
intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
