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.