# web hosting server - multiple domain



## fred974 (Aug 21, 2013)

Hello everyone,

I am still trying to polish my FreeBSD skills and manged to find three volunteers to help me out. Three companies are willing to let me host their websites on my test server (as it's all free) to see how well it runs. Now my problem is that so far I only had my own website on there and now I will have four. The question is: how do you guys manage multiple domains on one server without cpanel?

The customers need the ability to access their own space and add/remove as many email as they want. I found a tool called webmin that seen to be a perfect fit but am I not sure if it's what I need as my webserver runs nginx and not the popular Apache. Also I'm not sure if webmin can deal with multiple user email. Will creating a jail for each domain be the best approach?

Any links to tutorials/howtos are also welcome.

Thank you all.


----------



## fonz (Aug 21, 2013)

fred974 said:
			
		

> Will creating a jail for each domain be the best approach?


Actually, I don't think you even _can_ run mail and/or webservers in several jails because they all need to listen on the same ports.

For webservers, you'll probably want to look into _virtual domains_ (sorry I don't know of a tutorial off the top of my head, but now that you know what to look for you can probably find one).

Major mailservers such as Sendmail can be configured to accept mail for several domains. Do make sure the MX records in DNS are set up properly, though.


----------



## fred974 (Aug 21, 2013)

Thank you very much @fonz, I'll google 'FreeBSD virtual domains' and see what I can find 

fred


----------



## SirDice (Aug 21, 2013)

fonz said:
			
		

> Actually, I don't think you even _can_ run mail and/or webservers in several jails because they all need to listen on the same ports.


It's possible, I have something like that running on my VPS. It is a bit complicated though but I have net/haproxy running on the host. It 'forwards' requests based on the Host: header to several different jails. That way I was able to run Apache and Nginx on the same host (each running inside their own jail) and only use one external IP address. I don't think you can do this for mail though.

As for the original question, I think jails would be slightly overkill for this situation. A normal virtual host configuration should suffice and it'll be a lot easier to set up than my configuration.


----------



## fonz (Aug 21, 2013)

fred974 said:
			
		

> I'll google 'FreeBSD virtual domains' and see what I can find


If I'm not mistaken Apache calls it "virtual domain" and Nginx calls it "virtual host". Just so you know.


----------



## fred974 (Aug 21, 2013)

I found a few helpful articles showing how to create "virtual hosts" but then how do I give the customer access to their files without them having full access to my server file system?


----------



## fred974 (Aug 21, 2013)

Sorry for the dumb question but what do the following three lines do?

```
# D=/websites
# NROOT=/usr/local/etc/nginx
# mkdir $D
# mkdir $NROOT/vhosts
# mkdir /var/log/nginx/
# chown root:www /var/log/nginx/
```

I got it from the following how to.


----------



## SirDice (Aug 21, 2013)

I suggest finding out the marvels of the man(1) system. 

mkdir(1) and chown(8).


----------



## chatwizrd (Aug 21, 2013)

fonz said:
			
		

> If I'm not mistaken Apache calls it "virtual domain" and Nginx calls it "virtual host". Just so you know.



I have never ever seen anything besides "virtual host" in both web servers.


----------



## fred974 (Aug 21, 2013)

SirDice said:
			
		

> I suggest finding out the marvels of the man(1) system.
> 
> mkdir(1) and chown(8).




I had nothing in the man for NROOT*.* Does 
	
	



```
D=/websites
```
 set an alias?


----------



## fonz (Aug 21, 2013)

fred974 said:
			
		

> how do I give the customer access to their files without them having full access to my server file system?


One thing you could do is to create a jail for each customer and use nullfs(5) to mount their stuff in their respective jails. On the flipside, you'll probably need to run sshd in every jail and on a different port for every jail, but I'm inclined to say that's a very minor inconvenience.


----------



## SirDice (Aug 21, 2013)

fred974 said:
			
		

> Does
> 
> 
> 
> ...


No, it sets the variable D. Which can then be used in commands, like [cmd=]echo $D[/cmd] for example.

http://www.grymoire.com/Unix/Sh.html#uh-13


----------



## fred974 (Aug 22, 2013)

Thank you @SirDice.

On my server if set an alias by typing `alias D /website` that's why it didn't make sense to me.

If I type `D=/websites` I get 

```
D=/websites: Command not found
```

It must a be a shell thing.


----------



## fred974 (Aug 22, 2013)

Has anyone use Webmin/Virtualmin? http://www.webmin.com


----------



## fonz (Aug 22, 2013)

fred974 said:
			
		

