wiredfool

Download Last Updated 4/17/02

***What it is

If you’re administering a Frontier server on OSX, you need a way to set up port forwarding at startup. This archive contains a startup item that will set up portforwarding for all your machines ip addresses from port 80 to port 8080.

***Installation

Download. Get a command line prompt in the download directory. Use the following commands:

pwd
cd /Library/StartupItems 

if the cd command fails, type

sudo mkdir /Library/StartupItems
cd /Library/StartupItems 

Then type (replace /path/from/pwd with the path that is printed by the pwd command)

sudo tar -xvzf /path/from/pwd/portForward8080.tgz

This will expand the archive in the correct location to be execute on startup. If you want to, look at the script that is run (/Library/StartupItems/Multihoming/Multihoming ) to make sure that I’m not doing anything nasty to you.

Restart your machine to test that the command has been run properly. To check to see that it has been installed, run ‘ipfw show’ from a command prompt, and you chould see something like

[tibaby:~] erics% sudo ipfw show
00101        7        665 fwd 127.0.0.1,8080 tcp from any to any 80 in
65535 12709 53678 allow ip from any to any

The first line is the rule that was inserted, the second line is the default firewall configuration.

I [heart] logs. The more the better. when everything is logged, those wierd things that happen leave a foot print. And lots of times it’s obvious.

And if you can find the bug, it’s much easier to fix it.

*** Company in need of Clue
(or an entire train)

It looks like eHelp is in a fight with their users, customers and consultants.

It appears that one of their new products was purchased from another company, and in the transition increased in price about 6x. Their user community questions this move, and eHelp strikes back by firing their MVP and Certified Instructors for not toeing a company line.

eHelp meet cluetrain. I think that’s the light at the end of your tunnel.

Whenever I see the SCNS acronym I can’t help thinking of SCMODS. These are just cross wired in my brain. That happens a lot with initials and acronyms for me. Brands get mixed up, domains get crossed. Sometimes it’s even funny.

So to those marketers out there, if you want me to accurately remember your widget, make sure that it’s not confusable with obscure pop culture references. Or the code fragment manager (.cfm).

***Apple

Mmmmm xserve. I want one. Rather, I’ll take two, they’re small. I’ve got a dual 800 as my best server right now. It’s nice, but it’s big. And I’ve got a gaggle of other assorted g4’s hanging around. For what I’m doing, bandwidth to memory seems to be important, as well as the size of L3 cache.

The keys to the xserve are the DDR ram, lots of drives all on different controllers, lots of cache (2 meg per). It’s got bandwidth in all the important places, at least compared to what I’m working with now. Oh yeah, and it’s got a bit of processor too.

I still have a couple of questions about the storage subsystem and how it interacts with the software raid. Specifically, how can I split the 4 drives? 1 system + 3 raid 5? Raid 0+1? If I pull a (failed) drive and put in a spare will it sync up while on line? Are they going to require that I send them my firstborn?

I also find it interesting that it has a basic vga card and 9 pin serial for kvm or serial console access.

Sorry to those who’ve tried to log in to this site recently and failed. I did a database transplant on the membership and didn’t get everyone imported into the new system. I think things are working now. At the very least, things are working better than they were.

***Frontier TOC

The next revision to the ftocSuite should put it in the tcp.im drivers table. The functionality is going to be the same, but all of the scripts have been moved around a bit. All of the callbacks are now parsed through the new callback parser that was introduced on Friday. All of the outbound action scripts have been collected in their own sub table. And of course, there is the simple tcp.im interface on top of it all, if that’s all you need.

a scratchpad, a little bit of a brain dump.

***Notification, The scalability issue

At some point we’re probably going to be limited in the number of instant messages that we can send out.

Im’s are a 1:1 medium, im chat rooms are a many:many medium. In theory, a workgroup could subscribe to a chatroom, and as long as a bot held it open, could participate in a messaging medium where you could sent to all of the members of the room as easily as sending one im to an individual. There’s a little bit of hairy code required to make keep everyone in the room invited, which may turn out harder then just running down the list of people who want notification.

I haven’t seen this call in the api, but I suspect that lurking out there somewhere is a Send Message to all buddies method. That would make subscription lists essentially buddy lists, and once again making notification a single sent message.

***The 2k limit.

Aim has a 2k message limit, but we don’t have to be limited to AIM or other size limited channels. We have http. Aim’s strengths are that it’s a lightweight bus for quick messages between entities that are at unknown locations across the net. The only thing that we do know about them is that they have an open tcp/ip connection to AOL’s servers. this implies that the other end most likely has web access of somr form or another.

We can use an out of band data chunk to makeup for the small size limit, at least when sending from radio or a full peer frontier system with the http server running. We can either: upstream the body/attachment to /upstreamBase/imblobs/string.md5(some unique key) or map a url to the body in the frontier case. The other side would see the “big im rpc” message with the associated url, grab the content, and process from there. The hash is so that we can put content in a directory without having others poking around and having a likelyhood of finding anything. If there’s any response, or after some timeout, the sender can drop the link or delete the upstreamable file.

It’s unclear if we’d want to encode this in a im message or a gotourl message (at least from the aim case)

***Isomorphisims

An aimuser/pw/connection thread is similar to a service in user.inetd. User.inetd opens a listener for connections, IM opens a tcp connection then listens for packets from the AIM server.

The various messages that can be sent across (chat room, im, gotourl, etc.) are similar to the get/post/any methods of the http responder. By this analogy, mainresponder.respond is called by the any method of the default responder, the particular on_im_in method would be called by the im responder that picks up the request.

Does it make sense to design the im responder system so that it assumes that it will be trivial to run more than one resonder on different usernames? Prehaps pointing at a different responder table?

If we want the driver structure to take more than one connection in stride, we’re going to want to pass the address of the connection info so that the send method will be sending from the correct screenname. (eg, send(adrData, username, message)). That change is goign to have to percolate through the entire responder hierarchy.

Alternatively, we could set up a page table for the response, and store the pointer there. Any item that really needed to get to the connection info could get it through the pagetable. Or. If the im system needs it, it could set up the page table before calling into the tcp.im.server method. (this is sort of predicated on the threaded response model.)

***The other methods.

Almost all of the work and talking we’ve done up to this point has been on the on_im_in, do_send_im basis. Simple is good, and there is a lot that can be done with these. The other interesting api areas are in the chatrooms. We can certainly program a bot that will enter a chat if invited, or set up a chatroom and invite others.

I’ve updated “Frontier-Toc”. There are some bug fixes and a parsing class for callbacks in this release.

As a demonstration of how to use the system, I’ve got an im-> blog bot (ftocBlogger) that when configured, will route instant messages from an authorized user to your blogger api supporting weblog. You do need today’s release of the ftoc.root. Most of the configuration should be self explanatory if you’ve set up the blogger API before. Oddly enough, There are about as many items of configuration as lines of code.

***Updated

I’ve found an encoding error that was preventing certain common characters (e.g. “) from passing properly, which tended to prevent html from working properly. The fix has been uploaded.

Version 0.21

• 5/10 Fixed encoding error that f**ed up html.

Version 0.2

• 5/10 Added a parsing class so that callbacks can be written using logical parameters, rather than the “data” string.
• 5/10 Added logging levels and took out some of the logging of expected occurances.
• 5/10 Callbacks are now called in a threaded fashion.

No IM development last night, as I got to see the Mariners try to lose a game to Toronto. When the opposing pitcher walks 3 to load the bases, it helps to be able to manufacture a couple of runs out of it. Same for when he pitches 8 straight balls to open an inning.

A little gardening to round out the day. Family and other interested people can check out some more pictures of the new plantings.

I’ve just released Frontier-TOC, a Frontier/Radio Userland tool that implements one of the connection protocols to the AOL Instant Messenger Network.

This is the first release, and as such is still only interesting to developers. It can be useful for writing chatbots and other automated bits. It is not a full chat client.(At least, not yet)

There is a simple echo bot included with the download so that you can see the basics of how to connect and write an incoming IM handler.