2008 está a ser um ano com bastantes atritos e isso parece ir continuar durante o resto do ano e continuar,
desde a especulação existente sobre o preço do petróleo ao aumento do custo de alimentos.
Este promete ser o ínicio de uma época complicada.
A PT assinou terça-feira um acordo para a construção e manutenção de um cabo submarino de fibra óptica entre o Reino Unido e a Índia, no âmbito de um consórcio composto por 16 operadoras de telecomunicações.
O cabo terá 15 mil quilómetros de extensão e permitirá assegurar a conexão entre 13 países - Reino Unido, Portugal, Gibraltar, Marrocos, Mónaco, França, Líbia, Egipto, Arábia Saudita, Djibouti, Omã, Emirados Árabes Unidos e Índia - de três continentes.
http://www.jornaldenegocios.pt/default.asp?Session=&CpContentId=316799
Surpreendido ou não a Vodafone ganhou o contrato , dado a importância deste negócio em termos de divulgação da marca “Vodafone” não deve ter sido pouco o dinheiro pago para conseguir esta vantagem.
Espero para ver mas interessante lá está é o que eu digo os problemas não existem só em .pt
Encontre as diferenças se isso ajudar …
Relembro-me um livro da O’reilly sobre bind/ISC que recomenda o uso de localizações diferentes para nameservers primários ( localizações físicas e lógicas ), não é algo que eu siga, mas só não sigo porque não sou o chefe.
sudo traceroute 208.65.152.201
traceroute to 208.65.152.201 (208.65.152.201), 64 hops max, 40 byte packets
1 20.0.0.254 (20.0.0.254) 0 ms 0 ms 0 ms
2 * * *
3 * * *
4 195.22.12.69 (195.22.12.69) 6 ms 6 ms 6 ms
5 Cogent.AS174.gigapix.pt (193.136.250.80) 111 ms 111 ms 111 ms
6 te7-3.mpd02.mad05.atlas.cogentco.com (130.117.1.101) 109 ms 109 ms 109 ms
7 te4-3.mpd01.par02.atlas.cogentco.com (130.117.2.249) 289 ms te1-3.mpd01.par02.atlas.cogentco.com (130.117.0.22) 217 ms te3-3.mpd01.par02.atlas.cogentco.com (130.117.0.7 
212 ms
8 te2-2.mpd02.par01.atlas.cogentco.com (130.117.2.81) 111 ms te3-2.mpd02.par01.atlas.cogentco.com (130.117.2.110) 111 ms te1-2.mpd02.par01.atlas.cogentco.com (130.117.1.230) 110 ms
9 te4-4.ccr04.jfk02.atlas.cogentco.com (130.117.2.9) 109 ms te7-4.ccr04.jfk02.atlas.cogentco.com (154.54.1.21) 111 ms te4-4.ccr04.jfk02.atlas.cogentco.com (130.117.2.9) 109 ms
10 te8-2.mpd01.jfk01.atlas.cogentco.com (154.54.1.210) 110 ms te3-3.mpd01.jfk01.atlas.cogentco.com (154.54.24.149) 112 ms te8-2.mpd01.jfk01.atlas.cogentco.com (154.54.1.210) 110 ms
11 vl3490.mpd01.ewr03.atlas.cogentco.com (154.54.1.30) 111 ms te4-4.mpd01.ewr03.atlas.cogentco.com (154.54.1.3 111 ms vl3490.mpd01.ewr03.atlas.cogentco.com (154.54.1.30) 111 ms
12 you-tube-llc.demarc.cogentco.com (38.101.84.66) 110 ms 111 ms 110 ms
13 * * *
[15:17:55]andre@linux-wii:~$ sudo traceroute 208.65.152.201
traceroute to 208.65.152.201 (208.65.152.201), 64 hops max, 40 byte packets
1 20.0.0.254 (20.0.0.254) 0 ms 0 ms 0 ms
2 * * *
3 * * *
4 195.22.12.69 (195.22.12.69) 6 ms 8 ms 6 ms
5 Cogent.AS174.gigapix.pt (193.136.250.80) 110 ms 111 ms 110 ms
6 * * te7-3.mpd02.mad05.atlas.cogentco.com (130.117.1.101) 109 ms
7 te3-3.mpd01.par02.atlas.cogentco.com (130.117.0.7 111 ms te7-3.mpd01.par02.atlas.cogentco.com (130.117.2.173) 111 ms te4-3.mpd01.par02.atlas.cogentco.com (130.117.2.249) 109 ms
8 te1-2.mpd02.par01.atlas.cogentco.com (130.117.1.230) 110 ms * te2-2.mpd02.par01.atlas.cogentco.com (130.117.2.81) 111 ms
9 te7-4.ccr04.jfk02.atlas.cogentco.com (154.54.1.21) 110 ms te4-4.ccr04.jfk02.atlas.cogentco.com (130.117.2.9) 110 ms te4-4.mpd03.jfk02.atlas.cogentco.com (130.117.1.245) 110 ms
10 te8-2.mpd01.jfk01.atlas.cogentco.com (154.54.1.210) 110 ms te3-3.mpd01.jfk01.atlas.cogentco.com (154.54.24.149) 111 ms te8-2.mpd01.jfk01.atlas.cogentco.com (154.54.1.210) 109 ms
11 vl3490.mpd01.ewr03.atlas.cogentco.com (154.54.1.30) 117 ms te4-4.mpd01.ewr03.atlas.cogentco.com (154.54.1.3 111 ms vl3490.mpd01.ewr03.atlas.cogentco.com (154.54.1.30) 111 ms
12 you-tube-llc.demarc.cogentco.com (38.101.84.66) 212 ms 110 ms 113 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * dns1.sjl.youtube.com (208.65.152.201) 1595 ms *
[15:19:30]andre@linux-wii:~$ sudo traceroute 208.65.152.137
[sudo] password for andre:
traceroute to 208.65.152.137 (208.65.152.137), 64 hops max, 40 byte packets
1 20.0.0.254 (20.0.0.254) 0 ms 0 ms 0 ms
2 * * *
3 88.157.255.129 (88.157.255.129) 6 ms 6 ms 6 ms
4 195.22.12.69 (195.22.12.69) 6 ms 7 ms 6 ms
5 Cogent.AS174.gigapix.pt (193.136.250.80) 111 ms 111 ms 111 ms
6 te7-3.mpd02.mad05.atlas.cogentco.com (130.117.1.101) 110 ms * *
7 te1-3.mpd01.par02.atlas.cogentco.com (130.117.0.22) 110 ms te4-3.mpd01.par02.atlas.cogentco.com (130.117.2.249) 109 ms te7-3.mpd01.par02.atlas.cogentco.com (130.117.2.173) 111 ms
8 * te1-2.mpd02.par01.atlas.cogentco.com (130.117.1.230) 110 ms te3-2.mpd02.par01.atlas.cogentco.com (130.117.2.110) 111 ms
9 te4-4.mpd03.jfk02.atlas.cogentco.com (130.117.1.245) 110 ms te7-4.ccr04.jfk02.atlas.cogentco.com (154.54.1.21) 111 ms te4-4.mpd03.jfk02.atlas.cogentco.com (130.117.1.245) 109 ms
10 te8-4.mpd01.jfk01.atlas.cogentco.com (154.54.7.70) 110 ms 111 ms 110 ms
11 te4-4.mpd01.ewr03.atlas.cogentco.com (154.54.1.3 111 ms vl3490.mpd01.ewr03.atlas.cogentco.com (154.54.1.30) 112 ms te4-4.mpd01.ewr03.atlas.cogentco.com (154.54.1.3 110 ms
12 you-tube-llc.demarc.cogentco.com (38.101.84.66) 162 ms 202 ms 158 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 dns2.sjl.youtube.com (208.65.152.137) 192 ms 192 ms 192 ms
Quando se quebra o procedimento de um workflow uma vez na vida isso gera a que ele possa vir a ser que quebrado outras vezes, quebras no workflow dá origem a erros e falhas no resto do sistema.
Não gosto muito de o fazer mas aparentemente dá para “desenrascar” várias falhas no workflow actual, mas se o workflow tem falhas então não está bem desenhado.
Lá se usa mais uma vez a teoria do desenrasque muitas vezes usadas pelo Português.
++++ Statistics ++++
Time : 50 sec Messages transfered : 995 Messages skipped : 0 Total bytes transfered : 25959720 Total bytes skipped : 0 Total bytes error : 0 Detected 0 errors Please, rate imapsync at http://freshmeat.net/projects/imapsync/
real 0m50.666s user 0m46.519s sys 0m3.476s
28M /home/ndref/
Teste após ter feito um POP
++++ Statistics ++++ Time : 3 sec Messages transfered : 0 Messages skipped : 943 Total bytes transfered : 0 Total bytes skipped : 25720752 Total bytes error : 0 Detected 0 errors Please, rate imapsync at http://freshmeat.net/projects/imapsync/
real 0m3.377s user 0m3.140s sys 0m0.200s
Eliminei dados de uma das pastas
antes : du -s /home/ndref/ 28228 /home/ndref/
depois : du -s /home/ndref/ 28680 /home/ndref/
++++ Statistics ++++ Time : 44 sec Messages transfered : 39 Messages skipped : 943 Total bytes transfered : 346799 Total bytes skipped : 25720752 Total bytes error : 0 Detected 0 errors Please, rate imapsync at http://freshmeat.net/projects/imapsync/
real 0m43.550s user 0m40.927s sys 0m2.536s
Teste usando copy com scp e depois o mdb2maildir
time scp root@192.168.34.83:/var/spool/mail/user2 . root@192.168.34.83’s password: joseol 100% 275MB 34.4MB/s 00:08
real 0m10.490s user 0m3.840s sys 0m1.264s
time ./mb2md user2 user2Maildir real 0m40.188s user 0m30.702s sys 0m7.488s
Resultou em vários erros durante a conversão de timestamps.
http://www.gerg.ca/hacks/mb2md/ works more or less ok in maildir, need to test the file contents.
http://batleth.sapienti-sat.org/projects/mb2md/
time scp root@192.168.34.83:/var/spool/mail/teste61b . root@192.168.34.83’s password: tvtel47261b 100% 263MB 5.4MB/s 00:49
real 0m56.528s user 0m3.644s sys 0m1.348s
time ./mb2md user1 teste61bMaildir real 0m20.478s user 0m17.633s sys 0m2.600s [18:06:06] mailer1:~/tmp#
time scp root@192.168.34.83:/var/spool/mail/user1 . root@88.157.32.65’s password: tvtel105853b 100% 244MB 15.2MB/s 00:16
real 0m22.852s user 0m3.520s sys 0m1.180s
Após executar conversão com mb2maidir real 0m35.396s user 0m26.550s sys 0m6.644s
Teste hdparm
/dev/sda: Timing cached reads: 9662 MB in 2.00 seconds = 4837.35 MB/sec mailStorage1:/etc#
Hardware
2 discos sas em raid 1 ;
4GB Ram
QuadCore Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
Resultado:
No final o mb2md com nfs mounted volume funcionou bem mas mesmo usando este modo demorou uma eternidade para migrar tudo.
ImapSync demora muito quando se pretendem fazer várias caixas de correio simultaneamente, sincronismo semanalmente para migração lenta é engraçado mas o sync com mais de 1000 caixas de correio com ~250 MB demora muito.
O dovecot continua a surpreender-me com os vários mecanismos de controlo de conteúdo da INBOX .
O que falhou na migração ?! Nada correu tudo bem, foi demorado mas correu bem. Após a cópia fez-se um redimensionamento das quotas para abranger a junção da antiga home+mailbox para a nova Home.
Em alguns casos resultou num tamanho exagerado, as home’s só tinham mailbox do webmail foram migradas também com o script abaixo que foi melhorado pelo Russel Nelson.
Script usado : http://qmail.europnews.de/convert-and-create
este revelou vantagens no acesso às mailbox’s do uw-imap , conversão dos dados do webmail.
HdParm a um disco sas:
hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 8466 MB in 2.00 seconds = 4237.86 MB/sec
Criador do filesystem ReiserFS foi condenado a 25 anos de cadeia.
“When police eventually located Hans Reiser’s Honda CRX a few miles from his home, they found the interior waterlogged, the passenger seat missing, and two books on police murder investigations inside. They also found a sleeping-bag cover stained with a 6-inch wide blotch of Nina’s dried blood.”
A minha única opinião sobre isto é o seguinte o homem seguiu o conceito de um developer até ao fim,
RTFM before everything…
http://techreport.com/discussions.x/14641
for each ping do a reverse dns lookup
Ao ver o vídeo abaixo indicado cheguei às seguintes conclusões :
1 - Não sou só eu que faço merda.
2 - Não somos só nós que fazemos merda.
3 - Afinal até me desemerdo bem dadas as circunstâncias.
4 - Onde está a minha Firewall Alteon não sei quantos com a etiquetazinha a dizer Firewall ??
5 - O meu salário já devia ter sido aumentado para o dobro à dois anos atrás.
http://videos.sapo.pt/izcO3POmFEjgJ2SczNgj
As asneiras que eu fiz decididamente foram muitas mais mas paciência eu também mexo-me mais ;
Lá para o final do ano eu conto-as…
Um dos motivos para evitar falhas ou quebras de disponibilidade é o clustering das aplicações por várias máquinas. Nada de novo aqui, o problema é ter dinheiro para as máquinas.
