[MLB-WIRELESS] seeing connected nodes
Steven Haigh
netwiz at crc.id.au
Mon Aug 6 16:04:27 EST 2007
On 06/08/2007, at 3:13 PM, Jason Hecker wrote:
>> Are there any plans for bring this back? I assume there are
>> technical
>> limitations.
>
> Ohhh, this sort of thing takes time. I am sure someone can code it up
> over the course of a few evenings.
Probably. I'll set a bit of background history to explain what the
changes are and why they've been made - as this can probably all be
blamed on me ;)
The last revision of the wireless.org.au server was based on Fedora
Core 4. This has a life-span for security updates etc of about 12
months. After that, there are no security updates, no updates, no
nothing. The advantage of this however is that mapserver RPMs were
available for this distro! The down side about all this however is
that it locked us into certain library version and packages that we
really needed to upgrade to keep the system stable and secure.
The new server revision is built upon CentOS 5. CentOS is the
community edition of RedHat Enterprise Linux (RHEL). The CentOS team
take the source RPMs that RHEL uses and rebuilds them into a
distribution - and in the process, change all references of RHEL to
CentOS for legal reasons. The RHEL support timeframe for security
updates and maintenance is 5 years. From my point of view, this is
excellent - as we have 5 years to plan our next updates in a worst
case scenario. The upgrade path between revisions of RHEL is
excellent. The path is well tested on release, and is well supported.
This means I don't need to rebuild the entire server every time we
need to upgrade the OS.
Where this turns bad is that to make this all work correctly, we need
to stick to packages in the RHEL or well supported software repos
(such as RPMForge). As you guessed it, mapserver doesn't have any
RPMs in either RHEL or RPMForge - so it needs to be built from
source. Now to make sure we keep the server clean and crud free (ie I
don't want to rebuild it in 12 months time!), I've asked the dev guys
to put all the mapserver stuff in the common melbwireless home
directory. I've also suggested that the mapserver binary be built as
a static binary - so upgrades to server libraries will not cause the
mapserver to break. I guess my aim is to separate system stability
from mapserver stability and keep them both running under most
situations. This is pretty difficult, as mapserver is not the easiest
application to build. It has a lot of dependancies, and a lot of
twists and turns to get where we want.
There are a number of pros and cons about using google maps for the
node maps.
Google maps:
+) CPU/bandwidth requirements are shipped to google.
+) Mapping data is freely updated (we don't have to pay!)
+) It's very feature rich
-) We lose existing feature sets
-) Development time increases greatly
Mapserver:
+) We get full control over map appearances
+) We can do overlays for linking data
+) It should just work with existing site code
-) We have to try to acquire updated mapping data
-) mapserver is a pain to build and update
-) Very time consuming to get right
This is my insight into the whole maps issue. Feel free to ask any
questions :)
--
Steven Haigh
Email: netwiz at crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9017 0597 - 0404 087 474
More information about the Melbwireless
mailing list