Groups > linux.debian.user > #274436 > unrolled thread

utelnetd

Started by	peter@easthope.ca
First post	2024-11-10 04:20 +0100
Last post	2024-12-07 20:50 +0100
Articles	20 on this page of 26 — 11 participants

Back to article view | Back to linux.debian.user

  utelnetd peter@easthope.ca - 2024-11-10 04:20 +0100
    Re: utelnetd Jeffrey Walton <noloader@gmail.com> - 2024-11-10 04:50 +0100
      Re: utelnetd from 2012 and `make DEBUG=1` Geert Stappers <stappers@stappers.nl> - 2024-11-10 08:40 +0100
      Re: utelnetd peter@easthope.ca - 2024-11-10 17:30 +0100
        Re: utelnetd <tomas@tuxteam.de> - 2024-11-10 17:40 +0100
          Re: utelnetd peter@easthope.ca - 2024-11-10 19:30 +0100
            Re: utelnetd <tomas@tuxteam.de> - 2024-11-10 19:40 +0100
            Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-10 19:50 +0100
              Re: utelnetd peter@easthope.ca - 2024-11-14 20:00 +0100
                Re: utelnetd Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-11-14 20:30 +0100
                  Re: utelnetd peter@easthope.ca - 2024-11-15 18:20 +0100
                    Re: utelnetd debian-user@howorth.org.uk - 2024-11-15 18:30 +0100
                    Re: utelnetd Stefan Monnier <monnier@iro.umontreal.ca> - 2024-11-15 18:50 +0100
                      Re: utelnetd peter@easthope.ca - 2024-11-15 20:30 +0100
                        Re: utelnetd Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-11-15 23:00 +0100
                        Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-15 23:10 +0100
    Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-10 21:20 +0100
      Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-10 21:30 +0100
        Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-11-10 21:40 +0100
        Re: utelnetd Geert Stappers <stappers@stappers.nl> - 2024-11-10 22:30 +0100
        Re: utelnetd peter@easthope.ca - 2024-11-24 18:30 +0100
          Re: utelnetd Max Nikulin <manikulin@gmail.com> - 2024-11-25 03:30 +0100
    Re: utelnetd Greg Wooledge <greg@wooledge.org> - 2024-11-25 04:10 +0100
      [SOLVED] Re: utelnetd peter@easthope.ca - 2024-12-07 18:00 +0100
        Re: [SOLVED] Re: utelnetd Andy Smith <andy@strugglers.net> - 2024-12-07 19:20 +0100
        Re: utelnetd David Wright <deblis@lionunicorn.co.uk> - 2024-12-07 20:50 +0100

Page 1 of 2 [1] 2 Next page →

#274436 — utelnetd

From	peter@easthope.ca
Date	2024-11-10 04:20 +0100
Subject	utelnetd
Message-ID	<JH6Ex-7SyL-1@gated-at.bofh.it>

Retrieved utelnetd 0.1.11 from here.
https://public.pengutronix.de/software/utelnetd/

Installed gcc and tried make.
# make DEBUG=1 -f ./Makefile
make: Nothing to be done for 'all'.
#

This is the "all" stanza in Makefile.

all: $(PROGS)

$(PROGS): $(OBJS)
        $(CC) $(LDFLAGS) $(CFLAGS) $^ $(LDLIBS) -o $@
        $(STRIP) --remove-section=.comment --remove-section=.note $@

Is the problem in all?  Elsewhere?

Thanks,               ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [next] | [standalone]

#274437

From	Jeffrey Walton <noloader@gmail.com>
Date	2024-11-10 04:50 +0100
Message-ID	<JH77z-7SJE-1@gated-at.bofh.it>
In reply to	#274436

On Sat, Nov 9, 2024 at 10:18 PM <peter@easthope.ca> wrote:
>
> Retrieved utelnetd 0.1.11 from here.
> https://public.pengutronix.de/software/utelnetd/
>
> Installed gcc and tried make.
> # make DEBUG=1 -f ./Makefile
> make: Nothing to be done for 'all'.
> #
>
> This is the "all" stanza in Makefile.
>
> all: $(PROGS)
>
> $(PROGS): $(OBJS)
>         $(CC) $(LDFLAGS) $(CFLAGS) $^ $(LDLIBS) -o $@
>         $(STRIP) --remove-section=.comment --remove-section=.note $@
>
> Is the problem in all?  Elsewhere?

My guess is $PROGS is empty. But it is only a guess since the message
is missing so much information.

Maybe add a $(info $(PROGS)) before the 'all' recipe to see:

    $(info PROGS: $(PROGS))
    all: $(PROGS)

Jeff

[toc] | [prev] | [next] | [standalone]

#274438 — Re: utelnetd from 2012 and `make DEBUG=1`

From	Geert Stappers <stappers@stappers.nl>
Date	2024-11-10 08:40 +0100
Subject	Re: utelnetd from 2012 and `make DEBUG=1`
Message-ID	<JHaI9-7V2W-1@gated-at.bofh.it>
In reply to	#274437

