Vandaag begon de dag met een noodkreet van intern uit. Een medewerker had in een project en development omgeving die I-Company hanteert, een fout gemaakt. Bij het instellen van bepaalde permissies kwam hij de user group "users" en "-users" tegen. Bij de "users" stonden alle gebruikers opgeslagen en de andere groep bleek leeg te wezen. Deze verwijderde hij daarom, omdat hij dacht dat deze daarom overbodig was. Echter werd hij direct uit het systeem gegooid na het verwijderen vanwege het ontbreken van permissies. Het bleek dus uiteindelijk dat deze groep nooit verwijderd had mogen worden. Op dit moment kan helemaal niemand meer inloggen in het systeem. Wat ik voor hem heb geprobeerd is via de config files van het development systeem, alle authenticatie weghalen. Voor alle acties, views, schermen etc. zijn bepaalde user rechten nodig. Nadat ik deze in de config files had verwijderd konden we weer in het admin dashboard terecht komen zonder in te loggen. Echter, wanneer we weer de groep en permissies wilde aanmaken, gaf het systeem de error dat we onvoldoende permissie hadden en hiervoor diende in te loggen. Het probleem stagneerde dus. Maandag wordt gekeken of er een backup van eerder gerestored kan worden. Wat dan echter wel het probleem is, is dat al het werk gerestored wordt naar die backup.
Verder zijn we vandaag naar het datacenter in Haarlem geweest, om twee servers en een nieuwe 48-poort switch te installeren voor een klant. Deze klant kwam vanmorgen de apparatuur bij ons afleveren. Eenmaal in het datacenter aangekomen, hebben we de apparatuur uitgepakt en in ons rack gehangen. Bij het inschakelen van de server bleek één van de voedingen defect te wezen. Deze zal dus moeten worden vervangen. Gelukkig heeft de server altijd twee voedingen waardoor deze nu toch operationeel is. Vervolgens diende de nieuwe switch ook in het rack gehangen te worden. De oude 24-poort switch is namelijk al helemaal vol. We hebben hiervoor een kabel van de oude switch naar de nieuwe switch gekoppeld, en de losgekoppelde kabel van de server ook in de nieuwe switch gekoppeld. Vervolgens beide nieuwe servers aan de nieuwe switch gekoppeld. De klant zat ondertussen mee te testen of zij konden inloggen via RDP op de servers. Na wat kleine aanpassingen aangebracht te hebben, meldde zij dat zij op beide succesvol konden inloggen. Ons werk zat er dus weer op, en was het tijd voor weekend. . .
vrijdag 9 december 2011
donderdag 8 december 2011
Dag 69: SSL certificaten vernieuwen Linux / drukte servicedesk
Vandaag heb ik ook weer niet stil gezeten. Niet dat ik me ooit verveel, want ik heb naast me reguliere werkzaamheden natuurlijk nog een programmeer projectje lopen. Maar hier kwam ik vandaag niet eens aan toe.
Vandaag kreeg ik de herrinering dat twee SSL certificaten van twee, op Linux gehoste websites, morgen zouden verlopen. Deze diende dus vandaag, uitelijk morgen verlengd te worden.
Uiteraard heb ik hiervoor om toestemming gevraagd aan de klant, die op zijn beurt vroeg of ik het totale kosten plaatje kon berekenen. Dit heb ik voor hem netjes voor berekend. De twee Comodo certificaten kosten zo goed als niets, maar per certificaat wordt twee uur installatie en configuratie kosten berekend.
Na de klant zijn akkoord heb ik voor de betreffende websites op Linux een private key aangemaakt, middels het openssl commando, 2048 bits encryptie. Vervolgens heb ik van deze private key een certificate request gemaakt. Hierbij worden de gebruikelijk vragen gesteld, zoals bedrijfsnaam, stad etc.
De certificate request die hier vervolgens uitrolde kon ik vervolgens door sturen naar de instantie waar wij onze SSL certificaten bestellen. Het is op dit moment nog wachten totdat deze daadwerkelijk worden uitgegeven. Naar verwachting zal dat morgen wezen.
Verder ben ik vandaag nog aan de gang geweest met een aantal FTP accounts op te zetten op zowel Linux als Windows servers. Deze accounts diende natuurlijk gejailed te woorden en hun bijbehorende home directory. In dit geval waren dat een aantal website roots.
Ook ben ik vandaag nog bezig geweest met opnieuw een spam probleem van dezelfde klant als gisteren. Zij ontvingen nog steeds een hoop spam met de vraag hier wat aan te doen. Echter heb ik alleen enkele domeinen en IP adressen kunnen blokkeren in het spam filter. Verder kon ik hier niet veel aan doen, aangezien een botnetwerk vanzelf een slechte reputatie opbouwt. Deze scoort op dit moment nog net niet hoog genoeg om geweerd te worden.
Vandaag kreeg ik de herrinering dat twee SSL certificaten van twee, op Linux gehoste websites, morgen zouden verlopen. Deze diende dus vandaag, uitelijk morgen verlengd te worden.
Uiteraard heb ik hiervoor om toestemming gevraagd aan de klant, die op zijn beurt vroeg of ik het totale kosten plaatje kon berekenen. Dit heb ik voor hem netjes voor berekend. De twee Comodo certificaten kosten zo goed als niets, maar per certificaat wordt twee uur installatie en configuratie kosten berekend.
Na de klant zijn akkoord heb ik voor de betreffende websites op Linux een private key aangemaakt, middels het openssl commando, 2048 bits encryptie. Vervolgens heb ik van deze private key een certificate request gemaakt. Hierbij worden de gebruikelijk vragen gesteld, zoals bedrijfsnaam, stad etc.
De certificate request die hier vervolgens uitrolde kon ik vervolgens door sturen naar de instantie waar wij onze SSL certificaten bestellen. Het is op dit moment nog wachten totdat deze daadwerkelijk worden uitgegeven. Naar verwachting zal dat morgen wezen.
Verder ben ik vandaag nog aan de gang geweest met een aantal FTP accounts op te zetten op zowel Linux als Windows servers. Deze accounts diende natuurlijk gejailed te woorden en hun bijbehorende home directory. In dit geval waren dat een aantal website roots.
Ook ben ik vandaag nog bezig geweest met opnieuw een spam probleem van dezelfde klant als gisteren. Zij ontvingen nog steeds een hoop spam met de vraag hier wat aan te doen. Echter heb ik alleen enkele domeinen en IP adressen kunnen blokkeren in het spam filter. Verder kon ik hier niet veel aan doen, aangezien een botnetwerk vanzelf een slechte reputatie opbouwt. Deze scoort op dit moment nog net niet hoog genoeg om geweerd te worden.
woensdag 7 december 2011
Dag 68: Aantal service tickets explosief toegenomen / use cases afgemaakt
Vanochtend op de werkplek aangekomen was het even schrikken toen we de servicedesk (webportal) opende. Het aantal service tickets was namelijk explosief toegenomen. Gisteren stonden slechts vier tickets nog open, die niet direct actie behoefde, maar vanmorgen stonden er tot onze schrik plotseling vijftien in. Drie van deze verzoeken betrof een front-end probleem. Hier hadden wij dus niet veel mee te maken.
Een ander ticket betrof een probleem van een klant, die niet in staat was zijn outlook box te openen vanaf een server, maar wel via zijn eigen desktop. Wat precies het nut is van je mail lezen op een andere server over RDP weet ik niet, maar het was voor de klant een behoorlijke issue. Wanneer deze met zijn account op de server wilde inloggen op outlook, bleef outlook continu om credentials vragen. Wanneer echter deze persoon via zijn account inlogde met het admin account op outlook, werd ineens de mailbox geopend van de persoon waarvan het account is gekopieerd. Waarschijnlijk is er dus iets fout gegaan bij het kopieren van deze gebruiker. Ik ben er verder nog niet aan toegekomen dit uit te zoeken.
Tussendoor ben ik nog aan de slag gegaan met de documentatie van mijn C# registratie tooltje. Hiervoor maak ik verder geen uitgebreide documentatie rapporten, aangezien de tool maar van zeer beperkte omvang is. Wél plaats ik uiteraard commentaar in de code, en heb ik vandaag het use case diagram afgerond. Wat nu nog rest is een klasse diagram.
Verder kwam er vandaag weer een spam issue voorbij. Een klant die bij ons een aantal mailboxen afneemt, kreeg veel spam mail, die al wel gemarkeerd was als spam, maar nog wel gewoon in de mailbox van de klant belande. Enig onderzoek in de maillogs wees uit dat de mails al hoog genoeg scoorde om als spam gemarkeerd te worden, maar nog niet hoog genoeg scoorde om daadwerkelijk geweerd te worden. Een mogelijke oorzaak hiervoor kan zijn dat er een nieuw soort botnet actief, die nog bezig is zijn reputatie op te bouwen. Los van het betreffende IP adres te blokkeren waarvan de spam afkomstig is in ons spam filter konden wij helaas niet veel doen. Wanneer de reputatie van dit netwerk dusdanig verslechterd is, zullen deze berichten vanzelf geweerd worden.
Een ander ticket betrof een probleem van een klant, die niet in staat was zijn outlook box te openen vanaf een server, maar wel via zijn eigen desktop. Wat precies het nut is van je mail lezen op een andere server over RDP weet ik niet, maar het was voor de klant een behoorlijke issue. Wanneer deze met zijn account op de server wilde inloggen op outlook, bleef outlook continu om credentials vragen. Wanneer echter deze persoon via zijn account inlogde met het admin account op outlook, werd ineens de mailbox geopend van de persoon waarvan het account is gekopieerd. Waarschijnlijk is er dus iets fout gegaan bij het kopieren van deze gebruiker. Ik ben er verder nog niet aan toegekomen dit uit te zoeken.
Tussendoor ben ik nog aan de slag gegaan met de documentatie van mijn C# registratie tooltje. Hiervoor maak ik verder geen uitgebreide documentatie rapporten, aangezien de tool maar van zeer beperkte omvang is. Wél plaats ik uiteraard commentaar in de code, en heb ik vandaag het use case diagram afgerond. Wat nu nog rest is een klasse diagram.
Verder kwam er vandaag weer een spam issue voorbij. Een klant die bij ons een aantal mailboxen afneemt, kreeg veel spam mail, die al wel gemarkeerd was als spam, maar nog wel gewoon in de mailbox van de klant belande. Enig onderzoek in de maillogs wees uit dat de mails al hoog genoeg scoorde om als spam gemarkeerd te worden, maar nog niet hoog genoeg scoorde om daadwerkelijk geweerd te worden. Een mogelijke oorzaak hiervoor kan zijn dat er een nieuw soort botnet actief, die nog bezig is zijn reputatie op te bouwen. Los van het betreffende IP adres te blokkeren waarvan de spam afkomstig is in ons spam filter konden wij helaas niet veel doen. Wanneer de reputatie van dit netwerk dusdanig verslechterd is, zullen deze berichten vanzelf geweerd worden.
dinsdag 6 december 2011
Dag 67: Bellen met internationale klanten zonder kennis van zaken
Vandaag kwamen er weer een aantal zaken naar binnen rollen die de stress weer een beetje opvoerde. Ondanks dat ik hier eigelijk vrij weinig mee te maken had, werd ik weer achterna gezeten.
Vandaag moest er voor een kerst actie van een grote internationale klant, een bepaalde kerst pagina online komen te staan voor zowel Nederland als België.
Voor de Nederlandse versie, had ik al enige tijd correspondentie met een externe partij die de ontwikkeling hiervoor op zijn rekening neemt.
De hosting loopt echter via ons (en dus ook via mij). Echter voor de Belgische variant, is de communicatie verlopen via de manager binnen I-Company. Van deze Belgische variant had ik dus totaal geen kennis. Toch belde ons internationaal contact persoon van deze klant naar ons, en vroeg specifiek naar mij, of één en ander vandaag online gezet kon worden voor de Belgische kerst website. Dit werd uiteindelijk een erg lastig telefoon gesprek, en de klant was niet bepaald blij dat ik geen idee had waar het over ging. Deze website moest namelijk eind van deze dag online staan. Uiteindelijk ben ik er dus achter gekomen dat de communicatie over deze Belgische pagina via een ander persoon hier intern loopt. Hierdoor had ik dus totaal geen kennis van zaken toen ik deze klant aan de telefoon had.
Uiteindelijk is hier uit gekomen dat voor de Belgische pagina een language selector was gemaakt. Hiervoor hebben wij een jpg en een psd (photoshop) file aangeleverd gekregen waar de language selector op te zien was, maar geen html versie hiervan gekregen.
Uiteindelijk had ik de psd net zo goed zelf kunnen "slicen", en achter de knopjes de betreffende link kunnen plakken. In plaats van dat hebben we het deze partij zelf laten doen met als resultaat het nu nog steeds niet klaar is.
Verder heb ik voor de Nederlandse versie nog een ISAPI rewrite scriptje geschreven. Wanneer men namelijk naar de home URL navigeert, moet de eindgebruiker direct worden doorgestuurd naar de kerst pagina. Deze instelling moet blijven bestaan tot na de kerst.
Vandaag moest er voor een kerst actie van een grote internationale klant, een bepaalde kerst pagina online komen te staan voor zowel Nederland als België.
Voor de Nederlandse versie, had ik al enige tijd correspondentie met een externe partij die de ontwikkeling hiervoor op zijn rekening neemt.
De hosting loopt echter via ons (en dus ook via mij). Echter voor de Belgische variant, is de communicatie verlopen via de manager binnen I-Company. Van deze Belgische variant had ik dus totaal geen kennis. Toch belde ons internationaal contact persoon van deze klant naar ons, en vroeg specifiek naar mij, of één en ander vandaag online gezet kon worden voor de Belgische kerst website. Dit werd uiteindelijk een erg lastig telefoon gesprek, en de klant was niet bepaald blij dat ik geen idee had waar het over ging. Deze website moest namelijk eind van deze dag online staan. Uiteindelijk ben ik er dus achter gekomen dat de communicatie over deze Belgische pagina via een ander persoon hier intern loopt. Hierdoor had ik dus totaal geen kennis van zaken toen ik deze klant aan de telefoon had.
Uiteindelijk is hier uit gekomen dat voor de Belgische pagina een language selector was gemaakt. Hiervoor hebben wij een jpg en een psd (photoshop) file aangeleverd gekregen waar de language selector op te zien was, maar geen html versie hiervan gekregen.
Uiteindelijk had ik de psd net zo goed zelf kunnen "slicen", en achter de knopjes de betreffende link kunnen plakken. In plaats van dat hebben we het deze partij zelf laten doen met als resultaat het nu nog steeds niet klaar is.
Verder heb ik voor de Nederlandse versie nog een ISAPI rewrite scriptje geschreven. Wanneer men namelijk naar de home URL navigeert, moet de eindgebruiker direct worden doorgestuurd naar de kerst pagina. Deze instelling moet blijven bestaan tot na de kerst.
maandag 5 december 2011
Dag 66: Postcode check issue / All round probleempjes
Vanmorgen als eerste aan de gang gegaan met een probleem die via de klantenservice toegestuurd kregen van een grote klant van ons. Een consument van deze klant kon zich namelijk niet registreren op de website, omdat de website de opgegeven postcode niet accepteert. Aan ons de vraag dit uit te zoeken en op te lossen. Het probleem hiermee was, was dat dit een Nederlandse website is, waar een postcode check in gebouwd zit, en de betreffende consument is een Belg. Een Belgische postcode bestaat enkel uit vier cijfers, zonder letters. De postcode check verwacht echter een postcode met vier cijfers en twee letters. Vandaar dat deze consument dus niet de mogelijkheid had zich te registreren. Wel is er van deze zelfde website een .be variant. Echter zit hier niet het betreffende systeem in gebouwd waar de consument zich voor wilde aanmelden. Om deze postcode check uit de Nederlandse versie te verwijderen, dienen wij een officieel verzoek te krijgen van de klant zelf met toestemming deze check er uit te verwijderen.
Verder ben ik vandaag bezig geweest met het bieden van telefonisch support, zoals het toegang verlenen tot bepaalde servers via FTP en RDP. Ook zaten er enkele verzoeken bij dat een website in een IIS server betrof. In deze websites zit een IP filter geconfigureerd, die enkel de geregistreerde IP adressen toestaat (dit was voor een sales/intranet omgeving). Na telefonisch contact te hebben gezocht met de klant om zijn IP adres te achterhalen, kon ik deze toevoegen aan zowel de firewall als IIS IP filter voor de betreffende website.
Ook ben ik vandaag met enkele mail/spam issues aan de gang geweest, en enkele andere interne zaken (teveel om op te noemen!).
De kop is er weer af! Voor nu: op naar huis.
Verder ben ik vandaag bezig geweest met het bieden van telefonisch support, zoals het toegang verlenen tot bepaalde servers via FTP en RDP. Ook zaten er enkele verzoeken bij dat een website in een IIS server betrof. In deze websites zit een IP filter geconfigureerd, die enkel de geregistreerde IP adressen toestaat (dit was voor een sales/intranet omgeving). Na telefonisch contact te hebben gezocht met de klant om zijn IP adres te achterhalen, kon ik deze toevoegen aan zowel de firewall als IIS IP filter voor de betreffende website.
Ook ben ik vandaag met enkele mail/spam issues aan de gang geweest, en enkele andere interne zaken (teveel om op te noemen!).
De kop is er weer af! Voor nu: op naar huis.
Abonneren op:
Posts (Atom)