detfalskested

Squeezebox notifications in Ubuntu

4. august 2013 af Mikkel Munch Mortensen

I've caught a cold and have been in bed all day. The internet connection at the hotel is not good enough for video streaming and the TV only shows crap movies/series and lots of sports. So, what to do then?

Well, I looked through my ever growing list of small coding projects to do whenever I have the time for it. And I decided to start working on "now playing" notifications in Ubuntu from my Squeezebox(es).

And after ~4 hours of work, I'm very satisfied with the result:

squeezebox-notify

It notifies on pause/play and when the track changes.

Usually, at home, I'll just look at the display of the Squeezebox to see what track is playing. But at work I use a headless squeezeslave a lot, and having to go to the web interface to check out track info is suboptimal.

I hope to find some time to improve it further another day.

Code is available on GitHub.

0 kommentarer

Et indblik i valg af digitale formater hos Statens Arkiver

13. januar 2013 af Mikkel Munch Mortensen

Siden nytår har Folketingets medlemmer haft mulighed for, frivilligt, at arkivere deres e-mails, så forskere i fremtiden har mulighed for at få et indblik i hvad der foregår på Christiansborg. Jeg studsede over valget af dataformater, hvilket først førte til et godt grin og senere til lidt indsigt i tankerne bag netop dette valg.

3. januar kunne man i et Ritzau-telegram læse at:

Politikernes mails bliver konverteret til såkaldte tiff-filer, som viser et billede af dokumentet. Hvis eller når det forholdsvis simple tiff-format går af mode, vil Rigsarkivet konvertere hele molevitten til et nyt læsbart format.

Jeg undrede mig højlydt på Twitter, hvilket gav nogle reaktioner der først var humoristiske og senere indeholdt reel bekymring over metoden.

Statens Arkiver er heldigvis også på Twitter, og de samlede tråden op. Jeg sendte dem en e-mail med lidt uddybende spørgsmål og jeg fik et fornuftigt svar tilbage. E-mailkorrespondancen er her gengivet, med det forbehold fra chefkonsulent Jan Dalsten Sørensen hos Statens Arkiver, at der er tale om et ret hurtigt svar på en temmelig kompleks problemstilling.

Hej med jer

Dette er jf. udvekslingen på Twitter (jeg er @decibyte).

Først og fremmest fedt at I reagerer, til trods for at vi kan sidde her og grine lidt i skægget af jer (hvilket nu nok viser sig at være uberettiget).

Nå, det hele udsprang af dette Ritzau-telegram, hvori der står:

"Politikernes mails bliver konverteret til såkaldte tiff-filer (...)"

Det var det der undrede mig. Hvorfor lige TIFF? Jeg blev lidt klogere og en del mere rolig ved at læse jeres PDF om at I også gemmer i søgbare formater. Det er måske bare en forhastet journalist uden forstand på sagen der kun deler den halve sandhed?

Jeg forstår valget af TIFF hvis det er som supplerende format til netop at sikre en korrekt gengivelse af hvordan e-mailen ved sin afsendelse har været tiltænkt at skulle se ud. Men det primære format er da forhåbentligt de rå serverdata i en eller anden forstand.

Som Aslak (@aslakransby) påpeger ligger der jo også en del anden interessant data gemt i de rå serverfiler som evt. kan være interessante at grave i i en eller anden sammenhæng. Derudover kan det godt være at man med OCR kan søge inde i TIFF'erne, men det må da alt andet lige være mere effektivt at søge i de oprindelige e-maildata.

Jeg havde selv fornøjelsen af at kunne grave i en backup af en gammel postkasse, da et bekendtskab fra fordums tid dukkede op og vi gerne ville prøve at huske noget af alt det der skete dengang. Der var jeg glad for at jeg ikke skulle sidde og bladre i billedfiler, men blot kunne grep'e efter hendes e-mail-adresse og hurtigt finde frem til det relevante i de store mængder data.

nå, under alle omstændigheder: Det lyder som en udfordrende men interessant opgave med digital arkivering for eftertiden. Personligt synes jeg der skulle være tvangsarkivering for politikerne, men det er jo en helt anden diskussion end formater osv :)

Svar fra Statens Arkiver:

Hej Mikkel,

Tak for din henvendelse – og for Twitter-udvekslingen i går (@IT_arkivaren her).

