Bill; Good questions. Fortunately, we don't do a lot of ftp'ing (only one client and it was internal) so I haven't had to deal with these types of security issues.
The only really "security" issue I've had recently is printing. I have one client that no matter what he does our "overnight" process (started by the AT command scheduler) is not allowed to print to one of their printers. As far as I could tell "system" created the print job but we couldn't get the permissions right on the printer to allow it to print. We ended up splitting the job into 2 parts and they manually run the printing part - which works just fine with any of their users???? UD has always said they use the windows login, but they must wrap it somehow and something doesn't always get set right.... Glad you got things working though. Colin Alfke Calgary, Canada -----Original Message----- From: Bill Haskett Colin: I seem to have tracked down the issue here. I downloaded a product called Tunnelier and installed it on our UniData server (this is an SSH and SFTP client for Windows). [snip] There's no difference in the commands. The Tunnelier command-line interface allows a work-around so I can get this process to run properly in unattended mode. However, it seems to me there is a user context problem from within the UniData shell when executing O/S commands...I couldn't find any mention of this in the 44 UniData .pdf manuals I have. Also, all kinds of wierd problems occured because sometimes I could get the host key read from ECL but couldn't get it read from a phantom. No matter what, any time I rebooted UniData and Windows the problem appeared again and unattended communication failed; whether at ECL or via a phantom. I wonder why this is the case and what other limitations exist with user context, designed or otherwise, that would affect O/S commands. Bill ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
