In my earlier post vCSA 6.0 tricks: shell access, password expiration and certificate warnings I showed how can set the VCSA shell timeout to an effectively indefinite value using the command
shell.set --enabled true --timeout 2147483647
When I checked my own vCSA (that was originally installed with 6.0 GA, then upgraded to Update 1 and Update 1b) I found that my old large timeout setting was still in place and functioning. That means even in the latest build of the VCSA 6 it is still possible to set an arbitrarily large shell timeout, just not through the appliance shell or the VAMI. So how do you do this?
I knew that the shell timeout setting must be written in some VCSA configuration file, but it took me some time to figure out which one: It is in
/etc/applmgmt/appliance/appliance.conf.
It has the following contents:
You can convert Unix time back to a human readable format by using the date -d @ syntax. For my example you would use
date -d @2114290800
which results in
Wed Dec 31 00:00:00 CET 2036
That means on my system the shell will expire on Dec 31st 2036. Hopefully I will be retired by then :-)
If you want to set the shell expiration on your VCSA to a custom value like e.g. Jan 1st 2020 then you need to convert that time into Unix time by using
date -d "2020-01-01" +%s
This example will result in the number 1577833200. Now just edit the appliance.conf file and set this value for the shellExpirationTime. Also make sure that the shell is enabled in here by setting shellEnabled (line 10) to true.
After saving the file the new settings will immediately take place. That's it - no need to restart anything!
Please note that this is - of course - completely unsupported by VMware!
I knew that the shell timeout setting must be written in some VCSA configuration file, but it took me some time to figure out which one: It is in
/etc/applmgmt/appliance/appliance.conf.
It has the following contents:
{
"TimeSync": {
"mode": "NTP"
},
"monitoring": {
"logFreq": 12,
"period": 5
},
"cli": {
"shellEnabled": true,
"shellDefaultTimeout": 3600,
"shellExpirationTime": 2114290800
},
"settings": {
"soln.user": "[email protected]",
"cm.url": [
"http://localhost:18090/cm/sdk/?hostid=b247190f-cd53-4037-87eb-f52c37af0c06"
],
"productType": "vCenter Server with an embedded Platform Services Controller"
}
}
In line 12 there is the value shellExpirationTime. This is not the number of seconds left until the shell gets disabled again, but the date and time of expiration in Unix Time format. The Unix time is specified as the number of seconds that have passed since Jan 1st 1970, 0:00 UTC.You can convert Unix time back to a human readable format by using the date -d @ syntax. For my example you would use
date -d @2114290800
which results in
Wed Dec 31 00:00:00 CET 2036
That means on my system the shell will expire on Dec 31st 2036. Hopefully I will be retired by then :-)
If you want to set the shell expiration on your VCSA to a custom value like e.g. Jan 1st 2020 then you need to convert that time into Unix time by using
date -d "2020-01-01" +%s
This example will result in the number 1577833200. Now just edit the appliance.conf file and set this value for the shellExpirationTime. Also make sure that the shell is enabled in here by setting shellEnabled (line 10) to true.
After saving the file the new settings will immediately take place. That's it - no need to restart anything!
Please note that this is - of course - completely unsupported by VMware!
This post first appeared on the VMware Front Experience Blog and was written by Andreas Peetz.
Follow him on Twitter to keep up to date with what he posts.
Follow him on Twitter to keep up to date with what he posts.
Hi,
ReplyDeletejust for the sake of talking, isn't it easier to just change the root shell to bash and forget about the timeout? Is there a reason why one shouldn't do it that maybe I can't see?
Hi Caddo,
Deletesure, you can also just change root's shell to /bin/bash, but the appliance shell is there for a reason. It is the default and preferred shell that offers the "official" API commands that VMware wants us to use. The bash shell does not expose these commands.
If you permanently disable the appliance shell in this way it might lead to functionality not working as expected - now or later. Any significant deviation from the standard configuration can lead to unexpected behavior.
Of course the shell timeout hack is also a deviation from the standard, but I consider it less intrusive and dangerous.
Andreas