Al een tijdje had ik een probleempje met de webmail. Zo lukte het mij maar niet om bijlagen met e-mail mee te sturen. Dit probleem had ik steeds op de lange baan geschoven.
Nu merkte ik de afgelopen paar dagen dat ik het mij niet lukte om met WordPress bestanden te uploaden. Eerst bestond dan de directory niet waar ik dan naartoe moest uploaden, dus dan gaat het niet.. Maar na het aanmaken ervan en het voldoende rechten toekennen lukte het nog steeds niet. Ook had ik al in de log-bestanden gekeken, maar ook hierin zag ik geen foutmeldingen voorbij komen.
Alleen vanavond zag ik toch ineens dat er toch wel foutmeldingen komen, maar dan in /var/log/debug Lijkt mij op de verkeerde locatie, maar goed… Toch staat daar dan de volgende foutmelding:
Aug 17 15:25:41 papua lighttpd[28819]: (mod_fastcgi.c.2605) FastCGI-stderr: PHP Warning: Unknown: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/servers/) in Unknown on line 0
Aug 17 15:25:41 papua PHP Warning: File upload error – unable to create a temporary file in Unknown on line 0
Ofwel: gewoon een foute instelling in PHP. Nadat ik die had aangepast ging het gelukkig wel goed! Alleen heb ik nu nog wel een soort gelijke foutmelding met een plug-in onder WordPress. Daar ga ik nu even snel naar kijken!
Op mijn werk merkte ik op dat ik daar Add-on voor Firefox gebruikte. Dat is namelijk Ghostery. Hiermee kan ik zien naar welke andere websites de bezoekende website jouw informatie naartoe stuurt of informatie vandaan haalt. Dit is in de meeste gevallen voor statistieken of advertenties. Reuze handig om dit zo te kunnen zien!

