by R.I. Pienaar | Nov 6, 2005 | Code
The author of GMapEZ broke backwards compatibility with a recent change, this release will work around that. If you’re maps just wouldn’t display give this one a try.
There is also a new feature that lets you provide multiple extends, if you are upgrading from a previous version your config file needs to change, a new section [extends] has been added, you should also look at the sample index.php to see how to pass multiple extends to the backend.
Using this new ceature you can create one set of map data and one config file but provide different views, see my visited map showing default view and the same map with a view of just South England.
Some changes made to GMapEZ has some positive effects on my library, for one load time on maps with many points are much much faster now and there are also lots more colours to pick from.
I will be helping the GMapEZ author to produce a downloadable package containing all that is needed to self host the GMapEZ library rather than rely on his hosted version, that way I can also certify my code to work with a given version of GMapEZ.
The new version can be found here: http://www.devco.net/code/gmapsphp-current.tgz full documentation for this application can be found here
by R.I. Pienaar | Nov 3, 2005 | Code
Portaudit is intended to run daily against your ports directory identifying known vulnerabilities against a central database. Each night it produce an email that gets sent out and requires inspection.
The problem with this is with many FreeBSD hosts the emails can just be too many and I tend not to look at them.
Portaudit Central provides a means for delivering portaudit output to a central email box which will then produce a simple HTML based report of all machines. You can view a Sample Report produced using these scripts.
The server side script will call logger(1) with some useful diagnostic messages but the lines being logged will include some variables from the environment. I developed this under exim and the environment variables it logs are set by Exim. This will still work under another MTA, the worst that will happen is you’d have some logging entries thats missing details like the sender and message id.
I’ve taken some steps to prevent man-in-the-middle attacks. An attacker can in theory produce a report that says you have no vulnerabilities on a host when in fact you do have some. In order to combat this a few things are done:
- Only 1 report per host per day, any reports after the first one will result in errors being logged, this should be a clear indication that you’ve either configured multiple clients with the same $hostname or someone is up to no good.
- Each email being sent has a very simple crypto signature, the signature is basically a MD5 hash of the body of the message and a passphrase md5(body, passphrase) this means as long as your passphrases are secure – they aren’t being sent along in the email so no-one can sniff them – someone else should not be able to produce a report that will pass this check regardless of report content. Even if your passphrase gets compromised you should be alerted about tampering by the log entries produced by the duplicate checking mechanism above. As long as you monitor your log files.
I’ve used this system myself now for around a month and have been quite happy, but no-one else has had a look at it yet so I’d appreciate feedback if anyone use it. In the future I hope to make the output from the report generator themed, right now it’s very ugly but it does what it should. I will also move to a actual configuration file rather than editing some perl variables. I’m open to other suggestions.
Version 1.0 can be downloaded here: portauditcentral-current.tgz the full documentation including installation instructions can be found at the Wiki
by R.I. Pienaar | Nov 1, 2005 | Code
I run a number of jail on my servers and each of these have the same files over and over, the biggest problems are of course /usr/ports and /usr/src, they’re a total waste of space and a lot of work running multiple portsnap’s etc to keep them all synced.
BJE mentioned he is using nullfs to mount his main /usr/ports into the jails. I did some hunting of information on this and found its a bit thin on the ground, the main reason is that up till 6.0 it’s considered broken, though testing shows it works ok, at least for normal use.
FreeBSD 6.0 will have extensions to its rc.conf to make all of this easy.
You can create per-jail fstab files, by default they are stored in /etc/fstab.jailname but you can override the filename using jail_example_fstab. Below is a sample fstab file for one of my jails:
/usr/ports /jails/example/usr/ports nullfs rw 1 1
/usr/src /jails/example/usr/src nullfs ro 1 1
To enable the mounting of these file systems at boot time if you use the rc.conf method of booting your jails simply add a jail_example_mount_enable=”YES” to your jail section. A full rc.conf extract to start one example jail below:
jail_enable=”YES”
jail_list=”example”
jail_socket_unixiproute_only=”YES”
jail_sysvipc_allow=”NO”
jail_example_rootdir=”/jails/example”
jail_example_hostname=”example.com”
jail_example_ip=”192.168.1.100″
jail_example_exec=”/bin/sh /etc/rc”
jail_example_devfs_enable=”YES”
jail_example_fdescfs_enable=”NO”
jail_example_procfs_enable=”YES”
jail_example_devfs_ruleset=”devfsrules_jail”
jail_example_mount_enable=”YES”
I’ll investigate also sharing /bin, /sbin, /lib, /libexec, /usr/sbin, /usr/sbin and a few others between jails but it gets a bit tricky if you want to install other versions of perl from ports since they maintain symlinks in /usr/bin etc. This could however simplify world upgrades a lot.
While researching this I came across ezjail which is a script compatible with FreeBSD 6.0 and later to maintain jails that uses nullfs extensively to share a lot of directories from a base jail install. This gives a big potential security improvement because you can mount the system directories read only to give further protection in the event of a compromise. Will definitely investigate this before I start building my new hosted server once FreeBSD 6.0 is out.
by R.I. Pienaar | Aug 30, 2005 | Code
The sample data provided with my 1.0 release of GMaps PHP had a mistake in the config file which rendered the sample useless.
I’ve fixed this and also added a <comment> tag to the XML data file that will be shown at the locations. A full valid point in the XML file now looks like this:
<point>
<lat>-34.01715</lat>
<long>23.07238</long>
<type>visit</type>
<title>Knysna</title>
<country>South Africa</country>
<comment>Holiday during school years</comment>
</point>
The new version can be found here, full documentation including these changes can be found here.
Thanks to BJE for pointing this out.
by R.I. Pienaar | Aug 21, 2005 | Code
I’ve kept a map of my travels since around 1999, I used to use the now defunct PARC Xerox Map Viewer, when that went away I started just projecting dots onto XPlanet maps to produce a static map.
Ever since Google introduced their Google Maps system a number of mapping tools became available, dedicated blogs have been written like the very good Google Maps Mania and I’ve been thinking of trying to do my map using that instead.
Gary got hold of some code which got me going but it was a bit of a PITA so some searching brought me to Google Maps EZ which is basically a javascript library that takes standard HTML HREF’s and turns them into points etc, very easy to use.
My problem was still that maintaining data in a html file of HREF’s isn’t exactly what I had in mind, I was more partial to a XML file like the sample below:
<points>
<point>
<lat>-33.9333</lat>
<long>18.4667</long>
<type>lived</type>
<title>Cape Town</title>
<country>South Africa</country>
<href>http://flickr.com/photos/ripienaar/tags/capetown/</href>
<linkimg>images/19591136_35a14f6d58_s.jpg</linkimg>
</point>
</points> |
<points>
<point>
<lat>-33.9333</lat>
<long>18.4667</long>
<type>lived</type>
<title>Cape Town</title>
<country>South Africa</country>
<href>http://flickr.com/photos/ripienaar/tags/capetown/</href>
<linkimg>images/19591136_35a14f6d58_s.jpg</linkimg>
</point>
</points>
This contains a lot of information, the type of visit I made to the location, links to my images taken there, a thumbnail to show for the links etc it wouldn’t be great to automate the parsing of that to output the HTML for GMapsEZ?
So that is exactly what I wrote. My script takes a simple configuration file like the one below:
[map]
data = visited.xml
type = map
extend = "http://maps.google.com/maps?ll=51.964577,-1.241455&spn=3.460112,7.639893&hl=en"
width = 350
height = 200
showcountry = 1
showtype = 0
[controls]
mapctrl = 1
typectrl = 1
scalectrl = 0
size = small
[types]
visit = orange
transit = blue
lived = green
[misc]
gmapez=http://www.devco.net/visited/gmapez.js
apikey="mykey" |
[map]
data = visited.xml
type = map
extend = "http://maps.google.com/maps?ll=51.964577,-1.241455&spn=3.460112,7.639893&hl=en"
width = 350
height = 200
showcountry = 1
showtype = 0
[controls]
mapctrl = 1
typectrl = 1
scalectrl = 0
size = small
[types]
visit = orange
transit = blue
lived = green
[misc]
gmapez=http://www.devco.net/visited/gmapez.js
apikey="mykey"
By calling the script I wrote and passing the config file as argument it will produce all the HTML GMapsEZ needs to do its magic.
<?
require_once("gmap.inc.php");
print(getGMapEZ("smalldemo.cfg"));
?> |
<?
require_once("gmap.inc.php");
print(getGMapEZ("smalldemo.cfg"));
?>
And this is the map it will produce, this is just a screenshot of the final result, see below the image for a link to the full working page.
My full working version of the map can be seen here, it’s the same data as above just a much bigger map, bigger controls and a different extend. The only actual difference are some changes to the config file, same data and same PHP code was used.
I’ve set up a Wiki to maintain documentation for this as it matures over time, I will make announcements of new features on this blog, but the Wiki will be the resource that contains a always up to date reference to features and installation. You can read about obtaining, configuring and using this script there.
by R.I. Pienaar | May 25, 2005 | Code
I did some more testing with the code I posted yesterday and found it isn’t 100% compatible with some unzip programs. Works with unix unzip, Mac OS X default tool, WinZip, WinRAR but annoyingly not with the default XP zip folder thing.
The problem seem to be 4 rogue bytes that gets inserted somewhere. So back to Google, eventually I found a much better library at PHP Concept Library Zip. It works more or less the same, except you must pass it files to add instead of just data in variables, either works for me.
Some sample code:
require ("incl/pclzip.lib.php");
$zipfile = new PclZip('zipfile.zip');
$v_list = $zipfile->create('incl/pclzip.lib.php');
if ($v_list == 0) {
die ("Error: " . $zipfile->errorInfo(true));
}
header("Content-type: application/octet-stream");
header("Content-disposition: attachment; filename=zipfile.zip");
readfile("zipfile.zip");
This one works with every unzip tool I’ve tried, Windows, OS X, command line unzip etc. It also has decent error reporting etc.
