We have recently upgraded our environment to 9.3 and was told the Test environment was set-up exactly like Production. In each environment we have a Metadata Server, Application Server and Web Server all installed on AIX, and our client machines are Windows 7. No one ever uses the Test environment and there have been no changes to the environment, so I'm a little confused as to what is going on. I have checked the server logs and SAS Support but I haven't been able to find anything useful.

Has anyone out there experienced something similar or have any ideas on what I could try? I am definitely no SAS expert so any help would be much appreciated.

Re: SAS Connect Issue

Yes, I did get it resolved in the end. Sorry I forgot to update it here on this forum.

It was a relatively easy fix in the end. I had also logged a call with SAS Support who organised a WebEx conference. After about an hour or so checking our configuration they found the issue.

In the Properties of SASApp - ConnectServer, select the Options tab. Towards the bottom of this window is SIGNON Types, and another Options button. If you click on this, it will give you the Scriptless Options, which is Prompt for Userid/Password. This was set to 'No', so was changed to 'Yes', and voila, all sorted.

Like I mentioned earlier, an external vendor had created the autoexec for our Production environment, but hadn't documented the procedure. And me being fairly new to SAS, struggled to replicate it in our test environment. But glad it has been resolved now.

Re: SAS Connect Issue

The first thing I would ask is: has anyone else successfully connected to your test server? If yes check what they did for it to work. If no then there may well be a problem which is blocking everyone.

A search through SAS notes will bring up many potential reasons for your errors including Scott's one.

At this point you could consider raising a track with SAS Tech Support. They will be able to advise you on further diagnostics to do to identify the cause.

Re: SAS Connect Issue

Thanks for replying SASKiwi. I have asked someone else to test and they get the same error. I thought it may have been something with the SAS Test Connect User I have created as well, but I have been able to successfully create a Connection Profile for this user in SAS MC.

I actually have had a track open with SAS Support for the last couple of weeks, but they haven't been able to sort it yet, so that's why I have put something up on this forum.

The server (server side) please do not get confused it are just script file that are started

the classic SAS/connect is referring the spawner port and starts the script for the sas-process. This script file starting a SAS process is not being parameterized unless you build you own Connect script. That scripting language is a segregated part within the SAS/connenct documentation. SAS/CONNECT(R) 9.3 User's Guide

The metadata based SAS/connect is having that script with all other parameters being defined as part of metadata SAS/App servers. You can recognize all parameters being there as originally defined in the metadatabase. You can configure at .../Lev-/SASApp/Connect the OS usermod configuration-file in the same way as for a WorkspaceServer , Stored process Server etc.

No matter which method, classic/metdatabase, the started SAS session must have a valid OS-user being defined capable (authorized) doing the work you want.

The metadata-server approach of all parameters is still requiring started spawners new is that iit is for each one defines by a appserver. It still needs to be defined all Connect-options now not with a signon statement but needed for each known appserver a user want to get connected. I am wondering how to solve this when crossing boundaries definitions maintained by different metadatabases.

Remark:

The use of Rlink file is inherited from SAS V6, afterwards is was better an more easy to use the SAS-config setting. That is: sasconfig SASSCRIPT= SAS/CONNECT(R) 9.3 User's Guide and using CSCRIPT at the signon statement.

Now your issue question.

- You are connecting to "saspd1mds"

I hope this is a DNS-name when that is a single name it must be in the same network segment. Crossing network segments is asking fully names

- you are connecting the default app-server SASApp.

You did not segregate you usergroups in different ones to accomplish the business hierarchy?

- you are using a SAS internal account "SASConnectUser", this one can read SAS metadata.

How does that one possible start a SAS process on the OS-level? Where is the account for that.

Are you using a shared account for that being defined in the metadata with its associated password and is that correct working?

Are you expecting the users are using their personal account (defined at OS-level) in what way?

The error message you have is telling you there is something wrong at starting that sas script at the OS-level.

1. saspd1mds is our production metadata server. saststmds is our test metadata server. So basically the autoexec runs successfully in production using the SASConnectUser@saspw account. Therefore I have created a new account in test called SASTestConnectUser@saspw, encoded the password and updated the autoexec with the test server details.

2. I have also tried using the fully qualified name but I get the same error in test

3. Yes we are connecting to the default SAS-App server

4. We have a very basic set-up here, but I have mirrored the access in test off production

6. We had an external SAS consultant create the original autoexec and SASConnectUser for production, when we upgraded our environment last year. However they didn't document the process. Like I said I have tried to base this test account from the production account but obviously something is not right. I'm just wondering if they made a change to a config file on the server as well?

7. I have tried updating the autoexec with my credentials and other local sas accounts but get the same error. I have also compared the OS permissions between environments, but have had no luck.

Re: SAS Connect Issue

The --@saspw indication is an indication that user has only SAS-metadata access rights it is an SAS internal account.

You can connect to a metadata-server with that but as is not existing on the OS level you can not run any SAS processes with that.

You described a situation it succeeded in doing so, there must be a trick behind the curtains you have missed.

I am trusting the spawner port is working (default 7551).

You could check the mirror of production process is some server-name within the metadata could still point to you production server.

A SAS/connect session on a server is running by an OS-account. You can verify that on your prod machine. Choose a silent moment on that machine, start the connect session. Check the running processes before and after (ps -ef ...). When verifying that I hope you will find a process started by your personal key. When you find a process started by a generic account that is important information as then you should ask yourself where that one is coming from.

Let us make a checklist:

a- verify the SAS/connect is attempted on your indicated machine not on a other.

Search the metadata en SAS/connect server loggings for those events.

