WebGUI issue: HTTP 400. dev_icm referencing an old server (system copy)

[Former Member]

Hi all

I'm trying to set up WebGUI for a new system (system copy via export/import) and I've followed all the usual steps i.e.

set profile parameters:

icm/server_port_0 PROT=HTTP,PORT=8000

icm/host_name_full <Full Qualified Domain Name>

Transaction SICF, services started:

/sap/public/bc/its/mimes

/sap/public/bc/ur

/sap/bc/gui/sap/its/webgui

Transaction SE80 locate from the menu, Utilities --> Settings-->Internet Transaction Server (Tab)-->Publish

(Tab) and set “On Selected Site” = INTERNAL.

This restricts the publication in the next step to the integrated (internal) ITS.

In SE80 only, Locate the Internet Services: SYSTEM and WEBGUI.

Publish these services with the Context Menu -> Publish -> Complete Service

Also ran SIAC_PUBLISH_ALL_INT to republish anything else required.

Browsing to http://<server>:<icmport>/sap/bc/gui/sap/its/webgui/ presents the login page - all good so far.

However, when I log in, I get a "Service cannot be reached" error, "HTTP 400 - Session not found".

This is a 701 system (so note 1301591 doesn't apply - SICF_SESSIONS transaction doesn't exist)

I've just checked dev_icm trace file and see the following error:

*** WARNING => Connection request from (7/8/0) to host: <oldservername.domain.com>, service: 5720 failed

(NIEHOST_UNKNOWN)

Note that <oldservername.domain.com> is NOT my server name, but I think the name of the original system (remember this is a system copy).

I've searched through the profile parameters, and also checked table HTTPURLLOC, but I can not see any references to this old server name.

Where could this be defined/how do I remove it/update with the correct server name?

Thanks!

Ross

[Former Member · Accepted solution]

Finally fixed this one!

I think lots of factors were involved, but I entered up re-addressing an OSS note I'd come across previously. It didn't help at that stage; but I believe that's because I had an issue with port 8000 being closed on the networks side. Now that's been opened, I had another look and the note (1301591 - HTTP 400 - Session not found (Stateful HTTP communication)) looked like it could be relevant - lo and behold, I set icf/user_recheck=0 and the issue has been fixed!

Thanks all

[Former Member]

Hi all

It's been a while since I had a look at this one, the project is on hold and the client hasn't authorised me to continue looking at this, but for peace of mind/curiosity/the fact they may again want me to take a look at this, I want to try and get to the bottom of the problem.

It came to mind that the port may not be open (although I was sure I'd opened port 8000 via iptables earlier) so I tried "telnet hostname.domain.com 8000" and I got a "Could not open connection to the host, on port 8000: Connect failed" error.

I checked my parameters and they appeared to be set correctly:

icm/server_port_0     = PROT=HTTP,PORT=8000,PROCTIMEOUT=7200,TIMEOUT=7200

I then double checked the port was open in Linux:

nmap -sT -O localhost

PORT      STATE SERVICE

...

8000/tcp  open  http-alt

So that all looks ok. I also ran it for hostname.domain.com as well as localhost, with the same results.

I then realised that there were multiple IP addresses involved. If I run ifconfig I get:

lo 127.0.0.1

eth1 10.x.x.x

eth2 172.x.x.x

Which is weird as the server I'm ssh-ing to has a 58.x.x.x address, and hostname.domain.com maps to that from Windows (pinging, and going via the browser).

So I tried "telnet 172.x.x.x 8000" instead, and that works - the port is clearly open/connects.

So I figured perhaps the 172. address is the 'external' address that I should be using for the browser. However, I tried entering "http://172.x.x.x:8000/sap/bc/gui/sap/its/webgui/" in the browser and it doesn't work - it will ONLY work with the 58. address.

Another odd thing is, I can ssh onto the box via the 172. address - but I can't ping it from Windows (I guess ping could be blocked as it's an external IP address?).

If I ping "hostname.domain.com" from the Linux server (rather than Windows) that actually comes back with the 172. address too, not the 58. address.

This is all a little confusing, but not necessarily "wrong".

I can get to the front page of the GUI, click login and enter my username and password, all with the server name (58. address) and port 8000 - that works (so surely it CAN get through to port 8000, at least it can at that stage!) - it's only when it then accepts my login details that it then fails with the 'service not available' error - so could this still be down to some service not running in SAP?

