Debiteringssystem för CUPS-server

March 2nd, 2010

Hej, jag heter är Christian och jag praktiserar här på Örestad Linux.
Mina uppgifter utgörs för tillfället av att titta närmare på nätverksinfrastrukturen för hela Malmö Arena-kontorsförening – vilken vi tillhör – och pilla på olika lösningar för saker och ting som hör kontorslandskapet till.

Vidare till vad dagens bloggpost handlar om:
Jag fick under mina första dagar här uppgiften att implementera något slags debiteringssystem på skrivarservern. Anledningen är att kontoret ska koppla in en nyare färglaserskrivare där kostnaden för varje utskriven sida ökar markant jämfört med tidigare – och då skrivarservern delas av ett flertal företag i byggnaden är utskriftskontrollen en kommande prioritet.

Sagt och gjort – gröngölingen går loss på nätverket.

Syfte
Sätta upp en simpel billing/debiterings-lösning för en CUPS-server.
Tillvägagångssätt
Vid första anblicken utgörs problemet av två moment:
-Logga utskriftstillfällen
-Kalkylera antalet sidor för utskrivet dokument

Att logga utskriftstillfällen kan göras på ett flertal sätt, men för att på ett smidigt sätt hantera loggning och sidokalkylen i ett och samma moment valde jag att använda mig av programmet tea4cups.
Tea4cups är en fiffig open-source backend till CUPS med vilken man enkelt kan filtrera utskrifter och specifiera åtgärder som skall göras både före och efter en utskriftssession.
För sidkalkyleringen använder jag mig av pkpgcounter – ett smidigt program som kan räkna ut sidantal och även bläck/färgmängden(!) per angivet dokument.

Programvara
Installationen av tea4cups är enkel – hämta hem, extrahera, kopiera filer dit de ska – det exekverbara pythonskriptet placeras i /usr/lib/cups/backend/ och konfigurationsfilen i /etc/cups/.
När sedan CUPS startas om känner den av den och man kan lägga till skrivare med tea4cups-funktion – jag valde dock att konfigurera de skrivare jag ville skulle beröras av tea4cups genom att manuellt editera skrivarkonfigurationsfilen /etc/cups/printers.conf – och helt enkelt lägga till tea4cups:// före skrivarens DeviceURI:
DeviceURI tea4cups://hp:/usb/hp_LaserJet…
Starta om CUPS. Klart.

Programmet pkpgcounter hittar man antingen i aptitudes repositories
#apt-get install pkpgcounter
eller som tarball

Konfiguration
Om jag nu vill att något speciellt ska hända vid en utskrift lägger jag helt enkelt till en såkallad “hook” i /etc/cups/tea4cups.conf. “prehook_” kommer att köras innan utskriftsjobbet skickas vidare till CUPS och “posthook_” körs när utskriften är klar.
Vad tea4cups även tillhandahåller är en uppsättning miljövariabler som kan komma till nytta vid ‘hook’arna – hela listan ges i dokumentationen – jag kommer att använda mig av
$TEACLIENTHOST -IPadress på klienten som skickat utskriften
$TEAJOBID  -Jobid på utskriften, relativt mot filerna i /var/spool/cups/
$TEAPRINTERNAME -Namnet på den skrivare utskriften skickades till
$TEADATAFILE -Sökvägen till utskriftsjobbets temporära fil
$TEAUSERNAME -Användarnamn på klienten som skickade utskriften

Dessa variabler kommer jag att använda som parametrar till ett skript som kommer att köras från en posthook. Först kallar jag på skriptet med en hook i /etc/cups/tea4cups.conf

posthook_billing : /bin/bash /etc/cups/billing.sh $TEACLIENTHOST $TEAJOBID \ $TEAPRINTERNAME $TEADATAFILE `echo $TEAUSERNAME | sed ’s/ /-/g’`
(sedbehandlingen av användarnamnet ersätter eventuella mellanrum i användarnamnet med streck)

