Maintenance window 20137-03-25 & 2017-03-27 00:00 – 06:00

Hej / Hello
English version below

Vi på Adminor har blivit notifierade av Stokab som har planerat in ett driftavbrott på fiberförbindelser där vissa tjänster kommer påverkas.

Orsak till åtgärden är: Driftarbete av Stokab för flytt av kablar pga tvärbanan.

Adminor kommer växla över till sekundär länk mellan: 2017-03-25 kl. 00.00-06.00 och återställa till primärdrift EFTER att STOKAB 27/3 slutfört sitt arbete.
Överflytten beräknas ta några minuter vid varje tillfälle.
Avbrottet hos STOKAB kommer att ske mellan: 2017-03-27 kl. 00.00-06.00 och beräknas inte påverka Adminors kunder under deras servicefönster.

För eventuella frågor v.v. kontakta oss på noc@adminor.net, www.uppe.nu, telephone 08 564 314 30  eller tilldelat journummer.

English version

Adminor is hereby informing you of a planned maintenance of Stokab fibre connections servicing our datacenters.

The reason for this outage is: Rerouting of cables by Stokab due to construction works.

Adminor will switch-over to secondary paths: 2017-03-25 kl. 00.00-06.00 och återställa till primärdrift AFTER STOKAB 27/3 has performed their maintenance work. This is expected to take a couple of minutes at each change.
The outage with STOKAB is planned: 2017-03-27 at 00.00-06.00 and should not affect Adminor customers during their service window

If there are any questions regarding the above you are welcome to contact us at noc@adminor.net, www.uppe.nu, telephone 08 564 314 30  eller tilldelat journummer.

De berörda tjänsterna är / The services affected are:

Primary interconnect between Hammarby Datacenter and Västberga ( Virtual Machine replication between datacenters may be delayed ).
Services hosted on 46.253.192.0 – 46.253.207.254, 185.111.240.0/24 in Västberga DC but not in Hammarby DC.

For customers with services on 46.253.192.0/20 IP range, we offer replacement IPs on different IP ranges that originate from Västberga DC.

Let’s encrypt for varnish?

Do you have a site that’s accelerated with varnish but noticed that there is no native SSL support for Varnish?

No problems!
You can use a bunch of different methods to terminate SSL .
In this post I’m not going to be posting a bunch of configuration or setup steps. But discuss the caveats of terminating SSL .

Let’s say you are using drupal or wordpress.
Your current setup probably looks something like this:

varnish –> apache OR nginx backend -> application (wordpress/drupal) .

With Let’s encrypt you’re going to want to setup an SSL terminator. In the past I’ve recommended using ”pound” as an SSL terminator, but due to the slow development cycles I’ve moved towards nginx or haproxy.

Of the two I’d setup nginx SSL terminator in most cases as the Let’s encrypt certbot supports nginx natively for issuing and renewing SSL certificates.

Haproxy is awesome if you plan to use multiple backends or caches. If you use haproxy you probably know what you are doing but the problem with Let’s encrypt is that you have to run certbot in standalone mode with the ”certonly” variable on the commandline .

Haproxy will be configured to pass the acme-challenge to the standalone daemon that certbot launches. The renewal process will also use the forwarded requests .

With nginx it’s as simple as just creating the cert using certbot and configuring SSL proxy onwards to varnish.

We assume that you have previously managed to configure apache mod_rpaf , mod_remoteip or nginx to handle x-forwarded-for to provide the right IP to the web application.

One big issue that we’ve seen on customer installations when adding let’s encrypt support to already running setups is the fact that the backend application has no clue about https protocol. This sometimes causes forwarding loops or problems with loading http:// resources over a https:// connection (modern webrowsers raises alerts and refuses to load resources outside the https:// connection if it’s properly configured).

It’s important that the x-forwarded-for and protocol is passed on in all steps of the chain.

With haproxy you use option forwardfor and x-forwarded-proto.
Nginx needs to do the same.

On the backend side you can force SSL in a number of different ways.
The easiest way in php is to force https. Drupal and WordPress have a number of plugins to do so, you can also edit the php config files to force SSL.

