Online reizen boeken zit in de lift, het reisseizoen komt eraan, en verschillende reisorganisatoren prefereren boekingen via het internet. Toch zien we dat er niet of slecht geïnvesteerd wordt in de achterliggende IT of het netwerk, want de bedroevende uptimes zijn schrijnend. Het bedrijf “Watchmouse”, niet toevallig een aanbieder van uptime-monitoring diensten, voerde een onderzoek uit tussen 6 april en 9 mei naar de beschikbaarheid van reisorganisatoren en vliegtuigmaatschappijen. De resultaten zijn hier en hier te vinden. We zien duidelijk dat het merendeel goed scoort (99,9%/maand of meer), maar er is zelfs een bedrijf met een downtime van 1 dag, 12 uur en 27 minuten. Shocking!

Wat doen wij om een goede uptime te bekomen? Openminds heeft meerdere redundante BGP-transit links, en heeft een (nagenoeg volledig) redundant netwerk. Het inzetten van de aangekochte netwerkapparatuur zal het netwerk volledig redundant maken, zal ervoor zorgen dat ook bij DOS aanvallen en grote netwerkstoringen het netwerk sneller terug stabiel wordt, en meer kan “verdragen”. We zijn momenteel volop bezig met het testen van de nieuwe setup. Verder hebben we verschillende mechanismen die ons waarschuwen bij onregelmatigheden op het netwerk of de servers.

Wie zoeken we?
Een beginnende geek die ongelooflijk gemotiveerd is, basis kennis heeft van unix/linux en php/mysql programmatie, die wil bijleren en niet bang is om problemen met beide handen aan te pakken. We zoeken die hacker die regelmatig in zijn vrije tijd alles eraan doet om nog net dat ene bugje uit zijn setup te halen, en hiervoor niets schuwt, behalve de opkomende zon die de volgende dag aankondigt… Hij/zij krijgt van ons een voltijdse baan aangeboden in ons kantoor te Gent.

Ietwat kennis hier en daar is natuurlijk ook belangrijk, dus we zetten deze even op een rijtje:

• Unix kennis, minstens toch een jaar of 3 hiermee bezig zijn (mag tijdens uw vrije tijd zijn). De shell mag u niet afschrikken, en de kennis dat “grep”, “sed” en “awk” geen scheldwoorden zijn.
• PHP kennis. Veel projecten en systemen van ons zijn in PHP gebouwd, en dit is toch wel een vereiste.
• MySQL, of SQL in het algemeen. Een query kunnen maken is handig, want het meeste van onze data zit in databases.
• HTML/CSS kennis (je hoeft geen designer te zijn, daarvoor hebben we partners)
• Een rijbewijs B is een vereiste. Regelmatig moeten ingrepen gebeuren op de servers in de datacentra. Een eigen auto is zeker ook een pluspunt.
• Nederlands spreken en schrijven (geen SMS-turbo-taal aub, en liefst ook geen spelfouten) is ook een vereiste. Alle andere bijkomende talen is een pluspunt
• Algemeen verzorgd voorkomen, sociaal persoon, rechttoe-rechtaan…
• Zelfstandig en in groep kunnen werken, open voor discussies en andere opinies en afspraken nakomen…

Wat houdt de job in?
Linux systeembeheer, uitwerken en testen van nieuwe opstellingen, PHP/MySQL programmatie, scripting, klantenondersteuning, automatisering van de interne systemen, helpen bij projecten… De dagen zijn gevarieerd bij ons, en ‘s avonds is er altijd wel iets gebeurd dat we ‘s morgens nooit voor mogelijk achtten .

Wat bieden we?
Een voltijdse job te Gent aan een marktconform loon, een interessante werkomgeving, gevarieerd werk, centrum Gent, mogelijkheid om veel bij te leren, en flexibele werkgevers. Er wordt hier samengewerkt, ik ben Bernard, Frank is Frank, en jij bent wie je bent.

Interesse? Of ken je mensen die op zoek zijn naar een dergelijke job? Meer informatie? Of onmiddellijk solliciteren? Telefoneren kan naar 09/2258291, sollicitatiebrief/mail + CV (pdf!) kan naar jobs@openminds.be. Als je nog vragen hebt, horen we het graag!

PS: gelieve dit zoveel mogelijk door te geven/zeggen/bloggen/posten/…

