Sähköposti

Olen jättänyt sähköpostin asettamisen viimeiseksi, koska se on itseasiassa omalla tavallaan työläin asia. Se on myös sellainen, jonka toteutusta kannattaa miettiä pidempään – jopa kauemmin kuin sopivan dropletin valitsemista.

Internetin suuria ihmeellisyyksiä ei ole se, että miten sivustot saadaan toimimaan. Internetin suurin mysteeri on miten ylipäätään sähköpostien välittäminen onnistuu. Se on nimittäin monimutkaisempi asia ja paljon hankalampi ylläpidettävä kuin web koskaan. Monimutkaisuus, josta aiheutuu helposti virheitä ja aukkoja, joita sitten spämmääjät hyödyntävät, on suurin syy sille, että omaa sähköpostipalvelinta ei saa asennettua oikeastaan mihinkään.

Sivuston on kyettävä lähettämään sähköpostia. Mittakaava taasen ratkaisee paljonko kannattaa panostaa.

Ennenkuin jatketaan, niin tehdään yksi ehdottoman pakollinen asia. Avataan palomuuriin portti sähköposteja varten.

ufw allow 587

Serverin perusasetus

Lue viimeinen kappale ennen kuin alat tekemään tätä. Säästät aikaa ja pettymyksiä.

apt install postfix

Valitse nuolilla ja siirry tabilla, osassa joutuu valitsemaan välilyönnillä , ja siirry eli sarkaimella, ok tai cancel

Valitse Internet Site

Anna domainin nimi, tässä eksis.dev

Avataan asetukset:

nano /etc/postfix/main.cf

Etsi rivi inet_interfaces = all – se on luultavasti toiseksi viimeinen. Muuta se tällaiseksi:

inet_interfaces = loopback-only

Käynnistä uudelleen:

systemctl restart postfix

Testataan lähteekö sähköposti komentoriviltä. Asennetaan sitä varten mailutils:

apt install mailutils

Muuta edes sähköpostiosoite, johon lähetetään:

echo "Tässä olisi normaalisti viesti." | mail -s "Otsikko: testataan mailia" sinun.aito@gmail.com

Jos viestiä ei kuulu (varsinkin Gmail on hankala, koska pitää moista roskana), niin sitten vilkaistaan logeja, josko sieltä pääsisi eteenpäin virhettä etsiessä:

cat /var/log/mail.log

Tee vielä toinenkin testi. Pyydä salasanan palautusta WordPressiltä. Jos sekin toimii, niin kaikki on aika hyvin. Yleensä ei toimi kovinkaan hyvin jo pelkästään siksi, että maileja välittävät serverit eivät ilahdu lähettäjätiedoista, jotka niiden näkökannan mukaan näyttävät vahvasti väärennetyiltä. Se on yksi syy sihen miksi pääsääntöisesti käytetään lisäosia sähköpostien välitykseen. Ne eivät ota yhteyttä serverisi kautta, vaan suoraan API:n avulla, jonka saaminen on edellyttänyt lähettävän sähköpostiosoitteen tunnistamista tavalla tai toisella.

Pienten sivustojen ratkaisu

Jos tarve on lähettää kirjautumistietoja, sinulla on uutiskirje sivustolla ja luokkaa enintään sata vastaanottajaa ja lähetäjällä gmail-osoite ei haittaa, niin asenna WP Mail SMTP lisäosa:

cd /var/www/eksis.dev/public_html

wp plugin install wp-mail-smtp

wp plugin activate wp-mail-smtp

Kirjaudu sisään ja aseta WP Mail SMTP lisäosan ohjeiden mukaan – ja kyse ei todellakaan ole mistään yksi-klikkaus operaatiosta. Itseasiassa joutuu näkemään aika paljon vaivaa, että saa rajoitetun sähköpostiliikenteen toimimaan.

Samalla vaivalla saa oikeankin systeemin.

Jos ei halua maksaa sähköpostin välittämisestä, niin silloin kannattaa naittaa Postfix ja Gmail yhteen, jolloin et edes tarvitse mitään lisäosaa lähettämään sivuston posteja Gmailin kautta maailmalle. Seuraa näitä ohjeita.

Ammattilaisemmat ratkaisut

Gmail on toimiva, mutta lähettäjän sähköpostin muuttamisen vaikeus (gmail-osoite syö aina uskottavuutta) tai kalleus, jos sen hoitaa G Suiten kautta, ovat melkoisen rajoittaviakin tekijöitä. Suurin ongelma on kuitenkin rajattu lähetysmäärä. Mikä tahansa hiukankaan myyvä verkkokauppa törmää Gmailin rajoituksiin ja samalla postituslistat muuttuvat mahdottomiksi.

Toki postituslistat voi hoitaa esimerkiksi MailChimpin kautta, mutta se muuttuu hyvin äkkiä melkoisenkin hinnakkaaksi ilman, että saisi muuta vastineeksi kuin mahdollisuuden tehdä useampia listoja. Siksi postituslistat itseasiassa kannattaisi hostata itse. Mutta MailChimp ei ratkaise muita sähköpostikysymyksiä, se on pelkästään postilistaspesifinen ratkaisu – silti joutuu maksamaan muuta järjestelmästä.

