Thursday, 12 December 2013

How to change main hostname and IP of WHM/cPanel machine

One thing you’ll probably run into sometime is changing the hostname and IP address of a cPanel machine.. whether you’re cloning it for a quick start or if you’ve taken it over.. moving it to a different datacenter, etc..


This is based on CentOS 6…

First, grab a license for the new IP address you’re going to use..

Next, edit the following files with the new information and restart the network:
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network

Next, remove /etc/.whostgrft (this will restart the cpanel setup screen)
Next, edit /etc/wwwacct.conf

Log into whm as root and run through the setup..
Next, run /scripts/rebuildhttpdconf

Afterwards, you’ll find some other files that still may have old info.. here are some:
/etc/hosts
/etc/localdomains
/etc/mail_reverse_dns

You might still see old info in the httpd.conf file, so manually edit it and run:

/usr/local/cpanel/bin/apache_conf_distiller –update
If you come across other changes that need to be made, please comment below!

Server Setup & Configuration - cPanel / WHM

Steps to Install CPANEL on your VPS or Dedicated Server


Make sure that your VPS server has enough resources to be able to run cPanel. Minimum of 512 MB of memory to run Cpanel (1GB is recommended).


Before installing Cpanel, its good to setup a basic clean compile environment and get your server up to date with the latest patches and software updates.


[root@server1 /]#  yum install selinux coreutils binutils make dialog gcc gcc-* glib*
[root@server1 /]#  yum install libexi* libjpe* libpng* gifl* freetype curl curl-* xmlrpc
[root@server1 /]#  yum upgrade kernel*
[root@server1 /]#  yum update


Once you got the basics, time to install Cpanel/WHM:


[root@server1 /]#  cd
[root@server1 /]#  wget http://layer1.cpanel.net/cpanel-universal-install.sea
[root@server1 /]#  chmod 700 ./cpanel-universal-install.sea
[root@server1 /]#  ./cpanel-universal-install.sea


(The above will take you 30 minutes to an hour or so to finish)


After you have the base install done, it would be a good idea to run the 'checkperlmodules' a couple of times at least until it runs clean without trying to compile new modules so that you get all the required Perl modules you need to run Cpanel properly installed on your server:


[root@server1 /]#  /scripts/checkperlmodules


(Typically needs to be run about 3 times till it runs clean)


Once you have Cpanel installed, connect to WHM and go through the initial setup wizard to setup your server hostname, licensing, DNS servers, IP addresses, etc:


http://(your server primary IP):2086/


That's the basic rundown!