Nu is het wat manuals lezen, en alles correct instellen en testen. Hier zal wat werk inkruipen, maar dan hebben we zeker terug ruimte om te groeien, en komt de upgrade niet te laat. Momenteel loopt alles nog lekker, maar wanneer er nog wat grootverbruikers bijkomen zullen we beginnen flirten met enkele limieten, en dat willen we natuurlijk niet.

Ah, er zijn nog enkele foto's op het fotoalbum. 

Met name consumenten die toch al van winkel naar winkel surfen hebben weinig geduld en het is dan ook cruciaal dat laadtijden van websites geen storende factor is.

Openminds neemt momenteel netwerk af van 3 verschillende partijen, en beheert zelf het netwerk, zodat we niet afhankelijk zijn van één partij inzake connectiviteit. De machines worden de klok rond door onze monitoring in de gaten gehouden, zodat we bij problemen snel kunnen ingrijpen. Zo zorgen we ervoor dat uw site altijd vlot tot bij de eindgebruiker raakt.

De klant maakte zelf eenvoudig de volgende conclusie:

Een query van 0.0005sec 500.000 keer uitvoeren duurt nog geen 5minuten

Hij basseerde zich op phpmyadmin, die het volgende gaf:
Showing rows 0 - 0 (1 total, Query took 0.0005 sec)

De query in kwestie is de volgende:

mysql> SELECT parent FROM iets WHERE categoryID='21';
+--------+
| parent |
+--------+
| 21 |
+--------+
1 row in set (0.00 sec)


Kijk! 0.00 sec! Briljant, en als ik nu 10 of 1k of 1m queries doe, is dat allemaal gelijk. … *stil gesnik*

Vandaag kregen we ook de officiële bestelbon van Stad Sint-Niklaas, met de nodige stempels en handtekeningen. Hierbij zat een overzicht van de toewijzingscriteria, met een soort puntentelling en enkele gegevens van de andere partijen die ook een offerte hadden ingediend. Zo werden punten toegekend naar kostprijs, inhoud van de SLA, extra diensten, etc… het geeft meteen een beeld waarom er gekozen is voor onze oplossing. Het is natuurlijk ook ideaal om te zien wat anderen in de sector aanbieden voor een bepaalde prijs, en dus zo onze eigen prijszetting te be-oordelen.

Wij moesten helpen met de migratie en de overgang van de oude server naar de server bij ons. We kozen in overleg voor een eenvoudige overgang: gewoon beide systemen online zetten, het nieuwe systeem testen via een testadres, en dan de nameserver records wijzigen.

Er wordt veelvuldig gebruik gemaakt van Xoops, een PHP/MySQL gebasseerd CMS systeem, dat via modules uitbreidbaar is. De overzetting hiervan was quasi kinderspel, er diende één bestandje aangepast te worden, en alles bleef werken. De nieuwere versie van PHP zorgde voor enkele kleine zaken, maar niets wat niet binnen de minuut gevonden en opgelost was.

Wanneer het verkeer op de oude server sterk verminderd, zal ik daar misschien nog een rinetd plaatsen om de resteren mensen door te verwijzen tot wanneer iedereen het nieuwe IP gebruikt. Dat is een beetje afhankelijk van het resterende verkeer. Afhankelijk van het aantal bezoeken na enkele dagen wordt er misschien nog een pagina geplaatst op de oude server, die de mensen op de hoogte brengt van hun trage dns-servers .

Zo ben ik reeds enkele weken bezig met onze domein-interface aan het uitbreiden met nieuwe (*kuch*, nog ontbrekende) functionaliteit. Gestaag komt er functionaliteit bij, en na elke kleine aanpassing wordt mijn verstand en visie eens ge-cross-checked met Frank zijn idee erover, en indien nodig bijgestuurd. Hetzelfde heb ik enkele weken gedaan voor de facturatie-interface (al moet ik toegeven dat er daar ook nog een ellenlange todo-lijst aan vasthangt).

Ik weet het niet goed, maar het lijkt erop dat ik meer gedaan krijg op deze manier.

