[CentOS] tftp-server, unable to create new files (even with "-c"option)

[Davide Grandis]

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 at 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 at chl1 ~]#

Then rebooted.
After reboot the tftpd is not running (even if enabled, isn't it  
strange?!?!?)

[root at chl1 ~]# ps -ef | grep tftp
root      2896  2814  0 00:28 pts/2    00:00:00 grep tftp
[root at 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 at 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 at 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 at 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 at 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.
>