Re: tinysshd dependency on systemd

[Ivan Shmakov]

> Jonathan Dowland  writes:
> On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:

 >> I disagree; to the best of my knowledge, anyone can do the testing
 >> and suggest any fixes he or she deems necessary.  As such, having an
 >> issue recorded in the BTS is preferable to not having it recorded,
 >> and having a (semi-correct)

 >

 > You win the prize for the most Orwellian spelling of "untested and
 > broken" that I've seen today. (so far.)

If this comment has some purpose conductive to free software
development, I’m afraid it has so far eluded me.  (Though I
suppose I can be glad for you if you’ve found my wording amusing.)

 > Whilst you wasted your time (and ours) on this side-show,

If reading my messages on debian-devel@ takes a non-trivial amount
of time for you, may I suggest that you filter them out?

As for the assessment of how productive my efforts are – please
don’t; I’m perfectly capable of doing that myself.

 > the actual maintainer has actually fixed the dependency problem
 > (a one line change in the control file)

From whence I’ve found it adequate to probe if an effort to fix
the apparent violation of Policy 9.11 (quoted below) would be
appreciated.

  […]  However, any package integrating with other init systems must
  also be backwards-compatible with sysvinit by providing a SysV-style
  init script with the same name as and equivalent functionality to any
  init-specific job, as this is the only start-up configuration method
  guaranteed to be supported by all init implementations.

  — http://debian.org/doc/debian-policy/ch-opersys.html#alternate-init-systems

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: tinysshd dependency on systemd

[Jonathan Dowland]

On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:

I disagree; to the best of my knowledge, anyone can do the testing and
suggest any fixes he or she deems necessary.  As such, having an issue
recorded in the BTS is preferable to not having it recorded, and
having a (semi-correct)

   

You win the prize for the most Orwellian spelling of "untested and
broken" that I've seen today. (so far.)

Whilst you wasted your time (and ours) on this side-show, the actual
maintainer has actually fixed the dependency problem (a one line change
in the control file)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: tinysshd dependency on systemd

[Vincent Bernat]

 ❦ 22 octobre 2018 00:34 +0200, Svante Signell :