Sedan ett skript som kan hantera dessa parametrar och mata ut en logg.

———–

#!/bin/bash
declare IP="$1"
declare JOBID="$2"
declare PRINTER="$3"
declare PAGES=`pkpgcounter $4`
declare USER="$5"
declare DATE=`date`
declare PLIST="/billing/prints"
if [ ! -f $PLIST ]; then
echo "$DATE" > $PLIST
chmod 644 $PLIST
fi
echo "$IP::$USER::$PAGES::$JOBID::$PRINTER::$DATE" \
>> /billing/prints
exit 0

———–
Lite omdöpande av variabler – men kontentan är att en rad med de inkommande parametrarna matas ut i en loggfil.

Dock vill jag även att MAC-adressen hos klienten som skickade utskriften anges i loggen – IPadresser är ju dynamiska och det är kanske inte en bra idé att införa ett debiteringssystem där man helt plötsligt kan ärva någon annans skuld..
Först löste jag detta med att använda IP-variabeln för att pinga klienten och sedan kolla upp MACadressen i arp-cachen.. men detta var opålitligt(blockera ping – skriva ut gratis. hmm.) så jag löste det med att göra ett skript som samarbetar med DHCP-servern där IP och MAC kan matchas i en lease.
Jag lägger till MAC-ändringarna i skriptet:
declare MAC=`ssh user@dhcpserver ./macfinder.sh $1`
echo “$IP::$MAC::$USER::$PAGES::$JOBID::$PRINTER::$DATE” >> /billing/prints
Jag kallar på ett skript på dhcpservern via ssh(lösenordslös login!) – parametern som skickas är IPadressen och svaret är MACadressen den tillhör för nuläget.

Skriptet på DHCPservern ser ut som så här:
——–
#!/bin/bash
declare MAC
declare -i X=0
while read line; do
if [ $X -eq 1 ]; then
if [ "${line:0:8}" = "hardware" ]; then
MAC=`echo "$line" | sed 's/;//' | \
awk '{print $3}'`
break
fi
fi
if [ "$line" = "lease $1 {" ]; then
let X=1
fi
done </var/lib/dhcp3/dhcpd.leases
echo "$MAC"
exit 0

——-
Vad denna gör är att stycka upp dhcpd.leases och leta efter IPadressen som angavs och mata ut nästkommande MACadress.

Såja, vid det här laget bör billing/debiteringssystemet fungera – en loggrad bör se ut som
192.168.1.2::00:00:00:00:00:00::user::2::1680::HP_LaserJet_3015::Mon-Mar–1-14:40:01-CET-2010
Här syns en IP- och en MAC-adress från klienten, med anv.namn: user, som skickat ett skrivarjobb på två sidor till skrivaren HP_Laserjet_3015 den 1:a mars kl 14:40. Lagom detaljerad logg.

Nu – ett litet skript som kokar ihop loggen och får ut hur mycket klienterna har skrivit ut för. Just nu nöjer jag mig med att lista pris för varje loggad MACadress.
——-

#!/bin/bash
declare HPRICE="0.50"
declare LPRICE="0.10"
declare DATE=`date +"%B%d%Y"`
declare PAGES DEBT
declare -i RESULT
declare COLPAGES=0 NORMPAGES=0
declare LIST="/billing/prints"
declare MAC=(`awk -F "::" '{print $2}' $LIST | sort -u`)
declare OUTPUTFILE="/billing/RAPPORT$DATE"
declare COLPRINTER="EXPENSIVECOLORLASERPRINTER"
echo `date` > $OUTPUTFILE
for X in ${MAC[*]}; do
DEBT=0
COLPAGES=0
NORMPAGES=0
declare -a PRINTER=(`grep $X $LIST | awk -F "::" \
'{print $6}'`)
for Y in ${PRINTER[*]}; do
RESULT=0
PAGES=`grep $X $LIST | grep $Y | awk -F "::" \
'{print $4}'`
for Z in $PAGES; do
let RESULT=RESULT+Z
done
if [ "$Y" = "$COLPRINTER" ]; then
COST=`echo "$RESULT*$HPRICE" | bc`
COLPAGES="$RESULT"
else
COST=`echo "$RESULT*$LPRICE" | bc`
NORMPAGES="$RESULT"
fi
done
CDEBT=`echo "$COLPAGES*$HPRICE" | bc`
NDEBT=`echo "$NORMPAGES*$LPRICE" | bc`
DEBT=`echo "$NDEBT+$CDEBT" | bc`
echo "$X has current debt: $DEBT Kr -- \
color:$COLPAGES( $HPRICE ea.=total $CDEBT) - \
b/w:$NORMPAGES($LPRICE ea.=total $NDEBT)" \
>> $OUTPUTFILE
done
exit 0

——-
Detta skript går igenom skrivarloggen, sorterar ut MACadresser, sorterar ut vilka skrivare som använts av de olika MACadresserna och räknar ihop antalet utskrivna sidor per skrivare – jag har prissatt en skrivare lite högre, detta ska vara namnet på den dyrare färglaserskrivaren i framtiden, och alla andra skrivare har fått ett lägre pris. Sist matas en rad ut per MACadress där all samlad information om dess utskrifter räknats ihop.

Så – en lösning för ett simpelt billingsystem, löst med ett par enkla program och lite grundläggande skalskripting.
Tack för mig!

Tarball med skripts

Bookmark and Share

Testautomation för WebApplikationer – Selenium

November 16th, 2009

Skrivet av:
Paul Arcombe,
Certified ISTQB Foundation SoftwareTester,
Örestad-Linux, Malmö

INLEDNING.
Detta utkast är starten på ett projekt inom Test Automatisering, där vi undersöker testverktyget Selenium och dess möjligheter inom webapplicerad testautomatisering. Selenium används i denna studie tillsammans med JAVA och JUnit i en Windows XP miljö.


SAMMANFATTNING.
Selenium är ett test verktyg som används för att generera test skript. Detta sker genom att spela in de händelser som utföres av en användare på en internetsida i en valfri browser.

Skriptet som genereras, erhålles i ett speciellt skriptspråk – Selenese, som sedan kan exporteras till i princip vilket programmerings språk som helst. Dessa skript kan köras individuellt, i större sviter eller som inbäddade test i egendefinierade testapplikationer. Selenium är ett utmärkt Open Source verktyg som lämpar sig synnerligen väl för repetitiva RegressionsTestLösningar då tid, repeterbarhet och smidighet är nyckelfaktorer.


SYFTE / MÅL
Projektet går ut på att

  1. Undersöka vad Selenium kan erbjuda inom automatiserad test av webapplikationer.
  2. Installera och sätta upp Selenium.
  3. Bygga och slutligen använda enskilda tester med hjälp av Selenium.
  4. Att sätta upp och få igång en fungerande testmiljö bestående av Selenium, Java och JUnit
  5. BASICS: Hur man använder testsviter/multipla test från Selenium m.h.a. Java och JUnit.
  6. ADVANCED (I): Skriva/modifiera skript m.h.a. skriptspråket Selenese.
  7. ADVANCED (II): Loggar, Test sammanfattningar och Test rapporter

Projektet är avsett att uppdateras en gång per vecka, med start 091116.  Avslutat 091231.

<TIDIGARE>                                                            <NÄSTA>


KAPITEL 1:  Undersöka vad Selenium kan erbjuda inom automatiserad test av webapplikationer.


TESTAUTOMATION FÖR WEBAPPLIKATIONER.
Många, kanske de flesta, programvaruapplikationer är i dag skrivna som webbaserade applikationer att köras i en Internet webbläsare. Effektiviteten vid test av dessa applikationer varierar brett bland företag och organisationer.

I en era av fortlöpande förbättring av programvaruprocesser, som Agile och eXtreme programming (XP), kan det argumenteras att disciplinerad testning och quality assurance practices fortfarande är underutvecklat i många organisationer. Test av programvara utförs ofta manuellt. Emellanåt är detta effektivt; emellertid finns det alternativ till manuell testning som många organisationer är omedvetna om, eller saknar expertis att utföra. Att anpassa sin test verksamhet till sådana alternativ skulle i de flesta fall avsevärt förbättra effektiviteten i deras programvaruutveckling.

Test automation är ofta svaret. Test automations hjälpmedel, verktyg för att köra repeterbara test mot målapplikationen när helst det är nödvändigt.

Det finns många fördelar med test automation. De flesta är relaterade till repeterbarheten av testen, och den hastighet med vilken testen kan exekveras med. Det finns ett antal kommersiella och Open Source verktyg tillgängliga som hjälpmedel inom test automation utveckling. Selenium är troligtvis den mest använda Open Source lösningen. Denna användarguide är avsedd för såväl nya, och mer erfarna Selenium användare, som vill lära sig effektiva tekniker i att bygga testautomation för webapplikationer.

Denna guide introducerar Selenium, pekar på dess bredast använda särdrag, och ger användbar rådgivning i best practices ackumulerat från Selenium Community. Många exempel ges. Teknisk information som beskriver Seleniums interna struktur, och rekommenderat bruk av Selenium ges som bidrag från konsortiet av erfarna Seleniumanvändare.
Denna guide syftar till att vägleda nya användare i användandet av Selenium inom test automation.

För att hålla en röd tråd i denna guide kommer exempel och beskrivningar att begränsas till Selenium med inriktning mot Java och JUnit-test automatisering med Mozilla Firefox och Windows XP SP3 som testmiljö. Samma principer gäller dock för andra inriktningar, webbläsare och operativsystem, även om implementeringen skiljer sig. De som vill fördjupa sig i andra inriktningar hänvisas till specifik dokumentation på

Seleniums hemsida.


INTRODUKTION AV SELENIUM
Selenium är en robust uppsättning av verktyg som stöder Rapid Development av test automation för webbaserade applikationer. Selenium ger en rik uppsättning av testfunktioner, specifikt utformade för att möta behoven vid testning av webapplikationer. Dessa funktioner är flexibla och ger många alternativ för att lokalisera UI-beståndsdelar, och jämföra förväntade test resultat mot faktiskt applikations uppförande.

-  Ett av Seleniums huvudsakliga särdrag är möjligheten att utföra testning på multipla webbläsarplattformar.

-  Ett annat är att erhålla genererade testskript i valfritt programmeringsspråk, för användning såväl embedded som standalone. Detta är synnerligen användbart då man vill köra multipla test eller blandade testsviter i specifikt komponerade sekvenser.

-  Eftersom Selenium är byggt i Java är det även plattformsoberoende


PLATTFORMAR
Selenium fungerar på de flesta platformar. Här följer en lista på vilka:

Platforms supported by Selenium


VAD ÄR SELENIUM?
Selenium är ett testverktyg för webapplikationer, som använder sig av JavaScript och Iframes för att köra tester direkt i en webbläsare (browser). Det finns ett flertal verktyg som är baserade på denna teknologi: Selenium Core, Selenium IDE, Selenium Remote Control, Selenium Grid och Selenium on Rails (Den sistnämnda ingår inte i denna studie och kommer ej att nämnas mer.).


SELENIUM KOMPONENTER.
Selenium består av Selenium Core och tre andra huvudverktyg. Vart och ett med specifika roller inom testautomation för utveckling av webbapplikationer.
Selenium Core är ett annat sätt att köra test på. Man kan köra test skript från en webbläsare genom att använda dess HTML interface TestRunner.html. Detta är originalmetoden för att köra Selenium kommando. Det har dock sina begränsningar. Precis som Selenium-IDE, stöder det inte iteration.


