Whit Blauvelt <whit.gluster at transpect.com> wrote on 04/19/2011 12:25:13 PM: > On Tue, Apr 19, 2011 at 12:12:25PM -0500, Greg_Swift at aotx.uscourts.gov wrote: > > > So... I've a very similar configuration, and while it is strongly > > discouraged by Gluster proper, we just place the configured client files on > > the machines and do it that way. > > Wonder what the discouragement is about. With other mirroring tech, setting > up this way is recognized best practice. for a system which prides itself on > flexibility of deployment, this shouldn't be a big stretch, IMHO. By statically placing the configuration files on the clients instead of having them pull dynamically changes on the server are not readily reflected at the client level. Which is fairly legitimate. > What goes into configuring the client files? Since the ones downloaded from > the server contain names rather than IP addresses, I was hoping that simply > having the correct IPs for those names from the client's POV in the client's > /etc/hosts would resolve it correctly. But it doesn't. I've actually pulled DNS completely out of the picture on our network. I don't trust our DNS (a separate group) for something this important anymore. Changing the entries in the client's hosts machines in theory should have actually let you pull the configuration files dynamically from the servers, and is a reasonable path. I'm not sure why it didn't work. Arguably it might be better to have the valid DNS reflect what you want the clients accessing, and then hard code the static "private" networks in the /etc/hosts files on the gluster servers. With this setup you minimize the number of places where you have to configure the hosts files to a static group, and any new clients are perfectly welcome to use the standard "pull from server" mount method. I haven't tested it, but it does make sense. But then so did the one that failed on you. -greg
