Dag 55: Waarom is het vlak voor het weekend altijd zo druk?

Zoals de titel al doet verwachten was het vandaag een behoorlijk bedrijvige dag. Daarnaast moest Bryan wegens privé redenen halverwege de dag weg.
Het was vandaag een zeer drukke dag. Zeker nadat Bryan weg is gegaan was het door de hoeveelheid werk wat binnen kwam moeilijk om alleen te bolwerken.

Enkele bijzonderheden vandaag, waren een aantal domein registraties voor een klant. Deze klant wilde opeens voor zijn eigen administratie van iedere domein naam een document van ons tegemoet zien, met daarin de houder, administratief en technisch contact persoon. Dit terwijl we dit in het verleden nooit met de klant hebben gedaan. Uiteindelijk kwam het er op neer dat hij ons zijn administratie wilde laten doen. Dit is natuurlijk niet de bedoeling en heb ik tevens ook geen tijd voor. Ik heb deze klant vriendelijk verzocht mij een template aan te leveren met daarin alle benodigde gegevens. Ik heb het vervolgens verder ingevuld.

Later kwam er van deze zelfde klant nog een verzoek binnen om voor zijn developers een SQL account aan te maken, zodat deze konden inloggen op de database engine bij ons op de server (wij hosten deze server voor de klant, en zij doen de ontwikkeling).
Na herhaaldelijk verschillende rules toegevoegd te hebben in onze firewall, die een connectie van hun IP toestaan naar de server over de MSSQL poort, kregen we continu van de klant te horen dat zijn developers nog steeds geen toegang hadden. Uiteindelijk bleek dat onze eigen internet provider standaard poort 1433 blokkeert, vanwege vele hack aanvallen op databases. Maandag zal dus hier een oplossing voor gezocht moeten worden.
Dit vond de klant echter een onacceptabel antwoord. Zijn developer bleek al een week lang stil te liggen door dit probleem. Desondanks heeft hij dit probleem toch pas gistermiddag om 13:00 uur gemeld. De klant heeft geen SLA met hoge prioriteit, dus dit probleem kwam pas gister aan bod vlak voor we naar huis gingen. Om nu dus van ons te verwachten dat we alles voor het weekend voor elkaar hebben, is voor ons onacceptabel. Dit hebben wij de klant ook uitgelegd.

Dit waren twee bijzondere punten vandaag. Natuurlijk heb ik me vandaag door nog vele andere problemen en verzoeken heen gewerkt. Ik heb vooral niet stil gezeten!

Maar nu: weekend . . .

Dag 54: Verborgen functies dotnetnuke / C# app / Rit naar Hoofddorp

Vandaag ben ik begonnen met een verzoek van een klant, die graag wilde dat werknemers ook vanaf huis kunnen inloggen op het CMS systeem, en intranet van hun website. Deze website betreft een DotnetNuke website. In eerste instantie kon ik niet helemaal goed begrijpen waarom zij hier om vroegen. Ik dacht namelijk dat aangezien de website voor iedereen te benaderen is, zij ook gewoon kunnen inloggen op deze website. Dit bleek echter niet zo te wezen. In de DotnetNuke website zit een beveiliging ingebouwd die kan filteren op IP adressen. Deze IP adressen zijn per inlog account in te stellen. Wanneer een gebruiker wil inloggen met een gebruikersnaam, maar komt met zijn IP niet voor in de lijst van geauthoriseerde IP adressen, dan geeft de website simpelweg de melding dat de login credentials niet goed zijn. Hier kwam ik toevallig achter door proberen in te loggen vanaf een externe locatie.
Later kwam ik erachter dat het ingebouwde super admin account ("Host") de mogelijkheid heeft om deze IP adressen aan te passen op ieder account.
Zo leer je ook nog is wat over een CMS systeem...
Nadat ik hier was achter gekomen heb ik de klant verzocht de betreffende IP adressen toe te sturen, samen met de accounts waarop deze betrekking hebben.

Later kreeg ik de vraag om een telefoon toestel gereed te maken voor een collega. Echter zit zijn werkplek erg ver van het dichtsbijzijnde patchpanel. Hiervoor hadden we geen kabel meer over die lang genoeg was. Hiervoor ben ik naar Hoofddorp gereden, en heb daar een UTP kabel gekocht. Bij terugkomst heb ik het juiste patchnummer aangesloten op de telefooncentrale, en heb vervolgens de telefoon op het patchpanel aangesloten.

Verder ben ik nog een stukje aan de gang geweest met mijn C# applicatie. Zoals ik gister al beschreven heb, is het telefoon registratie gedeelte voltooid. Vandaag ben ik bezig geweest om ditzelfde op te zetten in de applicatie voor de lease auto registratie.

Dag 53: Eerste module C# app gereed / klant firewall onvindbaar

