PLANET.OPENSOURCE.DK
Folk:
Alexander Færøy
Anders Lund
Anders Ossowicki
Andreas Bach Aaen
Anton Berezin
Bryan Østergaard
Carsten Pedersen
Christian Jørgensen
Christian Sejersen
Christina Rudkjøbing
Dan Leinir Turthra Jensen
David Zeuthen
Erwin Lansing
Esben Mose Hansen
Flemming Jacobsen
Frederik S. Olesen
Georg Sluyterman
Henrik Brix Andersen
Henrik Lund Kramshøj
Jesper Dangaard Brouer
Jesper Jarlskov
Jesper K. Pedersen
Jesper K. Pedersen
Jesper Krogh
Jesper Louis Andersen
Jesper Nyerup
Josef Assad
Kenneth Christiansen
Klavs Klavsen
Kristian Høgsberg
Kristian Nielsen
Lars Sommer
Lars Sommer
Leif Lodahl
Mads Toftum
Martin Hansen
Martin Pihl
Martin Schlander
Martin von Haller Grønbæk
Martin von Haller Grønbæk
Niels Kjøller Hansen
Nikolaj Hald Nielsen
Peter Hansteen
Peter Larsen
Peter Makholm
Peter Makholm
Peter Rude
Peter Toft
Phil Regnauld
Poul-Henning Kamp
Sidsel Jensen
Sune Kloppenborg Jeppesen
Sune Vuorela
Søren Bredlund Caspersen
Søren Hansen
Søren Hansen
Søren Sandmann
Søren Straarup
Thilo Bangert
Thomas Alexander Frederiksen
Thomas H.P. Andersen
Thor Dekov Buur
Sidst opdateret:
May 16, 2012, 21:21 UTC
Disclaimer:
Dette er folks egne meninger og har ikke nødvendigvis nogen forbindelse til hvad danske opensource-foreninger mener.
Kom på:
Kontakt planet@opensource.dk hvis du føler du vil være her.
Inkluder venligst URL for det feed du ønsker optaget, samt en redegørelse for opfyldelsen af nedenstående krav.
Krav:
Powered by:
Planet
Alexander Færøy
Anders Lund
Anders Ossowicki
Andreas Bach Aaen
Anton Berezin
Bryan Østergaard
Carsten Pedersen
Christian Jørgensen
Christian Sejersen
Christina Rudkjøbing
Dan Leinir Turthra Jensen
David Zeuthen
Erwin Lansing
Esben Mose Hansen
Flemming Jacobsen
Frederik S. Olesen
Georg Sluyterman
Henrik Brix Andersen
Henrik Lund Kramshøj
Jesper Dangaard Brouer
Jesper Jarlskov
Jesper K. Pedersen
Jesper K. Pedersen
Jesper Krogh
Jesper Louis Andersen
Jesper Nyerup
Josef Assad
Kenneth Christiansen
Klavs Klavsen
Kristian Høgsberg
Kristian Nielsen
Lars Sommer
Lars Sommer
Leif Lodahl
Mads Toftum
Martin Hansen
Martin Pihl
Martin Schlander
Martin von Haller Grønbæk
Martin von Haller Grønbæk
Niels Kjøller Hansen
Nikolaj Hald Nielsen
Peter Hansteen
Peter Larsen
Peter Makholm
Peter Makholm
Peter Rude
Peter Toft
Phil Regnauld
Poul-Henning Kamp
Sidsel Jensen
Sune Kloppenborg Jeppesen
Sune Vuorela
Søren Bredlund Caspersen
Søren Hansen
Søren Hansen
Søren Sandmann
Søren Straarup
Thilo Bangert
Thomas Alexander Frederiksen
Thomas H.P. Andersen
Thor Dekov Buur
Sidst opdateret:
May 16, 2012, 21:21 UTC
Disclaimer:
Dette er folks egne meninger og har ikke nødvendigvis nogen forbindelse til hvad danske opensource-foreninger mener.
Kom på:
Kontakt planet@opensource.dk hvis du føler du vil være her.
Inkluder venligst URL for det feed du ønsker optaget, samt en redegørelse for opfyldelsen af nedenstående krav.
Krav:
- Du er aktivt involveret i free/open source software (udvikling, foreninger e.l.)
- Du skriver på skandinavisk og/eller på engelsk
- Du har en tilknytning til skandinavien
- Du skriver en gang i mellem om noget relevant for free/open source software-verdenen
Powered by:
Planet
May 15, 2012
Poul-Henning Kamp
a.k.a. phk
Datalogisk Sorteringsmesterskab ? (May 15, 2012, 18:32 UTC)
Jeg har hørt om folkvalg hele dagen og et af de faktisk problemer er tilsyneladende at sortere stemmeseddlerne.
Hvis jeg havde troet de ville forstå joken, havde jeg strakt hånden om bag mig og med mandig stemme sagt "Hurtigt Robin, giv mig Bat-Datalogen!"
Men helt seriøst taler vi altså om et ... May 14, 2012
Peter Toft
a.k.a. pto
Raspberry Pi - den booter ... oftest :-) (May 14, 2012, 21:41 UTC)
Så skete det - jeg har fået en Raspberry Pi (faktisk har jeg fået to - som er solgt til en god ven).
Jeg har som en start installeret en Debian Linux på et 2GB SD-kort. Det fungerer fint, men det var et noget nedskrællet Debian image jeg startede med.
Selv "vi" var ikke installeret - ej heller...
Poul-Henning Kamp
a.k.a. phk
eValg: Næste offentlige IT-skandale (May 14, 2012, 08:12 UTC)
Jeg skal til "workshop om elektroniske fremmødevalg" i morgen og jeg har allerede nu en grim smag i munden om det projekt.
Ikke alene for dets muligheder for at lave lort i vores mest fundamentale og på mange måder eneste demokratiske magtmiddel, men også fordi tilgangen til projektet på alle må... May 10, 2012
Anton Berezin
a.k.a. Grrrr
Why does not it meow? (May 10, 2012, 13:33 UTC)
Today I've spent quite some time chasing a bug in a legacy code at work. In retrospect, the problem is trivially simple.
It can be illustrated by the following snippet.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body>
<script src="irrelevant.js" type="text/javascript"/>
<script type="text/javascript">
function meow() { alert("meow"); }
</script>
<a href="http://dailyotter.org/"
onclick="meow(); return false;">
click for meow</a>
</body>
So, why does it show you otters instead of meowing, and how long did it take you to spot the bug?
Jesper Louis Andersen
a.k.a. jlouis
More on Erlang and State (May 10, 2012, 13:14 UTC)
One important key aspect of Erlang programs is to identify where your Stable state is in the program. Stable state is what you can trust. What you can trust is what you can build on. Joe Armstrong defines one of the key aspects of an Erlang system as Stable Storage. A place where we can push data and be sure it won't change. If we verify data before pushing, we can trust those data a great deal.
This is important. If our system partially crashes, as is the norm for Erlang programs, it may be necessary to reconstruct state. Stable storage provides the basis from which we can re-read data into memory. Even if recreating data is expensive, you may still want a cache to be able to reconstruct your state faster from disk. Persistent store on a disk is among the best way to make sure data is there.
In a BitTorrent client like eTorrent for instance, we only worry about the file. If we download a piece of a file and that pieces pass the BitTorrent SHA1 integrity check, we can now regard that part as "safe" write to stable storage, and never touch it again. I don't have to care about the internal state of peers I am communicating with. I don't have to worry about any internal structure in memory. The on-disk partial download provides all the needed information to reconstruct the system from scratch should I need it.
Second, there may be state we don't really want to lose - but we can afford it. We can't recreate a user input, so we need that on stable storage like above. But we don't want to redo expensive work if we can. To fix this in Erlang, we create a process to keep the important data, and we let that process protect the data simply by validating and verifying any change of the data. The process becomes a castle with the princess in it. And with a nasty dragon at the drawbridge. (Naturally, the princess and dragon have exquisite meals each night together and they like to dance tango. The nastiness and damsel-in-distress is only kept up for fun to lure unsuspecting knights to the party).
Third, we can exploit that sequential Erlang is a functional programming language. If we are state S1 and we apply a function to obtain state S2, we have an interesting property: either we obtain S2, or we get an error. But since the data store is persistent, we still have access to S1 if we keep a reference to it. This in effect creates an atomic way of processing: Either we get to the new state safely, or we can't move to the new state due to an error. This means that each state becomes a safe-haven in our processing. Since we can't mutate data, there is no way the processing to obtain S2 can corrupt the state of S1. It allows us to build programs that are highly stable as it ultimately works like a CPU: We have a state and atomically we process a clock cycle to obtain a new state. There is no "in between".
(Note: I must strain that modern CPUs are more advanced than this, but they try to uphold the illusion above)
Fourth, we can exploit the isolation between processes. To get state, I must ask another process for it. To ask another process for it, I must send it a message. It might never answer. So I must build my system around the idea that systems will fail occasionally. If it answers however, the data is now mine to do with as I please. It may be invalid since it is too old, but as long as I have it, I can do with it what I please. At that point, I don't care too much about the fate of the other process, since I have a safe copy. This in turn can used to build a system where we know where the stable state is all the time.
Fifth, we can exploit distributed Erlang. Have a couple of nodes. Store important data on multiple nodes. Now, should one node crash, the other nodes still have the data. And memory + network communication is often way faster than disk. Not to mention that you can get better parallel execution and faster recovery since data is already there in memory, ready to be served on the 10 gigabit link. The princess just phoned her girlfriends in Britain, France, Italy and Russia with the recipes for the next 100 meals (...and her work on homotopic type theory - princesses do have spare time to do research after all).
See, the point is: when the system begins failing - how do we want it to crash? When you get the chainsaw and slay the proverbial dragon (the tree in your garden which slighty but not really looks like a dragon at all) you don't want it to fall down into your nice house. You want it to crash differently, down on the lawn. The same with Erlang programs. We want them to crash so it has little impact on users, but also such that our important data is still safe. And if it goes really wrong, we want data persisted somewhere else. Either on another node in the cluster, or on disk. We want it to crash in ways which avoids the stable state.
The key is that we begin thinking about crashing a priori, before it happens. We think of where we have stable state and what parts we don't worry about crashing. The secret behind BitTorrent clients are that they are easy: you can throw away everything, sans the pieces of the file that have been checked for integrity. Everything else can just go crashing as it sees fit, we don't care. But when you take your own application and do the same kind of thinking, chances are that you will reach the same conclusion: there is a little bit of the system which needs protection, but you don't care about the rest.
That is a hint on how to structure your Erlang program.
PS. I should probably also write about how the loose coupling of Erlang processes foster good architecture, but that is another post for another time :)
(Edited a couple of times to fix wording - thanks DeadZen)
This is important. If our system partially crashes, as is the norm for Erlang programs, it may be necessary to reconstruct state. Stable storage provides the basis from which we can re-read data into memory. Even if recreating data is expensive, you may still want a cache to be able to reconstruct your state faster from disk. Persistent store on a disk is among the best way to make sure data is there.
In a BitTorrent client like eTorrent for instance, we only worry about the file. If we download a piece of a file and that pieces pass the BitTorrent SHA1 integrity check, we can now regard that part as "safe" write to stable storage, and never touch it again. I don't have to care about the internal state of peers I am communicating with. I don't have to worry about any internal structure in memory. The on-disk partial download provides all the needed information to reconstruct the system from scratch should I need it.
Second, there may be state we don't really want to lose - but we can afford it. We can't recreate a user input, so we need that on stable storage like above. But we don't want to redo expensive work if we can. To fix this in Erlang, we create a process to keep the important data, and we let that process protect the data simply by validating and verifying any change of the data. The process becomes a castle with the princess in it. And with a nasty dragon at the drawbridge. (Naturally, the princess and dragon have exquisite meals each night together and they like to dance tango. The nastiness and damsel-in-distress is only kept up for fun to lure unsuspecting knights to the party).
Third, we can exploit that sequential Erlang is a functional programming language. If we are state S1 and we apply a function to obtain state S2, we have an interesting property: either we obtain S2, or we get an error. But since the data store is persistent, we still have access to S1 if we keep a reference to it. This in effect creates an atomic way of processing: Either we get to the new state safely, or we can't move to the new state due to an error. This means that each state becomes a safe-haven in our processing. Since we can't mutate data, there is no way the processing to obtain S2 can corrupt the state of S1. It allows us to build programs that are highly stable as it ultimately works like a CPU: We have a state and atomically we process a clock cycle to obtain a new state. There is no "in between".
(Note: I must strain that modern CPUs are more advanced than this, but they try to uphold the illusion above)
Fourth, we can exploit the isolation between processes. To get state, I must ask another process for it. To ask another process for it, I must send it a message. It might never answer. So I must build my system around the idea that systems will fail occasionally. If it answers however, the data is now mine to do with as I please. It may be invalid since it is too old, but as long as I have it, I can do with it what I please. At that point, I don't care too much about the fate of the other process, since I have a safe copy. This in turn can used to build a system where we know where the stable state is all the time.
Fifth, we can exploit distributed Erlang. Have a couple of nodes. Store important data on multiple nodes. Now, should one node crash, the other nodes still have the data. And memory + network communication is often way faster than disk. Not to mention that you can get better parallel execution and faster recovery since data is already there in memory, ready to be served on the 10 gigabit link. The princess just phoned her girlfriends in Britain, France, Italy and Russia with the recipes for the next 100 meals (...and her work on homotopic type theory - princesses do have spare time to do research after all).
See, the point is: when the system begins failing - how do we want it to crash? When you get the chainsaw and slay the proverbial dragon (the tree in your garden which slighty but not really looks like a dragon at all) you don't want it to fall down into your nice house. You want it to crash differently, down on the lawn. The same with Erlang programs. We want them to crash so it has little impact on users, but also such that our important data is still safe. And if it goes really wrong, we want data persisted somewhere else. Either on another node in the cluster, or on disk. We want it to crash in ways which avoids the stable state.
The key is that we begin thinking about crashing a priori, before it happens. We think of where we have stable state and what parts we don't worry about crashing. The secret behind BitTorrent clients are that they are easy: you can throw away everything, sans the pieces of the file that have been checked for integrity. Everything else can just go crashing as it sees fit, we don't care. But when you take your own application and do the same kind of thinking, chances are that you will reach the same conclusion: there is a little bit of the system which needs protection, but you don't care about the rest.
That is a hint on how to structure your Erlang program.
PS. I should probably also write about how the loose coupling of Erlang processes foster good architecture, but that is another post for another time :)
(Edited a couple of times to fix wording - thanks DeadZen)
Poul-Henning Kamp
a.k.a. phk
Win8/ARM - M$ på rette spor ? (May 10, 2012, 10:15 UTC)
Microsofts beslutning om ikke at lave plads til andre browsere på Win8/ARM får en del exposure lige nu. men jeg synes der mangler en dimension i debatten.
Microsoft står for første gang siden NT/Alpha overfor en CPU der virkelig adskiller sig fra X86.
Det er ikke sjovt, det er overhovedet ikke ... May 08, 2012
Lars Sommer
a.k.a. lasg
Ved du hvad din firewall laver, når du ikke kigger? (May 08, 2012, 11:09 UTC)
Der har i mange år været fokus på malware til både PC'er, servere og smartphones. Men hvad med alt det andet udstyr vi har stående i serverrummet?
I 2010 og 2011 var der lidt fokus på SCADA-systemer, da Stuxnet-virussen blev kendt. Men der er intet fokus på netværksudstyr.
Har du nogensinde over...
Poul-Henning Kamp
a.k.a. phk
Brugervenlig IT (May 08, 2012, 06:56 UTC)
Vi tvinges som borgere til at være data i en masse IT systemer, men vi får næsten aldrig lov til at udnytte de fordele som intelligent anvendelse af data giver mulighed for.
Forestil jer at parti kød viser sig at indeholde et eller andet farligt og skal tilbagekaldes.
Idag bringer man det i rad... May 03, 2012
Dropbox på OpenSuSE 11.4 (May 03, 2012, 09:25 UTC)
Sidder og fedter med at få Dropbox installeret på min OpenSuSE 11.4. Der ligger en Fedora rpm på dropbox.com som fejler med uløste “dependencies” på pygtk2, som ikke lige er til at finde ud af.
Efter at have brugt alt for meget tid men at google, fandt jeg ud af, at dropbox ligger i softwarekilden ‘Hovedsoftwarekilde (Contrib)’.
For at spare andre for at spilde tid, klares installationen sådan:
sudo zypper addrepo http://download.opensuse.org/repositories/openSUSE:/11.4:/Contrib/standard/ “Hovedsoftwarekilde (Contrib)”
sudo zypper install dropbox dropbox-servicemenu nautilus-dropbox
May 02, 2012
Peter Toft
a.k.a. pto
Raspberry Pi - om tre dage?! (May 02, 2012, 18:45 UTC)
I kan sikkert huske at jeg har bestilt en Raspberri Pi fra Farnell - og jeg er på venteliste hos RS..
Fra Farnell har jeg intet hørt siden jeg fik en faktura hvilket skete på bestillingsdagen. RS har siden den gang skrevet emails ud hver uge "nu er ...næsten.... nu" men ikke meget konkret info.
... May 01, 2012
Poul-Henning Kamp
a.k.a. phk
Steganografi er slet ikke nemt. (May 01, 2012, 16:11 UTC)
Blandt hovmodige "cybernørder" er steganografi altid et hit, primært på grund af "alle strissere er for dumme" antagelsen.
Lige nu er en historie i nyhederne om terrorplaner fundet på en USB stick fyldt med pornofilm, et klassisk eksempel på steganografi.
Det er svært at lave steganografi godt,... April 29, 2012
Sune Vuorela
a.k.a. pusling
Boat to akademy? (April 29, 2012, 19:29 UTC)
I’m planning on taking the Tallink Silja boat from Stockholm to Tallin to get to (and from) Akademy. It is a all-night boat with restaurants, bars and almost whatever you would like. The boat leaves shortly before dinner and arrives shortly after breakfast and it is full of great fun.
Last time (Akademy 2010 in Tampere), Inge, Ryan, Chani, Martin and me were on such a boat and it was a nice experience.
Anyone up for such a experience this year ?
You hopefully know how to reach me
April 26, 2012
Poul-Henning Kamp
a.k.a. phk
DDHFwiki er åben... (April 26, 2012, 21:40 UTC)
Det har taget noget knofedt, alle 350 sider er blevet læst igennem, men nu er Datamuseum.dk's Wiki åben for offentligheden:
http://datamuseum.dk/wiki/
Vi har ikke lige en kvart, halv eller hel milliard til at bygge et museum for, så indtil videre må vi nøjes med vores depot i Ballerup og vores ... April 25, 2012
Peter Toft
a.k.a. pto
Google Drive (del 2) - Google ringede til mig :-) (April 25, 2012, 21:15 UTC)
Efter jeg skrev mit forrige blogindlæg http://v2.dk/45054 så blev jeg ringet op af en PR-Manager for Google Enterprise i dag. Han skrev at Google har udsendt følgende præcisering i dag angående Google Drive:
As we state in our terms of service, we don't claim ownership or control over your cont...
Google Drive - endelig kom det (og fejlede) (April 25, 2012, 06:37 UTC)
Hen over de sidste mange år har Google Drive været på rygtebasis. Netdrevet hos Google, som skulle slå f.eks. Dropbox af banen. I går kom det endelig på https://drive.google.com/ med fin Windows- og Android-integration.
Det spiller glimrende og direkte sammen med Google Docs, men ingen Linux unde... April 24, 2012
Poul-Henning Kamp
a.k.a. phk
eValg: Vis hvad I dur til ... (April 24, 2012, 13:24 UTC)
Der er folk der roder med "digitale fremmødevalg" i kommunalvalgs-kontext og de vil åbenbart have mig med i en workshop.
Fair nok, men jeg er en stor tilhænger af udliciteringer, så gider I ikke lige lave mit hjemmearbejde for mig ? :-)
"Digitalt fremmødevalg" handler om at få talt stemmerne h... April 22, 2012
Nemoland Sommerkoncerter 2012 (April 22, 2012, 09:34 UTC)
Nemoland har igen i år en række sommerkoncerter på programmet, hvor man bl.a. kan møde Sussi & Leo og Fallulah.
Programmet er tilgængeligt på Nemolands hjemmeside, men ikke i et specielt smartphone-venligt format.
Som en service fra mig til hele internettet er her således en Google-kalender med alle koncerterne indskrevet. Selvfølgelig med forbehold for fejl…
Rettelser er selvfølgelig velkomne!
Direkte links til html, ics og xml.
Foto af: Michael Falgreen.
April 20, 2012
Poul-Henning Kamp
a.k.a. phk
Åh nej, ikke nu igen... (April 20, 2012, 07:16 UTC)
Har i hørt om IT-systemet "DUBU" ?
Det står for "Digitalisering Udsatte Børn og Unge" og har en formålsparagraf der hedder noget i stil med:
DUBU, en fællesoffentlig it-løsning, der vil fremme effektivitet og kvalitet på området Udsatte børn og unge, gik i drift ultimo 2011.Brug af løsningen re... April 19, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Søren Schrøder - arkitekt hos Telenor (April 19, 2012, 19:00 UTC)
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Søren har været med til at lave netværk og mange andre ting til Linuxforum/Open Source Days.
Jeg har med vilje gemt dette interview ...
Open Source på arbejde: Mød Peter Müller - webprogrammør hos One.com (April 19, 2012, 04:30 UTC)
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Peter Müller er ansat hos One.com - nok landets største web-hosting firma, med masser af Linux-maskiner. Peter laver webprogrammering... April 18, 2012
Ubuntu 12.04 release party i København (April 18, 2012, 21:11 UTC)
På torsdag i næste uge, d. 26. april bliver Ubuntu 12.04 udgivet.
Søndag d. 29. april markerer vi udgivelsen i Ubuntu København. Vi mødes kl. 17 på Klaptræet på Kultorvet (tæt på Nørreport station). Der er ikke fastlagt noget program, så bare kom forbi og drik en kaffe, øl eller sodavand i venligt lag, mens du deler dine erfaringer med Ubuntu og hører hvad andre bruger systemet til.
For mere info, se
http://loco.ubuntu.com/events/ubuntu-dk/1685/detail/
https://www.facebook.com/events/155120397947872/
April 17, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Sidsel Jensen - systemadministrator hos Telia (April 17, 2012, 22:01 UTC)
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Sidsel er også en af mine gode venner. Vi har lavet mange Linuxforum/Open Source Days konferencer sammen, og det har været en fornøje...
Poul-Henning Kamp
a.k.a. phk
En advokat kom marcherende... (April 17, 2012, 18:08 UTC)
Vi har lige haft bloggermøde på Version2, det er altid underholdende, ikke mindst fordi der dukker nye ansigter op hver gang.
En lang tendens i branchen kulminerede idag, hvor de sædvanlige open source fanatikere sad på den ene side bordet og på den anden side sad der bla. tre jurister og ophavs... April 16, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Kenneth Geisshirt - freelance konsulent (April 16, 2012, 22:05 UTC)
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Kenneth Geisshirt er en af mine meget gamle venner. Vi har leget med Open Source i mange år. Vi har i sin tid været sammen om at skri... April 15, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Maja Løkkegaard - projektleder hos cloud.dk (April 15, 2012, 23:01 UTC)
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Jeg havde tidligt i forløbet tænkt på at jeg gerne ville have en projektleder med, som arbejdede med Open Source-relatede projekter.
... April 13, 2012
Why Not Use Port Knocking? (April 13, 2012, 13:31 UTC)
The robots currently at work knocking around for your guessable password could easily be repurposed to guess your Unicode password currently known as your port knocking sequence, and quite likely have been already. Plus, we already have authpf(8) for network-level restrictions on access.
Whenever you write about security in general and SSH security in particular (and for good measure also get slashdotted for your efforts), the comments inevitably turn up a variety of useful and less useful suggestions.
The April 6th, 2012 article about the possible preparations for a new round of slow bruteforcers was no different. Some of these recurring ideas are worthy of some more attention, and a more or less complete list is as follows -
I must admit that the port knocking concept fascinated me at first, but all implementations had the downside of adding yet another piece of clearly experimental software to my system along with somewhat convoluted procedures for setting the thing up, so I left it for later.
At each of the later dates when i decided to look into the topic again, I discovered new reasons not to like the method (read this thread on OpenBSD-misc for a particularly disenchanting example -- how's single-packet unconditional remote reboot or remote kill your sshd for a feature?). Finally, it was the appearance of the slow bruteforcers (also known as the Hail Mary Cloud) that made me finally decide that port knocking is neither particularly elegant or actually useful.
One of the reasons the port knocking concept seems so deceptively attractive is probably that it is fairly easy to explain (see the Port Knocking article on Wikipedia for a fairly thorough treatment). The target system runs with no services accessible to the outside, and in order to gain access a remote system must send a specific, pre-determined sequence of packets aimed at specified ports. Unless you know (or are able to guess) the correct sequence of ports, you will not be able to gain any access to the target system.
And after this explanation, the naive listener goes
But first impressions are not always correct. First, please take one step back and explain to me what problem this is supposed to solve. If the answer is the old canard "all the insecurities of that horrible SSH protocol", I will ask you to please point out to me just what those are, and if you will, describe which parts of what I am about to describe actually adds value (that's "security" to you) in a real life scenario.
So let's go straight to the the core of the matter, and consider what actual information content an attacker would need to get right in order to gain access to the system. The hopeful would need to know or guess a sequence of TCP or UDP ports. In both cases, the range of possible ports is a 16 bit number, with a total of 65536 possible values.
Each value is a 16-bit number, with a size of two bytes, or equal to two ASCII characters or one Unicode character. Port knocking examples generally do not run to more than three packets, which means that the minimum amount of information a prospective attacker would need to get right in order to gain access is six bytes, equal to six ASCII characters or three Unicode characters.
Seen from this angle, all port knocking gets you is a somewhat cumbersome method for encoding your unicode password. In most implementations, that password would even be common to all users, with no easy way to change it.
And of course, in almost all other contexts where passwords are used, most sites dictate that you choose a personal password that is longer than six bytes. So that's at least two failures rolled into one: a password that's common to several or all users, and one that is hard or impossible to change, possibly even short enough to fail even basic guidelines.
The amount of information an attacker would need to get right, measured in number of bits or bytes is a fairly useful measure. I admit it's a fairly crude measure, but at least real data are easy to obtain, and since we are talking here about designing and maintaining systems, not writing them, how much cryptographic fun goes into generating the necessary data is not really relevant to the context. Proper cryptography is essential to maintain confidentiality and ensure the integrity of the communications, but we'll leave the details of the crypto bits for a later time.
One other factor that speaks against most implementations of port knocking is that the system runs with no ports open, and a daemon that parses firewall logs for anticipated sequences of port numbers contacted as the sole authority to determine whether access will be granted. We all know that all non-trivial software will contain bugs, so what are the chances that even a fairly simple deamon will at some point in the future be confronted with a situation that makes it terminate, making your system inaccessible (or as we say around here, "bricking your system")?
And one other thing, how do you spot an attacker? If you're looking for access attempts to closed ports, as you should be if you run a port knocking setup, how do you spot an attacker in the primal soup of noise that will anyway be arriving at your public interfaces? Do you, for example, record all sequences that could possibly be seen as unsuccessful attempts and put the source addresses in a "definitely banned" list?
I have not seen any useful answer to that one either. Doing a sudo tcpdump -nettti pflog0 action drop (that is, using tcpdump(8) to extract information on blocked traffic from my packet filtering setup, directly from the log device) on my gateway here certainly shows me access attempts to ports I didn't know much about -- what legitimate purpose, for example, is UDP port 287 actually used for? Once again it all boils down to the fact that if you rely on port knocking, you're really only implementing a cumbersome variant encoding of relatively short passwords.
On a side note (thanks to Adrian Close for reminding me), anybody who sits in the signal path between your knock target and somebody executing the correct knock sequence will be able to record the connections (using, for example, a netflow based tool -- expect to see Netflow-themed columns here in the future), making your closely guarded secret roughly equivalent to a plaintext password much like we used to see in old-style ftp setups.
Next, let us let us instead look at the thing port knocking is trying to protect, namely the sshd service. Typical SSH connection setup involves the transfer of at least the public host keys (typically in the some hundred bytes to several kilobytes range), followed by the user authentication which can involve passwords, keys or a number of cryptography based toys^H^Hols, in any case producing further transfer and validation of anything up to several more kilobytes of data (and in some setups, use of out-of-band methods like short lived keys generated by special-purpose devices) before any meaningful access is possible. The exchange and validation of host keys in itself involves more information that the attacker would have to get right in order to gain access than is involved in any port knocking setup I've seen demonstrated. And remember, host keys exchange is only one early steps of several on the way to authentication.
For the actual math on how data sizes and entropy is significant (yes, in some contexts, size does matter), see the Wikipedia entry and a somewhat shorter summary by Phil Ratcliffe.
All port knocking implementations share the problems I've outlined, and their proponents have tended to ignore or gloss over the issues rather than address them. It is an unfortunate and perhaps embarrasing fact that port knocking in practice comes down to implementing and maintaining a separate set of passwords, and in all likelihood you will be using tools that are less appropriate for the task than the ones that already come with the base system on any reasonable Unix-like system.
In an environment where we know there are large, distributed efforts underway to crack easily guessable passwords, it is naive not to assume that the same password guessing tools could be adapted to try sequences of TCP or UDP ports instead of character sequences. If there is in fact any significant number of systems that use port knocking today, it would surprise me if this isn't already happening. The way I see it, the belief that port knocking in fact offers an effective protection against attackers is a dangerous misunderstanding and probably only serves to divert your attention away from the real problems involved in keeping your systems running in a secure fashion.
If you're still not convinced, I'll show you a better way
Now, if you really, really want to implement port knocking anyway, I'll let you in on a dirty little secret: you don't need a write a new daemon or install anything besides what's already in the OpenBSD base system (or for that matter, on other PF-equipped BSD variants).
You can implement port knocking in a relatively straightforward manner via minor contortions in your PF rule set, and I know for a fact that people have done just that. The examples I was thinking of before I started writing this piece appear to have been removed from the public eye, but with a little effort using the obvious keywords, some well intended but actually quite bad advice on how to put together a seemingly elegant implementation will be on its way to you.
Be aware that you will be doing things the tools were not designed for, and more likely than not you will soon find yourself in a mess of rinky-dink workarounds that keep fighting back.
If, however, what you really want to do is create a separate line of defence with its own round of authentication required for access, your OpenBSD base system already contains a suitable tool in authpf(8). It's fairly easy to come up with a setup that lets your users log in to the authenticating gateway, using any authentication method sshd(8) supports.
You can even run your inital sshd(8) on a separate, non-standard port if you like, and a successful login at that point will only result in a set of packet filtering rules (possibly tailored to that specific user) being loaded. When the ssh session terminates, the rules are unloaded, and the system reverts to the state it had before the user authenticated.
The tools are as flexible and robust as you have come to expect from the OpenBSD system tools (even if you're not running OpenBSD at the moment, you are by a large margin more likely than not using OpenSSH as your ssh client and server, which is supplied to the world by the OpenBSD project), and you can tailor your access profiles and services to your heart's content so they fit your needs.
If you've read this far, you've probably also come to the conclusion that port knocking is really not the way to go. Other, more appropriate tools exist. But how to go about improving the situation?
My suggestions follow below, with some specific suggestions that may have a personal slant.
A Path To Self Improvement
As with any problem that is really rooted in a lack of information or knowledge, educating yourself is the key. Read up on relevant subjects, go back and determine what problem you are actually trying to solve, and then perhaps shop around for tools that will help you solve that problem.
My suggestion is to go to first to www.openbsd.org and browse the resources available there, including the online manual pages and the extensive FAQ document that actually serves quite well as a user manual.
The next logical step is to go to the Orders page and order at least one copy of the latest release (and if you're reading this not too long after publication, do pre-order the upcoming release as well). If you're too impatient to wait for the postal services' mules to load up and deliver, you could download the release (or a -current snapshot if you're feeling adventurous) from a suitable mirror site and start installing right away.
If you don't order any merchandise, you really should head over to the donations page and donate at least an amount equal to the cost of the CDs and other stuff you would otherwise have ordered. There are several fit and frightening ghosts primed and ready to come haunt you if you don't.
If you want some literature to back up the official OpenBSD documentation, you could do worse than order The Book of PF, 2nd edition and Michael W. Lucas' 2012 book SSH Mastery. Using those links here will ensure the OpenBSD project gets a larger-than-otherwise cut of the money as net profit. There are also electronic versions available for both titles (see The Book of PF home page or the SSH Mastery home page for details). If you're really short of funds, even the free, online PF tutorial that the Book of PF evolved from will get you started.
And finally, there are few places better to collect useful information about OpenBSD and its sister operating systems than the various local and regional user groups and conferences such as the upcoming BSDCan in Ottawa, Canada May 9th through 12th, 2012 or EuroBSDCon, with this year's version to be held in Warsaw, Poland October 18th through 21st.
These events attract both regular users (some of them quite proficient) as well as a useful subset of the people who write and maintain the tools.
Whatever you end up doing, buying or downloading, please keep in mind that it's your responsibility to keep your systems in the best possible shape, and make sure you monitor them properly, via log files or other means. Also see the Pledge of the Network Admin for my (slightly humorous) take on that responsibility. Along with the better parts of the tutorial, it made its way into the book, too.
Thanks to Michael Dexter, Kristaps Dzonsons, Michael W. Lucas, Thordur Bjornsson and Henning Brauer for insightful comments and valuable input.
Copyright © 2012 Peter N. M. Hansteen
If you found this article inspiring, irritating, useful or otherwise moving, please let me know via the comments field just below here, or if you like, drop me a line at peter at bsdly dot se.
Whenever you write about security in general and SSH security in particular (and for good measure also get slashdotted for your efforts), the comments inevitably turn up a variety of useful and less useful suggestions.
The April 6th, 2012 article about the possible preparations for a new round of slow bruteforcers was no different. Some of these recurring ideas are worthy of some more attention, and a more or less complete list is as follows -
- Set up iptables with the recent module - a clear indication that the commenter did not, in fact read the article. That module implements a subset of the state tracking techniques from my PF rule set referenced in the article, but unlike the PF rules it is specific to the SSH protocol rather than a general technique. And inevitably, the actual configuration the poster presents would in fact not trigger on the kind of traffic we see from the Hail Mary Cloud with its signature slow brute force attempts. Misunderstandings of this kind keep cropping up, for no good reason.
- Disable root logins over the network. Yes, this is obviously useful, and if I remember correctly, PermitRootLogin no is the default in recent OpenSSH versions. Do remember to check what the setting is on your kit, obviously.
- Use packet filtering or other means to restrict where users can log in from. Once again, a very useful suggestion, but some sites may require shell access from semi-random locations, so practical issues (aka real life) can interfere with this one.
- Disable password logins entirely, and allow only key-based logins. Another a very useful suggestion, and one that is useful for several reasons. You do get the downside of managing your keys securely, but key-only logins are generally recommended practice and should be encouraged.
- Set up your sshd to listen on a non-standard port. Several sites report less log file noise after moving their sshd to a non-standard port. Easy to implement and possibly useful, but if a prospective attacker takes the time to do a real port scan for active services, they will find your sshd running on port 22222 fairly easily. I'd say moving your sshd to listen on a non-standard port postpones rather than solves the problem.
- Use denyhosts to automatically add hosts with too many failed logins to a blacklist. Yes, an excellent idea in principle, but it comes with one caveat: Creating a blacklist automatically leaves you in charge of maintaining its content. Blacklist maintenance -- as in keeping your lists up to date and useful, is a complex enough issue that I'm fairly confident it is worth a separate column, and I most likely will return to the issue later.
- Why not set up port knocking? Well, as you may have guessed I'm about to tell you about a few whys not. I've been circling port knocking as an article subject for a long time, and now it seems that the time has come to outline why I think that port knocking emphatically not a good idea. Read below for my take on the subject.
I must admit that the port knocking concept fascinated me at first, but all implementations had the downside of adding yet another piece of clearly experimental software to my system along with somewhat convoluted procedures for setting the thing up, so I left it for later.
At each of the later dates when i decided to look into the topic again, I discovered new reasons not to like the method (read this thread on OpenBSD-misc for a particularly disenchanting example -- how's single-packet unconditional remote reboot or remote kill your sshd for a feature?). Finally, it was the appearance of the slow bruteforcers (also known as the Hail Mary Cloud) that made me finally decide that port knocking is neither particularly elegant or actually useful.
One of the reasons the port knocking concept seems so deceptively attractive is probably that it is fairly easy to explain (see the Port Knocking article on Wikipedia for a fairly thorough treatment). The target system runs with no services accessible to the outside, and in order to gain access a remote system must send a specific, pre-determined sequence of packets aimed at specified ports. Unless you know (or are able to guess) the correct sequence of ports, you will not be able to gain any access to the target system.
And after this explanation, the naive listener goes
"Oh, how clever, we send packets to random ports!
Nobody will ever be able to guess our combination!".
But first impressions are not always correct. First, please take one step back and explain to me what problem this is supposed to solve. If the answer is the old canard "all the insecurities of that horrible SSH protocol", I will ask you to please point out to me just what those are, and if you will, describe which parts of what I am about to describe actually adds value (that's "security" to you) in a real life scenario.
So let's go straight to the the core of the matter, and consider what actual information content an attacker would need to get right in order to gain access to the system. The hopeful would need to know or guess a sequence of TCP or UDP ports. In both cases, the range of possible ports is a 16 bit number, with a total of 65536 possible values.
Each value is a 16-bit number, with a size of two bytes, or equal to two ASCII characters or one Unicode character. Port knocking examples generally do not run to more than three packets, which means that the minimum amount of information a prospective attacker would need to get right in order to gain access is six bytes, equal to six ASCII characters or three Unicode characters.
Seen from this angle, all port knocking gets you is a somewhat cumbersome method for encoding your unicode password. In most implementations, that password would even be common to all users, with no easy way to change it.
And of course, in almost all other contexts where passwords are used, most sites dictate that you choose a personal password that is longer than six bytes. So that's at least two failures rolled into one: a password that's common to several or all users, and one that is hard or impossible to change, possibly even short enough to fail even basic guidelines.
The amount of information an attacker would need to get right, measured in number of bits or bytes is a fairly useful measure. I admit it's a fairly crude measure, but at least real data are easy to obtain, and since we are talking here about designing and maintaining systems, not writing them, how much cryptographic fun goes into generating the necessary data is not really relevant to the context. Proper cryptography is essential to maintain confidentiality and ensure the integrity of the communications, but we'll leave the details of the crypto bits for a later time.
One other factor that speaks against most implementations of port knocking is that the system runs with no ports open, and a daemon that parses firewall logs for anticipated sequences of port numbers contacted as the sole authority to determine whether access will be granted. We all know that all non-trivial software will contain bugs, so what are the chances that even a fairly simple deamon will at some point in the future be confronted with a situation that makes it terminate, making your system inaccessible (or as we say around here, "bricking your system")?
And one other thing, how do you spot an attacker? If you're looking for access attempts to closed ports, as you should be if you run a port knocking setup, how do you spot an attacker in the primal soup of noise that will anyway be arriving at your public interfaces? Do you, for example, record all sequences that could possibly be seen as unsuccessful attempts and put the source addresses in a "definitely banned" list?
I have not seen any useful answer to that one either. Doing a sudo tcpdump -nettti pflog0 action drop (that is, using tcpdump(8) to extract information on blocked traffic from my packet filtering setup, directly from the log device) on my gateway here certainly shows me access attempts to ports I didn't know much about -- what legitimate purpose, for example, is UDP port 287 actually used for? Once again it all boils down to the fact that if you rely on port knocking, you're really only implementing a cumbersome variant encoding of relatively short passwords.
On a side note (thanks to Adrian Close for reminding me), anybody who sits in the signal path between your knock target and somebody executing the correct knock sequence will be able to record the connections (using, for example, a netflow based tool -- expect to see Netflow-themed columns here in the future), making your closely guarded secret roughly equivalent to a plaintext password much like we used to see in old-style ftp setups.
Next, let us let us instead look at the thing port knocking is trying to protect, namely the sshd service. Typical SSH connection setup involves the transfer of at least the public host keys (typically in the some hundred bytes to several kilobytes range), followed by the user authentication which can involve passwords, keys or a number of cryptography based toys^H^Hols, in any case producing further transfer and validation of anything up to several more kilobytes of data (and in some setups, use of out-of-band methods like short lived keys generated by special-purpose devices) before any meaningful access is possible. The exchange and validation of host keys in itself involves more information that the attacker would have to get right in order to gain access than is involved in any port knocking setup I've seen demonstrated. And remember, host keys exchange is only one early steps of several on the way to authentication.
For the actual math on how data sizes and entropy is significant (yes, in some contexts, size does matter), see the Wikipedia entry and a somewhat shorter summary by Phil Ratcliffe.
All port knocking implementations share the problems I've outlined, and their proponents have tended to ignore or gloss over the issues rather than address them. It is an unfortunate and perhaps embarrasing fact that port knocking in practice comes down to implementing and maintaining a separate set of passwords, and in all likelihood you will be using tools that are less appropriate for the task than the ones that already come with the base system on any reasonable Unix-like system.
In an environment where we know there are large, distributed efforts underway to crack easily guessable passwords, it is naive not to assume that the same password guessing tools could be adapted to try sequences of TCP or UDP ports instead of character sequences. If there is in fact any significant number of systems that use port knocking today, it would surprise me if this isn't already happening. The way I see it, the belief that port knocking in fact offers an effective protection against attackers is a dangerous misunderstanding and probably only serves to divert your attention away from the real problems involved in keeping your systems running in a secure fashion.
If you're still not convinced, I'll show you a better way
Now, if you really, really want to implement port knocking anyway, I'll let you in on a dirty little secret: you don't need a write a new daemon or install anything besides what's already in the OpenBSD base system (or for that matter, on other PF-equipped BSD variants).
You can implement port knocking in a relatively straightforward manner via minor contortions in your PF rule set, and I know for a fact that people have done just that. The examples I was thinking of before I started writing this piece appear to have been removed from the public eye, but with a little effort using the obvious keywords, some well intended but actually quite bad advice on how to put together a seemingly elegant implementation will be on its way to you.
Be aware that you will be doing things the tools were not designed for, and more likely than not you will soon find yourself in a mess of rinky-dink workarounds that keep fighting back.
If, however, what you really want to do is create a separate line of defence with its own round of authentication required for access, your OpenBSD base system already contains a suitable tool in authpf(8). It's fairly easy to come up with a setup that lets your users log in to the authenticating gateway, using any authentication method sshd(8) supports.
You can even run your inital sshd(8) on a separate, non-standard port if you like, and a successful login at that point will only result in a set of packet filtering rules (possibly tailored to that specific user) being loaded. When the ssh session terminates, the rules are unloaded, and the system reverts to the state it had before the user authenticated.
The tools are as flexible and robust as you have come to expect from the OpenBSD system tools (even if you're not running OpenBSD at the moment, you are by a large margin more likely than not using OpenSSH as your ssh client and server, which is supplied to the world by the OpenBSD project), and you can tailor your access profiles and services to your heart's content so they fit your needs.
If you've read this far, you've probably also come to the conclusion that port knocking is really not the way to go. Other, more appropriate tools exist. But how to go about improving the situation?
My suggestions follow below, with some specific suggestions that may have a personal slant.
A Path To Self Improvement
As with any problem that is really rooted in a lack of information or knowledge, educating yourself is the key. Read up on relevant subjects, go back and determine what problem you are actually trying to solve, and then perhaps shop around for tools that will help you solve that problem.
My suggestion is to go to first to www.openbsd.org and browse the resources available there, including the online manual pages and the extensive FAQ document that actually serves quite well as a user manual.
The next logical step is to go to the Orders page and order at least one copy of the latest release (and if you're reading this not too long after publication, do pre-order the upcoming release as well). If you're too impatient to wait for the postal services' mules to load up and deliver, you could download the release (or a -current snapshot if you're feeling adventurous) from a suitable mirror site and start installing right away.
If you don't order any merchandise, you really should head over to the donations page and donate at least an amount equal to the cost of the CDs and other stuff you would otherwise have ordered. There are several fit and frightening ghosts primed and ready to come haunt you if you don't.
If you want some literature to back up the official OpenBSD documentation, you could do worse than order The Book of PF, 2nd edition and Michael W. Lucas' 2012 book SSH Mastery. Using those links here will ensure the OpenBSD project gets a larger-than-otherwise cut of the money as net profit. There are also electronic versions available for both titles (see The Book of PF home page or the SSH Mastery home page for details). If you're really short of funds, even the free, online PF tutorial that the Book of PF evolved from will get you started.
And finally, there are few places better to collect useful information about OpenBSD and its sister operating systems than the various local and regional user groups and conferences such as the upcoming BSDCan in Ottawa, Canada May 9th through 12th, 2012 or EuroBSDCon, with this year's version to be held in Warsaw, Poland October 18th through 21st.
These events attract both regular users (some of them quite proficient) as well as a useful subset of the people who write and maintain the tools.
Whatever you end up doing, buying or downloading, please keep in mind that it's your responsibility to keep your systems in the best possible shape, and make sure you monitor them properly, via log files or other means. Also see the Pledge of the Network Admin for my (slightly humorous) take on that responsibility. Along with the better parts of the tutorial, it made its way into the book, too.
Thanks to Michael Dexter, Kristaps Dzonsons, Michael W. Lucas, Thordur Bjornsson and Henning Brauer for insightful comments and valuable input.
Copyright © 2012 Peter N. M. Hansteen
If you found this article inspiring, irritating, useful or otherwise moving, please let me know via the comments field just below here, or if you like, drop me a line at peter at bsdly dot se.
Fredagsrock kalender 2012 (April 13, 2012, 08:17 UTC)
Tivoli har endnu ikke lært hvordan man publicerer en koncertkalender i et fornuftigt format til integration i diverse elektroniske kalendere.
De har en fin hjemmeside og Facebook-integration, men en simpel ical fil har jeg ikke kunne finde nogen steder.
Så jeg har sat mig på min flade og lavet en selv. Her følger en kalender over sommerens Fredagsrock koncerter.
(Selvfølgelig helt uofficiel, med forbehold for trykfejl, ændringer fra Tivolis side og aldeles uden ansvar.)
Direkte links til: ical .ics, html og xml
God fornøjelse.
Foto af Stig Nygaard
April 12, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Lars Christensen fra Renesas Mobile (April 12, 2012, 22:00 UTC)
Dette blog-indlæg er en del af en serie - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Ideen til denne blog-serie startede ved at jeg forklarede den 13-årige Asger om hvad jeg lavede på mit arbejde hos Renesas Mobile ved Københavns Sydhavn. Da jeg står ba...
Poul-Henning Kamp
a.k.a. phk
En gave fra CSC (April 12, 2012, 09:29 UTC)
Guderne skal vide at CSC's ledelse ikke er plaget af hverken moral, etik eller for den sags skyld kompetence, men de skal have tak for deres gave til det danske IT miljø.
Som med alle andre gaver, er det ikke sikkert at modtageren forstår at værdsætte den, så jeg tillader mig at skære det ud i p... April 11, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Jacob Nordfalk, Android-udvikler og lærer (April 11, 2012, 22:05 UTC)
Dette blog-indlæg er en del af en serie - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
I dette blog-indlæg skal I møde Jacob Nordfalk, som er en af de dygtigste Android-programmører i Danmark.
Android er bl.a. interessant, fordi der ligger Linux i bunden... April 10, 2012
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød Jacob Jensen, der laver små taxa-computere (April 10, 2012, 22:15 UTC)
Dette blog-indlæg er en del af en serie - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Et af de områder, hvor Linux har fået stor succes de sidste par år er i embeddede systemer. Firmaet Frogne A/S i Ishøj er et godt eksempel.
De laver systemer til flåde...
Peter Larsen
a.k.a. czar
5592 er tallet, spørgsmålet var? (April 10, 2012, 06:34 UTC)
Spørgsmålet var hvor mange nye gTLD ansøgninger som ICANN har fået, og som de afslører på en liste d. 30 april/1. maj som de har lovet de ville.
Ansøgningsvinduet lukker her d. 12. april, efter 3 måneder, det er om 2 dage.
Der er 839 antal oprettet i ICANN’s ansøgningsmodel TAS, det giver potentielt set 41111 antal ansøgninger da hver enkelt TAS bruger kan afgive 49 ansøgninger, men mit eget gæt er mere moderat :) *)
De fleste i branchen fedtspiller og gætter på ca 1000-1500 ansøgninger, hvilket nok også er mere realistisk. Men faktum er at google her i de sidste minutter feks har lavet sive at man “nok søger om nogle stringe”.. http://domainincite.com/google-confirms-new-gtld-bids/
Vi har set mange som har snakket om det, og som har sagt “det har vi ikke nogen interesse i”, men når de så er færdig med at snakke så har de selv lagt en ansøgning i bunken, google er ikke den første der gør det, og bliver ikke den sidste.
Jeg forventer derfor også at finde en ansøgning om et .lego og et .facebook, upåagtet af de har været store fortaler for at det nye gTLD program ikke skulle være der, og de har på den måde måske spillet et kort for at tage interessen væk fra deres egen ansøgning om et gTLD.
Den 12 april er runde 1 slut, d. 1. maj sidder jeg og ser på listen, og her vil jeg blogge om de 10 som jeg finder specielt interessante, på den ene eller anden måde :)
*) baseret på de nyeste tal jeg har set, men ikke det endelige tal
Peter Toft
a.k.a. pto
Open Source på arbejde: Mød robotforskeren Kjeld Jensen (April 10, 2012, 04:45 UTC)
Dette blog-indlæg er en del af en serie - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-...
Jeg fandt hurtigt ud af at jeg manglede kontakt til en person, der arbejdede aktivt med robotter. Jeg vidste at der er en hel del aktivitet i dette fagområde, hvor Linux... April 09, 2012
Poul-Henning Kamp
a.k.a. phk
Spredehaglsspam (April 09, 2012, 18:26 UTC)
Som alle andre bruger jeg google til at søge efter ting, men nogen gange er det dybt obskure ting jeg søger efter og det afslører artige ting om hvordan spam og markedsføring virker nu om dage.
For lidt siden var det en "MOS 6508" chip jeg var efter, en variant af 6502 til indlejrede opgaver.
M...
If We Go One Attempt Every Ten Seconds, We're Under The Radar (April 09, 2012, 16:11 UTC)
The Slime Also Evolves: New bruteforce ssh attempts come in at 10 second intervals, and they keep going even if we block them. Is this the warmup to a new iteration of the Hail Mary Cloud?
Regular readers will remember the activities of the Hail Mary Cloud, which turned up in authentication logs with large numbers of unsuccessful ssh login attempts, apparently coordinated across a large number of source IP addresses and with any individual host in the attacker set making a new attempts at intervals of anything from several seconds to several minutes.
Regular readers will remember the activities of the Hail Mary Cloud, which turned up in authentication logs with large numbers of unsuccessful ssh login attempts, apparently coordinated across a large number of source IP addresses and with any individual host in the attacker set making a new attempts at intervals of anything from several seconds to several minutes.
At the time, commentators took these activites either as an indication of a truly inspired idea from a brilliant mind (after all, avoiding detection is essential) or a token of almost unimaginable ineptitude or perhaps just an overdose of faith that if you keep going long enough, even extremely unlikely things will happen.
It's been a litte while now since we last saw the slow, distributed bruteforce attacks at work here at the BSDly labs (we've kept collecting data here), but one curious incident during the last week indicates that somebody, somewhere is still working on ssh cracking scripts that operate on fairly similar methods.
Bruteforce attacks can be fairly easy to detect and head off. In most cases the attacker comes in with a larger than usual number of login attempts in rapid succession from a single IP address, and with modern tools such as OpenBSD's PF packet filter, you can set up rules that use state tracking options to intercept. The phenomenon is common enough that the bruteforce avoidance section is one of the more popular parts of my online PF tutorial (and of course, a slightly expanded version is avavailable in The Book of PF).
I wouldn't publish or recommend anything that I haven't at least tried myself, so just to illustrate,
On Sunday, April 1st 2012, I noticed an unusually high number of ssh login attempts coming from two Chinese addresses (58.214.5.51 and 61.160.76.123), amazingly persistent and for some reason they had not been caught by my bruteforce avoidance rules. Thinking I'd simply adjust my rate settings, I simply added those addresses to the table by hand and started looking at the authentication log versus my rule set. Then a little while later, I noticed that instead of just bowing out after blocking, these two kept going. (I also tweeted about this, however not accurate in all details, at the time)
A little later that same evening, the table looked like this:
It's been a litte while now since we last saw the slow, distributed bruteforce attacks at work here at the BSDly labs (we've kept collecting data here), but one curious incident during the last week indicates that somebody, somewhere is still working on ssh cracking scripts that operate on fairly similar methods.
Bruteforce attacks can be fairly easy to detect and head off. In most cases the attacker comes in with a larger than usual number of login attempts in rapid succession from a single IP address, and with modern tools such as OpenBSD's PF packet filter, you can set up rules that use state tracking options to intercept. The phenomenon is common enough that the bruteforce avoidance section is one of the more popular parts of my online PF tutorial (and of course, a slightly expanded version is avavailable in The Book of PF).
I wouldn't publish or recommend anything that I haven't at least tried myself, so just to illustrate,
[Fri Apr 06 14:48:21] peter@skapet:~$ sudo grep bruteforce /etc/pf.confThe PF rules on BSDly.net's gateway have something much like the published example. This means that a traditional bruteforce attempt will end up something like this:
table <bruteforce> persist counters
block log (all) quick from <bruteforce>
pass log (all) proto { tcp, udp } to port ssh keep state (max-src-conn 15, max-src-conn-rate 7/4, overload <bruteforce>
[Fri Apr 06 15:30:38] peter@skapet:~$ grep 203.34.37.62 /var/log/authlogAnd looking up the current contents of the table shows our new perpetrator has indeed been caught:
Apr 5 17:42:36 skapet sshd[32722]: Failed password for root from 203.34.37.62 port 44936 ssh2
Apr 5 17:42:36 skapet sshd[32722]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:38 skapet sshd[26527]: Failed password for root from 203.34.37.62 port 45679 ssh2
Apr 5 17:42:38 skapet sshd[26527]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:41 skapet sshd[29912]: Invalid user db2inst1 from 203.34.37.62
Apr 5 17:42:41 skapet sshd[29912]: Failed password for invalid user db2inst1 from 203.34.37.62 port 46283 ssh2
Apr 5 17:42:41 skapet sshd[29912]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:43 skapet sshd[30349]: Failed password for root from 203.34.37.62 port 46898 ssh2
Apr 5 17:42:43 skapet sshd[30349]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:46 skapet sshd[25557]: Invalid user prueba from 203.34.37.62
Apr 5 17:42:46 skapet sshd[25557]: Failed password for invalid user prueba from 203.34.37.62 port 47495 ssh2
Apr 5 17:42:46 skapet sshd[25557]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:48 skapet sshd[5380]: Failed password for bin from 203.34.37.62 port 48087 ssh2
Apr 5 17:42:48 skapet sshd[5380]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:51 skapet sshd[23635]: Invalid user postgres from 203.34.37.62
Apr 5 17:42:51 skapet sshd[23635]: Failed password for invalid user postgres from 203.34.37.62 port 48658 ssh2
Apr 5 17:42:51 skapet sshd[23635]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:54 skapet sshd[2450]: Failed password for root from 203.34.37.62 port 49307 ssh2
Apr 5 17:42:54 skapet sshd[2450]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:56 skapet sshd[16673]: Failed password for root from 203.34.37.62 port 49910 ssh2
Apr 5 17:42:57 skapet sshd[16673]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:42:59 skapet sshd[17522]: Failed password for root from 203.34.37.62 port 50503 ssh2
Apr 5 17:42:59 skapet sshd[17522]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:43:02 skapet sshd[4633]: Invalid user mythtv from 203.34.37.62
Apr 5 17:43:02 skapet sshd[4633]: Failed password for invalid user mythtv from 203.34.37.62 port 51218 ssh2
Apr 5 17:43:02 skapet sshd[4633]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:43:05 skapet sshd[25728]: Failed password for root from 203.34.37.62 port 51849 ssh2
Apr 5 17:43:05 skapet sshd[25728]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:43:08 skapet sshd[10487]: Failed password for root from 203.34.37.62 port 52565 ssh2
Apr 5 17:43:08 skapet sshd[10487]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:43:10 skapet sshd[31156]: Failed password for root from 203.34.37.62 port 53264 ssh2
Apr 5 17:43:11 skapet sshd[31156]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
Apr 5 17:43:13 skapet sshd[31956]: Invalid user mmroot from 203.34.37.62
Apr 5 17:43:13 skapet sshd[31956]: Failed password for invalid user mmroot from 203.34.37.62 port 53958 ssh2
Apr 5 17:43:13 skapet sshd[31956]: Received disconnect from 203.34.37.62: 11: Bye Bye [preauth]
[Fri Apr 06 15:34:23] peter@skapet:~$ sudo pfctl -t bruteforce -vT showThe table data show us one more thing worth noting: All of these bruteforcers sent exactly one packet after they were blocked, and gave up right away when they noticed they were blocked.
91.197.131.24
Cleared: Thu Apr 5 20:22:29 2012
In/Block: [ Packets: 1 Bytes: 52 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
200.11.174.131
Cleared: Thu Apr 5 19:09:30 2012
In/Block: [ Packets: 1 Bytes: 52 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
203.34.37.62
Cleared: Thu Apr 5 17:43:13 2012
In/Block: [ Packets: 1 Bytes: 52 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
On Sunday, April 1st 2012, I noticed an unusually high number of ssh login attempts coming from two Chinese addresses (58.214.5.51 and 61.160.76.123), amazingly persistent and for some reason they had not been caught by my bruteforce avoidance rules. Thinking I'd simply adjust my rate settings, I simply added those addresses to the table by hand and started looking at the authentication log versus my rule set. Then a little while later, I noticed that instead of just bowing out after blocking, these two kept going. (I also tweeted about this, however not accurate in all details, at the time)
A little later that same evening, the table looked like this:
[Sun Apr 01 22:58:02] peter@skapet:~$ sudo pfctl -t bruteforce -vT showThe two hosts kept coming, at a rate of roughly one attempt every ten seconds, and apparently ignored the fact that they were blocked in the packet filter rules and would be getting connection refused errors for each attempt.
58.51.95.75
Cleared: Sun Apr 1 22:05:29 2012
In/Block: [ Packets: 1 Bytes: 52 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
58.214.5.51
Cleared: Sun Apr 1 14:06:21 2012
In/Block: [ Packets: 3324 Bytes: 199440 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
61.91.125.115
Cleared: Sun Apr 1 03:10:05 2012
In/Block: [ Packets: 1 Bytes: 52 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
61.160.76.123
Cleared: Sun Apr 1 14:07:08 2012
In/Block: [ Packets: 3262 Bytes: 195720 ]
In/Pass: [ Packets: 0 Bytes: 0 ]
Out/Block: [ Packets: 0 Bytes: 0 ]
Out/Pass: [ Packets: 0 Bytes: 0 ]
Looking at the log data (preserved here along with data from various other attempts from other sources in the relevant period), both hosts were busy trying to guess root's password from the time they started until they were blocked. When the block expired after 24 hours, they had both apparently proceeded down similiar lists of user names and were busy with rooter):
Apr 2 14:10:06 skapet sshd[13332]: Invalid user rooter from 61.160.76.123They both kept going afterwards, at roughly the same rates as before. The host at 61.160.76.123 kept varying its rate and at one point sped up enough that it triggered the automatic bruteforce blocking.
Apr 2 14:10:06 skapet sshd[13332]: input_userauth_request: invalid user rooter [preauth]
Apr 2 14:10:06 skapet sshd[13332]: Failed password for invalid user rooter from 61.160.76.123 port 46578 ssh2
Apr 2 14:10:06 skapet sshd[13332]: Received disconnect from 61.160.76.123: 11: Bye Bye [preauth]
Apr 2 14:10:14 skapet sshd[30888]: Invalid user rooter from 58.214.5.51
Apr 2 14:10:14 skapet sshd[30888]: input_userauth_request: invalid user rooter [preauth]
Apr 2 14:10:14 skapet sshd[30888]: Failed password for invalid user rooter from 58.214.5.51 port 47587 ssh2
Apr 2 14:10:14 skapet sshd[30888]: Received disconnect from 58.214.5.51: 11: Bye Bye [preauth]
After running a fairly familiar alphabetic progression through a list of supposed user names, the remaining host finally gave up during the first hour of April 3rd, by CEST time:
It could be instructive to compare this last batch with the previous samples. The log format differs slightly, since the previous attempts were aimed at FreeBSD machines, while this last round was aimed at a single OpenBSD host.
The whois information for the two hosts (58.214.5.51 and 61.160.76.123) both point to Chinese networks, as far as I can tell in the same provice and possibly in the same city, Wuxi, which appears to be one of several Chinese tech cities.
The slow rate of the login attempts and the sequence of user names attempted are both similar enough to the earlier distributed attempts that it's possible this is a limited experiment by the developers of the previous bruteforcing malware. The rate of roughly one attempt per host per 10 seconds is a significant speedup compared to the previous attempts, and it fits in the interval where blocking due to the rate of connections would most likely produce an unacceptably high number of false positives.
Apr 3 00:36:24 skapet sshd[30287]: Received disconnect from 58.214.5.51: 11: Bye Bye [preauth]Before we go into further details, I have a question for you, dear reader: Did anything like this turn up in your authentication logs during the same rough time frame? If your logs show something similar, please drop me a line at (lightly obfuscated) peter at bsdly dot se.
Apr 3 00:36:33 skapet sshd[27318]: Invalid user clodia from 58.214.5.51
Apr 3 00:36:33 skapet sshd[27318]: input_userauth_request: invalid user clodia [preauth]
Apr 3 00:36:33 skapet sshd[27318]: Failed password for invalid user clodia from 58.214.5.51 port 58185 ssh2
Apr 3 00:36:33 skapet sshd[27318]: Received disconnect from 58.214.5.51: 11: Bye Bye [preauth]
It could be instructive to compare this last batch with the previous samples. The log format differs slightly, since the previous attempts were aimed at FreeBSD machines, while this last round was aimed at a single OpenBSD host.
The whois information for the two hosts (58.214.5.51 and 61.160.76.123) both point to Chinese networks, as far as I can tell in the same provice and possibly in the same city, Wuxi, which appears to be one of several Chinese tech cities.
The slow rate of the login attempts and the sequence of user names attempted are both similar enough to the earlier distributed attempts that it's possible this is a limited experiment by the developers of the previous bruteforcing malware. The rate of roughly one attempt per host per 10 seconds is a significant speedup compared to the previous attempts, and it fits in the interval where blocking due to the rate of connections would most likely produce an unacceptably high number of false positives.
It will be interesting to see what rate of incoming connection the next full scale attempts will be using. It is possible that the source addresses are somewhere close to the actual whereabouts of the malware developers, but at this point it's pure speculation.
At this point we can only keep watching our logs and make sure that our sshd configurations are the best possible shape. If you need up to date advice on how to configure and use SSH safely, you could do significantly worse than grabbing Michael W. Lucas' recent SSH book SSH Mastery.
At this point we can only keep watching our logs and make sure that our sshd configurations are the best possible shape. If you need up to date advice on how to configure and use SSH safely, you could do significantly worse than grabbing Michael W. Lucas' recent SSH book SSH Mastery.
The task panel in LibreOffice (April 09, 2012, 15:56 UTC)
<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } -->LibreOffice has a very little known feature called the task pane. You might already be familiar with the navigator and the Styles and formatting dialogues. These dialogues are dockable whitch means that you can glue the dialogues to the border of the LibreOffice window.It is however possible to create
Peter Toft
a.k.a. pto
Open Source på arbejde: En video-serie for unge (April 09, 2012, 14:09 UTC)
Over de næste to uger vil jeg gerne præsentere jer for en video-serie i min blog. Der kommer ni video-interviews med spændende personer der arbejder med Open Source i en eller anden form. Det har taget lang tid at lave og jeg har glædet mig meget til at præsentere det for jer :-)
Serien, som je... April 07, 2012
Jesper Nyerup
a.k.a. nyerup
Om forskellen på lov og kultur. Og flag. (April 07, 2012, 09:45 UTC)
Jeg er dansk. Det er jeg stolt af. Jeg holder meget af Dannebrog - jeg synes faktisk, mit land har Verdens smukkeste flag.
Derfor tilstår jeg også, at jeg var en lille smule forknyt, da jeg første gang læste om Radikales forslag til en liberalisering af flagloven. Jeg synes vi har en god, varmende flagkultur i Danmark, og Dannebrog er på én gang et meget subtilt, men samtidig også uhyre kraftfuldt, symbol på højtidelighed, festlighed og fælleskabsfølelse.
Men knap havde jeg nået at tænke den tanke til ende, før det gik op for mig, at det netop ikke er vores flaglov jeg er stolt af - men vores flagkultur. Og den er jeg ikke et sekund nervøs for, at vi sætter overstyr, bare fordi vi løsner loven omkring den.
Vi vil stadig flage for vort land på befrielsesdagen, for vores kære, når de bliver gift eller har fødselsdag, på halv stang når de går bort, for vores soldater og fodboldspillere når de gør os stolte ude i Verden, og for solen når den skinner. Alt sammen med Dannebrog.
Men selv om vi gør det, og det gør os stolte og bevidste om, at vi er danske, går der altså ingen skår af mig, hvis min amerikanske kollega får lov at hejse the Stars and Stripes til Thanksgiving eller den fjerde juli, hvis hele mit nabolag hejser Türk Bayragi for at fejre ramadanen eller valget til det tyrkiske parlament, eller endda hvis samtlige flagstænger i hele Danmark hejser den norske fane, når en forstyrret klovn begår massemord.
Det tror jeg sagtens Danmark kan rumme. Jeg tror ikke det vil få færre mennesker til at flage med Dannebrog -tværtimod. Jeg tror heller ikke det vil få færre mennesker til at føle sig danske. Til gengæld tror jeg det vil gøre det en lille smule nemmere for en masse mennesker, at vise, at de også elsker et andet land, udover Danmark.
Men fremfor alt tror jeg, det vil hjælpe Danmark og danskerne til at forstå, at der er langt mere stolthed i at bryste sig af sin kultur, end at gemme sig bag sine love.
April 05, 2012
Poul-Henning Kamp
a.k.a. phk
COMALs historie (April 05, 2012, 17:39 UTC)
Der var engang en fyr der hed Børge Christensen, han fandt på et programmeringssprog der hed COMAL og resten er historie.
"Engang" var så vidt vi kan gennemskue 1973 eller 1974 og historien vil vi rigtig gerne prøve at få styr på, inden "engang" er 40 år siden.
I 1985 udskiftede man faget "Data... April 03, 2012
Peter Toft
a.k.a. pto
Hvem bidrager mest til Linux-kernen? ... bla. Microsoft (April 03, 2012, 23:48 UTC)
Jeg tror mange af jer grinede med på min lille samling af Open Source-relaterede aprilsnar historier.
Men nu er det 4. april, og nu er det alvor igen - og det er værd lige at læse denne historie fra ZDNet, der kommenterer på Linux Foundations oversigt over Linux kernen.
Microsoft er for tiden i ... April 01, 2012
Peter Toft
a.k.a. pto
Det varmer mit Open Source hjerte at se disse tre historier i dag! (April 01, 2012, 20:19 UTC)
Microsoft opgiver kampen mod Open Source og går sammen med os :-)
http://www.muktware.com/c2050/3486/microsoft-joins-linux-foundation-dona...
En anden historie er at en Justin Bieber Linux-distribution er kommet. Endelig en måde at få fat i de unge på.
http://techlaze.com/2012/04/justin-bieber-l...
March 30, 2012
Poul-Henning Kamp
a.k.a. phk
Er der en mediawiki specialist tilstede ? (March 30, 2012, 07:23 UTC)
Jeg ved godt at det lyder lidt ironisk, men vi er ved at implementere en IT-strategi ude i datamuseum.dk
I mangel af et stort flot byggeprojekt, eller for nu at være ærlige: I mangel på den kvarte milliard kroner et sådant projekt koster, satser vi på at få gjort noget ved vores lidt antikke web... March 29, 2012
Poul-Henning Kamp
a.k.a. phk
Eric skyder med skarpt... (March 29, 2012, 08:39 UTC)
Livet er for kort til sendmail.cf og heldigvis kan min gode ven & lusepuster Eric Allman mere end det.
Han har lige skrevet et glimrende stykke i ACM Queue om "Technical Debt"
Teknisk gæld er lidt for hurtige og billige "løsninger" som man kommer til at bøde for senere, men der er mange nua... March 28, 2012
Poul-Henning Kamp
a.k.a. phk
Det er altsammen Kampmanns skyld (March 28, 2012, 07:42 UTC)
I gik glip af en pokkers interessant aften igår, Datamuseum.dk havde nogle af de helt centrale aktører til at fortælle om 50 års IT i staten.
Det er forundeligt hvor meget højere folk kan åbne munden når de er blevet pensionister og der kom nogle sandheder på banen som kunne have sparet danskern... March 27, 2012
Peter Makholm
a.k.a. brother
Bag om folketinget.dk (March 27, 2012, 18:13 UTC)
Jeg holder meget af websteder med fejl. Ofte giver det et helt andet indblik i den underliggende organisation end fejl i gammeldags programmer. I dag forsøgte jeg at skimme Folketingets liste af skriftlige §20 spørgsmål igennem. Pludselig bliver jeg præsenteret for dette vidunderlige SQL udtryk:
... March 26, 2012
Poul-Henning Kamp
a.k.a. phk
Dagens SW-grin fra Højesteret (March 26, 2012, 19:40 UTC)
Nogen gange er det svært ikke at grine af hvad vores Højesteret bliver nødt til at skrive i deres domme.
Dagens eksempel er:
Højesteret fastslog, at det var en væsentlig mangel, at de leasede softwarelicenser ikke eksisterede.
[...]
Højesteret ændrede med dommen landsrettens afgørelse.
Hvis ik...
March 25, 2012
Peter Toft
a.k.a. pto
Mød den danske mikro-computer Robocard (March 25, 2012, 09:28 UTC)
Jeg har været ude for at video-interviewe en masse spændende mennesker, der anvender Open Source software i hverdagen.
Det resulterer i en lang blog-serie som jeg regner med kommer online efter påske. Jeg mangler lidt, men det tegner godt.
Som en del af det projekt interviewede jeg Kjeld Jensen f...
March 21, 2012
Peter Toft
a.k.a. pto
Tør jeg logge på NemID? (March 21, 2012, 07:38 UTC)
En af mine gode venner skrev lige at jeg bør prøve at logge på NemID: https://www.nemid.nu/log_paa_selvbetjening/index.html
Dagens lille overraskelse er denne pop-up, der kommer frem
Jeg er ikke sikker på hvad der foregår her, og jeg er igen bekymret over om DanID har styr vores digitale indga...
March 19, 2012
Generalforsamling i foreningen af danske Ubuntubrugere (March 19, 2012, 22:15 UTC)
Søndag d. 15. april 2012 er der generalforsamling i foreningen af danske Ubuntubrugere.
Indkaldelsen kan læses herunder:
Kære alle
Hermed indkaldes til generalforsamling i Foreningen af danske Ubuntubrugere.
Generalforsamlingen bliver afholdt søndag d. 15. april 2012 kl. 16. Det kommer til at foregå i IRC kanalen #ubuntu-dk-moede på Freenode netværket.
Der vil være følgende dagsorden for generalforsamlingen
- Valg af dirigent
- Valg af referent
- Valg af stemmetællere
- Formandens beretning
- Regnskabsaflæggelse
- Behandling af indkomne forslag
- Godkendelse af budget
- Valg af bestyrelse
- Valg af formand
- Valg af kasser
- Valg af 3 bestyrelsesmedlemmer og 2 suppleanter
- Valg af revisor (ikke bestyrelsesmedlem)
- Valg af LoCo kontakt
- Eventuelt
Forslag der ønskes behandlet på generalforsamlingen skal være bestyrelsen i hænde senest 8 dage før generalforsamlingen, altså lørdag d. 7. april.
Opstilling til tillidsposter skal ske senest 7 dage før generalforsamlingen, altså søndag d. 8. april.
Jeg vil opfordre alle der kunne have lyst til at deltage i bestyrelsesarbejdet til at stille op, ligesom alle med interesse i foreningen og Ubuntu i Danmark opfordres til at møde op og deltage i
generalforsamlingen.
Vedtægter og kontaktinfo til bestyrelsen kan findes her:
http://ubuntudanmark.dk/forening/
Mvh.
Søren
Microsoft taber til open source hos kommuner (March 19, 2012, 12:57 UTC)
- Vores beregninger viste meget tydeligt, at OpenOffice / LibreOffice ville give en økonomisk fordel siger Michel van der Linden.
Vi har jo set det over en årrække, men tendensen bliver stadig tydeligere og tydeligere, at kommunerne stille og roligt bevæger sig mod mere open source.
Læs i Børsen: Det offentlige dropper dyre Word og Excel-programmer
Produkterne er nemlig modnet rigtigt meget, og samtidigt er det blevet lettere for kommuner at få hjælp og support til open source hos leverandører. Det betyder i den sidste ende, at kommunerne kan spare væsentlige beløb uden at tabe nævneværdig produktivitet, og det betyder til gengæld færre besparelser andre steder på budgettet.
Leder du efter en leverandør eller udvikler til et open source projekt, uanset om du er en større organisation eller kommune som skal bruge en seriøs og moden virksomhed, eller om du er en lille nystartet virksomhed, som bare skal bruge en enkelt udvikler eller to, vil jeg gerne give min anbefaling.
Kontakt mig her på siden, hvis du ønsker anbefaling af leverandører.