Hello everyone! Here at the Faculty of Organizational Sciences (Belgrade, Serbia) we're trying to set up Stateless Linux in order to handle and maintain several different courses at the same time.
In this case, for our first setup of Stateless Linux, we used the guidance given at http://fedoraproject.org/wiki/StatelessLinuxHOWTO. At the very beginning, we must say that we are more than willing to help you with the maintenance of Stateless linux Wiki and correction of few issues we've noticed during the initial setup process, as we've spent a lot of time and we put a great effort in managing all initial setup's specifics. At the very beginning of the setup process, one of the main requirements was to setup a subnet of two workstations of which one was used as a server, while another one we used as a client. The reason for this was, in fact, the existing main network with its own DHCP, DNS and TFTP services, so we wanted to avoid any possible interference in the future. On the other hand, our idea is to integrate this subnet into existing infrastructure in the future if something like that is possible. We've installed F7 on the server and we used only FC6 for a client and not a F7, as suggested in the StatelessLinuxHOWTO, because we couldn't access an external F7 extras mirror (we're behind a proxy server and we haven't found a way to use a proxy within anaconda) and we haven't made a local F7 mirror... But which is more important, we've noticed that the link to F7 extras repository in /var/lib/cobbler/F7-diskless.cfg points at FC6 extras repository (the correct link should be http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/i386/os/Fedora/) - F7 doesn't use FC6 repository structure - and we do not know if that's a typo or it it should be that way, as we did not test it, because of reasons given above. After server installation completed, we didn't do any system update (yum -y update). While installing the client image using anaconda, we've monitored processor load on server (using htop) and have noticed unusual utilization during execution of touch command (which also resulted in stalling the installation process). By checking those files touch was executing upon, we've confirmed that those files were changed (in other words, touch command has executed by success) but that for some reason, successful execution wasn't registered by the command. In order to let the script to finish the installation process, we killed those touch processes after some time, and everything continued with no problems whatsoever. We must say that we didn't found any meaningful or explainable reason for this odd behavior. Talking about client setup, one more thing we think it would be helpful for any newcomers - during the initrd image creation, it's important to find the exact ethernet card module name by looking at the another machine with FC6 on, that has the same ethernet card as the client you're setting up (in most ideal case, it would be nice to have an exact the same machine as the one you're setting the client on). By looking at the file /etc/modprobe.conf, one can notice a similar line: alias ethX module_name where X depends upon particular system's ethernet device. As for myserver variable, we've used specific IP address insted of server's hostname, because we weren't sure if it will resolve the way it should. Alongside with this client setup, we've used another FC6 on VMWare as another test client, which led us into situation to rebuild initrd. The very process of initrd rebuild is not sufficient, but one must execute "cobbler sync" afterwards. Occasionally, while using cobbler to add clients, it's important to write down the MAC address with ":", because in case of not doing so, script will report no errors, but while executing "cobbler sync" later on, the script won't be able to (re)start DHCP server, as specific file will not have the MAC address within. This is important to point out, because of the way pxelinux searches for possible clients, and it could lead others on a wrong track. The example of regular MAC address inscription is: 00:11:22:33:44:55 (and our BIOS reports the address without the ':'). As far as initial server and client installation is concerned, everything went just fine. While booting the client for the first time, we've encountered the same problem as Kent (by reading through Stateless Linux List archive we've found mail dated September 21st, with subject "first time setup of stateless client and server", where Kent has described exact the same problem (with one difference - he tried it with F7 and not FC6, as we did)) - after some debugging based on advices he was given, we've determined that this was caused by wrong version of fuse (which includes also versions of fuse-libs and fuse-devel), as suspected. During the initial installation, we suspect that anaconda used versions of fuse from FC6 extras, and not those given in stateless repository, because of version differences. That should be solved whether through the installer script or by pointing out that it should be done manually, after the installation is finished (one should look after all dependencies). We could write down all the commands we used in order to achieve this. One more thing - in part of the install process, where we define a persistent storage for a client, in our example, we've defined that our client is named as 'client', so the same name must be specified in the next few lines: mkdir /export/private/client echo "/export/private/client client(rw,no_root_squash,async)" >> /etc/exports service nfs restart When additional client's kernel parameters are added through tftpbot, that should be done at the end of the APPEND line in /tftpboot/pxelinux.cfg/client_MAC_address, with all letters in upper case on for CLIENTSTATE: CLIENTSTATE=server_IP_address:/export/private (in our case) because, the very rc.sysinit script will add the missing parameter - the client's hostname. CLIENTSTATE must be written in uppercase, because in opposite of doing so, that would be ignored and wouldn't be processed by the script as variable, without any warning. At the end of the same line, one must add 'selinux=0' as it seems to us that SElinux doesn't know how to handle NFS mounted root partitions. Both additional parameters (CLIENTSTATE and selinux) must be added through cobbler template, if we do not want them to be deleted by command 'cobbler sync' (set it in </var/lib/cobbler/settings>). One more thing that we also have changed is to enable client's cobbler logging on server by adding '-r' option in /etc/sysconfig/syslog file - after that, server was able to listen on port 514. We've had to open that port manually, by disabling server's firewall. Can you assist us and tell us why this is the case? Furthermore, client must be configured to log everything on server. All that was done because we've noticed that although service was listening on port 25150, nothing was logging at all trough cobbler. We've tried it, but with no success. Please, do not hesitate to ask us any question, as we would be glad to clarify things and to be of a help to anyone. We highly appreciate any further response and assistance and we hope you'll find us to be of some use. Regards, Milan Antonijevic ronin[at]fon[dot]bg[dot]ac[dot]yu Miroslav Tomic mtomic[at]fon[dot]bg[dot]ac[dot]yu
_______________________________________________ Stateless-list mailing list [email protected] http://www.redhat.com/mailman/listinfo/stateless-list