SELENIUM CORE
Selenium-Core kan inte skifta mellan http och https-protokoll. Sedan utvecklingen av Selenium-IDE och Selenium-RC, används dessa verktyg i större utsträckning än Selenium-Core själv. I skrivandets stund (November 2009) finns det fortfarande tillgängligt. Dock bör det uppmärksammas att Selenium-Core är en produkt som på sikt kommer att fasas ut. Selenium Community uppmuntrar till användning av Selenium-IDE och RC. De avråder användandet av Selenium-Core. Support för Selenium-Core blir allt mindre i omfattning och tillgänglighet och kommer sannolikt att fasas ut helt i framtida utgåvor.


SELENIUM IDE
Selenium-IDE är den integrerade utvecklingsmiljön för att bygga Selenium testfall.
Den fungerar som en Firefox-add on och tillhandahåller ett ”easy-to-use” interface för utveckling och körning av individuella testfall eller hela testsviter. Selenium-IDE har en inspelningsfunktion, som registrerar användar händelser efterhand som de utföres och lagrar dem som återanvändbara skript för återuppspelning. Den har även en context meny (högerklicka) integrerad med Firefox webbläsare, som tillåter användaren att välja från en lista av förslag och verifikationer för det valda läget. Selenium-IDE erbjuder även fullständiga editerings möjligheter av testfall för mer detaljerad precision och kontroll. Även om Selenium-IDE är en Firefox add-on, kan skapade testfall även köras mot andra webbläsare genom att använda Selenium-RC. Testfallen kan även köras från kommandoprompten genom att helt enkelt specificera namnet på den testsvit man vill köra.


SELENIUM RC
Selenium-RC ger test automations utvecklaren möjlighet att använda sig av olika programmeringsspråk för maximal flexibilitet och omfattning i utveckling av testlogiken. Till exempel, om applikationen som testas returnerar ett resultatset, och om det automatiserade testprogrammet behöver köra tester för varje element i resultatsetet, kan valt programmeringsspråks iterations support utnyttjas för att iterera genom resultat setet, och använda Seleniums kommando för att köra testen för varje enskillt testobjekt.
Selenium-RC tillhandahåller ett API (Application Programming Interface) och bibliotek för varje programmeringsspråk som det stöder:

HTML,
JAVA,
C#,
Perl,
PHP,
Python,
Ruby,
Drupal,

etc….

Denna möjlighet att använda Selenium-RC med högnivå programmeringsspråk för att utveckla testfall tillåter även den automatiserade testningen att integreras i ett projekts automatiserade byggmiljö.


SELENIUM GRID
Selenium-Grid gör det möjligt för Selenium RC lösningen att anpassas för stora test sviter eller test sviter som måste köras i multipla miljöer. När Selenium-Grids multipla instanser av Selenium-RC körs på olika operativsystem och webbläsarkonfigurationer, kommer var och en av dessa att registreras i ett nav (hub) efterhand som de startar. När testen sänds till navet kommer de att omdirigeras till en tillgänglig Selenium-RC, som kommer att starta sin webbläsare och köra testet. Detta tillåter parallellkörning av tester, där teoretiskt hela testsviten körs samtidigt och är klar på den tid som det tar att köra det längsta individuella testet.


HUR DET FUNGERAR.

how-it-works


<TIDIGARE>                       <ÖVERST>                       <NÄSTA>


Bookmark and Share

Ubuntu 9.04 vs Windows 7 Energy consumption test

September 29th, 2009

“The Ubuntu computer uses 15% less energy”

Background:

There was some discussions in our office about the consumption of electricity by computers using different OSes.

No real conclusion was given during the conversations and no evidence or tests were found, so my boss decided to run to the electronics store and purchase a couple of electronic meters to once and for all prove what OS saves the most energy.

We only wanted to test relevant OSes and as our company are highly focused on open source software and users of Ubuntu at work, the distrubution of our choice naturally became Ubuntu.
This is also one of the most mainstream distros and thereby very relevant to test.

