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)
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'.
But perhaps Make is right and utelnetd is built and ready to go?
What evidence would you have that it is not so?
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.
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
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"
#
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.
Retrieved utelnetd 0.1.11 from here. https://public.pengutronix.de/software/utelnetd/
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.
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.
Is this your first time building software from source code?
3) Run "make install" or something equivalent, to copy the program(s)
to the system directories. This usually requires root privileges.
Now, I have absolutely no idea what this "utelnetd" does, ...
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.
What's wrong with the telnet daemon that's included in Debian?
SSHD is packaged and available on Debian.
SSH encrypts the traffic but telnet is plain text.
You should look into Secure Shell SSH instead of telnet.
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.
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?
Naively, I wouldn't expect TLS to be necessary for localhost.
Hmm...`xterm` is unrelated: you'd run `telnet` or `ssh` *inside*
`xterm`, no *instead of* `xterm`.
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) ...
Presumably encryption is not needed for localhost ...
Exactly what I meant with "Naively, I wouldn't expect TLS to be
necessary for localhost.
... inetutils-telnetd which should work out of the box.
Now, I have absolutely no idea what this "utelnetd" does, ...
Retrieved utelnetd 0.1.11 from here. https://public.pengutronix.de/software/utelnetd/
Anyway, the program compiles just fine on Debian 12.
I won't try to guess how important the warnings are.
There is no need to complain to the Debian GCC maintainers ...
So much for trying to find documentation ...
Unencrypted login sessions, with passwords being > sent in the clearover a network, are inherently insecure.
Unencrypted login sessions, with passwords being > sent in the clear
over a network, are inherently insecure.
You give a password every time a xterm or similar is opened?
Unencrypted login sessions, with passwords being
sent in the clear over a network, are inherently insecure.
You give a password every time a xterm or similar is opened? To my understanding, most users just open the term and go at the command line.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 01:37:54 |
Calls: | 10,385 |
Calls today: | 2 |
Files: | 14,057 |
Messages: | 6,416,579 |