Greetings Rune: 


> On Mon, Apr 12, 2010 at 01:56:28AM -0700, root wrote:
>> >[root_at_sandbox2]# /tmp/coser-1.5-20090214-linux-ia32-3.bin /vice 1024
>> > `hostname -f` sandbox1.fqdn.com /tmp/update.tk 
> 
> Looks good (besides using `hostname -f` which may or may not correspond
> to the fqdn of the ip the server will listen on).

In our environment they match:
hostname -f = dns fqdn -> single ip address -> reverse DNS = dns fqdn 

>> >Fetching needed files from SCM sandbox1.fqdn.com. 
>> >
>> >Date: Mon 04/12/2010 
>> >
>> >08:24:09 Fetch failed with Permission denied
> 
> Actually I am unsure what may have happened. Some details of your
> installation differ quite certainly from what I tested with.

Perhaps, but we've redeployed using the best practices you have published.  
Hopefully our deployment is at least similar. 


> I would look into /etc/hosts and see what it says about the string you
> produced with `hostname -f` and similar things.

/etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 
localhost6.localdomain6 

# hostname -f
sandbox2.fqdn.com
# host `hostname -f`
sandbox2.fqdn.com has address 10.11.12.13
# host 10.11.12.13
13.12.11.10.in-addr.arpa domain name pointer sandbox2.DOES_NOT_MATCH. 

Could that be it? 

# ping `hostname -f` -c1
PING sandbox2.fqdn.com (10.11.12.13) 56(84) bytes of data.
64 bytes from sandbox2.DOES_NOT_MATCH (10.11.12.13): icmp_seq=1 ttl=64 
time=0.069 ms 

# ifconfig eth0|head -2
eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:55
         inet addr:10.11.12.13  Bcast:10.11.12.255  Mask:255.255.255.0 


The only dns check which doesn't pass is the rDNS IP -> FQDN lookup.  Is 
this crucial?  While the rDNS doesn't lookup to the same FQDN, it is still 
the same server, so traffic would still get to the correct server using 
either FQDN. 


>> Next, coser instructs me to do the following two things, but I'm not 100% 
>> certain of how to go about it: 
> 
>> >An entry for this host is needed in <server-directory>/db/servers
>> >on the SCM. 
>> 
>> What is the format of this file?  The current vice/db/servers file has
>> the SCM in it followed be a large number of spaces and the number '1'
>> (all on a single line).  
>> 
>> Do I just add the new non-SCM server and stick a 2 after an equal
>> number of spaces? 
> 
> This would do.
> Look for documentation. The format _is_ described somewhere,
> not i "coser" which does not include manuals.

Ok, good to know this is a correctly documented aspect of coda. 


>> >Then all servers belonging to the same realm need to be restarted,
>> >as they need to know about the new server. 
>> 
>> Which services?  I hope not the codaservice itself -- maybe just the
>> update 
> 
> All services. It is easy and mostly non-disruptive as soon as the data
> is replicated.

How do we check whether the data has been replicated for the restart? 


>> It also instructs me to update DNS.  I assume that is only after the 
>> install is completed, however. 
> 
> It will not hurt much even if done in advance but yes it is natural
> to do this when the realm is already running with the new server.

Good to know. 


> Good luck. I am not going to read the list for some time.

Hopefully someone equally knowledgable in coda will chime in during your 
absence. 


Regards,
 -Don
{void}