Sedan en tid tillbaka har det varit kraftig stiltje gällande uppdateringar på osource.se. Detta beror helt enkelt på att jobb och familj just nu upptar all den tid som finns just nu.

Vi kommer längre fram att försöka få ut mer artiklar och öka vår närvaro igen.

Vi har flyttat oSource.se till en ny server baserad på Lighttpd.

Allting skall flyta på som vanligt men skulle något vara kaputt så får ni jättegärna ta kontakt med oss omgående så att vi kan fixa till det.

Ny guide gällande webbtrafikshantering med Pound & openSUSE har anlänt.

Läs den här: Till Guide

Innehåll

• Förord
• Installation
• Konfiguration
• Resurser
• Slutord

Förord

Pound är en omvänd proxy, lastbalanserare & HTTPS Front för webbservrar. Pound utvecklades för att möjliggöra lastbalansering mellan flera webbservrar och för att tillåta en lämplig SSL-wrapper för webbservrar som inte stödjer SSL som standard.

Upp

Installation

Denna guide förutsätter att en färdig installation av openSUSE finns, det finns en guide att läsa här för hur man installerar openSUSE. Givetvis så går det att ta större delen av denna guide och applicera på andra Linux distributioner.

Nu skall vi installera Pound.

• Börja med att gå in i adminläge genom att skriva följande i konsolen.
  $ sudo -i
• Skriv sedan följande för att ladda ner och installera Pound.
  # yast install pound

För att lägga till pound i startup kör följande kommando.
# yast runlevel add service=pound

När installationen är klar är det dags att gå vidare till konfigurationen.

Upp

Konfiguration

Dags att sätta upp Pound för att hantera pekningar till våra webbservrar.

Som exempel så kommer vi att ha tre stycken servrar som levererar webbinnehåll, två av dessa skall lastbalanseras med varandra.

Vår miljö:

ps (192.168.0.2) – Vår Pound server.
web1 (192.168.0.5) – Webbserver som skall lastbalanseras.
web2 (192.168.0.6)- Webbserver som skall lastbalanseras.
mail (192.168.0.10) – E-Post server med webbgränssnitt.
www.example.se – Den adress som skall lastbalanseras.
mail.example.se – Mejlserverns webbgränssnitt nås ifrån denna adress.

• Öppna upp /etc/pound.cfg.
  # nano /etc/pound.cfg
• Ta bort allt utom följande rader.
  # Start pound as User with Group
  User  ”pound”
  Group ”pound”
• Nu skall vi skapa en lyssnare(listener) som är den som kommer att hantera trafiken till och från våra servrar. Lyssnaren kommer att lyssna på 192.168.0.2 och på port 80. Fyll på med följande information i /etc/pound.cfg.
  ListenHTTP
  Address 192.168.0.2
  Port 80
  End
• Nu skall vi lägga till våra servrar i konfigurationsfilen. Vi börjar med webb servrarna som skall lastbalanseras. Detta måste läggas in före End raden i lyssnaren.
  UrlGroup ”.*www.example.se.*”
  BackEnd 192.168.0.5,80,1
  BackEnd 192.168.0.6,80,2
  Session COOKIE auth 360
  EndGroup

Det vi har gjort här är att skapa en URL grupp där båda webb servrarna ingår med olika prioritetsordning, här med 1 & 2. Prioritetsordningen anges mellan 1-9 där 1 är lägst och 9 högst, dvs. i vårt fall så kommer servern med prioritetsordning 2 att få dubbelt så många anrop som servern med prioritetsordning 1.

UrlGroup: Det namn som skall lastbalanseras, hämtas ifrån det anrop som görs emot Pound servern. .* är ett så kallat reguljärt utryck som används vid strängsökning och måste finnas med.

BackEnd: Den/de servrar(192.168.0.x) som skall finnas med i lastbalanseringen, en server per BackEnd rad. Här anges även vilken port(80) samt vilken prioritetsordning(1,2) servern skall ha.

Session: Anger vilken typ av session som skall användas av Pound för att bibehålla anslutningsdata mellan specifika lastbalanserade servrar och klienten. Det finns IP, BASIC, URL, COOKIE, PARM & HEADER.

Då HTTP protokollet i sig är ett så kallat Anslutningslöst(Stateless) protokoll så innebär detta att när man gjort en förfrågan emot en server så har man ej längre kontakt med den och nästa gång man gör en ny förfrågan så skapas en ny anslutning med servern, detta är inget problem när man endast har en server som svarar på anrop, dock så blir detta ett problem när man kör med lastbalansering. Vid lastbalansering så vet man inte vilken server som svarar på det aktuella anropet och har man initierat en session emot den ena servern så kommer den sessionen mest troligt att avbrytas vid ett nytt anrop, beroende på vilken server som svarar. Detta går att komma runt med Session variabeln som vi angivit ovan, där har vi angivit att sessionstypen skall vara COOKIE som heter auth och att den skall vara giltig i 3600 sekunder, dvs 1h. Under denna timmen så kommer alla anrop ifrån en dator att hamna emot samma server.

