Category: Linux

WordPress Upgarde + SSL

Gisteren heb ik op mijn Raspberry Pi bij PCExtreme een proxy geïnstalleerd om zo mijn blog via https aan te bieden. Nu is enkel de verbinding op het netwerk van PCextreme onbeveiligd. Daarnaast is WordPress upgradet naar 3.9. Er werd nog een oude versie gebruikt, en ik botste dan ook op een probleem dat blijkbaar geïntroduceerd werd in versie 3.5. Sindsdien wordt de keuze tussen http en https in door WordPress gegenereerde URL's niet meer (alleen) gebaseerd op de URL uit de instellingen, maar (ook) op $_SERVER['HTTPS'], maar dat werkt natuurlijk niet aangezien de encryptie pas start vanaf de proxy. Er bestaat echter een plugin die dit oplost, al heb ik die wel aangepast, aangezien de JavaScript code volgens mij meer problemen kon veroorzaken dan oplossen.

Er is echter nog een klein ongemakje. Met name de editor plugin werkt niet meer, maar dat is geen prioriteit. Het is geen zo'n last om de bbcodes zelf te typen.

De proxy, daar had ik 2 opties, met name stud of nginx. Ik had eerst stud genomen, maar dan had ik enkel nog https, waardoor alle oude links niet meer zouden werken, en daarom koos ik toch voor nginx, via het pakket nginx-light. Bij stud had ik wel eerst een ander probleem, want het werkte gewoon niet. Uiteindelijk bleek het opgelost te zijn door de crt en key file samen te voegen in één pem file. Uiteindelijk koos ik dus voor nginx, en voor dit blog gebruik ik de volgende config:

server {
	listen blog.online-urbanus.be:443;
	ssl on;
	server_name blog.online-urbanus.be;

	ssl_certificate blog.pem;
	ssl_certificate_key blog.key;

	ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:ECDH+AES128:DH+AES256:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
	ssl_prefer_server_ciphers on;

	error_log /dev/null;
	access_log /dev/null;

	location / {
		proxy_pass http://blog.online-urbanus-be.nl02.members.pcextreme.nl:80;
		proxy_redirect off;
	}
}

server {
	listen 80;
	server_name blog.online-urbanus.be;

	error_log /dev/null;
	access_log /dev/null;

	return 301 https://blog.online-urbanus.be$request_uri;
}

De SSL configuratie is gebaseerd op dez pagina.

Daarnaast is ook de password hashing gewijzigd, zodat nieuwe wachtwoorden niet langer md5 zullen gebruiken.


Motif

Van tijd tot tijd gebruik ik wel eens Athena van de UGent. Probleem is echter dat daarvoor de non-free Citrix client nodig is, en die is enkel beschikbaar voor 32-bit systemen. Er is weliswaar een 64-bit pakket, maar dat werkt dus niet met et nieuwe multiarch systeem. Nu, een tijdje geleden, ik vermoed dat het op het einde van vorig semester was, concludeerde ik dat ook libmotif4:i386 nodig is voor een correcte werking.

Onder wheezy is dat nog non-free, maar inmiddels is dit beschikbaar onder de LGPL. Dus, ik heb maar even de nieuwe versie gebackport naar wheezy, zo hoef ik dus geen non-free pakket te installeren, al blijf ik natuurlijk zitten met de Citrix client zelf ...

01/04/2014, 18:39:
Nu weet ik het weer, het was voor de configuratie, die vereist motif.


GRUB Default kernel

Bij ons thuis in Eggewaarts zijn er al een tijdje verbouwingen aan de gang. In november werd er gewerkt aan de elektriciteit, en daarbij is de elektriciteit ook even uit geweest, waardoor mijn server offline was, en bijvoorbeeld alle opnamen van TV stopten. Nu had ik een dag daarvoor wat zitten rommelen in het BIOS van mijn computer in Gent, en daarbij werd ik er aan herinnerd dat je in het BIOS doet na een stroomonderbreking: de computer opstarten, de toestand (aan/uit) van voor de onderbreking herstellen, of uit laten. En dit heb ik dus toegepast op mijn server thuis.

Dat was echter nog niet voldoende, want voorlopig draaien de virtuele servers nog OpenVZ, tot ik eens tijd vind om over te schakelen op LXC. Tot dan gebruik ik de OpenVZ-kernel van Debian Squeeze. Dat wil echter wel zeggen dat ik niet wil dat de server start met de nieuwste kernel, want dat is natuurlijk de standaard kernel van Debian Wheezy. Ik wil dus dat automatisch de derde kernel in GRUB geselecteerd wordt.

Na wat opzoekwerk vond ik deze website en heb ik de volgende regel aangepast in /etc/default/grub:
GRUB_DEFAULT=2


Raspbmc naar OpenELEC

Toen ik vorig jaar mijn IR-receiver ontving heb ik Raspbmc op mijn Raspberry Pi geïnstalleerd. Dit deed ik vanwege het feit dat ik zo zowel een kleine Debian-server als een mediaspeler kon maken van mijn Raspberry Pi. Het was echter al een hele tijd (zo ongeveer altijd?) dat de apt-database enkele fouten bevatte, in die zin dat een aantal pakketten steeds errors gaven. Daarnaast begon ik me ferm te ergeren aan het feit dat er, in plaats van gebruik te maken van het uitstekende apt-systeem van repositories met Debian pakketten, er een eigen update systeem gebruikt werd, wat voor heel wat mensen ook problemen bleek op te leveren bij elke update. Persoonlijk heb ik hier weliswaar geen last van gehad, of toch zeker niet zo vaak als vele anderen, maar nu had ik in december een probleem dat de Raspberry Pi constant vast liep tijdens het afspelen van bestanden.

Het was praktisch onbruikbaar geworden, en aangezien Raspbmc steeds verder afweek van Raspbian/Debian heb ik beslist om OpenELEC te proberen. Die laatste zou sneller moeten zijn, stabieler, en samenhangender, maar heeft als nadeel dat het praktisch onmogelijk is om zelf software toe te voegen. Toch heb ik besloten OpenELEC op zijn minst eens te proberen, aangezien Raspbmc toch niet meer te doen was, en ik liever een paar beperkingen heb, waar ik dan misschien uiteindelijk rond kan werken, dan steeds schrik te moeten hebben of de update wel zal werken, en of de vele vertragingen van de laatste updates misschien terug een beetje ongedaan gemaakt zullen worden ...

Enfin, ik heb in december uiteindelijk OpenELEC geïnstalleerd, en dat was wel een grote verbetering qua prestaties. De Raspberry Pi presteerde bijna beter op stock speed met OpenELEC dan ferm overklokt met Raspbmc. Uiteindelijk heb ik toch nog een kleine overklok gedaan, en op deze manier heb ik toch een mooie prestatiewinst.

Van de beperkingen heb ik eigenlijk weinig last. In de praktijk doe ik namelijk maar 1 ding buiten de functionaliteit van XBMC, en dat is met name het tunnelen van verschillende poorten van mijn netwerk in Eggewaartskapelle. Met Raspbmc deed ik dit met een daemon met autossh. Wat ik nu gedaan heb is de basisfunctionaliteit van autossh met behulp van enkele shellscripts. Die scripts worden opgeroepen door een cronjob die elke 5 minuten wordt uitgevoerd:
*/5 * * * * /storage/bin/sshtunnel.sh 9981 192.168.1.4:9981

#!/bin/sh
echo "" | nc localhost $1
if [ $? -ne 0 ]; then
	killall ssh
	ssh -TCNgL $1:$2 kevin@paretje.dyndns.org &
fi

De 2de regel van de code test hierbij of er enige reactie is op de lokale poort van de tunnel. Indien niet, dan wordt een nieuwe tunnel gestart. Dit doet in de basisch ongeveer hetzelfde als wat ik verwachte van autossh. Dat wil wel zeggen dat er altijd tot zo'n 5 minuten vertraging is wanneer er een probleem is, of wanneer OpenELEC opgestart is.

Verder is er maar een ding spijtig: het is enkel mogelijk als root gebruiker in te loggen via ssh. Het is ook onmogelijk om een nieuwe gebruiker aan te maken, er is immers geen volledige omgeving die je tegenwoordig zou mogen verwachten. OpenELEC is immers bedoeld voor de beste prestaties als mediacenter, niet als een volledig OS.


Citrix ICA Client

Om gebruik te maken van Athena, wat van tijd tot tijd handig/noodzakelijk is, heb je de Citrix ICA Client nodig. Spijtig genoeg is dit proprietary software, en (dus?) binary-only. Ze bieden een deb aan, voor zowel i386 als amd64. Echter, de 64-bit versie maakt gebruik van, voor Debian, verouderde concepten. Het lijkt er op dat het 32 bit software is, echter steunt het pakket nog op allerlei compatibiliteits-lagen, terwijl Debian overgestapt is naar multiarch. Die verouderde lagen zitten zelfs niet meer in de Debian repo's voor Wheezy. Nu kan ik eventueel nspluginwrapper van squeeze of zelfs Ubuntu proberen, echter wist ik al via mail dat die weg toch, naar alle waarschijnlijkheid zou floppen.

Wat ik dus deed was multiarch activeren:

dpkg add-architecture i386
apt-get update

En nu het i386 pakket installeren. Nu gaf dit een error op, omdat op lijn 696 van het postinst-script nspluginwrapper werd opgeroepen. Blijkbaar controleerde het script zelf nog eens de architectuur, en riep dan maar nspluginwrapper op, die uiteraard niet geïnstalleerd stond, het was uiteindelijk ook geen dependency, en zou dus nooit mogen opgeroepen worden door het script. Nu dat aanpassen leverde dan later in het script een fout op, en wou niet zo mijn hele systeem laten vervuilen, en heb in prerm dezelfde wijzigingen doorgevoerd en het pakket verwijderd. Vervolgens heb ik de tar.gz gedownload, uitgepakt en de bestanden gewoon in ~/bin geplaatst. Vervolgens het root certificaat voor Athena toegevoegd aan ~/bin/icaclient/linuxx86/linuxx86.cor/keystore/cacerts.

Toen ik naar Athena surfte en een programma aanklikte wist Iceweasel uiteraard niet wat te doen met het bestand, aangezien er geen plugin geïnstalleerd is, enkel de bestanden in een lokale map uitgepakt, en geen enkel installatiescript uitgevoerd werd. Echter, gewoon het bestand laten openen met ~/bin/icaclient/linuxx86/linuxx86.cor/wfica "does the trick".

Dit bleek echter nog niet voldoende, en er kwamen errors over missende ini's. De oplossing was de ini's uit linuxx86/linuxx86.cor/nls/en te kopiëren naar linuxx86/linuxx86.cor/config. Nu werkt het!

Echter, we zijn nog niet klaar. Immers, de libraries die geïnstalleerd werden met icaclient, die zouden met een autoremove nu worden verwijderd. Dus moet ik die handmatig installeren. Nu, ik heb liefst zo min mogelijk handmatig geïnstalleerde pakketten, en dus heb ik eens getest welke nodig zijn om te voorkomen dat er pakketten verwijderd worden, en daarmee kwam ik tot het volgende:
apt-get install libgtk2.0-0:i386 libxmu6:i386 libxp6:i386 libxpm4:i386 libasound2:i386

Dit heeft één nadeel: wanneer de dependencies van één van die pakketten verandert, dan zou het in theorie kunnen dat ik ze opnieuw moet installeren, maar niet noodzakelijk. Maar zeker op gebied van libraries heb ik liefst niet (te veel) handmatig geïnstalleerde pakketten, dus doe ik het zo.


Horizontale offset

Een paar dagen terug wou ik terug beginnen aan mijn digitalisering, nadat het stil had gelegen om te gaan werken. Ik twijfelde echter of ik wel wou terug beginnen. Immers, ik had opgemerkt dat de nieuwe video speler een zeer goede beeldkwaliteit had, maar, zeker na digitalisering, viel het op dat de offset van de horizontale lijnen instabiel was/is. Na wat research bleek dat het feit dat dit niet zo was met de oude JVC te maken heeft met het feit dat de oude JVC naar alle waarschijnlijkheid een ingebouwde TBC had, aangezien het nu optredende effect een normaal effect is.

