What is required to run a Tiki? First of all, a person.

Congratulations and thanks for your interest in Tiki Wiki CMS Groupware. We hope Tiki will meet your needs for a highly configurable web platform. If there is anything we can do to help, be sure to let us know.

The requirements page is quite explicit about what you need in order to run a Tiki instance https://doc.tiki.org/Requirements . So we hope that any system administrator will be able to find a proper environment to run Tiki. It really isn't much to it, at its core Tiki is (very) simply put a PHP website, so it will happily run where your other web applications run. This being said, administrating a server for Tiki or other web applications is a job in itself. We will try to provide here a birdseye view of what is expected of you. But first of all if you are a total beginner in this field of system administration, you should first:

• take the time to learn a bit about the different web hosting technologies;
• try to mimic certain recipes available online, though you should in time always make your own decisions and come with your personal way of providing a Tiki to users;
• have patience but also have a bit of courage, this means having the inner desire to perfect your skills is an advantage, but always with an eye on the future, always eager to try new things. Passion helps here, a lot;
• be ready to become a tougher individual, ready to deal with the 24/7 stress of running any service others depend upon, more so with all the bad stuff happening online. This is no joke, you should expect problems, in fact problems will become your very job: either from your software/hardware stack, by your own hand or your users, and also via the armies of crackers (not hackers, please learn the difference) just waiting for you to have something, anything online. Down to your electricity and internet providers, whom will become your archenemies if building your own infrastructure;
• get in shape to build trust around you. A sysadmin that doesn't have a good moral compass is a danger to himself and others. Knowledgeable admins can be easily found. Trustworthy ones, at a level that people will hand over to you their personal info, sensible files, their family's well being and even the future of their company - that kind of person is more rare.

Let's go through your technical options now and also a few other points you might want to consider.

Shared hosting and cloud VPS

So where to host? The popular option is to either use a shared environment as the go to "pay and play" or rent a VPS, from a provider.

• In the first case you will not have to deal with the intricacies of having to set up a whole server, and everything is ready for you at the smallest price compared to the other options. Usually, just don't pick the cheapest offer out there, because it will have hidden costs in the terms of functionality, resources and availability. Simply research your provider, get the most for your money, and just try it out as there is not much administration involved. And it is standard to be able to scale your resources, so you can easily increase them if needed.
• Only in the second case, you will elevate yourself to a true sysadmin as it will be required of you to set up a server for your services in a virtual machine provided by a third party. This is a good option if you or your organization, don't have the resources, you aren't interested in running you own servers, or you just need to test your hand. Keep in mind this option is feasible only in the basic to mid tiers - prices will climb up quickly if you need more resources. This is the point where you should calculate how much will it cost you in the long run.

Roll your own. Containerized, virtualized or bare metal?

If your organization already owns the infrastructure or they intend to build one, you are not alone. In the cloud era, there is also a resurgence of the need to own your data, for privacy reasons mainly but also costs, if you have needs exceeding what is offered by subscriptions for some cloud VPS instances or even renting physical servers. There is also the case when you need a Tiki instance strictly in you LAN, for example when building an intranet portal; the choice to self host is imperative in this case. A few points here.

• Members of our team are making good use of container technologies like docker and podman, but mainly for developing and testing; it is not something we see often in production. It can be used just fine but in our experience the organizations are using containers for Tikis less often than the next two scenarios.
• Virtualization is the the preferred option for setting an internal but also a public facing Tiki. Popular virtualization technologies like KVM and Xen, or commercial solutions like VMware have no problem with a common web server + php and some SQL databases in a VM. And of course they are ubiquitous in modern corporate IT landscapes, so it makes sense to use your existing infrastructure. We urge admins to build their solutions using virtualization if they didn't already, for security via segregation, ease of restoration and consolidation purposes to say the least.
• Running on physical hardware is required when no virtualization is in place because you might have older servers that do not worth the effort or they do not have the proper CPU instructions sets. Or when you plan for a monster of a Tiki that really needs all the resources and the lowest latencies possible. This is a return to the old mantra, and you know what to do if you aim that big.

GNU/Linux is the best OS for Tiki

It doesn't matter the distribution as long as you have a Tux under the hood, and there is no point in even mentioning the two major commercial operating systems that have a bigger (desktop only) market share. Tiki builds on the same freedoms and philosophy with this family of operating systems, being in fact one the many technologies they spawned. We don't see any problems if you want to host your services on a rolling distro like Arch or Tumbleweed, bleeding edge ones like Fedora or the distros for purists, like Trisquel.

Though in production the general consensus is that you should opt for "stability" as in a slower paced, maybe sporting LTS versions, with mature packages like Debian, derivatives like Ubuntu, RHEL or rebuilds like Rocky Linux or AlmaLinux. You can't go wrong with any distribution when running Tiki, so it is up to you which one you choose, depending on other considerations and even personal views.

Here you can find comprehensive information about installing a Tiki instance in different environments https://doc.tiki.org/Tiki-Installation-Guide

First things first

As soon as you get your instance installed and running, you should check the following:

Backups

Yes, please start with backups. Weird thing to say to a system administrator, but everyone needs a reminder that losing data is not acceptable, at least not all the data. As soon as you manage to have a Tiki running or anything for that matter on a new server, you should start with making some backup decisions and put some automation in place from day one. Sooner or later this will spare you a lot of grief and it is only a matter of time before something happens, so it is not a question of "if" but a question of "when". Here is some info about what you need to do at a minimum https://doc.tiki.org/Backup which means having a database dump and your files copied somewhere else.

