Roadmap
Here's the Roadmap for Mamnuts as it is defined at the moment:
Following the directions that can be read at
http://mindboosternoori.blogspot.com/2005/11/building-talker.html, the idea os
MAMNUTS is to provide a secure an stable code base until AmNUTS 2.3.0 isn't
done. Here's the roadmap:
v1.0:
Release MAMNUTS as AmNUTS CVS is right now, but with the changes to show that
this is MAMNUTS and not AmNUTS.
This won't be a bug-free version, but will be the most bugless talker base
there is...
v1.1:
Fix #3: The easy fix is to take out the .sreboot command.
v1.2:
Fix #11: The easy fix is to take out the .kill command.
v1.3:
Fix #23: The easy fix is to take out .xcom and .gcom commands.
v1.4:
Fix #36: Revert "multi-line paste" changes. It will reduce usability but fix a security issue.
v2.0:
Fix #44: Changing "int" to "socklen_t" will probably fix the issue, but you'll
have to live with the fact that it won't work in old systems.
This will be (hopefully) a bug-free talker base.
If you have ideas for what should be included in this roadmap, please e-mail me
about it to marado@isp.novis.pt.
posted by Mind Booster Noori @ 1:49 PM
10 Comments:
The real way to fix sreboot is to fix the way users are logged on and off so that during a regular reboot a reboot trail (just a list of usernames and socket numbers) can be saved and users can be logged out without disconnecting their sockets then reboot the port and have the code notice the reboot trail and just auto-log people in without reconnecting sockets (just linking to the existing connected sockets).
The .kill is more than just the .kill command (just that is how it is most easily seen and how it was reported). What really needs to happen is that either the user list needs to be redesigned to remove linked lists or (even better) the way users disconnections/command execution needs to be looked at so one users cannot cause the destruction of another user struct in the same pass of the linked list. One way to do this is to mark users that are logged off in a certain fashion but not "reap" their user struct and then reap logged off structs in a separate pass.
Removing .gcom and .xcom might work but it doesnt fix the problem that access rights needs to be finer controlled than a strict linear level progression. What should be implements if true access control lists (ACLs) where users can belong to groups and those groups assigned rights (to commands, etc.).
Reverting the multiline paste just makesone bug go away and another take its place. The real fix is to implment true state-machine parsers that correctly parse both telnet and lines (as per the telnet specifications).
The int to socklen_t is an easy hack but the real fix to this is to use something like autoconf and automake that can probe system header files and functions and have the talker code provide a socklen_t for older systems that dont have such (and then use just socklen_t everywhere).
There are *many* other bugs and good things to doo too. Like I highly recomment riping out the netlinks and clone code as those are both rather poorly designed (and you can get rid of the multiple user types since there are three, clones, remote netlink and local regular users; rip those out and you can have just one and no need to track that--not to mention the huge code reduction).
If you want to add clone code back in the right way to do this is to revamp the room vcode into generalized channels. This has the added benefit of reducing the room code to one instead of regular rooms and personal rooms (have one room DB and allow rooms to be linked to "owners", etc.)
If you want to add something like netlinks back in instead add code to allow Amnuts to interact with ewtoo-like "intercom" code which is much better designed multi-talker interface.
Thanks for the insight Uzume.
1) The sreboot issue can be fixed as you said but while we don't have the time to do it we just removed sreboot. That way you won't have problems with it, right?
2) While the users struct still has the problem you mentioned (and that needs to be fixed somehow, maybe like you said even if that's not the Way To Do It (tm) (at least it's the quickier way I can remember of!)) we removed the .kill command. With the right manpower we will do a propper fix.
3) IMHO a talker should have two kinds of concepts that give them priviledges (commands or not): user level and user group. In lot's of thematic talkers we see a kind of "groups" being made, archaicly, and proper groups support would fix the problem at last.
4) Implementing a propper telnet support is such a big effort that I would rather do another talker base from scratch (which I will do in the future). Of course that if you're proposing yourself to it, I would gladly accept that contribution! ;-)
5) automake and autoconf would be sweet - but that's way out of the league here. If somebody has the time to do it, tho, we would gladly accept that contribution...
5) Taking the clones, netlinks and wizport stuff out of the talker _is_ in my roadmap.
6) The room vcode into generalized channels would be a really sweet feature, and I'm not talking about clones, but about lot's of other (for me more funny) things you could do out of it. But that's a feature, not a bugfix and I'm more worried about bugfixes.
7) For linking talkers (something I don't thing is that cool and I wouldn't spend time coding it, but yet it would be nice to have) I think that the best thing would not be netlinks or intercom but actually write a protocol for it, maybe an extension to XMPP or something...
I have no qualms with removing sreboot. I think rebooting should change things (or why reboot?) and the current implementation in 2.3.0 tries to maintain as much state as possible (so as to not change anything). This limits when you can do an sreboot and seems pointless IMO. I would rather see the hot-reboot ability added to the regular reboot by fixing the login and logout code so people can be saved with that vs. the binary struct write hack.
Actually if you fix the login and logout code it should be easy to fix the .kill issues by just marking disconnected user and reaping them in a separate user linked-list pass. TCP/sockets even has an elegant to handle this via a disconnection notice which I thought to employ.
Proper telnet actually isnt that hard. The tricky part comes in if you want to support telnet option negotiation (but that can be added later). Currently Amnuts really only tries to use like one or two telnet options and such usage isnt very necessary (like remote echo to obscure password entry, etc.)
autoconf/automake could also be retrofited incrementally.
Yes, the whole current design of communication flows is poor at best IMO. I do not think Neil or Andy really did much design work in the beginning.
ewtoo intercom code was just an example (it is much better designed though). I do want to generalize the connection session code to allow for different types of connections. I though an authenticated secure channel like ssh or TLS/SSL-telnet would be interesting as well as possible IM gateways (though I think I would want this to be limited).
I agree with you in those several points, and let me emphatise the need to have the talker-functionality and the comunication protocol in two different layers. That would make it easy for anyone to add support to other stuff besides telnet, or simple activate/deactivate its use. I don't know any nowadays talkers that allow you to connect only via telnet-ssl, but I know of some that allow both telnet and telnet-ssl (like mine). Some years ago I did a study (actualy an academic work) on wether would it be better to have SSH or telnet-ssl as encrypted connections to talkers, and SSH isn't the best choice definitively.
The problem in separating the communiation layer from the logic layer with the current (M)amnuts is that the code is just a mess mixing both, and the effort to do that is really big.
I also have some crazy ideas for what would be great as a "next-generation talker", but I still have to put those ideas into words and then I'll probably post them on my blog.
I would be very interested to hear about your study of telnet-ssl vs. ssh.
Yes, some heavy-lifting is required to fix/split the connection session stuff from the user/personal stuff (and I thought I might go one more and allow one authenticated user to have multiple personas as well so personas could point to authenticated sessions or something)
I have often thought it would be better to write one from scratch. The general concept is not that hard but to do it right requires a good infrastructure which means alot of tricky and boring code (at least to would be talker owners who usually want features done yesterday).
My main programming key is maintainability first. This usually means smaller is better (and often faster too though not always).
Some of the key things that need to be done in such an infrastructure is a socket polling library (that polls for events via blocking functions like select, poll, etc.--this is abstracted and the best can be used), an event queuing library (using a priority queue to queue timed events), a protocol/line parsing library (telnet, telnet-ssl, etc), a database library for storing data (talker config, user DB, channel/room DB, etc), and finally another good one is a string handling library (libc string.h and friends sucks and allows for many security issues). On top of these actual talker peices can be created (user ACLs, admin commands, interaction commands, etc.).
I have no machine in home at the moment (but got some fried data, tho :-( ) but once I fix it I'll look for my backed-up stuff looking for that paper... It was written in Portuguese, but once I find it I think I can easily spend some time getting it updated and in english.
BTW, you might want to read my article purposing a new generation talker here.
I am skeptical but it does sound interesting.
Where are things currently at with Mamnuts?
Check http://mamnuts.blogspot.com for status. A new version was recently released fixing a problem with Mamnuts on Solaris. There's a CVS repository setted up. And I'm working on a new version, to fix a little problem on mamnuts that was introduced on amnuts 2.3.0, regarding .smail.
Post a Comment
<< Home