mySphere Posts

Share

Interessante este blog somente sobre XPages vale a pena fazer umas visitas

XPages

Share

Recentemente tenho enfrentado alguns problemas com recepção de correio de outras empresas. As causas são diversas desde correio com endereço errado, hosts encontrados em black lists e problemas de DNS.
O maior problema que tenho visto é a má configuração de DNS por parte dos “remetentes” ou seja DNS MAL CONFIGURADO.
No primeiro momento fico indignado em saber e sofrer com a pressão de uma grande empresa não conseguir enviar e-mail para nosso domínio. O problema é sempre MEU nunca do “remetente”. Fica sempre a briga entre Meus usuários, eu e o grande cliente, traduzindo a briga entre O ROCHEO E O MAR, quem sai perdendo? O MARISCO no caso eu.
Depois de pensar sobre o assunto fiz uma pesquisa sobre estas questões de DNS  e fiquei espantado com o que andei encontrando.
Lendo alguns artigos descobri que o registro PTR para servidores de correio não é OBRIGATÓRIO e que 80% dos DNS’s na internet tem algum problema de configuração, então descobri  o motivo de vários hosts não conseguirem transmitir correio para o meu domínio. Resolvi então retirar a verificação do PRT (resolução de nome reversa).
Estarei observando o comportamento dos  usuários a medida que reclamações devem diminuir
Achei este artigo interessante http://www.saas.nsw.edu.au/solutions/dns.html e que explica como tudo funciona.

Share

Fazer um tema para o WebSphere Portal é um desafio dependendo dos requisitos, normalmente do pessoal do marketing. São menus dinâmicos, um monte de CSS imagens etc. Outro problema é fazer o tema funcionar em vários browsers (nada de diferente para aplicativos comuns em ambiente web).
O difícil é ficar contornando bugs principalmente do nosso amigo IE7. Um bug conhecido é a forma como o IE7 interpreta o CSS quando queremos um layout centralizado, muito comum hoje. Desde o meu primeiro projeto com Portal 6 tive de implementar um layout assim só que os browsers onde testei o código eram IE6 e Firefox 2.0.
Novamente nosso time teve de fazer um tema com layout centralizado e tudo estava indo bem até os testes com IE7. O tema ficava correto no IE6,IE8,Firefox 2.x ,3.0 e 3.5 mas no IE7 ele ficava sempre a esquerda.

Solução:

1 – Editar o default.jsp do tema utilizado e colocar uma tag DIV após o BODY e antes da DIV id=FLYParent> como exemplo DIV CLASS=”NOME DA CLASSE”
e fechar esta DIV após o /BODY. O que isto faz é colocar a página do portal dentro de uma DIV

2 – Criar a referência desta DIV no styles-theme.jspf da forma como está abaixo

.NOME DA CLASSE {
background-color:#FFFFFF;
height:100%;
margin:0 auto;
padding:0;
width:940px;
}

3 -Formatar a id FLYParent com os seguintes itens, no mesmo arquivo:
#FLYParent {
background-color:#FFFFFF;
float:left;
width:940px;
}

Até aqui tudo certo conforme achei pesquisando na Web este contorno para o bug, mas somente centralizou no portal depois que foi feito o seguinte:

