CityNetwork: Varningar och fel
 

Testade lägga upp en webbplats på City Network efter att ha hört gott om dom. Nu söker jag era åsikter då jag genast ramlade över en massa bekymmer.

Jag fick en vit sida i Firefox men HTTP 500 i Chrome. Detta (som alla vet) beror på ett PHP fatal error.

- Ingen errors.log existerar på FTP platsen.
- Ingen information finns hur man slår på felmeddelanden.
- En php_flag i htaccess genererar ett 404 file not found (?wtf felsidan finns inte?)
- En ini_set('display_errors', 'On') i scriptet ger ingen verkan.
- Sätta en egen errors_log genom ini_set ger ingen verkan.
- Supporten vet knappt vad jag pratar om.

Jag meddelar att det är viktigt och talar om vad jag provat. De återkommer och ber mig prova ini_set. Jag skrev precis att jag redan provat det. *suck*

Efter en vecka återkommer dom. Prioritet! *ironi*. De kan bekräfta att alla php fel är avstängda på servernivå och vare sig varningar, notices eller syntax errors kan visas. De tänker heller inte slå på det. Jag fick tipset att om jag inkluderar skripten i ett annat skript så finns möjlighet att error ska visas. Här tappar jag förståndet.

För mig upplever jag detta som lekstuga. Tekniker som trycker på knappar utan tänka på konsekvenserna. Jag vet att webbhotell kan ha varningar avstängda som standard. Men är det inte lite ifrågasättande varför man gjort det omöjligt att få fram felmeddelanden?

Jag har reklamerat mitt köp.

Jag hade också problem med liknande hos CN, men jag tror inte att det är specifikt för dom, utan Binero bör ha samma problem.

Det jag kom fram till då är att eftersom webbservern inte rapporterar felen själv direkt, utan filen måste parsas igenom så kommer felen inte visas om det blir fel vid header output.

Så troligen ligger ditt fel där.

Didn't know! Utgick kallt från att ni kör samma prylar more or less.

Det problem jag hade berodde på den förbannade WP-pluggen Timthumb som flippade ur och eftersom scriptet körs innan servern skickar ut några headers så syntes inget alls, även om jag slagit på all rapportering både till skärm och till fil.

Låter onekligen jättekonstigt, att man väljer att helt slå av det och att kunden inte kan slå på det. Vi får se vad johan1234 säger om det. Jag är av uppfattningen att man ska kunna justera 100% i php.ini specifikt för en kund, men jag vet att de flesta webbhotell inte kan/vill eller klarar av att ordna detta.

Man tappar verkligen hakan när man läser detta. Självklart ska man kunna se vad som går fel både genom errorlog och display_errors. Självklar ska man också kunna få unika inställningar i php.ini också om man vill. Trodde verkligen att alla webbhotell stödde en sådan grundläggande sak...

Nej, ni är verkligen inte unika :) Är tämligen övertygad om att felmeddelanden varit tillgängliga i CN:s gamla system men har knappt använt det nya än så det kan jag inte säga så mycket om.

Där skiljer sig nog uppfattningarna. Det finns ju inställningar som minnesanvändning och liknande som en enskild kund i delad miljö inte bör kunna påverka.

Att styra felrapportering vore dock trevligt.
Själv har jag nyligen svurit över att det som kund inte går att stänga av magic quotes.

Däremot bör ju supporten rimligen kunna åtgärda detta och hjälpa en kund.

Men det är ändå 2 skilda saker, vad en kund via tex. .htaccess kan ändra och vad som är möjligt att ändra av webbhotellet för kunden. Vissa inställningar ska naturligtvis kunden inte själv kunna sätta fritt, minnesanvändning osv, men vad jag menar är att det ska vara tekniskt möjligt för webbhotellet att ändra 100% av php.ini utifrån samförstånd med kunden och eventuellt ta mer betalt för högre utnyttjande.

njoy - först och främst vill jag säga hur djupt beklagad jag är över att det har tagit sådant tid för dig att få svar och få det löst.

Vi har valt att inte ha felmeddelanden aktiverat globalt. Majoriteten (som vi talat med) önskar det så och många vill inte att lite småfel i sin kod kan störa sidorna. Det kan också bli så att ett litet fel i någon av de större installationerna som WP eller annat skulle teoritiskt kunna ge fel i större skala vid en uppgradering eller liknande. Vi har alltså valt att låta de som kan utveckla och har behov - få aktivera det själva.

