Jump to content

Search the Community

Showing results for tags 'tor'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Richiesta informazioni e consigli hosting
    • Domini e Registrazioni
    • Shared e Managed Webhosting
    • WebHosting - Primi passi
    • Server dedicati, colocation, connettività e scelta data center
    • VPS - Virtual Private Server
    • Cloud Computing e Cloud Hosting
    • Gestione Server Windows e Server Linux
    • E-mail e Managed Services
    • Pannelli di controllo e Hosting software
    • Professione Hosting Provider
  • Sviluppo Web e Tempo Libero
    • Io Programmo
    • Promozione, advertising e SEO
    • Off-Topic
    • Il tuo sito
  • Guide su hosting, domini, server, CMS e Cloud Computing
    • Articoli e Guide su hosting, domini e cloud computing
    • Annunci e News
    • Offerte Hosting - Provider HostingTalk.it

Calendars

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biografia


Località


Interessi


Cosa fai nella vita?


Il tuo Hosting Provider?

Found 2 results

  1. Ciao a tutti, premetto che nonostante quello che sto per scrivere, mi trovo relativamente bene con il provider citato. Sono un ex utente aruba con esigenze di hosting relativamente modeste, una community che ha integrato un sistema via chat irc con messaggeria privata, sistema di forum e strumenti analoghi, con utenza media di 20-30 uenti online e rari picchi oltre i 40. Dopo essermi trovato malissimo con Aruba, che aldilà dei convenientissimi pacchetti base per qualunque opzione o servizio aggiuntivo azzera la convenzienza del pacchetto base e NON dispone comunque di cronjobs, manco a offrirsi di pagarli in oro, passai a netsons. Per le mie limitate esigenze mi trovo relativamente bene. Ho tutt'ora un piano hosting multidominio e due piani hosting "semicondivisi" (adesso si chiama Hosting professionale PRO), hostati su tre server diversi, e sono quindi anche in grado di dare qualche elemento comparativo. Evidenzio subito una comodità offerta da netsons, ossia la possibilità di frazionare i pagamenti in rateizzazione mensile, una possibilità che per utenti privati e/o amatoriali o a caccia del risparmio, non è da poco. Nell'insieme il servizio è buono, per quello che ho potuto misurare in ormai 5 anni di affezionata clientela, gli uptime sono rispettati rispetto a quelli dichiarati. sempre in un'ottica non proprio entry-level ma sempre in ambito personale/amatoriale, non c'è paragone tra la chiarezza dell'area utenti di netsons e la confusionarietà del portale da cui sono fuggito. Anche questo è un elemento che probabilmente può fare la differenza per un'utenza entry level o poco più. Veniamo a quelle che considero le note dolenti, che considero tali soprattutto perchè NON documentate e non illustrate prima dell'acquisto, a partire dall'approccio standard di Netsons alla sicurezza. Un vecchio adagio tra sistemisti, recita "L'unico computer sicuro è quello scollegato dalla rete". beh sembra che quelli di netsons abbiano preso alla lettera questo antica dottina informatica. Episodio 1, le policy antispam. Come già spiegato, gestisco un sistema integrato con chat, mp, forum vari e altri strumenti di supporto per quella che è fondamentalmente una comunità di giocatori di ruolo. Ora, può capitare che un giocatore scriva la parola "casino" (a intendere "confusione" non "casa da gioco"), o la parola "poker" (ad esempio in una frase come "faccia da poker"). tadaaah... al momento di cliccare sul tasto invio del form che invia la frase in chat, o il messaggio privato, o l'intervento sul forum, scatta la policy antispam di netsons, che "riconosce" la parola chiave (poker, casino, ecc) e fa apparire all'utente colpevole una magnifica pagina bianca 403 Forbidden. Ho impiegato non poco tempo per rintracciare il problema e quando, a forza di tentativi (e di richieste di inutili controlli del MIO codice da parte dell'help desk di Netsons) è stato chiaro che erano delle parole chiave causare l'errore 403, mi è stato risposto che su ogni hosting veniva attivata una wordlist predefinita di parole proibite. E qui veniamo ad un primo problema: Sul server che ospita il mio vecchio hosting frazionabile multidominio ho potuto risolvere il problema tramite file .htaccess, disattivando la sola wordlist. Sul serve su cui è ospitato l'hosting semicondiviso, al contrario, mi è stato risposto che la disattivazione parziale non è possibile e che l'unica soluzione era disattivare l'intero modulo di sicurezza antispam. Non lo iscriverei fra i punti di forza e di eccellenza di netsons, il fatto che a seconda del server su cui si capita (casuale? si può scegliere?), siano possibili differenti possibilità di intervento "a basso livello" sulle configurazioni del server web. Episodio 2, il "famigerato" TOR Browser e la rete anonimizzatrice TOR Premetto che anche qui ho riscontrato differenze tra i tre server su cui sono ospitati i tre servizi hosting da me sottoscritti. Non mi dilungo sulla legittimità o meno di navigare in anonimato. Chiunque gestisca una community online sa bene che, perseguitati politici esclusi, il 99% degli utenti che pretendono di usare la rete TOR per frequentare stabilmente una community (specie community ad alto rischo di litigiosità tra utenti) lo fanno per ragioni che c'entrano molto poco con la protezione della propria privacy e sicurezza personale. Lo fanno il più delle volte nella speranza di minimizzare sanzioni regolamentari dovuto alla violazione di una o più condizioni sottoscritte al momento della registrazione e di poterlo fare "in anonimato". Troll e spammer, per dirla fuori dai denti. Per questa ragione sul primo server (hosting frazionabile) e sul primo semicondiviso acquistato, usato per lo sviluppo e il collaudo della mia community, avevo predisposto un banalissimo controllo sulle connessioni da rete TOR, usufuendo di un tool messo a disposizione dalla rete TOR stessa. Funzionava alla perfezione, lasciando visibili anche da rete TOR le parti di sito "esterne" e consultabili senza registrazione, e bloccando con un bel "marameo" i tentativi di registrazione e login nell'area per gli iscritti. L'utente usante una connessione TOR veniva semplicemente reindirizzato sulla "pagina marameo". Tadaaahh. Arriviamo al terzo server. Lì se ti colleghi usando TOR, non vedi proprio il sito. Timeout infinito finchè non appare la pagina bianca che classifica il sito come "irraggiungibile". Chiedo spiegazioni all'help desk e (dopo la solita richiesta di default di effettuare una serie di inutili controlli sul mio codice), mi viene risposto che le connessioni TOR vengono bloccate da default, per gli stessi motivi per cui io volevo bloccare gli accessi all'area riservata agli iscritti. Ma... scusate un momento: Potrò decidere io quali parti del sito rendere inaccessibili a un probabile spammer o troll che usa TOR per nascondere il suo IP di provenienza? No, ci pensa Netsons, rendendo irraggiungibile di default il sito da parte di chiunque esca con un IP appartenente alla rete TOR. Chiedo se sia possibile modificare questa impostazione e mi viene risposto di no. Allora, scusate, perchè la cosa non viene chiaramente illustrata prima dell'acquisto? Nel mio caso non cambia nulla (anzi mi risparmia codice), ma se avessi voluto mettere in piedi un sito di informazione rivolto ai cittadini di paesi nei quali la censura politica li obbliga ad adottare ogni possibile misura a tutela della loro privacy, avrei acquistato inutilmente un pacchetto da netsons, senza essere informato che il mio sito sarà irraggiungibile proprio per l'utenza a cui mi rivolgo. E, anche qui, devo registrare la CASUALITA' di questa condizione, dal momento che su alcuni server il filtro è attivo e su altri no. Episodio 3, Whitelist vs Blacklist: la FOLLIA lavoro come consulente informatico entro una nota compagnia internazionale di assicurazioni e quando ho un momento libero, a volte mi colego al mio sito, giusto per buttare un'occhio in orari nei quali la maggior parte dei moderatori è al lavoro o in università. A seconda dei casi, la nostra rete aziendale, che è strutturata a livello europeo, mi fa "uscire" con connessioni che apparentemente partono da Parigi, da Amburgo, da Bruxelles o da Londra. Un giorno passo il link del mio sito a un collega della stanza affianco, giusto per farglielo vedere. Due minuti dopo mi richiama e mi dice "guarda che il sito è giù". Sulle prime penso a un disservizio temporaneo, perchè mi collego e anch'io vedo solo la pagina bianca prima che il browser vada in timeout e mi informi che non è riuscito a raggiungere il sito. Combinazione però mi viene detto per telefono che il sito non è affatto "giù". infatti faccio la prova da cellulare e con lo smartphone il sito risulta raggiungibilissimo. uhm... che sarà successo? Contatto l'help desk e dopo varie spiegazioni mi viene detto che il mio IP (in quel momento geolocalizzato a Bruxelles) risulta bloccato per ragioni di sicurezza. Mia faccia davanti alla notizia ---> O___O Comunque la signorina dell'HD si affretta ad assicurarmi di averlo sbloccato e infatti il sito mi torna nuovamente raggiungibile. Peccato che il giorno dopo il problema si ripete e... tadaaaaahhhh... spiegato l'arcano, il giorno dopo avevo un IP diverso, sempre appartenente allo stesso range, ma con la tripletta finale diversa. A quel punto mi "inalbero" un pochino e contatto di nuovo la signorina dell'help desk, chiedendo spiegazioni. E, dopo qualche domanda trabocchetto, ottengo la risposta che temevo di dover sentire. L'INTERO range di IP della mia compagnia (parliamo di una multinazionale delle assicurazioni, eh, non di una società offshore con sede nel Delaware o alle Bahamas) non è nella loro whitelist. Come, come? Piano, un momento. Cosa cavolo significa che non è nella whitelist??? Significa che per sperare che il proprio sito sia visibile fuori dall'Italia bisogna fare domanda di inserimento nella Whitelist??? Ma stiamo scherzando? Questa è una follia ancora peggiore del blocco di default delle connessioni TOR. Comunque mi armi di pazienza e, anceh se non dovrei essere io a farlo, fornisco alla gentile signorina dell'helpdesk tutto il range di IP che, per quanto ne so, è intestato alla rete della mia compagnia. La domanda mi sorge spontanea: quante altre connessioni dall'estero vengono bloccate a mia insaputa, col sito oscurato a mia insaputa, con al scusa delle "ragioni di sicurezza"? Mi rendo conto che Netsons avendo, gli anni passati, hostato un sito di estrema destra si è resa bersaglio di attacchi informatici indiscriminate da parte di cybedeficienti che per colpire un sito "nemico" decidono allegramente di colpire chiunque sia hostato dallo stesso provider, ma la "soluzione" adottata sa di paranoia, non di sicurezza. Ok, "l'unico computer sicuro è il computer non collegato a una rete", ma.... non l'avete preso un po' troppo alla lettera, cari signori di netsons? Anche perchè francamente dubito che dalla rete della assicurazione per cui lavoro siano mai partiti attacchi DoS contro netsons tali da spingerli a inserire l'intera rete aziendale europea in una blacklist. E soprattutto, non sarebbe vostro preciso dovere commerciale informare i potenziali clienti che se vogliono raggiungere un pubblico più esteso del proprio parentado e cerchia di ex compagni di classe rischiano di trovarsi "oscurati" senza saperlo? Episodio 4: Cloudflare, o no? La mia prima (tragica) esperienza con Cloudflare risale a tre, quasi quattro anni fa. Premessa: netsons pubblicizza apertamente tra i propri punti di eccellenza la connettività italiana e la vicinanza della sua server farm al princiapel nodo di Milano. Suggerendo evidentemente, al potenziale cliente, che questo comporterà un vantaggio in termini di velocità e di tempi di risposta del sito. Di più, il servizio Cloudflare viene pubblicizzato, correggetemi se sbaglio, come servizio di ridondanza e di backup, pronto a intervenire in caso di emergenza e a "sostituire" temporanamente il sito originale con una copia nel caso in cui il server che ospita l'originale sia down o sotto attacco. Cosa che per un provider come Netsons, bersagliato di continuo dai cyberdeficienti di cui sopra, dev'essere un investimento indispensabile per garantire la continuità del servizio. ora, la domanda, è: Quando e quanto spesso subentra effettivamente la "copia" su Clodflare in luogo dell'originale hostato sulla tanto pubblicizzata connettività italiana e server farm a un tiro di sputo dal nodo di Milano? Me lo sono chiesto proprio in occasione di quello che allora fu definito il più grande ed esteso attacco DDoS di tutti i tempi. Di cui, udite udite, non fu bersaglio netsons, ma proprio Cloudflare. Me lo sono chiesto perchè in quei giorni fastidiosissimi, si verificò una stranezza. I server italiani di netsons erano raggiungibili, via ping, via traceroute, addirittura via sftp. I webserver che avrebbero dovuto rispondere da quei server fisici, invece, no. Se provavi a collegarti la connessione andava in timeout oppure appariva una pagina di errore dei server californiani di Cloudflare di "server too busy". Morale: i server italiani "protetti" da Cloudflare non erano sotto attacco, ma Cloudflare (che era sì sotto attacco e pesantemente collassata) era subentrata lo stesso. Perchè? Perchè non rispondevano i magnifici server della webfarm a un tiro di sputo dal nodo di Milano e su connettività italiana e subentrava invece un server californiano sotto attacco? Di qui la domanda ovvia: Quando e quanto interviene effettivamente la ridondanza di backup di Cloudflare, se i server italiani non sono affatto sotto attacco nè down per anomalie tecniche? La domanda me la posi anche in altre circostanze, in cui di nuovo senza apparente spiegazione, e senza alcun attacco DoS in corso, nè ai danni di netsons nè ai danni di cloudflare, il server "di backup" subentravano comunque, non richiesti. me ne accorsi facendo degli aggiornamenti al mio codice e caricando ex novo delle pagine nuove via FTP. Caricate le pagine via ftp, le pagine visibili da browser web restavano quelle vecchie. Definire "evasive" le risposte in proposito avute dall'HD di netsons in quel periodo è poco. Ad ogni modo "risolsi" il problema rinunciando alla protezione di Clouflare, che sul vecchio server (hosting frazionabile) fu disattivato. Da allora stranamente non ho più registrato disallineamenti di versione tra gli script appena caricati via ftp e quelli consultabili via browser dagli utenti in circostanze normali. Quando ho acquistato i due pacchetti hosting semicondiviso, tanto per portarmi avanti, ho chiesto preventivamente la disattivazione di cloudflare ma, sopresa!, mi è stato risposto che su quei server il servizio non era comunque attivo. Anche qui: server diversi, configurazioni diverse, nessuna spiegazione preventiva all'acquirente. Perchè? Episodio 5: PHP, file remoti e "controlli il suo codice" Nell'ambito della community ho esigenza che gli utenti possano caricare un loro avatar, un'immagine del profilo, usabile nel gioco e sui forum interni. Non essendo intenzionato a permettere l'upload diretto delle immagini sul mio spazio web, ho sempre lasciato, sul vecchio hosting frazionabile, la possibilità agli utenti di caricare le loro immagini del profilo su un altro server e di hotlinkarle facendole richiamare dalle pagine interessate. Avvalendosi tipicamente di servizi esterni di hosting immagini come imageshack o tinypic, o più banalmente caricando le immagini nella famigerata cartella /_altervista_ht/ dei domini gratuiti di altervista, appositamente configurate per permettere l'hotlink esterno. Ovviamente con qualche controllo preventivo sul formato MIME del file e le sue dimensioni, prima del richiamo nella pagina, per evitare seccanti tentativi di sql injection e XSS. Banalmente, scrissi una funzionacina php che prima di autorizzare il caricamente di un avatar esterno nella pagina html generata da php, controllava il percorso (url), l'estensione, l'esistenza del file, il formato MIME e le dimensioni del file. Sul server che ospita il piano frazionabile, tutto ok. Provo a replicare lo stesso sistema sui due server dove ho l'hosting semidedicato e.. tadaaaah! Appena PHP tenta di leggere un file remoto, la pagina php va in timeout e la funzione php incaricata (si tratti di file_exists() o di getimagesize() e analoghe) di controllare esistenza e formato del file remoto, va in palla, tenendo l'utente a fissare una pagina bianca per una quarantina di secondi prima che il server si degni di rispondere con un errore. Faccio tutti i test del caso per accertarmi che il problema dipenda dal tentativo di accedere a file remoti, confezioni un bel ticket con tanto di spiegazioni preventive (tanto per risparmiarmi la solita, inutile richiesta di "controlli il suo codice" che ogni addetto help desk di Netsons ha in canna e copincolla di default appena risponde a un ticket) e contatto l'help desk. Inutile dire che la prima risposta è stata comunque "controlli il suo codice" e che la prima domanda di merito sul problema segnalato mi è stata posta circa 48 ore dopo l'apertura del ticket e solo al terzo scambio di messaggi. Va beh, facciamo finta di nulla. In quel momento avevo questioni di sviluppo più urgenti e per il momento disattivai quei controlli, lasciando cadere il ticket perchè in tutta sincerità in quel momento avevo troppo da fare per perdere tempo a spiegare all'addetto help desk che gli avevo già fornito tutti gli estremi necessari e che gli sarebbe bastato verificare se sul server era attivo un blocco degli accessi ai file remoti. Resta il fatto che ho acquistato ben DUE piani hosting, pubbblicizzati espressamente da netsons per la loro maggiore efficienza e performance (vengono consigliati appositamente a clienti che vogliano installare CMS pesanti come Drupal, tanto per dirne una) e non posso fare a meno di chiedermi cosa accade a chi prende quel tipo di hosting proprio per installarci drupal e si trova con gli utenti che vanno in timeout appena cercano di caricare un'immagine profilo hostata esternamente. E non posso fare a meno di rilevare, ancora una volta, il problema già verificato in altre circostanze: Server diversi, configurazioni diverse, nessuna informazione preventiva e apparente "casualità" a seconda del server su cui si finisce hostati. ----------------------------------------- Fin qui i casi ascrivibili alla categoria "sicurezza" che mi hanno generato forti perplessità, perchè tirando le somme delle anomalie, mi si prospetta un possibile scenario inquietante: Ossia che la pubblicizzata maggiore prestanza di certi piani hosting non sia ottenuta grazie a minore affollamento e/o grazie a configurazioni hardware più performanti, ma grazie all'applicazione di policy di "sicurezza" quanto meno bizzarre nella gestione di whitelist e blacklist (con potenziale grave danno in termini di oscuramento inatteso e indesiderato del sito al di fuori delle white/blacklist), nell'adozione di configurazioni di sicurezza assurdamente restrittive (per non dire paranoidi) e, cosa ben più grave, senza una preventiva e adeguata informazione all'acquirente. Arriviamo alla ciliegina sulla torta, quella che mi ha fatto definitivamente "sbroccare", come si dice qua a Roma. L'atteggiamento ormai di default degli addetti all'help desk, coloro che DOVREBBERO aiutare il cliente a individuare e risolvere una problema quando viene segnalato e che sempre più spesso si limitano ad agire come quelle segretarie d'ufficio che "fanno filtro" temporeggiando con i clienti che telefonano allo studio, prima di decidersi ad alzare il posteriore dalla poltrona e chiamare il titolare al telefono. Episodio 1, Server down e picchi di consumo: "Controlli il suo codice" e "Adesso il sito funziona" Una settimana fa il sito va down per un'oretta circa. Poco male, è tarda sera e la community è "chiusa" per manutenzione. Collegati c'eravamo solo io e altri due sviluppatori. Apro un ticket, dopo 20 minuti, quando non vedo il server ripartire e il giorno dopo mi viene risposto (conoscendo i miei polli allego anche i grafici di Cpanel sul consumo di risorse) con la solita richiesta di default, di controllare il mio codice perchè probabilmente, mi viene suggerito con tanto di "faccina", il picco di consumo di memoria e cpu è stato causato da "codice non ottimizzato". Tralascio i giramenti di posteriore, dato che in quel momento non stavo lavorando sul codice, e faccio presente che andando indietro di 24 ore si vedono benissimo altri picchi di consumo, in orari in cui non c'era proprio nessuno collegato, nessun cronjob stava girando e già che ci sono mostro come dalle date di modifica degli script PHP sia facile evincere che nessuna modifica era stata introdotta al codice nelle 72 ore precedenti al disservizio. Altre 24 ore prima di una nuova risposta, che consiste in "Abbiamo verificato, il sito risponde regolarmente e senza picchi. Non ci risulta alcun disservizio". Ticket chiuso. No, dico. la pazienza di Giobbe, ci vuole. Tengo per me (oltre alle parolacce) la spiegazione più ovvia, ossia un consumo di risorse non dovuto al MIO codice ma o a interventi sulla macchina, o a qualche "vicino" ingombrante, alla faccia del semicondiviso. Non è la prima volta che succede e 5 anni di esperienza mi hanno insegnato a lasciar cadere la cosa, visto che fortunatamente non si verifica troppo spesso. Episodio 2: Warning PHP/mariaDB per disalliamento header PHP e "Controlli il suo codice" La goccia che, per quanto mi riguarda, ha fatto traboccare il vaso. Non c'è nulla, dico nulla, di più irritante e frustrante, per un sistemista e programmatore, di sentirsi rispondere da un altro (supposto) sistemista con risposte evasive, approssimative e "alla carlona" mentre si sta tentando di risolvere un problema. Nulla. No, beh, un bug logico nel proprio programma, di queli che non causano errori di sistema ma danno risultati inattesi, forse è peggio. Ma di poco. Due giorni dopo l'episodio qui sopra riportato, inizia a verificarsi una stranezza. Tutti gli script php che accedono al database, in lettura o scrittura, buttano fuori un warning ad ogni connessione: PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Di per sè non sarebbe grave. Non è un errore bloccante, è solo un warning. E nella maggior parte dei casi, pagine poco consultate hanno riempito, in poche ore, le loro cartelle di file di log errore pieni del warning di cui sopra. Ma ci sono anche cartelle con pagine molto usate che nel giro di poche ore hanno podotto file di log delle dimensioni di un paio di megabyte. Mi insospettisco, quando noto che caso strano i warning iniziano a verificarsi dopo la fine del blackout di cui sopra, quello in cui per un'oretta e mezza il server è stato down. Tant'é che nel ticket chiedo esplicitamente se non siano stati effettuati aggiornamenti con conseguente disallineamento di versioni. sempre nella (inutile) speranza di risparmiarmi la rituale richiesta di controllare il mio codice, allego anche uno dei log errori contenenti il wanring ed evidenziando che a produrre il warning è la stessa funzione mysql_connect(). Non una query scritta male, non codice mal ottimizzato, non un errore logico che causa qualche loop. No. E' proprio la banalissima funzione che attiva il collegamento al database a buttare fuori il warning, appena PHP prova a bussare a MySql. Puntuale (dopo circa 24 ore) come la morte, arriva lo stesso la solita risposta a pennuto di cane: "con la presente La invito a verificare che il codice utilizzato deve essere compatibile con il PHP 5.6 e la versione del servizio DB MariaDB10" Eh no. Scusate, va bene tutto. Io capisco chi, qui, difende i colleghi per principio e si indigna quando i colleghi vengono messi alla gogna, ma qui si passa ogni limite. Ho citato espressamente la funzione che causa il warning. Ho pure allegato un log completo. Ti ho pure fornito sul piatto d'argento la possibile motivazione del warning, visto che basta cacciare quel warning nella ricerca di google per ottenere la spiegazione ( https://mariadb.com/kb/en/mariadb/installation-issues-with-php5/ ), che ovviamente dipende da una configurazione del server non accessibile al semplice utente "hostato". E tu mi rispondi "controlla il tuo codice"??? Quale sarebbe, il "mio codice" di cui si suggerisce l'incompatibilità con PHP 5.6 e MariaDB10", la funzione mysql_connect() ?? E' esattamente questo che rispondo all'addetto help desk, aggiungendo che se la funzione mysql_connect() fosse "mio codice" oggi probabilmente sarei miliardario. L'addetto lascia passare altre 24 ore e risponde piccatamente offeso, chiudendo il ticket in quanto "non gli ho fornito info rilevanti". Cari signori di netsons. Così non va. Di questo passo, state imboccando lo stesso sentiero di aruba. da sistemista posso capire a mia volta la fretta che può spingere un collega oberato di lavoro a cercare di temporeggiare per non essere sommerso dai problemi in lista di attesa. Ma che diamine: Un "adesso verifichiamo, stiamo lavorando sul problema, le faremo sapere", per quanto irritante è mille volte meglio di una risposta alla carlona dalla quale si evince che il vostro addetto non ha nemmeno fatto lo sforzo di leggere la prima riga del ticket. Non può esistere che la risposta di default dei vostri operatori, ormai, è "controlli il suo codice" qualunque cosa venga scritta nel ticket, anche quando è lampante che il ticket riguarda una configurazione del server e non un malfunzionamento di codice autoprodotto. Se l'unica residua convenzienza del vostro servizio diventa la presenza dei cronjob anche nel pacchetto base e la possibilità di rateizzare i pagamenti, presto o tardi la gente che è fuggita da aruba anni fa venendo da voi perchè aveva un servizio migliore, migrerà da qualche altra parte. Mi spiacerebbe, perchè dopo 5/6 anni con voi, nonostante tutto mi sono in qualche modo affezionato. Ma più passa il tempo, più imboccate questa strada, più passa la voglia.
  2. Un annuncio sul sito ufficiale del progetto Tor, sistema per la navigazione anonima in rete, comunica la compromissione di alcuni server del progetto, tra i quali anche uno contenente codice e pacchetti poi distribuiti agli utenti in rete. Il consiglio è quello di aggiornare il prima possibile il software alla versione 0.2.1.22 in modo da scongiurare eventuali modifiche avvenute all'interno del codice, anche se dai primi riscontri sembra che non siano stati compiuti cambiamenti. Leggi Compromessi i server del progetto Tor
×