 |
|
| Support Home Documentation Knowledgebase Help Desk Blog |
| Hosting > VPS > Linux VPS > Administration > | Sunday, October 12, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuring the Linux VPSThe instructions included in the following sections describe the tasks which enable you to complete the initial configuration of your private server:
Connect to Your Private Server the First TimeWhen you ordered your private server, you provided a username and password for your administrative user account. This account is the one you will use to connect to your private server to perform administrative tasks.Your administrative user is the primary user for managing your Account, and has email and FTP permissions, as well as the ability to manage virtual user accounts, as well as managing FTP, Web, and email configuration. In addition, the administrative user is a member of the wheel group, which means that the administrative user can use the su command to become the root user. When you connect to your private server to perform administrative tasks, always connect using a secure protocol (such as SSH, SFTP, or SCP). Avoid connecting to your private server directly as the root user, and never use an insecure protocol when doing so. A successful login places you in the User Home Directory. Only the User's files and directories are accessible here. To access the main server directories you will need to change your current directory to the Server Directory. Keep in mind that the user root is the primary administrative user on your private server. To modify many system files, including adding or modifying users, you must be root. Because root is such an important user with so much power, you should be especially careful about selecting a root password and maintaining its security. Only after you configure SSH keys are you able to connect directly to your private server as the user root. Until then, any user who belongs to the wheel group, such as the Administrative User that was created when your private server was provisioned, can SSH to the server and then use the su command to become root. Never use an insecure protocol such as Telnet for administrative tasks. If you do, any non-encrypted data could be sniffed by malicious hackers. Because the root user should only be used for administrative purposes, root does not have email or Web permissions. All users with shell access are able to login in as a substitute user (or su). This enables authorized users to become the root user, or it enables the root user to become another user. Once you become root, however, use the su command to become another user on the server without requiring a password. Access Your Private ServerShell provides a powerful tool for your private server administration tasks. Using an SSH (Secure Shell) client, connect and log in to your private server from anywhere in the world. You have SSH access to your private server. Your private server benefits from a security hardened environment which ensures that your data is not compromised. Using SSH, log into a remote machine such as your private server and provide secure, encrypted communications between your private server and your local computer. Because SSH provides complete shell capability over a secure channel, it is the useful tool for managing your private server. While SSH is preferable to Telnet, most operating systems include a Telnet client. Shell also includes a built-in Telnet client program.Once you have determined a SSH client, connecting to your private server requires you to specify a remote host. Your remote host is your private server, so you would specify your domain name (or your temporary domain, if applicable) or IP addresses. At some point, you are prompted for your login name and login password. You specified both your login name and login password when you ordered your private server. After the login process is successful, you will have gained access to your private server and can now issue commands at the command prompt. Follow these steps to access your private server by means of SSH:
Creating and Editing User AccountsYour private server enables you to create new users by manually editing the files that contain user information. To make the task easier, your private server supports commands which guide you through the process.The vadduser command is a standard command with which to add user accounts. If you are not familiar with the command, however, it can be confusing. For more information on the command, refer to the manual pages. To issue the vadduser command, connect to your private server by means of SSH and then type vadduser at the command prompt. The on screen instructions prompt you for the required information. The vedituser command is a custom script that modifies an existing user account. You are prompted to modify the user information, including permissions and quota. There are also several other tools that exist which you want to become familiar with. For more information about other tools, refer to the relevant manual pages.
When a user account is no longer needed, remove the account using the rmuser command. This gives you the option to keep or remove the home directory as well. Do not use this command to disable a user who you intend to reestablish at a later time. In those cases, it is better to change the password or to disable a user's privileges. User information is stored in several different files on your private server. First, the /etc/passwd file contains a list of user names, along with some account information. The following is a sample entry for the user test: test:*:1001:1001:Test User Account:/home/test:/usr/local/bin/tcshThe entry contains seven fields in a colon (:) delimited list. The first field is the username, followed by an asterisk (*), which represents the password. As a security measure, passwords are not actually stored in the /etc/passwd file, so you see an asterisk instead. Next are two numbers, the User ID number and the Group ID number. These are used by the account to track file access and ownership rights. After the numbers, the real name or a description of the user account, followed by the user's home directory, and finally the shell they are allowed to use. User passwords are stored in an encrypted format in the /etc/shadow file. This file is similar to the passwd file, although there are a few extra fields that the system uses. Additional user information is stored in files such as /etc/group and /aquota.user. Administrators can view users and user quota information. The vlistuser command displays a list of all the user accounts (excluding the system users). The following is an example of the output of the vlistuser command.
Configure Virtual Sub HostsVirtual sub hosting is one of the most powerful features of your private server and the Apache HTTP Server. This feature enables you to support multiple domain names that each resolve to their own unique subdirectories on a single Account. You can host example1.com and example2.com on the same account, each with its own domain name and unique site content. Provide each virtual sub host customer their own unique FTP login with access to their own subdirectory and email addresses using their own domain name.For performance reasons, you must adhere to guidelines with regard to the number of virtual sub hosts you should place on a single account. Keep in mind that these guidelines are suggested so that the performance of your own account and virtual sub host domains are not compromised. Here are guidelines to follow:
Create a Virtual HostThe vaddhost utility is an interactive, command-line program that automates the process of configuring virtual sub hosts. After launching vaddhost, it will ask you several questions about the configuration of your virtual sub host and provide you with default responses. As you answer each question, vaddhost will display the Virtual Host definition with each new piece of information.Once you have responded to all questions, vaddhost will create necessary directories, add the virtual host entry to your main Web server configuration file (/www/conf/httpd.conf), and create a backup of your old /www/conf/httpd.conf file in your /www/conf directory. Remove these backup files at your discretion. Note: If your Web server configuration file (/www/conf/httpd.conf) does not already have the NameVirtualHost directive, you will need to add it before adding any virtual sub hosts.To issue the vaddhost command, connect to your private server by means of SSH () and do the following:
CGI Scripts and Security IssuesIt is important to consider some of the security issues that relate to virtual sub hosting. In most cases it is likely that not only are you providing your clients with hosting service, but you are also designing their Web content and writing their CGI scripts as well.Because the virtual sub hosts operate in the same account environment, CGI scripts that are executed by any virtual sub host will inherit privileges to access any directory or file in your private server directory hierarchy. For example, a malicious virtual subhosted client could write a simple script to remove all of the files on your private server. Another script could send the contents of your /etc/passwd file to a remote email address where weak passwords could be decrypted. If your login password is susceptible to a dictionary crack, a subhosted client could effectively steal shell access away from you. Do not offer full CGI-binary access to your virtual subhosted users unless you have complete trust in them (even then, they can accidentally cause damage to your private server). Most Web sites do not demand a great deal of custom CGI programming. It is likely that you could provide a library of pre-made CGI scripts which your subhosted clients could then use. A sample composition of such a library can include: a counter, a guestbook, and a generic form processor. You would store these scripts in a subdirectory of your CGI-binary directory. You would then configure each of your virtual sub hosts to use this cgi-bin directory by adding the following lines to their virtual host definition: ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/sub-lib/Another alternative is to provide your subhosted clients with a CGI-binary that is not a subdirectory in their home directory. This would prohibit them from uploading and executing any arbitrary script. Instead, the subhosted client would email you the script, you would review it, and then install it into their CGI-binary directory (which can be configured to be a subdirectory of your main CGI-binary directory). An example is shown below: ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/SUBDIRECTORY/In this case, SUBDIRECTORY becomes the CGI-binary directory for a specific subhosted client (use the same subdirectory name for both the /www/vhosts and /www/cgi-bin to keep them organized). Verify Core ServicesVerify SMTP, POP3, IMAP, FTP, and Web operations, as follows:
Verify ResourcesAccess information about the following aspects of the resources available on your private server:
|
|
| Home | Site Map | Customer Backroom | Copyright © 1997-2008 AlpineWeb Design |