On Mon, Aug 19, 2002 at 10:19:12PM -0700, nate wrote:
| 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'll have to look deeper into this sometime.
| I have read about linux's NFS having locking problems(NFS in general
| is bad with locking I hear),
Yeah, I believe the locking is unreliable because the operation is not
atomic. However, I am not really concerned with such race conditions
in this setup, I merely want apt-get to not bug out on me :-).
I found that error message in the code, and with my firewall tweaks I
managed to get past that error and on to the next one (which says it
couldn't aquire the lock).
[...]
| > 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?
It defaults to deny, but allows anything on the loopback interface and
anything from the LAN. The new firewall is at the same URL (but I
deleted the old one before I thought to run 'diff' on them; however I
printed it first so I could inspect it offline). The changes which
seem like they might be relevant are :
ACCEPT packets from 127.0.0.1 (in addition to anything on the 'lo' iface)
ACCEPT all packets in the OUTGOING chain
(I don't know that this has an effect since I pretty much did
that anyways)
ACCEPT sunrpc packets from the client in the PREROUTING chain
(this wouldn't affect starting the server, merely connecting
to it from the client)
| > 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,
It works quite well. The printcap is merely
lp:\
:ff=:\
:lp=/dev/lp0:\
:sd=/var/spool/lpd/lp:\
:sh:
| another thing you could try if your really low on resources is
| rinetd.
rinetd looks interesting, but doesn't fit my situation. It is an
IP->IP forwarder, but I need IP->parallel port forwarder. lpd is
designed to do just that.
| (the kernel may be able to do this too but in my experience at least
| the 2.2 cannot..maybe 2.4 can),
I thought 2.2 could to DNAT, but I know 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 have 2 machines -- call them "A" and "B". Machine A is a decent
system and has CUPS (which I am happy with) installed. It also has a
printer occupying the single parallel port. Machine B is extremely
low powered (8MB RAM), but has a free parallel port. The extra
printer is an old line printer, and thus needs input to be converted
to its data stream. Machine A with CUPS has plenty of power to do
that, but no parallel port to plug into. Machine B has the parallel
port, but not enough computing power. It would have been convenient
if NFS would have translated the file operations to let machine A
manage the parallel port on machine B, but it doesn't work that way.
So I installed lpd on machine B and configured it to not do any input
filtering or processing apart from queueing the job and feeding the
raw data stream out the parallel port. It works quite well, and I
don't hear any thrashing while I print :-).
Thanks for your help nate!
-D
--
(A)bort, (R)etry, (T)ake down entire network?
http://dman.ddts.net/~dman/
Attachment:
pgpP6iUlZ3bLb.pgp
Description: PGP signature