1--- 2stage: Enablement 3group: Distribution 4info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments 5--- 6 7# What you should know about Omnibus packages 8 9Most users install GitLab using our Omnibus packages. As a developer it can be 10good to know how the Omnibus packages differ from what you have on your laptop 11when you are coding. 12 13## Files are owned by root by default 14 15All the files in the Rails tree (`app/`, `config/`, and so on) are owned by `root` in 16Omnibus installations. This makes the installation simpler and it provides 17extra security. The Omnibus reconfigure script contains commands that give 18write access to the `git` user only where needed. 19 20For example, the `git` user is allowed to write in the `log/` directory, in 21`public/uploads`, and they are allowed to rewrite the `db/structure.sql` file. 22 23In other cases, the reconfigure script tricks GitLab into not trying to write a 24file. For instance, GitLab will generate a `.secret` file if it cannot find one 25and write it to the Rails root. In the Omnibus packages, reconfigure writes the 26`.secret` file first, so that GitLab never tries to write it. 27 28## Code, data and logs are in separate directories 29 30The Omnibus design separates code (read-only, under `/opt/gitlab`) from data 31(read/write, under `/var/opt/gitlab`) and logs (read/write, under 32`/var/log/gitlab`). To make this happen the reconfigure script sets custom 33paths where it can in GitLab configuration files, and where there are no path 34settings, it uses symlinks. 35 36For example, `config/gitlab.yml` is treated as data so that file is a symlink. 37The same goes for `public/uploads`. The `log/` directory is replaced by Omnibus 38with a symlink to `/var/log/gitlab/gitlab-rails`. 39