
Duncan Farnworth
dunc at rumbletum.org
Overview
The digital system allows the display of advertising or information from the video output of a PC usually connected to a large screen in public view.
The system is divided into separate logical parts;
The Player
Usually a PC located in a remote location and connected to a plasma or projection screen.
Some network connection (ISDN, Modem or Ethernet) to/from the management server is needed
Able to play most video formats, HTML pages and Flash 6
The Control Server
Centrally holds all the media to be used by the players
Holds a database of play lists to control which ads get played on which players
Retrieves and processes data feeds for news, announcements, etc
Holds a mirror of each player’s content, ready to be synchronised with the remote player machines
Transmits content to player machines via TCP/IP
The Network
Using IP (Internetworking Protocol) for flexibility and compatibility
Using a router with ISDN, Modem and Ethernet connections to each player machine. Automatically routing data to players and hiding complexities of each connection from the server.
Running a name service on the router
Providing internet access for the collection of feeds and office web browsing
The Management Console
A Java application able to run on any platform with a Java virtual machine and an IP connection to the database on the server
Allows the loading of content into the system
Allows editing of the database
Edit data about each player machine
Edit records for each advert and resources they require
Edit and assemble play lists of adverts
Create a queue of updates to be sent to the players
Contents
The Player | |
Hardware | 4 |
Operating System | 4 |
Installed Software | 4 |
Display Configuration | 5 |
Networking | 5 |
Content / Media Types | 6 |
Building A Player | 7 |
The Server | |
Hardware | 8 |
Operating System | 8 |
Installed Software | 8 |
Configuration | 9 |
The Database | 10 |
The File System | 12 |
Database Synchronisation | 14 |
Data Feeds | 15 |
Synchronisation With Players | 16 |
Log Files | 17 |
Building a Server | 18 |
The Network | |
IP Numbering | 19 |
The Router | 20 |
PPP over ISDN | 22 |
PPP over modem | 23 |
Ethernet | 24 |
The Internet | 25 |
Building a Router | 26 |
The Console | |
Requirements | 27 |
Player Machine Records | 27 |
Advert Records | 28 |
Advert Resources | 28 |
Play lists | 29 |
Controlling updates | 29 |
Support | |
Internet Resources | 30 |
CDs | 31 |
Developers | 31 |
Unix Cheat Sheet | 32 |
The Player
Using a PC with a minimum of P3 800MHz with 256MB of Memory. The hard disk ideally 7200rpm of at least 10GB.
To keep things running well a BIOS which supports “Resume on Power Fail” and “Wake on LAN” or “Wake on Modem Ring” is very handy if there are any power cuts. Also have resume on ALL IRQs enabled!
Set the BIOS to resume on Alarm at 12:00 midday on month 0 or NA and day 0. This means that if the machine is off for whatever reason then it will start up at 12 on any day. This can save on long journeys to Cardiff or East Midlands Airport!
Configure the Hard Disk Parameters directly into the BIOS instead of auto detect. Just to boot quicker.
Depending on how you wish to connect this machine you need a hardware modem (NOT soft modem) or ISDN card (Generic w6692 work well for me) connected to a line with a distinct phone number to receive incoming calls. Or you can connect via Ethernet to another machine with dial in access or directly to the server’s network.
The favoured graphics card is Matrox G4/500 series. They’re good cards and have excellent support from linux. The Dual head versions can be useful.
Linux Mandrake version 8.2 has worked well for me. Kernel 2.4.18 Try www.mandrake.com for download sites. I’d get the ISO image if I were you.
Install as little as possible.
Any version of Linux, or FreeBSD (Providing you get or make the right binaries for the programs) should in theory do the job but these docs are tried and tested for Mandrake 8.2
Mplayer to play video
Win32 codecs allowing mplayer to play AVI and WMV
Isdn4linux for ISDN connectivity
Xwit to move the mouse pointer out of view
PPP for modem connections
Ending(.c) for identification of files by their extension
Plasma script to read playlists and invoke opera or mplayer
Xholder to keep the X server going and set the background to black and pointer to the bottom right corner.
Rsync daemon to allow content updates buy sending changes, not whole files.
Display Configuration
Select the monitor as “Generic VGA that can do 640x480” This allow display on almost any kind of screen no matter how low it’s sync rates are.
Select resolution of 640x480
Select Colour Depth of 24
Say that you DO NOT want X to start automatically on boot.
If you’re using a Matrox card, Install their HAL library to make dual head and some more features available
Install Matrox power desk from their rpm then type “mgapdesk” and configure the screen to maximum colour at 640x480, with dual head clone enabled.
Make sure that Opera has it’s config file (/.opera/opera6.ini) changed to show at 640x480 with black background
/etc/mplayer/mplayer.conf can be edited to support dual head by changing the vo option to X11, fs to yes and zoom to yes. If you’re using single head leave it alone because it runs faster with it’s default.
If you have a network card installed, set the IP number and hostname when you install Mandrake.
DO NOT configure ISDN cards with the installer, just note the card type it auto detects for later.
If you have only an ISDN card, use the ioptions.ippp0/1 file to set the IP with a line like 192.168.3.202:192.168.2.2 where the first is the player’s IP and the next is the office router’s IP
Make the /etc/ppp/pap-secrets file contain the ppp login ID. Make a user account for it if you want to use the login option of ppp. (good idea) Set the secrets file to mode 600
Add a line to /etc/inittab to run once only the isdn init script, /root/start. The script provided expects a w6692 ISDN card but change the line where it loads the hisax driver to the type of your card if different.
Edit inetd or xinetd configurations to start rsync as a daemon
Configure /etc/rsyncd.conf to share /plasma with a secrets file /etc/rsyncd.secrets. That should contain only one line: user:password in plain text. Keep it all secure with chmod 600 /etc/rsync*
Content / MediaTypes
Mplayer plays video from start to finish. The ideal format would be a video at 640x480 (so we don’t need to resize as we play = QUICKER) with no sound (Small file). Codecs are available for almost everything with the notable exception of quicktime .mov files. See the mplayer docs for info.
Everything else if played through Opera. The content needs to be inside a html page. The page can contain flash or not.
For flash files, The size is 640x480. Try and make them fade in from and out to black. Put action scrips at the start to hide the mouse pointer (mouse.hide()) and at the end to close the opera browser so we can play the next advert (getURL(“javascript:window.close())) If you generate an HTML page from flash, edit it so that margins=0 in the BODY tag. Make the bgcolor=”#000000” if you don’t use the full screen space with flash.
The key thing to remember is to call javascript:window.close() when the ad is finished. Do this from Flash or Javascript code in the HTML page with some timer code.
Resources of two types are used by the adverts (an advert is a video file or an HTML file). There are “res” which are usually flash files and are stored in a sub directory called res. This means when you include the flash in the html file it sould be src=”res/myflash.swf”
Data resources are the other type and are stored in a sub directory called data. You can use this for news and data feeds. Load data into flash with loadVariables(“data/mydata.txt”) or include data in your html page.
As the system currently stands, the most likely cause of problems is when a flash file is not found and opera does not close it’s window == blank screen or error message. Take care… Or build a javascript:window.close() failsafe into the html.
Building a Player
This is not so hard if you use the Mandrake installer and Plasma Player Build CD.
Install Mandrake with the following partitions:
/boot | Small 100MB partition |
swap | Usually double the RAM size (512MB) |
/ | The remaining space on the disk |
Set security to standard
Install Multimedia, Network Client, Configuration Tools, Development Tools and Docs if you have space. Also Network Server if you want it to be a gateway for some other player.
Choose individual Package selection the install from the server section the WU-FTPD and SSHD services.
Allow the system to install.
Set the root Password
Add a user “plasma” which will be used for ppp dial in, ftp transfers and rsync transfers.
Configure X as described earlier paying particular attention to the monitor type. Remember to set it to Generic 640x480 screen so it works with plasma and projector screens, which use lower sync rates than PC monitors. You most definitely DO NOT want to start X automatically when the system boots.
Configure services so that rsyncd is started automatically.
Allow the installer to complete and then wait for Linux to boot for the first time.
Log in as root with your password as set before.
Type “cd /mnt/cdrom” after inserting the player build CD.
Type “./install.sh” and say yes when required then wait untill X starts
Type “mgapdesk” to configure Matrox card specific stuff for X (Dual Head Clone)
Type crontab –e as root and insert a line to reboot at midnight every day:
00 00 * * * /sbin/shutdown –r now
Reboot when it’s done and then Hurray! You have a plasma player!
Read the install.sh script or CD info section, later on, to understand the details of the installer.
The Server
This machine is the heart of the system. It’s more of a central control machine than a server. I say server so I can use some technological buzzwords.
Find as fast a PC as you can get then put as much memory in it as you can get. Install a 100MB-network card and some big hard disks.
The same as any server… build it as big and fast as you possibly can.
Graphics card does not matter.
Again with the BIOS, try and find one that will re start the PC after a power failure. If this one stops, you will not be happy.
A tape drive or some kind of backup system will let you sleep easy.
samba-2.2.3a-10mdk
To allow Windows PCs in the office to share files and print
postgresql-7.2-12mdk
Our choice of database.
postgresql-jdbc-7.2-12mdk
JDBC driver for above
Pgaccess
An idiot proof database manager. Good for database set up.
j2sdk1.4.0
Java
j2sdkee1.3.1
Java Enterprise Libs
Rsync
To send update out to the players
Sshd
Remote access
wu-ftpd
File transfer daemon of the WU variety
/plasma/*
Scripts and files to run the ad system
Configuration
The following services should start at boot time: smbd, postgres/postmaster, sshd, ftpd, /plasma/bin/syncer
The real works of the system are in the /plasma directory.
This is divided up as so…
/plasma/bin/
fixmenfeed - Fixes the XML from the MEN so it’s valid
mkplasma - Creates a directory for a new player machine
pingtest - Tries to ping all machines for diagnostics
sync - Sends data to a particular machine
syncer - Runs the java to sycronise the DB with the filesystem
men - Converts the MEN feed so Flash can read it
news - Converts the BBC Ticker Feed for Flash then sends it out
sendcontent - Sends content to all machines (old)
syncall - Sends everything to all machines (old)
/plasma/main/
/plasma/$playername
/plasma/log
sync.log - Output of the sync command.
See transfers as they happen
/plasma/feeds - Raw feed data before it gets converted used by the news, fixmen and men scripts
Install the plasma directory from CD
The file smbd.conf file for samba should share home directories, the /bambi directiory (shared files) and /plasma/main for content updates from the windows clients. Share a printer too if you like.
The only important networking issue is that the default gateway is the router machine and that you can ping any workstations that want to connect to the database.
T
he
Database
The database in held by Postgres SQL and is accessed using SQL through Postgres’s JDBC driver.
There should be no reason to edit the database directly. It is expected to be edited and updated only by the Management console and the Database Synchronization service.
Each player machine to be controlled has an entry in the machines table. The most important fields here are machine_id, name, playlist_id and connection_name. Each machine plays only one specific play list. The connection name is the DNS name for the machine and the name it’s directory in the /plasma/$playername directory on the server.
A
play list groups together a list of adverts in a particular order and
take a file name, allowing a text file to be generated containing a
list of all the ads to be played.
An advert is a reference to a piece of media content to be played on the system.
It has a file name which refers to either a movie or HTML file held in the /plasma/main directory. Adverts do not live forever so it has a start and end date or a Boolean to say if it should be allowed to be played at any time.
In the case of a flash advert, it will have an .swf component needed by the HTML file. This is known as a resource and will be held in the res directory.
If we want to show changing messages on our screens, it would be easier to upload a small text file rather than a whole new ad each time we want to change it. This text file would be a data resource, held in the data directory.
With all data about machines, playlists, adverts and their resources collected together we know which ads to play on which player machine in which order.
We just need a way to send the data out to the players. This is done with the transfer table. Specify which machine is to be updated and what is to be sent in this table. We can send everything, just the playlist, just content, just data feeds or resources.
The database synchronizer looks at the database and changes the contents of the /plasma/$playername directories to reflect the data. It will then look at the transfer table and treat it as a job queue, sending updates to each machine as required.
The File System
In the /plasma directory, all of the content that can be sent to each machine is held in the main directory. These are often very large video files which would eat up disk space if we kept multiple copies of them. To syncronise with the player machines, we need a directory containing the files it needs. That’s one directory for each machine but not duplicating large files on the server.
So what I’ve done is create a directory for each machine with soft links for each required file linking to the main directory. Here is an example of a simple main directory
/plasma/main
playlist/
testplaylist.play
otherplaylist.play
t1.play
t2.play
transfer/
content/
ad_one.mpg
ad_two.mpg
ad_three.mpg
flash_ad1.html
other_ad.avi
someothervideo.wmv
news.html
sport.html
res/
news.swf
sport.swf
flash_ad1.swf
data/
newsfeed.txt
sportfeed.txt
nopoint
xholder
ending.c
ending
plasma
Now consider a machine called bambidev. It is set to play the play list testplaylist.play which contains the ads, ad_two.mpg, news.html and someothervideo.wmv. news.html has a flash resource and a data feed resource.
The Database Synchronizer works out the dependencies and what files are needed by this computer and creates a few links in the directory /plasma/bambidev and it looks like this:
/plasma/bambidev
playlist/
testplaylist.play
transfer/
content/
ad_two.mpg
news.html
someothervideo.wmv
res/
news.swf
data/
newsfeed.txt
nopoint
xholder
ending
plasma
Each file here is actually a soft link to the corresponding file in the /plasma/main directory.
The playlist directory will only ever contain one link to the playlist specified in the database.
The transfer directory is a link to the actual transfer directory in the main directory. This allows for convenient file transfer to every machine for admin purposes.
The content directory and it’s subdirectories are links to ads in the main directory, selected as a result of the content of playlist and the resource dependencies of each advert.
The last 4 files are links to the scripts that run the player. They are here to allow easy changes on every machine.
This file system structure is now ready to be synchronized to the /plasma directory on the remote player machine. /plasma/$machinename is equivalent to rsync://$machinename/plasma
Database Synchronization
When there are jobs in the queue, it deletes the links and play lists from each of the machine directories and then generates new ones to reflect any changes that were made in the database.
When all is ready, it calls the script /plasma/bin/sync with arguments of machinename and tranfertype. This script then pings the host to open up the network link to it and then runs rsync to syncronise the machines’ directory on the server with it’s own /plasma directory. Instead of sending the links, rsync is set to send the file which has been linked to. I.e. the real file in the main directory.
After each transmission, the links are re made to allow any changes made part way through an update to be included in the next transmission.
The sync command can send all or subsections of the directory tree by settinhg the transfer type to one of all, playlist, content, resources, or data. This can dramaticly improve transfer speed since it does not always have to consider the large video files.
The output of the sync script is appended to /plasma/log/sync.log
Data Feeds
To display live news, lottery numbers, announcements or any kind of changing information, we create text files in the data resources directory.
Most likely the format we get the feed supplied in will not be the format we can use to display it with Flash. This means we need to do some processing on an input file to create one or more output files.
The way I set up the existing feeds was to use wget to retrieve the feed input file from the provider and copy it into /plasma/feeds.
Some code is required to convert that into a url encoded variables file for flash’s loadVariables() action script command to open. I’ve written this in Java but use what you will or contact me with the email address on the cover.
The classes in mavl.beeb.* and mavl.men.* show some clues on how to write a feed processor. One is a bespoke text input and the other uses XML.
Every hour, a cron tab entry runs the /plasma/bin/news script. This runs wget to collect the feed file then if the file was retreived ok, runs the java which processes input and drops text files directly into the /plasma/main/content/data directory where to can be linked to for each machine, ready for rsyncing. The news script then calls /plasma/bin/sync $machinename data for each machine. If you add machines which will take advantage of these feeds, add a line to the news script to send updates to it automatically. Otherwise the data will be send when you do a manual sync using either the console transfer queue or just the sync script from the command line.
When designing flash to display these feeds, be aware that the data inside them can be changed to almost anything as it not under our control. Be prepared
.
Synchronization with Players
So we have a directory on the server full of soft filesystem links to the actual files we want to be in the /plasma directory on a particular player machine.
Each player machine should if all is well have a daemon running called rsyncd. In the file /etc/rsyncd.conf on the player, the directory /plasma is shared and with the correct authentication can be written to from another machine on the network.
The server has an IP connection either directly or through the router to any plasma machine. (maybe not all at once or quickly with ISDN & modem). We can use this to talk to the rsync daemon running on the player machine.
Rsync can be configured to send files pointed to by soft links. This is what we do. The script /plasma/bin/sync creates a nice clean wrapper around the rsync functions but basically runs rsync like this….
rsync -vzLP --delete --recursive --size-only . $SCREEN::plasma/
-v is to be verbose. Gives filename of files transferred
-z is to use compression to we send less data over the network
-L is to send the target of the links rather than links themselves
-P show progress if the file is a big one
--delete removes unwanted files from the player
--recursive sends sub directories too
--size-only decides if a file has changed by looking at it’s file size
. is the current directory (/plasma/$machinename)
$SCREEN is the network name of the player machine runnig rsyncd
::plasma refers to the plasma share provided by rsyncd
in the script, you can set the user name and password in environment variables.
The main advantage of rsync is that it will send changes rather than whole files if it can. If you have to update a 200MB video over a modem, you will appreciate this feature.
Use the /plasma/bin/sync script and not rsync directly to avoid disasters. Or read first http://rsync.samba.org before using rsync.
Log Files
There are two main log files to pay attention to.
The application / sync log file which is in /plasma/log/sync.log
Every time the sync command is run, it’s output goes into this log file.
You will see ping tests for each machine then rsync output telling you which files have been sent our in the case of sending a 200MB file over a modem, the progress made and how many more hours it needs.
This file has the potential to get very large if left unchecked. Delete or archive it regularly or make a cron job to do it for you.
The system log file /var/log/messages
Not just for the plasma system but for any linux machine, you will see what is happening in the system. If you have any crashes or problems with the operation of the system, look here.
Sometimes when the file gets big you’ll find messages.4.gz or similar. Type gzip –d <filename> to decompress it so you can read it
I’ve created an account called status on the server. This is not a full user account. Instead of a shell, you get a monitor of the sync log. This is good to watch the transfer happening and gives you confidence that your mouse clicks on the console are really making a difference to a plasma screen in a far away airport. Also a good way to see which machines are down… look for “not pingable” lines.
Building a Server
Install Mandrake from the CD with all the option you would like. I would use this installer for postgres as it will pre configure a database service.
Make sure that SSH, samba and postgres are all runnig.
Install Java and make sure that the postgres jdbc drivers are there.
Install the plasma server software from the cd. This will create the database.
Edit the samba config to share the /plasma/main directory so windows machines can copy content into it. Make the workgroup match whatever you ofice has.
Configure IP so that the default gateway and DNS resolver point to the router.
Back up the database directory and the /plasma/ directory often.
The Network
The numbering scheme used is a simple one. We’ve used numbers reserved for non internet private networks. 192.168.x.x
192.168.2.0 is for machines directly connected to the office and or the upcoming Manchester Airport advertising LAN.
192.168.3.0 is for machines external to this network. This will be machines using ISDN dial up or modem dial up through the router.
The router will open connections from the .2 net to the .3 net whenever required. Machines on the .3 net will be able to contact machines on the .2 net only when a connection is open from the router. .3 machines can not initiate connections to the .2 net, only receive incoming connections / calls on it’s ISDN or modem line.
The server machine is assigned 192.168.2.1
The router machine is assigned 192.168.2.2
Machines in the office (.2) should use numbers below 100
All machines whether .2 or .3 should have their gateway set to be the router (unless a LAN connects them to an ISDN machine, which forwards their packets on to the router.) The DNS server is also the router.
The Router
Using the Linux Kernel’s IP forwarding functions and routes maintained by the route command. ISDN4Linux and Diald (for modem connections) provide a dial on demand service to connect to remote machines.
We’re running BIND as our name server.
Any routes which are not .2 .or .3 addresses will be sent to the internet.
The server sends updates to player machines all the time. The server doesn’t care how it connects to these machines, it just sends its requests to the router or it’s local Ethernet card and hopes that the connection comes. IP can be carried over many mediums, if someone were to write a driver to route IP using carrier pigeons, it could be integrated into our network although I suspect the transfer rates would be rather slow. What I mean is that we can route IP over Ethernet, Telephone Line, ISDN line, satellite links, radio, whatever. So long as each connection can take packets and deliver them or hand them to another router that can deliver them, and so forth.
Both isdn4linux and diald can create a network device (type ifconfig –a to see them) which will dial a certain number and connect to the remote computer there whenever data is sent to the device. This is called dial on demand.
To connect to Manchester Terminal 2 Departures, we need to dial it up and supply a user name and password to connect. If we configure a network interface that knows this and can do it automatically then we can just send data to this interface when we want to send to t2 departures.
So we have lots of interfaces that dial certain numbers and supply a user name and password to bring up the link. But how do we know which interface to dial for which machine?
Routing is the process of deciding where to send IP packets based on their destination IP address. In our case we do that with a routing table. You can edit and view this table with the route command.
route add –host t2dep dev ippp2
…adds an entry to the routing table which sends data for t2 departures over this interface. –host sets the netmask to 255.255.255.255 meaning that only this one IP is available at the other end of the link. Make sure this is correct.
When the router starts, it suns /root/start which creates and configures interfaces and sets routes for them.
/root/routes is full of lines like above and is run frequently to keep our routes in the routing table. The data then goes to the right place, providing the player machine answers the phone and the connection is ready before the sender times out.
In addition to routing to remote plasma player machines, the router machine can send data to the internet. This is done by creating another interface configured to dial up to an ISP and setting it as the default (catch all) route. Data goes to the internet if the destination address is not for 192.168.2.0 or 192.168.3.0.
route add default ippp0
sets the default route so that ippp0 dials. It is also configured to masquerade on behalf of machines on the private network so they can connect to external web sites, etc.
named runs using zone files stored in /var/named
In the zone files we have reverse name maps for the 192.168.2.0 net and 192.168.3.0 net and forward maps for *.localdomain
named is configured to ask other name servers on the internet about any addresses it doesn’t know about and cache the result until it expires.
PPP over ISDN
Isdn4linux is what you need for this, together with one or more isdn cards and a line.
On the client / router side……
Create a new isdn device ipppn where n is a number like this:
isdnctrl addif ipppn
Configure this with a phone number using isdnctrl
Run ipppd for this device using:
ipppd file /etc/ppp/ioptions.ipppn
In the options file, use standard ppp config to set the user name for the log in.
In the /etc/ppp/pap-secrets file, make a line with the user name and password to use.
Set a route to send data over this link for whichever machine it dials up.
On the server / plasma player side……
Create a new isdn device ipppn where n is a number like this:
isdnctrl addif ipppn
Set the security to either off or add an incoming phone number of the router.
Run ipppd as above
Check the pap-secrets file so it has a matching username and password for the router’s config.
If there are other machines at the site, make some routes for that but this time over the ethernet card device, eth0
This could be discussed all day long so look at this page:
http://www.isdn4linux.de/faq/i4lfaq-6.html#config_links
PPP over Modem
Use diald for this.
For the router….
Create a diald config which specifies the modem device(s) to use and a dialing script to provide the phone number to use.
Run diald with the file option pointing to this configuration.
Make sure the pap-secrets
Add a route for the diald device for the machine that it connects to.
Run one diald instance for each connection you need.
For the player….
Use mgetty compiled with the AutoPPP extension to answer the phone.
Have mgetty listen to the modem and start PPP with pap authentication once it gets an incoming connection.
Make sure the pap-secrets file matches the details on the router.
This is not a simple topic and whole books have been written on it. Look on the internet..
For diald config help
http://pachome1.pacific.net.sg/~harish/diald.config.html
For mgetty AutoPPP help
http://www.gue-tech.org/unix/ppp/sol_autoppp.html
Ethernet
If you can route your data over an Ethernet card then the whole system will become very fast and reliable. This is by far the best means of data communication for our purpose.
In Manchester Airport, the office LAN will be / is connected to a bigger one in the airport which connects all the plasma player machines.
If the IP numbers are configured all on the 192.168.2.0 network and each machine has it’s netmask set to be 255.255.255.0 and all interconnections provided by the Airport work the you should have a connection as soon as you plug the card in.
All machines connected to the router and server by Ethernet should be on the .2 network.
Everyting not connected to the server or router by Ethernet should be on the .3 network space and the links to them from the router should have either a single host netmask or a small one to accommodate connected machines.
Networking is by no means simple and cannot be explained in 3 pages. Read this….
http://www.tldp.org/HOWTO/Net-HOWTO/
The Internet
…Is full of hackers, freaks and generally untrustworthy users and their computers.
The router connects to the internet whenever is has data destined for a machine whose address is not in the 192.168.2.0 or 192.168.3.0 ranges.
The server is configured to collect data feeds from the internet every hour. This means that every hour, if the internet connection is not already open from office web browsing or some other transfer, the router will call an ISP and obtain a valid internet IP address. This IP is dynamic and will change every time the machine dials up.
The dynamic IP and intermittent connection are quite good ways to avoid attacks but there’s always a chance that someone will try to connect into our network when we are connected to the internet.
The router runs only sshd and named. Both are listening to the internet and will accept incoming connections. No other ports are open. Named is configured to only answer requests from 192.168.2.0 and 192.168.3.0 addresses. IPChains firewall is running and securing the internet connection.
Ssh is a short name for secure shell. This service provides remote shell access in the same manner at telnet (but with some extra features such as X11 forwarding) but all data passed over the network is encrypted. Sshd will accept incoming connections from the internet when connected but requires username and password authentication for log in. This allows an engineer to connect remotely once the current external (Internet) IP number of the router is known. Once a shell on the router machine is obtained it is possible to work on any connected machine as if in the office.
Building a Router
Install mandrake 8.2 with the very basic minimum options. Remember that any services you install (samba, nfs, apache, etc) could also be available to external internet users. Either do not install them or configure them only to accept requests from local Ips.
Install the networking componets of mandrake. Or better Mandrake SNF.
Add ISDN cards and modems as required and load the hisax drivers…
modprobe hisax id=HiSax type=35,36 protocol=2,2
ISDN cards should be configured like this. The type numbers are available in the isdn4linux docs on the internet. This line is for two cards, one w6692 and one HFC type. The more cards you have the better. Channels will be pooled together and used when required.
On the router install CD, you will find scripts to start and stop the isdn devices, already configured with phone number for manchester, east mids and cardiff.
To install from CD, change directory to /mnt/cdrom and run the install.sh script.
If the card types or other hardware configuration have changed, you’ll have to look at the hisax driver type numbers and/or device entries in diald options files.
The Console
To run the console under windows, you need a Java runtime environment to be installed. You can download from www.javasoft.com
A valid samba account on the server with \\server\plasma mapped to p: and write access to this area.
The jar files for AbsoluteLayout.jar, jdbc7.1-1.2.jar, mavl.jar & TimerBean.jar in the classpath.
Start the console with ‘java mavl.BambiManager.Manager’ or usr a batch file to do it for you.
Each player machine needs to have a record in the database. The most important fields here are the playlist and connection name.
T
he
connection name should be the name of the machine as is it in DNS
records

And advert is either an HTML file or a video file. To make an advert valid either tick the House ad box or enter two dates where today’s date is between them.
When you click the browse button, next to filename box, the file you select will be copied on to the server.
You can insert it into a playlist right now or use the playlist tab to place it to your taste in the running order.
Advert Resources
Ads can have two types of resources. A Data resource is something like a data feed file for news. This is held in the data directory and should be referenced with a relative path of “data/resource.txt” from the base URL.
Other resources are stored in the res directory. These are normally graphics like flash or images. They should be included in the html with relative links such as “res/someflash.swf”
Play lists

To get one of your ads into the valid adverts list, it must either be a house ad or have valid start and end dates. You can then move it into a playlist with the add button.
The playlist filename is the actual file name that will be used on the player machine. Make sure it doesn’t clash with another and that it is a valid UNIX file name with NO spaces or strange characters in it. Name it descriptively.
Controlling updates
Updates are sent out through a first in, first out, queue system. There are several types of transfer available:
All
Data
Resources
Content
Playlist
They send different part of a player’s directory tree. See the filesystem section in the server chapter.
Updates are sent for a playlist, or group of machines.
Support
Internet Resources
There is a wealth of information to help support, update and modify this system. The whole system is assembled from freely available, open source packages. Each of these has it’s own documentation and HOWTO tutorials available on the Internet. www.linux.org has docs on almost all of the system.
Details of the operating system is available at www.mandrake-linux.com
Details of the video player are at www.mplayerhq.hu
Details of the flash player are at www.macromedia.com
Details of the HTML browser are at www.opera.com
Details of rsync are at http://rsync.samba.org
Samba (smbd) is documented at www.samba.org
The postgres database is at http://www.postgresql.org/
Java and its runtime is at http://www.javasoft.com
Networking topics are covered at http://www.tldp.org/LDP/nag/nag.html
Linux ISDN info is at http://www.isdn4linux.de/
The author of this system can be found at http://www.rumbletum.org
Abolutely everything else is searchable at http://www.google.com
CDs
The player software
Manchester
East Midlands
Cardiff
These vary only by the ads which are installed by default
The router
ISDN, firewall and routing setup scripts
The server
A snapshot of the postgres database and all java classes & source
Mandrake Linux 8.2
The base of all machines
Replacements are available by emailing dunc at rumbletum.org
For system related development (anything covered in this document or additions to the system) please contact dunc at rumbletum.org
Since all code used in the building of this system is either taken from open source projects or supplied with the system, it can be maintained either by it’s authors or someone with the following skills..
Linux System Administration, Bash Shell scripting, PostgreSQL or generic SQL, Java J2EE & JDBC, TCP/IP subnetting and routing over ISDN and modem with PPP.
Unix Cheat Sheet
cat Reading and printing multiple files
cd Changing directories, moving around
chmod Changing permissions on a file or directory
chown Changing ownership of files and directories
cp Copying files
date Displaying and setting dates
diff Differences between files
exit Stopping a process and coming back home
find Searching for files that meet specified conditions
finger Gathering information about users
grep Searching for lines that match regular expressions
head Printing the beginning of a file
kill Terminating processes
killall Terminate all the processes (-9 really do it)
less Displaying files in pages
ls Listing files (-l for more info)
man Using the online manual (type man command for more info)
mkdir Making directories
more Displaying files in pages
mv Moving and renaming files
passwd Creating or changing passwords
ping Test a network connection
ps List active processes
pwd Printing the pathname
rlogin Logging into remote systems
rm Removing files and directories
rmdir Removing directories
shutdown -r now Reboot!
ssh Connect to other machines
su Logging in as another user
tail Printing the end of a file (-f to do it as the file gets bigger)
telnet Communicating with other hosts
top Display a summary of the system
who Who is logged into a machine
Specific to the plasma system
/plasma/bin/sync machinename transfertype
eg /plasma/bin/sync bambidev all
/plasma/bin news Update the news feeds and add to send queue
killall –9 mplayer Skip ads on a player machine
killall –9 opera
Airport
Advertising Digital System