Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
And here is it concerning the home path owner & permissions:
[root@chl1 /]# ls -la ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]# ls -la tftpboot/ drwxrwxrwx 2 root root 4096 Sep 13 10:18 . drwxr-xr-x 25 root root 4096 Sep 13 17:48 .. -rwxrwxrwx 1 nobody nobody 1811552 Sep 12 10:28 c3500xl-c3h2s-mz. 120-5.WC17.bin -rwxrwxrwx 1 nobody nobody 1181 Sep 13 17:51 pippo.config
(pippo.config = fake file)
This is what I get at the TFTP 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# 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]? pippo.config !! 2327 bytes copied in 0.831 secs
So, it means that the TFTP client can only *re-write* an existing file but not creating new ones, and this is the expected behavior if the "-c" parameter is omitted!
What am I missing?
Any suggestion really appreciated!
TIA, Davide
Davide Grandis wrote: ...
What am I missing?
SELinux?
Mogens
Yes, forgot to mention, sorry.
SELinux is disabled, otherwise TFTP would be completely filtered out.
Regards, Davide
On Sep 13, 2007, at 6:04 PM, Mogens Kjaer wrote:
Davide Grandis wrote: ...
What am I missing?
SELinux?
Mogens
-- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk@crc.dk Homepage: http://www.crc.dk _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 13 Sep 2007, Davide Grandis wrote:
Yes, forgot to mention, sorry.
SELinux is disabled, otherwise TFTP would be completely filtered out.
I have SELinux and tftp working together without any trouble. I first used audit2allow to write a module:
grep tftp /var/log/audit/audit.log | audit2allow -M tftpwrite
Here's the resulting tftpwrite.pp file:
----- %< ----- module tftpwrite 1.0; require { class file write; type tftpd_t; type tftpdir_t; role system_r; }; allow tftpd_t tftpdir_t:file write; ----- %< -----
I compiled and activated it with semodule:
semodule -i tftpwrite.pp
Then make sure that the filename to which you want to write exists, is world-writable, and has the correct file contexts. If I wanted to write to /tftpboot/foo, for example, it ought to look like
-rw-rw-rw- root root user_u:object_r:tftpdir_t /tftpboot/foo
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
______________________________________________________________________ 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.
Even more, rebooted (just to be sure!:-)) )
Regards, Davide
On Sep 13, 2007, at 6:07 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
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
Davide Grandis wrote:
Even more, rebooted (just to be sure!:-)) )
It's working on my server and the only difference is instead of:
server_args = -s -c /tftpboot
I have:
server_args = -c -s /tftpboot
Maybe order is important here...
-Ross
On Sep 13, 2007, at 6:07 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
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
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.
Tried but with no luck, exact same behavior! :-(
tftp-server broken?
Thanks, Davide
On Sep 13, 2007, at 6:26 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Even more, rebooted (just to be sure!:-)) )
It's working on my server and the only difference is instead of:
server_args = -s -c /tftpbootI have:
server_args = -c -s /tftpbootMaybe order is important here...
-Ross
On Sep 13, 2007, at 6:07 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
_
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
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Davide Grandis wrote:
Tried but with no luck, exact same behavior! :-(
tftp-server broken?
Just to make sure, is the /tftpboot directory set to perms 777?
-Ross
On Sep 13, 2007, at 6:26 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Even more, rebooted (just to be sure!:-)) )
It's working on my server and the only difference is instead of:
server_args = -s -c /tftpbootI have:
server_args = -c -s /tftpbootMaybe order is important here...
-Ross
On Sep 13, 2007, at 6:07 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option
into the /etc/
xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
_
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
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
Ross S. W. Walker wrote:
Davide Grandis wrote:
Tried but with no luck, exact same behavior! :-(
tftp-server broken?
Just to make sure, is the /tftpboot directory set to perms 777?
Just checked the earlier post, and it is.
Oh, did you do a kill -HUP or a service xinetd restart after switching the -c and -s options?
After that I would add a -v or a -v -v to increase the verbosity and see if the reason appears in the logs.
-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.
Yes, it is. See here:
[root@chl1 /]# ls -la total 178 ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]#
Thanks, Davide
On Sep 13, 2007, at 7:01 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Tried but with no luck, exact same behavior! :-(
tftp-server broken?
Just to make sure, is the /tftpboot directory set to perms 777?
-Ross
On Sep 13, 2007, at 6:26 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Even more, rebooted (just to be sure!:-)) )
It's working on my server and the only difference is instead of:
server_args = -s -c /tftpbootI have:
server_args = -c -s /tftpbootMaybe order is important here...
-Ross
On Sep 13, 2007, at 6:07 PM, Ross S. W. Walker wrote:
Davide Grandis wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option
into the /etc/
xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
Did you give xinetd the HUP signal after modifying the file?
<snip>
_
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
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 13 Sep 2007, 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?
-- Russ Herrold
R P Herrold wrote:
On Thu, 13 Sep 2007, 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.
-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.
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.
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.
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@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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@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@chl1 ~]#
Then rebooted. After reboot the tftpd is not running (even if enabled, isn't it strange?!?!?)
[root@chl1 ~]# ps -ef | grep tftp root 2896 2814 0 00:28 pts/2 00:00:00 grep tftp [root@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@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@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@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@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.
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@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@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@chl1 ~]#
Then rebooted. After reboot the tftpd is not running (even if enabled, isn't it strange?!?!?)
[root@chl1 ~]# ps -ef | grep tftp root 2896 2814 0 00:28 pts/2 00:00:00 grep tftp [root@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@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@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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
Davide Grandis wrote: [snip]
So, xinetd is start tftpd ON-DEMAND (?!?!?!?)
That's the whole point of using xinetd.
$ man xinetd
NAME xinetd - the extended Internet services daemon
SYNOPSIS xinetd [options]
DESCRIPTION xinetd performs the same function as inetd: it starts programs that provide Internet services. Instead of having such servers started at system initialization time, and be dormant until a connection request arrives, xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file. When a request comes in, xinetd starts the appropriate server. Because of the way it operates, xinetd (as well as inetd) is also referred to as a super-server.
Davide Grandis wrote:
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.
I normally just open 2 windows from wherever I'm working, one ssh'd to the server holding the file copies, one for telnet or ssh to the device. Sometimes this involves a VPN connection and access to a freenx session that already has some of these windows open. For things like editing access lists, I find it much easier to edit on the computer side and tftp the whole thing than to work with the limited set of commands on a router. Likewise for initial router/switch setups, I usually create the file from a copy of something similar, edit it on the server, then tftp it to the startup config and reload. Plus, after tftp'ing any changes back to the server I need the connection there to commit to cvs.
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
And here is it concerning the home path owner & permissions:
[root@chl1 /]# ls -la ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]# ls -la tftpboot/ drwxrwxrwx 2 root root 4096 Sep 13 10:18 . drwxr-xr-x 25 root root 4096 Sep 13 17:48 .. -rwxrwxrwx 1 nobody nobody 1811552 Sep 12 10:28 c3500xl-c3h2s-mz. 120-5.WC17.bin -rwxrwxrwx 1 nobody nobody 1181 Sep 13 17:51 pippo.config
(pippo.config = fake file)
This is what I get at the TFTP 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# 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]? pippo.config !! 2327 bytes copied in 0.831 secs
So, it means that the TFTP client can only *re-write* an existing file but not creating new ones, and this is the expected behavior if the "-c" parameter is omitted!
What am I missing?
Any suggestion really appreciated!
TIA, Davide
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
Hi Grant,
Thanks for the support.
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
May I ask you to tell me the detailed steps to achieve that... I'm an absolute beginner! :-)
Thanks again, Davide
On Sep 13, 2007, at 7:27 PM, Grant McChesney wrote:
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote: Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d /tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
And here is it concerning the home path owner & permissions:
[root@chl1 /]# ls -la ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]# ls -la tftpboot/ drwxrwxrwx 2 root root 4096 Sep 13 10:18 . drwxr-xr-x 25 root root 4096 Sep 13 17:48 .. -rwxrwxrwx 1 nobody nobody 1811552 Sep 12 10:28 c3500xl-c3h2s-mz. 120-5.WC17.bin -rwxrwxrwx 1 nobody nobody 1181 Sep 13 17:51 pippo.config
(pippo.config = fake file)
This is what I get at the TFTP 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# 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]? pippo.config !! 2327 bytes copied in 0.831 secs
So, it means that the TFTP client can only *re-write* an existing file but not creating new ones, and this is the expected behavior if the "-c" parameter is omitted!
What am I missing?
Any suggestion really appreciated!
TIA, Davide
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote:
Hi Grant,
Thanks for the support.
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
May I ask you to tell me the detailed steps to achieve that... I'm an absolute beginner! :-)
Thanks again, Davide
Here's the post about this problem on fedora forum: http://forums.fedoraforum.org/archive/index.php/t-109735.html
Here's the ugly workaround:
In /etc/xinetd.d/tftp, set disable = yes Restart xinetd (/etc/init.d/xinetd restart) Run in.tftpd (for example, "/usr/sbin/in.tftpd -l -c -v -u root -s /tftpboot") You can add the previous command to /etc/rc.local to make it start on boot.
Grant McChesney wrote:
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote:
Hi Grant,
Thanks for the support.
I had this same problem when trying to back upmy switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
May I ask you to tell me the detailed steps to achieve that... I'm an absolute beginner! :-)
Thanks again,
Davide
Here's the post about this problem on fedora forum: http://forums.fedoraforum.org/archive/index.php/t-109735.html http://forums.fedoraforum.org/archive/index.php/t-109735.html
Here's the ugly workaround:
In /etc/xinetd.d/tftp, set disable = yes Restart xinetd (/etc/init.d/xinetd restart) Run in.tftpd (for example, "/usr/sbin/in.tftpd -l -c -v -u root -s /tftpboot") You can add the previous command to /etc/rc.local to make it start on boot.
I would not run tftpd as user root! "-u root"
I have tftpd server working in CentOS 5 via xinetd you can also get xinetd to start up an instance at startup and keep it running with an option if that is what it takes to make it work.
-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.
Hi Grant,
No luck again with the w/a you provided.
Here is the result of more investigation:
1) disabled (disable = yes) in /etc/xinetd.d/tftp
2) reboot or just "service xinetd restart"
3) run in.tftpd
Writing to a new file still fails. This is what I discovered from / var/log/messages:
Sep 13 23:56:39 chl1 xinetd[2301]: START: tftp pid=3036 from=10.58.2.159
That is, xinetd automatically starts TFTP when a TFTP request comes in. 10.58.2.159 in fact is the IP address of the switch from which I'm trying to TFTP-ing.
Checking the processes it turns out that:
[root@chl1 log]# ps -ef | grep tftp root 3014 2813 0 23:55 pts/2 00:00:00 ./in.tftpd -c -v -u root -s /tftpboot root 3036 2301 0 23:56 ? 00:00:00 in.tftpd -s /tftpboot root 3043 2888 0 23:57 pts/3 00:00:00 grep tftp [root@chl1 log]#
two tftpd are running. Apparently the one responding is the one w/o the '-c' option!!!
Can someone please explain to me why xinetd is starting tftp, even if disabled!?!?!?
Thanks, Davide
On Sep 13, 2007, at 7:52 PM, Grant McChesney wrote:
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote: Hi Grant,
Thanks for the support.
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
May I ask you to tell me the detailed steps to achieve that... I'm an absolute beginner! :-)
Thanks again, Davide
Here's the post about this problem on fedora forum: http://forums.fedoraforum.org/archive/index.php/t-109735.html
Here's the ugly workaround:
In /etc/xinetd.d/tftp, set disable = yes Restart xinetd (/etc/init.d/xinetd restart) Run in.tftpd (for example, "/usr/sbin/in.tftpd -l -c -v -u root -s / tftpboot") You can add the previous command to /etc/rc.local to make it start on boot. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 13 Sep 2007, Grant McChesney wrote:
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
And here is it concerning the home path owner & permissions:
[root@chl1 /]# ls -la ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]# ls -la tftpboot/ drwxrwxrwx 2 root root 4096 Sep 13 10:18 . drwxr-xr-x 25 root root 4096 Sep 13 17:48 .. -rwxrwxrwx 1 nobody nobody 1811552 Sep 12 10:28 c3500xl-c3h2s-mz. 120-5.WC17.bin -rwxrwxrwx 1 nobody nobody 1181 Sep 13 17:51 pippo.config
(pippo.config = fake file)
This is what I get at the TFTP 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# 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]? pippo.config !! 2327 bytes copied in 0.831 secs
So, it means that the TFTP client can only *re-write* an existing file but not creating new ones, and this is the expected behavior if the "-c" parameter is omitted!
What am I missing?
Any suggestion really appreciated!
TIA, Davide
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
Is xinetd installed?
-Connie Sieh
Hi Connie,
Is xinetd installed?
Yes, in fact, after editing the /etc/xinetd.d/tftp file, I restart it by means of:
[root@chl1 sbin]# service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] [root@chl1 sbin]#
Cheers, Davide
On Sep 13, 2007, at 8:46 PM, Connie Sieh wrote:
On Thu, 13 Sep 2007, Grant McChesney wrote:
On 9/13/07, Davide Grandis davide.grandis@fastwebnet.it wrote:
Hi all,
I'm trying to setup a TFTP server to serve as repository for the config of all my Cisco network devices.
As per the the tftpd man, I've added the "-c" option into the /etc/ xinetd.d/tftp (as follows) but I still cannot get write access (unless the file is already present).
[root@chl1 ~]# cd /etc/xinetd.d [root@chl1 xinetd.d]# cat 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 = -s -c /tftpboot per_source = 11 cps = 100 2 flags = IPv4 }
And here is it concerning the home path owner & permissions:
[root@chl1 /]# ls -la ... drwxrwxrwx 2 root root 4096 Sep 13 10:18 tftpboot ... [root@chl1 /]# ls -la tftpboot/ drwxrwxrwx 2 root root 4096 Sep 13 10:18 . drwxr-xr-x 25 root root 4096 Sep 13 17:48 .. -rwxrwxrwx 1 nobody nobody 1811552 Sep 12 10:28 c3500xl-c3h2s-mz. 120-5.WC17.bin -rwxrwxrwx 1 nobody nobody 1181 Sep 13 17:51 pippo.config
(pippo.config = fake file)
This is what I get at the TFTP 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# 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]? pippo.config !! 2327 bytes copied in 0.831 secs
So, it means that the TFTP client can only *re-write* an existing file but not creating new ones, and this is the expected behavior if the "-c" parameter is omitted!
What am I missing?
Any suggestion really appreciated!
TIA, Davide
I had this same problem when trying to back up my switch configs. After some googling, I found a workaround for RH-based systems. The workaround is disable tftp in xinetd, and run in.tftpd manually. I never figured out why it would not work with xinetd.
Is xinetd installed?
-Connie Sieh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Connie Sieh -
Davide Grandis -
Grant McChesney -
Les Mikesell -
Mogens Kjaer -
Paul Heinlein -
R P Herrold -
Ross S. W. Walker -
William Hooper