Re: your server doc
William Stein
<luizfelip...@gmail.com> wrote:
> Here it is.
>
> It ended up being pretty long and may be not so easy to follow.
>
> The idea of putting some of it in the notebook doc is a good one, but
> it would have to be streamlined. What I would do is to put in the doc
> only the parts that refer to the notebook setup itself, and have a
> link for the VM configuration and networking issues. This would make
> sense, since other people may want to other virtualization software,
> for example.
I think documentation based on what you're writing should be expanded
to be even longer and more helpful, and should occupy a first-class
position in the new Sphinx Sage documentation. It should likely go in
the Installation Guide, and be pointed to from the notebook?
docstring. Cross-reference is supposed to be very easy in Sphinx.
>
Comments:
* page 2: "The main reason virtualization is used in this setup is security."
You could also comment that virtualization also allows one to setup
a Sage server on almost any version of Microsoft Windows, OS X,
or Linux, and even copy the server between them.
* page 2: You might very quickly justify why one should install
VMware server instead of VMware player or VMware workstation:
(1) vmware server is free
(2) vmware server machines can be re-configured/rebooted/etc.
over the web and doesn't require any computer with a window sitting
there open. This is super important.
(3) a *drawback* to vmware server is that virtual machines
are limited to 8GB RAM.
* page 3: why do you suggest using a "Phisical [sic] drive" (note
the typo)? I've configured dozens of vmware virtual machines via
vmware server, and always use ISO images. I have never ever used a
physical drive, except for a windows virtual machine, where I had no
choice. Also, burning CD's contributes to pollution :-)
* page 3: "Infrastucture" -- spelling error
* page 3: bridged versus nat -- this should be expanded.
(1) for bridged you will have to get a new IP address from the
sysadmin of your network for the server. Then your virtual machine is
like a brand new computer on the network. This is by far the easiest
if your sysadmin will cooperate.
(2) for NAT you do *not* need a new ip address -- your virtual
machine appears on the outside to be the same machine. You can't
connect to the virtual machine from the outside unless you run some
sort of proxying and/or port forwarding. For example, you might
configure apache on your host machine to forward a certain port to the
virtual machine. This is how http://boxen.math.washington.edu:8080
works right now, using the following in /etc/apache2/httpd.conf and
appropriate modules loaded:
Listen 8080
ServerName boxen.math.washington.edu
RewriteEngine On
ProxyRequests off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<VirtualHost boxen.math.washington.edu:8080>
RewriteEngine On
ProxyPass / http://sagemath-new/
ProxyPassReverse / http://sagemath-new/
DocumentRoot /
</VirtualHost>
* page 4:
One should install at least gcc, g++, make into the virtual machine.
This is needed for using cython and for upgrading sage later.
"However, if you wish, you can compile it from source,
but this may require that you install the correct packages in the host
system." -- the correct packages are just g++ and make I think, so
this is easy. Also, this guarantees you'll be able to do "sage
-upgrade" later easily. It's good to also suggest that one install
latex, since that provides some nice tools for sage users.
* page 4: "goot [sic] point"; also " Infrastucture [sic]"
* page 6: On sagenb.org I set it up so that http://<VM address> works
*without* the :8000 bit. I did this by installing apache2 into
sagenb.org, then making this /etc/apache2/httpd.conf file:
----
ProxyRequests off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<VirtualHost *>
ServerName sagenb.org
ProxyPass / http://sagenb.org:8000/
ProxyPassReverse / http://sagenb.org:8000/
<Location />
DefaultType text/html
</Location>
</VirtualHost>
<VirtualHost *>
ServerName sagenb.com
ProxyPass / http://sagenb.com:8000/
ProxyPassReverse / http://sagenb.com:8000/
<Location />
DefaultType text/html
</Location>
</VirtualHost>
ServerName sagenb.org
-----
also, I have these modules enabled:
sage@sagenb:/etc/apache2$ ls mods-enabled/
alias.conf authz_groupfile.load cgid.conf mime.conf
proxy_balancer.load proxy.load
alias.load authz_host.load cgid.load mime.load
proxy.conf setenvif.conf
auth_basic.load authz_user.load dir.conf negotiation.conf
proxy_connect.load setenvif.load
authn_file.load autoindex.conf dir.load negotiation.load
proxy_ftp.load status.conf
authz_default.load autoindex.load env.load proxy_ajp.load
proxy_http.load status.load
---
page 6: *very* good job explaining how to setup ssh keys.
page 8: "The ulimit option must be taylored [sic] to your environment."
page 8: Regarding the secure=False option -- you might point out that
if one does that then it is pretty easy for any malicious user of the
notebook to sniff the network traffic and determine the login/password
of any other user. For a classroom setting this probably isn't an
issue. For the public sagenb.org I don't think it is much of an
issue. If somebody were setting this up say to make money (e.g., a
subscription service or to sell advertising), then secure=True would
IMHO be essential. [[I wonder what the market is like for
subscriptions to sage notebook servers??? Write me if you're
interested in discussing this.]]
* page 9: I see that you discuss NAT versus bridged in section 4. You
should point to this earlier when you first mention NAT/bridged.
* page 9: your suggestion to use guidedog looks smarter than my
suggestion to use apache above. Thanks!
* page 10: It would be cool to have something about how to limit the
server so it will only listen to a given range of IP addresses. For
example, I'm thinking of running a sage notebook server with lots of
commercial software installed into it, and for legal reasons, I can
only make it available to the UW math department. It would be good if
i could limit the ip address that are allowed to connect. This is a
standard linux configuration problem. Probably "shorewall" or
something like that is the solution.
William