PRO ISP støtter IKT servicefag
Skrevet av: Isabelle

PRO ISP startet i 2017 et samarbeid med IKT servicefag på Haugaland videregående skole. Samarbeidet innebærer egne priser for webhotell som benyttes i skolesammenheng.

 

Elevene kommer raskt i gang med opplæringen

Rune Karlsen er faglærer på IKT servicefag og forteller: «Ved å benytte PRO ISP sine tjenester kommer elevene raskt i gang med opplæringen for å drifte nettsider. Vi er opptatt av at dataene skal lagres på en mest mulig sikker måte, at det skal være mest mulig lokalt, og at serverhosten følger norske lover og regler. Vi kjører både lokal server og ekstern server slik at elvene får opplæring i begge. De må kjenne til de fleste mulighetene når de senere skal ut i jobb. Vi ønsker å bevisstgjøre dem i forhold til om det lønner seg økonomisk å sette ut tjenester, eller å kjøre dem selv.»

Tjenester som er relevante for elevene

PRO ISP fokuserer på automatisering av tjenestene der det er mulig. Vi er i tillegg opptatt av standardisering og kvalitetssikring. Det er viktig at tjenestene elevene benytter seg av er relevante og forbereder dem på IT-samfunnet de skal delta i.

«Vi er i konstant dialog med læreplassene til våre elever. Det er disse som legger føringer på hva elevene skal og bær lære før de blir ansatt som lærlinger. Det er vårt ansvar som faglærer å tolke hva som ligger innenfor kompetansemålene for å deretter lage læringsmål av dem» sier Karlsen.

PRO ISP ble anbefalt

«Vi ble anbefalt PRO ISP av Hatteland Solutions som også samarbeider tett med dem.» Karlsen forteller videre at de ønsker elevene skal besøke datahallene til Hatteland for å fysisk se hvor data blir lagret, og hvordan sikkerheten blir ivaretatt.

«Ved å benytte PRO ISP vet vi også at dataene til våre elever lagres i Norge og følger norske lover og regler. PRO ISP kunne også tilby våre elever en tjeneste til en overkommelig pris. At elevene også kunne overta tjenesten/nettsiden etter endt utdanning, var også et pluss.»

Et vellykket samarbeid

Faglærer Karlsen er meget fornøyd med samarbeidet mellom IKT servicefag og PRO ISP. Hele prosessen med å opprette domene for elevene, til installasjon av andre tjenester gikk smertefritt. Han forteller at elevene ga tilbakemelding om at det var intuitivt og enkelt å forholde seg til tjenestene fra PRO ISP.

«Jeg vil anbefale denne ordningen for alle IKT klasser. Våre elever lærte utmerket hvordan domene, webhotell, cPanel, integrering av eposter med MX etc henger sammen. Vi opplevde det var lettere for våre elever å se sammenhengen mellom de ulike teknologiene når vi benyttet PRO ISP. Vi er strålende fornøyd med tilbudet vi fikk og håper vi kan fortsette samarbeidet i mange år fremover.»

Skoleklasse som behøver webhotell?

PRO ISP tilbyr gode og rimelige avtaler for skoleklasser som ønsker å benytte våre webhotell. For mer informasjon kan lærer ta kontakt med oss på salg@proisp.no.

Please follow and like us:

Sikkerhet for nettsider – hvordan gjøre nettsiden sikker
Skrevet av: Trond Olav Ånesen

Å ivareta sikkerheten på nett er ikke på noen måte noe nytt. Mange tenker gjerne kun sikkerhet som besøkende på en nettside, men som eier må man også tenke sikkerhet. Det har ingen betydning hvilken type nettside du har. Enten det er en enkel informasjonsside, en blogg, en nettavis, en nettbutikk eller hva som helst.

Sikkerheten er viktig både for deg som eier og driver siden, og for de som besøker og bruker nettsiden. I denne artikkelen ser vi på hvordan man opprettholder grunnleggende sikkerhet og hva man kan/må gjøre hvis noe inntreffer.

