web hosting server - multiple domain

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.
 
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.
 
Thank you very much @fonz, I'll google 'FreeBSD virtual domains' and see what I can find :)

fred
 
Last edited by a moderator:
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.
 
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.
 
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?
 
Sorry for the dumb question but what do the following three lines do?
Code:
# 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.
 
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 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.
 
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
Code:
D=/websites: Command not found

It must a be a shell thing.
 
Last edited by a moderator:
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).
 
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.
 
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 ;)
 
Last edited by a moderator:
@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.
 
Last edited by a moderator:
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.
 
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.
 
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
 
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 ;)
 
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.
 
Back
Top