Re: mutt e postfix
On Sun, Dec 02, 2018 at 02:06:00PM +0100, Mauro wrote: > > semplicemente devi abilitare l'autenticazione come client da parte di > postfix. Semplice. [...] Grazie ad entrambi delle risposte. Ricontrollando meglio tutto, c'erano degli errori nelle credenziali d'accesso. Adesso sembra funzionare. Grazie Mattia
mutt e postfix
Buonasera a tutti, sul pc di casa ho debian sid con mutt e postfix. Vorrei utilizzare il server di posta in ufficio come relay (postfix su debian stretch), facendo spedire la posta da postfix sul pc di casa. Ho configurato postfix sul pc di casa seguendo questa guida: https://linode.com/docs/email/postfix/postfix-smtp-debian7/ Ma ottengo questo errore se uso la porta 25: 454 4.7.1 Relay access denied; Questo se uso la 587: 554 5.7.1 [...] Client host rejected: Access denied (in reply to RCPT TO command) Se modifico la conf di mutt in questo modo: set smtp_url = 'smtp://u...@smtp.mydomain.it:25/' riesco a mandare le mail (inserendo la password). Funziona anche con la porta 587. Anche su thunderbird tutto funziona, quindi non penso che sia qualche opzione troppo restrittiva sul server. Cosa potrebbe essere? Grazie Mattia
.Xresources
Ciao a tutti, ho aggiornato Sid dopo un paio di settimane ed adesso mi ritrovo con xterm con sfondo bianco e scritte nere. Nel mio file .Xresources però ho tra l'altro: XTerm*background: black XTerm*foreground: white Quindi mi sembra evidente che il file .Xresources non venga più caricato (da chi poi? GDM?). Prima dell'aggiornamento funzionava. Se lancio: xrdb -merge -I$HOME ~/.Xresources funziona ma devo darlo ad ogni riavvio. E' cambiato qualcosa di recente in GDM?
Re: Ancora su Spectre e Meltdown (compilare tutti i pacchetti con retpoline?)
On Sat, Feb 24, 2018 at 10:19:08AM +0100, Davide Prina wrote: > On 24/02/2018 00:38, Mattia Oss wrote: > > > Esiste una lista di tutte le opzioni da abilitare nel kernel per chi se > > lo ricompila? > > quando lo ricompili le puoi settare una ad una, ma per capire esattamente > cosa fa ognuna devi studiare molto Scusami, intendevo una lista di opzioni del kernel da abilitare per mitigare le vulnerabilità spectre e meltdown.
Re: Ancora su Spectre e Meltdown (compilare tutti i pacchetti con retpoline?)
On Fri, Feb 23, 2018 at 08:13:07PM +0100, Davide Prina wrote: > On 18/01/2018 23:07, Luca Costantino wrote: > > interessante risposta sulla domanda: saranno compilati tutti i pacchetti con > retpoline abilitato: Esiste una lista di tutte le opzioni da abilitare nel kernel per chi se lo ricompila?
Re: Portatile, ma di livello alto
On Fri, Feb 23, 2018 at 03:42:07PM +0100, Paolo Redaelli wrote: > Facciamo il paio con la discussione avviata da Leandro... bellissimo il Dell > XPS 13, ma se uno volesse qualcosa di simile con Debian preinstallato? > > C'è qualche possibilità? Sì, ho visto che sulle vecchie versioni dell'xps > Debian gira bene, ma su quello attuale non ci sono notizie "ufficiali" AFAICS > . > > Ho cercato su yeppon ma non c'è nulla. Santech? Sono configurabili e per quella che è la mia esperienza compatibili al 100% con debian. Io ne ho uno molto vecchio però.
Re: Grub con UEFI in RAID1
On Fri, Feb 16, 2018 at 11:26:48AM +0100, Piviul wrote: > Il 16/02/2018 11:06, Gollum1 ha scritto: > > [...] > > È proprio questo che intendevo, una volta che sei in raid 1, ci pensa il > > raid a sincronizzare le partizioni, ti fai l'installazione su md0 e vivi > > tranquillo > > > E ritorniamo a bomba: vale la pena mettere in raid la partizione EFI? > > Secondo me no perché basta lanciare la prima volta un grub-install sui > dischi che si vogliono come "backup" di boot e ridare lo stesso comando > quando viene aggiornato grub il che avviene molto di rado. > > Inoltre siccome la partizione EFI contiene anche tutte le informazioni sul > partizionamento del disco, la si può mettere in RAID soltanto se i dischi > sono identici e identicamente partizionati. > > Infine siccome non se ne è mai sentita l'esigenza sui dischi non EFI con il > vecchio settore di boot per intenderci, non vedo perché adesso, solo perché > lo si possa fare debba essere consigliato il farlo... > > Ma temo che qualcosa mi sfugga... E' una questione di simmetrie.. :) Scherzi a parte, alla fine è solo una questione di gusti, credo. Ma magari vista la facilità della soluzione (alla fine basta passare un'opzione a mdadm), potrebbe essere integrata nell'installer debian.
Re: Grub con UEFI in RAID1
On Wed, Feb 14, 2018 at 12:01:26PM +0100, Piviul wrote: > Mi sono un po' perso... non è sufficiente altrimenti ricordarsi di eseguire > un grub-install sui dischi che compongono il raid ogni volta che si cambia > la configurazione di grub? si ma grub-install aggiornerà solo la partizione efi che hai in /etc/fstab. Se ti muore il disco in cui c'è questa partizione, l'altro non sarà aggiornato e quindi probabilmente non partirà. Tutto questo ammesso che la partizione efi venga effettivamente modificata ogni qual volta si cambia la configurazione di grub, cosa che dubito. Ma prima o poi verrà modificata (aggiornamento di grub?). Mattia
Re: Grub con UEFI in RAID1
On Wed, Feb 07, 2018 at 02:24:37PM +0100, gerlos wrote: > > > Il giorno 06 feb 2018, alle ore 20:11, Mattia Oss ha > > scritto: > > > > On Tue, Feb 06, 2018 at 04:15:57PM +0100, Lorenzo "Palinuro" Faletra wrote: > >> posso confermare che la esp non può essere messa in raid > > > > Da come mi avevi risposto nella prima mi sembravi sicuro del contrario. > > Penso anch’io che la ESP non possa essere messa in RAID. > Sicuramente non in un RAID software linux, visto che il firmware del computer > ne ha bisogno per fare il boot. Se qualcuno fosse interessato, mi sono imbattuto per caso su questo articolo che spiega come fare per avere la partizione efi in raid: https://lars.st0ne.at/blog/efi+partition+on+software+raid+1 In pratica, si fa l'installazione creando le partizioni efi senza metterle in raid. Poi, a sistema installato, si crea un array RAID1 di queste partizioni passando l'opzione --metadata=1.0. Un po' scomodo, ma meglio di niente.
Re: Grub con UEFI in RAID1
On Tue, Feb 06, 2018 at 04:15:57PM +0100, Lorenzo "Palinuro" Faletra wrote: > posso confermare che la esp non può essere messa in raid Da come mi avevi risposto nella prima mi sembravi sicuro del contrario. > una soluzione che adotto sui miei server è di creare una partizione > fat12/fat16/fat32 con flag esp su tutti i dischi del raid di boot. > ovviamente solo una cartella farà da master, e solo una verrà tenuta > aggiornata dagli update di grub, così ho fatto in modo che fstab mi > monti /boot/efi, /boot/efi1, /boot/efi2 e così via, e che uno script di > post-aggiornamento di grub vada a lanciare un rsync che tenga il tutto > sempre aggiornato tra le varie cartelle Stavo pensando anch'io ad impostare qualcosa di simile. > dato che non so se grub supporti il raid e non ho avuto tempo per > sperimentare (e non sono il tipo che chiede), ho fatto la stessa cosa > anche per la partizione di boot, montandomi /boot, /boot1, /boot2 ecc, e > facendo uno script di post-aggiornamento con rsync simile al primo Ti posso confermare che la partizione /boot può essere messa in raid.
Re: Grub con UEFI in RAID1
On Mon, Feb 05, 2018 at 08:30:01PM +0100, Mattia Oss wrote: > On Sun, Feb 04, 2018 at 11:05:49PM +, Lorenzo "Palinuro" Faletra wrote: > > se esterna al raid rispetto ai 2 dischi in raid allora si, perchè la > > rottura di uno dei 2 dischi non compromette lanrottura della partizione di > > boot (che è altrove) > > > > se invece la partizione è su uno dei 2 dischi, ti ricordo che i raid da > > raid1 a salire nascono per il semplice fatto che a rompersi per usura sono > > i dischi, non le singole partizioni, quindi replicare anche la partizione > > esp di uefi è cosa buona e giusta > > Ma porc.. Che svista. Per fortuna non faccio il sistemista di > professione. Che faccio adesso? Se creo un array per queste 2 partizioni > parte debian? Leggendo in rete sembra che la partizione per un sistem UEFI deve essere di tipo efi/vfat. Sei sicuro che si possa mettere in RAID? Per il momento l'ho semplicemente clonata sull'altro disco e facendo la prova staccando i dischi sembra funzionare.
Re: Grub con UEFI in RAID1
On Sun, Feb 04, 2018 at 11:05:49PM +, Lorenzo "Palinuro" Faletra wrote: > se esterna al raid rispetto ai 2 dischi in raid allora si, perchè la rottura > di uno dei 2 dischi non compromette lanrottura della partizione di boot (che > è altrove) > > se invece la partizione è su uno dei 2 dischi, ti ricordo che i raid da raid1 > a salire nascono per il semplice fatto che a rompersi per usura sono i > dischi, non le singole partizioni, quindi replicare anche la partizione esp > di uefi è cosa buona e giusta Ma porc.. Che svista. Per fortuna non faccio il sistemista di professione. Che faccio adesso? Se creo un array per queste 2 partizioni parte debian?
Grub con UEFI in RAID1
Ciao a tutti, ho da poco installato debian con 2 dischi in raid1. Siccome vorrei essere in grado di avviare il sistema se uno dei dischi si rompe, in rete si suggerisce di installare grub su entrambi i dischi. Mi chiedevo, nei sistemi UEFI è ancora vero? Grub viene installato sulla partizione EFI (esterna al raid), quindi in teoria non dovrebbe essere necessario? O sbaglio?
gnome-terminal finestre fantasma
Ciao a tutti, ho veramente uno strano problema con gnome-terminal: ad un certo punto quando passo su un'area di lavoro vuota mi compare una finestra di gnome terminal in cui stavo lavorando in precedenza ma non è interattiva. Cioè si aggiorna (per esempio se sta eseguendo il comando tailf) ma non si può scrivere niente. Se premo il tasto win per mostrare tutte le finestre nell'area di lavoro, scompare. Se lo ripremo riappare. Tutti i terminali vengono lanciati in questo modo: gnome-terminal --hide-menubar --full-screen Per esempio: se apro una finestra di gnome-terminal (con una scorciatoia) sopra la finestra di gnome-terminal che sto usando per scrivere questa mail e poi la chiudo, e mi sposto su un'area di lavoro vuota questa mi compare.. O meglio il suo fantasma. Non posso continuare a scriverci sopra. Se uso il tasto win (per intendersi quello per far apparire la barra sopra per cercare le applicazioni) scompare, per poi riapparire se lo premo di nuovo. Succede con tutte le finestre di gnome-terminal TRANNE con 2, le prime 2 che ho creato (credo). Iberno il PC invece che spegnerlo. Speravo che con qualche aggiornamento si risolvesse automagicamente, invece è da un bel po' che va avanti. Cosa potrebbe essere?
Re: Server casalingo
Normalmente in lista si risponde sotto al testo quotato (eventualmente cancellando ciò che non è necessario). On Mon, Nov 20, 2017 at 08:55:49PM +0100, Carlo Bressan wrote: > Hai in mente una configurazione per darmi un'idea? No, come detto non sono un esperto. Prova a chiedere qui: http://www.hwupgrade.it/forum/forumdisplay.php?f=138
Re: Server casalingo
On Sun, Nov 19, 2017 at 05:11:23PM +0100, Carlo Bressan wrote: > Ciao a tutti e grazie per le risposte, > sto valutando diverse soluzioni, la mia necessità non sarebbe solo quella di > avere un nas. > Mi piacerebbe poterci montare un paio di macchine virtuali per fare dei test > sulle applicazioni che sviluppo. > Vorrei installarci un database server da usare anche dall’esterno e un > sistema di versionamento. > Non seguendo più da anni lo sviluppo delle architetture hardware non vorrei > ritrovarmi con un processore troppo scarso, come è successo ad un amico che > ha preso il famoso hp proliant g8 e ha dovuto sostituire il Celeron con un i3 > per avere più potenza di calcolo. > Il problema ulteriore è anche il fattore prezzo, perchè non vorrei spendere > più di 400€, quindi i processori xeon per me sono inarrivabili a meno di > super offerte online. Mi piacerebbe capire se una soluzione come il dell t20 > con processore pentium G3220 è ancora troppo scarso per quello che vorrei > fare oppure no. Non sono un esperto, ma non sarebbe meglio un assemblato?
Re: Bash * in variabili
On Sat, Nov 18, 2017 at 08:01:53AM +0100, Piviul wrote: > Il 11/17/17 21:04, Mattia Oss ha scritto: > > [...] > > Scusate, rileggendo la mia mail mi sono reso conto che non si capisce > > niente. > sono d'accordo con te... Percepisco una sottile ironia... :) > > Tipo quando entro nella cartella: > > /var/vmail/domain1/user1/Maildir/INBOX/Junk > > vorrei avere 2 variabili domain e user con i seguenti valori: > > domain=domain1 > > user=user1 > > > > Quando entro in > > /var/vmail/domain2/user3/Maildir/INBOX/Junk > > domain=domain2 > > user=user3 > for d in /var/vmail/*; do > [ ! -d "$d" ] && continue; > for sd in $d/*; do > [ ! -d "$sd" ] && continue; > domain=$(basename $d); > user=$(basename $sd); > for f in "$sd/Maildir/INBOX/Junk/*"; do > ... > done; > done; > done; Mi sembra perfetto. Grazie mille!
Re: Bash * in variabili
On Fri, Nov 17, 2017 at 03:45:48PM +0100, Teodoro Santoni wrote: > Ciao, > > Il 17/11/17, Mattia Oss ha scritto: > > In pratica da un for del tipo: > > for i in "/var/vmail/*/*/Maildir/INBOX/Junk/"; do > > > > è possibile inserire i valori che sostituiscono gli "*" in variabili? > > Spero di essermi spiegato.. > > Se vuoi tutto quello che si può reperire dalle wildcard, togli le > doppie virgolette e lo slash alla fine. > Se vuoi dei nomi particolari, al posto del * usa {valore,secondovalore} > Va bene anche con le variabili. Scusate, rileggendo la mia mail mi sono reso conto che non si capisce niente. Dunque ho delle cartelle tipo: /var/vmail/domain1/user1/Maildir/INBOX/Junk /var/vmail/domain1/user2/Maildir/INBOX/Junk /var/vmail/domain1/user3/Maildir/INBOX/Junk /var/vmail/domain2/user1/Maildir/INBOX/Junk /var/vmail/domain2/user3/Maildir/INBOX/Junk /var/vmail/domain3/user2/Maildir/INBOX/Junk /var/vmail/domain3/user3/Maildir/INBOX/Junk Con il ciclo: for i in "/var/vmail/*/*/Maildir/INBOX/Junk"; do mi trova tutte le cartelle ma mi servono i valori domain{1,2,3} e user{1,2,3}. Tipo quando entro nella cartella: /var/vmail/domain1/user1/Maildir/INBOX/Junk vorrei avere 2 variabili domain e user con i seguenti valori: domain=domain1 user=user1 Quando entro in /var/vmail/domain2/user3/Maildir/INBOX/Junk domain=domain2 user=user3 ecc...
Bash * in variabili
Scusate il pessimo titolo ma non so il nome dell'argomento e quindi spero di spiegarmi bene. In pratica da un for del tipo: for i in "/var/vmail/*/*/Maildir/INBOX/Junk/"; do è possibile inserire i valori che sostituiscono gli "*" in variabili? Spero di essermi spiegato.. Grazie Mattia signature.asc Description: PGP signature
Re: Downgrade pacchetti
On Mon, Sep 11, 2017 at 07:29:47PM +0200, Davide Prina wrote: > On 10/09/2017 08:16, Mattia Oss wrote: > > > Avete suggerimenti per clonare il server? Pensavo a rsync escludendo le > > cartelle di sistema. > > perché rsync? Non devi clonarlo una volta e basta? > > dd Hai perfettamente ragione. dd l'ho usato qualche volta per recuperare dei DVD. Proverò.
Re: Downgrade pacchetti
On Sat, Sep 09, 2017 at 07:36:21PM +0200, Davide Prina wrote: > On 07/09/2017 20:04, Davide Prina wrote: > > Package: * > Pin: release a=jessie > Pin-Priority: 1001 Grazie per il consiglio, come anche suggerito da una altra persona. In realtà bisogna mettere n=jessie oppure a=oldstable. Proverò appena avrò un po' di tranquillità. Avete suggerimenti per clonare il server? Pensavo a rsync escludendo le cartelle di sistema.
Re: Downgrade pacchetti
On Fri, Sep 08, 2017 at 01:02:19PM +0200, andrea biancalana wrote: > il giorno Fri, 8 Sep 2017 11:32:27 +0200 Mattia Oss > ha scritto: > > > Grazie a tutti per le risposte. > > I pacchetti sono pochi perché di solito quando aggiorno una stable > > modifico il source.list, aggiorno dpkg, apt e aptitude, poi faccio > > l'upgrade e alla fine il dist-upgrade. Qui avevo appena cominciato. > > > > osservazione un po' stupida: > ma non e' che hai interrotto nella fase di download dei pacchetti e, quindi, > installazione e configurazione non erano nemmeno cominciate?! No, io non ho interrotto l'installazione. Mi sono accorto dell'errore dopo la fine dell'installazione di alcuni pacchetti (dpkg, apt, ecc..).
Re: Downgrade pacchetti
On Fri, Sep 08, 2017 at 12:31:43AM +0200, Felipe Salvador wrote: > On Thu, Sep 07, 2017 at 05:25:59PM +0200, Mattia Oss wrote: > > Ciao a tutti, > > > > stavo facendo l'upgrade a stretch sul portatile quando mi sono accorto > > che in realtà mi trovavo su una console remota di un server. Questi sono > > i pacchetti che ho installato prima di accorgermi della ca**ata: > > A me pare una lista contenuta, anche solo per un primo apt-get upgrade > (non dist-upgrade), in fase di upgrade del sistema. > Questo mi fa sorgere una domanda: La lista che pubblichi è il > risultato di un apt-get upgrade conclusosi regolarmente, o, rendendoti > conto del pasticcio, hai chiuso tutto all'improvviso? > > > Se quella prima installazione di pacchetti si è conclusa regolarmente > senza errore potresti pensare, con molta pazienza, di lavorare caso > per caso, eseguendo un pin[1] ed effettuando il downgrade. > > Potrebbe essere un bagno di sangue. > > [1] https://wiki.debian.org/AptPreferences > Grazie a tutti per le risposte. I pacchetti sono pochi perché di solito quando aggiorno una stable modifico il source.list, aggiorno dpkg, apt e aptitude, poi faccio l'upgrade e alla fine il dist-upgrade. Qui avevo appena cominciato. Non me la sento di rischiare di fare casini. Non è un server mission critical, ma c'è il cloud dell'azienda e quindi preferisco lasciarlo così. Tanto più perché fra un paio di mesi devo cambiarlo. Saluti Mattia
Downgrade pacchetti
Ciao a tutti, stavo facendo l'upgrade a stretch sul portatile quando mi sono accorto che in realtà mi trovavo su una console remota di un server. Questi sono i pacchetti che ho installato prima di accorgermi della ca**ata: apt:amd64 1.4.7 aptitude:amd64 0.8.7-1 aptitude-common:all 0.8.7-1 apt-utils:amd64 1.4.7 dpkg:amd64 1.18.24 fping:amd64 3.10-2 gcc-6-base:amd64 6.3.0-18 gnupg:amd64 1.4.18-7+deb8u4 gpgv:amd64 1.4.18-7+deb8u4 libapt-inst2.0:amd64 1.4.7 libapt-pkg5.0:amd64 1.4.7 libboost-filesystem1.62.0:amd64 1.62.0+dfsg-4 libboost-iostreams1.62.0:amd64 1.62.0+dfsg-4 libboost-system1.62.0:amd64 1.62.0+dfsg-4 libc-bin:amd64 2.19-18+deb8u10 libcwidget3:amd64 0.5.17-2 libcwidget3v5:amd64 0.5.17-4+b1 libdbi1:amd64 0.9.0-4 libfreeradius-client2:amd64 1.1.6-7 libgd3:amd64 2.1.0-5+deb8u11 liblz4-1:amd64 0.0~r131-2+b1 liblzma5:amd64 5.2.2-1.2+b1 libncurses5:amd64 6.0+20161126-1 libncursesw5:amd64 6.0+20161126-1 libnet-snmp-perl:all 6.0.1-2 libperl5.20:amd64 5.20.2-3+deb8u8 libsensors4:amd64 1:3.3.5-2 libsigc++-2.0-0c2a:amd64 2.4.0-1 libsigc++-2.0-0v5:amd64 2.10.0-1 libsnmp30:amd64 5.7.2.1+dfsg-1 libsnmp-base:all 5.7.2.1+dfsg-1 libstdc++6:amd64 6.3.0-18 libtinfo5:amd64 6.0+20161126-1 libtirpc1:amd64 0.2.5-1+deb8u1 libxapian22:amd64 1.2.19-1+deb8u1 libxapian30:amd64 1.4.3-2 man-db:amd64 2.7.0.2-5 mime-support:all 3.58 monitoring-plugins:all 2.1.1-1 monitoring-plugins-basic:amd64 2.1.1-1 monitoring-plugins-common:amd64 2.1.1-1 monitoring-plugins-standard:amd64 2.1.1-1 nagios3:amd64 3.5.1.dfsg-2+b1 nagios3-cgi:amd64 3.5.1.dfsg-2+b1 nagios3-common:all 3.5.1.dfsg-2 nagios3-core:amd64 3.5.1.dfsg-2+b1 nagios3-doc:all 3.5.1.dfsg-2 nagios-images:all 0.8 nagios-plugins:all 2.1.1-1 nagios-plugins-basic:all 2.1.1-1 qstat:amd64 2.15-1 rpcbind:amd64 0.2.1-6+deb8u2 snmp:amd64 5.7.2.1+dfsg-1 tar:amd64 1.29b-1.1 Ho cercato un po' in giro ma sostanzialmente quello che si consiglia è di reinstallare tutto. Questo proprio non è possibile almeno per il momento. Non c'è proprio un modo per farlo senza incasinare tutto? Adesso ho rimesso jessie nel source.list. Quanto tempo ci vorrà prima che queste versioni dei pacchetti entrino in jessie? Anni? Grazie
Re: Mail server casalingo
On Mon, Jun 26, 2017 at 10:07:01AM +0200, maxlinux duemila wrote: > Sono anni che ho diversi server online con ip pubblico e dominio. Ricevono > centinaia di attacchi al giorno, ma finora nessun problema. > > Certo... Fail2ban e una buona configurazione iniziale è importante, inoltre > meglio non seguire le mode. Per esempio è appena uscita Debian 9, ma per > produzione meglio rimanere sulla 8 per i prossimi mesi, in modo che venga > fatto un buon debug > > El 26 jun. 2017 9:23 a. m., "Piviul" escribió: > > Il 26/06/2017 00:27, Mattia Oss ha scritto: > > > [...] > > Questa è la mia paura più grande: la gestione della sicurezza. > > Per prova ho configurato un cloud server e c'è poco da scherzare. > > > > Vedo tentativi di intrusione quasi quotidianamente e questo mi > > preoccupa. Direi che al momento è l'unica cosa che mi frena. > > > se lo tieni aggiornato e installi qualcosa come fail2ban secondo me i > rischi sono molto ridotti. > > Piviul Ho trovato degli ottimi howto su internet. Ho installato fail2ban e suricata sul cloud server (in cui c'è anche un server di posta di prova), è dai loro log che nasce la preoccupazione. Comunque credo che lo farò, ho diversi mesi per prepararmi. Colgo l'occasione per vedere se riesco a sciogliere questo dubbio: ho installato fwknop per aprire la porta di sshd prima di connettermi. E' fattibile usarlo dietro un router? Devo fare il forward della sua porta (62201/udp) verso il server? Oppure no? Non mi è ben chiaro come funziona, mi sembra di capire che sia una sorta di sniffer.
Re: Mail server casalingo
On Thu, Jun 22, 2017 at 07:22:12PM +0200, Mauro wrote: > Semmai, la cosa critica e' quella della sicurezza: hardware, os, > sofware: hai una macchina che in parte deve essere esposta, che puo' > essere soggetta ad attacchi, guasti, devi garantirti continuita' di > servizio, backup: se hai tempo per valutare queste cose, allora ben > venga,la cosa e' decisamente interessante e divertente, anzi, direi di > farlo... saprai sicuramente garantire maggiore qualita' rispetto a > tanti provider. > Di contro, se hai poco tempo, allora la rottura di balls e' garantita. Questa è la mia paura più grande: la gestione della sicurezza. Per prova ho configurato un cloud server e c'è poco da scherzare. Vedo tentativi di intrusione quasi quotidianamente e questo mi preoccupa. Direi che al momento è l'unica cosa che mi frena.
Mail server casalingo
Ciao a tutti, mi chiedevo se era fattibile avere un mail server che gestisce 4 account e con picchi massimi di 100 mail al giorno con una adsl telecom Business 20M Adaptive 256F (IP fisso). Non sto parlando di installazione, gestione, ecc.. sto solo parlando di banda. Sarebbe troppo lento per ricevere/spedire le mail? I client sono esterni alla LAN. Grazie