Of course we needed to compare with a Windows OS as it is the most popular OS family.
The newest contribution to the Windows family (Windows 7) was released as a RC.
This RC became the opponent in our test, and is very relevant as Microsoft states in this blog I have to assume it is the most energy efficient OS from Microsoft up to this date.
Without any further evidence we believe that Microsoft is being honest in this aspect and the older versions of Windows should be less efficient.

Luckily I was assigned this pretty interesting task.
I was to install Windows 7 RC 32 Build 7100 on one of our HP 550 and Ubuntu 9.04 32 on another identical HP 550 and push the computers through different tests while monitoring the meters.
This is the outcome of my tests.

Note:
Some of the employees at this office use Macbooks and while it would be very interesting to compare the OSes above with Mac OS X we can’t use identical hardware; the test wouldn’t be fair.
But as a side note the Macbook seems to use less energy than HP 550 with either Ubuntu or Windows.

Technical summary:
Hardware:

The computers used are 2 identical computers of model HP 550 with AC adapter plugged into the electronic meters and with batteries unplugged.
These are the specifications according to the HP website.

Processor type Intel® Core™2 Duo Processor T5670
• 1.80 GHz, 2 MB L2 cache, 800 MHz FSB
Chipset Mobile Intel® GME965
Standard memory 1 x 1024 MB DDR2
Memory slots 2 SODIMM slots supporting dual channel memory
Internal drives 160 GB
Harddisk speed 5400 rpm
Optical drives DVD+/-RW SuperMulti DL LightScribe Drive
Display size 15.4 inches diagonal
Video resolutions 1280 x 800 WXGA BV
Graphic subsystem Intel® Graphics Media Accelerator X3100
External I/O ports 3 USB 2.0 ports, VGA, stereo microphone in, stereo headphone/line out, power connector, RJ-11, RJ-45
Expansion slots Slots available for additional devices: 1 ExpressCard/54 slot, Secure Digital (SD) slot
Audio High Definition Audio, mono speaker, stereo headphone/line out, stereo microphone in
Network interface Intel Fast Ethernet Integrated Controller (10/100 NIC)
Modem 56K modem
Wireless technologies Intel® Wireless LAN 802.11a/b/g, Bluetooth 2.0+
Power requirements External 65W AC adapter, HP Fast Charge Technology
Power features 6-cell (47 WHr) Lithium-Ion battery (Unplugged while testing)

The meters show current Watt consumption and has a timer and a kWh counter.

Software:

Ubuntu 9.04 32 bits
Fully updated.
Standard install and no configuration.

Windows 7 RC 32 bits Build 7100.
Fully updated.
Standard install and no configuration.

Applications used during the test are mostly natively included ones.
For example I used Windows Media player 11 vs Movie player and Internet Explorer 8 vs Firefox 3.0.x. Etc.,
although some applications will be identical.

Method:

Day 1:

What to test first?
Well, I was in the mode for testing, the first fact is that Ubuntu boots to desktop faster and even though it’s not the purpose for this test I just had to do it.
Ubuntu boots in 53 seconds while Windows 7 boots in 1 minute and 8 seconds.


Note: Video shows Watt consumption differences between the OSes while booting

Now let’s go on topic.
Well both computers are now booted and the meters are running started at the exact same time.
I get about an hour of testing. Before the day is over the meters will measure the total kWh for this hour and I will try it again for a longer period after the weekend.

During this hour I have to come up with some tests.
How about ”idle mode” with no applications running at all.
Ubuntu shows a constant consumption of 33 W while Windows 7 shows a constant 36 W.
IMAG0144

Ubuntu is more efficient with nothing running but how about som standard office work.

I have installed Open Office 3.0 on the Windows 7 computer before starting the meters.
While starting up OO the Windows 7 meter peaks at 51 W while Ubuntu only peaks at 41 W but this lowers a bit during the document creation. I see about a 5 W difference in favor of Ubuntu during the short test period.

