Re: server can't start NFS (also how to share lp0)
Derrick dman Hudson said:
> dpkg: unable to lock dpkg status database: No locks available
> W: Not using locking for nfs mounted lock file /var/lib/dpkg/lock W:
> You may want to run apt-get update to correct these problems W: Not
> using locking for nfs mounted lock file /var/cache/apt/archives/lock
> E: Sub-process /usr/bin/dpkg returned an error code (2)
This is going beyond my experiences with nfs, my best suggestion
would be to be sure that the rpc.lock service is running on both
systems, if that doesn't work, then read into how to do locking
over NFS, I've never looked into it(and never have tried to do
what your doing, yet). I have read about linux's NFS having locking
problems(NFS in general is bad with locking I hear), but this
should be workable .....wish i could help more
> This happens with and without the firewall. Maybe I should drop the
> firewall on the client machine too ...
yes i would drop the firewall on the client during rpc startups,
while i use ipchains and not netfilter i do this to filter rpcs
since the $%#@$@! things use random ports:
PORTS="`rpcinfo -p | awk '{print $4}' | grep '[0-9]'`"
for rpcport in $PORTS
do
/sbin/ipchains -A input -s 0/0 -d 0/0 $rpcport -j REJECT -p tcp -i eth0
/sbin/ipchains -A input -s 0/0 -d 0/0 $rpcport -j REJECT -p udp -i eth0
done
it works great.. i used to run nmap after everytime I started
the rpc services and manually firewall each port, got pretty
sick of that..!
>
> Checking 'rpcinfo -p 192.168.0.1' (on the client, to the server, with and
> without the server's firewall) I get this in the output
> 100021 1 udp 3345 nlockmgr
> 100021 3 udp 3345 nlockmgr
> 100021 4 udp 3345 nlockmgr
>
> Any further ideas? The firewall is at
> http://dman.ddts.net/~dman/post/FIREWALL.486
I've never used netfilter, so understanding the rules
isn't the easiest thing for me :) but from what I see
your firewall is set to default deny? since the rpc
services use seemingly random ports between ~700 and
~1024 I would add rules to allow that traffic, and
be sure lockd is running. I've just run some crude
tests, and seems on my nfs server here at home,
the nfs-common script is set to load lockd. but it
doesn't actually load it(not sure why, maybe it
loads then exits..) so check that script
/etc/init.d/nfs-common out. as for if it should
be started before or after, I would say before,
but I don't know if that is set in stone or not.
> I'll try the 'lpr' package because it is smaller than lprng. Only my
> cups system will be communicating with it, and cups will do the
> PS-><whatever> conversion. Now I need a printcap that simply feeds the
> data out /dev/lp0 (no filters or anything).
lpr should be fine, another thing you could try if your
really low on resources is rinetd.(the kernel may be able
to do this too but in my experience at least the 2.2
cannot..maybe 2.4 can), have rinetd redirect localhost tcp/515
connections to your cups lpd. the redirection part should
work, whether or not it will actually do what you want
is another story, I expect it should, but I have not
tried it. I have used rinetd to redirect a port in
one city accross an internal network/vpn to an
internal server on the other side of the country though,
I really like rinetd. I would not use it for port forwarding
SMTP traffic though, it totally screws with the logs(all
traffic looks like it is comming from the same host)
nate
Reply to: