WordPress installeren op een Synology NAS

Aangezien mijn blog verhuist is van wordpress.com naar de huidige locatie (eigen domein, eigen ‘server’) en dit toch wat uitzoekwerk was, hierbij een klein overzicht hoe je WordPress werkend kan krijgen op je Synology NAS. DSM (het OS van Synology) ligt in mijn geval op versie 3.1.

De voorbereidingen

En zorg er daarnaast natuurlijk voor dat je een domeinnaam hebt en deze verwijst naar je eigen ip-adres. Tevens kan ik hier niet behandelen hoe je je router instelt, zodat verkeer op poort 80 wordt gerouteerd naar je Synology NAS. Ik ga er vanuit dat je dit al geregeld hebt.

Activeren van de MySQL database en Webservices

Ga naar het Control Panel van je Synology. Kies daar vervolgens voor ‘Web Services’. Kies hier voor ‘Enable WebStation’ en ‘Enable MySQL’

Kies hierna voor Virtual Host. Voeg hier een nieuwe virtual host toe. Daartoe kies je voor Create. Vul een sub-folder in, waar je WordPress straks gaat installeren binnen de webfolder. Vul vervolgens de domeinnaam in van je blog. Protocol en poort staan waarschijnlijk al goed ingevuld. De synology maakt nu in de gesharede map “Web” een extra subfolder aan waar je straks WordPress in kunt installeren.

Installatie PHP Admin en aanmaken van WordPress database

Log in op je Synology. Open het Synology startmenu via de pijl links bovenin en kies daar voor Package Management.

Binnen Package management kies je voor Install en selecteer je de gedownloade package van PHP Admin. Na installeren kies je voor Run. PHP Admin wordt nu gestart.

Klik op de URL van PHP Admin. Je browser opent nu een nieuw scherm en vraagt om een gebruikersnaam en wachtwoord. De eerste keer dat PHP admin start is de gebruikersnaam Root. Het wachtwoord kun je leeg maken. Nu inloggen moet je het wachtwoord aanpassen, zodat iemand die per ongeluk op PHP Admin terecht komt, hier niet in kan loggen. Na het wijzigen van het wachtwoord ga je naar het tabblad rechten (1), bovenin het scherm. Kies hier voor het toevoegen van een nieuwe gebruiker (2)

Maak de gebruiker als volgt aan (3):

  • Gebruikersnaam: Kies een willekeurige gebruikersnaam waarmee WordPress straks verbinding maakt met je database
  • Machine: Kies voor Lokaal – Localhost
  • Wachwoord: Kies het wachtwoord voor het account
  • Database voor gebruiker: Maak een database met dezelfde naam en geef alle rechten hierop

Kies daarna beneden in het scherm voor ‘Start’. De database en de gebruiker worden nu aangemaakt.

WordPress installeren

Maak nu met Windows Verkenner een verbinding met de synology door naar de naam of het ipadres te browsen ( \\ditismijnservernaam ). Hierin zie je nu meerdere shares. Kies de ‘Web’ share. Daarin staat een subdirectory die je via virtual hosts hebt aangemaakt voor WordPress.

Pak het gedownloade installatiebestand van WordPress uit naar deze subdirectory. Let er hierbij op dat je niet de ‘wordpress’ directory uit de zipfile meeneemt. De bestanden van WordPress moeten dus direct in de root van jou subdirectory terecht komen.

Maak nu met je SSH client een verbinding met je Synology. Log in als ‘root’ en gebruik het wachtwoord wat je ook voor je admin account op de GUI van de Synology gebruikt. Controleer de locatie van je WordPress bestanden, dit zou /volume1/web/subdir moeten zijn. We gaan nu op deze subdirectory rechten zetten voor nobody. Dat is het standaard account waarmee apache draait. Door deze rechten te zetten kan apache de bestanden van WordPress aanpassen tijdens de installatie.

Type hiervoor: chown -R nobody:nobody /volume1/web/subdir (geef ownership aan nobody voor alle bestanden)

