Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
reopen 620421 thanks Hello, On Sun, 03 Apr 2011 05:29:12 +0100 Ben Hutchings b...@decadent.org.uk wrote: I'm describing (actually, repeating) what was in the initial bug report for that test, modulo my misunderstanding about Bash's special treatment of that path. The initial bug report contained the output from the upgrade and the init script. The init script redirects errors from the test command to /dev/null because the error message is not expected to be meaningful in context. That's why I asked to run the test command directly. I confirm the bug. # cat /dev/null /dev/tcp/localhost/111 -su: /dev/tcp/localhost/111: No such file or directory -- WBR, Andrew signature.asc Description: PGP signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Wed, Apr 13, 2011 at 10:36:04PM +0300, Andrew O. Shadoura wrote: reopen 620421 thanks Hello, On Sun, 03 Apr 2011 05:29:12 +0100 Ben Hutchings b...@decadent.org.uk wrote: I'm describing (actually, repeating) what was in the initial bug report for that test, modulo my misunderstanding about Bash's special treatment of that path. The initial bug report contained the output from the upgrade and the init script. The init script redirects errors from the test command to /dev/null because the error message is not expected to be meaningful in context. That's why I asked to run the test command directly. I confirm the bug. # cat /dev/null /dev/tcp/localhost/111 -su: /dev/tcp/localhost/111: No such file or directory Let me guess, you're using bash from 'lenny'? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 10:12 PM, Andrew O. Shadoura wrote:
Hello,
On Wed, 13 Apr 2011 22:04:54 +0200
Luk Claes l...@debian.org wrote:
I confirm the bug.
# cat /dev/null /dev/tcp/localhost/111
-su: /dev/tcp/localhost/111: No such file or directory
Unless you show that you:
1) have bash 4.1-3 or later installed ('apt-cache policy bash' for
instance) 2) are using bash as shell ('exec bash' for instance)
3) sunrpc service is running ('lsof -i :111' for instance)
4) still have this issue
It's going to stay closed as only in that case it's supposed to work.
If it's the only case, it should be specified explicitly. And, after
all, why not use the utility that is supposed to be used, and not this
hackish thing?
The only reason it was implemented this way is because bash is still
essential and so does not need a dependency.
Also, there's no way to get a newer bash unless I install it by hand.
This system isn't lenny any more, but nothing has upgraded it yet by
means of dependencies.
Well, we only guarantee to support upgrades from stable to the next one.
Obviously we will try to not break things in unstable and testing.
Though it's not uncommon to make the assumption that users have at least
upgraded to stable before doing partial upgrades to unstable/testing
versions.
Anyway, using a really old packaged bash, a newly packaged bash or a
self compiled bash (even the version in lenny) should all work for this
/dev/tcp use. It can also be replaced by 'lsof -i :111' or something
netcat like, though for both these you need to make sure you have lsof
or netcat installed.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
Hello, On Wed, 13 Apr 2011 22:28:54 +0200 Luk Claes l...@debian.org wrote: If it's the only case, it should be specified explicitly. And, after all, why not use the utility that is supposed to be used, and not this hackish thing? The only reason it was implemented this way is because bash is still essential and so does not need a dependency. So you prefer not to specify dependencies at all and break the install than to specify the dependency explicitly? I don't grok this, sorry :( Also, there's no way to get a newer bash unless I install it by hand. This system isn't lenny any more, but nothing has upgraded it yet by means of dependencies. Well, we only guarantee to support upgrades from stable to the next one. Obviously we will try to not break things in unstable and testing. Though it's not uncommon to make the assumption that users have at least upgraded to stable before doing partial upgrades to unstable/testing versions. This machine is (obviously) a server. I can't 'just upgrade' it to the stable at once, so I do partial upgrades. Dist-upgrade is no go at this moment. So in my attempt to get NFS over IPv6 working I got broken NFS at all :( Anyway, using a really old packaged bash, a newly packaged bash or a self compiled bash (even the version in lenny) should all work for this /dev/tcp use. It's bash 3.2-4 from lenny, it's not so old. And it doesn't have /dev/tcp support. It can also be replaced by 'lsof -i :111' or something netcat like, though for both these you need to make sure you have lsof or netcat installed. It could be replaced by rpcinfo (as suggested before) which is provided by libc-bin, so no extra dependencies and no breakage. Why not? Why such a resistance? -- WBR, Andrew signature.asc Description: PGP signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Wed, Apr 13, 2011 at 11:39:37PM +0300, Andrew O. Shadoura wrote: [...] Well, we only guarantee to support upgrades from stable to the next one. Obviously we will try to not break things in unstable and testing. Though it's not uncommon to make the assumption that users have at least upgraded to stable before doing partial upgrades to unstable/testing versions. This machine is (obviously) a server. I can't 'just upgrade' it to the stable at once, so I do partial upgrades. Dist-upgrade is no go at this moment. So in my attempt to get NFS over IPv6 working I got broken NFS at all :( [...] This is extremely foolish. Partial upgrades are not nearly so well tested. And while Debian attempts to support partial upgrades from one stable release to the next (oldstable/stable or stable/testing/unstable), we explicitly do not support skipping a release, which is what you are doing by mixing oldstable and unstable. If you still insist on mixing oldstable and unstable, use a staging server and pay a consultant to support it. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote: Hello, On Wed, 13 Apr 2011 22:28:54 +0200 Luk Claes l...@debian.org wrote: If it's the only case, it should be specified explicitly. And, after all, why not use the utility that is supposed to be used, and not this hackish thing? The only reason it was implemented this way is because bash is still essential and so does not need a dependency. So you prefer not to specify dependencies at all and break the install than to specify the dependency explicitly? I don't grok this, sorry :( Also, there's no way to get a newer bash unless I install it by hand. This system isn't lenny any more, but nothing has upgraded it yet by means of dependencies. Well, we only guarantee to support upgrades from stable to the next one. Obviously we will try to not break things in unstable and testing. Though it's not uncommon to make the assumption that users have at least upgraded to stable before doing partial upgrades to unstable/testing versions. This machine is (obviously) a server. I can't 'just upgrade' it to the stable at once, so I do partial upgrades. Dist-upgrade is no go at this moment. So in my attempt to get NFS over IPv6 working I got broken NFS at all :( Anyway, using a really old packaged bash, a newly packaged bash or a self compiled bash (even the version in lenny) should all work for this /dev/tcp use. It's bash 3.2-4 from lenny, it's not so old. And it doesn't have /dev/tcp support. It can also be replaced by 'lsof -i :111' or something netcat like, though for both these you need to make sure you have lsof or netcat installed. It could be replaced by rpcinfo (as suggested before) which is provided by libc-bin, so no extra dependencies and no breakage. Why not? Why such a resistance? I didn't see the suggestion to use rpcinfo. The one of libc-bin will probably be removed at some point, though we always will have the one of rpcbind. Committed, so will be in a new upload unless any objections are out. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 13-Apr-2011, Debian Bug Tracking System wrote:
Date: Wed, 13 Apr 2011 23:12:15 +0300
From: Andrew O. Shadoura bugzi...@tut.by
Message-ID: 20110413231215.189a2fc2@ileemo
On Wed, 13 Apr 2011 22:04:54 +0200
Luk Claes l...@debian.org wrote:
Unless you show that you:
1) have bash 4.1-3 or later installed ('apt-cache policy bash' for
instance) 2) are using bash as shell ('exec bash' for instance)
3) sunrpc service is running ('lsof -i :111' for instance)
4) still have this issue
It's going to stay closed as only in that case it's supposed to
work.
If it's the only case, it should be specified explicitly.
$ dpkg-query --showformat='Depends: ${Depends}\n' --show nfs-common
Depends: libc6 (= 2.4), libcap2 (= 2.10), libcomerr2 (= 1.01),
libevent-1.4-2 (= 1.4.13-stable), libgssapi-krb5-2 (= 1.6.dfsg.2),
libgssglue1, libk5crypto3 (= 1.6.dfsg.2), libkrb5-3 (= 1.6.dfsg.2),
libnfsidmap2, libtirpc1, libwrap0 (= 7.6-4~), rpcbind | portmap, adduser, ucf,
lsb-base (= 1.3-9ubuntu3), netbase (= 4.24), initscripts (= 2.86.ds1-38.1)
No mention of bash at all. If a specific version of bash is required,
that must be expressed as a dependency.
And, after all, why not use the utility that is supposed to be used,
and not this hackish thing?
The patch supplied with the original message on this bug report works,
AFAICT. I ask again that it be applied, to avoid needing to use
version-specific Bash features.
--
\ “We can't depend for the long run on distinguishing one |
`\ bitstream from another in order to figure out which rules |
_o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney b...@benfinney.id.au
signature.asc
Description: Digital signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Wed, Apr 13, 2011 at 11:01:26PM +0200, Luk Claes wrote: On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote: [...] It could be replaced by rpcinfo (as suggested before) which is provided by libc-bin, so no extra dependencies and no breakage. Why not? Why such a resistance? I didn't see the suggestion to use rpcinfo. The one of libc-bin will probably be removed at some point, though we always will have the one of rpcbind. Committed, so will be in a new upload unless any objections are out. Does glibc's rpcinfo actually work with rpcbind, then? It is documented as only speaking the portmapper protocol, and we now know libtirpc doesn't handle that. Also, I think either method (/dev/tcp/localhost/111 or rpcinfo) will not work for anyone who configures rpcbind to listen on IPv6 only. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 04/13/2011 11:32 PM, Ben Hutchings wrote: On Wed, Apr 13, 2011 at 11:01:26PM +0200, Luk Claes wrote: On 04/13/2011 10:39 PM, Andrew O. Shadoura wrote: [...] It could be replaced by rpcinfo (as suggested before) which is provided by libc-bin, so no extra dependencies and no breakage. Why not? Why such a resistance? I didn't see the suggestion to use rpcinfo. The one of libc-bin will probably be removed at some point, though we always will have the one of rpcbind. Committed, so will be in a new upload unless any objections are out. Does glibc's rpcinfo actually work with rpcbind, then? It is documented as only speaking the portmapper protocol, and we now know libtirpc doesn't handle that. Yes, it does work. Also, I think either method (/dev/tcp/localhost/111 or rpcinfo) will not work for anyone who configures rpcbind to listen on IPv6 only. Only rpcbind's rpcinfo would work in that case, true. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Sat, 2011-04-02 at 11:54 +1100, Ben Finney wrote: On 02-Apr-2011, Ben Hutchings wrote: Which version of bash is installed? $ aptitude show bash | grep '^Version:' Version: 4.1-3 $ /bin/bash --version GNU bash, version 4.1.5(1)-release (powerpc-unknown-linux-gnu) So in what sense does the test 'not work'? Does 'cat /dev/null /dev/tcp/localhost/111' produce any error message? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 03-Apr-2011, Ben Hutchings wrote: So in what sense does the test 'not work'? It fails (exits with a non-zero status), even though the ‘portmapper’ service is running. Does 'cat /dev/null /dev/tcp/localhost/111' produce any error message? No. -- \ “It is the integrity of each individual human that is in final | `\examination. On personal integrity hangs humanity's fate.” | _o__) —Richard Buckminster Fuller, _Critical Path_, 1981 | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Sun, 2011-04-03 at 13:43 +1000, Ben Finney wrote: On 03-Apr-2011, Ben Hutchings wrote: So in what sense does the test 'not work'? It fails (exits with a non-zero status), even though the ‘portmapper’ service is running. Does 'cat /dev/null /dev/tcp/localhost/111' produce any error message? No. So you're saying that on your system, the 'cat' command can silently fail? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 03-Apr-2011, Ben Hutchings wrote: So you're saying that on your system, the 'cat' command can silently fail? I'm describing (actually, repeating) what was in the initial bug report for that test, modulo my misunderstanding about Bash's special treatment of that path. For now, I've worked around the problem and am unable to reproduce it (the test now passes). Possibly that's because of a kernel upgrade; I don't know. -- \ “It is forbidden to steal hotel towels. Please if you are not | `\ person to do such is please not to read notice.” —hotel, | _o__) Kowloon, Hong Kong | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
Package: nfs-kernel-server Version: 1:1.2.2-5 Severity: important Tags: patch The ‘/etc/init.d/nfs-kernel-server’ script has a new dependency on a non-existent directory: = # See if portmap or rpcbind are running (cat /dev/null /dev/tcp/localhost/111) 2/dev/null RET=$? if [ $RET != 0 ]; then echo log_warning_msg Not starting: portmap daemon is not running exit 0 fi = This results in the script failing, with “Not starting: portmap daemon is not running”. That's nothing to do with the portmapper service. It's because there is no such directory ‘/dev/tcp/’ on this machine: $ ls /dev/tcp/ ls: cannot access /dev/tcp/: No such file or directory To check for the portmapper service, the ‘rpcinfo(1)’ tool is provided. Using that program, we can see that the service is running on this machine: $ rpcinfo -t localhost portmapper program 10 version 2 ready and waiting The following patch uses this test, which works in current “Wheezy”. === modified file 'init.d/nfs-kernel-server' --- old/init.d/nfs-kernel-server2011-04-01 12:03:38 + +++ new/init.d/nfs-kernel-server2011-04-01 19:51:56 + @@ -84,7 +84,7 @@ log_progress_msg nfsd - # See if portmap or rpcbind are running - (cat /dev/null /dev/tcp/localhost/111) 2/dev/null + # See if the portmapper service is running. + (rpcinfo -t localhost portmapper) /dev/null 2/dev/null RET=$? if [ $RET != 0 ]; then echo -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.32-5-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-kernel-server depends on: ii libblkid1 2.17.2-9.1 block device id library ii libc6 2.11.2-11Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libgssapi-krb5-21.8.3+dfsg-4 MIT Kerberos runtime libraries - k ii libgssglue1 0.1-4mechanism-switch gssapi library ii libk5crypto31.8.3+dfsg-4 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg-4 MIT Kerberos runtime libraries ii libnfsidmap20.24-1 An nfs idmapping library ii librpcsecgss3 0.19-2 allows secure rpc communication us ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base3.2-27 Linux Standard Base 3.2 init scrip ii nfs-common 1:1.2.2-5NFS support files common to client ii ucf 3.0025+nmu1 Update Configuration File: preserv nfs-kernel-server recommends no packages. nfs-kernel-server suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Sat, Apr 2, 2011 at 07:00:11 +1100, Ben Finney wrote: The ‘/etc/init.d/nfs-kernel-server’ script has a new dependency on a non-existent directory: It's not supposed to be a directory, it's a bash feature for redirections to tcp sockets. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 01-Apr-2011, Julien Cristau wrote: On Sat, Apr 2, 2011 at 07:00:11 +1100, Ben Finney wrote: The ‘/etc/init.d/nfs-kernel-server’ script has a new dependency on a non-existent directory: It's not supposed to be a directory, it's a bash feature for redirections to tcp sockets. Okay. It's not working on this machine; the ‘rpcinfo -t localhost portmapper’ test does work. -- \ “If you don't know what your program is supposed to do, you'd | `\ better not start writing it.” —Edsger W. Dijkstra | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On Sat, Apr 02, 2011 at 08:42:09AM +1100, Ben Finney wrote: On 01-Apr-2011, Julien Cristau wrote: On Sat, Apr 2, 2011 at 07:00:11 +1100, Ben Finney wrote: The ‘/etc/init.d/nfs-kernel-server’ script has a new dependency on a non-existent directory: It's not supposed to be a directory, it's a bash feature for redirections to tcp sockets. Okay. It's not working on this machine; the ‘rpcinfo -t localhost portmapper’ test does work. Which version of bash is installed? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620421: nfs-kernel-server: init script depends on non-existent ‘/dev/tcp/’
On 02-Apr-2011, Ben Hutchings wrote: Which version of bash is installed? $ aptitude show bash | grep '^Version:' Version: 4.1-3 $ /bin/bash --version GNU bash, version 4.1.5(1)-release (powerpc-unknown-linux-gnu) -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
