Thanks for replying. The briefing about the daemons is a big help. However i wasnt running nfs daemon on the client in the first place. The lock daemon was being run so i removed that and the lockd messages persisted. I traced it down to the script S25netfs which was making an nfs mount. I used the -o nolock option and now i dont get the lock messages and i can log in fine (as an ordinary user; as root it gives me bash# prompt. I am also having trouble shutting down but i am going to deal with these tommorrow ). The thing thats bothering me at this point is that when i check the /clients/node1/etc/mtab on the server i see 192.168.1.1:/clients/node1 / nfs rw 0 0 none /proc proc rw 0 0 192.168.1.1:/bin /bin nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/usr /usr nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/sbin /sbin nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/home /home nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/lib /lib nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/clients/node1/etc /etc nfs rw,nolock,addr=192.168.1.1 0 0 192.168.1.1:/clients/node1/var /var nfs rw,nolock,addr=192.168.1.1 0 0 Where as my /clients/node1/etc/fstab says 192.168.1.1:/clients/node1 / nfs default 1 1 192.168.1.1:/clients/node1/etc /etc nfs default 0 0 192.168.1.1:/clients/node1/var /var nfs default 0 0 192.168.1.1:/bin /bin nfs default 0 0 192.168.1.1:/usr /usr nfs default 0 0 192.168.1.1:/sbin /sbin nfs default 0 0 192.168.1.1:/home /home nfs default 0 0 192.168.1.1:/lib /lib nfs default 1 0 none /proc proc default 0 0 /etc/exports say /clients/node1 node1.whatever(rw,no_root_squash) /usr node1.whatever(ro,no_root_squash) /sbin node1.whatever(ro,no_root_squash) /bin node1.whatever(ro,no_root_squash) /lib node1.whatever(ro,no_root_squash) /home node1.whatever(rw,no_root_squash) So how come the mtab shows rw for all directories. Is that normal behaviour and how is it justified? (If it is expected behaviour then what is the idea behind exporting it read-only). Mehvish P.S: Thanks to all who replied ---- you wrote: > Hi! > > > Hi > > > > I am setting up a diskless client . This setup is my first > > experience with linux. So please keep that in mind while > > reading the following. I am using RH 6.2. For the client I am > > mounting only /clients/node1 and /home as read-write. > > First thing that may lead to an error (see you error-message > "httpd/error_log permission failure") > System log is written to files in /var/log/ so this directory has to > be writeable. You can do without write permissions to the log-files > if you > a) do not log the system messages (do not start syslogd and klogd) > b) send all log infos to another machine, your server. (see man > syslogd for the apropriate command line switch) > > But IMHO you can not do without write permissions to the partitions > where the files "/var/run/utmp" "/var/log/wtmp" reside. > If you do not log your system messages nothing worse happens. You > just have no hint what happened in case of failure :) > > > All files needed for booting are not > > linked to those needed by the server. > > I have checked archives concerning the following problems but > > to no avail. These are the error messages on the client console: > > > > 1) chgrp: 'utmp' is an invalid group name > > why am I getting this when my /etc/group contains utmp. > > (this occurs when chgrp tmp /var/run/utmp /var/log/wtmp is > > executed in rc.sysinit) > > > > No idea yet. > > > 2) /etc/rc.sysinit: /boot/kernel.h file or directory not > > found ( I am getting this because I am using a floppy to boot > > and there is no boot directory in the client root filesystem > > being mounted from the server. > > How crucial is this can I comment out the part that needs > > this file in rc.sysinit? ) > > > > Which section leads to this error-message? I have a feeling that this > is not crucial but only needed in case of a kernel-panic when the > "System.map" file is helping to track down the module that caused the > failure. I might be wrong. > > > 3)when rc runs the startscripts in rc3.d it gives the > > following errors: > > Starting atd: lockd: cannot monitor 192.168.1.1 > > lockd: failed to monitor 192.168.1.1 [OK] > > (but then it stops as shown by the status command which i > > used in the rc script for debugging purpose) > > > > There are two messages mixed together. Prior to the daemon "atd", the > "nfs" daemon seems to be started, immediately switching to the > background. "lockd" is part of the NFS-server package and used for > accepting locking requests for files. "atd" is a daemon used to start > programs at a special time and then logout. Unlike cron, which can be > used to manage automatic, time-driven and repeated execution over a > period of one year, atd is used for single execution of one task > within the next 24 hours. So you really do not need it. "lockd" is > only needed if you run an NFS server (silly thing on the client!). > Perhaps you have copied the whole "/etc" directory of your server to > "/clients/node1/etc" the "etc" directory for the client. Maybe you > forgot to change the configuratition to match the different IP > address of your client. Nevertheless you definitely do not need the > NFS daemon! > > > .......................... > > ............................ > > > > Starting sendmail: > > lockd: cannot monitor 192.168.1.1 > > lockd: failed to monitor 192.168.1.1 > > (btw sendmail gives status running ) > > Again "lockd" tries to start in the background, failing and printing > an error-message just as sendmail is being started!! > You definitly do not need sendmail. If you really need a > mail-transfer-agent (MTA) then install something like exim-mailer or > another small mailer-dameon that just forwards every mail to your > Server (used as mail-hub) > > > httpd runs but then gives a stream of the above lockd > > messages then i get > > NFS: cannot silly-delete .nfs[lots of digits] after xfs > > script is executed and at the same time I get the following > > on the server: > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: httpd/error_log permission failure, acc=2, error=13 > > fh_verify: var/lock permission failure, acc=13, error=13 > > The httpd daemon can not write to the log-files because /var is > mounted write-protected. I am certain yo do not need a http-daemon!! > You can not redirect the log-output of apache to another system > because it uses its own mechanism an does not rely on syslogd!! But > you can redirect the output to /dev/null > > > ( my kernel is 2.2.14-5.0 and I have read a couple of posts > > about this bug related to silly-delete but I am not sure if > > this is because of the bug or because of some lock. If it is > > a bug can you please tell me where > > to get the patch and how to install it keeping > > in mind that /clients/node1 is the root for the client. ) > > > I do not think that this is a bug. You are starting an NFS > server-daemon on the client but you do not need the daemon to mount > NFS shares. Mounting NFS shares is completly done transparently in > the kernel. So just compile in the NFS support and do not bother with > NFS userland programs!! > > > 4) X Font Server is started displays [OK] but then the status > > says xfs dead but subsys locked . > > You do not need a font server on your client. Indeed this is really > head-bangig!! Just start one font-server on your central machine (the > NFS-server) and configure your client xwindows to use this one. Now > you can centralized manage (add/remove) fonts which is the purpose of > a font-server. > > > After startscript for linuxconf is executed i get an endless stream > > of > > I looked at the start-script of linuxconf and to mee it seems that > you need linuxconf just to configure your linux-box. So You do not > need it anymore after you have successfully configured your box! > > > lockd: cannot monitor ip > > lockd: failed to monitor ip > > and thats it no login prompt either. > > > > Look at your "/etc/inittab" file. Do you have any entry like: > "1:2345:respawn:/sbin/getty 38400 tty1". If so be sure that > "/sbin/getty" can be found and executed. This is the console-frontend > to login. To use a console be sure that you included support in the > kernel-configuration. > If you want an xwindows login instead, install and make "gdm" or > "xdm" start at boot-time! > > > 5) I'd like to know which of the startup scripts do I > > absolutely have to run. > > > > First think about what you really need!! > a) Do you need to write log-files? No -> disable syslogd and klogd! > b) Do you need to execute tasks in certain time-intervalls? No -> > disable crond > c) You definitely do not need "atd" or have you ever used it before? > d) You do not need the NFS daemon for you do not have any harddisk > with partitions to share! > e) Do you really need any MTA? Yes -> do not use sendmail!! Use > program that just forwards everything to the server > So deactivate sendmail > f) You definitely do not need "gpm" for you run xwindows with its own > mouse-driver > g) You may need "lpd" if you locally run programs and want to use the > remote-printer attached to your server. If you run programs remotely > with just a local visualization then you do not need "lpd" for > printing, printing is done on the remote machine then. > h) You do not need "routed". > i) Depending on your network-configuration you may need some service > like "identd" for authentication. These services are rarely needed so > use "inetd" to run them. But comment out everything you do not > really need. No service listed in "inetd" standard-configuration is > needed to run xwindows! > j) start "xdm" or "gdm" (gdm is for gnome!) an boot-time > k) Do not start a x-font server! > l) One HTTP server is enough, so do not start one on the client. > > To deactivate a daemon use "chkconfig --del <script-name>". > > > 6) Most of these scripts invoke services for which binaries > > are in /usr/sbin or /usr/bin . A lot of howtos on the net do > > not mount /usr at all. How then are these services invoked. > > > > Perhaps they mount just the root-filesystem "/" with a whole > directory tree, which is much easier, especially if you do not have > to be too paranoid. I am using two diskless machines. I have copied > all I need, a whole directory tree, to /home/diskless/nodeX and just > mount this NFS share as a root-filesystem. This is a good way to > start with. If you get more experienced you can play around > tightening the system. > > > I have been working on the above set of problems for more > > than a week with zero progress and am quite desperate. Please > > do reply. > > > > Thanx > > > > Did you compile your kernel with direct NFS support (not as a > module)? > Did you tell the compiled kernel that the root-filesystem is on a NFS > share? > (changing the setting directly in the image with "rdev image > /dev/nfsroot" or using "root=/dev/nfsroot" as a kernel parameter) > In your "/etc/exports" file you need you use a parameter > (no_root_squash) to allow root (of your client) to act as "root" to > your exported files. So be sure you use something like > /home/diskless/node1 192.168.4.3(rw,no_root_squash) > > I had a lot of troubles before I used this parameter because without > it the server does not consider the remote (client) root to be root > on the server and denies access to some files owned by root. (like > log-files) > I did not have the time to mess around with changing file permissions > in a try-and-error manner to do without this parameter! > > Hope this helps a bit. > > Niki > ---------------------------------------------------------------- Get your free email from AltaVista at http://altavista.iname.com =========================================================================== This Mail was sent to netboot mailing list by: werewitch@whoever.com To get help about this list, send a mail with 'help' as the only string in it's body to majordomo@baghira.han.de. If you have problems with this list, send a mail to netboot-owner@baghira.han.de.
For requests or suggestions regarding this mailing list archive please write to netboot@gkminix.han.de.