API-pohjalta toimivia sähköpostinvälityksiä on useita markkinoilla. Yksi sellainen on Mailgun. Jos olet jo heidän asiakkaansa, niin silloin sinun kannattaa vilkaista ohjeet miten Mailgun asetetaan yhteen Postfixin kanssa.

Syyt siihen miksi niin usein suositellaan käytettäväksi esimerkiksi MailChimpiä tai Mailgunia, ovat aika yksinkertaisia, osaltaan jopa masentavia:

• webhotelleissa ei ole muita vaihtoehtoja ja suurin osa on webhotellien asiakkaita
• todella isoilla sivustoilla, joissa budjetissa joku satasten kuukausikulut ovat pienempi kuin johdon kuukauden kahviostot, ulkoistaminen vähentää omaa työtä ja tehot ovat riittäviä. Aidosti siis säästetään rahaa, kun ei tarvitse panostaa omaa työtä. Eikä miettiä mikä on aito panostuksen ja tuoton suhde, koska kummassakin ollaan kahvirahoissa.
• ohjeiden kirjoittajat pääsevät vähemmällä, kun voi käyttää valmista ratkaisua (plus aika moni tekee maksettua tekstimainontaa kertomatta sitä)

Jos kuitenkin haluat globaalisti vahvan toimijan, joka ei ole edes kallis (halpaa ei olekaan, ja halpa on harvemmin hyvä tai edes luotettava), niin silloin asetat käyttöön Amazonin SES -palvelun. Olen kokeillut suunnilleen kaikkia isoja toimijoita ja Amazonia ei vaan pysty haastamaan. Varsinkin kun maksat vain siitä mitä käytät, et Mailgunin ja muiden tapaan kuukausihintaa siitä mitä voisit käyttää.

Amazonin käyttöönotto on hieman hankalampi, mutta ei päättömän vaikeaa. Ei virtuaaliserveriä kummallisempaa. Lue asennusohjeet WordPressin ja Amazon SES:n yhdistämisestä pariin kertaan läpi, niin tiedät missä mennään.

Amazon SES:ssä on toinenkin vahva pointti. Siitä saa tehtyä täysverisen sähköpostipalvelimen eli saat hoidettua myös saapuvan liikenteen. Kaikki edellä olevat ohjeet perustuvat siihen, että sivusto voin lähettää ja vastaukset täytyy ottaa jonnekin muualle. Vilkaise myös ohjeet miten Amazon SES hoitaa koko sähköpostiliikenteesi. Minä maksoin aiemmin webhotelleille kiinteää kuukausihintaa vain siksi, että sain domainille aidon sähköpostiosoitteen. Mutta en enää. Nyt kaikki kiertää Amazonin palvelimien kautta.

Vai onko esteenä siirtymisessä Amazonille G Suiten työryhmäominaisuudet ja webmail? Ei ongelmaa, Amazonilla on vastaava järjestelmä nimeltään WorkMail – ja tietysti WorkMailinkin käyttöönottoon löytyy täältä ohjeet.

Olevan sivuston muutto

Kaikki edellä kirjoitettu perustui ajatukseen, että tehdään uusi sivusto. Perusteltua, kun ollaan testausvaiheessa. Asiat muuttuvat hieman, jos ollaan siirtämässä sivustoa webhotellista, tai jopa toiselta serveriltä.

Serveri asennetaan aina samoin, teki uudisasennusta tai muuttua. Myös virtual host asennetaan sanoin Nginxiin. Se mikä muuttuu on WordPressin asennus.

Jos siirrät webhotellista virtuaaliserverille, niin kannattaa joko käyttää WordPressille tehtyä kopiointilisäosaa tai backup-ratkaisua. Kopiointi tietää, että siirretään uuteen paikkaan, eikä domaininkaan muuttuminen ole yleensä mikään ongelma. Backup taasen siirtää 1:1 kopion, koska tehdään palautus varmuuskopiosta – paikka on vain muuttunut. Export/import -lisäosista taasen kannattaa pysyä mahdollisimman kaukana. Ne eivät yleensä toimi kunnolla exportissakaan, importista puhumattakaan, puhumattakaan että siirrettäisiin koko sivusto.

Vilkaise näitä ohjeita, jos olet muuttamassa webhotellista virtuaaliserverille (tai toiseen webhotelliin).