On Sat, Nov 09, 2024 at 10:39:32PM -0500, Jeffrey Walton wrote:
> On Sat, Nov 9, 2024 at 10:18 PM <peter@easthope.ca> wrote:
> >
> > Retrieved utelnetd 0.1.11 from here.
> > https://public.pengutronix.de/software/utelnetd/
> >
> > Installed gcc and tried make.
> > # make DEBUG=1 -f ./Makefile
> > make: Nothing to be done for 'all'.
> > #

   :-)


> > This is the "all" stanza in Makefile.
> >
> > all: $(PROGS)
> >
> > $(PROGS): $(OBJS)
> >         $(CC) $(LDFLAGS) $(CFLAGS) $^ $(LDLIBS) -o $@
> >         $(STRIP) --remove-section=.comment --remove-section=.note $@
> >
> > Is the problem in all?  Elsewhere?
> 
> My guess is $PROGS is empty. But it is only a guess since the message
> is missing so much information.
> 
> Maybe add a $(info $(PROGS)) before the 'all' recipe to see:
> 
>     $(info PROGS: $(PROGS))
>     all: $(PROGS)


Curious about "info" in the Makefile, I tired it.
And I learnt it is "print".


Back to the original
> > make: Nothing to be done for 'all'.

It means "Request allready executed", it is worded
as "Nothing to be done"


Do `make clean`  and then `make DEBUG=1`.

 
> Jeff

Groeten
Geert Stappers



<screenshot
   note_1="Regular user, not root. Note the $, versus the # by original poster."
   note_2="There is no need for  `-f Makefile`."
   note_3="Lines with `PROGS: utelnet` are artifact of `$(info PROGS: $(PROGS))`"
>
stappers@paddy:~/src/utelnetd-0.1.11
$ make clean
PROGS: utelnetd
rm -f utelnetd *.o core
stappers@paddy:~/src/utelnetd-0.1.11
$ make
PROGS: utelnetd
gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -fomit-frame-pointer   -c -o utelnetd.o utelnetd.c
utelnetd.c: In function 'getpty':
utelnetd.c:232:13: warning: implicit declaration of function 'grantpt'; did you mean 'getpt'? [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |             ^~~~~~~
      |             getpt
utelnetd.c:232:29: warning: implicit declaration of function 'unlockpt' [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |                             ^~~~~~~~
utelnetd.c:238:35: warning: implicit declaration of function 'ptsname'; did you mean 'ptsname_r'? [-Wimplicit-function-declaration]
  238 |         strcpy(line, (const char*)ptsname(p));
      |                                   ^~~~~~~
      |                                   ptsname_r
utelnetd.c:238:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  238 |         strcpy(line, (const char*)ptsname(p));
      |                      ^
utelnetd.c: In function 'make_new_session':
utelnetd.c:264:17: warning: variable 't2' set but not used [-Wunused-but-set-variable]
  264 |         int t1, t2;
      |                 ^~
utelnetd.c:264:13: warning: variable 't1' set but not used [-Wunused-but-set-variable]
  264 |         int t1, t2;
      |             ^~
utelnetd.c: In function 'main':
utelnetd.c:561:42: warning: pointer targets in passing argument 3 of 'accept' differ in signedness [-Wpointer-sign]
  561 |                                          &salen)) < 0) {
      |                                          ^~~~~~
      |                                          |
      |                                          int *
In file included from utelnetd.c:45:
/usr/include/x86_64-linux-gnu/sys/socket.h:307:42: note: expected 'socklen_t * restrict' {aka 'unsigned int * restrict'} but argument is of type 'int *'
  307 |                    socklen_t *__restrict __addr_len);
      |                    ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