Hierdoor begon ik te twijfelen of ik wel verder wou gaan, en begon ik te denken wat de mogelijkheden waren. Zeker geen nieuwe videospeler kopen, noch een afzonderlijk apparaat, daarmee zou de kost van de digitalisering te hoog oplopen. Maar, ik zou wel kunnen vragen of ik de video-spelers van familieleden eens zou kunnen testen. Maar, uiteindelijk heb ik er vanaf gezien, immers, op die manier kan ik nog lang doorgaan, en weet ik nooit zeker of ik nu al dan niet kan beginnen. Daarnaast zijn dat allemaal oude spelers, waardoor dan weer het beeld zelf van lagere kwaliteit kan zijn. Daarnaast is het maar de vraag of ze dan TBC hebben, en heb ik dan misschien wel een jaar vergooid op het vlak van de digitalisering.

Ik zal dan ook gewoon meteen beginnen met het digitaliseren, maar enkel knippen met DVBCut, welke ook MPEG PS streams ondersteund, naast de TS streams van DVB(-T). Wanneer het dan klaar is zal ik dan eens moeten kijken om die storing weg te filteren. Eventueel door een eigen implementatie (of zelfs algoritme), eventueel met DeJitter voor AvxSynth. Die laatste is echter nog niet bepaald op punt gesteld, waardoor de kans relatief groot is dat ik gewoon eens zal uitzoeken als het moment daar is hoe ik zelf een filter kan schrijven voor Avidemux, eventueel aan de hand van de source code van DeJitter.


Debian Wheezy als server

Ik heb vandaag en gisteren mijn server thuis opnieuw geïnstalleerd. Op de server stond nog Ubuntu (10.04 LTS), het laatste apparaat waar ik nog geen Debian (Wheezy) op had gezet. Tijdens de installatie heb ik de volgende problemen gehad, de ene al wat groter dan de andere.

CUPS heeft de eer mijn eerste probleem te zijn. Het lukte niet die te benaderen vanaf mijn desktop, en een poging dit aan te passen in het config bestand lukte aanvankelijk niet. Uiteindelijk gewoon met behulp van elinks http://localhost:631 bezocht vanaf de server, en op die manier de server publiek gemaakt.

Mijn volgende probleem was wat serieuzer. Het lukte me namelijk niet om te scannen. Het is namelijk zo dat ook de scanner gedeeld is. Nu, tegenwoordig heb ik wel een via het netwerk aangesloten printer, maar toch is het zo handiger, want op die manier is het bvb niet noodzakelijk om alles op elke computer nog eens te installeren. Ik herinnerde me nog dat het me vroeger gelukt was via hp, hp-setup -i. Echter, nu lukte dit niet. Na dit uitgevoerd te hebben zag ik weliswaar op mijn computer de scanner, maar ik kreeg een error. Op de server via hp-scan en scanimage -L kreeg ik dezelfde meldingen. Na heel wat gezocht en geprobeerd te hebben, tot zelfs een brute backport van hplip, vond ik een aanwijzing in /var/log/syslog. Ik zag daar een reeks pogingen de all-in-one te vinden mbv mDNS. Dit lukte niet na 20 pogingen. En, toen bleek het pakket libnss-mdns niet geïnstalleerd te zijn, waardoor het niet werkte. Nu, door het brute backporten, uitvoeren van hp-plugin en een poging hp-check de problemen zelf te laten oplossen, heb ik voor de zekerheid opnieuw begonnen.

Als laatste probleem gold OpenVZ. Nu is het wel de bedoeling dit te vervangen in de toekomst, maar het is wel belangrijk dat de virtuele servers zo snel mogelijk terug online stonden, zodat er opnieuw backups gemaakt konden worden, etc. De bestaande containers zijn weliswaar i386, maar dit zou onder AMD64 geen probleem mogen zijn. Debian heeft OpenVZ echter afgeschreven onder Wheezy. De wiki geeft 3 opties, naast overschakelen op LXC. Ten eerste de packages van OpenVZ gebruiken, maar dat zijn Red Hat kernels (in rpm formaat) die via alien omgezet werden naar deb, en een andere was zonder gepatchte kernel werken met een van de nieuwe versies. Voor dat laatste moeten we zelf gaan compileren. Dat heb ik gedaan, maar het was voor mij niet duidelijk wat make install exact zou doen, en ik vervuil niet graag mijn systeem met bestanden verspreid over het systeem, zonder gebruik te maken van apt-get.