Virtuaaliserveriltä toiselle muutto on helpompi, monessakin suhteessa. Jos teet uuden serveriasennuksen, niin tee se tämän jutun ohjeilla. Pääsääntöisestihän WordPress ei ole kantaa ympäristöön. Jos käytät jotain WordPressin firewall-lisäosaa, niin asia saattaa olla toinen – mutta niitä ei kannattaisi muutenkaan käyttää. Niistä ei ole apua, eivätkä ne aidosti estä mitään. Hieman samaa kuin mitä bottiliikenteelle neuvotut honey potit, joilla ne saadaan ansaan. Teoriassa asia on niin, mutta käytännössä niihin ei ole mennyt edes script kiddien kopypastebotti sitten vuosituhannen alun. WordPressin palomuurit on tehty sellaisille, jotka eivät päivitä sivustoaan tai pelkäävät tarpeeksi paljon; tai molempia.

Jos haluat kopioida saman ympäristön, niin EksisONE tarjoaa roadmap-ohjeet miten serveriltä siirretään ohjelmien tiedot uuteen paikkaan.

WordPressin siirto sen sijaan ei ole koskaan ollut helpompaa, koska käytössä on wp ja rsync. Kun kohdeserveri on valmis, niin uusi WordPress on toiminnassa minuuteissa (toki sivuston tiedostokoosta riippuen). Ohjeet neuvovat miten siirto tehdään.

Nopeus on suhteellista

Jutun otsikointi oli hieman… jos ei ei yltiöpositiivinen, niin positiivinen ainakin. WordPressin nopeus nimittäin riippuu monesta asiasta.

Nopeuden yksi kriteeri on miten hyvin palvelinpuoli selviää työstään, ja selviäminen pitää sisällään myös nopeuden. Webhotelleissa olet täysin yrityksen armoilla, eikä sinulla ole montaa tapaa kiihdyttää itse perustekniikan toimintaa. Sivucache mallia WP Rocket on oikeastaan ainoa tapa. Webhotelleissa on myös täysin mahdotonta saada sivustoa skaalautumaan millään tavalla.

Skaalautuminen on tekniikan muuttumista niin, että kuormapiikit saadaan tasattua. Tarkkaan ottaen tämänkään ohjeen ratkaisu ei sinällään liity skaalautuvuuteen, mutta – mittakaava huomioiden – sitä cache tekee.

Mitä seuraavaksi?

Koska sinulla on (kohtuullisen) toimiva serveri, jossa on WordPress, niin ehkä kannattaa alkaa töihin. Tekemään sitä miksi ylipäätään on keksitty internet, web, serverit ja WordPress: sisältöä ihmisille.

On kuitenkin yksi pieni detalji, joka kannattaa varmistaa. Vilkaisen vapaana olevan muistin määrää. Jos sitä on vapaana kolmannes tai vähemmän, niin päivitä isompaan serveriin – heti. Joskus näkee virityksiä, jossa kaksi tai kolme sivustoa on viety omille viiden euron dropleteilleen. Kyllä, noin voi tehdä. Silloin on muutama heikkotehoinen serveri, jotka maksavat yhdessä lähes saman kuin yksi sellainen. joka pyörittäisi kaikkia kahta tai kolmea sivustoa ongelmitta.

Mutta nuo ovat valintakysymyksiä

Jos tarvitset jossain vaiheessa koottuja neuvoja kaikesta mitä pitäisi tehdä virtuaaliserverin käyttöönotossa, niin tämä ohjeistus lienee turhan pitkä. Et tarvitse enää myöhemmin selityksiä ja vakuutteluja. Riittäisi, että on listaus komennoista.

Sellainen on. Avaa roadmap.

Roadmap

Ubuntu

apt update

apt dist-upgrade

reboot

timedatectl set-timezone Europe/Helsinki

Nginx

apt install nginx

systemctl enable nginx

unlink /etc/nginx/sites-enabled/default

nano /etc/nginx/nginx.conf

nginx -t

systemctl restart nginx

PHP/PHP-FPM

apt install php7.4-fpm php7.4-common php7.4-mysql \
php7.4-xml php7.4-xmlrpc php7.4-curl php7.4-gd \
php7.4-imagick php7.4-cli php7.4-dev php7.4-imap \
php7.4-mbstring php7.4-opcache php7.4-redis \
php7.4-soap php7.4-zip -y

mv /etc/php/7.4/fpm/php-fpm.conf /etc/php/7.4/fpm/php-fpm.conf.backup

nano /etc/php/7.4/fpm/php-fpm.conf

mv/etc/php/7.4/fpm/php.ini /etc/php/7.4/fpm/php.ini.backup

nano /etc/php/7.4/fpm/php.ini

php-fpm7.4 -t

systemctl restart php7.4-fpm

systemctl enable php7.4-fpm

MariaDB

apt install mariadb-server

mysql_secure_installation

UFW

ufw app list

ufw allow 'Nginx Full'

ufw allow OpenSSH

ufw enable

ufw status

Fail2ban, asennus

apt install fail2ban

Let’s Encrypt

apt install letsencrypt

apt install python3-certbot-nginx

certbot certonly --nginx -d eksis.dev -d www.eksis.dev

Virtual Host

mkdir -p /var/www/eksis.dev/public_html

nano /etc/nginx/sites-available/eksis.dev

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.

Profiili: Jakke Lehtonen