Raspberry pi kodi webbrowser

Het is nog altijd wachten op een Raspberry PI KODI webbrowser. Ocelot van OSMC is nog niet beschikbaar en een andere oplossing is niet voorhanden.

De raspberry PI is inmiddels bijna een volwaardige computer ter grootte van een creditcard. Je kunt deze voor veel dingen gebruiken zoals voor cloudserver, domoticaserver, downloadserver, samba server, mediaserver, vpn server, beveiligingscamera, robot en nog veel meer. Hij wordt ook veel toegepast als HTPC.

De raspberry pi heeft als HTPC veel voordelen maar ook zijn er nog wel enkele beperkingen. Als je de Raspberry PI bijvoorbeeld gebruikt als HTPC dan installeer je hier vaak een KODI distributie op zoals OpenElec, OSMC (voorheen Raspbmc) of misschien wel Xbian. Een van de belangrijkste beperkingen van KODI in combinatie met de Raspberry PI is dan toch het gemis van een webbrowser.

Nu zijn er verschillende manieren bedacht om dit gebrek op te lossen. Er is bijvoorbeeld een plugin ‘Chrome launcer’. Perfect zou je denken, vanuit KODI chrome gebruiken als browser en dan alle online content benaderen! Helaas Google ondersteund armf (Raspberry PI platform) niet langer en dus werkt het niet op een Raspberry PI. Ook Chromium werkt dus niet meer. Nu is er wel een soort ‘hack’. Je kunt een oude aangepaste versie van chromium installeren via ingewikkelde opdrachten, maar een ‘echte’ oplossing is er nog niet.

Een andere oplossing is om Raspbian te installeren, in Raspbian KODI te installeren en zo KODI te gebruiken en steeds te ‘switchen’ van KODI naar Raspbian wanneer je een browser wilt gebruiken. Een echte mooie oplossing is dit echter niet. Het liefst wil je een geïntegreerde browser in KODI.

Een veelbelovende oplossing is de in 2015 beloofde webbrowser Ocelot van OSMC. Helaas is de ontwikkeling hiervan uitgesteld en is deze tot op heden nog niet uitgebracht. Het is dus nog altijd wachten op een Raspberry PI KODI webbrowser. Jammer, want een geintegreerde webbrowser is volgens mij echt een ‘killer feature’ voor een Raspberry PI KODI mediacentre.

 

ownCloud log in Logwatch deel 2

Wanneer je ownCloud gebruikt als eigen cloud zul je er ook snel achter komen dat je nog steeds moet inloggen om de ownCloud log te bekijken. Daarvoor is deze post. Het geeft antwoord op de vraag: “Hoe zorg ik dat het ownCloud log in Logwatch wordt opgenomen?”.

Het antwoord is uiteindelijk vrij simpel, maar ik heb het volledige antwoord nog nergens kunnen vinden. Daarom deze instructie. Omwille van de lengte is deze in twee delen opgesplitst. Het eerste deel gaat over het inrichten van ownCloud. Het tweede deel gaat over het inrichten van Logwatch zodanig dat deze het ownCloud log meeneemt. Dit is deel 2, deze gaat er vanuit dat je ownCloud log in Logwatch deel 1 reeds doorlopen hebt.

Deel 2: ownCloud log in Logwatch opnemen

Hier wordt ervan uitgegaan dat de ownCloud server draait op Raspbian, zijn deze instructies ook daar primair voor bedoeld. Waarom? De Raspberry kost maar 30 euro en draait op 5 Watt. Reken wel mee dat je een of meer SD kaarten, een voeding, een kastje en waarschijnlijk een harde schijf nodig hebt, dus kom je in totaal op meer uit. Maar hoe krijg je nu die ownCloud log in Logwatch?

Logwatch leest de scripts uit in /usr/share/logwatch/scripts/services/. Als je hierin een bestand plaatst met de naam owncloud en met een juist script erin, dan wordt deze opgenomen in de email. Simpel! Kopieer een bestaand script en pas deze aan zodat het ownCloud log wordt uitegelezen en in Logwatch wordt uitgespuugt.

2a. waar staat het script?

nano /etc/logwatch/conf/logfiles/owncloud.conf