Vanmorgen ben ik begonnen met het hulp verlenen aan een klant die via hun cms systeem op hun website geen hyperlinks meer kon bewerken. Het probleem was dat wanneer via het cms systeem een link wordt geselecteerd, dat deze via een knop te breken is, en vervolgens weer opnieuw kan worden aangemaakt als hyperlink. Het breken van deze hyperlink ging echter niet meer. Collegas van deze klant kregen het echter wel voor elkaar. Het cms systeem bleek al zo oud te zijn, dat deze issues met de browser kan geven. De klant heeft de link inclusief het stuk tekst verwijderd, en weer opnieuw ingevoerd. Hiervan kon de klant wel een link maken. Enige tijd later melde de klant echter dat de editor weer naar behoren werkte (erg fijn die problemen die zichzelf oplossen).

Later ben ik weer verder geweest aan mijn C# applicatie. Hiervan is de eerste module (mobiele telefoon registratie) nu voltooid. Laatste aanpassingen die gemaakt zijn is dat een datum en eigenaar alleen gespecificeerd kunnen worden wanneer de checkbox "uitgeleend" is aangevinkt voor een toestel.
Wat nu nog rest is een zelfde soort module voor de laptops, autoos en vpn tokens. Ook komt er een apart super admin gedeelte in.

Als laatste bijzonderheid vandaag moest iemand zijn ip met spoed worden toegevoegd aan een firewall, die wij voor de betreffende klant in beheer hebben. Deze moest namelijk met spoed kunnen rdpen naar hun eigen servers. Echter kon ik nergens ook maar enige documentatie vinden over deze firewall, zoals ip adres en inlog gegevens. De klant werd ondertussen al ongeduldig. Uiteindelijk bleek één van de collegas deze info op een kladblaadje te hebben staan. Deze info heb ik direct gedocumenteerd, en het gevraagde voor de klant uitgevoerd.

Dag 52: C# app uitleen en uitleen datum + storing intern

Vandaag ben ik weer een stuk verder gegaan aan mijn C# programmeer project.
Zoals vorige keer al aangegeven, is de wens van de afdeling administratie dat eveneens is bij te houden of een telefoon wel of niet is uitgeleend, en zo ja, op welke datum deze is uitgeleend.
Ik heb dit vandaag voor elkaar weten te krijgen door middel van een checkbox. Vinkje betekent uitgeleend en geen vinkje niet. Tevens moet het alleen mogelijk zijn een uitleen datum in te vullen wanneer "Uitgeleend" staat aangevinkt. Dit heb ik zo weten te maken dat de date picker alleen zichtbaar is wanneer "Uitgeleend" staat aangevinkt en direct weer verdwijnt als deze is uitgevinkt. Mocht het zo wezen dat er een uitleendatum al in de database stond opgeslagen, dan wordt deze direct weer leeggemaakt. Tevens worden de naam en achternaam van de persoon aan wie deze is uitgeleend, automatisch leeg gemaakt als "Uitgeleend" niet is aangevinkt.

Verder was er vandaag rond het middag uur een storing op het interne netwerk van het bedrijf. Hierdoor lag het internet er enige tijd uit. Direct trokken enkele klanten bij ons aan de bel die gebuik maken van ons monitoring systeem, om hun eigen servers die bij ons in het datacenter staan te controleren.
Dit monitoring systeem draait intern bij ons, en kon dus ook geen verbinding meer maken met deze servers. Hierdoor kregen de klanten te zien dat al hun servers offline waren, waar ze natuurlijk van schrokken.
Nadat ik de situatie aan ze heb uitgelegd, waren ze gerust gesteld. Enige tijd later kwam de link weer terug online.

Dag 51: Stressvolle dag door spoed klussen grote klanten

Vanmorgen begon de dag erg stress vol. 
Een domein van een klant dat naar ons is toe verhuisd, is sinds gister definitief over. Echter bleken de aangeleverde DNS records van de vorige beheerder niet te werken met de email. De klant, een grote multinational, belde tamelijk boos ons op, dat niemand in de ongeveer twintig landen waar zij actief zijn nog mail kon versturen en ontvangen.
Het uiteindelijke probleem bleek te zitten in de beheer tool die voor het beheer van DNS records wordt gebruikt. Doordat de vorige registrar ons een screenshot had gestuurd van hun beheer interface met daarop te zien de DNS records, dachten wij die zo over te nemen. Echter interpreteert onze tool de invoering van de records anders.
Door een aantal aanpassingen uit te voeren en de DNS cache te flushen, zagen wij dat onze mail weer prima aankwam. Enige tijd later kon de klant ook weer gebruik maken van hun mail.

Later kwam er van een andere klant een spoed aanvraag binnen om enkele ftp accounts aan te maken op hun webserver, en deze te jailen in de /var/www directorie (linux server). Echter was dit met de huidig geïnstalleerde ftp server niet te behalen.
Uiteindelijk heb ik ervoor gekozen om een andere ftp server te installeren. Deze kon ik configureren om users die een ftp sessie openen, te jailen in de www map.
De users heb ik vervolgens nog lid gemaakt van de apache groep (www-data), in verband met de rechten op de www map. Vervolgens heb ik de logins gecommuniceerd aan de klant.