Plasma Advertising Digital Signage

infojection linux digital signage
by dunc@Infojection originaly published at Rumbletum.net, Digital Signage News Wire

Technical notes to support the operation of the Digital Advertising System

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;


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


Hardware

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.


Operating System

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


Installed Software

X SVGA allowing 24bit 640x480 display

Opera to play html and flash. The file /.opera/opera6.ini contains the configuration to make the windows 640 x 480 and with a default colour of black

Flash player 6 netscape/motiff plugin

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


Install X with the Mandrake installer

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.


Networking


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


Hardware


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.


Operating System


Linux Mandrake 8.2, Kernel 2.4.18


Installed Software


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/

Contains ALL player data that can be available whether used or not


/plasma/$playername

The mirrors of each player’s /plasma directory, ready to be synced


/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


The Java class mavl.BambiManager.DBSync is designed to run permanently as a service. It watches the transfers table in the database for jobs. It should be run at system startup from the syncer script in /plasma/bin


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.


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.


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


IP Numbering


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


Requirements


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.



Player Machine Records


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


Advert 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:


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


Email


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


You’ll find installation CDs for


These vary only by the ads which are installed by default

ISDN, firewall and routing setup scripts

A snapshot of the postgres database and all java classes & source

The base of all machines


Replacements are available by emailing dunc at rumbletum.org


Developers


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 System23