[torpado]

Come ho già scritto il blocco ripe è stato spostato verso la vrack la notte tra domenica e lunedì (11/12 novembre) e di conseguenza le configurazioni di tutti i server che utilizzavano tali IP è stata aggiornata la stessa notte. Non sono state fatte successive modifiche alle configurazioni ma visto che le macchine usavano proxmox+drbd per erogare delle VM quando avete spento senza avvisarmi una delle macchine chiaramente i servizi sono ripartiti sulle altre macchine.

- primo incidente => #1190575 (12/11/12) h: 11:49:42 -> server in hack + logs

passano 2 giorni e nella vrack gira la stessa configurazione presente al primo incidente

- secondo incidente => #1192834 (14/11/12) h: 11:50:53 -> server in rupture poichè lo stesso identico problema si è riprodotto nel giro di 48h

Se invece ritenete che non ci sia stato alcun errore, che abbiate operato correttamente e che ciò che è avvenuto faccia parte delle normali prassi di OVH, allora mi vedo costretto a proseguire eventuali rivendicazioni in altre sedi allo scopo di tutelare la mia azienda e il rapporto con i miei clienti.

Riteniamo che non ci sono stati errori da parte nostra nella valutazione di questo caso ne nella configurazione della nostra infrastruttura.

Dettagli del caso :
L2 tunnels utilizzati tra i servers per joinare 2 networks nei nostri DC,
causando 4H di disservizio per 500 clienti.

[bago]

lo spunto di Angy è chiaro :

Contattami al supporto mettendomi in oggetto per scambiare i dettagli sulla configurazione e dettagli sullo stato della vrack al primo incidente : #1190575 (12/11/12) e sul secondo #1192834 (14/11/12)

Come ho già scritto il blocco ripe è stato spostato verso la vrack la notte tra domenica e lunedì (11/12 novembre) e di conseguenza le configurazioni di tutti i server che utilizzavano tali IP è stata aggiornata la stessa notte. Non sono state fatte successive modifiche alle configurazioni ma visto che le macchine usavano proxmox+drbd per erogare delle VM quando avete spento senza avvisarmi una delle macchine chiaramente i servizi sono ripartiti sulle altre macchine. Lo stato esatto non potremo mai saperlo perchè appunto avete spento la macchina: se aveste disabilitato la porta ethernet o altre operazioni similari avremmo potuto guardare cosa stesse facendo la macchina e come era configurata.

Se avete bisogno di fare qualche verifica specifica sul server, potete farla direttamente voi (il server che mi avete sospeso è lì, guardateci dentro e cercate quello che vi serve). Del resto siete voi che avete spento un server e che per questo dovreste aver raccolto prove sufficienti per stabilire che la colpa fosse di quel server, non io.
(Sarebbe piuttosto curioso che chiedeste a me di fornirvi delle prove in tal senso).

Detto questo a me a questo punto di analizzare quei server proxmox non mi interessa poichè ho migrato tutto su server CentOS senza virtualizzazione (visto che ho avuto l'impressione che proxmox in vrack con gli IP ripe lo utilizzino pochi clienti e la vostra documentazione sia lacunosa perchè non avete testato tale configurazione e quindi non voglio fare io da alfatester con le conseguenze del caso). Ora sto già perdendo un sacco di tempo per ripristinare ridondanze, backup e tutto quel che serve sui nuovi server e sinceramente di capire se ci sono problemi nelle configurazioni proxmox che proponete mi interessa poco visto che non la userò più.
Invece in altri topic ho fatto domande sulla CentOS (http://forum.ovh.it/showthread.php?t=4734 e http://forum.ovh.it/showthread.php?t=4735) che non hanno avuto risposte.

Sarebbe stato meglio cercare di dialogare prima dello spegnimento, o al più immediatamente dopo. Non a 2 settimane di distanza. Allora avremmo potuto capire insieme se il problema era sui miei server o sui vostri router e probabilmente avremmo potuto evitare almeno il problema del 14 novembre (che da quello che ho capito è stato quello più grave per OVH, nonostante la causa sembri essere stata la stessa). Con evidenti vantaggi per entrambi.

A questo punto per me la cosa realmente importante è capire se tutto ciò che è successo è da considerarsi un errore da parte vostra, o se al contrario reputate normale che un vostro cliente, a seguito di attività sistemistiche lecite, fatte seguendo le vostre guide di configurazione e sicuramente non riconducibili ad hacking o altre manomissioni intenzionali (e spererei che vista la situazione non ci siano dubbi su questo), si veda interrompere il proprio servizio SENZA alcun avviso preventivo (nonostante i vostri termini di servizio specifichino diversamente) e, cosa ben più grave, si veda di fatto sequestrare i propri dati per 2 giorni (cosa che non ha alcuna ragione di essere e che è il problema fondamentale di tutta la faccenda).

Se conveniamo che questo non è normale e che c'è stato un errore da parte vostra, posso ritenere quanto successo una eccezione e chiudere il discorso, nonostante i danni avuti.

Se invece ritenete che non ci sia stato alcun errore, che abbiate operato correttamente e che ciò che è avvenuto faccia parte delle normali prassi di OVH, allora mi vedo costretto a proseguire eventuali rivendicazioni in altre sedi allo scopo di tutelare la mia azienda e il rapporto con i miei clienti.

[raffo]

Almeno possiamo continuare o avere risposta anche se su OT?

:: edit :: prosegui pure sull'altro thread per evitare di fare ulteriore confusione, grazie

[torpado]

Spariscono i post da questo forum...

non spariscono i post, sono moderati e quelli OT spostati nella sezione adeguata

Questo thread ha un titolo preciso :
Re: vrack: 2 server spenti "Anti-hack" senza preavviso e nessun accesso ai dati

[Tipika]

Spariscono i post da questo forum...

non sono spariti - giustamente i post OT sono stati spostati qua http://forum.ovh.it/showthread.php?t=4740

(l'avrei fatto anch'io, fossi stato mod)

[elvincio]

Spariscono i post da questo forum...

[BiagioParuolo]

Mi associo.

[torpado]

...

Oltre a questo voglio farti notare che per il secondo server hanno effettuato una sospensione contrattuale con la sola motivazione "violazione delle condizioni contrattuali" (ricevuta dopo svariate ore di mie richieste dopo la sospensione), quindi anche volendo non avrei potuto riformattare tutto e ricominciare ad utilizzare il server.

lo spunto di Angy è chiaro :

Originally Posted by Angie Visualizza il messaggio
...
No one here know's how is done and what's inside and how is used, so no one can give you the answer.
So is perhaps an good idea that you design an plan and provide us the access etc.

So I hope this will help to see more clear.
I join the fight together with Torpado and I'm on his side to find out and to help.
But you must join us too.

Contattami al supporto mettendomi in oggetto per scambiare i dettagli sulla configurazione e dettagli sullo stato della vrack al primo incidente : #1190575 (12/11/12) e sul secondo #1192834 (14/11/12)

[bago]

@Tipika: nonostante l'email di motivazione della chiusura già avvenuta parlasse di "Anti-hack" mi pare che OVH stessa non abbia successivamente mai sostenuto che ci fosse un problema di "hacking" (ma magari mi sbaglio considerando che per quello che mi riguarda la situazione che Angie sostiene essere palese e banale a ma ancora non è molto chiara) ma piuttosto una sorta di configurazione errata (che però ancora non mi è chiara).

Oltre a questo voglio farti notare che per il secondo server hanno effettuato una sospensione contrattuale con la sola motivazione "violazione delle condizioni contrattuali" (ricevuta dopo svariate ore di mie richieste dopo la sospensione), quindi anche volendo non avrei potuto riformattare tutto e ricominciare ad utilizzare il server.

[Tipika]

Anche perché c'è il sequestro di due server dal costo non indifferente!
Inoltre questa policy che quando scatta l'allarme anti hack, si debba obbligatoriamente (senza appello e senza spiegazione!) ripristinare il server con ore e ore di downtime, mi sta un po' stretta (mettiamo che io abbia 200gb di dati: quanti mesi di upload ci metto per ricaricarli?)

[pftech]

Bago hai tutta la mia solidarietà al problema che ti è accaduto!!!

Utilizzando ormai da oltre un anno i servizi di OVH avevo compreso che fossero davvero professionali e fornissero servizi di altissimo livello, ma ora leggendo questa vicenda, inizio a non nutrire più tutta questa stima verso i servizi di OVH (vedasi anche come stanno gestendo la questione degli IP fail-over a pagamento che hanno dato comunicazioni discordanti e confusionali sulle evoluzioni del sistema!).

In bocca al lupo e per favore tienici aggiornati perchè penso di non essere il solo che desidera sapere come andrà a finire questa vicenda (certo che da parte di OVH fare un passo indietro e chiudere la questione in maniera "elegante" sarebbe meglio! Fareste di certo molta più bella figura visto che di preavvisi di spegnimento non ne avete mandati!!!).

[bago]

Hi,

I do not know what's 'complicated' here in this case and why you loss your time by talking about ... 'pay attention OVH has done this and this'.

My mother language is Italian and I bought an italian service with italian Term of Services, so I'll try to reply in english but I'm not responsible for translation issues. We can write italian otherwise.

Guy's that's only a very short story.

1) in your contracts are wrote that we can cut servers any time. Always if we MUST prevent risks, problems and downtimes in OUR network.
Note by: often we advise the customers and tell the that they not must do this or that or ..... '. But this is because we are cool, is not an obligation for us.

Not true. Not in the Term of services I accepted.

ARTICOLO 6 : RESPONSABILITA' DELLA OVH

OVH si riserva il diritto di interrompere la connessione ad Internet del Server noleggiato al Cliente, se questo
server costituisce un pericolo per il mantenimento della sicurezza della infrastruttura della OVH, in conseguenza
ad una violazione del server, o in seguito alla scoperta di una criticità nella sicurezza del sistema, o alla necessità
di aggiornamento del server.

OVH informerà preventivamente il Cliente, nella misura del possibile, con un preavviso ragionevole circa la natura
e la durata dell'interruzione, affinchè il Cliente adotti le misure appropriate. OVH si impegna a ristabilire la
connessione al momento in cui gli interventi di correzione siano stati effettuati dal Cliente.

I hope you can translate yuor own term of service in your language and understand that this is different from what you just wrote above.

2) The case of bago is simple.
He has an vrack. We do not know his buissness, his configurations, his usages, his services: we are not the administrators of his vrack.
But what we know is that his infra has caused 2 times a big network loop.
So our director has applied our contract and has stopped definitly this infra because he has sourced trouble on the mac learning for hundert of servers.