I.e. how can I rule out one thing or the other to try and get to the bottom of this problem?

Just to clarify: I'm not longer getting the 'old' server name entries in the host name buffer, I believe that issue has gone.

Regards

Ross

[JPReyes]

Hi Ross,

It might sound simple but make sure reference to the old system is not found in SMLG, RZ03/RZ04, etc... as this can be one of the side-effects

Regards, JP

[Former Member]

Hi

Thanks, I'd checked SMLG but not noticed the old entries in RZ03/RZ04! I have deleted those and created new ops modes with the correct names now... unfortunately it hasn't helped.

I've looked around more and found the 4 HTTP RFC connections below have the incorrect old server name in too:

However, I'm not able to edit these to correct them.

Any ideas?

Ross

[Former Member]

Progress!

Cleared the old entries in several places and noted that the server names were slightly different... it seems the ones that the WebGUI is redirecting to is the old Optical Archive server.

Checked in OAC0 and I can see that there are 3 ARCHLINK Content Repositories referring to HTTP Content Servers pointing to that server name!

Now, that's an old server, and not accessible from this network.

So, what to do?

Change the server to my server name? But if it's archived documents.... surely they won't be there anyway?

Remove the repositories???

[Former Member]

Hello Ross,

I believe you performed system form prod system to non-prod. In that case

Yes, you can remove the repositories or point/change the repositories to the corresponding non production servers.

thanks,

Hardeep

[Former Member]

Thanks Hardeep, I have now removed these but it hasn't helped the issue - I still get the HTTP 400 error and the dev_icm log shows the old (Archive log) server...

[Former Member]

This is what I have in the ICM host buffer right now:

web1 and web1.domain (blanked out for privacy reasons) is CORRECT.

The 'yellow' triangle atsl entry is the old incorrect one that comes up in dev_icm.

Still can't work out where this is coming from... no proxies should be involved...

[Former Member]

missed image from last post

[Former Member]

I can see that the ICM host name buffer has the incorrect server name in it.

If I clean this out (from SMICM or from SM51 - reset all) then it disappears, but as soon as I use the WebGUI again it reappears.

At one point, the correct hostname DID appear in the buffer - but the old incorrect one was also there - and the WebGUI still didn't work.

Did another reset, republished services etc, and back to just the old one in there.

Upped the trace level for ICM to 3, but nothing useful reported - still can't see where it gets this old server name from.

I also checked 773830 - FQHN determination in ICM and I can see SAPLOCALHOSTFULL is set and showing the correct name (by running SE38 RSPARAM).

Any other ideas where this could be coming from?

[cris_hansen]

Hi Ross,

Can you share the kernel (7.21) patch level you are using?

Thank you,

Cris

[Former Member]

721 patch 402

[cris_hansen]

Hello Ross,

You can also try some tests suggested in this wiki page.

Regards,

Cris

[cris_hansen]

Hello Ross,

I tried to find kernel corrections from pl 402 to 714, but no match for hostname cache or similar.

I think this is really a cache problem (something is telling me that might be related to HTTPURLLOC, even though you have already ruled out this possibility).

Cris

[Former Member]

Thanks Cris, will take a look

[cris_hansen]

Hello Ross,

Do you use a kernel 7.20 or higher?

Have you set:

~webgui_new_design 1

in the GUI Configuration of the WEBGUI service in SICF? (path = /default_host/sap/bc/gui/sap/its/webgui)

You can also check whether you have something in your hosts file, that points to the old server.

I also would try a ICM trace level 3 and see what is happening in the ICM.

Worst case scenario: wireshark trace and see from where the old server name is being fetched.

Kind regards,

Cris

PS: If you already have ~webgui_new_design in place, then publishing the services via SE80 is no longer required (SAP note 2264828).

[cris_hansen]

Hello Ross,

Another SAP notes that might worth to read:

611361 - Hostnames of SAP servers

129997 - Hostname and IP address lookup

124562 - Hostname resolution problems (DNS timeouts)

Kind regards,

Cris

[Former Member]

Thanks for the response.

We have a 721 kernel.

I tried setting webgui_new_design but this doesn't help.

Nothing in the hosts file that points to the old server. The old server name isn't known in DNS either. So I feel it must be in a config table somewhere...

I'll try an ICM trace next... don't have access to wireshark I'm afraid.

[cris_hansen]

Hello Ross,

You can also record a Fiddler trace - maybe you can find something odd there.

Kind regards,

Cris