This is an old revision of the document!
Everybody has definitely experienced the situation where the system got into a state where it wasn’t able to connect to SSH – be it because of a turned off sshd, incorrectly set rules in iptables or a lost SSH key. Luckily, you can use vpsAdmin to connect directly to the console of the VPS.
The console is available either via an online interface or directly from the terminal using the vpsfreectl utility. If you can choose, I recommend using vpsfreectl to access the console. The console works much more reliably and responsively in the terminal than in a web browser.
The console is persistent. That means that you can use it to follow the process of turning the VPS off and on. Disconnecting from the console does not log the user off unless an unintentional logoff takes place before disconnecting.
The installation process for vpsfreectl
is described in the article about our
API.
<html> <iframe width=“560” height=“315” src=“https://www.youtube.com/embed/Eg_i_iX7l6I” frameborder=“0” allowfullscreen></iframe> </html>
You can connect to the VPS console using the following command:
$ vpsfreectl vps remote_console <VPS_ID>
Here, substitute <VPS_ID>
for the ID of the VPS to which you want to connect the console.
The console can be closed by pressing the ENTER ESC .
buttons one after another (enter escape
period). This is the only way you can disconnect from the console (other than closing
the terminal window).
In order for the console to work as well as possible, it is important for the VPS to have the same locale
that is
used by the terminal from which you are connected. The most important thing here is encoding –
if the two sides use different encoding, certain characters will be replaced by
question marks, etc.
vpsAdmin cannot send the $TERM
environment variable to the console. However, some TUI
apps adapt to the value of this variable. Thus, at first glance it
might seem that the app or console is not working properly. For example, in order for the
mouse and colors to work in mc
, you first need to set TERM=xterm
or force this
mode using the mc -x
option.
You can have the $TERM
variable automatically set upon console startup
using .bashrc
:
cat <<EOF >> ~/.bashrc [ "`tty`" == "/dev/console" ] && export TERM=xterm EOF
Current distro templates mostly have this console preset. In older templates, it’s necessary to enable it manually.
Add the following line to the /etc/inittab
file:
1:2345:respawn:/sbin/getty 38400 tty0
Add the following lines to the /etc/init/tty.conf
file:
stop on runlevel [S016] respawn instance $TTY exec /sbin/mingetty $TTY
Then open /etc/init/start-ttys.conf
and add:
start on stopped rc RUNLEVEL=[2345] env ACTIVE_CONSOLES=/dev/tty[0-6] env X_TTY=/dev/tty1 task script . /etc/sysconfig/init for tty in $(echo $ACTIVE_CONSOLES) ; do [ "$RUNLEVEL" = "5" -a "$tty" = "$X_TTY" ] && continue initctl start tty TTY=$tty done end script
Add the following line to the /etc/inittab
file:
# vpsFree remote console c0:2345:respawn:/sbin/agetty --noreset 38400 tty0
The console should work after a restart.
This is not necessary for the current Ubuntu template.
Open the file /etc/init/tty0.conf
and add:
start on stopped rc or RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -L 38400 tty0 vt102
Run the service using sudo start tty0
. It will start automatically after
a restart.
If the console isn’t working, isn’t displaying every character or doesn’t allow login,
you probably have several instances of getty running and they have encountered an access right conflict.
This problem can be solved by turning off the extra getty in /etc/inittab
.