https://wiki.archlinux.org/api.php?action=feedcontributions&user=Garfiield&feedformat=atomArchWiki - User contributions [en]2024-03-28T19:34:08ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Server&diff=77227Server2009-10-05T17:18:35Z<p>Garfiield: /* SE Linux */ Fixed link to other wiki page to be internal instead of external</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Box Note | This article is currently undergoing a complete rewrite. We're extending the article to include more than just web services and removing specific installation instructions with links to already available articles. We'll strive to make this article complete and explenatory in nature. '''What you currently see is a work in progress.'''}}<br />
<br />
<br />
== Preface ==<br />
<br />
==== What is a server? ====<br />
In essence, a server is a computer that runs services that involve clients working on remote locations. All computers run services of some kind, for example: when using Arch as a desktop you will have a network service running to connect to a network. A server will, however, run services that involve external clients, for example: a webserver will run a website to be viewed via the internet or elsewhere on a local network.<br />
<br />
==== Why would I want a server? ====<br />
There are various reasons you may want a server. You may want to create a website for a company or you may wish to have an internal database for your network. Maybe you need a central fileserver for your home-network? This guide will give you an overview for the most common server options in existence and will outline some administration and security guidelines.<br />
<br />
==== Arch Linux as a server OS ====<br />
You may have seen the comments or claims: ''Arch Linux was never intended as a server operating system!'' This is correct: The basic installation includes next to none server features and there is no server installation disc available. This does not mean it's not possible, '''quite the contrary'''. Arch's core installation is a secure and capable foundation. Because of the low amount of things that come pre-installed, this core installation can easily be used as a basis for a Linux Server. Many applications and services you would want on a server (such as apache, sql and samba) are available in the repository and are well documented on the wiki.<br />
<br />
{{Note | Add note about users using arch as server.}}<br />
<br />
== Requirements ==<br />
For using Arch Linux on a server you will need to have an Arch Linux installation ready.<br />
<br />
In most Linux server Operating Systems you have 2 options:<br />
* A 'text' version of the OS (where everything is done from the command line)<br />
* A GUI version of the OS (where you get a desktop interface such as GNOME/KDE etc). <br />
<br />
{{Note | If you have services on your server that need to be administered using a gui and cannot be done remotely you must choose the second option.}} <br />
<br />
For the installation of Arch Linux, please refer to [[Beginners_Guide|the Beginner's Guide]], but do not go any further [[Beginners_Guide#Part_III:_Install_X_and_configure_ALSA|than this section]] unless you require a GUI.<br />
<br />
== Basic set-up ==<br />
So what is a "basic" set-up:<br />
* Remote acess to the server.<br />
We want to be able to remotely log-on to our server to perform several administrative tasks. When your server is located elsewhere or does not have a monitor attached: removing or adding files, changing configuration options and server rebooting are all tasks which are impossible to do without a way to log on to your server remotely. SSH nicely provides this functionallity.<br />
<br />
* Your '''L'''inux server.<br />
* A http server ('''A'''pache), required for serving webpages.<br />
* A database server ('''M'''ySql), often required for storing data of address book-, forum- or blog scripts.<br />
* The '''P'''HP scripting language, a highly popular internet scripting language used in blogs, forums, content management systems and many other web-scripts.<br />
As the bold letters suggest, there is a name for this combination of applications: LAMP.<br />
<br />
The following sections will guide you through the installation and confgiuration of the above mentionned basic set-up features.<br />
<br />
==== SSH ====<br />
SSH stands for '''S'''ecure '''Sh'''ell. SSH enables you to log on to your server through an SSH client, presenting you with a recognizable terminal-like interface.Users available on the system can be given access to log on remotely though SSH, thereby enabeling remote administration of your server.<br />
<br />
The [[SSH|Arch wiki SSH page]] covers Installation and Configuration nicely.<br />
<br />
==== LAMP ====<br />
A [http://en.wikipedia.org/wiki/LAMP_(software_bundle) LAMP] server is a reasonably standard webserver. <br><br />
There are often disputes as to what the 'P' stands for, some people say it is [http://www.php.net/ php] some people say it is [http://www.perl.org/ perl] while others say it's [http://www.python.org/ python]. For the purposes of this guide I am going to make it php, although there are some nice perl modules for linux so you may wish to install perl as well. <br><br />
Having said that, LAMP is a reasonably standard webserver, it is by no means simple so there may be a lot to take in here. <br />
<br />
<br />
Please refer to the [[LAMP]] wiki page for instructions on installation and configuration.<br />
<br />
== Additional web-services ==<br />
<br />
=== E-Mail ===<br />
<br />
{{Note | TODO: Add postfix and add introduction to E-Mail and describe the options}}<br />
<br />
Please refer to the [[Exim with a remote SMTP server | EXIM]] wiki page for instructions on installation and configuration.<br />
<br />
=== FTP ===<br />
<br />
FTP stands for '''F'''ile '''T'''ransfer '''P'''rotocol. FTP is a service that can provide access to the filesystem from a remote location through an FTP client (FileZilla, gftp etc.) or FTP-capable browser. Through FTP, you are able to add or remove files from a remote location, as well as apply some chmod commands to these files to set certain permissions. <br />
<br />
FTP access will be related to user accounts available on the system, allowing simple rights management. FTP is a much used tool for adding files to a webserver from a remote locations.<br />
<br />
There are several FTP daemons available, here follows a list of Arch Linux Wiki pages on a few:<br />
* [[Vsftpd|vsFTPd]]: Very Secure FTP Daemon (oftend the standard)<br />
* [[Glftpd|glFTPd]]: GreyLine FTP daemon (highly configurable, no system accounts required)<br />
* [[Proftpd|proFTPd]]: Article is incomplete.<br />
<br />
There is also the option of FTP over SSH, or [[SFTP]]<br />
<br />
== Local Network Services ==<br />
<br />
=== CUPS (printing) ===<br />
<br />
CUPS, or '''C'''ommon '''U'''NIX '''P'''rinting '''S'''ystem, can provide a central point via which a number of users can print. For instance, you have several (say 3) printers and several people on a local network that wish to print. You can either add all these printers to every user's pc, or add all printers to a server running CUPS, and then simply adding the server to all clients. This allows for a central printing system that can be online 24/7, especially nice for printers that do not have networking capabillities.<br />
<br />
Please refer to the [[CUPS]] wiki page for instructions on installation and configuration.<br />
<br />
=== DHCP ===<br />
{{Note | dhcp v4 does not currently work due to ipv6 issues, this guide part of the guide will be written when that issue is resolved.}}<br />
<br />
=== Samba (windows compatible file- and printer sharing) ===<br />
Samba is an open source implementation of SBM/CIFS networking protocols, effectively allowing you to share files and printers between Linux and Windows systems. Samba can provide public shares or require several forms of authentification.<br />
<br />
Please refer to the [[Samba]] wiki page for instructions on installation and configuration.<br />
<br />
== Security ==<br />
<br />
=== Firewall ===<br />
{{Note | TODO: mention iptables and possible GUI to this in case of a server with a DE}}<br />
<br />
=== Protecting SSH ===<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
* Use non-standard account names and passwords<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use denyhosts to monitor for brute force attacks, and ban brute forcing IPs accordingly<br />
<br />
===== Limiting access to SSH =====<br />
Firstly, let us check if our installation of arch linux is secure in terms of allowing external parties access to services on our server. The ''/etc/hosts.deny'' file should look like this:<br />
ALL: ALL: DENY<br />
<br />
This means that ALL hosts are DENIED ACCESS to ALL services on the system. Now, to actually allow remote hosts access to the services on our server, we should edit the counterpart of ''hosts.deny'' called ''hosts.allow''. <br />
<br />
The [[SSH#Allowing_others_in wiki |SSH]] wiki article mentions editing ''/etc/hosts.allow'' to allow outside connections to the SSH daemon.<br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0 <br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
You may not always know beforehand from what location you will be accessing your server. However, if you do know (i.e. you will be accessing your headless server from your desktop system with a fixed IP), it is wise to allow access '''only''' from these known locations.<br />
<br />
If you want more broad access to your server through SSH, from any location at any given time, you will have to allow ALL. This poses a threat, opening your SSH daemon for connections from anyone. These third parties will then be able to try and log in through means of brute force: continuously trying to log on with random user names and password combinations.<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. There are several ways to protect yourself from brute force attacks:<br />
* Deny access to the SSH daemon throuh well configured ''hosts.deny'' and ''hosts.allow''<br />
* Use an automated script that blocks anybody trying to brute force their way in.<br />
<br />
[[DenyHosts|Denyhosts]] is such a script. It constantly monitors ''/var/log/auth.log'' for incorrect login attempts and disables access to SSH, for that host, after a certain amount of incorrect login attempts has been reached. I consider this a vital addition to any server offering remote access through SSH.<br />
<br />
Please refer to the [[DenyHosts|Denyhosts]] wikipage for proper installation and configuration on Arch Linux.<br />
<br />
===== Deny root login =====<br />
It is generally considered bad practice to allow the user '''root''' to log in over SSH: The '''root''' account will exist on nearly any linux system and grants full access to the system, once login has been acchieved. Sudo provides root rights for actions requiring these and is the more secure solution, third parties would have to find a username present on the system, the matching password and the matching password for sudo to get root rights on your system. More barries to be breached before full access to the system is reached.<br />
<br />
Configure SSH to deny remote logins with the root user by editing (as root) ''/etc/sshd/sshd_config'' and look for this section:<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
''#PermitRootLogin yes''<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
Now simply change ''#PermitRootLogin yes'' to no, uncomment the line and restart the SSH daemon:<br />
PermitRootLogin no<br />
<br />
/etc/rc.d/sshd restart<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use ''su'' - or ''sudo'' to do system administration.<br />
<br />
=== SE Linux ===<br />
<br />
{{Note | SELinux is extremely intensive and can cause big problems, I would suggest not using it unless you absolutely require it.}}<br />
Please refer to the [[SELinux]] wiki page for instructions on installation and configuration, the page is only a stub, if you use SELinux you are on your own.<br />
<br />
== Administration and maintenance ==<br />
<br />
==== Accessibility ====<br />
'''SSH:'''<br />
Enabling SSH so you can remotely control your server via the command line. <br />
<br />
'''X Forwarding'''<br />
Forwarding your X session so you can login to the desktop GUI remotely (ignore this if you did not install a desktop GUI).<br />
<br />
== Extras ==<br />
<br />
=== phpMyAdmin ===<br />
"phpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement." http://www.phpmyadmin.net/home_page/index.php<br />
<br />
== More Resources ==<br />
* [[MySQL]] - Arch wiki article for MySQL<br />
* http://www.apache.org/<br />
* http://www.php.net/<br />
* http://www.mysql.com/</div>Garfiieldhttps://wiki.archlinux.org/index.php?title=Server&diff=77226Server2009-10-05T17:16:25Z<p>Garfiield: /* Protecting against brute force attacks */ Fixed links to other wiki pages to be internal instead of external</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Box Note | This article is currently undergoing a complete rewrite. We're extending the article to include more than just web services and removing specific installation instructions with links to already available articles. We'll strive to make this article complete and explenatory in nature. '''What you currently see is a work in progress.'''}}<br />
<br />
<br />
== Preface ==<br />
<br />
==== What is a server? ====<br />
In essence, a server is a computer that runs services that involve clients working on remote locations. All computers run services of some kind, for example: when using Arch as a desktop you will have a network service running to connect to a network. A server will, however, run services that involve external clients, for example: a webserver will run a website to be viewed via the internet or elsewhere on a local network.<br />
<br />
==== Why would I want a server? ====<br />
There are various reasons you may want a server. You may want to create a website for a company or you may wish to have an internal database for your network. Maybe you need a central fileserver for your home-network? This guide will give you an overview for the most common server options in existence and will outline some administration and security guidelines.<br />
<br />
==== Arch Linux as a server OS ====<br />
You may have seen the comments or claims: ''Arch Linux was never intended as a server operating system!'' This is correct: The basic installation includes next to none server features and there is no server installation disc available. This does not mean it's not possible, '''quite the contrary'''. Arch's core installation is a secure and capable foundation. Because of the low amount of things that come pre-installed, this core installation can easily be used as a basis for a Linux Server. Many applications and services you would want on a server (such as apache, sql and samba) are available in the repository and are well documented on the wiki.<br />
<br />
{{Note | Add note about users using arch as server.}}<br />
<br />
== Requirements ==<br />
For using Arch Linux on a server you will need to have an Arch Linux installation ready.<br />
<br />
In most Linux server Operating Systems you have 2 options:<br />
* A 'text' version of the OS (where everything is done from the command line)<br />
* A GUI version of the OS (where you get a desktop interface such as GNOME/KDE etc). <br />
<br />
{{Note | If you have services on your server that need to be administered using a gui and cannot be done remotely you must choose the second option.}} <br />
<br />
For the installation of Arch Linux, please refer to [[Beginners_Guide|the Beginner's Guide]], but do not go any further [[Beginners_Guide#Part_III:_Install_X_and_configure_ALSA|than this section]] unless you require a GUI.<br />
<br />
== Basic set-up ==<br />
So what is a "basic" set-up:<br />
* Remote acess to the server.<br />
We want to be able to remotely log-on to our server to perform several administrative tasks. When your server is located elsewhere or does not have a monitor attached: removing or adding files, changing configuration options and server rebooting are all tasks which are impossible to do without a way to log on to your server remotely. SSH nicely provides this functionallity.<br />
<br />
* Your '''L'''inux server.<br />
* A http server ('''A'''pache), required for serving webpages.<br />
* A database server ('''M'''ySql), often required for storing data of address book-, forum- or blog scripts.<br />
* The '''P'''HP scripting language, a highly popular internet scripting language used in blogs, forums, content management systems and many other web-scripts.<br />
As the bold letters suggest, there is a name for this combination of applications: LAMP.<br />
<br />
The following sections will guide you through the installation and confgiuration of the above mentionned basic set-up features.<br />
<br />
==== SSH ====<br />
SSH stands for '''S'''ecure '''Sh'''ell. SSH enables you to log on to your server through an SSH client, presenting you with a recognizable terminal-like interface.Users available on the system can be given access to log on remotely though SSH, thereby enabeling remote administration of your server.<br />
<br />
The [[SSH|Arch wiki SSH page]] covers Installation and Configuration nicely.<br />
<br />
==== LAMP ====<br />
A [http://en.wikipedia.org/wiki/LAMP_(software_bundle) LAMP] server is a reasonably standard webserver. <br><br />
There are often disputes as to what the 'P' stands for, some people say it is [http://www.php.net/ php] some people say it is [http://www.perl.org/ perl] while others say it's [http://www.python.org/ python]. For the purposes of this guide I am going to make it php, although there are some nice perl modules for linux so you may wish to install perl as well. <br><br />
Having said that, LAMP is a reasonably standard webserver, it is by no means simple so there may be a lot to take in here. <br />
<br />
<br />
Please refer to the [[LAMP]] wiki page for instructions on installation and configuration.<br />
<br />
== Additional web-services ==<br />
<br />
=== E-Mail ===<br />
<br />
{{Note | TODO: Add postfix and add introduction to E-Mail and describe the options}}<br />
<br />
Please refer to the [[Exim with a remote SMTP server | EXIM]] wiki page for instructions on installation and configuration.<br />
<br />
=== FTP ===<br />
<br />
FTP stands for '''F'''ile '''T'''ransfer '''P'''rotocol. FTP is a service that can provide access to the filesystem from a remote location through an FTP client (FileZilla, gftp etc.) or FTP-capable browser. Through FTP, you are able to add or remove files from a remote location, as well as apply some chmod commands to these files to set certain permissions. <br />
<br />
FTP access will be related to user accounts available on the system, allowing simple rights management. FTP is a much used tool for adding files to a webserver from a remote locations.<br />
<br />
There are several FTP daemons available, here follows a list of Arch Linux Wiki pages on a few:<br />
* [[Vsftpd|vsFTPd]]: Very Secure FTP Daemon (oftend the standard)<br />
* [[Glftpd|glFTPd]]: GreyLine FTP daemon (highly configurable, no system accounts required)<br />
* [[Proftpd|proFTPd]]: Article is incomplete.<br />
<br />
There is also the option of FTP over SSH, or [[SFTP]]<br />
<br />
== Local Network Services ==<br />
<br />
=== CUPS (printing) ===<br />
<br />
CUPS, or '''C'''ommon '''U'''NIX '''P'''rinting '''S'''ystem, can provide a central point via which a number of users can print. For instance, you have several (say 3) printers and several people on a local network that wish to print. You can either add all these printers to every user's pc, or add all printers to a server running CUPS, and then simply adding the server to all clients. This allows for a central printing system that can be online 24/7, especially nice for printers that do not have networking capabillities.<br />
<br />
Please refer to the [[CUPS]] wiki page for instructions on installation and configuration.<br />
<br />
=== DHCP ===<br />
{{Note | dhcp v4 does not currently work due to ipv6 issues, this guide part of the guide will be written when that issue is resolved.}}<br />
<br />
=== Samba (windows compatible file- and printer sharing) ===<br />
Samba is an open source implementation of SBM/CIFS networking protocols, effectively allowing you to share files and printers between Linux and Windows systems. Samba can provide public shares or require several forms of authentification.<br />
<br />
Please refer to the [[Samba]] wiki page for instructions on installation and configuration.<br />
<br />
== Security ==<br />
<br />
=== Firewall ===<br />
{{Note | TODO: mention iptables and possible GUI to this in case of a server with a DE}}<br />
<br />
=== Protecting SSH ===<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
* Use non-standard account names and passwords<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use denyhosts to monitor for brute force attacks, and ban brute forcing IPs accordingly<br />
<br />
===== Limiting access to SSH =====<br />
Firstly, let us check if our installation of arch linux is secure in terms of allowing external parties access to services on our server. The ''/etc/hosts.deny'' file should look like this:<br />
ALL: ALL: DENY<br />
<br />
This means that ALL hosts are DENIED ACCESS to ALL services on the system. Now, to actually allow remote hosts access to the services on our server, we should edit the counterpart of ''hosts.deny'' called ''hosts.allow''. <br />
<br />
The [[SSH#Allowing_others_in wiki |SSH]] wiki article mentions editing ''/etc/hosts.allow'' to allow outside connections to the SSH daemon.<br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0 <br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
You may not always know beforehand from what location you will be accessing your server. However, if you do know (i.e. you will be accessing your headless server from your desktop system with a fixed IP), it is wise to allow access '''only''' from these known locations.<br />
<br />
If you want more broad access to your server through SSH, from any location at any given time, you will have to allow ALL. This poses a threat, opening your SSH daemon for connections from anyone. These third parties will then be able to try and log in through means of brute force: continuously trying to log on with random user names and password combinations.<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. There are several ways to protect yourself from brute force attacks:<br />
* Deny access to the SSH daemon throuh well configured ''hosts.deny'' and ''hosts.allow''<br />
* Use an automated script that blocks anybody trying to brute force their way in.<br />
<br />
[[DenyHosts|Denyhosts]] is such a script. It constantly monitors ''/var/log/auth.log'' for incorrect login attempts and disables access to SSH, for that host, after a certain amount of incorrect login attempts has been reached. I consider this a vital addition to any server offering remote access through SSH.<br />
<br />
Please refer to the [[DenyHosts|Denyhosts]] wikipage for proper installation and configuration on Arch Linux.<br />
<br />
===== Deny root login =====<br />
It is generally considered bad practice to allow the user '''root''' to log in over SSH: The '''root''' account will exist on nearly any linux system and grants full access to the system, once login has been acchieved. Sudo provides root rights for actions requiring these and is the more secure solution, third parties would have to find a username present on the system, the matching password and the matching password for sudo to get root rights on your system. More barries to be breached before full access to the system is reached.<br />
<br />
Configure SSH to deny remote logins with the root user by editing (as root) ''/etc/sshd/sshd_config'' and look for this section:<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
''#PermitRootLogin yes''<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
Now simply change ''#PermitRootLogin yes'' to no, uncomment the line and restart the SSH daemon:<br />
PermitRootLogin no<br />
<br />
/etc/rc.d/sshd restart<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use ''su'' - or ''sudo'' to do system administration.<br />
<br />
=== SE Linux ===<br />
<br />
{{Note | SELinux is extremely intensive and can cause big problems, I would suggest not using it unless you absolutely require it.}}<br />
Please refer to the [http://wiki.archlinux.org/index.php/SELinux SELinux] wiki page for instructions on installation and configuration, the page is only a stub, if you use SELinux you are on your own.<br />
<br />
== Administration and maintenance ==<br />
<br />
==== Accessibility ====<br />
'''SSH:'''<br />
Enabling SSH so you can remotely control your server via the command line. <br />
<br />
'''X Forwarding'''<br />
Forwarding your X session so you can login to the desktop GUI remotely (ignore this if you did not install a desktop GUI).<br />
<br />
== Extras ==<br />
<br />
=== phpMyAdmin ===<br />
"phpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement." http://www.phpmyadmin.net/home_page/index.php<br />
<br />
== More Resources ==<br />
* [[MySQL]] - Arch wiki article for MySQL<br />
* http://www.apache.org/<br />
* http://www.php.net/<br />
* http://www.mysql.com/</div>Garfiieldhttps://wiki.archlinux.org/index.php?title=Server&diff=77225Server2009-10-05T17:09:29Z<p>Garfiield: /* FTP */ Fixed links to other wiki pages to be internal instead of external</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Box Note | This article is currently undergoing a complete rewrite. We're extending the article to include more than just web services and removing specific installation instructions with links to already available articles. We'll strive to make this article complete and explenatory in nature. '''What you currently see is a work in progress.'''}}<br />
<br />
<br />
== Preface ==<br />
<br />
==== What is a server? ====<br />
In essence, a server is a computer that runs services that involve clients working on remote locations. All computers run services of some kind, for example: when using Arch as a desktop you will have a network service running to connect to a network. A server will, however, run services that involve external clients, for example: a webserver will run a website to be viewed via the internet or elsewhere on a local network.<br />
<br />
==== Why would I want a server? ====<br />
There are various reasons you may want a server. You may want to create a website for a company or you may wish to have an internal database for your network. Maybe you need a central fileserver for your home-network? This guide will give you an overview for the most common server options in existence and will outline some administration and security guidelines.<br />
<br />
==== Arch Linux as a server OS ====<br />
You may have seen the comments or claims: ''Arch Linux was never intended as a server operating system!'' This is correct: The basic installation includes next to none server features and there is no server installation disc available. This does not mean it's not possible, '''quite the contrary'''. Arch's core installation is a secure and capable foundation. Because of the low amount of things that come pre-installed, this core installation can easily be used as a basis for a Linux Server. Many applications and services you would want on a server (such as apache, sql and samba) are available in the repository and are well documented on the wiki.<br />
<br />
{{Note | Add note about users using arch as server.}}<br />
<br />
== Requirements ==<br />
For using Arch Linux on a server you will need to have an Arch Linux installation ready.<br />
<br />
In most Linux server Operating Systems you have 2 options:<br />
* A 'text' version of the OS (where everything is done from the command line)<br />
* A GUI version of the OS (where you get a desktop interface such as GNOME/KDE etc). <br />
<br />
{{Note | If you have services on your server that need to be administered using a gui and cannot be done remotely you must choose the second option.}} <br />
<br />
For the installation of Arch Linux, please refer to [[Beginners_Guide|the Beginner's Guide]], but do not go any further [[Beginners_Guide#Part_III:_Install_X_and_configure_ALSA|than this section]] unless you require a GUI.<br />
<br />
== Basic set-up ==<br />
So what is a "basic" set-up:<br />
* Remote acess to the server.<br />
We want to be able to remotely log-on to our server to perform several administrative tasks. When your server is located elsewhere or does not have a monitor attached: removing or adding files, changing configuration options and server rebooting are all tasks which are impossible to do without a way to log on to your server remotely. SSH nicely provides this functionallity.<br />
<br />
* Your '''L'''inux server.<br />
* A http server ('''A'''pache), required for serving webpages.<br />
* A database server ('''M'''ySql), often required for storing data of address book-, forum- or blog scripts.<br />
* The '''P'''HP scripting language, a highly popular internet scripting language used in blogs, forums, content management systems and many other web-scripts.<br />
As the bold letters suggest, there is a name for this combination of applications: LAMP.<br />
<br />
The following sections will guide you through the installation and confgiuration of the above mentionned basic set-up features.<br />
<br />
==== SSH ====<br />
SSH stands for '''S'''ecure '''Sh'''ell. SSH enables you to log on to your server through an SSH client, presenting you with a recognizable terminal-like interface.Users available on the system can be given access to log on remotely though SSH, thereby enabeling remote administration of your server.<br />
<br />
The [[SSH|Arch wiki SSH page]] covers Installation and Configuration nicely.<br />
<br />
==== LAMP ====<br />
A [http://en.wikipedia.org/wiki/LAMP_(software_bundle) LAMP] server is a reasonably standard webserver. <br><br />
There are often disputes as to what the 'P' stands for, some people say it is [http://www.php.net/ php] some people say it is [http://www.perl.org/ perl] while others say it's [http://www.python.org/ python]. For the purposes of this guide I am going to make it php, although there are some nice perl modules for linux so you may wish to install perl as well. <br><br />
Having said that, LAMP is a reasonably standard webserver, it is by no means simple so there may be a lot to take in here. <br />
<br />
<br />
Please refer to the [[LAMP]] wiki page for instructions on installation and configuration.<br />
<br />
== Additional web-services ==<br />
<br />
=== E-Mail ===<br />
<br />
{{Note | TODO: Add postfix and add introduction to E-Mail and describe the options}}<br />
<br />
Please refer to the [[Exim with a remote SMTP server | EXIM]] wiki page for instructions on installation and configuration.<br />
<br />
=== FTP ===<br />
<br />
FTP stands for '''F'''ile '''T'''ransfer '''P'''rotocol. FTP is a service that can provide access to the filesystem from a remote location through an FTP client (FileZilla, gftp etc.) or FTP-capable browser. Through FTP, you are able to add or remove files from a remote location, as well as apply some chmod commands to these files to set certain permissions. <br />
<br />
FTP access will be related to user accounts available on the system, allowing simple rights management. FTP is a much used tool for adding files to a webserver from a remote locations.<br />
<br />
There are several FTP daemons available, here follows a list of Arch Linux Wiki pages on a few:<br />
* [[Vsftpd|vsFTPd]]: Very Secure FTP Daemon (oftend the standard)<br />
* [[Glftpd|glFTPd]]: GreyLine FTP daemon (highly configurable, no system accounts required)<br />
* [[Proftpd|proFTPd]]: Article is incomplete.<br />
<br />
There is also the option of FTP over SSH, or [[SFTP]]<br />
<br />
== Local Network Services ==<br />
<br />
=== CUPS (printing) ===<br />
<br />
CUPS, or '''C'''ommon '''U'''NIX '''P'''rinting '''S'''ystem, can provide a central point via which a number of users can print. For instance, you have several (say 3) printers and several people on a local network that wish to print. You can either add all these printers to every user's pc, or add all printers to a server running CUPS, and then simply adding the server to all clients. This allows for a central printing system that can be online 24/7, especially nice for printers that do not have networking capabillities.<br />
<br />
Please refer to the [[CUPS]] wiki page for instructions on installation and configuration.<br />
<br />
=== DHCP ===<br />
{{Note | dhcp v4 does not currently work due to ipv6 issues, this guide part of the guide will be written when that issue is resolved.}}<br />
<br />
=== Samba (windows compatible file- and printer sharing) ===<br />
Samba is an open source implementation of SBM/CIFS networking protocols, effectively allowing you to share files and printers between Linux and Windows systems. Samba can provide public shares or require several forms of authentification.<br />
<br />
Please refer to the [[Samba]] wiki page for instructions on installation and configuration.<br />
<br />
== Security ==<br />
<br />
=== Firewall ===<br />
{{Note | TODO: mention iptables and possible GUI to this in case of a server with a DE}}<br />
<br />
=== Protecting SSH ===<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
* Use non-standard account names and passwords<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use denyhosts to monitor for brute force attacks, and ban brute forcing IPs accordingly<br />
<br />
===== Limiting access to SSH =====<br />
Firstly, let us check if our installation of arch linux is secure in terms of allowing external parties access to services on our server. The ''/etc/hosts.deny'' file should look like this:<br />
ALL: ALL: DENY<br />
<br />
This means that ALL hosts are DENIED ACCESS to ALL services on the system. Now, to actually allow remote hosts access to the services on our server, we should edit the counterpart of ''hosts.deny'' called ''hosts.allow''. <br />
<br />
The [[SSH#Allowing_others_in wiki |SSH]] wiki article mentions editing ''/etc/hosts.allow'' to allow outside connections to the SSH daemon.<br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0 <br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
You may not always know beforehand from what location you will be accessing your server. However, if you do know (i.e. you will be accessing your headless server from your desktop system with a fixed IP), it is wise to allow access '''only''' from these known locations.<br />
<br />
If you want more broad access to your server through SSH, from any location at any given time, you will have to allow ALL. This poses a threat, opening your SSH daemon for connections from anyone. These third parties will then be able to try and log in through means of brute force: continuously trying to log on with random user names and password combinations.<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. There are several ways to protect yourself from brute force attacks:<br />
* Deny access to the SSH daemon throuh well configured ''hosts.deny'' and ''hosts.allow''<br />
* Use an automated script that blocks anybody trying to brute force their way in.<br />
<br />
[http://wiki.archlinux.org/index.php/DenyHosts Denyhosts] is such a script. It constantly monitors ''/var/log/auth.log'' for incorrect login attempts and disables access to SSH, for that host, after a certain amount of incorrect login attempts has been reached. I consider this a vital addition to any server offering remote access through SSH.<br />
<br />
Please refer to the [http://wiki.archlinux.org/index.php/DenyHosts Denyhosts] wikipage for proper installation and configuration on Arch Linux.<br />
<br />
===== Deny root login =====<br />
It is generally considered bad practice to allow the user '''root''' to log in over SSH: The '''root''' account will exist on nearly any linux system and grants full access to the system, once login has been acchieved. Sudo provides root rights for actions requiring these and is the more secure solution, third parties would have to find a username present on the system, the matching password and the matching password for sudo to get root rights on your system. More barries to be breached before full access to the system is reached.<br />
<br />
Configure SSH to deny remote logins with the root user by editing (as root) ''/etc/sshd/sshd_config'' and look for this section:<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
''#PermitRootLogin yes''<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
Now simply change ''#PermitRootLogin yes'' to no, uncomment the line and restart the SSH daemon:<br />
PermitRootLogin no<br />
<br />
/etc/rc.d/sshd restart<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use ''su'' - or ''sudo'' to do system administration.<br />
<br />
=== SE Linux ===<br />
<br />
{{Note | SELinux is extremely intensive and can cause big problems, I would suggest not using it unless you absolutely require it.}}<br />
Please refer to the [http://wiki.archlinux.org/index.php/SELinux SELinux] wiki page for instructions on installation and configuration, the page is only a stub, if you use SELinux you are on your own.<br />
<br />
== Administration and maintenance ==<br />
<br />
==== Accessibility ====<br />
'''SSH:'''<br />
Enabling SSH so you can remotely control your server via the command line. <br />
<br />
'''X Forwarding'''<br />
Forwarding your X session so you can login to the desktop GUI remotely (ignore this if you did not install a desktop GUI).<br />
<br />
== Extras ==<br />
<br />
=== phpMyAdmin ===<br />
"phpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement." http://www.phpmyadmin.net/home_page/index.php<br />
<br />
== More Resources ==<br />
* [[MySQL]] - Arch wiki article for MySQL<br />
* http://www.apache.org/<br />
* http://www.php.net/<br />
* http://www.mysql.com/</div>Garfiieldhttps://wiki.archlinux.org/index.php?title=Server&diff=77224Server2009-10-05T17:05:13Z<p>Garfiield: /* Requirements */ Fixed links to other wiki pages to be internal instead of external</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Box Note | This article is currently undergoing a complete rewrite. We're extending the article to include more than just web services and removing specific installation instructions with links to already available articles. We'll strive to make this article complete and explenatory in nature. '''What you currently see is a work in progress.'''}}<br />
<br />
<br />
== Preface ==<br />
<br />
==== What is a server? ====<br />
In essence, a server is a computer that runs services that involve clients working on remote locations. All computers run services of some kind, for example: when using Arch as a desktop you will have a network service running to connect to a network. A server will, however, run services that involve external clients, for example: a webserver will run a website to be viewed via the internet or elsewhere on a local network.<br />
<br />
==== Why would I want a server? ====<br />
There are various reasons you may want a server. You may want to create a website for a company or you may wish to have an internal database for your network. Maybe you need a central fileserver for your home-network? This guide will give you an overview for the most common server options in existence and will outline some administration and security guidelines.<br />
<br />
==== Arch Linux as a server OS ====<br />
You may have seen the comments or claims: ''Arch Linux was never intended as a server operating system!'' This is correct: The basic installation includes next to none server features and there is no server installation disc available. This does not mean it's not possible, '''quite the contrary'''. Arch's core installation is a secure and capable foundation. Because of the low amount of things that come pre-installed, this core installation can easily be used as a basis for a Linux Server. Many applications and services you would want on a server (such as apache, sql and samba) are available in the repository and are well documented on the wiki.<br />
<br />
{{Note | Add note about users using arch as server.}}<br />
<br />
== Requirements ==<br />
For using Arch Linux on a server you will need to have an Arch Linux installation ready.<br />
<br />
In most Linux server Operating Systems you have 2 options:<br />
* A 'text' version of the OS (where everything is done from the command line)<br />
* A GUI version of the OS (where you get a desktop interface such as GNOME/KDE etc). <br />
<br />
{{Note | If you have services on your server that need to be administered using a gui and cannot be done remotely you must choose the second option.}} <br />
<br />
For the installation of Arch Linux, please refer to [[Beginners_Guide|the Beginner's Guide]], but do not go any further [[Beginners_Guide#Part_III:_Install_X_and_configure_ALSA|than this section]] unless you require a GUI.<br />
<br />
== Basic set-up ==<br />
So what is a "basic" set-up:<br />
* Remote acess to the server.<br />
We want to be able to remotely log-on to our server to perform several administrative tasks. When your server is located elsewhere or does not have a monitor attached: removing or adding files, changing configuration options and server rebooting are all tasks which are impossible to do without a way to log on to your server remotely. SSH nicely provides this functionallity.<br />
<br />
* Your '''L'''inux server.<br />
* A http server ('''A'''pache), required for serving webpages.<br />
* A database server ('''M'''ySql), often required for storing data of address book-, forum- or blog scripts.<br />
* The '''P'''HP scripting language, a highly popular internet scripting language used in blogs, forums, content management systems and many other web-scripts.<br />
As the bold letters suggest, there is a name for this combination of applications: LAMP.<br />
<br />
The following sections will guide you through the installation and confgiuration of the above mentionned basic set-up features.<br />
<br />
==== SSH ====<br />
SSH stands for '''S'''ecure '''Sh'''ell. SSH enables you to log on to your server through an SSH client, presenting you with a recognizable terminal-like interface.Users available on the system can be given access to log on remotely though SSH, thereby enabeling remote administration of your server.<br />
<br />
The [[SSH|Arch wiki SSH page]] covers Installation and Configuration nicely.<br />
<br />
==== LAMP ====<br />
A [http://en.wikipedia.org/wiki/LAMP_(software_bundle) LAMP] server is a reasonably standard webserver. <br><br />
There are often disputes as to what the 'P' stands for, some people say it is [http://www.php.net/ php] some people say it is [http://www.perl.org/ perl] while others say it's [http://www.python.org/ python]. For the purposes of this guide I am going to make it php, although there are some nice perl modules for linux so you may wish to install perl as well. <br><br />
Having said that, LAMP is a reasonably standard webserver, it is by no means simple so there may be a lot to take in here. <br />
<br />
<br />
Please refer to the [[LAMP]] wiki page for instructions on installation and configuration.<br />
<br />
== Additional web-services ==<br />
<br />
=== E-Mail ===<br />
<br />
{{Note | TODO: Add postfix and add introduction to E-Mail and describe the options}}<br />
<br />
Please refer to the [[Exim with a remote SMTP server | EXIM]] wiki page for instructions on installation and configuration.<br />
<br />
=== FTP ===<br />
<br />
FTP stands for '''F'''ile '''T'''ransfer '''P'''rotocol. FTP is a service that can provide access to the filesystem from a remote location through an FTP client (FileZilla, gftp etc.) or FTP-capable browser. Through FTP, you are able to add or remove files from a remote location, as well as apply some chmod commands to these files to set certain permissions. <br />
<br />
FTP access will be related to user accounts available on the system, allowing simple rights management. FTP is a much used tool for adding files to a webserver from a remote locations.<br />
<br />
There are several FTP daemons available, here follows a list of Arch Linux Wiki pages on a few:<br />
* [http://wiki.archlinux.org/index.php/Vsftpd vsFTPd]: Very Secure FTP Daemon (oftend the standard)<br />
* [http://wiki.archlinux.org/index.php/Glftpd glFTPd]: GreyLine FTP daemon (highly configurable, no system accounts required)<br />
* [http://wiki.archlinux.org/index.php/Proftpd proFTPd]: Article is incomplete.<br />
<br />
There is also the option of FTP over SSH, or [http://wiki.archlinux.org/index.php/SFTP SFTP]<br />
<br />
== Local Network Services ==<br />
<br />
=== CUPS (printing) ===<br />
<br />
CUPS, or '''C'''ommon '''U'''NIX '''P'''rinting '''S'''ystem, can provide a central point via which a number of users can print. For instance, you have several (say 3) printers and several people on a local network that wish to print. You can either add all these printers to every user's pc, or add all printers to a server running CUPS, and then simply adding the server to all clients. This allows for a central printing system that can be online 24/7, especially nice for printers that do not have networking capabillities.<br />
<br />
Please refer to the [[CUPS]] wiki page for instructions on installation and configuration.<br />
<br />
=== DHCP ===<br />
{{Note | dhcp v4 does not currently work due to ipv6 issues, this guide part of the guide will be written when that issue is resolved.}}<br />
<br />
=== Samba (windows compatible file- and printer sharing) ===<br />
Samba is an open source implementation of SBM/CIFS networking protocols, effectively allowing you to share files and printers between Linux and Windows systems. Samba can provide public shares or require several forms of authentification.<br />
<br />
Please refer to the [[Samba]] wiki page for instructions on installation and configuration.<br />
<br />
== Security ==<br />
<br />
=== Firewall ===<br />
{{Note | TODO: mention iptables and possible GUI to this in case of a server with a DE}}<br />
<br />
=== Protecting SSH ===<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
* Use non-standard account names and passwords<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use denyhosts to monitor for brute force attacks, and ban brute forcing IPs accordingly<br />
<br />
===== Limiting access to SSH =====<br />
Firstly, let us check if our installation of arch linux is secure in terms of allowing external parties access to services on our server. The ''/etc/hosts.deny'' file should look like this:<br />
ALL: ALL: DENY<br />
<br />
This means that ALL hosts are DENIED ACCESS to ALL services on the system. Now, to actually allow remote hosts access to the services on our server, we should edit the counterpart of ''hosts.deny'' called ''hosts.allow''. <br />
<br />
The [[SSH#Allowing_others_in wiki |SSH]] wiki article mentions editing ''/etc/hosts.allow'' to allow outside connections to the SSH daemon.<br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0 <br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
You may not always know beforehand from what location you will be accessing your server. However, if you do know (i.e. you will be accessing your headless server from your desktop system with a fixed IP), it is wise to allow access '''only''' from these known locations.<br />
<br />
If you want more broad access to your server through SSH, from any location at any given time, you will have to allow ALL. This poses a threat, opening your SSH daemon for connections from anyone. These third parties will then be able to try and log in through means of brute force: continuously trying to log on with random user names and password combinations.<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations. There are several ways to protect yourself from brute force attacks:<br />
* Deny access to the SSH daemon throuh well configured ''hosts.deny'' and ''hosts.allow''<br />
* Use an automated script that blocks anybody trying to brute force their way in.<br />
<br />
[http://wiki.archlinux.org/index.php/DenyHosts Denyhosts] is such a script. It constantly monitors ''/var/log/auth.log'' for incorrect login attempts and disables access to SSH, for that host, after a certain amount of incorrect login attempts has been reached. I consider this a vital addition to any server offering remote access through SSH.<br />
<br />
Please refer to the [http://wiki.archlinux.org/index.php/DenyHosts Denyhosts] wikipage for proper installation and configuration on Arch Linux.<br />
<br />
===== Deny root login =====<br />
It is generally considered bad practice to allow the user '''root''' to log in over SSH: The '''root''' account will exist on nearly any linux system and grants full access to the system, once login has been acchieved. Sudo provides root rights for actions requiring these and is the more secure solution, third parties would have to find a username present on the system, the matching password and the matching password for sudo to get root rights on your system. More barries to be breached before full access to the system is reached.<br />
<br />
Configure SSH to deny remote logins with the root user by editing (as root) ''/etc/sshd/sshd_config'' and look for this section:<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
''#PermitRootLogin yes''<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
Now simply change ''#PermitRootLogin yes'' to no, uncomment the line and restart the SSH daemon:<br />
PermitRootLogin no<br />
<br />
/etc/rc.d/sshd restart<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use ''su'' - or ''sudo'' to do system administration.<br />
<br />
=== SE Linux ===<br />
<br />
{{Note | SELinux is extremely intensive and can cause big problems, I would suggest not using it unless you absolutely require it.}}<br />
Please refer to the [http://wiki.archlinux.org/index.php/SELinux SELinux] wiki page for instructions on installation and configuration, the page is only a stub, if you use SELinux you are on your own.<br />
<br />
== Administration and maintenance ==<br />
<br />
==== Accessibility ====<br />
'''SSH:'''<br />
Enabling SSH so you can remotely control your server via the command line. <br />
<br />
'''X Forwarding'''<br />
Forwarding your X session so you can login to the desktop GUI remotely (ignore this if you did not install a desktop GUI).<br />
<br />
== Extras ==<br />
<br />
=== phpMyAdmin ===<br />
"phpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement." http://www.phpmyadmin.net/home_page/index.php<br />
<br />
== More Resources ==<br />
* [[MySQL]] - Arch wiki article for MySQL<br />
* http://www.apache.org/<br />
* http://www.php.net/<br />
* http://www.mysql.com/</div>Garfiield