utelnetd.c:597:60: warning: pointer targets in passing argument 1 of 'remove_iacs' differ in signedness [-Wpointer-sign]
  597 |                                 ptr = remove_iacs(ts->buf1 + ts->wridx1, maxlen,
      |                                                   ~~~~~~~~~^~~~~~~~~~~~
      |                                                            |
      |                                                            char *
utelnetd.c:190:28: note: expected 'unsigned char *' but argument is of type 'char *'
  190 | remove_iacs(unsigned char *bf, int len, int *processed, int *num_totty) {
      |             ~~~~~~~~~~~~~~~^~
gcc  -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -fomit-frame-pointer utelnetd.o  -o utelnetd
strip  --remove-section=.comment --remove-section=.note utelnetd
stappers@paddy:~/src/utelnetd-0.1.11
$ make
PROGS: utelnetd
make: Nothing to be done for 'all'.
stappers@paddy:~/src/utelnetd-0.1.11
$ ls -l utelnetd
-rwxr-xr-x 1 stappers stappers 22984 Nov 10 08:12 utelnetd
stappers@paddy:~/src/utelnetd-0.1.11
$ make clean
PROGS: utelnetd
rm -f utelnetd *.o core
stappers@paddy:~/src/utelnetd-0.1.11
$ make DEBUG=1
PROGS: utelnetd
gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os   -c -o utelnetd.o utelnetd.c
utelnetd.c: In function 'getpty':
utelnetd.c:232:13: warning: implicit declaration of function 'grantpt'; did you mean 'getpt'? [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |             ^~~~~~~
      |             getpt
utelnetd.c:232:29: warning: implicit declaration of function 'unlockpt' [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |                             ^~~~~~~~
utelnetd.c:237:44: warning: implicit declaration of function 'ptsname'; did you mean 'ptsname_r'? [-Wimplicit-function-declaration]
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                                            ^~~~~~~
utelnetd.c:112:40: note: in definition of macro 'DEBUG_OUT'
  112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
      |                                        ^~~~~~~~~~~
utelnetd.c:237:19: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'int' [-Wformat=]
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
      |                                            |
      |                                            int
utelnetd.c:112:40: note: in definition of macro 'DEBUG_OUT'
  112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
      |                                        ^~~~~~~~~~~
utelnetd.c:237:39: note: format string is defined here
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                                      ~^
      |                                       |
      |                                       char *
      |                                      %d
utelnetd.c:238:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  238 |         strcpy(line, (const char*)ptsname(p));
      |                      ^
utelnetd.c: In function 'main':
utelnetd.c:561:42: warning: pointer targets in passing argument 3 of 'accept' differ in signedness [-Wpointer-sign]
  561 |                                          &salen)) < 0) {
      |                                          ^~~~~~
      |                                          |
      |                                          int *
In file included from utelnetd.c:45:
/usr/include/x86_64-linux-gnu/sys/socket.h:307:42: note: expected 'socklen_t * restrict' {aka 'unsigned int * restrict'} but argument is of type 'int *'
  307 |                    socklen_t *__restrict __addr_len);
      |                    ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
utelnetd.c:597:60: warning: pointer targets in passing argument 1 of 'remove_iacs' differ in signedness [-Wpointer-sign]
  597 |                                 ptr = remove_iacs(ts->buf1 + ts->wridx1, maxlen,
      |                                                   ~~~~~~~~~^~~~~~~~~~~~
      |                                                            |
      |                                                            char *
utelnetd.c:190:28: note: expected 'unsigned char *' but argument is of type 'char *'
  190 | remove_iacs(unsigned char *bf, int len, int *processed, int *num_totty) {
      |             ~~~~~~~~~~~~~~~^~
gcc  -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os utelnetd.o  -o utelnetd
# --remove-section=.comment --remove-section=.note utelnetd
stappers@paddy:~/src/utelnetd-0.1.11
$ make DEBUG=1
PROGS: utelnetd
make: Nothing to be done for 'all'.
stappers@paddy:~/src/utelnetd-0.1.11
$ ls -l utelnetd
-rwxr-xr-x 1 stappers stappers 44696 Nov 10 08:12 utelnetd
stappers@paddy:~/src/utelnetd-0.1.11
$
</screenshot>
-- 
Silence is hard to parse

[toc] | [prev] | [next] | [standalone]

#274449

From	peter@easthope.ca
Date	2024-11-10 17:30 +0100
Message-ID	<JHiZ3-80eh-5@gated-at.bofh.it>
In reply to	#274437

Jeffrey, thanks for the reply.  Decades since I've looked at a makefile. 
Understanding is marginal.

From: Jeffrey Walton <noloader@gmail.com>
Date: Sat, 9 Nov 2024 22:39:32 -0500
> My guess is $PROGS is empty. But it is only a guess since the message
> is missing so much information.
> 
> Maybe add a $(info $(PROGS)) before the 'all' recipe to see:
> 
>     $(info PROGS: $(PROGS))
>     all: $(PROGS)

Inserted line "$(info PROGS: $(PROGS))" ahead of "all: $(PROGS)".  That's 
what you intended, correct? 

Got this.
# make DEBUG=1 -f ./Makefile
PROGS: utelnetd
make: Nothing to be done for 'all'.

Confirms the assignment earlier in Makefile.

# grep utelnetd Makefile
# Makefile for utelnetd
CORE            := utelnetd.core
PROGS     = utelnetd
OBJS      = utelnetd.o

According to this, libc.so is the only dependancy.
https://boxmatrix.info/wiki/Property:utelnetd

/usr# find . -type f -name "libc.so"
./lib/x86_64-linux-gnu/libc.so

 Seems OK.

Something elementary and critical missing?

Thanks,                        ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274450

From	<tomas@tuxteam.de>
Date	2024-11-10 17:40 +0100
Message-ID	<JHj8J-80hv-11@gated-at.bofh.it>
In reply to	#274449

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 10, 2024 at 08:07:23AM -0700, peter@easthope.ca wrote:
> Jeffrey, thanks for the reply.  Decades since I've looked at a makefile. 
> Understanding is marginal.
> 
> From: Jeffrey Walton <noloader@gmail.com>
> Date: Sat, 9 Nov 2024 22:39:32 -0500
> > My guess is $PROGS is empty. But it is only a guess since the message
> > is missing so much information.
> > 
> > Maybe add a $(info $(PROGS)) before the 'all' recipe to see:
> > 
> >     $(info PROGS: $(PROGS))
> >     all: $(PROGS)
> 
> Inserted line "$(info PROGS: $(PROGS))" ahead of "all: $(PROGS)".  That's 
> what you intended, correct? 
> 
> Got this.
> # make DEBUG=1 -f ./Makefile
> PROGS: utelnetd
> make: Nothing to be done for 'all'.

That would mean that some "utelnetd" is there and is as young or
younger than its dependencies, so Make concludes that it has nothing
to do.

Perhaps you need a "make clean" before, to force Make to actually
do its thing? Missing that target, you might want to remove utelned,
and perhaps utelnetd.o.

But perhaps Make is right and utelnetd is built and ready to go?

What evidence would you have that it is not so?

Cheers
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#274451

From	peter@easthope.ca
Date	2024-11-10 19:30 +0100
Message-ID	<JHkRc-81ns-19@gated-at.bofh.it>
In reply to	#274450

    From: <tomas@tuxteam.de>
    Date: Sun, 10 Nov 2024 17:30:42 +0100
> But perhaps Make is right and utelnetd is built and ready to go?
> 
> What evidence would you have that it is not so?

# ls -ld /usr/local/bin/u*
ls: cannot access '/usr/local/bin/u*': No such file or directory

# cd /usr
# find . -type f -name "utelnetd"
#

> Perhaps you need a "make clean" before, to force Make to actually
> do its thing? Missing that target, you might want to remove utelned,
> and perhaps utelnetd.o.

# make clean
PROGS: utelnetd
rm -f utelnetd *.o core

Now make gives a flock of complaints.  See below.  Eg. grantpt vs. 
getpt.  

The problem is Debian differing from the system where where the 
developer worked?  I need to change some names?

Thanks,                 ... P.

# make DEBUG=1 -f ./Makefile
PROGS: utelnetd
gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os   -c -o utelnetd.o utelnetd.c
utelnetd.c: In function ‘getpty’:
utelnetd.c:232:13: warning: implicit declaration of function ‘grantpt’; did you mean ‘getpt’? [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |             ^~~~~~~
      |             getpt
utelnetd.c:232:29: warning: implicit declaration of function ‘unlockpt’ [-Wimplicit-function-declaration]
  232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
      |                             ^~~~~~~~
utelnetd.c:237:44: warning: implicit declaration of function ‘ptsname’; did you mean ‘ptsname_r’? [-Wimplicit-function-declaration]
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                                            ^~~~~~~
utelnetd.c:112:40: note: in definition of macro ‘DEBUG_OUT’
  112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
      |                                        ^~~~~~~~~~~
utelnetd.c:237:19: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
      |                                            |
      |                                            int
utelnetd.c:112:40: note: in definition of macro ‘DEBUG_OUT’
  112 | #define DEBUG_OUT(...) fprintf(stderr, __VA_ARGS__)
      |                                        ^~~~~~~~~~~
utelnetd.c:237:39: note: format string is defined here
  237 |         DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
      |                                      ~^
      |                                       |
      |                                       char *
      |                                      %d
utelnetd.c:238:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  238 |         strcpy(line, (const char*)ptsname(p));
      |                      ^
utelnetd.c: In function ‘main’:
utelnetd.c:561:7: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness [-Wpointer-sign]
  561 |       &salen)) < 0) {
      |       ^~~~~~
      |       |
      |       int *
In file included from utelnetd.c:45:
/usr/include/x86_64-linux-gnu/sys/socket.h:233:28: note: expected ‘socklen_t * restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
  233 |      socklen_t *__restrict __addr_len);
      |      ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
utelnetd.c:597:32: warning: pointer targets in passing argument 1 of ‘remove_iacs’ differ in signedness [-Wpointer-sign]
  597 |     ptr = remove_iacs(ts->buf1 + ts->wridx1, maxlen,
      |                       ~~~~~~~~~^~~~~~~~~~~~
      |                                |
      |                                char *
utelnetd.c:190:28: note: expected ‘unsigned char *’ but argument is of type ‘char *’
  190 | remove_iacs(unsigned char *bf, int len, int *processed, int *num_totty) {
      |             ~~~~~~~~~~~~~~~^~
gcc  -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os utelnetd.o  -o utelnetd
# --remove-section=.comment --remove-section=.note utelnetd
#
-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274452

From	<tomas@tuxteam.de>
Date	2024-11-10 19:40 +0100
Message-ID	<JHl0S-81qD-15@gated-at.bofh.it>
In reply to	#274451

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 10, 2024 at 10:08:47AM -0700, peter@easthope.ca wrote:
>     From: <tomas@tuxteam.de>
>     Date: Sun, 10 Nov 2024 17:30:42 +0100
> > But perhaps Make is right and utelnetd is built and ready to go?
> > 
> > What evidence would you have that it is not so?
> 
> # ls -ld /usr/local/bin/u*
> ls: cannot access '/usr/local/bin/u*': No such file or directory
> 
> # cd /usr
> # find . -type f -name "utelnetd"
> #
> 
> > Perhaps you need a "make clean" before, to force Make to actually
> > do its thing? Missing that target, you might want to remove utelned,
> > and perhaps utelnetd.o.
> 
> # make clean
> PROGS: utelnetd
> rm -f utelnetd *.o core
> 
> Now make gives a flock of complaints.  See below.  Eg. grantpt vs. 
> getpt.  
> 
> The problem is Debian differing from the system where where the 
> developer worked?  I need to change some names?
> 
> Thanks,                 ... P.
> 
> # make DEBUG=1 -f ./Makefile
> PROGS: utelnetd
> gcc -I. -pipe -DSHELLPATH=\"/bin/login\" -Wall -DDEBUG -g -Os   -c -o utelnetd.o utelnetd.c
> utelnetd.c: In function ‘getpty’:
> utelnetd.c:232:13: warning: implicit declaration of function ‘grantpt’; did you mean ‘getpt’? [-Wimplicit-function-declaration]
>   232 |         if (grantpt(p)<0 || unlockpt(p)<0) {
>       |             ^~~~~~~
>       |             getpt

[...]

Hm. No. This function should exist. Either your compile process is hitting
the wrong libc headers, or something else is amiss.

The error message just means that the compiler hasn't seen a declaration
for grantpt. It /should/ have seen one.

(the other error messages are in the same ballpark).

Now if the header file was just missing, the complaints would be different,
I guess.

Cheers
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#274453

From	Greg Wooledge <greg@wooledge.org>
Date	2024-11-10 19:50 +0100
Message-ID	<JHlax-81tQ-3@gated-at.bofh.it>
In reply to	#274451

On Sun, Nov 10, 2024 at 10:08:47 -0700, peter@easthope.ca wrote:
>     From: <tomas@tuxteam.de>
>     Date: Sun, 10 Nov 2024 17:30:42 +0100
> > But perhaps Make is right and utelnetd is built and ready to go?
> > 
> > What evidence would you have that it is not so?
> 
> # ls -ld /usr/local/bin/u*
> ls: cannot access '/usr/local/bin/u*': No such file or directory

Is this your first time building software from source code?  Normally
there are three steps:

1) Configure it to build on your system; this may involve running a
   shell script or a perl script, or editing files manually.  This
   is normally done as yourself.

2) Run "make" or "cmake" or some equivalent program.  This is normally
   done as yourself.  This builds the program(s) in the current directory,
   or some subdirectory.

3) Run "make install" or something equivalent, to copy the program(s)
   to the system directories.  This usually requires root privileges.

> # cd /usr
> # find . -type f -name "utelnetd"
> #

So what you're telling us is that you've done the first two steps, and
utelnetd has been built in the build directory, but you haven't
installed it into /usr/local/bin yet.

Now, I have absolutely no idea what this "utelnetd" does, other than what
I can guess from its name.  But if it's supposed to be a *telnet daemon*
that you run and connect to, then installing it in /usr/local/bin (or
somewhere) is only going to be one step among several.  You'd also need
to arrange for it to be run as a service.

If you're struggling with understanding the difference between "make"
and "make install", then getting this third party program running as a
service is going to have quite a learning curve for you.

The first question I had when I saw this thread was "Why on *earth* is
he trying to run a third party telnet daemon?"  What's wrong with the
telnet daemon that's included in Debian?  Why would you even want a
telnet daemon in 2024?  It's so incredibly insecure!

But hey, maybe the name is a red herring, and it does something else
entirely.  Who knows.

Anyway, I suggest you read the documentation more closely.  If the
documentation isn't adequate for someone with your skill set (which
is quite probable with third party programs), then please explain
to us what you're *trying to do*.  We'll probably tell you to throw
this thing away and use something else.

[toc] | [prev] | [next] | [standalone]

#274520

From	peter@easthope.ca
Date	2024-11-14 20:00 +0100
Message-ID	<JINep-8WaK-7@gated-at.bofh.it>
In reply to	#274453

    From: Greg Wooledge <greg@wooledge.org>
    Date: Sun, 10 Nov 2024 13:41:11 -0500
> Is this your first time building software from source code?

Haven't thought about make since about 1993 and my exposure then was 
minimal.  Remember "make"; not "install".

> 3) Run "make install" or something equivalent, to copy the program(s)
>    to the system directories.  This usually requires root privileges.

Thanks.  Was oblivious to that.  "man make" gives no mention of install but 
TLDP helps.
https://tldp.org/HOWTO/Software-Building-HOWTO-3.html
https://tldp.org/LDP/LG/current/smith.html
etc.

> Now, I have absolutely no idea what this "utelnetd" does, ...

Found it about a week ago.
https://wiki.gentoo.org/wiki/Utelnetd
https://boxmatrix.info/wiki/Property:utelnetd
https://public.pengutronix.de/software/utelnetd/
https://sourceforge.net/projects/utelnetd/
The boxmatrix and pengutronix pages suggest that it was developed 
primarily to allow a console on an embedded system.

> If you're struggling with understanding the difference between "make"
> and "make install", then getting this third party program running as a
> service is going to have quite a learning curve for you.

