GUI configure virtual hosts

Support
1

NethServer Version: 7.9.2009
Module: Web Server

I’m new to this OS and am rather lost trying to configure virtual hosts for Nextcloud and SOGo. I am using the cockpit interface to complete the configuration, but I am only getting a welcome page when I attempt to access the virtual host from a browser.

I just need the hosts to point to the respective resources in /usr/share/.

Can someone please give me some pointers? I can provide whatever information is required from my system.

Thanks,
Adam.

1 Like
2

Hello adam

Root folders for website are in /var/lib/nethserver/vhosts iirc correctly. You have a link in the vhost list page to copy and use it in the terminal. Any other path needs you write yourself your vhost conf manually

3

And place the vhost conf in the root folder?

I have tested a vhost conf in one of my root folders. I had it point to Nextcloud’s file in /usr/share. Unfortunately, that conf file didn’t seem to do the trick.

Am I writing a full vhost conf in the vhost file or a directory-based installation like the one described here: https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#apache-web-server-configuration?

4

Hi @Adam_P_Strombergsson

And welcome to the NethServer Community!

AFAIK, you do not need - and should NOT use vhosts for built in Applications of NethServer!
Nextcloud creates it’s own vhost, but you MUST do it from Nextclouds configuration page in Cockpit.
AFAIK, this is valid for most included applications in NethServer. I don’t use SoGo myself, but I could imagine the same is valid for SoGo too!

And why are you trying to use an instruction from NextCloud, and not the correct, specific one from NethServer? The Nextcloud docs starts from a general installed OS, like Ubuntu, Centos or Whatever - but: a common OS, not a Server-System like Nethserver.

Using the correct docs also helps, here’s the correct one from NethServer, for Nextcloud:

https://docs.nethserver.org/en/latest/nextcloud.html

VHosts in NethServer are generally for your own pages / applications.

My 2 cents
Andy

5

Place the web app in the root folder. You can use scp or ftp for this

6

Are you sure? Adam’s asking about putting Nextcloud and Sogo in their own virtual hosts. There’s no reason to do anything at the CLI for this, nor to be messing around with anything in /var/lib/nethserver. Instead, for Nextcloud, go to Applications → Nextcloud → Settings → Configuration, and enter the desired virtual host name in the Virtual host name field.

For SOGo, go to Applications → SOGo → Settings → Advanced settings, and enter the desired FQDN in Make SOGo reachable only from this domain.

2 Likes
7

Please see my comment above. If you’ve set anything in Applications → Web Server → Virtual hosts that you intend to point to these services, delete it. Then configure those services as I describe above. You’d use the Virtual hosts page to add your own web applications, not ordinarily to point a virtual host to an application provided by Nethserver.

1 Like
8

Indeed yes.

9

Thanks everyone.

Deleting the vhosts had the intended effect. I can now access the each service via the appropriate link.

My remaining quibble is configuring https. I have the certificates registered, but they do not yet seem to be active. Are there any adjustments needed in this regard? Or just wait for the certificates to propagate?

10

In what way do you have the certs “registered”, and in what way do they not seem to be “active”?

11

I de-registered my old certificates with LetsEncrypt before wiping my Ubuntu setup. I then registered new certificates using Nethserver’s Certificates page, which was delightfully easy to do.

I am now looking to tie these certificates to Nextcloud and SOGo, respectively. Nextcloud seems easy: I just add the sub-domain to the trusted domains list in the app.

SOGo, however, doesn’t have the option re. trusted domains list. Is it as simple as providing the FQDN in the space provided?

12

Neither Nextcloud nor SOGo supports using a separate certificate for that service–they will each use the default system certificate and cannot be configured to use any other. Therefore, both FQDNs (among any others you may want to use) will need to be on the default system cert.