Vores udfordring er, at vi skal bevare digitalt materiale i princippet for altid – og den eneste løsning, som efter vores vurdering er realistisk p.t. er at konvertere data og dokumenter til nogle få, klart definerede formater, som er velegnet til langtidsbevaring. Vi gemmer ikke de originale filer, bl.a. fordi det vil fordoble vores lagringsomkostninger, komplicere administrationen af de arkiverede data og det i øvrigt vil være tvivlsomt hvor længe ud i fremtiden, man vil have glæde af originaldata. Vi skal jo finde en balancegang, der også tager hensyn til omkostningerne, da midlerne til digital arkivering i sagens natur ikke er ubegrænsede :-)

TIFF er et rigtig godt arkivformat, som ikke er specielt komplekst, og som vi er helt trygge ved også ift. evt. fremtidige konverteringer. Det er altså muligt at bevare megen information inden for en rimelig økonomisk ramme og på en måde, som vi vurderer er fremtidssikker (i modsætning til bevaring af originalfiler eller mere komplekse formater, som er mindre egnede til langtidsbevaring).

I forhold til data og dokumenter fra offentlige myndigheder gemmer vi siden 2010 kun TIFF-filerne (som jo om nødvendigt kan OCR-behandles) samt alle de metadata, som myndigheden har registreret, naturligvis i søgbar form (XML-filer) – typisk sådan noget som titel, dato, afsender/modtager, dokumenttype, sagsbehandler, emneord osv osv.

I andre tilfælde, som eksempelvis politikernes e-mails, hvor der kun er få strukturerede metadata, gemmes også en søgbar version af teksten. Oplysninger som afsender/modtager, emne, dato, antal vedhæftede filer osv. uddrages i disse tilfælde af e-mailen i forbindelse med arkivering og findes i struktureret og søgbar form (som XML-filer).

1 kommentar

Uofficiel URL-forkorter til Kristeligt Dagblad

13. januar 2013 af Mikkel Munch Mortensen

Som så mange andre i min branche kan jeg godt lide at købe sjove domænenavne uden egentlig at have noget særligt fornuftigt at bruge dem til. Især er jeg glad for de såkaldte domain hacks.

I tirsdags sad jeg og prøvede at komme på et godt .li-domæne at anskaffe mig. Desværre var de gode jeg lige kunne komme på optaget, så jeg endte med at smide mine penge efter det arbejdsrelaterede krist.li.

Det oplagte var så at gøre det til en uofficiel URL-forkorter til links til Kristeligt Dagblads artikler. Også fordi URL-forkortning er en nem disciplin jeg endnu ikke havde prøvet kræfter med.

Jeg satte en deadline samme aften og gik i gang med at kode. Resultatet kan ses online på krist.li og koden bagved er tilgængelig på GitHub.

0 kommentarer

Missing graphs in Munin

9. januar 2013 af Mikkel Munch Mortensen

As some may have noticed, this site has been down for a while, only showing a database related error message. This is because I replaced my home server in August, but never finished moving everything from the old to the new server. I'm doing this tonight. And apart from restoring the database (yay, back online!), I also ventured into moving my Munin configuration and data.

I was trying to restore my old Munin data, although there would be quite a gap since last time any data was collected. Everything seemed to work just fine, except that the graphs were missing. They simply wasn't being generated.

All files were owned by the right users and stuff like that. And searching the interwebs didn't bring me any closer. That's why I'm writing this, hoping it will help cure someone else's headache.

Not knowing what to do, I finally took the time to look at the Munin log files, including munin-graph.log where I found this:

2013/01/09 20:41:28 [RRD ERROR] Unable to graph (...)/sda1-year.png : This RRD was created on another architecture

Aha! I didn't know the RRD files were architecture dependent. Will have to remember this when we advance from 64-bit computing.

And another important lesson learned (again, again): Always look in the log files!

0 kommentarer

(Mere) sikre kodeord

8. juni 2012 af Mikkel Munch Mortensen

De seneste par dage har flere store sites fortalt om at deres databaser med deres brugeres kodeord er blevet lækket.

I den forbindelse opfordres brugerne til at skifte deres kodeord på de kompromitterede sites, samt alle andre sites hvor brugerne anvender samme kodeord.

Der er 2 problematikker i denne sammenhæng: 1) At mange websites ikke krypterer de gemte kodeord i tilstrækkelig grad. Og 2) At de fleste mennesker er dovne og bruger det samme (eller nogle få) kodeord alle steder.

Jeg er selv en af de halvdovne brugere. Jeg har indtil videre brugt 3 forskellige kodeord rundt omkring.

Det første er til ligegyldige ting. Det er ikke særligt hemmeligt og jeg deler det gerne med folk hvis det giver mening at de får det. Fx bruger jeg det til mine trådløse netværk herhjemme.

