The XS installation instructions at http://wiki.laptop.org/go/XS_Installing_Software seem to have been subject to a fair amount of confusion recently. For example, the instructions to use domain_config were deleted, and instead they advised you to modify all of the config files entering the hostname by hand.
I just had a go at fixing the page: http://wiki.laptop.org/index.php?title=XS_Installing_Software&diff=212755&oldid=212729 Please review. A few notes: The page now explicitly states the XS position on DNS - i.e. don't need to do anything because the XS does it for you. However, some people may want to use ISP dns servers. It would be nice to see instructions for such users, but the current ones were incorrect. (the way to do it would be to configure bind to send all requests to an upstream server.) I am personally confused by issues surrounding hostname resolution of the local server. Deployments will usually make up hostnames, right? In which case they don't resolve on the out-of-the-box XS setup, yes? Does ejabberd really fail if it can't resolve the hostname? In Paraguay, we modified /etc/hosts on all XSs as follows: 127.0.0.1 schoolserver.escuelaXX.caacupe.paraguayeduca.org schoolserver localhost.localdomain localhost i.e. we added the FQDN (as stated in /etc/sysconfig/hostname) to the very front of the 127.0.0.1 resolution (must be the first entry, because I couldn't find any other way to get "hostname -s" and "hostname -f" working correctly), then we added the unqualified hostname "schoolserver." If I remember correctly, this was done in order to make puppet work. Maybe these are puppet and ejabberd bugs, but it doesn't seem unreasonable for applications to require the local hostname being correctly resolvable and the hostname being correctly output by the hostname program. If someone knows this situation better than I do, please jump in and modify the wiki page. Right now I sort-of-guessed and just wrote that people should modify /etc/hosts if the upstream authoritative DNS server for the XS domain doesn't give the right answer (e.g. if the hostname/domain is made up). Finally I commented out the instructions explaining how to fix ejabberd when the user changes the hostname, because they were incorrect. The solution would be to re-run domain_config and then fix the Mnesia DBs, but I'm not sure if re-running domain_config is advisable or if a certain flag needs to be used or something. It would be nice to see these instructions return if someone is in-the-know or can experiment. Alternatively we could wait for XS_0.6 as trac suggests that this is no longer an issue. Daniel _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