Sikkerhet på nettsiden din handler om:

  • Det skal være trygt for alle å besøke nettsiden
  • Nettsiden skal ikke være infisert med skadelig kode som kan infisere besøkende
  • Nettsiden skal ikke videresende til sider med skadelig kode
  • Informasjonen som utveksles mellom besøkende og nettside/server skal ikke kunne fanges opp av uvedkommende

I en artikkel som dette har vi ikke anledning til å gå i dybden på alt, men vi fokuserer på det viktigste; Det skal være trygt å besøke nettsiden din!

sikkerhet for nettsider

Sørg for at nettsiden ikke er eller kan bli infisert

Når en nettside er åpen på nett er den et potensielt mål for en hacker. Hackeren er ikke nødvendigvis en kar i svart hettejakke som bor i en klam kjeller. I de aller fleste tilfellene er en hacker bare en automatisert «Bot» (Robot). Slike «Boter» står kontinuerlig og skanner både kjente og ukjente nettsider etter sårbarheter som kan utnyttes. Sårbarhetene eksisterer i koden man kjører, direkte, eller i tillegg, utvidelser og annet. Et klassisk eksempel er en nettside laget i WordPress, med eget tema og en håndfull plugins installert. Vi tar utgangspunkt i nettopp dette eksempelet videre i denne artikkelen.

Siden WordPress er så utbredt som det er, så er det populært å lete etter svakheter i denne type installasjoner. Klarer man å infisere 1 nettside, kan man potensielt gjøre det samme med mange tusen flere nettsider.

Motivet bak det å infisere en nettside kan være forskjellig; en hacker ønsker å spre sitt eget budskap, de ønsker å sende ut spam fra din konto, de ønsker å fange opp sensitiv informasjon fra besøkende, de ønsker å videresende besøkende til andre lumske sider, de ønsker å bruke ressursene til konto i andre angrep osv. Dette er noe man selvsagt ønsker å unngå. Som regel er det ikke deg direkte de ønsker å ta.

Sjekkliste for å unngå at din nettside blir infisert

  • Alt må være oppdatert, alltid
    Siden WordPress (og andre lignende systemer) er såpass populært, kommer det også oppdateringer så snart sårbarheter blir funnet, og utbedringer blir laget. Man må følge med slik at man får med seg oppdateringer og implementere disse i egen installasjon. Så snart en sårbarhet er oppdaget og kjent, er det kun et tidsspørsmål før nettsider som ikke er oppdatert blir angrepet. Det samme gjelder for alt av tillegg som er installert.I eksempelet vårt kjøres et eget tema og en del plugins. Disse kan også inneholde sårbarheter og utviklerne kommer da jevnlig med oppdateringer som retter dette. Derfor er det like viktig at dette holdes oppdatert som selve installasjonen.
  • Alt som ikke er i bruk på webhotellet bør fjernes
    Alle temaer og utvidelser/plugins som ikke er i bruk bør slettes/fjernes. Selv om man deaktiverer en utvidelse/plugin eller tema så er ikke alltid alt faktisk borte. Filer ligger ofte igjen og kan da potensielt misbrukes. Altså; kun det som er nødvendig for å ha nettsiden fungerende optimalt skal være åpent tilgjengelig. Alt annet må enten slettes eller flyttes til et område hvor det ikke kan nås.
  • Bruk captcha i skjemaer
    Skjemaer; da av typen kontaktskjemaer, bestillingsskjemaer osv, må sikres slik at de ikke kan fylles ut automatisk. Slike «Boter» som vi nevnte i sted kan også brukes til å misbruke slike skjemaer, når de finnes, og da eksempelvis sende ut spam fra nettside/konto. Dette går ut over de besøkende på to måter:
    1. Ved at ressurser på webhotellet kan bli brukt til kun dette, slik at besøkende ikke får lastet siden.
    2. Ved at misbruket er av en slik karakter at konto må suspenderes for å unngå videre problemer. Da blir siden i praksis tatt ned. På alt av skjemaer og annet hvor besøkende kan fylle ut info, bør man ha en ekstra sjekk på plass. Captcha er den mest brukte (og anbefalte) metoden for dette.

