If I were to write my own BBS software...questions for Sysops and developers (in particular). reddit / bbs ---------------------------------------------------------------------- SqualorTrawler · 2018-09-16 23:12 One of the things that chaps my ass is how utterly frustrating I find using bulletin board systems. I think I'm probably one of the few people from the old days that feels this way today, and I get that. But I also know that a lot of the things which are frustrating me are probably frustrating to newcomers as well. I've made this attempt to "write my own BBS software" several times and I think I'm taking the wrong approach. I am a dabbler and hobbyist with code at best, and I wondered if anyone could provide some insight. I work mainly on Linux and FreeBSD. I figured out long ago that the (x)inetd daemons can be configured to run pretty much anything when something comes in on, say, the telnet port. My first question is, does anyone have a sense as to what the ramifications would be if telnet were disposed of altogether? Those of you who are sysops: Do you have any indication of how many people still use telnet, as a percentage of your users? I realize this is a meaningless question for those of you on retrocomputing platforms using old BBS software, so I am mainly asking people who run currently maintained systems like Mystic and Synchronet. My second question is, does running bbs.py or bbs.pl or whatever via the inetd.conf configuration for telnet even make sense? I've run into a variety of problems with Perl where things just didn't seem to work right - bad and unexpected formatting in particular (especially with newlines) and especially hotkeys. I can find no way to make hotkeys work in Perl/telnet. The input methods always require a carriage return which is irritating (one of the things I like about Mystic is how quickly you can fly through the interface with single keystrokes.) I can't recall all of the things I've tried - there was one or more way of doing single key input which works fine in a local terminal but doesn't work at all over telnet. Fighting with telnet is boring. I mean, it's telnet. Third question - does anyone know of a BBS package which can handle radically large terminal sizes, and can handle wrapping and the like in a reasonable manner? The 80x24 limitations feel claustrophobic to me especially on packages like Mystic with these gigantic headers and then a line at the bottom. I love the idea of a memeless, text-only messaging platform but I'd love to use my 1920x1080 resolution to its fullest. Fourth question - what are the security ramifications of assigning a user's login shell on a Linux or xBSD system to a script? Ordinarily you specify a standard shell like sh or bash or tcsh or whatever - but you can also specify a script, which is a way you can handle incoming SSH sessions. If I trap control sequences I can prevent a CTRL-C, but even if CTRL-C is used in this instance, it ordinarily just terminates the script and drops the connection anyway. I am just wondering if despite this, there is still a way of escaping to a shell I'm not thinking of (one way would be some kind of unsanitized input which runs a shell). For paging, I'd love to just use **less**. The basic idea is I'd like to just pass off these less interesting functions to well-developed, maintained packages and methodologies already available in the operating system. Lastly, I have to believe someone has thought of a lot of these limitations before. Are there any BBS-like packages out there which take into account the realities of modern computing? ---------------------------------------------------------------------- RealDeuce · 2018-09-17 05:49 > My first question is, does anyone have a sense as to what the ramifications would be if telnet were disposed of altogether? Do you mean the protocol or the software? If you mean the software, the ramification is that you will need to implement the telnet protocol yourself... and it's *terrible*. If you mean the protocol, you need to come up with an alternative. SSH can be used, but SSH generally requires authentication of the client, so you'll need a unique new user signup thing. RLogin can be used and is easy enough to implement, but there's no good way of passing additional data such as terminal size changes (the out-of-band data mechanism that RLogin uses is obsolete and broken). > My second question is, does running bbs.py or bbs.pl or whatever via the inetd.conf configuration for telnet even make sense? No, not really... you'll need to either implement the telnet protocol yourself (which is a nightmare), or use an existing one that is designed for very different use cases. > I've run into a variety of problems with Perl where things just didn't seem to work right - bad and unexpected formatting in particular (especially with newlines) and especially hotkeys. I can find no way to make hotkeys work in Perl/telnet. So the default mode of telnet is a line at a time, and a bare CR is expanded to a CRLF. Look at [RFC854](https://www.rfc- editor.org/rfc/rfc854.txt): > 1) Insofar as the availability of local buffer space permits, data should be accumulated in the host where it is generated until a complete line of data is ready for transmission, or until some locally-defined explicit signal to transmit occurs. This signal could be generated either by a process or by a human user. And: > Therefore, the sequence "CR LF" must be treated as a single "new line" character and used whenever their combined action is intended; the sequence "CR NUL" must be used where a carriage return alone is actually desired; and the CR character must be avoided in other contexts. You need to set various telnet options to get into the character at a time remote echo mode that you likely expect. See [RFC855](https://www.rfc-editor.org/rfc/rfc855.txt) for details. > I can find no way to make hotkeys work in Perl/telnet. The input methods always require a carriage return Sounds like you're looking for [Term::Readkey](https://metacpan.org/pod/Term::ReadKey). > Third question - does anyone know of a BBS package which can handle radically large terminal sizes, and can handle wrapping and the like in a reasonable manner? Synchronet can, but it takes a whole lot of work. The default config only supports wide terminals for reading messages... the default menus and text file are all formatted for 80 column screens. You would need to customize almost everything, and you would lose the ability to do multi-line formatting beyond word wrap. Mystic may be able to do generated lightbar menus, but again, all of the formatted stuff would fall apart. > Fourth question - what are the security ramifications of assigning a user's login shell on a Linux or xBSD system to a script? You potentially have a well-known user account with a public password on your system. Every service you stand up on that box needs to avoid allowing that valid local user account to do anything you don't want it to... you'll want to sandbox that user heavily... at the very least, assume that any user will be able to run arbitrary programs as that local user. > If I trap control sequences I can prevent a CTRL-C, but even if CTRL-C is used in this instance, it ordinarily just terminates the script and drops the connection anyway. I am just wondering if despite this, there is still a way of escaping to a shell I'm not thinking of (one way would be some kind of unsanitized input which runs a shell). For paging, I'd love to just use less. The basic idea is I'd like to just pass off these less interesting functions to well-developed, maintained packages and methodologies already available in the operating system. In less for example, :e lets you view arbitrary files. It's possible that v will allow editing the files, and ! and | allows executing arbitrary commands. Very few programs will assume the user isn't allowed to do things as the user. ---------------------------------------------------------------------- gozarc · 2018-09-17 15:26 I started work on a Linux based BBS in the mid 90s. The user interface was written in HTML and the user used Lynx to navigate the BBS. Lynx was re-compiled with the option to allow it to launch apps. Forums were handled with a local install of inn, and users used tin to read. Messaging used Pine, and could only be used locally. That's about as far as I got with the BBS before shutting it down. I had come home from using VMS on the university mainfraime and wasn't impressed with the BBS software that was available. Maybe there's some ideas in there for you? ---------------------------------------------------------------------- kevinlamonte · 2018-09-17 17:52 > implement the telnet protocol yourself (which is a nightmare) Writing enough of the telnet protocol to get 8-bit clean data isn't too bad. Implementing all of the line-oriented stuff would suck, true, but almost no one wants any of that anyway. But then again, no one should be using unencrypted data in today's world. ---------------------------------------------------------------------- kevinlamonte · 2018-09-17 17:56 > Lastly, I have to believe someone has thought of a lot of these limitations before. Are there any BBS-like packages out there which take into account the realities of modern computing? Yes, we have. Deuce had an interesting thread on DOVE-Net years ago as he was approaching SyncTERM 1.0, about doing BBS-like things without the 80x24, CP437, ANSI.SYS limitations. For me, I went [a little different route](https://github.com/klamonte/jexer) . I wanted to demonstrate what a real xterm could do, using UTF-8 and full mouse support. Someday I would like to build a BBS-like system for it, probably a text-based frontend to RetroShare. ---------------------------------------------------------------------- RealDeuce · 2018-09-17 19:16 > Writing enough of the telnet protocol to get 8-bit clean data isn't too bad. It's actually not even possible to get 8-bit clean data, IAC *always* needs special handling. While it would be easy enough to force only enough to get exactly what you want, WONT the rest, and hang up if the other side gets uppity, you would still be chasing client-specific corner cases for a long time. ---------------------------------------------------------------------- kevinlamonte · 2018-09-17 20:07 > It's actually not even possible to get 8-bit clean data, IAC always needs special handling. I was referring to getting a 8-bit clean stream to the higher-level client code (e.g. zmodem), not on the wire. But you are also right, looking at [my](https://github.com/klamonte/jexer/blob/master/src/jexe r/net/TelnetInputStream.java) [implementations](https://github.com/kla monte/qodem/blob/master/source/netclient.c) I do ignore Mark, Break, Interrupt Process, and so on which can come in at any time even when Binary is agreed to. > you would still be chasing client-specific corner cases for a long time True too. One of the Debian telnetd's circa jessie, don't remember if it was netkit or inetutils, was putting spurious CRs or LFs in the stream even after it had agreed to Binary. Took a while to discover that it really was the telnetd and not me doing that. My other complaint about telnet is that apparently zero telnetd's bother passing TERM or LANG to login, despite two different means of getting environment variables to them, so there is no seamless way to get UTF-8 for example. ---------------------------------------------------------------------- RolandMT32 · 2018-09-18 17:47 >My first question is, does anyone have a sense as to what the ramifications would be if telnet were disposed of altogether? Those of you who are sysops: > >Do you have any indication of how many people still use telnet, as a percentage of your users? For the terminal server, it seems to me that 99% of my users use telnet. I've thought that it would be more secure to use SSH, but if you disable telnet and only let people use SSH, I have a feeling that you would have far fewer users. Users tend to just use telnet. ​ >Third question - does anyone know of a BBS package which can handle radically large terminal sizes, and can handle wrapping and the like in a reasonable manner? The 80x24 limitations feel claustrophobic to me especially on packages like Mystic with these gigantic headers and then a line at the bottom. I love the idea of a memeless, text-only messaging platform but I'd love to use my 1920x1080 resolution to its fullest. I use Synchronet, and I think it has the potential to support any terminal size (and from a modding standpoint, the user's terminal size is made available to JavaScript, so you could program your mods to take advantage of a large terminal size). I think it's just that sysops tend to create their ANSI screens to be in an 80x24 format for historical reasons. But I don't see why you couldn't make bigger ANSI screens. It's just that in order for it to dynamically take advantage of various terminal sizes, you'd need something programmatic rather than using static ANSI files. I think one issue with this is that as screen resolutions increase (there are 4K monitors now), you can have a lot more text on the screen at a time, and if you stick with the default font size, you could potentially have a wall of text on the screen. As a user, it could get difficult to read through all the text on the screen. You may need to increase the font size to make things easier to read on a big screen, but that would also mean not being able to fit as much text on the screen. ---------------------------------------------------------------------- semi-matter · 2018-09-21 23:26 I'm not a sysop anymore, but I'll take a stab at your questions. 1. My impression is that there are still telnet boards up, but most of them are dead in terms of activity. For something like Mystic, I think beyond your limited set of users who are really into the rhythm and nostalgia of a tty -- it's just more practical to use a newsreader and pull messages via NNTP, when you have everything else in the world (e.g. reddit) competing for your attention. 2. IMO that sort of interface is realistically dead (not of any growing interest to people), unless and until someone introduces something new for power users. There are plenty of people who uses CLIs everyday in the world, and people who are comfortable with text- only interfaces (e.g. IRC). We need something that marries the most likeable and useful aspects of modern terminal apps. My personal opinion is that it'd have to be something that works pretty much like a unix shell does already, small tools working together written around a BBS core, and something users can extend with their own code (eg Lua, or equiv). 3. This wouldn't be an issue with an interface like I described above. 4. I'm assuming you know about rbash, chroot, things like that... and generally why it's bad to assign a login shell to a BBS account on a system that hasn't been hardened. You don't want to run anything where a user can find a way to drop out of and get a shell prompt. If you want users to be in a shell, you'll probably want to consider putting that environment in a container, one that should restrict SYS\_PTRACE. Then, assuming this is Linux, you'll want to combine a restricted shell plus SELinux to limit the scope of what users can do to just the BBS functions. You could very well cobble together a sort of "BBS" out of the stuff in a basic Linux install. Almost everything you need is there, but locking it down is another matter. 5. If you want to take a peek at some open-source C code for a BBS, [h ttp://www.iscabbs.com/index.php?doc=download](http://www.iscabbs.com/i ndex.php?doc=download) is a place to start. It's for a Citadel, but it should show you how to handle tty input, text wrapping, ANSI, and all of that from a C perspective.