At this point, you will have a basic copy of Cpanel installed but it won't be configured or optimized and your system won't have any security hardening, configurations, or optimizations either. To do that properly, you will have another couple hours of work ahead of you if you are experienced (a couple of days if you aren't) to get things fully setup and working properly the way they should.

Tuesday, 10 December 2013

Linux Maldet - Installation

This guide will help you through installing LMD (Linux Malware Detect) on your VPS or Dedicated servers
You will need to be logged in as root to the server over SSH.
Let's create a temporary directory and navigate into it, followed by downloading the latest release of maldet:



# mkdir tmp
# cd tmp
# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

Extract the archive containing LMD and navigate into the directory it creates:



# tar xf maldetect-current.tar.gz && cd maldetect-*

Warning: Version may vary, you can check the current directory listing with the command `ls` Once you're inside execute the install script:



#  ./install.sh

This will automatically install a cronjob inside /etc/cron.daily/maldet as well, it will make LMD execute daily and scan local cPanel accounts for possible malware.
Usage is fairly simple, to scan user's home directory or any other directory you would simply execute:



#      maldet -a /home/user

Any path is alright. Please note that LMD runs great with ClamAV.


Setting up e-mail alerts
LMD has an option to alert you each time it detects malware, please review these configuration variables inside /usr/local/maldetect/conf.maldet
variable     value     description
email_alert     1 or 0     enable or disable e-mail alerts
email_addr      e-mail address      target e-mail for notifications, should be put in quotes like: "root@domain.com"
Other configuration variables that you should look into:
variable     value     description
quar_hits     number     if the number is different than 0, enables automatic quarantine
maxfilesize      size      makes LMD skip files larger than set size, for example "512k" (512 K


Friday, 6 December 2013

SSH - PuTTYgen

In the interest of security, remote login into our Unix/Linux machines is only allowed over cryptographically protected connections using the secure shell (SSH) protocol, even where the connection remains within the department.

Our commonly used Windows SSH client software is PuTTY. When installing, always use the latest version. Especially if you use a version older than PuTTY 0.61, we strongly recommend that you upgrade now to benefit from Kerberos support.

Installation

If you are on a Lab-managed Windows machine and the latest version of PuTTY is not yet available, then you can install it yourself (even without an Administrator account) via the Systems Management “Advertised Programs” installer, or via \didcotswdistputty.

The installer may manifest itself as a small white rectangle in your task bar; otherwise, get to it via: Start Menu | Settings | Control Panel | Advertised Programs.

Basic configuration

The PuTTY installer places an icon on your desktop ("Shortcut to PuTTY", an image of two computers suffering a mutual lightning strike). When you start it up, you will see a small “PuTTY Configuration” window.



In there, for convenience, you should save all the PuTTY settings needed to talk to a particular server as a “Session”. The following example shows this for one of the Lab's main Linux SSH servers: “ssh-remote-0.cl.cam.ac.uk”.

Under “Category” select “Session” (you probably are already there).
In the “Host Name (or IP Address)” box, type: “ssh-remote-0.cl.cam.ac.uk”
Also check that you have “Port 22” and “Protocol: SSH”
Type a name for your session configuration into the “Saved Sessions” box, (e.g., “cl” or “ssh-remote-0”).
Click “Save”
Under “Category”, select “Windows | Translation” and choose the “UTF-8” character encoding.
Under “Category”, select “Connection | Data”. Enter your Unix login name (CRSID) into the “Auto-login username” field, or alternatively make sure that “When username is not specified: Use system username (your-crsid)” is selected. [This will avoid that you have to type in you user name each time.]
set auto-login username

Under “Category” select “Connection | SSH | Tunnels”:


In the box “X11 forwarding” tick “Enable X11 forwarding”. (This option, together with running an X11 server such as that provided by MobaXterm, XMing (both avaiable as free versions or eXceed, will allow your Unix applications to open windows on your Windows PC.
Under “Category” select “Connection | SSH | Auth | GSSAPI”:
Kerberos session

Make sure that both “Attempt GSSAPI authentication” and “Allow GSSAPI credential delegation” are selected. [This means that if your Windows machine has already a valid Kerberos ticket from our Active Domain controller, both authentication and forwarding of the Kerberos ticket such that the Linux server can access your home directory will all just work automatically.]
Under “Category” go back to “Session” and click “Save” once more.
Public/private key authentication

If you can use Kerberos/GSSAPI authentication (as configured above), then there is usually no need to configure ssh public keys. Your login will work fine without.

Kerberos authentication will not work in two situations:

You use a Windows computer where you have not logged into the AD.CL.CAM.AC.UK Kerberos domain, for example a private computer not managed by the Lab.
You are setting up TortoiseSVN with PuTTY to access a Subversion repository for editing the Lab’s website.
In both cases, you will have to generate an SSH public/private key pair, which PuTTY can then use to authenticate your identity during login. The generated private key must be made available to PuTTY, usually via starting the Pageant tool. The generated corresponding public key must be appended in your Linux home directory to the file “.ssh/authorized_keys”.

The following description explains two options for duing this in more detail.

On Linux

On a lab Linux machine, run the command: “ssh-keygen -t rsa”

This will create a public/private key pair and leave them in your filespace under Linux. Please ensure you use a secure pass phrase to protect this.

This has the side effect of creating a .ssh subdirectory structure in your home directory, where the key pair will be stored. You will find the newly generated public key in “~/.ssh/id_rsa.pub”; copy it.

Then “cd ~/.ssh” and edit “authorized_keys”, pasting the public key into a new line on its own. Just as detailed below you will need to add a section saying where the key can be used from, which should be as specific as possible. The end result should look like:

from="*.cl.cam.ac.uk" ssh-rsa AAAAB3NzaC1yc2EAAAADA […] onHiVNh0IkKift27RZL1 spqr1@example.cl.cam.ac.uk

On Windows



On a Windows machine, run “Puttygen” from the “Putty” Start Menu programs group.
Click on the “Generate” button.
Move the cursor continually over the blank space, as instructed, to generate a random key.
In the Key_comment box, replace any text with your own identifier, i.e. @cl.cam.ac.uk (see the image example below).
Set a passphrase. (This can be a password or a phrase.)
The key is the text that appears in the box below Public key for pasting into OpenSSH authorized_keys file:; copy that. Do not click Save public key and use the contents of the resulting file; that will not work.

Saving the public key

If this file does not exist then navigate to “\fileruserfiles
unix_home.ssh” and create a new file called “authorized_keys” (taking care not to leave it with a .txt suffix).
Click here if directory does not exist.

Note: If you are setting up keys for use with Subversion and Tortoise, email this public key to pagemaster.
Please ensure you give the Key comment field a meaningful name
i.e your CRSID, as shown in the example above.

Paste the public key into an empty line at the bottom of the file. Then, in front of the public key on that line, you need to state where the key can be used from, i.e on which domain. This needs to be as specific as possible. So for a lab managed machine, type:

“from="*.cl.cam.ac.uk"”

or for a laptop using Eduroam within Cambridge

“from="*.cam.ac.uk"”

followed by a space as shown in the example below:



Save the file

If the directory does not exist:

Map a drive to “\fileruserfiles
unix_home”
Run a command Window (Type “CMD” in Start, Run).
Change to the new drive letter you have just mapped.
Type “mkdir .ssh” to create the .ssh directory.
You can now create the “authorized_keys” file.
Back to Saving Public key

from="*.cl.cam.ac.uk"


Save the file

Saving the private key

You now need to save the private key to your local disc:

Click on the “Save private key” button.
Save the file locally on your PC. A logical place is in the Start->All Programs->Startup area of YOUR login under Documents and Settings. When it is saved here, “Pageant” (the program that activates your encryption keys) is set to run at start up everytime you (and only you) login to that PC.
(Note: For laptop use, you should have a different key on each machine, which is easily identifiable in case of loss.

Troubleshooting and refinements

The above represents the basic necessities for getting the setup working.

If you have suggestions to improve the arrangements, please contact the Windows administrators.

Other areas of the “PuTTY” configuration window allows you to alter the colour scheme, and so on. Remember to “Load” your session before making your changes, and “Save” your session afterwards.

If you are experiencing trouble logging into PuTTY, you may want to change the PuTTY settings so the Unix shell window doesn't close automatically, but logs the results of what happens, so you can send to a Windows Administrator:

Changing window settings:

Load your session (i.e “Computer lab”, which was our earlier example).
Under “Category”, select “Session”
Under “Close window on exit”, select the appropriate radio button, i.e. “Never”
Save your session.
Setting up Logging:

Load your Session.
Under “Category”, select “Session, Logging”.
Under “Session logging:”, select the appropriate radio button, i.e. “Log all session output”.
Under “Log file name:”, browse to a suitable location to save the logfile and give the logfile a name.
Under “What to do if the log file already exists:”, select the appropriate radio button, i.e. “Always append to the end of it”.
Save your session.
"No Supported authentication methods" error

When setting up PuTTY you may experience the above error message.

One possible cause is that the domain you have specified in the “authorized_keys” file and the domain your computer believes it resides in are not the same.

To resolve this issue, try whether you can login after removing the “from="*.cl.cam.ac.uk"” prefix from your authorized_keys file temporarily.

If so, then lookup your computer’s domain name:

Right click “My Computer” and select “Properties”
Click on the “Computer Name” tab. Here you will see your domain, i.e. “cl.cam.ac.uk”.
The domain written as part of the “from=” command in the “authorized_keys” file should match the domain listed here under the “Computer Name” tab.
Edit “authorized_keys” accordingly, save it, and try another PuTTY session.
If this still does not resolve your issue, it could be an absence of a reverse mapping of your IP address. You will need to contact a Windows administrator for further help.

How To Create SSH Keys with PuTTY to Connect to a VPS

Benefits of Public & Private SSH Keys





If your headless, or remote, VPS is visible over the Internet, you should use public key authentication instead of passwords, if at all possible. This is because SSH keys provide a more secure way of logging in compared to using a password alone. While a password can eventually be cracked with a brute-force attack, SSH keys are nearly impossible to decipher by brute force alone. With public key authentication, every computer has (i) a public and (ii) a private "key" (two mathematically-linked algorithms that are effectively impossible to crack).

Today, OpenSSH is the default SSH implementaion on Unix-like systems such as Linux and OS X. Key-based authentication is the most secure of several modes of authentication usable with OpenSSH, such as plain passwords and Kerberos tickets. Other authentication methods are only used in very specific situations. SSH can use either "RSA" (Rivest-Shamir-Adleman) or "DSA" ("Digital Signature Algorithm") keys. Both of these were considered state-of-the-art algorithms when SSH was invented, but DSA has come to be seen as less secure in recent years. RSA is the only recommended choice for new keys, so this tutorial uses "RSA key" and "SSH key" interchangeably.

When you log in to your DigitalOcean VPS, the SSH server uses the public key to "lock" messages in a way that can only be "unlocked" by your private key. This means that even the most resourceful attacker cannot snoop on, or interfere with, your session. As an extra security measure, some users and most SSH programs store the private key in a passphrase-protected format, to provide a window of time in which you can disable your compromised public key, should your computer be stolen or broken in to. For these reasons, public key authentication is a much better solution than passwords for most people. In fact, by not employing a passphrase on your private key, you will have the ability to automate parts of your configuration management with secure, automatic log-ins, such as incremental off-site backups, manage your DigitalOcean assets via the DigitalOcean API, and more.



Key-Based SSH Logins


You can save the same public key on as many cloud servers as you'd like, while your private key is saved on a client from which you log in to the server. Then, you can disable the normal username/password login procedure, which means that only people with a valid private/public key pair can log in; making your system more secure, because it will be impervious to brute-force attacks.



Automate the Creation of New Droplets


Another useful purpose that SSH keys can serve is in the creation of DigitalOcean droplets. As you know, when you spin up a droplet, you have to wait for an e-mail with your password. Although this email is very convenient, there is a more secure (and faster) way of gaining access to your new cloud server without the need for email. This can be done by saving your public key in the DigitalOcean Control Panel. To accomplish this:





  • First complete the section in this tutorial titled Generating OpenSSH-compatible Keys for Use with PuTTY.






  • Then, skip to Step Three of How to Use SSH Keys with DigitalOcean Droplets.


Prerequisites


This tutorial assumes that you are familiar with DigitalOcean's guide on How to Log Into Your Droplet with PuTTY (for windows users).







PuTTY Key Generator (a.k.a. PuTTYgen)





While PuTTY is a client program for SSH (in addition to Telnet and Rlogin), it is not a port of or otherwise based on OpenSSH. Consequently, PuTTY does not have native support for reading OpenSSH's SSH-2 private key files. However, PuTTY does have a companion named PuTTYgen (an RSA and DSA key generation utility), that can convert OpenSSH private key files into PuTTY's format; allowing you to connect to your cloud server from a Windows machine, with the added security that SSH keys provide.

PuTTYgen is a (free) open-source utility and can be downloaded from the maintainer's website. PuTTYgen is what you will use to generate your SSH keys for use in PuTTY. To start, all you need to do is download the exectuable files (.exe) and save them on the computer that you'll use to connect to your VPS, e.g. on the desktop. You will not need to "install" PuTTYgen, because it is a standalone application.



Generating OpenSSH-compatible Keys for Use with PuTTY





To generate a set of RSA keys with PuTTYgen:





  1. Start the PuTTYgen utility, by double-clicking on its .exe file;







  1. For Type of key to generate, select SSH-2 RSA;







  1. In the Number of bits in a generated key field, specify either 2048 or 4096 (increasing the bits makes it harder to crack the key by brute-force methods);







  1. Click the Generate button;







  1. Move your mouse pointer around in the blank area of the Key section, below the progress bar (to generate some randomness) until the progress bar is full;







  1. A private/ public key pair has now been generated;







  1. In the Key comment field, enter any comment you'd like, to help you identify this key pair, later (e.g. your e-mail address; home; office; etc.) -- the key comment is particularly useful in the event you end up creating more than one key pair;







  1. Optional: Type a passphrase in the Key passphrase field & re-type the same passphrase in the Confirm passphrase field (if you would like to use your keys for automated processes, however, you should not create a passphrase);







  1. Click the Save public key button & choose whatever filename you'd like (some users create a folder in their computer named my_keys);







  1. Click the Save private key button & choose whatever filename you'd like (you can save it in the same location as the public key, but it should be a location that only you can access and that you will NOT lose! If you lose your keys and have disabled username/password logins, you will no longer be able log in!);







  1. Right-click in the text field labeled Public key for pasting into OpenSSH authorized_keys file and choose Select All;






  1. Right-click again in the same text field and choose Copy.



NOTE: PuTTY and OpenSSH use different formats for public SSH keys. If the SSH Key you copied starts with "---- BEGIN SSH2 PUBLIC KEY ...", it is in the wrong format. Be sure to follow the instructions carefully. Your key should start with "ssh-rsa AAAA ...."



Save The Public Key On The Server





Now, you need to paste the copied public key in the file ~/.ssh/authorized_keys on your server.





  1. Log in to your destination server; see How to Log Into Your Droplet with PuTTY (for windows users)







  1. If your SSH folder does not yet exist, create it manually:



mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys





  1. Paste the SSH public key into your ~/.ssh/authorized_keys file (see Installing and Using the Vim Text Editor on an Cloud Server):



sudo vim ~/.ssh/authorized_keys





  1. Tap the i key on your keyboard & right-click your mouse to paste.






  1. To save, tap the following keys on your keyboard (in this order): Esc, :, w, q, Enter.


Create a PuTTY Profile to Save Your Server's Settings





In PuTTY, you can create (and save) profiles for connections to your various SSH servers, so you don't have to remember, and continually re-type, redundant information.





  1. Start PuTTY by double-clicking its executable file;







  1. PuTTY's initial window is the Session Category (navigate PuTTY's various categories, along the left-hand side of the window);







  1. In the Host Name field, enter the IP address of your VPS or its fully qualified domain name (FQDN); see How to Set Up a Host Name with DigitalOcean







  1. Enter the port number in the Port field (for added security, consider changing your server's SSH port to a non-standard port. See Step Five of Initial Server Setup with Ubuntu 12.04







  1. Select SSH under Protocol;







  1. Along the left-hand side of the window, select the Data sub-category, under Connection;







  1. Specify the username that you plan on using, when logging in to the SSH server, and whose profile you're saving, in the Auto-login username field;

  2. Expand the SSH sub-category, under Connection;







  1. Highlight the Auth sub-category and click the Browse button, on the right-hand side of the PuTTY window;







  1. Browse your file system and select your previously-created private key;







  1. Return to the Session Category and enter a name for this profile in the Saved Sessionsfield, e.g. user@123.456.78.9 or user@host.yourdomain.tld;






  1. Click the Save button for the Load, Save or Delete a stored session area.



Now you can go ahead and log in to user@1.2.3.4 and you will not be prompted for a password. However, if you had set a passphrase on your public key, you will be asked to enter the passphrase at that time (and every time you log in, in the future).



Disable Username/Password Logins





Once you have verified that your key-based logins are working, you may elect to disable username/password logins to achieve better security. To do this, you need to edit your SSH server's configuration file. On Debian/ Ubuntu systems, this file is located at/etc/ssh/sshd_config.



sudo vim /etc/ssh/sshd_config


Tap the i key on your keyboard and edit the lines, referenced below:



[...]
PasswordAuthentication no
[...]
UsePAM no
[...]


To save, tap the following keys on your keyboard (in this order): Esc, :, w, q, Enter. Now, reload the SSH server's configuration:



sudo reload ssh

Thursday, 5 December 2013

BRINGING UP LOOPBACK INTERFACE: RTNETLINK answers: File exists / OPERATION NOT SUPPORTED

One of our VPS suddenly not showing when running the command ifconfig Also while restarting network, I was getting the following error.

OpenVZ – RHEL/CentOS 6.5 Container Networking Bug

No active network interfaces:

[root@vps ~]# ifconfig
[root@vps ~]#


 [root@vps ~]# /etc/init.d/network restart
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:  RTNETLINK answers: Operation not supported
Failed to bring up lo.
[FAILED]
Bringing up interface venet0:  RTNETLINK answers: Operation not supported
Failed to bring up venet0.
[FAILED]
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists


Fix : The issue was with iproute package. The package got updated automatically and it was not excluded in yum updates. To fix the issue, you need to downgrade the package iproute.


How to solve (CentOS 6 64Bit):

Until the OpenVZ developers create an official fix, you can downgrade the iproute package as follows:

1. From your OpenVZ Hostmachine, download the old RPM:

[root@vps ~]#  wget http://repo.smartservermanagement.com/misc/iproute-2.6.32-23.el6.x86_64.rpm


2. Copy this inside the container:
[root@vps ~]#  cp /root/iproute-2.6.32-23.el6.x86_64.rpm /vz/private/<CTID>/root/


3. Console into the VPS, forcefully remove the current iproute package, and replace with old one:

[root@vps ~]#  vzctl enter <CTID>
[root@vps ~]#  rpm -e iproute-2.6.32-31.el6.x86_64 –nodeps
[root@vps ~]# rpm -ivh /root/iproute-2.6.32-23.el6.x86_64.rpm


4. Restart the network service

[root@vps ~]# service network restart


Don’t forget if you have automated yum updates configured (e.g. cPanel does this), add iproute* to the exclude= line in /etc/yum.conf for the time being.

Wednesday, 4 December 2013

How to install php-ldap module on CentOS

yum install php-ldap

vi /etc/php.ini

add extension=ldap.so

service httpd restart