sikkerhet for nettsider

  • Passord som benyttes må være sikre
    Et sikkert passord er langt og satt sammen av både tall, små og store bokstaver og ander tegn. Lange passord kan også være setninger eller fraser sammen med tilfeldige tall/tegn som kan være enklere å huske. Passord er relevant både på kundesider hos oss, på webhotell, på epostkontoer og på selve nettsiden/installasjonen. De passordene som brukes mest er også de som er mest sårbare. Man bør bytte passord minst et par ganger i løpet av er år. Det bør heller ikke brukes samme passord noe sted.
  • Implementer ekstra sikkerhet hvor det er mulig
    For mange CMSer (WordPress/Joomla/Drupal) utvikles det egne plugins som fokuserer kun på sikkerhet. Her bør man undersøke litt hvilke behov man har, og installere det man mener passer best. Det finnes flere gratis alternativer som er gode nok, men har man en stor side som genererer mye trafikk kan det være verdt å betale for ekstra sikkerhet. Eksempel på en aktør med godt rykte rundt dette, som også tilbyr gratis plugin, er Sucuri.

sikkerhet for nettside

  • Sørg for å alltid ha backup (sikkerhetskopi) av innholdet
    Man bør alltid sørge for at man har backup (sikkerhetskopi) av innholdet. Kunder av PRO ISP har inkludert en av de beste løsningene som er i markedet for backup. Denne løsningen har de tilgang til direkte via webhotellets kontrollpanel (cPanel). PRO ISP tar backup av all data 1 gang pr døgn, og backupen beholdes i 30 dager. Selv om man har svært god backup inkludert i webhotellet hos PRO ISP så anbefales det alltid å ha en ekstra kopi lagret eksternt. Slik backup kan da være av typen tatt 1 gang pr måned, 1 gang pr kvartal osv, litt avhengig av hvor kritisk det er og hvor mye endringer man er villige til å miste.

Nettsiden er allerede blitt infisert, hva gjør man?

Hva om skaden alt er skjedd? Hva om kontoen din har blitt suspendert av oss? Mange kan oppleve dette, og det oppleves i de fleste tilfellene som svært urettferdig.

Alle hostingselskaper operer på samme måte når det gjelder webhoteller; mange webhoteller deler ressurser på samme server. Det er naturlig nok litt av opphavet til navnet; Serveren er hotellet, kundenes kontoer er hotellrom på dette hotellet.

Når en webhotelleverandør opplever at ressurser misbrukes må dette stoppes for å unngå at det går ut over alle andre på samme hotell. Tenk for eksempel at et hotellrom blir ekstremt mye besøkt, så mye at ingen andre hotellgjester kommer seg verken inn eller ut av sine rom. Da må det rommet som skaper problemer stenges for å unngå nettopp dette.
Det er ikke alltid at en konto stenges ned, men ser vi tegn til hacking/misbruk så kan vi gi beskjed direkte om dette slik at det kan utbedres.

Det viktigste i slike tilfeller er; Følg de instrukser som gis, og spør om tips/råd/veiledning dersom man er usikker.

Dersom vi oppdager hacking/misbruk, og enten gir beskjed om det eller suspenderer konto, så gir vi alltid beskjed om hva som må gjøres.
I de fleste tilfeller er hackingen såpass ny at man kan benytte seg av backupen som er inkludert i webhotellet. Prosedyren er da forholdsvis enkel:

  • Slett innhold på webhotellet som er relatert til nettsiden.
  • Gjenopprett innholdet fra en dato FØR hacking fant sted (evt den eldste tilgjengelige backup, ved usikkerhet)
  • Gjennomgå punktene over for å hindre videre hacking/misbruk, altså oppdater alt, slett alt som er unødveding, sikre alle skjemaer, bytt alle passord og implementer ekstra sikkerhet

