NetWeaver Java 7.0 offered the tool SDM for managing applications. As of NW 7.1, SDM is gone. Most people won`t have noticed this, but with SAP Portal running on 7.3 and with ongoing migrations from 7.0 directly to 7.3, this is one of the changes you`ll have to adjust yourself to. SDM was used to deploy WDJ and portal applications; and it came with a nice feature: undeploy.
Correct: undeploy. How will you now undeploy a WDJ/SCA/EAR app without SDM? Before you give your BASIS team some headache and they start searching for how to run SDM on 7.3: on SCN is a document explaining the options you have now to undeploy an EAR / SCA file. It lists several options, with option 1 – telnet – mentioned as the best option.
Why not NWDS? Don`t know about you, but in my opinion NWDS should only be used in DEV environments and giving either the developer access in production to undeploy a file or install NWDS on the BASIS staff computer are far from what I consider considerable 😉 Note: not having NWDS on the BASIS computer also eliminates the ant scripts to deploy and undeploy a SDA. Besides, these should be used in a CI environment or in DEV only.
Let`s go with the telnet option.
In case you do not know the telnet port of your server, SAP MC can be used. Open SAP MC using the known URL (server:500013) and select telnet from the ICM process of the desired instance.
If not already configured, SAP MC will ask you to specify a telnet command.
In case you are not running on Windows XP or have Administrator rights, that’s it. No telnet program available. You might be charged and trusted to administer a valuable piece of software for the company, but normally they don`t trust you enough to give you permissions to install or change your computers software.
Fortunately, there is putty for Windows available that does not demand to be installed: it`s just an exe file to be executed (here we have to assume that the same Windows administrator that is not trusting you is not aware of any MS tool that blocks specific processes from being executed). Starting putty in telnet mode and pointing it to your server and telnet port will give you:
Before you now check your network cable, changes are good that the telnet server is running, but not available to you.
The server is listening, but only on interface 127.0.0.1. As this is the local interface, connections from outside the server are not possible. As you may now be tempted to SSH into the server and call telnet there:
Every trustworthy Linux / Unix distribution stopped shipping telnet years ago. As logging on via SSH to the server and then opening a telnet connection is a valid option, but normally admins are lazy, you may be tempted to open the telnet port for outside access.
Let us take a few seconds to reflect on that decision. You can do this, most people do it, but you shouldn`t. There is a good reason the default configuration of the telnet server is to listen only on localhost. If you opt to open the telnet port for remote access, you do this on your own and be aware of the possible security issues this will create. It is a good time to verify that your server is in a server DMZ with a firewall set up and configured in an intelligent way. The only way to connect to telnet should be indirect and with a secured connection. In fact, you should NOT continue to configure your server as outlined here. Unfortunately it is as of now one of the few ways to undeploy an application. I tried to create an idea on Idea Place, but there is not section for NetWeaver ideas (guess ideas related to NetWeaver are not considered disruptive). I'd like to have a (secured) web page or service (REST) that allows to manage applications.
An alternative is to use the guiconsole application. That will connect to the P4 port and from there to the telnet server. To be able to use that alternative, you'll have to configure the telnet server to accept connections from the P4 port. To prepare the telnet server for P4 access, use configtool:
Set the value to true.
Again, let me stop and reflect a little bit about this message. The last INFO text tells me to restart the cluster. Yes, the whole cluster just because I want to initiate a configuration reload of the telnet server. I do not know why this configuration change demands a cluster restart, or what is the reason behind it. For now, just let me say that I do not agree with it.
How does the telnet access over guiconsole look like?
The "alternative" with P4 means that while you won't have to configure ICM - P4 is accessible by default from remote - you`ll have to configure the telnet server. Restart of your cluster included. Independent what you use, in the end you`ll use telnet. So P4 without SSL should also not be used and you`ll have to make the guiconsole tool available on the administrator`s computer.
To access telnet from outside, one configuration option must be set:
- ICM must accept connection on the telnet port from remote
To configure ICM to allow remote access to the telnet port, the instance profile must be changed. For activating access, a default ICM parameter needs to be changed. To see the complete default configuration of ICM, you can use SAP MC:
This is the default configuration for the telnet protocol. The “security” here is that the hostname parameter is set to localhost, only allowing connections from the local NIC to port 50008. The profile file can be found here: ./profile/INSTANCE_PROFILE. Add the following line:
icm/server_port_3 = PROT=TELNET, PORT=50008
Restart your instance to make ICM pick up the configuration.
While your ICM is restarting, let me use this to make another comment. The configuration behavior leads to a permanent configuration of the telnet server. Instead of activating the external access for a few minutes to perform the action, administrators will leave the port open. This implies that the firewall between the server and the rest of the network is configured in such a way to block access from non-administrators. Although, I would like to see telnet gone. Either make the feature available by SSH or offer a web interface or [REST|WS] enabled service for SCA/EAR undeploys. Other portal JEE products allow this.
In case you skipped my above comments: telnet is bad.
Either way, now telnet is accessible from the outside and you can log on using a configured portal user.
- SAP Managed Tags:
1 Comment
