I had a problem wherein running a script with an embedded ftp call would work in the login shell during integration testing and then fail with an unrecognized option error in cron during acceptance testing. In solving this I discovered that RedHat, and therefore CentOS, ships with at least two ftp clients, /usr/bin/ftp ( which I thought I was using ) and /usr/kerberos/bin/ftp, which I actually was using. even though I had no inkling of its existence. My question is why? Why are there two ftp clients provided in a single distribution and why is the kerberos version effectively made the default whereas one might reasonably assume that anything in /usr/bin/ is the standard ( and by inference default ) ftp client for the distribution? If kerberos ftp is intended to be the default ftp client then why is it not in, or at least linked to from, /usr/bin? I just do not understand why these obscure distribution 'gotchas' are created in the first place, much less permitted to persist. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On 08/02/11 12:41 PM, James B. Byrne wrote:> I just do not understand why these obscure distribution 'gotchas' > are created in the first place, much less permitted to persist.you'd need to ask Red Hat that. Its their policy. -- john r pierce N 37, W 122 santa cruz ca mid-left coast
On Tue, Aug 2, 2011 at 2:41 PM, James B. Byrne <byrnejb at harte-lyne.ca>wrote:> > My question is why? Why are there two ftp clients provided in a > single distribution and why is the kerberos version effectively made > the default whereas one might reasonably assume that anything in > /usr/bin/ is the standard ( and by inference default ) ftp client > for the distribution? If kerberos ftp is intended to be the default > ftp client then why is it not in, or at least linked to from, > /usr/bin? > > If you look in /etc/profile.d/ you'll see the krb5-workstation.sh script.It tests the path to see if kerberos is in it, and if not, it prepends the path. This is why it is the first ftp used/found. As to why, dunno. Ask rh. -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20110802/1626903c/attachment-0003.html>
At Tue, 2 Aug 2011 15:41:52 -0400 (EDT) CentOS mailing list <centos at centos.org> wrote:> > I had a problem wherein running a script with an embedded ftp call > would work in the login shell during integration testing and then > fail with an unrecognized option error in cron during acceptance > testing. > > In solving this I discovered that RedHat, and therefore CentOS, > ships with at least two ftp clients, /usr/bin/ftp ( which I thought > I was using ) and /usr/kerberos/bin/ftp, which I actually was using. > even though I had no inkling of its existence. > > My question is why? Why are there two ftp clients provided in a > single distribution and why is the kerberos version effectively made > the default whereas one might reasonably assume that anything in > /usr/bin/ is the standard ( and by inference default ) ftp client > for the distribution? If kerberos ftp is intended to be the default > ftp client then why is it not in, or at least linked to from, > /usr/bin? > > I just do not understand why these obscure distribution 'gotchas' > are created in the first place, much less permitted to persist.Does this give you a clue: gollum.deepsoft.com% rpm -qf /usr/kerberos/bin/ftp /usr/bin/ftp krb5-workstation-1.6.1-55.el5_6.2 ftp-0.17-35.el5>-- Robert Heller -- 978-544-6933 / heller at deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
On 02/08/2011 3:41 PM, James B. Byrne wrote:> I had a problem wherein running a script with an embedded ftp call > would work in the login shell during integration testing and then > fail with an unrecognized option error in cron during acceptance > testing. > > In solving this I discovered that RedHat, and therefore CentOS, > ships with at least two ftp clients, /usr/bin/ftp ( which I thought > I was using ) and /usr/kerberos/bin/ftp, which I actually was using. > even though I had no inkling of its existence.>> My question is why? Why are there two ftp clients provided in a > single distribution and why is the kerberos version effectively made > the default whereas one might reasonably assume that anything in > /usr/bin/ is the standard ( and by inference default ) ftp client > for the distribution? If kerberos ftp is intended to be the default > ftp client then why is it not in, or at least linked to from, > /usr/bin? > > I just do not understand why these obscure distribution 'gotchas' > are created in the first place, much less permitted to persist.What I'm left wondering is: 1) Why you are relying on PATH expansion for this from something as critical as a cron job. It is good sysadmin practice to specify explicit paths for situations like this rather than to worry about whether or not there is a good or valid reason for there being 2 ftp clients installed on the system. 2) Why you are using an ftp client rather than something like wget or curl instead, both of which are far more powerful and script friendly. Presumably the kerberos client only gets installed if kerberos infrastructure is installed, and the standard ftp client is probably part of the default install as people expect it to be there perhaps. Putting in unnecessary logic to only install one ftp client and not the other doesn't make much sense either. Focusing on finding the best way develop solid solutions to administrative scripting problems like this is IMHO much more important than trying to know or guess what the rationale is behind there being 2 ftp binaries on the system. Anyhow, if you have expectations of specific software being installed or not installed on your systems the only reliable and reproducible way to do that is to use kickstart with a minimal install and build up the package list to include only the things you want to have installed. HTH
Mike A. Harris mharris at mharris.ca Tue Aug 2 16:45:56 EDT 2011> What I'm left wondering is: > > 1) Why you are relying on PATH expansion for this from something as > critical as a cron job. It is good sysadmin practice to specify > explicit paths for situations like this rather than to worry about > whether or not there is a good or valid reason for there being 2 > ftp clients installed on the system.Point taken and that is e=indeed what i subsequently did. However, in my defence I explicitly set the PATH variable in the crontab entry prior to invoking the calling script that uses ftp. It never crossed my mind that I should have first done a 'which ftp' to discover which one was being used in my login shell because it never crossed my mind that there would be two different ftp clients on my systems to begin with. And frankly, I do not think that anyone would a priori conceive of there being two separate telnet clients, two different sftp clients, or two of anything else of a similar nature as being a reasonable possibility.> 2) Why you are using an ftp client rather than something like > wget or curl instead, both of which are far more powerful and > script friendly.I tried to use cURL for this particular bit, I in fact use cURL everywhere else in the same script. However, I am unable to determine how to get cURL to give me a meaningful response to the SYST command whereas the ftp client gives me a quite fulsome answer.> Presumably the kerberos client only gets installed if kerberos > infrastructure is installed, and the standard ftp client is > probably part of the default install as people expect it to be > there perhaps. Putting in unnecessary logic to only install one > ftp client and not the other doesn't make much sense either.Leaving it for an unsuspecting user to discover that there are two dissimilar versions of the same utility is not user friendly.> Focusing on finding the best way develop solid solutions to > administrative scripting problems like this is IMHO much more > important than trying to know or guess what the rationale is > behind there being 2 ftp binaries on the system.A rationale is more than I expect. The excuse is likely that it is just too difficult to bother with, as you pointed out above.> Anyhow, if you have expectations of specific software being > installed or not installed on your systems the only reliable > and reproducible way to do that is to use kickstart with a > minimal install and build up the package list to include only > the things you want to have installed.I expected an ftp client to be installed and I found one in the place I expected it to be. What I did not expect was that there was a second one installed somewhere else on a basic CentOS system with few local customizations and that it was the other client that I was using in my login shell. I am sure that paranoia is a valued admin quality but truly I do not expect to have to run which on every stock utility present on a reputable distribution just to discover if there is a second version of something installed somewhere obscure and stuck into my path by the packager. Nor do I expect that this issue or any like it will ever be considered important enough to comment on by upstream, much less looked at and reconciled. Which essentially is why I dropped RH support and went to CentOS in the first place. But I am pissed that this sort of BS still gets me from time to time. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3