Gjør man det som blir anbefalt, og sørger for å skjerpe rutinene med alle nevnte punkter, så er man så sikker man kan få blitt. Da vil både du som eier nettsiden, de som besøker nettsiden, og vi som serverer den fra våre servere være fornøyd.

Sikre informasjon mellom besøkende og server (SSL sertifikat)

Sikkerhetssertifikat er noe som blir mer og mer aktuelt å snakke om, og høyst aktuelt når det gjelder sikkerhet for nettsider. Vi har tidligere hatt innlegg både om «Hvordan velge riktig SSL sertifikat» og hvordan de store leverandørene planlegger å «tvinge» mer og bedre bruk av dette for å opprettholde sikkerheten på nettet («Google advarer: Sikre nettsiden din»).

Nå blir det noen litt tekniske ord og uttrykk her, men litt teknisk må vi bli for å forklare:
SSL* er en krypteringsprotokoll, eller et sett med regler som forteller en server/klient (nettsiden og besøkende) om hvordan kryptering av data skal foregå. Kryptering er da prosessen med å gjøre noe uleselig eller uforståelig for andre.

* I praksis er det TLS som benyttes, men SSL og SSL sertifikater benyttes i dagligtalen, så derfor også her.

Målet med SSL er altså at kun den som besøker nettstedet, og serveren/nettstedet, skal kunne lese data som sendes mellom disse. Det er da spesielt viktig når det er personlig eller sensitiv informasjon som utveksles, så som telefonnr, brukernavn, passord, epostadresser, kredittkortinformasjon og lignende; for vi ønsker IKKE at slik info skal kunne ses av andre.

sikkerhet for nettside

For å få til denne krypteringen bruker vi såkalte «nøkler», og når både den besøkende og serveren/nettsiden har samme type «nøkkel», er det kun de som kan lese, og kryptere, informasjonen. Et SSL sertifikat er da et sertifikat som bekrefter eierskapet til disse nøklene, og at de er autentiske og gyldige. Hvor nøyaktig og grundig den bekreftelsen er kommer an på sertifikatet, les mer om dette i «Hvordan velge riktig SSL». I praksis bekreftes at sertifikatet er utstedt av en gyldig utsteder, for det nettstedet man besøker, og at det er gyldig for nettopp dette.
Du som besøkende kan se dette ved at man får opp en hengelås i adressefeltet og at nettleseren rapporterer om at nettstedet er å anse som «sikkert».

Som vi nevnte i «Google advarer: Sikre nettsiden din» så er kryptering av informasjon høyst aktuelt siden det snart blir et krav. Man kan selvsagt unngå bruk av SSL sertifikater, men da vil besøkende bli advart når de går til siden din. Denne advarselen kan sammenlignes med å rope til kundene: «Jeg tar ikke sikkerhet på alvor». For de som ikke har fått nettsiden sin over på https er tiden definitivt inne for å ta grep!

Har du flere spørsmål etter å ha lest innlegget?

Som nevnt innledningsvis er sikkerhet et såpass stort tema man ikke kan dekke alt i en enkel artikkel. Likevel, følger man de råd som er gitt her, og har sikkerhet litt mer i «bakhodet» har man kommet et langt stykke på vei.

Leser du innlegget og sitter igjen som et spørsmålstegn? Er det ting du lurer på som ikke ble forklart eller besvart her? Eller ønsker du bare råd og veiledning? Ikke nøl med å ta kontakt med oss.

Epost: support@proisp.no
Facebook: https://www.facebook.com/proisp/

Please follow and like us:

Nettsider på Enterprise webhotell – del 1
Skrevet av: Jon Eivind Malde

I denne bloggserien vil vi se nærmere på kunder som har byttet fra våre standard webhotell til Enterprise webhotell og hvilke forbedringer dette har medført. Vi vil også gå nærmere inn på hvilke endringer som er utført i skript dersom det er gjort forbedringer i forhold til dette.