Je blijft echter altijd met één groot probleem zitten: redundante opslag. Ik maak deze denkoefening nu al minstens 9 maand, en tot op heden ben ik er nog niet uitgeraakt wat het best is. Ofwel ga je op block-niveau gaan werken, en moet je kijken naar oplossingen als DRBD of iets dergelijks. Het enige wat hier mogelijk is, is failover (dus, omschakelen als de “hoofdserver” doodgevallen is), en wanneer je replicatie uitvalt, zit je met een block-device met daarop een mogelijks inconsistent filesysteem. Deze blockdevices kunnen geëxporteerd worden via verschillende technologieën, maar als het als block geëxporteerd is, moet een umount/detecteer ander device/chkfs/re-mount gebeuren. Hier heb ik reeds verschillende zaken getest (bvb iSCSI exports, via drbd gesynced, met HA, en dan portal failover of iets dergelijks voor het omschakelen). Heel het iSCSI gebeuren onder Linux kan nog wat stabiliteit en zo gebruiken, maar het is werkbaar als je er genoeg tijd in steekt om alles uit te vissen. LVM eronder, en je hebt een mooie schaalbare oplossing.

Wanneer je een filesysteem exporteert (smb/cifs, nfs…) kan je hier wat omheen werken, maar dan moet je je filesysteem syncroon houden, en dat is dan weer iets anders. GFS is blijkbaar één oplossing, maar daar heb ik al veel threads gezien met als onderwerp “horrible data corruption” of “where did my data go today?”. Ik heb het nog niet getest, maar het lijkt me dus onstabiel. Als mijn testmachines terug onder de levenden zijn, gooien we dat op de testbank. Verder zijn er ook zaken die met daemons werken, en files heen en terug syncroniseren (met rsync als onderliggende technologie). Dat heb ik dan wel al getest, en binnen de 5 minuten kreeg ik het stuk. Afgevoerd.

De enige oplossing die altijd terugkomt is NFS op een drbd gesyncd device. NFS heeft zijn nadelen, maar blijkbaar is het wel iets wat werkt. Je blijft echter zitten met het feit dat je FS corrupt kan zijn, als de replicatie op een slecht moment wegvalt. Je kan ook maar 2 storage devices gebruiken, en bvb geen 3 met load balancing, of “preferred device” wanneer je bvb je materiaal verdeelt over meerdere locaties en een applicatie bij voorkeur het “dichtste” device moet gebruiken.

Toevallig heb ik deze week heb ik wat zitten zoeken naar kant-en-klare NAS-distributies voor een klant, en vond ik OpenFiler en FreeNAS (naast een hoop andere rommel), en OpenFiler beweert een failover oplossing te hebben. Aangezien het een CentOS gebasseerde oplossing is, vermoed ik dat het terug GFS zal zijn. We gaan dat eens installeren en onderzoeken hoe ze het doen, en daar onze conclusies uit trekken.

Niets bijzonders? Gewoon 2 servers te koop. Kijken we even naar server 1, dan zien we iets verder dat er enkele fotos beschikbaar zijn (let op, vrij groot). Kijk even mee op de eerste foto.

Levensles voor een goede 1U server: luchtstroom gaat van voorkant naar achterkant, en blaast dus normaal over de disks en over/door het koelblok van de processor en de mogelijke koelblokken op north/southbridge, en op bvb een mogelijke raidcontroller. We zien duidelijk enkele fans (ventilators voor de server-leken) op het middenste stuk ijzer zitten (minstens 2, misschien 4 aan de schroefjes te zien). Jammer genoeg zien we enkele hindernissen. We zien dat bvb het geheugen haaks op de airflow staat. Een geheugenlatje is 3 cm hoog. Een kast is 1.75 inch hoog, ofwel 4,4 cm ongeveer. Je moet weten dat het moederbord ietwat boven de onderkant van de kast zweeft, en dat het geheugen ook in een socket zit. Er blijft dus niet veel meer over. Jammer. Achteraan de kast zien we ook niet echt veel perforatie voor de afvoer van de warme lucht.

Nog opmerkelijker is bvb de plaatsing van de koelvin op de chipset (de zilverkleurige). De vinnen staan haaks op de (toch al niet mogelijke) luchtstroom. De processorkoeling werd ook met de vinnen haaks op de luchtstroom gezet. Deze heeft echter een eigen koelingsfan.

Achteraan de kast zien we NA de voeding nog een koeler (zo een type dat boven/onderaan lucht zuigt, en dat door de “slurf” wegblaast). De fan die in de voeding ingebouwd zit blaast los op de zijkant van deze koeler.

