FTP server enabled but disabled on 7.3-2

[Susan Abercrombie]

I have an AlphaServer 2000 4/200running 7.3-2 and TCP/IP 5.4. I'm having a problem with the FTP server.

Using the server components option of
@sys$startup:tcpip$config
it shows FTP service as Enabled and Started. FTP client is also Enabled and Started. But
$tcpip show service ftp
lists the state as disabled. If I execute
$tcpip enable service ftp
I get no error message, but the service is still disabled.

I cannot make an ftp connection from another system to this host. Attempts to make a connection from another host fail with various messages depending on the client host. From an OpenVMS Itanium system on the same subnet the error is
%TCPIP-E-FTP_NETERR, I/O error on network device
-SYSTEM-F-REJECT, connect to network object rejected.
(Not surprising for a disabled service.)

The system was upgraded from OpenVMS 7.2-1 and TCP/IP 5.0a (if I recall the latter correctly). There was no problem connecting before the upgrade. There is no problem connecting from this host to the Itanium (similarly configured) or various other hosts. If I reboot to an image copy of the old 7.2-1 system, the settings seem to be the same, except that the FTP service is enabled within $TCPIP, and there is no problem with the FTP service.

Can someone suggest to me how the service can be both enabled/started and disabled, and how I can go about enabling it?

Thanks!
Sue

[Steven Schweda]

I have no real wisdom here, but have you
tried "TCPIP SHOW SERVICE /FULL FTP"?

Check user TCPIP$FTP in AUTHORIZE?

Anything in "SYS$MANAGER:TCPIP$FTP_SERVER.LOG"?

"@ SYS$MANAGER:TCPIP$FTP_SHUTDOWN.COM" and
"@ SYS$MANAGER:TCPIP$FTP_STARTUP.COM", and
look for anomalies?

SYSTEM-F-REJECT = "connection refused", as
you've probably surmised. (Outgoing and
incoming are pretty unrelated, so you should
concentrate on the broken half.)

TCPIP V5.4 is up to ECO 5 now.

[Volker Halle]

Sue,

a TCPIP service will switch from the enabled to disabled state, if the service (or the server process) cannot be correctly started. There should be an OPCOM message issued, which would provide additional information. The service logfile should also contain error inforamtion.

Volker.

[Ian Miller.]

Look for opcom messages and log files.
A problem I have had after a series of upgrades is incorrect ownership of directories.
Check owner and protection of TCPIP$FTP directory.

[Daniel Fernandez Illan]

Sue,

I had a similar problem with mount service when upgraded from TCP/IP 5.0a to TCP/IP 5.4.
Solution was to define Domain name on TCP/IP because version 5.0 did not need this variable but 5.4 yes.

Saludos.
Daniel.

[faris_3]

Hi,

This article cures 99 % of
%TCPIP-E-FTP_NETERR, I/O error on network device
-SYSTEM-F-REJECT, connect to network object rejected

errors.

Hoping you are noy in the 1% left.

http://h18000.www1.hp.com/support/asktima/communications/CHAMP_SRC960729007492.html

/homi

[faris_3]

>Can someone suggest to me how the service can be both enabled/started and disabled, and how I can go about enabling it?

If you have tried the latest ECO of 5.4,

in last ressort you can rename your SYS$COMMON:[SYSEXE]TCPIP$SERVICE.DAT to
something else end redo a full IP configuration.

/hf

[Willem Grooters]

Have you looked in the FTP logfiles (SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_RUN.LOG - that can hold clues on what might be the problem. As stated by others, check protection and ownership of this directory and the files in it (But since it has worked, I doubt there would be something wrong)

Willem

[Susan Abercrombie]

Thanks, folks, for entirely sensible pointers. Still struggling :-).

The recommended article on the support site seems to be out of date (but is useful, regardless, and thank you!). It refers to installed images TCPIP$FTPC and TCPIP$FTPD. I don't have these. I have TCPIP$FTP_SERVER.EXE.

When SYS$MANAGER:TCPIP$FTP_STARTUP.COM is executed, it does install the image with privs. No error from the startup procedure. Nothing odd in the directory ownership or privs that I can see. Anyway, nothing different from the IA64 box.

I don't have a server process running. When the system reboots or when I try to start it manually, the resulting SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_RUN.LOG contains:
%DCL-E-NOCMDPROC, error opening captive command procedure - access denied
TCPIP$FTP job terminated at 6-FEB-2006 16:07:15.68

Accounting information:
Buffered I/O count: 29 Peak working set size: 1952
Direct I/O count: 21 Peak virtual size: 171840
Page faults: 145 Mounted volumes: 0
Charged CPU time: 0 00:00:00.14 Elapsed time: 0 00:00:00.32

I assume the captive procedure TCPIP$FTP_RUN.COM in sys$system. It is owned by SYSTEM, and has W:RE protection. Same as on the IA64 box. There is nothing in the account's SYS$LOGIN other than a LOGIN.COM (with just a comment line), and its log files. All are owned by that user account.

Interactive execution from a privileged account resulted in a successful service. The initial output was
FTP server started on
.4 6-FEB-2006 19:29:11.88
That looked odd, so I set the domain, as someone suggested. Made the initial output prettier but did not allow the service to be started properly.

I booted up a 7.3-1 system which had been created by updating the 7.2-1. No problem starting the service there. I booted up a disk on which 7.3-2 had been installed from scratch rather than updated. No problem there.

So, the TCPIP$FTP user reports access denied on a captive procedure which is (presumably) SYS$SYSTEM:TCPIP$FTP_RUN.COM, which has W:RE protection.

I'm still baffled.

Is there any way that it could be trying to execute some other command procedure?