• Dags att lägga in mejlservern i /etc/pound.cfg också. Detta måste också läggas in före End raden i lyssnaren.
  Service
  HeadRequire ”Host: .*mail.example.se.*”
  BackEnd
  Address 192.168.0.10
  Port 80
  End
  End

Det vi gjort här är att skapa en service för mail.example.se där vi säger att när en klient begär denna adress så går Pound in och hämtar data för detta på adressen 192.168.0.10 via port 80 och skickar sedan detta tillbaka till klienten.

Upp

Resurser

Vidare läsning om Pound kan göras på tillverkarens hemsida samt genom att läsa manualen för Pound.

Hemsida: www.apsis.ch

manualen når man även genom att skriva följande i konsolen:

# man pound

Upp

Slutord

Pound är ett bra sätt att hantera/distribuera webbinnehåll via ett minimalt antal externa IP-Adresser, vilka man kanske vill hushålla med eller rent av så har man endast en att tillgå vilket gör det svårt att kunna hantera flera webbresurser utåt på ett vettigt sätt.

Upp

Nu har vi äntligen publicerat vår första artikel.

Ni kan läsa mer om den här: Vad är öppen källkod?

Innehåll

• Förord
• Källkod
• Koncept
• Licenstyper
• Slutord

Förord

Grunderna för öppen källkod är att den är just öppen och fri att använda. Men hur öppen och fri den är beror på vilken licens som det är kopplat till. En vanlig företeelse är att man kopplar ihop öppen med fri, dessa går oftast hand i hand, men inte alltid. en programvara kan vara fri att använda med själva källkoden till den är stängd. Detta skall vi försöka att förklara här och även förklara vad källkod är. Vi kommer även att i korthet visa vilka dom vanligaste licenserna är, innebörden av dessa samt lite historia runt dom.

Upp

källkod

Källkod är grundstenarna i alla program och är i dess form rena textfiler som är både läsbara och möjliga att förändra. När källkoden väl är omgjord till ett körbart program så försvinner möjligheten att modifiera programmet för någon annan än den som innehar källkoden.

Källkod kan jämnföras med t.ex.

• Delar till en bil
• Ingredienser till en maträtt

Utan dessa grundstenar så blir det varken en bil eller en färdig maträtt, samma gäller för program. För en icke insatt kan informationen i dessa filer vara rena gallimatias och det enda man bryr sig om är att det fungerar i slutändan, likaså att bilen fungerar eller att maträtten kan tillagas. För andra så kan detta vara ytterst viktigt att kunna se hur ett program är uppbyggt, dels för ett egenintresse men även ur ett samhällsperspektiv där man strävar efter en öppenhet där vem som helst kan kvalitetssäkra/förbättra koden ifall behovet skulle uppkomma.

Upp

Koncept

Dom grundläggande byggstenarna för licenser runt öppen källkod är följande kriterier, dessa är inhämtade ifrån OSI som är ett initiativ runt just öppen källkod och beskriver vad som får klassas som just öppen källkod.

• Fri vidaredistribution.
  Licensen får ej begränsa någon part från att sälja eller vidaredistribuera mjukvaran som en del av en sammansatt mjukvarudistribution med mjukvaror från flera skilda källor. Licensen skall inte kräva ersättning eller andra avgifter för sådan typ av försäljning.
• Källkoden.
  Mjukvaran måste inkludera källkoden och måste tillåta distribution av mjukvaran som källkod samt i kompilerat format. När någon form av produkt inte distribueras med sin källkod måste det finnas ett väl dokumenterat sätt om hur det går att få tag på källkoden till en resonabel reproduktionskostnad, fördelaktigt genom nerladdning via internet, kostnadsfritt. Källkoden måste vara det föredragna formatet för en programmerare att göra modifieringar i mjukvaran. Att medvetet komplicera, fördunkla källkoden är inte tillåtet. mellanliggande former såsom utdata ifrån en hjälpprocessor eller via förbehandling är inte tillåtet.
• Härledda verk
  Licensen måste tillåta modifieringar av härledda verk och måste tillåta att de för distribueras under samma termer som licensen för grundmjukvaran.
• Integritet hos författarens källkod
  Licensen får begränsa källkoden från att distribueras i modifierad form endast om licensen tillåter distribution av ”patch-filer” tillsammans med källkoden för att modifiera programvaran vid kompilering. Licensen måste explicit tillåta distribution av programvara som kompilerats från modifierad källkod. Licensen får kräva att härledda verk ges ett annat namn eller versionsnummer än den ursprungliga programvaran.
• Ingen diskriminering gentemot personer eller grupper
  Licensen får inte diskriminera någon person eller grupp av personer.
• Ingen diskriminering av användningsområden
  Licensen får inte begränsa någon att använda programmet inom ett särskilt område. Exempelvis får den inte begränsa att programmet inte kan användas i ett företag, eller användas för genetisk forskning.