Hoe komt dit nu? Het moederbord is een Asrock bordje, gegeerd door low-budget, el-cheapo hostingbedrijfjes die net beginnen. Dit bordje is niet ontworpen om in een 1U kast ingebouwd te worden. Verder is het design van de kast ietwat raar (onder andere die koeler achter de voeding deed me rillen), en niet echt optimaal te noemen.

Er is reeds 320 EUR geboden op deze server. Beschamend. Hij is geen 5 EUR waard in mijn ogen. Wanneer ik een moment tijd heb, neem ik eens enkele foto’s van de machines die hier klaar liggen om naar het datacentrum te vertrekken. We weten wel waarom we iets meer betalen voor een server.

Wat je ziet is een beeld van onder de verhoogde vloer in een van de datacentra waar we met materiaal zitten. De dikke zwarte kabel naast het doosje is een stroomkabel, die één van onze racks van 16A stroom voorziet (er zijn twee dergelijke kabels per rack, die door een STS in 1 redundante omgezet wordt).

Ik moet zeggen dat ik het doosje toch ietwat dichter naar de kabel heb geschoven, voor de slechtziende of slechtruikende knaagdieren nog wat meer te overtuigen van het eten van het lokaas ipv hun tanden in de kabel te zetten.

Als DC uitbater moet je dus aan alles denken, ook aan kleine knaagdieren. Ik vermoed dat het een ramp is om tussen de honderden kilometer kabel die er ligt, die ene kabel te beginnen vervangen die doorgeknaagd is (al denk ik dat vervangen niet gebeurt, maar gewoon een nieuwe leggen).

Hier en hier nog twee sfeerbeelden onder de verhoogde vloer.

Eentje ervan is de volgende: reeds enkele weken zijn we in overleg met Netlash over de nieuwe site. Er moet eens nieuwe structuur komen, andere tekst… en een nieuw design. Dirk is met verschillende ideeën komen opdagen, en nu is het aan ons om er het goeie uit te kiezen. We zullen deze allemaal eens printen, en rondhangen in het kantoor, zodat we dagelijks erop zitten te kijken, en zo zien wat er afstoot en wat er aantrekt. Er zitten echt goeie ideeën in…

Man, dit is moeilijk, en je weet niet als je keuze de goeie is… een sprong in het duister!

Wat klusjes in en om het huis aan het doen, en af en toe eens naar de PC lopen om te kijken als er geen dringende mail; daarnet wat tuinkruiden en potgrond strategisch gemengd, straks nog even snel heen en weer naar InterXion met een server voor een klant, dan misschien nog mijn gras afrijden. Daarna misschien een stukje programmeren voor het domeinsysteem, of misschien wel de afwas doen… Zeer verwarrend allemaal. Vanavond dan nog eens aan de kook slaan (scampis met verse pasta. Njamie!), en misschien nog wat denken over enkele strategische zaken die voor Openminds moeten gebeuren… Mijn vriendin is ook in de weer met de voorbereidingen voor een weekje stage, en met een half oog de wasmachine in de gaten aan het houden.

Zou dit nu part-time werken zijn? De kat vindt het allesinds superleuk, al die beweging.

In de business van het internet, met alle webbanking mogelijkheden, vragen mensen als het mogelijk is om cash te betalen. De laatste keer dat ik checkte, waren we geen supermarkt. De bedragen zijn ook niet zo belachelijk laag dat een overschrijving meer kost. Een van de drie was zelf een bedrag van 4 cijfers, en had reeds een factuur ontvangen.

Voor de goede orde, we ontvangen dus geen cash geld.

Om alles nog wat complexer te maken werkt de site op de Macromedia (ondertussen Adobe) Coldfusion MX 7 server, aangezien het een coldfusion site is. CMX7 is een Java-gebasseerde application server, die een eenvoudige scripting toelaat, zonder al te veel problemen (of mogelijkheden) te hebben met connecties en zo. De site administrator dient dit in te stellen in het administration panel.

Na enige tijd kregen we melding dat er vreemde karakters in enkele entries zaten, en dat deze niet goed weergegeven werden op de site. Er waren ondertussen nieuwe entries toegevoegd, en ook deze waren niet goed. Echter, in phpMyAdmin op de server, die niet door de CMX7 server werd afgehandeld, maar rechtstreeks door Apache/PHP, bleek het enkel de oude entries te zijn die verkeerd weergegeven waren, en niet de nieuwe. Deze waren goed. Er waren 3 stappen in het spel:

• De gedumpte file die we origineel hadden
• De database server zelf. Deze stond in latin1.
• Coldfusion MX7

Enig zoekwerk leverde me volgende zekerheid: Als CMX7 niets anders verteld wordt, werkt die in UTF8. Dat stemde ook overeen met het feit dat mijn Firefox elke pagina in UTF-8 weergaf, ondanks de “charset=iso-8859-1″ melding bovenaan de pagina. Een UTF-8 pagina geeft als eerste byte een speciaal karakter mee, zodat deze herkend kan worden.

Eerst en vooral heb ik de database omgezet naar UTF-8. Eerst en vooral een dump van de database nemen, en dan met enkele welgeplaatste “ALTER TABLE xxx DEFAULT CHARACTER SET = utf8″ commando’s de definities omgezet naar UTF8. Daarmee was mijn data echter nog niet in UTF8, ik wist zelfs niet wat het wel was.

De juiste codepagines vinden was niet zo een groot probleem. Via een pagina die ik vond op het internet, kon ik vinden welke sequence aan een bepaalde charset gekoppeld was. (Om te volgen, scroll helemaal naar onderen, bij het Euro symbool) Via een mysqldump (met default-charset=latin1, want mijn data was nog latin1), kreeg ik onderstaande voor de oude data:

Ik wist dat het een euro symbool moest zijn, en helemaal onderaan de pagina zien we dat de “E2 82 AC” sequence dus UTF-8 data is, en het eurosymbool voorstelt. Let er echter op dat we dit gedumpt hadden in latin1. Dat was dus gewone UTF8-data.

De nieuwe data gaf dit:

Een karakter met waarde “80″. Dit moest ook terug een Euro-symbool zijn. We zien dat ASCII 80 in verschillende codepages het eurosymbool is. De tweede deed een belletje rinkelen (codepage 1252 dus), want dit is de standaard Windows codepage.

De oude data kon dus via volgende commando’s hersteld worden (gewoon als latin1 dumpen, en als utf8 terug inladen, aangezien de data wel goed was):


mysqldump --set-default-charset=latin1 database tabelnaam > file
mysql --set-default-charset=utf8 database < file


Vreemd genoeg kreeg ik het nog altijd niet goed op de webpagina. Maar dat is voor later.

De nieuwe data heb ik via iconv omgezet:


iconv -f CP1252 -t UTF-8 tabeldump > tabeldump.utf8


Een snelle blik gaf me zekerheid dat het “80″ controlekarakter omgevormd was tot “E2 82 AC” waar er een Euro moest staan. Zover waren we al. Met wat scripting dan de boel gedumpt, de oude van de nieuwe data gescheiden, de nieuwe omgezet, en beide terug ingeladen.

Dubbel gecontroleerd dat alles van de database standaard op utf8 stond:


mysql> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+


UTF-8-er kan niet denk ik. Dan was er nog het probleem dat de data natuurlijk niet goed weergegeven werd. Elk controlekarakter werd nogmaals in UTF-8 ge-encodeerd (dus, utf-8 op reeds utf-8 data). Ik vermoedde dat de database connectie in CMX7 niet heel zuiver was, en heb een testopstelling gemaakt. Een nieuwe database met dezelfde data, maar deze keer met de JDBC connector van MySQL ipv de standaard driver in Coldfusion. Deze pagina geeft weer hoe je deze kan installeren en testen in coldfusion. Snel een coldfusion testpagina gemaakt, en het leek te werken. Dan een pagina van de site van de Culture club waar het fout liep omgebouwd zodat deze de nieuwe datasource gebruikte, en alles bleef werken.

Uiteindelijk de datasource aangepast naar de nieuwe datasource, en alles lijkt nu perfect te werken.

Charsets zijn echt wel een “p**n in the ass”.

Uiteindelijk staat er niet meer in dan wat ik al wist, maar toch nog even mijn gedacht hierover. Mr Parsons beweert dat de landrush compleet verkeerd verliep, en dat het een algemeen fiasco was.

De landrush verliep vlot, en alle servers hielden het goed uit. De online whois viel er wel vantussen, maar dat was enigzinds te verwachten, en zorgde niet voor problemen bij de registrars, enkel bij de eindklanten die hun status wensten te zien. De aanloop naar de landrush verliep minder chaotisch dan de aanloop naar sunrise 1 en 2, waar Eurid enkele dagen voor het begin van de sunrises nog wijzigingen aanbracht aan het systeem. Ze leren dus toch.