Acrescentar uma imagem (veja abaixo (neste caso ela está em branco pq o fundo é branco) na pasta do tema em colors/default/

Referenciar esta imagem no styles-theme.jspf da seguinte forma e acrescentar os itens caso não tenha:
body {
background:#FFFFFF url(./colors/default/fullBackground.jpg) repeat-y scroll center top;
color:#FFFFFF;
margin:0;
padding:0;
}

Editar body, html também da seguinte forma no mesmo styles-theme.jspf:
body, html {
height:100%;
margin:0;
padding:0;
width:100%;
}

Pronto!! Créditos para o Vinicius Afonso que trabalhou comigo para contornar este problema.

Share

A IBM ainda não homologou o IE 8 para ser utilizado como “cliente” do WebSphere Portal. De acordo com o TN 1389292 o IE 8 somente será compatível com versões 6.0.1.6+ e com a versão 6.1.0.2+ ou seja em breve estaremos aplicando fixes nos ambientes para mais uma mudança de browser, claro que ainda tem de ver o suporte para o FireFox 3.5.
A falta de padronização dos browsers causa muita dor de cabeça…

portal

Share

Sincronizar marcas de documentos não lidos sempre foi um desafio. Em ambientes com cluster isto se torna ainda mais grave pois o que todos querem é que o correio eletrônico seja igual em todos os servidores. Alguns cuidados tem de ser tomados e entre eles configurar corretamente os bancos de dados para que a replicação de marcas de não lidos seja feita corretamente. O primeiro passo é configurar a replicação destas informações. Na guia avançado da base de dados.
Se o usuário utilizar réplicas locais deve-se marcar a opção All Servers.
O TN 7002920 mostra a arquitetura das marcas de não lidos e os componentes envolvidos e o TN 1140018 mostra como resolver alguns problemas.

Image:Unread Marks

Unread Marks

Share

Atualmente venho instalando mais Domino em servidores com Linux do que servidores com Windows 2003/2008.
Já que o Linux é inevitável seguem alguns comandos que podem ajudar a verificar problemas de performance como uso de cpu, memória.

O comando abaixo mostra a utlização de CPU, user CPU, system CPU e mais alguns CPU’s

#mpstat

Mostra 5 relatórios de estatísticas para todos os processadores de 2 em 2 segundos

# mpstat -P ALL 2 5

Lista processos pelo % de uso da CPU

#ps -e -o pcpu,cpu,nice,state,cputime,args

Lista processos pelo uso de memória
 
#ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS

Mostra o quanto de memória ainda resta (em MB)

#free -m

Share

Uma documentação muito legal da IBM é um guia com um cenário simples mas que contém informações muito úteis para migração de um Portal 6.0 para Portal 6.1.
O guia está disponível neste link.

Migração

Share

O servidor Domino não possui a funcionalidade de resposta automática quando um usuário recebe correio. O motivo para implementar isto  Ã© uma simples mudança de telefone e endereço, ou seja , para cada correio que uma pessoa receber um aviso automático irá ser enviado para avisar que o endereço da empresa irá mudar e também o telefone.  Pesquisei um pouco e achei “pronto” um TN    que sendo “traduzido” resolve o problema. A desvantagem é que para cada correio que chegar vai sair outro, o tráfego vai aumentar bastante. Não encontrei o link do TN no site da IBM o resumo do TN segue abaixo

You can use a LotusScript agent to test for Internet addresses and limit the replies to those senders. For example, the agent below would use the trigger of “After new mail arrives.” The agent tests for an Internet address and then sends a reply to the sender with a “Thank you for your inquiry” response.

NOTE:  The code below is a sample script provided to illustrate one way to approach this issue. In order for this example to perform as intended, the script must be laid out exactly as indicated below. IBM Support cannot customize this script for a customer’s own configuration.

In the script, you can customize the BodyText variable as desired. The code can be placed in the Initialize event.

Dim session As New NotesSession
Dim db As NotesDatabase
Dim col As NotesDocumentCollection
Dim doc As NotesDocument
Dim MailDoc As NotesDocument
Dim Body As NotesRichTextItem
Dim OldBody As NotesRichTextItem
Dim OriginalFromAddress As String
Dim Subject As String
Dim BodyText As String

‘This is the body of the email, Chr(10) indicates a new line
‘you can change the body to whatever you want following this format

BodyText = “Thank you for your inquiry.” + Chr(10) +_
“This is an automatically generated response. Please do not reply.” + Chr(10) +_
“We will contact you shortly regarding your inquiry.” + Chr(10) +_
“Regards,” + Chr(10)+_
“John Doe” ‘SET THIS TO DESIRED NAME

‘set objects
Set db = session.CurrentDatabase
Set col = db.UnprocessedDocuments
Set doc = col.GetFirstDocument

‘set the subject of the email to go out
Subject = “Re: ” +  doc.GetItemValue(“Subject”)(0)

‘loop through the document collection
While Not doc Is Nothing
‘check the address to see if it contains an @ sign
If doc.HasItem(“SMTPOriginator”) Then
OriginalFromAddress = doc.GetItemValue(“SMTPOriginator”)(0)
Elseif doc.HasItem(“From”) Then
OriginalFromAddress = doc.GetItemValue(“From”)(0)
Else
Goto nextdoc
End If

‘if an @ sign is found, send a reply
If Instr(OriginalFromAddress,”@”) <> 0 Then
‘create a new mail document
Set MailDoc = db.CreateDocument

‘set the subject and from fields
Call MailDoc.ReplaceItemValue(“Subject”, Subject)

‘set the body and append the body from the original email
Set OldBody = doc.GetFirstItem(“body”)
Set body = MailDoc.CreateRichTextItem(“body”)
Call body.AppendText(bodyText)
Call body.AddNewline(2)
Call body.AppendRTItem(oldBody)

‘send the document
Call MailDoc.Send(False,OriginalFromAddress)
End If

Nextdoc:
‘update the processedDoc flag so that this document isn’t processed
‘again on a subsequent run

Call session.UpdateProcessedDoc(doc)

‘get the next document in the collection
Set doc = col.GetNextDocument(doc)
        Wend

Resposta

Share

Neste fim de semana fizemos um upagrade de um Domino 7.0.2 para a versão 8.5. O Linux instalado antes era o SUSE SLES 9 SP3.
O Domino 8.5 não suporta o SUSE 9 então solicitamos o upgrade para versão SUSE SLES 10 SP1, pois já existem 03 servidores em produção com este Linux.
O upgrade do Linux foi realizado, mas a versão instalada foi o SUSE SLES 10 SP2. Aparentemente tudo ok pois os requesitos de sistema não informam nada sobre SP1 ou SP2 para o SUSE. A instalação terminou com um “warning” informado que o SUSE 10 não é suportado. Foi um warning mas devia ser um “fail” pois o Domino assim que foi iniciado apresentou um CRASH. Veja abaixo a mensagem de erro:
 
06/20/2009 06:22:49 PM  HTTP Server: Using Internet Site Configuration View
Exception in thread “main” java.lang.SecurityException: Signers of ‘lotus.domino.axis.InternalFault’ do not match signers of other classes in package
        at java.lang.ClassLoader.checkPackageSigners(ClassLoader.java:312)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:254)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:506)
      
      ………
