Re: first install notes, issues, and some solutions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello again.

We realized that we need to clarify some things about our thread.

We are gratefull for the statelles-linux project, and all the people
that contribute.

It's a great project, and we think that it could be better, or maybe
better documented.

Maybe we should divide this mail in additions to documentation, and
unresolved issues, that we need help for.

Our organization (Innovations Centre), that exists as the part of
Faculty of Organizational Sciences in Belgrade, is a RedHat certified
training partner for western Balkans (Serbia, and few other countries
in the region). We, ourselves, are Red Hat certified Technicians,
Engineers, and Instructors, and we would like to learn about the
project, and implementing it, help documenting it, and live to teach
others about it :)

As a digest of the previous (unfortunately) long post, we have two
unresolved issues: cobbler remote syslogging doesn't seem to work, and
we cannot start clients in graphical mode (logging in works ok in
runlevel 3, with startx, and CLIENTSTATE defined, and mounted).

The rest of previous mail are just some points that, in our humble
oppinion, need some clarification, or more detailed explanation.

Thanks for reading,
Milan Antonijevic    ronin[at]fon[dot]bg[dot]ac[dot]yu
Miroslav Tomic        mtomic[at]fon[dot]bg[dot]ac[dot]yu

On 10/9/07, Milan Antonijevic <ronin@xxxxxxxxxxxx> wrote:
> 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
>

-- 
Milan Antonijevic
mailto: ronin@xxxxxxxxxxxx
mob/cell: +381638904862
- saradnik - / RHCT
Inovacioni  Centar - http://www.ic.fon.bg.ac.yu/
Fakultet Organizacionih Nauka - http://www.fon.bg.ac.yu/

_______________________________________________
Stateless-list mailing list
Stateless-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/stateless-list

[Index of Archives]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux