Hi Folks,
John Baker was kind enough to let me know that the script I posted had some
potential security vulnerabilities. He provided the following alternative:
<%@ page import="java.net.*" %>
<html><head></head><body><p>
<%
String myhostname= null;
try {
myhostname= InetAddress.getLocalHost().getHostName();
} catch (UnknownHostException e) {
}
if (myhostname!=null) { %>
This application server is running on hostname <%= myhostname %>.
<% } %>
</p></body></html>
Works great. Thanks John!
Larry
On Thu, Oct 16, 2014 at 11:44 PM, Larry Robinson <[email protected]> wrote:
> Hi William,
>
> I too receive problem reports from our Mid-tier users and struggled to
> determine which server they were connected to. I asked one of my JSP
> experts to write us a program that could run from the browser that would
> emit the name and IP of the Tomcat server that was serving the users
> session. We use LVS as our load balancer, which is IP based so once you are
> locked onto a server, you stay there.
>
> I put this JSP program in the Tomcat webapps/ROOT directory and ask the
> user to invoke it as:
>
> https://myservicename/s*erver_id.jsp*
>
> and have them tell me which server they are locked onto.
>
> Here is the code:
> *server_id.jsp*:
>
> <%@ page import="java.util.*,java.io.*" %>
> <%
> String cmd = "hostname";
> String outstr = "";
>
> try {
> Runtime rt = Runtime.getRuntime();
> Process p = rt.exec(cmd);
>
> try {
> InputStreamReader ise = new InputStreamReader(p.getErrorStream());
> BufferedReader bre = new BufferedReader(ise);
> InputStreamReader iso = new InputStreamReader(p.getInputStream());
> BufferedReader bro = new BufferedReader(iso);
>
> String line=null;
> while ( (line = bre.readLine()) != null ) {
> outstr += line;
> }
> while ( (line = bro.readLine()) != null ) {
> outstr += line;
> }
>
> }
> catch (IOException ioe) {
> ioe.printStackTrace();
> }
>
> int exitVal = p.waitFor();
> }
> catch (Throwable t) {
> t.printStackTrace();
> }
>
> %>
> <br>
> Hostname: <strong><%=outstr%></strong><br>
> Your IP:
> <strong><%=request.getRemoteAddr()%></strong><br>
> Service IP:
> <strong><%=request.getLocalAddr()%></strong><br>
>
> Hope this is helpful.
> Larry
>
> On Thu, Oct 16, 2014 at 1:02 PM, William Rentfrow <
> [email protected]> wrote:
>
>> **
>>
>> I sent this to our premiere support person and manager, but I'd be
>> interested to see what others have to say about this too.
>>
>>
>>
>> Original message below:
>>
>>
>>
>> Hi –
>>
>>
>>
>> This came up on our call and I wanted to write it out.
>>
>>
>>
>> BMC has stated that the Windows User Tool (WUT) is going to be
>> discontinued (in fact, it already was in 7.6x). What I need to know is
>> what is BMC’s recommendation for diagnosing problems with the AR Servers in
>> a server group?
>>
>>
>>
>> Currently our users will report an issue like this: “Remedy is
>> slow/locked up/whatever”. Routinely we get no more information than this.
>>
>>
>>
>> Right now our troubleshooting is to first diagnose which server(s) is
>> having problems. The fast way to do this is to login to every server with
>> the user tool. We usually know within a few seconds if one of the AR
>> servers is locked up, because we will not be able to log in to it. Then we
>> can bounce it and get service restored.
>>
>>
>>
>> If they are responsive we then move on the Mid-tier servers, etc.
>>
>>
>>
>> With a large load-balanced environment there is no way to * QUICKLY* do
>> this without the WUT. I could login with Developer Studio, but that
>> doesn’t use the same threads on the server as the WUT does. We have seen
>> instances where users are locked up and admins can log in with Dev studio
>> (and vice versa). Same goes for migrator and the import tool.
>>
>>
>>
>> Support suggesting checking the AR Error log, but there are two problems
>> with that – first, many lock-up scenarios do not results in errors in the
>> arerror.log file. There are numerous other logs to check on every server
>> as well (CMDB, Email, AIE, etc). Checking every log file on every server
>> is time consuming and not 100% guaranteed to show us which server is locked
>> up.
>>
>>
>>
>> The second problem with support’s suggestion is the sheer time it would
>> take to login to each server. We are on Linux, so we need to connect via
>> SSH using putty. We do that by first connecting to a gateway server. Then
>> we ssh to the actual AR server (direct access is not allowed). Finally, we
>> sudo to the user Remedy is running as. That means each time we connect
>> it’s 3X we login. If we multiply that by the 10 servers in our server
>> group it would take at least an hour just to triage the problem.
>>
>>
>>
>> I can do the same thing with the WUT in seconds.
>>
>>
>>
>> So here is the question: What is the proper way to QUICKLY triage which
>> server is having problems without using the WUT or Dev
>> Studio/Migrator/Import?
>>
>>
>>
>> William Rentfrow
>>
>>
>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
>
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