Simple case.

The point here is that we are wasting time by talking about this.
More important for bago until search 'my fault , ovh fault' is how this has happen, what's the solution, can we work together to solve it ?

But for this he has to send and complet plan and providing us: provide us FULL informations: what he are doing, what he has enable, what he run ( HA, DRS etc .... )

So we can check what on his vrack has sourced the problem. Seems he can not find out, perhaps we can, but for this we must cooperate and so perhaps we can reopen.

Time the discution still in the sense: 'my fault, your fault and OVH has not do ....' we will not go ahead.

I tried talking to you since my first server has been closed. I've been told I needed VIP support to have answers and in the ticket I've been replied that my server was suspended and no answer was due to me. So I've tried talking and I found a wall. There are a lot of logs about this, so I don't see why you're trying to report a different history. When I phone called the voice said the call was recorded (that's good in this case). Every contact has been logged or recorded, so there won't be problems telling who did what.

Torpado, my coworker is talking to me since cloture of the services each day about your case. I'm note sure that you know how many he invest his work for you.

I'm not responsible of your time. Your TOS says you have to contact me before closing my service and you have to provide me informations. You did not do that.. if you spoke with torpado for hours/days/weeks this didn't fix any of my issues. My first server has been closed on monday, the second on wednsday and I had to discuss 2 more days to have access to the data of the second server .. so 2 full days of requests in order to have my server rebooted in rescue-pro so to be able to look at the data (rescue-ftp in case of your standard proxmox ditro doesn't give read access to the system, please take note)

So you have on ovh italy an good ear: the ears of Torpado and he is there for you to start up the investigations. This guy is fighting in interne side for customers. But you must stop to ask US why, to discute on the forum: 'why' because the answer is in your infrastructure. No one here know's how is done and what's inside and how is used, so no one can give you the answer.
So is perhaps an good idea that you design an plan and provide us the access etc.

So I hope this will help to see more clear.
I join the fight together with Torpado and I'm on his side to find out and to help.
But you must join us too.

Nice day to everybody.

1) If you decide to shut down a server you MUST have some proof that the server is creating issue. So I'm simply asking that proofs.
2) Whatever happened, you violated your TOS, so I'm asking why and trying to understand why you are not trying to fix this at least commercially and instead one of my server has been left in suspended mode.

My main problem is not money, but to understand how OVH deal with this issues. My main issue was not the shutdown of the servers but not being able to access my data for 2 full days after this facts. This TOS violation created me the biggest issues with my customer and a wast of my (and my team) time recovering backups and then merging changes.

Now if you have technical things to say and want to give some final word about the STM_LOOP log (and what makes you so sure it was not a bug in the cisco or a configuration problem on your side) then I'm ready to talk about this. Otherwise if you only want to talk about administrative/contractual things then I pretend to talk in italian as I accepted italian TOS from an italian company and so we are subject to the italian law.

[Angie]

Hi,

I do not know what's 'complicated' here in this case and why you loss your time by talking about ... 'pay attention OVH has done this and this'.

Guy's that's only a very short story.

1) in your contracts are wrote that we can cut servers any time. Always if we MUST prevent risks, problems and downtimes in OUR network.
Note by: often we advise the customers and tell the that they not must do this or that or ..... '. But this is because we are cool, is not an obligation for us.

2) The case of bago is simple.
He has an vrack. We do not know his buissness, his configurations, his usages, his services: we are not the administrators of his vrack.
But what we know is that his infra has caused 2 times a big network loop.
So our director has applied our contract and has stopped definitly this infra because he has sourced trouble on the mac learning for hundert of servers.

Simple case.

The point here is that we are wasting time by talking about this.
More important for bago until search 'my fault , ovh fault' is how this has happen, what's the solution, can we work together to solve it ?

But for this he has to send and complet plan and providing us: provide us FULL informations: what he are doing, what he has enable, what he run ( HA, DRS etc .... )

So we can check what on his vrack has sourced the problem. Seems he can not find out, perhaps we can, but for this we must cooperate and so perhaps we can reopen.

Time the discution still in the sense: 'my fault, your fault and OVH has not do ....' we will not go ahead.

Torpado, my coworker is talking to me since cloture of the services each day about your case. I'm note sure that you know how many he invest his work for you.

So you have on ovh italy an good ear: the ears of Torpado and he is there for you to start up the investigations. This guy is fighting in interne side for customers. But you must stop to ask US why, to discute on the forum: 'why' because the answer is in your infrastructure. No one here know's how is done and what's inside and how is used, so no one can give you the answer.
So is perhaps an good idea that you design an plan and provide us the access etc.

So I hope this will help to see more clear.
I join the fight together with Torpado and I'm on his side to find out and to help.
But you must join us too.

Nice day to everybody.


Angie

[bago]

No, non ho sospetti, soprattutto perchè quel MAC address che riporti è quello di uno switch CISCO che non è mai stato "annunciato" dai miei server.

Visto che i server che mi sono stati spenti sono due e che il primo che mi è stato spento senza motivazioni non è stato sospeso ma solamente spento, potrebbe essere utile se voi aveste log anche di quel primo evento per vedere se ci sono cose comuni tra i due server. Inoltre avevo un terzo server Proxmox configurato allo stesso identico modo che invece non è mai stato spento o sospeso, ma che la notte tra giovedì e venerdì ho dismesso io dopo aver migrato tutto su un nuovo server CentOS per cercare di evitare ulteriori brutte sorprese.

Se avessimo IP e MAC address dei miei server che secondo voi hanno creato problemi potremmo andare più a fondo, anche se per farlo avreste dovuto evitare di spegnere il server ma solamente scollegarlo dalla rete, perchè già uno spegnimento rende più difficile capire. Comunque le configurazioni del server sospeso sono ancora lì.

Provo a ricostruire gli eventi a memoria, poi li ricostruirò per bene guardando log ed email.

Il venerdì ho spostato i server nella vrack, senza modificare le configurazioni.

Poi ho aggiunto la configurazione della vlan e dell'ip privato e verificato che i server dialogassero tra loro su questa rete, lasciando per il momento gli IP RIPE assegnati singolarmente ai singoli server.

La notte tra domenica e lunedì ho deciso di fare lo spostamento dei blocchi RIPE sulla vrack: ho notato queste cose:
- Una classe RIPE (quella più piccola) ha impiegato pochi minuti per essere reroutata sulla vrack.
- L'altra classe RIPE ci ha messo quasi 2 ore: non so se sia normale o se fosse già sintomo di un problema (non ci sono guide che spiegano cosa ci si deve aspettare quando si spostano dei server e delle classi ripe nella vrack e la "Procedura di migrazione senza interruzione" della guida dice "Sezione in corso di redazione" da sempre.

Prima di mattina i 3 server migrati funzionavano correttamente, compresi gli IP assegnati alle VM.

Lunedì in tarda mattinata mi trovo uno dei server spento senza motivazioni/preavvisi. Dopo un po' mi arriva l'email che mi segnala la condizioni di "Hacking" senza dettagli. Cerco di raccogliere informazioni sull'accaduto ma mi vengono date risposte generiche, troppo generiche per capire cosa potesse essere successo. Sono abbastanza sicuro che il server non sia stato hackato, ma ovviamente per averne certezza devo mettermi a guardare al contenuto e verificare un po' di log/configurazioni ed altro.

Nel frattempo le VM che venivano erogate dal server spento si riattivano sugli altri server (sono clonate con DRBD).
Passo 2 giorni ad investigare su questo "supposto" problema di hacking del mio server (senza avere alcun dettaglio da OVH) e il mercoledì mi trovo con un secondo server spento senza motivazioni.

Questa volta non riesco nemmeno ad avere accesso ai miei dati e contattando OVH mi sento solamente dire che devo comprare il supporto VIP o che non ci possono fare niente perchè ho violato le condizioni di servizio e il mio sistema è sospeso.

A quel punto vedendo che 2 macchine su 3 con proxmox ci sono state spente mentre le macchine centos non sono state toccate e non avendo alcuna informazione da parte di OVH ci organizziamo per migrare tutti i servizi su macchine centos, senza virtualizzazione. Ovviamente dovendo gestire anche l'emergenza di due server spenti e non riuscendo nemmeno ad ottenere accesso ai dati la cosa non può essere istantanea e quindi la notte tra giovedì e venerdì completiamo la migrazione dei servizi dell'unico server proxmox rimasto.

Tutto questo non l'ho fatto perchè pensavo che ci fosse un errore nelle nostre configurazioni ma solo come gestione dell'emergenza: se mi vengono spenti senza motivi 2 server e in comune hanno il fatto di essere proxmox e non riesco ad ottenere alcuna risposta o alcun contatto tecnico con OVH allora mi organizzo per gestire l'emergenza cercando di trovare strade che mi tutelino e quindi innanzitutto abbiamo cercato di ripristinare le repliche dei servizi che stavano sui server spenti e trovare il modo di recuperare dai backup i dati per i quali non avevamo più accesso.

Nel frattempo dovevamo gestire le chiamate di decine di clienti incavolati per i disservizi che purtroppo con 2 server spenti senza preavviso ci sono stati e anche gravi.

Per poter fare ulteriori ipotesi avrei bisogno di avere più informazioni sul vostro lato, su come è configurata la vostra rete, come gestite le VLAN, come gestite il routing, l'HA e quant'altro, le configurazioni dei router e switch coinvolti. Senza queste informazioni non sono in grado di investigare sul problema e fare ipotesi tecniche sull'accaduto.

L'unico log che avete è questo? Non avete altro?

2012 Nov 14 11:21:43 sw.178.33.236.2**
%FWM-2-STM_LOOP_DETECT: Loops detected in the network for
mac 0005.73a0.0000 among ports Eth101/1/32 and Po10 vlan
2148 - Disabling dynamic learn notifications for 180 seconds

2012 Nov 14 11:24:43 sw.178.33.236.2**
%FWM-2-STM_LEARNING_RE_ENABLE: Re enabling dynamic learning on all interfaces

2012 Nov 14 11:25:17 sw.178.33.236.2**
%FWM-2-STM_LOOP_DETECT: Loops detected in the network for
mac 0005.73a0.0000 among ports Eth101/1/32 and Po10 vlan
2148 - Disabling dynamic learn notifications for 180 seconds

Questo non parla di porte che vengono "disabilitate" ma solamente di dynamic learning disabilitato, che è appunto una protezione per evitare che lo switch di incarti quando rileva una situazione anomala e non dovrebbe quindi essere sufficiente a far morire lo switch (come dite che è accaduto) e non è una condizione che dovrebbe impedire il funzionamento del normale "switching".

Se è l'unico evento che avete mi sembra strano che per voi sia sufficiente per stabilire che c'è un problema di hacking sui miei server e che me li spegnete senza preavviso, ma passiamo oltre: avete almeno l'evento equivalente che ha portato lo spegnimento del primo server?

Lo switch che ha loggato questo evento è un nexus5000? Avete il risultato di uno "show spanning-tree vlan 2148" fatto durante l'evento?

Io ho controllato i log dei miei server e non ho trovato problemi che facciano supporre che ci fosse un problema di networking di qualsiasi tipo. Ho solo numerose segnalazioni di clienti che in quei giorni segnalavano rallentamenti nell'utilizzo dei nostri servizi.

[torpado]

Ok, mi interessa rendere leggibile la discussione, appunto per essere trasparenti soprattutto con chi legge da esterno il thread.

La situazione periocolosa che ha causato il down dello switch come da log è determinata da questa situazione :

Lo switch si "disabilita" perchè si trova in questa condizione :
devo ruotare il traffico per 0005.73a0.0000 , ma sta rispondendo 2 volte contemporaneamente!! Attenzione mi disabilito per sicurezza!!
---
Hai qualche sospetto su cosa nella tua configurazione abbia potuto generare questo evento ?

[bago]

Non abbiamo la necessaria visibilità sulla configurazione del servizio che hai applicato al momento del verificarsi dell'incidente. Non è ancora stata comunicata.

Nessuno me l'ha ancora chiesta, al contrario di quello che ci si aspetterebbe dalle vostre condizioni di servizio prima dello spegnimento di un server.

Al momento dell'incidente non era stata fatta alcuna configurazione da parte nostra. La macchina che mi avete sospeso aveva ricevuto la sua ultima configurazione la notte tra domenica e lunedì.

La macchina era stata messa all'interno della vrack e il blocco ripe era stato configurato secondo le vostre guida, abilitando quindi il proxy_arp in quanto senza questa opzione il server non riceveva i pacchetti destinati alle VM (per quanto possibile visto che non avete una guida per il mio caso specifico di vrack+proxmox+bloccoripe ma solo guide che prendono in considerazioni alcuni aspetti).

Le configurazioni sono ancora tutte nella macchina, per questo vi ho invitato a non cancellare la macchina, in quanto ritengo di non aver fatto nulla di sbagliato.

Partendo dai logs che segnalano i dettagli dell'evento (a dimostrazione che non ci divertiamo a chiudere i servizi a caso o per un problema sui nostri switch) e confrontandoci con il network team, abbiamo ipotizzato quale potesse essere stata la causa scatenante, preoccupandoci di escludere ogni nostro possibile errore.
Questo il motivo dei numerosi scambi qui e con il supporto.

I log non segnalano nessun dettaglio utile per quel che ho potuto vedere: non c'è nessuna informazione che spieghi il problema ma solo il riferimento ad un vostro mac address: come fate ad escludere che sia un problema sul vostro switch ed essere certi invece che il problema sia stato sul mio router?

Non può essere evidente una situazione per la quale non si hanno dettagli sulla configurazione che hai eseguito.
Negli scambi email non trovo una tua indicazione su quale configurazione sia stata applicata sulla vrack e lo scopo. Nessun dettaglio sulle operazioni eseguite lato vrack al momento del down dello switch.

Questo perchè come ti ho detto non ce ne sono state. Se invece andiamo indietro nel tempo direi che è quasi impossibile ricostruire esattamente tutte le configurazioni che possono essere state applicate al server. Posso darti la certezza assoluta che non ho fatto nulla che le vostre condizioni di servizio o le leggi o la prassi di configurazione dei server classifichino come errata.

Capisco che hai cercato una configurazione "particolare" sulla vrack della quale non conosco ancora i dettagli, ma anche che non ti sei preoccupato di informarti, prima di attuarla, se questa avesse o meno potuto causare dei problemi sulla infrastruttura a monte, ovvero sulla rete Ovh.
Una comunicazione in più con il supporto prima di applicare questa configurazione avrebbe evitato il peggio.

E' l'esatto opposto. Io non ho fatto alcuna configurazione particolare. Io ho seguito le vostre guide lacunose. Non c'è scritto da nessuna parte che prima di fare una configurazione io debba chiedere conferma che si possa fare anche perchè in questo caso dovreste garantirmi dei tempi di risposta e mi pare invece che stiamo parlando di offerte unmanaged.

Se io sapessi di aver fatto una configurazione pericolosa non sarei certo qui a discutere e lamentarmi di quello che è successo. Invece io penso di non aver fatto nulla di sbagliato e invece voi mi avete spento i server con motivazioni non chiare e, a quanto pare, ora chiedete a me le prove/motivazioni per cui voi mi avreste spento il server perchè quelle che avete voi non bastano a stabilire quale fosse il problema (e nemmeno che fosse causato da me).

Ribadisco per l'ultima volta che io sono estremamente convinto di non aver fatto nulla di sbagliato (e vedremo se riusciremo a verificarlo al momento opportuno) ma che sono anche estremamente convinto che anche se tutta questa faccenda dipendesse da una mia configurazione errata voi avete agito contrariamente alle VOSTRE condizioni di servizio, violandole in vari punti (mancato preavviso, mancate motivazioni, mancato accesso ai dati repentino)

Comunque visto che insisti/insistete sulla linea di cercare mie colpe significa che le nostre posizioni sono troppo distanti per trovare una soluzione amichevole e che quindi questo forum non è la sede opportuna per continuare a parlarne.

Se volete comunque documentare cose per l'utilità di altri che leggono questo topic sarò lieto di fornire tutte le informazioni in mio possesso.

[torpado]

Di ragione me ne sono state svariate:
1. Prima mi è stato detto che ho usato proxy_arp che non è consentito
2. poi mi è stato detto che avevo usato lo stesso IP su due server
3. poi mi è stato detto che ho usato lo stesso vmac su due server
3b. successivamente mi è stato detto che il MAC (e non VMAC): "Il mac che ha causato il problema : 0005.73a0.0000 , utilizzato contemporaneamente su più servers." ma come dimostrato si trattava di un mac dello switch di OVH e non di un mio server e quindi, per ora non è stato dato riscontro di un singolo IP o MAC che avrei usato in maniera errata.
4. poi mi è stato detto che ho usato O 2 IP con lo stesso mac o 2 mac con lo stesso IP
5. mi è anche stato detto che ho messo in comunicazione 2 VLAN diverse tra loro.
6. "un mac, interno alla configurazione attivata nella vrack e non visibile esternamente alla vrack, utilizzato contemporaneamente." (che sinceramente mi sembra una frase che in italiano risulta incompleta)

