Fedora-baserad privat server

(This article was originally published by Datormagazin. Republished with permission)

Fedora-baserad privat server

Det är ofta användbart att ha tillgång till en egen server för olika ändamål.

I följande artikel visar vi hur man kan sätta upp en server som är lämplig att tex dela filer mellan släkt och vänner, och många andra användningsområden.

bild:

  • firewall
  • apache httpd
  • ldap

... och exempel,

  • subsonic
  • mld
  • owncloud

Idag får man mycket hjälp av moderna linux-distributioner. Vi har valt Fedora, men principerna är desamma oberoende av distribution. Fedora ligger till grund för Red Hat Enterprise Linux som är en vanligt förekommande distribution bland större företag. Som en extra bonus lär vi oss alltså tekniker vi ofta kan återanvända inom arbetslivet.

Man har väldigt många frihetsgrader när man arbetar med en modern Linuxdistribution. Det gör det oöverskådligt att gå igenom alla tänkbara konfigurationsdetaljer. Vi har istället valt att hålla oss så nära distributionens grundinställningar som möjligt. På så sätt når vi relativt fort en användbar installation, som sedan kan modifieras för att bättre passa med dina specifika behov.

Installation av operativsystemet

Om du inte redan har en färdiginstallerad maskin kan man antingen installera en ny fysisk maskin, eller prova ut konceptet på en virtuell maskin. I artikeln använder vi Fedora 19 installerad på en virtuell maskin som skapades med virt-manager under värdoperativet, också det Fedora. VirtualBox är också ett bra alternativ, och fungerar utmärkt på till exempel Windows.

Vi använde iso:n för Fedora 19 netinst vilken är på ca 250 mb, resten hämtas från nätet. Under installeringen användes sedan fördefinierad inställningar för en webserver, vilket ger en bra grund av paket som inte tar mycket plats.

fett eller svält?

Det är vanligen bäst med snålt konfigurerade servrar, dvs man bör inte installera browsers och andra klientverktyg.

I detta fall har vi av valt att frångå denna tumregel. Det är för att det är lättare att testa konfigurationer med en exempelvis en lokalt installerad browser. Man kan välja att inte installera klientpaket och testa på annat sätt, eller att avinstallera klientpaket sedan.

Vill man testa med hjälp av Firefox:

1yum install firefox

För beroenden som typsnitt etc:

1yum groupinstall 'Xfce Desktop'

I vårt fall använde vi mestadels ssh för att konfigurera installationen från kommandoraden, och tunnlade sedan X via ssh för att starta firefox lokalt på servern och göra webbaserad konfiguration den vägen.

Ett annat alternativ är att portforwardera http-porten med ssh, för att på så sätt undvika att installera klientprogramvaror på servern. Nackdelen med den metoden är att det är oklart från början exakt vilka portar man behöver, och en del html kan fallera. Det fungerar dock i allmänhet bra om man är uppmärksam på de problem som kan uppstå.

Ett tredje alternativ är att ändra i httpd-konfigurationerna som ges som default i Fedora, så att tjänster blir tillgängliga utanför den lokala servern. Vi går igenom hur man gör detta för respektive tjänst.

Exempelurlarna i artikeln är angivna som http://localhost/service. Om du väljer att inte installera en lokal browser, får du byta ut localhost mot det ip nummer servern har.

Säkerhet

Om du väljer den fettrika vägen bör du inte släppa ut servern på internet utan vidare. Släpp inte heller igenom servern genom din brandvägg innan du är helt nöjd med konfigurationen.

I allmänhet ska man nog tänka både en eller två gånger innan man exponerar en server mot internet. Det är därför bra att ha en separat maskin, antingen virtuellt eller fysiskt, som man inte behöver vara så rädd om.

Apache Httpd

Hjärtat i systemet är Apache httpd, en trotjänare lika gammal som internet. Man kan invända att Apache httpd är tungrodd, och att nyare utmanare som Nginx är mera lämpade. Det kan vara sant om man förväntar sig last i stil med vad Wordpress eller Tumblr behöver hantera.

För vårt ändamål fungerar dock Apache httpd mer än väl. Dessutom är de paketkonfigurationer som medföljer Fedora oftast anpassade för Apache httpd, och vill man prova någon annan webserver så är det oftast inte problematiskt när man väl har klart för sig vad man vill åstadkomma.

I vårt fall har Apache httpd ett antal roller

  • tjäna som en samlad front-end till tjänster, en sk reverse proxy
  • SSL kryptera trafik
  • säkerställa att användare har önskad behörighet

Om du valde webserverprofilen under operativsystemsinstallationen har du redan detta paket, men det skadar inte att säkerställa att så är fallet:

1yum install httpd

Fedora använder systemctl, vilket inte är standard i alla distributioner. Här är några exempel för httpd.

Konfigurera httpd att starta vid boot:

1systemctl enable httpd

starta slutligen httpd:

1systemctl start httpd

Nu kan du du testa http://localhost Fedoras testsida skall nu visas.

När vi sedan installerar tjänster kommer de i allmänhet att exponeras som kontext under roten, exempelvis httpd://localhost/phpldapadmin/.

Vissa av tjänsterna, som phpldapadmin, är konfigurerade på det här sättet direkt efter installation. Detta gäller i allmänhet tjänster som exekverar i httpd, till exempel de som är baserade på php. Andra tjänster, exempelvis Subsonic, exekverar som separata demoner som man får tillverka proxy-konfigurationer för att de skall vara tillgängliga genom httpd.

Varför då inte istället exponera fler portar, en för varje demon? Det är en möjlighet men krånglar till det för dina användare.

Exempel på båda typer av tjänster kommer att visas.

389

389 är en LDAP server som vi använder för att lagra användare och lösenord. Namnet kommer sig av att LDAP protokollet använder sig av port 389. Ibland kallas den även för Red Hat Directory Server, men 389 är vad rpm paketen heter. 389 har en lång historik, och man ser ofta olika varianter av de tidigare namnen på produkten i dokumentationen, Slapd, Netscape Directory Server, SunOne Directory Server, RHEL Directory Server, och 389. Kärt barn har många namn!

Det är strängt taget inte nödvändigt med LDAP, eftersom de olika delsystemen vi beskriver oftast har någon form av inbyggd användarhantering. LDAP underlättar dock när man sätter samman ett antal olika system och vill ha en gemensamm användaridentitet i varje delsystem.

LDAP är ett brett ämne, och det finns böcker på området. Vi nöjer oss här med att konstatera att LDAP för våra ändamål är en typ av hierarkisk databas för användare, som många önskvärda tjänster kan integrera med.

Det är viktigt för många tjänster under Linux att ha ett sk. FQDN, Fully Qualified Domain Name satt. Detta gäller speciellt 389 servern. Sätt FQDN i filen /etc/hosts.

Installera paketen:

1yum install 389-ds-base
2yum install 389-admin

Kör sedan:

1/usr/sbin/setup-ds-admin.pl

Välj Express setup, och ange lösenord för administrativa konton.

När det hela är klart kan du testa http://localhost:9830/, under förutsättning att du har en lokalt installerad browser.

phpldapadmin

Nu när 389 är installerad installerar vi Phpldapadmin, som är ett trevligt administrativt webbaserat gränssnitt för LDAP-servrar.

phpldapadmin är som namnet antyder implementerad med php.

1yum install phpldapadmin

installerar phpldapadmin samt alla dess beroenden.

prova sedan:

http://localhost/phpldapadmin/

Logga in med den administrativa användaren du angav vid installationen av 389.

Skapa nu en användare för teständamål, under ou=People.

Vi skall sedan testa att det går att logga in på de olika tjänsterna med denna användare.