Første kunde* vi ser nærmere på har flyttet www.trondheim.no og www.trondheim.com fra våre vanlige webhotell med Apache webserver til Enterprise webhotell. Nettsidene er basert på Joomla og det er ikke utført noen endringer i oppsettet i overgangen. Nettsidene er offisielle nettsider for Trondheim hvor kort og godt det meste om Trondheim er presentert på en oversiktelig måte på både norsk og engelsk.

Per dags dato tilbyr ikke LiteSpeed egen plugin for Joomla for caching (som de for eksempel gjør for WordPress), men dette skal være på planleggingsstadiet. Det skal være mulig å sette opp LiteSpeed caching for Joomla som beskrevet her:
Joomla LSCache

Vi har ikke satt på caching som nevnt over og nettsidene hadde ikke aktivert noen form for caching i perioden da nettsidene ble flyttet.

For å best mulig vise forbedringene flyttingen har medført har vi foretatt målinger før og etter flytting via følgende:

Ettersom resultatene er tilnærmet like for nettsidene og kun den norske versjonen var tilgjengelig på no.trondheim.com har vi foretatt alle tester mot den adressen.

Før flytting til Enterprise webhotell

ab fra Norge

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking no.trondheim.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests

Server Software: Apache
Server Hostname: no.trondheim.com
Server Port: 80

Document Path: /
Document Length: 21846 bytes

