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

[Ross S. W. Walker]

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.