Editing VPS Management (section)

= Common Problems =
== Login to any machine without a password ==

This is possible via the use of ssh keys. The process is thus:

1. place the public key for your user (root@mail) in the /root/.ssh/authorized_keys file on the server you wish to login to
 cat /root/.ssh/id_dsa.pub
(paste that into authorized_keys on the target server). If the file doesn't exist, create it.

2. enable root login (usually only applies to FreeBSD). Edit the /etc/ssh/sshd_config on the target server and change:
<tt>#PermitRootLogin no</tt>
to
<tt>PermitRootLogin yes</tt>

3. Restart the sshd on the target machine. First, find the sshd process: 
 jailps <hostname> | grep sshd 
or 
 vp <VEID> | grep sshd

Look for the process resembling:
 root     17296  0.0  0.0  5280 1036 ?        Ss    2011   4:27 /usr/sbin/sshd 
(this is the sshd)

Not:
 root      6270  0.5  0.0  6808 2536 ?        Ss   14:33   0:00 sshd: root [priv]
(this is an sshd child- someone already ssh'd in as root)

Restart the sshd: 
 kill -1 <PID>

Ex:
 kill -1 17296

You may now ssh in.

Once you're done, IF you enabled root login, you should repeat steps 2 and 3 to disable root logins.

== Letting someone in who has locked themselves out (killed sshd, lost pwd) ==

There are two ways people frequently lock themselves out - either they forget a password, or they kill off sshd somehow.

These are actually both fairly easy to solve.  First, let's say someone kills off their sshd, or somehow mangles /etc/ssh/sshd_config such that it no longer lets them in.

Their email may be very short, or it may have all sorts of details about how you should fix sshd_config to let them in ... just ignore all of this. They can fix their own mangled sshd.  Fixing this is very simple.  First, edit the /etc/inetd.conf on their system and uncomment the telnet line:

 telnet stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd
 #telnet stream  tcp6    nowait  root    /usr/libexec/telnetd    telnetd

(just leave the tcp6 version of telnet commented)

Then, use jailps to list the processes on their system, and find their inetd process.  Then simply:

 kill -HUP (pid)

where (pid) is the PID of their inetd process.  Now they have telnet running on their system and they can log in and do whatever they need to do.

The only complications that could occur are:

a) their firewall config on our firewall has port 23 blocked, in which case you will need to open that - will be covered in a different lesson.

b) they are not running inetd, so you can't HUP it.  If this happens, edit their /etc/rc.conf, add the inetd_enable="YES" line, and then kill
their jail with /tmp/jailkill.pl - then restart their jail with the jail line from their quad/safe file.  Easy.

If they have forgotten a password,

On 6.x+ you can reset their password with:
 jexec <jailID from jls> passwd root

Note: the default password for 6.x jails is 8ico2987, for 4.x it is p455agfa

On 4.x, you need to cd to their etc directory
... for instance:

 cd /mnt/data2/198.78.65.136-col00261-DIR/etc

and run:

 vipw -d .

Then paste in these two lines (theres a paste with these):

 root:$1$krszPxhk$xkCepSnz3mIikT3vCtJCt0:0:0::0:0:Charlie &:/root:/bin/csh
 user:$1$Mx9p5Npk$QdMU6c8YQqp2FW2M3irEh/:1001:1001::0:0:User &:/home/user:/bin/sh

overwriting the lines they already have for "user" and "root" - then just tell them that both user and root have been reset to the default password of p455agfa.

For linux, just passwd inside shell or 
 vzctl set <veid> --userpasswd root:p455agfa –save

Starting in 2009 we began giving out randomized passwords for FreeBSD and Linux as the default password. That is stored with each system in Mgmt. You should look for and reset the password to that password in the event of a reset and refer the customer to use their original password from their welcome email- this way we don’t have to send the password again via email (in clear text).


== sendmail can’t be contacted from ext ip (only locally) ==

By default redhat puts this line in sendmail.mc:

 DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

which makes it only answer on localhost.  Comment it out like:

 dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

and then rebuild sendmail.cf with:

 m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

== virt doesn’t properly let go of ve’s ip(s) when moved to another system ==

