Cloud Backup

I have kept meticulous backups of every turn from the three games I run. Before and after each turn, the data file, orders file and summary are zipped up into a .tar.bz2 file. This is essential for fixing bugs weeks later, because it lets me re-run a turn with the old data and watch what went wrong in my debugger “as it happens”.

The problem with these backups is that they sit on the machine in Germany that hosts the game, and I tend to do my debugging at home. Also, storing the current game data and the backups on the same hard disk is hardly redundancy. A weekly rsync between my home machine and the server would solve this, but my home machine runs Windows for a number of reasons, and so that’s not really an option. I could rsync to another machine in the house (I have a few Raspberry Pi for similar purposes) but then I still have to move the files from there to my desktop PC when I actually want to debug something.

Today I finally solved that problem, with a free Box (previously box.net) account. Box supports webdav, so it’s as easy a single curl request to upload my file to a shared folder, and the Box app on Windows will sync it to my desktop. Backup and local debug copies solved!

For future reference: to store the eressea.db sqlite database in a Box folder named Eressea, this is the curl command to do the HTTP PUT request:

    curl -n

-T eressea.db

https://app.box.com/app/Eressea/eressea.db 

Authentication with Box is done through a .netrc file on the host, because I don’t want to check the account password into github along with my backup script. cat ~/.netrc:

    machine dav.box.com login box@eressea.de password swordfish

Standards are great, and WebDAV support really makes the decision for which cloud storage service I want to use an easy one. The free account gives me 10 GB storage, enough for approximately 460 turns at today’s size of the game, so if I move them to CD backup frequently enough, I should never have to pay for storage. Nice!

Advertisements

Memory Leaks

Eressea has a pretty simple memory usage pattern. It allocates a bunch of memory during startup, when it loads the current game data file and creates all the regions, factions, units, etc. and the new orders, then stays pretty much flat while it executes the turn, only allocating more memory for messages and auxiliary structures. Then, after the report is written, it exits and the death of the process cleans everything up nicely.

There shouldn’t be a lot of memory leaks in a situation like that, but the code is written with the intention of being able to load and unload data files from the console, for operations like building statistics over time, repairing one file based on data in another, etc. A recent example was “link every familiar in turn X to the same mage they were familiars of in turn X-1″. So while programmatic cleanup is usually not required, it is in a situation like this (after analyzing turn X-1, we should free it before reading turn X to apply the fix).

Another reason for working cleanup code is testing. Unit tests work best when running from clean state, so anything that gets created in one test should be destroyed at the end of it, so it won’t interfere with the next test. My favorite tool for finding leaks like this is valgrind, and recently it was reporting almost 1,000 leaks when run on the full unit test suite. I started a new feature branch to eliminate them, and after a couple of evenings of hard work, I have pared them down to one final leak in the parser that is really hard to track, and a bunch of static variables that are the bane of this code base. As can be expected when doing work like this, I found a number of small errors that were more than just leaks, and added a lot more test coverage, so this should cause overall code stability to go up. The work ended up in one giant pull request, and will be part of the 3.7 version of the code.

Plans Change

Last time I regularly updated this site,  my plans were to use my copious free time to create a mobile version of Eressea, or at least a game based on the same principles. That’s no longer the plan.

Eressea is less a game than it is a world simulation. In this, the original designers were correct. There isn’t very much good strategy game-play at its core, and many of the game’s elements are not in support of a war game, but for world-building and to give players other, self-defined, goals to strive for.

With that said, I don’t have a lot of existing game to build on. Building a mobile client was fun as long as I did it, but the total time required to build what I had in mind was going to be enormous. I was also having more fun just working on successive new releases of Eressea itself.

So the mobile project is dead. Long live the original game!

Some former players have started new factions this years, eking out a living in the ruins of fallen empires, trying to hold their own against the zombie hordes and finding some resources that they can mine, or older factions they can cooperate with. It’s a different way to play, but it seems to be working for some, and for the original game, it’s a better way to maintain the active player base than new recruits and growing the map.

That means my development work is now defined by bug fixing, new features, and occasionally tools for creating new worlds. When I’m asked, I try to support anybody who wants to run a game of their own. And those are the topics that this site is likely going to cover in the future.

Sikkerhet på tnb.no

Siden jeg endelig fikk pin-kode til mitt konto, kan jeg nå logge meg inn i tnb.no, og sjekke resten av stedet.

