Question

Installed One-Click Gitlab Droplet. Now want OwnCloud and a regular server. How?

Okay. So I installed a droplet using one-click Gitlab which did the setup for me. I made a subdomain called “gitlab.mydomain.com” which points to my Gitlab page. I then used Lets Encrypt to secure it via this guide here.

The trouble I am having now is I want to install Owncloud but apparently I dont know where Nginx is (that used by Gitlab) or even if i have to install a fresh version. I also want to install owncloud and make “owncloud.mydomain.com” point to it.

Is there a one-click for owncloud to install? (Other than running another droplet) or atleast a guide?

Also how can I make my regular domain stop pointing to Gitlab?

Thanks

Subscribe
Share

It’s best to have a separate server for Owncloud - their requirements list apache, and prefer RHEL (but you could use CentOS) -https://doc.owncloud.org/server/9.0/admin_manual/installation/system_requirements.html#recommended-setup-for-running-owncloud

Okay I should clarify more:

I have Gitlab running. Im trying to find the location of Nginx so I can install owncloud but dont know how. I tried installing Apache but Gitlab wont let it run. I want to run both gitlab and owncloud. How do I make this happen?


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

@mzbd

I agree with @BrookDO.

OwnCloud, much like GitLab, is a purpose-specific application and is designed to be ran on its own instance (Droplet/VPS, LXC Container, Docker Container, etc).

All arguments aside, only one prevails in my eyes (from a security standpoint) and that would be that when it comes to data backup, you never host backups on public servers as any successful attack on such a server could lead to such data being exposed and made available to anyone that should request it.

You can, of course, ignore that warning, in which case NGINX, by default, is going to store any and all configuration to:

/etc/nginx

And the primary configuration file would be:

/etc/nginx/nginx.conf

Near the bottom of that file, unless the server blocks are in the file above, you should see a line such as:

include /some/path

…which is normally the path to the individual files that separate the server blocks from the primary configuration file (which is the ideal way to configure each domain). You really don’t want one huge nginx.conf file as it’s hard to read and harder to troubleshoot.

@mzbd - The number of comments are limited per reply, so I’m starting a new one here.

You can find a copy of the NGINX server block that it’s referencing at the URL below. From looking at the guide, I believe it assumes that you’re working from /.

https://github.com/gitlabhq/gitlabhq/blob/master/lib/support/nginx/gitlab

You’d simply need to copy & paste that to a file in the directory it’s referencing. So in this case, you would:

nano /etc/nginx/sites-available/gitlab

Copy the server block from the URL above, paste that in to the open file and then CTRL + X, then y and hit enter. Once the file is there, the command:

sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

Is creating a symlink, or reference point for the file in the sites-enabled directory. For simplicity, I’d go ahead and do it, though in all reality, NGINX doesn’t require that you use the sites-* directories. Server blocks can be stored anywhere NGINX can read from (though they shouldn’t be stored in the users directories, i.e. public directories).

As for the home directories, personally, I prefer to use /home/ as that’s what it was intended for (it’s also the directory that GitLab is using too). This keeps NGINX configuration separate from user data entirely.