Concurrency Level: 2
Time taken for tests: 77.225 seconds
Complete requests: 300
Failed requests: 0
Write errors: 0
Total transferred: 6728100 bytes
HTML transferred: 6553800 bytes
Requests per second: 3.88 [#/sec] (mean)
Time per request: 514.833 [ms] (mean)
Time per request: 257.416 [ms] (mean, across all concurrent requests)
Transfer rate: 85.08 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 5 5 0.1 5 6
Processing: 341 507 76.3 523 1063
Waiting: 323 480 73.8 498 1038
Total: 346 513 76.3 528 1068

Percentage of the requests served within a certain time (ms)
 50% 528
 66% 540
 75% 544
 80% 548
 90% 559
 95% 573
 98% 643
 99% 867
 100% 1068 (longest request)

ab fra Tyskland

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking no.trondheim.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests

Server Software: Apache
Server Hostname: no.trondheim.com
Server Port: 80

Document Path: /
Document Length: 21846 bytes

Concurrency Level: 2
Time taken for tests: 88.542 seconds
Complete requests: 300
Failed requests: 0
Write errors: 0
Total transferred: 6728100 bytes
HTML transferred: 6553800 bytes
Requests per second: 3.39 [#/sec] (mean)
Time per request: 590.282 [ms] (mean)
Time per request: 295.141 [ms] (mean, across all concurrent requests)
Transfer rate: 74.21 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 32 34 0.6 34 37
Processing: 377 553 119.3 562 1316
Waiting: 342 509 95.5 526 1058
Total: 411 587 119.3 596 1351

Percentage of the requests served within a certain time (ms)
 50% 596
 66% 606
 75% 612
 80% 618
 90% 670
 95% 801
 98% 1000
 99% 1136
 100% 1351 (longest request)

Pingdom Website Speed Test

Pingdom før flytting til Enterprise webhotell

GTMetrix

GTMetrix før flytting til Enterprise webhotell

Etter flytting til Enterprise webhotell

ab fra Norge

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking no.trondheim.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests

Server Software: LiteSpeed
Server Hostname: no.trondheim.com
Server Port: 80

Document Path: /
Document Length: 21846 bytes

Concurrency Level: 2
Time taken for tests: 35.143 seconds
Complete requests: 300
Failed requests: 0
Write errors: 0
Total transferred: 6735600 bytes
HTML transferred: 6553800 bytes
Requests per second: 8.54 [#/sec] (mean)
Time per request: 234.287 [ms] (mean)
Time per request: 117.144 [ms] (mean, across all concurrent requests)
Transfer rate: 187.17 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 3 3 0.2 3 5
Processing: 217 231 15.5 228 380
Waiting: 208 220 14.7 218 369
Total: 220 234 15.5 231 383

Percentage of the requests served within a certain time (ms)
 50% 231
 66% 234
 75% 235
 80% 236
 90% 240
 95% 247
 98% 273
 99% 325
 100% 383 (longest request)

ab fra Tyskland

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking no.trondheim.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests

Server Software: LiteSpeed
Server Hostname: no.trondheim.com
Server Port: 80

Document Path: /
Document Length: 21846 bytes

Concurrency Level: 2
Time taken for tests: 47.443 seconds
Complete requests: 300
Failed requests: 0
Write errors: 0
Total transferred: 6735600 bytes
HTML transferred: 6553800 bytes
Requests per second: 6.32 [#/sec] (mean)
Time per request: 316.284 [ms] (mean)
Time per request: 158.142 [ms] (mean, across all concurrent requests)
Transfer rate: 138.65 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 31 33 0.8 33 36
Processing: 269 282 10.4 281 386
Waiting: 237 249 10.3 248 353
Total: 301 315 10.5 313 420

Percentage of the requests served within a certain time (ms)
 50% 313
 66% 316
 75% 317
 80% 318
 90% 322
 95% 327
 98% 337
 99% 369
 100% 420 (longest request)

Pingdom Website Speed Test

Pingdom etter flytting til Enterprise webhotell

GTMetrix

GTMetrix etter flytting til Enterprise webhotell

Forbedringer som følge av flyttingen til Enterprise webhotell

Det som er verdt å merke seg i forhold til forskjellene mellom før og etter for ab testene i Norge er at gjennomsnittlig lastetid er gått ned fra 513ms til 234ms, noe som tilsvarer en reduksjon på ca. 54%. Vi ser også at forskjellen på laveste lastetid til høyeste lastetid er gått fra 722ms til 149ms, noe som innebærer at besøkende til nettsiden nå ikke vil oppleve store variasjoner i lastetiden som de kanskje gjorde før.

Pingdom og GTMetrix testene viser også at innholdet som lastes ned er redusert fra ca. 1.9mb til 1.0mb. Dette skyldes i hovedsak at det ikke var satt på noen form for komprimering på forrige server, mens LiteSpeed er satt opp til å automatisk komprimere innholdet. Vi ser også at den totale lastetiden ca. 37% for Pingdom og 21% for GTMetrix. Årsaken til at reduksjonen er lavere for disse enn for ab testene er i hovedsak at ab testene kun laster ned HTML koden som vises på siden, mens de 2 andre laster ned alle elementer (bilder, CSS filer mm.) som inkluderer det som ligger på webhotellet hos oss og på eksterne servere.

Ab testene er relativt like med unntak av avstanden mellom Norge og Tyskland både før og etter flytting. Vi har tatt med ab fra 2 lokasjoner kun for å bekrefte resultatene fra mer enn en lokasjon.

Oppsummering:
Vi kan slå fast at det har vært en markant forbedring på lastetiden etter flytting til Enterprise webhotell, samt at den varierer i mye mindre grad enn før. Reduksjonen på størrelsen på det som lastes ned er også redusert markant, noe som er svært fordelaktig i forhold til enheter som befinner seg på tregere nett. Alle forbedringene kommer uten at noen endringer er utført på eksisterende løsning. Dersom vi hadde aktivert Joomla LSCache hadde lastetiden vært redusert ytterligere.

Ønsker du å flytte til Enterprise webhotell?

Har du en nettside du kan tenke deg å flytte til våre Enterprise webhotell? Ta kontakt så kan vi være behjelpelige i forhold til flytting, benyttelse av cache i LiteSpeed (om aktuelt) og presentere resultatet dersom nettsiden benytter en løsning som ikke allerede er presentert.

*Grunnet etiske prinsipper og retningslinjer kan vi ikke omtale kunden nærmere, noe vi kommer til å gjøre for andre nettsider i kommende blogginnlegg så sant ikke samme omstendigheter gjelder.

Please follow and like us: