Kristoffer Qvists blogg om allt möjligt

Kategori: Guider

Blandade guider om hur man t.ex. sätter upp diverse IT-tjänster.

Inaktivera Bing-sökningar i Windows 10, version 2004

I Windows 10, version 2004, visas Bing-sökningar som standard då man söker. Detta trots att man under Inställningar > Sökning har inaktiverat det under tidigare versioner. Istället måste man nu göra ändringar i Registereditorn (regedit.exe).

Vi får börja med att gå till följande plats:

Dator\HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows

För min egen del var jag tvungen att skapa en ny nyckel här. Det gör man genom att högerklicka på “Windows”-nyckeln, och välja “Nytt > Nyckel”. Namnge nyckeln till Explorer.

I nyckeln behöver vi även lägga till ett DWORD. Namnge det till DisableSearchBoxSuggestions och sätt dess innehåll till 1.

Sammanfattningsvis, för att inaktivera Bing-sökningar

Vi behöver gå till nedan plats i Registereditorn:

Dator\HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Explorer

Skapa ett DWORD som namnges till DisableSearchBoxSuggestions. Sätt dess värde till 1. Klart!

Tack till How-To Geek för denna värdefulla information!

Problemet med Mastodon m.fl.

Detta är enbart baserat på mina upplevelser. Jag skriver inte bara om Mastodon, utan även GNU Social och Pump.io. Dessa är några exempel av de öppna källkodslösningar som finns, och som fungerar liknande. Programmen är alternativ mot exempelvis Twitter och Facebook. Den största skillnaden är att du själv kan köra det på din server. Och att registrerade användare från server A kan hämta information från Server B.

Idén är god bakom samtliga anser jag. Tanken är att man som användare inte ska behöva låsa in sig hos EN leverantör, såsom Facebook eller Google. Dessutom kan man läsa källkoden om man vill. Dessa saker är jag inte emot.

Kräver dock många beroenden

Vad jag däremot har problem med är programmens “beroendehelvete” som någon uttryckte på engelska. Jag har förståelse att man som utvecklare inte vill återuppfinna hjulet. Jag förstår att man därför använder bibliotek, eller verktygslådor, som gör utvecklingen snabbare. Dock så skadar det användarvänligheten ibland. Visst kan jag ta mig an informationen, och leta efter lösningar fel som kan uppstå om så behövs. Men jag uppskattar att kunna slippa det och ha programmet körklart på fem minuter. För det är det användarvänlighet betyder, i min mening. Guiden för att installera Mastodon är något lång, kanske inte användarvänlig och kan göras mer säker. Följer man den så är det inte garanterat att installationen går igenom, varpå man får felsöka. Ett tips från mig är att köra kommandot nedan.

journalctl -u mastodon-*

Det kommer förmodligen att visa de fel som finns. I annat fall kan man köra något av följande kommando nedan:

journalctl -u mastodon-web

Eller:

journalctl -u mastodon-sidekiq

Eller:

journalctl -u mastodon-mastodon-streaming

Du kan läsa mer på Mastodons sida. De visar om tjänsten körs, om de har stött på något fel med mera.

Glöm inte GDPR

Dataskyddsförordningen, eller GDPR, kom som en EU-lag i maj 2018. Lagen kom med många nyheter. Bland annat ger lagen registrerade större rättigheter samtidigt som personuppgiftshanterare krävs på större ansvar. Som personuppgiftshanterare kan man också råka ut för större skadestånd än före förordningen.

GDPR ersatte i Sverige den något tandlösa personuppgiftslagen, PUL. Ett axplock av nyheterna som GDPR införde är följande:

När vi tar Mastodon som exempel så kan vi inte kontrollera samtliga instanser som kan ta del av information. Dessutom kan man inte kontrollera vilka instanser som man inhämtar information ifrån. För att förenkla min förklaring så tänker jag exemplifiera:

Kalles och Pers server (exempel)

Kalle har en server som heter kalles-social.info. Per har en annan server som heter pers-social.io. På sin server har Kalle namnet @kalle@kalles-social.info. På Pers server heter Per @fotboll4life@pers-social.io. Kalle hittar Per på Pers server, och börjar prenumerera, eller “följa” Per. Kalles server kommer då att inhämta alla inlägg som Per har gjort på sin server, och presentera dem på Kalles server.

Data som Per nu gjort publik kommer att finnas på Kalles server. Beroende på vad Per har skrivit kan det ju vara alltifrån inte så personligt identifierbar information till mer av det stuket. Hur mycket beror ju helt på hur öppen Per har varit med sin data.

Att då skriva ett användaravtal och policy som håller för denna datahantering lär vara svårt.

Lärdomar för Mastodon-teamet

Användarvänlighet är vad Mastodon och övriga behöver lära sig från WordPress. WordPress är väldigt enkelt; du laddar ned en .zip-fil, extraherar innehållet och kör (något förenklat). Visst behöver man en MySQL-databas och webbserver med stöd för PHP. Därefter tar det kanske fem minuter innan man är uppe och kör.

Jag har provat att ladda ned Mastodon till en server för att testa och se hur det fungerade. Det har varit lite varierat resultat på de instanser som jag provade installationen på.

De första försöken var ett misslyckande. Förmodligen kunde det ha att göra med något lite RAM-minne på den instansen. Även om jag lade till utökat swap-minne så kunde jag inte ladda ned de beroenden som krävdes. Dock var det svårt att utläsa hur mycket som krävdes, eftersom det inte står dokumenterat vilka hårdvarukrav som Mastodon har.

Efter lite arbete och en ny instans så kunde jag snart få igång en egen Mastodon-server. Det var ett intressant mjukvaruprojekt att testa, men inte något för mig.

När ska man använda Drupal?

Ofta har man kanske läst om det, att Drupal lämpar sig väl till vissa projekt. Som verktyg är det väldigt anpassningsbart, och man behöver inte kunna koda även om det är fördelaktigt. Ibland kanske man bör undvika att använda Drupal medan andra gånger ska man köra på. Jag kommer gå igenom när Drupal passar just ditt projekt.

0. Ha en färdig kravspec

Förmodligen givet för de flesta, men tyvärr inte alla. För det första, innan man bestämmer sig att använda något verktyg, är det väldigt viktigt att ha en kravspecifikation. Drupal skulle jag gärna vilja likna vid ett ramverk, som man ”klipper och klistrar” ihop till en sajt. Utan en given kravspecifikation kan det nämligen bli väldigt svårt att komma igång och faktiskt grotta ned sig i sajtbygget.

1. Du bygger en sajt för många

Drupal skiner igenom när man skapar en sajt för flera användare med olika roller. Exempel på tillämpningsområden kan vara om man använder ett system för intra- och extranät. Då kan förstås integration med LDAP vara viktigt, och kanske Single Sign-On (SSO). Här kan jag nämna projekten LDAP samt Webserver Auth.  Används de senare rekommenderar jag att man använder Drupal 7, eftersom båda inte har fullt stöd ännu för Drupal 8.

Råkar du ha en webbredaktör kan du även behöva Linkit för att förenkla deras jobb.

2. Du behöver en anpassningsbar, modulär lösning

Ibland är man i behov av en lösning som fixas på 5 minuter, men som inte behöver anpassas mycket därefter. Drupal kräver drygt en halvdag för att lägga till och anpassa moduler som krävs i sajten.

3. Var inte rädd för att söka hjälp

Stöter man på patrull är det bra att känna till att Drupal har forum där man kan ställa frågor. Drupal har även en egen subdomän på Stackexchange. Mitt viktigaste verktyg är däremot en sökmotor. Vill man använda sig av en privat sökmotor kan jag tipsa om Startpage.com. Mig veterligen är det den enda som är granskad av tredje part att bejaka besökarnas sekretess.

Moduler för Drupal som (jag tycker) är viktiga

Moduler för Drupal är definitivt en viktig fråga. Men först en jämförelse av både WordPress och Drupal, bara för skojs skull. Kanske finns det någon läsare som undrar ”varför ska jag välja x över y”? Tanken med inlägget är att ge svar i den frågan.

Jag kanske har nämnt det tidigare, att jag gillar Drupal trots att det är något komplext. Jag gillar kommentaren som jag såg, förmodligen på en sida på Drupal.org, där olika webbpubliceringsverktyg jämfördes. Jag parafraserar kommentaren nedan, då jag inte kommer ihåg den exakt:

WordPress är som en smörkniv, medan Drupal är en Schweizisk armékniv.

Innebörden är ungefär den, att WordPress är byggd för att fungera för de flesta. Vill man specialisera sidan, så lär det genast bli svårare för den som äger sidan. Fördelen är dock att WordPress är väldigt enkelt att lära sig, eftersom sajtägare behöver kanske fem minuter innan man har en fullt fungerande (om än tom) webbsajt. Drupal å andra sidan gör inga antaganden av vilken typ av sida du vill ha. Istället ges du verktyg att anpassa sidan till mycket högre grad i jämförelse med WordPress.

Nackdelen med Drupal är dock den, att det kräver mer kunskap av webbsajtens innehavare. Olikt WordPress så tar det inte fem minuter att få en fullt fungerande sida. Lite skämtsamt skulle jag nog säga fem timmar, eftersom man ofta vill ha diverse moduler och kanske anpassa utseendet. Man märker också på communityt att det är rätt anpassat för programmerare, för man uppmanas att använda verktyg som webbprogramerare använder. Jag kan dock ta det i ett annat inlägg, eftersom jag nedan kommer presentera de viktigaste modulerna (enligt mig).

Viktiga moduler för Drupal

Modulerna som presenteras nedan har jag kategoriserat efter vad de gör, eller har för funktion. De hjälper sidans användbarhet. Alla moduler är i skrivande stund aktiva och aktuella för Drupal 8.

Utseende

Pathauto är en modul som skapar specialiserade URL:er automatiskt. Standardinställningen i Drupal genereral länkar som ser ut som www.example.com/node/123. Med Pathauto kan man istället skapa länkar med sidans rubrik, eller datum för skapande. Det finns förstås fler sätt, och dessa kan läsas i modulens konfiguration.

Pathauto kräver även modulerna Token och Chaos Tools (ctools).

Om man även vill modifiera administrativa gränssnittet är temat Adminimal. Till det bör man installera modulerna Admin Toolbar, som används av Adminimal Admin Toolbar.

Säkerhet

Drupal kommer inte med ett spamfilter, utan det får man lägga till i efterhand. Bland moduler som motverkar spam kan jag nämna Honeypot och Antibot. Deras approach skiljer sig åt något; Honeypot skapar ett gömt fält, som spambottar gärna fyller med data. Därav kan modulen bestämma vilka som är människor och vilka som är spambottar.

Antibot å andra sidan använder javascript för att filtrera bort spambottar. De flesta spambottar kör nämligen inte javascript och kan således inte registrera sig eller skriva kommentarer.

Inaktiva moduler som kanske behövs

Tänker man köra en blogg, eller nyhetssida, kan man eventuellt vara intresserad av att visa arkiv för månader och år. I skrivande stund har Drupal stöd för att visa arkiv, men denna funktion är inte påslagen som standard.

När modulen är aktiverad kanske man också vill lägga till ett ytterligare kriterium för blocket. Vanligtvis listar den nämligen vanliga sidor och inlägg skapta ett visst år och månad. Om man går till <drupals installationsmapp>/admin/structure/views/view/archive så får man lägga till Content: Innehållstyp (= Artikel) under ”Filterkriterier”.

Vidareutveckla sajt

För att verkligen bli ett ess med Drupal gäller det att lära sig. En resurs på nätet som jag stött på och är tacksam för är Webwash. Där kan man exempelvis lära sig att skapa en blogg med Drupal. Annars är förstås Drupals sajt också en nyttig resurs på webben. Om du vill lägga till ytterligare funktionalitet kan du antingen söka efter moduler för Drupal eller utveckla dem själv.

Kryptera loggfiler i Linux med GnuPG och logrotate

I mitt tidigare inlägg skrev jag angående GDPR och kryptering. För den som är intresserad, skriver jag nedan om att kryptera loggfiler i Linux-miljö. Inlägget är inspirerat av det som skrevs i ctrl.blog, eftersom skribenten inte gick djupare i det ämnet. Förhoppningsvis kan mitt inlägg ge lite bättre svar i ämnet.

1. Skapa ett nyckelpar, i en separat maskin

GnuPG är ett fritt program som implementerar OpenPGP-standarden enligt RFC4880 (även känt som PGP). För att öka säkerheten bör ett nyckelpar skapas i en separat maskin. Det minskar eventuella skador, om någon obehörig skulle ta över måldatorn som skall kryptera loggfilerna.