If all else fails, may ask another question.

> What's wrong with the telnet daemon that's included in Debian?

Used it for years.  When multiple terminals connected to a central 
mainframe it was appropriate.  My application is software (embedded) 
in a Debian system.  Only 2 or 3 telnet consoles needed.

Gruesome details here.
https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Telnet_Console
https://en.wikibooks.org/wiki/Oberon/A2#User_Level_Applications

inetd/telnetd is rather overkill and utelned should suffice.

Regards,                        ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274521

From	Timothy M Butterworth <timothy.m.butterworth@gmail.com>
Date	2024-11-14 20:30 +0100
Message-ID	<JINHr-8WA9-7@gated-at.bofh.it>
In reply to	#274520

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 14, 2024 at 1:57 PM <peter@easthope.ca> wrote:

>     From: Greg Wooledge <greg@wooledge.org>
>     Date: Sun, 10 Nov 2024 13:41:11 -0500
> > Is this your first time building software from source code?
>
> Haven't thought about make since about 1993 and my exposure then was
> minimal.  Remember "make"; not "install".
>
> > 3) Run "make install" or something equivalent, to copy the program(s)
> >    to the system directories.  This usually requires root privileges.
>
> Thanks.  Was oblivious to that.  "man make" gives no mention of install
> but
> TLDP helps.
> https://tldp.org/HOWTO/Software-Building-HOWTO-3.html
> https://tldp.org/LDP/LG/current/smith.html
> etc.
>
> > Now, I have absolutely no idea what this "utelnetd" does, ...
>
> Found it about a week ago.
> https://wiki.gentoo.org/wiki/Utelnetd
> https://boxmatrix.info/wiki/Property:utelnetd
> https://public.pengutronix.de/software/utelnetd/
> https://sourceforge.net/projects/utelnetd/
> The boxmatrix and pengutronix pages suggest that it was developed
> primarily to allow a console on an embedded system.
>

