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 birds eye view of what is expected of you. But if you are a total beginner in this field of system administration, you should first:
Let's go through your technical options now and also a few other points you might want to consider. Shared hosting and cloud VPSSo 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.
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 your LAN, for example when building an intranet portal; the choice to self host is imperative in this case. A few points here.
GNU/Linux is the best OS for TikiIt doesn't matter the distribution as long as you have a Tux under the hood, and there is no point in even mentioning the other two major proprietary 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 of 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 firstAs soon as you get your instance installed and running, you should check the following: BackupsYes, 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):
Check the health of your TikiYou should check the health of your Tiki right after installing, but also once in a while and even more so in case of problems, 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. PermissionsPermissions 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 at least 755 for folders, 644 for files, owned by the proper web user. By the way, why do you think you are seeing in logs scans for "/test", "/dev" or brute forces for "admin" with password "123456"? Because people use them in testing, not production. The same applies to your permissions, even when testing. ResourcesFor 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 for a web server with a few other services, 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. Probably there is someone else in charge with getting the money you need for the setup, and that would be an inappropriate thing to do, transferring this burden to a sysadmin. That is saying: you should find proper resources for a job well done not try to squeeze yourself into "some" resources. And if something is critical it will cost more to keep it in good order, so everyone should treat the corresponding expenses as such. It is not uncommon nowadays to think about loosing your data in terms of: how much does our data/solution worth? 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 (ideal, triple that and combine). 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, accessible DNS services with low TTL etc). For the self hosted hardware tinkerers out there: you already know that you should have some spare parts for pretty much everything, so we thank you for being an inspiration for us all. Monitor as much as you canEverything is good and running, but we keep telling you that something bad is going to happen. How will you know?
So drop that angry sysadmin routine and remember - you are doing this for them and they can help. And if they are disgruntled, you will be too, so make them part of the team. Caches and indexesTiki already has a caching system, so if some page does not display the most recent content be sure to empty the caches https://doc.tiki.org/Clearing-Cache and as stated there, remember to empty your browser's cache too. There are also other systems that can help to speed up the delivery of your Tiki, like PHP's opcache as a minimum, or even the memcached and APC systems. Mod_pagespeed can also be an option but use with care and test properly. One of the most important features in Tiki, and wikis in general is the fast or even instant filtering and search. For this to work well on a Tiki instance we use a unified index. OK, it is a simplification, but for you as a sysadmin it is important to rebuild this index regularly, at least one per day via a cron job. Know that there are multiple options for the engine, as explained here https://doc.tiki.org/Unified-Index-Comparison Availability and uptimeA complicated subject that doesn't get the justice it deserves, as 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 the downtime is obviously the reverse. As in most cases there is no recipe for uptime; 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 so take all the precautions one can think of. But if you do, always have the best of reasons if you are the one directly responsible; or if it is an accident that will become a war story, be prepared with a save. Above anything else - investigate, have data, be honest and forth coming, so do not let the impression of a marketing department speaking. Nothing more to say here, not without staring into the abyss, as every downtime is specific to the cause that created it. Use a control panel if possibleThis is as much 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 not a very good designer, and 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. Point is - you will need to provide access and allocate resources, maybe even provide your users with a tool to manage their account. Can you set everything manually? Yes. But can you do it with the highest consistency, best segregation and also the highest speed possible? Sometimes yes, usually no. And you will end up reinventing the wheel anyways. This is where a control panel comes in handy as this specific type of software can assist both administrators and users to get the best out of their server. We don't intend to suggest here proprietary ones like Plesk or cPanel. There are a few very good and open source ones that will make your life so much easier, like Hestia, ISPConfig or Virtualmin (that we like the most). They can provide you the ability to create and delegate a domain on your server, complete with databases, DNS, email, SFTP/FTPS and others in a matter of seconds after you filled in some fields and clicked a few buttons. So give them the proper attention, we doubt even a terminal ninja is able to do that without a plethora of in-house scripts. Tiki Manager and the WikiSuite projectThe previous control panel section is also a way to introduce another two projects related to us that will make your Tiki sysadmin life much easier. Tiki Manager is a CLI tool that can assist you with creating, importing, deleting, cloning and backing up Tiki instances. It can even check their health for example. It sports a soon to be deprecated separate web interface, that we are dropping because we managed to integrate Tiki Manager as a package in Tiki, such that an instance is now able to control other instances, even on remote servers, even by creating their domains if the Virtualmin web hosting panel is involved. This brings us to... WikiSuite is an effort to build upon Virtualmin via a modified install script in order to provide you with the best setup for a Tiki server. This means that after running the script you will end up with a proper machine that is able to immediately host your Tiki instances in the best way possible. To this end we integrated Tiki Manager as a feature in Virtualmin and you can find it in your domain's left menu just like any other option. We plan to keep adding to this solution as to become a ready to go script that will a provide an organization with everything it needs. Secure everything to the point of false positivesRunning a web server facing the world it is fairly standard, though it has some hot spots, security being one of them. We see it more of a mix of separate skills, experience that will come with time and most important - best practices. Your security posture can be helped by the following:
There is a lot more, but we hope this will get you started if you want to become your very own sysadmin. Where to get helpTiki 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:
|