Jeg klaget jo allerede over mangelfulle sertifikater, og har sendt en epost til 

Webredaktør Stine Lindstad, og fikk som svar idag at det er ikke hun, men Trygve Kikut som er ansvarlig for tekniske ting som dette, men han er på ferie til 17. august. Derfor har jeg ingen andre valg enn å logge meg på over en usikker forbindelse, med pin-kode og brukernavn i klartekst.

Første funksjonen son skal testes er derfor endring av pin kode. Ikke at dette hjelper noe stort, siden den alltid kommer til å bli sendt i klartekst, men det forteller oss kanskje noe mer om systemet. På profilsiden leser jeg: “Vi gjør oppmerksom på at din PIN-kode kan bli oppgitt i brev og e-post du mottar fra biblioteket, f.eks. hentemeldinger- og purrebrev. Dette gjør vi for at det skal være lettere for deg å benytte denne tjenesten”

Hva betyr dette? For å kunne sende pin-koden til meg i brev eller e-post er det nødvendig å lagre den i klartekst på server-siden. Normal standard for passord til et system som dette er å bruke en en-veis hashfunksjion (gjerne scrypt eller bcrypt), noe som betyr at det er umulig å lese passordene selv om det er noen innbrudd eller databasen blir stjålet gjennom en feil i systemet. PIN-koden kan dessuten bare inneholde tall, og må være fire sifre langt, hva betyr at selv om de hadde brukt ordentlig kryptering av passordene ville det vært trivielt å kjøre brute-force attack mot passord-databasen. Det er nesten like enkelt å kjøre det mot selveste nettsiden, og det skulle ikke ta mer en noen minutter å bryte seg inn i et konto når man vet (eller gjetter) et låner-nummer.

Så er det bruk av informasjonskapsler, eller cookies. Innloggingen har en mulighet for å forbli pålogget, noe som gjør at når en setter et kryss på det, så trenger man ikke å logge seg på igjen fra samme nettleseren. Dette blir som vanlig gjort gjennom en unik session-cookie som blir spart i nettleseren, og hver gang en side fra tnb.no blir etterspørt, sender nettleseren selveste cookie tilbake, og så vet nettstedet at det er meg. Vis noen klarer å stjele dette cookie er det lett for han å få tilgang til min konto, han trenger ikke en gang å logge seg på. Det er derfor det er vanlig at all trafikk til nettsteder med brukerkontoer (som tnb.no) skal sendes over SSL-krypterte forbindelser (HTTPS), og derfor er det så ille at sertifikatene til tnb.no ikke fungerer. Vis jeg sitter i samme rom med noen som bruker tnb.no på trådlos-nettverket, er det for eksempel meget enkelt å lese verdien av hans cookie med en verktøy som Wireshark.

Det er derfor også vanlig for et nettsted som bruker session-cookies å gi dem veldig kort levetid, dvs. de fungerer bare i noen timer, og så blir det utvekslet en ny en, i tilfelle det gamle er blitt stjålet. Levetiden på selveste cookie fra tnb.no er ett år, og da antar jeg at dette

heller ikke ble gjort ordentlig.

image

Svar fra TNB

I dag har Tønsberg og Nøtterøy Bibliotek svart på min epost fra gårsdagen, som klaget over manglende svar på forespørsel etter ny pin-kode. De sendte meg SMS til min registrert telefonnummer med ny PIN kode, og koden fungerer.

For meg ser dette ut som det ikke finnes noe automatisk behandling av pin-kode forespørsel, men her sitter det en person som får en epost hver gang jeg trykker på “glemt kode” knappen på nettsiden, og sender en SMS. Dette er noe som skulle fungere automatisk, fordi det er ikke noe jobb som krever utdanning til bibliotekar, og da ville det også fungert på en søndag. Tenk om Facebook ville brukt samme metoden, hvor mange kundebehandlere de ville trengt bare for det. Men norske kommuner har sikkert spart mye penger på IKT systemer som de kan sløse bort på jobber som den? Vi har i hvert fall ingenting å frykte fra automatiseringen, den skaper jo flere jobber en den ødelegger.

At hun sendte koden gjennom SMS til mitt registrerte nummer, istedenfor til en epost-adresse som ikke var registrert i min profil, er et bra tegn, fordi det kunne jo vært hvem som helst som hadde funnet låner-nummeret mitt og skulle trenge seg inn i min konto. Med andre ord: det er ikke bra, men det kunne vært enda verre.

