2024-11-02 20:27 from IGnatius T Foobar
Subject: Re: New telnet problem!
There's some chatter out on teh interwebz about `docker exec` failing
to forward signals to the payload process, and supposedly it's been
fixed but maybe my Docker package isn't up to date with that change or
something. I'll try it again someday. For now I worked around the
problem by grabbing the client binary and libcitadel binary and running
them outside of the Docker container.
Indeed I'd recommend avoiding running docker exec. As you have noted, one way to do that is to host the client outside the container. Another approach is to forward port 23 to the container and run a telnetd in the container. I don't know what your Dockerfile looks like, but you might have to add `supervisord` or similar in order to have multiple services in a single container. That's a fairly common approach. (The "one service per container" dogma is just that: dogma, for inflexibly-minded people.)
It's at https://code.citadel.org/citadel-docker.git/tree/Dockerfile if you want to take a look.
I did briefly consider running supervisord, but it's written in Python. I love Python, but I didn't want to include the entire runtime in the container just to run a bunch of C programs, so I wrote an equivalent program in C to handle that task. ctdlvisor is the container's entrypoint and it can start things up in a couple of different maintenance modes, and under the normal mode it starts up citserver and two copies of webcit (one http and one https), and restarts them just like init or systemd if they exit for an unexpected reason. citserver is considered the "leader" and the whole thing shuts down if citserver is commanded to exit.
So yes, we could run a telnet service inside the container, and it might even be the ideal way to go. Or as an even more ambitious approach, build telnet support directly into the client. Gotta find the most compact way to do so. I'd prefer not to have the whole xinetd/inetd infrastructure in there.
There's also the small matter of adding SSH support. I suppose the SSH user could just be sent to a script that calls telnet.
Great BBS! Thanks for keeping it running!
My story:
I remember using webcit sometimes > 10 yrs ago (when I was a sysadmin),
but never the text client.
Today I manually compiled the text client under NetBSD (which I am proud of :)
and here we are...
Make Textual Client Great Again! (no pun intended, I am not even from USA :)
Thanks again and have a nice BBS-ing ;)
Having your own copy of the client is definitely the better way to go if you're connecting over a high-latency link (like an I2P tunnel). Congratulations on getting that going.
I plan to stick around not only because of the text client (which I like much), but also I find the discussions here facinating :) As mentioned somewhere in the citadel documentation "We have a great community of fun people there. And as you might expect, it isn't oppressed by the cancel culture of Big Tech."
... that is true!
Not much of a chatter myself, but I would enjoy the community :)
Cheers!
The more the merrier..
like IRC people like to do. You'll definitely want to explore the
options you can configure in citadel.rc such as automatic login, the
yes, just doing it :) it is a lot of fun :) there are super useful things (just found that I can download files from directory!) there are others which are probably much useful, but I already have them on my super-duper-customised-terminal (like opening urls)
BTW, i maybe just found a bug: commands.c line 841 'rc_ansi_color = 1;' maybe needs to be 'rc_ansi_color = 0;', because later on at line 943 it is again 'rc_ansi_color = 1;' and it never has the possibility to turn off the colors (i'm trying to configure ansi_color=off in citadel.rc) - i am speaking for textclient "#define CLIENT_VERSION 1004"
Cheers, the joy continues ... ;)
I should try that sometime.
i dunno, a man either lives in the terminal, or not...
now I put 'ansi_color=off' in ~/.citadelrc and the client is forced to no color
(was not working before)
"I love this game!" : speaking about the text client :)
Do you know some way to Reply a message with Editor, e.g whenever I have:
(0) <B>ack <A>gain <R>eply reply<Q>uoted <N>ext <S>top <?>help ->
and when I hit <R>eply to give me a possibility to reply with my own editor?
Cheers :)
I was about to come and report this quirk having finally upgraded my server from 1000 to 1006 -- nice to know it is a bug and should be fixed, as it's made telnet annoying to use with garbage characters in the name field on the citadel client. Fine with SSH.
Actually made a workaround by having telnet ssh into the server, but that still broke in a freedos test, so... yeah... once this is fixed things should be back to normal I guess. :D
I was about to come and report this quirkToday i reported it (maybe you have seen it already in the support room)
freedos testah! as I am a newbie here - for the first time learned that someone is using
citadel together with freedos :) this is exciting :)
Cheers :)
freedos testah! as I am a newbie here - for the first time learned that someone is using
citadel together with freedos :) this is exciting :)Well, I mean in as far as using the built in Telnet client that comes with FreeDos - it will support color fine but even with the workaround I mentioned it breaks in that particular client.
I wish I had access to my C128 to test with, while I'm thinking on it but, well, it's going to be a while before I can use that hardware again, but here I'm just thinking out loud... haha.
VICE emulator will do a C128.
So yes, we could run a telnet service inside the container, and it
might even be the ideal way to go. Or as an even more ambitious
Aha! I found a way to run telnetd without requiring the heft of inetd or xinetd. `socat` does the trick.
/usr/bin/socat tcp6-listen:23,reuseaddr,fork EXEC:"telnetd -h -E /usr/local/bin/citadel"
I wasn't comfortable putting a general purpose superserver into the container image, but just socat and telnetd, that's not so bad. That still leaves SSH to contend with, though. Until I think it through I'm going to just leave socat+telnetd running in the LXC container and run the servers in Docker.
yup, setting 'rc_ansi_color = 0;' on line 841 of commands.c resolves theproblem
now I put 'ansi_color=off' in ~/.citadelrc and the client is forced to nocolor
There were recent changes there and I broke it :)
Just fixed it tonight (in upstream). Until recently it was off/on/auto but ANSI terminals are so ubiquitous now that "auto" ought to be the right setting almost everywhere.
BUT ... as some of you are discovering, there are situations where it doesn't seem to wait long enough after the terminal enquiry, and you end up with the text of the terminal's answerback on the username prompt. This both sucks and blows and I'm trying to figure out what makes that happen.
ah! as I am a newbie here - for the first time learned that someone is using
citadel together with freedos :) this is exciting :)
I'm just thrilled that there's so much interest in the Citadel text mode experience right now.
Spread the word -- I'd love to see a lot more enthusiasts here.
I'm just thrilled that there's so much interest in the Citadel text mode experience right now.
Spread the word -- I'd love to see a lot more enthusiasts here.
I'll continue to do my part with my reach and skill set. I can read C enough and know enough about the terminal world to see some neat things coming for the text mode client. Given my focus on Final Zone being a good old Citadel BBS I'm naturally going to continue to follow the text mode client thoroughly. Hell, I wish I had the skills to contribute in some meaningful way and maybe I do but just not in a way I can think of at the moment.
Just curious, when should that color fix be pushed to release -- that is to say, I guess, when might we get 1007?