>> Well, reporting bugs about software you don't care or patches you
>> don't test is not always useful. For example, you clearly didn't test
>> your wrapper (shebang is #!/usr/sh) nor the init script
>> (/lib/init/init-d-script is expecting the daemon to fork). The
>> maintainer would have to do the testing, possibly the immediate fixes
>> and all the future maintenance. Just for you to make a point.
>
> Did you treat the code in the previous message as patches for some bug,
> in that case which bug? I did not, Ivan just published some possible
> code snippets to help.

You are right, I may have jumped too soon.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: tinysshd dependency on systemd

[Svante Signell]

On Sun, 2018-10-21 at 23:04 +0200, Vincent Bernat wrote:
>  ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :
> 
> > 
> > You know, in almost twenty years of using GNU/Linux, I think
> > it’s the first time I’m requested /not/ to report bugs and
> > contribute patches.  How times did change, indeed!
> 
> Well, reporting bugs about software you don't care or patches you
> don't test is not always useful. For example, you clearly didn't test
> your wrapper (shebang is #!/usr/sh) nor the init script
> (/lib/init/init-d-script is expecting the daemon to fork). The
> maintainer would have to do the testing, possibly the immediate fixes
> and all the future maintenance. Just for you to make a point.

Did you treat the code in the previous message as patches for some bug,
in that case which bug? I did not, Ivan just published some possible
code snippets to help.

Confused.

Re: tinysshd dependency on systemd

[Ivan Shmakov]

> Vincent Bernat  writes:
> ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :

 >>> so if you were an actual user, I would propose you file a bug
 >>> report against the package to let the maintainer knows the
 >>> dependency is too strong for your use (and maybe propose a patch to
 >>> integrate with inetd).

 >>> As you are not, please, do not.  Our resources are scarce and we
 >>> already cater for the need of many non-existent users.

 >> You know, in almost twenty years of using GNU/Linux, I think it’s
 >> the first time I’m requested /not/ to report bugs and contribute
 >> patches.  How times did change, indeed!

 > Well, reporting bugs about software you don’t care or patches you
 > don’t test is not always useful.  For example, you clearly didn’t
 > test your wrapper (shebang is #!/usr/sh) nor the init script
 > (/lib/init/init-d-script is expecting the daemon to fork.)

Indeed; I even said that much in my posting.  (Meanwhile, one
another issue I’ve found is that the wrapper lacks a trailing
‘exit 1’.)

AFAICT, the init.d script issue can be fixed by adding
START_ARGS=--background there.

 > The maintainer would have to do the testing, possibly the immediate
 > fixes and all the future maintenance.  Just for you to make a point.

I disagree; to the best of my knowledge, anyone can do the
testing and suggest any fixes he or she deems necessary.  As
such, having an issue recorded in the BTS is preferable to not
having it recorded, and having a (semi-correct) patch on file
is preferable to not having any patch at all.

If maintainer decides resolving the issue is not worth the
effort, the (wishlist) bug can stay in the BTS indefinitely.
The maintainer can as well make /that/ a point.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: tinysshd dependency on systemd

[Vincent Bernat]

 ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :

>  > so if you were an actual user, I would propose you file a bug report
>  > against the package to let the maintainer knows the dependency is too
>  > strong for your use (and maybe propose a patch to integrate with inetd).
>
>  > As you are not, please, do not.  Our resources are scarce and we
>  > already cater for the need of many non-existent users.
>
>   You know, in almost twenty years of using GNU/Linux, I think
>   it’s the first time I’m requested /not/ to report bugs and
>   contribute patches.  How times did change, indeed!

Well, reporting bugs about software you don't care or patches you don't
test is not always useful. For example, you clearly didn't test your
wrapper (shebang is #!/usr/sh) nor the init script
(/lib/init/init-d-script is expecting the daemon to fork). The
maintainer would have to do the testing, possibly the immediate fixes
and all the future maintenance. Just for you to make a point.
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

tinysshd dependency on systemd

[Ivan Shmakov]

> Vincent Bernat  writes:
> ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
> ‘TFH’ == Tollef Fog Heen  writes:

[…]

 TFH> tinysshd only ships a systemd unit file; neomutt links against
 TFH> libgpgme11 which again Depends on gnupg.  It’s the kind of
 TFH> dependencies that individually make sense,

 >> I beg to differ; I suppose (though haven’t actually tried) I can
 >> start tinysshd straight from rc.local just as well, or even write my
 >> own init.d script, right?  Having the dependency in place just makes
 >> it harder to me to contribute an init.d script for the package.

 > tinysshd requires some kind of socket server to run.  It could run
 > from inetd,

Reading tinysshd(8), I see that it can also be started from
tcpserver(8) or BusyBox’ tcpsvd (which doesn’t seem to be
available in Debian yet.)  Or, I suppose, socat(1)?  Say:

# setsid -- socat  TCP6-LISTEN:22,fork \
  EXEC:"tinysshd -v /etc/tinyssh/sshkeydir" & 

Contrary to running from Inetd, the use of the likes of socat(1)
and tcpserver(8) can readily be adapted for an init.d script
(or, rather, init-d-script(5) DAEMON wrapper), which in turn
allows the user to control the daemon with the usual service(8).

Examples (untested) of such a wrapper and a corresponding init.d
script are MIMEd.

 > so if you were an actual user, I would propose you file a bug report
 > against the package to let the maintainer knows the dependency is too
 > strong for your use (and maybe propose a patch to integrate with inetd).

 > As you are not, please, do not.  Our resources are scarce and we
 > already cater for the need of many non-existent users.

You know, in almost twenty years of using GNU/Linux, I think
it’s the first time I’m requested /not/ to report bugs and
contribute patches.  How times did change, indeed!

-- 
FSF associate member #7257  http://am-1.org/~ivan/
#!/usr/sh
### tinysshd-wrapper  -*- Sh -*-
## Run tinysshd via socat(1) or tcpserver(8), whichever is available.

### Ivan Shmakov, 2018

## To the extent possible under law, the author(s) have dedicated
## all copyright and related and neighboring rights to this software
## to the public domain worldwide.  This software is distributed
## without any warranty.

## You should have received a copy of the CC0 Public Domain Dedication
## along with this software.  If not, see
## .

### Code:

set -e

TINYSSHD=/usr/sbin/tinysshd
SSHKEYDIR=/etc/tinyssh/sshkeydir
PORT=22
PREFERENCE="socat tcpserver"

test  -r /etc/default/tinysshd-wrapper \
&& . /etc/default/tinysshd-wrapper

run_socat () {
## .
exec socat  TCP6-LISTEN:"$PORT",fork \
EXEC:"$TINYSSHD -l -v $SSHKEYDIR"
}

run_tcpserver () {
## .
exec tcpserver -HRDl0 0.0.0.0 "$PORT" \
"$TINYSSHD" -v "$SSHKEYDIR"
}

for p in ${PREFERENCE} ; do
type "$p" > /dev/null || continue
## .
run_"$p"
done

printf %s\\n "FATAL: Neither of ${PREFERENCE:-(none?)} are available" >&2

### tinysshd-wrapper ends here
#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides: tinysshd
# Required-Start:	$remote_fs $syslog
# Required-Stop: 	$remote_fs $syslog
# Default-Start: 	2 3 4 5
# Default-Stop:  	0 1 6
# Short-Description:minimalistic (subset of) SSHv2 server
### END INIT INFO
DESC="minimalistic (subset of) SSHv2 server"
DAEMON=/usr/sbin/tinysshd-wrapper