For example in wp-config.php :
define(‘FORCE_SSL_ADMIN’, true);
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)
$_SERVER[‘HTTPS’]=’on’;

Do you need help to add SSL and let’s encrypt for your current varnish setups? Feel free to contact us 

Adminor also offers ready-made VM images with Let’s encrypt varnish proxies for our VPS customers.

Driftstörning 2017-02-13

Berörd site:
– Hammarby, IP-ONLY
– Västberga, VBDC

Idag drabbades vårat nätverk av driftstörningar.
Ursprungliga felet beror på att uppströmsleverantör oannonserat dragit om fiber (som inte skulle beröra vår utrustning).
De har av misstag brutit anslutning mot våra fiberlänkar mot knytpunkter och andra hallar.

Vid 14:45 inkom rapport om fel.
Vid 14:45 påbörjades migrering av våra tjänster till sekundär fiber.
Vid 15:20 var samtliga länkar överflyttade.

15:55 kontaktas uppströmsleverantör för att felsöka vad som är fel.
Vid 16:45 hittar de felet. De kopplar dock in optiken innan vi förberett nätverket för överväxling. Detta skapar en switchloop i nätverket vilket ger följden att svarsförluster och access drabbas.
Vid 16:55 kopplas detta ur igen och nätverksaccess återställs.

SAN och storage går över en helt separat förbindelse, backup path var igång hela tiden så att inte dataförluster ska uppstå.
Om det ändå är något problem, kontakta oss direkt så avhjälper vi det.

English:

Malfunction 2017-02-13

Concerned site:
– Hammarby, IP-ONLY
– Västberga VBDC

A network issue impacted our network operations.
The original error was caused by the upstream supplier performing routine work on other equipment and connections (not related to Adminor). Their technician accidently broke connectivity to our primary uplink to our core.

At 14:45 discovered a network fault.
At 14:45 started the migration of our services to secondary fiber.
At 15:20, all links transferred. (A few customer VLANs did not transfer automatically, we’re troubleshooting this to decrease chance of this happening again.)

15:55 contacted upstream provider to troubleshoot issues to resolve the primary link being down.
At 16:45 fault was found. The upstream provider connected the port before we were ready, which caused a switchloop.
At 16:55 the switch-loop was resolved.

SAN and storage go over a completely separate connection, the backup path was running all the time so that no data loss will occur.
If there still is a problem, please contact us directly so we can remedy it.

 

Ny transit operatör från 1 augusti

Adminor har tecknat transitavtal med Cogent direkt .
Det betyder att Adminor från 1 Augusti kommer byta trafik med Cogent direkt istället för via en tredjepart.

För att inspektera och pröva nätverkspaths så kan man testa deras looking glass: http://www.cogentco.com/en/network/looking-glass

Källa: http://cogentco.com/en/network/network-map

Supersnabb WordPress installation på Adminor SSDVPS

Det första du behöver är en SSDVPS från Adminor (även om det går bra med andra leverantörer också så rekommenderar vi våra tjänster)

SSDVPS:en ska köra Ubuntu 14.04 LTS för att denna guide ska vara kompatibelt.
Vi kommer använda oss utav Zach Adams guide för att installera en miljö med följande komponenter:

Percona DB (MySQL) (Looking for MariaDB? Try this)
HHVM (Default PHP Parser)
PHP-FPM (Backup PHP Parser)
Nginx
Varnish (Running by default)
Memcached and APC
Clean WordPress Install (Latest Version)
WP-CLI

 

