I want to share some thoughts on the necessity or lack thereof of a control panel for a commercial single-server web project with a very part-time admin. The story began a couple of years ago when acquaintances asked me to assist with the technical side of buying a business—a news website. I needed to understand how everything worked, ensure that all necessary details were transferred correctly and completely, and strategically think about what could be improved.
The deal was made, and the violinist was no longer needed. The end. Actually, no.
The site was running on a dual-core 4GB VM on Linode, with some outdated Debian 5 and an uptime of about 400 days, along with a long list of unupdated packages. The web part was on a custom CMS, using nginx, PHP 5.3 FPM, and a MySQL optimized with Percona. In principle, it worked.
At the same time, while talking to me, the new owner was looking for a programmer to align the project with expectations. He found one. The programmer assessed the traffic and volumes and decided that he was skilled in optimization and cost management. He migrated the entire site to a 700-ruble shared hosting managed by a familiar IS****er. A few days later, I got a call from the owner: "Everything is lagging, and it seems we’ve been hacked." I tried to fix the situation through the panel, but after some futile attempts to change the PHP version or handler from fcgi to fpm, I gave up and accessed the shell. There I found debug mode enabled, which exposed the MySQL password to the internet, 777 permissions on some folders that were by then cracking from uploaded malware, and similar nonsense. The owner realized that saving on hosting, programming, and an admin who would keep an eye on things was a mistake.
We're moving to RuVDS. A bit closer than British Linode, and if you ever want to store personal data and all that, you won't have to move anywhere else. Since we planned to expand the project, we took a VM that's 'future-proof': 4 cores, 8 GB of RAM, 80 GB of disk space. It's not that I can't configure nginx manually; it's just that I didn't have the enthusiasm to engage with this project so intimately (see above about part-time). So, I installed Plesk (I'll skip the installation details since there aren't many: ran the installer, set an admin password, entered the key – done), at that time it was version 17.0. Basic settings work reasonably well out of the box, with fail2ban and the latest available versions of PHP and nginx.
It's probably worth pausing to explain why I chose this. Since I don't often work on these things, and I don't have any special tools or templates for every situation, it was clear that I needed some automation of basic tasks to be fast, secure, and ensure that someone had already implemented all the best practices.
So, I installed it. I saved quite a bit of time; the website restart on the new server was practically instantaneous. I just needed to tweak the MySQL config, allocating half the memory and increasing the number of buffer pools, and assign half of the cores to nginx (Plesk doesn't touch the global configs), and over a couple of days, I checked the shell for stats from mysqltuner. Oh, and I bought the paid ImunifyAV from the extensions catalog to get rid of the uploaded malware. There were about 11,000 infected files found. The nasty part was that obfuscated pieces of code were injected into the static files, and cleaning this up manually would have been a real drag. At first, I tried ClamAV, but it turned out it doesn't handle such things, while ImunifyAV did. Moreover, the cleaned files remain functional; only the piece with the malware gets removed.
The math is simple: $50 a month for the VM, $10 for Plesk (actually less, because we bought a one-year subscription with a two-month discount), and $3 for the antivirus. Or a lot of cash for my time, which I would have spent on the server initially cleaning up this mess manually. The owner was quite satisfied with this arrangement.
Meanwhile, we found a new programmer. We agreed with him on the distribution of responsibilities, created a subdomain for the test version, and work began. He was developing a new version of the site on Laravel while I kept an eye on fail2ban.
Interestingly, the flow of curious onlookers never stops, and there are always about a hundred addresses in the banned list. The effect is interesting: for instance, typically, when I enter the shell, I see about 20,000-30,000 failed SSH login attempts in the welcome message. With fail2ban enabled, there are about 70. Effort invested: 0. Unfortunately, there was a bit of a catch, as the WAF (modsecurity) was by default 'semi-enabled': in detection mode. This meant it only logged suspicious activity, but did not take any actual actions. Meanwhile, fail2ban indiscriminately read all logs according to the active jails and blocked everything that moved. As a result, we banned half of the editorial team :D. We had to disable that jail and whitelist the necessary IP addresses for reliability. Effort invested: just clicking twice with the mouse and teaching the editors to provide their IP addresses.
What the programmer immediately liked was the ability to upload databases directly in the panel and quick access to phpMyAdmin.
What I liked were the logs and backups. The logs are generated and rotated automatically; backups are very easy to configure. During the slowest periods, a full backup is created, around 10 gigabytes, followed by an incremental backup of about 200 megabytes daily for a week. Restoration is granular, down to a specific file or database. If a restoration from an incremental backup is needed, there's no hassle with starting from the full backup and restoring the entire chain; Plesk handles everything automatically. Backups can be uploaded anywhere: via FTP, to Dropbox, S3 buckets, Google Drive, and more.
Day X: the programmer finally completed the new engine, we deployed it to production, imported the old data, and sat down to choose the color of our future Maseratis. We are still choosing.
We encountered the first problems. The new site was predictably heavier than the old one, but the real issue was that we were using Yandex.Zen among other sources to attract traffic, which brought in visitors in droves. The site struggled with 150 simultaneous connections (I'm not talking about RPS because we didn't measure it). We started pressing buttons and tweaking settings in the php_fpm area.
Oh, it's already holding 500 connections. As we applied the credit card to the promotion funds, the waves of traffic grew larger. The next milestone is 1000 simultaneous connections. Here, we had to refine the code and take a close look at the muscle. Plesk didn't help with this, but we didn't really expect it. We enabled the slow queries log, added indexes to the database, removed unnecessary queries from the code, and brushed up the MySQL config again based on mysqltuner's recommendations.
The new challenge is 2000 connections. Just in time, the Plesk 17.8 version was released, which added nginx caching, among other things. We updated (surprisingly easily). Let's give it a try. It works! And then we hit a snag: the Yandex.Zen feed stopped working. The site works, but the feed doesn't. No feed means no traffic. Tension is rising. Under pressure and lacking imagination, I immediately started stracing nginx and found what was wrong. It turns out, at some point, the silly nginx cached a 500 error response for the Yandex get feed.xml request. We fixed it by adding exceptions to the cache settings:
Naturally, the owner needs MORE, and the waves are gradually increasing. We're managing for now, but we started experimenting with memcached in advance, as Laravel supports it almost out of the box. Installing memcached manually for 'testing' didn't seem appealing, so we set up a Docker image right from the panel.
Well, I admit I had to go into the shell and install the module via pecl. Right according to . I can't say much about bandwidth growth yet, as there haven't been any significant spikes. The site's engine connected to localhost:11211, stats are showing, memory is being used. If this works well, we'll see what to do next. Either we leave it as is or install a 'real' one directly in the system. Alternatively, we might try redis in the same way.
Then we needed to add email distribution. No relays, just SMTP authentication. We set up an email address and using its details, we do the distribution through PHP.
Not long ago, Plesk Obsidian (18.0) was released, and based on previous experience, we updated without fear. Everything went very smoothly; there's even nothing to report. On the pleasant side, the interface quality has significantly improved, it modernized and became more user-friendly in some places. The Advanced Monitoring feature on Grafana is a cool thing.
I haven’t delved into it deeply yet, but for example, you can set up alerts for any parameter to email. To the owner, lol.
Since I'm talking about the interface, it's adaptive and works quite well on phones. In the early stages, while we were trying to find the optimal PHP settings and everything else, it really helped us out. Especially when the programmer, in a fit of work enthusiasm, does something at 11 PM, and I, in a similar fit of enthusiasm, am drinking vodka in the bath, and urgently need to switch something.
Oh, by the way. The image shows that PHP Composer has appeared. We haven't played with it yet, but, let's say, for Laravel, it can save a couple of logins in the shell and some time on dependency installation. There's a similar system for Node.js and Ruby.
SSL is straightforward. If the domain resolves where it should, Let’s Encrypt can be set up with one click and updates itself further, both for the domain and for subdomains, and even for mail services.
The Plesk software is quite pleasant and stable at the moment. It updates itself and the OS quietly, consumes few resources, and works smoothly. I can't even remember encountering any obvious product defects. There were issues, of course, but they were either due to configuration imperfections or somewhere at the interface, so there's nothing to complain about. Overall, my impressions of working with Plesk are positive. What it lacks, and it's important to understand, is any kind of (any) clustering. Neither LB nor HA. It can be attempted, but the efforts required would be so significant that it's better to approach it differently initially.
I think we can summarize. In scenarios where there is either no admin or very little, when the cost of hosting and the websites running on it exceeds, say, 100 units, when we aren't talking about some cattle shed with 1500 sites on a server, and when the decision-maker has to choose between hiring a part-time admin or buying software and bringing in an admin at 'half a cracker,' or not hiring at all — there's definitely a point. From the perspective of a remote admin — the same. $10 a month saves time and adds flexibility to work at a much larger scale. For instance, if someone strongly asks me to take a similar project under my wing, I'll insist on moving it to Plesk.higher level of isolation, as if one controller is broken, the problem is confined to that specific context).Wine 5.0 has been released.
Source: habr.com
