Dag 50: Hosting aanvragen verwerkt

Vandaag ben ik de dag begonnen met een spoed aanvraag. Ik was namelijk nog geen minuut binnen toen de projectmanager zich naar mij toe snelde. Er moest namelijk met spoed een nieuwe domeinnaam voor een klant worden geregistreerd.
Nadat ik deze aanvraag had uitgevoerd, en de DNS record van dit domein had gewijzigd naar onze webserver, werkte deze intern al direct. Bij de klant werkte dit echter nog niet direct, vanwege het feit DNS publicaties een tijdje in beslag kunnen nemen. Na ongeveer een uurtje meldde de klant dat ook hij de website kon benaderen.

Later ben ik aan de gang geweest met de registratie van een domeinnaam voor een andere klant. Echter ging dit niet geheel als geplanned. Tijdens de registratie procedure van dit domein werd ik terug gekicked naar het inlog scherm van onze DNS beheel panel. Het resultaat was ook niet naar behoren. De domeinnaam was nergens in ons beheer paneel terug te vinden, maar stond al wel op onze naam geregistreerd. Hierdoor was het niet meer mogelijk om het domein te beheren.
De oplossing hiervoor was om op de database van dit beheer paneel in te loggen, en bij de betreffende klant een record toe te voegen met het domein en de betreffende DNS records. Na dit opgeslagen te hebben was het domein gelukkig weer zichtbaar en te beheren en onze DNS beheer paneel.

Verder ben ik natuurlijk vandaag bezig geweest met de reguliere systeembeheer en netwerkbeheer werkzaamheden. Zoals het toevoegen van een aantal klant IP adressen aan onze firewall voor toegang tot een financieel systeem van een klant.

En dan nu: weekend . . .

Dag 49: Half dagje

Gisteren heb ik tot 20:15 aanwezig moeten wezen, vanwege een project dat eigelijk gister online had gemoeten. Hierdoor mocht ik vandaag om 12:15 weg, ook vanwege privé zaken.

Wat ik vandaag nog heb gedaan is een ftp account opzetten op een server. Dit wilde eerst niet werken en kreeg ik bij het connecten via ftp direct een time out. Met wireshark heb ik toen de packets gesniffed en zag plotseling de ftp verbinding geredirect worden naar een ander ip adres dan die van de server. Dit bleek te komen doordat iemand de verkeerde ip binding in iis had ingesteld bij de ftp site. Na dit gecorrigeerd te hebben werkte het naar behoren.

Verder heb ik vandaag nog enkele ip adressen moeten toestaan in de firewall voor het opzetten van deze ftp sessies.

Dag 48: Domein registraties + C# app edit en zoek functie

Vandaag was het weer een wat drukkere dag op de servicedesk.
Eén van de punten die vandaag aan bod zijn gekomen is het registreren van een domein voor een nieuwe klant. Hiervoor heb ik het domein bij ons geregistreerd en het betreffende A record toegevoegd die wijst naar de klant hun server.

Later die dag kreeg ik telefoon van een klant, die normaal gesproken na inloggen als admin op zijn website, de website ook daadwerkelijk kon beheren en content kon aanpassen. Dit was nu echter niet meer mogelijk en aan mij de vraag hier even naar te kijken. Na een kijkje genomen te hebben in de user tabel van de database die gekoppeld is aan deze website, zag ik al vrij snel wat het probleem was. Het betreffende admin account had als parameter '0' staan voor de 'superuser' eigenschap. Na deze aan te passen naar '1' werkte het admin account weer naar behoren en kon de klant zijn website ook daadwerkelijk weer aanpassen.

Hierna ben ik bezig geweest met het aanmaken van een development omgeving en een live omgeving voor een website, die eind deze week live moet gaan.
Voor de live omgeving moest er in IIS nog een SSL certificaat gekoppeld worden aan de website. Dit certificaat stond het gelukkig toe om ook aan subdomeinen toegevoegd te worden. Deze live omgeving betreft namelijk een subdomein voor een reeds bestaande website. Normaal gesproken zou er voor iedere aparte website een nieuw certificaat nodig zijn.

Later vandaag ben ik nog verder gegaan aan mijn C# applicatie. Hiermee ben ik verder gegaan aan de Edit en de zoek functie. Met de edit functie liep ik eerst tegen een probleem aan, namelijk: wanneer een gebruiker twee keer hetzelfde nummer toevoegd, en later één van de twee records bewerkt, dan zullen direct beide records met hetzelfde nummer worden aangepast. Dit komt natuurlijk door de "WHERE Telefoonnummer =" in de query. Het is nu zo aangepast dat gegevens worden gewijzigd op basis van ID.
Ook heb ik de zoekfunctie af gemaakt. Het is nu mogelijk om op alle gegevens te zoeken naar bepaalde records.
Later zal ik nog enkele tabs aan de applicatie toevoegen die het tevens mogelijk maken om te registreren wie welke laptop gebruikt, VPN tokens en auto's. Dit naar aanleiding van een verzoek van de administratie. Op deze manier creëer ik als het ware een universele registratie tool.

Dag 47: Laatste requests weg gewerkt

Vandaag was het sinds een lange tijd weer eens vrij rustig op de hosting afdeling. Daarom zijn wij vandaag alle resterende open service verzoeken gaan wegwerken, en hebben we ook zoveel mogelijk de tickets weg gewerkt die nog op "On Hold" stonden.
Verder is er vandaag niet heel veel gebeurd dat interessant is om te melden. Naast de reguliere werkzaamheden was er slechts één interessant puntje.

Via de servicedesk kwam er van een klant een verzoek binnen een backup terug te zetten van een website, omdat deze klant aanpassingen had gemaakt die niet de bedoeling waren en ze niet meer ongedaan kon maken.
Deze server is een virtual machine in ons cluster in Haarlem. Echter kwamen wij tot onze schrik erachter dat sinds 1 november de backup procedure stagneerde, en er sindsdien geen backups meer zijn gemaakt.
Dit bleek te komen doordat VMware een bepaalde "Integrity check" niet meer kon uitvoeren, en daarom het proces lockte van het maken van snapshots van de VM's. De oplossing was gelukkig vrij simpel: het lock bestand van VMware op de moeder server verwijderen, en de service herstarten. Vervolgens is een nieuwe integrety check gestart, waar deze een paar uur mee bezig is. Als deze succesvol verloopt zal het backup proces gelukkig weer hervat worden.

Dag 46: Dure fout van klant + iscsi error‏

Vandaag was weer een behoorlijk bedrijvig dagje. vanmorgen om 9:00 uur kreeg ik telefoon van een klant, die met zijn nieuwe laptop niet meer zijn bestanden kon vinden. Hij beweerde dat deze via een netwerk share schijf opgeslagen stonden. De domain controller beheren wij voor deze klant, dus ik ging op zoek naar deze shared folder van de user. Deze was echter helemaal nergens te vinden en de klant begon continu te bellen omdat er haast achter zat. Na heel veel zoeken en bellen kwam het hoge woord eruit. Extern vanaf huis etc. kon de klant ook altijd via zijn oude laptop bij zijn bestanden komen. Voor mij was dat toen reden genoeg om aan te nemen dat deze bestanden helemaal niet in het domein opgeslagen werden, maar gewoon local op zijn laptop stonden. Dit bleek ook zo te wezen.

Later die dag kwam er een error op een server voorbij over een iSCSI error. Deze server maakt gebruik van een NAS schijf om voice logs op op te slaan. De SCSI connector verloor continu de verbinding met deze schijf. Dit komt mogelijk door een switch die kuren vertoond in het datacenter.

Wordt vervolgd. . .