Il problema è che per nessuna di queste mi sono state date sufficienti informazioni/prove e ogni volta, facendo finta che la motivazione mi sia già stata data, me ne viene fornita una diversa (a meno che per voi quelle 6 frasi non siano equivalenti).

O meglio, il proxy_arp lo so che l'ho usato, ma del resto le vostre guide dicono di usarlo. Le altre 4 condizioni invece a me non risulta siano possibili secondo le configurazioni che io ho utilizzato e i log che mi sono stati riportati non dimostrano nulla, non forniscono alcuna informazione che dimostri che c'è stato un errore di configurazione da parte mia (la motivazione n.6 invece non la capisco quindi per ora non la contesto).

Quindi per quello che mi riguarda se non mi viene detto esattamente qual è la condizione (se ci sono degli IP del MAC coinvolti come minimo mi aspetto che mi vengano forniti come elenco gli IP e i MAC e gli orari, non credete?) io comincio a pensare che invece io non ho sbagliato nessuna configurazione e per un problema ai vostri switch mi sono stati spenti due server, senza preavviso, e ancora peggio, senza motivazioni. Il fatto che il problema sia stato scatenato dai miei server è tutto da dimostrare, come anche il fatto che la causa sia da imputare ad una mia violazione del contratto con OVH, di qualche legge o di qualche regola etica o morale che sia.

Non abbiamo la necessaria visibilità sulla configurazione del servizio che hai applicato al momento del verificarsi dell'incidente. Non è ancora stata comunicata.

Partendo dai logs che segnalano i dettagli dell'evento (a dimostrazione che non ci divertiamo a chiudere i servizi a caso o per un problema sui nostri switch) e confrontandoci con il network team, abbiamo ipotizzato quale potesse essere stata la causa scatenante, preoccupandoci di escludere ogni nostro possibile errore.
Questo il motivo dei numerosi scambi qui e con il supporto.

Comunque mi sembra di aver scritto fin troppo. Credo che la situazione sia evidente per tutti a questo punto.

Non può essere evidente una situazione per la quale non si hanno dettagli sulla configurazione che hai eseguito.
Negli scambi email non trovo una tua indicazione su quale configurazione sia stata applicata sulla vrack e lo scopo. Nessun dettaglio sulle operazioni eseguite lato vrack al momento del down dello switch.

Capisco che hai cercato una configurazione "particolare" sulla vrack della quale non conosco ancora i dettagli, ma anche che non ti sei preoccupato di informarti, prima di attuarla, se questa avesse o meno potuto causare dei problemi sulla infrastruttura a monte, ovvero sulla rete Ovh.
Una comunicazione in più con il supporto prima di applicare questa configurazione avrebbe evitato il peggio.

[bago]

No. La ragione della sospensione è già stata fornita anche nelle risposte precedenti, sia via email che nel forum.

E' stato causato un down dello switch a causa di un mac, interno alla configurazione attivata nella vrack e non visibile esternamente alla vrack, utilizzato contemporaneamente.

Ero in attesa da parte del network team di conferma dell'appartenenza del mac comunicato nei logs : è il mac della porta dello switch coinvolta.

Di ragione me ne sono state svariate:
1. Prima mi è stato detto che ho usato proxy_arp che non è consentito
2. poi mi è stato detto che avevo usato lo stesso IP su due server
3. poi mi è stato detto che ho usato lo stesso vmac su due server
3b. successivamente mi è stato detto che il MAC (e non VMAC): "Il mac che ha causato il problema : 0005.73a0.0000 , utilizzato contemporaneamente su più servers." ma come dimostrato si trattava di un mac dello switch di OVH e non di un mio server e quindi, per ora non è stato dato riscontro di un singolo IP o MAC che avrei usato in maniera errata.
4. poi mi è stato detto che ho usato O 2 IP con lo stesso mac o 2 mac con lo stesso IP
5. mi è anche stato detto che ho messo in comunicazione 2 VLAN diverse tra loro.
6. "un mac, interno alla configurazione attivata nella vrack e non visibile esternamente alla vrack, utilizzato contemporaneamente." (che sinceramente mi sembra una frase che in italiano risulta incompleta)

Il problema è che per nessuna di queste mi sono state date sufficienti informazioni/prove e ogni volta, facendo finta che la motivazione mi sia già stata data, me ne viene fornita una diversa (a meno che per voi quelle 6 frasi non siano equivalenti).

O meglio, il proxy_arp lo so che l'ho usato, ma del resto le vostre guide dicono di usarlo. Le altre 4 condizioni invece a me non risulta siano possibili secondo le configurazioni che io ho utilizzato e i log che mi sono stati riportati non dimostrano nulla, non forniscono alcuna informazione che dimostri che c'è stato un errore di configurazione da parte mia (la motivazione n.6 invece non la capisco quindi per ora non la contesto).

Quindi per quello che mi riguarda se non mi viene detto esattamente qual è la condizione (se ci sono degli IP del MAC coinvolti come minimo mi aspetto che mi vengano forniti come elenco gli IP e i MAC e gli orari, non credete?) io comincio a pensare che invece io non ho sbagliato nessuna configurazione e per un problema ai vostri switch mi sono stati spenti due server, senza preavviso, e ancora peggio, senza motivazioni. Il fatto che il problema sia stato scatenato dai miei server è tutto da dimostrare, come anche il fatto che la causa sia da imputare ad una mia violazione del contratto con OVH, di qualche legge o di qualche regola etica o morale che sia.

Il fatto che per ottenere accesso ai miei dati ci siano voluti più di 2 giorni è solo un'aggravante di questa faccenda.

Comunque mi sembra di aver scritto fin troppo. Credo che la situazione sia evidente per tutti a questo punto.

Speravo/pensavo/immaginavo che chiarite le cose OVH si sarebbe scusata per l'accaduto e mi avrebbe contattato per vedere come rimediare alla cosa (anche se ormai il danno è fatto), e invece ho continuato a ricevere solamente mezze risposte con estrema lentezza ed essere trattato come un criminale. A questo punto proverò con canali più formali.

[torpado]

Ma uno sbaglia una configurazione e gli viene sequestrato il server+dati a tempo indefinito?
Mi pare scandaloso

Nessun sequestro di dati : semplicemente lo standard della rescue FTP non era sufficiente per il recupero dei dati a causa della configurazione creata dal cliente.
I dati sono stati resi in seguito accessibili.

[Tipika]

Ma uno sbaglia una configurazione e gli viene sequestrato il server+dati a tempo indefinito?
Mi pare scandaloso

[torpado]

Ancora nessuna notizia?

Vi invito a non cancellare il contenuto del server in questione fino a quando non avremo tutte le risposte necessarie, in quanto può contenere prove utili. Io non ho la possiiblità di rinnovarlo (essendo sospeso da parte vostra il manager non me lo mette tra le opzioni) e fra 3 giorni scade.

