on 03-28-2014 3:28 PM
Hello,
im am running HANA One on SP7 Rev 70.
During some research I came across this document: http://awsmedia.s3.amazonaws.com/SAP_HANA_on_AWS_Implementation_and_Operations_Guide.pdf
Although it is not specific for HANA One, the topic "OS Security" seemed interesting:
"Operating system patches are the responsibility of the customer and should be performed on a periodic basis. The
command “zypper up” will update SuSE Linux to the latest patch level available in the SuSE Linux repos on AWS."
Since my HANA One is running for nearly 5 Months now without any OS Update I thought this might be a good idea.
I started with my developer instance - all working fine after the update and a restart of the instance.
Then I did the same on HANA One. After the update, the database is running just as usual - Client, XS-Engine everything is fine.
But now I wanted to log in to the management console --> wrong password
Somehow strange, but resetting the password didn't work either.
So I looked into the Network-Response sent to the Browser:
https://myhostname/cgi-bin/validateUserHash.cgi
{"step": "doingInports\nException: could not import config stuff.\nException type: <type 'exceptions.Exception'>\nFilename: validateUserHash.cgi\nLine number: 41", "response": "230"}
Obviously it is not a problem with the wrong password, but the backend-scripts are broken now.
looks like this section in the .cgi is causing the problem:
''' checking all the imports here '''
someStep = 'doingInports'
try:
sys.path.append('/srv/www')
import config
sys.path.append(config.env.HANAONE_SCRIPTS)
except:
someResponse = 230
raise Exception, 'could not import config stuff.'
--> I guess the import config is responsible for the exception.
How can I solve this problem?
Kind Regards,
Fabian
Hello Fabian,
Here are the some options that we can try
1. We tried to reproduce this as follows
Instantiating a Productive Instance
Upgrading to latest addon.
Ran a Zypper update.
Rebooted the Instance.
We did not experience this issue as indicated.
2. In terms of getting you back quickly, we can recommend the following.
Restore a existing Backup from current backup into a new AWS Instance.
While transferring data from old server to new server please use hdbadm as user.
Alternatively, you can change ownership to be hdbadm.sapsys for the directory.
3. We do not know what exactly change at the filesystem level. If you share your credentials, we can try to debug the issue. This can take quite some time and outcomes are not always what we expect, but we would be more than happy to take a look into this.
thanks,
dhruman
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Dhruman,
if you give me your email address,I can give you SSH access. I would really appreciate if you could solve this problem this way.
Currently I don't need option 2 (yet?) because all services are running fine (only MMC --> no updates). Also if I deploy a new instance I will have to do quite a lot of configuration again which is not covered by the backup/restore like SSL-Certificate for XS Engine, installing and configuring aws toolkit for S3 Up/Downloads, ...
Thanks for your help,
Fabian
Hello Fabian
After OS update, Hana One environment is broken. Please run the setenv.sh script for the root and hdbadm users.to reset the Hana One required environment variables.
Thanks
Shankar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe this is the problem:
Executing this script doesn't set the environment variables:
hanaserver:~ # echo $HANAONEENV
hanaserver:~ # /usr/sap/tomcat/bin/setenv.sh
hanaserver:~ # echo $HANAONEENV
hanaserver:~ # sh /usr/sap/tomcat/bin/setenv.sh
hanaserver:~ # echo $HANAONEENV
hanaserver:~ #
I tried executing it directly (see first command) and via sh. Both have no effect.
First lines of the script:
if [ "$HANAONEENV" == "" ]
then
export HANAONEENV="YES"
Same with hdbadm user.
Kind Regards,
Fabian
The reason the env variables don't appear to be being set is because they are only being set for any subshells of the bash shell you've executed the script in. To have the changes take effect in the current shell, you must execute the command like so:
source setenv.sh
See this Stack Overflow question for more info.
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.