# The LogFile path is relative to /var/log by default.
# You can change the default by setting LogDir.
LogFile = /var/log/owncloud/*.log

# This enables searching through zipped archives as well.
Archive = /var/log/owncloud/*.gz

# Expand the repeats (actually just removes them now).
*ExpandRepeats

2b. wat moet in de email?

nano /etc/logwatch/conf/services/owncloud.conf

# The title shown in the report.
Title = “ownCloud”

# The name of the log file group (file name).
LogFile = owncloud

2c. welke regels wil je zien?

Hier is een eenvoudig voorbeeld voor een script dat het volledige log van de voorgaande dag in de email opneemt:

#!/usr/bin/perl

#ownCloud standard environment variables
$DateRange = $ENV{‘LOGWATCH_DATE_RANGE’} || yesterday;

if ($DateRange =~ /yesterday/) {
$epoc = time();
$epoc = $epoc – 24 * 60 * 60; # one day before of current date.
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($epoc);
$DateString = sprintf(“%04d-%02d-%02d”, $year+1900, $mon+1, $mday);
$DateString = $DateString.”T”;
}

while (defined($ThisLine = <STDIN>)) {
$ThisLine =~ s/\\//g;
$ThisLine =~ s/%20/ /g;
$FullLog{$ThisLine}++;

#filter for datarange yesterday
if ( ($DataRange = yesterday) and ($ThisLine !~ /$DateString/) ) {
#don’t care about these
}
else {
# Report any unmatched entries…
chomp($ThisLine);
$Unmatched{$ThisLine}++;
}
}

if (keys %Unmatched) {
print “\n**Unmatched Entries**\n”;
foreach $ThisOne (keys %Unmatched) {
print ” $Unmatched{$ThisOne} Time(s): $ThisOne\n”;
}
}

exit(0);

Nu heb je het ownCloud log in Logwatch opgenomen. Maar het kan nog beter toch?

2d. maak het leesbaar

Het script in kale vorm plaatsen is een relatief simpel klusje. Als je simpelweg het gehele log wilt laten uitspugen, dan is dit gelukkig niet moeilijk. Het bovenstaande script laat het volledige log in de email meesturen en haalt een aantal ‘onleesbare’ tekens eruit (de \ en de%20) en vervangt deze.  Echter om de gegevens in een beter interpreteerbare vorm te krijgen zul je nog wat moeten tweaken. Dit is nog ‘work in progress’.

Hierbij kunnen de volgende linux instructies van pas komen:

Test het script:

cat /owncloud/owncloud.log | perl /usr/share/logwatch/scripts/services/owncloud

Test logwatch:

logwatch –detail high –mailto name@domain.com –service all –range yesterday

 

 

ownCloud log in Logwatch deel 1

Wanneer je ownCloud gebruikt als eigen cloud zul je er snel achter komen dat je nog steeds moet inloggen om het ownCloud log te bekijken. Daarvoor is deze post. Het geeft antwoord op de vraag:

“Hoe zorg ik dat het ownCloud log in Logwatch worden opgenomen?”.

Het antwoord is uiteindelijk vrij simpel, maar ik heb het volledige antwoord nog nergens kunnen vinden. Daarom deze instructie. Omwille van de lengte is deze in twee delen opgesplitst. Dit eerste deel gaat over het inrichten van ownCloud. Het tweede deel gaat over het inrichten van Logwatch zodanig dat deze het ownCloud log meeneemt. Lees het vervolg in ownCloud log in Logwatch deel 2!

Voorwaarde: een server met ownCloud en Logwatch

Over het bouwen van een ownCloud server en het installeren en configureren van Logwatch is veel informatie te vinden op het internet. Maar niet hoe je het ownCloud log in Logwatch opneemt. Daarom wordt hier niet ingegaan op bouwen van een server met ownCloud en Logwatch. Dit is de basis, als je dit kunt, dan is het configureren van Logwatch wat hierna wordt behandeld zeker binnen bereik.

Deel 1: ownCloud log directory

In ownCloud kun je op twee manieren de logs laten wegschrijven. Standaard worden deze in een afzonderlijke directory geplaatst (data directory). Maar het is ook mogelijk om deze in het systeemlog op te laten nemen. In dit geval wordt ervan uitgegaan dat het logbestand in een afzonderlijke directory worden geplaatst, /owncloud/owncloud.log

Stap 1a: zet de rechten goed

Zorg dat je webserver bij het owncloud log kan.

chown www-data:www-data /owncloud

chmod 770 /owncloud

chmod 660 /owncloud/owncloud.log

Stap 1a: owncloud.conf

Voeg de locatie van je log toe in het owncloud configuratie bestand.

nano /var/www/owncloud/config/owncloud.conf

‘logfile’ => ‘/owncloud/owncloud.log’,

Stap 1c: log rotatie

Omdat het roteren van logs door het programma logrotate specifieke rechten vereist, heb ik ervoor gekozen een cronjob aan te maken waarin het log dagelijks wordt geroteerd:

nano /etc/cron.daily/00logwatch

#!/bin/sh
DATE=`date +%Y%m%d`
logwatch –detail high –mailto name@domain.com –service all –range yesterday
mv /var/log/owncloud/owncloud.log /var/log/owncloud/owncloud$DATE.log
gzip /var/log/owncloud/owncloud$DATE.log

 

Raspberry PI 3

De Raspberry PI 3 is kort geleden uitgebracht, is beschikbaar in Nederland en mensen zijn aan het besluiten of ze er een willen kopen of niet. Er zit een snellere 64 bits processor in en heeft ingebouwde wifi en bluetooth.

Tijd voor een vergelijking dus.

  Raspberry Pi 3 Model B Raspberry Pi 2 Model B
CPU Cortex-A53 Cortex-A7
Processor Speed QUAD Core @1.2 GHz QUAD Core @900 MHz
Platform 64Bit ARM 32Bit ARM v7
Processor Chipset Broadcom BCM2837 64Bit Quad Core Processor powered Single Board Computer running at 1.2GHz Broadcom BCM2836 32Bit Quad Core Processor powered Single Board Computer running at 900MHz
GPU Dual Core VideoCore IV Multimedia Co-Processor Dual Core VideoCore IV Multimedia Co-Processor
GPU speed Dual Core Dual Core
RAM 1GB SDRAM 1GB SDRAM
RAM speed 900 MHz 400 MHz
Storage MicroSD MicroSD
USB 2.0 4x 4x
Max Power Draw/voltage 2.5A @ 5V 1.8A @ 5V
GPIO 40 pin 40 pin
Ethernet 10/100mb Ethernet RJ45 Jack 10/100mb Ethernet RJ45 Jack
WiFi 10/100 ethernet, 802.11n Wireless LAN No
Bluetooth Bloothooth 4.0 & Blootooth Low Energy (BLE) No
HDMI 1x 1x
Audio 3.5 mm analoge audio-video jack 3.5 mm analoge audio-video jack

De conclusie is eenvoudig. Als je een beetje pit wilt voor een server of een htpc dan is deze Raspberry pi3 een aanrader. Hij trekt net wat meer amperes, maar het voltage is gelijk.

Het blijft jammer dat er geen Gigabit ethernet op zit. Voor HD content en het lezen en schrijven naar een schijf is het ruim voldoende, maar wanneer je een ssd of snelle raid opstelling hebt is dit nog een ‘killer feature’. Vooral ook voor het ‘servicen’ van meerdere connecties van/naar je server. Natuurlijk moet dan je internet verbinding (ik ga even uit van glasvezel i.v.m. de uploadsnelheid) dit toestaan.

HTPC kiezen?

Welke HTPC kiezen? Tegenwoordig zijn er zoveel HTPC mogelijkheden.

Als voorbeeld mijn geschiedenis: eerst maakte ik een eigen kast omdat er nog niet veel kleine pc’s waren, toen kocht ik een kleine kast en zette die onder mijn tv, vervolgens kocht ik een nog kleinere kast die ‘fanless’ was, daarna kocht ik een Raspberry PI.

Dus welke HTPC kiezen?

Het maken van een eigen kast raad ik af, een kleine pc raad ik ook af wegens het geluid van fans en hoe deze er veelal uitzien, dus luid het advies te kiezen uit de volgende vier opties:

  1. gebruik gewoon de meegeleverde functies op je tv of de setup box van je tv provider als je daar genoeg aan hebt
  2. koop een apple tv  als je een apple fan bent
  3. koop of bouw een raspberry pi2 media centre als je een ‘out of the box’ stille oplossing wilt, niet veel geld kwijt wilt zijn en vooral KODI gebruikt.
  4. koop of bouw een fannless pc en plaats die onder je tv als je meer wilt van je mediacentre

Onder mijn tv staat een fannless chassis met cd speler zodat ik die films op cd nog kan afspelen en en de kleinsten spellen kunnen doen op de tv. Ik overweeg om deze te vervangen door een raspberry pi, maar moet dan een alternatief vinden voor de cds en de spelletjes.

Kodi legaal gebruiken

banner-sbs-11-600x336De laatste tijd is Kodi in combinatie met de Raspberry Pi een populaire manier om een media center te maken. Met de komst van de Raspberry Pi 2 is de performance hiervan zelfs acceptabel te noemen. Echter de wet en regelgeving is ook aan het veranderen en in Nederland is het sinds 2014 niet meer legaal om beschermd materiaal te downloaden. Kodi zelf is legaal, maar er bestaan add-ons die niet legaal meer zijn. Op welke manier kan ik Kodi legaal blijven gebruiken?

Stichting Brein zegt echter dat de individuele downloader niet aangepakt zal worden, maar wil je als consument dit risico wel lopen? In Duitsland worden al boetes uitgedeeld van 800 euro of meer. Hoe lang zal het nog duren voordat stichting Brein haar beleid aanpast en ook achter de individuele downloader aangaat? En wie zegt dat Duitsland niet in Nederland boetes gaat opleggen? Het staat de rechthebbende immers vrij om achter de individuele downloader aan te gaan voor verhaal.

Hierdoor rijst de vraag hoe je legaal gebruik maakt van Kodi als je eenmaal zo’n prachtig apparaatje hebt. Het antwoord is vrij simpel te geven: gebruik alleen de plugins uit de Kodi repository. Deze zijn gescreend op illegaliteit. Als je toch andere plugins wilt gebruiken, vermijd dan de plugins en repositories die zijn vermeld op deze pagina.

Overwegingen voor een server

serverMet het werkend krijgen van een HTPC of een media center ontstaat (in ieder geval bij mij) als snel de behoefte om ook een server te bouwen en neer te zetten.

Een server biedt heel veel mogelijkheden om media te delen en te streamen.

Met Kodi is het bijvoorbeeld mogelijk om (wanneer de server een tuner heeft die het dvb-c signaal decodeert) vanaf een server een digitale tv signaal te ontvangen. Dit is legaal zolang je per tuner een kaart heb voor het decoderen, niet boven het aantal toegestane kaarten uitgaat, en niet boven het aantal apparaten uitgaat waarop je van de provider mag kijken.

Na enig uitzoekwerk heb ik een van mijn PC’s ingezet als server en inmiddels werkt dit prima. Een keurige 4 threaded cpu (dual core) met virtualisatie mogelijkheden. Deze draait op ubuntu 14.04 met daarop enkele kvm virtuele machines. Aangezien het inmiddels lekker werkt blijkt ook het kostenaspect in beeld te komen.

Als een server 24 uur per dag aanstaat kost dit geld. Voor 5 Watt (Raspberry Pi) betaal je ongeveer 7 euro per jaar. Voor een gewone dual core (65 watt) gaat dit al naar zo’n  90 euro per jaar. Nu zal deze niet altijd 65 watt vragen in idle stand, maar met een 4-tal harde schijven (4x5watt) in btrfs raid opstelling plus en wat randapparatuur zoals een tuner en een kaartlezer loopt dit al snel op.

Hierdoor wordt het minder interessant om zelf een server te draaien die altijd aan staat, en dat is uiteindelijk wel het doel van een server. Het wordt daardoor zinvol om te gaan zoeken naar alternatieven. Ik bedacht er zo een aantal.

Als eerste oplossing heb ik de server ingesteld dat deze na enige inactiviteit op ‘idle’ springt (in mijn geval s3). Dit werkt als een speer. In idle stand kost het minder energie. Een nadeel is echter dat er een wake on lan packet nodig is om deze aan te zetten. Nu zijn er in bijvoorbeeld Kodi plugins die dit kunnen, maar het automatisch aan- en uitzetten via Kodi vind ik niet geweldig werken. Bijvoorbeeld Advanced Wake On Lan werkt wel, maar stuurt bijvoorbeeld bij opstarten een signaal en niet ‘on demand’. Hierdoor wordt de server vaak onnodig aangezet en ook dit werkt niet altijd vlekkenloos. Dit is dus alles bij elkaar (nog) niet de meest geweldig oplossing. Er is inmiddels een oplossing in Kodi voor het ‘on demand’ aanzetten van de server, maar ook dit werkt niet altijd ‘on demand’. Bijvoorbeeld wanneer je de tv server wilt gebruiken (via tvheadend) wordt verwacht dat de tv headend plugin de tv server aanzet. Helaas is dit dus ook niet de oplossing.

Als tweede oplossingsrichting kun je denken aan een 5 watt server met een Raspberry Pi. Dit lijkt geweldig, maar dan heb je nog altijd de randapparatuur die ook stroom gebruikt. Deze zul je moeten ‘idlen’ bij inactiviteit. De Raspberry Pi heeft geen pci, geen gigabit en geen sata (wel 4 usb poorten, maar dit is USB 2 en dus een stuk minder snel dan sata of (‘snelle’) usb 3. Ook draait de Raspberry Pi op ARM en nog niet iedere software ondersteunt dit platform. Het bouwen van en volwaardige server op de Pi is dus nog een uitdaging.

Als derde oplossing kun je denken aan een ‘volwaardige’ amd64 server op Intel architectuur, maar dan met een laag wattage. Het nadeel is hier dat dit een stuk duurder is en dat de mogelijkheden nog beperkt zijn wanneer de hardware een laag wattage heeft. Een 35 wat server is haalbaar wellicht zelfs lager, maar een server op 5 watt (bijvoorbeeld een Atom server) levert vooralsnog een uitdaging op. Kortom als je een server wilt met echt laag energie gebruik, dan zul je nog wat uitzoekwerk moeten doen en is het op dit moment nog maar de vraag of het je lukt dit te bouwen.