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