SLD Migration and gw/acl_mode
Almost every SAP installation today has one feature in common, and that is the presence, somewhere in the landscape, of SLD, or System Landscape Directory. For many, if not most, customers, SLD is integrated with another necessary component, Solution Manager, on the same system, as this is a very quick and easy way to get a basic SLD up and running, and the integration with Solution Manager is practically built-in. Other customers may have had their first SLD as part of a PI installation, and much of what follows below may apply in the same manner.
Maintenance Downtime Dependencies
If you use Java software components in your productive landscape, such as pre-WDA ESS or MSS, or your own custom Java WebDynpro developments, these components depend upon the availability of SLD in order to function. ABAP systems do not have this dependency; if SLD is down, the periodic synchronization of system data will fail, but this will go completely unnoticed by end users, as the system itself and its applications continue to operate just fine. Java and Portal systems themselves also continue to operate in the absence of SLD, but the Java WebDynpro software components will fail.
This means that SLD maintenance has a production impact, and so typically must be scheduled for maintenance windows outside normal business hours.
If your SLD is integrated with Solution Manager, this same restriction therefore applies to Solution Manager maintenance. Note, depending on which SolMan scenarios you utilize, you may have this restriction anyway, but if your primary purpose for SolMan is Maintenance Optimizer and landscape monitoring, then your Basis team may be quite frustrated by the need for production downtimes in order to maintain it.
Restriction to Older Release
Solution Manager is currently in release 7.1, but the underlying NetWeaver release is 7.02. This means that your commingled SLD will be release 7.02. However, newer releases of SLD, beginning with NetWeaver 7.1, have some significant enhancements which are simply unavailable to you while SLD is part of Solution Manager. See How to Get an SAP NetWeaver 7.1 System Landscape Directory? and How to Ensure that SLD Data is Available during Maintenance for some reasons why a newer SLD may be advantageous.
Load Balancing and Redundancy
You also may simply want a second, or multiple, SLDs for purposes of redundancy and load balancing, especially if you have a busy landscape with many WDJ components.
Many customers therefore seek to separate SLD from Solution Manager, migrating it to its own system, and thus insulating it and your production landscape from Solution Manager maintenance activities. A number of documents describe this process, so this isn’t the main focus of the current post. However, here’s a quick overview of the process, along with links to more detailed documents for each step:
- Install new AS Java (currently in release 7.4 SR1)
- Temporarily register it in existing ‘old’ SLD
- Update AS Java to latest support package stack
- Enable SSL, create administrative users
- Initially configure new SLD
- Post-Installation Checklist – Configuring, Working with and Administering System Landscape Directory – SAP Library
- Configuring System Landscape Directory – AS Java Configuration – SAP Library
- This includes the following step, and using it to configure the “System Landscape Directory” functional unit only
- Migrate content from old SLD to new SLD
- Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1
- SLD and LMDB Topology: Replacing the Source SLD for the LMDB
- Once the initial unidirectional content sync is complete, the new SLD should continue periodically pulling data from the old SLD. The old SLD, being release 7.02, is not compatible with bidirectional sync, so this is one-way.
- The above procedures should also result in your LMDB (part of Solution Manager) now receiving data exclusively from the new SLD.
- Configure data suppliers to sync to new SLD
- A number of documents describe this process, but here’s a good one to get you started:
- Disable old-to-new SLD content sync
The New Problem
You’ll notice I’ve highlighted step 6 of the solution above. This is because you will likely run into an unanticipated issue here with your ABAP systems. Your Java systems, generally, will probably synchronize with the new SLD without much hiccup, but your ABAP systems, including the ABAP stack of your Solution Manager system, will encounter RFC gateway errors. The SAP_SLD_DATA_COLLECT job will record something like the following in the generated spool file:
Collection of SLD data finish
Data collected successfully
RFC data prepared
Used RFC destination: SLD_UC
RFC call failed: Error when o
So, you’ll check SM59 and the SLD_UC RFC connection will fail a connection test. You’ll wallow about looking at gateway ports and services, checking RFC listener statuses, etc (Tom Cenens has a great post about the things to check that could go wrong at How to push ABAP system data to a Java only SLD).
When you have ensured that everything is configured correctly, that’s when you realize there is a (mostly) undocumented step in configuring the security on a gateway in newer NetWeaver releases. There is a small text file which you must create and populate appropriately, and the documentation on the need for this is mainly found in SAP Notes (see Notes 1843782: GW: Installation changes default from gw/acl_mode to 1, 1480644: gw/acl_mode versus gw/reg_no_conn_info, and especially 1069911: GW: Changes to the ACL list of the gateway (reginfo)).
What is happening here is that a kernel parameter, gw/acl_mode, which has existed for a long time, had its default setting changed from 0 to 1 for new installations of NetWeaver 7.0x and higher since the end of 2012. If your Solution Manager was installed prior to then, then you had the old behavior. Your new SLD has the new behavior.
So what does gw/acl_mode = 1 do?
It causes the gateway to reject registrations from external servers by default, instead of accepting them. This is a security enhancement, and a good thing, but it means you must do a little more configuration if you want your ABAP systems to be able to register themselves to your new SLD. You may see advice in the forums to set this parameter to 0, and that will work, of course, but it is not the preferred solution. Setting the acl_mode to 0 opens up your system to potential attack (though this was of course the default setting in the past).
You probably won’t actually find this parameter in your SLD instance or default profile, which means it will be at the default setting, i.e. “1.”
With this setting, the system will check for the existence of a reginfo or secinfo file. However, by default, these files don’t exist unless you create them. In the absence of explicit instructions coded into these files, the system reverts to the default behavior of rejecting registrations from all external systems, and thus your SLD updates from ABAP systems are not occurring.
The preferred method for allowing external systems of your choosing to register with the gateway, and thus with SLD, is to create the permissions file. The default location for the file is \usr\sap\<SID>\SCS<nr>\data, and the default filename is REGINFO.DAT. You won’t find this file there in a fresh installation, however, so you must create it yourself.
Note 1069911 (linked above) and Note 1105897 (GW: reginfo and secinfo with permit and deny ACL) between them give an overview of the ways you can format the reginfo file, but the bottom line is that you need something like the following in it:
P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*
The file is case-sensitive, so you must user upper-case on the keywords (VERSION, TP, HOST, etc). Also, the first line must have “#VERSION=2” or the gateway will register an error on startup in the trace and not parse the rest of the file.
The following lines (there can definitely be more than one) will start with either P (Permit) or D (Deny). There are four keywords (TP, HOST, ACCESS, and CANCEL) to be specified, each with their own list or range.
TP is where you specify the registration ID of the external server program. Wildcards are allowed. In the case of SLD registrations, the external servers register using either SLD_UC or SLD_NUC, depending on whether they are Unicode or Non-Unicode systems. In some scenarios, they might also have a SID listed as part of the registration or program ID, but it will always begin with SLD_. Therefore, “SLD_*” works as a pattern to ensure the registrations are only SLD-related.
HOST is where you can specify host or domain names, or IP addresses or subnets, that are either permitted or denied. You could use “*.yourdomain.com” to allow all hosts within “yourdomain.com” to register, or you could use an IP subnet, such as 10.x.x.*, if all your SAP servers are on this same subnet. You can create comma-separated lists as well, but do not use spaces between the items in the list, only a comma. There are other ways to get more complex about using the HOSTS keyword, and I recommend checking Note 1069911 (linked above) for more details.
ACCESS is very similar to HOST. The difference is that HOST specifies the servers that are allowed to log on, whereas ACCESS specifies the servers allowed to use the registered server. It’s a very specific difference, and in most cases you will probably have exactly the same list for HOST and ACCESS. Again, see the Note for details.
CANCEL is the list of servers allowed to log off. Again, you will probably have the same list for CANCEL as you do for HOST and ACCESS.
For all three, HOST, ACCESS, and CANCEL, the local system is always included (permitted), so you don’t need to specify it explicitly. You only need to specify external systems.
So, if all of your SAP systems are on the subnet 10.50.15.x, as an example, then your REGINFO.DAT file will probably look like this:
P TP=SLD_* HOST=10.50.15.* ACCESS=10.50.15.* CANCEL=10.50.15.*
If you need something more complex, I strongly recommend perusing Notes 1069911 and 1105897 carefully.
After creating your REGINFO.DAT file, there is no need to completely restart the J2EE instance. It is enough to restart the gwrd process of your SCS instance. If everything is formatted correctly, the trace file for gwrd (dev_rd in the SCS work folder) will show this one line during startup:
GwIRegInitRegInfo: reginfo version = 2
In the work folder, the gw_log file (with datestamp) will have a set of lines similar to:
(re)load reginfo file X:\usr\sap\<SID>\SCS<nr>\data\reginfo.DAT, version=2 (2 entries)
P TP=SLD_* HOST=10.x.x.* ACCESS=10.x.x.* CANCEL=10.x.x.*
And, of course, the RFC connection will now test successfully and registrations will succeed.
For an overview of best practices, how-tos, and planning guides related to SLD, I recommend visiting and bookmarking More on System Landscape Directory, maintained by Wolf Hengevoss. Most of the documentation available for SLD is linked from this highly informative page.