Se deseja saber quanto tempo resta para um certificado no seu servidor de aplicação expirar, segue um comandinho de shell bem rápido. digite o comando a seguir(não se esqueça de colocar o alias e a senha do certificado, aqui simbolizadas por variávies):
echo Restam $(( ($( xx=`keytool -list -v -keystore MEU_CERTIFICADO.jks -alias $MEU_ALIAS -storepass $MINHA_SOTREPASS | grep Valid | awk '{data=substr($0, index($0, "until:")+11 ,length($0)); print data; exit; }'`; date -d "$xx" +%s) - $(date +%s) ) / 86400)) dias para expirar o certificado.
a saída no shell será:
Restam X dias para expirar o certificado.
Agora vai da sua criatividade elaborar um script.
enjoy. ;)
quinta-feira, 18 de fevereiro de 2010
sexta-feira, 12 de fevereiro de 2010
Reset do ias_admin - Oracle iAS
Se nesse momento acontece com você de precisar usar o enterprise manager e não possuir o ias_admin, siga estes passos:
1) pare o enterprise manager:
$ORACLE_HOME/opmn/bin/emctl stop iasconsole
2) Faça um backup do arquivo jazn-data.xml localizado em $ORACLE_HOME/sysman/j2ee/config
3) edite o arquivo jazn-data.xml apagando toda a linha 6, inclusive as tags.
1 <code> <realm>
2 <name>enterprise-manager</name>
3 <users>
4 <user>
5 <name>ias_admin</name>
6 <credentials>XXXXXXABC123</credentials>
7 </user></users></realm></code>
4) salve o arquivo e chame o seguinte comando:
$ORACLE_HOME/bin/emctl set password reset $NOVA_SENHA
5) inicie o enterprise manager.
$ORACLE_HOME/bin/emctl start iasconsole.
Pronto. Resetado.
1) pare o enterprise manager:
$ORACLE_HOME/opmn/bin/emctl stop iasconsole
2) Faça um backup do arquivo jazn-data.xml localizado em $ORACLE_HOME/sysman/j2ee/config
3) edite o arquivo jazn-data.xml apagando toda a linha 6, inclusive as tags.
1 <code> <realm>
2 <name>enterprise-manager</name>
3 <users>
4 <user>
5 <name>ias_admin</name>
6 <credentials>XXXXXXABC123</credentials>
7 </user></users></realm></code>
4) salve o arquivo e chame o seguinte comando:
$ORACLE_HOME/bin/emctl set password reset $NOVA_SENHA
5) inicie o enterprise manager.
$ORACLE_HOME/bin/emctl start iasconsole.
Pronto. Resetado.
domingo, 7 de fevereiro de 2010
Vulnerabilidades do jboss: Porta RMI
Recentemente, resolvi testar as versões antigas do jboss em alguns clientes.
de uma forma bem prática, fiz um telnet ás portas de sevriço RMI (a default é 8083) e executei alguns comandos.
exemplo:
#telnet [hostapp] 8083
GET %. HTTP/1.0
HTTP/1.0 400 /opt/jboss/server/default/deploy/jmx-console.war (Is a directory)
Content-Type: text/html
---
Nesse primeiro comando, ele me retornou o diretório do jboss. eu consegui capturar também os arquivos de configuração, até mesmo o login e senha de banco de dados (outra prática incorreta é não manter isto criptografado).
para corrigir, sugiro a atualização para versões acima da 4.0.2. Se isso não for possível logo de início, o bugtraq nos traz um aconselhamento:
dentro do jboss-service.xml, faça a alteração em attribute name="DownloadServerClasses" de true para false.
não resolve tudo mas ajuda a proteger um pouco até atualizar o jboss.
de uma forma bem prática, fiz um telnet ás portas de sevriço RMI (a default é 8083) e executei alguns comandos.
exemplo:
#telnet [hostapp] 8083
GET %. HTTP/1.0
HTTP/1.0 400 /opt/jboss/server/default/deploy/jmx-console.war (Is a directory)
Content-Type: text/html
---
Nesse primeiro comando, ele me retornou o diretório do jboss. eu consegui capturar também os arquivos de configuração, até mesmo o login e senha de banco de dados (outra prática incorreta é não manter isto criptografado).
seguem aqui mais alguns:#GET %login-config HTTP/1.0
#GET %server.policy HTTP/1.0
http://seclists.org/bugtraq/2005/Jun/147
enfim, existem muito mais coisas possíveis,
como caminhar pelos diretórios do jboss se utilizando
de "%../tmp" ou "%../deploy"
dando uma googada, li esta notificação no bugtraq:
para corrigir, sugiro a atualização para versões acima da 4.0.2. Se isso não for possível logo de início, o bugtraq nos traz um aconselhamento:
dentro do jboss-service.xml, faça a alteração em attribute name="DownloadServerClasses" de true para false.
não resolve tudo mas ajuda a proteger um pouco até atualizar o jboss.
sexta-feira, 5 de fevereiro de 2010
Multiplas jdk no Oracle iAS
Aconteceu comigo uma solicitação de upgrade do java no OracleAS 10g. você pensa na hora: qualquer servidor de aplicação você facilmente atualiza a JDK. Ok, em 5 minutos de pesquisa você encontra alguém dizendo para você substituir o diretório /jdk. Não concordo. Uma coisa é você utilizar uma instância OC4J com uma aplicação qualquer. Outra coisa é você possuir muitas aplicações, Oracle Forms e Reports á todo vapor com bibliotecas extras como a webutils por exemplo, ou Portal, ou um cluster. O fato é que o core de funcionamento interno do Oracle AS é baseado no java 1.4.
Meu conselho é:
1) Mantenha o diretório jdk padrão quietinho, sem alterar nada.
2) Para as aplicações que necessitam de outra versão do java, abra o opmn.xml ($ORACLE_HOME/opmn/conf/opmn.xml), e adicione a seguinte linha destacada aqui em negrito, embaixo de cada componente que deseja atualizar a versão da JVM:
<process-type id="MINHA APLICACAO">
<module-data>
<category id="start parameters">
<data id...>
...
<data id="java-bin" value="PATH_DO_JAVA/bin/java"/>
</category>
Dessa forma, você não compromete nada que seja nativo do iAS e mantém as instâncias OC4J que deseja atualizadas. Isto não é uma prática que funciona sempre, mantenha contato com a sua fábrica para ver exatamente o quê do container é utilizado. Mas lhes digo, não tive nenhum problema agindo assim.
Meu conselho é:
1) Mantenha o diretório jdk padrão quietinho, sem alterar nada.
2) Para as aplicações que necessitam de outra versão do java, abra o opmn.xml ($ORACLE_HOME/opmn/conf/opmn.xml), e adicione a seguinte linha destacada aqui em negrito, embaixo de cada componente que deseja atualizar a versão da JVM:
<process-type id="MINHA APLICACAO">
<module-data>
<category id="start parameters">
<data id...>
...
<data id="java-bin" value="PATH_DO_JAVA/bin/java"/>
</category>
Dessa forma, você não compromete nada que seja nativo do iAS e mantém as instâncias OC4J que deseja atualizadas. Isto não é uma prática que funciona sempre, mantenha contato com a sua fábrica para ver exatamente o quê do container é utilizado. Mas lhes digo, não tive nenhum problema agindo assim.
quinta-feira, 4 de fevereiro de 2010
Horário de verão resolvido de uma vez!
Já li dviersos posts e diversas maneiras de fazer atualização do java no temido horário de verão. Demorou um pouco para que eu adotasse esta forma na qual vou compartilhar, muito simples de se fazer.
primeiro vamos checar se está tudo certo:
crie um arquivo chamado DSTTest.java com o seguinte código
/*
* Timezone test to check that the new US 2007 DST rules have been
* picked up by the JRE. TimeZone used is the default one on OS.
* Sample result :
* $java DSTTest "11/04/2007 0:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 00:00:00 EDT 2007
* TimeZone tested : Eastern Daylight Time
* Your tested time is in daylight-savings time.
* $java DSTTest "11/04/2007 3:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 03:00:00 EST 2007
* TimeZone tested : Eastern Standard Time
* Your tested time is not in daylight-savings time.
* $echo $TZ
* America/New_York
*
*/
import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;
public class DSTTest {
private static final String DATE_FORMAT_PATTERN = "MM/dd/yyyy hh:mm a";
public static void main(String[] args) {
try {
String ver = System.getProperty("java.version");
String testDate = args[0]; // "11/04/2007 1:00 AM";
SimpleDateFormat df = new SimpleDateFormat(DATE_FORMAT_PATTERN);
Date currentDate = df.parse(testDate, new ParsePosition(0));
System.out.println("JRE version : " + ver);
System.out.println(currentDate);
// Default timezone from the system is used.
TimeZone tz = TimeZone.getDefault();
// Could manually set the timezone above. e.g :
//TimeZone tz = TimeZone.getTimeZone("America/New_York");
System.out.println("TimeZone tested : " + tz.getDisplayName(tz.inDaylightTime(currentDate), TimeZone.LONG));
boolean indaylight = tz.inDaylightTime(currentDate);
System.out.println("Your tested time is " + (indaylight ? "in " : "not in ") + "daylight-savings time.");
} catch (Exception e) {
System.out.println("Error encoutered. Please insure you supply a valid date format pattern.");
System.out.println("Ensure you've quotes placed around the pattern!");
System.out.println("e.g java DSTTest \"11/04/2007 1:00 AM\"");
}
}
}
em seguida, compile o garoto: #javac DSTTest.java
após compilar é hora de rodar: #java DSTTest "02/22/2010 1:00 AM"
o resultado te apontará se na data escolhida (no caso 22/02, após a virada do horário) a JVM estará no horário de verão ou não:
...
TimeZone Tested: Brasilia Summer Time
Your tested time is in daylght time.
....
Caso ela ainda estiver no horário de verão, ou não entrar (dependendo da data em que você precisa ajustar), basta aplicar o patch chamado tzupdater
http://java.sun.com/javase/tzupdater_README.html, siga os comandos e boa sorte! o resultado será positivo, com toda certeza.
já fiz por outras maneiras mas esta é a melhor que eu encontrei. ah, fica um plus: pra vc ter certeza e provar para as pessoas que a JVM está com o horário correto, compile este programinha (#javac hora.java) e rode-o (#java hora). ele captura a hora da JVM.
teste.java
------
public class teste {
public static void main (String[] args ) {
System.out.println(new java.util.Date());
}
}
-----
enjoy!
primeiro vamos checar se está tudo certo:
crie um arquivo chamado DSTTest.java com o seguinte código
/*
* Timezone test to check that the new US 2007 DST rules have been
* picked up by the JRE. TimeZone used is the default one on OS.
* Sample result :
* $java DSTTest "11/04/2007 0:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 00:00:00 EDT 2007
* TimeZone tested : Eastern Daylight Time
* Your tested time is in daylight-savings time.
* $java DSTTest "11/04/2007 3:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 03:00:00 EST 2007
* TimeZone tested : Eastern Standard Time
* Your tested time is not in daylight-savings time.
* $echo $TZ
* America/New_York
*
*/
import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;
public class DSTTest {
private static final String DATE_FORMAT_PATTERN = "MM/dd/yyyy hh:mm a";
public static void main(String[] args) {
try {
String ver = System.getProperty("java.version");
String testDate = args[0]; // "11/04/2007 1:00 AM";
SimpleDateFormat df = new SimpleDateFormat(DATE_FORMAT_PATTERN);
Date currentDate = df.parse(testDate, new ParsePosition(0));
System.out.println("JRE version : " + ver);
System.out.println(currentDate);
// Default timezone from the system is used.
TimeZone tz = TimeZone.getDefault();
// Could manually set the timezone above. e.g :
//TimeZone tz = TimeZone.getTimeZone("America/New_York");
System.out.println("TimeZone tested : " + tz.getDisplayName(tz.inDaylightTime(currentDate), TimeZone.LONG));
boolean indaylight = tz.inDaylightTime(currentDate);
System.out.println("Your tested time is " + (indaylight ? "in " : "not in ") + "daylight-savings time.");
} catch (Exception e) {
System.out.println("Error encoutered. Please insure you supply a valid date format pattern.");
System.out.println("Ensure you've quotes placed around the pattern!");
System.out.println("e.g java DSTTest \"11/04/2007 1:00 AM\"");
}
}
}
em seguida, compile o garoto: #javac DSTTest.java
após compilar é hora de rodar: #java DSTTest "02/22/2010 1:00 AM"
o resultado te apontará se na data escolhida (no caso 22/02, após a virada do horário) a JVM estará no horário de verão ou não:
...
TimeZone Tested: Brasilia Summer Time
Your tested time is in daylght time.
....
Caso ela ainda estiver no horário de verão, ou não entrar (dependendo da data em que você precisa ajustar), basta aplicar o patch chamado tzupdater
http://java.sun.com/javase/tzupdater_README.html, siga os comandos e boa sorte! o resultado será positivo, com toda certeza.
já fiz por outras maneiras mas esta é a melhor que eu encontrei. ah, fica um plus: pra vc ter certeza e provar para as pessoas que a JVM está com o horário correto, compile este programinha (#javac hora.java) e rode-o (#java hora). ele captura a hora da JVM.
teste.java
------
public class teste {
public static void main (String[] args ) {
System.out.println(new java.util.Date());
}
}
-----
enjoy!
quarta-feira, 3 de fevereiro de 2010
a saga do oracle web-cache
O Enterprise Manager do Oracle Application Server de um dos servidores produtivos de um cliente não funcionava. Extremamente crashado. acabado. detonado. Os amigos indianos no qual abrimos chamado no fabricante foram claros em dizer: despreze-o. utilize na mão(como todo garoto de 15 anos faz com uma revista).
Pois bem, um dia foi necessário alterar um parâmetro que acredito que todos conhecem, chamado origin server timeout. até aí nenhum problema, afinal todos nós sabemos que existe o web-cache admin. Fiz a pergunta que preferia nunca ter feito: qual a senha?
Não existia. Bom, a hora é cara e tinha que resolver então parti pra ignorância:
a solução foi capturar um hash genérico para uma senha "administrator". após editar o parâmetro MONITORING com o hash B3ACA92C793EE0E9B1A9B0A5F5FC044E05140DF3
do webcache.xml, e reiniciar o serviço consegui me logar no webcache manager e alterar a origin server timeout dentro de network timeout para o solicitado, e em seguida a senha que foi entregue aos responsáveis.
Depois de configurar, não satisfeito eu quis saber o bendito parâmetro para no caso do web-cache admin também não funcionar. o grep -i demorava mas eu esperei com um belo café ele terminar:
OSRECV_TIMEOUT - dentro de webcache.xml. Ele mostra numa medida de tempo diferente, isto torna difícil encontrá-lo logo de cara.
Pegadinha do mallandro.. ;)
Pois bem, um dia foi necessário alterar um parâmetro que acredito que todos conhecem, chamado origin server timeout. até aí nenhum problema, afinal todos nós sabemos que existe o web-cache admin. Fiz a pergunta que preferia nunca ter feito: qual a senha?
Não existia. Bom, a hora é cara e tinha que resolver então parti pra ignorância:
a solução foi capturar um hash genérico para uma senha "administrator". após editar o parâmetro MONITORING com o hash B3ACA92C793EE0E9B1A9B0A5F5FC044E05140DF3
do webcache.xml, e reiniciar o serviço consegui me logar no webcache manager e alterar a origin server timeout dentro de network timeout para o solicitado, e em seguida a senha que foi entregue aos responsáveis.
Depois de configurar, não satisfeito eu quis saber o bendito parâmetro para no caso do web-cache admin também não funcionar. o grep -i demorava mas eu esperei com um belo café ele terminar:
OSRECV_TIMEOUT - dentro de webcache.xml. Ele mostra numa medida de tempo diferente, isto torna difícil encontrá-lo logo de cara.
Pegadinha do mallandro.. ;)
Assinar:
Comentários (Atom)