Hello,
> Excellent explanation! Thanks.
> So a cert-key combo for a user, for example, would allow you to set
> permissions, home directory etc. for that user only (and noone else on
> the VS), etc. etc.?
Yes and no. If a cert-key combo were issued to a user, then the user
would be able to connect and do user-type things, but at present that
level isn't supported. The cert/key pair relate to the freeVSD protocol
only, so its only of use in the levels defined by the protocol which
are: Host, Virtual Server and Virtual Domain. Make sense?
> And the multiple 'httpd' and 'safe_mysqld' etc. processes visible with a
> "ps -A" on the host are ones that have been executed in such a way as to
> bind them to the VS IP and give them a "chroot"ed view of the world (in
> "/home/vsd/vs/krusty" for example) by freeVSD?
Exactly.
> As an additional point, if a VS 'admin' user installed a daemon on their
> VS (in /usr/local/...) and ran it to bind to any IP address or to that
> of the host server or a different VS, what would happen? Does freeVSD
> somehow stop this?
Ah, good point. If the host server is aware of this service and it has
been virtualised (it has been configured properly in [x]inetd to run
through virtuald), then yes this may cause problems. Having just tried
it with apache, you get errors as the vs configured to bind to all IPs
fails to come up if there is another vs already running http, as it
can't bind to that address, so you're more likely to screw up your own
services that those on the other vs's. If the host server doesn't know
of the service (or it hasn't been virtualised) then there is no way to
get requests to the virtual server.
Damion.
------------------------- The freeVSD Support List --------------------------
Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support
Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support
Archives: http://freevsd.org/support/mail-archives/freevsd-support
-----------------------------------------------------------------------------
