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

Thu Sep 13 23:07:56 UTC 2007

Hi Guys,

I got the error, now it's working like a charm!!!! :-)

It was my (huge) mistake. I realized that only checking the list of  
services activated by xinetd with "chkconfig --list". There I found  
an interesting thing, that I lucklily noted:

xinetd based services:
         chargen-dgram:  off
...
         tftp:           on
         tftp_old:     on
...
[root at chl1 ~]#

Basically, before editing /etc/xinetd.d/tftp for adding "-c" I  
thought it was a good idea to backup the original file as "tftp_old"!  
Did not imagine that that would have been a process started by  
xinetd.d :-(

Thanks a lot to all who responded - at least I can say that I've  
learned something today.

Cheers,
Davide

On Sep 14, 2007, at 12:33 AM, Davide Grandis wrote:

> 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.
>>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos