[Xastir] The future, how soon? B-)

[Gerry Creager n5jxs]

Curt, WE7U wrote:
> On Sat, 26 Jun 2004, Aaron May wrote:
> 
> 
>>Lets have a command line parameter that turns off the interface for the
>>current xastir, then we have a very clear migration path.  All the good work
>>currently happening in xastir continues, xastir slowly becomes xastird and we
>>tack on a storage module. (initially just a crude interface to a virtual map
>>file or something to get us started)  After that its a simple matter of
>>exposing a socket and a request/response mechanism Then I get to write my
>>Visual Basic Xastir Client!! :-)
> 
> 
> Hmmm, maybe all this is NOT such a good idea.  hi hi.
> 
> Having a command-line parameter for this would be a start, but
> eventually we'd want a stripped down xastird that doesn't have all
> the fluff so that it can run efficiently and be a small executable
> image.
> 
> 
> 
>>Maybe xastir never totally looses its interface, thus we can run it as an app
>>on a laptop and in daemon mode on a server?
> 
> 
> We could certainly create one that could be compiled with either
> method.  Might be best though to separate out the functionality into
> separate files.  Try to keep the #ifdef's to a minimum so that the
> code is maintainable.
> 
> 
> 
>>Base security on a host and a username/password for clients connecting to
>>xastir.  Allow different users and groups to have different host limits.
> 
> 
> Limits might be done with tcpwrappers, right?  You can also limit
> who connects from what site that way, making some of the security
> problems go away.  I was actually thinking something more along the
> lines of SSH for connecting, which should provide excellent security
> but is probably overkill.

I've already seen concerns about encrypted protocols.  I do NOT see that 
as a long-term obstacle to inter-computer communications.  More to the 
point, I believe the US FCC will allow strong encryption tools sooner 
rather than later in the Amateur Service, to allow us to preserve our 
role in emergency communications.

Open passwords are *not* acceptable.

I also like the hosts.allow/hosts.deny model for authorization...


>>Xastir is run in daemon mode.  It opens a listening socket.
>>
>>A client program attempts to connect to xastird. Xastir checks the ip address
>>against the defaults in the access file and accepts it.
>>
>>A username/password pair is provided by client. Xastir checks this against
>>users.  If the password matches, each of the groups belonged to is checked to
>>ensure that the host is permitted. (A user who is a member of Admins may be
>>denied unless the client is running on the localhost.)
>>
>>A client requests a map image sourced from a combination of map data from
>>public and private storage areas, and the aprs/opentac data overlaid. Xastir
>>passes the username/password for the requesting socket to the Storage Module
>>and requests the data for the specified area and timeframe. Xastir builds the
>>map and sends it to the client to display.
> 
> 
> Ok, you're assuming a single xastird daemon is the traffic cop for
> the system.  We could do that, or we could split xastird into two
> daemons, xastird which only talks to the storage module, and
> xastir-clientd which services clients, talks to the storage module
> and perhaps directly to xastird as well.  The second configuration
> would allow us to have a very lightweight configuration on the
> server, just xastird and the storage module most of the time when
> clients aren't needed.

I'm not sure multiple performing daemons is the way to go.  I've 
problems with interdependent daemons and less than graceful exits of the 
remaining ones, when something dies unexpectedly.  I'd prefer a slightly 
more complex superdaemon, or something in the xinetd flavor that can 
keep track of various sub-daemons and kick them when they stumble.

>>The user opens the Interfaces dialog on the client app and the client requests
>>a detailed list of interfaces.  It parses the response and presents the user
>>with the result. If the response indicates access, the user may click a
>>button beside a given interface to start/stop the interface. The client app
>>would then send a request. Xastir would check the username against the access
>>specified in the interface definition, and action the request if permitted.
>>
>>What have I missed?
>>
>>A question from me; it seems that xastir and many other linux progs are
>>written in C rather than C++. Why?  While I make a living from MS VB,  I am
>>inspired by what you  have achieved with xastir, to the point where I am
>>slowly teaching myself a 'real' programming language.  Doesn't C++ offer
>>more? Are there platform, speed issues or what?

C vs C++ is a religious discussion rather than a technical discussion. 
I might point out that Barjne Strarstrupp taught Java this past year 
here...  Good programmers already engage in code reuse and some degree 
of object orientation and persistence regardless of the language.

> I tried some time back to ask for a switch to C++ or Java.  It
> appeared to fall on deaf ears.  The original app was written in C
> and I think most of the developers had experience in C, but not the
> others.
> 
> This may be time to switch to something else.  Then again, may not.

At the risk of getting hammered, Java will result in a slower daemon app 
overall; C++ is do-able but will require some paradigm shifting and 
religious modification for those not already so engaged...

Gerry
-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843