Självklart sätter du själv igång det på enkelt sätt och du har varit på rätt spår hela tiden. Men det verkar tyvärr vara så att du hade ett kritiskt fel i den filen där du aktiverar felmeddelandet. Därför kommer det inte igång. Jag tror Johan F nämnde det till dig i något av supportmailen - om än sent. Ser självklart gärna att antinget du tar bort det kritiska felet (så felrapporteingen kan komma igång) eller att vi får hjälpa dig göra det (borde vår support redan gjort proaktivt - med ditt tillstånd). Du kan alltså, precis som du säger, sätta igång både errors.log filen eller få direkta felmeddelanden - gäller bara att du inte har fel i just den filen där du sätter igång det. Något supporten självklart skulle funnit långt tidigare och du har helt rätt i att kritisera oss för detta.

Det finns inga ursäkter till att det tog tid - men vill ändå tillägga mer som förklaring - att några av våra experter på området är på semester och belastningen något högre generellt i semestertider. Något som vi av ditt problem kommer se till att det blir ändring på nästa sommar.

Vill också poängtera det kjette säger - det är absolut skillnader i hur Binero och City Network driftar (bland annat underliggande hårdvara) - även om kontrollpanelerna och funktionalitet är relativt lika. Vi äger dessutom vår huvudhall och har full kontroll på miljön.

Då verkar ju allt vara som det ska (utöver tidsaspekten då). Jag anser också att det är lämpligt att ha felmeddelanden avstängt per default såsom t.ex. Loopia och City Network kör. I produktion vill man ju precis som Johan säger inte ha några felmeddelanden.

Felmeddelanden av, men tillgång till error.log via ftp borde vara standard.

Det finns en lite hake i att göra så, det går, men det finns en viss risk att man toppar antalet filedescriptors, och hela webbservern dör. Det är av den anledningen man väljer att rotera ut accessloggarna med jämna mellanrum och inte i realtid.

Vadå relativt lika? De är ju exakt lika! Ni, Binero och Telia kör alla med Atomias kontrollpanel (Se http://www.atomia.com/references). En i stort bra kontrollpanel (Kudos till Sam som utvecklat den då det behövs alternativ till de som tidigare funnits) men också en kontrollpanel som tyvärr brottats med en hel del barnsjukdomar. Detta har ju varit ett skådespel som vi alla sett på nära håll i och med alla problem som Binero haft sista åren med implementeringen av den nya kontrollpanelen, något som även ni och Telia fått smaka på.

webbkonsulterna - Jag säger relativt lika för det är just vad det är. Vi har APIn som vi jobbar med och vi har lagt till olika tjänster på olika sätt. Utseenede är i stort sett lika också - men långt från exakt. Så igen - relativt lika. Även grunden är olika - dvs tekniken med hårdvara mm. Låt inte ögat lura dig. :-)

Visst har det funnits barnsjukdomar - och Binero fick en del smällar då de började ett år tidigare än vi. (OFF TOPIC RADERAT)

Har dock kört en del system genom tiderna och kan säga att jag än idag inte kört ett buggfritt system. Ropa på mig när du hittar ett... ;-)

Johan1234:
Om ni hade stöd för php_flag i htaccess skulle man inte behöva inkludera skriptet i ett annat skript. Vad är vitsen att slå på errors på skriptnivå om det ändå inte ger nån output vid syntax fel. Jag kan varken stärka eller dementera detta påstående men har för mig att ini_set läses in även om critical errors följer i filen, så länge den är före det kritsika felet. Nån kanske kan täcka in här.

De flesta skript ser ut enligt nedan.

<?php
require('config.inc.php'); // <-- här är behändigt att göra en ini_set

' // <-- syntax error
foobar(); // <-- fatal error
?>

Ni har av prestanda och säkerhetsskäl stängt av errors.txt på FTPn och man kan heller inte göra en override och få nån användaranpassad. Jag skulle säga det vore av säkerhet i åtanke att möjliggöra en egen errors_log. Vi som bryr oss och vill veta när nåt går fel är beroende av intern felrapportering.

Men lösningen ryska gumman (att inkludera nåt i nåt som är inkluderat i nåt) känns inte alls genomtänkt. Om den nu skulle fungerat.

