We have about 10 pc stations in the office that are using Zterm and ATE. We use Zterm primarily for support and ATE inhouse. Sometimes we use ATE to telnet onto a client but that is rare.

Anyways, we are trying to move into the 90's and start supporting our linux boxes thru telnet/internet connections. Only about half of our 120 or so linux servers in the field have static ip's, but we are trying to increase this.
The problem is that it seems that each station in our office is mainting their own, often old or incorrect profile list of customer sites with ip addresses... I would like to centralize this somehow and have 1 database of profiles/addresses. I can't seem to find a way to make this work... even installing zterm on the network and pointing to it keeps the profiles local to the pc setting them up.

I cant believe we are the only ones attempting this, probably more like the caboose!

Would appreciate any help here, or even alternate suggestions would be appreciated.

Thanks.

As far as keeping track of the IP addresses of the remote servers, I recommend using their DNS names, rather than their addresses. For the ones that have dynamic addresses, they can use a Dynamic DNS service, like dyndns.org, which allows you to essentially pretend that they do have a static IP address. (Most Internet routers nowadays support the dynamic DNS scheme directly, otherwise, you can run a little daemon on one of the machines at each site that updates the dynamic DNS entry when the IP address changes.)

That may not totally eliminate the desirability of having a central list of the DNS names of all the remote servers, but it reduces it to the same situation you have now with any other Internet address. (For example, every PC needs to separately enter and otherwise keep track of changes to the address for sites such as google or microsoft.) I suggest that before you start helping people set up their dynamic DNS names, you establish some kind of systematic naming convention, so that if one of your in-house users needs to connect to, say, Orlando Olfactory Associates, they could reasonably guess that the DNS name is orlando-olfactory-assoc.dnsalias.net. (Or better yet, if you have internal customer ID's for each of them, you could use that as the DNS prefix, eliminating all the uncertainty.)

As for the other details involved in connecting, such as a login name and password, it might be nice to have some central scheme for that, but on the other hand, in theory those things should be private to each of your users.

Since both ATE and ZTERM keep their profiles in the Registry, the only way I can see to share them easily is to set up a Remote Desktop Server in house, and have your users RDP to it and then use a shared profile to connect from there to the remote system. But even that has the problem that in order to access the HKEY_LOCAL_MACHINE area of the registry where the shared profiles are, you may need to give everyone higher privileges on the server than you wanted to. Plus, RDP licenses are not without cost (although I think you get 2 free with your W2003 server license).

One other thing: I strongly suggest using SSH instead of Telnet for non-VNC connections over the Internet!

Another couple of comments/suggestions/ideas:

1. If you had a standard support login on each of your customer servers, and you wanted to set up a complete profile for each, one approach would be to create the first profile, then export it from the Registry. Then open up the exported reg file in an editor like Notepad, and replicate the profile, once for each remote site. There may only be one field that needs to be changed (the IP address) for each. Then reload the reg file, make sure that the new configurations work, then reexport it. Now you can just email that .reg file to each of your in-house support people. Obviously that doesn't solve the on-going maintenance issue, but would simplify getting the first hundred profiles distributed.

2. Or, just use the same profile for every site. You'll have to change the IP address each time, but that's about the same amount of work as it would be to just enter the IP address from scratch each time (like you would do with a generic emulator). ZTERM actually keeps track of several most-recently-used IP addresses for a given profile, which is a way to share one profile among many target systems which only differ in the IP address (provided that you use hostnames rather than numeric IP addresses, which would be hard to recognize in the dropdown list). We could perhaps add something like that for ATE if there was sufficient interest.

Hi,

If you are planning to start any project to make your remote accesses to customers easier, the best I can do is to show what we've done here.

We have developed our own Dynamic DNS service provider (after one year of using dyndns.org and realized that, instead of paying for that we could receive, and that's what we do now )
The following picture shows our FMWip control panel where we can see if any customer is not connected, or to confirm their current IP.
Note that, this panel is accessible from the outside, we don't need to be at the office.




Ok, we already know how to reach our customers since we have their IP or their DynDNS, but we still need to connect to them.
Here we have different issues to solve:
- which method to connect is configured on each customer ?
- which machines are reachable?
- username & passwords ?
If I'm at the office, one way or another I'll be able to get that information, if I'm out of the office but with my computer, surely I will get that, but if I'm anyware w/o my computer, if not impossible, it will be much difficult.

So, to solve all this in one step we have created, on the same site, one panel (Acessos Remotos) where we have all the exiting remote connections, and on each customer we have all the computers accessible from the outside. Each computer is configured with the proper method (in the picture you can see a customer where the Server is accessed by RDP and a workstation where we use Radmin from Famatech).
With this, we are able to connect to our customers from everywhere, and not less important, as soon as we have a new customer, anybody will be able to remotely access it w/o the need to ask.





Obviously that you surely will find the most adequate method for your internal needs, but I know what we tried and changed until found our method (and we are still trying to improve), so I thought that some ideas would not hurt

Be my guest to ask whatever you need to know.

Regards

Hi Jack and Jorge,

Thanks for the many suggestions.

Jorge, your solution is very elegant... but probably to advanced for me to try to emulate at this time. We dont have a need to access sites while out of the office, and if i introduced it, we would be on call 24/7!

Jack, thanx for the suggestion of using a dns name, though it seems like its the same amt of work as we have now...

I wouldnt mind pursuing an option of using ATE as a front end... We sort of do that now, but unfortunately the .ash files reside on the server and the connection info resides in the registry. Your "connection front end" is already 99% of the way there, and is a great tool for setting up profiles, naming them, etc, save for the fact that they are stored locally.

I dont know how much work is required on your side for this or if there is any other vested interest out there... but i would be willing to help out if it became feasible.

Anyways, its easter weekend. guess i should scram.. enjoy the holiday weekend everybody!

Just a thought and i wanted your feedback on the pros/cons on this:

Maurice and I were tossing around the notion of while in ATE (or even Zterm), issuing a host command and invoking telnet thru linux and opening a connection to the remote system. Much to my suprise, ATE ran flawlessly in this scenario... There was an issue with file transfers still to hash out, but i was wondering if this is an acceptable approach to the problem at hand. I can write a little gui front end program to store contact info and addresses, let the rep pick the client and invoke telnet and launch the connection from there.

It almost seems to straight forward to be viable.... so before i go start in this direction, what do you think?

Thanks.

That sounds pretty good to me. File transfers will require some additional engineering though. Getting the file transfer command from the host to the PC client is no problem - it will pass through the double-telnet link just like everything else. But as it stands, both ZTERM and ATE expect the host side of the FTP to be the same system that it is telnetting to, which would be your Linux server, not the remote customer server. One manual approach would be to just use some standalone FTP mechanism, like MadFTP, and manually launch/connect it.

Or, we could consider enhancing the AG_FTP command (or the equivalent ZTERM ESC sequence) to allow the host to pass its IP address as part of the command. That would only be an option for ATE, since it would require an update on the client side. Note that there is already a TAB(-10,AG_FTPSETPW) command allowing you to set the FTP login info from the host, so you wouldn't even have to make that common across all servers.

Technically, you can do everything you need right now, by writing a custom SBX which uses FTPDLX.SBX to perform the FTP transfer (since it already allows the client to specify the host IP). You would launch your SBX and pass it the necessary IP and any other parameters using TAB(-10,AG_XFUNC).

I can see how you might think that extending the AG_FTP protocol to allow a different host IP to be specified might be simpler though (at least for you). On that other hand, that would require an update to 5.1, so the approach just outlined might actually be the best solution for right now.

Cool.

I certainly dont mind doing the coding on my end if ATE will support the functionality "as-is".

I will do some additional research on the file transfer and will most likely have some specific questions a bit later as i get into it...

If this turns out relatively turn-key i would be happy to donate it to the SOSLIB.

Hey Jack,

I know this isnt a front burner deal, but i was just wondering if you were thinking about tinkering with the ATE 5.1 connection properties info and being able to store that stuff on an alternate drive... or should i go about and build my own database and issue local telnet commands as previously mentioned...

thanx

Well I'm not against the idea. One possibility would be to implement a command line switch that told ATE to retrieve the connection properties from a specified file rather than from the registry, with the file being generated by some kind of Save As operation in the Connection Properties dialog. You could then use the dialog to create a configuration, save it to a file, and distribute it to others (or store it on a central network drive.)

Let me roll it around a bit before committing to that though.

Hey that sounds great.. roll til your heart's content!