Een probleem dat hij aanhaalt zijn de spookbedrijven, en dat zo bepaalde bedrijven meer registraties konden binnenhalen. Ik denk niet dat godaddy.com veel problemen zou hebben om dit ook te doen, en hier zeker genoeg cash voor kon vrijmaken, en Bob heeft dus geen reden tot klagen. Kleinere bedrijven kunnen dit natuurlijk niet, en deze hebben wel te klagen. Ik moet wel opmerken dat op een van de eerste samenkomsten van Eurid, deze vraag expliciet werd gesteld (“mag een bedrijf meerdere registrys hebben?”), en dat het antwoord van Eurid duidelijk was (“Ja”). Het mocht dus, en men moest er zelfs geen spookbedrijven voor oprichten. Waarom sommigen dit wel deden, kan misschien een gevolg zijn van gewijzigde reglementen na de roadshow van Eurid. Als dit later gewijzigd is, en er zijn spookbedrijven opgericht om dit te omzeilen, kan een onderzoek misschien geen kwaad.

Mr Parsons stelt voor om alle bedrijven aan een onderzoek te onderwerpen, en enkel deze die effectief domeinregistraties aanbieden aan derden nog toe te laten, en de andere op te doeken en hun domeinen vrij te geven. Dat zal weinig oplossen, en de kans is heel klein dat Eurid het lef heeft om dit te doen. Eurid is ongeveer gelijk aan Dns.be, en daar hebben ze ook nooit de ballen om iets te doen, als het erop aankomt. Probleem is dat, als ze het eenmaal doen, ze altijd gevraagd zullen worden om in te grijpen, en DNS.Be; oeps, Eurid; staat liever aan de zijlijn.

Wat me meer tegen de borst stuit is het misbruik van bvb het beeldrecht om eender welke goede namen in sunrise 1 en 2 te kapen. Een goed voorbeeld is de domeinnaam “hypotheek.eu”, die door een bedrijf geregistreerd is omdat deze een recht hebben op “h&y&p&o&t&h&e&e&k” in Malta (EU whois). Het is een handig omzeilen van de regels, en in theorie is er weinig tegen te doen (regels zijn regels, en ze gelden voor iedereen), maar het is toch duidelijk misbruik.

Merk echter op dat de waarde van een .eu momenteel quasi nihil is, aangezien niemand weet dat .eu domeinnamen bestaan. Enkel heel generieken namen zijn misschien vandaag van enige waarde. De enige die hier gouden zaken deed is Eurid, die als VZW zomaar even 10 miljoen euro binnenhaalde op 1 dag. De kosten zullen niet gering zijn (geschoold personeel, in elke mogelijke taal van de eu, goede planning en zwaar servermateriaal…), maar het lijkt me onwaarschijnlijk dat deze berg geld volledig opgemaakt zal worden; of dat er andere minder correcte uitgaven zullen gemaakt worden. Een monopolie in handen geven van een entiteit (op Europees of op landelijk niveau; lees, “Eurid” of “Dns.be”), en dan geen controle uitoefenen is hoe dan ook verkeerd. Kijk naar de Sidn fiasco in Nederland als je een extreem voorbeeld wenst te hebben. Ik hoop dat er toch enige controle voorzien wordt bij Eurid, maar heb er geen al te grote hoop op (lang leve het beeld dat de burger heeft van Europa).

Laten we hopen dat Murphy ons vandaag overslaat. De registraties gebeuren met hetzelfde systeem als bij sunrise 1, waar we uitstekende resultaten haalden, dus op zich zijn we al bij al er vrij gerust in…

Gelukkig zoeken en indexeren zoekmachines nog op andere manieren dan enkel deze woorden, want anders zouden de cowboy-praktijken die er soms gebeuren wel heel erge gevolgen kunnen hebben. Enkele concurrenten kunnen het blijkbaar niet laten om klanten van Openminds af te snoepen, wanneer deze naar “openminds” zouden zoeken op het internet. Verschillende malen zien we onze naam opduiken tussen de “keywords” lijstjes op sites van concurrenten… Let even niet op de heel slechte cut’n'paste’n'glue werkzaamheden op de afbeelding…

Toch schrik je soms nog eens bij wie je ze vindt…