Det andet er mit primære kodeord. Det er det jeg bruger til langt de fleste ting. Faktisk har jeg 2 af dem, da forskellige sites har forskellige krav til kompleksiteten af kodeord og de hver især tilfredsstiller disse krav uden at være særligt komplekse.

Det sidste er mit meget hemmelige kodeord som jeg kun bruger til mit NemID.

Allerede her er jeg sikkert bedre beskyttet end de fleste. Alligvel kunne jeg ikke lade være med at blive en lille smule bekymret da Last.fm i dag annoncerede at de også er blevet kompromitteret. For der har jeg en bruger med mit primære kodeord.

Heldigvis udtænkte jeg i nat – da jeg alligevel lå søvnløs og spekulerede over et par af livets store spørgsmål – en smart (synes jeg selv) metode til at have forskellige kodeord på forskellige sites, som stadigt er til at huske. Her følger en generel beskrivelse af min tilgang.

Vælg et grundkodeord

Til at starte med skal man finde sig et grundkodeord der er til at huske og som umiddelbart lever op til alle sikkerhedskrav om længde og blandede tegn (tal, bogstaver, specialtegn). Jeg er fx meget glad for citrusfrugter, og er født i november (måned nr. 11), så et grundkodeord kunne være: CTRSfrgt-11.

Dette er ret nemt for mig at huske. Derudover skulle det også i sig selv være et ret stærkt kodeord. Men det nytter jo ikke noget hvis nogen bare kan hive det ud af en lækket database. Derfor skal det gøres unikt for hvert site man logger ind på.

Parametre til manipulation

Lad mig bruge Last.fm som eksempel. Min ide er at bruge ting fra domænenavnet til at manipulere grundkodeordet med. Alle websites har unikke domænenavne, og giver dermed unikke værdier for parametre at manipulere sit grundkodeord med. Last.fm's domænenavn er – overraskende nok – last.fm.

Af domænet kan jeg fx uddrage at top level-domænet (TLD) – fm – er 2 tegn langt. Og Second level-domænet (SLD) – last – er 4 tegn langt. Desuden kan jeg give bogstaverne i domænet en talværdi svarende til deres position i alfabetet. Fx er l nr. 12 i alfabetet, a er nr. 1 i alfabetet, s er nr. 19 i alfabetet, t er nr. 20 i alfabetet, osv.

Tænker man lidt længere kan man sikkert finde flere tal i et domænenavn.

Manipuler grundkodeordet

Næste skridt er så at bruge disse tal til at manipulere sit grundkodeord. En simpel ting kunne være at lægge længden af SLD'et til tallet i grundkodeordet. Således vil mit kodeord til Last.fm blive CTRSfrgt-15.

Vupti, så vil jeg have forskelligt kodeord på forskellige sites. Nogle sites vil selvfølgelig have samme længde SLD som hinanden, og dermed få samme kodeord. Så det er nok en god ide at manipulere sit kodeord med flere parametre.

Næste manipulation kunne fx være at "lægge bogstaver sammen", så værdien af det andet bogstav fra SLD'et lægges til værdien af det andet bogstav i kodeordet og dermed giver et nyt bogstav. I mit eksempel ville det være 20 + 1 = 21, eller rettere: T + a = U. Mit kodeord til Last.fm ville herefter være CURSfrgt-15.

Allerede med 2 manipulationer vil risikoen for at 2 sites har samme kodeord være ret lille. Men man kan sagtens tilføje endnu flere manipulationer. Det vigtige er bare at man kan huske dem alle (og evt. også i den rigtige rækkefølge) når man sidder og skal bruge et kodeord.

Andre typer af manipulationer kunne være at gange noget med noget andet, trække fra hinanden og modulo mellem to værdier.

Fx kunne specialtegnet være det specialtegn der sidder på Shift+X, hvor X er talværdien af sidste tegn i TLD'et modulo 10 (13 modulo 10 = 3 => Shift+3 => #). Eller man kunne lade antallet af benyttede manipulationer være afgjort af længden på TLD'et.

Mulighederne er mange, og med blot nogle få manipulationer skulle man meget gerne have nogle ret sikre kodeord som er forholdsvist nemme at huske – eller i hvert fald regne sig frem til.

Man skal selvfølgelig regne og tænke lidt hver gang man skal logge ind et sted, men det har jeg allerede vænnet mig ret hurtigt til på en halv dag, og i forvejen bruger jeg altid "husk mig"-funktionen, hvis der er en sådan til stede på sitet.

2 kommentarer

nyere indlægældre indlæg