Om jag fick bestämma en branchstandard själv så skulle det vara följande:

* display_errors off. Men kan slås på via både php_flag eller ini_set.
* errors.txt på FTP.
* Möjlighet till egen errors_log.

Håller med dig till 100%, det första är ju helt basic.

njoy - vill börja med att jag tar exakt din önskan ovan och kommer på torsdag eller fredag skicka dig ett privat meddelande om eventuella ändringar som vi gör i miljön - baserat på diskussioner här på kontoret. Jag är inte utvecklare men kan bara säga att dina tankar låter sunda rakt av och jag bollar med en hel del folk. Även tartareandesire har jag stor respekt för så jag skall ta alla punkterna för att ge raka svar som minimum. Visst finns det många aspekter att tänka på - bland annat säkerhet - men om så är fallet vill jag ge svar exakt varför vi gör något på ett visst sätt.

Att sätta igång via ini är kanske inte idealiskt men mycket vanligt. Att det inte funkar om man har kritiskt fel i just den filen - nej det är inte heller idealiskt. Är övertygad att vi löser det åt dig eller att du själv löser det dock. Men som sagt - återkommer med svar och eventuella ändringar som görs framöver - för att göra allt för att hitta en lösning som är bästa möjliga för dig och för alla våra kunder - utan att för den delen rucka på våra säkerhetskriterier.

Nu har jag rensat bort en massa irrelevant. Diskussionen handlar om felhantering av php i delad miljö och inte hur Binero, City Network med flera har byggt sina system. Vi kan gott nöja oss med att företrädare för de båda webbhotellen båda säger att systemen är baserade på samma kontrollpanel och därmed relativt lika om än inte identiska.

Det känns som att det lätt blir smutskastning mellan olika leverantörer och sådant hör inte hemma här.

Johan1234 just det här med långsamma svar får du ta til dig. Var i kontakt med er support ang en sida jag flyttat från Loopia till er men som bara blev vit. Jag kunde ej få fram något felmeddelande och er kvällssupport kunde ej hjälpa mig alls då deras kunskaper inte verkade så stora. De lovade att återkomma dagen efter när det fanns tekniker på plats. Detta var i april i år och jag har ej ännu fått något svar. Jag flyttade tillbaka sidan till Loopia ist.

Kanske beror på att domänen du har, fiskensimmar.se inte är registrerad?

Hej Jens - Tråkigt att höra att det blivit en miss i att återkomma till dig. Vi har som mål att aldrig låta någon vänta mer än 2 timmar på mail. Detta håller vi allt som oftast - dock vid olika problem eller vid eventuell nertid - drar det ofta iväg då vi inte klarar volymen. Nu i sommar har det också varit tillfällen (som du sett i tråden) som inte varit bra nog. Något vi absolut kommer se över.

När det gäller telefonsupporten så publicerar vi en rapport varje månad så att alla kunder kan se exakt vad som gäller i vår telefonkö mm. Vi har som mål att nå en sittid under 1 minut väntetid. Som du ser på rapporten nedan ligger vi på några sekunder över en minut de flesta månaderna - så inte riktigt målet men nära. I juni väntade den som väntade längst 22 minuter.

http://www.citynetwork.se/support/supportrapport-juni/

Hursom - som svar på din fråga är det du gick igenom inte accepterbart och ger oss bara mer råg i ryggen för att vi måste bättra oss. Stora massan får både kunnig och snabba svar - men det är inte ok att någon slinker emellan på det sättet du har gjort. Vi är ledsna för det och hoppas vi får chansen att visa vad vi går för en annan gång.

Lycka till!

Jag har konto hos er och är nöjd i övrigt. Era svarstider i telefon är mycket imponerande.

Roligt att höra Jens. Som sagt vi kommer ta än hårdare tag. Framförallt kommer nästa sommar har vi fler personer aktiva. Tack igen för feedback både JensS och njoy.

Lånar denna tråd lite eftersom det handlar om City Network.

Jag använder deras nya webbhotellstjänst vilket har fungerat bra prestandamässigt fram till och med måndag. Jag vet att de hade driftstörningar vilket står både på deras driftinfo och i det mailsvar jag fått från supporten.

Enligt driftinfo är felet nu åtgärdat men jag upplever fortfarande kraftiga prestandaproblem och har mailat supporten om det men undrar om någon annan också har problem eller är det bara jag vilket verkar lite konstigt.