b- verify the account that SAS/connect is running at OS-level of your operational machine (this cannot be the SAS internal account)

c- verify the authdomain setting that is (possible) associated with your Connect-server definition in the metadata

This can be the hidden trick to use different users/passwords.

d1- having that account (b) verify the scripting and settings at the OS-level are correct

Do a login with that account at the OS-level.

Go to the (config) .../lev1/SASApp/ConnectServer and start the *.sh script found there (use X11 mode)

When there are OS-errors or SAS errors it will give better understandable error messages. Solve those when occurring.

It could be as easy as a missing home-dir for the used account.

d2- having that account verify the way the SAS-metadata to get that account with password from the metadata. It must be somewhere there as you are not typing that

It could be a group membership with your SAS internal account, but somewhere there must be a login-field in the SAS-metadata having that necessary information.

Re: SAS Connect Issue

Since you can connect OK to the test SAS server via SAS MC that suggests that the server is fundamentally working OK. I suggest you look at the SAS metadata server log for evidence of what is happening when you connect from PC SAS. This log should have error messages relating to your failed connections and may offer some further clues as to what is wrong. Jaap's test is a good one too.

I have also been checking the metadata logs in both environments, and from comparing them both, it looks like the connection for SASTestConnectUser is being accepted.Prod:SASConnectUser@saspw. Encryption level is Credentials using encryption algorithm SASPROPRIETARY. Peer IP address and port are [::ffff:10.64.7.110]:49170 for APPNAME=SAS.2014-04-09T09:10:40,919 INFO [07234153] 134718:sas - Client connection 134718 for user SASConnectUser@saspw closed.2014-04-09T09:10:52,276 INFO [07234155] ASConnectUser@saspw - New client connection (142042) accepted from server port 8561 for user SASConnectUser@saspw. Encryption level is Credentials using encryption algorithm SASPROPRIETARY. Peer IP address and port are [::ffff:10.64.7.110]:49173 for APPNAME=SAS.

Then if I look in the sav9_usermods.cfg, on Test (/opt/sas/sas93/config/Lev2/SASApp) there appears to be an entry for SASUSER (-SASUSER /sasdata/sasuser )

/* * sasv9_usermods.cfg * * This config file extends options set in sasv9.cfg. Place your site-specific * options in this file. Any options included in this file are common across * all server components in this application server. * * Do NOT modify the sasv9.cfg file. * */

The thing I don't understand is why this entry is not in our production environment. The file in prod is very similar except for that entry (not sure why it is not on the next line, but I have also tried dropping the entry to the next line). In Test, we have a directory called sasdata/sasuser but can't see this in Prod. I can see a sasusers directory in both environments, but only the directory in production has user profiles.

1/ Your personal account in the prod-system is "vellis" (pid=19071220) and is that account running the spawned process for connect (pid=25821360) . That sasels process is coming from your SAS/connectproces (Pid 18481230 - 25821360)

It is not the internal SASConmectUser@saspw. As you have proved this, where is the account "vellis" coming from in production?

As you are saying to do a login with that internal account, the result is something different. why? how? What are we missing?

2/ The metadata server log is as you have given are describing correct actions and the mentioned users are coming in.

You changed the portnumbers being the suffix 1-=series to 2-series. This is smart and sensible as very recognizable also for firewalls/networking domains.

In production there is process started, no immediate close. In test it is closed immediate. We already are knowing is, the log is having that same information too.

3/ The local generic account "sas" is running the connectspawner (pid 5636288) and is that doing since may for prod. The test also running (pid=11337962) since 9 apr.

The connect spawner port are nicely there 7551 for the prod machine and 7552 for the test machine.

Within these startups a logfile is mentioned (ConnectSpawner_saspd1cts.log ConnectSpawner_saststcts.log) is there information in? when not you could exchange that temporary for the logconfig.trace.xml (intention debugging) at your test-machine, restart the Connectspawner and do some tests.

I am missing your attempts to connect using port 7551(prod) 7552(test) directly with a signon command in the classic approach.

I am also missing the results for query-ing the SAS metadata with a signon command and than doing the Serverv.....

As you change port numbers and a lot more I am convinced you did a clean configuration trying to achieve a similar installation.

Running a process since May, that is in the future in his moment (10 apr 2014). It is telling that process was never restarted since last year.

Hopefully nobody did change anything on that machine. All security information in a Unix approach is cached at startup and this cache is never refreshed.

Imagine a security change having impact on your processes. You will only notice that as you need to restart them. Never mind spawners are not very critical suffering on this.

4/ Starting that ConnectServer.sh script you are seeing the handshake of a Connect-session start. That SAS process is responding with a Portnumber that is used in the to be port-port communication of SAS/connect sessions.

Your note 18527 is of the old time (v8) but is valid for a possible root-cause in this case a failing SASUSER location.

The usermods file somebody added changed by hand, normally it is left empty. The name is "usermods" intentionally.

The Work must be a valid location and accessible to all sas-users it is something like /tmp of Unix. /tmp is setup with the access rights 3777 (gid-bit and sticky bit) for valid reasons. What is your access to /saswork?

The SASUSER should be a valid location for your users. Normally that is: "/home/<user>". You definition is strange in this config-file.

For my head. It is possible to start this ConnectServer.sh with options so you can use that in terminal mode. have an X11 server started, your DISPLAY environment being set and use parameters -terminal -dmr (and ? ) with that script. It will not give you that port-number but a normal SAS session.

This is what I see in the ConnectSpawner_saststcts.log. I am pretty sure I have checked this previously but haven't seen these Permission Denied error which are concerning. I have checked the internet and forums but haven't been able to find anything useful regarding this error.