Nyckelpar kan skapas i Linux-, Windows- och Mac-datorer i olika program. Github har skrivit ett inlägg om hur man skapar ett nyckelpar med GPG.

2. Importera enbart den publika nyckeln

För att kryptera loggfilerna i servern måste gpg2 vara installerad i servern. Därefter måste den publika nyckeln importeras till loggservern. Nyckeln används för att kryptera filerna, och kan inte användas för att avkryptera dem. När nyckeln hos på den berörda användaren som exekverar logrotate, skall även nyckeln importeras med kommandot nedan (förutsatt att den publika nyckeln heter public.key):

gpg --import public.key

Det viktiga är också att nyckeln är betrodd. För att få nyckelidentiteter som man har på Linux-servern kör man nedan kommando.

gpg --list-keys --keyid-format LONG

Nyckeln som man importerat kan man också modifiera, om den inte känns igen som betrodd. Kör då nedan kommando (obs! Du bör vara helt säker på att detta är din importerade nyckel):

gpg --edit-key keyid

Därefter väljs förtroende för denna nyckel, som är viktig för att kunna kryptera loggfilerna framöver.

3. Modifiera konfigurationsfilen för att kryptera loggfiler

Lägg till nedan kod för de program som du önskar krypteras. Keyid är det användar-id som är lagrat med nyckeln (exempelvis namn@e-post.com). ”Shred” tar bort loggen i klartext efter att den krypteras och komprimeras. Loggen finns i maskinen enbart 24 timmar i klartext innan den komprimeras och krypteras:

daily
shred
compress
compresscmd /usr/bin/gpg2
compressoptions -r keyid --encrypt --default-key keyid --trust-model always
compressext .gpg

Observera! Ovan kod antar att nyckeln hela tiden är betrodd. Det betyder att ingen kontroll genomförs av nyckelns identitet.

Lägga till arkivsida i Grav

Eftersom detta är en blogg är det för mig naturligt att man har en så kallad ”arkivsida”. I denna kan man visa då samtliga inlägg skrivna en viss månad eller ett visst år. Det finns ett plugin till Grav som gör detta, men denna är inte automatiskt igång. Det finns förstås färdiga skelett som kommer med mycket färdiggjort, men väljer man däremot att skräddarsy sin sajt med enbart det man behöver bör man ha lite kunskap inom PHP, HTML och Twig.

Mitt inlägg är inspirerat av Bszymans inlägg, som behandlar just detta ämne. Även om pluginet har viss dokumentation på deras Github-sida, är den inte riktigt fullständig. Jag vill också lägga till vissa punkter som jag upplever att båda saknade.

Mål och förklaringar

Målet med detta är att skapa en arkivsida som kan användas i bloggen. Det andra målet är att bloggen skall kunna använda sig av en URL som är mer snarlik en svensk URL än en engelsk. Dock kan man välja att ha kvar de engelska kategorinamnen och ändra arkiv-urlen till engelska om man upplever att det skulle fungera bättre för sin blogg.

Jag använder mig av vissa ord och uttryck i nedan text, nedan finns dessa förklaringar:

  • grav-root Mapp/katalog där Grav är installerat
  • _temanamn Då alla teman heter olika, är det tänkt att detta skall vara samma tema du som läser använder

Välj tema som stödjer arkiv

För att minimera den tid som man behöver skräddarsy sin sajt, rekommenderar jag att man använder ett tema som stödjer arkiv-funktionen. Samtliga teman går att hitta på Gravs hemsida.

Installera och modifiera plugin

Själva pluginet kan installeras via kommandoraden, om man är under grav-root, skriver man bin/gpm install archives i kommandoraden. Pluginet kommer därefter att finnas under grav-root/user/plugins/archives. För att modifiera pluginet ändrar man i grav-root/user/plugins/archives/archives.yaml. Nedan visar jag ett exempel då man vill använda ”blogg” istället för ”blog” som kategori för blogginlägg:

enabled: true
built_in_css: true
date_display_format: 'F Y'
show_count: true
limit: 12
order:
    by: date
    dir: desc
filter_combinator: and
filters:
    category: blogg
taxonomy_names:
    month: archives_month
    year: archives_year

Nu kan man även kopiera arkivinnehållet från plugin till temat. Det gäller att man kopierar filen grav-root/user/plugins/archives/templates/partials/archives.html.twig till grav-root/user/themes/_temanamn/templates/partials/archives.html.twig

Om temat inte har stöd för arkiv, kan nedan kodrad behövas läggas till i grav-root/user/themes/_temanamn/templates/partials/sidebar.html.twig

{% if config.plugins.archives.enabled %}
  <div class="sidebar-content">
    <h6 class="sidebar--heading">Archives</h6>
    <hr class="hr--small">
    {% include 'partials/archives.html.twig' with {'base_url':base_url_relative} %}
  </div>
{% endif %}

Modifiera sidfältet

För att ändra arkivfältet i själva sidfältet, modifiera filen grav-root/user/templates/partials/archives.html.twig. Ändra nedan kodrad

{{ base_url }}/{{ config.plugins... }}

till följande:

{{ base_url }}/arkiv/{{ config.plugins... }}

Modifiera mall och själva arkivsidan

Nu gäller det att dels skapa mallen för arkiv och själva arkivsidan. Först skapas mallen. Skapa filen grav-root/user/themes/_temanamn/templates/arkiv.html.twig. I denna skrivs sidans utseende. Nedan finns ett exempel på hur detta kan se ut:

{% embed 'partials/base.html.twig' %}

    {% block content %}

        <h1>Arkiv</h1>

        <div class="infinite-scroll columns small-12 large-8">
        {% for post in page.collection({'items':{'@taxonomy':{"category": "blogg", "archives_month": uri.param("archives_month")}}}) %}
            {% include 'partials/post-item.html.twig' %}
        {% endfor %}

        {% if config.plugins.pagination.enabled and collection.params.pagination %}
            {% include 'partials/load-more.html.twig' %}
        {% endif %}

        </div>

        <div class="sidebar columns large-4 show-for-large">
            <div class="sidebar--inner">
                {% include 'partials/sidebar.html.twig' with {'blog':page} %}
            </div>
        </div>
    {% endblock %}

{% endembed %}

Mallen säger åt systemet att dels hämta sidans utseende, men också att hämta sidofältet. För att använda mallen i en sida måste denna sida nu skapas. Skapa mappen grav-root/user/pages/arkiv och filen grav-root/user/pages/arkiv/arkiv.md. Fyll i nedan innehåll i filen arkiv.md

---
content:
items:
    "@page.children": "/blogg"
---

Nu bör det finnas en fungerande arkivsida på sajten. Det finns förmodligen sätt att få den sidan ännu bättre, men sidan ser redan nu väldigt bra ut.

Lägg till stöd för logotyp i WordPress

Ibland kan man behöva modifiera WordPress efter ens egna behov, och då kan det handla om att ”gräva ned sig” i koden för att göra ändringarna. Ett exempel kan vara när man vill lägga till en logotyp till ett tema som inte redan stödjer detta. För min egna del krävde detta lite ”trial-and-error”, men till slut så fick jag kläm på det hela. Inlägget kommer att visa hur man gör det i en vanlig

För att exemplet nedan skall fungera krävs minst WordPress 4.5.

Till att börja med bör man modifiera filen functions.php, och detta kan man göra direkt i webbläsaren om man inte råkar ha en mer ”låst” installation, via redigeraren som man kan finna under fliken ”Utseende”. Därifrån väljs filen functions.php, i länken kan det stå Temafunktioner.

I funktionen function tema_setup() (där tema står för ditt aktiva tema) lägger du till följande kodsnutt:

add_theme_support( 'custom-logo', array(
	'height'      => 100,
	'width'       => 400,
	'flex-height' => true,
	'flex-width'  => true,
	'header-text' => array( 'site-title', 'site-description' ),
) );

Därefter läggs kodblocket nedan efter add_action( 'after_setup_theme', 'tema_setup' ); där tema återigen står för det aktiva temat.

function tema_the_custom_logo() {
	if ( function_exists( 'the_custom_logo' ) ) {
		the_custom_logo();
	}
}

Nu är vi nästan klara. Det som krävs nu är att lägga till funktionen tema_the_custom_logo(), eventuellt inom php-taggar, där vi vill ha loggan.

Om loggan behöver centreras, kan detta göras genom att lägga till följande kodblock i stilmallen style.css.

.custom-logo {
	display: block;
	margin-left: auto;
	margin-right: auto;
}

Förmodligen kommer min lösning inte att fungera som ”handen i hansken” för alla, men jag önskar att den vägleder dem som undrar hur man ska sätta upp en logotype till sin sida. Som jag själv skrev tidigare, så var det inte självklart för mig till en början. Men efter lite lekande med koden, så gick det vägen med att få sidan att visa loggan som jag ville.

Egentligen är ”best practice”, eller praxis, att skapa ett så kallat ”child theme”. I och med att syftet med detta inlägg enbart är att visa hur man kan gå tillväga, så ansåg jag att det inte behövdes i inlägget eftersom att det finns en risk för att inlägget blir mer komplicerat än vad det behöver vara.

Installera phpLDAPadmin på Raspberry Pi

Syftet med denna guide är inte en säker installation – snarare en fungerande sådan. För att säkra installationen krävs exempelvis att LDAPS eller StartTLS konfigureras för LDAP, samt att HTTPS konfigueras för NGINX.

Guiden kommer att gå igenom hur OpenLDAP installeras på en Raspberry Pi, som kör Raspbian. Den bör även vara användbar för operativsystem som kör Debian. Övrigt som installeras är en webbserver, samt en frontend som hanterar användarna i LDAP för enkelhetens skull.

Installera paket

Till att börja med, så installeras de viktigaste paketen. I och med att jag föredrar vim framför nano, så väljer jag att även lägga till det bland de andra paketen.

sudo apt-get install vim slapd ldap-utils php5-fpm php5-cli php5-ldap php-apc phpldapadmin nginx

Därefter kommer man att ombedas att ge ett lösenord för LDAP-administratören. Just denna gång behöver man inte ange ett lösenord som man ska komma ihåg, eftersom att lösenordet kommer bli omskrivet när paketen konfigureras.

Konfigurera paket

Nu måste paketen konigureras innan de kan användas.

OpenLDAP

Först konfigureras LDAP, eftersom att hela dess konfiguration inte gås igenom vid installationen. Kör kommandot:

sudo dpkg-reconfigure slapd

Nu måste du komma ihåg lösenordet för administratörskontot för LDAP.

Phpldapadmin

Därefter konfigurerar vi Phpldapadmin. Börja med att modifiera filen /etc/phpldapadmin/config.php så att de motsvarar domänens inställningar.

vim /etc/phpldapadmin/config.php

Leta där efter följande rader:

$servers->setValue('server','base',array(''));
# ...
$servers->setValue('login','bind_id','cn=admin,dc=example,dc=com');
# ...
$servers->setValue('login','bind_pass','secret');

Ändra raderna till det som gäller för din domän. Skulle din domän exempelvis vara qvi.st, så ändras raderna till följande:

Med ”binding” till administratörskontot

$servers->setValue('server','base',array('dc=qvi,dc=st'));
# ...
$servers->setValue('login','bind_id','cn=admin,dc=qvi,dc=st');
# ...
$servers->setValue('login','bind_pass','MittLösenord');

Det går även att använda s.k. Anonymous bind, lämna då både bind_id och bind_pass tomt, som visas nedan.

Utan ”bind”

$servers->setValue('server','base',array('dc=qvi,dc=st'));
# ...
$servers->setValue('login','bind_id','');
# ...
$servers->setValue('login','bind_pass','');

Nginx

Skapa en server-fil för phpLDAPadmin

sudo vim /etc/nginx/sites-available/phpldapadmin

Skriv in följande rader kod i filen:

server {
  listen 80;
  root /usr/share/phpldapadmin/htdocs;
  index index.php index.html;
  server_name _;

  location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }

  error_log /var/log/nginx/phpldapadmin_error.log;
  access_log /var/log/nginx/phpldapadmin_access.log;
}

Och skapa en symbolsik länk (soft link) av filen som skapades nyss:

sudo ln -s /etc/nginx/sites-available/phpldapadmin /etc/nginx/sites-enabled/phpldapadmin

Därefter avlänkas filen /etc/nginx/sites-enabled/default:

sudo unlink /etc/nginx/sites-enabled/default

Till slut startas webbservern om, och då bör du komma åt det grafiska gränssnittet för phpLDAPadmin.

sudo service nginx restart

Nu går det att även grafiskt konfigurera LDAP, peka då en webbläsare till IP-adressen av din LDAP-server.

© 2024 qvi.st

Tema av Anders NorenUpp ↑