Exception in thread “main” java.lang.SecurityException: Signers of ‘lotus.domino.axis.message.RPCParam’ do not match signers of other classes in package
        at java.lang.ClassLoader.checkPackageSigners(ClassLoader.java:312)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:254)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:506)
      
       ……….
Exception in thread “main” java.lang.SecurityException: Signers of ‘lotus.domino.types.Fault’ do not match signers of other classes in package
        at java.lang.ClassLoader.checkPackageSigners(ClassLoader.java:312)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:254)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:506)
        at java.net.URLClassLoader.access$300(URLClassLoader.java:77)
        at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:905)
        at java.security.AccessController.doPrivileged(AccessController.java:284)

Stack base = 0xbfeb088c, Stack size = 556 bytes
Fatal Error signal = 0x0000000b PID/TID = 9362/-1263466832
6/20/2009 18:22:51  Running NSD
NSD is in progress ……………..

Verifiquei o install.log e percebi que ele removeu alguns arquivos do diretório /java/bin. Como era um upgrade achamos que poderia ser até normal.
A task que gerava o CRASH era a HTTP. Abrimos um PMR e a IBM não tinha ainda nenhum caso parecido, mas ajudaram pois fizeram um análise do NSD e detectaram que alguns arquivos estavam faltando.

Solução:  O Linux foi reinstalado para SUSE SLES 10 SP1 e reinstalamos o Domino 8.5, tudo funcionou perfeitamente.
Portanto cuidado com o SUSE SLES 10 SP2, infelizmente não ficamos sabendo a causa do problema pois o servidor tinha de voltar a operar e a janela de manutenção já estava acabando.

Domino

Share

A tarefa update pode causar problemas de performance quando o servidor tem muitos bancos de dados principalmente quando os bancos de dados são grandes. Uma alternativa para evitar problemas, é agendar a frequência de atualização do índice. Isto depende de cada aplicação, do design das views.  Uma opção interessante é o agendamento onde pode-se configurar de quanto em quanto tempo ou quando o índice vai ser atualizado.
Para configurar vá nas propriedades do banco de dados e configure a atualização do full text index como na figura abaixo:

Image:Agendar Update do Full Text

Depois crie um programa no Domino Directory para atualizar o índice;

Image:Agendar Update do Full Text
Image:Agendar Update do Full Text

full text

Share

Um log que pode ser muito útil para rastrear as “tarefas” administrativas pode ser configurado no Portal. O seriço é o Auditing Service que gera um log de vários eventos tais como criação de portlets entre outras. Para ver mais detalhes veja neste link.
O serviço tem de ser habilitado alterando-se o arquivo AuditService.properties e reiniciar o portal

portal

Share

Não considero uma boa política ficar restringindo o uso do Sametime, é uma ferramenta de comunicação muito poderosa, mas… (sempre tem um mas) existem usuários que abusam ou o chefe não compreende a importância do uso do Sametime.
Fui questionado, por um cliente sobre qual a melhor maneira de restringir o uso do Sametime ou seja que alguns usuários não usem o produto. O TN1166845 mostra algumas maneiras de atingir o objetivo.
A opção que fizemos foi usar um atributo do Diretório Domino existente (evita customização) e alterar o filtro de autenticação e busca do Sametime.

sametime