Updated Running a public or community server (markdown)

MartinFarrent 2012-05-24 15:21:04 -07:00
parent 183e981595
commit a9d409b45d

@ -26,18 +26,17 @@ On a public or community server, you'll need to block the use of the prefix 'www
Decide whether or not you're going to use SSL now. If you are, you need to mandate it. You can't have a public or community site that allows http and https for one reason - Internet Explorer. A considerable number of your members may be using this browser despite its questionable reputation. These people will be presented with mixed content warnings on practically every page (if there is a single non-SSL element on an SSL page, or vice-versa).
Don't use a self-signed certificate. They're very, very annoying for technical users, and a deal breaker for ordinary users. Get a free certificate from StartSSL instead. For more, see the [SSL How-To](https://github.com/friendica/friendica/wiki/Running-Friendica-with-SSL)
Don't use a self-signed certificate. They're very, very annoying for technical users, and a deal breaker for ordinary users (who are scared off by browser warnings). Get a free certificate from StartSSL instead. For more, see the [SSL How-To](https://github.com/friendica/friendica/wiki/Running-Friendica-with-SSL)
***Other tips***
***Other tools***
5. If you need a graphical control panel, use Webmin. Your webserver is going to crash, or start spewing out 504s at some point, and it's times like this that you really need to see what's going on. If you need a web based interface for this, you're screwed if you use something that relies on your webserver, but webmin runs on it's own separate (and resource minimal) webserver, so you can access it even if your site is down.
If you need a graphical control panel, use Webmin. Your webserver is going to crash, or start issuing 504s at some point, and it's times like this that you really need to see what's going on. If you need a web-based interface for this, you're in trouble if you use something that relies on your webserver. Webmin runs on it's own separate (and resource minimal) webserver, so you can access it even if your site is down.
6. Don't stick random additional software on your server. Your public/community site should share a server with a mail server (ideally - for the reasons in point 1 - Postfix) and not much else. You might, in some cases, like a jabber server too, but don't push it. Installing wikis, blogs, and other sites willy-nilly is just asking for trouble.
Don't install random additional software on your server. Your public/community site should share its VPS with a mail server to deliver notifications and registration emails (Postfix is our recommendation). There should be little to nothing else on that box. You might, in some cases, like an XMPP server too, but don't push it (chat can be resource-intensive!). Installing wikis, blogs, and other apps willy-nilly is just asking for trouble.
7. Don't use command line tools where they can be avoided. Yes, they're quicker, yes, they're often easier. But it's also much easier to typo, or use a wrong command. Even if (often precisely because!) you're copy-pasting from somebody else. You're not just messing about with your own site - many other users are depending on you too.
8. Don't use unorthodox solutions suggested by random geeks. If you read a how-to on the official wiki and it says "Click the button that says..." and somebody on the forum gives you some SQL to execute, an nginx rule, and tells you to install a proxy... then maybe, just maybe, whoever wrote the how-to is the person you should listen to.
Don't use command line tools where they can be avoided. Yes, they're quicker, and yes, they're often easier. But it's also much easier to mistype or use a wrong command - even if (often precisely because!) you're copy-pasting from somebody else. Remember: You're not just messing about with your own site - many other users are depending on you too.
Don't use unorthodox solutions suggested by random geeks. Some of them know what they're doing - but know far more than you do and are able to repair their errors quickly, too. Others are just guessing. Stick to the official documentation or to advice issued by the main developers.
***Configuration***