[[PageOutline]] This page documents the procedure for creating a new KVM guest on a mayfirst server. To decommission a server see [wiki:decommission_kvm this faq] = Creating a new KVM guest = In these directions, the host (or ) refers to the name of the kvm host computer (e.g. negri, or bolivar, etc.). The guest (or ) refers to the name of the virtualized server you are creating. The examples use negri as the host and hay as the guest. == Initial steps == * Pick an activist to name the server after. Find the wikipedia page (or a similar page) describing your activist. * Allocate an IP Address [wiki:how-to/servers/add_ip_allocation using this method]. * Add an A record and a ptr record in the May First/People Link -> mayfirst.org -> DNS section of the control panel matching your server name with the IP you have allocated for it. * Make sure there is an open ticket for creating the new server. The ticket should be tagged with "new-server." * '''In your local puppet''' Create Manifest file * Copy an existing puppet node file, preferably one from the same host, naming it after your activist (pick either the first or last name of the activist, up to you) and replace all instances of the old guest name with your new guest name and change the namesake URL and description text and anything else (be sure that the onsite/rdiff-backup server is in the same colo center as the server you are creating) and replace the IP address in the nagios stanza with the correct IP address * Edit the puppet configuration file for the host server. Copy an existing m_kvm::guest stanza, replacing values as needed. Normally you will want to set the nameserver to the ip of the physical host. The stanza will look something like this: {{{ m_kvm::guest { "rivera": guest_nameservers => "216.66.22.48", guest_ipaddress => "209.51.180.231", guest_netmask => "255.255.255.224" guest_gateway => "209.51.180.225", guest_ram => "2GB", guest_disksize => "50G", } }}} * commit changes to the puppet repo and git push to the host machine 1. git pull --rebase origin master 2. git push origin master 3. git push master == While root on the host machine == * Check the date of file /usr/local/share/ISOs/default.iso , if the date is older than the latest debian stable installer release then: * delete /usr/local/share/ISOs/default.iso * delete /usr/local/share/ISOs/.iso * run freepuppet-run and puppet should invoke di-maker to create both files again. For more details about how these images are created see the puppet config files {{{modules/mayfirst/manifests/m_kvm.pp}}} and {{{/modules/mayfirst/templates/kvm/preseed.cfg.erb}}} * Create a symlink to the ISO in the newly created user's home directory... {{{ ln -s /usr/local/share/ISOs/.iso /home//vms//cd.iso }}} * Start the new guest {{{ update-service --add /etc/sv/kvm/ }}} * Remove the symlink to the ISO in the newly created user's home directory... {{{ rm /home//vms//cd.iso }}} == While logged in as @ == * Enter the screen session: {{{ screen -x }}} * Press enter to start the install. Confirm the disk format. * Afer installation: * ssh -t @ screen -x * Login with root and no password (type 'root' at login prompt and hit enter). * The preseed file will leave all leftover space on the disk in a logical volume called "delete". You can remove this logical volume with: {{{ lvremove vg_0/delete }}} * Replace with the name of the server, '''E.g.''': {{{ lvremove vg_hay0/delete }}} * If your server is not running MySQL, you may want to also delete the mysql partition (and edit /etc/fstab to remove the /var/lib/mysql entry) * To create one or more new volumes from the remaining free space {{{ lvcreate --size -n vg_0 }}} E.g. {{{ lvcreate --size 80G -n home vg_goldman0 }}} * Edit fstab with the mount point(s) for the new logical volume(s) {{{ /dev/mapper/vg_0- }}} E.g. {{{ /dev/mapper/vg_goldman0-home /home ext4 defaults,relatime,nosuid,nodev 0 2 }}} You may need to create a file system for the new volume group. {{{ mkfs.ext3 /dev/mapper/vg_0- }}} * Mount the new logical volume(s). This will test the syntax of fstab to ensure successful mount(s) on the next reboot. {{{ mount }}} E.g. {{{ mount /home }}} * Set the root password. If you run the [wiki:keyringer keyringer pass] command without any arguments, it will prompt you with a random password and store the password in keyringer. To set the root password on the guest do: {{{ passwd }}} * Check the ssh host fingerprint (for comparison during steps below) {{{ ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub }}} == While in your puppet conf directory on your local machine == * Setup a remote for the new server: {{{ freepuppet-helper gsr: }}} * ssh into the new vm as root to make sure you get the new vm's key in your authorized keys file (see above for fingerprint) {{{ssh root@.mayfirst.org}}}. As of debian jessie the default config for the ssh server in /etc/ssh/sshd_config includes {{{PermitRootLogin without-password}}} which will prevent you from logging into the server directly with a password unless you add your public ssh key to /root/.ssh/authorized_keys or change the above config to {{{PermitRootLogin yes}}} and restart the ssh server. The former is preferred. * Initialize the new server for puppet with: {{{ freepuppet-helper is: }}} * Push git repo to guest: {{{ freepuppet-helper gp: }}} * If you get errors during this process, which is likely--they show up in some attention grabbing color, purple for me--rerun the process with the following: {{{ freepuppet-helper pr: }}} * Sign host key: {{{ freepuppet-helper shgk: }}} * We no longer need to sign the root key. Instead, ensure that the contents of /root/.ssh/id_rsa.pub is saved in puppet in the manifests/globals.pp file * In addition, if this server will be a red/control panel host (mosh), run the following from the helper directory of your puppet repo: {{{ ./generate-known-host-files }}} And append the content to modules/mayfirst/files/ssh/known_hosts.red.servers and push to hay * Push changes to the nagios server and to each of the backup servers '''NOTE:''' We have experienced errors with backup servers syncing. Please see ticket:5455#comment:3 if you see errors syncing backups. You also may need to run `freepuppet-helper gsr:SERVER_NAME` for this step, if you haven't set the remotes for these servers yet. {{{ freepuppet-helper gp:jojobe freepuppet-helper gp: freepuppet-helper gp: }}} == Restart the server! == == MOSH servers == If you are installing a MOSH server: * Grant access to the Control panel database, from your local machine: {{{ freepuppet-helper rda: }}} * Add the server to the red_server table in the red/seso database. Setting accepting = 1 will enable it to show up in the drop down list for everyone: * '''NOTE''': The command below may not work properly, in which case you should login to hay and run it from the mysql cli. {{{ ssh root@hay.mayfirst.org mysql -e "INSERT INTO red_server SET server = '.mayfirst.org', accepting = 1" seso }}} You can toggle the value of accepting with the following sql statements: {{{ UPDATE red_server SET accepting = 0 WHERE server = '.mayfirst.org'; UPDATE red_server SET accepting = 1 WHERE server = '.mayfirst.org'; }}} Setting to "accepting = 0" in the above statement will remove the option to create new hosting order in the indicated guest server for members who have not previously created hosting orders within that server. However members who have previously created hosting orders in that guest can still create new ones there. To prevent any new hosting orders on the guest in question the following statement is needed. {{{ UPDATE red_server SET closed = 1 WHERE server = '.mayfirst.org'; }}} * [wiki:letsencrypt setup x509 certificates]. === Dedicated MOSH servers === Some groups request a dedicated virtual private servers. Unfortunately, you have to jump through a few hoops to get this done. Usually, the reason for the request is because the user wants to run CiviCRM or otherwise wants PHP to perform more efficiently than is possible with suExec. These directions assume that's the purpose of the MOSH: * In the puppet configuration, specify the following in the m_mosh call: {{{ php => "mod_php", apache_user => "USERNAME", apache_group => "GROUPNAME", }}} Here's an example of a real live config: {{{ class { "m_mosh": php => "mod_php", apache_user => "nybrecht", apache_group => "brechtforum", apache_max_clients => 40 } }}} Sadly, there's a chicken/egg problem. You can't know what the USERNAME and GROUPNAME will be until you've added a hosting order via the control panel. But, you can't add a hosting order via the control panel until you configured puppet. So, I suggest start by keeping the USERNAME/GROUPNAME place holders and tolerate puppet reporting an error (it will tell you that apache failed to start). Next, create a hosting order for the requesting member in the control panel. If you specified "accepting = 1" in the steps above, the server should be available (and hopefully no other member has decided to put a hosting order there). After you have created your hosting order, manually update the red_server table to change the accepting field to 0 so other members can't use it. Then, in the control panel, click on Top and then click the Server Access tab. Create a new record specify the member requesting the server, the server that you have added, and the user account that, when they login to the control panel, should have full access to the server. This probably will be the user account that was created in the previous step but it doesn't have to be (if they have hosting orders on other servers). Now, you can modify the puppet record for the server and replace the USERNAME and GROUPNAME with the user account that you created for the hosting order on this server. The username and groupname should be the same.