Dagens interaksjon med tnb.no får dermed terningkast 2 av 6.

Tønsberg og Nøtterøy Bibliothek

http://tnb.no/ skulle jeg kunne bestille bøker, fornye de som jeg har utlånt, og søke i katalogen. Søket fungerer, kanskje fordi søk er noe som bibliotekarene selv bruker?

De fleste andre funksjonene forutsetter selvfølgelig at jeg logger meg på. Det gjør jeg med låner-nummer plus PIN-kode. Og her blir det skammelig.

For det første så ble ikke følgt noen sikkerhetsstandard her. Istedenfor passord har jeg en firesiffret PIN-kode, og hele nettsiden er ikke kryptert med SSL. Om jeg prøver å logge meg på blir brukernavn og passord overført i klartekst. Prøver jeg å åpne https://tnb.no/ får jeg meldingen fra nettlesern at nettstedet er usikkert, fordi sertifikatet er utstilt til websok.tnb.no – den ansvarlige utvikleren har kjøpt sertifikat for en subdomene istedenfor en wildcard-sertifikat til hele *.tnb.no, og det forklarer vel hvorfor det ikke er i bruk.

Dette er grovt uansvarlig av en moderne nettside. Men enda verre, selv om jeg logger meg inn med mitt brukernummer og PIN-kode, så blir jeg til en side som sier at jeg har oppgitt “feil i lånernummer eller pin-kode”, og siden jeg har kopiert nummeret fra lånerkortet må det vel være pin-kode som er feil? Jeg trodde helt sikkert at jeg husket den, men jeg skal prøve å få meg en ny en.

For å få ny pin-kode skal jeg altså oppgi låner-nummer og epost-adresse. Så får jeg svar at ny pin-kode skal bli sendt til meg, men ingenting skjer. Er det fordi det er søndag idag, og forespørsel blir svart på manuelt? Jeg håper jo at noe så enkelt blir automatisert. Eller er det fordi det står her: “ Dersom e-postadressen ikke er lik den som er registrert i bibliotekets base så vil det ikke bli laget noen ny PIN-kode”. Har jeg registrert noen epost-adresse? Muligens ikke, jeg har jo aldri brukt dette systemet før.

“Har du ikke registrert din e-post adresse hos oss, kan du kontakte oss på tbg@tnb.no” – det er søndag, men jeg skal prøve, og se om jeg får noen svar. Men for en nettside som skal bli brukt av folk flest er dette veldig trist. Jeg kan umulig være den første som har liknende problemer, og jeg undrer meg om det er noen utviklere som samler på sånne type brukerproblemer og fikser dem. Antageligvis har biblioteket kjøpt dette systemet for noen år siden, og ingen har noen gang brydd seg om hvor bra den fungerer, eller hvor mange brukere som har problemer med den.

Jeg ser en del ting som jeg har jobbet med da jeg utviklet en stor nettside i PHP selv. Som for eksempel problemer med character encoding av norske bokstaver:

Her har noen skrevet innholdet i Windows-1252 codepage, men CMS-systemet kjører på UTF-8, og tilsammen blir dette bare vrøvl.

HTTPS Everywhere und spiegel.de

Seit einer Weile schon habe ich das Problem, dass auf spiegel.de Teile der Artikel fehlen. Gelegentlich sehe ich nur die Einleitung eines Artikels, und alle interaktiven Inhalte, ob Infografiken oder Sporttabellen, sind kaputt.

Zuerst habe ich natürlich den Adblocker als Schuldigen vermutet. Ein schneller Blick auf die Seiten im Inkognito-Modus von Chrome, wo alle Extensions deaktiviert sind, zeigt den vollständigen Artikel. Also nach und nach alle Erweiterungen abgeschaltet, bis der Artikel lesbar war, und siehe da: Es war HTTPS Everywhere.

Nun will ich auf keinen Fall die Erweiterung abschalten müssen, also habe ich mir die Liste der Regeln vorgenommen, und auch hier eine nach der anderen deaktiviert. Schuldig waren am Ende zwei Regelsätze (siehe Bild). Ich werde die mal komplett abschalten, statt herauszufinden, wie man die Regeln ändert, und hoffe, dass das kein zu großer Hammer ist. Am schönsten wäre natürlich, wenn man bei SPON in der Technik ohne diese Mengen an IFRAME Elementen in den Artikeln auskommen würde, aber das ist wohl zu viel verlangt?

Korrektes Webdesign ist schwer.