These are my notes about the recently updated "Perfect" install instructions for Ubuntu v20. I hope this helps. I can expand if required. The beta doc is really good. Thanks. (I know it's mostly copy/paste from the prior doc but that was good too. ) Doc does not include notes for (optional) Metronome XMPP Server. Ref A lot of people have been confused about /etc/hosts over the years. I'm surprised the doc is not clear on this. There is a link from the Perfect doc to a page about installing a minimal Ubuntu 20.04 server. That page includes this for /etc/hosts: But to ensure that `hostname -fqdn` returns the recommended FQDN, this is required: It's not made clear in the doc (and forum posts on the topic) that the FQDN must be a real A-name, and that DNS must resolve to the server. If you cannot type (per above) server1.example.com and access the site, you won't be able to login. The cert is generated from this FQDN too, so if the server FQDN doesn't match the DNS FQDN, you're going to get an invalid cert warning. I rebooted after the first few apt-get install operations, just because... While we should not need to do this and Linux fans would take this as an insult ("what? like Windows!?") the fact is that sometimes a restart is required, and the few seconds delay doesn't hurt. Only download the ISPConfig installer to /tmp when you need it - after a reboot it might get deleted. Or, just put it somewhere else. About "/etc/apt/sources.list", there is a warning about it being a generated file, and "do not edit". So perhaps other instructions should be provided. That said, on my systems where I did a fresh Ubuntu install before ISPConfig (three so far) no change was required anyway. Trivial typo: "shown in read" should be "shown in red". About "/etc/fstab", the instruction to edit this file comes before "To enable quota, run these commands". The command to nano that file should follow that line. Still on fstab, every system will look very different. I would be very concerned about someone blindly edting in the quota detail. Or rather, the rest of the instructions are amazingly easy to follow. Someone who follows the fstab can really mess up their system, compared to all of the other copy/paste-ready commands that are flawless. I think that area needs some comments or links for more info. Because of this issue I did not enable quota (I don't need it anyway). About certs: From prior experience I know that when we enter the detail for certs, hitting the backspace key inserts a ^h rather than removing the last character. So when I type this info, I am VERY careful to get it exactly right. I think there should be a note in there about this. Would "stty erase ^h" or similar help? For anyone who uses an external firewall or security policies, ports need to be opened to access the ISPConfig installation. Please correct or confirm: 8080 : Should be restricted to IP addresses/block owned by admins 25 : Global inbound (0.0.0.0/0) 465+587 as desired by the site Anything else? About the command "openssl req -x509 -nodes -days 7300" for Pure FTPd : I used 360 days. Do recent decisions about limiting cert life apply here? I believe these are only self-signed anyway. So it shouldn't make a difference. Still about that command which includes "rsa:2048" : The certs generated from ISPConfig are 4096 bit. I think this openssl command should be modified for 4k as well. Once the site is up with the self-signed cert. Is there a designated place with instructions about how to generate a proper cert for the ISPConfig site itself? I'm going to familiarize with this environment (named ns1.mydomain.tld) for a couple days and then install a secondary server. Is there anything different in v3.2 about multiserver configurations or setting up our own DNS (as ns2.mydomain.tld) ? Thanks!
Thank you fos posting your suggestions. Metronome is not supported any more for quite a while and also recent Metronome versions will not work with ISPConfig anyway, none of the recent guides includes it for that reason.
i've not actually used 3.2 yet, just going through creating a test multiserver setup. i have already looked through the 20.04 perfect server tutorial. i do have a couple of suggestions for that. 1. rspamd. there's no mention of it. i know there's a separate tutorial for switching from amavis to rspamd. others may not know that though. i think it should be included in the perfect server guide for those looking to start new installs and planning to use rspamd right from the beginning, especially if the plan for ispconfig is to switch to rspamd as the default option going forward. should probably also include any specific changes needed for rspamd and it's management interface when the mailserver is a separate server in a multi-server setup - definitely should be in any new perfect server multi-server guide, but in the absence of any new one of those yet, it should maybe have a section in the normal perfect server guide. 2. roundcube the guide shows how to install roundcube. but nothing about installing the plugins and connecting it to the control panel. again that parts available as a separate tutorial, but again, others may not know that. To ensure newcomers to ispconfig end up with a complete working system and correctly functioning webmail, i think the roundcube plugin installation and configuration should also be part of the perfect server guide, which would hopefully cut down on the number of posts to the forums about roundcube not working, cant login, can't change email passwords etc. 3. goaccess. i can see for website stats, goaccess is now an option, alongside awstats and webalizer but there's no mention of it in the perfect server guide. installation? configuration?
I can eventually write a up to date guide on installing the plugins, which we could eventually include in the Perfect Server tutorial, since the current guides on HTF are outdated.
That's new info to this newcomer. The Ubuntu 18 installation instructions for v3.1.11 includes this. And the Ubuntu 20 info for v3.2 shows quotacheck being executed from /opt/metronome. That's certainly a copy/paste, no problem, but to the reader, maybe someone who never installed 3.1, that gives the impression that some step was missed. I'm sure you understand, none of this is intended to be critical or argumentative - it's purely intended to be constructive. I do regret that (like most projects) it seems like pointing out details like this just creates more distracting work for the primary developers. I will gladly volunteer to correct verified inaccuracies in all documentation. Thanks!
Thanks for mentioning this. I have pages from this forum about rspamd bookmarked but I haven't read them yet. My intent was to get a default server installed and then approach this as a customization later. I had no idea that it will be a new default. So your notes here are very informative and welcome.
Day 2 I created a subnet with three servers, two for DNS and one for client sites. I am the only client for now. I had to switch a lot between the old Multi-Server install docs and the latest Beta doc for 3.2. So far all three servers are communicating properly through ISPConfig. (Wow! First time! No errors! When does That ever happen?) Please don't take this the wrong way, but there is no clean documentation for a 3.2 multi-system environment. I was only able to do this because I knew when Not to rely on the docs. Please also note that I am not asking for help with these points. I'm happy to do my homework. I'm just saying the available documentation leaves these topics open for misconfiguration and subsequent requests for help. If we improve the docs then entire classes of problems might go away. Examples: Don't just copy/paste all of the apt-get install commands. Adapt to PHP7, Python3, and JailKit2.21, etc. The Multi-Server install doc does not include everything it should when it refers to the older "section 6" of the then-current v3 install doc. Be sure to update the live DNS with server names to ensure you can access systems. It's not clear if/when there will be any callback from Let's Encrypt back to a new server to issue a cert. From the ISPConfig UI there is certainly an outbound request made and a cert is returned. I/we need to research in these forums and docs to ensure systems are accessible when they need to be, even before full configuration is complete. The installation of each server type is almost identical. Just think about what each server does. If described functionality doesn't seem to belong on a specific server type, don't install it. For example, you don't need Jailkit on the DNS. The Multi-Server install doc example is great but you need to understand what it's describing. In my case I have mail, databases, DNS, and the ISPConfig master controller on the same system. So during installation using expert options, I was careful to only install the required components. That said, all systems get a database. The Multi-Server install doc refers to MySQL but MariaDB is much better. You don't even need to translate all mysql commands to mariadb - after mariadb-client and -server are installed, (almost) all mysql commands are auto-handled by MariaDB. The database situation can be very confusing. At various points we are asked to provide a user and password, and default passwords are offered. To get through this, l accepted the generated dbispconfig password. But wherever it asks for a MySQL root password, I used the same password for all systems. Then I modified the Master/DB server to accept requests from the other systems, all using the same root+password. I will be looking for better ways to handle this. T̶h̶e̶ ̶M̶u̶l̶t̶i̶-̶S̶e̶r̶v̶e̶r̶ ̶i̶n̶s̶t̶a̶l̶l̶ ̶d̶o̶c̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶t̶r̶a̶n̶s̶i̶t̶i̶o̶n̶ ̶f̶r̶o̶m̶ ̶i̶n̶s̶t̶a̶l̶l̶i̶n̶g̶ ̶t̶h̶e̶ ̶w̶e̶b̶ ̶s̶e̶r̶v̶e̶r̶ ̶t̶o̶ ̶c̶o̶m̶p̶l̶e̶t̶i̶n̶g̶ ̶t̶h̶e̶ ̶i̶n̶s̶t̶a̶l̶l̶a̶t̶i̶o̶n̶ ̶o̶f̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶s̶e̶r̶v̶e̶r̶.̶ The 3.2 installer still asks if we want to configure XMPP. Ignore that. When installing the Master system, it's tempting to answer that this system is a web server, because obviously it's serving the UI. I was afraid that if I answered no that it would not install underpinnings to allow a browser connection to the UI. I was mistaken. Only say it's a web server for systems where web sites will be generated - though it's easy after installation to toggle functionality for each system. Something else confused me and it will take time to figure this out (with forum research and maybe a new thread). When we're providing IP addresses it's not always clear which address is required - the local intranet or the public internet. So for example I found that when my first web server added itself to the master db that it used its local IP (10.0.0.x). That's easy to correct. Related, it's not always clear which server name to use, public or private. For example, my primary DNS has three names: ns1, ns1.mydomain.tld, and a petname, (like "mozart" or "jupiter"...) Following the "cattle not pets" concept, I'll eliminate the pet names so that its easy, for example, to replace ws01 with another ws01. And I'll need to look around here to learn when external names are required, like for DNS. As you see, there is a lot that someone needs to figure out beyond the available docs. I don't expect developers to educate software users, nor for every detail to be documented. What I'm saying is that the docs could be better annotated at writing time and over time, with links or notes about some details so that we can all adapt as the docs get older, or to different site-specific requirements. I'll continue later, after I have adjusted some configuration details and made the shift from my ISP DNS to my own new DNS. HTH (And now you guys see why I was asking a while back if there was any interest in a blog...) [EDIT 16-sep-20] Point #9 was invalid. The multi-server tutorial describes the first web server as being the primary ISPC controller. I initially missed that.
When we start on the "new" manual, it would be nice if you could contribute to it, either by writing/updating topics or pointing us at out of date information. We'll post about it in the dev forum for sure.
for multi-server, apart from joining a new server to an existing system during the actual ispconfig panel install, it's pretty much identical. the only real difference is adding the ispconfig@ users and relevant permissions to the master mysql instance. for points 5 & 6. yes, only install the required software on each server. although there's probably not much that won't get installed on every server. you'll most likely want virus scanning on all servers, and if you're paranoid about system changes, you'll want rkhunter installed on all servers, which will install postfix anyway, you just might not need to install or do all the dovecot/courier configuration, and not open those ports. also although bind will only be installed on dns servers, if you're using vps's you'll probably want haveged installed on them even without bind. the biggest thing not needed to be installed on every server is probably all the actual php stuff, and there's plenty of reasons why you might still want that on each server anyway. 11, you may not want the master server installed as a web server, then again, you may want some of your own/administrative/other sites, eg whmcs, your own company website, nagios/icinga etc on the same server, still managed within ispconfig, but away from any servers serving up clients sites. having it configured as a web server wouldn't hurt anything anyway, just don't assign any clients to that server. 12. generally stick with local ip's. not the public ip's and they should be included in the hosts file, avoids things breaking if there's any dns problems. plus if you're using eg, AWS, the public ip may not actually be part of the vps in any way, but part of the networking architecture in front of the actual servers. so using public ip's may not be the quickest/most direct route between servers. plus they charge more for traffic across EIP's, so using the local ip's can help keep costs down. use public ip's if the servers are on remote networks, eg most of your system is in aws and you have an ispconfig dns server on digitalocean, then you the public ip for the dns server from the aws side, and the public ip's of the aws servers from the digitalocean side. there's so many different ways an admin may want to split services out across different servers that there's no way to be specific in the multi-server install guide, all you can really do is cover the requirements for each part and then leave the admin to decide which bits they want where. you can just as easily install everything on every server, and just use the panel options and firewall to not configure/enable certain services and block access to those ports. it may use a little more ram and disk space, but not enough to cause any problems unless you have a really very small vps.
Yes, all ISPConfig servers require a local database server to which the various services (postfix, ftpd, etc.) and jobs/scripts connect to make everything function. Most slave servers do not need, and should not have, access to the database server (port 3306) open to the network, just bind mysqld to localhost addr, and additionally firewall the port and maybe even setup a fail2ban jail to catch failed logins for good measure. You can choose one or more servers to provide database service to your clients, typically for a database used by their website (eg. wordpress, as the prevalent example). It is quite common that the same server providing web service is used as a database server for those same websites, though sometimes people prefer to have a standalone database server separate from the web server. Any standalone database server needs to allow connections from the web server(s) it is used with, as well as from phpmyadmin if that is installed elsewhere. (I simply install phpmyadmin on the same webserver that clients use, and also use that as their database server, so no network access to mysql is needed.) Ideally you do not allow network access to mysql on any of your servers from the internet or other hosts on the local network; there are rare exceptions though (use a vpn and setup ssl in your mysql server). All slave servers need to be able to connect to mysql on your control panel server. They do not need to login as the mysql root user for ongoing operation, only for ISPConfig installation and updates. You should not use the same mysql root password on your slave nodes as on your master server. ISPConfig is designed to not save the master's mysql root password anywhere, so it cannot be found and abused when one of your slave servers is compromised; you enter that password interactively during ISPConfig install/update and it is subsequently forgotten. It would be even better if all servers had a different mysql root password, but if you're careful to not allow access to the database between them, and to also not inadvertently setup access to them within the mysql user table, the various slave servers could share a mysql root password without much concern. The one concern in that regard would be when you have phpmyadmin installed on multiple machines, when someone obtains the root password from one slave server, they could then login using it via phpmyadmin on another server if you don't prohibit that. So, do both - use different mysql root passwords, and configure phpmyadmin to not allow login for any root equivalent accounts. I block phpmyadmin logins from 'root', 'ispconfig' and 'debian-sys-maint' users; on the rare occasion I wish to use phpmyadmin as root, I temporarily edit /etc/phpmyadmin/config.inc.php to allow it; the rest of the time it has: Code: // Disallow login from root and ispconfig users $cfg['Servers'][$i]['AllowRoot'] = FALSE; $cfg['Servers'][$i]['AllowDeny']['order'] = 'deny,allow'; $cfg['Servers'][$i]['AllowDeny']['rules'] = array( 'deny ispconfig from all', 'deny debian-sys-maint from all', ); I do have phpmyadmin installed on our control panel node for occasional administrative use, and have restricted access to administrator ip addresses. (I use mysql cli much more often, and could easily get by without phpmyadmin.)
The detail and insight provided here is Gold. Thank you Very much. Apparently I need to tighten down the subnet and databases, and clean up some configuration, before I monkey with DNS. I'm also doing my best to search this forum for relevant posts, for issues others incurred at this stage of the onboarding process. I can see a need for a document or flow chart or even some programs, with questions about how the environment is intended to be setup, recommendations for specific configuration, and some actual tests to verify that the intended configuration is functional. For example: There might be a check to ensure that we can or cannot login as MySQL root to a slave server. There might be a check for the allow/deny rules for phpMyAdmin. There might be a dynamic checklist to look for rkhunter and clamav (or whatever the admin wants to use) to ensure the software is installed and configured as desiredin each system. Speaking of rkhunter and clamav. I didn't install these on the web server or the secondary DNS. That was an oversight. I didn't know that clamav monitors end-points and websites. I try hard not to blindly follow directions, to understand everything that I'm doing. But with a million tools we need to pick and choose those with which we have expertise or basic competence. If I were editing the docs I would have a popup tooltip over rkhunter and clamav, recommending them or similar packages for rootkit and endpoint protection. Thanks again for the ongoing support and encouragement.
ClamAV is needed only on email nodes, it is not used for websites. Rkhunter is something different, it is recommended to install it on each node.
Clamav is used by maldet, if you use that to scan websites. The signatures are definitely more geared towards email, but it finds some infections on occasion.
@Jesse Norell: I just meant from an ISPConfig setup point of view, maldet is not part of a standard ISPConfig setup.
I'm writing a new doc for the multi-server installation, of course based on the existing one. The recent notes here are of interest: Yes, ISPC only uses ClamAV for email but I'm adding it to the notes that it can be installed on all (Linux) servers, with a link to the doc that describes the file scan functionality. (Easy to remove these lines later if this is not desirable.) With respect for this and similar notes by Jesse: "Most slave servers do not need, and should not have, access to the database server (port 3306) open to the network" When we install ISPConfig on a non control-panel system, it still asks for the FQDN of the current server. If we are not exposing the server to the internet, do we really need to assign a FQDN just for this purpose? For example, the mail server needs a FQDN like mail.mypublicdomain.tld, but a database-only server in an intranet might not need to FQDN for any purpose. As another example, a web server might be hosting several sites for different domains, and there might not be a need to give it a FQDN as web01.myintranet.tld. And where ISPConfig is installed on a local secondary name server, does the primary DNS need the FQDN of the secondary? I'm thinking the FQDN is only required for extranet/internet access, and where we need to generate a cert (which actually could be on every server). So ... When do we really need a FQDN there? If the FQDN for a specific server is not necessary, might it be acceptable to simply add the host_only-name to /etc/hosts in the ISPC controller, and have that show up in the list of servers? Thanks!
I just noticed that the install doc still includes a reference to mcrypt. But the apt-get instruction does not include it anymore, and it's not even included in PHP 7.2+. So, is there a new requirement for libsodium for encryption, or is there no more need for an additional library? This would include requirements outside of ISPConfig for mail server functionality. Ref: https://serverpilot.io/docs/how-to-install-the-php-mcrypt-extension/
Yes, we do. Search about FQDN and you'll know why, especially your concern is security and encryption.
Read the most recent perfect server guides, e.g this one: https://www.howtoforge.com/tutorial...l-pureftpd-bind-postfix-doveot-and-ispconfig/ , everything that is needed package wise for the latest ISPConfig versions is described there. Do not install any other software or libs that are not mentioned in the apt commands and therefore not required, it makes no sense as they won't be used anyway. It might be that something is mentioned in the descriptive text somewhere, what matters are only the commands and if something gets not installed by the commands, then it's not needed.
just out of interest, what would you use to scan and protect websites then? would you rely solely on ispprotect? or would you use something else as well? i know (on windows desktop at least) it's generally recommended to use multiple scanners (not scanning simultaneously) as each one will likely find something that the other one missed.
