Configuration
(1) Add the following in/etc/httpd/httpd.conf
Alias/nextcloud "/srv/httpd/htdocs/nextcloud/"
Options +FollowSymlinks
AllowOverride All
Dav off
SetEnv HOME "/srv/httpd/htdocs/nextcloud"
SetEnv HTTP_HOME "/srv/httpd/htdocs/nextcloud"
(2) In /etc/httpd/httpd.conf, enable mod_rewrite and PHP by uncommenting
"LoadModule rewrite_module ..." and "Include/etc/httpd/mod_php.conf",
then restart httpd.
I just installed Nextcloud on Arch and the official packages caused the most headaches I ever had within my 3 years of arch. In contrast I installed the official Jellyfin and Prometheus Server packages and they ran OOTB.
I ended up with not using the official packages but extracting the tar.bz2 into /var/www/nextcloud and slightly modifying the nginx config from their site. I had to move the inclusion of the MIME-Types file to a different block for nextcloud to deliver its CSS, SVGs and images. It wasn’t exactly straight-forward too considering permissions. I found it a beast compared to many other server software.
I mean… I would consider anywhere that you might download software from sensitive. This isn’t really a smart move. And sure, the mirror’s page they link to uses https, but if the regular site doesn’t a man-in-the-middle could change the url and serve an official looking malicious version… I wouldn’t consider putting your users at an elevated risk when it’s relatively easy to set up TLS “a smart move”.
If it hasn’t I would just assume that Slackware isn’t a big enough target and that anybody in the position to man-in-the-middle a large number of people would have better targets. I mean, to be clear TLS is not a silver bullet either, but it goes a long way for ensuring the integrity of the data you receive over the internet in addition to hiding the contents.
Distros usually sign their ISOs with PGP as well (Slackware does this), so it’s a good idea to verify those signatures as it’s a second channel that you can use to double check the validity of the ISO (but I’m not sure many people actually do this). Of course, anybody can make PGP keys so you have to find out which key is actually supposed to be signing the iso, otherwise an attacker can just make a bogus key and tell you that that’s the Slackware signing key (on the official website too, because it doesn’t use tls!). The web of trust arguably helps some (though this can be faked as well unless you actually participate in key signing parties or something), and you can hope that the Slackware public key is mirrored in several places that you trust so you can compare them… but at the end of the day for most people all trust in the distribution comes from the domain name, and if you don’t have TLS certificates you’re kind of setting up a weak foundation of trust… Maybe it will be fine because you’re not a big enough target for somebody to bother, but in this day and age it’s pretty much trivial to set up TLS certificates and that gets you a far better foundation… why take the risk? Why is it smart to unnecessarily expose your users to more risk than necessary?
My “I don’t have time for this” moment came when I tried to set up Nextcloud on Arch:
https://wiki.archlinux.org/title/Nextcloud
Meanwhile on Slackware:
Configuration (1) Add the following in /etc/httpd/httpd.conf Alias /nextcloud "/srv/httpd/htdocs/nextcloud/" Options +FollowSymlinks AllowOverride All Dav off SetEnv HOME "/srv/httpd/htdocs/nextcloud" SetEnv HTTP_HOME "/srv/httpd/htdocs/nextcloud" (2) In /etc/httpd/httpd.conf, enable mod_rewrite and PHP by uncommenting "LoadModule rewrite_module ..." and "Include /etc/httpd/mod_php.conf", then restart httpd.I just installed Nextcloud on Arch and the official packages caused the most headaches I ever had within my 3 years of arch. In contrast I installed the official Jellyfin and Prometheus Server packages and they ran OOTB.
I ended up with not using the official packages but extracting the tar.bz2 into /var/www/nextcloud and slightly modifying the nginx config from their site. I had to move the inclusion of the MIME-Types file to a different block for nextcloud to deliver its CSS, SVGs and images. It wasn’t exactly straight-forward too considering permissions. I found it a beast compared to many other server software.
ngl, I love how “I don’t give a removed” the slackware authors are, they didn’t even bother with https on their official website.
I love how their official “support” page links to a website that includes this:
https://www.steubentech.com/~talon/desktop/
lmao this is exactly the image that would pop into my head if I imagine a Slackware user in 2023.
You don’t need SSL if you’re not exchanging sensitive information.
If they aren’t exchanging sensitive information, then it’s less not giving a removed and more not using technologies ‘just because’ everyone else is.
It’s a smart move.
I mean… I would consider anywhere that you might download software from sensitive. This isn’t really a smart move. And sure, the mirror’s page they link to uses https, but if the regular site doesn’t a man-in-the-middle could change the url and serve an official looking malicious version… I wouldn’t consider putting your users at an elevated risk when it’s relatively easy to set up TLS “a smart move”.
What do you think is stopping someone from doing this?
Who says it hasn’t happened? :P
If it hasn’t I would just assume that Slackware isn’t a big enough target and that anybody in the position to man-in-the-middle a large number of people would have better targets. I mean, to be clear TLS is not a silver bullet either, but it goes a long way for ensuring the integrity of the data you receive over the internet in addition to hiding the contents.
Distros usually sign their ISOs with PGP as well (Slackware does this), so it’s a good idea to verify those signatures as it’s a second channel that you can use to double check the validity of the ISO (but I’m not sure many people actually do this). Of course, anybody can make PGP keys so you have to find out which key is actually supposed to be signing the iso, otherwise an attacker can just make a bogus key and tell you that that’s the Slackware signing key (on the official website too, because it doesn’t use tls!). The web of trust arguably helps some (though this can be faked as well unless you actually participate in key signing parties or something), and you can hope that the Slackware public key is mirrored in several places that you trust so you can compare them… but at the end of the day for most people all trust in the distribution comes from the domain name, and if you don’t have TLS certificates you’re kind of setting up a weak foundation of trust… Maybe it will be fine because you’re not a big enough target for somebody to bother, but in this day and age it’s pretty much trivial to set up TLS certificates and that gets you a far better foundation… why take the risk? Why is it smart to unnecessarily expose your users to more risk than necessary?