You should look into Secure Shell SSH instead of telnet. SSH encrypts the
traffic but telnet is plain  text. SSHD is packaged and available on Debian.


>
> > If you're struggling with understanding the difference between "make"
> > and "make install", then getting this third party program running as a
> > service is going to have quite a learning curve for you.
>
> If all else fails, may ask another question.
>
> > What's wrong with the telnet daemon that's included in Debian?
>
> Used it for years.  When multiple terminals connected to a central
> mainframe it was appropriate.  My application is software (embedded)
> in a Debian system.  Only 2 or 3 telnet consoles needed.
>
> Gruesome details here.
> https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Telnet_Console
> https://en.wikibooks.org/wiki/Oberon/A2#User_Level_Applications
>
> inetd/telnetd is rather overkill and utelned should suffice.
>
> Regards,                        ... P.
>
> --
> VoIP:   +1 604 670 0140
> <http://voice.google.com/calls?a=nc,%2B16046700140>
> work: https://en.wikibooks.org/wiki/User:PeterEasthope
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[toc] | [prev] | [next] | [standalone]

#274526

From	peter@easthope.ca
Date	2024-11-15 18:20 +0100
Message-ID	<JJ89b-99hm-3@gated-at.bofh.it>
In reply to	#274521

Extremely long References header shortened.  =8~/

    From: Timothy M Butterworth <timothy.m.butterworth@gmail.com>
    Date: Thu, 14 Nov 2024 14:21:20 -0500
> SSHD is packaged and available on Debian.

Timothy, for a console on localhost do you use ssh exclusively?  Never 
xterm or similar?  You authenticate every connection to localhost?

> SSH encrypts the traffic but telnet is plain  text.

I don't know the implementation of xterm and etc.   Is an xterm 
connection to localhost direct or under TLS?  Naively, I wouldn't 
expect TLS to be necessary for localhost.  When a miscreant has access 
to a machine, TLS on a local console connection probably won't help.  
=8~/

> You should look into Secure Shell SSH instead of telnet. 

Used it in A2.  

ETHO would require significant updating.  (Project for my next life.)
Details available via my previous message.

Thx,                        ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274527

From	debian-user@howorth.org.uk
Date	2024-11-15 18:30 +0100
Message-ID	<JJ8iR-99kG-3@gated-at.bofh.it>
In reply to	#274526