Vorrei capire al più presto come si chiuderà tutta questa faccenda: mi sembra eccessivo che dopo 12 giorni dalla sospensione di un mio server io non abbia ancora una giustificazione a quanto accaduto e un riferimento alla norma contrattuale da me violata.

Vorrei evitare le vie legali perchè sono una enorme perdita di tempo per tutti e generano solo noie, ma non posso nemmeno aspettare risposte per mesi o continuare a ricevere risposte vaghe e contrastanti tra loro.

No. La ragione della sospensione è già stata fornita anche nelle risposte precedenti, sia via email che nel forum.

E' stato causato un down dello switch a causa di un mac, interno alla configurazione attivata nella vrack e non visibile esternamente alla vrack, utilizzato contemporaneamente.

Ero in attesa da parte del network team di conferma dell'appartenenza del mac comunicato nei logs : è il mac della porta dello switch coinvolta.

[bago]

Ancora nessuna notizia?

Vi invito a non cancellare il contenuto del server in questione fino a quando non avremo tutte le risposte necessarie, in quanto può contenere prove utili. Io non ho la possiiblità di rinnovarlo (essendo sospeso da parte vostra il manager non me lo mette tra le opzioni) e fra 3 giorni scade.

Vorrei capire al più presto come si chiuderà tutta questa faccenda: mi sembra eccessivo che dopo 12 giorni dalla sospensione di un mio server io non abbia ancora una giustificazione a quanto accaduto e un riferimento alla norma contrattuale da me violata.

Vorrei evitare le vie legali perchè sono una enorme perdita di tempo per tutti e generano solo noie, ma non posso nemmeno aspettare risposte per mesi o continuare a ricevere risposte vaghe e contrastanti tra loro.

[bago]

grazie.

[torpado]

Non so come leggere quel log, ma sicuramente "0005.73a0.0000" è un MAC address di un router cisco e non un MAC address di un mio server.

Sto chiedendo maggiori dettagli al fine di avere completa trasparenza sul log riportato.

Non avendo accesso diretto ai routers devo attendere un feedback da parte del network team.

[BiagioParuolo]

Caspita...non è la prima volta che tali apparati "Cisco" automaticamente notifica e causano problemi ai clienti...

[bago]

Non so come leggere quel log, ma sicuramente "0005.73a0.0000" è un MAC address di un router cisco e non un MAC address di un mio server.

[torpado]

...
Per finire, il server è rimasto comunque sospeso e quindi non potrò rinnovarlo. Cosa di cui mi frega poco, ma della quale non comprendo le ragioni. (quindi mai pagare i server più di un mese alla volta: si rischia solamente che te lo sospendano senza ragione e si tengano i soldi già pagati)

Voglio anche sottolineare che io avevo 3 server configurati allo stesso identico modo, 1 mi è stato spento lunedì (senza motivazioni) e poi mi è stata data la possiblità di accedere al rescue-pro, il secondo mi è stato spento mercoledì (sempre senza motivazioni) e questa volta senza rescue-pro. Quando ieri mi è stato detto che forse era per colpa del proxy-arp sono stato io a migrare tutti i servizi del terzo server su un nuovo server prima che loro me lo spegnessero e poi l'ho disabilitato. Quindi non mi è chiaro perchè non mi resituiscono il server "sospeso" e allo stesso tempo non si preoccupano invece di segnalarmi che c'è un terzo server che ha una configurazione errata. Comunque io preferisco prevenire e ho migrato tutto. Certo che se qualcuno mi avesse contattato, invece di spegnermi 2 server senza motivazioni, avremmo potuto risolvere il problema più velocemente e con meno danni per tutti.

Il disservizio di mercoledì, che a dire di OVH ha creato problemi ad altri clienti, poteva essere evitato se solo lunedì ci fosse stata comunicazione chiara da parte loro.

Ho inoltre imparato che nel pianificare una architettura la sfiga più grossa della quale tenere conto non è la rottura di due dischi contemporaneamente ma piuttosto l'intervento di un "admin OVH" che spegne e sospende macchine alla leggera. Se almeno facessero anche le riattivazioni con la stessa leggerezza non avrei perso una settimana di lavoro (mia e dei miei colleghi).

Il problema è dovuto al disservizio causato sul dynamic mac learning dello switch, questo ha causato il disservizio per tutti i clienti ad esso collegati.

Nel ticket incidente è stato riportato il log relativo :

2012 Nov 14 11:21:43 sw.178.33.236.2**
%FWM-2-STM_LOOP_DETECT: Loops detected in the network for
mac 0005.73a0.0000 among ports Eth101/1/32 and Po10 vlan
2148 - Disabling dynamic learn notifications for 180 seconds

2012 Nov 14 11:24:43 sw.178.33.236.2**
%FWM-2-STM_LEARNING_RE_ENABLE: Re enabling dynamic learning on all interfaces

2012 Nov 14 11:25:17 sw.178.33.236.2**
%FWM-2-STM_LOOP_DETECT: Loops detected in the network for
mac 0005.73a0.0000 among ports Eth101/1/32 and Po10 vlan
2148 - Disabling dynamic learn notifications for 180 seconds

Il mac che ha causato il problema : 0005.73a0.0000 , utilizzato contemporaneamente su più servers.

[bago]

Come aggiornamento, dopo numerosi scambi email, oggi alle 15.45 sono riuscito ad ottenere che il server fosse riavviato in rescue-pro così da poter entrare in SSH, montare le partizioni delle vm e le immagini contenute in esse. Così sono riuscito a fare una copia dei miei dati. Una operazione che richiede loro pochissimi minuti (forse secondi) mi ha richiesto 2 giorni abbondanti (lavorativi, non è Natale!).

Alla fine non ho ancora ottenuto una motivazione precisa delle cause della sospensione. Prima mi hanno parlato di "proxy_arp" non consentito, poi mi hanno parlato di "proxy non consentiti secondo il contratto" (che in realtà parla solo di IRC proxy vietato) poi di MAC address multipli, poi l'ultima è stata:

Dopo essermi confrontato su tutti i dettagli del problema con il network team, viene evidenziato l'utilizzo del medesimo MAC :

2 volte lo stesso MAC su 2 diversi servers

O

stesso IP con 2 diversi MAC su 2 servers

