Dag 65: UML diagrammen C# app / telefonische support

Vandaag ben ik aan de slag gegaan met de documentatie van mijn C# projectje.
Hiervoor ben ik gestart met de UML diagrammen, namelijk, Use Case diagram. In dit use case diagram zal ik grafisch duidelijk maken wat de eindgebruiker zoal voor acties kan uitvoeren met de tool, de afhankelijkheden etc.
Ook zal ik later nog een klasse diagram in elkaar zetten, om het toekomstige onderhoud van de tool te vergemakkelijken. Natuurlijk wordt ook de code voorzien van commentaar.

Later vandaag kreeg ik, los van de reguliere werkzaamheden, nog twee telefoontjes van klanten die graag support wilde hebben.
Het eerste telefoontje betrof een probleem met FTP. De klant waarvoor ik vorige week vrijdag een PHP website heb deployed op één van onze Linux machines, klaagde nu over dat deze website niet tussen hun gebruikelijke FTP lijstje stond. Dit klopt ook wel, want deze klant heeft bij ons een Windows server afgehuurd, waarop zij zelf dit FTP account hebben. Aangezien PHP websites nooit zo zullen draaien onder IIS als onder Apache, staat deze website op een Linux machine gehost. Hiervoor diende zij dus ook een FTP account nodig te hebben op de Linux machine. Na een account op deze machine aangemaakt te hebben, heb ik dit account lid gemaakt van de apache group (www-data) zodat dit account dezelfde rechten heeft apache (rwx). Vervolgens heb ik het account gechangeroot naar hun website folder.
Als laatste puntje heb ik het IP adres van de klant toegestaan in de firewall zodat zij ook daadwerkelijk toegang krijgen tot de FTP omgeving.

Tweede telefoontje kwam van een andere klant, die op zijn website een actiefolder probeerde te uploaden. Om deze folder weer te geven is er een aparte module op de website geïnstalleerd. Deze module behoeft alleen de link met het pad waar de bestanden voor deze folder zijn terug te vinden. Waar het fout ging bij deze klant, is dat hij de bestanden in een .zip pakket had geupload naar zijn server, en vervolgens deze in de folder module probeerde aan te roepen onder folder.zip/index.html. Aangezien dit niet gaat werken heb ik de klant uitgelegd dat hij deze bestanden eerst lokaal op zijn eigen computer dient uit te pakken, en vervolgens los moet uploaden naar de server toe. Daarna is in de folder module het pad te specificeren zoals hij gewend is, zonder de .zip extensies.

En dan nu: weekend . . .

Dag 64: Permissions issue website

Vandaag ook weer kunnen profiteren van een gisteren en eergisteren opgeruimd ticket systeem. Doordat we de afgelopen twee dagen even flink de schouders eronder hebben gezet, waren zo goed als alle verzoeken op de Hosting afdeling weg gewerkt. Op deze manier is het ook een stuk beter bij te houden, en lopen er geen verschillende dingen tegelijk en door elkaar heen.
Ook vandaag was het dus weer een wat rustigere dag. Eigelijk was er maar één puntje noemenswaardig interessant.
Een klant waarvoor wij de hosting omgeving regelen, heeft bij ons een website gehost die door de klant zelf is ontwikkeld. Bij het bewerken van een aantal bestanden in het CMS systeem van deze website, kregen zij plotseling een foutmelding dat zij niet voldoende permissies hadden om de aanpassingen uit te voeren. Dit kwam dus vervolgens bij ons terecht, met de vraag dit aan te passen. Vervolgens de permissies recursief doorlopen op alle files en (sub)folders. Deze stonden allemaal goed ingesteld.
Een collega programmeur heeft vervolgens geassisteerd bij het in elkaar zetten van een eenvoudige upload tool. Met deze tool was het tevens voor ons mogelijk om bestanden op de betreffende website te uploaden en aan te passen. Uitgesloten was dus dat dit een permissions issue betrof.
In de stack trace van de klant troffen we de melding aan dat een bepaald bestand niet gevonden kon worden. Waarschijnlijk is dus het geval de klant via het CMS geprobeerd heeft bestanden te bewerken die reeds verwijderd zijn, maar het CMS nog niet gesynchroniseerd heeft.
Enige uren later meldde de klant dat dit inderdaad het geval bleek te wezen.

