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@centos.org 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.