Variáveis de ambiente e configuração adicional do usuário

2

Eu tenho um arquivo jar, que funciona em muitas máquinas. No entanto, nós apenas pedimos um novo usuário unix para instalá-lo, e ele não está se comportando da mesma forma ... imagine se poderia ser qualquer coisa relacionada a algum env. var.

a ideia básica é:

WorkingUser@box$ java -jar install.jar -h
[output help instructions]

mas depois

NewUser@box$ java -jar install.jar -h
The java class is not found:  pkg1.pkg2.pkg3.Loader

Antes que alguém pergunte, não há um caminho de classe necessário e sim, o cksum para o jarro está ok. na verdade:

$ jar tf install.jar
META-INF/
META-INF/MANIFEST.MF
pkg1/
pkg1/pkg2/
pkg1/pkg2/pkg3/
pkg1/pkg2/pkg3/script/
pkg1/pkg2/pkg3/Loader.class
pkg1/pkg2/pkg3/LoaderHelper.class
package.jar

E você pode descobrir que MANIFEST.MF é bom, já que funciona em outros usuários.

Eu tentei executar com -cp install.jar sem sucesso. Além disso, o $CLASSPATH para usuários que trabalham e não trabalham contém apenas " . ".

[EDITAR]

Parece que encontrei coisas mais estranhas nesse novo usuário. Existem algumas outras coisas que não funcionam, o que pode indicar um problema com a criação do usuário. Infelizmente eu não conheço muita administração de usuários no AIX, então espero que vocês possam me ajudar a descobrir esses leads;

Acabei de descobrir que o tar simples não pode ser criado na casa desse usuário.

NewUser@box$ echo "thisisatest" > testfile.txt
NewUser@box$ tar cf testfile.txt.tar testfile.txt
tar: The getwd subroutine failed.
        Cannot open the parent directory.

NewUser@box$ ls -l testfile*
-rw-r-----    1 user  group             12 Feb 08 14:15 testfile.txt
-rw-r-----    1 user  group              0 Feb 08 14:15 testfile.txt.tar

(Observe como testfile.txt.tar tem 0 bytes?)

Escusado será dizer que todos estes comandos funcionam no outro utilizador.

Além disso, há outro pequeno sintoma relacionado à conexão com scp , WinSpc na verdade.

A conexão não funciona gerando o seguinte erro no início:

Paracorrigiresteerro,eusimplesmentetenhoqueconfiguraroremotepathnaconfiguraçãodoWinScp(queaparentementedefineocaminhoparaacasadousuário)eelefuncionarábem.

EuusoWinScpnooutroservidorefuncionamuitobemsemqualquerconfiguração-Euignoreiesteerronoinício,masagoraparecemaisrelevante.

Observeque/etc/passwdtemtodososparâmetroscorretosparaesseusuário.Podeseralgumaconfiguraçãododgier...

Alémdisso,apastahometemtodasaspermissõescorretas-nãotenhocertezadecomoesse"bit pegajoso" está relacionado a ele, mas ... bem ...

Obrigado antecipadamente!

obrigado,

f.

    
por filippo 08.02.2011 / 13:04

1 resposta

0

Tente copiar o arquivo para / tmp ou / var / tmp e executar a instalação a partir dele. Será que vai ser melhor / ter sucesso?

[EDITAR]

Isso foi muito próximo do problema real. Eu acabei fazendo um teste similar que funcionou e que com alguns testes me levou a achar que as permissões mount point estavam erradas, ie a pasta onde o fs do usuário está montado pertence a root e teve acesso 774 (nenhum exec a outros ).

Sempre acho fascinante como permissões erradas em um nível baixo causam os efeitos mais adversos nas camadas superiores. Eu tinha (e ainda não tenho certeza disso) que as permissões do ponto de montagem afetaram o fs montado ...

De qualquer forma, nós demos a permissão do exec e voilá , o java encontra suas classes. Existem mais problemas com toda esta instalação, mas estes podem ir para outras questões:)

Obrigado a todos.

    
por 08.02.2011 / 18:38