Mike Spross's questions

Forgive me if this seems like a fundamental question, but I couldn't really find anything concrete on Google, and I'm not a system administrator by trade.

We are setting up a SAN at our office using NexentaStor with an 8-disk RAID Z3 configuration (8 x 1.36 TB drives) and are in the process of configuring everything.

Right now, in terms of total disk space, we have about 10.8 TB of "real" storage on the SAN, all allocated in a single zpool/zvol. I was considering thin-provisioning the zvol with (say for the sake of argument) 100 TB of space to account for future growth.

It seems simple enough in theory: when we are close to running out of actual disk space, we just add some new drives and it will "just work": no file-system resizing or downtime to worry about.

However, how do we know when we need to add more capacity, short of logging into the SAN every few hours and making sure we still have free space left?

For example, is this normally handled by setting up a cron job, or does NexentaStor (or ZFS itself) provide warnings when you are near capacity, or is it expected that you should just "know" how much space you have left at any given time and have to keep track of it yourself?

If it helps, the 10.8 TB zvol will be used as backing storage (over iSCSI) for our virtual servers and test virtual machines (which are also thin-provisioned), so part of the problem I see is that it could be easy to run out of disk space if we are constantly creating/snapshotting/restoring VM's (which we do a lot of when testing different machine configurations and software environments).

I'm trying to resolve some funky DNS issues related to DHCP on our network (I suspect we have more than one DHCP server running at the moment), and while trying to figure that out, I noticed something strange with a new server I just set up.

The server in question is a Xen virtual machine running Ubuntu 9.10 Server. The physical Xen server is also on our network, and when I booted up the VM for the first time in Xen (I imported it from a local Virtualbox VM running on my machine, where it was running on a different network), it got a DHCP lease from our office network and everything was good.

I checked the dhclient.eth0.leases file to see what got configured, and saw that the old DHCP lease from the previous network the machine was on was still there, as well as the new DHCP lease for the office network it's currently connected to. There are two things I noticed right away:

1. The old DHCP lease information from the previous network doesn't have an options host-name line, which I take to mean the original VirtualBox version of the VM wasn't sending this option to the DHCP server. Or does this mean the old DHCP server didn't support the DHCP host name option? It was using VirualBox's internal DHCP server at the time...

2. The new DHCP lease information does have an options host-name line, which includes the correct, current hostname for the server ("fozzie"). If I understand correctly, this means the server sent it's hostname to the DHCP server on our network.

There are a number of things I don't understand about all this.

First, I did not change dhclient.conf for the server at any point; it's using the default configuration. In fact it contains the following line verbatim:

send host-name "<hostname>"

So my first question is, how in the heck did it know to send the server's real hostname if the configuration isn't set up to send it in the first place?

Second, why did the first DHCP lease (for the old network) not include option host-name, but the second DHCP lease (on the new network) did include it, if I haven't touched any of the configuration files?

All I did was export the original VirtualBox machine as an OVF, and then import it into XenServer, so how did it magically configure my hostname via DHCP if it's not even configured with the actual hostname in dhclient.conf?

Third: When I run hostname, the server returns fozzie.our.domain, but dhclient.eth0.leases says the hostname option was set to fozzie (no domain). How did it know to strip off the domain?

I've set up a dedicated Subversion server with Apache and mod_dav_svn on Ubuntu 9.10 Server, and I've got everything working fine at this point. However, I noticed that when it comes to assigning the right file permissions to the repository directory, most tutorials telll you to do something like this:

sudo chown -R www-data:www-data /svn/myrepo # make www-data the owner of the repo so Apache
                                            # can write to it
sudo chmod -R g+ws /svn/myrepo  # Give the www-data group write access as well, and enable
                                # setgid so that new directories have that group

Now, I did it a little differently. I created a new subversion group, and made that the owner of the repository, then added myself and www-data to that group, the reasoning being that this way I can edit the configuration files in /svn/myrepo/conf and the hook scripts in /svn/myrepo/hooks, and it also keeps Apache and Subversion a bit more separate from each other. I've seen other tutorials recommend something similar, but then tell you to do this:

sudo chwown -R www-data:subversion /svn/myrepo
sudo chmod -R g+ws /svn/myrepo

These same tutorials imply that you are creating the subversion group specifically to keep Subversion and Apache mostly separate from each other, so why do they turn around and make www-data the owner of the files? Is there any good reason to make www-data the owner of the repository files at all? Why not just make root the owner? It seems like keeping www-data as the owner of the repository unnecessarily ties Subversion "too much" to Apache. Is there any good reason to make the owner www-data instead of root, as long as the group is still subversion?