To do a relevant test on some actual office work 1 hour before the weekend I started downloading the Big Buck Bunny movie. Speeds are about 1.7 MB/s at both computers.
The Ubuntu meters while downloading is a constant 36 W while using Windows 7 got the meter up to a constant 41 W.

Let’s play the movie too using Media player 11 vs Movie player.
The Ubuntu meter is not constant, while playing it changes between 37 and 40 W.
The Windows meter changes between 40 and 42 W.

One hour of testing is not that much but I got some interesting facts.
Ubuntu does seem to be more energy efficient. Before I go home I look at the kWh meter.
It shows 0.04 kWh for Windows 7 and 0.03 kWh for Ubuntu.
I will be testing for a longer period after the weekend.

Day 2:

Time to start the meters again and boot up, I will try to measure as long as possible today.

While figuring out what next to test the computers idle.
After about 15 minutes the energy saving functions start as configured by default.
Both computers turns off the screen but with the Ubuntu meter showing no difference in consumption.
A solid 31 W is showing while Windows 7 dips down to 24 W.

I wait even longer to see what happens.
Windows 7 hibernates itself and while in hibernation mode it only consumes 9 W.
Ubuntu does not hibernate itself but uses only 18 W idling.

Microsoft seems to have better energy saving functions at default setup on Windows 7.
Well thats good, but it isn’t actual office work so on with some actual usage of the computers.

The next test is some Internet activities using Internet Explorer 8 vs Firefox 3.0.x.
I know that the Swedish site www.aftonbladet.se is totally bloated with flash based commercials etc.
Let’s go in there. It must be one of the most demanding site on the Internet.

The meters are pending but again Ubuntu is the winner, by around 10 W.
Let’s push it!
20 tabs of the same demanding site.
The Ubuntu meter varies between 44 and 47 W while Windows is pretty constant at 51 W.

I want to push the computers even more so let’s install Blender 2.49b and render a frame from this project.

While rendering I clearly notice that these computer aren’t really the best choice for rendering.
Both computers kind of lock down and the system monitors show maximum activity on the processors.
No real feedback until about half an hour.
But the meters still show 47 W on Windows and 45 W on Ubuntu.
Not as big a difference as before but still Ubuntu wins it again.

Then I saw the rendering times:
Windows ends at 25 minutes and 29 seconds while
Ubuntu ends at 26 minutes and 34 seconds.

It is possible that it all evens out in this test because of the lesser rendering time for Windows 7.

The last test I am going to write about is yet another ”stress” test.
10 open office documents while surfing 5 tabs of www.aftonbladet.se.
I hit the highest Watt during these test and its Windows 7 again at 54 W.
The Ubuntu meter shows between 44 and 47 W.

I look at the meters.
4 hour of usage and the Windows 7 meter stops at 0.16 kWh
The Ubuntu meter stops at 0.14 kWh.

Conclusion:

It’s fairly clear with all these facts, using Ubuntu at work will be more energy efficient.
5 hours of office work and the Ubuntu computer used 0.17 kWh while Windows 7 used a total of 0.20 kWh and this test was made on identical hardware.

The Ubuntu computer uses 15% less energy in 5 hours.
You have to figure out yourself how much money you will save in a year by migrating.

Bookmark and Share

3 Line ISP connection using iproute2

August 21st, 2009

Hi, it’s Sami again, this time we will be setting up a 3 line ISP connection on our squid server.
This is intended for static routing only. We are working on setting it up dynamically.
As usual we will be using debian 5 (Lenny). Although this is not a fresh install! We are continuing our squid install for SSWC.

First of all install iproute2 since it is not in base.

apt-get install iproute2

Now we need a script to setup our routes.

First of all we will add the routing tables that we use.

echo "1 First_eth1" >> /etc/iproute2/rt_tables
echo "2 Second_eth2" >> /etc/iproute2/rt_tables
echo "3 Third_eth3" >> /etc/iproute2/rt_tables

Variables

