Hello,
Ben Kennish wrote:
>
> As freeVSD progresses, I seem to be getting a little confused about
> certain aspects of it so I was wondering if anyone could clarify any of
> the following...?
>
> -----------
>
> 1) Is the "skel-repo" directory used when using a pre-built skel (as
> opposed to generating your own)? If so how?
It is used in the creation of the skel, but not after. So if your
question was: when I install/un-tar a pregenerated skel does it use the
skel-repo directory on the computer I am installing it on? The answer is
no, however, it did use the skel-repo direcotry on the machine the skel
was created on. Have I just confused matters?
> 2) How does "vsd-linkvs.pl" do its business? What happens to files on
> the VS that are not present in the skel to move from (i.e. ones created
> by the VS users since the VS was created)?
vsd-linkvs.pl, checks every file in a virtual server against the old
skel, if a file in the virtual server and the old skel are the same (and
they both exist) then the file is unlinked. If they differ, the file is
left alone (and if the file doesn't exist in the skel in the first place
its left alone). It then checks the virtual server against the new skel,
if a file exists in the new skel and not in the virtual server, then a
link is created, if the file exists in the new skel and the virtual
server, and they differ, and file called $filename.linkupdate is
created. vsd-linkvs.pl also ignores the home directory all together. So
the files created/modified by the VS owner get left alone, and any
correspoding files in the new skel get copied in to the vs with a
.linkupdate suffix, so any new configuration files etc can have the vs
owners information merged into them.
> 3) The whole CA thing is really getting confusing for me. Is the
> following true (assuming that we're not using plaintext vsd)?....
This is Tim's realm, but I shall try to explain.
> i In order to do some ISP administration on a freeVSD NS/CA/Hosting
> server (using the freevsd ssl port (1726)) the computer you're
> connecting from needs to own a valid certificate (.crt) and key file
> (.key).
Yes.
> ii Each certificate-key combination is generated by a CA which also
> has the power to revoke the combo.
Yes.
> iii As a freeVSD server (CA, DNS or host server), when someone tries
> to connect to you on the vsd secure port (to do some ISP
> administration), you check with the CA (which could be yourself or could
> be a central CA server) that the certificate-key pair that they provided
> is valid and not revoked. If this is true, you allow them to connect.
Yes.
> 4) I dont understand why you would have a cert-key pair for an entity
> other than a hosting server (e.g. for a VS , a virtual domain, a user
> etc. etc.)
Say you had customers using VSDClient to administer their virtual
servers, they will need access from outside your network. Now to allow
that customer (and only the customer) to connect to the virtual server
(and only that virtual server) you would create a certificate for their
virtual server and issue it to the client. The client then uses this
certificate to connect, and because of the type of certificate, it will
allow them to only perform operations on there virtual server, and at
the virtual server level. If you gave them a copy of the hosts cert.,
they would not only be able to administer their vs, but also the host
and any other vs's, so you need a way to limit the available options,
hence the certificate for a virtual server.
> 5) I do not clearly understand the purpose of sub-CAs. Is this CAs on a
> VS?
The sub-CAs are there so that a virtual server administrator can create
a certificate/key pair for a virtual domain to allow the domain's admin
to connect and administer the domain, otherwise the virtual server admin
would need to ask the ISP to generate a cert/key pair which isn't really
desirable.
> 6) I'd like to understand a little more about how freeVSD works. When I
> do a "ps -A" on host server when freeVSD is running, I see no "vsd"
> process or similar. How does freeVSD go about its business?
The vsd process runs on the host server only. All communication takes
place with/on the host server, and for anything that needs to be
performed in the vs, the host server chroots into the vs and executes
any necessary command. You won't see a vsd process running on the host
server either because it runs out of [x]inetd, and therefore will only
be fired up when a connection is requested.
Hope this helps, let me know if there is anything else outstanding, if
nothing else it will help us fill the holes in the documentation.
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
-----------------------------------------------------------------------------