• Distribution av licens
  De rättigheter som tillskrivits programvaran måste vara tillämpliga på alla till vilka programmet sprids, utan att det behövs någon ytterligare licens för dessa parter.
• Licensen får inte vara specifik för en produkt
  De rättigheter som tillskrivits programvaran får inte vara beroende av att programmet är en del av en viss distribution av programvara. Om programmet extraheras från distributionen och används eller distribueras enligt villkoren i programmets licens, alla parter till vilka programmet sprids ha samma rättigheter som de som ges i kombination med den ursprungliga programdistribution.
• Licensen får inte begränsa annan programvara
  Licensen får inte införa restriktioner på annan programvara som distribueras tillsammans med den licensierade programvaran. Exempelvis får inte licensen kräva att all annan programvara som sprids på samma medium måste vara öppen källkod.
• Licensen måste vara teknikneutral
  Ingen bestämmelse i licensen får begränsa till enskild teknik eller stil av gränssnitt.

Bryter man mot dessa grunddirektiv så får inte programmet/källkoden benämnas som öppen eller fri.

Upp

Licenstyper

När det gäller licenser för program, öppen källkod o.s.v. så finns det en hel uppsjö med licenser och varje licens tolkar saker på sitt sätt, vilket kan göra det svårt att få något helhetsgrepp om vad licensen egentligen tillåter eller inte tillåter.

• GPLv3 (Gnu Public License Version 3)

Den mest använda och debatterade licensen för öppen källkod. Denna licens är ytterst restriktiv i hur mjukvara baserad på just denna licens får användas, därför är det ytterst viktigt att läsa igenom den både 3 eller 4 gånger innan man använder denna licens, speciellt när man utvecklar mjukvara.
Ref: OSI GPL Information

• LGPLv3 (Lesser Gnu Public License Version 3)

Är en uppmjukning av själva GPLv3 licensen. Denna licens uppkom då vissa ansåg att huvudlicensen GPL var för hårt styrd då den inte tillåter att mjukvara som är baserad på GPL att användas som en del av en proprietär mjukvara.
Ref: OSI LGPL Information

• BSDL (BSD License)

Berkeley Software Distribution (BSD, som ibland kallas Berkeley Unix) är ett Unix-operativsystem derivat som utvecklades och distribuerades av Computer Systems Research Group (CSRG) vid University of California, Berkeley, 1977 till 1995. Denna licens är rätt enkel att förstå då den är väldigt rättfram i vad den tillåter eller inte tillåter.
Ref: OSI BSDL Information

Dessa är de mest använda men det finns fler licenser som du kan hitta mer information om hos OSI.

Upp

Slutord

Syftet med denna artikel är att visa det mest grundläggande om vad öppen källkod är och några exempel på licenser som finns runtom. Det finn alltid olika aspekter på hur man ser på öppen källkod, det finns även lite politik över det hela, men det är alltid viktigt att se öppen källkod ur ett opolitiskt perspektiv, dvs. ur ett användarperspektiv där man sätter användaren i första rum och ger dem möjligheten att utvecklas och förändras på sina egna villkor.

Upp

Vi här på oSource.se anser det viktigt att försöka påverka och förändra saker som missgynnar den öppna källkodsvärlden.

I det här fallet gäller det nVidia och deras ovilja att öppna upp deras drivrutiner så att fler får insyn och kan hjälpa till att förbättra drivrutinerna så att stabiliteten & funktionaliteten i Linux/Unix system kan bli bättre.

Då man i dagsläget kör med stängd källkod och inte har en bra kontaktyta gentemot utvecklarna gällande problem som finns och eventuellt uppkommer i nya versioner av drivrutinerna utan hänvisar istället till ett forum där i princip inga utvecklare eller tekniker ifrån nVidia går in och kollar och svarar på frågor. Skulle det mot förmodan ske att någon ifrån nVidia svarar så är det ofta med negativ ton gentemot frågeställaren.

Detta är oacceptabelt på alla sätt och vis då nVidia är en av dom ledande tillverkarna av grafikkort till datorer och att inte ge folk rätten till att kunna välja själv vad man vill köra på sin dator, speciellt när det gäller bärbara där man inte kan välja grafikkort hursomhelst.

Ni kan se och skriva under denna namnlista på följande adress: [Extern Länk]

Nu har vi strukturerat upp så att ni kan prenumerara på 2 olika RSS flöde, ett för nyheter och ett för guider. Vi har även satt upp ett twitter konto där ni kan följa oss när vi twittrar lite.

Nu har version 11.2 av openSUSE släppts och många av nyheterna är bl.a.

• bättre hårdvarustöd.
• Stöd för nya EXT4 filsystemet.
• Möjlighet att kryptera hela hårdisken ifall man har behov av det.
• Flertalen grafiska förbättringar.

Läs mer här: openSUSE 11.2 Release

Nu har vi publicerat vår första guide.

• Server Med openSUSE

Kolla gärna in den och återkom med synpunkter, ris som ros. Kom gärna in med förslag på guider och annat som ni känner att dom borde finnas här.