Guru Of Geeks

This means that WordPress is having limited permission for making changes in the folder that it was installed. In-order to fix this, all that you need to do is provide necessary permissions for the same. Run the following Command in your Terminal / Putty / Commandline Prompt after connecting to your Server via SSH: sudo chown - R apache : apache / var / www / html

Resolving The Problem The automatic session expiry can not be prevented. However, you can change the session expiry time.The default session expiry is set to 760 minutes. Use the WebSphere Application Server admin console to change the expiry time: 1) Open the WebSphere Application Server web admin console (https://<domain>:9043/ibm/console/login.do?action=secure) and login as the WebSphere administrative user (not the Information Server administrative user) 2) Open the Security -> Global security pane from the left hand tree 3) Open the LTPA link in the content pane 4) Change the 'LTPA timeout" value from 760 to the desired value. 5) Stop and restart WebSphere Application Server

Resolving The Problem To resolve the issue, you need to increase the maximum heap size for EngMonApp by following these steps: 1. Log into server as dsadm or root. 2. cd InformationServerRoot/Server/DSODB/bin/utils_private/ 3. Back up the DSEngMonApp.sh file cp -p DSEngMonApp.sh DSEngMonApp.sh.bak 4. Edit DSEngMonApp.sh file to increase -Xmx384m, for example to -Xmx896m (896 megabytes). #$APW_NOHUP_CMD "$JAVA" -DPSMARKER=$PSMARKER -Xmx384m -classpath "$CLASSPATH" com.ibm.datastage.runtime.engmonapp.EngMonApp 1>&2 & $APW_NOHUP_CMD "$JAVA" -DPSMARKER=$PSMARKER -Xmx896m -classpath "$CLASSPATH" com.ibm.datastage.runtime.engmonapp.EngMonApp 1>&2 & You may need to try different -Xmx values until you find an adequate heap size. 5. Restart EngMonApp by starting the DataStage AppWatcher service: InformationServerRoot/Server/DSODB/bin/DSAppWatcher.sh -start on unix as the DataStage administration user (e.g. dsadm).

View List of Available SDK Names Use this command to view a list of available SDK names for the product installation: managesdk.sh -listAvailable The following shows sample returned information. Set the command default to the version 7.0 SDK Use this command to set the command default to the version 7.0 SDK: managesdk.sh -setCommandDefault -sdkname 1.7_64 The following shows sample returned information. Set the New Profile Default to the Version 7.0 SDK Use this command to set the new profile default to version 7.0 SDK: managesdk.sh -setNewProfileDefault -sdkname 1.7_64 The following shows sample returned information. If Profiles Already Exist, Enable the Profiles to use the Version 7.0 SDK If profiles already exist, use this command to enable the profiles to use the version 7.0 SDK: managesdk.sh -enableProfileAll -sdkname 1.7_64 -enableServers The following shows sample returned information.

Open the global.ini file  /hana/shared/$SID/global/hdb/custom/config/ global.ini   ​ ​ Restart the services.

Secure the communication between HANA Server and HANA Studio through SSL. It is highly recommended when there are lot of sensitive data handled in the system, which you want to secure from the middle-man attacks. There could be multiple documents available in SCN on this topic, but here I wants to show my experience on setting this up, in short time. Pre-requisites: HANA Server is installed and running HANA studio is installed in the local system Access to the HANA server Putty / WinSCP tools HANA Server and client without SSL configured: Steps need to be performed in HANA Server: Login to HANA server system using Putty, as a root user and check if the libssl.so file exists. If not, create a symbolic link to libssl.so.0.9.8. Now login to HANA server system, as a "<sid>adm" user. Create the Root Certificate: Go to Home directory "/usr/sap/<sid>/home" Create directory with a same ".ssl" Get into ".ssl" directory    4.  Execute the f...

https://github.com/satterly/AWSCloudFormation-samples