Ghostery in actie!
Je kan ook per externe website aangeven of dit geblokkeerd moet worden of niet. Ook het aantal externe websites kan je laten zien. Deze add-on voor Firefox vind ik dan ook wel reuze handig.
Vandaag ben ik bezig geweest om NLLINUX weer wat nieuw leven in te blazen. Gisteren opende ik daarvoor nog een Twitter-account. Nu dus de website zelf. Hiervoor heb ik gekozen voor Wordpress. Nu is het dus mogelijk om meerdere websites te laten doen met één Wordpress installatie, maar hiervoor heb ik dus niet gekozen. Zo heb ik dus een nieuwe Wordpress installatie gedaan. Hierdoor kan ik wat meer website specifieke dingen eenvoudiger doorvoeren. Zo ga ik daar weer plug-ins gebruiken die ik hier weer niet ga gebruiken.
Ook heb ik vandaag nog een nieuwe logo gemaakt voor de website. Dat ziet er wel goed uit. Al zeg ik het zelf.
De komende 2 weken ga ik de installatie testen en mogelijk al wat artikelen schrijven. Je kan het al bewonderen tot 1 september op deze locatie. Wil je gaan mee helpen aan de nieuwe NLLINUX website dan kan dat natuurlijk. Geef mij maar een gil en dan komt het wel goed.
Een paar dagen geleden heb ik ook het domein nllinux.nl een e-mailadres gegeven. Ik vond het meteen al opvallend rustig qua e-mail. Al vond ik vanmiddag al wel één SPAM-bericht op dat e-mailadres. Verder nog niks.
Nu ging ik een Twitter-account koppelen aan dat nieuwe e-mailadres. Nu gaf Twitter aan dat het geen e-mail kon verzenden naar dat e-mailadres. Dus ik ging dat ook even uitproberen. Intern versturen ging anders wel prima naar dat adres toe! Vanaf dat adres naar welk adres dan ook ging ook prima. Alleen extern naar dat e-mailadres ging fout.
Ik ben de instellingen van Postfix gaan nagelopen en ik vond niks geks. Daarna zag ik ook niks verkeerds staan bij de DNS-instellingen in BIND, maar dat zag ik toen verkeerd. Ten eerste was het adres van de mailserver fout. Daar stond adeliae.pygoscelis.tk i.p.v. papua.pygoscelis.tk. en inderdaad óók moest daar nog een punt achter. Ondertussen heb ik het nu goed ingesteld staan en ontvang ik daar weer externe e-mail. Hopelijk valt de SPAM mee…
En dan moet ik nog de rest van het systeem back-uppen… Alleen ben ik nog aan het nadenken over hoe ik dat nu het beste kan doen. Het grootste probleem is dat het nogal groot kan worden. En om dan daar elke dag een copy per e-mail te gaan versturen, tja dat zal niet gaan werken! Dan kan je ervoor kiezen om alleen de verschillen te gaan updaten, maar zelf zie ik dat eigenlijk niet helemaal zitten. Dat kan goed gaan… of geheel de mist in! Dat laatste hangt weer af van de methode van herstellen van de back-up. Aan dat laatste daar wil ik niet te veel aandacht aan besteden. Dat klinkt gek, maar dat is zo! Meestal heb je een back-up pas nodig wanneer het goed mis is gegaan. En dan doe je het altijd anders dan het eerst was wanneer je het gaat herstellen.
Ik ga waarschijnlijk onderscheid maken tussen welke data ik ga back-uppen. Dan is alleen de data en de configuratie belangrijk. De data staat her en der verspreid over de server. De configuratie pas je nou ook weer niet elke dag aan. Maar is vaak slechts beperkt in de grootte, dus dat valt nog wel te mailen elke dag of alleen wanneer er veranderingen zijn ten opzichte van de vorige back-up.
Voor grotere back-ups moet ik nog kijken hoe ik dat dan het beste kan back-uppen. Mogelijk via rsync waarmee ik dan de bestanden synchroniseer op een andere pc. De komende tijd ga ik dit allemaal uitzoeken! Wanneer ik dan ga overstappen op Arch Linux dan kan ik meteen testen of dat het back-uppen dan werkt.
Op dit moment ben ik bezig om op mijn server back-ups in te stellen. Ik ben nu begonnen om eerst de database te back-uppen, want dat is het moeilijkste te herstellen.
Nu zijn er tig methodes om een back-up te maken. Ze hebben allemaal zo hun voor en nadelen. Dus ik heb er zelf eentje gekozen welke ik eenvoudig kan instellen. Nu heb ik gekozen om één BASH-script te maken dat al mijn handelingen doet. Dit script laat ik dan weer door een cronjob elke dag uitvoeren. Eenvoudig toch?
Dat BASH-script laat ik door mysqldump een dump maken van de database. Zo moet ik dan voor elke database een mysqldump maken. Vervolgens laat ik al die dumps inpakken in één bestand. Dit bestand mail ik dan naar een Gmail-account toe. Dus in elk geval niet naar een mailbox die op mijn eigen server staat, want dat zou ‘een beetje dom zijn’.
Zo ziet mijn script eruit (met natuurlijk alle belangrijke data eruit):
#!/bin/bash
# mail setup
MAILSUB=
"Backup (`echo $USER @ $HOSTNAME`) as on `date`"
MES=~
/scripts
/mes.txt
mysqldump –user gebruikersnaam –password=mijnwachtwoord databasenaam > /back-up/sqldata/db_databasenaam.sql
# En dit dan herhalen totdat ik elke database gehad heb!
cd /back-up/sqldata/
filename="db_daily_"`eval date +%Y%m%d`".tgz"
tar -zcvf $filename *.sql
mutt e-mailadres@gmail.com -s "$MAILSUB" -a "$filename" < $MES
Met hierin opgemerkt dat ik nog een tekstbestandje heb aangemaakt ~/scripts/mes.txt met daarin de boodschap in de e-mail, want anders vraagt mutt daarom en dat wil je NIET!
Momenteel moet WordPress door iedere gebruiker ge-update worden. Dit vanwege een flinke beveiligingsbug. En de beveiliging van WordPress stond al niet erg hoog aangeschreven. Nu gebruik ik voor deze blog dus ook WordPress en op een andere site wil ik het eigenlijk ook gaan gebruiken. Maar of dat nou wijs is???
Zie over de bug deze link.
Maar ondertussen is op deze weblog dus WordPress weer up-to-date!
Vanavond heb ik mijn domein degroot.info eens van wat inhoud voorzien. Een tijdlang stond hier niet erg veel op. Aangezien ik dit domein graag voor een goede prijs wil verkopen is het handig om eventueel geïnteresseerde kopers daar op te wijzen. Ook heb ik er gelijk een stukje code eraan gevoegd, zodat ik via Google Analytics kan zien hoeveel bezoekers er eigenlijk op dit domein zonder noemenswaardige inhoud afkomen.
Hopelijk komt er een aannemer langs die dat domein wil overnemen in ruil voor een nieuw huis wat ik wil bouwen.
Maar dat zal denk ik niet.
Soms dan word ik gek van Gentoo Linux. Op zich is het systeem heel mooi. Er wordt van alles bijgehouden wat nu wat nodig heeft. Al klopt dat niet altijd… Of wil het je systeem om zeep helpen als je persé wil proberen sommige updates er door te duwen. Maar ja Gentoo vraagt erom, want anders kan je niks meer updaten.. Nu ook weer een apart geval:
papua ~
# emerge -upvNk world
These are the packages that would be merged, in order:
Calculating dependencies… done!
!!! All ebuilds that could satisfy ">=sys-apps/util-linux-2.16" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/util-linux-9999 (masked by: package.mask, missing keyword)
/etc/portage/package.mask:
# >=sys-fs/e2fsprogs-1.41.0
- sys-apps/util-linux-2.16 (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "sys-fs/udev-145" [ebuild])
(dependency required by "world" [argument])
Wat hier boven staat zegt eigenlijk dat udev ge-update moet worden naar versie 145. Dat laatste doe ik niet, want dan krijg ik serieus problemen. Dan is er een nieuwere kernel nodig waar ik niet over beschik.
Maar goed om die nieuwe udev te installeren moet util-linux worden ge-update. Dit kan ik ook weer niet doen, want dan moeten ook ss en com_err worden ge-update, waardoor ook e2fsprogs en e2fsprogs-libs worden ge-update. En dan heb je een bak ellende!! Op 2 Gentoo installaties heb ik dat probleem al gehad. Hierdoor gaan een paar essentiële programma’s op kapot, zoals wget en rpm. Bij het updaten van software kan je die weleens nodig hebben, waarbij rpm in mindere mate onder Gentoo.
In /etc/portage/package.mask heb ik niet voor niks de volgende regels staan:
>sys-libs/e2fsprogs-libs-1.40.9
>sys-fs/e2fsprogs-1.40.9
>sys-libs/com_err-1.40.9
>sys-libs/ss-1.40.9
>=sys-apps/util-linux-2.14.1
Om de spaghetti die Gentoo heeft gemaakt op te lossen en om te voorkomen dat udev versie 145 wil installeren heb ik de volgende regel in /etc/portage/package.mask toegevoegd:
Hierna kan ik mijn Gentoo machine weer gewoon updaten:
papua ~
# emerge -upvNk world
These are the packages that would be merged, in order:
Calculating dependencies… done!
[ebuild U ] dev-db/sqlite-3.6.17 [3.6.16] USE="threadsafe -debug -doc -soundex -tcl" 2,859 kB
Total: 1 package (1 upgrade), Size of downloads: 2,859 kB
Ik wilde de links hier op deze weblog (Wordpress) wat korter hebben. Eerst stond er in elke url nog index.php en dat wilde ik niet. Nu is Wordpress voornamelijk gemaakt dat je dan Apache als webserver hebt. Dus dan moet je een .htaccess bestand hebben om dat mogelijk te maken. Nu ondersteund lighttpd geen .htaccess bestanden. Maar met de mod_rewrite module kan ik zo wel de urls korter laten schrijven. Hiervoor stond gelukkig de module mod_rewrite ergens bovenin al ingeschakeld in het /etc/lighttpd/lighttpd.conf
Verder was het voor deze weblog nog een blokje invoegen:
url.rewrite = (
“^/(.*)\.(.+)$” => “$0″,
“^/(.+)/?$” => “/index.php/$1″
)
En wel zodat:
$HTTP["host"] == “stefan.diario.tk” {
server.port = 80
server.document-root = “/var/www/servers/diario.tk/stefan/htdocs/wordpress/”
url.rewrite = (
“^/(.*)\.(.+)$” => “$0″,
“^/(.+)/?$” => “/index.php/$1″
)
#server.bind = “www.diario.tk”
accesslog.filename = “/var/log/lighttpd/stefan.diario.tk-access.log”
server.errorlog = “/var/log/lighttpd/stefan.diario.tk-error.log”
}
Hierdoor zijn de urls op deze weblog nu een stuk mooier.
Alleen is mod_rewrite géén tovermiddel! Het nadeel eraan schijnt te zijn dat mod_rewrite niet kan controleren of dat bestanden wel of niet bestaan. Nu ondersteund lighttpd ook LUA-script m.b.v. de module mod_magnet maar hoe dat allemaal werkt moet ik nog eens een keertje uitzoeken!