Dag 63: Erg rustige dag / start laptop module C# app

Vandaag valt er weinig interessants te melden.
Het was een erg rustige dag vandaag. Een dag zoals ik in de afgelopen tijd al heel lang niet meer heb meegemaakt. Er zijn vandaag maar twee problemen gemeld bij de servicedesk, die ik beide telefonisch heb kunnen afhandelen met de klant.
Eén van deze problemen betrof een tijd synchronisatie probleem op één van de servers van een klant. Deze klant wilde op zijn server een software pakket installeren, waarvoor de systeem klok een belangrijk element bleek te wezen. De systeem klok op deze server bleek 20 minuten voor te lopen op de werkelijke tijd. Hierdoor kon de installatie van de klant zijn software niet voortgaan. De klant nam vervolgens telefonisch contact met mij op om te vragen wat er aan de hand was. De tijd handmatig aanpassen resulteerde in de klok die zichzelf automatisch weer 20 minuten vooruit zette.
Een mogelijkheid die ik me kon bedenken is dat deze server een virtuele machine moest wezen, waarvan de host zelf 20 minuten voor loopt. Na de controle op de Hyper-V machine bleek inderdaad dat deze klok voor liep. Hierdoor synchroniseerde de virtuele machine continu met de host machine. Nadat deze klok van de host was aangepast, kon ook de systeem klok van de virtuele machine weer aangepast worden. Naderhand kon de klant de installatie van zijn software pakket weer voortzetten.

Verder ben ik vandaag weer een stukje verder gegaan aan mijn C# applicatie. Ik ben verder gegaan met een nieuwe registratie module, namelijk, voor de laptops. Ik ben gestart met enkele klasses aan te maken die de eigenschappen van een laptop beschrijven (eigenaar, merk, type, windows licentie etc.). Verder heb ik de GUI alvast aangemaakt voor deze registratie module, en de tabel geinitialiseerd.

Hopelijk is er morgen weer wat meer te doen. Alhoewel een rustig dagje na enkele zeer drukke dagen ook niet heel vervelend was.

Dag 62: Fout website naar live grote klant / trucen met Iframes

Vandaag kreeg ik de aanvraag van een collega van de afdeling Sales, om op de website van een erg grote internationale klant, een extra sublink aan te maken. Dit was simpelweg te behalen door voor de betreffende sublink een directory aan te maken in de mappen structuur van de website. Deze website wordt echter gehost bij een externe partij in Amerika. Na dit ene mapje aangemaakt te hebben op de "Staging" (test) omgeving, heb ik het verzoek ingediend bij deze externe hoster, de test omgeving te synchroniseren met de live omgeving. Echter ging hier zo gruwlijk iets fout, dat de website voor ongeveer zes uur offline is geweest. De melding die werd weergegeven was 403 Access denied. Na heel veel over en weer gemail is de oorzaak uiteindelijk gevonden. Tijdens het deployen van de test omgeving naar de live omgeving, bleek de web.config niet in orde te zijn, waardoor deze fout werd veroorzaakt. Echter hebben wij niets anders gedaan dan eenvoudigweg een mapje aangemaakt. Het is op dit moment een welles nietes verhaal geworden over welke partij hier nu schuldig aan is, maar alles wijst erop dat de hosting partij een fout begaan heeft. Immers is het onmogelijk dat bestanden zich uit zichzelf gaan aanpassen bij het aanmaken van een lege directory. . .

