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.
Cheers,
Davide
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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