/Tomas

Jag har upplvet samma sak men fick svar idag att det skulle vara ordnat.

Fick som svar att det vart problem med en switch samt nån process som hängt sig.
Mina problem började i mitten av förra veckan.

Be dem kolla om du har några php processer (om du kör php) som hängt sig.
Hoppas det löser sig.

Kan ge lite mer info här. Vi har under två dagar åkt på lite olika former av dos-attacker. Detta har vi tyvärr trott ha "ordnat" för att sedan se att det är tillbaka på lite annat sätt. Dvs det kommer och går. Vi har under de senaste 12 timmarna kommit närmare en lösning - men jag hoppas det i alla fall ger en indikation på vad problemet är. Vi hoppas fixa under natten helt.

Nu till info om det faktiska i denna tråden dock. Har fått diskutera och det är uppenbart att vi i vår nya miljö inte aktiverat allt som vi önskar och vi får tacka trådskaparen för att ha tagit upp detta för det leder till en förändring. Redan under nästa vecka kommer miljöerna gås igenom för att tillåta htaccess och ini att använda för att få igång errors. Vi kommer dock gå igenom noga vad som kanske ytterligare bör möjliggöras... Så tack igen och ändring kommer tack vare denna dialog.

Lyhördhet, det gillar jag !!!!

Roligt att höra AndersN. Vi återkommer med mer info när jag får den...

Kul att en tråd lett till förändring! :)

och nu är det inte längre några prestandaproblem heller.

/Tomas

Oj - en vecka blev mer än en vecka. Krävdes dock en hel del research på htaccess sidan.

Då är det fullt möjligt att använda php.ini för att göra inställningar (var till viss del innan också men vi har öppnat mer). De saker som man bland annat inte kan ändra är listade nedan samt standard värden.

max_execution_time = 60
memory_limit = 128M
max_input_time = 120
post_max_size = 120M
upload_max_filesize = 120M
enable_dl = Off

Utöver detta kan allt som kan ändras under runtime ändras. Allt utom det som står som PHP_INI_SYSTEM och 'php.ini only' i http://www.php.net/manual/en/ini.list.php

Vi kör som många av er vet med en lösning som körs över en massa blad med VMware i botten som är klustrad och lastbalanserad. I denna lösningen är det viktigt med isoleringen mellan kunder. Det är också så att en kund inte ska kunna ta ner en annan kund eller "äta" upp resurser som han/hon inte fått tilldelat. Allt för en stabiliare miljö dvs.

Detta gör att vi inte kommer tillåta dessa ändringar i htaccess för att hålla isoleringen mellan kunder på bästa nivå. php.ini gör man det således genom.

Syntaxen är precis som systemets php.ini

<parameter att ändra> = <värde>
Ex.
mysql_default_host = 127.0.0.1

Feedback?

Snyggt, vart placerar jag php.ini och jag antar att det här kommer att vara enkelt att hitta i er Wiki/Supportforum? ;)

Bra Johan, bevisar återigen varför jag väljer Citynetwork och Citycloud, även om det är små fel lite här och var ( som det gärna blir vid konvertering till ny panel) så får man gehör och hjälp.

abergman - bra fråga. Jag sökte själv och hittade följande - men känner att de bör gå igenom och få ett riktigt tydligt svar - så jag skall pusha för det.

http://forum.citynetwork.se/citynetw..._jag_fel_i_php

Fredrik - Riktigt roligt att höra! Tusen tack för de vänliga orden!

Är det inget som man sätter i htaccess menar du?
Jag brukar köra sådan override med htaccess på vissa hostar för att öka timeout och minne osv.

När det gäller php biten och htaccess så kan du sätta allt i php.ini - dvs som du kan sätta i htaccess. Så det du gör för php i htaccess kan du även lösa i php.ini.

Hejsan!

Kan inte skapa MySQL databaser i kontrollpanelen längre. Kan inte heller skapa e-postlistor eller använda auto installeraren utav script.

Här om dagen så laddade jag även upp ett script via FTP som inte alls fungerar på mitt CityNetworks konto men som funkar fint hos en annan webhosting som jag har.

Någon som haft liknande problem?

Mvh,
Douglas B

Har du kontaktat deras support och frågat om de vet varför?