[Karl Rohwedder]

Susan,

regarding 'access denied': have you also checked the LGICMD procedure of the TCPIP$FTP account (should be LOGIN.COM)?

regards Kalle

[Steven Schweda]

%DCL-E-NOCMDPROC looks bad. My log file
begins:

$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
******************************************************************
FTP server started on alp.antinode.org
******************************************************************
[...]


alp $ help /mess NOCMDPROC

NOCMDPROC, error opening captive command procedure - access denied

Facility: CLI, Command Language Interpreter (DCL)

Explanation: When you attempted to log in, you failed because you have a
captive account and DCL received an error during the login.
For example, DCL could not find your LOGIN.COM file. You
may also have incorrect protection on the system's SYLOGIN
file (SYS$MANAGER:SYLOGIN.COM or /SYSTEM/EXEC logical). The
system's SYLOGIN file must be protected with at least WORLD:E
access to the file and the directory that contains it.

User Action: See your system manager.


I assume that "captive" here also includes
"restricted", as that's what AUTHORIZE says
about user TCPIP$TFTP.

Around here:

ALP $ dire /owne /prot SYS$SYSDEVICE:[000000]TCPIP$TFTP

Directory SYS$SYSDEVICE:[000000]

TCPIP$TFTP.DIR;1 [TCPIP$AUX,TCPIP$TFTP] (RWE,RWE,RE,E)

and, for the login.com:

Directory SYS$SYSDEVICE:[TCPIP$TFTP]

LOGIN.COM;1 [TCPIP$AUX,TCPIP$TFTP] (RWED,RWED,RE,RE)


Perhaps you should "See your system
manager." (You have a mirror?)

[Steven Schweda]

Also, where the real action is:

Directory SYS$COMMON:[SYSEXE]

TCPIP$FTP_RUN.COM;1
[SYSTEM] (RWED,RWED,RE,RE)

[Susan Abercrombie]

And the winner is -- Karl Rohwedder. Thanks, Kalle! Protection on sylogin.com was W:. There was also an error in it, I found, once the protection was fixed. So a previous edit was bungled twice.

Many thanks to all who responded.

Sue

[faris_3]

Not to minimise Karl's advice :-)

but in the article you can read :

Use the "$ DIRECTORY /SECURITY command to check the file protections of
the following:

TCPIP V5.n

...
SYS$MANAGER:SYLOGIN.COM,

...

/hf

[Susan Abercrombie]

My apologies, Homi. I had worked my way through a good deal but not all of the article, then was diverted to some more pressing issues. When I got back to this issue, there were new replies, one of which was the specific pointer to SYLOGIN. I had not looked that early in the chain of steps in creating the process. I had observed that the user LOGIN did not seem to execute. So I concentrated on SYLOGIN, and that was the answer.

I'll go back and see whether I managed to skip over that issue in the article or didn't get there.

Again, thanks to you (and to everyone who offered assistance).

Sue

[faris_3]

No problems Susan.

I was just wondering if your case was in the 99 % covered by the article
(even if as you have seen the names of some of the images have changed).

[Susan Abercrombie]

Hi, Homi!

I would probably have parsed the article a little more closely if I hadn't found the discrepancies right from the top. My initial scan of it suggested that, though not current, it had very good material in it. And I was grateful for the pointer to the detailed (and, parenthetically, official) information. Since it was out of date, I had to parse my way through detailed data that clearly wasn't current. That didn't make it of less interest, just slower to process. As it happened, someone else put the particular issue front and center in my face at the right time.

That is one of the problems with support publications. Out of date sources have important material which can be hidden by version discrepancies. I'm not sure when FTPC and FTPD disappeared, but several versions bsck. Their presence in the article is distracting. I don't know who is responsible for maintaining those resources. I'm inclined to think that it's time to make a distinction between TCPIP 5.0 (or so) and the current versions rather than UCX and 5.0 (or so). But that's just my $0.02.

In any event, thank you very much for your assistance and your continued interest in my problem after viewing it and posting your recommendation. In my experience, the inclination to help the other guy is what has distinguished the DEC/.../HP world from the rest of the industry.

Sue

[Jan van den Ende]

Sue,

what remains for you to do is to give some value to your thanks:

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Remember, it is the ONLY reward for the effort by your colleagues!

Proost.

Have one on me.

jpe

[faris_3]

>That is one of the problems with support >publications. Out of date sources have >important material which can be hidden by >version discrepancies.

Yes but the articles are validated only at the date of the publication and for the listed versions of the products.

>I don't know who is responsible for >maintaining those resources.

Usually the articles are written by Customer Support Center specialists ( i am one in France). But nobody (as far as i know) is responsible for maintaining the articles up to date. They are updated on a need basis (many calls on a given subject).
They should be considered as valid at the time of the publication.

>I'm inclined to think that it's time to >make a distinction between TCPIP 5.0 (or >so) and the current versions rather than >UCX and 5.0 (or so). But that's just my >$0.02.

Good suggestion. I'll try to update this one.

>In any event, thank you very much for your >assistance and your continued interest in >my problem after viewing it and posting >your recommendation. In my experience, the >inclination to help the other guy is what >has distinguished the DEC/.../HP world >from the rest of the industry.

I have no merit. It's my job. (Though the participation in the forum is not part of it).

/homi

[Ira Carmel2]

I have run into this problem with restricted accounts, but the solution was very subtle. The problem was that the account had a lgicmd SCT_LOGIN, and there was a logical with the same name as the file. This was very hard to figure out, as the account would work perfectly when it was not RESTRICTED, no errors, no indications, but then when you set the RESTRICTED flag on, the logical prevented the login.

-Ira