Easy PXE Network boot

I had been meaning to set up a network boot system for FlingOS for a while. Yesterday I finally got around to it and after several hours of trying different software and solutions, I finally found one which worked nicely.

I had been meaning to set up a network boot system for FlingOS for a while. Yesterday I finally got around to it and after several hours of trying different software and solutions, I finally found one which worked nicely.

There is a modest selection of software out there which will let you set up PXE Network booting. The majority of it focuses around Windows installation and updating. What I needed was a system that would allow me to switch on any network-connected laptop and have it boot the latest version of FlingOS that I just compiled on my PC or main laptop. FlingOS already uses Syslinux as its bootloader so it made sense to use the Pxelinux variant of Syslinux. Unfortunately, Pxelinux requires something that most PXE Server programs don’t support – something called the tsize command.

PXE relies on a combination of DHCP, Binl and TFTP to allow a PC to detect the availability of a PXE server and to retrieve the boot image(s). Pxelinux requires that the TFTP server supports the unusual tsize command. “tsize” allows Pxelinux to request the size of a file ahead of time i.e. before it starts to retrieve it.

After various attempts using Serva and other software, I came across TinyPXE. Finally something that would work. TinyPXE was written by a guy who needed a simple, effective, no-install solution to running a PXE server. Perfect. It even comes with support for Pxelinux, Grub and others. What’s even better, is that it can auto-load everything from a human-readable config file. So once you’ve worked out what setup you need, you can just put it in the config file and never have to worry after that.

Here’s a copy of the contents of my config file (config.ini):

[arch]
;will over rule the bootp filename or opt67 if the client arch matches one of the below
00006=bootia32.efi
00007=bootx64.efi
[dhcp]
;needed to tell TFTPd where is the root folder
root=G:\Fling OS\Fling OS\Kernel\Kernel\bin\Debug\DriversCompiler\ISO
;bootp filename as in http://tools.ietf.org/html/rfc951
;filename=ipxe-undionly.kpxe
filename=pxelinux.0
;alternative bootp filename if request comes from ipxe or gpxe
; altfilename=menu.ipxe
;start HTTPd
httpd=0
binl=1
start=1
dnsd=0
proxydhcp=1
;default=1
bind=0
;tftpd=1 by default
;will share (netbios) the root folder as PXE
smb=0
;will log to log.txt
log=0
opt1=255.255.255.0
opt3=192.168.43.1
opt6=192.168.43.1
opt28=192.168.43.255
;opt15=
;opt17=
;opt43=
;opt51=
opt54=192.168.43.120
;opt67=
;opt66=
;opt252=
poolstart=192.168.43.121
poolsize=20
;alternative bootp filename if request comes thru proxydhcp (udp:4011)
;proxybootfilename=
;any extra dhcp options
;my gpxe / ipxe dhcp options
optextra=175.6.1.1.1.8.1.1
;the below will be executed when clicking on the online button
;cmd=_test.bat
;if log=1, will log to log.txt
log=1
[frmDHCPServer]
top=441
left=258

Google Analytics spam data

I’ve been using Google Analytics on the FlingOS website for over 6 months now and while it is very good at tracking, with low-volumes of requests most of the tracking data is rendered useless. Spam websites such as free-social-buttons.com, ilovevitaly.com and simple-share-buttons.com log between tens and hundreds of requests per month. This leaves the remaining statistics heavily skewed.

These sites are performing these spam requests in an effort to get their referrer in your analytics list. This is in the hope that unwise web-admins will go to the referrer URL to see what is causing the traffic and then fall foul of the spoof sites which are there. These sites are distinct from auto-bots or search-engine crawlers in two primary ways. One is that crawlers don’t leave a referrer and often use a non-standard browser (or at least user-agent). Crawlers are not trying to pretend they are humans nor hide themselves. Crawlers also pay attention to do-not-follow headers, site maps and robots.txt files and so leave far fewer requests. Lastly, most crawlers are detected and automatically filtered by Google Analytics (based on the user-agent or other more sophisticated mechanism).

In an effort to reduce the level of spam, I switched on IIS’s IP blocking and reverse looked-up the various spam website’s IP addresses. This was, as it turns out, very effective. The number of visits with the targeted spam referrers almost entirely disappeared. Unfortunately, spam websites are relentless and as soon as you’ve eliminated one, another appears. I found myself endlessly updating the IP address block list. This is both tedious and dangerous because over time IP addresses shift, so the filter can potentially end up blocking genuine requests.

So how do I solve this problem? I don’t know! If you have any ideas, please let me know by commenting below or emailing me directly at flingos@outlook.com.