Ora, a parte che se hanno analizzato dei log dovrebbero sapere esattamente quale delle due condizioni si è verificata e non usare un "O", vorrei sottolineare che in ogni caso da una sospensione mi aspettavo come minimo che mi venissero citati IP, MAC e orari delle problematiche e non una risposta generica (tra l'altro diversa dalle motivazioni precedenti). Li ho chiesti, ma per ora non li ho ottenuti. Almeno ho ottenuto il rescue-pro.

Per finire, il server è rimasto comunque sospeso e quindi non potrò rinnovarlo. Cosa di cui mi frega poco, ma della quale non comprendo le ragioni. (quindi mai pagare i server più di un mese alla volta: si rischia solamente che te lo sospendano senza ragione e si tengano i soldi già pagati)

Voglio anche sottolineare che io avevo 3 server configurati allo stesso identico modo, 1 mi è stato spento lunedì (senza motivazioni) e poi mi è stata data la possiblità di accedere al rescue-pro, il secondo mi è stato spento mercoledì (sempre senza motivazioni) e questa volta senza rescue-pro. Quando ieri mi è stato detto che forse era per colpa del proxy-arp sono stato io a migrare tutti i servizi del terzo server su un nuovo server prima che loro me lo spegnessero e poi l'ho disabilitato. Quindi non mi è chiaro perchè non mi resituiscono il server "sospeso" e allo stesso tempo non si preoccupano invece di segnalarmi che c'è un terzo server che ha una configurazione errata. Comunque io preferisco prevenire e ho migrato tutto. Certo che se qualcuno mi avesse contattato, invece di spegnermi 2 server senza motivazioni, avremmo potuto risolvere il problema più velocemente e con meno danni per tutti.

Il disservizio di mercoledì, che a dire di OVH ha creato problemi ad altri clienti, poteva essere evitato se solo lunedì ci fosse stata comunicazione chiara da parte loro.

Ho inoltre imparato che nel pianificare una architettura la sfiga più grossa della quale tenere conto non è la rottura di due dischi contemporaneamente ma piuttosto l'intervento di un "admin OVH" che spegne e sospende macchine alla leggera. Se almeno facessero anche le riattivazioni con la stessa leggerezza non avrei perso una settimana di lavoro (mia e dei miei colleghi).

[EvolutionCrazy]

mette un po' di timore leggere di questi eventi

[bago]

Nella email che mi avete mandato non ci sono domande, ma mi dite solamente che il problema è l'uso del proxy_arp che non è consentito.

A parte che non ho trovato alcun documento o help che dica che proxy_arp non è consentito, quindi non vedo come possiate classificarlo come "pirateria" (come mi è stato risposto nel ticket), e comunque la cosa di cui mi lamento è che state violando il contratto in due punti:
1) il contratto dice che darete un preavviso prima di spegnere un server
2) il contratto dice che se spegnete un server darete accesso ai dati dello stesso per dar modo di sistemare il problema e invece a me avete dato solamente un FTP in sola lettura su una sola partizione che non contiene alcun dato. Quindi non mi avete messo in grado di capire o di sistemare il problema.

Tra l'altro preciso che i server che mi avete spento sono due, immagino per lo stesso motivo, ma solo uno dei due me l'avete sospeso "contrattualmente".

Se le nostre configurazioni hanno creato un problema ad OVH mi dispiace molto, ma dovete rendervi conto che non abbiamo fatto nulla di "male" (proxy_arp è perfettamente lecito altrove e sfido a dimostrare che sia una pratica di hacking/pirateria) e soprattutto non c'è scritto ne nelle condizioni di servizio ne nelle guide che ho potuto leggere su proxmox/ipripe/vrack prima di accingermi alla migrazione. Non ci avete dato alcuno strumento per capire che stavamo facendo qualcosa che per voi era sbagliato e non abbiamo fatto niente che sia riconosciuto universalmente come "sbagliato".

[torpado]

Sì sì, vedremo quello che dicono... per quello che so io loro si sono appropriati dei miei dati e mi inibiscono l'accesso ai dati stessi (volontariamente). Io lo chiamo furto, fino a prova contraria. E poi in italia esistono anche le clausole vessatorie.. ma valuterò se passare tutto all'avvocato in funzione di come prosegue la faccenda.

E comunque il contratto che ho accettato io prevede al punto 6 che io venga avvisato preventivamente prima della disattivazione di un mio server e la sospesione immediata può avvenire solamente in caso di violazione del punto 7, cosa che non mi risulta. Se anche fosse una violazione del punto 7 sono legalmente obbligati a dare una motivazione specificando l'articolo violato nel momento in cui vogliono sospendere unilateralmente un servizio.

Legalmente penso di essere molto tutelato e di avere ragione, ma di questa ragione e tutela me ne faccio ben poco se perdo i clienti.

Come ho già provveduto a comunicarti via email il servizio è stato dismesso per ragioni di sicurezza, compromesse dalla configurazione in oggetto realizzata.
Molti clienti hanno subito un down di servizio a causa di questa configurazione e quindi è venuta meno una parte di sicurezza che Ovh deve garantire sulla propria rete.

Sto comunque valutando tutti gli aspetti del caso con un admin e ti invito a rispondere all'email che ti ho inviato tramite supporto.

[bago]

