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

[Aaron May]

Yippeee! The future is comming...

On Friday 25 June 2004 04:52, Curt, WE7U wrote:
> On Sat, 12 Jun 2004, Jeff Brenton KA9VNV wrote:
> > So, what I'm REALLY wondering is, "Just how far is Xastir from having a
> > daemon-capable part that monitors interfaces, collects and stores data,
> > and feeds it to the APRS RF and internet networks, and a separate client
> > to display it?" I.e., how soon before I can put a ITX board with CF disk
> > running Linux+Xastir next to the transmitter, and everything else on a
> > workstation elsewhere?

I am in a similar situation, my weather station hooks into xastir on my server 
PC, which beacons the data to RF.  I would like to access xastir from a 
workstation, etc, show multiple maps etc.
<snip>
>
> I've been moving this along in my INBOX so that it didn't get
> forgotten.
>
> Yes, you're right, it has been discussed several times over the last
> two or three years.  I'm often the one bringing it up.  It usually
> gets talked about for a bit, then forgotten again, as the developers
> get busy doing other things.  It would take a major effort to break
> away from the bug-fixing and the adding of yet-another-feature in
> order to start on version 2.0.  It needs to be done though.
>
> Here's what I currently envision:
>
> *) xastird. 
> *) Storage module.  This can be flat files, db files, SQL Database.
> *) Map import module.

> *) Map and Message client. 

Combined, or separate.  Lets get the first three going and I suspect a hundred 
clients will spring up, each with slightly different colours and flavors.

> We could separate out the various types of interfaces in xastird,
> but I don't currently see a need to do so.  I think one monolithic
> piece for that might make sense, at least for now.  Because that
> stuff is multi-threaded though, it could make some sense in the
> future to fully separate them into different processes.
>
> I think where we left off last time was that I was going to try to
> separate out the interface stuff from everything else.  I never
> found the time to do so.  I would think that to be a logical first
> step, then try to separate out the storage from everything else.
> Once that is done, we can try to make the storage piece into
> something that would work for multiple storage methods.

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!! :-) 

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?

> One big question in my mind is security:  How do we connect all
> these pieces on the same machine or on different machines yet keep
> unauthorized people from messing with them?  We need a method that
> works across all platforms.

Base security on a host and a username/password for clients connecting to 
xastir.  Allow different users and groups to have different host limits.

Xastir would have to trust connections to interfaces such as TNC and weather 
stations that are specified in the config file.  Interfaces would only be 
created by editing the config file, or in the longer term, an authenticated 
xastird client. 

There is no way to tell if a socket defined as a networkWX on another host is 
the weather daemon or something else. We would just have to check the 
incoming data matches certain rules before being processed.

A username and a (hashed) password allows for user permissions. Each group of 
users would have permission to access various functions.  Each module would 
have different functions.

As an example, I see the storage area broken into public and user areas (like 
virtual directories in apache, each with accept/deny and user lists), or map 
directories in xastir currently). A given user, once validated by the storage 
module would be able to store maps within his personal (if granted one by the 
admin) area, but still read from the public area. Another user would have the 
ability to write and delete in the public area. 

So try this...

### /xastir/access.conf

<default>
  Accept localhost
  Accept 192.168.0.0/24
</default>
<Group>
  Name=Administrators
  Accept=localhost
  Deny=All
</Group>
<Group>
  Name=Users
</Group>
<User>
  User=Aaron
  Password=hashed string
  Groups=Administrators, Users
</User>

###/etc/xastir/storage.conf

<StorageFolder>
  FolderType=PacketStore
  DataType=gdbm
  DataPath=/usr/share/xastird/packets.gdbm
</StorageFolder>

<StorageFolder>
  FolderType=MapStore
  FolderName=Xastir Maps
  DataType=gdbm
  DataPath=/usr/share/xastird/publicmaps.gdbm
  AllowReadWrite=Administrators
  AllowReadOnly=Users
</StorageFolder>

<StorageFolder>
  FolderType=MapStore
  FolderName=Personal Maps
  FolderType=MapStore
  DataType=gdbm
  DataPath=/home/aaron/.xastird/mymaps.gdbm
  AllowAll=Aaron
</StorageFolder>

###/etc/xastir/xastird.conf

<Interface>
  Name=Command
  Type=Command
  Port=8000
</Interface>

<Interface>
  Name=Radio
  Type=SerialTNC
  Interface=/dev/ttyS0
  AllowStateChange=Administrators; Users
</Interface>

<Interface>
  Name=Aarons Weather Station
  Type=WX918
  Interface=localhost
  Port=9873
  AllowStateChange=Administrators
</Interface>

<Interface>
  Name=Web Port
  Type=HTTPRequestHandler
  Port=81
</Interface>

How this would work....

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.

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?

Cheers,
Aaron ZL3AR.