Later kreeg ik voor deze zelfde klant nog een verzoek om een link in te richten voor een kerst pagina. De content voor deze kerst pagina moet van een externe URL worden opgehaald. Het is natuurlijk niet zo netjes om hierbij een 301 redirect uit te voeren, en de eindgebruiker direct fysiek wordt door gelinkt naar een andere URL. Om dit te voorkomen, heb ik in de subdirectory van deze website een html file aangemaakt, met daarin een fullscreen Iframe. Dit iframe laadt achter de schermen de content van de externe URL in. Hierdoor wordt de URL niet veranderd, en is het voor de eindgebruiker nog steeds net alsof hij zich op dezelfde pagina bevind.
De klant was erg blij met de geboden oplossing en de snelheid van het doorvoeren van zijn aanvraag.

Dag 61: C# auto registratie gereed / mod_rewrite Apache

Vandaag de dag begonnen met een nogal verontrustend ticket van een klant. Deze gaf aan dat ongeveer zeven van de tien servers die wij voor hun in beheer hebben, offline bleken te wezen. Na dit direct te controleren bleek echter dat alle servers nog gewoon online waren. Wat de klant uiteindelijk bedoelde was dat hij deze server niet meer via RDP kon benaderen.
Aangezien ik dit zelf nog wel kon bij alle machines, kwam bij mij direct het idee naar boven dat deze klant vanaf verschillende machines heeft geprobeerd in te loggen via RDP. Na deze vraag bij de klant neer gelegd te hebben, bleek dit ook daadwerkelijk zo te wezen. De drie machines die volgens de klant nog wel te benaderen waren, waren benaderd vanaf de machine die al wel was toegestaan in onze firewall. De overige zeven bleken vanaf een externe locatie geprobeerd benaderd te worden (nogal logisch dat dat niet gaat werken!). Ik heb vervolgens het IP adres van deze persoon opgevraagd bij de klant, en deze vervolgens in de firewall toegestaan op 3389/tcp (RDP). Na verificatie bleek alles weer naar behoren te werken, ook voor deze externe persoon.

Later voor lunchtijd ben ik nog aan de gang geweest met mijn C# applicatie. De auto registratie module is nu af. Het resterende puntje was om deze nog fool proof te maken, door middel van enkele checks bij het toevoegen en bewerken scherm. Het is nu niet meer mogelijk om onzin in te vullen.

Na de lunch ben ik aan de ganag geweest met een PHP website die ik afgelopen vrijdag op een Linux machine bij ons heb opgezet. Deze website bestaat uit een zowel Nederlands als Engelstalige versie. De drie domeinen die naar deze website toe moeten linken zijn .nl, .be en .com. De .nl en .be versie moeten standaard op de Nederlandstalige versie van de website uitkomen. De .com versie standaard op de engelse. Het probleem was echter dat deze website zo gebouwd is, dat het met cookies werkt. Standaard komen alle drie de domeinen op de Nederlandstalige versie uit. Wanneer men op klikt op de Engelstalige versie van de website, worden deze instellingen opgeslagen in een cookie en opgeslagen op de computer van de gebruiker. Wanneer vervolgens de drie domeinen worden bezocht (.nl, .be en .com) blijken ze allemaal de Engelstalige versie weer te geven door de instellingen die uit deze cookies worden geladen.
Aangezien dit niet wenselijk is, en de klant dit ook aan gaf, heb ik via Apache mod_rewrite rules in de virtualhost config file een aantal rules geschreven die achter de schermen naar de /nl versie gaan wanneer de .nl en .be website bezocht worden. Wanneer het .com domein wordt bezocht wordt de gebruiker vanzelf door gestuurd naar de /en versie van de website.
Het is natuurlijk niet zo netjes dat deze daadwerkelijk in de URL worden weergegeven (voorbeeld: www.example.com/en). Daarom heb ik hierbij ook geen gebruik gemaakt van een 301 redirect. Wat ik wel heb gebruikt zijn een aantal RewriteRules, die dus zonder dat de gebruiker dit te zien krijgt, de content voor '/' (root) ophaalt bij /en of /nl. Hierdoor krijgt de gebruiker de juiste taal te zien afhankelijk van het bezochte domein, maar krijgt dit niet als subpad achter het domein te zien.