> If I type `D=/websites` I get
> 
> ```
> D=/websites: Command not found
> ...


You're probably using (t)csh. In that case, try `setenv D /websites`.


----------



## overmind (Aug 22, 2013)

If you want to offer your customers the ability to manage their subdomains, email accounts, databases you could either purchase DirectAdmin which is a lot cheaper than CPanel (and it works on FreeBSD) or use froxlor, from FreeBSD's ports which is free (froxlor is a fork of the older syscp, it works great, it is lightweight and the PHP code is clean).


----------



## ShelLuser (Aug 22, 2013)

I'm going to try and address several issues at once here.



			
				fred974 said:
			
		

> I found a few helpful articles showing how to create "virtual hosts" but then how do I give the customer access to their files without them having full access to my server file system?


Depends, I usually tell my FTP server that when people logon they should be chrooted to their home directory, from there on they can access all their own contents without wandering off. My personal favourite in this case being ftp/proftpd but others will be able to cope here as well.

As you probably noticed by now this isn't an issue of knowing your way around FreeBSD any longer. In fact, FreeBSD has little to do with all this. What's important here is finding and using the right components to set this all up (webserver, mailserver, etc.).



			
				fred974 said:
			
		

> Has anyone use Webmin/Virtualmin? http://www.webmin.com


Yes, very intensively as well. All my 5 company servers use it.

The main problem is that its main aim is focussed on Linux environments and not so much FreeBSD. It'll work, but it's by far a substitute for having some in depth understanding on how this whole thing works. In fact; because of the "Linux approach" there are several modules which simply won't run too well on FreeBSD. For example I've had my share of issues with the MySQL, log rotation, spam filtering and virus filtering modules (mainly used within Virtualmin).

I fixed the latter by simply writing a procmail script which handled filtering through clamav and SpamAssassin. Ignored the log rotation setting in its entirety and re-configured the MySQL module.

But as you can see; all of those tasks require some degree of basic understanding on how all of this stuff works. As such, although I consider sysutils/webmin a very valuable enhancement of a FreeBSD system it simply can't cope with everything.

It most certainly won't provide the same kind of "overall" solution as it does on Linux, though I'd still recommend looking into it since it can make certain things a bit easier.

*Edit*:

It can definitely provide your customers with a (safe) way to access parts of their website configuration and related assets. Even on FreeBSD.


----------



## fonz (Aug 22, 2013)

ShelLuser said:
			
		

> simply writing a procmail script



Procmail is old and crusty. Maildrop is the new, shiny version. See here.

Admittedly, I still use Procmail myself; I just wanted to be quicker than @wblock


----------



## fred974 (Aug 22, 2013)

@ShelLuser, thank you for taking the time to share your experience

@fonz I do use csh, so you were right about the syntax. reading back on the post I completely misunderstood @SireDice  Sorry about that.

Googling DirectAdmin and froxlor.

Thanks for all your input.


----------



## J65nko (Aug 22, 2013)

You should not allow your users to use ftp, that program should be outlawed  Instead teach them how to configure ftp/filezilla to use ftp over ssh, which is encrypted.

With the ChrootDirectory directive of sshd_config(5) you can chroot users to their home directory.


----------



## ShelLuser (Aug 22, 2013)

J65nko said:
			
		

> You should not allow your users to use ftp, that program should be outlawed  Instead teach them how to configure ftp/filezilla to use ftp over ssh, which is encrypted.


I disagree with that because there are several caveats to this approach. Encryption itself does not provide extra security perse. In fact, I think this approach has the potential to introduce more insecurity instead.

First of all both services have different goals. SSH is mainly used to allow access to the console ("Secure SHell") whereas FTP's main goal is to provide means to copy data back and forth. So if you have customers which maintain large(r) websites then it might be much more profitable to have them use FTP to copy their data (which, through the means of passive FTP, can also provide some parallel data transfers) than having them hogging your SSH daemon.

Which brings me to another caveat; SSH can use other means of authentication but isn't built to easily provide virtual user accounts. In general you'd allow users to logon using their system account directly. And considering the fact that users are most likely very sloppy with their credentials you're basically introducing an extra risk to your system.

Most modern FTP servers can be very easily configured to use virtual user accounts instead. So the very moment the credentials of a user are abused the damage will most likely be limited to their home directory and not so much the system itself. Abusers can try, but they'll never be able to directly logon to the system, simply because the account doesn't exist.

Well, and finally; the FTP protocol itself has supported encryption for quite some time now, and most modern FTP servers can utilize this too. You don't need SSH for that.

Personally I'd keep SSH access as far away from my customers as possible, simply because it has the potential to provide direct access to a system and you don't want that.

*Edit*: I wasn't planning to mention this at first since it could go a bit too deep, but it might still be useful information..

To be honest I even prefer not to have any password based authentication taking place altogether while accessing the SSH daemon. Because of its potential to provide direct access to a system, but also to more easily cancel out any means of brute forcing entry.

The only way to gain access to any of my systems through SSH is using keybased authentication, where the minimal key length is 1024bits. No key, no entry, no login prompt to try passwords.


----------



## storvi_net (Aug 22, 2013)

You probably can go for WebDAV as protocol, combined with the advice of SirDice using a reverse proxy.

One jail with the reverse proxy and the external IP, which redirects the requests based on the ServerName variable in the request to each jail (internal addresses).

The advantage: All based on HTTPS, it works on nearly every client, you can divide into static and dynamic content and you can scale the solution by adding webservers when needed.

Regards
Markus


----------



## J65nko (Aug 22, 2013)

ShelLuser said:
			
		

> I disagree with that because there are several caveats to this approach. Encryption itself does not provide extra security perse. In fact, I think this approach has the potential to introduce more insecurity instead.
> 
> First of all both services have different goals. SSH is mainly used to allow access to the console ("Secure SHell") whereas FTP's main goal is to provide means to copy data back and forth.


I did not want to go into details, but the purpose of my idea was never to allow console access, but only allowing the user to use sftp-server(8) in his chrooted home directory.

You set the user shell to /usr/sbin/nologin, don't put anything in his home directory and configure an appropriate Match block in sshd_config where you disallow all the forwarding connection stuff and force the command to be internal-sftp.This way the user has no console access, he can only use sftp(1). 

You can even put his public key in his .ssh/authorized_keys to allow key based authentication only


----------



## ShelLuser (Aug 22, 2013)

J65nko said:
			
		

> I did not want to go into details, but the purpose of my idea was never to allow console access, but only allowing the user to use sftp-server(8) in his chrooted home directory.


I'm aware, but that process is always run through sshd. It's also why I mentioned _potential_ security issues and not a security issue per definition.

I guess we'll have to agree to disagree; I simply don't think that allowing customers to access sshd is a good alternative for ftpd.


----------



## storvi_net (Aug 22, 2013)

You could run a separate sshd on another port just for sftp.


----------