Owncloud

Nu när vi gjort grundjobbet, vill vi testa att installera någon intressant tjänst på vår nya server.

Owncloud, http://owncloud.org, är en typ av intranät för privatpersoner och företag. Owncloud kan hantera upp och nerladdning av filer, kalendrar medmera. Fedora har i skrivande stund inte den senaste versionen av Owncloud i sitt bibliotek, men den tillgängliga versionen är ändå tillräckligt bra för våra ändamål. Versionsskillnaden visar också på ett vanligt problem för distributioner. Fedora har ett direktiv för paketering som kräver att beroenden skall brytas ut och levereras som separata paket. Det är i allmänhet bra för det leder till mindre redundans inom distributionen, men ibland leder det till svårigheter för paketerarna som gör att de ligger efter versionsmässigt. Man kan installera Owncloud direkt från källkod eller från alternativa bibliotek, men vi väljer inte den metoden eftersom vi önskar hålla det hela så enkelt som möjligt.

Vi installerar med yum:

1yum install owncloud

Surfa nu till: http://localhost/owncloud

ange ett namn på ett administrativt konto och ett lösenord.

Det finns mycket att utforska här, men vi väljer att konfigurera LDAP autentifiering. Gå till "Apps" och slå på "LDAP" applikationen. Nu tillkommer LDAP inställningar under Admin-fliken.

Host: localhost Base DN: dc=localdomain uid=%uid

Det kan vara besvärligt att få till rätt inställningar. Som tur är finns en möjlighet att prova att det fungerar, med funktionen "Test Configuration". Spara och logga ut det administrativa kontot. Nu skall du kunna logga in som den LDAP användare du skapade tidigare.

Nu har vi alltså ett system som börjar bli användbart:

  • Vi kan skapa användare i phpldapadmin
  • vi kan konfigurera en exempeltjänst, Owncloud, så den integrerar med LDAP

Vi går vidare med fler tjänster.

Subsonic

Subsonic är en trevlig server för att strömma musikfiler till din telefon eller laptop. Den blir ett bra komplement till vår server.

Subsonic har dock ett antal tekniska egenheter som den delar med en del andra tjänster. Det gör Subsonic till ett bra exempel på hur man löser problem. En annan egenhet är att trots att Subsonic är fri programvara under GPLV3, så finns det en nedräknare för en prövoperiod i gränssnittet. Om du gillar Subsonic kan du antingen betala en liten summa för att få en nyckel, eller helt enkelt kompilera om Subsonic utan nyckelkontrollen. Detta är helt legitimt, men en smula udda för att vara en GPL-licensierad produkt. Ordet "Fri" i fri programvara betyder inte alltid kostnadsfri.

Subsonic finns inte tillgänglig i Fedoras bibliotek, så vi måste ladda ner ett rpm paket:

http://www.subsonic.org/pages/download.jsp

Du kan antingen använda en lokal browser på servern, eller med en kommandoradsbaserad nedladdare som wget.

installera sedan paketet med yum, för att även installera eventuella beroenden.

yum install subsonic-4.8.rpm yum install jre systemctl enable subsonic.service

Desvärre fanns i skrivande stund en bug i subsonics init fil tillsammans med systemctl. För att komma runt detta kommentera följande rad i /etc/init.d/subsonic:

1#. /etc/init.d/functions

Subsonic konfigurerar med filen /etc/sysconfig/subsonic, där vi vill sätta kontextroten, så vi sedan enklare kan exponera Subsonic på samma port som andra tjänster utan att de krockar:

1SUBSONIC_ARGS="--max-memory=150  --context-path=/subsonic"

Du bör även ändra användaren SUBSONIC_USER från root till någon annan användare.

Surfa nu till http://localhost:4040/subsonic och slutför installationen genom att ange ett administrativt konto.

Ange följande LDAP inställningar:

1(uid={0})
2ldap://localhost:389/ou=People,dc=localdomain

och ange även "Automatically create users in Subsonic".

Om du nu loggar ut ditt administrativa konto skall du sedan kunna logga in med en LDAP användare.

Lägg in några musikfiler och testa!

Nu skall vi proxa subsonic, med en ny fil, /etc/httpd/conf.d/subsonic.conf.

 1ProxyPass /subsonic  http://localhost:4040/subsonic
 2ProxyPassReverse /subsonic http://localhost:4040/subsonic
 3ProxyRequests     Off
 4ProxyPreserveHost On
 5RewriteEngine on
 6RewriteRule ^/subsonic(.*) https://SERVER/subsonic$1
 7<Proxy http://localhost:4040/subsonic*>
 8  Order deny,allow
 9  Allow from all
10</Proxy>

Byt ut SERVER mot det aktuella servernamnet. Det måste vara ett namn som dina klienter kan DNS resolvera mot servern. Observera även att https används när vi når subsonic genom httpd.

SSL och DNS

Man måste inte ssl-kryptera sin webtrafik, men det försvårar en del enklare attacker, som sniffning av lösenord i klartext.

Fedora skapar automatiskt självsignerade certifikat. Dessa fungerar men ger upphov till extra dialogrutor i webläsare, som inverkar menligt på användbarheten av din server.

Man kan skapa egna skarpa certifikat relativt enkelt hos Startcom, http://www.startcom.org/. För att kunna utnyttja denna tjänst måste vi först ha registrerat ett servernamn i DNS, eftersom ssl-certifikat utställs för specifika DNS namn.

Om du använder någon tjänst för dynamisk dns, kan du använda paketet ez-ipupdate för att uppdatera din servers ip-address.

Autentisering

Tanken är att vi skall exponera våra tjänster via https, med autentisering mot LDAP, när vi går genom internet. På vårt lokala lan kan vi använda http eller https omväxlande.

Installera httpd:s LDAP modul:

1yum install mod_ldap

i ssl.conf:

1<Location />
2Deny from all
3  AuthType Basic
4  AuthName "DMZserver"
5   AuthBasicProvider ldap
6   AuthLDAPURL              "ldap://localhost:389/ou=People,dc=localdomain"
7   Satisfy Any
8   Require valid-user
9</Location>

Starta om httpd och prova tex:

https://localhost/owncloud

Det vi vann nu var att trafiken blir SSL krypterad och att autentisering krävs.

Brandvägg

De flesta har antagligen en router uppkopplad mot internet. Om vi önskar kunna komma åt vår server från internet måste vi alltså portforwardera från brandväggen till vår interna server. De flesta brandväggar tillåter detta i sina webgränsnitt.

I detta fall önskar vi portfarwardera https porten, 443, från internet till vår nya server.

Detta kan dock gärna vänta tills servern är färdigkonfigurerad.

Förutom brandväggen i routern har även Fedora en inbyggd brandvägg. Den är baserad på iptables, med en frontend som heter firewalld.

När vi aktiverar en tjänst måste vi även släppa igenom tjänsteporten, exempelvis för http och https:

1firewall-cmd --add-service=http
2firewall-cmd --add-service=https

Förbättringar

Vi har egentligen bara skrapat på ytan av vad man kan göra. Framför allt vill man antagligen ha fler tjänster. Det finns en uppsjö att välja mellan, och någon av metoderna i denna artikel bör i allmänhet kunna användas när du konfigurerar tjänsten.

Här är några förslag på fler intressanta tjänster:

  • Mldonkey är en serverbaserad nedladdningsklient som stödjer bland annat bittorrent och har ett fleranvändarsystem.

  • Roundcubemail är en kompetent webmailklient som stödjer IMAP. Man kan antingen koppla upp den mot en befintlig IMAP server, eller en egen som till exempel Dovecot.

Vi önskar nu lycka till med att utforska din server!