Jump to content
Sign in to follow this  
arkangelus

Servizio Ricevuto da SEFLOW...

Recommended Posts

ciao,

non so se è capitato anche a voi di ricevere questo trattamento:

scopro sulla mia VPS Seflow dei virus, allora compro il servizio

Fanatic, nato proprio per dare meggiore supporto, insieme ad un upgrade

dello spazio disco.

Naturalmente vado di fretta perchè ci sono i miei clienti abbastanza inquieti,

e in tutta risposta mi dicono dall'amministrazione che la Procedura

richiede la verifica del ricevimento del bonifico, perchè il CRO non basta,

loro non si fidano.

Già, come se io non pagando li fregassi, tanto loro non possono staccare il servizio.

Forse dimenticano che hanno sempre loro, ahimè, il coltello dalla parte del manico.

E infatti, come temevo, l'upgrade disco tarda ad arrivare, nonostante mi dicessero che era stata fatta.

Su mio doveroso 'iput' si accorgono che, oopps, avevano aumentato lo spazio ad un altro utente...

 

Ma è solo l'inizio!

dopo che ho fatto la rebuild e faticosamente messo su tutti i siti tra sabato

e domenica notte,

Martedì su mia richiesta di assistenza per il servizio email che non va,

dopo avere dato la mia pw di root, guarda caso i siti

non sono più visualizzati, improvvisamente, senza che io avessi fatto nulla se non

un monitoring dalla shell.

 

Allora interviene Matteo Berlonghi, che mi manda email dicendomi che è tutto ok.

 

Magari. Tutti i miei siti puntano ad uno soltanto, con ovvio sconcerto perchè questa roba non si era mai vista.

 

Allora in tutta risposta mi accusano di avere fatto io dei casini di reinstallazione,

citando dei log mai allegati, mentre io ho le schermate dalla shell sulle operazioni

fatte, e ci sono alcune rebuild delle mod_rewrite di Apache che non ho fatto io,

ma fatte da un utente root dopo che ho dato loro la mia password.

 

In più, ciliegina, mi dicono che Apache 2.2 è ancora in testing,

e che io ho 'tentato un improbabile installazione' di un software instabile:

'Tale versione di apache è ancora in beta e infatti è la causa del suo problema coi siti.'

Ma allora vanno in contraddizione perchè proprio nelle loro guide c'è scritto

di scegliere Apache 2.2!!!!!!!!!!

 

ECCO LA GUIDA:

howto Installare DirectAdmin su CentOS .: SeFlow.it Knowledge Base

 

ed ecco cosa dicono in questa guida:

-------

Potete scegliere anche l' opzione 1, ma vi consiglio di scegliere quella indicata che vi permetterà di installare php 5 e Apache 2.2

Would you like the default settings of apache 2.2 and php 5 cli? (y/n): y

-----

 

MA ALLORA LO FANNO APPOSTA?

 

la cosa ridicola che ho pagato per il Fanatic,

e mi dicono che prima devo risolvermela io,

poi loro intervengono. Eh già ora pur pagando mi tocca lavorare e me!

 

A voi è capitata una cosa del genere ultimamente?

 

Ora che ho rifatto la rebuild scegliendo Apache 2.0, indvinate un pò......

i siti ancora giù, nonostante ns e dns corretti!

facendo nslookup infatti vedo il mio ip, solo che ci sono casini a livello di conf di apache, sicuramente!

Share this post


Link to post
Share on other sites

Due cose, senza entrare nel merito:

 

Apache 2.2 è assolutamente stabile, e lo è da un pezzo. Puoi vederlo qui: Welcome! - The Apache HTTP Server Project

 

Poi, è difficile che apache abbia un bug così idiota da far vedere un solo sito su tutti gli url.

 

Secondo me è una incompatiblità o un errore con directadmin, chessò, che carica il vhost di default al momento sbagliato.

 

O si sono confusi loro e hanno sbagliato a scrivere o hai interpretato tu male. Senza avere lo storico delle conversazioni io non so giudicare :D

Share this post


Link to post
Share on other sites

Apache 2.2 è assolutamente stabile, e lo è da un pezzo. Puoi vederlo qui: Welcome! - The Apache HTTP Server Project

 

Anche da qui:

Index of /dist/httpd

http://www.apache.org/dist/httpd/CURRENT-IS-2.2.12

 

Secondo me è una incompatiblità o un errore con directadmin, chessò, che carica il vhost di default al momento sbagliato.

 

Nessuna incompatibilità, lo installa DirectAdmin stesso.

E poi:

# httpd -V | grep "Server version"
Server version: Apache/2.2.11 (Unix)

 

E' più probabile un errore di configurazione.

Share this post


Link to post
Share on other sites

Ciao arkangelus,

 

scusa ma non ho capito una cosa, il directadmin ce l'avevi installato prima del rebuild del disco?

Non è possibile risalire ad un backup della conf di apache o di direct admin tuo o di seeflow di tempo fa della vps in questione? mai fatto uno snapshot?

 

Ora,devi superare il problema (penso che i tuoi clienti non sono felicissimi) devi capire a livello sistemistico quel che ti è successo e tamponare in qualche modo da solo o chi ha le competenze.

 

Buon lavoro

Edited by Bitstorm Srl

Share this post


Link to post
Share on other sites

Salve,

giusto per puntualizzare,. Nel contratto è ampiamente scritto che il servizio managed è applicabile esclusivamente se il VPS o server dedicato si trova in condizioni perp oterci lavorare sopra.

 

Quando lei ha telefonato per richiedere il fanatic perchè era stato compromesso le è stato detto "testuali parole":

 

"Non siamo certi dell' attivazione dell' eXtreme fanatic", dipende dal grado di compromissione, in quanto quando un server viene compromesso può capitare che siano state installate backdoor nascoste". Quando ho verificato ho trovato compromissioni risalenti ad almeno 3 mesi prima, il server era in condizioni disastrose e un ripristino era pressochè impossibile.

 

Le abbiamo quindi comunicato che per l' attivazione del servizio fanatic avrebbe dovuto ripristinarsi il VPS e solo una volta riportato in condizioni di piena funzionalità lo avremmo adeguato al servizio da lei scelto.

 

Così pochi giorno dopo ci contatta dicendo di aver ripristinato il tutto, ma che ha problemi nella posta. Il giorno dopo mi contatta telefonicamente dicendo che l' assistenza ha creato problemi e che non riescono a risolvere. Guardando i log scopro (e si nei log rimane traccia), che prima di richiedere assistenza aveva modificato manualmente i file di configurazione di apache. Al primo riavvio eseguito automaticamente da directadmin, lo stesso ha preso le nuove configurazione praticamente perdendo tutti i vhost possibili.

 

Non sapendo le sue modifiche quindi le ho richiesto, appunto perchè per attivare il servizio eXtreme Fanatic serve un vps funzionante di sistmare il problema.

 

Vedo spesso che l' utenza media si autogestisce i servizi credendo di saperlo fare, quando poi la situazione diventa tragica chiedono l'attivazione del servizio managed credendo che il tecnico possa fare dei miracoli. Purtroppo il ripristino di server compromessi, nel 90% dei casi richiede una completa reinstallazione e noi non possiamo prenderci l' onere di reinstallare, dopo poche ore che abbiamo preso in gestione quel server, tutti i dati dei clienti in quanto ovviamente non sapremmo cosa salvare, le configurazioni fatte, le personalizzazione eccetera.

 

Per apache 2.2 non ho indicato che il demone è beta, ma lo è il custombuild che prepara apache 2.2 con directadmin. La versione stabile al momento è la 2.0.

 

Purtroppo lei ha chiesto il servizio extreme fanatic quando aveva già superato il punto di non ritorno. Se riteneva che le sue conoscenze non erano sufficienti per la gestione del server avrebbe dovuto chiedere l' attivazione del servizio quando il server era in condizioni almeno dignitose. A questo punto saremo disposti ad attivarle il servizio fanatic quando avrà un vps completamente funzionante, non prima, in quanto già da la colpa a noi adesso che non è gestito, figuriamoci se dovessimo aiutarla per il ripristino, saremmo il capro espiatorio perfetto per la sua coscienza :-)

 

Resto a sua disposizione privatamente, possibilmente con toni educati evitando le minacce che han accompagnato le sue email fatte sia a me che a marco, visto che siamo esseri umani che lavorano e fanno del loro meglio per aiutare i propri clienti, ma è gradito almeno il rispetto e la cortesia.

Share this post


Link to post
Share on other sites

in ogni caso bastava fare un chmod 644 in

/etc/httpd/conf/extra/directadmin-vhosts.conf

evidentemente l'installazione di DA con Apache2.0 ha questo buggino.

 

Ora ne ho coperto un altro:

la configurazione base di Apache mi fa problemi se non c'è un file index.html

Anche se metto un index.htm non gli piace, con il risultato che nella pagina

principale va a vedere solo l'indx.html e non carica un index.php

 

Avete idea su cosa possa essere e soprattuto su quale file agire su CENTOS /DA?

 

grazie mille,

sono sicuro di risolvere, ormai ci siamo :)

Share this post


Link to post
Share on other sites
in ogni caso bastava fare un chmod 644 in

/etc/httpd/conf/extra/directadmin-vhosts.conf

evidentemente l'installazione di DA con Apache2.0 ha questo buggino.

 

Ora ne ho coperto un altro:

la configurazione base di Apache mi fa problemi se non c'è un file index.html

Anche se metto un index.htm non gli piace, con il risultato che nella pagina

principale va a vedere solo l'indx.html e non carica un index.php

 

Avete idea su cosa possa essere e soprattuto su quale file agire su CENTOS /DA?

 

grazie mille,

sono sicuro di risolvere, ormai ci siamo :)

 

Let me google that for you

 

(non ho resistito) :cartello_lol:

Share this post


Link to post
Share on other sites

arkangelus spiacente ma seflow ha pienamente ragione. Non conosco i modi con cui si sono posti per cui non li discuto e non li considero.

Parlo solo del discorso strettamente lavorativo dal punto di vista tecnico.

Un buon sistemista è in grado di mantenere un sistema stabili spendendoci in media un certo tempo X al giorno. Il costo di un pacchetto managed è appunto fatto al 90% sulla base di questo tempo.

Lavorare su un server compromesso è invece un lavoro la cui stima temporale non è stimabile e la cui soluzione non è certa. Quindi alla ditta il recupero di un sistema può costare 10 o 20 volte il costo del managed mensile. Se questo recupero è colpa sua, ossia una managed bucata, beh è un problema suo e se lo smazza la ditta. Ma su che base dovrebbe prendersi una mole di lavoro pari a 20X ed esser pagata X?

La soluzione, non so se proposta, è che il cliente paghi prima il tentativo (non sicuro) di ripristino e dopo il managed come 2 servizi distinti. Altrimenti pialla la vps (o da ordine di farlo) e fa partire il managed su una vps che il cliente non tocca più.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×