peter@easthope.ca wrote:
> Extremely long References header shortened.  =8~/
> 
>     From: Timothy M Butterworth <timothy.m.butterworth@gmail.com>
>     Date: Thu, 14 Nov 2024 14:21:20 -0500
> > SSHD is packaged and available on Debian.  
> 
> Timothy, for a console on localhost do you use ssh exclusively?
> Never xterm or similar?  You authenticate every connection to
> localhost?
> 
> > SSH encrypts the traffic but telnet is plain  text.  
> 
> I don't know the implementation of xterm and etc.   Is an xterm 
> connection to localhost direct or under TLS?  Naively, I wouldn't 
> expect TLS to be necessary for localhost.  When a miscreant has
> access to a machine, TLS on a local console connection probably won't
> help. =8~/
> 
> > You should look into Secure Shell SSH instead of telnet.   
> 
> Used it in A2.  
> 
> ETHO would require significant updating.  (Project for my next life.)
> Details available via my previous message.
> 
> Thx,                        ... P.

I'm thoroughly confused. What are you actually trying to do?

[toc] | [prev] | [next] | [standalone]

#274528

From	Stefan Monnier <monnier@iro.umontreal.ca>
Date	2024-11-15 18:50 +0100
Message-ID	<JJ8Cd-99r6-1@gated-at.bofh.it>
In reply to	#274526

>> SSHD is packaged and available on Debian.
> Timothy, for a console on localhost do you use ssh exclusively?  Never 
> xterm or similar?  You authenticate every connection to localhost?

Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside*
`xterm`, no *instead of* `xterm`.

> Naively, I wouldn't  expect TLS to be necessary for localhost.

When you want to "log into localhost" you can usually use `su` instead
of `ssh/telnet`.  This said, I sometimes use `ssh` anyway (typically in
scripts) so it works the same for local and non-local connections.
Presumably encryption is not needed for localhost (tho I'm not
completely sure to what extent there could be non-root processes which
could listen on the connection via the loopback device), but as long as
you're not transferring large amounts of data the overhead of encryption
should be lost in the noise.


        Stefan

[toc] | [prev] | [next] | [standalone]

#274529

From	peter@easthope.ca
Date	2024-11-15 20:30 +0100
Message-ID	<JJab0-9arq-3@gated-at.bofh.it>
In reply to	#274528

    From: Stefan Monnier <monnier@iro.umontreal.ca>
    Date: Fri, 15 Nov 2024 12:45:14 -0500
> Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside* 
> `xterm`, no *instead of* `xterm`.

OK, I understand that.  If X11 is running you use xterm or similar. If 
X11 is not running you can do "ssh localhost" on the command line of a 
virtual console.

> When you want to "log into localhost" you can usually use `su` instead
> of `ssh/telnet`.  This said, I sometimes use `ssh` anyway (typically in
> scripts) ...

I considered only the live interactive case.  Not a script.

> Presumably encryption is not needed for localhost ...

Exactly what I meant with "Naively, I wouldn't expect TLS to be 
necessary for localhost.  When a miscreant has access to a machine, 
TLS on a local console connection probably won't help."

Thx,                 ... P.

-- 
VoIP:   +1 604 670 0140
work: https://en.wikibooks.org/wiki/User:PeterEasthope

[toc] | [prev] | [next] | [standalone]

#274532

From	Timothy M Butterworth <timothy.m.butterworth@gmail.com>
Date	2024-11-15 23:00 +0100
Message-ID	<JJcw9-9bOu-1@gated-at.bofh.it>
In reply to	#274529

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 15, 2024 at 2:27 PM <peter@easthope.ca> wrote:

>     From: Stefan Monnier <monnier@iro.umontreal.ca>
>     Date: Fri, 15 Nov 2024 12:45:14 -0500
> > Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside*
> > `xterm`, no *instead of* `xterm`.
>
> OK, I understand that.  If X11 is running you use xterm or similar. If
> X11 is not running you can do "ssh localhost" on the command line of a
> virtual console.
>

If you are logged into a virtual console you do not need SSH or Telnet. You
can simply issue the commands, as you will be logged into a BaSH Shell.


> > When you want to "log into localhost" you can usually use `su` instead
> > of `ssh/telnet`.  This said, I sometimes use `ssh` anyway (typically in
> > scripts) ...
>
> I considered only the live interactive case.  Not a script.
>
> > Presumably encryption is not needed for localhost ...
>
> Exactly what I meant with "Naively, I wouldn't expect TLS to be
> necessary for localhost.  When a miscreant has access to a machine,
> TLS on a local console connection probably won't help."
>
> Thx,                 ... P.
>
> --
> VoIP:   +1 604 670 0140
> <http://voice.google.com/calls?a=nc,%2B16046700140>
> work: https://en.wikibooks.org/wiki/User:PeterEasthope
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[toc] | [prev] | [next] | [standalone]

#274533