Installation

  1. SSH:a till din nyligen skapade server, lägg till nödväntiga apt paket om dessa redan inte är installerade:
    sudo apt-get install software-properties-common
  2. Lägg till Ansible med sudo add-apt-repository ppa:ansible/ansible
  3. Uppdatera Apt med sudo apt-get update && sudo apt-get upgrade
  4. Installera Git oc Ansible med sudo apt-get install ansible git
  5. Klona detta repository med git clone https://github.com/zach-adams/hgv-deploy-full/
  6. Flytta in till  cd hgv-deploy-full
  7. Editera hosts filen och ändra yourhostname.com till ditt eget hostname. Om du har fler siter på denna server så lägg till varje domän på en ny rad.
  8. Editera yourhostname.com filen in host_vars katalogen till ditt eget hostname. Om du vill installera fler siter på denna server så ska du kopiera den nuvarande och byta namn på den till den andra sitens domän .
  9. Ändra site specifik information inklusive lösenord innuti hostname filen i host_vars katalogen
  10. Kör Ansible med sudo ansible-playbook -i hosts playbook.yml -c local. Får du några fel så kontakta oss så kanske vi kan hjälpa till.
  11. Ta bort den klonade git katalogen från din server med rm -rf hgv-deploy-full/
  12. Kör /usr/bin/mysql_secure_installation för att installera MySQL och säkra det. Ditt root-lösenord är tomt från början.
  13. Starta om Varnish och Nginx med: sudo service varnish restart && sudo service nginx restart
  14. Du bör nu vara klar! En ny WordPress installation som kör HHVM och Varnish bör nu vara klar i hostname/s!

 

Hur man installerar en Ny Site / Hostname

Dessa steg funkar bara om du installerat med metoden ovan. Ta alltid en backup på din server innan du gör ändringar!

  1. Ta en backup
  2. Följ steg 1-6 ovan
  3. När du kommer till din hosts fil följ samma steg MEN dinkludera inga tidigare installationer av WordPress eller hostnames, bara de nya du vill installera.
  4. Upprepa detta för din host_var katalog
  5. Följ steg  9-12 och får du några problem så kan du kontakta oss så kanske vi kan hjälpa till.

Hur man stänger av Varnish (använd bara Nginx)

Om du får problem att ändra eller får problem med backend när du använder Varnish så kan du stänga av det och bara använda Nginx. Du bör fortfarande få relativt god prestanda. Så här gör du det:

  1. Öppna varje konfiguration i Nginx för siter du har installerat på din server med kommandot: sudo nano /etc/nginx/sites-available/your-hostname.com
  2. Ändra listen = 8080; till listen = 80;
  3. Gör detta för alla siter som är installerade på servern
  4. Stoppa Varnish och Starta om Nginx med sudo service varnish stop && sudo service nginx restart
  5. Du bör nu vara klar! Har du ingen cache plugin för wordpress installerat så rekommenderar vi att du skaffar en.

Växla från HHVM tillbaka till PHP-FPM

Din Nginx konfiguration bör växla automatiskt till PHP-FPM om det uppstår problem med HHVM, du kan däremot växla manuellt om du behöver göra det:

  1. Öppna din Nginx konfigurationsfil med  vim|emacs|nano /etc/nginx/sites-available/( Your Hostname )
  2. Ändra följande sektion i slutet av filen:
    location ~ \.php$ {
        proxy_intercept_errors on;
        error_page 500 501 502 503 = @fallback;
        fastcgi_buffers 8 256k;
        fastcgi_buffer_size 128k;
        fastcgi_intercept_errors on;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass hhvm;
    }
  1. Ändra fastcgi_pass hhvm; till fastcgi_pass php;
  2. Starta om Nginx med sudo service nginx restart
  3. Du bör nu köra PHP-FPM! Kontrollera med phpinfo(); i en php fil

Vill du att vi installerar åt dig så erbjuder vi konfigurationstjänst. Kontakta oss på support@adminor.net för offert!

 

Recursive DNS – Adminor

Adminor has shutdown its last internal recursive DNS. It will not permit recursion (DNS lookup of non authorative domains) from other IPs outside of Adminors own network.

Customers on Adminors IP ranges can still use it as a DNS server for lookups, although we recommend googles:

8.8.8.8

8.8.4.4

 

This change has been made to reduce the risk of Adminors DNS server being used in DNS amplification attacks.

Maintenance 00:30 – 00:50 2015-11-10

An emergency maintenance was performed at 00:30 to 00:50 to update some critical nodes.

We apologize for this inconvenience.
Due to a configuration error the network did not come back online as planned and the maintenance windows was felt for our customers. Manual intervention by on-call technician was required to rectify this issue.

This update was performed on Adminor and Transit providers network edge causing disruption. Since the update caused errors some of the updates were rolled back.
Another update will be attempted at another scheduled time.