Add-on rationale

From MineOS
Jump to: navigation, search

There are a few reasons that MineOS CRUX has add-ons, rather than simply including them in each MineOS CRUX install, or at least offering them as an option during install. First, the technical limitations:


Technical Limitations

Order of installation / password entry

A few of these addons require passwords to be both set and existing passwords to be entered, in order to install properly. One such example is PhpMyAdmin. Since installing PhpMyAdmin depends on the MySQL database--and the mysqld background daemon is not running until the first boot--it is not plausible to complete the PhpMyAdmin installation via the installation script anyway. On top of this, this database is often unused in many installations, to install this addon would force admins who don't wish to use it/know what it is to go through the MySQL securing password procedure. Keep in mind, though this is a good step to complete anyway, it is not a security threat, due to the secured iptables.

Unnecessary granting of permissions

On top of this, PhpMyAdmin would require PHP (CGI) execution on the Hiawatha webserver. Since the Hiawatha webserver has a convention for security-first, it would be irresponsible to allow CGI execution in more directories than what all admins need. Permit the absolute essentials, allow the admin to open up additional functionality.

Unnecessary opening of ports

Similarly, some addons require ports opened such as umurmur. Since it would be wasteful for every MineOS server to have the umurmur daemon running all the time, especially for those unfamiliar with the service, it is more simple to leave it up to the admin to build, install and configure it on a per-use basis. Since it must also be added to the running services array (rc.conf), it is just as well that the admin go through the complete steps from start-to-finish to fully understand the process, than to do 5% of the steps manually.

More customization

Allowing more current versions

MineOS does many things for the Linux admin that spares him or her a great deal of effort in learning and executing actions. Including many of these non-custom creations (i.e., not my Python scripts) means versioning will occur at a pace I will not care to keep up with. Instead of including version x.y of an addon such as PhpBB on the ISO, it is much easier to let the user download the few MB as needed, ensuring the most recent version straight from the developer's repository. With this model, each user can use the same steps to get their addons installed, each time with the latest version (or the version of their choice).

Architecture-agnostic scripts for architecture-specific optimization

Since MineOS aims to be as educational as it is efficient, I encourage users to build things from source, such as the php-gd library, which has limited functionality to users unless they are using PhpBB. This process takes very little time, but also ensures a recent stable version is built, as well as it is being built on each admin's respective architecture (x86 or x64), allowing optimizations to be fully wielded.

OS without-the-fat

Some addons are very specifically desired, such as eXtplorer and phpsysinfo--since many experts and many novices alike may never want to use these softwares, it is good to keep them left out, but easily added. Less files, less disk space, more secure, more control.

For these reasons (and probably others), addons are left as addons, rather than includes. If you have any ideas for something that should be made into an addon (or even an include), be sure to contact me!