Fredag aften kl. 20.50, skete det der aldrig må ske i et datacenter: Vi mistede alt strøm.
Strømafbrydelsen betød, at alle UnoEuro servere og services, var utilgængelige fra kl. 20.50 og frem. De første services kom online igen kl. 23.34, og al drift var normaliseret igen kl. 01.03.
Læs videre “Incident report 29-07-2016: Strømafbrydelse i datacenter”
Vi er glade for at kunne tilbyde .NET Core 1 på alle vores ASP webhoteller.
Du kan læse mere om .NET Core her: https://dotnet.github.io/.
Vi er ved at gøre os nogle erfaringer med PHP7 og diverse CMS, her er en række problemer og løsninger.
Vi gør enormt meget ud af vores antispam og mail-setup, så det både er stabilt og effektivt.
Vores seneste tiltag er Greylisting
I den evige kamp imod spam, hackere og malware er vi ved at lave nogle ændringer og optimeringer af smtp.unoeuro.com.
Vi har opgraderet vores MS SQL servere til MS SQL Server 2014.
Det betyder kunder også bør opdatere deres Management Studio til version 2014: http://www.microsoft.com/en-us/download/details.aspx?id=42299
Du vidste det måske ikke, men vi har faktisk i mange år tilbudt en formmail.
Formmailen har været en nem måde at sende mail igennem HTML, uden at gøre brug af PHP eller ASP/ASP.NET.
Desværre er tiden løbet fra en central formmail. Pga. misbrug og vedligeholdelse, ser vi os derfor nødsaget til at lukke ned for denne. Som alternativ kan der gøres brug af mail funktionen direkte i PHP, eller i ASP/ASP.NET
Det er selvfølgelig også stadig muligt at finde en hosted formmail-service et andet sted.
Vi beklager evt. gener det medfører de få kunder der stadig måtte bruge vores formmail.
Hermed en kort status på vores PHP 5.6 projekt.
Vi havde oprindeligt lovet at opgradere vores servere i Oktober/November 2014.
Vi er i mellemtiden blevet meget bekymret for evt. problemer der måtte opstå for kunder midt i det vigtige julesalg. Dette taget i betragtning, og efter nærmere analyse af den nye platform, har vi derfor valgt at udskyde opgraderingen af eksisterende servere til efter jul. Formentlig Januar/Februar. Det vil også give os noget mere tid til at teste den nye platform lidt mere.
Vi er i øjeblikket ved at teste den nye platform sammen med nye kunder, pt. kører det som det skal, men lidt ekstra tid til test vil ikke gøre os noget :) Det er trods alt en kæmpe opdatering af vores platform.
Desværre er Ioncube folkene nådestløst langsomme til at understøtte PHP 5.6, derfor ser det pt. ud til vi må sænke forventningerne, og starte med at opgradere til PHP 5.5, indtil Ioncube kommer med på vognen. Vejen fra PHP 5.5 til PHP 5.6 skulle også være forholdsvis problemfri, sammenlignet med 5.3 til 5.5.
Vi håber det giver mening, og beklager selvfølgelig over for de folk sidder og venter på PHP 5.6 opdateringen. Der er ikke noget vi hellere vil end at køre 5.6, men vi vil også gerne sikre at den stabilitet, som vi er så kendt for, følger med.
Planen er derfor at eksisterende servere/kunder/webhoteller ikke bliver opdateret før Januar/Februar. Alle nye webhoteller vil snarest muligt blive oprettet på en PHP 5.5 server (med safe_mode off, osv.). Når Ioncube kommer med 5.6 understøttelse, så opgradere vi til PHP 5.6.
Kunder der virkelig virkelig gerne vil køre PHP 5.5+ hurtigst muligt, kan evt. kontakte vores support og blive flyttet til en PHP 5.5 server, når en sådan kommer i produktion. Dette indlæg vil blive opdateret når det sker.
Opdatering 9/11: Vores første PHP 5.5 server er nu i produktion.
Opdatering 10/11: Ja ok, så var Ioncube lige kommet til 5.6 – så vi kører nu 5.6 i stedet for 5.5. Alt er godt :)
Vi arbejder på højtryk på vores PHP 5.6 opgradering og vil derfor allerede nu gerne varsle vores kunder at vi i løbet af efteråret (oktober/november) forventer at opgradere samtlige PHP webhoteller til PHP 5.6 (fra PHP 5.3).
Den præcise dato følger.
Der er ingen grund til at opgradere til PHP 5.4, dernæst PHP 5.5 og så efterfølgende til PHP 5.6.
Det har altid været vores mål at tilbyde alle kunder nyeste version af PHP, ligesom vi tilbyder nyeste version af fx MySQL og ASP.NET. Det er vi glade for endelig at kunne komme tilbage til.
Nej, efter opgraderingen vil det ikke være muligt at bruge PHP 5.3, PHP 5.4 eller PHP 5.5 på vores webhoteller. Kun PHP 5.6.
Sørg for at opdatere dit CMS, eller kontakt din webmaster omkring det. Det samme gælder, hvis der imod forventning skulle opstå problemer som følge af opgraderingen.
Som udgangspunkt er der ikke de store bagudkompatibitetsproblemer.
Kunder der bruger CMS systemer og plugins til disse, bør sørge for at disse er fuldt opdateret – så burde der ikke opstå problemer.
Se følgende links omkring opgradering fra PHP 5.3 til PHP 5.6:
Vi har observeret der kan være nogle problemer med tegnsæt. Vores servere er sat til ISO-8859-1 pga. bagud-kompatibilitet. Ønsker du at køre UTF-8 (eller oplever problemer med tegnsæt) kan det være nødvendigt at sætte default_charset til UTF-8 med en .htaccess fil og linjen:
php_value default_charset "utf-8"
Du også tvinge tegnsættet til ISO-8859-1, skulle serveren senere blive ændret til UTF-8 (muligt):
php_value default_charset "ISO-8859-1"
Du kan lave disse ændringer allerede inden opgraderingen til PHP 5.6.
safe_mode er ikke længere eksisterende i PHP 5.6.
Ja, du læste rigtigt, de tider er bag os :)
Vi har altid sat stor ære i vores sikkerhed. Vi har brugt enormt meget tid på at sørge for vores servere er sikret selv om safe_mode forsvinder.
open_basedir er stadig aktiveret på vores servere. Det er muligt vi med tiden vil fjerne dette.
Ja, vi kan godt lide Apache :)
Vi kører dog ikke mod_php5 mere, men det bør ikke have nogen betydning.
.htaccess filer virker som de altid har gjort, det samme gør php_value og php_flag funktionerne.
register_globals og magic_quotes er fjernet i PHP 5.4 og frem, så hvis du har ‘aktiveret’ disse igennem en .htaccess fil, vil de ingen virkning have mere.
Nej, vi har ingen server-cache på vores servere, og har aldrig haft det. Vi mener cache er noget kunder selv skal implementere i deres CMS/kode.
Opcode cache er ikke aktiveret. Det er noget vi på sigt vil undersøge om vi kan tilbyde, det er dog ikke specielt webhotel-venligt. Såfremt vi aktiverer det, vil der komme nærmere herom.
Opdatering: Vi tilbyder nu DNSSEC.
Vi er begyndt at se en del problemer med DNSSEC og .dk domæner.
Til dem der ikke ved hvad DNSSEC er, så er det en måde at signere ens DNS Zone, så man sikrer sig at den navneserver som svarer for domænet, rent faktisk er den rigtige.
Det gøres ved at signere zonen på navneserveren med en nøgle og herefter give denne nøgle til f.eks. DK-Hostmaster. Når disse to så passer er alt som det skal være.
DNSSEC er meget udbredt på .se TLD’et, men er forholdsvis nyt på .dk – det er også forholdsvis nyt at verdens DNS resolvere (f.eks. Googles Public DNS) rent faktisk validerer på DNSSEC. Senest er TDC begyndt at gøre det.
Problemer begynder at opstå når man så redelegerer domænet til andre navneservere.
Så passer nøglen hos DK-Hostmaster ikke længere med nøglen hos den nye udbyder og så svarer domænet ikke korrekt hvis ens besøgende bruger en DNS Resolver som tjekker på DNSSEC.
På .se domæner løses dette ved at udbyderen (f.eks. os) fjerner DNSSEC fra domænet når man overtager domænet. Det er desværre ikke en funktion DK-Hostmaster giver os mulighed for, her skal domæneejeren manuelt ind i DK-Hostmasters selvbetjening og deaktivere DNSSEC på sit domæne.
Verisign har et værktøj du kan teste med her: http://dnssec-debugger.verisignlabs.com/.
Hvis der står “No DS records found for example.dk in the dk zone” så er der ingen DNSSEC på dit domæne.
For .dk domæner gøres dette via DK-Hostmasters selvbetjening. For de fleste andre TLD’er kan vi gøre det for dig. Vi drømmer om den dag .dk virker på samme måde.
Det kunne vi godt, men vi har valgt ikke at gøre det på nuværende tidspunkt. Vi mener DNSSEC giver anledning til en masse problemer hvis man ikke er sat ordentlig ind i det som domæneejer. Samtidig betyder DNSSEC en unødvendig komplicering af vores navneserverinfrastruktur. Vi vil dog formentlig understøtte det på et tidspunkt, når vi mener det gør mere gavn end skade. Selv om vi understøttede DNSSEC, skal en domæneejer stadig ind på DK-Hostmasters hjemmeside og ændre nøgleansvarlig ved en evt. redelegering, så der er stadig rig mulighed for at det giver problemer. Vi mener ikke det er det værd.
