TcServer create a cluster-node template based on tomcat-8 - tomcat8

I am using TcServer Release 3.1.0 on a Windows Environment, specifically the "cluster-node" template, the problem consist that when I run the command to create the server it's based on tomcat-7, and I need it to be based on tomcat-8, here is the command that I am using it:
tcruntime-instance.bat create myserver1 --template cluster-node
and here is the message that i get from the command prompt:
Applying template 'base-tomcat-7'
Reading on the documentation it says that depends on the tc Runtime version to select between "base-tomcat-7" or "base-tomcat-8" to be used by the instance, so any ideas to make mandatory apply the base-tomcat-8?
Thanks in advance.

That tc Server version defaults to tc Runtime 7. You need to pass in the --version parameter specifying the 8.0.XX version along with the templates you want.

Related

WHMAPI1 Addpkgext Package Extensions Key Value (cPanel)

I am trying to run this WHMAPI1 command using the shell to add package extensions to a package using the guide https://api.docs.cpanel.net/openapi/whm/operation/addpkgext/
We have created 3 Package extensions and working well on the WHM interface, but we need to activate these extensions from WHMAPI calls.
The command we are using is :
whmapi1 addpkgext name=samplepackage _PACKAGE_EXTENSIONS='ext1=value ext2=value ext3=value'
On the guide, it clearly says we can use Key=Value pairs in the command but when we run the above command, it returns -
metadata:
command: addpkgext
reason: Package extension value is invalid.
result: 0
version: 1
I am getting the same result when I use "addpkg", "editpkd", or "modifypkg" API functions.
Can anyone help me sort this?
Thanks!

Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ

On AzureML Batchendpoint, I'm recently hitting the following error:
Unable to get image details : Environment version Autosave_(date)T(time)Z_******** provided in request doesn't match environ.
when I setup the batch-endpoint with a yml config:
environment: azureml:env-name:env-version
So, AzureML creates and builds the environment with the version I specify env-version, which is just a number (in my case = 3).
and then for some weird reason, AzureML creates an extra environment version called Autosave_(date)T(time)Z_********, which is not built, but based on the previous one just created, and then it becomes the latest version of that environment.
In summary, AzureML instead of looking for the version that I specified as env-name:3 it seems to be looking for env-name:Autosave_(date)T(time)Z_******** and then throws the error message mentioned above.
I found the problem was that when creating an environment from a YAML specification file, one of my conda dependencies was cmake, which I needed to allow installation of another python module. The docker image is exactly the same as a previously created environment.
Removing the cmake dependency from the YAML file, eliminated the issue. So the workaround is to install it using a Dockerfile.
The error message was very misleading to start with, but got there in the end after understanding that AzureML reuses a cached image, based on the hash value, from the environment definition accordingly to this
So for that reason, the automatically created Autosave docker image references to that same build, which only happens once when the first job is sent.

Liquibase Installation Troubleshooting

Liquibase was install in the following location
C:\liquibase
when I run the following command on cmd,
liquibase
I get error
the system can not find specified path
I added liquibase to system variable
when I run the following command on cmd
java -version
The following output is displayed
java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) Client VM (build 25.271-b09, mixed mode, sharing)
I also tried navigating to C:\liquibase and ran
liquibase --help
and the output was
the system can not find specified path
Any suggestion on what should be adjusted to run liquibase?
After deleting JAVA_HOME variable that was set on user variables, the issue was fixed. See the following image that shows the user and system evironment variables, the user variable that was deleted is indicated surrounded by a red rectangle.
You need to add C:\liquibase to your Path variable in order for liquibase.bat file (which is located in C:\liquibase) to be accessible from any location.

The local psql command could not be located

I'm following the instructions found here.
When I try to run $ heroku pg:psql or $ heroku pg:psql HEROKU POSTGRESQL_BROWN I recieve the following error message:
! The local psql command could not be located ! For help
installing psql, see local-postgresql
I can't find anything useful on the link it gives me (it just links to the instructions I was already using, but further down the page) nor can I find this error anywhere else.
If I've missed anything you need to know to answer this, just let me know. I'm rather new to all this and teaching myself as I go.
I had same error even after installing Postgres locally.
But after seeing this
I saw that "pqsl" was not in the PATH so I then did
PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin
which worked for me
I have since solved this myself. When I ran heroku pg:info it says the version number is 9.1.8, I was locally running 9.2
installing 9.1.8 and ensuring Path pointed to the appropriate folder solved the problem.
After you change the path, make sure to restart the terminal!
Set the PATH. To find out the PATH of your psql script (on mac) open the sql shell script from your finder in Applications/Postgres installation. This will give you a hint as to where it is installed. That opened a window which told me it is located here: /Library/PostgreSQL/8.4/scripts/runpsql.sh
Then, I set the PATH variable from the terminal window by typing:
$ PATH="/Library/PostgreSQL/8.4/bin:$PATH"
(depends on the location of your PostgreSQL installation, find your bin path first, another exp: /usr/local/Cellar/postgresql#9.6/9.6.8/bin)
OR.....
You can also connect to the shell by opening the shell directly from your postgres installation folder. Then enter the credentials. If you don't know the credentials, here is how to find them out:
$ heroku pg:info
=== HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)
$ heroku pg:credentials HEROKU_POSTGRESQL_RED_URL
Top answer wouldn't work for me oddly, my system would not add the Path via cmd with administrator access (Not sure why).
So check this > Windows key > environment variables > system variables
And add the last line (your version may differ in the path)
Make sure you've installed the toolbelt as psql is installed by default.
However you also need to ensure you've installed a local copy of PostgreSQL; if you don't the toolbelt will be unable to find the native psql client.
Assuming you have installed a local copy of PostgreSQL, make sure you can execute psql from the command line directly (i.e make sure you PATH is set correctly ). If the command does not execute, check your PATH, if it does execute see if you can connect via the PSQL connection string provided in the Heroku control panel. If you can connect reinstall the toolbelt, if you are unable to connect provision another dev database and try again.
If there are still issues, I would suggest contacting Heroku support for assistance after verifying no API issues are listed on the status page located here.
I got rid if this annoying message on Windows by adding a path element without the spaces, i.e.
C:\Progra~1\PostgreSQL\9.4\data
instead of
“C:\Program Files\PostgreSQL\9.4\data”
I followed the instructions here: http://www.computerhope.com/issues/ch000549.htm, which worked for me if you prefer to go the point-and-click configuration of the PATH variable.
This type of error usually appears in the Windows environment, because if you do not update the PATH after installing Postgresql, heroku pg:psql command does not work.
So you need to update your PATH environment variable to add the bin directory of your Postgres installation. The directory will look like this:
C:\Program Files\PostgreSQL\<VERSION>\bin.
For more information, go to the Heroku in Local setup website:
heroku-postgresql: Local setup
I had the same problem and discovered that Heroku doesn't seem to provision the latest version of PostgreSQL by default. Where the Heroku Getting Started instructions said
heroku addons:create heroku-postgresql:hobby-dev
That provisioned a v10 database for some reason (which you can check by clicking on Heroku Postgres in the Add-ons tab of your dashboard). I deleted that database and provisioned a new database using the --version flag:
heroku addons:create heroku-postgresql:hobby-dev --version 11
As of now, at least, you can find the latest version of Postgres supported by Heroku at this link: https://devcenter.heroku.com/articles/heroku-postgresql#version-support-and-legacy-infrastructure
I'm writing this in early 2019, but according to the PostgreSQL website the next version (12) is "tentatively scheduled" for third quarter of 2019 so if you're reading this in late 2019 potentially the same problem will come up for v12 instead
On Mac you can use the following:
export PATH="/Library/PostgreSQL/12/bin/:$PATH"
The only solution that I found on Windows:
go to advanced system settings
go to environment variables
select Path variable and click Edit
add a new line and enter your bin directory path (C:\Program Files\PostgreSQL<version>\bin) and click ok
restart your terminal
enter your psql command (heroku pg:psql)

PHP clone keyword vs clone() command line CLI issues

I have been using the clone keyword to duplicate objects like so:
$x = clone $obj;
as per the manual.
This works fine when accessed by browser. phpinfo() reports PHP version 5.2.6.
However when run by cron or from the CLI I get
"Parse error: syntax error, unexpected T_VARIABLE"
from the clone keyword.
php -v reports PHP 4.4.9 (cli)
Is this error from a version conflict?
If I use clone() in my scripts like so:
$_SESSION['user'] = clone($userObject);
I get odd intermittent problems with the $_SESSION['user'] which do not occur when using the clone keyword.
Does this make any sense to anyone?
Any advice?
It seems that the clone $foo keyword is only available on PHP 5 and newer.
Also, if you're still using PHP 4.4.9, that may be a bigger problem.
Turns out the server has 4 and 5 installed and the CLI reports 4.4.9 simply due to PATH order:
From support:
"Running the "php -v" command in the shell will always return V4. That's because we have two separate installs for PHP on your server. One for V4 and one for V5, and the PHP 4 interpreter shows up in your PATH environment variable first. If you'd like to use V5 through the shell you'll need to be sure to use the full path"