From	Andy Smith <andy@strugglers.net>
Date	2024-11-15 23:10 +0100
Message-ID	<JJcFQ-9c7S-9@gated-at.bofh.it>
In reply to	#274529

Hi,

On Fri, Nov 15, 2024 at 11:11:49AM -0700, peter@easthope.ca wrote:
> Exactly what I meant with "Naively, I wouldn't expect TLS to be 
> necessary for localhost.

This utelnetd is also not necessary for localhost. And if telnet was
actually a requirement, I'm fairly confident that the telnetd that is
already packaged in Debian would suffice for your purposes on all but
the most tiny of systems. If you have been able to boot Debian on it,
probably Debian's telnetd is okay.

It seems really really unlikely that working out how to compile this
ancient telnetd variant is what you actually want to do here.

Put simply, if there is no IP network involved then you do not need an
sshd or telnetd.

If there is am IP network involved then you probably want sshd.

If you have really unusual requirements like one end or the other not
being up to the task of even running ssh, then MAYBE you could try
telnet, in which case Debian's telnetd is right there.

I think the time has past that even telnetd has to be cut down, which
I think probably reflects the last date that utelnetd received an
update.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#274455

From	Andy Smith <andy@strugglers.net>
Date	2024-11-10 21:20 +0100
Message-ID	<JHmzD-82xM-1@gated-at.bofh.it>
In reply to	#274436

On Sat, Nov 09, 2024 at 07:02:12PM -0700, peter@easthope.ca wrote:
Hi,

> Retrieved utelnetd 0.1.11 from here.
> https://public.pengutronix.de/software/utelnetd/

This is really old software that you're trying to build from source and
while that should still be possible, it seems it's not something that
you're very familiar with so could be a lot of work to learn what needs
to be fixed to make that work on up to date Debian.

Is there some specific reason why you need a very minimal telnet
server?

If the machine is capable of running openssh or dropbear then normally
anything you would want to do through telnet could be done through ssh,
with the advantage that these are packaged in Debian already.

There is also a telnetd packaged in Debian but I think that one needs to
be run under an inetd so you'd have to install one of those as well.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#274456

From	Greg Wooledge <greg@wooledge.org>
Date	2024-11-10 21:30 +0100
Message-ID	<JHmJj-82AY-7@gated-at.bofh.it>
In reply to	#274455

On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
> There is also a telnetd packaged in Debian but I think that one needs to
> be run under an inetd so you'd have to install one of those as well.

Fortunately, the inetutils-telnetd package in Debian depends on
inetutils-inetd | inet-superserver, so it should bring in an inetd
automatically if one isn't already present.

I'd really like to hear why the OP is trying to build a third-party
telnet daemon instead of simply installing inetutils-telnetd which
should work out of the box.

[toc] | [prev] | [next] | [standalone]

#274458

From	Andy Smith <andy@strugglers.net>
Date	2024-11-10 21:40 +0100
Message-ID	<JHmSZ-82DU-1@gated-at.bofh.it>
In reply to	#274456

Hi,

On Sun, Nov 10, 2024 at 03:23:38PM -0500, Greg Wooledge wrote:
> On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
> > There is also a telnetd packaged in Debian but I think that one needs to
> > be run under an inetd so you'd have to install one of those as well.
> 
> Fortunately, the inetutils-telnetd package in Debian depends on
> inetutils-inetd | inet-superserver, so it should bring in an inetd
> automatically if one isn't already present.

Sure, but I was wondering if the reason not to run the packaged telnetd
was because it would mean running an inetd as well.

Just struggling to find the point of utelnetd existing I suppose.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#274459

From	Geert Stappers <stappers@stappers.nl>
Date	2024-11-10 22:30 +0100
Message-ID	<JHnFn-839o-3@gated-at.bofh.it>
In reply to	#274456

On Sun, Nov 10, 2024 at 03:23:38PM -0500, Greg Wooledge wrote:
> On Sun, Nov 10, 2024 at 20:15:44 +0000, Andy Smith wrote:
> > There is also a telnetd packaged in Debian but I think that one needs to
> > be run under an inetd so you'd have to install one of those as well.
> 
> Fortunately, the inetutils-telnetd package in Debian depends on
> inetutils-inetd | inet-superserver, so it should bring in an inetd
> automatically if one isn't already present.
> 
> I'd really like to hear why the OP is trying to build a third-party
> telnet daemon instead of simply installing inetutils-telnetd which
> should work out of the box.

Original Poster now in Cc:   And I have the awark feeling that OP
missed https://lists.debian.org/debian-user/2024/11/msg00217.html


Groeten
Geert Stappers
-- 
Silence is hard to parse

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

utelnetd

Contents

#274436 — utelnetd

#274437

#274438 — Re: utelnetd from 2012 and `make DEBUG=1`

#274449

#274450

#274451

#274452

#274453

#274520

#274521

#274526

#274527

#274528

#274529

#274532

#274533

#274455

#274456

#274458

#274459