Dus, gepatchte kernels dan, want OpenVZ is wel nodig, ik moet eerst eens rustig de overstap naar LXC kunnen voorbereiden. Nu, de door OpenVZ aangeboden repo bevat dus door alien geconverteerde kernels, gebaseerd op Linux 2.6.32. En, daarom heb ik het iets anders gedaan. Ik heb gewoon de Debian Squueze repo toegevoegd aan mijn sources.list, want die zijn ook 2.6.32, maar tenminste gemaakt voor Debian, volgens de Debian normen. Dan moet ik maar eens kijken om in de komende maanden over te stappen op LXC.


Recommends met deborphan

Op 10 juli begon ik een post om even een manier te melden om echt alle verwijderbare pakketten te verwijderen. Deborhan is daar een heel goede tool voor, maar zal enkel libraries melden, maar ook die die je zelf handmatig geïnstalleerd hebt, en dat is niet helemaal wat het moet zijn. Toch brengt het vaak pakketten boven, die apt-get autoremove niet ziet. Het lijkt een veel eenvoudiger algoritme te gebruiken, dat echter in de praktijk dus vaak vollediger resultaten biedt.

Daarom heb ik me eens verdiept in de argumenten van deborphan tijdens de examens. Je kan er voor zorgen dat deborphan alle pakketten als overbodig ziet als ze niet op een lijst staan, of nodig zijn voor die pakketten. Met andere woorden, als we hem een lijst geven met alle manual gemarkeerde pakketten, dan is ons probleem opgelost.

Echter, om de een of andere reden werkt dit niet:
deborphan -k <( apt-mark showmanual ) -na

Hiermee krijgt deborphan een lege lijst, en mag ik dus alles verwijderen. Dit lost dit dus wel op:
apt-mark showmanual > /tmp/manual ; deborphan -k /tmp/manual -na ; rm /tmp/manual


VNC server

Nu is het zeer goed dat mijn computer nu automatisch wordt uitgeschakeld, maar zo wordt het wel onmogelijk om via de GUI nog iets te doen vanop afstand, want het tot noch toe gebruikte vino start pas op wanneer een gebruiker zich inlogt.

Het is echter dus de bedoeling dat reeds bij het inlogscherm een VNC server wordt opgestard. LightDM heeft standaard ondesteuning voor tightvncserver, maar dat is niet echt wat we willen, want dan starten we steeds een nieuwe sessie voor de VNC-server, inplaats van de algemene sessie over te nemen. Dit wordt vooral problematisch wanneer de connectie verbroken wordt in tussentijd, of in het algemeen bij langere taken.

Na wat zoeken bleek het wel te lukken met behulp van x11vnc. Ik heb nu het volgende in mijn /etc/lightdm/lightdm.conf:
greeter-setup-script=/usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -forever -bg -rfbport 5900 -o /var/log/x11vnc.log


Automatisch afsluiten

Het is al een hele tijd geleden dat ik er voor gezorgd heb dat mijn computer automatisch opstart wanneer ik iets wil opnemen, of toch in het geval hij nog niet opgestart is. Tot noch toe had ik echter nog steeds niet gedaan om hem ook terug af te sluiten.

Gisteren heb ik daar eindelijk iets aan gedaan. Naar aanleiding van de problemen die ik had met de computer van mijn moeder, was er ee hernieuwde interesse om dit nu eindelijk eens te doen, en op een manier waar geen afzonderlijke root cronjob opmijn computer zelf nodig was.

Als eerste dacht ik dus een policykit, en daar had ik het volgende commando voor:
dbus-send system print-reply dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop

Nu kreeg ik steeds het volgende:
Error org.freedesktop.ConsoleKit.Manager.NotPrivileged: Not Authorized

Nu, de oplossing zou moeten liggen in het starten van een sessie:
ck-launch-session

Echter, dit verhelpt het probleem niet. Mogelijk wordt het recht enkel toegekend aan de GUI, of is het omdat ik ook via de GUI ingelogd was, maar dat bleek het toch ook niet te zijn.

Uiteindelijk toch wat verder gekeken, en blijkt dat dit ook niet echt de beste manier zou zijn, vanuit een cronjob. Dus, lijkt het dan het beste dit op te lossen via sudo, en dus voegde ik de volgende lijn toe aan mijn /etc/sudoers file:
kevin ALL=(root) NOPASSWD: /sbin/shutdown