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.