Herojska podrška AdriaHost-a

Obaveštavamo Vas da smo se zadnjih dana bavili poboljšanjem sigurnosti i bezbednosti naših servera, i preduzeli nekoliko koraka u tom procesu, i time postigli da Vaše web prezentacije budu najsigurnije u regionu, a Vaš uptime 99.9%, kako web tako i mail servera. Da bismo to potvrdili od strane trećeg lica, pogledajte http://twitpic.com/1mwyo6 . Sigurnost deljenog hostinga je veliki izazov , jer mora da bude osiguran I sa strane servera, I sa strane klijenta. AdriaHost ulaže svaki napor da website svakog klijenta bude osiguran sa strane servera u najvećoj mogućoj meri.

Ovim putem bismo hteli da Vas obavestimo o novim načinima zaštite, kao i novim opcijama koje koristimo, da bismo ispratili zahteve savremenog tržišta:

Dani kada niste mogli da izmenite ili obrišete fajl/folder zbog nobody ownership-a su gotovi!

Naime, implementirali smo novi PHP handler, koji:
* izvršava PHP kao klijentski user/group
* PHP fajlovi imaju permisije 640 (skrivanje password od drugih accounta I slično)
* PHP folderi imaju permisije755 (umesto često zloupotrebljenih 777 permisija)
* Fajlovi/folder kreirani od strane PHP se kreiraju kao user/group (ne Apache ili neki drugi globalni user)
* Custom php.ini file per site (can add/remove security options)
* .htaccess fajl Vašeg sajta ne može sadržati php_flag i php_value vrednosti, iz sigurnosnih razloga.

Šta ovo znaci u praksi?

Glavna odlika ovog rešenja je što ce vaši folderi imati permisije 755, a php skripte permisije 644, tako da ne može doći do upisa u iste od strane neovlašcenih lica. Svaka druga vrednost foldera i fajlova sem 755 i 644, respektabilno rezultuje 500 Internal Server Error greškom, slično kao na slici ispod:

Ako vidite ovaj ekran, potrebno je da podesite permisije ili .htaccess fajl

Dve reči o permisijama:
1 ili x = execute
2 ili w = write
4 ili r = read

Najčešće ćete naići na instrukcije da podesite permisije na broj 755. Taj broj se dobija zbirom pojedinačnih permisija nad fajlom.
User = 7 – ovo je 1 za izvršenje, 2 za pisanje i 4 za čitanje = 7
Group = 5 – ovo je 1 za izvršenje, 4 za čitanje = 5
World = 5 – ovo je 1 za izvršenje, 4 za čitanje = 5

Permisije možete menjati uz pomoć FTP klijenta ili preko cPanela:

1.Ulogujte se na Vaš cPanel
2. Unesite parametre za pristup koje ste dobili prilikom otvaranja hostinga
3. Pod delom Files , odaberite File Manager
4. Čekirajte opciju Document Root for: , i kliknite na OK
5. Nalazite se u public_html folder, u njemu nađite željeni folder ili fajl
6. Štiklirajte folder ili fajl i u glavnom meniju, na vrhu strane, odaberite Change Permissions.
7. Unesite željene permisije, ili štiklirajte polja za Read, Write i Execute
8. Kliknite na Change Permissions.
9. Vašem folderu ili fajlu su promenjene permisije.

[VAŽNO] Podešavanje permisija kao na slici ispod (777) će rezultovati 500 greškom.

Implementirano rešenje se pokazalo kao najbolja sigurnosna mera u savremenoj hosting usluzi.

Danas većina hosting paketa sadrži konfiguracione fajlove, log fajlove, direktorijume koji se koriste za sadržaj drugih korisnika, a ponekad I fajlove vezane za sigurnost. To znači da , uz pogrešno podešene permisije , nalog može I upisivati u fajlove/foldere, a ne samo čitati iz njih (bez obzira na permisije, korišćenje chmod-a nije problem)

Navodimo par primera:

• Phpmyadmin sadrži fajl koji se zove congif.php koji može sadržati lozinke I slične informacije. Taj fajl može da pročita samo webserver. Bez korišćenja handlera koji smo implementirali, kada bi korisnik pronašao lokaciju tog fajla (relativno lako) , on bi mogao da pročita taj fajl, I pristupi poverljivim informacijama kao što su parametri za SQL bazu.
• Joomla CMS  sadrži fajl koji se zove congifuration.php koji može sadržati lozinke I slične informacije. Taj fajl može da pročita samo webserver. Bez korišćenja handlera koji smo implementirali, kada bi korisnik pronašao lokaciju tog fajla (relativno lako) , a on ima pogrešno podešenu permisiju , on bi mogao da pročita taj fajl, I pristupi poverljivim informacijama kao što su parametri za SQL, korisnika nad bazom, I slično.

Napomena: Naveli bismo da izmene koje smo izvršili rešavaju situaciju kada Joomla ili neki drugi CMS napravi fajl/folder , dodeli mu ownership, a korisniku bude onemogućeno da taj fajl/folder prepiše kroz FTP.

Neki korisnici iskoriste .htaccess fajl da postave PHP konfiguracione linije koda, u vidu php_flag var, ili php_value. Korišćenje php_flag ili php_value u htaccess fajlu će takođe rezultovati 500 Internal Server Error greškom.

Ovim ćemo pojednostaviti korišcenje naših hosting usluga i učiniti ih user-friendly u najvećoj meri.

Hteli bi da se zahvalimo svim klijentima koji su do sada bili uz nas, AdriaHost se brine o sigurnosti Vaših web prezentacija i pruža najbolju hosting uslugu u Srbiji.

Pokušavamo već par nedelja da napravimo ovaj roštilj ali nikako da uspemo – čas kiša, čas gužva na poslu. Konačno uspeh!

Ono što je sigurno je da je jedina sigurna stvar u prirodi – promena. Koliko god se ti trudiš da osiguraš server, zaštitiš ga, preduprediš sve moguće napade, nikada nije 100% sigurno. Uvek može da se desi neki problem. Administracija servera mora uvek biti proaktivna – pratiti logove, čitati o najnovijim security rupama, virusima i slično. Čak i širom web-a poznate firme za administraciju servera ne garantuju 100% da se vašem serveru ništa neće desiti, već garantuju da će učiniti sve da umanje rizik i da će brzo reagovati kada se nešto desi.

Evo šta se nama desilo prošle nedelje. Vrati se kolega sa pauze za kafu i ugleda sigurnosni mail koji javlja da se neko ulogovao kao Root na server sa IP adrese koja nije u firmi. Odmah, smo napravili hitan sastanak i porazgovarali o čemu se radi, ko bi mogao da bude (ponekad angažujemo jednu US firmu za određene poslove) međutim zaključimo da se radi o upadu na server.  Identifikovali smo koji je proces pokrenut i prekinuli ga (terminated). Uljez (aka Alien) je izbačen posle 12 minuta, ali to vreme je bilo dovoljno da skrip koji je pokrenuo ukloni index stranice sa oko 200 sajtova. Na desetak sajtova je osvanula arapska zastava, a na većini skript jednostavno nije stigao da završi do kraja i uklonio je samo index pa sajt nije bio vidljiv. Užas – teroristi!

Rešenje

Ok, šta da radimo sada? Prvo smo se bacili na analizu i pokušali da utvrdimo šta se tačno desilo. U tom trenutku počinju da zvone telefoni u prodaji. Korisnici pokušavaju da dobiju korisničku podršku iako ne pružamo korisničku podršku putem telefona (objasniću kasnije).

Utvrdili smo da napad ipak nije napravio neku veliku štetu, već da se radi o pokušaju defejsovanja (“defacing”). U kratko, to je kada vickasti napadač, upadne na sajt i zameni index stranice (homepage tj. frontpage), pobode svoju zastavu ili znak i  tako ispadne dasa. U Srbiji su napadači obično sa bliskog istoka ili sa Kosova i Albanije. I tako se na par desetina sajtova pojavila dotična arapska zastava sa početka članka.

Naravno da imamo backup svih sajtova. Mi pravimo nedeljni backup sajtova svih naših klijenata, iako svaki korisnik ima mogućnost da u cPanelu jednim klikom napravi bekap svog sajta ili da zakaže pravljenje backapa u neko vreme (recimo svaka 4 dana).  U Srbiji većina hosting kompanija nema backup jer to poprilično povećava mesečne troškove (zakup dodatnih hard diskova, bandwith i offsite oprema). Čuo sam gomilu tužnih priča, a imam i lično iskustvo sa jednom velikom hosting kompanijom. Priča je kratka – server je napadnut, sajtovi inficirani, pa obrisani i onda vam kažu “podignite ponovo sajt” – jer oni nemaju backup.

Ipak, tu je i mali problem. Backup je nedeljni i nije problem vratiti sajtove koji su napadnuti, ali backup je star 2 dana, što znači da kada vratimo te sajtove korisnici će imati poslednji zapis u bazi od pre 2 dana. Sobzirom da je napadač samo zamenio index sajta, nema potrebe da se restor-uje ceo sajt, nego bi mnogo bolje samo izvući index.htm iz backup-a. E, tu je mala začkoljica – za to nema automatske opcije već je potrebno sve raditi ručno i za svaki od 200 sajtova je potrebno 3-5 minuta po sajtu. Tu je razlika između naše usluge i usluge koju bi ste obično dobili. Da bi smo svih 200 sajtova vratili treba nam manje od 30 minuta, ali da bi smo uradili to na bolji način treba ceo dan. Odlučujemo se za kvalitetniju varijantu i krećemo.

Sobzirom da radimo sa poslovnim korisnicima, vraćanje 2 dana unazad podrazumeva – gubljenje porudžbina 2 zadnja dana, ili rezervacija, podataka korisnika koji su se od tada registrovali ili slično… Operacija uspešno završena, a sobzirom da je urađeno van radnog vremena od 01 do 05 ujutru, većina korisnika to nije ni osetila, ali je naš tim za podršku imao ne prespavanu noć. 

Ponosan sam na nivo usluge koji pružamo, pa sam zato potrošio ovoliko reči da objasnim o čemu se radi.

Šiptar i magarac

Ranije (pre 5 godina i pružanja hosting usluga), kada bi neko pronašao neku rupu u skriptu i deface-ovao neki od naših sajtova, mi bi smo uzvratili kontra-udarac na neki način, evo jednog vickastog kojeg često prepričavamo. Naime, obično u kodu stranice koju su postavili napadač poziva sliku koju je postavio negde na serveru, e tu sliku bi smo mi zamenili sa čuvenim video klipom “šiptar i magarac” na kome neki tip radi “nešto” sa magarcem, to sve snima njegov drugi i pričaju na albanskom. Na taj način bi smo praktično izmenili stranicu, tj. ostao bi njihov potpis, url i slično – ali umesto ponosne albanske zastave bi se pojavio video klip koji smo mi postavili. 

Ipak, sobzirom da su naši klijenti poslovni korisnici, nisu dozvoljeni nikakvi kontranapadi, hate-mailovi i slične stvari jer ne želimo da provociramo i izazivamo probleme. Zaludan čovek ima vremena na pretek.

Milion evra na shared hostingu

Ok, svi sajtovi vraćeni. Služba prodaje zove korisnike koji su bili uzrujani da ih obavesti da je problem od prethodnog dana rešen i tu se susrećemo sa najčešćim pitanjem – “Kako je moguće da se to desilo? Zar vaš server nije 100% siguran?”. Ne postoji 100% siguran server, postoji mogućnost da se maksimalno smanji rizik od napada i potreba da tu uvek bude neko ko će brzo i ispravno reagovati na problem.

I tada me zovu iz prodaje da mi prenesu kako bi direktor te i te firme da popriča sa direktorom jer nije zadovoljan uslugom i da će nas tužiti za odštetu. Preuzmem poziv i pokušam da objasnim čoveku o čemu se radi, međutim iz razgovora vidim da on ne razume ni malo tematiku već da jednostavno samo želi da nekome natrlja nos zbog toga što mu sajt nije bio vidljiv par sati.

“Jel znate vi da poslovanje naše firme prevazilazi milion evra ovog meseca i da ste vi to ugrozili? Ja ozbiljno razmatram da vas tužim za odštetu!”

Zamisli?! Firma koja vredi milion evra, kupi hosting od 100€ godišnje i očekuje da nikada nema nikakav problem. Najgore od svega je što je ta firma, koja inače ima i svoj IT sektor u početku uzela i server kod nas, međutim izračunali su da im je 200-300€ mesečno previše skupo i da je bolje da pređu na shared hosting. To zaista nije problem, ali onda ne treba mešati babe i žabe.

“Shared” hosting je “deljeni hosting”, tj. kada vaš sajt nije sam na serveru već delite prostor/cpu/memoriju sa drugim korisnicima servera. Jako je važno da imate dobru podršku i da neko redovno prati taj server kako bi većinu sigurnosnih rupa zakrpio. Nemoguće je zatvoriti sve sigurnosne rupe jer onda mnogi skriptovi (wordpress, joomla, forumi…) ne bi radili. Recimo jako je sigurno preći na php5, najnoviju verziju mySql-a, isključiti register_global funkcije… ali ako to uradite mnogi sajtovi neće raditi. Zato sigurnosna politika balansira na shared hosting serveru i traži način kako da pruži maksimum sigurnosti – ali da zadrži i najvažnije funkcionalnosti.

Sigurnost servera najčeše kompromituju neozbiljni korisnici – wannabe web dizajneri i klinci koji podižu forume, chat skripte i slično. Wannabe dizajneri (“i want to be” – želim da postanem) – često zbog neiskustva pišu loš php kod koji napadač lako iskoristi ili zaborave da updejtuju skript koji koriste (joomla 1.3 bez sigurnosnih zakrpa) što na kraju dovede do toga da im neko upadne na sajt. Sa druge strane Klinci (to je radni naziv kod nas), često postavljaju hate forume kojima provociraju neku kontra stranu (najčešće na osnovu nacionalnosti, vere ili sexualne orijentacije) što na kraju dovede do napada na server. Zato kod nas postoje posebni serveri za poslovne korisnike i za fizička lica što umanjuje šansu da se pomešaju ozbiljni i neozbiljni korisnici, ali to samo umanjuje opasnost ali ne može 100% da  garantuje. Na “deljenom” hostingu vi jednostavno delite sudbinu drugih, ali je Shared hosting  jeftino i prilično pouzdano rešenje.

Server – podrazumeva da ste sami na serveru, tada  je moguće zatvoriti mnogo više sigurnosnih rupa i šanse za napad su mnogo manje. Na serveru ste gospodar svoje sudbine, ali je to rešenje skuplje i potrebno vam je 150-400€ mesečno za zakup servera i administratora koji će ga održavati. Ovo rešenje je idealno za firme čije je poslovanje vezano za web i koje imaju obrt od nekoliko hiljada evra mesečno. Velika je greška, ako vaša firma pravi veliki obrt da tada dovedete u pitanje “posao od milion evra” zato što ste rešili da uštedite i zakupite hosting od 50€ godišnje – to je neodgovorno.

Zašto ne pružamo podršku putem telefona?

Često pitanje – ima više ugova ovde. Prvo, ne možeš pružiti podršku ako telefoni non-stop zvone jer korisnici često zovu i nekoliko puta za redom, a padne i po neka psovka. Drugo, tu je problem artikulacije zahteva – često korisnik ne ume da objasni, ne zna šta hoće da pita, ne zna svoj username, ne zna na kom je serveru, ne zna ime domena i slično. Kada nama stigne tiket kroz tiketing sistem odmah možemo da zaključimo o kom serveru se radi, kom hostingu i slično… Treće, tu je problem evidencije – da ne bude posle “ja sam javio tada, a vi niste reagovali na vreme…” ili “nisam to rekao, nego…”. U tiketu je jasno zabeleženo vreme i verbalizovan problem, kao i vreme odgovora naše podrške i njegov sadržaj. Broj tiketa je merljiv i jasno je vidljivo ko je preuzeo slučaj.

Dakle, moj savet koji važi bez obzira kod koga imate hosting je da napišete tiket. Dobro objasnite o čemu se radi i prikupite što više informacija kako bi pomogli podršci da vam pomogne.

Za šta vi pružate podršku?

Ovo je drugo pitanje na koje treba da obratite pažnju. Mi pružamo podršku za sva pitanja vezana za funkcionalnost servera i instalaciju skripti koje nudimo (cPanel i Fantastico). Obratite pažnju, mi garantujemo da će vam se skript ispravno instalirati ali ne pružamo podršku za sam skript (podršku za skript tražite od proizvođača ili od svog webmastera). Evo, par primera:

Primer 1 – ne radi mi Joomla

Ako vam Joomla ne radi, mi ćemo proveriti da li se ona ispravno instalira, da li je baza uredu, da nije u pitanju nešto oko funkcionalnosti servera, ali ne možemo vam pružiti podršku za modifikaciju i konfigurisanje samog skripta. To je posao vašeg webdizajnera ili webmastera.

Primer 2 – imam virus na sajtu

Vi ste dužni za održavanje i bezbednost svoga sajta. Mi smo dužni za održavanje i bezbednost servera. Drugim rečima, ako se desi da vam je sajt inficiran, vi ste dužni da ga sredite i zatvorite sigurnosne rupe. Ukoliko je skript znatno modifikovan pa je popravka teška, mi vam možemo vratiti iz backup-a stari sajt. Ipak, ni backup nije svemoguć. Desilo se par puta da klijent ni ne primeti da mu je sajt inficiran, već da mi to zaključimo tokom redovnih provera i obavestimo klijenta o tome. Zatim bi klijent tražio da mu vratimo sajt iz backup-a, ali to nije bilo moguće jer mi imamo nedeljni backup a sajt je inficiran pre tog vremena, pa je jednostavno backup-ovan takav. U tom slučaju klijentu jedino preostaje da podigne svoj backup ili da angažuje webmastera da mu sredi sajt.

Ukoliko je korisnik krajnje neozbiljan i desi mu se više puta da mu je hosting kompromitovan, ostaje suspendovan jer ne želimo da dozvolimo da ugrožava sigurnost servera svojim postupcima.

Eto, raspisah se ja ovde pod utiskom prošle nedelje.

Bio je običan radni dan u Adriahostu kada zazvoni telefon za podršku i javi se važan klijent: “Dobar dan. Zovem vas da proverim zašto meni ne radi veverica?”

“Izvinite? Nisam baš razumeo?” reče zbunjeno predstavnik Adriahosta.

“Zašto mi ne radi veverica?” – doda klijent,

“Kakva veverica?”

“Pa znate ona veverica za poštu” – odgovara klijent.

Naš kolega se okrenu ka nama i reče “Jel mi imamo neku vevericu? Jel neko zna o ćemu priča ovaj čovek?”

Nastade par sekundi tišine, a onda se dosetismo na šta je čovek mislio:

Squirrel mail – eto ti sad… nismo očekivali prevod na srpski.

btw – to je deo cpanel paketa za webmail (pregled elektronske pošte preko weba).

Svim radio stanicama dajemo besplatan audio streaming za 10 slušalaca u kvalitetu 64 kbps.

 Ideja je da probate kvalitet naše usluge, do 10 slušalaca ide na naš račun, a ako vam treba više lako se može proširiti.

Sada možete postati globalna Radio stanica. Audio streaming je tehnologija distribucije audio sadržaja putem interneta. Program koji emitujete radijskom mrežom možete distribuirati preko interneta i na taj nacin proširiti svoju publiku širom sveta.

Koliko se može proširiti? Nema ograničenja, cene su veoma povoljne (pogledaj ovde), plaćanje je preko računa, a vaš signal je dostupan globalno – svakome ko ima internet. Mi pružamo streaming servis najvećim beogradskim radio stanicama i po nekoliko hiljada ljudi prati internet radio u svakom trenutku. Vi brinite o svom poslovanju, a mi ćemo o tehnici i kapacitetu linka.

Ako ste zainteresovani kontaktirajte nas na +381 (011) 395 63 63 ili  preko emaila klikni ovde .

P.S. Da smanjim količinu pitanja – često se po internetu mogu naći ponude tipa “audio streaming – neograničen broj slušalaca mesečno”. Da ne bismo trošili vreme na objašnjavanja radi se o najobičnijoj prevari. Kada od provajdera koji ima ovakvu uslugu uzmete streaming servis, ne možete da proverite koliko slušalaca ima trenutno – tj. nema statistiku u realnom vremenu. “Neograničen broj slušalaca” je samo reklamni trik i siguran znak slabog kvaliteta usluge.

Evo primera – recimo da imate u svakom trenutku 100 slušalaca po 64 kbps. To znači da oni troše oko 6mb u sekundi protoka, a to je oko 385 mb u minuti, što opet dovodi do oko 550 GB dnevno, a to opet do 16.5 TB protoka mesečno. E, 16 TB ima svoju cenu, to svakako nije besplatno.

Svaki naš klijent ima svoj kontrolni panel sa statistikom u realnom vremenu. Uostalom, da ne davim više – probajte.

Povezivanje je vrlo jednostavno (pogledaj ovde) i ne treba vam više od sat vremena da krenete sa svojim internet radiom.

RNIDS je od ICANN-a zatražio produženje života yu registra zbog specifičnih problema koje ove izmene nose. Pored prestanka rada starih mail naloga gašenjem yu domena domaći web će pretrpeti udarac i u formi gašenja brojnih neažurnih backlinkova, mail adresa u mail listama, kao i pada google page ranka .yu stranica.

Iz RNIDS najavljuju da .yu neće gasiti ni nakon isteka ovog perioda dok od Internacionalnog registra ne dobiju zvaničan zahtev.

Po zvaničnim podacima RNIDS tranzicija na .rs završena je u maju 2009, a na staroj .yu adresi ostalo je još oko 4000 domena (broj registrovanih .rs domena trenutno iznosi oko 50.000).

Zainteresovani mogu pogledati zvanično obaveštenje o gašenju .yu domena, kao i RNIDS izveštaj ICANN-u u kome se traži spomenuto produženje roka zbog navedenih razloga.

U slučaju da Vam se sajt i dalje primarno hostuje na .yu domenu predlažemo Vam što skoriji prelazak na .rs ili neki od internacionalnih domena.

Produženje .yu domena webmasterima daje dodatno vreme  da prelazak na novi domen izvedu što bezbolnije prateći sledeći postupak:

- provera internih i izlaznih linkova u okviru samog sajta
- provera spoljnih linkova sa kojih saobraćaj dolazi na sajt, ukoliko je sajt i dalje linkovan na .yu domenu trebalo bi zamoliti druge webmastere da
- usmerenje sadržaja sa starog na novi domen 301 redirekcijom, o čemu smo već pisali na blogu.

Čak i ukoliko nemate .yu domen potrebno je proveriti mailove registrovanih korisnika i obavestiti ih o prelasku na .rs domen i mail adrese korisnika koji imaju .yu mailove promeniti na .rs mailove (u slučaju većih provajdera). Ovo je naročito bitno ako korisnici za logovanje na sajtu koriste e-mail adresu jer je uvek moguće da će samoinicijativno pokušaju da sajtu pristupe koristeći novi .rs mail.

Mnoge knjige su napisane o načinima pružanja efikasne tehničke podrške, ali ni jedan o načinima na koje dobru podršku možete dobiti. Jedno je sigurno, ljudi tokom kontakta sa predstavnicima ove branše prave česte greške koje umesto da ubrzaju proces rešavanja problema samo otežavaju osobi sa druge strane da pruži adekvatnu pomoć.

Svaki pad servera, nedostupnost sajta ili problem sa skriptom može biti izuzetno frustrirajući. Prva reakcija klijenta koji ima problem je obično udarac o sto, bacanje tastature i hvatanje za telefon. Ljutom čoveku je teško da svoj problem objasni na realan način i da shvati da u trenutku kada se problem dešava verovatno nije jedini u tom trenutku i da ukoliko je problem do pružaoca usluge postoje velike šanse da je tehničar sa druge strane već zatrpan zahtevima ljudi koji zovu da pitaju šta se dešava.

1. Upamtite da je sa druge strane osoba. Nije bitno gde je locirana tehnička podrška i na koji način joj pristupate sa druge strane je uvek čovek čija je dužnost da vam pomogne. Ukoliko se potrudite da problem iznesete na ljubazan način i možda se čak i zahvalite u napred očekujući brzo rešenje vrlo je moguće da će službenik sa kojim komunicirate bar podsvesno probati da tu zahvalnost što bolje zasluži.

2. Nikad ne pretpostavljajte da će vaš zahtev biti ignorisan. Iznenađujuće je koliko ljudi inicijalni kontakt umeju da ostvare porukom tipa “znam da ovo niko ne čita i da vas nije briga…”. Adriahost odgovara na sve zahteve koje uputite u najkraćem roku, a ovo će verovatno uraditi i većina drugih firmi kojima se obraćate ako im klijent sam ne oteža posao nepoštujući procedure.

3. Ne započinjite pretnjom. Uvek je lakše pomoći čoveku za koga deluje da mu je lako pomoći. Ukoliko sami stvorite utisak da je sa vama teško komunicirati tehničaru će verovatno razgovor sa vama zaista i postati noćna mora i biće mu teško da izvuče informacije koje su bitne za rešavanje problema ukoliko je dobar deo procesa tehničke podrške okrenut tome koliko ste ljuti jer imate problem i kako razmišljate da zovete advokata.

4. Pokušajte da obezbedite korisne, dobro opisane i bitne informacije. Vrlo često ljudi koji traže pomoć od tehničke podrške veći deo svog zahteva posvete manje bitnim informacijama, izostavljajući one ključne. Svaka bitna informacija koju dostavite službi tehničke podrške će smanjiti zastoje u rešavanju problema koji mogu nastati kada tehničar mora da vas kontaktira da bi dobio informaciju koja je bila lako dostupna i prvi put.

5. Ne pišite predugačke zahteve tehničkoj podršci. Što je vaš ticket duži to je teže iz njega izdvojiti relevantne informacije. Probajte da budete jasni, precizni i kratki.

6. Više ticketa ne znači više podrške. Ne otvarajte više ticketa za isto pitanje jer ćete umesto da odgovor dobijete brže obično jednostavno zatrpati tehničara zahtevima i otežati mu da u nekoliko ticketa prati tok rasprave. Uvek se držite jednog ticketa vezanog za vaš problem i jedino u njemu odgovarajte sve dok problem nije rešen.

Cilj svakog susreta sa tehničkom podrškom bi trebao da bude zadovoljan klijent sa rešenim problemom. Postavite sebe u poziciju da dobro prezentujete svoj problem i šanse da i Vi budete zadovoljni i Vaš problem rešen u najkraćem mogućem roku će porasti.

Ovi saveti su proizvod iskustva sa obe strane žice i mogu se koristiti u svakom kontaktu sa različitim vidovima tehničke podrške.

Prelazak na PHP5 je neminovan jer podrška i dalji razvoj za PHP4 prestaju u svetu, a ovaj postupak je takođe korak napred jer će omogućiti korišćenje novih PHP funkcija.

