Etikett: serverlogg

Uppdateringar på Cloudheaven

Några uppdateringar i servermiljön dessa dagar mellan jul och nyår:

  • Uppdaterat WordPress till WordPress 5.0.
  • Lagt till domänen nikodemuskarlsson.se, med tillhörande WordPresskonto.
  • Justering av http-servern så att omskrivning görs från eventuell www före domännamnet till enbart domännamnet och omdirigering till https
  • Justering av http-servern så att ”frames” är tillåtna i https-läge (mycket smidigt i WordPress, där man då kan förhandsgranska hur inläggen ser ut som ett ”överlägg”)
  • Installerat senaste Python-versionen, Python 3.7.2.

Det som tog absolut längst tid var adressomskrivningen. Ett bra verktyg för att studera hur adresserna skrivs om hittade jag på redirect-checker.org.

Antivirusproblem

På cloudheaven.se så använder jag antivirussystemet clamav. För att skanna inkommande mail med avseende på virus (och även spam) så anropas clamav av ett annat program, amavisd (båda dessa program är gratis och open source, förstås!). Dessa måste förstås kunna kommunicera med varandra, och det görs via ett ”uttag” (socket).

Det jag upptäckte idag var att den utgående mailloggen visade att clamav inte tog emot anropet från amavisd. Det hade den gjort tidigare, när jag konfigurerade systemet för ett par år sedan. Men uppdateringar gör väl att konfigurationsfiler ändras.

Det som behövde göras var att ändra filen amavisd.conf enligt

code_diff.png

Omstart av serverprogram enligt
systemctl restart clamd@scan, systemctl restart clamd@amavisd och systemctl restart amavisd.

Så, vips var problemet ur världen ?. Det var bara det att detta ”vips” tog närmare tre timmar att hitta…?

Denna logg gör jag som en del av det underhållsarbete jag utför på cloudheaven.se. Övriga inlägg av den karaktären finns här.

 

Strul med Let’s Encrypt och Python

Den här servern har ett ssl-certifikat från Let’s Encrypt. Det var lätt att installera och det är gratis, så jag var nöjd med det. Giltighetstiden på certifikatet är dock enbart tre månader, sedan måste det förnyas. Det finns det skript för, och jag kör det automatiskt en gång per vecka. Men förra veckan såg jag i loggen att något inte var som det skulle. Istället för det vanliga meddelandet att ingen förnyelse behövdes, så var det bara tomt. Det verkade inte ens vara kört.

Manuell koll. Felmeddelanden som hade med Python att göra. Just det; förra veckan när jag jag rutinmässigt uppdaterade serverns program så var det ju en uppdatering av just Python. Felet verkade vara relaterat till pip, Python:s pakethanterare som bl a Let’s Encrypt använder.

Det jag fick göra var följande:

* yum remove python-pip # Ta bort det pip som var installerat
* yum install python-pip # Installera exakt samma version
* pip install --upgrade pip # Uppgradera till det senaste pip, 9.0.1
* pip install certbot # (Om)installera programvaran från Let's Encrypt
* touch /usr/lib/python2.7/site-packages/setuptools-34.4.1.dist-info/METADATA # Skapa den fil som efterfrågades när jag körde pip

Nu fungerade det! Jag slapp iallafall installera om själva certifikatet; förhoppningsvis så sker det problemfritt när det väl är aktuellt.

Permalinks i WordPress

För att anpassade s.k permalinks ska fungera i WordPress kan man vara tvungen att ändra i webbserverns konfiguration. För webbservern Apaches del gäller att det dels filen /etc/httpd/conf/httpd.conf och dels filen /var/www/html/.htaccess som kan behöva justeras.
Fortsätt läsa ”Permalinks i WordPress”

Mail från servern

OK, jag har tidigare konfigurerat mailutskick från serven med Postfix, och genom att ”reläa” utskicken genom mitt gmail-konto. Det funkade, men det visade sig vara krångligt med att anpassa avsändaradressen (som blev en gmail-adress som standard). Nu hittade jag en beskrivning på denna sida, och att få adressen från @cloudheaven.se visade sig vara ganska enkelt.

Om jag behöver ytterligare anpassning finns det beskrivet här hur man kan göra.

Återställning av MySQL-databasen

Fick idag orsak att använda min senaste backup av MySQL-databasen här på cloudheaven.se. Jag försökte ändra på sökvägen till denna webbplats, så att den ska ligga i webbserverns rot. Det gick inte så bra… (uppdatering: jag gjorde en manuell överföring den 24 januari)

För att, efter detta missöde, återställa databasen till den senaste backupen gick jag in i MySQL-kommandohanteraren enligt nedan:

[my prompt]> mysql -u  -p
Enter password:
MariaDB [(none)]> use myDatabase
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [myDatabase]> source mysql_dump.sql

Tyvärr verkar det inte gå på något enkelt sätt att ändra installationen till webbservern rot, så jag kommer att göra en ny installation på rätt plats. Nu känner jag till så mycket jag behöver för att kunna starta upp sajten där jag vill ha den.