P0_NET=192.168.1.0
P1_NET=192.168.16.0
P2_NET=192.168.67.0
P3_NET=192.168.40.0

P1=192.168.16.1
P2=192.168.67.1
P3=192.168.40.1

IF0=eth0
IF1=eth1
IF2=eth2
IF3=eth3

IP0=192.168.1.1
IP1=192.168.16.114
IP2=192.168.67.2
IP3=192.168.40.2

T1=First_eth1
T2=Second_eth2
T3=Third_eth3

Adding routes

ip route add $P1_NET dev $IF1 src $IP1 table $T1
ip route add default via $P1 table $T1
ip route add $P1_NET dev $IF1 src $IP1

ip route add $P2_NET dev $IF2 src $IP2 table $T2
ip route add default via $P2 table $T2
ip route add $P2_NET dev $IF2 src $IP2

ip route add $P3_NET dev $IF3 src $IP3 table $T3
ip route add default via $P3 table $T3
ip route add $P3_NET dev $IF3 src $IP3

Adding rules

ip rule add from $IP1 table $T1
ip rule add from $IP2 table $T2
ip rule add from $IP3 table $T3

ip route add $P0_NET dev $IF0 table $T2
ip route add $P1_NET dev $IF1 table $T2
ip route add 127.0.0.0/8 dev lo table $T2

ip route add $P0_NET dev $IF0 table $T3
ip route add $P2_NET dev $IF2 table $T3
ip route add 127.0.0.0/8 dev lo table $T3

ip route add $P0_NET dev $IF0 table $T1
ip route add $P3_NET dev $IF3 table $T1
ip route add 127.0.0.0/8 dev lo table $T1

Adding nexthops and weight.

ip route add default scope global \
nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1 \
nexthop via $P3 dev $IF3 weight 1

We had a lot of problems with this.
Just remember one important thing!
Running this with all eth{1,2,3} on the same network with the same gateway will NOT work.
Our gateway actually mixed up all of our interfaces and added the MAC address for eth1 to eth2 and eth3 in the arp table.

iptables is also needed for this configuration.
Something like this.

iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth3 -m state --state ESTABLISHED,RELATED -j ACCEPT

Adding some masquerading.

iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface eth2 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface eth3 -j MASQUERADE

Bookmark and Share

Transparent proxy running cache on ramdisk.

August 21st, 2009

Hi my name is Sami.
This is my first blog post so it might not make sense at all to some.

We wanted to run a transparent proxy for the SSWC event here in Sweden.
What we ended up with was pretty nice actually.

So, we started with installing squid and dhcp3-server on a new machine.
We are using a fresh install of debian 5 (Lenny).

apt-get install dhcp3-server
apt-get install squid

I wont go through how to setup dhcp-server. We just set the scope for 192.168.1.0/24 net.
Now that we have the squid installed we need to configure it.

As they say, the default configuration in squid will take you very far.

What our configuration does is the following:
Transparency:

http_port 8080 transparent

YouTube caching for videos:

refresh_pattern -i \.flv$ 10080 90% 999999 ignore-no-cache override-expire ignore-private
quick_abort_min -1 KB
maximum_object_size 4 GB
acl youtube dstdomain .youtube.com
icp_access allow youtube
cache allow youtube

Ramdisk caching:
Since some 2.4 and all 2.6 there is a tmpfs driver that uses ramdisk.
Although you might want to setup some boot options like; when you reboot your memory will be cleaned out.
So our squid directory will no longer exist and the permissions will be gone aswell.

cache_dir aufs /dev/shm/squid 1014 16 256

Caching webdata:

cache allow all

Even though http_port 8080 transparent is set that is not enough.
Out server must intercept all port 80 connections and redirect them to :8080 on the squid server.
This is easily done with iptables.

iptables -t nat -A PREROUTING -i 192.168.1.1 -p tcp --dport 80 -j REDIRECT --to-port 8080

This is all that is needed for the squid.

Bookmark and Share