Na het uitpakken maak je verbinding met de hoofdsite van WordPress ( http://DomeinnaamVanVirtualHost/wp-admin/install.php ) en volg je de wizard. Let hierbij op de volgende zaken:

  • Als eerste wordt gevraagd verbinding te maken met de database. Gebruik de gegevens van de user die je hebt aangemaakt. De database naam is dezelfde als de usernaam binnen MySQL.
  • Gebruik geen wp_ als prefix van de database tabellen. Verander deze, aangezien het een security risk kan zijn om de default waarden aan te houden

  • Gebruik niet ‘admin’ als hoofdaccount van je WordPress. Ook dit is een default waarde en vormt een security issue.

Na installatie zetten we de rechten voor Apache op de WordPress folder wat strakker. We willen immers niet dat vreemden te veel toegang kunnen krijgen. Volgens best practises doe je het volgende:

Maak verbinding via je SSH client en log in als root. Voer hierna in:

  • chmod –R 755 /volume1/web/subdir (beperk rechten op de WordPress directory)
  • chmod 644 /volume1/web/subdir/.htaccess
  • chmod 644 /volume1/web/subdir/wp-admin/index.php

Extra’s voor WordPress installatie

Unzip: Mocht je IPKG geïnstalleerd hebben, installeer dan ‘unzip’ zodat WordPress automatisch plugins voor je kan installeren. Dit is nodig omdat de meeste plugins gezipped zijn, en WordPress deze module nodig heeft om deze te kunnen unzippen. Type hiertoe ‘ipkg install unzip’ in een SSH sessie (login als root)

Mod_expires: Voor WordPress Super Cache is mod_expires nodig. Dit staat standaard geïnstalleerd op de Synology, maar is niet geactiveerd. Dit kun je activeren door het volgende bestand aan te passen: /usr/syno/apache/conf/httpd.conf-user . Voeg daarin de volgende tekst onderin toe:

LoadModule expires_module module/mod_expires.so
<IfModule mod_expires.c>
ExpiresActive on
</IfModule>

Geef daarna het commando: /usr/syno/etc/rc.d/S97apache-user.sh restart . Apache zal nu automatisch de module activeren die WP Super Cache nodig heeft.

Installatie van multi language packs via commandline in Windows 2008 R2/Windows 7

Na installatie van het OS, wat wij als IT-ers natuurlijk in het engels installeren, kan het voor komen dat je nog een extra taal wilt toevoegen. Nou kan dat via de GUI, maar dat wil je niet altijd. Het liefst zou je zien dat je deze via RES Automation Manager of een andere uitroltool geïnstalleerd kan krijgen.

Op de languagepack cd’s van Windows 2008 en Windows 7 vind je meerdere directories. Kies de directory met de taal die je wil installeren en neem hier de lp.cab uit. Deze kun je via de commandline installeren via lpksetup /i * /p [patch of/en bestandsnaam van de languagepack] /r /s

De switches achter lpksetup.exe dienen de volgende doelen:

/i Installeer een taal
/i *

/i [taalkeuze]

Installeer alle talen in het languagepack. Mocht je een languagepack hebben met meerdere talen dan kun je hier één selectie uit maken door bv. nl-NL te gebruiken ipv ster.
/p [path naar languagepack directory]

/p [path+bestandnaam van languagepack]

Path naar een directory met alle languagepacks die je wil installeren. Wil je maar één bepaalde languagepack installeren, dan moet je ook de bestandsnaam erbij plaatsen
/r Geen reboot op het einde van de installatie
/s Stille installatie

Let er bij het gebruik van een languagepack op, dat je versie van Windows wel meerdere talen ondersteund. Installeer je een languagepack op een Windows versie die geen multi-language ondersteund, dan wordt de hoofdtaal van die installatie overschreven!

Na installatie van een languagepack heb je via de GUI de mogelijkheid om de taal in te stellen voor de gebruiker en voor het systeem. Bij Terminal Servers (of Citrix XenApp) wil je in de meeste gevallen dat bij een Nederlands bedrijf Nederlands de standaard taal wordt voor gebruikers en voor het OS/System account.

Dit kun je via de volgende commandline doen: control.exe intl.cpl,,/f:”[path naar configuratie.xml]”

Het configuratiebestand moet er voor Nederlands als volgt uitzien:

<gs:GlobalizationServices xmlns:gs=”urn:longhornGlobalizationUnattend”>

<!– user list –>
  <gs:UserList>
    <gs:User UserID=”Current” CopySettingsToDefaultUserAcct=”true” CopySettingsToSystemAcct=”true”/>
  </gs:UserList>

<!– GeoID –>
  <gs:LocationPreferences>
    <gs:GeoID Value=”176″/>
  </gs:LocationPreferences>

<!– UI Language Prefernces –>
  <gs:MUILanguagePreferences>
    <gs:MUILanguage Value=”nl-NL”/>
    <gs:MUIFallback Value=”en-US”/>
  </gs:MUILanguagePreferences>

<!– system locale –>
  <gs:SystemLocale Name=”nl-NL”/>
<!– user locale –>

<gs:UserLocale>
   <gs:Locale Name=”nl-NL” SetAsCurrent=”true” ResetAllSettings=”false”>
   </gs:Locale>
</gs:UserLocale>

</gs:GlobalizationServices>

Dit configuratie bestand zorgt ervoor dat de taal van de huidige user op Nederlands wordt gezet en dat de regionale instellingen worden gekopieerd naar het default-user profiel en naar het systeem account. De regionale instellingen worden zelf niet ingesteld (dit kan wel) en ook de toetsenbord instelling wordt niet aangepast. De instellingen worden na een reboot aktief op de machine.

Voor meer opties en meer uitleg over de opbouw van het xml-bestand kun je terecht op:

RES Automation Manager: RunBook Parameter Linking

In een eerdere blog heb ik laten zien hoe je via RES Automation Manager een gebruiker aan kan maken, waarbij de user logonname automatisch via een counter wordt verhoogd in het geval dat er al een gebruiker bestaat met dezelfde logonnaam. In deze blog laat ik zien hoe je die aangemaakt logonname kunt gebruiken om de homedrive voor die gebruiker aan te maken. Uiteraard zou je dit nog verder door kunnen trekken, door ook de mailbox, etc. aan te maken. Het linken of transporteren van de waarde van een module naar een andere module, kan vanaf RES AM 2011 SR1. Datgene wat wij er in deze blog mee gaan doen, kan vanaf RES AM 2011 SR2 of RES AM 2012 IR1. Het is namelijk niet mogelijk om een waarde door te geven op het moment dat de module de status ‘finished with errors’ heeft in RES AM 2011 SR1.

Create Homedrive module

Als eerste maken we een module aan voor het creëren van de homedrive. Geef de module een logische naam, zoals ‘create a homedrive’. Ga vervolgens naar de tab ‘parameters’ en maak een nieuwe parameter aan. Geef deze de naam ‘UserLogonName’ (zonder de ‘ ‘) en stel de parameter zo in dat deze vraagt om een waarde op het moment dat hij gescheduled word. Check tevens de checkboxen en zorg ervoor dat alleen de box ‘Hide parameter if parameter is not used directly’ aangevinkt is.

Ga vervolgens naar het tabblad ‘Tasks’ en maak een nieuwe task aan. Kies voor ‘Configuration -> Files -> Perform operations. Maak hierin een nieuwe aktie type ‘Create Folder’ aan. Bij ‘Folder Path’ type je het path waar de folder aangemaakt moet worden. De driveletter is de letter van de drive van de server waar de map op aangemaakt word. Deze server moet uiteraard ook een RES AM Agent geïnstalleerd hebben. Plaats de cursor vervolgens achter de laatste ” in het path en selecteer de ‘UserLogonName’-parameter (dit kun je doen door een rechtermuisknop -> Insert Parameter -> $[UserLogonName] )

Klik OK en nogmaals OK om de ‘Perform file operation’-task af te sluiten.

Maak nu een nieuwe taak aan in de module. Kies hiervoor Security -> File Permissions -> Set. Gebruik dezelfde folder als in de ‘create folder’-task die je net hebt aangemaakt en vink het vinkje bij ‘Remove all existing permissions’ uit. Dit voorkomt dat standaard permissies die al bestaan op de folder (bv. Domain Users full control), worden verwijderd. Kies vervolgens voor ‘Add Entry’

In de ‘Add entry’ dialog venster kies je voor the ‘UserLogonName’-parameter (via rechtermuisknop) en vervolgens voor ‘Full control’ en ‘Add access allowed’

Klik vervolgens op OK, nog eens OK (om het venster van de taak Folder Permissies te sluiten) en nogmaals op OK (om de module te sluiten). De module voor het aanmaken van de homedrive is nu klaar. Je kunt deze testen door de module eenmaal uit te voeren, een testuseraccount op te geven en deze te module te starten op de machine waar de homedrives op aangemaakt worden. Controleer na het uitvoeren of de directory is aangemaakt en de juiste rechten er op zijn uitgedeeld.

Runbook parameter linking

Nu we beide modules hebben voor het aanmaken van een gebruiker en het aanmaken van een homedrive, gaan we deze samen plaatsen in een RunBook. Hierbij gebruiken we de aangemaakt UserLogonName uit de eerste module als input voor de ‘create homedrive’-module.

Maak een nieuwe RunBook aan en geef deze een goede naam, zoals ‘Create user and homedrive’. Ga vervolgens naar het tabblad ‘Jobs’ en maak hier een nieuwe job aan. In het ‘Add RunBook job’ venster kies je eerst voor ‘What’. Selecteer vervolgens de ‘Create domain user’ task. Vervolgens kies je in het ‘Who’ veld de juiste machine. In het geval van het aanmaken van een user account, zal dit waarschijnlijk de domain controller zijn. Op deze machine moet ook de juiste connector voor deze taak zijn geïnstalleerd. Onder het venster kies je voor ‘Continue Run Book on Error’ in het ‘Error control’ veld. Deze instelling is nodig om het RunBook door te laten gaan in het geval de module met het resultaat ‘Finished with errors’ terug komt (wat niet onwaarschijnlijk is dat dit gebeurd, omdat er regelmatig mensen zijn die dezelfde gebruikersnaam opleveren). Druk vervolgens op OK om de job aan te maken.

Maak vervolgens een tweede job aan. Selecteer hierbij de ‘create user homedrive’ en zorg ervoor dat deze op de fileserver komt te draaien. De fileserver kan van een normale agent worden voorzien. Laat ‘error control’ op de default waarde ‘stop run book on error’ staan.

Nu beide jobs in het RunBook staan, kies je voor het tabblad ‘Run Book parameters’ en klik je vervolgens op de knop ‘AutoCreate’ (onderin het venster). RES Automation Manager creeerd nu alle parameters die ook in de modules en/of projecten worden gebruikt. Verwijder na het aanmaken de ‘Counter’-parameter. Dubbelklik vervolgens op de UserLogonName om deze aan te passen. Maak het veld ‘Value’ leeg en ga vervolgens naar de ‘Links’ tab in dit dialoog venster. Klik hier met rechts op de ‘Create User Account’-job en kies vervolgens voor Action -> Get final value. Dit zorgt ervoor dat op het einde van de job, de waarde van UserLogonName wordt teruggegeven aan het RunBook.

Klik vervolgens met de rechtermuisknop op de ‘Create home drive’-job en kies voor ‘Set initial value’. Het resultaat zou vervolgens moeten zijn wat hieronder staat. De richting van de pijlen is hierbij het belangrijkste.

Klik op OK om terug te gaan naar de RunBook parameters tab. Klik hier op de ‘Links’ tab, deze zou er ongeveer zo uit moeten zien:

Op dit moment hebben we een RunBoom met twee verschillende jobs die mogelijk draaien op twee verschillende servers. De 2de job (het aanmaken van een homedrive) is afhankelijk van de gebruikersnaam die de eerste job (create user) heeft aangemaakt. Als de eerste job heeft gedraaid, wordt door het linken van de parameters, de laatste waarde van de UserLogonName-parameter van de job, getransporteerd naar de gelijkwaardige parameter in de RunBook. Het RunBook start vervolgens de 2de job en geeft deze (ook weer via de gelinkte parameters) de waarde mee die hij van de 1ste job heeft ontvangen. De 2de job maakt daardoor een homedrive aan met de user logonname die de 1ste job uiteindelijk heeft gecreeerd.

Nu hebben we alleen een problem als de ‘create user’-job faalt en het resultaat ‘failed’ krijgt. Doordat is aangegeven dat het RunBook door moet gaan als er problemen optreden, zal hij ook doorgaan als het resultaat ‘failed’ is. Om dit te voorkomen moeten we een conditie op de 2de job zetten. Ga daarvoor naar het tabblad ‘jobs’ van het RunBook, selecteer de 2de job (‘create home drive’) en klik onderaan het scherm op ‘condition’. Maak een nieuwe conditie aan met de volgende waarde ‘Status of previously executed job <> Failed’. Als de conditie WAAR (TRUE) is dan ‘Executed job’. De waarde bij FALSE komt op ‘Skip this and all other jobs’. Dit zorgt ervoor dat andere jobs (na het creeeren van de homedrive) in hetzelfde RunBook ook niet gedraaid worden (bijvoorbeeld het aanmaken van een mailbox).

Resultaat

Als we dit RunBook nu draaien en de voornaam, achternaam, etc. opgeven, maakt het RunBook eerst een gebruikersaccount aan. Daarnaa wordt de homedrive gecreëerd, tenzij de gebruikersnaam niet aangemaakt kon worden. Vraag je de uitslag van het RunBook op na draaien, dan zie je ongeveer hetgene hieronder:

  1. Het aanmaken van de user. De eerste 5x gingen niet goed. Na de 5de keer werd de gebruiker wel goed aangemaakt.
  2. Toont de settings die uiteindelijk via parameters gebruikt zijn in het process van het aanmaken van de gebruiker. De uiteindelijke gebruikersnaam is DuckK5 geworden.
  3. Let op de counter, deze toont het getal 5. Dit zijn de verhogingen van het getal achter de gebruikersnaam die ontstaan zijn doordat het aanmaken de eerste 4 keer niet goed ging, omdat die gebruikersnamen al bestonden.
  4. The job parameter die doorgegeven is aan de job ‘create home drive’. Deze bevat de user logonnaam die in de eerste stappen is gemaakt door de 1ste job.

Dit RunBook kun nu eenvoudig uitgebreid worden met bv. het aanmaken van een mailbox of het geven van rechten op andere systemen waar de gebruikersnaam van belang is. Via een CSV bestand kunnen snel meerdere gebruikers aangemaakt worden en ook is via Service Orchestration deze module te gebruiken om automatisch gebruikers aan te maken.