Update on SlickStack project and thanks to LET

jessuppi

Hello everyone,

It's been a few years since I posted about SlickStack:

https://lowendtalk.com/discussion/167212/slickstack-free-wordpress-lemp-install-script

TLDR: free, open source LEMP+ stack optimized for WordPress

https://github.com/littlebizzy/slickstack

Since that time, we've had quite a lot of users coming from LET to check it out, provide feedback and suggestions, and more. I wanted to say thanks to the energetic community here for all their ideas (and criticism) and also for helping SlickStack to get better and better

Here are some of the changes made since 2020:

• most of the previous LittleBizzy MU plugins are no longer installed
• much fewer files/plugins are now auto-deleted... a clearer policy has been established for file deletion which is now focused narrowly on malware, exploits, database thrashing, or conflicts with our core functionality... in other words, less opinion-based, and more security-based
• WordPress plugin blacklist can be completely disabled if desired (this is different from the file cleanup above, the blacklist simply prevents certain plugins from being installed in WP Admin, e.g. for clients)
• much cleaner/simpler file structure in our GitHub repo
• remote database servers are now 100% supported in SlickStack
• we have doubled down on not supporting any WP cache plugins or AMP, and instead leverage FastCGI caching via Nginx only, for stability
• swapfiles are now force-installed if they do not exist already
• WordPress Multisite is now supported (wildcard OpenSSL certs + Cloudflare)
• /wp-admin/install.php is now permanently blocked and all WordPress installation must be performed programmatically via the shell
• staging/dev subdomains are now quite stable, although syncing between them is still a work in progress... tools for managing this in WP Admin are being planned

• A+ security headers now default:
  https://securityheaders.com/?q=https://slickstack.io/&followRedirects=on

• junk content is now noindexed by default in SlickStack, for example /feed/ or /tag/ or /page/... URL patterns, along with certain file types like DOC, PDF, and TXT, etc.

We have also decided to not move forward with supporting Postfix or other email servers for stronger security... we assume that an email API inside WordPress is good enough for now. We also decided to not support PHP Composer or apps that require it, such as Magento.

Anyway if anyone has any questions or feedback, please feel free to comment here. Thanks!

jessuppi

A brief follow-up here, after lots of requests, SlickStack now also supports cloudflare.conf sub-module for Nginx, to enable "real visitor IPs" for sites behind Cloudflare.

https://github.com/littlebizzy/slickstack/issues/198

All you do is set this option to true during the setup wizard, and it will automatically update the list of Cloudflare IP ranges every so often in the background, no manual configuration needed.

Malin

If it were really aimed at optimization it would not be limited/built around Ubuntu only. There are other operating systems that perform way better than Ubuntu and are less bloated.

I tested it a while back and managed to get it running on Debian 11 after tweaking the install script and I can say that I was impressed, but at the same time disappointed for it being so OS dependant.

jessuppi

@Malin said:
If it were really aimed at optimization it would not be limited/built around Ubuntu only. There are other operating systems that perform way better than Ubuntu and are less bloated.

I tested it a while back and managed to get it running on Debian 11 after tweaking the install script and I can say that I was impressed, but at the same time disappointed for it being so OS dependant.

Thanks for your feedback, you bring up a great point! Since one of our main goals is portability, SlickStack should definitely aim to support more Linux distros, esp. Debian.

In fact some users are already running SlickStack on Debian from what they have said, but since I haven't had time to seriously test it, it still gives a warning during installation if Ubuntu LTS is not detected. However if anyone wants to do more in-depth testing and share feedback publicly on a GitHub Issue or something we could definitely remove that warning and "officially" support Debian, we just need a bit of community support.

Other distros are probably on the back burner for now, although I'd love to support as many as possible as time goes on... kinda depends on feedback

Our migration script is almost finished, where you can migrate your website between any Ubuntu LTS servers in just minutes, if we could make that cross-distro it would be fantastic.

Malin

The main limitation, imho, which makes it OS dependent is the installation of most of the software from packages and not compiling it from sources.

One of the bad sides of Linux is the lack of consensus and the existence of thousands of package managers which pretty much makes it impossible for developers to do something cross-platform without taking into considerations a lot of aspects and doing a lot of "if {} else {}". The only thing consistent across everything is source code compilation.

I am not a developer, but if it were me I would ditch the OS fingerprint and would look instead for a compiler, do I have a compiler and the libraries needed to compile? If yes then pull all the sources and compile. This way you solve three major problems:

1. Achieve cross-platform compatibility
2. Obtain more agile binaries which have been compiled in accordance with the specifications of the host operating system.
3. You don't have to take into consideration dependency hell which is introduced by most of the unmaintained packages.

I work a lot with FreeBSD and there are a handful of stuff you cannot find pre-packaged and even if it is for as long as I have it in the ports tree I compile it from ports.

tjn

@Malin said:
The only thing consistent across everything is source code compilation.

And Docker - ish.

Malin

@tjn said:

@Malin said:
The only thing consistent across everything is source code compilation.

And Docker - ish.

Yup, but Docker over a VPS is not always a viable solution.

emgh

@Malin said:

@tjn said:

@Malin said:
The only thing consistent across everything is source code compilation.

And Docker - ish.

Yup, but Docker over a VPS is not always a viable solution.

But a lot of times it is

EasyEngine

jessuppi

I appreciate the feedback on Docker, we have had this discussion a few times:

https://github.com/littlebizzy/slickstack/issues/127

https://slickstack.io/requirements

As a project maintainer I kinda have to read between the lines... how many devs asking about Docker would really start using SlickStack if we switched to use Docker? The answer is unclear: it seems to me that a lot of highly skilled "full stack" devs seem to casually make such (kneejerk) comments, even before trying SlickStack, but for a variety of reasons they may not actually end up using SlickStack for their WordPress websites anyways.

The same goes for supporting various Linux distros, etc... what I mean is that, by not using Docker and focusing on Ubuntu LTS and KVM, we attract more frontend devs who are a bit intimidated by sysadmin tasks and the shell but have decided to try SlickStack because of the simple approach. And that's an audience that I think has staying power...

Trying to win the respect of highly skilled Linux geeks, who treat projects as commodities and are constantly shopping around (and often maintain their own scripts too) is not really the best audience for SlickStack to cater to I think because they are not really in the business of "how do I quickly setup cloud servers for WordPress and get back to my SEO/design work" and may not participate in our community long-term.

At least, that's my impression over the past few years

emgh

@jessuppi said: how many devs asking about Docker would really start using SlickStack if we switched to use Docker?

2-3

jessuppi

And beyond that, how many devs using EasyEngine, specifically because it supports Docker, might change to use SlickStack if we started using Docker?

Not to mention the several other Dockerfiles, many from China, for LEMP stacks:

https://github.com/topics/lemp

SlickStack, EasyEngine, Roots Trellis, WordOps, Webinoly, etc all kinda have their niche. I feel like we could potentially end up losing more users, or potential users, than we gain.

emgh

@jessuppi said: And beyond that, how many devs using EasyEngine, specifically because it supports Docker, might change to use SlickStack if we started using Docker?

0-1