So think about your backup philosophy (if you don't have one, make it up right now):
- what are your Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?
- respect the golden 3-2-1 rule: have at least 3 copies of data, on 2 different media, 1 copy being off site; it is acceptable that one of those might be the production data itself;
- more planning: how much space do you need for backups, where to host them, how long it will take to create a backup but also transfer it via the network or the internet, and what exactly happens if the backup does not succeed?
- full vs. incremental backups; as a rule try to have as many full backups as you can; and please do not forget about encryption fi you don't trust the environment;
- review you settings and test the backups later, if possible regularly, despite being a tedious work.

Check the health of your Tiki

You should check right after installing, but also once in a while and even more so in case of problems the health of your Tiki, via the Tools > Server Check option in your Tiki's control panel. The usual culprits will be clearly presented and explained, with meaningful hints. Great tool, you should use it.

Permissions

Permissions issues are not common encounters in shared hosting as you don't manage much, your host does, and so it is their job to keep them in good order. But they do happen when you are in charge. Their effects can be quite noticeable in any deployment starting from weird Tiki behavior, explicit errors in control panels or pages and ending with a complete website crash. Though when you get them right, there is nothing more to it.

So problems rise due to user errors, a misbehaving script or inappropriate defaults in the OS/specific software servers. Never use full 777 permissions for anything and never run anything web as root, not even when testing as you will learn the very wrong lesson that they are a quick fix. Use 755 for folders, 644 for files, owned by the proper web user.

Resources

For sysadmins it is a good idea to first over provision and second to have an alternative, a different environment. You should never get 2 cores if that is the bare minimum a web server with a bunch of other services will need, as you should never try to get away with 2GB of RAM or 50% more of your current storage needs. Remember, in the long run requirements will always go up, and the moment resources will count the most is when... you need them or you have problems and you don't have them; more so, you may invite downtime and other sorts of issues when trying to resize or add disks/partitions, RAM or cores.

We are not recommending wasting money here, but remember, if you are cheap that is exactly what you will get and in an organization it is not your job to complain about the IT budget being big, but rather to get what you need for your job. That is saying: you should find proper resources for a job well done not try to squeeze yourself into resources. And if something is critical it will cost more to keep it in good order, so everyone should treat the corresponding expanses as such. It is not uncommon nowadays to think about loosing your data in terms of: how much does our data cost? Well... as much as the company itself, even more if you affect other parties.

We were mentioning you should also have an escape route in case of problems, being a second server, a second VM, a second shared hosting account (best, a combination of those. This means identifying and getting resources proactively for when the main environment will go down. Because it will just go down at some point. Hybridization is good here: for example if you have a local physical server, you should also buy a VM in the cloud (or at least become very fast to get it and set up one, ie all decisions taken, scalability in mind, have some reserve money).

For the hardware tinkerers out there: you already know that you should have some spare parts for pretty much everything.

Monitor as much as you can

Everything is good and running, but we keep telling that something bad is going to happen. How will you now?

First, you should set-up some external monitoring, because you will need to know if something goes down and local monitoring does not help: for example if you server will crash, it will take down the email service, and such it will not be able to alert you. This can be a simple script that just pings or curls machines and services, free or paid external monitoring services that check your uptime, or even starting a dedicated machine that will check for problems, with tools like Zabbix, Nagios etc. This is for the complete loss of connectivity to the server.

Second some local monitoring is a must. Maybe you will have only a couple of services go down, some performance issues, software bugs etc. Local tools like Netdata will be invaluable, and if those can alert you it will be great.

Third, the users are a sensor net themselves. Obviously people will try to contact you if services are down. So keep paying attention to what they are saying, learn to communicate with them in layman's terms, and also identify some quick checks that might help you understand things, from their side, from their perspective. Most of the times these alerts are local issues, misunderstandings and such. But you should check each and every one of their claims, and encourage them to keep reporting but somehow properly, more tuned. You will be amazed how much value an educated user can bring you when he already reports his external IP address, gives you the proper link, and they already checked themselves against the blacklists.

If they are angry, you will be angry. So drop that angry sysadmin routine and remember - you are doing this for them.

Caches and indexes

Availability and uptime

A complicated subject that doesn't get the justice it deserves, the availability of your services will define you and your work as a sysadmin. Being always on is hard and nothing can substitute experience here. Ignoring the previous advises will not do you any good, as the uptime of your services is the sum of everything you do and as in most cases there is no recipe here; so in order to get there just make it your everyday objective.

Preventing IT hardware and workloads to go down is done via a simple rule: just do not go down and take all the precautions one can think of. But if you do, always have the best of reasons if you did it yourself, or if it is an accident that will become a war story, be prepared with an alternative. Nothing more to say here, as every downtime is specific to the cause that created it.

Use a control panel if possible

This as much as about productivity and automation, as it is about usability for you and a few privileged users that for example need access to the root of their website. If you are a sysadmin, than probably you are to a lesser degree a developer, and in an organization you will surely have colleagues or third parties that will need access to your server. Can you set everything manually? Yes. But can you do it with the highest consistency, best segregations and also the highest speed possible? Sometimes yes, usually no.

This is where a control panel comes handy as they assist both administrators and users to get the best out of their server.

Tiki Manager and the WikiSuite project

The control panel part is also a way to introduce another two project related to Tiki.

Secure everything to the point of false positives.

Where to get help

Tiki is a bit complex, with many features and preference options, and some things may be done differently than in other similar software, so familiarization may take some time. Please visit the documentation site for details on feature use, etc. Also make use of the sources of help listed on Get Help, in particular:

• Ask questions in the forums or in the Matrix chat.
• Get involved in the Tiki community.
• Please feel free to participate in our monthly roundtable meetings.