On virtuozzo 2.6 systems, it's been observed that when moving ips from one virt to another that sometimes the routing table will not get updated to reflect the removal of the ip addresses.

A recent example was a customer that was moving to a new ve on a new virt and the ip addresses were traded between the two ve's.  After the trade the two systems were not able to talk to each other.  When looking at the routing table for the old system all the ip addresses were still in the routing table as being local, like so:

<pre>netstat -rn | grep 69.55.225.149
69.55.225.149   0.0.0.0         255.255.255.255 UH       40 0          0 venet0</pre>

This was preventing traffic to the other system from being routed properly.
The solution is to manually delete the route:

 route delete 69.55.225.149 gw 0.0.0.0

Supposedly, this was fixed in 2.6.1

== sshd on FreeBSD 6.2 segfaults ==

First try to reinstall ssh

<pre>cd /usr/src/secure
cd lib/libssh
make depend && make all install
cd ../../usr.sbin/sshd
make depend && make all install
cd ../../usr.bin/ssh
make depend && make all install</pre>

Failing that, find the library that’s messed up:

<pre>ldd /usr/sbin/sshd
         libssh.so.3 => /usr/lib/libssh.so.3 (0x280a3000) 
         libutil.so.5 => /lib/libutil.so.5 (0x280d8000) 
         libz.so.3 => /lib/libz.so.3 (0x280e4000) 
         libwrap.so.4 => /usr/lib/libwrap.so.4 (0x280f5000) 
         libpam.so.3 => /usr/lib/libpam.so.3 (0x280fc000) 
         libbsm.so.1 => /usr/lib/libbsm.so.1 (0x28103000) 
         libgssapi.so.8 => /usr/lib/libgssapi.so.8 (0x28112000) 
         libkrb5.so.8 => /usr/lib/libkrb5.so.8 (0x28120000) 
         libasn1.so.8 => /usr/lib/libasn1.so.8 (0x28154000) 
         libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x28175000) 
         libroken.so.8 => /usr/lib/libroken.so.8 (0x28177000) 
         libcrypto.so.4 => /lib/libcrypto.so.4 (0x28183000) 
         libcrypt.so.3 => /lib/libcrypt.so.3 (0x28276000) 
         libc.so.6 => /lib/libc.so.6 (0x2828e000) 
         libmd.so.3 => /lib/libmd.so.3 (0x28373000)</pre>

md5 them and compare to other jail hosts or jails running on host

for libcrypto reinstall:
<pre>/usr/src/crypto
make depend && make all install</pre>

== Moving a server to a different account in the management system ==

This is a tough one. You gotta touch a bunch of tables in the mysql database.
<pre>
  systems
  subs
  ipmap
</pre>

basically, get the sysid and go off that:

<pre>
update systems set cid='newcid' where sysid=xxxxx
update subs set cid='newcid' where sysid=xxxxx
update ipmap set cid='newcid' where sysid=xxxxx
</pre>

You then need to rename the server disk space to change the old ID to the new one.

For a jail -
<pre>
stopjail <hostname>
mv 69.55.2XX.XXX-col0<oldid>     69.55.2XX.XXX-col0<newid>
mv 69.55.2XX.XXX-col0<oldid>-DIR 69.55.2XX.XXX-col0<newid>-DIR
vi /usr/local/jail/bin/quad1       [Update the ID in the quad file]
startjail <hostname>
</pre>

For a virt -
You will have to 
* stop the virt 
* rename the directories 
* modify the config file /vzconf/<veid>.conf 
* rename the virt conf file 
* restart the new virt.

that ought to do it..


== Re-enable a customer account in the management system ==

For example to re-instate col03438, In mysql:

<pre>
show tables ;
select * from customers where cid='col03438' ;
update customers set status=1 where cid='col03438' ;
select * from  systems where cid='col03438' ;
update systems set stop_date=NULL where cid='col03438' ;
update systems set cancel_date=NULL where cid='col03438' ;
update systems set status=1 where cid='col03438' ;
select * from subs where cid='col03438' ;
update subs set stop_date=NULL where cid='col03438' ;
update subs set status=1 where cid='col03438' 

</pre>