Difficile dirlo senza andare in tribunale. Comunque una clausola che dice che ti possono spegnere un server senza motivi sarebbe vessatoria in quanto viola la consistenza del servizio stesso. Preciso che non sono un avvocato, dico solo cose che ricordo da conversazioni passate con il nostro avvocato (non riguardanti OVH, tra l'altro). E come scrivevo prima, tale clausola non c'è, motivo per cui è abbastanza evidente che OVH sta violando il contratto che io ho accettato (che non è quello del 2012 ma quello del 2010, per la precisione)

[BiagioParuolo]

"Quali sono le clausole vessatorie?"..mi interessano.

Ti ho inviato un'email.

[bago]

Sì sì, vedremo quello che dicono... per quello che so io loro si sono appropriati dei miei dati e mi inibiscono l'accesso ai dati stessi (volontariamente). Io lo chiamo furto, fino a prova contraria. E poi in italia esistono anche le clausole vessatorie.. ma valuterò se passare tutto all'avvocato in funzione di come prosegue la faccenda.

E comunque il contratto che ho accettato io prevede al punto 6 che io venga avvisato preventivamente prima della disattivazione di un mio server e la sospesione immediata può avvenire solamente in caso di violazione del punto 7, cosa che non mi risulta. Se anche fosse una violazione del punto 7 sono legalmente obbligati a dare una motivazione specificando l'articolo violato nel momento in cui vogliono sospendere unilateralmente un servizio.

Legalmente penso di essere molto tutelato e di avere ragione, ma di questa ragione e tutela me ne faccio ben poco se perdo i clienti.

[BiagioParuolo]

Il problema è che ti risponderanno sul fatto che dal tuo server o meno potevano partire attacchi e compromettere la rete ( vedi anche clausole nel contratto ).

[bago]

Ancora nessun aggiornamento.

Abbiamo lavorato incessantemente fino a poche ore fa per riprendere backup di lunedì ospitati fuori da OVH e rimettere su i servizi su nuovi server (ahime sempre OVH visto che sono vincolato alla classe RIPE che ho qui, per adesso) purtroppo perdendo quindi i dati di due giorni ma almeno ridando servizio ai nostri clienti.

Secondo me il comportamento di OVH è come minimo ingiustificabile, e ritengo sia anche illegale, ma questo lo vedremo a emergenza conclusa, visto che non mi piace prendere certe decisioni "a caldo".

Fino ad oggi sapevo che non potevo contare sull'assistenza in caso di problemi hardware e mi sono sempre tutelato creando dei cluster e ridondando i servizi: oggi so che non solo non c'è assistenza, ma che oltre al guasto hardware bisogna mettere in conto che OVH può spegnerti più server senza preavviso e senza giustificazioni.

Purtroppo con questi strumenti diventa difficile erogare un servizio di qualità ai miei clienti... ma vediamo.. magari OVH ha una reale giustificazione plausibile per tutto questo.

[BiagioParuolo]

Preoccupante la cosa? Aggiornamenti? La solita storia...paghi per trovarti con il coltello alla gola da parte dei clienti e dall'altro il vuoto assoluto e senza assistenza...

La stessa cosa successe a me..vedi post di qualche tempo fa... ho altri server in altro provider vicino geograficamente anche al telefono...-

[pftech]

Wow... che bello!!! Stavo giusto pensando che prima o poi prenderò una vRack per Proxmox, ma vista questa cosa faccio "indietro tutta" e me ne sto tranquillo tranquillo come ora...

E' curiosa sta cosa che hanno cessato il contratto senza motivazione specifica alcuna.... non penso possano farlo e presumo che tu gli possa chiedere i danni se non forniscono una motivazione specifica, concreta e dettagliata!!!

.... e il dubbio che giustamente hai cioè che Proxmox magari possa aver generato del traffico eccessivo e che loro lo abbiano classificato come hack può starci benissimo (comunque non eslcudere backdoor e altro perchè davvero è pieno di attacchi in continuazione in giro!!!).

In bocca al lupo e facci sapere come si evolve la situazione oggi...

[bago]

Dubito sia veramente un hack, molto fortemente. Se anche fosse mi sembra assurdo che OVH spenga i server e poi dopo 8 ore che fai domande ti dia una risposta di quel tipo. Se è un hack allora che forniscano delle informazioni. E inoltre, se anche fosse veramente un hack, che mi dessere l'accesso rescue-pro con il quale io possa andare a copiarmi i dati che voglio. Se anche il server fosse pieno di virus, backdoor, worms (che escludo categoricamente, ma supponiamolo comunque) che problema ci sarebbe per loro a darmi accesso ai miei dati? Fosse rotto potrei capire, ma il server è lì, acceso, con un FTP in sola lettura sulla partizione di boot (che non ha niente di importante)... non sai quanto mi senta preso per i fondelli.

[mac]

Quella risposta suona veramente male.

In ogni caso, non escludere in modo così categorico la possibilità di hack... se non hai avuto la possibilità di controllare in modo decente, il fatto che abbiano sempre funzionato bene non è una garanzia.

Io spero per te che si tratti davvero di un errore o che ti venga detto quello che è successo e il modo (concreto) di riparare.

Buona fortuna

[bago]

Siamo veramente fuori dal mondo. Dopo 8 ore che ho aperto il ticket mi viene risposto questo:

Salve,

i nostri amministratori hanno
messo fine al Suo contratto.

Cordialmente
Sabrina.

Ovviamente OVH lo sa benissimo ma per gli altri che leggono qui vorrei precisare che io sono una azienda e che con quei server ci faccio business e che su quei server ci sono servizi per i miei clienti. Sono CERTO che non c'è stato un hack e che non ci sono stati servizi illegali e nemmeno immorali. Che razza di risposta è?

OVH spegne i server senza preavviso alcuno, senza motivazione alcuna e dopo 8 ore di domande quella è la risposta?

[bago]

come aggiornamento, ancora adesso non ho ricevuto risposta al ticket e i miei server sono down (rescue-ftp limitato al solo ftp sola lettura della partizione primaria.. no altre partizioni, no ssh, no possibilità di cambiare netbook).

La cosa che vorrei ribadire è che prima mi hanno spento i server poi mi hanno aperto un ticket "Anti hack", quindi non ho avuto nemmeno il tempo di provare a guardare a cosa potessero riferirsi. Comunque in 3 anni quei server sono cambiati davvero poco e non ho mai avuto problemi di hack, l'unica cosa è che lunedì li ho spostati sulla vrack, quindi direi che è abbastanza ovvio che il problema sia la configurazione sulla vrack. Da notare che le guide ovh su come si configurano gli IP ripe in vrack ci sono per varie distribuzioni ma non per Proxmox, quindi ho dovuto fare di testa mia, per questo temo che il problema sia qualche configurazione che ho adottato, ma rimane il fatto che sono andate per 2-3 giorni prima che OVH me le spegnesse senza avviso.

[bago]

perchè, per quello che ne so fino ad ora, il motivo dell'antihack è proprio qualche configurazione di proxmox per fare andare le vm KVM. Gli stessi server sono sempre andati bene fuori dalla vrack.

[mac]

Indipendentemente da questo problema (visto altre volte in caso di hack), che è certamente fastidioso... non mi è chiara questa raccomandazione:

Evitate come la peste di prendere una vrack se usate proxmox.

perchè?

[bago]

Ho da poco spostato alcuni server proxmox su una nuova vrack.

Lunedì, senza alcun preavviso, mi trovo uno dei server spento e un ticket aperto "Anti-hack".

Mi dicono che devo risolvere il problema di hacking e poi potrò richiedere l'accessione. Mi danno un accesso FTP in sola lettura: come faccio a sistemare qualunque cosa nel server se ho un FTP in sola lettura?

Va beh.. era un nodo di un cluster, mi metto l'anima in pace e verifico che l'altro nodo stia funzionando.

L'unica ipotesi che mi viene in mente che possa aver creato problemi ad OVH è il proxy_arp che ho dovuto attivare sulle proxmox perchè gli IP associati alle VM "routed" funzionassero correttamente, così nel frattempo compro altri 2 server fisici sui quali installare i servizi ospitati dalle VM per precauzione.

Tra ieri e oggi preparo le nuove macchine, sono quasi pronto quando mi trovo spento anche il secondo nodo e dopo pochi minuti arriva anche lì l'email dell'antihack.

Chiamo l'assistenza italiana per chiedere che mi venga dato accesso rescue-ftp (completo, con anche l'ssh) al server in quanto con ftp sulla sola partizione primaria non posso fare niente (e il netbook è disabilitato per colpa dell'antihack) e mi dicono che devo rispondere al ticket antihack.

Rispondo al ticket che dopo 2 ore viene assegnato a tale Simona S. e dopo altre 3 ora ancora non si sa nulla. Non credo che per riattivare il netboot ad un server servano 3 ore.

E' normale che OVH spenga dei server senza preavviso alcuno? Al telefono mi dicono che prima di spegnere mandano almeno 3 email, ma io non ho ricevuto niente (e tutte le altre email di OVH le ho sempre ricevute).

Evitate come la peste di prendere una vrack se usate proxmox.

Se mettiamo insieme il down del NAS-HA di 8 ore di qualche settimana, fa, gli IP RIPE che passano da 0€ a 3000€/anno e questo problema nel cercare di avere accesso ai dati credo che il vaso sia pieno e che sia ora per me di cercare un altro provider.