Onderwerp: Java EJB vraagje met JBoss

Hi allemaal,

Is het mogelijk, en zo ja hoe, met behulp van een EJB op de remote server
een bash script op te starten onder het root account?

BVD

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J.Kraaijeveld@Askesis.nl
web: www.askesis.nl

Joost Kraaijeveld <J.Kraaijeveld@askesis.nl> wrote:
> Is het mogelijk, en zo ja hoe, met behulp van een EJB op de remote server
> een bash script op te starten onder het root account?

Ik zou niet inzien waarom dat niet zou kunnen (althans als de
securitymanager van jboss java.lang.Runtime.exec() toestaat). Maar
waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.

--

Daniel Tryba

> Ik zou niet inzien waarom dat niet zou kunnen (althans als de
> securitymanager van jboss java.lang.Runtime.exec() toestaat).
Hoewel ik e.e.a. van JBoss afweet heb ik hier niets concreets over kunnen
vinden.

> waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.
Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige programma
in Java te maken.

Groeten

Joost

Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>:
>> waarom zou je dat uberhaupt willen? Dit riekt naar een vieze hack.
>
> Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige
> programma in Java te maken.

Remote rootlogins toestaan is een veiligsheidsrisico, maar daar ben je
natuurlijk van op de hoogte en zo

--
robert

Joost Kraaijeveld:
>Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige programma
>in Java te maken.

Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
een EJB-applicatie gebruiken?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Joost Kraaijeveld:
>>Dit voornamelijk riekt naar een mogelijkheid om een webmin-achtige
>>programma in Java te maken.
>
> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
> prachtig voor de command line en Q&D-scripts...

bash is nooit prachtig, maar laten we er geen shellwar van maken

> ...maar waarom zou je het in een EJB-applicatie gebruiken?

Als je geautomatiseerde systeembeheertaken op een *nixdoos wilt uitvoeren
kom je al snel terecht bij shellscripting.

--
robert

> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
> prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
> een EJB-applicatie gebruiken?
Om commandlinetools op te starten die met die, mits de juiste argumenten
worden meegegeven, doen wat je wil.

Joost Kraaijeveld:
>> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash is
>> prachtig voor de command line en Q&D-scripts, maar waarom zou je het in
>> een EJB-applicatie gebruiken?

>Om commandlinetools op te starten die met die, mits de juiste argumenten
>worden meegegeven, doen wat je wil.

De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat je
wilt).

Als je die kunt opstarten, dan kun je ook direct die andere
commandlinetools opstarten :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Joost Kraaijeveld:
>
>>> Hoe kom je van een "webmin-achtig programma" op "bash scripts"? Bash
>>> is prachtig voor de command line en Q&D-scripts, maar waarom zou je
>>> het in een EJB-applicatie gebruiken?
>
>>Om commandlinetools op te starten die met die, mits de juiste argumenten
>>worden meegegeven, doen wat je wil.
>
> De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat
> je wilt).
>
> Als je die kunt opstarten, dan kun je ook direct die andere
> commandlinetools opstarten :-)

Toch lijkt me het grouperen van aanroepen van externe tools in één script
een stukje handiger dan die aanroepen te hardcoden in een Java-applicatie.

--
robert

> De shell _is_ een commandline tool, die doet wat je zegt (soms niet wat je
> wilt).
>
> Als je die kunt opstarten, dan kun je ook direct die andere
> commandlinetools opstarten :-)
Ah ja, natuurlijk. Ik noemde de shell voornamelijk als voorbeeld van de
commandline tool. Ik heb een hele zut aan scripts die al wrappers zijn om
andere commandline tools. Vandaar.

Weet jij een methode om met behulp van JBoss externe programma's op te
starten op de remote server?

Groeten

Joost

robert:
>Toch lijkt me het grouperen van aanroepen van externe tools in één script
>een stukje handiger dan die aanroepen te hardcoden in een Java-applicatie.

Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?) en
programmeren in script "handiger" ("softcoden")?

Ik zou juist zo snel mogelijk van die vage shell scripts afwillen en het
volledig in een nette programmeertaal als Java programmeren. Denk aan de
voordelen van exception handling enzo.

Of dat in het abstracte platform-onafhankelijke Java een beetje gaat
lukken weet ik niet, maar met Python zou ik zeker die benadering kiezen.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>
>>Toch lijkt me het grouperen van aanroepen van externe tools in één
>>script een stukje handiger dan die aanroepen te hardcoden in een
>>Java-applicatie.
>
> Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?)
> en programmeren in script "handiger" ("softcoden")?

Zo moeilijk is het toch niet om te begrijpen? Stel dat je een taak wilt
uitvoeren die er als volgt uit ziet:

programma1 > bestand1
programma2 < bestand1 > bestand2
programma3 < bestand2 | programma4 > bestand3

Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
met die redirects en pipes niet...).

Op een later tijdstip wil je echter de uitvoer van programma4 pipen door
programma5. Dat houdt in dat je je Java source kunt gaan aanpassen,
programma5 in de pipeline moet opnemen, je code opnieuw moet compileren, en
je hele applicatie opnieuw kunt opstarten omdat er een aangepaste .class
file in je .jar zit.

Of je roept vanuit je Javacode één shellscript aan, en past on-the-fly dat
script aan als er aanpassingen gemaakt moeten worden aan de pipeline.

Ik weet wel waar ik voor zou kiezen.

> Ik zou juist zo snel mogelijk van die vage shell scripts afwillen en het
> volledig in een nette programmeertaal als Java programmeren. Denk aan de
> voordelen van exception handling enzo.
>
> Of dat in het abstracte platform-onafhankelijke Java een beetje gaat
> lukken weet ik niet, maar met Python zou ik zeker die benadering kiezen.

Het gaat om het aanroepen van _externe_ programma's. Om daar Python, als
mislukte shellinterpreter, voor te gebruiken is je goed recht, maar het
lijkt me weinig nuttig.

Je kan natuurlijk de functionaliteiten van die externe programma's gaan
implementeren in Python/Java/..., maar zoiets is vaak maar in beperkte mate
voordeliger dan een aanroep van een extern programma.

--
robert

robert:
>Rene Pijlman:
> > robert:
> >
> >>Toch lijkt me het grouperen van aanroepen van externe tools in één
> >>script een stukje handiger dan die aanroepen te hardcoden in een
> >>Java-applicatie.
> >
> > Que? Waarom is programmeren in Java "hardcoden" (wat is dat eigenlijk?)
> > en programmeren in script "handiger" ("softcoden")?
>
>Zo moeilijk is het toch niet om te begrijpen?

Er was nog niets om te begrijpen, behalve een niet-onderbouwde bewering
met een onduidelijke betekenis :-)

>Stel dat je een taak wilt uitvoeren die er als volgt uit ziet:
>
> programma1 > bestand1
> programma2 < bestand1 > bestand2

Da's gewoon file I/O. Dat is toch niets bijzonders in Java? Waarom zou je
dat kleine stukje van een Java-programma opeens in een externe shell gaan
doen?

> programma3 < bestand2 | programma4 > bestand3
>
>Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
>met die redirects en pipes niet...).

Waar komt toch het idee vandaan dat je functionaliteit moet implementeren
door text stream-producerende en -consumerende programma's aan elkaar te
knopen?

Ontwerp toch een normaal OO-programma met classes, exception handling
etc., dat functioneel hetzelfde doet.

>Op een later tijdstip wil je echter de uitvoer van programma4 pipen door
>programma5. Dat houdt in dat je je Java source kunt gaan aanpassen,
>programma5 in de pipeline moet opnemen, je code opnieuw moet compileren, en
>je hele applicatie opnieuw kunt opstarten omdat er een aangepaste .class
>file in je .jar zit.

Ja, zo werkt Java-programmeren nu eenmaal. Dat geldt bij alle wijzigingen
van het algoritme.

>Of je roept vanuit je Javacode één shellscript aan, en past on-the-fly dat
>script aan als er aanpassingen gemaakt moeten worden aan de pipeline.
>
>Ik weet wel waar ik voor zou kiezen.

Ik ook: Python :-) Dat combineert OO-programmeren met de eenvoud van
shell-scripts.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>
>>Stel dat je een taak wilt uitvoeren die er als volgt uit ziet:
>>
>> programma1 > bestand1
>> programma2 < bestand1 > bestand2
>
> Da's gewoon file I/O. Dat is toch niets bijzonders in Java? Waarom zou
> je dat kleine stukje van een Java-programma opeens in een externe shell
> gaan doen?
>
>> programma3 < bestand2 | programma4 > bestand3
>>
>>Als je dat in Java wilt coden, prima, ga je gang (maar leuk lijkt het me
>>met die redirects en pipes niet...).
>
> Waar komt toch het idee vandaan dat je functionaliteit moet
> implementeren door text stream-producerende en -consumerende programma's
> aan elkaar te knopen?

Ik noem een voorbeeld dat niet geheel ondenkbaar is in een applicatie
waarmee je systeembeheer wilt uitvoeren. Logs parsen en interessante
onderdelen van die logs archiveren, om maar iets te noemen.

> Ontwerp toch een normaal OO-programma met classes, exception handling
> etc., dat functioneel hetzelfde doet.

gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
zelf bouwen, enzovoort. Plus dat ik niet verwacht dat jij in Java een
grep kunt bouwen die sneller is dan de commandlineversie; en met mega-GB
logfiles is snelheid toch vaak echt wel een vereiste.

--
robert

robert:
>Rene Pijlman:
> > Ontwerp toch een normaal OO-programma met classes, exception handling
> > etc., dat functioneel hetzelfde doet.
>
>gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
>zelf bouwen, enzovoort.

Nu haal je twee dingen door elkaar:

1) Programmeermodel Java vs. shell script

2) Hergebruiken vs. zelf bouwen

Ik had het over punt 1.

>Plus dat ik niet verwacht dat jij in Java een grep kunt bouwen die sneller is
>dan de commandlineversie; en met mega-GB logfiles is snelheid toch vaak echt
>wel een vereiste.

Nu haal je twee dingen door elkaar:

1) Programmeermodel Java vs. shell script

2) De performance van C vs. die van Java.

Als performance belangrijk is dan zou ik zeggen: implementeer de code in C
en gebruik JNI.

Het wordt tijd dat we shell scripts naar het computermuseum verbannen en
dat we normale OO-talen, APIs en componentarchitecturen gaan gebruiken om
bouwstenen aan elkaar te knopen.

Shell scripts zijn een idee uit de jaren 80, toen nog niemand
daadwerkelijk gebruik maakte van OO-talen en componentarchitecturen.

Hé, is J2EE/EJB trouwens niet een componentarchitectuur? Gebruik het dan
zo!

--
René Pijlman

Wat wil jij leren? http://www.leren.nl