Bezbednost servera na PHP5 će biti povećana gašenjem mogućnosti da se pomoću include() funkcije učita kod sa drugog sajta preko URL-a što će omogućiti stabilan rad servera uz smanjenu opasnost od hakerskih upada čak i na sajtovima čiji kod nije bezbedno napisan.

Normalno funkcionisanje include() tačnije učitavanje lokalnih fajlova naravno neće biti izmenjeno.

Više informacija o PHP5 include() funkciji koju ćemo ugasiti možete pročitati na linku: http://www.php.net/include/

Ukoliko ste prilikom pisanja Vašeg sajta koristili neke od bug-ova koje poseduje PHP4, a ispravljeni su u PHP5 imaćete rok od narednih mesec dana da unesete potrebne ispravke da bi sajt pravilno funkcionisao. Od izuzetne je važnosti da izvršite potrebne ispravke inače ne odgovaramo za funkcionalnost sajta, samim tim Vas blagovremeno obaveštavamo o našem budućem postupku.

Prelazak na PHP5 ćemo pokrenuti od  01. maja 2009. godine.

Molimo vas da za sva pitanja u vezi sa ovim i za eventualne probleme koji mogu nastati u ovom procesu otvorite ticket i uputite ga službi tehničke podrške.

Google objašnjenje 301 redirekcije možete pročitati za više informacija prednostima 301 redirekcije u odnosu na ostale načine preusmeravanja, a mi ćemo se zadržati na implementaciji.

Da bi redirektovali saobraćaj sa starog domena možete kopirati sledeći kod u Vaš .htaccess fajl.

RewriteEngine On

RewriteCond %{HTTP_HOST} ^.*starisajt\.com$ [NC]
RewriteRule ^(.*)$ http://www.novisajt.com/$1 [R=301,L]

Ako Vam je potrebno da redirektujete samo jednu stranu možete upotrebiti kod :

Redirect 301 /staraadresastrane.html http://www.novidomen/novaadresastrane.html

URL adrese u kodu je naravno potrebno izmeniti da odgovaraju adresama na Vašem sajtu.

Telefoni se usijali a mailovi samo stižu što je skroz super ali treba me nekako hirurški odstraniti od telefona i tastature kasnije…

Ugrabili smo malo vremena da napravimo čestitku za NG…u moru kičastih idejnih rešenja (nabudžene jelkice, deda mraz sa rumenim obraščićima, itd..fuj) želeli smo nešto skroz gotivno da odradimo i samim tim smo moj dragi kolega dizajner i ja proveli dva sata googlajući… a svega smo se nagledali za to vreme – deda mraz u tangama, deda mraz sa deda mrazicama/zečicama (plavuše, crnke, ma ima ženski ima sve)…u principu svašta za svakog . Taman počeli da gubimo nadu kad se pojavi nešto što je tako u našem fazonu i samim tim je došlo do nenormalnog naleta kreativnosti što je rezultiralo sledećom pojavom:

Nama se sviđa tako da eto za sve do kojih naša čestitka nije stigla mailom!

Tužno konstantujem da je danas utorak…tužno jer je četvrtak tek prekosutra. Četvrtak je tradicionalno “Ćevap day” tj, dan kada ekipa iz AdriaHost-a ide na ćevape kod Nišlije…mmm Nišlija – pojam za sve ostale fast food kioske u Bg-u…po našem skromnom mišljenju…a neka vrsta životne misije nam je da sve isprobamo.

Srećni smo što nam je došao novi kolega – Ivan. Dečko neverovatnih sposobnosti, snalažljiv, pametan – u suštini, neko ko rešava probleme, što je definitivno profil jednog zaposlenog u AdriaHost-u.

Jedino što smo ustanovili kao manu je da dečko fizički totalno ne odgovara profilu jednog zaposlenog u AdriaHost-u.

U prilogu…

You can see the pattern here…

Ovom prilikom pozivam kolegu Ivana da nam se pridruži u našoj omiljenoj tradiciji sa željom da napredujemo iz nedelje u nedelju u svakom pogledu!